From 8c05dd67720ae3630b768a435ca4f8350a3cd2d7 Mon Sep 17 00:00:00 2001 From: Jody Garnett Date: Fri, 23 Feb 2024 20:12:40 -0800 Subject: [PATCH] Deployed 3c2441440c with MkDocs version: 1.5.3 --- community/backuprestore/usagerest/index.html | 24 +- community/cog/cog/index.html | 229 +++- community/dds/index.html | 32 +- community/elasticsearch/index.html | 205 +++- .../features-templating/directives/index.html | 134 ++- community/features-templating/index.html | 32 +- community/hana/index.html | 52 +- community/mbtiles/input/index.html | 74 +- community/ncwms/index.html | 24 +- community/ogc-api/coverages/index.html | 21 +- community/ogc-api/features/index.html | 51 +- community/ogc-api/maps/index.html | 27 +- community/ogc-api/styles/index.html | 21 +- community/ogc-api/tiles/index.html | 21 +- community/opensearch-eo/automation/index.html | 139 ++- .../opensearch-eo/configuration/index.html | 65 +- community/pgraster/pgraster/index.html | 64 +- community/proxy-base-ext/usage/index.html | 89 +- community/solr/configure/index.html | 64 +- .../vector-mosaic/configuration/index.html | 52 +- configuration/contact/index.html | 107 +- configuration/service-metadata/index.html | 59 +- configuration/status/index.html | 199 +++- data/app-schema/feature-chaining/index.html | 216 +++- data/app-schema/mongo-tutorial/index.html | 43 +- data/cascaded/stored_query/index.html | 74 +- data/cascaded/wfs/index.html | 117 +- data/cascaded/wms/index.html | 57 +- data/cascaded/wmts/index.html | 67 +- data/database/connection-pooling/index.html | 57 +- data/database/oracle/index.html | 67 +- data/database/postgis/index.html | 298 +++-- data/database/primarykey/index.html | 47 +- data/raster/arcgrid/index.html | 42 +- data/raster/geopkg/index.html | 42 +- data/raster/geotiff/index.html | 42 +- .../imagemosaic/configuration/index.html | 327 +++++- data/raster/imagemosaic/tutorial/index.html | 147 ++- data/raster/imagepyramid/index.html | 42 +- data/raster/worldimage/index.html | 42 +- data/vector/directory/index.html | 52 +- data/vector/geopkg/index.html | 62 +- data/vector/properties/index.html | 42 +- data/vector/shapefile/index.html | 62 +- data/webadmin/layers/index.html | 34 +- data/webadmin/stores/index.html | 34 +- extensions/authkey/index.html | 69 +- extensions/cas/index.html | 83 +- .../geofence-server/rest-adminrule/index.html | 153 ++- extensions/geofence-server/rest/index.html | 189 ++- extensions/geofence/cache/index.html | 46 +- extensions/geopkg-output/usage/index.html | 99 +- extensions/grib/grib/index.html | 42 +- extensions/importer/rest_reference/index.html | 33 +- extensions/monitoring/query/index.html | 138 ++- extensions/monitoring/reference/index.html | 303 ++++- extensions/netcdf/netcdf/index.html | 42 +- extensions/params-extractor/usage/index.html | 93 +- extensions/querylayer/index.html | 37 +- .../wmts-multidimensional/usage/index.html | 322 +++++- filter/ecql_reference/index.html | 334 ++++-- filter/filter_reference/index.html | 265 ++++- filter/function_reference/index.html | 1021 ++++++++++++++--- geowebcache/webadmin/demopage/index.html | 49 +- gettingstarted/geopkg-quickstart/index.html | 180 ++- gettingstarted/group-quickstart/index.html | 44 +- gettingstarted/image-quickstart/index.html | 164 ++- gettingstarted/postgis-quickstart/index.html | 90 +- gettingstarted/style-quickstart/index.html | 37 +- production/config/index.html | 37 +- production/container/index.html | 47 +- rest/about/index.html | 52 +- rest/api/resources/index.html | 44 +- rest/api/selfadmin/index.html | 27 +- rest/api/userrole/index.html | 273 ++++- search/search_index.json | 2 +- security/auth/chain/index.html | 34 +- security/layer/index.html | 187 ++- security/urlchecks/index.html | 53 +- .../usergrouprole/roleservices/index.html | 286 +++-- .../usergroupservices/index.html | 238 ++-- security/webadmin/auth/index.html | 141 ++- security/webadmin/data/index.html | 49 +- security/webadmin/services/index.html | 39 +- security/webadmin/ugr/index.html | 475 ++++++-- services/wcs/configuration/index.html | 80 +- services/wcs/reference/index.html | 32 +- services/wfs/axis_order/index.html | 39 +- services/wfs/outputformats/index.html | 51 +- services/wfs/reference/index.html | 258 ++++- services/wfs/webadmin/index.html | 34 +- services/wms/configuration/index.html | 102 +- services/wms/decoration/index.html | 209 +++- services/wms/get_legend_graphic/index.html | 97 +- .../features/kmlreflector/index.html | 146 ++- .../features/kmlregionation/index.html | 42 +- .../features/kmlscoring/index.html | 72 +- .../tutorials/heights/heights/index.html | 32 +- .../tutorials/time/time/index.html | 116 +- .../wms/nonstandardautonamespace/index.html | 69 +- services/wms/outputformats/index.html | 133 ++- services/wms/reference/index.html | 618 ++++++++-- services/wps/operations/index.html | 42 +- services/wps/processes/gs/index.html | 160 ++- sitemap.xml.gz | Bin 4568 -> 4568 bytes styling/css/cookbook/index.html | 34 +- styling/css/cookbook/line/index.html | 253 +++- styling/css/cookbook/point/index.html | 145 ++- styling/css/cookbook/polygon/index.html | 156 ++- styling/css/cookbook/raster/index.html | 67 +- styling/css/directives/index.html | 44 +- styling/css/filters/index.html | 127 +- styling/css/properties/index.html | 858 +++++++++++--- styling/css/valuetypes/index.html | 34 +- styling/mbstyle/cookbook/index.html | 29 +- styling/mbstyle/cookbook/lines/index.html | 165 ++- styling/mbstyle/cookbook/points/index.html | 57 +- styling/mbstyle/cookbook/polygons/index.html | 63 +- styling/mbstyle/reference/index.html | 23 +- styling/sld/cookbook/index.html | 37 +- styling/sld/cookbook/lines/index.html | 253 +++- styling/sld/cookbook/points/index.html | 145 ++- styling/sld/cookbook/polygons/index.html | 156 ++- styling/sld/cookbook/rasters/index.html | 77 +- .../composite-blend/modes/index.html | 110 +- .../sld/extensions/pointsymbols/index.html | 248 +++- styling/sld/extensions/randomized/index.html | 45 +- .../extensions/rendering-transform/index.html | 32 +- .../sld/extensions/substitution/index.html | 61 +- .../sld/extensions/z-order/example/index.html | 63 +- .../sld/extensions/z-order/syntax/index.html | 116 +- styling/sld/reference/labeling/index.html | 160 ++- styling/sld/reference/layers/index.html | 86 +- .../sld/reference/linesymbolizer/index.html | 135 ++- .../sld/reference/pointsymbolizer/index.html | 148 ++- .../reference/polygonsymbolizer/index.html | 99 +- styling/sld/reference/rules/index.html | 116 +- styling/sld/reference/sld/index.html | 31 +- styling/sld/reference/styles/index.html | 98 +- .../sld/reference/textsymbolizer/index.html | 223 +++- styling/webadmin/index.html | 293 +++-- styling/workshop/css/css/index.html | 37 +- styling/workshop/css/linestring/index.html | 30 +- styling/workshop/css/point/index.html | 37 +- styling/workshop/css/polygon/index.html | 37 +- styling/workshop/css/raster/index.html | 74 +- .../workshop/mbstyle/linestring/index.html | 37 +- styling/workshop/mbstyle/mbstyle/index.html | 37 +- styling/workshop/mbstyle/point/index.html | 37 +- styling/workshop/mbstyle/polygon/index.html | 37 +- styling/workshop/mbstyle/raster/index.html | 74 +- styling/workshop/ysld/linestring/index.html | 37 +- styling/workshop/ysld/point/index.html | 37 +- styling/workshop/ysld/polygon/index.html | 37 +- styling/workshop/ysld/raster/index.html | 74 +- styling/workshop/ysld/ysld/index.html | 37 +- styling/ysld/cookbook/index.html | 34 +- styling/ysld/cookbook/lines/index.html | 239 +++- styling/ysld/cookbook/points/index.html | 131 ++- styling/ysld/cookbook/polygons/index.html | 141 ++- styling/ysld/cookbook/rasters/index.html | 72 +- .../ysld/reference/featurestyles/index.html | 95 +- styling/ysld/reference/filters/index.html | 111 +- styling/ysld/reference/rules/index.html | 65 +- styling/ysld/reference/scalezoom/index.html | 83 +- styling/ysld/reference/symbolizers/index.html | 155 ++- .../reference/symbolizers/line/index.html | 374 +++--- .../reference/symbolizers/point/index.html | 622 +++++----- .../reference/symbolizers/polygon/index.html | 566 +++++---- .../reference/symbolizers/raster/index.html | 228 ++-- .../reference/symbolizers/text/index.html | 498 ++++++-- styling/ysld/reference/transforms/index.html | 59 +- styling/ysld/reference/variables/index.html | 37 +- .../imagemosaic_timeseries/index.html | 159 ++- .../palettedimage/palettedimage/index.html | 67 +- tutorials/wmsreflector/index.html | 52 +- 176 files changed, 16465 insertions(+), 4716 deletions(-) diff --git a/community/backuprestore/usagerest/index.html b/community/backuprestore/usagerest/index.html index 5573637789b..33e17b39633 100644 --- a/community/backuprestore/usagerest/index.html +++ b/community/backuprestore/usagerest/index.html @@ -4061,7 +4061,7 @@

Usage Example

Query status of Backup executions

Status of the operation can be queried making an HTTP GET request to the location listed in the response.

-
``http://mygeoserver/geoserver/rest/br/backup/$ID.{json/xml}``
+
``http://mygeoserver/geoserver/rest/br/backup/$ID.{json/xml}``
 

Replace $ID with the ID of the backup operation you'd like to inspect.

curl -u "admin:geoserver" http://mygeoserver/geoserver/rest/br/backup/1.json
@@ -4100,7 +4100,7 @@ 

Usage Example

  • BK_PASSWORD_TOKENS: A comma separated list of equal sign separated key/values to be replaced in data store passwords in an incoming backup. For example:

    -
    BK_PASSWORD_TOKENS=${workspace:store1.passwd.encryptedValye}=foo,${workspace:store2.passwd.encryptedValue}=bar
    +
    BK_PASSWORD_TOKENS=${workspace:store1.passwd.encryptedValye}=foo,${workspace:store2.passwd.encryptedValue}=bar
     
  • @@ -4124,19 +4124,19 @@

    Usage Example

    Also an optional Filter can be passed to restrict the scope of the restore operation to a list of workspaces.

    For example:

    -
    {
    -   "restore":{
    -      "archiveFile":"/home/sg/BackupAndRestore/test_rest_1.zip",
    -      "options":{
    -        "option": ["BK_DRY_RUN=true"] 
    -      },
    -"filter": "name IN ('topp','geosolutions-it')"
    -   }
    -}
    +
    {
    +   "restore":{
    +      "archiveFile":"/home/sg/BackupAndRestore/test_rest_1.zip",
    +      "options":{
    +        "option": ["BK_DRY_RUN=true"] 
    +      },
    +"filter": "name IN ('topp','geosolutions-it')"
    +   }
    +}
     

    If archiveFile is specified, the archive specified on that path of the remote file system will be used to initiate the restore procedure. Otherwise the archive needs to be uploaded from your local system.

    Then make a POST HTTP request to GeoServer's REST interface endpoint for the restore procedure

    -
    curl -u "admin:geoserver" -i -H "Content-Type: application/json" -X POST --data @restore_post.json http://mygeoserver/geoserver/rest/br/restore/
    +
    curl -u "admin:geoserver" -i -H "Content-Type: application/json" -X POST --data @restore_post.json http://mygeoserver/geoserver/rest/br/restore/
     

    Restore procedure will be initiated.

    Here is a sample response:

    diff --git a/community/cog/cog/index.html b/community/cog/cog/index.html index 7e584ef2613..fe89a8f51f5 100644 --- a/community/cog/cog/index.html +++ b/community/cog/cog/index.html @@ -4117,35 +4117,94 @@

    COG GeoTIFF Configuration Panel

    COG Connection params

    Checking the Cloud Optimized GeoTIFF (COG) checkbox will provide new options:

    -
    -

    Option Description

    -
    -

    URL (prefixed by cog://) representing the connection URL to the COG Dataset.

    -

    Range Reader Settings Which type of Range Reader implementation. Values currently supported are HTTP, GoogleCloud, Azure, S3 the latter using an S3 Client

    -

    User Name / Access Key ID / Account Name Optional user name (HTTP) or Access Key ID (S3) or Account Name (Azure) in case the COG dataset requires authentication

    -

    Password / Secret Access Key / Account Key Password (HTTP) or Secret Access Key (S3) or Account Key (Azure) for the previous credential

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + +
    OptionDescription
    URL(prefixed by cog://) representing the connection URL to the COG Dataset.
    Range Reader SettingsWhich type of Range Reader implementation. Values currently supported are HTTP, GoogleCloud, Azure, S3 the latter using an S3 Client
    User Name / Access Key ID / Account NameOptional user name (HTTP) or Access Key ID (S3) or Account Name (Azure) in case the COG dataset requires authentication
    Password / Secret Access Key / Account KeyPassword (HTTP) or Secret Access Key (S3) or Account Key (Azure) for the previous credential

    COG ImageMosaic Configuration

    Additional configuration parameters can be specified in the ImageMosaic indexer configuration, in order to properly configure a COG based ImageMosaic.

    indexer.properties

    -
    -

    Parameter Mandatory? Description

    -
    -

    Cog Y A boolean flag (true/false) to be set (Cog=true) in order to signal that the ImageMosaic is a COG data mosaic.

    -

    CogRangeReader N Specifies the desired RangeReader implementation performing the Range Reads requests.

    -

    CogUser N Credential to be set whenever basic HTTP authentication is needed to access the COG Datasets or an S3 Access KeyID is required or an Azure AccountName is required

    -

    CogPassword N Password for the above user OR Secret Access Key for the above S3 KeyId or AccountKey for the above Azure AccountName.

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ParameterMandatory?Description
    CogYA boolean flag (true/false) to be set (Cog=true) in order to signal that the ImageMosaic is a COG data mosaic.
    CogRangeReaderNSpecifies the desired RangeReader implementation performing the Range Reads requests.
    CogUserNCredential to be set whenever basic HTTP authentication is needed to access the COG Datasets or an S3 Access KeyID is required or an Azure AccountName is required
    CogPasswordNPassword for the above user OR Secret Access Key for the above S3 KeyId or AccountKey for the above Azure AccountName.

    COG RangeReader

    The following table provides the values for the CogRangeReader based on the type of target storage:

    -
    -

    Storage type Class name

    -
    -

    HTTP Can be omitted, or set to it.geosolutions.imageioimpl.plugins.cog.HttpRangeReader

    -

    AWS S3 it.geosolutions.imageioimpl.plugins.cog.S3RangeReader

    -

    Google Cloud it.geosolutions.imageioimpl.plugins.cog.GSRangeReader

    -

    Azure it.geosolutions.imageioimpl.plugins.cog.AzureRangeReader

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + +
    Storage typeClass name
    HTTPCan be omitted, or set to it.geosolutions.imageioimpl.plugins.cog.HttpRangeReader
    AWS S3it.geosolutions.imageioimpl.plugins.cog.S3RangeReader
    Google Cloudit.geosolutions.imageioimpl.plugins.cog.GSRangeReader
    Azureit.geosolutions.imageioimpl.plugins.cog.AzureRangeReader

    COG Global Settings

    The GeoServer Global Settings page contains the default COG settings presented when setting up a new COG GeoTIFF Store.

    @@ -4158,27 +4217,72 @@

    Image locations

    HTTP Client (OkHttp) configuration

    HTTP client configuration (based on OkHttp client) can be specified through Environment variables.

    -
    -

    Environment Variable Description

    -
    -

    IIO_HTTP_MAX_REQUESTS The maximum number of requests to execute concurrently. Above this requests queue in memory, waiting for the running calls to complete. (Default 128)

    -

    IIO_HTTP_MAX_REQUESTS_PER_HOST The maximum number of requests for each host to execute concurrently. (Default 5)

    -

    IIO_HTTP_MAX_IDLE_CONNECTIONS The maximum number of idle connections. (Default 5)

    -

    IIO_HTTP_KEEP_ALIVE_TIME The Keep alive time (in seconds), representing maximum time that excess idle threads will wait for new tasks before terminating. (Default 60)

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + +
    Environment VariableDescription
    IIO_HTTP_MAX_REQUESTSThe maximum number of requests to execute concurrently. Above this requests queue in memory, waiting for the running calls to complete. (Default 128)
    IIO_HTTP_MAX_REQUESTS_PER_HOSTThe maximum number of requests for each host to execute concurrently. (Default 5)
    IIO_HTTP_MAX_IDLE_CONNECTIONSThe maximum number of idle connections. (Default 5)
    IIO_HTTP_KEEP_ALIVE_TIMEThe Keep alive time (in seconds), representing maximum time that excess idle threads will wait for new tasks before terminating. (Default 60)

    AWS S3 Client configuration

    A single S3 Asynchronous Client will be used for the same region and alias (url schema, i.e. http, https). The following Environment Variables can be set to customize the pool for the asynchronous client for that particular alias. On the table below, replace the "\$ALIAS\$" template with HTTP or HTTPS or S3 if you are configuring properties for these schema.

    -
    -

    Environment Variable Description

    -
    -

    IIO_\$ALIAS\$_AWS_CORE_POOL_SIZE The core pool size for the S3 Client (Default 50)

    -

    IIO_\$ALIAS\$_AWS_MAX_POOL_SIZE The maximum number of thread to allow in the pool for the S3 Client (Default 128)

    -

    IIO_\$ALIAS\$_AWS_KEEP_ALIVE_TIME The Keep alive time (in seconds), representing maximum time that excess idle threads will wait for new tasks before terminating. (Default 10)

    -

    IIO_\$ALIAS\$_AWS_USER Default user (access key ID) for AWS basic authentication credentials

    -

    IIO_\$ALIAS\$_AWS_PASSWORD Default password (secret access key) for AWS basic authentication credentials

    -

    IIO_\$ALIAS\$_AWS_REGION Default AWS region

    -

    IIO_\$ALIAS\$_AWS_ENDPOINT Endpoint to Amazon service or any other S3-compatible service run by a third-party

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Environment VariableDescription
    IIO_\$ALIAS\$_AWS_CORE_POOL_SIZEThe core pool size for the S3 Client (Default 50)
    IIO_\$ALIAS\$_AWS_MAX_POOL_SIZEThe maximum number of thread to allow in the pool for the S3 Client (Default 128)
    IIO_\$ALIAS\$_AWS_KEEP_ALIVE_TIMEThe Keep alive time (in seconds), representing maximum time that excess idle threads will wait for new tasks before terminating. (Default 10)
    IIO_\$ALIAS\$_AWS_USERDefault user (access key ID) for AWS basic authentication credentials
    IIO_\$ALIAS\$_AWS_PASSWORDDefault password (secret access key) for AWS basic authentication credentials
    IIO_\$ALIAS\$_AWS_REGIONDefault AWS region
    IIO_\$ALIAS\$_AWS_ENDPOINTEndpoint to Amazon service or any other S3-compatible service run by a third-party

    Google Cloud storage configuration

    The credentials to access Google Cloud cannot be provided as username and password (an authentication method that Google Cloud does not support), but need to be provided via a system variable pointing to the key file:

    set GOOGLE_APPLICATION_CREDENTIALS=/path/to/the/key-file.json
    @@ -4186,15 +4290,36 @@ 

    Google Cloud storage configuration

    Azure configuration

    A single Azure Client will be used for the same container. Account and container will be retrieved from the provided Azure URL. The following System Properties can be set to customize client properties where missing.

    -
    -

    System property Description

    -
    -

    azure.reader.accountName The Azure Account Name

    -

    azure.reader.accountKey The Azure Account Key for the above Account

    -

    azure.reader.container The default container for the above Account

    -

    azure.reader.prefix The optional prefix containing blobs

    -

    azure.reader.maxConnections The max number of connections supported by the underlying Azure client

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    System propertyDescription
    azure.reader.accountNameThe Azure Account Name
    azure.reader.accountKeyThe Azure Account Key for the above Account
    azure.reader.containerThe default container for the above Account
    azure.reader.prefixThe optional prefix containing blobs
    azure.reader.maxConnectionsThe max number of connections supported by the underlying Azure client

    Client configuration (System Properties)

    Note that all the IIO settings reported in the previous tables can also be specified using System Properties instead of Environment variables. You just need to replace UPPER CASE words with lower case words and underscores with dots. So, the value for Maximum HTTP requests can be specified by setting either a IIO_HTTP_MAX_REQUESTS Environment variable or a iio.http.max.requests Java System Property alternatively (Environment variables are checked first).

    By default, when accessing a COG, an initial chunk of 16 KB is read in attempt to parse the header so that the reader will have the offset and length of the available tiles. When dealing with files hosting many tiles, it is possible that the whole header won't fit in the initial chunk. In this case additional reads (chunks of the same size) will be progressively made to complete loading the header. A it.geosolutions.cog.default.header.length system property can be configured to set the length (in bytes) of the reading chunk. Tuning this so that the header is read with few extra requests can help improve performance. A value too large can cause memory consumption issues and will reduce efficiency, as un-necessary data will be read.

    diff --git a/community/dds/index.html b/community/dds/index.html index ef098bacc5c..0a30f47738b 100644 --- a/community/dds/index.html +++ b/community/dds/index.html @@ -3888,12 +3888,32 @@

    Configuring the BIL format

    For a client application to use a BIL layer, it must know the data encoding of the BIL file (e.g. 16-bit integer, 32-bit floating point, etc), the byte order of the data, and the value that indicates missing data. BIL files do not contain this metadata, so it may be necessary to configure the server to produce BIL files in the format that a client application expects.

    The BIL output format can be configured for each layer in the Publishing tab of the layer configuration. The plugin supports the following options:

    -
    -

    Option Description

    -

    Default encoding The data encoding to use if the request does not specify an encoding. For example, application/bil does not specify the response encoding, while application/bil16 does specify an encoding. Default: use same encoding as layer source files.

    -

    Byte order Byte order of the response. Default: network byte order (big endian).

    -

    No Data value The value that indicates missing data. If this option is set, missing data values will be recoded to this value. Default: no data translation.

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + +
    OptionDescription
    Default encodingThe data encoding to use if the request does not specify an encoding. For example, application/bil does not specify the response encoding, while application/bil16 does specify an encoding. Default: use same encoding as layer source files.
    Byte orderByte order of the response. Default: network byte order (big endian).
    No Data valueThe value that indicates missing data. If this option is set, missing data values will be recoded to this value. Default: no data translation.

    For compatibility with the default behavior of NASA World Wind, use these settings:

    • Default encoding: application/bil16
    • diff --git a/community/elasticsearch/index.html b/community/elasticsearch/index.html index 5453b4db50b..db338f0877f 100644 --- a/community/elasticsearch/index.html +++ b/community/elasticsearch/index.html @@ -4234,21 +4234,68 @@

      Configuring layer


      field_list


      -
      -

      Item Description

      -

      Use All Use all fields in the layer feature type

      -

      Use Used to select the fields that will make up the layer feature type

      -

      Name Name of the field

      -

      Type Type of the field, as derived from the Elasticsearch schema. For geometry types, you have the option to provide a more specific data type.

      -

      Order Integer order values are used to sort fields, where fields with smaller order are returned first

      -

      Custom Name Provides the option to give the field a custom name

      -

      Default Geometry Indicates if the geometry field is the default one. Useful if the documents contain more than one geometry field, as SLDs and spatial filters will hit the default geometry field unless otherwise specified

      -

      Stored Indicates whether the field is stored in the index

      -

      Analyzed Indicates whether the field is analyzed

      -

      SRID Native spatial reference ID of the geometries. Currently only EPSG:4326 is supported.

      -

      Valid Date Formats Possible valid date formats used for parsing field values and printing filter elements

      -

      Refresh If the field mappings or Elasticsearch schema has changed since this page was loaded, use this button to update the field configuration list.

      -
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      ItemDescription
      Use AllUse all fields in the layer feature type
      UseUsed to select the fields that will make up the layer feature type
      NameName of the field
      TypeType of the field, as derived from the Elasticsearch schema. For geometry types, you have the option to provide a more specific data type.
      OrderInteger order values are used to sort fields, where fields with smaller order are returned first
      Custom NameProvides the option to give the field a custom name
      Default GeometryIndicates if the geometry field is the default one. Useful if the documents contain more than one geometry field, as SLDs and spatial filters will hit the default geometry field unless otherwise specified
      StoredIndicates whether the field is stored in the index
      AnalyzedIndicates whether the field is analyzed
      SRIDNative spatial reference ID of the geometries. Currently only EPSG:4326 is supported.
      Valid Date FormatsPossible valid date formats used for parsing field values and printing filter elements
      RefreshIf the field mappings or Elasticsearch schema has changed since this page was loaded, use this button to update the field configuration list.

      To return to the field table after it has been closed, click the "Configure Elasticsearch fields" button below the "Feature Type Details" panel on the layer configuration page.


      field_list_edit

      @@ -4430,12 +4477,42 @@

      Geohash grid aggregations

      The store may update the precision to a smaller value, if it finds it goes beyond the aggregation limits setup in its configuration, see grid_size and grid_threshold above.

      Grid Strategy

      gridStrategy: Parameter to identify the org.geoserver.process.elasticsearch.GeoHashGrid implementation that will be used to convert each geohashgrid bucket into a raster value (number).

      -
      -

      Name gridStrategy gridStrategyArgs Description

      -

      Basic basic no Raster value is geohashgrid bucket doc_count.

      -

      Metric metric yes Raster value is geohashgrid bucket metric value.

      -

      Nested nested_agg yes Extract raster value from nested aggregation results.

      -
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      NamegridStrategygridStrategyArgsDescription
      BasicbasicnoRaster value is geohashgrid bucket doc_count.
      MetricmetricyesRaster value is geohashgrid bucket metric value.
      Nestednested_aggyesExtract raster value from nested aggregation results.

      gridStrategyArgs: (Optional) Parameter used to specify an optional argument list for the grid strategy.

      emptyCellValue: (Optional) Parameter used to specify the value for empty grid cells. By default, empty grid cells are set to 0.

      scaleMin, scaleMax: (Optional) Parameters used to specify a scale applied to all raster values. Each tile request is scaled according to the min and max values for that tile. It is best to use a non-tiled layer with this parameter to avoid confusing results.

      @@ -4460,11 +4537,32 @@

      Basic

      Extracted raster value: 1

      Metric

      Raster value is geohashgrid bucket metric value.

      -
      -

      Argument Index Default Value Description

      -

      0 metric Key used to pluck metric object from top level bucket. Empty string results in plucking doc_count.

      -

      1 value Key used to pluck the value from the metric object.

      -
      + + + + + + + + + + + + + + + + + + + + + + + + + +
      Argument IndexDefault ValueDescription
      0metricKey used to pluck metric object from top level bucket. Empty string results in plucking doc_count.
      1valueKey used to pluck the value from the metric object.

      Example Aggregation:

      {
         "agg": {
      @@ -4493,15 +4591,52 @@ 

      Metric

      Extracted raster value: 4.9

      Nested

      Extract raster value from nested aggregation results.

      -
      -

      Argument Index Default Value Description

      -

      0 nested Key used to pluck nested aggregation results from the geogrid bucket.

      -

      1 empty string Key used to pluck metric object from each nested aggregation bucket. Empty string results in plucking doc_count.

      -

      2 value Key used to pluck the value from the metric object.

      -

      3 largest largest | smallest. Strategy used to select a bucket from the nested aggregation buckets. The grid cell raster value is extracted from the selected bucket.

      -

      4 value key | value. Strategy used to extract the raster value from the selected bucket. value: Raster value is the selected bucket's metric value. key: Raster value is the selected bucket's key.

      -

      5 null (Optional) Map used to convert String keys into numeric values. Use the format key1:1;key2:2. Only utilized when raster strategy is key.

      -
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      Argument IndexDefault ValueDescription
      0nestedKey used to pluck nested aggregation results from the geogrid bucket.
      1empty stringKey used to pluck metric object from each nested aggregation bucket. Empty string results in plucking doc_count.
      2valueKey used to pluck the value from the metric object.
      3largestlargest
      4valuekey
      5null(Optional) Map used to convert String keys into numeric values. Use the format key1:1;key2:2. Only utilized when raster strategy is key.

      Example Aggregation:

      {
         "agg": {
      diff --git a/community/features-templating/directives/index.html b/community/features-templating/directives/index.html
      index b206ee5091e..8426bb27c98 100644
      --- a/community/features-templating/directives/index.html
      +++ b/community/features-templating/directives/index.html
      @@ -4503,30 +4503,120 @@ 

      Template directive summary

      The following constitutes a summary of all the template directives and it is meant to be used for quick reference. Each directive is explained in detail in the sections below.

      JSON based templates

      The following are the directives available in JSON based templates.

      -
      -

      Usage Syntax Description

      -

      property interpolation \${property} specify it as an attribute value ("json_attribute":"${property}")

      -

      cql evaluation \$\${cql} specify it as an element value ("json_attribute":"$${cql}")

      -

      setting the evaluation context for child attributes. \${source}. specify it as the first nested object in arrays ({"$source":"property"}) or as an attribute in objects ("$source":"property")

      -

      filter the array, object, attribute \$filter specify it inside the first nested object in arrays ({"$filter":"condition"}) or as an attribute in objects ("$filter":"condition") or in an attribute next to the attribute value separated by a , ("attribute":"$filter{condition}, ${property}")

      -

      defines options to customize the output outside of a feature scope \$options specify it at the top of the JSON template as a JSON object (GeoJSON options: "$options":{"flat_output":true, "separator":"."}; JSON-LD options: "$options":{"@context": "the context json", "encode_as_string": true, "@type":"schema:SpecialAnnouncement", "collection_name":"customCollectionName"}).

      -

      allows including a template into another \$include, \$includeFlat specify the $include option as an attribute value ("attribute":"$include{subProperty.json}") and the $includeFlat as an attribute name with the included template path as a value ("$includeFlat":"included.json")

      -

      allows a template to extend another template \$merge specify the $merge directive as an attribute name containing the path to the extended template (:code: "\$merged":"base_template.json").

      -

      allows null values to be encoded. default is not encoded. \${property}! or \$\${expression}! ! at the end of a property interpolation or cql directive ("attribute":"${property}!" or "attribute":"$${expression}!").

      -
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      UsageSyntaxDescription
      property interpolation\${property}specify it as an attribute value ("json_attribute":"${property}")
      cql evaluation\$\${cql}specify it as an element value ("json_attribute":"$${cql}")
      setting the evaluation context for child attributes.\${source}.specify it as the first nested object in arrays ({"$source":"property"}) or as an attribute in objects ("$source":"property")
      filter the array, object, attribute\$filterspecify it inside the first nested object in arrays ({"$filter":"condition"}) or as an attribute in objects ("$filter":"condition") or in an attribute next to the attribute value separated by a , ("attribute":"$filter{condition}, ${property}")
      defines options to customize the output outside of a feature scope\$optionsspecify it at the top of the JSON template as a JSON object (GeoJSON options: "$options":{"flat_output":true, "separator":"."}; JSON-LD options: "$options":{"@context": "the context json", "encode_as_string": true, "@type":"schema:SpecialAnnouncement", "collection_name":"customCollectionName"}).
      allows including a template into another\$include, \$includeFlatspecify the $include option as an attribute value ("attribute":"$include{subProperty.json}") and the $includeFlat as an attribute name with the included template path as a value ("$includeFlat":"included.json")
      allows a template to extend another template\$mergespecify the $merge directive as an attribute name containing the path to the extended template (:code: "\$merged":"base_template.json").
      allows null values to be encoded. default is not encoded.\${property}! or \$\${expression}!! at the end of a property interpolation or cql directive ("attribute":"${property}!" or "attribute":"$${expression}!").

      XML based templates

      The following are the directives available in XML based templates.

      -
      -

      Usage Syntax Description

      -

      property interpolation \${property} specify it either as an element value (<element>${property}</element>) or as an xml attribute value (<element attribute:"${property}"/>)

      -

      cql evaluation \$\${cql} specify them either as an element value (<element>$${cql}</element>) or as an xml attribute value (<element attribute:"$${cql}"/>)

      -

      setting the evaluation context for property interpolation and cql evaluation in child elements. gft:source specify it as an xml attribute (<element gft:source:"property">)

      -

      filter the element to which is applied based on the defined condition gft:filter specify it as an XML attribute on the element to be filtered (<element gft:filter:"condition">)

      -

      marks the beginning of an XML template. gft:Template It has to be the root element of an XML template (<gft:Template> Template content</gft:Template>)

      -

      defines options to customize the output outside of a feature scope gft:Options specify it as an element at the beginning of the xml document after the <gft:Template> one (<gft:Options></gft:Options>). GML options: <gtf:Namespaces>,<gtf:SchemaLocation>. HTML options: <script>, :code: <script type="application/ld+json"/>, <style>, :code: <link>.

      -

      allows including a template into another \$include, gft:includeFlat specify the $include option as an element value (<element>$include{included.xml}</element>) and the gft:includeFlat as an element having the included template as text content (<gft:includeFlat>included.xml</gft:includeFlat>)

      -

      allows null values to be encoded. default is not encoded. \${property}! specify it either as an element value (<element>${property}!</element>) or as an xml attribute value (<element attribute:"${property}!"/>)

      -
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      UsageSyntaxDescription
      property interpolation\${property}specify it either as an element value (<element>${property}</element>) or as an xml attribute value (<element attribute:"${property}"/>)
      cql evaluation\$\${cql}specify them either as an element value (<element>$${cql}</element>) or as an xml attribute value (<element attribute:"$${cql}"/>)
      setting the evaluation context for property interpolation and cql evaluation in child elements.gft:sourcespecify it as an xml attribute (<element gft:source:"property">)
      filter the element to which is applied based on the defined conditiongft:filterspecify it as an XML attribute on the element to be filtered (<element gft:filter:"condition">)
      marks the beginning of an XML template.gft:TemplateIt has to be the root element of an XML template (<gft:Template> Template content</gft:Template>)
      defines options to customize the output outside of a feature scopegft:Optionsspecify it as an element at the beginning of the xml document after the <gft:Template> one (<gft:Options></gft:Options>). GML options: <gtf:Namespaces>,<gtf:SchemaLocation>. HTML options: <script>, :code: <script type="application/ld+json"/>, <style>, :code: <link>.
      allows including a template into another\$include, gft:includeFlatspecify the $include option as an element value (<element>$include{included.xml}</element>) and the gft:includeFlat as an element having the included template as text content (<gft:includeFlat>included.xml</gft:includeFlat>)
      allows null values to be encoded. default is not encoded.\${property}!specify it either as an element value (<element>${property}!</element>) or as an xml attribute value (<element attribute:"${property}!"/>)

      A step by step introduction to features-templating syntax

      This introduction is meant to illustrate the different directives that can be used in a template. For clarity the documentation will start with a Simple Feature example and then progress through a Complex Feature example. However all the directives that will be shown are available for both Simple and Complex Features. GeoJSON and GML examples will be used mostly. For JSON-LD output format the rules to define a template are the same as the GeoJSON template with two exceptions:

        diff --git a/community/features-templating/index.html b/community/features-templating/index.html index 08cc297554a..a279d358df2 100644 --- a/community/features-templating/index.html +++ b/community/features-templating/index.html @@ -3862,12 +3862,32 @@

        Features-Templating Extension

        The Features Templating plug-in works by allowing us to define a What You See Is What You Get template, that will be applied on a stream of features respecting the defined content negotiation rules. Both Simple and Complex features are supported. The following services and operations are supported:

        -
        -

        Service Operation

        -

        WFS GetFeature

        -

        WMS GetFeatureInfo

        -

        OGCAPI Features Collection

        -
        + + + + + + + + + + + + + + + + + + + + + + + + + +
        ServiceOperation
        WFSGetFeature
        WMSGetFeatureInfo
        OGCAPI FeaturesCollection

        The following output formats are supported:

        • GeoJSON
        • diff --git a/community/hana/index.html b/community/hana/index.html index c8d58f51fb4..861cc920bad 100644 --- a/community/hana/index.html +++ b/community/hana/index.html @@ -3936,16 +3936,48 @@

          Configuring a SAP HANA data store

          Configuring a SAP HANA data store

          The following options are relevant for SAP HANA:

          -
          -

          host The machine name or IP address to connect to.

          -

          port The port to connect to. If set and different from 0, the parameters instance and database are ignored. If not set or 0, the instance parameter must be set.

          -

          instance The instance to connect to. This parameter is ignored if a port is set. The instance field is at the bottom of the configuration form in case you have difficulties locating it.

          -

          database The database to connect to. Leave empty in case of single-container databases. Set to SYSTEMDB to connect to the system database of a multi-container database. This parameter is ignored if a port is set.

          -

          schema The database schema to access. If left blank, the user-specific database schema is accessed.

          -

          user The database user used to connect to the database.

          -

          passwd The password used to connect to the database.

          -

          use ssl If checked the TLS/SSL cryptographic protocol is used to establish a secure connection with the database.

          -
          + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
          hostThe machine name or IP address to connect to.
          portThe port to connect to. If set and different from 0, the parameters instance and database are ignored. If not set or 0, the instance parameter must be set.
          instanceThe instance to connect to. This parameter is ignored if a port is set. The instance field is at the bottom of the configuration form in case you have difficulties locating it.
          databaseThe database to connect to. Leave empty in case of single-container databases. Set to SYSTEMDB to connect to the system database of a multi-container database. This parameter is ignored if a port is set.
          schemaThe database schema to access. If left blank, the user-specific database schema is accessed.
          userThe database user used to connect to the database.
          passwdThe password used to connect to the database.
          use sslIf checked the TLS/SSL cryptographic protocol is used to establish a secure connection with the database.
          diff --git a/community/mbtiles/input/index.html b/community/mbtiles/input/index.html index c6bf8af3a6c..472469cd8a7 100644 --- a/community/mbtiles/input/index.html +++ b/community/mbtiles/input/index.html @@ -3909,26 +3909,72 @@

          Adding an MBTiles Mosaic Ra MBTiles in the list of raster data sources

          Configuring an MBTiles data source

          -
          -

          Option Description

          -

          Workspace Name of the workspace to contain the MBTiles Mosaic store. This will also be the prefix of the raster layers created from the store.

          -

          Data Source Name Name of the MBTiles Store as it will be known to GeoServer. This can be different from the filename.

          -

          Description A full free-form description of the MBTiles store.

          -

          Enabled If checked, it enables the store. If unchecked (disabled), no data in the GeoPackage Mosaic Store will be served from GeoServer.

          -

          URL Location of the MBTiles file. This can be an absolute path (such as file:C:\Data\landbase.mbtiles) or a path relative to GeoServer's data directory (such as file:data/landbase.mbtiles).

          -
          + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
          OptionDescription
          WorkspaceName of the workspace to contain the MBTiles Mosaic store. This will also be the prefix of the raster layers created from the store.
          Data Source NameName of the MBTiles Store as it will be known to GeoServer. This can be different from the filename.
          DescriptionA full free-form description of the MBTiles store.
          EnabledIf checked, it enables the store. If unchecked (disabled), no data in the GeoPackage Mosaic Store will be served from GeoServer.
          URLLocation of the MBTiles file. This can be an absolute path (such as file:C:\Data\landbase.mbtiles) or a path relative to GeoServer's data directory (such as file:data/landbase.mbtiles).

          Adding an MBTiles vector tiles Data Store

          When the extension has been installed, MBTiles with vector tiles will be an option in the Vector Data Sources list when creating a new data store.

          MBTiles in the list of vector data sources

          Configuring an MBTiles data store

          -
          -

          Option Description

          -

          database Path to the MBTiles file

          -

          user Optional username

          -

          passwd Optional password

          -
          + + + + + + + + + + + + + + + + + + + + + + + + + +
          OptionDescription
          databasePath to the MBTiles file
          userOptional username
          passwdOptional password

          After configuration the store will allow setting up the layers, as they get described in the json entry of the metadata table.

          Configuring layers out of a MBTiles store

          diff --git a/community/ncwms/index.html b/community/ncwms/index.html index a9fd8763cdd..06dffa07584 100644 --- a/community/ncwms/index.html +++ b/community/ncwms/index.html @@ -4119,12 +4119,24 @@

          ncWMS GetTimeSeries operation

          ncWMS extension configuration

          The ncWMS extension adds a panel at the bottom of the WMS administration page:

          -
          -

          Option Description

          -
          -

          GetTimeSeries thread pool size Size of the thread pool used to compute GetTimeSeries results (parallelized to speed up computation)

          -

          Maximum number of times in GetTimeSeries Maximum number of times tha GetTimeSeries will process. A user asking for more times will get back a service exception. The configuration is set the first time the admin hits save in the WMS page, even with a value of 0 (from that point on, GetTimeSeries will be independent on the WMS max dimensions setting).

          -
          + + + + + + + + + + + + + + + + + +
          OptionDescription
          GetTimeSeries thread pool sizeSize of the thread pool used to compute GetTimeSeries results (parallelized to speed up computation)
          Maximum number of times in GetTimeSeriesMaximum number of times tha GetTimeSeries will process. A user asking for more times will get back a service exception. The configuration is set the first time the admin hits save in the WMS page, even with a value of 0 (from that point on, GetTimeSeries will be independent on the WMS max dimensions setting).
          diff --git a/community/ogc-api/coverages/index.html b/community/ogc-api/coverages/index.html index 7c32515e035..60d8523e82e 100644 --- a/community/ogc-api/coverages/index.html +++ b/community/ogc-api/coverages/index.html @@ -4041,11 +4041,22 @@

          OGC API - Coverages

        • CRS transformation

        OGC API - Coverages Implementation status

        -
        -

        OGC API - Coverages Version Implementation status

        -
        -

        Part 1: Core Draft Implementation based on early specification draft, not yet updated to final version

        -
        + + + + + + + + + + + + + + + +
        OGC API - CoveragesVersionImplementation status
        Part 1: CoreDraftImplementation based on early specification draft, not yet updated to final version

        Installing the GeoServer OGC API - Coverages module

        1. diff --git a/community/ogc-api/features/index.html b/community/ogc-api/features/index.html index 6e4fd076b24..2a27a571220 100644 --- a/community/ogc-api/features/index.html +++ b/community/ogc-api/features/index.html @@ -4178,16 +4178,47 @@

          OGC API - Features

          An OGC Features API publishing feature data using an OpenAPI web service.

          Features Implementation status

          -
          -

          OGC API - Features Version Implementation status

          -
          -

          Part 1: Core 1.0.0 Passes compliance tests

          -

          Part 2: Coordinate Systems by Reference 1.0.0 Passes compliance tests

          -

          Part 3: Filtering Draft Draft implemented (mind, the draft does not include a filtering language)

          -

          Part 4: Create, Replace, Update and Delete Draft Not implemented (volunteers/sponsoring wanted)

          -

          Common Query Language (CQL2) Draft Implements an earlier draft for for both text and JSON encodings. To be updated.

          -

          Part n: Query by IDs Proposal Proposal implemented, but syntax and semantic is subject to change in a future release. Thus said, usage should be carefully considered.

          -
          + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
          OGC API - FeaturesVersionImplementation status
          Part 1: Core1.0.0Passes compliance tests
          Part 2: Coordinate Systems by Reference1.0.0Passes compliance tests
          Part 3: FilteringDraftDraft implemented (mind, the draft does not include a filtering language)
          Part 4: Create, Replace, Update and DeleteDraftNot implemented (volunteers/sponsoring wanted)
          Common Query Language (CQL2)DraftImplements an earlier draft for for both text and JSON encodings. To be updated.
          Part n: Query by IDsProposalProposal implemented, but syntax and semantic is subject to change in a future release. Thus said, usage should be carefully considered.

          Installing the GeoServer OGC API Features module

          1. diff --git a/community/ogc-api/maps/index.html b/community/ogc-api/maps/index.html index d260664c82c..aeda67f34cf 100644 --- a/community/ogc-api/maps/index.html +++ b/community/ogc-api/maps/index.html @@ -4040,12 +4040,27 @@

            OGC API - Maps

          2. HTML representation of a map with OpenLayers is only partially functional

      OGC API - Maps Implementation status

      -
      -

      OGC API - Maps Version Implementation status

      -
      -

      Part 1: Core Draft Implementation based on early specification draft.

      -

      Part 2: Partitioning Draft Implementation based on early specification draft.

      -
      + + + + + + + + + + + + + + + + + + + + +
      OGC API - MapsVersionImplementation status
      Part 1: CoreDraftImplementation based on early specification draft.
      Part 2: PartitioningDraftImplementation based on early specification draft.

      Installing the GeoServer OGC API - Maps module

      1. diff --git a/community/ogc-api/styles/index.html b/community/ogc-api/styles/index.html index 94678f3cc7e..0b9f451653c 100644 --- a/community/ogc-api/styles/index.html +++ b/community/ogc-api/styles/index.html @@ -4029,11 +4029,22 @@

        OGC API - Styles

        A OGC Styles API based on the early draft of this specification.

        This service describes, retrieves and updates the styles present on the server. Styles are cross linked with their associated collections in both the Features and Tiles API.

        OGC API - Styles Implementation status

        -
        -

        OGC API - Styles Version Implementation status

        -
        -

        Part 1: Core Draft Implementation based on early specification draft.

        -
        + + + + + + + + + + + + + + + +
        OGC API - StylesVersionImplementation status
        Part 1: CoreDraftImplementation based on early specification draft.

        Installing the GeoServer OGC API - Styles module

        1. diff --git a/community/ogc-api/tiles/index.html b/community/ogc-api/tiles/index.html index 643b3afef87..67f60a557a3 100644 --- a/community/ogc-api/tiles/index.html +++ b/community/ogc-api/tiles/index.html @@ -4029,11 +4029,22 @@

          OGC API - Tiles

          A OGC Tiles API delivering both tiled data (vector tiles) and tiled maps (classic map tiles).

          GeoServer implementation is based on an ealier specification draft (the specification is now finalized).

          OGC API - Tiles Implementation status

          -
          -

          OGC API - Tiles Version Implementation status

          -
          -

          Part 1: Core Draft Implementation based on early specification draft, not yet updated to final version

          -
          + + + + + + + + + + + + + + + +
          OGC API - TilesVersionImplementation status
          Part 1: CoreDraftImplementation based on early specification draft, not yet updated to final version

          Installing the GeoServer OGC API - Tiles module

          1. diff --git a/community/opensearch-eo/automation/index.html b/community/opensearch-eo/automation/index.html index 82c0190728f..c5a46c264d4 100644 --- a/community/opensearch-eo/automation/index.html +++ b/community/opensearch-eo/automation/index.html @@ -4100,25 +4100,72 @@

            Understanding the zip file uploadsThe description of a collection and product is normally made of various components, in order to expedite data creation and reduce protocol chattines, it is possible to bulk-upload all files composing the description of collections and products as a single zip file.

            Collection components

            A collection.zip, sent as a PUT request to rest/collections would contain the following files:

            -
            -

            Name Optional Description

            -
            -

            collection.json N The collection attributes, matching the database structure (the prefixes are separated with a colon in this document)

            -

            description.html Y The HTML description for the collection

            -

            thumbnail.png, thumbnail.jpg or thumbnail.jpeg Y The collection thumbnail

            -

            owsLinks.json Y The list of OWS links to OGC services providing access to the collection contents (typically as a time enabled layer)

            -
            + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
            NameOptionalDescription
            collection.jsonNThe collection attributes, matching the database structure (the prefixes are separated with a colon in this document)
            description.htmlYThe HTML description for the collection
            thumbnail.png, thumbnail.jpg or thumbnail.jpegYThe collection thumbnail
            owsLinks.jsonYThe list of OWS links to OGC services providing access to the collection contents (typically as a time enabled layer)

            Product components

            A product.zip, sent as a POST request to rest/collections/<theCollection>/products would contain the following files:

            - + + + - + + + + + + + + + + + + + + + + + + + + + + +
            NameOptionalDescription
            product.jsonNThe product attributes, matching the database structure (the prefixes are separated with a colon in this JSON document)
            description.htmlYThe HTML description for the product
            thumbnail.png, thumbnail.jpg or thumbnail.jpegYThe collection thumbnail
            owsLinks.jsonYThe list of OWS links to OGC services providing access to the product contents (typically, a specific time slice in the collection layer, but other organizations are possible too)
            granules.jsonYThe list of actual files making up the product, along with their bounding boxes, file location and eventual band name, for products splitting bands in different files. Could be a single file, a list of files split by area, or a list of files representing the various bands of a multispectral product.
            @@ -4141,12 +4188,46 @@

            Usage - + + - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
            AttributeDescription
            workspaceThe workspace that will contain the store and layer to be published
            layerThe name of the layer that will be created
            separateBandsA boolean value, true if the underlying granule table has the "band" column populated with values, meaning the product bands are split among different files, false if a single product is stored in a single file
            heterogeneousCRSA boolean value, indicating if the products in the collection share the same CRS (false) or are expressed in different CRSses (true)
            timeRangesA boolean value, indicating if the products are associated to a single time (false) or have have a time range of validity (true)
            bandsThe list of bands used in this layer (to be specified only if "separateBands" is used)
            browseBandsAn array of 1 or 3 band names used to create the default display for the layer
            mosaicCRSThe identifier of the CRS used by the mosaic (must match the granules table one)
            defaultLayerA flag indicating if the layer is considered the default one for the collection (thus also appearing at /oseo/collection/{COLLECTION}/layer
            @@ -4202,14 +4283,32 @@

            Usage

            COG Mosaic creation

            It's also possible to configure a layer on top of a COG ImageMosaic, provided that the COG (Cloud Optimized GeoTIFF) Support plugin has been installed in GeoServer.

            Additional fields for the layer configuration are:

            -
            -

            Attribute Description

            -
            -

            cog Set it to true to specify the layer is made of COG datasets

            -

            cogUser (Optional) Credential to be set whenever basic HTTP authentication is needed to access the COG Datasets or an S3 Access KeyID is required

            -

            cogPassword (Optional) Password for the above user OR Secret Access Key for the above S3 KeyId.

            -

            cogRangeReader (Optional) Specify the desired RangeReader implementation. (default is HTTP based)

            -
            + + + + + + + + + + + + + + + + + + + + + + + + + +
            AttributeDescription
            cogSet it to true to specify the layer is made of COG datasets
            cogUser(Optional) Credential to be set whenever basic HTTP authentication is needed to access the COG Datasets or an S3 Access KeyID is required
            cogPassword(Optional) Password for the above user OR Secret Access Key for the above S3 KeyId.
            cogRangeReader(Optional) Specify the desired RangeReader implementation. (default is HTTP based)

            See COG RangeReader from the COG plugin documentation, for the list of supported RangeReader implementations.

            diff --git a/community/opensearch-eo/configuration/index.html b/community/opensearch-eo/configuration/index.html index f7567986f37..1144c5d99cf 100644 --- a/community/opensearch-eo/configuration/index.html +++ b/community/opensearch-eo/configuration/index.html @@ -4075,17 +4075,60 @@

            Advanced: adding product classes

            The design of the OpenSearch module is "data driven", meaning that one can materialize new search properties by just adding new columns to the product and collection tables.

            In particular, both tables have a "prefix based" convention linking the properties to their respective product types, and the engine will advertise for a particular product only the properties relevant to it. For example, in an optical product, the properties starting with "opt" will be listed, but not those starting with "sar".

            Here is a table of the product classes known out of the box:

            -
            -

            Name Prefix Namespace Description

            -
            -

            eop_generic eop http://www.opengis.net/eop/2.1 Base properties shared among all EO products. Never remove this class.

            -

            optical opt http://www.opengis.net/opt/2.1 Optical products properties

            -

            radar sar http://www.opengis.net/sar/2.1 Radar products properties

            -

            Altimetric alt http://www.opengis.net/alt/2.1 Altimetric products properties

            -

            Atmospheric atm http://www.opengis.net/atm/2.1 Atmospheric products properties

            -

            Limb lmb http://www.opengis.net/lmb/2.1 Limb products properties

            -

            ssp ssp http://www.opengis.net/ssp/2.1 SSP products properties

            -
            + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
            NamePrefixNamespaceDescription
            eop_genericeophttp://www.opengis.net/eop/2.1Base properties shared among all EO products. Never remove this class.
            opticalopthttp://www.opengis.net/opt/2.1Optical products properties
            radarsarhttp://www.opengis.net/sar/2.1Radar products properties
            Altimetricalthttp://www.opengis.net/alt/2.1Altimetric products properties
            Atmosphericatmhttp://www.opengis.net/atm/2.1Atmospheric products properties
            Limblmbhttp://www.opengis.net/lmb/2.1Limb products properties
            sspssphttp://www.opengis.net/ssp/2.1SSP products properties

            The various properties have different usages:

            • The name is used in the collection to define the type of sensor (eoSensorType column)
            • diff --git a/community/pgraster/pgraster/index.html b/community/pgraster/pgraster/index.html index 8efb78360ae..86328952702 100644 --- a/community/pgraster/pgraster/index.html +++ b/community/pgraster/pgraster/index.html @@ -3871,20 +3871,56 @@

              Usage

          -
          -

          Name Description

          -
          -

          PostGIS server The PostGIS server IP

          -

          PostGIS port The PostGIS server port

          -

          User The PostGIS DB user

          -

          Password The PostGIS DB password

          -

          Database The PostGIS Database (should have already been created)

          -

          Schema The schema where the table will be created (default is public. The schema need to be already defined into the Database before the import)

          -

          Table The name of the metadata table which contains all the references to

          -

          File extension The extension of the raster files to be imported (such as png). It may not be specified when raster tiles have been already manually imported into the database by the user

          -

          raster2pgsql import options The raster2pgsql script importing options (as an instance "-t 128x128" for raster tiles of 128x128). It may not be specified when raster tiles have been already manually imported into the database by the user

          -

          EPSG Code The EPSG code which will be configured in the coverage configuration xml. (Default is 4326)

          -
          + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
          NameDescription
          PostGIS serverThe PostGIS server IP
          PostGIS portThe PostGIS server port
          UserThe PostGIS DB user
          PasswordThe PostGIS DB password
          DatabaseThe PostGIS Database (should have already been created)
          SchemaThe schema where the table will be created (default is public. The schema need to be already defined into the Database before the import)
          TableThe name of the metadata table which contains all the references to
          File extensionThe extension of the raster files to be imported (such as png). It may not be specified when raster tiles have been already manually imported into the database by the user
          raster2pgsql import optionsThe raster2pgsql script importing options (as an instance "-t 128x128" for raster tiles of 128x128). It may not be specified when raster tiles have been already manually imported into the database by the user
          EPSG CodeThe EPSG code which will be configured in the coverage configuration xml. (Default is 4326)

          Limitations

          Right now it doesn't allow to import data folders which have been created with the gdal_retile's useDirForEachRow option.

          diff --git a/community/proxy-base-ext/usage/index.html b/community/proxy-base-ext/usage/index.html index 13ba6f312b0..b3b80b1eb2f 100644 --- a/community/proxy-base-ext/usage/index.html +++ b/community/proxy-base-ext/usage/index.html @@ -3904,12 +3904,32 @@

          Using the Proxy Base Extension mo

          Proxy Base Extension Rules

          Proxy Base Extension rules allow the matching of the URLs for alteration based on their path elements and followed by the specification a replacement for the entire URL.

          A Proxy Base Extension rule is defined by three mandatory attributes:

          -
          -

          Attribute Description

          -

          Position The priority of the rule, the lower the number the higher the priority. Rules are applied on a first match basis.

          -

          Matcher The pattern used to match against paths. Regular expressions can be used to achieve matches.

          -

          Transformer The transformation that will be applied to the entire URL. Literal expressions can be used to achieve transformations based on matching header values.

          -
          + + + + + + + + + + + + + + + + + + + + + + + + + +
          AttributeDescription
          PositionThe priority of the rule, the lower the number the higher the priority. Rules are applied on a first match basis.
          MatcherThe pattern used to match against paths. Regular expressions can be used to achieve matches.
          TransformerThe transformation that will be applied to the entire URL. Literal expressions can be used to achieve transformations based on matching header values.

          The following example shows a rule that will match any URL contains the substring wfs in the path (the example matcher value is .*/wfs) and replace the full URL (the example transformer value is https://wfs.eastern.com/${myCollection}/${yourFeature}) with https://wfs.eastern.com/ABigCollection/AnImportantFeature if the myCollection header is set to ABigCollection and the yourFeature header is set to AnImportantFeature. Note that if one or more of the headers referenced in the transformer by literal expressions are not present the rule will not be applied.

          Example of a Proxy Base Extension rule:

          @@ -3924,17 +3944,52 @@

          Rules Management

          Rules can be managed and tested with simulated headers in the rules management UI. Besides the basic operations like add, remove and update is also possible to activate or deactivate rules. A deactivated rule will be ignored by this module.

          Rules management UI

          -
          -

          Attribute Description

          -

          Position The priority of the rule, the lower the number the higher the priority. Rules are applied on a first match basis.

          -

          Matcher The pattern used to match against paths. Regular expressions can be used to achieve matches.

          -

          Transformer The transformation that will be applied to the entire URL. Literal expressions can be used to achieve transformations based on matching header values.

          -

          Active When this box is checked, the rule will be applied.

          -

          Edit Click to launch an editor for this specific rule.

          -

          Input The input URL to be tested against the rules listed above.

          -

          Headers If the rule to be tested has literal expressions, simulated headers for the test can be entered here in Properties File Format (equal sign separated, with each header on a new line).

          -

          Output The result of applying the rules to the input URL will be displayed here after the Test button is clicked.

          -
          + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
          AttributeDescription
          PositionThe priority of the rule, the lower the number the higher the priority. Rules are applied on a first match basis.
          MatcherThe pattern used to match against paths. Regular expressions can be used to achieve matches.
          TransformerThe transformation that will be applied to the entire URL. Literal expressions can be used to achieve transformations based on matching header values.
          ActiveWhen this box is checked, the rule will be applied.
          EditClick to launch an editor for this specific rule.
          InputThe input URL to be tested against the rules listed above.
          HeadersIf the rule to be tested has literal expressions, simulated headers for the test can be entered here in Properties File Format (equal sign separated, with each header on a new line).
          OutputThe result of applying the rules to the input URL will be displayed here after the Test button is clicked.

          REST API

          The rules can also be managed by means of a REST API found at geoserver/rest/proxy-base-ext. Documentation for it is available in Swagger format

          diff --git a/community/solr/configure/index.html b/community/solr/configure/index.html index 1c38e810f3a..97a5464fb9a 100644 --- a/community/solr/configure/index.html +++ b/community/solr/configure/index.html @@ -4005,9 +4005,20 @@

          Connecting to a SOLR server

          Configuring a SOLR data store

          Configuring a SOLR data store

          -
          -

          solr_url Provide a link to the SOLR server that provides the documents

          -
          + + + + + + + + + + + + + +
          solr_urlProvide a link to the SOLR server that provides the documents

          Once the parameters are entered and confirmed, GeoServer will contact the SOLR server and fetch a list of layer names and fill the layer chooser page accordingly:

          List of layers available in the SOLR server

          @@ -4015,15 +4026,44 @@

          Configuring a new SOLR base layer

          Once the layer name is chosen, the usual layer configuration panel will appear, with a pop-up showing in a table the fields available:

          The layer field list configuration

          -
          -

          Is empty Read only fields, checked if the field has no values in the documents associated to this layer

          -

          Use Used to select the fields that will make up this layer features

          -

          Name Name of the field

          -

          Type Type of the field, as derived from the SOLR schema. For geometry types, you have the option to provide a more specific data type

          -

          SRID Native spatial reference ID of the geometries

          -

          Default geometry Indicates if the geometry field is the default one. Useful if the documents contain more than one geometry field, as SLDs and spatial filters will hit the default geometry field unless otherwise specified

          -

          Identifier Check if the field can be used as the feature identifier

          -
          + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
          Is emptyRead only fields, checked if the field has no values in the documents associated to this layer
          UseUsed to select the fields that will make up this layer features
          NameName of the field
          TypeType of the field, as derived from the SOLR schema. For geometry types, you have the option to provide a more specific data type
          SRIDNative spatial reference ID of the geometries
          Default geometryIndicates if the geometry field is the default one. Useful if the documents contain more than one geometry field, as SLDs and spatial filters will hit the default geometry field unless otherwise specified
          IdentifierCheck if the field can be used as the feature identifier

          By default the list will contain only the fields that have at least one non null value in the documents associated to the layer, but it is possible to get the full list by un-checking the "Hide field if empty" check-box:

          Showing all fields available in SOLR

          diff --git a/community/vector-mosaic/configuration/index.html b/community/vector-mosaic/configuration/index.html index 670d25871e2..dae34fb19db 100644 --- a/community/vector-mosaic/configuration/index.html +++ b/community/vector-mosaic/configuration/index.html @@ -3834,16 +3834,48 @@

          Vector Mosaic Datastore configura Vector Mosaic Data Store in the list of vector data sources

          Configuring an Vector Mosaic data source

          -
          -

          Option Description

          -

          Workspace Name of the workspace to contain the Vector Mosaic store.

          -

          Data Source Name Name of the Vector Mosaic Store as it will be known to GeoServer.

          -

          Description A full free-form description of the Vector Mosaic store.

          -

          Enabled If checked, it enables the store. If unchecked (disabled), no data in the Vector Mosaic Store will be served from GeoServer.

          -

          delegateStoreName The data source name of the data store previously created that holds the index information about the constituent vector granules. See here for more details about delegate store requirements.

          -

          connectionParameterKey The delegate store has a mandatory field called "params". Params can either be a URI pointing at the granule resource location or it can be a configuration string in .properties format. (See Java Properties file for more details about the format) In the latter case this optional parameter specifies which key points at the location of the granule. Accepted values are "file" and "url".

          -

          preferredDataStoreSPI This optional parameter can serve as an optimization to speed up the lookup of granule data stores. Instead of attempting to use the mandatory delegate params field (See delegate requirements for more details about delegate store requirements.) to look up supported data store types, the Vector Mosaic data store will use the data store SPI specified in this field to identify the correct type.

          -
          + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
          OptionDescription
          WorkspaceName of the workspace to contain the Vector Mosaic store.
          Data Source NameName of the Vector Mosaic Store as it will be known to GeoServer.
          DescriptionA full free-form description of the Vector Mosaic store.
          EnabledIf checked, it enables the store. If unchecked (disabled), no data in the Vector Mosaic Store will be served from GeoServer.
          delegateStoreNameThe data source name of the data store previously created that holds the index information about the constituent vector granules. See here for more details about delegate store requirements.
          connectionParameterKeyThe delegate store has a mandatory field called "params". Params can either be a URI pointing at the granule resource location or it can be a configuration string in .properties format. (See Java Properties file for more details about the format) In the latter case this optional parameter specifies which key points at the location of the granule. Accepted values are "file" and "url".
          preferredDataStoreSPIThis optional parameter can serve as an optimization to speed up the lookup of granule data stores. Instead of attempting to use the mandatory delegate params field (See delegate requirements for more details about delegate store requirements.) to look up supported data store types, the Vector Mosaic data store will use the data store SPI specified in this field to identify the correct type.
          diff --git a/configuration/contact/index.html b/configuration/contact/index.html index c8c7fe28661..28880fcdf63 100644 --- a/configuration/contact/index.html +++ b/configuration/contact/index.html @@ -1753,42 +1753,99 @@

          Organization

          Contact Information Organization

          The welcome message is displayed in the welcome page header as an introduction to the GeoServer web services. The organization name and online resource, if provided, are used in the welcome page header for the For more information visit link.

          Contact information fields:

          -
          -

          Field Description

          -
          -

          Organization Name of the organization with which the contact is affiliated

          -

          Online Resource Website for organization

          -

          Welcome Introduction displayed on the welcome page

          -
          + + + + + + + + + + + + + + + + + + + + + +
          FieldDescription
          OrganizationName of the organization with which the contact is affiliated
          Online ResourceWebsite for organization
          WelcomeIntroduction displayed on the welcome page

          Primary contact

          Complete this form with the relevant contact information.

          Contact Information Primary Contact

          The email address, if provided, is used to provide a Contact administrator link for the welcome page footer.

          Contact information fields:

          -
          -

          Field Description

          -
          -

          Contact Contact information for webmaster

          -

          Position Position of the contact within their organization

          -

          Email Contact email address

          -

          Telephone Contact phone number

          -

          Fax Contact Fax number

          -
          + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
          FieldDescription
          ContactContact information for webmaster
          PositionPosition of the contact within their organization
          EmailContact email address
          TelephoneContact phone number
          FaxContact Fax number

          Address

          Complete this form with the relevant physical address information.

          Contact Information Address

          Address information fields:

          -
          -

          Address Type Type of address specified, such as postal

          -
          -

          Address Actual street address

          -

          City City of the address

          -

          State State or province of the address

          -

          Zip code Postal code for the address

          -

          Country Country of the address

          -
          + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
          Address TypeType of address specified, such as postal
          AddressActual street address
          CityCity of the address
          StateState or province of the address
          Zip codePostal code for the address
          CountryCountry of the address
          diff --git a/configuration/service-metadata/index.html b/configuration/service-metadata/index.html index f8d0d299003..4559c2e244c 100644 --- a/configuration/service-metadata/index.html +++ b/configuration/service-metadata/index.html @@ -1657,19 +1657,52 @@

          Service Metadata

          WMS Service Metadata

          These elements are described in the following table. Though these field types are the same regardless of service, their values are not shared. As such, parameter definitions below refer to the respective service. For example, enable on the WFS Service page, enables WFS service requests and has no effect on WCS or WMS requests.

          -
          -

          Field Description

          -
          -

          Enabled Specifies whether the respective services --WCS, WFS or WMS-- should be enabled or disabled. When disabled, the respective service requests will not be processed.

          -

          Strict CITE compliance When selected, enforces strict OGC Compliance and Interoperability Testing Initiative (CITE) conformance. Recommended for use when running conformance tests.

          -

          Maintainer Name of the responsible party (organization, company, or person) that maintains the service instance.

          -

          Online Resource Defines the top-level HTTP URL of the service. Typically the Online Resource is the URL of the service "home page." (Required)

          -

          Title A human-readable title to briefly identify this service in menus to clients. (Required)

          -

          Abstract Provides a descriptive narrative with more information about the service.

          -

          Fees Indicates any fees imposed by the service provider for usage of the service. The keyword NONE is reserved to mean no fees and fits most cases.

          -

          Access Constraints Describes any constraints imposed by the service provider on the service. The keyword NONE is reserved to indicate no access constraints are imposed and fits most cases.

          -

          Keywords List of terms that are associated with the service to aid in cataloging and searching.

          -
          + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
          FieldDescription
          EnabledSpecifies whether the respective services --WCS, WFS or WMS-- should be enabled or disabled. When disabled, the respective service requests will not be processed.
          Strict CITE complianceWhen selected, enforces strict OGC Compliance and Interoperability Testing Initiative (CITE) conformance. Recommended for use when running conformance tests.
          MaintainerName of the responsible party (organization, company, or person) that maintains the service instance.
          Online ResourceDefines the top-level HTTP URL of the service. Typically the Online Resource is the URL of the service "home page." (Required)
          TitleA human-readable title to briefly identify this service in menus to clients. (Required)
          AbstractProvides a descriptive narrative with more information about the service.
          FeesIndicates any fees imposed by the service provider for usage of the service. The keyword NONE is reserved to mean no fees and fits most cases.
          Access ConstraintsDescribes any constraints imposed by the service provider on the service. The keyword NONE is reserved to indicate no access constraints are imposed and fits most cases.
          KeywordsList of terms that are associated with the service to aid in cataloging and searching.
          diff --git a/configuration/status/index.html b/configuration/status/index.html index 6bc41a5ecc1..4e472e55817 100644 --- a/configuration/status/index.html +++ b/configuration/status/index.html @@ -1917,39 +1917,172 @@

          System Status

          This information is also available via the REST API to troubleshoot remote systems. The library OSHI is used to retrieve system-level information without depending on native libraries or DLLs, relying solely on Apache JNA. Major operating systems (Linux, Windows and MacOS) are supported out of the box.

          Use the checkbox Enable All Statistics to start and stop the collecting and displaying system status information. Disabling is useful if GeoServer is generating a high CPU load due to system status collection.

          The available system information is:

          -
          -

          Info Example Description

          -

          Operating system Linux Mint 18 Name of the operating system and the used version

          -

          Uptime 08:34:50 Up time of the system

          -

          System average load 1 minute 0.90 System average load for the last minute

          -

          System average load 5 minutes 1.12 System average load for the last five minute

          -

          System average load 15 minute 0.68 System average load for the last fifteen minute

          -

          Number of physical CPUs 4 Number of physical CPUs / cores available

          -

          Number of logical CPUs 8 Number of logical CPUs / cores available

          -

          Number of running process 316 Total number of process running in the system

          -

          Number of running threads 1094 Total number of threads running in the system

          -

          CPU load average 4.12 % Average load of the CPU in the last second

          -

          CPU * load 11.43 % Load of a specific core in the last second

          -

          Used physical memory 31.58 % Percentage of the system memory used

          -

          Total physical memory 31.4 GiB System total memory

          -

          Free physical memory 21.4 GiB System memory available for use

          -

          Used swap memory 0.00% Percentage of swap memory used

          -

          Total swap memory 32.0 GiB System total swap memory

          -

          Free swap memory 32.0 GiB Free swap memory

          -

          File system usage 65.47 % File system usage taking in account all partitions

          -

          Partition * used space 54.8 % Percentage of space used in a specific partition

          -

          Partition * total space 338.9 GiB Total space of a specific partition

          -

          Partition * free space 117.0 GiB Free space on a specific partition

          -

          Network interfaces send 42.0 MiB Data send through all the available network interfaces

          -

          Network interfaces received 700.4 MiB Data received through all the available network interfaces

          -

          Network interface * send 25.0 MiB Data send through a specific network interface

          -

          Network interface * received 250.4 MiB Data received through a specific network interface

          -

          CPU temperature 52.00 ºC CPU temperature

          -

          CPU voltage 1.5 V CPU voltage

          -

          GeoServer CPU usage 3.5 % Percentage of CPU used by GeoServer in the last second

          -

          GeoServer threads 49 Number of threads created by GeoServer

          -

          GeoServer JVM memory usage 5.83 % Percentage of the JVM memory used by GeoServer

          -
          + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
          InfoExampleDescription
          Operating systemLinux Mint 18Name of the operating system and the used version
          Uptime08:34:50Up time of the system
          System average load 1 minute0.90System average load for the last minute
          System average load 5 minutes1.12System average load for the last five minute
          System average load 15 minute0.68System average load for the last fifteen minute
          Number of physical CPUs4Number of physical CPUs / cores available
          Number of logical CPUs8Number of logical CPUs / cores available
          Number of running process316Total number of process running in the system
          Number of running threads1094Total number of threads running in the system
          CPU load average4.12 %Average load of the CPU in the last second
          CPU * load11.43 %Load of a specific core in the last second
          Used physical memory31.58 %Percentage of the system memory used
          Total physical memory31.4 GiBSystem total memory
          Free physical memory21.4 GiBSystem memory available for use
          Used swap memory0.00%Percentage of swap memory used
          Total swap memory32.0 GiBSystem total swap memory
          Free swap memory32.0 GiBFree swap memory
          File system usage65.47 %File system usage taking in account all partitions
          Partition * used space54.8 %Percentage of space used in a specific partition
          Partition * total space338.9 GiBTotal space of a specific partition
          Partition * free space117.0 GiBFree space on a specific partition
          Network interfaces send42.0 MiBData send through all the available network interfaces
          Network interfaces received700.4 MiBData received through all the available network interfaces
          Network interface * send25.0 MiBData send through a specific network interface
          Network interface * received250.4 MiBData received through a specific network interface
          CPU temperature52.00 ºCCPU temperature
          CPU voltage1.5 VCPU voltage
          GeoServer CPU usage3.5 %Percentage of CPU used by GeoServer in the last second
          GeoServer threads49Number of threads created by GeoServer
          GeoServer JVM memory usage5.83 %Percentage of the JVM memory used by GeoServer

          If some information is not available the special term NOT AVAILABLE will appear. Values will be automatically converted to best human readable unit.

          JVM Console

          For information on the live Java Runtime Environment the JVM Console tab provides access to two useful troubleshooting tools.

          diff --git a/data/app-schema/feature-chaining/index.html b/data/app-schema/feature-chaining/index.html index 64a09f17d26..7a4d8022394 100644 --- a/data/app-schema/feature-chaining/index.html +++ b/data/app-schema/feature-chaining/index.html @@ -2443,26 +2443,127 @@

          Configure nesting on the n

      The ENVIRONMENT_OWNER column in CGI_TermValue view corresponds to the ID column in GeologicEvent view.

      Geologic Event property file:

      -
      -

      id GEOLOGIC_UNIT_ID:String ghminage:String ghmaxage:String ghage_cdspace:String

      -

      ge.26931120 gu.25699 Oligocene Paleocene

      -

      ge.26930473 gu.25678 Holocene Pleistocene

      -

      ge.26930960 gu.25678 Pliocene Miocene

      -

      ge.26932959 gu.25678 LowerOrdovician LowerOrdovician

      -
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      idGEOLOGIC_UNIT_ID:Stringghminage:Stringghmaxage:Stringghage_cdspace:String
      ge.26931120gu.25699OligocenePaleocene
      ge.26930473gu.25678HolocenePleistocene
      ge.26930960gu.25678PlioceneMiocene
      ge.26932959gu.25678LowerOrdovicianLowerOrdovician

      CGI Term Value property file:

      -
      -

      id VALUE:String PROCESS_OWNER:String ENVIRONMENT_OWNER:String

      -

      3 fluvial NULL ge.26931120

      -

      4 swamp/marsh/bog NULL ge.26930473

      -

      5 marine NULL ge.26930960

      -

      6 submarine fan NULL ge.26932959

      -

      7 hemipelagic NULL ge.26932959

      -

      8 detrital deposition still water ge.26930473 NULL

      -

      9 water [process] ge.26932959 NULL

      -

      10 channelled stream flow ge.26931120 NULL

      -

      11 turbidity current ge.26932959 NULL

      -
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      idVALUE:StringPROCESS_OWNER:StringENVIRONMENT_OWNER:String
      3fluvialNULLge.26931120
      4swamp/marsh/bogNULLge.26930473
      5marineNULLge.26930960
      6submarine fanNULLge.26932959
      7hemipelagicNULLge.26932959
      8detrital deposition still waterge.26930473NULL
      9water [process]ge.26932959NULL
      10channelled stream flowge.26931120NULL
      11turbidity currentge.26932959NULL

      The system field FEATURE_LINK doesn't get encoded in the output:

      <gsml:GeologicEvent>                      
         <gml:name codeSpace="urn:cgi:classifierScheme:GSV:GeologicalUnitId">gu.25699</gml:name>
      @@ -2593,18 +2694,73 @@ 

      Configure nesting on t
    • linkField: FEATURE_LINK, the linking field mapped in gsml:CompositionPart type that also stores the geologic unit id. If there are more than one of these attributes in the nested feature type, make sure the index is included, e.g. FEATURE_LINK[2].

    Geologic Unit property file:

    -
    -

    id ABBREVIATAION:String NAME:String TEXTDESCRIPTION:String

    -

    gu.25699 -Py Yaugher Volcanic Group Olivine basalt, tuff, microgabbro, minor sedimentary rocks

    -

    gu.25678 -Py Yaugher Volcanic Group Olivine basalt, tuff, microgabbro, minor sedimentary rocks

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    idABBREVIATAION:StringNAME:StringTEXTDESCRIPTION:String
    gu.25699-PyYaugher Volcanic GroupOlivine basalt, tuff, microgabbro, minor sedimentary rocks
    gu.25678-PyYaugher Volcanic GroupOlivine basalt, tuff, microgabbro, minor sedimentary rocks

    Composition Part property file:

    -
    -

    id COMPONENT_ROLE:String PROPORTION:String GEOLOGIC_UNIT_ID:String

    -

    cp.167775491936278812 interbedded component significant gu.25699

    -

    cp.167775491936278856 interbedded component minor gu.25678

    -

    cp.167775491936278844 sole component major gu.25678

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    idCOMPONENT_ROLE:StringPROPORTION:StringGEOLOGIC_UNIT_ID:String
    cp.167775491936278812interbedded componentsignificantgu.25699
    cp.167775491936278856interbedded componentminorgu.25678
    cp.167775491936278844sole componentmajorgu.25678

    Run the getFeature request to test this configuration. Check that the nested features returned in Step 2 are appropriately lined inside the containing features. If they are not there, or exceptions are thrown, scroll down and read the "Trouble Shooting" section.

    Multiple mappings of the same type

    At times, you may find the need to have different FeatureTypeMapping instances for the same type. You may have two different attributes of the same type that need to be nested. For example, in gsml:GeologicUnit, you have gsml:exposureColor and gsml:outcropCharacter that are both of gsml:CGI_TermValue type.

    diff --git a/data/app-schema/mongo-tutorial/index.html b/data/app-schema/mongo-tutorial/index.html index 78101f82548..6cfe283d070 100644 --- a/data/app-schema/mongo-tutorial/index.html +++ b/data/app-schema/mongo-tutorial/index.html @@ -2491,13 +2491,42 @@

    MongoDB Store

    Both parameters can also be specified via the REST API, see Cleaning schemas on internal MongoDB stores for more details.

    Nested elements

    MongoDB objects may contain nested elements and nested collections. The following three functions make possible to select nested elements and link nested collections using a JSON path:

    -
    -

    Function Example Description

    -

    jsonSelect jsonSelect('contact.mail') Used to retrieve the value for the mapping from a MongoDB object.

    -

    collectionLink collectionLink('measurements.values') Used when chaining entities with a nested collection.

    -

    collectionId collectionId() Instructs the mapper to generate a ID for the nested collection.

    -

    nestedCollectionLink nestedCollectionLink() Used on the nested collection to create a link with the parent feature.

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    FunctionExampleDescription
    jsonSelectjsonSelect('contact.mail')Used to retrieve the value for the mapping from a MongoDB object.
    collectionLinkcollectionLink('measurements.values')Used when chaining entities with a nested collection.
    collectionIdcollectionId()Instructs the mapper to generate a ID for the nested collection.
    nestedCollectionLinknestedCollectionLink()Used on the nested collection to create a link with the parent feature.

    Mappings file example

    A station data is composed of some meta-information about the station and a list of measurements. Each measurement as some meta-information and contains a list of values. The mappings will contain three top entities: the station, the measurements and the values.

    Follows a the complete mappings file:

    diff --git a/data/cascaded/stored_query/index.html b/data/cascaded/stored_query/index.html index 1406f6362a2..fbdbe4f5d34 100644 --- a/data/cascaded/stored_query/index.html +++ b/data/cascaded/stored_query/index.html @@ -1908,24 +1908,70 @@

    Cascaded Web Feature Servic

    Cascaded stored query parameters

    The relationship between stored query parameters and the schema returned by the query is not well defined. For cascaded stored queries to work, the relationship between the query received by GeoServer and the parameters passed to the stored query must be defined.

    When you set up a layer based on a stored query, you have to select which stored query to cascade and what values are passed to each parameter. Cascaded stored queries can leverage view parameters passed to the query. This is similar to how arbitrary parameters are passed to SQL Views. GeoServer supports multiple strategies to pass these values. See below for a full list.

    -
    -

    Parameter type Explanation

    -

    No mapping The value of the view parameter will be passed as is to the stored query. No parameter will be passed if there is no view parameter of the same name.

    -

    Blocked This parameter will never be passed to the stored query

    -

    Default The specified value is used unless overwritten by a view parameter

    -

    Static The specified value is always used (view parameter value will be ignored)

    -

    CQL Expression An expression that will be evaluated on every request (see below for more details)

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Parameter typeExplanation
    No mappingThe value of the view parameter will be passed as is to the stored query. No parameter will be passed if there is no view parameter of the same name.
    BlockedThis parameter will never be passed to the stored query
    DefaultThe specified value is used unless overwritten by a view parameter
    StaticThe specified value is always used (view parameter value will be ignored)
    CQL ExpressionAn expression that will be evaluated on every request (see below for more details)

    See Using a parametric SQL View for more details how clients pass view parameters to GeoServer.

    CQL expressions

    Parameter mappings configured as CQL expressions are evaluated for each request using a context derived from the request query and the view parameters. General information on CQL expressions is available here Expression.

    The context contains the following properties that may be used in the expressions:

    -
    -

    Property name Explanation

    -

    bboxMinX bboxMinY bboxMaxX bboxMaxY Evaluates to a corner coordinate of the full extent of the query

    -

    defaultSRS Evaluates to the default SRS of the feature type

    -

    viewparam:name Evaluates to the value of the view parameter name in this query

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + +
    Property nameExplanation
    bboxMinX bboxMinY bboxMaxX bboxMaxYEvaluates to a corner coordinate of the full extent of the query
    defaultSRSEvaluates to the default SRS of the feature type
    viewparam:nameEvaluates to the value of the view parameter name in this query

    Configuring a cascaded stored query layer

    In order to create a cascaded stored query layer the administrator invokes the Create new layer page. When an External Web Feature Server is selected, the usual list of tables and views available for publication appears, a link Configure Cascaded Stored Query... also appears:

    diff --git a/data/cascaded/wfs/index.html b/data/cascaded/wfs/index.html index ed79b7378c5..af91e66344a 100644 --- a/data/cascaded/wfs/index.html +++ b/data/cascaded/wfs/index.html @@ -1908,29 +1908,100 @@

    Adding an external WFS

    To connect to an external WFS, it is necessary to load it as a new datastore. To start, navigate to Stores → Add a new store → Web Feature Server.

    Adding an external WFS as a store

    -
    -

    Option Description

    -

    Workspace Name of the workspace to contain the store. This will also be the prefix of all of the layer names created from the store.

    -

    Data Source Name Name of the store as known to GeoServer.

    -

    Description Description of the store.

    -

    Enabled Enables the store. If disabled, no data from the external WFS will be served.

    -

    GET_CAPABILITIES_URL URL to access the capabilities document of the remote WFS.

    -

    PROTOCOL When checked, connects with POST, otherwise uses GET.

    -

    USERNAME The user name to connect to the external WFS.

    -

    PASSWORD The password associated with the above user name.

    -

    ENCODING The character encoding of the XML requests sent to the server. Defaults to UTF-8.

    -

    TIMEOUT Time (in milliseconds) before timing out. Default is 3000.

    -

    BUFFER_SIZE Specifies a buffer size (in number of features). Default is 10 features.

    -

    TRY_GZIP Specifies that the server should transfer data using compressed HTTP if supported by the server.

    -

    LENIENT When checked, will try to render features that don't match the appropriate schema. Errors will be logged.

    -

    MAXFEATURES Maximum number of features to retrieve for each featuretype. Default is no limit.

    -

    AXIS_ORDER Axis order used in result coordinates (It applies only to WFS 1.x.0 servers). Default is Compliant.

    -

    AXIS_ORDER_FILTER Axis order used in filter (It applies only to WFS 1.x.0 servers). Default is Compliant.

    -

    OUTPUTFORMAT Output format to request (instead of the default remote service one) e.g. JSON.

    -

    GML_COMPLIANCE_LEVEL OCG GML compliance level. i.e. (simple feature) 0, 1 or 2. Default is 0.

    -

    GML_COMPATIBLE_TYPENAMES Use GML Compatible TypeNames (replace : by _). Default is no false.

    -

    USE_HTTP_CONNECTION_POOLING Use connection pooling to connect to the remote WFS service. Also enables digest authentication.

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    OptionDescription
    WorkspaceName of the workspace to contain the store. This will also be the prefix of all of the layer names created from the store.
    Data Source NameName of the store as known to GeoServer.
    DescriptionDescription of the store.
    EnabledEnables the store. If disabled, no data from the external WFS will be served.
    GET_CAPABILITIES_URLURL to access the capabilities document of the remote WFS.
    PROTOCOLWhen checked, connects with POST, otherwise uses GET.
    USERNAMEThe user name to connect to the external WFS.
    PASSWORDThe password associated with the above user name.
    ENCODINGThe character encoding of the XML requests sent to the server. Defaults to UTF-8.
    TIMEOUTTime (in milliseconds) before timing out. Default is 3000.
    BUFFER_SIZESpecifies a buffer size (in number of features). Default is 10 features.
    TRY_GZIPSpecifies that the server should transfer data using compressed HTTP if supported by the server.
    LENIENTWhen checked, will try to render features that don't match the appropriate schema. Errors will be logged.
    MAXFEATURESMaximum number of features to retrieve for each featuretype. Default is no limit.
    AXIS_ORDERAxis order used in result coordinates (It applies only to WFS 1.x.0 servers). Default is Compliant.
    AXIS_ORDER_FILTERAxis order used in filter (It applies only to WFS 1.x.0 servers). Default is Compliant.
    OUTPUTFORMATOutput format to request (instead of the default remote service one) e.g. JSON.
    GML_COMPLIANCE_LEVELOCG GML compliance level. i.e. (simple feature) 0, 1 or 2. Default is 0.
    GML_COMPATIBLE_TYPENAMESUse GML Compatible TypeNames (replace : by _). Default is no false.
    USE_HTTP_CONNECTION_POOLINGUse connection pooling to connect to the remote WFS service. Also enables digest authentication.

    When finished, click Save.

    Configuring external WFS layers

    When properly loaded, all layers served by the external WFS will be available to GeoServer. Before they can be served, however, they will need to be individually configured as new layers. See the section on Layers for how to add and edit new layers.

    diff --git a/data/cascaded/wms/index.html b/data/cascaded/wms/index.html index c820d797e02..c9d8eb0c402 100644 --- a/data/cascaded/wms/index.html +++ b/data/cascaded/wms/index.html @@ -1947,17 +1947,52 @@

    Adding an external WMS

    Adding an external WMS as a store

    Configuring a new external WMS store

    -
    -

    Option Description

    -

    Workspace Name of the workspace to contain the store. This will also be the prefix of all of the layer names published from the store. The workspace name on the remote WMS is not cascaded.

    -

    Data Source Name Name of the store as known to GeoServer.

    -

    Description Description of the store.

    -

    Enabled Enables the store. If disabled, no data from the remote WMS will be served.

    -

    Capabilities URL The URL to access the capabilities document of the remote WMS. If URL contains just server address "https://host.org/wms" the required WMS GetCapabilities query parameters will be added automatically. Alternatively URL can be a full URL to access the capabilities document "https://host.org/wms?service=WMS&version=1.1.1&request=GetCapabilities".

    -

    User Name If the WMS requires authentication, the user name to connect as.

    -

    Password If the WMS requires authentication, the password to connect with.

    -

    Max concurrent connections The maximum number of persistent connections to keep for this WMS.

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    OptionDescription
    WorkspaceName of the workspace to contain the store. This will also be the prefix of all of the layer names published from the store. The workspace name on the remote WMS is not cascaded.
    Data Source NameName of the store as known to GeoServer.
    DescriptionDescription of the store.
    EnabledEnables the store. If disabled, no data from the remote WMS will be served.
    Capabilities URLThe URL to access the capabilities document of the remote WMS. If URL contains just server address "https://host.org/wms" the required WMS GetCapabilities query parameters will be added automatically. Alternatively URL can be a full URL to access the capabilities document "https://host.org/wms?service=WMS&version=1.1.1&request=GetCapabilities".
    User NameIf the WMS requires authentication, the user name to connect as.
    PasswordIf the WMS requires authentication, the password to connect with.
    Max concurrent connectionsThe maximum number of persistent connections to keep for this WMS.

    When finished, click Save.

    Configuring external WMS layers

    When properly loaded, all layers served by the external WMS will be available to GeoServer. Before they can be served, however, they will need to be individually configured (published) as new layers. See the section on Layers for how to add and edit new layers. Once published, these layers will show up in the Layer Preview and as part of the WMS capabilities document.

    diff --git a/data/cascaded/wmts/index.html b/data/cascaded/wmts/index.html index daf4553e8af..a89e0cf4c69 100644 --- a/data/cascaded/wmts/index.html +++ b/data/cascaded/wmts/index.html @@ -1948,19 +1948,60 @@

    Adding an external WMTS

    Adding an external WMTS as a store

    Configuring a new external WTMS store

    -
    -

    Option Description

    -

    Workspace Name of the workspace to contain the store. This will also be the prefix of all of the layer names published from the store.

    -

    Data Source Name Name of the store as known to GeoServer.

    -

    Description Description of the store.

    -

    Enabled Enables the store. If disabled, no data from the remote WMTS will be served.

    -

    Capabilities URL The full URL to access the capabilities document of the remote WMTS.

    -

    User Name If the WMTS requires authentication, the user name to connect as.

    -

    Password If the WMTS requires authentication, the password to connect with.

    -

    HTTP header name If the WMTS requires a custom HTTP header, the header name.

    -

    HTTP header value If the WMTS requires a custom HTTP header, the header value.

    -

    Max concurrent connections The maximum number of persistent connections to keep for this WMTS.

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    OptionDescription
    WorkspaceName of the workspace to contain the store. This will also be the prefix of all of the layer names published from the store.
    Data Source NameName of the store as known to GeoServer.
    DescriptionDescription of the store.
    EnabledEnables the store. If disabled, no data from the remote WMTS will be served.
    Capabilities URLThe full URL to access the capabilities document of the remote WMTS.
    User NameIf the WMTS requires authentication, the user name to connect as.
    PasswordIf the WMTS requires authentication, the password to connect with.
    HTTP header nameIf the WMTS requires a custom HTTP header, the header name.
    HTTP header valueIf the WMTS requires a custom HTTP header, the header value.
    Max concurrent connectionsThe maximum number of persistent connections to keep for this WMTS.

    When finished, click Save.

    Configuring external WMTS layers

    When properly loaded, all layers served by the external WMTS will be available to GeoServer. Before they can be served, however, they will need to be individually configured (published) as new layers. See the section on Layers for how to add and edit new layers. Once published, these layers will show up in the Layer Preview and as part of the WMS capabilities document. If the WMTS layer has additional dimensions (e.g. time), related info will be reported on the WMS capabilities as well.

    diff --git a/data/database/connection-pooling/index.html b/data/database/connection-pooling/index.html index dc480e9dbbc..5d559c1ca8a 100644 --- a/data/database/connection-pooling/index.html +++ b/data/database/connection-pooling/index.html @@ -2018,17 +2018,52 @@

    Database Connection Pooling

    The purpose served by a connection pool is to maintain connection to an underlying database between requests. The benefit of which is that connection setup only need to occur once on the first request. Subsequent requests use existing connections and achieve a performance benefit as a result.

    Whenever a data store backed by a database is added to GeoServer an internal connection pool is created. This connection pool is configurable.

    Connection pool options

    -
    -

    max connections The maximum number of connections the pool can hold. When the maximum number of connections is exceeded, additional requests that require a database connection will be halted until a connection from the pool becomes available. The maximum number of connections limits the number of concurrent requests that can be made against the database.

    -

    min connections The minimum number of connections the pool will hold. This number of connections is held even when there are no active requests. When this number of connections is exceeded due to serving requests additional connections are opened until the pool reaches its maximum size (described above).

    -

    validate connections Flag indicating whether connections from the pool should be validated before they are used. A connection in the pool can become invalid for a number of reasons including network breakdown, database server timeout, etc.. The benefit of setting this flag is that an invalid connection will never be used which can prevent client errors. The downside of setting the flag is that a performance penalty is paid in order to validate connections.

    -

    fetch size The number of records read from the database in each network exchange. If set too low (<50) network latency will affect negatively performance, if set too high it might consume a significant portion of GeoServer memory and push it towards an Out Of Memory error. Defaults to 1000.

    -

    connection timeout Time, in seconds, the connection pool will wait before giving up its attempt to get a new connection from the database. Defaults to 20 seconds.

    -

    Test while idle Periodically test if the connections are still valid also while idle in the pool. Sometimes performing a test query using an idle connection can make the datastore unavailable for a while. Often the cause of this troublesome behaviour is related to a network firewall placed between GeoServer and the Database that force the closing of the underlying idle TCP connections.

    -

    Evictor run periodicity Number of seconds between idle object evictor runs.

    -

    Max connection idle time Number of seconds a connection needs to stay idle before the evictor starts to consider closing it.

    -

    Evictor tests per run Number of connections checked by the idle connection evictor for each of its runs.

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    max connectionsThe maximum number of connections the pool can hold. When the maximum number of connections is exceeded, additional requests that require a database connection will be halted until a connection from the pool becomes available. The maximum number of connections limits the number of concurrent requests that can be made against the database.
    min connectionsThe minimum number of connections the pool will hold. This number of connections is held even when there are no active requests. When this number of connections is exceeded due to serving requests additional connections are opened until the pool reaches its maximum size (described above).
    validate connectionsFlag indicating whether connections from the pool should be validated before they are used. A connection in the pool can become invalid for a number of reasons including network breakdown, database server timeout, etc.. The benefit of setting this flag is that an invalid connection will never be used which can prevent client errors. The downside of setting the flag is that a performance penalty is paid in order to validate connections.
    fetch sizeThe number of records read from the database in each network exchange. If set too low (<50) network latency will affect negatively performance, if set too high it might consume a significant portion of GeoServer memory and push it towards an Out Of Memory error. Defaults to 1000.
    connection timeoutTime, in seconds, the connection pool will wait before giving up its attempt to get a new connection from the database. Defaults to 20 seconds.
    Test while idlePeriodically test if the connections are still valid also while idle in the pool. Sometimes performing a test query using an idle connection can make the datastore unavailable for a while. Often the cause of this troublesome behaviour is related to a network firewall placed between GeoServer and the Database that force the closing of the underlying idle TCP connections.
    Evictor run periodicityNumber of seconds between idle object evictor runs.
    Max connection idle timeNumber of seconds a connection needs to stay idle before the evictor starts to consider closing it.
    Evictor tests per runNumber of connections checked by the idle connection evictor for each of its runs.
    diff --git a/data/database/oracle/index.html b/data/database/oracle/index.html index 0d8b75380c3..c13dafd5084 100644 --- a/data/database/oracle/index.html +++ b/data/database/oracle/index.html @@ -2195,19 +2195,60 @@

    Adding an Oracle datastore

    Configuring an Oracle datastore

    Configuring an Oracle datastore

    -
    -

    Option Description

    -

    host The Oracle server host name or IP address.

    -

    port The port on which the Oracle server is accepting connections (often this is port 1521).

    -

    database The name of the database to connect to. By default this is interpreted as a SID name. To connect to a Service, prefix the name with a /.

    -

    schema The database schema to access tables from. Setting this value greatly increases the speed at which the data store displays its publishable tables and views, so it is advisable to set this.

    -

    user The name of the user to use when connecting to the database.

    -

    password The password to use when connecting to the database. Leave blank for no password.

    -

    max connections min connections fetch size Connection timeout validate connections Connection pool configuration parameters. See Database Connection Pooling for details.

    -

    Loose bbox Controls how bounding box filters are made against geometries in the database. See the Using loose bounding box section below.

    -

    Metadata bbox Flag controlling the use of MDSYS.USER_SDO_GEOM_METADATA or MDSYS.ALL_SDO_GEOM_METADATA table for bounding box calculations, this brings a better performance if the views access is fast and the bounds are configured right in the tables default is false

    -

    Get remarks Boolean flag specifies whether REMARKS metadata will be returned.

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    OptionDescription
    hostThe Oracle server host name or IP address.
    portThe port on which the Oracle server is accepting connections (often this is port 1521).
    databaseThe name of the database to connect to. By default this is interpreted as a SID name. To connect to a Service, prefix the name with a /.
    schemaThe database schema to access tables from. Setting this value greatly increases the speed at which the data store displays its publishable tables and views, so it is advisable to set this.
    userThe name of the user to use when connecting to the database.
    passwordThe password to use when connecting to the database. Leave blank for no password.
    max connections min connections fetch size Connection timeout validate connectionsConnection pool configuration parameters. See Database Connection Pooling for details.
    Loose bboxControls how bounding box filters are made against geometries in the database. See the Using loose bounding box section below.
    Metadata bboxFlag controlling the use of MDSYS.USER_SDO_GEOM_METADATA or MDSYS.ALL_SDO_GEOM_METADATA table for bounding box calculations, this brings a better performance if the views access is fast and the bounds are configured right in the tables default is false
    Get remarksBoolean flag specifies whether REMARKS metadata will be returned.

    Connecting to an Oracle cluster

    In order to connect to an Oracle RAC one can use an almost full JDBC url as the database, provided it starts with ( it will be used verbatim and options "host" and "port" will be ignored. Here is an example "database" value used to connect to an Oracle RAC:

    (DESCRIPTION=(LOAD_BALANCE=on)(ADDRESS=(PROTOCOL=TCP)(HOST=host1) (PORT=1521))(ADDRESS=(PROTOCOL=TCP)(HOST=host2) (PORT=1521))(CONNECT_DATA=(SERVICE_NAME=service)))
    diff --git a/data/database/postgis/index.html b/data/database/postgis/index.html
    index 218424efa72..8288340532a 100644
    --- a/data/database/postgis/index.html
    +++ b/data/database/postgis/index.html
    @@ -2322,88 +2322,250 @@ 

    Using default connection

    Fill in the Basic Store Info used to identify the database when managing layers.

    Adding a PostGIS database

    -
    -

    Basic Store Info Description

    -
    -

    Workspace Name of the workspace to contain the database. This will also be the prefix of any layer names created from tables in the database.

    -

    Data Source Name Name of the database. This can be different from the name as known to PostgreSQL/PostGIS.

    -

    Description Description of the database/store.

    -

    Enabled Enables the store. If disabled, no data in the database will be served.

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + +
    Basic Store InfoDescription
    WorkspaceName of the workspace to contain the database. This will also be the prefix of any layer names created from tables in the database.
    Data Source NameName of the database. This can be different from the name as known to PostgreSQL/PostGIS.
    DescriptionDescription of the database/store.
    EnabledEnables the store. If disabled, no data in the database will be served.

    Move on to the connection parameters used to connect and interact with the database.

    PostGIS connection parameters

    The dbtype and namespace connection parameters are not directly editable. The dbtype parameter is for internal use only (and only accessible via the REST API).

    -
    -

    Connection Parameter Description

    -
    -

    dbtype Type of database. Internal value, leave this value as the default.

    -

    namespace Namespace to be associated with the database. This field is altered by changing the workspace name.

    -
    + + + + + + + + + + + + + + + + + +
    Connection ParameterDescription
    dbtypeType of database. Internal value, leave this value as the default.
    namespaceNamespace to be associated with the database. This field is altered by changing the workspace name.

    Connection parameters establishing a database connection (see Database Connection Pooling):

    -
    -

    Connection Parameter Description

    -
    -

    host Host name where the database exists.

    -

    port Port number to connect to the above host.

    -

    database Name of the database as known on the host.

    -

    schema Schema in the above database.

    -

    user Username to connect to the database.

    -

    passwd Password associated with the above user.

    -

    max connections Maximum amount of open connections to the database.

    -

    min connections Minimum number of pooled connections.

    -

    fetch size Number of records read with each interaction with the database.

    -

    Connection timeout Time (in seconds) the connection pool will wait before timing out.

    -

    validate connections Checks the connection is alive before using it.

    -

    Evictor run periodicity Number of seconds between idle object evictor runs.

    -

    Max connection idle time Number of seconds a connection needs to stay idle before the evictor starts to consider closing it.

    -

    Evictor tests per run Number of connections checked by the idle connection evictor for each of its runs.

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Connection ParameterDescription
    hostHost name where the database exists.
    portPort number to connect to the above host.
    databaseName of the database as known on the host.
    schemaSchema in the above database.
    userUsername to connect to the database.
    passwdPassword associated with the above user.
    max connectionsMaximum amount of open connections to the database.
    min connectionsMinimum number of pooled connections.
    fetch sizeNumber of records read with each interaction with the database.
    Connection timeoutTime (in seconds) the connection pool will wait before timing out.
    validate connectionsChecks the connection is alive before using it.
    Evictor run periodicityNumber of seconds between idle object evictor runs.
    Max connection idle timeNumber of seconds a connection needs to stay idle before the evictor starts to consider closing it.
    Evictor tests per runNumber of connections checked by the idle connection evictor for each of its runs.

    Connection parameters managing SQL generation:

    -
    -

    Connection Parameter Description

    -
    -

    Expose primary keys Expose primary key columns as values suitable for filtering.

    -

    Primary key metadata table Provide table defining how primary keys values are generated (see Controlling feature ID generation in spatial databases)

    -

    Session startup SQL SQL applied to connection before use (see Custom SQL session start/stop scripts)

    -

    Session close-up SQL SQL applied to connection after use (see Custom SQL session start/stop scripts)

    -

    preparedStatements Enables prepared statements for SQL generation, rather than text substitution.

    -

    Max open prepared statements Number of prepared statements available.

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Connection ParameterDescription
    Expose primary keysExpose primary key columns as values suitable for filtering.
    Primary key metadata tableProvide table defining how primary keys values are generated (see Controlling feature ID generation in spatial databases)
    Session startup SQLSQL applied to connection before use (see Custom SQL session start/stop scripts)
    Session close-up SQLSQL applied to connection after use (see Custom SQL session start/stop scripts)
    preparedStatementsEnables prepared statements for SQL generation, rather than text substitution.
    Max open prepared statementsNumber of prepared statements available.

    Connection parameters managing database interaction:

    -
    -

    Connection Parameter Description

    -
    -

    Loose bbox Performs only the primary filter on the bounding box. See the section on Using loose bounding box for details.

    -

    Estimated extends Use spatial index to quickly estimate bounds, rather than check every row.

    -

    Encode functions Generate supported filter functions into their SQL equivalent.

    -

    Support on the fly geometry simplification Enables use of PostGIS geometry simplification

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + +
    Connection ParameterDescription
    Loose bboxPerforms only the primary filter on the bounding box. See the section on Using loose bounding box for details.
    Estimated extendsUse spatial index to quickly estimate bounds, rather than check every row.
    Encode functionsGenerate supported filter functions into their SQL equivalent.
    Support on the fly geometry simplificationEnables use of PostGIS geometry simplification

    Connection parameters supporting initial database creation:

    -
    -

    Connection Parameter Description

    -
    -

    create database Enable to define a new database on connection

    -

    create database params Additional CREATE DATABASE definition, example WITH TEMPLATE=postgis

    -
    + + + + + + + + + + + + + + + + + +
    Connection ParameterDescription
    create databaseEnable to define a new database on connection
    create database paramsAdditional CREATE DATABASE definition, example WITH TEMPLATE=postgis

    When finished, click Save.

    Using JNDI

    GeoServer can also connect to a PostGIS database using JNDI (Java Naming and Directory Interface).

    To begin, navigate to Stores → Add a new store → PostGIS NG (JNDI).

    Adding a PostGIS database (using JNDI)

    -
    -

    Option Description

    -
    -

    Workspace Name of the workspace to contain the store. This will also be the prefix of all of the layer names created from the store.

    -

    Data Source Name Name of the database. This can be different from the name as known to PostgreSQL/PostGIS.

    -

    Description Description of the database/store.

    -

    Enabled Enables the store. If disabled, no data in the database will be served.

    -

    dbtype Type of database. Leave this value as the default.

    -

    jndiReferenceName JNDI path to the database.

    -

    schema Schema for the above database.

    -

    namespace Namespace to be associated with the database. This field is altered by changing the workspace name.

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    OptionDescription
    WorkspaceName of the workspace to contain the store. This will also be the prefix of all of the layer names created from the store.
    Data Source NameName of the database. This can be different from the name as known to PostgreSQL/PostGIS.
    DescriptionDescription of the database/store.
    EnabledEnables the store. If disabled, no data in the database will be served.
    dbtypeType of database. Leave this value as the default.
    jndiReferenceNameJNDI path to the database.
    schemaSchema for the above database.
    namespaceNamespace to be associated with the database. This field is altered by changing the workspace name.

    When finished, click Save.

    Configuring PostGIS layers

    When properly loaded, all tables in the database will be visible to GeoServer, but they will need to be individually configured before being served by GeoServer. See the section on Layers for how to add and edit new layers.

    diff --git a/data/database/primarykey/index.html b/data/database/primarykey/index.html index 25ffc1f9fff..b1d8f326d33 100644 --- a/data/database/primarykey/index.html +++ b/data/database/primarykey/index.html @@ -2085,15 +2085,44 @@

    Metadata table description

    The table can be given a different name. In that case, the (schema qualified) name of the table must be specified in the primary key metadata table configuration parameter of the store.

    The following table describes the meaning of each column in the metadata table.

    -
    -

    Column Description

    -

    table_schema Name of the database schema in which the table is located.

    -

    table_name Name of the table or view to be published

    -

    pk_column Name of a column used to form the feature IDs

    -

    pk_column_idx Index of the column in a multi-column key, else NULL. In case multi column keys are needed, multiple records with the same table schema and table name will be used.

    -

    pk_policy The new value generation policy, used in case a new feature needs to be added in the table (following a WFS-T insert operation).

    -

    pk_sequence The name of the database sequence to be used when generating a new value for the pk_column.

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ColumnDescription
    table_schemaName of the database schema in which the table is located.
    table_nameName of the table or view to be published
    pk_columnName of a column used to form the feature IDs
    pk_column_idxIndex of the column in a multi-column key, else NULL. In case multi column keys are needed, multiple records with the same table schema and table name will be used.
    pk_policyThe new value generation policy, used in case a new feature needs to be added in the table (following a WFS-T insert operation).
    pk_sequenceThe name of the database sequence to be used when generating a new value for the pk_column.

    The possible values for pk_policy are:

      diff --git a/data/raster/arcgrid/index.html b/data/raster/arcgrid/index.html index 31b90d32dbc..14c34f26e2f 100644 --- a/data/raster/arcgrid/index.html +++ b/data/raster/arcgrid/index.html @@ -2009,14 +2009,40 @@

      Adding an ArcGrid data store

      Configuring a ArcGrid data store

      Configuring an ArcGrid data store

      -
      -

      Option Description

      -

      Workspace

      -

      Data Source Name

      -

      Description

      -

      Enabled

      -

      URL

      -
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      OptionDescription
      Workspace
      Data Source Name
      Description
      Enabled
      URL
      diff --git a/data/raster/geopkg/index.html b/data/raster/geopkg/index.html index 89f3334ebc9..883e23ecf92 100644 --- a/data/raster/geopkg/index.html +++ b/data/raster/geopkg/index.html @@ -1991,14 +1991,40 @@

      Adding a GeoPackage Raster GeoPackage (mosaic) in the list of raster data stores

      Configuring a GeoPackage (mosaic) data store

      -
      -

      Option Description

      -

      Workspace Name of the workspace to contain the GeoPackage Mosaic store. This will also be the prefix of the raster layers created from the store.

      -

      Data Source Name Name of the GeoPackage Mosaic Store as it will be known to GeoServer. This can be different from the filename. )

      -

      Description A full free-form description of the GeoPackage Mosaic Store.

      -

      Enabled If checked, it enables the store. If unchecked (disabled), no data in the GeoPackage Mosaic Store will be served from GeoServer.

      -

      URL Location of the GeoPackage file. This can be an absolute path (such as file:C:\Data\landbase.gpkg) or a path relative to GeoServer's data directory (such as file:data/landbase.gpkg).

      -
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      OptionDescription
      WorkspaceName of the workspace to contain the GeoPackage Mosaic store. This will also be the prefix of the raster layers created from the store.
      Data Source NameName of the GeoPackage Mosaic Store as it will be known to GeoServer. This can be different from the filename. )
      DescriptionA full free-form description of the GeoPackage Mosaic Store.
      EnabledIf checked, it enables the store. If unchecked (disabled), no data in the GeoPackage Mosaic Store will be served from GeoServer.
      URLLocation of the GeoPackage file. This can be an absolute path (such as file:C:\Data\landbase.gpkg) or a path relative to GeoServer's data directory (such as file:data/landbase.gpkg).

      When finished, click Save.

      diff --git a/data/raster/geotiff/index.html b/data/raster/geotiff/index.html index 8ee35fc5639..103102b4c9b 100644 --- a/data/raster/geotiff/index.html +++ b/data/raster/geotiff/index.html @@ -2039,14 +2039,40 @@

      Adding a GeoTIFF data store

      Configuring a GeoTIFF data store

      Configuring a GeoTIFF data store

      -
      -

      Option Description

      -

      Workspace Name of the workspace to contain the GeoTIFF store. This will also be the prefix of the raster layer created from the store.

      -

      Data Source Name Name of the GeoTIFF as it will be known to GeoServer. This can be different from the filename. The combination of the workspace name and this name will be the full layer name (ex: world:landbase)

      -

      Description A full free-form description of the GeoTIFF store.

      -

      Enabled If checked, it enables the store. If unchecked (disabled), no data in the GeoTIFF will be served from GeoServer.

      -

      URL Location of the GeoTIFF file. This can be an absolute path (such as file:C:\Data\landbase.tif) or a path relative to GeoServer's data directory (such as file:data/landbase.tif).

      -
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      OptionDescription
      WorkspaceName of the workspace to contain the GeoTIFF store. This will also be the prefix of the raster layer created from the store.
      Data Source NameName of the GeoTIFF as it will be known to GeoServer. This can be different from the filename. The combination of the workspace name and this name will be the full layer name (ex: world:landbase)
      DescriptionA full free-form description of the GeoTIFF store.
      EnabledIf checked, it enables the store. If unchecked (disabled), no data in the GeoTIFF will be served from GeoServer.
      URLLocation of the GeoTIFF file. This can be an absolute path (such as file:C:\Data\landbase.tif) or a path relative to GeoServer's data directory (such as file:data/landbase.tif).

      Note

      Notice that the GeoTiff plugin is able to handle internal/external overviews and internal/external masks.

      diff --git a/data/raster/imagemosaic/configuration/index.html b/data/raster/imagemosaic/configuration/index.html index 2744b527ab0..e4240828c59 100644 --- a/data/raster/imagemosaic/configuration/index.html +++ b/data/raster/imagemosaic/configuration/index.html @@ -2218,23 +2218,82 @@

      Configuration files

      Primary configuration file

      The mosaic configuration file is the primary file used to store the configuration parameters that control the ImageMosaic plugin. When created by GeoServer it is by default called <directory>.properties, where <directory> is the name of the root directory of the store. (It is not related to the store name in GeoServer.) It can have other names, as long as it does not conflict with other files such as datastore.properties or indexer.properties. This file usually does not require manual editing.

      The table below describes the various elements in this configuration file.

      -
      -

      Parameter Mandatory? Description

      -
      -

      Levels Y Represents the resolutions for the various levels of the granules of this mosaic.

      -

      Heterogeneous N Sets whether the image files are heterogeneous. Default is false.

      -

      AbsolutePath N Controls whether or not the path stored inside the location attribute represents an absolute path or a path relative to the location of the shapefile index. Notice that a relative index ensures much more portability of the mosaic itself. Default value for this parameter is false, which means relative paths.

      -

      Name N The name to be assigned to the index. If unspecified, the index name will usually match the name of the folder containing the mosaic.

      -

      TypeName Y Featuretype name for this mosaic. Usually the name as Name.

      -

      Caching N Boolean value to enable caching. When set to true, the ImageMosaic will try to save in memory the entire contents of the index to reduce loading/query time. Set to false for a large granule index and/or if new granules are to be ingested (for example, when the index is on a database and we interact directly with it). Default is false.

      -

      ExpandToRGB N Boolean flag to force color expansion from index color model (paletted datasets) to component color model (RGB). Default is false.

      -

      LocationAttribute Y The name of the attribute path in the shapefile index. Default is location.

      -

      SuggestedSPI Y Suggested plugin for reading the image files.

      -

      SuggestedFormat N Suggested GridFormat for reading the image files.

      -

      Envelope2D N Envelope for the mosaic formatted as LLX,LLY URX,URY (notice the space between the lower left and upper right coordinate pairs).

      -

      CheckAuxiliaryMetadata N This parameter allows to specify whether the ImageMosaic plugin should check for the presence of a GDAL aux.xml file beside each granule file. For most common use cases, you don't need to set or specify this parameter. Being disabled by Default, ImageMosaic won't look for an ancillary file for each granule being initialized in the GranuleCatalog. This avoid useless checks, especially when dealing with thousand of granules. You should set that parameter to true when you want to instruct the ImageMosaic to look for a GDAL generated aux.xml file containing PAM (Persistent Auxiliary Metadata) for each granule, to be attached to the Granule info (GranuleDescriptor). This is specially useful when you have setup a Dynamic ColorMap rendering transformation which dynamically set a color map based on the statistics collected into the granule's GDAL PAM being previously generated with a gdalinfo -stats parameter.

      -

      LevelsNum Y Represents the number of reduced resolution layers that we currently have for the granules of this mosaic.

      -
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      ParameterMandatory?Description
      LevelsYRepresents the resolutions for the various levels of the granules of this mosaic.
      HeterogeneousNSets whether the image files are heterogeneous. Default is false.
      AbsolutePathNControls whether or not the path stored inside the location attribute represents an absolute path or a path relative to the location of the shapefile index. Notice that a relative index ensures much more portability of the mosaic itself. Default value for this parameter is false, which means relative paths.
      NameNThe name to be assigned to the index. If unspecified, the index name will usually match the name of the folder containing the mosaic.
      TypeNameYFeaturetype name for this mosaic. Usually the name as Name.
      CachingNBoolean value to enable caching. When set to true, the ImageMosaic will try to save in memory the entire contents of the index to reduce loading/query time. Set to false for a large granule index and/or if new granules are to be ingested (for example, when the index is on a database and we interact directly with it). Default is false.
      ExpandToRGBNBoolean flag to force color expansion from index color model (paletted datasets) to component color model (RGB). Default is false.
      LocationAttributeYThe name of the attribute path in the shapefile index. Default is location.
      SuggestedSPIYSuggested plugin for reading the image files.
      SuggestedFormatNSuggested GridFormat for reading the image files.
      Envelope2DNEnvelope for the mosaic formatted as LLX,LLY URX,URY (notice the space between the lower left and upper right coordinate pairs).
      CheckAuxiliaryMetadataNThis parameter allows to specify whether the ImageMosaic plugin should check for the presence of a GDAL aux.xml file beside each granule file. For most common use cases, you don't need to set or specify this parameter. Being disabled by Default, ImageMosaic won't look for an ancillary file for each granule being initialized in the GranuleCatalog. This avoid useless checks, especially when dealing with thousand of granules. You should set that parameter to true when you want to instruct the ImageMosaic to look for a GDAL generated aux.xml file containing PAM (Persistent Auxiliary Metadata) for each granule, to be attached to the Granule info (GranuleDescriptor). This is specially useful when you have setup a Dynamic ColorMap rendering transformation which dynamically set a color map based on the statistics collected into the granule's GDAL PAM being previously generated with a gdalinfo -stats parameter.
      LevelsNumYRepresents the number of reduced resolution layers that we currently have for the granules of this mosaic.

      A sample configuration file follows:

      Levels=0.4,0.4
       Heterogeneous=false
      @@ -2316,31 +2375,122 @@ 

      datastore.properties

      indexer.properties

      In addition to the required envelope and location attributes, the schema for the index store may expose other custom attributes which can be used later for filtering the ImageMosaic granules on the fly during a WMS or WCS request or to diver WMS and WCS dimensions like TIME, ELEVATION and so on. This is configured by the indexer.properties file:

      -
      -

      Parameter Mandatory? Description

      -
      -

      Schema Y A comma-separated sequence describing the mapping between attribute and data type.

      -

      PropertyCollectors Y A comma-separated list of PropertyCollectors. Each entry in the list includes the extractor class, the file name (within square brackets [ ] and not including the .properties suffix) containing the regular expression needed to extract the attribute value from the granule file name, and the attribute name (within parentheses ( )). The instance of the extractor class also indicates the type of object computed by the specific collector, so a TimestampFileNameExtractorSPI will return Timestamps while a DoubleFileNameExtractorSPI will return Double numbers.

      -

      TimeAttribute N Specifies the name of the time-variant attribute.

      -

      ElevationAttribute N Specifies the name of the elevation attribute.

      -

      AuxiliaryFile N Path to an auxiliary file to be used for internal purposes (For example: when dealing with NetCDF granules, it refers to the NetCDF XML ancillary file.)

      -

      AbsolutePath N Controls whether or not the path stored inside the location attribute represents an absolute path or a path relative to the location of the shapefile index. Notice that a relative index ensures better portability of the mosaic itself. Default value for this parameter is false, which means relative paths.

      -

      Caching N Boolean value to enable caching. When set to true, the ImageMosaic will try to save in memory the entire contents of the index to reduce loading/query time. Set to false for a large granule index and/or if new granules are to be ingested (for example, when the index is on a database and we interact directly with it). Default is false.

      -

      CanBeEmpty N Boolean flag used for configuring empty mosaics. When enabled the ImageMosaic will not throw an exception caused by the absence of any coverage. By default it is set to false.

      -

      Envelope2D N Envelope for the mosaic formatted as LLX,LLY URX,URY (notice the space between the lower left and upper right coordinate pairs).

      -

      ExpandToRGB N Boolean flag to force color expansion from index color model (paletted datasets) to component color model (RGB). Default is false.

      -

      IndexingDirectories N Comma separated values list of paths referring to directories containing granules to be indexed. If unspecified, the IndexingDirectory will be the mosaic configuration directory. This parameter allows configuration of a mosaic in a folder which contains only configuration files, while the granules to be indexed are stored somewhere else.

      -

      Name N The name to be assigned to the index. If unspecified, the index name will usually match the name of the folder containing the mosaic.

      -

      NoData N Specifies the NoData for the mosaic. (This might be useful, as an instance, when imposing the Envelope2D. At time of ImageMosaic's initialization, a small 5x5 pixels sample read is performed by ImageMosaic on the Envelope's corner in order to retrieve granule's metadata and properties, as nodata. If Envelope2D is forced in configuration, there might be the case that this sample read will not involve any actual granule so a default noData will be set which may be different with respect to what is actually stored on granules. Specifying the desired NoData property in indexer will solve this type of issue).

      -

      CoverageNameCollectorSPI N As described in the previous row, the Name parameter allows specification of the coverage name to be exposed by the ImageMosaic. An ImageMosaic of NetCDFs instead exposes a coverage for each supported variable found in the NetCDF, using the variable's name as the coverage name (for instance, air_temperature, wind_speed, etc.) The optional CoverageNameCollectorSPI property allows specification of a CoverageNameCollector plugin to be used to instruct the ImageMosaic on how to setup different coverageNames for granules. It should contains the full name of the implementing class plus an optional set of semicolon-separated keyValue pairs prefixed by ":". See below for an example.

      -

      Recursive N Boolean flag used at indexing time. When set to true, the indexer will look for granules by scanning any subdirectory contained in the indexing directory. If false, only the main folder will be analyzed. Default is true.

      -

      UseExistingSchema N Boolean flag used for enabling/disabling the use of existing schemas. When enabled, the ImageMosaic will start indexing granules using the existing database schema (from datastore.properties) instead of populating it. This is useful when you already have a database with a valid mosaic schema (the_geom, location and other attributes, take a look at gdalindex) or when you do not want to rename the images to add times and dimensions (you should simply add them to the table, to AdditionalDomainAttributes and to PropertyCollectors). Default is false.

      -

      Wildcard N Wildcard used to specify which files should be scanned by the indexer. (For instance: "*.tif"). Currently, logic operators and lists aren't supported, so this field is limited to a single wildcard element with no support for AND/OR operators combinations.

      -

      WrapStore N By default, Postgresql identifiers can't be longer than 63 chars. Longer names will be truncated to that fixed length. When dealing with multidimensional datasets (for instance: NetCDFs, GRIBs) each variable (NetCDF) or parameter (GRIB) is indexed into a table with the same name. Therefore an atmosphere-absorption-optical-thickness-due-to-particulate-organic-matter-ambient-aerosol-particles NetCDF CF variable will be associated to a table with the same name. Postgresql will truncate that to atmosphere-absorption-optical-thickness-due-to-particulate-orga breaking the one-to-one mapping and therefore breaking the proper functioning. Setting the WrapStore flag to true will establish a hidden mapping between full long names and truncated table names to support proper working.

      -

      MosaicCRS N The "native" CRS of the mosaic, that is, the one in which footprints are collected. Useful when dealing with granules in multiple CRSs (see tutorial)

      -

      AdditionalDomainAttributes N Comma separate list of custom dimensions to be exposed. Each custom dimension declaration can be a simple attribute name from the schema, e.g., runtime, a mapping from dimension name to attribute name, e.g. time2(runtime), or a mapping from a range dimension name to two attributes, e.g., timerange(timeStart,timeEnd)

      -

      PropertySelection N Boolean value to enable/disable selection of properties from the mosaic index. Default is false. When enabled, the ImageMosaic will try to load in memory only the properties needed to perform mosaicking. A typical use case is using a STAC API as a mosaic index, a STAC item typically contains many complex properties, and the API might be remote, reducing the payload improves both query time and memory usage.

      -
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      ParameterMandatory?Description
      SchemaYA comma-separated sequence describing the mapping between attribute and data type.
      PropertyCollectorsYA comma-separated list of PropertyCollectors. Each entry in the list includes the extractor class, the file name (within square brackets [ ] and not including the .properties suffix) containing the regular expression needed to extract the attribute value from the granule file name, and the attribute name (within parentheses ( )). The instance of the extractor class also indicates the type of object computed by the specific collector, so a TimestampFileNameExtractorSPI will return Timestamps while a DoubleFileNameExtractorSPI will return Double numbers.
      TimeAttributeNSpecifies the name of the time-variant attribute.
      ElevationAttributeNSpecifies the name of the elevation attribute.
      AuxiliaryFileNPath to an auxiliary file to be used for internal purposes (For example: when dealing with NetCDF granules, it refers to the NetCDF XML ancillary file.)
      AbsolutePathNControls whether or not the path stored inside the location attribute represents an absolute path or a path relative to the location of the shapefile index. Notice that a relative index ensures better portability of the mosaic itself. Default value for this parameter is false, which means relative paths.
      CachingNBoolean value to enable caching. When set to true, the ImageMosaic will try to save in memory the entire contents of the index to reduce loading/query time. Set to false for a large granule index and/or if new granules are to be ingested (for example, when the index is on a database and we interact directly with it). Default is false.
      CanBeEmptyNBoolean flag used for configuring empty mosaics. When enabled the ImageMosaic will not throw an exception caused by the absence of any coverage. By default it is set to false.
      Envelope2DNEnvelope for the mosaic formatted as LLX,LLY URX,URY (notice the space between the lower left and upper right coordinate pairs).
      ExpandToRGBNBoolean flag to force color expansion from index color model (paletted datasets) to component color model (RGB). Default is false.
      IndexingDirectoriesNComma separated values list of paths referring to directories containing granules to be indexed. If unspecified, the IndexingDirectory will be the mosaic configuration directory. This parameter allows configuration of a mosaic in a folder which contains only configuration files, while the granules to be indexed are stored somewhere else.
      NameNThe name to be assigned to the index. If unspecified, the index name will usually match the name of the folder containing the mosaic.
      NoDataNSpecifies the NoData for the mosaic. (This might be useful, as an instance, when imposing the Envelope2D. At time of ImageMosaic's initialization, a small 5x5 pixels sample read is performed by ImageMosaic on the Envelope's corner in order to retrieve granule's metadata and properties, as nodata. If Envelope2D is forced in configuration, there might be the case that this sample read will not involve any actual granule so a default noData will be set which may be different with respect to what is actually stored on granules. Specifying the desired NoData property in indexer will solve this type of issue).
      CoverageNameCollectorSPINAs described in the previous row, the Name parameter allows specification of the coverage name to be exposed by the ImageMosaic. An ImageMosaic of NetCDFs instead exposes a coverage for each supported variable found in the NetCDF, using the variable's name as the coverage name (for instance, air_temperature, wind_speed, etc.) The optional CoverageNameCollectorSPI property allows specification of a CoverageNameCollector plugin to be used to instruct the ImageMosaic on how to setup different coverageNames for granules. It should contains the full name of the implementing class plus an optional set of semicolon-separated keyValue pairs prefixed by ":". See below for an example.
      RecursiveNBoolean flag used at indexing time. When set to true, the indexer will look for granules by scanning any subdirectory contained in the indexing directory. If false, only the main folder will be analyzed. Default is true.
      UseExistingSchemaNBoolean flag used for enabling/disabling the use of existing schemas. When enabled, the ImageMosaic will start indexing granules using the existing database schema (from datastore.properties) instead of populating it. This is useful when you already have a database with a valid mosaic schema (the_geom, location and other attributes, take a look at gdalindex) or when you do not want to rename the images to add times and dimensions (you should simply add them to the table, to AdditionalDomainAttributes and to PropertyCollectors). Default is false.
      WildcardNWildcard used to specify which files should be scanned by the indexer. (For instance: "*.tif"). Currently, logic operators and lists aren't supported, so this field is limited to a single wildcard element with no support for AND/OR operators combinations.
      WrapStoreNBy default, Postgresql identifiers can't be longer than 63 chars. Longer names will be truncated to that fixed length. When dealing with multidimensional datasets (for instance: NetCDFs, GRIBs) each variable (NetCDF) or parameter (GRIB) is indexed into a table with the same name. Therefore an atmosphere-absorption-optical-thickness-due-to-particulate-organic-matter-ambient-aerosol-particles NetCDF CF variable will be associated to a table with the same name. Postgresql will truncate that to atmosphere-absorption-optical-thickness-due-to-particulate-orga breaking the one-to-one mapping and therefore breaking the proper functioning. Setting the WrapStore flag to true will establish a hidden mapping between full long names and truncated table names to support proper working.
      MosaicCRSNThe "native" CRS of the mosaic, that is, the one in which footprints are collected. Useful when dealing with granules in multiple CRSs (see tutorial)
      AdditionalDomainAttributesNComma separate list of custom dimensions to be exposed. Each custom dimension declaration can be a simple attribute name from the schema, e.g., runtime, a mapping from dimension name to attribute name, e.g. time2(runtime), or a mapping from a range dimension name to two attributes, e.g., timerange(timeStart,timeEnd)
      PropertySelectionNBoolean value to enable/disable selection of properties from the mosaic index. Default is false. When enabled, the ImageMosaic will try to load in memory only the properties needed to perform mosaicking. A typical use case is using a STAC API as a mosaic index, a STAC item typically contains many complex properties, and the API might be remote, reducing the payload improves both query time and memory usage.

      Here is a sample indexer.properties file:

      Schema=*the_geom:Polygon,location:String,ingestion:java.util.Date,elevation:Double
       PropertyCollectors=TimestampFileNameExtractorSPI[timeregex](ingestion),DoubleFileNameExtractorSPI[elevationregex](elevation)
      @@ -2359,18 +2509,48 @@ 

      indexer.properties

      Property collectors

      The following table enumerates the available property collectors

      -
      -

      Collector SPI name Description

      -
      -

      ByteFileNameExtractorSPI DoubleFileNameExtractorSPI FloatFileNameExtractorSPI IntegerFileNameExtractorSPI LongFileNameExtractorSPI ShortFileNameExtractorSPI Extracts an number from the file name using a regular expression specified in a sidecar file, casting it to the desired type based on the SPI name (e..g, DoubleFileNameExtractorSPI extracts double precision floating points, IntegerFileNameExtractorSPI extracts 32 bit integers)

      -

      TimestampFileNameExtractorSPI Extracts a timestamp from the filename using a regular expression specified in a sidecar file

      -

      StringFileNameExtractorSPI Extracts a string from the filename using a regular expression specified in a sidecar file

      -

      CurrentDateExtractorSPI Returns the current date and time (useful to track ingestion times in a mosaic)

      -

      FSDateExtractorSPI Returns the creation date of the file being harvested

      -

      DateExtractorSPI Returns the date found in tiff file header "DateTime" (code 306)

      -

      ResolutionExtractorSPI ResolutionXExtractorSPI ResolutionYExtractorSPI Returns the native resolution of the raster being harvested. ResolutionExtractorSPI and ResolutionXExtractorSPI return the x resolution of the raster, ResolutionYExtractorSPI returns the resolution on the Y axis instead

      -

      CRSExtractorSPI Returns the code of the raster coordinate reference system, as a string, e.g. "EPSG:4326"

      -
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      Collector SPI nameDescription
      ByteFileNameExtractorSPI DoubleFileNameExtractorSPI FloatFileNameExtractorSPI IntegerFileNameExtractorSPI LongFileNameExtractorSPI ShortFileNameExtractorSPIExtracts an number from the file name using a regular expression specified in a sidecar file, casting it to the desired type based on the SPI name (e..g, DoubleFileNameExtractorSPI extracts double precision floating points, IntegerFileNameExtractorSPI extracts 32 bit integers)
      TimestampFileNameExtractorSPIExtracts a timestamp from the filename using a regular expression specified in a sidecar file
      StringFileNameExtractorSPIExtracts a string from the filename using a regular expression specified in a sidecar file
      CurrentDateExtractorSPIReturns the current date and time (useful to track ingestion times in a mosaic)
      FSDateExtractorSPIReturns the creation date of the file being harvested
      DateExtractorSPIReturns the date found in tiff file header "DateTime" (code 306)
      ResolutionExtractorSPI ResolutionXExtractorSPI ResolutionYExtractorSPIReturns the native resolution of the raster being harvested. ResolutionExtractorSPI and ResolutionXExtractorSPI return the x resolution of the raster, ResolutionYExtractorSPI returns the resolution on the Y axis instead
      CRSExtractorSPIReturns the code of the raster coordinate reference system, as a string, e.g. "EPSG:4326"

      The PropertyCollectors parameter in the example above indicates two additional .properties files used to populate the ingestion and elevation attributes:

      timeregex.properties:

      regex=[0-9]{8}T[0-9]{9}Z(\?!.*[0-9]{8}T[0-9]{9}Z.*)
      @@ -2413,15 +2593,36 @@ 

      Store parameters

      ImageMosaic in the list of raster data stores

      Configuring an ImageMosaic data store

      -
      -

      Option Description

      -
      -

      Workspace Workspace for the store

      -

      Data Source Name Name of the store

      -

      Description Description of the store

      -

      Enabled Determines whether the store is enabled. If unchecked, all layers in the store will be disabled.

      -

      URL The location of the store. Can be a local directory.

      -
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      OptionDescription
      WorkspaceWorkspace for the store
      Data Source NameName of the store
      DescriptionDescription of the store
      EnabledDetermines whether the store is enabled. If unchecked, all layers in the store will be disabled.
      URLThe location of the store. Can be a local directory.

      Coverage parameters

      Creation of the store is the first step to getting an ImageMosaic published in GeoServer. Most of the configuration is done when publishing the resulting coverage (layer).

      The Coverage Editor gives users the possibility to set a few control parameters to further control the mosaic creation process.

      diff --git a/data/raster/imagemosaic/tutorial/index.html b/data/raster/imagemosaic/tutorial/index.html index 09e27b04b42..0580d718e1f 100644 --- a/data/raster/imagemosaic/tutorial/index.html +++ b/data/raster/imagemosaic/tutorial/index.html @@ -2350,17 +2350,44 @@

      DEM/Bathymetry

    The configuration parameters are as follows:

    -
    -

    Parameter Value

    -
    -

    MaxAllowedTiles 2147483647

    -

    BackgroundValues -9999

    -

    OutputTransparentColor \"no color\"

    -

    InputTransparentColor \"no color\"

    -

    AllowMultiThreading True

    -

    USE_JAI_IMAGEREAD True

    -

    SUGGESTED_TILE_SIZE 512,512

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ParameterValue
    MaxAllowedTiles2147483647
    BackgroundValues-9999
    OutputTransparentColor\"no color\"
    InputTransparentColor\"no color\"
    AllowMultiThreadingTrue
    USE_JAI_IMAGEREADTrue
    SUGGESTED_TILE_SIZE512,512

    Aerial imagery

    In this example we are going to create a mosaic that will serve aerial imagery, specifically RGB GeoTIFFs. Because this is visual data, in the Coverage Editor you can use the basic raster style, which is just a stub SLD to instruct the GeoServer raster renderer to not do anything particular in terms of color management:

    <?xml version="1.0" encoding="ISO-8859-1"?>
    @@ -2395,17 +2422,44 @@ 

    Aerial imagery

    Those ugly black areas are the result of applying the default mosaic parameters to a mosaic that does not entirely cover its bounding box. The areas within the BBOX that are not covered with data will default to a value of 0 on each band. Since this mosaic is RGB we can simply set the OutputTransparentColor to 0,0,0 in order to get transparent fills for the BBOX.

    The various parameters can be set as follows:

    -
    -

    Parameter Value

    -
    -

    MaxAllowedTiles 2147483647

    -

    BackgroundValues (default)

    -

    OutputTransparentColor #000000

    -

    InputTransparentColor \"no color\"

    -

    AllowMultiThreading True

    -

    USE_JAI_IMAGEREAD True

    -

    SUGGESTED_TILE_SIZE 512,512

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ParameterValue
    MaxAllowedTiles2147483647
    BackgroundValues(default)
    OutputTransparentColor#000000
    InputTransparentColor\"no color\"
    AllowMultiThreadingTrue
    USE_JAI_IMAGEREADTrue
    SUGGESTED_TILE_SIZE512,512

    The result is the following:

    ![](images/prato_2.png)
     *Advanced configuration*
    @@ -2419,17 +2473,44 @@ 

    Scanned maps

    This mosaic, formed by two single granules, shows a typical case where the \"nodata\" collar areas of the granules overlap, as shown in the picture above. In this case we can use the InputTransparentColor parameter to make the collar areas disappear during the superimposition process --- in this case, by using an InputTransparentColor of #FFFFFF.

    The final configuration parameters are the following:

    -
    -

    Parameter Value

    -
    -

    MaxAllowedTiles 2147483647

    -

    BackgroundValues (default)

    -

    OutputTransparentColor \"no color\"

    -

    InputTransparentColor #FFFFFF

    -

    AllowMultiThreading True

    -

    USE_JAI_IMAGEREAD True

    -

    SUGGESTED_TILE_SIZE 512,512

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ParameterValue
    MaxAllowedTiles2147483647
    BackgroundValues(default)
    OutputTransparentColor\"no color\"
    InputTransparentColor#FFFFFF
    AllowMultiThreadingTrue
    USE_JAI_IMAGEREADTrue
    SUGGESTED_TILE_SIZE512,512

    This is the result:

    ![](images/iacovella_2.png)
     *Advanced configuration*
    diff --git a/data/raster/imagepyramid/index.html b/data/raster/imagepyramid/index.html
    index dbd2b1e8153..cbc9370f22b 100644
    --- a/data/raster/imagepyramid/index.html
    +++ b/data/raster/imagepyramid/index.html
    @@ -2044,14 +2044,40 @@ 

    Adding an ImagePyramid data store

    Configuring an ImagePyramid data store

    Configuring an ImagePyramid data store

    -
    -

    Option Description

    -

    Workspace

    -

    Data Source Name

    -

    Description

    -

    Enabled

    -

    URL

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    OptionDescription
    Workspace
    Data Source Name
    Description
    Enabled
    URL
    diff --git a/data/raster/worldimage/index.html b/data/raster/worldimage/index.html index 32a52e4e223..f8769e65765 100644 --- a/data/raster/worldimage/index.html +++ b/data/raster/worldimage/index.html @@ -2009,14 +2009,40 @@

    Adding a WorldImage data store

    Configuring a WorldImage data store

    Configuring a WorldImage data store

    -
    -

    Option Description

    -

    Workspace

    -

    Data Source Name

    -

    Description

    -

    Enabled

    -

    URL

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    OptionDescription
    Workspace
    Data Source Name
    Description
    Enabled
    URL
    diff --git a/data/vector/directory/index.html b/data/vector/directory/index.html index 795010cefa0..2132e723329 100644 --- a/data/vector/directory/index.html +++ b/data/vector/directory/index.html @@ -1915,16 +1915,48 @@

    Adding a directory

    To begin, navigate to Stores → Add a new store → Directory of spatial files.

    Adding a directory of spatial files as a store

    -
    -

    Option Description

    -

    Workspace Name of the workspace to contain the store. This will also be the prefix of all of the layer names created from shapefiles in the store.

    -

    Data Source Name Name of the store as known to GeoServer.

    -

    Description Description of the directory store.

    -

    Enabled Enables the store. If disabled, no data in any of the shapefiles will be served.

    -

    URL Location of the directory. Can be an absolute path (such as file:C:\Data\shapefile_directory) or a path relative to the data directory (such as file:data/shapefile_directory.

    -

    namespace Namespace to be associated with the store. This field is altered by changing the workspace name.

    -

    skip scan Skip scan of alternative shapefile extensions (i.e. .SHP, .shp.XML, .CPG, ...) on Not-Windows systems. This can be useful when you have a directory containing several thousands of shapefiles. By Default, the shapefile plugin will look for all the shapefile extensions (.shp, .dbf, .shx, .prj, .qix, .fix, .shp.xml, .cpg). As soon as one of these is missing, it will do a search on the directory for the missing file, ignoring the case. This might be time consuming on directories with a huge number of files.

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    OptionDescription
    WorkspaceName of the workspace to contain the store. This will also be the prefix of all of the layer names created from shapefiles in the store.
    Data Source NameName of the store as known to GeoServer.
    DescriptionDescription of the directory store.
    EnabledEnables the store. If disabled, no data in any of the shapefiles will be served.
    URLLocation of the directory. Can be an absolute path (such as file:C:\Data\shapefile_directory) or a path relative to the data directory (such as file:data/shapefile_directory.
    namespaceNamespace to be associated with the store. This field is altered by changing the workspace name.
    skip scanSkip scan of alternative shapefile extensions (i.e. .SHP, .shp.XML, .CPG, ...) on Not-Windows systems. This can be useful when you have a directory containing several thousands of shapefiles. By Default, the shapefile plugin will look for all the shapefile extensions (.shp, .dbf, .shx, .prj, .qix, .fix, .shp.xml, .cpg). As soon as one of these is missing, it will do a search on the directory for the missing file, ignoring the case. This might be time consuming on directories with a huge number of files.

    When finished, click Save.

    Configuring shapefiles

    All of the shapefiles contained in the directory store will be loaded as part of the directory store, but they will need to be individually configured as new layers they can be served by GeoServer. See the section on Layers for how to add and edit new layers.

    diff --git a/data/vector/geopkg/index.html b/data/vector/geopkg/index.html index ba402b788a6..76137abe360 100644 --- a/data/vector/geopkg/index.html +++ b/data/vector/geopkg/index.html @@ -1896,18 +1896,56 @@

    Adding a GeoPackage Vector Data S GeoPackage in the list of vector data stores

    Configuring a GeoPackage Vector data store

    -
    -

    Option Description

    -

    database URI specifying geopackage file.

    -

    user User to access database.

    -

    passwd Password to access database.

    -

    namespace Namespace to be associated with the database. This field is altered by changing the workspace name.

    -

    max connections Maximum amount of open connections to the database.

    -

    min connections Minimum number of pooled connections.

    -

    fetch size Number of records read with each interaction with the database.

    -

    Connection timeout Time (in seconds) the connection pool will wait before timing out.

    -

    validate connections Checks the connection is alive before using it.

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    OptionDescription
    databaseURI specifying geopackage file.
    userUser to access database.
    passwdPassword to access database.
    namespaceNamespace to be associated with the database. This field is altered by changing the workspace name.
    max connectionsMaximum amount of open connections to the database.
    min connectionsMinimum number of pooled connections.
    fetch sizeNumber of records read with each interaction with the database.
    Connection timeoutTime (in seconds) the connection pool will wait before timing out.
    validate connectionsChecks the connection is alive before using it.

    When finished, click Save.

    diff --git a/data/vector/properties/index.html b/data/vector/properties/index.html index 0dfa585949c..274880c7068 100644 --- a/data/vector/properties/index.html +++ b/data/vector/properties/index.html @@ -1937,14 +1937,40 @@

    Adding a Properties data store

    Configuring a Properties data store

    Configuring a Properties data store

    -
    -

    Option Description

    -

    Workspace Sets the namespace prefix of the feature types (layers) and their properties

    -

    Data Source Name Unique identifier to distinguish this data store

    -

    Description Optional text giving a verbose description of the data store

    -

    Enabled Features will be delivered only if this option is checked

    -

    directory Filesystem path to a directory containing one or more property files, for example /usr/local/geoserver/data/ex

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    OptionDescription
    WorkspaceSets the namespace prefix of the feature types (layers) and their properties
    Data Source NameUnique identifier to distinguish this data store
    DescriptionOptional text giving a verbose description of the data store
    EnabledFeatures will be delivered only if this option is checked
    directoryFilesystem path to a directory containing one or more property files, for example /usr/local/geoserver/data/ex

    Every property file TYPENAME.properties in the designated directory is served as a feature type TYPENAME (the name of the file without the .properties), in the namespace of the data store.

    Before a feature type (layer) can be used, you must edit it to ensure that its bounding box and other metadata is configured.

    Property file format

    diff --git a/data/vector/shapefile/index.html b/data/vector/shapefile/index.html index 0b0a62f9413..62f8c832f70 100644 --- a/data/vector/shapefile/index.html +++ b/data/vector/shapefile/index.html @@ -1920,18 +1920,56 @@

    Adding a shapefile

    To begin, navigate to Stores → Add a new store → Shapefile.

    Adding a shapefile as a store

    -
    -

    Option Description

    -

    Workspace Name of the workspace to contain the store. This will also be the prefix of the layer created from the store.

    -

    Data Source Name Name of the shapefile as known to GeoServer. Can be different from the filename. The combination of the workspace name and this name will be the full layer name (ex: topp:states).

    -

    Description Description of the shapefile/store.

    -

    Enabled Enables the store. If unchecked, no data in the shapefile will be served.

    -

    URL Location of the shapefile. Can be an absolute path (such as file:C:\Data\shapefile.shp) or a path relative to the data directory (such as file:data/shapefile.shp.

    -

    namespace Namespace to be associated with the shapefile. This field is altered by changing the workspace name.

    -

    create spatial index Enables the automatic creation of a spatial index.

    -

    charset Character set used to decode strings from the .dbf file.

    -

    memory mapped buffer Cache and reuse memory maps Enables the use of memory mapped I/O, improving caching of the file in memory. Turn off on Windows servers.

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    OptionDescription
    WorkspaceName of the workspace to contain the store. This will also be the prefix of the layer created from the store.
    Data Source NameName of the shapefile as known to GeoServer. Can be different from the filename. The combination of the workspace name and this name will be the full layer name (ex: topp:states).
    DescriptionDescription of the shapefile/store.
    EnabledEnables the store. If unchecked, no data in the shapefile will be served.
    URLLocation of the shapefile. Can be an absolute path (such as file:C:\Data\shapefile.shp) or a path relative to the data directory (such as file:data/shapefile.shp.
    namespaceNamespace to be associated with the shapefile. This field is altered by changing the workspace name.
    create spatial indexEnables the automatic creation of a spatial index.
    charsetCharacter set used to decode strings from the .dbf file.
    memory mapped buffer Cache and reuse memory mapsEnables the use of memory mapped I/O, improving caching of the file in memory. Turn off on Windows servers.

    When finished, click Save.

    Configuring a shapefile layer

    Shapefiles contain exactly one layer, which needs to be added as a new layer before it will be able to be served by GeoServer. See the section on Layers for how to add and edit a new layer.

    diff --git a/data/webadmin/layers/index.html b/data/webadmin/layers/index.html index 09f289079b3..b6df4d67200 100644 --- a/data/webadmin/layers/index.html +++ b/data/webadmin/layers/index.html @@ -2326,14 +2326,32 @@

    Layers

    Layers View

    Layer types

    Layers can be divided into two types of data: raster and vector. These two formats differ in how they store spatial information. Vector types store information about feature types as mathematical paths---a point as a single x,y coordinate, lines as a series of x,y coordinates, and polygons as a series of x,y coordinates that start and end on the same place. Raster format data is a cell-based representation of features on the earth surface. Each cell has a distinct value, and all cells with the same value represent a specific feature.

    -
    -

    Field Description

    -
    -

    image Raster (grid)

    -

    image Polygon

    -

    image Line

    -

    image Point

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + +
    FieldDescription
    imageRaster (grid)
    imagePolygon
    imageLine
    imagePoint

    Add a Layer

    At the upper left-hand corner of the layers view page there are two buttons for the adding and removal of layers. The green plus button allows you to add a new layer. The red minus button allows you to remove selected layers.

    diff --git a/data/webadmin/stores/index.html b/data/webadmin/stores/index.html index 9f7398f21f2..fde9fa024c2 100644 --- a/data/webadmin/stores/index.html +++ b/data/webadmin/stores/index.html @@ -1995,14 +1995,32 @@

    Stores

    Stores View

    Store types

    While there are many potential formats for data sources, there are only four kinds of stores. For raster data, a store can be a file. For vector data, a store can be a file, database, or server.

    -
    -

    Type Icon Description

    -
    -

    image raster data in a file

    -

    image vector data in a file

    -

    image vector data in a database

    -

    image vector server (web feature server)

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + +
    Type IconDescription
    imageraster data in a file
    imagevector data in a file
    imagevector data in a database
    imagevector server (web feature server)

    Edit a Store

    To view or edit a store, click the store name. A store configuration page will be displayed. The exact contents of this page depend on the specific format of the store. See the sections Vector data, Raster data, and Databases for information about specific data formats. The example shows the configuration for the nurc:ArcGridSample store.

    diff --git a/extensions/authkey/index.html b/extensions/authkey/index.html index 3ff5339f200..2034d2d3228 100644 --- a/extensions/authkey/index.html +++ b/extensions/authkey/index.html @@ -3185,21 +3185,64 @@

    Key provider using a property fileKey provider using an external web service

    This key provider calls an external URL to map the authentication key to the user. This allows GeoServer to integrate into an existing security infrastructure, where a session token is shared among applications and managed through dedicated web services.

    The web service URL and some other parameters can be specified to configure the mapper in detail:

    -
    -

    Option Description

    -

    Web Service URL, with key placeholder the complete URL of the key mapping webservice, with a special placeholder ({key}) that will be replaced by the current authentication key

    -

    Web Service Response User Search Regular Expression a regular expression used to extract the username from the webservice response; the first matched group (the part included in parentheses) in the regular expression will be used as the username; the default (\^\s(.)\s*\$) takes all the response text, trimming spaces at both ends

    -

    Connection Timeout timeout to connect to the webservice

    -

    Read Timeout timeout to read data from the webservice

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    OptionDescription
    Web Service URL, with key placeholderthe complete URL of the key mapping webservice, with a special placeholder ({key}) that will be replaced by the current authentication key
    Web Service Response User Search Regular Expressiona regular expression used to extract the username from the webservice response; the first matched group (the part included in parentheses) in the regular expression will be used as the username; the default (\^\s(.)\s*\$) takes all the response text, trimming spaces at both ends
    Connection Timeouttimeout to connect to the webservice
    Read Timeouttimeout to read data from the webservice

    The mapper will call the webservice using an HTTP GET request (webservice requiring POST are not supported yet), replacing the {key} placeholder in the configured URL with the actual authentication key.

    If a response is received, it is parsed using the configured regular expression to extract the username from it. New lines are automatically stripped from the response. Some examples of regular expression that can be used are:

    -
    -

    Regular Expression Usage

    -

    ^\s*(.*)\s*$ all text trimming spaces at both ends

    -

    ^.*?"user"\s*:\s*"([^"]+)".*$ json response where the username is contained in a property named user

    -

    ^.*?<username>(.*?)</username>.*$ xml response where the username is contained in a tag named username

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + +
    Regular ExpressionUsage
    ^\s*(.*)\s*$all text trimming spaces at both ends
    ^.*?"user"\s*:\s*"([^"]+)".*$json response where the username is contained in a property named user
    ^.*?<username>(.*?)</username>.*$xml response where the username is contained in a tag named username

    Synchronizing users with the user/group service means clearing the current Security context cache. The keys cached in memory will be removed and re-created at the next call.

    AuthKEY WebService Body Response UserGroup Service

    When using an external web service to get Auth details, it is possible to define a custom GeoServer UserGroup Service being able to fetch Authorities - aka user's Roles - from the HTTP Body Response.

    diff --git a/extensions/cas/index.html b/extensions/cas/index.html index b86e1ef796e..ec9ec615d02 100644 --- a/extensions/cas/index.html +++ b/extensions/cas/index.html @@ -3070,26 +3070,71 @@

    Configuration

    -
    -

    Key Description

    -
    -

    Name Name of the filter

    -

    CAS server URL including context root The CAS server location (GeoServer will redirect to it, for example, in order to login, adding the necessary extra path elements)

    -

    No single sign on If checkecd, will send the "renew=true" options to the CAS server, forcing the user to login on the server at each request (unless session creation is allowed)

    -

    Participate in single sign out Whether GeoServer should receive and handle callbacks for Single Sign Out.

    -

    URL in CAS loutput page CAS logout page location

    -

    Proxy callback URL The URL CAS will call back to after proxy ticket authentication

    -

    Role source A choice of role sources for the user authenticated via CAS

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    KeyDescription
    NameName of the filter
    CAS server URL including context rootThe CAS server location (GeoServer will redirect to it, for example, in order to login, adding the necessary extra path elements)
    No single sign onIf checkecd, will send the "renew=true" options to the CAS server, forcing the user to login on the server at each request (unless session creation is allowed)
    Participate in single sign outWhether GeoServer should receive and handle callbacks for Single Sign Out.
    URL in CAS loutput pageCAS logout page location
    Proxy callback URLThe URL CAS will call back to after proxy ticket authentication
    Role sourceA choice of role sources for the user authenticated via CAS

    Specifically for the role source, the following options are available:

    -
    -

    Source Description

    -
    -

    User group service Locate the user in a the specified user group service, extract the roles from it.

    -

    Role service Locate user roles from the specified role service

    -

    Header attribute Look up the roles in the specified HTTP header of the CAS response

    -

    Custom CAS attribute Extract the roles from a CAS custom attribute in the <cas:serviceResponse> received from the server. The attributes must be configured, on the CAS side, via an attribute repository, and then released for publication in service configuration.

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + +
    SourceDescription
    User group serviceLocate the user in a the specified user group service, extract the roles from it.
    Role serviceLocate user roles from the specified role service
    Header attributeLook up the roles in the specified HTTP header of the CAS response
    Custom CAS attributeExtract the roles from a CAS custom attribute in the <cas:serviceResponse> received from the server. The attributes must be configured, on the CAS side, via an attribute repository, and then released for publication in service configuration.

    Example CAS configuration

    In order to use the CAS custom attributes the server must be configured to extract the attributes from a given attribute repository, and then allow their release in the GeoServer service configuration.

    For example, the following cas.properties file sets up a JDBC user source, as well as JDBC attribute repository (this configuration file might useful for testing purposes, but not setup for production):

    diff --git a/extensions/geofence-server/rest-adminrule/index.html b/extensions/geofence-server/rest-adminrule/index.html index 0ba56182752..8aaac407f2a 100644 --- a/extensions/geofence-server/rest-adminrule/index.html +++ b/extensions/geofence-server/rest-adminrule/index.html @@ -3336,43 +3336,136 @@

    Data Object Transfer

    Filter Parameters

    All filter parameters are optional.

    -
    -

    Name Type Description

    -
    -

    page number Used for paging a list of rules. Specifies the number of the page. Leave out for no paging. If specified, entries should also be specified.

    -

    entries number Used for paging a list of rules. Specifies the number of entries per page. Leave out for no paging. If specified, page should also be specified.

    -

    userName string Filter rules on username (excludes all other specified usernames).

    -

    userAny 0 or 1. Specify whether rules matching any username should be included or not.

    -

    roleName string Filter rules on rolename (excludes all other specified rolenames).

    -

    roleAny 0 or 1. Specify whether rules matching any rolename should be included or not.

    -

    workspace string Filter rules on workspace (excludes all other specified workspaces).

    -

    workspaceAny 0 or 1. Specify whether rules matching any workspace should be included or not.

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    NameTypeDescription
    pagenumberUsed for paging a list of rules. Specifies the number of the page. Leave out for no paging. If specified, entries should also be specified.
    entriesnumberUsed for paging a list of rules. Specifies the number of entries per page. Leave out for no paging. If specified, page should also be specified.
    userNamestringFilter rules on username (excludes all other specified usernames).
    userAny0 or 1.Specify whether rules matching any username should be included or not.
    roleNamestringFilter rules on rolename (excludes all other specified rolenames).
    roleAny0 or 1.Specify whether rules matching any rolename should be included or not.
    workspacestringFilter rules on workspace (excludes all other specified workspaces).
    workspaceAny0 or 1.Specify whether rules matching any workspace should be included or not.

    Requests

    /geofence/rest/adminrules/

    Query all adminrules or add a new adminrule.

    -
    -

    Method Action Supported parameters Response

    -
    -

    GET List all adminrules, with respect to any added filters page, entries, userName, userAny, roleName, roleAny, workspace, workspaceAny 200 OK. List of adminrules in XML.

    -

    POST Add a new adminrule None 201 Inserted. Created ID header.

    -
    + + + + + + + + + + + + + + + + + + + + + + + +
    MethodActionSupported parametersResponse
    GETList all adminrules, with respect to any added filterspage, entries, userName, userAny, roleName, roleAny, workspace, workspaceAny200 OK. List of adminrules in XML.
    POSTAdd a new adminruleNone201 Inserted. Created ID header.

    /geofence/rest/adminrules/count

    Counts (filtered) adminrules.

    -
    -

    Method Action Supported parameters Response

    -
    -

    GET Count all adminrules, with respect to any added filters userName, userAny, roleName, roleAny, workspace, workspaceAny 200 OK. Rule list count in XML.

    -
    + + + + + + + + + + + + + + + + + +
    MethodActionSupported parametersResponse
    GETCount all adminrules, with respect to any added filtersuserName, userAny, roleName, roleAny, workspace, workspaceAny200 OK. Rule list count in XML.

    /geofence/rest/adminrules/id/<id>

    Query, modify or delete a specific adminrule.

    -
    -

    Method Action Supported parameters Response

    -
    -

    GET Read adminrule information None 200 OK. AdminRule in XML.

    -

    POST Modify the adminrule, unspecified fields remain unchanged. None 200 OK.

    -

    DELETE Delete the adminrule None 200 OK.

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    MethodActionSupported parametersResponse
    GETRead adminrule informationNone200 OK. AdminRule in XML.
    POSTModify the adminrule, unspecified fields remain unchanged.None200 OK.
    DELETEDelete the adminruleNone200 OK.
    diff --git a/extensions/geofence-server/rest/index.html b/extensions/geofence-server/rest/index.html index a1e2d7745e3..8807f1ba2c2 100644 --- a/extensions/geofence-server/rest/index.html +++ b/extensions/geofence-server/rest/index.html @@ -3364,49 +3364,166 @@

    Data Object Transfer

    Filter Parameters

    All filter parameters are optional.

    -
    -

    Name Type Description

    -
    -

    page number Used for paging a list of rules. Specifies the number of the page. Leave out for no paging. If specified, entries should also be specified.

    -

    entries number Used for paging a list of rules. Specifies the number of entries per page. Leave out for no paging. If specified, page should also be specified.

    -

    userName string Filter rules on username (excludes all other specified usernames).

    -

    userAny 0 or 1. Specify whether rules for 'any' username are included or not.

    -

    roleName string Filter rules on rolename (excludes all other specified rolenames).

    -

    roleAny 0 or 1. Specify whether rules for 'any' rolename are included or not.

    -

    service string Filter rules on service (excludes all other specified services).

    -

    serviceAny 0 or 1. Specify whether rules for 'any' service are included or not.

    -

    request string Filter rules on request (excludes all other specified requests).

    -

    requestAny 0 or 1. Specify whether rules for 'any' request are included or not.

    -

    workspace string Filter rules on workspace (excludes all other specified workspaces).

    -

    workspaceAny 0 or 1. Specify whether rules for 'any' workspace are included or not.

    -

    layer string Filter rules on layer (excludes all other specified layers).

    -

    layerAny 0 or 1. Specify whether rules for 'any' layer are included or not.

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    NameTypeDescription
    pagenumberUsed for paging a list of rules. Specifies the number of the page. Leave out for no paging. If specified, entries should also be specified.
    entriesnumberUsed for paging a list of rules. Specifies the number of entries per page. Leave out for no paging. If specified, page should also be specified.
    userNamestringFilter rules on username (excludes all other specified usernames).
    userAny0 or 1.Specify whether rules for 'any' username are included or not.
    roleNamestringFilter rules on rolename (excludes all other specified rolenames).
    roleAny0 or 1.Specify whether rules for 'any' rolename are included or not.
    servicestringFilter rules on service (excludes all other specified services).
    serviceAny0 or 1.Specify whether rules for 'any' service are included or not.
    requeststringFilter rules on request (excludes all other specified requests).
    requestAny0 or 1.Specify whether rules for 'any' request are included or not.
    workspacestringFilter rules on workspace (excludes all other specified workspaces).
    workspaceAny0 or 1.Specify whether rules for 'any' workspace are included or not.
    layerstringFilter rules on layer (excludes all other specified layers).
    layerAny0 or 1.Specify whether rules for 'any' layer are included or not.

    Requests

    /rest/geofence/rules/

    Query all rules or add a new rule.

    -
    -

    Method Action Supported parameters Response

    -
    -

    GET List all rules, with respect to any added filters page, entries, userName, userAny, roleName, roleAny, service, serviceAny, request, requestAny, workspace, workspaceAny, layer, layerAny 200 OK. List of rules in XML.

    -

    POST Add a new rule None 201 Inserted. Created ID header.

    -
    + + + + + + + + + + + + + + + + + + + + + + + +
    MethodActionSupported parametersResponse
    GETList all rules, with respect to any added filterspage, entries, userName, userAny, roleName, roleAny, service, serviceAny, request, requestAny, workspace, workspaceAny, layer, layerAny200 OK. List of rules in XML.
    POSTAdd a new ruleNone201 Inserted. Created ID header.

    /rest/geofence/rules/count

    Counts (filtered) rules.

    -
    -

    Method Action Supported parameters Response

    -
    -

    GET Count all rules, with respect to any added filters userName, userAny, roleName, roleAny, service, serviceAny, request, requestAny, workspace, workspaceAny, layer, layerAny 200 OK. Rule list count in XML.

    -
    + + + + + + + + + + + + + + + + + +
    MethodActionSupported parametersResponse
    GETCount all rules, with respect to any added filtersuserName, userAny, roleName, roleAny, service, serviceAny, request, requestAny, workspace, workspaceAny, layer, layerAny200 OK. Rule list count in XML.

    /rest/geofence/rules/id/<id>

    Query, modify or delete a specific rule.

    -
    -

    Method Action Supported parameters Response

    -
    -

    GET Read rule information None 200 OK. Rule in XML.

    -

    POST Modify the rule, unspecified fields remain unchanged. None 200 OK.

    -

    DELETE Delete the rule None 200 OK.

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    MethodActionSupported parametersResponse
    GETRead rule informationNone200 OK. Rule in XML.
    POSTModify the rule, unspecified fields remain unchanged.None200 OK.
    DELETEDelete the ruleNone200 OK.
    diff --git a/extensions/geofence/cache/index.html b/extensions/geofence/cache/index.html index 580e09cf041..6f29400228a 100644 --- a/extensions/geofence/cache/index.html +++ b/extensions/geofence/cache/index.html @@ -3119,18 +3119,44 @@

    GeoFence Cache REST

    Requests

    /geofence/ruleCache/info

    Retrieve information about the geofence cache status.

    -
    -

    Method Action Parameters Response

    -
    -

    GET Retrieve information about the geofence cache status. Per cache (rules, admin rules and users) we retrieve the cache size, hits, misses, load successes, load failures, load times and evictions. --- 200 OK. Text Format.

    -
    + + + + + + + + + + + + + + + + + +
    MethodActionParametersResponse
    GETRetrieve information about the geofence cache status. Per cache (rules, admin rules and users) we retrieve the cache size, hits, misses, load successes, load failures, load times and evictions.---200 OK. Text Format.

    /geofence/ruleCache/invalidate

    Invalidate the geofence cache.

    -
    -

    Method Action Parameters Response

    -
    -

    PUT Invalidate (clear) the geofence cache --- 200 OK.

    -
    + + + + + + + + + + + + + + + + + +
    MethodActionParametersResponse
    PUTInvalidate (clear) the geofence cache---200 OK.
    diff --git a/extensions/geopkg-output/usage/index.html b/extensions/geopkg-output/usage/index.html index e5625de303b..6c58d0f0154 100644 --- a/extensions/geopkg-output/usage/index.html +++ b/extensions/geopkg-output/usage/index.html @@ -3197,58 +3197,53 @@

    WMS

    WMS Format options

    You can also add format options (format_options=param1:value1;param2:value2;...) to the request. With all default values, you will get a GeoPackage with PNG tiles of multiple resolutions. There will be a little more than 255 total tiles - all occupying the area in the request's bbox.

    -
    -
    +--------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------+
    -
    | Parameter | Description |
    -
    +==============+=============================================================================================================================================================+
    -
    | min_zoom | Grid Zoom level for tiles to start. |
    -
    | | |
    -
    | | default: zoom level based on a single tile covering the bbox area. |
    -
    +--------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------+
    -
    | max_zoom | Grid Zoom level for tiles to end. |
    -
    | | |
    -
    | | default: zoom where there's >255 tiles in total in the geopkg (could be a bit more) |
    -
    +--------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------+
    -
    | num_zooms | Number of zoom levels in the geopkg. |
    -
    | | |
    -
    | | If present then max_zoom = min_zoom + num_zooms |
    -
    +--------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------+
    -
    | format | Format for the image tiles in the geopkg. |
    -
    | | |
    -
    | | default: PNG |
    -
    +--------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------+
    -
    | tileset_name | Name of tile set ("layer") used in the geopkg. |
    -
    | | |
    -
    | | default: based on the layer names given in the request ('_' separated) |
    -
    +--------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------+
    -
    | min_column | First column number (from the gridset) to use. |
    -
    | | |
    -
    | | default: use request bbox to determine which tiles to produce |
    -
    +--------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------+
    -
    | max_column | Last column number (from the gridset) to use. |
    -
    | | |
    -
    | | default: use request bbox to determine which tiles to produce |
    -
    +--------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------+
    -
    | min_row | First row number (from the gridset) to use. |
    -
    | | |
    -
    | | default: use request bbox to determine which tiles to produce |
    -
    +--------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------+
    -
    | max_row | Last row number (from the gridset) to use. |
    -
    | | |
    -
    | | default: use request bbox to determine which tiles to produce |
    -
    +--------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------+
    -
    | gridset | Name of the gridset (from GWC GridSetBroker) to uses. |
    -
    | | |
    -
    | | default: find based on request SRS |
    -
    +--------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------+
    -
    | flipy | Do NOT set. |
    -
    | | |
    -
    | | default: TRUE (required for GeoPackage - The tile coordinate (0,0) always refers to the tile in the upper left corner of the tile matrix\...) |
    -
    +--------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------+
    -
    -

    Format Options

    -
    -
    +

    +--------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------+ +| Parameter | Description | ++==============+=============================================================================================================================================================+ +| min_zoom | Grid Zoom level for tiles to start. | +| | | +| | default: zoom level based on a single tile covering the bbox area. | ++--------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------+ +| max_zoom | Grid Zoom level for tiles to end. | +| | | +| | default: zoom where there's >255 tiles in total in the geopkg (could be a bit more) | ++--------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------+ +| num_zooms | Number of zoom levels in the geopkg. | +| | | +| | If present then max_zoom = min_zoom + num_zooms | ++--------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------+ +| format | Format for the image tiles in the geopkg. | +| | | +| | default: PNG | ++--------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------+ +| tileset_name | Name of tile set ("layer") used in the geopkg. | +| | | +| | default: based on the layer names given in the request ('_' separated) | ++--------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------+ +| min_column | First column number (from the gridset) to use. | +| | | +| | default: use request bbox to determine which tiles to produce | ++--------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------+ +| max_column | Last column number (from the gridset) to use. | +| | | +| | default: use request bbox to determine which tiles to produce | ++--------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------+ +| min_row | First row number (from the gridset) to use. | +| | | +| | default: use request bbox to determine which tiles to produce | ++--------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------+ +| max_row | Last row number (from the gridset) to use. | +| | | +| | default: use request bbox to determine which tiles to produce | ++--------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------+ +| gridset | Name of the gridset (from GWC GridSetBroker) to uses. | +| | | +| | default: find based on request SRS | ++--------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------+ +| flipy | Do NOT set. | +| | | +| | default: TRUE (required for GeoPackage - The tile coordinate (0,0) always refers to the tile in the upper left corner of the tile matrix\...) | ++--------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------+

    diff --git a/extensions/grib/grib/index.html b/extensions/grib/grib/index.html index 2f84cb9fd6e..8d3e847420b 100644 --- a/extensions/grib/grib/index.html +++ b/extensions/grib/grib/index.html @@ -3048,14 +3048,40 @@

    Adding a GRIB data store

    Configuring a GRIB data store

    Configuring a GRIB data store

    -
    -

    Option Description

    -

    Workspace

    -

    Data Source Name

    -

    Description

    -

    Enabled

    -

    URL

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    OptionDescription
    Workspace
    Data Source Name
    Description
    Enabled
    URL

    Relationship with NetCDF

    Note

    diff --git a/extensions/importer/rest_reference/index.html b/extensions/importer/rest_reference/index.html index 1f8aa8f50a5..af504a3db9c 100644 --- a/extensions/importer/rest_reference/index.html +++ b/extensions/importer/rest_reference/index.html @@ -4214,13 +4214,32 @@

    Creating a new import

    }
  • The parameters are:

    -
    -

    Name Optional Description

    -
    -

    targetWorkspace Y The target workspace to import to

    -

    targetStore Y The target store to import to

    -

    data Y The data to be imported

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + +
    NameOptionalDescription
    targetWorkspaceYThe target workspace to import to
    targetStoreYThe target store to import to
    dataYThe data to be imported

    The mere creation does not start the import, but it may automatically populate its tasks depending on the target. For example, by referring a directory of shapefiles to be importer, the creation will automatically fill in a task to import each of the shapefiles as a new layer.

    The response to the above POST request will be:

    Status: 201 Created
    diff --git a/extensions/monitoring/query/index.html b/extensions/monitoring/query/index.html
    index 1bf943878ac..c8d3dde6dfb 100644
    --- a/extensions/monitoring/query/index.html
    +++ b/extensions/monitoring/query/index.html
    @@ -3533,55 +3533,117 @@ 

    Request Set Query

    The request set query accepts various parameters that control what requests are returned and how they are sorted. The available parameters are:

    count Parameter

    Specifies how many records should be returned.

    -
    -

    Syntax Example

    -
    -

    count=<integer> requests.html?count=100

    -
    + + + + + + + + + + + + + +
    SyntaxExample
    count=<integer>requests.html?count=100

    offset Parameter

    Specifies where in the result set records should be returned from.

    -
    -

    Syntax Example

    -
    -

    offset=<integer> requests.html?count=100&offset=500

    -
    + + + + + + + + + + + + + +
    SyntaxExample
    offset=<integer>requests.html?count=100&offset=500

    live Parameter

    Specifies that only live (currently executing) requests be returned.

    -
    -

    Syntax Example

    -
    -

    live=<yes|no|true|false> requests.html?live=yes

    -
    + + + + + + + + + + + + + +
    SyntaxExample
    live=<yes|no|true|false>requests.html?live=yes

    This parameter relies on a Monitor Mode being used that maintains real time request information (either live or mixed).

    from Parameter

    Specifies an inclusive lower bound on the timestamp for the start of a request. The timestamp can be specified to any desired precision.

    -
    -

    Syntax Example

    -
    -

    from=<timestamp> requests.html?from=2010-07-23T16:16:44

    -
                               requests.html?from=2010-07-23
    -
    -
    + + + + + + + + + + + + + + + + + +
    SyntaxExample
    from=<timestamp>requests.html?from=2010-07-23T16:16:44
    requests.html?from=2010-07-23

    to Parameter

    Specifies an inclusive upper bound on the timestamp for the start of a request. The timestamp can be specified to any desired precision.

    -
    -

    Syntax Example

    -
    -

    to=<timestamp> requests.html?to=2010-07-24T00:00:00

    -
                               requests.html?to=2010-07-24
    -
    -
    + + + + + + + + + + + + + + + + + +
    SyntaxExample
    to=<timestamp>requests.html?to=2010-07-24T00:00:00
    requests.html?to=2010-07-24

    order Parameter

    Specifies which request attribute to sort by, and optionally specifies the sort direction.

    -
    -

    Syntax Example

    -
    -

    order=<attribute>[;<ASC|DESC>] requests.html?order=path

    -
                                     requests.html?order=startTime;DESC
    -
    -                                 requests.html?order=totalTime;ASC
    -
    -
    + + + + + + + + + + + + + + + + + + + + + +
    SyntaxExample
    order=<attribute>[;<ASC|DESC>]requests.html?order=path
    requests.html?order=startTime;DESC
    requests.html?order=totalTime;ASC
    diff --git a/extensions/monitoring/reference/index.html b/extensions/monitoring/reference/index.html index 8b591638846..2d5d0c25143 100644 --- a/extensions/monitoring/reference/index.html +++ b/extensions/monitoring/reference/index.html @@ -3273,18 +3273,57 @@

    Data Reference

    The following is a list of all the attributes of a request that are captured by the monitor extension.

    General

    -
    -

    Attribute Description Type

    -
    -

    ID Numeric identifier of the request. Every request is assigned an identifier upon its creation. Numeric

    -

    Status Status of the request. See notes below. String

    -

    Category The type of request being made, for example an OGC service request, a REST call, etc... See notes below. String

    -

    Start time The time of the start of the request. Timestamp

    -

    End time The time of the completion of the request. Timestamp

    -

    Total time The total time spent handling the request, measured in milliseconds, equal to the end time - start time. Numeric

    -

    Error message The exception message if the request failed or resulted in an error. String

    -

    Error The raw exception if the message failed or resulted in an error. Text blob

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    AttributeDescriptionType
    IDNumeric identifier of the request. Every request is assigned an identifier upon its creation.Numeric
    StatusStatus of the request. See notes below.String
    CategoryThe type of request being made, for example an OGC service request, a REST call, etc... See notes below.String
    Start timeThe time of the start of the request.Timestamp
    End timeThe time of the completion of the request.Timestamp
    Total timeThe total time spent handling the request, measured in milliseconds, equal to the end time - start time.Numeric
    Error messageThe exception message if the request failed or resulted in an error.String
    ErrorThe raw exception if the message failed or resulted in an error.Text blob

    Status

    The status of a request changes over it's life cycle and may have one of the following values:

      @@ -3304,58 +3343,206 @@

      Category

    HTTP

    The following attributes are all HTTP related.

    -
    -

    Attribute Description Type

    -
    -

    HTTP method The HTTP method, one of GET, POST, PUT, or DELETE String

    -

    Remote address The IP address of the client from which the request originated. String

    -

    Remote host The hostname corresponding to the remote address, obtained via reverse DNS lookup. String

    -

    Host The hostname of the server handling the request, from the point of view of the client. String

    -

    Internal host The hostname of the server handling request, from the point of view of the local network. Availability depends on host and network configuration. String

    -

    Path The path component of the request URL, for example: "/wms", "/rest/workspaces.xml", etc... String

    -

    Query string The query string component of the request URL. Typically only present when the HTTP method is GET. String

    -

    Body The body content of the request. Typically only present when the HTTP method is PUT or POST. Binary blob

    -

    Body content length The total number of bytes comprising the body of the request. Typically only present when the HTTP method is PUT or POST. Numeric

    -

    Body content type The mime type of the body content of the request, for example: "application/json", "text/xml; subtype=gml/3.2", etc... Typically only present when the HTTP method is PUT or POST. String

    -

    Response status The HTTP response code, for example: 200, 401, etc... Numeric

    -

    Response length The total number of bytes comprising the response to the request. Numeric

    -

    Response content type The mime type of the response to the request. String

    -

    Remote user The username specified parsed of the request. Only available when request included credentials for authentication. String

    -

    Remote user agent The value of the User-Agent HTTP header. String

    -

    Http referrer The value of the Referer HTTP header. String

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    AttributeDescriptionType
    HTTP methodThe HTTP method, one of GET, POST, PUT, or DELETEString
    Remote addressThe IP address of the client from which the request originated.String
    Remote hostThe hostname corresponding to the remote address, obtained via reverse DNS lookup.String
    HostThe hostname of the server handling the request, from the point of view of the client.String
    Internal hostThe hostname of the server handling request, from the point of view of the local network. Availability depends on host and network configuration.String
    PathThe path component of the request URL, for example: "/wms", "/rest/workspaces.xml", etc...String
    Query stringThe query string component of the request URL. Typically only present when the HTTP method is GET.String
    BodyThe body content of the request. Typically only present when the HTTP method is PUT or POST.Binary blob
    Body content lengthThe total number of bytes comprising the body of the request. Typically only present when the HTTP method is PUT or POST.Numeric
    Body content typeThe mime type of the body content of the request, for example: "application/json", "text/xml; subtype=gml/3.2", etc... Typically only present when the HTTP method is PUT or POST.String
    Response statusThe HTTP response code, for example: 200, 401, etc...Numeric
    Response lengthThe total number of bytes comprising the response to the request.Numeric
    Response content typeThe mime type of the response to the request.String
    Remote userThe username specified parsed of the request. Only available when request included credentials for authentication.String
    Remote user agentThe value of the User-Agent HTTP header.String
    Http referrerThe value of the Referer HTTP header.String

    OWS/OGC

    The following attributes are OGC service specific.

    -
    -

    Attribute Description Type

    -
    -

    Service The OGC service identifier, for example: "WMS", "WFS", etc... String

    -

    Operation The OGC operation name, for example: "GetMap", "GetFeature", etc... String

    -

    Sub operation The ogc sub operation (if it applies). For instance when the operation is a WFS Transaction the sub operation may be one of "Insert", "Update", etc... String

    -

    OWS/OGC Version The OGC service version, for example with WFS the version may be "1.0.0", "1.1.0", etc... String

    -

    Resources Names of resources (layers, processes, etc...) specified as part of the request. List of String

    -

    Resources processing times in milliseconds. Rendering times for resources. Rendering is performed by two concurrent threads, one reading and preprocessing data and styles towards a Java2D compatible format, the other painting the results of the first on the canvas. When the first thread starts reading the next layer, the second thread is likely still painting features from the layer before it, thus, times in this list are overlapping with each other, and the sum will be greater than the actual wall rendering time. List of Numeric

    -

    Labels Processing Time Processing time in milliseconds for the labels of all resources listed. Numeric

    -

    Bounding box The bounding box specified as part of the request. In some cases this is not possible to obtain this reliable, an example being a complex WFS query with a nested "BBOX" filter. List of Numeric

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    AttributeDescriptionType
    ServiceThe OGC service identifier, for example: "WMS", "WFS", etc...String
    OperationThe OGC operation name, for example: "GetMap", "GetFeature", etc...String
    Sub operationThe ogc sub operation (if it applies). For instance when the operation is a WFS Transaction the sub operation may be one of "Insert", "Update", etc...String
    OWS/OGC VersionThe OGC service version, for example with WFS the version may be "1.0.0", "1.1.0", etc...String
    ResourcesNames of resources (layers, processes, etc...) specified as part of the request.List of String
    Resources processing times in milliseconds.Rendering times for resources. Rendering is performed by two concurrent threads, one reading and preprocessing data and styles towards a Java2D compatible format, the other painting the results of the first on the canvas. When the first thread starts reading the next layer, the second thread is likely still painting features from the layer before it, thus, times in this list are overlapping with each other, and the sum will be greater than the actual wall rendering time.List of Numeric
    Labels Processing TimeProcessing time in milliseconds for the labels of all resources listed.Numeric
    Bounding boxThe bounding box specified as part of the request. In some cases this is not possible to obtain this reliable, an example being a complex WFS query with a nested "BBOX" filter.List of Numeric

    GeoIP

    The following attributes are specific to GeoIP look ups and are not captured out of the box. See GeoIP for more details.

    -
    -

    Attribute Description Type

    -
    -

    Remote country Name of the country of the client from which the request originated. String

    -

    Remote city Name of the city from which the request originated. String

    -

    Remote lat The latitude from which the request originated. Numeric

    -

    Remote lon The longitude from which the request originated. Numeric

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    AttributeDescriptionType
    Remote countryName of the country of the client from which the request originated.String
    Remote cityName of the city from which the request originated.String
    Remote latThe latitude from which the request originated.Numeric
    Remote lonThe longitude from which the request originated.Numeric

    GWC

    The following attributes are specific to tile cached requests.

    -
    -

    Attribute Description Type

    -
    -

    CacheResult "HIT" or "MISS" (can be empty if GWC was not involved) String

    -

    MissReason A description of why the cache was not used. Available only on requests hitting a cached layer on direct WMS integration, applies to cases where the request was not forwarded to GWC, for example "no parameter filter exists for FEATUREID", "request does not align to grid(s) "EPSG:4326" or "not a tile layer". Will be missing for any request not hitting the direct integration (e.g., direct WMTS requests, for example) String

    -
    + + + + + + + + + + + + + + + + + + + + +
    AttributeDescriptionType
    CacheResult"HIT" or "MISS" (can be empty if GWC was not involved)String
    MissReasonA description of why the cache was not used. Available only on requests hitting a cached layer on direct WMS integration, applies to cases where the request was not forwarded to GWC, for example "no parameter filter exists for FEATUREID", "request does not align to grid(s) "EPSG:4326" or "not a tile layer". Will be missing for any request not hitting the direct integration (e.g., direct WMTS requests, for example)String
    diff --git a/extensions/netcdf/netcdf/index.html b/extensions/netcdf/netcdf/index.html index f66af180ae8..886e70a5ca1 100644 --- a/extensions/netcdf/netcdf/index.html +++ b/extensions/netcdf/netcdf/index.html @@ -3246,14 +3246,40 @@

    Adding a NetCDF data store

    Configuring a NetCDF data store

    Configuring a NetCDF data store

    -
    -

    Option Description

    -

    Workspace

    -

    Data Source Name

    -

    Description

    -

    Enabled

    -

    URL

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    OptionDescription
    Workspace
    Data Source Name
    Description
    Enabled
    URL

    Notes on supported NetCDFs

    The NetCDF plugin for GeoServer supports gridded NetCDF files having dimensions following the COARDS convention (custom, Time, Elevation, Lat, Lon). The NetCDF plugin supports plain NetCDF datasets (.nc files) as well .ncml files (which aggregate and/or modify one or more datasets) and Feature Collections. It supports Forecast Model Run Collection Aggregations (FMRC) either through the NCML or Feature Collection syntax. It supports an unlimited amount of custom dimensions, including runtime.

    ToolsUI is an useful java tool developed by UCAR which can be useful for a preliminary check on your dataset. Opening a sample NetCDF using that tool will show an output like this in the Viewer tab:

    diff --git a/extensions/params-extractor/usage/index.html b/extensions/params-extractor/usage/index.html index 02cd0568f46..37818a0c34d 100644 --- a/extensions/params-extractor/usage/index.html +++ b/extensions/params-extractor/usage/index.html @@ -3173,12 +3173,32 @@

    Echo Parameter Rules

    Basic Rules

    Basic rules allow us to handle simple uses cases where we only want to extract a parameter from the URL.

    A basic rule is defined by three mandatory attributes:

    -
    -

    Attribute Description

    -

    Position The position of the URL base path element to be selected

    -

    Parameter The name of the parameter produced by this rule

    -

    Transform Expression that defines the value of the parameter, use {PARAMETER} as a placeholder for the selected path element

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + +
    AttributeDescription
    PositionThe position of the URL base path element to be selected
    ParameterThe name of the parameter produced by this rule
    TransformExpression that defines the value of the parameter, use {PARAMETER} as a placeholder for the selected path element

    For commodity is also possible when defining this type of rules to configure that an existing parameter in the URL should be echoed to a get capabilities result.

    Example of a basic rule:

    @@ -3192,16 +3212,57 @@

    Basic Rules

    Advanced Rules

    Advanced rules allow us to handle more complex uses cases where more flexibility is required.

    An advanced rule is defined by three mandatory attributes and four optional ones:

    -
    -

    Attribute Description Mandatory

    -

    Match Regex match expression with groups, for example \^(?:/[\^/]){3}(/([\^/]+)).\$ selects the URL base path third element Yes

    -

    Activation If defined this rule will only be applied to URLs that match this regex expression No

    -

    Parameter The name of the parameter produced by this rule Yes

    -

    Transform Expression that defines the value of the parameter, use \$1 ... \$n as placeholders for groups defined in the match expression Yes

    -

    Remove The match expression group to be removed from URL, by default 1 No

    -

    Combine Defines how to combine parameter existing value (\$1 existing value, \$2 new value), by default the value is overridden No

    -

    Repeat If defined, Combine is applied not only once, but for every layer included in the LAYERS parameter, this allows filling parameters that require a value for each layer (e.g. STYLES or CQL_FILTER) No

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    AttributeDescriptionMandatory
    MatchRegex match expression with groups, for example \^(?:/[\^/]){3}(/([\^/]+)).\$ selects the URL base path third elementYes
    ActivationIf defined this rule will only be applied to URLs that match this regex expressionNo
    ParameterThe name of the parameter produced by this ruleYes
    TransformExpression that defines the value of the parameter, use \$1 ... \$n as placeholders for groups defined in the match expressionYes
    RemoveThe match expression group to be removed from URL, by default 1No
    CombineDefines how to combine parameter existing value (\$1 existing value, \$2 new value), by default the value is overriddenNo
    RepeatIf defined, Combine is applied not only once, but for every layer included in the LAYERS parameter, this allows filling parameters that require a value for each layer (e.g. STYLES or CQL_FILTER)No

    For commodity is also possible when defining this type of rules to configure that an existing parameter in the URL should be echoed to a get capabilities result.

    Example of an advanced rule:

    diff --git a/extensions/querylayer/index.html b/extensions/querylayer/index.html index a4ae67cf6c2..c094ca295b9 100644 --- a/extensions/querylayer/index.html +++ b/extensions/querylayer/index.html @@ -3119,12 +3119,37 @@

    Installing the querylayer module

    Function reference

    The extension provides the following filter functions to support cross-layer filtering.

    -
    -

    Name Arguments Description

    -

    querySingle layer : String, attribute : String, filter : String Queries the specified layer applying the specified ECQL filter and returns the value of attribute from the first feature in the result set. The layer name must be qualified (e.g. topp:states). If no filtering is desired use the filter INCLUDE.

    -

    queryCollection layer : String, attribute : String, filter : String Queries the specified layer applying the specified ECQL filter and returns a list containing the value of attribute for every feature in the result set. The layer name must be qualified (e.g. topp:states). If no filtering is desired use the filter INCLUDE. An exception is thrown if too many results are collected (see Memory Limits).

    -

    collectGeometries geometries: a list of Geometry objects Converts a list of geometries into a single Geometry object. The output of queryCollection must be converted by this function in order to use it in spatial filter expressions (since geometry lists cannot be used directly). An exception is thrown if too many coordinates are collected (see Memory Limits).

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    NameArgumentsDescription
    querySinglelayer : String, attribute : String, filter : StringQueries the specified layer applying the specified ECQL filter and returns the value of attribute from the first feature in the result set. The layer name must be qualified (e.g. topp:states). If no filtering is desired use the filter INCLUDE.
    queryCollectionlayer : String, attribute : String, filter : StringQueries the specified layer applying the specified ECQL filter and returns a list containing the value of attribute for every feature in the result set. The layer name must be qualified (e.g. topp:states). If no filtering is desired use the filter INCLUDE. An exception is thrown if too many results are collected (see Memory Limits).
    collectGeometriesgeometries: a list of Geometry objectsConverts a list of geometries into a single Geometry object. The output of queryCollection must be converted by this function in order to use it in spatial filter expressions (since geometry lists cannot be used directly). An exception is thrown if too many coordinates are collected (see Memory Limits).

    Optimizing performance

    In the GeoServer 2.1.x series, in order to have cross-layer filters execute with optimal performance it is necessary to specify the following system variable when starting the JVM:

    -Dorg.geotools.filter.function.simplify=true
    diff --git a/extensions/wmts-multidimensional/usage/index.html b/extensions/wmts-multidimensional/usage/index.html
    index fe5d5280980..035b97e41fc 100644
    --- a/extensions/wmts-multidimensional/usage/index.html
    +++ b/extensions/wmts-multidimensional/usage/index.html
    @@ -3210,30 +3210,91 @@ 

    GetCapabilities

    Descriptions for the new introduced operations and associated formats will also be added to the capabilities document.

    Operations

    This module adds three new operations to the WMTS service that are described in detail in this document:

    -
    -

    Operation Description

    -
    -

    DescribeDomains Describes all the dimension domains in a compact document, along with the restricted bounding box of the two dimensional space intercepted by the request.

    -

    GetDomainValues Allows to page through domain values (supplements DescribeDomains in case the domain has too many values, and the client still wants to get all of them, one page at a time)

    -

    GetHistogram Given a scattered domain description and an interval, this operation divides the interval in regular buckets, and provides an item count for each bucket.

    -

    GetFeature Enumerate the actual dimension possible values combinations, returns a list of features along with dimension values using the same formats as the feature info operation ("application/gml+xml; version=3.1").

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + +
    OperationDescription
    DescribeDomainsDescribes all the dimension domains in a compact document, along with the restricted bounding box of the two dimensional space intercepted by the request.
    GetDomainValuesAllows to page through domain values (supplements DescribeDomains in case the domain has too many values, and the client still wants to get all of them, one page at a time)
    GetHistogramGiven a scattered domain description and an interval, this operation divides the interval in regular buckets, and provides an item count for each bucket.
    GetFeatureEnumerate the actual dimension possible values combinations, returns a list of features along with dimension values using the same formats as the feature info operation ("application/gml+xml; version=3.1").

    Note that currently there is no restful implementations of this operations.

    DescribeDomains

    This operation is useful to understand which domains are available in our layer dimensions and how they relate to each other. The parameters available for this operation are:

    -
    -

    Name Mandatory Description

    -
    -

    Service=WMTS Yes Service type identifier

    -

    Request=DescribeDomains Yes Operation name

    -

    Version=1.0.0 Yes Standard and schema version for this operation

    -

    Layer Yes Layer identifier

    -

    TileMatrixSet Yes Tile matrix set identifier

    -

    bbox=minx,miny,maxx,maxy No Bounding box corners (lower left, upper right) in CRS units

    -

    DimensionIdentifier No At most one per dimension, a range described as min/max, restricting the domain of this dimension

    -

    Domains No A comma separated list of domain names to be returned, in case only a subset is required. The space domain is identified by "bbox".

    -

    ExpandLimit No A numerical value, greater or equal to zero. If the number of unique domain values is below ExpandLimit then the domain with be represented in full, as a comma separated list of values, otherwise in compact form, as start--end. The server assumes a built-in limit of 200 in case not specified, and allows client to specify a value up to 10000, values can be tuned via the user interface, in the WMTS panel (server defaults) and on a layer by layer basis.

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    NameMandatoryDescription
    Service=WMTSYesService type identifier
    Request=DescribeDomainsYesOperation name
    Version=1.0.0YesStandard and schema version for this operation
    LayerYesLayer identifier
    TileMatrixSetYesTile matrix set identifier
    bbox=minx,miny,maxx,maxyNoBounding box corners (lower left, upper right) in CRS units
    DimensionIdentifierNoAt most one per dimension, a range described as min/max, restricting the domain of this dimension
    DomainsNoA comma separated list of domain names to be returned, in case only a subset is required. The space domain is identified by "bbox".
    ExpandLimitNoA numerical value, greater or equal to zero. If the number of unique domain values is below ExpandLimit then the domain with be represented in full, as a comma separated list of values, otherwise in compact form, as start--end. The server assumes a built-in limit of 200 in case not specified, and allows client to specify a value up to 10000, values can be tuned via the user interface, in the WMTS panel (server defaults) and on a layer by layer basis.

    Configuration domain expansion limits.

    The bbox parameter allows the client to restrict the DescribeDomains operation to a certain spatial area, by default the layer extent will be used.

    @@ -3328,21 +3389,72 @@

    DescribeDomains

    GetDomainValues

    This operation is useful to page through the values of a given domain, in case the "multidimensional" area of interest is too large for DescribeDomain to return them in a single shot.

    -
    -

    Name Mandatory Description

    -
    -

    Service=WMTS Yes Service type identifier

    -

    Request=GetDomainValues Yes Operation name

    -

    Version=1.0.0 Yes Standard and schema version for this operation

    -

    Layer Yes Layer identifier

    -

    bbox=minx,miny,maxx,maxy No Bounding box corners (lower left, upper right) in CRS units

    -

    DimensionIdentifier No At most one per dimension, a range described as min/max, restricting the domain of this dimension

    -

    Domain Yes Name of the domain whose values will be returned (one cannot use "bbox", only single value dimensions can be enumerated by GetDomainValues, e.g., time, elevation).

    -

    FromValue No Sets the beginning of domain enumeration, for paging purposes. It's not included in the result

    -

    FromEnd No If equals to true specifies that the beginning of domain enumeration, set by the FromValue, should be applied to the end attribute. When set to true results will be sorted by end attribute.

    -

    Sort No Can be "asc" or "desc", determines if the enumeration is from low to high, or from high to low

    -

    Limit No Maximum number of values returned by this call. The server assumes a built-in limit of 1000 in case not specified, and allows client to specify a value up to 10000.

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    NameMandatoryDescription
    Service=WMTSYesService type identifier
    Request=GetDomainValuesYesOperation name
    Version=1.0.0YesStandard and schema version for this operation
    LayerYesLayer identifier
    bbox=minx,miny,maxx,maxyNoBounding box corners (lower left, upper right) in CRS units
    DimensionIdentifierNoAt most one per dimension, a range described as min/max, restricting the domain of this dimension
    DomainYesName of the domain whose values will be returned (one cannot use "bbox", only single value dimensions can be enumerated by GetDomainValues, e.g., time, elevation).
    FromValueNoSets the beginning of domain enumeration, for paging purposes. It's not included in the result
    FromEndNoIf equals to true specifies that the beginning of domain enumeration, set by the FromValue, should be applied to the end attribute. When set to true results will be sorted by end attribute.
    SortNoCan be "asc" or "desc", determines if the enumeration is from low to high, or from high to low
    LimitNoMaximum number of values returned by this call. The server assumes a built-in limit of 1000 in case not specified, and allows client to specify a value up to 10000.

    For example, let's say a "elevation" domain has values 1,2,3 and 5, and that we are paging through it by pages of 2 elements. The client will start without providing a "fromValue", and will then continue using the last value of the previous page as a reference:

    http://localhost:8080/geoserver/gwc/service/wmts?request=GetDomainValues&Version=1.0.0&Layer=sampleLayer&domain=elevation&limit=2
     
    @@ -3427,20 +3539,67 @@

    GetDomainValues

    GetHistogram

    This operation can be used to provide information about the data distribution between the minimum and maximum values of a certain dimension.

    The parameters available for this operation are:

    -
    -

    Name Mandatory Description

    -
    -

    Service=WMTS Yes Service type identifier

    -

    Request=GetHistogram Yes Operation name

    -

    Version=1.0.0 Yes Standard and schema version for this operation

    -

    Layer Yes Layer identifier

    -

    TileMatrixSet Yes Tile matrix set identifier

    -

    BBOX=minx,miny,maxx,maxy No Bounding box corners (lower left, upper right) in CRS units

    -

    DimensionIdentifier No At most one per dimension, a range described as min/max, restricting the domain of this dimension

    -

    Histogram Yes Name of the dimension for which the histogram will be computed

    -

    Resolution No Suggested size of the histogram bucket. Cannot be provided for enumerated dimensions, will use the period syntax for time (e.g. PT1H), a number for numeric dimensions, or auto to leave the decision to the server

    -

    Format No The desired output format, default is text/html.

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    NameMandatoryDescription
    Service=WMTSYesService type identifier
    Request=GetHistogramYesOperation name
    Version=1.0.0YesStandard and schema version for this operation
    LayerYesLayer identifier
    TileMatrixSetYesTile matrix set identifier
    BBOX=minx,miny,maxx,maxyNoBounding box corners (lower left, upper right) in CRS units
    DimensionIdentifierNoAt most one per dimension, a range described as min/max, restricting the domain of this dimension
    HistogramYesName of the dimension for which the histogram will be computed
    ResolutionNoSuggested size of the histogram bucket. Cannot be provided for enumerated dimensions, will use the period syntax for time (e.g. PT1H), a number for numeric dimensions, or auto to leave the decision to the server
    FormatNoThe desired output format, default is text/html.

    The parameters common to the DescribeDomains operation work as already described above. Currently only the text/xml output format is supported.

    The following example request the histogram for time dimension with a resolution of 8 hours restricting elevations between 500.0 and 1000.0 meters:

    http://localhost:8080/geoserver/gwc/service/wmts?REQUEST=GetHistogram&Version=1.0.0&Layer=some_layer&TileMatrixSet=EPSG:4326&histogram=time&resolution=PT8H&elevation=500.0/1000.0
    @@ -3471,18 +3630,57 @@ 

    GetHistogram

    GetFeature

    This operation is capable to enumerate the actual possible values combinations. The output of this operation is similar to the output of the WFS 2.0 GetFeature operation which is a list of features along with dimension values using the same formats as the feature info operation. This output can be used to draw the features on a map for example.

    The parameters available for this operation are:

    -
    -

    Name Mandatory Description

    -
    -

    Service=WMTS Yes Service type identifier

    -

    Request=GetFeature Yes Operation name

    -

    Version=1.0.0 Yes Standard and schema version for this operation

    -

    Layer Yes Layer identifier

    -

    TileMatrixSet Yes Tile matrix set identifier

    -

    BBOX=minx,miny,maxx,maxy No Bounding box corners (lower left, upper right) in CRS units

    -

    DimensionIdentifier No At most one per dimension, a range described as min/max, restricting the domain of this dimension

    -

    Format Yes The desired output format

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    NameMandatoryDescription
    Service=WMTSYesService type identifier
    Request=GetFeatureYesOperation name
    Version=1.0.0YesStandard and schema version for this operation
    LayerYesLayer identifier
    TileMatrixSetYesTile matrix set identifier
    BBOX=minx,miny,maxx,maxyNoBounding box corners (lower left, upper right) in CRS units
    DimensionIdentifierNoAt most one per dimension, a range described as min/max, restricting the domain of this dimension
    FormatYesThe desired output format

    The parameters common to the DescribeDomains operation work as already described above. Currently only the application/gml+xml; version=3.1 output format is supported.

    Using the same restrictions parameters we used for the second request used as an example for the DescribeDomains operation a GetFeature request will look like this:

    http://localhost:8080/geoserver/gwc/service/wmts?REQUEST=GetFeature&Version=1.0.0&Layer=some_layer&TileMatrixSet=EPSG:4326&elevation=0/500&time=2016-02-23T03:00:00.000Z
    diff --git a/filter/ecql_reference/index.html b/filter/ecql_reference/index.html
    index 199c0a0ce6f..a25e72b7e16 100644
    --- a/filter/ecql_reference/index.html
    +++ b/filter/ecql_reference/index.html
    @@ -1651,63 +1651,220 @@ 

    Syntax Notes

    Condition

    A filter condition is a single predicate, or a logical combination of other conditions.

    -
    -

    Syntax Description

    -

    Predicate Single predicate expression

    -

    Condition AND | OR Condition Conjunction or disjunction of conditions

    -

    NOT Condition Negation of a condition

    -

    ( | [ Condition ] | ) Bracketing with ( or [ controls evaluation order

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    SyntaxDescription
    PredicateSingle predicate expression
    Condition ANDOR Condition
    NOT ConditionNegation of a condition
    ([ Condition ]

    Predicate

    Predicates are boolean-valued expressions which specify relationships between values.

    -
    -

    Syntax Description

    -

    Expression = | <> | < | <= | > | >= Expression Comparison operations

    -

    Expression [ NOT ] BETWEEN Expression AND Expression Tests whether a value lies in or outside a range (inclusive)

    -

    Expression [ NOT ] LIKE | ILIKE like-pattern Simple pattern matching. like-pattern uses the % character as a wild-card for any number of characters. ILIKE does case-insensitive matching.

    -

    Attribute [ NOT ] IN ( Expression { ,Expression } ) Tests whether an attribute value is (not) in a set of values.

    -

    [ NOT ] IN ( Literal { ,Literal } ) Tests whether a feature ID value is (not) in a given set. ID values are integers or string literals

    -

    Expression IS [ NOT ] NULL Tests whether a value is (non-)null

    -

    Attribute EXISTS | DOES-NOT-EXIST Tests whether a featuretype does (not) have a given attribute

    -

    INCLUDE | EXCLUDE Always include (exclude) features to which this filter is applied

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    SyntaxDescription
    Expression =<>
    Expression [ NOT ] BETWEEN Expression AND ExpressionTests whether a value lies in or outside a range (inclusive)
    Expression [ NOT ] LIKEILIKE like-pattern
    Attribute [ NOT ] IN ( Expression { ,Expression } )Tests whether an attribute value is (not) in a set of values.
    [ NOT ] IN ( Literal { ,Literal } )Tests whether a feature ID value is (not) in a given set. ID values are integers or string literals
    Expression IS [ NOT ] NULLTests whether a value is (non-)null
    Attribute EXISTS **** DOES-NOT-EXIST
    INCLUDEEXCLUDE

    Temporal Predicate

    Temporal predicates specify the relationship of a time-valued expression to a time or time period.

    -
    -

    Syntax Description

    -

    ecql_expr BEFORE Time <ecql_reference.rst#ecql_literal>_ Tests whether a time value is before a point in time

    -

    Expression BEFORE OR DURING Time Period Tests whether a time value is before or during a time period

    -

    Expression DURING Time Period Tests whether a time value is during a time period

    -

    Expression DURING OR AFTER Time Period Tests whether a time value is during or after a time period

    -

    ecql_expr AFTER Time <ecql_reference.rst#ecql_literal>_ Tests whether a time value is after a point in time

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    SyntaxDescription
    ecql_expr BEFORE Time <ecql_reference.rst#ecql_literal>_Tests whether a time value is before a point in time
    Expression BEFORE OR DURING Time PeriodTests whether a time value is before or during a time period
    Expression DURING Time PeriodTests whether a time value is during a time period
    Expression DURING OR AFTER Time PeriodTests whether a time value is during or after a time period
    ecql_expr AFTER Time <ecql_reference.rst#ecql_literal>_Tests whether a time value is after a point in time

    Spatial Predicate

    Spatial predicates specify the relationship between geometric values. Topological spatial predicates (INTERSECTS, DISJOINT, CONTAINS, WITHIN, TOUCHES CROSSES, OVERLAPS and RELATE) are defined in terms of the DE-9IM model described in the OGC Simple Features for SQL specification.

    -
    -

    Syntax Description

    -

    INTERSECTS(Expression , Expression ) Tests whether two geometries intersect. The converse of DISJOINT

    -

    DISJOINT(Expression , Expression ) Tests whether two geometries are disjoint. The converse of INTERSECTS

    -

    CONTAINS(Expression , Expression ) Tests whether the first geometry topologically contains the second. The converse of WITHIN

    -

    WITHIN(Expression , Expression ) Tests whether the first geometry is topologically within the second. The converse of CONTAINS

    -

    TOUCHES(Expression , Expression ) Tests whether two geometries touch. Geometries touch if they have at least one point in common, but their interiors do not intersect.

    -

    CROSSES(Expression , Expression ) Tests whether two geometries cross. Geometries cross if they have some but not all interior points in common

    -

    OVERLAPS(Expression , Expression ) Tests whether two geometries overlap. Geometries overlap if they have the same dimension, have at least one point each not shared by the other, and the intersection of the interiors of the two geometries has the same dimension as the geometries themselves

    -

    EQUALS(Expression , Expression ) Tests whether two geometries are topologically equal

    -

    RELATE( Expression , Expression , pattern ) Tests whether geometries have the spatial relationship specified by a DE-9IM matrix pattern. A DE-9IM pattern is a string of length 9 specified using the characters *TF012. Example: '1*T***T**'

    -

    DWITHIN( Expression , Expression , distance , units ) Tests whether the distance between two geometries is no more than the specified distance. distance is an unsigned numeric value for the distance tolerance. units is one of feet, meters, statute miles, nautical miles, kilometers

    -

    BEYOND( Expression , Expression , distance , units ) Similar to DWITHIN, but tests whether the distance between two geometries is greater than the given distance.

    -

    BBOX ( Expression , Number , Number , Number , Number [ , CRS ] ) Tests whether a geometry intersects a bounding box specified by its minimum and maximum X and Y values. The optional CRS is a string containing an SRS code (For example, 'EPSG:1234'. The default is to use the CRS of the queried layer)

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    SyntaxDescription
    INTERSECTS(Expression , Expression )Tests whether two geometries intersect. The converse of DISJOINT
    DISJOINT(Expression , Expression )Tests whether two geometries are disjoint. The converse of INTERSECTS
    CONTAINS(Expression , Expression )Tests whether the first geometry topologically contains the second. The converse of WITHIN
    WITHIN(Expression , Expression )Tests whether the first geometry is topologically within the second. The converse of CONTAINS
    TOUCHES(Expression , Expression )Tests whether two geometries touch. Geometries touch if they have at least one point in common, but their interiors do not intersect.
    CROSSES(Expression , Expression )Tests whether two geometries cross. Geometries cross if they have some but not all interior points in common
    OVERLAPS(Expression , Expression )Tests whether two geometries overlap. Geometries overlap if they have the same dimension, have at least one point each not shared by the other, and the intersection of the interiors of the two geometries has the same dimension as the geometries themselves
    EQUALS(Expression , Expression )Tests whether two geometries are topologically equal
    RELATE( Expression , Expression , pattern )Tests whether geometries have the spatial relationship specified by a DE-9IM matrix pattern. A DE-9IM pattern is a string of length 9 specified using the characters *TF012. Example: '1*T***T**'
    DWITHIN( Expression , Expression , distance , units )Tests whether the distance between two geometries is no more than the specified distance. distance is an unsigned numeric value for the distance tolerance. units is one of feet, meters, statute miles, nautical miles, kilometers
    BEYOND( Expression , Expression , distance , units )Similar to DWITHIN, but tests whether the distance between two geometries is greater than the given distance.
    BBOX ( Expression , Number , Number , Number , Number [ , CRS ] )Tests whether a geometry intersects a bounding box specified by its minimum and maximum X and Y values. The optional CRS is a string containing an SRS code (For example, 'EPSG:1234'. The default is to use the CRS of the queried layer)

    Expression

    An expression specifies a attribute, literal, or computed value. The type of the value is determined by the nature of the expression. The standard PEMDAS order of evaluation is used.

    -
    -

    Syntax Description

    -

    Attribute Name of a feature attribute

    -

    Literal Literal value

    -

    Expression + | - | * | / Expression Arithmetic operations

    -

    function ( [ Expression { , Expression } ] ) Value computed by evaluation of a filter function with zero or more arguments.

    -

    ( | [ Expression ] | ) Bracketing with ( or ```` controls evaluation order

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    SyntaxDescription
    AttributeName of a feature attribute
    LiteralLiteral value
    Expression +-
    function ( [ Expression { , Expression } ] )Value computed by evaluation of a filter function with zero or more arguments.
    ( | [ Expression ] | )Bracketing with ( or ```` controls evaluation order

    Attribute

    An attribute name denotes the value of a feature attribute.

      @@ -1717,23 +1874,72 @@

      Attribute

    Literal

    Literals specify constant values of various types.

    -
    -

    Type Description

    -

    Number Integer or floating-point number. Scientific notation is supported.

    -

    Boolean TRUE or FALSE

    -

    String String literal delimited by single quotes. To include a single quote in the string use two single-quotes: ''

    -

    Geometry Geometry in WKT or EWKT format. WKT is defined in the OGC Simple Features for SQL specification. All standard geometry types are supported: POINT, LINESTRING, POLYGON, MULTIPOINT, MULTILINESTRING, MULTIPOLYGON, GEOMETRYCOLLECTION. EWKT allows specifying a geometry spatial reference system by prefixing it with a numerical code, in the form SRID=number;WKT, for example, SRID=4326;POINT (1 2). A custom type of Envelope is also supported with syntax ENVELOPE ( x1 x2 y1 y2 ).

    -

    Time A UTC date/time value in the format yyyy-mm-hhThh:mm:ss. The seconds value may have a decimal fraction. The time zone may be specified as Z or +/-hh:mm. Example: 2006-11-30T00:30:00Z

    -

    Duration A time duration specified as P [ y Y m M d D ] T [ h H m M s S ]. The duration can be specified to any desired precision by including only the required year, month, day, hour, minute and second components. Examples: P1Y2M, P4Y2M20D, P4Y2M1DT20H3M36S

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    TypeDescription
    NumberInteger or floating-point number. Scientific notation is supported.
    BooleanTRUE or FALSE
    StringString literal delimited by single quotes. To include a single quote in the string use two single-quotes: ''
    GeometryGeometry in WKT or EWKT format. WKT is defined in the OGC Simple Features for SQL specification. All standard geometry types are supported: POINT, LINESTRING, POLYGON, MULTIPOINT, MULTILINESTRING, MULTIPOLYGON, GEOMETRYCOLLECTION. EWKT allows specifying a geometry spatial reference system by prefixing it with a numerical code, in the form SRID=number;WKT, for example, SRID=4326;POINT (1 2). A custom type of Envelope is also supported with syntax ENVELOPE ( x1 x2 y1 y2 ).
    TimeA UTC date/time value in the format yyyy-mm-hhThh:mm:ss. The seconds value may have a decimal fraction. The time zone may be specified as Z or +/-hh:mm. Example: 2006-11-30T00:30:00Z
    DurationA time duration specified as P [ y Y m M d D ] T [ h H m M s S ]. The duration can be specified to any desired precision by including only the required year, month, day, hour, minute and second components. Examples: P1Y2M, P4Y2M20D, P4Y2M1DT20H3M36S

    Time Period

    Specifies a period of time, in several different formats.

    -
    -

    Syntax Description

    -

    Time / Time Period specified by a start and end time

    -

    Duration / Time Period specified by a duration before a given time

    -

    Time / Duration Period specified by a duration after a given time

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + +
    SyntaxDescription
    Time / TimePeriod specified by a start and end time
    Duration / TimePeriod specified by a duration before a given time
    Time / DurationPeriod specified by a duration after a given time
    diff --git a/filter/filter_reference/index.html b/filter/filter_reference/index.html index 5a7c20a2118..906b118b537 100644 --- a/filter/filter_reference/index.html +++ b/filter/filter_reference/index.html @@ -1894,19 +1894,61 @@

    Binary Comparison operators

    They contain the elements:

    -
    -

    Element Required? Description

    -

    Expression Yes The first value to compare. Often a <PropertyName>.

    -

    Expression Yes The second value to compare

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + +
    ElementRequired?Description
    ExpressionYesThe first value to compare. Often a <PropertyName>.
    ExpressionYesThe second value to compare

    Binary comparison operator elements may include an optional matchCase attribute, with the value true or false. If this attribute is true (the default), string comparisons are case-sensitive. If the attribute is false strings comparisons do not check case.

    PropertyIsLike operator

    The <PropertyIsLike> operator matches a string property value against a text pattern. It contains the elements:

    -
    -

    Element Required? Description

    -

    <PropertyName> Yes Contains a string specifying the name of the property to test

    -

    <Literal> Yes Contains a pattern string to be matched

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + +
    ElementRequired?Description
    <PropertyName>YesContains a string specifying the name of the property to test
    <Literal>YesContains a pattern string to be matched

    The pattern is specified by a sequence of regular characters and three special pattern characters. The pattern characters are defined by the following required attributes of the <PropertyIsLike> element:

      @@ -1917,18 +1959,60 @@

      PropertyIsLike operator

    PropertyIsNull operator

    The <PropertyIsNull> operator tests whether a property value is null. It contains the element:

    -
    -

    Element Required? Description

    -

    <PropertyName> Yes contains a string specifying the name of the property to be tested

    -
    + + + + + + + + + + + + + + + + + + + + +
    ElementRequired?Description
    <PropertyName>Yescontains a string specifying the name of the property to be tested

    PropertyIsBetweeen operator

    The <PropertyIsBetween> operator tests whether an expression value lies within a range given by a lower and upper bound (inclusive). It contains the elements:

    -
    -

    Element Required? Description

    -

    Expression Yes The value to test

    -

    <LowerBoundary> Yes Contains an Expression giving the lower bound of the range

    -

    <UpperBoundary> Yes Contains an Expression giving the upper bound of the range

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ElementRequired?Description
    ExpressionYesThe value to test
    <LowerBoundary>YesContains an Expression giving the lower bound of the range
    <UpperBoundary>YesContains an Expression giving the upper bound of the range

    Spatial operators

    Spatial operators are used to specify conditions on the geometric attributes of a feature. The following spatial operators are available:

    Topological operators

    @@ -1946,11 +2030,32 @@

    Topological operators

    These contains the elements:

    -
    -

    Element Required? Description

    -

    <PropertyName> Yes Contains a string specifying the name of the geometry-valued property to be tested.

    -

    GML Geometry Yes A GML literal value specifying the geometry to test against

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + +
    ElementRequired?Description
    <PropertyName>YesContains a string specifying the name of the geometry-valued property to be tested.
    GML GeometryYesA GML literal value specifying the geometry to test against

    Distance operators

    These operators test distance relationships between a geometry property and a geometry literal:

    @@ -1960,19 +2065,65 @@

    Distance operators

    They contain the elements:

    -
    -

    Element Required? Description

    -

    <PropertyName> Yes Contains a string specifying the name of the property to be tested. If omitted, the default geometry attribute is assumed.

    -

    GML Geometry Yes A literal value specifying a geometry to compute the distance to. This may be either a geometry or an envelope in GML 3 format

    -

    <Distance> Yes Contains the numeric value for the distance tolerance. The element may include an optional units attribute.

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ElementRequired?Description
    <PropertyName>YesContains a string specifying the name of the property to be tested. If omitted, the default geometry attribute is assumed.
    GML GeometryYesA literal value specifying a geometry to compute the distance to. This may be either a geometry or an envelope in GML 3 format
    <Distance>YesContains the numeric value for the distance tolerance. The element may include an optional units attribute.

    Bounding Box operator

    The <BBOX> operator tests whether a geometry-valued property intersects a fixed bounding box. It contains the elements:

    -
    -

    Element Required? Description

    -

    <PropertyName> No Contains a string specifying the name of the property to be tested. If omitted, the default geometry attribute is assumed.

    -

    <gml:Box> Yes A GML Box literal value specifying the bounding box to test against

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + +
    ElementRequired?Description
    <PropertyName>NoContains a string specifying the name of the property to be tested. If omitted, the default geometry attribute is assumed.
    <gml:Box>YesA GML Box literal value specifying the bounding box to test against

    Examples

    • This filter selects features with a geometry that intersects the point (1,1).
    • @@ -2068,14 +2219,40 @@

      Property Value

      The <PropertyName> element refers to the value of a feature attribute. It contains a string or an XPath expression specifying the attribute name.

      Literal

      The <Literal> element specifies a constant value. It contains data of one of the following types:

      -
      -

      Type Description

      -

      Numeric A string representing a numeric value (integer or decimal).

      -

      Boolean A boolean value of true or false.

      -

      String A string value. XML-incompatible text may be included by using character entities or <![CDATA[ ]]> delimiters.

      -

      Date A string representing a date.

      -

      Geometry An element specifying a geometry in GML3 format.

      -
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      TypeDescription
      NumericA string representing a numeric value (integer or decimal).
      BooleanA boolean value of true or false.
      StringA string value. XML-incompatible text may be included by using character entities or <![CDATA[ ]]> delimiters.
      DateA string representing a date.
      GeometryAn element specifying a geometry in GML3 format.

      WFS 2.0 namespaces

      WFS 2.0 does not depend on any one GML version and thus requires an explicit namespace and schemaLocation for GML. In a GET request, namespaces can be placed on a Filter element (that is, filter= the block below, URL-encoded):

      <fes:Filter
      diff --git a/filter/function_reference/index.html b/filter/function_reference/index.html
      index 305c74573a1..d8f65ea6a91 100644
      --- a/filter/function_reference/index.html
      +++ b/filter/function_reference/index.html
      @@ -1673,38 +1673,151 @@ 

      Filter Function Reference

      The list of functions available on a GeoServer instance can be determined by browsing to http://localhost:8080/geoserver/wfs?request=GetCapabilities and searching for ogc:Function_Names (WFS 1.0.0), ogc:FunctionNames (WFS 1.1.0), or fes:Functions (WFS 2.0.0) in the returned XML. If a function is described in the Capabilities document but is not in this reference, then it might mean that the function cannot be used for filtering, or that it is new and has not been documented. Ask for details on the user mailing list.

      Unless otherwise specified, none of the filter functions in this reference are understood natively by the data stores, and thus expressions using them will be evaluated in-memory.

      Function argument type reference

      -
      -

      Type Description

      -

      Double Floating point number, 8 bytes, IEEE 754. Ranges from 4.94065645841246544e-324d to 1.79769313486231570e+308d

      -

      Float Floating point number, 4 bytes, IEEE 754. Ranges from 1.40129846432481707e-45 to 3.40282346638528860e+38. Smaller range and less accurate than Double.

      -

      Integer Integer number, ranging from -2,147,483,648 to 2,147,483,647

      -

      Long Integer number, ranging from -9,223,372,036,854,775,808 to +9,223,372,036,854,775,807

      -

      Number A numeric value of any type

      -

      Object A value of any type

      -

      String A sequence of characters

      -

      Timestamp Date and time information

      -
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      TypeDescription
      DoubleFloating point number, 8 bytes, IEEE 754. Ranges from 4.94065645841246544e-324d to 1.79769313486231570e+308d
      FloatFloating point number, 4 bytes, IEEE 754. Ranges from 1.40129846432481707e-45 to 3.40282346638528860e+38. Smaller range and less accurate than Double.
      IntegerInteger number, ranging from -2,147,483,648 to 2,147,483,647
      LongInteger number, ranging from -9,223,372,036,854,775,808 to +9,223,372,036,854,775,807
      NumberA numeric value of any type
      ObjectA value of any type
      StringA sequence of characters
      TimestampDate and time information

      Comparison functions

      -
      -

      Name Arguments Description

      -

      between num:Number, low:Number, high:Number returns true if low <= num <= high

      -

      equalTo a:Object, b:Object Can be used to compare for equality two numbers, two strings, two dates, and so on

      -

      greaterEqualThan x:Object, y:Object Returns true if x >= y. Parameters can be either numbers or strings (in the second case lexicographic ordering is used)

      -

      greaterThan x:Object, y:Object Returns true if x > y. Parameters can be either numbers or strings (in the second case lexicographic ordering is used)

      -

      in2, in3, in4, in5, in6, in7, in8, in9, in10 candidate:Object, v1:Object, ..., v9:Object Returns true if candidate is equal to one of the v1, ..., v9 values. Use the function name matching the number of arguments specified.

      -

      in candidate:Object, v1:Object, v2:Object, ... Works exactly the same as the in2, ..., in10 functions described above, but takes any number of values as input.

      -

      isLike string:String, pattern:String Returns true if the string matches the specified pattern. For the full syntax of the pattern specification see the Java Pattern class javadocs

      -

      isNull obj:Object Returns true the passed parameter is null, false otherwise

      -

      lessThan x:Object, y:Object Returns true if x < y. Parameters can be either numbers or strings (in the second case lexicographic ordering is used

      -

      lessEqualThan x:Object, y:Object Returns true if x <= y. Parameters can be either numbers or strings (in the second case lexicographic ordering is used

      -

      not bool:Boolean Returns the negation of bool

      -

      notEqualTo x:Object, y:Object Returns true if x and y are equal, false otherwise

      -
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      NameArgumentsDescription
      betweennum:Number, low:Number, high:Numberreturns true if low <= num <= high
      equalToa:Object, b:ObjectCan be used to compare for equality two numbers, two strings, two dates, and so on
      greaterEqualThanx:Object, y:ObjectReturns true if x >= y. Parameters can be either numbers or strings (in the second case lexicographic ordering is used)
      greaterThanx:Object, y:ObjectReturns true if x > y. Parameters can be either numbers or strings (in the second case lexicographic ordering is used)
      in2, in3, in4, in5, in6, in7, in8, in9, in10candidate:Object, v1:Object, ..., v9:ObjectReturns true if candidate is equal to one of the v1, ..., v9 values. Use the function name matching the number of arguments specified.
      incandidate:Object, v1:Object, v2:Object, ...Works exactly the same as the in2, ..., in10 functions described above, but takes any number of values as input.
      isLikestring:String, pattern:StringReturns true if the string matches the specified pattern. For the full syntax of the pattern specification see the Java Pattern class javadocs
      isNullobj:ObjectReturns true the passed parameter is null, false otherwise
      lessThanx:Object, y:ObjectReturns true if x < y. Parameters can be either numbers or strings (in the second case lexicographic ordering is used
      lessEqualThanx:Object, y:ObjectReturns true if x <= y. Parameters can be either numbers or strings (in the second case lexicographic ordering is used
      notbool:BooleanReturns the negation of bool
      notEqualTox:Object, y:ObjectReturns true if x and y are equal, false otherwise

      Control functions

      -
      -

      Name Arguments Description

      -

      if_then_else condition:Boolean, x:Object, y: Object Returns x if the condition is true, y otherwise

      -
      + + + + + + + + + + + + + + + + + + + + +
      NameArgumentsDescription
      if_then_elsecondition:Boolean, x:Object, y: ObjectReturns x if the condition is true, y otherwise

      Environment function

      This function returns the value of environment variables defined in various contexts. WMS GetMap automatically defines some variables SLD rendering, while others can be provided using the env request parameter. Example usage in e.g. a dynamic symbolizer:

      ${env('size', 20)}

      @@ -1721,155 +1834,723 @@

      Environment function

      </Graphic> </PointSymbolizer>
      -
      -

      Name Arguments Description

      -

      env variable:String Returns the value of the environment variable variable.

      -
      + + + + + + + + + + + + + + + + + + + + +
      NameArgumentsDescription
      envvariable:StringReturns the value of the environment variable variable.

      Feature functions

      -
      -

      Name Arguments Description

      -

      id feature:Feature returns the identifier of the feature

      -

      PropertyExists f:Feature, propertyName:String Returns true if f has a property named propertyName

      -

      property f:Feature, propertyName:String Returns the value of the property propertyName. Allows property names to be computed or specified by Variable substitution in SLD.

      -

      mapGet f:Feature, map:Map, key:String Get the value of the map map related to the specified key.

      -
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      NameArgumentsDescription
      idfeature:Featurereturns the identifier of the feature
      PropertyExistsf:Feature, propertyName:StringReturns true if f has a property named propertyName
      propertyf:Feature, propertyName:StringReturns the value of the property propertyName. Allows property names to be computed or specified by Variable substitution in SLD.
      mapGetf:Feature, map:Map, key:StringGet the value of the map map related to the specified key.

      Spatial Relationship functions

      For more information about the precise meaning of the spatial relationships consult the OGC Simple Feature Specification for SQL

      -
      -

      Name Arguments Description

      -

      contains a:Geometry, b:Geometry Returns true if the geometry a contains b

      -

      crosses a:Geometry, b:Geometry Returns true if a crosses b

      -

      disjoint a:Geometry, b:Geometry Returns true if the two geometries are disjoint, false otherwise

      -

      equalsExact a:Geometry, b:Geometry Returns true if the two geometries are exactly equal, same coordinates in the same order

      -

      equalsExactTolerance a:Geometry, b:Geometry, tol:Double Returns true if the two geometries are exactly equal, same coordinates in the same order, allowing for a tol distance in the corresponding points

      -

      intersects a:Geometry, b:Geometry Returns true if a intersects b

      -

      isWithinDistance a: Geometry, b:Geometry, distance: Double Returns true if the distance between a and b is less than distance (measured as an euclidean distance)

      -

      overlaps a: Geometry, b:Geometry Returns true a overlaps with b

      -

      relate a: Geometry, b:Geometry Returns the DE-9IM intersection matrix for a and b

      -

      relatePattern a: Geometry, b:Geometry, pattern:String Returns true if the DE-9IM intersection matrix for a and b matches the specified pattern

      -

      touches a: Geometry, b: Geometry Returns true if a touches b according to the SQL simple feature specification rules

      -

      within a: Geometry, b:Geometry Returns true is fully contained inside b

      -
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      NameArgumentsDescription
      containsa:Geometry, b:GeometryReturns true if the geometry a contains b
      crossesa:Geometry, b:GeometryReturns true if a crosses b
      disjointa:Geometry, b:GeometryReturns true if the two geometries are disjoint, false otherwise
      equalsExacta:Geometry, b:GeometryReturns true if the two geometries are exactly equal, same coordinates in the same order
      equalsExactTolerancea:Geometry, b:Geometry, tol:DoubleReturns true if the two geometries are exactly equal, same coordinates in the same order, allowing for a tol distance in the corresponding points
      intersectsa:Geometry, b:GeometryReturns true if a intersects b
      isWithinDistancea: Geometry, b:Geometry, distance: DoubleReturns true if the distance between a and b is less than distance (measured as an euclidean distance)
      overlapsa: Geometry, b:GeometryReturns true a overlaps with b
      relatea: Geometry, b:GeometryReturns the DE-9IM intersection matrix for a and b
      relatePatterna: Geometry, b:Geometry, pattern:StringReturns true if the DE-9IM intersection matrix for a and b matches the specified pattern
      touchesa: Geometry, b: GeometryReturns true if a touches b according to the SQL simple feature specification rules
      withina: Geometry, b:GeometryReturns true is fully contained inside b

      Geometric functions

      -
      -

      Name Arguments Description

      -

      area geometry:Geometry The area of the specified geometry. Works in a Cartesian plane, the result will be in the same unit of measure as the geometry coordinates (which also means the results won't make any sense for geographic data)

      -

      boundary geometry:Geometry Returns the boundary of a geometry

      -

      boundaryDimension geometry:Geometry Returns the number of dimensions of the geometry boundary

      -

      buffer geometry:Geometry, distance:Double Returns the buffered area around the geometry using the specified distance

      -

      bufferWithSegments geometry:Geometry, distance:Double, segments:Integer Returns the buffered area around the geometry using the specified distance and using the specified number of segments to represent a quadrant of a circle.

      -

      centroid geometry:Geometry Returns the centroid of the geometry. Can be often used as a label point for polygons, though there is no guarantee it will actually lie inside the geometry

      -

      convexHull geometry:Geometry Returns the convex hull of the specified geometry

      -

      difference a:Geometry, b:Geometry Returns all the points that sit in a but not in b

      -

      dimension a:Geometry Returns the dimension of the specified geometry

      -

      distance a:Geometry, b:Geometry Returns the euclidean distance between the two geometries

      -

      endAngle line:LineString Returns the angle of the end segment of the linestring

      -

      endPoint line:LineString Returns the end point of the linestring

      -

      envelope geometry:geometry Returns the polygon representing the envelope of the geometry, that is, the minimum rectangle with sides parallels to the axis containing it

      -

      exteriorRing poly:Polygon Returns the exterior ring of the specified polygon

      -

      geometryType geometry:Geometry Returns the type of the geometry as a string. May be Point, MultiPoint, LineString, LinearRing, MultiLineString, Polygon, MultiPolygon, GeometryCollection

      -

      geomFromWKT wkt:String Returns the Geometry represented in the Well Known Text format contained in the wkt parameter

      -

      geomLength geometry:Geometry Returns the length/perimeter of this geometry (computed in Cartesian space)

      -

      getGeometryN collection:GeometryCollection, n:Integer Returns the n-th geometry inside the collection

      -

      getX p:Point Returns the x ordinate of p

      -

      getY p:Point Returns the y ordinate of p

      -

      getZ p:Point Returns the z ordinate of p

      -

      interiorPoint geometry:Geometry Returns a point that is either interior to the geometry, when possible, or sitting on its boundary, otherwise

      -

      interiorRingN polyg:Polygon, n:Integer Returns the n-th interior ring of the polygon

      -

      intersection a:Geometry, b:Geometry Returns the intersection between a and b. The intersection result can be anything including a geometry collection of heterogeneous, if the result is empty, it will be represented by an empty collection.

      -

      isClosed line: LineString Returns true if line forms a closed ring, that is, if the first and last coordinates are equal

      -

      isEmpty geometry:Geometry Returns true if the geometry does not contain any point (typical case, an empty geometry collection)

      -

      isometric geometry:Geometry, extrusion:Double Returns a MultiPolygon containing the isometric extrusions of all components of the input geometry. The extrusion distance is extrusion, expressed in the same unit as the geometry coordinates. Can be used to get a pseudo-3d effect in a map

      -

      isRing line:LineString Returns true if the line is actually a closed ring (equivalent to isRing(line) and isSimple(line))

      -

      isSimple line:LineString Returns true if the geometry self intersects only at boundary points

      -

      isValid geometry: Geometry Returns true if the geometry is topologically valid (rings are closed, holes are inside the hull, and so on)

      -

      numGeometries collection: GeometryCollection Returns the number of geometries contained in the geometry collection

      -

      numInteriorRing poly: Polygon Returns the number of interior rings (holes) inside the specified polygon

      -

      numPoint geometry: Geometry Returns the number of points (vertexes) contained in geometry

      -

      offset geometry: Geometry, offsetX:Double, offsetY:Double Offsets all points in a geometry by the specified X and Y offsets. Offsets are working in the same coordinate system as the geometry own coordinates.

      -

      pointN geometry: Geometry, n:Integer Returns the n-th point inside the specified geometry

      -

      startAngle line: LineString Returns the angle of the starting segment of the input linestring

      -

      startPoint line: LineString Returns the starting point of the input linestring

      -

      symDifference a: Geometry, b:Geometry Returns the symmetrical difference between a and b (all points that are inside a or b, but not both)

      -

      toWKT geometry: Geometry Returns the WKT representation of geometry

      -

      union a: Geometry, b:Geometry Returns the union of a and b (the result may be a geometry collection)

      -

      vertices geom: Geometry Returns a multi-point made with all the vertices of geom

      -
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      NameArgumentsDescription
      areageometry:GeometryThe area of the specified geometry. Works in a Cartesian plane, the result will be in the same unit of measure as the geometry coordinates (which also means the results won't make any sense for geographic data)
      boundarygeometry:GeometryReturns the boundary of a geometry
      boundaryDimensiongeometry:GeometryReturns the number of dimensions of the geometry boundary
      buffergeometry:Geometry, distance:DoubleReturns the buffered area around the geometry using the specified distance
      bufferWithSegmentsgeometry:Geometry, distance:Double, segments:IntegerReturns the buffered area around the geometry using the specified distance and using the specified number of segments to represent a quadrant of a circle.
      centroidgeometry:GeometryReturns the centroid of the geometry. Can be often used as a label point for polygons, though there is no guarantee it will actually lie inside the geometry
      convexHullgeometry:GeometryReturns the convex hull of the specified geometry
      differencea:Geometry, b:GeometryReturns all the points that sit in a but not in b
      dimensiona:GeometryReturns the dimension of the specified geometry
      distancea:Geometry, b:GeometryReturns the euclidean distance between the two geometries
      endAngleline:LineStringReturns the angle of the end segment of the linestring
      endPointline:LineStringReturns the end point of the linestring
      envelopegeometry:geometryReturns the polygon representing the envelope of the geometry, that is, the minimum rectangle with sides parallels to the axis containing it
      exteriorRingpoly:PolygonReturns the exterior ring of the specified polygon
      geometryTypegeometry:GeometryReturns the type of the geometry as a string. May be Point, MultiPoint, LineString, LinearRing, MultiLineString, Polygon, MultiPolygon, GeometryCollection
      geomFromWKTwkt:StringReturns the Geometry represented in the Well Known Text format contained in the wkt parameter
      geomLengthgeometry:GeometryReturns the length/perimeter of this geometry (computed in Cartesian space)
      getGeometryNcollection:GeometryCollection, n:IntegerReturns the n-th geometry inside the collection
      getXp:PointReturns the x ordinate of p
      getYp:PointReturns the y ordinate of p
      getZp:PointReturns the z ordinate of p
      interiorPointgeometry:GeometryReturns a point that is either interior to the geometry, when possible, or sitting on its boundary, otherwise
      interiorRingNpolyg:Polygon, n:IntegerReturns the n-th interior ring of the polygon
      intersectiona:Geometry, b:GeometryReturns the intersection between a and b. The intersection result can be anything including a geometry collection of heterogeneous, if the result is empty, it will be represented by an empty collection.
      isClosedline: LineStringReturns true if line forms a closed ring, that is, if the first and last coordinates are equal
      isEmptygeometry:GeometryReturns true if the geometry does not contain any point (typical case, an empty geometry collection)
      isometricgeometry:Geometry, extrusion:DoubleReturns a MultiPolygon containing the isometric extrusions of all components of the input geometry. The extrusion distance is extrusion, expressed in the same unit as the geometry coordinates. Can be used to get a pseudo-3d effect in a map
      isRingline:LineStringReturns true if the line is actually a closed ring (equivalent to isRing(line) and isSimple(line))
      isSimpleline:LineStringReturns true if the geometry self intersects only at boundary points
      isValidgeometry: GeometryReturns true if the geometry is topologically valid (rings are closed, holes are inside the hull, and so on)
      numGeometriescollection: GeometryCollectionReturns the number of geometries contained in the geometry collection
      numInteriorRingpoly: PolygonReturns the number of interior rings (holes) inside the specified polygon
      numPointgeometry: GeometryReturns the number of points (vertexes) contained in geometry
      offsetgeometry: Geometry, offsetX:Double, offsetY:DoubleOffsets all points in a geometry by the specified X and Y offsets. Offsets are working in the same coordinate system as the geometry own coordinates.
      pointNgeometry: Geometry, n:IntegerReturns the n-th point inside the specified geometry
      startAngleline: LineStringReturns the angle of the starting segment of the input linestring
      startPointline: LineStringReturns the starting point of the input linestring
      symDifferencea: Geometry, b:GeometryReturns the symmetrical difference between a and b (all points that are inside a or b, but not both)
      toWKTgeometry: GeometryReturns the WKT representation of geometry
      uniona: Geometry, b:GeometryReturns the union of a and b (the result may be a geometry collection)
      verticesgeom: GeometryReturns a multi-point made with all the vertices of geom

      Math functions

      -
      -

      Name Arguments Description

      -

      abs value:Integer The absolute value of the specified Integer value

      -

      abs_2 value:Long The absolute value of the specified Long value

      -

      abs_3 value:Float The absolute value of the specified Float value

      -

      abs_4 value:Double The absolute value of the specified Double value

      -

      acos angle:Double Returns the arc cosine of an angle in radians, in the range of 0.0 through PI

      -

      asin angle:Double Returns the arc sine of an angle in radians, in the range of -PI / 2 through PI / 2

      -

      atan angle:Double Returns the arc tangent of an angle in radians, in the range of -PI/2 through PI/2

      -

      atan2 x:Double, y:Double Converts a rectangular coordinate (x, y) to polar (r, theta) and returns theta.

      -

      ceil x: Double Returns the smallest (closest to negative infinity) double value that is greater than or equal to x and is equal to a mathematical integer.

      -

      cos angle: Double Returns the cosine of an angle expressed in radians

      -

      double2bool x: Double Returns true if x is zero, false otherwise

      -

      exp x: Double Returns Euler's number e raised to the power of x

      -

      floor x: Double Returns the largest (closest to positive infinity) value that is less than or equal to x and is equal to a mathematical integer

      -

      IEEERemainder x: Double, y:Double Computes the remainder of x divided by y as prescribed by the IEEE 754 standard

      -

      int2bbool x: Integer Returns true if x is zero, false otherwise

      -

      int2ddouble x: Integer Converts x to a Double

      -

      log x: Integer Returns the natural logarithm (base e) of x

      -

      max, max_3, max_4 x1: Double, x2:Double, x3:Double, x4:Double Returns the maximum between x1, ..., x4

      -

      min, min_3, min_4 x1: Double, x2:Double, x3:Double, x4:Double Returns the minimum between x1, ..., x4

      -

      pi None Returns an approximation of pi, the ratio of the circumference of a circle to its diameter

      -

      pow base:Double, exponent:Double Returns the value of base raised to the power of exponent

      -

      random None Returns a Double value with a positive sign, greater than or equal to 0.0 and less than 1.0. Returned values are chosen pseudo-randomly with (approximately) uniform distribution from that range.

      -

      rint x:Double Returns the Double value that is closest in value to the argument and is equal to a mathematical integer. If two double values that are mathematical integers are equally close, the result is the integer value that is even.

      -

      round_2 x:Double Same as round, but returns a Long

      -

      round x:Double Returns the closest Integer to x. The result is rounded to an integer by adding ½, taking the floor of the result, and casting the result to type Integer. In other words, the result is equal to the value of the expression (int)floor(a + 0.5)

      -

      roundDouble x:Double Returns the closest Long to x

      -

      sin angle: Double Returns the sine of an angle expressed in radians

      -

      tan angle:Double Returns the trigonometric tangent of angle expressed in radians

      -

      toDegrees angle:Double Converts an angle expressed in radians into degrees

      -

      toRadians angle:Double Converts an angle expressed in radians into degrees

      -
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      NameArgumentsDescription
      absvalue:IntegerThe absolute value of the specified Integer value
      abs_2value:LongThe absolute value of the specified Long value
      abs_3value:FloatThe absolute value of the specified Float value
      abs_4value:DoubleThe absolute value of the specified Double value
      acosangle:DoubleReturns the arc cosine of an angle in radians, in the range of 0.0 through PI
      asinangle:DoubleReturns the arc sine of an angle in radians, in the range of -PI / 2 through PI / 2
      atanangle:DoubleReturns the arc tangent of an angle in radians, in the range of -PI/2 through PI/2
      atan2x:Double, y:DoubleConverts a rectangular coordinate (x, y) to polar (r, theta) and returns theta.
      ceilx: DoubleReturns the smallest (closest to negative infinity) double value that is greater than or equal to x and is equal to a mathematical integer.
      cosangle: DoubleReturns the cosine of an angle expressed in radians
      double2boolx: DoubleReturns true if x is zero, false otherwise
      expx: DoubleReturns Euler's number e raised to the power of x
      floorx: DoubleReturns the largest (closest to positive infinity) value that is less than or equal to x and is equal to a mathematical integer
      IEEERemainderx: Double, y:DoubleComputes the remainder of x divided by y as prescribed by the IEEE 754 standard
      int2bboolx: IntegerReturns true if x is zero, false otherwise
      int2ddoublex: IntegerConverts x to a Double
      logx: IntegerReturns the natural logarithm (base e) of x
      max, max_3, max_4x1: Double, x2:Double, x3:Double, x4:DoubleReturns the maximum between x1, ..., x4
      min, min_3, min_4x1: Double, x2:Double, x3:Double, x4:DoubleReturns the minimum between x1, ..., x4
      piNoneReturns an approximation of pi, the ratio of the circumference of a circle to its diameter
      powbase:Double, exponent:DoubleReturns the value of base raised to the power of exponent
      randomNoneReturns a Double value with a positive sign, greater than or equal to 0.0 and less than 1.0. Returned values are chosen pseudo-randomly with (approximately) uniform distribution from that range.
      rintx:DoubleReturns the Double value that is closest in value to the argument and is equal to a mathematical integer. If two double values that are mathematical integers are equally close, the result is the integer value that is even.
      round_2x:DoubleSame as round, but returns a Long
      roundx:DoubleReturns the closest Integer to x. The result is rounded to an integer by adding ½, taking the floor of the result, and casting the result to type Integer. In other words, the result is equal to the value of the expression (int)floor(a + 0.5)
      roundDoublex:DoubleReturns the closest Long to x
      sinangle: DoubleReturns the sine of an angle expressed in radians
      tanangle:DoubleReturns the trigonometric tangent of angle expressed in radians
      toDegreesangle:DoubleConverts an angle expressed in radians into degrees
      toRadiansangle:DoubleConverts an angle expressed in radians into degrees

      String functions

      String functions generally will accept any type of value for String arguments. Non-string values will be converted into a string representation automatically.

      -
      -

      Name Arguments Description

      -

      Concatenate s1:String, s2:String, ... Concatenates any number of strings. Non-string arguments are allowed.

      -

      strAbbreviate sentence:String, lower:Integer, upper:Integer, append:String Abbreviates the sentence at first space beyond lower (or at upper if no space). Appends append if string is abbreviated.

      -

      strCapitalize sentence:String Fully capitalizes the sentence. For example, "HoW aRe YOU?" will be turned into "How Are You?"

      -

      strConcat a:String, b:String Concatenates the two strings into one

      -

      strDefaultIfBlank str:String, default:String returns default if str is empty, blank or null

      -

      strEndsWith string:String, suffix:String Returns true if string ends with suffix

      -

      strEqualsIgnoreCase a:String, b:String Returns true if the two strings are equal ignoring case considerations

      -

      strIndexOf string:String, substring:String Returns the index within this string of the first occurrence of the specified substring, or -1 if not found

      -

      strLastIndexOf string:String, substring:String Returns the index within this string of the last occurrence of the specified substring, or -1 if not found

      -

      strLength string:String Returns the string length

      -

      strMatches string:String, pattern:String Returns true if the string matches the specified regular expression. For the full syntax of the pattern specification see the Java Pattern class javadocs

      -

      strReplace string:String, pattern:String, replacement:String, global: boolean Returns the string with the pattern replaced with the given replacement text. If the global argument is true then all occurrences of the pattern will be replaced, otherwise only the first. For the full syntax of the pattern specification see the Java Pattern class javadocs

      -

      strStartsWith string:String, prefix:String Returns true if string starts with prefix

      -

      strStripAccents string:String Removes diacritics (\~= accents) from a string. The case will not be altered.

      -

      strSubstring string:String, begin:Integer, end:Integer Returns a new string that is a substring of this string. The substring begins at the specified begin and extends to the character at index endIndex - 1 (indexes are zero-based).

      -

      strSubstringStart string:String, begin:Integer Returns a new string that is a substring of this string. The substring begins at the specified begin and extends to the last character of the string

      -

      strToLowerCase string:String Returns the lower case version of the string

      -

      strToUpperCase string:String Returns the upper case version of the string

      -

      strTrim string:String Returns a copy of the string, with leading and trailing blank-space omitted

      -
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      NameArgumentsDescription
      Concatenates1:String, s2:String, ...Concatenates any number of strings. Non-string arguments are allowed.
      strAbbreviatesentence:String, lower:Integer, upper:Integer, append:StringAbbreviates the sentence at first space beyond lower (or at upper if no space). Appends append if string is abbreviated.
      strCapitalizesentence:StringFully capitalizes the sentence. For example, "HoW aRe YOU?" will be turned into "How Are You?"
      strConcata:String, b:StringConcatenates the two strings into one
      strDefaultIfBlankstr:String, default:Stringreturns default if str is empty, blank or null
      strEndsWithstring:String, suffix:StringReturns true if string ends with suffix
      strEqualsIgnoreCasea:String, b:StringReturns true if the two strings are equal ignoring case considerations
      strIndexOfstring:String, substring:StringReturns the index within this string of the first occurrence of the specified substring, or -1 if not found
      strLastIndexOfstring:String, substring:StringReturns the index within this string of the last occurrence of the specified substring, or -1 if not found
      strLengthstring:StringReturns the string length
      strMatchesstring:String, pattern:StringReturns true if the string matches the specified regular expression. For the full syntax of the pattern specification see the Java Pattern class javadocs
      strReplacestring:String, pattern:String, replacement:String, global: booleanReturns the string with the pattern replaced with the given replacement text. If the global argument is true then all occurrences of the pattern will be replaced, otherwise only the first. For the full syntax of the pattern specification see the Java Pattern class javadocs
      strStartsWithstring:String, prefix:StringReturns true if string starts with prefix
      strStripAccentsstring:StringRemoves diacritics (\~= accents) from a string. The case will not be altered.
      strSubstringstring:String, begin:Integer, end:IntegerReturns a new string that is a substring of this string. The substring begins at the specified begin and extends to the character at index endIndex - 1 (indexes are zero-based).
      strSubstringStartstring:String, begin:IntegerReturns a new string that is a substring of this string. The substring begins at the specified begin and extends to the last character of the string
      strToLowerCasestring:StringReturns the lower case version of the string
      strToUpperCasestring:StringReturns the upper case version of the string
      strTrimstring:StringReturns a copy of the string, with leading and trailing blank-space omitted

      Parsing and formatting functions

      -
      -

      Name Arguments Description

      -

      dateFormat format:String, date:Timestamp Formats the specified date according to the provided format. The format syntax can be found in the Java SimpleDateFormat javadocs

      -

      dateParse format:String, dateString:String Parses a date from a dateString formatted according to the format specification. The format syntax can be found in the Java SimpleDateFormat javadocs

      -

      numberFormat format:String, number:Double, locale:String Formats the number according to the specified format using the default locale or the one provided as an optional argument. The format syntax can be found in the Java DecimalFormat javadocs

      -

      parseBoolean boolean:String Parses a string into a boolean. The empty string, f, 0.0 and 0 are considered false, everything else is considered true.

      -

      parseDouble number:String Parses a string into a double. The number can be expressed in normal or scientific form.

      -

      parseInt number:String Parses a string into an integer.

      -

      parseLong number:String Parses a string into a long integer

      -
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      NameArgumentsDescription
      dateFormatformat:String, date:TimestampFormats the specified date according to the provided format. The format syntax can be found in the Java SimpleDateFormat javadocs
      dateParseformat:String, dateString:StringParses a date from a dateString formatted according to the format specification. The format syntax can be found in the Java SimpleDateFormat javadocs
      numberFormatformat:String, number:Double, locale:StringFormats the number according to the specified format using the default locale or the one provided as an optional argument. The format syntax can be found in the Java DecimalFormat javadocs
      parseBooleanboolean:StringParses a string into a boolean. The empty string, f, 0.0 and 0 are considered false, everything else is considered true.
      parseDoublenumber:StringParses a string into a double. The number can be expressed in normal or scientific form.
      parseIntnumber:StringParses a string into an integer.
      parseLongnumber:StringParses a string into a long integer

      Temporal functions

      -
      -

      Name Arguments Description

      -

      dateDifference a:Date, b:Date, timeUnits:String Computes the difference between two date (as a-b) and return a result in a specific time units. timeUnits is optional, representing the desired time units result. Default as milliseconds. Possible values are s (seconds), m (minutes), h (hours), d (days).

      -

      now None Returns the current time as a Date

      -
      + + + + + + + + + + + + + + + + + + + + + + + + + +
      NameArgumentsDescription
      dateDifferencea:Date, b:Date, timeUnits:StringComputes the difference between two date (as a-b) and return a result in a specific time units. timeUnits is optional, representing the desired time units result. Default as milliseconds. Possible values are s (seconds), m (minutes), h (hours), d (days).
      nowNoneReturns the current time as a Date

      Transformation functions

      Transformation functions transform values from one data space into another. These functions provide a concise way to compute styling parameters from feature attribute values. See also Styling using Transformation Functions.

      +-------------+----------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ diff --git a/geowebcache/webadmin/demopage/index.html b/geowebcache/webadmin/demopage/index.html index a21983a9163..da45fc99a7c 100644 --- a/geowebcache/webadmin/demopage/index.html +++ b/geowebcache/webadmin/demopage/index.html @@ -2257,17 +2257,44 @@

      Seeding

      You can configure seeding processes via the Web administration interface. See the Tile Layers page for more information.

      It is also possible to configure seeding process via the Demo page. The page contains a link next to each layer entitled Seed this layer. This link will trigger authentication with the GeoServer configuration. Use the same username and password that you would use to log on to the Web administration interface. After a successful logon, a new page shows up with seeding options.

      The seeding options page contains various parameters for configuring the way that the layer is seeded.

      -
      -

      Option Description

      -
      -

      Number of threads to use Possible values are between 1 and 16.

      -

      Type of operation Sets the operation. There are three possible values: Seed (creates tiles, but does not overwrite existing ones), Reseed (like Seed, but overwrites existing tiles) and Truncate (deletes all tiles within the given parameters)

      -

      SRS Specifies the projection to use when creating tiles (default values are EPSG:4326 and EPSG:900913)

      -

      Format Sets the image format of the tiles. Can be application/vnd.google-earth.kml+xml (Google Earth KML), image/gif (GIF), image/jpeg (JPEG), image/png (24 bit PNG), and image/png8 (8 bit PNG)

      -

      Zoom start Sets the minimum zoom level. Lower values indicate map views that are more zoomed out. When seeding, GeoWebCache will only create tiles for those zoom levels inclusive of this value and Zoom stop.

      -

      Zoom stop Sets the maximum zoom level. Higher values indicate map views that are more zoomed in. When seeding, GeoWebCache will only create tiles for those zoom levels inclusive of this value and Zoom start.

      -

      Bounding box (optional) Allows seeding to occur over a specified extent, instead of the full extent of the layer. This is useful if your layer contains data over a large area, but the application will only request tiles from a subset of that area. The four boxes correspond to Xmin, Ymin, Xmax, and Ymax.

      -
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      OptionDescription
      Number of threads to usePossible values are between 1 and 16.
      Type of operationSets the operation. There are three possible values: Seed (creates tiles, but does not overwrite existing ones), Reseed (like Seed, but overwrites existing tiles) and Truncate (deletes all tiles within the given parameters)
      SRSSpecifies the projection to use when creating tiles (default values are EPSG:4326 and EPSG:900913)
      FormatSets the image format of the tiles. Can be application/vnd.google-earth.kml+xml (Google Earth KML), image/gif (GIF), image/jpeg (JPEG), image/png (24 bit PNG), and image/png8 (8 bit PNG)
      Zoom startSets the minimum zoom level. Lower values indicate map views that are more zoomed out. When seeding, GeoWebCache will only create tiles for those zoom levels inclusive of this value and Zoom stop.
      Zoom stopSets the maximum zoom level. Higher values indicate map views that are more zoomed in. When seeding, GeoWebCache will only create tiles for those zoom levels inclusive of this value and Zoom start.
      Bounding box(optional) Allows seeding to occur over a specified extent, instead of the full extent of the layer. This is useful if your layer contains data over a large area, but the application will only request tiles from a subset of that area. The four boxes correspond to Xmin, Ymin, Xmax, and Ymax.

      Warning

      Currently there is no progress bar to inform you of the time required to perform the operation, nor is there any intelligent handling of disk space. In short, the process may take a very long time, and the cache may fill up your disk. You may wish to set a Disk quota before running a seed job.

      diff --git a/gettingstarted/geopkg-quickstart/index.html b/gettingstarted/geopkg-quickstart/index.html index cbe152439f9..82d573569de 100644 --- a/gettingstarted/geopkg-quickstart/index.html +++ b/gettingstarted/geopkg-quickstart/index.html @@ -1954,21 +1954,35 @@

      Creating a new workspace

      - - + - - - - - - +
      FieldValue
      Name:tutorial
      Namespace URIhttp://localhost:8080/geoserver/tutorial
      +
        +
      • +
          +
        • Field
        • +
        • Value
        • +
        +
      • +
      • +
          +
        • Name:
        • +
        • tutorial
        • +
        +
      • +
      • +
          +
        • Namespace URI
        • +
        • http://localhost:8080/geoserver/tutorial
        • +
        +
      • +

      Note

      A workspace name is an identifier describing your project. It must not exceed ten characters or contain spaces.

      @@ -2012,25 +2026,41 @@

      Create a store

      - - + - - - - - - - - - - +
      FieldValue
      workspacetutorial
      Data Source NameNaturalEarth
      DescriptionGeoPackage of NaturalEarth data
      +
        +
      • +
          +
        • Field
        • +
        • Value
        • +
        +
      • +
      • +
          +
        • workspace
        • +
        • tutorial
        • +
        +
      • +
      • +
          +
        • Data Source Name
        • +
        • NaturalEarth
        • +
        +
      • +
      • +
          +
        • Description
        • +
        • GeoPackage of NaturalEarth data
        • +
        +
      • +

      This information is internal to GeoServer and is not used as part of the web service protocols. We recommend keeping the Data Source Name simple as they will be used to form folders in the data directory (so keep any operating system restrictions on character use in mind).

      Basic Store info

      @@ -2048,21 +2078,35 @@

      Create a store

      - - + - - - - - - +
      FieldValue
      Databasefile:data/ne/natural_earth.gpkg
      Read onlychecked
      +
        +
      • +
          +
        • Field
        • +
        • Value
        • +
        +
      • +
      • +
          +
        • Database
        • +
        • file:data/ne/natural_earth.gpkg
        • +
        +
      • +
      • +
          +
        • Read only
        • +
        • checked
        • +
        +
      • +

      The use of read_only above indicates that we will not be writing to this GeoPackage, allowing GeoServer to avoid managing write locks when accessing this content for greater performance.

      Connection Parameters

      @@ -2100,25 +2144,41 @@

      Creating a layer

      - - + - - - - - - - - - - +
      FieldValue
      Namecountries
      TitleCountries
      AbstractSovereign states
      +
        +
      • +
          +
        • Field
        • +
        • Value
        • +
        +
      • +
      • +
          +
        • Name
        • +
        • countries
        • +
        +
      • +
      • +
          +
        • Title
        • +
        • Countries
        • +
        +
      • +
      • +
          +
        • Abstract
        • +
        • Sovereign states
        • +
        +
      • +

      The naming of a layer is important, and while GeoServer does not offer restrictions many of the individual protocols will only work with very simple names.

      Basic Resource Info

      @@ -2128,25 +2188,41 @@

      Creating a layer

      - - + - - - - - - - - - - +
      FieldValue
      Native SRSEPSG:4326
      Declaired SRSEPSG:4326
      SRS HandlingForce declared
      +
        +
      • +
          +
        • Field
        • +
        • Value
        • +
        +
      • +
      • +
          +
        • Native SRS
        • +
        • EPSG:4326
        • +
        +
      • +
      • +
          +
        • Declaired SRS
        • +
        • EPSG:4326
        • +
        +
      • +
      • +
          +
        • SRS Handling
        • +
        • Force declared
        • +
        +
      • +

      Coordinate Reference Systems

      diff --git a/gettingstarted/group-quickstart/index.html b/gettingstarted/group-quickstart/index.html index dede6cbaed6..82be89f6740 100644 --- a/gettingstarted/group-quickstart/index.html +++ b/gettingstarted/group-quickstart/index.html @@ -1913,12 +1913,44 @@

      Create a layer group

    • Locate Basic Resource Info and define the layer:

      -
      -

      Name basemap

      -

      Title Basemap

      -

      Abstract Plain basemap suitable as a backdrop for geospatial data.

      -

      Workspace tutorial

      -
      + + + + + + + + + + + +
      +
        +
      • +
          +
        • Name
        • +
        • basemap
        • +
        +
      • +
      • +
          +
        • Title
        • +
        • Basemap
        • +
        +
      • +
      • +
          +
        • Abstract
        • +
        • Plain basemap suitable as a backdrop for geospatial data.
        • +
        +
      • +
      • +
          +
        • Workspace
        • +
        • tutorial
        • +
        +
      • +

      Basic resource information

    • diff --git a/gettingstarted/image-quickstart/index.html b/gettingstarted/image-quickstart/index.html index ad082aa7e9f..47602c5c7bb 100644 --- a/gettingstarted/image-quickstart/index.html +++ b/gettingstarted/image-quickstart/index.html @@ -1957,10 +1957,32 @@

      Creating a new workspace

    • You will be prompted to enter a workspace Name and Namespace URI.

      -
      -

      Name: tutorial

      -

      Namespace URI http://localhost:8080/geoserver/tutorial

      -
      + + + + + + + + + + + +
      +
        +
      • +
          +
        • Name:
        • +
        • tutorial
        • +
        +
      • +
      • +
          +
        • Namespace URI
        • +
        • http://localhost:8080/geoserver/tutorial
        • +
        +
      • +

      Note

      A workspace name is an identifier describing your project. It must not exceed ten characters or contain spaces.

      @@ -1999,11 +2021,38 @@

      Create a store

    • Begin by configuring the Basic Store Info.

      -
      -

      workspace tutorial

      -

      Data Source Name ShadedRelief

      -

      Description Grayscale shaded relief of land areas.

      -
      + + + + + + + + + + + +
      +
        +
      • +
          +
        • workspace
        • +
        • tutorial
        • +
        +
      • +
      • +
          +
        • Data Source Name
        • +
        • ShadedRelief
        • +
        +
      • +
      • +
          +
        • Description
        • +
        • Grayscale shaded relief of land areas.
        • +
        +
      • +

      This information is internal to GeoServer and is not used as part of the web service protocols. We recommend keeping the Data Source Name simple as they will be used to form folders in the data directory (so keep any operating system restrictions on character use in mind).

      Basic Store info

      @@ -2016,9 +2065,26 @@

      Create a store

    • The Connection Parameters for our geopackage are:

      -
      -

      database file:data/ne/SR_50M.tif

      -
      + + + + + + + + + + + +
      +
        +
      • +
          +
        • database
        • +
        • file:data/ne/SR_50M.tif
        • +
        +
      • +

      The use of read_only above indicates that we will not be writing to this GeoPackage, allowing GeoServer to avoid managing write locks when accessing this content for greater performance.

      Connection Parameters

      @@ -2049,11 +2115,38 @@

      Creating a layer

    • Locate Basic Resource Info and define the layer:

      -
      -

      Name shaded

      -

      Title Shaded Relief

      -

      Abstract Grayscale shaded relief of land areas.

      -
      + + + + + + + + + + + +
      +
        +
      • +
          +
        • Name
        • +
        • shaded
        • +
        +
      • +
      • +
          +
        • Title
        • +
        • Shaded Relief
        • +
        +
      • +
      • +
          +
        • Abstract
        • +
        • Grayscale shaded relief of land areas.
        • +
        +
      • +

      The naming of a layer is important, and while GeoServer does not offer restrictions many of the individual protocols will only work with very simple names.

      Basic Resource Info

      @@ -2064,11 +2157,38 @@

      Creating a layer

      Note

      In this case select Force declared to prefer the GeoServer internal EPSG database definition of WGS84 over the prj file provided alongside the same image.

    • -
      -

      Native SRS EPSG:4326

      -

      Declaired SRS EPSG:4326

      -

      SRS Handling Force declared

      -
      + + + + + + + + + + + +
      +
        +
      • +
          +
        • Native SRS
        • +
        • EPSG:4326
        • +
        +
      • +
      • +
          +
        • Declaired SRS
        • +
        • EPSG:4326
        • +
        +
      • +
      • +
          +
        • SRS Handling
        • +
        • Force declared
        • +
        +
      • +

      Coordinate Reference Systems

      diff --git a/gettingstarted/postgis-quickstart/index.html b/gettingstarted/postgis-quickstart/index.html index 62f6966f50d..2e13f5090ca 100644 --- a/gettingstarted/postgis-quickstart/index.html +++ b/gettingstarted/postgis-quickstart/index.html @@ -2003,45 +2003,71 @@

      Creating a store

      - - + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
      OptionValue
      dbtypepostgis
      hostlocalhost
      port5432
      databasenyc
      schemapublic
      userpostgres
      passwd(Password for the postgres user)
      validate connections(Checked)
      +
        +
      • +
          +
        • Option
        • +
        • Value
        • +
        +
      • +
      • +
          +
        • dbtype
        • +
        • postgis
        • +
        +
      • +
      • +
          +
        • host
        • +
        • localhost
        • +
        +
      • +
      • +
          +
        • port
        • +
        • 5432
        • +
        +
      • +
      • +
          +
        • database
        • +
        • nyc
        • +
        +
      • +
      • +
          +
        • schema
        • +
        • public
        • +
        +
      • +
      • +
          +
        • user
        • +
        • postgres
        • +
        +
      • +
      • +
          +
        • passwd
        • +
        • (Password for the postgres user)
        • +
        +
      • +
      • +
          +
        • validate connections
        • +
        • (Checked)
        • +
        +
      • +

      Note

      Leave all other fields at their default values.

      diff --git a/gettingstarted/style-quickstart/index.html b/gettingstarted/style-quickstart/index.html index a9523732651..c5b1eb2d2d1 100644 --- a/gettingstarted/style-quickstart/index.html +++ b/gettingstarted/style-quickstart/index.html @@ -1887,11 +1887,38 @@

      Create a style

    • Locate Style Data and define the style:

      -
      -

      Name background

      -

      Workspace tutorial

      -

      Format SLD

      -
      + + + + + + + + + + + +
      +
        +
      • +
          +
        • Name
        • +
        • background
        • +
        +
      • +
      • +
          +
        • Workspace
        • +
        • tutorial
        • +
        +
      • +
      • +
          +
        • Format
        • +
        • SLD
        • +
        +
      • +

      Style data

    • diff --git a/production/config/index.html b/production/config/index.html index 43a6e5d91a8..b17388783fa 100644 --- a/production/config/index.html +++ b/production/config/index.html @@ -1927,13 +1927,36 @@

      Logging configuration hardening

      Set a service strategy

      A service strategy is the method in which output is served to the client. This is a balance between proper form (being absolutely sure of reporting errors with the proper OGC codes, etc.) and speed (serving output as quickly as possible). This is a decision to be made based on the function that GeoServer is providing. You can configure the service strategy by modifying the web.xml file of your GeoServer instance.

      The possible strategies are:

      -
      -

      Strategy Description

      -

      SPEED Serves output right away. This is the fastest strategy, but proper OGC errors are usually omitted.

      -

      BUFFER Stores the whole result in memory, and then serves it after the output is complete. This ensures proper OGC error reporting, but delays the response quite a bit and can exhaust memory if the response is large.

      -

      FILE Similar to BUFFER, but stores the whole result in a file instead of in memory. Slower than BUFFER, but ensures there won't be memory issues.

      -

      PARTIAL-BUFFER A balance between BUFFER and SPEED, this strategy tries to buffer in memory a few KB of response, then serves the full output.

      -
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      StrategyDescription
      SPEEDServes output right away. This is the fastest strategy, but proper OGC errors are usually omitted.
      BUFFERStores the whole result in memory, and then serves it after the output is complete. This ensures proper OGC error reporting, but delays the response quite a bit and can exhaust memory if the response is large.
      FILESimilar to BUFFER, but stores the whole result in a file instead of in memory. Slower than BUFFER, but ensures there won't be memory issues.
      PARTIAL-BUFFERA balance between BUFFER and SPEED, this strategy tries to buffer in memory a few KB of response, then serves the full output.

      Personalize your server

      This isn't a performance consideration, but it is just as important. In order to make GeoServer as useful as possible, you should customize the server's metadata to your organization. It may be tempting to skip some of the configuration steps, and leave in the same keywords and abstract as the sample, but this will only confuse potential users.

      Suggestions:

      diff --git a/production/container/index.html b/production/container/index.html index 96d2e03d1cc..a78a863ed99 100644 --- a/production/container/index.html +++ b/production/container/index.html @@ -1680,15 +1680,44 @@

      Container Considerations

      Java web containers such as Tomcat or Jetty ship with configurations that allow for fast startup, but don't always deliver the best performance.

      Optimize your JVM

      Set the following performance settings in the Java virtual machine (JVM) for your container. These settings are not specific to any container.

      -
      -

      Option Description

      -

      -Xms128m By starting with a larger heap GeoServer will not need to pause and ask the operating system for more memory during heavy load. The setting -Xms128m will tell the virtual machine to acquire grab a 128m heap memory on initial startup.

      -

      -Xmx756M Defines an upper limit on how much heap memory Java will request from the operating system (use more if you have excess memory). By default, the JVM will use ¼ of available system memory. The setting -Xms756m allocates 756MB of memory to GeoServer.

      -

      -XX:SoftRefLRUPolicyMSPerMB=36000 Increases the lifetime of "soft references" in GeoServer. GeoServer uses soft references to cache datastore, spatial reference systems, and other data structures. By increasing this value to 36000 (which is 36 seconds) these values will stay in memory longer increasing the effectiveness of the cache.

      -

      -XX:+UseParallelGC This garbage collector pauses the application while using several threads to recover memory. Recommended if your GeoServer will be under light load and can tolerate pauses to clean up memory.

      -

      -XX:+UseParNewGC Enables use of the concurrent mark sweep (CMS) garbage collector uses multiple threads to recover memory while the application is running. Recommended for GeoServer under continuous use, with heap sizes of less than 6GB.

      -

      –XX:+UseG1GC The default garbage collector since Java 9. Enables use of the Garbage First Garbage Collector (G1) using background threads to scan memory while the application is running prior to cleanup. Recommended for GeoServer under continuous load and heap sizes of 6GB or more. Additionally you may experiment with -XX:+UseStringDeduplicationJVM to ask G1 to better manage common text strings in memory.

      -
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      OptionDescription
      -Xms128mBy starting with a larger heap GeoServer will not need to pause and ask the operating system for more memory during heavy load. The setting -Xms128m will tell the virtual machine to acquire grab a 128m heap memory on initial startup.
      -Xmx756MDefines an upper limit on how much heap memory Java will request from the operating system (use more if you have excess memory). By default, the JVM will use ¼ of available system memory. The setting -Xms756m allocates 756MB of memory to GeoServer.
      -XX:SoftRefLRUPolicyMSPerMB=36000Increases the lifetime of "soft references" in GeoServer. GeoServer uses soft references to cache datastore, spatial reference systems, and other data structures. By increasing this value to 36000 (which is 36 seconds) these values will stay in memory longer increasing the effectiveness of the cache.
      -XX:+UseParallelGCThis garbage collector pauses the application while using several threads to recover memory. Recommended if your GeoServer will be under light load and can tolerate pauses to clean up memory.
      -XX:+UseParNewGCEnables use of the concurrent mark sweep (CMS) garbage collector uses multiple threads to recover memory while the application is running. Recommended for GeoServer under continuous use, with heap sizes of less than 6GB.
      –XX:+UseG1GCThe default garbage collector since Java 9. Enables use of the Garbage First Garbage Collector (G1) using background threads to scan memory while the application is running prior to cleanup. Recommended for GeoServer under continuous load and heap sizes of 6GB or more. Additionally you may experiment with -XX:+UseStringDeduplicationJVM to ask G1 to better manage common text strings in memory.

      For more information about JVM configuration, see the article Performance tuning garbage collection in Java and The 4 Java Garbage Collectors.

      Note

      diff --git a/rest/about/index.html b/rest/about/index.html index 7fa071efb56..4a470658936 100644 --- a/rest/about/index.html +++ b/rest/about/index.html @@ -1851,16 +1851,48 @@

      System Status

      System status

      The XML and JSON representations are quite similar. For each system information metric, the following attributes will be available:

      -
      -

      Name Description

      -

      name name of the metric

      -

      available TRUE if the system information value is available

      -

      description description of this system information

      -

      unit unit of the system information, can be empty

      -

      category category of this system information

      -

      priority this value can be used to render the metrics in a predefined order

      -

      identifier identifies the resource associated with the metric, e.g. file partition name

      -
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      NameDescription
      namename of the metric
      availableTRUE if the system information value is available
      descriptiondescription of this system information
      unitunit of the system information, can be empty
      categorycategory of this system information
      prioritythis value can be used to render the metrics in a predefined order
      identifieridentifies the resource associated with the metric, e.g. file partition name

      Example of XML representation:

      <metrics>
         <metric>
      diff --git a/rest/api/resources/index.html b/rest/api/resources/index.html
      index 06c07829b55..91e2dc1209e 100644
      --- a/rest/api/resources/index.html
      +++ b/rest/api/resources/index.html
      @@ -2286,14 +2286,42 @@
       
       

      Resources

      /resource</path/to/resource>

      -
      -

      Method Action Status code Parameters

      -
      -

      GET Download a resource, list contents of directory, or show formatted resource metadata. 200 operation (default | metadata); format (html | xml | json)

      -

      HEAD Show resource metadata in HTTP headers. 200

      -

      PUT Upload/move/copy a resource, create directories on the fly (overwrite if exists). For move/copy operations, place source path in body. Copying is not supported for directories. 200 (exists) 201 (new) operation (default | copy | move)

      -

      DELETE Delete a resource (recursively if directory) 200

      -
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      MethodActionStatus codeParameters
      GETDownload a resource, list contents of directory, or show formatted resource metadata.200operation (default
      HEADShow resource metadata in HTTP headers.200
      PUTUpload/move/copy a resource, create directories on the fly (overwrite if exists). For move/copy operations, place source path in body. Copying is not supported for directories.200 (exists) 201 (new)operation (default
      DELETEDelete a resource (recursively if directory)200

      Exceptions

      diff --git a/rest/api/selfadmin/index.html b/rest/api/selfadmin/index.html index 4b911535cf2..616327b1974 100644 --- a/rest/api/selfadmin/index.html +++ b/rest/api/selfadmin/index.html @@ -2241,12 +2241,27 @@

      /security/self/password

      { "newPassword":"newPassword" }
       

      Exceptions

      -
      -

      Exception Status code Error string (payload)

      -
      -

      PUT with an invalid newPassword or bad params 400 Missing 'newPassword'

      -

      PUT for user not updatable 424 User service does not support changing pw

      -
      +
      + + + + + + + + + + + + + + + + + + + +
      ExceptionStatus codeError string (payload)
      PUT with an invalid newPassword or bad params400Missing 'newPassword'
      PUT for user not updatable424User service does not support changing pw
      diff --git a/rest/api/userrole/index.html b/rest/api/userrole/index.html index e9432790e2d..42b2c3ec4bc 100644 --- a/rest/api/userrole/index.html +++ b/rest/api/userrole/index.html @@ -2523,88 +2523,237 @@

      Configuration

      Requests

      /rest/usergroup/[service/<serviceName>/]users/

      Query all users or add a new user in a particular or the default user/group service.

      -
      -

      Method Action Response

      -
      -

      GET List all users in service. 200 OK. List of users in XML.

      -

      POST Add a new user 201 Inserted. Created ID header.

      -
      + + + + + + + + + + + + + + + + + + + + +
      MethodActionResponse
      GETList all users in service.200 OK. List of users in XML.
      POSTAdd a new user201 Inserted. Created ID header.

      /rest/usergroup/[service/<serviceName>/]user/<user>

      Query, modify or delete a specific user in a particular or the default user/group service.

      -
      -

      Method Action Response

      -
      -

      GET Read user information 200 OK. User in XML.

      -

      POST Modify the user, unspecified fields remain unchanged. 200 OK.

      -

      DELETE Delete the user 200 OK.

      -
      + + + + + + + + + + + + + + + + + + + + + + + + + +
      MethodActionResponse
      GETRead user information200 OK. User in XML.
      POSTModify the user, unspecified fields remain unchanged.200 OK.
      DELETEDelete the user200 OK.

      /rest/usergroup/[service/<serviceName>/]groups/

      Query all groups in a particular user/group or the default service.

      -
      -

      Method Action Response

      -
      -

      GET List all groups in service. 200 OK. List of groups in XML.

      -
      + + + + + + + + + + + + + + + +
      MethodActionResponse
      GETList all groups in service.200 OK. List of groups in XML.

      /rest/usergroup/[service/<serviceName>/]group/<group>

      Add or delete a specific group in a particular or the default user/group service.

      -
      -

      Method Action Response

      -
      -

      POST Add the group. 200 OK.

      -

      DELETE Delete the group. 200 OK.

      -
      + + + + + + + + + + + + + + + + + + + + +
      MethodActionResponse
      POSTAdd the group.200 OK.
      DELETEDelete the group.200 OK.

      /rest/usergroup/[service/<serviceName>/]user/<user>/groups

      Query all groups associated with a user in a particular or the default user/group service.

      -
      -

      Method Action Response

      -
      -

      GET List all groups associated with user. 200 OK. List of groups in XML.

      -
      + + + + + + + + + + + + + + + +
      MethodActionResponse
      GETList all groups associated with user.200 OK. List of groups in XML.

      /rest/usergroup/[service/<serviceName>/]group/<group>/users

      Query all users associated with a group in a particular or the default user/group service.

      -
      -

      Method Action Response

      -
      -

      GET List all users associated with group. 200 OK. List of groups in XML.

      -
      + + + + + + + + + + + + + + + +
      MethodActionResponse
      GETList all users associated with group.200 OK. List of groups in XML.

      /rest/usergroup/[service/<serviceName>/]<user>/group/<group>

      Associate or disassociate a specific user with a specific group in a particular or the default user/group service.

      -
      -

      Method Action Response

      -
      -

      POST Associate the user with the group. 200 OK.

      -

      DELETE Disassociate the user from the group. 200 OK.

      -
      + + + + + + + + + + + + + + + + + + + + +
      MethodActionResponse
      POSTAssociate the user with the group.200 OK.
      DELETEDisassociate the user from the group.200 OK.

      rest/roles/[service/{serviceName}/]

      Query all roles in a particular role service or the active role service.

      -
      -

      Method Action Response

      -
      -

      GET List all roles in service. 200 OK. List of roles in XML.

      -
      + + + + + + + + + + + + + + + +
      MethodActionResponse
      GETList all roles in service.200 OK. List of roles in XML.

      /rest/roles/[service/<serviceName>/]role/<role>

      Add or delete a specific role in a particular role service or the active role service.

      -
      -

      Method Action Response

      -
      -

      POST Add the role. 200 OK.

      -

      DELETE Delete the role. 200 OK.

      -
      + + + + + + + + + + + + + + + + + + + + +
      MethodActionResponse
      POSTAdd the role.200 OK.
      DELETEDelete the role.200 OK.

      /rest/roles/[service/<serviceName>/]<serviceName>/user/<user>/roles

      Query all roles associated with a user in a particular role service or the active role service.

      -
      -

      Method Action Response

      -
      -

      GET List all roles associated with user. 200 OK. List of roles in XML.

      -
      + + + + + + + + + + + + + + + +
      MethodActionResponse
      GETList all roles associated with user.200 OK. List of roles in XML.

      /rest/roles/[service/<serviceName>/]role/<role>/user/<user>/

      Associate or disassociate a specific user with a specific role in a particular role service or the active role service.

      -
      -

      Method Action Response

      -
      -

      POST Associate the user with the role. 200 OK.

      -

      DELETE Disassociate the user from the role. 200 OK.

      -
      + + + + + + + + + + + + + + + + + + + + +
      MethodActionResponse
      POSTAssociate the user with the role.200 OK.
      DELETEDisassociate the user from the role.200 OK.
      diff --git a/search/search_index.json b/search/search_index.json index 45e5cd7a708..212d72dfe4e 100644 --- a/search/search_index.json +++ b/search/search_index.json @@ -1 +1 @@ -{"config":{"lang":["en"],"separator":"[\\s\\-]+","pipeline":["stopWordFilter"]},"docs":[{"location":"","title":"GeoServer User Manual","text":"

      GeoServer is an open source software server written in Java that allows users to share and edit geospatial data. Designed for interoperability, it publishes data from any major spatial data source using open standards.

      This User Manual is a comprehensive guide to all aspects of using GeoServer. Whether you are a novice or a veteran user of this software, we hope that this documentation will be a helpful reference.

      Introduction

      Learn about GeoServer.

      Installation

      Install GeoServer for your platform.

      Getting started

      Tutorials to help you get started with GeoServer.

      Web administration interface

      Navigate the GeoServer graphical interface.

      Data management

      Load and publish data from a variety of sources.

      Styling

      Styling and visualization for published layers in GeoServer.

      Services

      OGC services, the primary method of publishing data in GeoServer.

      Filtering

      Filter your requests and responses to increase efficiency.

      Server configuration

      Configuration options for GeoServer administrators.

      GeoServer data directory

      Settings and configuration files for GeoServer.

      Running in a production environment

      Best practices for using GeoServer.

      REST

      Interact programmatically with GeoServer without using the graphical interface.

      Security

      Secure and restrict access to data and services.

      GeoWebCache

      Accelerate your GeoServer with tile caching.

      Extensions

      Add extra functionality to GeoServer with extensions.

      Community modules

      Add cutting-edge functionality to GeoServer with community modules.

      Tutorials

      Other tips and tricks for getting the most out of your GeoServer instance.

      "},{"location":"community/","title":"Community modules","text":"

      This section is devoted to GeoServer community modules. Community modules are considered \"pending\" in that they are not officially part of the GeoServer releases. They are however built along with the nightly builds, so you can download and play with them.

      Warning

      Community modules are generally considered experimental in nature and are often under constant development. For that reason documentation in this section should not be considered solid or final and will be subject to change.

      Note

      Unlike the official extensions, these modules are not released and stored on SourceForge when an official GeoServer release is produced. As a consequence, using a module built against the nightly build of GeoServer with an official release won't probably work.

      If you need a community module for an official release, the only way is to build it with the sources of the GitHub tag matching the release.

      • Backup and Restore Documentation
      • COG (Cloud Optimized GeoTIFF) Documentation
      • Dynamic colormap generation
      • CoverageJSON output format
      • DDS/BIL(World Wind Data Formats) Extension
      • Elasticsearch data store
      • Features-Templating Extension
      • WFS FlatGeobuf output format
      • GDAL based WCS Output Format
      • GeoMesa data store
      • GeoPackage Extension
      • GeoStyler
      • Graticule Extension
      • GSR Extension
      • GWC Azure BlobStore plugin
      • GWC Distributed Caching community module
      • GWC MBTiles layer plugin
      • GWC SQLite Plugin
      • SAP HANA
      • Imagemap
      • Importer JDBC storage
      • JDBCConfig
      • JDBCStore
      • Introduction
      • Keycloak extension
      • Libdeflate
      • MBTiles Extension
      • Monitoring Hibernate storage
      • Monitoring Kafka storage
      • ncWMS WMS extensions support
      • GHRSST NetCDF output
      • Notification community module Plugin Documentation
      • Authentication with OAuth2
      • OGC API modules
      • OGR datastore
      • OpenSearch for EO
      • PGRaster
      • Proxy Base Extension
      • Raster Attribute Table support
      • WPS Remote community module
      • S3 Support for GeoTiff
      • Schemaless Features Plugin
      • Smart Data Loader Extension
      • SpatialJSON WFS Output Format Extension
      • STAC Datastore extension
      • SOLR data store
      • Geoserver Task Manager
      • Vector Mosaic datastore
      • VSI Virtual File System Support
      • XSLT WFS output format module
      • HTTP Based Authorization plug-in
      • WMS WebP output format
      • WPS longitudinal profile process
      "},{"location":"community/imagemap/","title":"Imagemap","text":"

      HTML ImageMaps have been used for a long time to create interactive images in a light way. Without using Flash, SVG or VML you can simply associate different links or tooltips to different regions of an image. Why can't we use this technique to achieve the same result on a GeoServer map? The idea is to combine a raster map (png, gif, jpeg, ...) with an HTML ImageMap overlay to add links, tooltips, or mouse events behavior to the map.

      An example of an ImageMap adding tooltips to a map:

      <img src=\"...\" usemap=\"#mymap\"/>\n<map name=\"mymap\">\n     <area shape=\"poly\" coords=\"536,100 535,100 534,101 533,101 532,102\"  title=\"This is a tooltip\"/>\n     <area shape=\"poly\" coords=\"518,113 517,114 516,115 515,114\"  title=\"Another tooltip\"/>\n</map>\n

      An example of an ImageMap adding links to a map:

      <img src=\"...\" usemap=\"#mymap\"/>\n<map name=\"mymap\">\n     <area shape=\"poly\" coords=\"536,100 535,100 534,101 533,101 532,102\"  href=\"http://www.mylink.com\"/>\n     <area shape=\"poly\" coords=\"518,113 517,114 516,115 515,114\"  href=\"http://www.mylink2.com\"/>\n</map>\n

      A more complex example adding interactive behaviour on mouse events:

      <img src=\"...\" usemap=\"#mymap\"/>\n<map name=\"mymap\">\n     <area shape=\"poly\" coords=\"536,100 535,100 534,101 533,101 532,102\"  onmouseover=\"onOver('<featureid>')\" onmouseout=\"onOut('<featureid>')\"/>\n     <area shape=\"poly\" coords=\"518,113 517,114 516,115 515,114\"   onmouseover=\"onOver('<featureid>')\" onmouseout=\"onOut('<featureid>')\"/>\n</map>\n

      To realize this in GeoServer some great community contributors developed an HTMLImageMap GetMapProducer for GeoServer, able to render an HTMLImageMap in response to a WMS GetMap request.

      The GetMapProducer is associated to the text/html mime type. It produces, for each requested layer, a ... section containing the geometries of the layer as distinct tags. Due to the limitations in the shape types supported by the tag, a single geometry can be split into multiple ones. This way almost any complex geometry can be rendered transforming it into simpler ones.

      To add interactive attributes we use styling. In particular, an SLD Rule containing a TextSymbolizer with a Label definition can be used to define dynamic values for the tags attributes. The Rule name will be used as the attribute name.

      As an example, to define a title attribute (associating a tooltip to the geometries of the layer) you can use a rule like the following one:

      <Rule>\n   <Name>title</Name>\n   <TextSymbolizer>\n      <Label><PropertyName>MYPROPERTY</PropertyName></Label>\n   </TextSymbolizer>\n</Rule>\n

      To render multiple attributes, just define multiple rules, with different names (href, onmouseover, etc.)

      Styling support is not limited to TextSymbolizers, you can currently use other symbolizers to detail rendering. For example you can:

      • use a PointSymbolizer with a Size property to define point sizes.
      • use LineSymbolizer with a stroke-width CssParameter to create thick lines.
      "},{"location":"community/backuprestore/","title":"Backup and Restore Documentation","text":"

      This section describes the GeoServer Backup and Restore plugin functionality and APIs.

      • Installation
      • Usage Via GeoServer's User Interface
      • Usage Via GeoServer's REST API
      • Backup and Restore Extension for the management of ImageMosaic indexers
      • Use Cases
      "},{"location":"community/backuprestore/extensions/","title":"Backup and Restore Extension for the management of ImageMosaic indexers","text":""},{"location":"community/backuprestore/extensions/#introduction","title":"Introduction","text":"

      ImageMosaics CoverageStores make use of several .properties files instructing the reader on how to create the mosaic index.

      What we want to achieve is to allow the GeoServer Backup & Restore module to inject environment properties on indexers allowing the ImageMosaic to be automatically ported among different environments.

      "},{"location":"community/backuprestore/extensions/#technical-details","title":"Technical Details","text":"

      The GeoServer Backup & Restore module actually provides an extension point on reading / writing allowing GeoServer to handle additional resources related to a particular ResourceInfo.

      The interfaces :

      public interface CatalogAdditionalResourcesWriter<T> {\n\n    public boolean canHandle(Object item);\n\n    public void writeAdditionalResources(Backup backupFacade, Resource base, T item)\n            throws IOException;\n\n}\n\npublic interface CatalogAdditionalResourcesReader<T> {\n\n    public boolean canHandle(Object item);\n\n    public void readAdditionalResources(Backup backupFacade, Resource base, T item)\n            throws IOException;\n\n}\n

      Is invoked by the CatalogFileWriter (when doing a Backup) and the CatalogItemWriter (when doing a Restore) after a successful write of the resource configuration on the, respectively, target backup folder and in-memory catalog.

      The idea is the following one allowing the CatalogItemWriter to:

      1. Restore the ImageMosaic Indexer Properties injecting environment properties
      2. Check if the Mosaic index physically exist and if not create an empty one

      In order to do that we envisage the following technical approach

      On a BACKUP operation

      1. The Additional Resource Writer checks if the ResourceInfo is an ImageMosaic Coverage Store.
      2. The Additional Resource Writer looks for *.template files on the ImageMosaic index directory. It must store them into the zip archive by reading the path from the Coverage Store.
      3. The Additional Resource Writer stores the *.template along with the *.properties files on the target backup folder. Same as above.

      On a RESTORE operation

      1. The Additional Resource Reader checks if the ResourceInfo is an ImageMosaic Coverage Store.
      2. The Additional Resource Reader looks for *.template files on the ImageMosaic index directory. It will try to restore them by using the path read from the Coverage Store configuration.
      3. The Additional Resource Reader overwrites the *.properties files by resolving all the environment properties declared on the templates.
      4. The Additional Resource Reader checks if the empty mosaic must be created or not.
      "},{"location":"community/backuprestore/installation/","title":"Installation","text":""},{"location":"community/backuprestore/installation/#manual-install","title":"Manual Install","text":"

      To download and install the required extensions by hand:

      1. Download the geoserver- 2.24.2-backup-restore-plugin.zip from:

        • Community Builds (GeoServer WebSite)

        It is important to download the version that matches the GeoServer you are running.

      2. Stop the GeoServer application.

      3. Navigate into the webapps/geoserver/WEB-INF/lib folder.

        These files make up the running GeoServer application.

      4. Unzip the contents of the zip file into the lib folder.

      5. Restart the Application Server.

      6. Login to the Web Administration application. Select Data from the naviagion menu. Click Backup and Restore and ensure the page is rendered correctly and without errors.

      Backup and Restore plugin can be used both via user interface and via HTTP REST interface. For more details please see the next sections.

      "},{"location":"community/backuprestore/usagegui/","title":"Usage Via GeoServer's User Interface","text":"

      At the end on Backup and Restore plugin installation you will see a new section in GeoServer UI

      Clicking on the Backup and Restore label will give you access to the Backup and Restore configuration settings:

      Here you'll be able to specify various parameters for the Backup / Restore procedure:

      1. Archive full path: Path on the file system to the archive created by the backup procedure, in case a Backup is executed, or the archive to restore from, in case of a Restore procedure.

      2. Filter by Workspace: Optional parameter that allows you to restrict the scope of the Backup / Restore to workspaces that meet the specified filter.

      3. Backup Options:

        1. Overwrite Existing Archive: When enabled the backup procedure will overwrite any previously existing archive
        2. Skip Failing Resources: If enabled and errors are found during the backup of existing resources, skip the resource and go ahead with the backup procedure
      4. Backup Executions: Report of running and previously run backups

      5. Restore Options:

        1. Dry Run: Test the restore procedure using the provided archive but do not apply any changes to current configuration. Useful to test archives before actually performing a Restore
        2. Skip Failing Resources: If enabled and errors are found during the restore of resources, skip the resource and go ahead with the restore procedure
      6. Restore Executions: Report of running and previously run restore

      "},{"location":"community/backuprestore/usagegui/#performing-a-full-backup-via-ui","title":"Performing a full backup via UI","text":"

      In order to perform a full backup, provide the full path of the target .zip archive where to store the configuration data.

      Note

      Please notice that the backup will store just the configuration files and not the original data.

      It is also possible to use the Browse instrument to navigate the server folders. In any case the backup procedure won't start until it find a valid .zip path archive.

      It is possible to select the backup options by enabling the appropriate checkboxes before starting the backup procedure.

      Note

      Please notice that while performing a backup or restore task, GeoServer won't allow users to access other sections by locking the catalog and configuration until the process has finished. Although it is always possible to stop or abandon a backup or restore procedure.

      At the end of the backup, the user will be redirected to an Execution Summary page

      The same page can be accessed also later by clicking an execution link from the main page.

      Note

      Please notice that the list of executions is not persisted and therefore it will be reset after a GeoServer container restart.

      At the bottom of the Execution Details page, it's possible to download the .zip archive directly by clicking on the Download Archive File link.

      In case some running exceptions or warning have been catched by the process, they will be presented on the execution summary. The Error Detail Level allows to inspect the causes by exposing the stack trace for each of them.

      "},{"location":"community/backuprestore/usagegui/#restoring-via-ui","title":"Restoring via UI","text":"

      The steps are almost the same of the backup. Just select the .zip archive full path before launching the restore process.

      Warning

      Please notice that a non-dry-run restore will lose all your current GeoServer configuration by replacing it with the new one, so be careful and be sure to backup everything before starting a restore.

      DRY-RUN RESTORE

      Dry Run option allows a user to test a .zip archive before actually performing a full restore.

      ::: note ::: title Note :::

      Please notice that the dry run should always being executed when trying to restore a new configuration. :::

      A failing restore dry-run will appear like this

      If some exception occurs, it will be listed on the execution summary page. The original cause can be inspected by rising up the errors details level and refreshing

      "},{"location":"community/backuprestore/usagegui/#savingrestoring-only-specific-workspaces","title":"Saving/restoring only specific workspaces","text":"

      It is possible to backup or restore only a subset of the available workspaces in the catalog. From the WEB interface is currently possible to select all or just one workspace to backup/restore

      Through the REST APIs it is possible to filter out also more than one workspaces as explained in the next sections.

      Note

      Please notice that from a backup archive containing filtered workspaces won't be possible to restore also the missing ones. In order to do that it is advisable to backup the whole catalog and then restore only the workspaces needed.

      "},{"location":"community/backuprestore/usagerest/","title":"Usage Via GeoServer's REST API","text":"

      The Backup and Restore REST API consists of a few resources meant to be used in an asynchronous fashion:

      Resource Method Parameters and Notes /rest/br/backup/ POST Post a JSON/XML document with the backup parameters, see below /rest/br/backup/backupId GET Returns a json/xml representation of the backup operation. See below /rest/br/backup/backupId DELETE Cancels the backup operation /rest/br/restore POST Post a JSON/XML document with the restore parameters, see below /rest/br/restore/restoreId GET Returns a json/xml representation of the backup operation, see below /rest/br/restore/restoreId DELETE Cancels the restore operation"},{"location":"community/backuprestore/usagerest/#usage-example","title":"Usage Example","text":"

      We are going to use the command line tool cURL to send HTTP REST requests to GeoServer.

      The /rest/br/backup/ and /rest/br/restore endpoints accept an optional format suffix that allows the Backup / Restore archive to be streamed to / from the client instead of being written on / read from the file system.

      Initiate a Backup

      Prepare a file containing with a JSON object representing the Backup procedure configuration.

      backup_post.json:

      {\n   \"backup\":{\n      \"archiveFile\":\"/home/sg/BackupAndRestore/test_rest_1.zip\",\n      \"overwrite\":true,\n      \"options\":{\n      }\n   }\n}\n

      In this case we did not specify any options in the backup configuration so default values will be used.

      Available options are:

      1. BK_BEST_EFFORT: Skip any failing resources and proceed with the backup procedure. Default: false.
      2. BK_PARAM_PASSWORDS: Whether outgoing store passwords should be parameterized in the backup. With this option set all store passwords will be replaced with a token that looks like \\${workspaceName:storeName.passwd.encryptedValue}. See also BK_PASSWORD_TOKENS for the Restore command.
      3. BK_SKIP_SECURITY: This will exclude security settings from the backup. Default: true.
      4. BK_SKIP_SETTINGS: This will attempt to exclude global settings from the backup, as well as security settings. Default: true.
      5. BK_SKIP_GWC: This option will avoid backup / restore the GWC catalog and folders. Default: false.
      6. BK_CLEANUP_TEMP: This will attempt to delete temporary folder at the end of the execution. Default: true.
      7. exclude.file.path: A ; separated list of paths relative to the GEOSERVER_DATA_DIR (e.g.: 'exclude.file.path=/data/geonode;/monitoring;/geofence'). If exist, the backup / restore will skip the path listed. Default: [[]]{.title-ref}. WARNING: security and workspaces are treated differently. This option should be used only for custom external resources located under the GEOSERVER_DATA_DIR.

      Also an optional Filter can be passed to restrict the scope of the restore operation to a list of workspaces.

      For example:

      {\n   \"backup\":{\n      \"archiveFile\":\"/home/sg/BackupAndRestore/test_rest_1.zip\",\n\"overwrite\":true,\n      \"options\":{\n        \"option\": [\"BK_BEST_EFFORT=true\"] \n      },\n\"filter\": \"name IN ('topp','geosolutions-it')\"\n   }\n}\n

      Backup procedure will be initiated.

      Here is a sample response:

      HTTP/1.1 201 Created\nDate: Mon, 01 Aug 2016 14:35:44 GMT\nLocation: http://mygeoserver/geoserver/rest/br/backup/1\nServer: Noelios-Restlet-Engine/1.0..8\nContent-Type: application/json\nTransfer-Encoding: chunked\n
      {\n   \"backup\":{\n      \"totalNumberOfSteps\":9,\n      \"execution\":{\n         \"id\":1,\n         \"version\":1,\n         \"stepExecutions\":{\n            \"@class\":\"java.util.concurrent.CopyOnWriteArraySet\"\n         },\n         \"status\":[\n            \"STARTED\"\n         ],\n         \"startTime\":\"2016-08-01 14:35:44.802 UTC\",\n         \"createTime\":\"2016-08-01 14:35:44.798 UTC\",\n         \"lastUpdated\":\"2016-08-01 14:35:44.803 UTC\",\n         \"exitStatus\":{\n            \"exitCode\":\"UNKNOWN\",\n            \"exitDescription\":\"\"\n         },\n         \"progress\":\"1\\/9\"\n      },\n      \"options\":{\n         \"@class\":\"synchList\",\n         \"option\":[\n            \"OVERWRITE=true\"\n         ]\n      },\n      \"warningsList\":{\n         \"@class\":\"synchList\"\n      },\n      \"archiveFile\":{\n         \"@class\":\"resource\",\n         \"$\":\"\\/home\\/sg\\/BackupAndRestore\\/test_rest_1.zip\"\n      },\n      \"overwrite\":true\n   }\n}\n

      At the end of the backup procedure you'll be able to download the generated archive to your local file system by making an HTTP GET request to the same endpoint, using the backup ID as above and adding the .zip at the end.

      curl -u \"admin:geoserver\" -i -X GET  \"http://mygeoserver/geoserver/rest/br/backup/1.zip\" -o 1.zip\n

      Query status of Backup executions

      Status of the operation can be queried making an HTTP GET request to the location listed in the response.

      ``http://mygeoserver/geoserver/rest/br/backup/$ID.{json/xml}``\n

      Replace $ID with the ID of the backup operation you'd like to inspect.

      curl -u \"admin:geoserver\" http://mygeoserver/geoserver/rest/br/backup/1.json\n

      or

      curl -u \"admin:geoserver\" http://mygeoserver/geoserver/rest/br/backup/1.xml\n

      GeoServer will respond with the status of the backup job corresponding to that ID

      Here you are able to see the status of all the steps involved in the backup procedure with creation time, start time, end time, exit status etc.

      Cancel a Backup

      Cancel an in progress Backup by sending an HTTP DELETE request with the ID of the task

      curl -v -XDELETE -u \"admin:geoserver\" http://mygeoserver/geoserver/rest/br/backup/$ID\n

      Replace $ID with the ID of the backup operation you'd like to cancel.

      Initiate a Restore

      Prepare a file with a JSON object representing the Restore procedure configuration

      restore_post.json:

      {\n   \"restore\":{\n      \"archiveFile\":\"/home/sg/BackupAndRestore/test_rest_1.zip\",\n      \"options\":{\n      }\n   }\n}\n

      In this case we did not specify any options in the restore configuration so default values will be used.

      Available Options are:

      1. BK_DRY_RUN: Only test the archive do not persist the restored configuration. Default: false.

      2. BK_BEST_EFFORT: Skip any failing resources and proceed with the restore procedure. Default: false.

      3. BK_PASSWORD_TOKENS: A comma separated list of equal sign separated key/values to be replaced in data store passwords in an incoming backup. For example:

        BK_PASSWORD_TOKENS=${workspace:store1.passwd.encryptedValye}=foo,${workspace:store2.passwd.encryptedValue}=bar\n
      4. BK_SKIP_SECURITY: This will exclude security settings from the restore. Default: true.

      5. BK_SKIP_SETTINGS: This will attempt to exclude global settings from the backup, as well as security settings. Default: true.

      6. BK_PURGE_RESOURCES: If 'false' this parameter will avoid deleting incoming resources where possible. In particular, existing workspaces will not be deleted during the restore. Default: true.

      7. BK_SKIP_GWC: This option will avoid backup / restore the GWC catalog and folders. Default: false.

      8. BK_CLEANUP_TEMP: This will attempt to delete temporary folder at the end of the execution. Default: true.

      9. exclude.file.path: A ; separated list of paths relative to the GEOSERVER_DATA_DIR (e.g.: 'exclude.file.path=/data/geonode;/monitoring;/geofence'). If exist, the backup / restore will skip the path listed. Default: [[]]{.title-ref}. WARNING: security and workspaces are treated differently. This option should be used only for custom external resources located under the GEOSERVER_DATA_DIR.

      Also an optional Filter can be passed to restrict the scope of the restore operation to a list of workspaces.

      For example:

      {\n   \"restore\":{\n      \"archiveFile\":\"/home/sg/BackupAndRestore/test_rest_1.zip\",\n      \"options\":{\n        \"option\": [\"BK_DRY_RUN=true\"] \n      },\n\"filter\": \"name IN ('topp','geosolutions-it')\"\n   }\n}\n

      If archiveFile is specified, the archive specified on that path of the remote file system will be used to initiate the restore procedure. Otherwise the archive needs to be uploaded from your local system.

      Then make a POST HTTP request to GeoServer's REST interface endpoint for the restore procedure

      curl -u \"admin:geoserver\" -i -H \"Content-Type: application/json\" -X POST --data @restore_post.json http://mygeoserver/geoserver/rest/br/restore/\n

      Restore procedure will be initiated.

      Here is a sample response:

      HTTP/1.1 201 Created\nDate: Mon, 01 Aug 2016 15:07:29 GMT\nLocation: http://mygeoserver/geoserver/rest/br/restore/2\nServer: Noelios-Restlet-Engine/1.0..8\nContent-Type: application/json\nTransfer-Encoding: chunked\n
      {\n   \"restore\":{\n      \"totalNumberOfSteps\":9,\n      \"execution\":{\n         \"id\":2,\n         \"version\":1,\n         \"stepExecutions\":{\n            \"@class\":\"java.util.concurrent.CopyOnWriteArraySet\"\n         },\n         \"status\":[\n            \"STARTED\"\n         ],\n         \"startTime\":\"2016-08-01 15:07:29.398 UTC\",\n         \"createTime\":\"2016-08-01 15:07:29.393 UTC\",\n         \"lastUpdated\":\"2016-08-01 15:07:29.398 UTC\",\n         \"exitStatus\":{\n            \"exitCode\":\"UNKNOWN\",\n            \"exitDescription\":\"\"\n         },\n         \"progress\":\"0\\/9\"\n      },\n      \"options\":{\n         \"@class\":\"synchList\"\n      },\n      \"warningsList\":{\n         \"@class\":\"synchList\"\n      },\n      \"archiveFile\":{\n         \"@class\":\"resource\",\n         \"$\":\"\\/home\\/sg\\/BackupAndRestore\\/test_rest_1.zip\"\n      }\n   }\n}\n

      To upload the archive from our local system instead, omit the archiveFile parameter in the JSON object and pass the --upload-file parameter to cURL:

      restore_post.json:

      {\n   \"restore\":{\n      \"options\":{\n      },\n   }\n}\n
      curl -u \"admin:geoserver\" -i -H \"Content-Type: application/json\" --upload-file \"archive_to_restore.zip\" -X POST --data @restore_post.json http://localhost:8081/geoserver/rest/br/restore/\n

      Local archive_to_restore.zip archive will be uploaded and used by the restore procedure.

      Query for status of Restore operations

      http://mygeoserver/geoser/restore/$ID.{json/xml}:

      {\n   \"restore\":{\n      \"execution\":{\n         \"hash\":2,\n         \"key\":{\n            \"@class\":\"long\",\n            \"$\":\"2\"\n         },\n         \"val\":{\n            \"@class\":\"restore\",\n            \"totalNumberOfSteps\":9,\n            \"execution\":{\n               \"id\":2,\n               \"version\":2,\n               \"stepExecutions\":{\n                  \"@class\":\"java.util.concurrent.CopyOnWriteArraySet\",\n                  \"step\":[\n                     {\n                        \"name\":\"restoreNamespaceInfos\",\n                        \"status\":\"COMPLETED\",\n                        \"exitStatus\":{\n                           \"exitCode\":\"COMPLETED\",\n                           \"exitDescription\":\"\"\n                        },\n                        \"startTime\":\"8\\/1\\/16 3:07 PM\",\n                        \"endTime\":\"8\\/1\\/16 3:07 PM\",\n                        \"lastUpdated\":\"8\\/1\\/16 3:07 PM\",\n                        \"parameters\":{\n                           \"input.file.path\":\"file:\\/\\/\\/opt\\/tomcat-geoserver-2.9.x\\/temp\\/tmpbbe2388a-f26d-4f26-a20f-88c653d88aec\",\n                           \"time\":1470064049392\n                        },\n                        \"readCount\":1,\n                        \"writeCount\":1,\n                        \"failureExceptions\":\"\"\n                     },\n                    ...\n                     {\n                        \"name\":\"restoreGeoServerSecurityManager\",\n                        \"status\":\"COMPLETED\",\n                        \"exitStatus\":{\n                           \"exitCode\":\"COMPLETED\",\n                           \"exitDescription\":\"\"\n                        },\n                        \"startTime\":\"8\\/1\\/16 3:07 PM\",\n                        \"endTime\":\"8\\/1\\/16 3:07 PM\",\n                        \"lastUpdated\":\"8\\/1\\/16 3:07 PM\",\n                        \"parameters\":{\n                           \"input.file.path\":\"file:\\/\\/\\/opt\\/tomcat-geoserver-2.9.x\\/temp\\/tmpbbe2388a-f26d-4f26-a20f-88c653d88aec\",\n                           \"time\":1470064049392\n                        },\n                        \"readCount\":0,\n                        \"writeCount\":0,\n                        \"failureExceptions\":\"\"\n                     }\n                  ]\n               },\n               \"status\":\"COMPLETED\",\n               \"startTime\":\"2016-08-01 15:07:29.398 UTC\",\n               \"createTime\":\"2016-08-01 15:07:29.393 UTC\",\n               \"endTime\":\"2016-08-01 15:07:30.356 UTC\",\n               \"lastUpdated\":\"2016-08-01 15:07:30.772 UTC\",\n               \"exitStatus\":{\n                  \"exitCode\":\"COMPLETED\",\n                  \"exitDescription\":\"\"\n               },\n               \"progress\":\"9\\/9\"\n            },\n            \"options\":{\n               \"@class\":\"synchList\"\n            },\n            \"warningsList\":{\n               \"@class\":\"synchList\"\n            },\n            \"archiveFile\":{\n               \"@class\":\"resource\",\n               \"$\":\"\\/home\\/sg\\/BackupAndRestore\\/test_rest_1.zip\"\n            }\n         }\n      }\n      ...\n

      Here you are able to see the status of all the steps involved in the restore procedure with creation time, start time, end time, exit status etc.

      Cancel a Restore

      Cancel an in-progress Restore by sending an HTTP DELETE request:

      curl -v -XDELETE -u \"admin:geoserver\" http://mygeoserver/geoserver/rest/br/restore/$ID\n

      Replace $ID with the ID of the restore operation you'd like to cancel.

      "},{"location":"community/backuprestore/usecases/","title":"Use Cases","text":""},{"location":"community/backuprestore/usecases/#database-vs-shapefile-based-indexer","title":"Database vs. Shapefile based indexer","text":"

      When using a DataBase as backend storage for the mosaic index, a datastore.properties file is present on the mosaic folder containing the connection parameters.

      In case the user wants to parametrize this, he must create a .template datastore properties file containing all the properties of the original one but using placemarks as parametric values.

      As an instance:

      host=${mosaic1.jdbc.host}\nport=${mosaic1.jdbc.port}\n...\n

      The backup and restore extension will save on the archive both the original .properties and the .template

      When restoring, the extension will overwrite the .properties by using the .template and substituting the placemarks with the correct environment property values.

      When using a shapefile as backend for the index the shapefile itself will be created once again by the mosaic when performing the first harvest operation.

      "},{"location":"community/backuprestore/usecases/#database-connection-parameters-vs-jndi","title":"Database Connection Parameters vs. JNDI","text":"

      This use case is similar to the previous one, except for the fact that instead of parameters like host and port we will have a parametric JNDI name.

      "},{"location":"community/backuprestore/usecases/#indexer-files-and-regex","title":"Indexer files and regex","text":"

      The approach will be exactly the same of the datastore.properties.

      It's worth notice that the backup extension will overwrite only the files having a corresponding .template prototype.

      "},{"location":"community/backuprestore/usecases/#granules-stored-on-the-same-mosaic-folder-vs-absolute-path","title":"Granules stored on the same mosaic folder vs. absolute path","text":"

      This won't impact the backup and restore at all, since it will never dumps data into the final archive.

      It is important, however, that the absolute paths are parametric similar to the connection parameters explained above.

      "},{"location":"community/backuprestore/usecases/#dealing-with-non-existing-indexes-on-the-target-restored-environment","title":"Dealing with non-existing indexes on the target restored environment","text":"

      It is possible that when restoring the ImageMosaic the index does not exist on the target environment.

      The backup and restore extension should perform a double check once restored the datastore.properties file trying to access the index store.

      1. In case of failure, i.e. the extension cannot connect to the datastore, the resource will fail.
      2. In case the datastore is accessible but the index does not exist, the plugin will create an empty mosaic on the catalog instead of failing.
      "},{"location":"community/cog/","title":"COG (Cloud Optimized GeoTIFF) Documentation","text":"

      This section describes the COG plugin usage and it also contains an example on how to configure an ImageMosaic on top of remote COG datasets and harvest them.

      • COG (Cloud Optimized GeoTIFF) Support
      • ImageMosaic example with Modis COG datasets
      • COG ImageMosaic from local storage to S3
      "},{"location":"community/cog/cog/","title":"COG (Cloud Optimized GeoTIFF) Support","text":"

      COG (Cloud Optimized GeoTIFF) is a regular GeoTIFF file, aimed at being hosted on a HTTP file server, whose internal organization is friendly for consumption by clients issuing HTTP GET range requests. The COG module allows to set configuration params to connect to a Cloud GeoTIFF, as well as adding JARs to the classpath needed to support that connection.

      "},{"location":"community/cog/cog/#installation","title":"Installation","text":"

      As a community module, the package needs to be downloaded from the nightly builds, picking the community folder of the corresponding GeoServer series (e.g. if working on the GeoServer main development branch nightly builds, pick the zip file form main/community-latest).

      To install the module, unpack the zip file contents into the GeoServer WEB-INF/lib directory and restart GeoServer.

      "},{"location":"community/cog/cog/#cog-geotiff-configuration-panel","title":"COG GeoTIFF Configuration Panel","text":"

      The COG plugin does not add new stores, instead, it adds COG support to existing ones.

      When configuring a GeoTIFF store, a new checkbox is available: Cloud Optimized GeoTIFF (COG). Setting that will open a new section presenting the COG configuration parameters for this COG Store.

      COG Connection params

      Checking the Cloud Optimized GeoTIFF (COG) checkbox will provide new options:

      Option Description

      URL (prefixed by cog://) representing the connection URL to the COG Dataset.

      Range Reader Settings Which type of Range Reader implementation. Values currently supported are HTTP, GoogleCloud, Azure, S3 the latter using an S3 Client

      User Name / Access Key ID / Account Name Optional user name (HTTP) or Access Key ID (S3) or Account Name (Azure) in case the COG dataset requires authentication

      Password / Secret Access Key / Account Key Password (HTTP) or Secret Access Key (S3) or Account Key (Azure) for the previous credential

      "},{"location":"community/cog/cog/#cog-imagemosaic-configuration","title":"COG ImageMosaic Configuration","text":"

      Additional configuration parameters can be specified in the ImageMosaic indexer configuration, in order to properly configure a COG based ImageMosaic.

      "},{"location":"community/cog/cog/#indexerproperties","title":"indexer.properties","text":"

      Parameter Mandatory? Description

      Cog Y A boolean flag (true/false) to be set (Cog=true) in order to signal that the ImageMosaic is a COG data mosaic.

      CogRangeReader N Specifies the desired RangeReader implementation performing the Range Reads requests.

      CogUser N Credential to be set whenever basic HTTP authentication is needed to access the COG Datasets or an S3 Access KeyID is required or an Azure AccountName is required

      CogPassword N Password for the above user OR Secret Access Key for the above S3 KeyId or AccountKey for the above Azure AccountName.

      "},{"location":"community/cog/cog/#cog_plugin_rangereader","title":"COG RangeReader","text":"

      The following table provides the values for the CogRangeReader based on the type of target storage:

      Storage type Class name

      HTTP Can be omitted, or set to it.geosolutions.imageioimpl.plugins.cog.HttpRangeReader

      AWS S3 it.geosolutions.imageioimpl.plugins.cog.S3RangeReader

      Google Cloud it.geosolutions.imageioimpl.plugins.cog.GSRangeReader

      Azure it.geosolutions.imageioimpl.plugins.cog.AzureRangeReader

      "},{"location":"community/cog/cog/#cog-global-settings","title":"COG Global Settings","text":"

      The GeoServer Global Settings page contains the default COG settings presented when setting up a new COG GeoTIFF Store.

      Default Global COG Settings

      "},{"location":"community/cog/cog/#image-locations","title":"Image locations","text":"

      For images served by a HTTP server, a HTTP URL must be used. For images served by S3 or Google Cloud, it's possible to use both the public HTTP URL, or the idiomatic URIS, for example:

      • s3://landsat-pds/c1/L8/153/075/LC08_L1TP_153075_20190515_20190515_01_RT/LC08_L1TP_153075_20190515_20190515_01_RT_B2.TIF
      • gs://gcp-public-data-landsat/LC08/01/044/034/LC08_L1GT_044034_20130330_20170310_01_T2/LC08_L1GT_044034_20130330_20170310_01_T2_B11.TIF
      "},{"location":"community/cog/cog/#http-client-okhttp-configuration","title":"HTTP Client (OkHttp) configuration","text":"

      HTTP client configuration (based on OkHttp client) can be specified through Environment variables.

      Environment Variable Description

      IIO_HTTP_MAX_REQUESTS The maximum number of requests to execute concurrently. Above this requests queue in memory, waiting for the running calls to complete. (Default 128)

      IIO_HTTP_MAX_REQUESTS_PER_HOST The maximum number of requests for each host to execute concurrently. (Default 5)

      IIO_HTTP_MAX_IDLE_CONNECTIONS The maximum number of idle connections. (Default 5)

      IIO_HTTP_KEEP_ALIVE_TIME The Keep alive time (in seconds), representing maximum time that excess idle threads will wait for new tasks before terminating. (Default 60)

      "},{"location":"community/cog/cog/#aws-s3-client-configuration","title":"AWS S3 Client configuration","text":"

      A single S3 Asynchronous Client will be used for the same region and alias (url schema, i.e. http, https). The following Environment Variables can be set to customize the pool for the asynchronous client for that particular alias. On the table below, replace the \"\\$ALIAS\\$\" template with HTTP or HTTPS or S3 if you are configuring properties for these schema.

      Environment Variable Description

      IIO_\\$ALIAS\\$_AWS_CORE_POOL_SIZE The core pool size for the S3 Client (Default 50)

      IIO_\\$ALIAS\\$_AWS_MAX_POOL_SIZE The maximum number of thread to allow in the pool for the S3 Client (Default 128)

      IIO_\\$ALIAS\\$_AWS_KEEP_ALIVE_TIME The Keep alive time (in seconds), representing maximum time that excess idle threads will wait for new tasks before terminating. (Default 10)

      IIO_\\$ALIAS\\$_AWS_USER Default user (access key ID) for AWS basic authentication credentials

      IIO_\\$ALIAS\\$_AWS_PASSWORD Default password (secret access key) for AWS basic authentication credentials

      IIO_\\$ALIAS\\$_AWS_REGION Default AWS region

      IIO_\\$ALIAS\\$_AWS_ENDPOINT Endpoint to Amazon service or any other S3-compatible service run by a third-party

      "},{"location":"community/cog/cog/#google-cloud-storage-configuration","title":"Google Cloud storage configuration","text":"

      The credentials to access Google Cloud cannot be provided as username and password (an authentication method that Google Cloud does not support), but need to be provided via a system variable pointing to the key file:

      set GOOGLE_APPLICATION_CREDENTIALS=/path/to/the/key-file.json\nexport GOOGLE_APPLICATION_CREDENTIALS\n
      "},{"location":"community/cog/cog/#azure-configuration","title":"Azure configuration","text":"

      A single Azure Client will be used for the same container. Account and container will be retrieved from the provided Azure URL. The following System Properties can be set to customize client properties where missing.

      System property Description

      azure.reader.accountName The Azure Account Name

      azure.reader.accountKey The Azure Account Key for the above Account

      azure.reader.container The default container for the above Account

      azure.reader.prefix The optional prefix containing blobs

      azure.reader.maxConnections The max number of connections supported by the underlying Azure client

      "},{"location":"community/cog/cog/#client-configuration-system-properties","title":"Client configuration (System Properties)","text":"

      Note that all the IIO settings reported in the previous tables can also be specified using System Properties instead of Environment variables. You just need to replace UPPER CASE words with lower case words and underscores with dots. So, the value for Maximum HTTP requests can be specified by setting either a IIO_HTTP_MAX_REQUESTS Environment variable or a iio.http.max.requests Java System Property alternatively (Environment variables are checked first).

      By default, when accessing a COG, an initial chunk of 16 KB is read in attempt to parse the header so that the reader will have the offset and length of the available tiles. When dealing with files hosting many tiles, it is possible that the whole header won't fit in the initial chunk. In this case additional reads (chunks of the same size) will be progressively made to complete loading the header. A it.geosolutions.cog.default.header.length system property can be configured to set the length (in bytes) of the reading chunk. Tuning this so that the header is read with few extra requests can help improve performance. A value too large can cause memory consumption issues and will reduce efficiency, as un-necessary data will be read.

      "},{"location":"community/cog/mosaic/","title":"ImageMosaic example with Modis COG datasets","text":""},{"location":"community/cog/mosaic/#introduction","title":"Introduction","text":"

      This tutorial provide some hints on configuring an ImageMosaic on top of some MODIS Vegetation Index datasets available at NASA EarthData

      "},{"location":"community/cog/mosaic/#imagemosaic-configuration-files","title":"ImageMosaic Configuration files","text":"

      We need a couple of configuration files to have an ImageMosaic properly set. Configuration is based on these key points:

      • The ImageMosaic will be initially created empty without any data. Data will be harvested as a second step.
      • A Time dimension will be used, based on the date contained in the file's name.

      More details on ImageMosaic configuration are available on the dedicated documentation section: ImageMosaic configuration

      Based on the above key points, we can setup the following configuration files:

      "},{"location":"community/cog/mosaic/#indexerproperties","title":"indexer.properties:","text":"

      This contains the main configuration to index the datasets composing the ImageMosaic.

      Cog=true\nPropertyCollectors=TimestampFileNameExtractorSPI[timeregex](time)\nTimeAttribute=time\nSchema=*the_geom:Polygon,location:String,time:java.util.Date\nCanBeEmpty=true\nName=modisvi\n

      Relevant parts:

      • Cog flag specifying that the ImageMosaic is a Mosaic of COG Datasets
      • PropertyCollectors, TimeAttribute and Schema are used to define the ImageMosaic index columns and how to populate them
      • CanBeEmpty allows to define an empty ImageMosaic. It will be populated afterwards
      • Name is the name for this mosaic
      "},{"location":"community/cog/mosaic/#timeregexproperties","title":"timeregex.properties:","text":"

      The previous indexer refers to a time dimension and the related time column in the index's schema that will get populated by extracting the time value from the filename (the 8 digits, representing YEAR, MONTH, DAY) using the regex specified in the timeregex.properties file. An example of sample file for this collection as stored on the S3 bucket is 2018.01.01.tif so the time regex will reflect that. Note the 3 groups of digits and the 'format' of the date.

      . literalinclude:: src/modisvi/timeregex.properties

      "},{"location":"community/cog/mosaic/#datastoreproperties","title":"datastore.properties:","text":"

      Due to the amount of available datasets, storing the ImageMosaic index on a DBMS is recommended, i.e. a PostGIS DB. See **`datastore.properties** <../../data/raster/imagemosaic/configuration.rst#mosaic_datastore_properties>`_ section of the ImageMosaic documentation for more info. Make sure that a DB with the name reported in the datastore is available

      user=postgres\nport=5432\npasswd=postgres\nurl=jdbc\\:postgresql\\:modisvi\nhost=localhost\ndatabase=modisvi\ndriver=org.postgresql.Driver\nschema=public\nSPI=org.geotools.data.postgis.PostgisNGDataStoreFactory\nfetch\\ size=1000\nmax\\ connections=20\nmin\\ connections=5\nvalidate\\ connections=true\nLoose\\ bbox=true\nExpose\\ primary\\ key=false\nMax\\ open\\ prepared\\ statements=50\npreparedStatements=false\nEstimated\\ extends=false\nConnection\\ timeout=20\n

      Once the 3 files have been setup, create a zip archive with them and let's name it modisvi.zip. (Note that the files need to be in the root of the zip files, not into a subdirectory)

      You are now ready to use REST calls to start the ImageMosaic creation.

      "},{"location":"community/cog/mosaic/#imagemosaic-rest-operations","title":"ImageMosaic REST operations","text":"

      On the next steps we assume:

      • An existing GeoServer instance is running on port 8080 of localhost.
      • A workspace named \"test\" exists on that GeoServer.
      • REST credentials are user=admin password=geoserver.
      • A default aws region is defined on JAVA System Property, using the flag -Diio.https.aws.region=us-west-2.

      Make sure to update the incoming URLs accordingly, based on your actual installation.

      Create an empty ImageMosaic without configuring it

      curl request

      curl -u admin:geoserver -XPUT --write-out %{http_code} -H \"Content-type:application/zip\" --data-binary @modisvi.zip http://localhost:8080/geoserver/rest/workspaces/test/coveragestores/modisvi/file.imagemosaic?configure=none

      Response

      201 OK\n

      Providing sample prototyping granules

      Next step is providing a prototype dataset for the coverage to be supported.

      curl request

      curl -u admin:geoserver -XPOST -H \"Content-type: text/plain\" --write-out %{http_code} -d \"https://modis-vi-nasa.s3-us-west-2.amazonaws.com/MOD13A1.006/2018.01.01.tif\" \"http://localhost:8080/geoserver/rest/workspaces/test/coveragestores/modisvi/remote.imagemosaic\"

      Response

      202 Accepted\n

      Initializing the store (Listing available coverages)

      Once a prototype has been provided we need to initialize the store by querying it for the available coverages.

      curl request

      curl -v -u admin:geoserver -XGET http://localhost:8080/geoserver/rest/workspaces/test/coveragestores/modisvi/coverages.xml?list=all

      Response

      <List>\n  <coverageName>modisvi</coverageName>\n</list>\n

      Configuring the coverage

      Once we get the list of available coverages, we need to configure a coverage by sending the config through REST.

      curl request

      curl -v -u admin:geoserver -XPOST -H \"Content-type: text/xml\" -d @\"coverage.xml\" \"http://localhost:8080/geoserver/rest/workspaces/test/coveragestores/modisvi/coverages\"

      where coverage.xml has this content:

      <coverage>\n  <name>modisvi</name>\n  <nativeName>modisvi</nativeName>\n  <enabled>true</enabled>\n  <metadata>\n    <entry key=\"time\">\n      <dimensionInfo>\n        <enabled>true</enabled>\n        <presentation>LIST</presentation>\n        <units>ISO8601</units>\n        <defaultValue>\n          <strategy>MAXIMUM</strategy>\n        </defaultValue>\n      </dimensionInfo>\n    </entry>\n  </metadata>\n</coverage>\n

      Adding more granules

      Now that we have a coverageStore ready and a coverage layer configured we can start adding more granules.

      curl request

      curl -u admin:geoserver -XPOST -H \"Content-type: text/plain\" --write-out %{http_code} -d \"https://modis-vi-nasa.s3-us-west-2.amazonaws.com/MOD13A1.006/2018.01.17.tif\" \"http://localhost:8080/geoserver/rest/workspaces/test/coveragestores/modisvi/remote.imagemosaic\"

      Setting Style

      That MODIS data has 2 bands representing (Normalized Difference Vegetation Index) (NDVI) and Enhanced Vegetation Index (EVI). Let's add this ndvi.sld style to apply a proper colormap to the NDVI band (copy this content to a file named ndvi.sld to be used by the next REST call):

      <StyledLayerDescriptor xmlns=\"http://www.opengis.net/sld\" xmlns:sld=\"http://www.opengis.net/sld\" xmlns:gml=\"http://www.opengis.net/gml\" xmlns:ogc=\"http://www.opengis.net/ogc\" version=\"1.0.0\">\n  <NamedLayer>\n    <Name>Default Styler</Name>\n    <UserStyle>\n      <Name>ndvi</Name>\n      <Title>ndvi</Title>\n      <FeatureTypeStyle>\n        <Name>name</Name>\n        <Rule>\n          <RasterSymbolizer>\n            <ChannelSelection>\n              <GrayChannel>\n                <SourceChannelName>1</SourceChannelName>\n              </GrayChannel>\n            </ChannelSelection>\n            <ColorMap>\n              <ColorMapEntry color=\"#000000\" quantity=\"-1\"/>\n              <ColorMapEntry color=\"#0000ff\" quantity=\"-0.75\"/>\n              <ColorMapEntry color=\"#ff00ff\" quantity=\"-0.25\"/>\n              <ColorMapEntry color=\"#ff0000\" quantity=\"0\"/>\n              <ColorMapEntry color=\"#ffff00\" quantity=\"0.5\"/>\n              <ColorMapEntry color=\"#00ff00\" quantity=\"1\"/>\n            </ColorMap>\n            <ContrastEnhancement/>\n          </RasterSymbolizer>\n        </Rule>\n      </FeatureTypeStyle>\n    </UserStyle>\n  </NamedLayer>\n</StyledLayerDescriptor>\n

      curl request to create the style

      curl -v -u admin:geoserver -XPOST -H \"Content-type: application/vnd.ogc.sld+xml\" -d @ndvi.sld http://localhost:8080/geoserver/rest/styles

      curl request to set the style as default style of the layer

      :

      curl -v -u admin:geoserver -XPUT -H \"Content-type: text/xml\" -d \"<layer><defaultStyle><name>ndvi</name></defaultStyle></layer>\" http://localhost:8080/geoserver/rest/layers/modisvi.xml\n
      "},{"location":"community/cog/mosaic/#final-preview","title":"Final preview","text":"

      This is how a layer preview will looks like:

      NDVI COG dataset

      "},{"location":"community/cog/update/","title":"COG ImageMosaic from local storage to S3","text":""},{"location":"community/cog/update/#introduction","title":"Introduction","text":"

      This tutorial provides instructions to update an existing ImageMosaic built on top of local granules to a COG ImageMosaic with granules stored on S3 bucket. It is aimed to users that want to move COG granules of an ImageMosaic to a remote bucket without the need of re-harvesting the whole collection of granules.

      "},{"location":"community/cog/update/#assumptions","title":"Assumptions","text":"
      • An ImageMosaic store already exists, with its index based on a DB (i.e. PostGIS).
      • Local GeoTIFF granules are already valid COGs.
      • User has experience with uploading data on S3.
      "},{"location":"community/cog/update/#verifying-data-is-valid-cog","title":"Verifying data is valid COG","text":"

      Verifying that a sample GeoTIFF is a valid COG can be achieved using COG validator service.

      1. Store a sample GeoTIFF to the target bucket (or to the server location) you will use for remote serving and copy its full URL location, i.e. https://modis-vi-nasa.s3-us-west-2.amazonaws.com/MOD13A1.006/2018.01.01.tif.
      2. Go to COG Validator
      3. Paste the sample COG URL in the text box and hit the submit button.
      4. In case the sample file is a valid COG, you will get a message like this:

      Cloud Optimized GeoTIFF Validator: result Validation succeeded ! https://sample.s3.eu-central-1.amazonaws.com/test/cog.tif is a valid Cloud Optimized GeoTIFF.

      In case the file isn't a valid COG, you can use GDAL 3.1 or above to convert your file to COG format. See the related GDAL documentation for further details.

      Once the data has been verified, all of your granules need to be stored to an S3 bucket.

      "},{"location":"community/cog/update/#imagemosaic-update","title":"ImageMosaic update","text":"

      Next step is updating both the ImageMosaic's config as well as the index.

      "},{"location":"community/cog/update/#imagemosaic-configuration-update","title":"ImageMosaic configuration update","text":"

      A few new properties need to be added to the ImageMosaic configuration to support COG.

      Locate the .properties file containing the mosaic configuration. It's usually a .properties file having the same name of the parent folder. You may recognize it since it's usually being autogenerated during first ImageMosaic configuration and it contains this header:

      #-Automagically created from GeoTools-.

      Let's assume it's named mosaic.properties for simplicity for future references in this documentation. Once located, edit that file by adding these new properties:

      • Cog=true
      • SuggestedSPI=it.geosolutions.imageioimpl.plugins.cog.CogImageReaderSpi

      When storing your granules on a public bucket, you may stick with the default RangeReader implementation so no other flags are needed and you can skip to the ImageMosaic index update paragraph.

      In case you are using a private bucket instead, you need to specify additional properties to the mosaic.properties file:

      • CogRangeReader=it.geosolutions.imageioimpl.plugins.cog.S3RangeReader
      • CogUser=S3AccessKeyID
      • CogPassword=S3SecretAccessKey

      Where the S3AccessKeyID and S3SecretAccessKey are the actual values needed to access that bucket.

      "},{"location":"community/cog/update/#imagemosaic-index-update","title":"ImageMosaic index update","text":"

      The next step is updating the ImageMosaic index which is a catalog of all the granules composing the mosaic. We need to update the location values to refer to remote URLs instead of local paths on disk. The location attribute initially contains the path of each granule on disk, which can be either a relative or an absolute path. Relative paths are relative to the ImageMosaic parent configuration folder whilst absolute paths are full paths.

      The mosaic.properties file contains a PathType property set to RELATIVE or ABSOLUTE. On old mosaics, that property might be missing and AbsolutePath property exists instead with a boolean value true/false. Based on that, note that all the paths of the same mosaic will be either relative or absolute.

      To give you an example, an ImageMosaic stored at /var/data/imageMosaic/mosaic with a granule at /var/data/imageMosaic/mosaic/2018.01.01.tif may have a record in the database with location attribute equal to :

      • 2018.01.01.tif in case of relative path
      • /var/data/imageMosaic/mosaic/2018.01.01.tif in case of absolute path.

      The type of path affects the query to be executed to update the index.

      Note

      Make sure to backup your table for a quick recovery in case of messes with the updating query.

      For this example, we are going to use the same public datasets from S3 Urls being used in the previous ImageMosaic example with Modis COG datasets section.

      For location with relative paths a simple replacing query could be like this:

      UPDATE schema.table SET location=CONCAT(\n'https://modis-vi-nasa.s3-us-west-2.amazonaws.com/MOD13A1.006/', location);\n

      So we are basically prepending the S3 bucket URL to the location value. By this way, based on the above examples, location=2018.01.01.tif will become location='https://modis-vi-nasa.s3-us-west-2.amazonaws.com/MOD13A1.006/2018.01.01.tif

      For location with absolute path, a replacing query may be like this (for our example):

      UPDATE schema.table SET location=REPLACE(location,'/var/data/imageMosaic/mosaic/',\n'https://modis-vi-nasa.s3-us-west-2.amazonaws.com/MOD13A1.006/');\n
      "},{"location":"community/cog/update/#geoserver-reload","title":"GeoServer reload","text":"

      Once everything is done, reload the GeoServer configuration.

      "},{"location":"community/colormap/","title":"Dynamic colormap generation","text":"

      ras:DynamicColorMap is a Raster-to-Raster rendering transformation which applies a dynamic color map to a Raster on top of its statistics and a set of colors.

      "},{"location":"community/colormap/#installing-the-dynamic-colormap-community-extension","title":"Installing the dynamic colormap community extension","text":"
      1. Download the extension from the nightly GeoServer community module builds.

        ::: warning ::: title Warning :::

        Make sure to match the version of the extension to the version of the GeoServer instance! :::

      2. Extract the contents of the archive into the WEB-INF/lib directory of the GeoServer installation.

      "},{"location":"community/colormap/#usage","title":"Usage","text":"

      The following SLD invokes a Dynamic Color Map rendering transformation on a Coverage using colorMaps created on top of QuantumGIS SVG files. Dynamic Color Map Rendering Transformation takes data as first parameter (the coverage) and ColorRamp as second parameter which is a colorMap.

      <?xml version=\"1.0\" encoding=\"ISO-8859-1\"?>\n<StyledLayerDescriptor version=\"1.0.0\"\n    xsi:schemaLocation=\"http://www.opengis.net/sld StyledLayerDescriptor.xsd\"\n    xmlns=\"http://www.opengis.net/sld\"\n    xmlns:ogc=\"http://www.opengis.net/ogc\"\n    xmlns:xlink=\"http://www.w3.org/1999/xlink\"\n    xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\">\n  <NamedLayer>\n    <Name>DynamicColorMap</Name>\n    <UserStyle>\n      <Title>DynamicColorMap</Title>\n      <Abstract>A DynamicColorMap</Abstract>\n      <FeatureTypeStyle>\n        <Transformation>\n          <ogc:Function name=\"ras:DynamicColorMap\">\n            <ogc:Function name=\"parameter\">\n              <ogc:Literal>data</ogc:Literal>\n            </ogc:Function>\n            <ogc:Function name=\"parameter\">\n              <ogc:Literal>colorRamp</ogc:Literal>\n              <ogc:Function name=\"colormap\">\n                <ogc:Literal>gmt\\GMT_panoply</ogc:Literal>\n                <ogc:Function name=\"gridCoverageStats\"><ogc:Literal>minimum</ogc:Literal></ogc:Function>\n                <ogc:Function name=\"gridCoverageStats\"><ogc:Literal>maximum</ogc:Literal></ogc:Function>\n              </ogc:Function>\n            </ogc:Function>\n          </ogc:Function>\n        </Transformation>\n        <Rule>\n         <Name>rule1</Name>\n         <RasterSymbolizer>\n           <Opacity>1.0</Opacity>\n         </RasterSymbolizer>\n        </Rule>\n      </FeatureTypeStyle>\n    </UserStyle>\n  </NamedLayer>\n </StyledLayerDescriptor>\n

      Key aspects of the SLD are:

      • Lines 14-15 define the rendering transformation, using the process ras:DynamicColorMap.

      • Lines 16-18 supply the input data parameter, named data in this process.

      • Lines 19-21 supply a value for the process's colorRamp parameter which specifies a colorMap.

      • Lines 22-23 supply the value for the colorMap parameter. In this case it's a reference to a SVG containing a LinearGradient definition.

        A sample of QuantumGIS SVG LinearGradient subelement is:

        <linearGradient id=\"GMT_panoply\" gradientUnits=\"objectBoundingBox\" spreadMethod=\"pad\" x1=\"0%\" x2=\"100%\" y1=\"0%\" y2=\"0%\">\n    <stop offset=\"0.00%\" stop-color=\"rgb(4,14,216)\" stop-opacity=\"1.0000\"/>\n    <stop offset=\"6.25%\" stop-color=\"rgb(4,14,216)\" stop-opacity=\"1.0000\"/>\n    <stop offset=\"6.25%\" stop-color=\"rgb(32,80,255)\" stop-opacity=\"1.0000\"/>\n    <stop offset=\"12.50%\" stop-color=\"rgb(32,80,255)\" stop-opacity=\"1.0000\"/>\n    <stop offset=\"12.50%\" stop-color=\"rgb(65,150,255)\" stop-opacity=\"1.0000\"/>\n    <stop offset=\"18.75%\" stop-color=\"rgb(65,150,255)\" stop-opacity=\"1.0000\"/>\n    <stop offset=\"18.75%\" stop-color=\"rgb(109,193,255)\" stop-opacity=\"1.0000\"/>\n    <stop offset=\"25.00%\" stop-color=\"rgb(109,193,255)\" stop-opacity=\"1.0000\"/>\n    <stop offset=\"25.00%\" stop-color=\"rgb(134,217,255)\" stop-opacity=\"1.0000\"/>\n    <stop offset=\"31.25%\" stop-color=\"rgb(134,217,255)\" stop-opacity=\"1.0000\"/>\n    <stop offset=\"31.25%\" stop-color=\"rgb(156,238,255)\" stop-opacity=\"1.0000\"/>\n    <stop offset=\"37.50%\" stop-color=\"rgb(156,238,255)\" stop-opacity=\"1.0000\"/>\n    <stop offset=\"37.50%\" stop-color=\"rgb(175,245,255)\" stop-opacity=\"1.0000\"/>\n    <stop offset=\"43.75%\" stop-color=\"rgb(175,245,255)\" stop-opacity=\"1.0000\"/>\n    <stop offset=\"43.75%\" stop-color=\"rgb(206,255,255)\" stop-opacity=\"1.0000\"/>\n    <stop offset=\"50.00%\" stop-color=\"rgb(206,255,255)\" stop-opacity=\"1.0000\"/>\n    <stop offset=\"50.00%\" stop-color=\"rgb(255,254,71)\" stop-opacity=\"1.0000\"/>\n    <stop offset=\"56.25%\" stop-color=\"rgb(255,254,71)\" stop-opacity=\"1.0000\"/>\n    <stop offset=\"56.25%\" stop-color=\"rgb(255,235,0)\" stop-opacity=\"1.0000\"/>\n    <stop offset=\"62.50%\" stop-color=\"rgb(255,235,0)\" stop-opacity=\"1.0000\"/>\n    <stop offset=\"62.50%\" stop-color=\"rgb(255,196,0)\" stop-opacity=\"1.0000\"/>\n    <stop offset=\"68.75%\" stop-color=\"rgb(255,196,0)\" stop-opacity=\"1.0000\"/>\n    <stop offset=\"68.75%\" stop-color=\"rgb(255,144,0)\" stop-opacity=\"1.0000\"/>\n    <stop offset=\"75.00%\" stop-color=\"rgb(255,144,0)\" stop-opacity=\"1.0000\"/>\n    <stop offset=\"75.00%\" stop-color=\"rgb(255,72,0)\" stop-opacity=\"1.0000\"/>\n    <stop offset=\"81.25%\" stop-color=\"rgb(255,72,0)\" stop-opacity=\"1.0000\"/>\n    <stop offset=\"81.25%\" stop-color=\"rgb(255,0,0)\" stop-opacity=\"1.0000\"/>\n    <stop offset=\"87.50%\" stop-color=\"rgb(255,0,0)\" stop-opacity=\"1.0000\"/>\n    <stop offset=\"87.50%\" stop-color=\"rgb(213,0,0)\" stop-opacity=\"1.0000\"/>\n    <stop offset=\"93.75%\" stop-color=\"rgb(213,0,0)\" stop-opacity=\"1.0000\"/>\n    <stop offset=\"93.75%\" stop-color=\"rgb(158,0,0)\" stop-opacity=\"1.0000\"/>\n    <stop offset=\"100.00%\" stop-color=\"rgb(158,0,0)\" stop-opacity=\"1.0000\"/>\n</linearGradient>\n

        Which should be rendered like this:

      • Lines 24 supplies the minimum parameter which is determined through a FilterFunction which takes the minimum value from the GridCoverage statistics,

      • Lines 25 supplies the maximum parameter which is determined through a FilterFunction which takes the maximum value from the GridCoverage statistics,

        The resulting image may look like this (you may note the STEPs across colors due to color intervals):

        Using an GMT_drywet SVG, the resulting image may look like this, which uses a smoother color ramp:

      Alternatively, a ColorMap may be specified this way:

      ..........\n           <ogc:Function name=\"ras:DynamicColorMap\">\n             <ogc:Function name=\"parameter\">\n               <ogc:Literal>data</ogc:Literal>\n             </ogc:Function>\n             <ogc:Function name=\"parameter\">\n               <ogc:Literal>colorRamp</ogc:Literal>\n               <ogc:Function name=\"colormap\">\n                 <ogc:Literal>#0000FF;#00FF00;#FF0000</ogc:Literal>\n                 <ogc:Function name=\"gridCoverageStats\"><ogc:Literal>minimum</ogc:Literal></ogc:Function>\n                 <ogc:Function name=\"gridCoverageStats\"><ogc:Literal>maximum</ogc:Literal></ogc:Function>\n               </ogc:Function>\n             </ogc:Function>\n           </ogc:Function>\n...........\n

      or

      ..........\n           <ogc:Function name=\"ras:DynamicColorMap\">\n             <ogc:Function name=\"parameter\">\n               <ogc:Literal>data</ogc:Literal>\n             </ogc:Function>\n             <ogc:Function name=\"parameter\">\n               <ogc:Literal>colorRamp</ogc:Literal>\n               <ogc:Function name=\"colormap\">\n                 <ogc:Literal>rgb(0,0,255);rgb(0,255,0);rgb(255,0,0)</ogc:Literal>\n                 <ogc:Function name=\"gridCoverageStats\"><ogc:Literal>minimum</ogc:Literal></ogc:Function>\n                 <ogc:Function name=\"gridCoverageStats\"><ogc:Literal>maximum</ogc:Literal></ogc:Function>\n               </ogc:Function>\n             </ogc:Function>\n           </ogc:Function>\n...........\n

      In these cases a RAMP will be used with the indicated colors.

      The resulting image may look like this:

      "},{"location":"community/colormap/#dynamiccolormap-requirements","title":"DynamicColorMap Requirements","text":"
      • A preliminar gdalinfo -stats command needs to be run against the coverages in order to create the PAM Auxiliary file containing statistics and metadata.
      • In order to setup colorMap from QuantumGIS, you should have copied the QuantumGIS SVG resources folder from apps/qgis/resources/cpt-city-XXXXX within the GEOSERVER_DATA_DIR as a styles/ramps subfolder.
      • The underlying reader should support statistics retrieval by adding a PAMDataset object as a property of the returned coverage. For this reason the user should take care of setting the CheckAuxiliaryMetadata flag to true inside the indexer.properties or update the .properties file generated by GeoServer with that flag in case of already configured stores (You also need to reload the configuration in that case).
      "},{"location":"community/cov-json/","title":"CoverageJSON output format","text":"

      CoverageJSON is a format for encoding geotemporal coverage data like grids and time series. For example, it can be as output format for a WCS2.0 getCoverage requesting a TimeSeries on a specific coordinate. As per the specification, the format to be specified to get back a cov-json output is application/prs.coverage+json.

      "},{"location":"community/cov-json/#installation","title":"Installation","text":"

      As a community module, the cov-json package needs to be downloaded from the nightly builds, picking the community folder of the corresponding GeoServer series (e.g. if working on the GeoServer main development branch nightly builds, pick the zip file form main/community-latest).

      To install the module, unpack the zip file contents into GeoServer own WEB-INF/lib directory and restart GeoServer.

      "},{"location":"community/cov-json/#example-wcs-20-timeseries","title":"Example: WCS 2.0 - TimeSeries","text":"

      Let test:timeseries be a sample layer related to a coverage with time dimensions enabled. Suppose we want to get the coverage values for a specific time period on a specific lat/lon coordinate. That will be a slicing on lat/lon coordinate and trimming on time dimension.

      A getCoverage request can be posted with a similar content to http://server:port/geoserver/wcs:

      <wcs:GetCoverage service=\"WCS\" version=\"2.0.1\"\nxmlns:wcs=\"http://www.opengis.net/wcs/2.0\"\nxmlns:gml=\"http://www.opengis.net/gml/3.2\" \nxmlns:crs=\"http://www.opengis.net/spec/WCS_service-extension_crs/1.0\"\nxmlns:rsub=\"http://www.opengis.net/spec/wcs_service-extension_range-subsetting/1.0\"\nxmlns:scal=\"http://www.opengis.net/spec/WCS_service-extension_scaling/1.0/\"\nxmlns:wcsgeotiff=\"http://www.opengis.net/wcs/geotiff/1.0\"\nxmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\"\nxsi:schemaLocation=\"http://www.opengis.net/wcs/2.0 http://schemas.opengis.net/wcs/2.0/wcsAll.xsd\">\n\n  <wcs:CoverageId>test__timeseries</wcs:CoverageId>\n  <wcs:format>application/prs.coverage+json</wcs:format>\n  <wcs:DimensionSlice>\n    <wcs:Dimension>Long</wcs:Dimension>\n    <wcs:SlicePoint>56</wcs:SlicePoint>\n  </wcs:DimensionSlice>\n  <wcs:DimensionSlice>\n    <wcs:Dimension>Lat</wcs:Dimension>\n    <wcs:SlicePoint>0</wcs:SlicePoint>\n  </wcs:DimensionSlice>\n  <wcs:DimensionTrim>\n    <wcs:Dimension>Time</wcs:Dimension>\n    <wcs:TrimLow>2014-01-01T00:00:00.000Z</wcs:TrimLow>\n    <wcs:TrimHigh>2017-01-01T00:00:00.000Z</wcs:TrimHigh>\n  </wcs:DimensionTrim>\n</wcs:GetCoverage>\n

      The outcome will be something like this:

      {\n  \"type\": \"Coverage\",\n  \"domain\": {\n  \"type\": \"Domain\",\n  \"domainType\": \"PointSeries\",\n  \"axes\": {\n    \"x\": {\n    \"values\": [\n      56.0\n    ]\n    },\n    \"y\": {\n    \"values\": [\n      1.0112359550561785\n    ]\n    },\n    \"t\": {\n    \"values\": [\n      \"2014-01-01T00:00:00Z\",\n      \"2015-01-01T00:00:00Z\",\n      \"2016-01-01T00:00:00Z\",\n      \"2017-01-01T00:00:00Z\"\n    ]\n    }\n  },\n  \"referencing\": [\n    {\n    \"coordinates\": [\n      \"x\",\n      \"y\"\n    ],\n    \"system\": {\n      \"type\": \"GeographicCRS\",\n      \"id\": \"http://www.opengis.net/def/crs/EPSG/0/4326\"\n    }\n    },\n    {\n    \"coordinates\": [\n      \"t\"\n    ],\n    \"system\": {\n      \"type\": \"TemporalRS\",\n      \"calendar\": \"Gregorian\"\n    }\n    }\n  ]\n  },\n  \"parameters\": {\n  \"TIMESERIES\": {\n    \"type\": \"Parameter\",\n    \"description\": {\n    \"en\": \"timeseries\"\n    },\n    \"observedProperty\": {\n    \"label\": {\n      \"en\": \"timeseries\"\n    }\n    }\n  }\n  },\n  \"ranges\": {\n  \"TIMESERIES\": {\n    \"type\": \"NdArray\",\n    \"dataType\": \"float\",\n    \"axisNames\": [\n    \"t\",\n    \"y\",\n    \"x\"\n    ],\n    \"shape\": [\n    4,\n    1,\n    1\n    ],\n    \"values\": [\n    25.5,\n    24.76,\n    26.06,\n    23.22\n    ]\n  }\n  }\n}\n

      Note the domainType = PointSeries where x,y axes have a single and the t axis has 4 times in the values. Also note the ranges property is reporting 4 values.

      "},{"location":"community/dds/","title":"DDS/BIL(World Wind Data Formats) Extension","text":"

      This output module allows GeoServer to output imagery and terrain in formats understood by NASA World Wind. The mime-types supported are:

      1. Direct Draw Surface (DDS) - image/dds. This format allows efficient loading of textures to the GPU and takes the task off the WorldWind client CPU in converting downloaded PNG, JPEG or TIFF tiles. The DDS compression is done using DXT3 with help from the worldwind library on server side.
      2. Binary Interleaved by Line(BIL) - image/bil. This is actually a very simple raw binary format produced using the RAW Image Writer. The supplied GridCoverage2D undergoes appropriate subsampling, reprojection and bit-depth conversion. The output can be requested as 16bit Int or 32bit Float.
      "},{"location":"community/dds/#installing-the-ddsbil-extension","title":"Installing the DDS/BIL extension","text":"
      1. Download the DDS/BIL extension from the nightly GeoServer community module builds. A prebuilt version for GeoServer 2.0.x can be found on Jira - GEOS-3586.

        Warning

        Make sure to match the version of the extension to the version of the GeoServer instance!

      2. Extract the contents of the archive into the WEB-INF/lib directory of the GeoServer installation.

      "},{"location":"community/dds/#checking-if-the-extension-is-enabled","title":"Checking if the extension is enabled","text":"

      Once the extension is installed, the provided mime-types should appear in the layer preview dropbox as shown:

      The mime-types will also be listed in the GetCapabilities document:

      <Format>image/bil</Format>\n<Format>image/dds</Format>\n
      "},{"location":"community/dds/#configuring-the-bil-format","title":"Configuring the BIL format","text":"

      For a client application to use a BIL layer, it must know the data encoding of the BIL file (e.g. 16-bit integer, 32-bit floating point, etc), the byte order of the data, and the value that indicates missing data. BIL files do not contain this metadata, so it may be necessary to configure the server to produce BIL files in the format that a client application expects.

      The BIL output format can be configured for each layer in the Publishing tab of the layer configuration. The plugin supports the following options:

      Option Description

      Default encoding The data encoding to use if the request does not specify an encoding. For example, application/bil does not specify the response encoding, while application/bil16 does specify an encoding. Default: use same encoding as layer source files.

      Byte order Byte order of the response. Default: network byte order (big endian).

      No Data value The value that indicates missing data. If this option is set, missing data values will be recoded to this value. Default: no data translation.

      For compatibility with the default behavior of NASA World Wind, use these settings:

      • Default encoding: application/bil16
      • Byte order: Little endian
      • No data: -9999
      "},{"location":"community/dds/#configuring-world-wind-to-access-imageryterrain-from-geoserver","title":"Configuring World Wind to access Imagery/Terrain from GeoServer","text":"

      Please refer to the WorldWind Forums for instructions on how to setup World Wind to work with layers published via GeoServer. For image layers(DDS) the user need to create a WMSTiledImageLayer either via XML configuration or programmatically. For terrain layers (BIL) the equivalent class is WMSBasicElevationModel.

      "},{"location":"community/elasticsearch/","title":"Elasticsearch data store","text":"

      Elasticsearch is a popular distributed search and analytics engine that enables complex search features in near real-time. Default field type mappings support string, numeric, boolean and date types and allow complex, hierarchical documents. Custom field type mappings can be defined for geospatial document fields. The geo_point type supports point geometries that can be specified through a coordinate string, geohash or coordinate array. The geo_shape type supports Point, LineString, Polygon, MultiPoint, MultiLineString, MultiPolygon and GeometryCollection GeoJSON types as well as envelope and circle types. Custom options allow configuration of the type and precision of the spatial index.

      This data store allows features from an Elasticsearch index to be published through GeoServer. Both geo_point and geo_shape type mappings are supported. OGC filters are converted to Elasticsearch queries and can be combined with native Elasticsearch queries in WMS and WFS requests.

      "},{"location":"community/elasticsearch/#configuration","title":"Configuration","text":""},{"location":"community/elasticsearch/#config_elasticsearch","title":"Configuring data store","text":"

      Once the Elasticsearch GeoServer extension is installed, Elasticsearch index will be an available vector data source format when creating a new data store.

      The Elasticsearch data store configuration panel includes connection parameters and search settings.

      Available data store configuration parameters are summarized in the following table:

      +--------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Parameter | Description | +--------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------+ | elasticsearch_host | Host (IP) for connecting to Elasticsearch. HTTP scheme and port can optionally be included to override the defaults. Multiple hosts can be provided. Examples: | | | | | | localhost | | | localhost:9200 | | | http://localhost | | | http://localhost:9200 | | | https://localhost:9200 | | | https://somehost.somedomain:9200,https://anotherhost.somedomain:9200 | +--------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------+ | elasticsearch_port | Default HTTP port for connecting to Elasticsearch. Ignored if the hostname includes the port. | +--------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------+ | user | Elasticsearch user. Must have superuser privilege on index. | +--------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------+ | passwd | Elasticsearch user password | +--------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------+ | runas_geoserver_user | Whether to submit requests on behalf of the authenticated GeoServer user | +--------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------+ | proxy_user | Elasticsearch user for document queries. If not provided then admin user credentials are used for all requests. | +--------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------+ | proxy_passwd | Elasticsearch proxy user password | +--------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------+ | index_name | Index name or alias (wildcards supported) | +--------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------+ | reject_unauthorized | Whether to validate the server certificate during the SSL handshake for https connections | +--------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------+ | default_max_features | Default used when maxFeatures is unlimited | +--------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------+ | source_filtering_enabled | Whether to enable filtering of the _source field | +--------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------+ | scroll_enabled | Enable the Elasticsearch scan and scroll API | +--------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------+ | scroll_size | Number of documents per shard when using the scroll API | +--------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------+ | scroll_time | Search context timeout when using the scroll API | +--------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------+ | array_encoding | Array encoding strategy. Allowed values are JSON (keep arrays) and CSV (keep first array element). | +--------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------+ | grid_size | Hint for Geohash grid size (numRows*numCols) | +--------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------+ | grid_threshold | Geohash grid aggregation precision will be the minimum necessary so that actual_grid_size/grid_size > grid_threshold | +--------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------+ | response_buffer_limit | Maximum number of bytes to buffer in memory when reading responses from Elasticsearch | +--------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------+

      "},{"location":"community/elasticsearch/#configuring-authentication","title":"Configuring authentication","text":"

      Basic authentication is supported through the user and passwd credential parameters. The provided user must have superuser privilege on the index to enable the mapping and alias requests performed during store initialization. Note that aliases must already be present on the Elasticsearch index. If you enter an alias which is not present, the plugin will not generate it for you. Optional proxy_user and proxy_passwd parameters can be used to specify an alternate user for document search (OGC service) requests. The proxy user can have restricted privileges on the index through document level security. If not provided the default user is used for all requests.

      The runas_geoserver_user flag can be used to enable Elasticsearch requests to be submitted on behalf of the authenticated GeoServer user. When the run-as mechanism is configured the plugin will add the es-security-runas-user header with the authenticated GeoServer username. See X-Pack run-as documentation for more information. Note the run-as mechanism is applied only to document search requests.

      For added security it is recommended to define proxy_user and proxy_passwd when using the run-as mechanism. The proxy user will be used when submitting requests on behalf of the GeoServer user and can have restricted privileges enabling access only to documents that all users can have access to. The plugin can optionally be deployed to require user credentials and proxy credentials and to force the use of runas_geoserver_user by setting the environment variable org.geoserver.elasticsearch.xpack.force-runas:

      $ export JAVA_OPTS=\"-Dorg.geoserver.elasticsearch.xpack.force-runas $JAVA_OPTS\"\n
      "},{"location":"community/elasticsearch/#configuring-httpsssl","title":"Configuring HTTPS/SSL","text":"

      System properties are supported for SSL/TLS configuration:

      javax.net.ssl.trustStore\njavax.net.ssl.trustStorePassword\njavax.net.ssl.keyStore\njavax.net.ssl.keyStorePassword\n

      See HttpClientBuilder documentation for available properties.

      For example, use javax.net.ssl.trustStore[Password] to validate server certificate:

      $ export JAVA_OPTS=\"-Djavax.net.ssl.trustStore=/path/to/truststore.jks -Djavax.net.ssl.trustStorePassword=changeme $JAVA_OPTS \"\n
      "},{"location":"community/elasticsearch/#configuring-layer","title":"Configuring layer","text":"

      The initial layer configuration panel for an Elasticsearch layer will include an additional pop-up showing a table of available fields.

      Item Description

      Use All Use all fields in the layer feature type

      Use Used to select the fields that will make up the layer feature type

      Name Name of the field

      Type Type of the field, as derived from the Elasticsearch schema. For geometry types, you have the option to provide a more specific data type.

      Order Integer order values are used to sort fields, where fields with smaller order are returned first

      Custom Name Provides the option to give the field a custom name

      Default Geometry Indicates if the geometry field is the default one. Useful if the documents contain more than one geometry field, as SLDs and spatial filters will hit the default geometry field unless otherwise specified

      Stored Indicates whether the field is stored in the index

      Analyzed Indicates whether the field is analyzed

      SRID Native spatial reference ID of the geometries. Currently only EPSG:4326 is supported.

      Valid Date Formats Possible valid date formats used for parsing field values and printing filter elements

      Refresh If the field mappings or Elasticsearch schema has changed since this page was loaded, use this button to update the field configuration list.

      To return to the field table after it has been closed, click the \"Configure Elasticsearch fields\" button below the \"Feature Type Details\" panel on the layer configuration page.

      "},{"location":"community/elasticsearch/#configuring-logging","title":"Configuring logging","text":"

      Logging is configurable through Log4j. The data store includes logging such as the query object being sent to Elasticsearch, which is logged at a lower level than may be enabled by default. To enable these logs, add the following lines to the GeoServer logging configuration file (see GeoServer Global Settings):

      log4j.category.org.geoserver.data.elasticsearch=DEBUG \nlog4j.category.org.geoserver.process.elasticsearch=DEBUG\n

      The logging configuration file will be in the logs subdirectory in the GeoServer data directory. Check GeoServer global settings for which logging profile is being used (e.g. DEFAULT_LOGGING, etc.).

      "},{"location":"community/elasticsearch/#filtering","title":"Filtering","text":"

      Filtering capabilities include OpenGIS simple comparisons, temporal comparisons, as well as other common filter comparisons. Elasticsearch natively supports numerous spatial filter operators, depending on the type:

      • geo_shape types natively support BBOX/Intersects, Within and Disjoint binary spatial operators
      • geo_point types natively support BBOX and Within binary spatial operators, as well as the DWithin and Beyond distance buffer operators

      Requests involving spatial filter operators not natively supported by Elasticsearch will include an additional filtering operation on the results returned from the query, which may impact performance.

      "},{"location":"community/elasticsearch/#native-queries","title":"Native queries","text":"

      Native Elasticsearch queries can be applied in WMS feature requests through a custom rendering transformation, vec:GeoHashGrid, which translates aggregation response data into a raster for display. If supplied, the query is combined with the query derived from the request bbox, CQL or OGC filter using the AND logical binary operator.

      "},{"location":"community/elasticsearch/#examples","title":"Examples","text":"

      BBOX and CQL filter:

      http://localhost:8080/geoserver/test/wms?service=WMS&version=1.1.0&request=GetMap\n     &layers=test:active&styles=&bbox=-1,-1,10,10&width=279&height=512\n     &srs=EPSG:4326&format=application/openlayers&maxFeatures=1000\n     &cql_filter=standard_ss='IEEE 802.11b'\n

      BBOX and native query:

      http://localhost:8080/geoserver/test/wms?service=WMS&version=1.1.0&request=GetMap\n     &layers=test:active&styles=NativeQueryStyle&bbox=-1,-1,10,10&width=279&height=512\n     &srs=EPSG:4326&format=application/openlayers&maxFeatures=1000\n\n\n<StyledLayerDescriptor version=\"1.0.0\"\n   xsi:schemaLocation=\"http://www.opengis.net/sld StyledLayerDescriptor.xsd\"\n   xmlns=\"http://www.opengis.net/sld\"\n   xmlns:ogc=\"http://www.opengis.net/ogc\"\n   xmlns:xlink=\"http://www.w3.org/1999/xlink\"\n   xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\">\n <NamedLayer>\n   <Name>test</Name>\n   <UserStyle>\n     <Title>Test</Title>\n     <Abstract>Test Native Query</Abstract>\n     <FeatureTypeStyle>\n       <Transformation>\n         <ogc:Function name=\"vec:GeoHashGrid\">\n           <ogc:Function name=\"parameter\">\n             <ogc:Literal>data</ogc:Literal>\n           </ogc:Function>\n           <ogc:Function name=\"parameter\">\n             <ogc:Literal>queryDefinition</ogc:Literal>\n             <ogc:Literal>{\"term\":{\"standard_ss\":\"IEEE 802.11b\"}}\n           </ogc:Function>\n           <ogc:Function name=\"parameter\">\n             <ogc:Literal>outputBBOX</ogc:Literal>\n             <ogc:Function name=\"env\">\n               <ogc:Literal>wms_bbox</ogc:Literal>\n             </ogc:Function>\n           </ogc:Function>\n           <ogc:Function name=\"parameter\">\n             <ogc:Literal>outputWidth</ogc:Literal>\n             <ogc:Function name=\"env\">\n               <ogc:Literal>wms_width</ogc:Literal>\n             </ogc:Function>\n           </ogc:Function>\n           <ogc:Function name=\"parameter\">\n             <ogc:Literal>outputHeight</ogc:Literal>\n             <ogc:Function name=\"env\">\n               <ogc:Literal>wms_height</ogc:Literal>\n             </ogc:Function>\n           </ogc:Function>\n         </ogc:Function>\n       </Transformation>\n       <Rule>\n        <RasterSymbolizer>\n          <Geometry>\n            <!-- Actual geometry property name in feature source -->\n            <ogc:PropertyName>geo</ogc:PropertyName></Geometry>\n          <Opacity>0.6</Opacity>\n          <ColorMap type=\"ramp\" >\n            <ColorMapEntry color=\"#FFFFFF\" quantity=\"0\" label=\"nodata\" opacity=\"0\"/>\n            <ColorMapEntry color=\"#2851CC\" quantity=\"1\" label=\"values\"/>\n            <ColorMapEntry color=\"#211F1F\" quantity=\"2\" label=\"label\"/>\n            <ColorMapEntry color=\"#EE0F0F\" quantity=\"3\" label=\"label\"/>\n            <ColorMapEntry color=\"#AAAAAA\" quantity=\"4\" label=\"label\"/>\n            <ColorMapEntry color=\"#6FEE4F\" quantity=\"5\" label=\"label\"/>\n            <ColorMapEntry color=\"#DDB02C\" quantity=\"10\" label=\"label\"/>\n          </ColorMap>\n        </RasterSymbolizer>\n       </Rule>\n     </FeatureTypeStyle>\n   </UserStyle>\n </NamedLayer>\n</StyledLayerDescriptor>\n
      "},{"location":"community/elasticsearch/#aggregations","title":"Aggregations","text":"

      Elasticsearch aggregations are supported through WMS requests by including the query in WMS requests through a custom rendering transformation, vec:GeoHashGrid, which translates aggregation response data into a raster for display.

      Note that size is set to zero when an aggregation is supplied so only aggregation features are returned (e.g. maxFeatures is ignored and there will be no search hit results). See FAQ for common issues using aggregations.

      "},{"location":"community/elasticsearch/#geohash-grid-aggregations","title":"Geohash grid aggregations","text":"

      Geohash grid aggregation support includes dynamic precision updating and a custom rendering transformation for visualization. Geohash grid aggregation precision is updated dynamically to approximate the specified grid_size based on current bbox extent and the additional grid_threshold parameter as described above.

      Geohash grid aggregation visualization is supported in WMS requests through a custom rendering transformation, vec:GeoHashGrid, which translates aggregation response data into a raster for display. By default, raster values correspond to the aggregation bucket doc_count. The following shows an example GeoServer style that uses the GeoHashGrid rendering transformation:

      <StyledLayerDescriptor version=\"1.0.0\"\n    xsi:schemaLocation=\"http://www.opengis.net/sld StyledLayerDescriptor.xsd\"\n    xmlns=\"http://www.opengis.net/sld\"\n    xmlns:ogc=\"http://www.opengis.net/ogc\"\n    xmlns:xlink=\"http://www.w3.org/1999/xlink\"\n    xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\">\n  <NamedLayer>\n    <Name>GeoHashGrid</Name>\n    <UserStyle>\n      <Title>GeoHashGrid</Title>\n      <Abstract>GeoHashGrid aggregation</Abstract>\n      <FeatureTypeStyle>\n        <Transformation>\n          <ogc:Function name=\"vec:GeoHashGrid\">\n            <ogc:Function name=\"parameter\">\n              <ogc:Literal>data</ogc:Literal>\n            </ogc:Function>\n            <ogc:Function name=\"parameter\">\n              <ogc:Literal>gridStrategy</ogc:Literal>\n              <ogc:Literal>Basic</ogc:Literal>\n            </ogc:Function>\n            <ogc:Function name=\"parameter\">\n              <ogc:Literal>outputBBOX</ogc:Literal>\n              <ogc:Function name=\"env\">\n                <ogc:Literal>wms_bbox</ogc:Literal>\n              </ogc:Function>\n            </ogc:Function>\n            <ogc:Function name=\"parameter\">\n              <ogc:Literal>outputWidth</ogc:Literal>\n              <ogc:Function name=\"env\">\n                <ogc:Literal>wms_width</ogc:Literal>\n              </ogc:Function>\n            </ogc:Function>\n            <ogc:Function name=\"parameter\">\n              <ogc:Literal>outputHeight</ogc:Literal>\n              <ogc:Function name=\"env\">\n                <ogc:Literal>wms_height</ogc:Literal>\n              </ogc:Function>\n            </ogc:Function>\n          </ogc:Function>\n        </Transformation>\n        <Rule>\n         <RasterSymbolizer>\n           <Geometry>\n             <!-- Actual geometry property name in feature source -->\n             <ogc:PropertyName>geo</ogc:PropertyName></Geometry>\n           <Opacity>0.6</Opacity>\n           <ColorMap type=\"ramp\" >\n             <ColorMapEntry color=\"#FFFFFF\" quantity=\"0\" label=\"nodata\" opacity=\"0\"/>\n             <ColorMapEntry color=\"#2851CC\" quantity=\"1\" label=\"values\"/>\n             <ColorMapEntry color=\"#211F1F\" quantity=\"2\" label=\"label\"/>\n             <ColorMapEntry color=\"#EE0F0F\" quantity=\"3\" label=\"label\"/>\n             <ColorMapEntry color=\"#AAAAAA\" quantity=\"4\" label=\"label\"/>\n             <ColorMapEntry color=\"#6FEE4F\" quantity=\"5\" label=\"label\"/>\n             <ColorMapEntry color=\"#DDB02C\" quantity=\"10\" label=\"label\"/>\n           </ColorMap>\n         </RasterSymbolizer>\n        </Rule>\n      </FeatureTypeStyle>\n    </UserStyle>\n  </NamedLayer>\n </StyledLayerDescriptor>\n

      Example WMS request including Geohash grid aggregation with the above custom style:

      http://localhost:8080/geoserver/test/wms?service=WMS&version=1.1.0&request=GetMap\n     &layers=test:active&styles=geohashgrid&bbox=0.0,0.0,24.0,44.0&srs=EPSG:4326\n     &width=418&height=768&format=application/openlayers\n

      The Elasticsearch aggregation definition can be computed automatically, or provided as an explicit parameter, for example:

      <ogc:Function name=\"parameter\">\n  <ogc:Literal>aggregationDefinition</ogc:Literal>\n  <ogc:Literal>{\"agg\": {\"geohash_grid\": {\"field\": \"_ogr_geometry_.coordinates\", \"precision\": 3}}}</ogc:Literal>\n</ogc:Function>\n

      The store may update the precision to a smaller value, if it finds it goes beyond the aggregation limits setup in its configuration, see grid_size and grid_threshold above.

      "},{"location":"community/elasticsearch/#grid-strategy","title":"Grid Strategy","text":"

      gridStrategy: Parameter to identify the org.geoserver.process.elasticsearch.GeoHashGrid implementation that will be used to convert each geohashgrid bucket into a raster value (number).

      Name gridStrategy gridStrategyArgs Description

      Basic basic no Raster value is geohashgrid bucket doc_count.

      Metric metric yes Raster value is geohashgrid bucket metric value.

      Nested nested_agg yes Extract raster value from nested aggregation results.

      gridStrategyArgs: (Optional) Parameter used to specify an optional argument list for the grid strategy.

      emptyCellValue: (Optional) Parameter used to specify the value for empty grid cells. By default, empty grid cells are set to 0.

      scaleMin, scaleMax: (Optional) Parameters used to specify a scale applied to all raster values. Each tile request is scaled according to the min and max values for that tile. It is best to use a non-tiled layer with this parameter to avoid confusing results.

      useLog: (Optional) Flag indicating whether to apply logarithm to raster values (applied prior to scaling, if applicable)

      "},{"location":"community/elasticsearch/#basic","title":"Basic","text":"

      Raster value is geohashgrid bucket doc_count.

      Example Aggregation:

      {\n  \"agg\": {\n    \"geohash_grid\": {\n      \"field\": \"geo\"\n    }\n  }\n}\n

      Example bucket:

      {\n  \"key\" : \"xv\",\n  \"doc_count\" : 1\n}\n

      Extracted raster value: 1

      "},{"location":"community/elasticsearch/#metric","title":"Metric","text":"

      Raster value is geohashgrid bucket metric value.

      Argument Index Default Value Description

      0 metric Key used to pluck metric object from top level bucket. Empty string results in plucking doc_count.

      1 value Key used to pluck the value from the metric object.

      Example Aggregation:

      {\n  \"agg\": {\n    \"geohash_grid\": {\n      \"field\": \"geo\"\n    },\n    \"aggs\": {\n      \"metric\": {\n        \"max\": {\n          \"field\": \"magnitude\"\n        }\n      }\n    }\n  }\n}\n

      Example bucket:

      {\n  \"key\" : \"xv\",\n  \"doc_count\" : 1,\n  \"metric\" : {\n    \"value\" : 4.9\n  }\n}\n

      Extracted raster value: 4.9

      "},{"location":"community/elasticsearch/#nested","title":"Nested","text":"

      Extract raster value from nested aggregation results.

      Argument Index Default Value Description

      0 nested Key used to pluck nested aggregation results from the geogrid bucket.

      1 empty string Key used to pluck metric object from each nested aggregation bucket. Empty string results in plucking doc_count.

      2 value Key used to pluck the value from the metric object.

      3 largest largest | smallest. Strategy used to select a bucket from the nested aggregation buckets. The grid cell raster value is extracted from the selected bucket.

      4 value key | value. Strategy used to extract the raster value from the selected bucket. value: Raster value is the selected bucket's metric value. key: Raster value is the selected bucket's key.

      5 null (Optional) Map used to convert String keys into numeric values. Use the format key1:1;key2:2. Only utilized when raster strategy is key.

      Example Aggregation:

      {\n  \"agg\": {\n    \"geohash_grid\": {\n      \"field\": \"geo\"\n    },\n    \"aggs\": {\n      \"nested\": {\n        \"histogram\": {\n          \"field\": \"magnitude\",\n          \"interval\": 1,\n          \"min_doc_count\": 1\n        }\n      }\n    }\n  }\n}\n

      Example Parameters:

      <ogc:Function name=\"parameter\">\n  <ogc:Literal>gridStrategyArgs</ogc:Literal>\n  <ogc:Literal>nested</ogc:Literal>\n  <ogc:Literal></ogc:Literal>\n  <ogc:Literal></ogc:Literal>\n  <ogc:Literal>largest</ogc:Literal>\n  <ogc:Literal>key</ogc:Literal>\n</ogc:Function>\n

      Example bucket:

      {\n  \"key\" : \"xv\",\n  \"doc_count\" : 1729,\n  \"nested\" : {\n    \"buckets\" : [\n      {\n        \"key\" : 2.0,\n        \"doc_count\" : 5\n      },\n      {\n        \"key\" : 3.0,\n        \"doc_count\" : 107\n      },\n      {\n        \"key\" : 4.0,\n        \"doc_count\" : 1506\n      },\n      {\n        \"key\" : 5.0,\n        \"doc_count\" : 100\n      },\n      {\n        \"key\" : 6.0,\n        \"doc_count\" : 11\n      }\n    ]\n  }\n}\n

      Extracted raster value: 4.0

      "},{"location":"community/elasticsearch/#implementing-a-custom-grid-strategy","title":"Implementing a custom Grid Strategy","text":"

      By default the raster values computed in the geohash grid aggregation rendering transformation correspond to the top level doc_count. Adding an additional strategy for computing the raster values from bucket data currently requires source code updates to the gt-elasticsearch-process module as described below.

      First create a custom implementation of org.geoserver.process.elasticsearch.GeoHashGrid and provide an implementation of the computeCellValue method, which takes the raw bucket data and returns the raster value. For example, the default basic implementation simply returns the doc_count:

      public class BasicGeoHashGrid extends GeoHashGrid {\n    @Override\n    public Number computeCellValue(Map<String,Object> bucket) {\n        return (Number) bucket.get(\"doc_count\");\n    }\n}\n

      Then update org.geoserver.process.elasticsearch.GeoHashGridProcess and add a new entry to the Strategy enum to point to the custom implementation.

      After deploying the customized plugin, the new geohash grid computer can be used by updating the gridStrategy parameter in the GeoServer style:

      <StyledLayerDescriptor version=\"1.0.0\"\n    ...\n        <Transformation>\n          <ogc:Function name=\"vec:GeoHashGrid\">\n            ...\n            <ogc:Function name=\"parameter\">\n              <ogc:Literal>gridStrategy</ogc:Literal>\n              <ogc:Literal>NewName</ogc:Literal>\n            </ogc:Function>\n
      "},{"location":"community/elasticsearch/#FAQ","title":"FAQ","text":"
      • By default, arrays are returned directly, which is suitable for many output formats including GeoJSON. When using CSV output format with layers containing arrays it's necessary to set the array_encoding store parameter to CSV. Note however when using the CSV array encoding that only the first value will be returned.
      • When updating from pre-2.11.0 versions of the plugin it may be necessary to reload older layers to enable full aggregation and time support. Missing aggregation data or errors of the form IllegalArgumentException: Illegal pattern component indicate a layer reload is necessary. In this case the layer must be removed and re-added to GeoServer (e.g. a feature type reload will not be sufficient).
      • Commas in the native query and aggregation body must be escaped with a backslash. Additionally, body may need to be URL encoded.
      • Geometry property name in the aggregation SLD RasterSymbolizer must be a valid geometry property in the layer
      • PropertyIsEqualTo maps to an Elasticsearch term query, which will return documents that contain the supplied term. When searching on an analyzed string field, ensure that the search values are consistent with the analyzer used in the index. For example, values may need to be lowercase when querying fields analyzed with the default analyzer. See the Elasticsearch term query documentation for more information.
      • PropertyIsLike maps to either a query string query or a regexp query, depending on whether the field is analyzed or not. Reserved characters should be escaped as applicable. Note case sensitive and insensitive searches may not be supported for analyzed and not analyzed fields, respectively. See Elasticsearch query string and regexp query documentation for more information.
      • Date conversions are handled using the valid date formats from the associated type mapping, or date_optional_time if not found. Note that UTC timezone is used for both parsing and printing of dates.
      • Filtering on Elasticsearch object types is supported. By default, field names will include the full path to the field (e.g. \"parent.child.field_name\"), but this can be changed in the GeoServer layer configuration.
        • When referencing fields with path elements using cql_filter, it may be necessary to quote the name (e.g. cql_filter=\"parent.child.field_name\"='value')
      • Filtering on Elasticsearch nested types is supported only for non-geospatial fields.
      • Circle geometries are approximate and may not be fully consistent with the implementation in Elasticsearch, especially at extreme latitudes (see #86).
      • The joda-shaded module may need to be excluded when importing the project into Eclipse. Otherwise modules may have build errors of the form DateTimeFormatter cannot be resolved to a type.
      • When updating from Elasticgeo 2.16.0, note that the Short Names feature has been removed as it is not compatible with Elasticsearch 2.0 and beyond. Previous fields which used the short names will be reverted to the full name, but you can still use aliasing to accomplish the same effect.
      "},{"location":"community/features-templating/","title":"Features-Templating Extension","text":"

      The Features Templating plug-in works by allowing us to define a What You See Is What You Get template, that will be applied on a stream of features respecting the defined content negotiation rules. Both Simple and Complex features are supported. The following services and operations are supported:

      Service Operation

      WFS GetFeature

      WMS GetFeatureInfo

      OGCAPI Features Collection

      The following output formats are supported:

      • GeoJSON
      • GML
      • JSON-LD JSON-LD is a Linked Data format, based on JSON format, and revolves around the concept of \"context\" to provide additional mappings from JSON to an RDF model.
      • HTML

      The first part of the plug-in documentation will go through the template syntax. The second one will show how to configure the template to apply it to a vector layer. The third part shows the backwards mapping functionality.

      • Installing the GeoServer FEATURES-TEMPLATING extension
      • Template Directives
      • Template Configuration
      • Backward Mapping
      • Features Templatring Rest API
      "},{"location":"community/features-templating/configuration/","title":"Template Configuration","text":"

      This part of the documentation explains how to add new templates to GeoServer and how to define rules from the layer configuration page for when a template should be applied.

      "},{"location":"community/features-templating/configuration/#add-features-templates-to-geoserver","title":"Add Features Templates to GeoServer","text":"

      Once the plug-in is installed, the left panel of the GeoServer UI will show a new option Feature Templating under the Data section. Clicking on that option will open a table with the available templates.

      Clicking on the add New button will open the configuration page.

      In the first tab the user can specify the following values:

      • the Template Name. This name will be used for the template file name when saved in the data directory.

      • the Template File Type (file extension) of the template, by selecting one among those available.

      • the Workspace if the user wants to limit the usage of the template to the vector layers available in a specific workspace.

        • the Layer Name if the user wants to limit the usage of the template to only a specific vector layer. Selecting a Layer Name will not cause the template to be applied to that Layer. This option is intended to make the template usable only by the selected Layer. In order to apply a template content negotiation rules need to be configured on a per layer basis (see section below).

      The Workspace and Layer Name values, if specified, will also affect where the template will be saved:

      • if neither is specified the template will be saved inside the features-templating directory.
      • if a Workspace is specified the template will be saved in that workspace folder.
      • if a Layer Name is specified the template will be saved in that layer folder.

      The Template Content section is where the template is actually defined.

      • The template can be uploaded from a file, and in that case the Template Name and Template File Type fields are automatically populated from the file.
      • Otherwise the template can be written from scratch into the template editor.

      By clicking on the Preview tab the user can specify parameters to test the template and preview the result. The preview will only return a single feature.

      Warning

      When previewing a template the template will be saved/updated in the data directory. This is due the fact that the preview works by issuing a WFS request. This implies that the previous state is lost, but also that any modification is immediately visible to a user that might be accessing the layer.

      • The user must specify one value among the Available Output Formats
      • The user must specify values among those available for the Workspace and Layer Name fields.
      • If the user specified a Workspace for the template in the Data tab the preview Workspace will be automatically set from that workspace.
      • If the user specified a Layer Name for the template in the Data tab the preview Layer Name will be automatically set from that layer.
      • The user can specify a Feature ID to obtain a preview for the specified feature.
      • The user can specify a CQL Filter to obtain a preview for a feature matching the filter.

      The Validate button acts differently according to the output format:

      • In the GML case, it will trigger a schema validation based on the Schema Location specified in the template.
      • In the JSON-LD case, it will perform a JSON-LD @context validation.
      • In the GeoJSON case no validation will occur.
      "},{"location":"community/features-templating/configuration/#add-templates-rules-to-a-layer","title":"Add Templates Rules to a Layer","text":"

      To inform GeoServer when to apply a template, the user needs to specify the rules on a per layer basis. The most basic rule is one that binds a template to a specific output format. Request CQL Functions allow specifying more advanced rules.

      When the plug-in is installed a new tab will be available in the Layer configuration page, allowing for the definition of Template rules.

      Once the form is filled the user needs to press the Add button to add the rule to the rules table. The rules will be then persisted to the layer configuration only when the Save button is pressed.

      The following values can be specified:

      • the Priority needed to inform GeoServer which rule should be applied if more than one rule matches the GetFeature request.
      • the Template Name that indicates which template should be applied. If the template has a global scope the dropdown will present it with the template name value only. If a Workspace has been defined at template configuration time, the format will be {workspace name}:{template name}. If a Layer Name has been specified at template configuration time, the format will be {workspace name}:{layer name}:{template name}.
      • the Supported Output Formats dropdown shows the output formats for which a template can be invoked. The user can choose one to indicate which output format the selected template should be applied to. If the GML value is selected, the template will be applied to all GML version output formats. If different GML templates should be applied for different GML versions, it is possible to define a condition on the MIME Type using the mimeType() function.
      • the Request CQL filter area allows defining a generic CQL filter to evaluate against the request to determine if the template should be t. The available request functions to be used are listed on the right side of the form.
      • the Profile CQL Filter allows defining a CQL filter allowing a content negotiation to be done per profile. The available request functions to be used are listed on the right side of the form. There is several approaches for content negotiations per profile, for example one of them is the W3C recommended approach where the profile is provided as an HTTP header. This will translate in a CQL filter similar to this one header('Accept-Profile')='http://my-profile/geo+json'.

      An example CQL filter might be the following:

      • `requestParam('myParameter')`` = 'use this template'
      • mimeType() = 'application/geo+json'
      • requestMatchRegex('^.*matchedPart.*$') = true
      • header('testHeader') = 'myHeaderValue'

      Every rule must define either a value from the Supported Output Formats dropdown or a Request CQL filter with a filter on the mimeType() value, or both.

      Once rules are defined, if an incoming GetFeature request is matched the template corresponding to the matched rule will be applied to the output.

      "},{"location":"community/features-templating/configuration/#data-directory-configuration","title":"Data Directory configuration","text":"

      A features template can be configured directly from the GeoServer data dir without any UI usage. In this case the template needs to be placed in the Feature Type directory. When configuring templates in this way only one feature template per Feature Type is supported and the name is fixed for each output format as shown in the list below:

      • GML 2 = gml2-template.xml
      • GML 3.1 = gml31-template.xml
      • GML 3.2 = gml32-template.xml
      • JSON-LD = json-ld-template.json
      • GEOJSON = geojson-template.json
      • HTML = html-template.xhtml
      "},{"location":"community/features-templating/directives/","title":"Template Directives","text":"

      This part of the documentation is an introduction explaining the different template directives. Examples will be provided for both Simple Features and Complex Features. The syntax of the directives varies slightly between XML based templates and JSON based templates.

      The examples will be provided mainly for GeoJSON and GML. However the syntax defined for GeoJSON output, unless otherwise specified, is valid for JSON-LD templates

      "},{"location":"community/features-templating/directives/#template-directive-summary","title":"Template directive summary","text":"

      The following constitutes a summary of all the template directives and it is meant to be used for quick reference. Each directive is explained in detail in the sections below.

      "},{"location":"community/features-templating/directives/#json-based-templates","title":"JSON based templates","text":"

      The following are the directives available in JSON based templates.

      Usage Syntax Description

      property interpolation \\${property} specify it as an attribute value (\"json_attribute\":\"${property}\")

      cql evaluation \\$\\${cql} specify it as an element value (\"json_attribute\":\"$${cql}\")

      setting the evaluation context for child attributes. \\${source}. specify it as the first nested object in arrays ({\"$source\":\"property\"}) or as an attribute in objects (\"$source\":\"property\")

      filter the array, object, attribute \\$filter specify it inside the first nested object in arrays ({\"$filter\":\"condition\"}) or as an attribute in objects (\"$filter\":\"condition\") or in an attribute next to the attribute value separated by a , (\"attribute\":\"$filter{condition}, ${property}\")

      defines options to customize the output outside of a feature scope \\$options specify it at the top of the JSON template as a JSON object (GeoJSON options: \"$options\":{\"flat_output\":true, \"separator\":\".\"}; JSON-LD options: \"$options\":{\"@context\": \"the context json\", \"encode_as_string\": true, \"@type\":\"schema:SpecialAnnouncement\", \"collection_name\":\"customCollectionName\"}).

      allows including a template into another \\$include, \\$includeFlat specify the $include option as an attribute value (\"attribute\":\"$include{subProperty.json}\") and the $includeFlat as an attribute name with the included template path as a value (\"$includeFlat\":\"included.json\")

      allows a template to extend another template \\$merge specify the $merge directive as an attribute name containing the path to the extended template (:code: \"\\$merged\":\"base_template.json\").

      allows null values to be encoded. default is not encoded. \\${property}! or \\$\\${expression}! ! at the end of a property interpolation or cql directive (\"attribute\":\"${property}!\" or \"attribute\":\"$${expression}!\").

      "},{"location":"community/features-templating/directives/#xml-based-templates","title":"XML based templates","text":"

      The following are the directives available in XML based templates.

      Usage Syntax Description

      property interpolation \\${property} specify it either as an element value (<element>${property}</element>) or as an xml attribute value (<element attribute:\"${property}\"/>)

      cql evaluation \\$\\${cql} specify them either as an element value (<element>$${cql}</element>) or as an xml attribute value (<element attribute:\"$${cql}\"/>)

      setting the evaluation context for property interpolation and cql evaluation in child elements. gft:source specify it as an xml attribute (<element gft:source:\"property\">)

      filter the element to which is applied based on the defined condition gft:filter specify it as an XML attribute on the element to be filtered (<element gft:filter:\"condition\">)

      marks the beginning of an XML template. gft:Template It has to be the root element of an XML template (<gft:Template> Template content</gft:Template>)

      defines options to customize the output outside of a feature scope gft:Options specify it as an element at the beginning of the xml document after the <gft:Template> one (<gft:Options></gft:Options>). GML options: <gtf:Namespaces>,<gtf:SchemaLocation>. HTML options: <script>, :code: <script type=\"application/ld+json\"/>, <style>, :code: <link>.

      allows including a template into another \\$include, gft:includeFlat specify the $include option as an element value (<element>$include{included.xml}</element>) and the gft:includeFlat as an element having the included template as text content (<gft:includeFlat>included.xml</gft:includeFlat>)

      allows null values to be encoded. default is not encoded. \\${property}! specify it either as an element value (<element>${property}!</element>) or as an xml attribute value (<element attribute:\"${property}!\"/>)

      "},{"location":"community/features-templating/directives/#a-step-by-step-introduction-to-features-templating-syntax","title":"A step by step introduction to features-templating syntax","text":"

      This introduction is meant to illustrate the different directives that can be used in a template. For clarity the documentation will start with a Simple Feature example and then progress through a Complex Feature example. However all the directives that will be shown are available for both Simple and Complex Features. GeoJSON and GML examples will be used mostly. For JSON-LD output format the rules to define a template are the same as the GeoJSON template with two exceptions:

      • A @context needs to be specified (see the options section below).
      • The standard mandates that attributes' values are all strings.
      "},{"location":"community/features-templating/directives/#property-and-cql-directive-simple-feature-example","title":"\\${property} and \\$\\${cql} directive (Simple Feature example)","text":""},{"location":"community/features-templating/directives/#geojson","title":"GeoJSON","text":"

      Assume that we want to change the default geojson output of the topp:states layer. A single feature in the default output is like the following:

      {\n \"type\": \"Feature\",\n  \"id\": \"states.1\",\n  \"geometry\": {},\n  \"geometry_name\": \"the_geom\",\n  \"properties\": {\n  \"STATE_NAME\": \"Illinois\",\n  \"STATE_FIPS\": \"17\",\n  \"SUB_REGION\": \"E N Cen\",\n  \"STATE_ABBR\": \"IL\",\n  \"LAND_KM\": 143986.61,\n  \"WATER_KM\": 1993.335,\n  \"PERSONS\": 11430602,\n  \"FAMILIES\": 2924880,\n  \"HOUSHOLD\": 4202240,\n  \"MALE\": 5552233,\n  \"FEMALE\": 5878369,\n  \"WORKERS\": 4199206,\n  \"DRVALONE\": 3741715,\n  \"CARPOOL\": 652603,\n  \"PUBTRANS\": 538071,\n  \"EMPLOYED\": 5417967,\n  \"UNEMPLOY\": 385040,\n  \"SERVICE\": 1360159,\n  \"MANUAL\": 828906,\n  \"P_MALE\": 0.486,\n  \"P_FEMALE\": 0.514,\n  \"SAMP_POP\": 1747776\n  }\n}\n

      In particular we want to include in the final output only certain properties (e.g. the geometry, the state name, the code, values about population, male, female and workers). We want also to change some attribute names and to have them lower cased. Finally we want to have a string field having a wkt representation of the geometry. The desired output is like the following:

      {\n  \"type\":\"Feature\",\n  \"id\":\"states.1\",\n  \"geometry\":{\n     \"type\":\"MultiPolygon\",\n     \"coordinates\":\"[....]\"   \n  },\n  \"properties\":{\n     \"name\":\"Illinois\",\n     \"region\":\"E N Cen\",\n     \"code\":\"IL\",\n     \"population_data\":{\n        \"population\":114306027,\n        \"males\":5552233.0,\n        \"females\":5878369.0,\n        \"active_population\":4199206.0\n     },\n     \"wkt_geom\":\"MULTIPOLYGON (((37.51099000000001 -88.071564, [...])))\"\n  }\n}\n

      A template like this will allows us to produce the above output:

      {\n\"type\": \"Feature\",\n\"id\": \"${@id}\",\n\"geometry\": \"${the_geom}\",\n\"properties\": {\n    \"name\": \"${STATE_NAME}\",\n    \"region\": \"${SUB_REGION}\",\n    \"code\": \"${STATE_ABBR}\",\n    \"population_data\":{\n        \"population\": \"${PERSONS}\",\n        \"males\": \"${MALE}\",\n        \"females\": \"${FEMALE}\",\n        \"active_population\": \"${WORKERS}\"\n    },\n    \"wkt_geom\":\"$${toWKT(the_geom)}\"\n}\n}\n

      As it is possible to see the new output has the attribute names defined in the template. Moreover the population related attributes have been placed inside a nested json object. Finally a wkt_geom attribute with the WKT geometry representation has been added.

      "},{"location":"community/features-templating/directives/#gml","title":"GML","text":"

      The same template mechanism can be applied to a GML output format. This is an example GML template, again for the topp:states layer

      <gft:Template>\n <gft:Options>\n   <gft:Namespaces xmlns:topp=\"http://www.openplans.org/topp\"/>\n   <gft:SchemaLocation xsi:schemaLocation=\"http://www.opengis.net/wfs/2.0 http://brgm-dev.geo-solutions.it/geoserver/schemas/wfs/2.0/wfs.xsd http://www.opengis.net/gml/3.2 http://schemas.opengis.net/gml/3.2.1/gml.xsd\"/>\n </gft:Options>\n <topp:states gml:id=\"${@id}\">\n   <topp:name code=\"${STATE_ABBR}\">${STATE_NAME}</topp:name>\n   <topp:region>${SUB_REGION}</topp:region>\n   <topp:population>${PERSONS}</topp:population>\n   <topp:males>${MALE}</topp:males>\n   <topp:females>${FEMALE}</topp:females>\n   <topp:active_population>${WORKERS}</topp:active_population>\n   <topp:wkt_geom>$${toWKT(the_geom)}</topp:wkt_geom>\n </topp:states>\n</gft:Template>\n

      And this is how a feature will appear:

      <topp:states gml:id=\"states.10\">\n   <topp:name code=\"MO\">Missouri</topp:name>\n   <topp:region>W N Cen</topp:region>\n   <topp:population>5117073.0</topp:population>\n   <topp:males>2464315.0</topp:males>\n   <topp:females>2652758.0</topp:females>\n   <topp:active_population>1861192.0</topp:active_population>\n   <topp:wkt_geom>MULTIPOLYGON (([....])))</topp:wkt_geom>\n </topp:states>\n

      As it is possible to see the geometry is being encoded only as a wkt, moreover the STATE_ATTR value is now present as an xml attribute of the element topp:states. Finally elements that were not defined in the template did not show up.

      Looking at these examples it is possible to see additional directives that can customize the output:

      • Property interpolation can be invoked using the directive ${property_name}.
      • In case complex operation are needed a CQL expression can be used thought a $${cql} syntax (all CQL functions are supported).
      • Simple text values are reproduced in the final output as they are.
      • Finally the GML template needs the actual template content to be wrapped into a gft:Template element. The gft doesn't needs to be bound to a namespace. It is used just as marker of a features-templating related element and will not be present in the final output.
      • There is also another element, the gft:Options, with two more elements inside. It will be explained in a later dedicated section.
      "},{"location":"community/features-templating/directives/#source-and-filter-complex-feature-example","title":"Source and filter (Complex Feature example)","text":""},{"location":"community/features-templating/directives/#geojson_1","title":"GeoJSON","text":"

      Let's assume now that an AppSchema layer has been configured and customization of the complex features output is needed. The Meteo Stations use case will be used as an example. For a description of the use case check the documentation at Smart Data Loader Extension. This is the domain model of the use case:

      The default GeoJSON output format produces features like the following:

      {\n  \"type\":\"Feature\",\n  \"id\":\"MeteoStationsFeature.7\",\n  \"geometry\":{\n\n  },\n  \"properties\":{\n     \"@featureType\":\"MeteoStations\",\n     \"id\":7,\n     \"code\":\"BOL\",\n     \"common_name\":\"Bologna\",\n     \"meteoObservations\":[\n        {\n           \"id\":3,\n           \"time\":\"2016-12-19T11:28:31Z\",\n           \"value\":35,\n           \"meteoParameters\":[\n              {\n                 \"id\":1,\n                 \"param_name\":\"temperature\",\n                 \"param_unit\":\"C\"\n              }\n           ]\n        },\n        {\n           \"id\":4,\n           \"time\":\"2016-12-19T11:28:55Z\",\n           \"value\":25,\n           \"meteoParameters\":[\n              {\n                 \"id\":1,\n                 \"param_name\":\"temperature\",\n                 \"param_unit\":\"C\"\n              }\n           ]\n        },\n        {\n           \"id\":5,\n           \"time\":\"2016-12-19T11:29:24Z\",\n           \"value\":80,\n           \"meteoParameters\":[\n              {\n                 \"id\":2,\n                 \"param_name\":\"wind speed\",\n                 \"param_unit\":\"Km/h\"\n              }\n           ]\n        },\n        {\n           \"id\":6,\n           \"time\":\"2016-12-19T11:30:26Z\",\n           \"value\":1019,\n           \"meteoParameters\":[\n              {\n                 \"id\":3,\n                 \"param_name\":\"pressure\",\n                 \"param_unit\":\"hPa\"\n              }\n           ]\n        },\n        {\n           \"id\":7,\n           \"time\":\"2016-12-19T11:30:51Z\",\n           \"value\":1015,\n           \"meteoParameters\":[\n              {\n                 \"id\":3,\n                 \"param_name\":\"pressure\",\n                 \"param_unit\":\"hPa\"\n              }\n           ]\n        }\n     ]\n  }\n}\n

      The above JSON has a data structure where:

      • Station object has a nested array of Observations.
      • Each Observation has a an array of parameter that describe the type of Observation.

      Now let's assume that a different output needs to be produced where instead of having a generic array of observation nested into the root object, arrays are provided separately for each type of parameter e.g. Temperatures, Pressures and Winds_speed observations. In other words instead of having the Observation type defined inside a nested Parameter object that information should be provided directly in the attribute name. The desired output looks like the following:

      {\n \"type\":\"FeatureCollection\",\n \"features\":[\n    {\n       \"Identifier\":\"MeteoStationsFeature.7\",\n       \"geometry\":{\n          \"type\":\"Point\",\n          \"coordinates\":[\n             44.5,\n             11.34\n          ]\n       },\n       \"properties\":{\n          \"Name\":\"Bologna\",\n          \"Code\":\"STATION-BOL\",\n          \"Location\":\"POINT (44.5 11.34)\",\n          \"Temperatures\":[\n             {\n                \"Timestamp\":\"2016-12-19T11:28:31.000+00:00\",\n                \"Value\":35.0\n             },\n             {\n                \"Timestamp\":\"2016-12-19T11:28:55.000+00:00\",\n                \"Value\":25.0\n             }\n          ],\n          \"Pressures\":[\n             {\n                \"Timestamp\":\"2016-12-19T11:30:26.000+00:00\",\n                \"Value\":1019.0\n             },\n             {\n                \"Timestamp\":\"2016-12-19T11:30:51.000+00:00\",\n                \"Value\":1015.0\n             }\n          ],\n          \"Winds_speed\":[\n             {\n                \"Timestamp\":\"2016-12-19T11:29:24.000+00:00\",\n                \"Value\":80.0\n             }\n          ]\n       }\n    }\n ],\n \"totalFeatures\":3,\n \"numberMatched\":3,\n \"numberReturned\":1,\n \"timeStamp\":\"2021-07-13T14:00:19.457Z\",\n \"crs\":{\n    \"type\":\"name\",\n    \"properties\":{\n       \"name\":\"urn:ogc:def:crs:EPSG::4326\"\n    }\n }\n}\n

      A template like this will allow to produce such an output:

      {\n     \"$source\":\"st:MeteoStationsFeature\",\n     \"Identifier\":\"${@id}\",\n     \"geometry\":\"${st:position}\",\n     \"properties\":{\n     \"Name\":\"${st:common_name}\",\n     \"Code\":\"$${strConcat('STATION-', xpath('st:code'))}\",\n     \"Location\":\"$${toWKT(xpath('st:position'))}\",\n     \"Temperatures\":[\n       {\n         \"$source\":\"st:meteoObservations/st:MeteoObservationsFeature\",\n         \"$filter\":\"xpath('st:meteoParameters/st:MeteoParametersFeature/st:param_name') = 'temperature'\"\n       },\n       {\n         \"Timestamp\": \"${st:time}\",\n         \"Value\": \"${st:value}\"\n       }\n     ],\n     \"Pressures\":[\n       {\n         \"$source\":\"st:meteoObservations/st:MeteoObservationsFeature\",\n         \"$filter\":\"xpath('st:meteoParameters/st:MeteoParametersFeature/st:param_name') = 'pressure'\"\n       },\n       {\n         \"Timestamp\": \"${st:time}\",\n         \"Value\": \"${st:value}\"\n       }\n     ],\n     \"Winds_speed\":[\n       {\n         \"$source\":\"st:meteoObservations/st:MeteoObservationsFeature\",\n         \"$filter\":\"xpath('st:meteoParameters/st:MeteoParametersFeature/st:param_name') = 'wind speed'\"\n       },\n       {\n         \"Timestamp\": \"${st:time}\",\n         \"Value\": \"${st:value}\"\n       }\n     ]\n   }\n  }\n

      In addition to the ${property} and $${cql} directives seen before, there are two more:

      • In the example above the xpath('xpath') function is used to reference property. When dealing with Complex Features it must be used when referencing properties inside a $filter or a $${cql} directive.
      • $source which is meant to provide the context against which evaluated nested element properties and xpaths. In this case the \"$source\":\"st:meteoObservations/st:MeteoObservationsFeature\" provides the context for the nested attributes angainst which the directives will be evaluated. When defining a $source for a JSON array it should be provided in a JSONObject separated from the JSON Object mapping the nested feature attributes as in the example above. When defining the $source for a JSONObject it can be simply added as an object attribute (see below examples).
      • When using ${property} directive or an xpath('xpath') function it is possible to reference a property bounded to an upper $source using a ../ notation eg. ${../previousContextValue}.
      • $filter provides the possibility to filter the value that will be included in the element to which is applied, in this case a json array. For instance the filter $filter\":\"xpath('st:meteoParameters/st:MeteoParametersFeature/st:param_name') = 'wind speed' in the Winds_speed array allows filtering the element that will be included in this array according to the param_name value.

      One note aboute the Source. It is strictly needed only when referencing a nested feature. This means that in the GeoJSON template example the \"$source\":\"st:MeteoStationsFeature\" could have been omitted. This not apply for nested elements definition where the \"$source\":\"st:meteoObservations/st:MeteoObservationsFeature\" is mandatory.

      Follows a list of JSON template bits showing filters definition in context different from a JSON array, as well as $source definition for a JSONObject.

      • Object (encode the JSON object only if the st:value is greater than 75.3).
      {\n  \"Observation\":\n        {\n          \"$source\":\"st:MeteoObservationsFeature\",\n          \"$filter\":\"st:value > 75.3 \",\n          \"Timestamp\":\"${st:time}\",\n          \"Value\":\"${st:value}\"\n       }\n}\n
      • Attribute (encode the Timestamp attribute only if the st:value is greater than 75.3).
      {\n\"Observation\":\n       {\n         \"$source\":\"st:MeteoObservationsFeature\",\n         \"Timestamp\":\"$filter{st:value > 75.3}, ${st:time}\",\n         \"Value\":\"${st:value}\"\n      }\n}\n
      • Static attribute (encode the Static_value attribute only if the st:value is greater than 75.3).
      {\n\"Observation\":\n      {\n        \"$source\":\"st:MeteoObservationsFeature\",\n        \"Timestamp\":\"${st:time}\",\n        \"Static_value\":\"$filter{st:value > 75.3}, this Observation has a value > 75.3\",\n        \"Value\":\"${st:value}\"\n     }\n}\n

      As it is possible to see from the previous example in the array and object cases the filter syntax expected a \"$filter\" key followed by an attribute with the filter to evaluate. In the attribute case, instead, the filter is being specified inside the value as \"$filter{...}\", followed by the CQL expression, or by the static content, with a comma separating the two.

      "},{"location":"community/features-templating/directives/#gml_1","title":"GML","text":"

      filter and source are available as well in GML templates. Assuming that the desired output is the corresponding GML equivalent of the GeoJSON output above e.g.:

      <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<wfs:FeatureCollection xmlns:st=\"http://www.stations.org/1.0\" xmlns:xs=\"http://www.w3.org/2001/XMLSchema\" xmlns:wfs=\"http://www.opengis.net/wfs/2.0\" xmlns:xlink=\"http://www.w3.org/1999/xlink\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xmlns:gml=\"http://www.opengis.net/gml/3.2\" numberMatched=\"3\" numberReturned=\"0\" timeStamp=\"2021-07-13T15:09:28.620Z\">\n<wfs:member>\n <st:MeteoStations gml:id=\"MeteoStationsFeature.7\">\n   <st:code>Station_BOL</st:code>\n   <st:name>Bologna</st:name>\n   <st:geometry>\n     <gml:Point srsName=\"urn:ogc:def:crs:EPSG::4326\" srsDimension=\"2\" gml:id=\"smdl-stations.1.geom\">\n       <gml:pos>11.34 44.5</gml:pos>\n     </gml:Point>\n   </st:geometry>\n   <st:temperature>\n     <st:temperature>\n       <st:Temperature>\n         <st:time>2016-12-19T11:28:31.000Z</st:time>\n         <st:value>35.0</st:value>\n       </st:Temperature>\n     </st:temperature>\n     <st:temperature>\n       <st:Temperature>\n         <st:time>2016-12-19T11:28:55.000Z</st:time>\n         <st:value>25.0</st:value>\n       </st:Temperature>\n     </st:temperature>\n   </st:temperature>\n   <st:pressure>\n     <st:pressure>\n       <st:Pressure>\n         <st:time>2016-12-19T11:30:26.000Z</st:time>\n         <st:value>1019.0</st:value>\n       </st:Pressure>\n     </st:pressure>\n     <st:pressure>\n       <st:Pressure>\n         <st:time>2016-12-19T11:30:51.000Z</st:time>\n         <st:value>1015.0</st:value>\n       </st:Pressure>\n     </st:pressure>\n   </st:pressure>\n   <st:wind_speed>\n     <st:wind_speed>\n       <st:Wind_speed>\n         <st:time>2016-12-19T11:29:24.000Z</st:time>\n         <st:value>80.0</st:value>\n       </st:Wind_speed>\n     </st:wind_speed>\n   </st:wind_speed>\n </st:MeteoStations>\n</wfs:member>\n</wfs:FeatureCollection>\n

      The following GML template will produce the above output:

      <gft:Template>\n<gft:Options>\n  <gft:Namespaces xmlns:st=\"http://www.stations.org/1.0\"/>\n</gft:Options>\n<st:MeteoStations gml:id=\"${@id}\">\n<st:code>$${strConcat('Station_',st:code)}</st:code>\n<st:name>${st:common_name}</st:name>\n<st:geometry>${st:position}</st:geometry>\n<st:temperature gft:isCollection=\"true\" gft:source=\"st:meteoObservations/st:MeteoObservationsFeature\" gft:filter=\"xpath('st:meteoParameters/st:MeteoParametersFeature/st:param_name') = 'temperature'\">\n<st:Temperature>\n  <st:time>${st:time}</st:time>\n  <st:value>${st:value}</st:value>\n</st:Temperature>\n</st:temperature>\n<st:pressure gft:isCollection=\"true\" gft:source=\"st:meteoObservations/st:MeteoObservationsFeature\"  gft:filter=\"xpath('st:meteoParameters/st:MeteoParametersFeature/st:param_name') = 'pressure'\">\n<st:Pressure>\n  <st:time>${st:time}</st:time>\n  <st:value>${st:value}</st:value>\n</st:Pressure>\n</st:pressure>\n<st:wind_speed gft:isCollection=\"true\" gft:source=\"st:meteoObservations/st:MeteoObservationsFeature\"  gft:filter=\"xpath('st:meteoParameters/st:MeteoParametersFeature/st:param_name') = 'wind speed'\">\n<st:Wind_speed>\n  <st:time>${st:time}</st:time>\n  <st:value>${st:value}</st:value>\n</st:Wind_speed>\n</st:wind_speed>\n</st:MeteoStations>\n</gft:Template>\n

      In the GML case filter and source directives are defined in a slightly different manner from the JSON usecase.

      • The filter needs to be defined as an attribute gft:filter in the element that is meant to be filtered.
      • The source needs to be defined as an attribute gft:source in the element that will set the source for its child elements.
      • The attribute gft:isCollection=\"true\" defines a directive meant to be used in GML templates to mark collection elements: this directive is needed since XML doesn't have the array concept and the template mechanism needs to be informed if an element should be repeated because it represent a collection element.

      As for the GeoJSON case the source is not needed for the top level feature. In this case we indeed omitted it for the st:MeteoStations element. Instead, as stated above, it is mandatory for nested elements like Temperature, Pressure and Winds_speed. All of them show indeed a gft:source=\"st:meteoObservations/st:MeteoObservationsFeature\".

      "},{"location":"community/features-templating/directives/#more-on-xpath-function","title":"More on XPath Function","text":"

      The xpath('xpath') function is meant to provide the possibility to reference a Feature's properties no matter how nested, in a template, providing also the possibility to reference the previous context value through ../.

      Check the following template from the GeoJSON Stations use case.

      {\n\"$source\":\"st:MeteoStationsFeature\",\n\"properties\":{\n   \"Code\":\"$${strConcat('STATION-', xpath('st:code'))}\",\n   \"Location\":\"$${toWKT(xpath('st:position'))}\",\n   \"Temperatures\":[\n    {\n       \"$source\":\"st:meteoObservations/st:MeteoObservationsFeature\",\n       \"$filter\":\"xpath('st:meteoParameters/st:MeteoParametersFeature/st:param_name') = 'temperature'\"\n    },\n    {\n      \"Value\": \"${st:value}\",\n      \"StillCode\":\"$${strConcat('STATION-', xpath('../st:code'))}\"\n     }\n ]\n}\n

      In the Temperatures array a StillCode attribute has been defined that through ../ references not the \"$source\":\"st:meteoObservations/st:MeteoObservationsFeature\", but the previous one \"$source\":\"st:MeteoStationsFeature\".

      The same can be achieved with the property interpolation directive if a cql function evaluation is not needed: \"StillCode\":\"$${strConcat('STATION-', xpath('../st:code'))}\".

      Warning

      the xpath('some xpath) cql function is meant to be used in the scope of this plugin. For general usage please refer to the property function.

      "},{"location":"community/features-templating/directives/#template-options","title":"Template Options","text":"

      The directives seen so far allow control of the output in the scope of a Feature element. The options directive, instead, allows customizing the output for part of the output outside the Feature scope or to define general modifications to the overall output. The available options vary according to the output format.

      "},{"location":"community/features-templating/directives/#geojson_2","title":"GeoJSON","text":"

      In the context of a GeoJSON template two options are available: flat_output and separator. These options are meant to provide a GeoJSON output encoded following INSPIRE rule for alternative feature GeoJSON encoding (see also). To use the functionality an \"$options\" JSON object can be added on top of a JSON template, like in the following example:

      {\n     \"$options\":{\n       \"flat_output\":true,\n       \"separator\": \".\"\n     },\n     \"$source\":\"st:MeteoStationsFeature\",\n     \"Identifier\":\"${@id}\",\n     \"geometry\":\"${st:position}\",\n     \"properties\":{\n     \"Name\":\"${st:common_name}\",\n     \"Code\":\"$${strConcat('STATION-', xpath('st:code'))}\",\n     \"Location\":\"$${toWKT(xpath('st:position'))}\",\n     \"Temperatures\":[\n       {\n         \"$source\":\"st:meteoObservations/st:MeteoObservationsFeature\",\n         \"$filter\":\"xpath('st:meteoParameters/st:MeteoParametersFeature/st:param_name') = 'temperature'\"\n       },\n       {\n         \"Timestamp\": \"${st:time}\",\n         \"Value\": \"${st:value}\"\n       }\n     ],\n     \"Pressures\":[\n       {\n         \"$source\":\"st:meteoObservations/st:MeteoObservationsFeature\",\n         \"$filter\":\"xpath('st:meteoParameters/st:MeteoParametersFeature/st:param_name') = 'pressure'\"\n       },\n       {\n         \"Timestamp\": \"${st:time}\",\n         \"Value\": \"${st:value}\"\n       }\n     ],\n     \"Winds_speed\":[\n       {\n         \"$source\":\"st:meteoObservations/st:MeteoObservationsFeature\",\n         \"$filter\":\"xpath('st:meteoParameters/st:MeteoParametersFeature/st:param_name') = 'wind speed'\"\n       },\n       {\n         \"Timestamp\": \"${st:time}\",\n         \"Value\": \"${st:value}\"\n       }\n     ]\n   }\n  }\n

      The flat_output will act in the following way:

      • The encoding of nested arrays and objects will be skipped, by encoding only their attributes.
      • Object attribute names will be concatenated with the names of their json attributes.
      • Arrays' attribute names will be concatenated as well with the one of the json attributes of their inner object. In addition an index value will be added after the array's attribute name for each nested object.
      • The separator specifies the separator of the attributes' names. Default is _.
      • The final output will have a flat list of attributes with names produced by the concatenation, like the following.
      "},{"location":"community/features-templating/directives/#json-ld","title":"JSON-LD","text":"

      A JSON-LD template can be defined as a GeoJSON template since it is a JSON based output as well. However it needs to have a @context attribute, object or array at the beginning of it in order to conform to the standard. Moreover each JSON Object must have an @type defining a type through a vocabulary term. To accomplish these requirements it is possible to specify several $options on the template:

      • @context providing a full JSON-LD @context.
      • @type providing a type term for the root JSON object in the final output (by default the value is FeatureCollection).
      • collection_name providing an alternative name for the features array in the final output (by default features is used). The option is useful in case the user wants to use a features attribute name equals to a specific term defined in a vocabulary.
      {\n \"$options\":{\n    \"encode_as_string\": true,\n    \"collection_name\":\"stations\",\n    \"@type\":\"schema:Thing\",\n    \"@context\":[\n       \"https://opengeospatial.github.io/ELFIE/contexts/elfie-2/elf-index.jsonld\",\n       \"https://opengeospatial.github.io/ELFIE/contexts/elfie-2/gwml2.jsonld\",\n       {\n          \"gsp\":\"http://www.opengis.net/ont/geosparql#\",\n          \"sf\":\"http://www.opengis.net/ont/sf#\",\n          \"schema\":\"https://schema.org/\",\n          \"st\":\"http://www.stations.org/1.0\",\n          \"wkt\":\"gsp:asWKT\",\n          \"Feature\":\"gsp:Feature\",\n          \"geometry\":\"gsp:hasGeometry\",\n          \"point\":\"sf:point\",\n          \"features\":{\n             \"@container\":\"@set\",\n             \"@id\":\"schema:hasPart\"\n          }\n       }\n    ]\n },\n \"$source\":\"st:MeteoStationsFeature\",\n \"Identifier\":\"${@id}\",\n \"Name\":\"${st:common_name}\",\n \"Code\":\"$${strConcat('STATION-', xpath('st:code'))}\",\n \"Location\":\"$${toWKT(st:position)}\",\n \"Temperatures\":[\n    {\n       \"$source\":\"st:meteoObservations/st:MeteoObservationsFeature\",\n       \"$filter\":\"xpath('st:meteoParameters/st:MeteoParametersFeature/st:param_name') = 'temperature' AND 'yes' = env('showTemperatures','yes')\"\n    },\n    {\n       \"Timestamp\":\"${st:time}\",\n       \"Value\":\"${st:value}\"\n    }\n ],\n \"Pressures\":[\n    {\n       \"$source\":\"st:meteoObservations/st:MeteoObservationsFeature\",\n       \"$filter\":\"xpath('st:meteoParameters/st:MeteoParametersFeature/st:param_name') = 'pressure' AND 'yes' = env('showPressures','yes')\"\n    },\n    {\n       \"Timestamp\":\"${st:time}\",\n       \"Value\":\"${st:value}\"\n    }\n ],\n \"Winds speed\":[\n    {\n       \"$source\":\"st:meteoObservations/st:MeteoObservationsFeature\",\n       \"$filter\":\"xpath('st:meteoParameters/st:MeteoParametersFeature/st:param_name') = 'wind speed' AND 'yes' = env('showWinds','yes')\"\n    },\n    {\n       \"Timestamp\":\"${st:time}\",\n       \"Value\":\"${st:value}\"\n    }\n ]\n}\n

      The @context will show up at the beginning of the JSON-LD output:

      {\n  \"@context\":[\n     \"https://opengeospatial.github.io/ELFIE/contexts/elfie-2/elf-index.jsonld\",\n     \"https://opengeospatial.github.io/ELFIE/contexts/elfie-2/gwml2.jsonld\",\n     {\n        \"gsp\":\"http://www.opengis.net/ont/geosparql#\",\n        \"sf\":\"http://www.opengis.net/ont/sf#\",\n        \"schema\":\"https://schema.org/\",\n        \"st\":\"http://www.stations.org/1.0\",\n        \"wkt\":\"gsp:asWKT\",\n        \"Feature\":\"gsp:Feature\",\n        \"geometry\":\"gsp:hasGeometry\",\n        \"point\":\"sf:point\",\n        \"features\":{\n           \"@container\":\"@set\",\n           \"@id\":\"schema:hasPart\"\n        }\n     }\n  ],\n  \"type\":\"FeatureCollection\",\n  \"@type\":\"schema:Thing\",\n  \"stations\":[\n     {\n        \"Identifier\":\"MeteoStationsFeature.7\",\n        \"Name\":\"Bologna\",\n        \"Code\":\"STATION-BOL\",\n        \"Location\":\"POINT (44.5 11.34)\",\n        \"Temperatures\":[\n           {\n              \"Timestamp\":\"2016-12-19T11:28:31.000+00:00\",\n              \"Value\":\"35.0\"\n           },\n           {\n              \"Timestamp\":\"2016-12-19T11:28:55.000+00:00\",\n              \"Value\":\"25.0\"\n           }\n        ],\n        \"Pressures\":[\n           {\n              \"Timestamp\":\"2016-12-19T11:30:26.000+00:00\",\n              \"Value\":\"1019.0\"\n           },\n           {\n              \"Timestamp\":\"2016-12-19T11:30:51.000+00:00\",\n              \"Value\":\"1015.0\"\n           }\n        ],\n        \"Winds speed\":[\n           {\n              \"Timestamp\":\"2016-12-19T11:29:24.000+00:00\",\n              \"Value\":\"80.0\"\n           }\n        ]\n     }\n  ]\n}\n

      The above template defines, along with the @context, also the option encode_as_string. The option is used to request a JSON-LD output where all the attributes are encoded as text. By default attributes are instead encoded as in GeoJSON output format.

      When dealing with a GetFeatureInfo request over a LayerGroup asking for a JSON-LD output the plug-in will perform a union of the JSON-LD @context (when different) defined in the template of each contained layer. This means that in case of conflicting attributes name the attributes name will override each other according to the processing order of the layers. The user can prevent this behaviour by taking advantage of the include directive, explained below, defining a single @context included in the template of each contained layer. In this way all the layer will share the same context definition.

      "},{"location":"community/features-templating/directives/#gml_2","title":"GML","text":"

      GML output has two options: Namespaces and SchemaLocation, that define the namespaces and the SchemaLocation attribute that will be included in the FeatureCollection element in the resulting output. These options needs to be specified inside a gft:Options element at the beginning of the template right after the gft:Template element, e.g.

      <gft:Template>\n <gft:Options>\n   <gft:Namespaces xmlns:st=\"http://www.stations.org/1.0\"/>\n   <gft:SchemaLocation xsi:schemaLocation=\"http://www.stations.org/1.0 http://www.stations.org/stations/1.0/xsd/stations.xsd\"/>\n </gft:Options>\n <st:MeteoStations gml:id=\"${@id}\">\n<st:code>$${strConcat('Station_',st:code)}</st:code>\n<st:name>${st:common_name}</st:name>\n<st:geometry>${st:position}</st:geometry>\n<st:temperature gft:isCollection=\"true\" gft:source=\"st:meteoObservations/st:MeteoObservationsFeature\" gft:filter=\"xpath('st:meteoParameters/st:MeteoParametersFeature/st:param_name') = 'temperature'\">\n<st:Temperature>\n  <st:time>${st:time}</st:time>\n  <st:value>${st:value}</st:value>\n</st:Temperature>\n</st:temperature>\n<st:pressure gft:isCollection=\"true\" gft:source=\"st:meteoObservations/st:MeteoObservationsFeature\"  gft:filter=\"xpath('st:meteoParameters/st:MeteoParametersFeature/st:param_name') = 'pressure'\">\n<st:Pressure>\n  <st:time>${st:time}</st:time>\n  <st:value>${st:value}</st:value>\n</st:Pressure>\n</st:pressure>\n<st:wind_speed gft:isCollection=\"true\" gft:source=\"st:meteoObservations/st:MeteoObservationsFeature\"  gft:filter=\"xpath('st:meteoParameters/st:MeteoParametersFeature/st:param_name') = 'wind speed'\">\n<st:Wind_speed>\n  <st:time>${st:time}</st:time>\n  <st:value>${st:value}</st:value>\n</st:Wind_speed>\n</st:wind_speed>\n</st:MeteoStations>\n</gft:Template>\n
      "},{"location":"community/features-templating/directives/#html","title":"HTML","text":"

      HTML templates can use several options:

      • <script> allows defining whatever javascript is needed, e.g. to create a tree view (as in the example below) or an openlayers map client.

      • code

        <script type=\"application/ld+json\"/> allows to inject the JSON-LD representation of the features being templated in the <head>. In order to have the option working properly a JSON-LD template must be configured for the layer, or GeoServer will return an error message.

      • <style> allows defining css content.

      • <link> allows linking to external resources.

      The content of <script> and <style> needs to be provided as <![CDATA[.

      The following is an example of a HTML template that will output the Stations features as a tree view. Also in this example we are using the same filter on st:meteoObservations as in the other template examples.:

      <gft:Template>\n  <gft:Options>\n     <style>\n     <![CDATA[ul, #myUL {\n     list-style-type: none;\n     }\n     #myUL {\n     margin: 0;\n     padding: 0;\n     }\n     .caret {\n     cursor: pointer;\n     -webkit-user-select: none; /* Safari 3.1+ */\n     -moz-user-select: none; /* Firefox 2+ */\n     -ms-user-select: none; /* IE 10+ */\n     user-select: none;\n     }\n     .caret::before {\n     content: \"\\25B6\";\n     color: black;\n     display: inline-block;\n     margin-right: 6px;\n     }\n     .caret-down::before {\n     -ms-transform: rotate(90deg); /* IE 9 */\n     -webkit-transform: rotate(90deg); /* Safari */'\n     transform: rotate(90deg);  \n     }\n     .nested {\n     display: none;\n     }\n     .active {\n     display: block;\n     }]]></style>\n     <script><![CDATA[window.onload = function() {\n     var toggler = document.getElementsByClassName(\"caret\");\n     for (let item of toggler){\n     item.addEventListener(\"click\", function() {\n     this.parentElement.querySelector(\".nested\").classList.toggle(\"active\");\n     this.classList.toggle(\"caret-down\");\n     });\n     }\n     }]]></script>\n     <script type=\"application/ld+json\"/>\n     </gft:Options>\n     <ul id=\"myUL\">\n      <li>\n        <span class=\"caret\">MeteoStations</span>\n        <ul class=\"nested\">\n           <li>\n              <span class=\"caret\">Code</span>\n              <ul class=\"nested\">\n                 <li>$${strConcat('Station_',st:code)}</li>\n              </ul>\n           </li>\n           <li>\n              <span class=\"caret\">Name</span>\n              <ul class=\"nested\">\n                 <li>${st:common_name}</li>\n              </ul>\n           </li>\n           <li>\n              <span class=\"caret\">Geometry</span>\n              <ul class=\"nested\">\n                 <li>${st:position}</li>\n              </ul>\n           </li>\n           <li gft:isCollection=\"true\" gft:source=\"st:meteoObservations/st:MeteoObservationsFeature\" gft:filter=\"xpath('st:meteoParameters/st:MeteoParametersFeature/st:param_name') = 'temperature'\">\n              <span class=\"caret\">Temperature</span>\n              <ul class=\"nested\">\n                 <li>\n                    <span class=\"caret\">Time</span>\n                    <ul class=\"nested\">\n                       <li>${st:time}</li>\n                    </ul>\n                 </li>\n                 <li>\n                    <span class=\"caret\">Value</span>\n                    <ul class=\"nested\">\n                       <li>${st:time}</li>\n                    </ul>\n                 </li>\n              </ul>\n           </li>\n           <li gft:isCollection=\"true\" gft:source=\"st:meteoObservations/st:MeteoObservationsFeature\" gft:filter=\"xpath('st:meteoParameters/st:MeteoParametersFeature/st:param_name') = 'pressure'\">\n              <span class=\"caret\">Pressure</span>\n              <ul class=\"nested\">\n                 <li>\n                    <span class=\"caret\">Time</span>\n                    <ul class=\"nested\">\n                       <li>${st:time}</li>\n                    </ul>\n                 </li>\n                 <li>\n                    <span class=\"caret\">Value</span>\n                    <ul class=\"nested\">\n                       <li>${st:time}</li>\n                    </ul>\n                 </li>\n              </ul>\n           </li>\n           <li gft:isCollection=\"true\" gft:source=\"st:meteoObservations/st:MeteoObservationsFeature\" gft:filter=\"xpath('st:meteoParameters/st:MeteoParametersFeature/st:param_name') = 'wind speed'\">\n              <span class=\"caret\">Wind Speed</span>\n              <ul class=\"nested\">\n                 <li>\n                    <span class=\"caret\">Time</span>\n                    <ul class=\"nested\">\n                       <li>${st:time}</li>\n                    </ul>\n                 </li>\n                 <li>\n                    <span class=\"caret\">Value</span>\n                    <ul class=\"nested\">\n                       <li>${st:time}</li>\n                    </ul>\n                 </li>\n              </ul>\n           </li>\n        </ul>\n     </li>\n  </ul>\n</gft:Template>\n

      The output of the template will be the following:

      "},{"location":"community/features-templating/directives/#including-other-templates","title":"Including other templates","text":"

      While developing a group of templates, it's possible to notice sections that repeat across different template instances. Template inclusion allows sharing the common parts, extracting them in a re-usable building block.

      Inclusion can be performed using two directives:

      • include allows including a separate template as is.
      • includeFlat allows including a separate template, stripping the top-most container.

      As for other directives the syntax varies slightly between JSON based template and XML based ones.

      The two directives need to specify a path to the template to be included. Template names can be plain, as in this example, refer to sub-directories, or be absolute. Examples of valid template references are:

      • subProperty.json
      • ./subProperty.json
      • ./blocks/aBlock.json
      • /templates/test/aBlock.json

      However it's currently not possible to climb up the directory hierarchy using relative references, so a reference like ../myParentBlock.json will be rejected.

      "},{"location":"community/features-templating/directives/#json-based-templates-geojson-json-ld","title":"JSON based templates (GeoJSON, JSON-LD)","text":"

      In this context the two directives can be defined as:

      • $include.
      • $includeFlat.

      Regarding the $includeFlat option is worth mentioning that in a JSON context:

      • If a JSON object is included, then its properties are directly included in-place, which makes sense only within another object.
      • If instead a JSON array is included, then its values are directly included in-place, which makes sense only within another array.

      The following JSON snippet shows the four possible syntax options for template inclusion:

      {\n   \"aProperty\": \"$include{subProperty.json}\", \n   \"$includeFlat\": \"propsInAnObject.json\", \n   \"anArray\" : [\n      \"$include{arrayElement.json}\", \n      \"$includeFlat{subArray.json}\" \n   ],\n  \"$includeFlat\": \"${property}\"\n}\n

      Notes:

      1) The subProperty.json template (line 2) can be both an object or an array, it will be used as the new value of aProperty 2) The propsInAnObject.json template (line 3) is required to be a JSON object, its properties will be directly included in-place where the $includeFlat directive is 3) The arrayElement.json template (line 5) can be both an object or an array, the value will be replaced directly as the new element in anArray. This allows creation of a JSON object as the array element, or the creation of a nested array. 4) The subArray.json template (line 6) must be an array itself, the container array will be stripped and its values directly integrated inside anArray.

      In case an includeFlat directive is specified and it's attribute value is a property interpolation directive, if the property name evaluates to a json it gets included flat in the final output e.g

      including json:

      {\n   \"property\":\"${property}\", \n   \"bProperty\":\"15\",\n   \"cProperty\":\"30\"\n}\n

      \\${property} value:

      {\n   \"aProperty\": \"10\", \n   \"bProperty\": \"20\"\n}\n

      result:

      {\n   \"aProperty\":\"10\", \n   \"bProperty\":\"20\",\n   \"cProperty\":\"30\"\n}\n

      The ${property} directive evaluates to a JSON that will be merged with the including one. In case the including JSON as an attribute with the name equal to one of the attributes in the included JSON, the included will override the property with the same name in the including one.

      In case an includeFlat directive is specified inside a JSON Array with a Feature property and the property evaluate to a JSON Array, the container array will be stripped and its values included directly inside the container Array:

      [\n   \"value1\",\n   \"value2\",\n   \"value3\",\n   \"$includeFlat{${property}}\"\n]\n

      \\${property} value:

      [\n   \"value4\", \n   \"value5\"\n]\n

      result:

      [\n   \"value1\",\n   \"value2\",\n   \"value3\",\n   \"value4\",\n   \"value5\"\n]\n
      "},{"location":"community/features-templating/directives/#xml-based-templates-gml","title":"XML based templates (GML)","text":"

      In an XML context the two directives needs to be defined in the following way:

      • <gft:includeFlat>path/to/included.xml</gft:includeFlat>.
      • <gsml:specification gft:source=\"gsml:specification\">$include{includedTemplate.xml}</gsml:specification>.

      In the first case the included template will replace the <gft:includeFlat> element. In the second one the included template will be placed inside the <gsml:specification> element.

      "},{"location":"community/features-templating/directives/#extending-other-templates-via-merge-json-based-templates-only","title":"Extending other templates via merge (JSON based templates only)","text":"

      Templates inclusion, described above, allows importing a block into another template, as is. The $merge directive instead allows getting an object and use it as a base, that will be overridden by the properties of the object it is merged into.

      For example, let's assume this is a base JSON template:

      {\n  \"a\": 10,\n  \"b\": \"${attribute1}\",\n  \"c\": \"${attribute2}\",\n  \"array\": [1, 2, 3]\n}\n

      and this is a template extending it:

      {\n  \"$merge\": \"base.json\",\n  \"a\": {\n    \"a1\": 1,\n    \"a2\": 2\n  },\n  \"b\": null,\n  \"d\": \"${customAttribute}\"\n}\n

      The template actually being processed would look as follows:

      {\n  \"a\": {\n    \"a1\": 1,\n    \"a2\": 2\n  },\n  \"c\": \"${attribute2}\",\n  \"array\": [1, 2, 3]\n  \"d\": \"${customAttribute}\"\n}\n

      The general rules for object merging are:

      • Overridden simple properties are replaced.
      • Properties set to null are removed.
      • Nested objects available in both trees are drilled down, being recursively merged.
      • Arrays are replaced as-is, with no merging. The eventual top level features array is the only exception to this rule.
      • While order of the keys is not important in JSON, the merge is processed so that the base property names are included first in the merged result, and the new ones included in the override are added after them.
      • If in the overalay JSON template, are present attributes with a property interpolation directive or an expression that in turn returns a JSON, the JSON attribute tree will be merged too with the corresponding one in the base JSON tree.

      The $merge directive can be used in any object, making it the root for the merge operation. This could be used as an alternative to inclusion when local customizations are needed.

      "},{"location":"community/features-templating/directives/#environment-parametrization","title":"Environment parametrization","text":"

      A template configuration can also be manipulated on the fly, replacing existing attributes, attributes' names and sources using the env parameter. To achieve this the attribute name, the attribute, or the source should be replaced by the env function in the following way $${env('nameOfTheEnvParameter','defaultValue')}. If in the request it is specified an env query parameter env='nameOfTheEnvParameter':'newValue', the default value will be replaced in the final output with the one specified in the request.

      The functionality allows also to manipulate dynamically filters and expression. For example it is possible to change Filter arguments: \"$filter\":\"xpath('gsml:name') = env('nameOfTheEnvParameter','defaultValue').

      Xpaths can be manipulated as well to be totally or partially replaced: $${xpath(env('xpath','gsml:ControlledConcept/gsml:name')} or $${xpath(strConcat('env('gsml:ControlledConcept',xpath','/gsml:name')))}.

      "},{"location":"community/features-templating/directives/#dynamic-keys","title":"Dynamic keys","text":"

      Keys in JSON output can also be fully dependent on feature attributes, for example:

      {\n   \"${attributeA}\" : \"${attributeB}\",\n   \"$${strSubstring(attributeC, 0, 3)}\": \"$${att1 * att2}\"\n}\n

      Using a key depending on feature attributes has however drawbacks: it won't be possible to use it for filtering in WFS and for queriables generation in OGC APIs, as it does not have a stable value.

      "},{"location":"community/features-templating/directives/#json-based-properties","title":"JSON based properties","text":"

      Certain databases have native support for JSON fields. For example, PostgreSQL has both a JSON and a JSONB type. The JSON templating machinery can recognize these fields and export them as JSON blocks, for direct substitution in the output.

      It is also possible to pick a JSON attribute and use the jsonPointer function to extract either a property or a whole JSON subtree from it. See the JSON Pointer RFC for more details about valid expressions.

      Here is an example of using JSON properties:

      {\n   \"assets\": \"${assets}\",\n   \"links\": [\n     \"$${jsonPointer(others, '/fullLink')}\",\n     {\n       \"href\": \"$${jsonPointer(others, '/otherLink/href')}\",\n       \"rel\": \"metadata\",\n       \"title\": \"$${jsonPointer(others, '/otherLink/title')}\",\n       \"type\": \"text/xml\"\n     }\n   ]\n}\n

      Some references:

      • Line 1 uses assets, a property that can contain a JSON tree of any shape, which will be expanded in place.
      • Line 4 inserts a full JSON object in the array. The object is a sub-tree of the others property, which is a complex JSON document with several extra properties (could be a generic containers for properties not fitting the fixed database schema).
      • Line 6 and Line 8 extract from the others property specific string values.
      "},{"location":"community/features-templating/directives/#array-based-properties-json-based-templates-only","title":"Array based properties (JSON based templates only)","text":"

      Along JSON properties, it's not rare to find support for array based attributes in modern databases. E.g. varchar[] is a attributes containing an array of strings.

      The array properties can be used as-is, and they will be expanded into a JSON array. Let's assume the keywords database column contains a list of strings, then the following template:

      {\n   \"keywords\": \"${keywords}\"\n}\n

      May expand into:

      {\n   \"keywords\": [\"features\", \"templating\"]\n}\n

      It is also possible to use an array as the source of iteration, referencing the current array item using the ${.} XPath. For example:

      {\n   \"metadata\": [\n      {\n         \"$source\": \"keywords\"\n      },\n      {\n         \"type\": \"keyword\",\n         \"value\": \"${.}\"\n      }\n   ]\n}\n

      The above may expand into:

      {\n   \"metadata\": [\n      {\n         \"type\": \"keyword\",\n         \"value\": \"features\"\n      },\n      {\n         \"type\": \"keyword\",\n         \"value\": \"templating\"\n      }\n   ]\n}\n

      In case a specific item of an array needs to be retrieved, the item function can be used, for example, the following template extracts the second item in an array (would fail if not present):

      {\n   \"second\": \"$${item(keywords, 1)}\"\n}\n

      There is currently no explicit support for array based columns in GML templates.

      "},{"location":"community/features-templating/directives/#simplified-property-access","title":"Simplified Property Access","text":"

      The features-templating plug-in provides the possibility to directly reference domain name when dealing with Complex Features and using property interpolation in a template. As an example let's use again the meteo stations use case. This is the ER diagram of the Database table involved.

      The following is a GeoJSON template that directly reference table names and column name, instead of referencing the target Xpath in the AppSchema mappings.

      {\n  \"$source\":\"meteo_stations\",\n  \"Identifier\":\"${id}\",\n  \"Name\":\"${common_name}\",\n  \"Code\":\"$${strConcat('STATION-', xpath('code'))}\",\n  \"Location\":\"$${toWKT(position)}\",\n  \"Temperatures\":[\n     {\n        \"$source\":\"meteo_observations\",\n        \"$filter\":\"propertyPath('->meteo_parameters.param_name') = 'temperature' AND 'yes' = env('showTemperatures','yes')\"\n     },\n     {\n        \"Timestamp\":\"${time}\",\n        \"Value\":\"${value}\"\n     }\n  ],\n  \"Pressures\":[\n     {\n        \"$source\":\"meteo_observations\",\n        \"$filter\":\"propertyPath('->meteo_parameters.param_name') = 'pressure' AND 'yes' = env('showPressures','yes')\"\n     },\n     {\n        \"Timestamp\":\"${time}\",\n        \"Value\":\"${value}\"\n     }\n  ],\n  \"Winds speed\":[\n     {\n        \"$source\":\"meteo_observations\",\n        \"$filter\":\"propertyPath('->meteo_parameters.param_name') = 'wind speed' AND 'yes' = env('showWinds','yes')\"\n     },\n     {\n        \"Timestamp\":\"${time}\",\n        \"Value\":\"${value}\"\n     }\n  ]\n}\n

      As it is possible to see this template has some differences comparing to the one seen above:

      • Property interpolation (${property}) and cql evaluation ($${cql}) directives are referencing the column name of the attribute that is meant to be included in the final output. The names match the ones of the columns and no namespaces prefix is being used.
      • Inside the \\$\\${cql} directive instead of using an xpath function the propertyPath function is being use. It must be used when the property references domain names inside a $${cql} directive. Paths in this case are no more separated by a / but by a . dot.
      • The $source directive references the table names.
      • When a column/property in a table/source is referenced from the context of the upper table/source, as in all the filters in the template, the table name needs to be prefixed with a -> symbol, and column name can come next separated by a . dot. Putting it in another way: the -> signals that the next path part is a table joined to the last source defined.

      Warning

      the propertyPath('propertyPath') cql function is meant to be used only in the scope of this plugin. It is not currently possible to reference domain property outside the context of a template file.

      This functionality is particularly useful when defining templates on top of Smart Data Loader based Complex Features.

      "},{"location":"community/features-templating/directives/#controlling-attributes-with-n-cardinality","title":"Controlling Attributes With N Cardinality","text":"

      When a property interpolation targets an attribute with multiple cardinality in a Complex Feature, feature templating will output the result as an array. This default behaviour can be controlled and modified with the usage of a set of CQL functions that are available in the plug-in, which allow to control how the list should be encoded in the template.

      • aggregate: takes as arguments an expression (a property name or a function) that returns a list of values and a literal with the aggregation type eg. aggregate(my.property.name,'MIN'). The supported aggregation type are the following:

        • MIN will return the minimum value from a list of numeric values.
        • MAX will return the max value from a list of numeric values.
        • AVG will return the average value from a list of numeric values.
        • UNIQUE will remove duplicates values from a list of values.
        • JOIN will concatenate the list of values in a single string. It accepts a parameter to specify the separator that by default is blank space: aggregate(my.property.name,'JOIN(,)') .
      • stream: takes an undefined number of expressions as parameters and chain them so that each expression evaluate on top of the output of the previous expression: eg. stream(aPropertyName,aFunction,anotherPropertyName) while evaluate the aFunction on the output of aPropertyName evaluation and finally anotherPropertyName will evaluate on top of the result of aFunction.

      • filter: takes a literal cql filter as a parameter and evaluates it. Every string literal value in the cql filter must be between double quotes escaped: eg. filter('aProperty = \"someValue\"').

      • sort: sort the list of values in ascending or descending order. It accepts as a parameter the sort order (ASC,DESC) and optionally a property name to target the property on which the sorting should be executed. If no property name is defined the sorting will be applied on the current node on which the function evaluates: sort('DESC',nested.property), sort('ASC').

      The above functions can be combined allowing fine grained control over the encoding of list values in a template. Assuming to write a template for the meteo stations use case, these are some example of the usage of the functions (simplified property access is used in the example below):

      • aggregate(stream(->meteo_observations,filter('value > 35')),AVG) will compute and return the average value of all the Observation nested feature value attribute.
      • aggregate(stream(->meteo_observations.->meteo_parameters,sort(\"ASC\",param_name),param_unit),JOIN(,)) will pick up the meteo_parameter nested features for each station feature, will sort them in ascending order based on the value of the param_name and will concatenate the param_unit values in a single string, comma separated.
      "},{"location":"community/features-templating/directives/#template-validation","title":"Template Validation","text":"

      There are two kind of validation available. The first one is done automatically every time a template is requested for the first time or after modifications occurred. It is done automatically by GeoServer and validates that all the property names being used in the template applies to the Feature Type. The second type of validation can be issued from the UI (see the configuration section) in case a JSON-LD or a GML output are request. The GML validation will validate the output against the provided SchemaLocation values. The JSON-LD validation is detailed below.

      "},{"location":"community/features-templating/directives/#json-ld-validation","title":"JSON-LD Validation","text":"

      The plugin provides a validation for the json-ld output against the @context defined in the template. It is possible to require it by specifying a new query parameter in the request: validation=true. The validation takes advantage form the json-ld api and performs the following steps:

      • the expansion algorithm is executed against the json-ld output, expanding each features' attribute name to IRIs, removing those with no reference in the @context and the @context itself;
      • the compaction algorithm is then executed on the expansion result, putting back the @context and shortens to the terms the expanded attribute names as in the original output;
      • finally the result of the compaction process is compared to the original json-ld and if some attributes are missing it means that they were not referenced in the @context. An exception is thrown with a message pointing to the missing attributes.
      "},{"location":"community/features-templating/installing/","title":"Installing the GeoServer FEATURES-TEMPLATING extension","text":"
      1. Download the Features Templating community module from features-templating.

        ::: warning ::: title Warning :::

        Make sure to match the version of the extension to the version of the GeoServer instance! :::

      2. Extract the contents of the archive into the WEB-INF/lib directory of the GeoServer installation.

      3. The full package requires the OGC API - Features service to be available. If the server does not include it, the jar gs-features-templating-ogcapi-<version>.jar should be removed from WEB-INF/lib

      "},{"location":"community/features-templating/querying/","title":"Backward Mapping","text":"

      When performing queries, using CQL filters, against layers that support a templated output, it will be possible to reference the template attributes in the CQL expressions. The plugin will take care of interpreting the CQL filter and translate it, when possible, to a data source native filter. For example, if that data source is a relational database, the CQL filter will be translated to one or multiple SQL queries that will be used to retrieve only the needed data.

      Consider the following GML output example:

      <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<wfs:FeatureCollection xmlns:wfs=\"http://www.opengis.net/wfs\" xmlns:gml=\"http://www.opengis.net/gml\" xmlns:st=\"http://www.stations.org/1.0\" xmlns:xlink=\"http://www.w3.org/1999/xlink\" xmlns:xs=\"http://www.w3.org/2001/XMLSchema\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" numberOfFeature=\"0\" timeStamp=\"2021-07-16T08:38:50.735Z\">\n  <gml:featureMember>\n     <st:MeteoStations gml:id=\"MeteoStationsFeature.7\">\n        <st:code>Station_BOL</st:code>\n        <st:name>Bologna</st:name>\n        <st:geometry>\n           <gml:Point srsName=\"EPSG:4326\" srsDimension=\"2\">\n              <gml:pos>11.34 44.5</gml:pos>\n           </gml:Point>\n        </st:geometry>\n        <st:temperature>\n           <st:Temperature>\n              <st:time>2016-12-19T11:28:31.000Z</st:time>\n              <st:value>35.0</st:value>\n           </st:Temperature>\n        </st:temperature>\n        <st:temperature>\n           <st:Temperature>\n              <st:time>2016-12-19T11:28:55.000Z</st:time>\n              <st:value>25.0</st:value>\n           </st:Temperature>\n        </st:temperature>\n        <st:pressure>\n           <st:Pressure>\n              <st:time>2016-12-19T11:30:26.000Z</st:time>\n              <st:value>1019.0</st:value>\n           </st:Pressure>\n        </st:pressure>\n        <st:pressure>\n           <st:Pressure>\n              <st:time>2016-12-19T11:30:51.000Z</st:time>\n              <st:value>1015.0</st:value>\n           </st:Pressure>\n        </st:pressure>\n        <st:wind_speed>\n           <st:Wind_speed>\n              <st:time>2016-12-19T11:29:24.000Z</st:time>\n              <st:value>80.0</st:value>\n           </st:Wind_speed>\n        </st:wind_speed>\n     </st:MeteoStations>\n  </gml:featureMember>\n  <gml:featureMember>\n     <st:MeteoStations gml:id=\"MeteoStationsFeature.13\">\n        <st:code>Station_ALS</st:code>\n        <st:name>Alessandria</st:name>\n        <st:geometry>\n           <gml:Point srsName=\"EPSG:4326\" srsDimension=\"2\">\n              <gml:pos>8.63 44.92</gml:pos>\n           </gml:Point>\n        </st:geometry>\n        <st:temperature>\n           <st:Temperature>\n              <st:time>2016-12-19T11:26:40.000Z</st:time>\n              <st:value>20.0</st:value>\n           </st:Temperature>\n        </st:temperature>\n        <st:wind_speed>\n           <st:Wind_speed>\n              <st:time>2016-12-19T11:27:13.000Z</st:time>\n              <st:value>155.0</st:value>\n           </st:Wind_speed>\n        </st:wind_speed>\n     </st:MeteoStations>\n  </gml:featureMember>\n  <gml:featureMember>\n     <st:MeteoStations gml:id=\"MeteoStationsFeature.21\">\n        <st:code>Station_ROV</st:code>\n        <st:name>Rovereto</st:name>\n        <st:geometry>\n           <gml:Point srsName=\"EPSG:4326\" srsDimension=\"2\">\n              <gml:pos>11.05 45.89</gml:pos>\n           </gml:Point>\n        </st:geometry>\n     </st:MeteoStations>\n  </gml:featureMember>\n</wfs:FeatureCollection>\n

      The following are valid CQL_FILTERS

      • st:name = 'Station_BOL'.
      • st:temperature.st:Temperature.st:value < 25.

      Given this underlying GML template:

      <gft:Template>\n<gft:Options>\n  <gft:Namespaces xmlns:st=\"http://www.stations.org/1.0\"/>\n</gft:Options>\n<st:MeteoStations gml:id=\"${@id}\">\n<st:code>$${strConcat('Station_',st:code)}</st:code>\n<st:name>${st:common_name}</st:name>\n<st:geometry>${st:position}</st:geometry>\n<st:temperature gft:isCollection=\"true\" gft:source=\"st:meteoObservations/st:MeteoObservationsFeature\" gft:filter=\"xpath('st:meteoParameters/st:MeteoParametersFeature/st:param_name') = 'temperature'\">\n  <st:Temperature>\n      <st:time>${st:time}</st:time>\n      <st:value>${st:value}</st:value>\n  </st:Temperature>\n</st:temperature>\n<st:pressure gft:isCollection=\"true\" gft:source=\"st:meteoObservations/st:MeteoObservationsFeature\"  gft:filter=\"xpath('st:meteoParameters/st:MeteoParametersFeature/st:param_name') = 'pressure'\">\n  <st:Pressure>\n      <st:time>${st:time}</st:time>\n      <st:value>${st:value}</st:value>\n  </st:Pressure>\n</st:pressure>\n<st:wind_speed gft:isCollection=\"true\" gft:source=\"st:meteoObservations/st:MeteoObservationsFeature\"  gft:filter=\"xpath('st:meteoParameters/st:MeteoParametersFeature/st:param_name') = 'wind speed'\">\n  <st:Wind_speed>\n      <st:time>${st:time}</st:time>\n      <st:value>${st:value}</st:value>\n  </st:Wind_speed>\n</st:wind_speed>\n</st:MeteoStations>\n</gft:Template>\n

      The above cql_filter will be internally translated to:

      • strConcat('Station_',st:code) = 'Station_BOL'.
      • st:meteoObservations/st:MeteoObservationsFeature/st:MeteoParametersFeature/st:value < 25 AND st:meteoObservations/st:MeteoObservationsFeature/st:MeteoParametersFeature/st:param_name = 'temperature'.

      As it is possible to see from the second example, if a template filter is defined for the value we want to filter by, the filter will be automatically included in the query.

      Backwards mapping capability is available for all the output formats. Consider the following JSON-LD output example:

      The following are example of valid CQL filters:

      • gsml:GeologicUnit.description = 'some string value'
      • name in (\"MERCIA MUDSTONE\", \"UKNOWN\")
      • gsml:positionalAccuracy.valueArray1 = \"100\"
      {\n  \"@context\": {\n      \"gsp\": \"http://www.opengis.net/ont/geosparql#\",\n      \"sf\": \"http://www.opengis.net/ont/sf#\",\n      \"schema\": \"https://schema.org/\",\n      \"dc\": \"http://purl.org/dc/terms/\",\n      \"Feature\": \"gsp:Feature\",\n      \"FeatureCollection\": \"schema:Collection\",\n      \"Point\": \"sf:Point\",\n      \"wkt\": \"gsp:asWKT\",\n      \"features\": {\n          \"@container\": \"@set\",\n          \"@id\": \"schema:hasPart\"\n      },\n      \"geometry\": \"sf:geometry\",\n      \"description\": \"dc:description\",\n      \"title\": \"dc:title\",\n      \"name\": \"schema:name\"\n  },\n  \"type\": \"FeatureCollection\",\n  \"features\": [\n      {\n          \"@id\": \"mf2\",\n          \"@type\": [\n              \"Feature\",\n              \"gsml:MappedFeature\",\n              \"http://vocabulary.odm2.org/samplingfeaturetype/mappedFeature\"\n          ],\n          \"name\": \"MERCIA MUDSTONE GROUP\",\n          \"gsml:positionalAccuracy\":{\n              \"value\":\"100\",\n              \"valueArray\": [\"100\",\"someStaticVal\"]\n          },\n          \"gsml:GeologicUnit\": {\n              \"@id\": \"gu.25678\",\n              \"description\": \"Olivine basalt, tuff, microgabbro, minor sedimentary rocks\",\n              \"gsml:geologicUnitType\": \"urn:ogc:def:nil:OGC::unknown\",\n              \"gsml:composition\": [\n                  {\n                      \"gsml:compositionPart\": [\n                          {\n                              \"gsml:role\": {\n                                  \"value\": \"interbedded component\",\n                                  \"@codeSpace\": \"urn:cgi:classi...\"\n                              },\n                              \"proportion\": {\n                                  \"@dataType\": \"CGI_ValueProperty\",\n                                  \"CGI_TermValue\": {\n                                      \"@dataType\": \"CGI_TermValue\",\n                                      \"value\": {\n                                          \"value\": \"significant\",\n                                          \"@codeSpace\": \"some:uri\"\n                                      }\n                                  }\n                              },\n                              \"lithology\": [\n                                  {\n                                      \"@id\": \"cc.3\",\n                                      \"name\": {\n                                          \"value\": \"name_cc_3\",\n                                          \"@lang\": \"en\"\n                                      },\n                                      \"vocabulary\": {\n                                          \"@href\": \"urn:ogc:def:nil:OGC::missing\"\n                                      }\n                                  }\n                              ]\n                          }\n                      ]\n                  },\n                  {\n                      \"gsml:compositionPart\": [\n                          {\n                              \"gsml:role\": {\n                                  \"value\": \"interbedded component\",\n                                  \"@codeSpace\": \"urn:cgi:class...\"\n                              },\n                              \"proportion\": {\n                                  \"@dataType\": \"CGI_ValueProperty\",\n                                  \"CGI_TermValue\": {\n                                      \"@dataType\": \"CGI_TermValue\",\n                                      \"value\": {\n                                          \"value\": \"minor\",\n                                          \"@codeSpace\": \"some:uri\"\n                                      }\n                                  }\n                              },\n                              \"lithology\": [\n                                  {\n                                      \"@id\": \"cc.4\",\n                                      \"name\": {\n                                          \"value\": \"name_cc_4\",\n                                          \"@lang\": \"en\"\n                                      },\n                                      \"vocabulary\": {\n                                          \"@href\": \"urn:ogc:def:nil:OGC::missing\"\n                                      }\n                                  }\n                              ]\n                          }\n                      ]\n                  }\n              ],\n              \"geometry\": {\n                  \"@type\": \"Polygon\",\n                  \"wkt\": \"POLYGON ((52.5 -1.3, 52.6 -1.3, 52.6 -1.2,...))\"\n              }\n          }\n      }\n  ]\n  }\n

      The following are example of valid CQL filters:

      • gsml:GeologicUnit.description = 'some string value'
      • name in (\"MERCIA MUDSTONE\", \"UKNOWN\")
      • gsml:positionalAccuracy.valueArray1 = \"100\"

      As the last example shows, to refer to elements in arrays listing simple attributes, the index of the attribute is needed, starting from 1, in the form {attributeName}{index}, as in features.gsml:positionalAccuracy.valueArray1.

      "},{"location":"community/features-templating/rest/","title":"Features Templatring Rest API","text":""},{"location":"community/features-templating/rest/#introduction","title":"Introduction","text":"

      The Features Templating Rest API allows performing CRUD operation over Features Templates and Template Layer Rules.

      "},{"location":"community/features-templating/rest/#template-configuration","title":"Template Configuration","text":"

      /rest/featurestemplates

      Finds all templates in the global (features-templating) directory or creates a new template in the global directory.

      +--------+-------------------------------------------------------------------------------------------------+------------------------------------+-------------------------------------------------------------------------------------------------------------------+----------------------------------------------------------------------------------------+------------------------------------+ | Method | Consumes | Produces | Action | Supported parameters | Response | +========+=================================================================================================+====================================+===================================================================================================================+========================================================================================+====================================+ | GET | | application/xml, application/json. | List of all the templates available in the features-templating directory. | | 200. List of rules in XML or JSON. | +--------+-------------------------------------------------------------------------------------------------+------------------------------------+-------------------------------------------------------------------------------------------------------------------+----------------------------------------------------------------------------------------+------------------------------------+ | POST | application/xml, text/xml, application/json, text/json, application/xhtml+xml, application/zip. | text/plain. | Add the template in the request body (text or zip file) as a new Template in the features-templating directory. | templateName (mandatory when posting a raw template, optional when posting a zip file) | 201. Created Location header. | +--------+-------------------------------------------------------------------------------------------------+------------------------------------+-------------------------------------------------------------------------------------------------------------------+----------------------------------------------------------------------------------------+------------------------------------+

      /rest/workspaces/<workspace name>/featurestemplates

      Finds all templates in the workspace directory or creates a new template in the workspace directory.

      +--------+-------------------------------------------------------------------------------------------------+------------------------------------+---------------------------------------------------------------------------------------------------------+----------------------------------------------------------------------------------------+------------------------------------+ | Method | Consumes | Produces | Action | Supported parameters | Response | +========+=================================================================================================+====================================+=========================================================================================================+========================================================================================+====================================+ | GET | | application/xml, application/json. | List of all the templates available in the workspace directory | | 200. List of rules in XML or JSON. | +--------+-------------------------------------------------------------------------------------------------+------------------------------------+---------------------------------------------------------------------------------------------------------+----------------------------------------------------------------------------------------+------------------------------------+ | POST | application/xml, text/xml, application/json, text/json, application/xhtml+xml, application/zip. | text/plain. | Add the template in the request body (text or zip file) as a new Template in the workspace directory. | templateName (mandatory when posting a raw template, optional when posting a zip file) | 201. Created Location header. | +--------+-------------------------------------------------------------------------------------------------+------------------------------------+---------------------------------------------------------------------------------------------------------+----------------------------------------------------------------------------------------+------------------------------------+

      /rest/workspaces/<workspace name>/featuretypes/<featureType name>/featurestemplates

      Finds all templates in the featuretype directory or creates a new template in the featuretype directory.

      +--------+-------------------------------------------------------------------------------------------------+------------------------------------+------------------------------------------------------------------------------------------------------------+----------------------------------------------------------------------------------------+------------------------------------+ | Method | Consumes | Produces | Action | Supported parameters | Response | +========+=================================================================================================+====================================+============================================================================================================+========================================================================================+====================================+ | GET | | application/json, application/xml. | List of all the templates available in the featuretype directory | | 200. List of rules in XML or JSON. | +--------+-------------------------------------------------------------------------------------------------+------------------------------------+------------------------------------------------------------------------------------------------------------+----------------------------------------------------------------------------------------+------------------------------------+ | POST | application/xml, text/xml, application/json, text/json, application/xhtml+xml, application/zip. | text/plain. | Add the template in the request body (text or zip file) as a new Template in the Feature Type directory. | templateName (mandatory when posting a raw template, optional when posting a zip file) | 201. Created Location header. | +--------+-------------------------------------------------------------------------------------------------+------------------------------------+------------------------------------------------------------------------------------------------------------+----------------------------------------------------------------------------------------+------------------------------------+

      /rest/featurestemplates/<template name>

      If the template with the specified name exists in the global (features-templating) directory, returns the template or replaces the template content with the one in the request body.

      +--------+-------------------------------------------------------------------------------------------------+-----------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------+--------------------+ | Method | Consumes | Produces | Action | Response | +========+=================================================================================================+===========================================================+=================================================================================================================================+====================+ | GET | | application/xml, application/json, application/xhtml+xml. | the template with the specified name if present in the features-templating directory. | 200. The template. | +--------+-------------------------------------------------------------------------------------------------+-----------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------+--------------------+ | PUT | application/xml, text/xml, application/json, text/json, application/xhtml+xml, application/zip. | text/plain. | replace the template, if found in the features-templating directory with the template in the request body (text or zip file). | 201. | +--------+-------------------------------------------------------------------------------------------------+-----------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------+--------------------+ | DELETE | | | delete the template, if found in the features-templating directory. | 204. | +--------+-------------------------------------------------------------------------------------------------+-----------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------+--------------------+

      /rest/workspaces/<workspace name>/featurestemplates/<template name>

      If the template with the specified name exists in the workspace directory, returns the template or replaces the template content with the one in the request body.

      +--------+-------------------------------------------------------------------------------------------------+-----------------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------+--------------------+ | Method | Consumes | Produces | Action | Response | +========+=================================================================================================+===========================================================+================================================================================================================================+====================+ | GET | | application/xml, application/json, application/xhtml+xml. | the template with the specified name if present in the workspace directory. | 200. The template. | +--------+-------------------------------------------------------------------------------------------------+-----------------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------+--------------------+ | PUT | application/xml, text/xml, application/json, text/json, application/xhtml+xml, application/zip. | text/plain. | replace the existing template, if found in the workspace directory with the template in the request body (text or zip file). | 201. | +--------+-------------------------------------------------------------------------------------------------+-----------------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------+--------------------+ | DELETE | | | delete the template, if found in the workspace directory. | 204. | +--------+-------------------------------------------------------------------------------------------------+-----------------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------+--------------------+

      /rest/workspaces/<workspace name>/featuretypes/<featureType name> /featurestemplates/<template name>

      If the template with the specified name exists in the featuretype directory, returns the template or replaces the template content with the one in the request body.

      +--------+-------------------------------------------------------------------------------------------------+-----------------------------------------------------------+----------------------------------------------------------------------------------------------------------------------------------+--------------------+ | Method | Consumes | Produces | Action | Response | +========+=================================================================================================+===========================================================+==================================================================================================================================+====================+ | GET | | application/xml, application/json, application/xhtml+xml. | the template with the specified name if present in the featuretype directory. | 200. The template. | +--------+-------------------------------------------------------------------------------------------------+-----------------------------------------------------------+----------------------------------------------------------------------------------------------------------------------------------+--------------------+ | PUT | application/xml, text/xml, application/json, text/json, application/xhtml+xml, application/zip. | text/plain. | replace the existing template, if found in the featuretype directory with the template in the request body (text or zip file). | 201. | +--------+-------------------------------------------------------------------------------------------------+-----------------------------------------------------------+----------------------------------------------------------------------------------------------------------------------------------+--------------------+ | DELETE | | | delete the template, if found in the featuretype directory. | 204. | +--------+-------------------------------------------------------------------------------------------------+-----------------------------------------------------------+----------------------------------------------------------------------------------------------------------------------------------+--------------------+

      "},{"location":"community/features-templating/rest/#template-rule-configuration","title":"Template Rule Configuration","text":"

      /rest/workspaces/<workspace name>/featuretypes/<featureType name>/templaterules

      Finds all the configured template rules for the featuretype or creates a new one.

      +--------+---------------------------------------------------------+------------------------------------+-----------------------------------------------------------------+------------------------------------+ | Method | Consumes | Produces | Action | Response | +========+=========================================================+====================================+=================================================================+====================================+ | GET | | application/xml, application/json. | List of all the template rules available for the featuretype. | 200. List of rules in XML or JSON. | +--------+---------------------------------------------------------+------------------------------------+-----------------------------------------------------------------+------------------------------------+ | POST | application/xml, text/xml, application/json, text/json. | text/plain. | Add the template rule in the request body. | 201. Created Location header. | +--------+---------------------------------------------------------+------------------------------------+-----------------------------------------------------------------+------------------------------------+

      /rest/workspaces/<workspace name>/featuretypes/<featureType name> /templaterules/<rule identifier>

      Finds, replaces, updates or deletes the template rule with the specified identifier.

      +--------+---------------------------------------------------------+------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------------+ | Method | Consumes | Produces | Action | Response | +========+=========================================================+====================================+=========================================================================================================================================================================================================================+====================================+ | GET | | application/xml, application/json. | The rule with the specified rule identifier. | 200. List of rules in XML or JSON. | +--------+---------------------------------------------------------+------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------------+ | PUT | application/xml, text/xml, application/json, text/json. | text/plain. | Replace the rule with the specified id with the one provided in the request body. | 201. | +--------+---------------------------------------------------------+------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------------+ | PATCH | application/xml, text/xml, application/json, text/json. | text/plain. | Allows partial updates of the rule with the specified id using the fields specified in the rule provided in the request body. It uses a JSON merge patch like strategy | 201. | +--------+---------------------------------------------------------+------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------------+ | DELETE | | | Delete the rule with the specified id. | 204. | +--------+---------------------------------------------------------+------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------------+

      "},{"location":"community/features-templating/rest/#data-object-transfer","title":"Data Object Transfer","text":"

      Both XML and JSON are supported for transfer of data objects.

      Encoding of a template rule in XML:

      <Rule>\n    <ruleId>..</ruleId>\n    <priority>..</priority>\n    <templateName>..</templateName>\n    <outputFormat>..</outputFormat>\n    <cqlFilter>..</cqlFilter>\n<profileFilter>...</profileFilter>\n</Rule>\n

      Encoding of a rule in JSON:

      {\"Rule\": {\"ruleId\":..,\"priority\":..,\"templateName\":\"..\",\"outputFormat\":\"..\",\"cqlFilter\":\"..\",\"profileFilter\":\"..\"}}\n

      When applying partial updates missing attributes/element in incoming object are left unchanged. Properties can be set to null. E.g. the following example will allow to set the profileFilter to null:

      XML:

      <Rule>\n  <profileFilter xsi:nil=\"true\"/>\n</Rule>\n

      JSON:

      {\"Rule\":{\"profileFilter\":null}}\n
      "},{"location":"community/flatgeobuf/","title":"WFS FlatGeobuf output format","text":"

      This section discusses the WFS FlatGeobuf output format.

      • Installing WFS FlatGeobuf output format
      "},{"location":"community/flatgeobuf/installing/","title":"Installing WFS FlatGeobuf output format","text":"

      To install the WFS FlatGeobuf output format extension:

      1. Download the flatgeobuf community extension from the appropriate nightly build. The file name is called geoserver-*-flatgeobuf-plugin.zip, where * matches the version number of GeoServer you are using.
      2. Extract this these files and place the JARs in WEB-INF/lib.
      3. Perform any configuration required by your servlet container, and then restart.
      "},{"location":"community/gdal/","title":"GDAL based WCS Output Format","text":"

      The gdal_translate based output format leverages the availability of the gdal_translate command to allow the generation of more output formats than GeoServer can natively produce. The basic idea is to dump to the file system a file that gdal_translate can translate, invoke it, zip and return the output of the translation.

      This extension is thus the equivalent of the OGR extension for raster data.

      "},{"location":"community/gdal/#out-of-the-box-behaviour","title":"Out of the box behaviour","text":"

      Out of the box the plugin assumes the following:

      • gdal_translate is available in the path
      • the GDAL_DATA variable is pointing to the GDAL data directory (which stores the spatial reference information for GDAL)

      In the default configuration the following formats are supported:

      • JPEG-2000 part 1 (ISO/IEC 15444-1)
      • Geospatial PDF
      • Arc/Info ASCII Grid
      • ASCII Gridded XYZ

      The list might be shorter if gdal_translate has not been built with support for the above formats (for example, the default JPEG-2000 format relies on the JasPer-based GDAL driver).

      Once installed in GeoServer, a bunch of new supported formats will be listed in the ServiceMetadata section of the WCS 2.0 GetCapabilities document, e.g. image/jp2 and application/pdf.

      "},{"location":"community/gdal/#gdal_translate-conversion-abilities","title":"gdal_translate conversion abilities","text":"

      The gdal_translate utility is usually able to convert more formats than the default setup of this output format allows for, but the exact list depends on how the utility was built from sources. To get a full list of the formats available by your ogr2ogr build just run:

      gdal_translate --long-usage\n

      and you'll get the full set of options usable by the program, along with the supported formats.

      For example, the above produces the following output using gdal 1.11.2 compiled with libgeotiff 1.4.0, libpng 1.6, libjpeg-turbo 1.3.1, libjasper 1.900.1 and libecwj2 3.3::

      Usage: gdal_translate [--help-general] [--long-usage] [-ot {Byte/Int16/UInt16/UInt32/Int32/Float32/Float64/ CInt16/CInt32/CFloat32/CFloat64}] [-strict] [-of format] [-b band] [-mask band] [-expand {gray|rgb|rgba}] [-outsize xsize[%] ysize[%]] [-unscale] [-scale[_bn] [src_min src_max [dst_min dst_max]]] [-exponent[_bn] exp_val] [-srcwin xoff yoff xsize ysize] [-projwin ulx uly lrx lry] [-epo] [-eco] [-a_srs srs_def] [-a_ullr ulx uly lrx lry] [-a_nodata value] [-gcp pixel line easting northing [elevation]] [-mo \"META-TAG=VALUE\"] [-q] [-sds] [-co \"NAME=VALUE\"]* [-stats] [-norat] src_dataset dst_dataset

      GDAL 1.11.2, released 2015/02/10

      The following format drivers are configured and support output: VRT: Virtual Raster GTiff: GeoTIFF NITF: National Imagery Transmission Format HFA: Erdas Imagine Images (.img) ELAS: ELAS AAIGrid: Arc/Info ASCII Grid DTED: DTED Elevation Raster PNG: Portable Network Graphics JPEG: JPEG JFIF MEM: In Memory Raster GIF: Graphics Interchange Format (.gif) XPM: X11 PixMap Format BMP: MS Windows Device Independent Bitmap PCIDSK: PCIDSK Database File PCRaster: PCRaster Raster File ILWIS: ILWIS Raster Map SGI: SGI Image File Format 1.0 SRTMHGT: SRTMHGT File Format Leveller: Leveller heightfield Terragen: Terragen heightfield ISIS2: USGS Astrogeology ISIS cube (Version 2) ERS: ERMapper .ers Labelled ECW: ERDAS Compressed Wavelets (SDK 3.x) JP2ECW: ERDAS JPEG2000 (SDK 3.x) FIT: FIT Image JPEG2000: JPEG-2000 part 1 (ISO/IEC 15444-1) RMF: Raster Matrix Format RST: Idrisi Raster A.1 INGR: Intergraph Raster GSAG: Golden Software ASCII Grid (.grd) GSBG: Golden Software Binary Grid (.grd) GS7BG: Golden Software 7 Binary Grid (.grd) R: R Object Data Store PNM: Portable Pixmap Format (netpbm) ENVI: ENVI .hdr Labelled EHdr: ESRI .hdr Labelled PAux: PCI .aux Labelled MFF: Vexcel MFF Raster MFF2: Vexcel MFF2 (HKV) Raster BT: VTP .bt (Binary Terrain) 1.3 Format LAN: Erdas .LAN/.GIS IDA: Image Data and Analysis LCP: FARSITE v.4 Landscape File (.lcp) GTX: NOAA Vertical Datum .GTX NTv2: NTv2 Datum Grid Shift CTable2: CTable2 Datum Grid Shift KRO: KOLOR Raw ARG: Azavea Raster Grid format USGSDEM: USGS Optional ASCII DEM (and CDED) ADRG: ARC Digitized Raster Graphics BLX: Magellan topo (.blx) Rasterlite: Rasterlite PostGISRaster: PostGIS Raster driver SAGA: SAGA GIS Binary Grid (.sdat) KMLSUPEROVERLAY: Kml Super Overlay XYZ: ASCII Gridded XYZ HF2: HF2/HFZ heightfield raster PDF: Geospatial PDF ZMap: ZMap Plus Grid

      The full list of formats that gdal_translate is able to support is available on the GDAL site. Mind that this output format can handle only outputs that are file based and that do support creation. So, for example, you won't be able to use the PostGIS Raster output (since it's database based) or the Arc/Info Binary Grid (creation not supported).

      "},{"location":"community/gdal/#customisation","title":"Customisation","text":"

      If gdal_translate is not available in the default path, the GDAL_DATA environment variable is not set, or if the output formats needs tweaking, a gdal_translate.xml configuration file can be created to customize the output format. The file should be put inside a gdal folder in the root of the GeoServer data directory.

      Note

      GeoServer will automatically detect any change to the file and reload the configuration, without a need to restart.

      The default configuration is equivalent to the following xml file:

      <ToolConfiguration>\n  <executable>gdal_translate</executable>\n  <environment>\n    <variable name=\"GDAL_DATA\" value=\"/usr/local/share/gdal\" />\n  </environment>\n  <formats>\n    <Format>\n      <toolFormat>JPEG2000</toolFormat>\n      <geoserverFormat>GDAL-JPEG2000</geoserverFormat>\n      <fileExtension>.jp2</fileExtension>\n      <singleFile>true</singleFile>\n      <mimeType>image/jp2</mimeType>\n      <type>binary</type> <!-- not really needed, it's the default -->\n  <option>-co</option>\n  <option>FORMAT=JP2</option>\n    </Format>\n    <Format>\n      <toolFormat>PDF</toolFormat>\n      <geoserverFormat>GDAL-PDF</geoserverFormat>\n      <fileExtension>.pdf</fileExtension>\n      <singleFile>true</singleFile>\n      <mimeType>application/pdf</mimeType>\n      <formatAdapters>\n         <GrayAlphaToRGBA/>\n         <PalettedToRGB/>\n      </formatAdapters>\n    </Format>\n    <Format>\n      <toolFormat>AAIGrid</toolFormat>\n      <geoserverFormat>GDAL-ArcInfoGrid</geoserverFormat>\n      <fileExtension>.asc</fileExtension>\n      <singleFile>false</singleFile>\n    </Format>\n    <Format>\n      <toolFormat>XYZ</toolFormat>\n      <geoserverFormat>GDAL-XYZ</geoserverFormat>\n      <fileExtension>.txt</fileExtension>\n      <singleFile>true</singleFile>\n      <mimeType>text/plain</mimeType>\n      <type>text</type>\n    </Format>\n  </formats>\n</ToolConfiguration>\n

      The file showcases all possible usage of the configuration elements:

      • executable can be just gdal_translate if the command is in the path, otherwise it should be the full path to the executable. For example, on a Linux box with a custom build GDAL library might be:

        <executable>/usr/local/bin/gdal_translate</executable>\n
      • environment contains a list of variable elements, which can be used to define environment variables that should be set prior to invoking gdal_translate. For example, to setup a GDAL_DATA environment variable pointing to the GDAL data directory, the configuration might be:

        <environment>\n <variable name=\"GDAL_DATA\" value=\"/usr/local/share/gdal\" />\n</environment>\n
      • Format defines a single format, which is defined by the following tags:

        • toolFormat: the name of the format to be passed to gdal_translate with the -of option (case insensitive).
        • geoserverFormat: is the name of the output format as advertised by GeoServer
        • fileExtension: is the extension of the file generated after the translation, if any (can be omitted)
        • option: can be used to add one or more options to the gdal_translate command line. As you can see by the JPEG2000 example, each item must be contained in its own option tag. You can get a full list of options by running gdal_translate --help or by visiting the GDAL website). Also, consider that each format supports specific creation options, listed in the description page for each format (for example, here is the JPEG2000 one).
        • singleFile: if true the output of the conversion is supposed to be a single file that can be streamed directly back without the need to wrap it into a zip file
        • mimeType: the mime type of the file returned when using singleFile. If not specified application/octet-stream will be used as a default.
        • formatAdapters: transformations on the coverage that might need to be applied in order to successfully encode the output. The transformations are applied only if their input conditions are met.

      The available format adapters are:

      • GrayAlphaToRGBA: expands a gray image with alpha channel to RGBA (mandatory for geospatial PDF for example)
      • PallettedToRGB: expands a paletted image RGB(A) (mandatory for geospatial PDF for example)
      "},{"location":"community/geomesa/","title":"GeoMesa data store","text":"

      GeoMesa provides a GeoTools DataStore to access SimpleFeatures stored in Apache Accumulo.

      "},{"location":"community/geopkg/","title":"GeoPackage Extension","text":"

      This plugin brings in the ability to write GeoPackage files in GeoServer using WPS. Reading GeoPackage files is part of the core functionality of GeoServer, and does not require this extension.

      For WMS and WFS GeoPackage output, see the GeoPKG Output<geopkgoutput> extension.

      GeoPackage is an SQLite based standard format that is able to hold multiple vector and raster data layers in a single file.

      The GeoServer GeoPackage extension also allows to create a completely custom made GeoPackage with multiple layers, using the GeoPackage process.

      • Installing the GeoServer GeoPackage extension
      • GeoPackage WPS Process
      "},{"location":"community/geopkg/installing/","title":"Installing the GeoServer GeoPackage extension","text":"
      1. If you haven't done already, install the WPS extension: Installing the WPS extension.

      2. Download the Geopkg extension from the nightly GeoServer community module builds.

        ::: warning ::: title Warning :::

        Make sure to match the version of the extension to the version of the GeoServer instance! :::

      3. Extract the contents of the archive into the WEB-INF/lib directory of the GeoServer installation.

      "},{"location":"community/geopkg/output/","title":"GeoPackage WPS Process","text":"

      A custom GeoPackage can be created with any number of tiles and features layers using the GeoPackage WPS Process (see Process Cookbook).

      Warning

      While the process generates a compliant GeoPackage, some abilities like generalization, style and part of the metadata export are based on unofficial extensions discussed in the Testbed 16 GeoPackage engineering report.

      The WPS process takes in one parameter: contents which is an XML schema that represents the desired output.

      General outline of a contents scheme:

      <geopackage name=\"mygeopackage\" xmlns=\"http://www.opengis.net/gpkg\">\n    <features name=\"myfeaturelayer\" identifier=\"L01\">\n        <description>describe the layer</description>\n        <srs>EPSG:4216</srs>\n        <bbox>\n            <minx>-180</minx>\n            <miny>-90</miny>\n            <maxx>180</maxx>\n            <maxy>90</maxy>\n        </bbox>\n        <!-- ... -->\n    </features>\n\n    <tiles name=\"mytileslayer\" identifier=\"L02\">\n        <description>describe the layer</description>\n        <srs>..</srs>\n        <bbox>..</bbox>\n        <!-- ... -->\n    </tiles>\n</geopackage>\n

      Each GeoPackage has a mandatory name, which will be the name of the file (with the extension .gpkg added). Each layer (features or tiles) has the following properties:

      • name (mandatory): the name of the layer in the GeoPackage;
      • identifier (optional): an identifier for the layer;
      • description (optional): a description for the layer;
      • srs ( mandatory for tiles, optional for features): coordinate reference system; for features the default is the SRS of the feature type;
      • bbox ( mandatory for tiles, optional for features): the bounding box; for features the default is the bounding box of the feature type.

      Outline of the features layer:

      <features name=\"myfeaturelayer\" identifier=\"L01\">\n    <description>..</description>\n    <srs>..</srs>\n    <bbox>..</bbox>\n    <featuretype>myfeaturetype</featuretype>\n    <propertynames>property1, property2</propertynames>\n    <filter>..</filter>\n    <indexed>true</indexed>\n    <styles>true</styles>\n    <metadata>true</metadata>\n    <overviews>...</overviews>\n    <sort xmlns:fes=\"http://www.opengis.net/fes/2.0\">\n        <fes:SortProperty>\n            <fes:ValueReference>theGeom</fes:ValueReference>\n        </fes:SortProperty>\n    </sort>\n</features>\n
      Each features layer has the following properties:
      • featuretype (mandatory): the feature type
      • propertynames (optional): list of comma-separated names of properties in feature type to be included (default is all properties)
      • filter (optional): any OGC filter that will be applied on features before output
      • indexed (optional): include spatial indexes in the output (true/false)
      • styles (optional): include styles in the output (true/false). The exported structure uses the portrayal and semantic annotation extensions, as described in Testbed 16 E/R
      • metadata (optional): embed metadata referred by the layer metadata links into the GeoPackage (true/false). The base metadata tables are filled with contents, while semantic annotations might be used to add extra information about the metadata itself.
      • overviews (optional): adds overview tables that can speed up rendering. See more at Creating generalized tables
      • sort (optional): a filter encoding fes:SortByType which allows sorting the table contents on one or more attributes. If the chosen attribute is a geometry, the table will be sorted on its GeoHash, improving access locality when using spatial indexes.

      Outline of the tiles layer:

      <tiles name=\"mytileslayer\" identifier=\"L02\">\n    <description>...</description>\n    <srs>..</srs>\n    <bbox>..</bbox>\n    <layers>layer1, layer2</styles>\n    <styles>style1, style2</styles>\n    <sld>path/to/file.sld</sld>\n    <sldBody>..</sldBody>\n    <format>mime/type</format>\n    <bgcolor>ffffff</bgcolor>\n    <transparent>true</transparent>\n    <coverage>\n        <minZoom>5</minZoom>\n        <maxZoom>50</maxZoom>\n        <minColumn>6</minColumn>\n        <maxColumn>60</maxColumn>\n        <minRow>7</minRow>\n        <maxRow>70</maxRow>\n    </coverage>\n    <gridset>\n        ...\n    </gridset>\n    <parameters>\n      <parameter name=\"...\">value</parameter>\n    <parameters>\n</tiles>\n
      Each tiles layer has the following properties:
      • layers (mandatory): comma-separated list of layers that will be included

      • styles, sld, and sldbody are mutually exclusive, having one is mandatory
        • styles: list of comma-separated styles to be used
        • sld: path to SLD style file
        • sldbody: inline SLD style file
      • format (optional): mime-type of image format of tiles (image/png or image/jpeg)

      • bgcolor (optional): background colour as a six-digit hexadecimal RGB value

      • transparent (optional): transparency (true or false)

      • coverage (optional)

      • minzoom, maxzoom, minColumn, maxColumn, minRow, maxRow (all optional): set the minimum and maximum zoom level, column, and rows

      • gridset (optional): see below

      • parameters (optional): list of other parameters that can be used in a GetMap to produce tiles (open to all GeoServer vendor parameters)

      Gridset can take on two possible (mutually exclusive) forms:

      <gridset>\n    <name>mygridset</name>\n</gridset>\n

      where the name of a known gridset is specified; or a custom gridset may be defined as follows:

      <gridset>\n    <grids>\n        <grid>\n            <zoomlevel>1</zoomlevel>\n            <tileWidth>256</tileWidth>\n            <tileHeight>256</tileHeight>\n            <matrixWidth>4</matrixWidth>\n            <matrixHeight>4</matrixHeight>\n            <pixelXSize>0.17</pixelXSize>\n            <pixelYSize>0.17</pixelYSize>\n        </grid>\n        <grid>...</grid>\n        <!-- ... -->\n    </grids>\n</gridset>\n
      "},{"location":"community/geopkg/output/#overviews","title":"Creating generalized tables","text":"

      The process can create generalized tables, as described in Testbed 16 generalized tables extension.

      Generalized tables are sidecar tables that typically contain less records than the original table, with the option to also generalize their geometry. These are created by adding a list of overview directives in a feature layer description, each one containing:

      • name (mandatory): the generalized table name
      • distance (optional): the generalization distance to create simplified geometries
      • scaleDenominator: the scale denominator at which the table starts being used, in preference to the original table, and other tables with a lower scale denominator value
      • filter (optional): an OGC filter removing features that are not meant to be rendered at the target scale denominator

      Here is an example:

      <features name=\"woodland\" identifier=\"woodland\">\n  <description>woodland</description>\n  <srs>EPSG:27700</srs>\n  <featuretype>oszoom:woodland</featuretype>\n  <indexed>true</indexed>\n  <styles>true</styles>\n  <overviews>\n    <overview>\n      <name>woodland_g1</name>\n      <scaleDenominator>80000</scaleDenominator>\n      <filter xmlns:fes=\"http://www.opengis.net/fes/2.0\">\n        <fes:Or>\n          <fes:PropertyIsEqualTo>\n            <fes:ValueReference>type</fes:ValueReference>\n            <fes:Literal>National</fes:Literal>\n          </fes:PropertyIsEqualTo>\n          <fes:PropertyIsEqualTo>\n            <fes:ValueReference>type</fes:ValueReference>\n            <fes:Literal>Regional</fes:Literal>\n          </fes:PropertyIsEqualTo>\n        </fes:Or>\n      </filter>\n    </overview>\n    <overview>\n      <name>woodland_g2</name>\n      <scaleDenominator>320000</scaleDenominator>\n      <filter xmlns:fes=\"http://www.opengis.net/fes/2.0\">\n        <fes:PropertyIsEqualTo>\n          <fes:ValueReference>type</fes:ValueReference>\n          <fes:Literal>National</fes:Literal>\n        </fes:PropertyIsEqualTo>\n      </filter>\n    </overview>\n  </overviews>\n</features>\n
      "},{"location":"community/geostyler/","title":"GeoStyler","text":"

      Note: This plugin is maintained and hosted externally on GitHub.

      It creates an extra tab in the style editor with a graphical style editor.

      The GeoStyler is a set of JavaScript packages that can be used to edit and convert various style formats.

      When editing a style in the GeoStyler the SLD code editor is automatically refreshed and vice versa, so you can just edit the style and then apply/save it as usual.

      If you run into trouble using the GeoStyler module or have some suggestions feel free to open an issue in the GeoStyler repository.

      "},{"location":"community/graticules/","title":"Graticule Extension","text":"

      This module allows GeoServer to add graticules or grids to a WMS (or to allow them to be downloaded as WFS). The extension includes a vector process that can transform the grid lines to label points based on a bounding box, to allow adding labels in WMS images (this reqiures the WPS module to be present).

      "},{"location":"community/graticules/#installing-the-graticule-extension","title":"Installing the graticule extension","text":"
      1. Download the graticule extension from the nightly GeoServer community module builds.

        ::: warning ::: title Warning :::

        Make sure to match the version of the extension to the version of the GeoServer instance! :::

      2. Extract the contents of the archive into the WEB-INF/lib directory of the GeoServer installation.

      "},{"location":"community/graticules/#checking-if-the-extension-is-enabled","title":"Checking if the extension is enabled","text":"

      Once the extension is installed, the new graticule store should show up in the New data source page:

      "},{"location":"community/graticules/#creating-a-graticule-data-source","title":"Creating a Graticule Data Source","text":"

      A new graticule store is created by providing a name, optional description and the a bounding box (which can be calculated automatically from the CRS), a Coordinate Reference System and a series of steps separated by commas.

      The bounding box will set the limits of the grid when the user has zoomed out to small scales, while the CRS will be used to determine the values of the grid lines. The list of steps will be used to provide a more detailed grid as the user zooms in to larger scale maps. Each step is used to define a level of grid with a gap of step units between the gaps.

      "},{"location":"community/graticules/#creating-a-new-style-for-graticule","title":"Creating a new style for graticule","text":"

      Displaying a graticule in a sensible way will require creating a custom style to control the line appearance, the labels, and the visualization hierarchy if multiple levels of graticule are used. This can lead to complex styles, which can be tamed by leveraging the available attributes along with filter functions.

      Let's assume one has a graticule with 5 levels of lines at different resolutions (e.g., 1, 5, 10, 20 and 30 degrees spacing), and wants to display them as follows:

      • level 0: scale denominator lower than 1M
      • level 1: scale denominator between 1M and 20M
      • level 2: scale denominator between 20M and 100M
      • level 3: scale denominator between 10M and 400M
      • level 4: scale denominator higher than 400M

      The following style would be used, using a single Rule, by leveraging the Categorize function along with the wms_scale_denominator environment variable (Variable substitution in SLD):

      <?xml version=\"1.0\" encoding=\"ISO-8859-1\"?>\n<StyledLayerDescriptor version=\"1.0.0\"\n                       xsi:schemaLocation=\"http://www.opengis.net/sld http://schemas.opengis.net/sld/1.0.0/StyledLayerDescriptor.xsd\"\n                       xmlns=\"http://www.opengis.net/sld\" xmlns:ogc=\"http://www.opengis.net/ogc\"\n                       xmlns:xlink=\"http://www.w3.org/1999/xlink\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\">\n\n  <NamedLayer>\n    <Name>graticule</Name>\n    <UserStyle>\n      <FeatureTypeStyle>\n        <Name>name</Name>\n        <Rule>\n          <ogc:Filter>\n            <ogc:PropertyIsEqualTo>\n              <ogc:PropertyName>level</ogc:PropertyName>\n              <ogc:Function name=\"Categorize\">\n                <ogc:Function name=\"env\"><ogc:Literal>wms_scale_denominator</ogc:Literal></ogc:Function>\n                <ogc:Literal>0</ogc:Literal>\n                <ogc:Literal>1000000</ogc:Literal>\n                <ogc:Literal>1</ogc:Literal>\n                <ogc:Literal>20000000</ogc:Literal>\n                <ogc:Literal>2</ogc:Literal>\n                <ogc:Literal>100000000</ogc:Literal>\n                <ogc:Literal>3</ogc:Literal>\n                <ogc:Literal>400000000</ogc:Literal>\n                <ogc:Literal>4</ogc:Literal>\n              </ogc:Function>\n            </ogc:PropertyIsEqualTo>\n          </ogc:Filter>\n          <LineSymbolizer>\n            <Stroke>\n              <CssParameter name=\"stroke\">#666666</CssParameter>\n              <CssParameter name=\"stroke-dasharray\">2.0 2.0</CssParameter>\n            </Stroke>\n          </LineSymbolizer>\n        </Rule>        \n      </FeatureTypeStyle>\n\n    </UserStyle>\n  </NamedLayer>\n</StyledLayerDescriptor>\n

      If some important lines are meant to be displayed with solid line rather than dashed, it's possible to use a function to keep the style compact, rather than duplicating the whole rule. The following example makes the equator and the prime meridian solid lines, while keeping the rest dashed:

      <LineSymbolizer>\n  <Stroke>\n    <CssParameter name=\"stroke\">#666666</CssParameter>\n    <CssParameter name=\"stroke-dasharray\">\n      <ogc:Function name=\"if_then_else\">\n        <ogc:Function name=\"equalTo\">\n          <ogc:PropertyName>value</ogc:PropertyName>\n          <ogc:Literal>0</ogc:Literal>\n        </ogc:Function>  \n        <ogc:Literal>0</ogc:Literal>\n        <ogc:Literal>3 3</ogc:Literal>\n      </ogc:Function>\n    </CssParameter>\n  </Stroke>\n</LineSymbolizer>\n

      Finally, labelling can be a tricky job. A rendering transform is provided to help with this, vec:GraticuleLabelPoint, which will take the grid lines and return a point at ends of each gridline, preserving the attributes of the original line, but adding extra ones that can be used to simplify the labelling process:

      • \"top\" indicates if a label is at the top of the line (true) or at the bottom (false) of a vertical line
      • \"left\" indicates if a label is at the left of the line (true) or at the right (false) of a horizontal line
      • \"anchorX\", \"anchorY\" provides a suitable value to anchor the label inside the grid
      • \"offsetX\" and \"offsetY\" provides a suitable value to offset the label from the anchor point, again to keep labels inside the grid

      The process itself takes the following parameters:

      • \"grid\" is the grid lines being processed (the graticule layer).
      • \"boundingBox\" is the bounding box of the map being rendered, which is used to clip lines and to calculate the label points. This parameter is optional, if missing the labels will be generated at the end of the graticule lines no matter what the display area is. For un-tiled maps, the usage of \"boundingBox\" helps having the labels as a reference in every map, while for tiled maps it's better to omit it, or the labels will be repeated at the border of every (meta)tile.
      • \"offset\" is the offset of the label from the grid line (used to compute the values of \"offsetX\" and \"offsetY\"), which can be provided using the current request bounding box using the wms_bbox environment variable (Variable substitution in SLD).
      • \"positions\" indicates which groups of labels should be generated, and can be one of \"top\", \"bottom\", \"left\", \"right\" or \"topleft\", \"topright\", \"bottomleft\", \"bottomright\", or the default value \"both\" which generates labels on all four sides of the map.

      Leveraging this process, the labels can be generated using the following style:

      <FeatureTypeStyle>\n  <Name>label</Name>\n  <Transformation>\n    <ogc:Function name=\"vec:GraticuleLabelPoint\">\n      <ogc:Function name=\"parameter\">\n        <ogc:Literal>grid</ogc:Literal>\n      </ogc:Function>\n      <ogc:Function name=\"parameter\">\n        <ogc:Literal>boundingBox</ogc:Literal>\n        <ogc:Function name=\"env\">\n          <ogc:Literal>wms_bbox</ogc:Literal>\n        </ogc:Function>\n      </ogc:Function>\n      <ogc:Function name=\"parameter\">\n        <ogc:Literal>offset</ogc:Literal>\n        <ogc:Literal>4</ogc:Literal>\n      </ogc:Function>\n    </ogc:Function>\n  </Transformation>\n  <Rule>\n    <TextSymbolizer>\n      <Label>\n        <ogc:PropertyName>label</ogc:PropertyName>\n      </Label>\n      <Font>\n        <CssParameter name=\"font-family\">Noto Sans</CssParameter>\n        <CssParameter name=\"font-size\">12</CssParameter>\n        <CssParameter name=\"font-style\">normal</CssParameter>\n      </Font>\n      <LabelPlacement>\n        <PointPlacement>\n          <AnchorPoint>\n            <AnchorPointX><ogc:PropertyName>anchorX</ogc:PropertyName></AnchorPointX>\n            <AnchorPointY><ogc:PropertyName>anchorY</ogc:PropertyName></AnchorPointY>\n          </AnchorPoint>\n          <Displacement>\n            <DisplacementX><ogc:PropertyName>offsetX</ogc:PropertyName></DisplacementX>\n            <DisplacementY><ogc:PropertyName>offsetY</ogc:PropertyName></DisplacementY>\n          </Displacement>\n        </PointPlacement>\n      </LabelPlacement>\n      <Halo>\n        <Radius>1</Radius>\n        <Fill>\n          <CssParameter name=\"fill\">#FFFFFF</CssParameter>\n        </Fill>\n      </Halo>\n      <Fill>\n        <CssParameter name=\"fill\">#000000</CssParameter>\n      </Fill>\n      <VendorOption name=\"partials\">true</VendorOption>\n    </TextSymbolizer>\n  </Rule>      \n</FeatureTypeStyle>\n
      "},{"location":"community/gsr/","title":"GSR Extension","text":"

      This plugin provides a GeoService REST compatibility API. Please reference http://geoservices.github.io/ for authoritative information on the GeoServices API. This document describes only the GeoServer extension.

      • Installing the GeoServer GSR extension
      • GSR Usage
      • Functionality
      • Examples
      "},{"location":"community/gsr/dynamicMapLayer/","title":"Dynamic Map Layer Examples","text":""},{"location":"community/gsr/dynamicMapLayer/#dynamic-map-layer","title":"Dynamic Map Layer","text":"
      <html>\n<head>\n    <meta charset=\"utf-8\">\n    <meta name=\"viewport\" content=\"initial-scale=1,maximum-scale=1,user-scalable=no\">\n    <title>MapImageLayer - create dynamic map layers - 4.5</title>\n\n    <link rel=\"stylesheet\" href=\"https://js.arcgis.com/4.5/esri/css/main.css\">\n    <script src=\"https://js.arcgis.com/4.5/\"></script>\n\n    <style>\n        html,\n        body,\n        #viewDiv {\n            padding: 0;\n            margin: 0;\n            height: 100%;\n            width: 100%;\n        }\n\n        #info-div {\n            background-color: white;\n            border-radius: 8px;\n            padding: 8px;\n            opacity: 0.92;\n        }\n    </style>\n\n    <script>\n        require([\"esri/config\"], function (esriConfig) {\n            esriConfig.request.corsEnabledServers.push(\"localhost:8080\");\n        });\n        require([\n            \"esri/Map\",\n            \"esri/views/MapView\",\n            \"esri/layers/MapImageLayer\",\n            \"esri/widgets/Legend\",\n            \"dojo/domReady!\"\n        ], function (Map, MapView, MapImageLayer, Legend) {\n\n            var layer = new MapImageLayer({\n                url: \"http://localhost:8080/geoserver/gsr/services/topp/MapServer/3\",\n                title: \"Topp\"\n            });\n\n            /*****************************************************************\n             * Add the layer to a map\n             *****************************************************************/\n\n            var map = new Map({\n                layers: [layer]\n            });\n\n            var view = new MapView({\n                container: \"viewDiv\",\n                map: map,\n                extent: { // autocasts as new Extent()\n                    xmin: 143.83482400000003,\n                    ymin: -43.648056,\n                    xmax: 148.47914100000003,\n                    ymax: -39.573891,\n                    spatialReference: 4326\n                }\n            });\n        });\n    </script>\n\n</head>\n\n<body>\n<div id=\"viewDiv\"></div>\n<div id=\"info-div\">\n</div>\n</body>\n\n</html>\n\n<!-- Esri\u00ae, ArcGIS\u00ae and ArcGIS Online\u00ae  are trademarks, registered trademarks, or service marks of Esri in the United States, the European Community, or certain other jurisdictions. Other companies and products mentioned may be trademarks of their respective owners.-->\n
      "},{"location":"community/gsr/dynamicMapLayer/#dynamic-map-layer-wholeservice","title":"Dynamic Map Layer Wholeservice","text":"
      <html>\n<head>\n    <meta charset=\"utf-8\">\n    <meta name=\"viewport\" content=\"initial-scale=1,maximum-scale=1,user-scalable=no\">\n    <title>MapImageLayer - create dynamic map layers - 4.5</title>\n\n    <link rel=\"stylesheet\" href=\"https://js.arcgis.com/4.5/esri/css/main.css\">\n    <script src=\"https://js.arcgis.com/4.5/\"></script>\n\n    <style>\n        html,\n        body,\n        #viewDiv {\n            padding: 0;\n            margin: 0;\n            height: 100%;\n            width: 100%;\n        }\n\n        #info-div {\n            background-color: white;\n            border-radius: 8px;\n            padding: 8px;\n            opacity: 0.92;\n        }\n    </style>\n\n    <script>\n        require([\"esri/config\"], function (esriConfig) {\n            esriConfig.request.corsEnabledServers.push(\"localhost:8080\");\n        });\n        require([\n            \"esri/Map\",\n            \"esri/views/MapView\",\n            \"esri/layers/MapImageLayer\",\n            \"esri/widgets/Legend\",\n            \"dojo/domReady!\"\n        ], function (Map, MapView, MapImageLayer, Legend) {\n\n            var layer = new MapImageLayer({\n                url: \"http://localhost:8080/geoserver/gsr/services/tiger/MapServer\",\n                title: \"Census Demographics\"\n            });\n\n            /*****************************************************************\n             * Add the layer to a map\n             *****************************************************************/\n\n            var map = new Map({\n                layers: [layer]\n            });\n\n            var view = new MapView({\n                container: \"viewDiv\",\n                map: map,\n                extent: { // autocasts as new Extent()\n                    xmin: -74.0118315772888,\n                    ymin: 40.70754683896324,\n                    xmax: -74.00153046439813,\n                    ymax: 40.719885123828675,\n                    spatialReference: 4326\n                }\n            });\n        });\n    </script>\n\n</head>\n\n<body>\n<div id=\"viewDiv\"></div>\n<div id=\"info-div\">\n    Select a demographic variable<br><br>\n    <select id=\"layer-select\">\n        <option value=\"0\">Population density</option>\n        <option value=\"1\" selected>Renter occupied units</option>\n        <option value=\"2\">Median age</option>\n    </select>\n</div>\n</body>\n\n</html>\n\n<!-- Esri\u00ae, ArcGIS\u00ae and ArcGIS Online\u00ae  are trademarks, registered trademarks, or service marks of Esri in the United States, the European Community, or certain other jurisdictions. Other companies and products mentioned may be trademarks of their respective owners.-->\n
      "},{"location":"community/gsr/examples/","title":"Examples","text":"

      Follows a list of examples using the official JS client.

      • Feature Layer Examples
      • Dynamic Map Layer Examples
      • Feature Table Example
      "},{"location":"community/gsr/featureLayer/","title":"Feature Layer Examples","text":""},{"location":"community/gsr/featureLayer/#fema-example","title":"Fema example","text":"
      <html>\n<head>\n    <meta charset=\"utf-8\">\n    <meta name=\"viewport\" content=\"initial-scale=1,maximum-scale=1,user-scalable=no\">\n    <title>FeatureLayer - 4.5</title>\n\n    <link rel=\"stylesheet\" href=\"https://js.arcgis.com/4.11/esri/css/main.css\">\n    <script src=\"https://js.arcgis.com/4.11/\"></script>\n\n    <style>\n        html,\n        body,\n        #viewDiv {\n            padding: 0;\n            margin: 0;\n            height: 100%;\n            width: 100%;\n        }\n    </style>\n\n    <script>\n        require([\n                \"esri/Map\",\n                \"esri/views/MapView\",\n                \"esri/layers/FeatureLayer\",\n                \"dojo/domReady!layers-featurelayer\"\n            ],\n            function (Map, MapView,\n                      FeatureLayer) {\n\n                var map = new Map({});\n\n                var view = new MapView({\n                    container: \"viewDiv\",\n                    map: map,\n                    extent: { // autocasts as new Extent()\n                        xmin: -107.97,\n                        ymin: 25.46,\n                        xmax: -91.28,\n                        ymax: 37.74,\n                        spatialReference: 4326\n                    }\n                });\n\n                /********************\n                 * Add feature layer\n                 ********************/\n                var featureLayer2 = new FeatureLayer({\n                    url: \"http://localhost:8080/geoserver/gsr/services/cite/FeatureServer/0\",\n                    outFields: [\"*\"]\n                });\n\n                map.add(featureLayer2);\n\n            });\n\n        require([\"esri/config\"], function (esriConfig) {\n            esriConfig.request.corsEnabledServers.push(\"localhost:8080\");\n        });\n    </script>\n</head>\n\n<body>\n<div id=\"viewDiv\"></div>\n</body>\n\n</html>\n\n<!-- Esri\u00ae, ArcGIS\u00ae and ArcGIS Online\u00ae  are trademarks, registered trademarks, or service marks of Esri in the United States, the European Community, or certain other jurisdictions. Other companies and products mentioned may be trademarks of their respective owners.-->\n
      "},{"location":"community/gsr/featureLayer/#point-example","title":"Point example","text":"
      <html>\n<head>\n    <meta charset=\"utf-8\">\n    <meta name=\"viewport\" content=\"initial-scale=1,maximum-scale=1,user-scalable=no\">\n    <title>FeatureLayer - 4.5</title>\n\n    <link rel=\"stylesheet\" href=\"https://js.arcgis.com/4.5/esri/css/main.css\">\n    <script src=\"https://js.arcgis.com/4.5/\"></script>\n\n    <style>\n        html,\n        body,\n        #viewDiv {\n            padding: 0;\n            margin: 0;\n            height: 100%;\n            width: 100%;\n        }\n    </style>\n\n    <script>\n        require([\n                \"esri/Map\",\n                \"esri/views/MapView\",\n                \"esri/layers/FeatureLayer\",\n                \"dojo/domReady!layers-featurelayer\"\n            ],\n            function (Map, MapView,\n                      FeatureLayer) {\n\n                var map = new Map({});\n\n                var view = new MapView({\n                    container: \"viewDiv\",\n                    map: map,\n\n                    extent: { // autocasts as new Extent()\n                        xmin: -103.8725637911543,\n                        ymin: 44.37740330855979,\n                        xmax: -103.63794182141925,\n                        ymax: 44.48804280772808,\n                        spatialReference: 4326\n                    }\n                });\n\n                /********************\n                 * Add feature layer\n                 ********************/\n\n                    // Carbon storage of trees in Warren Wilson College.\n                var featureLayer = new FeatureLayer({\n                        url: \"http://localhost:8080/geoserver/gsr/services/sf/FeatureServer/0\"\n                    });\n\n                map.add(featureLayer);\n\n            });\n\n        require([\"esri/config\"], function (esriConfig) {\n            esriConfig.request.corsEnabledServers.push(\"localhost:8080\");\n        });\n    </script>\n</head>\n\n<body>\n<div id=\"viewDiv\"></div>\n</body>\n\n</html>\n\n<!-- Esri\u00ae, ArcGIS\u00ae and ArcGIS Online\u00ae  are trademarks, registered trademarks, or service marks of Esri in the United States, the European Community, or certain other jurisdictions. Other companies and products mentioned may be trademarks of their respective owners.-->\n
      "},{"location":"community/gsr/featureLayer/#polygon-example","title":"Polygon example","text":"
      <html>\n<head>\n    <meta charset=\"utf-8\">\n    <meta name=\"viewport\" content=\"initial-scale=1,maximum-scale=1,user-scalable=no\">\n    <title>FeatureLayer - 4.5</title>\n\n    <link rel=\"stylesheet\" href=\"https://js.arcgis.com/4.5/esri/css/main.css\">\n    <script src=\"https://js.arcgis.com/4.5/\"></script>\n\n    <style>\n        html,\n        body,\n        #viewDiv {\n            padding: 0;\n            margin: 0;\n            height: 100%;\n            width: 100%;\n        }\n    </style>\n\n    <script>\n        require([\n                \"esri/Map\",\n                \"esri/views/MapView\",\n                \"esri/layers/FeatureLayer\",\n                \"dojo/domReady!layers-featurelayer\"\n            ],\n            function (Map, MapView,\n                      FeatureLayer) {\n\n                var map = new Map({});\n\n                var view = new MapView({\n                    container: \"viewDiv\",\n                    map: map,\n                    extent: { // autocasts as new Extent()\n                        xmin: -74.255591362951,\n                        ymin: 40.4961153956091,\n                        xmax: -73.7000090634675,\n                        ymax: 40.915532775817,\n                        spatialReference: 4326\n                    }\n                });\n\n                /********************\n                 * Add feature layer\n                 ********************/\n                var featureLayer2 = new FeatureLayer({\n                    url: \"http://localhost:8080/geoserver/gsr/services/cite/FeatureServer/0\",\n                    outFields: [\"*\"]\n                });\n\n                map.add(featureLayer2);\n\n            });\n\n        require([\"esri/config\"], function (esriConfig) {\n            esriConfig.request.corsEnabledServers.push(\"localhost:8080\");\n        });\n    </script>\n</head>\n\n<body>\n<div id=\"viewDiv\"></div>\n</body>\n\n</html>\n\n<!-- Esri\u00ae, ArcGIS\u00ae and ArcGIS Online\u00ae  are trademarks, registered trademarks, or service marks of Esri in the United States, the European Community, or certain other jurisdictions. Other companies and products mentioned may be trademarks of their respective owners.-->\n
      "},{"location":"community/gsr/featureLayer/#polygon-non-cors-example","title":"Polygon non cors example","text":"
      <html>\n<head>\n    <meta charset=\"utf-8\">\n    <meta name=\"viewport\" content=\"initial-scale=1,maximum-scale=1,user-scalable=no\">\n    <title>FeatureLayer - 4.5</title>\n\n    <link rel=\"stylesheet\" href=\"https://js.arcgis.com/4.5/esri/css/main.css\">\n    <script src=\"https://js.arcgis.com/4.5/\"></script>\n\n    <style>\n        html,\n        body,\n        #viewDiv {\n            padding: 0;\n            margin: 0;\n            height: 100%;\n            width: 100%;\n        }\n    </style>\n\n    <script>\n        require([\n                \"esri/Map\",\n                \"esri/views/MapView\",\n                \"esri/layers/FeatureLayer\",\n                \"dojo/domReady!layers-featurelayer\"\n            ],\n            function (Map, MapView,\n                      FeatureLayer) {\n\n                var map = new Map({});\n\n                var view = new MapView({\n                    container: \"viewDiv\",\n                    map: map,\n                    extent: { // autocasts as new Extent()\n                        xmin: -74.255591362951,\n                        ymin: 40.4961153956091,\n                        xmax: -73.7000090634675,\n                        ymax: 40.915532775817,\n                        spatialReference: 4326\n                    }\n                });\n\n                /********************\n                 * Add feature layer\n                 ********************/\n\n                var featureLayer2 = new FeatureLayer({\n                    url: \"http://localhost:9191/geoserver/gsr/services/cite/FeatureServer/0\",\n                    outFields: [\"*\"]\n                });\n\n                map.add(featureLayer2);\n\n            });\n    </script>\n</head>\n\n<body>\n<div id=\"viewDiv\"></div>\n</body>\n\n</html>\n\n<!-- Esri\u00ae, ArcGIS\u00ae and ArcGIS Online\u00ae  are trademarks, registered trademarks, or service marks of Esri in the United States, the European Community, or certain other jurisdictions. Other companies and products mentioned may be trademarks of their respective owners.-->\n
      "},{"location":"community/gsr/featureTable/","title":"Feature Table Example","text":"
      <html>\n<head>\n  <meta charset=\"utf-8\">\n  <meta name=\"viewport\" content=\"initial-scale=1,maximum-scale=1,user-scalable=no\">\n  <title>Intro to PopupTemplate - 4.8</title>\n\n  <style>\n    html,\n    body,\n    #viewDiv {\n      padding: 0;\n      margin: 0;\n      height: 100%;\n      width: 100%;\n    }\n  </style>\n\n  <link rel=\"stylesheet\" href=\"https://js.arcgis.com/4.8/esri/css/main.css\">\n  <script src=\"https://js.arcgis.com/4.8/\"></script>\n\n  <script>\n    require([\n      \"esri/Map\",\n      \"esri/layers/FeatureLayer\",\n      \"esri/views/MapView\",\n      \"dojo/domReady!\"\n    ], function(\n      Map,\n      FeatureLayer,\n      MapView\n    ) {\n\n      // Create the map\n      var map = new Map({\n        basemap: \"osm\"\n      });\n\n      // Create the MapView\n      var view = new MapView({\n        container: \"viewDiv\",\n        map: map,\n        extent: { // autocasts as new Extent()\n            xmin: -74.255591362951,\n            ymin: 40.4961153956091,\n            xmax: -73.7000090634675,\n            ymax: 40.915532775817,\n            spatialReference: 4326\n        },\n      });\n\n      /*************************************************************\n       * The PopupTemplate content is the text that appears inside the\n       * popup. {fieldName} can be used to reference the value of an\n       * attribute of the selected feature. HTML elements can be used\n       * to provide structure and styles within the content. The\n       * fieldInfos property is an array of objects (each object representing\n       * a field) that is use to format number fields and customize field\n       * aliases in the popup and legend.\n       **************************************************************/\n\n      var template = { // autocasts as new PopupTemplate()\n        title: \"Boroughs in NY\",\n        content: [{\n          // It is also possible to set the fieldInfos outside of the content\n          // directly in the popupTemplate. If no fieldInfos is specifically set\n          // in the content, it defaults to whatever may be set within the popupTemplate.\n          type: \"fields\",\n          fieldInfos: [{\n            fieldName: \"boro_name\",\n            label: \"Borough Name\",\n            visible: true\n          }, {\n            fieldName: \"shape_area\",\n            label: \"Borough Area\",\n            visible: true,\n            format: {\n              digitSeparator: true,\n              places: 0\n            }\n          }, {\n            fieldName: \"shape_leng\",\n            label: \"Borough Length\",\n            visible: true,\n            format: {\n              digitSeparator: true,\n              places: 0\n            }\n          }]\n        }]\n      };\n\n      // Reference the popupTemplate instance in the\n      // popupTemplate property of FeatureLayer\n      var featureLayer = new FeatureLayer({\n        url: \"http://localhost:8080/geoserver/gsr/services/cite/FeatureServer/0\",\n        outFields: [\"*\"],\n        popupTemplate: template\n      });\n      map.add(featureLayer);\n    });\n    require([\"esri/config\"], function (esriConfig) {\n            esriConfig.request.corsEnabledServers.push(\"localhost:8080\");\n        });\n  </script>\n</head>\n\n<body>\n  <div id=\"viewDiv\"></div>\n</body>\n\n</html>\n\n<!-- Esri\u00ae, ArcGIS\u00ae and ArcGIS Online\u00ae  are trademarks, registered trademarks, or service marks of Esri in the United States, the European Community, or certain other jurisdictions. Other companies and products mentioned may be trademarks of their respective owners.-->\n
      "},{"location":"community/gsr/functionality/","title":"Functionality","text":""},{"location":"community/gsr/functionality/#formats","title":"Formats","text":"

      While the ArcGIS\u00ae implementation of GeoServices supports multiple file formats, all responses from the GeoServer plugin use JSON (for example, browser-friendly HTML is not provided). The ?f=json parameter specifying JSON is still required. Moreover, since at the moment there is no support for pjson output format, if client specifies a f=pjson parameter a normal JSON will be returned.

      Note

      Esri\u00ae, ArcGIS\u00ae and ArcGIS Online\u00ae are trademarks, registered trademarks, or service marks of Esri in the United States, the European Community, or certain other jurisdictions. Other companies and products mentioned may be trademarks of their respective owners.

      "},{"location":"community/gsr/functionality/#capabilities","title":"Capabilities","text":"
      • Catalog: yes
      • Map:
        • All layers and tables. Supported.
        • Attachment. Not supported.
        • Attachment info. Not supported.
        • Dynamic Layer/Table. Not supported.
        • Estimate export tile size. Not supported.
        • Export map. Not supported.
        • Export tiles. Not supported.
        • Service extension. Not supported.
        • Feature (dynamic layer). Not supported.
        • Feature (layer). Not supported.
        • Find. Not supported.
        • Generate KML. Not supported.
        • Generate renderer (Dynamic layer). Not supported.
        • Generate renderer (Layer). Not supported.
        • HTML Popup (Dynamic layer). Not supported.
        • HTML Popup (Layer). Not supported.
        • Identify. Not supported.
        • Image. Not supported.
        • KML Image. Not supported.
        • Layer/Table. Supported.
        • Legend. Supported.
        • Map tile. Not supported.
        • Map service input. Not supported.
        • Map service job. Not supported.
        • Map service result. Not supported.
        • Non-geospatial filters. Not supported
        • Requests to feature layers in non-native spatial reference systems. Not supported.
        • Query (Dynamic layer.) Not supported.
        • Query (Layer.) Supported.
        • Query related records (Dynamic layer.) Not supported.
        • Query related records (Layer.) Not supported.
        • WMTS. Not supported. (GeoServer does support this, but via GeoWebCache integration rather than the GeoServices extension.)
        • WMTS Capabilities. Not supported. (GeoServer does support this, but via GeoWebCache integration rather than the GeoServices extension.)
        • WMTS Tile. Not supported. (GeoServer does support this, but via GeoWebCache integration rather than the GeoServices extension.)
      "},{"location":"community/gsr/functionality/#technical-limitations","title":"Technical Limitations","text":""},{"location":"community/gsr/functionality/#features","title":"Features","text":"

      While GeoServer supports fields of arbitrary type (determined by the data store) the GeoServices REST API constrains field types to a short list of types.

      The GeoServer plugin maintains a mapping between these types and native Java classes in the FieldTypeEnum class. Fields whose types are not translatable will be omitted from responses.

      "},{"location":"community/gsr/functionality/#layer","title":"Layer","text":"

      GeoServer does not model layers the same way that they are presented in the GeoServices REST API. GeoServer layers may have multiple associated styles, while GeoServices allows for one style per layer. The GeoServer plugin uses the \"default\" style for the layer and ignores any alternative styles. GeoServer also has no concept corresponding to the \"sublayers\" supported by GeoServices.

      "},{"location":"community/gsr/functionality/#styles","title":"Styles","text":"

      GeoServer does not model styles the same way that they are presented in the GeoServices REST API. GeoServer styles use the SLD format, which allows a wide variety of conditional styling, while \"Renderers\" in the GeoServices REST API are much more constrained. The GeoServices plugin checks for SLD styles conforming to a small number of patterns and converts these to equivalent renderers, but when an SLD uses capabilities with no analog in GeoServices a simple default style will be advertised instead.

      "},{"location":"community/gsr/installing/","title":"Installing the GeoServer GSR extension","text":"
      1. Download the extension from the nightly GeoServer community module builds gsr.

        ::: warning ::: title Warning :::

        Make sure to match the version of the extension to the version of the GeoServer instance! :::

      2. Extract the contents of the archive into the WEB-INF/lib directory of the GeoServer installation.

      "},{"location":"community/gsr/usage/","title":"GSR Usage","text":"

      Currently basic FeatureServer and MapServer functionality work. Each GeoServer workspace is considered an ArcGIS\u00ae \"service\" for the purposes of the API. ArcGIS\u00ae URLs look like this in GeoServer:

      http://localhost:8080/geoserver/gsr/services/topp/MapServer/ http://localhost:8080/geoserver/gsr/services/topp/FeatureServer/

      Where topp is the workspace name.

      Note

      Esri\u00ae, ArcGIS\u00ae and ArcGIS Online\u00ae are trademarks, registered trademarks, or service marks of Esri in the United States, the European Community, or certain other jurisdictions. Other companies and products mentioned may be trademarks of their respective owners.

      "},{"location":"community/gsr/usage/#cors","title":"CORS","text":"

      When using the official JS API, CORS detection does not work correctly. You will need to add your server manually to the list of CORS enabled servers:

      require([\"esri/config\"], function (esriConfig) {\n  esriConfig.request.corsEnabledServers.push(\"localhost:9191\");\n});\n

      CORS support also needs to be enabled on the server. Without these settings, it will attempt to use JSONP, which may not be as well supported.

      For information on enabling CORS in GeoServer, see here.

      "},{"location":"community/gsr/usage/#web-mercator-spatial-reference","title":"Web Mercator Spatial Reference","text":"

      The official APIs use Spatial Reference 102100 as Web Mercator. In order for this to work, add the following custom projection to your data_dir/user_projections/epsg.properties file:

      102100=PROJCS[\"WGS 84 / Pseudo-Mercator\",GEOGCS[\"Popular Visualisation CRS\", DATUM[\"Popular_Visualisation_Datum\",SPHEROID[\"Popular Visualisation Sphere\",6378137,0, AUTHORITY[\"EPSG\",\"7059\"]],TOWGS84[0,0,0,0,0,0,0],AUTHORITY[\"EPSG\",\"6055\"]], PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.01745329251994328, AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\",\"4055\"]],UNIT[\"metre\",1,AUTHORITY[\"EPSG\",\"9001\"]], PROJECTION[\"Mercator_1SP\"],PARAMETER[\"central_meridian\",0],PARAMETER[\"scale_factor\",1], PARAMETER[\"false_easting\",0],PARAMETER[\"false_northing\",0],AUTHORITY[\"EPSG\",\"3785\"], AXIS[\"X\",EAST],AXIS[\"Y\",NORTH]]

      "},{"location":"community/gwc-azure-blob/","title":"GWC Azure BlobStore plugin","text":"

      This plugin supports the use of the Azure BLOB storage. as storage medium for GeoWebCache settings.

      "},{"location":"community/gwc-azure-blob/#installing-the-azure-blobstore-plugin","title":"Installing the Azure BlobStore plugin","text":"
      1. Download the extension from the nightly GeoServer community module builds.

        ::: warning ::: title Warning :::

        Make sure to match the version of the extension to the version of the GeoServer instance! :::

      2. Extract the contents of the archive into the WEB-INF/lib directory of the GeoServer installation.

      "},{"location":"community/gwc-azure-blob/#configuring-the-azure-blobstore-plugin","title":"Configuring the Azure BlobStore plugin","text":"

      Once the plugin has been installed, one or more Azure BlobStores may be configured through BlobStores. Afterwards, cached layers can be explicitly assigned to it or one blobstore could be marked as 'default' to use it for all unassigned layers.

      "},{"location":"community/gwc-azure-blob/#container","title":"Container","text":"

      The name of the Azure storage container where the tiles are stored.

      "},{"location":"community/gwc-azure-blob/#account-name","title":"Account name","text":"

      Azure storage account name

      "},{"location":"community/gwc-azure-blob/#account-key","title":"Account key","text":"

      Azure storage Account Key.

      "},{"location":"community/gwc-azure-blob/#azure-object-key-prefix","title":"Azure Object Key Prefix","text":"

      A prefix path to use as the root to store tiles under the container (optional).

      "},{"location":"community/gwc-azure-blob/#maximum-connections","title":"Maximum Connections","text":"

      The maximum number of allowed open HTTP connections.

      "},{"location":"community/gwc-azure-blob/#use-https","title":"Use HTTPS","text":"

      When enabled, a HTTPS connection will be used. When disabled, a regular HTTP connection will be used.

      "},{"location":"community/gwc-azure-blob/#proxy-host","title":"Proxy Host","text":"

      Proxy host the client will connect through (optional).

      "},{"location":"community/gwc-azure-blob/#proxy-port","title":"Proxy Port","text":"

      Proxy port the client will connect through (optional).

      "},{"location":"community/gwc-azure-blob/#proxy-username","title":"Proxy Username","text":"

      User name the client will use if connecting through a proxy (optional).

      "},{"location":"community/gwc-azure-blob/#proxy-password","title":"Proxy Password","text":"

      Password the client will use if connecting through a proxy (optional).

      Note

      Unlike AWS, Azure storage controls whether tiles can be accessed by the public at the container level. If you desire to build a public tile cache that can be directly accessed by clients as static files, set the container access level to \"public\" or \"BLOB\" and fully seed the cache.

      "},{"location":"community/gwc-distributed/","title":"GWC Distributed Caching community module","text":"

      GWC Distributed Caching module provides support for distributed in Memory caching using the Hazelcast API.

      "},{"location":"community/gwc-distributed/#installing-the-wps-download-module","title":"Installing the WPS download module","text":"
      1. Download the GWC Distributed module from the nightly GeoServer community module builds.

        Warning

        Make sure to match the version of the extension to the version of the GeoServer instance.

      2. Extract the contents of the archive into the WEB-INF/lib directory of the GeoServer installation.

      "},{"location":"community/gwc-distributed/#module-description","title":"Module description","text":"

      More information about Caching Configuration can be found at the Configuration and Caching defaults pages.

      "},{"location":"community/gwc-mbtiles/","title":"GWC MBTiles layer plugin","text":"

      This plugin allows adding a GWC MBTiles Layer to GeoServer's cached Tile Layers configuration so that GeoServer can load cached tiles from ready-to-use MBTiles.

      "},{"location":"community/gwc-mbtiles/#installation","title":"Installation","text":"

      As a community module, make sure you have downloaded the gwc-mbtiles

      To install the module, unpack the zip file contents into the GeoServer WEB-INF/lib directory and restart GeoServer.

      "},{"location":"community/gwc-mbtiles/#configuring-a-mbtileslayer","title":"Configuring a MBTilesLayer","text":"

      The configuration of a new MBTilesLayer can be done by editing the geowebcache configuration file located in <data_dir>/gwc/geowebcache.xml

      Locate the layers section of the config or add it if missing.

      Then define a new mbTilesLayer node for each new MBTilesLayer you want to add. A GWC configuration containing a configured MBTiles Layer would look like this:

      <gwcConfiguration>\n  <!-- ... -->\n  <layers>\n    <!-- Other layer definitions may be here -->\n    <mbtilesLayer>\n      <tilesPath>D:\\Data\\mbtiles\\countries-raster.mbtiles</tilesPath>\n      <tileSize>256</tileSize>\n      <name>countries</name>\n      <metaInformation>\n        <title>Countries</title>\n        <description>Raster Layer with Countries</description>\n      </metaInformation>\n    </mbtilesLayer>\n    <!-- Other layer definitions may be here -->\n  </layers>\n</gwcConfiguration>\n

      A few note on the above configuration elements of an mbtilesLayer definition:

      • tilesPath (mandatory) is the path to the MBTiles file containing the tiles.
      • tileSize is the size of the tiles stored on the MBTiles file. When not set, it will be defaulted to 256.
      • name (optional) represents the name to be assigned to the layer. If not specified, the name field of the metadata table stored in the MBTiles file will be used. Make sure to define it in case the MBTiles metadata is missing it.
      • metaInformation with title and description are optional tags. They will be exposed in the capabilities document when available.
      "},{"location":"community/gwc-sqlite/","title":"GWC SQLite Plugin","text":"

      This plugin provides integration with GWC SQLite based blob stores. At the moment only one blob store of this type is available, the MBTiles blob store.

      "},{"location":"community/gwc-sqlite/#mbtiles-blob-store","title":"MBTiles Blob Store","text":"

      This blob store allow us to store tiles using the MBTiles specification (version 1.1) which defines a schema for storing tiles in an SQLite database with some restrictions regarding tiles formats and projections.

      MBTiles specification only supports JPEG and PNG formats and projection EPSG:3857 is assumed. The implemented blob store will read and write MBTiles files compliant with the specification but will also be able to write and read MBTiles files that use others formats and projections.

      Using the MBTiles blob store will bring several benefits at the cost of some performance loss. The MBTiles storage uses a significantly smaller number of files, which results in easier data handling (e.g., backups, moving tiles between environments). In some cases the stored data will be more compact reducing the size of the data on disk.

      When compared to the file blob store this store has two limitations:

      • This store does not integrate with disk quota, this is a consequence of using database files.
      • This store cannot be shared among several GeoWebCache instances.

      Note

      If disk quota is activated the stored stats will not make much sense and will not reflect the actual disk usage, the size of the database files cannot be really controlled.

      Database files cannot be managed as simple files. When connections to a database are open the associated file should not be deleted, moved or switched or the database file may become corrupted. Databases files can also become fragmented after deleting an huge amount of data or after frequent inserts, updates or delete operations.

      "},{"location":"community/gwc-sqlite/#file-path-templates","title":"File Path Templates","text":"

      An MBTiles file will correspond to an SQLite database file. In order to limit the amount of contention on each single database file users will be allowed to decide the granularity of the databases files. When GeoWebCache needs to map a tile to a database file it will only look at the databases files paths, it will not take in account the MBTiles metadata (this is why this store is able to handle others formats and projections).

      To configure the databases files granularity the user needs to provide a file path template. The default file path template for the MBTiles blob store is this one:

      {layer}/{grid}{format}{params}/{z}-{x}-{y}.sqlite\n

      This file template will stores all the tiles belonging to a certain layer in a single folder that will contain sub folders for each given format, projection and set of parameters and will group tiles with the same zoom level, column range and row range in a SQLite file. The column and row range values are passed by configuration, by default those values are equal to 250. The provided files paths templates will always be considered relative to the root directory provided as a configuration option.

      Follows an example of what the blob store root directory structure may look like when using the default path template:

      .\n|-- nurc_Pk50095\n|   `-- EPSG_4326image_pngnull\n|       |-- 11_2000_1500.sqlite\n|       `-- 12_4250_3000.sqlite\n`-- topp_states\n    |-- EPSG_900913image_jpeg7510004a12f49fdd49a2ba366e9c4594be7e4358\n    |   |-- 6_250_500.sqlite\n    |   `-- 7_0_0.sqlite\n    `-- EPSG_900913image_jpegnull\n        |-- 3_500_0.sqlite\n        |-- 4_0_250.sqlite\n        `-- 8_750_500.sqlite\n

      If no parameters were provided null string will be used. Is the responsibility of the user to define a file path template that will avoid collisions.

      The terms that can be used in the file path template are:

      • grid: the grid set id
      • layer: the name of the layer
      • format: the image format of the tiles
      • params: parameters unique hash
      • x: column range, computed based on the column range count configuration property
      • y: row range, computed based on the row range count configuration property
      • z: the zoom level

      It is also possible to use parameters values, like style for example. If the parameter is not present null will be used.

      Note

      Characters and `/` can be used as path separator, they will be translated to the operating system specific one ( for Linux and / for Windows). Any special char like `,/,:` or empty space used in a term value will be substituted with an underscore.

      "},{"location":"community/gwc-sqlite/#mbtiles-metadata","title":"MBTiles Metadata","text":"

      A valid MBTiles file will need some metadata, the image format and layer name will be automatically added when an MBTiles file is created. The user can provide the remaining metadata using a properties file whose name must follow this pattern:

      <layerName>.metadata\n

      As an example, to add metadata description and attribution entries to layer tiger_roads a file named tiger_roads.properties with the following content should be present in the metadata directory:

      description=ny_roads\nattribution=geoserver\n

      The directory that contains this metadata files is defined by a configuration property.

      "},{"location":"community/gwc-sqlite/#expiration-rules","title":"Expiration Rules","text":"

      The MBTiles specification don't give information about when a tile was created. To allow expire rules, an auxiliary table is used to store tile creation time. In the presence of an MBTiles file generated by a third party tool it is assumed that the creation time of a tile was the first time it was accessed. This feature can be activated or deactivated by configuration. Note that this will not break the MBTiles specification compliance.

      "},{"location":"community/gwc-sqlite/#eager-truncate","title":"Eager Truncate","text":"

      When performing a truncate of the cache the store will try to remove the whole database file avoiding to create fragmented space. This is not suitable for all the situations and is highly dependent on the database files granularity. The configuration property eagerDelete allows the user to disable or deactivate this feature which is disabled by default.

      When a truncate request by tile range is received all the databases files that contains tiles that belong to the tile range are identified. If eager delete is set to true those databases files are deleted otherwise a single delete query for each file is performed.

      "},{"location":"community/gwc-sqlite/#configuration-example","title":"Configuration Example","text":"

      Follows as an example the default configuration of the MBTiles store:

      The rootDirectory property defines the location where all the files produced by this store will be created. The templatePath property is used to control the granularity of the database files (see section above). Properties rowRangeCount and columnRangeCount will be used by the path template to compute tile ranges.

      The poolSize property allows to control the max number of open database files, when defining this property the user should take in account the number open files allowed by the operating system. The poolReaperIntervalMs property controls how often the pool size will be checked to see if some database files connections need to be closed.

      Property eagerDelete controls how the truncate operation is performed (see section above). The property useCreateTime can be used to activate or deactivate the insertion of the tile creation time (see section above). Property executorConcurrency controls the parallelism used to perform certain operations, like the truncate operation for example. Property mbtilesMetadataDirectory defines the directory where the store will look for user provided MBTiles metadata.

      Note

      Since the connection pool eviction happens at a certain interval, it means that the number of files open concurrently can go above the threshold limit for a certain amount of time.

      "},{"location":"community/gwc-sqlite/#replace-operation","title":"Replace Operation","text":"

      As said before, if the cache is running SQLite files cannot be simply switched, first all connections need to be closed. The replace operation was created for this propose. The replace operation will first copy the new file side by side the old one, then block the requests to the old file, close the connections tot he old file, delete the old one, rename the new file to current one, reopen the new db file and start serving requests again. Should be almost instant.

      A REST entry point for this operation is available, it will be possible to submit a ZIP file or a single file along with the request. The replace operation can also use an already present file or directory. When using a directory the directory structure will be used to find the destination of each file, all the paths will be assumed to be relative to the store root directory. This means that is possible to replace a store content with another store content (a seeded one for example) by zipping the second store root directory and send it as a replacement.

      Note

      When using a local directory or submitting a zip file all the file present in the directory will be considered.

      There is four ways to invoke this operation. Follows an example of all those variants invocations using CURL.

      Replace a single file uploading the replacement file:

      curl -u admin:geoserver -H 'Content-Type: multipart/form-data'\n  -F \"file=@tiles_0_0.sqlite\"\n  -F \"destination=EPSG_4326/sf_restricted/image_png/null/10/tiles_0_0.sqlite\"\n  -F \"layer=sf:restricted\"\n  -XPOST 'http://localhost:8080/geoserver/gwc/rest/sqlite/replace'\n

      Replace a single file using a file already present on the system:

      curl -u admin:geoserver -H 'Content-Type: multipart/form-data'\n  -F \"source=/tmp/tiles_0_0.sqlite\"\n  -F \"destination=EPSG_4326/sf_restricted/image_png/null/10/tiles_0_0.sqlite\"\n  -F \"layer=sf:restricted\"\n  -XPOST 'http://localhost:8080/geoserver/gwc/rest/sqlite/replace'\n

      Replace multiple files uploading a ZIP file:

      curl -u admin:geoserver -H 'Content-Type: multipart/form-data'\n  -F \"file=@tiles.zip\"\n  -F \"layer=sf:restricted\"\n  -XPOST 'http://localhost:8080/geoserver/gwc/rest/sqlite/replace'\n

      Replace multiple files using a directory already present on the system:

      curl -u admin:geoserver -H 'Content-Type: multipart/form-data'\n  -F \"source=/tmp/tiles\"\n  -F \"layer=sf:restricted\"\n  -XPOST 'http://localhost:8080/geoserver/gwc/rest/sqlite/replace'\n

      The layer parameter identifies the layer whose associated blob store content should be replaced. The file parameter is used to upload a single file or a ZIP file. The source parameter is used to reference an already present file or directory. The destination parameter is used to define the file that should be replaced with the provided file.

      This are the only valid combinations of this parameters other combinations will ignore some of the provided parameters or will throw an exception.

      "},{"location":"community/hana/","title":"SAP HANA","text":""},{"location":"community/hana/#supported-versions","title":"Supported versions","text":"

      The module supports

      • SAP HANA 1 SPS 12
      • SAP HANA 2 (all SPS including the free express edition)
      • SAP HANA Cloud
      "},{"location":"community/hana/#hana_install","title":"Installing SAP HANA support","text":"

      GeoServer has no built-in support for SAP HANA. You can enable SAP HANA support by adding the HANA GeoTools module and the HANA JDBC driver to your GeoServer installation.

      "},{"location":"community/hana/#installing-the-hana-geotools-module","title":"Installing the HANA GeoTools module","text":"

      Identify the GeoTools version your GeoServer installation is using by navigating to the webapps/geoserver/WEB-INF/lib/ folder in your GeoServer installation and locating the file gt-jdbc-{<version>}.jar as shown in the image below. In the example below the GeoServer version is 22.0.

      Finding the GeoTools version

      Download the GeoTools archive with the version used by GeoServer from the GeoTools website. You need the geotools-{<version>}-bin.zip file. Copy the gt-jdbc-hana-{<version>}.jar file to the webapps/geoserver/WEB-INF/lib/ folder of your GeoServer installation.

      Locating the GeoTools HANA module

      "},{"location":"community/hana/#installing-the-hana-jdbc-driver","title":"Installing the HANA JDBC driver","text":"

      Browse to the SAP Development Tools website and download the JDBC component to the webapps/geoserver/WEB-INF/lib/ folder of your GeoServer installation.

      Downloading ngdbc.jar from the SAP Development Tools website

      Afterwards restart your GeoServer instance.

      "},{"location":"community/hana/#adding-a-sap-hana-database","title":"Adding a SAP HANA database","text":"

      After both modules have been installed, SAP HANA will show up as an option when creating a new data store.

      HANA in the list of vector data sources

      "},{"location":"community/hana/#configuring-a-sap-hana-data-store","title":"Configuring a SAP HANA data store","text":"

      Configuring a SAP HANA data store

      The following options are relevant for SAP HANA:

      host The machine name or IP address to connect to.

      port The port to connect to. If set and different from 0, the parameters instance and database are ignored. If not set or 0, the instance parameter must be set.

      instance The instance to connect to. This parameter is ignored if a port is set. The instance field is at the bottom of the configuration form in case you have difficulties locating it.

      database The database to connect to. Leave empty in case of single-container databases. Set to SYSTEMDB to connect to the system database of a multi-container database. This parameter is ignored if a port is set.

      schema The database schema to access. If left blank, the user-specific database schema is accessed.

      user The database user used to connect to the database.

      passwd The password used to connect to the database.

      use ssl If checked the TLS/SSL cryptographic protocol is used to establish a secure connection with the database.

      "},{"location":"community/importer-jdbc/","title":"Importer JDBC storage","text":"

      This plugin allows sharing the state of imports in a relational database supported by GeoTools. Compared to the default in-memory storage, this helps in two ways:

      • The state of the imports is persisted and survives restarts
      • If an external database, such as PostgreSQL/PostGIS, is used, then it's possible to run multiple imports on different GeoServer nodes in load balancing and get a consolidated view of their state
      "},{"location":"community/importer-jdbc/#installation","title":"Installation","text":"

      The module zip just need to be unpacked in the GeoServer WEB-INF\\lib. On startup the module will create by default a H2 database in a \"importer\" folder inside the data directory, as well as a configuration file at ${GEOSERVER_DATA_DIR}/jdbc-import-store.properties.

      The property file can be modified to point to an external database, for example, the following contents are suitable for a PostGIS database (PostGIS extensions mandatory, even if not used):

      dbtype=postgis\nuser=myUserName\npasswd=myPassword\ndatabase=databaseName\nport=5432\nhost=localhost\nschema=public\n

      On connection the code will create one table and the suitable indexes to track the imports. In case the user above is not allowed to create tables, the following SQL statement can be used (adapt to the specific database):

      CREATE TABLE public.import_context\n(\n  fid serial,\n  context text,\n  created timestamp,\n  updated timestamp,\n  \"user\" character varying,\n  state character varying,\n  CONSTRAINT import_context_pkey PRIMARY KEY (fid)\n);\nCREATE INDEX import_context_state ON import_context(state);\nCREATE INDEX import_context_user ON import_context(\"user\");\n

      Note

      The store has been tested with H2 and Postgresql with PostGIS extensions, it may work with other relational databases too assuming that they have a corresponding GeoTools data store plugin installed and the database is not changing the name of the columns (Oracle will most likely not work).

      Note

      With some light extra development and testing the code could be extended to save the status of imports in any GeoTools supported store, e.g., SOLR, MongoDB.

      "},{"location":"community/jdbcconfig/","title":"JDBCConfig","text":"

      The JDBCConfig module enhances the scalability performance of the GeoServer Catalog. It allows externalising the storage of the Catalog configuration objects (such as workspaces, stores, layers) to a Relational Database Management System, rather than using xml files in the GeoServer data directory. This way the Catalog can support access to unlimited numbers of those configuration objects efficiently.

      • Installing JDBCConfig
      • JDBCConfig configuration
      "},{"location":"community/jdbcconfig/configuration/","title":"JDBCConfig configuration","text":"

      The JDBCConfig module is configured in the file jdbcconfig/jdbcconfig.properties inside the GeoServer data directory. The following properties may be set:

      • enabled: Use JDBCConfig. Turn off to use the data directory for all configuration instead.
      • initdb: Initialize an empty database if this is set on true.
      • import : The import configuration option tells GeoServer whether to import the current catalog from the file system to the database or not. If set to true, it will be imported and the config option will be set the value 'false' for the next start up to avoid trying to re-import the catalog configuration.
      • repopulate: The repopulate configuration option tells GeoServer to repopulate the queryable field values in the database. These are the fields of catalog objects jdbcconfig can query via the database, i.e. much faster than via post-filtering in memory. May be necessary after jdbcconfig upgrades or if someone manually adds queryable fields to the database. (In such cases, if the values were not properly repopulated, queries might give incorrect results.)
      • initScript: Path to initialisation script .sql file. Only used if initdb = true.
      "},{"location":"community/jdbcconfig/configuration/#jndi","title":"JNDI","text":"

      Get the database connection from the application server via JNDI lookup.

      • jndiName: The JNDI name for the data source. Only set this if you want to use JNDI, the JDBC configuration properties may still be set for in case the JNDI Lookup fails.
      "},{"location":"community/jdbcconfig/configuration/#direct-jdbc-connection","title":"Direct JDBC Connection","text":"

      Provide the connection parameters directly in the configuration file. This includes the password in the clear which is a potential security risk. To avoid this use JNDI instead.

      • jdbcUrl: JDBC direct connection parameters.
      • username: JDBC connection username.
      • password: JDBC connection password.
      • pool.minIdle: minimum connections in pool
      • pool.maxActive: maximum connections in pool
      • pool.poolPreparedStatements: whether to pool prepared statements
      • pool.maxOpenPreparedStatements: size of prepared statement cache, only used if pool.poolPreparedStatements is true
      • pool.testOnBorrow: whether to validate connections when obtaining from the pool
      • pool.validationQuery: validation query for connections from pool, must be set when pool.testOnBorrow is true
      • pool.testWhileIdle: whether to validate idle connections, used in conjunction with the idle timer below
      • pool.setTimeBetweenEvictionRunsMillis: period in millseconds for the idle object evictor, -1 to disable
      "},{"location":"community/jdbcconfig/installing/","title":"Installing JDBCConfig","text":"

      To install the JDBCConfig module:

      1. Visit the website download page and download jdbcconfig.
      2. Extract this file and place the JARs in WEB-INF/lib.
      3. Perform any configuration required by your servlet container, and then restart. On startup, JDBCConfig will create a configuration directory jdbcconfig in the GeoServer data directory.
      4. Verify that the configuration directory was created to be sure installation worked then turn off GeoServer.
      5. Configure JDBCConfig (JDBCConfig configuration), being sure to set enabled, initdb, and import to true, and to provide the connection information for an empty database.
      6. Start GeoServer again. This time JDBCConfig will connect to the specified database, initialize it, import the old catalog into it, and take over from the old catalog. Subsequent start ups will skip the initialize and import steps unless you re-enable them in jdbcconfig.properties.
      7. Log in as admin and a message should appear on the welcome page:

      "},{"location":"community/jdbcstore/","title":"JDBCStore","text":"

      The JDBCStore module allows efficient sharing of configuration data in a clustered deployment of GeoServer. It allows externalising the storage of all configuration resources to a Relational Database Management System, rather than using the default File System based GeoServer data directory. This way the multiple instances of GeoServer can use the same Database and therefore share in the same configuration.

      • Installing JDBCStore
      • JDBCStore configuration
      "},{"location":"community/jdbcstore/configuration/","title":"JDBCStore configuration","text":"

      The JDBCStore module is configured in the file jdbcstore/jdbcstore.properties inside the GeoServer data directory. The following properties may be set:

      • enabled: Use JDBCStore. Turn off to use the data directory for all configuration instead.
      • initdb: Initialize an empty database if this is set on true.
      • import : The import configuration option tells GeoServer whether to import the current GeoServer data directory from the file system to the database or not. If set to true, it will be imported and the config option will be set the value 'false' for the next start up to avoid trying to re-import the catalog configuration.
      • initScript: Path to initialisation script .sql file. Only used if initdb is true.
      • ignoreDirs: specify all subdirectories of the GeoServer data directory that should be ignored by the JDBCStore, in a comma-separate list. These subdirectories will not be imported and while JDBCStore is running, all access to these subdirectories and their contents will be redirected to the default file system store. This is usually done with the data directory (which holds data rather than metadata such as images and shapefiles), temporary directories (which are not used for permanent storage) and the catalog directories (when using JDBCConfig, these are unused anyway and they need not be copied into the JDBCStore).
      • cachedDirs: specify all subdirectories of the datadir that should be automatically cached on the file system by the JDBCStore, in a comma-separate list. These subdirectories will be stored in the database, but an up-to-date copy will be stored on the hard drive at all times. This is handy for files that are used by tools that do not support jdbcstore (such as Application Schemas <../../data/app-schema/index.rst>_ for example) but still need to be synced between nodes.
      • deleteDestinationOnRename: allow automatic overwriting of existing destinations on move and rename operations (linux-style versus windows-style - the default store is platform dependant).
      "},{"location":"community/jdbcstore/configuration/#jndi","title":"JNDI","text":"

      Get the database connection from the application server via JNDI lookup.

      • jndiName: The JNDI name for the data source. Only set this if you want to use JNDI, the JDBC configuration properties may still be set for in case the JNDI Lookup fails.
      "},{"location":"community/jdbcstore/configuration/#direct-jdbc-connection","title":"Direct JDBC Connection","text":"

      Provide the connection parameters directly in the configuration file. This includes the password in the clear which is a potential security risk. To avoid this use JNDI instead.

      • jdbcUrl: JDBC direct connection parameters.
      • username: JDBC connection username.
      • password: JDBC connection password.
      • pool.minIdle: minimum connections in pool
      • pool.maxActive: maximum connections in pool
      • pool.poolPreparedStatements: whether to pool prepared statements
      • pool.maxOpenPreparedStatements: size of prepared statement cache, only used if pool.poolPreparedStatements is true
      • pool.testOnBorrow: whether to validate connections when obtaining from the pool
      • pool.validationQuery: validation query for connections from pool, must be set when pool.testOnBorrow is true
      • pool.testWhileIdle: whether to validate idle connections, used in conjunction with the idle timer below
      • pool.setTimeBetweenEvictionRunsMillis: period in millseconds for the idle object evictor, -1 to disable
      "},{"location":"community/jdbcstore/installing/","title":"Installing JDBCStore","text":"

      To install the JDBCStore module:

      1. Download the module: jdbcstore

        The JDBCStore plug-in automatically includes the JDBCConfig plugin as well which will generally be run at the same time.

      2. Extract this file and place the JARs in WEB-INF/lib.

      3. Perform any configuration required by your servlet container, and then restart. On startup, JDBCStore will create a configuration directory jdbcstore and JDBCConfig will create a configuration directory jdbcconfig in the GeoServer data directory .

      4. Verify that the configuration directories were created to be sure installation worked then turn off GeoServer.

      5. If you want to use JDBCConfig as well, configure it first, being sure to set enabled, initdb, and import to true, and to provide the connection information for an empty database. Start GeoServer to initialize the JDBCConfig database, import the old catalog into it, and take over from the old catalog. Subsequent start ups will skip the initialize and import steps unless you re-enable them in jdbcconfig.properties.

      6. Now configure JDBCStore in a similar fashion (JDBCStore configuration), being sure to set enabled, initdb, and import to true, and to provide the connection information for an empty database. Start GeoServer again. This time JDBCStore will connect to the specified database, initialize it, import the old GeoServer data directory into it, and take over from the old GeoServer data directory. Subsequent start ups will skip the initialize and import steps unless you re-enable them in jdbcstore.properties.

      "},{"location":"community/jms-cluster/","title":"JMS based Clustering","text":""},{"location":"community/jms-cluster/#introduction","title":"Introduction","text":"

      The are several approaches to implement a clustered deployment with GeoServer, based on different mixes of data directory sharing plus configuration reload. The JMS based clustering module architecture is depicted in the following diagram:

      This module implements a robust Primary/Replica approach which leverages on a Message Oriented Middleware (MOM) where:

      • The Primaries accept changes to the internal configuration, persist them on their own data directory but also forward them to the Replicas via the MOM
      • The Replicas should not be used to change their configuration from either REST or the User Interface, since are configured to inject configuration changes disseminated by the Primary(s) via the MOM
      • The MOM is used to make the Primary and the Replicas exchange messages in a durable fashion
      • Each Replicas has its own data directory and it is responsible for keeping it aligned with the Primary's one. In case a Replicas goes down when it goes up again he might receive a bunch of JMS messages to align its configuration to the Primary's one.
      • A Node can be both Primary and Replica at the same time, this means that we don't have a single point of failure, i.e. the Primary itself

      Summarizing, the Primary as well as each Replicas use a private data directory, Replicas receive changes from the Primary, which is the only one where configuration changes are allowed, via JMS messages. Such messages transport GeoServer configuration objects that the Replicas inject directly in their own in-memory configuration and then persist on disk on their data directory, completely removing the need for a configuration reload for each configuration change.

      To make things simpler, in the default configuration the MOM is actually embedded and running inside each GeoServer, using multicast to find its peers and thus allowing for a clustering installation without the need to have a separate MOM deploy.

      "},{"location":"community/jms-cluster/#description","title":"Description","text":"

      The GeoServer Primary/Replica integration is implemented using JMS, Spring and a MOM (Message Oriented Middleware), in particular ActiveMQ. The schema in Illustration represents a complete high level design of Primary/Replica platform. It is composed by 3 distinct actors:

      1. GeoServer Primary
      2. GeoServer Replicas
      3. The MOM (ActiveMQ)

      This structure allows to have:

      1. Queue fail-over components (using MOM).
      2. Replica down are automatically handled using durable topic (which will store message to re-synch changes happens if one of the replicas is down when the message was made available)
      3. Primary down will not affect any replicas synchronization process.

      This full blown deployment is composed by:

      • A pure Primary GeoServer(s), this instance can only send events to the topic. It cannot act as a replica
      • A set of GeoServer which can work as both Primary and Replica. These instances can send and receive messages to/from the topic. They can work as Primaries (sending message to other subscribers) as well as Replicas (these instances are also subscribers of the topic).
      • A set of pure Replicas GeoServer instances whic can only receive messages from the topic.
      • A set of MOM brokers so that each GeoServer instance is configured with a set of available brokers (failover). Each broker use the shared database as persistence. Doing so if a broker fails for some reason, messages can still be written and read from the shared database.

      All the produced code is based on spring-jms to ensure portability amongst different MOM, but if you look at the schema, we are also leveraging ActiveMQ VirtualTopics to get dynamic routing (you can dynamically attach primary and replica).

      The VirtualTopics feature has also other advantages explained here: http://activemq.apache.org/virtual-destinations.html

      As said above, in the default configuration the MOM runs inside GeoServer itself, simplifying the topology and the setup effort.

      "},{"location":"community/jms-cluster/#installation","title":"Installation","text":"

      To install the jms cluster modules into an existing GeoServer refer to the jms.installation page

      "},{"location":"community/jms-cluster/#how-to-configure-geoserver-instances","title":"How to configure GeoServer Instances","text":"

      The configuration for the GeoServer is very simple and can be performed using the provided GUI or modifying the cluster.properties file which is stored into the GEOSERVER_DATA_DIR under the cluster folder (e.g. ${GEOSERVER_DATA_DIR}/cluster).

      To override the default destination of this configuration file you have to setup the CLUSTER_CONFIG_DIR variable defining the destination folder of the cluster.properties file. This is mandatory when you want to share the same GEOSERVER_DATA_DIR, but not required if you are giving each GeoServer its own data directory.

      In case of shared data directory, it will be necessary to add a different system variable to each JVM running a GeoServer, e.g.:

      • -DCLUSTER_CONFIG_DIR=/var/geoserver/clusterConfig/1 to the JVM running the first node
      • -DCLUSTER_CONFIG_DIR=/var/geoserver/clusterConfig/2 to the JVM running the second node
      • and so on

      If the directories are missing, GeoServer will create them and provide a initial cluster.properties with reasonable defaults.

      "},{"location":"community/jms-cluster/#instance-name","title":"Instance name","text":"

      The instance.name is used to distinguish from which GeoServer instance the message is coming from, so each GeoServer instance should use a different, unique (for a single cluster) name.

      "},{"location":"community/jms-cluster/#broker-url","title":"Broker URL","text":"

      The broker.url field is used to instruct the internal JMS machinery where to publish messages to (primary GeoServer installation) or where to consume messages from (replica GeoServer installation). Many options are available for configuring the connection between the GeoServer instance and the JMS broker, for a complete list, please, check http://activemq.apache.org/configuring-transports.html. In case when (recommended) failover set up is put in place multiple broker URLs can be used. See http://activemq.apache.org/failover-transport-reference.html for more information about how to configure that. Note GeoServer will not complete the start-up phase until the target broker is correctly activated and reachable.

      "},{"location":"community/jms-cluster/#limitations-and-future-extensions","title":"Limitations and future extensions","text":""},{"location":"community/jms-cluster/#data","title":"Data","text":"

      NO DATA IS SENT THROUGH THE JMS CHANNEL The clustering solution we have put in place is specific for managing the GeoServer internal configuration, no data is transferred between primary and replicas. For that purpose use external mechanisms (ref. [GeoServer REST]). In principle this is not a limitation per se since usually in a clustered environment data is stored in shared locations outside the data directory. With our solution this is a requirement since each replicas will have its own private data directory.

      "},{"location":"community/jms-cluster/#things-to-avoid","title":"Things to avoid","text":"
      • NEVER RELOAD THE GEOSERVER CATALOG ON A PRIMARY: Each primary instance should never call the catalog reload since this propagates the creation of all the resources, styles, etc to all the connected replicas.
      • NEVER CHANGE CONFIGURATION USING A PURE REPLICA: This will make the configuration of the specific replica out of synch with the others.
      "},{"location":"community/jms-cluster/#refs","title":"Refs:","text":"
      • Installation of the JMS Cluster modules
      • HOWTO configure ActiveMQ broker
      • JDBC Primary/Replica
      • Shared File System Primary/Replica
      "},{"location":"community/jms-cluster/#bibliography","title":"Bibliography:","text":"

      [JMS specs] Sun microsystens - Java Message Service - Version 1.1 April 12, 2002

      [JMS] Snyder Bosanac Davies - ActiveMQ in action - Manning

      [GeoServer] http://docs.geoserver.org/

      [GeoServer REST] http://docs.geoserver.org/latest/en/user/rest/index.html#rest

      [ActiveMQ] http://activemq.apache.org/

      "},{"location":"community/jms-cluster/installation/","title":"Installation","text":"

      jms.installation

      "},{"location":"community/jms-cluster/installation/#jms.installation","title":"Installation of the JMS Cluster modules","text":"

      To install the JMS Cluster modules you simply have to:

      • Download the geoserver-jms-cluster-<version>.zip file from the nightly builds, community section
      • Stop GeoServer
      • Unpack the zip file in webapps/geoserver/WEB-INF/lib
      • Start again GeoServer

      .. warning:

      In GeoServer versions 2.10.4, 2.11.1 and 2.12-beta default topic name was renamed from VirtualTopic.>, which has a special meaning in ActiveMQ, to VirtualTopic.geoserver. When upgrading to one of this versions or above the virtual topic name will be automatically updated. Note that only GeoServer instances that use the same topic name will be synchronized.

      As a recommendation, for the first tests try to run the cluster module on a cluster of GeoServer all having their own data directory.

      If you want to use the clustering extension while sharing the same data dir that's also possible, but you'll have to remember to use the CLUSTER_CONFIG_DIR system variable, and set it to a different folder for each instance, e.g.:

      • set -DCLUSTER_CONFIG_DIR=/path/to/cluster/config/dir/1 on the first node,
      • set -DCLUSTER_CONFIG_DIR=/path/to/cluster/config/dir/2 on the second node
      • and so on

      The directories do not need to exist, GeoServer will create and populate them on startup automatically.

      "},{"location":"community/jms-cluster/activemq/JDBC/","title":"JDBC Primary/Replica","text":"

      If you are using pure JDBC and not using the high performance journal then you are generally relying on your database as your single point of failure and persistence engine. If you do not have really high performance requirements this approach can make a lot of sense as you have a single persistence engine to backup and manage etc.

      "},{"location":"community/jms-cluster/activemq/JDBC/#startup","title":"Startup","text":"

      When using just JDBC as the data source you can use a Primary/Replica approach, running as many brokers as you wish as this diagram shows. On startup one primary grabs an exclusive lock in the broker database - all other brokers are replicas and pause waiting for the exclusive lock.

      Clients should be using the Failover Transport to connect to the available brokers. e.g. using a URL something like the following failover:(tcp://broker1:61616,tcp://broker2:61616,tcp://broker3:61616) Only the primary broker starts up its transport connectors and so the clients can only connect to the primary.

      "},{"location":"community/jms-cluster/activemq/JDBC/#primary-failure","title":"Primary failure","text":"

      If the primary looses connection to the database or looses the exclusive lock then it immediately shuts down. If a primary shuts down or fails, one of the other replicas will grab the lock and so the topology switches to the following diagram

      One of the other replicas immediately grabs the exclusive lock on the database to then commences becoming the primary, starting all of its transport connectors. Clients lose connection to the stopped primary and then the failover transport tries to connect to the available brokers - of which the only one available is the new primary. Primary restart At any time you can restart other brokers which join the cluster and start as replicas waiting to become a primary if the primary is shutdown or a failure occurs. So the following topology is created after a restart of an old primary...

      "},{"location":"community/jms-cluster/activemq/JDBC/#configuring-jdbc-primaryreplica","title":"Configuring JDBC Primary/Replica","text":"

      By default if you use the to avoid the high performance journal you will be using JDBC Primary/Replica by default. You just need to run more than one broker and point the client side URIs to them to get primary/replica. This works because they both try an acquire an exclusive lock on a shared table in the database and only one will succeed.

      The following example shows how to configure the ActiveMQ broker in JDBC Primary/Replica mode

      <beans>\n\n  <!-- Allows us to use system properties as variables in this configuration file -->\n  <bean class=\"org.springframework.beans.factory.config.PropertyPlaceholderConfigurer\"/>\n\n  <broker xmlns=\"http://activemq.apache.org/schema/core\">\n\n    <destinationPolicy>\n  <policyMap><policyEntries>\n\n      <policyEntry topic=\"FOO.>\">\n        <dispatchPolicy>\n      <strictOrderDispatchPolicy />\n        </dispatchPolicy>\n        <subscriptionRecoveryPolicy>\n      <lastImageSubscriptionRecoveryPolicy />\n        </subscriptionRecoveryPolicy>\n      </policyEntry>\n\n  </policyEntries></policyMap>\n    </destinationPolicy>\n\n\n    <persistenceAdapter>\n    <jdbcPersistenceAdapter dataDirectory=\"${activemq.base}/activemq-data\"/>\n\n    <!-- \n    <jdbcPersistenceAdapter dataDirectory=\"activemq-data\" dataSource=\"#oracle-ds\"/>\n    --> \n    </persistenceAdapter>\n\n    <transportConnectors>\n  <transportConnector name=\"default\" uri=\"tcp://localhost:61616\"/>\n    </transportConnectors>\n\n  </broker>\n\n  <!--  This xbean configuration file supports all the standard spring xml configuration options -->\n\n  <!-- Postgres DataSource Sample Setup -->\n  <!-- \n  <bean id=\"postgres-ds\" class=\"org.postgresql.ds.PGPoolingDataSource\">\n    <property name=\"serverName\" value=\"localhost\"/>\n    <property name=\"databaseName\" value=\"activemq\"/>\n    <property name=\"portNumber\" value=\"0\"/>\n    <property name=\"user\" value=\"activemq\"/>\n    <property name=\"password\" value=\"activemq\"/>\n    <property name=\"dataSourceName\" value=\"postgres\"/>\n    <property name=\"initialConnections\" value=\"1\"/>\n    <property name=\"maxConnections\" value=\"10\"/>\n  </bean>\n  -->\n\n  <!-- MySql DataSource Sample Setup -->\n  <!-- \n  <bean id=\"mysql-ds\" class=\"org.apache.commons.dbcp.BasicDataSource\" destroy-method=\"close\">\n    <property name=\"driverClassName\" value=\"com.mysql.jdbc.Driver\"/>\n    <property name=\"url\" value=\"jdbc:mysql://localhost/activemq?relaxAutoCommit=true\"/>\n    <property name=\"username\" value=\"activemq\"/>\n    <property name=\"password\" value=\"activemq\"/>\n    <property name=\"poolPreparedStatements\" value=\"true\"/>\n  </bean>\n  -->  \n\n  <!-- Oracle DataSource Sample Setup -->\n  <!--\n  <bean id=\"oracle-ds\" class=\"org.apache.commons.dbcp.BasicDataSource\" destroy-method=\"close\">\n    <property name=\"driverClassName\" value=\"oracle.jdbc.driver.OracleDriver\"/>\n    <property name=\"url\" value=\"jdbc:oracle:thin:@localhost:1521:AMQDB\"/>\n    <property name=\"username\" value=\"scott\"/>\n    <property name=\"password\" value=\"tiger\"/>\n    <property name=\"poolPreparedStatements\" value=\"true\"/>\n  </bean>\n  -->\n\n  <!-- Embedded Derby DataSource Sample Setup -->\n  <!-- \n  <bean id=\"derby-ds\" class=\"org.apache.derby.jdbc.EmbeddedDataSource\">\n    <property name=\"databaseName\" value=\"derbydb\"/>\n    <property name=\"createDatabase\" value=\"create\"/>\n  </bean>\n  -->  \n\n</beans>\n
      "},{"location":"community/jms-cluster/activemq/SharedFolder/","title":"Shared File System Primary/Replica","text":"

      Basically you can run as many brokers as you wish from the same shared file system directory. The first broker to grab the exclusive lock on the file is the primary broker. If that broker dies and releases the lock then another broker takes over. The replica brokers sit in a loop trying to grab the lock from the primary broker. The following example shows how to configure a broker for Shared File System Primary/Replica where /sharedFileSystem is some directory on a shared file system. It is just a case of configuring a file based store to use a shared directory.

      <persistenceAdapter>\n  <kahaDB directory=\"/sharedFileSystem/sharedBrokerData\"/>\n</persistenceAdapter>\n

      or:

      <persistenceAdapter>\n  <levelDB directory=\"/sharedFileSystem/sharedBrokerData\"/>\n</persistenceAdapter>\n

      or:

      <persistenceAdapter>\n  <amqPersistenceAdapter directory=\"/sharedFileSystem/sharedBrokerData\"/>\n</persistenceAdapter>\n
      "},{"location":"community/jms-cluster/activemq/SharedFolder/#startup","title":"Startup","text":"

      On startup one primary grabs an exclusive lock on the broker file directory - all other brokers are replicas and pause waiting for the exclusive lock.

      Clients should be using the Failover Transport to connect to the available brokers. e.g. using a URL something like the following

      failover:(tcp://broker1:61616,tcp://broker2:61616,tcp://broker3:61616)\n

      Only the primary broker starts up its transport connectors and so the clients can only connect to the primary.

      "},{"location":"community/jms-cluster/activemq/SharedFolder/#primary-failure","title":"Primary failure","text":"

      If the primary looses the exclusive lock then it immediately shuts down. If a primary shuts down or fails, one of the other replicas will grab the lock and so the topology switches to the following diagram

      One of the other replicas immediately grabs the exclusive lock on the file system to them commences becoming the primary, starting all of its transport connectors. Clients lose connection to the stopped primary and then the failover transport tries to connect to the available brokers - of which the only one available is the new primary.

      "},{"location":"community/jms-cluster/activemq/SharedFolder/#primary-restart","title":"Primary restart","text":"

      At any time you can restart other brokers which join the cluster and start as replicas waiting to become a primary if the primary is shutdown or a failure occurs. So the following topology is created after a restart of an old primary...

      Note

      If you have a SAN or shared file system it can be used to provide high availability such that if a broker is killed, another broker can take over immediately.

      Ensure your shared file locks work

      Note that the requirements of this failover system are a distributed file system like a SAN for which exclusive file locks work reliably. If you do not have such a thing available then consider using Primary/Replica instead which implements something similar but working on commodity hardware using local file systems which ActiveMQ does the replication.

      OCFS2 Warning

      Was testing using OCFS2 and both brokers thought they had the primary lock - this is because \"OCFS2 only supports locking with 'fcntl' and not 'lockf and flock', therefore mutex file locking from Java isn't supported.\"

      From http://sources.redhat.com/cluster/faq.html#gfs_vs_ocfs2 :

      OCFS2: No cluster-aware flock or POSIX locks

      GFS: fully supports Cluster-wide flocks and POSIX locks and is supported.

      NFSv3 Warning

      In the event of an abnormal NFSv3 client termination (i.e., the ActiveMQ primary broker), the NFSv3 server will not timeout the lock that is held by that client. This effectively renders the ActiveMQ data directory inaccessible because the ActiveMQ replica broker can't acquire the lock and therefore cannot start up. The only solution to this predicament with NFSv3 is to reboot all ActiveMQ instances to reset everything.

      Use of NFSv4 is another solution because it's design includes timeouts for locks. When using NFSv4 and the client holding the lock experiences an abnormal termination, by design, the lock is released after 30 seconds, allowing another client to grab the lock. For more information about this, see this blog entry.

      "},{"location":"community/jms-cluster/activemq/activemqBroker/","title":"HOWTO configure ActiveMQ broker","text":"

      Deploy the produced activemqBroker.war in your tomcat instance and check the extracted webapp. You may locate a file called activemq-jmx.properties which will help you to configure your instance with the most important parameters. Anyhow it is only an example and we encourage you to also check the ApplicationContext.xml file deployed to activemq/WEB-INF/classes/ApplicationContext.xml which is the complete configuration:

      ...\n<!-- The transport connectors expose ActiveMQ over a given protocol to \n  clients and other brokers. \n  For more information, see: http://activemq.apache.org/configuring-transports.html -->\n<transportConnectors>\n    <transportConnector name=\"openwire\" uri=\"tcp://192.168.1.XXX:61616\" />\n</transportConnectors>\n...\n
      "},{"location":"community/jms-cluster/activemq/activemqBroker/#persistence-configuration","title":"Persistence Configuration","text":"

      It is possible to enable persistence for messages that cannot be delivered right away (e.g. all consumers are down). Detailed information can be found here, we are simply going to provide basic information on how to achieve that. To configure the persistence for the messages to deliver you need to setup the node in the same file as above and then configure a proper datasource in your DBMS of choice.

      ...\n<persistenceAdapter>\n<!-- <kahaDB directory=\"${activemq.base}/data/kahadb\"/> --> \n  <jdbcPersistenceAdapter dataDirectory=\"activemq-data\" \n    dataSource=\"#postgres-ds\" lockKeepAlivePeriod=\"0\"/>\n</persistenceAdapter>\n...\n

      In the above section we defined a jdbcPersistenceAdapter connected to a dataSource called #postgres-ds that forces the broker to use PostgreSQL for persisting its messages when the delivery cannot be guaranteed (e.g. a replica goes down unexpectedly). You now need to configure your own datasource as specified in the following section which are specific for different DBMS.

      "},{"location":"community/jms-cluster/activemq/activemqBroker/#oracle-datasource","title":"Oracle datasource","text":"

      To configure the broker to use an oracle database as datasource you need to uncomment and modify the following peace into the ApplicationContext.xml file:

      ...\n<bean id=\"oracle-ds\" class=\"org.apache.commons.dbcp.BasicDataSource\" destroy-method=\"close\">\n  <property name=\"driverClassName\" value=\"oracle.jdbc.driver.OracleDriver\"/>\n  <property name=\"url\" value=\"jdbc:oracle:thin:@localhost:1521:AMQDB\"/>\n  <property name=\"username\" value=\"oracle\"/>\n  <property name=\"password\" value=\" oracle \"/>\n  <property name=\"poolPreparedStatements\" value=\"true\"/>\n</bean>\n...\n

      In addition, you need to make sure that the jar containing the driver for Oracle is correctly deployed inside the WEB-INF/lib for the activemq war file. At the same time the database referred in provided instructions as well as the user must be already present.

      "},{"location":"community/jms-cluster/activemq/activemqBroker/#postgres-datasource","title":"Postgres datasource","text":"

      Configuring PostgreSQL as the datasource to use for the persistence of the messages for the ActiveMQ broker follows the same pattern as above. See below for some examples.

      ...\n<bean id=\"postgres-ds\" class=\"org.postgresql.ds.PGPoolingDataSource\">\n    <property name=\"serverName\" value=\"192.168.1.XXX\"/>\n    <property name=\"databaseName\" value=\"activemq\"/>\n    <property name=\"portNumber\" value=\"5432\"/>\n    <property name=\"user\" value=\"postgres\"/>\n    <property name=\"password\" value=\"postgres\"/>\n    <property name=\"dataSourceName\" value=\"postgres\"/>\n    <property name=\"initialConnections\" value=\"15\"/>\n    <property name=\"maxConnections\" value=\"30\"/>\n</bean>\n...\n

      In addition, you need to make sure that the jar containing the driver for PostgreSQL is correctly deployed inside the WEB-INF/lib for the activemq war file. At the same time the database referred in provided instructions as well as the user must be already present.

      Note

      The above ApplicationContext.xml file contains some unused sections which are intentionally commented out to show different types of configurations [Ref. ActiveMQ].

      "},{"location":"community/jms-cluster/activemq/activemqBroker/#kaha-datasource-embedded-database","title":"Kaha datasource (Embedded database)","text":"

      Besides using server DBMS as indicated above we can use embedded database for simpler uses cases of demoing since this usually largely simplify the configuration. At this link all the information needed for achieving this result can be found; basically we need to uncomment the related datasource and then reference it from the persistenceAdapter.

      "},{"location":"community/jms-cluster/activemq/activemqBroker/#control-instances-using-jmx","title":"Control instances using JMX","text":"

      Be sure to edit the activemq-jmx.properties (or via the environment variables) setting different JMX ports for different broker instances. Deploy as explained the instances into 2 different webapplication container (f.e. Tomcat) and start both application (on different port f.e. 8081 and 8082). Now run jconsole to connect to the brokers via JMX:

      \\${JAVA_HOME}/bin/jconsole

      After you connect to the brokers you may see something like this:

      You may look at the console, as you can see the 2nd instance of the broker cannot take the look on the file (the example uses KahaDB); this is also visible in the JMX console into the widhow on the right side.

      If now you select the 'operation' (on the left side window) you will see:

      Using that console we are able to perform many operation, so to simulate a broker down we try to click on the 'stop()' button.

      Doing so, the first broker instance will stop and the JMX connection will be closed, and the second instance (on the right side) will keep the control of the DB.

      "},{"location":"community/keycloak/","title":"Keycloak extension","text":"

      The Keycloak module allows GeoServer to work with a keycloak service to authenticate users and establish authorization using roles.

      • Installing Keycloak
      • Authentication with Keycloak
      • Keycloak Role Service
      "},{"location":"community/keycloak/authentication/","title":"Authentication with Keycloak","text":"

      This tutorial introduces GeoServer Keycloak support and walks through the process of setting up authentication against an Keycloak provider. It is recommended that the Authentication chain section be read before proceeding.

      The GeoServer Keycloak-authn/authz plugin will allow you to use an instance of Keycloak to control access to resources within GeoServer.

      "},{"location":"community/keycloak/authentication/#configuration-instructions","title":"Configuration Instructions","text":"

      As the Keycloak Admin:

      Note

      In this example the Keycloak service runs on port 8080 while GeoServer runs on port 8181

      1. Create a new client for GeoServer named geoserver-client.

      2. Make sure to add the base URL of GeoServer to the list of acceptable redirect paths, and add also the Keycloak OIDC endpoint base URI.

        eg:
        • http://localhost:8181/geoserver*
        • http://localhost:8080/auth/realms/demo/broker/keycloak-oidc/endpoint*
        ![](images/keycloak_client002.png)\n
      3. Set the access-type of client as appropriate. If your GeoServer instance is depending on another service for authentication (eg: NGINX auth plugin) then you should probably select bearer-only. Otherwise, you should select confidential.

      4. Add the ADMINISTRATOR and AUTHENTICATED client-role to the geoserver-client in Keycloak.

        In this phase you will need to map GeoServer Roles to the geoserver-client ones in Keycloak.

        Use the AUTHENTICATED one for generic users. Assign this role ADMINISTRATOR to the users/groups who should have administrative access to GeoServer.

      5. Obtain the installation-configuration for the geoserver-client in JSON, and provide this to the GeoServer Admin for the next steps.

      As the GeoServer Admin:

      Note

      In this example the Keycloak service runs on port 8080 while GeoServer runs on port 8181

      1. Under the Authentication UI, add a new authentication-filter. Select Keycloak from the list of provided options, and name your new filter keycloak_adapter. Paste the installation-configuration from the Keycloak-server in the text area provided.

        If not present, be sure to add the following options before clicking Save:

        \"use-resource-role-mappings\": true\n

        The Enable redirect to Keycloak Login page checkbox should be checked if the desired behaviour is to authenticate on the web ui only through keycloak. Note that in this case the keycloak filter should be the only one available in the /web filter chain. On the contrary if the keycloak filter needs to coexists with other filters on the filter chain and reach it must be unchecked.

        The Role Source drop down enable the selection of the desired role source for the user being authenticated through keycloak. If none is selected by default the Active Role Service will be used.

      2. Add the keycloak_adapter to the web filter-chain if you want to protect the Admin GUI, as an instance. If you have checked Enable redirect to Keycloak Login page on the filter configuration to be redirected every time to Keycloak, then remove all of the others chain filters (basic, form, rememberme, anonymous).

      3. Once done navigate to the GeoServer UI. If at filter configuration time the checkbox Enable redirect to Keycloak Login page was kept unchecked and the keycloak filter cohexists on the /web chain with the form and anonymous filter you will see a keycloak login button that allows the user to reach the keycloak login page.

      Otherwise the user will be directly redirected to the Keycloak login-page, and after logging-in redirected back to the actual GeoServer UI page.

      You should verify that the message logged in as <USERNAME> is posted in the top right corner before continuing.

      Warning

      Workaround in the event of a 403 unauthorized response after logging-in.

      Enforce the algorithm RS256 in the keycloak client.

      Copy the public key for the RS256 algorithm from the Realm Settings into the adapter config as:

      \"realm-public-key\": XXXXXXX\n

      "},{"location":"community/keycloak/installation/","title":"Installing Keycloak","text":"

      To install the keycloak module:

      1. To obtain the keycloak community module:

        • If working with a 2.24.2 nightly build, download the module: keycloak

          Verify that the version number in the filename corresponds to the version of GeoServer you are running (for example 2.24.2 above).

        • Community modules are not yet ready for distribution with GeoServer release.

          To compile the keycloak community module yourself download the src bundle for your GeoServer version and compile:

          cd src/community\nmvn install -PcommunityRelease -DskipTests\n

          And package:

          cd src/community\nmvn assembly:single -N\n
          2. Place the JARs in WEB-INF/lib. 3. Restart GeoServer.

      "},{"location":"community/keycloak/keycloak_role_service/","title":"Keycloak Role Service","text":"

      This tutorial walks through how to set up Keycloak as a role service for GeoServer.

      Note

      In this example the Keycloak service runs on port 8080 while GeoServer runs on port 8181.

      The Keycloak Role Service uses the Keycloak REST api in order to retrieve the roles for its various operations. By default it will retrieve roles with realm scope. However it can be configured to retrieve roles with a client scope in a specific realm.

      "},{"location":"community/keycloak/keycloak_role_service/#keycloak-client-configuration","title":"Keycloak Client Configuration","text":"

      Follow the Authentication with Keycloak guide to configure GeoServer to allow logging in via Keycloak. The Keycloak Role Service needs a client to be configured on Keycloak side having Access Type set to confidential.

      If for your Keycloak Authentication Filter you have used a different Access Type i.e. barer-only, a separate client will have then to be configured for the Keycloak Role Service.

      For the client, ensure that:

      • Standard flow, implicit flow, and direct access grants are enabled
      • The base URL is set to http://localhost:8181/geoserver/web
      • The following redirect URIs are enabled:
        • http://localhost:8181/geoserver*
        • http://localhost:8080/auth/realms/master/broker/keycloak-oidc/endpoint*
      • The Access Type is set to confidential and the Service Accounts Enabled option is enabled.

      • Under the Service Account Roles tab, ensure that the realm-admin, from the realm-management client role is addedd to the Assigned roles.

      To assign a user a role:

      1. Under the users section in Keycloak, click the user's ID (if there are missing users, click \"View all users\").
      2. In the role mappings tab, select the GeoStore client from the client roles dropdown.
      3. Select the role from the available roles, and click add selected.

      An example set of role mappings for a user.

      When creating custom roles, ensure they begin with ROLE_ e.g. ROLE_STAFF.

      "},{"location":"community/keycloak/keycloak_role_service/#geoserver-configuration-for-role-syncing","title":"GeoServer Configuration for Role Syncing","text":"

      Role syncing with Keycloak will be tied to the confidential client.

      1. In GeoServer as an admin, on the 'Users, Groups, Roles' page, add a new role service.
      2. Select Keycloak from the list of provided options. All fillable fields are required, excluding the Comma separated list of ID of client (not client-id).
        • Base URL for Keycloak is the keycloak host name eg. http://localhost:8080.
        • The Realm Name is the realm from which the roles should be retrieved eg. master.
        • The Client ID can be retrieved from the Settings tab of the client configuration on Keycloak.
        • The Client secret can be retrieved from the Credentials tab of the client configuration on Keycloak.
        • The Comma separated list of ID of client (not client-id) is meant to allow the Role Service to retrieve also roles with client scope. By default indeed the Keycloak Role Service will retrieve realm roles only. The id of a client can be retrieved from the URL when viewing the client configuration page in Keycloak. URL format: eg. /auth/admin/master/console/#/realms/master/clients/{ID of client}

      Administrator Role and Group administator role dropdown should be empty at the beginning. They can be filled once saved the role service with the Keycloak role that we want to map to the GeoServer ADMIN and GROUP ADMIN.

      1. Ensure you click save to create the Keycloak role service.
      2. Once the Role Service has been created and configured to have it active:
        • it can be assigned as a RoleSource to the Keycloak Filter,
        • it can be set as the Active Role Service in the Security Settings page.

      An example of a fully configured Keycloak role service.

      "},{"location":"community/keycloak/keycloak_role_service/#geoserver-configuration-for-keycloak-authentication-filters","title":"GeoServer Configuration for Keycloak Authentication Filters","text":"

      Under the Authentication section of GeoServer:

      • Add the Keycloak authentication filter to the top of the web and default filter chains.
      • Add keycloak to the selected provider chains, and place it above the default.
      "},{"location":"community/libdeflate/","title":"Libdeflate","text":"

      Support for alternative Deflate encoder/decoder provided through libdeflate JNI bindings for Java which provides better performance.

      • Reading can be 10% - 20% faster
      • Writing can be 40% - 60% faster

      (Tests have been made on deflate input data stored on SSD disk so neither Disk I/O, nor Network transfer was the bottleneck)

      "},{"location":"community/libdeflate/#installation","title":"Installation","text":"

      As a community module, the package needs to be downloaded from the nightly builds, picking the community folder of the corresponding GeoServer series (e.g. if working on the GeoServer main development branch nightly builds, pick the zip file form main/community-latest).

      To install the module, unpack the zip file contents into the GeoServer WEB-INF/lib directory and restart GeoServer.

      When the community module is not installed, the TIFF Deflate compression/decompression goes through ZLIB based ZIP Deflater and Inflater counterpart. Once the community module plugin is installed, TIFF Deflate compression/decompression goes through libdeflate by default. This can be however customized, by changing the plugin priority in the Global Settings page of GeoServer.

      "},{"location":"community/libdeflate/#global-settings","title":"Global Settings","text":"

      Default ZIP Deflater compression plugin has priority 50. Libdeflate compression plugin has default priority 80 for both compression and decompression. Is it possible to fallback to the old plugin for either compression, decompression or both. Go to the Global Settings and set the priority to a value lower than 50.

      Default Libdeflate compression Settings

      Finally, during testing phases, we found that, at compression level 9, the old plugin is faster than the new one. By default, when priority is higher, the Libdeflate compression will be only used for compression levels in the range 1 to 8. These settings can be modified in the above Global Settings too.

      "},{"location":"community/libdeflate/#current-limitations","title":"Current limitations","text":"

      The current available version is 0.1.0-beta which only contains linux libraries.

      "},{"location":"community/mbtiles/","title":"MBTiles Extension","text":"

      This plugin brings in the ability to read and write MBTiles files in GeoServer. MBTiles is an SQLite based standard format that is able to hold a single tiles map layer in a file.

      MBTiles can both be used as a raster input datastore as well as an WMS GetMap output format.

      • Installing the GeoServer MBTiles extension
      • MBTiles Raster and Vector Data Stores
      • MBTiles Output Format
      "},{"location":"community/mbtiles/input/","title":"MBTiles Raster and Vector Data Stores","text":""},{"location":"community/mbtiles/input/#adding-an-mbtiles-mosaic-raster-data-source","title":"Adding an MBTiles Mosaic Raster Data Source","text":"

      When the extension has been installed, :guilabel:MBTiles` will be an option in the Raster Data Sources list when creating a new data store.

      MBTiles in the list of raster data sources

      Configuring an MBTiles data source

      Option Description

      Workspace Name of the workspace to contain the MBTiles Mosaic store. This will also be the prefix of the raster layers created from the store.

      Data Source Name Name of the MBTiles Store as it will be known to GeoServer. This can be different from the filename.

      Description A full free-form description of the MBTiles store.

      Enabled If checked, it enables the store. If unchecked (disabled), no data in the GeoPackage Mosaic Store will be served from GeoServer.

      URL Location of the MBTiles file. This can be an absolute path (such as file:C:\\Data\\landbase.mbtiles) or a path relative to GeoServer's data directory (such as file:data/landbase.mbtiles).

      "},{"location":"community/mbtiles/input/#adding-an-mbtiles-vector-tiles-data-store","title":"Adding an MBTiles vector tiles Data Store","text":"

      When the extension has been installed, MBTiles with vector tiles will be an option in the Vector Data Sources list when creating a new data store.

      MBTiles in the list of vector data sources

      Configuring an MBTiles data store

      Option Description

      database Path to the MBTiles file

      user Optional username

      passwd Optional password

      After configuration the store will allow setting up the layers, as they get described in the json entry of the metadata table.

      Configuring layers out of a MBTiles store

      Each vector tile contains data for all the layers described, the store maintains a \"soft cache\" of parsed tiles to avoid re-parsing them from the binary on multi-layer rendering operations.

      "},{"location":"community/mbtiles/installing/","title":"Installing the GeoServer MBTiles extension","text":"

      Warning

      Make sure to match the version of the extension to the version of the GeoServer instance!

      1. Download the extensions from the nightly GeoServer community module builds.

        1. Download the mbtiles-store-plugin from mbtiles-store if you simply want to read MBTiles files.
        2. Download the mbtiles-plugin from mbtiles if you also want to use the WMS output format generaring MBTiles and the WPS process doing the same. Make sure to install corresponding WPS extension for GeoServer instance before installing this plugin, or GeoServer won't start.
      2. Extract the contents of the archive into the WEB-INF/lib directory of the GeoServer installation.

      "},{"location":"community/mbtiles/output/","title":"MBTiles Output Format","text":""},{"location":"community/mbtiles/output/#mbtiles-wms-output-format","title":"MBTiles WMS Output Format","text":"

      Any WMS GetMap request can be returned in the form of a Geopackage by specifying format=mbtiles as output format (see WMS output formats). The returned result will be an MBTiles file with a single tile layer.

      The following additional parameters can be passed on using format_options:
      • tileset_name: name to be used for tileset in mbtiles file (default is name of layer(s)).
      • min_zoom, max_zoom, min_column, max_column, min_row, max_row: set the minimum and maximum zoom level, column, and rows
      • gridset: name of gridset to use (otherwise default for CRS is used)

      Warning

      The GetMap request won't be subject to any execution time limit, a client can thus make request that will takes very long times to execute by providing a high max_zoom value.

      "},{"location":"community/mbtiles/output/#mbtiles-wps-process","title":"MBTiles WPS Process","text":"

      It is possible to generate an mbtiles file by calling the WPS process gs:MBTiles. This process requires the following parameters:

      • layername: Name of the input layer.
      • format : format of the final images composing the file.
      • minZoom, maxZoom, minColumn, maxColumn, minRow, maxRow: (Optional) set the minimum and maximum zoom level, column, and rows.
      • boundingbox: (Optional) Bounding box of the final mbtiles. If CRS is not set, the layer native one is used.
      • filename: (Optional) name of the mbtiles file created.
      • bgColor: (Optional) value associated to the background colour.
      • transparency: (Optional) parameter indicating if the transparency must be present.
      • stylename, stylepath, stylebody: (Optional) style to associate to the layer. Only one of these 3 parameters can be used.

      The process returns an URL containing the path of the generated file.

      Warning

      The process implementation does not currently support cancellation, a client can thus make request that will takes very long times to execute by providing a high max_zoom value.

      "},{"location":"community/monitor-hibernate/","title":"Monitoring Hibernate storage","text":"

      The monitor hibernate storage allows to track the requests made against a GeoServer instance in a relational database, as opposed to keeping the data in memory for a short time, or logging it on a audit file.

      • Installing the Hibernate Monitor Extension
      • Hibernate storage Configuration
      • Database Persistence
      • Upgrading
      "},{"location":"community/monitor-hibernate/configuration/","title":"Hibernate storage Configuration","text":"

      Many aspects of the monitor extension are configurable. The configuration files are stored in the data directory under the monitoring directory:

      <data_directory>\n    monitoring/\n        db.properties\n        hibernate.properties\n

      In particular: * db.properties - Database configuration when using database persistence. * hibernate.properties - Hibernate configuration when using database persistence.

      "},{"location":"community/monitor-hibernate/configuration/#monitor-storage","title":"Monitor Storage","text":"

      How request data is persisted is configurable via the storage property defined in the monitor.properties file. The following values are supported for the storage property:

      • memory - Request data is to be persisted in memory alone.
      • hibernate - Request data is to be persisted in a relational database via Hibernate.

      The default value is memory, in order to use hibernate the storage configuration needs to be switced to hibernate.

      "},{"location":"community/monitor-hibernate/db/","title":"Database Persistence","text":"

      The monitor extension is capable of persisting request data to a database via the Hibernate library.

      Note

      In order to utilize hibernate persistence the hibernate extension must be installed on top of the core monitoring extension. See the Installing the Monitor Extension for details.

      "},{"location":"community/monitor-hibernate/db/#configuration","title":"Configuration","text":""},{"location":"community/monitor-hibernate/db/#general","title":"General","text":"

      In order to activate hibernate persistence the storage parameter must be set to the value \"hibernate\":

      storage=hibernate\n

      The hibernate storage backend supports both the history and live modes however care should be taken when enabling the live mode as it results in many transactions with the database over the life of a request. Unless updating the database in real time is required the history mode is recommended.

      "},{"location":"community/monitor-hibernate/db/#database","title":"Database","text":"

      The file db.properties in the <GEOSERVER_DATA_DIR>/monitoring directory specifies the Hibernate database. By default an embedded H2 database located in the monitoring directory is used. This can be changed by editing the db.properties file:

      # default configuration is for h2 \ndriver=org.h2.Driver\nurl=jdbc:h2:file:${GEOSERVER_DATA_DIR}/monitoring/monitoring\n

      For example to store request data in an external PostgreSQL database, set db.properties to:

      driver=org.postgresql.Driver \nurl=jdbc:postgresql://192.168.1.124:5432/monitoring\nusername=bob\npassword=foobar\ndefaultAutoCommit=false\n

      In addition to db.properties file is the hibernate.properties file that contains configuration for Hibernate itself. An important parameter of this file is the hibernate dialect that informs hibernate of the type of database it is talking to.

      When changing the type of database both the databasePlatform and database parameters must be updated. For example to switch to PostgreSQL:

      # hibernate dialect\ndatabasePlatform=org.hibernate.dialect.PostgreSQLDialect\ndatabase=POSTGRESQL\n\n# other hibernate configuration\nhibernate.use_sql_comments=true\ngenerateDdl=true\nhibernate.format_sql=true\nshowSql=false\nhibernate.generate_statistics=true\nhibernate.session_factory_name=SessionFactory\nhibernate.hbm2ddl.auto=update\nhibernate.bytecode.use_reflection_optimizer=true\nhibernate.show_sql=false\n
      "},{"location":"community/monitor-hibernate/db/#hibernate","title":"Hibernate","text":"

      As mentioned in the previous section the hibernate.properties file contains the configuration for Hibernate itself. Aside from the database dialect parameters it is not recommended that you change this file unless you are an experienced Hibernate user.

      "},{"location":"community/monitor-hibernate/installation/","title":"Installing the Hibernate Monitor Extension","text":"

      Note

      If performing an upgrade of the monitor extension please see Upgrading.

      As a community module, the package needs to be downloaded from the nightly builds, picking the community folder of the corresponding GeoServer series (e.g. if working on GeoServer main development branch nightly builds, pick the zip file form main/community-latest).

      To install the module, unpack the zip file contents into GeoServer own WEB-INF/lib directory and restart GeoServer.

      For the module to work, the Monitoring extensions must also be installed.

      "},{"location":"community/monitor-hibernate/upgrade/","title":"Upgrading","text":"

      The monitoring extension uses Hibernate to persist request data. Changes to the extension over time affect the structure of the underlying database, which should be taken into consideration before performing an upgrade. Depending on the nature of changes in an upgrade, it may involve manually making changes to the underlying database before deploying a new version of the extension.

      The sections below provides a history of such changes, and recommended actions that should be taken as part of the upgrade. Upgrades are grouped into two categories:

      • minor upgrades that occur during a minor GeoServer version change, for example going from 2.1.2 to 2.1.3. These changes are backward compatible in that no action is specifically required but potentially recommended. In these cases performing an upgrade without any action still result in the monitoring extension continuing to function.
      • major upgrades that occur during a major GeoServer version change, for example going from 2.1.2 to 2.2.0. These changes may be backward compatible, but not necessarily. In these cases performing an upgrade without any action could potentially result in the monitoring extension ceasing to function, and may result in significant changes to the underlying database.

      For each change the following information is maintained:

      • The released version containing the change
      • The date of the change
      • The subversion revision of the change
      • The jira issue referring to the change

      The date and subversion revision are especially useful if a nightly build of the extension is being used.

      "},{"location":"community/monitor-hibernate/upgrade/#minor-upgrades","title":"Minor upgrades","text":""},{"location":"community/monitor-hibernate/upgrade/#column-resource-renamed-to-name-in-request_resources-table","title":"Column resource renamed to name in request_resources table","text":"
      • Version: n/a, extension still community status
      • Date: Dec 09, 2011
      • Subversion revision: 16632
      • Reference: GEOS-4871

      Upgrading without performing any action will result in the name column being added to the request_resources table, leaving the resource column intact. From that point forward the resource column will essentially be ignored. However no data from the resource column will be migrated, which will throw off reports, resource access statistics, etc... If you wish to migrate the data perform one of the following actions two actions.

      The first is a pre upgrade action that involves simply renaming the column before deploying the new monitoring extension:

      ALTER TABLE request_resources RENAME COLUMN resource to name;\n

      Alternatively the migration may occur post upgrade:

      UPDATE TABLE request_resources SET name = resource where name is NULL;\nALTER TABLE request_resources DROP COLUMN resource;\n
      "},{"location":"community/monitor-hibernate/upgrade/#column-remote_user_agent-added-to-request-table","title":"Column remote_user_agent added to request table","text":"
      • Version: n/a, extension still community status
      • Date: Dec 09, 2011
      • Subversion revision: 16634
      • Reference: GEOS-4872

      No action should be required here as Hibernate will simply append the new column to the table. If for some reason this does not happen the column can be added manually:

      ALTER TABLE request ADD COLUMN remote_user_agent VARCHAR(1024);\n
      "},{"location":"community/monitor-hibernate/upgrade/#major-upgrades","title":"Major upgrades","text":""},{"location":"community/monitor-kafka/","title":"Monitoring Kafka storage","text":"

      The Monitor Kafka storage extension allows to track the requests made against a GeoServer instance in an Apache Kafka topic, as opposed to keeping the data in memory for a short time, or logging it on a audit file.

      • Installing the Kafka Monitor Extension
      • Kafka storage Configuration
      • Usage of Monitoring Kafka extension
      • Message keys are not supported. This means that the messages will be distributed in a round robbin fashion between the partitions.
      • The extension tries to connect and describe the topic at startup, if the topic does not exist or the connection cannot be established the extension will fail to start and disable itself. Subsequent requests to this instance will not be logged. The timeout for the describe command is set to 10 seconds.
      • The only used serialization format is avro. Avro might be used in other extensions like geomesa where a conflict with the version of kafka-avro library might be possible.
      Permissions

      The Kafka extension needs the following permissions on the Kafka topic in order to work:

      • DESCRIBE
      • WRITE
      "},{"location":"community/monitor-kafka/configuration/","title":"Kafka storage Configuration","text":"

      Many aspects of the monitor extension are configurable. The configuration files are stored in the data directory under the monitoring directory:

      <data_directory>\n    monitoring/\n        monitor.properties\n

      In particular:

      • monitor.properties - Can be extended to set the connection details to Apache Kafka.
      "},{"location":"community/monitor-kafka/configuration/#monitor-storage","title":"Monitor Storage","text":"

      How request data is persisted is configurable via the storage property defined in the monitor.properties file. The following values are supported for the storage property:

      • memory - Request data is to be persisted in memory alone.
      • hibernate - Request data is to be persisted in a relational database via Hibernate.
      • kafka - Request data is to be persisted in Apache Kafka.

      The default value is memory, in order to use Apache Kafka the storage configuration needs to be switched to kafka.

      In addition you can set the topic name with the kafka.topic property. The default value is geoserver-monitor.

      You can set all the Kafka properties for a kafka producer by prefixing it with the kafka keyword e.g. set the acks to 1 with kafka.acks=1. For further details on the Kafka producer properties see the Kafka documentation.

      The following is an example of the monitor.properties file configured to use Apache Kafka:

      storage=kafka\n... other properties ...\nkafka.bootstrap.servers=localhost:9092\nkafka.topic=monitor\nkafka.acks=1\nkafka.retries=3\nkafka.batch.size=65536\nkafka.linger.ms=200\nkafka.compression.type=snappy\nkafka.schema.registry.url=http://localhost:8081\n

      In order to use Confluent Cloud you need to configure these properties:

      storage=kafka\n... other properties ...\nkafka.bootstrap.servers=pkc-def12.europe-west.gcp.confluent.cloud:9092\nkafka.topic=monitor\nkafka.security.protocol=SASL_SSL\nkafka.sasl.mechanism=PLAIN\nkafka.sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required username='KAFKA_API_KEY' password='KAFKA_SECRET';\nkafka.schema.registry.url=https://psrc-abc12.europe-west.gcp.confluent.cloud\nkafka.schema.registry.basic.auth.credentials.source=USER_INFO\nkafka.schema.registry.basic.auth.user.info=SR_API_KEY:SR_API_SECRET\n\nkafka.acks=1\nkafka.retries=0\nkafka.batch.size=65536\nkafka.linger.ms=200\nkafka.compression.type=snappy\n

      It might be a good idea to set the kafka.linger.ms to avoid too many requests to the Kafka broker and get the benefits from batching and compression. One request can cause multiple messages to be sent to Kafka as a load of multiple tiles may does. Also the compressions should be quite effective as the messages repeat some data. Make sure to also set the kafka.compression.type.

      "},{"location":"community/monitor-kafka/installation/","title":"Installing the Kafka Monitor Extension","text":"

      As a community module, the package needs to be downloaded from the nightly builds, picking the community folder of the corresponding GeoServer series (e.g. if working on GeoServer main development branch nightly builds, pick the zip file form main/community-latest).

      To install the module, unpack the zip file contents into GeoServer own WEB-INF/lib directory and restart GeoServer.

      For the module to work, the Monitoring extensions must also be installed.

      "},{"location":"community/monitor-kafka/usage/","title":"Usage of Monitoring Kafka extension","text":"

      To try out there is a docker-compose.yml file in the test/resources directory. This will start up a Kafka broker and a schema registry instance. To start it up you need docker and docker-compose installed then run:

      # start kafka\ncd src/community/monitor-kafka/src/test/resources\ndocker-compose up -d\n

      This will start up the Kafka broker and the schema registry.

      Once Kafka is running start geoserver with monitor and monitor-kafka extension from src/web/app:

      mvn jetty:run -P monitor,monitor-kafka\n

      This will initialize the data directory in src/web/app/src/main/webapp/data and start up geoserver. Stop the geoserver again.

      With this you will get the default monitor config installed automatically in src/web/app/src/main/webapp/data/monitoring/. Edit it to use the Kafka storage.

      Then you need to configure the monitor-kafka extension for it with:

      storage=kafka\nkafka.bootstrap.servers=localhost:9092\nkafka.schema.registry.url=http://localhost:8081\n

      Create your topic with:

      docker exec -ti broker kafka-topics --bootstrap-server localhost:9092 --create --topic geoserver-monitor --partitions 1 --replication-factor 1 --if-not-exists\n

      Start geoserver again with:

      mvn jetty:run -P monitor,monitor-kafka\n

      Check that the monitoring extension is actually enabled by looking for the following log line:

      INFO   [geoserver.monitor] - Kafka connection established and topic geoserver-monitor exists\n

      Head over to http://localhost:8080/geoserver and hit some map, so you get some data into the topic.

      If you want to consume the data you need a consumer which has the right Deserializer configured (io.confluent.kafka.serializers.KafkaAvroDeserializer).

      The easiest way to do this is to enter the schema registry container with:

      docker exec -ti schema-registry bash\n# from within the container run:\n  kafka-avro-console-consumer \\\n    --bootstrap-server broker:29092 \\\n    --topic geoserver-monitor \\\n    --from-beginning\n\n# or directly from the host machine so you can pipe it into jq or a file...\ndocker exec -ti schema-registry kafka-avro-console-consumer \\\n    --bootstrap-server broker:29092 \\\n    --topic geoserver-monitor \\\n    --from-beginning | tee >(grep -E \"^{\" | jq) | grep -vE \"^{\"\n

      Then you will see messages like this:

      {\n    \"id\": 2,\n    \"status\": \"FINISHED\",\n    \"category\": \"OWS\",\n    \"path\": \"/tiger/wms\",\n    \"queryString\": \"SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&FORMAT=image/png&TRANSPARENT=true&STYLES&LAYERS=tiger:giant_polygon&exceptions=application/vnd.ogc.se_inimage&SRS=EPSG:4326&WIDTH=768&HEIGHT=384&BBOX=3.7958354296875,-40.4131489453125,71.2627583203125,-6.6962260546875\",\n    \"body\": \"\",\n    \"bodyContentLength\": 0,\n    \"bodyContentType\": \"\",\n    \"httpMethod\": \"GET\",\n    \"startTime\": 1697172148809,\n    \"endTime\": 1697172148902,\n    \"totalTime\": 93,\n    \"remoteAddress\": \"[0:0:0:0:0:0:0:1]\",\n    \"remoteHost\": \"0:0:0:0:0:0:0:1\",\n    \"host\": \"localhost\",\n    \"internalHost\": \"client\",\n    \"remoteUser\": \"anonymous\",\n    \"remoteUserAgent\": \"Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/117.0.0.0 Safari/537.36\",\n    \"remoteCountry\": \"\",\n    \"remoteCity\": \"\",\n    \"remoteLat\": 0.0,\n    \"remoteLon\": 0.0,\n    \"service\": \"WMS\",\n    \"operation\": \"GetMap\",\n    \"owsVersion\": \"1.1.1\",\n    \"subOperation\": \"\",\n    \"resources\": [\n        \"tiger:giant_polygon\"\n    ],\n    \"responseLength\": 6594,\n    \"responseContentType\": \"image/png\",\n    \"errorMessage\": \"\",\n    \"responseStatus\": 0,\n    \"httpReferer\": \"\",\n    \"coordinateReferenceSystem\": \"EPSG:WGS 84\",\n    \"minx\": 3.7958354296875,\n    \"miny\": -40.4131489453125,\n    \"maxx\": 71.2627583203125,\n    \"maxy\": -6.6962260546875,\n    \"cacheResult\": \"\",\n    \"missReason\": \"\",\n    \"resourceProcessingTimes\": [],\n    \"labelingProcessingTime\": 0\n}\n{\n    \"id\": 3,\n    \"status\": \"FINISHED\",\n    \"category\": \"OWS\",\n    \"path\": \"/tiger/wms\",\n    \"queryString\": \"SERVICE=WMS&VERSION=1.1.1&REQUEST=GetFeatureInfo&FORMAT=image/png&TRANSPARENT=true&QUERY_LAYERS=tiger:giant_polygon&STYLES&LAYERS=tiger:giant_polygon&exceptions=application/vnd.ogc.se_inimage&INFO_FORMAT=text/html&FEATURE_COUNT=50&X=50&Y=50&SRS=EPSG:4326&WIDTH=101&HEIGHT=101&BBOX=39.23891004908502,-32.22561743843973,48.11586317408502,-23.348664313439727\",\n    \"body\": \"\",\n    \"bodyContentLength\": 0,\n    \"bodyContentType\": \"\",\n    \"httpMethod\": \"GET\",\n    \"startTime\": 1697172178181,\n    \"endTime\": 1697172178213,\n    \"totalTime\": 32,\n    \"remoteAddress\": \"[0:0:0:0:0:0:0:1]\",\n    \"remoteHost\": \"\",\n    \"host\": \"localhost\",\n    \"internalHost\": \"client\",\n    \"remoteUser\": \"anonymous\",\n    \"remoteUserAgent\": \"Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/117.0.0.0 Safari/537.36\",\n    \"remoteCountry\": \"\",\n    \"remoteCity\": \"\",\n    \"remoteLat\": 0.0,\n    \"remoteLon\": 0.0,\n    \"service\": \"WMS\",\n    \"operation\": \"GetFeatureInfo\",\n    \"owsVersion\": \"1.1.1\",\n    \"subOperation\": \"\",\n    \"resources\": [\n        \"giant_polygon\"\n    ],\n    \"responseLength\": 803,\n    \"responseContentType\": \"text/html;charset=utf-8\",\n    \"errorMessage\": \"\",\n    \"responseStatus\": 0,\n    \"httpReferer\": \"\",\n    \"coordinateReferenceSystem\": \"EPSG:WGS 84\",\n    \"minx\": 43.63344129908502,\n    \"miny\": -27.743195563439727,\n    \"maxx\": 43.63344129908502,\n    \"maxy\": -27.743195563439727,\n    \"cacheResult\": \"\",\n    \"missReason\": \"\",\n    \"resourceProcessingTimes\": [],\n    \"labelingProcessingTime\": 0\n}\n
      "},{"location":"community/ncwms/","title":"ncWMS WMS extensions support","text":"

      The ncWMS module adds to GeoServer the ability to support some of the ncWMS extensions to the WMS protocol and configuration. In particular:

      • Ability to create a named style by simply providing a list of colors, that will adapt to the layer in use based on request parameters and its statistics
      • Ability to control the palette application in GetMap via a number of extra parameters
      • GetTimeSeries operation, which can retrieve a CSV or an xy chart of a time series of values on a certain point

      At the time of writing the extra calls to extract elevation series, transects and NetCDF metadata are not supported. The extension is however not NetCDF specific, but can be used with any single banded raster layer instead.

      "},{"location":"community/ncwms/#the-dynamic-palette-style-format","title":"The Dynamic Palette style format","text":"

      A new \"Dynamic palette\" style format has been added that accepts a palette, one color per line, defining a color progression to be applied on raster data. Each color can be defined using these possible syntaxes (same as ncWMS):

      • #RRGGBB
      • #AARRGGBB
      • 0xRRGGBB
      • 0xAARRGGBB

      Comments can be added in the file by starting the line by a percentage sign. For example, a red to blue progression might look like:

      % Red to blue progression\n#FF0000\n#0000FF\n

      Configuring a dynamic palette style

      Several ready to use palettes coming from the popular \"color brewer\" site are available in the ncWMS source code repository.

      The palette translates on the fly into a SLD with rendering transformation using the Dynamic colormap generation module, in particular, the above style translates to the following style:

      <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<sld:StyledLayerDescriptor xmlns=\"http://www.opengis.net/sld\" xmlns:sld=\"http://www.opengis.net/sld\" xmlns:gml=\"http://www.opengis.net/gml\" xmlns:ogc=\"http://www.opengis.net/ogc\" version=\"1.0.0\">\n  <sld:NamedLayer>\n    <sld:Name/>\n    <sld:UserStyle>\n      <sld:Name/>\n      <sld:FeatureTypeStyle>\n        <sld:Transformation>\n          <ogc:Function name=\"ras:DynamicColorMap\">\n            <ogc:Function name=\"parameter\">\n              <ogc:Literal>data</ogc:Literal>\n            </ogc:Function>\n            <ogc:Function name=\"parameter\">\n              <ogc:Literal>opacity</ogc:Literal>\n              <ogc:Function name=\"env\">\n                <ogc:Literal>OPACITY</ogc:Literal>\n                <ogc:Literal>1.0</ogc:Literal>\n              </ogc:Function>\n            </ogc:Function>\n            <ogc:Function name=\"parameter\">\n              <ogc:Literal>colorRamp</ogc:Literal>\n              <ogc:Function name=\"colormap\">\n                <ogc:Literal>rgb(255,0,0);rgb(0,0,255)</ogc:Literal>\n                <ogc:Function name=\"env\">\n                  <ogc:Literal>COLORSCALERANGE_MIN</ogc:Literal>\n                  <ogc:Function name=\"bandStats\">\n                    <ogc:Literal>0</ogc:Literal>\n                    <ogc:Literal>minimum</ogc:Literal>\n                  </ogc:Function>\n                </ogc:Function>\n                <ogc:Function name=\"env\">\n                  <ogc:Literal>COLORSCALERANGE_MAX</ogc:Literal>\n                  <ogc:Function name=\"bandStats\">\n                    <ogc:Literal>0</ogc:Literal>\n                    <ogc:Literal>maximum</ogc:Literal>\n                  </ogc:Function>\n                </ogc:Function>\n                <ogc:Function name=\"env\">\n                  <ogc:Literal>BELOWMINCOLOR</ogc:Literal>\n                  <ogc:Literal>rgba(0,0,0,0)</ogc:Literal>\n                </ogc:Function>\n                <ogc:Function name=\"env\">\n                  <ogc:Literal>ABOVEMAXCOLOR</ogc:Literal>\n                  <ogc:Literal>rgba(0,0,0,0)</ogc:Literal>\n                </ogc:Function>\n                <ogc:Function name=\"env\">\n                  <ogc:Literal>LOGSCALE</ogc:Literal>\n                  <ogc:Literal>false</ogc:Literal>\n                </ogc:Function>\n                <ogc:Function name=\"env\">\n                  <ogc:Literal>NUMCOLORBANDS</ogc:Literal>\n                  <ogc:Literal>254</ogc:Literal>\n                </ogc:Function>\n              </ogc:Function>\n            </ogc:Function>\n          </ogc:Function>\n        </sld:Transformation>\n        <sld:Rule>\n          <sld:RasterSymbolizer/>\n        </sld:Rule>\n      </sld:FeatureTypeStyle>\n    </sld:UserStyle>\n  </sld:NamedLayer>\n</sld:StyledLayerDescriptor>\n

      The above explains a bit of how the palette is applied:

      • By default a palette of 254 colors is generated between a min and max value, plus one color for anything below the minimum and another for anything above the maximum
      • It is possible to pass the minimum and maximum values using the GetMap env parameter, if not provided, they are fetched from the configured band statistics (as found in the layer configuration)
      • The overall opacity of the palette can be controlled (using a value between 0 and 1 to conform with the SLD opacity description)
      • The scale can be either linear, or logarithmic

      Editing the defaults for min/max scale range values in the GeoServer layer editor

      The above parameters can all be used at will to control the palette generation using the typical environment variable approach. However, it's also possible to use ncWMS own extensions, which are adding direct parameters in the request. See the following section for details.

      "},{"location":"community/ncwms/#ncwms-getmap-extensions","title":"ncWMS GetMap extensions","text":"

      This module also adds a dynamic translator taking the ncWMS GetMap vendor parameters and mapping them to the dynamic palette expectations. In particular (copying the parameter description from the ncWMS manual, with GeoServer specific annotations):

      • COLORSCALERANGE: Of the form min,max this is the scale range used for plotting the data (mapped to the COLORSCALERANGE_MIN and COLORSCALERANGE_MAX env vars)
      • NUMCOLORBANDS: The number of discrete colours to plot the data. Must be between 2 and 250 (mapped to the NUMCOLORBANDS env variable)
      • ABOVEMAXCOLOR: The colour to plot values which are above the maximum end of the scale range. Colours are of the form 0xRRGGBB or 0xAARRGGBB, and it also accepts \"transparent\" and \"extend\"
      • BELOWMINCOLOR: The colour to plot values which are below the minimum end of the scale range. Colours are of the form 0xRRGGBB or 0xAARRGGBB, and it also accepts \"transparent\" and \"extend\"
      • LOGSCALE: \"true\" or \"false\" - whether to plot data with a logarithmic scale
      • OPACITY: The percentage opacity of the final output image as a number between 0 and 100 (maps to OPACITY env var by translating it to a number between 0 and 1)
      • ANIMATION: \"true\" or \"false\" - whether to generate an animation. The ncWMS documentation states that TIME has to be of the form starttime/endtime, but currently TIME needs to be a list of discrete times instead. Animation requires using the \"image/gif\" as the response format (as the only format supporting animation)

      Here are a few examples based on the \"ArcSample\" arcgrid sample layer, containing annual precipitation data. The one band provided by this layer has been configured with a default range of 0 to 6000.

      • Default output with the \"redblue\" palette:

        http://localhost:8080/geoserver/wms?STYLES=redblue&LAYERS=nurc%3AArc_Sample&FORMAT=image%2Fpng&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&SRS=EPSG%3A4326&BBOX=-180,-90,180,90&WIDTH=500&HEIGHT=250

      • Adopting a logarithmic scale by adding &COLORSCALERANGE=1,6000&LOGSCALE=true (a logarithmic scale needs a positive minimum)

      • Using just 5 colors in logarithmic mode by adding &COLORSCALERANGE=1,6000&LOGSCALE=true&NUMCOLORBANDS=5

      • Limiting the range and specifying other colors above (gray) and below (yellow) by adding &COLORSCALERANGE=100,2000&BELOWMINCOLOR=0xFFFF00&ABOVEMAXCOLOR=0xAAAAAA

      "},{"location":"community/ncwms/#ncwms-getcapabilities-extensions","title":"ncWMS GetCapabilities extensions","text":"

      ncWMS allows users to filter the contents of a capabilities document by adding a &dataset=datasetName parameter to the request.

      While GeoServer does not have a concept of dataset, the ncWMS extension allows to use the same parameter to filter on workspaces, layers and layer groups, by name.

      For example:

      • Getting everything in the \"topp\" workspace: http://localhost:8080/geoserver/ows?service=wms&version=1.3.0&request=GetCapabilities&dataset=topp
      • Getting only the \"topp:states\" layer: http://localhost:8080/geoserver/ows?service=wms&version=1.3.0&request=GetCapabilities&dataset=topp:states
      • Getting the \"tasmania\" layer group: http://localhost:8080/geoserver/ows?service=wms&version=1.3.0&request=GetCapabilities&dataset=tasmania
      "},{"location":"community/ncwms/#ncwms-gettimeseries-operation","title":"ncWMS GetTimeSeries operation","text":"

      ncWMS provides a GetTimeSeries operation, which can retrieve a time series of values on a certain point, using a syntax similar to the GetFeatureInfo operation. The time series can be retrieved as a chart in PNG or JPEG image, or as a CSV.

      For example:

      • Getting a time series as CSV: http://localhost:8080/geoserver/wms?SERVICE=WMS&VERSION=1.1.1&REQUEST=GetTimeSeries&FORMAT=image%2Fjpeg&TIME=2008-10-31T00:00:00.000Z/2008-11-01T00:00:00.000Z&QUERY_LAYERS=watertemp&STYLES&LAYERS=watertemp&INFO_FORMAT=text%2Fcsv&FEATURE_COUNT=50&X=50&Y=50&SRS=EPSG%3A4326&WIDTH=101&HEIGHT=101&BBOX=3.724365234375%2C40.81420898437501%2C5.943603515625%2C43.03344726562501
      • Getting a time series as PNG: http://localhost:8080/geoserver/wms?SERVICE=WMS&VERSION=1.1.1&REQUEST=GetTimeSeries&FORMAT=image%2Fjpeg&TIME=2008-10-31T00:00:00.000Z/2008-11-01T00:00:00.000Z&QUERY_LAYERS=watertemp&STYLES&LAYERS=watertemp&INFO_FORMAT=image%2Fpng&FEATURE_COUNT=50&X=50&Y=50&SRS=EPSG%3A4326&WIDTH=101&HEIGHT=101&BBOX=3.724365234375%2C40.81420898437501%2C5.943603515625%2C43.03344726562501
      • Getting a time series as JPG: http://localhost:8080/geoserver/wms?SERVICE=WMS&VERSION=1.1.1&REQUEST=GetTimeSeries&FORMAT=image%2Fjpeg&TIME=2008-10-31T00:00:00.000Z/2008-11-01T00:00:00.000Z&QUERY_LAYERS=watertemp&STYLES&LAYERS=watertemp&INFO_FORMAT=image%2Fjpg&FEATURE_COUNT=50&X=50&Y=50&SRS=EPSG%3A4326&WIDTH=101&HEIGHT=101&BBOX=3.724365234375%2C40.81420898437501%2C5.943603515625%2C43.03344726562501

      The INFO_FORMAT accepts the following values: image/png, image/jpg and text/csv

      The TIME parameter accepts a time range as defined for other operations in the WMS standard (see Annex D of the 06-042 Web Map Server Implementation Specification). Examples:

      • TIME=2008-10-31T00:00:00.000Z/2008-11-01T00:00:00.000Z
      • TIME=2008-10-31T00:00:00.000Z/2008-10-31T00:00:00.000Z

      Since GeoServer 2.17, TIME parameter also supports 2 additional syntax even if not expressly supported by ncWMS specification:

      1. A List of Times:
        • Example: TIME=2014-01,2015-01,2016-01,2017-01,2018-01
        • Example: TIME=2017-01-01T00:00:00Z,2017-02-01T00:00:00Z,2017-01-03T00:00:00Z
      2. A periodic time within a range:
        • Example: TIME=2015-01/2019-01/P1Y

      ::: note ::: title Note :::

      • Shortened time specifications in a list are parsed as time ranges by GeoServer. Therefore, a Time like 2014-01 will represent the whole month of January 2014, so a time range: 2014-01-01T00:00:00/2014-01-31T23:59:59.

      • Months and Years expressed through a Period specification (as an instance P2M, P1Y) are considered made of 30 days and 365.25 days respectively. Therefore a periodic interval like 2000-04/2000-12/P1M will be parsed as the list of time instants starting from April 2000 through December 2000 with a period of 30 days:

        • Apr 01 00:00:00 2000
        • May 01 00:00:00 2000
        • May 31 00:00:00 2000
        • Jun 30 00:00:00 2000
        • Jul 30 00:00:00 2000
        • Aug 29 00:00:00 2000
        • Sep 28 00:00:00 2000
        • Oct 28 00:00:00 2000
        • Nov 27 00:00:00 2000
        • Dec 27 00:00:00 2000
        • Therefore if your original dataset has an entry for the first day of each month, this request will only return 2 values: Apr 01 and May 01. In that case, you might consider enabling nearest match on Layer's time dimension. :::

      Sample CSV output:

      # Latitude: 40.396728515625\n# Longitude: -0.6921386718750019\nTime (UTC),Temperature (degrees)\n2014-01-01T00:00:00.000Z,0.4194810092449188\n2014-02-01T00:00:00.000Z,0.8373379707336426\n2014-03-01T00:00:00.000Z,3.1670899391174316\n2014-04-01T00:00:00.000Z,4.932330131530762\n

      Sample chart output:

      Note: Since GeoServer 2.17, nodata pixels will not be reported in the result chart. Moreover, entries in CSV list related to nodata pixels will report time but will have no pixel value reported, as in the example below for times 2014-02-01 and 2014-05-01:

      # Latitude: 40.396728515625\n# Longitude: -0.6921386718750019\nTime (UTC),Temperature (degrees)\n2014-01-01T00:00:00.000Z,0.4194810092449188\n2014-02-01T00:00:00.000Z,\n2014-03-01T00:00:00.000Z,3.1670899391174316\n2014-04-01T00:00:00.000Z,4.932330131530762\n2014-05-01T00:00:00.000Z,\n2014-06-01T00:00:00.000Z,0.8373379707336426\n
      "},{"location":"community/ncwms/#ncwms-extension-configuration","title":"ncWMS extension configuration","text":"

      The ncWMS extension adds a panel at the bottom of the WMS administration page:

      Option Description

      GetTimeSeries thread pool size Size of the thread pool used to compute GetTimeSeries results (parallelized to speed up computation)

      Maximum number of times in GetTimeSeries Maximum number of times tha GetTimeSeries will process. A user asking for more times will get back a service exception. The configuration is set the first time the admin hits save in the WMS page, even with a value of 0 (from that point on, GetTimeSeries will be independent on the WMS max dimensions setting).

      "},{"location":"community/netcdf-ghrsst/","title":"GHRSST NetCDF output","text":"

      GHRSST is Group for High Resolution Sea Surface Temperature. Among its various activities it issued a specification on how sea surface temperature data should be organized in NetCDF files.

      The NetCDF GHRSST module allows to generate complaint GHRSST files as WCS outputs, given a compliant GHRSST input.

      "},{"location":"community/netcdf-ghrsst/#installation","title":"Installation","text":"

      As a community module, the package needs to be downloaded from the nightly builds, picking the community folder of the corresponding GeoServer series (e.g. if working on the GeoServer main development branch nightly builds, pick the zip file form main/community-latest).

      To install the module, unpack the zip file contents into GeoServer own WEB-INF/lib directory and restart GeoServer.

      For the module to work, the NetCDF and NetCDF Output Format extensions must also be installed.

      "},{"location":"community/netcdf-ghrsst/#input-preparation","title":"Input preparation","text":"

      A GHRSST file contains multiple variables that are related with each other, and should be explored together in order to better understand the data. Thus, it is assumed that the source GHRSST file is published as a single coverage view holding all the variables as bands, retaining their native name (this is important for the plugin to work):

      Setting up a coverage view with all variables as bands

      A GHRSST output must also have a time, so the time dimension of this layer should be enabled (the output generation will fail with an error otherwise).

      At the time of writing a coverage view requires the source bands to be of uniform data type, and the data sources might not be. In case setting up the view is not possible with the data available, a NCML file can be used to reprocess the source NetCDF into one that has bands with uniform data type. A downloadable example has been provided to facilitate setting up the view.

      Download the reference NCML transformation

      The GHRSST may also have to be setup in a image mosaic in order to provide a deep temporal layer that users can select data from. The image mosaic setup can be complex, so a downloadable example has been provided for it as well (will require some changes, at a minimum, fix the paths at the bottom of indexer.xml, and the database connection parameters in the two datastore properties files).

      Download the sample mosaic configuration files

      "},{"location":"community/netcdf-ghrsst/#configuring-ghrsst-output","title":"Configuring GHRSST output","text":"

      The normal WCS NetCDF output will pick the first band of a coverage and generate a single variable NetCDF output. When the GHRSST plugin is installed, a new UI element will show up that enables GHRSST output:

      Enabling GHRSST output mode

      Notes about the configuration UI:

      • Various normal configurations such as variable name, unit of measure, and data packing will be ignored (each variable in GHRSST has its own assigned data type and packing, as from specification)
      • For the output to be compliant, enable copy of both global and per variable attributes
      • The RDAC, Processing Level, SST Type and Product String have to be filled in order to generate a valid GHRSST file name in output. The user interface provides auto-complete with names picked from the specification, but others can be inputed as well.

      For the output to generate correctly the coverage band names have to follow exactly the expected specification variable names (which comes naturally if the input is valid GHRSST), variable will be re-packed in output according to specification, so even if the inputs are all floats, the output will follow the expected data types.

      Any extra coverage band not present in the specification will be copied from input to output un-modified.

      "},{"location":"community/notification/","title":"Notification community module Plugin Documentation","text":"

      The notification community module is meant to be a pluggable system to listen, summarize and notify events triggered by GeoServer data and configuration manipulation to some external source, in some agreed upon format.

      The events of interest are:

      1. Catalog configuration changes (insert/update/removal of layers, styles, workspaces, stores, groups and so on)
      2. Data changes via WFS-T (anything that can affect the data precise bounding box)

      The system is completely pluggable in terms of notification destinations, potential targets can be direct HTTP calls to external system, message queues, log files, email. The message format can also vary depending on the target and intended usage, both in terms of contents, e.g., it could be full of details or simply an indication of what changed, and encoding, e.g., xml, json, text, html.

      "},{"location":"community/notification/#overall-architecture","title":"Overall architecture","text":"

      The overall architecture is depicted in the following diagram:

      The system basically generates a set of events, has a configuration to match them with a desired tool to send the message out (the processor). The sender can be conceived as a the combination of an \"encoder\" that generates the message payload and a \"sender\".

      Each message is combined with its processor and send into a destination queue, where a thread pool picks the events and runs their processor. For some type of events, like catalog ones, the thread pool will have to be configured with just one thread to make sure the events are sent in the right order to the destinations.

      "},{"location":"community/notification/#installing-the-extension","title":"Installing the extension","text":"
      1. Download the Notification extension from the nightly GeoServer community module builds.
      2. Download the Notification Common extension from the nightly GeoServer community module builds.
      3. (optional) If you want use sender/encoder provided for GeoNode, download the Notification Geonode extension from the nightly GeoServer community module builds.
      4. Place the JARs into the WEB-INF/lib directory of the GeoServer installation.
      "},{"location":"community/notification/#usage","title":"Usage","text":"

      The usage of the extensions is based on two components that defines its behavior and logic:

      • A configuration file named notifier.xml that must be present on a \"notifier\" subfolder of Geoserver root data directory (if extensions found no one notifier.xml file under notifier folder, will create a new one with default values)
      • A JAR that implements the specific logic of sender/encoder
      "},{"location":"community/notification/#configuration-file","title":"Configuration file","text":"

      The configuration file will be parsed by XStream framework to instantiate the right classes. An example of notifier.xml have the follow content:

      <notificationConfiguration>\n<queueSize>1000</queueSize>\n  <notificator>\n    <messageFilter>type='Catalog'</messageFilter>\n    <queueSize>1000</queueSize>\n    <processorThreads>1</processorThreads>    \n    <genericProcessor>\n      <geonodeEncoder />\n      <fanoutSender>\n        <username>guest</username>\n        <password>guest</password>\n        <host>localhost</host>\n        <port>4432</port>\n        <virtualHost></virtualHost>\n        <exchangeName>testExchange</exchangeName>\n        <routingKey>testRouting</routingKey>\n      </fanoutSender>\n    </genericProcessor>\n  </notificator>\n  <notificator>\n  ...\n  </notificator>\n</notificationConfiguration>\n

      notificationConfiguration -> queueSize = the size of queue that store all the notification messages.

      notificationConfiguration -> notificator = is possible to have one or more notificator.

      notificationConfiguration -> notificator -> messageFilter = the is a CQL filter, only notification message that satisfy this filter, will be processed by this notificator. Possible values are:

      • type='Catalog'
      • type='Data'

      notificationConfiguration -> notificator -> queueSize = the size of queue to store the notification messages for specific notificator, only the notification that satisfy the CQL filter specified on <messageFilter> element will be pushed in this queue.

      notificationConfiguration -> notificator -> processorThreads = number of threads that will be work to encode and send the notification messages. Note that for 'Catalog' type event, this will have to be valued as 1 to make sure the events are sent in the right order to the destinations.

      notificationConfiguration -> notificator -> genericProcessor = configurations for the encoder and sender components

      notificationConfiguration -> notificator -> geonodeEncoder = this is a placeholder tag that must match with the alias used to map the implementation class for encoder. Based on custom implementation, additional attributes or child tags can be provided.

      Note

      is mandatory that one and only one implementation of encoder match with each alias.

      notificationConfiguration -> notificator -> fanoutSender = this is a placeholder tag that must match with the alias used to map the implementation class for sender. Based on custom implementation, additional attributes or child tags can be provided.

      Note

      is mandatory that one and only one implementation of sender match with each alias.

      For the case of AMQP Fanout (RabbitMQ) based sender implementation, the additional parameters are:

      • host : the IP/DNS to which the underlying TCP connection is made
      • port : port number to which the underlying TCP connection is made
      • virtualhost (optional) : a path which acts as a namespace
      • username (optional) : if present is used for SASL exchange
      • password (optional) : if present is used for SASL exchange
      • exchangeName : the name of exchange to publish the message to
      • routingKey : identify the queue to publish the message to (ignored by fanout type)
      "},{"location":"community/notification/#sender-and-encoder-implementations","title":"Sender and encoder implementations","text":"

      This plugin allow the pluggability of sender/encoder implementation, multiple implementation plugins are allowed.

      The core notification extension will be resolve the implementations of the interfaces:

      • org.geoserver.notification.common.NotificationEncoder
      • org.geoserver.notification.common.NotificationProcessor
      • org.geoserver.notification.common.NotificationXStreamInitializer

      Based on the match between the tag names on configuration file (notifier.xml) and the aliases define in NotificationXStreamInitializer, the notification core will be use the right implementation of NotificationEncoder / NotificationProcessor.

      An example of this implementation is provided by the Notification Geonode extension.

      The minimal dependencies of this kind of plugin are (see pom.xml of Notification Geonode extension):

      • gs-notification-common
      • gs-main

      The plugin must be extends/implements almost the three classes/interfaces:

      NotificationXStreamDefaultInitializer: is a utility implementation of NotificationXStreamInitializer to define the match between NotificationEncoder / NotificationProcessor and configuration aliases:

      • getEncoderName : this method must be return the alias for encoder
      • getSenderName : this method must be return the alias for sender
      • getEncoderClass : this method must be return the class for encoder
      • getSenderClass : this method must be return the class for sender
      "},{"location":"community/oauth2/","title":"Authentication with OAuth2","text":"

      This tutorial introduces GeoServer OAuth2 support and walks through the process of setting up authentication against an OAuth2 provider. It is recommended that the Authentication chain section be read before proceeding.

      • Installing an OAuth2 Protocol
      • Configure the Google authentication provider
      • Configure the GeoServer OAuth2 filter
      • OpenID connect authentication
      "},{"location":"community/oauth2/google/","title":"Configure the Google authentication provider","text":"

      The first thing to do is to configure the OAuth2 Provider and obtain Client ID and Client Secret keys.

      1. Obtain OAuth 2.0 credentials from the Google API Console.

        Visit the Google API Console to obtain OAuth 2.0 credentials such as a client ID and client secret that are known to both Google and your application. The set of values varies based on what type of application you are building. For example, a JavaScript application does not require a secret, but a web server application does.

        • Login with a valid Google Account

        • Click on APIs & Services

        • Click on Credentials

          Note

          The first time you land here, Google will ask to create at least one project

          For the purpose of this tutorial we will create a sample project. You are free to create other projects or update existing ones through the Google API Console later.

          If no Credentials are present, you will be asked to create new one.

      2. Select an existing (or create a new one) OAuth Client ID

      3. Configure a new Web application

        • If it is the first time you create an OAuth Client ID, you will be asked to create a new consent screen

        • Customize the consent screen

          Warning

          This step is mandatory only if it's the first time you are defining a Web application on a new project. If you don't have an organization, you can only choose type External from the screen below.

        • Fill the form below and click on save and continue untill all tabs are filled.

          Note

          It can be edited and updated also later (see last point of this section below)

        • From the credentials page, click on CREATE CREDENTIALS> OAuth Client ID and select Application type -> Web application

          Warning

          This step is mandatory only if it's the first time you are defining a Web application on a new project.

        • Add a Name and the Authorized redirect URIs like shown here below.

          Note

          This sample creates a client working on the default local URL http://localhost:8080/geoserver. Of course this will work only on a local instance and can't be used for a production system.

          However it is possible to add as many Authorized redirect URIs you need to a new Web application.

          It is also possible to create many Client credentials with customised consent screen and Web application, depending on your specific needs. Every public GeoServer instance (or cluster of GeoServer belonging to a specific project) should have its own specific Client credentials.

          Note

          Always add two entries for each URI. One without the ending / and another one with it.

      4. Click on Create and take note of the Client ID and the Client Secret.

        At the end of the procedure Google will show-up a small dialog box with the Client ID and the Client Secret. That info can be always accessed and updated from the Google API Console

      5. Optionally customize the OAuth consent screen.

        At any time it is possible to update and customize the OAuth consent screen. You can put here your logo, app name, ToS and so on.

      "},{"location":"community/oauth2/installing/","title":"Installing an OAuth2 Protocol","text":"

      This module allows GeoServer to authenticate against the OAuth2 Protocol.

      In order to let the module work, it is mandatory to setup and configure an oauth2-xxxx-extension:

      • sec-oauth2-google
      • sec-oauth2-geonode
      • sec-oauth2-github
      • sec-oauth2-openid-connect

      Each ZIP files contains the oauth2-core extension, and the jars and the jars for the provider.

      The first one contains the necessary dependencies of the OAuth2 core module. This module contains the GeoServer security filter, the base classes for the OAuth2 Token services and the GeoServer GUI panel.

      The second one provides the OAuth2 implementation for each provider. Since in almost all cases the only difference between OAuth2 Providers are the endpoint URIs and the client connection information (not only the keys -public and secret - but also the user profile representations). In order to allow GeoServer to connect to a specific OAuth2 provider it is sufficient to install the OAuth2 Core module plugin (and correctly configure the parameters through the GeoServer GUI - see next section for the details) and the concrete implementation of the OAuth2 REST token template and resource details.

      Currently this module is shipped with a sample extension for Google OAuth2 Provider. This is a particular case since the Google JWT response is not standard and therefore we had to define and inject also a GoogleUserAuthenticationConverter taking the Google REST response against a valid access_token and converting it to an OAuth2 standard one.

      Other than this the most interesting part is the implementation of the base class GeoServerOAuth2SecurityConfiguration.

      The latter contains the Google implementation of the OAuth2RestTemplate.

      In the next section we will see how to install and configure the OAuth2 security filter on GeoServer authenticating against Google OAuth2 Provider.

      "},{"location":"community/oauth2/oauth2/","title":"Configure the GeoServer OAuth2 filter","text":"
      1. Start GeoServer and login to the web admin interface as the admin user.

      2. Click the Authentication link located under the Security section of the navigation sidebar.

      3. Scroll down to the Authentication Filters panel and click the Add new link.

      4. Click the OAuth2 link.

      5. Fill in the fields of the settings form as follows:

        The default values provided with the plugin are valid for the Google OAuth2 Provider and are the following:

        \"Enable Redirect Authentication EntryPoint\" = False\n\"Access Token URI\" = https://accounts.google.com/o/oauth2/token\n\"User Authorization URI\" = https://accounts.google.com/o/oauth2/auth\n\"Redirect URI\" = http://localhost:8080/geoserver\n\"Check Token Endpoint URL\" = https://www.googleapis.com/oauth2/v1/tokeninfo\n\"Logout URI\" = https://accounts.google.com/logout\n\"Scopes\" = https://www.googleapis.com/auth/userinfo.email,https://www.googleapis.com/auth/userinfo.profile\n

        Note

        1. Client ID and Client Secret are the ones Google provided
        2. Choose a Role Service able to recognize user emails as IDs. By default a connected user will have ROLE_USER role

        Warning

        A few words on the Enable Redirect Authentication EntryPoint option

        This option allows you to decide whether or not to force automatic redirection to OAuth2 Access Token URI or not for authentication.

        What does that mean?

        • Enable Redirect Authentication EntryPoint = True

          If not already authenticated (or no valid Access Token is provided in the query string), this option will force a redirection to the OAuth2 Provider Login page.

          This may cause unwanted behavior since it will override every other explicit login method like form. In other words if the filter is applied for instance to the web endpoint, it won't be possible to access to the GeoServer Admin GUI using the standard login method via browser.

        • Enable Redirect Authentication EntryPoint = False

          In order to avoid the above issue, by disabling this option you will be forced to use an explicit Authentication Endpoint to login via the OAuth2 Provider login page.

          If not already authenticated (or no valid Access Token is provided in the query string), you must authenticate through the following URLs:

          1. GeoServer OAuth2 Authorization Endpoint; http://<host:port>/geoserver/j_spring_oauth2_login

          2. OAuth2 Provider Explicit User Authorization Endpoint; this must be adapted for your specific OAuth2 Provider, the protocol stated that it should be

            https://<USER_AUTHORIZATION_URI>?scope=<SCOPES>&response_type=code&redirect_uri=<REDIRECT_URI>&client_id=<CLIENT_ID>\n

            For Google OAuth2 Provider is:

            https://accounts.google.com/o/oauth2/auth?scope%3Dhttps://www.googleapis.com/auth/userinfo.email%2Bhttps://www.googleapis.com/auth/userinfo.profile%26response_type%3Dcode%26redirect_uri%3D<REDIRECT_URI>%26client_id%3D<CLIENT_ID>\n
      6. Update the filter chains by adding the new OAuth2 filter.

        Once everything has been configured you should be able to see the new oauth2 filter available among the Authentication Filters list

        Through this it will be always possible to modify / update the filter options, or create more of them.

        The next step is to add the filter to the Filter Chains you want to protect with OAuth2 also

      7. Select the OAuth2 Filter for each filter chain you want to protect with OAuth2.

        If you need to protect all the GeoServer services and the GeoServer Admin GUI too with OAuth2, you need to add the oauth2 filter to all the following chains

        • web
        • rest
        • gwc
        • default

        The order of the authentication filters depends basically on which method you would like GeoServer to try first.

        Note

        During the authentication process, the authentication filters of a Filter Chain are executed serially until one succeed (for more details please see the section Authentication chain)

        Warning

        If Enable Redirect Authentication EntryPoint = True for OAuth2 Filter, the web chain won't be able to login through the form method.

        Note

        Remember that the anonymous filter must be always the last one.

      8. Save.

      It's now possible to test the authentication:

      1. Navigate to the GeoServer home page and log out of the admin account.

      2. Try to login again, you should be able now to see the external Google login form.

      "},{"location":"community/oauth2/oidc/","title":"OpenID connect authentication","text":"

      The OAuth2 OpenID Connect (OIDC) authentication is working in a way quite similar to Google (and GitHub) authentications, the only difference is that the authentication page cannot propose default values for the various endpoints, which have to be configured manually.

      In case the web login will not be used, the client ID and client secret are not actually needed, and can be filled with two made up values (the validation just checks they are present, but they will be used only in the \"authorisation flow\", but not when doing OGC requests where the client is supposed to have autonomously retrieved a valid bearer token).

      The configuration GUI supports OpenID Discovery documents. If the server supports them it's sufficient to provide the path to the document, or to the authentication service root, and the GUI will auto-fill itself based on the document contents:

      The UI allow to set also the Post Logout Redirect URI which will be used to populate the post_logout_redirect_uri request param, when doing the global logout from the GeoServer UI. The OpenId provider will use the URI to redirect to the desired app page.

      In addition, the OpenID connect authentication is able to extract the user roles from either the ID token or the Access Token:

      The chosen attribute must be present in either the Access Token or in the Id token, and be either a string or an array of strings.

      From UI it is also possible to set the Response Mode value. The field can be kept empty but it is needed when the OpenId server used as Identity Provider doesn't send by default the authorization code as a query string (that is mandatory in order to allow GeoServer and OpenId integration to work properly).

      Finally the admin can allow the sending of the client_secret during an access_token request trough the Send Client Secret in Token Request. Some OpenId implementation requires it for the Authorization Code flow when the client app is a confidential client and can safely store the client_secret.

      "},{"location":"community/oauth2/oidc/#logging-oauth2-activity","title":"Logging OAuth2 Activity","text":"

      The plugin includes an OIDC_LOGGING profile which is installed on startup. This logging profile quiets most GeoServer logging activity, while enabling trace logging for OAuth2 functionality.

      The module also includes an additional connection setting to include the token details as additinoal log messages. This is intended to assist in troubleshooting durring development and initial setup.

      Log sensitive information

      This setting can obviously used to access sensitive information and you are advised clear logs after use.

      To setup for troubleshooting OIDC activity:

      1. Navigate to Settings \u2192 Global

      2. Select the logging profile OIDC_LOGGING

      3. Navigate Security \u2192 Authentication

      4. Setup your OAuth2 OpenID Connect configuration with Log Sensitive Information (do not use in production) checked

      5. With these settings each individual steps of the OAuth2 authentication is shown. The logging senstive information setting logs access token and id token (the content of these token may be decoded using https://jwt.io ).

        DEBUG  [security.oauth2] - OIDC: - CLIENT_SECRET: squirrel\nDEBUG  [security.oauth2] - OIDC: received a CODE from Identity Provider - handing it in for ID/Access Token\nDEBUG  [security.oauth2] - OIDC: CODE=...\nDEBUG  [security.oauth2] - OIDC: Identity Provider returned Token, type=Bearer\nDEBUG  [security.oauth2] - OIDC: SCOPES=openid geocat\nDEBUG  [security.oauth2] - OIDC: ACCESS TOKEN: .... \nDEBUG  [security.oauth2] - OIDC: ID  TOKEN: ... \nDEBUG  [security.oauth2] - OIDC: Getting Roles from UserGroupService, location=null\nDEBUG  [security.oauth2] - OIDC: Geoserver Roles: ADMIN\nDEBUG  [security.oauth2] - OIDC: Geoserver Roles: ROLE_ADMINISTRATOR\n
      "},{"location":"community/oauth2/oidc/#openid-connect-with-attached-access-bearer-tokens","title":"OpenID Connect With Attached Access Bearer Tokens","text":"

      The OpenID Connect plugin allows the use of Attached Bearer Access Tokens. This is typically used by automated (i.e. desktop or external Web Service) to access the Geoserver REST API.

      Bearer Tokens

      The setup process is as follows:

      1. Setup your OAuth2 OpenID Connect configuration as normal
      2. On the OpenID Connect configuration screen (bottom), makes sure \"Allow Attached Bearer Tokens\" is checked
      3. You can not use ID Tokens as a Role Source for the attached Bearer Tokens (see below)

      To Use:

      1. Obtain an Access Token from the underlying IDP
      2. Attach the access token to your HTTP request headers

      Authorization: Bearer <token>

      The Access Token (JWT) is validated;

      1. The Access Token is used to get the \"userinfo\" endpoint. The underlying IDP will verify the token (i.e. signature and expiry)
      2. The Audience of the Token is checked that it contains the GeoServer configured Client Id. This make sure an Access Token for another application is not being inappropriately reused in GeoServer (cf. AudienceAccessTokenValidator.java).
      3. The Subject of the userinfo and Access Token are verified to be about the same person. The OpenID specification recommends checking this (cf. SubjectTokenValidator.java).

      For KeyCloak, consider using the \"userinfo endpoint\" role source and configure Keycloak to put groups in the \"userinfo.\"

      For Azure AD, configure Azure to allow access to the MS Graph API (memberOf) and use the \"Microsoft Graph API (Azure AD)\" role source.

      To configure Azure AD for \"memberOf\" (\"GroupMember.Read.All\" permission) access;

      1. Go to your application in Azure AD (in the portal)
      2. On the left, go to \"API permissions\"
      3. Click \"Add a permission\"
      4. press \"Microsoft Graph\"
      5. press \"Delegated permission\"
      6. Scroll down to \"GroupMember\"
      7. Choose \"GroupMemeber.Read.All\"
      8. Press \"Add permission\"
      9. On the API Permission screen, press the \"Grant admin consent for ...\" text

      This has been tested with KeyCloak (with groups in the userinfo endpoint response), and with MS Azure AD (with the groups from the GraphAPI). This should work with other IDPs - however, make sure that the Subject and Audience token verification works with their tokens.

      If you do not need Bearer Token functionality, it is recommended to turn this off.

      "},{"location":"community/oauth2/oidc/#proof-key-of-code-exchange-pkce","title":"Proof Key of Code Exchange (PKCE)","text":"

      The OpenID Connect plugin allows the use of Proof Key of Code Exchange (PKCE).

      Proof Key of Code Echange

      The setup process is as follows:

      1. Setup your OAuth2 OpenID Connect configuration as normal
      2. On the OpenID Connect configuration screen (bottom), makes sure \"Use PKCE\" is checked

      To prevent client side refequest forgery:

      • Step 1: GeoServer will include a code_challenge during initial authorization code request

      • Step 2: GeoServer will include a code_verifer during the access token request.

        The authentication server will confirm that code_verifier hash matches the initial code_challenge in order the confirm the client is the same as in Step 1.

      Log output of this exchange is as follows:

      DEBUG  [oauth2.pkce] - Generate code_verifier: yQat4Y.....\nDEBUG  [oauth2.pkce] - CODE_CHALLENGE: 5HiD...\nDEBUG  [oauth2.pkce] - CODE_CHALLENGE_METHOD: S256\nDEBUG  [oauth2.pkce] - CLIENT_SECRET: squirrel\nDEBUG  [oauth2.pkce] - CODE_VERIFIER: yQat4Y...\n

      Reference:

      • rfc7636 Proof Key for Code Exchange by OAuth Public Clients
      "},{"location":"community/oauth2/oidc/#json-web-key-set-uri","title":"JSON Web Key set URI","text":"

      The JSON Web Key set URI provides the location of a document of public keys that can be used to check the signature of the provided accessToken.

      Optional: It is no longer required to use Check Token Endpoint URL - if you leave that field blank you may rely only on the JSON Web Key set URI signature check. When use in this manner roles cannot be extracted from access token.

      "},{"location":"community/oauth2/oidc/#azure-ad-and-adfs-setup","title":"Azure AD and ADFS setup","text":"

      To make the OpenIdConnect filter to work properly with an Azure AD or ADFS server via the OpenId protocol, the user must set, in addition to the other configuration parameters, the Response Mode to query (otherwise by default ADFS will return a url fragment) and check the checkbox Send Client Secret in Token Request (the client_secret is mandatory in token request according to the Microsoft documentation).

      "},{"location":"community/oauth2/oidc/#ssl-trusted-certificates","title":"SSL Trusted Certificates","text":"

      When using a custom Keystore or trying to access a non-trusted or self-signed SSL-protected OAuth2 Provider from a non-SSH connection, you will need to add the certificates to the JVM Keystore.

      In order to do this you can follow the next steps:

      In this example we are going to

      1. Retrieve SSL certificates from Google domains:

        \"Access Token URI\" = https://accounts.google.com/o/oauth2/token therefore we need to trust https://accounts.google.com or (accounts.google.com:443) \"Check Token Endpoint URL\" = https://www.googleapis.com/oauth2/v1/tokeninfo therefore we need to trust https://www.googleapis.com or (www.googleapis.com:443)

        ::: note ::: title Note :::

        You will need to get and trust certificates from every different HTTPS URL used on OAuth2 Endpoints. :::

      2. Store SSL Certificates on local hard disk

      3. Add SSL Certificates to the Java Keystore

      4. Enable the JVM to check for SSL Certificates from the Keystore

      1. Retrieve the SSL Certificates from Google domains

        Use the openssl command in order to dump the certificate

        For https://accounts.google.com

        openssl s_client -connect accounts.google.com:443\n

        And for https://www.googleapis.com

        openssl s_client -connect www.googleapis.com:443\n

      2. Store SSL Certificates on local hard disk

        Copy-and-paste the two sections -BEGIN CERTIFICATE-, -END CERTIFICATE- and save them into two different .cert files

        Note

        .cert file are plain text files containing the ASCII characters included on the -BEGIN CERTIFICATE-, -END CERTIFICATE- sections

        google.cert (or whatever name you want with .cert extension)

        google-apis.cert (or whatever name you want with .cert extension)

      3. Add SSL Certificates to the Java Keystore

        You can use the Java command keytool like this

        google.cert (or whatever name you want with .cert extension)

        keytool -import -noprompt -trustcacerts -alias google -file google.cert -keystore ${KEYSTOREFILE} -storepass ${KEYSTOREPASS}\n

        google-apis.cert (or whatever name you want with .cert extension)

        keytool -import -noprompt -trustcacerts -alias google-apis -file google-apis.cert -keystore ${KEYSTOREFILE} -storepass ${KEYSTOREPASS}\n

        or, alternatively, you can use some graphic tool which helps you managing the SSL Certificates and Keystores, like Portecle

        java -jar c:\\apps\\portecle-1.9\\portecle.jar\n

      4. Enable the JVM to check for SSL Certificates from the Keystore

        In order to do this, you need to pass a JAVA_OPTION to your JVM:

        -Djavax.net.ssl.trustStore=F:\\tmp\\keystore.key\n
      5. Restart your server

      Note

      Here below you can find a bash script which simplifies the Keystore SSL Certificates importing. Use it at your convenience.

      HOST=myhost.example.com\nPORT=443\nKEYSTOREFILE=dest_keystore\nKEYSTOREPASS=changeme\n\n# get the SSL certificate\nopenssl s_client -connect ${HOST}:${PORT} </dev/null \\\n    | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > ${HOST}.cert\n\n# create a keystore and import certificate\nkeytool -import -noprompt -trustcacerts \\\n    -alias ${HOST} -file ${HOST}.cert \\\n    -keystore ${KEYSTOREFILE} -storepass ${KEYSTOREPASS}\n\n# verify we've got it.\nkeytool -list -v -keystore ${KEYSTOREFILE} -storepass ${KEYSTOREPASS} -alias ${HOST}\n
      "},{"location":"community/ogc-api/","title":"OGC API modules","text":"

      This plugin includes implementation of a set of OGC API service implementations

      • Configuring the GeoServer OGC API module
      • OGC API - Features
      • OGC API - Tiles
      • OGC API - Maps
      • OGC API - Coverages
      • OGC API - Styles
      • OGC API - Tiled features demonstration
      • OGC Testbed Experiments

      Warning

      The OGC API services are still in heavy development, most of the specs and extensions are still in draft form and their behavior are subject to change in the coming months/years.

      How to help

      The modules are still in their infancy, there is a set of activities that could help their development:

      • Implementation of additional draft API services, such as the Maps API, the Coverages API, the Records API and the Process API.
      • Implementation of new draft extensions not yet covered, like the OGC Features API Transaction extension.
      • Improvement of the HTML representation of resources, both in terms of looks and functionality (the specification makes no mandate for these pages, so they may be implemented as we see fit).
      • Testing and improvement of the OpenAPI documents generated by each service, with particular focus on automatic generation of clients.
      • General testing, reporting and bug fixing.

      Check documentation pages for \"implementation status\" outlining present state of development.

      "},{"location":"community/ogc-api/configure/","title":"Configuring the GeoServer OGC API module","text":"

      The OGC API modules provide additional services along side the existing Open Web Services (OWS).

      "},{"location":"community/ogc-api/configure/#service","title":"Service","text":"

      The OGC API modules primarily use the same configurations as their equivalent OWS services. So, for example, setting the WFS limited SRS list will also limit the SRS list for OGC API - Features.

      In addition, the OGC API modules will have some unique configuration options.

      "},{"location":"community/ogc-api/configure/#security","title":"Security","text":"
      • Data security: Data security is managed independently of web service. The same data security restrictions placed on a workspace or layer content are enforced for both OWS services and OGC API web services

      • Service security: OGC API web services are managed directly in Security > Services page. New access rules can be defined for OGC API services.

        Service rule for OGC API Features getLandingPage

      "},{"location":"community/ogc-api/configure/#collections","title":"Collections","text":"

      OGCAPI web services provides a collections resource describing the published content.

      As an example OGC API - Features collections lists:

      • links: Links and metadata
      • collections: List of individual collections available
      • crs: List of coordinate reference systems defined by WFS settings
      "},{"location":"community/ogc-api/configure/#custom-links-for-the-collections-resource","title":"Custom links for the \"collections\" resource","text":"

      The collections resource can have a number of additional links, beyond the basic ones that the service code already includes. Navigate to *Settings > Global``. The links are configured under heading*OGC API Settings.

      Links used to indicate global Creative Commons license

      Link editor column description:

      • rel: the link relation type, as per the OGC API - Features specification
      • Mime type: the mime type for the resource found following the link
      • URL: the link URL
      • Title: the link title (optional)
      • Service: the service for which the link is valid (optional, defaults to all)

      Common links relationships that could be added for the collections resource are:

      • enclosure, in case there is a package delivering all the collections (e.g. a GeoPackage, a ZIP full of shapefiles).
      • describedBy, in case there is a document describing all the collections (e.g. a JSON or XML schema).
      • license, if all collection data is under the same license.

      Example from OGC API - Features service (http://localhost:8080/geoserver/ogc/features/v1/collections/?f=application%2Fjson):

      {\n  \"href\": \"https://creativecommons.org/licenses/by/3.0/\",\n  \"rel\": \"license\",\n  \"type\": \"text/html\",\n  \"title\": \"Creative Commons - Attribution\"\n}\n
      "},{"location":"community/ogc-api/configure/#custom-links-for-workspace-collections","title":"Custom links for workspace collections","text":"

      Additional custom collections links can also be defined for an individual workspace. Navigate to *Workspaces > Edit Workspace``. Links are configured on the*Basic Info tab.

      Links used to indicate public domain license for ne workspace

      In this example the license is changed to reflect the natural earth terms of use (overriding the license defined in global settings).

      Example from workspace OGC API - Features service ( http://localhost:8080/geoserver/ne/ogc/features/v1/collections/?f=application%2Fjson):

      {\n  \"href\": \"https://www.naturalearthdata.com/about/terms-of-use/\",\n  \"rel\": \"license\",\n  \"type\": \"text/html\",\n  \"title\": \"Public Domain\"\n}\n
      "},{"location":"community/ogc-api/configure/#single-collection","title":"Single collection","text":"

      Each GeoServer layer is published is represented in OGC API as a single collection.

      As an example OGC API - Features collections lists:

      • id: Layer name
      • title: Layer title
      • description: Layer abstract
      • extent: Layer bounds
      • links: Links to access content and metadata
      • crs
      • storageCrs
      "},{"location":"community/ogc-api/configure/#custom-links-for-single-collection","title":"Custom links for single collection","text":"

      Additional custom links can be provided for an individual layer. Use the Layer Editor *Publishing`` tab, and locate the heading for*OGC API.

      Links used to define enclosure download for ne:counteries layer

      The relationships are the same as for the collections resource, but used in case there is anything that is specific to the collection (e.g., the schema for the single collection). In addition, other relations can be specified, like the tag relation, to link to the eventual INSPIRE feature concept dictionary entry.

      Example from workspace ne:counteries collection providing enclosure for download:

      {\n  \"href\": \"https://www.naturalearthdata.com/http//www.naturalearthdata.com/download/10m/cultural/ne_10m_admin_0_countries.zip\",\n  \"rel\": \"enclosure\",\n  \"type\": \"application/zip\",\n  \"title\": \"ne_10m_admin_0_countries.zip\"\n}\n
      "},{"location":"community/ogc-api/testbed/","title":"OGC Testbed Experiments","text":"

      The following modules are part of the OGC Testbed experiments.

      "},{"location":"community/ogc-api/testbed/#images-and-changesets","title":"Images and Changesets","text":"

      A couple of extra API, images and changesets, based on engineering reports of Testbed 15, allowing to update a image mosaic and get a list of tiles affected by the change.

      To install these modules:

      1. Download the OGC API nightly GeoServer community module from ogcapi-images.

        Warning

        Verify that the version number in the filename corresponds to the version of GeoServer you are running (for example geoserver- 2.24.2-ogcapi-images-plugin.zip above).

      2. Extract the contents of the archive into the WEB-INF/lib directory of the GeoServer installation.

      3. On restart the services are listed at http://localhost:8080/geoserver

      "},{"location":"community/ogc-api/testbed/#dggs","title":"DGGS","text":"

      The DGGS functionality exposes data structured as DGGS, based on either H2 or rHealPix, based on engineering reports of Testbed 18.

      To make full usage of the DGGS functionality, a ClickHouse installation is also needed.

      To install these modules:

      1. Download the OGC API nightly GeoServer community module from ogcapi-dggs.

        Warning

        Verify that the version number in the filename corresponds to the version of GeoServer you are running (for example geoserver- 2.24.2-ogcapi-dggs-plugin.zip above).

      2. Extract the contents of the archive into the WEB-INF/lib directory of the GeoServer installation.

      3. On restart the services are listed at http://localhost:8080/geoserver

      "},{"location":"community/ogc-api/coverages/","title":"OGC API - Coverages","text":"

      A OGC API - Coverages based on an earlier specification draft, delivering partial functionality:

      • Collection listing
      • Download in the same formats supported by WCS
      • Spatial and temporal subsetting
      • Mosaic index filtering (GeoServer extension)
      • Domain set description in JSON

      Missing functionality at the time of writing, and known issues:

      • Full coverage JSON support
      • Scaling
      • CRS transformation
      "},{"location":"community/ogc-api/coverages/#ogc-api-coverages-implementation-status","title":"OGC API - Coverages Implementation status","text":"

      OGC API - Coverages Version Implementation status

      Part 1: Core Draft Implementation based on early specification draft, not yet updated to final version

      "},{"location":"community/ogc-api/coverages/#installing-the-geoserver-ogc-api-coverages-module","title":"Installing the GeoServer OGC API - Coverages module","text":"
      1. Download the OGC API nightly GeoServer community module from ogcapi-coverages.

        Warning

        Verify that the version number in the filename corresponds to the version of GeoServer you are running (for example geoserver- 2.24.2-ogcapi-coverages-plugin.zip above).

      2. Extract the contents of the archive into the WEB-INF/lib directory of the GeoServer installation.

      3. On restart the services are listed at http://localhost:8080/geoserver

      "},{"location":"community/ogc-api/coverages/#configuration-of-ogc-api-covearges-module","title":"Configuration of OGC API - Covearges module","text":"

      The module is based on the GeoServer WCS one, follows the same configuration and exposes the same coverages.

      "},{"location":"community/ogc-api/features/","title":"OGC API - Features","text":"

      An OGC Features API publishing feature data using an OpenAPI web service.

      "},{"location":"community/ogc-api/features/#features-implementation-status","title":"Features Implementation status","text":"

      OGC API - Features Version Implementation status

      Part 1: Core 1.0.0 Passes compliance tests

      Part 2: Coordinate Systems by Reference 1.0.0 Passes compliance tests

      Part 3: Filtering Draft Draft implemented (mind, the draft does not include a filtering language)

      Part 4: Create, Replace, Update and Delete Draft Not implemented (volunteers/sponsoring wanted)

      Common Query Language (CQL2) Draft Implements an earlier draft for for both text and JSON encodings. To be updated.

      Part n: Query by IDs Proposal Proposal implemented, but syntax and semantic is subject to change in a future release. Thus said, usage should be carefully considered.

      "},{"location":"community/ogc-api/features/#installing-the-geoserver-ogc-api-features-module","title":"Installing the GeoServer OGC API Features module","text":"
      1. Download the OGC API nightly GeoServer community module from ogcapi-features.

        Warning

        Verify that the version number in the filename corresponds to the version of GeoServer you are running (for example geoserver- 2.24.2-ogcapi-features-plugin.zip above).

      2. Extract the contents of the archive into the WEB-INF/lib directory of the GeoServer installation.

      3. On restart the services are listed at http://localhost:8080/geoserver

      "},{"location":"community/ogc-api/features/#use-of-ogc-api-features-service","title":"Use of OGC API - Features service","text":"

      The OGC API Features Service is accessed via the FEATURES version 1.0 link on the home page.

      "},{"location":"community/ogc-api/features/#capabilities","title":"Capabilities","text":"

      The service is self described using:

      • html: A collection of web pages, with links for navigation between content (and that can be indexed by search engines for discoverability).

        OGC API Features service

      • application/json: A collection of json documents, with reference between each document for programmatic access by web developers.

        {\n  \"title\": \"GeoServer Web Feature Service\",\n  \"description\": \"This is the reference implementation of WFS 1.0.0 and WFS 1.1.0, supports all WFS operations including Transaction.\",\n  \"links\": [\n    {\n      \"href\": \"http://localhost:8080/geoserver/ogc/features/?f=application%2Fx-yaml\",\n      \"rel\": \"alternate\",\n      \"type\": \"application/x-yaml\",\n      \"title\": \"This document as application/x-yaml\"\n    },\n    {\n      \"href\": \"http://localhost:8080/geoserver/ogc/features/?f=application%2Fjson\",\n      \"rel\": \"self\",\n      \"type\": \"application/json\",\n      \"title\": \"This document\"\n    },\n    {\n      \"href\": \"http://localhost:8080/geoserver/ogc/features/?f=text%2Fhtml\",\n      \"rel\": \"alternate\",\n      \"type\": \"text/html\",\n      \"title\": \"This document as text/html\"\n    }\n
      • application/x-yaml: A collection of yaml documents, with references between each document for programmatic access.

        title: GeoServer Web Feature Service\ndescription: This is the reference implementation of WFS 1.0.0 and WFS 1.1.0, supports\n  all WFS operations including Transaction.\nlinks:\n- href: http://localhost:8080/geoserver/ogc/features/?f=application%2Fx-yaml\n  rel: self\n  type: application/x-yaml\n  title: This document\n- href: http://localhost:8080/geoserver/ogc/features/?f=application%2Fjson\n  rel: alternate\n  type: application/json\n  title: This document as application/json\n- href: http://localhost:8080/geoserver/ogc/features/?f=text%2Fhtml\n  rel: alternate\n  type: text/html\n  title: This document as text/html\n

      The service title and description are provided by the existing Web Feature Service (WFS) settings.

      "},{"location":"community/ogc-api/features/#open-api","title":"Open API","text":"

      For programmatic access an OpenAPI description of the service is provided, that may be browsed as documentation, or used to generate a client to access the web services.

      OGC API Features OpenAPI Document

      "},{"location":"community/ogc-api/features/#collections","title":"Collections","text":"

      The collection of feature types being published by the service.

      Each collection entry is described using the layer details of title, description, geographic extent.

      Data can be browsed as web pages, or downloaded in a range of formats such as GeoJSON and GML documents.

      Collection sf:roads download formats

      "},{"location":"community/ogc-api/features/#conformance","title":"Conformance","text":"

      Lists the operations this service can perform, each \"conformance class\" documents supported functionality.

      OGC API Features Conformance

      "},{"location":"community/ogc-api/features/#contact-information","title":"Contact information","text":"

      Advertises contact information for the service.

      Defined by defined in by Contact Information.

      "},{"location":"community/ogc-api/features/#configuration-of-ogc-api-features-module","title":"Configuration of OGC API - Features module","text":"

      The service does not require any additional configuration to use. The service is configured using:

      • The existing Web Feature Service (WFS) settings to define title, abstract, and output formats.

        This is why the service page is titled GeoServer Web Feature Service by default.

      • Built-in templates used for html generation

      • Extra links can be added on a per-service or per-collection basis as indicated in Configuring the GeoServer OGC API module.

      "},{"location":"community/ogc-api/features/#html-templates","title":"HTML Templates","text":"

      To override an OGC API Features template:

      1. Create a directory ogc/features in the location you wish to override:

        • GEOSERVER_DATA_DIR/templates/ogc/features/v1
        • GEOSERVER_DATA_DIR/workspace/{workspace}/ogc/features/v1
        • GEOSERVER_DATA_DIR/workspace/{workspace}/{datastore}/ogc/features/v1
        • GEOSERVER_DATA_DIR/workspace/{workspace}/{datastore}/{featuretype}/ogc/features/v1
      2. Create a file in this location, using the GeoServer 2.24.2 examples below:

        • ogc/features/v1/collection.ftl
        • ogc/features/v1/collection_include.ftl
        • ogc/features/v1/collections.ftl
        • ogc/features/v1/queryables.ftl
        • ogc/features/v1/functions.ftl

        The above built-in examples are for GeoServer 2.24.2, please check for any changes when upgrading GeoServer.

      The templates for listing feature content are shared between OGC API services. To override a template used to list features:

      1. Use the directory in the location you wish to override:

        • GEOSERVER_DATA_DIR/templates
        • GEOSERVER_DATA_DIR/workspace/{workspace}
        • GEOSERVER_DATA_DIR/workspace/{workspace}/{datastore}
        • GEOSERVER_DATA_DIR/workspace/{workspace}/{datastore}/{featuretype}
        • ogc/features/landingPage.ftl
      2. Create a file in this location, using the GeoServer 2.24.2 examples below:

        • ogc/features/getfeature-complex-content.ftl
        • ogc/features/getfeature-content.ftl
        • ogc/features/getfeature-empty.ftl
        • ogc/features/getfeature-footer.ftl
        • ogc/features/getfeature-header.ftl

        The above built-in examples are for GeoServer 2.24.2, please check for any changes when upgrading GeoServer.

      As an example customize how collections are listed:

      1. The file ogc/features/collections.ftl lists published collection:

        <#global pagecrumbs=\"<li class='breadcrumb-item'><a href='\"+serviceLink(\"\")+\"'>Home</a></li><li class='breadcrumb-item active'>Collections</li>\">\n<#include \"common-header.ftl\">\n\n  <h1>GeoServer Feature Collections</h1>\n  <p class=\"my-4\">\n    This document lists all the collections available in the Features service.<br/>\n  </p>\n\n  <div class=\"row\">\n    <#list model.collections as collection>\n    <div class=\"col-xs-12 col-md-6 col-lg-4 pb-4\">\n      <div class=\"card h-100\">\n        <div class=\"card-header\">\n          <h2><a href=\"${serviceLink(\"collections/${collection.id}\")}\">${collection.id}</a></h2>\n        </div>\n        <#include \"collection_include.ftl\">\n      </div>\n    </div>\n    </#list>\n  </div>\n\n<#include \"common-footer.ftl\">\n
      2. Save file to GEOSERVER_DATA_DIR/workspace/templates/ogc/collections.ftl, and rewrite as:

        <#include \"common-header.ftl\">\n       <h2>OGC API Feature Collections</h2>\n       <p>List of collections published.</p>\n       <p>See also: <#list model.getLinksExcept(null, \"text/html\") as link>\n          <a href=\"${link.href}\">${link.type}</a><#if link_has_next>, </#if></#list>.</p>\n\n     <#list model.collections as collection>\n       <h2><a href=\"${serviceLink(\"collections/${collection.id}\")}\">${collection.id}</a></h2>\n       <#include \"collection_include.ftl\">\n     </#list>\n<#include \"common-footer.ftl\">\n
      3. Many templates are constructed using #include, for example collection.ftl above uses <#include \"common-header.ftl\"> located next to collections.ftl.

        Presently each family of templates manages its own common-header.ftl (as shown in the difference between ogc/features service templates, and getfeature templates above).

      4. A restart is required, as templates are cached.

        Template collections.ftl override applied

      5. Language codes are appended for internationalization. For French create the file GEOSERVER_DATA_DIR/workspace/{workspace}/ogc/collections_fr.ftl and translate contents:

        <#include \"common-header.ftl\">\n       <h2>OGC API Feature Service</h2>\n       <p>Liste des collections publi\u00e9es.</p>\n       <p>Voir \u00e9galement: <#list model.getLinksExcept(null, \"text/html\") as link>\n          <a href=\"${link.href}\">${link.type}</a><#if link_has_next>, </#if></#list>.</p>\n\n     <#list model.collections as collection>\n       <h2><a href=\"${serviceLink(\"collections/${collection.id}\")}\">${collection.id}</a></h2>\n       <#include \"collection_include.ftl\">\n     </#list>\n<#include \"common-footer.ftl\">\n
      6. For details on how to write templates see Freemarker Templates tutorial.

      "},{"location":"community/ogc-api/maps/","title":"OGC API - Maps","text":"

      A OGC API - Maps based on the current early specification draft, delivering partial functionality:

      • Collection listing
      • Styles per collection
      • Map and info support for single collection

      Missing functionality at the time of writing, and known issues:

      • API definition
      • Maps specific metadata (e.g., scale ranges)
      • Support for multi-collection map representation
      • HTML representation of a map with OpenLayers is only partially functional
      "},{"location":"community/ogc-api/maps/#ogc-api-maps-implementation-status","title":"OGC API - Maps Implementation status","text":"

      OGC API - Maps Version Implementation status

      Part 1: Core Draft Implementation based on early specification draft.

      Part 2: Partitioning Draft Implementation based on early specification draft.

      "},{"location":"community/ogc-api/maps/#installing-the-geoserver-ogc-api-maps-module","title":"Installing the GeoServer OGC API - Maps module","text":"
      1. Download the OGC API nightly GeoServer community module from ogcapi-maps.

        Warning

        Verify that the version number in the filename corresponds to the version of GeoServer you are running (for example geoserver- 2.24.2-ogcapi-maps-plugin.zip above).

      2. Extract the contents of the archive into the WEB-INF/lib directory of the GeoServer installation.

      3. On restart the services are listed at http://localhost:8080/geoserver

      "},{"location":"community/ogc-api/maps/#configuration-of-ogc-api-maps-module","title":"Configuration of OGC API - Maps module","text":"

      The module is based on the GeoServer WMS one, follows the same configuration and exposes the same layers. As a significant difference, Maps does not have a concept of layer tree, so only individual layers and groups can be exposed.

      "},{"location":"community/ogc-api/styles/","title":"OGC API - Styles","text":"

      A OGC Styles API based on the early draft of this specification.

      This service describes, retrieves and updates the styles present on the server. Styles are cross linked with their associated collections in both the Features and Tiles API.

      "},{"location":"community/ogc-api/styles/#ogc-api-styles-implementation-status","title":"OGC API - Styles Implementation status","text":"

      OGC API - Styles Version Implementation status

      Part 1: Core Draft Implementation based on early specification draft.

      "},{"location":"community/ogc-api/styles/#installing-the-geoserver-ogc-api-styles-module","title":"Installing the GeoServer OGC API - Styles module","text":"
      1. Download the OGC API nightly GeoServer community module from ogcapi-styles.

        Warning

        Verify that the version number in the filename corresponds to the version of GeoServer you are running (for example geoserver- 2.24.2-ogcapi-styles-features-plugin.zip above).

      2. Extract the contents of the archive into the WEB-INF/lib directory of the GeoServer installation.

      3. On restart the services are listed at http://localhost:8080/geoserver

      "},{"location":"community/ogc-api/styles/#configuration-of-ogc-api-styles-module","title":"Configuration of OGC API - Styles module","text":"

      At the time of writing the module has no configuration, it's simply exposing all available GeoServer styles.

      "},{"location":"community/ogc-api/tiled-features/","title":"OGC API - Tiled features demonstration","text":"

      This module provides an example of extending the OGC API - Features module with a building block from OGC API - Tiles, used for tiled access to raw vector data (the vector tiles modules is included).

      This module is not required to use vector tiles, it's also possible to use OGC API - Tiles directly, see OGC API - Tiles, along with the installation of the vector tiles extension.

      "},{"location":"community/ogc-api/tiled-features/#installing-the-geoserver-ogc-api-tiled-features-module","title":"Installing the GeoServer OGC API tiled features module","text":"
      1. Download the OGC API nightly GeoServer community module from ogcapi-tiled-features.

        Warning

        Verify that the version number in the filename corresponds to the version of GeoServer you are running (for example geoserver- 2.24.2-ogcapi-tiled-features-plugin.zip above).

      2. Extract the contents of the archive into the WEB-INF/lib directory of the GeoServer installation.

      3. On restart the services are listed at http://localhost:8080/geoserver

      "},{"location":"community/ogc-api/tiled-features/#extensions","title":"Extensions","text":"

      Upon installation, the OGC API - Features API will show the following extensions:

      • Conformance classes are expanded with OGC API - Tiles ones

      • Tile matrix sets links from the home page

        Tile matrix EPSG:4326 definition

      • Collections with vector tiles enabled will have a \"data tiles\" link pointing at the tiles endpoint

        Data tiles link

      "},{"location":"community/ogc-api/tiles/","title":"OGC API - Tiles","text":"

      A OGC Tiles API delivering both tiled data (vector tiles) and tiled maps (classic map tiles).

      GeoServer implementation is based on an ealier specification draft (the specification is now finalized).

      "},{"location":"community/ogc-api/tiles/#ogc-api-tiles-implementation-status","title":"OGC API - Tiles Implementation status","text":"

      OGC API - Tiles Version Implementation status

      Part 1: Core Draft Implementation based on early specification draft, not yet updated to final version

      "},{"location":"community/ogc-api/tiles/#installing-the-geoserver-ogc-api-tiles-module","title":"Installing the GeoServer OGC API - Tiles module","text":"
      1. Download the OGC API nightly GeoServer community module from ogcapi-tiles.

        Warning

        Verify that the version number in the filename corresponds to the version of GeoServer you are running (for example geoserver- 2.24.2-ogcapi-tiles-plugin.zip above).

      2. Extract the contents of the archive into the WEB-INF/lib directory of the GeoServer installation.

      3. On restart the services are listed at http://localhost:8080/geoserver

      "},{"location":"community/ogc-api/tiles/#configuration-of-ogc-api-tiles-module","title":"Configuration of OGC API - Tiles module","text":"

      The module exposes all Tiled layers configured for GeoWebCache using the OGC API - Tiles specification.

      As such, it follows the same WMTS and Tile Caching configuration used to manage GeoWebCache.

      "},{"location":"community/ogr-store/","title":"OGR datastore","text":"

      The OGR datastore module allows to use the GDAL/OGR <https://gdal.org/> native library to access a wide variety of vector spatial formats and publish them in GeoServer.

      This library is recommended to use when a particular data source does not have a GeoServer pure Java datastore fulfilling the same needs, in particular, compared to built in sources, it has the following limitations:

      • Generally slower than the existing pure Java counterparts, especially for map rendering (the GeoServer stores can help rendering by providing reduced resolution version of the geometries, OGR provides no such facility)
      • Less scalable than the pure Java counterparts, as the DataSource objects used to access data are not thread safe (see the pooling options below)
      • More risky than the pure java counterparts, a SEGFAULT occurring inside OGR will take down the entire GeoServer process (while a pure Java exception is managed and reported, but won't have consequences on the server itself)

      The OGR store has been tested with GDAL 2.2.x, but might be working with other versions as well. In case of malfunctions, you can try to remove the gdal-<version>.jar file from the GeoServer installation package, and replace it with the specific version jar instead, which you should find in your GDAL installation.

      "},{"location":"community/ogr-store/#installing","title":"Installing","text":"

      This is a community module, which means that it will not be available in the GeoServer official releases and needs to be installed manually.

      This module can be installed following these steps:

      1. Download this module package from the nightly builds, the module version should match the desired GeoServer version.
      2. Extract the contents of the package into the WEB-INF/lib directory of the GeoServer installation.
      3. Make sure that the GDAL library as well as the GDAL JNI native library are available in the GeoServer path (see below).
      "},{"location":"community/ogr-store/#linux-installation-details","title":"Linux installation details","text":"

      On Linux the native librariers are commonly available via packages such as gdal and gdal-java, which, on installation, make available the required libraries on the file system (the specific name may vary):

      /usr/lib/libgdal.so\n/usr/lib/jni/libgdaljni.so\n

      Normally these directories are already in the PATH, so no further configuration is required.

      If using a custom build instead, the LD_LIBRARY_PATH and GDAL_DATA directories:

      export LD_LIBRARY_PATH /path/to/gdal/libraries\nexport GDAL_DATA /path/to/gdal/data\n

      See also the GDAL FAQ about the GDAL_DATA setup.

      "},{"location":"community/ogr-store/#windows-installation-details","title":"Windows installation details","text":"

      On windows the files in question might look like:

      gdal204.dll\ngdalalljni.dll\n

      Locating a pre-build GDAL that includes Java support might be difficult. One option is to download the gisinternals.com packages, in particular the release zip packages including both mapserver and GDAL (these are rather complete and include the necessary libraries, whilst the MSI installers are typically missing the Java support).

      Once the package is available on disk, one has to set the following environment variables before starting GeoServer (the path might change depending on the package that is being downloaded):

      set PATH=%PATH%;C:\\path\\to\\release-1900-x64-gdal-2-4-0-mapserver-7-2-1\\bin;C:\\tmp\\release-1900-x64-gdal-2-4-0-mapserver-7-2-1\\bin\\gdal\\java\nset GDAL_DRIVER_PATH=C:\\path\\to\\release-1900-x64-gdal-2-4-0-mapserver-7-2-1\\bin\\gdal\\plugins\nset GDAL_DATA=C:\\path\\to\\release-1900-x64-gdal-2-4-0-mapserver-7-2-1\\bin\\gdal-data\n
      "},{"location":"community/ogr-store/#configuring-a-store","title":"Configuring a store","text":"

      If the library is properly installed you will get the \"OGR\" data store among the supported stores in the \"new store\" page. In case it's not there, check the logs, they might be reporting that the GDAL/OGR native libs are missing, if the error is not there, check that the jars have been unpacked in the right position instead.

      Creating a new store requires configuration of only the DatasourceName field, any other parameter is optional:

      The OGR datasore configuration page

      The DatasourceName can be a reference to a file, a directory, or a set of connection parameters to a server. For example, to connect to a PostGIS database the connection parameters could be:

      PG:user=theUser password=thePassword dbname=theDatabase

      Notice how, unlike documented in the OGR page, single quotes are not needed (and actually harmful) around the user/password/dbname section. The Browse button can be used to quickly peek files or directories from the file system.

      The Driver parameter is optional, OGR should be able to recognize the appropriate driver automatically, but it's useful to force a specific choice when multiple competing drivers are available for the same data source (e.g., OpenFileGDB vs FileGDB).

      The pooling parameters, similar to those found in a database, merit an explanation. OGR exposes access to data through DataSource objects, which are not thread safe, so only one request at a time can use them. At the same time, they can be expensive to create and hold onto useful state, like in memory data caches, spatial indexes and the like. As such, they have been stored in a pool much like relational database connections.

      The Prime DataSources option can be enabled to force a full read of the source data before the GDAL DataSource object is used. In some formats this allows the creation of useful support data structures, like an in memory spatial index in the OpenFileGDB format. Since the full read can be expensive, care should be taken to configure the pooling options so that it gets reused as much as possible (e.g., setting a higher min connections, eventually setting it to the same value as max connections).

      "},{"location":"community/opensearch-eo/","title":"OpenSearch for EO","text":"
      • Introduction to OpenSearch for EO
      • Installing the OpenSearch for EO module
      • Configuring the OpenSearch module
      • The JDBC store database structure
      • Automation with the administration REST API
      • The STAC extension
      • OpenSearch/STAC JSON templates
      • Upgrading from previous version
      "},{"location":"community/opensearch-eo/STAC/","title":"The STAC extension","text":"

      The OpenSeach for EO subsystem exposes also a STAC service, implemented as a OGC API Features conformant STAC API.

      The landing page of the STAC API is linked from the GeoServer home page, and available at $HOST:$PORT/geoserver/ogc/stac. The API exposes the OpenSearch for EO contents, restructuring them as needed:

      • The collections table is mapped to STAC collections
      • The products table is mapped to STAC items

      Given the differences in names and structures the STAC resources are created using templates, in particular:

      • The HTML representation is built using Freemarker templates
      • The GeoJSON representation is built using GeoJSON features templates

      The default templates work against the default PostGIS database structure and can be customized to include new properties to follow eventual database modifications.

      All built-in templates are copied over to the data directory for customization, and placed in the $GEOSERER_DATA_DIR/templates/ogc/stac folder:

      • collection.ftl
      • collection_include.ftl
      • collections.ftl
      • collections.json
      • item.ftl
      • item_include.ftl
      • items-content.ftl
      • items-empty.ftl
      • items-footer.ftl
      • items-header.ftl
      • items.json
      • landingPage.ftl
      • queryables-collection.ftl
      • queryables-common.ftl
      • queryables-global.ftl
      • search-content.ftl
      • search-empty.ftl
      • search-footer.ftl
      • search-header.ftl

      Specifically for the JSON output:

      • \\$GEOSERVER_DATA_DIR/templates/ogc/stac/v1/collections.json is the collections template
      • \\$GEOSERVER_DATA_DIR/templates/ogc/stac/v1/items.json is the items template

      The JSON templates in the case of STAC also drive database querying, the exposed STAC properties are back-mapped into database properties by interpreting the template. It is advised to keep property mapping as simple as possible to allow usage of native SQL queries and indexes while accessing the database through the STAC API.

      For both items and collections, collection specific templates can also be provided, which would contain directives and mappings unique to that collection. A collection specific template can be placed in the same templates directory as above, using the naming convention items-<COLLECTION_ID>.json or collections-<COLLECTION_ID>.json, where <COLLECTION_ID> is the collection identifier. For example, if the collection is named SENTINEL2:

      • The collections specific template for it is named collections-SENTINEL2.json
      • The items template specific for it is named items-SENTINEL2.json
      "},{"location":"community/opensearch-eo/STAC/#fields-fragments","title":"Fields fragments","text":"

      When dealing with JSON output for GET requests in the context of STAC service, the module supports the selection of fields based on the inclusion and exclusion semantic described in the field fragments specification. According to the current specification:

      • If no fields query parameter is specified all the item's attribute are returned.
      • If a fields attribute is specified with no values, only the item's default values (the one necessary to have a valid STAC entity) are returned: id,type,geometry,bbox,links,assets,properties.datetime,properties.created.
      • If fields value is specified GeoServer will return always the default attributes, if the user doesn't target them as excluded. Eg. assets will always be present if not exluced explicitly (fields=-assets,...).
      • If only include is specified, these attributes are added to the default set of attributes (set union operation).
      • If only exclude is specified, these attributes are subtracted from the union of the default set of attributes and the include attributes (set difference operation). This will result in an entity that is not a valid Item if any of the excluded attributes are in the default set of attributes, but no error message will be raised by GeoServer.
      • If a attribute is included, e.g. properties, but one or more of the nested attributes is excluded, e.g. -properties.datetime, then the excluded nested attributes will not appear in properties.
      • If an attribute is excluded, e.g. -properties.nestedObj, but one of more of the nested attributes is included, e.g. properties.nestedObject.attribute, then nestedObject will appear in the output with the included attributes only.
      "},{"location":"community/opensearch-eo/STAC/#datacube-extension-support","title":"Datacube Extension Support","text":"

      Support for the STAC Datacube Extension \"cube_dimensions\" elements is available in HTML and JSON templates via the eoSummaries function. eoSummaries supports presenting the following collection-wide summary statistics:

      • min - The minimum value of the field in the collection
      • max - The maximum value of the field in the collection
      • distinct - An array of distinct values of the field in the collection
      • bounds - Minimum and maximum dimension values of the spatial bounding box of the collection (either x or y, presented as a two value array or xmin, xmax, ymin, ymax presented as individual dimension values)

      eoSummaries has three arguments:

      • aggregate - The type of summary statistic. One of \"min\", \"max\", \"distinct\", or \"bounds\".

      • collectionIdentifier - The name of the collection that is being summarized.

      • property - The name of the property being summarized.

        • Note that for the \"bounds\" aggregate, this value should either be \"x\",\"y\",\"xmin\",\"ymin\",\"xmax\", or \"ymax\".

      JSON Template Example:

      \"extent\": {\n  \"spatial\": {\n    \"bbox\": [\n      [\n        \"$${eoSummaries('bounds',eo:parentIdentifier,'xmin')}\",\n        \"$${eoSummaries('bounds',eo:parentIdentifier,'ymin')}\",\n        \"$${eoSummaries('bounds',eo:parentIdentifier,'xmax')}\",\n        \"$${eoSummaries('bounds',eo:parentIdentifier,'ymax')}\"\n      ]\n    ]\n  },\n  \"cube:dimensions\"\\: {\n   \"x\": {\n      \"type\": \"spatial\",\n      \"axis\": \"x\",\n      \"extent\": \"$${eoSummaries('bounds',eo:parentIdentifier,'x')}\",\n      \"reference_system\": 4326},\n          \"y\": {\n          \"type\": \"spatial\",\n          \"axis\": \"y\",\n          \"extent\": \"$${eoSummaries('bounds',eo:parentIdentifier,'y')}\",\n          \"reference_system\": 4326},\n          \"time\": \n              {\"type\": \"temporal\",\n              \"extent\": \n                  [\"$${eoSummaries('min',eo:parentIdentifier,'timeStart')}\",\n              \"$${eoSummaries('min',eo:parentIdentifier,'timeEnd')}\"]\n              }\n      }\n

      HTML/FTL Example:

      <li><b>Extents</b>:\n     <ul>\n    <li data-tid='gbounds'>Geographic (WGS84):\n                ${model.eoSummaries(\"bounds\",a.name.value,\"x\")[0]}, \n                ${model.eoSummaries(\"bounds\",a.name.value,\"y\")[0]}, \n                ${model.eoSummaries(\"bounds\",a.name.value,\"x\")[1]}, \n                ${model.eoSummaries(\"bounds\",a.name.value,\"y\")[1]}.\n            </li>\n            <li data-tid='tbounds'>Temporal: \n                ${model.eoSummaries(\"min\",a.name.value,\"timeStart\")}/\n                ${model.eoSummaries(\"max\",a.name.value,\"timeEnd\")}\n            </li> \n        </ul>\n</li>\n
      "},{"location":"community/opensearch-eo/automation/","title":"Automation with the administration REST API","text":"

      The OpenSearch module supports full automation REST API that can be used to create collections, ingest products and eventually their granules. The full API is available at this URL:

      • /oseo

      In general terms, one would:

      • Create a collection, along with thumbnail, OGC links
      • Then create a product, along with thumbnail, OGC links
      • Finally, and optionally, specify the granules composing the product (actually needed only if the OpenSearch subsystem is meant to be used for publishing OGC services layers too, instead of being a simple search engine.
      "},{"location":"community/opensearch-eo/automation/#understanding-the-zip-file-uploads","title":"Understanding the zip file uploads","text":"

      The description of a collection and product is normally made of various components, in order to expedite data creation and reduce protocol chattines, it is possible to bulk-upload all files composing the description of collections and products as a single zip file.

      "},{"location":"community/opensearch-eo/automation/#collection-components","title":"Collection components","text":"

      A collection.zip, sent as a PUT request to rest/collections would contain the following files:

      Name Optional Description

      collection.json N The collection attributes, matching the database structure (the prefixes are separated with a colon in this document)

      description.html Y The HTML description for the collection

      thumbnail.png, thumbnail.jpg or thumbnail.jpeg Y The collection thumbnail

      owsLinks.json Y The list of OWS links to OGC services providing access to the collection contents (typically as a time enabled layer)

      "},{"location":"community/opensearch-eo/automation/#product-components","title":"Product components","text":"

      A product.zip, sent as a POST request to rest/collections/<theCollection>/products would contain the following files:

      It is also possible to send the zip file on the rest/collections/<theCollection>/products/<theProduct> resource as a PUT request, it will update an existing product by replacing the parts contained in the file. Parts missing from the file will be kept unchanged, to remove them run an explicit DELETE request on their respective REST resources.

      "},{"location":"community/opensearch-eo/automation/#usage-of-the-api-for-search-and-integrated-ogc-service-publishing","title":"Usage of the API for search and integrated OGC service publishing","text":"

      In this case the user intend to both use the OpenSearch module for search purposes, but also to publish actual mosaics for each collection.

      In this case the following approach should is recommended:

      • Create a collection via the REST API, using the ZIP file POST upload
      • Create at least one product in the collection in the REST API, using the ZIP file POST upload and providing a full granules.json content with all the granules of said product
      • Post a layer publishing description file to /oseo/collection/{COLLECTION}/layers to have the module setup a set of mosaic configuration files, store, layer with eventual coverage view and style

      A collection can have multiple layers:

      • Getting the /oseo/collection/{COLLECTION}/layers resource returns a list of the available ones
      • /oseo/collection/{COLLECTION}/layers/{layer} returns the specific configuration (PUT can be used to modify it, and DELETE to remove it).
      • Creation of a layer configuration can be done either by post-ing to /oseo/collection/{COLLECTION}/layers or by put-int to /oseo/collection/{COLLECTION}/layers/{layer}.

      The layer configuration fields are:

      The layer configuration specification will have different contents depending on the collection structure:

      • Single CRS, non band split, RGB or RGBA files, time configured as an \"instant\" (only timeStart used):

        {\n    \"workspace\": \"gs\",\n    \"layer\": \"test123\",\n    \"separateBands\": false,\n    \"heterogeneousCRS\": false,\n    \"timeRanges\": false\n}\n
      • Single CRS, multiband in single file, with a gray browse style, product time configured as a range between timeStart and timeEnd:

        {\n    \"workspace\": \"gs\",\n    \"layer\": \"test123\",\n    \"separateBands\": false,\n    \"browseBands\": [\"test123[0]\"],\n    \"heterogeneousCRS\": false,\n    \"timeRanges\": true\n}\n
      • Heterogeneous CRS, multi-band split across files, with a RGB browse style (\"timeRanges\" not specified, implying it's handled as an instant):

        {\n    \"workspace\": \"gs\",\n    \"layer\": \"test123\",\n    \"separateBands\": true,\n    \"bands\": [\n        \"VNIR\",\n        \"QUALITY\",\n        \"CLOUDSHADOW\",\n        \"HAZE\",\n        \"SNOW\"\n    ],\n    \"browseBands\": [\n        \"VNIR[0]\", \"VNIR[1]\", \"SNOW\"\n    ],\n    \"heterogeneousCRS\": true,\n    \"mosaicCRS\": \"EPSG:4326\"\n}\n

      In terms of band naming the \"bands\" parameter contains coverage names as used in the \"band\" column of the granules table, in case a granule contains multiple bands, they can be referred by either using the full name, in which case they will be all picked, or by using zero-based indexes like BANDNAME[INDEX], which allows to pick a particular band.

      The same syntax is meant to be used in the browseBands property. In case the source is not split band, the browseBands can still be used to select specific bands, using the layer name as the coverage name, e.g. \"test123[0]\" to select the first band of the coverage.

      "},{"location":"community/opensearch-eo/automation/#cog-mosaic-creation","title":"COG Mosaic creation","text":"

      It's also possible to configure a layer on top of a COG ImageMosaic, provided that the COG (Cloud Optimized GeoTIFF) Support plugin has been installed in GeoServer.

      Additional fields for the layer configuration are:

      Attribute Description

      cog Set it to true to specify the layer is made of COG datasets

      cogUser (Optional) Credential to be set whenever basic HTTP authentication is needed to access the COG Datasets or an S3 Access KeyID is required

      cogPassword (Optional) Password for the above user OR Secret Access Key for the above S3 KeyId.

      cogRangeReader (Optional) Specify the desired RangeReader implementation. (default is HTTP based)

      See COG RangeReader from the COG plugin documentation, for the list of supported RangeReader implementations.

      "},{"location":"community/opensearch-eo/configuration/","title":"Configuring the OpenSearch module","text":"

      The OpenSearch module needs to know upon which database perform the searches.

      Follow these steps:

      • Setup a standard PostGIS database pointing to the database and schema created above from the SQL file. Note down the full name of the store (e.g. test:metadata where test is the workspace and metadata is the store name). Besides filling the connection parameters, remember to set \"expose primary keys\" to true.

      • Create a new store of type \"JDBC based OpenSearch store\" and configure the fully qualified name of the basic PostGIS store in its \"store\" parameter.

      • Go into the \"OS-EO\" service configuration page and configure the \"OpenSearch\" store

        • (Optional) You can also configure how long values will be cached for performance purposes for templates that require collection level aggregate statistics by adjusting the cache time to live duration and time units.

      • Global Queryables (applicable to the STAC API to define queryable fields for all Collections) can be configured

      using a comma delimited list in the text box under OpenSearch specific metadata

      "},{"location":"community/opensearch-eo/configuration/#advanced-adding-product-classes","title":"Advanced: adding product classes","text":"

      The design of the OpenSearch module is \"data driven\", meaning that one can materialize new search properties by just adding new columns to the product and collection tables.

      In particular, both tables have a \"prefix based\" convention linking the properties to their respective product types, and the engine will advertise for a particular product only the properties relevant to it. For example, in an optical product, the properties starting with \"opt\" will be listed, but not those starting with \"sar\".

      Here is a table of the product classes known out of the box:

      Name Prefix Namespace Description

      eop_generic eop http://www.opengis.net/eop/2.1 Base properties shared among all EO products. Never remove this class.

      optical opt http://www.opengis.net/opt/2.1 Optical products properties

      radar sar http://www.opengis.net/sar/2.1 Radar products properties

      Altimetric alt http://www.opengis.net/alt/2.1 Altimetric products properties

      Atmospheric atm http://www.opengis.net/atm/2.1 Atmospheric products properties

      Limb lmb http://www.opengis.net/lmb/2.1 Limb products properties

      ssp ssp http://www.opengis.net/ssp/2.1 SSP products properties

      The various properties have different usages:

      • The name is used in the collection to define the type of sensor (eoSensorType column)
      • The prefix is used in the product table as a prefix to column name in order to associate them to a particular product type, shows up as-is in the JSON representations of the REST API, as well as the prefix in XML outputs
      • The namespace is used in XML output, along with the prefix (e.g., xmlns:opt=\"http://www.opengis.net/opt/2.1\")

      It is possible to add new product classes as well as changing the built-in ones, but care should be taken to keep product classes and database aligned. After any change to the database structure remember to \"reset\" the GeoServer configuration to make it re-scan the table structures.

      "},{"location":"community/opensearch-eo/configuration/#oseo_html_templates","title":"HTML templates","text":"

      The Freemarker templates for collections and products can be found in $GEOSERVER_DATA_DIRECTORY/templates/os-eo:

      • generic-header.ftl receives SearchResults, Query, organization, title, updated(date), builder and encodes a generic header Atom HTML description for it.
      • generic-footer.ftl exists simple for having a closing tag.
      • product.ftl receives an OpenSearch product, updated(date), dcDate(date), offerings and encodes the Atom HTML description for it.
      • collection.ftl receives an OpenSearch collection, updated(date), dcDate(date), offerings and encodes the Atom HTML description for it.

      The default templates, linked above, report the time range for the product/collection, and link to other pertinent OpenSearch resources (metadata, self link, quicklooks).

      Collection specific templates can be set up in the data directory, appending the collection identifier to the file name, e.g. collection-SENTINEL2.ftl or product-SENTINEL2.ftl.

      The templates can use a oseoLink function to build links pointing back to the OpenSearch service. The function receives the following parameters:

      • The first argument is a path segment under the oseo service path.
      • The other arguments, optional, are couple of keys and values, used to encode the link's query string.
      "},{"location":"community/opensearch-eo/configuration/#oseo_metadata_templates","title":"Metadata templates","text":"

      The Freemarker metadata templates for collections and products can be found in $GEOSERVER_DATA_DIRECTORY/templates/os-eo:

      • product-metadata.ftl receives an OpenSearch product and encodes the Atom HTML description for it.
      • collection-metadata.ftl receives an OpenSearch collection and encodes the Atom HTML description for it.

      The default templates, linked above, generate respectively a ISO metadata sheet for collections, and a EO O&M product metadata sheet for products.

      The templates can use a oseoLink function to build links pointing back to the OpenSearch service. The function receives the following parameters:

      • The first argument is a path segment under the oseo service path.
      • The other arguments, optional, are couple of keys and values, used to encode the link's query string.

      The templates can also use a gml function that generates a GML 3.2 representation of a geometry (mind, the output must be forced not to be escaped, using ?no_esc, as well as minx, miny, maxx, maxy that can be used to extract the bounding box corner values. All these function expect a geometry as input.

      Finally templates can use a loadJSON function to read a JSON from a file inside the GeoServer data directory. The path to the JSON file can be absolute eg. \"${loadJSON('/path/to/read.json')}\", or a plain file name, in case the JSON file is present in the GeoServer root directory eg. \"${loadJSON('read.json')}\".

      The function returns a string JSON that can be parsed using the ?eval_json free marker built-in function: <#assign loadedJSON = \"${loadJSON('readAndEval.json')}\"> <#assign evalJSON = loadedJSON?eval_json>

      More information about writing templates can be found in the templates guide.

      "},{"location":"community/opensearch-eo/configuration/#geojson-output-templates","title":"GeoJSON output templates","text":"

      The module supports GeoJSON encoding of collections and products according to the <https://docs.opengeospatial.org/is/17-047r1/17-047r1.html>>_.

      Give the structure required in output, it's not possible to use the simple features GeoJSON encoders. The module is instead using two dedicated features templates, that the user can customize to match the database structure.

      The default templates are part of the GeoServer distribution, and are automatically copied to the data directory on startup, to allow for customization:

      • \\$GEOSERVER_DATA_DIR/templates/os-eo/products.json is the products template
      • \\$GEOSERVER_DATA_DIR/templates/os-eo/collections.json is the collections template

      The default templates work against the default PostGIS database structure and can be customized to include new properties to follow eventual database modifications.

      Collection specific templates can also be provided, which would contain directives and mappings unique to that collection. A collection specific template can be placed in the same templates directory as above, called either collections-<COLLECTION_ID>.json or products-<COLLECTION_ID>.json where <COLLECTION_ID> is the collection identifier. For example, if the collection is named SENTINEL2 a products template specific for it will be named products-SENTINEL2.json, while the collection template will be named collections-SENTINEL2.json.

      More information about writing templates can be found in the templates guide.

      "},{"location":"community/opensearch-eo/database/","title":"The JDBC store database structure","text":"

      The JDBC store uses a conventional relational structure, depicted in the following picture:

      So a collection has its own primary search attributes, as well as:

      • Zero or more OGC links pointing to where the collection is published
      • Layer publishing information (for auto-generation of mosaic, layer and eventual coverage view in case the actual data resides locally)
      • One or more products

      A product in turn is associated to:

      • A thumbnail image, in PNG or JPEG format
      • Zero or more OGC links pointing to where the product is published

      The granule table is designed to contain per product file information in case there is a desire to publish the actual data from the same local GeoServer (but in general, OGC services might be missing or provided by a separate server).

      "},{"location":"community/opensearch-eo/database/#collections","title":"Collections","text":"

      The collection table currently looks as follows (check the SQL file in the installation instructions for a more up to date version of it):

      create table collection (\n  \"id\" serial primary key,\n  \"name\" varchar,\n  \"primary\" boolean,\n  \"htmlDescription\" text,\n  \"footprint\" geography(Polygon, 4326),\n  \"timeStart\" timestamp,\n  \"timeEnd\" timestamp,\n  \"productCqlFilter\" varchar,\n  \"masked\" boolean,\n  \"eoIdentifier\" varchar unique,\n  \"eoProductType\" varchar,\n  \"eoPlatform\" varchar,\n  \"eoPlatformSerialIdentifier\" varchar,\n  \"eoInstrument\" varchar,\n  \"eoSensorType\" varchar check (\"eoSensorType\" in ('OPTICAL', 'RADAR', 'ALTIMETRIC', 'ATMOSPHERIC', 'LIMB')),\n  \"eoCompositeType\" varchar,\n  \"eoProcessingLevel\" varchar,\n  \"eoOrbitType\" varchar,\n  \"eoSpectralRange\" varchar,\n  \"eoWavelength\" int,\n  \"eoSecurityConstraints\" boolean,\n  \"eoDissemination\" varchar,\n  \"eoAcquisitionStation\" varchar,\n  \"queryables\" varchar[],\n  \"workspaces\" varchar[]\n);\n

      Most of the attributes should be rather self-explanatory to those familiar with OGC Earth Observation terminology. Each attribute prefixed by \"eo\" is exposed as a search attribute in OpenSearch, the structure can be modified by adding extra attributes and they will show up and made searchable.

      Specific attributes notes:

      • A primary collection is normally linked to a particular satellite/sensor and contains its own products. Setting \"primary\" to false makes the collection \"virtual\" and the productCQLFilter field should be filled with a CQL filter that will collect all the products in the collection (warning, virtual collections are largely untested at the moment)
      • The footprint field is used for spatial searches, while timeStart and timeEnd are used for temporal ones
      • The htmlDescription drives the generation of the visible part of the Atom OpenSearch response, see the dedicated section later to learn more about filling it
      • The workspaces field is an array used to specify the GeoServer workspaces that the collection is associated with. If the field is left empty or null, or if the array contains a null value, the collection will be associated with all workspaces. If the field is populated, the collection will only be associated with the specified workspaces and will be hidden from workspace specific STAC calls.

      The collection_ogclink table contains the OGC links towards the services providing visualization and download access to the collection contents. See the \"OGC links\" section to gather more information about it.

      "},{"location":"community/opensearch-eo/database/#products","title":"Products","text":"

      The product table currently looks as follows (check the SQL file in the installation instructions for a more up to date version of it):

      -- the products and attributes describing them\ncreate table product (\n  \"id\" serial primary key,\n  \"htmlDescription\" text,\n  \"footprint\" geography(Polygon, 4326),\n  \"timeStart\" timestamp,\n  \"timeEnd\" timestamp,\n  \"originalPackageLocation\" varchar,\n  \"originalPackageType\" varchar,\n  \"thumbnailURL\" varchar,\n  \"quicklookURL\" varchar,\n  \"crs\" varchar,\n  \"eoIdentifier\" varchar unique,\n  \"eoParentIdentifier\" varchar references collection(\"eoIdentifier\") on delete cascade,\n  \"eoProductionStatus\" varchar,\n  \"eoAcquisitionType\" varchar check (\"eoAcquisitionType\" in ('NOMINAL', 'CALIBRATION', 'OTHER')),\n  \"eoOrbitNumber\" int,\n  \"eoOrbitDirection\" varchar check (\"eoOrbitDirection\" in ('ASCENDING', 'DESCENDING')),\n  \"eoTrack\" int,\n  \"eoFrame\" int,\n  \"eoSwathIdentifier\" text,\n  \"optCloudCover\" int check (\"optCloudCover\" between 0 and 100),\n  \"optSnowCover\" int check (\"optSnowCover\" between 0 and 100),\n  \"eoProductQualityStatus\" varchar check (\"eoProductQualityStatus\" in ('NOMINAL', 'DEGRADED')),\n  \"eoProductQualityDegradationStatus\" varchar,\n  \"eoProcessorName\" varchar,\n  \"eoProcessingCenter\" varchar,\n  \"eoCreationDate\" timestamp,\n  \"eoModificationDate\" timestamp,\n  \"eoProcessingDate\" timestamp,\n  \"eoSensorMode\" varchar,\n  \"eoArchivingCenter\" varchar,\n  \"eoProcessingMode\" varchar,\n  \"eoAvailabilityTime\" timestamp,\n  \"eoAcquisitionStation\" varchar,\n  \"eoAcquisitionSubtype\" varchar,\n  \"eoStartTimeFromAscendingNode\" int,\n  \"eoCompletionTimeFromAscendingNode\" int,\n  \"eoIlluminationAzimuthAngle\" float,\n  \"eoIlluminationZenithAngle\" float,\n  \"eoIlluminationElevationAngle\" float,\n  \"sarPolarisationMode\" varchar check (\"sarPolarisationMode\" in ('S', 'D', 'T', 'Q', 'UNDEFINED')),\n  \"sarPolarisationChannels\" varchar check (\"sarPolarisationChannels\" in ('horizontal', 'vertical')),\n  \"sarAntennaLookDirection\" varchar check (\"sarAntennaLookDirection\" in ('LEFT', 'RIGHT')),\n  \"sarMinimumIncidenceAngle\" float,\n  \"sarMaximumIncidenceAngle\" float,\n  \"sarDopplerFrequency\" float,\n  \"sarIncidenceAngleVariation\" float,\n  \"eoResolution\" float\n);\n

      Notes on the attributes:

      • The footprint field is used for spatial searches, while timeStart and timeEnd are used for temporal ones
      • The htmlDescription drives the generation of the visible part of the Atom OpenSearch response, see the dedicated section later to learn more about filling it
      • The crs attribute is optional and is used only for automatic layer publishing for collections having heterogeneous CRS products. It must contain a \"EPSG:XYWZ\" expression (but the product footprint still need to be expressed in WGS84, east/north oriented).
      • The EO search attributes need to be filled according to the nature of the product, eo prefixes generic EOP attributes, opt optical ones, sar radar ones, atm altimetric, lmb limbic, ssp Synthesis and Systematic Product. New attributes can be added based on the above prefixes (at the time of writing only optical and sar attributes have been tested)

      The product_thumb table contains the product thumbnail, in PNG or JPEG format, for display in the OpenSearch Atom output.

      The product_ogclink table contains the OGC links towards the services providing visualization and download access to the collection contents. See the \"OGC links\" section to gather more information about it.

      "},{"location":"community/opensearch-eo/database/#ogc-links","title":"OGC links","text":"

      The OpenSearch module implements \"OGC cross linking\" by adding pointers to OGC services for to collection/product visualization and download.

      -- links for collections\ncreate table collection_ogclink (\n  \"lid\" serial primary key,\n  \"collection_id\" int references collection(\"id\") on delete cascade,\n  \"offering\" varchar,\n  \"method\" varchar,\n  \"code\" varchar,\n  \"type\" varchar,\n  \"href\" varchar\n);\n\n-- links for products\ncreate table product_ogclink (\n  \"lid\" serial primary key,\n  \"product_id\" int references product(\"id\") on delete cascade,\n  \"offering\" varchar,\n  \"method\" varchar,\n  \"code\" varchar,\n  \"type\" varchar,\n  \"href\" varchar\n);\n

      This is done by adding a set of owc:offering elements in the Atom response, mapping directly from the table contents:

      <owc:offering code=\"http://www.opengis.net/spec/owc/1.0/req/atom/wcs\">\n  <owc:operation method=\"GET\" code=\"GetCapabilities\" href=\"http://localhost/sentinel2/sentinel2-TCI/ows?service=WCS&amp;version=2.0.1&amp;request=GetCapabilities\" type=\"application/xml\"/>\n</owc:offering>\n<owc:offering code=\"http://www.opengis.net/spec/owc/1.0/req/atom/wmts\">\n  <owc:operation method=\"GET\" code=\"GetCapabilities\" href=\"http://localhost/sentinel2/sentinel2-TCI/gwc/service/wmts?REQUEST=GetCapabilities\" type=\"application/xml\"/>\n</owc:offering>\n<owc:offering code=\"http://www.opengis.net/spec/owc/1.0/req/atom/wms\">\n  <owc:operation method=\"GET\" code=\"GetCapabilities\" href=\"http://localhost/sentinel2/sentinel2-TCI/ows?service=wms&amp;version=1.3.0&amp;request=GetCapabilities\" type=\"application/xml\"/>\n  <owc:operation method=\"GET\" code=\"GetMap\" href=\"http://localhost/sentinel2/sentinel2:sentinel2-TCI/wms?SERVICE=WMS&amp;VERSION=1.1.1&amp;REQUEST=GetMap&amp;FORMAT=image%2Fjpeg&amp;STYLES&amp;LAYERS=sentinel2%3Asentinel2-TCI&amp;SRS=EPSG%3A4326&amp;WIDTH=800&amp;HEIGHT=600&amp;BBOX=-180%2C-90%2C180%2C90\" type=\"image/jpeg\"/>\n</owc:offering>\n

      The contents of the tables need to be filled with the sane named elements of a OWC offering, the href one can contain a ${BASE_URL} variable that GeoServer will replace with its own base URL.

      "},{"location":"community/opensearch-eo/database/#the-granule-table","title":"The granule table","text":"

      The granule table can be filled with information about the actual raster files making up a certain product in order to publish the collection as a GeoServer image mosaic:

      -- the granules table (might be abstract, and we can use partitioning)\ncreate table granule (\n  \"gid\" serial primary key,\n  \"product_id\" int not null references product(\"id\") on delete cascade,\n  \"band\" varchar,\n  \"location\" varchar not null,\n  \"the_geom\" geometry(Polygon, 4326) not null\n);\n

      The granules associated to a product can have different topologies:

      • A single raster file containing all the information about the product
      • Multiple raster files splitting the products spatially in regular tiles
      • Multiple raster files splitting the product wavelength wise
      • A mix of the two above

      Notes about the columns:

      • The band column need to be filled only for products split in several files by bands, at the time of writing it needs to be a progressive integer starting from 1 (the module will hopefully allow more meaningful band names in the future)
      • The location is the absolute path of the file
      • The the_geom field is a polygon in WGS84, regardless of what the actual footprint of the file is. The polygon must represent the rectangular extend of the raster file, not its valid area (masking is to be treated separately, either with sidecar mask files or with NODATA pixels)
      "},{"location":"community/opensearch-eo/installation/","title":"Installing the OpenSearch for EO module","text":"

      The installation of the module requires four steps:

      • Setting up a PostGIS database with the required schema
      • Install the OpenSearch for EO plugin and configure it
      • Fill the database with information about collection and metadata
      "},{"location":"community/opensearch-eo/installation/#setting-up-the-postgis-database","title":"Setting up the PostGIS database","text":"

      Create a PostgreSQL database and run the following SQL script:

      https://raw.githubusercontent.com/geoserver/geoserver/main/src/community/oseo/oseo-core/src/test/resources/postgis.sql\n
      "},{"location":"community/opensearch-eo/installation/#downloading-and-installing-the-opensearch-extension","title":"Downloading and installing the OpenSearch extension","text":"

      The module is a community one, and thus available among the nightly builds of the desired series (the module works for 2.12.x onwards):

      • Check the download page <http://geoserver.org/download/> for the desired series (development, stable or maintenance)

      • Follow the nightly build links

      • Check the community-latest folder

      • Download the geoserver-<VERSION>-SNAPSHOT-opensearch-eo-plugin.zip file, and unzip its contents in the GeoServer unpacked WAR lib directory, e.g., \"geoserver/WEB-INF/lib\"

      • Restart GeoServer

        The GeoServer home page after the OpenSearch for EO module installation.

      "},{"location":"community/opensearch-eo/intro/","title":"Introduction to OpenSearch for EO","text":"

      This plugin adds support for the OpenSearch for Earth Observation protocol to GeoServer. References:

      • OpenSearch
      • OpenSearch parameter extension
      • OpenSearch Geo and Time extension
      • OpenSearch for Earth Observation

      The OpenSearch plugin organizes data in \"Collections\" and \"Products\":

      • A collection is a set of products with some uniformity, described by some search attributes and a ISO metadata sheet
      • A product is a set of images (and ancillary information), describe by some search attributes and a O&M metadata sheet

      The system allows the common EO \"two level\" searches, that is:

      • Firsts lookup for the desired collection of data on the main OSDD document
      • Once the collection is located, a second OSDD providing access to the product search is delivered

      If the database contains also the OGC cross links, the Atom search outputs will also contain links allowing a client to jump from the data search to the actual data visualization and exploitation on OGC services.

      "},{"location":"community/opensearch-eo/intro/#search-engine-storage","title":"Search engine storage","text":"

      The OpenSearch protocol implementation relies on an extension of GeoTools DataAccess called OpenSearchAccess. At the time of writing a single implementation of such interface exists, called JDBCOpenSearchAccess, built and tested to work against a specific PostGIS database schema.

      Note

      The JDBCOpenSearchAccess is written in general enough terms that other databases should be usable as well, but it's likely some code improvements will be required to deal with certain databases naming restrictions (e.g., Oracle).

      In the future we hope to see other implementations as well, based on storage that might be more suitable for large scale search engine such as SOLR or ElasticSearch.

      "},{"location":"community/opensearch-eo/templates/","title":"OpenSearch/STAC JSON templates","text":"

      General rules for writing the (Geo)JSON templates:

      • Single // and multiline /* ... */ comments are allowed in the input, for the editor's convenience. and will be discarded in the output.
      • The properties follow the same names as the OpenSearch queryables:
        • If the column in the database has no prefix, use none in the template too (e.g. startTime).
        • If the column has a prefix, it gets transformed, so for example, eoInstrument in the database becomes eo:instrument in the template.
        • The \"eo\" prefix has a special rule, when it's used in the products table, it's called eop in the template. For example the column eoSensorMode in the products tables becomes eop:sensorMode.
      • Two special CQL functions assist in the creation of links:
        • serviceLink takes a URL template using the Java Formatter syntax and all the subsequent parameters are meant to be replaced in the template, one by one. This is used for links that are built on the fly based on product/collection attributes only.
        • templateLink takes a URL template using a single ${BASE_URL} placeholder, and replaces it with the base URL of the request. This is already used by RSS output, and assumes the links are contained database fields, like the OGC links.

      For information about building feature templates, refer to the features templating documentation.

      "},{"location":"community/opensearch-eo/upgrading/","title":"Upgrading from previous version","text":""},{"location":"community/opensearch-eo/upgrading/#removal-of-htmldescription","title":"Removal of htmlDescription","text":"

      Starting with version 2.20 the OpenSearch module dropped the HTML template columns in the database, and switched to freemarker templates instead. This relieves the database from a significant burden, especially on the products table.

      The default templates are automatically used, and the old htmlDescription columns ignored (they should therefore be removed).

      In order for the default collection.ftl to work, two new fields, title and description, should be added to the database structure, if not already present.

      As a result of these changes, the REST resources previously used to manage the description templates have been removed, and residual HTML description templates included in product or collection zips will be ignored.

      The replacement Freemarker templates are located in the data directory<oseo_html_templates> and can be thus managed via the /resource REST API.

      "},{"location":"community/opensearch-eo/upgrading/#removal-of-collection_metadata-and-product_metadata","title":"Removal of collection_metadata and product_metadata","text":"

      Starting with version 2.20 the OpenSearch module dropped the metadata storage tables from the database, and switched to freemarker templates instead. This relieves the database from a significant burden, especially on the products metadata table.

      The default templates are automatically used, and the old metadata tables are ignored (they should therefore be removed).

      As a result of these changes, the REST resources previously used to manage the metadata have been removed, and residual metadata xml files included in product or collection zips will be ignored.

      The replacement Freemarker templates are located in the data directory<oseo_metadata_templates> and can be thus managed via the /resource REST API.

      "},{"location":"community/pgraster/pgraster/","title":"PGRaster","text":"

      The PGRaster geoserver module adds the ability to simplify the configuration of a PostGis Raster based ImageMosaic-JDBC store. Before proceeding, make sure to take a look to the PostGis Raster plugin documentation for background information. Note that configuration files, table creations and raster imports explained in that documentation, will be automatically handled by this module.

      This module allows to do the following steps automatically:

      1. use raster2pgsql (optionally) to import raster tiles previously configured with gdal_retile
      2. create a metadata table (optionally) referring to tiles tables created through raster2pgsql
      3. create the imageMosaic JDBC XML configuration containing PostGis database connection parameters, attributes mapping and coverage configuration.
      4. configure the imageMosaic JDBC on top of the newly configured XML.
      "},{"location":"community/pgraster/pgraster/#requirements","title":"Requirements","text":"
      • You must have a PostGIS 2.0 database where your raster tiles will be stored.
      • Raster tiles should have been previously created using gdal_retile since this module will simply import them and configure the store. The ImageMosaic JDBC setup example documentation provides examples of how to do that.
      • In case you want to perform automatic import of the raster tiles into the database, you need to have raster2pgsql and psql executables installed on your machine and configured on your PATH. (In case your PostGIS 2.0 installation is on the same machine where you will run GeoServer, the executables should be already available).
      "},{"location":"community/pgraster/pgraster/#installation","title":"Installation","text":""},{"location":"community/pgraster/pgraster/#download-the-pgraster-community-module-for-your-version-of-geoserver-from-the-pre-220-download-page-or-from-the-220-download-page","title":". Download the pgraster community module for your version of GeoServer from the pre 2.20 download page or from the 2.20+ download page.","text":"
      1. Unzip the archive into the WEB-INF/lib directory of the GeoServer installation.

        Note

        On Windows, make sure to add a RASTER2PGSQL_PATH=Drive:\\Path\\to\\bin\\folder\\containing_raster2pgsqlExecutable property to the JAVA_OPTS as an instance: JAVA_OPTS=-DRASTER2PGSQL_PATH=C:\\work\\programs\\PostgreSQL\\9.2\\bin

      2. Restart GeoServer.

      "},{"location":"community/pgraster/pgraster/#usage","title":"Usage","text":"
      1. As for any other store configuration, go to Stores->Add new Store

      2. Select ImageMosaicJDBC. You will see the usual \"Add Raster Data Source\" form.

        For backward compatibility, you may still configure an ImageMosaicJDBC in the old-way, by specifying the URL of a valid XML configuration file, as done in the past (Where all the components of the ImageMosaicJDBC need to be configured by hand by the user).

      3. Notice the presence of a checkBox which allows to proceed with the PGRaster automatic configuration parameters specification. Once Clicking on it, you will see a set of new parameters for the automatic configuration step. When enabling that checkBox, the URL parameter needs to point to the main folder containing the rasters which have been previously produced using gdal_retile.

        Other parameters are explained below:

      Name Description

      PostGIS server The PostGIS server IP

      PostGIS port The PostGIS server port

      User The PostGIS DB user

      Password The PostGIS DB password

      Database The PostGIS Database (should have already been created)

      Schema The schema where the table will be created (default is public. The schema need to be already defined into the Database before the import)

      Table The name of the metadata table which contains all the references to

      File extension The extension of the raster files to be imported (such as png). It may not be specified when raster tiles have been already manually imported into the database by the user

      raster2pgsql import options The raster2pgsql script importing options (as an instance \"-t 128x128\" for raster tiles of 128x128). It may not be specified when raster tiles have been already manually imported into the database by the user

      EPSG Code The EPSG code which will be configured in the coverage configuration xml. (Default is 4326)

      "},{"location":"community/pgraster/pgraster/#limitations","title":"Limitations","text":"

      Right now it doesn't allow to import data folders which have been created with the gdal_retile's useDirForEachRow option.

      "},{"location":"community/proxy-base-ext/","title":"Proxy Base Extension","text":"

      This extension allows the replacement of URLs in the response of a web service request with a different URL. This is useful in order to proxy a web service request to a different server, while still retaining the original URL in the response.

      • Installing the Proxy Base extension
      • Using the Proxy Base Extension module
      "},{"location":"community/proxy-base-ext/install/","title":"Installing the Proxy Base extension","text":"

      The Proxy Base extension is listed among the other extension downloads on the GeoServer download page.

      The installation process is similar to other GeoServer extensions:

      1. Visit the website download page, locate your release, and download: proxy-base-ext

        Verify that the version number in the filename (for example 2.24.2 above) corresponds to the version of GeoServer you are running.

      2. Extract the contents of the archive into the WEB-INF/lib directory in GeoServer. Make sure not to create any sub-directories during the extraction process.

      3. Restart GeoServer.

      On successful installation, a new Proxy Base Extension entry will appear in the left menu, under \"Settings\".

      The Proxy Base Extension menu entry

      "},{"location":"community/proxy-base-ext/usage/","title":"Using the Proxy Base Extension module","text":"

      This extension allows the replacement of URLs in the response of a web service request with a different URL. This is useful in order to proxy a web service request to a different server, while still retaining the original URL in the response. An example of this is proxying a WMS request to a different server, but wanting to keep the original URL in the elements of the GetCapabilities response. E.g., rather than exposing WMS at: http://myserver/geoserver/wms The module allows exposing the service at: http://wms.mycompany.com/ and making sure all backlinks in the Capabilities document point to such host.

      "},{"location":"community/proxy-base-ext/usage/#proxy-base-extension-rules","title":"Proxy Base Extension Rules","text":"

      Proxy Base Extension rules allow the matching of the URLs for alteration based on their path elements and followed by the specification a replacement for the entire URL.

      A Proxy Base Extension rule is defined by three mandatory attributes:

      Attribute Description

      Position The priority of the rule, the lower the number the higher the priority. Rules are applied on a first match basis.

      Matcher The pattern used to match against paths. Regular expressions can be used to achieve matches.

      Transformer The transformation that will be applied to the entire URL. Literal expressions can be used to achieve transformations based on matching header values.

      The following example shows a rule that will match any URL contains the substring wfs in the path (the example matcher value is .*/wfs) and replace the full URL (the example transformer value is https://wfs.eastern.com/${myCollection}/${yourFeature}) with https://wfs.eastern.com/ABigCollection/AnImportantFeature if the myCollection header is set to ABigCollection and the yourFeature header is set to AnImportantFeature. Note that if one or more of the headers referenced in the transformer by literal expressions are not present the rule will not be applied.

      Example of a Proxy Base Extension rule:

      Example of a Proxy Base Extension rule defined in the UI

      This rule will transform the URL (when the myCollection and yourFeature headers are set):

      http://localhost:8080/geoserver/wfs\n

      to:

      https://wfs.eastern.com/ABigCollection/AnImportantFeature\n
      "},{"location":"community/proxy-base-ext/usage/#rules-management","title":"Rules Management","text":"

      Rules can be managed and tested with simulated headers in the rules management UI. Besides the basic operations like add, remove and update is also possible to activate or deactivate rules. A deactivated rule will be ignored by this module.

      Rules management UI

      Attribute Description

      Position The priority of the rule, the lower the number the higher the priority. Rules are applied on a first match basis.

      Matcher The pattern used to match against paths. Regular expressions can be used to achieve matches.

      Transformer The transformation that will be applied to the entire URL. Literal expressions can be used to achieve transformations based on matching header values.

      Active When this box is checked, the rule will be applied.

      Edit Click to launch an editor for this specific rule.

      Input The input URL to be tested against the rules listed above.

      Headers If the rule to be tested has literal expressions, simulated headers for the test can be entered here in Properties File Format (equal sign separated, with each header on a new line).

      Output The result of applying the rules to the input URL will be displayed here after the Test button is clicked.

      "},{"location":"community/proxy-base-ext/usage/#rest-api","title":"REST API","text":"

      The rules can also be managed by means of a REST API found at geoserver/rest/proxy-base-ext. Documentation for it is available in Swagger format

      "},{"location":"community/rat/","title":"Raster Attribute Table support","text":"

      A GDAL Raster Attribute Table (RAT) is a data structure associated with a raster dataset, providing a way to associate attribute information for individual pixel values within the raster. Essentially, it acts as a tabular data structure that links each cell value in the raster to one or more attributes.

      The RAT consists of rows and columns, where each row corresponds to a unique cell value in the raster, and each column represents a different attribute or property of those cells. These attributes can be numerical, categorical, text-based and may include information like land cover types, elevation values, or any other relevant data, but may also contain color information that can be used to render the raster in a more visually appealing way.

      The RAT is stored in a separate file from the raster data itself, and is typically stored in a \".aux.xml\" file, as part of a a PAMDataset. Each of the bands in the PAM can contain a separate RAT, allowing for different attributes to be associated with each band.

      One example of RAT usage is the NOAA Bluetopo dataset, which contains 3 floating points bands:

      • The first band contains bathymetry data
      • The second band contains a measure of uncertainty
      • The third band, dubbed \"contributor\", links to a RAT that contains various information about the source of the data, such as the name of the source institution, the source license, date of survey, and more.

      In this section:

      • Installing the RAT module
      • Using the RAT Module
      "},{"location":"community/rat/installing/","title":"Installing the RAT module","text":"

      To install the Raster Attribute Table support:

      1. Download the rat community extension from the appropriate nightly build. The file name is called geoserver-*-rat-plugin.zip, where * matches the version number of GeoServer you are using.
      2. Extract this these files and place the JARs in WEB-INF/lib.
      3. Perform any configuration required by your servlet container, and then restart.
      "},{"location":"community/rat/using/","title":"Using the RAT Module","text":"

      The RAT modules adds facilities to explore a Raster Attribute Table, and generate styles based on a classification column of choice.

      If the source raster contains a RAT, a new panel will appear in the Publishing tab of the layer.

      The table allows for exploration of the attribute table, while the toolbar at the top allows to generate styles based on the table contents:

      • The Band dropdown allows to select a raster band.
      • The Classification dropdown allows to select a column to use for classification.
      • The Style name controls the name of the style to be generated. It's automatically filled with a naming convention of <layer>_b<band>_<classification>, but can be customized.
      • The Create style button generates the style based on the chosen classification, eventually using colors if available in the table, otherwise generating random colors. The geneated style will also be included among the \"alternate styles\" of the layer.

      The generated style will match all the values in the raster attribute table, and ensure the chosen classification column is used for both styling, legend generation, and GetFeatureInfo output.

      Here is an example style:

      <?xml version=\"1.0\" encoding=\"UTF-8\"?><sld:StyledLayerDescriptor xmlns:sld=\"http://www.opengis.net/sld\" xmlns:gml=\"http://www.opengis.net/gml\" xmlns:ogc=\"http://www.opengis.net/ogc\" xmlns=\"http://www.opengis.net/sld\" version=\"1.0.0\">\n  <sld:NamedLayer>\n    <sld:Name>Class</sld:Name>\n    <sld:UserStyle>\n      <sld:Name>Class</sld:Name>\n      <sld:FeatureTypeStyle>\n        <sld:Rule>\n          <sld:Name>Class</sld:Name>\n          <sld:RasterSymbolizer>\n            <sld:ColorMap type=\"intervals\">\n              <sld:ColorMapEntry color=\"#000A64\" opacity=\"1.0\" quantity=\"-1.0E25\" label=\"zero\"/>\n              <sld:ColorMapEntry color=\"#641400\" opacity=\"1.0\" quantity=\"3.0E12\" label=\"one\"/>\n              <sld:ColorMapEntry color=\"#C81E32\" opacity=\"1.0\" quantity=\"1.0E20\" label=\"two\"/>\n              <sld:ColorMapEntry color=\"#FFFFFF\" opacity=\"0.0\" quantity=\"5.0E25\"/>\n            </sld:ColorMap>\n            <sld:VendorOption name=\"addAttributeTable\">true</sld:VendorOption>\n          </sld:RasterSymbolizer>\n        </sld:Rule>\n      </sld:FeatureTypeStyle>\n    </sld:UserStyle>\n  </sld:NamedLayer>\n</sld:StyledLayerDescriptor>\n

      This is a map generated using the style, with the GetFeatureInfo containing the classification as an extra attribute:

      "},{"location":"community/rat/using/#rest-api","title":"REST API","text":"

      A REST API is available, to fetch the full PAM dataset attached to a raster, and to create styles out of RAT classfication fields:

      • /rat
      "},{"location":"community/remote-wps/","title":"WPS Remote community module","text":"

      The GeoServer WPS remote module allows to discover, run and monitor processes running on one or more remote machines, exposing them via the WPS protocol and allowing both synchronous and asynchronous runs of the same, with eventual progress monitoring.

      The remote process can be anything, from a Python script or a command line executable. The only constraint is to have a remote component able to handle few RPCs, like run, progress, complete (which means collect and send the outcome to the GeoServer machine), execution error (which means if any error occurs report the exception) and kill. On GeoServer side the module manages the same RPCs in order to perform the integration with the WPS. All the communications and command take place over the XMPP protocol, as a suitable cross-language communication system

      A reference implementation of the remote end is available at https://github.com/geoserver/wps-remote, a configurable Python/XMPP wrapper for remote commands. The Python XMPP wrapper resides into the remote machine and is able to send a presentation of the remote process through an XMPP message by JSON-encoding into the body the process inputs/outputs parameter descriptors along with their type. On the GeoServer side the WPS Remote module automatically recognizes and loads an XMPP implementation of the RemoteClient. The GeoServer plugin is able to inquire for new available services, un-marshall their inputs and outputs and build appropriate process wrapper for GeoServer WPS to use. At execution time, the new Process is able to interact with the RemoteClient plug-in implementation in order to send a request to the Service.py, follow the status of the remote process and get the outputs at the end.

      "},{"location":"community/remote-wps/#orchestrating-remote-executable-through-geoserver-wps-and-xmpp","title":"Orchestrating remote executable through GeoServer WPS and XMPP","text":"

      The Remote WPS infrastructure is designed to run external programs asynchronously through the standard OGC WPS protocol interface on remote machines and to track their progress through the XMPP Protocols.

      The infrastructure relies on an XMPP Server (which can be external or embedded) in order to implement a message passing distributed infrastructure that uses the XMPP protocols for exchanging control and status messages between the GeoServer instances and the executables running on remote machines.

      A Python based framework, along with addoc GeoServer plugins, manages and translates the XMPP messages by decoupling the custom mechanism of launching external executables running on remote machines from the standard way of invoking OGC WPS compliant processes in GeoServer.

      The OGC WPS process I/O map is automatically generated by the Remote WPS GeoServer plug-ins at runtime. Every time the framework recognizes a new external executable declared on the XMPP channel, the Remote WPS GeoServer plug-in creates the equivalent OGC WPS compliant interface and establishes the communication between GeoServer and the external executable. Every time a GeoServer user starts a new OGC WPS compliant process run, the infrastructure performs a call to the external executable and takes care of managing the communication between the two entities asynchronously.

      The Remote WPS GeoServer plug-ins provide a new ProcessFactory which is responsible to register/unregister the OGC WPS compliant processes automatically and at runtime. Orchestration will be performed by the newly created GeoServer ProcessFactory upon a WPS execution request with the help of the XMPP Server which provides out-of-the-box nodes presence discovery and load balancing capabilities for the remote node through the interaction with the Python framework.

      The orchestrator will also be responsible for redirecting the messages generated by running executables on the remote machines to the correct GeoServer process and vice versa for control messages. Executables running on the remote hosts through the Python framework wrappers, will generate progress information which will be sent back to the orchestrator via XMPP.

      It is important to note that there are two levels of load balancing. One on the GeoServer side and one on the remote processing nodes side. The GeoServer load balancer will know which user has requested the processing and will be able to enforce system and resources limitations associated to it; as an instance, a user won't be able to run more than M processes in parallel and a quota for both the inputs and outputs will be assigned to its executions. The Orchestrator will be responsible, in cooperation with the XMPP service, for balancing the load for a certain executables on the remote hosts and for deciding where to send a new execution request in case a certain executable has been deployed on multiple remote machines.

      Also note that the GeoServer instances comprising the cluster will share a specific directory where the WPS specific resources will be stored.

      "},{"location":"community/remote-wps/#invoking-remote-processes-and-consuming-the-results","title":"Invoking remote processes and consuming the results","text":"

      The executables on the remote hosts will be invoked through the command line by the Python framework wrappers in response to execution commands, received via the Orchestrator XMPP messages, as the result of a GeoServer WPS Execute call.

      On the remote machines the Python framework wrappers and scripts will act as XMPP clients providing the ability to:

      • launch command-line executables using the inputs provided by the end user from the GeoServer process orchestrator
      • send back to the orchestrator status messages with the progress and status of the execution
      • receive eventual control messages from the orchestrator to tentatively kill running executions
      • perform clean-up operations like looking for zombie executions and killing them or removing stale files on the file system from old executions
      • perform runtime discovery of new remote executable

      The illustration below shows the interaction between the GeoServer Remote WPS plug-in and the Python framework wrappers. The whole communication is achieved through the XMPP protocols. The Python framework makes available a set of scripts and wrappers allowing to invoke the external executables and manage the entire execution by translating commands and outputs into XMPP messages to be sent and received by GeoServer.

      As mentioned above the remote executables should adhere to a certain contract in order to fully support all these functionalities. As an example the ability to kill an existing execution heavily relies on the fact that the current process accounted for this functionality, otherwise we would have to try and kill it using operating system calls. This might require the end user to create wrappers around the legacy executables in certain cases.

      Runtime discovery of new remote executable will be supported through adding new Properties files to a location known to the Python modules. A new OGC WPS compliant process will be directly exposed to GeoServer without restarting the GeoServer itself for the new remote executable since the Python wrappers will communicate the existence of a new executable by interacting with the GeoServer Orchestrator via XMPP messages. The end user will see as many OGC WPS compliant processes as properties configuration files on the remote machines thanks to the functionalities implemented by the Python framework scripts.

      An example of such a properties file can be like below:

      [Description]\nservice = Service\nnamespace = default\ndescription = A dummy service, replace with your own description\nexecutable = process.py\nprocess_buffer = 0\nresult_size = 0\nactive = True\n\n[Options]\ncustomargs = --path=D:\\user\\\nargformat = --key=value\ndebug = True\n\n[Input]\nname = {\"type\": \"string\", \"description\": \"A person name\", \"enum\": [\"Hans\", \"Peter\", \"Alex\", \"Michi\"],\n\"default\": \"Hans\", \"max\": 1}\nsurname = {\"type\": \"string\", \"description\": \"A persons surname\", \"max\": 1, \"default\": \"Meier\"}\nchild = {\"type\": \"string\", \"description\": \"A child name\", \"min\": 0, \"max\": 10}\n\n[Output]\nwelcome = {\"type\": \"string\", \"description\": \"A welcome message\"}\ngoodbye = {\"type\": \"string\", \"description\": \"A goodbye message\"}\n

      Warning

      the configuration above is a simplified and non-working example of a Remote Process wrapper configuration. The scope of the example above is just for better understand of the high-level scenario and is not meant to be used in a real use case.

      "},{"location":"community/remote-wps/#deploy-diagram","title":"Deploy Diagram","text":"

      The illustration shows a deploy diagram of a Change Detection executable running on a remote machine and exposed as a GeoServer WPS Process thought the WPS Remote Plug-in.

      • The external users issue a processing request through GeoServer using the OGC WPS compliant protocol.
      • The GeoServer Remote WPS plug-in, thanks to the WPS RemoteProcessFactory, will be able to expose the processes I/O map along with the process descriptors, and take care of the entire execution by providing feedbacks to the users in an OGC compliant way.
      • On the remote machines, where the executables rely and where the real computation takes place, the Python framework, through the use of wrappers and ad h.o.c. scripts, handles transparently the communication with the Remote plug-in through the XMPP protocols.
      • The XMPP Server, in the middle, handles the secured communication channels ensuring that the endpoints are correctly registered to the system and are able to exchange messages.
      • The outcomes are exchanged through a shared folder.
      "},{"location":"community/remote-wps/#installation-and-configuration-steps","title":"Installation and Configuration Steps","text":"

      The following sections will guide the user to the deployment and configuration of an example GDAL CONTOUR command exposed as a GeoServer WPS Process through the WPS Remote Plugin.

      The examples will show step-by-step procedures to configure and deploy the whole example on two different machines:

      • Commands to deploy GeoServer with the WPS Remote Plug-in and an OpenFire XMPP Server, will be executed on a CentOS Minimal machine
      • Commands to deploy the WPS Remote XMPP Python Wrapper and GDAL, will be executed on a Windows 7+ machine
      • Deployment And Setup Of GeoServer With WPS Remote Plugin
      • Installation Of OpenFire XMPP Server To Exchange Messages
      • Deployment And Setup Of The XMPP Python Wrappers
      • A Remote \"Gdal Contour\" Process Binding Example
      "},{"location":"community/remote-wps/install_geoserver/","title":"Deployment And Setup Of GeoServer With WPS Remote Plugin","text":"

      The following commands will prepare a CentOS 7 Minimal ISO machine for the deployment of:

      • GeoServer with the following plugins:

        • GeoServer WPS
        • GeoServer Remote WPS Orchestrator
        • GeoServer Importer

      The OS iso has been downloaded from::

      http://isoredirect.centos.org/centos/7/isos/x86_64/CentOS-7-x86_64-Minimal-1503-01.iso\n
      "},{"location":"community/remote-wps/install_geoserver/#preparation-of-the-system-standard-and-basic-os-packages","title":"Preparation of the system: standard and basic OS packages","text":""},{"location":"community/remote-wps/install_geoserver/#hostname-and-other-useful-packages","title":"Hostname and other useful packages","text":"

      Update the file /etc/hosts making sure that the ip addresses matches the name of the machine.

      # as root\n\n$> yum -y install man vim openssh-clients mc zip unzip wget net-tools\n
      "},{"location":"community/remote-wps/install_geoserver/#configure-the-java-virtual-environment","title":"Configure the Java Virtual Environment","text":"
      # as root\n\n$> wget --no-check-certificate --no-cookies --header \"Cookie: oraclelicense=accept-securebackupcookie\" http://download.oracle.com/otn-pub/java/jdk/8u65-b17/jdk-8u74-linux-x64.tar.gz\n\n$> tar xzvf jdk-8u65-linux-x64.tar.gz\n$> mkdir /usr/java\n$> mv jdk1.8.0_65/ /usr/java/\n\n$> alternatives --install /usr/bin/java java /usr/java/jdk1.8.0_65/bin/java 20000\n\n$> alternatives --install /usr/bin/javac javac /usr/java/jdk1.8.0_65/bin/javac 20000\n\n$> alternatives --install /usr/bin/jar jar /usr/java/jdk1.8.0_65/bin/jar 20000\n\n$> alternatives --install /usr/bin/javaws javaws /usr/java/jdk1.8.0_65/bin/javaws 20000\n\n$> alternatives --set java /usr/java/jdk1.8.0_65/bin/java\n$> alternatives --set javac /usr/java/jdk1.8.0_65/bin/javac\n$> alternatives --set jar /usr/java/jdk1.8.0_65/bin/jar\n$> alternatives --set javaws /usr/java/jdk1.8.0_65/bin/javaws\n\n# Verify the proper installation on the JDK\n\n$> java -version\n  java version \"1.8.0_65\"\n  Java(TM) SE Runtime Environment (build 1.8.0_65-b17)\n  Java HotSpot(TM) 64-Bit Server VM (build 25.65-b01, mixed mode)\n\n$> javac -version\n  javac 1.8.0_65\n
      "},{"location":"community/remote-wps/install_geoserver/#installing-apache-tomcat","title":"Installing Apache Tomcat","text":"
      # as root\n\n$> yum -y install tomcat-webapps\n$> systemctl disable tomcat.service\n\n$> cp /etc/sysconfig/tomcat /etc/sysconfig/geoserver\n$> ln -s /usr/share/tomcat/ /opt/tomcat\n

      Creating apache tomcat HOME context

      Creating base template directory

      # as root\n\n$> mkdir -p /var/lib/tomcat/geoserver/{bin,conf,logs,temp,webapps,work}\n\n$> cp -Rf /opt/tomcat/conf/* /var/lib/tomcat/geoserver/conf/\n

      Creating geoserver apache tomcat BASE context

      Make sure you already:

      • installed tomcat (Installing apache tomcat)
      • created the base catalina template (Creating apache tomcat HOME context)

      Edit server.xml file

      GeoServer is the first tomcat instance we are installing in this VM, so we can keep the default ports:

      • 8005 for commands to catalina instance
      • 8009 for the AJP connection port
      • 8080 for the HTTP connection port

      Remember that you may change these ports in the file /var/lib/tomcat/geoserver/conf/server.xml

      Final configurations

      Set the ownership of the geoserver/ related directories to user tomcat

      # as root\n\n$> chown tomcat: -R /var/lib/tomcat/geoserver\n$> cp /etc/tomcat/tomcat.conf /etc/tomcat/geoserver.conf\n\n$> vi /etc/tomcat/geoserver.conf\n\n  # This variable is used to figure out if config is loaded or not.\n  TOMCAT_CFG_LOADED=\"1\"\n\n  # In new-style instances, if CATALINA_BASE isn't specified, it will\n  # be constructed by joining TOMCATS_BASE and NAME.\n  TOMCATS_BASE=\"/var/lib/tomcats/\"\n\n  # Where your java installation lives\n  #JAVA_HOME=\"/usr/lib/jvm/jre\"\n  JAVA_HOME=\"/usr/java/jdk1.7.0_71\"\n\n  # Where your tomcat installation lives\n  CATALINA_HOME=\"/usr/share/tomcat\"\n  CATALINA_BASE=\"/var/lib/tomcat/geoserver\"\n  CATALINA_PID=$CATALINA_BASE/work/pidfile.pid\n\n  # System-wide tmp\n  CATALINA_TMPDIR=\"/var/cache/tomcat/temp\"\n\n  # You can pass some parameters to java here if you wish to\n  #JAVA_OPTS=\"-Xminf0.1 -Xmaxf0.3\"\n  # Use JAVA_OPTS to set java.library.path for libtcnative.so\n  #JAVA_OPTS=\"-Djava.library.path=/usr/lib\"\n  JAVA_OPTS=\"-server -XX:SoftRefLRUPolicyMSPerMB=36000 -Xms1024m -Xmx2048m\n  -XX:PermSize=64m -XX:+UseConcMarkSweepGC -XX:NewSize=48m -DGEOSERVER_DATA_DIR=/storage/data/\n  -DENABLE_ADVANCED_PROJECTION=false -Dorg.geotools.shapefile.datetime=true -Duser.timezone=GMT\n  -Dorg.geotools.filter.function.simplify=true -DGEOMETRY_COLLECT_MAX_COORDINATES=50000\"\n\n  # You can change your tomcat locale here\n  #LANG=\"en_US\"\n  # Run tomcat under the Java Security Manager\n  SECURITY_MANAGER=\"false\"\n\n$> cp /usr/lib/systemd/system/tomcat.service /usr/lib/systemd/system/geoserver.service\n\n$> vi /usr/lib/systemd/system/geoserver.service\n\n  EnvironmentFile=/etc/tomcat/geoserver.conf\n\n$> systemctl enable geoserver.service\n$> systemctl restart geoserver.service\n\n# Follow the server startup procedure and make sure everything goes smoothly through the following command\n\n$> tail -F /var/lib/tomcat/geoserver/logs/catalina.YYYY-MM-DD.log\n
      "},{"location":"community/remote-wps/install_geoserver/#deploy-and-configure-geoserver","title":"Deploy And Configure GeoServer","text":"

      First deployment

      # as root\n\n# Git and Maven must be installed on the system\n$> yum -y install git\n$> yum -y install maven\n\n# Verify the Maven installation and double check that the JDK recognized is the Java Sun 1.7+\n$> mvn -version\n\n  Apache Maven 3.0.5 (Red Hat 3.0.5-16)\n  Maven home: /usr/share/maven\n  Java version: 1.8.0_65, vendor: Oracle Corporation\n  Java home: /usr/java/jdk1.8.0_65/jre\n  Default locale: en_US, platform encoding: UTF-8\n  OS name: \"linux\", version: \"3.10.0-229.el7.x86_64\", arch: \"amd64\", family: \"unix\"\n\n# The following procedures allow to collect and compile the source code from the GIT repository.\n$> cd\n\n$> git clone https://github.com/geosolutions-it/geoserver.git geoserver.src\n\n$> cd geoserver.src/src\n\n$> git checkout wps-remote\n$> git pull\n\n$> mvn clean install -Pwps,wps-remote,importer,security,rest-ext -DskipTests\n\n$> mv web/app/target/geoserver.war /var/lib/tomcat/geoserver/webapps/\n\n$> chown -Rf tomcat: /var/lib/tomcat/geoserver\n\n$> mv /var/lib/tomcat/geoserver/webapps/geoserver/data/ /storage/\n\n$> chown -Rf tomcat: /storage\n\n$> vim /storage/data/remoteProcess.properties\n\n  # Default Properties\n  remoteProcessStubCycleSleepTime = 100\n\n  # Base path where uploaded files are stored\n  # . This is used only when a remote uploader is enabled on the Python\n  # . WPS Agent. This property represents the local base path (on the filesystem\n  # . of GeoServer) where to search for uploaded files.\n  # . If not file has been found here (or this option is not enabled), GeoServer\n  # . looks for absolute path and/or paths relative to the GEOSERVER DATA DIR.\n  #uploadedFilesBasePath = /tmp\n\n  # Full path to the template used to generate the OWS WMC Json output\n  # . This property is used only when a \"application/owc\" output type on\n  # . the Python WPS Agent.\n  #owc_wms_json_template = absolute_path/to/wmc_template.json\n\n  # Specific kvps for {@link RemoteProcessClient) implementations\n  xmpp_server = localhost\n  xmpp_server_embedded = false\n  xmpp_server_embedded_secure = true\n  xmpp_server_embedded_certificate_file = bogus_mina_tls.cert\n  xmpp_server_embedded_certificate_password = boguspw\n  xmpp_port = 5222\n\n  xmpp_manager_username = admin\n  xmpp_manager_password = R3m0T3wP5\n\n  # domain and MUC service name of the XMPP Server\n  xmpp_domain = geoserver.org\n  xmpp_bus = conference\n\n  # name, user and password of the management room\n  xmpp_management_channel = management\n  xmpp_management_channel_user = admin\n  xmpp_management_channel_pwd = R3m0T3wP5\n\n  # comma separated list of available rooms for services. Those rooms'names will be equal to the service and WPS Process namespace\n  # Avoid spaces\n  xmpp_service_channels = default,geosolutions\n\n  # millis\n  xmpp_packet_reply_timeout = 500\n\n  # connection keep alive\n  xmpp_connection_ping_interval = 30000\n  xmpp_connection_ping_timeout = 10000\n  xmpp_connection_ping_initial_delay = 20000\n\n  # Thresholds indicating overloaded resources\n  xmpp_cpu_perc_threshold = 82.5\n  xmpp_mem_perc_threshold = 84.6\n\n# Restart GeoServer\n\n$> service geoserver restart\n

      Warning

      GeoServer won't connect to XMPP Server until it has been correctly configured and started as explained in the next section Installation Of OpenFire XMPP Server To Exchange Messages.

      "},{"location":"community/remote-wps/install_python/","title":"Deployment And Setup Of The XMPP Python Wrappers","text":""},{"location":"community/remote-wps/install_python/#remote-wps-python-wrapper-framework","title":"Remote WPS Python Wrapper Framework","text":"

      The Remote WPS Python framework source code is available on a public GitHub Repository of GeoSolutions S.A.S.

      Users can install the \"wps-remote\" Python package by using the PyPi distribution :

      pip install wps-remote==2.11.0\n

      The source code repository is available at the following address:

      https://github.com/geoserver/wps-remote

      The source code is available on the main development (main) branch.

      "},{"location":"community/remote-wps/install_python/#how-the-system-works","title":"How The System Works","text":"

      This setup will configure the Remote WPS Python Wrapper to launch a Python executable called test.py that performs a gdal_contour on a GeoTIFF DEM.

      The test.py executable takes in input just two parameters:

      • -i; \"--interval\", nargs='?', default=\"10\", help=\"Elevation interval between contours.\"
      • -w; \"--workdir\", nargs='?', default=\"\", help=\"Remote process sandbox working directory.\"

      The paths of the command line and GeoTIFF to process (provided with the source code as sample data), are hard-coded into the Python code and must be changed accordingly to the system settings as explained later in the docs:

      • gdalContour = r'/usr/bin/gdal_contour'
      • src = r'/share/xmpp_data/resource_dir/srtm_39_04/srtm_39_04_c.tif'

      The assumptions are that during the execution, the algorithms send logging and progress info to the standard output in a form similar to the following one:

      2016-02-15 15:18:03,594 - main.create_logger - [INFO] ProgressInfo:100%\n

      The log format has been configured through the logger_test.properties file:

      [loggers]\nkeys=root\n\n[handlers]\nkeys=consoleHandler\n\n[formatters]\nkeys=simpleFormatter\n\n[logger_root]\nlevel=DEBUG\nhandlers=consoleHandler\n\n[handler_consoleHandler]\nclass=StreamHandler\nlevel=DEBUG\nformatter=simpleFormatter\nargs=(sys.stdout,)\n\n[formatter_simpleFormatter]\nformat=%(asctime)s - %(name)s - [%(levelname)s] %(message)s\ndatefmt=\n

      The role of the Remote WPS Python wrapper is to take care of the communication between GeoServer WPS and the test.py executable.

      The Python wrapper must be configured by specifying the number and type of input and output parameters of the executable, other than the connection parameter of the remote XMPP Server. The Python wrapper knows how to invoke the executables from the command line and how to parse and interpret the logging information thanks to some properties files containing a set of regular expressions which will be presented in details further in this document.

      There must be a running instance of the Python wrapper for each executable, every one with its own specific configuration and XMPP user. The wrapper instances will connect automatically to the XMPP Server and GeoServer will send an \"invite\" message as soon it recognizes a new authenticated user appearing on the XMPP communication channels. In order to register the WPS Process into the GeoServer through the Remote Process Factory, the Python wrapper must reply to the invitation with a \"register\" message containing all the details about the I/O params of the executable. All those passages are managed automatically and transparently to the users by the Remote WPS Python framework.

      Every time a user issues a new GeoServer WPS execute request, the Python wrapper starts a new thread calling the executables with the input parameters coming from GeoServer itself. The two running instances are connected through a unique \"process execution ID\" generated by GeoServer Remote Process Factory.

      From now on, the Python wrapper thread follows the entire execution and takes care of sending feedbacks and logging information to the GeoServer Remote Process Factory, which are translated and forwarded to the GeoServer WPS Execution Manager. From the outside the users will experience a standard execution of an OGC WPS compliant process.

      "},{"location":"community/remote-wps/install_python/#summary-of-the-configuration-steps","title":"Summary Of The Configuration Steps","text":"

      Connecting a new executable instance to GeoServer through the Python wrapper requires few configuration steps summarized here below:

      1. Clone a structure of .properties files containing:
        • The connection parameter to the XMPP Server
        • The descriptor of the executable command line
        • The descriptor of the process I/O parameters
        • The logging informations
      2. Update the remote.config file with the correct XMPP Server information:
        • Provide remote host and port parameters
        • Provide domain and XMPP communication secured channels details
        • Provide pointers to the shared folder
      3. Update the logger.properties file with the full path to the service.log file.

      4. Update the service.config file with the executables parameters:
        • The service name and the namespace
            !!! note\n\n        there must exist an user on the XMPP Server named as `namespace.serviceName` and a communication channel with the same identified of the service namespace.\n\n        e.g.:\n\n        -   service = gdalContour\n        -   namespace = default\n\n        means that on the XMPP Server we are looking for a communication channel named `default` and we will try to connect with the username `default.gdalContour`.\n\n        Both of them must be defined before running the Python wrapper daemon.\n\n-   The description of the service and the full path to the main executable\n\n-   Other secondary parameters like the local output folder (where to store temporary results of the execution) and the max running time\n\n-   The description of the Inputs and the actions to be taken\n\n-   The description of the Outputs and the actions to be taken\n\n-   The description of the logging information and the actions to be taken\n
      "},{"location":"community/remote-wps/install_python/#installation-and-configuration-steps","title":"Installation and Configuration Steps","text":""},{"location":"community/remote-wps/install_python/#basic-environment-preparation","title":"Basic Environment Preparation","text":"

      The following commands will prepare a MS Windows 7+, Windows 2008+ Server ISO machine for the deployment of:

      1. Remote WPS Python wrapper
      2. Sample configuration and testing of a sample executable test.py running the gdal_contour on a GeoTIFF DEM

      Preparation of the system: standard and basic OS packages

      Python

      The system requires Python 2.7.9+ with few packages in order to work correctly. The installation of Python on a Windows system is quite fast

      # as administrator\n\n#.1 Download the Python 2.7.9 installation package from the browser, choosing the best suitable distribution accordingly to the OS\n\n  https://www.python.org/downloads/release/python-279/\n\n#.2 Define the following System Environment Variables\n\nPATH=%PATH%;C:\\Python27;C:\\Python27\\Scripts\nPYTHONPATH=.\\;C:\\Python27;C:\\work\\RemoteWPS\n

      Other Mandatory Python Packages

      # as administrator\n\n# From a Command Line prompt\n\n$> pip install wps-remote==2.11.0\n

      Configure the RemoteWPS Environment

      NFS Shared Folder

      Link the shared folder to the C:/share through the NFS protocol. This is possible simply by turning on the NFS Services of the MS Windows functionalities and creating a client NFS connection to the NFS server.

      Warning

      \"Services for NFS\" have been removed on Windows 10. They are available only on Windows 10 Enterprise edition. For older Windows versions you can use the following procedure in order to enable NFS Client

      Installing the client

      1. Go to Control Panel \u2192 Programs \u2192 Programs and Features
      2. Select: Turn Windows features on or off\" from the left hand navigation.
      3. Scroll down to \"Services for NFS\" and click the \"plus\" on the left
      4. Check \"Client for NFS\"
      5. Select \"Ok\"
      6. Windows should install the client. Once the client package is install you will have the \"mount\" command available.

      Mounting the export

      This assumes the following:

      • You know and can ping the hostname of the machine with the NFS exports
      • The name of the exported filesystem ( eg. /export, /home/users, /some/cool/file/path )
        • Open a command prompt. ( Win + R, enter \"cmd\" and press OK )

        The file systems are properly exported and accessible

        • Type:

          mount \\\\{machinename}\\{filesystem} {driveletter}

      Examples:

      mount \\\\filehost\\home\\users H:\nmount \\\\server1234\\long\\term\\file\\storage S:\nmount \\\\nas324\\exports E:\n

      Note

      It is important that the shared folder structure is fully replicated on the Windows machine and the folder writable by the Windows processes.

      | /share\n|\n|-- xmpp_data\n|\n|-- -- output\n|\n|-- -- resource_dir\n
      "},{"location":"community/remote-wps/install_python/#first-deploy-of-the-remotewps-python-framework","title":"First Deploy Of The RemoteWPS Python Framework","text":"

      The wps-remote WHL archive contains a folder with a sample configuration :

      xmpp_data\n

      Extract this folder and proceed with the next steps.

      The files can also be downloaded from the GitHub source repository.

      To clone the RemoteWPS Python Framework into a working folder, e.g.:

      $> cd C:\\work\n\n$> git clone https://github.com/geoserver/wps-remote RemoteWPS\n

      Setting Up The remote.config

      # Edit the file xmpp_data/configs/remote.config\n\n  [DEFAULT]\n\n  bus_class_name = xmppBus.XMPPBus\n\n  port = 5223\n  address =  127.0.0.1\n  domain = geoserver.org\n\n  # . Those are the connection parameters to the XMPP Server.\n  # . The user must exists on the Server and its name must be\n  # . equal to the service name.\n  user = default.GdalContour\n  password = R3m0T3wP5\n\n  mucService = conference.%(domain)s\n  mucServicePassword = admin\n\n  resource_file_dir = /share/xmpp_data/resource_dir\n\n  # . Configure this option (along with 'backup_on_wps_execution_shared_dir' \n  # . on single outputs of 'service.config') in order to make a copy\n  # . of the results into a shared folder before sending messages to XMPP\n  # . WARNING: this option takes precedence on \"UPLOADER\" option\n  # wps_execution_shared_dir = /share/xmpp_data/share\n\n  # . This section is used to configure the uploader class and connection\n  # . parameters.\n  # . This is necessary in order to let the 'upload_data' option work on\n  # . single outputs of 'service.config'\n  [UPLOADER]\n  # There are different implementations of the FTP Uploader available right now:\n  # . Plain standard FTP Protocol (based on ftplib)\n  #       ftpUpload.FtpUpload\n  # . FTP over TLS (FTPS) Protocol (based on ftplib)\n  #       ftpsUpload.FtpsUpload\n  # . S-FTP Protocol (based on paramiko Python lib)\n  #       sftpUpload.SFtpUpload\n  uploader_class_name = ftpUpload.FtpUpload\n  uploader_host = ftp.<your_host_here>:<your_port_here_default_21>\n  uploader_username = <ftp_username>\n  uploader_password = <ftp_password_encrypted>\n\n  # . \"encryptor\" you can use encrypted passwords with a private/public key couple\n  #\n  # . To generate a new private key use the following command:\n  #     openssl genrsa -out myTestKey.pem -passout pass:\"f00bar\" -des3 2048\n  #\n  # . To generate a new public key use the following command:\n  #     openssl rsa -pubout -in myTestKey.pem -passin pass:\"f00bar\" -out myTestKey.pub\n  #\n  # . To encrypt your password use the following utility\n  #     python encrypt.py password path/to/rsakey.pub passphrase\n  #\n  # . To double check the password is correct use the following utility\n  #     python decrypt.py password path/to/rsakey.pem passphrase\n  uploader_private_rsa_key = /share/xmpp_data/ssl/myTestKey.pem\n  uploader_passphrase = f00bar\n

      The requisites for this configuration to work properly are:

      1. Make sure the <XMPP_server_ip_address> is reachable and the port 5223 is allowed by the Firewall
      2. Make sure the default.GdalContour user exists into the XMPP Server and that the password is correct

      1. The MUC Service and the MUC Service Password are correct
      2. The resource dir and the shared folder exists and are writable

      Setting Up The logger.properties

      # Edit the file xmpp_data/configs/logger.properties\n\n[loggers]\nkeys=root\n\n[handlers]\nkeys=consoleHandler,file\n\n[formatters]\nkeys=simpleFormatter,consoleFormatter\n\n[logger_root]\nlevel=DEBUG\nhandlers=file, consoleHandler\n\n[handler_consoleHandler]\nclass=StreamHandler\nlevel=DEBUG\nformatter=consoleFormatter\nargs=(sys.stdout,)\nfilter=\n\n[handler_file]\nclass=handlers.TimedRotatingFileHandler\ninterval=midnight\nbackupCount=5\nformatter=simpleFormatter\nlevel=DEBUG\nargs=('/share/xmpp_data/service.log',)\n\n[formatter_simpleFormatter]\nformat=%(asctime)s - %(name)s - %(levelname)s - %(message)s\ndatefmt=\n\n[formatter_consoleFormatter]\nformat=%(asctime)s [%(levelname)s] %(message)s\ndatefmt=\n

      The requisites for this configuration to work properly are:

      1. Make sure the \"C:/share/xmpp_data/\" exists and is writable

      Setting Up The service.config

      # Edit the file xmpp_data/configs/myservice/service.config\n\n  # This is a INI file to be read with python ConfigParser (https://docs.python.org/2/library/configparser.html)\n  # Is possible to reference another variable in the ini file using the format %(<variable name>)s (note the 's' at the end)\n\n  # ########################################### #\n  # Default Service Params                      #\n  # ########################################### #\n\n  [DEFAULT]\n  service = GdalContour\n  namespace = default\n  description = GDAL Contour Remote Service\n  executable_path = /share/xmpp_data/configs/myservice/code\n  executable_cmd = python %(executable_path)s/test.py\n  output_dir = /share/xmpp_data/output/\n  unique_execution_id = %(unique_exe_id)s\n  workdir = %(output_dir)s/%(unique_execution_id)s\n  active = True\n  max_running_time_seconds = 300\n\n  # . This option allows you to set the CPU and Memory average load scan time.\n  # . It is espressed in 'minutes' and if disabled here it will be set by default\n  # . to 15 minutes.\n  load_average_scan_minutes = 1\n\n  # . Use this option to completely avoid using this host (and prevent starting a new\n  # . 'processbot') whenever one of the following process names are running.\n  # . In other words, if one of the following processes are currently running on this machine,\n  # . GeoServer won't send any WPS execute request until they are finished.\n  process_blacklist = [resource consuming process name1, resource consuming process name2]\n\n  # ########################################### #\n  # Inputs and Actions Declaration              #\n  # ########################################### #\n\n  [Input1]\n  class = param\n  name = interval\n  title = Elevation Interval\n  type = int\n  description = Elevation interval between contours.\n  min = 1\n  max = 1\n  default = 200\n\n  [Action1]\n  class = cmdline\n  input_ref = interval\n  alias = i\n  template = -name value\n\n  [Const1]\n  class = const\n  name = workdir\n  type = string\n  description = Remote process sandbox working directory\n  value = %(workdir)s\n\n\n  [Action2]\n  class = cmdline\n  input_ref = workdir\n  alias = w\n  template = -name value\n\n  # ########################################### #\n  # Output Parameters Declaration               #\n  # ########################################### #\n\n  [Output1]\n  name = result1\n  type = application/zip\n  description = WPS Resource Binary File\n  title = SRTM\n  filepath = %(workdir)s/contour.zip\n  publish_as_layer = true\n  publish_default_style = polygon\n  publish_target_workspace = it.geosolutions\n  publish_layer_name = contour\n\n  # . Enable this option in order to perform a backup of this output\n  # . before sending it to GeoServer.\n  # . WARNING: This option works only along with 'wps_execution_shared_dir'\n  # .          option on 'remote.config', and takes precedence on 'upload_data'\n  # backup_on_wps_execution_shared_dir = true\n\n  # . Enable this option if you want the output to be uploaded on remote host.\n  # . Notice that you must also configure uploader parameters on 'remote.config'\n  # upload_data = true\n\n  # . Optionally it is possible to specify a root folder if the uploader class supports it.\n  # upload_data_root = /remote-wps/default\n\n  [Output2]\n  name = result2\n  type = application/x-netcdf\n  description = NetCDF Binary File\n  title = flexpart\n  filepath = %(output_dir)s/flexpart.nc\n  publish_as_layer = true\n  publish_default_style = raster\n  publish_target_workspace = it.geosolutions\n  publish_layer_name = flexpart\n\n  # . Enable this option in order to perform a backup of this output\n  # . before sending it to GeoServer.\n  # . WARNING: This option works only along with 'wps_execution_shared_dir'\n  # .          option on 'remote.config', and takes precedence on 'upload_data'\n  # backup_on_wps_execution_shared_dir = true\n\n  # . Enable this option if you want the output to be uploaded on remote host.\n  # . Notice that you must also configure uploader parameters on 'remote.config'\n  # upload_data = true\n\n  # . Optionally it is possible to specify a root folder if the uploader class supports it.\n  # upload_data_root = /remote-wps/default\n\n  [Output3]\n  name = result3\n  type = application/owc\n  description = WPS OWC Json MapContext\n  layers_to_publish = result2\n  publish_as_layer = true\n  publish_layer_name = owc_json_ctx\n  publish_metadata = /share/xmpp_data/resource_dir/owc_json_ctx.json\n\n  # ########################################### #\n  # Logging Options Declaration                 #\n  # ########################################### #\n\n  [Logging]\n  stdout_parser = [.*\\[DEBUG\\](.*), .*\\[INFO\\] ProgressInfo\\:([-+]?[0-9]*\\.?[0-9]*)\\%, .*\\[(INFO)\\](.*), .*\\[(WARN)\\](.*), .*\\[(ERROR)\\](.*), .*\\[(CRITICAL)\\](.*)]\n  stdout_action = [ignore,          progress,                                          log,              log,              abort,               abort]\n

      The requisites for this configuration to work properly are:

      1. Make sure the default.GdalContour user exists into the XMPP Server and that the password is correct

      2. Make sure the default channel exists on the XMPP Server

      3. Make sure the executable path and command are correct

      4. Make sure the output_dir exists and is writable

      5. Make sure the max_running_time_seconds have been set to a value high enough to allow the executables to complete the jobs.

        The GeoServer instance must also respect the WPS execution timings which must be configured accordingly. In order to do that access to the GeoServer Web Admin GUI.

        http://host:8080/geoserver/web/

        login as administrator (default credentials are admin/geoserver which should be changed anyway).

        From the Web Processing Service settings page

        The timeouts and the number of parallel executions (both async and sync) must be tuned accordingly to the execution needs.

      6. Make sure the inputs have been configured correctly for the command line execution

        [Input1]\nclass = param\nname = interval\ntitle = Elevation Interval\ntype = int\ndescription = Elevation interval between contours.\nmin = 1\nmax = 1\ndefault = 200\n\n[Action1]\nclass = cmdline\ninput_ref = interval\nalias = i\ntemplate = -name value\n

        The configuration above sets an input of type int (the expected value will be interpreted as text and declared as Literal to the WPS), which is mandatory (min = 1) and can have a single value (max = 1).

        The [Action1] is connected to the input through the input_ref which is equal to the [Input1].name.

        In the example above the action simply gets the input value specified by the user and forward it to the command line.

        The final result will be something lihe this:

        $> /work/RemoteWPS/xmpp_data/configs/myservice/code/test.py <input_value_here>\n

        The [Action1].template property allows to specify the name of the option if required by the executable.

        As an instance the following value for the [Action1].template:

        alias = i\ntemplate = -name value\n

        will result in something like this:

        $> /work/RemoteWPS/xmpp_data/configs/myservice/code/test.py -i <input_value>\n

        There exists other types of input and actions.

        As an instance it is possible to specify constant input types like the following one:

        [Const1]\nclass = const\nname = workdir\ntype = string\ndescription = Remote process sandbox working directory\nvalue = %(workdir)s\n\n[Action2]\nclass = cmdline\ninput_ref = workdir\nalias = w\ntemplate = -name value\n

        The [Const1].value can be a constant value or a reference to the configuration file properties.

        In the example above we are going to pass to the command line the full path of the process workind directory, which is a unique folder created at runtime where the RemoteWPS framework stores temporary and intermediate results of the process execution.

        Enabling the constant input above, the resulting command line will be something like the following one:

        $> /work/RemoteWPS/xmpp_data/configs/myservice/code/test.py -i <input_value> -w /share/xmpp_data/output/<exec_id>\n

        ::: note ::: title Note :::

        The is known at runtime only. :::

      7. Make sure the outputs have been configured correctly for the command line execution

        [Output1]\nname = result1\ntype = application/zip\ndescription = WPS Resource Binary File\ntitle = SRTM\nfilepath = %(workdir)s/contour.zip\npublish_as_layer = true\npublish_default_style = polygon\npublish_target_workspace = it.geosolutions\npublish_layer_name = contour\n

        In the example above we declare to the WPS only one output of type application/zip.

        In this case the RemoteWPS framework expects to find a contour.zip file at the end of the execution into the working directory (see above).

        There are many kind of possible outputs which can be defined here. As an instance it is possible to define an output of type string which can read the outcome from a file and stream it out as plain text.

        It is also possible to define several kind of binary outputs depending on the executable outcomes. For more details please refer to the Remote WPS Python framework specific documentation at the end of this section.

      8. Make sure the regular expressions of the \"stdout_parser\" are correct and valid accordingly to the output of the executable

        [Logging]\nstdout_parser = [.*\\[DEBUG\\](.*), .*\\[INFO\\] ProgressInfo\\:([-+]?[0-9]*\\.?[0-9]*)\\%, .*\\[(INFO)\\](.*), .*\\[(WARN)\\](.*), .*\\[(ERROR)\\](.*), .*\\[(CRITICAL)\\](.*)]\nstdout_action = [ignore,          progress,                                          log,              log,              log,               abort]\n

        The example configuration above:

        • Ignores all STDOUT debug logs received from test.py
        • Translates as progress info message any number parsed by the regex from STDOUT and sends it to GeoServer WPS.
        • Logs all STDOUT info, warn and error logs received from test.py
        • Translates as abort message any keyword CRITICAL parsed by the regex from STDOUT and sends it to GeoServer WPS.

        At least progress and abort messages are mandatory in order to take track of the process execution progress and fault state.

      9. "},{"location":"community/remote-wps/install_python/#a-running-example","title":"A Running Example","text":"

        In the section A Remote \"Gdal Contour\" Process Binding Example will show how to run the example and how to parse the results in GeoServer.

        "},{"location":"community/remote-wps/install_python/#annex-a-remote-wps-python-wrapper-reference","title":"ANNEX A: Remote WPS Python Wrapper Reference","text":"

        This section is meant to be a summary of the current possible options for the RemoteWPS Python Wrapper service.config configuration.

        "},{"location":"community/remote-wps/install_python/#default-section","title":"Default Section","text":"
        # ########################################### #\n# Default Service Params                      #\n# ########################################### #\n\n[DEFAULT]\nservice = GdalContour\nnamespace = default\ndescription = GDAL Contour Remote Service\nexecutable_path = /work/RemoteWPS/xmpp_data/configs/myservice/code\nexecutable_cmd = python %(executable_path)s/test.py\noutput_dir = /share/xmpp_data/output/\nunique_execution_id = %(unique_exe_id)s\nworkdir = %(output_dir)s/%(unique_execution_id)s\nsharedir = /home/myproc/repository/default\nactive = True\nmax_running_time_seconds = 300\nload_average_scan_minutes = 1\nprocess_blacklist = [resource consuming process name1, resource consuming process name2]\n
        • service; The name of the WPS service. On GeoServer the WPS Process will be represented as namespace.service

          Note

          The XMPP Server must have a registered user named like the fully qualified service name namespace.service

        • namespace; The namespace (or prefix) of the service. Along with the service parameter, it represents the fully qualified name of the service.

        • description; This contains the textual description of the GeoServer WPS Process.

        • executable_path; Full path of the executable to wrap.

        • executable_cmd; Executable command.

        • output_dir; The base output folder where the Python wrapper stores logs and temporary files.

        • unique_execution_id; The unique ID generated by GeoServer and sent to the process via the REQUEST command message.

        • workdir; Temporary folder where to store the outcomes and log files.

        • sharedir; Shared folder where to backup outcomes with backup_on_wps_execution_shared_dir property equal true

        • active; Boolean which enables or disables the service.

        • max_running_time_seconds; After this time the Python Wrapper tries to shutdown the process and send a FAILED message to GeoServer.

        • load_average_scan_minutes; This option allows you to set the CPU and Memory average load scan time. It is espressed in 'minutes' and if disabled here it will be set by default to 15 minutes.

        • process_blacklist; Use this option to completely avoid using this host (and prevent starting a new 'processbot') whenever one of the following process names are running. In other words, if one of the following processes are currently running on this machine, GeoServer won't send any WPS execute request until they are finished.

        "},{"location":"community/remote-wps/install_python/#inputs-section","title":"Inputs Section","text":"
        # ########################################### #\n# Inputs and Actions Declaration              #\n# ########################################### #\n\n[Input1]\nclass = param\nname = interval\ntitle = Elevation Interval\ntype = int\ndescription = Elevation interval between contours.\nmin = 1\nmax = 1\ndefault = 200\n\n[Action1]\nclass = cmdline\ninput_ref = interval\nalias = i\ntemplate = -name value\n\n[Const1]\nclass = const\nname = workdir\ntype = string\ndescription = Remote process sandbox working directory\nvalue = %(workdir)s\n\n[Action2]\nclass = cmdline\ninput_ref = workdir\nalias = w\ntemplate = -name value\n

        The Inputs Section can contain three type of objects:

        1. [Input#]; Descriptor of the corresponding GeoServer WPS Input parameter.
        2. [Action#]; 1..n actions of the Python Wrapper associated to an [Input]. The reference is done through the input_ref property.
        3. [Const#]; Constant values passed to the executable and transparent to the GeoServer WPS.

        [Input#]

        • class; Uses introspection to instantiate an Input parameter. Currently the only value admitted is param
        • name; The name of the input parameter. This will be also the name of the GeoServer Input parameter.
        • title; The title of the input parameter. To be used as internal descriptor.
        • description; The description of the input parameter. This will be also the description of the GeoServer Input parameter.
        • type; The type of the input parameter. Allowed types are:
          1. string; Simple text input. Invalid characters will be automatically removed.
          2. int; Integer numeric input value.
          3. float; Float numeric input value.
          4. url; Must contain a valid URL. Invalid characters will be automatically removed.
          5. application/json; Threated as a JSON string. It will be parsed by the Python Wrapper and converted into a complex object.
          6. datetime; Converted into a Python datetime object accordingly to the formatter property containing the date pattern and which must also be provided.
        • min; Optional parameter which sets the minimum set of inputs of this type allowed by the GeoServer WPS. 0 by default.
        • max; Optional parameter which sets the maximum set of inputs of this type allowed by the GeoServer WPS. 0 (alias infinite) by default.
        • default; Optional parameter for setting the default value of this input if a value has not provided.
        • formatter; Optional parameter to be used along with datetime inputs. Defines the date pattern to be applied to the input string (e.g.: %Y-%m-%d %H:%M:%S)

        [Action#]

        • class; Uses introspection to instantiate the type of Action.

          1. cmdline; The value of the associated input will be passed to the executable as a key-value pair accordingly to the template specified (e.g.: --name=value).

            • template; Template of the key-value pair format (e.g.: template = -name value)
            • alias; Alias of the key (e.g.: alias = i will be translated as -i value)
          2. createJSONfile; The value of the associated input will be dumped to a JSON file and the reference to the file passed to the executable.

            • target_filepath; PATH Where to store the JSON file.
            • json_schema; The PATH to the JSON Schema to be used to validate the input values.
          3. updateJSONfile; The value of the associated input will be substituted into a target template JSON file, which then will be passed to the executbale as reference.

            • source_filepath; PATH of the source JSON template file.
            • target_filepath; PATH of the target JSON file.
            • json_path_expr; JSON path expression used to subsitute the values.
          4. copyfile; The value of the associated input will be interpreted as a path to a source file. The content of the file will be copied into a temporary file and then passed to the executbale as reference.

            • source_filepath; PATH of the source JSON template file.
            • target_filepath; PATH of the target JSON file.
          5. updateINIfile; The value of the associated input will be substituted into a target template INI file, which then will be passed to the executbale as reference.

            • source_filepath; PATH of the source JSON template file.
            • target_filepath; PATH of the target JSON file.
            • section; Section of the INI file where to store key-value pair entries.
          6. updateINIfileList; The value of the associated input will be parsed as a list and substituted into a target template INI file, which then will be passed to the executbale as reference.

            • source_filepath; PATH of the source JSON template file.
            • target_filepath; PATH of the target JSON file.
            • section; Section of the INI file where to store key-value pair entries.
        • input_ref; name of the input parameter referenced by this Action.

        [Const#]

        • class = const
        • name; Name of the input parameter, used by an action as reference.
        • type; May be one of the [Input#].type ones.
        • description; Internal description of the parameter.
        • value; Fixed value parsed by the referencing Action.
        "},{"location":"community/remote-wps/install_python/#outputs-section","title":"Outputs Section","text":"
        # ########################################### #\n# Output Parameters Declaration               #\n# ########################################### #\n\n# WARNING: the name must start with the keyword \"result\"\n\n[Output1]     \nname = result1\ntype = string\ndescription = WPS Resource Plain Text\nfilepath = %(workdir)s/geoserverLayerOutput.xml\n\n[Output2]\nname = result2\ntype = image/geotiff\ndescription = WPS Resource Binary File\ntitle = SRTM\nfilepath = %(workdir)s/srtm_39_04_c.tif\nbackup_on_wps_execution_shared_dir = true\npublish_as_layer = true\npublish_default_style = raster\npublish_target_workspace = it.geosolutions\npublish_layer_name = srtm_39_04_c\n# Such metadata is a JSON snippet itself (/tmp/resource_dir/result2.json) with a small particularity. \n# Since you cannot know a-priori some of the final Layer properties, \n# you can use inside the json (/tmp/resource_dir/result2.json) some keywords which will be updated \n# automatically by the RemoteWPS which are the following ones:\n#\n# ${type} \n# ${name}\n# ${title}  \n# ${description} \n# ${lastUpdated} \n# ${getMapBaseUrl} \n# ${srs} \n# ${bbox} \n# ${workspace} \n# ${layers} \n# ${styles} \npublish_metadata = /<path_to>/resource_dir/result2.json\n\n[Output3]\nname = result3\ntype = image/geotiff;stream\ndescription = WPS Resource Binary Stream\ntitle = This Is A GeoTIFF Layer\nfilepath = %(workdir)s/srtm_39_04_c.tif\npublish_as_layer = true\npublish_default_style = raster\npublish_target_workspace = it.geosolutions\npublish_layer_name = srtm_39_04_c\n\n[Output4]\nname = result4\ntype = application/x-netcdf\ndescription = NetCDF Binary File\ntitle = Wind\nfilepath = %(workdir)s/RS1_STB_1FSCLS20111003_175545_00000018xS2x_16bxx_83066_29447_wind.nc\nbackup_on_wps_execution_shared_dir = true\npublish_as_layer = true\npublish_default_style = raster\npublish_target_workspace = it.geosolutions\npublish_layer_name = wind\n# Such metadata is a JSON snippet itself (/tmp/resource_dir/result3.json) with a small particularity. \n# Since you cannot know a-priori some of the final Layer properties, \n# you can use inside the json (/tmp/resource_dir/result4.json) some keywords which will be updated \n# automatically by the RemoteWPS which are the following ones:\n#\n# ${type} \n# ${name}\n# ${title}  \n# ${description} \n# ${lastUpdated} \n# ${getMapBaseUrl} \n# ${srs} \n# ${bbox} \n# ${workspace} \n# ${layers} \n# ${styles} \npublish_metadata = /<path_to>/resource_dir/result4.json\n\n# ########################################### #\n# GML Possible type values are                #\n#  text/xml;subtype=gml/3.1.1                 #\n#  text/xml;subtype=gml/2.1.2                 #\n#  application/gml-3.1.1                      #\n#  application/gml-2.1.2                      #\n# ########################################### #\n[Output5]\nname = result5\ntype = text/xml;subtype=gml/3.1.1\ndescription = WPS Resource GML\nfilepath = %(workdir)s/geoserverLoadLayerOutput.xml\n\n[Output6]\nname = result6\ntype = video/mp4\ndescription = Video MP4 Binary File\ntitle = Wind\nfilepath = %(workdir)s/RS1_STB_1FSCLS20111003_175545_00000018xS2x_16bxx_83066_29447_wind.mp4\nbackup_on_wps_execution_shared_dir = false\n\n[Output7]\nname = result7\ntype = application/owc\ndescription = WPS OWC Json MapContext\nlayers_to_publish = result2;result4\npublish_as_layer = true\npublish_layer_name = owc_json_ctx\npublish_metadata = /<path_to>/resource_dir/owc_json_ctx.json\n

        The examples above represents all the possible types of Outputs currently supported by the Remote WPS Wrapper.

        • type = string

          The content of the file specified by the filepath is read and sent to the WPS. The GeoServer WPS declares this as a text/plain output type.

        • type = image/geotiff

          The content of the binary GeoTIFF specified by the filepath is read and sent to the WPS. The GeoServer WPS declares this as a otput binary RAW FILE output type.

        • type = image/geotiff;stream

          The content of the binary GeoTIFF specified by the filepath is read and sent to the WPS. The GeoServer WPS declares this as a otput binary RAW STREAM output type.

        • type = application/x-netcdf

          The content of the binary NetCDF specified by the filepath is read and sent to the WPS. The GeoServer WPS declares this as a otput binary RAW FILE output type.

        • type = text/xml;subtype=gml/3.1.1

          The content of the file specified by the filepath is read and sent to the WPS. The GeoServer WPS declares this as a text/xml output type.

        • type = video/mp4

          The content of the binary MPEG-4 specified by the filepath is read and sent to the WPS. The GeoServer WPS declares this as a otput binary RAW FILE output type.

        • type = application/owc

          This is a particular type of output. From the GeoServer WPS point of view is a text/plain JSON output type describing a Web Mapping Context.

          The Remote WPS Plugin on GeoServer side takes care of publishing the layers specified by layers_to_publish = result2;result4 and render the templates specified by publish_metadata of each output.

          The outcome will be a complex JSON WMC describing the map to publish.

          In order to activate this funcionality, update the GeoServer remoteProcess.properties on the GEOSERVER_DATA_DIR with a new option:

          # full path to the template used to generate the OWS WMC Json output\n\nowc_wms_json_template = /tmp/resource_dir/wmc_template.json\n

          Sample wmc_template.json

          {\n  \"type\": \"FeatureCollection\",\n  \"id\": \"GeoServer OWC Map Context: version of 2015-07-14\",\n  \"geometry\": {\n              \"type\":\"Polygon\",\n              \"coordinates\": ${renderingArea}\n    },\n    \"features\" : [\n            <#list featureList?keys as key>\n            {\n                \"type\": \"Feature\",\n                \"id\": \"${featureList[key].name}\",\n                \"geometry\": \n                {\n                \"type\" : \"Polygon\",\n                \"coordinates\" : ${featureList[key].geometryCoords}\n            },\n            \"properties\": {\n                <#if featureList[key].owcProperties != \"\">${featureList[key].owcProperties},</#if>\n                \"offerings\" : [\n                    {\n                      \"code\" : \"http://www.opengis.net/spec/owc-atom/1.0/req/wms\",\n                      \"operations\" : [{\n                          \"code\" : \"GetCapabilities\",\n                          \"method\" : \"GET\",\n                          \"type\" : \"application/xml\",\n                          \"href\" : \"${featureList[key].getMapBaseUrl}?SERVICE=WMS&VERSION=1.3.0&REQUEST=GetCapabilities\",\n                          \"request\":{},\n                          \"result\":{}\n                        },{\n                          \"code\" : \"GetMap\",\n                          \"method\" : \"GET\",\n                          \"type\" : \"image/png\",\n                          \"href\" : \"${featureList[key].getMapBaseUrl}?SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&SRS=${featureList[key].srs}&BBOX=${featureList[key].bbox}&WIDTH=500&HEIGHT=500&LAYERS=${featureList[key].layers}&STYLES=${featureList[key].styles}&FORMAT=image/png&BGCOLOR=0xffffff&TRANSPARENT=TRUE&EXCEPTIONS=application/vnd.ogc.se_xml\",\n                          \"request\":{},\n                          \"result\":{}\n                        }],\n                      \"contents\" : []\n                    }\n                <#if featureList[key].type == \"VECTOR\">\n                    ,{\n                      \"code\" : \"http://www.opengis.net/spec/owc-atom/1.0/req/wfs\",\n                      \"operations\" : [{\n                          \"code\" : \"DescribeFeatureType\",\n                          \"method\" : \"GET\",\n                          \"type\" : \"application/xml\",\n                          \"href\" : \"${featureList[key].getMapBaseUrl}?SERVICE=WFS&VERSION=1.1.0&REQUEST=DescribeFeatureType&TYPENAME=${featureList[key].layers}\",\n                          \"request\":{},\n                          \"result\":{}\n                        },{\n                          \"code\" : \"GetFeature\",\n                          \"method\" : \"GET\",\n                          \"type\" : \"application/xml\",\n                          \"href\" : \"${featureList[key].getMapBaseUrl}?SERVICE=WFS&VERSION=1.1.0&REQUEST=GetFeature&TYPENAME=${featureList[key].layers}\",\n                          \"request\":{},\n                          \"result\":{}\n                        }],\n                      \"contents\" : []\n                    }\n            <#elseif featureList[key].type == \"RASTER\">\n                    ,{\n                      \"code\" : \"http://www.opengis.net/spec/owc-atom/1.0/req/wcs\",\n                      \"operations\" : [{\n                          \"code\" : \"DescribeCoverage\",\n                          \"method\" : \"GET\",\n                          \"type\" : \"application/xml\",\n                          \"href\" : \"${featureList[key].getMapBaseUrl}?SERVICE=WCS&VERSION=1.1.0&REQUEST=GetCapabilities&IDENTIFIER=${featureList[key].layers}\",\n                          \"request\":{},\n                          \"result\":{}\n                        },{\n                          \"code\" : \"GetCoverage\",\n                          \"method\" : \"GET\",\n                          \"type\" : \"image/tiff\",\n                          \"href\" : \"${featureList[key].getMapBaseUrl}?SERVICE=WCS&VERSION=1.1.0&REQUEST=GetCoverage&IDENTIFIER=${featureList[key].layers}&BOUNDINGBOX=${featureList[key].bbox}&FORMAT=GeoTIFF\",\n                          \"request\":{},\n                          \"result\":{}\n                        }],\n                      \"contents\" : []\n                    }\n            </#if>\n            ]\n           }\n         }<#if key_has_next>,</#if>\n     </#list>\n     ]\n  , \n\n  \"properties\" : {\n            ${owcProperties}\n      }      \n\n}\n

          Sample owc_json_ctx.json

          \"lang\" : \"en\",\n\"title\" : \"Sample Title goes here\",\n\"subtitle\" : \"Sample sub-title goes here\",\n\"generator\" : \"Sample generator\",\n\"rights\" : \"Sample Legal Constraints and CopyRights (C)\",\n\"authors\" : [{\"name\" : \"Author1 Name\"}, {\"name\" : \"Author2 Name\"}],\n\"contributors\" : [{\"name\" : \"Contrib1 Name\"}, {\"name\" : \"Contrib2 Name\"}],\n\"categories\" : [{\n        \"term\" : \"wms\",\n        \"label\" : \"This file is compliant with version 1.0 of OGC Context\"\n    },{\n        \"term\" : \"maps\",\n        \"label\" : \"This file contains maps\"\n}],\n\"links\" : [{\n        \"rel\" : \"profile\",\n        \"href\" : \"http://www.opengis.net/spec/owc-atom/1.0/req/core\",\n        \"title\" : \"This file is compliant with version 1.0 of OGC Context\"\n    },{\n        \"rel\" : \"via\",\n        \"type\" : \"application/xml\",\n        \"href\" : \"http://www.opengis.uab.cat/wms/satcat/metadades/EPSG_23031/Cat_20110301.htm\",\n        \"title\" : \"HMTL metadata in Catalan\"\n    }]\n

          Sample result#.json

          \"title\" : \"Result 2\",\n\"updated\" : \"${lastUpdated}\",\n\"content\" : \"Sample Content Description for result 2 goes here\",\n\"authors\" : [\n    {\n      \"name\" : \"GeoServer Administrator\",\n      \"email\" : \"info@sample.author.com\"\n    }\n],\n\"authors\" : [{\"name\" : \"Author2.1 Name\"}, {\"name\" : \"Author2.2 Name\"}],\n\"contributors\" : [{\"name\" : \"Contrib2.1 Name\"}, {\"name\" : \"Contrib2.2 Name\"}],\n\"categories\" : [{\"name\" : \"Category2.1 Name\"}, {\"name\" : \"Category2.2 Name\"}],\n\"links\" : [\n    {\n     \"rel\" : \"enclosure\",\n     \"type\" : \"image/png\",\n     \"title\" : \"WMS output for ${title}\",\n     \"href\" : \"${getMapBaseUrl}?SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&SRS=${srs}&BBOX=${bbox}&WIDTH=500&HEIGHT=500&LAYERS=${layers}&FORMAT=image/png&BGCOLOR=0xffffff&TRANSPARENT=TRUE&EXCEPTIONS=application/vnd.ogc.se_xml\"\n    },\n    {\n     \"rel\" : \"icon\",\n     \"type\" : \"image/png\",\n     \"title\" : \"Preview for ${title}\",\n     \"href\" : \"${getMapBaseUrl}?SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&SRS=${srs}&BBOX=${bbox}&WIDTH=100&HEIGHT=100&LAYERS=${layers}&STYLES=${styles}&FORMAT=image/png&BGCOLOR=0xffffff&TRANSPARENT=TRUE&EXCEPTIONS=application/vnd.ogc.se_xml\"\n    },\n    {\n     \"rel\" : \"via\",\n     \"type\" : \"application/vnd.ogc.wms_xml\",\n     \"title\" : \"Original GetCapabilities document\",\n     \"href\" : \"${getMapBaseUrl}?SERVICE=WMS&VERSION=1.1.1&REQUEST=GetCapabilities\"\n    }\n]\n

        Other options for the Outputs

        • backup_on_wps_execution_shared_dir; This is a boolean which tells to the Remote WPS to store first the outcome into the sharedir defined into the [DEFAULT] section before streaming out to GeoServer. This allows the Remote WPS to preserve the outcomes even when the resources are cleaned out.

        • upload_data; This is a boolean which tells to the Remote WPS to upload first the outcome into the host defined into the [UPLOADER] section before streaming out to GeoServer. This allows the Remote WPS to preserve the outcomes even when the resources are cleaned out.

          ::: warning ::: title Warning :::

          If both enabled for a certain output, the backup_on_wps_execution_shared_dir takes precedence to the upload_data one. :::

        • publish_as_layer; A boolean to instruct GeoServer Remote WPS to try to automatically publish the outcome as a new Layer through the GeoServer Importer Plugin.

        • publish_default_style; The default style to use when publishing the Layer.

        • publish_target_workspace; The default workspace to use when publishing the Layer.

        • publish_layer_name; The default name to use when publishing the Layer.

        "},{"location":"community/remote-wps/install_python/#logging-section","title":"Logging Section","text":"
        # ########################################### #\n# Logging RegEx and Levels                    #\n# ########################################### #\n\n[Logging]\nstdout_parser = [.*\\[DEBUG\\](.*), .*\\[INFO\\] ProgressInfo\\:([-+]?[0-9]*\\.?[0-9]*)\\%, .*\\[(INFO)\\](.*), .*\\[(WARN)\\](.*), .*\\[(ERROR)\\](.*), .*\\[(CRITICAL)\\](.*)]\nstdout_action = [ignore,          progress,                                          log,              log,              log,               abort]\n
        • stdout_parser

          This property must contain a list of regular expressions matching the possible executable STDOUT logging messages the user wants to forward to GeoServer.

          As an instance

          .*\\[DEBUG\\](.*)\n

          Matches all the messages containing the keyword [DEBUG] and forwards to the corresponding stdout_action (see below) the content of the first matching group (.*)

          In this case everything after [DEBUG] is forwarded to the action.

          Another example

          .*\\[INFO\\] ProgressInfo\\:([-+]?[0-9]*\\.?[0-9]*)\\%\n

          Matches all the messages containing the keyword [INFO] ProgressInfo:<any_number>% and forwards to the corresponding stdout_action (see below) the content of the first matching group ([-+]?[0-9]*\\.?[0-9]*)

          In this case the expression extracts a float number form the text along with the sign [-+]

        • stdout_action

          This property must contain a list of keywords associated to a particular action which will take the content of the corresponding regular expression and forwards it to GeoServer packaged ad a specific XMPP message.

          As an instance

          • progress; gets the content of the match and sends a PROGRESS XMPP message to GeoServer. The PROGRESS messgae must always contain a number.
          • abort; gets the content of the match and sends a ABORT XMPP message to GeoServer. This will cause GeoServer to mark the WPS Process as FAILED.
          • ignore; simply throws out everything matching the corresponding regular expression.
          • log; sends a LOG message to GeoServer with the content of the match. This will appear into the GeoServer Log file.
        "},{"location":"community/remote-wps/install_xmpp/","title":"Installation Of OpenFire XMPP Server To Exchange Messages","text":"

        The following commands will prepare a CentOS 7 Minimal ISO machine for the deployment of:

        • Openfire XMPP Server
        • NFS shared file-system

        Note

        Prerequisite to this section, is the basic preparation of the CentOS machine as described on the section Deployment And Setup Of GeoServer With WPS Remote Plugin.

        "},{"location":"community/remote-wps/install_xmpp/#setup-and-configuration-of-openfire-xmpp-server","title":"Setup and configuration of Openfire XMPP Server","text":"

        Originally named Jabber, XMPP is the new label for Extensible Messaging and Presence Protocol. and it is associated mostly with instant messaging.

        "},{"location":"community/remote-wps/install_xmpp/#setting-up-postgresql-database-backend","title":"Setting up PostgreSQL database backend","text":"

        For the purposes of running a private XMPP communication platform, we can safely stick with PostgreSQL 9.2 which is stable and comes in CentOS 7 by default.

        # as root\n\n$> yum install -y postgresql postgresql-server postgresql-devel postgresql-libs\n\n# After PostgreSQL packages are installed, enable PostgreSQL to start after each reboot.\n\n$> systemctl enable postgresql.service\n\n# Initialize directory structure and postgres system database.\n\n$> postgresql-setup initdb\n\n# And start the service.\n\n$> systemctl start postgresql.service\n

        Postgres installation is now up and running, lets proceed with setting up the specific database and the dedicated user for OpenFire, together with authentication method and administration password.

        For full administration access, switch to postgres user.

        su postgres\n\n# as postgres\n\n$> createdb openfire\n$> createuser -P openfire\n\n# The '-P' parameter ensures that the shell will explicitly ask for user's password and you will need to type it in. Enter the password twice\n\n   R3m0T3wP5\n\n$> psql -U postgres -d postgres -c \"ALTER USER postgres WITH PASSWORD 'R3m0T3wP5';\"\n

        Postgres user is secured with the new password. Lets put authentication methods in practice and force every application or shell login to prompt for these passwords.

        # as postgres\n\n$> vim /var/lib/pgsql/data/pg_hba.conf\n\n# Scroll down to the bottom of the file and replace all peer and ident strings with md5 string.\n# The configuration should look like this:\n\n   # TYPE DATABASE USER CIDR-ADDRESS METHOD\n\n   # \"local\" is for Unix domain socket connections only\n\n   local      all         all                 md5\n\n   # IPv4 local connections:\n\n   host       all         all 127.0.0.1/32    md5\n\n   # IPv6 local connections:\n\n   host       all         all      ::1/128    md5\n

        Go back from postgres shell (Ctrl+D) and restart postgresql service as root.

        # as root\n\n$> systemctl restart postgresql.service\n
        "},{"location":"community/remote-wps/install_xmpp/#download-and-install-openfire-from-ignite-realtime","title":"Download and install Openfire from Ignite Realtime","text":"

        Since OpenFire RPM package is not included in any major RHEL / CentOS / Fedora distribution repositories, it must be downloaded directly from Ignite Realtime website.

        # as root\n\n$> wget http://www.igniterealtime.org/downloadServlet?filename=openfire/openfire-3.10.0-1.i386.rpm -O openfire-3.10.0-1.i386.rpm\n\n# This package come in 32bit version only, so in case we run this installation on x86_64 system, we need to make sure to install corresponding 32bit libraries as well.\n\n$> yum install -y /root/openfire-3.9.3-1.i386.rpm\n\n$> yum install -y glibc.i686\n

        Enable the openfire service and start it

        # as root\n\n$> chkconfig openfire on\n\n$> systemctl start openfire.service\n\n# We need to open the firewall ports in order to expose the gui to the outside\n\n$> firewall-cmd --permanent --zone=public --add-port=9090/tcp\n$> firewall-cmd --permanent --zone=public --add-port=9091/tcp\n$> firewall-cmd --reload\n

        Configuration of Openfire server

        Move the browser to the url

        http://YOUR-SERVER-IP:9090

        Choose preferable language and hit Contine

        Specify the server Domain as

        geoserver.org

        Choose the Standard Database Connection in the next section

        Provide the Database connection parameters for the PostgreSQL DB in the standard connection section.

        The password for the user openfire is the same provided in the PostgreSQL DB setup (see above).

        Note

        Be sure the openfire database and user have been correctly created on PostgreSQL and the passwords provided (see above for instructions).

        If there are no connection issues, choose Default value on the users profile settings section.

        Create the Administrator account in the next section.

        The password must match the one specified in the remoteProcess.properties file

        R3m0T3wP5

        The initial setup is now complete. Log into the system using the newly created admin account.

        Move to the Server Certificates section of the Server Settings tab panel.

        Warning

        This passage is not needed anymnore on Openfire 4.0+. At least the management of the certificates is a bit different. Please refer to the specific Openfire documentation for more information.

        Make sure that the self-signed certificates have been correctly generated and click on here in order to restart the server

        Warning

        This passage is not needed anymnore on Openfire 4.0+. At least the management of the certificates is a bit different. Please refer to the specific Openfire documentation for more information.

        The same section now shows the server certificates and won't ask for another restart unless the certificates are generated again.

        Update the Security Settings in order to allow the server accepting self-signed certificates on secured connections.

        Warning

        This passage is not needed anymnore on Openfire 4.0+. At least the management of the certificates is a bit different. Please refer to the specific Openfire documentation for more information.

        Create the default channel as shown in the next figure.

        Create the management channel as shown in the next figure. Pay attention to the Room Options and specify the password for the channel

        R3m0T3wP5

        Double check that the channels have been correctly created and they appear in the Group Chat Rooms.

        Restart GeoServer

        # as root\n\n$> systemctl restart geoserver\n

        After the GeoServer has successfully restarted, double check that it is connected to the server using the admin credentials.

        It is very important that the user is shown as Authenticated.

        Check also that the user is registered to the XMPP channels created above.

        "},{"location":"community/remote-wps/install_xmpp/#firewall-rules-for-xmpp-ports","title":"Firewall Rules For XMPP Ports","text":"

        By default the TCP Ports where the XMPP Server is listening for incoming connection are closed to the outside. Therefore it is necessary to enable the Firewall rules at least for the Openfire default secured port 5223 unless it has been changed by the user during the server setup.

        In order to do that issue the following commands:

        # as root\n\n# We need to open the firewall ports in order to expose the gui to the outside\n\n$> firewall-cmd --permanent --zone=public --add-port=5222/tcp\n$> firewall-cmd --permanent --zone=public --add-port=5223/tcp\n\n$> firewall-cmd --reload\n
        "},{"location":"community/remote-wps/install_xmpp/#forward-proxy-to-apache-httpd-server","title":"Forward Proxy to Apache HTTPD Server","text":"

        The procedures described in this section allows to expose GeoServer via HTTPD through Apache HTTPD Server.

        Those steps are not mandatory and the procedure may change accordingly to the final deployment on production systems.

        In order to install Apache HTTPD Server proceed as follows:

        # as root\n\n$> yum -y install httpd mod_ssl\n\n$> vi /etc/httpd/conf.d/forward-proxy.conf\n\n   ProxyRequests Off\n\n   ProxyPass /geoserver ajp://localhost:8009/geoserver\n   ProxyPassReverse /geoserver ajp://localhost:8009/geoserver\n\n$> systemctl enable httpd.service\n\n$> service httpd restart\n

        Selinux, enabled by default, needs to be instructed to allow http network connections. This can be done by running the command:

        # as root\n\n$> /usr/sbin/setsebool -P httpd_can_network_connect 1\n
        "},{"location":"community/remote-wps/install_xmpp/#shared-folder-through-the-nfs-protocol","title":"Shared Folder through the NFS protocol","text":"

        The next steps describe how to setup the system in order to expose a Shared Network Folder which will be used to store the outcomes of the remote processing.

        The following procedures are not mandatory and the final deployment on the production system may be configured to use different protocols and frameworks to expose shared file-systems.

        The setup and initial configuration of the NFS packages can be done by following the next procedure:

        # as root\n\n$> yum -y install nfs-utils\n\n$> vi /etc/idmapd.conf\n\n   # The following should be set to the local NFSv4 domain name\n\n   # The default is the host's DNS domain name.\n   Domain = geoserver.org\n

        Note

        The domain specified above maybe different depending on the final system deployment and the production environment setup.

        Creating and exposing a shared folder is possible by following the next steps:

        1. as root
        2. Create the physical folder structure to be exposed via the Network Filesystem
        $> mkdir /share\n$> mkdir /share/xmpp_data\n$> mkdir /share/xmpp_data/output\n$> mkdir /share/xmpp_data/resource_dir\n
        1. Modify the rights in order to allow

          $> chmod -Rf 777 /share\n
        2. Once the physical folder is ready it must be exposed via the exports

        $> vi /etc/exports\n
        1. write settings for NFS exports
        /share host_ip/24(rw,no_root_squash)\n
        1. Restart the NFS services
        $> systemctl start rpcbind nfs-server\n\n$> systemctl enable rpcbind nfs-server\n

        Note

        The host_ip must be the one of the host exposing the shared folder.

        Selinux, enabled by default, needs to be instructed to allow NFS connections. This can be done by running the following commands:

        # as root\n\n$> setsebool -P httpd_use_nfs=1\n\n$> setsebool -P samba_share_nfs=1\n\n$> setsebool -P samba_export_all_ro=1\n\n$> setsebool -P samba_export_all_rw=1\n
        "},{"location":"community/remote-wps/running_example/","title":"A Remote \"Gdal Contour\" Process Binding Example","text":"

        Before continue reading this section, please be sure to have fully understood and successfully completed all the passages at sections:

        • Deployment And Setup Of GeoServer With WPS Remote Plugin
        • Installation Of OpenFire XMPP Server To Exchange Messages
        • Deployment And Setup Of The XMPP Python Wrappers
        "},{"location":"community/remote-wps/running_example/#running-the-python-wps-agent","title":"Running the Python WPS Agent","text":"

        In order to start the RemoteWPS Python Wrapper, we need to run an instance of the wpsagent.py using the configuration files defined at section Deployment And Setup Of The XMPP Python Wrappers

        $> cd C:\\work\\RemoteWPS\n\n$> python wpsagent.py -r .\\xmpp_data\\configs\\remote.config -s .\\xmpp_data\\configs\\myservice\\service.config service\n

        Few instants after the execution of the command, you should be able to see con invite message on the prompt

        and the default.GdalContour instance successfully connected and authenticated into the XMPP Server channels

        The new GeoServer WPS Process should be now available among the GeoServer Processes

        The GeoServer Remote Process Factory automatically creates the WPS interface for the new process, exposing through the OGC WPS Protocol the Inputs and Outputs definitions like shown in the illustration below

        At the Execute Request the Remote WPS Python framework starts a new thread and assigns to it the unique execution_id provided by GeoServer.

        The logs of the execution are stored into the working directory

        From the log file is possible to recognize the full command line executed by the Remote WPS Python wrapper along with the lines received through the standard output

        The main window shows the received XMPP messages and the actions taken accordingly

        Note

        The same information can be found into the log file specified into the \"logger.properties\" file (see above).

        On GeoServer side, it is possible to follow the process execution by following the messages sent via XMPP to the GeoServer logs

        $> tail -F -n 200 /storage/data/logs/geoserver.log\n

        "},{"location":"community/s3-geotiff/","title":"S3 Support for GeoTiff","text":"

        Support for GeoTiffs hosted on Amazon S3 or on other Amazon S3 compatible services, via a custom GeoTools GridFormat.

        "},{"location":"community/s3-geotiff/#whats-in-the-box","title":"What's in the Box?","text":"
        • org.geotools.s3.geotiff: S3 GeoTiff Format/FormatFactory/GridCoverage2dReader implementations based off of the GeoTiff versions. Only very minor changes to their parent classes.
        • org.geotools.s3.cache: Very basic caching of images from S3 based off of EhCache.
        • S3ImageInputStreamImpl: An implementation of ImageInputStream from JAI for reading imagery from S3. This class mainly contains the logic of stream position and chunking, while the cache package handles the actual S3 reads.
        "},{"location":"community/s3-geotiff/#geotiffs-hosted-on-amazon-s3","title":"GeoTiffs hosted on Amazon S3","text":""},{"location":"community/s3-geotiff/#configuration","title":"Configuration","text":"

        Almost all configuration is currently done via system properties. For caching configuration, please see the class org.geotools.s3.cache.CacheConfig.

        "},{"location":"community/s3-geotiff/#usage","title":"Usage","text":"

        S3GeoTiff uses s3:// style URLs to operate. The only twist is that S3GeoTiff uses query string parameters to configure certain parameters

        • awsRegion: Controls the region to use when connecting. Needs to be in Java enum format eg. US_WEST_2
        • useAnon: Controls whether to authenticate anonymously. This needs to be used to connect anonymous buckets

        For example:

        s3://landsat-pds/L8/001/002/LC80010022016230LGN00/LC80010022016230LGN00_B1.TIF?useAnon=true&awsRegion=US_WEST_2

        "},{"location":"community/s3-geotiff/#credentials","title":"Credentials","text":"

        Unless S3_USE_ANON is set to true the default AWS client credential chain is used.

        "},{"location":"community/s3-geotiff/#geotiffs-hosted-on-other-amazon-s3-compatible-services","title":"GeoTiffs hosted on other Amazon S3 compatible services","text":"

        Access geotiffs on S3 servers not hosted on Amazon, e.g. https://www.minio.io/ or other. There are 2 steps to access the geofiff files. configure the server in the s3.properties file and then you can use the prefix as an alias to access the file in the S3GeoTiff module for geoserver.

        "},{"location":"community/s3-geotiff/#configuration_1","title":"Configuration","text":"

        The S3 endpoints are configured in the s3.properties file. The following properties are needed for each endpoint. The prefix alias can be any value you choose in order to configure multiple endpoints.

        • alias.s3.endpoint=http://your-s3-server/
        • alias.s3.user=your-user-name
        • alias.s3.password=your-password
        "},{"location":"community/s3-geotiff/#usage_1","title":"Usage","text":"

        Using the above configuration in the s3.properties file, the files on the S3 service can be accessed with the following URL style configuration in geoserver:

        alias://bucketname/filename.tiff

        • alias: The prefix you choose for the configuration of the endpoint
        • bucketname: The path to the folder where the geotiffs are stored
        • filename.tif: The name of the geotiff file
        "},{"location":"community/schemaless-features/","title":"Schemaless Features Plugin","text":"

        This plugin includes support for serving complex features directly from Schemaless Feature sources.

        Warning

        At the time of writing only MongoDB support is provided. The plug-in supports only the following services/operation with the indicated output formats:

        • WMS:
          • GetMap (all the formats)
          • GetFeatureInfo (GeoJSON and HTML outputs only)
        • WFS:
          • GetFeature (GeoJSON output only)
        • Installing the Schemaless Mongo module
        • MongoDB Schemaless Support
        "},{"location":"community/schemaless-features/install/","title":"Installing the Schemaless Mongo module","text":"
        1. Download mongodb-schemaless nightly GeoServer community module.

          Warning

          Verify that the version number in the filename corresponds to the version of GeoServer you are running (for example geoserver- 2.24.2-schemaless-features-plugin.zip above).

        2. Extract the contents of the archive into the WEB-INF/lib directory of the GeoServer installation.

        3. On restart the MongoDB Schemaless vector source option will be available from the New Data Source page:

        "},{"location":"community/schemaless-features/schemaless-mongo/","title":"MongoDB Schemaless Support","text":"

        By clicking on MongoDB Schemaless we land on the store configuration page. The only needed parameters are the workspace and the MongoDBURI. For a description of the available MongoDB URI format check here .

        After saving, it will be possible to serve every MongoDB collection found in the database as a layer, by the layer configuration page.

        The default geometry can be defined by setting a geometry index on the desired geometry attribute in the MongoDB collection.

        As an example of the obtained output we will use the Stations use case. In the MongoDB collection we have the following document among the others being served:

        {\n\"_id\": {\n \"$oid\": \"58e5889ce4b02461ad5af080\"\n},\n\"id\": \"1\",\n\"name\": \"station 1\",\n\"numericValue\": 20,\n\"contact\": {\n \"mail\": \"station1@mail.com\"\n},\n\"geometry\": {\n \"coordinates\": [\n   50,\n   60\n ],\n \"type\": \"Point\"\n},\n\"measurements\": [\n {\n   \"name\": \"temp\",\n   \"unit\": \"c\",\n   \"values\": [\n     {\n       \"time\": 1482146800,\n       \"value\": 20\n     }\n   ]\n },\n {\n   \"name\": \"wind\",\n   \"unit\": \"km/h\",\n   \"values\": [\n     {\n       \"time\": 1482146833,\n       \"value\": 155\n     }\n   ]\n }\n]\n}\n

        The GeoJSON output for that specific document will be the following feature:

        {\n \"type\": \"Feature\",\n \"id\": \"58e5889ce4b02461ad5af080\",\n \"geometry\": {\n   \"type\": \"Point\",\n   \"coordinates\": [\n     50,\n     60\n   ]\n },\n \"properties\": {\n   \"@featureType\": \"stations\",\n   \"_id\": \"58e5889ce4b02461ad5af080\",\n   \"name\": \"station 1\",\n   \"numericValue\": 20,\n   \"contact\": {\n     \"type\": \"Feature\",\n     \"id\": \"fid-3087ff95_17844d87c61_-7aad\",\n     \"geometry\": null,\n     \"properties\": {\n       \"@featureType\": \"Contact\",\n       \"mail\": \"station1@mail.com\"\n     }\n   },\n   \"id\": \"1\",\n   \"measurements\": [\n     {\n       \"values\": [\n         {\n           \"value\": 20,\n           \"time\": 1482146800\n         }\n       ],\n       \"name\": \"temp\",\n       \"unit\": \"c\"\n     },\n     {\n       \"values\": [\n         {\n           \"value\": 155,\n           \"time\": 1482146833\n         }\n       ],\n       \"name\": \"wind\",\n       \"unit\": \"km/h\"\n     }\n   ]\n  }\n}\n

        As it is possible to see, the feature object is very close to the appearance of the corresponding MongoDB document.

        "},{"location":"community/schemaless-features/schemaless-mongo/#simplified-property-access","title":"Simplified Property Access","text":"

        Behind the scenes the module builds a complex feature schema on the fly automatically along with the complex features being served. Every array or object in the document is considered to be a nested feature. This might result in a hard time trying to foreseen the xpath needed to access a feature property for styling or filtering purpose, because the internal nested feature representation follows the GML object property model.

        To clarify this lets assume that we want to filter the stations features on a measurements value greater than 100. According to the above GeoJSON feature representation the whole filter will look like: measurements.MeasurementsFeature.values.ValuesFeature.value > 100.

        The property path needs to specify for each nested complex attribute the property name and the feature name. The former coincides with the original attribute name in the document, while the latter with that attribute name with the first letter upper cased and the Feature suffix.

        To avoid users needing to deal with this complexity, simplified property access support has been implemented. This allows referencing a property with a path that matches the GeoJSON output format or the document structure.

        The previously defined filter could then be: measurements.values.value > 100.

        As can be seen, the property path can be easily inferred both from the GeoJSON output and from the MongoDB document.

        "},{"location":"community/smart-data-loader/","title":"Smart Data Loader Extension","text":"

        This plugin allows automation of the configuration for Application-Schema based complex features, by providing a data source that will automatically generate the required XSD definition and App-Schema mappings files.

        Warning

        The current version only supports PostGIS datasources.

        • Installing the Smart Data Loader extension
        • Smart Data Loader
        "},{"location":"community/smart-data-loader/data-store/","title":"Smart Data Loader","text":""},{"location":"community/smart-data-loader/data-store/#data-store","title":"Data Store","text":"

        In addition to the parameters common to each DataStore configuration such as workspace, name and description, the page shows the following connection parameters in the dedicated section:

        • Data store name: the name of the PostGIS DataStore already created under the same workspace. It will be used to access the database and build xsd and mappings file based on the database metadata.
        • Root entity: the name of the DB table to be used as the root FeatureType to build the xsd and the mapping file.

        Once selected the root entity a diagram of the entities available will appear. Uncheck the attributes that should not be included in the XSD and the mapping file.

        "},{"location":"community/smart-data-loader/data-store/#meteo-stations-example","title":"Meteo Stations example","text":"

        This section provides an example of configuring the DataStore with weather station information.

        Note

        This example is intended to be illustrative of a general approach, and does not reflect a formally defined schema or information model. Also, more complicated scenarios may require significantly more work.

        A diagram of the entities involved is shown below:

        Entities diagram

        As shown, the dataset consists of:

        • A One to Many relationship between the meteo_stations and meteo_observations tables.
        • A Many to Many relationship between the meteo_stations and meteo_maintainers tables, mapped by the relation table meteo_stations_maintainers.
        • A Many to One relationship between the meteo_observations and the meteo_parameters tables.

        Assuming a PostGIS datastore named meteos-simple under the st workspace, by opening the Smart Data Loader page we will have to select the desired workspace and the postgis datastore belonging to the selected workspace, in this case the meteos-postgis one:

        Smart Data Loader configuration page

        After having selected the root entity as meteo-stations, a schema, which will be used to generate the XSD and mappings file, will appear. Each attribute/entity can be unchecked to avoid it being included in the generated mappings.

        ..figure:: images/store-relations.png

        Smart Data Loader configuration page - entities' tree

        After pressing the save button, the files will be generated automatically in the store data-dir directory under app-schema-mappings directory.

        The generated mappings file for this example are explained below.

        GML schema definition:

        <?xml version=\"1.0\" encoding=\"UTF-8\"?><xs:schema xmlns:gml=\"http://www.opengis.net/gml/3.2\" xmlns:st=\"http://www.stations.org/1.0\" xmlns:xs=\"http://www.w3.org/2001/XMLSchema\" attributeFormDefault=\"unqualified\" elementFormDefault=\"qualified\" targetNamespace=\"http://www.stations.org/1.0\" version=\"1.0\">\n<xs:import namespace=\"http://www.opengis.net/gml/3.2\" schemaLocation=\"http://schemas.opengis.net/gml/3.2.1/gml.xsd\"/>\n<xs:complexType name=\"MeteoStationsType\">\n  <xs:complexContent>\n    <xs:extension base=\"gml:AbstractFeatureType\">\n      <xs:sequence>\n        <xs:element maxOccurs=\"1\" minOccurs=\"0\" name=\"id\" type=\"xs:int\"/>\n        <xs:element maxOccurs=\"1\" minOccurs=\"0\" name=\"code\" type=\"xs:string\"/>\n        <xs:element maxOccurs=\"1\" minOccurs=\"0\" name=\"common_name\" type=\"xs:string\"/>\n        <xs:element maxOccurs=\"1\" minOccurs=\"0\" name=\"position\" type=\"gml:GeometryPropertyType\"/>\n        <xs:element maxOccurs=\"unbounded\" minOccurs=\"0\" name=\"meteoObservations\" type=\"st:MeteoObservationsPropertyType\"/>\n        <xs:element maxOccurs=\"unbounded\" minOccurs=\"0\" name=\"meteoStationsMaintainers\" type=\"st:MeteoStationsMaintainersPropertyType\"/>\n      </xs:sequence>\n    </xs:extension>\n  </xs:complexContent>\n</xs:complexType>\n<xs:element name=\"MeteoStationsFeature\" substitutionGroup=\"gml:AbstractFeature\" type=\"st:MeteoStationsType\"/>\n<xs:complexType name=\"MeteoObservationsType\">\n  <xs:complexContent>\n    <xs:extension base=\"gml:AbstractFeatureType\">\n      <xs:sequence>\n        <xs:element maxOccurs=\"1\" minOccurs=\"0\" name=\"id\" type=\"xs:int\"/>\n        <xs:element maxOccurs=\"1\" minOccurs=\"0\" name=\"time\" type=\"xs:dateTime\"/>\n        <xs:element maxOccurs=\"1\" minOccurs=\"0\" name=\"value\" type=\"xs:double\"/>\n        <xs:element maxOccurs=\"unbounded\" minOccurs=\"0\" name=\"meteoParameters\" type=\"st:MeteoParametersPropertyType\"/>\n      </xs:sequence>\n    </xs:extension>\n  </xs:complexContent>\n</xs:complexType>\n<xs:element name=\"MeteoObservationsFeature\" substitutionGroup=\"gml:AbstractFeature\" type=\"st:MeteoObservationsType\"/>\n<xs:complexType name=\"MeteoObservationsPropertyType\">\n  <xs:sequence minOccurs=\"0\">\n    <xs:element ref=\"st:MeteoObservationsFeature\"/>\n  </xs:sequence>\n  <xs:attributeGroup ref=\"gml:AssociationAttributeGroup\"/>\n</xs:complexType>\n<xs:complexType name=\"MeteoParametersType\">\n  <xs:complexContent>\n    <xs:extension base=\"gml:AbstractFeatureType\">\n      <xs:sequence>\n        <xs:element maxOccurs=\"1\" minOccurs=\"0\" name=\"id\" type=\"xs:int\"/>\n        <xs:element maxOccurs=\"1\" minOccurs=\"0\" name=\"param_name\" type=\"xs:string\"/>\n        <xs:element maxOccurs=\"1\" minOccurs=\"0\" name=\"param_unit\" type=\"xs:string\"/>\n      </xs:sequence>\n    </xs:extension>\n  </xs:complexContent>\n</xs:complexType>\n<xs:element name=\"MeteoParametersFeature\" substitutionGroup=\"gml:AbstractFeature\" type=\"st:MeteoParametersType\"/>\n<xs:complexType name=\"MeteoParametersPropertyType\">\n  <xs:sequence minOccurs=\"0\">\n    <xs:element ref=\"st:MeteoParametersFeature\"/>\n  </xs:sequence>\n  <xs:attributeGroup ref=\"gml:AssociationAttributeGroup\"/>\n</xs:complexType>\n<xs:complexType name=\"MeteoStationsMaintainersType\">\n  <xs:complexContent>\n    <xs:extension base=\"gml:AbstractFeatureType\">\n      <xs:sequence>\n        <xs:element maxOccurs=\"1\" minOccurs=\"0\" name=\"id\" type=\"xs:int\"/>\n        <xs:element maxOccurs=\"unbounded\" minOccurs=\"0\" name=\"meteoMaintainers\" type=\"st:MeteoMaintainersPropertyType\"/>\n      </xs:sequence>\n    </xs:extension>\n  </xs:complexContent>\n</xs:complexType>\n<xs:element name=\"MeteoStationsMaintainersFeature\" substitutionGroup=\"gml:AbstractFeature\" type=\"st:MeteoStationsMaintainersType\"/>\n<xs:complexType name=\"MeteoStationsMaintainersPropertyType\">\n  <xs:sequence minOccurs=\"0\">\n    <xs:element ref=\"st:MeteoStationsMaintainersFeature\"/>\n  </xs:sequence>\n  <xs:attributeGroup ref=\"gml:AssociationAttributeGroup\"/>\n</xs:complexType>\n<xs:complexType name=\"MeteoMaintainersType\">\n  <xs:complexContent>\n    <xs:extension base=\"gml:AbstractFeatureType\">\n      <xs:sequence>\n        <xs:element maxOccurs=\"1\" minOccurs=\"0\" name=\"id\" type=\"xs:int\"/>\n        <xs:element maxOccurs=\"1\" minOccurs=\"0\" name=\"name\" type=\"xs:string\"/>\n        <xs:element maxOccurs=\"1\" minOccurs=\"0\" name=\"surname\" type=\"xs:string\"/>\n        <xs:element maxOccurs=\"1\" minOccurs=\"0\" name=\"company\" type=\"xs:string\"/>\n      </xs:sequence>\n    </xs:extension>\n  </xs:complexContent>\n</xs:complexType>\n<xs:element name=\"MeteoMaintainersFeature\" substitutionGroup=\"gml:AbstractFeature\" type=\"st:MeteoMaintainersType\"/>\n<xs:complexType name=\"MeteoMaintainersPropertyType\">\n  <xs:sequence minOccurs=\"0\">\n    <xs:element ref=\"st:MeteoMaintainersFeature\"/>\n  </xs:sequence>\n  <xs:attributeGroup ref=\"gml:AssociationAttributeGroup\"/>\n</xs:complexType>\n</xs:schema>\n

        App-Schema mappings file:

        <?xml version=\"1.0\" encoding=\"UTF-8\"?><ns3:AppSchemaDataAccess xmlns:ns2=\"http://www.opengis.net/ogc\" xmlns:ns3=\"http://www.geotools.org/app-schema\">\n<namespaces>\n  <Namespace>\n    <prefix>gml</prefix>\n    <uri>http://www.opengis.net/gml/3.2</uri>\n  </Namespace>\n  <Namespace>\n    <prefix>st</prefix>\n    <uri>http://www.stations.org/1.0</uri>\n  </Namespace>\n</namespaces>\n<includedTypes/>\n<targetTypes>\n  <FeatureType>\n    <schemaUri>./meteo_stations-gml.xsd</schemaUri>\n  </FeatureType>\n</targetTypes>\n<typeMappings>\n  <FeatureTypeMapping>\n    <sourceDataStore>smartappschematest</sourceDataStore>\n    <sourceType>meteo_stations</sourceType>\n    <targetElement>st:MeteoStationsFeature</targetElement>\n    <attributeMappings>\n      <AttributeMapping>\n        <targetAttribute>st:MeteoStationsFeature</targetAttribute>\n        <idExpression>\n          <OCQL>strConcat('MeteoStationsFeature.',id)</OCQL>\n        </idExpression>\n      </AttributeMapping>\n      <AttributeMapping>\n        <targetAttribute>st:id</targetAttribute>\n        <sourceExpression>\n          <OCQL>id</OCQL>\n        </sourceExpression>\n      </AttributeMapping>\n      <AttributeMapping>\n        <targetAttribute>st:code</targetAttribute>\n        <sourceExpression>\n          <OCQL>code</OCQL>\n        </sourceExpression>\n      </AttributeMapping>\n      <AttributeMapping>\n        <targetAttribute>st:common_name</targetAttribute>\n        <sourceExpression>\n          <OCQL>common_name</OCQL>\n        </sourceExpression>\n      </AttributeMapping>\n      <AttributeMapping>\n        <targetAttribute>st:position</targetAttribute>\n        <sourceExpression>\n          <OCQL>position</OCQL>\n        </sourceExpression>\n      </AttributeMapping>\n      <AttributeMapping>\n        <targetAttribute>meteoObservations</targetAttribute>\n        <sourceExpression>\n          <linkField>FEATURE_LINK[1]</linkField>\n          <linkElement>st:MeteoObservationsFeature</linkElement>\n          <OCQL>id</OCQL>\n        </sourceExpression>\n      </AttributeMapping>\n      <AttributeMapping>\n        <targetAttribute>meteoStationsMaintainers</targetAttribute>\n        <sourceExpression>\n          <linkField>FEATURE_LINK[1]</linkField>\n          <linkElement>st:MeteoStationsMaintainersFeature</linkElement>\n          <OCQL>id</OCQL>\n        </sourceExpression>\n      </AttributeMapping>\n    </attributeMappings>\n  </FeatureTypeMapping>\n  <FeatureTypeMapping>\n    <sourceDataStore>smartappschematest</sourceDataStore>\n    <sourceType>meteo_observations</sourceType>\n    <targetElement>st:MeteoObservationsFeature</targetElement>\n    <attributeMappings>\n      <AttributeMapping>\n        <targetAttribute>FEATURE_LINK[1]</targetAttribute>\n        <sourceExpression>\n          <OCQL>station_id</OCQL>\n        </sourceExpression>\n      </AttributeMapping>\n      <AttributeMapping>\n        <targetAttribute>st:MeteoObservationsFeature</targetAttribute>\n        <idExpression>\n          <OCQL>strConcat('MeteoObservationsFeature.',id)</OCQL>\n        </idExpression>\n      </AttributeMapping>\n      <AttributeMapping>\n        <targetAttribute>st:id</targetAttribute>\n        <sourceExpression>\n          <OCQL>id</OCQL>\n        </sourceExpression>\n      </AttributeMapping>\n      <AttributeMapping>\n        <targetAttribute>st:time</targetAttribute>\n        <sourceExpression>\n          <OCQL>time</OCQL>\n        </sourceExpression>\n      </AttributeMapping>\n      <AttributeMapping>\n        <targetAttribute>st:value</targetAttribute>\n        <sourceExpression>\n          <OCQL>value</OCQL>\n        </sourceExpression>\n      </AttributeMapping>\n      <AttributeMapping>\n        <targetAttribute>meteoParameters</targetAttribute>\n        <sourceExpression>\n          <linkField>FEATURE_LINK[1]</linkField>\n          <linkElement>st:MeteoParametersFeature</linkElement>\n          <OCQL>parameter_id</OCQL>\n        </sourceExpression>\n      </AttributeMapping>\n    </attributeMappings>\n  </FeatureTypeMapping>\n  <FeatureTypeMapping>\n    <sourceDataStore>smartappschematest</sourceDataStore>\n    <sourceType>meteo_parameters</sourceType>\n    <targetElement>st:MeteoParametersFeature</targetElement>\n    <attributeMappings>\n      <AttributeMapping>\n        <targetAttribute>FEATURE_LINK[1]</targetAttribute>\n        <sourceExpression>\n          <OCQL>id</OCQL>\n        </sourceExpression>\n      </AttributeMapping>\n      <AttributeMapping>\n        <targetAttribute>st:MeteoParametersFeature</targetAttribute>\n        <idExpression>\n          <OCQL>strConcat('MeteoParametersFeature.',id)</OCQL>\n        </idExpression>\n      </AttributeMapping>\n      <AttributeMapping>\n        <targetAttribute>st:id</targetAttribute>\n        <sourceExpression>\n          <OCQL>id</OCQL>\n        </sourceExpression>\n      </AttributeMapping>\n      <AttributeMapping>\n        <targetAttribute>st:param_name</targetAttribute>\n        <sourceExpression>\n          <OCQL>param_name</OCQL>\n        </sourceExpression>\n      </AttributeMapping>\n      <AttributeMapping>\n        <targetAttribute>st:param_unit</targetAttribute>\n        <sourceExpression>\n          <OCQL>param_unit</OCQL>\n        </sourceExpression>\n      </AttributeMapping>\n    </attributeMappings>\n  </FeatureTypeMapping>\n  <FeatureTypeMapping>\n    <sourceDataStore>smartappschematest</sourceDataStore>\n    <sourceType>meteo_stations_maintainers</sourceType>\n    <targetElement>st:MeteoStationsMaintainersFeature</targetElement>\n    <attributeMappings>\n      <AttributeMapping>\n        <targetAttribute>FEATURE_LINK[1]</targetAttribute>\n        <sourceExpression>\n          <OCQL>station_id</OCQL>\n        </sourceExpression>\n      </AttributeMapping>\n      <AttributeMapping>\n        <targetAttribute>st:MeteoStationsMaintainersFeature</targetAttribute>\n        <idExpression>\n          <OCQL>strConcat('MeteoStationsMaintainersFeature.',id)</OCQL>\n        </idExpression>\n      </AttributeMapping>\n      <AttributeMapping>\n        <targetAttribute>st:id</targetAttribute>\n        <sourceExpression>\n          <OCQL>id</OCQL>\n        </sourceExpression>\n      </AttributeMapping>\n      <AttributeMapping>\n        <targetAttribute>meteoMaintainers</targetAttribute>\n        <sourceExpression>\n          <linkField>FEATURE_LINK[1]</linkField>\n          <linkElement>st:MeteoMaintainersFeature</linkElement>\n          <OCQL>maintainer_id</OCQL>\n        </sourceExpression>\n      </AttributeMapping>\n    </attributeMappings>\n  </FeatureTypeMapping>\n  <FeatureTypeMapping>\n    <sourceDataStore>smartappschematest</sourceDataStore>\n    <sourceType>meteo_maintainers</sourceType>\n    <targetElement>st:MeteoMaintainersFeature</targetElement>\n    <attributeMappings>\n      <AttributeMapping>\n        <targetAttribute>FEATURE_LINK[1]</targetAttribute>\n        <sourceExpression>\n          <OCQL>id</OCQL>\n        </sourceExpression>\n      </AttributeMapping>\n      <AttributeMapping>\n        <targetAttribute>st:MeteoMaintainersFeature</targetAttribute>\n        <idExpression>\n          <OCQL>strConcat('MeteoMaintainersFeature.',id)</OCQL>\n        </idExpression>\n      </AttributeMapping>\n      <AttributeMapping>\n        <targetAttribute>st:id</targetAttribute>\n        <sourceExpression>\n          <OCQL>id</OCQL>\n        </sourceExpression>\n      </AttributeMapping>\n      <AttributeMapping>\n        <targetAttribute>st:name</targetAttribute>\n        <sourceExpression>\n          <OCQL>name</OCQL>\n        </sourceExpression>\n      </AttributeMapping>\n      <AttributeMapping>\n        <targetAttribute>st:surname</targetAttribute>\n        <sourceExpression>\n          <OCQL>surname</OCQL>\n        </sourceExpression>\n      </AttributeMapping>\n      <AttributeMapping>\n        <targetAttribute>st:company</targetAttribute>\n        <sourceExpression>\n          <OCQL>company</OCQL>\n        </sourceExpression>\n      </AttributeMapping>\n    </attributeMappings>\n  </FeatureTypeMapping>\n</typeMappings>\n<sourceDataStores>\n  <DataStore>\n    <id>smartappschematest</id>\n    <parameters>\n      <Parameter>\n        <name>schema</name>\n        <value>smartappschematest</value>\n      </Parameter>\n      <Parameter>\n        <name>database</name>\n        <value>mock?sslmode=DISABLE&amp;binaryTransferEnable=bytea</value>\n      </Parameter>\n      <Parameter>\n        <name>port</name>\n        <value>5432</value>\n      </Parameter>\n      <Parameter>\n        <name>passwd</name>\n        <value>postgres</value>\n      </Parameter>\n      <Parameter>\n        <name>Expose primary keys</name>\n        <value>true</value>\n      </Parameter>\n      <Parameter>\n        <name>dbtype</name>\n        <value>postgis</value>\n      </Parameter>\n      <Parameter>\n        <name>host</name>\n        <value>localhost</value>\n      </Parameter>\n      <Parameter>\n        <name>user</name>\n        <value>postgres</value>\n      </Parameter>\n    </parameters>\n  </DataStore>\n</sourceDataStores>\n</ns3:AppSchemaDataAccess>\n
        "},{"location":"community/smart-data-loader/data-store/#customize-smart-data-loader-generated-mappings-and-xsd-definition","title":"Customize smart-data-loader generated mappings and xsd definition","text":"

        The Smart Data Loader does not allow direct modification of the mappings and XSD type definition. However it can be used as a starting point to generate configuration files that can be customized as required. This is the suggested workflow for such a use case:

        • Create a new smart-data-loader store, select the desired PostGIS store, and then the root entity and save it.
        • Go to the geoserver datadir and identify the Smart Data Loader store folder under the workspace that was selected while configuring it. An app-schema-mappings directory should be in that store folder.
        • Copy and paste the files contained in that directory to another directory and modify them as needed.
        • Delete the Smart Data Loader store, and create a new App-Schema store with a uri parameter pointing to the folder containing the modified files.
        "},{"location":"community/smart-data-loader/install/","title":"Installing the Smart Data Loader extension","text":"

        The Smart Data Loader extension is listed among the other extension downloads on the GeoServer download page.

        The installation process is similar to other GeoServer extensions:

        1. Download the Smart Data Loader nightly GeoServer community module from smart-data-loader.

          Verify that the version number in the filename corresponds to the version of GeoServer you are running (for example 2.24.2 above).

        2. Make sure you have downloaded and installed the app-schema extension.

        3. Extract the contents of the archive into the WEB-INF/lib directory in GeoServer. Make sure you do not create any sub-directories during the extraction process.

        4. Restart GeoServer.

        If installation was successful, you will see a new Smart Data Loader entry in the \"new Data Source\" menu.

        Smart Data Loader entry

        "},{"location":"community/solr/","title":"SOLR data store","text":"

        SOLR is a popular search platform based on Apache Lucene project. Its major features include powerful full-text search, hit highlighting, faceted search, near real-time indexing, dynamic clustering, database integration, rich document (e.g., Word, PDF) handling, and most importantly for the GeoServer integration, geospatial search.

        The latest versions of SOLR can host most basic types of geometries (points, lines and polygons) as WKT and index them with a spatial index.

        Note

        GeoServer does not come built-in with support for SOLR; it must be installed through this community module.

        The GeoServer SOLR extension has been tested with SOLR version 4.8, 4.9, and 4.10.

        The extension supports all WKT geometry types (all linear types, point, lines and polygons, SQL/MMcurves are not supported), plus \"bounding box\" (available starting SOLR 4.10). It does not support the solr.LatLonType type yet.

        The following pages shows how to use the SOLR data store.

        • SOLR layer configuration
        • Loading spatial data into SOLR
        • Optimize rendering of complex polygons
        "},{"location":"community/solr/configure/","title":"SOLR layer configuration","text":""},{"location":"community/solr/configure/#mapping-documents-to-layers","title":"Mapping documents to layers","text":"

        SOLR indexes almost free form documents, the SOLR instance has a collection of fields, and each document can contain any field, in any combination. On the other side, GeoServer organizes data in fixed structure feature types, and exposes data in separate layers. This leaves the question of how documents in the index should be organized into layers.

        By default the store exposes a single layer, normally named after the SOLR collection the store is connected to, by publishing it one can decide which fields to include, and eventually add a filter to select which attributes it will contain.

        This single layer can be published multiple times, giving each published layer a different name, set of selected attributes, and a different filter to select the documents contained in the layer.

        "},{"location":"community/solr/configure/#installing-the-solr-extension","title":"Installing the SOLR extension","text":"
        1. Download the SOLR extension from the nightly GeoServer community module builds.

          Warning

          Make sure to match the version of the extension to the version of the GeoServer instance.

        2. If GeoServer is running, stop it.

        3. Extract the contents of the archive into the WEB-INF/lib directory of the GeoServer installation.

        4. Restart GeoServer, the SOLR data store should show up as an option when going through the new store creation workflow.

        "},{"location":"community/solr/configure/#connecting-to-a-solr-server","title":"Connecting to a SOLR server","text":"

        Once the extension is properly installed SOLR will show up as an option when creating a new data store.

        SOLR in the list of vector data sources

        "},{"location":"community/solr/configure/#community_solr_configure_store","title":"Configuring a SOLR data store","text":"

        Configuring a SOLR data store

        solr_url Provide a link to the SOLR server that provides the documents

        Once the parameters are entered and confirmed, GeoServer will contact the SOLR server and fetch a list of layer names and fill the layer chooser page accordingly:

        List of layers available in the SOLR server

        "},{"location":"community/solr/configure/#configuring-a-new-solr-base-layer","title":"Configuring a new SOLR base layer","text":"

        Once the layer name is chosen, the usual layer configuration panel will appear, with a pop-up showing in a table the fields available:

        The layer field list configuration

        Is empty Read only fields, checked if the field has no values in the documents associated to this layer

        Use Used to select the fields that will make up this layer features

        Name Name of the field

        Type Type of the field, as derived from the SOLR schema. For geometry types, you have the option to provide a more specific data type

        SRID Native spatial reference ID of the geometries

        Default geometry Indicates if the geometry field is the default one. Useful if the documents contain more than one geometry field, as SLDs and spatial filters will hit the default geometry field unless otherwise specified

        Identifier Check if the field can be used as the feature identifier

        By default the list will contain only the fields that have at least one non null value in the documents associated to the layer, but it is possible to get the full list by un-checking the \"Hide field if empty\" check-box:

        Showing all fields available in SOLR

        Once the table is filled with the all the required parameters, press the \"Apply\" button to confirm and go back to the main layer configuration panel. Should the choice of fields be modified, you can click the \"Configure SOLR fields\" just below the \"Feature Type Details\" panel.

        Going back to the field list editor

        The rest of the layer configuration works as normal, once all the fields are provided you'll be able to save and use the layer in WMS and WFS.

        Warning

        In order to compute the bounding box GeoServer will have to fetch all the geometries making up the layer out of SOLR, this operation might take some time, you're advised to manually entered the native bounding box when configuring a layer out of a large document set

        "},{"location":"community/solr/configure/#custom-q-and-fq-parameters","title":"Custom q and fq parameters","text":"

        The SOLR store will translate most OGC filters, as specified in SLD, CQL Filter or OGC filter, down into the SOLR engine for native filtering, using the fq parameter. However, in some occasions you might need to specify manually either q or fq, to leverage some native SOLR filtering ability that cannot be expressed via OGC filters.

        This can be done by specifying those as viewparams, pretty much like in parametric sql views atop relational databases.

        For example, the following URL:

        http://localhost:8080/geoserver/nurc/wms?service=WMS&version=1.1.0&request=GetMap\n     &layers=nurc:active&styles=geo2&bbox=0.0,0.0,24.0,44.0&width=279&height=512\n     &srs=EPSG:4326&format=application/openlayers\n     &viewparams=fq:security_ss:WEP\n

        Will send down to SOLR a query looking like:

        omitHeader=true&fl=geo,id&q=*:*&rows=2147483647&sort=id asc\n&fq=status_s:active AND geo:\"Intersects(POLYGON ((-0.125 -0.5333333333333333, -0.125 44.53333333333333, \n24.125 44.53333333333333, 24.125 -0.5333333333333333, -0.125 -0.5333333333333333)))\"\n&fq=security_ss:WEP&cursorMark=*\n

        You can notice that:

        • Only the columns needed for the display (in this case, a single geometry) are retrieved
        • The bbox and layer identification filters are specified in the first fq
        • The custom fq is passed as a second fq parameter (SOLR will treat it as being and-ed with the previous one)
        "},{"location":"community/solr/load/","title":"Loading spatial data into SOLR","text":"

        This section provides a simple example on how to convert and load a shapefile into a SOLR instance. For more advanced needs and details about spatial support in SOLR consult the SOLR documentation, making sure to read the one associated to the version at hand (spatial support is still rapidly evolving).

        The current example has been developed and tested using GDAL 1.11 and SOLR 4.8, different versions of the tools and server might require a different syntax for upload.

        The SOLR instance is supposed to have the following definitions in its schema:

        <field name=\"geo\" type=\"location_rpt\" indexed=\"true\" stored=\"true\" multiValued=\"true\" />  \n<dynamicField name=\"*_i\"  type=\"int\"    indexed=\"true\"  stored=\"true\"/>\n<dynamicField name=\"*_s\"  type=\"string\"  indexed=\"true\"  stored=\"true\" />\n

        The above defines \"geo\" as explicit fields, leaving the other types to dynamic field interpretation.

        The SpatialRecursivePrefixTreeFieldType accepts geometries as WKT, so as a preparation for the import we are going to turn a shapefile into a CSV file with WKT syntax for the geometry. Let's also remember that SOLR needs a unique id field for the records, and that the coordinates are supposed to be in WGS84. The shapefile in question is instead in UTM, has a linestring geometry, and some fields, cat,id and label.

        The following command translates the shapefile in CSV (the command should be typed in a single line, it has been split over multiple lines for ease of reading):

        ogr2ogr  -f CSV \n         -sql 'select FID as id, cat as cat_i, label as label_s, \n              \"roads\" as layer FROM roads' \n         -lco geometry=AS_WKT -s_srs \"EPSG:26713\" -t_srs \"EPSG:4326\"  \n         /tmp/roads.csv roads.shp\n

        Some observations:

        • The SQL is used mostly to include the special FID field into the results (a unique field is required)
        • The reprojection is performed to ensure the output geometries are in WGS84
        • The layer_s dynamic field is added to

        This will generate a CSV file looking as follows:

        WKT,id,cat_i,label_s,layer\n\"LINESTRING (-103.763291353072518 44.375039982911382,-103.763393874038698 44.375282535746727,-103.764152625689903 44.376816068582023,-103.763893508430911 44.377653708326527,-103.76287152579593 44.378473197876396,-103.762075892308829 44.379009292692757,-103.76203441159079 44.379195585236509,-103.762124217456204 44.379295262047272,-103.762168141872152 44.379399997909999,-103.762326134985983 44.379527769244149,-103.763328403265064 44.380245486928708,-103.764011871363465 44.381295133519728,-103.76411460103661 44.381526706124056,-103.764953940327757 44.382396618315049,-103.765097289111338 44.382919576408355,-103.765147974157941 44.383073790503197,-103.76593766187851 44.384162856249255,-103.765899236602976 44.384607239970421,-103.765854384388703 44.384597320206453)\",0,5,unimproved road,roads\n\"LINESTRING (-103.762930948900078 44.385847721442218,-103.763012156628747 44.386002223293282,-103.763510654805799 44.386297912655408,-103.763869052966967 44.386746022746649,-103.763971116268394 44.387444295314552,-103.764244098825387 44.387545690358827,-103.764264649212294 44.387677659170357,-103.764160551326043 44.387951214930865,-103.764540576800869 44.388042632912118,-103.764851624437995 44.388149874425885,-103.764841258550391 44.388303515682807,-103.76484332449354 44.388616502755184,-103.765188923261391 44.388927221995502,-103.765110961905023 44.389448103450221,-103.765245311197177 44.389619574129583,-103.765545516097987 44.389907903843323,-103.765765403056434 44.390420596862072,-103.766285436779711 44.391655378673697,-103.766354640463163 44.39205684519964,-103.76638734105434 44.392364628456725,-103.766410556756725 44.392776645318136,-103.765934443919321 44.393365174368313,-103.766220869020188 44.393571013181166,-103.766661604125247 44.393684955690581,-103.767294323528063 44.393734806102117,-103.767623238680557 44.394127721518785,-103.769273719703676 44.394900867042516,-103.769609703946827 44.395326786724503,-103.769732072038536 44.395745219647871,-103.769609607364416 44.396194309461826,-103.769310708537489 44.396691166475954,-103.768865902286791 44.397236074649896)\",1,5,unimproved road,roads\n

        At this point the CSV can be imported into SOLR using CURL:

        curl \"http://solr.geo-solutions.it/solr/collection1/update/csv?commit=true&separator=%2C&fieldnames=geo,id,cat_i,label_s,layer_s&header=true\" \n     -H 'Content-type:text/csv; charset=utf-8' --data-binary @/tmp/roads.csv\n

        Some observations:

        • The files gets uploaded as a text/csv file, older versions might require a text/plain mime type
        • The fieldnames overrides the CSV header and allows us to specify the field name as expected by SOLR

        At this point it's possible to configure a layer showing only the roads in the GeoServer UI:

        Setting up the roads layer

        After setting the bounding box and the proper style, the layer preview will show the roads stored in SOLR:

        Preview roads from SOLR layer

        "},{"location":"community/solr/optimize/","title":"Optimize rendering of complex polygons","text":"

        Rendering large maps with complex polygons, to show the overall distribution of the data, can take a significant toll, especially if GeoServer cannot connect to the SOLR server via a high speed network.

        A common approach to handle this issue is to add a second geometry to the SOLR documents, representing the centroid of the polygon, and using that one to render the features when fairly zoomed out.

        Once the SOLR documents have been updated with a centroid column, and it has been populated, the column can be added as a secondary geometry. Make sure to keep the polygonal geometry as the default one:

        ... (other fields omitted)

        Configuring a layer with multiple geometries

        With this setup the polygonal geometry will still be used for all spatial filters, and for rendering, unless the style otherwise specifical demands for the centroid.

        Then, a style with scale dependencies can be setup in order to fetch only then centroids when fairly zoomed out, like in the following CSS example: :

        [@scale > 50000] {\n  geometry: [centroid];\n  mark: symbol(square);\n}\n:mark {\n  fill: red;\n  size: 3;\n}\u200b\n[@scale <= 50000] {\n  fill: red;\n  stroke: black;\n}\n

        Using this style the spatial field will still be used to resolve the BBOX filter implicit in the WMS requests, but only the much smaller centroid one will be transferred to GeoServer for rendering.

        "},{"location":"community/spatialjson/","title":"SpatialJSON WFS Output Format Extension","text":"

        This module adds the SpatialJSON WFS output format. The SpatialJSON format is a more compact and memory-friendly variant of GeoServer's GeoJSON format. It aims to save space by applying several optimizations to traditional GeoJSON format for simple feature results. Most of these optimizations work by removing redundand information from the JSON-encoded features.

        A service exception is thrown if the result contains complex features as the SpatialJSON format does not handle those.

        Note

        The SpatialJSON format is not compatible with GeoJSON. A SpatialJSON enabled reader is required to decode features transferred in SpatialJSON format.

        This module adds two additional WFS output formats for requesting simple features in SpatialJSON format:

        • application/json; subtype=json/spatial for requesting SpatialJSON
        • text/javascript; subtype=json/spatial for requesting SpatialJSON as a JSONP request

        Warning

        At the time of writing, this format is still work in progress and changes may be applied in the future.

        • Installation
        • Development Status
        • Opt. 1: Removing Redundant Schema Information
        • Opt. 2: Removing Redundant Attribute Values
        "},{"location":"community/spatialjson/attributes/","title":"Opt. 2: Removing Redundant Attribute Values","text":""},{"location":"community/spatialjson/attributes/#shared-string-table","title":"Shared String Table","text":"

        A SpatialJSON response may contain a Shared String Table, which may contain strings that are referenced by some features' properties. Only properties expressed as JSON strings can be stored in a shared string table (at current, temporal values, like Dates and Timestamps, which are expressed as strings as well, are not stored in a shared string table).

        If present, a new \"sharedStrings\" property is available in the top-level \"FeatureCollection\" object:

        {\n  \"type\": \"FeatureCollection\",\n\n  \"$note\": \" /* remaining properties go here */ \",\n\n  \"schemaInformation\": {\n    \"propertyNames\": [\"str_1\", \"num_2\", \"str_3\", \"str_4\", \"bool_5\"],\n    \"geometryName\": \"the_geom\"\n  },\n  \"sharedStrings\": {\n    \"indexes\": [0, 2, 3],\n    \"table\": [\"Lorem ipsum dolor sit amet,\",\n              \"consetetur sadipscing elitr,\",\n              \"sed diam nonumy eirmod tempor invidunt ut labore\",\n              \"et dolore magna aliquyam erat,\",\n              \"sed diam voluptua.\"]\n  }\n}\n

        It contains these two properties:

        • \"table\" - Contains the shared strings. These are referenced by their index in the array.
        • \"indexes\" - Contains the zero-based indexes of feature properties that may be stored in this shared string table.

        In SpatialJSON, a feature's properties are basically stored in an array only (in contrast to GeoJSON which stores properties in an object). The \"indexes\" array contains the indexes in these properties arrays that may have their values stored in the shared string table. In a feature's property array, such a value may actually be either null, a regular JSON string or a JSON number (integral number). In the latter case, the property's value is actually stored in the shared string table, the value being used as the index into the shared string table.

        These examples show how some feature's properties arrays are evaluated using the above string table:

        /* showing properties array of feature #1 */\nproperties: [\"foo\", 23, 2, null, true]\n\n/* gets evaluated to */\nproperties: {\n  \"str_1\": \"foo\",\n  \"num_2\": 23,\n  \"str_3\": \"sed diam nonumy eirmod tempor invidunt ut labore\",\n  \"str_4\": null,\n  \"bool_5\": true\n}\n\n/* showing properties array of feature #2 */\nproperties: [1, 32, \"K\", 3, false]\n\n/* gets evaluated to */\nproperties: {\n  \"str_1\": \"consetetur sadipscing elitr\",\n  \"num_2\": 32,\n  \"str_3\": \"K\",\n  \"str_4\": \"et dolore magna aliquyam erat\",\n  \"bool_5\": false\n}\n

        As the examples show, there is no guarantee that all strings of a property whose index is part of the sharedStrings.indexes array are actually stored in the shared string table.

        "},{"location":"community/spatialjson/attributes/#spatialjson-writer-implementation","title":"SpatialJSON Writer Implementation","text":"

        It is completely up to the SpatialJSON writer to decide, which strings to add to the shared string table. Several strategies can be used. However, the current implementation in this module makes no attempt to create an optimal shared string table. In order to be fast, strings are added as they come when features are serialized. Building an optimal table would likely require iterating features several times, calculating frequencies of strings, etc.

        Nevertheless, this module's SpatialJSON writer has some simple rules for building the shared string table. Even for worst case scenarios, these try (at least) not to use (much) more bytes than needed for the same result without using a shared string table. (In theory, there are cases in which the shared string table adds some extra bytes to the result.) However, for most real world datasets, this strategy could save a moderate to significant number of bytes.

        These are the rules that prevent a string from being added to the shared string table:

        • The string's UTF-8 encoded byte length is less than a hard-coded minimum (currently 2, may be configurable in the future)
        • The shared sting table is full, that is, it contains 2,147,483,647 entries (not really expected)
        • The string's UTF-8 encoded byte length (including quotes) is less than the number of digits of it's designated index

        Obviously, most savings can be achieved if a dataset contains only a few different large strings. That may be the case for attributes, that contain values of an enumeration, for example. The more often a certain string is used in the dataset, the more space can be saved by using a shared string table. In contrast, if every string in the set of encoded features is used only once (e. g. attributes that contain random or UUID-like strings), no savings will be achieved (in fact, using a shared string table in that case will produce even slightly bigger results).

        "},{"location":"community/spatialjson/attributes/#shared-strings-per-request-customization","title":"Shared Strings per Request Customization","text":"

        By default, the current implementation will add all JSON string encoded properties to the shared string table. (Except temporal values, like Dates and Timestamps, which in JSON technically are strings as well. However, we do not expect much redundancy in temporal values.) With the format_options vendor parameter it is possible to specify which properties can store values in the shared string table or to completely skip the creation of such a table.

        The supported format option is:

        • sharedstrings (default is *) - Specify false or leave empty (e. g. format_options=sharedstrings:) to skip shared string table generation, or true or * to create a table including all JSON string encoded properties (that is the default behavior). Alternatively, a comma-separated list of property names could specify the set of properties that may store their values in the shared string table.

        When a comma-separated list of property names is specified for the sharedstrings format option, these additional rules apply:

        • Commas in property names (really?) may be escaped with a backslash character ``.

        • The prefix re: may be prepended to the list in order to designate each item a Java Regular Expression: (e. g. format_options=sharedstrings:re:adm_.*,\\d\\d_[a-z]+$). See Java Pattern class.

          Specifying an invalid regular expression results in a Service Exception.

        • The prefix glob: may be prepended to the list in order to designate each item a glob pattern: (e. g. format_options=sharedstrings:glob:adm_*,[0-9][0-9]_*name). See glob patterns.

          Specifying an invalid glob pattern results in a Service Exception.

        Although the SpatialJSON Shared String Table feature works fine and typically saves a moderate number of bytes for arbitrary datasets in its default configuration, that is without specifying the sharedstrings format option, this parameter provides a solid handle for advanced fine tuning of the string table's creation process.

        "},{"location":"community/spatialjson/development/","title":"Development Status","text":"

        The SpatialJSON format is still a playground for implementing several optimizations to transfer even huge amounts of spatial data from the server to the client efficiently:

        1. Opt. 1: Removing redundant schema information, see topic
        2. Opt. 2: Removing redundant attribute values (e. g. shared string table), see topic
        3. Opt. 3: Handling sparse rows (most values are NULL) more efficiently
        4. Opt. 4: Reducing space required for geometries (e. g. differential coordinates)

        Bold items have already been implemented.

        The shown optimizations are ordered from simple to implement to hard to implement (not really hard, however). That's also the intended order of implementation. Although some optimizations are optional, all optimizations could be in effect at the same time. Then, each optimization contributes his part to lower the space required for encoding a certain set of features.

        In some cases, however, it may be useful to specify which optimizations shall be used for a request. Several techniques are available to give a client the ability to specify the set of SpatialJSON optimizations it is able or willing to use (e. g. parameter format_options, additional outputFormat parameters). It's still not clear how this will be implemented and how fine grained that will be.

        "},{"location":"community/spatialjson/installation/","title":"Installation","text":""},{"location":"community/spatialjson/installation/#manual-installation","title":"Manual Installation","text":"

        To download and install the required extensions by hand:

        1. Download the geoserver- 2.24.2-spatialjson-plugin.zip from:

          • Community Builds (GeoServer WebSite)

          It is important to download the version that matches the GeoServer you are running.

        2. Stop the GeoServer application.

        3. Navigate into the webapps/geoserver/WEB-INF/lib folder.

          These files make up the running GeoServer application.

        4. Unzip the contents of the zip file into the lib folder.

        5. Restart the Application Server.

        After restarting the Application Server the SpatialJSON WFS output format is available and ready to use.

        "},{"location":"community/spatialjson/schema/","title":"Opt. 1: Removing Redundant Schema Information","text":"

        In traditional GeoJSON, every feature in a (simple feature) feature collection has its own schema information. That is, every feature contains all its (not necessarily short) attribute names. Except the geometry name, these names are used as the keys in the \"properties\" map:

        {\n  \"type\": \"FeatureCollection\",\n  \"features\": [\n    {\n      \"type\": \"Feature\",\n      \"id\": \"areas.1\",\n      \"geometry\": {\n        \"type\": \"Point\",\n        \"coordinates\": [590529, 4914625]\n      },\n      \"geometry_name\": \"the_geom\",\n      \"properties\": {\n        \"area_no\": 12,\n        \"area_name\": \"Mainland\",\n        \"area_description\": \"grassland\",\n        \"area_cost_center\": \"0815\"\n      }\n    },\n    {\n      \"type\": \"Feature\",\n      \"id\": \"areas.2\",\n      \"geometry\": {\n        \"type\": \"Point\",\n        \"coordinates\": [590215, 4913987]\n      },\n      \"geometry_name\": \"the_geom\",\n      \"properties\": {\n        \"area_no\": 17,\n        \"area_name\": \"South region\",\n        \"area_description\" : \"meadow, pasture\",\n        \"area_cost_center\": \"0812\"\n      }\n    }\n  ],\n  \"totalFeatures\": 2,\n  \"numberMatched\": 2,\n  \"numberReturned\": 2,\n  \"timeStamp\": \"2022-10-17T08:12:45.248Z\",\n  \"crs\": {\n    \"type\": \"name\",\n    \"properties\": {\n      \"name\": \"urn:ogc:def:crs:EPSG::26713\"\n    }\n  }\n}\n

        Since all features have the same schema information, SpatialJSON does not write attribute names for every feature. Instead, a single \"schemaInformation\" property is added to the end of the top-level \"FeatureCollection\" object:

        {\n  \"type\": \"FeatureCollection\",\n  \"features\": [\n    {\n      \"type\": \"Feature\",\n      \"id\": \"areas.1\",\n      \"geometry\": {\n        \"type\": \"Point\",\n        \"coordinates\": [590529, 4914625]\n      },\n      \"properties\": [12, \"Mainland\", \"grassland\", \"0815\"]\n    },\n    {\n      \"type\": \"Feature\",\n      \"id\": \"areas.2\",\n      \"geometry\": {\n        \"type\": \"Point\",\n        \"coordinates\": [590215, 4913987]\n      },\n      \"properties\": [17, \"South region\", \"meadow, pasture\", \"0812\"]\n    }\n  ],\n  \"totalFeatures\": 2,\n  \"numberMatched\": 2,\n  \"numberReturned\": 2,\n  \"timeStamp\": \"2022-10-17T08:14:36.521Z\",\n  \"crs\": {\n    \"type\": \"name\",\n    \"properties\": {\n      \"name\": \"urn:ogc:def:crs:EPSG::26713\"\n    }\n  },\n  \"schemaInformation\": {\n    \"propertyNames\": [\"area_no\", \"area_name\", \"area_description\", \"area_cost_center\"],\n    \"geometryName\": \"the_geom\"\n  }\n}\n

        With SpatialJSON, each feature's \"properties\" map becomes an ordered list (array) whose index corresponds to the \"propertyNames\" array that holds the attribute names in the new \"schemaInformation\" object. Additionally, the repeated property \"geometry_name\" is replaced by a single property named \"geometryName\" in the new schema information object.

        "},{"location":"community/spatialjson/schema/#evaluation","title":"Evaluation","text":"

        In the above example, without whitespaces and line breaks, savings in space are only about 5%. With much more features savings could reach almost 27% (the ratio of the sizes of a GeoJSON and a SpatialJSON feature object), that is, the size of the SpatialJSON response is only 73% of the size of a traditional GeoJSON response. More savings are possible with more attributes per feature. Savings basically depend on the ratio between schema information size and data size. In tests requesting several thousands of simple features with 200+ columns/attributes savings up to 70% have been achieved.

        These savings drop to between \\~50% and \\~3% when a compressing content encoding method (like gzip, deflate or brotli) is used on the wire. However, it's not all about transfer size. The smaller the uncompressed JSON response, the lesser characters the client has to parse. Smaller uncompressed responses are also much more memory-friendly on both the server and the client side.

        "},{"location":"community/stac-datastore/","title":"STAC Datastore extension","text":"

        This plugin adds a vector data store that can connect to a STAC API, delivering collections as feeare types, and items as features.

        Warning

        The current version requires a STAC API RC1 with the \"search\" conformance class. It will works best if the API supports field selection, sorting and CQL2 filtering, but can fall back on in-memory operations if they are not natively supported.

        • Installing the STAC data store
        • STAC data store
        "},{"location":"community/stac-datastore/data-store/","title":"STAC data store","text":""},{"location":"community/stac-datastore/data-store/#configuring-a-store","title":"Configuring a Store","text":"

        In addition to the parameters common to each DataStore configuration such as workspace, name and description, and the common HTTP connector parameters, such as connection pooling, using GZIP, user name and password, the page shows the following connection parameters in the dedicated section:

        • landingPage: this should point to the landing page of the target STAC API
        • fetchSize: how many items the store will try to fetch per page. The actual number is in control of the server, the store will simply try to suggest this value.
        • featureTypeItems: how many items to read in order to guess the structure of the feature type (GeoServer in general needs a predictable structure)
        • hardLimit: maximum amount of items to fetch from the STAC store, in any request (it's a good idea to pose a limit, as many STAC APIs host millions of items, and the data transfer is not particularly efficient due to the large size of items, and the paged transfer)

        STAC datastore configuration

        STAC items are multi-temporal, so it's advisable to configure the time dimension when setting up the layer, using the datetime attribute. This will allow time navigation and reduce the number of items returned to a more manageable subset:

        Setting up time for the layers

        "},{"location":"community/stac-datastore/data-store/#mosaicking-images-from-a-stac-store","title":"Mosaicking images from a STAC store","text":"

        STAC items may point to actual image files among its \"assets\" data structure. Assets are a top level object, not part of the Feature properties, that the store makes available to the image mosaic for image mosaicking purposes. The images in question must be Cloud Optimized GeoTIFFs and the COG plugin must be installed in GeoServer.

        The STAC store can then be used as the index of an image mosaic, setting up two configuration files:

        • A datastore.properties pointing at the configured STAC server.
        • A indexer.properties indicating the collection to use, setup for the COG usage, and the location of the asset providing the images.
        "},{"location":"community/stac-datastore/data-store/#simple-mosaic-setup","title":"Simple mosaic setup","text":"

        Here is an example datastore.properties, pointing at an existing STAC store already configured in GeoServer:

        StoreName=stac\\:dlr-eoc\n

        And here is an indexer.properties:

        MosaicCRS=EPSG\\:4326\nTimeAttribute=datetime\nAbsolutePath=true\nName=WSF_2019\nCog=true\nHeterogeneous=true\nHeterogeneousCRS=false\nTypeName=WSF_2019\nUseExistingSchema=true\nLocationAttribute=assets/wsf2019/href\nMaxInitTiles=10\n

        Notes about the file contents:

        • The time dimension is set up and linked to the datetime attribute
        • The mosaic is setup to allow heterogeneous resolution images, but in this particular case, assumes that all images are in the same CRS.
        • The TypeName property points to the target STAC collection.
        • The LocationAttribute uses a JSONPointer to the desired asset URL.
        • MaxInitTiles is configured so that the image mosaic does not try to scan the entire index to figure out a common image structure, only the first 10 items returned by the STAC API will be used for auto-configuration.
        "},{"location":"community/stac-datastore/data-store/#multi-band-mosaic-setup","title":"Multi-band mosaic setup","text":"

        It's also possible to mosaic images whose bands are offered as separate images and in different coordinate reference systems, with a more complex setup. Here is an example for a false color Sentinel 2 mosaic, using a coverage view to merge the images back into a single RGB composite.

        The datastore.properties configures two new properties, enabling query caching (as the coverage view machinery will load each band in turn, repeating the same queries):

        StoreName=stac\\:dlr-loose\nQueryCacheMaxAge=10000\nQueryCacheMaxFeatures=1000\n

        The indexer must instead be provided in XML format, to configure multiple coverage and their attributes:

        <?xml version=\"1.0\" encoding=\"UTF-8\" standalone=\"yes\"?>\n<Indexer>\n  <domains>\n     <domain name=\"time\">\n       <attributes><attribute>datetime</attribute></attributes>\n     </domain>\n     <domain name=\"crs\">\n       <attributes><attribute>proj:epsg</attribute></attributes>\n     </domain>\n  </domains>\n  <coverages>\n    <coverage>\n      <name>B04</name>\n      <domains>\n        <domain ref=\"time\" />\n        <domain ref=\"crs\" />\n      </domains>\n      <parameters>\n          <parameter name=\"LocationAttribute\" value=\"assets/B04/href\" />\n      </parameters>\n    </coverage>\n    <coverage>\n      <name>B03</name>\n      <domains>\n        <domain ref=\"time\" />\n        <domain ref=\"crs\" />\n      </domains>\n      <parameters>\n          <parameter name=\"LocationAttribute\" value=\"assets/B03/href\" />\n      </parameters>\n    </coverage>\n    <coverage>\n      <name>B02</name>\n      <domains>\n        <domain ref=\"time\" />\n        <domain ref=\"crs\" />\n      </domains>\n      <parameters>\n          <parameter name=\"LocationAttribute\" value=\"assets/B02/href\" />\n      </parameters>\n    </coverage>\n  </coverages>\n  <parameters>\n      <parameter name=\"MosaicCRS\" value=\"EPSG:4326\" />\n      <parameter name=\"AbsolutePath\" value=\"true\" />\n      <parameter name=\"Cog\" value=\"true\" />\n      <parameter name=\"Heterogeneous\" value=\"true\" />\n      <parameter name=\"HeterogeneousCRS\" value=\"true\" />\n      <parameter name=\"UseExistingSchema\" value=\"true\" />\n      <parameter name=\"TypeName\" value=\"S2_L2A_MSI_COG\" />\n      <parameter name=\"MaxInitTiles\" value=\"10\"/>\n  </parameters>\n</Indexer>\n

        Some notes about the configuration:

        • The time and crs attributes are declared as dimensions.
        • Each coverage has a different LocationAttribute specification.
        • The mosaic heterogeneous CRS support is enabled.

        Once the mosaic is configured in GeoServer, create a new coverage view setting up the bands according to the desired order:

        Creating a coverage view from a multi-band mosaic

        Also remember to configure the time dimension for this layer, for the same reasons explained in the vector data section above.

        "},{"location":"community/stac-datastore/install/","title":"Installing the STAC data store","text":"

        The STAC store community module is listed among the other community modules on the GeoServer download page.

        The installation process is similar to other GeoServer extensions:

        1. Download the STAC store nightly GeoServer community module from stac-datastore.

          Verify that the version number in the filename corresponds to the version of GeoServer you are running (for example 2.24.2 above).

        2. Extract the contents of the archive into the WEB-INF/lib directory in GeoServer. Make sure you do not create any sub-directories during the extraction process.

        3. Restart GeoServer.

        If installation was successful, you will see a new STAC datastore entry in the \"new Data Source\" menu.

        STAC datastore entry

        "},{"location":"community/taskmanager/","title":"Geoserver Task Manager","text":"

        The GeoServer Task Manager is a tool that allows scheduled tasks and batches to run inside a GeoServer instance. The initial purpose of the task manager was to synchronize data and metadata between different geoserver instances and their data sources, as to automise and assist a particular workflow within an organisation that includes pre-tested publications and frequent updates. However, the task manager offers an extensive and flexible API that makes it possible to write any kind of extensions and customisations, allowing other purposes as well.

        • Basic Concepts
        • TaskManager User Guide
        • Developer's Guide
        "},{"location":"community/taskmanager/basic/","title":"Basic Concepts","text":"

        The two main kinds of objects of the Task Manager are configurations and batches. Task Manager also allows the creation of Templates for configurations.

        "},{"location":"community/taskmanager/basic/#configurations","title":"Configurations","text":"

        The configuration is the central object in the Task Manager. A configuration is typically linked to a data object, such as a GeoServer layer, and serves as an entry point to the tasks and batches related to this data object.

        A configuration has a unique name, a description and a workspace. It contains three groups of objects:

        • Attributes: The attributes contain information about this configuration that can be shared between the different tasks of this configuration. An attribute has a name and a value. Each attribute is associated with at least one task parameter (see below). Attributes inherit their validation properties from their associated parameters, such as its accepted values and whether it is required.
        • Tasks: Each task configures an operation that can be executed on this configuration. Each task has a name that is unique within the configuration, a type and a list of parameters with each a name and a value. The full name of a task is donated as configuration-name/task-name (which serves as a unique identifier for the task). The task's type is chosen from a list of available task types which define different kinds of operations (for example: copy a database table, publish a layer, ..) and expects a list of parameters that each has a name and a type. A parameter may or may not be required. The parameter type defines the accepted values of the parameter. Parameter types are dependent types when the list of accepted values depends on the value of another parameter (for example: tables inside a database). A parameter value is either a literal or a reference to an attribute of the form ${attribute-name}.
        • Batches.
        "},{"location":"community/taskmanager/basic/#batches","title":"Batches","text":"

        A batch is made of an ordered sequence of tasks that can either be run on demand or be scheduled to run repeatedly at specific times. There are two kinds of batches:

        • Configuration batches: these are batches that belong to a configuration. All of the tasks inside this batch are tasks that belong to that same configuration.
        • Independent batches: these are batches that do not belong to a configuration. They may contains tasks from any existing configuration.

        A batch has a name, a description and a workspace. The name of a batch must be unique amongst its configuration or amongst all independent batches. The full name of a batch is denoted as [configuration-name:]batch-name which serves as a unique identifier for the batch.

        Configuration batches that have a name starting with a @, are hidden from the general batch overview and are only accessible from their configuration. Hidden batch names may be reserved for special functions. At this point, there is only one such case (see Initializing templates).

        A batch can be run manually if the following conditions are met:

        • the list of tasks is non-empty;
        • the operating user has the security rights to do so (see Security).

        A batch will be run automatically on its scheduled time if the following conditions are met:

        • the list of tasks is non-empty;
        • the batch is enabled;
        • the batch has a frequency configured other than NEVER;
        • the batch is independent or its configuration has been completed, i.e. validated without errors (in some cases a configuration may be saved before it is validated, see Initializing templates).
        "},{"location":"community/taskmanager/basic/#running-a-batch","title":"Running a batch","text":"

        The batch is executed in two phases:

        • RUN phase: tasks are executed in the defined order. If an error occurs or the run is manually intermitted, cease execution and go to ROLLBACK phase. If all tasks finish successfully, go to COMMIT phase.
        • COMMIT/ROLLBACK phase: tasks are committed or rollbacked in the opposite order.

        Consider a batch with three tasks

        B = T1 -> T2 -> T3.

        A normal run would then be

        run T1 -> run T2 -> run T3 -> commit T3 -> commit T2 -> commit T1.

        However, if T2 fails, the run would be

        run T1 -> run T2 (failure) -> rollback T1.

        Most tasks support COMMIT/ROLLBACK by creating temporary objects that only become definite objects after a COMMIT. The ROLLBACK phase then simply cleans up those temporary objects. However, some particular task types may not support the COMMIT/ROLLBACK mechanism (in which case running them is definite).

        The commit phase happens in opposite order because dependencies in the old version of the data often requires this. A concrete example may clear things up. Imagine that T1 copies a database table R from one database to another, while T2 creates a view V based on that table, so V depends on R. If the table and view already exist in older versions (R_old and V_old), they must not be removed until the COMMIT phase, so that their original state remains in the case of a ROLLBACK. During the COMMIT phase, R_old and V_old are removed, but it is not possible to remove R_old until V_old is removed. Therefore it is necessary to commit T2 before T1.

        The COMMIT phase typically replaces old objects with the new objects that have a temporary name. Since tasks often create objects that depend on objects of the previous tasks, these objects contain references to temporary names. Which means that when the temporary object is committed and becomes the real object, references in depending objects must also be updated. For this purpose, a tasks that uses a temporary object from a previous task registers a dependency, which is essentially an update added to the commit phase of that previous task.

        If T3 has a dependency on task T1 that we call D1, the following happens:

        run T1 -> run T2 -> run T3, register D1 -> commit T3 -> commit T2 -> commit T1, update D1.

        Let's make it clearer again using an example. During the RUN phase T1 creates table R1_temp and T2 creates V1_temp that depends on R1_temp, this dependency will be registered. During the commit phase, T2 will replace V1 by V1_temp. Then, T1 will replace T1 by T1_temp. However, V1 may still reference T1_temp which no longer exists. Therefore, T1 will use the registered dependency to update V1 to refer to T1 instead of T1_temp.

        Within a batch run, each task that has yet started has a status. These are the possible statuses:

        • RUNNING: the task is currently running.
        • WAITING_TO_COMMIT: the task has finished running, but is waiting to commit (or rollback) while other tasks are running or committing (or rolling back).
        • COMMITTING: the task is currently committing.
        • ROLLING_BACK: the task is currently rolling back.
        • COMMITTED: the task was successfully committed.
        • ROLLED_BACK: the task was successfully rolled back.
        • NOT_COMMITTED: the task was supposed to commit but failed during the commit phase.
        • NOT_ROLLED_BACK: the task was supposed to roll back but failed during roll back phase.

        A task is consired finished if its status is not RUNNING, WAITING_TO_COMMIT, ROLLING_BACK or COMMITTING. A batch run does not have its own status, but it takes on the status of the last task that has started but is not COMMITTED or ROLLED_BACK. A batch run is considered finished if its status is not RUNNING, WAITING_TO_COMMIT or COMMITTING.

        There is concurrency protection both on the level of tasks and batches. A single batch can never run simultaneously in multiple runs (the second run will wait for the first one to finish). A single task can never run simultaneously in multiple runs, even if part of a different batch. A single task can also not commit simultaneously in multiple runs.

        "},{"location":"community/taskmanager/basic/#templates","title":"Templates","text":"

        Templates are in every way identical to configurations, with the exception of:

        • they are never validated when saved (their attributes need not be filled in) and
        • their tasks and batches can never be executed.

        A template is used as a blueprint for the creation of configurations that are very similar to each other. Typically, the tasks are all the same but the attribute values are different. However, a template may also have attribute values filled in that serve as defaults.

        Once a configuration is created from a template, it is independent from that template (changes to the template do not affect it). The configuration can then be modified like any other configuration, including the removal, addition and manipulation of tasks.

        "},{"location":"community/taskmanager/basic/#initializing-templates","title":"Initializing templates","text":"

        An initializing template is any template that has a batch named @Initialize (case sensitive), which configures special behaviour. The purpose of this batch is to execute some tasks that must have been done at least once until some other tasks can actually be configured. For example, you may want to create a vector layer based on that table copied from a source database, then synchronise this layer to a target geoserver. The task that synchronizes a layer to the external geoserver will expect an existing configured layer, which you cannot create until you have copied the table first. The @Initialize batch would in this case copy the table from the source and create a layer in the local geoserver.

        When creating a configuration from this template, configuration happens in two phases

        • (1) Initially, only attributes related to tasks in the @Initialize batch must be configured. When the configuration is saved, the @Initialize batch is automatically executed.

        • (2) Now, all other attributes and tasks must be configured and the configuration must be saved again.

        This is the only case that a configuration can be saved before all the required attributes are filled in. Mind that batches will not be scheduled or visible in the general overview until the batch has been saved again (and the attributes have thus been validated).

        "},{"location":"community/taskmanager/developer/","title":"Developer's Guide","text":"
        • Task Types - write your own operations
        • Actions - extend the GUI for your tasks
        • Reporting - choose the content and destination of your batch reports
        "},{"location":"community/taskmanager/developer/#task-types","title":"Task Types","text":"

        Task manager can be extended with custom made task types. Make your own implementation of the interface TaskType and let it be a spring bean. The name provided via the Named interface is used as a reference.

        /**\n * A Task Type.\n * \n */\npublic interface TaskType extends Named {\n\n    /**\n     * Return parameter info for this task type.\n     * It is recommended to use a LinkedHashMap and add the parameters in a intuitive order.\n     * This order will be preserved to present parameters to the user. \n     *\n     * @return the parameter info\n     */\n    Map<String, ParameterInfo> getParameterInfo();\n\n    /**\n     * Run a task, based on these parameter values.\n     * @param ctx task context\n     * @return the task result\n     */\n    TaskResult run(TaskContext ctx) throws TaskException;\n\n    /**\n     * Do a clean-up for this task (for example, if this task publishes something, remove it).\n     * @param ctx task context\n     * @throws TaskException \n     */\n    void cleanup(TaskContext ctx) throws TaskException;\n\n    /**\n     * task type can specify whether it supports clean-up or not\n     * \n     * @return true if clean-up is supported\n     */\n    default boolean supportsCleanup() {\n        return true;\n    }\n\n}\n

        A ParameterInfo object contains a name, a type, whether they are required, and which other parameters they depend on (for example, a database table depends on a database).

        The Task context looks as follows:

        /**\n * Task Context used during batch run or task clean-up.\n * \n */\npublic interface TaskContext {\n\n    /**\n     * @return the task\n     */\n    Task getTask();\n\n    /**     \n     * @return the batch context, null if this is a clean-up\n     */\n    BatchContext getBatchContext();\n\n    /**\n     * \n     * @return the parameter values, lazy loaded from task and configuration.\n     * \n     * @throws TaskException\n     */\n    Map<String, Object> getParameterValues() throws TaskException;\n\n    /**\n     * Tasks can call this function to check if the user wants to interrupt the batch\n     * and interrupt themselves.\n     * If they do, they should still return a TaskResult that implements a roll back\n     * of what was already done.\n     * \n     * @return whether the batch run should be interrupted, false if this is a clean-up\n     */\n    boolean isInterruptMe();\n\n}\n

        The batch context looks as follows:

        /**\n * During run, tasks create temporary objects that are committed to real objects during\n * the commit phase (such as a table name) This maps real objects\n * to temporary objects during a single batch run. Tasks should save and look up temporary \n * objects so that tasks within a batch can work together.\n * \n */\npublic interface BatchContext {\n\n    public static interface Dependency {\n        public void revert() throws TaskException;\n    }    \n\n    Object get(Object original);\n\n    Object get(Object original, Dependency dependency);\n\n    /**\n     * Whatever is put here in the task, must be removed in the commit!\n     * \n     * @param original\n     * @param temp\n     */\n    void put(Object original, Object temp);\n\n    void delete(Object original) throws TaskException;\n\n    BatchRun getBatchRun();\n\n}\n

        The task result looks as follows:

        /**\n * A handle of a task that was run but must still be committed or rolled back.\n * \n *\n */\npublic interface TaskResult {\n\n    /**\n     * finalize and clean-up resources any roll-back data\n     */\n    void commit() throws TaskException;\n\n    /**\n     * batch has failed - cancel all changes\n     */\n    void rollback() throws TaskException;\n\n}\n

        This is an example of how a task type can create temporary object:

        //inside TaskType.run method\n\nctx.getBatchContext().put(originalObject, tempObject)\n\n...\n\nreturn new TaskResult() {\n   @Override\n   public void commit() throws TaskException {\n       //this MUST be done!!!\n       ctx.getBatchContext.delete(originalObject)\n   } \n\n       ...\n\n}\n

        Another task type would use this temporary object as follows:

        //inside TaskType.run method\n\nObject tempObject = ctx.getBatchContext().get(originalObject, new Dependency() {\n  @Override\n  public void revert() {\n      Object object = ctx.getBatchContext().get(originalObject);\n\n      mySomething.setMyProperty(object);\n      mySomething.save();\n  }\n});\n\nmySomething.setMyProperty(tempObject);\nmySomething.save();\n
        "},{"location":"community/taskmanager/developer/#parameter-types","title":"Parameter Types","text":"

        Custom task types may use existing or define new parameter types. They handle parameter validation, parsing parameter Strings into other object types, and provide information to the GUI about the parameters.

        Existing regular Parameter Types (static members of ParameterType interface):

        • STRING
        • INTEGER
        • BOOLEAN
        • URI
        • SQL (protects against ';' hacking)

        External Parameter Types (members of ExtTypes spring bean): * dbName: database name * tableName: table name (parameter must depend on parameter of dbName type) * extGeoserver: external geoserver * internalLayer: layer from geoserver catalog * name: name qualified with namespace from geoserver catalog * fileService: file service * file: reference to file (parameter must dpend of parameter of fileService type)

        Defining a new Parameter Type:

        /**\n * \n * A Parameter Type For a Task\n * \n */\npublic interface ParameterType {\n\n    /**\n     * List possible values for this parameter (when applicable).\n     * Include an empty string if custom value is also allowed.\n     * \n     * @param dependsOnRawValues raw values of depending parameters.\n     * @return list of possible values, null if not applicable.\n     */\n    public List<String> getDomain(List<String> dependsOnRawValues);\n\n    /**\n     * Validate and parse a parameter value for this parameter (at run time).\n     * \n     * @param value the raw value.\n     * @param dependsOnRawValues raw values of depending parameters.\n     * @return the parsed value, NULL if the value is invalid.\n     */\n    public Object parse(String value, List<String> dependsOnRawValues);\n\n    /**\n     * Validate a parameter value (at configuration time).\n     * \n     * @param value the raw value.\n     * @param dependsOnRawValues raw values of depending parameters.\n     * @return true if the value is considered valid at configuration time (may still be considered\n     * invalid at parse time)\n     */\n    public default boolean validate(String value, List<String> dependsOnRawValues) {\n        return parse(value, dependsOnRawValues) != null;\n    }\n\n    /**\n     * Returns a list of web actions related to this type\n     * \n     * @return list of web actions\n     */\n    public default List<String> getActions() {\n        return Collections.emptyList();\n    }\n\n}\n
        "},{"location":"community/taskmanager/developer/#actions","title":"Actions","text":"

        Actions are extensions to the taskmanager webGUI attached to particular parameter types.

        public interface Action extends Named, Serializable {\n\n    /**\n     * Execute this action.\n     * \n     * @param onPage the configuration page.\n     * @param target the target of the ajax request that executed this action.\n     * @param valueModel the value of the attribute, for reading and writing.\n     * @param dependsOnRawValues raw values of depending attributes. \n     */\n    void execute(ConfigurationPage onPage, AjaxRequestTarget target, IModel<String> valueModel, List<String> dependsOnRawValues);\n\n    /**\n     * Check whether this action can be executed with current values.\n     * \\\n     * @param value the value of the attribute.\n     * @param dependsOnRawValues raw values of depending attributes. \n     * @return whether this action accepts these values.\n     */\n    default boolean accept(String value, List<String> dependsOnRawValues) {\n        return true;\n    }\n\n}\n

        In order to be linked to parameter types, an action must be spring bean. The name provided via the Named interface is used as a reference.

        "},{"location":"community/taskmanager/developer/#reporting","title":"Reporting","text":""},{"location":"community/taskmanager/developer/#report-builders","title":"Report builders","text":"

        Reports are user friendly representations of finished batch runs, that are sent to some destination right after the batch run has finished. A report has a type (FAILED, CANCELLED or SUCCESS), a title and a content. Use spring to configure a single report builder.

        /**\n * A report builder generates a report from a batch.\n * One could write a custom one.\n *\n */\npublic interface ReportBuilder {\n\n    Report buildBatchRunReport(BatchRun batchRun);\n\n}\n
        "},{"location":"community/taskmanager/developer/#report-services","title":"Report services.","text":"

        Use spring to configure any number of report services.

        /**\n * A report service sends a report to a particular destination.\n * One can add an unlimited amount of report services which will all be used.\n *\n */\npublic interface ReportService {\n\n    /**\n     * Enumeration for filter.\n     *\n     */\n    public enum Filter {\n        /** All batch runs are reported **/\n        ALL (Report.Type.FAILED, Report.Type.CANCELLED, Report.Type.SUCCESS),\n        /** Only failed and cancelled batch runs are reported **/\n        FAILED_AND_CANCELLED (Report.Type.FAILED, Report.Type.CANCELLED), \n        /** Only failed batch runs are reported **/\n        FAILED_ONLY (Report.Type.FAILED);\n\n        Report.Type[] types;\n\n        private Filter(Report.Type... types) {\n            this.types = types;\n        }\n\n        public boolean matches(Report.Type type) {\n            return ArrayUtils.contains(types, type);\n        }\n\n    }\n\n    /**\n     * Return the filter of the report.\n     * \n     * @return the filter of the report.\n     */\n    public Filter getFilter();\n\n    /**\n     * Send a report.\n     * \n     * @param report the report.\n     */\n    public void sendReport(Report report);\n\n}\n
        "},{"location":"community/taskmanager/user/","title":"TaskManager User Guide","text":""},{"location":"community/taskmanager/user/#installation","title":"Installation","text":"

        To install the GeoServer Task Manager extension:

        1. Download the extension from the GeoServer Download Page <download> release page: taskmanager-core. For S3 support, also install the plugin taskmanager-s3
        2. Extract this file and place the JARs in WEB-INF/lib.
        3. Perform any configuration required by your servlet container, and then restart. On startup, Task Manager will create a configuration directory taskmanager in the GeoServer Data Directory. You will be able to see the Task Manager configuration pages from the GeoServer WebGUI menu.
        "},{"location":"community/taskmanager/user/#server-configuration","title":"Server Configuration","text":""},{"location":"community/taskmanager/user/#configuration-database-clustering","title":"Configuration Database & Clustering","text":"

        By default, Task Manager will create a H2 database in its configuration directory. This can be easily changed to any JDBC resource via the taskmanager.properties file.

        The configuration directory also contains a Spring configuration file called taskManager-applicationContext.xml which allows more advanced configuration.

        TaskManager uses Quartz Scheduler. If you are running Task Manager in a clustered environment, you must configure Quartz to use a database as well as Task Manager. See the commented block in the Spring configuration and the Quartz documentation for further instructions. SQL Scripts to create the required database structures for Quartz can be found here. Task Manager can create its database automatically, or alternatively this script can be used (note: the script was made for postgresql. For any other DBMS, the script might need to be modified, or alternatively, the database could be automatically created in a development environment and then copied for a production environment). It is fine to use a single database both for Quartz and Task Manager.

        Furthermore, a property should be added to the taskmanager.properties file each of the nodes except for one: batchJobService.init=false. This is necessary because otherwise all of the nodes will attempt to load all of the same batches in to the clustered quartz database at the same time at start-up, which is likely to cause issues. This initialisation needs to happen only once for the entire cluster.

        "},{"location":"community/taskmanager/user/#taskmanager_user_databases","title":"Databases","text":"

        Task Manager allows any number of databases to be used both as sources and targets for data transfer operations. These are configured via the Spring configuration file. Currently only PostGIS is supported as a target (as well as a source), either via JNDI or directly via JDBC.

        <bean class=\"org.geoserver.taskmanager.external.impl.PostgisDbSourceImpl\"> \n    <property name=\"name\" value=\"mypostgisdb\"/> \n    <property name=\"host\" value=\"hostname\" /> \n    <property name=\"db\" value=\"dbname\" /> \n    <!-- optional --> <property name=\"schema\" value=\"schema\" /> \n    <property name=\"username\" value=\"username\" />\n    <property name=\"password\" value=\"password\" /> \n    <!-- optional, for security purposes -->\n    <property name=\"roles\">\n      <list>\n       <value>ROLE1</value>\n       <value>ROLE2</value>\n      </list>\n    </property>\n</bean>\n
        <bean class=\"org.geoserver.taskmanager.external.impl.PostgisJndiDbSourceImpl\">\n    <property name=\"name\" value=\"mypostgisjndidb\" />\n    <property name=\"jndiName\" value=\"java:/comp/env/jdbc/my-jndi-source\" />\n    <!-- optional --> <property name=\"schema\" value=\"schema\" /> \n    <!-- optional, if database has different jndi name on target geoserver servers -->  \n     <property name=\"targetJndiNames\">\n     <map>\n        <entry key=\"mygs\" value=\"java:/comp/env/jdbc/my-jndi-source-on-mygs\" />\n     </map>\n    </property>\n    <!-- optional, for security purposes -->\n    <property name=\"roles\">\n      <list>\n       <value>ROLE1</value>\n       <value>ROLE2</value>\n      </list>\n    </property>\n</bean>\n

        Roles can be specified for security purposes.

        Other database systems should generally work as a source database (not for publishing) using the GenericDbSourceImpl (this has been tested with MS SQL).

        <bean class=\"org.geoserver.taskmanager.external.impl.GenericDbSourceImpl\">\n    <property name=\"name\" value=\"mysqldb\" />\n    <property name=\"driver\" value=\"com.microsoft.sqlserver.jdbc.SQLServerDriver\"/> \n    <property name=\"connectionUrl\" value=\"jdbc:sqlserver://mysqldbhost:1433;database=mydb\" /> \n    <property name=\"username\" value=\"username\" />\n    <property name=\"password\" value=\"password\" /> \n    <property name=\"schema\" value=\"dbo\" /> \n</bean>\n

        There is also specific support for Informix as a source database (not for publishing).

        <bean class=\"org.geoserver.taskmanager.external.impl.InformixDbSourceImpl\">\n    <property name=\"name\" value=\"myinformixdb\" />\n    <property name=\"driver\" value=\"com.informix.jdbc.IfxDriver\"/> \n    <property name=\"connectionUrl\" value=\"jdbc:informix-sqli://informix-server:1539\" /> \n    <property name=\"username\" value=\"username\" />\n    <property name=\"password\" value=\"password\" /> \n</bean>\n

        It is also possible to use a source that does not support geometries, and translate them automatically from some raw type. To do this, one must create a table in the database that contains a list of all geometry columns that need to be translated. This can be configured as follows:

        <bean name=\"geomtable\" class=\"org.geoserver.taskmanager.external.impl.GeometryTableImpl\">\n    <!-- the name of your metadata table -->\n   <property name=\"nameTable\" value=\"Metadata_Geo\" />\n    <!-- the attribute name that contains table name -->\n   <property name=\"attributeNameTable\" value=\"table_name\" />\n    <!-- the attribute name that contains column name -->\n   <property name=\"attributeNameGeometry\" value=\"column_name\" />\n    <!-- the attribute name that contains geometry type -->\n   <property name=\"attributeNameType\" value=\"geometry_type\" />\n    <!-- the attribute name that contains SRID code -->\n   <property name=\"attributeNameSrid\" value=\"srid\" />\n    <!-- the type of conversion: WKT (string to geometry), WKB (binary to geometry), WKB_HEX (hex string to geometry) -->\n   <property name=\"type\" value=\"WKB_HEX\" />\n</bean>\n\n<bean class=\"org.geoserver.taskmanager.external.impl.GenericDbSourceImpl\">\n    ....  \n    <property name=\"rawGeometryTable\" ref=\"geomtable\"/>\n</bean>\n
        "},{"location":"community/taskmanager/user/#taskmanager_user_external_geoserver","title":"External GeoServers","text":"

        Task Manager allows any number of external geoservers to be used as targets for layer publications. These are configured via the Spring configuration file.

        <bean class=\"org.geoserver.taskmanager.external.impl.ExternalGSImpl\"> \n    <property name=\"name\" value=\"mygs\"/> \n    <property name=\"url\" value=\"http://my.geoserver/geoserver\" /> \n    <property name=\"username\" value=\"admin\" />\n    <property name=\"password\" value=\"geoserver\" />\n    <property name=\"supportMetadata\" value=\"true\" />\n</bean>\n

        The ''supportsMetadata'' field indicates whether this target geoserver contains the the Metadata Community Module, which provides additional support for it in certain tasks.

        The configuration above will log-in to geoserver using basic authentication. Task Manager also supports geoservers protected with keycloak:

        <bean class=\"org.geoserver.taskmanager.external.impl.ExternalKeycloakGSImpl\">\n    <property name=\"name\" value=\"keycloakgs\"/>\n    <property name=\"url\" value=\"http://my.geoserver/geoserver\"/>\n    <property name=\"username\" value=\"keycloak_admin\"/>\n    <property name=\"password\" value=\"keycloak_password\"/>\n    <property name=\"clientId\" value=\"my clientid\"/>\n    <property name=\"clientSecret\" value=\"my clientsecret\"/>\n    <property name=\"real\" value=\"my realm\"/>\n    <property name=\"authUrl\" value=\"http://my.keycloak.server/auth\"/>\n    <property name=\"supportMetadata\" value=\"true\" />\n</bean>\n
        "},{"location":"community/taskmanager/user/#taskmanager_user_file_services","title":"File Services","text":"

        File Services are used to upload and access files such as raster layers or vector files. They are configured via the Spring configuration file.

        "},{"location":"community/taskmanager/user/#regular-file-service","title":"Regular File Service","text":"

        Regular file services provide support for rasters and vector files that are stored on the hard drive.

        <bean class=\"org.geoserver.taskmanager.external.impl.FileServiceImpl\">\n    <property name=\"rootFolder\" value=\"/tmp\"/>\n    <property name=\"name\" value=\"Temporary Directory\"/>\n    <property name=\"roles\">\n      <list>\n       <value>ROLE1</value>\n       <value>ROLE2</value>\n      </list>\n    </property>\n</bean>\n

        Roles can be specified for security purposes.

        Non-absolute paths as rootFolder will be relative to the GeoServer Data Directory.

        Alternatively, it is also possible to use ResourceFileServiceImpl (same properties). This one only accepts relative paths and will use the data directory via the geoserver resource store, so that alternative implementations such as JDBC Store can be used. This might be useful for Application Schemas, for example.

        "},{"location":"community/taskmanager/user/#s3-file-service","title":"S3 File Service","text":"

        S3 File Services provide support for rasters that are stored on an S3 compatible server.

        They do not need to be configured via the application context, but are taken from the properties file provided via the property s3.properties.location (see S3 DataStore).

        A service will be created for each service and each bucket. We must add one line per alias to the s3.properties file:

        alias.s3.rootfolder=comma,separated,list,of,buckets

        The above example will create five s3 file services: alias-comma, alias-separated, alias-list, alias-of and alias-buckets.

        Roles can optionally be specified for security purposes as follows:

        alias.bucket.s3.roles=comma,separated,list,of,roles

        "},{"location":"community/taskmanager/user/#aws-file-service","title":"AWS File Service","text":"

        Amazon AWS S3 buckets are also supported.

        <bean class=\"org.geoserver.taskmanager.external.impl.AWSFileServiceImpl\">\n    <property name=\"rootFolder\" value=\"/tmp\"/>\n    <property name=\"anonymous\" value=\"false\"/>\n    <property name=\"awsRegion\" value=\"us-west-1\"/>\n    <property name=\"roles\">\n      <list>\n       <value>ROLE1</value>\n       <value>ROLE2</value>\n      </list>\n    </property>\n</bean>\n

        Unless anonymous is set to true, the default AWS client credential chain is used.

        "},{"location":"community/taskmanager/user/#prepare-script","title":"Prepare script","text":"

        The task manager GUI allows immediate upload of files to file services for local publication. It may be handy to perform some preprocessing tasks on the uploaded data before publication (such as GDAL commands). You may do this by creating a file in the taskmanager configuration directory named prepare.sh. If the user ticks the prepare checkbox in the upload dialog, this script will be run with the uploaded file as its first parameter.

        "},{"location":"community/taskmanager/user/#security","title":"Security","text":"

        Each configuration and each independent batch is associated with a workspace in GeoServer (when the workspace field is empty, it is automatically associated with the default workspace in geoserver). The configuration or batch takes its security permissions directly from this workspace.

        • If the user has reading permissions on the workspace, they may view the configuration or batch.
        • If the user has writing permissions on the workspace, they may run the batch or the batches in the configuration.
        • If the user has administrative permissions on the workspace, they may edit the configuration/batch.

        Each Database or File Service may be associated with a list of roles. If you do so, only users with those roles will have access to the database or file service in question. If you want to disable security restrictions, do not include the roles property at all (because an empty list will result in no access.)

        "},{"location":"community/taskmanager/user/#graphical-user-interface","title":"Graphical User Interface","text":"

        Currently GeoServer Task Manager can only be configured and operated from the GeoServer WebGUI.

        "},{"location":"community/taskmanager/user/#templates","title":"Templates","text":"

        From the templates page, new templates can be created (or copied from existing templates), existing templates can be edited and removed.

        templates

        Once you open a new or existing template, attributes, tasks and batches can be edited. The attribute table adjusts automatically based on the information in the tasks table; and only the values must be filled in. In the task table, the name and parameters of each task can be edited, and new tasks can be created. Batches can be created and edited from here as well, however the template must exist in order to be able to do that (in case of a new template, you must click apply once before you can create new batches). New tasks must also be saved (again, via the apply button) before they can be added to a batch.

        template db workflow

        "},{"location":"community/taskmanager/user/#configurations","title":"Configurations","text":"

        From the configurations page, new configurations can be created from scratch or from templates (or copied from existing configurations), existing configurations can be edited and removed.

        configurations

        When removing a configuration, you have to option to do a clean-up, which will attempt to remove all resources (database tables, files, layers) that were created by (tasks of) this configuration. If this (partially) fails, the configuration will still be removed and the user will be notified.

        Once you open a new or existing configuration, attributes, tasks and batches can be edited.

        workflow config 2

        The attribute table adjusts automatically based on the information in the tasks table; and only the values must be filled in. In the task table, the name and parameters of each task can be edited, and new tasks can be created. Tasks can only be removed if they are not part of a batch any longer. Batches can only be removed if they are not running anywhere. When removing a task, you have to option to do a clean-up, which will attempt to remove all resources (database tables, files, layers) that were created by this task. If this (partially) fails, the task will still be removed and the user will be notified.

        Batches can be created and edited from here as well, however the configuration must exist in order to be able to do that (in case of a new configuration, you must click apply once before you can create new batches). New tasks must also be saved (again, via the apply button) before they can be added to a batch. In case that the conditions are met, batch runs can be started, and the status/history of current and past batch runs can be displayed. Current batch runs can be interrupted (which is not guaranteed to happen immediately).

        "},{"location":"community/taskmanager/user/#importexport","title":"Import/Export","text":"

        It is also possible to import/export entire configurations to XML, for example to transfer them from one geoserver to another. The import button is on the configurations page, while the export button is on the page of a specific configuration. The user is responsible for making sure that the configuration is compatible with the other geoserver (available task extensions, attribute values,...).

        "},{"location":"community/taskmanager/user/#batches","title":"Batches","text":"

        From the batches page, new independent batches (not associated with a configuration) can be created, existing batches can be edited and removed. All existing batches - independent as well as belonging to a configuration - are shown, unless they are special (if they start with a @) or if the configuration has not yet been completed (see initializing templates).

        batches

        In case that the conditions are met, batch runs can be started, and the status/history of current and past batch runs can be displayed. Current batch runs can be interrupted (which is not guaranteed to happen immediately).

        batchruns

        batchrun

        Once you open a new or existing batch, one can add or remove tasks from it and change the order of the tasks. You can also enable/disable the batch (if disabled, the batch is not scheduled) and choose the scheduling time. The user can choose between a daily schedule (with time), weekly (with day of week and time), monthly (with day of month and time) or specify a custom cron expression.

        batch synchronize

        "},{"location":"community/taskmanager/user/#task-types","title":"Task Types","text":"
        • CopyTableTask Copy a database table from one database to another. The user can specify a source database, source table name, target database and target table name. The source table name may also be a view. If the source does not contain a primary key column (f.e. if it is a view), an additional column 'generated_id', with an automatically generated primary key will be added to the destination table. The task will also copy all existing indexes. If the source table contains a geometry column but not a spatial index (f.e. if it is a view), a spatial index will automatically be added to the destination table. Supports commit/rollback by creating a temporary table.
        • CreateViewTask Create a view based on a single table. The user can specify the database, the table name, the selected fields and (optionally) a where condition. Supports commit/rollback by creating a temporary view.
        • CreateComplexViewTask Create a view based on a multiple tables. The user can specify the database and a whole query, where it can use any other configuration attribute in the form of '\\${placeholder}'. Supports commit/rollback by creating a temporary view.
        • CopyFileTask Copy a file from one file service to another. Commit/rollback is supported by a versioning system, where the version of the file is inserted into the file name. The location of the version number is specified in the path as ### (or set auto-versioned to true to add the placeholder automatically before the extension dot). On commit, the older version is removed. On rollback, the newer version is removed. The publication tasks will automatically publish the latest version.
        • LocalDbPublicationTask Publish a database layer locally. The user can specify database, table and a layer name. Supports commit/rollback by advertising or removing the layer it created.
        • RemoteDbPublicationTask Publish a database layer to another geoserver. The user can specify a target geoserver, a source layer and a target database. All information is taken from the source layer except for the target database which may be different. Supports commit/rollback through creating a temporary (unadvertised) layer. This task also supports the version place holder or auto-versioning, in order to combine with the CopyFileTask.
        • LocalFilePublicationTask Publish a file layer locally (raster or shapefile). The user can specify a file service, a file (which can be uploaded unto the service) and a layer name. Supports commit/rollback by advertising or removing the layer it created.
        • RemoteFilePublicationTask Publish a file layer locally (taster or shapefile). The user can specify a target geoserver, a source layer and a target file service and path (optional). All information is taken from the source layer except for the file service and path which may be different. Supports commit/rollback through creating a temporary (unadvertised) layer.
        • MetaDataSyncTask Synchronise the metadata between a local layer and a layer on another geoserver (without re-publishing). The user can specify a target geoserver, a local and a remote layer. Does not support commit/rollback. If the target geoserver supports the Metadata Community Module native metadata attributes mapped to custom metadata attributes will be updated. Note that all of the publication tasks will synchronize metadata in the same way.
        • ConfigureCachedLayer Configure caching for a layer on a remote geoserver with internal GWC, synchronise the settings with the local geoserver. This task may turn caching on or off depending on local configuration.
        • ClearCachedLayer Clear (truncate) all tiles of a cached layer on a remote geoserver with internal GWC.
        • LocalAppSchemaPublicationTask Publish an Application Schema layer locally. This is exactly the same as LocalFilePublicationTask with the Application Schema mapping file as the file being published, and two additional features.
          • The mapping file may be provided as a template, with placeholders in the form of ${placeholder}. The placeholders are replaced by the values of the connection parameters of the database that is provided as parameter to the task. This makes it possible to fill in the underlying source database for different geoservers. For example: specify ${jndiReferenceName} as source database connection parameter in the mapping file.
          • Multiple mapping files may be provided for a single layer (when the layer mapping uses included types), in the form of a ZIP file. The main mapping file and the ZIP file must have the same name before the extension.
        • RemoteAppSchemaPublicationTask Publish an Application Schema layer remotely. This is exactly the same as LocalFilePublicationTask with the Application Schema mapping file as the file being published, and two additional features:
          • The mapping file may be provided as a template, with placeholders in the form of ${placeholder}. The placeholders are replaced by the values of the connection parameters of the database that is provided as parameter to the task. This makes it possible to fill in the underlying source database for different geoservers. For example: specify ${jndiReferenceName} as source database connection parameter in the mapping file.
          • Multiple mapping files may be provided for a single layer (when the layer mapping uses included types), in the form of a ZIP file. The main mapping file and the ZIP file must have the same name before the extension.
        • LayerSecuritySync this task will synchronise all data access security rules associated with a layer to the external geoserver. Warning: the task assumes that the same roles exist on both geoservers. Does not support commit/rollback.
        • WorkspaceSecuritySync this task will synchronise all data access security rules associated with a workspace to the external geoserver. Warning: the task assumes that the same roles exist on both geoservers. Does not support commit/rollback.
        • TimeStamp update a time stamp in a layer's metadata that represents the last time a layer's data has been updated. Since the data timestamp is part of the metadata, a metadata timestamp can also be updated. The task must be configured through its Spring Bean properties timeStampTaskType.dataTimestampProperty and timeStampTaskType.metadataTimestampProperty which represent the key (or key path) in the layer's resource metadata. If you are using the Metadata Community Module you should set timeStampTaskType.metadataTimestampProperty=custom._timestamp.
        • MetadataTemplateSync this task requires the Metadata Community Module and the taskmanager-metadata submodule. It will synchronize all metadata linked to a specific metadata template. Useful when you change the template.
        "},{"location":"community/taskmanager/user/#bulk-operations","title":"Bulk Operations","text":"

        The task manager provides a number of bulk operation tools via an additional page in the GUI. The import tool is also available via a REST service.

        "},{"location":"community/taskmanager/user/#run-batches","title":"Run Batches","text":"

        A whole series of batches may be scheduled all at once. You specify a workspace, configuration name and batch name pattern to select the series of batches you want to schedule. You may specify how long to wait before starting to execute the batches. You may specify how long to wait in between execution of each batch. This option is strongly recommended not to overload your software and cause failures.

        "},{"location":"community/taskmanager/user/#import-configurations","title":"Import Configurations","text":"

        The import tool allows bulk creation of an unlimited amount of configurations on the basis of a template and a CSV file with attribute values. Contrary to the rest of the configuration, this function is only exposed via a REST service and not via the GUI. The import tool will generate a new configuration for each line in the CSV file, except for the first. The first line must specify the attribute names which should all match attributes that exist in the template, plus name (required), description (optional) and workspace (optional) for the configuration metadata. The CSV file mustspecify a valid attribute value for each required attribute.

        Optionally, you may skip validation (at your own risk).

        As an alternative to using the GUI page, you may POST your CSV file to http://{geoserver-host}/geoserver/taskmanager-import/{template}[validate=false]

        "},{"location":"community/taskmanager/user/#initialize-configurations","title":"Initialize Configurations","text":"

        If you have imported configurations in bulk based on an Initializing template, you may also want to initialize them in bulk. This works similarly to running batches in bulk. The configurations will be validated after initialization.

        "},{"location":"community/taskmanager/user/#examples","title":"Examples","text":"

        Consider the following setup.

        Three geoservers:

        • work geoserver: a geoserver only available in the local network, only used by administrators. New and updated data is published here as layers for the first time, to test both the validity of data and the publication configuration.
        • internal geoserver: a geoserver only available in the local network, for internal users.
        • public geoserver: a geoserver available on the internet, for the general public.

        Several databases:

        • multiple source databases: these are databases provided by partners that provide new and updated data. they are not used to directly publish on a geoserver.
        • work database: database used by the work geoserver where its vector data is stored.
        • internal database: database used by the internal geoserver where its vector data is stored.
        • public database: database used by the public geoserver where its vector data is stored.

        A typical workflow for a new layer goes as follows:

        1. A new table is copied from a source database to the work database and then published on the work geoserver
        2. After testing, the table is either copied to the internal database and published on the internal geoserver or copied to the public database and published on the public geoserver.
        3. Every week, data is synchronised between the three databases and metadata is synchronised between the two geoservers.

        Taskmanager should be installed only on the work geoserver. Then we could make the following template:

        template db workflow

        with the following batches:

        template db workflow batches

        The @Initialize batch:

        batch initialize

        The PublishRemotely batch:

        batch publish remotely

        The Synchronize batch:

        batch synchronize

        When we now create a new configuration based on this template we choose a source database, table name and layer name:

        workflow config

        After clicking apply, the configuration is being initialized (the layer is created locally)...

        initializing...

        We can now fill in the rest of the details, save, and make the remote publication. The synchronization is scheduled weekly.

        workflow config 2

        "},{"location":"community/vector-mosaic/","title":"Vector Mosaic datastore","text":"

        The Vector Mosaic datastore is a datastore that mosaics several vector datasets into a single layer. This provides the convenience of not having to create separate stores and layers for each constituent granule vector dataset. The datastore uses the index table as an index to speed up cross dataset queries (e.g., finding the granules that match the current bbox and opening only those ones). Vector Mosaic datastore layers will have a feature type that incorporates the index table attributes (with the exception of geometry and connection parameters) combined with the vector granule attributes.

        • Installing Vector Mosaic Datastore
        • Vector Mosaic Datastore configuration
        • Vector Mosaic Datastore Delegate Requirements
        "},{"location":"community/vector-mosaic/configuration/","title":"Vector Mosaic Datastore configuration","text":"

        When the extension has been installed, Vector Mosaic Data Store will be an option in the Vector Data Sources list when creating a new data store.

        Vector Mosaic Data Store in the list of vector data sources

        Configuring an Vector Mosaic data source

        Option Description

        Workspace Name of the workspace to contain the Vector Mosaic store.

        Data Source Name Name of the Vector Mosaic Store as it will be known to GeoServer.

        Description A full free-form description of the Vector Mosaic store.

        Enabled If checked, it enables the store. If unchecked (disabled), no data in the Vector Mosaic Store will be served from GeoServer.

        delegateStoreName The data source name of the data store previously created that holds the index information about the constituent vector granules. See here for more details about delegate store requirements.

        connectionParameterKey The delegate store has a mandatory field called \"params\". Params can either be a URI pointing at the granule resource location or it can be a configuration string in .properties format. (See Java Properties file for more details about the format) In the latter case this optional parameter specifies which key points at the location of the granule. Accepted values are \"file\" and \"url\".

        preferredDataStoreSPI This optional parameter can serve as an optimization to speed up the lookup of granule data stores. Instead of attempting to use the mandatory delegate params field (See delegate requirements for more details about delegate store requirements.) to look up supported data store types, the Vector Mosaic data store will use the data store SPI specified in this field to identify the correct type.

        "},{"location":"community/vector-mosaic/delegate/","title":"Vector Mosaic Datastore Delegate Requirements","text":"

        The Vector Mosaic Datastore Delegate is a datastore that contains references to the vector granule datastores, bounding polygon or multipolygon geometry to delineate the index area, and optionally other attributes that can be queried in order to return vector granules.

        The delegate datastore can be in any format that GeoServer supports but there are two required fields:

        • There must be a geometry field representing the index spatial area in either Polygon or MultiPolygon form. There are not requirements on the name of such field.
        • There should be a field called params, in text format, that contains either:
          • The name of a store already configured in GeoServer (useful to handle few granule stores, and avoid re-creating the store at every read). The string is considered a potential name if it does not contain an equal sign (making it a candidate for property format) or a colon or having path separators (making it a candidate for URI/URL).
          • The URI/URL pointing at granule resources like shapefiles, GeoPackage, FlatGeobuf, etc. (for simplicity).
          • A configuration string in .properties format. (See Java Properties file for more details about the format).

        In addition to that, the following fields are optional: * type indicates the typename to be used when querying the granule store. Useful when the target store can contain multiple feature types. If not present, it's recommended to target a store with a single feature type (e.g., Shapefile, FlatGeoBuf). * filter is a (E)CQL filter that can be used to cherry pick the features to be read from the delegate store. This is useful when the delegate store contains a large number of features, and only a subset of them are of interest for the given set of index record attributes.

        Any other field beyond the two required can serve as queryable/filterable attribute, and will be used to narrow the number of potential granule vectors that are searched by a query. The non-required parameters will be combined with the vector granule parameters to create the output feature type.

        An example of a delegate in property datastore format can be found here. The name field can be used to filter the granules, while params` contains the location of the granule file andgeomits footprint. Thetypefield can be used for filtering, but also indicates the name of the feature type to be used when querying the granule store (in this case, happens to match the name of the target shapefile). Creating an Index with ogrtindex ================================ The `ogrtindex <https://gdal.org/programs/ogrtindex.html>`_ commandline tool from the GDAL library can be used to collect all data sets in a directory, and create an index table for it. The format of the location is slightly different than the one GeoServer expects, as it uses alocation,tableIndexformat, so a quick SQL needs to be run to make it match. Here is an example that generates a delegate shapefile from a directory of shapefiles. The third step below usesogr2ogrcommandline to trim a comma and number thatogrtindexappends to the end of the granule reference, and to turn the file location into a valid URL. #. Switch to directory with the shapefiles #. ogrtindex -write_absolute_path -tileindex \"params\" delegate_raw.shp \\*.shp #. ogr2ogr delegate.shp delegate_raw.shp -dialect SQLite -sql \"SELECT Geometry,'file://'||SUBSTR(params,1,LENGTH(params)-2) AS params from delegate_raw\" Thedelegate.shpshapefile can then be published as a store in GeoServer (no need to publish the layer), and then the mosaic store can be created, referencing to it: For example, let's say one downloads the `TIGER shapefile <https://www.census.gov/geographies/mapping-files/time-series/geo/tiger-line-file.html>`_ for thePLACEtheme, providing a shapefile with urban areas for each of the US states: .. code-block:: raw_markdown ![](images/places-files.png) Scripts exist that help with the bulk download of the files for a given theme and year, e.g. `get-tiger <https://github.com/fitnr/get-tiger>`_.ogrtindexandogr2ogrcan be used to generate a index shapefile, which will be then configured in GeoServer, and then serve as the base for mosaic store: .. code-block:: raw_markdown ![](images/places-stores.png) *The store containing the delegate/index table, and the mosaic store* .. code-block:: raw_markdown ![](images/places-mosaic-config.png) *The mosaic store refers to the delegate store by name* TheconnectionParameterKeyisurl, as that's what the Shapefile datastore is looking for, a parameter namedurlwith the location of the shapefile to open. The preferred SPI is setup to the Shapefile store to speed up the lookup of the granule store (it can be omitted, with a small performance drop). The mosaic layer can then be published in GeoServer, rendering all the required shapefiles in a single map: .. code-block:: raw_markdown ![](images/places-mosaic.png) Creating FlatGeobuf Granules with ogr2ogr and ogrtindex ====================================================================== `FlatGeobuf <https://flatgeobuf.org>`_ files make for an excellent option for cloud storage of granule data due the built in support for R-Tree indices and the use of `HTTP Range requests <https://developer.mozilla.org/en-US/docs/Web/HTTP/Range_requests>`_ to limit the amount of data streamed over the network.ogr2ogrcan be used to convert a directory of shapefiles into a directory of indexed Flatgeobufs using a simple bash script like below .. code-block:: bash #!/bin/bash shopt -s nullglob FILES=\"/data/tiger/*.shp\" for f in $FILES do fgbfilename=\"$(basename $f .shp).fgb\" ogr2ogr -f FlatGeobuf $fgbfilename $f -nlt PROMOTE_TO_MULTI -lco SPATIAL_INDEX=YES done Here is an example that generates a delegate shapefile from the directory of FlatGeobufs. The third step below usesogr2ogrcommandline to trim a comma and number thatogrtindexappends to the end of the granule reference, and to turn the file location into a valid URL. Note the exclusion of thewrite_absolute_path. Instead we append the AWS S3 bucket URL to the generated filename. #. Switch to directory with the FlatGeoBufs. #. ogrtindex -tileindex \"params\" delegate_raw.shp \\*.fgb #. ogr2ogr delegate.shp delegate_raw.shp -dialect SQLite -sql \"SELECT Geometry,'https://mybucketname.s3.amazonaws.com/'||SUBSTR(params,1,LENGTH(params)-2) AS params from delegate_raw\" #. Upload FlatGeobuf granule files to the S3 bucket referenced in the earlier step (and confirm that the bucket contents are publicly available). At this point you can publish thedelegate.shp`shapefile as a store in GeoServer as described in the previous example or you can load it into PostGIS before publication (see \\`Smart Data Loader \\<../smart-data-loader/data-store.html\\>_ for a tool for creating the PostGIS store). A PostGIS delegate is especially useful mosaics that might change over time due to support for concurrent edits, high rate loading and transactions. Note that because the granule references in the index are HTTPS URLs the index FlatgeoBuf can be hosted anywhere that your GeoServer installation can access.

        "},{"location":"community/vector-mosaic/installing/","title":"Installing Vector Mosaic Datastore","text":"

        To install the Vector Mosaic datastore:

        1. Download the module: vector-mosaic
        2. Extract this file and place the JARs in WEB-INF/lib.
        3. Perform any configuration required by your servlet container, and then restart.
        "},{"location":"community/vsi/","title":"VSI Virtual File System Support","text":"

        Support for GDAL's virtual file systems, accessible via a /vsi-prefixed path.

        "},{"location":"community/vsi/#configuration","title":"Configuration","text":"

        All configuration parameters are specified in a vsi.properties file. Any configuration option listed in GDAL's documentation. is available as a key in this file. You can specify its location on your system with the -Dvsi.properties.location option. An example configuration providing OpenStack credentials may look like:

        OS_IDENTITY_API_VERSION = 3\nOS_AUTH_URL = https://swift.provider.com/v3\nOS_PROJECT_NAME = test-project\nOS_USERNAME = user@example.com\nOS_PASSWORD = example-password\nOS_USER_DOMAIN_NAME = Default\nOS_PROJECT_DOMAIN_NAME = default\n
        "},{"location":"community/vsi/#usage","title":"Usage","text":"

        This extension adds 'VSI Virtual File System' as a possible raster data store type. The only values required when choosing this type is a connection path. This is identical to the connection paths specified in GDAL's documentation. You may also chain GDAL drivers together by concatenating their prefixes, as in the example below.

        VSI Virtual File System data store configuration

        "},{"location":"community/web-service-auth/","title":"HTTP Based Authorization plug-in","text":"

        This plugin brings the possibility to authenticate users using an external authentication service.

        • Installing the HTTP Based Authorization plug-in
        • HTTP Based Authorization configuration
        "},{"location":"community/web-service-auth/configuration/","title":"HTTP Based Authorization configuration","text":"

        The HTTP Based Authorization plug-in will try to authenticate the user on an configured external authentication service. The username and the password will be sent to the service in one of the following ways:

        • In a Header named X-HTTP-AUTHORIZATION.
        • As a query parameters or as request path. For this use case the url needs to be configured by inseritng two placeholder, namely {user} and {password} , where the username and password are expected to be provided eg. https://my-auth-service?username={username}&password={password}.

        The Authentication Provider will perform a GET request, sending credential Base64 encoded. If the response status returned by the external service is different from 200 the user will not be authenticated.

        In case the external authentication service is returning the authenticated user's roles in the response body, it is possible to define a regular expression to extract them, allowing for their usage for authorization. There is no limitation to a specific content type.

        Once the plug-in is installed, it can be configured by:

        • Opening the Authentication option in the Security menu
        • Choosing Authentication provider and then add new.
        • Choose the Web Service Authentication option

        Clicking on Web Service Authentication offers the possibility to enter the provider settings.

        Where:

        • Service URL is the URL of the external service meant to be used for authentication.
        • Timeout is the connection timeout.
        • Read Timeout is the timeout on waiting to read response data.
        • The Send credentials in X-HTTP-AUTHORIZATION Header checkbox is meant to be flagged if credentials have to be sent through the authorization header. If unchecked (default) GeoServer expects to find placeholders for username and password as {user} and {password} in the provided URL instead.
        • The Allow HTTP connection checkbox if flagged will allow authentication request to be performed toward an external service that uses HTTP protocol. By default only HTTPS is allowed.
        • In the Authorization section the radio button allows to define whether to use a GeoServer RoleService to read roles or if roles are meant to be returned by the external authentication service.
        • In case Read Roles from Web Response is chosen, a regular expression to extract the roles from the authentication service response needs to be provided.

        Once the settings are saved the new AuthenticationProvider is added to the list and needs to be added into the list of the providers' chain

        "},{"location":"community/web-service-auth/install/","title":"Installing the HTTP Based Authorization plug-in","text":"
        1. Download the nightly GeoServer community module from web-service-auth.

          ::: warning ::: title Warning :::

          Make sure to match the version of the extension to the version of the GeoServer instance! :::

        1. Extract the contents of the archive into the WEB-INF/lib directory of the GeoServer installation.
        "},{"location":"community/webp/","title":"WMS WebP output format","text":"

        This module adds the WebP WMS output format.

        WMS GetMap Request: FORMAT=image/webp

        Advantages of the WebP image format compared to other formats:

        • | WebP lossy images are about 30% smaller than comparable JPEG images.

        • | WebP supports transparency, typically providing 3x smaller file sizes compared to PNG.

        • | WebP supports paletted images, typically providing 20% smaller file sizes compared to PNG.

        Attention! Unfortunately, all the advantages of the WebP format regarding file size are negated by a more complex, time and energy-consuming processing.

        However, the WebP format could serve as an input format for the GWC and then play out the advantages again. Work is in progress.

        Read more about it here: WebP processing

        Only in exceptional cases where a slow internet connection is given (e.g. G3) this format makes sense.

        WebP is supported by all modern browsers (caniuse). However, backwards compatibility can be built in on the client side. Use Google's recommended function to detect with Javascript if the browser supports WebP. Be aware that the used image-loading is non-blocking and asynchronous. Any code that depends should preferably be put in the callback function.

        Example for OpenLayers v7 WebP browser support check via javascript:

        ...\nimport ImageLayer from 'ol/layer/Image';\nimport ImageWMS from 'ol/source/ImageWMS';\n...\nfunction check_webp_feature(feature, callback) {\n... // code from google link above\n}\ncheck_webp_feature('lossless', function (feature, isSupported) {\n  let wmsoutputformat = 'image/webp'\n  if (!isSupported) {\n     wmsoutputformat = 'image/png'\n  }\n  var wmsLayerSource = new ImageWMS({\n    params: {'LAYERS': 'yourLayerName','FORMAT': wmsoutputformat},\n    ...\n  });\n  ... // your OL code\n});\n

        Because native libraries are used, not all platforms are supported. For those supported, no additional native library needs to be installed though. The plugin is based on Java ImageIO WebP support, here you can find further information. If your platform is not supported, there are instructions for compiling the native library. In this case, do not forget to contribute.

        • Installing WMS WebP output format
        • WebP Processing
        "},{"location":"community/webp/installing/","title":"Installing WMS WebP output format","text":"

        To install the WMS WebP output format extension:

        1. Download the webp community extension from the appropriate nightly build. The file name is called geoserver-*-webp-plugin.zip, where * matches the version number of GeoServer you are using.
        2. Extract this these files and place the JARs in WEB-INF/lib.
        3. Perform any configuration required by your servlet container, and then restart.
        "},{"location":"community/webp/webp_processing/","title":"WebP Processing","text":"

        WebP achieves better compression rates by being more complex. The cost of this complexity is that it's slower, particularly at encoding.

        \"Therefore, it's not usually advisable to convert images to WebP on the fly. WebP files should be generated in advance.\" (@webmproject.org)

        Detailed information about this image format can be obtained from Googles WebP Website and the WebP Discussion Group.

        A simpler representative representation can be found at Learn Images! WebP.

        Results based on the standard libraries and the ImageIO WebP extension

        +---------------------+--------------------+-------------------------+-----------------------+ | tile size [pixel] | ImageIO PNG [ms] | ImageIO Ext WebP [ms] | LibWebP encode [ms] | +=====================+====================+=========================+=======================+ | > 128 | > 5 | > 67 | > 11.2 | +---------------------+--------------------+-------------------------+-----------------------+ | > 256 | > 15 | > 304 | > 30.1 | +---------------------+--------------------+-------------------------+-----------------------+ | > 512 | > 64 | > 1034 | > 91.4 | +---------------------+--------------------+-------------------------+-----------------------+ | > 1024 | > 177 | > 2089 | > 440.5 | +---------------------+--------------------+-------------------------+-----------------------+ | > 2048 | > 1068 | > 8027 | > 1595.9 | +---------------------+--------------------+-------------------------+-----------------------+

        Table 1: Comparison of the processing time for different tile sizes and image formats. For the ImageIO images, the average of 1000 .write functions was calculated. With LibWebP, the average of the encoding duration was calculated for 10 passes. For WebP processing, the default settings were used (lossy, q=75) and Version 1.0.0. GeoserverRequest for image (256*256).

        +---------------------+--------------+-------------+------------------+---------+ | tile size [pixel] | PNG original | ImageIO PNG | ImageIO Ext WebP | LibWebP | +=====================+==============+=============+==================+=========+ | > 128 | > 14 | > 13 | > 5 | > 5 | +---------------------+--------------+-------------+------------------+---------+ | > 256 | > 64 | > 60 | > 25 | > 25 | +---------------------+--------------+-------------+------------------+---------+ | > 512 | > 223 | > 204 | > 106 | > 106 | +---------------------+--------------+-------------+------------------+---------+ | > 1024 | > 805 | > 769 | > 352 | > 352 | +---------------------+--------------+-------------+------------------+---------+ | > 2048 | > 2283 | > 2171 | > 1062 | > 1062 | +---------------------+--------------+-------------+------------------+---------+

        Table 2: Comparison of the size in KB for different tile sizes and image formats (see table above).

        It is obvious that WebP can never match the performance of PNG images due to its encoding time.

        However, this does not explain the much worse results of the ImageIO WebP extension. Unfortunately, the original repository is not available any more, and the main fork webp_imageio is outdated and unmaintained. The Geoserver plugin is based on the fork from GOTSON. A hopeful new pure Java implementation is TwelveMonkeysImageIO WebP, but so far only supports read access. Scrimage Webp produced mostly faster results, but does not fit in Geoservers ImageIO ecosystem. Google itself provides for Android libwebp Java bindings.

        WebP supports lossless compression (for graphics) and lossy compression (for photos). Default is lossy with compression quality 75.

        • | Lossy compression: A small compression quality factor (q) produces a smaller file with lower quality (best quality q=100).

        • | Lossless compression: A small factor enables faster compression speed, but produces a larger file (maximum compression q=100).

        +-------+-----------------+-----------------+--------------+--------------+ | q | lossless [ms] | lossless [kb] | lossy [ms] | lossy [kb] | +=======+=================+=================+==============+==============+ | > 0.0 | > 48 | > 57 | > 18.6 | > 25 | +-------+-----------------+-----------------+--------------+--------------+ | > 0.1 | > 48.8 | > 57 | > 19.5 | > 26 | +-------+-----------------+-----------------+--------------+--------------+ | > 0.2 | > 48.7 | > 57 | > 19.7 | > 27 | +-------+-----------------+-----------------+--------------+--------------+ | > 0.3 | > 82.6 | > 45 | > 20.4 | > 27 | +-------+-----------------+-----------------+--------------+--------------+ | > 0.4 | > 84.6 | > 45 | > 20.6 | > 28 | +-------+-----------------+-----------------+--------------+--------------+ | > 0.5 | > 85.6 | > 45 | > 20.8 | > 29 | +-------+-----------------+-----------------+--------------+--------------+ | > 0.6 | > 89.1 | > 45 | > 20.8 | > 29 | +-------+-----------------+-----------------+--------------+--------------+ | > 0.7 | > 93.9 | > 45 | > 21.2 | > 30 | +-------+-----------------+-----------------+--------------+--------------+ | > 0.8 | > 99.3 | > 45 | > 21.4 | > 32 | +-------+-----------------+-----------------+--------------+--------------+ | > 0.9 | > 99.3 | > 45 | > 22.5 | > 36 | +-------+-----------------+-----------------+--------------+--------------+ | > 1.0 | > 1425 | > 44 | > 25.3 | > 46 | +-------+-----------------+-----------------+--------------+--------------+

        Table 3: Comparison of the lossy/lossless mode and compression factor (q) for LibWebP encoding time and file size. Input image, see below. The average of the encoding duration was calculated for 10 passes.

        +-------+-----------------+-----------------+--------------+--------------+ | q | lossless [ms] | lossless [kb] | lossy [ms] | lossy [kb] | +=======+=================+=================+==============+==============+ | > 0.0 | > 242 | > 57 | > 113 | > 25 | +-------+-----------------+-----------------+--------------+--------------+ | > 0.1 | > 211 | > 57 | > 145 | > 26 | +-------+-----------------+-----------------+--------------+--------------+ | > 0.2 | > 236 | > 57 | > 137 | > 27 | +-------+-----------------+-----------------+--------------+--------------+ | > 0.3 | > 370 | > 45 | > 150 | > 27 | +-------+-----------------+-----------------+--------------+--------------+ | > 0.4 | > 376 | > 45 | > 140 | > 28 | +-------+-----------------+-----------------+--------------+--------------+ | > 0.5 | > 308 | > 45 | > 128 | > 29 | +-------+-----------------+-----------------+--------------+--------------+ | > 0.6 | > 375 | > 45 | > 123 | > 29 | +-------+-----------------+-----------------+--------------+--------------+ | > 0.7 | > 529 | > 45 | > 126 | > 30 | +-------+-----------------+-----------------+--------------+--------------+ | > 0.8 | > 468 | > 45 | > 125 | > 32 | +-------+-----------------+-----------------+--------------+--------------+ | > 0.9 | > 424 | > 45 | > 130 | > 36 | +-------+-----------------+-----------------+--------------+--------------+ | > 1.0 | > 3106 | > 44 | > 184 | > 46 | +-------+-----------------+-----------------+--------------+--------------+

        Table 4: Comparison of the lossy/lossless mode and compression factor (q) for ImageIO WebP extension .write time and file size. Input image, see below. The average of 1000 .write functions was calculated.

        Figure 1: Input image for comparison in table 3 and 4 (PNG 256 * 256 px, 73 kb).

        Unfortunately, the best result regarding speed and size is not really usable (see below).

        Figure 2: Image of the best result (lossy, q=0).

        In general, the default values (lossy, q=0.75) are a good choice.

        The significantly longer duration regarding the ImageIO Extension cannot be explained by the writing process alone (compare tables 3 & 4).

        Processing time & energy consumption

        The increased processing time correlates with increased energy consumption.

        Measured with a commercial power meter on a local PC for one hour (multiple times).

        Stack:

        • | Windows10

        • | Java11

        • | Tomcat9

        • | Chrome Browser

        • | OpenLayers Client

        • | random WMS GetMap requests every 0.5 seconds

        Result:

        • | PNG 0.067 kWh

        • | WebP 0.071 kWh

        • | NoRequests 0.047 kWh

        This also applies to the JPEG format in a weakened way.

        Browser rendering energy impact for different image formats

        +--------------+----------------+ | Image Format | Energie impact | +==============+================+ | > WebP | > 0.4532 | +--------------+----------------+ | > PNG | > 0.4545 | +--------------+----------------+ | > PNG8 | > 0.457 | +--------------+----------------+ | > JPEG | > 0.4414 | +--------------+----------------+

        Table 5: Comparison of the rendering energy consumption for different image formats in Firefox. Average of 1000 WMS GetMap requests.

        Firefox \"Energy Impact\" (about:processes page) shows the processing power being used by the CPU.

        Despite the different file sizes of the image formats, no really significant differences can be seen. Of course, more complex coding also requires more complex decoding.

        "},{"location":"community/wps-longitudinal-profile/","title":"WPS longitudinal profile process","text":"

        WPS longitudinal profile process provides the ability to calculate an altitude profile for the specified linestring.

        In addition, the process can:

        • Reproject result to different CRS
        • Adjust altitude profile based on additional layer
        "},{"location":"community/wps-longitudinal-profile/#installing-the-wps-longitudinal-profile-process","title":"Installing the WPS longitudinal profile process","text":"
        1. If you haven't done already, install the WPS extension: Installing the WPS extension.

        2. Download the WPS longitudinal profile process extension from the nightly GeoServer community module builds.

          ::: warning ::: title Warning :::

          Make sure to match the version of the extension to the version of the GeoServer instance! :::

        3. Extract the contents of the archive into the WEB-INF/lib directory of the GeoServer installation.

        "},{"location":"community/wps-longitudinal-profile/#module-description","title":"Module description","text":"

        This module provides longitudinal profile process. The process splits provided geometry (for example linestring) into segments of no more then provided distance length. Then evaluates altitude for each point and builds longitudinal profile. If adjustment layer name is provided, altitude will be adjusted by searching feature that contains corresponding point, and getting it's altitude attribute, further subtracting it from altitude received from coverage. If targetProjection parameter is provided, points of profile will be reprojected to target CRS, otherwise to CRS of provided ewkt geometry.

        Process accepts following parameters:

        Required:

        1. layerName - name of the raster layer (coverage) which will be used for altitude profile creation
        2. geometry - geometry in wkt or ewkt format, along which the altitude profile will be created. If wkt is used, its CRS will be assumed as CRS of coverage.
        3. distance - maximal distance between points of altitude profile

        Optional:

        1. adjustmentLayerName - name of the layer with altitude, which will be used to adjust altitude values. Layer should have polygon or multipolygon geometry, and altitude attribute. Layer should be configured in the GeoServer
        2. targetProjection - target CRS of result
        3. altitudeIndex - index of altitude field in the array of coverage coordinates (0 by default)
        4. altitudeName - name of the altitude attribute on adjustment layer feature type

        Response contains following objects:

        1. profile - contains array of points of the profile
        2. infos - general info on process result

        The profile object contains an array of points.

        Each point has following values:

        1. totalDistanceToThisPoint - distance to this point from the beginning of the profile (first point) in units of CRS
        2. x - x coordinate of point
        3. y - y coordinate of point
        4. altitude - altitude of this point
        5. slope - slope between previous and current altitude

        Infos object fields:

        1. altitudePositive - sum of positive altitudes on this profile
        2. altitudeNegative - sum of negative altitudes on this profile
        3. distance - total length of profile
        4. firstpointX - x coordinate of first point
        5. firstpointY - y coordinate of first point
        6. lastpointX - x coordinate of last point
        7. lastpointY - y coordinate of last point
        8. representation - target CRS of resulting points
        9. processedpoints - total number of processed points
        10. executedtime - duration of process execution in milliseconds

        Note

        It's possible to set wpsLongitudinalMaxThreadPoolSize (integer value) environment variable to limit the size of the extension's thread pool. It's possible to set wpsLongitudinalVerticesChunkSize (integer value) environment variable to define number of vertices processed in a chunk.

        "},{"location":"community/xslt/","title":"XSLT WFS output format module","text":"

        The xslt module for GeoServer is a WFS output format generator which brings together a base output, such as GML, and a XSLT 1.0 style sheet to generate a new textual output format of user choosing.

        The configuration for this output format can be either performed directly on disk, or via a REST API.

        "},{"location":"community/xslt/#manual-configuration","title":"Manual configuration","text":"

        All the configuration for the output resides in the $GEOSERVER_DATA_DIR/wfs/transform folder, which is going to be created on startup when missing if the XSLT output format has been installed in GeoServer.

        Each XSLT transformation must be configured with its own xml file in the $GEOSERVER_DATA_DIR/wfs/transform folder, which in turn points to a xslt file for the transformation. While the names can be freeform, it is suggested to follow a simple naming convention:

        • .xml for the xml config file
        • .xslt for the xslt tile

          Transformations can be either global, and thus applicable to any feature type, or type specific, in which case the transformation knows about the specific attributes of the transformed feature type.

          "},{"location":"community/xslt/#global-transformation-example","title":"Global transformation example","text":"

          Here is an example of a global transformation setup. The $GEOSERVER_DATA_DIR/wfs/transform/global.xml file will look like:

          <transform>\n  <sourceFormat>text/xml; subtype=gml/2.1.2</sourceFormat>\n  <outputFormat>HTML</outputFormat>\n  <outputMimeType>text/html</outputMimeType>\n  <fileExtension>html</fileExtension>\n  <xslt>global.xslt</xslt>\n</transform>\n

          Here is an explanation of each element:

          • sourceFormat (mandatory): the output format used as the source of the XSLT transformation
          • outputFormat (mandatory): the output format generated by the transformation
          • outputMimeType (optional): the mime type for the generated output. In case it's missing, the outputFormat is assumed to be a mime type and used for the purpose.
          • fileExtension (optional): the file extension for the generated output. In case it's missing txt will be used.
          • xslt (mandatory): the name of XSLT 1.0 style sheet used for the transformation

          The associated XSLT file will be $GEOSERVER_DATA_DIR/wfs/transform/global.xslt folder, and it will be able to transform any GML2 input into a corresponding HTML file. Here is an example:

          <?xml version=\"1.0\" encoding=\"ISO-8859-1\"?>\n<xsl:stylesheet version=\"1.0\" xmlns:wfs=\"http://www.opengis.net/wfs\"\n  xmlns:tiger=\"http://www.census.gov\" xmlns:gml=\"http://www.opengis.net/gml\"\n  xmlns:xsl=\"http://www.w3.org/1999/XSL/Transform\">\n  <xsl:template match=\"/\">\n    <html>\n      <body>\n      <xsl:for-each select=\"wfs:FeatureCollection/gml:featureMember/*\">\n        <h2><xsl:value-of select=\"@fid\"/></h2>\n        <table border=\"1\">\n          <tr>\n            <th>Attribute</th>\n            <th>Value</th>\n          </tr>\n            <!-- [not(*)] strips away all nodes having \n                 children, in particular, geometries -->\n            <xsl:for-each select=\"./*[not(*)]\">\n            <tr>\n              <td>\n                <xsl:value-of select=\"name()\" />\n              </td>\n              <td>\n                <xsl:value-of select=\".\" />\n              </td>\n            </tr>\n            </xsl:for-each>\n        </table>\n     </xsl:for-each>\n     </body>\n   </html>\n  </xsl:template>\n</xsl:stylesheet>\n
          "},{"location":"community/xslt/#type-specific-transformations","title":"Type specific transformations","text":"

          Type specific transformations can refer to a specific type and leverage its attributes directly. While not required, it is good practice to setup a global transformation that can handle any feature type (since the output format is declared in the capabilities document as being general, not type specific) and then override it for specific feature types in order to create special transformations for them.

          Here is an example of a transformation declaration that is type specific, that will be located at $GEOSERVER_DATA_DIR/wfs/transform/html_bridges.xml

          <transform>\n  <sourceFormat>text/xml; subtype=gml/2.1.2</sourceFormat>\n  <outputFormat>HTML</outputFormat>\n  <outputMimeType>text/html</outputMimeType>\n  <fileExtension>html</fileExtension>\n  <xslt>html_bridges.xslt</xslt>\n  <featureType>\n    <id>cite:Bridges</id>\n  </featureType>\n</transform>\n

          The extra featureType element associates the transformation to the specific feature type

          The associated xslt file will be located at $GEOSERVER_DATA_DIR/wfs/transform/html_bridges.xslt and will leveraging knowledge about the input attributes:

          <?xml version=\"1.0\" encoding=\"ISO-8859-1\"?>\n<xsl:stylesheet version=\"1.0\" xmlns:wfs=\"http://www.opengis.net/wfs\"\n  xmlns:cite=\"http://www.opengis.net/cite\" xmlns:gml=\"http://www.opengis.net/gml\"\n  xmlns:xsl=\"http://www.w3.org/1999/XSL/Transform\">\n  <xsl:template match=\"/\">\n    <html>\n      <body>\n        <h2>Bridges</h2>\n        <xsl:for-each\n            select=\"wfs:FeatureCollection/gml:featureMember/cite:Bridges\">\n        <ul>\n          <li>ID: <xsl:value-of select=\"@fid\" /></li>\n          <li>FID: <xsl:value-of select=\"cite:FID\" /></li>\n          <li>Name: <xsl:value-of select=\"cite:NAME\" /></li>\n        </ul>\n        <p/>\n        </xsl:for-each>\n      </body>\n    </html>\n  </xsl:template>\n</xsl:stylesheet>\n

          Note

          While writing the XSLT always remember to declare all prefixes used in the sheet in the stylesheet element, otherwise you might encounter hard to understand error messages

          A specific feature type can be associated to multiple output formats. While uncommon, the same xslt file can also be associated to multiple feature types by creating multiple xml configuration files, and associating a different feature type in each.

          "},{"location":"community/xslt/#rest-configuration","title":"Rest configuration","text":"

          Transformations can be created, updated and deleted via the REST api (normally, this requires administrator privileges). Each transformation is represented with the same XML format used on disk, but with two variants:

          • a new name attribute appears, which matches the XML file name
          • the featureType element contains also a link to the resource representing the feature type in the REST config tree

          For example:

          <transform>\n  <name>test</name>\n  <sourceFormat>text/xml; subtype=gml/2.1.2</sourceFormat>\n  <outputFormat>text/html</outputFormat>\n  <fileExtension>html</fileExtension>\n  <xslt>test-tx.xslt</xslt>\n  <featureType>\n    <name>tiger:poi</name>\n    <atom:link xmlns:atom=\"http://www.w3.org/2005/Atom\" rel=\"alternate\" href=\"http://localhost:8080/geoserver/rest/workspaces/cite/datastores/cite/featuretypes/bridges.xml\" type=\"application/xml\"/>\n  </featureType>\n</transform>\n

          Here is a list of resources and the HTTP methods that can be used on them.

          /rest/services/wfs/transforms[.<format>]

          Method Action Return Code Formats Default Format Parameters GET List all available transforms 200 HTML, XML, JSON HTML POST Add a new transformation 201, with Location header XML, JSON name, sourceFormat, outputFormat, outputMimeType PUT Update global settings 200 XML, JSON DELETE 405

          The POST method can be used to create a transformation in two ways:

          • if the content type used is application/xml the server will assume a <transform> definition is being posted, and the XSLT will have to be uploaded separately using a PUT request with content type application/xslt+xml against the transformation resource
          • if the content type used is application/xslt+xml the server will assume the XSLT itself is being posted, and the name, sourceFormat, outputFormat, outputMimeType query parameters will be used to fill in the transform configuration instead

          /rest/services/wfs/transforms/<transform>[.<format>]

          Method Action Return Code Formats Default Format GET Returns the transformation 200 HTML, XML, XSLT HTML POST 405 PUT Updates either the transformation configuration, or its XSLT, depending on the mime type used 200 XML, XSLT DELETE Deletes the transformation 200

          The PUT operation behaves differently depending on the content type used in the request:

          • if the content type used is application/xml the server will assume a <transform> definition is being sent and will update it
          • if the content type used is application/xslt+xml the server will assume the XSLT itself is being posted, as such the configuration won't be modified, but the XSLT associated to it will be overwritten instead
          "},{"location":"configuration/","title":"Server configuration","text":"

          This page will detail how to set various configuration options in GeoServer as well as test out the services in GeoServer. It also describes how to view the GeoServer instance status.

          • Status
          • Contact Information
          • Service Metadata
          • Global Settings
          • Image Processing
          • Raster Access
          • REST Configuration
          • Advanced log configuration
          • Coordinate Reference System Handling
          • Virtual Services
          • Internationalization (i18n)
          • Demos
          • Tools
          "},{"location":"configuration/REST/","title":"REST Configuration","text":"

          Note

          For more information, please see the section on REST.

          The RESTful API allows to create new stores and append new granules to mosaics via file uploads. By default the new stores and granules are saved with the following directory structure:

          $GEOSERVER_DATA_DIR/data/<workspace>/<store>[/<file>]\n

          For changing the Root Directory from \\$GEOSERVER_DATA_DIR/data to another directory, the user can define a parameter called Root Directory path inside Global Settings Page and Workspace Settings Page.

          In order to avoid cross workspace contamination, the final path will always be:

          ${rootDirectory}/workspace/store[/<file>]\n

          Path remapping is achieved by using the default implementation of the RESTUploadPathMapper interface. This interface gives the possibility to also map the file position inside the store, which could be useful for harvesting files into an existing mosaic DataStore.

          "},{"location":"configuration/contact/","title":"Contact Information","text":"

          The Contact Information is used in the `Capabilities`` document of the WMS and other web services, and is publicly accessible.

          Contact information supports Internationalization (i18n) allowing services to be described in the requested locale.

          "},{"location":"configuration/contact/#organization","title":"Organization","text":"

          Complete this form with the organization details.

          Contact Information Organization

          The welcome message is displayed in the welcome page header as an introduction to the GeoServer web services. The organization name and online resource, if provided, are used in the welcome page header for the For more information visit link.

          Contact information fields:

          Field Description

          Organization Name of the organization with which the contact is affiliated

          Online Resource Website for organization

          Welcome Introduction displayed on the welcome page

          "},{"location":"configuration/contact/#primary-contact","title":"Primary contact","text":"

          Complete this form with the relevant contact information.

          Contact Information Primary Contact

          The email address, if provided, is used to provide a Contact administrator link for the welcome page footer.

          Contact information fields:

          Field Description

          Contact Contact information for webmaster

          Position Position of the contact within their organization

          Email Contact email address

          Telephone Contact phone number

          Fax Contact Fax number

          "},{"location":"configuration/contact/#address","title":"Address","text":"

          Complete this form with the relevant physical address information.

          Contact Information Address

          Address information fields:

          Address Type Type of address specified, such as postal

          Address Actual street address

          City City of the address

          State State or province of the address

          Zip code Postal code for the address

          Country Country of the address

          "},{"location":"configuration/globalsettings/","title":"Global Settings","text":"

          The Global Setting page configures messaging, logging, character, and proxy settings for the entire server.

          "},{"location":"configuration/globalsettings/#ogc-services","title":"OGC Services","text":"

          Global Settings are used to configure how OGC Web Services function.

          Global Settings Service Configuration

          "},{"location":"configuration/globalsettings/#service-settings","title":"Service Settings","text":""},{"location":"configuration/globalsettings/#config_globalsettings_proxy_base","title":"Proxy Base URL","text":"

          GeoServer can have the capabilities documents report a proxy properly. \"The Proxy Base URL\" field is the base URL seen beyond a reverse proxy.

          The Proxy Base URL field support environment parametrization (see Parameterize catalog settings ) by activating the JVM parameter:

          -DALLOW_ENV_PARAMETRIZATION=true\n

          Once activated the environment parametrization Proxy Base URL can be parameters placeholders like:

          ${proxy.base.url}\n
          "},{"location":"configuration/globalsettings/#config_globalsettings_proxy_headers","title":"Use headers for Proxy URL","text":"

          Checking this box allows a by-request modification of the proxy URL using templates (templates based on HTTP proxy headers).

          The supported proxy headers are:

          1. X-Forwarded-Proto The protocol used by the request
          2. X-Forwarded-Host The hostname and port of the proxy URL
          3. X-Forwarded-For The client IP address
          4. X-Forwarded-Path The path of the proxy URL (this is not an official HTTP header, although it is supported by some web-servers)
          5. Forwarded Header that supersedes the \"X-Forwarded-*\" headers above. It has these components: \"by\", \"for\", \"host\", \"proto\", \"path\" (this component is not official, but added for consistency with X-Forwarded-Path)
          6. Host Same as X-Forwarded

          For instance, to allow different protocols (http and https) and different hostnames, the proxy base URL field may be changed to: ${X-Forwarded-Proto}://${X-Forwarded-Host}/geoserver The use of the Forwarded header is a tad more complex, as its components have to be referenced in templates with the dot-notation, as in: {Forwarded.proto}://${Forwarded.host}/geoserver.

          Multiple templates can be put into the \"Proxy Base URL\". These templates provide fall-backs, since only the first one that is fully matched is used. For instance, a Proxy Base URL of http://${X-Forwarded-Host}/geoserver http://www.foo.org/geoserver (note: templates are space-separated) can result in either: http://www.example.com/geoserver (if X-Forwarded-Host is set to www.example.com) or http://www.foo.org/geoserver (if X-Forwarded-Host is not set.)

          Both header names and the appended path (e.g. /geoserver) in templates are case-insensitive.

          When environment parametrization is activated with headers support for Proxy URL, the order of evaluation is:

          1. Environment parametrization placeholders replacement (if placeholder is not found on environment variables, it remains untouched).
          2. Headers placeholders replacements.
          "},{"location":"configuration/globalsettings/#config_globalsettings_global","title":"Enable Global Services","text":"

          When enabled, allows access to both global services and virtual services. When disabled, clients will only be able to access virtual services. Disabling is useful if GeoServer is hosting a large number of layers and you want to ensure that client always request limited layer lists. Disabling is also useful for security reasons.

          "},{"location":"configuration/globalsettings/#config_globalsettings_stored_queries","title":"Allow Per-Workspace Stored Queries","text":"

          When enabled, allows to persist Stored queries per workspace, making queries created inside a workspace available in the workspace virtual service only.

          "},{"location":"configuration/globalsettings/#service-request-settings","title":"Service Request Settings","text":""},{"location":"configuration/globalsettings/#config_globalsettings_external_entities","title":"Unrestricted XML External Entity Resolution","text":"

          XML Requests sent to GeoServer can include references to other XML documents. Since these files are processed by GeoServer the facility could be used to access files on the server, which is a security concern.

          • Enable the Unrestricted XML External Entity Resolution option when using the application schema extension to allow use of local XSD definition.

            This option disables all other External Entity Resolution restrictions (see External Entities Resolution)

          "},{"location":"configuration/globalsettings/#service-response-settings","title":"Service Response Settings","text":""},{"location":"configuration/globalsettings/#config_globalsettings_charset","title":"Character Set","text":"

          Specifies the global character encoding that will be used in XML responses. Default is UTF-8, which is recommended for most users. A full list of supported character sets is available on the IANA Charset Registry.

          "},{"location":"configuration/globalsettings/#config_globalsettings_decimals","title":"Number of Decimals","text":"

          Refers to the number of decimal places returned in a GML GetFeature response. Also useful in optimizing bandwidth. Default is 8.

          "},{"location":"configuration/globalsettings/#config_globalsettings_verbose_xml","title":"Verbose XML output","text":"

          Verbose Messages, when enabled, will cause GeoServer to return XML with newlines and indents.

          Because such XML responses contain a larger amount of data, and in turn requires a larger amount of bandwidth, it is recommended to use this option only for testing purposes.

          "},{"location":"configuration/globalsettings/#service-error-settings","title":"Service Error Settings","text":""},{"location":"configuration/globalsettings/#config_globalsettings_service_problems","title":"How to handle data and configuration problems","text":"

          This setting determines how GeoServer will respond when a layer becomes inaccessible for some reason.

          By default, when a layer has an error (for example, when the default style for the layer is deleted), a service exception is printed as part of the capabilities document, making the document invalid. For clients that rely on a valid capabilities document, this can effectively make a GeoServer appear to be \"offline\".

          An administrator may prefer to configure GeoServer to simply omit the problem layer from the capabilities document, thus retaining the document integrity and allowing clients to connect to other published layers.

          There are two options:

          • OGC_EXCEPTION_REPORT: This is the default behavior. Any layer errors will show up as Service Exceptions in the capabilities document, making it invalid.

          • SKIP_MISCONFIGURED_LAYERS: With this setting, GeoServer will elect simply to not describe the problem layer at all, removing it from the capabilities document, and preserving the integrity of the rest of the document.

            Note that having a layer \"disappear\" may cause other errors in client functionality.

            This is the default setting starting with GeoServer 2.11 and allows for faster startups, as the stores connectivity does not need to be checked in advance.

          "},{"location":"configuration/globalsettings/#config_globalsettings_service_exceptions","title":"Include stack trace in service exceptions","text":"

          Verbose exception reporting returns service exceptions with full java stack traces (similar to how they appear in geoserver log file).

          By default, this setting is disabled, and GeoServer returns single-line error messages.

          This setting is only recommended for local troubleshooting and debugging. The excessive level of detail, can act as security vulnerability (for example a file not found exception revealing folder structure of your server).

          "},{"location":"configuration/globalsettings/#internal-settings","title":"Internal Settings","text":"

          Global Settings are also used to control the GeoServer application as a whole.

          Global Settings Internal Configuration

          "},{"location":"configuration/globalsettings/#logging-settings","title":"Logging Settings","text":""},{"location":"configuration/globalsettings/#config_globalsettings_log_location","title":"Log Location","text":"

          Sets the written output location for the logs. A log location may be a directory or a file, and can be specified as an absolute path (e.g., C:\\GeoServer\\GeoServer.log) or a relative one (for example, geoserver.log). Relative paths are relative to the GeoServer data directory. Default is logs/geoserver.log.

          This Log location setting can be overridden by GEOSERVER_LOG_LOCATION property, see Advanced log configuration for details (this setting is applied FileAppender or RollingFile geoserverlogfile appender).

          "},{"location":"configuration/globalsettings/#config_globalsettings_log_profile","title":"Logging Profile","text":"

          Select a Logging profile to determine the amount of detail GeoServer logs during operation.

          The built-in logging profiles available on the global settings page are:

          • Default Logging (DEFAULT_LOGGING) --- Provides a good mix of detail without being too verbose.

            Default logging enables CONFIG and INFO messages, with a few (chatty) GeoServer and GeoTools packages reduced to WARN.

            This logging level is useful for seeing the incoming requests to GeoServer in order to double check that requests being received have been parsed correctly.

          • GeoServer Developer Logging (GEOSERVER_DEVELOPER_LOGGING) - A verbose logging profile that includes DEBUG information for GeoServer activities.

            This developer profile is recommended for active debugging of GeoServer.

          • GeoTools Developer Logging (GEOTOOLS_DEVELOPER_LOGGING) - A verbose logging profile that includes DEBUG messages for the GeoTools library.

            This developer profile is recommended for active debugging of GeoTools. This is especially good for troubleshooting rendering and data access issues.

          • Production Logging (PRODUCTION_LOGGING) - Minimal logging profile, with only WARN log messages.

            With production level logging, only problems are written to the log files.

          • Quiet Logging (QUIET_LOGGING) - Turns off logging.

          • Verbose Logging (VERBOSE_LOGGING) - Provides more detail by enabling DEBUG messages.

            This profile is only useful when troubleshooting.

          Each profile corresponds to a log4j configuration file in the GeoServer data directory (Apache log4j is a Java-based logging utility). Additional customized profiles can be added by copying one of the built-in profiles above, in the logs folder, and editing the log4j file. Use of log4j can be disabled using RELINQUISH_LOG4J_CONTROL property. See Advanced log configuration for more information.

          "},{"location":"configuration/globalsettings/#config_globalsettings_log_stdout","title":"Log to StdOut","text":"

          Standard output determines where a program writes its output data. In GeoServer, the Log to StdOut setting enables logging to the text terminal that initiated the program.

          If you are running GeoServer in a large J2EE container, you might not want your container-wide logs filled with GeoServer information. Clearing this option will suppress most GeoServer logging, with only FATAL exceptions still output to the console log.

          This setting can be overridden by system property, see Advanced log configuration for details (this setting removes Console stdout appender).

          "},{"location":"configuration/globalsettings/#config_globalsettings_log_request","title":"Enable Request Logging","text":"

          These settings enable the logging of the requested URL, and optionally request headers and the POST requests' contents, for all requests sent to GeoServer.

          • Enable Request Logging: Select to enable logging of incoming requests, this will include the operation (GET,POST,etc...) and the URL requested.
          • Log Request Bodies: Select to enable logging the body of the incoming request. Text content will be logged, or the number of bytes for binary content, based on the setting Number of characters to log for incoming requests setting below.
          • Number of characters to log for incoming POST requests: In more verbose logging levels, GeoServer will log the body of incoming requests. It will only log the initial part of the request though, since it has to store (buffer) everything that gets logged for use in the parts of GeoServer that use it normally. This setting sets the size of this buffer, in characters. A setting of 0 will disable logging the body of the request.
          • Log Request Headers: Select to enable logging of request header information.

          We recommend leaving these settings disabled in day to day operations. For more information on applying these settings and their use in troubleshooting see troubleshooting.

          "},{"location":"configuration/globalsettings/#catalog-settings","title":"Catalog Settings","text":""},{"location":"configuration/globalsettings/#config_globalsettings_type_cache","title":"Feature type cache size","text":"

          GeoServer can cache datastore connections and schemas in memory for performance reasons. The cache size should generally be greater than the number of distinct featuretypes that are expected to be accessed simultaneously. If possible, make this value larger than the total number of featuretypes on the server, but a setting too high may produce out-of-memory errors. On the other hand, a value lower than the total number of your registered featuretypes may clear and reload the resource-cache more often, which can be expensive and e.g. delay WFS-Requests in the meantime. The default value for the Feature type cache size is 100.

          "},{"location":"configuration/globalsettings/#config_globalsettings_locking","title":"File Locking","text":"

          This configuration settings allows control of the type of file locking used when accessing the GeoServer Data Directory. This setting is used to protect the GeoServer configuration from being corrupted by multiple parties editing simultaneously. File locking should be employed when using the REST API to configure GeoServer, and can protected GeoServer when more than one administrator is making changes concurrently.

          There are three options:

          • NIO File locking: Uses Java New IO File Locks suitable for use in a clustered environment (with multiple GeoServers sharing the same data directory).
          • In-process locking: Used to ensure individual configuration files cannot be modified by two web administration or REST sessions at the same time.
          • Disable Locking: No file locking is used.
          "},{"location":"configuration/globalsettings/#webui-settings","title":"WebUI Settings","text":""},{"location":"configuration/globalsettings/#config_globalsettings_webui","title":"WebUI Mode","text":"

          This configuration setting allows control over WebUI redirecting behaviour. By default, when the user loads a page that contains input, a HTTP 302 Redirect response is returned that causes a reload of that same with a generated session ID in the request parameter. This session ID allows the state of the page to be remembered after a refresh and prevents any occurrence of the 'double submit problem'. However, this behaviour is incompatible with clustering of multiple geoserver instances.

          There are three options:

          • DEFAULT: Use redirecting unless a clustering module has been loaded.
          • REDIRECT: Always use redirecting (incompatible with clustering).
          • DO_NOT_REDIRECT: Never use redirecting (does not remember state when reloading a page and may cause double submit).

          Note that a restart of GeoServer is necessary for a change in the setting to have effect.

          "},{"location":"configuration/globalsettings/#other-settings","title":"Other Settings","text":"

          Additional settings for GeoServer:

          "},{"location":"configuration/globalsettings/#other-settings_1","title":"Other settings","text":""},{"location":"configuration/globalsettings/#config_globalsettings_rest_notfound","title":"REST Disable Resource not found Logging","text":"

          This parameter can be used to mute exception logging when doing REST operations and the requested Resource is not present. This default setting can be overridden by adding to a REST call the following parameter: quietOnNotFound=true/false.

          "},{"location":"configuration/globalsettings/#config_globalsettings_rest_root_dir","title":"REST PathMapper Root directory path","text":"

          This parameter is used by the RESTful API as the Root Directory for the newly uploaded files, following the structure:

          ${rootDirectory}/workspace/store[/<file>]\n
          "},{"location":"configuration/globalsettings/#config_globalsettings_display_creation","title":"Display creation timestamps on administration lists","text":"

          These check boxes can be used to toggle Date of Creation on Workspaces, Stores, Layers, Layer Groups and Styles administration list pages.

          Time of Creation can be seen by hovering the mouse cursor over the dates.

          "},{"location":"configuration/globalsettings/#config_globalsettings_display_modify","title":"Display modification timestamps on administration lists","text":"

          These check boxes can be used to toggle Date of Modification on Workspaces, Stores, Layers, Layer Groups and Styles administration list pages.

          Time of Modification can be seen by hovering the mouse cursor over the dates.

          "},{"location":"configuration/globalsettings/#match-urls-with-trailing-slash","title":"Match URLs with trailing slash","text":"

          This setting determine whether GeoServer matches URLs whether or not the request has a trailing slash. If enabled a request mapped to \"/ogc/collections\" also matches \"/ogc/collections/\". A restart is required for a change to this setting to take effect.

          Note that trailing slash matches may be removed entirely in future versions of GeoServer due to introduced ambiguities that can lead to security vulnerabilities. Discussion of the issue can be found in this Spring issue.

          "},{"location":"configuration/logging/","title":"Advanced log configuration","text":"

          GeoServer uses the Log4J framework for logging, which is configured by selecting a logging profile (in the global settings).

          The GeoServer logging profiles assign logging levels to specific server operations:

          • GeoServer loggers record server function and the activity of individual services.
          • GeoWebCache loggers record the activity of the tile protocol library used by GeoServer.
          • GeoTools loggers record the activity of the data access and rendering library used by GeoServer.
          • The appender stdout is setup as a Console appender sending information to standard output, based on Log to Stdout global settings.
          • The appender geoserverlogfile is setup as a FileAppender or RollingFile appender sending information to the Log location global settings.
          • Logging levels range from:
            • Failure (FATAL, ERROR, WARN) levels
            • Operational (INFO, CONFIG) levels
            • Verbose (DEBUG, TRACE, FINEST) levels

          In addition to the built-in profiles you may setup a custom logging profile, or override the logging configuration completely (even to use another logging library altogether).

          "},{"location":"configuration/logging/#built-in-logging-profiles","title":"Built-in logging profiles","text":"

          GeoServer includes several built-in logging profiles:

          • DEFAULT_LOGGING
          • GEOSERVER_DEVELOPER_LOGGING
          • GEOTOOLS_DEVELOPER_LOGGING
          • PRODUCTION_LOGGING
          • QUIET_LOGGING
          • VERBOSE_LOGGING

          The built-in logging profiles are installed into your data directory the first time the application is run. If you have customized (see the next section) these files and wish to restore the original contents:

          • Use the startup parameter -DUPDATE_BUILT_IN_LOGGING_PROFILES=true, the built-in logging profiles will be checked and updated if required; or
          • Delete the file and restart GeoServer, the missing file will be restored; or
          • Copy the contents from the download links above

          For a description of these logging profiles see Logging Profile. Additional built-in logging profiles are supplied by installed extensions (example IMPORTER_LOGGING profile is built into the importer extension).

          "},{"location":"configuration/logging/#custom-logging-profiles","title":"Custom logging profiles","text":"

          Anyone can write a new logging profile by adding a Log4J configuration file to the list of files already available in the $GEOSERVER_DATA_DIR/logs folder.

          Profiles in this folder that match *_LOGGING.* will be listed on the global settings page as available for use. The name of the file, excluding the extension, will be presented as the profile name.

          Here is an example, taken from the DEFAULT_LOGGING.xml configuration, which enables additional GeoServer log messages to be included in the logs:

          <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<!-- This log4j configuration file needs to stay here, and is used as the default logging setup -->\n<!-- during data_dir upgrades and in case the chosen logging config isn't available.            -->\n<Configuration name=\"DEFAULT_LOGGING\" status=\"fatal\" dest=\"out\">\n    <Appenders>\n        <Console name=\"stdout\" target=\"SYSTEM_OUT\">\n            <PatternLayout pattern=\"%date{dd MMM HH:mm:ss} %-6level [%logger{2}] - %msg%n%throwable{filters(org.junit,org.apache.maven,sun.reflect,java.lang.reflect)}\"/>\n        </Console>\n        <RollingFile name=\"geoserverlogfile\">\n            <filename>logs/geoserver.log</filename>\n            <filePattern>logs/geoserver-%i.log</filePattern>\n            <PatternLayout pattern=\"%date{dd MMM HH:mm:ss} %-6level [%logger{2}] - %msg%n%throwable{filters(org.junit,org.apache.maven,sun.reflect,java.lang.reflect)}\"/>\n            <Policies>\n                <SizeBasedTriggeringPolicy size=\"20 MB\" />\n            </Policies>\n            <DefaultRolloverStrategy max=\"3\" fileIndex=\"min\"/>\n        </RollingFile>\n    </Appenders>\n    <Loggers>\n        <Logger name=\"org.geotools\" level=\"warn\" additivity=\"false\">\n            <AppenderRef ref=\"stdout\"/>\n            <AppenderRef ref=\"geoserverlogfile\"/>\n        </Logger>\n        <Logger name=\"org.geotools.factory\" level=\"warn\" additivity=\"false\">\n            <AppenderRef ref=\"stdout\"/>\n            <AppenderRef ref=\"geoserverlogfile\"/>\n        </Logger>\n        <Logger name=\"org.geoserver\" level=\"CONFIG\" additivity=\"false\">\n            <AppenderRef ref=\"stdout\"/>\n            <AppenderRef ref=\"geoserverlogfile\"/>\n        </Logger>\n        <Logger name=\"org.vfny.geoserver\" level=\"CONFIG\" additivity=\"false\">\n            <AppenderRef ref=\"stdout\"/>\n            <AppenderRef ref=\"geoserverlogfile\"/>\n        </Logger>\n\n        <Logger name=\"org.springframework\" level=\"warn\" additivity=\"false\">\n            <AppenderRef ref=\"stdout\"/>\n            <AppenderRef ref=\"geoserverlogfile\"/>\n        </Logger>\n\n        <Logger name=\"org.geowebcache\" level=\"CONFIG\" additivity=\"false\">\n            <AppenderRef ref=\"stdout\"/>\n            <AppenderRef ref=\"geoserverlogfile\"/>\n        </Logger>\n        <Logger name=\"org.geowebcache.seed\" level=\"warn\" additivity=\"false\">\n            <AppenderRef ref=\"stdout\"/>\n            <AppenderRef ref=\"geoserverlogfile\"/>\n        </Logger>\n        <Root level=\"warn\">\n            <AppenderRef ref=\"stdout\"/>\n            <AppenderRef ref=\"geoserverlogfile\"/>\n        </Root>\n    </Loggers>\n</Configuration>\n

          Any custom configuration can be setup to enable specific packages to emit logs at the desired logging level.

          There are however a few rules to follow:

          • Custom levels are available for CONFIG and FINEST levels.
          • Appenders are used to output logging information, with GeoServer providing external configuration for appenders named geoserverlogfile and stdout.

            • Always include a geoserverlogfile FileAppender or RollingFile appender that GeoServer will configure to work against the location configured in the global settings.

              Care is taken to preserve your file extension when updating <filename> location, so if you wish to log to access_logs.txt you may do so, and the txt extension will be preserved.

            • When setting geoserverlogfile appender as RollingFile appender, care is taken to preserve your <filePattern> extensions, which must align with the roll over strategies configured.

              As an example -%i is used with DefaultRolloverStrategy to produce a maximum of 3 backup files.

              <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<!-- This log4j configuration file needs to stay here, and is used as the default logging setup -->\n<!-- during data_dir upgrades and in case the chosen logging config isn't available.            -->\n<Configuration name=\"DEFAULT_LOGGING\" status=\"fatal\" dest=\"out\">\n    <Appenders>\n        <Console name=\"stdout\" target=\"SYSTEM_OUT\">\n            <PatternLayout pattern=\"%date{dd MMM HH:mm:ss} %-6level [%logger{2}] - %msg%n%throwable{filters(org.junit,org.apache.maven,sun.reflect,java.lang.reflect)}\"/>\n        </Console>\n        <RollingFile name=\"geoserverlogfile\">\n            <filename>logs/geoserver.log</filename>\n            <filePattern>logs/geoserver-%i.log</filePattern>\n            <PatternLayout pattern=\"%date{dd MMM HH:mm:ss} %-6level [%logger{2}] - %msg%n%throwable{filters(org.junit,org.apache.maven,sun.reflect,java.lang.reflect)}\"/>\n            <Policies>\n                <SizeBasedTriggeringPolicy size=\"20 MB\" />\n            </Policies>\n            <DefaultRolloverStrategy max=\"3\" fileIndex=\"min\"/>\n        </RollingFile>\n    </Appenders>\n    <Loggers>\n        <Logger name=\"org.geotools\" level=\"warn\" additivity=\"false\">\n            <AppenderRef ref=\"stdout\"/>\n            <AppenderRef ref=\"geoserverlogfile\"/>\n        </Logger>\n        <Logger name=\"org.geotools.factory\" level=\"warn\" additivity=\"false\">\n            <AppenderRef ref=\"stdout\"/>\n            <AppenderRef ref=\"geoserverlogfile\"/>\n        </Logger>\n        <Logger name=\"org.geoserver\" level=\"CONFIG\" additivity=\"false\">\n            <AppenderRef ref=\"stdout\"/>\n            <AppenderRef ref=\"geoserverlogfile\"/>\n        </Logger>\n        <Logger name=\"org.vfny.geoserver\" level=\"CONFIG\" additivity=\"false\">\n            <AppenderRef ref=\"stdout\"/>\n            <AppenderRef ref=\"geoserverlogfile\"/>\n        </Logger>\n\n        <Logger name=\"org.springframework\" level=\"warn\" additivity=\"false\">\n            <AppenderRef ref=\"stdout\"/>\n            <AppenderRef ref=\"geoserverlogfile\"/>\n        </Logger>\n\n        <Logger name=\"org.geowebcache\" level=\"CONFIG\" additivity=\"false\">\n            <AppenderRef ref=\"stdout\"/>\n            <AppenderRef ref=\"geoserverlogfile\"/>\n        </Logger>\n        <Logger name=\"org.geowebcache.seed\" level=\"warn\" additivity=\"false\">\n            <AppenderRef ref=\"stdout\"/>\n            <AppenderRef ref=\"geoserverlogfile\"/>\n        </Logger>\n        <Root level=\"warn\">\n            <AppenderRef ref=\"stdout\"/>\n            <AppenderRef ref=\"geoserverlogfile\"/>\n        </Root>\n    </Loggers>\n</Configuration>\n
            • a Console appender writing to the standard output should be called stdout and again GeoServer will enable/disable it according to the configuration set in the global settings

              <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<!-- This log4j configuration file needs to stay here, and is used as the default logging setup -->\n<!-- during data_dir upgrades and in case the chosen logging config isn't available.            -->\n<Configuration name=\"DEFAULT_LOGGING\" status=\"fatal\" dest=\"out\">\n    <Appenders>\n        <Console name=\"stdout\" target=\"SYSTEM_OUT\">\n            <PatternLayout pattern=\"%date{dd MMM HH:mm:ss} %-6level [%logger{2}] - %msg%n%throwable{filters(org.junit,org.apache.maven,sun.reflect,java.lang.reflect)}\"/>\n        </Console>\n        <RollingFile name=\"geoserverlogfile\">\n            <filename>logs/geoserver.log</filename>\n            <filePattern>logs/geoserver-%i.log</filePattern>\n            <PatternLayout pattern=\"%date{dd MMM HH:mm:ss} %-6level [%logger{2}] - %msg%n%throwable{filters(org.junit,org.apache.maven,sun.reflect,java.lang.reflect)}\"/>\n            <Policies>\n                <SizeBasedTriggeringPolicy size=\"20 MB\" />\n            </Policies>\n            <DefaultRolloverStrategy max=\"3\" fileIndex=\"min\"/>\n        </RollingFile>\n    </Appenders>\n    <Loggers>\n        <Logger name=\"org.geotools\" level=\"warn\" additivity=\"false\">\n            <AppenderRef ref=\"stdout\"/>\n            <AppenderRef ref=\"geoserverlogfile\"/>\n        </Logger>\n        <Logger name=\"org.geotools.factory\" level=\"warn\" additivity=\"false\">\n            <AppenderRef ref=\"stdout\"/>\n            <AppenderRef ref=\"geoserverlogfile\"/>\n        </Logger>\n        <Logger name=\"org.geoserver\" level=\"CONFIG\" additivity=\"false\">\n            <AppenderRef ref=\"stdout\"/>\n            <AppenderRef ref=\"geoserverlogfile\"/>\n        </Logger>\n        <Logger name=\"org.vfny.geoserver\" level=\"CONFIG\" additivity=\"false\">\n            <AppenderRef ref=\"stdout\"/>\n            <AppenderRef ref=\"geoserverlogfile\"/>\n        </Logger>\n\n        <Logger name=\"org.springframework\" level=\"warn\" additivity=\"false\">\n            <AppenderRef ref=\"stdout\"/>\n            <AppenderRef ref=\"geoserverlogfile\"/>\n        </Logger>\n\n        <Logger name=\"org.geowebcache\" level=\"CONFIG\" additivity=\"false\">\n            <AppenderRef ref=\"stdout\"/>\n            <AppenderRef ref=\"geoserverlogfile\"/>\n        </Logger>\n        <Logger name=\"org.geowebcache.seed\" level=\"warn\" additivity=\"false\">\n            <AppenderRef ref=\"stdout\"/>\n            <AppenderRef ref=\"geoserverlogfile\"/>\n        </Logger>\n        <Root level=\"warn\">\n            <AppenderRef ref=\"stdout\"/>\n            <AppenderRef ref=\"geoserverlogfile\"/>\n        </Root>\n    </Loggers>\n</Configuration>\n
              - Loggers are used to collect messages from geoserver components, and individual libraries used. - GeoServer Logger names match up with the package names in the project javadocs overview (available for download).

              As an example package org.geoserver.wms is listed, allowing level of WMS service logging to be controlled:

              <Logger name=\"org.geoserver.wms\" level=\"debug\" additivity=\"false\">\n    <AppenderRef ref=\"stdout\"/>\n    <AppenderRef ref=\"geoserverlogfile\"/>\n</Logger>\n
            • GeoTools Logger names match up with the package names in the project javadocs overview.

              As an example package org.geotools.data.shapefile is listed, allowing level of shapefile logging to be controlled:

              <Logger name=\"org.geotools.data.shapefile\" level=\"debug\" additivity=\"false\">\n    <AppenderRef ref=\"stdout\"/>\n    <AppenderRef ref=\"geoserverlogfile\"/>\n</Logger>\n
            • Assign a level to each logger indicating the level of detail you wish to record:

              Level Description OFF Turn off all logging FATAL A serious problem has occurred, application may be crashing or in need of restart ERROR Problem has occurred, application unable to perform requested operation WARN Potential problem, application will try and continue INFO Normal function indicating what application is doing. CONFIG Normal application function during application startup and configuration DEBUG Internal messages intended for debugging TRACE Metod by method tracing of execution FINEST Really detailed troubleshooting of an algorithm ALL Turn on all logging

              The more verbose logging levels potentially include a stack-trace showing where the message occurred.

            • Use additivity=\"false\" to prevent a message collected from one logger from being passed to the next.

              If you end up with double log messages chances check for this common misconfiguration.

            • The Root logger is last in the list and should collect everything.

          "},{"location":"configuration/logging/#example-of-console-only-logging","title":"Example of console only logging","text":"

          Copy built-in logging profile and customize:

          1. Copy an example such as QUIET_LOGGING.xml to CONSOLE_LOGGING.xml:

          2. Update the initial part of CONSOLE_LOGGING.xml with the new name:

            <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<Configuration name=\"CONSOLE_LOGGING\" status=\"fatal\" dest=\"out\">\n
          3. Double check the Console appender configuration:

            <Appenders>\n    <Console name=\"stdout\" target=\"SYSTEM_OUT\">\n        <PatternLayout pattern=\"%date{dd mmm HH:mm:ss} %-6level [%logger{2}] - %msg%n%\"/>\n    </Console>\n</Appenders>\n
          4. Add appenders for geoserver (and any others you wish to track):

            <Logger name=\"org.geoserver\" level=\"ERROR\" additivity=\"false\">\n    <AppenderRef ref=\"stdout\"/>\n</Logger>\n<Logger name=\"org.vfny.geoserver\" level=\"ERROR\" additivity=\"false\">\n    <AppenderRef ref=\"stdout\"/>\n</Logger>\n
          5. Double check the root logger:

            <Root level=\"FATAL\">\n    <AppenderRef ref=\"stdout\"/>\n</Root>\n
          6. This result provides minimal feedback to the console, only reporting when GeoServer encounters an error.

          "},{"location":"configuration/logging/#overriding-the-log-location-setup-in-the-geoserver-configuration","title":"Overriding the log location setup in the GeoServer configuration","text":"

          When setting up a cluster of GeoServer machines it is common to share a single data directory among all the cluster nodes.

          There is however a gotcha, all nodes would end up writing the logs in the same file, which would cause various kinds of troubles depending on the operating system file locking rules (a single server might be able to write, or all together in an uncontrolled manner resulting in an unreadable log file).

          A common choice could be to use the machine name as a distinction, setting values such as logs/geoserver_node1.log, logs/geoserver_node2.log and so on: in this case all the log files would still be contained in the data directory and properly rotated, but each server would have its own separate log file to write on.

          In this case it is convenient to set a separate log location for each GeoServer node:

          • The GEOSERVER_LOG_LOCATION parameter can be set as system property, environment variables, or servlet context parameters:

            GEOSERVER_LOG_LOCATION=<the location of the file>\n

            This setting overrides global setting, and is applied to geoserverlogfile appender as a template for filename and filePattern.

          • This same effect may be obtained using Log4J property substitution, where a wide range of property lookups are available.

            <RollingFile name=\"geoserverlogfile\">\n    <filename>logs/geoserver-${hostName}.log</filename>\n    <filePattern>logs/geoserver-${hostName}-%d{yyyy-MM-dd-HH}-%i.zip</filePattern>\n    <PatternLayout pattern=\"%date{dd mmm HH:mm:ss} %-6level [%logger{2}] - %msg%n\"/>\n    <Policies>\n      <OnStartupTriggeringPolicy />\n      <SizeBasedTriggeringPolicy size=\"20 MB\" />\n      <TimeBasedTriggeringPolicy />\n    </Policies>\n    <DefaultRolloverStrategy max=\"9\" fileIndex=\"min\"/>\n</RollingFile>\n

            Where ${hostName} is the current system host name or ip address.

          "},{"location":"configuration/logging/#forcing-geoserver-to-relinquish-log4j-control","title":"Forcing GeoServer to relinquish Log4J control","text":"

          GeoServer internally overrides the Log4J configuration by using the current logging configuration as a template and applying the log location and standard output settings configured by the administrator.

          If you wish GeoServer not to override the normal Log4J behavior you can set the following parameter among the JVM system variables, environment variables, or servlet context parameters:

          RELINQUISH_LOG4J_CONTROL=true\n

          This can be combined with log4j2.configurationFile system property to configure Log4J externally :

          -DRELINQUISH_LOG4J_CONTROL=true -Dlog4j2.configurationFile=logging_configuration.xml\n
          "},{"location":"configuration/logging/#forcing-geoserver-to-use-an-alternate-logging-redirection","title":"Forcing GeoServer to use an alternate logging redirection","text":"

          GeoServer uses the GeoTools logging framework, which in turn is based on Java Logging, but allowing to redirect all messages to an alternate framework of the user's choice.

          By default GeoServer setups a Log4J redirection, but it is possible to configure GeoServer to use plain Java Logging, or Commons Logging instead (support for other loggers is also possible by using some extra programming).

          If you wish to force GeoServer to use a different logging mechanism set the following parameters among the JVM system variables, environment variables, or servlet context parameters:

          GT2_LOGGING_REDIRECTION=[CommonsLogging,JavaLogging,Log4J,Log4J2,LogBack]\nRELINQUISH_LOG4J_CONTROL=true\n

          As noted in the example you'll also have to demand that GeoServer does not exert control over the Log4J configuration.

          "},{"location":"configuration/logging/#force-java-logging-example","title":"Force java logging example","text":"

          As an example to configure java logging:

          -DRELINQUISH_LOG4J_CONTROL=true -DGT2_LOGGING_REDIRECTION=JavaLogging -Djava.util.logging.config.file=logging.properties\n

          With java util logging configuration provided by logging.properties:

          handlers=java.util.logging.ConsoleHandler\n\njava.util.logging.ConsoleHandler.level = ALL\njava.util.logging.ConsoleHandler.formatter = org.geotools.util.logging.MonolineFormatter\norg.geotools.util.logging.MonolineFormatter.source = class:short\n\n.level= ALL\norg.geoserver.level = CONFIG\norg.vfny.geoserver.level = WARN\n\norg.geotools.level = WARN\norg.geotools.factory.level = WARN\n
          "},{"location":"configuration/raster_access/","title":"Raster Access","text":"

          The Coverage Access Settings page in the Server menu in the Web administration interface provides configuration options to customize thread pool executors and ImageIO caching memory.

          Raster Access Settings

          "},{"location":"configuration/raster_access/#ImageIO_settings","title":"Memory Use","text":"

          WMS requests usually produce relatively small images whilst WCS requests may frequently deal with bigger datasets. Caching the image in memory before encoding it may be helpful when the size of the image isn't too big. For a huge image (as one produced by a big WCS request) it would be better instead caching through a temporary file with respect to caching in memory. This section allows to specify a threshold image size to let GeoServer decide whether to use a MemoryCacheImageOutputStream or FileCacheImageOutputStream when encoding the images.

          ImageIO Cache Memory Threshold---Sets the threshold size (expressed in KiloBytes) which will make GeoServer choose between file cache vs memory based cache. If the estimated size of the image to be encoded is smaller than the threshold value, a MemoryCacheImageOutputStream will be used resulting into caching the image in memory. If the estimated size of the image to be encoded is greater than the threshold value, a FileCacheImageOutputStream will be used.

          "},{"location":"configuration/raster_access/#cpu-use","title":"CPU Use","text":"

          The imageMosaic reader may load, in parallel, different files that make up the mosaic by means of a ThreadPoolExecutor . A global ThreadPoolExecutor instance is shared by all the readers supporting and using concurrent reads. This section of the Coverage Access Settings administration page allows configuration of the Executor parameters.

          Core Pool Size---Sets the core pool size of the thread pool executor. A positive integer must be specified.

          Maximum Pool Size---Sets the maximum pool size of the thread pool executor. A positive integer must be specified.

          Keep Alive Time---Sets the time to be wait by the executor before terminating an idle thread in case there are more threads than corePoolSize.

          Queue Type---The executor service uses a BlockingQueue to manage submitted tasks. Using an unbounded queue is recommended which allows to queue all the pending requests with no limits (Unbounded). With a direct type, incoming requests will be rejected when there are already maximumPoolSize busy threads.

          Note

          If a new task is submitted to the list of tasks to be executed, and less than corePoolSize threads are running, a new thread is created to handle the request. Incoming tasks are queued in case corePoolSize or more threads are running.

          Note

          If a request can't be queued or there are less than corePoolSize threads running, a new thread is created unless this would exceed maximumPoolSize.

          Note

          If the pool currently has more than corePoolSize threads, excess threads will be terminated if they have been idle for more than the keepAliveTime.

          Note

          If a new task is submitted to the list of tasks to be executed and there are more than corePoolSize but less than maximumPoolSize threads running, a new thread will be created only if the queue is full. This means that when using an Unbounded queue, no more threads than corePoolSize will be running and keepAliveTime has no influence.

          Note

          If corePoolSize and maximumPoolSize are the same, a fixed-size thread pool is used.

          "},{"location":"configuration/raster_access/#system-properties-configuration","title":"System Properties Configuration","text":"

          There are some additional global configuration parameters involved in raster access which can be specified through System properties.

          "},{"location":"configuration/raster_access/#max-oversampling-factor","title":"Max Oversampling Factor","text":"

          When dealing with reprojection, the underlying raster read operation might do some oversampling in order to provide the requested output resolution. Depending on the reprojection and the requested area, the oversampling factor might be high.

          Consider an untiled whole world request of an EPSG:4326 raster, towards EPSG:3857, filling a 1024x768 image. Due to the big distortion introduced by the Mercator Projection at high latitudes, the underlying read operation may result in actually reading 20000x8000 pixels, in other words, an oversampling factor of almost 20. Image processing operations will work on that big input image before returning back the desired 1024x768 image.

          This can be very time consuming (you may notice long rendering time for that). It's possible to put a limit on the maximum oversampling factor by adding the following java option to GeoServer startup script and restart it:

          -Dorg.geotools.coverage.max.oversample=N

          With N a number representing the maximum oversampling factor. By this way, the underlying read operation will use a reading resolution within that limit, making the rendering faster. The speed gain has however a penalty, output quality decrease at the poles. So you may want to play a bit with this value to find the optimal trade-off between speed and quality. For example, you could start trying with a value of 3 and check the results, and then slowly increase it until the output matches the desired quality within an acceptable rendering time.

          "},{"location":"configuration/status/","title":"Status","text":"

          The Server Status page has two tabs to summarize the current status of GeoServer. The Status tab provides a summary of server configuration parameters and run-time status. The modules tab provides the status of the various modules installed on the server. This page provides a useful diagnostic tool in a testing environment.

          "},{"location":"configuration/status/#server-status","title":"Server Status","text":"

          Status Page (default tab)

          "},{"location":"configuration/status/#status-field-descriptions","title":"Status Field Descriptions","text":"

          The following table describes the current status indicators.

          +-----------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Option | Description | +=============================+======================================================================================================================================================================================================================================================================================================================================================================================================================+ | Data directory | Shows the path to the GeoServer data directory (GEOSERVER_DATA_DIR property). | +-----------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Locks | A WFS has the ability to lock features to prevent more than one person from updating the feature at one time. If data is locked, edits can be performed by a single WFS editor. When the edits are posted, the locks are released and features can be edited by other WFS editors. A zero in the locks field means all locks are released. If locks is non-zero then a client has reserved some content for editing. | | | | | | Press Free locks to release all feature locks currently held by the server and update the field value to zero. | +-----------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Connections | Refers to the numbers of stores GeoServer is connected to, in the above case 9, that are enabled and available. | +-----------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Memory Usage | The amount of memory currently used by GeoServer. In the above example, 174 MB of memory used out of a total of 3.56 GB available to Java. | | | | | | Press Free Memory to recycle unused memory by running the garbage collector. | +-----------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | JVM Version | Denotes which version of the JVM (Java Virtual Machine) is being used to power the server. Here the JVM is AdoptOpenJDK 1.8.0_282. | +-----------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Java Rendering Engine | Shows the rendering engine used for vector operations. | +-----------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Available Fonts | Shows the number of fonts available. Selecting the link will show the full list. | +-----------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Native JAI | GeoServer uses Java Advanced Imaging (JAI) framework for image rendering and coverage manipulation. | | | | | | We recommend the use of JAI-EXT operations for greater stability. | +-----------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Native JAI ImageIO | GeoServer uses JAI Image IO (JAI) framework for raster data loading and image encoding. | | | | | | We recommend use of libjpeg-turbo for those interested in increasing encoding performance. | +-----------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | JAI Maximum Memory | The amount of memory available for the image processing tile cache, in this case 1.78 GB. | +-----------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | JAI Memory Usage | Run-time amount of memory is used for the tile cache. | | | | | | Press Free Memory to clear available JAI memory by flushing the tile cache. | +-----------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | JAI Memory Threshold | Refers to the percentage, e.g. 75, of cache memory to retain during tile removal. | +-----------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Number of JAI Tile Threads | The number of parallel threads used by the scheduler to handle tiles. | +-----------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | JAI Tile Thread Priority | Schedules the global tile scheduler priority. The priority value defaults to 5, and must fall between 1 and 10. | +-----------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Thread Pool Core Pool Size | Number of threads that the ThreadPoolExecutor will create. This is underlying Java runtime functionality - see the Java documentation for ThreadPoolExecutor for more information. | +-----------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Thread Pool Max Pool Size | Maximum number of threads that the ThreadPoolExecutor will create. This is underlying Java runtime functionality - see the Java documentation for ThreadPoolExecutor for more information. | +-----------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Thread Pool Keep Alive Time | Timeout for threads to be terminated if they are idle and more than the core pool number exist. This is underlying Java runtime functionality - see the Java documentation for ThreadPoolExecutor for more information. | +-----------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Update Sequence | Refers to the number of times, e.g. 157, the server configuration has been modified. | +-----------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Resource cache | GeoServer maintains a resource cache with connections to stores, feature type definitions, external graphics, font definitions, and CRS definitions. This includes custom CRS definitions defined in data directory user_projections/epsg.properties. | | | | | | Press Clear to empty the resource cache. This will force GeoServer to reconnect to stores, reconnect to databases, re-read icon and font information, and reload custom CRS definitions. | +-----------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Configuration and catalog | GeoServer keeps its configuration data in memory. | | | | | | Press Reload to force GeoServer to reload all of its configuration from disk. This is useful if for any reason that configuration information has become stale (e.g., an external utility has modified the configuration on disk). | +-----------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+

          "},{"location":"configuration/status/#config_serverstatus_module","title":"Module Status","text":"

          The Modules tab provides a summary of the status of all installed modules in the running server.

          Module Status

          "},{"location":"configuration/status/#field-descriptions","title":"Field Descriptions","text":"

          +-----------------+----------------------------------------------------------------------------------------------------------------------+ | Module Name | Human readable name of the module, this links to a popup containing the full details and messages of the module | +=================+======================================================================================================================+ | Module ID | The internal package name of the module | +-----------------+----------------------------------------------------------------------------------------------------------------------+ | Available | Whether the module is available to GeoServer. | | | | | | A database extension requiring a third-party database driver to be installed would not be available for use. | +-----------------+----------------------------------------------------------------------------------------------------------------------+ | Enabled | Whether the module is enabled in the current GeoServer configuration | +-----------------+----------------------------------------------------------------------------------------------------------------------+ | Component | Functional component provided by the module. | +-----------------+----------------------------------------------------------------------------------------------------------------------+ | Version | The version of the installed module | +-----------------+----------------------------------------------------------------------------------------------------------------------+ | Message (popup) | Status message such as what Java rendering engine is in use, or the library path if the module/driver is unavailable | +-----------------+----------------------------------------------------------------------------------------------------------------------+

          Module Status popup

          "},{"location":"configuration/status/#config_serverstatus_system","title":"System Status","text":"

          The System Status tab provides extra information about the system environment GeoServer is running in. This provides an overview of the status of the GeoServer instance.

          System status

          This information is also available via the REST API to troubleshoot remote systems. The library OSHI is used to retrieve system-level information without depending on native libraries or DLLs, relying solely on Apache JNA. Major operating systems (Linux, Windows and MacOS) are supported out of the box.

          Use the checkbox Enable All Statistics to start and stop the collecting and displaying system status information. Disabling is useful if GeoServer is generating a high CPU load due to system status collection.

          The available system information is:

          Info Example Description

          Operating system Linux Mint 18 Name of the operating system and the used version

          Uptime 08:34:50 Up time of the system

          System average load 1 minute 0.90 System average load for the last minute

          System average load 5 minutes 1.12 System average load for the last five minute

          System average load 15 minute 0.68 System average load for the last fifteen minute

          Number of physical CPUs 4 Number of physical CPUs / cores available

          Number of logical CPUs 8 Number of logical CPUs / cores available

          Number of running process 316 Total number of process running in the system

          Number of running threads 1094 Total number of threads running in the system

          CPU load average 4.12 % Average load of the CPU in the last second

          CPU * load 11.43 % Load of a specific core in the last second

          Used physical memory 31.58 % Percentage of the system memory used

          Total physical memory 31.4 GiB System total memory

          Free physical memory 21.4 GiB System memory available for use

          Used swap memory 0.00% Percentage of swap memory used

          Total swap memory 32.0 GiB System total swap memory

          Free swap memory 32.0 GiB Free swap memory

          File system usage 65.47 % File system usage taking in account all partitions

          Partition * used space 54.8 % Percentage of space used in a specific partition

          Partition * total space 338.9 GiB Total space of a specific partition

          Partition * free space 117.0 GiB Free space on a specific partition

          Network interfaces send 42.0 MiB Data send through all the available network interfaces

          Network interfaces received 700.4 MiB Data received through all the available network interfaces

          Network interface * send 25.0 MiB Data send through a specific network interface

          Network interface * received 250.4 MiB Data received through a specific network interface

          CPU temperature 52.00 \u00baC CPU temperature

          CPU voltage 1.5 V CPU voltage

          GeoServer CPU usage 3.5 % Percentage of CPU used by GeoServer in the last second

          GeoServer threads 49 Number of threads created by GeoServer

          GeoServer JVM memory usage 5.83 % Percentage of the JVM memory used by GeoServer

          If some information is not available the special term NOT AVAILABLE will appear. Values will be automatically converted to best human readable unit.

          "},{"location":"configuration/status/#config_serverstatus_jvm","title":"JVM Console","text":"

          For information on the live Java Runtime Environment the JVM Console tab provides access to two useful troubleshooting tools.

          Press Thread Dump for a summary of all active threads. This is primarily used to troubleshoot performance issues and a non-responsive system. This can be used to identify when significant work is happening in the background, or if threads are stuck waiting on a resource.

          Thread Dump console output

          Press Heap Dump for an overview of memory use. This can be used to troubleshoot systems that are encountering a memory leak over time. .. code-block:: raw_markdown

          ! Heap Dump console output

          • Click Download link to download the JVM Console contents.

          For more information on effective use see Troubleshooting.

          "},{"location":"configuration/virtual-services/","title":"Virtual Services","text":"

          The different types of services in GeoServer include WFS, WMS, and WCS, commonly referred to as \"Open Web Services (OWS)\" services. These services are global in that each service publishes every layer configured on the server. WFS publishes all vector layer (feature types), WCS publishes all raster layers (coverages), and WMS publishes everything.

          A virtual service is a view of the global service that consists only of a subset of the layers. Virtual services are based on GeoServer workspaces. For each workspace that exists a virtual service exists along with it. The virtual service publishes only those layers that fall under the corresponding workspace.

          Warning

          Virtual services only apply to the core OWS services, and not OWS services accessed through GeoWebCache. It also does not apply to other subsystems such as REST.

          When a client accesses a virtual service that client only has access to those layers published by that virtual service. Access to layers in the global service via the virtual service will result in an exception. This makes virtual services ideal for compartmentalizing access to layers. A service provider may wish to create multiple services for different clients handing one service url to one client, and a different service url to another client. Virtual services allow the service provider to achieve this with a single GeoServer instance.

          "},{"location":"configuration/virtual-services/#filtering-by-workspace","title":"Filtering by workspace","text":"

          Consider the following snippets of the WFS capabilities document from the GeoServer release configuration that list all the feature types:

          http://localhost:8080/geoserver/wfs?request=GetCapabilities\n\n<wfs:WFS_Capabilities>\n\n  <FeatureType xmlns:tiger=\"http://www.census.gov\">\n   <Name>tiger:poly_landmarks</Name>\n--\n  <FeatureType xmlns:tiger=\"http://www.census.gov\">\n   <Name>tiger:poi</Name>\n--\n  <FeatureType xmlns:tiger=\"http://www.census.gov\">\n   <Name>tiger:tiger_roads</Name>\n--\n  <FeatureType xmlns:sf=\"http://www.openplans.org/spearfish\">\n   <Name>sf:archsites</Name>\n--\n  <FeatureType xmlns:sf=\"http://www.openplans.org/spearfish\">\n   <Name>sf:bugsites</Name>\n--\n  <FeatureType xmlns:sf=\"http://www.openplans.org/spearfish\">\n   <Name>sf:restricted</Name>\n--\n  <FeatureType xmlns:sf=\"http://www.openplans.org/spearfish\">\n   <Name>sf:roads</Name>\n--\n  <FeatureType xmlns:sf=\"http://www.openplans.org/spearfish\">\n   <Name>sf:streams</Name>\n--\n  <FeatureType xmlns:topp=\"http://www.openplans.org/topp\">\n   <Name>topp:tasmania_cities</Name>\n--\n  <FeatureType xmlns:topp=\"http://www.openplans.org/topp\">\n   <Name>topp:tasmania_roads</Name>\n--\n  <FeatureType xmlns:topp=\"http://www.openplans.org/topp\">\n   <Name>topp:tasmania_state_boundaries</Name>\n--\n  <FeatureType xmlns:topp=\"http://www.openplans.org/topp\">\n   <Name>topp:tasmania_water_bodies</Name>\n--\n  <FeatureType xmlns:topp=\"http://www.openplans.org/topp\">\n   <Name>topp:states</Name>\n--\n  <FeatureType xmlns:tiger=\"http://www.census.gov\">\n   <Name>tiger:giant_polygon</Name>\n\n</wfs:WFS_Capabilities>\n

          The above document lists every feature type configured on the server. Now consider the following capabilities request:

          http://localhost:8080/geoserver/topp/wfs?request=GetCapabilities\n

          The part of interest in the above request is the \"topp\" prefix to the wfs service. The above url results in the following feature types in the capabilities document:

          <wfs:WFS_Capabilities>\n\n   <FeatureType xmlns:topp=\"http://www.openplans.org/topp\">\n    <Name>topp:tasmania_cities</Name>\n --\n   <FeatureType xmlns:topp=\"http://www.openplans.org/topp\">\n    <Name>topp:tasmania_roads</Name>\n --\n   <FeatureType xmlns:topp=\"http://www.openplans.org/topp\">\n    <Name>topp:tasmania_state_boundaries</Name>\n --\n   <FeatureType xmlns:topp=\"http://www.openplans.org/topp\">\n    <Name>topp:tasmania_water_bodies</Name>\n --\n   <FeatureType xmlns:topp=\"http://www.openplans.org/topp\">\n    <Name>topp:states</Name>\n\n </wfs:WFS_Capabilities>\n

          The above feature types correspond to those configured on the server as part of the \"topp\" workspace.

          The consequence of a virtual service is not only limited to the capabilities document of the service. When a client accesses a virtual service it is restricted to only those layers for all operations. For instance, consider the following WFS feature request:

          http://localhost:8080/geoserver/topp/wfs?request=GetFeature&typename=tiger:roads\n

          The above request results in an exception. Since the request feature type \"tiger:roads\" is not in the \"topp\" workspace the client will receive an error stating that the requested feature type does not exist.

          "},{"location":"configuration/virtual-services/#filtering-by-layer","title":"Filtering by layer","text":"

          It is possible to further filter a global service by specifying the name of layer as part of the virtual service. For instance consider the following capabilities document:

          http://localhost:8080/geoserver/topp/states/wfs?request=GetCapabilities\n

          The part of interest is the \"states\" prefix to the wfs service. The above url results in the following capabilities document that contains a single feature type:

          <wfs:WFS_Capabilities>\n\n  <FeatureType xmlns:topp=\"http://www.openplans.org/topp\">\n   <Name>topp:states</Name>\n\n<wfs:WFS_Capabilities>\n
          "},{"location":"configuration/virtual-services/#global_services_off","title":"Turning off global services","text":"

          It is possible to completely restrict access to the global OWS services by setting a configuration flag. When global access is disabled OWS services may only occur through a virtual service. Any client that tries to access a service globally will receive an exception.

          To disable global services, log into the GeoServer web administration interface and navigate to \"Global Settings\". Uncheck the \"Enable Global Services\" check box.

          "},{"location":"configuration/virtual-services/#workspace_isolated","title":"Isolated Workspaces","text":"

          Isolated workspaces content is only visible and queryable in the context of a virtual service bound to the isolated workspace. This means that isolated workspaces content will not show up in global capabilities documents and global services cannot query isolated workspaces contents. Note that these restrictions do not apply to the REST API.

          A workspace can be made isolated by checking the Isolated Workspace checkbox when creating or editing a workspace.

          Making a workspace isolated

          An isolated workspace will be able to reuse a namespace already used by another workspace, but its resources (layers, styles, etc ...) can only be retrieved when using that workspace virtual services and will only show up in those virtual services capabilities documents.

          It is only possible to create two or more workspaces with the same namespace in GeoServer if only one of them is non isolated, i.e. isolated workspaces have no restrictions in namespaces usage but two non isolated workspaces can't use the same namespace.

          The following situation will be valid:

          • Prefix: st1 Namespace: http://www.stations.org/1.0 Isolated: false
          • Prefix: st2 Namespace: http://www.stations.org/1.0 Isolated: true
          • Prefix: st3 Namespace: http://www.stations.org/1.0 Isolated: true

          But not the following one:

          • Prefix: st1 Namespace: http://www.stations.org/1.0 Isolated: false
          • Prefix: st2 Namespace: http://www.stations.org/1.0 Isolated: false
          • Prefix: st3 Namespace: http://www.stations.org/1.0 Isolated: true

          At most only one non isolated workspace can use a certain namespace.

          Consider the following image which shows to workspaces (st1 and st2) that use the same namespace (http://www.stations.org/1.0) and several layers contained by them:

          Two workspaces using the same namespace, one of them is isolated.

          In the example above st2 is the isolated workspace. Consider the following WFS GetFeature requests:

          1. http://localhost:8080/geoserver/ows?service=WFS&version=2.0.0&request=DescribeFeatureType&typeName=layer2
          2. http://localhost:8080/geoserver/st2/ows?service=WFS&version=2.0.0&request=DescribeFeatureType&typeName=layer2
          3. http://localhost:8080/geoserver/ows?service=WFS&version=2.0.0&request=DescribeFeatureType&typeName=st1:layer2
          4. http://localhost:8080/geoserver/st2/ows?service=WFS&version=2.0.0&request=DescribeFeatureType&typeName=st2:layer2
          5. http://localhost:8080/geoserver/ows?service=WFS&version=2.0.0&request=DescribeFeatureType&typeName=st2:layer2
          6. http://localhost:8080/geoserver/ows?service=WFS&version=2.0.0&request=DescribeFeatureType&typeName=layer5

          The first request is targeting WFS global service and requesting layer2, this request will use layer2 contained by workspace st1. The second request is targeting st2 workspace WFS virtual service, layer2 belonging to workspace st2 will be used. Request three and four will use layer2 belonging to workspace, respectively, st1 and st2. The last two requests will fail saying that the feature type was not found, isolated workspaces content is not visible globally.

          The rule of thumb is that resources (layers, styles, etc ...) belonging to an isolated workspace can only be retrieved when using that workspaces virtual services and will only show up in those virtual services capabilities documents.

          "},{"location":"configuration/crshandling/","title":"Coordinate Reference System Handling","text":"

          This section describes how coordinate reference systems (CRS) are handled in GeoServer, as well as what can be done to extend GeoServer's CRS handling abilities.

          • Coordinate Reference System Configuration
          • Custom CRS Definitions
          • Coordinate Operations
          • Manually editing the EPSG database
          "},{"location":"configuration/crshandling/configurecrs/","title":"Coordinate Reference System Configuration","text":"

          When adding data, GeoServer tries to inspect data headers looking for an EPSG code:

          • If the data has a CRS with an explicit EPSG code and the full CRS definition behind the code matches the one in GeoServer, the CRS will be already set for the data.
          • If the data has a CRS but no EPSG code, you can use the Find option on the Layers page to make GeoServer perform a lookup operation where the data CRS is compared against every other known CRS. If this succeeds, an EPSG code will be selected. The common case for a CRS that has no EPSG code is shapefiles whose .PRJ file contains a valid WKT string without the EPSG identifiers (as these are optional).

          If an EPSG code cannot be found, then either the data has no CRS or it is unknown to GeoServer. In this case, there are a few options:

          • Force the declared CRS, ignoring the native one. This is the best solution if the native CRS is known to be wrong.
          • Reproject from the native to the declared CRS. This is the best solution if the native CRS is correct, but cannot be matched to an EPSG number. (An alternative is to add a custom EPSG code that matches exactly the native SRS. See the section on Custom CRS Definitions for more information.)

          If your data has no native CRS information, the only option is to specify/force an EPSG code.

          "},{"location":"configuration/crshandling/configurecrs/#increasing-comparison-tolerance","title":"Increasing Comparison Tolerance","text":"

          Decimal numbers comparisons are made using a comparison tolerance. This means, as an instance, that an ellipsoid's semi_major axis equals a candidate EPSG's ellipsoid semi_major axis only if their difference is within that tolerance. Default value is 10\\^-9 although it can be changed by setting a COMPARISON_TOLERANCE Java System property to your container's JVM to specify a different value.

          Warning

          The default value should be changed only if you are aware of use cases which require a wider tolerance. Don't change it unless really needed (See the following example).

          "},{"location":"configuration/crshandling/configurecrs/#example","title":"Example","text":"
          • Your sample dataset is known to be a LambertConformalConic projection and the related EPSG code defines latitude_of_origin value = 25.0.
          • The coverageStore plugin is exposing raster projection details through a third party library which provides projection parameter definitions as float numbers.
          • Due to the underlying math computations occurring in that third party library, the exposed projection parameters are subject to some accuracy loss, so that the provided latitude_of_origin is something like 25.0000012 whilst all the other params match the EPSG definition.
          • You notice that the native CRS isn't properly recognized as the expected EPSG due to that small difference in latitude_of_origin

          In that case you could consider increasing a bit the tolerance.

          "},{"location":"configuration/crshandling/coordtransforms/","title":"Coordinate Operations","text":"

          Coordinate operations are used to convert coordinates from a source CRS to a target CRS.

          If source and target CRSs are referred to a different datum, a datum transform has to be applied. Datum transforms are not exact, they are determined empirically. For the same pair of CRS, there can be many datum transforms and versions, each one with its own domain of validity and an associated transform error. Given a CRS pair, GeoServer will automatically pick the most accurate datum transform from the EPSG database, unless a custom operation is declared.

          • Coordinate operations can be queried and tested using the Reprojection Console.
          • To enable higher accuracy Grid Shift transforms, see Add Grid Shift Transform files.
          • See Define a custom Coordinate Operation to declare new operations. Custom operations will take precedence over the EPSG ones.
          "},{"location":"configuration/crshandling/coordtransforms/#reprojection-console","title":"Reprojection Console","text":"

          The reprojection console (available in Demos) lets you quickly test coordinate operations. Use it to convert a single coordinate or WKT geometry, and to see the operation details GeoServer is using. It is also useful to learn by example when you have to Define a custom Coordinate Operation.

          Read more about the Reprojection console.

          "},{"location":"configuration/crshandling/coordtransforms/#add-grid-shift-transform-files","title":"Add Grid Shift Transform files","text":"

          GeoServer supports NTv2 and NADCON grid shift transforms. Grid files are not shipped out with GeoServer. They need to be downloaded, usually from your National Mapping Agency website.

          Warning

          Grid Shift files are only valid in the specific geographic domain for which they where made; trying to transform coordinates outside this domain will result in no trasformation at all. Make sure that the Grid Shift files are valid in the area you want to transform.

          1. Search for the Grid File Name(s) int the tables below, which are extracted from EPSG version 7.9.0. If you need to use a Grid Shift transform not declared in EPSG, you will need to Define a custom Coordinate Operation.
          2. Get the Grid File(s) from your National Mapping Agency (NTv2) or the US National Geodetic Survey (NADCON).
          3. Copy the Grid File(s) in the user_projections directory inside your data directory.
          4. Use the Reprojection Console to test the new transform.
          "},{"location":"configuration/crshandling/coordtransforms/#list-of-available-grid-shift-transforms","title":"List of available Grid Shift transforms","text":"

          The list of Grid Shift transforms declared in EPSG version 7.9.0 is:

          "},{"location":"configuration/crshandling/coordtransforms/#ntv2","title":"NTv2","text":"Source CRS Target CRS Grid File Name Source Info 4122 4326 NB7783v2.gsb OGP 4122 4326 NS778301.gsb OGP 4122 4326 PE7783V2.gsb OGP 4122 4617 NB7783v2.gsb New Brunswick Geographic Information Corporation land and water information standards manual. 4122 4617 NS778301.gsb Nova Scotia Geomatics Centre - Contact aflemmin@linux1.nsgc.gov.ns.ca or telephone 902-667-6409 4122 4617 PE7783V2.gsb PEI Department of Transportation & Public Works 4149 4150 CHENyx06a.gsb Bundesamt f\u00fcr Landestopografie swisstopo; www.swisstopo.ch 4149 4151 CHENyx06_ETRS.gsb Bundesamt f\u00fcr Landestopografie swisstopo; www.swisstopo.ch 4149 4258 CHENyx06_ETRS.gsb Bundesamt f\u00fcr Landestopografie swisstopo; www.swisstopo.ch 4149 4326 CHENyx06_ETRS.gsb IOGP 4171 4275 rgf93_ntf.gsb ESRI 4202 4283 A66 National (13.09.01).gsb GDA Technical Manual. http://www.icsm.gov.au/gda 4202 4283 SEAust_21_06_00.gsb Office of Surveyor General Victoria; http://www.land.vic.gov.au/ 4202 4283 nt_0599.gsb GDA Technical Manual. http://www.icsm.gov.au/gda 4202 4283 tas_1098.gsb http://www.delm.tas.gov.au/osg/Geodetic_transform.htm 4202 4283 vic_0799.gsb Office of Surveyor General Victoria; http://www.land.vic.gov.au/ 4202 4326 A66 National (13.09.01).gsb OGP 4203 4283 National 84 (02.07.01).gsb GDA Technical Manual. http://www.icsm.gov.au/gda 4203 4283 wa_0700.gsb Department of Land Information, Government of Western Australia; http://www.dola.wa.gov.au/ 4203 4326 National 84 (02.07.01).gsb OGP 4207 4258 DLx_ETRS89_geo.gsb Instituto Geografico Portugues; http://www.igeo.pt 4225 4326 CA7072_003.gsb OGP 4225 4674 CA7072_003.gsb IBGE. 4230 4258 100800401.gsb Geodesy Unit, Cartographic Institute of Catalonia (ICC); http://www.icc.cat 4230 4258 SPED2ETV2.gsb Instituto Geogr\u00e1fico Nacional, www.cnig.es 4230 4326 SPED2ETV2.gsb OGP 4258 4275 rgf93_ntf.gsb OGP 4267 4269 NTv2_0.gsb http://www.geod.nrcan.gc.ca/products/html-public/GSDapps/English/NTv2_Fact_Sheet.html 4267 4269 QUE27-83.gsb Geodetic Service of Quebec. Contact alain.bernard@mrn.gouv.qc.ca 4267 4326 NTv2_0.gsb OGP 4267 4326 QUE27-98.gsb OGP 4267 4326 SK27-98.gsb OGP 4267 4617 NB2783v2.gsb \"Generation of a NAD27-NAD83(CSRS) NTv2-type Grid Shift File for New Brunswick\", Marcelo C. Santos and Carlos A. Garcia, Department of Geodesy and Geomatics Engineering, University of New Brunswick, October, 2011 via Service New Brunswick. 4267 4617 QUE27-98.gsb Geodetic Service of Quebec. Contact alain.bernard@mrn.gouv.qc.ca 4267 4617 SK27-98.gsb Dir Geodetic Surveys; SaskGeomatics Div.; Saskatchewan Property Management Company. 4269 4326 AB_CSRS.DAC OGP 4269 4326 NAD83-98.gsb OGP 4269 4326 SK83-98.gsb OGP 4269 4617 AB_CSRS.DAC Geodetic Control Section; Land and Forest Svc; Alberta Environment; http://www3.gov.ab.ca/env/land/dos/ 4269 4617 NAD83-98.gsb Geodetic Service of Quebec. Contact alain.bernard@mrn.gouv.qc.ca 4269 4617 SK83-98.gsb Dir Geodetic Surveys; SaskGeomatics Div.; Saskatchewan Property Management Company. 4272 4167 nzgd2kgrid0005.gsb Land Information New Zealand: LINZS25000 Standard for New Zealand Geodetic Datum 2000; 16 November 2007. 4272 4326 nzgd2kgrid0005.gsb OGP 4274 4258 D73_ETRS89_geo.gsb Instituto Geografico Portugues; http://www.igeo.pt 4277 4258 OSTN02_NTv2.gsb Ordnance Survey of Great Britain, http://www.gps.gov.uk 4277 4258 OSTN15_NTv2_OSGBtoETRS.gsb Ordnance Survey of Great Britain. 4277 4326 OSTN02_NTv2.gsb OGP 4277 4326 OSTN15_NTv2_OSGBtoETRS.gsb IOGP 4283 7844 COCOS_C_V1.gsb GDA2020 Technical Manual (http://www.icsm.gov.au) 4283 7844 GDA94_GDA2020_conformal.gsb GDA2020 Technical Manual and ICSM Datum Technical Fact Sheet TN1 (http://www.icsm.gov.au). 4283 7844 GDA94_GDA2020_conformal_and_distortion.gsb GDA2020 Technical Manual and ICSM Datum Technical Fact Sheet TN1 (http://www.icsm.gov.au). 4283 7844 XMAS_C_V1.gsb GDA2020 Technical Manual (http://www.icsm.gov.au). 4289 4258 rdtrans2008.gsb Kadaster and Rijkswaterstaat CIV, working together under the name RDNAP. 4300 4258 tm75_etrs89.gsb ESRI Ireland. 4300 4326 tm75_etrs89.gsb OGP 4301 4612 tky2jgd.gsb ESRI 4301 6668 tky2jgd.gsb OGP 4312 4258 AT_GIS_GRID.gsb Federal Office of Metrology and Surveying (BEV); http://www.bev.gv.at 4313 4258 bd72lb72_etrs89lb08.gsb IGN Brussels www.ngi.be 4314 4258 BETA2007.gsb BKG via EuroGeographics http://crs.bkg.bund.de/crs-eu/ 4314 4326 BETA2007.gsb OGP 4326 4275 rgf93_ntf.gsb OGP 4608 4269 May76v20.gsb Geodetic Survey of Canada http://www.geod.nrcan.gc.ca/ 4608 4326 May76v20.gsb OGP 4609 4269 CGQ77-83.gsb Geodetic Service of Quebec. Contact alain.bernard@mrn.gouv.qc.ca 4609 4326 CGQ77-98.gsb OGP 4609 4617 CGQ77-98.gsb Geodetic Service of Quebec. Contact alain.bernard@mrn.gouv.qc.ca 4612 6668 touhokutaiheiyouoki2011.gsb ESRI 4618 4326 SAD69_003.gsb OGP 4618 4674 SAD69_003.gsb IBGE. 4745 4258 NTv2_SN.gsb Saxony State Spatial Data and Land Survey Corporation (GeoSN). 4745 4326 BETA2007.gsb OGP 4746 4326 BETA2007.gsb OGP 4749 4644 RGNC1991_NEA74Noumea.gsb ESRI 4749 4662 RGNC1991_IGN72GrandeTerre.gsb ESRI 5524 4326 CA61_003.gsb OGP 5524 4674 CA61_003.gsb IBGE. 5527 4326 SAD96_003.gsb OGP 5527 4674 SAD96_003.gsb IBGE."},{"location":"configuration/crshandling/coordtransforms/#nadcon","title":"NADCON","text":"Source CRS Target CRS Version Latitude shift file Longitude shift file 4135 4269 NGS-Usa HI hawaii.las hawaii.los 4136 4269 NGS-Usa AK StL stlrnc.las stlrnc.los 4137 4269 NGS-Usa AK StP stpaul.las stpaul.los 4138 4269 NGS-Usa AK StG stgeorge.las stgeorge.los 4139 4269 NGS-PRVI prvi.las prvi.los 4169 4152 NGS-Asm E eshpgn.las eshpgn.los 4169 4152 NGS-Asm W wshpgn.las wshpgn.los 4267 4269 NGS-Usa AK alaska.las alaska.los 4267 4269 NGS-Usa Conus conus.las conus.los 4269 4152 NGS-Usa AL alhpgn.las alhpgn.los 4269 4152 NGS-Usa AR arhpgn.las arhpgn.los 4269 4152 NGS-Usa AZ azhpgn.las azhpgn.los 4269 4152 NGS-Usa CA n cnhpgn.las cnhpgn.los 4269 4152 NGS-Usa CO cohpgn.las cohpgn.los 4269 4152 NGS-Usa CA s cshpgn.las cshpgn.los 4269 4152 NGS-Usa ID MT e emhpgn.las emhpgn.los 4269 4152 NGS-Usa TX e ethpgn.las ethpgn.los 4269 4152 NGS-Usa FL flhpgn.las flhpgn.los 4269 4152 NGS-Usa GA gahpgn.las gahpgn.los 4269 4152 NGS-Usa HI hihpgn.las hihpgn.los 4269 4152 NGS-Usa IA iahpgn.las iahpgn.los 4269 4152 NGS-Usa IL ilhpgn.las ilhpgn.los 4269 4152 NGS-Usa IN inhpgn.las inhpgn.los 4269 4152 NGS-Usa KS kshpgn.las kshpgn.los 4269 4152 NGS-Usa KY kyhpgn.las kyhpgn.los 4269 4152 NGS-Usa LA lahpgn.las lahpgn.los 4269 4152 NGS-Usa DE MD mdhpgn.las mdhpgn.los 4269 4152 NGS-Usa ME mehpgn.las mehpgn.los 4269 4152 NGS-Usa MI mihpgn.las mihpgn.los 4269 4152 NGS-Usa MN mnhpgn.las mnhpgn.los 4269 4152 NGS-Usa MO mohpgn.las mohpgn.los 4269 4152 NGS-Usa MS mshpgn.las mshpgn.los 4269 4152 NGS-Usa NE nbhpgn.las nbhpgn.los 4269 4152 NGS-Usa NC nchpgn.las nchpgn.los 4269 4152 NGS-Usa ND ndhpgn.las ndhpgn.los 4269 4152 NGS-Usa NewEng nehpgn.las nehpgn.los 4269 4152 NGS-Usa NJ njhpgn.las njhpgn.los 4269 4152 NGS-Usa NM nmhpgn.las nmhpgn.los 4269 4152 NGS-Usa NV nvhpgn.las nvhpgn.los 4269 4152 NGS-Usa NY nyhpgn.las nyhpgn.los 4269 4152 NGS-Usa OH ohhpgn.las ohhpgn.los 4269 4152 NGS-Usa OK okhpgn.las okhpgn.los 4269 4152 NGS-Usa PA pahpgn.las pahpgn.los 4269 4152 NGS-PRVI pvhpgn.las pvhpgn.los 4269 4152 NGS-Usa SC schpgn.las schpgn.los 4269 4152 NGS-Usa SD sdhpgn.las sdhpgn.los 4269 4152 NGS-Usa TN tnhpgn.las tnhpgn.los 4269 4152 NGS-Usa UT uthpgn.las uthpgn.los 4269 4152 NGS-Usa VA vahpgn.las vahpgn.los 4269 4152 NGS-Usa WI wihpgn.las wihpgn.los 4269 4152 NGS-Usa ID MT w wmhpgn.las wmhpgn.los 4269 4152 NGS-Usa OR WA wohpgn.las wohpgn.los 4269 4152 NGS-Usa TX w wthpgn.las wthpgn.los 4269 4152 NGS-Usa WV wvhpgn.las wvhpgn.los 4269 4152 NGS-Usa WY wyhpgn.las wyhpgn.los 4675 4152 NGS-Gum guhpgn.las guhpgn.los 8351 4156 UGKK-Svk Slovakia_JTSK03_to_JTSK.LAS.las Slovakia_JTSK03_to_JTSK.LAS.los 8351 4156 UGKK-Svk Slovakia_JTSK03_to_JTSK.LOS.las Slovakia_JTSK03_to_JTSK.LOS.los"},{"location":"configuration/crshandling/coordtransforms/#define-a-custom-coordinate-operation","title":"Define a custom Coordinate Operation","text":"

          Custom Coordinate Operations are defined in epsg_operations.properties file. This file has to be placed into the user_projections directory, inside your data directory (create it if it doesn't exist).

          Each line in epsg_operations.properties will describe a coordinate operation consisting of a source CRS, a target CRS, and a math transform with its parameter values. Use the following syntax:

          <source crs code>,<target crs code>=<WKT math transform>\n

          Math transform is described in Well-Known Text syntax. Parameter names and value ranges are described in the EPSG Geodetic Parameter Registry.

          Note

          Use the Reprojection Console to learn from example and to test your custom definitions.

          "},{"location":"configuration/crshandling/coordtransforms/#examples","title":"Examples","text":"

          Custom NTv2 file:

          4230,4258=PARAM_MT[\"NTv2\", \\\n  PARAMETER[\"Latitude and longitude difference file\", \"100800401.gsb\"]]\n

          Geocentric transformation, preceded by an ellipsoid to geocentric conversion, and back geocentric to ellipsoid. The results is a concatenation of three math transforms:

          4230,4258=CONCAT_MT[ \\\n  PARAM_MT[\"Ellipsoid_To_Geocentric\", \\\n    PARAMETER[\"dim\", 2], \\\n    PARAMETER[\"semi_major\", 6378388.0], \\\n    PARAMETER[\"semi_minor\", 6356911.9461279465]], \\\n  PARAM_MT[\"Position Vector transformation (geog2D domain)\", \\\n    PARAMETER[\"dx\", -116.641], \\\n    PARAMETER[\"dy\", -56.931], \\\n    PARAMETER[\"dz\", -110.559], \\\n    PARAMETER[\"ex\", 0.8925078166311858], \\\n    PARAMETER[\"ey\", 0.9207660950870382], \\\n    PARAMETER[\"ez\", -0.9166407989620964], \\\n    PARAMETER[\"ppm\", -3.5200000000346066]], \\\n  PARAM_MT[\"Geocentric_To_Ellipsoid\", \\\n    PARAMETER[\"dim\", 2], \\\n    PARAMETER[\"semi_major\", 6378137.0], \\\n    PARAMETER[\"semi_minor\", 6356752.314140356]]]\n

          You can make use of existing grid shift files such as this explicit transformation from NAD27 to WGS84 made up of a NADCON transform from NAD27 to NAD83 followed by a Molodenski transform converting from the GRS80 Ellipsoid (used by NAD83) to the WGS84 Ellipsoid:

          4267,4326=CONCAT_MT[ \\\n  PARAM_MT[\"NADCON\", \\\n    PARAMETER[\"Latitude difference file\", \"conus.las\"], \\\n    PARAMETER[\"Longitude difference file\", \"conus.los\"]], \\\n  PARAM_MT[\"Molodenski\", \\\n    PARAMETER[\"dim\", 2], \\\n    PARAMETER[\"dx\", 0.0], \\\n    PARAMETER[\"dy\", 0.0], \\\n    PARAMETER[\"dz\", 0.0], \\\n    PARAMETER[\"src_semi_major\", 6378137.0], \\\n    PARAMETER[\"src_semi_minor\", 6356752.314140356], \\\n    PARAMETER[\"tgt_semi_major\", 6378137.0], \\\n    PARAMETER[\"tgt_semi_minor\", 6356752.314245179]]]\n

          Affine 2D transform operating directly in projected coordinates:

          23031,25831=PARAM_MT[\"Affine\", \\\n  PARAMETER[\"num_row\", 3], \\\n  PARAMETER[\"num_col\", 3], \\\n  PARAMETER[\"elt_0_0\", 1.0000015503712145], \\\n  PARAMETER[\"elt_0_1\", 0.00000758753979846734], \\\n  PARAMETER[\"elt_0_2\", -129.549], \\\n  PARAMETER[\"elt_1_0\", -0.00000758753979846734], \\\n  PARAMETER[\"elt_1_1\", 1.0000015503712145], \\\n  PARAMETER[\"elt_1_2\", -208.185]]\n

          Each operation can be described in a single line, or can be split in several lines for readability, adding a backslash \"\\\" at the end of each line, as in the former examples.

          "},{"location":"configuration/crshandling/customcrs/","title":"Custom CRS Definitions","text":""},{"location":"configuration/crshandling/customcrs/#add-a-custom-crs","title":"Add a custom CRS","text":"

          This example shows how to add a custom projection in GeoServer.

          1. The projection parameters need to be provided as a WKT (well known text) definition. The code sample below is just an example:

            PROJCS[\"NAD83 / Austin\",\n  GEOGCS[\"NAD83\",\n    DATUM[\"North_American_Datum_1983\",\n      SPHEROID[\"GRS 1980\", 6378137.0, 298.257222101],\n      TOWGS84[0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]],\n    PRIMEM[\"Greenwich\", 0.0],\n    UNIT[\"degree\", 0.017453292519943295],\n    AXIS[\"Lon\", EAST],\n    AXIS[\"Lat\", NORTH]],\n  PROJECTION[\"Lambert_Conformal_Conic_2SP\"],\n  PARAMETER[\"central_meridian\", -100.333333333333],\n  PARAMETER[\"latitude_of_origin\", 29.6666666666667],\n  PARAMETER[\"standard_parallel_1\", 31.883333333333297],\n  PARAMETER[\"false_easting\", 2296583.333333],\n  PARAMETER[\"false_northing\", 9842500.0],\n  PARAMETER[\"standard_parallel_2\", 30.1166666666667],\n  UNIT[\"m\", 1.0],\n  AXIS[\"x\", EAST],\n  AXIS[\"y\", NORTH],\n  AUTHORITY[\"EPSG\",\"100002\"]]\n

            Note

            This code sample has been formatted for readability. The information will need to be provided on a single line instead, or with backslash characters at the end of every line (except the last one).

          2. Go into the user_projections directory inside your data directory, and open the epsg.properties file. If this file doesn't exist, you can create it.

          3. Insert the code WKT for the projection at the end of the file (on a single line or with backslash characters):

            100002=PROJCS[\"NAD83 / Austin\", \\\n  GEOGCS[\"NAD83\", \\\n    DATUM[\"North_American_Datum_1983\", \\\n      SPHEROID[\"GRS 1980\", 6378137.0, 298.257222101], \\\n      TOWGS84[0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]], \\\n    PRIMEM[\"Greenwich\", 0.0], \\\n    UNIT[\"degree\", 0.017453292519943295], \\\n    AXIS[\"Lon\", EAST], \\\n    AXIS[\"Lat\", NORTH]], \\\n  PROJECTION[\"Lambert_Conformal_Conic_2SP\"], \\\n  PARAMETER[\"central_meridian\", -100.333333333333], \\\n  PARAMETER[\"latitude_of_origin\", 29.6666666666667], \\\n  PARAMETER[\"standard_parallel_1\", 31.883333333333297], \\\n  PARAMETER[\"false_easting\", 2296583.333333], \\\n  PARAMETER[\"false_northing\", 9842500.0], \\\n  PARAMETER[\"standard_parallel_2\", 30.1166666666667], \\\n  UNIT[\"m\", 1.0], \\\n  AXIS[\"x\", EAST], \\\n  AXIS[\"y\", NORTH], \\\n  AUTHORITY[\"EPSG\",\"100002\"]]\n

          Note

          Note the number that precedes the WKT. This will determine the EPSG code. So in this example, the EPSG code is 100002.

          1. Save the file.
          2. Restart GeoServer.
          3. Verify that the CRS has been properly parsed by navigating to the SRS List page in the Web administration interface.
          4. If the projection wasn't listed, examine the logs for any errors.
          "},{"location":"configuration/crshandling/customcrs/#override-an-official-epsg-code","title":"Override an official EPSG code","text":"

          In some situations it is necessary to override an official EPSG code with a custom definition. A common case is the need to change the TOWGS84 parameters in order to get better reprojection accuracy in specific areas.

          The GeoServer referencing subsystem checks the existence of another property file, epsg_overrides.properties, whose format is the same as epsg.properties. Any definition contained in epsg_overrides.properties will override the EPSG code, while definitions stored in epsg.proeprties can only add to the database.

          Special care must be taken when overriding the Datum parameters, in particular the TOWGS84 parameters. To make sure the override parameters are actually used the code of the Datum must be removed, otherwise the referencing subsystem will keep on reading the official database in search of the best Datum shift method (grid, 7 or 5 parameters transformation, plain affine transform).

          For example, if you need to override the official TOWGS84 parameters of EPSG:23031:

          PROJCS[\"ED50 / UTM zone 31N\", \n  GEOGCS[\"ED50\", \n    DATUM[\"European Datum 1950\", \n      SPHEROID[\"International 1924\", 6378388.0, 297.0, AUTHORITY[\"EPSG\",\"7022\"]], \n      TOWGS84[-157.89, -17.16, -78.41, 2.118, 2.697, -1.434, -1.1097046576093785],\n      AUTHORITY[\"EPSG\",\"6230\"]], \n    PRIMEM[\"Greenwich\", 0.0, AUTHORITY[\"EPSG\",\"8901\"]], \n    UNIT[\"degree\", 0.017453292519943295], \n    AXIS[\"Geodetic longitude\", EAST], \n    AXIS[\"Geodetic latitude\", NORTH], \n    AUTHORITY[\"EPSG\",\"4230\"]], \n PROJECTION[\"Transverse_Mercator\"], \n  PARAMETER[\"central_meridian\", 3.0], \n  PARAMETER[\"latitude_of_origin\", 0.0], \n  PARAMETER[\"scale_factor\", 0.9996], \n  PARAMETER[\"false_easting\", 500000.0], \n  PARAMETER[\"false_northing\", 0.0], \n  UNIT[\"m\", 1.0], \n  AXIS[\"Easting\", EAST], \n  AXIS[\"Northing\", NORTH], \n  AUTHORITY[\"EPSG\",\"23031\"]]\n

          You should write the following (in a single line, here it's reported formatted over multiple lines for readability):

          23031=\n PROJCS[\"ED50 / UTM zone 31N\", \n   GEOGCS[\"ED50\", \n     DATUM[\"European Datum 1950\", \n       SPHEROID[\"International 1924\", 6378388.0, 297.0, AUTHORITY[\"EPSG\",\"7022\"]], \n       TOWGS84[-136.65549, -141.4658, -167.29848, 2.093088, 0.001405, 0.107709, 11.54611], \n       AUTHORITY[\"EPSG\",\"6230\"]], \n     PRIMEM[\"Greenwich\", 0.0, AUTHORITY[\"EPSG\",\"8901\"]], \n     UNIT[\"degree\", 0.017453292519943295], \n     AXIS[\"Geodetic longitude\", EAST], \n     AXIS[\"Geodetic latitude\", NORTH]], \n  PROJECTION[\"Transverse_Mercator\"], \n   PARAMETER[\"central_meridian\", 3.0], \n   PARAMETER[\"latitude_of_origin\", 0.0], \n   PARAMETER[\"scale_factor\", 0.9996], \n   PARAMETER[\"false_easting\", 500000.0], \n   PARAMETER[\"false_northing\", 0.0], \n   UNIT[\"m\", 1.0], \n   AXIS[\"Easting\", EAST], \n   AXIS[\"Northing\", NORTH], \n   AUTHORITY[\"EPSG\",\"23031\"]]\n

          The definition has been changed in two places, the TOWGS84 paramerers, and the Datum code, AUTHORITY[\"EPSG\",\"4230\"], has been removed.

          "},{"location":"configuration/crshandling/manualepsg/","title":"Manually editing the EPSG database","text":"

          Warning

          These instructions are very advanced, and are here mainly for the curious who want to know details about the EPSG database subsystem.

          To define a custom projection, edit the EPSG.sql file, which is used to create the cached EPSG database.

          1. Navigate to the WEB-INF/lib directory

          2. Uncompress the gt2-epsg-h.jar file. On Linux, the command is:

            jar xvf gt2-epsg-h.jar\n
          3. Open org/geotools/referencing/factory/epsg/EPSG.sql with a text editor. To add a custom projection, these entries are essential:

            1. An entry in the EPSG_COORDINATEREFERENCESYSTEM table:

              (41111,'WGC 84 / WRF Lambert',1324,'projected',4400,NULL,4326,20000,NULL,NULL,'US Nat. scale mapping.','Entered by Alex Petkov','Missoula Firelab WRF','WRF','2000-10-19','',1,0),\n

              where:

              • 1324 is the EPSG_AREA code that describes the area covered by my projection
              • 4400 is the EPSG_COORDINATESYSTEM code for my projection
              • 20000 is the EPSG_COORDOPERATIONPARAMVALUE key for the array that contains my projection parameters
            2. An entry in the EPSG_COORDOPERATIONPARAMVALUE table:

              (20000,9802,8821,40,'',9102),    //latitude of origin\n(20000,9802,8822,-97.0,'',9102), //central meridian\n(20000,9802,8823,33,'',9110),    //st parallel 1\n(20000,9802,8824,45,'',9110),    //st parallel 2\n(20000,9802,8826,0.0,'',9001),   //false easting\n(20000,9802,8827,0.0,'',9001)    //false northing\n

              where:

              • 9802 is the EPSG_COORDOPERATIONMETHOD key for the Lambert Conic Conformal (2SP) formula
            3. An entry in the EPSG_COORDOPERATION table:

              (20000,'WRF Lambert','conversion',NULL,NULL,'',NULL,1324,'Used for weather forecasting.',0.0,9802,NULL,NULL,'Used with the WRF-Chem model for weather forecasting','Firelab in Missoula, MT','EPSG','2005-11-23','2005.01',1,0)

              where:

              • 1324 is the EPSG_AREA code that describes the area covered by my projection
              • 9802 is the EPSG_COORDOPERATIONMETHOD key for the Lambert Conic Conformal (2SP) formula

          Note

          Observe the commas. If you enter a line that is at the end of an INSERT statement, the comma is omitted (make sure the row before that has a comma at the end). Otherwise, add a comma at the end of your entry.

          1. After all edits, save the file and exit.

          2. Compress the gt2-epsg-h.jar file. On Linux, the command is:

            jar -Mcvf gt2-epsg-h.jar META-INF org\n
          3. Remove the cached copy of the EPSG database, so that can be recreated. On Linux, the command is:

            rm -rf /tmp/Geotools/Databases/HSQL\n
          4. Restart GeoServer.

          The new projection will be successfully parsed. Verify that the CRS has been properly parsed by navigating to the SRS List page in the Web administration interface.

          "},{"location":"configuration/demos/","title":"Demos","text":"

          This page contains helpful links to various information pages regarding GeoServer and its features. You do not need to be logged into GeoServer to access this page.

          The page contains the following options

          • Demo Requests
          • SRS List
          • Reprojection console
          • WCS Request Builder

          Demos page

          If you have the WPS extension installed, you will see an additional option:

          • WPS Request Builder

          Demos page with WPS extension installed

          "},{"location":"configuration/demos/#demos_demorequests","title":"Demo Requests","text":"

          This page has example WMS, WCS, and WFS requests for GeoServer that you can use, examine, and change. Select a request from the drop down list.

          Selecting demo requests

          Both Web Feature Service (WFS) as well as Web Coverage Service (WCS) requests will display the request URL and the XML body. Web Map Service (WMS) requests will only display the request URL.

          WFS 1.1 DescribeFeatureType sample request

          Click Submit to send the request to GeoServer. For WFS and WCS requests, GeoServer will automatically generate an XML response.

          XML response from a WFS 1.1 DescribeFeatureType sample request

          Submitting a WMS GetMap request displays an image based on the provided geographic data.

          OpenLayers WMS GetMap request

          WMS GetFeatureInfo requests retrieve information regarding a particular feature on the map image.

          WMS GetFeatureInfo request

          "},{"location":"configuration/demos/#srs_list","title":"SRS List","text":"

          GeoServer natively supports almost 4,000 Spatial Referencing Systems (SRS), also known as projections, and more can be added. A spatial reference system defines an ellipsoid, a datum using that ellipsoid, and either a geocentric, geographic or projection coordinate system. This page lists all SRS info known to GeoServer.

          Listing of all Spatial Referencing Systems (SRS) known to GeoServer

          The Code column refers to the unique integer identifier defined by the author of that spatial reference system. Each code is linked to a more detailed description page, accessed by clicking on that code.

          Details for SRS EPSG:2000

          The title of each SRS is composed of the author name and the unique integer identifier (code) defined by the Author. In the above example, the author is the European Petroleum Survey Group (EPSG) and the Code is 2000. The fields are as follows:

          Description---A short text description of the SRS

          WKT---A string describing the SRS. WKT stands for \"Well Known Text\"

          Area of Validity---The bounding box for the SRS

          "},{"location":"configuration/demos/#demos_reprojectionconsole","title":"Reprojection console","text":"

          The reprojection console allows you to calculate and test coordinate transformation. You can input a single coordinate or WKT geometry, and transform it from one CRS to another.

          For example, you can use the reprojection console to transform a bounding box (as a WKT polygon or line) between different CRSs.

          Reprojection console showing a transformed bounding box

          Use Forward transformation to convert from source CRS to target CRS, and Backward transformation to convert from target CRS to source CRS.

          You can also view the underlying calculation GeoServer is using to perform the transformation.

          Reprojection console showing operation details

          Read more about Coordinate Reference System Handling.

          "},{"location":"configuration/demos/#demos_wcsrequestbuilder","title":"WCS Request Builder","text":"

          The WCS Request Builder is a tool for generating and executing WCS requests. Since WCS requests can be cumbersome to author, this tool can make working with WCS much easier.

          Read more about the WCS Request Builder.

          "},{"location":"configuration/demos/#demos_wpsrequestbuilder","title":"WPS Request Builder","text":"

          GeoServer with the WPS extension installed includes a request builder for generating and executing WPS processes. Since WPS requests can be cumbersome to author, this tool can make working with WPS much easier.

          Read more about the WPS Request Builder.

          "},{"location":"configuration/image_processing/","title":"Image Processing","text":"

          Java Advanced Imaging (JAI) is an image processing library built by Sun Microsystems. JAI Image I/O Tools provides reader, writer, and stream plug-ins for the standard Java Image I/O Framework.

          Several JAI parameters, used by both WMS and WCS operations, can be configured in the Image Processing page.

          Image Processing

          "},{"location":"configuration/image_processing/#memory-tiling","title":"Memory & Tiling","text":"

          When supporting large images it is efficient to work on image subsets without loading everything to memory. A widely used approach is tiling which basically builds a tessellation of the original image so that image data can be read in parts rather than whole. Since very often processing one tile involves surrounding tiles, tiling needs to be accompanied by a tile-caching mechanism. The following JAI parameters allow you to manage the JAI cache mechanism for optimized performance.

          Memory Capacity---For memory allocation for tiles, JAI provides an interface called TileCache. Memory Capacity sets the global JAI TileCache as a percentage of the available heap. A number between 0 and 1 exclusive. If the Memory Capacity is smaller than the current capacity, the tiles in the cache are flushed to achieve the desired settings. If you set a large amount of memory for the tile cache, interactive operations are faster but the tile cache fills up very quickly. If you set a low amount of memory for the tile cache, the performance degrades.

          Memory Threshold---Sets the global JAI TileCache Memory threshold. Refers to the fractional amount of cache memory to retain during tile removal. JAI Memory Threshold value must be between 0.0 and 1.0. The Memory Threshold visible on the Status page.

          Tile Threads---JAI utilizes a TileScheduler for tile calculation. Tile computation may make use of multithreading for improved performance. The Tile Threads parameter sets the TileScheduler, indicating the number of threads to be used when loading tiles.

          Tile Threads Priority---Sets the global JAI Tile Scheduler thread priorities. Values range from 1 (Min) to 10 (Max), with default priority set to 5 (Normal).

          Tile Recycling---Enable/Disable JAI Cache Tile Recycling. If selected, Tile Recycling allows JAI to re-use already loaded tiles, which can provide significant performance improvement.

          Native Acceleration---To improve the computation speed of image processing applications, the JAI comes with both Java Code and native code for many platform. If the Java Virtual Machine (JVM) finds the native code, then that will be used. If the native code is not available, the Java code will be used. As such, the JAI package is able to provide optimized implementations for different platforms that can take advantage of each platform's capabilities.

          JPEG Native Acceleration---Enables/disable JAI JPEG Native Acceleration. When selected, enables JPEG native code, which may speed performance, but compromise security and crash protection.

          PNG Encoder Type---Provides a selection of the PNG encoder between the Java own encoder, the JAI ImageIO native one, and a PNGJ based one:

          • The Java standard encoder is always set to maximum compression. It provides the smallest output images, balanced by a high performance cost (up to six times slower than the other two alternatives).
          • The ImageIO native encoder, available only when the ImageIO native extensions are installed, provided higher performance, but also generated significantly larger PNG images
          • The PNGJ based encoder provides the best performance and generated PNG images that are just slightly larger than the Java standard encoder. It is the recommended choice, but it's also newer than the other two, so in case of misbehavior the other two encoders are left as an option for the administrator.

          Mosaic Native Acceleration---To reduce the overhead of handling them, large data sets are often split into smaller chunks and then combined to create an image mosaic. An example of this is aerial imagery which usually comprises thousands of small images at very high resolution. Both native and JAI implementations of mosaic are provided. When selected, Mosaic Native Acceleration use the native implementation for creating mosaics.

          Warp Native Acceleration---Also for the Warp operation are provided both native and JAI implementations. If the checkbox is enabled, then the native operation is used for the warp operation.

          It is quite important to remember that faster encoders are not necessarily going to visibly improve performance, if data loading and processing/rendering are dominating the response time, choosing a better encoder will likely not provide the expected benefits.

          "},{"location":"configuration/image_processing/#JAIEXT","title":"JAI-EXT","text":"

          The JAI-EXT library is open-source project which aims to replace closed source JAI project provided by Sun. The main difference between JAI and JAI-EXT operations is the support for external Region of Interests (ROI) and image NoData in JAI-EXT.

          The following panel is be available at the bottom of the JAI Settings page

          JAI/JAIEXT Setup panel

          This panel can be used to selectively enable/disable JAI-EXT operations in favor of JAI ones.

          By default, JAI-EXT operations are enabled. In case of misbehavior add the following java option to GeoServer startup script and restart GeoServer to disable them.

          -Dorg.geotools.coverage.jaiext.enabled=false

          Warning

          Users should take care that JAI native libraries are not supported by JAI-EXT, since JAI-EXT is a pure Java API.

          "},{"location":"configuration/internationalization/","title":"Internationalization (i18n)","text":"

          GeoServer supports returning a GetCapabilities document in various languages. The functionality is available for the following services:

          • WMS 1.1 and 1.3
          • WFS 2.0
          • WCS 2.0
          "},{"location":"configuration/internationalization/#configuration","title":"Configuration","text":"

          GeoServer provides an i18n editor for the title and abstract of:

          • Layers configuration page.
          • Layergroups configuration page.
          • WMS, WFS, WCS service configuration pages.
          • For Styles i18n configuration see i18N in SLD.

          The editor is disabled by default and can be enabled from the i18n checkbox:

          In the Contact Information page all the fields can be internationalized:

          "},{"location":"configuration/internationalization/#service-getcapabilities","title":"Service GetCapabilities","text":"

          The GetCapabilities document language can be selected using the AcceptLanguages request parameter. The GeoServer response will vary based on the following rules:

          • The internationalized elements will be titles, abstracts and keywords.

          • If a single language code is specified, e.g. AcceptLanguages=en GeoServer will try to return the content in that language.

            If no content is found in the requested language a ServiceExceptionReport will be returned.

          • If multiple language codes are specified, e.g. AcceptLanguages=en fr or AcceptLanguages=en,fr, for each internationalizable content GeoServer will try to return it in one of the specified language.

            If no content is found for any of the requested languages ServiceExceptionReport will be returned.

          • Languages can be configured and requested also according to local language variants (e.g. AcceptLanguages=en fr-CA or AcceptLanguages=en,fr-CA).

            If any i18n content has been specified with a local variant and the request parameters specifies only the language code the content will be encoded in the response. Keep in mind that the inverse situation content is recorded using a language code will not be available for local variant requests.

            Example: If the i18n content is specified with the local variant fr-CA and the requested only specifies a language code AcceptLanguages=fr` the local variantfr-CAcontent will be used. Example: If the i18n content is specified with the language codefrand the requested only specifies the local variantAcceptLanguages=fr-CAthe language codefr` content is unavailable.

          • If a * is present among the parameter values, e.g. AcceptLanguages=en fr * or AcceptLanguages=en,fr,*, GeoServer will try to return the content in one of the specified language code.

            If no content is found content will be returned in a language among those available.

          • If not all the configurable elements have i18n title and abstract available for the requested language, GeoServer will encode those attributes only for services, layers, layergroups and styles that have them defined.

            In case the missing value is the tile, in place of the missing internationalized content an error message like the following, will appear: DID NOT FIND i18n CONTENT FOR THIS ELEMENT.

          • When using AcceptLanguages parameter GeoServer will encode URL present in the response adding language parameter with the first value retrieved from the AcceptLanguages parameter.

          "},{"location":"configuration/internationalization/#default-language","title":"Default Language","text":"

          GeoServer allows defining a default language to be used when international content has been set in services', layers' and groups' configuration pages, but no AcceptLanguages parameter has been specified in a GetCapabilities request. The default language can be set from the services' configuration pages (WMS, WFS, WCS) or from global settings from a dropdown as shown below:

          It is also possible to set an i18n entry with empty language for each configurable field, acting as the default translation.

          When international content is requested, for each internationalized field, GeoServer will behave as follows:

          • The service specific default language, if present, will be used.
          • If not found, the global default language, if present, will be used.
          • If not found the i18n content empty language value, if present, will be used.
          • If not found the first i18n value found for the field will be used.
          "},{"location":"configuration/service-metadata/","title":"Service Metadata","text":"

          Open Web Services (WCS, WFS, WMS, and WPS) use common metadata definitions to describe the service offered and indicate any restrictions on use.

          WMS Service Metadata

          These elements are described in the following table. Though these field types are the same regardless of service, their values are not shared. As such, parameter definitions below refer to the respective service. For example, enable on the WFS Service page, enables WFS service requests and has no effect on WCS or WMS requests.

          Field Description

          Enabled Specifies whether the respective services --WCS, WFS or WMS-- should be enabled or disabled. When disabled, the respective service requests will not be processed.

          Strict CITE compliance When selected, enforces strict OGC Compliance and Interoperability Testing Initiative (CITE) conformance. Recommended for use when running conformance tests.

          Maintainer Name of the responsible party (organization, company, or person) that maintains the service instance.

          Online Resource Defines the top-level HTTP URL of the service. Typically the Online Resource is the URL of the service \"home page.\" (Required)

          Title A human-readable title to briefly identify this service in menus to clients. (Required)

          Abstract Provides a descriptive narrative with more information about the service.

          Fees Indicates any fees imposed by the service provider for usage of the service. The keyword NONE is reserved to mean no fees and fits most cases.

          Access Constraints Describes any constraints imposed by the service provider on the service. The keyword NONE is reserved to indicate no access constraints are imposed and fits most cases.

          Keywords List of terms that are associated with the service to aid in cataloging and searching.

          "},{"location":"configuration/tools/","title":"Tools","text":"

          This page contains helpful tools for administrators to manage or automate configuration. You need to be logged into GeoServer to access this page.

          • Bulk Load tool
          • Resource Browser tool
          "},{"location":"configuration/tools/bulk/","title":"Bulk Load tool","text":"

          The Catalog Bulk Load Tool is used to duplicate GeoServer configuration (workspaces, stores, layers) for testing. The tool can also be used to make a single duplicate for experimenting with configuration and optimization.

          Catalog Bulk Load Tool

          "},{"location":"configuration/tools/bulk/#duplicating-configuration","title":"Duplicating Configuration","text":"
          1. Navigate to Tools \u2192 Catalog Bulk Load Tool
          2. Select the item to copy:
            • Workspace and Namespace
            • Store
            • Resource and Layer
          3. Fill in the # of times to duplicate.
          4. Provide a Suffix to append
          5. Choose to recursively copy:
            • Recursively copying a workspace will duplicate all stores and layers contained in the workspace
            • Recursively copying a store will copy all layers published by the store
          6. Press Start to begin duplicating
          "},{"location":"configuration/tools/resource/","title":"Resource Browser tool","text":"

          Tools page to manage data directory resources including icons, fonts, and configuration files.

          • Installing the GeoServer Web Resource extension
          • Resource Browser
          • Resource Browser Examples
          "},{"location":"configuration/tools/resource/browser/","title":"Resource Browser","text":"

          The Resource Browser provides a tree showing configuration folders, along with actions to edit and manage resources.

          Resource Browser

          User interface elements:

          • Resource tree is used to explore configuration folders and resource items.

          • Upload uploads files to GeoServer. Select a directory to enable this tool.

            Upload a resource

          • Download is used to download a selected resource from GeoServer as a file.

          • New resource creates a new text file in the selected directory. The Edit Resource dialog is used to record the resource location, and the contents.

            Edit a Resource (New File)

          • Edit a selected resource.

            Edit a Resource (Existing File)

          • Use Cut, Copy, and Paste to move resources between folders.

            Paste a Resource

          • Rename to rename a selected resource.

            Rename a Resource

          • Delete to remove a selected resource.

            Delete a resource

          "},{"location":"configuration/tools/resource/browser/#before-you-start","title":"Before you start","text":"

          The resource browser is used to manage configuration resources in environments that do not provide direct disk access:

          • When running GeoServer on a remote machine it can be difficult mange the icons and fonts used for effective styling
          • Some cloud deployments of GeoServer operate without a data directory. In these environments the resource browser is used to manage items stored in a database or cloud storage rather than a file system.
          • Folders are visual only, when creating or uploading a resource you can type a path and folders will be created as needed.

          Warning

          Please use this tool with caution:

          • Configuration files managed by the web administration application can be reviewed and even modified using this tool.
          • It is not advised to edit these files directly as GeoServer must reload its Catalog to notice these changes.
          "},{"location":"configuration/tools/resource/examples/","title":"Resource Browser Examples","text":""},{"location":"configuration/tools/resource/examples/#uploading-an-icon-to-a-styles-folder","title":"Uploading an icon to a styles folder","text":"

          To upload a file to the global styles folder:

          1. Use Resource Browser to select / \u2192 styles in the resource tree.

            Resource Browser styles folder

          2. Click Upload button to open Upload a Resource dialog.

          3. Use Browse to select a file from the local file system.

            Upload icon to styles folder

          4. Press OK to upload the file.

            Resource Browser icon

          "},{"location":"configuration/tools/resource/examples/#creating-a-control-flow-configuration-file","title":"Creating a control-flow configuration file","text":"

          Many extensions, such as Control flow module, are managed using a configuration file.

          To create a controlflow.properties file:

          1. Use Resource Browser to select the root / folder in the resource tree.

            This can be tricky as the label is not very long.

            Resource Browser root folder

          2. Click New resource button to open Edit a Resource dialog.

            • Resource: controlflow.properties

            • Content: file contents

              {% \n  include \"../../../extensions/controlflow/controlflow.properties\"\n%}\n
          3. Press OK to create the resource.

            Edit a Resource controlflow.properties

          "},{"location":"configuration/tools/resource/install/","title":"Installing the GeoServer Web Resource extension","text":"

          The Resource Brower tool is provided by the web-resource extension is listed on the GeoServer download page.

          To install web-resource extension:

          1. From the GeoServer Download page locate the release used and download: web-resource

            Verify that the version number in the filename corresponds to the version of GeoServer you are running (for example 2.24.2 above).

          2. Extract the contents of the archive into the WEB-INF/lib directory in GeoServer.

            This extension includes two jars.

          3. Restart GeoServer.

          4. To confirm successful installation, navigate to Tools page and confirm the availability of Resource Browser tool.

          "},{"location":"data/","title":"Data management","text":"

          GeoServer connects to and publishes data from a wide variety of sources. This section will discuss how to use the GeoServer web interface to accomplish most common tasks, along with the different data formats served by GeoServer.

          Note

          There are many more data sources available through Extensions and Community modules. If you are looking for a specific data format and not finding it here, please check those sections.

          • Data settings
          • Vector data
          • Raster data
          • Databases
          • Cascaded service data
          • Application schemas
          "},{"location":"data/app-schema/","title":"Application schemas","text":"

          The application schema support (app-schema) extension provides support for app-schema.complex-features in GeoServer WFS.

          Note

          You must install the app-schema plugin to use Application Schema Support.

          GeoServer provides support for a broad selection of simple feature data stores, including property files, shapefiles, and JDBC data stores such as PostGIS and Oracle Spatial. The app-schema module takes one or more of these simple feature data stores and applies a mapping to convert the simple feature types into one or more complex feature types conforming to a GML application schema.

          Three tables in a database are accessed using GeoServer simple feature support and converted into two complex feature types.

          The app-schema module looks to GeoServer just like any other data store and so can be loaded and used to service WFS requests. In effect, the app-schema data store is a wrapper or adapter that converts a simple feature data store into complex features for delivery via WFS. The mapping works both ways, so queries against properties of complex features are supported.

          • Complex Features
          • Installation
          • WFS Service Settings
          • Configuration
          • Mapping File
          • Application Schema Resolution
          • Supported GML Versions
          • Secondary Namespaces
          • CQL functions
          • Property Interpolation
          • Data Stores
          • Feature Chaining
          • Polymorphism
          • Data Access Integration
          • WMS Support
          • WFS 2.0 Support
          • Joining Support For Performance
          • Tutorial
          • MongoDB Tutorial
          • Apache Solr Tutorial
          "},{"location":"data/app-schema/app-schema-resolution/","title":"Application Schema Resolution","text":"

          To be able to encode XML responses conforming to a GML application schema, the app-schema plugin must be able to locate the application schema files (XSDs) that define the schema. This page describes the schema resolution process.

          "},{"location":"data/app-schema/app-schema-resolution/#schema-downloading-is-now-automatic-for-most-users","title":"Schema downloading is now automatic for most users","text":"

          GeoServer will automatically download and cache (see Cache below) all the schemas it needs the first time it starts if:

          1. All the application schemas you use are accessed via http/https URLs, and
          2. Your GeoServer instance is deployed on a network that permits it to download them.

          Note

          This is the recommended way of using GeoServer app-schema for most users.

          If cached downloading is used, no manual handling of schemas will be required. The rest of this page is for those with more complicated arrangements, or who wish to clear the cache.

          "},{"location":"data/app-schema/app-schema-resolution/#resolution-order","title":"Resolution order","text":"

          The order of sources used to resolve application schemas is:

          1. OASIS Catalog
          2. Classpath
          3. Cache

          Every attempt to load a schema works down this list, so imports can be resolved from sources other than that used for the originating document. For example, an application schema in the cache that references a schema found in the catalog will use the version in the catalog, rather than caching it. This allows users to supply unpublished or modified schemas sourced from, for example, the catalog, at the cost of interoperability (how do WFS clients get them?).

          "},{"location":"data/app-schema/app-schema-resolution/#oasis-catalog","title":"OASIS Catalog","text":"

          An OASIS XML Catalog is a standard configuration file format that instructs an XML processing system how to process entity references. The GeoServer app-schema resolver uses catalog URI semantics to locate application schemas, so uri or rewriteURI entries should be present in your catalog. The optional mapping file catalog element provides the location of the OASIS XML Catalog configuration file, given as a path relative to the mapping file, for example:

          <catalog>../../../schemas/catalog.xml</catalog>\n

          Earlier versions of the app-schema plugin required all schemas to be present in the catalog. This is no longer the case. Because the catalog is searched first, existing catalog-based deployments will continue to work as before.

          To migrate an existing GeoServer app-schema deployment that uses an OASIS Catalog to instead use cached downloads (see Cache below), remove all catalog elements from your mapping files and restart GeoServer.

          "},{"location":"data/app-schema/app-schema-resolution/#classpath","title":"Classpath","text":"

          Java applications such as GeoServer can load resources from the Java classpath. GeoServer app-schema uses a simple mapping from an http or https URL to a classpath resource location. For example, an application schema published at http://schemas.example.org/exampleml/exml.xsd would be found on the classpath if it was stored either:

          • at /org/example/schemas/exampleml/exml.xsd in a JAR file on the classpath (for example, a JAR file in WEB-INF/lib) or,
          • on the local filesystem at WEB-INF/classes/org/example/schemas/exampleml/exml.xsd .

          The ability to load schemas from the classpath is intended to support testing, but may be useful to users whose communities supply JAR files containing their application schemas.

          "},{"location":"data/app-schema/app-schema-resolution/#app-schema-cache","title":"Cache","text":"

          If an application schema cannot be found in the catalog or on the classpath, it is downloaded from the network and stored in a subdirectory app-schema-cache of the GeoServer data directory.

          • Once schemas are downloaded into the cache, they persist indefinitely, including over GeoServer restarts.
          • No attempt will be made to retrieve new versions of cached schemas.
          • To clear the cache, remove the subdirectory app-schema-cache of the GeoServer data directory and restart GeoServer.

          GeoServer app-schema uses a simple mapping from an http or https URL to local filesystem path. For example, an application schema published at http://schemas.example.org/exampleml/exml.xsd would be downloaded and stored as app-schema-cache/org/example/schemas/exampleml/exml.xsd . Note that:

          • Only http and https URLs are supported.
          • Port numbers, queries, and fragments are ignored.

          If your GeoServer instance is deployed on a network whose firewall rules prevent outgoing TCP connections on port 80 (http) or 443 (https), schema downloading will not work. (For security reasons, some service networks [\"demilitarised zones\"] prohibit such outgoing connections.) If schema downloading is not permitted on your network, there are three solutions:

          1. Either: Install and configure GeoServer on another network that can make outgoing TCP connections, start GeoServer to trigger schema download, and then manually copy the app-schema-cache directory to the production server. This is the easiest option because GeoServer automatically downloads all the schemas it needs, including dependencies.
          2. Or: Deploy JAR files containing all required schema files on the classpath (see Classpath above).
          3. Or: Use a catalog (see OASIS Catalog above).

          Warning

          System property \"schema.cache.dir\" with a cache directory location is required for using a mapping file from a remote URL with 'http://' or 'https://' protocol.

          "},{"location":"data/app-schema/complex-features/","title":"Complex Features","text":"

          To understand complex features, and why you would want use them, you first need to know a little about simple features.

          "},{"location":"data/app-schema/complex-features/#simple-features","title":"Simple features","text":"

          A common use of GeoServer WFS is to connect to a data source such as a database and access one or more tables, where each table is treated as a WFS simple feature type. Simple features contain a list of properties that each have one piece of simple information such as a string or number. (Special provision is made for geometry objects, which are treated like single items of simple data.) The Open Geospatial Consortium (OGC) defines three Simple Feature profiles; SF-0, SF-1, and SF-2. GeoServer simple features are close to OGC SF-0, the simplest OGC profile.

          GeoServer WFS simple features provide a straightforward mapping from a database table or similar structure to a \"flat\" XML representation, where every column of the table maps to an XML element that usually contains no further structure. One reason why GeoServer WFS is so easy to use with simple features is that the conversion from columns in a database table to XML elements is automatic. The name of each element is the name of the column, in the namespace of the data store. The name of the feature type defaults to the name of the table. GeoServer WFS can manufacture an XSD type definition for every simple feature type it serves. Submit a DescribeFeatureType request to see it.

          "},{"location":"data/app-schema/complex-features/#benefits-of-simple-features","title":"Benefits of simple features","text":"
          • Easy to implement
          • Fast
          • Support queries on properties, including spatial queries on geometries
          "},{"location":"data/app-schema/complex-features/#drawbacks-of-simple-features","title":"Drawbacks of simple features","text":"
          • When GeoServer automatically generates an XSD, the XML format is tied to the database schema.
          • To share data with GeoServer simple features, participants must either use the same database schema or translate between different schemas.
          • Even if a community could agree on a single database schema, as more data owners with different data are added to a community, the number of columns in the table becomes unmanageable.
          • Interoperability is difficult because simple features do not allow modification of only part of the schema.
          "},{"location":"data/app-schema/complex-features/#simple-feature-example","title":"Simple feature example","text":"

          For example, if we had a database table stations containing information about GPS stations:

          | id | code |      name      |         location         |\n+----+------+----------------+--------------------------+\n| 27 | ALIC | Alice Springs  | POINT(133.8855 -23.6701) |\n| 4  | NORF | Norfolk Island | POINT(167.9388 -29.0434) |\n| 12 | COCO | Cocos          | POINT(96.8339 -12.1883)  |\n| 31 | ALBY | Albany         | POINT(117.8102 -34.9502) |\n

          GeoServer would then be able to create the following simple feature WFS response fragment:

          <gps:stations gml:id=\"stations.27\">\n    <gps:code>ALIC</gps:code>\n    <gps:name>Alice Springs</gps:name>\n    <gps:location>\n        <gml:Point srsName=\"urn:x-ogc:def:crs:EPSG:4326\">\n            <gml:pos>-23.6701 133.8855</gml:pos>\n        </gml:Point>\n    </gps:location>\n</gps:stations>\n
          • Every row in the table is converted into a feature.
          • Every column in the table is converted into an element, which contains the value for that row.
          • Every element is in the namespace of the data store.
          • Automatic conversions are applied to some special types like geometries, which have internal structure, and include elements defined in GML.
          "},{"location":"data/app-schema/complex-features/#complex-features_1","title":"Complex features","text":"

          Complex features contain properties that can contain further nested properties to arbitrary depth. In particular, complex features can contain properties that are other complex features. Complex features can be used to represent information not as an XML view of a single table, but as a collection of related objects of different types.

          Simple feature Complex feature Properties are single data item, e.g. text, number, geometry Properties can be complex, including complex features XML view of a single table Collection of related identifiable objects Schema automatically generated based on database Schema agreed by community One large type Multiple different types Straightforward Richly featured data standards Interoperability relies on simplicity and customisation Interoperability through standardization"},{"location":"data/app-schema/complex-features/#benefits-of-complex-features","title":"Benefits of complex features","text":"
          • Can define information model as an object-oriented structure, an application schema.
          • Information is modelled not as a single table but as a collection of related objects whose associations and types may vary from feature to feature (polymorphism), permitting rich expression of content.
          • By breaking the schema into a collection of independent types, communities need only extend those types they need to modify. This simplifies governance and permits interoperability between related communities who can agree on common base types but need not agree on application-specific subtypes..
          "},{"location":"data/app-schema/complex-features/#drawbacks-of-complex-features","title":"Drawbacks of complex features","text":"
          • More complex to implement
          • Complex responses might slower if more database queries are required for each feature.
          • Information modelling is required to standardize an application schema. While this is beneficial, it requires effort from the user community.
          "},{"location":"data/app-schema/complex-features/#complex-feature-example","title":"Complex feature example","text":"

          Let us return to our stations table and supplement it with a foreign key gu_id that describes the relationship between the GPS station and the geologic unit to which it is physically attached:

          | id | code |      name      |         location         | gu_id |\n+----+------+----------------+--------------------------+-------+\n| 27 | ALIC | Alice Springs  | POINT(133.8855 -23.6701) | 32785 |\n| 4  | NORF | Norfolk Island | POINT(167.9388 -29.0434) | 10237 | \n| 12 | COCO | Cocos          | POINT(96.8339 -12.1883)  | 19286 |\n| 31 | ALBY | Albany         | POINT(117.8102 -34.9502) | 92774 |\n

          The geologic unit is stored in the table geologicunit:

          | gu_id |                       urn             |         text        |\n+-------+---------------------------------------+---------------------+\n| 32785 | urn:x-demo:feature:GeologicUnit:32785 | Metamorphic bedrock |\n...\n

          The simple features approach would be to join the stations table with the geologicunit table into one view and then deliver \"flat\" XML that contained all the properties of both. The complex feature approach is to deliver the two tables as separate feature types. This allows the relationship between the entities to be represented while preserving their individual identity.

          For example, we could map the GPS station to a sa:SamplingPoint with a gsml:GeologicUnit. The these types are defined in the following application schemas respectively:

          • http://schemas.opengis.net/sampling/1.0.0/sampling.xsd

            • Documentation: OGC 07-002r3: http://portal.opengeospatial.org/files/?artifact_id=22467
          • http://www.geosciml.org/geosciml/2.0/xsd/geosciml.xsd

            • Documentation: http://www.geosciml.org/geosciml/2.0/doc/

          The complex feature WFS response fragment could then be encoded as:

          <sa:SamplingPoint gml:id=\"stations.27>\n  <gml:name codeSpace=\"urn:x-demo:SimpleName\">Alice Springs</gml:name>\n  <gml:name codeSpace=\"urn:x-demo:IGS:ID\">ALIC</gml:name>\n  <sa:sampledFeature>\n     <gsml:GeologicUnit gml:id=\"geologicunit.32785\">\n         <gml:description>Metamorphic bedrock</gml:description>\n         <gml:name codeSpace=\"urn:x-demo:Feature\">urn:x-demo:feature:GeologicUnit:32785</gml:name>\n     </gsml:GeologicUnit>\n  </sa:sampledFeature>\n  <sa:relatedObservation xlink:href=\"urn:x-demo:feature:GeologicUnit:32785\" />\n  <sa:position>\n      <gml:Point srsName=\"urn:x-ogc:def:crs:EPSG:4326\">\n          <gml:pos>-23.6701 133.8855</gml:pos>\n      </gml:Point>\n  </sa:position>\n</sa:SamplingPoint>\n
          • The property sa:sampledFeature can reference any other feature type, inline (included in the response) or by reference (an xlink:href URL or URN). This is an example of the use of polymorphism.
          • The property sa:relatedObservation refers to the same GeologicUnit as sa:sampledFeature, but by reference.
          • Derivation of new types provides an extension point, allowing information models to be reused and extended in a way that supports backwards compatibility.
          • Multiple sampling points can share a single GeologicUnit. Application schemas can also define multivalued properties to support many-to-one or many-to-many associations.
          • Each GeologicUnit could have further properties describing in detail the properties of the rock, such as colour, weathering, lithology, or relevant geologic events.
          • The GeologicUnit feature type can be served separately, and could be uniquely identified through its properties as the same instance seen in the SamplingPoint.
          "},{"location":"data/app-schema/complex-features/#portrayal-complex-features-sf0","title":"Portrayal complex features (SF0)","text":"

          Portrayal schemas are standardized schemas with flat attributes, also known as simple feature level 0 (SF0). Because a community schema is still required (e.g. GeoSciML-Portrayal), app-schema plugin is still used to map the database columns to the attributes.

          • WFS CSV output format is supported for complex features with portrayal schemas. At the moment, propertyName selection is not yet supported with csv outputFormat, so it always returns the full set of attributes.
          • Complex features with nesting and multi-valued properties are not supported with WFS CSV output format.
          "},{"location":"data/app-schema/configuration/","title":"Configuration","text":"

          Configuration of an app-schema complex feature type requires manual construction of a GeoServer data directory that contains an XML mapping file and a datastore.xml that points at this mapping file. The data directory also requires all the other ancillary configuration files used by GeoServer for simple features. GeoServer can serve simple and complex features at the same time.

          "},{"location":"data/app-schema/configuration/#workspace-layout","title":"Workspace layout","text":"

          The GeoServer data directory contains a folder called workspaces with the following structure:

          workspaces\n    - gsml\n        - SomeDataStore\n            - SomeFeatureType\n                - featuretype.xml\n            - datastore.xml\n            - SomeFeatureType-mapping-file.xml\n

          Note

          The folder inside workspaces must have a name (the workspace name) that is the same as the namespace prefix (gsml in this example).

          "},{"location":"data/app-schema/configuration/#datastore","title":"Datastore","text":"

          Each data store folder contains a file datastore.xml that contains the configuration parameters of the data store. To create an app-schema feature type, the data store must be configured to load the app-schema service module and process the mapping file. These options are contained in the connectionParameters:

          • namespace defines the XML namespace of the complex feature type.
          • url is a file: URL that gives the location of the app-schema mapping file relative to the root of the GeoServer data directory.
          • dbtype must be app-schema to trigger the creation of an app-schema feature type.
          "},{"location":"data/app-schema/cql-functions/","title":"CQL functions","text":"

          CQL functions enable data conversion and conditional behaviour to be specified in mapping files. Some of these functions are provided by the app-schema plugin specifically for this purpose.

          • The uDig manual includes a list of CQL functions:

            • http://udig.refractions.net/confluence/display/EN/Constraint%20Query%20Language.html
          • CQL string literals are enclosed in single quotes, for example 'urn:ogc:def:nil:OGC:missing'.

          • Single quotes are represented in CQL string literals as two single quotes, just as in SQL. For example, 'yyyy-MM-dd''T''HH:mm:ss''Z''' for the string yyyy-MM-dd'T'HH:mm:ss'Z'.

          "},{"location":"data/app-schema/cql-functions/#vocabulary-translation","title":"Vocabulary translation","text":"

          This section describes how to serve vocabulary translations using some function expressions in application schema mapping file. If you're not familiar with application schema mapping file, read app-schema.mapping-file.

          "},{"location":"data/app-schema/cql-functions/#recode","title":"Recode","text":"

          This is similar to if_then_else function, except that there is no default clause. You have to specify a translation value for every vocabulary key.

          Syntax:

          Recode(COLUMN_NAME, key1, value1, key2, value2,...)\n
          • COLUMN_NAME: column name to get values from

          Example:

          <AttributeMapping>\n  <targetAttribute>gml:name</targetAttribute>\n  <sourceExpression>\n      <OCQL>Recode(ABBREVIATION, '1GRAV', 'urn:cgi:classifier:CGI:SimpleLithology:2008:gravel',\n                                 '1TILL', 'urn:cgi:classifier:CGI:SimpleLithology:2008:diamictite',\n                                 '6ALLU', 'urn:cgi:classifier:CGI:SimpleLithology:2008:sediment')\n      </OCQL>\n  </sourceExpression>\n</AttributeMapping>\n

          The above example will map gml:name value to urn:cgi:classifier:CGI:SimpleLithology:2008:gravel if the ABBREVIATION column value is 1GRAV.

          "},{"location":"data/app-schema/cql-functions/#categorize","title":"Categorize","text":"

          This is more suitable for numeric keys, where the translation value is determined by the key's position within the thresholds.

          Syntax:

          Categorize(COLUMN_NAME, default_value, threshold 1, value 1, threshold 2, value 2, ..., [preceding/succeeding])\n
          • COLUMN_NAME: data source column name

          • default_value: default value to be mapped if COLUMN_NAME value is not within the threshold

          • threshold(n): threshold value

          • value(n): value to be mapped if the threshold is met

          • preceding/succeeding:
            • optional, succeeding is used by default if not specified.
            • not case sensitive.
            • preceding: value is within threshold if COLUMN_NAME value > threshold
            • succeeding: value is within threshold if COLUMN_NAME value >= threshold

          Example:

          <AttributeMapping>\n  <targetAttribute>gml:description</targetAttribute>\n  <sourceExpression>\n      <OCQL>Categorize(CGI_LOWER_RANGE, 'missing_value', 1000, 'minor', 5000, 'significant')</OCQL>\n  </sourceExpression>\n</AttributeMapping>\n

          The above example means gml:description value would be significant if CGI_LOWER_RANGE column value is >= 5000.

          "},{"location":"data/app-schema/cql-functions/#vocab","title":"Vocab","text":"

          This function is more useful for bigger vocabulary pairs. Instead of writing a long key-to-value pairs in the function, you can keep them in a separate properties file. The properties file serves as a lookup table to the function. It has no header, and only contains the pairs in ''='' format.

          Syntax:

          Vocab(COLUMN_NAME, properties file)\n
          • COLUMN_NAME: column name to get values from
          • properties file: absolute path of the properties file

          Example:

          Properties file:

          1GRAV=urn:cgi:classifier:CGI:SimpleLithology:2008:gravel\n1TILL=urn:cgi:classifier:CGI:SimpleLithology:2008:diamictite\n6ALLU=urn:cgi:classifier:CGI:SimpleLithology:2008:sediment\n

          Mapping file:

          <AttributeMapping>\n  <targetAttribute>gml:name</targetAttribute>\n  <sourceExpression>\n      <OCQL>Vocab(ABBREVIATION, strconcat('${config.parent}', '/mapping.properties'))</OCQL>\n  </sourceExpression>\n</AttributeMapping>\n

          The above example will map gml:name to urn:cgi:classifier:CGI:SimpleLithology:2008:gravel if ABBREVIATION value is 1GRAV.

          This example uses the config.parent predefined interpolation property to specify a vocabulary properties file in the same directory as the mapping file. See app-schema.property-interpolation for details.

          "},{"location":"data/app-schema/cql-functions/#geometry-creation","title":"Geometry creation","text":""},{"location":"data/app-schema/cql-functions/#todirectposition","title":"toDirectPosition","text":"

          This function converts double values to DirectPosition geometry type. This is needed when the data store doesn't have geometry type columns. This function expects:

          Literal

          'SRS_NAME' (optional)

          Expression

          expression of SRS name if 'SRS_NAME' is present as the first argument

          Expression

          name of column pointing to first double value

          Expression

          name of column pointing to second double value (optional, only for 2D)

          "},{"location":"data/app-schema/cql-functions/#toenvelope","title":"ToEnvelope","text":"

          ToEnvelope function can take in the following set of parameters and return as either Envelope or ReferencedEnvelope type:

          Option 1 (1D Envelope):

          ToEnvelope(minx,maxx)\n

          Option 2 (1D Envelope with crsname):

          ToEnvelope(minx,maxx,crsname)\n

          Option 3 (2D Envelope):

          ToEnvelope(minx,maxx,miny,maxy)\n

          Option 4 (2D Envelope with crsname):

          ToEnvelope(minx,maxx,miny,maxy,crsname)\n
          "},{"location":"data/app-schema/cql-functions/#topoint","title":"toPoint","text":"

          This function converts double values to a 2D Point geometry type. This is needed when the data store doesn't have geometry type columns. This function expects:

          Literal

          'SRS_NAME' (optional)

          Expression

          expression of SRS name if 'SRS_NAME' is present as the first argument

          Expression

          name of column pointing to first double value

          Expression

          name of column pointing to second double value

          Expression

          expression of gml:id (optional)

          "},{"location":"data/app-schema/cql-functions/#tolinestring","title":"toLineString","text":"

          This function converts double values to 1D LineString geometry type. This is needed to express 1D borehole intervals with custom (non EPSG) CRS.

          Literal

          'SRS_NAME' (EPSG code or custom SRS)

          Expression

          name of column pointing to first double value

          Expression

          name of column pointing to second double value

          "},{"location":"data/app-schema/cql-functions/#reference","title":"Reference","text":""},{"location":"data/app-schema/cql-functions/#toxlinkhref","title":"toXlinkHref","text":"

          This function redirects an attribute to be encoded as xlink:href, instead of being encoded as a full attribute. This is useful in polymorphism, where static client property cannot be used when the encoding is conditional. This function expects:

          Expression

          REFERENCE_VALUE (could be another function or literal)

          "},{"location":"data/app-schema/cql-functions/#datetime-formatting","title":"Date/time formatting","text":""},{"location":"data/app-schema/cql-functions/#formatdatetimezone","title":"FormatDateTimezone","text":"

          A function to format a date/time using a SimpleDateFormat pattern in a time zone supported by Java. This function improves on dateFormat, which formats date/time in the server time zone and can produce unintended results. Note that the term \"date\" is derived from a Java class name; this class represents a date/time, not just a single day.

          Syntax:

          FormatDateTimezone(pattern, date, timezone)\n
          pattern

          formatting pattern supported by SimpleDateFormat, for example 'yyyy-MM-dd'. Use two single quotes to include a literal single quote in a CQL string literal, for example 'yyyy-MM-dd''T''HH:mm:ss''Z'''.

          date

          the date/time to be formatted or its string representation, for example '1948-01-01T00:00:00Z'. An exception will be returned if the date is malformed (and not null). Database types with time zone information are recommended.

          timezone

          the name of a time zone supported by Java, for example 'UTC' or 'Canada/Mountain'. Note that unrecognised timezones will silently be converted to UTC.

          This function returns null if any parameter is null.

          This example formats date/times from a column POSITION in UTC for inclusion in a csml:TimeSeries:

          <AttributeMapping>\n    <targetAttribute>csml:timePositionList</targetAttribute>                    \n    <sourceExpression>\n        <OCQL>FormatDateTimezone('yyyy-MM-dd''T''HH:mm:ss''Z''', POSITION, 'UTC')</OCQL>\n    </sourceExpression>\n    <isList>true</isList>\n</AttributeMapping>\n
          "},{"location":"data/app-schema/data-access-integration/","title":"Data Access Integration","text":"

          This page assumes prior knowledge of Application schemas and app-schema.feature-chaining. To use feature chaining, the nested features can come from any complex feature data access, as long as:

          • it has valid data referred by the \"container\" feature type,
          • the data access is registered via DataAccessRegistry,
          • if FEATURE_LINK is used as the link field, the feature types were created via ComplexFeatureTypeFactoryImpl

          However, the \"container\" features must come from an application schema data access. The rest of this article describes how we can create an application data access from an existing non-application schema data access, in order to \"chain\" features. The input data access referred in this article is assumed to be the non-application schema data access.

          "},{"location":"data/app-schema/data-access-integration/#how-to-connect-to-the-input-data-access","title":"How to connect to the input data access","text":"

          Configure the data store connection in \"sourceDataStores\" tag as usual, but also specify the additional \"isDataAccess\" tag. This flag marks that we want to get the registered complex feature source of the specified \"sourceType\", when processing the source data store. This assumes that the input data access is registered in DataAccessRegistry upon creation, for the system to find it.

          Example:

          <sourceDataStores>\n  <DataStore>\n  <id>EarthResource</id>\n  <parameters>\n     <Parameter>\n       <name>directory</name>\n       <value>file:./</value>\n     </Parameter>\n  </parameters>\n  <isDataAccess>true</isDataAccess>\n  </DataStore>\n</sourceDataStores>\n...\n<typeMappings>\n  <FeatureTypeMapping>\n    <sourceDataStore>EarthResource</sourceDataStore>\n  <sourceType>EarthResource</sourceType>\n...\n
          "},{"location":"data/app-schema/data-access-integration/#how-to-configure-the-mapping","title":"How to configure the mapping","text":"

          Use \"inputAttribute\" in place of \"OCQL\" tag inside \"sourceExpression\", to specify the input XPath expressions.

          Example:

          <AttributeMapping>\n  <targetAttribute>gsml:classifier/gsml:ControlledConcept/gsml:preferredName</targetAttribute>\n  <sourceExpression>\n      <inputAttribute>mo:classification/mo:MineralDepositModel/mo:mineralDepositGroup</inputAttribute>\n  </sourceExpression>\n</AttributeMapping>\n
          "},{"location":"data/app-schema/data-access-integration/#how-to-chain-features","title":"How to chain features","text":"

          Feature chaining works both ways for the re-mapped complex features. You can chain other features inside these features, and vice-versa. The only difference is to use \"inputAttribute\" for the input XPath expressions, instead of \"OCQL\" as mentioned above.

          Example:

          <AttributeMapping>\n  <targetAttribute>gsml:occurence</targetAttribute>\n  <sourceExpression>\n      <inputAttribute>mo:commodityDescription</inputAttribute>\n      <linkElement>gsml:MappedFeature</linkElement>\n      <linkField>gml:name[2]</linkField>\n  </sourceExpression>\n  <isMultiple>true</isMultiple>\n</AttributeMapping>\n
          "},{"location":"data/app-schema/data-access-integration/#how-to-use-filters","title":"How to use filters","text":"

          From the user point of view, filters are configured as per normal, using the mapped/output target attribute XPath expressions. However, when one or more attributes in the expression is a multi-valued property, we need to specify a function such as \"contains_text\" in the filter. This is because when multiple values are returned, comparing them to a single value would only return true if there is only one value returned, and it is the same value. Please note that the \"contains_text\" function used in the following example is not available in GeoServer API, but defined in the database.

          Example:

          Composition is a multi-valued property:

          <ogc:Filter>\n  <ogc:PropertyIsEqualTo>\n    <ogc:Function name=\"contains_text\">\n        <ogc:PropertyName>gsml:composition/gsml:CompositionPart/gsml:proportion/gsml:CGI_TermValue/gsml:value</ogc:PropertyName>\n        <ogc:Literal>Olivine basalt, tuff, microgabbro, minor sedimentary rocks</ogc:Literal>\n    </ogc:Function>\n    <ogc:Literal>1</ogc:Literal>\n  </ogc:PropertyIsEqualTo>\n</ogc:Filter>\n
          "},{"location":"data/app-schema/data-stores/","title":"Data Stores","text":"

          The app-schema app-schema.mapping-file requires you to specify your data sources in the sourceDataStores section. For GeoServer simple features, these are configured using the web interface, but because app-schema lacks a web configuration interface, data stores must be configured by editing the mapping file.

          Many configuration options may be externalised through the use of app-schema.property-interpolation.

          "},{"location":"data/app-schema/data-stores/#the-datastore-element","title":"The DataStore element","text":"

          A DataStore configuration consists of

          • an id, which is an opaque identifier used to refer to the data store elsewhere in a mapping file, and
          • one or more Parameter elements, which each contain the name and value of one parameter, and are used to configure the data store.

          An outline of the DataStore element:

          <DataStore>\n     <id>datastore</id>\n     <parameters>\n         <Parameter>\n             <name>...</name>\n             <value>...</value>\n         </Parameter>\n         ...\n     </parameters>\n</DataStore>\n

          Parameter order is not significant.

          "},{"location":"data/app-schema/data-stores/#database-options","title":"Database options","text":"

          Databases such as PostGIS and Oracle share some common or similar configuration options.

          name Meaning value examples dbtype Database type postgisng, Oracle host Host name or IP address of database server database.example.org, 192.168.3.12 port database schema user passwd TCP port on database server PostGIS/Oracle database The database schema The user name used to login to the database server The password used to login to the database server Default if omitted: 1521 (Oracle), 5432 (PostGIS) Expose primary keys Columns with primary keys available for mapping Default is false, set to true to use primary key columns in mapping"},{"location":"data/app-schema/data-stores/#postgis","title":"PostGIS","text":"

          Set the parameter dbtype to postgisng to use the PostGIS NG (New Generation) driver bundled with GeoServer 2.0 and later.

          Example:

          <DataStore>\n    <id>datastore</id>\n    <parameters>\n        <Parameter>\n            <name>dbtype</name>\n            <value>postgisng</value>\n        </Parameter>\n        <Parameter>\n            <name>host</name>\n            <value>postgresql.example.org</value>\n        </Parameter>\n        <Parameter>\n            <name>port</name>\n            <value>5432</value>\n        </Parameter>\n        <Parameter>\n            <name>database</name>\n            <value>test</value>\n        </Parameter>\n        <Parameter>\n            <name>user</name>\n            <value>test</value>\n        </Parameter>\n        <Parameter>\n            <name>passwd</name>\n            <value>test</value>\n        </Parameter>\n    </parameters>\n</DataStore>\n

          Note

          PostGIS support is included in the main GeoServer bundle, so a separate plugin is not required.

          "},{"location":"data/app-schema/data-stores/#oracle","title":"Oracle","text":"

          Set the parameter dbtype to Oracle to use the Oracle Spatial NG (New Generation) driver compatible with GeoServer 2.0 and later.

          Example:

          <DataStore>\n    <id>datastore</id>\n    <parameters>\n        <Parameter>\n            <name>dbtype</name>\n            <value>Oracle</value>\n        </Parameter>\n        <Parameter>\n            <name>host</name>\n            <value>oracle.example.org</value>\n        </Parameter>\n        <Parameter>\n            <name>port</name>\n            <value>1521</value>\n        </Parameter>\n        <Parameter>\n            <name>database</name>\n            <value>demodb</value>\n        </Parameter>\n        <Parameter>\n            <name>user</name>\n            <value>orauser</value>\n        </Parameter>\n        <Parameter>\n            <name>passwd</name>\n            <value>s3cr3t</value>\n        </Parameter>\n    </parameters>\n</DataStore>\n

          Note

          You must install the Oracle plugin to connect to Oracle Spatial databases.

          "},{"location":"data/app-schema/data-stores/#shapefile","title":"Shapefile","text":"

          Shapefile data sources are identified by the presence of a parameter url, whose value should be the file URL for the .shp file.

          In this example, only the url parameter is required. The others are optional:

          <DataStore>\n    <id>shapefile</id>\n    <parameters>\n        <Parameter>\n            <name>url</name>\n            <value>file:/D:/Workspace/shapefiles/VerdeRiverBuffer.shp</value>\n        </Parameter>\n        <Parameter>\n            <name>memory mapped buffer</name>\n            <value>false</value>\n        </Parameter>\n        <Parameter>\n            <name>create spatial index</name>\n            <value>true</value>\n        </Parameter>\n        <Parameter>\n            <name>charset</name>\n            <value>ISO-8859-1</value>\n        </Parameter>\n    </parameters>\n</DataStore>\n

          Note

          The url in this case is an example of a Windows filesystem path translated to URL notation.

          Note

          Shapefile support is included in the main GeoServer bundle, so a separate plugin is not required.

          "},{"location":"data/app-schema/data-stores/#property-file","title":"Property file","text":"

          Property files are configured by specifying a directory that is a file: URI.

          • If the directory starts with file:./ it is relative to the mapping file directory. (This is an invalid URI, but it works.)

          For example, the following data store is used to access property files in the same directory as the mapping file:

          <DataStore>\n    <id>propertyfile</id>\n    <parameters>\n        <Parameter>\n            <name>directory</name>\n            <value>file:./</value>\n        </Parameter>\n    </parameters>\n</DataStore>\n

          A property file data store contains all the feature types stored in .properties files in the directory. For example, if the directory contained River.properties and station.properties, the data store would be able to serve them as the feature types River and station. Other file extensions are ignored.

          Note

          Property file support is included in the main GeoServer bundle, so a separate plugin is not required.

          "},{"location":"data/app-schema/data-stores/#jndi","title":"JNDI","text":"

          Defining a JDBC data store with a jndiReferenceName allows you to use a connection pool provided by your servlet container. This allows detailed configuration of connection pool parameters and sharing of connections between data sources, and even between servlets.

          To use a JNDI connection provider:

          1. Specify a dbtype parameter to indicate the database type. These values are the same as for the non-JNDI examples above.
          2. Give the jndiReferenceName you set in your servlet container. Both the abbreviated form jdbc/oracle form, as in Tomcat, and the canonical form java:comp/env/jdbc/oracle are supported.

          This example uses JNDI to obtain Oracle connections:

          <DataStore>\n    <id>datastore</id>\n    <parameters>\n        <Parameter>\n            <name>dbtype</name>\n            <value>Oracle</value>\n        </Parameter>\n        <Parameter>\n            <name>jndiReferenceName</name>\n            <value>jdbc/oracle</value>\n        </Parameter>\n    </parameters>\n</DataStore>\n

          Your servlet container my require you to add a resource-ref section at the end of your geoserver/WEB-INF/web.xml. (Tomcat requires this, Jetty does not.) For example:

          <resource-ref>\n    <description>Oracle Spatial Datasource</description>\n    <res-ref-name>jdbc/oracle</res-ref-name>\n    <res-type>javax.sql.DataSource</res-type>\n    <res-auth>Container</res-auth>\n</resource-ref>\n

          Here is an example of a Tomcat 6 context in /etc/tomcat6/server.xml that includes an Oracle connection pool:

          <Context\n    path=\"/geoserver\"\n    docBase=\"/usr/local/geoserver\"\n    crossContext=\"false\"\n    reloadable=\"false\">\n    <Resource\n        name=\"jdbc/oracle\"\n        auth=\"Container\"\n        type=\"javax.sql.DataSource\"\n        url=\"jdbc:oracle:thin:@YOUR_DATABASE_HOSTNAME:1521:YOUR_DATABASE_NAME\"\n        driverClassName=\"oracle.jdbc.driver.OracleDriver\"\n        username=\"YOUR_DATABASE_USERNAME\"\n        password=\"YOUR_DATABASE_PASSWORD\"\n        maxActive=\"20\"\n        maxIdle=\"10\"\n        minIdle=\"0\"\n        maxWait=\"10000\"\n        minEvictableIdleTimeMillis=\"300000\"\n        timeBetweenEvictionRunsMillis=\"300000\"\n        numTestsPerEvictionRun=\"20\"\n        poolPreparedStatements=\"true\"\n        maxOpenPreparedStatements=\"100\"\n        testOnBorrow=\"true\"\n        validationQuery=\"SELECT SYSDATE FROM DUAL\" />\n</Context>\n

          Firewall timeouts can silently sever idle connections to the database and cause GeoServer to hang. If there is a firewall between GeoServer and the database, a connection pool configured to shut down idle connections before the firewall can drop them will prevent GeoServer from hanging. This JNDI connection pool is configured to shut down idle connections after 5 to 10 minutes.

          See also Setting up a JNDI connection pool with Tomcat.

          "},{"location":"data/app-schema/data-stores/#expose-primary-keys","title":"Expose primary keys","text":"

          By default, GeoServer conceals the existence of database columns with a primary key. To make such columns available for use in app-schema mapping files, set the data store parameter Expose primary keys to true:

          <Parameter>\n    <name>Expose primary keys</name>\n   <value>true</value>\n</Parameter>\n

          This is known to work with PostGIS, Oracle, and JNDI data stores.

          "},{"location":"data/app-schema/data-stores/#mongodb","title":"MongoDB","text":"

          The data store configuration for a MongoDB data base will look like this:

          <sourceDataStores>\n    <DataStore>\n        <id>data_source</id>\n        <parameters>\n            <Parameter>\n                <name>data_store</name>\n                <value>MONGO_DB_URL</value>\n            </Parameter>\n            <Parameter>\n                <name>namespace</name>\n                <value>NAME_SPACE</value>\n            </Parameter>\n            <Parameter>\n                <name>schema_store</name>\n                <value>SCHEMA_STORE</value>\n            </Parameter>\n            <Parameter>\n                <name>data_store_type</name>\n                <value>complex</value>\n            </Parameter>\n        </parameters>\n    </DataStore>\n</sourceDataStores>\n

          Check MongoDB Tutorial for a more detailed description about how to use MongoDB with app-schema.

          Note

          You must install the MongoDB plugin to connect to MongoDB databases.

          "},{"location":"data/app-schema/feature-chaining/","title":"Feature Chaining","text":""},{"location":"data/app-schema/feature-chaining/#scope","title":"Scope","text":"

          This page describes the use of \"Feature Chaining\" to compose complex features from simpler components, and in particular to address some requirements that have proven significant in practice.

          • Handling multiple cases of multi-valued properties within a single Feature Type
          • Handing nesting of multi-valued properties within other multi-valued properties
          • Linking related (through association) Feature Types, and in particular allowing re-use of the related features types (for example the O&M pattern has relatedObservation from a samplingFeature, but Observation may be useful in its own right)
          • Encoding the same referenced property object as links when it appears in multiple containing features
          • Eliminating the need for large denormalized data store views of top level features and their related features. Denormalized views would still be needed for special cases, such as many-to-many relationships, but won't be as large.

          For non-application schema configurations, please refer to app-schema.data-access-integration.

          "},{"location":"data/app-schema/feature-chaining/#mapping-steps","title":"Mapping steps","text":""},{"location":"data/app-schema/feature-chaining/#create-a-mapping-file-for-every-complex-type","title":"Create a mapping file for every complex type","text":"

          We need one mapping file per complex type that is going to be nested, including non features, e.g. gsml:CompositionPart.

          Non-feature types that cannot be individually accessed (eg. CompositionPart as a Data Type) can still be mapped separately for its reusability. For this case, the containing feature type has to include these types in its mapping file. The include tag should contain the nested mapping file path relative to the location of the containing type mapping file. In GeologicUnit_MappingFile.xml:

          <includedTypes>   \n    <Include>CGITermValue_MappingFile.xml</Include>\n    <Include>CompositionPart_MappingFile.xml</Include>\n</includedTypes>\n

          Feature types that can be individually accessed don't need to be explicitly included in the mapping file, as they would be configured for GeoServer to find. Such types would have their mapping file associated with a corresponding datastore.xml file, which means that it can be found from the data store registry. In other words, if the type is associated with a datastore.xml file, it doesn't need to be explicitly included if referred from another mapping file.

          Example:

          For this output: MappedFeature_Output.xml, here are the mapping files:

          • MappedFeature_MappingFile.xml
          • GeologicUnit_MappingFile.xml
          • CompositionPart_MappingFile.xml
          • GeologicEvent_MappingFile.xml
          • CGITermValue_MappingFile.xml

          GeologicUnit type

          You can see within GeologicUnit features, both gml:composition (CompositionPart type) and gsml:geologicHistory (GeologicEvent type) are multi-valued properties. It shows how multiple cases of multi-valued properties can be configured within a single Feature Type. This also proves that you can \"chain\" non-feature type, as CompositionPart is a Data Type.

          GeologicEvent type

          Both gsml:eventEnvironment (CGI_TermValue type) and gsml:eventProcess (also of CGI_TermValue type) are multi-valued properties. This also shows that \"chaining\" can be done on many levels, as GeologicEvent is nested inside GeologicUnit. Note that gsml:eventAge properties are configured as inline attributes, as there can only be one event age per geologic event, thus eliminating the need for feature chaining.

          "},{"location":"data/app-schema/feature-chaining/#configure-nesting-on-the-nested-feature-type","title":"Configure nesting on the nested feature type","text":"

          In the nested feature type, make sure we have a field that can be referenced by the parent feature. If there isn't any existing field that can be referred to, the system field FEATURE_LINK can be mapped to hold the foreign key value. This is a multi-valued field, so more than one instances can be mapped in the same feature type, for features that can be nested by different parent types. Since this field doesn't exist in the schema, it wouldn't appear in the output document.

          In the source expression tag:

          • OCQL: the value of this should correspond to the OCQL part of the parent feature

          Example One: Using FEATURE_LINK in CGI TermValue type, which is referred by GeologicEvent as gsml:eventProcess and gsml:eventEnvironment.

          In GeologicEvent (the container feature) mapping:

          <AttributeMapping>\n  <targetAttribute>gsml:eventEnvironment</targetAttribute>\n  <sourceExpression>\n      <OCQL>id</OCQL>\n      <linkElement>gsml:CGI_TermValue</linkElement>\n      <linkField>FEATURE_LINK[1]</linkField>\n  </sourceExpression>\n  <isMultiple>true</isMultiple>\n</AttributeMapping>\n<AttributeMapping>\n  <targetAttribute>gsml:eventProcess</targetAttribute>\n  <sourceExpression>\n      <OCQL>id</OCQL>\n      <linkElement>gsml:CGI_TermValue</linkElement>\n      <linkField>FEATURE_LINK[2]</linkField>\n  </sourceExpression>\n  <isMultiple>true</isMultiple>\n</AttributeMapping>\n

          In CGI_TermValue (the nested feature) mapping:

          <AttributeMapping>\n  <!-- FEATURE_LINK[1] is referred by geologic event as environment -->\n  <targetAttribute>FEATURE_LINK[1]</targetAttribute>\n  <sourceExpression>\n      <OCQL>ENVIRONMENT_OWNER</OCQL>\n  </sourceExpression>\n</AttributeMapping>\n<AttributeMapping>\n  <!-- FEATURE_LINK[2] is referred by geologic event as process -->\n  <targetAttribute>FEATURE_LINK[2]</targetAttribute>\n  <sourceExpression><\n      <OCQL>PROCESS_OWNER</OCQL>\n  </sourceExpression>\n</AttributeMapping>\n

          The ENVIRONMENT_OWNER column in CGI_TermValue view corresponds to the ID column in GeologicEvent view.

          Geologic Event property file:

          id GEOLOGIC_UNIT_ID:String ghminage:String ghmaxage:String ghage_cdspace:String

          ge.26931120 gu.25699 Oligocene Paleocene

          ge.26930473 gu.25678 Holocene Pleistocene

          ge.26930960 gu.25678 Pliocene Miocene

          ge.26932959 gu.25678 LowerOrdovician LowerOrdovician

          CGI Term Value property file:

          id VALUE:String PROCESS_OWNER:String ENVIRONMENT_OWNER:String

          3 fluvial NULL ge.26931120

          4 swamp/marsh/bog NULL ge.26930473

          5 marine NULL ge.26930960

          6 submarine fan NULL ge.26932959

          7 hemipelagic NULL ge.26932959

          8 detrital deposition still water ge.26930473 NULL

          9 water [process] ge.26932959 NULL

          10 channelled stream flow ge.26931120 NULL

          11 turbidity current ge.26932959 NULL

          The system field FEATURE_LINK doesn't get encoded in the output:

          <gsml:GeologicEvent>                      \n  <gml:name codeSpace=\"urn:cgi:classifierScheme:GSV:GeologicalUnitId\">gu.25699</gml:name>\n  <gsml:eventAge>\n    <gsml:CGI_TermRange>\n       <gsml:lower>\n          <gsml:CGI_TermValue>   \n            <gsml:value codeSpace=\"urn:cgi:classifierScheme:ICS:StratChart:2008\">Oligocene</gsml:value>\n          </gsml:CGI_TermValue>\n       </gsml:lower>\n       <gsml:upper>\n          <gsml:CGI_TermValue>\n            <gsml:value codeSpace=\"urn:cgi:classifierScheme:ICS:StratChart:2008\">Paleocene</gsml:value>\n          </gsml:CGI_TermValue>\n       </gsml:upper>\n    </gsml:CGI_TermRange>\n  </gsml:eventAge>\n  <gsml:eventEnvironment>\n    <gsml:CGI_TermValue>\n       <gsml:value>fluvial</gsml:value>\n    </gsml:CGI_TermValue>\n  </gsml:eventEnvironment>\n  <gsml:eventProcess>\n    <gsml:CGI_TermValue>\n       <gsml:value>channelled stream flow</gsml:value>\n    </gsml:CGI_TermValue>\n  </gsml:eventProcess>\n

          Example Two: Using existing field (gml:name) to hold the foreign key, see MappedFeature_MappingFile.xml:

          gsml:specification links to gml:name in GeologicUnit:

          <AttributeMapping>\n  <targetAttribute>gsml:specification</targetAttribute> \n  <sourceExpression>\n    <OCQL>GEOLOGIC_UNIT_ID</OCQL> \n    <linkElement>gsml:GeologicUnit</linkElement> \n    <linkField>gml:name[3]</linkField> \n  </sourceExpression>\n</AttributeMapping>\n

          In GeologicUnit_MappingFile.xml:

          GeologicUnit has 3 gml:name properties in the mapping file, so each has a code space to clarify them:

          <AttributeMapping>\n  <targetAttribute>gml:name[1]</targetAttribute> \n  <sourceExpression>\n    <OCQL>ABBREVIATION</OCQL> \n  </sourceExpression>\n  <ClientProperty>\n    <name>codeSpace</name> \n    <value>'urn:cgi:classifierScheme:GSV:GeologicalUnitCode'</value> \n  </ClientProperty>\n</AttributeMapping>\n<AttributeMapping>\n  <targetAttribute>gml:name[2]</targetAttribute> \n  <sourceExpression>\n    <OCQL>NAME</OCQL> \n  </sourceExpression>\n  <ClientProperty>\n    <name>codeSpace</name> \n    <value>'urn:cgi:classifierScheme:GSV:GeologicalUnitName'</value> \n  </ClientProperty>\n</AttributeMapping>\n<AttributeMapping>\n  <targetAttribute>gml:name[3]</targetAttribute> \n  <sourceExpression>\n    <OCQL>id</OCQL> \n  </sourceExpression>\n  <ClientProperty>\n    <name>codeSpace</name> \n    <value>'urn:cgi:classifierScheme:GSV:MappedFeatureReference'</value> \n  </ClientProperty>\n</AttributeMapping>\n

          The output with multiple gml:name properties and their code spaces:

          <gsml:specification>\n  <gsml:GeologicUnit gml:id=\"gu.25678\">\n      <gml:description>Olivine basalt, tuff, microgabbro, minor sedimentary rocks</gml:description>\n      <gml:name codeSpace=\"urn:cgi:classifierScheme:GSV:GeologicalUnitCode\">-Py</gml:name>\n      <gml:name codeSpace=\"urn:cgi:classifierScheme:GSV:GeologicalUnitName\">Yaugher Volcanic Group</gml:name>\n      <gml:name codeSpace=\"urn:cgi:classifierScheme:GSV:MappedFeatureReference\">gu.25678</gml:name>\n

          If this is the \"one\" side of a one-to-many or many-to-one database relationship, we can use the feature id as the source expression field, as you can see in above examples. See one_to_many_relationship.JPG as an illustration.

          If we have a many-to-many relationship, we have to use one denormalized view for either side of the nesting. This means we can either use the feature id as the referenced field, or assign a column to serve this purpose. See many_to_many_relationship.JPG as an illustration.

          Note

          • For many-to-many relationships, we can't use the same denormalized view for both sides of the nesting.

          Test this configuration by running a getFeature request for the nested feature type on its own.

          "},{"location":"data/app-schema/feature-chaining/#configure-nesting-on-the-containing-feature-type","title":"Configure nesting on the \"containing\" feature type","text":"

          When nesting another complex type, you need to specify in your source expression:

          • OCQL: OGC's Common Query Language expression of the data store column

          • linkElement:
            • the nested element name, which is normally the targetElement or mappingName of the corresponding type.
            • on some cases, it has to be an OCQL function (see app-schema.polymorphism)
          • linkField: the indexed XPath attribute on the nested element that OCQL corresponds to

          Example: Nesting composition part in geologic unit feature.

          In Geologic Unit mapping file:

          <AttributeMapping>\n    <targetAttribute>gsml:composition</targetAttribute>\n    <sourceExpression>\n        <OCQL>id</OCQL>\n        <linkElement>gsml:CompositionPart</linkElement>\n        <linkField>FEATURE_LINK</linkField>\n    </sourceExpression>\n    <isMultiple>true</isMultiple>\n</AttributeMapping>\n
          • OCQL: id is the geologic unit id
          • linkElement: links to gsml:CompositionPart type
          • linkField: FEATURE_LINK, the linking field mapped in gsml:CompositionPart type that also stores the geologic unit id. If there are more than one of these attributes in the nested feature type, make sure the index is included, e.g. FEATURE_LINK[2].

          Geologic Unit property file:

          id ABBREVIATAION:String NAME:String TEXTDESCRIPTION:String

          gu.25699 -Py Yaugher Volcanic Group Olivine basalt, tuff, microgabbro, minor sedimentary rocks

          gu.25678 -Py Yaugher Volcanic Group Olivine basalt, tuff, microgabbro, minor sedimentary rocks

          Composition Part property file:

          id COMPONENT_ROLE:String PROPORTION:String GEOLOGIC_UNIT_ID:String

          cp.167775491936278812 interbedded component significant gu.25699

          cp.167775491936278856 interbedded component minor gu.25678

          cp.167775491936278844 sole component major gu.25678

          Run the getFeature request to test this configuration. Check that the nested features returned in Step 2 are appropriately lined inside the containing features. If they are not there, or exceptions are thrown, scroll down and read the \"Trouble Shooting\" section.

          "},{"location":"data/app-schema/feature-chaining/#multiple-mappings-of-the-same-type","title":"Multiple mappings of the same type","text":"

          At times, you may find the need to have different FeatureTypeMapping instances for the same type. You may have two different attributes of the same type that need to be nested. For example, in gsml:GeologicUnit, you have gsml:exposureColor and gsml:outcropCharacter that are both of gsml:CGI_TermValue type.

          This is when the optional mappingName tag mentioned in app-schema.mapping-file comes in. Instead of passing in the nested feature type's targetElement in the containing type's linkElement, specify the corresponding mappingName.

          Note

          • The mappingName is namespace aware and case sensitive. * When the referred mappingName contains special characters such as '-', it must be enclosed with single quotes in the linkElement. E.g. 'observation-method'. * Each mappingName must be unique against other mappingName and targetElement tags across the application. * The mappingName is only to be used to identify the chained type from the nesting type. It is not a solution for multiple FeatureTypeMapping instances where > 1 of them can be queried as top level features. * When queried as a top level feature, the normal targetElement is to be used. Filters involving the nested type should still use the targetElement in the PropertyName part of the query. * You can't have more than 1 FeatureTypeMapping of the same type in the same mapping file if one of them is a top level feature. This is because featuretype.xml would look for the targetElement and wouldn't know which one to get.

          The solution for the last point above is to break them up into separate files and locations with only 1 featuretype.xml in the intended top level feature location. E.g.

          • You can have 2 FeatureTypeMapping instances in the same file for gsml:CGI_TermValue type since it's not a feature type.
          • You can have 2 FeatureTypeMapping instances for gsml:MappedFeature, but they have to be broken up into separate files. The one that can be queried as top level feature type would have featuretype.xml in its location.
          "},{"location":"data/app-schema/feature-chaining/#nesting-simple-properties","title":"Nesting simple properties","text":"

          You don't need to chain multi-valued simple properties and map them separately. The original configuration would still work.

          "},{"location":"data/app-schema/feature-chaining/#filtering-nested-attributes-on-chained-features","title":"Filtering nested attributes on chained features","text":"

          Filters would work as usual. You can supply the full XPath of the attribute, and the code would handle this. E.g. You can run the following filter on gsml:MappedFeatureUseCase2A:

          <ogc:Filter>\n      <ogc:PropertyIsEqualTo>\n          <ogc:Function name=\"contains_text\">\n              <ogc:PropertyName>gsml:specification/gsml:GeologicUnit/gml:description</ogc:PropertyName>\n              <ogc:Literal>Olivine basalt, tuff, microgabbro, minor sedimentary rocks</ogc:Literal>\n          </ogc:Function>\n          <ogc:Literal>1</ogc:Literal>\n      </ogc:PropertyIsEqualTo>\n</ogc:Filter>\n
          "},{"location":"data/app-schema/feature-chaining/#multi-valued-properties-by-reference-xlinkhref","title":"Multi-valued properties by reference (xlink:href)","text":"

          You may want to use feature chaining to set multi-valued properties by reference. This is particularly handy to avoid endless loop in circular relationships. For example, you may have a circular relationship between gsml:MappedFeature and gsml:GeologicUnit. E.g.

          • gsml:MappedFeature has gsml:GeologicUnit as gsml:specification
          • gsml:GeologicUnit has gsml:MappedFeature as gsml:occurrence

          Obviously you can only encode one side of the relationship, or you'll end up with an endless loop. You would need to pick one side to \"chain\" and use xlink:href for the other side of the relationship.

          For this example, we are nesting gsml:GeologicUnit in gsml:MappedFeature as gsml:specification.

          • Set up nesting on the container feature type mapping as usual:

            <AttributeMapping>\n  <targetAttribute>gsml:specification</targetAttribute>\n  <sourceExpression>\n      <OCQL>GEOLOGIC_UNIT_ID</OCQL>\n    <linkElement>gsml:GeologicUnit</linkElement>\n    <linkField>gml:name[2]</linkField>\n  </sourceExpression>\n</AttributeMapping>\n
          • Set up xlink:href as client property on the other mapping file:

            <AttributeMapping>\n  <targetAttribute>gsml:occurrence</targetAttribute>      \n  <sourceExpression>\n    <OCQL>id</OCQL>\n    <linkElement>gsml:MappedFeature</linkElement>\n    <linkField>gsml:specification</linkField>\n  </sourceExpression>                               \n  <isMultiple>true</isMultiple>                                       \n  <ClientProperty>\n     <name>xlink:href</name>\n     <value>strConcat('urn:cgi:feature:MappedFeature:', ID)</value>\n  </ClientProperty>       \n</AttributeMapping>\n

          As we are getting the client property value from a nested feature, we have to set it as if we are chaining the feature; but we also add the client property containing xlink:href in the attribute mapping. The code will detect the xlink:href setting, and will not proceed to build the nested feature's attributes, and we will end up with empty attributes with xlink:href client properties.

          This would be the encoded result for gsml:GeologicUnit:

          <gsml:GeologicUnit gml:id=\"gu.25678\">\n         <gsml:occurrence xlink:href=\"urn:cgi:feature:MappedFeature:mf2\"/>\n         <gsml:occurrence xlink:href=\"urn:cgi:feature:MappedFeature:mf3\"/>\n

          Note

          • Don't forget to add XLink in your mapping file namespaces section, or you could end up with a StackOverflowException as the xlink:href client property won't be recognized and the mappings would chain endlessly. * app-schema.resolve may be used to force app-schema to do full feature chaining up to a certain level, even if an xlink reference is specified.
          "},{"location":"data/app-schema/installation/","title":"Installation","text":"

          Application schema support is a GeoServer extension and is downloaded separately.

          • Download the app-schema plugin zip file for the same version of GeoServer.
          • Unzip the app-schema plugin zip file to obtain the jar files inside. Do not unzip the jar files.
          • Place the jar files in the WEB-INF/lib directory of your GeoServer installation.
          • Restart GeoServer to load the extension (although you might want to configure it first [see below]).
          "},{"location":"data/app-schema/joining/","title":"Joining Support For Performance","text":"

          App-schema joining is a optional configuration parameter that tells app-schema to use a different implementation for app-schema.feature-chaining, which in many cases can improve performance considerably, by reducing the amount of SQL queries sent to the DBMS.

          "},{"location":"data/app-schema/joining/#conditions","title":"Conditions","text":"

          In order to use App-schema Joining, the following configuration conditions must be met:

          • All feature mappings used must be mapped to JDBC datastores.
          • All feature mappings that are chained to each other must map to the same physical database.
          • In your mappings, there are restrictions on the CQL expressions specified in the of both the referencing field in the parent feature as well as the referenced field in the nested feature (like FEATURE_LINK). Any operators or functions used in this expression must be supported by the filter capabilities, i.e. geotools must be able to translate them directly to SQL code. This can be different for each DBMS, though as a general rule it can assumed that comparison operators, logical operators and arithmetic operators are all supported but functions are not. Using simple field names for feature chaining is guaranteed to always work.

            Failing to comply with any of these three restrictions when turning on Joining will result in exceptions thrown at run-time.

            When using app-schema with Joining turned on, the following restrictions exist with respect to normal behaviour:

            • XPaths specified inside Filters do not support handling referenced features (see app-schema.feature-chaining-by-reference) as if they were actual nested features, i.e. XPaths can only be evaluated when they can be evaluated against the actual XML code produced by WFS according to the XPath standard.
            "},{"location":"data/app-schema/joining/#configuration","title":"Configuration","text":"

            Joining is turned on by default. It is disabled by adding this simple line to your app-schema.properties file (see app-schema.property-interpolation) :

            app-schema.joining = false\n

            Or, alternatively, by setting the value of the Java System Property \"app-schema.joining\" to \"false\", for example :

            java -DGEOSERVER_DATA_DIR=... -Dapp-schema.joining=false Start\n

            Not specifying \"app-schema.joining\" parameter will enable joining by default.

            "},{"location":"data/app-schema/joining/#database-design-guidelines","title":"Database Design Guidelines","text":"
            • Databases should be optimised for fast on-the-fly joining and ordering.
            • Make sure to put indexes on all fields used as identifiers and for feature chaining, unique indexes where possible. Lack of indices may result in data being encoded in the wrong order or corrupted output when feature chaining is involved.
            • Map your features preferably to normalised tables.
            • It is recommended to apply feature chaining to regular one-to-many relationships, i.e. there should be a unique constraint defined on one of the fields used for the chaining, and if possible a foreign key constraint defined on the other field.
            "},{"location":"data/app-schema/joining/#effects-on-performance","title":"Effects on Performance","text":"

            Typical curves of response time for configurations with and without joining against the amount of features produced will be shaped like this:

            In the default implementation, response time increases rapidly with respect to the amount of produced features. This is because feature chaining is implemented by sending multiple SQL requests to the DBMS per feature, so the amount of requests increases with the amount of features produced. When Joining is turned on, response time will be almost constant with respect to the number of features. This is because in this implementation a small amount of larger queries is sent to the DBMS, independent of the amount of features produced. In summary, difference in performance becomes greater as the amount of features requested gets bigger. General performance of joining will be dependant on database and mapping design (see above) and database size.

            Using joining is strongly recommended when a large number of features need to be produced, for example when producing maps with WMS (see app-schema.wms-support).

            Optimising the performance of the database will maximise the benefit of using joining, including for small queries.

            "},{"location":"data/app-schema/joining/#native-encoding-of-filters-on-nested-attributes","title":"Native Encoding of Filters on Nested Attributes","text":"

            When App-Schema Joining is active, filters operating on nested attributes (i.e. attributes of features that are joined to the queried type via app-schema.feature-chaining) are translated to SQL and executed directly in the database backend, rather than being evaluated in memory after all features have been loaded (which was standard behavior in earlier versions of GeoServer). Native encoding can yield significant performance improvements, especially when the total number of features in the database is high (several thousands or more), but only a few of them would satisfy the filter.

            There are, however, a few limitations in the current implementation:

            1. Joining support must not have been explicitly disabled and all its pre-conditions must be met (see above)
            2. Only binary comparison operators (e.g. PropertyIsEqualTo, PropertyIsGreaterThan, etc...), PropertyIsLike and PropertyIsNull filters are translated to SQL
            3. Filters involving conditional polymorphic mappings are evaluated in memory
            4. Filters comparing two or more different nested attributes are evaluated in memory
            5. Filters matching multiple nested attribute mappings are evaluated in memory

            Much like joining support, native encoding of nested filters is turned on by default, and it is disabled by adding to your app-schema.properties file the line :

            app-schema.encodeNestedFilters = false\n

            Or, alternatively, by setting the value of the Java System Property \"app-schema.encodeNestedFilters\" to \"false\", for example :

            java -DGEOSERVER_DATA_DIR=... -Dapp-schema.encodeNestedFilters=false Start\n
            "},{"location":"data/app-schema/joining/#union-performance-improvement-for-or-conditions","title":"UNION performance improvement for OR conditions","text":"

            OR conditions are difficult to optimize for postgresql and are usually slow. App-Schema improves OR condition performance using UNION clauses instead OR for nested filter subqueries.

            With UNION improvement enabled main OR binary operator on nested filter subquery will rebuild normal OR query like:

            SELECT id, name FROM table WHERE name = \"A\" OR name = \"B\"\n

            to:

            SELECT id, name FROM table WHERE name = \"A\" UNION SELECT id, name FROM table WHERE name = \"B\"\n

            UNION improvement is enabled by default, and it is disabled by adding to your app-schema.properties file the line :

            app-schema.orUnionReplace = false\n

            Or, alternatively, by setting the value of the Java System Property \"app-schema.orUnionReplace\" to \"false\", for example :

            java -DGEOSERVER_DATA_DIR=... -Dapp-schema.orUnionReplace=false Start\n

            Note

            This optimization will only be applied when a PostgresSQL database is being used.

            "},{"location":"data/app-schema/mapping-file/","title":"Mapping File","text":"

            An app-schema feature type is configured using a mapping file that defines the data source for the feature and the mappings from the source data to XPaths in the output XML.

            "},{"location":"data/app-schema/mapping-file/#outline","title":"Outline","text":"

            Here is an outline of a mapping file:

            <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<as:AppSchemaDataAccess xmlns:as=\"http://www.geotools.org/app-schema\"\n    xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\"\n    xsi:schemaLocation=\"http://www.geotools.org/app-schema AppSchemaDataAccess.xsd\">\n    <namespaces>...</namespaces>\n    <includedTypes>...</includedTypes>\n    <sourceDataStores>...</sourceDataStores>\n    <catalog>...</catalog>\n    <targetTypes...</targetTypes>\n    <typeMappings>...</typeMappings>\n</as:AppSchemaDataAccess>\n
            • namespaces defines all the namespace prefixes used in the mapping file.
            • includedTypes (optional) defines all the included non-feature type mapping file locations that are referred in the mapping file.
            • sourceDataStores provides the configuration information for the source data stores.
            • catalog is the location of the OASIS Catalog used to resolve XML Schema locations.
            • targetTypes is the location of the XML Schema that defines the feature type.
            • typeMappings give the relationships between the fields of the source data store and the elements of the output complex feature.
            "},{"location":"data/app-schema/mapping-file/#mapping-file-schema","title":"Mapping file schema","text":"
            • AppSchemaDataAccess.xsd is optional because it is not used by GeoServer. The presence of AppSchemaDataAccess.xsd in the same folder as the mapping file enables XML editors to observe its grammar and provide contextual help.
            "},{"location":"data/app-schema/mapping-file/#settings","title":"Settings","text":""},{"location":"data/app-schema/mapping-file/#namespaces","title":"namespaces","text":"

            The namespaces section defines all the XML namespaces used in the mapping file:

            <Namespace>\n    <prefix>gsml</prefix>\n    <uri>urn:cgi:xmlns:CGI:GeoSciML:2.0</uri>\n</Namespace>\n<Namespace>\n    <prefix>gml</prefix>\n    <uri>http://www.opengis.net/gml</uri>\n</Namespace>\n<Namespace>\n    <prefix>xlink</prefix>\n    <uri>http://www.w3.org/1999/xlink</uri>\n</Namespace>\n
            "},{"location":"data/app-schema/mapping-file/#includedtypes-optional","title":"includedTypes (optional)","text":"

            Non-feature types (eg. gsml:CompositionPart is a data type that is nested in gsml:GeologicUnit) may be mapped separately for its reusability, but we don't want to configure it as a feature type as we don't want to individually access it. Related feature types don't need to be explicitly included here as it would have its own workspace configuration for GeoServer to find it. The location path in Include tag is relative to the mapping file. For an example, if gsml:CompositionPart configuration file is located in the same directory as the gsml:GeologicUnit configuration:

            <includedTypes>\n    <Include>gsml_CompositionPart.xml</Include>\n</includedTypes>\n
            "},{"location":"data/app-schema/mapping-file/#sourcedatastores","title":"sourceDataStores","text":"

            Every mapping file requires at least one data store to provide data for features. app-schema reuses GeoServer data stores, so there are many available types. See app-schema.data-stores for details of data store configuration. For example:

            <sourceDataStores>\n    <DataStore>\n        <id>datastore</id>\n        <parameters>\n            ...\n        </parameters>\n    </DataStore>\n    ...\n</sourceDataStores>\n

            If you have more than one DataStore in a mapping file, be sure to give them each a distinct id.

            "},{"location":"data/app-schema/mapping-file/#catalog-optional","title":"catalog (optional)","text":"

            The location of an OASIS XML Catalog configuration file, given as a path relative to the mapping file. See app-schema.app-schema-resolution for more information. For example:

            <catalog>../../../schemas/catalog.xml</catalog>\n
            "},{"location":"data/app-schema/mapping-file/#targettypes","title":"targetTypes","text":"

            The targetTypes section lists all the application schemas required to define the mapping. Typically only one is required. For example:

            <targetTypes>\n    <FeatureType>\n        <schemaUri>http://www.geosciml.org/geosciml/2.0/xsd/geosciml.xsd</schemaUri>\n    </FeatureType>\n</targetTypes>\n
            "},{"location":"data/app-schema/mapping-file/#mappings","title":"Mappings","text":""},{"location":"data/app-schema/mapping-file/#typemappings-and-featuretypemapping","title":"typeMappings and FeatureTypeMapping","text":"

            The typeMappings section is the heart of the app-schema module. It defines the mapping from simple features to the nested structure of one or more simple features. It consists of a list of FeatureTypeMapping elements, which each define one output feature type. For example:

            <typeMappings>\n    <FeatureTypeMapping>\n        <mappingName>mappedfeature1</mappingName>\n        <sourceDataStore>datastore</sourceDataStore>\n        <sourceType>mappedfeature</sourceType>\n        <targetElement>gsml:MappedFeature</targetElement>\n        <isDenormalised>true</isDenormalised>\n        <defaultGeometry>gsml:MappedFeature/gsml:shape/gml:Polygon</defaultGeometry>\n        <attributeMappings>\n            <AttributeMapping>\n                ...\n
            • mappingName is an optional tag, to identify the mapping in app-schema.feature-chaining when there are multiple FeatureTypeMapping instances for the same type. This is solely for feature chaining purposes, and would not work for identifying top level features.

            • sourceDataStore must be an identifier you provided when you defined a source data store the sourceDataStores section.

            • sourceType is the simple feature type name. For example:

              • a table or view name, lowercase for PostGIS, uppercase for Oracle.
              • a property file name (without the .properties suffix)
            • targetElement is the element name in the target application schema. This is the same as the WFS feature type name.

            • isDenormalised is an optional tag (default true) to indicate whether this type contains denormalised data or not. If data is not denormalised, then app-schema will build a more efficient query to apply the global feature limit. When combined with a low global feature limit (via Services --> WFS), setting this option to false can prevent unnecessary processing and database lookups from taking place.

            • defaultGeometry can be used to explicitly define the attribute of the feature type that should be used as the default geometry, this is more relevant in WMS than WFS. The default geometry XML path can reference any attribute of the feature type, exactly the same path that would be used to reference the desired property in a OGC filter. The path can reference a nested attribute belonging to a chained feature having a zero or one relationship with the root feature type.

            "},{"location":"data/app-schema/mapping-file/#attributemappings-and-attributemapping","title":"attributeMappings and AttributeMapping","text":"

            attributeMappings comprises a list of AttributeMapping elements:

            <AttributeMapping>\n    <targetAttribute>...</targetAttribute>\n    <idExpression>...</idExpression>\n    <sourceExpression>...</sourceExpression>\n    <targetAttributeNode>...</targetAttributeNode>\n    <isMultiple>...</isMultiple>\n    <ClientProperty>...</ClientProperty>\n</AttributeMapping>\n
            "},{"location":"data/app-schema/mapping-file/#targetattribute","title":"targetAttribute","text":"

            targetAttribute is the XPath to the output element, in the context of the target element. For example, if the containing mapping is for a feature, you should be able to map a gml:name property by setting the target attribute:

            <targetAttribute>gml:name</targetAttribute>\n

            Multivalued attributes resulting from app-schema.denormalised-sources are automatically encoded. If you wish to encode multivalued attributes from different input columns as a specific instance of an attribute, you can use a (one-based) index. For example, you can set the third gml:name with:

            <targetAttribute>gml:name[3]</targetAttribute>\n

            The reserved name FEATURE_LINK is used to map data that is not encoded in XML but is required for use in app-schema.feature-chaining.

            "},{"location":"data/app-schema/mapping-file/#idexpression-optional","title":"idExpression (optional)","text":"

            A CQL expression that is used to set the custom gml:id of the output feature type. This should be the name of a database column on its own. Using functions would cause an exception because it is not supported with the default joining implementation.

            Note

            Every feature must have a gml:id. This requirement is an implementation limitation (strictly, gml:id is optional in GML).

            • If idExpression is unspecified, gml:id will be <the table name>.<primary key>, e.g. MAPPEDFEATURE.1.
            • In the absence of primary keys, this will be <the table name>.<generated gml id>, e.g. MAPPEDFEATURE.fid--46fd41b8_1407138b56f_-7fe0.
            • If using property files instead of database tables, the default gml:id will be the row key found before the equals (\"=\") in the property file, e.g. the feature with row mf1=Mudstone|POINT(1 2)|... will have gml:id mf1.

            Note

            gml:id must be an NCName.

            "},{"location":"data/app-schema/mapping-file/#sourceexpression-optional","title":"sourceExpression (optional)","text":"

            Use a sourceExpression tag to set the element content from source data. For example, to set the element content from a column called DESCRIPTION:

            <sourceExpression><OCQL>DESCRIPTION</OCQL></sourceExpression>\n

            If sourceExpression is not present, the generated element is empty (unless set by another mapping).

            You can use CQL expressions to calculate the content of the element. This example concatenated strings from two columns and a literal:

            <sourceExpression>\n    <OCQL>strConCat(FIRST , strConCat(' followed by ', SECOND))</OCQL>\n</sourceExpression>\n

            You can also use app-schema.cql-functions for vocabulary translations.

            Warning

            Avoid use of CQL expressions for properties that users will want to query, because the current implementation cannot reverse these expressions to generate efficient SQL, and will instead read all features to calculate the property to find the features that match the filter query. Falling back to brute force search makes queries on CQL-calculated expressions very slow. If you must concatenate strings to generate content, you may find that doing this in your database is much faster.

            "},{"location":"data/app-schema/mapping-file/#linkelement-and-linkfield-optional","title":"linkElement and linkField (optional)","text":"

            The presence of linkElement and linkField change the meaning of sourceExpression to a app-schema.feature-chaining mapping, in which the source of the mapping is the feature of type linkElement with property linkField matching the expression. For example, the following sourceExpression uses as the result of the mapping the (possibly multivalued) gsml:MappedFeature for which gml:name[2] is equal to the value of URN for the source feature. This is in effect a foreign key relation:

            <sourceExpression>\n    <OCQL>URN</OCQL>\n    <linkElement>gsml:MappedFeature</linkElement>\n    <linkField>gml:name[2]</linkField>\n</sourceExpression>\n

            The feature type gsml:MappedFeature might be defined in another mapping file. The linkField can be FEATURE_LINK if you wish to relate the features by a property not exposed in XML. See app-schema.feature-chaining for a comprehensive discussion.

            For special cases, linkElement could be an OCQL function, and linkField could be omitted. See app-schema.polymorphism for further information.

            "},{"location":"data/app-schema/mapping-file/#targetattributenode-optional","title":"targetAttributeNode (optional)","text":"

            targetAttributeNode is required wherever a property type contains an abstract element and app-schema cannot determine the type of the enclosed attribute.

            In this example, om:result is of xs:anyType, which is abstract. We can use targetAttributeNode to set the type of the property type to a type that encloses a non-abstract element:

            <AttributeMapping>\n      <targetAttribute>om:result</targetAttribute>\n      <targetAttributeNode>gml:MeasureType</targetAttributeNode>\n      <sourceExpression>\n          <OCQL>TOPAGE</OCQL>\n      </sourceExpression>\n      <ClientProperty>\n          <name>xsi:type</name>\n          <value>'gml:MeasureType'</value>\n      </ClientProperty>\n      <ClientProperty>\n          <name>uom</name> \n          <value>'http://www.opengis.net/def/uom/UCUM/0/Ma'</value>\n      </ClientProperty> \n</AttributeMapping>\n

            If the casting type is complex, the specific type is implicitly determined by the XPath in targetAttribute and targetAttributeNode is not required. E.g., in this example om:result is automatically specialised as a MappedFeatureType:

            <AttributeMapping>\n      <targetAttribute>om:result/gsml:MappedFeature/gml:name</targetAttribute>\n      <sourceExpression>\n          <OCQL>NAME</OCQL>\n      </sourceExpression>\n</AttributeMapping>\n

            Although it is not required, we may still specify targetAttributeNode for the root node, and map the children attributes as per normal. This mapping must come before the mapping for the enclosed elements. By doing this, app-schema will report an exception if a mapping is specified for any of the children attributes that violates the type in targetAttributeNode. E.g.:

            <AttributeMapping>\n      <targetAttribute>om:result</targetAttribute>\n      <targetAttributeNode>gsml:MappedFeatureType<targetAttributeNode>\n</AttributeMapping> \n<AttributeMapping>\n      <targetAttribute>om:result/gsml:MappedFeature/gml:name</targetAttribute>\n      <sourceExpression>\n          <OCQL>NAME</OCQL>\n      </sourceExpression>\n</AttributeMapping>\n

            Note that the GML encoding rules require that complex types are never the direct property of another complex type; they are always contained in a property type to ensure that their type is encoded in a surrounding element. Encoded GML is always type/property/type/property. This is also known as the GML \"striping\" rule. The consequence of this for app-schema mapping files is that targetAttributeNode must be applied to the property and the type must be set to the XSD property type, not to the type of the contained attribute (gsml:CGI_TermValuePropertyType not gsml:CGI_TermValueType). Because the XPath refers to a property type not the encoded content, targetAttributeNode appears in a mapping with targetAttribute and no other elements when using with complex types.

            The XML encoder will encode nested complex features that are mapped to a complex type that does not respect the GML striping rule. The Java configuration property encoder.relaxed can be set to false to disable this behavior.

            "},{"location":"data/app-schema/mapping-file/#encodeifempty-optional","title":"encodeIfEmpty (optional)","text":"

            The encodeIfEmpty element will determine if an attribute will be encoded if it contains a null or empty value. By default encodeIfEmpty is set to false therefore any attribute that does not contain a value will be skipped:

            <encodeIfEmpty>true</encodeIfEmpty>\n

            encodeIfEmpty can be used to bring up attributes that only contain client properties such as xlink:title.

            "},{"location":"data/app-schema/mapping-file/#ismultiple-optional","title":"isMultiple (optional)","text":"

            The isMultiple element states whether there might be multiple values for this attribute, coming from denormalised rows. Because the default value is false and it is omitted in this case, it is most usually seen as:

            <isMultiple>true</isMultiple>\n

            For example, the table below is denormalised with NAME column having multiple values:

            ID NAME DESCRIPTION gu.25678 Yaugher Volcanic Group 1 Olivine basalt, tuff, microgabbro gu.25678 Yaugher Volcanic Group 2 Olivine basalt, tuff, microgabbro

            The configuration file specifies isMultiple for gml:name attribute that is mapped to the NAME column:

            <AttributeMapping>\n    <targetAttribute>gml:name</targetAttribute>                       \n    <sourceExpression>\n        <OCQL>NAME</OCQL>\n</sourceExpression>                 \n<isMultiple>true</isMultiple>\n<ClientProperty>\n    <name>codeSpace</name>\n    <value>'urn:ietf:rfc:2141'</value>\n</ClientProperty>\n</AttributeMapping>\n

            The output produces multiple gml:name attributes for each feature grouped by the id:

            <gsml:GeologicUnit gml:id=\"gu.25678\">\n    <gml:description>Olivine basalt, tuff, microgabbro</gml:description>\n    <gml:name codeSpace=\"urn:ietf:rfc:2141\">Yaugher Volcanic Group 1</gml:name>\n    <gml:name codeSpace=\"urn:ietf:rfc:2141\">Yaugher Volcanic Group 2</gml:name>\n ...\n
            "},{"location":"data/app-schema/mapping-file/#islist-optional","title":"isList (optional)","text":"

            The isList element states whether there might be multiple values for this attribute, concatenated as a list. The usage is similar with isMultiple, except the values appear concatenated inside a single node instead of each value encoded in a separate node. Because the default value is false and it is omitted in this case, it is most usually seen as:

            <isList>true</isList>\n

            For example, the table below has multiple POSITION for each feature:

            +-------+-----------+ | ID | POSITION | +=======+===========+ | ID1.2 | > 1948-05 | +-------+-----------+ | ID1.2 | > 1948-06 | +-------+-----------+ | ID1.2 | > 1948-07 | +-------+-----------+ | ID1.2 | > 1948-08 | +-------+-----------+ | ID1.2 | > 1948-09 | +-------+-----------+

            The configuration file uses isList on timePositionList attribute mapped to POSITION column:

            <AttributeMapping>\n    <targetAttribute>csml:timePositionList</targetAttribute>\n    <sourceExpression>\n    <OCQL>POSITION</OCQL>\n    </sourceExpression>\n    <isList>true</isList>\n</AttributeMapping>\n

            The output produced:

            <csml:pointSeriesDomain>\n    <csml:TimeSeries gml:id=\"ID1.2\">\n        <csml:timePositionList>1949-05 1949-06 1949-07 1949-08 1949-09</csml:timePositionList>\n    </csml:TimeSeries>\n</csml:pointSeriesDomain>\n
            "},{"location":"data/app-schema/mapping-file/#clientproperty-optional-multivalued","title":"ClientProperty (optional, multivalued)","text":"

            A mapping can have one or more ClientProperty elements which set XML attributes on the mapping target. Each ClientProperty has a name and a value that is an arbitrary CQL expression. No OCQL element is used inside value.

            This example of a ClientProperty element sets the codeSpace XML attribute to the literal string urn:ietf:rfc:2141. Note the use of single quotes around the literal string. This could be applied to any target attribute of GML CodeType:

            <ClientProperty>\n    <name>codeSpace</name>\n    <value>'urn:ietf:rfc:2141'</value>\n</ClientProperty>\n

            When the GML association pattern is used to encode a property by reference, the xlink:href attribute is set and the element is empty. This ClientProperty element sets the xlink:href XML attribute to the value of the RELATED_FEATURE_URN field in the data source (for example, a column in an Oracle database table). This mapping could be applied to any property type, such a gml:FeaturePropertyType, or other type modelled on the GML association pattern:

            <ClientProperty>\n    <name>xlink:href</name>\n    <value>RELATED_FEATURE_URN</value>\n</ClientProperty>\n

            See the discussion in app-schema.feature-chaining for the special case in which xlink:href is created for multivalued properties by reference.

            "},{"location":"data/app-schema/mapping-file/#cql","title":"CQL","text":"

            CQL functions enable data conversion and conditional behaviour to be specified in mapping files.

            • See app-schema.cql-functions for information on additional functions provided by the app-schema plugin.

            • The uDig manual includes a list of CQL functions:

              • http://udig.refractions.net/confluence/display/EN/Constraint+Query+Language
            • CQL string literals are enclosed in single quotes, for example 'urn:ogc:def:nil:OGC:missing'.

            "},{"location":"data/app-schema/mapping-file/#database-identifiers","title":"Database identifiers","text":"

            When referring to database table/view names or column names, use:

            • lowercase for PostGIS
            • UPPERCASE for Oracle Spatial
            "},{"location":"data/app-schema/mapping-file/#app-schema.denormalised-sources","title":"Denormalised sources","text":"

            Multivalued properties from denormalised sources (the same source feature ID appears more than once) are automatically encoded. For example, a view might have a repeated id column with varying name so that an arbitrarily large number of gml:name properties can be encoded for the output feature.

            Warning

            Denormalised sources must grouped so that features with duplicate IDs are provided without any intervening features. This can be achieved by ensuring that denormalised source features are sorted by ID. Failure to observe this restriction will result in data corruption. This restriction is however not necessary when using app-schema.joining because then ordering will happen automatically.

            "},{"location":"data/app-schema/mapping-file/#attributes-with-cardinality-1n","title":"Attributes with cardinality 1..N","text":"

            Consider the following two tables, the first table contains information related to meteorological stations:

            ID NAME st.1 Station 1 st.2 Station 2

            The second table contains tags that are associated with meteorological stations:

            ID STATION_ID TAG CODE tg.1 st.1 temperature X1Y tg.2 st.1 wind X2Y tg.3 st.2 pressure X3Y

            A station can have multiple tags, establishing a one to many relationship between stations and tags, the GML representation of the first station should look like this:

            (...)\n<st:Station gml:id=\"st.1\">\n  <st:name>Station 1</st:name>\n  <st:tag st:code=\"X1Y\">temperature</st:tag>\n  <st:tag st:code=\"X2Y\">wind</st:tag>\n</st:Station_gml32>\n(...)\n

            Mappings with a one to many relationship are supported with a custom syntax in JDBC based data stores and Apache Solr data store.

            "},{"location":"data/app-schema/mapping-file/#sql-based-data-stores","title":"SQL based data stores","text":"

            When using JDBC based data stores attributes with a 1..N relationship can be mapped like this:

            (...)\n<AttributeMapping>\n  <targetAttribute>st:tag</targetAttribute>\n  <jdbcMultipleValue>\n    <sourceColumn>ID</sourceColumn>\n    <targetTable>TAGS</targetTable>\n    <targetColumn>STATION_ID</targetColumn>\n    <targetValue>TAG</targetValue>\n  </jdbcMultipleValue>\n  <ClientProperty>\n    <name>st:code</name>\n    <value>CODE</value>\n  </ClientProperty>\n</AttributeMapping>\n(...)\n

            The targetValue refers to the value of the <st:tag> element, the client property is mapped with the usual syntax. Behind the scenes App-Schema will take care of associating the st:code attribute value with the correct tag.

            Another variant of this feature can be used for nested elements on an unbounded anonymous sequence, Using 'anonymousAttribute' element definition for generating child elements and values inside an anonymous umbounded sequence:

            (...)\n<AttributeMapping>\n  <targetAttribute>st:tag</targetAttribute>\n  <jdbcMultipleValue>\n    <sourceColumn>ID</sourceColumn>\n    <targetTable>TAGS</targetTable>\n    <targetColumn>STATION_ID</targetColumn>\n  </jdbcMultipleValue>\n  <anonymousAttribute>\n    <name>st:code</name>\n    <value>CODE</value>\n  </anonymousAttribute>\n</AttributeMapping>\n(...)\n

            In this case 'st:code' element children will be generated with the computed client property value:

            (...)\n<st:Station gml:id=\"st.1\">\n  <st:name>Station 1</st:name>\n  <st:tag>\n    <st:code>X1Y</st:code>\n    <st:code>X2Y</st:code>\n  </st:tag>\n</st:Station_gml32>\n(...)\n

            Having an schema with anonymous unbounded sequence like :

            <xs:complexType name=\"StationType\">\n  <xs:complexContent>\n    <xs:extension base=\"gml:AbstractFeatureType\">\n      <xs:sequence>\n        <xs:element name=\"name\" type=\"xs:string\"/>\n        <xs:element name=\"contact\" type=\"st:ContactPropertyType\"/>\n        <xs:element name=\"location\" type=\"gml:GeometryPropertyType\"/>\n        <xs:element maxOccurs=\"unbounded\" minOccurs=\"0\" name=\"tag\" type=\"st:TagType\"/>\n        <xs:element name=\"measurements\" type=\"ms:MeasurementPropertyType\" minOccurs=\"0\" maxOccurs=\"unbounded\"/>\n        <xs:element name=\"maintainer\" minOccurs=\"0\">\n          <xs:complexType>\n            <xs:sequence maxOccurs=\"unbounded\">\n              <xs:element name=\"name\" type=\"xs:string\"/>\n              <xs:element name=\"level\" type=\"xs:integer\" nillable=\"true\"/>\n              <xs:element name=\"classType\" />\n            </xs:sequence>\n          </xs:complexType>\n        </xs:element>\n      </xs:sequence>\n    </xs:extension>\n  </xs:complexContent>\n</xs:complexType>\n

            We could define the following mapping :

            <FeatureTypeMapping>\n <sourceDataStore>stations_gml32</sourceDataStore>\n <sourceType>stations_gml32</sourceType>\n <targetElement>st_gml32:Station_gml32</targetElement>\n <attributeMappings>\n   <AttributeMapping>\n     <targetAttribute>st_gml32:Station_gml32</targetAttribute>\n     <idExpression>\n       <OCQL>ID</OCQL>\n     </idExpression>\n   </AttributeMapping>\n   <AttributeMapping>\n     <targetAttribute>st_gml32:name</targetAttribute>\n     <sourceExpression>\n       <OCQL>NAME</OCQL>\n     </sourceExpression>\n   </AttributeMapping>\n   <AttributeMapping>\n     <targetAttribute>st_gml32:location</targetAttribute>\n     <sourceExpression>\n       <OCQL>LOCATION</OCQL>\n     </sourceExpression>\n   </AttributeMapping>\n   <AttributeMapping>\n     <targetAttribute>st_gml32:maintainer</targetAttribute>\n     <jdbcMultipleValue>\n       <sourceColumn>ID</sourceColumn>\n       <targetTable>MAINTAINERS_GML32</targetTable>\n       <targetColumn>OWNER</targetColumn>\n     </jdbcMultipleValue>\n     <anonymousAttribute>\n       <name>st_gml32:name</name>\n       <value>NAME</value>\n     </anonymousAttribute>\n     <anonymousAttribute>\n       <name>st_gml32:level</name>\n       <value>LEVEL</value>\n     </anonymousAttribute>\n     <anonymousAttribute>\n       <name>st_gml32:classType</name>\n       <value>CLASSTYPE</value>\n     </anonymousAttribute>\n   </AttributeMapping>\n   <AttributeMapping>\n     <targetAttribute>st_gml32:measurements</targetAttribute>\n     <sourceExpression>\n       <OCQL>ID</OCQL>\n       <linkElement>ms_gml32:Measurement_gml32</linkElement>\n       <linkField>FEATURE_LINK[1]</linkField>\n     </sourceExpression>\n   </AttributeMapping>\n </attributeMappings>\n</FeatureTypeMapping>\n

            So Geoserver will produce GML like this :

            <st_gml32:Station_gml32 gml:id=\"st.2\">\n  <st_gml32:name>station2</st_gml32:name>\n  <st_gml32:location>\n    <gml:Point srsDimension=\"2\" srsName=\"urn:ogc:def:crs:EPSG::4326\">\n      <gml:pos>-3 -2</gml:pos>\n    </gml:Point>\n  </st_gml32:location>\n  <st_gml32:measurements>\n    <ms_gml32:Measurement_gml32 gml:id=\"ms.3\">\n      <ms_gml32:name>pressure</ms_gml32:name>\n      <ms_gml32:tag>pressure_tag</ms_gml32:tag>\n    </ms_gml32:Measurement_gml32>\n  </st_gml32:measurements>\n  <st_gml32:maintainer>\n    <st_gml32:name>mnt_c</st_gml32:name>\n    <st_gml32:level>73</st_gml32:level>\n    <st_gml32:classType>st_2_mnt_c</st_gml32:classType>\n    <st_gml32:name>mnt_d</st_gml32:name>\n    <st_gml32:level>74</st_gml32:level>\n    <st_gml32:classType>st_2_mnt_d</st_gml32:classType>\n    <st_gml32:name>mnt_e</st_gml32:name>\n    <st_gml32:level>75</st_gml32:level>\n    <st_gml32:classType>st_2_mnt_e</st_gml32:classType>\n  </st_gml32:maintainer>\n</st_gml32:Station_gml32>\n
            "},{"location":"data/app-schema/mapping-file/#apache-solr","title":"Apache Solr","text":"

            When using Apache Solr data stores, 1..N relationships can be handled with multiValued fields and mapped like this:

            (...)\n<AttributeMapping>\n  <targetAttribute>st:tag</targetAttribute>\n  <solrMultipleValue>TAG</solrMultipleValue>\n  <ClientProperty>\n    <name>st:code</name>\n    <value>CODE</value>\n  </ClientProperty>\n</AttributeMapping>\n(...)\n
            "},{"location":"data/app-schema/mapping-file/#external-apache-solr-index","title":"External Apache Solr Index","text":"

            Is possible to use an external Apache Solr index to speed up text based searches. Consider the following WFS GetFeatureRequest:

            <wfs:GetFeature service=\"WFS\" version=\"2.0.0\" xmlns:fes=\"http://www.opengis.net/fes/2.0\" xmlns:gml=\"http://www.opengis.net/gml/3.2.1\" xmlns:wfs=\"http://www.opengis.net/wfs/2.0\">\n  <wfs:Query typeNames=\"st:Station\">\n    <fes:Filter>\n      <fes:PropertyIsLike escapeChar=\"!\" singleChar=\".\" wildCard=\"*\">\n        <fes:ValueReference>st:Station/st:measurement/st:Measurement/st:description</fes:ValueReference>\n        <fes:Literal>*high*</fes:Literal>\n      </fes:PropertyIsLike>\n    </fes:Filter>\n  </wfs:Query>\n</wfs:GetFeature>\n

            This request will return all the stations that have at least one measurement that contains the text high in its description. This type of text based queries are (usually) quite expensive to execute in relational data bases.

            Apache Solr is a well known open source project that aims to solve those type of performance issues, it allow us to index several fields and efficiently query those fields. Although Apache Solr allow us to index several types of fields, e.g. numbers or even latitudes longitudes, where it really shines is when dealing with text fields and text based queries.

            The goal of external indexes is to allow App-Schema to take advantage of Apache Solr text searches performance and at the same time to take advantage of relational databases relational capabilities. In practice, this means that the full data will be stored in the relational database and we will only need to index in Apache Solr the fields we need to improve our text based queries.

            Using the stations use case as an example, our data will be stored in a relational database, e.g. PostgreSQL, and we will index the possible descriptions measurements values in an Apache Solr index.

            Our mapping file will look like this:

            <as:AppSchemaDataAccess xmlns:as=\"http://www.geotools.org/app-schema\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xsi:schemaLocation=\"http://www.geotools.org/app-schema AppSchemaDataAccess.xsd\">\n  <namespaces>\n    <Namespace>\n      <prefix>gml</prefix>\n      <uri>http://www.opengis.net/gml/3.2</uri>\n    </Namespace>\n    <Namespace>\n      <prefix>st</prefix>\n      <uri>http://www.stations.org/1.0</uri>\n    </Namespace>\n  </namespaces>\n  <sourceDataStores>\n    <SolrDataStore>\n      <id>stations_solr</id>\n      <url>http://localhost:8983/solr/stations_index</url>\n      <index name=\"stations_index\"/>\n    </SolrDataStore>\n    <DataStore>\n      <id>stations_db</id>\n      <parameters>\n        <Parameter>\n          <name>dbtype</name>\n          <value>postgisng</value>\n        </Parameter>\n      </parameters>\n    </DataStore>\n  </sourceDataStores>\n  <targetTypes>\n    <FeatureType>\n      <schemaUri>./stations.xsd</schemaUri>\n    </FeatureType>\n  </targetTypes>\n  <typeMappings>\n    <FeatureTypeMapping>\n      <sourceDataStore>stations_db</sourceDataStore>\n      <sourceType>stations</sourceType>\n      <targetElement>st:Station</targetElement>\n      <!-- configure the index data store for this feature type -->\n      <indexDataStore>stations_solr</indexDataStore>\n      <indexType>stations_index</indexType>\n      <attributeMappings>\n        <AttributeMapping>\n          <targetAttribute>st:Station</targetAttribute>\n          <idExpression>\n            <OCQL>id</OCQL>\n          </idExpression>\n          <!-- the Solr index field that matches this feature type table primary key -->\n          <indexField>id</indexField>\n        </AttributeMapping>\n        <AttributeMapping>\n          <targetAttribute>st:name</targetAttribute>\n          <sourceExpression>\n            <OCQL>name</OCQL>\n          </sourceExpression>\n        </AttributeMapping>\n        <AttributeMapping>\n          <targetAttribute>st:measurement</targetAttribute>\n          <sourceExpression>\n            <OCQL>id</OCQL>\n            <linkElement>st:Measurement</linkElement>\n            <linkField>FEATURE_LINK[1]</linkField>\n          </sourceExpression>\n          <isMultiple>true</isMultiple>\n        </AttributeMapping>\n      </attributeMappings>\n    </FeatureTypeMapping>\n    <FeatureTypeMapping>\n      <sourceDataStore>stations_db</sourceDataStore>\n      <sourceType>measurements</sourceType>\n      <targetElement>st:Measurement</targetElement>\n      <attributeMappings>\n        <AttributeMapping>\n          <targetAttribute>st:Measurement</targetAttribute>\n          <idExpression>\n            <OCQL>id</OCQL>\n          </idExpression>\n        </AttributeMapping>\n        <AttributeMapping>\n          <targetAttribute>st:description</targetAttribute>\n          <sourceExpression>\n            <OCQL>description</OCQL>\n          </sourceExpression>\n          <!-- the Solr index field that indexes the description possible values -->\n          <indexField>description_txt</indexField>\n        </AttributeMapping>\n        <AttributeMapping>\n          <targetAttribute>FEATURE_LINK[1]</targetAttribute>\n          <sourceExpression>\n            <OCQL>station_id</OCQL>\n          </sourceExpression>\n        </AttributeMapping>\n      </attributeMappings>\n    </FeatureTypeMapping>\n  </typeMappings>\n</as:AppSchemaDataAccess>\n

            To be able to use an external Apache Solr index, we need at least to:

            • declare the Solr data store and the index: this is done in the root feature type mapping, e.g. st:Station.
            • map the Solr index field that matches the database primary key: this is done id mapping of the root feature type, e.g.<indexField>id</indexField>.
            • map each attribute that is indexed in Apache Solr: this is done using the indexField element, e.g <indexField>description_txt</indexField>.

            Is worth mentioning that if an external Solr index was defined, App-Schema will always query the external Solr index first and then query the relational database.

            "},{"location":"data/app-schema/mongo-tutorial/","title":"MongoDB Tutorial","text":"

            This tutorial demonstrates how to use app-schema plugin with a MongoDB data store. This tutorial will focus on the MongoDB data store specificities is highly recommended to read the app-schema documentation before.

            "},{"location":"data/app-schema/mongo-tutorial/#use-case","title":"Use Case","text":"

            The use case for this tutorial will be to serve through app-schema the information about some meteorological stations stored in a MongoDB database. Note that this use case is completely fictional and only used to demonstrate the MongoDB and app-schema integration.

            First of all let's insert some test data in a MongoDB data store:

            db.stations.insert({\n    \"id\": \"1\",\n    \"name\": \"station 1\",\n    \"contact\": {\n        \"mail\": \"station1@mail.com\"\n    },\n    \"geometry\": {\n        \"coordinates\": [\n            50,\n            60\n        ],\n        \"type\": \"Point\"\n    },\n    \"measurements\": [\n        {\n            \"name\": \"temp\",\n            \"unit\": \"c\",\n            \"values\": [\n                {\n                    \"time\": 1482146800,\n                    \"value\": 20\n                }\n            ]\n        },\n        {\n            \"name\": \"wind\",\n            \"unit\": \"km/h\",\n            \"values\": [\n                {\n                    \"time\": 1482146833,\n                    \"value\": 155\n                }\n            ]\n        }\n    ]\n})\n\ndb.stations.insert({\n    \"id\": \"2\",\n    \"name\": \"station 2\",\n    \"contact\": {\n        \"mail\": \"station2@mail.com\"\n    },\n    \"geometry\": {\n        \"coordinates\": [\n            100,\n            -50\n        ],\n        \"type\": \"Point\"\n    },\n    \"measurements\": [\n        {\n            \"name\": \"temp\",\n            \"unit\": \"c\",\n            \"values\": [\n                {\n                    \"time\": 1482146911,\n                    \"value\": 35\n                },\n                {\n                    \"time\": 1482146935,\n                    \"value\": 25\n                }\n            ]\n        },\n        {\n            \"name\": \"wind\",\n            \"unit\": \"km/h\",\n            \"values\": [\n                {\n                    \"time\": 1482146964,\n                    \"value\": 80\n                }\n            ]\n        },\n        {\n            \"name\": \"pression\",\n            \"unit\": \"pa\",\n            \"values\": [\n                {\n                    \"time\": 1482147026,\n                    \"value\": 1019\n                },\n                {\n                    \"time\": 1482147051,\n                    \"value\": 1015\n                }\n            ]\n        }\n    ]\n})\n\ndb.stations.createIndex({\n    \"geometry\": \"2dsphere\"\n})\n

            This is the schema that will be used to do the mappings in app-schema:

            <xs:schema version=\"1.0\" xmlns:xs=\"http://www.w3.org/2001/XMLSchema\"\n           xmlns:gml=\"http://www.opengis.net/gml\"\n           xmlns:st=\"http://www.stations.org/1.0\"\n           targetNamespace=\"http://www.stations.org/1.0\"\n           elementFormDefault=\"qualified\" attributeFormDefault=\"unqualified\">\n\n  <xs:import namespace=\"http://www.opengis.net/gml\"\n             schemaLocation=\"http://schemas.opengis.net/gml/3.2.1/gml.xsd\"/>\n\n  <xs:complexType name=\"ContactType\">\n    <xs:sequence>\n      <xs:element name=\"mail\" minOccurs=\"0\" maxOccurs=\"1\" type=\"xs:string\"/>\n    </xs:sequence>\n  </xs:complexType>\n\n  <xs:complexType name=\"MeasurementPropertyType\">\n    <xs:sequence minOccurs=\"0\">\n      <xs:element ref=\"st:Measurement\"/>\n    </xs:sequence>\n    <xs:attributeGroup ref=\"gml:AssociationAttributeGroup\"/>\n  </xs:complexType>\n\n  <xs:complexType name=\"MeasurementType\" abstract=\"true\">\n    <xs:sequence>\n      <xs:element name=\"name\" minOccurs=\"1\" maxOccurs=\"1\" type=\"xs:string\"/>\n      <xs:element name=\"unit\" minOccurs=\"1\" maxOccurs=\"1\" type=\"xs:string\"/>\n      <xs:element name=\"values\" minOccurs=\"1\" maxOccurs=\"unbounded\" type=\"st:ValuePropertyType\"/>\n    </xs:sequence>\n  </xs:complexType>\n\n  <xs:complexType name=\"ValuePropertyType\">\n    <xs:sequence minOccurs=\"0\">\n      <xs:element ref=\"st:Value\"/>\n    </xs:sequence>\n    <xs:attributeGroup ref=\"gml:AssociationAttributeGroup\"/>\n  </xs:complexType>\n\n  <xs:complexType name=\"ValueType\">\n    <xs:sequence>\n      <xs:element name=\"timestamp\" minOccurs=\"1\" maxOccurs=\"1\" type=\"xs:long\"/>\n      <xs:element name=\"value\" minOccurs=\"1\" maxOccurs=\"1\" type=\"xs:double\"/>\n    </xs:sequence>\n  </xs:complexType>\n\n  <xs:complexType name=\"StationFeatureType\">\n    <xs:complexContent>\n      <xs:extension base=\"gml:AbstractFeatureType\">\n        <xs:sequence>\n          <xs:element name=\"name\" minOccurs=\"1\" maxOccurs=\"1\" type=\"xs:string\"/>\n          <xs:element name=\"contact\" minOccurs=\"0\" maxOccurs=\"1\" type=\"st:ContactType\"/>\n          <xs:element name=\"measurement\" minOccurs=\"0\" maxOccurs=\"unbounded\" type=\"st:MeasurementPropertyType\"/>\n          <xs:element name=\"geometry\" type=\"gml:GeometryPropertyType\" minOccurs=\"0\" maxOccurs=\"1\"/>\n        </xs:sequence>\n      </xs:extension>\n    </xs:complexContent>\n  </xs:complexType>\n\n  <xs:element name=\"StationFeature\" type=\"st:StationFeatureType\"  substitutionGroup=\"gml:_Feature\"/>\n  <xs:element name=\"Measurement\" type=\"st:MeasurementType\"  substitutionGroup=\"gml:_Feature\"/>\n  <xs:element name=\"Value\" type=\"st:ValueType\"  substitutionGroup=\"gml:_Feature\"/>\n\n</xs:schema>\n
            "},{"location":"data/app-schema/mongo-tutorial/#mappings","title":"Mappings","text":""},{"location":"data/app-schema/mongo-tutorial/#mongodb-store","title":"MongoDB Store","text":"

            When configuring app-schema mappings for a MongoDB source some connection parameters tweaks might be needed, in order to ensure that the full set of recognized and made available to the mapping. The setup of a MongoDB Store implies the creation of a Mongo schema, inferred from the db collection. This process by default will use a random Mongo object from the collection. If that object doesn't contain all attributes of interest, the result will be an incomplete schema. This behaviour can thus be controlled by means of the following two parameters, which should be provided inside the <parameters> element under the <DataStore> node:

            • objs_id_schema, which specifies a comma separated list of MongoDB JSON object to be used to build the schema (not needed if max_objs_schema is present).
            <Parameter>\n  <name>objs_id_schema</name>\n  <value>6eb85d889396eb0475f815ef,6eb85d889396eb0475f815eg</value>\n</Parameter>\n
            • max_objs_schema, which specifies the max number of MongoDB JSON object to be used to build the schema and where a value of -1 means all the objects present in the collection (not needed if objs_id_schema is present).
            <Parameter>\n  <name>max_objs_schema</name>\n  <value>-1</value>\n</Parameter>\n

            Both parameters can also be specified via the REST API, see Cleaning schemas on internal MongoDB stores for more details.

            "},{"location":"data/app-schema/mongo-tutorial/#nested-elements","title":"Nested elements","text":"

            MongoDB objects may contain nested elements and nested collections. The following three functions make possible to select nested elements and link nested collections using a JSON path:

            Function Example Description

            jsonSelect jsonSelect('contact.mail') Used to retrieve the value for the mapping from a MongoDB object.

            collectionLink collectionLink('measurements.values') Used when chaining entities with a nested collection.

            collectionId collectionId() Instructs the mapper to generate a ID for the nested collection.

            nestedCollectionLink nestedCollectionLink() Used on the nested collection to create a link with the parent feature.

            "},{"location":"data/app-schema/mongo-tutorial/#mappings-file-example","title":"Mappings file example","text":"

            A station data is composed of some meta-information about the station and a list of measurements. Each measurement as some meta-information and contains a list of values. The mappings will contain three top entities: the station, the measurements and the values.

            Follows a the complete mappings file:

            <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<as:AppSchemaDataAccess xmlns:as=\"http://www.geotools.org/app-schema\"\n                      xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\"\n                      xsi:schemaLocation=\"http://www.geotools.org/app-schema AppSchemaDataAccess.xsd\">\n<namespaces>\n  <Namespace>\n    <prefix>st</prefix>\n    <uri>http://www.stations.org/1.0</uri>\n  </Namespace>\n  <Namespace>\n    <prefix>gml</prefix>\n    <uri>http://www.opengis.net/gml</uri>\n  </Namespace>\n</namespaces>\n\n<sourceDataStores>\n  <DataStore>\n    <id>data_source</id>\n    <parameters>\n      <Parameter>\n        <name>data_store</name>\n        <value>mongodb://{mongoHost}:{mongoPort}/{dataBaseName}</value>\n      </Parameter>\n      <Parameter>\n        <name>namespace</name>\n        <value>http://www.stations.org/1.0</value>\n      </Parameter>\n      <Parameter>\n        <name>schema_store</name>\n        <value>file:{schemaStore}</value>\n      </Parameter>\n      <Parameter>\n        <name>data_store_type</name>\n        <value>complex</value>\n      </Parameter>\n      <Parameter>\n          <name>max_objs_schema</name>\n          <value>-1</value>\n      </Parameter>\n    </parameters>\n  </DataStore>\n</sourceDataStores>\n\n<targetTypes>\n  <FeatureType>\n    <schemaUri>stations.xsd</schemaUri>\n  </FeatureType>\n</targetTypes>\n\n<typeMappings>\n  <FeatureTypeMapping>\n    <sourceDataStore>data_source</sourceDataStore>\n    <sourceType>{collectionName}</sourceType>\n    <targetElement>st:StationFeature</targetElement>\n    <attributeMappings>\n      <AttributeMapping>\n        <targetAttribute>st:StationFeature</targetAttribute>\n        <idExpression>\n          <OCQL>jsonSelect('id')</OCQL>\n        </idExpression>\n      </AttributeMapping>\n      <AttributeMapping>\n        <targetAttribute>st:name</targetAttribute>\n        <sourceExpression>\n          <OCQL>jsonSelect('name')</OCQL>\n        </sourceExpression>\n      </AttributeMapping>\n      <AttributeMapping>\n        <targetAttribute>st:contact/st:mail</targetAttribute>\n        <sourceExpression>\n          <OCQL>jsonSelect('contact.mail')</OCQL>\n        </sourceExpression>\n      </AttributeMapping>\n      <AttributeMapping>\n        <targetAttribute>st:measurement</targetAttribute>\n        <sourceExpression>\n          <OCQL>collectionLink('measurements')</OCQL>\n          <linkElement>aaa</linkElement>\n          <linkField>FEATURE_LINK[1]</linkField>\n        </sourceExpression>\n        <isMultiple>true</isMultiple>\n      </AttributeMapping>\n      <AttributeMapping>\n        <targetAttribute>st:geometry</targetAttribute>\n        <sourceExpression>\n          <OCQL>jsonSelect('geometry')</OCQL>\n        </sourceExpression>\n      </AttributeMapping>\n    </attributeMappings>\n  </FeatureTypeMapping>\n  <FeatureTypeMapping>\n    <sourceDataStore>data_source</sourceDataStore>\n    <sourceType>{collectionName}</sourceType>\n    <mappingName>aaa</mappingName>\n    <targetElement>st:Measurement</targetElement>\n    <attributeMappings>\n      <AttributeMapping>\n        <targetAttribute>st:Measurement</targetAttribute>\n        <idExpression>\n          <OCQL>collectionId()</OCQL>\n        </idExpression>\n      </AttributeMapping>\n      <AttributeMapping>\n        <targetAttribute>st:name</targetAttribute>\n        <sourceExpression>\n          <OCQL>jsonSelect('name')</OCQL>\n        </sourceExpression>\n      </AttributeMapping>\n      <AttributeMapping>\n        <targetAttribute>st:unit</targetAttribute>\n        <sourceExpression>\n          <OCQL>jsonSelect('unit')</OCQL>\n        </sourceExpression>\n      </AttributeMapping>\n      <AttributeMapping>\n        <targetAttribute>st:values</targetAttribute>\n        <sourceExpression>\n          <OCQL>collectionLink('values')</OCQL>\n          <linkElement>st:Value</linkElement>\n          <linkField>FEATURE_LINK[2]</linkField>\n        </sourceExpression>\n        <isMultiple>true</isMultiple>\n      </AttributeMapping>\n      <AttributeMapping>\n        <targetAttribute>FEATURE_LINK[1]</targetAttribute>\n        <sourceExpression>\n          <OCQL>nestedCollectionLink()</OCQL>\n        </sourceExpression>\n      </AttributeMapping>\n    </attributeMappings>\n  </FeatureTypeMapping>\n  <FeatureTypeMapping>\n    <sourceDataStore>data_source</sourceDataStore>\n    <sourceType>{collectionName}</sourceType>\n    <targetElement>st:Value</targetElement>\n    <attributeMappings>\n      <AttributeMapping>\n        <targetAttribute>st:Value</targetAttribute>\n        <idExpression>\n          <OCQL>collectionId()</OCQL>\n        </idExpression>\n      </AttributeMapping>\n      <AttributeMapping>\n        <targetAttribute>st:timestamp</targetAttribute>\n        <sourceExpression>\n          <OCQL>jsonSelect('time')</OCQL>\n        </sourceExpression>\n      </AttributeMapping>\n      <AttributeMapping>\n        <targetAttribute>st:value</targetAttribute>\n        <sourceExpression>\n          <OCQL>jsonSelect('value')</OCQL>\n        </sourceExpression>\n      </AttributeMapping>\n      <AttributeMapping>\n        <targetAttribute>FEATURE_LINK[2]</targetAttribute>\n        <sourceExpression>\n          <OCQL>nestedCollectionLink()</OCQL>\n        </sourceExpression>\n      </AttributeMapping>\n    </attributeMappings>\n  </FeatureTypeMapping>\n</typeMappings>\n\n</as:AppSchemaDataAccess>\n

            The mappings for the attributes are straightforward, for example the following mapping:

            <AttributeMapping>\n    <targetAttribute>st:contact/st:mail</targetAttribute>\n    <sourceExpression>\n        <OCQL>jsonSelect('contact.mail')</OCQL>\n    </sourceExpression>\n</AttributeMapping>\n

            The mapping above defines that the contact mail for a station will be available at the JSON path contact.mail and that the correspondent XML schema element is the XPATH st:contact/st:mail.

            The feature chaining is a little bit more complex. Let's take as an example the chaining between StationFeature and Measurement features. In the StationFeature feature type the link to the Measurement entity is defined with the following mapping:

            <AttributeMapping>\n    <targetAttribute>st:measurement</targetAttribute>\n    <sourceExpression>\n        <OCQL>collectionLink('measurements')</OCQL>\n        <linkElement>st:Measurement</linkElement>\n        <linkField>FEATURE_LINK[1]</linkField>\n    </sourceExpression>\n    <isMultiple>true</isMultiple>\n</AttributeMapping>\n

            and in the Measurement feature type the link to the parent feature is defined with the following mapping:

            <AttributeMapping>\n    <targetAttribute>FEATURE_LINK[1]</targetAttribute>\n    <sourceExpression>\n        <OCQL>nestedCollectionLink()</OCQL>\n    </sourceExpression>\n</AttributeMapping>\n

            With the two mapping above we tie the two features types together. When working with a MongoDB data store this mappings will always be petty much the same, only the nested collection path and the feature link index need to be updated. Note that the JSON path of the nested collections attributes are relative to the parent.

            "},{"location":"data/app-schema/mongo-tutorial/#querying","title":"Querying","text":"

            To create an MongoDB app-schema layer in GeoServer, the app-schema extension and the mongo-complex extension needs to be installed.

            A workspace for each name space declared in the mappings file needs to be created, in this case the workspace st with URI http://www.stations.org/1.0 needs to be created. No need to create a gml workspace.

            Creating a MongoDB app-schema layer is similar to any other app-schema layer, just create an app-schema store pointing to the correct mappings file and select the layer correspondent to the top entity, in this case st:StationFeature.

            Is possible to query with WFS complex features encoded in GML and GeoJson using complex features filtering capabilities. For example, querying all the stations that have a measurement value with a time stamp superior to 1482146964:

            <wfs:Query typeName=\"st:StationFeature\">\n    <ogc:Filter>\n        <ogc:Filter>\n            <ogc:PropertyIsGreaterThan>\n                    <ogc:PropertyName>  \n                        st:StationFeature/st:measurement/st:values/st:timestamp\n                    </ogc:PropertyName>\n                    <ogc:Literal>\n                        1482146964\n                    </ogc:Literal>\n                </ogc:PropertyIsGreaterThan>\n        </ogc:Filter>\n    </ogc:Filter>\n</wfs:Query>\n
            "},{"location":"data/app-schema/polymorphism/","title":"Polymorphism","text":"

            Polymorphism in this context refers to the ability of an attribute to have different forms. Depending on the source value, it could be encoded with a specific structure, type, as an xlink:href reference, or not encoded at all. To achieve this, we reuse feature chaining syntax and allow OCQL functions in the linkElement tag. Read more about app-schema.feature-chaining, if you're not familiar with the syntax.

            "},{"location":"data/app-schema/polymorphism/#data-type-polymorphism","title":"Data-type polymorphism","text":"

            You can use normal feature chaining to get an attribute to be encoded as a certain type. For example:

            <AttributeMapping>                                                                                                                                                                                                                                                                                                                                                                                                    \n    <targetAttribute>ex:someAttribute</targetAttribute>\n    <sourceExpression>\n        <OCQL>VALUE_ID</OCQL>\n      <linkElement>NumericType</linkElement>\n      <linkField>FEATURE_LINK</linkField>\n    </sourceExpression>\n</AttributeMapping>\n<AttributeMapping>\n    <targetAttribute>ex:someAttribute</targetAttribute>\n    <sourceExpression>\n      <OCQL>VALUE_ID</OCQL>\n      <linkElement>gsml:CGI_TermValue</linkElement>\n      <linkField>FEATURE_LINK</linkField>\n    </sourceExpression>\n</AttributeMapping>\n

            Note: NumericType here is a mappingName, whereas gsml:CGI_TermValue is a targetElement.

            In the above example, ex:someAttribute would be encoded with the configuration in NumericType if the foreign key matches the linkField. Both instances would be encoded if the foreign key matches the candidate keys in both linked configurations. Therefore this would only work for 0 to many relationships.

            Functions can be used for single attribute instances. See useful functions for a list of commonly used functions. Specify the function in the linkElement, and it would map it to the first matching FeatureTypeMapping. For example:

            <AttributeMapping>\n    <targetAttribute>ex:someAttribute</targetAttribute>   \n    <sourceExpression>\n      <OCQL>VALUE_ID</OCQL>   \n      <linkElement>\n        Recode(CLASS_TEXT, 'numeric', 'NumericType', 'literal', 'gsml:CGI_TermValue')\n        </linkElement>\n      <linkField>FEATURE_LINK</linkField>\n    </sourceExpression>                   \n    <isMultiple>true</isMultiple>\n</AttributeMapping>\n

            The above example means, if the CLASS_TEXT value is 'numeric', it would link to 'NumericType' FeatureTypeMapping, with VALUE_ID as foreign key to the linked type. It would require all the potential matching types to have a common attribute that is specified in linkField. In this example, the linkField is FEATURE_LINK, which is a fake attribute used only for feature chaining. You can omit the linkField and OCQL if the FeatureTypeMapping being linked to has the same sourceType with the container type. This would save us from unnecessary extra queries, which would affect performance. For example:

            FeatureTypeMapping of the container type:

            <FeatureTypeMapping>\n    <sourceDataStore>PropertyFiles</sourceDataStore>\n    <sourceType>PolymorphicFeature</sourceType>\n

            FeatureTypeMapping of NumericType points to the same table:

            <FeatureTypeMapping>\n    <mappingName>NumericType</mappingName>\n    <sourceDataStore>PropertyFiles</sourceDataStore>\n    <sourceType>PolymorphicFeature</sourceType>\n

            FeatureTypeMapping of gsml:CGI_TermValue also points to the same table:

            <FeatureTypeMapping>\n    <sourceDataStore>PropertyFiles</sourceDataStore>\n    <sourceType>PolymorphicFeature</sourceType>\n    <targetElement>gsml:CGI_TermValue</targetElement>\n

            In this case, we can omit linkField in the polymorphic attribute mapping:

            <AttributeMapping>\n    <targetAttribute>ex:someAttribute</targetAttribute>   \n    <sourceExpression>\n      <linkElement>\n        Recode(CLASS_TEXT, 'numeric', 'NumericType', 'literal', 'gsml:CGI_TermValue')\n        </linkElement>\n    </sourceExpression>                   \n    <isMultiple>true</isMultiple>\n</AttributeMapping>\n
            "},{"location":"data/app-schema/polymorphism/#referential-polymorphism","title":"Referential polymorphism","text":"

            This is when an attribute is set to be encoded as an xlink:href reference on the top level. When the scenario only has reference cases in it, setting a function in Client Property will do the job. E.g.:

            <AttributeMapping>\n  <targetAttribute>ex:someAttribute</targetAttribute>\n  <ClientProperty>\n    <name>xlink:href</name>\n    <value>if_then_else(isNull(NUMERIC_VALUE), 'urn:ogc:def:nil:OGC:1.0:missing', strConcat('#', NUMERIC_VALUE))</value>\n    </ClientProperty>\n</AttributeMapping>\n

            The above example means, if NUMERIC_VALUE is null, the attribute should be encoded as:

            <ex:someAttribute xlink:href=\"urn:ogc:def:nil:OGC:1.0:missing\">\n

            Otherwise, it would be encoded as:

            <ex:someAttribute xlink:href=\"#123\">\n    where NUMERIC_VALUE = '123'\n

            However, this is not possible when we have cases where a fully structured attribute is also a possibility. The toxlinkhref function can be used for this scenario. E.g.:

            <AttributeMapping>\n    <targetAttribute>ex:someAttribute</targetAttribute> \n    <sourceExpression>\n      <linkElement>\n        if_then_else(isNull(NUMERIC_VALUE), toXlinkHref('urn:ogc:def:nil:OGC:1.0:missing'), \n              if_then_else(lessEqualThan(NUMERIC_VALUE, 1000), 'numeric_value', toXlinkHref('urn:ogc:def:nil:OGC:1.0:missing'))) \n        </linkElement>\n    </sourceExpression> \n</AttributeMapping>\n

            The above example means, if NUMERIC_VALUE is null, the output would be encoded as:

            <ex:someAttribute xlink:href=\"urn:ogc:def:nil:OGC:1.0:missing\">\n

            Otherwise, if NUMERIC_VALUE is less or equal than 1000, it would be encoded with attributes from FeatureTypeMapping with 'numeric_value' mappingName. If NUMERIC_VALUE is greater than 1000, it would be encoded as the first scenario.

            "},{"location":"data/app-schema/polymorphism/#useful-functions","title":"Useful functions","text":""},{"location":"data/app-schema/polymorphism/#if_then_else-function","title":"if_then_else function","text":"

            Syntax:

            if_then_else(BOOLEAN_EXPRESSION, value, default value)\n
            • BOOLEAN_EXPRESSION: could be a Boolean column value, or a Boolean function
            • value: the value to map to, if BOOLEAN_EXPRESSION is true
            • default value: the value to map to, if BOOLEAN_EXPRESSION is false
            "},{"location":"data/app-schema/polymorphism/#recode-function","title":"Recode function","text":"

            Syntax:

            Recode(EXPRESSION, key1, value1, key2, value2,...)\n
            • EXPRESSION: column name to get values from, or another function

            • key-n:
              • key expression to map to value-n
              • if the evaluated value of EXPRESSION doesn't match any key, nothing would be encoded for the attribute.
            • value-n: value expression which translates to a mappingName or targetElement

            "},{"location":"data/app-schema/polymorphism/#lessequalthan","title":"lessEqualThan","text":"

            Returns true if ATTRIBUTE_EXPRESSION evaluates to less or equal than LIMIT_EXPRESSION.

            Syntax:

            lessEqualThan(ATTRIBUTE_EXPRESSION, LIMIT_EXPRESSION)\n
            • ATTRIBUTE_EXPRESSION: expression of the attribute being evaluated.
            • LIMIT_EXPRESSION: expression of the numeric value to be compared against.
            "},{"location":"data/app-schema/polymorphism/#lessthan","title":"lessThan","text":"

            Returns true if ATTRIBUTE_EXPRESSION evaluates to less than LIMIT_EXPRESSION.

            Syntax:

            lessThan(ATTRIBUTE_EXPRESSION, LIMIT_EXPRESSION)\n
            • ATTRIBUTE_EXPRESSION: expression of the attribute being evaluated.
            • LIMIT_EXPRESSION: expression of the numeric value to be compared against.
            "},{"location":"data/app-schema/polymorphism/#equalto","title":"equalTo","text":"

            Compares two expressions and returns true if they're equal.

            Syntax:

            equalTo(LHS_EXPRESSION, RHS_EXPRESSION)\n
            "},{"location":"data/app-schema/polymorphism/#isnull","title":"isNull","text":"

            Returns a Boolean that is true if the expression evaluates to null.

            Syntax:

            isNull(EXPRESSION)\n
            • EXPRESSION: expression to be evaluated.
            "},{"location":"data/app-schema/polymorphism/#toxlinkhref","title":"toXlinkHref","text":"

            Special function written for referential polymorphism and feature chaining, not to be used outside of linkElement. It infers that the attribute should be encoded as xlink:href.

            Syntax:

            toXlinkHref(XLINK_HREF_EXPRESSION)\n
            • XLINK_HREF_EXPRESSION:
              • could be a function or a literal
              • has to be wrapped in single quotes if it's a literal

            Note

            • To get toXlinkHref function working, you need to declare xlink URI in the namespaces.
            "},{"location":"data/app-schema/polymorphism/#other-functions","title":"Other functions","text":"

            Please refer to Filter Function Reference.

            "},{"location":"data/app-schema/polymorphism/#combinations","title":"Combinations","text":"

            You can combine functions, but it might affect performance. E.g.:

            if_then_else(isNull(NUMERIC_VALUE), toXlinkHref('urn:ogc:def:nil:OGC:1.0:missing'), \n    if_then_else(lessEqualThan(NUMERIC_VALUE, 1000), 'numeric_value', toXlinkHref('urn:ogc:def:nil:OGC:1.0:missing')))\n

            Note

            • When specifying a mappingName or targetElement as a value in functions, make sure they're enclosed in single quotes. * Some functions have no null checking, and will fail when they encounter null. * The workaround for this is to wrap the expression with isNull() function if null is known to exist in the data set.
            "},{"location":"data/app-schema/polymorphism/#null-or-missing-value","title":"Null or missing value","text":"

            To skip the attribute for a specific case, you can use Expression.NIL as a value in if_then_else or not include the key in Recode function . E.g.:

            if_then_else(isNull(VALUE), Expression.NIL, 'gsml:CGI_TermValue')\n    means the attribute would not be encoded if VALUE is null.\n\nRecode(VALUE, 'term_value', 'gsml:CGI_TermValue')\n    means the attribute would not be encoded if VALUE is anything but 'term_value'.\n

            To encode an attribute as xlink:href that represents missing value on the top level, see Referential Polymorphism.

            "},{"location":"data/app-schema/polymorphism/#any-type","title":"Any type","text":"

            Having xs:anyType as the attribute type itself infers that it is polymorphic, since they can be encoded as any type.

            If the type is pre-determined and would always be the same, we might need to specify app-schema.mapping-file.targetAttributeNode. E.g.:

            <AttributeMapping>\n      <targetAttribute>om:result</targetAttribute>\n      <targetAttributeNode>gml:MeasureType<targetAttributeNode>\n      <sourceExpression>\n          <OCQL>TOPAGE</OCQL>\n      </sourceExpression>\n      <ClientProperty>\n          <name>xsi:type</name>\n          <value>'gml:MeasureType'</value>\n      </ClientProperty>\n      <ClientProperty>\n          <name>uom</name> \n          <value>'http://www.opengis.net/def/uom/UCUM/0/Ma'</value>\n      </ClientProperty> \n</AttributeMapping>\n

            If the casting type is complex, this is not a requirement as app-schema is able to automatically determine the type from the XPath in targetAttribute. E.g., in this example om:result is automatically specialised as a MappedFeatureType:

            <AttributeMapping>\n      <targetAttribute>om:result/gsml:MappedFeature/gml:name</targetAttribute>\n      <sourceExpression>\n          <OCQL>NAME</OCQL>\n      </sourceExpression>\n</AttributeMapping>\n

            Alternatively, we can use feature chaining. For the same example above, the mapping would be:

            <AttributeMapping>\n  <targetAttribute>om:result</targetAttribute>\n  <sourceExpression>\n    <OCQL>LEX_D</OCQL>\n    <linkElement>gsml:MappedFeature</linkElement>\n    <linkField>gml:name</linkField>\n  </sourceExpression>\n</AttributeMapping>\n

            If the type is conditional, the mapping style for such attributes is the same as any other polymorphic attributes. E.g.:

            <AttributeMapping>\n  <targetAttribute>om:result</targetAttribute>\n  <sourceExpression>\n    <linkElement>\n       Recode(NAME, Expression.Nil, toXlinkHref('urn:ogc:def:nil:OGC::missing'),'numeric',\n               toXlinkHref(strConcat('urn:numeric-value::', NUMERIC_VALUE)), 'literal', 'TermValue2')\n    </linkElement>\n  </sourceExpression>\n</AttributeMapping>\n
            "},{"location":"data/app-schema/polymorphism/#filters","title":"Filters","text":"

            Filters should work as usual, as long as the users know what they want to filter. For example, when an attribute could be encoded as gsml:CGI_TermValue or gsml:CGI_NumericValue, users can run filters with property names of:

            • ex:someAttribute/gsml:CGI_TermValue/gsml:value to return matching attributes that are encoded as gsml:CGI_TermValue and satisfy the filter.
            • likewise, ex:someAttribute/gsml:CGI_NumericValue/gsml:principalValue should return matching gsml:CGI_NumericValue attributes.

            Another limitation is filtering attributes of an xlink:href attribute pointing to an instance outside of the document.

            "},{"location":"data/app-schema/property-interpolation/","title":"Property Interpolation","text":"

            Interpolation in this context means the substitution of variables into strings. GeoServer app-schema supports the interpolation of properties (the Java equivalent of environment variables) into app-schema mapping files. This can be used, for example, to simplify the management of database connection parameters that would otherwise be hardcoded in a particular mapping file. This enables data directories to be given to third parties without inapplicable authentication or system configuration information. Externalising these parameters make management easier.

            "},{"location":"data/app-schema/property-interpolation/#defining-properties","title":"Defining properties","text":"
            • If the system property app-schema.properties is not set, properties are loaded from WEB-INF/classes/app-schema.properties (or another resource /app-schema.properties on the classpath).

            • If the system property app-schema.properties is set, properties are loaded from the file named as the value of the property. This is principally intended for debugging, and is designed to be used in an Eclipse launch configuration.

              • For example, if the JVM is started with -Dapp-schema.properties=/path/to/some/local.properties, properties are loaded from /path/to/some/local.properties.
            • System properties override properties defined in a configuration file, so if you define -Dsome.property at the java command line, it will override a value specified in the app-schema.properties file. This is intended for debugging, so you can set a property file in an Eclipse launch configuration, but override some of the properties contained in the file by setting them explicitly as system properties.

            • All system properties are available for interpolation in mapping files.

            "},{"location":"data/app-schema/property-interpolation/#predefined-properties","title":"Predefined properties","text":"

            If not set elsewhere, the following properties are set for each mapping file:

            • config.file is set to the name of the mapping file
            • config.parent is set to the name of the directory containing the mapping file
            "},{"location":"data/app-schema/property-interpolation/#using-properties","title":"Using properties","text":"
            • Using ${some.property} anywhere in the mapping file will cause it to be replaced by the value of the property some.property.
            • It is an error for a property that has not been set to be used for interpolation.
            • Interpolation is performed repeatedly, so values can contain new interpolations. Use this behaviour with caution because it may cause an infinite loop.
            • Interpolation is performed before XML parsing, so can be used to include arbitrary chunks of XML.
            "},{"location":"data/app-schema/property-interpolation/#example-of-property-interpolation","title":"Example of property interpolation","text":"

            This example defines an Oracle data store, where the connection parameter are interpolated from properties:

            <sourceDataStores>\n    <DataStore>\n        <id>datastore</id>\n        <parameters>\n            <Parameter>\n                <name>dbtype</name>\n                <value>Oracle</value>\n            </Parameter>\n            <Parameter>\n                <name>host</name>\n                <value>${example.host}</value>\n            </Parameter>\n            <Parameter>\n                <name>port</name>\n                <value>1521</value>\n            </Parameter>\n            <Parameter>\n                <name>database</name>\n                <value>${example.database}</value>\n            </Parameter>\n            <Parameter>\n                <name>user</name>\n                <value>${example.user}</value>\n            </Parameter>\n            <Parameter>\n                <name>passwd</name>\n                <value>${example.passwd}</value>\n            </Parameter>\n        </parameters>\n    </DataStore>\n</sourceDataStores>\n
            "},{"location":"data/app-schema/property-interpolation/#example-property-file","title":"Example property file","text":"

            This sample property file gives the property values that are interpolated into the mapping file fragment above. These properties can be installed in WEB-INF/classes/app-schema.properties in your GeoServer installation:

            example.host = database.example.com\nexample.database = example\nexample.user = dbuser\nexample.passwd = s3cr3t\n
            "},{"location":"data/app-schema/secondary-namespaces/","title":"Secondary Namespaces","text":""},{"location":"data/app-schema/secondary-namespaces/#what-is-a-secondary-namespace","title":"What is a secondary namespace?","text":"

            A secondary namespace is one that is referenced indirectly by the main schema, that is, one schema imports another one as shown below:

            a.xsd imports b.xsd\nb.xsd imports c.xsd\n

            (using a, b and c as the respective namespace prefixes for a.xsd, b.xsd and c.xsd):

            a.xsd declares b:prefix\nb.xsd declares c:prefix\n

            The GeoTools encoder does not honour these namespaces and writes out:

            \"a:\" , \"b:\" but NOT \"c:\"\n

            The result is c's element being encoded as:

            <null:cElement/>\n
            "},{"location":"data/app-schema/secondary-namespaces/#when-to-configure-for-secondary-namespaces","title":"When to configure for secondary namespaces","text":"

            If your application spans several namespaces which may be very common in application schemas.

            A sure sign that calls for secondary namespace configuration is when prefixes for namespaces are printed out as the literal string \"null\" or error messages like:

            java.io.IOException: The prefix \"null\" for element \"null:something\" is not bound.\n

            Note

            When using secondary namespaces, requests involving complex featuretypes must be made to the global OWS service only, not to Virtual Services. This is because virtual services are restricted to a single namespace, and thus are not able to access secondary namespaces.

            In order to allow GeoServer App-Schema to support secondary namespaces, please follow the steps outlined below:

            Using the sampling namespace as an example.

            "},{"location":"data/app-schema/secondary-namespaces/#step-1create-the-secondary-namespace-folder","title":"Step 1:Create the Secondary Namespace folder","text":"

            Create a folder to represent the secondary namespace in the data/workspaces directory, in our example that will be the \"sa\" folder.

            "},{"location":"data/app-schema/secondary-namespaces/#step-2create-files","title":"Step 2:Create files","text":"

            Create two files below in the \"sa\" folder:

            1. namespace.xml
            2. workspace.xml
            "},{"location":"data/app-schema/secondary-namespaces/#step-3edit-content-of-files","title":"Step 3:Edit content of files","text":"

            Contents of these files are as follows:

            namespace.xml(uri is a valid uri for the secondary namespace, in this case the sampling namespace uri):

            <namespace>\n    <id>sa_workspace</id>   \n    <prefix>sa</prefix>\n    <uri>http://www.opengis.net/sampling/1.0</uri>\n</namespace>\n

            workspace.xml:

            <workspace>\n    <id>sa_workspace</id>   \n    <name>sa</name>\n</workspace>\n

            That's it.

            Your workspace is now configured to use a Secondary Namespace.

            "},{"location":"data/app-schema/solr-tutorial/","title":"Apache Solr Tutorial","text":"

            This tutorial demonstrates how to use the App-Schema plugin with a Apache Solr data store. This tutorial will focus on the Apache Solr data store specific aspects, and the App-Schema documentation should be read first.

            The use case for this tutorial will be to serve through App-Schema the information about some meteorological stations index in an Apache Solr core. Note that this use case is completely fictional and only used to demonstrate the Apache Solr and App-Schema integration.

            A station data is composed of some meta-information about the station, e.g. it's name and position. The only extra different configuration we need to provide when using Apache Solr as a data source is the configuration of the data store itself.

            Apache Solr data source configuration as a specific syntax and allow us to specify geometry attributes and to explicitly set the default geometry:

            <sourceDataStores>\n  <SolrDataStore>\n    <id>stations</id>\n    <url>http://localhost:8983/solr/stations</url>\n    <index name=\"stations\">\n      <geometry default=\"true\">\n        <name>location</name>\n        <srid>4326</srid>\n        <type>POINT</type>\n      </geometry>\n    </index>\n  </SolrDataStore>\n</sourceDataStores>\n

            In this particular case the location attribute contains a point geometry and will be the default geometry.

            The complete mapping file is:

            <?xml version=\"1.0\" encoding=\"UTF-8\" standalone=\"yes\"?>\n<as:AppSchemaDataAccess xmlns:as=\"http://www.geotools.org/app-schema\">\n    <namespaces>\n        <Namespace>\n            <prefix>st</prefix>\n            <uri>http://www.stations.org/1.0</uri>\n        </Namespace>\n        <Namespace>\n            <prefix>gml</prefix>\n            <uri>http://www.opengis.net/gml/3.2</uri>\n        </Namespace>\n    </namespaces>\n    <sourceDataStores>\n        <SolrDataStore>\n            <id>stations</id>\n            <url>http://localhost:8983/solr/stations</url>\n            <index name=\"stations\">\n                <geometry default=\"true\">\n                    <name>location</name>\n                    <srid>4326</srid>\n                    <type>POINT</type>\n                </geometry>\n            </index>\n        </SolrDataStore>\n    </sourceDataStores>\n    <targetTypes>\n        <FeatureType>\n            <schemaUri>stations.xsd</schemaUri>\n        </FeatureType>\n    </targetTypes>\n    <typeMappings>\n        <FeatureTypeMapping>\n            <mappingName>stations_solr</mappingName>\n            <sourceDataStore>stations</sourceDataStore>\n            <sourceType>stations</sourceType>\n            <targetElement>st:Station</targetElement>\n            <attributeMappings>\n                <AttributeMapping>\n                    <targetAttribute>st:Station</targetAttribute>\n                    <idExpression>\n                        <OCQL>station_id</OCQL>\n                    </idExpression>\n                </AttributeMapping>\n                <AttributeMapping>\n                    <targetAttribute>st:stationName</targetAttribute>\n                    <sourceExpression>\n                        <OCQL>station_name</OCQL>\n                    </sourceExpression>\n                </AttributeMapping>\n                <AttributeMapping>\n                    <targetAttribute>st:position</targetAttribute>\n                    <sourceExpression>\n                        <OCQL>station_location</OCQL>\n                    </sourceExpression>\n                </AttributeMapping>\n            </attributeMappings>\n        </FeatureTypeMapping>\n    </typeMappings>\n</as:AppSchemaDataAccess>\n

            The mappings for the attributes are straightforward and follow the normal App-Schema attributes mappings syntax. Currently multi valued fields are not supported.

            "},{"location":"data/app-schema/solr-tutorial/#using-solr-as-app-schema-indexes","title":"Using Solr as App-Schema Indexes","text":"

            App-Schema Indexes is an extension for mapping that allows to use Apache Solr as Index for queries and retrieving data from normal App-Schema datasource (SQL DB, MongoDB, ... ).

            The only requirement to use it is having Geoserver App-Schema extension and Solr extension installed.

            "},{"location":"data/app-schema/solr-tutorial/#how-index-layer-works","title":"How Index layer works","text":"

            When App-Schema detects the index layer is activated for a FeatureType, it will use Solr configured fields for every query incoming from Geoserver OWS requests. If the incoming query uses only indexed fields App-Schema will query only on Solr data source for retrieving matching features IDs and will connect to normal data source to get all in depth data but exclusively for matching IDs.

            Warning

            note that both Primary Keys (solr index core and data source) should match to get Index layer working.

            "},{"location":"data/app-schema/solr-tutorial/#linking-an-index-only-store","title":"Linking an index only store","text":"

            Begin creating the SolrDataStore definition as usual along with the Postgis store definition:

            (...)\n<sourceDataStores>\n(...)\n    <SolrDataStore>\n        <id>stations_index</id>\n        <url>http://localhost:8983/solr/stations</url>\n        <index name=\"stations\">\n            <geometry default=\"true\">\n                <name>location</name>\n                <srid>4326</srid>\n                <type>POINT</type>\n            </geometry>\n        </index>\n    </SolrDataStore>\n     <DataStore>\n          <id>postgis_dataStore</id>\n          <parameters>\n              <Parameter>\n                  <name>Connection timeout</name>\n                  <value>20</value>\n              </Parameter>\n              <Parameter>\n                  <name>port</name>\n                  <value>5432</value>\n              </Parameter>\n              <Parameter>\n                  <name>passwd</name>\n                  <value>postgres</value>\n              </Parameter>\n              <Parameter>\n                  <name>dbtype</name>\n                  <value>postgis</value>\n              </Parameter>\n(...)\n

            Link a solr index as index layer on FeatureTypeMapping setting:

            • indexDataStore : The SolrDataStore id property from the store you use as index layer only.
            • indexType : The solr core to use.
            <typeMappings>\n(...)\n    <FeatureTypeMapping>\n        <mappingName>Stations</mappingName>\n        <sourceDataStore>postgis_dataStore</sourceDataStore>\n        <sourceType>meteo_stations</sourceType>\n        <targetElement>st:Station</targetElement>\n        <defaultGeometry>st:position</defaultGeometry>\n        <indexDataStore>stations_index</indexDataStore>\n        <indexType>stations</indexType>\n        <attributeMappings>\n        (...)\n
            "},{"location":"data/app-schema/solr-tutorial/#linking-an-index-enabled-attribute","title":"Linking an index enabled attribute","text":"

            To link a solr core field as index for an AttributeMapping you only need to add an indexField definition with this format:

            <AttributeMapping>\n(...)\n  <indexField>${SOLR_FIELD_NAME}</indexField>\n(...)\n</AttributeMapping>\n
            • \\${SOLR_FIELD_NAME} : The field name from solr core to use in index layer.

            For example if you need to use solr fields: station_id and station_name; you will write on mapping:

            <AttributeMapping>\n    <targetAttribute>st:Station</targetAttribute>\n    <idExpression>\n        <OCQL>id</OCQL>\n    </idExpression>\n    <indexField>station_id</indexField>\n</AttributeMapping>\n<AttributeMapping>\n    <targetAttribute>st:stationName</targetAttribute>\n    <sourceExpression>\n        <OCQL>strConcat('1_', common_name)</OCQL>\n    </sourceExpression>\n    <indexField>station_name</indexField>\n</AttributeMapping>\n
            "},{"location":"data/app-schema/supported-gml-versions/","title":"Supported GML Versions","text":""},{"location":"data/app-schema/supported-gml-versions/#gml-311","title":"GML 3.1.1","text":"
            • GML 3.1.1 application schemas are supported for WFS 1.1.0.
            • Clients must specify WFS 1.1.0 in requests because the GeoServer default is WFS 2.0.0.
            • GET URLs must contain version=1.1.0 to set the WFS version to 1.1.0.
            "},{"location":"data/app-schema/supported-gml-versions/#gml-321","title":"GML 3.2.1","text":"
            • GML 3.2.1 application schemas are supported for WFS 1.1.0 and (incomplete) WFS 2.0.0.
            • Some WFS 2.0.0 features not in WFS 1.1.0 such as GetFeatureById are not yet supported.
            • Clients using WFS 1.1.0 must specify WFS 1.1.0 in requests and select the gml32 output format for GML 3.2.1.
            • To use WFS 1.1.0 for GML 3.2.1, GET URLs must contain version=1.1.0 to set the WFS version to 1.1.0 and outputFormat=gml32 to set the output format to GML 3.2.1.
            • The default WFS version is 2.0.0, for which the default output format is GML 3.2.1.
            • All GML 3.2.1 responses are contained in a WFS 2.0.0 FeatureCollection element, even for WFS 1.1.0 requests, because a WFS 1.1.0 FeatureCollection cannot contain GML 3.2.1 features.
            "},{"location":"data/app-schema/supported-gml-versions/#secondary-namespace-for-gml-321-required","title":"Secondary namespace for GML 3.2.1 required","text":"

            GML 3.2.1 WFS responses are delivered in a WFS 2.0.0 FeatureCollection. Unlike WFS 1.1.0, WFS 2.0.0 does not depend explicitly on any GML version. As a consequence, the GML namespace is secondary and must be defined explicitly as a secondary namespace. See app-schema.secondary-namespaces for details.

            For example, to use the prefix gml for GML 3.2, create workspaces/gml/namespace.xml containing:

            <namespace>\n    <id>gml_namespace</id>\n    <prefix>gml</prefix>\n    <uri>http://www.opengis.net/gml/3.2</uri>\n</namespace>\n

            and workspaces/gml/workspace.xml containing:

            <workspace>\n    <id>gml_workspace</id>\n    <name>gml</name>\n</workspace>\n

            Failure to define the gml namespace prefix with a secondary namespace will result in errors like:

            java.io.IOException: The prefix \"null\" for element \"null:name\" is not bound.\n

            while encoding a response (in this case one containing gml:name), even if the namespace prefix is defined in the mapping file.

            "},{"location":"data/app-schema/supported-gml-versions/#gml-321-geometries-require-gmlid","title":"GML 3.2.1 geometries require gml:id","text":"

            GML 3.2.1 requires that all geometries have a gml:id. While GeoServer will happily encode WFS responses without gml:id on geometries, these will be schema-invalid. Encoding a gml:id on a geometry can be achieved by setting an idExpression in the mapping for the geometry property. For example, gsml:shape is a geometry property and its gml:id might be generated with:

            <AttributeMapping>\n    <targetAttribute>gsml:shape</targetAttribute>\n    <idExpression>\n        <OCQL>strConcat('shape.', getId())</OCQL>\n    </idExpression>\n    <sourceExpression>\n        <OCQL>SHAPE</OCQL>\n    </sourceExpression>\n</AttributeMapping>\n

            In this example, getId() returns the gml:id of the containing feature, so each geometry will have a unique gml:id formed by appending the gml:id of the containing feature to the string \"shape.\".

            If a multigeometry (such as a MultiPoint or MultiSurface) is assigned a gml:id of (for example) parentid, to permit GML 3.2.1 schema-validity, each geometry that the multigeometry contains will be automatically assigned a gml:id of the form parentid.1, parentid.2, ... in order.

            "},{"location":"data/app-schema/supported-gml-versions/#gml-33","title":"GML 3.3","text":"

            The proposed GML 3.3 is itself a GML 3.2.1 application schema; preliminary testing with drafts of GML 3.3 indicates that it works with app-schema as expected.

            "},{"location":"data/app-schema/tutorial/","title":"Tutorial","text":"

            This tutorial demonstrates how to configure two complex feature types using the app-schema plugin and data from two property files.

            "},{"location":"data/app-schema/tutorial/#geosciml","title":"GeoSciML","text":"

            This example uses Geoscience Markup Language (GeoSciML) 2.0, a GML 3.1 application schema:

            \"GeoSciML is an application schema that specifies a set of feature-types and supporting structures for information used in the solid-earth geosciences.\"

            The tutorial defines two feature types:

            1. gsml:GeologicUnit, which describes \"a body of material in the Earth\".
            2. gsml:MappedFeature, which describes the representation on a map of a feature, in this case gsml:GeologicUnit.

            Because a single gsml:GeologicUnit can be observed at several distinct locations on the Earth's surface, it can have a multivalued gsml:occurrence property, each being a gsml:MappedFeature.

            "},{"location":"data/app-schema/tutorial/#installation","title":"Installation","text":"
            • Install GeoServer as usual.

            • Install the app-schema plugin geoserver-*-app-schema-plugin.zip:

              • Place the jar files in WEB-INF/lib.

              • The tutorial folder contains the GeoServer configuraration (data directory) used for this tutorial.

                • Either replace your existing data directory with the tutorial data directory,
                • Or edit WEB-INF/web.xml to set GEOSERVER_DATA_DIR to point to the tutorial data directory. (Be sure to uncomment the section that sets GEOSERVER_DATA_DIR.)
            • Perform any configuration required by your servlet container, and then start the servlet. For example, if you are using Tomcat, configure a new context in server.xml and then restart Tomcat.

            • The first time GeoServer starts with the tutorial configuration, it will download all the schema (XSD) files it needs and store them in the app-schema-cache folder in the data directory. You must be connected to the internet for this to work.

            "},{"location":"data/app-schema/tutorial/#datastorexml","title":"datastore.xml","text":"

            Each data store configuration file datastore.xml specifies the location of a mapping file and triggers its loading as an app-schema data source. This file should not be confused with the source data store, which is specified inside the mapping file.

            For gsml_GeologicUnit the file is workspaces/gsml/gsml_GeologicUnit/datastore.xml:

            <dataStore>\n    <id>gsml_GeologicUnit_datastore</id>\n    <name>gsml_GeologicUnit</name>\n    <enabled>true</enabled>\n    <workspace>\n        <id>gsml_workspace</id>\n    </workspace>\n    <connectionParameters>\n        <entry key=\"namespace\">urn:cgi:xmlns:CGI:GeoSciML:2.0</entry>\n        <entry key=\"url\">file:workspaces/gsml/gsml_GeologicUnit/gsml_GeologicUnit.xml</entry>\n        <entry key=\"dbtype\">app-schema</entry>\n    </connectionParameters>\n</dataStore>\n

            For gsml:MappedFeature the file is workspaces/gsml/gsml_MappedFeature/datastore.xml:

            <dataStore>\n    <id>gsml_MappedFeature_datastore</id>\n    <name>gsml_MappedFeature</name>\n    <enabled>true</enabled>\n    <workspace>\n        <id>gsml_workspace</id>\n    </workspace>\n    <connectionParameters>\n        <entry key=\"namespace\">urn:cgi:xmlns:CGI:GeoSciML:2.0</entry>\n        <entry key=\"url\">file:workspaces/gsml/gsml_MappedFeature/gsml_MappedFeature.xml</entry>\n        <entry key=\"dbtype\">app-schema</entry>\n    </connectionParameters>\n</dataStore>\n

            Note

            Ensure that there is no blank-space inside an entry element.

            "},{"location":"data/app-schema/tutorial/#mapping-files","title":"Mapping files","text":"

            Configuration of app-schema feature types is performed in mapping files:

            • workspaces/gsml/gsml_GeologicUnit/gsml_GeologicUnit.xml
            • workspaces/gsml/gsml_MappedFeature/gsml_MappedFeature.xml
            "},{"location":"data/app-schema/tutorial/#namespaces","title":"Namespaces","text":"

            Each mapping file contains namespace prefix definitions:

            <Namespace>\n    <prefix>gml</prefix>\n    <uri>http://www.opengis.net/gml</uri>\n</Namespace>\n<Namespace>\n    <prefix>gsml</prefix>\n    <uri>urn:cgi:xmlns:CGI:GeoSciML:2.0</uri>\n</Namespace>\n<Namespace>\n    <prefix>xlink</prefix>\n    <uri>http://www.w3.org/1999/xlink</uri>\n</Namespace>\n

            Only those namespace prefixes used in the mapping file need to be declared, so the mapping file for gsml:GeologicUnit has less.

            "},{"location":"data/app-schema/tutorial/#source-data-store","title":"Source data store","text":"

            The data for this tutorial is contained in two property files:

            • workspaces/gsml/gsml_GeologicUnit/gsml_GeologicUnit.properties
            • workspaces/gsml/gsml_MappedFeature/gsml_MappedFeature.properties

            Java Properties describes the format of property files.

            For this example, each feature type uses an identical source data store configuration. This directory parameter indicates that the source data is contained in property files named by their feature type, in the same directory as the corresponding mapping file:

            <sourceDataStores>\n     <DataStore>\n         <id>datastore</id>\n         <parameters>\n             <Parameter>\n                 <name>directory</name>\n                 <value>file:./</value>\n             </Parameter>\n         </parameters>\n     </DataStore>\n </sourceDataStores>\n

            See app-schema.data-stores for a description of how to use other types of data stores such as databases.

            "},{"location":"data/app-schema/tutorial/#target-types","title":"Target types","text":"

            Both feature types are defined by the same XML Schema, the top-level schema for GeoSciML 2.0. This is specified in the targetTypes section. The type of the output feature is defined in targetElement in the typeMapping section below:

            <targetTypes>\n    <FeatureType>\n        <schemaUri>http://www.geosciml.org/geosciml/2.0/xsd/geosciml.xsd</schemaUri>\n    </FeatureType>\n</targetTypes>\n

            In this case the schema is published, but because the OASIS XML Catalog is used for schema resolution, a private or modified schema in the catalog can be used if desired.

            "},{"location":"data/app-schema/tutorial/#mappings","title":"Mappings","text":"

            The typeMappings element begins with configuration elements. From the mapping file for gsml:GeologicUnit:

            <typeMappings>\n    <FeatureTypeMapping>\n        <sourceDataStore>datastore</sourceDataStore>\n        <sourceType>gsml_GeologicUnit</sourceType>\n        <targetElement>gsml:GeologicUnit</targetElement>\n
            • The mapping starts with sourceDataStore, which gives the arbitrary identifier used above to name the source of the input data in the sourceDataStores section.
            • sourceType gives the name of the source simple feature type. In this case it is the simple feature type gsml_GeologicUnit, sourced from the rows of the file gsml_GeologicUnit.properties in the same directory as the mapping file.
            • When working with databases sourceType is the name of a table or view. Database identifiers must be lowercase for PostGIS or uppercase for Oracle Spatial.
            • targetElement is the name of the output complex feature type.
            "},{"location":"data/app-schema/tutorial/#gmlid-mapping","title":"gml:id mapping","text":"

            The first mapping sets the gml:id to be the feature id specified in the source property file:

            <AttributeMapping>\n    <targetAttribute>\n        gsml:GeologicUnit\n    </targetAttribute>\n    <idExpression>\n        <OCQL>ID</OCQL>\n    </idExpression>\n</AttributeMapping>\n
            • targetAttribute is the XPath to the element for which the mapping applies, in this case, the top-level feature type.
            • idExpression is a special form that can only be used to set the gml:id on a feature. Any field or CQL expression can be used, if it evaluates to an NCName.
            "},{"location":"data/app-schema/tutorial/#ordinary-mapping","title":"Ordinary mapping","text":"

            Most mappings consist of a target and source. Here is one from gsml:GeologicUnit:

            <AttributeMapping>\n    <targetAttribute>\n        gml:description\n        </targetAttribute>\n    <sourceExpression>\n        <OCQL>DESCRIPTION</OCQL>\n    </sourceExpression>\n</AttributeMapping>\n
            • In this case, the value of gml:description is just the value of the DESCRIPTION field in the property file.
            • For a database, the field name is the name of the column (the table/view is set in sourceType above). Database identifiers must be lowercase for PostGIS or uppercase for Oracle Spatial.
            • CQL expressions can be used to calculate content. Use caution because queries on CQL-calculated values prevent the construction of efficient SQL queries.
            • Source expressions can be CQL literals, which are single-quoted.
            "},{"location":"data/app-schema/tutorial/#client-properties","title":"Client properties","text":"

            In addition to the element content, a mapping can set one or more \"client properties\" (XML attributes). Here is one from gsml:MappedFeature:

            <AttributeMapping>\n    <targetAttribute>\n        gsml:specification\n    </targetAttribute>\n    <ClientProperty>\n        <name>xlink:href</name>\n        <value>GU_URN</value>\n    </ClientProperty>\n</AttributeMapping>\n
            • This mapping leaves the content of the gsml:specification element empty but sets an xlink:href attribute to the value of the GU_URN field.
            • Multiple ClientProperty mappings can be set.

            In this example from the mapping for gsml:GeologicUnit both element content and an XML attribute are provided:

            <AttributeMapping>\n    <targetAttribute>\n        gml:name[1]\n        </targetAttribute>\n    <sourceExpression>\n        <OCQL>NAME</OCQL>\n    </sourceExpression>\n    <ClientProperty>\n        <name>codeSpace</name>\n        <value>'urn:x-test:classifierScheme:TestAuthority:GeologicUnitName'</value>\n    </ClientProperty>\n</AttributeMapping>\n
            • The codespace XML attribute is set to a fixed value by providing a CQL literal.
            • There are multiple mappings for gml:name, and the index [1] means that this mapping targets the first.
            "},{"location":"data/app-schema/tutorial/#targetattributenode","title":"targetAttributeNode","text":"

            If the type of a property is abstract, a targetAttributeNode mapping must be used to specify a concrete type. This mapping must occur before the mapping for the content of the property.

            Here is an example from the mapping file for gsml:MappedFeature:

            <AttributeMapping>\n    <targetAttribute>gsml:positionalAccuracy</targetAttribute>\n    <targetAttributeNode>gsml:CGI_TermValuePropertyType</targetAttributeNode>\n</AttributeMapping>\n<AttributeMapping>\n    <targetAttribute>gsml:positionalAccuracy/gsml:CGI_TermValue/gsml:value</targetAttribute>\n    <sourceExpression>\n        <OCQL>'urn:ogc:def:nil:OGC:missing'</OCQL>\n    </sourceExpression>\n    <ClientProperty>\n        <name>codeSpace</name>\n        <value>'urn:ietf:rfc:2141'</value>\n    </ClientProperty>\n</AttributeMapping>\n
            • gsml:positionalAccuracy is of type gsml:CGI_TermValuePropertyType, which is abstract, so must be mapped to its concrete subtype gsml:CGI_TermValuePropertyType with a targetAttributeNode mapping before its contents can be mapped.
            • This example also demonstrates that mapping can be applied to nested properties to arbitrary depth. This becomes unmanageable for deep nesting, where feature chaining is preferred.
            "},{"location":"data/app-schema/tutorial/#feature-chaining","title":"Feature chaining","text":"

            In feature chaining, one feature type is used as a property of an enclosing feature type, by value or by reference:

            <AttributeMapping>\n    <targetAttribute>\n        gsml:occurrence\n    </targetAttribute>\n    <sourceExpression>\n        <OCQL>URN</OCQL>\n        <linkElement>gsml:MappedFeature</linkElement>\n        <linkField>gml:name[2]</linkField>\n    </sourceExpression>\n    <isMultiple>true</isMultiple>\n</AttributeMapping>\n
            • In this case from the mapping for gsml:GeologicUnit, we specify a mapping for its gsml:occurrence.
            • The URN field of the source gsml_GeologicUnit simple feature is use as the \"foreign key\", which maps to the second gml:name in each gsml:MappedFeature.
            • Every gsml:MappedFeature with gml:name[2] equal to the URN of the gsml:GeologicUnit under construction is included as a gsml:occurrence property of the gsml:GeologicUnit (by value).
            "},{"location":"data/app-schema/tutorial/#wfs-response","title":"WFS response","text":"

            When GeoServer is running, test app-schema WFS in a web browser. If GeoServer is listening on localhost:8080 you can query the two feature types using these links:

            • http://localhost:8080/geoserver/wfs?request=GetFeature&version=1.1.0&typeName=gsml:GeologicUnit
            • http://localhost:8080/geoserver/wfs?request=GetFeature&version=1.1.0&typeName=gsml:MappedFeature
            "},{"location":"data/app-schema/tutorial/#gsmlgeologicunit","title":"gsml:GeologicUnit","text":"

            Feature chaining has been used to construct the multivalued property gsml:occurrence of gsml:GeologicUnit. This property is a gsml:MappedFeature. The WFS response for gsml:GeologicUnit combines the output of both feature types into a single response. The first gsml:GeologicUnit has two gsml:occurrence properties, while the second has one. The relationships between the feature instances are data driven.

            Because the mapping files in the tutorial configuration do not contain attribute mappings for all mandatory properties of these feature types, the WFS response is not schema-valid against the GeoSciML 2.0 schemas. Schema-validity can be achieved by adding more attribute mappings to the mapping files.

            Note

            These feature types are defined in terms of GML 3.1 (the default for WFS 1.1.0); other GML versions will not work.

            Warning

            The web interface does not yet support app-schema store or layer administration.

            "},{"location":"data/app-schema/tutorial/#acknowledgements","title":"Acknowledgements","text":"

            gsml_GeologicUnit.properties and gsml_MappedFeature.properties are derived from data provided by the Department of Primary Industries, Victoria, Australia. For the purposes of this tutorial, this data has been modified to the extent that it has no real-world meaning.

            "},{"location":"data/app-schema/wfs-2.0-support/","title":"WFS 2.0 Support","text":""},{"location":"data/app-schema/wfs-2.0-support/#resolving","title":"Resolving","text":"

            Local resolve is supported in app-schema. This can be done by setting the 'resolve' parameter to either 'local' or 'all'. (Remote Resolving is not supported.) The parameter 'resolveDepth' specifies how many levels of references will be resolved. The parameter 'resolveTimeOut' may be used to specify, in seconds, an upper limit to how long app-schema should search for the feature needed for resolving. If the time out limit is reached, the feature is not resolved.

            When resolving without Feature Chaining (see below), a GML ID is extracted from the x-link reference and a brute force is done on all feature types to find a feature with this GML ID. The extraction of this GML ID from the Xlink Reference is done using the following rules:

            • In case of a URN: The GML ID comes after last colon in the URN. Make sure that the full GML ID is included after the last colon (including a possible feature type prefix).
            • In case of a URL: The GML ID comes after the # symbol.

            Failing to respect one of these rules will result in failure of resolve.

            "},{"location":"data/app-schema/wfs-2.0-support/#resolving-and-feature-chaining-by-reference","title":"Resolving and Feature Chaining By Reference","text":"

            The 'resolve' and 'resolveDepth' parameters may also be used in the case of app-schema.feature-chaining-by-reference. In this case, no brute force will take place, but resolving will instruct App-Schema to do full feature chaining rather than inserting a reference. The URI will not be used to find the feature, but the feature chaining parameters specified in the mapping, as with normal feature chaining. Because of this, the parameter 'resolveTimeOut' will be ignored in this case.

            However, be aware that every feature can only appear once in a response. If resolving would break this rule, for example with circular references, the encoder will change the resolved feature back to an (internal) x-link reference.

            "},{"location":"data/app-schema/wfs-2.0-support/#getpropertyvalue","title":"GetPropertyValue","text":"

            The GetPropertyValue request is now fully supported. Resolving is also possible in this request, following the same rules as described above.

            "},{"location":"data/app-schema/wfs-2.0-support/#paging","title":"Paging","text":"

            Paging is now supported in App-Schema. There are a few exceptions:

            • Paging is only supported for data stores with JDBC back ends and will not work for data stores with property files. It has been tested with Oracle and PostGIS databases.
            • Paging with filters involving attributes that are mapped to functions will not be supported, as this cannot be translated into SQL.

            For more efficient SQL queries generation, please set isDenormalised to false where applicable (when a one to one database table is used). See app-schema.mapping-file.

            "},{"location":"data/app-schema/wfs-2.0-support/#numbermatched","title":"NumberMatched","text":"

            The numberMatched valued in a GetFeature response contains the number of features that matches the criterion of the request. App-Schema supports it in the following cases:

            • When the App-Schema underlying dataStores are JDBC dataStore, with the exception of the cases where the query has a filter that cannot be translated to SQL query and PropertyName points to a nested attribute.
            • When the App-Schema underlying dataStores are different from JDBC dataStore and the query doesn't have filters.
            "},{"location":"data/app-schema/wfs-service-settings/","title":"WFS Service Settings","text":"

            There are two GeoServer WFS service settings that are strongly recommended for interoperable complex feature services. These can be enabled through the Services \u2192 WFS page on the GeoServer web interface or by manually editing the wfs.xml file in the data directory,

            "},{"location":"data/app-schema/wfs-service-settings/#canonical-schema-location","title":"Canonical schema location","text":"

            The default GeoServer behaviour is to encode WFS responses that include a schemaLocation for the WFS schema that is located on the GeoServer instance. A client will not know without retrieving the schema whether it is identical to the official schema hosted at schemas.opengis.net. The solution is to encode the schemaLocation for the WFS schema as the canonical location at schemas.opengis.net.

            To enable this option, choose one of these:

            1. Either: On the Service \u2192 WFS page under Conformance check Encode canonical WFS schema location.

            2. Or: Insert the following line before the closing tag in wfs.xml:

              <canonicalSchemaLocation>true</canonicalSchemaLocation>\n
            "},{"location":"data/app-schema/wfs-service-settings/#encode-using-featuremember","title":"Encode using featureMember","text":"

            By default GeoServer will encode WFS 1.1 responses with multiple features in a single gml:featureMembers element. This will cause invalid output if a response includes a feature at the top level that has already been encoded as a nested property of an earlier feature, because there is no single element that can be used to encode this feature by reference. The solution is to encode responses using gml:featureMember.

            To enable this option, choose one of these:

            1. Either: On the Service \u2192 WFS page under Encode response with select Multiple \"featureMember\" elements.

            2. Or: Insert the following line before the closing tag in wfs.xml:

              <encodeFeatureMember>true</encodeFeatureMember>\n
            "},{"location":"data/app-schema/wms-support/","title":"WMS Support","text":"

            App-schema supports WMS requests as well as WFS requests. This page provides some useful examples for configuring the WMS service to work with complex features.

            Note that the rendering performance of WMS can be significantly slower when using app-schema data stores. We strongly recommend employing app-schema.joining when using WMS with feature chaining, which can make response time for large data requests several orders of magnitude faster.

            "},{"location":"data/app-schema/wms-support/#configuration","title":"Configuration","text":"

            For WMS to be applicable to complex feature data, it is necessary that the complex feature types are recognised by GeoServer as layers. This must be configured by adding an extra configuration file named 'layer.xml' in the data directory of each feature type that we want to use as a WMS layer.

            This will expand the structure of the workspaces folder in the GeoServer data directory as follows (workspaces) (see app-schema.configuration): :

            workspaces\n    - gsml\n        - SomeDataStore\n            - SomeFeatureType\n                - featuretype.xml\n        - layer.xml\n            - datastore.xml\n            - SomeFeatureType-mapping-file.xml\n

            The file layer.xml must have the following contents: :

            <layer>\n<id>[mylayerid]</id>\n<name>[mylayername]</name>\n<path>/</path>\n<type>VECTOR</type>\n<defaultStyle>\n    <name>[mydefaultstyle]</name>\n</defaultStyle>\n<resource class=\"featureType\">\n    <id>[myfeaturetypeid]</id>\n</resource>\n<enabled>true</enabled>\n<attribution>\n    <logoWidth>0</logoWidth>\n    <logoHeight>0</logoHeight>\n</attribution>\n</layer>\n

            Replace the fields in between brackets with the following values:

            • [mylayerid] must be a custom id for the layer.
            • [mylayername] must be a custom name for the layer.
            • [mydefaultstyle] the default style used for this layer (when a style is not specified in the wms request). The style must exist in the GeoServer configuration.
            • [myfeaturetypeid] is the id of the feature type. This must the same as the id specified in the file featuretype.xml of the same directory.
            "},{"location":"data/app-schema/wms-support/#getmap","title":"GetMap","text":"

            Read GetMap for general information on the GetMap request. Read Styling for general information on how to style WMS maps with SLD files. When styling complex features, you can use XPaths to specify nested properties in your filters, as explained in app-schema.filtering-nested. However, in WMS styling filters X-paths do not support handling referenced features (see app-schema.feature-chaining-by-reference) as if they were actual nested features (because the filters are applied after building the features rather than before.) The prefix/namespace context that is used in the XPath expression is defined locally in the XML tags of the style file. This is an example of a Style file for complex features:

            <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<StyledLayerDescriptor version=\"1.0.0\" \n    xsi:schemaLocation=\"http://www.opengis.net/sld StyledLayerDescriptor.xsd\" \n    xmlns:ogc=\"http://www.opengis.net/ogc\" \n    xmlns:xlink=\"http://www.w3.org/1999/xlink\" \n    xmlns:gml=\"http://www.opengis.net/gml\" \n    xmlns:gsml=\"urn:cgi:xmlns:CGI:GeoSciML:2.0\"\n    xmlns:sld=\"http://www.opengis.net/sld\"\n    xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\">\n <sld:NamedLayer>\n  <sld:Name>geology-lithology</sld:Name>\n  <sld:UserStyle>\n    <sld:Name>geology-lithology</sld:Name>\n    <sld:Title>Geological Unit Lithology Theme</sld:Title>\n    <sld:Abstract>The colour has been creatively adapted from Moyer,Hasting\n         and Raines, 2005 (http://pubs.usgs.gov/of/2005/1314/of2005-1314.pdf) \n         which provides xls spreadsheets for various color schemes. \n         plus some creative entries to fill missing entries.\n    </sld:Abstract>\n    <sld:IsDefault>1</sld:IsDefault>\n    <sld:FeatureTypeStyle>\n      <sld:Rule>\n        <sld:Name>acidic igneous material</sld:Name>\n        <sld:Abstract>Igneous material with more than 63 percent SiO2.  \n                       (after LeMaitre et al. 2002)\n        </sld:Abstract>\n        <ogc:Filter>\n          <ogc:PropertyIsEqualTo>\n            <ogc:PropertyName>gsml:specification/gsml:GeologicUnit/gsml:composition/\n                 gsml:CompositionPart/gsml:lithology/@xlink:href</ogc:PropertyName>\n            <ogc:Literal>urn:cgi:classifier:CGI:SimpleLithology:200811:\n                         acidic_igneous_material</ogc:Literal>\n          </ogc:PropertyIsEqualTo>\n        </ogc:Filter>\n        <sld:PolygonSymbolizer>\n          <sld:Fill>\n            <sld:CssParameter name=\"fill\">#FFCCB3</sld:CssParameter>\n          </sld:Fill>\n        </sld:PolygonSymbolizer>\n      </sld:Rule>\n      <sld:Rule>\n        <sld:Name>acidic igneous rock</sld:Name>\n        <sld:Abstract>Igneous rock with more than 63 percent SiO2.  \n                     (after LeMaitre et al. 2002)\n        </sld:Abstract>\n        <ogc:Filter>\n          <ogc:PropertyIsEqualTo>\n            <ogc:PropertyName>gsml:specification/gsml:GeologicUnit/gsml:composition/\n                 gsml:CompositionPart/gsml:lithology/@xlink:href</ogc:PropertyName>\n            <ogc:Literal>urn:cgi:classifier:CGI:SimpleLithology:200811:\n                         acidic_igneous_rock</ogc:Literal>\n            </ogc:PropertyIsEqualTo>\n        </ogc:Filter>\n        <sld:PolygonSymbolizer>\n          <sld:Fill>\n            <sld:CssParameter name=\"fill\">#FECDB2</sld:CssParameter>\n          </sld:Fill>\n        </sld:PolygonSymbolizer>\n      </sld:Rule>\n      ...\n    </sld:FeatureTypeStyle>\n  </sld:UserStyle>\n </sld:NamedLayer>\n</sld:StyledLayerDescriptor>\n
            "},{"location":"data/app-schema/wms-support/#getfeatureinfo","title":"GetFeatureInfo","text":"

            Read GetFeatureInfo for general information on the GetFeatureInfo request. Read the tutorial on GetFeatureInfo Templates for information on how to template the html output. If you want to store a separate standard template for complex feature collections, save it under the filename complex_content.ftl in the template directory.

            Read the tutorial on Freemarker Templates for more information on how to use the freemarker templates. Freemarker templates support recursive calls, which can be useful for templating complex content. For example, the following freemarker template creates a table of features with a column for each property, and will create another table inside each cell that contains a feature as property: :

            <#-- \nMacro's used for content\n-->\n\n<#macro property node>\n    <#if !node.isGeometry>\n      <#if node.isComplex>      \n      <td> <@feature node=node.rawValue type=node.type /> </td>  \n      <#else>\n      <td>${node.value?string}</td>\n      <!--#if-->\n    <!--#if-->\n<!--#macro-->\n\n<#macro header typenode>\n<caption class=\"featureInfo\">${typenode.name}</caption>\n  <tr>\n  <th>fid</th>\n<#list typenode.attributes as attribute>\n  <#if !attribute.isGeometry>\n    <#if attribute.prefix == \"\">      \n        <th >${attribute.name}</th>\n    <#else>\n        <th >${attribute.prefix}:${attribute.name}</th>\n    <!--#if-->\n  <!--#if-->\n<!--#list-->\n  </tr>\n<!--#macro-->\n\n<#macro feature node type>\n<table class=\"featureInfo\">\n  <@header typenode=type />\n  <tr>\n  <td>${node.fid}</td>    \n  <#list node.attributes as attribute>\n      <@property node=attribute />\n  <!--#list-->\n  </tr>\n</table>\n<!--#macro-->\n\n<#-- \nBody section of the GetFeatureInfo template, it's provided with one feature collection, and\nwill be called multiple times if there are various feature collections\n-->\n<table class=\"featureInfo\">\n  <@header typenode=type />\n\n<#assign odd = false>\n<#list features as feature>\n  <#if odd>\n    <tr class=\"odd\">\n  <#else>\n    <tr>\n  <!--#if-->\n  <#assign odd = !odd>\n\n  <td>${feature.fid}</td>    \n  <#list feature.attributes as attribute>\n    <@property node=attribute />\n  <!--#list-->\n  </tr>\n<!--#list-->\n</table>\n<br/>\n
            "},{"location":"data/cascaded/","title":"Cascaded service data","text":"

            This section discusses how GeoServer can proxy external OGC services. This is known as cascading services.

            GeoServer supports cascading the following services:

            • External Web Feature Server
            • Cascaded Web Feature Service Stored Queries
            • External Web Map Server
            • External Web Map Tile Server
            "},{"location":"data/cascaded/stored_query/","title":"Cascaded Web Feature Service Stored Queries","text":"

            Stored query is a feature of Web Feature Services. It allows servers to serve pre-configured filter queries or even queries that cannot be expressed as GetFeature filter queries. This feature of GeoServer allows to create cascaded layers out of stored queries.

            Stored queries are read-only, and layers derived from cascaded stored queries cannot be updated with WFS-T.

            "},{"location":"data/cascaded/stored_query/#cascaded-stored-query-parameters","title":"Cascaded stored query parameters","text":"

            The relationship between stored query parameters and the schema returned by the query is not well defined. For cascaded stored queries to work, the relationship between the query received by GeoServer and the parameters passed to the stored query must be defined.

            When you set up a layer based on a stored query, you have to select which stored query to cascade and what values are passed to each parameter. Cascaded stored queries can leverage view parameters passed to the query. This is similar to how arbitrary parameters are passed to SQL Views. GeoServer supports multiple strategies to pass these values. See below for a full list.

            Parameter type Explanation

            No mapping The value of the view parameter will be passed as is to the stored query. No parameter will be passed if there is no view parameter of the same name.

            Blocked This parameter will never be passed to the stored query

            Default The specified value is used unless overwritten by a view parameter

            Static The specified value is always used (view parameter value will be ignored)

            CQL Expression An expression that will be evaluated on every request (see below for more details)

            See Using a parametric SQL View for more details how clients pass view parameters to GeoServer.

            "},{"location":"data/cascaded/stored_query/#cql-expressions","title":"CQL expressions","text":"

            Parameter mappings configured as CQL expressions are evaluated for each request using a context derived from the request query and the view parameters. General information on CQL expressions is available here Expression.

            The context contains the following properties that may be used in the expressions:

            Property name Explanation

            bboxMinX bboxMinY bboxMaxX bboxMaxY Evaluates to a corner coordinate of the full extent of the query

            defaultSRS Evaluates to the default SRS of the feature type

            viewparam:name Evaluates to the value of the view parameter name in this query

            "},{"location":"data/cascaded/stored_query/#configuring-a-cascaded-stored-query-layer","title":"Configuring a cascaded stored query layer","text":"

            In order to create a cascaded stored query layer the administrator invokes the Create new layer page. When an External Web Feature Server is selected, the usual list of tables and views available for publication appears, a link Configure Cascaded Stored Query... also appears:

            Selecting the Configure Cascaded Stored Query... link opens a new page where the parameter mapping is set up. By default all parameters are set up as No mapping.

            "},{"location":"data/cascaded/wfs/","title":"External Web Feature Server","text":"

            GeoServer has the ability to load data from a remote Web Feature Server (WFS). This is useful if the remote WFS lacks certain functionality that GeoServer contains. For example, if the remote WFS is not also a Web Map Server (WMS), data from the WFS can be cascaded through GeoServer to utilize GeoServer's WMS. If the remote WFS has a WMS but that WMS cannot output KML, data can be cascaded through GeoServer's WMS to output KML.

            "},{"location":"data/cascaded/wfs/#adding-an-external-wfs","title":"Adding an external WFS","text":"

            To connect to an external WFS, it is necessary to load it as a new datastore. To start, navigate to Stores \u2192 Add a new store \u2192 Web Feature Server.

            Adding an external WFS as a store

            Option Description

            Workspace Name of the workspace to contain the store. This will also be the prefix of all of the layer names created from the store.

            Data Source Name Name of the store as known to GeoServer.

            Description Description of the store.

            Enabled Enables the store. If disabled, no data from the external WFS will be served.

            GET_CAPABILITIES_URL URL to access the capabilities document of the remote WFS.

            PROTOCOL When checked, connects with POST, otherwise uses GET.

            USERNAME The user name to connect to the external WFS.

            PASSWORD The password associated with the above user name.

            ENCODING The character encoding of the XML requests sent to the server. Defaults to UTF-8.

            TIMEOUT Time (in milliseconds) before timing out. Default is 3000.

            BUFFER_SIZE Specifies a buffer size (in number of features). Default is 10 features.

            TRY_GZIP Specifies that the server should transfer data using compressed HTTP if supported by the server.

            LENIENT When checked, will try to render features that don't match the appropriate schema. Errors will be logged.

            MAXFEATURES Maximum number of features to retrieve for each featuretype. Default is no limit.

            AXIS_ORDER Axis order used in result coordinates (It applies only to WFS 1.x.0 servers). Default is Compliant.

            AXIS_ORDER_FILTER Axis order used in filter (It applies only to WFS 1.x.0 servers). Default is Compliant.

            OUTPUTFORMAT Output format to request (instead of the default remote service one) e.g. JSON.

            GML_COMPLIANCE_LEVEL OCG GML compliance level. i.e. (simple feature) 0, 1 or 2. Default is 0.

            GML_COMPATIBLE_TYPENAMES Use GML Compatible TypeNames (replace : by _). Default is no false.

            USE_HTTP_CONNECTION_POOLING Use connection pooling to connect to the remote WFS service. Also enables digest authentication.

            When finished, click Save.

            "},{"location":"data/cascaded/wfs/#configuring-external-wfs-layers","title":"Configuring external WFS layers","text":"

            When properly loaded, all layers served by the external WFS will be available to GeoServer. Before they can be served, however, they will need to be individually configured as new layers. See the section on Layers for how to add and edit new layers.

            "},{"location":"data/cascaded/wfs/#connecting-to-an-external-wfs-layer-via-a-proxy-server","title":"Connecting to an external WFS layer via a proxy server","text":"

            In a corporate environment it may be necessary to connect to an external WFS through a proxy server. To achieve this, various java variables need to be set.

            For a Windows install running GeoServer as a service, this is done by modifying the wrapper.conf file. For a default Windows install, modify C:\\Program Files\\GeoServer x.x.x\\wrapper\\wrapper.conf similarly to the following.

            # Java Additional Parameters\n\nwrapper.java.additional.1=-Djetty.home=.\nwrapper.java.additional.2=-DGEOSERVER_DATA_DIR=\"%GEOSERVER_DATA_DIR%\"\nwrapper.java.additional.3=-Dhttp.proxySet=true\nwrapper.java.additional.4=-Dhttp.proxyHost=maitproxy\nwrapper.java.additional.5=-Dhttp.proxyPort=8080\nwrapper.java.additional.6=-Dhttps.proxyHost=maitproxy\nwrapper.java.additional.7=-Dhttps.proxyPort=8080\nwrapper.java.additional.8=-Dhttp.nonProxyHosts=\"mait*|dpi*|localhost\"\n

            Note that the http.proxySet=true parameter is required. Also, the parameter numbers must be consecutive - i.e. no gaps.

            For a Windows install not running GeoServer as a service, modify startup.bat so that the java command runs with similar -D parameters.

            For a Linux/UNIX install, modify startup.sh so that the java command runs with similar -D parameters.

            "},{"location":"data/cascaded/wms/","title":"External Web Map Server","text":"

            GeoServer has the ability to proxy a remote Web Map Service (WMS). Supported WMS versions are 1.1.1 and 1.3.0. This process is sometimes known as Cascading WMS. Loading a remote WMS is useful for many reasons. If you don't manage or have access to the remote WMS, you can now manage its output as if it were local. Even if the remote WMS is not GeoServer, you can use GeoServer features to treat its output (watermarking, decoration, printing, etc).

            To access a remote WMS, it is necessary to load it as a store in GeoServer. GeoServer must be able to access the capabilities document of the remote WMS for the store to be successfully loaded.

            "},{"location":"data/cascaded/wms/#adding-an-external-wms","title":"Adding an external WMS","text":"

            To connect to an external WMS, it is necessary to load it as a new store. To start, in the Web administration interface, navigate to Stores \u2192 Add a new store \u2192 WMS. The option is listed under Other Data Sources.

            Adding an external WMS as a store

            Configuring a new external WMS store

            Option Description

            Workspace Name of the workspace to contain the store. This will also be the prefix of all of the layer names published from the store. The workspace name on the remote WMS is not cascaded.

            Data Source Name Name of the store as known to GeoServer.

            Description Description of the store.

            Enabled Enables the store. If disabled, no data from the remote WMS will be served.

            Capabilities URL The URL to access the capabilities document of the remote WMS. If URL contains just server address \"https://host.org/wms\" the required WMS GetCapabilities query parameters will be added automatically. Alternatively URL can be a full URL to access the capabilities document \"https://host.org/wms?service=WMS&version=1.1.1&request=GetCapabilities\".

            User Name If the WMS requires authentication, the user name to connect as.

            Password If the WMS requires authentication, the password to connect with.

            Max concurrent connections The maximum number of persistent connections to keep for this WMS.

            When finished, click Save.

            "},{"location":"data/cascaded/wms/#configuring-external-wms-layers","title":"Configuring external WMS layers","text":"

            When properly loaded, all layers served by the external WMS will be available to GeoServer. Before they can be served, however, they will need to be individually configured (published) as new layers. See the section on Layers for how to add and edit new layers. Once published, these layers will show up in the Layer Preview and as part of the WMS capabilities document.

            "},{"location":"data/cascaded/wms/#features","title":"Features","text":"

            Connecting a remote WMS allows for the following features:

            • Dynamic reprojection. While the default projection for a layer is cascaded, it is possible to pass the SRS parameter through to the remote WMS. Should that SRS not be valid on the remote server, GeoServer will dynamically reproject the images sent to it from the remote WMS.
            • GetFeatureInfo. WMS GetFeatureInfo requests will be passed to the remote WMS. If the remote WMS supports the application/vnd.ogc.gml format the request will be successful.
            • Full REST Configuration. See the REST section for more information about the GeoServer REST interface.
            "},{"location":"data/cascaded/wms/#cascaded-wms-settings","title":"Cascaded WMS Settings","text":"

            Making use of Remotely advertised styles and supported image formats.

            • Remote Styles Configuration. Remote Styles advertised in WMS capability document under tag, can also be used. A default style and additionally supported styles can be selected. By default no remote style is selected which indicates Geoserver to use whatever style is configured remotely and all available styles are selected. This means that remote styles can be passed in a GetMap request just like local styles. If the styles on remote WMS server have changed, please re-save the layer from UI.
            • Remote Image Format. Preferred image format(s) can be selected. It is possible to select a preferred image format and additionally supported image formats. This configuration works looks at the requested image format in local GetMap, if the GetMap format is either the preferred remote format or one of the many selected remote formats, the passed image format will be relayed in the remote WMS request. If the image format requested in local GetMap is neither the preferred remote image format nor in the list of Selected formats, the remote WMS format will use the preferred remote image format. This setting only works for image formats and ignore other advertised formats such as JSON, KML and SVG etc
            • Scale Denominators. Min and Max scale denominators can be applied to WMS layers. The effects of this configurations on the WMS layer are similar to that of scale denominators used in SLD as filters. See Rules
            • Respect Advertised Bounds. It is possible to ignore remote WMS requests with bounding box completely outside the advertised bounds of remote WMS layer. Some external WMS providers might respond with error instead of empty transparent image for WMS requests outside their advertised bounds, in such cases enable the check box to bar Geoserver from making empty WMS requests to WMS provider.
            • "},{"location":"data/cascaded/wms/#limitations","title":"Limitations","text":"

              Layers served through an external WMS have some, but not all of the functionality of a local WMS.

              • Layers cannot be styled with SLD.
              • Alternate (local) styles cannot be used.
              • Extra request parameters (time, elevation, cql_filter, etc.) cannot be used.
              • Image format cannot be specified. GeoServer will attempt to request PNG images, and if that fails will use the remote server's default image format.
              "},{"location":"data/cascaded/wmts/","title":"External Web Map Tile Server","text":"

              GeoServer has the ability to proxy a remote Web Map Tile Service (WMTS). This process is sometimes known as Cascading WMTS, even if the incoming requests follow the WMS protocol and the backing service follows the WMTS one; the WMTS cascading functionality is more like a \"protocol translator\", where the different handled data (capabilities documents, images) are translated by the \"WMTS cascading\" logic.

              Loading a remote WMTS is useful for many reasons. If you don't manage or have access to the remote WMTS, you can now manage its output as if it were local. Even if you don't have any control on the remote WMTS, you can use GeoServer features to treat its output (watermarking, decoration, printing, etc).

              To access a remote WMTS, it is necessary to load it as a store in GeoServer. GeoServer must be able to access the capabilities document of the remote WMTS for the store to be successfully loaded.

              "},{"location":"data/cascaded/wmts/#adding-an-external-wmts","title":"Adding an external WMTS","text":"

              To connect to an external WMTS, it is necessary to load it as a new store. To start, in the Web administration interface, navigate to Stores \u2192 Add a new store \u2192 WMTS. The option is listed under Other Data Sources.

              Adding an external WMTS as a store

              Configuring a new external WTMS store

              Option Description

              Workspace Name of the workspace to contain the store. This will also be the prefix of all of the layer names published from the store.

              Data Source Name Name of the store as known to GeoServer.

              Description Description of the store.

              Enabled Enables the store. If disabled, no data from the remote WMTS will be served.

              Capabilities URL The full URL to access the capabilities document of the remote WMTS.

              User Name If the WMTS requires authentication, the user name to connect as.

              Password If the WMTS requires authentication, the password to connect with.

              HTTP header name If the WMTS requires a custom HTTP header, the header name.

              HTTP header value If the WMTS requires a custom HTTP header, the header value.

              Max concurrent connections The maximum number of persistent connections to keep for this WMTS.

              When finished, click Save.

              "},{"location":"data/cascaded/wmts/#configuring-external-wmts-layers","title":"Configuring external WMTS layers","text":"

              When properly loaded, all layers served by the external WMTS will be available to GeoServer. Before they can be served, however, they will need to be individually configured (published) as new layers. See the section on Layers for how to add and edit new layers. Once published, these layers will show up in the Layer Preview and as part of the WMS capabilities document. If the WMTS layer has additional dimensions (e.g. time), related info will be reported on the WMS capabilities as well.

              "},{"location":"data/cascaded/wmts/#features","title":"Features","text":"

              Connecting a remote WMTS allows for the following features:

              • Dynamic reprojection. While the default projection for a layer is cascaded, it is possible to pass the SRS parameter through to the remote WMS. Should that SRS not be valid on the remote server, GeoServer will dynamically reproject the tiles sent to it from the remote WMTS.
              • Full REST Configuration. See the REST section for more information about the GeoServer REST interface.
              "},{"location":"data/cascaded/wmts/#limitations","title":"Limitations","text":"

              Layers served through an external WMTS have some, but not all of the functionality of a local layer.

              • Layers cannot be styled with SLD.
              • Alternate (local) styles cannot be used.
              • GetFeatureInfo requests aren't supported.
              • GetLegendGraphic requests aren't supported.
              • Image format cannot be specified. GeoServer will attempt to request PNG images, and if that fails will use the remote server's default image format.
              "},{"location":"data/cascaded/wmts/#images-output-discrepancies-in-a-cascaded-wmts-layer","title":"Images output discrepancies in a cascaded WMTS Layer","text":"

              WMTS it is a service that serves tiles and they have been generated for a concrete resolution/scale denominator. Asking a WMTS cascaded layer to generate WMS GetMap images or other WMTS tiles, with other scale denominators, will require image re-sampling:

              • If the image is stretched (scaled out) and the scale difference is notable, the borders, lines, and labels that appear in it could be blurred.
              • On the other hand if shrunk, the same object and shape could appear smaller than the original size and will be similarly appear blurred.

              This figure compares the resulting image from a WMTS to a cascaded layer which has been slightly stretched or scaled outLeft image shows a original wmts layer at its defined zoom level 4 which scale denominator is about 4M Right image shows a cascaded wmts layer as wms layer with at different scale denominator (the closest to its homologous cascaded layer) which is about 5M

              "},{"location":"data/database/","title":"Databases","text":"

              This section discusses the database data sources that GeoServer can access.

              The standard GeoServer installation supports accessing the following databases:

              • PostGIS
              • H2

              Other data sources are supplied as GeoServer extensions. Extensions are downloadable modules that add functionality to GeoServer. Extensions are available at the GeoServer download page.

              Warning

              The extension version must match the version of the GeoServer instance.

              • Db2
              • MySQL
              • Oracle
              • Microsoft SQL Server and SQL Azure

              GeoServer provides extensive facilities for controlling how databases are accessed. These are covered in the following sections.

              • Database Connection Pooling
              • JNDI
              • SQL Views
              • Controlling feature ID generation in spatial databases
              • Custom SQL session start/stop scripts
              "},{"location":"data/database/connection-pooling/","title":"Database Connection Pooling","text":"

              When serving data from a spatial database connection pooling is an important aspect of achieving good performance. When GeoServer serves a request that involves loading data from a database table, a connection must first be established with the database. This connection comes with a cost as it takes time to set up such a connection.

              The purpose served by a connection pool is to maintain connection to an underlying database between requests. The benefit of which is that connection setup only need to occur once on the first request. Subsequent requests use existing connections and achieve a performance benefit as a result.

              Whenever a data store backed by a database is added to GeoServer an internal connection pool is created. This connection pool is configurable.

              "},{"location":"data/database/connection-pooling/#connection-pool-options","title":"Connection pool options","text":"

              max connections The maximum number of connections the pool can hold. When the maximum number of connections is exceeded, additional requests that require a database connection will be halted until a connection from the pool becomes available. The maximum number of connections limits the number of concurrent requests that can be made against the database.

              min connections The minimum number of connections the pool will hold. This number of connections is held even when there are no active requests. When this number of connections is exceeded due to serving requests additional connections are opened until the pool reaches its maximum size (described above).

              validate connections Flag indicating whether connections from the pool should be validated before they are used. A connection in the pool can become invalid for a number of reasons including network breakdown, database server timeout, etc.. The benefit of setting this flag is that an invalid connection will never be used which can prevent client errors. The downside of setting the flag is that a performance penalty is paid in order to validate connections.

              fetch size The number of records read from the database in each network exchange. If set too low (<50) network latency will affect negatively performance, if set too high it might consume a significant portion of GeoServer memory and push it towards an Out Of Memory error. Defaults to 1000.

              connection timeout Time, in seconds, the connection pool will wait before giving up its attempt to get a new connection from the database. Defaults to 20 seconds.

              Test while idle Periodically test if the connections are still valid also while idle in the pool. Sometimes performing a test query using an idle connection can make the datastore unavailable for a while. Often the cause of this troublesome behaviour is related to a network firewall placed between GeoServer and the Database that force the closing of the underlying idle TCP connections.

              Evictor run periodicity Number of seconds between idle object evictor runs.

              Max connection idle time Number of seconds a connection needs to stay idle before the evictor starts to consider closing it.

              Evictor tests per run Number of connections checked by the idle connection evictor for each of its runs.

              "},{"location":"data/database/db2/","title":"Db2","text":"

              Note

              GeoServer does not come built-in with support for Db2; it must be installed through an extension. Proceed to Installing the Db2 extension for installation details.

              The Db2 spatial support implements the OGC specification \"Simple Features for SQL using types and functions\" and the ISO \"SQL/MM Part 3 Spatial\" standard. When installing Db2 on Linux, Unix and Windows platforms, the \"custom\" option must be selected and the server spatial support included.

              A free of charge copy of Db2 can be downloaded from https://www.ibm.com/analytics/db2/trials.

              "},{"location":"data/database/db2/#Db2_install","title":"Installing the Db2 extension","text":"

              Warning

              Due to licensing requirements, not all files are included with the extension. To install Db2 support, it is necessary to download additional files. Just installing the Db2 extension will have no effect.

              "},{"location":"data/database/db2/#geoserver-files","title":"GeoServer files","text":"
              1. From the download page locate the release of GeoServer you are running and download the Db2 extension: db2

                Warning

                Ensure to match plugin (example 2.24.2 above) version to the version of the GeoServer instance.

              2. Extract the contents of the archive into the WEB-INF/lib directory of the GeoServer installation.

              "},{"location":"data/database/db2/#required-external-files","title":"Required external files","text":"

              The Db2 JDBC driver is not packaged with the GeoServer extension: db2jcc4.jar. This file should be available in the java subdirectory of your Db2 installation directory. Copy this file to the WEB-INF/lib directory of the GeoServer installation.

              After all GeoServer files and external files have been downloaded and copied, restart GeoServer.

              "},{"location":"data/database/db2/#adding-a-db2-data-store","title":"Adding a Db2 data store","text":"

              When properly installed, Db2 will be an option in the Vector Data Sources list when creating a new data store.

              Db2 in the list of raster data stores

              "},{"location":"data/database/db2/#configuring-a-db2-data-store","title":"Configuring a Db2 data store","text":"

              Configuring a Db2 data store

              "},{"location":"data/database/db2/#configuring-a-db2-data-store-with-jndi","title":"Configuring a Db2 data store with JNDI","text":""},{"location":"data/database/db2/#notes-on-usage","title":"Notes on usage","text":"

              Db2 schema, table, and column names are all case-sensitive when working with GeoTools/GeoServer. When working with Db2 scripts and the Db2 command window, the default is to treat these names as upper-case unless enclosed in double-quote characters but this is not the case in GeoServer.

              "},{"location":"data/database/h2/","title":"H2","text":"

              Note

              GeoServer does not come built-in with support for H2; it must be installed through an extension. Proceed to Installing the H2 extension for installation details.

              "},{"location":"data/database/h2/#h2_install","title":"Installing the H2 extension","text":"
              1. Visit the website download page, locate your release, and download: h2

                Warning

                Ensure to match plugin (example 2.24.2 above) version to the version of the GeoServer instance.

              2. Extract the contents of the archive into the WEB-INF/lib directory of the GeoServer installation.

              "},{"location":"data/database/h2/#adding-an-h2-data-store","title":"Adding an H2 data store","text":"

              Once the extension is properly installed H2 will be an option in the Vector Data Sources list when creating a new data store.

              H2 in the list of vector data stores

              "},{"location":"data/database/h2/#configuring-an-h2-data-store","title":"Configuring an H2 data store","text":"

              Configuring an H2 data store

              "},{"location":"data/database/h2/#configuring-an-h2-data-store-with-jndi","title":"Configuring an H2 data store with JNDI","text":"

              See JNDI.

              "},{"location":"data/database/jndi/","title":"JNDI","text":"

              Many data stores and connections in GeoServer have the option of utilizing Java Naming and Directory Interface on JNDI. JNDI allows for components in a Java system to look up other objects and data by a predefined name.

              A common use of JNDI is to store a JDBC data source globally in a container. This has a few benefits. First, it can lead to a much more efficient use of database resources. Database connections in Java are very resource-intensive objects, so usually they are pooled. If each component that requires a database connection is responsible for creating their own connection pool, resources will stack up fast. In addition, often those resources are under-utilized and a component may not size its connection pool accordingly. A more efficient method is to set up a global pool at the servlet container level, and have every component that requires a database connection use that.

              Furthermore, JNDI consolidates database connection configuration, as not every component that requires a database connection needs to know any more details than the JNDI name. This is very useful for administrators who may have to change database parameters in a running system, as it allows the change to occur in a single place.

              "},{"location":"data/database/mysql/","title":"MySQL","text":"

              Note

              GeoServer does not come built-in with support for MySQL; it must be installed through an extension. Proceed to Installing the MySQL extension for installation details.

              Warning

              Currently the MySQL extension is unmaintained and carries unsupported status. While still usable, do not expect the same reliability as with other extensions.

              MySQL is an open source relational database with some limited spatial functionality.

              "},{"location":"data/database/mysql/#mysql_install","title":"Installing the MySQL extension","text":"
              1. Visit the website download page, locate your release, and download: mysql

                Warning

                Ensure to match plugin (example 2.24.2 above) version to the version of the GeoServer instance.

              2. Extract the contents of the archive into the WEB-INF/lib directory of the GeoServer installation.

              "},{"location":"data/database/mysql/#adding-a-mysql-database","title":"Adding a MySQL database","text":"

              Once the extension is properly installed MySQL will show up as an option when creating a new data store.

              MySQL in the list of data sources

              "},{"location":"data/database/mysql/#configuring-a-mysql-data-store","title":"Configuring a MySQL data store","text":"

              Configuring a MySQL data store

              +------------------------+------------------------------------------------------------------------------------------------------------------------------+ | host | The mysql server host name or ip address. | +------------------------+------------------------------------------------------------------------------------------------------------------------------+ | port | The port on which the mysql server is accepting connections. | +------------------------+------------------------------------------------------------------------------------------------------------------------------+ | database | The name of the database to connect to. Can also contain a suffix with a connection URL query, such as mydbname?useSSL=false | +------------------------+------------------------------------------------------------------------------------------------------------------------------+ | user | The name of the user to connect to the mysql database as. | +------------------------+------------------------------------------------------------------------------------------------------------------------------+ | password | The password to use when connecting to the database. Left blank for no password. | +------------------------+------------------------------------------------------------------------------------------------------------------------------+ | max connections | Connection pool configuration parameters. See the Database Connection Pooling section for details. | | | | | min connections | | | | | | validate connections | | +------------------------+------------------------------------------------------------------------------------------------------------------------------+

              "},{"location":"data/database/oracle/","title":"Oracle","text":"

              Note

              GeoServer does not come built-in with support for Oracle; it must be installed through an extension. Proceed to Installing the Oracle extension for installation details.

              Oracle Spatial and Locator are the spatial components of Oracle. Locator is provided with all Oracle versions, but has limited spatial functions. Spatial is Oracle's full-featured spatial offering, but requires a specific license to use.

              "},{"location":"data/database/oracle/#oracle_install","title":"Installing the Oracle extension","text":"
              1. Visit the website download page, locate your release, and download: oracle

                Warning

                Ensure to match plugin (example 2.24.2 above) version to the version of the GeoServer instance.

              2. Extract the contents of the archive into the WEB-INF/lib directory of the GeoServer installation.

              "},{"location":"data/database/oracle/#adding-an-oracle-datastore","title":"Adding an Oracle datastore","text":"

              Once the extension is properly installed Oracle appears as an option in the Vector Data Sources list when creating a new data store.

              Oracle in the list of data sources

              "},{"location":"data/database/oracle/#configuring-an-oracle-datastore","title":"Configuring an Oracle datastore","text":"

              Configuring an Oracle datastore

              Option Description

              host The Oracle server host name or IP address.

              port The port on which the Oracle server is accepting connections (often this is port 1521).

              database The name of the database to connect to. By default this is interpreted as a SID name. To connect to a Service, prefix the name with a /.

              schema The database schema to access tables from. Setting this value greatly increases the speed at which the data store displays its publishable tables and views, so it is advisable to set this.

              user The name of the user to use when connecting to the database.

              password The password to use when connecting to the database. Leave blank for no password.

              max connections min connections fetch size Connection timeout validate connections Connection pool configuration parameters. See Database Connection Pooling for details.

              Loose bbox Controls how bounding box filters are made against geometries in the database. See the Using loose bounding box section below.

              Metadata bbox Flag controlling the use of MDSYS.USER_SDO_GEOM_METADATA or MDSYS.ALL_SDO_GEOM_METADATA table for bounding box calculations, this brings a better performance if the views access is fast and the bounds are configured right in the tables default is false

              Get remarks Boolean flag specifies whether REMARKS metadata will be returned.

              "},{"location":"data/database/oracle/#connecting-to-an-oracle-cluster","title":"Connecting to an Oracle cluster","text":"

              In order to connect to an Oracle RAC one can use an almost full JDBC url as the database, provided it starts with ( it will be used verbatim and options \"host\" and \"port\" will be ignored. Here is an example \"database\" value used to connect to an Oracle RAC:

              (DESCRIPTION=(LOAD_BALANCE=on)(ADDRESS=(PROTOCOL=TCP)(HOST=host1) (PORT=1521))(ADDRESS=(PROTOCOL=TCP)(HOST=host2) (PORT=1521))(CONNECT_DATA=(SERVICE_NAME=service)))\n

              More information about this syntax can be found in the Oracle documentation.

              "},{"location":"data/database/oracle/#connecting-to-a-sid-or-a-service","title":"Connecting to a SID or a Service","text":"

              Recent versions of Oracle support connecting to a database via either a SID name or a Service name. A SID connection descriptor has the form: host:port:database, while a Service connection descriptor has the format host:port/database. GeoServer uses the SID form by default. To connect via a Service, prefix the database name configuration entry with a /.

              "},{"location":"data/database/oracle/#connecting-to-database-through-ldap","title":"Connecting to database through LDAP","text":"

              For instance if you want to establish a connection with the jdbc thin driver through LDAP, you can use following connect string for the input field database ldap://[host]:[Port]/[db],cn=OracleContext,dc=[oracle_ldap_context].

              If you are using referrals, enable it by placing a jndi.properties file in geoserver's CLASSPATH, which is in geoserver/WEB-INF/classes. This property file contains:

              java.naming.referral=follow

              "},{"location":"data/database/oracle/#oracle_loose_bbox","title":"Using loose bounding box","text":"

              When the Loose bbox option is set, only the bounding box of database geometries is used in spatial queries. This results in a significant performance gain. The downside is that some geometries may be reported as intersecting a BBOX when they actually do not.

              If the primary use of the database is through the Web Map Service (WMS) this flag can be set safely, since querying more geometries does not have any visible effect. However, if using the Web Feature Service (WFS) and making use of BBOX filtering capabilities, this flag should not be set.

              "},{"location":"data/database/oracle/#using-the-geometry-metadata-table","title":"Using the geometry metadata table","text":"

              The Oracle data store by default looks at the MDSYS.USER_SDO* and MDSYS.ALL_SDO* views to determine the geometry type and native SRID of each geometry column. Those views are automatically populated with information about the geometry columns stored in tables that the current user owns (for the MDSYS.USER_SDO* views) or can otherwise access (for the MDSYS.ALL_SDO* views).

              There are a few issues with this strategy:

              • if the connection pool user cannot access the tables (because impersonation is used) the MDSYS views will be empty, making it impossible to determine both the geometry type and the native SRID
              • the geometry type can be specified only while building the spatial indexes, as an index constraint. However such information is often not included when creating the indexes
              • the views are populated dynamically based on the current user. If the database has thousands of tables and users the views can become very slow

              Starting with GeoServer 2.1.4 the administrator can address the above issues by manually creating a geometry metadata table describing each geometry column. Its presence is indicated via the Oracle datastore connection parameter named Geometry metadata table (which may be a simple table name or a schema-qualified one). The table has the following structure (the table name is flexible, just specify the one chosen in the data store connection parameter):

              CREATE TABLE GEOMETRY_COLUMNS(\n   F_TABLE_SCHEMA VARCHAR(30) NOT NULL, \n   F_TABLE_NAME VARCHAR(30) NOT NULL, \n   F_GEOMETRY_COLUMN VARCHAR(30) NOT NULL, \n   COORD_DIMENSION INTEGER, \n   SRID INTEGER NOT NULL, \n   TYPE VARCHAR(30) NOT NULL,\n   UNIQUE(F_TABLE_SCHEMA, F_TABLE_NAME, F_GEOMETRY_COLUMN),\n   CHECK(TYPE IN ('POINT','LINE', 'POLYGON', 'COLLECTION', 'MULTIPOINT', 'MULTILINE', 'MULTIPOLYGON', 'GEOMETRY') ));\n

              When the table is present the store first searches it for information about each geometry column to be classified, and falls back on the MDSYS views only if the table does not contain any information.

              "},{"location":"data/database/oracle/#configuring-an-oracle-database-with-jndi","title":"Configuring an Oracle database with JNDI","text":"

              See Setting up a JNDI connection pool with Tomcat for a guide on setting up an Oracle connection using JNDI.

              "},{"location":"data/database/postgis/","title":"PostGIS","text":"

              PostGIS is an open source spatial database based on PostgreSQL, and is currently one of the most popular open source spatial databases today.

              "},{"location":"data/database/postgis/#adding-a-postgis-database","title":"Adding a PostGIS database","text":"

              As with all formats, adding a shapefile to GeoServer involves adding a new store to the existing Stores through the Web administration interface.

              "},{"location":"data/database/postgis/#using-default-connection","title":"Using default connection","text":"

              To begin, navigate to Stores \u2192 Add a new store \u2192 PostGIS NG.

              Fill in the Basic Store Info used to identify the database when managing layers.

              Adding a PostGIS database

              Basic Store Info Description

              Workspace Name of the workspace to contain the database. This will also be the prefix of any layer names created from tables in the database.

              Data Source Name Name of the database. This can be different from the name as known to PostgreSQL/PostGIS.

              Description Description of the database/store.

              Enabled Enables the store. If disabled, no data in the database will be served.

              Move on to the connection parameters used to connect and interact with the database.

              PostGIS connection parameters

              The dbtype and namespace connection parameters are not directly editable. The dbtype parameter is for internal use only (and only accessible via the REST API).

              Connection Parameter Description

              dbtype Type of database. Internal value, leave this value as the default.

              namespace Namespace to be associated with the database. This field is altered by changing the workspace name.

              Connection parameters establishing a database connection (see Database Connection Pooling):

              Connection Parameter Description

              host Host name where the database exists.

              port Port number to connect to the above host.

              database Name of the database as known on the host.

              schema Schema in the above database.

              user Username to connect to the database.

              passwd Password associated with the above user.

              max connections Maximum amount of open connections to the database.

              min connections Minimum number of pooled connections.

              fetch size Number of records read with each interaction with the database.

              Connection timeout Time (in seconds) the connection pool will wait before timing out.

              validate connections Checks the connection is alive before using it.

              Evictor run periodicity Number of seconds between idle object evictor runs.

              Max connection idle time Number of seconds a connection needs to stay idle before the evictor starts to consider closing it.

              Evictor tests per run Number of connections checked by the idle connection evictor for each of its runs.

              Connection parameters managing SQL generation:

              Connection Parameter Description

              Expose primary keys Expose primary key columns as values suitable for filtering.

              Primary key metadata table Provide table defining how primary keys values are generated (see Controlling feature ID generation in spatial databases)

              Session startup SQL SQL applied to connection before use (see Custom SQL session start/stop scripts)

              Session close-up SQL SQL applied to connection after use (see Custom SQL session start/stop scripts)

              preparedStatements Enables prepared statements for SQL generation, rather than text substitution.

              Max open prepared statements Number of prepared statements available.

              Connection parameters managing database interaction:

              Connection Parameter Description

              Loose bbox Performs only the primary filter on the bounding box. See the section on Using loose bounding box for details.

              Estimated extends Use spatial index to quickly estimate bounds, rather than check every row.

              Encode functions Generate supported filter functions into their SQL equivalent.

              Support on the fly geometry simplification Enables use of PostGIS geometry simplification

              Connection parameters supporting initial database creation:

              Connection Parameter Description

              create database Enable to define a new database on connection

              create database params Additional CREATE DATABASE definition, example WITH TEMPLATE=postgis

              When finished, click Save.

              "},{"location":"data/database/postgis/#using-jndi","title":"Using JNDI","text":"

              GeoServer can also connect to a PostGIS database using JNDI (Java Naming and Directory Interface).

              To begin, navigate to Stores \u2192 Add a new store \u2192 PostGIS NG (JNDI).

              Adding a PostGIS database (using JNDI)

              Option Description

              Workspace Name of the workspace to contain the store. This will also be the prefix of all of the layer names created from the store.

              Data Source Name Name of the database. This can be different from the name as known to PostgreSQL/PostGIS.

              Description Description of the database/store.

              Enabled Enables the store. If disabled, no data in the database will be served.

              dbtype Type of database. Leave this value as the default.

              jndiReferenceName JNDI path to the database.

              schema Schema for the above database.

              namespace Namespace to be associated with the database. This field is altered by changing the workspace name.

              When finished, click Save.

              "},{"location":"data/database/postgis/#configuring-postgis-layers","title":"Configuring PostGIS layers","text":"

              When properly loaded, all tables in the database will be visible to GeoServer, but they will need to be individually configured before being served by GeoServer. See the section on Layers for how to add and edit new layers.

              "},{"location":"data/database/postgis/#postgis_loose_bbox","title":"Using loose bounding box","text":"

              When the option loose bbox is enabled, only the bounding box of a geometry is used. This can result in a significant performance gain, but at the expense of total accuracy; some geometries may be considered inside of a bounding box when they are technically not.

              If primarily connecting to this data via WMS, this flag can be set safely since a loss of some accuracy is usually acceptable. However, if using WFS and especially if making use of BBOX filtering capabilities, this flag should not be set.

              "},{"location":"data/database/postgis/#publishing-a-postgis-view","title":"Publishing a PostGIS view","text":"

              Publishing a view follows the same process as publishing a table. The only additional step is to manually ensure that the view has an entry in the geometry_columns table.

              For example consider a table with the schema:

              my_table( id int PRIMARY KEY, name VARCHAR, the_geom GEOMETRY )\n

              Consider also the following view:

              CREATE VIEW my_view as SELECT id, the_geom FROM my_table;\n

              Before this view can be served by GeoServer, the following step is necessary to manually create the geometry_columns entry:

              INSERT INTO geometry_columns VALUES ('','public','my_view','my_geom', 2, 4326, 'POINT' );\n
              "},{"location":"data/database/postgis/#performance-considerations","title":"Performance considerations","text":""},{"location":"data/database/postgis/#geos","title":"GEOS","text":"

              GEOS (Geometry Engine, Open Source) is an optional component of a PostGIS installation. It is recommended that GEOS be installed with any PostGIS instance used by GeoServer, as this allows GeoServer to make use of its functionality when doing spatial operations. When GEOS is not available, these operations are performed internally which can result in degraded performance.

              "},{"location":"data/database/postgis/#spatial-indexing","title":"Spatial indexing","text":"

              It is strongly recommended to create a spatial index on tables with a spatial component (i.e. containing a geometry column). Any table of which does not have a spatial index will likely respond slowly to queries.

              "},{"location":"data/database/postgis/#common-problems","title":"Common problems","text":""},{"location":"data/database/postgis/#primary-keys","title":"Primary keys","text":"

              In order to enable transactional extensions on a table (for transactional WFS), the table must have a primary key. A table without a primary key is considered read-only to GeoServer.

              GeoServer has an option to expose primary key values (to make filters easier). Please keep in mind that these values are only exposed for your convenience - any attempted to modify these values using WFS-T update will be silently ignored. This restriction is in place as the primary key value is used to define the FeatureId. If you must change the FeatureId you can use WFS-T delete and add in a single Transaction request to define a replacement feature.

              "},{"location":"data/database/postgis/#multi-line","title":"Multi-line","text":"

              To insert multi-line text (for use with labeling) remember to use escaped text:

              INSERT INTO place VALUES (ST_GeomFromText('POINT(-71.060316 48.432044)', 4326), E'Westfield\\nTower');\n
              "},{"location":"data/database/postgis/#jsonpointer-function-support","title":"JsonPointer Function support","text":"

              GeoServer is able to translate the jsonPointer function to a query using PostgreSQL support for JSON types. The following are the main characteristics of the implementation:

              • The jsonPointer function syntax is like the following: jsonPointer(attributeName,'/path/to/json/attribute').
              • The function is able to select attributes inside json arrays by specifying the index of the target element in the json path eg. '/path/to/array/element/0'.
              • When accessing a JSON property it is implicitly assumed that the same property will have the same type on all features, otherwise a cast exception will be thrown by the database.
              • GeoServer will perform a cast automatically to the expect type from the evaluation; the cast is completely delegated to the database.
              • If the property doesn't exists no errors will be issued, but the features that have that property will be excluded; hence the property we wish to query is not mandatory in all features.
              "},{"location":"data/database/postgis/#examples","title":"Examples","text":"

              Having a json column storing jsonvalues like the following,

              { \"name\": \"city name\",

              \"description\": \"the city description\", \"districts\": [ { \"name\":\"district1\", \"population\": 2000 }, { \"name\":\"district2\", \"population\": 5000 } ] \"population\":{ \"average_age\": 35, \"toal\": 50000 }

              }

              and assuming an attribute name as city, valid jsonPointer functions would be:

              • jsonPointer(city, '/name').
              • jsonPointer(city, '/population/average_age').
              • jsonPointer(city, '/districts/0/name').

              An example cql_filter would then be jsonPointer(city, '/population/average_age') > 30.

              While an example rule in a sld style sheet could be:

              <Rule>\n  <Name>Cities</Name>\n     <ogc:Filter>\n       <ogc:PropertyIsEqualTo>\n         <ogc:Function name=\"jsonPointer\">\n           <ogc:PropertyName>city</ogc:PropertyName>\n           <ogc:Literal>/population/average_age</ogc:Literal>\n         </ogc:Function>\n         <ogc:Literal>35</ogc:Literal>\n       </ogc:PropertyIsEqualTo>\n       </ogc:Filter>          \n     <PointSymbolizer>\n       <Graphic>\n         <Mark>\n           <WellKnownName>square</WellKnownName>\n             <Fill>\n               <CssParameter name=\"fill\">#FF0000</CssParameter>\n             </Fill>\n         </Mark>\n         <Size>16</Size>\n       </Graphic>\n    </PointSymbolizer>\n </Rule>\n
              "},{"location":"data/database/postgis/#datatypes","title":"DataTypes","text":"

              PostgreSQL defines two JSON datatypes:

              • json that stores an exact copy of the input text.
              • jsonb which store the value in a decomposed binary format.

              The jsonPointer function supports both, as well as the text format if it contains a valid json representation. Anyways, the PostgreSQL documentation recommends usage of jsonb, as it is faster to process.

              PostgreSQL supports also indexing on json types. And index on a specific json attribute can be created as follow:

              CREATE INDEX description_index ON table_name ((column_name -> path -> to ->> json_attribute )).

              Index can also be specified in partial way:

              CREATE INDEX description_index ON table_name ((column_name -> path -> to ->> json_attribute )) WHERE (column_name -> path -> to ->> json_attribute) IS NOT NULL.

              "},{"location":"data/database/primarykey/","title":"Controlling feature ID generation in spatial databases","text":""},{"location":"data/database/primarykey/#introduction","title":"Introduction","text":"

              All spatial database data stores (PostGIS, Oracle, MySQL and so on) normally derive the feature ID from the table primary key and assume certain conventions on how to locate the next value for the key in case a new feature needs to be generated (WFS insert operation).

              Common conventions rely on finding auto-increment columns (PostGIS) or finding a sequence that is named after a specific convention such as <table>_<column>_SEQUENCE (Oracle case).

              In case none of the above is found, normally the store will fall back on generating random feature IDs at each new request, making the table unsuitable for feature ID based searches and transactions.

              "},{"location":"data/database/primarykey/#metadata-table-description","title":"Metadata table description","text":"

              These defaults can be overridden manually by creating a primary key metadata table that specifies which columns to use and what strategy to use to generate new primary key values. The (schema qualified) table can be created with this SQL statement (this one is valid for PostGIS and ORACLE, adapt it to your specific database, you may remove the check at the end if you want to):

              --PostGIS DDL\n\nCREATE TABLE my_schema.gt_pk_metadata (\n  table_schema VARCHAR(32) NOT NULL,\n  table_name VARCHAR(32) NOT NULL,\n  pk_column VARCHAR(32) NOT NULL,\n  pk_column_idx INTEGER,\n  pk_policy VARCHAR(32),\n  pk_sequence VARCHAR(64),\n  unique (table_schema, table_name, pk_column),\n  check (pk_policy in ('sequence', 'assigned', 'autogenerated'))\n)\n\n\n--ORACLE DDL\n\nCREATE TABLE gt_pk_metadata (\n  table_schema VARCHAR2(32) NOT NULL,\n  table_name VARCHAR2(32) NOT NULL,\n  pk_column VARCHAR2(32) NOT NULL,\n  pk_column_idx NUMBER(38),\n  pk_policy VARCHAR2(32),\n  pk_sequence VARCHAR2(64),\n  constraint  chk_pk_policy check (pk_policy in ('sequence', 'assigned', 'autogenerated')));\n\nCREATE UNIQUE INDEX gt_pk_metadata_table_idx01 ON gt_pk_metadata (table_schema, table_name, pk_column);\n

              The table can be given a different name. In that case, the (schema qualified) name of the table must be specified in the primary key metadata table configuration parameter of the store.

              The following table describes the meaning of each column in the metadata table.

              Column Description

              table_schema Name of the database schema in which the table is located.

              table_name Name of the table or view to be published

              pk_column Name of a column used to form the feature IDs

              pk_column_idx Index of the column in a multi-column key, else NULL. In case multi column keys are needed, multiple records with the same table schema and table name will be used.

              pk_policy The new value generation policy, used in case a new feature needs to be added in the table (following a WFS-T insert operation).

              pk_sequence The name of the database sequence to be used when generating a new value for the pk_column.

              The possible values for pk_policy are:

              • assigned. The value of the attribute in the newly inserted feature will be used (this assumes the \"expose primary keys\" flag has been enabled)
              • sequence. The value of the attribute will be generated from the next value of a sequence indicated in the pk_sequence column.
              • autogenerated. The column is an auto-increment one, the next value in the auto-increment will be used.
              "},{"location":"data/database/primarykey/#using-the-metadata-table-with-views","title":"Using the metadata table with views","text":"

              GeoServer can publish spatial views without issues, but normally results in two side effects:

              • the view is treated as read only
              • the feature IDs are randomly generated

              The metadata table can also refer to views, just use the view name in the table_name column: this will result in stable ids, and in databases supporting updatable views, it will also make the code treat the view as writable (thus, enabling usage of WFS-T on it).

              "},{"location":"data/database/sqlserver/","title":"Microsoft SQL Server and SQL Azure","text":"

              Note

              GeoServer does not come built-in with support for SQL Server; it must be installed through an extension. Proceed to Installing the SQL Server extension for installation details.

              Microsoft's SQL Server is a relational database with spatial functionality. SQL Azure is the database option provided in the Azure cloud solution which is in many respects similar to SQL Server.

              "},{"location":"data/database/sqlserver/#supported-versions","title":"Supported versions","text":"

              The extension supports SQL Server 2008 - 2019 and SQL Azure.

              "},{"location":"data/database/sqlserver/#sqlserver_install","title":"Installing the SQL Server extension","text":""},{"location":"data/database/sqlserver/#geoserver-files","title":"GeoServer files","text":"
              1. Visit the website download page, locate your release, and download: sqlserver

                Warning

                Ensure to match plugin (example 2.24.2 above) version to the version of the GeoServer instance.

              2. Extract the contents of the archive into the WEB-INF/lib directory of the GeoServer installation.

              3. Restart the GeoServer to load the extension.

              "},{"location":"data/database/sqlserver/#adding-a-sql-server-database","title":"Adding a SQL Server database","text":"

              Once the extension is properly installed SQL Server will show up as an option when creating a new data store.

              SQL Server in the list of vector data sources

              "},{"location":"data/database/sqlserver/#configuring-a-sql-server-data-store","title":"Configuring a SQL Server data store","text":"

              Configuring a SQL Server data store

              +-------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | host | The sql server instance host name or ip address, only. Note that server\\instance notation is not accepted - specify the port below, instead, if you have a non-default instance. | +-------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | port | The port on which the SQL server instance is accepting connections. See the note below. | +-------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | database | The name of the database to connect to. Might be left blank if the user connecting to SQL Server has a \"default database\" set in the user configuration | +-------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | schema | The database schema to access tables from (optional). | +-------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | user | The name of the user to connect to the database as. | +-------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | password | The password to use when connecting to the database. Leave blank for no password. | +-------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | max connections | Connection pool configuration parameters. See the Database Connection Pooling section for details. If you are connecting to SQL Azure make sure to set the validate connections flag as SQL Azure closes inactive connections after a very short delay. | | | | | min connections | | +-------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+

              "},{"location":"data/database/sqlserver/#port_notes","title":"Determining the port used by the SQL Server instance","text":"

              You can determine the port in use by connecting to your SQL server instance using some other software, and then using netstat to display details on network connections. In the following example on a Windows PC, the port is 2646 :

              C:>netstat -a | find \"sql1\"\nTCP   DPI908194:1918   maittestsql1.dpi.nsw.gov.au:2646   ESTABLISHED\n
              "},{"location":"data/database/sqlserver/#using-the-geometry-metadata-table","title":"Using the geometry metadata table","text":"

              The SQL server data store can determine the geometry type and native SRID of a particular column only by data inspection, by looking at the first row in the table. Of course this is error prone, and works only if there is data in the table. The administrator can address the above issue by manually creating a geometry metadata table describing each geometry column. Its presence is indicated via the SQL Server datastore connection parameter named Geometry metadata table (which may be a simple table name or a schema-qualified one). The table has the following structure (the table name is flexible, just specify the one chosen in the data store connection parameter):

              CREATE TABLE GEOMETRY_COLUMNS(\n   F_TABLE_SCHEMA VARCHAR(30) NOT NULL,\n   F_TABLE_NAME VARCHAR(30) NOT NULL,\n   F_GEOMETRY_COLUMN VARCHAR(30) NOT NULL,\n   COORD_DIMENSION INTEGER,\n   SRID INTEGER NOT NULL,\n   TYPE VARCHAR(30) NOT NULL,\n   UNIQUE(F_TABLE_SCHEMA, F_TABLE_NAME, F_GEOMETRY_COLUMN),\n   CHECK(TYPE IN ('POINT', 'LINESTRING', 'POLYGON', 'MULTIPOINT', 'MULTILINESTRING', 'MULTIPOLYGON', 'GEOMETRYCOLLECTION') ));\n

              When the table is present the store first searches it for information about each geometry column to be classified, and falls back on data inspection only if the table does not contain any information.

              "},{"location":"data/database/sqlsession/","title":"Custom SQL session start/stop scripts","text":"

              Starting with version 2.1.4 GeoServer support custom SQL scripts that can be run every time GeoServer grabs a connection from the connection pool, and every time the session is returned to the pool.

              These scripts can be parametrized with the expansion of environment variables, which can be in turn set into the OGC request parameters with the same mechanism as Variable substitution in SLD.

              In addition to the parameters provided via the request the GSUSER variable is guaranteed to contain the current GeoServer user, or be null if no authentication is available. This is useful if the SQL sessions scripts are used to provide tight control over database access

              The SQL script can expand environment variables using the ${variableName, defaultValue} syntax, for example the following alters the current database user to be the same as the GeoServer current user, or geoserver in case no user was authenticated

              SET SESSION AUTHORIZATION \\${GSUSER,geoserver}

              "},{"location":"data/database/sqlsession/#using-sql-session-scripts-to-control-authorizations-at-the-database-level","title":"Using SQL session scripts to control authorizations at the database level","text":"

              GeoServer connects to a database via a connection pool, using the same rights as the user that is specified in the connection pool setup. In a setup that provides a variety of services and tables the connection pool user must have a rather large set of rights, such as table selection (WMS), table insert/update/delete (WFS-T) and even table creation (data upload via RESTConfig, WPS Import process and eventual new processes leveraging direct database connections).

              What a user can do can be controlled by means of the GeoServer security subsystem, but in high security setups this might not be considered enough, and a database level access control be preferred instead. In these setups normally the connection pool user has limited access, such as simple read only access, while specific users are allowed to perform more operations.

              When setting up such a solution remember the following guidelines:

              • The connection pool user must be able to access all table metadata regardless of whether it is able to actually perform a select on the tables (dictionary tables/describe functionality must be always accessible)
              • The connection pool must see each and every column of tables and views, in other words, the structure of the tables must not change as the current user changes
              • the database users and the GeoServer user must be kept in synch with some external tools, GeoServer provides no out of the box facilities
              • during the GeoServer startup the code will access the database to perform some sanity checks, in that moment there is no user authenticated in GeoServer so the code will run under whatever user was specified as the \"default value\" for the GSUSER variable.
              • The user that administers GeoServer (normally admin, but it can be renamed, and other users given the administration roles too) must also be a database user, all administrative access on the GeoServer GUI will have that specific user controlling the session

              Typical use cases:

              • Give insert/update/delete rights only to users that must use WFS-T
              • Only allow the administrator to create new tables
              • Limit what rows of a table a user can see by using dynamic SQL views taking into account the current user to decide what rows to return

              To make a point in case, if we want the PostgreSQL session to run with the current GeoServer user credentials the following scripts will be used:

              Setting up session authorization for PostgreSQL

              The first command makes the database session use either the current GeoServer user, or the geoserver user if no authentication was available (anonymous user, or startup situation). The second command resets the session to the rights of the connection pool user.

              "},{"location":"data/database/sqlview/","title":"SQL Views","text":"

              The traditional way to access database data is to configure layers against either tables or database views. Starting with GeoServer 2.1.0, layers can also be defined as SQL Views. SQL Views allow executing a custom SQL query on each request to the layer. This avoids the need to create a database view for complex queries.

              Even more usefuly, SQL View queries can be parameterized via string substitution. Parameter values can be supplied in both WMS and WFS requests. Default values can be supplied for parameters, and input values can be validated by Regular Expressions to eliminate the risk of SQL injection attacks.

              Note

              SQL Views are read-only, and thus cannot be updated by WFS-T transactions.

              "},{"location":"data/database/sqlview/#creating-a-sql-view","title":"Creating a SQL View","text":"

              In order to create a SQL View the administrator invokes the Create new layer page. When a database store is selected, the usual list of tables and views available for publication appears, A link Configure new SQL view... also appears:

              Selecting the Configure new SQL view... link opens a new page where the SQL view query can be specified:

              Note

              The query can be any SQL statement that is valid as a subquery in a FROM clause (that is, select * from (<the sql view>) [as] vtable). This is the case for most SQL statements, but in some databases special syntax may be needed to call stored procedures. Also, all the columns returned by the SQL statement must have names. In some databases alias names are required for function calls.

              When a valid SQL query has been entered, press the Refresh link in the Attributes table to get the list of the attribute columns determined from the query:

              GeoServer attempts to determine the geometry column type and the native SRID, but these should be verified and corrected if necessary.

              Note

              Having a correct SRID (spatial reference id) is essential for spatial queries to work. In many spatial databases the SRID is equal to the EPSG code for the specific spatial reference system, but this is not always the case (for instance, Oracle has a number of non-EPSG SRID codes).

              If stable feature ids are desired for the view's features, one or more columns providing a unique id for the features should be checked in the Identifier column. Always ensure these attributes generate a unique key, or filtering and WFS requests will not work correctly.

              Once the query and the attribute details are defined, press Save. The usual New Layer configuration page will appear. If further changes to the view are required, the page has a link to the SQL View editor at the bottom of the Data tab:

              Once created, the SQL view layer is used in the same way as a conventional table-backed layer, with the one limitation of being read-only.

              Warning

              Saving the SQL view definition here is not sufficient, the layer containing it must be saved as well for the change to have any effect. This is because the SQL view definition is actually just one component of the layer/featuretype/coverage attributes.

              "},{"location":"data/database/sqlview/#parameterizing-sql-views","title":"Parameterizing SQL Views","text":"

              A parametric SQL view is based on a SQL query containing named parameters. The values for the parameters can be provided dynamically in WMS and WFS requests using the viewparams request parameter. Parameters can have default values specified, to handle the situation where they are not supplied in a request. Validation of supplied parameter values is supported by specifying validation regular expressions. Parameter values are only accepted if they match the regular expression defined for them. Appropriate parameter validation should always be used to avoid the risk of SQL injection attacks.

              Warning

              SQL View parameter substitution should be used with caution, since improperly validated parameters open the risk of SQL injection attack. Where possible, consider using safer methods such as dynamic filtering in the request, or Variable substitution in SLD.

              "},{"location":"data/database/sqlview/#defining-parameters","title":"Defining parameters","text":"

              Within the SQL View query, parameter names are delimited by leading and trailing % signs. The parameters can occur anywhere within the query text, including such uses as within SQL string constants, in place of SQL keywords, or representing entire SQL clauses.

              Here is an example of a SQL View query for a layer called popstates with two parameters, low and high:

              Each parameter needs to be defined with its name, an optional default value, and a validation expression. The Guess parameters from SQL link can be clicked to infer the query parameters automatically, or they can be entered manually. The result is a table filled with the parameter names, default values and validation expressions:

              In this case the default values should be specified, since the query cannot be executed without values for the parameters (because the expanded query select gid, state_name, the_geom from pgstates where persons between and is invalid SQL). Since the use of the parameters in the SQL query requires their values to be positive integer numbers, the validation regular expressions are specified to allow only numeric input (i.e. ^[\\d]+$):

              Once the parameters have been defined, the Attributes Refresh link is clicked to parse the query and retrieve the attribute columns. The computed geometry type and column identifier details can be corrected if required. From this point on the workflow is the same as for a non-parameterized query.

              "},{"location":"data/database/sqlview/#using_a_parametric_sql_view","title":"Using a parametric SQL View","text":"

              The SQL view parameters are specified by adding the viewparams parameter to the WMS GetMap or the WFS GetFeature request. The viewparams argument is a list of key:value pairs, separated by semicolons:

              viewparams=p1:v1;p2:v2;...

              If the values contain semicolons or commas these must be escaped with a backslash (e.g. \\, and \\;).

              For example, the popstates SQL View layer can be displayed by invoking the Layer Preview. Initially no parameter values are supplied, so the defaults are used and all the states are displayed.

              To display all states having more than 20 million inhabitants the following parameter is added to the GetMap request: &viewparams=low:20000000

              To display all states having between 2 and 5 million inhabitants the view parameters are: &viewparams=low:2000000;high:5000000

              Parameters can be provided for multiple layers by separating each parameter map with a comma:

              &viewparams=l1p1:v1;l1p2:v2,l2p1:v1;l2p2:v2,...

              The number of parameter maps must match the number of layers (featuretypes) included in the request.

              "},{"location":"data/database/sqlview/#using-xml-view-parameters-format","title":"Using XML View parameters format","text":"

              Aside the default SQL view parameters format, an XML format is available by using the request parameter/value:

              &viewParamsFormat=XML

              XML alternative format example:

              &viewParams=<VP><PS><P n=\"m1\">8302,802,8505</P><P n=\"m2\">22,44</P></PS><PS/><PS><P n=\"csvInput\">acv,rrp;1,0;0,7;22,1</P></PS></VP>

              viewParamsFormat new optional parameter definition:
              • Selects the view parameters format, valid implementation values are CharSeparated (default) and XML.
              • It's an optional parameter, if not set the default character separated format will be used supporting backward compatibility.
              XML tags/attributes definition:
              • VP: the root XML element tag for View Params. This ensures XML validity (an XML document must have a single root element).
              • PS: contains the parameters for a given layer (by position). If there are no parameters for the current layer this must be set as an empty element, e.g. <PS/>
              • P: the parameter definition XML element, including the parameter name as the n attribute and the value as its text content.
              • n: the parameter name attribute inside the P element.

              If a layer doesn't have parameters to be set, just provide an empty PS element : <PS/>

              Note: XML view parameters can be used only in GET requests.

              "},{"location":"data/database/sqlview/#parameters-and-validation","title":"Parameters and validation","text":"

              The value of a SQL View parameter can be an arbitrary string of text. The only constraint is that the attribute names and types returned by the view query must never change. This makes it possible to create views containing parameters representing complex SQL fragments. For example, using the view query select * from pgstates %where% allows specifying the WHERE clause of the query dynamically. However, this would likely require an empty validation expression. which presents a serious risk of SQL injection attacks. This technique should only be used if access to the server is restricted to trusted clients.

              In general, SQL parameters must be used with care. They should always include validation regular expressions that accept only the intended parameter values. Note that while validation expressions should be constructed to prevent illegal values, they do not necessarily have to ensure the values are syntactically correct, since this will be checked by the database SQL parser. For example:

              • ^[\\d\\.\\+-eE]+$ checks that a parameter value contains valid characters for floating-point numbers (including scientific notation), but does not check that the value is actually a valid number
              • [^;']+ checks that a parameter value does not contain quotes or semicolons. This prevents common SQL injection attacks, but otherwise does not impose much limitation on the actual value
              "},{"location":"data/database/sqlview/#resources-for-validation-regular-expressions","title":"Resources for Validation Regular expressions","text":"

              Defining effective validation regular expressions is important for security. Regular expressions are a complex topic that cannot be fully addressed here. The following are some resources for constructing regular expressions:

              • GeoServer uses the standard Java regular expression engine. The Pattern class Javadocs contain the full specification of the allowed syntax.
              • http://www.regular-expressions.info has many tutorials and examples of regular expressions.
              • The myregexp applet can be used to test regular expressions online.
              "},{"location":"data/database/sqlview/#place-holder-for-the-sql-where-clause","title":"Place holder for the SQL WHERE clause","text":"

              The SQL WHERE clause produced by GeoServer using the context filters, e.g. the bounding box filter of a WMS query, will be added around the SQL view definition. This comes handy (better performance) when we have extra operations that can be done on top of the rows filtered with the GeoServer produced filter first.

              A typical use case for this functionality is the execution of analytic functions on top of the filtered results:

              SELECT STATION_NAME,\n       MEASUREMENT,\n       MEASUREMENT_TYPE,\n       LOCATION\nFROM\n  (SELECT STATION_NAME,\n          MEASUREMENT,\n          MEASUREMENT_TYPE,\n          LOCATION,\n          ROW_NUMBER() OVER(PARTITION BY STATION_ID, MEASUREMENT_TYPE\n                            ORDER BY TIME DESC) AS RANK\n   FROM\n     (SELECT st.id AS STATION_ID,\n             st.common_name AS STATION_NAME,\n             ob.value AS MEASUREMENT,\n             pr.param_name AS MEASUREMENT_TYPE,\n             ob.time AS TIME,\n             st.position AS LOCATION\n      FROM meteo.meteo_stations st\n      LEFT JOIN meteo.meteo_observations ob ON st.id = ob.station_id\n      LEFT JOIN meteo.meteo_parameters pr ON ob.parameter_id = pr.id\n\n      -- SQL WHERE clause place holder for GeoServer\n      WHERE 1 = 1 :where_clause:) AS stations_filtered) AS stations\n\nWHERE RANK = 1;\n

              A few restrictions apply when using the explicit :where_clause: place holder:

              • it needs to be added in a position where all the attributes known by GeoServer are already present
              • the :where_clause: can only appear once

              When a WHERE clause place holder is present, GeoServer will always add an explicit AND at the beginning of the produced WHERE clause. This allows the injection of the produced WHERE in the middle of complex expressions if needed.

              "},{"location":"data/raster/","title":"Raster data","text":"

              This section discusses the raster (coverage) data sources that GeoServer can access.

              The standard GeoServer installation supports the loading and serving of the following data formats:

              • GeoTIFF
              • WorldImage
              • ImageMosaic
              • GeoPackage

              Other data sources are supplied as GeoServer extensions. Extensions are downloadable modules that add functionality to GeoServer. Extensions are available at the GeoServer download page.

              Warning

              The extension version must match the version of the GeoServer instance.

              • ArcGrid
              • GDAL Image Formats
              • ImagePyramid

              GeoServer provides extensive facilities for controlling how rasters are accessed. These are covered in the following sections.

              • Coverage Views
              "},{"location":"data/raster/arcgrid/","title":"ArcGrid","text":"

              ArcGrid is a coverage file format created by ESRI.

              "},{"location":"data/raster/arcgrid/#adding-an-arcgrid-data-store","title":"Adding an ArcGrid data store","text":"

              By default, ArcGrid will be an option in the Raster Data Sources list when creating a new data store.

              ArcGrid in the list of raster data stores

              "},{"location":"data/raster/arcgrid/#configuring-a-arcgrid-data-store","title":"Configuring a ArcGrid data store","text":"

              Configuring an ArcGrid data store

              Option Description

              Workspace

              Data Source Name

              Description

              Enabled

              URL

              "},{"location":"data/raster/coverageview/","title":"Coverage Views","text":"

              Starting with GeoServer 2.6.0, You can define a new raster layer as a Coverage View. Coverage Views allow defining a View made of different bands originally available inside coverages (either bands of the same coverage or different coverages) of the same Coverage Store.

              "},{"location":"data/raster/coverageview/#creating-a-coverage-view","title":"Creating a Coverage View","text":"

              In order to create a Coverage View the administrator invokes the Create new layer page. When a Coverage store is selected, the usual list of coverages available for publication appears. A link Configure new Coverage view... also appears:

              Selecting the Configure new Coverage view... link opens a new page where you can configure the coverage view:

              The upper text box allows to specify the name to be assigned to this coverage view. (In the following picture we want to create as example, a currents view merging together both u and v components of the currents, which are exposed as separated 1band coverages).

              Next step is defining the output bands to be put in the coverage view. It is possible to specify which input coverage bands need to be put on the view by selecting them from the Composing coverages/bands....

              Once selected, they needs to be added to the output bands of the coverage view, using the add button.

              Optionally, is it possible to remove the newly added bands using the remove and remove all buttons. Once done, clicking on the save button will redirect to the standard Layer configuration page.

              Scrolling down to the end of the page, is it possible to see the bands composing the coverage (and verify they are the one previously selected).

              At any moment, the Coverage View can be refined and updated by selecting the Edit Coverage view... link available before the Coverage Bands details section.

              Once all the properties of the layer have been configured, by selecting the Save button, the coverage will be saved in the catalog and it will become visible as a new layer.

              "},{"location":"data/raster/coverageview/#heterogeneous-coverage-views","title":"Heterogeneous coverage views","text":"

              In case the various coverages bound in the view have different resolution, the UI will present two extra controls:

              The coverage envelope policy defines how the bounding box of the output is calculated for metadata purposes. Having different resolutions, the coverages are unlikely to share the same bounding box. The possible values are:

              • Intersect envelopes: Use the intersection of all input coverage envelopes
              • Union envelopes: Use the union of all input coverage envelopes

              The coverage resolution policy defines which target resolution is used when generating outputs:

              • Best: Use the best resolution available among the chosen bands (e.g., in a set having 60m, 20m and 10m the 10m resolution will be chosen)
              • Worst: Use the worst resolution available among the chosen bands (e.g., in a set having 60m, 20m and 10m the 60m resolution will be chosen)

              The coverage resolution policy is context sensitive. Assume the input is a 12 bands Sentinel 2 dataset at three different resolution, 10, 20 and 30 meters, and a false color image is generated by performing a band selection in the SLD. If the policy is best and the SLD selects only bands at 20 and 60 meters, the output will be at 20 meters instead of 10 meters.

              "},{"location":"data/raster/coverageview/#coverage-view-in-action","title":"Coverage View in action","text":"

              A Layer preview of the newly created coverage view will show the rendering of the view. Note that clicking on a point on the map will result into a GetFeatureInfo call which will report the values of the bands composing the coverage view.

              "},{"location":"data/raster/gdal/","title":"GDAL Image Formats","text":"

              GeoServer can leverage the ImageI/O-Ext GDAL libraries to read selected coverage formats. GDAL is able to read many formats, but for the moment GeoServer supports only a few general interest formats and those that can be legally redistributed and operated in an open source server.

              The following image formats can be read by GeoServer using GDAL:

              • DTED, Military Elevation Data (.dt0, .dt1, .dt2): http://www.gdal.org/frmt_dted.html
              • EHdr, ESRI .hdr Labelled: <http://www.gdal.org/frmt_various.html#EHdr>
              • ENVI, ENVI .hdr Labelled Raster: <http://www.gdal.org/frmt_various.html#ENVI>
              • HFA, Erdas Imagine (.img): <http://www.gdal.org/frmt_hfa.html>
              • JP2MrSID, JPEG2000 (.jp2, .j2k): <http://www.gdal.org/frmt_jp2mrsid.html>
              • MrSID, Multi-resolution Seamless Image Database: <http://www.gdal.org/frmt_mrsid.html>
              • NITF: <http://www.gdal.org/frmt_nitf.html>
              • ECW, ERDAS Compressed Wavelets (.ecw): <http://www.gdal.org/frmt_ecw.html>
              • JP2ECW, JPEG2000 (.jp2, .j2k): http://www.gdal.org/frmt_jp2ecw.html
              • AIG, Arc/Info Binary Grid: <http://www.gdal.org/frmt_various.html#AIG>
              • JP2KAK, JPEG2000 (.jp2, .j2k): <http://www.gdal.org/frmt_jp2kak.html>
              "},{"location":"data/raster/gdal/#installing-gdal-extension","title":"Installing GDAL extension","text":"

              From GeoServer version 2.2.x, GDAL must be installed as an extension. To install it:

              1. Visit the website download page, locate your release, and download: gdal

                Warning

                Ensure to match plugin (example 2.24.2 above) version to the version of the GeoServer instance.

              2. The download link for GDAL will be in the Extensions section under Coverage Format.

              • Extract the files in this archive to the WEB-INF/lib directory of your GeoServer installation. On Windows You may be prompted for confirmation to overwrite existing files, confirm the replacement of the files

              Moreover, in order for GeoServer to leverage these libraries, the GDAL (binary) libraries must be installed through your host system's OS. Once they are installed, GeoServer will be able to recognize GDAL data types. See below for more information.

              "},{"location":"data/raster/gdal/#installing-gdal-native-libraries","title":"Installing GDAL native libraries","text":"

              Starting with GeoServer 2.21.x the imageio-ext plugin is tested with GDAL version 3.x (tested in particular with 3.2.x and 3.4.x).

              The imageio-ext plugin is tested with the GDAL 3.2 SWIG bindings, included in the extension download as gdal-3.2.0.jar.

              "},{"location":"data/raster/gdal/#in-case-of-version-mismatch","title":"In case of version mismatch","text":"

              We recommend matching the version gdal jar to the version of gdal available in your environment:

              gdalinfo --version\n
              GDAL 3.4.1, released 2021/12/27\n

              If you are using a version of GDAL that does not match the one expected by GeoServer, you can go and replace the gdal-3.2.0.jar file with the equivalent java binding jar (typically named either gdal-<version>.jar) included with your GDAL version:

              • If your GDAL version does not include a bindings jar, it was probably not compiled with the java bindings and will not work with GeoServer.
              • You may also search for the correct gdal jar here: https://search.maven.org/artifact/org.gdal/gdal
              "},{"location":"data/raster/gdal/#windows-packages-and-setup","title":"Windows packages and setup","text":"

              For Windows, gisinternals.com provides complete packages, with Java bindings support, in the release-<version>-GDAL-<version>-mapserver-<version>.zip packages (the GDAL binary downloads at the time of writing do not include Java support).

              Unpack the zip file in a suitable location, and then set the following variables before starting up GeoServer:

              set PATH=%PATH%;C:\\<unzipped_package>\\bin;C:\\<unzipped_package>\\bin\\gdal\\java\nset GDAL_DRIVER_PATH=C:\\<unzipped_package>\\bin\\gdal\\plugins\nset GDAL_DATA=C:\\<unzipped_package>\\bin\\gdal-data\n

              There are a few optional drivers that you can find in [file:C:\\](file:%60C:\\)<unzipped_package>bingdalplugins-extra and C:<unzipped_package>bingdalplugins-optional. Include these paths in `GDAL_DRIVER_PATH enables the additional formats.

              Warning

              Before adding the extra formats please make sure that you are within your rights to use them in a server environment (some packages are specifically forbidden from free usage on the server side and require a commercial licence, e.g., ECW).

              Note

              Depending on the version of the underlying operating system you will have to pick up the right one. You can google around for the one you need. Also make sure you download the 32 bit version if you are using a 32 bit version of Windows or the 64 bit version (has a \"-x64\" suffix in the name of the zip file) if you are running a 64 bit version of Windows. Again, pick the one that matches your infrastructure.

              "},{"location":"data/raster/gdal/#note-on-running-geoserver-as-a-service-on-windows","title":"Note on running GeoServer as a Service on Windows","text":"

              Deploying the GDAL ImageI/O-Ext native libraries in a location referred by the PATH environment variable (like, as an instance, the JDK/bin folder) will not allow the GeoServer service to use GDAL. As a result, during the service startup, GeoServer log will likely report the following message:

              it.geosolutions.imageio.gdalframework.GDALUtilities loadGDAL\nWARNING: Native library load failed.java.lang.UnsatisfiedLinkError: no gdaljni in java.library.path\n

              Taking a look at the jsl74.ini configuration file available inside the GeoServer installation , there is this useful entry:

              ;The java command line\n;The entry method below using a parameter list still works but the command line variant is more convenient.\n;Everything separated by whitespace on a java command line is broken down into a parameter here. \n;You don't need to care about quotes\n;around strings containing spaces here. e.g. \ncmdline = -cp \"..\\src\" com.roeschter.jsl.TelnetEcho\n

              To allow the GDAL native DLLs to be loaded:

              1. Edit the command line to include -Djava.library.path with the location of your GDAL libraries.
              "},{"location":"data/raster/gdal/#linux-packages-and-setup","title":"Linux packages and setup","text":"

              For common LTS Linux distribution there are packages for GDAL and the associated Java bindings, e.g., on Ubuntu and derivatives you can install them using:

              sudo apt-get install gdal-bin libgdal-java\n

              The libraries as installed above are already in the search path, so no extra setup is normally needed. In case setting up the GDAL_DATA is required to handle certain projections, it's normally found in /usr/share/gdal/<version>, so you can execute the following prior to start GeoServer, e.g:

              export GDAL_DATA=/usr/share/gdal/<version>\n

              In case you decide to build from sources instead, remember to run configure with --with-java, and after the main build and install, get into the swig/java and run a build and install there. For more information about building GDAL see:

              • General build information
              • Specific info to build GDAL Java bindings

              After the build and installation, export the following variables to make GeoServer use the GDAL custom build:

              export LD_LIBRARY_PATH=/<path_to_gdal_install>/lib\nexport GDAL_DATA=/<path_to_gdal_install>/share/gdal\n
              "},{"location":"data/raster/gdal/#testing-the-installation","title":"Testing the installation","text":"

              Once these steps have been completed, restart GeoServer.

              Navigate to About > Server Status page, and change to the Modules tab, and click **** link for status information.

              ImageI/O GDAL Coverage Extension Module Status

              This information can be used to verify that the extension is active, the version of GDAL used, and the version of the SWIG bindings used.

              If all the steps have been performed correctly, new data formats will be in the Raster Data Sources list when creating a new data store in the Stores section as shown here below.

              GDAL image formats in the list of raster data stores

              If new formats do not appear in the GUI and you see the following message in the log file:

              it.geosolutions.imageio.gdalframework.GDALUtilities loadGDAL WARNING: Native library load failed.java.lang.UnsatisfiedLinkError: no gdaljni in java.library.path WARNING: Native library load failed.java.lang.UnsatisfiedLinkError: no gdalalljni in java.library.path*

              This means that the extension was installed, bu twas not able to access your gdal library for some reason.

              "},{"location":"data/raster/gdal/#configuring-a-dted-data-store","title":"Configuring a DTED data store","text":"

              Configuring a DTED data store

              "},{"location":"data/raster/gdal/#configuring-a-ehdr-data-store","title":"Configuring a EHdr data store","text":"

              Configuring a EHdr data store

              "},{"location":"data/raster/gdal/#configuring-a-erdasimg-data-store","title":"Configuring a ERDASImg data store","text":"

              Configuring a ERDASImg data store

              "},{"location":"data/raster/gdal/#configuring-a-jp2mrsid-data-store","title":"Configuring a JP2MrSID data store","text":"

              Configuring a JP2MrSID data store

              "},{"location":"data/raster/gdal/#configuring-a-nitf-data-store","title":"Configuring a NITF data store","text":"

              Configuring a NITF data store

              "},{"location":"data/raster/gdal/#supporting-vector-footprints","title":"Supporting vector footprints","text":"

              Starting with version 2.9.0, GeoServer supports vector footprints. A footprint is a shape used as a mask to hide those pixels that are outside of the mask, hence making that part of the parent image transparent. The currently supported footprint formats are WKB, WKT and Shapefile. By convention, the footprint file should be located in the same directory as the raster data that the footprint applies to.

              Note

              In the examples of this section and related subsections, we will always use .wkt as extension, representing a WKT footprint, although both .wkb and .shp are supported too.

              For example, supposing you have a MrSID file located at /mnt/storage/data/landsat/N-32-40_2000.sid to be masked, you just need to place a WKT file on the same folder, as /mnt/storage/data/landsat/N-32-40_2000.wkt Note that the footprint needs to have same path and name of the original data file, with .wkt extension.

              This is how the sample footprint geometry looks:

              A sample geometry stored as WKT, rendered on OpenJump

              Once footprint file has been added, you need to change the FootprintBehavior parameter from None (the default value) to Transparent, from the layer configuration.

              Setting the FootprintBehavior parameter

              The next image depicts 2 layer previews for the same layer: the left one has no footprint, the right one has a footprint available and FootprintBehavior set to transparent.

              No Footprint VS FootprintBehavior = Transparent

              "},{"location":"data/raster/gdal/#external-footprints-data-directory","title":"External Footprints data directory","text":"

              As noted above, the footprint file should be placed in the same directory as the raster file. However in some cases this may not be possible. For example, the folder containing the raster data may be read only.

              As an alternative, footprint files can be located in a common directory, the footprints data directory. The subdirectories and file names under that directory must match the original raster path and file names. The footprints data directory is specified as a Java System Property or an Environment Variable, by setting the FOOTPRINTS_DATA_DIR property/variable to the directory to be used as base folder.

              "},{"location":"data/raster/gdal/#example","title":"Example","text":"

              Suppose you have 3 raster files with the following paths:

              • /data/raster/charts/nitf/italy_2015.ntf
              • /data/raster/satellite/ecw/orthofoto_2014.ecw
              • /data/raster/satellite/landsat/mrsid/N-32-40_2000.sid

              They can be represented by this tree:

              /data\n \\---raster\n     +---charts\n     |   \\---nitf\n     |           italy_2015.ntf\n     |\n     \\---satellite\n         +---ecw\n         |       orthofoto_2014.ecw\n         |\n         \\---landsat\n             \\---mrsid\n                     N-32-40_2000.sid\n

              In order to support external footprints you should

              1. Create a /footprints (as an example) directory on disk
              2. Set the FOOTPRINTS_DATA_DIR=/footprints variable/property.
              3. Replicate the rasters folder hierarchy inside the specified folder, using the full paths.
              4. Put the 3 WKT files in the proper locations:

              5. /footprints/data/raster/charts/nitf/italy_2015.wkt

              6. /footprints/data/raster/satellite/ecw/orthofoto_2014.wkt
              7. /footprints/data/raster/satellite/landsat/mrsid/N-32-40_2000.wkt

              Which can be represented by this tree:

              /footprints\n \\---data\n     \\---raster\n         +---charts\n         |   \\---nitf\n         |           italy_2015.wkt\n         |\n         \\---satellite\n             +---ecw\n             |       orthofoto_2014.wkt\n             |\n             \\---landsat\n                 \\---mrsid\n                         N-32-40_2000.wkt\n

              Such that, in the end, you will have the following folders hierarchy tree:

              +---data\n|   \\---raster\n|       +---charts\n|       |   \\---nitf\n|       |           italy_2015.ntf\n|       |\n|       \\---satellite\n|           +---ecw\n|           |       orthofoto_2014.ecw\n|           |\n|           \\---landsat\n|               \\---mrsid\n|                       N-32-40_2000.sid\n|\n\\---footprints\n    \\---data\n        \\---raster\n            +---charts\n            |   \\---nitf\n            |           italy_2015.wkt\n            |\n            \\---satellite\n                +---ecw\n                |       orthofoto_2014.wkt\n                |\n                \\---landsat\n                    \\---mrsid\n                            N-32-40_2000.wkt\n

              Note the parallel mirrored folder hierarchy, with the only differences being a /footprints prefix at the beginning of the path, and the change in suffix.

              "},{"location":"data/raster/geopkg/","title":"GeoPackage","text":"

              GeoPackage is an SQLite based standard format that is able to hold multiple vector and raster data layers in a single file.

              GeoPackage files can be used both as Vector Data Stores as well as Raster Data Stores (so that both kinds of layers can published).

              "},{"location":"data/raster/geopkg/#adding-a-geopackage-raster-mosaic-data-store","title":"Adding a GeoPackage Raster (Mosaic) Data Store","text":"

              By default, GeoPackage (mosaic) will be an option in the Raster Data Sources list when creating a new data store.

              GeoPackage (mosaic) in the list of raster data stores

              Configuring a GeoPackage (mosaic) data store

              Option Description

              Workspace Name of the workspace to contain the GeoPackage Mosaic store. This will also be the prefix of the raster layers created from the store.

              Data Source Name Name of the GeoPackage Mosaic Store as it will be known to GeoServer. This can be different from the filename. )

              Description A full free-form description of the GeoPackage Mosaic Store.

              Enabled If checked, it enables the store. If unchecked (disabled), no data in the GeoPackage Mosaic Store will be served from GeoServer.

              URL Location of the GeoPackage file. This can be an absolute path (such as file:C:\\Data\\landbase.gpkg) or a path relative to GeoServer's data directory (such as file:data/landbase.gpkg).

              When finished, click Save.

              "},{"location":"data/raster/geotiff/","title":"GeoTIFF","text":"

              A GeoTIFF is a georeferenced TIFF (Tagged Image File Format) file.

              "},{"location":"data/raster/geotiff/#adding-a-geotiff-data-store","title":"Adding a GeoTIFF data store","text":"

              By default, GeoTIFF will be an option in the Raster Data Sources list when creating a new data store.

              GeoTIFF in the list of raster data stores

              "},{"location":"data/raster/geotiff/#configuring-a-geotiff-data-store","title":"Configuring a GeoTIFF data store","text":"

              Configuring a GeoTIFF data store

              Option Description

              Workspace Name of the workspace to contain the GeoTIFF store. This will also be the prefix of the raster layer created from the store.

              Data Source Name Name of the GeoTIFF as it will be known to GeoServer. This can be different from the filename. The combination of the workspace name and this name will be the full layer name (ex: world:landbase)

              Description A full free-form description of the GeoTIFF store.

              Enabled If checked, it enables the store. If unchecked (disabled), no data in the GeoTIFF will be served from GeoServer.

              URL Location of the GeoTIFF file. This can be an absolute path (such as file:C:\\Data\\landbase.tif) or a path relative to GeoServer's data directory (such as file:data/landbase.tif).

              Note

              Notice that the GeoTiff plugin is able to handle internal/external overviews and internal/external masks.

              "},{"location":"data/raster/geotiff/#custom-crs-definition","title":"Custom CRS definition","text":"

              Creating an auxiliary .prj file that contains coordinate reference system information as described in the Custom CRS Definitions chapter will override internal CRS tags that are included in the original GeoTIFF file. This can be used to work-around problematic source files without making modifications to the file.

              "},{"location":"data/raster/imagepyramid/","title":"ImagePyramid","text":"

              Note

              GeoServer does not come built-in with support for Image Pyramid; it must be installed through an extension. Proceed to Installing the ImagePyramid extension for installation details.

              An image pyramid is several layers of an image rendered at various image sizes, to be shown at different zoom levels.

              "},{"location":"data/raster/imagepyramid/#imagepyramid_install","title":"Installing the ImagePyramid extension","text":"
              1. Visit the website download page, locate your release, and download: pyramid

                Warning

                Ensure to match plugin (example 2.24.2 above) version to the version of the GeoServer instance.

              2. Extract the contents of the archive into the WEB-INF/lib directory of the GeoServer installation.

              "},{"location":"data/raster/imagepyramid/#adding-an-imagepyramid-data-store","title":"Adding an ImagePyramid data store","text":"

              Once the extension is properly installed ImagePyramid will be an option in the Raster Data Sources list when creating a new data store.

              ImagePyramid in the list of raster data stores

              "},{"location":"data/raster/imagepyramid/#configuring-an-imagepyramid-data-store","title":"Configuring an ImagePyramid data store","text":"

              Configuring an ImagePyramid data store

              Option Description

              Workspace

              Data Source Name

              Description

              Enabled

              URL

              "},{"location":"data/raster/worldimage/","title":"WorldImage","text":"

              A world file is a plain text file used to georeference raster map images. This file (often with an extension of .jgw or .tfw) accompanies an associated image file (.jpg or .tif). Together, the world file and the corresponding image file is known as a WorldImage in GeoServer.

              "},{"location":"data/raster/worldimage/#adding-a-worldimage-data-store","title":"Adding a WorldImage data store","text":"

              By default, WorldImage will be an option in the Raster Data Sources list when creating a new data store.

              WorldImage in the list of raster data stores

              "},{"location":"data/raster/worldimage/#configuring-a-worldimage-data-store","title":"Configuring a WorldImage data store","text":"

              Configuring a WorldImage data store

              Option Description

              Workspace

              Data Source Name

              Description

              Enabled

              URL

              "},{"location":"data/raster/imagemosaic/","title":"ImageMosaic","text":"

              The ImageMosaic data store allows the creation of a mosaic from a number of georeferenced rasters.

              The mosaic operation creates a mosaic from two or more source images. This operation could be used to assemble a set of overlapping geospatially rectified images into a contiguous image. It could also be used to create a montage of photographs such as a panorama.

              The plugin can be used with GeoTIFFs, as well as rasters accompanied by a world file (.wld, .pgw for PNG files, .jgw for JPG files, etc.). In addition, if imageIO-ext GDAL extension is properly installed, the plugin can also serve all the formats supported by it such as MrSID, ECW, JPEG2000. It also supports NetCDF and GRIB.

              • ImageMosaic configuration
              • Using the ImageMosaic extension
              "},{"location":"data/raster/imagemosaic/configuration/","title":"ImageMosaic configuration","text":""},{"location":"data/raster/imagemosaic/configuration/#granules","title":"Granules","text":"

              Each individual image is commonly referred to as a granule. In recent releases of GeoServer the similarities requirements for the granules have been dropped significantly, including:

              • The granules do not need to share the same coordinate reference system (see the multi-CRS mosaic tutorial)
              • The granules can be in different color models, with an allowance of mixing gray, RGB, RGBA and indexed color granules (it is however not possible to mix colored granules with scientific data types like as float/double). In order to benefit of mixed color models JAI-Ext support must be enabled, see the JAI-EXT support documentation.

              In addition it is worth remarking on the fact that currently the ImageMosaic is able to handle raster data whose grid-to-world transformation is a scale and translate transformation, hence no rotation or skew.

              "},{"location":"data/raster/imagemosaic/configuration/#index-and-configuration-file-creation","title":"Index and configuration file creation","text":"

              When a new store is created, an index shapefile will be generated to associate each granule file with its bounding box. The index creation respects directory trees as well as single directories. All you need to do is point the store to the root of the hierarchy, and all images will be considered for inclusion in the ImageMosaic.

              The index will contain the enclosing polygon for each raster file (in an appropriate coordinate reference system) and the path to each of these files. The location attribute can be relative to the configuration folder or absolute. By default, the name of this attribute is location, but this can be changed in the main configuration file.

              If you already have these files generated, GeoServer will respect them and not generate a new index. By default, a shapefile is used for the index, but PostGIS, H2, and Oracle are also supported, with additional configuration steps.

              "},{"location":"data/raster/imagemosaic/configuration/#configuration-files","title":"Configuration files","text":"

              Within each store there are multiple configuration files that determine how the mosaic is rendered.

              Note

              The property file syntax uses a few reserved chars that need escaping in order to be used for keys or values. For example, the # character is used to comment out lines, in order to use it in values it needs to be escaped, like this: \\#. The same applies to the = character, which is used to separate the property name from its value: it should be specified as \\=. Finally, if there is a need to use the ` itself, it will have to be escaped as well:`.

              "},{"location":"data/raster/imagemosaic/configuration/#primary-configuration-file","title":"Primary configuration file","text":"

              The mosaic configuration file is the primary file used to store the configuration parameters that control the ImageMosaic plugin. When created by GeoServer it is by default called <directory>.properties, where <directory> is the name of the root directory of the store. (It is not related to the store name in GeoServer.) It can have other names, as long as it does not conflict with other files such as datastore.properties or indexer.properties. This file usually does not require manual editing.

              The table below describes the various elements in this configuration file.

              Parameter Mandatory? Description

              Levels Y Represents the resolutions for the various levels of the granules of this mosaic.

              Heterogeneous N Sets whether the image files are heterogeneous. Default is false.

              AbsolutePath N Controls whether or not the path stored inside the location attribute represents an absolute path or a path relative to the location of the shapefile index. Notice that a relative index ensures much more portability of the mosaic itself. Default value for this parameter is false, which means relative paths.

              Name N The name to be assigned to the index. If unspecified, the index name will usually match the name of the folder containing the mosaic.

              TypeName Y Featuretype name for this mosaic. Usually the name as Name.

              Caching N Boolean value to enable caching. When set to true, the ImageMosaic will try to save in memory the entire contents of the index to reduce loading/query time. Set to false for a large granule index and/or if new granules are to be ingested (for example, when the index is on a database and we interact directly with it). Default is false.

              ExpandToRGB N Boolean flag to force color expansion from index color model (paletted datasets) to component color model (RGB). Default is false.

              LocationAttribute Y The name of the attribute path in the shapefile index. Default is location.

              SuggestedSPI Y Suggested plugin for reading the image files.

              SuggestedFormat N Suggested GridFormat for reading the image files.

              Envelope2D N Envelope for the mosaic formatted as LLX,LLY URX,URY (notice the space between the lower left and upper right coordinate pairs).

              CheckAuxiliaryMetadata N This parameter allows to specify whether the ImageMosaic plugin should check for the presence of a GDAL aux.xml file beside each granule file. For most common use cases, you don't need to set or specify this parameter. Being disabled by Default, ImageMosaic won't look for an ancillary file for each granule being initialized in the GranuleCatalog. This avoid useless checks, especially when dealing with thousand of granules. You should set that parameter to true when you want to instruct the ImageMosaic to look for a GDAL generated aux.xml file containing PAM (Persistent Auxiliary Metadata) for each granule, to be attached to the Granule info (GranuleDescriptor). This is specially useful when you have setup a Dynamic ColorMap rendering transformation which dynamically set a color map based on the statistics collected into the granule's GDAL PAM being previously generated with a gdalinfo -stats parameter.

              LevelsNum Y Represents the number of reduced resolution layers that we currently have for the granules of this mosaic.

              A sample configuration file follows:

              Levels=0.4,0.4\nHeterogeneous=false\nAbsolutePath=false\nName=osm\nTypeName=osm\nCaching=false\nExpandToRGB=false\nLocationAttribute=location\nSuggestedSPI=it.geosolutions.imageioimpl.plugins.tiff.TIFFImageReaderSpi\nSuggestedFormat=org.geotools.gce.geotiff.GeoTiffFormat\nCheckAuxiliaryMetadata=false\nLevelsNum=1\n
              "},{"location":"data/raster/imagemosaic/configuration/#mosaic_datastore_properties","title":"datastore.properties","text":"

              By default the ImageMosaic index is specified by a shapefile, which is located at the root of the ImageMosaic directory, just like the primary configuration file.

              If needed, different storage can be used for the index --- like a spatial DBMS, which is the preferred solution when you wish to share the ImageMosaic itself in a cluster of GeoServer instances. In this case the user must supply GeoServer with the proper connection parameters, which can be specified by using a datastore.properties file placed at the root of the ImageMosaic directory.

              Note

              A shapefile is created automagically if it does not exist or if there is no datastore.properties file.

              Warning

              At the time of writing the following spatial DBMS have been tested successfully: Oracle, PostgreSQL, H2, SQLServer.

              +-----------------------+------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Parameter | Mandatory? | Description | +=======================+============+==================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================+ | StoreName | N | Can be used to refer to a GeoServer registered store, using a \"workspace:storeName\" syntax. When this is used, the no other connection parameters need to be provided. The SPI can still be provided to inform the mosaic of the resulting type of store (e.g., Oracle) in case specific behavior need to be enacted for it (e.g., in the case of Oracle the attributes are all uppercase and cannot be longer than 30 chars, the mosaic will respect the limits but the SPI parameter needs to be explicitly set to org.geotools.data.oracle.OracleNGDataStoreFactory as the actual store type is hidden when it reaches the mosaic code). Also, as a reminder, the code is picking up a Store reference, not a layer one, meaning that security restrictions that might have been applied to a layer exposing the feature type do not apply to the mosaic code (e.g., if a user has restrictions such as a spatial filter on said layer, it won't transfer to the mosaic, which needs to be secured separately) | +-----------------------+------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | SPI | Y | The DataStoreFactory used to connect to the index store: | | | | | | | | - PostGIS: org.geotools.data.postgis.PostgisNGDataStoreFactory | | | | - Oracle: org.geotools.data.oracle.OracleNGDataStoreFactory | | | | - H2: org.geotools.data.h2.H2DataStoreFactory | | | | - SQLServer: org.geotools.data.sqlserver.SQLServerDataStoreFactory | | | | | | | | JNDI can also be used with any of these stores. If JNDI is used, the DataStoreFactory name will differ from the above. | +-----------------------+------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Connection parameters | Y | The connection parameters used by the specified SPI. The list of these connection parameters can be found in the GeoTools documentation on the relevant store: | | | | | | | | - PostGIS | | | | - Oracle | | | | - H2 | | | | - SQLServer | | | | | | | | If JNDI is used, the connection parameters will include jndiReferenceName instead of host, port, etc. Note that for any connection parameters that include a space (such as loose bbox), the space must be escaped by preceding it with a backslash (loose\\ bbox). | +-----------------------+------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+

              Here is a sample datastore.properties file for a PostGIS index:

              SPI=org.geotools.data.postgis.PostgisNGDataStoreFactory\nhost=localhost\nport=5432\ndatabase=osm\nschema=public\nuser=user\npasswd=password\nLoose\\ bbox=true\nEstimated\\ extends=false\nvalidate\\ connections=true\nConnection\\ timeout=10\npreparedStatements=true\n

              Here is a sample datastore.properties file for a PostGIS index via JNDI:

              SPI=org.geotools.data.postgis.PostgisNGJNDIDataStoreFactory\n#String\n# JNDI data source\n# Default \"java:comp/env/\"+\"jdbc/mydatabase\"\njndiReferenceName=\n\n#Boolean\n# perform only primary filter on bbox\n# Default Boolean.TRUE\nLoose\\ bbox=true\n\n#Boolean\n# use prepared statements\n#Default Boolean.FALSE\npreparedStatements=false\n
              "},{"location":"data/raster/imagemosaic/configuration/#indexerproperties","title":"indexer.properties","text":"

              In addition to the required envelope and location attributes, the schema for the index store may expose other custom attributes which can be used later for filtering the ImageMosaic granules on the fly during a WMS or WCS request or to diver WMS and WCS dimensions like TIME, ELEVATION and so on. This is configured by the indexer.properties file:

              Parameter Mandatory? Description

              Schema Y A comma-separated sequence describing the mapping between attribute and data type.

              PropertyCollectors Y A comma-separated list of PropertyCollectors. Each entry in the list includes the extractor class, the file name (within square brackets [ ] and not including the .properties suffix) containing the regular expression needed to extract the attribute value from the granule file name, and the attribute name (within parentheses ( )). The instance of the extractor class also indicates the type of object computed by the specific collector, so a TimestampFileNameExtractorSPI will return Timestamps while a DoubleFileNameExtractorSPI will return Double numbers.

              TimeAttribute N Specifies the name of the time-variant attribute.

              ElevationAttribute N Specifies the name of the elevation attribute.

              AuxiliaryFile N Path to an auxiliary file to be used for internal purposes (For example: when dealing with NetCDF granules, it refers to the NetCDF XML ancillary file.)

              AbsolutePath N Controls whether or not the path stored inside the location attribute represents an absolute path or a path relative to the location of the shapefile index. Notice that a relative index ensures better portability of the mosaic itself. Default value for this parameter is false, which means relative paths.

              Caching N Boolean value to enable caching. When set to true, the ImageMosaic will try to save in memory the entire contents of the index to reduce loading/query time. Set to false for a large granule index and/or if new granules are to be ingested (for example, when the index is on a database and we interact directly with it). Default is false.

              CanBeEmpty N Boolean flag used for configuring empty mosaics. When enabled the ImageMosaic will not throw an exception caused by the absence of any coverage. By default it is set to false.

              Envelope2D N Envelope for the mosaic formatted as LLX,LLY URX,URY (notice the space between the lower left and upper right coordinate pairs).

              ExpandToRGB N Boolean flag to force color expansion from index color model (paletted datasets) to component color model (RGB). Default is false.

              IndexingDirectories N Comma separated values list of paths referring to directories containing granules to be indexed. If unspecified, the IndexingDirectory will be the mosaic configuration directory. This parameter allows configuration of a mosaic in a folder which contains only configuration files, while the granules to be indexed are stored somewhere else.

              Name N The name to be assigned to the index. If unspecified, the index name will usually match the name of the folder containing the mosaic.

              NoData N Specifies the NoData for the mosaic. (This might be useful, as an instance, when imposing the Envelope2D. At time of ImageMosaic's initialization, a small 5x5 pixels sample read is performed by ImageMosaic on the Envelope's corner in order to retrieve granule's metadata and properties, as nodata. If Envelope2D is forced in configuration, there might be the case that this sample read will not involve any actual granule so a default noData will be set which may be different with respect to what is actually stored on granules. Specifying the desired NoData property in indexer will solve this type of issue).

              CoverageNameCollectorSPI N As described in the previous row, the Name parameter allows specification of the coverage name to be exposed by the ImageMosaic. An ImageMosaic of NetCDFs instead exposes a coverage for each supported variable found in the NetCDF, using the variable's name as the coverage name (for instance, air_temperature, wind_speed, etc.) The optional CoverageNameCollectorSPI property allows specification of a CoverageNameCollector plugin to be used to instruct the ImageMosaic on how to setup different coverageNames for granules. It should contains the full name of the implementing class plus an optional set of semicolon-separated keyValue pairs prefixed by \":\". See below for an example.

              Recursive N Boolean flag used at indexing time. When set to true, the indexer will look for granules by scanning any subdirectory contained in the indexing directory. If false, only the main folder will be analyzed. Default is true.

              UseExistingSchema N Boolean flag used for enabling/disabling the use of existing schemas. When enabled, the ImageMosaic will start indexing granules using the existing database schema (from datastore.properties) instead of populating it. This is useful when you already have a database with a valid mosaic schema (the_geom, location and other attributes, take a look at gdalindex) or when you do not want to rename the images to add times and dimensions (you should simply add them to the table, to AdditionalDomainAttributes and to PropertyCollectors). Default is false.

              Wildcard N Wildcard used to specify which files should be scanned by the indexer. (For instance: \"*.tif\"). Currently, logic operators and lists aren't supported, so this field is limited to a single wildcard element with no support for AND/OR operators combinations.

              WrapStore N By default, Postgresql identifiers can't be longer than 63 chars. Longer names will be truncated to that fixed length. When dealing with multidimensional datasets (for instance: NetCDFs, GRIBs) each variable (NetCDF) or parameter (GRIB) is indexed into a table with the same name. Therefore an atmosphere-absorption-optical-thickness-due-to-particulate-organic-matter-ambient-aerosol-particles NetCDF CF variable will be associated to a table with the same name. Postgresql will truncate that to atmosphere-absorption-optical-thickness-due-to-particulate-orga breaking the one-to-one mapping and therefore breaking the proper functioning. Setting the WrapStore flag to true will establish a hidden mapping between full long names and truncated table names to support proper working.

              MosaicCRS N The \"native\" CRS of the mosaic, that is, the one in which footprints are collected. Useful when dealing with granules in multiple CRSs (see tutorial)

              AdditionalDomainAttributes N Comma separate list of custom dimensions to be exposed. Each custom dimension declaration can be a simple attribute name from the schema, e.g., runtime, a mapping from dimension name to attribute name, e.g. time2(runtime), or a mapping from a range dimension name to two attributes, e.g., timerange(timeStart,timeEnd)

              PropertySelection N Boolean value to enable/disable selection of properties from the mosaic index. Default is false. When enabled, the ImageMosaic will try to load in memory only the properties needed to perform mosaicking. A typical use case is using a STAC API as a mosaic index, a STAC item typically contains many complex properties, and the API might be remote, reducing the payload improves both query time and memory usage.

              Here is a sample indexer.properties file:

              Schema=*the_geom:Polygon,location:String,ingestion:java.util.Date,elevation:Double\nPropertyCollectors=TimestampFileNameExtractorSPI[timeregex](ingestion),DoubleFileNameExtractorSPI[elevationregex](elevation)\nTimeAttribute=ingestion\nElevationAttribute=elevation\nCaching=false\nAbsolutePath=false\n

              An example of optional CoverageNameCollectorSPI could be:

              CoverageNameCollectorSPI=org.geotools.gce.imagemosaic.namecollector.FileNameRegexNameCollectorSPI:regex=^([a-zA-Z0-9]+)\n

              This defines a regex-based name collector which extracts the coverage name from the prefix of the file name, so that an ImageMosaic with temperature_2015.tif, temperature_2016.tif, pressure_2015.tif, pressure_2016.tif will put temperature granules on a temperature coverage and pressure granules on a pressure coverage.

              Note

              The extraction works from the match of the full regular expression, if there are no capturing groups. If there are capturing groups instead, the match will be the concatenation of the text matched by all the capturing groups. This can be used to simplify the regular expression, for example, in order to match a string surrounded by underscores, regex=.*_(\\\\w+)_.* can be used instead of the more complex regex=(?<\\=_)\\\\w+(?\\=_) (using non capturing groups instead).

              "},{"location":"data/raster/imagemosaic/configuration/#property-collectors","title":"Property collectors","text":"

              The following table enumerates the available property collectors

              Collector SPI name Description

              ByteFileNameExtractorSPI DoubleFileNameExtractorSPI FloatFileNameExtractorSPI IntegerFileNameExtractorSPI LongFileNameExtractorSPI ShortFileNameExtractorSPI Extracts an number from the file name using a regular expression specified in a sidecar file, casting it to the desired type based on the SPI name (e..g, DoubleFileNameExtractorSPI extracts double precision floating points, IntegerFileNameExtractorSPI extracts 32 bit integers)

              TimestampFileNameExtractorSPI Extracts a timestamp from the filename using a regular expression specified in a sidecar file

              StringFileNameExtractorSPI Extracts a string from the filename using a regular expression specified in a sidecar file

              CurrentDateExtractorSPI Returns the current date and time (useful to track ingestion times in a mosaic)

              FSDateExtractorSPI Returns the creation date of the file being harvested

              DateExtractorSPI Returns the date found in tiff file header \"DateTime\" (code 306)

              ResolutionExtractorSPI ResolutionXExtractorSPI ResolutionYExtractorSPI Returns the native resolution of the raster being harvested. ResolutionExtractorSPI and ResolutionXExtractorSPI return the x resolution of the raster, ResolutionYExtractorSPI returns the resolution on the Y axis instead

              CRSExtractorSPI Returns the code of the raster coordinate reference system, as a string, e.g. \"EPSG:4326\"

              The PropertyCollectors parameter in the example above indicates two additional .properties files used to populate the ingestion and elevation attributes:

              timeregex.properties:

              regex=[0-9]{8}T[0-9]{9}Z(\\?!.*[0-9]{8}T[0-9]{9}Z.*)\n

              The above is a property file containing a regex used to extract Date and Time represented in ISO-8601 as part of the filename. (Note the T char between digits for date and digits for time, as per ISO-8601)

              In case of custom format datetimes in filename, an additional format element should be added after the regex, preceded by a comma, defining the custom representation.

              | Example: | Temperature_2017111319.tif | an hourly Temperature file with datetime = November, 13 2017 at 7:00 PM (the last 2 digits = 19) | | In that case, the timeregex.properties file should be like this:

              regex=.([0-9]{10}).,format=yyyyMMddHH

              In case of reduced precision of temporal information, where there is the need to get the higher time included in that reduced value, an additional ,useHighTime=true element should be added.

              | Example: | Temperature_2017111319.tif | an hourly Temperature file with datetime = November, 13 2017 at 19h 00m 00s 000ms | You want to get the max time included in that reduced precision, which is November, 13 2017 at 19h 59m 59s 999ms | | In that case, the timeregex.properties file should be like this:

              regex=.([0-9]{10}).,format=yyyyMMddHH,useHighTime=true

              In case the temporal information is spread along the whole file path, an additional ,fullPath=true element should be added.

              | Example: | /data/20120202/Temperature.T1800.tif | an hourly Temperature tif file with Year,Month and Day specified in the parent folder (20120202) and time value embedded in the name (Temperature.T1800.tif) | | In that case, the timeregex.properties file should be like this:

              regex=(?:/)(\\d{8})(?:/)(?:Temperature.)(T\\d{4})(?:.tif),fullPath=true

              elevationregex.properties:

              regex=(?<=_)(\\\\d{4}\\\\.\\\\d{3})(?=_)\n
              "},{"location":"data/raster/imagemosaic/configuration/#store-parameters","title":"Store parameters","text":"

              By default, ImageMosaic will be an option in the Raster Data Sources list when creating a new data store.

              ImageMosaic in the list of raster data stores

              Configuring an ImageMosaic data store

              Option Description

              Workspace Workspace for the store

              Data Source Name Name of the store

              Description Description of the store

              Enabled Determines whether the store is enabled. If unchecked, all layers in the store will be disabled.

              URL The location of the store. Can be a local directory.

              "},{"location":"data/raster/imagemosaic/configuration/#coverage-parameters","title":"Coverage parameters","text":"

              Creation of the store is the first step to getting an ImageMosaic published in GeoServer. Most of the configuration is done when publishing the resulting coverage (layer).

              The Coverage Editor gives users the possibility to set a few control parameters to further control the mosaic creation process.

              Coverage parameters

              The parameters are as follows:

              +---------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Parameter | Description | +=================================+===================================================================================================================================================================================================================================================================================================================================================================================================================+ | Accurate resolution computation | Boolean value. If true, computes the resolution of the granules in 9 points: the corners of the requested area and the middle points, taking the better one. This will provide better results for cases where there is a lot more deformation on a subregion (top/bottom/sides) of the requested bounding box with respect to others. If false, computes the resolution using a basic affine scale transform. | +---------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | AllowMultithreading | If true, enables multithreaded tile loading. This allows performing parallelized loading of the granules that compose the mosaic. Setting this to true makes sense only if you set USE_JAI_IMAGEREAD to false at the same time to force immediate loading of data into memory. | +---------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | BackgroundValues | Sets the value of the mosaic background. Depending on the nature of the mosaic it is wise to set a value for the \"nodata\" area (usually -9999). This value is repeated on all the mosaic bands. | +---------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Filter | Sets the default mosaic filter. It should be a valid ECQL query to be used by default if no cql_filter is specified (instead of Filter.INCLUDE). This filter will be applied against the mosaic index, and may include any attributes exposed by the index store. If the cql_filter is specified in the request it will be overridden. | | | | | | ::: note | | | ::: title | | | Note | | | ::: | | | | | | Do not use this filter to change time or elevation dimensions defaults. It will be added as AND condition with CURRENT for \"time\" and LOWER for \"elevation\". | | | ::: | +---------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | FootprintBehavior | Sets the behavior of the regions of a granule that are outside of the granule footprint. Can be None (ignore the footprint), Cut (remove regions outside the footprint from the image and don't add an alpha channel), or Transparent (make regions outside the footprint completely transparent, and add an alpha channel if one is not already present). Defaults to None. | +---------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | InputTransparentColor | Sets the transparent color of the granules prior to processing by the ImageMosaic plugin, in order to control how they are superimposed. When GeoServer composes the granules to satisfy a user request, some can overlap others; setting this parameter with an appropriate color avoids the overlap of \"nodata\" areas between granules. See below for an example: | | | | | | | | | InputTransparentColor parameter not configured | | | | | | | | | InputTransparentColor parameter configured | +---------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | MaxAllowedTiles | Sets the maximum number of tiles that can be loaded simultaneously for a request. For large mosaics, this parameter should be set to avoid saturating the server by loading too many granules simultaneously. | +---------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | MergeBehavior | The method used to handle overlapping granules during the mosaic operation. Can be FLAT (only the topmost granule is visible in the case of an overlap) or STACK (a band-stacking merge is applied to the overlapping granules). Default is FLAT. | +---------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | OutputTransparentColor | Set the transparent color for the mosaic. This parameter make sense for RGB or paletted mosaics, but not for a DEM or MetOc data. See below for an example: | | | | | | | | | OutputTransparentColor parameter configured with \"no color\" | | | | | | | | | OutputTransparentColor parameter configured with \"nodata\" color | +---------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | SORTING | Controls the order in which the granules are passed to the mosaic operation. Only useful if MergeBehavior is set to FLAT. Should be the name of an attribute in the index file, followed by a space, followed by A for ascending, or D for descending. For example: sortattr D. | +---------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | SUGGESTED_TILE_SIZE | Controls the tile size of the input granules as well as the tile size of the output mosaic. It consists of two positive integers separated by a comma. Default is 512,512. If your data is properly tiled, you might want to set this parameter to blank to avoid unnecessarily reformatting when reading. | +---------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | USE_JAI_IMAGEREAD | Controls the low-level mechanism used to read the granules. If set to true, GeoServer will use the JAI ImageRead operation and its deferred loading mechanism. If set to false, GeoServer will perform direct ImageIO read calls, which will result in immediate loading. | | | | | | ::: note | | | ::: title | | | Note | | | ::: | | | | | | Deferred loading consumes less memory since it uses a streaming approach to only load into memory the data immediately needed for processing, but may cause problems under heavy load since it keeps the granule files open for a long time. | | | | | | Immediate loading consumes more memory since it loads the requested mosaic into memory all at once, but usually performs faster and prevents the \"too many files open\" error conditions that can occur with deferred loading. | | | ::: | +---------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+

              Continue on with the ImageMosaic tutorial to learn more and see examples.

              "},{"location":"data/raster/imagemosaic/tutorial/","title":"Using the ImageMosaic extension","text":"

              This tutorial will show you how to configure and publish an ImageMosaic store and coverage, followed by some configuration examples.

              "},{"location":"data/raster/imagemosaic/tutorial/#configuring-a-coverage-in-geoserver","title":"Configuring a coverage in GeoServer","text":"

              This is a process very similar to creating a featuretype. More specifically, one has to perform the steps highlighted in the sections below:

              "},{"location":"data/raster/imagemosaic/tutorial/#create-a-new-store","title":"Create a new store","text":"
              1. Go to Data Panel \u2192 Stores and click Add new Store.

              2. Select ImageMosaic under Raster Data Source:

                ImageMosaic in the list of raster data stores

              3. In order to create a new mosaic it is necessary to choose a workspace and store name in the Basic Store Info section, as well as a URL in the Connection Parameters section. Valid URLs include:

                • The absolute path to the shapefile index, or a directory containing the shapefile index.
                • The absolute path to the configuration file (\\*.properties````) or a directory containing the configuration file. If ````datastore.properties```` and ````indexer.properties` exist, they should be in the same directory as this configuration file.
                • The absolute path of a directory where the files you want to mosaic reside. In this case GeoServer automatically creates the needed mosaic files (.dbf, .prj, .properties, .shp and .shx) by inspecting the data present in the given directory and any subdirectories.
              4. Click Save:

                ![](images/imagemosaicconfigure.png)\n*Configuring an ImageMosaic data store*\n
              "},{"location":"data/raster/imagemosaic/tutorial/#create-a-new-coverage","title":"Create a new coverage","text":"
              1. Navigate to Data Panel --> Layers and click Add a new resource.

              2. Choose the name of the store you just created:

                ![](images/vito_newlayerchoser.png)\n*Layer Chooser*\n
              3. Click the layer you wish to configure and you will be presented with the Coverage Editor:

                ![](images/vito_coverageeditor.png)\n*Coverage Editor*\n
              4. Make sure there is a value for Native SRS, then click the Submit button. If the Native CRS is UNKNOWN, you must declare the SRS in the Declared SRS field.

              5. Click Save.

              6. Use the Layer Preview to view the mosaic.

              Warning

              If the created layer appears to be all black, it may be that GeoServer has not found any acceptable granules in the provided index. It is also possible that the shapefile index is empty (no granules were found in the provided directory) or it might be that the granules\\' paths in the shapefile index are not correct, which could happen if an existing index (using absolute paths) is moved to another place. If the shapefile index paths are not correct, then the DBF file can be opened and fixed with an editor. Alternately, you can delete the index and let GeoServer recreate it from the root directory.

              "},{"location":"data/raster/imagemosaic/tutorial/#configuration-examples","title":"Configuration examples","text":"

              Below are a few examples of mosaic configurations to demonstrate how we can make use of the ImageMosaic parameters.

              "},{"location":"data/raster/imagemosaic/tutorial/#dembathymetry","title":"DEM/Bathymetry","text":"

              Such a mosaic can be used to serve large amounts of data representing altitude or depth and therefore does not specify colors directly (it needs an SLD to generate pictures). In our case, we have a DEM dataset which consists of a set of raw GeoTIFF files.

              The first operation is to create the CoverageStore specifying, for example, the path of the shapefile in the URL field.

              Inside the Coverage Editor Publishing tab, you can specify the dem default style in order to represent the visualization style of the mosaic. The following is an example style:

              <?xml version=\"1.0\" encoding=\"ISO-8859-1\"?>\n<StyledLayerDescriptor version=\"1.0.0\"\n  xmlns=\"http://www.opengis.net/sld\" xmlns:ogc=\"http://www.opengis.net/ogc\"\n  xmlns:xlink=\"http://www.w3.org/1999/xlink\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\"\n  xsi:schemaLocation=\"http://www.opengis.net/sld  http://schemas.opengis.net/sld/1.0.0/StyledLayerDescriptor.xsd\">\n  <NamedLayer>\n    <Name>gtopo</Name>\n    <UserStyle>\n      <Name>dem</Name>\n      <Title>Simple DEM style</Title>\n      <Abstract>Classic elevation color progression</Abstract>\n      <FeatureTypeStyle>\n        <Rule>\n          <RasterSymbolizer>\n            <Opacity>1.0</Opacity>\n            <ColorMap>\n              <ColorMapEntry color=\"#000000\" quantity=\"-9999\" label=\"nodata\" opacity=\"1.0\" />\n              <ColorMapEntry color=\"#AAFFAA\" quantity=\"0\" label=\"values\" />\n              <ColorMapEntry color=\"#00FF00\" quantity=\"1000\" label=\"values\" />\n              <ColorMapEntry color=\"#FFFF00\" quantity=\"1200\" label=\"values\" />\n              <ColorMapEntry color=\"#FF7F00\" quantity=\"1400\" label=\"values\" />\n              <ColorMapEntry color=\"#BF7F3F\" quantity=\"1600\" label=\"values\" />\n              <ColorMapEntry color=\"#000000\" quantity=\"2000\" label=\"values\" />\n            </ColorMap>\n          </RasterSymbolizer>\n        </Rule>\n      </FeatureTypeStyle>\n    </UserStyle>\n  </NamedLayer>\n</StyledLayerDescriptor>\n

              In this way you have a clear distinction between the different intervals of the dataset that compose the mosaic, like the background and the \\\"nodata\\\" area.

              ![](images/vito_config_1.png)\n

              Note

              The \\\"nodata\\\" on the sample mosaic is -9999. The default background value is for mosaics is 0.0.

              The result is the following:

              ![](images/vito_1.png)\n*Basic configuration*\n

              By setting the other configuration parameters appropriately, it is possible to improve both the appearance of the mosaic as well as its performance. For instance, we could:

              • Make the \\\"nodata\\\" areas transparent and coherent with the real data. To achieve this we need to change the opacity of the \\\"nodata\\\" ColorMapEntry in the dem style to 0.0 and set the BackgroundValues parameter to -9999 so that empty areas will be filled with this value. The result is as follows:

                ![](images/vito_2.png)\n*Advanced configuration*\n
              • Allow multithreaded granules loading. By setting the AllowMultiThreading parameter to true, GeoServer will load the granules in parallel using multiple threads with a increase in performance on some architectures.

              The configuration parameters are as follows:

              Parameter Value

              MaxAllowedTiles 2147483647

              BackgroundValues -9999

              OutputTransparentColor \\\"no color\\\"

              InputTransparentColor \\\"no color\\\"

              AllowMultiThreading True

              USE_JAI_IMAGEREAD True

              SUGGESTED_TILE_SIZE 512,512

              "},{"location":"data/raster/imagemosaic/tutorial/#aerial-imagery","title":"Aerial imagery","text":"

              In this example we are going to create a mosaic that will serve aerial imagery, specifically RGB GeoTIFFs. Because this is visual data, in the Coverage Editor you can use the basic raster style, which is just a stub SLD to instruct the GeoServer raster renderer to not do anything particular in terms of color management:

              <?xml version=\"1.0\" encoding=\"ISO-8859-1\"?>\n<StyledLayerDescriptor version=\"1.0.0\"\n  xmlns=\"http://www.opengis.net/sld\" xmlns:ogc=\"http://www.opengis.net/ogc\"\n  xmlns:xlink=\"http://www.w3.org/1999/xlink\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\"\n  xsi:schemaLocation=\"http://www.opengis.net/sld  http://schemas.opengis.net/sld/1.0.0/StyledLayerDescriptor.xsd\">\n  <NamedLayer>\n    <Name>raster</Name>\n    <UserStyle>\n      <Name>raster</Name>\n      <Title>Raster</Title>\n      <Abstract>A sample style for rasters, good for displaying imagery   </Abstract>\n      <FeatureTypeStyle>\n        <FeatureTypeName>Feature</FeatureTypeName>\n        <Rule>\n          <RasterSymbolizer>\n            <Opacity>1.0</Opacity>\n          </RasterSymbolizer>\n        </Rule>\n      </FeatureTypeStyle>\n    </UserStyle>\n  </NamedLayer>\n</StyledLayerDescriptor>\n

              The result is the following:

              ![](images/prato_1.png)\n*Basic configuration*\n

              Note

              Those ugly black areas are the result of applying the default mosaic parameters to a mosaic that does not entirely cover its bounding box. The areas within the BBOX that are not covered with data will default to a value of 0 on each band. Since this mosaic is RGB we can simply set the OutputTransparentColor to 0,0,0 in order to get transparent fills for the BBOX.

              The various parameters can be set as follows:

              Parameter Value

              MaxAllowedTiles 2147483647

              BackgroundValues (default)

              OutputTransparentColor #000000

              InputTransparentColor \\\"no color\\\"

              AllowMultiThreading True

              USE_JAI_IMAGEREAD True

              SUGGESTED_TILE_SIZE 512,512

              The result is the following:

              ![](images/prato_2.png)\n*Advanced configuration*\n
              "},{"location":"data/raster/imagemosaic/tutorial/#scanned-maps","title":"Scanned maps","text":"

              In this case we want to show how to serve scanned maps (mostly B&W images) via a GeoServer mosaic.

              In the Coverage Editor you can use the basic raster since there is no need to use any of the advanced RasterSymbolizer capabilities.

              The result is the following.

              ![](images/iacovella_1.png)\n*Basic configuration*\n

              This mosaic, formed by two single granules, shows a typical case where the \\\"nodata\\\" collar areas of the granules overlap, as shown in the picture above. In this case we can use the InputTransparentColor parameter to make the collar areas disappear during the superimposition process --- in this case, by using an InputTransparentColor of #FFFFFF.

              The final configuration parameters are the following:

              Parameter Value

              MaxAllowedTiles 2147483647

              BackgroundValues (default)

              OutputTransparentColor \\\"no color\\\"

              InputTransparentColor #FFFFFF

              AllowMultiThreading True

              USE_JAI_IMAGEREAD True

              SUGGESTED_TILE_SIZE 512,512

              This is the result:

              ![](images/iacovella_2.png)\n*Advanced configuration*\n
              "},{"location":"data/raster/imagemosaic/tutorial/#dynamic-imagery","title":"Dynamic imagery","text":"

              A mosaic need not be static. It can contain granules which change, are added or deleted. In this example, we will create a mosaic that changes over time.

              1. Create a mosaic in the standard way. (The specific configuration isn\\'t important.)
              ![](images/tutorial_dynamic1.png)\n*This mosaic contains 5 granules. Note that ``InputTransparentColor`` is set to ``#FFFFFF`` here.*\n

              To add new granules, the index that was created when the mosaic was originally created needs to be regenerated. There are two ways to do this:

              • Manually through the file system
              • Through the REST interface

              To update an ImageMosaic through the file system:

              1. Update the contents of the mosaic by copying the new files into place. (Subdirectories are acceptable.)
              2. Delete the index files. These files are contained in the top level directory containing the mosaic files and include (but are not limited to) the following:
                • `\\<mosaic_name>.dbf`
                • `\\<mosaic_name>.fix`
                • `\\<mosaic_name>.prj`
                • `\\<mosaic_name>.properties`
                • `\\<mosaic_name>.shp`
                • `\\<mosaic_name>.shx`
              3. (Optional but recommended) Edit the layer definition in GeoServer, making to sure to update the bounding box information (if changed).
              4. Save the layer. The index will be recreated.
              ![](images/tutorial_dynamic2.png)\n*This mosaic contains 9 granules*\n

              Note

              Please see the REST section for information on Uploading a new image mosaic.

              "},{"location":"data/raster/imagemosaic/tutorial/#multi-crs-mosaic","title":"Multi-resolution imagery with reprojection","text":"

              As a general rule, we want to have the highest resolution granules shown \\\"on top\\\", with the lower-resolution granules filling in the gaps as necessary.

              In this example, we will serve up overlapping granules that have varying resolutions. In addition, we will mix resolutions, such that the higher resolution granule is reprojected to match the resolution of the lower resolution granules.

              1. In the Coverage Editor, use the basic raster style.

              2. Create the mosaic in GeoServer.

              3. One important configuration setting is the SORTING parameter of the layer. In order to see the highest resolution imagery on top (the typical case), it must be set to resolution A. (For the case of lowest resolution on top, use resolution D .)

              4. Make any other configuration changes.

              5. Also, in order to allow for multiple CRSs in a single mosaic, an `indexer.properties` file will need to be created. Use the following :

                GranuleAcceptors=org.geotools.gce.imagemosaic.acceptors.HeterogeneousCRSAcceptorFactory\nGranuleHandler=org.geotools.gce.imagemosaic.granulehandler.ReprojectingGranuleHandlerFactory\nHeterogeneousCRS=true\nMosaicCRS=EPSG\\:4326\nPropertyCollectors=CRSExtractorSPI(crs),ResolutionExtractorSPI(resolution)\nSchema=*the_geom:Polygon,location:String,crs:String,resolution:String\n

                The MosaicCRS property is not mandatory, but it\\'s a good idea to set a predictable target CRS that all granule footprints can be reprojected into, otherwise the mosaic machinery will use the CRS of the first indexed granule.

              6. Save this file in the root of the mosaic directory (along with the index files). The result is the following:

                ![](images/tutorial_reproj_artifact.png)\n*Closeup of granule overlap (high resolution granule on right)*\n
              7. To remove the reprojection artifact (shown in the above as a black area) edit the layer configuration to set InputTransparentColor to #000000.

                ![](images/tutorial_reproj_noartifact.png)\n*Closeup of granule overlap (high resolution granule on right)*\n
              "},{"location":"data/raster/imagemosaic/tutorial/#referring-to-a-datastore-configured-in-geoserver","title":"Referring to a datastore configured in GeoServer","text":"

              It is possible to make the mosaic refer to an existing data store. The ``datastore.properties`` file in this case will contain only one or two properties, referring to the store to be used via the StoreName property. For simple cases, e.g., a PostGIS store, the following will be sufficient:

              StoreName=workspace:storename\n

              For Oracle or H2, it\\'s best to also specify the SPI in order to inform the mosaic that it needs to work around specific limitations of the storage (e.g., forced uppercase attribute usage, limitation in attribute name length and the like):

              StoreName=workspace:storename\nSPI=org.geotools.data.oracle.OracleNGDataStoreFactory\n

              The above will be sufficient in case the image mosaic can create the index table and perform normal indexing, using the directory name as the table name. In case a specific table name needs to be used, add an ``indexer.properties`` specifying the TypeName property, e.g.:

              TypeName=myMosaicTypeName

              In case the index \\\"table\\\" already exists instead, then a ``indexer.properties`` file will be required, with the following contents:

              UseExistingSchema=true\nTypeName=nameOfTheFeatureTypeContainingTheIndex\nAbsolutePath=true\n

              The above assumes location attribute provides absolute paths to the mosaic granules, instead of paths relative to the mosaic configuration files directory.

              "},{"location":"data/vector/","title":"Vector data","text":"

              This section discusses the vector data sources that GeoServer can access.

              The standard GeoServer installation supports the loading and serving of the following data formats:

              • Shapefile
              • Directory of spatial files
              • Java Properties
              • GeoPackage

              Other data sources are supplied as GeoServer extensions. Extensions are downloadable modules that add functionality to GeoServer. Extensions are available at the GeoServer download page.

              Warning

              The extension version must match the version of the GeoServer instance.

              • Pregeneralized Features
              "},{"location":"data/vector/directory/","title":"Directory of spatial files","text":"

              The directory store automates the process of loading multiple shapefiles into GeoServer. Loading a directory that contains multiple shapefiles will automatically add each shapefile to GeoServer.

              Note

              While GeoServer has robust support for the shapefile format, it is not the recommended format of choice in a production environment. Databases such as PostGIS are more suitable in production and offer better performance and scalability. See the section on Running in a production environment for more information.

              "},{"location":"data/vector/directory/#adding-a-directory","title":"Adding a directory","text":"

              To begin, navigate to Stores \u2192 Add a new store \u2192 Directory of spatial files.

              Adding a directory of spatial files as a store

              Option Description

              Workspace Name of the workspace to contain the store. This will also be the prefix of all of the layer names created from shapefiles in the store.

              Data Source Name Name of the store as known to GeoServer.

              Description Description of the directory store.

              Enabled Enables the store. If disabled, no data in any of the shapefiles will be served.

              URL Location of the directory. Can be an absolute path (such as file:C:\\Data\\shapefile_directory) or a path relative to the data directory (such as file:data/shapefile_directory.

              namespace Namespace to be associated with the store. This field is altered by changing the workspace name.

              skip scan Skip scan of alternative shapefile extensions (i.e. .SHP, .shp.XML, .CPG, ...) on Not-Windows systems. This can be useful when you have a directory containing several thousands of shapefiles. By Default, the shapefile plugin will look for all the shapefile extensions (.shp, .dbf, .shx, .prj, .qix, .fix, .shp.xml, .cpg). As soon as one of these is missing, it will do a search on the directory for the missing file, ignoring the case. This might be time consuming on directories with a huge number of files.

              When finished, click Save.

              "},{"location":"data/vector/directory/#configuring-shapefiles","title":"Configuring shapefiles","text":"

              All of the shapefiles contained in the directory store will be loaded as part of the directory store, but they will need to be individually configured as new layers they can be served by GeoServer. See the section on Layers for how to add and edit new layers.

              "},{"location":"data/vector/featurepregen/","title":"Pregeneralized Features","text":"

              Note

              GeoServer does not come built-in with support for Pregeneralized Features; it must be installed through an extension.

              "},{"location":"data/vector/featurepregen/#installing-the-pregeneralized-features-extension","title":"Installing the Pregeneralized Features extension","text":"
              1. Visit the website download page, locate your release, and download: feature-pregeneralized

                Warning

                Ensure to match plugin (example 2.24.2 above) version to the version of the GeoServer instance.

              2. Extract the contents of the archive into the WEB-INF/lib directory of the GeoServer installation.

              "},{"location":"data/vector/featurepregen/#adding-a-pregeneralized-features-data-store","title":"Adding a Pregeneralized Features data store","text":"

              If the extension is properly installed, Generalized Data Store will be listed as an option when creating a new data store.

              Generalized Data Store in the list of vector data stores

              "},{"location":"data/vector/featurepregen/#configuring-a-pregeneralized-features-data-store","title":"Configuring a Pregeneralized Features data store","text":"

              Configuring a Pregeneralized Features data store

              For a detailed description, look at the Tutorial</tutorials/feature-pregeneralized/feature-pregeneralized_tutorial>

              "},{"location":"data/vector/geopkg/","title":"GeoPackage","text":"

              GeoPackage is an SQLite based standard format that is able to hold multiple vector and raster data layers in a single file.

              GeoPackage files can be used both as Raster Data Stores as well as Vector Data Stores (so that both kinds of layers can published).

              "},{"location":"data/vector/geopkg/#adding-a-geopackage-vector-data-store","title":"Adding a GeoPackage Vector Data Store","text":"

              When the extension has been installed, GeoPackage will be an option in the Vector Data Sources list when creating a new data store.

              GeoPackage in the list of vector data stores

              Configuring a GeoPackage Vector data store

              Option Description

              database URI specifying geopackage file.

              user User to access database.

              passwd Password to access database.

              namespace Namespace to be associated with the database. This field is altered by changing the workspace name.

              max connections Maximum amount of open connections to the database.

              min connections Minimum number of pooled connections.

              fetch size Number of records read with each interaction with the database.

              Connection timeout Time (in seconds) the connection pool will wait before timing out.

              validate connections Checks the connection is alive before using it.

              When finished, click Save.

              "},{"location":"data/vector/properties/","title":"Java Properties","text":"

              The Properties data store provides access to one or more feature types (layers) stored in Java property files; these are plain text files stored on the local filesystem. The Properties data store was never intended to be shipped with GeoServer. It originated in a GeoTools tutorial, and later found widespread use by developers in automated tests that required a convenient store for small snippets of data. It slipped into GeoServer through the completeness of the packaging process, and was automatically detected and offered to users via the web interface. The Property data store has proved useful in tutorials and examples.

              • We do not recommend the use the Properties data store for large amounts of data, with either many features or large geometries. Its performance will be terrible.
              • For small data sets, such as collections of a few dozen points, you may find it to be satisfactory. For example, if you have a few points you wish to add as an extra layer, and no convenient database in which store them, the Properties data store provides a straightforward means of delivering them.
              • Changes to a property file are immediately reflected in GeoServer responses. There is no need to recreate the data store unless the first line of a property file is changed, or property files are added or removed.
              "},{"location":"data/vector/properties/#adding-a-properties-data-store","title":"Adding a Properties data store","text":"

              By default, Properties will be an option in the Vector Data Sources list when creating a new data store.

              Properties in the list of vector data stores

              "},{"location":"data/vector/properties/#configuring-a-properties-data-store","title":"Configuring a Properties data store","text":"

              Configuring a Properties data store

              Option Description

              Workspace Sets the namespace prefix of the feature types (layers) and their properties

              Data Source Name Unique identifier to distinguish this data store

              Description Optional text giving a verbose description of the data store

              Enabled Features will be delivered only if this option is checked

              directory Filesystem path to a directory containing one or more property files, for example /usr/local/geoserver/data/ex

              Every property file TYPENAME.properties in the designated directory is served as a feature type TYPENAME (the name of the file without the .properties), in the namespace of the data store.

              Before a feature type (layer) can be used, you must edit it to ensure that its bounding box and other metadata is configured.

              "},{"location":"data/vector/properties/#property-file-format","title":"Property file format","text":"

              The property file format is a subset of the Java properties format: a list of lines of the form KEY=VALUE.

              This example stations.properties defines four features of the feature type (layer) stations:

              _=id:Integer,code:String,name:String,location:Geometry:srid=4326\nstations.27=27|ALIC|Alice Springs|POINT(133.8855 -23.6701)\nstations.4=4|NORF|Norfolk Island|POINT(167.9388 -29.0434)\nstations.12=12|COCO|Cocos|POINT(96.8339 -12.1883)\nstations.31=31|ALBY|Albany|POINT(117.8102 -34.9502)\n
              • Blank lines are not permitted anywhere in the file.
              • The first line of the property file begins with _= and defines the type information required to interpret the following lines.
                • Comma separated values are of the form NAME:TYPE
                • Names are the property name that are used to encode the property in WFS responses.
                • Types include Integer, String, Float, and Geometry
                • Geometry can have an extra suffix :srid=XXXX that defines the Spatial Reference System by its numeric EPSG code. Note that geometries defined in this way are in longitude/latitude order.
              • Subsequent lines define features, one per line.
                • The key before the = is the feature ID (fid or gml:id in WFS responses). Each must be an NCName.
                • Feature data follows the = separated by vertical bars (|). The types of the data must match the declaration on the first line.
                • Leave a field empty if you want it to be null; in this case the property will be ignored.

              Note that in this example srid=4326 sets the spatial reference system (SRS) to EPSG:4326, which is by convention in longitude/latitude order when referred to in the short form. If you request these features in GML 3 you will see that GeoServer correctly translates the geometry to the URN form SRS urn:x-ogc:def:crs:EPSG:4326 in latitude/longitude form. See the WFS settings page for more on SRS axis order options.

              "},{"location":"data/vector/shapefile/","title":"Shapefile","text":"

              A shapefile is a popular geospatial vector data format.

              Note

              While GeoServer has robust support for the shapefile format, it is not the recommended format of choice in a production environment. Databases such as PostGIS are more suitable in production and offer better performance and scalability. See the section on Running in a production environment for more information.

              "},{"location":"data/vector/shapefile/#adding-a-shapefile","title":"Adding a shapefile","text":"

              A shapefile is actually a collection of files (with the extensions: .shp, .dbf, .shx, .prj, and sometimes others). All of these files need to be present in the same directory in order for GeoServer to accurately read them. As with all formats, adding a shapefile to GeoServer involves adding a new store to the existing Stores through the Web administration interface.

              Warning

              The .prj file, while not mandatory, is strongly recommended when working with GeoServer as it contains valuable projection info. GeoServer may not be able to load your shapefile without it!

              To begin, navigate to Stores \u2192 Add a new store \u2192 Shapefile.

              Adding a shapefile as a store

              Option Description

              Workspace Name of the workspace to contain the store. This will also be the prefix of the layer created from the store.

              Data Source Name Name of the shapefile as known to GeoServer. Can be different from the filename. The combination of the workspace name and this name will be the full layer name (ex: topp:states).

              Description Description of the shapefile/store.

              Enabled Enables the store. If unchecked, no data in the shapefile will be served.

              URL Location of the shapefile. Can be an absolute path (such as file:C:\\Data\\shapefile.shp) or a path relative to the data directory (such as file:data/shapefile.shp.

              namespace Namespace to be associated with the shapefile. This field is altered by changing the workspace name.

              create spatial index Enables the automatic creation of a spatial index.

              charset Character set used to decode strings from the .dbf file.

              memory mapped buffer Cache and reuse memory maps Enables the use of memory mapped I/O, improving caching of the file in memory. Turn off on Windows servers.

              When finished, click Save.

              "},{"location":"data/vector/shapefile/#configuring-a-shapefile-layer","title":"Configuring a shapefile layer","text":"

              Shapefiles contain exactly one layer, which needs to be added as a new layer before it will be able to be served by GeoServer. See the section on Layers for how to add and edit a new layer.

              "},{"location":"data/webadmin/","title":"Data settings","text":"

              This section describes how to manage load, manage, and publish data in the GeoServer web interface.

              It describes the core configuration data types that GeoServer uses to access and publish geospatial information. Each subsection describes the data type pages which provide add, view, edit, and delete capabilities.

              • Layer Preview
              • Workspaces
              • Stores
              • Layers
              • Layer Groups

              Note

              Information on the Styles pages can be found on the Styles page.

              "},{"location":"data/webadmin/layergroups/","title":"Layer Groups","text":"

              A layer group is a container in which layers and other layer groups can be organized in a hierarchical structure. A layer group can be referred to by a single name in WMS requests. This allows simpler requests, as one layer can be specified instead of multiple individual layers. A layer group also provides a consistent, fixed ordering of the layers it contains, and can specify alternate (non-default) styles for layers.

              Layer Groups page

              "},{"location":"data/webadmin/layergroups/#layer-group-modes","title":"Layer Group modes","text":"

              Layer group behaviour can be configured by setting its mode. There are 5 available values:

              • single: the layer group is exposed as a single layer with a name, acting as an alias for a list of layers. The layers are still showing up as top level entries in the WMS capabilities document (unless explicitly referred by a tree group).
              • opaque container: the layer group is exposed as a single layer with a name, acting as an alias for a list of layers. However, the layers and sub-groups contained in it won't show up in the capabilities document (unless explicitly referred by a tree group) and won't be available by themselves in WMS calls and in the WMS capabilities document, but only as part of the group.
              • named tree: the layer group can be referred to by one name, but also exposes its nested layers and groups in the capabilities document.
              • container tree: the layer group is exposed in the capabilities document, but does not have a name, making it impossible to render it on its own. This is called \"containing category\" in the WMS specification.
              • Earth Observation tree: a special type of group created to manage the WMS Earth Observation requirements. This group does not render its nested layers and groups, but only a \"preview layer\" called Root Layer. When this mode is chosen, a new field \"Root Layer\" will be exposed in the configuration UI.

              If a layer is included in any non single mode group, it will no longer be listed in the flat layer list. It will still be possible to include the layer in other layer groups.

              Layer Group Mode Named Contains Children Lists Children Details

              Single named no

              Opaque Container named yes no hides children

              Named Tree named yes lists children

              Container Tree yes lists children

              Earth Observation Tree named yes lists children has root layer

              "},{"location":"data/webadmin/layergroups/#edit-a-layer-group","title":"Edit a Layer Group","text":"

              To view or edit a layer group, click the layer group name. A layer group configuration page will be displayed. The initial fields allow you to configure the name, title, abstract, workspace, bounds, projection and mode of the layer group. To automatically set the bounding box, select the Generate Bounds button or the Generate Bounds From CRS button to use the bounds defined in the CRS (if available). You may also provide your own custom bounding box extents. To select an appropriate projection click the Find button.

              Note

              A layer group can contain layers with dissimilar bounds and projections. GeoServer automatically reprojects all layers to the projection of the layer group.

              The new Enabled checkbox, if disabled, will cause the layer group to just show up at configuration time (and in REST config), while the new Advertised checkbox, if unchecked, will make it to not be available in GetCapabilities request and in the layer preview. The behaviour of layer group regarding both checkboxes will not affect the behaviour of any of the layers being grouped, which will follow respectively that specified in the corresponding edit page.

              Layer Groups Edit page

              The table at the bottom of the page lists layers and groups contained within the current layer group. We refer to layers and layer groups as publishable elements. When a layer group is processed, the layers are rendered in the order provided, so the publishable elements at the bottom of list will be rendered last and will show on top of the other publishable elements.

              A publishable element can be positioned higher or lower on this list by clicking the green up or down arrows, respectively, or can be simply dragged in the target position. The layer at the top of the list is the first one to be painted, the layer below it will be painted second, and so on, the last layer will be painted on top of all others (this is the so called \"painter's model\").

              The Style column shows the style associated with each layer. To change the style associated with a layer, click the appropriate style link. A list of enabled styles will be displayed. Clicking on a style name reassigns the layer's style.

              Style editing for a layer within a layer group

              To remove a publishable element from the layer group, select its button in the Remove column. You will now be prompted to confirm or cancel this deletion.

              A layer can be added to the list by clicking the Add Layer... button at the top of the table. From the list of layers, select the layer to be added by clicking the layer name. The selected layer will be appended to the bottom of the publishable list.

              Dialog for adding a layer to a layer group

              A layer group can be added by clicking the Add Layer Group... button at the top of the table. From the list of layer groups, select the layer group to be added by clicking its name. The selected group will be appended to the bottom of the publishable list.

              Dialog for adding a layer group to a layer group

              A style group can be added by clicking the Add Style Group... button at the top of the table. From the list of styles, select the style group to be added by clicking its name. The selected style will be appended to the bottom of the publishable list.

              Dialog for adding a style group to a layer group

              You can view layer groups in the Layer Preview section of the web admin.

              Openlayers preview of the layer group \"tasmania\"

              Note

              By default, a layer group is queryable when at least a child layer is queryable. Uncheck \"Queryable\" box if you want to explicitly indicate that it is not queryable independently of how the child layers are configured.

              Security tab allows to set data access rules at layer group level.

              Note

              For more information on data access rules, please see the section on Data.

              To create/edit layergroup's data access rules simply check/uncheck checkboxes according to desired access mode and role. The Grant access to any role checkbox grant each role for each access mode.

              "},{"location":"data/webadmin/layergroups/#layer-group-styles","title":"Layer Group Styles","text":"

              The user can also define styles for a Layer Group. By style in this context we mean a different group definition that, while carrying the same meaning, uses a different set of styles, or even a different set of layers (e.g., night versus day style, or full versus simplified). The styles are named and can be thus be referenced through the styles parameter in the various WMS operations (GetMap, GetLegendGraphic, GetFeatureInfo), while the usual Layer Group configuration is kept as the default style.

              To add a new style on the Data tab scroll down until reaching the Layer Group Styles section and click on Add new.

              A form will pop up. Once defined a name (mandatory), it is possible to select the a list of layers and corresponding styles for the group style definition.

              In the above example the style uses the same list of layers, but different styles have been defined for the tiger:giant_polygon and tiger:poly_landmarks layers, respectively giant-polygon-2 and poly_landmarks-2. However the Layer Group Style might also contain a different list of layers comparing to the default one.

              Once a style has been defined it will appear in the GetCapabilities document and clients will be able to reference it in the styles parameter of GetMap, GetLegendGraphic and GetFeatureInfo operations, using the name defined at configuration time.

              The base configuration will be treated as the default Style of the Layer Group and used when either no style name is provided or the style name matches the default Layer Group Style name.

              Note

              The overall functionality is available only for Layer Group with mode SINGLE or OPAQUE. If a Layer Group is defined with another mode, the style name eventually present in a WMS operation will be ignored if not matching the default style name. Moreover the Layer Group Style section will not be available and the Style will not be advertised in the GetCapabilities response. This is due to the group internal structure appearing in the capabilities layer tree: only one list of sub-layers and sub-groups can be advertised.

              "},{"location":"data/webadmin/layergroups/#add-a-layer-group","title":"Add a Layer Group","text":"

              The buttons for adding and removing a layer group can be found at the top of the Layer Groups page.

              Buttons to add or remove a layer group

              To add a new layer group, select the \"Add a new layer group\" button. You will be prompted to name the layer group.

              New layer group dialog

              When finished, click Submit. You will be redirected to an empty layer group configuration page. Begin by adding layers by clicking the Add layer... button (described in the previous section). Once the layers are positioned accordingly, press Generate Bounds to automatically generate the bounding box and projection. You may also press the Generate Bounds From CRS button to use the CRS bounds (if available). Press Save to save the new layer group.

              New layer group configuration page

              "},{"location":"data/webadmin/layergroups/#remove-a-layer-group","title":"Remove a Layer Group","text":"

              To remove a layer group, select it by clicking the checkbox next to the layer group. Multiple layer groups can be selected, or all can be selected by clicking the checkbox in the header. Click the Remove selected layer group(s) link. You will be asked to confirm or cancel the deletion. Selecting OK removes the selected layer group(s).

              Removing a layer group

              "},{"location":"data/webadmin/layergroups/#layer-group-keywords","title":"Layer Group Keywords","text":"

              Is possible to associate a layer group with some keywords that will be used to assist catalog searching.

              Layer groups keywords editor

              Layer groups keywords will no be merged with contained layers keywords but keywords of a layer group should be logically inherited by contained layers.

              "},{"location":"data/webadmin/layergroups/#root-layer-in-capabilities","title":"Root Layer in Capabilities","text":"

              Capabilities documents in GeoServer always have a top level (root) Layer element that works as a container of all the available layers and groups.

              When a layer group is the only top level element in the Capabilities document, it is possible to remove this root Layer and return a hierarchy where the layer group is the root instead.

              To enable this functionality, choose the No option from the Root Layer in Capabilities section.

              By default this behaviour is inherited from the global WMS service settings (WMS Global Settings option). Finally, it is possible to override the service settings and force a Yes to always include the GeoServer root element.

              Layer groups root layer in capabilities options

              "},{"location":"data/webadmin/layergroups/#http-settings","title":"HTTP Settings","text":"

              Cache parameters that apply to the HTTP response from client requests.

              • Response Cache Headers--- If selected, conforming HTTP clients will not request the same tile twice within the time specified in Cache Time. One hour measured in seconds (3600), is the default value for Cache Time. Layer group Response Cache Headers configuration replace Response Cache Headers configured in layers defined in layer group.

              "},{"location":"data/webadmin/layerpreview/","title":"Layer Preview","text":"

              This page provides layer views in various output formats. A layer must be enabled to be previewed.

              Layer Preview Page

              Each layer row consists of a type, name, title, and available formats for viewing.

              Icon Description Raster (grid) Polygon Line Point Other Geometry Layer Group Cascading WMS Unknown/Other

              Name refers to the Workspace and Layer Name of a layer, while Title refers to the brief description configured in the Edit Layer: Data panel. In the following example, nurc refers to the Workspace, Arc_Sample refers to the Layer Name and \"A sample ArcGrid field\" is specified on the Edit Later Data panel.

              Single Layer preview row

              "},{"location":"data/webadmin/layerpreview/#output-formats","title":"Output Formats","text":"

              The Layer Preview page supports a variety of output formats for further use or data sharing. You can preview all three layer types in the common OpenLayers and KML formats. Similarly, using the \"All formats\" menu you can preview all layer types in seven additional output formats---AtomPub, GIF, GeoRss, JPEG, KML (compressed), PDF, PNG, SVG, and TIFF. Only Vector layers provide the WFS output previews, including the common GML as well as the CSV, GML3, GeoJSON and shapefile formats. The table below provides a brief description of all supported output formats, organized by output type (image, text, or data).

              "},{"location":"data/webadmin/layerpreview/#image-outputs","title":"Image Outputs","text":"

              All image outputs can be initiated from a WMS getMap request on either a raster, vector or coverage data. WMS are methods that allows visual display of spatial data without necessarily providing access to the features that comprise those data.

              Format Description KML KML (Keyhole Markup Language) is an XML-based language schema for expressing geographic data in an Earth browser, such as Google Earth or Google Maps. KML uses a tag-based structure with nested elements and attributes. For GeoServer, KML files are distributed as a KMZ, which is a zipped KML file. JPEG WMS output in raster format. The JPEG is a compressed graphic file format, with some loss of quality due to compression. It is best used for photos and not recommended for exact reproduction of data. GIF WMS output in raster format. The GIF (Graphics Interchange Format) is a bitmap image format best suited for sharp-edged line art with a limited number of colors. This takes advantage of the format's lossless compression, which favors flat areas of uniform color with well defined edges (in contrast to JPEG, which favors smooth gradients and softer images). GIF is limited to an 8-bit palette, or 256 colors. SVG WMS output in vector format. SVG (Scalable Vector Graphics) is a language for modeling two-dimensional graphics in XML. It differs from the GIF and JPEG in that it uses graphic objects rather than individual points. TIFF WMS output in raster format. TIFF (Tagged Image File Format) is a flexible, adaptable format for handling multiple data in a single file. GeoTIFF contains geographic data embedded as tags within the TIFF file. PNG WMS output in raster format. The PNG (Portable Network Graphics) file format was created as the free, open-source successor to the GIF. The PNG file format supports truecolor (16 million colors) while the GIF supports only 256 colors. The PNG file excels when the image has large, uniformly coloured areas. OpenLayers WMS GetMap request outputs a simple OpenLayers preview window. OpenLayers is an open source JavaScript library for displaying map data in web browsers. The OpenLayers output has some advanced filters that are not available when using a standalone version of OpenLayers. Further, the generated preview contains a header with easy configuration options for display. Version 3 of the OpenLayers library is used by default. Version 3 can be disabled with the ENABLE_OL3 (true/false) format option or system property. For older browsers not supported by OpenLayers 3, version 2 is used regardless of the setting. PDF A PDF (Portable Document Format) encapsulates a complete description of a fixed-layout 2D document,including any text, fonts, raster images, and 2D vector graphics.

              Sample Image Output-an OpenLayers preview of nurc:Pk50095

              "},{"location":"data/webadmin/layerpreview/#text-outputs","title":"Text Outputs","text":"Format Description AtomPub WMS output of spatial data in XML format. The AtomPub (Atom Publishing Protocol) is an application-level protocol for publishing and editing Web Resources using HTTP and XML. Developed as a replacement for the RSS family of standards for content syndication, Atom allows subscription of geo data. GeoRss WMS GetMap request output of vector data in XML format. RSS (Rich Site Summary) is an XML format for delivering regularly changing web content. GeoRss is a standard for encoding location as part of a RSS feed.supports Layers Preview produces a RSS 2.0 documents, with GeoRSS Simple geometries using Atom. GeoJSON JavaScript Object Notation (JSON) is a lightweight data-interchange format based on the JavaScript programming language. This makes it an ideal interchange format for browser based applications since it can be parsed directly and easily in to javascript. GeoJSON is a plain text output format that add geographic types to JSON (and is now a w3c standard). CSV WFS GetFeature output in comma-delimited text. CSV (Comma Separated Values) files are text files containing rows of data. Data values in each row are separated by commas. CSV files also contain a comma-separated header row explaining each row's value ordering. GeoServer's CSVs are fully streaming, with no limitation on the amount of data that can be outputted.

              A fragment of a simple GeoRSS for nurc:Pk50095 using Atom:

              <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n <rss xmlns:atom=\"http://www.w3.org/2005/Atom\"\n      xmlns:georss=\"http://www.georss.org/georss\" version=\"2.0\">\n    <channel>\n      <title>Pk50095</title>\n      <description>Feed auto-generated by GeoServer</description>\n      <link>></link>     \n      <item>\n        <title>fid--f04ca6b_1226f8d829e_-7ff4</title>\n        <georss:polygon>46.722110379286 13.00635746384126 \n         46.72697223230676 13.308182612644663 46.91359611878293\n         13.302316867622581 46.90870264238999 12.999446822650462 \n         46.722110379286 13.00635746384126\n        </georss:polygon>\n        </item>\n    </channel>\n</rss>\n
              "},{"location":"data/webadmin/layerpreview/#data-outputs","title":"Data Outputs","text":"

              All data outputs are initiated from a WFS GetFeature request on vector data.

              Format Description GML2 GML3 GML (Geography Markup Language) is the XML grammar defined by the Open Geospatial Consortium (OGC) to express geographical features. GML serves as a modeling language for geographic systems as well as an open interchange format for geographic data sharing. GML2 is the default (Common) output format, while GML3 is available from the \"All Formats\" menu. Shapefile The ESRI Shapefile, or simply a shapefile, is the most commonly used format for exchanging GIS data. GeoServer outputs shapefiles in zip format, with a directory of .cst, .dbf, .prg, .shp, and .shx files."},{"location":"data/webadmin/layers/","title":"Layers","text":"

              In GeoServer, the term \"layer\" refers to a raster or vector dataset that represents a collection of geographic features. Vector layers are analogous to \"featureTypes\" and raster layers are analogous to \"coverages\". All layers have a source of data, known as a Store. The layer is associated with the Workspace in which the Store is defined.

              In the Layers section of the web interface, you can view and edit existing layers, add (register) a new layer, or remove (unregister) a layer. The Layers View page displays the list of layers, and the Store and Workspace in which each layer is contained. The View page also displays the layer's status and native SRS.

              Layers View

              "},{"location":"data/webadmin/layers/#layer-types","title":"Layer types","text":"

              Layers can be divided into two types of data: raster and vector. These two formats differ in how they store spatial information. Vector types store information about feature types as mathematical paths---a point as a single x,y coordinate, lines as a series of x,y coordinates, and polygons as a series of x,y coordinates that start and end on the same place. Raster format data is a cell-based representation of features on the earth surface. Each cell has a distinct value, and all cells with the same value represent a specific feature.

              Field Description

              Raster (grid)

              Polygon

              Line

              Point

              "},{"location":"data/webadmin/layers/#data_webadmin_layers_add_a_layer","title":"Add a Layer","text":"

              At the upper left-hand corner of the layers view page there are two buttons for the adding and removal of layers. The green plus button allows you to add a new layer. The red minus button allows you to remove selected layers.

              Buttons to Add and Remove a Layer

              Clicking the Add a new layer button brings up a New Layer Chooser panel. The menu displays all currently enabled stores. From this menu, select the Store where the layer should be added.

              List of all currently enabled stores

              Upon selection of a Store, a list is displayed of resources within the store. Resources which have already been published as layers are listed first, followed by other resources which are available to be published. In this example, giant_polygon, poi, poly_landmarks and tiger_roads are all existing layers within the NYC store.

              List of published and available resources in a store

              To add a layer for an available resource click Publish. To add a new layer for a published resource click Publish Again. (Note that when re-publishing the name of the new layer may have to be modified to avoid conflict with an existing layer.) The actions display an Edit Layer page to enter the definition of the new layer.

              "},{"location":"data/webadmin/layers/#remove-a-layer","title":"Remove a Layer","text":"

              To remove a layer, select it by clicking the checkbox next to the layer. As shown below, multiple layers can be selected for batch removal. Note that selections for removal will not persist from one results pages to the next.

              Some layers selected for removal

              All layers can be selected for removal by clicking the checkbox in the header.

              All layers selected for removal

              Once layer(s) are selected, the Remove selected resources link is activated. Once you've clicked the link, you will be asked to confirm or cancel the removal. Selecting OK removes the selected layer(s).

              "},{"location":"data/webadmin/layers/#data_webadmin_layers_edit_data","title":"Edit Layer: Data","text":"

              To view or edit a layer, click the layer name. A layer configuration page will be displayed. The Data tab, activated by default, allows you to define and change data parameters for a layer.

              Edit Layer: Data tab

              "},{"location":"data/webadmin/layers/#basic-info","title":"Basic Info","text":"

              The beginning sections---Basic Resource Info, Keywords and Metadata link---are analogous to the Service Metadata section for WCS, WFS, and WMS. These sections provide \"data about the data,\" specifically textual information that make the layer data easier to understand and work with. The metadata information will appear in the capabilities documents which refer to the layer.

              • Name---Identifier used to reference the layer in WMS requests. (Note that for a new layer for an already-published resource, the name must be changed to avoid conflict.)

              • Enabled---A layer that is not enabled won't be available to any kind of request, it will just show up in the configuration (and in REST config)

              • Advertised---A layer is advertised by default. A non-advertised layer will be available in all data access requests (for example, WMS GetMap, WMS GetFeature) but won't appear in any capabilities document or in the layer preview.

              • Title---Human-readable description to briefly identify the layer to clients (required)

              • Abstract---Describes the layer in detail

              • Keywords---List of short words associated with the layer to assist catalog searching

              • Metadata Links---Allows linking to external documents that describe the data layer. The \"type\" input provides a few example types, like FGDC or ISO19115:2003, but allows any other type to be declared. The optional \"About\" entry can be used to point to the definition of the metadata standard, or any other side information about it. Finally, \"URL\" points to the actual metadata, while \"Format\" provides its mime type.

                Adding a metadata link in FGDC format

              "},{"location":"data/webadmin/layers/#coordinate-reference-systems","title":"Coordinate Reference Systems","text":"

              A coordinate reference system (CRS) defines how georeferenced spatial data relates to real locations on the Earth's surface. CRSes are part of a more general model called Spatial Reference Systems (SRS), which includes referencing by coordinates and geographic identifiers. GeoServer needs to know the Coordinate Reference System of your data. This information is used for computing the latitude/longitude bounding box and reprojecting the data during both WMS and WFS requests.

              Coordinate reference system of a layer

              • Native SRS---Specifies the coordinate system the layer is stored in. Clicking the projection link displays a description of the SRS.
              • Declared SRS---Specifies the coordinate system GeoServer publishes to clients
              • SRS Handling---Determines how GeoServer should handle projection when the two SRSes differ. Possible values are:
                • Force declared (default): the declared SRS is forced upon the data, overwriting the native one. This is the default option and normally the best course of action, the declared code comes from the EPSG database and has a wealth of extra information in it, starting from a valid EPSG code, an area of validity, a link back in the database to find the best transformation steps to other coordinate reference systems should reprojection be required. Use this option when the source has no native CRS, has a wrong one, or has one matching the EPSG code (in order to get full metadata in the CRS used by GeoServer).
                • Reproject from native: This setting should be used when the native data set has a CRS that is not matching any official EPSG. OGC protocols need to advertise a EPSG code for the layers, with this setting the declared one will be advertised, and reprojection from native will happen on the fly as needed (in case a third CRS is requested, the reprojection will go directly from native to declared)
                • Keep native: this is a setting that should be used in very rare cases. Keeping native means using the declared one in the capabilities documents, but then using the native CRS in all otherrequests (with no reprojection in between, unless explicitly requested from client). This is particularly problematic if the source is a shapefile, as the PRJ files lack all the extra information provided by the EPSG database (it will for example break WFS 1.1 and 2.0 SRS declarations in GML output). The setting meant to be used in cases where WMS is the primary target, and the native and declared CRSs have very small differences, avoiding on the fly reprojection and datum change.

              In summary, use Force Declared as your primary option, Reproject from native only if your source data does not match any EPSG code, and Keep Native only if you really know what you're doing.

              For WMS Server and WFS-NG layers with multiple supported CRS in capability document, the Native CRS can be selected from clicking Find button next to Native SRS field

              "},{"location":"data/webadmin/layers/#bounding-boxes","title":"Bounding Boxes","text":"

              The bounding box determines the extent of the data within a layer.

              • Native Bounding Box---The bounds of the data specified in the Native SRS. These bounds can be generated by clicking the Compute from data button or they can be generated from the SRS definition by clicking the Compute from SRS bounds button. The SRS used depends on the SRS Handling chosen: the declared SRS when Force declared or Reproject native to declared are chosen, otherwise the native SRS is used. If the SRS does not have a bounding defined then none is generated.
              • Lat/Lon Bounding Box---The bounds specified in geographic coordinates. These bounds can be calculated by clicking the Compute from native bounds button.

              Bounding Boxes of a layer

              "},{"location":"data/webadmin/layers/#coverage-parameters-raster","title":"Coverage Parameters (Raster)","text":"

              Optional coverage parameters are possible for certain types of raster data. For example, WorldImage formats request a valid range of grid coordinates in two dimensions known as a ReadGridGeometry2D. For ImageMosaic, you can use InputImageThresholdValue, InputTransparentColor, and OutputTransparentColor to control the rendering of the mosaic in terms of thresholding and transparency.

              "},{"location":"data/webadmin/layers/#curves-support-vector","title":"Curves support (Vector)","text":"

              GeoServer can handle geometries containing circular arcs (initially only from Oracle Spatial and the \"properties data store\", though more data sources are planned).

              These geometries are kept in memory in their circular representation for as long as possible, are properly visually depicted in WMS, and encoded in GML 3.x as curved.

              There are two options pertaining the circular arcs:

              • Linear geometries can contain circular arcs should be checked to inform the GML encoder that the layer can contain circular arcs among other linear segments in the geometries, and thus use \"gml:Curve\" in place of \"gml:LineString\" in GML 3.1 output format. This is required because there is no quick way to know from the data sources if the linear geometries do contain circular arcs, and the choice of top level GML elements influences whether it is possible, or not, to represent circular arcs in their natural form.
              • Linearization tolerance controls how accurately the linearized version of geometries matches the original circular version of them. The tolerance can be expressed as an absolute number in the native unit of measure of the data, or it can be expressed in meters or feet using the \"m\" and \"ft\" suffixes (such as \"10m\" or \"15ft\").

              Curved geometry control

              "},{"location":"data/webadmin/layers/#data_webadmin_layers_edit_publishing","title":"Feature Type Details (Vector)","text":"

              Vector layers have a list of the Feature Type Details. These include the Property and Type of a data source. For example, the sf:archsites layer shown below includes a geometry (the_geom) of type \"point\".

              Feature Type Details

              The Nillable option refers to whether the property requires a value or may be flagged as being null. Meanwhile Min/Max Occurrences refers to how many values a field is allowed to have. Currently both Nillable and Min/Max Occurrences are set to true and 0/1 but may be extended with future work on complex features.

              The Customize attributes checkbox opens an attribute editor allowing customization.

              Attribute customization

              It is possible to:

              • Change the order of attributes, using either the up/down arrows, or dragging the attribute row.
              • Remove an attribute using the \"remove\" icon at the end of the attribute row.
              • Add a new attribute, which will be computed based on the Source CQL expression.
              • Rename an attribute.
              • Add a description of the attribute, which will be visible wherever the feature type is described.
              • Change the nillability of the attribute, for example, making the attribute mandatory even if it's not in the data source, and vice-versa.
              • Change the type of the attribute using the Type column. The most common types are available in a drop-down on editing, but it's possible to indicate any valid Java class, as long as GeoServer has a converter that goes from the value produced by the Source expression to the target type (new converters can be plugged in with some Java programming).
              • Reset the table to the native settings, using the Reset customization link.

              Some of the feature type edits might result in the layer not being editable anymore, for example, by removing an attribute that is marked as mandatory in the data source.

              "},{"location":"data/webadmin/layers/#restricting-features-showing-up-in-the-layer","title":"Restricting features showing up in the layer","text":"

              By default GeoServer will publish all the features available in the layer. It is possible to restrict the features to a subset by specifying a CQL filter in the configuration:

              Restrict the features on layer by CQL filter

              Note

              It is recommended to use this setting for layers that are not meant to be edited. The filter is only applied to reads, if a WFS-T insert adds a feature not matching the filter, it will be added to the store anyways, but won't show up in any of the outputs.

              "},{"location":"data/webadmin/layers/#edit-layer-publishing","title":"Edit Layer: Publishing","text":"

              The Publishing tab configures HTTP and WMS/WFS/WCS settings.

              Edit Layer: Publishing tab

              "},{"location":"data/webadmin/layers/#http-settings","title":"HTTP Settings","text":"

              Cache parameters that apply to the HTTP response from client requests.

              • Response Cache Headers--- If selected, GeoServer will not request the same tile twice within the time specified in Cache Time. One hour measured in seconds (3600), is the default value for Cache Time.

              "},{"location":"data/webadmin/layers/#root-layer-in-capabilities","title":"Root Layer in Capabilities","text":"

              Capabilities documents in GeoServer always have a top level (root) Layer element that works as a container of all the available layers and groups.

              When a layer is the only top level element in the Capabilities document, it is possible to remove this root Layer and return a hierarchy where the layer is the root instead.

              To enable this functionality, choose the No option from the Root Layer in Capabilities section.

              By default this behaviour is inherited from the global WMS service settings (WMS Global Settings option). Finally, it is possible to override the service settings and force a Yes to always include the GeoServer root element.

              Layer root layer in capabilities options

              "},{"location":"data/webadmin/layers/#services-settings","title":"Services Settings","text":"

              Sets services configuration on layer level.

              Services Settings

              • Selectively enable services for layer---Activate/deactivate service enable/disable configuration for the layer.

              • Enabled Services---Selects enabled services list for this layer.

              • Disabled Services---Selects disabled services list for this layer.

                Note

                It is also possible to set by-default disabled services to all layers using the org.geoserver.service.disabled system/env/servlet context variable. This variable accepts a comma separated list of services that should be disabled by default, in case the resource in question has no explicit configuration.

              "},{"location":"data/webadmin/layers/#wms-settings","title":"WMS Settings","text":"

              Sets the WMS specific publishing parameters.

              WMS Settings

              • Queryable---Controls whether the layer is queryable via WMS GetFeatureInfo requests.
              • Default style---Style that will be used when the client does not specify a named style in GetMap requests.
              • Additional styles---Other styles that can be associated with this layer. Some clients (and the GeoServer Layer Preview) will present those as styling alternatives for that layer to the user.
              • Default rendering buffer---Default value of the buffer GetMap/GetFeatureInfo vendor parameter. See the WMS vendor parameters for more details.
              • Default WMS path---Location of the layer in the WMS capabilities layer tree. Useful for building non-opaque layer groups
              • Default Interpolation Method---Allows to specify a default resampling (interpolation) method for this layer. The available options are Nearest neighbor, Bilinear, Bicubic, or Use service default, which means that no layer specific configuration will be created (the default interpolation method selected in the WMS service configuration page will be used, see Raster Rendering Options for details). Can be overridden by the interpolations vendor parameter.
              "},{"location":"data/webadmin/layers/#wms-attribution","title":"WMS Attribution","text":"

              Sets publishing information about data providers.

              WMS Attribution

              • Attribution Text---Human-readable text describing the data provider. This might be used as the text for a hyperlink to the data provider's website.
              • Attribution Link---URL to the data provider's website.
              • Logo URL---URL to an image that serves as a logo for the data provider.
              • Logo Content Type, Width, and Height---These fields provide information about the logo image that clients may use to assist with layout. GeoServer will auto-detect these values if you click the Auto-detect image size and type link at the bottom of the section. The text, link, and URL are each advertised in the WMS Capabilities document if they are provided. Some WMS clients will display this information to advise users which providers provide a particular dataset. If you omit some of the fields, those that are provided will be published and those that are not will be omitted from the Capabilities document.
              "},{"location":"data/webadmin/layers/#wfs-settings","title":"WFS Settings","text":"

              Sets the WFS specific publishing parameters.

              WFS Settings

              • Per-Request Feature Limit---Sets the maximum number of features for a layer a WFS GetFeature operation should generate (regardless of the actual number of query hits)

              • Maximum number of decimals---Sets the maximum number of decimals in GML output.

              • Activate complex to simple features conversion - If the target output format does not handle complex features natively, this option enables the conversion of complex features to simple features, using only SF-0 (simple) attributes. This means that nested features and multiple-value attributes will be omitted from the final result, instead of throwing errors while generating the output. Output formats capable of handling complex features are not affected.

                Note

                It is also possible to override the OtherSRS/OtherCRS list configured in the WFS service, including overriding it with an empty list if need be. The input area will accept a comma separated list of EPSG codes:

                WFS otherSRS/otherCRS override

                The list will be used only for the capabilities document generation, but will not be used to limit the actual target SRS usage in GetFeature requests.

              • Encode coordinates measures---Checking this setting will cause coordinates measures (\"M\") to be encoded in WFS output formats that support measures. The default (not checked) is to not encode coordinates measures.

              "},{"location":"data/webadmin/layers/#wcs-settings","title":"WCS Settings","text":"
              • Request SRS---Provides a list of SRSs the layer can be converted to. New Request SRS allows you to add an SRS to that list.
              • Interpolation Methods---Sets the raster rendering process, if applicable.
              • Formats---Lists which output formats a layers supports.
              • GeoSearch---When enabled, allows the Google Geosearch crawler to index from this particular layer. See What is a Geo Sitemap? for more information.
              "},{"location":"data/webadmin/layers/#kml-format-settings","title":"KML Format Settings","text":"

              Limits features based on certain criteria, otherwise known as regionation.

              • Default Regionating Attribute---Choose which feature should show up more prominently than others.
              • Regionating Methods---There are four types of regionating methods:
                • external-sorting---Creates a temporary auxiliary database within GeoServer. The first request to build an index takes longer than subsequent requests.
                • geometry---Externally sorts by length (if lines) or area (if polygons)
                • native-sorting---Uses the default sorting algorithm of the backend where the data is hosted. It is faster than external-sorting, but will only work with PostGIS datastores.
                • random---Uses the existing order of the data and does not sort
              "},{"location":"data/webadmin/layers/#data_webadmin_layers_edit_dimensions","title":"Edit Layer: Dimensions","text":"

              GeoServer supports adding specific dimensions to WMS layers, as specified in WMS 1.1.1 and WMS 1.3.0 standards. There are two pre-defined dimensions in the WMS standards mentioned above, TIME and ELEVATION. Enabling dimensions for a layer allows users to specify those as extra parameters in GetMap requests, filtering the dataset to that particular set of times or elevations.

              These dimensions can be enabled and configured on the Dimensions tab.

              TIME dimension enabled for a WMS layer

              For each enabled dimension the following configuration options are available:

              • Attribute---Attribute name for picking the value for this dimension (vector only). This is treated at start of the range if End attribute is also given.
              • End attribute---Attribute name for picking the end of the value range for this dimension (optional, vector only).
              • Presentation---The presentation type for the available values in the capabilities document. Either each value separately (list), interval and resolution, or continuous interval.
              • Default value---Default value to use for this dimension if none is provided with the request. Select one of from four strategies:
                • smallest domain value---Uses the smallest available value from the data
                • biggest domain value---Uses the biggest available value from the data
                • nearest to the reference value---Selects the data value closest to the given reference value
                • reference value---Tries to use the given reference value as-is, regardless of whether its actually available in the data or not.
              • Reference value---The default value specifier. Only shown for the default value strategies where its used.
              • Nearest match---Whether to enable, or not, WMS nearest match support on this dimension. Currently supported only on the time dimension.
              • Nearest match on raw data---Whether to enable, or not, nearest match support on this dimension for raw data requests (WCS for coverage layers, WFS for feature layers). Currently supported only on the time dimension for WCS service.
              • Acceptable interval---A maximum search distance from the specified value (available only when nearest match is enabled). Can be empty (no limit), a single value (symmetric search) or using a before/after syntax to specify an asymmetric search range. Time distances should specified using the ISO period syntax. For example, PT1H/PT0H allows to search up to one hour before the user specified value, but not after.
              • On nearest match fail---What to do if the nearest match fails the acceptable interval. The default behavior is to use the original value and thus return an empty result, but can also be configured to throw an InvalidDimensionValue exception instead. In case the value is not set, it defaults to ignoring the nearest match and using the original value. To switch to the opposite default, set the following variable (system, environment, or web.xml, as usual): org.geoserver.wms.nearestFail=EXCEPTION.
              • Begin of data range---A manually declared start value for the data range. When specified, the End of data range has to be specified also. Has to be either numeric, an ISO 8601 DateTime format or the string PRESENT. If left blank GeoServer will determine the value automatically based on the data. When using 'PRESENT' the current DateTime of the server will be used when the capabilities document is generated. Setting this value manually may be desired when working with layers consisting of huge amounts of data where the automatic determination can get slow. This parameter is only handled for WMS Layers in their capabilities document.
              • End of data range---A manually declared end value for the data range. When specified, the Begin of data range has to be specified also. Has to be either numeric, an ISO 8601 DateTime format or the string PRESENT. If left blank GeoServer will determine the value automatically based on the data. When using 'PRESENT' the current DateTime of the server will be used when the capabilities document is generated. Setting this value manually may be desired when working with layers consisting of huge amounts of data where the automatic determination can get slow. This parameter is only handled for WMS Layers in their capabilities document.

              For time dimension the value must be in ISO 8601 DateTime format yyyy-MM-ddThh:mm:ss.SSSZ For elevation dimension, the value must be and integer of floating point number.

              Only for the \"Reference value\" strategy, it is also possible to use ranges or times and ranges of elevation, in the form fromValue/toValue. Only for the \"Reference value\" strategy, and limited to times, it's also possible to use relative times like P1M/PRESENT, but caution is given that the reference value is copied verbatim into the capabilities document, and as a result, not all client might be recognizing that syntax.

              Note

              For more information on specifying times, please see the section on Time Support in GeoServer WMS.

              "},{"location":"data/webadmin/layers/#vector-custom-dimensions","title":"Vector Custom Dimensions","text":"

              GeoServer also supports adding custom dimensions to vector layers, defining their names and configurations.

              Custom dimension enabled for a vector layer

              For each enabled dimension the following configuration options are available:

              • Name---Custom dimension name.
              • Attribute---Attribute name for picking the value for this dimension (vector only). This is treated at start of the range if End attribute is also given.
              • End attribute---Attribute name for picking the end of the value range for this dimension (optional, vector only).
              • Presentation---The presentation type for the available values in the capabilities document. Either each value separately (list), interval and resolution, or continuous interval.
              • Default value---Default value to use for this dimension if none is provided with the request. Select one of from four strategies:
                • smallest domain value---Uses the smallest available value from the data
                • biggest domain value---Uses the biggest available value from the data
                • nearest to the reference value---Selects the data value closest to the given reference value
                • reference value---Tries to use the given reference value as-is, regardless of whether its actually available in the data or not.
              • Reference value---The default value specifier. Only shown for the default value strategies where its used.
              • Nearest match---Whether to enable, or not, WMS nearest match support on this dimension.
              • Acceptable interval---A maximum search distance from the specified value (available only when nearest match is enabled). Can be empty (no limit), a single value (symmetric search) or using a before/after syntax to specify an asymmetric search range.
              • Begin of data range---A manually declared start value for the data range. When specified, the End of data range has to be specified also. Has to be either numeric, an ISO 8601 DateTime format or the string PRESENT. If left blank GeoServer will determine the value automatically based on the data. When using 'PRESENT' the current DateTime of the server will be used when the capabilities document is generated. Setting this value manually may be desired when working with layers consisting of huge amounts of data where the automatic determination can get slow. This parameter is only handled for WMS Layers in their capabilities document.
              • End of data range---A manually declared end value for the data range. When specified, the Begin of data range has to be specified also. Has to be either numeric, an ISO 8601 DateTime format or the string PRESENT. If left blank GeoServer will determine the value automatically based on the data. When using 'PRESENT' the current DateTime of the server will be used when the capabilities document is generated. Setting this value manually may be desired when working with layers consisting of huge amounts of data where the automatic determination can get slow. This parameter is only handled for WMS Layers in their capabilities document.
              "},{"location":"data/webadmin/layers/#edit-layer-security","title":"Edit Layer: Security","text":"

              Note

              For more information on data access rules, please see the section on Data.

              Sets data access rules at layer level.

              To create/edit layer's data access rules simply check/uncheck checkboxes according to desired access mode and role. The Grant access to any role checkbox grant each role for each access mode.

              "},{"location":"data/webadmin/stores/","title":"Stores","text":"

              A store connects to a data source that contains raster or vector data. A data source can be a file or group of files, a table in a database, a single raster file, or a directory (for example, a Vector Product Format library). The store construct allows connection parameters to be defined once, rather than for each dataset in a source. As such, it is necessary to register a store before configuring datasets within it.

              Stores View

              "},{"location":"data/webadmin/stores/#store-types","title":"Store types","text":"

              While there are many potential formats for data sources, there are only four kinds of stores. For raster data, a store can be a file. For vector data, a store can be a file, database, or server.

              Type Icon Description

              raster data in a file

              vector data in a file

              vector data in a database

              vector server (web feature server)

              "},{"location":"data/webadmin/stores/#edit-a-store","title":"Edit a Store","text":"

              To view or edit a store, click the store name. A store configuration page will be displayed. The exact contents of this page depend on the specific format of the store. See the sections Vector data, Raster data, and Databases for information about specific data formats. The example shows the configuration for the nurc:ArcGridSample store.

              Editing a raster data store

              "},{"location":"data/webadmin/stores/#basic-store-info","title":"Basic Store Info","text":"

              The basic information is common for all formats.

              • Workspace - the store is assigned to the selected workspace
              • Data Source Name - the store name as listed on the view page
              • Description - (optional) a description that displays in the administration interface
              • Enabled - enables or disables access to the store, along with all datasets defined for it
              • Auto disable on connection failure - auto disables access to the store if any issue happens when geoserver tries to acquire access to the store
              "},{"location":"data/webadmin/stores/#connection-parameters","title":"Connection Parameters","text":"

              The connection parameters vary depending on data format.

              "},{"location":"data/webadmin/stores/#data_webadmin_stores_add_a_store","title":"Add a Store","text":"

              The buttons for adding and removing a store can be found at the top of the Stores page.

              Buttons to add and remove a Store

              To add a store, select the Add new Store button. You will be prompted to choose a data source. GeoServer natively supports many formats (with more available via extensions). Click the appropriate data source to continue.

              Choosing the data source for a new store

              The next page configures the store. Since connection parameters differ across data sources, the exact contents of this page depend on the store's specific format. See the sections Vector data, Raster data, and Databases for information on specific data formats. The example below shows the ArcGrid raster configuration page.

              Configuration page for an ArcGrid raster data source

              "},{"location":"data/webadmin/stores/#remove-a-store","title":"Remove a Store","text":"

              To remove a store, click the checkbox next to the store. Multiple stores can be selected, or all can be selected by clicking the checkbox in the header.

              Stores selected for removal

              Click the Remove selected Stores button. You will be asked to confirm the removal of the configuration for the store(s) and all resources defined under them. Clicking OK removes the selected store(s), and returns to the Stores page.

              Confirm removal of stores

              "},{"location":"data/webadmin/workspaces/","title":"Workspaces","text":"

              This section describes how to view and configure workspaces. Analogous to a namespace, a workspace is a container which organizes other items. In GeoServer, a workspace is often used to group similar layers together. Layers may be referred to by their workspace name, colon, layer name (for example topp:states). Two different layers can have the same name as long as they belong to different workspaces (for example sf:states and topp:states).

              Workspaces page

              "},{"location":"data/webadmin/workspaces/#data_webadmin_workspaces_add_workspace","title":"Add a Workspace","text":"

              The buttons for adding and removing a workspace can be found at the top of the Workspaces view page.

              Buttons to add and remove

              To add a workspace, select the Add new workspace button. You will be prompted to enter the workspace name and URI (as described in Edit a Workspace below).

              New Workspace page with example

              "},{"location":"data/webadmin/workspaces/#remove-a-workspace","title":"Remove a Workspace","text":"

              To remove a workspace, select it by clicking the checkbox next to the workspace. Multiple workspaces can be selected, or all can be selected by clicking the checkbox in the header. Click the Remove selected workspaces(s) button. You will be asked to confirm or cancel the removal. Clicking OK removes the selected workspace(s).

              Workspace removal confirmation

              "},{"location":"data/webadmin/workspaces/#data_webadmin_workspaces_edit","title":"Edit a Workspace","text":"

              To view or edit a workspace, click the workspace name. A workspace configuration page will be displayed.

              Workspace named \"topp\"

              A workspace is defined by a name and a Namespace URI (Uniform Resource Identifier).

              • Name: The workspace name, may not contain whitespace.

                The workspace name is used as an XML prefix for the Namespace URI when generating xml documents.

                The workspace name is used as a prefix when naming individual layers (unless Default workspace is used as described below).

              • Namespace URI: A URI is similar to a URL, except URIs do not need to point to an actual location on the web, and only need to be a unique identifier.

                For a Workspace URI, we recommend using a URL associated with your project, with perhaps a different trailing identifier. For example, http://www.openplans.org/topp is the URI for the \"topp\" workspace.

              • Default Workspace: One workspace can be nominated as the default.

                Layers belonging to the default workspace can be accessed directly, and do not require the workspace name as a prefix.

                A GeoServer configured with one workspace can use this setting to avoid using the workspace name when referencing layers. Keep in mind the workspace name will still be used in the generation of xml documents (where the name is used as an XML prefix to reference the workspace Namespace URI).

              • Isolated workspace: Isolated workspaces content so they are not included as part of global web services.

                The workspace contents will only be visible and queryable in the context of a Virtual Services as described below Isolated Workspaces.

              "},{"location":"data/webadmin/workspaces/#workspace_services","title":"Workspace Services","text":"

              Use the checkbox located next to each service to override the global service definition for the associated service.

              Enable workspace services to provide default service description

              Once enabled clicking on the service link will open the settings page for the service, allowing default values for service title, abstract and other details to be supplied.

              Workspace WMS Settings

              Clients accessing this workspace as a Virtual Services will use the service metadata and settings provided here.

              "},{"location":"data/webadmin/workspaces/#workspace_settings","title":"Workspace Settings","text":"

              Use Enabled checkbox to override the global configuration and contact information for this workspace.

              Enable workspace settings to provide default contact information

              "},{"location":"data/webadmin/workspaces/#contact-information","title":"Contact Information","text":"

              Clients accessing this workspace as a Virtual Services will use the contact information provided here.

              Organization contact information:

              • The Welcome message is used as an introduction in the welcome page header for this workspace.
              • The Organization name and Online Resource are combined to form an organization link in the welcome page header for this workspace.

              Workspace Organization

              Primary contact information:

              • The email address if provided, will be used as the administrator contact in the welcome page footer for this workspace.

              Workspace Primary Contact

              Address contact information:

              Workspace address

              If this information is not provided the contact information from the global Contact Information page is used.

              "},{"location":"data/webadmin/workspaces/#service-settings","title":"Service Settings","text":"

              Other settings provide additional Global Settings can be overridden on a workspace-by-workspace basis.

              • Include Layer Prefix in Local Workspace Capabilities: Enable this setting to force the inclusion of the workspace name as a prefix when accessing workspace contents as a virtual web service. The layer ne:countries is always referenced as ne:countries with this setting enabled.

                With this setting disabled layers may be referenced directly (with no prefix) when accessed by a virtual web service. The layer ne:countries can be referenced as countries when this setting is disabled (and the layer is being accessed via a ne virtual web service).

              • Root Directory for REST PathMapper: setting used by the RESTful API as the Root Directory for uploaded files, following the structure:

                ${rootDirectory}/workspace/store[/<file>]\n

                Note

                This parameter is only used when the Enabled parameter of the Settings section is checked.

              Other Settings

              If this information is not provided the global settings will be used. For details on other settings see Global Settings.

              "},{"location":"data/webadmin/workspaces/#workspace_security","title":"Security","text":"

              The Security tab allows to set data access rules at workspace level.

              Note

              For more information on data access rules, please see the section on Data.

              To create/edit the workspace's data access rules, check/uncheck checkboxes according to the desired role. The Grant access to any role checkbox grant each role for any access mode.

              "},{"location":"datadirectory/","title":"GeoServer data directory","text":"

              The GeoServer data directory is the location in the file system where GeoServer stores its configuration information.

              The configuration defines what data is served by GeoServer, where it is stored, and how services interact with and serve the data. The data directory also contains a number of support files used by GeoServer for various purposes.

              For production use, it is recommended to define an external data directory (outside the application) to make it easier to upgrade. The Setting the data directory location section describes how to configure GeoServer to use an existing data directory.

              Note

              Since GeoServer provides both an interactive interface (via the web admin interface) and programmatic interface (through the REST API) to manage configuration, most users do not need to know about the internal structure of the data directory, but an overview is provided below.

              • Data directory default location
              • Setting the data directory location
              • Structure of the data directory
              • Migrating a data directory between versions
              • Parameterize catalog settings
              "},{"location":"datadirectory/configtemplate/","title":"Parameterize catalog settings","text":"

              Environment parametrization allows to parameterize some of the settings in GeoServer's catalog by means of a templating mechanism to tailor GeoServer's settings to the environment in which is run.

              For example, there might be the need to move the latest changes made from a GeoServer instance running on machine A to another instance running on machine B, but there are some differences in the way the two environments are set up (e.g. the password used to connect to the database is different). In such scenario if a simple backup of the catalog from instance A is created and restored on instance B, the stores configured on the database will not be accessible and the corresponding layers will not work properly.

              Another example can be the need to have different connection pool configuration for two different GeoServer instances, with respect to the max number of connections available in the pool.

              To enable env parametrization the following flag needs to be set via system variable to GeoServer's environment:

              -DALLOW_ENV_PARAMETRIZATION=true\n

              A properties file holding the parametrized settings needs to be created. It can be provided by naming it geoserver-environment.properties and by placing it in the root directory of the GeoServer's DATA_DIR.

              GeoServer is also able to use a properties file outside the GeoServer's DATA_DIR. In this case the path to the properties file must be defined in one of the following ways:

              • By providing a system variable -DENV_PROPERTIES={properties filepath}.
              • By providing an environment variable named ENV_PROPERTIES and the path to the properties file as the value.
              • By providing a context parameter in the WEB-INF/web.xml file for the GeoServer application:
              <web-app>\n  ...\n  <context-param>\n    <param-name>ENV_PROPERTIES</param-name>\n    <param-value>/var/lib/geoserver_data</param-value>\n  </context-param>\n  ...\n</web-app>\n

              Once a strategy to load the ENV_PROPERTIES has been defined and set, it is possible to edit GeoServer's configuration files of the source machine that needs to be parametrized. For example, let's parameterize the URL of a store (this can also be done via GeoServer admin UI):

              vim coveragestore.xml :

              ...\n <enabled>true</enabled>\n  <workspace>\n    <id>WorkspaceInfoImpl--134aa31e:1564c12ef68:-7ffe</id>\n  </workspace>\n  <__default>false<!--__default-->\n  <url>${store_url}</url>\n</coverageStore>\n

              A definition for the variable store_url needs to be added in

              geoserver-environment.properties :

              store_url = file:///var/geoserver/store/teststore\n

              Once GeoServer has been restarted, it is possible to see that the URL in \"Connection Parameters\" settings now refers the variable store_url whose value is defined in the geoserver-environment.properties file.

              Another common use case is parameterizing connection details for a vector datastore. Hostname, credentials and connection pool parameters for the databases tend to change between environments. Once the variables are set in the geoserver-environment.properties file, the Datastore can be configured as follows:

              "},{"location":"datadirectory/location/","title":"Data directory default location","text":"

              If GeoServer is running in standalone mode (via an installer or a binary) the data directory is located at <installation root>/data_dir.

              Standalone platform Default/typical location Windows (except XP) C:\\Program Files\\GeoServer 2.24.2\\data_dir Windows XP C:\\Program Files\\GeoServer 2.24.2\\data_dir Mac OS X /Applications/GeoServer.app/Contents/Resources/Java/data_dir Linux (Tomcat) /var/lib/tomcat9/webapps/geoserver/data

              If GeoServer is running as a web archive inside of a custom-deployed application server, the data directory is by default located at <web application root>/data.

              "},{"location":"datadirectory/location/#creating-a-new-data-directory","title":"Creating a new data directory","text":"

              The easiest way to create a new data directory is to copy an existing one.

              Once the data directory has been located, copy it to a new location. To point a GeoServer instance at the new data directory proceed to the next section Setting the data directory location.

              "},{"location":"datadirectory/migrating/","title":"Migrating a data directory between versions","text":"

              It is possible to keep the same data directory while migrating to different versions of GeoServer, such as during an update.

              There should generally be no problems or issues migrating data directories between patch versions of GeoServer (for example, from 2.9.0 to 2.9.1 or vice versa).

              Similarly, there should rarely be any issues involved with migrating between minor versions (for example, from 2.8.x to 2.9.x). Care should be taken to back up the data directory prior to migration.

              Note

              Some minor version migrations may not be reversible, since newer versions of GeoServer may make backwards-incompatible changes to the data directory.

              "},{"location":"datadirectory/setting/","title":"Setting the data directory location","text":"

              The procedure for setting the location of the GeoServer data directory is dependent on the type of GeoServer installation. Follow the instructions below specific to the target platform.

              Note

              If the location of the GeoServer data directory is not set explicitly, the directory data_dir under the root of the GeoServer installation will be chosen by default.

              "},{"location":"datadirectory/setting/#windows","title":"Windows","text":"

              On Windows platforms the location of the GeoServer data directory is controlled by the GEOSERVER_DATA_DIR environment variable.

              To set the environment variable:

              1. Open the System Control Panel.

              2. Click Advanced System Properties.

              3. Click Environment Variables.

              4. Click the New button and create a environment variable called GEOSERVER_DATA_DIR and set it to the desired location.

                Setting an environment variable on Windows

              "},{"location":"datadirectory/setting/#linux","title":"Linux","text":"

              On Linux platforms the location of the GeoServer data directory is controlled by the GEOSERVER_DATA_DIR environment variable. Setting the variable can be achieved with the following command (in the terminal):

              export GEOSERVER_DATA_DIR=/var/lib/geoserver_data\n

              To make the variable persist, place the command in the .bash_profile or .bashrc file. Ensure that this done for the user running GeoServer.

              "},{"location":"datadirectory/setting/#mac-os-x","title":"Mac OS X","text":"

              For the binary install of GeoServer on Mac OS X, the data directory is set in the same way as for Linux.

              For the Mac OS X install, set the GEOSERVER_DATA_DIR environment variable to the desired directory location. See this page for details on how to set an environment variable in Mac OS X.

              "},{"location":"datadirectory/setting/#web-archive","title":"Web archive","text":"

              When running a GeoServer WAR inside a servlet container, the data directory can be specified in a number of ways. The recommended method is to set a servlet context parameter. An alternative is to set a Java system property.

              "},{"location":"datadirectory/setting/#context-parameter","title":"Context parameter","text":"

              To specify the data directory using a servlet context parameter, create the following <context-param> element in the WEB-INF/web.xml file for the GeoServer application:

              <web-app>\n  ...\n  <context-param>\n    <param-name>GEOSERVER_DATA_DIR</param-name>\n    <param-value>/var/lib/geoserver_data</param-value>\n  </context-param>\n  ...\n</web-app>\n
              "},{"location":"datadirectory/setting/#java-system-property","title":"Java system property","text":"

              It is also possible to specify the data directory location with a Java system property. This method can be useful during upgrades, as it avoids the need to set the data directory after every upgrade.

              Warning

              Using a Java system property will typically set the property for all applications running in the servlet container, not just GeoServer.

              The method of setting the Java system property is dependent on the servlet container:

              • For Tomcat, edit the file bin/setclasspath.sh under the root of the Tomcat installation. Specify the GEOSERVER_DATA_DIR system property by setting the CATALINA_OPTS variable:

                CATALINA_OPTS=\"-DGEOSERVER_DATA_DIR=/var/lib/geoserver_data\"\n
              • For Glassfish, edit the file domains/<<domain>>/config/domain.xml under the root of the Glassfish installation, where <<domain>> refers to the domain that the GeoServer web application is deployed under. Add a <jvm-options> element inside the <java-config> element:

                ...\n<java-config>\n   ...\n  <jvm-options>-DGEOSERVER_DATA_DIR=/var/lib/geoserver_data</jvm-options>  \n</java-config>\n...\n
              "},{"location":"datadirectory/setting/#require-files-to-exist","title":"Require files to exist","text":"

              If the data directory is on a network filesystem, it can be desirable for security reasons to require one or more files or directories to exist before GeoServer will start, to prevent GeoServer from falling back into a default insecure configuration if the data directory appears to be empty because of the loss of this network resource.

              To require files or directories to exist, use any of the methods above to set GEOSERVER_REQUIRE_FILE. Do not specify a mount point as this will still exist if a network filesystem is unavailable; instead specify a file or directory inside a network mount. For example:

              Environment variable:

              export GEOSERVER_REQUIRE_FILE=/mnt/server/geoserver_data/global.xml\n

              Servlet context parameter:

              <web-app>\n  ...\n  <context-param>\n    <param-name>GEOSERVER_REQUIRE_FILE</param-name>\n    <param-value>/mnt/server/geoserver_data/global.xml</param-value>\n  </context-param>\n  ...\n</web-app>\n

              Java system property:

              CATALINA_OPTS=\"-DGEOSERVER_REQUIRE_FILE=/mnt/server/geoserver_data/global.xml\"\n
              "},{"location":"datadirectory/setting/#multiple-files","title":"Multiple files","text":"

              To specify multiple files or directories that must exist, separate them with the path separator (: on Linux, ; on Windows):

              Environment variable:

              export GEOSERVER_REQUIRE_FILE=/mnt/server/geoserver_data/global.xml:/mnt/server/data\n

              Servlet context parameter:

              <web-app>\n  ...\n  <context-param>\n    <param-name>GEOSERVER_REQUIRE_FILE</param-name>\n    <param-value>/mnt/server/geoserver_data/global.xml:/mnt/server/data</param-value>\n  </context-param>\n  ...\n</web-app>\n

              Java system property:

              CATALINA_OPTS=\"-DGEOSERVER_REQUIRE_FILE=/mnt/server/geoserver_data/global.xml:/mnt/server/data\"\n
              "},{"location":"datadirectory/structure/","title":"Structure of the data directory","text":"

              This section gives an overview of the structure and contents of the GeoServer data directory.

              This is not intended to be a complete reference to the GeoServer configuration information, since generally the data directory configuration files should not be accessed directly.

              Instead, the web_admin can be used to view and modify the configuration, and for programmatic access and manipulation the REST API <../rest/index.rst>_ should be used.

              The directories that do contain user-modifiable content are:

              • logs
              • palettes
              • templates
              • user_projections
              • www
              "},{"location":"datadirectory/structure/#top-level-xml-files","title":"Top-level XML files","text":"

              The top-level XML files contain information about the services and various global options for the server instance.

              File Description global.xml Contains settings common to all services, such as contact information, JAI settings, character sets and verbosity. logging.xml Specifies logging parameters, such as logging level, logfile location, and whether to log to stdout. wcs.xml Contains the service metadata and various settings for the WCS service. wfs.xml Contains the service metadata and various settings for the WFS service. wms.xml Contains the service metadata and various settings for the WMS service."},{"location":"datadirectory/structure/#workspaces","title":"workspaces","text":"

              The workspaces directory contain metadata about the layers published by GeoServer. It contains a directory for each defined workspace.

              Each workspace directory contains directories for the datastores defined in it. Each datastore directory contains directories for the layers defined for the datastore.

              Each layer directory contains a layer.xml file, and either a coverage.xml or a featuretype.xml file depending on whether the layer represents a raster or vector dataset.

              "},{"location":"datadirectory/structure/#data","title":"data","text":"

              The data directory can be used to store file-based geospatial datasets being served as layers.

              Note

              This should not be confused with the main GeoServer data directory, which is the parent to this directory.

              This directory is commonly used to store shapefiles and raster files, but can be used for any data that is file-based.

              The main benefit of storing data files under the data directory is portability.

              Consider a shapefile stored external to the data directory at a location C:\\gis_data\\foo.shp. The datastore entry in catalog.xml for this shapefile would look like the following:

              <datastore id=\"foo_shapefile\">\n   <connectionParams>\n     <parameter name=\"url\" value=\"file://C:/gis_data/foo.shp\" />\n   </connectionParams>\n </datastore>\n

              Now consider trying to port this data directory to another host running GeoServer. The location C:\\gis_data\\foo.shp probably does not exist on the second host. So either the file must be copied to this location on the new host, or catalog.xml must be changed to reflect a new location.

              This problem can be avoided by storing foo.shp in the data directory. In this case the datastore entry in catalog.xml becomes:

              <datastore id=\"foo_shapefile\">\n  <connectionParams>\n    <parameter name=\"url\" value=\"file:data/foo.shp\"/>\n  </connectionParams>\n</datastore>\n

              The value attribute is rewritten to be relative to the data directory. This location independence allows the entire data directory to be copied to a new host and used directly with no additional changes.

              "},{"location":"datadirectory/structure/#demo","title":"demo","text":"

              The demo directory contains files which define the sample requests available in the Demo Request page.

              "},{"location":"datadirectory/structure/#gwc","title":"gwc","text":"

              The gwc directory holds the tile cache created by the embedded GeoWebCache service.

              "},{"location":"datadirectory/structure/#layergroups","title":"layergroups","text":"

              The layergroups directory contains configuration information for the defined layergroups.

              "},{"location":"datadirectory/structure/#logs","title":"logs","text":"

              The logs directory contains configuration information for the various defined logging profiles, and the default geoserver.log log file.

              Note

              See also the Logging section for more details.

              "},{"location":"datadirectory/structure/#palettes","title":"palettes","text":"

              The palettes directory is used to store pre-computed Image Palettes. Image palettes are used by the GeoServer WMS as way to reduce the size of produced images while maintaining image quality.

              Note

              See also the Paletted Images tutorial for more information.

              "},{"location":"datadirectory/structure/#security","title":"security","text":"

              The security directory contains the files used to configure the GeoServer security subsystem. This includes a set of property files which define access roles, along with the services and data each role is authorized to access.

              Note

              See also the Security section for more information.

              "},{"location":"datadirectory/structure/#styles","title":"styles","text":"

              The styles directory contains files which contain styling information used by the GeoServer WMS.

              Note

              See also the Styling section for more information.

              For each SLD file in this directory there is a corresponding XML file:

              <style>\n  <id>StyleInfoImpl--570ae188:124761b8d78:-7fe1</id>\n  <name>grass</name>\n  <sldVersion>\n    <version>1.0.0</version>\n  </sldVersion>\n  <filename>grass_poly.sld</filename>\n  <legend>\n    <width>32</width>\n    <height>32</height>\n    <format>image/png</format>\n    <onlineResource>grass_fill.png</onlineResource>\n  </legend>\n</style>\n

              The styles directory can also be used to host support files referenced during style configuration:

              • Support files: SLD files can reference external graphics. This is useful when supplying your own icons in the form of image files or TrueType font files. Without any path information supplied, the default will be this directory.
              • A style external graphic is dynamically created for use as a legend. The contents of the directory is published allowing clients to access the legends used. When running GeoServer on localhost, an image file image.png stored in this directory can be referenced in a browser using http:/<host:port>/geoserver/styles/image.png.
              "},{"location":"datadirectory/structure/#templates","title":"templates","text":"

              The templates directory contains files used by the GeoServer templating subsystem. Templates are used to customize the output of various GeoServer operations.

              Note

              See also Freemarker Templates for more information..

              "},{"location":"datadirectory/structure/#user_projections","title":"user_projections","text":"

              The user_projections directory contains a file called epsg.properties which is used to define custom spatial reference systems that are not part of the official EPSG database.

              Note

              See also Custom CRS Definitions for more information.

              "},{"location":"datadirectory/structure/#www","title":"www","text":"

              The www directory is used to allow GeoServer to serve files like a regular web server. While not a replacement for a full web server, this can be useful for serving client-side mapping applications. The contents of this directory are served at http:/<host:port>/geoserver/www.

              Note

              See also Serving Static Files for more information.

              "},{"location":"extensions/","title":"Extensions","text":"

              Extensions are modules that add functionality to GeoServer. They are installed as add-ons to the base GeoServer installation.

              This section describes most of the extensions available for GeoServer. Other data formats can be found in the Vector data, Raster data, Databases, and Styling sections.

              • Key authentication module
              • Control flow module
              • DXF OutputFormat for WFS and WPS PPIO
              • Excel WFS Output Format
              • GeoPackage Output
              • GRIB
              • Importer
              • INSPIRE
              • JP2K Plugin
              • libjpeg-turbo Map Encoder Extension
              • Monitoring
              • NetCDF
              • NetCDF Output Format
              • OGR based WFS Output Format
              • GeoServer Printing Module
              • Cross-layer filtering
              • Vector Tiles
              • Web Coverage Service 2.0 Earth Observation extensions
              • MongoDB Data Store
              • SLD REST Service
              • Geofence Plugin
              • Geofence Internal Server
              • Geofence WPS Integration
              • CAS integration
              • Parameters Extractor
              • GWC S3 BlobStore plugin
              • WMTS Multidimensional
              • WPS Download plugin
              • WPS JDBC
              • MapML
              • Catalog Services for the Web (CSW) - ISO Metadata Profile
              • Metadata
              • IAU planetary CRSs
              "},{"location":"extensions/excel/","title":"Excel WFS Output Format","text":"

              The GeoServer Excel plugin adds the ability to output WFS responses in either Excel 97-2003 (.xls) or Excel 2007 (.xlsx) formats.

              "},{"location":"extensions/excel/#installation","title":"Installation","text":"
              1. From the website download page, locate your release, and download: excel
              2. Unzip the archive into the WEB-INF/lib directory of the GeoServer installation.
              3. Restart GeoServer.
              "},{"location":"extensions/excel/#usage","title":"Usage","text":"

              When making a WFS request, set the outputFormat to excel (for Excel 97-2003) or excel2007 (for Excel 2007).

              "},{"location":"extensions/excel/#examples","title":"Examples","text":"Excel 97-2003 GET:

              http://localhost:8080/geoserver/wfs?request=GetFeature&version=1.1.0&typeName=topp:states&outputFormat=excel

              Excel 2007 GET:

              http://localhost:8080/geoserver/wfs?request=GetFeature&version=1.1.0&typeName=topp:states&outputFormat=excel2007

              Excel 97-2003 POST:

              <wfs:GetFeature service=\"WFS\" version=\"1.1.0\"\n  outputFormat=\"excel\"\n  xmlns:topp=\"http://www.openplans.org/topp\"\n  xmlns:wfs=\"http://www.opengis.net/wfs\"\n  xmlns:ogc=\"http://www.opengis.net/ogc\"\n  xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\"\n  xsi:schemaLocation=\"http://www.opengis.net/wfs\n                      http://schemas.opengis.net/wfs/1.1.0/wfs.xsd\">\n  <wfs:Query typeName=\"topp:states\" />\n</wfs:GetFeature>\n
              "},{"location":"extensions/excel/#limitations","title":"Limitations","text":"

              Excel 97-2003 files are stored in a binary format and are thus space-efficient, but have inherent size limitations (65,526 rows per sheet; 256 columns per sheet).

              Excel 2007 files are XML-based, and have much higher limits (1,048,576 rows per sheet; 16,384 columns per sheet). However, because they are text files Excel 2007 files are usually larger than Excel 97-2003 files.

              If the number of rows in a sheet or characters in a cell exceeds the limits of the chosen Excel file format, warning text is inserted to indicate the truncation.

              "},{"location":"extensions/ogr/","title":"OGR based WFS Output Format","text":"

              The ogr2ogr based output format leverages the availability of the ogr2ogr command to allow the generation of more output formats than GeoServer can natively produce. The basics idea is to dump to the file system a file that ogr2ogr can translate, invoke it, zip and return the output of the translation.

              "},{"location":"extensions/ogr/#out-of-the-box-behaviour","title":"Out of the box behaviour","text":"

              Out of the box the plugin assumes the following:

              • ogr2ogr is available in the path
              • the GDAL_DATA variable is pointing to the GDAL data directory (which stores the spatial reference information for GDAL)

              In the default configuration the following formats are supported:

              • MapInfo in TAB format
              • MapInfo in MIF format
              • Un-styled KML
              • CSV (without geometry data dumps)

              The list might be shorter if ogr2ogr has not been built with support for the above formats.

              Once installed in GeoServer four new GetFeature output formats will be available, in particular, OGR-TAB, OGR-MIF, OGR-KML, OGR-CSV.

              "},{"location":"extensions/ogr/#ogr2ogr-conversion-abilities","title":"ogr2ogr conversion abilities","text":"

              The ogr2ogr utility is usually able to convert more formats than the default setup of this output format allows for, but the exact list depends on how the utility was built from sources. To get a full list of the formats available by your ogr2ogr build just run:

              ogr2ogr --help\n

              and you'll get the full set of options usable by the program, along with the supported formats. For example, the above produces the following output using the FWTools 2.2.8 distribution (which includes ogr2ogr among other useful information and conversion tools):

              Usage: ogr2ogr [--help-general] [-skipfailures] [-append] [-update] [-gt n]\n            [-select field_list] [-where restricted_where] \n            [-sql <sql statement>] \n            [-spat xmin ymin xmax ymax] [-preserve_fid] [-fid FID]\n            [-a_srs srs_def] [-t_srs srs_def] [-s_srs srs_def]\n            [-f format_name] [-overwrite] [[-dsco NAME=VALUE] ...]\n            [-segmentize max_dist]\n            dst_datasource_name src_datasource_name\n            [-lco NAME=VALUE] [-nln name] [-nlt type] [layer [layer ...]]\n\n-f format_name: output file format name, possible values are:\n  -f \"ESRI Shapefile\"\n  -f \"MapInfo File\"\n  -f \"TIGER\"\n  -f \"S57\"\n  -f \"DGN\"\n  -f \"Memory\"\n  -f \"BNA\"\n  -f \"CSV\"\n  -f \"GML\"\n  -f \"GPX\"\n  -f \"KML\"\n  -f \"GeoJSON\"\n  -f \"Interlis 1\"\n  -f \"Interlis 2\"\n  -f \"GMT\"\n  -f \"SQLite\"\n  -f \"ODBC\"\n  -f \"PostgreSQL\"\n  -f \"MySQL\"\n  -f \"Geoconcept\"\n-append: Append to existing layer instead of creating new if it exists\n-overwrite: delete the output layer and recreate it empty\n-update: Open existing output datasource in update mode\n-select field_list: Comma-delimited list of fields from input layer to\n                    copy to the new layer (defaults to all)\n-where restricted_where: Attribute query (like SQL WHERE)\n-sql statement: Execute given SQL statement and save result.\n-skipfailures: skip features or layers that fail to convert\n-gt n: group n features per transaction (default 200)\n-spat xmin ymin xmax ymax: spatial query extents\n-segmentize max_dist: maximum distance between 2 nodes.\n                      Used to create intermediate points\n-dsco NAME=VALUE: Dataset creation option (format specific)\n-lco  NAME=VALUE: Layer creation option (format specific)\n-nln name: Assign an alternate name to the new layer\n-nlt type: Force a geometry type for new layer.  One of NONE, GEOMETRY,\n     POINT, LINESTRING, POLYGON, GEOMETRYCOLLECTION, MULTIPOINT,\n     MULTIPOLYGON, or MULTILINESTRING.  Add \"25D\" for 3D layers.\n     Default is type of source layer.\n-a_srs srs_def: Assign an output SRS\n-t_srs srs_def: Reproject/transform to this SRS on output\n-s_srs srs_def: Override source SRS\n\nSrs_def can be a full WKT definition (hard to escape properly),\nor a well known definition (ie. EPSG:4326) or a file with a WKT\ndefinition.\n

              The full list of formats that ogr2ogr is able to support is available on the OGR site. Mind that this output format can handle only outputs that are file based and that do support creation. So, for example, you won't be able to use the Postgres output (since it's database based) or the ArcInfo binary coverage (creation not supported).

              "},{"location":"extensions/ogr/#customisation","title":"Customisation","text":"

              If ogr2ogr is not available in the default path, the GDAL_DATA is not set, or if the output formats needs tweaking, a ogr2ogr.xml file can be put in the root of the GeoServer data directory to customize the output format.

              The default GeoServer configuration is equivalent to the following xml file:

              <OgrConfiguration>\n  <ogr2ogrLocation>ogr2ogr</ogr2ogrLocation>\n  <!-- <gdalData>...</gdalData> -->\n  <formats>\n    <Format>\n      <ogrFormat>MapInfo File</ogrFormat>\n      <formatName>OGR-TAB</formatName>\n      <fileExtension>.tab</fileExtension>\n    </Format>\n    <Format>\n      <ogrFormat>MapInfo File</ogrFormat>\n      <formatName>OGR-MIF</formatName>\n      <fileExtension>.mif</fileExtension>\n      <option>-dsco</option>\n      <option>FORMAT=MIF</option>\n    </Format>\n    <Format>\n      <ogrFormat>CSV</ogrFormat>\n      <formatName>OGR-CSV</formatName>\n      <fileExtension>.csv</fileExtension>\n      <singleFile>true</singleFile>\n      <mimeType>text/csv</mimeType>\n    </Format>\n    <Format>\n      <ogrFormat>KML</ogrFormat>\n      <formatName>OGR-KML</formatName>\n      <fileExtension>.kml</fileExtension>\n      <singleFile>true</singleFile>\n      <mimeType>application/vnd.google-earth.kml</mimeType>\n    </Format>\n  </formats>\n</OgrConfiguration>\n

              The file showcases all possible usage of the configuration elements:

              • ogr2ogrLocation can be just ogr2ogr if the command is in the path, otherwise it should be the full path to the executable. For example, on a Windows box with FWTools installed it might be:

                <ogr2ogrLocation>c:\\Programmi\\FWTools2.2.8\\bin\\ogr2ogr.exe</ogr2ogrLocation>\n
              • gdalData must point to the GDAL data directory. For example, on a Windows box with FWTools installed it might be:

                <gdalData>c:\\Programmi\\FWTools2.2.8\\data</gdalData>\n
              • Format defines a single format, which is defined by the following tags:

                • ogrFormat: the name of the format to be passed to ogr2ogr with the -f option (it's case sensitive).
                • formatName: is the name of the output format as advertised by GeoServer
                • fileExtension: is the extension of the file generated after the translation, if any (can be omitted)
                • option: can be used to add one or more options to the ogr2ogr command line. As you can see by the MIF example, each item must be contained in its own tag. You can get a full list of options by running ogr2ogr --help or by visiting the ogr2ogr web page. Also consider that each format supports specific creation options, listed in the description page for each format (for example, here is the MapInfo one).
                • singleFile (since 2.0.3): if true the output of the conversion is supposed to be a single file that can be streamed directly back without the need to wrap it into a zip file
                • mimeType (since 2.0.3): the mime type of the file returned when using singleFile. If not specified application/octet-stream will be used as a default.
              "},{"location":"extensions/ogr/#ogr-based-wps-output-format","title":"OGR based WPS Output Format","text":"

              The OGR based WPS output format provides the ability to turn feature collection (vector layer) output types into formats supported by OGR, using the same configuration and same machinery provided by the OGR WFS output format (which should also be installed for the WPS portion to work).

              Unlike the WFS case the WPS output formats are receiving different treatment in WPS responses depending on whether they are binary, text, or xml, when the Execute response style chosen by the client is \"document\":

              • Binary types need to be base64 encoded for XML embedding
              • Text types need to be included inside a CDATA section
              • XML types can be integrated in the response as-is

              In order to understand the nature of the output format a new optional configuration element, <type>, can be added to the ogr2ogr.xml configuration file in order to specify the output nature. The possible values are binary, text, xml, in case the value is missing, binary is assumed. Here is an example showing all possible combinations:

              <OgrConfiguration>\n    <ogr2ogrLocation>ogr2ogr</ogr2ogrLocation>\n    <!-- <gdalData>...</gdalData> -->\n    <formats>\n        <Format>\n            <ogrFormat>MapInfo File</ogrFormat>\n            <formatName>OGR-TAB</formatName>\n            <fileExtension>.tab</fileExtension>\n            <type>binary</type> <!-- not really required, it\u2019s the default -->\n        </Format>\n        <Format>\n            <ogrFormat>MapInfo File</ogrFormat>\n            <formatName>OGR-MIF</formatName>\n            <fileExtension>.mif</fileExtension>\n            <option>-dsco</option>\n            <option>FORMAT=MIF</option>\n        </Format>\n        <Format>\n            <ogrFormat>CSV</ogrFormat>\n            <formatName>OGR-CSV</formatName>\n            <fileExtension>.csv</fileExtension>\n            <singleFile>true</singleFile>\n            <mimeType>text/csv</mimeType>\n            <option>-lco</option>\n            <option>GEOMETRY=AS_WKT</option>\n            <type>text</type>\n        </Format>\n        <Format>\n            <ogrFormat>KML</ogrFormat>\n            <formatName>OGR-KML</formatName>\n            <fileExtension>.kml</fileExtension>\n            <singleFile>true</singleFile>\n            <mimeType>application/vnd.google-earth.kml</mimeType>\n            <type>xml</type>\n        </Format>\n    </formats>\n</OgrConfiguration>\n
              "},{"location":"extensions/authkey/","title":"Key authentication module","text":"

              The authkey module for GeoServer allows for a very simple authentication protocol designed for OGC clients that cannot handle any kind of security protocol, not even the HTTP basic authentication.

              For these clients the module allows a minimal form of authentication by appending a unique key in the URL that is used as the sole authentication token. Obviously this approach is open to security token sniffing and must always be associated with the use of HTTPS connections.

              A sample authenticated request looks like:

              http://localhost:8080/geoserver/topp/wms?service=WMS&version=1.3.0&request=GetCapabilities&authkey=ef18d7e7-963b-470f-9230-c7f9de166888\n

              Where authkey=ef18d7e7-963b-470f-9230-c7f9de166888 is associated to a specific user (more on this later). The capabilities document contains backlinks to the server itself, linking to the URLs that can be used to perform GetMap, GetFeatureInfo and so on. When the authkey parameter is provided the backlinks will contain the authentication key as well, allowing any compliant WMS client to access secured resources.

              "},{"location":"extensions/authkey/#limitations","title":"Limitations","text":"

              The authkey module is meant to be used with OGC services. It won't work properly against the administration GUI, nor RESTConfig.

              The authkey module replaces the default basic authentication provider, therefore when editing a user the Enabled checkbox does not affect the authkey provider and you cannot disable users this way.

              "},{"location":"extensions/authkey/#key-providers","title":"Key providers","text":"

              Key providers are responsible for mapping the authentication keys to a user. The authentication key itself is a UUID (Universally Unique IDentifier (UUID)). A key provider needs a user/group service and it is responsible for synchronizing the authentication keys with the users contained in this service.

              "},{"location":"extensions/authkey/#key-provider-using-user-properties","title":"Key provider using user properties","text":"

              This key provider uses a user property UUID to map the authentication key to the user. User properties are stored in the user/group service. Synchronizing is simple since the logic has to search for users not having the property UUID and add it. The property value is a generated UUID.

              UUID=b52d2068-0a9b-45d7-aacc-144d16322018

              If the user/group service is read only, the property has to be added from outside, no synchronizing is possible.

              "},{"location":"extensions/authkey/#key-provider-using-a-property-file","title":"Key provider using a property file","text":"

              This key provider uses a property file named authkeys.properties. The default user/group service is named default. The authkeys.properties for this service would be located at

              $GEOSERVER_DATA_DIR/security/usergroup/default/authkeys.propeties

              A sample file looks as follows:

              # Format is authkey=username\nb52d2068-0a9b-45d7-aacc-144d16322018=admin\n1825efd3-20e1-4c18-9648-62c97d3ee5cb=sf\nef18d7e7-963b-470f-9230-c7f9de166888=topp\n

              This key provider also works for read only user/group services. Synchronizing adds new users not having an entry in this file and removes entries for users deleted in the user/group service.

              "},{"location":"extensions/authkey/#key-provider-using-an-external-web-service","title":"Key provider using an external web service","text":"

              This key provider calls an external URL to map the authentication key to the user. This allows GeoServer to integrate into an existing security infrastructure, where a session token is shared among applications and managed through dedicated web services.

              The web service URL and some other parameters can be specified to configure the mapper in detail:

              Option Description

              Web Service URL, with key placeholder the complete URL of the key mapping webservice, with a special placeholder ({key}) that will be replaced by the current authentication key

              Web Service Response User Search Regular Expression a regular expression used to extract the username from the webservice response; the first matched group (the part included in parentheses) in the regular expression will be used as the username; the default (\\^\\s(.)\\s*\\$) takes all the response text, trimming spaces at both ends

              Connection Timeout timeout to connect to the webservice

              Read Timeout timeout to read data from the webservice

              The mapper will call the webservice using an HTTP GET request (webservice requiring POST are not supported yet), replacing the {key} placeholder in the configured URL with the actual authentication key.

              If a response is received, it is parsed using the configured regular expression to extract the username from it. New lines are automatically stripped from the response. Some examples of regular expression that can be used are:

              Regular Expression Usage

              ^\\s*(.*)\\s*$ all text trimming spaces at both ends

              ^.*?\"user\"\\s*:\\s*\"([^\"]+)\".*$ json response where the username is contained in a property named user

              ^.*?<username>(.*?)</username>.*$ xml response where the username is contained in a tag named username

              Synchronizing users with the user/group service means clearing the current Security context cache. The keys cached in memory will be removed and re-created at the next call.

              "},{"location":"extensions/authkey/#authkey-webservice-body-response-usergroup-service","title":"AuthKEY WebService Body Response UserGroup Service","text":"

              When using an external web service to get Auth details, it is possible to define a custom GeoServer UserGroup Service being able to fetch Authorities - aka user's Roles - from the HTTP Body Response.

              The rationale is mostly the same; that kind of GeoServer UserGroup Service will apply a rolesRegex - Roles Regular Expression - to the body response - which can be either XML, JSON or Plain Text/HTML - in order to fetch the list of available Authorities.

              In order to do this, it is possible to configure instances of AuthKEY WebService Body Response User Group Service.

              First thing to do is to:

              1. Login as an Administrator

              2. Move to Security > Users, Groups, Roles and select Add new from User Group Services

              3. Click on AuthKEY WebService Body Response

              4. Provide a Name and select anything you want from Passwords - those won't be used by this service, but they are still mandatory for GeoServer -

              5. Provide a suitable Roles Regex to apply to your Web Service Response

              ::: note ::: title Note :::

              This is the only real mandatory value to provide. The others are optional and will allow you to customize the User Group Service behavior (see below) :::

              Once the new GeoServer UserGroup Service has been configured, it can be easily linked to the Key Provider Web Service Mapper.

              1. From Authentication > Authentication Filters, select - or add new - AuthKEY using Web Service as key mapper

              2. Select the newly defined UserGroup Service and save

              Additional Options

              1. Optional static comma-separated list of available Groups from the Web Service response

                It is worth notice that this UserGroup Service will always translate fetched Roles in the form ROLE_<ROLENAME>

                As an instance, if the Roles Regular Expression will match something like:

                my_user_role1, another_custom_user_role, role_External_Role_X\n

                this will be converted into 3 different GeoServer User Roles named as:

                ROLE_MY_USER_ROLE1\nROLE_ANOTHER_CUSTOM_USER_ROLE\nROLE_EXTERNAL_ROLE_X\n

                Of course the role names are known only at runtime; nevertheless it is possible to statically specify associated GeoServer User Groups to be mapped later to other internal GeoServer User Roles.

                What does this mean? A GeoServer User Group can be defined on the GeoServer Catalog and can be mapped by the active Role Services to one or more specific GeoServer User Roles.

                This mainly depends on the GeoServer Role Service you use. By default, the internal GeoServer Role Service can map Roles and Groups through static configuration stored on the GeoServer Data Dir. This is possible by editing GeoServer User Group details from the Users, Groups, and Roles panel

                Now, this custom UserGroup Service maps dynamically GeoServer User Role to GeoServer User Group as follows:

                ROLE_MY_USER_ROLE1              <> GROUP_MY_USER_ROLE1\nROLE_ANOTHER_CUSTOM_USER_ROLE   <> GROUP_ANOTHER_CUSTOM_USER_ROLE\nROLE_EXTERNAL_ROLE_X            <> GROUP_EXTERNAL_ROLE_X\n

                In order to be able to assign any GeoServer User Group to other internal GeoServer User Roles, since those are known only at runtime, the UserGroup Service allows us to statically specify the GeoServer User Groups the Web Service can use; this possible by setting the Optional static comma-separated list of available Groups from the Web Service response option:

                Once this is correctly configured, it will be possible to edit and assign GeoServer User Roles to the Groups by using the standard way

              2. Role Service to use

              By default, if no Role Service specified, the UserGroup Service will use the GeoServer Active Role Service to resolve GeoServer User Roles from GeoServer User Groups - as specified above -

              It is possible to define a Custom Role Service to use instead, to resole GeoServer User Roles; this is possible simply by selecting the Role Service to use from the Role Service to use option

              "},{"location":"extensions/authkey/#configuration","title":"Configuration","text":"

              Configuration can be done using the administrator GUI. There is a new type of authentication filter named authkey offering the following options.

              1. URL parameter name. This the name of URL parameter used in client HTTP requests. Default is authkey.
              2. Key Provider. GeoServer offers the providers described above.
              3. User/group service to be used.

              Some of the key providers can require additional configuration parameter. These will appear under the Key Provider combo-box when one of those is selected.

              After configuring the filter it is necessary to put this filter on the authentication filter chain(s).

              Note

              The administrator GUI for this filter has button Synchronize. Clicking on this button saves the current configuration and triggers a synchronize. If users are added/removed from the backing user/group service, the synchronize logic should be triggered.

              "},{"location":"extensions/authkey/#enabling-mappers-auto-synchronization","title":"Enabling Mappers' Auto-Synchronization","text":"

              The following check is available for all provides.

              If enabled, the service will automatically invoke the corresponding mapper synchronize method; the one associated to the current AuthKey provider.

              By default the synchronization happens every 60 seconds. In the case an administrator needs to change the auto-sync frequency, he will need to:

              1. Edit the file applicationContext.xml within the gs-authkey jar file
              2. Edit the property autoSyncDelaySeconds of the authenticationKeyProvider bean
              3. Restart GeoServer
              "},{"location":"extensions/authkey/#provider-pluggability","title":"Provider pluggability","text":"

              With some Java programming it is possible to programmatically create and register a new key to user name mapper that works under a different logic. For example, you could have daily tokens, token generators and the like.

              In order to provide your custom mapper you have to implement the org.geoserver.security.AuthenticationKeyMapper interface and then register said bean in the Spring application context. Alternatively it is possible to subclass from org.geoserver.security.AbstractAuthenticationKeyMapper. A mapper (key provider) has to implement

              /**\n * \n * Maps a unique authentication key to a username. Since usernames are\n * unique within a {@link GeoServerUserGroupService} an individual mapper\n * is needed for each service offering this feature.\n * \n * @author Andrea Aime - GeoSolution\n */\npublic interface AuthenticationKeyMapper extends BeanNameAware {\n\n    /**\n     * Maps the key provided in the request to the {@link GeoServerUser} object\n     * of the corresponding user, or returns null\n     * if no corresponding user is found\n     * \n     * Returns <code>null</code> if the user is disabled\n     * \n     * @param key\n     * @return\n     */\n    GeoServerUser getUser(String key) throws IOException;\n\n    /**\n     * Assures that each user in the corresponding {@link GeoServerUserGroupService} has\n     * an authentication key.\n     * \n     * returns the number of added authentication keys\n     * \n     * @throws IOException\n     */\n    int synchronize() throws IOException;\n\n    /**\n     * Returns <code>true</code> it the mapper can deal with read only u \n     * user/group services\n     * \n     * @return \n     */\n    boolean supportsReadOnlyUserGroupService();\n\n    String getBeanName();\n\n    void setUserGroupServiceName(String serviceName);\n    String getUserGroupServiceName();\n\n    public GeoServerSecurityManager getSecurityManager();\n    public void setSecurityManager(GeoServerSecurityManager securityManager);\n\n }\n

              The mapper would have to be registered in the Spring application context in a applicationContext.xml file in the root of your jar. Example for an implementation named com.mycompany.security.SuperpowersMapper:

              <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<!DOCTYPE beans PUBLIC \"-//SPRING//DTD BEAN//EN\" \"http://www.springframework.org/dtd/spring-beans.dtd\">\n<beans>\n  <bean id=\"superpowersMapper\" class=\"com.mycompany.security.SuperpowersMapper\"/>\n</beans>\n

              At this point you can drop the authkey jar along with your custom mapper jar and use it in the administrator GUI of the authentication key filter.

              "},{"location":"extensions/cas/","title":"CAS integration","text":"

              The CAS module allows to integrate GeoServer with the Central Authentication Service (CAS) Single Sign On (SSO), in particular, using standard tickets and proxy tickets.

              "},{"location":"extensions/cas/#installation","title":"Installation","text":"

              To install the CAS module:

              1. Visit the website download page, locate your release, and download: cas

                The download link will be in the Extensions section under Security.

                Warning

                Ensure to match plugin (example 2.24.2 above) version to the version of the GeoServer instance.

              1. Extract the files in this archive to the WEB-INF/lib directory of your GeoServer installation.
              2. Restart GeoServer
              "},{"location":"extensions/cas/#configuration","title":"Configuration","text":"

              The CAS integration is a authentication filter module, hence in order to use it one has to:

              • Go to the authentication page, add the CAS filter and configure it
              • Add it to the authentication chains, taking care of removing the other authentication methods (or the CAS authentication won't trigger and redirect users to the CAS login page)

              This page serves as a reference for configuration options, but a step by step tutorial is also available, see Authentication with CAS.

              Key Description

              Name Name of the filter

              CAS server URL including context root The CAS server location (GeoServer will redirect to it, for example, in order to login, adding the necessary extra path elements)

              No single sign on If checkecd, will send the \"renew=true\" options to the CAS server, forcing the user to login on the server at each request (unless session creation is allowed)

              Participate in single sign out Whether GeoServer should receive and handle callbacks for Single Sign Out.

              URL in CAS loutput page CAS logout page location

              Proxy callback URL The URL CAS will call back to after proxy ticket authentication

              Role source A choice of role sources for the user authenticated via CAS

              Specifically for the role source, the following options are available:

              Source Description

              User group service Locate the user in a the specified user group service, extract the roles from it.

              Role service Locate user roles from the specified role service

              Header attribute Look up the roles in the specified HTTP header of the CAS response

              Custom CAS attribute Extract the roles from a CAS custom attribute in the <cas:serviceResponse> received from the server. The attributes must be configured, on the CAS side, via an attribute repository, and then released for publication in service configuration.

              "},{"location":"extensions/cas/#example-cas-configuration","title":"Example CAS configuration","text":"

              In order to use the CAS custom attributes the server must be configured to extract the attributes from a given attribute repository, and then allow their release in the GeoServer service configuration.

              For example, the following cas.properties file sets up a JDBC user source, as well as JDBC attribute repository (this configuration file might useful for testing purposes, but not setup for production):

              cas.server.name=https://localhost:8443\ncas.server.prefix=${cas.server.name}/cas\nserver.ssl.key-store=file:/etc/cas/config/thekeystore\nserver.ssl.key-store-password=changeit\nlogging.config=file:/etc/cas/config/log4j2.xml\n# cas.authn.accept.users=\n\ncas.authn.jdbc.query[0].driver-class=org.postgresql.Driver\ncas.authn.jdbc.query[0].url=jdbc:postgresql://localhost:5432/cas_users\ncas.authn.jdbc.query[0].dialect=org.hibernate.dialect.PostgreSQL95Dialect\ncas.authn.jdbc.query[0].driver-class=org.postgresql.Driver\ncas.authn.jdbc.query[0].user=theDbUser\ncas.authn.jdbc.query[0].password=theDbPassword\ncas.authn.jdbc.query[0].sql=SELECT * FROM users WHERE email = ?\ncas.authn.jdbc.query[0].password-encoder.type=BCRYPT\ncas.authn.jdbc.query[0].field-password=password\ncas.authn.jdbc.query[0].field-expired=expired\ncas.authn.jdbc.query[0].field-disabled=disabled\n\n\ncas.authn.attributeRepository.jdbc[0].driver-class=org.postgresql.Driver\ncas.authn.attributeRepository.jdbc[0].url=jdbc:postgresql://localhost:5432/cas_users\ncas.authn.attributeRepository.jdbc[0].dialect=org.hibernate.dialect.PostgreSQL95Dialect\ncas.authn.attributeRepository.jdbc[0].driver-class=org.postgresql.Driver\ncas.authn.attributeRepository.jdbc[0].user=theDbUser\ncas.authn.attributeRepository.jdbc[0].password=theDbPassword\ncas.authn.attributeRepository.jdbc[0].attributes.role=role\ncas.authn.attributeRepository.jdbc[0].singleRow=false\ncas.authn.attributeRepository.jdbc[0].columnMappings.attribute=value\ncas.authn.attributeRepository.jdbc[0].sql=SELECT * FROM roles WHERE {0}\ncas.authn.attributeRepository.jdbc[0].username=email\n\ncas.service-registry.json.location=classpath:/services\n

              The database has the following two tables for users and roles:

              CREATE TABLE public.users (\n    id bigint NOT NULL,\n    disabled boolean,\n    email character varying(40),\n    first_name character varying(40),\n    last_name character varying(40),\n    expired boolean,\n    password character varying(100)\n);\n\nCREATE TABLE public.roles (\n    email character varying,\n    attribute character varying,\n    value character varying\n);\n

              A sample service configuration for GeoServer might look as follows (again, setup for testing and development only):

              {\n  \"@class\" : \"org.apereo.cas.services.RegexRegisteredService\",\n  \"serviceId\" : \"^http(s)?://localhost:[\\\\d]+/geoserver/.*\",\n  \"name\" : \"GeoServer\",\n  \"id\" : 1002,\n  \"logoutType\" : \"BACK_CHANNEL\",\n  \"logoutUrl\" : \"https://localhost:8442/geoserver\",\n  \"redirectUrl\" : \"https://localhost:8442/geoserver\",\n  \"proxyPolicy\" : {\n    \"@class\" : \"org.apereo.cas.services.RegexMatchingRegisteredServiceProxyPolicy\",\n    \"pattern\" : \"^http(s)?://localhost:[\\\\d]+/geoserver/.*\"\n  },\n  \"attributeReleasePolicy\" : {\n    \"@class\" : \"org.apereo.cas.services.ReturnAllAttributeReleasePolicy\"\n  }\n}\n
              "},{"location":"extensions/cas/#configuring-the-web-chain","title":"Configuring the web chain","text":"

              The CAS authentication can be included in the web filter chain, with different behavior depending on which filters are included. The following discusses three possible examples.

              As first case, let's consider having only the CAS authentication in the \"web\" filter chain:

              Since anonymous access is not allowed, any attempt to access the GeoServer web console will cause a redirect to the CAS server, for login. Once logged in, the user interface shows a button to initiate a CAS logout (the logout is shared among all examples, won't be repeated in the following text).

              A second option is to allow anonymous access in the web chain, allowing users to access the layer preview and other demo functionality without logging in:

              In this case the web console does not immediately redirect to the CAS server, but provides a CAS login button instead:

              As a final example, let's consider having both CAS and form login in the web chain:

              This allows both a CAS login, and a form based login using GeoServer local username/password. It could be useful to allow GeoServer administration while the CAS server is offline for any reason. In this case both the form login and the CAS login button appear at the same time:

              "},{"location":"extensions/controlflow/","title":"Control flow module","text":"

              The control-flow module for GeoServer allows the administrator to control the amount of concurrent requests actually executing inside the server, as well as giving an opportunity to slow down users making too many requests. This kind of control is useful for a number of reasons:

              • Performance: tests show that, with local data sources, the maximum throughput in GetMap requests is achieved when allowing at most 2 times the number of CPU cores requests to run in parallel.
              • Resource control: requests such as GetMap can use a significant amount of memory. The WMS request limits<wms_configuration_limits> allow to control the amount of memory used per request, but an OutOfMemoryError is still possible if too many requests run in parallel. By controlling also the amount of requests executing it's possible to limit the total amount of memory used below the memory that was actually given to the Java Virtual Machine.
              • Fairness: a single user should not be able to overwhelm the server with a lot of requests, leaving other users with tiny slices of the overall processing power.

              The control flow method does not normally reject requests, it just queues up those in excess and executes them late. However, it's possible to configure the module to reject requests that have been waited in queue for too long.

              "},{"location":"extensions/controlflow/#installation","title":"Installation","text":"
              1. Visit the website download page, locate your release, and download: control-flow

                Warning

                Ensure to match plugin (example 2.24.2 above) version to the version of the GeoServer instance.

              1. Extract the files in this archive to the WEB-INF/lib directory of your GeoServer installation.
              2. Restart GeoServer
              "},{"location":"extensions/controlflow/#rule-syntax-reference","title":"Rule syntax reference","text":"

              The current implementation of the control flow module reads its rules from a controlflow.properties property file located in the GeoServer data directory.

              "},{"location":"extensions/controlflow/#total-ows-request-count","title":"Total OWS request count","text":"

              The global number of OWS requests executing in parallel can be specified with:

              ows.global=<count>\n

              Every request in excess will be queued and executed when other requests complete leaving some free execution slot.

              "},{"location":"extensions/controlflow/#per-request-control","title":"Per request control","text":"

              A per request type control can be demanded using the following syntax:

              ows.<service>[.<request>[.<outputFormat>]]=<count>\n

              Where:

              • <service> is the OWS service in question (at the time of writing can be wms, wfs, wcs)
              • <request>, optional, is the request type. For example, for the wms service it can be GetMap, GetFeatureInfo, DescribeLayer, GetLegendGraphics, GetCapabilities
              • <outputFormat>, optional, is the output format of the request. For example, for the wms GetMap request it could be image/png, image/gif and so on

              A few examples:

              # don't allow more than 16 WCS requests in parallel\nows.wcs=16\n# don't allow more than 8 GetMap requests in parallel\nows.wms.getmap=8\n# don't allow more than 2 WFS GetFeature requests with Excel output format\nows.wfs.getfeature.application/msexcel=2\n
              "},{"location":"extensions/controlflow/#request-priority-support","title":"Request priority support","text":"

              Requests controlled by \"ows.*\" controllers above can be also executed in priority order, in case there are too many the request will block and wait, and will we awoken in priority order (highest to lowest).

              Currently the only way to specific a priority for a request is to add it to a request HTTP header:

              ows.priority.http=<headerName>,<defaultPriority>\n

              The header \"headerName\" will contain a number defining the priority for the request, the default priority is used as a fallback if/when the header is not found.

              Using a header implies some other system is involved in the priority management. This is particularly good when using a load balancer, as the requests priorities need to be evenly split across cluster elements, control-flow only has visibility of a single instance. As an example, the priority will be de facto ignored at the cluster level if there are two nodes, and for whatever chance or design, the high priority requests end up converging on the same cluster node.

              "},{"location":"extensions/controlflow/#per-user-concurrency-control","title":"Per user concurrency control","text":"

              There are two mechanisms to identify user requests. The first one is cookie based, so it will work fine for browsers but not as much for other kinds of clients. The second one is ip based, which works for any type of client but that can limit all the users sitting behind the same router

              This avoids a single user (as identified by a cookie) to make too many requests in parallel:

              user=<count>\n

              Where <count> is the maximum number of requests a single user can execute in parallel.

              The following avoids a single ip address from making too many requests in parallel:

              ip=<count>\n

              Where <count> is the maximum number of requests a single ip address can execute in parallel.

              It is also possible to make this a bit more specific and throttle a single ip address instead by using the following:

              ip.<ip_addr>=<count>\n

              Where <count> is the maximum number of requests the ip specified in <ip_addr> will execute in parallel.

              To reject requests from a list of ip addresses:

              ip.blacklist=<ip_addr1>,<ip_addr2>,...\n
              "},{"location":"extensions/controlflow/#per-user-rate-control","title":"Per user rate control","text":"

              The rate control rules allow to setup the maximum number of requests per unit of time, based either on a cookie or IP address. These rules look as follows (see \"Per user concurrency control\" for the meaning of \"user\" and \"ip\"):

              user.ows[.<service>[.<request>[.<outputFormat>]]]=<requests>/<unit>[;<delay>s]\nip.ows[.<service>[.<request>[.<outputFormat>]]]=<requests>/<unit>[;<delay>s]\n

              Where:

              • <service> is the OWS service in question (at the time of writing can be wms, wfs, wcs)
              • <request>, optional, is the request type. For example, for the wms service it can be GetMap, GetFeatureInfo, DescribeLayer, GetLegendGraphics, GetCapabilities
              • <outputFormat>, optional, is the output format of the request. For example, for the wms GetMap request it could be image/png, image/gif and so on
              • <requests> is the number of requests in the unit of time
              • <unit> is the unit of time, can be \"s\", \"m\", \"h\", \"d\" (second, minute, hour and day respectively).
              • <delay> is an optional the delay applied to the requests that exceed the maximum number of requests in the current time slot. If not specified, once the limit is exceeded a immediate failure response with HTTP code 429 (\"Too many requests\") will be sent back to the caller.

              The following rule will allow 1000 WPS Execute requests a day, and delay each one in excess by 30 seconds:

              user.ows.wps.execute=1000/d;30s\n

              The following rule will instead allow up to 30 GetMap requests a second, but will immediately fail any request exceeding the cap:

              user.ows.wms.getmap=30/s\n

              In both cases headers informing the user of the request rate control will be added to the HTTP response. For example:

              X-Rate-Limit-Context: Any OGC request\nX-Rate-Limit-Limit: 10\nX-Rate-Limit-Remaining: 9\nX-Rate-Limit-Reset: 1103919616\nX-Rate-Limit-Action: Delay excess requests 1000ms\n

              In case several rate control rules apply to a single request, a batch of headers will be added to the response for each of them, it is thus advised to avoid adding too many of these rules in parallel

              Where:

              • X-Rate-Limit-Context is the type of request being subject to control
              • X-Rate-Limit-Limit is the total amount of requests allowed in the control interval
              • X-Rate-Limit-Remaining is the number of remaining requests allowed before the rate control kicks in
              • X-Rate-Limit-Reset is the Unix epoch at which the new control interval will begin
              • X-Rate-Limit-Action specifies what action is taken on requests exceeding the rate control
              "},{"location":"extensions/controlflow/#timeout","title":"Timeout","text":"

              A request timeout is specified with the following syntax:

              timeout=<seconds>\n

              where <seconds> is the number of seconds a request can stay queued waiting for execution. If the request does not enter execution before the timeout expires it will be rejected.

              "},{"location":"extensions/controlflow/#throttling-tile-requests-wms-c-tms-wmts","title":"Throttling tile requests (WMS-C, TMS, WMTS)","text":"

              GeoWebCache contributes three cached tiles services to GeoServer: WMS-C, TMS, and WMTS. It is also possible to use the Control flow module to throttle them, by adding the following rule to the configuration file:

              ows.gwc=<count>\n

              Where <count> is the maximum number of concurrent tile requests that will be delivered by GeoWebCache at any given time.

              Note also that tile request are sensitive to the other rules (user based, ip based, timeout, etc).

              "},{"location":"extensions/controlflow/#a-complete-example","title":"A complete example","text":"

              Assuming the server we want to protect has 4 cores a sample configuration could be:

              # if a request waits in queue for more than 60 seconds it's not worth\n# executing, the client will  likely have given up by then\ntimeout=60\n\n# don't allow the execution of more than 100 requests total in parallel\nows.global=100\n\n# don't allow more than 10 GetMap in parallel\nows.wms.getmap=10\n\n# don't allow more than 4 outputs with Excel output as it's memory bound\nows.wfs.getfeature.application/msexcel=4\n\n# don't allow a single user to perform more than 6 requests in parallel\n# (6 being the Firefox default concurrency level at the time of writing)\nuser=6\n\n# don't allow the execution of more than 16 tile requests in parallel\n# (assuming a server with 4 cores, GWC empirical tests show that throughput\n# peaks up at 4 x number of cores. Adjust as appropriate to your system)\nows.gwc=16\n
              "},{"location":"extensions/csw-iso/","title":"Catalog Services for the Web (CSW) - ISO Metadata Profile","text":"

              This section discusses the Catalog Services for Web (CSW) ISO Metadata Profile extension. With this community module on top of the general Catalog Services for the Web (CSW) extension, GeoServer supports the ISO Metadata Profile as an additional scheme for the CSW service.

              • Installing Catalog Services for Web (CSW) - ISO Metadata Profile
              • CSW ISO Metadata Profile Mapping File
              • Catalog Services for the Web (CSW) ISO Metadata tutorial
              "},{"location":"extensions/csw-iso/installing/","title":"Installing Catalog Services for Web (CSW) - ISO Metadata Profile","text":"

              To install the CSW ISO extension:

              1. Visit the GeoServer download page and navigate to the download page for the version of GeoServer your are using. If you do not have the CSW extension yet, get it first. Both the csw and csw-iso downloads are listed under extensions. The file needed are geoserver-*-csw-plugin.zip (if necessary) and geoserver-*-SNAPSHOT-csw-iso-plugin.zip, where * matches the version number of GeoServer you are using.
              2. Extract these zip files and place all the JARs in WEB-INF/lib.
              3. Perform any configuration required by your servlet container, and then restart.
              4. Verify that the CSW module was installed correctly by going to the Welcome page of the Web administration interface and seeing that CSW is listed in the Service Capabilities list. Open the CSW capabilities and search for the text gmd:MD_Metadata to verify that the ISO metadata profile was installed correctly.
              "},{"location":"extensions/csw-iso/mapping/","title":"CSW ISO Metadata Profile Mapping File","text":""},{"location":"extensions/csw-iso/mapping/#general","title":"General","text":"

              See Mapping Files for basic information on the CSW mapping file. The ISO Metadata mapping can be found in the file csw/MD_Metadata.properties inside the data directory.

              Below is an example of an ISO Metadata Profile Mapping File:

              @fileIdentifier.CharacterString=id\nidentificationInfo.MD_DataIdentification.citation.CI_Citation.title.CharacterString=title\nidentificationInfo.MD_DataIdentification.citation.CI_Citation.alternateTitle.CharacterString=list(description,alias,strConcat('##',title)) \nidentificationInfo.MD_DataIdentification.descriptiveKeywords.MD_Keywords.keyword.CharacterString=keywords \nidentificationInfo.MD_DataIdentification.abstract.CharacterString=abstract\n$dateStamp.Date= if_then_else ( isNull(\"metadata.date\") , 'Unknown', \"metadata.date\")\nhierarchyLevel.MD_ScopeCode.@codeListValue='http://purl.org/dc/dcmitype/Dataset'\n$contact.CI_ResponsibleParty.individualName.CharacterString=\nidentificationInfo.MD_DataIdentification.resourceConstraints[0].MD_LegalConstraints.accessConstraints.MD_RestrictionCode=\nidentificationInfo.MD_DataIdentification.resourceConstraints[1].MD_SecurityConstraints.classification.MD_ClassificationCode=\nidentificationInfo.MD_DataIdentification.citation.CI_Citation.date%.CI_Date.date.Date=lapply(\"metadata.citation-date\", if_then_else(isNull(\".\"), \"Expression/NIL\", dateFormat('YYYY-MM-dd', \".\")))\nidentificationInfo.MD_DataIdentification.descriptiveKeywords.MD_Keywords.keyword.CharacterString=list(keywords, if_then_else(equalTo(typeOf(\".\"), 'FeatureTypeInfo'), 'vector', 'raster'))\n

              The full path of each field must be specified (separated with dots). XML attributes are specified with the @ symbol, similar to the usual XML X-path notation. To avoid confusion with the identifier-symbol at the beginning of a mapping line, use @ (for an attribute that is not an identifier) or @@ (for an attribute that is also the identifier) - see the feature catatalog mapping file for an example.

              The % symbol denotes where a multi-valued mapping should be split in to multiple tags. Multiple % symbols may be used for multi-dimensional mappings - see the feature catatalog mapping file below for an example.

              Indexes with square brackets can be used to avoid merging tags that shouldn't be merged, as demonstrated above for resourceConstraints.

              To keep the result XSD compliant, the parameters dateStamp.Date and contact.CI_ResponsibleParty.individualName.CharacterString must be preceded by a $ sign to make sure that they are always included even when using property selection.

              The lapply function can be used to apply expressions to items of lists, which can be handy with multidimensional fields.

              The typeOf function (exclusive to CSW-ISO module) returns the type of the catalog item that is being processed (LayerGroupInfo, FeatureTypeInfo, CoverageInfo,...), which can be handy if you for example need to handle vector layers differently to raster layers.

              For more information on the ISO Metadata standard, please see the OGC Implementation Specification 07-045.

              "},{"location":"extensions/csw-iso/mapping/#feature-catalogs","title":"Feature Catalogs","text":"Within the ISO Metadata Profile, there is also support for Feature Catalogues that contain information about vector layer type metadata. As specified by the ISO Metadata standard these are exposed in separate records. For this purpose we have a separate mapping file::

              @@uuid=\"metadata.custom.feature-catalog/feature-catalog-uidentifier\" @id=\"metadata.custom.feature-catalog/feature-catalog-identifier\" \\$featureType.FC_FeatureType.typeName.LocalName=concatenate(\"name\", 'Type') \\$featureType.FC_FeatureType.isAbstract.Boolean='false' \\$featureType.FC_FeatureType.featureCatalogue.@uuidref=\"metadata.custom.feature-catalog/feature-catalog-identifier\" featureType.FC_FeatureType.definition.CharacterString=\"metadata.custom.feature-catalog/feature-type/feature-type-definition\" featureType.FC_FeatureType.carrierOfCharacteristics%.FC_FeatureAttribute.memberName.LocalName=\"metadata.custom.feature-catalog/feature-type/feature-attribute/name\" featureType.FC_FeatureType.carrierOfCharacteristics%.FC_FeatureAttribute.valueType.TypeName.aName.CharacterString=\"metadata.custom.feature-catalog/feature-type/feature-attribute/type\" featureType.FC_FeatureType.carrierOfCharacteristics%.FC_FeatureAttribute.length.CharacterString=\"metadata.custom.feature-catalog/feature-type/feature-attribute/length\" featureType.FC_FeatureType.carrierOfCharacteristics%.FC_FeatureAttribute.definition.CharacterString=\"metadata.custom.feature-catalog/feature-type/feature-attribute/definition\" featureType.FC_FeatureType.carrierOfCharacteristics%.FC_FeatureAttribute.cardinality.Multiplicity.range.MultiplicityRange.lower.Integer=\"metadata.custom.feature-catalog/feature-type/feature-attribute/min-occurrence\" featureType.FC_FeatureType.carrierOfCharacteristics%.FC_FeatureAttribute.cardinality.Multiplicity.range.MultiplicityRange.upper.UnlimitedInteger=\"metadata.custom.feature-catalog/feature-type/feature-attribute/max-occurrence\" featureType.FC_FeatureType.carrierOfCharacteristics%.FC_FeatureAttribute.cardinality.Multiplicity.range.MultiplicityRange.upper.UnlimitedInteger.@isInfinite=false featureType.FC_FeatureType.carrierOfCharacteristics%.FC_FeatureAttribute.listedValue%.FC_ListedValue.label.CharacterString=\"metadata.custom.feature-catalog/feature-type/feature-attribute/domain/value\" featureType.FC_FeatureType.carrierOfCharacteristics%.FC_FeatureAttribute.listedValue%.FC_ListedValue.definition.CharacterString=\"metadata.custom.feature-catalog/feature-type/feature-attribute/domain/definition\" featureType.FC_FeatureType.carrierOfCharacteristics%.FC_FeatureAttribute.listedValue%.FC_ListedValue.code.CharacterString=\"metadata.custom.feature-catalog/feature-type/feature-attribute/domain/code\"

              Only records that have a non-null identifier in the catalog mapping file will have a feature catalogue record. There is no support in the standard Geoserver GUI for user configuration of this information. The upcoming metadata community module makes this possible.

              "},{"location":"extensions/csw-iso/tutorial/","title":"Catalog Services for the Web (CSW) ISO Metadata tutorial","text":"

              This tutorial will show how to use the CSW module with the ISO Metadata Profile scheme. It assumes a fresh installation of GeoServer with the CSW ISO Metadata Profile module installed.

              "},{"location":"extensions/csw-iso/tutorial/#configuration","title":"Configuration","text":"

              In the <data_dir>/csw directory, create a new file named MD_Metadata.properties (ISO Metadata Profile mapping file) with the following contents:

              @fileIdentifier.CharacterString=prefixedName\nidentificationInfo.AbstractMD_Identification.citation.CI_Citation.title.CharacterString=title\nidentificationInfo.AbstractMD_Identification.descriptiveKeywords.MD_Keywords.keyword.CharacterString=keywords \nidentificationInfo.AbstractMD_Identification.abstract.CharacterString=abstract\n$dateStamp.Date= if_then_else ( isNull(\"metadata.date\") , 'Unknown', \"metadata.date\")\nhierarchyLevel.MD_ScopeCode.@codeListValue='http://purl.org/dc/dcmitype/Dataset'\n$contact.CI_ResponsibleParty.individualName.CharacterString='John Smith'\n
              "},{"location":"extensions/csw-iso/tutorial/#services","title":"Services","text":"

              With GeoServer running (and responding on http://localhost:8080), test GeoServer CSW in a web browser by querying the CSW capabilities as follows:

              http://localhost:8080/geoserver/csw?service=csw&version=2.0.2&request=GetCapabilities\n

              We can request a description of our Metadata record:

              http://localhost:8080/geoserver/csw?service=CSW&version=2.0.2&request=DescribeRecord&typeName=gmd:MD_Metadata\n

              This yields the following result:

              <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<csw:DescribeRecordResponse xmlns:csw=\"http://www.opengis.net/cat/csw/2.0.2\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xsi:schemaLocation=\"http://www.opengis.net/cat/csw/2.0.2 http://localhost:8080/geoserver/schemas/csw/2.0.2CSW-discovery.xsd\">\n<csw:SchemaComponent targetNamespace=\"http://www.opengis.net/cat/csw/2.0.2\" schemaLanguage=\"http://www.w3.org/XML/Schema\">\n<xs:schema xmlns:xs=\"http://www.w3.org/2001/XMLSchema\" xmlns:xlink=\"http://www.w3.org/1999/xlink\" xmlns:gco=\"http://www.isotc211.org/2005/gco\" xmlns:gmd=\"http://www.isotc211.org/2005/gmd\" targetNamespace=\"http://www.isotc211.org/2005/gmd\" elementFormDefault=\"qualified\" version=\"2012-07-13\">\n  <!-- ================================= Annotation ================================ -->\n  <xs:annotation>\n      <xs:documentation>Geographic MetaData (GMD) extensible markup language is a component of the XML Schema Implementation of Geographic Information Metadata documented in ISO/TS 19139:2007. GMD includes all the definitions of http://www.isotc211.org/2005/gmd namespace. The root document of this namespace is the file gmd.xsd. This identification.xsd schema implements the UML conceptual schema defined in A.2.2 of ISO 19115:2003. It contains the implementation of the following classes: MD_Identification, MD_BrowseGraphic, MD_DataIdentification, MD_ServiceIdentification, MD_RepresentativeFraction, MD_Usage, MD_Keywords, DS_Association, MD_AggregateInformation, MD_CharacterSetCode, MD_SpatialRepresentationTypeCode, MD_TopicCategoryCode, MD_ProgressCode, MD_KeywordTypeCode, DS_AssociationTypeCode, DS_InitiativeTypeCode, MD_ResolutionType.</xs:documentation>\n  </xs:annotation>\n  ...\n

              Query all layers as follows:

              http://localhost:8080/geoserver/csw?service=CSW&version=2.0.2&request=GetRecords&typeNames=gmd:MD_Metadata&resultType=results&elementSetName=full&outputSchema=http://www.isotc211.org/2005/gmd\n

              Request a particular layer by ID...:

              http://localhost:8080/geoserver/csw?service=CSW&version=2.0.2&request=GetRecordById&elementsetname=summary&id=CoverageInfoImpl--4a9eec43:132d48aac79:-8000&typeNames=gmd:MD_Metadata&resultType=results&elementSetName=full&outputSchema=http://www.isotc211.org/2005/gmd\n

              ...or use a filter to retrieve it by Title:

              http://localhost:8080/geoserver/csw?service=CSW&version=2.0.2&request=GetRecords&typeNames=gmd:MD_Metadata&resultType=results&elementSetName=full&outputSchema=http://www.isotc211.org/2005/gmd&constraint=Title=%27mosaic%27\n

              Either case should return:

              <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<csw:GetRecordsResponse xmlns:xml=\"http://www.w3.org/XML/1998/namespace\" xmlns=\"http://www.opengis.net/cat/csw/apiso/1.0\" xmlns:csw=\"http://www.opengis.net/cat/csw/2.0.2\" xmlns:gco=\"http://www.isotc211.org/2005/gco\" xmlns:gmd=\"http://www.isotc211.org/2005/gmd\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" version=\"2.0.2\" xsi:schemaLocation=\"http://www.opengis.net/cat/csw/2.0.2 http://localhost:8080/geoserver/schemas/csw/2.0.2/record.xsd\">\n  <csw:SearchStatus timestamp=\"2013-06-28T13:41:43.090Z\"/>\n  <csw:SearchResults numberOfRecordsMatched=\"1\" numberOfRecordsReturned=\"1\" nextRecord=\"0\" recordSchema=\"http://www.isotc211.org/2005/gmd\" elementSet=\"full\">\n<gmd:MD_Metadata>\n  <gmd:fileIdentifier>\n    <gco:CharacterString>CoverageInfoImpl--4a9eec43:132d48aac79:-8000</gco:CharacterString>\n  </gmd:fileIdentifier>\n  <gmd:dateStamp>\n    <gco:Date>Unknown</gco:Date>\n  </gmd:dateStamp>\n  <gmd:identificationInfo>\n    <gmd:MD_DataIdentification>\n      <gmd:extent>\n    <gmd:EX_Extent>\n      <gmd:geographicElement>\n        <gmd:EX_GeographicBoundingBox crs=\"urn:x-ogc:def:crs:EPSG:6.11:4326\">\n          <gmd:westBoundLongitude>36.492</gmd:westBoundLongitude>\n          <gmd:southBoundLatitude>6.346</gmd:southBoundLatitude>\n          <gmd:eastBoundLongitude>46.591</gmd:eastBoundLongitude>\n          <gmd:northBoundLatitude>20.83</gmd:northBoundLatitude>\n        </gmd:EX_GeographicBoundingBox>\n      </gmd:geographicElement>\n    </gmd:EX_Extent>\n      </gmd:extent>\n    </gmd:MD_DataIdentification>\n    <gmd:AbstractMD_Identification>\n      <gmd:citation>\n    <gmd:CI_Citation>\n      <gmd:title>\n        <gco:CharacterString>mosaic</gco:CharacterString>\n      </gmd:title>\n    </gmd:CI_Citation>\n      </gmd:citation>\n      <gmd:descriptiveKeywords>\n    <gmd:MD_Keywords>\n      <gmd:keyword>\n        <gco:CharacterString>WCS</gco:CharacterString>\n      </gmd:keyword>\n      <gmd:keyword>\n        <gco:CharacterString>ImageMosaic</gco:CharacterString>\n      </gmd:keyword>\n      <gmd:keyword>\n        <gco:CharacterString>mosaic</gco:CharacterString>\n      </gmd:keyword>\n    </gmd:MD_Keywords>\n      </gmd:descriptiveKeywords>\n    </gmd:AbstractMD_Identification>\n  </gmd:identificationInfo>\n  <gmd:contact>\n    <gmd:CI_ResponsibleParty>\n      <gmd:individualName>\n    <gco:CharacterString>John Smith</gco:CharacterString>\n      </gmd:individualName>\n    </gmd:CI_ResponsibleParty>\n  </gmd:contact>\n  <gmd:hierarchyLevel>\n    <gmd:MD_ScopeCode codeListValue=\"http://purl.org/dc/dcmitype/Dataset\"/>\n  </gmd:hierarchyLevel>\n</gmd:MD_Metadata>\n  </csw:SearchResults>\n</csw:GetRecordsResponse>\n

              We can request the domain of a property. For example, all values of \"Title\":

              http://localhost:8080/geoserver/csw?service=csw&version=2.0.2&request=GetDomain&propertyName=Title\n

              This should yield the following result:

              <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<csw:GetDomainResponse xmlns:csw=\"http://www.opengis.net/cat/csw/2.0.2\" xmlns:dc=\"http://purl.org/dc/elements/1.1/\" xmlns:dct=\"http://purl.org/dc/terms/\" xmlns:ows=\"http://www.opengis.net/ows/1.1\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xsi:schemaLocation=\"http://www.opengis.net/cat/csw/2.0.2 http://localhost:8080/geoserver/schemas/csw/2.0.2/CSW-discovery.xsd\">\n  <csw:DomainValues type=\"csw:Record\">\n  <csw:PropertyName>Title</csw:PropertyName>\n  <csw:ListOfValues>\n    <csw:Value>A sample ArcGrid file</csw:Value>\n    <csw:Value>Manhattan (NY) landmarks</csw:Value>\n    <csw:Value>Manhattan (NY) points of interest</csw:Value>\n    <csw:Value>Manhattan (NY) roads</csw:Value>\n    <csw:Value>North America sample imagery</csw:Value>\n    <csw:Value>Pk50095 is a A raster file accompanied by a spatial data file</csw:Value>\n    <csw:Value>Spearfish archeological sites</csw:Value>\n    <csw:Value>Spearfish bug locations</csw:Value>\n    <csw:Value>Spearfish restricted areas</csw:Value>\n    <csw:Value>Spearfish roads</csw:Value>\n    <csw:Value>Spearfish streams</csw:Value>\n    <csw:Value>Tasmania cities</csw:Value>\n    <csw:Value>Tasmania roads</csw:Value>\n    <csw:Value>Tasmania state boundaries</csw:Value>\n    <csw:Value>Tasmania water bodies</csw:Value>\n    <csw:Value>USA Population</csw:Value>\n    <csw:Value>World rectangle</csw:Value>\n    <csw:Value>mosaic</csw:Value>\n    <csw:Value>sfdem is a Tagged Image File Format with Geographic information</csw:Value>\n  </csw:ListOfValues>\n  </csw:DomainValues>\n</csw:GetDomainResponse>\n

              To request more than the first 10 records or for more complex queries you can use a HTTP POST request with an XML query as the request body. For example, using the maxRecords option in the following request it is possible to return the first 50 layers with \"ImageMosaic\" in a keyword:

              http://localhost:8080/geoserver/csw\n

              Postbody:

              <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<GetRecords service=\"CSW\" version=\"2.0.2\" maxRecords=\"50\" startPosition=\"1\" resultType=\"results\" outputFormat=\"application/xml\" outputSchema=\"http://www.opengis.net/cat/csw/2.0.2\" xmlns=\"http://www.opengis.net/cat/csw/2.0.2\" xmlns:csw=\"http://www.opengis.net/cat/csw/2.0.2\" xmlns:ogc=\"http://www.opengis.net/ogc\" xmlns:ows=\"http://www.opengis.net/ows\" xmlns:dc=\"http://purl.org/dc/elements/1.1/\" xmlns:dct=\"http://purl.org/dc/terms/\" xmlns:gml=\"http://www.opengis.net/gml\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xsi:schemaLocation=\"http://www.opengis.net/cat/csw/2.0.2 ../../../csw/2.0.2/CSW-discovery.xsd\">\n  <Query typeNames=\"csw:Record\">\n    <ElementSetName typeNames=\"csw:Record\">full</ElementSetName>\n    <Constraint version=\"1.1.0\">\n      <ogc:Filter>\n        <ogc:PropertyIsLike wildCard=\"%\" singleChar=\"_\" escapeChar=\"\">\n          <ogc:PropertyName>dc:subject</ogc:PropertyName>\n          <ogc:Literal>%ImageMosaic%</ogc:Literal>\n        </ogc:PropertyIsLike>\n      </ogc:Filter>\n    </Constraint>\n  </Query>\n</GetRecords>\n
              "},{"location":"extensions/dxf/","title":"DXF OutputFormat for WFS and WPS PPIO","text":"

              This extension adds two distinct functionalities to GeoServer, both related to DXF format support as an output.

              DXF is a CAD interchange format, useful to import data in several CAD systems. Being a textual format it can be easily compressed to a much smaller version, so the need for a DXF-ZIP format, for low bandwidth usage.

              There have been multiple revisions of the format, so we need to choose a \"version\" of DXF to write. The extension implements version 14, but can be easily extended (through SPI providers) to write other versions too.

              The DXF OutputFormat for WFS adds the support for two additional output formats for WFS GetFeature requests. The new formats, DXF and DXF-ZIP are associated to the \"application/dxf\" and \"application/zip\" mime type, respectively. They produce a standard DXF file or a DXF file compressed in zip format.

              The WPS PPIO adds dxf as an on output format option for WPS processes. The WPS PPIO requires the WPS extension to be installed on GeoServer.

              "},{"location":"extensions/dxf/#wfs-output-format-usage","title":"WFS Output Format usage","text":"

              Request Example:

              http://localhost:8080/geoserver/wfs?request=GetFeature&typeName=Polygons&\noutputFormat=dxf\n

              Output Example (portion):

              0\nSECTION\n2\nHEADER\n9\n$ACADVER\n1\nAC1014\n...\n0\nENDSEC\n...\n0\nSECTION\n2\nTABLES\n...  \n0\nTABLE\n2\nLAYER\n...\n0\nLAYER\n5\n2E\n330\n2\n100\nAcDbSymbolTableRecord\n100\nAcDbLayerTableRecord\n2\nPOLYGONS\n70\n   0\n62\n   7\n6\nCONTINUOUS\n0\nENDTAB\n...\n0\nENDSEC\n0\nSECTION\n2\nBLOCKS\n...\n0\nENDSEC\n0\nSECTION\n2\nENTITIES\n0\nLWPOLYLINE\n5\n927C0\n330\n1F\n100\nAcDbEntity\n8\nPOLYGONS\n100\nAcDbPolyline\n90\n   5\n70\n   1\n43\n0.0\n10\n500225.0\n20\n500025.0\n10\n500225.0\n20\n500075.0\n10\n500275.0\n20\n500050.0\n10\n500275.0\n20\n500025.0\n10\n500225.0\n20\n500025.0\n0\nENDSEC\n0\nSECTION\n2\nOBJECTS\n...\n0\nENDSEC\n0\nEOF\n

              Each single query is rendered as a layer. Geometries are encoded as entities (if simple enough to be expressed by a single DXF geometry type) or blocks (if complex, such as polygons with holes or collections).

              Some options are available to control the output generated. They are described in the following paragraphs.

              "},{"location":"extensions/dxf/#get-requests-format_options","title":"GET requests format_options","text":"The following format_options are supported:
              1. version: (number) creates a DXF in the specified version format (only 14 is currently supported)
              2. asblock: (true/false) if true, all geometries are written as blocks and then inserted as entities. If false, simple geometries are directly written as entities.
              3. colors: (comma delimited list of numbers): colors to be used for the DXF layers, in sequence. If layers are more than the specified colors, they will be reused many times. A set of default colors is used if the option is not used. Colors are AutoCad color numbers (7=white, etc.).
              4. ltypes: (comma delimited list of line type descriptors): line types to be used for the DXF layers, in sequence. If layers are more than the specified line types, they will be reused many times. If not specified, all layers will be given a solid, continuous line type. A descriptor has the following format: ![!], where is the name assigned to the line type, (optional) is a real number that tells how long is each part of the line pattern (defaults to 0.125), and is a visual description of the repeatable part of the line pattern, as a sequence of - (solid line), (dot) and _ (empty space). For example a dash-dot pattern would be expressed as --__.
              5. layers: (comma delimited list of strings) names to be assigned to the DXF layers. If specified, must contain a name for each requested query. By default a standard name will be assigned to layers.
              6. withattributes: (true/false) enables writing an extra layer with attributes from each feature, the layer has a punctual geometry, with a point in the centroid of the original feature
              7. "},{"location":"extensions/dxf/#post-options","title":"POST options","text":"

                Unfortunately, it's not currently possible to use format_options in POST requests. The only thing we chose to implement is the layers options, via the handle attribute of Query attributes. So, if specified, the layer of a Query will be named as its handle attribute. The handle attribute of the GetFeature tag can also be used to override the name of the file produced.

                "},{"location":"extensions/dxf/#wps-ppio","title":"WPS PPIO","text":"

                When the WPS PPIO module is installed, together with the WPS extension, WPS processes returning a FeatureCollection can use application/dxf or application/zip as output mime type to get a DXF (or zipped DXF) in output.

                "},{"location":"extensions/geofence/","title":"Geofence Plugin","text":"

                GeoFence offers an alternative to the GeoServer Security subsystem of GeoServer, allowing far more advanced security configurations, such as rules that combine data and service restrictions. It uses a client-server model, and this plugin only provides the client component. It must connect either to an external Geofence server, or be used in combination with the GeoServer integrated Geofence server Geofence Internal Server.

                • Installing the GeoServer GeoFence extension
                • GeoFence Admin GUI
                • GeoFence Cache REST
                "},{"location":"extensions/geofence/cache/","title":"GeoFence Cache REST","text":"

                The Geofence client cache status can be queried, and the cache cleared (invalidated) through a REST service.

                "},{"location":"extensions/geofence/cache/#requests","title":"Requests","text":""},{"location":"extensions/geofence/cache/#geofencerulecacheinfo","title":"/geofence/ruleCache/info","text":"

                Retrieve information about the geofence cache status.

                Method Action Parameters Response

                GET Retrieve information about the geofence cache status. Per cache (rules, admin rules and users) we retrieve the cache size, hits, misses, load successes, load failures, load times and evictions. --- 200 OK. Text Format.

                "},{"location":"extensions/geofence/cache/#geofencerulecacheinvalidate","title":"/geofence/ruleCache/invalidate","text":"

                Invalidate the geofence cache.

                Method Action Parameters Response

                PUT Invalidate (clear) the geofence cache --- 200 OK.

                "},{"location":"extensions/geofence/configuration/","title":"GeoFence Admin GUI","text":"

                The GeoFence Admin Page is a component of the GeoServer web interface. You can access it from the GeoServer web interface by clicking the GeoFence link, found on the left side of the screen after logging in.

                "},{"location":"extensions/geofence/configuration/#general-settings","title":"General Settings","text":"

                Configure the following settings here:

                • Geoserver instance name: the name under which this geoserver is known by the geofence server. This useful for when you use an external geofence server with multiple geoserver servers.
                • GeoServer services URL: this is how geoserver knows how to connect to the external geofence server. When using an internal geofence server, this is not configurable. For example \"http://localhost:9191/geofence/remoting/RuleReader\" for an external geofence server on localhost.
                "},{"location":"extensions/geofence/configuration/#options","title":"Options","text":"

                Configure the following settings here:

                • Allow remote and inline layers in SLD

                • Authenticated users can write

                • Use GeoServer roles to get authorizations

                  • Disabled: For each authorization request, GeoServer sends only the user info to GeoFence.

                    GeoFence will retrieve all the roles associated to the user, and will merge the permissions granted for each role.

                  • Enabled: For each authorization request, GeoServer sends to GeoFence the user info AND the roles assigned in the current request session.

                    GeoFence will retrieve all the roles associated to the user, and will only consider the requested roles that are really associated to the user.

                • Comma delimited list of mutually exclusive roles for authorization

                  • This field is mandatory when the previous option is enabled.

                    GeoServer will send to GeoFence the roles in the current request session which match the entries in this list. You can use the '' symbol to match any session role. When using \"\", you can use the format \"-ROLENAME\" to exclude one or more roles from the the session roles list.

                "},{"location":"extensions/geofence/configuration/#cache","title":"Cache","text":"

                Configure the following settings here:

                • Size of the rule cache (amount of entries)
                • Cache refresh interval (ms)
                • Cache expire interval (ms)

                Collected data about the cache can be retrieved here. Per cache (rules, admin rules and users) we retrieve the cache size, hits, misses, load successes, load failures, load times and evictions. The cache can be manually invalidated (cleared).

                "},{"location":"extensions/geofence/configuration/#basic-geoserver-configuration","title":"Basic GeoServer configuration","text":"
                • Login with the default administrative credentials admin / geoserver (or whatever you have configured before).
                • In the security panel you'll find the GeoFence link to the GeoFence security admin page
                • Open the GeoFence admin page; you'll get to this page:

                  You can notice here the information that allow the GeoFence probe inside GeoServer to communicate with the GeoFence engine:

                  • the URL that the probe shall use to communicate with GeoFence;
                  • the name (default is default-gs) this instance will use to identify itself to GeoFence. This instance name should be equal to the one we set into GeoFence.
                • Testing connection to GeoFence.

                  We already performed a connection test from GeoFence to GeoServer. Using the button Test connection we can also test that GeoServer can communicate to GeoFence. If everything is ok, you'll get this message:

                • Open the Authentication page under the Security settings:

                • Add the GeoFence authenticator and put it as the first in the list otherwise you will not be able to login as admin/admin:

                • Now that we added GeoFence as authentication provider, we'll be able to log into GeoServer using the credentials we added in GeoFence (user admin and user tiger). Try and log in using user tiger.
                "},{"location":"extensions/geofence/configuration/#testing-authorization","title":"Testing authorization","text":"
                • Logging into GeoServer as admin you will be able to see all the defined layers:
                • Logging into GeoServer as a non-admin user, the defined rules will be examined; since we defined no rules yet, the default behaviour is to deny access to all resources:
                • Get back to GeoFence, and add a rule which allows all layers in workspace tiger for user tiger; create a rule defining:

                  • user tiger
                  • instance default-gs
                  • workspace tiger (you will get a dropdown menu containing all the workspaces available in the selected instance)
                  • grant type: allow You'll get a line like this one:

                • Verify the new authorizations.

                  Since the probe caches the GeoFence responses, you may need to login again as administrator (or you may keep an admin session open in another browser) and clear the probe cache. You can do it by pressing the \"Invalidate\" button in the bottom of the GeoFence admin page:

                • Login again in GeoServer as user tiger and you will see in layer preview all the layers in the tiger workspace:

                "},{"location":"extensions/geofence/installing/","title":"Installing the GeoServer GeoFence extension","text":"

                For version 2.15 and later, use the standard procedure to install an extension.

                1. Visit the website download page, locate your release, and download: geofence

                  The download link will be in the Extensions section under Other.

                  Warning

                  Ensure to match plugin (example 2.24.2 above) version to the version of the GeoServer instance.

                2. Extract the files in this archive to the WEB-INF/lib directory of your GeoServer installation.

                3. Restart GeoServer

                "},{"location":"extensions/geofence-server/","title":"Geofence Internal Server","text":"

                This plugin runs a GeoFence server integrated internally in GeoServer. Geofence allows far more advanced security configurations than the default GeoServer Security subsystem, such as rules that combine data and service restrictions.

                In the integrated version, the users and roles service configured in geoserver are associated with the geofence rule database. The integrated geofence server can be configured using its WebGUI page or REST configuration.

                • Installing the GeoServer GeoFence Server extension
                • GeoFence Server GUI
                • GeoFence Rest API
                • AdminRules Rest API
                • Batch Rest API
                • Using the Internal GeoFence server (Tutorial)
                • Migrating old GeoFence configuration to GeoServer 2.12 and following
                "},{"location":"extensions/geofence-server/gui/","title":"GeoFence Server GUI","text":"

                The GeoFence user interface is a component of the GeoServer web interface. You can access it from the GeoServer web interface by clicking the GeoFence Data Rules link, found on the left side of the screen after logging in.

                "},{"location":"extensions/geofence-server/gui/#rules-page","title":"Rules page","text":"

                An overview of all rules is provided with priority, the rule's scope specifications (role, user, service, request, workspace and layer) and its access behaviour. The '*' symbol means that the rule applies to all possible values of that specification. Rules are always ordered by priority, but the order can be reversed by pressing the 'P' priority column header.

                A new rule can be added with the \"Add new rule\" link. Any number of rules can be deleted by selecting them and then clicking on the \"Remove selected rules\" link.

                Rule priority order can be easily on this page through the up and down arrows on the right side. Rules can be modified using the pencil symbol, which opens the rule page.

                "},{"location":"extensions/geofence-server/gui/#rule-page","title":"Rule page","text":"

                This page is displayed both when creating a new rule and modifying an existing rule.

                Priority can be changed manually by specifying a priority number. If this priority number is already occupied by another rule, this will cause that rule and all rules after it to shift one place to a lower priority.

                If using the IP Address range to limit access then on Linux (and other systems with IPv6 enabled) add the -Djava.net.preferIPv4Stack=true flag to the GeoServer startup options to make sure that the IP range matching works with IPv4 style addresses. Currently, IPv6 style address ranges are not supported by GeoFence.

                When Access type LIMIT is selected, additional options are displayed that allows the user to select the Catalog Mode and the Allowed Area (WKT) associated with this rule. The Spatial Filter Type parameter allows to define whether apply the Allowed Area filter to vector data as an Intersects or a Clip filter.

                When Access type ACCESS is selected as well as a specific layer, it becomes possible to specify the \"layer details\" in a separate tab. These make it possible to add additional filters to the layer for the rule in question. For example, the rule can alter the default style of the layer, specify which styles are available at all, which attributes are accessible for reading and/or writing, specify CQL filters for both reading and writing, specify a catalog mode, and an allowed area (WKT) filter.

                A CQL Read Filter can be setup to allow users to only access a subset of the available data.

                For example, having a daily time series layer (a Layer with time attribute/dimension), it's possible to restrict access to a given time range.

                A CQL filter to limit access to the whole 2020 year (static time range) would look as follows:

                time between 2020-01-01 and 2020-12-31\n

                A CQL filter limiting access to data older than a week (dynamic time range) would look like this instead:

                dateDifference(now(), time, 'd') > 7\n

                (see temporal-functions for more details on the date difference function)

                Allowed area can be defined in whatever SRID. Geoserver will automatically reproject it to the resource CRS when needed.

                "},{"location":"extensions/geofence-server/gui/#layer-groups","title":"Layer groups","text":"

                Layer groups are also supported. If no workspace has been specified, the layer dropdown will show global layer groups, while if a workspace is selected the workspace's layergroup will be showed together with the layers.

                The read and write filters text areas as well as the style palette in the layer details tab are disabled when the layer group is being configured.

                When a LayerGroup is request the contained resource will be handled in the following way:

                • a limit applied to the layer groups (allowed area or grant type) will be applied to all the contained layers.
                • if the access rule a contained layer is denying the access to the layer for the user requesting group, the layer will not be present in the output.
                • if the access rule of the layer has limits on its own, they will be merged in a restrictive way (intersection) with the one of the layer group if both the limits have been defined for the same role.
                • if the access rule of the layer has limits on its own, they will be merged in a permissive way (union) with the one of the layer group if both the limits have been defined for the different roles.

                When a layer contained in one or more layer group is directly accessed in the context of a WMS request, the following rules apply:

                • If any of the layer groups containing the requested resource has mode SINGLE no limits eventually defined for any of the layer groups will be applied.
                • If all the layer groups containing the requested resource have mode OPAQUE, the layer will not be visible.
                • If all the layer groups containing the resource has mode different from SINGLE and OPAQUE, the layer groups limits will be applied and merged with the one defined for the resource if present. For each layer group, the limits will be merged in a restrictive way with the ones defined for the resource if the rule was defined for the same role. On the contrary the limits will be merged with an enlargement logic, if coming from rules defined for different roles.
                "},{"location":"extensions/geofence-server/installing/","title":"Installing the GeoServer GeoFence Server extension","text":"
                1. Visit the website download page, locate your release, and download: geofence-server

                  The download link will be in the Extensions section under Other.

                  Warning

                  Ensure to match plugin (example 2.24.2 above) version to the version of the GeoServer instance.

                1. Extract the files in this archive to the WEB-INF/lib directory of your GeoServer installation.

                  ::: note ::: title Note :::

                  By default GeoFence will store this data in a H2 database and the database schema will be automatically managed by Hibernate.

                  The GeoFence documentation explains how to configure a different backed database and configure Hibernate behavior. :::

                2. Add the following system variable among the JVM startup options (location varies depending on installation type): -Dgwc.context.suffix=gwc

                3. Restart GeoServer

                "},{"location":"extensions/geofence-server/migration/","title":"Migrating old GeoFence configuration to GeoServer 2.12 and following","text":"

                Starting from GeoServer 2.12, the allowDynamicStyles GeoFence configuration option has been moved to the core GeoServer WMS module.

                This means that if you had this option active in GeoFence, you have to manually enable the same option in the WMS service configuration page of the GeoServer Admin UI (either globally or on a virtual service by virtual service basis).

                See here: WMS settings

                "},{"location":"extensions/geofence-server/rest-adminrule/","title":"AdminRules Rest API","text":""},{"location":"extensions/geofence-server/rest-adminrule/#security","title":"Security","text":"

                The Geofence Rest API is only accessible to users with the role ROLE_ADMIN.

                "},{"location":"extensions/geofence-server/rest-adminrule/#inputoutput","title":"Input/Output","text":""},{"location":"extensions/geofence-server/rest-adminrule/#data-object-transfer","title":"Data Object Transfer","text":"

                Both XML and JSON are supported for transfer of data objects. The default is XML. Alternatively, JSON may be used by setting the 'content-type' (POST) and 'accept' (GET) http headers to 'application/json' in your requests.

                Encoding of an AdminRule in XML:

                <AdminRule>\n    <id>..</id>\n    <priority>..</priority>\n    <userName>..</userName>\n    <roleName>..</roleName>\n    <addressRange>..</addressRange>\n    <workspace>..</workspace>\n    <access>..</access>\n</AdminRule>\n

                Encoding of a rule in JSON:

                {\"id\":..,\"priority\":..,\"userName\":\"..\",\"roleName\":\"..\",\"addressRange\":\"..\",\"workspace\":\"..\",\"access\":\"..\"}\n

                In case a rule that has \"any\" (\"*\") for a particular field the field is either not included (default), left empty or specified with a single asterisk (the latter two may be used for updates to distinguish from \"do not change this field\").

                access should be either ADMIN or USER.

                addressRange is a string in CIDR notation (block/bits: e.g. 127.0.0.1/32).

                Encoding of a list of rules in XML:

                <AdminRules count=\"n\">\n    <AdminRule> ... </AdminRule>\n    <AdminRule> ... </AdminRule>\n    ...     \n</AdminRules>\n

                The result of a count would not include the actual tags.

                Encoding of a list of rules in JSON:

                {\"count\":n,\"adminrules\":[{..},{..},..]}\n
                "},{"location":"extensions/geofence-server/rest-adminrule/#filter-parameters","title":"Filter Parameters","text":"

                All filter parameters are optional.

                Name Type Description

                page number Used for paging a list of rules. Specifies the number of the page. Leave out for no paging. If specified, entries should also be specified.

                entries number Used for paging a list of rules. Specifies the number of entries per page. Leave out for no paging. If specified, page should also be specified.

                userName string Filter rules on username (excludes all other specified usernames).

                userAny 0 or 1. Specify whether rules matching any username should be included or not.

                roleName string Filter rules on rolename (excludes all other specified rolenames).

                roleAny 0 or 1. Specify whether rules matching any rolename should be included or not.

                workspace string Filter rules on workspace (excludes all other specified workspaces).

                workspaceAny 0 or 1. Specify whether rules matching any workspace should be included or not.

                "},{"location":"extensions/geofence-server/rest-adminrule/#requests","title":"Requests","text":""},{"location":"extensions/geofence-server/rest-adminrule/#geofencerestadminrules","title":"/geofence/rest/adminrules/","text":"

                Query all adminrules or add a new adminrule.

                Method Action Supported parameters Response

                GET List all adminrules, with respect to any added filters page, entries, userName, userAny, roleName, roleAny, workspace, workspaceAny 200 OK. List of adminrules in XML.

                POST Add a new adminrule None 201 Inserted. Created ID header.

                "},{"location":"extensions/geofence-server/rest-adminrule/#geofencerestadminrulescount","title":"/geofence/rest/adminrules/count","text":"

                Counts (filtered) adminrules.

                Method Action Supported parameters Response

                GET Count all adminrules, with respect to any added filters userName, userAny, roleName, roleAny, workspace, workspaceAny 200 OK. Rule list count in XML.

                "},{"location":"extensions/geofence-server/rest-adminrule/#geofencerestadminrulesidid","title":"/geofence/rest/adminrules/id/<id>","text":"

                Query, modify or delete a specific adminrule.

                Method Action Supported parameters Response

                GET Read adminrule information None 200 OK. AdminRule in XML.

                POST Modify the adminrule, unspecified fields remain unchanged. None 200 OK.

                DELETE Delete the adminrule None 200 OK.

                "},{"location":"extensions/geofence-server/rest-batch-op/","title":"Batch Rest API","text":"

                Batch operations allow to run multiple insert, update and delete at the same time over rules and admin rules. All the operations are executed in a single transaction: this means that either all of them are successful or all the operations are rolled back.

                "},{"location":"extensions/geofence-server/rest-batch-op/#security","title":"Security","text":"

                The Geofence REST API is only accessible to users with the role ROLE_ADMIN.

                "},{"location":"extensions/geofence-server/rest-batch-op/#inputoutput","title":"Input/Output","text":""},{"location":"extensions/geofence-server/rest-batch-op/#data-object-transfer","title":"Data Object Transfer","text":"

                Both XML and JSON are supported for transfer of data objects. The default is XML. Alternatively, JSON may be used by setting the Content-Type and Accept HTTP headers to application/json in your requests.

                A Batch data object transfer must declare a list of operations. Each operation needs to declare:

                • The service name (rules for a Rule operation or adminrules for an AdminRule operation).
                • The type of the operation (insert, update, delete).
                • The id of the entity over which the operation is being performed in case of an update or delete types.
                • The Rule or AdminRule data object transfer in case of insert or update operation.

                Encoding of a Batch in XML:

                <Batch>\n<operations service=\"rules\" id=\"2\" type=\"update\">\n  <Rule id=\"2\">\n     <access>ALLOW</access>\n     <layer>layer</layer>\n     <priority>5</priority>\n     <request>GETMAP</request>\n     <roleName>ROLE_AUTHENTICATED</roleName>\n     <service>WMS</service>\n     <workspace>ws</workspace>\n  </Rule>\n</operations>\n<operations service=\"rules\" id=\"5\" type=\"delete\" />\n<operations service=\"adminrules\" type=\"insert\">\n  <RuleAdmin>\n     <priority>2</priority>\n     <roleName>ROLE_USER</roleName>\n     <workspace>ws</workspace>\n     <access>ADMIN</access>\n  </RuleAdmin>\n</operations>\n</Batch>\n

                Encoding of a Batch in JSON:

                {\n\"Batch\":{\n  \"operations\":[\n     {\n        \"@service\":\"adminrules\",\n        \"@type\":\"update\",\n        \"@id\":\"3\",\n        \"Rule\":{\n           \"access\":\"ALLOW\",\n           \"layer\":\"layer\",\n           \"priority\":5,\n           \"request\":\"GETMAP\",\n           \"service\":\"WMS\",\n           \"roleName\":\"ROLE_AUTHENTICATED\",\n           \"workspace\":\"ws\"\n        }\n     },\n     {\n        \"@service\":\"rules\",\n        \"@type\":\"delete\",\n        \"@id\":5\n     },\n     {\n        \"@service\":\"adminrules\",\n        \"@type\":\"insert\",\n        \"AdminRule\":{\n           \"priority\":2,\n           \"roleName\":\"ROLE_USER\",\n           \"workspace\":\"ws\",\n           \"access\":\"ADMIN\"\n        }\n     }\n  ]\n}\n}\n
                "},{"location":"extensions/geofence-server/rest-batch-op/#requests","title":"Requests","text":""},{"location":"extensions/geofence-server/rest-batch-op/#restgeofencebatchexec","title":"/rest/geofence/batch/exec","text":"

                Issue a Batch operation executing all the declared operations.

                Method Action Response code Response

                POST Execute a batch 200 OK

                                         400             BadRequest: malformed request body, duplicate rule addition\n\n                         404             NotFound: rule not found\n\n                         500             InternalServerError: unexpected error\n
                "},{"location":"extensions/geofence-server/rest/","title":"GeoFence Rest API","text":""},{"location":"extensions/geofence-server/rest/#security","title":"Security","text":"

                The Geofence Rest API is only accessible to users with the role ROLE_ADMIN.

                "},{"location":"extensions/geofence-server/rest/#inputoutput","title":"Input/Output","text":""},{"location":"extensions/geofence-server/rest/#data-object-transfer","title":"Data Object Transfer","text":"

                Both XML and JSON are supported for transfer of data objects. The default is XML. Alternatively, JSON may be used by setting the 'content-type' (POST) and 'accept' (GET) http headers to 'application/json' in your requests.

                Encoding of a rule in XML:

                <Rule>\n    <id>..</id>\n    <priority>..</priority>\n    <userName>..</userName>\n    <roleName>..</roleName>\n    <workspace>..</workspace>\n    <layer>..</layer>\n    <service>..</service>\n    <request>..</request>\n    <subfield>..</subfield>\n    <access> ALLOW | DENY | LIMIT </access>\n\n    <!-- for LIMIT access rules-->\n    <limits> \n        <allowedArea>..</allowedArea>\n        <catalogMode> HIDE | CHALLENGE | MIXED </catalogMode>\n    </limits>\n\n    <!-- for ALLOW access rules with specified layer -->\n    <layerDetails>\n        <layerType> VECTOR | RASTER | LAYERGROUP </layerType>\n        <defaultStyle>..</defaultStyle>\n        <cqlFilterRead>..</cqlFilterRead>\n        <cqlFilterWrite>..</cqlFilterWrite>\n        <allowedArea>..</allowedArea>\n        <catalogMode> HIDE | CHALLENGE | MIXED </catalogMode>\n\n        <allowedStyle>..</allowedStyle>\n        ..\n\n        <attribute>\n            <name>..</name>\n            <datatype>..</datatype>\n            <accessType> NONE | READONLY | READWRITE </accessType>\n        </attribute>            \n                    ..\n\n    </layerDetails>\n</Rule>\n

                Encoding of a rule in JSON:

                {\"Rule\": {\"id\":..,\"priority\":..,\"userName\":\"..\",\"roleName\":\"..\",\"workspace\":\"..\",\"layer\":\"..\",\"service\":\"..\",\"request\":\"..\",\"subfield\":\"..\",\"access\":\"..\"}}\n

                In case a rule that has \"any\" (\"*\") for a particular field the field is either not included (default), left empty or specified with a single asterisk (the latter two may be used for updates to distinguish from \"do not change this field\").

                Encoding of a list of rules in XML:

                <Rules count=\"n\">\n    <Rule> ... </Rule>\n    <Rule> ... </Rule>\n    ...     \n</Rules>\n

                The result of a count would not include the actual tags.

                Encoding of a list of rules in JSON:

                {\"count\":n,\"rules\":[{..},{..},..]}\n
                "},{"location":"extensions/geofence-server/rest/#filter-parameters","title":"Filter Parameters","text":"

                All filter parameters are optional.

                Name Type Description

                page number Used for paging a list of rules. Specifies the number of the page. Leave out for no paging. If specified, entries should also be specified.

                entries number Used for paging a list of rules. Specifies the number of entries per page. Leave out for no paging. If specified, page should also be specified.

                userName string Filter rules on username (excludes all other specified usernames).

                userAny 0 or 1. Specify whether rules for 'any' username are included or not.

                roleName string Filter rules on rolename (excludes all other specified rolenames).

                roleAny 0 or 1. Specify whether rules for 'any' rolename are included or not.

                service string Filter rules on service (excludes all other specified services).

                serviceAny 0 or 1. Specify whether rules for 'any' service are included or not.

                request string Filter rules on request (excludes all other specified requests).

                requestAny 0 or 1. Specify whether rules for 'any' request are included or not.

                workspace string Filter rules on workspace (excludes all other specified workspaces).

                workspaceAny 0 or 1. Specify whether rules for 'any' workspace are included or not.

                layer string Filter rules on layer (excludes all other specified layers).

                layerAny 0 or 1. Specify whether rules for 'any' layer are included or not.

                "},{"location":"extensions/geofence-server/rest/#requests","title":"Requests","text":""},{"location":"extensions/geofence-server/rest/#restgeofencerules","title":"/rest/geofence/rules/","text":"

                Query all rules or add a new rule.

                Method Action Supported parameters Response

                GET List all rules, with respect to any added filters page, entries, userName, userAny, roleName, roleAny, service, serviceAny, request, requestAny, workspace, workspaceAny, layer, layerAny 200 OK. List of rules in XML.

                POST Add a new rule None 201 Inserted. Created ID header.

                "},{"location":"extensions/geofence-server/rest/#restgeofencerulescount","title":"/rest/geofence/rules/count","text":"

                Counts (filtered) rules.

                Method Action Supported parameters Response

                GET Count all rules, with respect to any added filters userName, userAny, roleName, roleAny, service, serviceAny, request, requestAny, workspace, workspaceAny, layer, layerAny 200 OK. Rule list count in XML.

                "},{"location":"extensions/geofence-server/rest/#restgeofencerulesidid","title":"/rest/geofence/rules/id/<id>","text":"

                Query, modify or delete a specific rule.

                Method Action Supported parameters Response

                GET Read rule information None 200 OK. Rule in XML.

                POST Modify the rule, unspecified fields remain unchanged. None 200 OK.

                DELETE Delete the rule None 200 OK.

                "},{"location":"extensions/geofence-server/tutorial/","title":"Using the Internal GeoFence server (Tutorial)","text":""},{"location":"extensions/geofence-server/tutorial/#introduction","title":"Introduction","text":"

                This tutorial shows how to install and configure the Geofence Internal Server plug-in. It shows how to create rules in two ways: using the GUI and REST methods.

                The tutorial assumes:

                • GeoServer is running on http://localhost:8080/geoserver

                • You have a user/group service called \"default\" that allows the creation of new users. If your primary user/group service is not called \"default\", you must start geoserver with the following java system property present:

                  org.geoserver.rest.DefaultUserGroupServiceName=<name_of_usergroupservice>\n

                with a user/group service that allows the creation of new users."},{"location":"extensions/geofence-server/tutorial/#getting-started","title":"Getting Started","text":"

                Install the plugin-in, see Installing the GeoServer GeoFence Server extension. Configure the user/group service as described above if necessary.

                Restart GeoServer.

                ::: note ::: title Note :::

                Since we defined no rules yet, the default behavior of GeoFence is to deny access to all resources. :::

                There should now be a GeoFence Data Rules link on the left side of the screen after logging in. Click on it. This is the configuration page of your internal GeoFence.

                "},{"location":"extensions/geofence-server/tutorial/#creating-new-rules-with-the-gui","title":"Creating new Rules with the GUI","text":"
                1. Click on the \"Add new rule\" link. Change only \"Access\" to \"DENY\".

                Click on \"Save\".

                We have now expressed that the first rule (with lowest priority) disallows everyone from everything. The following more specific rules we make will provide the exceptions to that general rule. It is also possible to do it the other way (allow everyone to anything as most general rule and specify exceptions to that.)

                1. As a next step, we will grant the administrator access to everything. Click on \"Add new rule\" again. Change \"Role\" to \"ADMIN\" and click \"Save\".

                You now have a working, basic security configuration.

                "},{"location":"extensions/geofence-server/tutorial/#creating-rules-with-the-rest-api","title":"Creating rules with the REST API","text":"

                1. Open a new tab with your browser and go to the following URL: http://localhost:8080/geoserver/geofence/rest/rules. You should get an XML representation of your rules:

                <?xml version=\"1.0\" encoding=\"UTF-8\" standalone=\"yes\"?>\n<Rules count=\"2\">\n  <Rule id=\"2\">\n      <access>ALLOW</access>\n      <priority>0</priority>\n      <roleName>ADMIN</roleName>\n  </Rule>\n  <Rule id=\"1\">\n      <access>DENY</access>\n      <priority>1</priority>\n  </Rule>\n</Rules>\n

                2. Let us first create a new user. Do this by sending a POST request to the following URL http://localhost:8080/geoserver/rest/security/usergroup/users with the following content:

                <user>\n      <userName>michaeljfox</userName>\n      <password>back2$future</password>\n      <enabled>true</enabled>\n</user>\n

                You should receive a 201 Created HTTP Response.

                3. Now we will create an access rule for this user. Do this by sending a POST request to the following URL: http://localhost:8080/geoserver/geofence/rest/rules with the following content:

                <Rule>\n      <userName>michaeljfox</userName>\n      <workspace>topp</workspace>\n      <layer>states</layer>\n      <service>WMS</service>\n      <request>GetMap</request>\n      <access>ALLOW</access>\n</Rule>\n

                Again, you should receive a 201 Created HTTP Response. When browsing to the URL http://localhost:8080/geoserver/geofence/rest/rules we should now see the following information:

                <?xml version=\"1.0\" encoding=\"UTF-8\" standalone=\"yes\"?>\n<Rules count=\"2\">\n  <Rule id=\"3\">\n      <access>ALLOW</access>\n      <layer>states</layer\n      <priority>0</priority>\n      <request>GETMAP</request>\n      <service>WMS</service>\n      <userName>michaeljfox</userName>\n      <workspace>topp</workspace>\n  </Rule>\n  <Rule id=\"2\">\n      <access>ALLOW</access>\n      <priority>0</priority>\n      <roleName>ADMIN</roleName>\n  </Rule>\n  <Rule id=\"1\">\n      <access>DENY</access>\n      <priority>1</priority>\n  </Rule>\n</Rules>\n
                1. It should now be possible to log on with username michaeljfox and password back2$future and perform a GetMap on the layer topp:states, but nothing else.
                "},{"location":"extensions/geofence-wps/","title":"Geofence WPS Integration","text":"

                This plugin adds a fine-grained control over WPS processes.

                Without this plugin, you can only allow/deny a layer for the whole WPS service for given user/roles.

                Using this plugin, you can create authorization rules for the single WPS process.

                • Installing the GeoServer GeoFence WPS Integration
                • GeoFence WPS rules setup
                "},{"location":"extensions/geofence-wps/gui/","title":"GeoFence WPS rules setup","text":"

                This plugin will not change the GUI in any way. Anyway, you can now use the subfield field to select the processes you want to authorize.

                For instance, with the following rules:

                you will enable all WPS processes for the tasmania_cities layer, but you will prevent to download it via WPS.

                "},{"location":"extensions/geofence-wps/gui/#chained-processes","title":"Chained processes","text":"

                Please note that this plugin also considers chained WPS processes, when they are running in the same GeoServer instance. If a user is running an execute request containing more than one chained process, all processes will be needed to be allowed in order for the request to be run successfully.

                For instance, if the user sends a request of this kind:

                /--> Proc2 --> Layer A\nProc1 --|\n\\              /--> Layer B\n --> Proc3 --|\n               --> Proc4 --> Layer C\n

                the user will need at least these permissions:

                • Proc1: LayerA + LayerB + LayerC
                • Proc2: LayerA
                • Proc3: LayerB + LayerC
                • Proc4: LayerC
                "},{"location":"extensions/geofence-wps/installing/","title":"Installing the GeoServer GeoFence WPS Integration","text":"
                1. Visit the website download page, locate your release, and download: geofence-wps

                  The download link will be in the Extensions section under Other.

                  Warning

                  Ensure to match plugin (example 2.24.2 above) version to the version of the GeoServer instance.

                1. Extract the files in this archive to the WEB-INF/lib directory of your GeoServer installation.
                2. Restart GeoServer
                "},{"location":"extensions/geopkg-output/","title":"GeoPackage Output","text":"

                This extension supports GeoPKG as an output format for both WFS (vectors) and WMS (tiles).

                • Installing the GeoPackage Output Extension
                • Using the GeoPackage Output Extension
                "},{"location":"extensions/geopkg-output/install/","title":"Installing the GeoPackage Output Extension","text":"

                The GeoPackage Output extension is an official extension. Download the extension here - geopkg-output

                1. Download the extension for your version of GeoServer.

                  Warning

                  Make sure to match the version of the extension to the version of GeoServer.

                2. Extract the archive and copy the contents into the GeoServer WEB-INF/lib directory.

                3. Restart GeoServer.

                "},{"location":"extensions/geopkg-output/install/#verify-installation","title":"Verify Installation","text":"

                To verify that the extension was installed successfully:

                1. Request the WFS 1.0.0 GetCapabilities document from your server.

                2. Inside the resulting WFS 1.0.0 XML GetCapabilities document, find the WFS_Capabilities/Capability/GetFeature/ResultFormat section

                3. Verify that geopkg, geopackage, and gpkg are listed as a supported format

                  <GetFeature>\n    <ResultFormat>\n        <GML2/>\n        <GML3/>\n        <SHAPE-ZIP/>\n        <CSV/>\n        <JSON/>\n        <KML/>\n        <geopackage/>\n        <geopkg/>\n        <gpkg/>\n    </ResultFormat>\n</GetFeature>\n

                Note

                You can also verify installation by looking for GeoPKG Output Extension on the server's Module Status Page.

                "},{"location":"extensions/geopkg-output/usage/","title":"Using the GeoPackage Output Extension","text":"

                The GeoPackage Output Extension adds support to WFS and WMS to request GetFeature and GetMap results in GeoPackage Format.

                "},{"location":"extensions/geopkg-output/usage/#wfs","title":"WFS","text":"

                Add &outputFormat=geopkg to your request. The result will be a GeoPackage (MIME type application/geopackage+sqlite3) containing the requested features.

                curl \"http://localhost:8080/geoserver/wfs?service=wfs&version=2.0.0&request=GetFeature&typeNames=ws:layername&outputFormat=geopkg\" \\\n-o wfs.gpkg\n

                You can use geopkg, geopackage, or gpkg as the output format in the request. Use 1.0.0, 1.1.0, or 2.0.0 as version= to specify which WFS version to use.

                Note

                GeoPackages always have the ordinates in X,Y (EAST_NORTH) format.

                "},{"location":"extensions/geopkg-output/usage/#wfs-output-configuration","title":"WFS Output Configuration","text":"

                GeoPackage output format configuration properties are available. For information on use of configuration properties see running in a production environment instructions.

                "},{"location":"extensions/geopkg-output/usage/#geopackagewfsindexed","title":"geopackage.wfs.indexed","text":"

                By default a spatial index is generated when generating GeoPackage output.

                Use java system property -Dgeopackage.wfs.indexed=false to suppress the generation of a spatial index in generated geopackage output.

                "},{"location":"extensions/geopkg-output/usage/#geopackagewfstempdir","title":"geopackage.wfs.tempdir","text":"

                The GeoPackage file format is an SQLite database which can only be managed as a file locally. To produce a GeoPackage GeoServer makes use of a temporary file created in java.io.tmpdir location. This temporary file is removed once the response is completed.

                Some container environments recommend use of a network share for their java.io.tmpdir location. This approach is not compatible with SQLite database driver which requires a local disk location and file lock.

                To override the temporary file location used for GeoPackage output format file generation use property -Dgeopackage.wfs.tempdir=<path location> to provide an alternate path.

                "},{"location":"extensions/geopkg-output/usage/#wms","title":"WMS","text":"

                Add &format=geopkg to your request. The result will be a GeoPackage (MIME type application/geopackage+sqlite3) containing the requested tiles.

                Using WMS 1.1.0 to access tiled image geopkg:

                curl \"http://localhost:8080/geoserver/wms?service=WMS&version=1.1.0&request=GetMap&layers=ws:layername&bbox=-123.43670607166865%2C48.3956835%2C-123.2539813%2C48.5128362547052&width=1536&height=984&srs=EPSG%3A4326&styles=&format=geopkg\" \\\n-o wms.gpkg\n

                Using WMS 1.3.0 to access tiled image geopkg:

                curl \"http://localhost:8080/geoserver/wms?service=WMS&version=1.3.0&request=GetMap&layers=ws:layername&bbox=48.3956835,-123.43670607166865,48.5128362547052,-123.2539813&width=768&height=492&srs=EPSG%3A4326&styles=&format=geopkg\" \\\n-o wms.gpkg\n

                You can use format=geopkg, format=geopackage, or format=gpkg as the output format in the request. Use WMS version=1.1.0, or version=1.3.0 to specify which WMS version to use, keeping in mind axis order for bbox differences.

                Note

                Regardless of WMS axis order used for bbox the resulting GeoPackages always have the ordinates in X,Y (EAST_NORTH) order as required by the specification.

                "},{"location":"extensions/geopkg-output/usage/#wms-format-options","title":"WMS Format options","text":"

                You can also add format options (format_options=param1:value1;param2:value2;...) to the request. With all default values, you will get a GeoPackage with PNG tiles of multiple resolutions. There will be a little more than 255 total tiles - all occupying the area in the request's bbox.

                +--------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Parameter | Description | +==============+=============================================================================================================================================================+ | min_zoom | Grid Zoom level for tiles to start. | | | | | | default: zoom level based on a single tile covering the bbox area. | +--------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------+ | max_zoom | Grid Zoom level for tiles to end. | | | | | | default: zoom where there's >255 tiles in total in the geopkg (could be a bit more) | +--------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------+ | num_zooms | Number of zoom levels in the geopkg. | | | | | | If present then max_zoom = min_zoom + num_zooms | +--------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------+ | format | Format for the image tiles in the geopkg. | | | | | | default: PNG | +--------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------+ | tileset_name | Name of tile set (\"layer\") used in the geopkg. | | | | | | default: based on the layer names given in the request ('_' separated) | +--------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------+ | min_column | First column number (from the gridset) to use. | | | | | | default: use request bbox to determine which tiles to produce | +--------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------+ | max_column | Last column number (from the gridset) to use. | | | | | | default: use request bbox to determine which tiles to produce | +--------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------+ | min_row | First row number (from the gridset) to use. | | | | | | default: use request bbox to determine which tiles to produce | +--------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------+ | max_row | Last row number (from the gridset) to use. | | | | | | default: use request bbox to determine which tiles to produce | +--------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------+ | gridset | Name of the gridset (from GWC GridSetBroker) to uses. | | | | | | default: find based on request SRS | +--------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------+ | flipy | Do NOT set. | | | | | | default: TRUE (required for GeoPackage - The tile coordinate (0,0) always refers to the tile in the upper left corner of the tile matrix\\...) | +--------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------+

                Format Options

                "},{"location":"extensions/grib/grib/","title":"GRIB","text":""},{"location":"extensions/grib/grib/#adding-a-grib-data-store","title":"Adding a GRIB data store","text":"

                To add a GRIB data store the user must go to Stores \u2192 Add New Store \u2192 GRIB.

                GRIB in the list of raster data stores

                "},{"location":"extensions/grib/grib/#configuring-a-grib-data-store","title":"Configuring a GRIB data store","text":"

                Configuring a GRIB data store

                Option Description

                Workspace

                Data Source Name

                Description

                Enabled

                URL

                "},{"location":"extensions/grib/grib/#relationship-with-netcdf","title":"Relationship with NetCDF","text":"

                Note

                Note that internally the GRIB extension uses the NetCDF reader, which supports also GRIB data. See also the NetCDF documentation page for further information.

                "},{"location":"extensions/grib/grib/#current-limitations","title":"Current limitations","text":"
                • Input coverages/slices should share the same bounding box (lon/lat coordinates are the same for the whole ND cube)
                "},{"location":"extensions/gwc-s3/","title":"GWC S3 BlobStore plugin","text":"

                This plugin supports the use of the AWS Simple Storage Service (Amazon S3) as storage medium for GWC<gwc_webadmin>.

                • Installing the GWC S3 extension
                • Configuring the S3 BlobStore plugin
                "},{"location":"extensions/gwc-s3/configuration/","title":"Configuring the S3 BlobStore plugin","text":"

                Once the plugin has been installed, one or more S3 BlobStores may be configured through BlobStores. Afterwards, cached layers can be explicitly assigned to it or one blobstore could be marked as 'default' to use it for all unassigned layers.

                "},{"location":"extensions/gwc-s3/configuration/#bucket","title":"Bucket","text":"

                The name of the AWS S3 bucket where the tiles are stored.

                "},{"location":"extensions/gwc-s3/configuration/#aws-access-key","title":"AWS Access Key","text":"

                The AWS Access Key ID. If AWS Access Key and AWS Secret Access Key are left blank, AWS Default Credential Chain will be used.

                "},{"location":"extensions/gwc-s3/configuration/#aws-secret-key","title":"AWS Secret Key","text":"

                AWS Secret Access Key.

                "},{"location":"extensions/gwc-s3/configuration/#s3-object-key-prefix","title":"S3 Object Key Prefix","text":"

                A prefix path to use as the root to store tiles under the bucket (optional).

                "},{"location":"extensions/gwc-s3/configuration/#maximum-connections","title":"Maximum Connections","text":"

                The maximum number of allowed open HTTP connections.

                "},{"location":"extensions/gwc-s3/configuration/#use-https","title":"Use HTTPS","text":"

                When enabled, a HTTPS connection will be used. When disabled, a regular HTTP connection will be used.

                "},{"location":"extensions/gwc-s3/configuration/#proxy-domain","title":"Proxy Domain","text":"

                A Windows domain name for configuring NTLM proxy support (optional).

                "},{"location":"extensions/gwc-s3/configuration/#proxy-workstation","title":"Proxy Workstation","text":"

                A Windows workstation name for configuring NTLM proxy support (optional).

                "},{"location":"extensions/gwc-s3/configuration/#proxy-host","title":"Proxy Host","text":"

                Proxy host the client will connect through (optional).

                "},{"location":"extensions/gwc-s3/configuration/#proxy-port","title":"Proxy Port","text":"

                Proxy port the client will connect through (optional).

                "},{"location":"extensions/gwc-s3/configuration/#proxy-username","title":"Proxy Username","text":"

                User name the client will use if connecting through a proxy (optional).

                "},{"location":"extensions/gwc-s3/configuration/#proxy-password","title":"Proxy Password","text":"

                Password the client will use if connecting through a proxy (optional).

                "},{"location":"extensions/gwc-s3/configuration/#use-gzip","title":"Use Gzip","text":"

                When enabled, the stored tiles will be GZIP compressed.

                "},{"location":"extensions/gwc-s3/configuration/#access-type","title":"Access Type","text":"

                Stored tiles will be created either as Public (readable and writable by any user that can access the S3 bucket), or Private (readable and writable only by the user identified by the AWS credentials specified above). Important: if the bucket itself is setup to block all public access, then the blobstore needs to be setup to Private as well, or AWS will return a 403 when attempting to store tiles.

                "},{"location":"extensions/gwc-s3/install/","title":"Installing the GWC S3 extension","text":"

                The GWC S3 extension is listed among the other extension downloads on the GeoServer download page.

                The installation process is similar to other GeoServer extensions:

                1. Visit the website download page, locate your release, and download: gwc-s3

                  Verify that the version number in the filename (for example 2.24.2 above) corresponds to the version of GeoServer you are running.

                2. Extract the contents of the archive into the WEB-INF/lib directory in GeoServer. Make sure you do not create any sub-directories during the extraction process.

                3. Restart GeoServer.

                To verify the installation was successful, to \"Tile Caching\", \"Blobstores\" and create a new blobstore, the S3 option show be available:

                The S3 option showing while creating a new blobstore

                "},{"location":"extensions/iau/","title":"IAU planetary CRSs","text":"

                This extension adds IAU planetary CRSs to the database recognized by GeoServer and helps configuring and generating data in such CRSs, without having to create a fake EPSG code.

                • Installing the IAU authority
                • Using IAU authority
                "},{"location":"extensions/iau/install/","title":"Installing the IAU authority","text":"

                The IAU authority is an official extension. Download the extension here - iau

                1. Download the extension for your version of GeoServer.

                  Warning

                  Make sure to match the version of the extension to the version of GeoServer.

                2. Extract the archive and copy the contents into the GeoServer WEB-INF/lib directory.

                3. Restart GeoServer.

                "},{"location":"extensions/iau/install/#verify-installation","title":"Verify Installation","text":"

                To verify that the extension was installed successfully:

                1. On the left menu, get into Demos and then SRS List
                2. Go into the table filter text field, and type IAU, then press enter
                3. A number of IAU codes should appear in the table

                "},{"location":"extensions/iau/usage/","title":"Using IAU authority","text":"

                Support for the IAU authority required deep changes to the GeoServer code base, as the assumption that the only possible authority is EPSG was widespread.

                At the time of writing, the following modules support IAU:

                • GeoTIFF reading and writing (e.g. WCS output)
                • Shapefile and GeoPackage reading and writing (e.g. WFS output)
                • PostGIS reading (the spatial_ref_sys table must contain the IAU codes and definitions)
                • Basic functionality of WMS, WFS, WCS, WPS, OGC API - Features and OGC API - Maps.
                • GML and GeoJSON outputs, in various versions
                • The importer module should be able to successfully handle input data in IAU CRSs

                Other functionality might not be ready, the code base will be improved and generalized as contributions and funding allow.

                "},{"location":"extensions/importer/","title":"Importer","text":"

                The Importer extension gives a GeoServer administrator an alternate, more-streamlined method for uploading and configuring new layers.

                There are two primary advantages to using the Importer over the standard GeoServer data-loading workflow:

                1. Supports batch operations (loading and publishing multiple spatial files or database tables in one operation)
                2. Creates unique styles for each layer, rather than linking to the same (existing) styles.

                This section will discuss the Importer extension.

                • Installing the Importer extension
                • Configuring the Importer extension
                • Using the Importer extension
                • Importer interface reference
                • Supported data formats
                • REST API
                • Importer REST API examples
                "},{"location":"extensions/importer/configuring/","title":"Configuring the Importer extension","text":"

                The importer extension can be used without any explicit configuration, and by default it will:

                • Stage the REST uploads in a dedicated sub-folder of the data directory (uploads).
                • Pose no limit to the amount of concurrent imports executed.

                It is however possible to configure the above using the \"Importer\" entry under the \"Settings\" menu:

                The importer configuration menu entry

                The configuration page looks as follows:

                The importer configuration page

                +----------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Entry | Description | +========================================+===============================================================================================================================================================================================================================================================================================================================================+ | Upload root | The folder that will hold REST call uploads | +----------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Maximum synchronous jobs | How many synchronous jobs can be run in parallel. Synchronous jobs can only be run via the REST API. | +----------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Maximum asynchronous jobs | How many asynchronous jobs can be run in parallel. Asynchronous jobs can run via the REST API, | | | | | | : and all jobs started from the GUI are asynchronous. | +----------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Maximum asynchronous jobs | How many asynchronous jobs can be run in parallel. Asynchronous jobs can run via the REST API, | | | | | | : and all jobs started from the GUI are asynchronous. | +----------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Completed and stale imports expiration | How many minutes to wait, before removing an import from the database. Imports that are still running are ignored, while completed, errored, or imports that were created, but never started, are going to be considered for cleanup. Value is in minutes, set to zero or negative to never remove values. Defaults to 1440 minutes, one day. | +----------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+

                "},{"location":"extensions/importer/configuring/#importer-logging","title":"Importer Logging","text":"

                The importer extension includes a new IMPORTER_LOGGING profile which may be selected in global settings.

                • This profile is quiet during normal operation (similar to PRODUCTION_LOOGGING)
                • Provides configuration and information logs on importer activity
                "},{"location":"extensions/importer/formats/","title":"Supported data formats","text":"

                The importer supports any format that GeoServer can use a data store or coverage store. These include the most commonly used formats:

                • Shapefile
                • GeoTIFF

                And a few additional formats:

                • CSV
                • KML

                The following databases are supported:

                • PostGIS
                • Oracle
                • Microsoft SQL Server

                Note

                Oracle and SQL Server require extra drivers to be installed.

                • Install instructions for Oracle
                • Install instructions for SQL Server
                "},{"location":"extensions/importer/guireference/","title":"Importer interface reference","text":"

                The Layer Importer user interface is a component of the GeoServer web interface. You can access it from the GeoServer web interface by clicking the Import Data link, found on the left side of the screen after logging in.

                "},{"location":"extensions/importer/guireference/#data-sources-page","title":"Data sources page","text":"

                The front page of the Layer Importer is where the data source and format are set. The following options are displayed:

                "},{"location":"extensions/importer/guireference/#choose-a-data-source-to-import-from","title":"Choose a data source to import from","text":"

                Select one of the following data sources to use for the import:

                • Spatial Files (see Supported data formats for more details)
                • PostGIS database
                • Oracle database
                • SQL Server database

                Choose a data source

                The contents of the next section is dependent on the data source chosen here.

                "},{"location":"extensions/importer/guireference/#configure-the-data-source-spatial-files","title":"Configure the data source: Spatial Files","text":"

                There is a single box for selecting a file or directory. Click the Browse link to bring up a file chooser. To select a file, click on it. To select a directory, click on a directory name to open it and then click OK.

                Spatial file data source

                File chooser for selecting spatial files

                "},{"location":"extensions/importer/guireference/#configure-the-data-source-postgis","title":"Configure the data source: PostGIS","text":"

                Fill out fields for Connection type (Default or JNDI) Host, Port, Database name, Schema, Username to connect with, and Password.

                There are also advanced connection options, which are common to the standard PostGIS store loading procedure. (See the PostGIS data store page in the GeoServer reference documentation.)

                PostGIS data source connection

                "},{"location":"extensions/importer/guireference/#configure-the-data-source-oracle","title":"Configure the data source: Oracle","text":"

                The parameter fields for the Oracle import are identical to that of PostGIS. The fields aren't populated with default credentials with the exception of the port, which is set to 1521 by default.

                Note

                This option is only enabled if the Oracle extension is installed.

                Oracle data source connection

                "},{"location":"extensions/importer/guireference/#configure-the-data-source-sql-server","title":"Configure the data source: SQL Server","text":"

                The parameter fields for the SQL Server import are identical to that of PostGIS. The fields aren't populated with default credentials with the exception of the port, which is set to 4866 by default.

                Note

                This option is only enabled if the SQL Server extension is installed.

                SQL Server data source connection

                "},{"location":"extensions/importer/guireference/#specify-the-target-for-the-import","title":"Specify the target for the import","text":"

                This area specifies where in the GeoServer catalog the new data source will be stored. This does not affect file placement.

                Select the name of an existing workspace and store.

                Target workspace and store in GeoServer

                Alternately, select Create New and type in a names for a new workspace or store. During the import process, these will be created.

                Creating a new workspace and store

                "},{"location":"extensions/importer/guireference/#recent-imports","title":"Recent imports","text":"

                This section will list previous imports, and whether they were successful or not. Items can be removed from this list with the Remove button, but otherwise cannot be edited.

                Recent imports

                When ready to continue to the next page, click Next.

                "},{"location":"extensions/importer/guireference/#layer-listing-page","title":"Layer listing page","text":"

                On the next page will be a list of layers found by the Layer Importer. The layers will be named according to the source content's name (file name of database table name). For each entry there will be a Status showing if the source is ready to be imported.

                All layers will be selected for import by default, but can be deselected here by unchecking the box next to each entry.

                List of layers to be imported

                A common issue during the import process is when a CRS cannot be determined for a given layer. In this case, a dialog box will display where the CRS can be declared explicitly. Enter the CRS and Click Apply.

                Declaring a CRS

                When ready to perform the import, click Import.

                Each selected layer will be added to the GeoServer catalog inside a new or existing store, and published as a layer.

                After the import is complete the status area will refresh showing if the import was successful for each layer. If successful, a dialog box for previewing the layer will be displayed, with options for Layer Preview (OpenLayers), Google Earth, and GeoExplorer.

                Layers successfully imported

                "},{"location":"extensions/importer/guireference/#advanced-import-settings-page","title":"Advanced import settings page","text":"

                The Advanced link next to each layer will lead to the Advanced import settings page.

                On this page, data can be set to be reprojected from one CRS to another during the import process. To enable reprojection, select the Reprojection box, and enter the source and target CRS.

                In addition, on this page attributes can be renamed and their type changed. Click on the Add link under Attribute Remapping to select the attribute to alter, its type, and its new name. Click Apply when done.

                Click Save when finished.

                Advanced layer list page

                "},{"location":"extensions/importer/installing/","title":"Installing the Importer extension","text":"
                1. Visit the website download page, locate your release, and download: importer

                  Verify that the version number in the filename (for example 2.24.2 above) corresponds to the version of GeoServer you are running.

                2. Extract the archive and copy the contents into the GeoServer WEB-INF/lib directory.

                3. Restart GeoServer.

                4. To verify that the extension was installed successfully, open the Web administration interface and look for an Import Data option in the Data section on the left-side menu.

                  Importer extension successfully installed.

                For additional information please see the section on Using the Importer extension.

                "},{"location":"extensions/importer/rest_examples/","title":"Importer REST API examples","text":""},{"location":"extensions/importer/rest_examples/#mass-configuring-a-directory-of-shapefiles","title":"Mass configuring a directory of shapefiles","text":"

                In order to initiate an import of the c:\\data\\tasmania directory into the existing tasmania workspace:

                1. The following JSON will be POSTed to GeoServer.

                  {\n   \"import\": {\n      \"targetWorkspace\": {\n         \"workspace\": {\n            \"name\": \"tasmania\"\n         }\n      },\n      \"data\": {\n        \"type\": \"directory\",\n        \"location\": \"C:/data/tasmania\"\n      }\n   }\n}\n
                2. This curl command can be used for the purpose:

                curl -u admin:geoserver -XPOST -H \"Content-type: application/json\" \\\n  -d @import.json \\\n  \"http://localhost:8080/geoserver/rest/imports\"\n

                The importer will locate the files to be imported, and automatically prepare the tasks, returning the following response:

                {\n  \"import\": {\n    \"id\": 9,\n    \"href\": \"http://localhost:8080/geoserver/rest/imports/9\",\n    \"state\": \"PENDING\",\n    \"archive\": false,\n    \"targetWorkspace\": {\n      \"workspace\": {\n        \"name\": \"tasmania\"\n      }\n    },\n    \"data\": {\n      \"type\": \"directory\",\n      \"format\": \"Shapefile\",\n      \"location\": \"C:\\\\data\\\\tasmania\",\n      \"href\": \"http://localhost:8080/geoserver/rest/imports/9/data\"\n    },\n    \"tasks\": [\n      {\n        \"id\": 0,\n        \"href\": \"http://localhost:8080/geoserver/rest/imports/9/tasks/0\",\n        \"state\": \"READY\"\n      },\n      {\n        \"id\": 1,\n        \"href\": \"http://localhost:8080/geoserver/rest/imports/9/tasks/1\",\n        \"state\": \"READY\"\n      },\n      {\n        \"id\": 2,\n        \"href\": \"http://localhost:8080/geoserver/rest/imports/9/tasks/2\",\n        \"state\": \"READY\"\n      },\n      {\n        \"id\": 3,\n        \"href\": \"http://localhost:8080/geoserver/rest/imports/9/tasks/3\",\n        \"state\": \"READY\"\n      }\n    ]\n  }\n}\n
                1. After checking every task is ready, the import can be initiated by executing a POST on the import resource:

                  curl -u admin:geoserver -XPOST \\\n   \"http://localhost:8080/geoserver/rest/imports/9\"\n
                2. The resource can then be monitored for progress, and eventually final results:

                  curl -u admin:geoserver -XGET \\\n   \"http://localhost:8080/geoserver/rest/imports/9\"\n

                  Which in case of successful import will look like:

                  {\n  \"import\": {\n    \"id\": 9,\n    \"href\": \"http://localhost:8080/geoserver/rest/imports/9\",\n    \"state\": \"COMPLETE\",\n    \"archive\": false,\n    \"targetWorkspace\": {\n      \"workspace\": {\n        \"name\": \"tasmania\"\n      }\n    },\n    \"data\": {\n      \"type\": \"directory\",\n      \"format\": \"Shapefile\",\n      \"location\": \"C:\\\\data\\\\tasmania\",\n      \"href\": \"http://localhost:8080/geoserver/rest/imports/9/data\"\n    },\n    \"tasks\": [\n      {\n        \"id\": 0,\n        \"href\": \"http://localhost:8080/geoserver/rest/imports/9/tasks/0\",\n        \"state\": \"COMPLETE\"\n      },\n      {\n        \"id\": 1,\n        \"href\": \"http://localhost:8080/geoserver/rest/imports/9/tasks/1\",\n        \"state\": \"COMPLETE\"\n      },\n      {\n        \"id\": 2,\n        \"href\": \"http://localhost:8080/geoserver/rest/imports/9/tasks/2\",\n        \"state\": \"COMPLETE\"\n      },\n      {\n        \"id\": 3,\n        \"href\": \"http://localhost:8080/geoserver/rest/imports/9/tasks/3\",\n        \"state\": \"COMPLETE\"\n      }\n    ]\n  }\n} \n
                "},{"location":"extensions/importer/rest_examples/#configuring-a-shapefile-with-no-projection-information","title":"Configuring a shapefile with no projection information","text":"

                In this case, let's assume we have a single shapefile, tasmania_cities.shp, that does not have the **.prj** sidecar file (the example is equally good for any case where the **prj`** file contents cannot be matched to an official EPSG code).

                1. We are going to post the following import definition:

                  {\n   \"import\": {\n      \"targetWorkspace\": {\n         \"workspace\": {\n            \"name\": \"tasmania\"\n         }\n      },\n      \"data\": {\n        \"type\": \"file\",\n        \"file\": \"C:/data/tasmania/tasmania_cities.shp\"\n      }\n   }\n}\n
                2. With the cURL POST command:

                  curl -u admin:geoserver -XPOST -H \"Content-type: application/json\" \\\n   -d @import.json \\\n   \"http://localhost:8080/geoserver/rest/imports\"\n

                  The response in case the CRS is missing will be:

                  {\n  \"import\": {\n    \"id\": 13,\n    \"href\": \"http://localhost:8080/geoserver/rest/imports/13\",\n    \"state\": \"PENDING\",\n    \"archive\": false,\n    \"targetWorkspace\": {\n      \"workspace\": {\n        \"name\": \"tasmania\"\n      }\n    },\n    \"data\": {\n      \"type\": \"file\",\n      \"format\": \"Shapefile\",\n      \"file\": \"tasmania_cities.shp\"\n    },\n    \"tasks\": [\n      {\n        \"id\": 0,\n        \"href\": \"http://localhost:8080/geoserver/rest/imports/13/tasks/0\",\n        \"state\": \"NO_CRS\"\n      }\n    ]\n  }\n}\n
                3. Drilling into the task layer:

                  curl -u admin:geoserver -XGET -H \"Content-type: application/json\" \\\n     http://localhost:8080/geoserver/rest/imports/13/tasks/0/layer\n

                  We can see the srs information is missing:

                  {\n  \"layer\": {\n    \"name\": \"tasmania_cities\",\n    \"href\": \"http://localhost:8080/geoserver/rest/imports/13/tasks/0/layer\",\n    \"title\": \"tasmania_cities\",\n    \"originalName\": \"tasmania_cities\",\n    \"nativeName\": \"tasmania_cities\",\n    \"bbox\": {\n      \"minx\": 146.2910004483,\n      \"miny\": -43.85100181689,\n      \"maxx\": 148.2910004483,\n      \"maxy\": -41.85100181689\n    },\n    \"attributes\": [\n      {\n        \"name\": \"the_geom\",\n        \"binding\": \"org.locationtech.jts.geom.MultiPoint\"\n      },\n      {\n        \"name\": \"CITY_NAME\",\n        \"binding\": \"java.lang.String\"\n      },\n      {\n        \"name\": \"ADMIN_NAME\",\n        \"binding\": \"java.lang.String\"\n      },\n      {\n        \"name\": \"CNTRY_NAME\",\n        \"binding\": \"java.lang.String\"\n      },\n      {\n        \"name\": \"STATUS\",\n        \"binding\": \"java.lang.String\"\n      },\n      {\n        \"name\": \"POP_CLASS\",\n        \"binding\": \"java.lang.String\"\n      }\n    ],\n    \"style\": {\n      \"name\": \"tasmania_tasmania_cities2\",\n      \"href\": \"http://localhost:8080/geoserver/rest/imports/13/tasks/0/layer/style\"\n    }\n  }\n}\n
                4. Use the following json snippet to update the SRS:

                  {\n   layer : {\n      srs: \"EPSG:4326\"\n   }\n}  \n

                  Using cURL PUT command:

                  curl -u admin:geoserver -XPUT -H \"Content-type: application/json\" \\\n  -d @layerUpdate.json \\\n  \"http://localhost:8080/geoserver/rest/imports/13/tasks/0/layer/\"\n
                5. Getting the import definition again:

                  curl -u admin:geoserver -XGET -H \"Content-type: application/json\" \\\n     http://localhost:8080/geoserver/rest/imports/13/tasks/0\n

                  The import is now ready to execute:

                  {\n  \"import\": {\n    \"id\": 13,\n    \"href\": \"http://localhost:8080/geoserver/rest/imports/13\",\n    \"state\": \"PENDING\",\n    \"archive\": false,\n    \"targetWorkspace\": {\n      \"workspace\": {\n        \"name\": \"tasmania\"\n      }\n    },\n    \"data\": {\n      \"type\": \"file\",\n      \"format\": \"Shapefile\",\n      \"file\": \"tasmania_cities.shp\"\n    },\n    \"tasks\": [\n      {\n        \"id\": 0,\n        \"href\": \"http://localhost:8080/geoserver/rest/imports/13/tasks/0\",\n        \"state\": \"READY\"\n      }\n    ]\n  }\n}\n
                6. A POST request will execute the import:

                  curl -u admin:geoserver -XPOST \\\n  \"http://localhost:8080/geoserver/rest/imports/13\"\n

                  With a successful import marking the task as COMPLETE:

                  {\n  \"import\": {\n    \"id\": 13,\n    \"href\": \"http://localhost:8080/geoserver/rest/imports/13\",\n    \"state\": \"COMPLETE\",\n    \"archive\": false,\n    \"targetWorkspace\": {\n      \"workspace\": {\n        \"name\": \"tasmania\"\n      }\n    },\n    \"data\": {\n      \"type\": \"file\",\n      \"format\": \"Shapefile\",\n      \"file\": \"tasmania_cities.shp\"\n    },\n    \"tasks\": [\n      {\n        \"id\": 0,\n        \"href\": \"http://localhost:8080/geoserver/rest/imports/13/tasks/0\",\n        \"state\": \"COMPLETE\"\n      }\n    ]\n  }\n}\n
                "},{"location":"extensions/importer/rest_examples/#uploading-a-shapefile-to-postgis","title":"Uploading a Shapefile to PostGIS","text":"

                This example shows the process for uploading a Shapefile (in a zip file) to an existing PostGIS datastore (cite:postgis).

                1. Setup cite:postgis datastore:

                  {\n  \"dataStore\": {\n    \"name\": \"postgis\",\n    \"type\": \"PostGIS\",\n    \"workspace\": {\n      \"name\": \"cite\"\n    },\n    \"connectionParameters\": {\n      \"entry\": [\n        {\"@key\": \"schema\",\"$\": \"public\"},\n        {\"@key\": \"database\",\"$\": \"postgres\"},\n        {\"@key\": \"host\",\"$\": \"localhost\"},\n        {\"@key\": \"port\",\"$\": \"5432\"},\n        {\"@key\": \"passwd\",\"$\": \"postgres\"},\n        {\"@key\": \"dbtype\",\"$\": \"postgis\"},\n        {\"@key\": \"user\",\"$\": \"postgres\"},\n        {\"@key\": \"Estimated extends\",\"$\": \"true\"},\n        {\"@key\": \"encode functions\",\"$\": \"true\"},\n        {\"@key\": \"Loose bbox\",\"$\": \"true\"},\n        {\"@key\": \"Method used to simplify geometries\",\"$\": \"PRESERVETOPOLOGY\"},\n        {\"@key\": \"Support on the fly geometry simplification\",\"$\": \"true\"},\n        {\"@key\": \"validate connections\",\"$\": \"true\"},\n        {\"@key\": \"Connection timeout\",\"$\": \"20\"},\n        {\"@key\": \"min connections\",\"$\": \"1\"},\n        {\"@key\": \"max connections\",\"$\": \"10\"},\n        {\"@key\": \"Evictor tests per run\",\"$\": \"3\"},\n        {\"@key\": \"Test while idle\",\"$\": \"true\"},\n        {\"@key\": \"Max connection idle time\",\"$\": \"300\"}\n      ]\n    },\n    \"_default\": true\n  }\n}\n

                  Using curl POST:

                  curl  -u admin:geoserver -XPOST -H \"Content-type: application/json\" \\\n  -d @postgis.json \\\n  \"http://localhost:8080/geoserver/rest/workspaces/cite/datastores.json\"\n
                2. Create the import definition:

                  {\n   \"import\": {\n      \"targetWorkspace\": {\n         \"workspace\": {\n            \"name\": \"cite\"\n         }\n      },\n      \"targetStore\": {\n         \"dataStore\": {\n            \"name\": \"postgis\"\n         }\n      }\n   }\n}\n

                  POST this definition to /geoserver/rest/imports:

                  curl -u admin:geoserver -XPOST -H \"Content-type: application/json\" \\\n  -d @import.json \\\n  \"http://localhost:8080/geoserver/rest/imports\"\n

                  The response will contain the import ID.

                3. We now have an empty import with no tasks. To add a task, POST the shapefile to the list of tasks:

                  curl -u admin:geoserver \\\n  -F name=myshapefile.zip -F filedata=@myshapefile.zip \\\n  \"http://localhost:8080/geoserver/rest/imports/14/tasks\"\n
                4. Since we sent a shapefile, importer assumes the target will be a shapefile store. To import to PostGIS, we will need to reset it.

                  Create the following JSON file:

                  {\n  \"dataStore\": {\n    \"name\":\"postgis\"\n  }\n}\n

                  PUT this file to /geoserver/rest/imports/14/tasks/0/target:

                  curl -u admin:geoserver -XPUT -H \"Content-type: application/json\" \\\n  -d @target.json \\\n  \"http://localhost:8080/geoserver/rest/imports/14/tasks/0/target\"\n
                5. Finally, we execute the import by sending a POST to /geoserver/rest/imports/14:

                  curl -u admin:geoserver -XPOST \\\n  \"http://localhost:8080/geoserver/rest/imports/14\"\n
                "},{"location":"extensions/importer/rest_examples/#uploading-a-csv-file-to-postgis-while-transforming-it","title":"Uploading a CSV file to PostGIS while transforming it","text":"

                A remote sensing tool is generating CSV files with some locations and measurements, that we want to upload into PostGIS as a new spatial table.

                1. First, we are going to create a empty import with an existing postgis store as the target:

                  curl -u admin:geoserver -XPOST -H \"Content-type: application/json\" \\\n  -d @import.json \\\n  \"http://localhost:8080/geoserver/rest/imports\"\n

                  Where import.json is:

                  {\n   \"import\": {\n      \"targetWorkspace\": {\n         \"workspace\": {\n            \"name\": \"cite\"\n         }\n      },\n      \"targetStore\": {\n         \"dataStore\": {\n            \"name\": \"postgis\"\n         }\n      }\n   }\n}\n
                2. Then, we are going to POST the csv file to the tasks list.

                  AssetID, SampleTime, Lat, Lon, Value\n1, 2015-01-01T10:00:00, 10.00, 62.00, 15.2\n1, 2015-01-01T11:00:00, 10.10, 62.11, 30.25\n1, 2015-01-01T12:00:00, 10.20, 62.22, 41.2\n1, 2015-01-01T13:00:00, 10.31, 62.33, 27.6\n1, 2015-01-01T14:00:00, 10.41, 62.45, 12\n

                  In order to create an import task for it:

                  curl -u admin:geoserver -F name=test -F filedata=@values.csv \\\n  \"http://localhost:8080/geoserver/rest/imports/0/tasks\"\n

                  And we are going to get back a new task definition, with a notification that the CRS is missing:

                  {\n  \"task\": {\n    \"id\": 0,\n    \"href\": \"http://localhost:8080/geoserver/rest/imports/0/tasks/0\",\n    \"state\": \"NO_CRS\",\n    \"updateMode\": \"CREATE\",\n    \"data\": {\n      \"type\": \"file\",\n      \"format\": \"CSV\",\n      \"file\": \"values.csv\"\n    },\n    \"target\": {\n      \"href\": \"http://localhost:8080/geoserver/rest/imports/0/tasks/0/target\",\n      \"dataStore\": {\n        \"name\": \"postgis\",\n        \"type\": \"PostGIS\"\n      }\n    },\n    \"progress\": \"http://localhost:8080/geoserver/rest/imports/0/tasks/0/progress\",\n    \"layer\": {\n      \"name\": \"values\",\n      \"href\": \"http://localhost:8080/geoserver/rest/imports/0/tasks/0/layer\"\n    },\n    \"transformChain\": {\n      \"type\": \"vector\",\n      \"transforms\": []\n    }\n  }\n}\n
                3. Force the CRS by updating the layer:

                  {\n   \"layer\" : {\n      \"srs\": \"EPSG:4326\"\n   }\n}\n

                  Using PUT to update task layer:

                  curl -u admin:geoserver -XPUT -H \"Content-type: application/json\" \\\n  -d @layerUpdate.json \\\n  \"http://localhost:8080/geoserver/rest/imports/0/tasks/0/layer/\"\n

                  Updating the srs:

                  {\n  \"layer\": {\n    \"name\": \"values\",\n    \"href\": \"http://localhost:8080/geoserver/rest/imports/0/tasks/0/layer\",\n    \"title\": \"values\",\n    \"originalName\": \"values\",\n    \"nativeName\": \"values\",\n    \"srs\": \"EPSG:4326\",\n    \"bbox\": {\n      \"minx\": 0,\n      \"miny\": 0,\n      \"maxx\": -1,\n      \"maxy\": -1\n    },\n    \"attributes\": [\n      {\n        \"name\": \"AssetID\",\n        \"binding\": \"java.lang.Integer\"\n      },\n      {\n        \"name\": \"SampleTime\",\n        \"binding\": \"java.lang.String\"\n      },\n      {\n        \"name\": \"Lat\",\n        \"binding\": \"java.lang.Double\"\n      },\n      {\n        \"name\": \"Lon\",\n        \"binding\": \"java.lang.Double\"\n      },\n      {\n        \"name\": \"Value\",\n        \"binding\": \"java.lang.Double\"\n      }\n    ],\n    \"style\": {\n      \"name\": \"point\",\n      \"href\": \"http://localhost:8080/geoserver/rest/imports/0/tasks/0/layer/style\"\n    }\n  }\n}\n
                4. Then, we are going to create a transformation mapping the Lat/Lon columns to a point:

                  {\n  \"type\": \"AttributesToPointGeometryTransform\",\n  \"latField\": \"Lat\",\n  \"lngField\": \"Lon\"\n}\n

                  The above will be uploaded task transforms:

                  curl -u admin:geoserver -XPOST -H \"Content-type: application/json\" \\\n  -d @toPoint.json \\\n  \"http://localhost:8080/geoserver/rest/imports/0/tasks/0/transforms\"\n
                5. Now the import is ready to run, and we'll execute it using:

                  curl -u admin:geoserver -XPOST \\\n  \"http://localhost:8080/geoserver/rest/imports/0\"\n
                6. The new layer is created in PostGIS and registered in GeoServer as a new layer.

                  In case the features in the CSV need to be appended to an existing layer a PUT request against the task might be performed, changing its updateMode from \"CREATE\" to \"APPEND\". Changing it to \"REPLACE\" instead will preserve the layer, but remove the old contents and replace them with the newly uploaded ones.

                "},{"location":"extensions/importer/rest_examples/#replacing-postgis-table-using-the-contents-of-a-csv-file","title":"Replacing PostGIS table using the contents of a CSV file","text":"

                To update the values layer with new content:

                1. Create a new import into cite:postgis:

                  curl -u admin:geoserver -XPOST -H \"Content-type: application/json\" \\\n  -d @import.json \"http://localhost:8080/geoserver/rest/imports\"\n

                  Using:

                  {\n   \"import\": {\n      \"targetWorkspace\": {\n         \"workspace\": {\n            \"name\": \"cite\"\n         }\n      },\n      \"targetStore\": {\n         \"dataStore\": {\n            \"name\": \"postgis\"\n         }\n      }\n   }\n}\n
                2. Use replace.csv to create a new task:

                  curl -u admin:geoserver -XPOST \\\n  -F filedata=@replace.csv \\\n  \"http://localhost:8080/geoserver/rest/imports/1/tasks\"\n

                  The csv file has an additional column:

                  AssetID, SampleTime, Lat, Lon, Value, Status\n1, 2015-01-01T10:00:00, 10.00, 62.00, 15.2, ready\n1, 2015-01-01T11:00:00, 10.10, 62.11, 30.25, recording\n1, 2015-01-01T12:00:00, 10.20, 62.22, 41.2, recording\n1, 2015-01-01T13:00:00, 10.31, 62.33, 27.6, recording\n1, 2015-01-01T14:00:00, 10.41, 62.45, 12, complete\n
                3. Update task with as a \"REPLACE\" and supply srs information:

                  curl -u admin:geoserver -XPUT -H \"Content-type: application/json\" \\\n  -d @taskUpdate.json \\\n  \"http://localhost:8080/geoserver/rest/imports/1/tasks/0\"\n

                  Using:

                  {\n   \"task\": {\n       \"updateMode\": \"REPLACE\",\n       \"layer\" : {\n          \"name\": \"values\",\n          \"title\": \"values\",\n          \"nativeName\": \"values\",\n          \"srs\": \"EPSG:4326\"\n       }\n   }\n}\n
                4. Update transform to supply a geometry column:

                  curl -u admin:geoserver -XPOST -H \"Content-type: application/json\" \\\n  -d @toPoint.json \\\n  \"http://localhost:8080/geoserver/rest/imports/1/tasks/0/transforms\"\n

                  Using:

                  {\n  \"type\": \"AttributesToPointGeometryTransform\",\n  \"latField\": \"Lat\",\n  \"lngField\": \"Lon\"\n}\n
                5. Double check import:

                  curl -u admin:geoserver -XGET \\\n  http://localhost:8080/geoserver/rest/imports/1.json\n
                  {\n  \"import\": {\n    \"id\": 2,\n    \"href\": \"http://localhost:8080/geoserver/rest/imports/1\",\n    \"state\": \"PENDING\",\n    \"archive\": false,\n    \"targetWorkspace\": {\n      \"workspace\": {\n        \"name\": \"cite\",\n        \"isolated\": false\n      }\n    },\n    \"targetStore\": {\n      \"dataStore\": {\n        \"name\": \"postgis\",\n        \"type\": \"PostGIS\"\n      }\n    },\n    \"tasks\": [\n      {\n        \"id\": 0,\n        \"href\": \"http://localhost:8080/geoserver/rest/imports/1/tasks/0\",\n        \"state\": \"READY\"\n      }\n    ]\n  }\n}\n

                  Task:

                  curl -u admin:geoserver -XGET \\\n  http://localhost:8080/geoserver/rest/imports/1/tasks/0.json\n
                  {\n  \"task\": {\n    \"id\": 0,\n    \"href\": \"http://localhost:8080/geoserver/rest/imports/2/tasks/0\",\n    \"state\": \"READY\",\n    \"updateMode\": \"REPLACE\",\n    \"data\": {\n      \"type\": \"file\",\n      \"format\": \"CSV\",\n      \"file\": \"replace.csv\"\n    },\n    \"target\": {\n      \"href\": \"http://localhost:8080/geoserver/rest/imports/2/tasks/0/target\",\n      \"dataStore\": {\n        \"name\": \"postgis\",\n        \"type\": \"PostGIS\"\n      }\n    },\n    \"progress\": \"http://localhost:8080/geoserver/rest/imports/2/tasks/0/progress\",\n    \"layer\": {\n      \"name\": \"replace\",\n      \"href\": \"http://localhost:8080/geoserver/rest/imports/2/tasks/0/layer\"\n    },\n    \"transformChain\": {\n      \"type\": \"vector\",\n      \"transforms\": [\n        {\n          \"type\": \"AttributesToPointGeometryTransform\",\n          \"href\": \"http://localhost:8080/geoserver/rest/imports/2/tasks/0/transforms/0\"\n        }\n      ]\n    }\n  }\n}\n

                  Check layer to ensure name indicates layer to replace, and nativeName indicates the table contents to replace:

                  curl -u admin:geoserver -XGET \\\n  http://localhost:8080/geoserver/rest/imports/1/tasks/0/layer.json\n
                  {\n  \"layer\": {\n    \"name\": \"values\",\n    \"href\": \"http://localhost:8080/geoserver/rest/imports/1/tasks/0/layer\",\n    \"title\": \"values\",\n    \"originalName\": \"replace\",\n    \"nativeName\": \"replace\",\n    \"srs\": \"EPSG:4326\",\n    \"bbox\": {\n      \"minx\": 0,\n      \"miny\": 0,\n      \"maxx\": -1,\n      \"maxy\": -1\n    },\n    \"attributes\": [\n      {\n        \"name\": \"AssetID\",\n        \"binding\": \"java.lang.Integer\"\n      },\n      {\n        \"name\": \"SampleTime\",\n        \"binding\": \"java.lang.String\"\n      },\n      {\n        \"name\": \"Lat\",\n        \"binding\": \"java.lang.Double\"\n      },\n      {\n        \"name\": \"Lon\",\n        \"binding\": \"java.lang.Double\"\n      },\n      {\n        \"name\": \"Value\",\n        \"binding\": \"java.lang.Integer\"\n      }\n    ],\n    \"style\": {\n      \"name\": \"point\",\n      \"href\": \"http://localhost:8080/geoserver/rest/imports/1/tasks/0/layer/style\"\n    }\n  }\n}\n

                  Transform:

                  curl -u admin:geoserver -XGET \\\n  http://localhost:8080/geoserver/rest/imports/1/tasks/0/transforms/0.json\n
                6. To run the import:

                  curl -u admin:geoserver -XPOST \\\n  \"http://localhost:8080/geoserver/rest/imports/1\"\n
                "},{"location":"extensions/importer/rest_examples/#uploading-and-optimizing-a-geotiff-with-ground-control-points","title":"Uploading and optimizing a GeoTiff with ground control points","text":"

                A data supplier is periodically providing GeoTiffs that we need to configure in GeoServer. The GeoTIFF is referenced via Ground Control Points, is organized by stripes, and has no overviews. The objective is to rectify, optimize and publish it via the importer.

                First, we are going to create a empty import with no store as the target:

                curl -u admin:geoserver -XPOST -H \"Content-type: application/json\" -d @import.json \"http://localhost:8080/geoserver/rest/imports\"\n

                Where import.json is:

                {\n   \"import\": {\n      \"targetWorkspace\": {\n         \"workspace\": {\n            \"name\": \"sf\"\n         }\n      }\n   }\n}\n

                Then, we are going to POST the GeoTiff file to the tasks list, in order to create an import task for it:

                curl -u admin:geoserver -F name=test -F filedata=@box_gcp_fixed.tif \"http://localhost:8080/geoserver/rest/imports/0/tasks\"\n

                We are then going to append the transformations to rectify (gdalwarp), retile (gdal_translate) and add overviews (gdaladdo) to it:

                curl -u admin:geoserver -XPOST -H \"Content-type: application/json\" -d @warp.json \"http://localhost:8080/geoserver/rest/imports/0/tasks/0/transforms\"\ncurl -u admin:geoserver -XPOST -H \"Content-type: application/json\" -d @gtx.json \"http://localhost:8080/geoserver/rest/imports/0/tasks/0/transforms\"\ncurl -u admin:geoserver -XPOST -H \"Content-type: application/json\" -d @gad.json \"http://localhost:8080/geoserver/rest/imports/0/tasks/0/transforms\"\n

                warp.json is:

                {\n  \"type\": \"GdalWarpTransform\",\n  \"options\": [ \"-t_srs\", \"EPSG:4326\"]\n}\n

                gtx.json is:

                {\n  \"type\": \"GdalTranslateTransform\",\n  \"options\": [ \"-co\", \"TILED=YES\", \"-co\", \"BLOCKXSIZE=512\", \"-co\", \"BLOCKYSIZE=512\"]\n}\n

                gad.json is:

                {\n  \"type\": \"GdalAddoTransform\",\n  \"options\": [ \"-r\", \"average\"],\n  \"levels\" : [2, 4, 8, 16]\n}\n

                Now the import is ready to run, and we'll execute it using:

                curl -u admin:geoserver -XPOST \"http://localhost:8080/geoserver/rest/imports/0\"\n

                A new layer box_gcp_fixed layer will appear in GeoServer, with an underlying GeoTiff file ready for web serving.

                "},{"location":"extensions/importer/rest_examples/#adding-a-new-granule-into-an-existing-mosaic","title":"Adding a new granule into an existing mosaic","text":"

                A data supplier is periodically providing new time based imagery that we need to add into an existing mosaic in GeoServer. The imagery is in GeoTiff format, and lacks a good internal structure, which needs to be aligned with the one into the other images.

                First, we are going to create a import with an indication of where the granule is located, and the target store:

                curl -u admin:geoserver -XPOST -H \"Content-type: application/json\" -d @import.json \"http://localhost:8080/geoserver/rest/imports\"

                Where import.json is:

                {\n   \"import\": {\n      \"targetWorkspace\": {\n         \"workspace\": {\n            \"name\": \"topp\"\n         }\n      },\n      \"data\": {\n        \"type\": \"file\",\n        \"file\": \"/home/aaime/devel/gisData/ndimensional/data/world/world.200407.3x5400x2700.tiff\"\n      },\n      \"targetStore\": {\n         \"dataStore\": {\n            \"name\": \"bluemarble\"\n         }\n      }\n   }\n}\n

                We are then going to append the transformations to harmonize the file with the rest of the mosaic:

                curl -u admin:geoserver -XPOST -H \"Content-type: application/json\" -d @gtx.json \"http://localhost:8080/geoserver/rest/imports/0/tasks/0/transforms\"\ncurl -u admin:geoserver -XPOST -H \"Content-type: application/json\" -d @gad.json \"http://localhost:8080/geoserver/rest/imports/0/tasks/0/transforms\"\n

                gtx.json is:

                {\n  \"type\": \"GdalTranslateTransform\",\n  \"options\": [ \"-co\", \"TILED=YES\"]\n}\n

                gad.json is:

                {\n  \"type\": \"GdalAddoTransform\",\n  \"options\": [ \"-r\", \"average\"],\n  \"levels\" : [2, 4, 8, 16, 32, 64, 128]\n}\n

                Now the import is ready to run, and we'll execute it using:

                curl -u admin:geoserver -XPOST \"http://localhost:8080/geoserver/rest/imports/0\"\n

                The new granule will be ingested into the mosaic, and will thus be available for time based requests.

                "},{"location":"extensions/importer/rest_examples/#asynchronously-fetching-and-importing-data-from-a-remote-server","title":"Asynchronously fetching and importing data from a remote server","text":"

                We assume a remote FTP server contains multiple shapefiles that we need to import in GeoServer as new layers. The files are large, and the server has much better bandwidth than the client, so it's best if GeoServer performs the data fetching on its own.

                In this case a asynchronous request using remote data will be the best fit:

                curl -u admin:geoserver -XPOST -H \"Content-type: application/json\" -d @import.json \"http://localhost:8080/geoserver/rest/imports?async=true\"\n

                Where import.json is:

                {\n   \"import\": {\n      \"targetWorkspace\": {\n         \"workspace\": {\n            \"name\": \"topp\"\n         }\n      },\n      \"data\": {\n        \"type\": \"remote\",\n        \"location\": \"ftp://myserver/data/bc_shapefiles\",\n        \"username\": \"dan\",\n        \"password\": \"secret\"\n      }\n   }\n}\n

                The request will return immediately with an import context in \"INIT\" state, and it will remain in such state until the data is fetched and the tasks created. Once the state switches to \"PENDING\" the import will be ready for execution. Since there is a lot of shapefiles to process, also the import run will be done in asynchronous mode:

                curl -u admin:geoserver -XPOST \"http://localhost:8080/geoserver/rest/imports/0?async=true\"\n

                The response will return immediately in this case as well, and the progress can be followed as the tasks in the import switch state.

                "},{"location":"extensions/importer/rest_examples/#importing-and-optimizing-a-large-image-with-a-single-request","title":"Importing and optimizing a large image with a single request","text":"

                A large image appears every now and then on a mounted disk share, the image needs to be optimized and imported into GeoServer as a new layer. Since the source is large and we need to copy it on the local disk where the data dir resides, a \"remote\" data is the right tool for the job, an asynchronous execution is also recommended to avoid waiting on a possibly large command. In this case the request will also contains the \"exec=true\" parameter to force the importer an immediate execution of the command.

                The request will then look as follows:

                curl -u admin:geoserver -XPOST -H \"Content-type: application/json\" -d @import.json \"http://localhost:8080/geoserver/rest/imports?async=true&exec=true\"\n

                Where import.json is:

                {\n  \"import\": {\n    \"targetWorkspace\": {\n      \"workspace\": {\n        \"name\": \"topp\"\n      }\n    },\n    \"data\": {\n      \"type\": \"remote\",\n      \"location\": \"\\/mnt\\/remoteDisk\\/bluemarble.tiff\"\n    },\n    \"transforms\": [\n      {\n        \"type\": \"GdalTranslateTransform\",\n        \"options\": [\n          \"-co\", \"TILED=YES\",\n          \"-co\", \"COMPRESS=JPEG\",\n          \"-co\", \"JPEG_QUALITY=85\",\n          \"-co\", \"PHOTOMETRIC=YCBCR\"\n        ]\n      },\n      {\n        \"type\": \"GdalAddoTransform\",\n        \"options\": [\n          \"-r\",\n          \"average\",\n          \"--config\", \"COMPRESS_OVERVIEW\", \"JPEG\",\n          \"--config\", \"PHOTOMETRIC_OVERVIEW\", \"YCBCR\"\n        ],\n        \"levels\": [ 2, 4, 8, 16, 32, 64 ]\n      }\n    ]\n  }\n}\n

                Given the request is asynchronous, the client will have to poll the server in order to check if the initialization and execution have succeeded.

                "},{"location":"extensions/importer/rest_reference/","title":"REST API","text":""},{"location":"extensions/importer/rest_reference/#importer-concepts","title":"Importer concepts","text":"

                The importer REST api is built around a tree of objects representing a single import, structured as follows:

                • import
                  • target workspace
                  -   data\n\n-\n\n    task (one or more)\n\n    :   -   data\n        -   layer\n        -   transformation (one or more)\n

                An import refers to the top level object and is a \"session\" like entity the state of the entire import. It maintains information relevant to the import as a whole such as user information, timestamps along with optional information that is uniform along all tasks, such as a target workspace, the shared input data (e.g., a directory, a database). An import is made of any number of task objects.

                A data is the description of the source data of a import (overall) or a task. In case the import has a global data definition, this normally refers to an aggregate store such as a directory or a database, and the data associated to the tasks refers to a single element inside such aggregation, such as a single file or table.

                A task represents a unit of work to the importer needed to register one new layer, or alter an existing one, and contains the following information:

                • The data being imported
                • The target store that is the destination of the import
                • The target layer
                • The data of a task, referred to as its source, is the data to be processed as part of the task.
                • The transformations that we need to apply to the data before it gets imported

                This data comes in a variety of forms including:

                • A spatial file (Shapefile, GeoTiff, KML, etc...)
                • A directory of spatial files
                • A table in a spatial database
                • A remote location that the server will download data from

                A task is classified as either \"direct\" or \"indirect\". A direct task is one in which the data being imported requires no transformation to be imported. It is imported directly. An example of such a task is one that involves simply importing an existing Shapefile as is. An indirect task is one that does require a transformation to the original import data. An example of an indirect task is one that involves importing a Shapefile into an existing PostGIS database. Another example of indirect task might involve taking a CSV file as an input, turning a x and y column into a Point, remapping a string column into a timestamp, and finally import the result into a PostGIS.

                "},{"location":"extensions/importer/rest_reference/#rest-api-reference","title":"REST API Reference","text":""},{"location":"extensions/importer/rest_reference/#all-the-imports","title":"All the imports","text":""},{"location":"extensions/importer/rest_reference/#imports","title":"/imports","text":"Method Action Status Code/Headers Input Output Parameters GET Retrieve all imports 200 n/a Import Collection n/a POST Create a new import 201 with Location header n/a Imports async=false/true,execute=false/true"},{"location":"extensions/importer/rest_reference/#retrieving-the-list-of-all-imports","title":"Retrieving the list of all imports","text":"
                GET /imports     \n

                results in:

                Status: 200 OK\nContent-Type: application/json\n\n    {\n       \"imports\": [{\n         \"id\": 0,\n         \"state\": \"COMPLETE\",\n         \"href\": \"http://localhost:8080/geoserver/rest/imports/0\"\n\n       }, {\n         \"id\": 1,\n         \"state\": \"PENDING\",\n         \"href\": \"http://localhost:8080/geoserver/rest/imports/1\"          \n       }]\n    }\n
                "},{"location":"extensions/importer/rest_reference/#creating-a-new-import","title":"Creating a new import","text":"

                Posting to the /imports path a import json object creates a new import session:

                Content-Type: application/json\n\n{\n   \"import\": {\n      \"targetWorkspace\": {\n         \"workspace\": {\n            \"name\": \"scratch\"\n         }\n      },\n      \"targetStore\": {\n         \"dataStore\": {\n            \"name\": \"shapes\"\n         }\n      },\n      \"data\": {\n        \"type\": \"file\",\n        \"file\": \"/data/spearfish/archsites.shp\"\n      }\n   }\n}\n

                The parameters are:

                Name Optional Description

                targetWorkspace Y The target workspace to import to

                targetStore Y The target store to import to

                data Y The data to be imported

                The mere creation does not start the import, but it may automatically populate its tasks depending on the target. For example, by referring a directory of shapefiles to be importer, the creation will automatically fill in a task to import each of the shapefiles as a new layer.

                The response to the above POST request will be:

                Status: 201 Created\nLocation: http://localhost:8080/geoserver/rest/imports/2\nContent-Type: application/json\n\n{  \n  \"import\": {\n    \"id\": 2, \n    \"href\": \"http://localhost:8080/geoserver/rest/imports/2\", \n    \"state\": \"READY\", \n    \"targetWorkspace\": {\n      \"workspace\": {\n        \"name\": \"scratch\"\n      }\n    }, \n    \"targetStore\": {\n      \"dataStore\": {\n        \"name\": \"shapes\", \n        \"type\": \"PostGIS\"\n      }\n    }, \n    \"data\": {\n      \"type\": \"file\", \n      \"format\": \"Shapefile\", \n      \"href\": \"http://localhost:8080/geoserver/rest/imports/2/data\", \n      \"file\": \"archsites.shp\"\n    }, \n    \"tasks\": [\n      {\n        \"id\": 0, \n        \"href\": \"http://localhost:8080/geoserver/rest/imports/2/tasks/0\", \n        \"state\": \"READY\"\n      }\n    ]\n  }\n}\n

                The operation of populating the tasks can require time, especially if done against a large set of files, or against a \"remote\" data (more on this later), in this case the POST request can include ?async=true at the end of the URL to make the importer run it asynchronously. In this case the import will be created in INIT state and will remain in such state until all the data transfer and task creation operations are completed. In case of failure to fetch data the import will immediately stop, the state will switch to the INIT_ERROR state, and a error message will appear in the import context \"message\" field.

                Adding the \"execute=true\" parameter to the context creation will also make the import start immediately, assuming tasks can be created during the init phase. Combining both execute and async, \"?async=true&execute=true\" will make the importer start an asynchronous initialization and execution.

                The import can also have a list of default transformations, that will be applied to tasks as they get created, either out of the initial data, or by upload. Here is an example of a import context creation with a default transformation:

                {\n  \"import\": {\n    \"targetWorkspace\": {\n      \"workspace\": {\n        \"name\": \"topp\"\n      }\n    },\n    \"data\": {\n      \"type\": \"file\",\n      \"file\": \"/tmp/locations.csv\"\n    },\n    \"targetStore\": {\n      \"dataStore\": {\n        \"name\": \"h2\"\n      }\n    },\n    \"transforms\": [\n      {\n        \"type\": \"AttributesToPointGeometryTransform\",\n        \"latField\": \"LAT\",\n        \"lngField\": \"LON\"\n      }\n    ]\n  }\n}\n

                To get more information about transformations see the Transformation reference.

                "},{"location":"extensions/importer/rest_reference/#import-object","title":"Import object","text":""},{"location":"extensions/importer/rest_reference/#imports_1","title":"/imports/ Method Action Status Code/Headers Input Output Parameters GET Retrieve import with id 200 n/a Imports n/a POST Execute import with id 204 n/a n/a async=true/false PUT Create import with proposed id . If the proposed id is ahead of the current (next) id, the current id will be advanced. If the proposed id is less than or equal to the current id, the current will be used. This allows an external system to dictate the id management. 201 with Location header n/a Imports n/a DELETE Remove import with id 200 n/a n/a n/a

                The representation of a import is the same as the one contained in the import creation response. The execution of a import can be a long task, as such, it's possible to add async=true to the request to make it run in an asynchronous fashion, the client will have to poll the import representation and check when it reaches either the \"COMPLETE\" or \"COMPLETE_ERROR\" state.

                ","text":""},{"location":"extensions/importer/rest_reference/#data","title":"Data","text":"

                A import can have a \"data\" representing the source of the data to be imported. The data can be of different types, in particular, \"file\", \"directory\", \"mosaic\", \"database\" and \"remote\". During the import initialization the importer will scan the contents of said resource, and generate import tasks for each data found in it.

                Most data types are discussed in the task section, the only type that's specific to the whole import context is the \"remote\" one, that is used to ask the importer to fetch the data from a remote location autonomusly, without asking the client to perform an upload.

                The representation of a remote resource looks as follows:

                \"data\": {\n  \"type\": \"remote\",\n  \"location\": \"ftp://fthost/path/to/importFile.zip\",\n  \"username\": \"user\",\n  \"password\": \"secret\",\n  \"domain\" : \"mydomain\"\n}\n

                The location can be any URI supported by Commons VFS, including HTTP and FTP servers. The username, password and domain elements are all optional, and required only if the remote server demands an authentication of sorts. In case the referred file is compressed, it will be unpacked as the download completes, and the tasks will be created over the result of unpacking.

                "},{"location":"extensions/importer/rest_reference/#tasks","title":"Tasks","text":""},{"location":"extensions/importer/rest_reference/#importstasks","title":"/imports//tasks Method Action Status Code/Headers Input Output GET Retrieve all tasks for import with id 200 n/a Task Collection POST Create a new task 201 with Location header Multipart form data Tasks","text":""},{"location":"extensions/importer/rest_reference/#file_upload","title":"Getting the list of tasks
                GET /imports/0/tasks\n

                Results in:

                Status: 200 OK\nContent-Type: application/json\n\n{\n  \"tasks\": [\n    {\n      \"id\": 0, \n      \"href\": \"http://localhost:8080/geoserver/rest/imports/2/tasks/0\", \n      \"state\": \"READY\"\n    }\n  ]\n}\n
                ","text":""},{"location":"extensions/importer/rest_reference/#creating-a-new-task-as-a-file-upload","title":"Creating a new task as a file upload

                A new task can be created by issuing a POST to imports/<importId>/tasks as a \"Content-type: multipart/form-data\" multipart encoded data as defined by RFC 2388. One or more file can be uploaded this way, and a task will be created for importing them. In case the file being uploaded is a zip file, it will be unzipped on the server side and treated as a directory of files.

                The response to the upload will be the creation of a new task, for example:

                Status: 201 Created\nLocation: http://localhost:8080/geoserver/rest/imports/1/tasks/1\nContent-type: application/json\n\n{\n  \"task\": {\n    \"id\": 1, \n    \"href\": \"http://localhost:8080/geoserver/rest/imports/2/tasks/1\", \n    \"state\": \"READY\",\n    \"updateMode\": \"CREATE\", \n    \"data\": {\n      \"type\": \"file\", \n      \"format\": \"Shapefile\", \n      \"href\": \"http://localhost:8080/geoserver/rest/imports/2/tasks/1/data\", \n      \"file\": \"bugsites.shp\"\n    }, \n    \"target\": {\n      \"href\": \"http://localhost:8080/geoserver/rest/imports/2/tasks/1/target\", \n      \"dataStore\": {\n        \"name\": \"shapes\", \n        \"type\": \"PostGIS\"\n      }\n    },\n    \"progress\": \"http://localhost:8080/geoserver/rest/imports/2/tasks/1/progress\", \n    \"layer\": {\n      \"name\": \"bugsites\", \n      \"href\": \"http://localhost:8080/geoserver/rest/imports/2/tasks/1/layer\"\n    }, \n    \"transformChain\": {\n      \"type\": \"vector\", \n      \"transforms\": []\n    }\n  }\n}\n
                ","text":""},{"location":"extensions/importer/rest_reference/#creating-a-new-task-from-form-upload","title":"Creating a new task from form upload

                This creation mode assumes the POST to imports/<importId>/tasks of form url encoded data containing a url parameter:

                Content-type: application/x-www-form-urlencoded\n\nurl=file:///data/spearfish/\n

                The creation response will be the same as the multipart upload.

                ","text":""},{"location":"extensions/importer/rest_reference/#single-task-resource","title":"Single task resource","text":""},{"location":"extensions/importer/rest_reference/#importstasks_1","title":"/imports//tasks/ Method Action Status Code/Headers Input Output GET Retrieve task with id within import with id 200 n/a Task PUT Modify task with id within import with id 200 Task Task DELETE Remove task with id within import with id 200 n/a n/a

                The representation of a task resource is the same one reported in the task creation response.

                ","text":""},{"location":"extensions/importer/rest_reference/#updating-a-task","title":"Updating a task

                A PUT request over an existing task can be used to update its representation. The representation can be partial, and just contains the elements that need to be updated.

                The updateMode of a task may have different values.

                UpdateMode Description CREATE This is the default starting updateMode of a task, that is: create the target resource if missing. REPLACE For vector stores: delete the existing features in the target layer and replace them with those from the task source. For raster stores: replace the underlying data. When dealing with StructuredGridCoverage reader (e.g. ImageMosaic) the new file will be harvested (replacing the old one). For single raster coverages (e.g. GeoTIFF) the name of the file should be the same so that the coverageStore layer will preserve the original name (the old file will be deleted). APPEND Add the features from the task source into an existing layer.

                The following PUT request updates a task from \"CREATE\" to \"APPEND\" mode:

                Content-Type: application/json\n\n{\n  \"task\": {\n     \"updateMode\": \"APPEND\"\n  }\n}\n
                ","text":""},{"location":"extensions/importer/rest_reference/#directory-files-representation","title":"Directory files representation","text":"

                The following operations are specific to data objects of type directory.

                "},{"location":"extensions/importer/rest_reference/#importstasksdatafiles","title":"/imports//tasks//data/files Method Action Status Code/Headers Input Output GET Retrieve the list of files for a task with id within import with id 200 n/a Task

                The response to a GET request will be:

                Status: 200 OK\nContent-Type: application/json\n\n{\n    files: [\n        {\n        file: \"tasmania_cities.shp\",\n        href: \"http://localhost:8080/geoserver/rest/imports/0/tasks/0/data/files/tasmania_cities.shp\"\n        },\n        {\n        file: \"tasmania_roads.shp\",\n        href: \"http://localhost:8080/geoserver/rest/imports/0/tasks/0/data/files/tasmania_roads.shp\"\n        },\n        {\n        file: \"tasmania_state_boundaries.shp\",\n        href: \"http://localhost:8080/geoserver/rest/imports/0/tasks/0/data/files/tasmania_state_boundaries.shp\"\n        },\n        {\n        file: \"tasmania_water_bodies.shp\",\n        href: \"http://localhost:8080/geoserver/rest/imports/0/tasks/0/data/files/tasmania_water_bodies.shp\"\n        }\n    ]\n}\n
                ","text":""},{"location":"extensions/importer/rest_reference/#importstasksdatafiles_1","title":"/imports//tasks//data/files/ Method Action Status Code/Headers Input Output GET Retrieve the file with id from the data of a task with id within import with id 200 n/a Task DELETE Remove a specific file from the task with id within import with id 200 n/a n/a

                Following the links we'll get to the representation of a single file, notice how in this case a main file can be associate to sidecar files:

                Status: 200 OK\nContent-Type: application/json\n\n{\n    type: \"file\",\n    format: \"Shapefile\",\n    location: \"C:\\devel\\gs_data\\release\\data\\taz_shapes\",\n    file: \"tasmania_cities.shp\",\n    href: \"http://localhost:8080/geoserver/rest/imports/0/tasks/0/data/files/tasmania_cities.shp\",\n    prj: \"tasmania_cities.prj\",\n    other: [\n        \"tasmania_cities.dbf\",\n        \"tasmania_cities.shx\"\n    ]\n}\n
                ","text":""},{"location":"extensions/importer/rest_reference/#mosaic-extensions","title":"Mosaic extensions

                In case the input data is of mosaic type, we have all the attributes typical of a directory, plus support for directly specifying the timestamp of a particular granule.

                In order to specify the timestamp a PUT request can be issued against the granule:

                Content-Type: application/json\n\n{\n   \"timestamp\": \"2004-01-01T00:00:00.000+0000\"\n}\n

                and the response will be:

                Status: 200 OK\nContent-Type: application/json\n\n{\n  \"type\": \"file\", \n  \"format\": \"GeoTIFF\", \n  \"href\": \"http://localhost:8080/geoserver/rest/imports/0/tasks/0/data/files/bm_200401.tif\", \n  \"location\": \"/data/bluemarble/mosaic\", \n  \"file\": \"bm_200401.tiff\", \n  \"prj\": null, \n  \"other\": [], \n  \"timestamp\": \"2004-01-01T00:00:00.000+0000\"\n}\n
                ","text":""},{"location":"extensions/importer/rest_reference/#database-data","title":"Database data","text":"

                The following operations are specific to data objects of type database. At the time or writing, the REST API does not allow the creation of a database data source, but it can provide a read only description of one that has been created using the GUI.

                "},{"location":"extensions/importer/rest_reference/#importstasksdata","title":"/imports//tasks//data Method Action Status Code/Headers Input Output GET Retrieve the database connection parameters for a task with id within import with id 200 n/a List of database connection parameters and available tables

                Performing a GET on a database type data will result in the following response:

                {\n    type: \"database\",\n    format: \"PostGIS\",\n    href: \"http://localhost:8080/geoserver/rest/imports/0/data\",\n    parameters: {\n        schema: \"public\",\n        fetch size: 1000,\n        validate connections: true,\n        Connection timeout: 20,\n        Primary key metadata table: null,\n        preparedStatements: true,\n        database: \"gttest\",\n        port: 5432,\n        passwd: \"cite\",\n        min connections: 1,\n        dbtype: \"postgis\",\n        host: \"localhost\",\n        Loose bbox: true,\n        max connections: 10,\n        user: \"cite\"\n    },\n    tables: [\n        \"geoline\",\n        \"geopoint\",\n        \"lakes\",\n        \"line3d\",\n    ]\n}\n
                ","text":""},{"location":"extensions/importer/rest_reference/#database-table","title":"Database table","text":"

                The following operations are specific to data objects of type table. At the time or writing, the REST API does not allow the creation of a database data source, but it can provide a read only description of one that has been created using the GUI. A table description is normally linked to task, and refers to a database data linked to the overall import.

                "},{"location":"extensions/importer/rest_reference/#importstasksdata_1","title":"/imports//tasks//data Method Action Status Code/Headers Input Output GET Retrieve the table description for a task with id within import with id 200 n/a A table representation

                Performing a GET on a database type data will result in the following response:

                {\n    type: \"table\",\n    name: \"abc\",\n    format: \"PostGIS\",\n    href: \"http://localhost:8080/geoserver/rest/imports/0/tasks/0/data\"\n}\n
                ","text":""},{"location":"extensions/importer/rest_reference/#task-target-layer","title":"Task target layer","text":""},{"location":"extensions/importer/rest_reference/#importstaskslayer","title":"/imports//tasks//layer

                The layer defines how the target layer will be created

                Method Action Status Code/Headers Input Output GET Retrieve the layer of a task with id within import with id 200 n/a A layer JSON representation PUT Modify the target layer for a task with id within import with id 200 Task Task

                Requesting the task layer will result in the following:

                Status: 200 OK\nContent-Type: application/json\n\n{\n    layer: {\n    name: \"tasmania_cities\",\n    href: \"http://localhost:8080/geoserver/rest/imports/0/tasks/0/layer\",\n    title: \"tasmania_cities\",\n    originalName: \"tasmania_cities\",\n    nativeName: \"tasmania_cities\",\n    srs: \"EPSG:4326\",\n    bbox: {\n        minx: 147.2909004483,\n        miny: -42.85110181689001,\n        maxx: 147.2911004483,\n        maxy: -42.85090181689,\n        crs: \"GEOGCS[\"WGS 84\", DATUM[\"World Geodetic System 1984\", SPHEROID[\"WGS 84\", 6378137.0, 298.257223563, AUTHORITY[\"EPSG\",\"7030\"]], AUTHORITY[\"EPSG\",\"6326\"]], PRIMEM[\"Greenwich\", 0.0, AUTHORITY[\"EPSG\",\"8901\"]], UNIT[\"degree\", 0.017453292519943295], AXIS[\"Geodetic longitude\", EAST], AXIS[\"Geodetic latitude\", NORTH], AUTHORITY[\"EPSG\",\"4326\"]]\"\n    },\n    attributes: [\n        {\n            name: \"the_geom\",\n            binding: \"org.locationtech.jts.geom.MultiPoint\"\n        },\n        {\n            name: \"CITY_NAME\",\n            binding: \"java.lang.String\"\n        },\n        {\n            name: \"ADMIN_NAME\",\n            binding: \"java.lang.String\"\n        },\n        {\n            name: \"CNTRY_NAME\",\n            binding: \"java.lang.String\"\n        },\n        {\n            name: \"STATUS\",\n            binding: \"java.lang.String\"\n        },\n        {\n            name: \"POP_CLASS\",\n            binding: \"java.lang.String\"\n        }\n        ],\n        style: {\n            name: \"cite_tasmania_cities\",\n            href: \"http://localhost:8080/geoserver/rest/imports/0/tasks/0/layer/style\"\n        }\n    }\n}\n

                All the above attributes can be updated using a PUT request. Even if the above representation is similar to the REST config API, it should not be confused with it, as it does not support all the same properties, in particular the supported properties are all the ones listed above.

                ","text":""},{"location":"extensions/importer/rest_reference/#task-transformations","title":"Task transformations","text":""},{"location":"extensions/importer/rest_reference/#importstaskstransforms","title":"/imports//tasks//transforms Method Action Status Code/Headers Input Output GET Retrieve the list of transformations of a task with id within import with id 200 n/a A list of transfromations in JSON format POST Create a new transformation and append it inside a task with id within import with id 201 A JSON transformation representation The transform location","text":""},{"location":"extensions/importer/rest_reference/#retrieving-the-transformation-list","title":"Retrieving the transformation list

                A GET request for the list of transformations will result in the following response:

                Status: 200 OK\nContent-Type: application/json\n\n{\n  \"transforms\": [\n    {\n      \"type\": \"ReprojectTransform\", \n      \"href\": \"http://localhost:8080/geoserver/rest/imports/0/tasks/1/transforms/0\", \n      \"source\": null, \n      \"target\": \"EPSG:4326\"\n    }, \n    {\n      \"type\": \"DateFormatTransform\", \n      \"href\": \"http://localhost:8080/geoserver/rest/imports/0/tasks/1/transforms/1\", \n      \"field\": \"date\", \n      \"format\": \"yyyyMMdd\"\n    }\n  ]\n}\n
                ","text":""},{"location":"extensions/importer/rest_reference/#appending-a-new-transformation","title":"Appending a new transformation

                Creating a new transformation requires posting a JSON document with a type property identifying the class of the transformation, plus any extra attribute required by the transformation itself (this is transformation specific, each one will use a different set of attributes).

                The following POST request creates an attribute type remapping:

                Content-Type: application/json\n\n{\n   \"type\": \"AttributeRemapTransform\",\n   \"field\": \"cat\",\n   \"target\": \"java.lang.Integer\"\n}\n

                The response will be:

                Status: 201 OK\nLocation: http://localhost:8080/geoserver/rest/imports/0/tasks/1/transform/2\n
                ","text":""},{"location":"extensions/importer/rest_reference/#importstaskstransforms_1","title":"/imports//tasks//transforms/ Method Action Status Code/Headers Input Output GET Retrieve a transformation identified by inside a task with id within import with id 200 n/a A single transformation in JSON format PUT Modifies the definition of a transformation identified by inside a task with id within import with id 200 A JSON transformation representation (eventually just the portion of it that needs to be modified) The full transformation representation DELETE Removes the transformation identified by inside a task with id within import with id 200 A JSON transformation representation (eventually just the portion of it that needs to be modified) The full transformation representation","text":""},{"location":"extensions/importer/rest_reference/#retrieve-a-single-transformation","title":"Retrieve a single transformation

                Requesting a single transformation by identifier will result in the following response:

                Status: 200 OK\nContent-Type: application/json\n\n{\n  \"type\": \"ReprojectTransform\", \n  \"href\": \"http://localhost:8080/geoserver/rest/imports/0/tasks/1/transforms/0\", \n  \"source\": null, \n  \"target\": \"EPSG:4326\"\n}\n
                ","text":""},{"location":"extensions/importer/rest_reference/#modify-an-existing-transformation","title":"Modify an existing transformation

                Assuming we have a reprojection transformation, and that we need to change the target SRS type, the following PUT request will do the job:

                Content-Type: application/json\n{\n   \"type\": \"ReprojectTransform\",\n   \"target\": \"EPSG:3005\"\n}\n

                The response will be:

                Status: 200 OK\nContent-Type: application/json\n\n{\n  \"type\": \"ReprojectTransform\", \n  \"href\": \"http://localhost:8080/geoserver/rest/imports/0/tasks/1/transform/0\", \n  \"source\": null, \n  \"target\": \"EPSG:3005\"\n}\n
                ","text":""},{"location":"extensions/importer/rest_reference/#transformations","title":"Transformation reference","text":""},{"location":"extensions/importer/rest_reference/#attributeremaptransform","title":"AttributeRemapTransform

                Remaps a certain field to a given target data type

                Parameter Optional Description field N The name of the field to be remapped target N The \"target\" field type, as a fully qualified Java class name","text":""},{"location":"extensions/importer/rest_reference/#attributecomputetransform","title":"AttributeComputeTransform

                Computes a new field based on an expression that can use the other field values

                Parameter Optional Description field N The name of the field to be computed fieldType N The field type, as a fully qualified Java class name (e.g., java.lang.String, java.lang.Integer, java.util.Date and so on) cql N The (E)CQL expression used to compute the new field (can be a constant value, e.g. 'My String')","text":""},{"location":"extensions/importer/rest_reference/#attributestopointgeometrytransform","title":"AttributesToPointGeometryTransform

                Transforms two numeric fields latField and lngField into a point geometry representation with pointFieldName setting name of the point POINT(lngField,latField), the source fields will be removed if preserveGeometry is false.

                Parameter Optional Description latField N The \"latitude\" field lngField N The \"longitude\" field pointFieldName Y The name of the point preserveGeometry Y Setting this flag will prevent source fields from removal (false by default)","text":""},{"location":"extensions/importer/rest_reference/#createindextransform","title":"CreateIndexTransform

                For database targets only, creates an index on a given column after importing the data into the database

                Parameter Optional Description field N The field to be indexed","text":""},{"location":"extensions/importer/rest_reference/#dateformattransform","title":"DateFormatTransform

                Parses a string representation of a date into a Date/Timestamp object

                Parameter Optional Description field N The field to be parsed format Y A date parsing pattern, setup using the Java SimpleDateFormat syntax. In case it's missing, a number of built-in formats will be tried instead (short and full ISO date formats, dates without any separators). enddate Y The field used as end date for the time dimension. presentation Y The time dimension presentation type; one of","text":""},{"location":"extensions/importer/rest_reference/#integerfieldtodatetransform","title":"IntegerFieldToDateTransform

                Takes a integer field and transforms it to a date, interpreting the intereger field as a date

                Parameter Optional Description field N The field containing the year information","text":""},{"location":"extensions/importer/rest_reference/#reprojecttransform","title":"ReprojectTransform

                Reprojects a vector layer from a source CRS to a target CRS

                Parameter Optional Description source Y Identifier of the source coordinate reference system (the native one will be used if missing) target N Identifier of the target coordinate reference system","text":""},{"location":"extensions/importer/rest_reference/#gdaltranslatetransform","title":"GdalTranslateTransform

                Applies gdal_translate to a single file raster input. Requires gdal_translate to be inside the PATH used by the web container running GeoServer.

                Parameter Optional Description options N Array of options that will be passed to gdal_translate (beside the input and output names, which are internally managed)","text":""},{"location":"extensions/importer/rest_reference/#gdalwarptransform","title":"GdalWarpTransform

                Applies gdalwarp to a single file raster input. Requires gdalwarp to be inside the PATH used by the web container running GeoServer.

                Parameter Optional Description options N Array of options that will be passed to gdalwarp (beside the input and output names, which are internally managed)","text":""},{"location":"extensions/importer/rest_reference/#gdaladdotransform","title":"GdalAddoTransform

                Applies gdaladdo to a single file raster input. Requires gdaladdo to be inside the PATH used by the web container running GeoServer.

                Parameter Optional Description options N Array of options that will be passed to gdaladdo (beside the input file name, which is internally managed) levels N Array of integers with the overview levels that will be passed to gdaladdo","text":""},{"location":"extensions/importer/rest_reference/#postscripttransform","title":"PostScriptTransform

                Runs the specified script after the data is imported. The script must be located in $GEOSERVER_DATA_DIR/importer/scripts. The script can be any executable file. At the time of writing, there is no way to pass information about the data just imported to the script (TBD).

                Parameter Optional Description name N Name of the script to be invoked options Y Array of options that will be passed to the script","text":""},{"location":"extensions/importer/using/","title":"Using the Importer extension","text":"

                Here are step-by-step instructions to import multiple shapefiles in one operation. For more details on different types of operations, please see Importer interface reference.

                1. Find a directory of shapefiles and copy into your GeoServer data directory.

                  Note

                  You can always use the Natural Earth Quickstart data for this task.

                2. Log in as an administrator and navigate to the Data \u2192 Import Data page.

                3. For select Spatial Files as the data source.

                  Data source

                4. Click Browse to navigate to the directory of shapefiles to be imported.

                5. The web-based file browser will show as options your home directory, data directory, and the root of your file system (or drive). In this case, select Data directory

                  Directory

                6. Back on the main form, select Create new next to Workspace, and enter ne to denote the workspace.

                  Note

                  Make sure the Store field reads Create new as well.

                  Import target workspace

                7. Click Next to start the import process.

                8. On the next screen, any layers available for import will be shown.

                  Note

                  Non-spatial files will be ignored.

                  Import layer list

                9. In most cases, all files will be ready for import, but if the spatial reference system (SRS) is not recognized, you will need to manually input this but clicking Advanced

                  Note

                  You will need to manually input the SRS if you used the Natural Earth data above. For each layer click on Advanced and set reprojection to EPSG:4326.

                  Advanced import settings

                10. Check the box next to each layer you wish to import.

                  Setting the layers to import

                11. When ready, click Import.

                  Warning

                  Don't click Done at this point, otherwise the import will be canceled.

                12. The results of the import process will be shown next to each layer.

                13. When finished, click Done.

                  Note

                  Recent import processes are listed at the bottom of the page. You may wish to visit these pages to check if any difficulties were encountered during the import process or import additional layers.

                  Recent imports

                "},{"location":"extensions/inspire/","title":"INSPIRE","text":"

                The INSPIRE extension allows GeoServer to be compliant with the View Service and Download Service specifications put forth by the Infrastructure for Spatial Information in the European Community (INSPIRE) directive.

                In practice this means adding some extra elements into an extended capabilities section of the WMS, WFS and WCS capabilities documents. For WMS, WFS and WCS this includes a Metadata URL element with a link to the metadata associated with the service, and SupportedLanguages and ResponseLanguage elements which report the response language (GeoServer can only support one response language). For WFS and WCS there are also one or more SpatialDataSetIdentifier elements for each spatial data resource served by the service.

                Note

                The current INSPIRE extension fulfills \"Scenario 1\" of the View Service extended metadata requirements. \"Scenario 2\" is not currently supported in GeoServer, but is certainly possible to implement. If you are interested in implementing or funding this, please raise the issue on the GeoServer mailing list.

                For more information on the INSPIRE directive, please see the European Commission's INSPIRE website.

                • Installing the INSPIRE extension
                • Using the INSPIRE extension
                "},{"location":"extensions/inspire/installing/","title":"Installing the INSPIRE extension","text":"
                1. Visit the website download page, locate your release, and download: inspire

                  Verify that the version number in the filename (for example 2.24.2 above) corresponds to the version of GeoServer you are running.

                2. Extract the archive and copy the contents into the GeoSever WEB-INF/lib directory.

                3. Restart GeoServer.

                To verify that the extension was installed successfully, please see the next section on Using the INSPIRE extension.

                "},{"location":"extensions/inspire/using/","title":"Using the INSPIRE extension","text":"

                When the INSPIRE extension has been properly installed, the WMS settings, WFS settings and WCS settings sections of the Web administration interface will show an extra INSPIRE configuration section. If the data directory has not been configured with INSPIRE parameters before, this section will just contain a check box to enable the creation of an INSPIRE ExtendedCapabilities element.

                Note

                If you do not see this content in the service configuration pages, the INSPIRE extension may not be installed properly. Reread the section on Installing the INSPIRE extension and verify that the correct file was saved to the correct directory.

                "},{"location":"extensions/inspire/using/#extended-wms-and-wmts-configuration","title":"Extended WMS and WMTS configuration","text":"

                INSPIRE-specific configuration is accessed on the main WMS settings or WMTS settings page in the Web administration interface. This is accessed by clicking on the WMS or WMTS link on the sidebar.

                Note

                You must be logged in as an administrator to edit WMS or WMTS configuration.

                Once on the service configuration page, there will be a block titled INSPIRE. If you enable the checkbox shown above this section will have three additional settings:

                • Default Language combo box, for setting the Default
                • Other Supported Languages area for setting Supported Languages
                • Service Metadata URL field, a URL containing the location of the metadata associated with the service
                • Service Metadata Type combo box, for detailing whether the metadata came from a CSW (Catalog Service) or a standalone metadata file

                INSPIRE-related options

                After clicking Submit on this page, any changes will be immediately reflected in the services (WMS 1.3.0 or WMTS 1.0.0) capabilities document.

                Note

                The Service Metadata URL field is mandatory so you will not be allowed to submit a blank value.

                Note

                The Service Metadata Type combo box only allows to select the appropriate MIME type for a CSW response or standalone metadata file or to omit a value altogether. If you think other values would be useful you could raise the issue on the GeoServer mailing list. In the meantime it is possible to manually edit the created configuration files as a workaround.

                "},{"location":"extensions/inspire/using/#extended-wms-and-wmts-capabilities","title":"Extended WMS and WMTS Capabilities","text":"

                Note

                The INSPIRE extension only modifies the WMS 1.3.0 response, so please make sure that you are viewing the correct capabilities document.

                The WMS 1.3.0 and WMTS 1.0.0 capabilities document will contain two additional entries in the xsi:schemaLocation of the root <WMS_Capabilities> tag once the INSPIRE extension is installed:

                • http://inspire.ec.europa.eu/schemas/inspire_vs/1.0
                • https://inspire.ec.europa.eu/schemas/inspire_vs/1.0/inspire_vs.xsd

                If you have enabled the check box to create the INSPIRE ExtendedCapabilities element and entered the values described in the previous section then there will also be an additional ExtendedCapabilities block. This tag block shows up in between the tags for <Exception> and <Layer>. It contains the following information:

                • Metadata URL and MIME type
                • Supported Language(s)
                • Response Language

                With the example values shown in the above configuration panel, this block would contain the following content:

                <inspire_vs:ExtendedCapabilities>\n <inspire_common:MetadataUrl>\n  <inspire_common:URL>\n   http://mysite.org/metadata.xml\n  </inspire_common:URL>\n  <inspire_common:MediaType>\n   application/vnd.iso.19139+xml\n  </inspire_common:MediaType>\n </inspire_common:MetadataUrl>\n <inspire_common:SupportedLanguages>\n  <inspire_common:DefaultLanguage>\n   <inspire_common:Language>eng</inspire_common:Language>\n  </inspire_common:DefaultLanguage>\n  <inspire_common:SupportedLanguage>fre</inspire_common:SupportedLanguage>\n </inspire_common:SupportedLanguages>\n <inspire_common:ResponseLanguage>\n  <inspire_common:Language>eng</inspire_common:Language>\n </inspire_common:ResponseLanguage>\n</inspire_vs:ExtendedCapabilities>\n

                ISNPIRE recommends that every layer offered by a INSPIRE WMTS should use the InspireCRS84Quad grid set which is already configured in GeoServer, but is up to the user to select it when publishing a INSPIRE WMTS layer.

                "},{"location":"extensions/inspire/using/#extended-wfs-and-wcs-configuration","title":"Extended WFS and WCS configuration","text":"

                INSPIRE-specific configuration is accessed on the main WFS settings and WCS settings pages in the Web administration interface. These are accessed by clicking on the WFS and WCS links on the sidebar respectively.

                Note

                You must be logged in as an administrator to edit WFS configuration.

                Once on the WFS or WCS configuration page, there will be a block titled INSPIRE. If you enable the checkbox shown above this section will have the following additional settings:

                • Language combo box, for setting the Supported, Default, and Response languages
                • Other Supported Languages area for setting Supported Languages
                • Service Metadata URL field, a URL containing the location of the metadata associated with the WFS or WCS
                • Service Metadata Type combo box, for detailing whether the metadata came from a CSW (Catalog Service) or a standalone metadata file
                • Spatial dataset identifiers table, where you can specify a code (mandatory), a namespace (optional) and a metadata URL (optional) for each spatial data set the WFS or WCS is offering

                INSPIRE-related options

                After clicking Submit on this page, any changes will be immediately reflected in the WFS 1.1 and WFS 2.0 or WCS 2.0 capabilities documents as appropriate.

                Note

                The Service Metadata URL field and at least one Spatial dataset identifiers entry are mandatory so you will not be allowed to submit the page without these.

                Note

                The Service Metadata Type combo box only allows to select the appropriate MIME type for a CSW response or standalone metadata file or to omit a value altogether. If you think other values would be useful you could raise the issue on the GeoServer mailing list. In the meantime it is possible to manually edit the created configuration files as a workaround.

                "},{"location":"extensions/inspire/using/#extended-wfs-and-wcs-capabilities","title":"Extended WFS and WCS Capabilities","text":"

                Note

                The INSPIRE directive is relevant to WFS 1.1 and 2.0 and WCS 2.0 only, so please make sure that you are viewing the correct capabilities document.

                The WFS and WCS capabilities documents will contain two additional entries in the xsi:schemaLocation of the root element tag once the INSPIRE extension is installed:

                • https://inspire.ec.europa.eu/schemas/common/1.0/common.xsd
                • https://inspire.ec.europa.eu/schemas/inspire_dls/1.0/inspire_dls.xsd

                If you have enabled the check box to create the INSPIRE ExtendedCapabilities element and entered the values described in the previous section then there will also be an additional ExtendedCapabilities block with the following information:

                • Metadata URL and MIME type
                • Supported Language(s)
                • Response Language
                • Spatial data identifier(s)

                With the example values shown in the above configuration panel, this block would contain the following content:

                <inspire_dls:ExtendedCapabilities>\n  <inspire_common:MetadataUrl>\n    <inspire_common:URL>\n      http://mysite.org/csw?SERVICE=CSW&REQUEST=GetRecord\n    </inspire_common:URL>\n    <inspire_common:MediaType>\n      application/vnd.iso.19139+xml\n    </inspire_common:MediaType>\n  </inspire_common:MetadataUrl>\n  <inspire_common:SupportedLanguages>\n    <inspire_common:DefaultLanguage>\n     <inspire_common:Language>eng</inspire_common:Language>\n    </inspire_common:DefaultLanguage>\n    <inspire_common:SupportedLanguage>fre</inspire_common:SupportedLanguage>\n  </inspire_common:SupportedLanguages>\n  <inspire_common:ResponseLanguage>\n    <inspire_common:Language>eng</inspire_common:Language>\n  </inspire_common:ResponseLanguage>\n  <inspire_dls:SpatialDataSetIdentifier metadataURL=\"http://mysite.org/ds/md/ds1.xml\">\n    <inspire_common:Code>\n     fc929094-8a30-2617-e044-002128a47908\n    </inspire_common:Code>\n  <inspire_common:Namespace>\n     http://metadata.mysite.org/ds\n  </inspire_common:Namespace>\n </inspire_dls:SpatialDataSetIdentifier>\n</inspire_dls:ExtendedCapabilities>\n

                The spatial data identifiers section is mandatory, but cannot be filled by default, it is your duty to provide at least one spatial dataset identifier (see the INSPIRE download service technical guidelines for more information).

                "},{"location":"extensions/inspire/using/#internationalization-support","title":"Internationalization support","text":"

                GeoServer offers the ability to configure GetCapabilities response in multiple languages. Content in different languages can be requested by using the request parameter Language, e.g. Language=eng. At the time of writing, the following services support the parameter: WFS 2.0, WMS 1.1 and 1.3, WCS 2.0.

                At the time of writing the INSPIRE Schemas only allow 23 choices for DefaultLanguage. The GeoServer INSPIRE extension allows some other languages to be chosen. If you choose one of these your capabilities document won't be Schema valid but, as discussed in issue 7388, the INSPIRE Schemas seem to be at fault.

                The language list available from the UI is define in a classpath file named available_languages.properties with the following content:

                bul=bg\ncze=cs\ndan=da\ndut=nl\neng=en\nest=et\nfin=fi\nfre=fr\nhrv=hr\nice=is\nger=de\ngle=ga\ngre=el\ngsw=de-CH\nhun=hu\nita=it\nlav=lv\nlit=lt\nmlt=mt\nnor=nb\npol=pl\npor=pt\nrum=ro\nslo=sk\nslv=sl\nspa=es\nswe=sv\n

                The entries of the above list represent the available INSPIRE language code matched with the corresponding ISO 639-1 code. The GeoServer internationalization support is based on OWS 2.0, and thus using ISO codes internally. The INSPIRE module maps on the fly the INSPIRE names to ISO codes based on the above property file. The property file can be overridden by placing a properties file named available_languages.properties in the inspire directory inside the GeoServer data directory.

                "},{"location":"extensions/jp2k/","title":"JP2K Plugin","text":"

                GeoServer can leverage the JP2K Geotools plugin to read JP2K coverage formats. In case you have a Kakadu license and you have built your set of native libraries, you will be able to access the JP2K data with higher performances leveraging on it. Otherwise you will use the standard SUN's JP2K. See GeoTools JP2K Plugin for further information.

                "},{"location":"extensions/jp2k/#installing-kakadu","title":"Installing Kakadu","text":"

                In order for GeoServer to leverage on the Kakadu libraries, the Kakadu binaries must be installed through your host system's OS.

                If you are on Windows, make sure that the Kakadu DLL files are on your PATH. If you are on Linux, be sure to set the LD_LIBRARY_PATH environment variable to be the folder where the SOs are extracted.

                Once these steps have been completed, restart GeoServer. If done correctly, new data formats will be in the Raster Data Sources list when creating a new data store:

                Raster Data Source

                Configuring a JP2K data store

                "},{"location":"extensions/libjpeg-turbo/","title":"libjpeg-turbo Map Encoder Extension","text":"

                This plugin brings in the ability to encode JPEG images as WMS output using the libjpeg-turbo library. Citing its website the libjpeg-turbo library is a derivative of libjpeg that uses SIMD instructions (MMX, SSE2, NEON) to accelerate baseline JPEG compression and decompression on x86, x86-64, and ARM systems. On such systems, libjpeg-turbo is generally 2-4x as fast as the unmodified version of libjpeg, all else being equal. I guess it is pretty clear why we wrote this plugin! Note that the underlying imageio-ext-turbojpeg uses TurboJpeg which is a higher level set of API (providing more user-friendly methods like \"Compress\") built on top of libjpeg-turbo.

                Warning

                The speedup may vary depending on the target infrastructure.

                The module, once installed, simply replace the standard JPEG encoder for GeoServer and allows us to use the libjpeg-turbo library to encode JPEG response for GetMap requests.

                Note

                It is worth to point out that the module depends on a successful installation of the libjpeg-turbo native libraries (more on this later).

                "},{"location":"extensions/libjpeg-turbo/#installing-the-libjpeg-turbo-native-library","title":"Installing the libjpeg-turbo native library","text":"

                Installing the libjpeg-turbo native library is a precondition to have the relative GeoServer Map Encoder properly installed; once the GeoServer extension has been installed as we explain in the following section, the needed JARs with the Java bridge to the library are in the classpath, therefore all we need to do is to install the native library itself to start encoding JPEG at turbo speed.

                To perform the installation of the libjpeg-turbo binaries (or native library) you have to perform the following steps:

                1. Go to the download site here and download the latest available stable release (1.2.90 at the time of writing)
                2. Select the package that matches the target platform in terms of Operating System (e.g. Linux rather than Windows) and Architecture (32 vs 64 bits)
                3. Perform the installation using the target platform conventions. As an instance for Windows you should be using an installer that installs all the needed libs in a location at user's choice. On Ubuntu Linux systems you can use the deb files instead.
                4. Once the native libraries are installed, you have to make sure the GeoServer can load them. This should happen automatically after Step 2 on Linux, while on Windows you should make sure that the location where you placed the DLLs is part of the PATH environment variable for the Java Process for the GeoServer.

                Warning

                When installing on Windows, always make sure that the location where you placed the DLLs is part of the PATH environment variable for the Java Process for the GeoServer. This usually means that you have to add such location to the PATH environmental variable for the user that is used to run GeoServer or the system wide variables.

                Warning

                When installing on Linux, make sure that the location where you placed the DLLs is part of the LD_LIBRARY_PATH environment variable for the Java Process for the GeoServer. This usually happens automatically for the various Linux packages, but in some cases you might be forced to do that manually

                Note

                It does not hurt to add also the location where the native libraries where installed to the Java startup options -Djava.library.path="},{"location":"extensions/libjpeg-turbo/#installing-the-geoserver-libjpeg-turbo-extension","title":"Installing the GeoServer libjpeg-turbo extension","text":"

                ::: warning ::: title Warning :::

                Before moving on make sure you installed the libjpeg-turbo binaries as per the section above. :::

                1. Visit the website download page, locate your release, and download: libjpeg-turbo

                  Warning

                  Make sure to match the version of the extension (for example 2.24.2 above) to the version of the GeoServer instance!

                1. Extract the contents of the archive into the WEB-INF/lib directory of the GeoServer installation.
                "},{"location":"extensions/libjpeg-turbo/#checking-if-the-extension-is-enabled","title":"Checking if the extension is enabled","text":"

                Once the extension is installed, the following lines should appear in the GeoServer log:

                10-mar-2013 19.16.28 it.geosolutions.imageio.plugins.turbojpeg.TurboJpegUtilities load\nINFO: TurboJPEG library loaded (turbojpeg)\n

                or:

                10 mar 19:17:12 WARN [turbojpeg.TurboJPEGMapResponse] - The turbo jpeg encoder is available for usage\n

                You can also check in the Server Status page. From the Modules tab:

                • Locate the GeoServer libjpeg-turbo Module module. The enabled status indicates if the extension is available
                • Click on the GeoServer libjpeg-turbo Module link to check module status. The Module Info dialog indicates the JNI LibJPEGTurbo Wrapper Version used.
                "},{"location":"extensions/libjpeg-turbo/#disabling-the-extension","title":"Disabling the extension","text":"

                When running GeoServer the turb encoder can be disabled by using the Java switch for the JVM process:

                -Ddisable.turbojpeg=true\n

                In this case a message like the following should be found in the log:

                WARN [map.turbojpeg] - The turbo jpeg encoder has been explicitly disabled\n

                Note

                We will soon add a section in the GUI to check the status of the extension and to allow users to enable/disable it at runtime.

                "},{"location":"extensions/mapml/","title":"MapML","text":"

                Map Markup Language (MapML) is a text-based format which allows map authors to encode map information as hypertext documents exchanged over the Uniform Interface of the Web. The format definition is a work-in-progress by the Maps for HTML W3C Community Group. Various tools to work with the format exist, including a Leaflet-based map viewer included in the GeoServer MapML extension. For more information on MapML refer to the Maps for HTML Community Group <https://maps4html.org/>.

                The MapML module for GeoServer adds new MapML resources to access WMS, WMTS and WFS services configured in Geoserver. The MapML modules includes support for styles, tiling, querying, and dimensions options for WMS layers, and also provides a MapML outputFormat for WMS GetFeatureInfo and WFS GetFeatures requests. See below for information on installing and configuring the MapML module.

                ::: note ::: title Note :::

                The Maps for HTML community kindly requests that if you use MapML and the software provided here or elsewhere, that you give us feedback about your experience: open an issue or start a discussion on GitHub. :::

                ::: warning ::: title Warning :::

                MapML is an experimental proposed extension of HTML for the Web. The objective of the project is to standardize map, layer and feature semantics in HTML. As the format progresses towards a Web standard, it may change slightly. Always use the latest version of this extension, and follow or join in the project's progress at https://maps4html.org. :::

                "},{"location":"extensions/mapml/#installation","title":"Installation","text":"
                1. Visit the website download page, locate your release, and download: mapml

                  Warning

                  Make sure to match the version of the extension (for example 2.24.2 above) to the version of the GeoServer instance!

                2. Extract the contents of the archive into the WEB-INF/lib directory of the GeoServer installation.

                3. Restart GeoServer.

                "},{"location":"extensions/mapml/#configuration","title":"Configuration","text":"

                Configuration can be done using the Geoserver administrator GUI. The MapML configuration is accessible in the MapML Settings section under the Publishing tab of the Layer or Layer Group Configuration page for the layer or layer group being configured. Here is the MapML Settings section, with some example values filled in:

                There is also a MapML-specific global WMS setting in the MapML Extension section of the WMS Services Settings Page. This setting is used to control the handling of multi-layer requests.

                If the Represent multi-layer requests as multiple elements is checked (and the configuration is saved), an individually accessible element will be generated for each requested layer. The default is to represent the layers as a single (hidden) .

                "},{"location":"extensions/mapml/#styles","title":"Styles","text":"

                Like any WMS layer or layer group available from GeoServer, a comma-separated list of styles may be supplied in the WMS GetMap styles parameter. If no style name is requested, the default style will be used for that layer. For single-layer (or layer group) requests, the set of alternate styles is presented as an option list in the layer preview map's layer control, with the currently requested style indicated.

                Note that in order to ensure that the default layer style is properly available to the preview map's option list, make sure that the style is moved to the Available Styles list in the Publishing tab of the Layer Configuration page. If the style is set to Default but not explicitly made Available, the style will not be available to MapML. Similarly but a with a slight variation in requirement, for Layer Groups, the 'default' layer group style must be copied and given a name matching default-style- plus the layer group name.

                "},{"location":"extensions/mapml/#license-info","title":"License Info","text":"

                Together these two attributes allow the administrator to define the contents of the <link rel=license> element in the MapML header. Here is an example of the resulting XML:

                https://creativecommons.org/licenses/by/4.0/\" rel=\"license\" title=\"Attribution 4.0 International (CC BY 4.0)\"/>

                License Title

                The License Title will be included as the value of title attribute of the <link rel=license> element in the MapML header.

                License Link

                The License Link will be included as the value of href attribute of the <link rel=license> element in the MapML header, and should be a valid URL referencing the license document.

                "},{"location":"extensions/mapml/#tile-settings","title":"Tile Settings","text":"

                Using tiles to access the layer can increase the performance of your web map. This is especially true if there is a tile cache mechanism in use between GeoServer and the browser client.

                Use Tiles

                If the \"Use Tiles\" checkbox is checked, by default the output MapML will define a tile-based reference to the WMS server. Otherwise, an image-based reference will be used. If one or more of the MapML-defined GridSets is referenced by the layer or layer group in its \"Tile Caching\" profile, GeoServer will generate tile references instead of generating WMS GetMap URLs in the MapML document body.

                "},{"location":"extensions/mapml/#tile-caching","title":"Tile Caching","text":"

                In the Tile Caching tab panel of the Edit Layer or Edit Layer Group page, at the bottom of the page you will see the table of GridSets that are assigned to the layer or layer group. The values \"WGS84\" and \"OSMTILE\" are equivalent to the EPSG:4326 and EPSG:900913 built in GeoWebCache GridSets. However, for the MapML module to recognize these GridSets, you must select and use the MapML names. For new layers or layer groups, or newly created grid subsets for a layer or layer group, the MapML values are selected by default. For existing layers that you wish to enable the use of cached tile references by the MapML service, you will have to select and add those values you wish to support from the dropdown of available GridSets. The set of recognized values for MapML is \"WGS84\" (equivalent to EPSG:4326), \"OSMTILE\" (equivalent to EPSG:900913), \"CBMTILE\" (Canada Base Map) and \"APSTILE\" (Alaska Polar Stereographic).

                "},{"location":"extensions/mapml/#sharding-config","title":"Sharding Config","text":"

                The Sharding Config options are intended to allow for parallel access to tiles via different server names. The actual server names must be configured in the DNS to refer to either the same server or different servers with the same GeSserver layer configuration. In the example above, the mapML client would alternate between the servers a.geoserver.org, b.geoserver.org, and c.geoserver.org to access the map images. The values in the example above would result in the following MapML:

                <input name=\"s\" type=\"hidden\" shard=\"true\" list=\"servers\" min=\"0.0\" max=\"0.0\"/>\n<datalist id=\"servers\">\n    <option value=\"a\"/>\n    <option value=\"b\"/>\n    <option value=\"c\"/>\n</datalist>\n<link tref=\"http://{s}.geoserver.org:8080/geoserver/test/wms?version=1.3.0&amp;service=WMS&amp;request=GetMap&amp;crs=EPSG:3857&amp;layers=cntry00&amp;styles=&amp;bbox={xmin},{ymin},{xmax},{ymax}&amp;format=image/png&amp;transparent=false&amp;width={w}&amp;height={h}\" rel=\"image\"/>\n
                Enable Sharding

                If Enable Sharding is checked, and values are provided for the Shard List and Shard Server Pattern fields, then a hidden shard list input will be included in the MapML.

                Shard List

                If Enable Sharding is checked, the Shard List should be populated with a comma-separated list of shard names which will be used to populate the shard data list element.

                Shard Server Pattern

                The Shard Server Pattern should be a valid DNS name including the special placeholder string {s} which will be replace with the Shard Names from the Shard List in requests to the server. This pattern should not include any slashes, the protocol string (http://) or the port number (:80), as these are all determined automatically from the URL used to access the MapML resource.

                "},{"location":"extensions/mapml/#dimension-config","title":"Dimension Config","text":"Dimension

                The selected dimension (if any) is advertised in the mapml as an input with the appropriate value options or ranges, as configured in the Dimension tab of the Layer Configuration page. Only dimensions enabled in the Dimension tab are available as options.

                "},{"location":"extensions/mapml/#attribute-to-mapping","title":"Attribute to mapping

                List of attributes The list allows you to read the names of the layer attributes, it doesn't really do more than that.

                Feature Caption Template String

                To cause an attribute to be serialized in MapML vector content as the element value, you must enter its name as a \\${placeholder} in the text box immediately below the attributes list. You can also add (a small amount of) plain text that will be copied verbatim into the content. is used as the accessible name of features by screen reader software, which will often read out this value without the user having to expand a popup; in other words, it will be used as a visual and audible tooltip when the feature is focused.","text":""},{"location":"extensions/mapml/#mapml-resources","title":"MapML Resources","text":"

                MapML resources will be available for any published WMS layers by making a GetMap request with the WMS output format to format=text/mapml. See Web Map Service (WMS) for further WMS details, GetMap for GetMap details, and WMS output formats for output format reference information.

                SRS/CRS

                Note that the WMS SRS or CRS must be one of the projections supported by MapML:

                • MapML:WGS84 (or EPSG:4326)
                • MapML:OSMTILE (or EPSG:3857)
                • MapML:CBMTILE (or EPSG:3978)
                • MapML:APSTILE (or EPSG:5936)

                The equivalent EPSG codes are provided for reference, but the MapML names are recommended, as they imply not only a coordinate refefence system, but also a tile grid and a set of zoom levels (Tiled CRS), that the MapML client will use when operating in tiled mode. When using tiles, it's also recommended to set up tile caching for the same-named gridsets.

                If the native SRS of a layer is not a match for the MapML ones, remember to configure the projection policy to \"reproject native to declare\". You might have to save and reload the layer configuration in order to re-compute the native bounds correctly.

                If the SRS or CRS is not one of the above, the GetMap request will fail with an InvalidParameterValue exception. The main \"MapML\" link in the preview page generates a HTML client able to consume MapML resources. The link is generated so that it always work, if the CRS configured for the layer is not supported, it will automatically fall back on MapML:WGS84.

                MapML Output Format

                The output image format for the MapML resource should be specified using the format_options parameter with a key called mapml-wms-format. If provided, the provided mime type must be a valid WMS format specifier. If not provided, it defaults to image/png.

                Example:

                http://localhost:8080/geoserver/tiger/wms?service=WMS&version=1.1.0&request=GetMap&layers=tiger:giant_polygon&bbox=-180.0,-90.0,180.0,90.0&width=768&height=384&srs=EPSG:4326&styles=&format=text/mapml&format_options=mapml-wms-format:image/jpeg\n
                "},{"location":"extensions/mapml/#mapml-visualization","title":"MapML Visualization","text":"

                With the MapML Extension module installed, the GeoServer Layer Preview page is modified to add a WMS GetMap link to the MapML resources for each layer or layer group. The MapML link in the Layer Preview table is generated by the MapML extension to an HTML Web map page that is created on the fly which refers to the GeoServer resource:

                You can add layers to the map as you like, by dragging the URL bar value generated by the the Layer Preview WMS formats dropdown menu selection of \"MapML\" as shown below, and dropping it onto another layer's MapML preview:

                If all goes well, you should see the layers stacked on the map and in the layer control.

                MapML visualization is supported by the Web-Map-Custom-Element project. The MapML viewer is built into the GeoServer layer and layer group preview facility. You can find out more about the Web-Map-Custom-Element at the project website <https://maps4html.org/web-map-doc/>. Here is a simple, self-contained example of an HTML page that uses the and elements:

                <!DOCTYPE html>\n<html lang=\"en\">\n  <head>\n    <meta charset=\"utf-8\" >\n    <title>MapML Test Map</title>\n    <meta name=\"viewport\" content=\"width=device-width, initial-scale=1\">\n    <script type=\"module\" src=\"http://localhost:8080/geoserver/mapml/viewer/widget/mapml-viewer.js\"></script>\n    <style>\n      html, body { height: 100%; }\n      * { margin: 0; padding: 0; }\n      mapml-viewer:defined { max-width: 100%; width: 100%; height: 100%; }\n      mapml-viewer:not(:defined) > * { display: none; } layer- { display: none; }\n    </style>\n  </head>\n  <body>\n    <mapml-viewer projection=\"osmtile\" zoom=\"2\" lat=\"61.209125\" lon=\"-90.850837\" controls>\n      <layer- label=\"US States\" src=\"http://localhost:8080/geoserver/mapml/topp:states/osmtile?style=population\" checked></layer->\n    </mapml-viewer>\n  </body>\n</html>\n

                In the above example, the place-holders topp:states, localhost:8080, osmtile, and population would need to be replaced with the appropriate values, and/or the style parameter could be removed entirely from the URL if not needed. You may also like to \"View Source\" on the preview page to see what the markup looks like for any layer. This code can be copied and pasted without harm, and you should try it and see what works and what the limitations are. For further information about MapML, and the Maps for HTML Community Group, please visit http://maps4html.org.

                "},{"location":"extensions/metadata/","title":"Metadata","text":"

                The Metadata module adds a fully customizable metadata tab to the layer configuration, allowing the user to have the layer configuration and layer metadata in one central place.

                • Getting Started
                • Fields configuration
                • Advanced Configuration
                • User Guide

                Bulk Operations can be done via the Metadata Rest Service.

                The layer metadata can be exposed by the Catalog Services for the Web (CSW) service, from there periodically harvested by GeoNetwork . Have a look at the INSPIRE metadata configuration using metadata and CSW tutorial for an example of matching metadata and CSW configurations that can be harvested by GeoNetwork.

                "},{"location":"extensions/metadata/advanced/","title":"Advanced Configuration","text":""},{"location":"extensions/metadata/advanced/#import-from-geonetwork","title":"Import from Geonetwork","text":"

                The Import from Geonetwork option allows the user to import existing metadata from GeoNetwork. Two confurations are needed for the import to work:

                • geonetworks: configure a list geonetwork endpoints
                • geonetworkmapping: define the mapping between the geonetwork fields and the fields configured in the metadata module.

                The configuration can be added to the same yaml file as the UI configuration or it can be put in a separate file.

                "},{"location":"extensions/metadata/advanced/#geonetwork-endpoint-configuration","title":"Geonetwork endpoint configuration","text":"

                The example will configure 2 endpoints.

                geonetworks:\n    - name: Geonetwork DOV production\n      url: https://www.dov.vlaanderen.be/geonetwork/srv/api/records/${UUID}/formatters/xml?attachment=true\n    - name: Geonetwork test\n      url: https://geonetwork-opensource.org/test/srv/api/records/${UUID}/formatters/xml?attachment=true\n

                +----------+----------+--------------------------------------------------------------------------------------------------------------------------+ | Key | Required | Description | +==========+==========+==========================================================================================================================+ | name | > yes | > The name of the Geonetwork endpoint that will be shown in the dropdown. | +----------+----------+--------------------------------------------------------------------------------------------------------------------------+ | url | > yes | > The url of the XML export of the metadata in the Geonetwork, where ${UUID} will be replaced by the metadata's UUID. | +----------+----------+--------------------------------------------------------------------------------------------------------------------------+

                "},{"location":"extensions/metadata/advanced/#geonetwork-mapping-configuration","title":"Geonetwork mapping configuration","text":"

                Each field from Geonetwork can be mapped to a native field from GeoServer or a field from the metadata module. The configuration for simple components are added under the yaml attribute geonetworkmapping. The fields of the type COMPLEX are mapped under the attribute objectmapping.

                The example will map one field (UUID) from the geonetwork xml to UI.

                geonetworkmapping:\n    -  geoserver: metadata-identifier\n       geonetwork: //gmd:fileIdentifier/gco:CharacterString/text()\n

                A complex object is mapped in the following example:

                objectmapping:\n    - typename: responsible-party\n      mapping:\n        - geoserver: organisation\n          geonetwork: .//gmd:CI_ResponsibleParty/gmd:organisationName/gco:CharacterString/text()\n        - geoserver: contactinfo\n          geonetwork: .//gmd:CI_ResponsibleParty/gmd:contactInfo\n        - geoserver: role\n          geonetwork: .//gmd:CI_ResponsibleParty/gmd:role/gmd:CI_RoleCode/@codeListValue\n

                Metadata from geonetwork can also be mapped to native fields. Do this by setting the mappingType to NATIVE

                -  geoserver: title\n   geonetwork: //gmd:identificationInfo/gmd:MD_DataIdentification/gmd:citation/gmd:CI_Citation/gmd:title/gco:CharacterString/text()\n   mappingType: NATIVE\n-  geoserver: alias\n   geonetwork: //gmd:identificationInfo/gmd:MD_DataIdentification/gmd:citation/gmd:CI_Citation/gmd:alternateTitle/gco:CharacterString/text()\n   mappingType: NATIVE\n

                +------------------+----------+-------------------------------------------------------------------------------------------------------------------------------------------+ | Key | Required | Description | +==================+==========+===========================================================================================================================================+ | geoserver | > yes | the key for the attributes in geoserver | +------------------+----------+-------------------------------------------------------------------------------------------------------------------------------------------+ | geonetwork | > yes | The xpath expression pointing to the content from the geonetwork metadata xml file. | +------------------+----------+-------------------------------------------------------------------------------------------------------------------------------------------+ | mappingType: | > no | > | CUSTOM (default; map to fields from the metadata module configuration) | | | | > | NATIVE (map to geoserver native fields) | +------------------+----------+-------------------------------------------------------------------------------------------------------------------------------------------+

                "},{"location":"extensions/metadata/advanced/#community_metadata_advanced_configuration_custom_native","title":"Custom to Native Mapping","text":"

                Sometimes your custom metadata configuration may contain a more complex version of fields already present in geoserver native metadata, or you may want to derive geoserver native fields (such as URL's, keywords, etcetera) from information in your custom metadata. Native fields are used by GetCapabilities requests, and you want to avoid filling in the same information twice. We can automatise deriving these native fields from custom fields using a custom-to-native mapping configuration. For example in the following configuration:

                customNativeMappings:\n  - type: KEYWORDS\n    mapping:\n      value: KEY_${keywords/name}\n      vocabulary: ${keywords/vocabulary}\n  - type: IDENTIFIERS\n    mapping:\n      value: ${identifiers/id}\n      authority: ${identifiers/authority}\n  - type: METADATALINKS\n    mapping:\n      value: https://my-host/geonetwork/?uuid=${uuid}\n      type: text/html\n      metadataType: ISO191156:2003\n  - type: METADATALINKS\n    mapping:\n      value: https://my-host/geonetwork/srv/nl/csw?Service=CSW&Request=GetRecordById&Version=2.0.2&outputSchema=http://www.isotc211.org/2005/gmd&elementSetName=full&id=${uuid}\n      type: text/xml\n      metadataType: ISO191156:2003\n

                +-------------+----------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Key | Required | Description | +=============+==========+===================================================================================================================================================================================+ | type | > yes | currently supported: KEYWORDS, IDENTIFIERS, METADATALINKS | +-------------+----------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | mapping | > yes | | List of key to value pairs. Value contains a literal with or without placeholder that contains custom attribute path (the / symbol denoting subfields inside complex fields). | | | | | Possible keys for KEYWORDS: value, vocabulary | | | | | Possible keys for METADATALINKS: value, type, metadataType, about | | | | | Possible keys for IDENTIFIERS: value, authority | +-------------+----------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+

                The synchronisation of the metadata takes place each time a layer is saved. Any information that has been entered by the user in mapped native fields via the GUI will be lost.

                "},{"location":"extensions/metadata/configuration/","title":"Getting Started","text":""},{"location":"extensions/metadata/configuration/#installation","title":"Installation","text":"

                To install the GeoServer Metadata extension:

                • Visit the GeoServer download page and navigate to the download page for the version of GeoServer your are using. The metadata download is listed under extensions. The file name is called geoserver-*-metadata-plugin.zip, where * matches the version number of GeoServer you are using.
                • Extract this file and place the JARs in WEB-INF/lib.
                • Perform any configuration required by your servlet container, and then restart. On startup, Metadata module will create a configuration directory metadata in the GeoServer Data Directory. The module will scan all yaml files in the metadata directory.
                "},{"location":"extensions/metadata/configuration/#basic-configuration","title":"Basic configuration","text":"

                By default the metadata module will add an extra tab to the edit layer page. Open the layer: navigate to Layers \u2192 Choose the layer \u2192 Metadata tab.

                The initial UI. Note the Metadata fields panel is still empty

                The content of the Metadata fields is configured by placing one or multiple yaml files describing the UI components in the metadata configuration folder, see INSPIRE metadata configuration using metadata and CSW for a real life example.

                Example UI configuration:

                attributes:\n  - key: metadata-identifier\n    fieldType: UUID\n  - key: metadata-datestamp\n    label: Date\n    fieldType: DATETIME\n  - key: data-language\n    fieldType: DROPDOWN\n    values:\n          - dut\n          - eng\n          - fre\n          - ger\n  - key: topic-category\n    fieldType: SUGGESTBOX\n    occurrence: REPEAT\n    values:\n          - farming\n          - biota\n          - boundaries\n          - climatologyMeteorologyAtmosphere\n          - economy\n          - elevation \n  - key: data-date\n    fieldType: COMPLEX\n    typename: data-identification-date\n    occurrence: REPEAT   \ntypes:    \n   - typename: data-identification-date\n     attributes:\n      - key: date\n        fieldType: DATE\n      - key: date-type\n        fieldType: DROPDOWN\n        values:\n          - creation\n          - publication\n          - revision  \n

                This configuration results in the following GUI:

                There are 3 main parts in the yaml:

                • attributes: a list of GUI components that will be rendered in the tab. They can be a basic type or a complex type, a complex type is a collection of basic types.
                • types: a list that defines the fields in each complex type.
                • tabs optionally, attributes may be displayed on separate tabs.

                Fields configuration gives an overview of all supported types and advanced features.

                "},{"location":"extensions/metadata/uiconfiguration/","title":"Fields configuration","text":"

                The ui for the metadata tab is made from a list of field components. The type of the field component and how they behave can be configured in the yaml file. All fields should be configured as a list which has the parent key attributes.

                "},{"location":"extensions/metadata/uiconfiguration/#field-options","title":"Field options","text":"

                A field is defined in the yaml following key-value pairs:

                • key
                • fieldType
                • label
                • occurrence
                • condition
                • tab
                • values (specific field types)
                • derivedFrom (specific field types)
                • typename (specific field types)
                "},{"location":"extensions/metadata/uiconfiguration/#key","title":"key","text":"

                The key is the identifier for the field and should therefore be unique. Other configurations can refer the field by using this identifier. E.g the geonetwork mapping, internationalization.

                +-------+----------+-------------------+ | Key | Required | Value | +=======+==========+===================+ | > key | > yes | > a unique string | +-------+----------+-------------------+

                "},{"location":"extensions/metadata/uiconfiguration/#fieldtype","title":"fieldType","text":"

                Chooses the type of input widget for the field. A detailed description for each type can be found in the Field Types section.

                +-------------+----------+------------------+ | Key | Required | Value | +=============+==========+==================+ | > fieldType | > yes | > - COMPLEX | | | | > - TEXT | | | | > - NUMBER | | | | > - TEXT_AREA | | | | > - DATE | | | | > - DATETIME | | | | > - BOOLEAN | | | | > - UUID | | | | > - DROPDOWN | | | | > - SUGGESTBOX | | | | > - REQUIREBOX | | | | > - DERIVED | +-------------+----------+------------------+

                "},{"location":"extensions/metadata/uiconfiguration/#label","title":"label","text":"

                If present this value will be used as the label for the field. When the label is not present in the yaml configuration the key will be used as label. Note: when the key is present in the internationalization (i18n) file see Internationalization support than the value from that file will be used as the label.

                +---------+----------+--------------+ | Key | Required | Value | +=========+==========+==============+ | > label | > no | > any string | +---------+----------+--------------+

                "},{"location":"extensions/metadata/uiconfiguration/#occurrence","title":"occurrence","text":"

                The value for occurrence determines whether or not the field should displayed as a table or as a single input field. SINGLE will result in one input field.

                e.g. single value input field of fieldType TEXT.

                Choosing REPEAT will render the field in a table allowing the user to input multiple values.

                e.g. field of fieldType TEXT rendered as a table.

                The data in table can be sorted using the green arrow buttons.

                +--------------+----------+------------------------+ | Key | Required | Value | +==============+==========+========================+ | > occurrence | > no | > - SINGLE (Default) | | | | > - REPEAT | +--------------+----------+------------------------+

                "},{"location":"extensions/metadata/uiconfiguration/#condition","title":"condition","text":"

                Conditional attributes are attributes that are only visible for some layers. A typical example are attributes only present for raster or vector layers. The condition is specified in CQL which is evaluated against the layer's ResourceInfo object.

                For example:

                condition: equalTo(typeOf(\".\"), 'FeatureTypeInfo')\n
                "},{"location":"extensions/metadata/uiconfiguration/#tab","title":"tab","text":"

                Optionally, attributes may be displayed on separate tabs. All tabs must be listed under tabs in the main configuration. Then this property is used to assign each attribute to one or more tab (separated by comma), so that the custom metadata panel is divided in tabs:

                "},{"location":"extensions/metadata/uiconfiguration/#values","title":"values","text":"

                The choices in a DROPDOWN, SUGGESTBOX or REQUIREBOX can be set using the values attribute in the yaml. This is useful for small list, for larger list it can be better to list the choices in a separate .csv file.

                "},{"location":"extensions/metadata/uiconfiguration/#derivedfrom","title":"derivedFrom","text":"

                Only used in the DERIVED field. The attribute derivedFrom contains the key for the parent on which the DERIVED field depends. Follow the link for more information on the DERIVED field.

                "},{"location":"extensions/metadata/uiconfiguration/#typename","title":"typename","text":"

                The typename is a required attribute for COMPLEX fields. It contains the key pointing to the definition of the COMPLEX field. A special typename featureAttribute is reserved for the Feature Catalog Generation and should not be used.

                "},{"location":"extensions/metadata/uiconfiguration/#field-types","title":"Field Types","text":"
                • TEXT
                • TEXT_AREA
                • UUID
                • NUMBER
                • BOOLEAN
                • DATE
                • DATETIME
                • DROPDOWN
                • SUGGESTBOX
                • REQUIREBOX
                • DERIVED
                • COMPLEX
                "},{"location":"extensions/metadata/uiconfiguration/#text","title":"TEXT","text":"

                Input field that allows any text.

                attributes:\n  - key: text-field\n    fieldType: TEXT\n
                "},{"location":"extensions/metadata/uiconfiguration/#text_area","title":"TEXT_AREA","text":"

                A multiline input.

                attributes:\n  - key: text-area-field\n      fieldType: TEXT_AREA\n
                "},{"location":"extensions/metadata/uiconfiguration/#uuid","title":"UUID","text":"

                Input field for a UUID, it allows any text input or the user can generate a UUID.

                attributes:\n  - key: uuid-field\n    fieldType: UUID\n
                "},{"location":"extensions/metadata/uiconfiguration/#number","title":"NUMBER","text":"

                Only numbers are accepted as valid input.

                attributes:\n  - key: number-field\n    fieldType: NUMBER\n
                "},{"location":"extensions/metadata/uiconfiguration/#boolean","title":"BOOLEAN","text":"

                Input field with checkbox.

                attributes:\n  - key: boolean-field\n    fieldType: BOOLEAN\n
                "},{"location":"extensions/metadata/uiconfiguration/#date","title":"DATE","text":"

                Date selection without time information.

                attributes:\n  - key: date-field\n    fieldType: DATE\n
                "},{"location":"extensions/metadata/uiconfiguration/#datetime","title":"DATETIME","text":"

                Selection date with time information.

                attributes:\n  - key: datetime-field\n    fieldType: DATETIME\n
                "},{"location":"extensions/metadata/uiconfiguration/#dropdown","title":"DROPDOWN","text":"

                A field for selecting a value from a dropdown. The values can be configured with the values attribute in the yaml or they can be configured in an other .csv file which is used for dropdowns with a lot of choices.

                Configuration in the yaml file.

                attributes:\n  - key: dropdown-field\n    fieldType: DROPDOWN\n    values:\n          - first\n          - second\n          - third\n

                To configure the values in a separate file add a yaml key csvImports on the same level as attributes and add the list of CSV files under this key. The first line in each CSV file should contain the key of the dropdown field for which you want to add the choices.

                metadata-ui.yaml

                attributes:\n  - key: dropdown-field\n    fieldType: DROPDOWN\n csvImports:\n  - dropdowncontent.csv   \n

                dropdowncontent.csv

                dropdown-field\nfirst\nsecond\nthird\n
                "},{"location":"extensions/metadata/uiconfiguration/#suggestbox","title":"SUGGESTBOX","text":"

                A field for selecting a value from a suggestbox. Suggestions will be given for the values where the input matches the beginning of the possible values. The values can be put in a separate CSV file in the same way as for the DROPDOWN field.

                attributes:\n  - key: suggestbox-field\n    fieldType: SUGGESTBOX\n    values:\n          - first\n          - second\n          - third\n
                "},{"location":"extensions/metadata/uiconfiguration/#requirebox","title":"REQUIREBOX","text":"

                This type is identical to suggestbox, except that the user is not allowed to fill in a custom value but enforced to choose a suggested value. This can be handy when an field value must be an element from a list, but this list is too long for a dropdown to be practical.

                "},{"location":"extensions/metadata/uiconfiguration/#derived","title":"DERIVED","text":"

                A derived field is a hidden field whose value depends on an other field. The yaml key derivedFrom should contain the key of the field it depends on. When a value is selected in the parent field a matching value for the derived field is searched in csv file or the value with the same index is picked from the values list.

                The CSV file should have at least two columns and start with the key of the parent field in the first column followed by the values for the parent field, the other columns should contain the key(s) of the derived field(s) in the first row followed by the matching values.

                Example derived field with config in a CSV file:

                metadata-ui.yaml

                attributes:\n  - key: derived-parent-field\n    fieldType: DROPDOWN\n  - key: hidden-field\n    fieldType: DERIVED\n    derivedFrom: derived-parent-field\ncsvImports:\n  - derived-mapping.csv\n

                derivedmapping.csv

                derived-parent-field;hidden-field\nparent-value01;hidden-value01\nparent-value02;hidden-value02\nparent-value03;hidden-value03\n

                Example derived field with values lists:

                metadata-ui.yaml

                attributes:\n  - key: derived-parent-field\n    fieldType: DROPDOWN\n    values:\n        - parent-value01\n        - parent-value02\n        - parent-value03\n  - key: hidden-field\n    fieldType: DERIVED\n    derivedFrom: derived-parent-field\n    values:\n        - hidden-value01\n        - hidden-value02\n        - hidden-value03\n
                "},{"location":"extensions/metadata/uiconfiguration/#complex","title":"COMPLEX","text":"

                A complex field is composed of multiple other fields. The yaml key typename is added to the field configuration. On the root level the yaml key types indicates the beginning of all complex type definition. A type definition should contain the typename followed by the key attributes which contains the configuration for the subfields.

                attributes:\n  - key: complex-type\n    fieldType: COMPLEX\n    typename: complex-field\n\ntypes:\n   - typename: complex-field\n     attributes:\n          - key: object-text\n            fieldType: TEXT\n          - key: object-numer\n            fieldType: NUMBER\n
                "},{"location":"extensions/metadata/uiconfiguration/#feature-catalog-generation","title":"Feature Catalog Generation","text":"

                To create a feature catalog for a vector layer, a complex structure is needed to describe all the attributes. A lot of this information is already present in the GeoServer feature type or the database. Metadata supports automatically generating a new structure in the metadata from the information at hands that can be customised afterwards. To create support for this feature in your configuration, define a repeatable COMPLEX field with built-in fieldType featureAttribute .

                In the example the featureCatalog object has two attributes. A unique identifier of the type UUID and the feature attribute field.

                e.g. Empty Feature attribute field

                - typename: featureCatalog\n  attributes:\n      - label: Unique identifier\n        key: feature-catalog-identifier\n        fieldType: UUID\n      - label: Feature attribute\n        key: feature-attribute\n        fieldType: COMPLEX\n        typename: featureAttribute\n        occurrence: REPEAT\n

                The Generate action will check the database metadata for that layer and generate a feature attribute for each column in the table.

                e.g. Feature attribute with generate feature types

                Whitin each feature attribute there is another Generate action that will generate the domain.

                e.g. Generate domain dialog

                There are two options to do this:
                • Using the existing data in the database for this attribute.
                • Using data from a look-up table in the same database. In this case you must specify the table, an attribute from which to take values and an attribute from which to take definitions.

                e.g. Feature attribute with generate domain

                "},{"location":"extensions/metadata/uiconfiguration/#internationalization-support","title":"Internationalization support","text":"

                All metadata field labels that appear in the Metadata fields can be internationalized. This is performed by creating an internationalization (i18n) file named metadata.properties. Create an entry for each key in the gui configuration following this pattern: PREFIX.attribute-key

                e.g.

                metadata.properties

                metadata.generated.form.metadata-identifier=Unique identifier for the metadata\n

                metadata_nl.properties

                metadata.generated.form.metadata-identifier=Metadata identificator\n

                Drop-down labels can be translated too, in the same properties file, using the key metadata.generated.form.[attributeKey].[value]=[label]. The value that will be internally stored for this field stays the same.

                "},{"location":"extensions/metadata/uiconfiguration/#community_metadata_uiconfiguration_hidden_fields","title":"Hidden Fields","text":"

                Hidden fields are not visible in the GUI and do not need to be configured. They are updated automatically.

                • _timestamp: date and time of the last metadata update.
                "},{"location":"extensions/metadata/user/","title":"User Guide","text":"

                To add metadata to a layer follow the steps in Adding metadata to Layer . When the metadata is repeated in multiple layers it is easier to create a template and reuse the data in the template for all the layers. See Templates .

                "},{"location":"extensions/metadata/user/#adding-metadata-to-layer","title":"Adding metadata to Layer","text":""},{"location":"extensions/metadata/user/#manually-adding-metadata","title":"Manually adding metadata","text":"

                Open the layer: navigate to Layers \u2192 Choose the layer \u2192 Metadata tab.

                The metadata fields are available in the panel Metadata fields.

                "},{"location":"extensions/metadata/user/#import-from-geonetwork","title":"Import from geonetwork","text":"

                See Advanced Configuration. Choose a geonetwork from the drop downbox, add the UUID from the metadata record and click Import. All the content of the fields that are mapped in the geonetwork mapping configuration will be deleted. All templates will be unlinked. The content will be replaced with the content from geonetwork.

                "},{"location":"extensions/metadata/user/#link-with-metadata-template","title":"Link with metadata template","text":"

                A metadata template can contain the content for metadata fields used in multiple layers. By defining these fields in a template you create one source for the content making it easier to maintain.

                To link a layer with template navigate to Layers \u2192 Choose the layer \u2192 Metadata tab in the Link with Template panel choose a template from the dropdown and click Link with template

                The values from the template will added to the metadata of the layer. How this is done depents on the type of the field.

                The field is not a list

                When the field is not a list the value will be replaced with the value from the template and the field will be read only. This will only happen for fields that are not empty in the template.

                The Field is a list

                For Fields that are a list the values from the template will be added as read only fields. The duplicate values in list will be removed if there are any.

                When multiple templates are linked with a layer the priority of the template will determine which values are added. If a field is present in both templates the value of the template with the highest priority will be picked. The priority is determined by the template order

                "},{"location":"extensions/metadata/user/#copy-from-other-layer","title":"Copy from other Layer","text":"

                Choose another layer from the drop downbox click Copy. Content will be replaced with any metadata content from the other layer, except for UUID's, which will be ignored.

                "},{"location":"extensions/metadata/user/#templates","title":"Templates","text":"

                Templates can be created, edited, deleted and ordered in Metadata \u2192 Templates . All changes to the templates will also update the linked layers when the templates are saved by clicking the Save button in the overview page. Templates that are linked to a layer cannot be removed and a warning message will appear.

                "},{"location":"extensions/metadata/user/#create-template","title":"Create template","text":"

                Use the Add new action to create a new template and choose a name for the template. The name is required and must be unique.

                "},{"location":"extensions/metadata/user/#edit-template","title":"Edit template","text":"

                Click on a template name to open the template and edit the values. Click Save to go back to the overview page, this will also recalculate the values in all linked layers.

                "},{"location":"extensions/metadata/user/#delete-template","title":"Delete template","text":"

                Select the templates that needs to be removed and click delete, the selected rows will be removed from the table. Save the changes by clicking the Save button.

                "},{"location":"extensions/metadata/user/#template-order","title":"Template order","text":"

                The templates have an order. The templates at the top of the list have a higher priority than the templates at the bottom. When a field has a value in multiple templates and the layer is linked with those templates the priority will determine which value is displayed in the metadata UI. The value defined in the template with the highest priority will be displayed.

                Change the order of the templates with the arrow keys in the priority column and save the changes by clicking Save button, this will also recalculate the values in all linked layers that may be affected.

                "},{"location":"extensions/metadata/user/#bulk-operations","title":"Bulk Operations","text":"

                This page provides a number of bulk operations mostly used for maintenance and migrations.

                "},{"location":"extensions/metadata/user/#clean-fix-all","title":"Clean / fix all","text":"

                This operation will go through all layers and perform a series of different actions on each of them to clean and repair any obsolete, corrupt or inconsistent data. This operation is useful after changing the metadata attribute configuration, bug fixes or other software updates, or exceptionally, unexpected failures.

                The actions performed are:
                • remove any existing metadata that is not according to the configuration
                • check the internal data structure and fix it if necessary
                • recalculate derived metadata fields
                • recalculate Custom to Native Mapping
                • Timestamp
                "},{"location":"extensions/metadata/user/#import-metadata","title":"Import metadata","text":"

                This option allows bulk import of metadata from GeoNetwork (see Advanced Configuration) and/or linking layers to templates. The layers that should be imported or linked are specified in a CSV file. You may specify a GeoNetwork to import from.

                The CSV file should use semicolumn as separator. The first column of your CSV files should be the layer name, the second column should be the geonetwork UUID (or left empty if you do not want to import from geonetwork), and any number of templates may be specified afterwards in the following columns.

                "},{"location":"extensions/metadata/user/#transfer-native-to-custom","title":"Transfer Native To Custom","text":"

                This operation will attempt to do the exact reverse of the Custom to Native Mapping that happens usually each time you save a layer. This will work in so far as the native attributes follow the patterns configured in your custom-to-native mapping configuration, or your configuration is basic enough. This operation is useful when you are migrating layers that were previously configured without the metadata module.

                You may optionally specify a selected list of rules if you do not wish to apply all them (by number, in the order of which they appear in the configuration), and a text file with layer names if you do not wish to go through all of them.

                "},{"location":"extensions/metadata/user/#clear-metadata","title":"Clear metadata","text":"

                Removes all existing metadata from all layers. Optionally, remove all existing templates as well. This cannot be undone.

                "},{"location":"extensions/mongodb/","title":"MongoDB Data Store","text":"

                This module provides support for MongoDB data store. This extension is build on top of GeoTools MongoDB plugin.

                "},{"location":"extensions/mongodb/#installation","title":"Installation","text":"
                1. Visit the website download page, locate your release, and download: mongodb

                  The download link will be in the Extensions section under Vector Formats.

                  Warning

                  Make sure to match the version of the extension (for example 2.24.2 above) to the version of the GeoServer instance!

                2. Extract the files in this archive to the WEB-INF/lib directory of your GeoServer installation.

                3. Restart GeoServer

                "},{"location":"extensions/mongodb/#usage","title":"Usage","text":"

                If the extension was successfully installed a new type of data store named MongoDB should be available:

                MongoDB data store.

                Configuring a new MongoDB data store requires providing:

                1. The URL of a MongoDB database.
                2. The absolute path to a data directory where GeoServer will store the schema produced for the published collections.

                Configuring a MongoDB data store.

                For more details about the usage of this data store please check the GeoTools MongoDB plugin documentation.

                "},{"location":"extensions/monitoring/","title":"Monitoring","text":"

                The monitor extension tracks requests made against a GeoServer instance. With the extension request data can be persisted to a database, used to generate simple reports , and routed to a customized request audit log.

                To get the extension proceed to Installing the Monitor Extension. To learn more about how it works jump to the Monitoring Overview section.

                • Installing the Monitor Extension
                • Monitoring Overview
                • Data Reference
                • Monitor Configuration
                • Audit Logging
                • Monitor Query API
                • GeoIP
                "},{"location":"extensions/monitoring/audit/","title":"Audit Logging","text":"

                The history mode logs all requests into a database. This can put a very significant strain on the database and can lead to insertion issues as the request table begins to host millions of records.

                As an alternative to the history mode it's possible to enable the auditing logger, which will log the details of each request in a file, which is periodically rolled. Secondary applications can then process these log files and built ad-hoc summaries off line.

                "},{"location":"extensions/monitoring/audit/#configuration","title":"Configuration","text":"

                The monitor.properties file can contain the following items to enable and configure file auditing:

                audit.enabled=true\naudit.path=/path/to/the/logs/directory\naudit.roll_limit=20\n

                The audit.enable is used to turn on the logger (it is off by default). The audit.path is the directory where the log files will be created. The audit.roll_limit is the number of requests logged into a file before rolling happens. The files are also automatically rolled at the beginning of each day.

                In clustered installations with a shared data directory the audit path will need to be different for each node. In this case it's possible to specify the audit path by using a JVM system variable, add the following to the JVM startup options and it will override whatever is specified in monitor.properties:

                -DGEOSERVER_AUDIT_PATH=/path/to/the/logs/directory

                "},{"location":"extensions/monitoring/audit/#log-files","title":"Log Files","text":"

                The log directory will contain a number of log files following the geoserver_audit_yyyymmdd_nn.log pattern. The nn is increased at each roll of the file. The contents of the log directory will look like:

                geoserver_audit_20110811_2.log\ngeoserver_audit_20110811_3.log\ngeoserver_audit_20110811_4.log\ngeoserver_audit_20110811_5.log\ngeoserver_audit_20110811_6.log\ngeoserver_audit_20110811_7.log\ngeoserver_audit_20110811_8.log\n

                By default each log file contents will be a xml document looking like the following:

                <?xml version=\"1.0\" encoding=\"UTF-8\" ?>\n<Requests>\n    <Request id=\"168\">\n       <Service>WMS</Service> \n       <Version>1.1.1</Version>\n       <Operation>GetMap</Operation> \n       <SubOperation></SubOperation>\n       <Resources>GeoSolutions:elba-deparea</Resources>\n       <ResourcesProcessingTime>4</ResourcesProcessingTime>\n       <LabelsProcessingTime>0</LabelsProcessingTime>\n       <Path>/GeoSolutions/wms</Path>\n       <QueryString>LAYERS=GeoSolutions:elba-deparea&amp;STYLES=&amp;FORMAT=image/png&amp;TILED=true&amp;TILESORIGIN=9.916,42.312&amp;SERVICE=WMS&amp;VERSION=1.1.1&amp;REQUEST=GetMap&amp;EXCEPTIONS=application/vnd.ogc.se_inimage&amp;SRS=EPSG:4326&amp;BBOX=9.58375,42.64425,9.916,42.9765&amp;WIDTH=256&amp;HEIGHT=256</QueryString>\n       <HttpMethod>GET</HttpMethod>\n       <StartTime>2011-08-11T20:19:28.277Z</StartTime> \n       <EndTime>2011-08-11T20:19:28.29Z</EndTime>\n       <TotalTime>13</TotalTime> \n       <RemoteAddr>192.168.1.5</RemoteAddr>\n       <RemoteHost>192.168.1.5</RemoteHost>\n       <Host>demo1.geo-solutions.it</Host> \n       <RemoteUser>admin</RemoteUser>\n       <ResponseStatus>200</ResponseStatus>\n       <ResponseLength>1670</ResponseLength>\n       <ResponseContentType>image/png</ResponseContentType>\n       <Failed>false</Failed>\n    </Request>\n    ...\n</Requests>\n
                "},{"location":"extensions/monitoring/audit/#customizing-log-contents","title":"Customizing Log Contents","text":"

                The log contents are driven by three FreeMarker templates.

                header.ftl is used once when a new log file is created to form the first few lines of the file. The default header template is:

                <?xml version=\"1.0\" encoding=\"UTF-8\" ?>\n<Requests>\n

                content.ftl is used to write out the request details. The default template dumps all the known fields about the request:

                <#escape x as x?xml>\n<Request id=\"${id!\"\"}\">\n   <Service>${service!\"\"}</Service> \n   <Version>${owsVersion!\"\"}</Version>\n   <Operation>${operation!\"\"}</Operation> \n   <SubOperation>${subOperation!\"\"}</SubOperation>\n   <Resources>${resourcesList!\"\"}</Resources>\n   <ResourcesProcessingTime>${resourcesProcessingTimeList!\"\"}</ResourcesProcessingTime>\n   <LabelsProcessingTime>${labellingProcessingTime!\"\"}</LabelsProcessingTime>\n   <Path>${path!\"\"}</Path>\n   <QueryString>${queryString!\"\"}</QueryString>\n   <#if bodyAsString??>\n   <Body>\n   ${bodyAsString}\n   </Body>\n   <!--#if-->\n   <HttpMethod>${httpMethod!\"\"}</HttpMethod>\n   <StartTime>${startTime?datetime?iso_utc_ms}</StartTime> \n   <EndTime>${endTime?datetime?iso_utc_ms}</EndTime>\n   <TotalTime>${totalTime}</TotalTime> \n   <RemoteAddr>${remoteAddr!\"\"}</RemoteAddr>\n   <RemoteHost>${remoteHost!\"\"}</RemoteHost>\n   <Host>${host}</Host> \n   <RemoteUser>${remoteUser!\"\"}</RemoteUser>\n   <ResponseStatus>${responseStatus!\"\"}</ResponseStatus>\n   <ResponseLength>${responseLength?c}</ResponseLength>\n   <ResponseContentType>${responseContentType!\"\"}</ResponseContentType>\n   <CacheResult>${cacheResult!\"\"}</CacheResult>\n   <MissReason>${missReason!\"\"}</MissReason>\n   <#if error??>\n   <Failed>true</Failed>\n   <ErrorMessage>${errorMessage!\"\"}</ErrorMessage>\n   <#else>\n   <Failed>false</Failed>\n   <!--#if-->\n</Request>\n<!--#escape-->\n

                footer.ftl is executed just once when the log file is closed to build the last few lines of the file. The default footer template is:

                </Requests>\n

                The administrator is free to provide alternate templates, they can be placed in the same directory as monitor.properties, with the same names as above. GeoServer will pick them up automatically.

                "},{"location":"extensions/monitoring/configuration/","title":"Monitor Configuration","text":"

                Many aspects of the monitor extension are configurable. All configuration files are stored in the data directory under the monitoring directory:

                <data_directory>\n    monitoring/\n        filter.properties\n        monitor.properties\n

                The monitor.properties file is the main configuration file whose contents are described in the following sections. The filter.properties allows for filtering out those requests from being monitored.

                Database persistence with hibernate is described in more detail in the Database Persistence section.

                "},{"location":"extensions/monitoring/configuration/#monitor_storage","title":"Monitor Storage","text":"

                How request data is persisted is configurable via the storage property defined in the monitor.properties file. The following values are supported for the storage property:

                • memory - Request data is to be persisted in memory alone.

                The default value is memory.

                The \"monitor hibernate\" community module allows to also store the requests in a relational database.

                "},{"location":"extensions/monitoring/configuration/#memory-storage","title":"Memory Storage","text":"

                With memory storage only the most recent 100 requests are stored. And by definition this storage is volatile in that if the GeoServer instance is restarted, shutdown, or crashes this data is lost.

                "},{"location":"extensions/monitoring/configuration/#monitor_mode","title":"Monitor Mode","text":"

                The monitor extension supports different \"monitoring modes\" that control how request data is captured. Currently two modes are supported:

                • history (Default) - Request information updated post request only. No live information made available.
                • live - Information about a request is captured and updated in real time.

                The monitor mode is set with the mode property in the monitor.properties file. The default value is history.

                "},{"location":"extensions/monitoring/configuration/#history-mode","title":"History Mode","text":"

                History mode persists information (sending it to storage) about a request after a request has completed. This mode is appropriate in cases where a user is most interested in analyzing request data after the fact and doesn't require real time updates.

                "},{"location":"extensions/monitoring/configuration/#live-mode","title":"Live Mode","text":"

                Live mode updates request data (sending it to storage) in real time as it changes. This mode is suitable for users who care about what a service is doing now.

                "},{"location":"extensions/monitoring/configuration/#bounding-box","title":"Bounding Box","text":"

                When applicable one of the attributes the monitor extension can capture is the request bounding box. In some cases, such as WMS and WCS requests, capturing the bounding box is easy. However in other cases such as WFS it is not always possible to 100% reliably capture the bounding box. An example being a WFS request with a complex filter element.

                How the bounding box is captured is controlled by the bboxMode property in the monitor.properties file. It can have one of the following values.

                • none - No bounding box information is captured.
                • full - Bounding box information is captured and heuristics are applied for WFS requests.
                • no_wfs - Bounding box information is captured except for WFS requests.

                Part of a bounding box is a coordinate reference system (crs).Similar to the WFS case it is not always straight forward to determine what the crs is. For this reason the bboxCrs property is used to configure a default crs to be used. The default value for the property is \"EPSG:4326\" and will be used in cases where all lookup heuristics fail to determine a crs for the bounding box.

                "},{"location":"extensions/monitoring/configuration/#request-body-size","title":"Request Body Size","text":"

                The monitor extension will capture the contents of the request body when a body is specified as is common with a PUT or POST request. However since a request body can be large the extension limits the amount captured to the first 1024 bytes by default.

                A value of 0 indicates that no data from the request body should be captured. A value of -1 indicates that no limit should be placed on the capture and the entire body content should be stored.

                This limit is configurable with the maxBodySize property of the monitor.properties file.

                Note

                When using database persistence it is important to ensure that the size of the body field in the database can accommodate the maxBodySize property.

                "},{"location":"extensions/monitoring/configuration/#ignore-post-processors","title":"Ignore Post Processors","text":"

                The monitor passes request information through post processors which enrich the request information with DNS lookup, Location using IP database etc. It is possible to disable these post processors if some enrichments are not required with ignorePostProcessors property of the monitor.properties file.

                This parameter takes comma separated names of known post processors. The valid values are reverseDNS,geoIp,layerNameNormalizer

                "},{"location":"extensions/monitoring/configuration/#request_filters","title":"Request Filters","text":"

                By default not all requests are monitored. Those requests excluded include any web admin requests or any Monitor Query API requests. These exclusions are configured in the filter.properties file:

                /rest/monitor/**\n/web/**\n

                These default filters can be changed or extended to filter more types of requests. For example to filter out all WFS requests the following entry is added:

                /wfs\n
                "},{"location":"extensions/monitoring/configuration/#monitoring-threads","title":"Monitoring threads","text":"

                You can choose the number of post processor threads by configuring the postProcessorThreads property in the monitor.properties file. The default is 2.

                "},{"location":"extensions/monitoring/configuration/#dns-cache-configuration","title":"DNS cache configuration","text":"

                The reverseDNS post processor caches its result. You can modify the cache configuration by configuring the dnsCacheConfiguration property in the monitor.properties file. The default policy is expireAfterWrite=15m,maximumSize=1000 . Consult the guava cache builder documentation for all possibilities.

                "},{"location":"extensions/monitoring/configuration/#how-to-determine-the-filter-path","title":"How to determine the filter path","text":"

                The contents of filter.properties are a series of ant-style patterns that are applied to the path of the request. Consider the following request:

                http://localhost:8080/geoserver/wms?request=getcapabilities\n

                The path of the above request is /wms. In the following request:

                http://localhost:8080/geoserver/rest/workspaces/topp/datastores.xml\n

                The path is /rest/workspaces/topp/datastores.xml.

                In general, the path used in filters is comprised of the portion of the URL after /geoserver (including the preceding /) and before the query string ?:

                http://<host>:<port>/geoserver/<path>?<queryString>\n

                Note

                For more information about ant-style pattern matching, see the Apache Ant manual.

                "},{"location":"extensions/monitoring/configuration/#samples","title":"Samples","text":""},{"location":"extensions/monitoring/configuration/#monitorproperties","title":"monitor.properties","text":"
                # storage and mode\nstorage=memory\nmode=history\n\n# request body capture\nmaxBodySize=1024\n\n# bounding box capture\nbboxMode=no_wfs\nbboxCrs=EPSG:4326\n
                "},{"location":"extensions/monitoring/configuration/#filterproperties","title":"filter.properties","text":"
                # filter out monitor query api requests\n/rest/monitor/**\n\n# filter out all web requests\n/web\n/web/**\n\n# filter out requests for WCS service\n/wcs\n
                "},{"location":"extensions/monitoring/geoip/","title":"GeoIP","text":"

                The monitor extension has the capability to integrate with the MaxMind GeoIP database in order to provide geolocation information about the origin of a request. This functionality is not enabled by default.

                Note

                At this time only the freely available GeoLite City database is supported.

                "},{"location":"extensions/monitoring/geoip/#enabling-geoip-lookup","title":"Enabling GeoIP Lookup","text":"

                In order to enable the GeoIP lookup capabilities

                1. Download the GeoLite City database.
                2. Uncompress the file and copy GeoLiteCity.dat to the monitoring directory.
                3. Restart GeoServer.
                "},{"location":"extensions/monitoring/installation/","title":"Installing the Monitor Extension","text":"

                Note

                If performing an upgrade of the monitor extension please see Upgrading.

                The monitor extension is not part of the GeoServer core and must be installed as a plug-in. To install:

                1. Visit the website download page, locate your release, and download: monitor

                  The download link will be in the Extensions section under Other.

                  Warning

                  Make sure to match the version of the extension (for example 2.24.2 above) to the version of the GeoServer instance!

                2. Extract the files in this archive to the WEB-INF/lib directory of your GeoServer installation.

                3. Restart GeoServer

                "},{"location":"extensions/monitoring/installation/#verifying-the-installation","title":"Verifying the Installation","text":"

                There are two ways to verify that the monitoring extension has been properly installed.

                1. Start GeoServer and open the Web administration interface. Log in using the administration account. If successfully installed, there will be a Monitor section on the left column of the home page.

                Monitoring section in the web admin interface

                1. Start GeoServer and navigate to the current GeoServer data directory. If successfully installed, a new directory named monitoring will be created in the data directory.
                "},{"location":"extensions/monitoring/overview/","title":"Monitoring Overview","text":"

                The following diagram outlines the architecture of the monitor extension:

                Monitor extension architecture

                As a request is processed the monitor inserts itself at particular points in the request life cycle to capture various information about the request. Such information includes:

                • Timestamp of the origin of the request
                • Total time it took for the request to complete
                • Origin of the request
                • HTTP information such as the body content type, header information, etc...

                And more. See the Data Reference section for a complete list.

                In addition to capturing request data the monitor extension is also capable of persisting it. Two options are provided out of the box:

                • Persisting to a relational database, see Database Persistence for more details
                • Piping to a log file, see Audit Logging for more details

                By default the extension will do neither and simply maintain data for only the most recent requests. The data is stored in memory meaning that if the server is restarted or shutdown this information is lost.The Monitor Configuration section provides a comprehensive guide to configuring the monitor extension.

                Stored request information is made available through a simple query api that allows clients to access request data through a HTTP interface.

                "},{"location":"extensions/monitoring/query/","title":"Monitor Query API","text":"

                The monitor extension provides a simple HTTP-based API for querying request information. It allows retrieving individual request records or sets of request records, in either HTML or CSV format. Records can be filtered by time range and the result set sorted by any field. Large result sets can be paged over multiple queries.

                "},{"location":"extensions/monitoring/query/#examples","title":"Examples","text":"

                The following examples show the syntax for common Monitoring queries.

                "},{"location":"extensions/monitoring/query/#all-requests-as-html","title":"All requests as HTML","text":"

                The simplest query is to retrieve an HTML document containing information about all requests:

                GET http://localhost:8080/geoserver/rest/monitor/requests.html\n
                "},{"location":"extensions/monitoring/query/#all-requests-as-csv","title":"All requests as CSV","text":"

                Request information can be returned in CSV format, for easier post-processing:

                GET http://localhost:8080/geoserver/rest/monitor/requests.csv\n

                Request bodies containing newlines are handled with quoted text. If your CSV reader doesn't handle quoted newlines, it will not work correctly.

                "},{"location":"extensions/monitoring/query/#all-requests-as-pkzip","title":"All requests as PKZip","text":"

                A PKZip archive containing the CSV file above, with all the request bodies and errors as separate files:

                GET http://localhost:8080/geoserver/rest/monitor/requests.zip\n
                "},{"location":"extensions/monitoring/query/#all-requests-as-ms-excel","title":"All requests as MS Excel","text":"

                A Microsoft Excel spreadsheet containing the same information as the CSV file:

                GET http://localhost:8080/geoserver/rest/monitor/requests.xls\n
                "},{"location":"extensions/monitoring/query/#requests-during-a-time-period","title":"Requests during a time period","text":"

                Requests can be filtered by date and time range:

                GET http://localhost:8080/geoserver/rest/monitor/requests.html?from=2010-06-20&to=2010-07-20\nGET http://localhost:8080/geoserver/rest/monitor/requests.html?from=2010-06-20T2:00:00&to=2010-06-20T16:00:00\n
                "},{"location":"extensions/monitoring/query/#request-set-paging","title":"Request set paging","text":"

                Large result sets can be paged over multiple queries:

                GET http://localhost:8080/geoserver/rest/monitor/requests.html?count=100\nGET http://localhost:8080/geoserver/rest/monitor/requests.html?count=100&offset=100\nGET http://localhost:8080/geoserver/rest/monitor/requests.html?count=100&offset=200\nGET http://localhost:8080/geoserver/rest/monitor/requests.html?count=100&offset=300\n
                "},{"location":"extensions/monitoring/query/#single-request","title":"Single request","text":"

                An individual request can be retrieved by specifying its ID:

                GET http://localhost:8080/geoserver/rest/monitor/requests/12345.html\n
                "},{"location":"extensions/monitoring/query/#api-reference","title":"API Reference","text":"

                There are two kinds of query: one for single requests, and one for sets of requests.

                "},{"location":"extensions/monitoring/query/#single-request-query","title":"Single Request Query","text":"

                A query for a single request record has the structure:

                GET http://<host>:<port>/geoserver/rest/monitor/requests/<id>.<format>\n

                where id is the numeric identifier of a single request, and format specifies the representation of the returned result as one of:

                • html - an HTML table.
                • csv - a Comma Separated Values table.
                • zip - PKZip archive containing CSV as above, plus plain text of errors and request body.
                • xls - Microsoft Excel spreadsheet.

                Note

                An alternative to specifying the returned representation with the format extension is to use the http Accept header and specify the MIME type as one of:

                • text/html
                • application/csv
                • application/zip
                • application/vnd.ms-excel

                See the HTTP specification for more information about the Accept header.

                "},{"location":"extensions/monitoring/query/#request-set-query","title":"Request Set Query","text":"

                The structure of a query for a set of requests is:

                GET http://<host>:<port>/geoserver/rest/monitor/requests.<format>[?parameter{&parameter}]\n

                where format is as described above, and parameter is one or more of the parameters listed below.

                The request set query accepts various parameters that control what requests are returned and how they are sorted. The available parameters are:

                "},{"location":"extensions/monitoring/query/#count-parameter","title":"count Parameter","text":"

                Specifies how many records should be returned.

                Syntax Example

                count=<integer> requests.html?count=100

                "},{"location":"extensions/monitoring/query/#offset-parameter","title":"offset Parameter","text":"

                Specifies where in the result set records should be returned from.

                Syntax Example

                offset=<integer> requests.html?count=100&offset=500

                "},{"location":"extensions/monitoring/query/#live-parameter","title":"live Parameter","text":"

                Specifies that only live (currently executing) requests be returned.

                Syntax Example

                live=<yes|no|true|false> requests.html?live=yes

                This parameter relies on a Monitor Mode being used that maintains real time request information (either live or mixed).

                "},{"location":"extensions/monitoring/query/#from-parameter","title":"from Parameter","text":"

                Specifies an inclusive lower bound on the timestamp for the start of a request. The timestamp can be specified to any desired precision.

                Syntax Example

                from=<timestamp> requests.html?from=2010-07-23T16:16:44

                                           requests.html?from=2010-07-23\n
                "},{"location":"extensions/monitoring/query/#to-parameter","title":"to Parameter","text":"

                Specifies an inclusive upper bound on the timestamp for the start of a request. The timestamp can be specified to any desired precision.

                Syntax Example

                to=<timestamp> requests.html?to=2010-07-24T00:00:00

                                           requests.html?to=2010-07-24\n
                "},{"location":"extensions/monitoring/query/#order-parameter","title":"order Parameter","text":"

                Specifies which request attribute to sort by, and optionally specifies the sort direction.

                Syntax Example

                order=<attribute>[;<ASC|DESC>] requests.html?order=path

                                                 requests.html?order=startTime;DESC\n\n                                 requests.html?order=totalTime;ASC\n
                "},{"location":"extensions/monitoring/reference/","title":"Data Reference","text":"

                The following is a list of all the attributes of a request that are captured by the monitor extension.

                "},{"location":"extensions/monitoring/reference/#general","title":"General","text":"

                Attribute Description Type

                ID Numeric identifier of the request. Every request is assigned an identifier upon its creation. Numeric

                Status Status of the request. See notes below. String

                Category The type of request being made, for example an OGC service request, a REST call, etc... See notes below. String

                Start time The time of the start of the request. Timestamp

                End time The time of the completion of the request. Timestamp

                Total time The total time spent handling the request, measured in milliseconds, equal to the end time - start time. Numeric

                Error message The exception message if the request failed or resulted in an error. String

                Error The raw exception if the message failed or resulted in an error. Text blob

                "},{"location":"extensions/monitoring/reference/#status","title":"Status","text":"

                The status of a request changes over it's life cycle and may have one of the following values:

                • WAITING - The request has been received by the server, but is queued and not yet being actively handled.
                • RUNNING - The request is in the process of being handled by the server.
                • FINISHED - The request has been completed and finished normally.
                • FAILED - The request has been completed but resulted in an error.
                • CANCELLED - The request was cancelled before it could complete.
                • INTERRUPTED - The request was interrupted before it could complete.
                "},{"location":"extensions/monitoring/reference/#category","title":"Category","text":"

                Requests are grouped into categories that describe the nature or type of the request. The following are the list of all categories:

                • OWS - The request is an OGC service request.
                • REST - The request is a REST service request.
                • OTHER - All other requests.
                "},{"location":"extensions/monitoring/reference/#http","title":"HTTP","text":"

                The following attributes are all HTTP related.

                Attribute Description Type

                HTTP method The HTTP method, one of GET, POST, PUT, or DELETE String

                Remote address The IP address of the client from which the request originated. String

                Remote host The hostname corresponding to the remote address, obtained via reverse DNS lookup. String

                Host The hostname of the server handling the request, from the point of view of the client. String

                Internal host The hostname of the server handling request, from the point of view of the local network. Availability depends on host and network configuration. String

                Path The path component of the request URL, for example: \"/wms\", \"/rest/workspaces.xml\", etc... String

                Query string The query string component of the request URL. Typically only present when the HTTP method is GET. String

                Body The body content of the request. Typically only present when the HTTP method is PUT or POST. Binary blob

                Body content length The total number of bytes comprising the body of the request. Typically only present when the HTTP method is PUT or POST. Numeric

                Body content type The mime type of the body content of the request, for example: \"application/json\", \"text/xml; subtype=gml/3.2\", etc... Typically only present when the HTTP method is PUT or POST. String

                Response status The HTTP response code, for example: 200, 401, etc... Numeric

                Response length The total number of bytes comprising the response to the request. Numeric

                Response content type The mime type of the response to the request. String

                Remote user The username specified parsed of the request. Only available when request included credentials for authentication. String

                Remote user agent The value of the User-Agent HTTP header. String

                Http referrer The value of the Referer HTTP header. String

                "},{"location":"extensions/monitoring/reference/#owsogc","title":"OWS/OGC","text":"

                The following attributes are OGC service specific.

                Attribute Description Type

                Service The OGC service identifier, for example: \"WMS\", \"WFS\", etc... String

                Operation The OGC operation name, for example: \"GetMap\", \"GetFeature\", etc... String

                Sub operation The ogc sub operation (if it applies). For instance when the operation is a WFS Transaction the sub operation may be one of \"Insert\", \"Update\", etc... String

                OWS/OGC Version The OGC service version, for example with WFS the version may be \"1.0.0\", \"1.1.0\", etc... String

                Resources Names of resources (layers, processes, etc...) specified as part of the request. List of String

                Resources processing times in milliseconds. Rendering times for resources. Rendering is performed by two concurrent threads, one reading and preprocessing data and styles towards a Java2D compatible format, the other painting the results of the first on the canvas. When the first thread starts reading the next layer, the second thread is likely still painting features from the layer before it, thus, times in this list are overlapping with each other, and the sum will be greater than the actual wall rendering time. List of Numeric

                Labels Processing Time Processing time in milliseconds for the labels of all resources listed. Numeric

                Bounding box The bounding box specified as part of the request. In some cases this is not possible to obtain this reliable, an example being a complex WFS query with a nested \"BBOX\" filter. List of Numeric

                "},{"location":"extensions/monitoring/reference/#geoip","title":"GeoIP","text":"

                The following attributes are specific to GeoIP look ups and are not captured out of the box. See GeoIP for more details.

                Attribute Description Type

                Remote country Name of the country of the client from which the request originated. String

                Remote city Name of the city from which the request originated. String

                Remote lat The latitude from which the request originated. Numeric

                Remote lon The longitude from which the request originated. Numeric

                "},{"location":"extensions/monitoring/reference/#gwc","title":"GWC","text":"

                The following attributes are specific to tile cached requests.

                Attribute Description Type

                CacheResult \"HIT\" or \"MISS\" (can be empty if GWC was not involved) String

                MissReason A description of why the cache was not used. Available only on requests hitting a cached layer on direct WMS integration, applies to cases where the request was not forwarded to GWC, for example \"no parameter filter exists for FEATUREID\", \"request does not align to grid(s) \"EPSG:4326\" or \"not a tile layer\". Will be missing for any request not hitting the direct integration (e.g., direct WMTS requests, for example) String

                "},{"location":"extensions/netcdf/netcdf/","title":"NetCDF","text":""},{"location":"extensions/netcdf/netcdf/#adding-a-netcdf-data-store","title":"Adding a NetCDF data store","text":"

                To add a NetCDF data store the user must go to Stores \u2192 Add New Store \u2192 NetCDF.

                NetCDF in the list of raster data stores

                "},{"location":"extensions/netcdf/netcdf/#configuring-a-netcdf-data-store","title":"Configuring a NetCDF data store","text":"

                Configuring a NetCDF data store

                Option Description

                Workspace

                Data Source Name

                Description

                Enabled

                URL

                "},{"location":"extensions/netcdf/netcdf/#notes-on-supported-netcdfs","title":"Notes on supported NetCDFs","text":"

                The NetCDF plugin for GeoServer supports gridded NetCDF files having dimensions following the COARDS convention (custom, Time, Elevation, Lat, Lon). The NetCDF plugin supports plain NetCDF datasets (.nc files) as well .ncml files (which aggregate and/or modify one or more datasets) and Feature Collections. It supports Forecast Model Run Collection Aggregations (FMRC) either through the NCML or Feature Collection syntax. It supports an unlimited amount of custom dimensions, including runtime.

                ToolsUI is an useful java tool developed by UCAR which can be useful for a preliminary check on your dataset. Opening a sample NetCDF using that tool will show an output like this in the Viewer tab:

                NetCDF viewer in ToolsUI

                • This dataset has 4 dimensions (time, z, lat, lon, marked by the D icon in the left side of the GUI. They have been marked by a blue rectangle in the screenshot).
                • Each dimension has an associated independent coordinate variable (marked by the green rectangle).
                • Finally, the dataset has 3 geophysical variables, marked by a red rectangle, each having 4 dimensions.

                The NetCDF plugin fully supports datasets where each variable's axis is identified by an independent coordinate variable, as shown in the previous example. There is limited support for coordinate variables with two dimensions (see Two-Dimensional Coordinate Variables), as part of the result of an aggregation (such as time,runtime - in the case of a runtime aggregation). Two dimensional non-independent latitude-longitude coordinate variables aren't currently supported. A similar dataset will look like this in ToolsUI. Look at the red marked latitude and longitude coordinate variables, each one identified by a y,x 2D matrix.

                NetCDF viewer in ToolsUI for 2D coordinate variables

                "},{"location":"extensions/netcdf/netcdf/#netcdf_multidim","title":"Two-Dimensional Coordinate Variables","text":"

                Two-dimension coordinate variables are exposed in GeoServer as single dimensions. Their domain is exposed in GetCapabilities as a flat list of possible values. However, they imply an interdependence between the different dimensions, where some combinations of values exist (have data) and other combinations do not. For example:

                +-----------+----------+----------+----------+----------+ | > Runtime | | > Time | | | +===========+==========+==========+==========+==========+ | | | > 0 | > 1 | > 2 | +-----------+----------+----------+----------+----------+ | 0 | 1/1/2017 | 1/1/2017 | \u00bd/2017 | \u00bc/2017 | +-----------+----------+----------+----------+----------+ | 1 | \u00bd/2017 | \u00bd/2017 | \u2153/2017 | > XXXX | +-----------+----------+----------+----------+----------+ | 2 | \u2153/2017 | \u2153/2017 | > XXXX | > XXXX | +-----------+----------+----------+----------+----------+

                The time dimension would thus be exposed in GeoServer as {1/1/2017, \u00bd/2017, \u2153/2017, \u00bc/2017}. However, the combinations (runtime=1/1/2017, time=\u2153/2017), (runtime=\u00bd/2017, time=1/1/2017), (runtime=\u00bd/2017, time=\u00bc/2017) , (runtime=\u2153/2017, time=1/1/2017), (runtime=\u2153/2017, time=\u00bd/2017) and (runtime=\u2153/2017, time=\u00bc/2017) do not exist.

                Some additional functionality was introduced to maximally exploit two-dimensional coordinate variables:

                • With requests that do not specify certain dimension values, we want to select default values that makes sense with regards to the dimensions values that were specified in the request. More specifically we want the maximum or minimum of the domain that matches the specified request's other dimension values; rather than the maximum or minimum of the entire domain.
                • The user may want to query which combination of dimension values do exist and which don't. This can be done through an Auxiliary Vector Store that publishes the entire index.

                A number of system properties allow us to configure this behavior:

                • org.geotools.coverage.io.netcdf.param.max

                  A comma separated list of dimensions that must be maximised when their value is absent in the request. In the layer configuration, the default value of these dimensions must be set to 'Built-in'.

                • org.geotools.coverage.io.netcdf.param.min

                  A comma separated list of dimensions that must be minimised when their value is absent in the request. In the layer configuration, the default value of these dimensions must be set to 'Built-in'.

                • org.geotools.coverage.io.netcdf.auxiliary.store

                  Set to TRUE to display the 'NetCDF Auxiliary Store' option in Geoserver. A NetCDF Auxiliary Store must be published after publishing the actual NetCDF store.

                The NetCDF Auxiliary Store returns a WFS record like this for each possible combination of dimension values that do not include the two prime spatial dimensions:

                <topp:my-aux-store gml:id=\"1\">\n <topp:the_geom>\n  <gml:Polygon srsName=\"http://www.opengis.net/gml/srs/epsg.xml#4326\" srsDimension=\"2\">\n   <gml:exterior><gml:LinearRing>\n   <gml:posList>259.96003054 -0.04 259.96003054 70.04 310.03999998 70.04 310.03999998 -0.04 259.96003054   -0.04</gml:posList>\n   </gml:LinearRing></gml:exterior>\n  </gml:Polygon>\n </topp:the_geom>\n <topp:imageindex>160</topp:imageindex>\n <topp:depth>0.0</topp:depth>\n <topp:time>2017-01-01T00:00:00Z</topp:time>\n <topp:runtime>2017-01-02T00:00:00Z</topp:runtime>\n</topp:my-aux-store>\n
                "},{"location":"extensions/netcdf/netcdf/#supporting-custom-netcdf-coordinate-reference-systems","title":"Supporting Custom NetCDF Coordinate Reference Systems","text":""},{"location":"extensions/netcdf/netcdf/#grid-mapping-attributes","title":"Grid Mapping attributes","text":"

                Starting with GeoServer 2.8.x, NetCDF related modules (both NetCDF/GRIB store, imageMosaic store based on NetCDF/GRIB dataset and NetCDF output format) allow to support custom Coordinate Reference Systems and Projections. As reported in the NetCDF CF documentation, Grid mappings section a NetCDF CF file may expose gridmapping attributes to describe the underlying projection. A grid_mapping attribute in the variable refers to the name of a variable containing the grid mapping definition.

                The GeoTools NetCDF machinery will parse the attributes (if any) contained in the underlying NetCDF dataset to setup an OGC CoordinateReferenceSystem object. Once created, a CRS lookup will be made to identify a custom EPSG (if any) defined by the user to match that Projection. In case the NetCDF gridMapping is basically the same of the one exposed as EPSG entry but the matching doesn't happen, you may consider tuning the comparison tolerance: See Coordinate Reference System Configuration, Increase Comparison Tolerance section.

                Grid Mapping and related custom EPSG definition

                User defined NetCDF Coordinate Reference Systems with their custom EPSG need to be provided in user_projections\\netcdf.projections.properties file inside your data directory (you have to create that file if missing).

                A sample entry in that property file could look like this:

                971835=PROJCS[\"albers_conical_equal_area\", GEOGCS[\"unknown\", DATUM[\"unknown\", SPHEROID[\"unknown\", 6378137.0, 298.2572221010042]], PRIMEM[\"Greenwich\", 0.0], UNIT[\"degree\", 0.017453292519943295], AXIS[\"Geodetic longitude\", EAST], AXIS[\"Geodetic latitude\", NORTH]], PROJECTION[\"Albers_Conic_Equal_Area\"], PARAMETER[\"central_meridian\", -126.0], PARAMETER[\"latitude_of_origin\", 45.0], PARAMETER[\"standard_parallel_1\", 50.0], PARAMETER[\"false_easting\", 1000000.0], PARAMETER[\"false_northing\", 0.0], PARAMETER[\"standard_parallel_2\", 58.5], UNIT[\"m\", 1.0], AXIS[\"Easting\", EAST], AXIS[\"Northing\", NORTH], AUTHORITY[\"EPSG\",\"971835\"]]

                Note

                Note the \"unknown\" names for GEOGCS, DATUM and SPHEROID elements. This is how the underlying NetCDF machinery will name custom elements.

                Note

                Note the number that precedes the WKT. This will determine the EPSG code. So in this example, the EPSG code is 971835.

                Note

                When dealing with records indexing based on PostGIS, make sure the custom code isn't greater than 998999. (It took us a while to understand why we had some issues with custom codes using PostGIS as granules index. Some more details, here)

                Note

                If a parameter like \"central_meridian\" or \"longitude_of_origin\" or other longitude related value is outside the range [-180,180], make sure you adjust this value to belong to the standard range. As an instance a Central Meridian of 265 should be set as -95.

                You may specify further custom NetCDF EPSG references by adding more lines to that file.

                1. Insert the code WKT for the projection at the end of the file (on a single line or with backslash characters):

                  971835=PROJCS[\"albers_conical_equal_area\", \\\n  GEOGCS[\"unknown\", \\\n    DATUM[\"unknown\", \\\n      SPHEROID[\"unknown\", 6378137.0, 298.2572221010042]],  \\\n    PRIMEM[\"Greenwich\", 0.0], \\\n    UNIT[\"degree\", 0.017453292519943295], \\\n    AXIS[\"Geodetic longitude\", EAST], \\\n    AXIS[\"Geodetic latitude\", NORTH]], \\\n  PROJECTION[\"Albers_Conic_Equal_Area\"], \\\n  PARAMETER[\"central_meridian\", -126.0], \\\n  PARAMETER[\"latitude_of_origin\", 45.0], \\\n  PARAMETER[\"standard_parallel_1\", 50.0], \\\n  PARAMETER[\"false_easting\", 1000000.0], \\\n  PARAMETER[\"false_northing\", 0.0], \\\n  PARAMETER[\"standard_parallel_2\", 58.5], \\\n  UNIT[\"m\", 1.0], \\\n  AXIS[\"Easting\", EAST], \\\n  AXIS[\"Northing\", NORTH], \\\n  AUTHORITY[\"EPSG\",\"971835\"]]\n
                2. Save the file.

                3. Restart GeoServer.

                4. Verify that the CRS has been properly parsed by navigating to the SRS List page in the Web administration interface.

                5. If the projection wasn't listed, examine the logs for any errors.

                "},{"location":"extensions/netcdf/netcdf/#projected-coordinates-with-axis-in-km","title":"Projected Coordinates with axis in km","text":"

                For GeoServer < 2.16.x, Projected Coordinates with axis units in km are automatically converted to meters and associated ProjectedCRS has Unit in meters too. Therefore, polygons stored in the geometry table have coordinates in meters.

                Starting with GeoServer 2.16.x, automatic conversion km-to-m is disabled by default in order to support km coordinates, directly. Therefore, make sure to define a proper custom CRS with km unit if you want to support it. (That is also needed if you want to publish the index as a vector layer).

                For example:

                971815=PROJCS[\"albers_conical_equal_area\", \\\n  GEOGCS[\"unknown\", \\\n    DATUM[\"unknown\", \\\n      SPHEROID[\"unknown\", 6378137.0, 298.2572221010042]],  \\\n    PRIMEM[\"Greenwich\", 0.0], \\\n    UNIT[\"degree\", 0.017453292519943295], \\\n    AXIS[\"Geodetic longitude\", EAST], \\\n    AXIS[\"Geodetic latitude\", NORTH]], \\\n  PROJECTION[\"Albers_Conic_Equal_Area\"], \\\n  PARAMETER[\"central_meridian\", -126.0], \\\n  PARAMETER[\"latitude_of_origin\", 45.0], \\\n  PARAMETER[\"standard_parallel_1\", 50.0], \\\n  PARAMETER[\"false_easting\", 1000000.0], \\\n  PARAMETER[\"false_northing\", 0.0], \\\n  PARAMETER[\"standard_parallel_2\", 58.5], \\\n  UNIT[\"km\", 1000.0], \\\n  AXIS[\"Easting\", EAST], \\\n  AXIS[\"Northing\", NORTH], \\\n  AUTHORITY[\"EPSG\",\"971815\"]]\n

                Note:

                UNIT[\"km\", 1000.0], \\\n

                Set -Dorg.geotools.coverage.io.netcdf.convertAxis.km to true to activate the automatic conversion or false to deactivate it.

                Note

                that is a global JVM setting: Any dataset with coordinates in km being configured before swapping the conversion behavior will need to be reconfigured to set the new Geometries and CRS.

                "},{"location":"extensions/netcdf/netcdf/#specify-an-external-file-through-system-properties","title":"Specify an external file through system properties","text":"

                You may also specify the NetCDF projections definition file by setting a Java system property which links to the specified file. As an instance: -Dnetcdf.projections.file=/full/path/of/the/customfile.properties

                "},{"location":"extensions/netcdf/netcdf/#wkt-attributes","title":"WKT Attributes","text":"

                Some NetCDFs may include a text attribute containing the WKT definition of a Coordinate Reference System. When present, it will be parsed by GeoServer to setup a CRS and a lookup will be performed to see if any EPSG is matching it.

                • spatial_ref

                  GDAL spatial_ref attribute

                • esri_pe_string

                  An attribute being defined by NetCDF CERP Metadata Convention

                "},{"location":"extensions/netcdf/netcdf/#netcdf-files-in-read-only-directories","title":"NetCDF files in read-only directories","text":"

                GeoServer creates hidden index files when accessing NetCDF files. Because these index files are created in the same directory as each NetCDF file, GeoServer will fail to publish NetCDF files if it lacks write access the containing directory.

                To permit access to NetCDF files in read-only directories, specify an alternate writeable directory for NetCDF index files by setting the NETCDF_DATA_DIR Java system property:

                -DNETCDF_DATA_DIR=/path/to/writeable/index/file/directory\n
                "},{"location":"extensions/netcdf/netcdf/#supporting-custom-netcdf-units","title":"Supporting Custom NetCDF Units","text":"

                The NetCDF format expresses units using a syntax that is not always understood by our unit parser, and often, uses unit names using unrecognized symbols or that simply unknown to it. The system already comes with some smarts, but in case a unit is not recognized, it's possible to act on the configuration and extend it.

                There are two property files that can be setup in order to modify unit magement, one is an alias file, the other is a replacement file:

                • An \"alias\" is a different symbol/name for a base unit (e.g., instead of using \"g\" the NetCDF files might be using \"grammes\")
                • A (text) \"replacement\" is used when the unit is a derived one, needing a full expression, or the syntax of the unit is simply unrecognized

                The alias file is called netcdf-unit-aliases.properties, if not provided these contents are assumed:

                # Aliases for unit names that can in turn be used to build more complex units\nMeter=m\nmeter=m\nMetre=m\nmicrogram=\u00b5g\nmicrogrammes=\u00b5g\nnanograms=ng\ndegree=deg\npercentage=%\ncelsius=\u00b0C\n````\n

                The replacement file is called netcdf-unit-replacements.properties, if not provided the following contents are assumed:

                microgrammes\\ per\\ cubic\\ meter=\u00b5g*m^-3\nDU=\u00b5mol*m^-2*446.2\nm2=m^2\nm3=m^3\ns2=s^2\n

                Both files express the NetCDF unit as the key, and the standard symbol or replacement text as the value.

                It is possible to place the files in three different locations:

                • If the NETCDF_UNIT_ALIASES and/or NETCDF_UNIT_REPLACEMENTS system variables are defined, the respective files will be looked up at the specified location (must be full paths, including the file name)
                • If the above are missing and external NetCDF data dir is defined via NETCDF_DATA_DIR then the files will be looked up in there
                • If the above are missing the root of the GeoServer data directory will be searched
                • If none of the above provide a file, then the built-in configuration will be used
                "},{"location":"extensions/netcdf/netcdf/#caching","title":"Caching","text":"

                When opening a NetCDF file, metadata and structures need to be setup, such as the Coordinate Reference System and related Coordinate Systems, the optional datastore configuration, the coverages structure (schemas and dimensions). Depending on the complexity of the file itself, those can be time consuming tasks. Operations that are continuously and repeatedly accessing the same files will be impacted by that. Therefore, starting with GeoServer 2.20.x, a caching mechanism has been setup.

                Some entities that can be considered static are internally cached once parsed: they include the NetCDF datastore configuration setup on top of the datastore properties file, the indexer built on top of the auxiliary xml file, as well as the unit of measure of the variables.

                Note

                Make sure to do a GeoServer reload if one of these config files get modified or updated, to clean the cache and allow the new settings to be used.

                "},{"location":"extensions/netcdf/netcdf/#file-caching","title":"File Caching","text":"

                An additional level of caching can be manually enabled, so that NetCDF Files can be cached and re-used. The object being cached is not the whole file, but a NetcdfDataset object, which is built on top of parsed metadata, including coordinate system info. Whenever a NetCDF dataset is being accessed, a cached instance is provided and released back to the cache-pool once done. So if there are 10 concurrent requests accessing the same NetCDF file, up to 10 different NetCDF dataset cached instances will be used.

                These Java system variables can be set to enable and configure the file caching:

                • org.geotools.coverage.io.netcdf.cachefile : boolean. set it to true to enable the dataset caching. (default: false, no files caching)
                • org.geotools.coverage.io.netcdf.cache.min : integer value representing the minimum number of datasets to be kept in cache (default: 200).
                • org.geotools.coverage.io.netcdf.cache.max : integer value representing the maximum number of datasets to be kept in cache before a cleanup get triggered (default: 300).
                • org.geotools.coverage.io.netcdf.cache.cleanup.period : integer value representing the time period (in seconds) before the next cache cleanup occurs (0 for no periodic cleanup, default is 12 minutes)

                Note

                When enabling the file caching and setting up an ImageMosaic of NetCDFs, consider disabling the Deferred Loading from the coverage configuration so that the underlying readers get access to the NetCDF dataset and release them as soon as the read is done.

                "},{"location":"extensions/netcdf/netcdf/#mosaic-of-netcdf-files","title":"Mosaic of NetCDF files","text":""},{"location":"extensions/netcdf/netcdf/#setting-up-a-basic-mosaic","title":"Setting up a basic mosaic","text":"

                A mosaic of NetCDF files is a bit different than usual, because each NetCDF file can contain multiple coverages. As a result, the mosaic setup requires extra configuration files, an indexer.xml acting as the mosaic index, and a _auxiliary.xml, describing the NetCDF file contents.

                Setting up these files can be a cumbersome process, so a utility has been written, which automatically fills their contents based on a sample NetCDF file (under the assumeption that all NetCDF files in the mosaic share the same variables and dimensions).

                Given a sample NetCDF file, you can get into the mosaic directory and run the CreateIndexer tool (for the NetCDF projection files, see above). On Windows:

                java -cp <path-to-geoserver>\\WEB-INF\\lib\\*.jar org.geotools.coverage.io.netcdf.tools.CreateIndexer <path-to-sample-nc-file> [-p <path-to-netcdf-projections>] [<path-to-output-directory>]\n

                On Linux:

                java -cp '<path-to-geoserver>/WEB-INF/lib/*' org.geotools.coverage.io.netcdf.tools.CreateIndexer <path-to-sample-nc-file> [-p <path-to-netcdf-projections>] [<path-to-output-directory>]\n

                Warning

                On older GeoServer version the command might fail complaining it cannot find org.jaxen.NamespaceContext. If that\\'s the case, download Jaxen 1.1.6, add it into the GeoServer WEB-INF/lib directory, and try again.

                This will generate the files and it\\'s going to be good enough if each NetCDF contains the same coverages. The indexer.xml file might look as follows:

                <?xml version=\"1.0\" encoding=\"UTF-8\"?><Indexer>\n  <domains>\n    <domain name=\"time\">\n      <attributes><attribute>time</attribute></attributes>\n    </domain>\n  </domains>\n  <coverages>\n    <coverage>\n      <name>dbz</name>\n      <schema name=\"dbz\">\n        <attributes>\n           the_geom:Polygon,imageindex:Integer,location:String,time:java.util.Date\n        </attributes>\n      </schema>\n      <domains>\n        <domain ref=\"time\" />\n      </domains>\n    </coverage>\n  </coverages>\n  <parameters>\n    <parameter name=\"AuxiliaryFile\" value=\"/path/to/the/mosaic/_auxiliary.xml\" />\n    <parameter name=\"AbsolutePath\" value=\"true\" />\n  </parameters>\n</Indexer>\n

                While the _auxiliary.xml file might look like:

                <?xml version=\"1.0\" encoding=\"UTF-8\"?><Indexer>\n    <coverages>\n        <coverage>\n            <schema name=\"dbz\">\n                <attributes>\n                   the_geom:Polygon,imageindex:Integer,time:java.util.Date\n                </attributes>\n            </schema>\n            <origName>dbz</origName>\n            <name>dbz</name>\n        </coverage>\n    </coverages>\n</Indexer>\n

                If instead there are different NetCDF files containing different coverages in the same mosaic, you\\'ll have to:

                • Run the above command using a different sample NetCDF file for each coverage, generating the output in different folders.
                • Manually merge them into a unified indexer.xml and _auxiliary.xml that will be placed in the mosaic directory.

                NetCDF files contain usually time dimensions, as a result, it\\'s not possible to rely on Shapefile based indexes, but use a relational database instead. So, add a datastore.properties file into the mosaic directory, pointing to a database of choice. Here is an example file, suitable to connect to a PostGIS enabled database, with a schema dedicated to contain the mosaic indexes (make sure it already exists in the database, GeoServer won\\'t create it):

                SPI=org.geotools.data.postgis.PostgisNGDataStoreFactory\nhost=localhost\nport=5432\ndatabase=netcdf\nschema=mosaic_indexes\nuser=user\npasswd=pwd\nLoose\\ bbox=true\nEstimated\\ extends=false\nvalidate\\ connections=true\nConnection\\ timeout=10\npreparedStatements=true\nmax\\ connections=20\n

                With this in place, it\\'s possible to create stores and layers in GeoServer:

                • Create a new Image Mosaic store, pointing to the mosaic directory.
                • After a bit of processing, the list of available coverages should appear, ready for layer creation.
                • Create each layer, and remember to configure time, elevation and custom dimensions in the \\\"dimensions\\\" tab.

                In case of error during the set up, the following suggestions apply:

                • Remove all extra files the mosaic might have created in the mosaic directory.
                • Remove the eventual new tables created in the database.
                • Enable the GeoTools developer logging profile in the global settings.
                • Run the mosaic creation again, inspect the logs to find out the reason (often it\\'s due to database permissions, or to NetCDF files that are not conforming to the CF conventions).
                • Repeat from the top until the mosaic creation succeeds.
                "},{"location":"extensions/netcdf/netcdf/#storing-netcdf-internal-indexes-in-a-centralized-index","title":"Storing NetCDF internal indexes in a centralized index","text":"

                By default the NetCDF reader creates a hidden directory, either as a sidecar or in the NetCDF data dir, containing a low level index file to speed up slices lookups, as well as a H2 database containing information about slice indexes and dimensions associated to them. This H2 store is opened and closed every time the associated NetCDF is read, causing less than optimal performance in map rendering.

                As an alternative, it\\'s possible to store all slice metadata from H2 to a centralized database, and have GeoServer manage the store connecting to it, thus keeping it always open. Some work is needed in order to make that happen thought.

                As a first step, create a store connection property file named netcdf_datastore.properties. Here is an example file, suitable to connect to a PostGIS enabled database, which makes the pair with the previously introduced datastore.properties :

                SPI=org.geotools.data.postgis.PostgisNGDataStoreFactory\nhost=localhost\nport=5432\ndatabase=netcdf\nschema=netcdf_indexes\nuser=user\npasswd=pwd\nLoose\\ bbox=true\nEstimated\\ extends=false\nvalidate\\ connections=true\nConnection\\ timeout=10\npreparedStatements=true\nmax\\ connections=20\n

                Notice how the NetCDF indexes are going to be stored in a different database schema, to prevent eventual table name conflicts (again, make sure the schema already exists in the database).

                GeoServer needs to be informed of this new configuration file, by editing the indexer.xml file and adding this new line in the parameters section:

                <parameter name=\"AuxiliaryDatastoreFile\" value=\"netcdf_datastore.properties\" /> \n

                The _auxiliary.xml file also needs to be modified, open it and change the attributes element(s), adding a location:String attribute right after the imageIndex:Integer attribute (position is important, mosaic construction will fail if the attribute is misplaced):

                <attributes>the_geom:Polygon,imageindex:Integer,location:String,time:java.util.Date</attributes>\n

                At this point the mosaic construction can be repeated from the GUI, just like a normal NetCDF image mosaic.

                "},{"location":"extensions/netcdf/netcdf/#migrating-mosaics-with-h2-netcdf-index-files-to-a-centralized-index","title":"Migrating mosaics with H2 NetCDF index files to a centralized index","text":"

                While the above setup allows to centralized index for NetCDF file contents. In case one already has a (very) large image mosaic of NetCDF files, having to re-harvest the NetCDF files can be time consuming and, in general, not practical.

                A utility has been created to perform the migration of existing mosaics to a centralized database index, the H2Migrate tool.

                On Windows:

                java -cp <path-to-geoserver>/WEB-INF/lib/*.jar org.geotools.coverage.io.netcdf.tools.H2Migrate -m <path-to-mosaic-directory> -is <indexPropertyFile> -v\n

                On Linux:

                java -cp '<path-to-geoserver>/WEB-INF/lib/*' org.geotools.coverage.io.netcdf.tools.H2Migrate -m <path-to-mosaic-directory> -is <indexPropertyFile> -v\n

                The tool supports other options as well, they can be discovered by running the tool without any parameter.

                Warning

                On older GeoServer version the command might fail complaining it cannot find org.apache.commons.cli.ParseException. If that\\'s the case, download commons-cli 1.1.4, add it into the GeoServer WEB-INF/lib directory, and try again.

                H2Migrate will connect to the target store using the information in indexPropertyFile, locate the granules to be migrated inspecting the mosaic contents, create a netcdf_index.properties file with StoreName=storeNameForIndex and update the mosaic to use it (basically, update the indexer.xml and all coverage property files to have a AuxiliaryDatastoreFile property pointing to netcdf_indexer.properties).

                It will also generate two files, migrated.txt and h2.txt:

                • migrated.txt contains the list of files successfully migrated, for audit purposes
                • h2.txt the list of H2 database files that can now be removed. The tool won\\'t do it automatically to ensure that the migration, but with this one one could automate removal, e.g., on Linux a simple cat h2.txt | xargs rm would do the trick (the <name>.log.db files change name often, it\\'s likely that they will have to be hunted down and removed with other means, e.g. if on Linux, using the \\\"find\\\").

                If the mosaic to be migrated is backed by a OpenSearch index, then the tool won\\'t be able to open the mosaic (it would require running inside GeoServer), so the connection parameters will have to be provided in a second property file, along with the list of tables containing the granules paths in the \\\"location\\\" attribute, e.g.:

                java -cp \\<path-to-geoserver>/WEB-INF/lib/*.jar org.geotools.coverage.io.netcdf.tools.H2Migrate -m \\<path-to-mosaic-directory> -ms \\<mosaicStorePropertyFile> -mit granule -is \\<indexPropertyFile> -isn \\<storeNameForIndex> -v

                After a successful migration, one final manual step is required. As before, the _auxiliary.xml file also needs to be modified. Open it and change the attributes element(s), adding a location:String attribute right after the imageIndex:Integer attribute (position is important, mosaic construction will fail if the attribute is mispaced):

                <attributes>the_geom:Polygon,imageindex:Integer,location:String,time:java.util.Date</attributes>\n

                Also, find every XML file holding a indexer like configuration, and add the parameter AuxiliaryDatastoreFile parameter:

                <parameter name=\"AuxiliaryDatastoreFile\" value=\"<path/to/mosaic/directory/>netcdf_datastore.properties\" /> \n

                Finally, do the same with the property files for each coverage, adding:

                AuxiliaryDatastoreFile=<path/to/mosaic/directory/>netcdf_datastore.properties\n

                The path to netcdf_datastore.properties can also be relative, but only if the image mosaic is configured to use relative paths.

                If GeoServer was running during the migration, the mosaic store just migrated needs to be reset so that it reads again its configuration: go to the mosaic store, open its configuration, and without changing any parameter, save it again: the layers backed by the mosaic are now ready to use.

                "},{"location":"extensions/netcdf-out/","title":"NetCDF Output Format","text":"

                This plugin adds the ability to encode WCS 2.0.1 multidimensional output as a NetCDF file using the Unidata NetCDF Java library.

                "},{"location":"extensions/netcdf-out/#getting-a-netcdf-output-file","title":"Getting a NetCDF output file","text":"

                Request NetCDF output by specifying format=application/x-netcdf in a GetCoverage request:

                http://localhost:8080/geoserver/wcs?service=WCS&version=2.0.1&request=GetCoverage&coverageid=it.geosolutions__V&format=application/x-netcdf...\n
                "},{"location":"extensions/netcdf-out/#current-limitations","title":"Current limitations","text":"
                • Input coverages/slices should share the same bounding box (lon/lat coordinates are the same for the whole ND cube).
                • NetCDF output will be produced only when input coverages come from a StructuredGridCoverage2D reader (this allows to query the GranuleSource to get the list of granules in order to setup dimensions slices for each sub-coverage).
                "},{"location":"extensions/netcdf-out/#netcdf-4","title":"NetCDF-4","text":"

                NetCDF-4 output is supported but requires native libraries (see Installing required NetCDF-4 Native libraries). NetCDF-4 adds support for compression. Use format=application/x-netcdf4 to request NetCDF-4 output.

                "},{"location":"extensions/netcdf-out/#settings","title":"Settings","text":"

                NetCDF output settings can be configured for each raster layer. The similar section in the Global Settings page configures the default settings used for newly created raster layers.

                • Variable Name (optional)
                  • Sets the NetCDF variable name.
                  • Does not change the layer name, which can be configured in the Data tab.
                • Variable Unit of Measure (optional)
                  • Sets the NetCDF uom attribute.
                • Data Packing
                  • Lossy compression by storing data in reduced precision.
                  • One of NONE, BYTE, SHORT, or INT.
                • NetCDF-4 Compression Level
                  • Lossless compression.
                  • Level is an integer from 0 (no compression, fastest) to 9 (most compression, slowest).
                • NetCDF-4 Chunk Shuffling
                  • Lossless byte reordering to improve compression.
                • Copy Variable Attributes from NetCDF/GRIB Source
                  • Most attributes are copied from the source NetCDF/GRIB variable.
                  • Some attributes such as coordinates and missing_value are skipped as these may no longer be valid.
                  • For an ImageMosaic, one granule is chosen as the source.
                • Copy Global Attributes from NetCDF/GRIB Source
                  • Attributes are copied from the source NetCDF/GRIB global attributes.
                  • For an ImageMosaic, one granule is chosen as the source.
                • Variable Attributes
                  • Values are encoded as integers or doubles if possible, otherwise strings.
                  • Values set here overwrite attributes set elsewhere, such as those copied from a source NetCDF/GRIB variable.
                • Global Attributes
                  • Values are encoded as integers or doubles if possible, otherwise strings.
                • Scalar Variables Copied from NetCDF/GRIB Source
                  • Source specifies the name of the source variable in a NetCDF file or the toolsUI view of a GRIB file; only scalar source variables are supported.
                  • Output specifies the name of the variable in the output NetCDF file.
                  • If only one of Source or Output is given, the other is taken as the same.
                  • Dimension is either blank to simply copy the source scalar from one granule, or the name of one output NetCDF dimension to cause values to be copied from multiple granules (such as those from an ImageMosaic over a non-spatial dimension) into a one-dimensional variable. The example above copies a single value from multiple reftime scalars into forecast_reference_time dimensioned by time in an ImageMosaic over time.
                  • For an ImageMosaic, one granule is chosen as the source for variable attributes.
                "},{"location":"extensions/netcdf-out/#cf-standard-names-support","title":"CF Standard names support","text":"

                Note that the output name can also be chosen from the list of CF Standard names. Check CF standard names page for more info on it.

                Once you click on the dropdown, you may choose from the set of available standard names.

                NetCDF CF Standard names list

                Note that once you specify the standard name, the unit will be automatically configured, using the canonical unit associated with that standard name.

                NetCDF CF Standard names and canonical unit

                The list of standard names is populated by taking the entries from a standard name table xml. At time of writing, a valid example is available Here

                You have three ways to provide it to GeoServer.

                1. Add a -DNETCDF_STANDARD_TABLE=/path/to/the/table/tablename.xml property to the startup script.
                2. Put that xml file within the NETCDF_DATA_DIR which is the folder where all NetCDF auxiliary files are located. (More info)
                3. Put that xml file within the GEOSERVER_DATA_DIR.

                Note

                Note that for the 2nd and 3rd case, file name must be cf-standard-name-table.xml.

                "},{"location":"extensions/netcdf-out/nc4/","title":"Nc4","text":"orphan"},{"location":"extensions/netcdf-out/nc4/#nc4","title":"Installing required NetCDF-4 Native libraries","text":"

                In order to write NetCDF-4 files, you must have the NetCDF-4 C library (version 4.3.1 or above) available on your system, along with all supporting libraries (HDF5, zlib, etc). The following sections provide quick reference installation instructions. For more detailed info, please take a look at the NetCDF-4 C Library Loading page.

                "},{"location":"extensions/netcdf-out/nc4/#windows-install","title":"Windows install","text":"
                1. Download the latest NetCDF4 installer from the NetCDF-C Windows Libraries page.
                2. Install the executable
                3. Make sure to add the bin folder of the package you have extracted, to the PATH environment variable.
                "},{"location":"extensions/netcdf-out/nc4/#linux-install","title":"Linux install","text":"
                1. Download the latest required dependencies (SZIP, ZLIB, HDF5) from the NetCDF-4 libraries section.

                  As an instance:

                  bash wget ftp://ftp.unidata.ucar.edu/pub/netcdf/netcdf-4/hdf5-1.8.13.tar.gz wget ftp://ftp.unidata.ucar.edu/pub/netcdf/netcdf-4/zlib-1.2.8.tar.gz

                2. Download the latest NetCDF-C source code from here.

                  As an instance:

                  bash wget https://github.com/Unidata/netcdf-c/archive/v4.3.3.1.tar.gz

                3. Build and install the required dependencies (The following instructions assume that you will install all NetCDF4 C libs on /work/libs/nc4libs, as an instance).

                  1. ZLIB

                    ``` bash ./configure --prefix=/work/libs/nc4libs

                    make check install\n```\n
                  2. HDF5

                    ``` bash ./configure --with-zlib=/work/libs/nc4libs --prefix=/work/libs/nc4libs --enable-threadsafe --with-pthread=/DIR/TO/PTHREAD

                    make check install\n```\n
                4. Build the NetCDF C Library.

                  CPPFLAGS=-I/work/libs/nc4libs/include LDFLAGS=-L/work/libs/nc4libs/lib ./configure --prefix=/work/libs/nc4libs\n\nmake check install\n
                5. Make sure to add the lib folder of the package you have extracted, to the PATH environment variable.

                "},{"location":"extensions/netcdf-out/nc4/#geoserver-startup-checks","title":"GeoServer startup checks","text":"

                If everything has been properly configured, you may notice a similar log message during GeoServer startup:

                | NetCDF-4 C library loaded (jna_path='null', libname='netcdf'). | Netcdf nc_inq_libvers='4.3.1 of Jan 16 2014 15:04:00 $' isProtected=true |

                In case the native libraries haven't been properly configured you will see a message like this, instead:

                NetCDF-4 C library not present (jna_path='null', libname='netcdf').

                "},{"location":"extensions/netcdf-out/nc4/#requesting-a-netcdf4-classic-output-file-as-wcs20-output","title":"Requesting a NetCDF4-Classic output file as WCS2.0 output","text":"

                Specifying application/x-netcdf4 as Format, will return a NetCDF4-Classic output files, provided that the underlying libraries are available.

                "},{"location":"extensions/params-extractor/","title":"Parameters Extractor","text":"

                This module allow us to entering specific request parameters as URL path fragments instead of using the query string.

                • Installing the Parameter Extractor extension
                • Using the Parameters Extractor module
                "},{"location":"extensions/params-extractor/install/","title":"Installing the Parameter Extractor extension","text":"

                The Parameter Extractor extension is listed among the other extension downloads on the GeoServer download page.

                The installation process is similar to other GeoServer extensions:

                1. Visit the website download page, locate your release, and download: params-extractor

                  Verify that the version number in the filename (for example 2.24.2 above) corresponds to the version of GeoServer you are running.

                2. Extract the contents of the archive into the WEB-INF/lib directory in GeoServer. Make sure you do not create any sub-directories during the extraction process.

                3. Restart GeoServer.

                If installation was successful, you will see a new Params-Extractor entry in the left menu, under \"Settings\".

                The Parameter Extractor menu entry

                "},{"location":"extensions/params-extractor/usage/","title":"Using the Parameters Extractor module","text":"

                This module allow us to entering specific request parameters as URL path fragments instead of using the query string. For example, we want to be able to apply a cql_filter using a URL in the following form:

                /geoserver/<workspace>/<layer>/<filter>/ows?service=WMS&version=1.3.0&request=GetMap\n

                As a simple example of usage, if the is something like:

                K_140M\n

                the URL would become:

                /geoserver/<workspace>/<layer>/K_140M/ows?service=WMS&version=1.3.0&request=GetMap\n

                and this module will translate the URL to this new one:

                /geoserver/<workspace>/<layer>/ows?service=WMS&version=1.3.0&request=GetMap&cql_filter=seq='K140M'\n

                This module is configured by a set of rules that will be applied to the incoming URLs. Note that a get capabilities result will include the original URL maintaining the extra filter.

                This module also gives the possibility to echo existing URL parameters to the result of a get capabilities result. As an example, by default the following get capabilities request (note the existing cql_filter parameter):

                /geoserver/ows?service=wms&version=1.3.0&request=GetCapabilities&cql_filter=CFCC=%27D68%27\n

                will return a get capabilities document were the URLs will be of the type:

                /geoserver/ows?SERVICE=WMS&\n

                if this module is configured to echo an existing cql_filter parameter the result would be:

                /geoserver/ows?SERVICE=WMS&CQL_FILTER=CFCC%3D%27D68%27&\n

                This module is configured using three types of rules: echo parameter rules, basic rules and advanced rules. All of them can be managed in this module UI which is integrated in GeoServer UI.

                "},{"location":"extensions/params-extractor/usage/#echo-parameter-rules","title":"Echo Parameter Rules","text":"

                Echo parameter rules are very simple, they allow us to define that a certain existing URL parameter should be echoed to a get capabilities result. This type of rules only required one mandatory parameter which is the name of the existing URL parameter that should be echoed to a get capabilities result.

                Example of an echo parameter rule:

                Example of a echo parameter rule defined in the UI

                This rule will echo the cql_filter of this URL:

                /geoserver/ows?service=wms&version=1.3.0&request=GetCapabilities&cql_filter=CFCC=%27D68%27\n

                to the get capabilities result:

                /geoserver/ows?SERVICE=WMS&CQL_FILTER=CFCC%3D%27D68%27&\n
                "},{"location":"extensions/params-extractor/usage/#basic-rules","title":"Basic Rules","text":"

                Basic rules allow us to handle simple uses cases where we only want to extract a parameter from the URL.

                A basic rule is defined by three mandatory attributes:

                Attribute Description

                Position The position of the URL base path element to be selected

                Parameter The name of the parameter produced by this rule

                Transform Expression that defines the value of the parameter, use {PARAMETER} as a placeholder for the selected path element

                For commodity is also possible when defining this type of rules to configure that an existing parameter in the URL should be echoed to a get capabilities result.

                Example of a basic rule:

                Example of a basic rule defined in the UI

                This rule will transform the URL:

                /geoserver/tiger/wms/H11?SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap\n

                in:

                /geoserver/tiger/wms?SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&CQL_FILTER=CFCC%3D%27H11%27\n
                "},{"location":"extensions/params-extractor/usage/#advanced-rules","title":"Advanced Rules","text":"

                Advanced rules allow us to handle more complex uses cases where more flexibility is required.

                An advanced rule is defined by three mandatory attributes and four optional ones:

                Attribute Description Mandatory

                Match Regex match expression with groups, for example \\^(?:/[\\^/]){3}(/([\\^/]+)).\\$ selects the URL base path third element Yes

                Activation If defined this rule will only be applied to URLs that match this regex expression No

                Parameter The name of the parameter produced by this rule Yes

                Transform Expression that defines the value of the parameter, use \\$1 ... \\$n as placeholders for groups defined in the match expression Yes

                Remove The match expression group to be removed from URL, by default 1 No

                Combine Defines how to combine parameter existing value (\\$1 existing value, \\$2 new value), by default the value is overridden No

                Repeat If defined, Combine is applied not only once, but for every layer included in the LAYERS parameter, this allows filling parameters that require a value for each layer (e.g. STYLES or CQL_FILTER) No

                For commodity is also possible when defining this type of rules to configure that an existing parameter in the URL should be echoed to a get capabilities result.

                Example of an advanced rule:

                Example of an advanced rule defined in the UI

                This rule will transform the URL:

                /geoserver/tiger/wms/H11?SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&CQL_FILTER=CFCC%3D%27D68%27\n

                in:

                /geoserver/tiger/wms?SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&CQL_FILTER=CFCC%3D%27D68%27+or+CFCC%3D%27H11%27\n

                No that this rule will also echo an existing cql_filter parameter to the get capabilities result.

                Example of an advanced rule with repeat:

                Example of an advanced rule with repeat defined in the UI

                This rule will transform the URL:

                /geoserver/wms/H11?SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&LAYERS=tiger,other\n

                in:

                /geoserver/wms?SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&LAYERS=tiger,otherCQL_FILTER=CFCC%3D%27D68%27%3BCFCC%3D%27H11%27\n
                "},{"location":"extensions/params-extractor/usage/#rules-management","title":"Rules Management","text":"

                Rules can be managed and tested in the rules management UI. Besides the basic operations like add, remove and update is also possible to activate or deactivate rules. A deactivated rule will be ignored by this module.

                Follow a print screen of the rules management UI with all the rules previously defined:

                Rules management UI

                Note that the first rule (the advanced one) is not active.

                "},{"location":"extensions/params-extractor/usage/#rest-api","title":"REST API","text":"

                The rules and echo parameters can also be managed by means of a REST API found at geoserver/rest/params-extractor. Documentation for it is available in Swagger format

                "},{"location":"extensions/params-extractor/usage/#intercepting-the-security-filters-chain","title":"Intercepting the security filters chain","text":"

                By default, the params-extractor module does not interact with the security authentication filters. This is because the params-extractor filter is called later in the GeoServer filters chain.

                If you want params-extractor to work before the security filter chain, you have to configure it as a standard servlet filter in the GeoServer WEB-INF/web.xml file.

                This can be done adding the following to your current web.xml (immediately after the Set Character Encoding filter) and restarting GeoServer:

                <!DOCTYPE beans PUBLIC \"-//SPRING//DTD BEAN//EN\" \"http://www.springframework.org/dtd/spring-beans.dtd\">\n<web-app>\n    ...\n    <filter>\n     <filter-name>ExtractParams</filter-name>\n     <filter-class>org.geoserver.params.extractor.Filter</filter-class>\n    </filter>\n    ...\n    <filter-mapping>\n      <filter-name>ExtractParams</filter-name>\n      <url-pattern>/*</url-pattern>\n    </filter-mapping>\n    ...\n</web-app>\n
                "},{"location":"extensions/printing/","title":"GeoServer Printing Module","text":"

                The printing module for GeoServer allows easy hosting of the Mapfish printing service within a GeoServer instance. The Mapfish printing module provides an HTTP API for printing that is useful within JavaScript mapping applications. User interface components for interacting with the print service are available from the Mapfish and GeoExt projects.

                Reference:

                • https://mapfish.github.io/mapfish-print-v2/ (mapfish-print-lib documentation)
                "},{"location":"extensions/printing/#installation","title":"Installation","text":"
                • Visit the website download page, locate your release, and download: printing
                • Extract the contents of the ZIP archive into the /WEB-INF/lib/ in the GeoServer webapp. For example, if you have installed the GeoServer binary to /opt/geoserver/, the printing extension JAR files should be placed in /opt/geoserver/webapps/geoserver/WEB-INF/lib/.
                • After extracting the extension, restart GeoServer in order for the changes to take effect. All further configuration can be done with GeoServer running.
                "},{"location":"extensions/printing/#verifying-installation","title":"Verifying Installation","text":"

                On the first startup after installation, GeoServer should create a print module configuration file in {GEOSERVER_DATA_DIR}/printing/config.yaml. Checking for this file's existence is a quick way to verify the module is installed properly. It is safe to edit this file; in fact there is currently no way to modify the print module settings other than by opening this configuration file in a text editor.

                If the module is installed and configured properly, then you will also be able to retrieve a list of configured printing parameters from http://localhost:8080/geoserver/pdf/info.json . This service must be working properly for JavaScript clients to use the printing service.

                Finally, you can test printing in this sample page <files/print-example.html>. You can load it directly to attempt to produce a map from a GeoServer running at http://localhost:8080/geoserver/. If you are running at a different host and port, you can download the file and modify it with your HTML editor of choice to use the proper URL.

                Warning

                This sample script points at the development version of GeoExt. You can modify it for production use, but if you are going to do so you should also host your own, minified build of GeoExt and OpenLayers. The libraries used in the sample are subject to change without notice, so pages using them may change behavior without warning.

                "},{"location":"extensions/printing/#mapfish-documentation","title":"MapFish documentation","text":"
                • Configuration
                • Protocol
                • FAQ
                "},{"location":"extensions/printing/configuration/","title":"Configuration","text":"

                The server side uses a YAML configuration file that defines the page layouts and allowed values. This file is usually called config.yaml.

                Note

                Warranty disclaimer and license

                The authors provide these documents \"AS-IS\", without warranty of any kind either expressed or implied.

                Document under Creative Common License Attribution-Share Alike 2.5 Generic.

                Authors: MapFish developers.

                "},{"location":"extensions/printing/configuration/#general-structure","title":"General structure","text":"

                Here is the general structure:

                dpis:\n  - 254\n  - 190\n  {...}\n\n?maxSvgWidth: 2048 # set the maximum dimensions to 2048 points, this is useful when using MapServer and a maximum dimension is there\n?maxSvgHeight: 2048\n?integerSvg: false # the library in MapServer <= 5.6 does not support floating point values in the SVG coordinate space, set this to true if using a WMS that does not support floating point values in SVG coordinates\n\n?ignoreCapabilities: false # assume client is correct and do not load capabilities.  This is not recommended to be used unless you it fails when false (false is default)\n?disableLayersMerging: false # WMS layers with mergable parameters will be merged by default. Set this to true to disable attempts to merge.\n?maxPrintTimeBeforeWarningInSeconds: 30 # if print jobs take longer than this then a warning in the logs will be written along with the spec.\n?printTimeoutMinutes: 5 # The maximum time to allow a print job to take before cancelling the print job.  The default is 5 (minutes)\n?formats:\n  - pdf\n  - png\n  {...}\n\nscales:\n  - 25000\n  - 50000\n  {...}\n\nhosts:\n  - {HOST_WHITELIST_DEFINITION}\n  {...}\n\n?localHostForward: # For request on map.example.com we build an http request on localhost with the header Host=map.example.com, this is to don't pass throw the proxy.\n?  from:\n?    - map.example.com\n?  https2http: True # For above hosts on request on https we build a request on http\n\n?headers: ['Cookie', 'Referer'] # The header that will be copyed to the tiles http requests\n\n?keys:\n?  - !key\n?    host: !dnsMatch\n?      host: maps.google.com\n?      port: 80\n?    domain: !dnsMatch\n?      host: localhost\n?    key: 1234456\n?    id: gmd-xyz\n\n\n?fonts:\n? - {PATH}\n\n?globalParallelFetches: 5\n?perHostParallelFetches: 5\n?tilecacheMerging: false\n?connectionTimeout: 30000           MF_V1.2\n?socketTimeout: 180000              MF_V1.2\n?outputFilename: Mapfish-print      MF_V1.2\n?disableScaleLocking: false\n?brokenUrlPlaceholder: default      MF_V2.0\n?proxyBaseUrl: http://mapfishprint.org  MF_V2.0\n?tmsDefaultOriginX: 0.0f   MF_V2.0\n?tmsDefaultOriginY: 0.0f   MF_V2.0\n\n?security:\n?  - !basicAuth\n?      matcher: !dnsMatch\n?        host: www.camptocamp.com\n?        post: 443\n?      username: xyz\n?      password: zyx\n?      preemptive: true\n?  - !basicAuth\n?    username: abc\n?    password: bca\n\nlayouts:\n   {LAYOUT_NAME}:\n?   : Mapfish-print.pdf  MF_V1.2\n?   metaData:\n?     {METADATA_DEFINITION}\n?   titlePage:\n?     {PAGE_DEFINITION}\n    mainPage:\n?     rotation: false\n      {PAGE_DEFINITION}\n?   lastPage:\n?     {PAGE_DEFINITION}\n  {...}\n

                Optional parts are shown with a question mark in the left margin. The question marks must not be put in the configuration file. Their default values is shown.

                Note: Sets of values like DPI can be entered in one of two forms:

                dpi: [1,2,3,...]\n

                or

                dpis:\n  - 254\n  - 190\n
                "},{"location":"extensions/printing/configuration/#dpi-and-pdf-dimensions","title":"DPI and PDF Dimensions","text":"

                A chosen DPI value from the above configuration is used in WMS GetMap requests as an added format_options (GeoServer) or map_resolution (MapServer) parameter. This is used for symbol/label-rescaling suitable for high resolution printouts, see Geoserver format_options specification (Geoserver 2.1) and MapServer defresolution keyword (MapServer 5.6) for more information.

                In general, PDF dimensions and positions are specified in points. 72 points == 1 inch == 25.4 mm.

                "},{"location":"extensions/printing/configuration/#getting-maps","title":"Getting Maps","text":"

                The list of {HOST_WHITELIST_DEFINITION} defines the allowed URLs for getting maps. Its format will be defined in the next sub-section.

                The formats element lists the values formats that the server permits.

                • If omitted only 'pdf' is permitted.
                • If the single element '*' (quotes are required) is present then all formats that the server can produce can be requested.

                The formats the server can produce depends to a large degree on how the Java is configured.

                PDF is supported on all systems but for image output formats JAI and ImageIO is used which means both must be on the server for them to be available. You can get the list of supported formats by running the standalone client with the --clientConfig flag enabled (you will need to supply a yaml config file as well). If you are using the servlet then do a get info request to see the list of formats (with the '*' as the outputFormats parameter in the config file).

                \"globalParallelFetches\" and \"perHostParallelFetches\" are used to tune the parallel loading of the map tiles/images. If you want to disable the parallel loading, set \"globalParallelFetches\" to 1.

                New versions of tilecache added the support for merging multiple layers in a single WMS request. If you want to use this functionality, set the \"tilecacheMerging\" attribute to true.

                \"connectionTimeout\" and \"socketTimeout\" can be used to tune the timeouts for reading tiles from map servers.

                \"proxyBaseUrl\" the optional url of the proxy between mapfish-print and the internet. This is the url base that will be in the info.json response. On occasion the url or port of the web server containing mapfish-print is not the server that is public to the internet and the requests are proxied to the mapfish-print webserver. In this case it is important for the info.json request to return the public URL instead of the url of the webserver.

                \"tmsDefaultOriginX\" By default this is null. If non-null then TmsMapReader will use this as the origin x value if null then the origin will be derived from the maxExtent parameter.

                \"tmsDefaultOriginY\" By default this is null. If non-null then TmsMapReader will use this as the origin y value if null then the origin will be derived from the maxExtent parameter.

                "},{"location":"extensions/printing/configuration/#layouts","title":"Layouts","text":"

                You can have as many layouts as you want. Their name must be unique and will be used on the client side.

                A layout can have a \"titlePage\" that will be added at the beginning of the generated document. It cannot contain any map.

                The \"mainPage\" section is mandatory and will be used once for each page requested. The details of a {PAGE_DEFINITION} section can be found in another sub-section of this document.

                A layout \"lastPage\", will be added for the end of the document, and cannot contain any map.

                If you want to let the user rotate the map (for a given layout), you have to set the \"rotate\" field to \"true\" in the corresponding \"mainPage\" section.

                "},{"location":"extensions/printing/configuration/#output-filename","title":"Output filename","text":"

                If the 'outputFilename' parameter is defined in the main body then that name will be used by the MapPrintServlet when sending the pdf to the client. It will be the name of the file that the client downloads. If the 'outputFilename' parameter is defined in a layout then that value will override the default name. In both cases the .pdf suffic is optional; if not present the server will append .pdf to the name.

                In all cases the json request can override the filename defined in the configuration file by posting a 'outputFilename' attribute in the posted JSON. If the outputFilename has \\${date}, \\${time} or \\${dateTime} in it, it will be replaced with the current date using the related DateFormat.get*Instance().format() method. If a pattern is provided it will be passed to SimpleDataFormat for processing. A few examples follow:

                • outputFilename: \"host-\\${yyyyMMdd}.pdf\" # results in host-20111213.pdf
                • outputFilename: \"host-\\${date}\" # results in host-Dec_13_2011.pdf (actual output depends on local of server)
                • outputFilename: \"host-\\${dateTime}\" # results in host-Dec_13_2011_1:10:50_PM.pdf (actual output depends on local of server)
                • outputFilename: \"host-\\${time}.pdf\" # results in host-1:11:14_PM.pdf (actual output depends on local of server)
                • outputFilename: \"host-\\${yyMMdd-hhmmss}\"# results in host-111213-011154.pdf (actual output depends on local of server)

                \"disableScaleLocking\" allows you to bypass the choosing of scale from the available factors, and simply use the suggested value produced inside MapBlock.java.

                "},{"location":"extensions/printing/configuration/#broken-images","title":"Broken images","text":"

                \"brokenUrlPlaceholder\" the placeholder image to use in the case of a broken url. By default, when a url request fails, an error is thrown and the pdf process terminates. However if this parameter is set then instead a placeholder image is returned.

                Non-null values are:

                • \"default\" - use the system default image.
                • \"throw\" - throw an exception.
                • - obtain the image from the supplied url. If this url is broken then an exception will be thrown. This can be anytype of valid url from a file url to https url."},{"location":"extensions/printing/configuration/#security","title":"Security","text":"

                  Both Keys and Security are options for accessing protected services. Keys are currently for Google maps premium accounts and Security is for other types and is more general Currently only BasicAuth is supported but other strategies can easily be added

                  security:\n    - !basicAuth\n        matcher: !dnsMatch\n          host: www.camptocamp.com\n          post: 443\n        username: xyz\n        password: zyx\n        preemptive: true\n    - !basicAuth\n      username: abc\n      password: cba\n

                  The above example has 2 security configuration. Each option is tested (in order) to see if it can be used for the given URI and if it applies it is used to configure requests for the URI. In the above example the first configuration will be used if the URI matches the hostmatcher provided if not then the second configuration will be applied. The last configuration has no host matcher so it is applied to all URIs.

                  A basicAuth security configuration consists of 4 options

                  • matcher - a host matcher for determining which requests need the security to be applied
                  • username - username for basicauth
                  • password - password for basicauth
                  • preemptive - optional, but for cases where the credentials need to be sent without the challenge
                  "},{"location":"extensions/printing/configuration/#x-forwarded-for","title":"X Forwarded For","text":"

                  Added addForwardedFor optional flag (true / false) to enable by IP security.

                  When the option is true, every request to WMS services have an X-Forwarded-For header with the client IP / name, so that IP based security rules are correctly applied by the underlying service.

                  "},{"location":"extensions/printing/configuration/#keys","title":"Keys","text":"

                  Google maps currently requires a private key to be used (we only support users Google maps premium accounts).

                  The keys section allows a key to be mapped to hosts. The hosts are identified with host matchers that are described in the sub-section.

                  In addition a domain hostmatcher can be used to select a key based on the domain of the local server. This can be useful if the same configuration is used in a test environment and a production environment with differing domains. For example mapfish.org and mapfish.net.

                  Finally google maps (for example) requires a client id as well that is associated with the private key. There for in the case of google premium services a legal key would be:

                  keys:\n  - !key\n    key: yxcvyxvcyxvyx\n    id: gme-xxxcs\n

                  Thanks to the hosts and domain matcher it is possible to have a key for google maps and (for future proofing) a different key for a different service.

                  "},{"location":"extensions/printing/configuration/#fonts-definition","title":"Fonts definition","text":"

                  The \"fonts\" section is optional. It contains the path of the fonts you want to use. The entries can point to files (TTF, OTF, TTC, AFM, PFM) or directories. Don't point to directories containing too many files since it will slow down the start time. By default, PDF gives you access to the following fonts (Cp1252 encoding only):

                  • Courrier (-Bold, -Oblique, -BoldOblique)
                  • Helvetica (-Bold, -Oblique, -BoldOblique)
                  • Times (-Roman, -Bold, -Oblique, -BoldOblique)
                  • Symbol
                  • ZapfDingbats
                  "},{"location":"extensions/printing/configuration/#host-whitelist-definition","title":"Host whitelist definition","text":"

                  In this section, you can put as many entries as you want, even for the same type of filter. If at least one matches, the Map server can be used.

                  This section is not for defining which client can request maps. It is just here to avoid having the print module used as a proxy to access documents from computers behind firewalls.

                  There are 3 ways to whitelist a host.

                  "},{"location":"extensions/printing/configuration/#allowing-every-local-services","title":"Allowing every local services:","text":"
                  - !localMatch\n  dummy: true\n

                  The \"dummy\" parameter is ignored, but mandatory to avoid a limitation in the YAML format.

                  "},{"location":"extensions/printing/configuration/#allowing-by-dns-name","title":"Allowing by DNS name:","text":"
                  - !dnsMatch\n  host: labs.metacarta.com\n
                  "},{"location":"extensions/printing/configuration/#allowing-by-ip-address","title":"Allowing by IP address:","text":"
                  - !ipMatch\n  ip: www.camptocamp.org\n?   mask: 255.255.255.255\n

                  The \"ip\" parameter can be a DNS name that will be resolved or directly an IP address.

                  All the methods accept the following optional parameters:

                  • port: to limit to a certain TCP port
                  • pathRegexp: a regexp that must match the path part of the URL (before the '?').
                  "},{"location":"extensions/printing/configuration/#metadata-definition","title":"Metadata definition","text":"

                  Allow to add some metadata to the generated PDF. They are visible in acroread in the File->Properties menu.

                  The structure is like that:

                  metaData:\n?     title: ''\n?     author: ''\n?     subject: ''\n?     keywords: ''\n?     creator: ''\n?     supportLegacyReader: false\n

                  All fields are optional and can use global variables, as defined in the Block definition chapter. Page specific variables are not accessible.

                  "},{"location":"extensions/printing/configuration/#page-definition","title":"Page definition","text":"

                  The structure is like that:

                  pageSize: A4\n?     landscape: false\n?     marginLeft: 40\n?     marginRight: 40\n?     marginTop: 20\n?     marginBottom: 20\n?     backgroundPdf: template.pdf\n?     condition: null\n?     header:\n  height: 50\n  items:\n    - {BLOCK_DEFINITION}\n    {...}\nitems:\n  - {BLOCK_DEFINITION}\n  {...}\n?     footer:\n  height: 50\n  items:\n    - {BLOCK_DEFINITION}\n    {...}\n?     includeTitlePage: true\n?     includeLastPage: true\n?     includeExtraPage: true\n

                  With the \"condition\" we can completely hide a page, same behavior than in block.

                  If \"backgroundPdf\" is specified, the first page of the given PDF file will be added as background of every page.

                  The \"header\" and \"footer\" sections are optional. If the \"items\" that are in the main section are too big, more pages are generated. The header and footer will be drawn on those pages as well.

                  Here is a short list of supported pageSizes:

                  name width height

                  LETTER 612 792

                  LEGAL 612 1008

                  A4 595 842

                  A3 842 1191

                  The complete list can be found in http://api.itextpdf.com/itext/com/itextpdf/text/PageSize.html. If you want to use a custom page size, you can set pageSize to the width and the height separated by a space.

                  "},{"location":"extensions/printing/configuration/#skip-rendering-of-pages","title":"Skip Rendering Of Pages","text":"

                  New flag params to skip rendering of particular pages have been implemented:

                  • includeTitlePage
                  • includeLastPage
                  • includeExtraPage

                  They are all defaulted to true.

                  "},{"location":"extensions/printing/configuration/#extra-pages","title":"Extra Pages","text":"

                  Additional Pages are supported in many different places. They can be rendered due to legends overflowing on multiple pages, or by the dynamic images functionality.

                  Where additional pages can be generated, the generating block will be spread among all the created pages (for example, the legend block will put legends on different pages, if configured to do so). If you want to put additional blocks on additional page, you can specify the renderOnExtraPage flag on the desired blocks. Only first level blocks are considered.

                  In addition to that, an explicit extraPage block can be used in config.yaml to add a custom page between other pages. The renderOn property specify the exact position for rendering (beforeMainPage, beforeLastPage or afterLastPage).

                  "},{"location":"extensions/printing/configuration/#block-definition","title":"Block definition","text":"

                  The next sub-sections document the possible types of blocks.

                  In general, text values or URLs can contain values taken from the spec structure coming with the client's request. A syntax similar to shell is used: \\${variableName}. If the current page is a titlePage, only the root values are taken. If it's a mainPage, the service will first look in the current page section then in the root values. Here is how to use this functionality:

                  text: 'The value of mapTitle is: ${mapTitle}'\n

                  Some virtual variables can be used:

                  • \\${pageNum}: The current page number.
                  • \\${pageTot}: The total number of pages. Can be used only in text blocks.
                  • \\${now}: The current date and time as defined by the machine's locale.
                  • \\${now FORMAT}: The current date and time as defined by the FORMAT string. The syntax is here: http://java.sun.com/j2se/1.5.0/docs/api/java/text/SimpleDateFormat.html.
                  • \\${configDir}: The absolute path to the directory of the configuration file.
                  • \\${format PRINTF VAR}: Format the value of VAR using the provided PRINTF format (for example: %,d).

                  All the blocks can have a condition attribute that takes a spec attribute name. If the attribute name exists and is not equal to \"false\" or \"0\", the block is drawn. Otherwise, it is ignored. An exclamation mark may precede the condition to invert it, exclamation mark is part of yaml syntax, than the expression should be in quotes.

                  Example: show text block only if in the spec the attribute name \"showText\" is given, is not equal to \"false\" and not equal to \"0\":

                  - !text\n  text: 'mytext'\n  condition: showText\n
                  "},{"location":"extensions/printing/configuration/#text-block","title":"Text block","text":"
                  - !text\n?         font: Helvetica\n?         fontSize: 12\n?         fontEncoding: Cp1252\n?         fontColor: black\n?         spacingAfter: 0\n?         align: left\n?         vertAlign: middle\n?         backgroundColor: #FFFFFF\n  text: 'Blahblah'\n?         asHTML: false\n

                  Typical \"fontEncoding\" values are:

                  • Cp1250
                  • Cp1252
                  • Cp1257
                  • Identity-H (horizontal UTF-8)
                  • Identity-V (vertical UTF-8)
                  • MacRoman

                  The \"font\" must refer to a standard PDF font or a declared font.

                  "},{"location":"extensions/printing/configuration/#html-in-text-blocks","title":"HTML In Text Blocks","text":"

                  The new configuration property asHTML (to be used in config.yaml text blocks) allows to automatically render the included text as HTML (when true), instead of simple text. HTML tags are interpreted and styled.

                  "},{"location":"extensions/printing/configuration/#image-block","title":"Image block","text":"
                  - !image\n  maxWidth: 200\n  maxHeight: 100\n?         spacingAfter: 0\n?         align: left\n?         vertAlign: middle\n  url: http://trac.mapfish.org/trac/mapfish/chrome/site/img/mapfish.png\n

                  Supported formats are PNG, GIF, Jpeg, Jpeg2000, BMP, WMF (vector), SVG and TIFF.

                  The original aspect ratio will be respected. The url can contain \"\\${}\" variables.

                  "},{"location":"extensions/printing/configuration/#simple-colored-box-icons","title":"Simple colored box icons","text":"

                  This enhancement adds the feature of drawing a simple colored box, instead of an icon into a legend item.

                  To draw a colored box, include a color: #hexvalue property in the printing spec, instead of an icon: url property.

                  "},{"location":"extensions/printing/configuration/#base64","title":"Base64","text":"

                  We added support for Base64 encoded images uris to PDFUtils so that embedded images can be included for styling vector points (for example).

                  Example url:

                  url: data:image/png;base64,<encoded image>\n
                  "},{"location":"extensions/printing/configuration/#images-content","title":"Images content","text":"

                  This enhancement allow you add SVG content inside the specification of the print. You need to add a name into the image to manage:

                  - !columns\n    width: 580\n    height: 271\n    absoluteX:70\n    absoluteY:400\n    items:\n      - !image\n        name: chart1\n        maxWidth: 580\n        maxHeight: 271\n        rotation: '${rotation}'\n

                  Spec:

                  {\n...\nchart1:{\n  content: '<svg>SVG content</svg>' \n},\n...\n}\n

                  then, the content its rendered inside the print page with the layout configuration.

                  "},{"location":"extensions/printing/configuration/#columns-block","title":"Columns block","text":"
                  - !columns\n?         config: {TABLE_CONFIG}\n?         widths: [25,25,25,25]\n?         backgroundColor: #FFFFFF\n?         absoluteX: null\n?         absoluteY: null\n?         width: {PAGE_WIDTH}\n?         spacingAfter: 0\n?         nbColumns: -1\n  items:\n    - {BLOCK_DEFINITION}\n    {...}\n

                  Can be called !table as well.

                  By default, the width of the columns will be equal.

                  Each item will be in its own column.

                  If the absoluteX, absoluteY and width are given, the columns block will be floating on top of the page at the specified position.

                  The widths attribute can be used to change the width of the columns (by default, they have the same width). It must contain one integer for each column. The width of a given column is tableWidth*columnWeight/sum(columnWeight).

                  Every block type is allowed except for map if the column has an absolute position.

                  Look at <http://trac.mapfish.org/trac/mapfish/wiki/PrintModuleServer#Tableconfiguration to know how to specify the config field.

                  "},{"location":"extensions/printing/configuration/#map-block","title":"Map block","text":"

                  Allowed only within a mainPage.

                  - !map\n  width: 0\n  height: 0\n?         name: map\n?         spacingAfter: 0\n?         align: left\n?         vertAlign: middle\n?         absoluteX: null\n?         absoluteY: null\n?         overviewMap: null\n?         backgroundColor: #FFFFFF\n

                  width and height are mandatory. You can use variable substitution in this part, but if you do so, the browser won't receive the map size when it calls info.json. You'll have to override mapfish.widgets.print.Base.configReceived and set the map width and height of your layouts.

                  If the absoluteX and absoluteY are given, the map block will be floating on top of the page at the specified position.

                  The name is what will be displayed in the Acrobat's reader layer panel. The map layers will be displayed bellow it.

                  If overviewMap is specified, the map will be an overview of the extent augmented by the given factor. There are few cases to consider with map overviews:

                  1. If there is no overview overrides and no OL.Control.MapOverview, then all the layers will figure in the PDF map overview.
                  2. If there are overview overrides, the OL map overview control is ignored.
                  3. If there are no overview overrides and there is an OL.Control.MapOverview (takes the first one), then the layers defined in the control are taken into account. By default it is the current base layer.
                  "},{"location":"extensions/printing/configuration/#scalebar-block","title":"Scalebar block","text":"

                  Display a scalebar.

                  Allowed only within a mainPage.

                  - !scalebar\n  maxSize: 150\n?         type: line\n?         intervals: 3\n?         subIntervals: false\n?         units: m\n?         barSize: 5\n?         lineWidth: 1\n?         barDirection: up\n?         textDirection: up\n?         labelDistance: 3\n?         font: Helvetica\n?         fontSize: 12\n?         fontColor: black\n?         color: #000000\n?         barBgColor: null\n?         spacingAfter: 0\n?         align: left\n?         vertAlign: middle\n?         backgroundColor: #FFFFFF\n?         lockUnits: true\n?         preferredIntervals: [1,2,5,10]\n?         preferredIntervalFractions: 0.0\n

                  The scalebar, will adapt its width up to maxSize (includes the labels) in order to have a multiple of 1, 2 or 5 values at each graduation. For example:

                  • 0, 1, 2, ...
                  • 0, 2, 4, ...
                  • 0, 5, 10, ...
                  • 0, 10, 20, ...

                  The barSize is the thickness of the bar or the height of the tick marks on the line. The lineWith is for the thickness of the lines (or bar border).

                  Units can be any of:

                  • m (mm, cm, m or km)
                  • ft (in, ft, yd, mi)
                  • degrees (min, sec, \u00b0)

                  If the value is too big or too small, the module will switch to one of the unit in parenthesis (the same unit is used for every intervals). If this behaviour is not desired, the lockUnits parameter will force the declared unit (or map unit if no unit is declared) to be used for the scalebar.

                  The number of intervals can be set to anything >=2. Labels are drawn only at main intervals. If there is no space to display a label at a certain interval, this label won't be displayed. If subIntervals are enabled, their number will depend on the length of an interval.

                  The type can be:

                  • line: A simple line with graduations
                  • bar: A thick bar with a suite of color and barBgColor blocks.
                  • bar_sub: Like bar, but with little lines for labels.

                  The bar and/or text orientation can be set to \"up\", \"down\", \"left\" or \"right\".

                  The align attribute is for placing the whole scalebar withing the surrounding column or page. The vertAlign attribute is used only when placed in a column.

                  Labels are always centered on the graduation, at a distance specified by labelDistance.

                  "},{"location":"extensions/printing/configuration/#custom-intervals-in-scalebarblock","title":"Custom intervals in ScalebarBlock","text":"

                  With this improvement we added two new configuration parameters to !scalebar blocks that allow to customize the scalebar preferred bar lengths.

                  Now this set can be customized using the preferredIntervals property. This property is an array with the new (integer) allowed lengths. By default these were chosen in the 1,2,5,10 set.

                  Another property, preferredIntervalFractions, can be specified to also use fractional intervals. By default only 0.0 is used, and thus only integer lengths are allowed.

                  Example:

                  .. code-block:: yaml\n

                  preferredIntervals: [1,3,5,10] preferredIntervalFractions: [0.2,0.5]

                  "},{"location":"extensions/printing/configuration/#attributes-block","title":"Attributes block","text":"

                  Allows to display a table of the displayed feature's attributes.

                  Allowed only within a mainPage.

                  - !attributes\n  source: results\n?         tableConfig: {TABLE_CONFIG}\n  columnDefs:\n    {COLUMN_NAME}:\n?             columnWeight: 0        MF_V1.2\n      header: {BLOCK_DEFINITION}\n      cell: {BLOCK_DEFINITION}\n    {...}\n

                  Look here for how to specify the tableConfig field.

                  The columnWeigth (MF_V1.2 only) allows to define a weight for the column width. If you specify it for one column, you have to specify it for all of them. The width of a given column is tableWidth*columnWeight/sum(columnWeight).

                  The source value defines the name of the entry in the root of the client's spec. For example, it would look like that:

                  {\n  ...\n  pages: [\n    {\n      ...\n      results: {\n        data: [\n          {id:1, name: 'blah', icon: 'icon_pan'},\n          ...\n        ],\n        columns: ['id', 'name', 'icon']\n      }\n    }\n  ]\n  ...\n}\n

                  With this spec you would have to define 3 columnDefs with the names id, name and icon. Each cell definition blocks have access to all the values of the current row.

                  The spec part is filled automatically by the 2 MapFish widgets when their grids parameter is set.

                  Here is a crazy example of columnDef that will show the name of the icon and it's bitmap side-by-side inside a single column:

                  columnDefs:\n  icon:\n    header: !text\n      text: Symbol\n      backgroundColor: #A0A0A0\n    cell: !columns\n      items:\n        - !text\n          text: '${icon}'\n        - !image\n          align: center\n          maxWidth: 15\n          maxHeight: 15\n          url: 'http://www.mapfish.org/svn/mapfish/trunk/MapFish/client/mfbase/mapfish/img/${icon}.png'\n

                  A more complex example can be found in SVN: config.yaml spec.json

                  The print widgets are able to fill the spec for you based on a dictionary of Ext.grid.GridPanel. Just pass them through the grids parameter.

                  "},{"location":"extensions/printing/configuration/#group-rendering-in-attribute-blocks","title":"Group Rendering In Attribute Blocks","text":"

                  Attribute blocks now support grouping, by a specific attribute. Rows should be sorted by that attribute for grouping to work (no automatic sort is accomplished by the printing library).

                  To identify the grouping attribute, use the groupBy property.

                  Each group can be prefixed by a title, using the groupTitle property. You can specify any block in the groupTitle property, to render any kind of content as a title.

                  You can also skip table header using the includeHeader flag (true by default).

                  Finally you can force a page break before any new group, using the groupOnNewPage flag.

                  "},{"location":"extensions/printing/configuration/#legends-block","title":"Legends block","text":"

                  Display each layers along with its classes (icons and labels).

                  - !legends\n?         backgroundColor: #FFFFFF\n?         borders: false\n?         horizontalAlignment: center\n?         maxWidth: 0\n?         maxHeight: 0\n?         iconMaxWidth: 0\n?         iconMaxHeight: 8\n?         iconPadding: 8 7 6 5\n?         textMaxWidth: 8\n?         textMaxHeight: 8\n?         textPadding: 8 7 6 5\n?         defaultScale: 1.0\n?         inline: true\n?         classIndentation: 20\n?         layerSpaceBefore: 5\n?         layerSpace: 5\n?         classSpace: 2\n?         layerFont: Helvetica\n?         layerFontSize: 10\n?         classFont: Helvetica\n?         classFontSize: 8\n?         fontEncoding: Cp1252\n?         columnMargin: 3\n?         overflow: false\n?         maxColumns: 1\n?         reorderColumns: false\n?         dontBreakItems: false\n?         fitWidth: 0\n?         fitHeight: 0\n

                  borders is mainly for debugging purpouses and shows all borders in the legend tables. This can be either 'true' or 'false'.

                  horizontalAlignment can be left, right or center (default) and aligns all items left, right or in the center.

                  iconMaxWidth, iconMaxHeight, defaultScale with value of 0 indicate that the value will be ignored, i.e. the values are automatically set to the equivalent of Infinity, Infinity and 1 respectively. If the legends URL passed to MapFish (see http://mapfish.org/doc/print/protocol.html#print-pdf) are obtained from a WMS GetLegendGraphic request, the width/height are only indicative (even more when a label text is included with LEGEND_OPTIONS/forceLabels parameter) and it would be safer, in order to preserve scale coherence between legends and map, to set iconMaxWidth and iconMaxHeight to zero.

                  textMaxWidth/Height and iconMaxWidth/Height define how wide/high the text/icon cells of a legend item can be. At this point textMaxHeight is ignored.

                  textPadding and iconPadding can be used like standard CSS padding. In the above example 8 is the padding top, 7 padding right, 6 padding bottom and 5 padding left.

                  if inline is true icons and text are rendered on the same line, BUT multicolumn is still enabled.

                  if maxWidth is set the whole legend gets a maximum width, just like other blocks. Note that maxWidth does not have any impact on icons size, thus icons may overflow outside the legends block.

                  if maxHeight is set the whole legend gets a maximum height. This forces more than one column to appear if the legend is higher than the specified value. This can be used to enable the multi-column layout. 0 makes the maxHeight= max value, i.e. the equivalent of infinity.

                  if defaultScale is non null it means that the legend image will be scaled so it doesn't take the full space. This can be overriden for individual classes in the spec JSON sent to the print module by adding an attribute called 'scale' and giving it a number. In conjunction with iconMaxWidth/Height this can be used to control average and also maximum width/height. If defaultScale equals 1, one pixel is scaled to one point (1/72 inch) in generated PDF. By default, as GeoServer legends are generated with \\~90 dpi resolution (exactly 25.4/0.28), setting defaultScale value to 0.7937 (72*0.28/25.4) produces legend icons of same size as corresponding map icons. As the LEGEND_OPTIONS/dpi GeoServer parameter is not handled by MapFish, the resolution will necessary be \\~91 dpi, which may cause visual quality difference with the map.

                  For this to work, you need to set the layerTree config option on MF print widgets, more precisely the legends should be present in the print.pdf JSON request.

                  layerSpaceBefore is to specify the space before the second and consecutive layers.

                  layerSpace and classSpace is to specify the line space to add after layers and classes.

                  columnMaxWidth maximum width of a column in multi-column layout.

                  maxColumns allows to specify a maximum number of columns to be used. After this number is reached, a new row is created.

                  classIndentation amount of points to indent classes by.

                  layerSpaceBefore if a layer is after another one, this defines the amount of space to have before it. This will not be applied if the layer is the first item in its column in multi-column layout.

                  layerFont font of layer name legend items.

                  layerFontSize font size of layer name.

                  classFont font of class legend items.

                  classFontSize font size of class.

                  fontEncoding (see below)

                  "},{"location":"extensions/printing/configuration/#legend-fitting","title":"Legend fitting","text":"

                  Support for legend fitting (legend resized to fit a given rectangle) has been added, through 2 new config.yaml configuration properties (to be used in legend blocks).

                  The properties are:

                  • fitWidth: width of the rectangle for fitting (defaults to 0, meaning no fit)
                  • fitHeight: height of the rectangle for fitting (defaults to 0, meaning no fit)

                  Both properties or only one of them can be specified. When only one property is set, the other dimension is calculated to mantain the original aspect ratio for the legend.

                  "},{"location":"extensions/printing/configuration/#multipage-legends","title":"Multipage legends","text":"

                  By default a LegendsBlock must be contained in a single page. To allow it to span on several pages the overflow option can be used, setting it to true.

                  When this option is used you also need to define maxColumns, to fix the max number of columns on each page and maxHeight, to fix the maximum height of each column.

                  The LegendsBlock will be rendered on as many pages as needed to get all the items rendered with the given constraints.

                  Please note that if more than one page is needed, the second and following pages will only contain legend columns, without any of the other element of the page where the legends block is defined.

                  "},{"location":"extensions/printing/configuration/#creating-an-horizontal-layout-for-legends","title":"Creating an horizontal layout for legends","text":"

                  Using some config.yaml configuration options in an unusual way it is possible to have a layout for legends that is horizontal, instead of vertical.

                  To get this behaviour is necessary to:

                  • use the legend block maxHeight property with a very low value (e.g. 1) to force a new column for each legend item
                  • use the legend block maxColumns value to choose the number of columns for the legend (a new row will be forced after maxColumns is reached)
                  "},{"location":"extensions/printing/configuration/#reorder-legends-block-in-columns","title":"Reorder legends block in columns","text":"

                  When the option reorderColumns inside legends block it set to true and more than one column is necessary for the legends block, a new algorithm computes the best distribution of the legend items inside the columns. Currently a first fit with items sorted in height descending order is used. This is not sub-optimal, but it's fast.

                  When a legend item is rendered to another column, by default name and legend icon could finish on different columns. To fix it, please enable the dontBreakItems option.

                  "},{"location":"extensions/printing/configuration/#dont-break-legend-items","title":"Don't break legend items","text":"

                  Set the flag dontBreakItems to true on legends block if you want to render legend and names as one table to forbid the break between different columns

                  "},{"location":"extensions/printing/configuration/#table-configuration","title":"Table configuration","text":"

                  The columns block and the attributes block can take a table configuration object like that:

                  config:\n?     borderWidth: 0\n?     borderWidthLeft: 0\n?     borderWidthRight: 0\n?     borderWidthTop: 0\n?     borderWidthBottom: 0\n?     borderColor: black\n?     borderColorLeft: black\n?     borderColorRight: black\n?     borderColorTop: black\n?     borderColorBottom: black\n?     cells:\n?       - {CELL_CONFIGURATION}\n

                  A cell configuration looks like that:

                  ?     row: {...}\n?     col: {...}\n?     borderWidth: 0\n?     borderWidthLeft: 0\n?     borderWidthRight: 0\n?     borderWidthTop: 0\n?     borderWidthBottom: 0\n?     borderColor: black\n?     borderColorLeft: black\n?     borderColorRight: black\n?     borderColorTop: black\n?     borderColorBottom: black\n?     padding: 0\n?     paddingLeft: 0\n?     paddingRight: 0\n?     paddingTop: 0\n?     paddingBottom: 0\n?     backgroundColor: white\n?     align: LEFT\n?     vertAlign: TOP\n

                  The stuff configured at table level is for the table border, not every cell.

                  The cells list defines overrides for some cells. The cells an override is applied to is defined by the row and col attribute. Those attributes can have several formats:

                  • 0: apply only to row or column 0 (the first)
                  • 0-10: applies only the row or columns from 0 to 10
                  • or you can use any regular expression

                  Every matching overrides is applied in order and will override the values defined in the previous ones.

                  For example, if you want to draw an attribute block like that:

                  You define that:

                  - !attributes\n  tableConfig:\n    borderWidth: 1\n    cells:\n      # match every cell (default cell formatting)\n      - borderWidthBottom: 0.5\n        borderWidthLeft: 0.5\n        padding: 4\n        paddingTop: 0\n      # match every even cell (yellowish background)\n      - row: '\\d*[02468]'\n        backgroundColor: #FFFFCC\n      # for the header\n      - row: 0\n        borderWidthBottom: 1\n        backgroundColor: #FA0002\n        align: center\n  {...}\n
                  "},{"location":"extensions/printing/configuration/#dynamic-images-page","title":"Dynamic images page","text":"

                  New layout to let you print a different number of pages dinamically.

                  You need to put it in config.yaml:

                  dynamicImagesPage:\n      rotation: true\n      pageSize: 595 842\n      landscape: false\n      items:[...]\n

                  and when you called to the print servlet, you'll need to add this property to the spec:

                  imagesPages:[\n     {firstPageConfiguration},\n     {secondPageConfiguration}\n]\n

                  then it's render one page for each item found in the imagesPages property.

                  Also, you cant select the pages placement inside the document with the property renderOn:

                  • afterLastPage: It's rendered after the last page. It's the default option active.
                  • beforeLastPage: It's rendered just before last page (between main page and last page layouts)
                  • beforeMainPage: It's rendered before main page (between first page and main page)

                  The first use of this layout it's add a dynamic number of pages with differents images with svg content generated dynamicaly (using also the images content enhancement). This is an example of use with two dynammic images by page:

                  Example config.yaml:

                  ...\n dynamicImagesPage:\n   rotation: true\n   pageSize: 595 842\n   landscape: false\n   items:\n     - !columns\n       absoluteX: 30\n       absoluteY: 812\n       width: 535\n       height: 100\n       items:\n         - !image\n           maxWidth: 535\n           url: '${configDir}/print_header.png'\n     - !columns\n       absoluteX: 0\n       absoluteY: 750\n       width: 595\n       widths: [595]\n       items:\n         - !text\n           align: center\n           vertAlign: middle\n           fontSize: 14\n           text: '${meteorologicalPagesTitle}'\n     - !columns\n       width: 580\n       height: 271\n       absoluteX:70\n       absoluteY:697\n       items:\n         - !image\n           name: chart1\n           maxWidth: 580\n           maxHeight: 271\n           rotation: '${rotation}'\n     - !columns\n       width: 580\n       height: 271\n       absoluteX:70\n       absoluteY:400\n       items:\n         - !image\n           name: chart2\n           maxWidth: 580\n           maxHeight: 271\n           rotation: '${rotation}'\n

                  spec:

                  {\n...\nimagePages:[\n    images:{\n        chart1:{\n             content: '<svg>SVG content</svg>'\n        },\n        chart2:{\n             content: '<svg>SVG content</svg>'\n        }\n    }\n],\n...\n}\n
                  "},{"location":"extensions/printing/faq/","title":"FAQ","text":"

                  Note

                  Warranty disclaimer and license

                  The authors provide these documents \"AS-IS\", without warranty of any kind either expressed or implied.

                  Document under Creative Common License Attribution-Share Alike 2.5 Generic.

                  Authors: MapFish developers.

                  All I get in my PDF is: \"ERROR: infinite table loop\". What's wrong?

                  Something in your page is too big. For example, the width or the height of your !map block.

                  I tried to print (pylons mode) and I get a \"Java error\". What's next?

                  Look in the apache error log, you'll find more information.

                  What are the limitations of the type 2 layers?

                  It depends mostly on the map server you use. For the moment, GeoServer has not been extensively tested. With MapServer:

                  • The PDF output must be enabled when you compile and doesn't work in WMS mode, only in native MapServer mode. There are some limitations. on the styling. And you must use truetype fonts.
                  • The SVG output is limited regarding the stylings you can use. For example only plain polygon fillings are supported by MapServer. If a complex styling is used, your features may appear plain black.
                  I tried to change the layout and half the Map is printed off the page on the right. Or I have an empty page added. Is it a bug?

                  It's mostly a feature ;-) . This kind of behavior can be seen in iText, when adding a block that is too big for the page size. Try to reduce the size of your map block.

                  When I look at my generated PDF in Acrobat Reader, it looks good. But, when I print it, it misses some tiles/layers, some bitmaps are just weird or there are no page printed. What's wrong?

                  There are three possible explanations:

                  • Your printer has not enough memory: in Acrobat's print dialog, select \"Save printer memory\"
                  • Your printer firmware is buggy: upgrade it
                  • Your printer driver is buggy: upgrade it
                  The module needs to go through a proxy to access the map services.

                  It's so 90s... you should hire some fresh guys for your IT team. ;-)

                  You need to set some system properties (http.proxy*) when you start your java programs.

                  On the browser, the scale is displayed with spaces to separate thousands and it's against my religion. How do I put my sacred separator?

                  By default, the browser's configured locale is used. You can force another locale in the print widget configuration:

                  {\n  ...\n  configUrl: 'print/info.json',\n  serviceParams: { locale: 'fr_CH' },\n  ...\n}\n
                  I copied the examples and the print widgets are not working.

                  First edit the client/examples/examples.js file and make sure the URLs are correct.

                  1. If you don't want to install the server side, make sure you installed a proxy (see Configure Proxy). For example, test (must return a JSON content, not the proxy.cgi script's content) it with an URL like that (adapt the hostname, port and path): http://localhost/cgi-bin/proxy.cgi?url=http://demo.mapfish.org/mapfishsample/trunk/print/info.json
                  2. If you installed the server side, make sure it works by calling the URL specified in the mapfish.SERVER_BASE_URL variable (must be the hostname/port your page is accessed through) added with /print/info.json. For example, if you have mapfish.SERVER_BASE_URL=\"http://localhost/mapfish\": http://localhost/mapfish/print/info.json

                  If it still doesn't work, use firefox, install firebug and check in the console panel that the AJAX request made by the print widget works fine.

                  "},{"location":"extensions/printing/protocol/","title":"Protocol","text":"

                  Four commands are available and are documented in the next sections.

                  Every command uses the HTTP status code to notify errors.

                  Note

                  Warranty disclaimer and license

                  The authors provide these documents \"AS-IS\", without warranty of any kind either expressed or implied.

                  Document under Creative Common License Attribution-Share Alike 2.5 Generic.

                  Authors: MapFish developers.

                  "},{"location":"extensions/printing/protocol/#infojson","title":"info.json","text":"

                  HTTP command:

                  GET {PRINT_URL}/info.json?url={PRINT_URL}%2Finfo.json&var=printConfig\n

                  Returns a JSON structure as such:

                  var printConfig = {\n    \"scales\":[\n        {\"name\":\"25000\"},\n        {\"name\":\"50000\"},\n        {\"name\":\"100000\"}\n    ],\n    \"dpis\":[\n        {\"name\":\"190\"},\n        {\"name\":\"254\"}\n    ],\n    \"outputFormats\":[\n        {\"name\":\"pdf\"},\n        {\"name\":\"png\"}\n    ],\n    \"layouts\":[\n        {\n            \"name\":\"A4 portrait\",\n            \"map\":{\n                \"width\":440,\n                \"height\":483\n            }\n        }\n    ],\n    \"printURL\":\"http:\\/\\/localhost:5000\\/print\\/print.pdf\",\n    \"createURL\":\"http:\\/\\/localhost:5000\\/print\\/create.json\"\n}\n

                  This can be loaded through an HTML script tag like that:

                  <script type=\"text/javascript\"\n      src=\"http://localhost:5000/print/info.json?var=printConfig\"></script>\n

                  or through an AJAX request, in this case the var query parameter will be omitted.

                  The \"url\" query parameter is here to help the print servlet to know what URL is used by the browser to access the servlet. This parameter is here because the servlet can be behind a proxy, hiding the real URL.

                  "},{"location":"extensions/printing/protocol/#printpdf","title":"print.pdf","text":"

                  HTTP command:

                  GET {PRINT_URL}/print.pdf?spec={SPEC}\n   or\nPOST {PRINT_URL}/print.pdf    with {SPEC} in the request body\n

                  The \"SPEC\" parameter is a JSON structure like that:

                  {\n    layout: 'A4 portrait',\n    ...CUSTOM_PARAMS...\n    srs: 'EPSG:4326',\n    units: 'degrees',\n    geodetic: false,\n    outputFilename: 'political-boundaries',\n    outputFormat: 'pdf',\n    mergeableParams: {\n        cql_filter: {\n            defaultValue: 'INCLUDE',\n            separator: ';',\n            context: 'http://labs.metacarta.com/wms/vmap0'\n        }\n    },\n    layers: [\n        {\n            type: 'WMS',\n            layers: ['basic'],\n            baseURL: 'http://labs.metacarta.com/wms/vmap0',\n            format: 'image/jpeg'\n        }\n    ],\n    pages: [\n        {\n            center: [6, 45.5],\n            scale: 4000000,\n            dpi: 190,\n            geodetic: false,\n            strictEpsg4326: false,\n            ...CUSTOM_PARAMS...\n        }\n    ],\n    legends: [\n        {\n            classes: [\n                {\n                    icons: [\n                        'full url to the image'\n                    ],\n                    name: 'an icon name',\n                    iconBeforeName: true\n                }\n            ],\n            name: 'a class name'\n        }\n    ]\n}\n

                  The location to show on the map can be specified with a center and a scale as show or with a bbox like that:

                  bbox: [5, 45, 6, 46]\n

                  The print module will use the nearest scale and will make sure the aspect ratio stays correct.

                  The geodetic parameter can be set to true so the scale of geodetic layers can correctly be calculated. Certain projections (Google and Latlong for example) are based on a spheroid and therefore require geodetic: true in order to correctly calculate the scale. If the geodetic parameter is not present it will be assumed to be false.

                  The optional strictEpsg4326 parameter can be set to true to control how EPSG:4326 is interpreted. This needs to be true for WMS version 1.3.0 GetMap requests. See https://www.google.ch/search?q=epsg+4326+latitude+longitude+order&oq=epsg+4326+&aqs=chrome.3.69i57j0l5.5996j0j4&sourceid=chrome&espv=210&es_sm=93&ie=UTF-8 for some links to the history and mess that is EPSG:4326.

                  The outputFilename parameter is optional and if omitted the values used in the server's configuration will be used instead. If it is present it will be the name of the downloaded file. The suffix will be added if not left off in the parameter. The date can be substituted into the filename as well if desired. See configuration's outputFilename for more information and examples

                  The outputFormat parameter is optional and if omitted the value 'pdf' will be used. Only the formats returned in the info are permitted.

                  There are two locations where custom parameters can be added. Those will be ignored by the web service but, will be accessible from the layout templates.

                  Some layer types support merging more layers request into one, when the server is the same (for example WMS). For those, a mergeableParams section can be used to define merging strategies for some custom parameters. The default rule is to merge layers with identical custom parameters. Using mergeableParams, defined parameters values can be joined using a given separator and a default value if some of the layers miss the parameter. Mergeable parameters can have a context, that is the baseURL they can be used for (if not defined they will be used for every layer).

                  For the format of the layers section, please look at the implementations pointed by mapfish.PrintProtocol.SUPPORTED_TYPES.

                  This command returns the PDF file directly.

                  "},{"location":"extensions/printing/protocol/#createjson","title":"create.json","text":"

                  HTTP command:

                  POST {PRINT_URL}/create.json?url={PRINT_URL}%2Fcreate.json\n

                  The spec defined in the \"print.pdf\" command must be included in the POST body.

                  Returns a JSON structure like that:

                  {\n    getURL: 'http:\\/\\/localhost:5000\\/print\\/56723.pdf'\n}\n

                  The URL returned can be used to retrieve the PDF file. See the next section.

                  "},{"location":"extensions/printing/protocol/#idpdf","title":"{ID}.pdf","text":"

                  This command's URL is returned by the \"create.json\" command.

                  HTTP command:

                  GET {PRINT_URL}/{ID}.pdf\n

                  Returns the PDF. Can be called only during a limited time since the server side temporary file is deleted afterwards.

                  "},{"location":"extensions/printing/protocol/#multiple-maps-on-a-single-page","title":"Multiple maps on a single page","text":"To print more than one map on a single page you need to:
                  • specify several map blocks in a page of the yaml file, each with a distinct name property value
                  • use a particular syntax in the spec to bind different rendering properties to each map block

                  This is possible specifying a maps object in spec root object with a distinct key - object pair for each map. The key will refer the map block name as defined in yaml file. The object will contain layers and srs for the named map. Another maps object has to be specified inside the page object to describe positioning, scale and so on.

                  {\n    ...\n    maps: {\n        \"main\": {\n            layers: [\n                ...\n            ],\n            srs: 'EPSG:4326'\n        },\n        \"other\": {\n            layers: [\n                ...\n            ],\n            srs: 'EPSG:4326'\n        }\n    },\n    ...\n    pages: [\n        {\n            maps: {\n                \"main\": {\n                    center: [6, 45.5],\n                    scale: 4000000,\n                    dpi: 190,\n                    geodetic: false,\n                    strictEpsg4326: false,\n                    ...CUSTOM_PARAMS...\n                },\n                \"other\": {\n                    center: [7.2, 38.6],\n                    scale: 1000000,\n                    dpi: 300,\n                    geodetic: false,\n                    strictEpsg4326: false,\n                    ...CUSTOM_PARAMS...\n                }\n            }\n\n        }\n    ],\n    ...\n}\n

                  Other config blocks have been enabled to multiple maps usage. The scalebar block can be bound to a specific map, specifying a name property that matches the map name. Also, in text blocks you can use the \\${scale.} placeholder to print the scale of the map whose name is ."},{"location":"extensions/printing/protocol/#layers-params","title":"Layers Params","text":""},{"location":"extensions/printing/protocol/#vector","title":"Vector","text":"

                  Type: vector

                  Render vector layers. The geometries and the styling comes directly from the spec JSON.

                  • opacity (Defaults to 1.0)
                  • geoJson (Required) the geoJson to render
                  • styleProperty (Defaults to '_style') Name of the property within the features to use as style name. The given property may contain a style object directly.
                  • styles (Optional) dictionary of styles. One style is defined as in OpenLayers.Feature.Vector.style.
                  • name (Defaults to vector) the layer name.
                  "},{"location":"extensions/printing/protocol/#wms","title":"WMS","text":"

                  Type: wms

                  Support for the WMS protocol with possibilities to go through a WMS-C service (TileCache).

                  • opacity (Defaults to 1.0)
                  • baseURL (Required) Service URL
                  • customParams (Optional) Map, additional URL arguments
                  • layers (Required)
                  • styles (Optional)
                  • format (Required)
                  • version (Defaults to 1.1.1)
                  • useNativeAngle (Defaults to false) it true transform the map angle to customParams.angle for GeoServer, and customParams.map_angle for MapServer.
                  "},{"location":"extensions/printing/protocol/#wmts","title":"WMTS","text":"

                  Type: wmts

                  Support for the protocol using directly the content of a WMTS tiled layer, support REST or KVP.

                  Two possible mode, standard or simple, the simple mode imply that all the topLeftCorner are identical.

                  Standard mode:

                  • opacity (Defaults to 1.0)
                  • baseURL the 'ResourceURL' available in the WMTS capabilities.
                  • customParams (Optional) Map, additional URL arguments
                  • layer (Required) the layer name
                  • version (Defaults to 1.0.0) WMTS protocol version
                  • requestEncoding (Defaults to REST) REST or KVP
                  • style (Optional) the style name
                  • dimensions (Optional) list of dimensions names
                  • params (Optional) dictionary of dimensions name (capital) => value
                  • matrixSet (Required) the name of the matrix set
                  • matrixIds (Required) array of matrix ids e.g.:
                  [{\n    \"identifier\": \"0\",\n    \"matrixSize\": [1, 1],\n    \"resolution\": 4000,\n    \"tileSize\": [256, 256],\n    \"topLeftCorner\": [420000, 350000]\n}, ...]\n
                  • format (Optional, Required id requestEncoding is KVP)

                  Simple mode:

                  • baseURL base URL without the version.
                  • layer (Required)
                  • version (Required)
                  • requestEncoding (Required) REST
                  • tileOrigin (Required)
                  • tileSize (Required)
                  • extension (Required)
                  • resolutions (Required)
                  • style (Required)
                  • tileFullExtent (Required)
                  • zoomOffset (Required)
                  • dimensions (Optional)
                  • params (Optional)
                  • formatSuffix (Required)
                  "},{"location":"extensions/printing/protocol/#tms","title":"Tms","text":"

                  Type: tms

                  Support the TMS tile layout.

                  • opacity (Defaults to 1.0)
                  • baseURL (Required) Service URL
                  • customParams (Optional) Map, additional URL arguments
                  • maxExtent (Required) Array, extent coordinates [420000, 30000, 900000, 350000]
                  • tileSize (Required) Array, tile size e.g. [256, 256]
                  • format (Required)
                  • layer (Required)
                  • resolutions (Required) Array of resolutions
                  • tileOrigin (Optional) Object, tile origin. Defaults to 0,0

                  Resources:

                  • Quick intro to TMS requests: http://geowebcache.org/docs/current/services/tms.html
                  • TMS Spec (Not an Official Standard): http://wiki.osgeo.org/wiki/Tile_Map_Service_Specification
                  "},{"location":"extensions/printing/protocol/#xyz","title":"Xyz","text":"

                  Type: xyz

                  Support the tile layout z/x/y..

                  • opacity (Defaults to 1.0)
                  • baseURL (Required) Service URL
                  • customParams (Optional) Map, additional URL arguments
                  • maxExtent (Required) Array, extent coordinates [420000, 30000, 900000, 350000]
                  • tileSize (Required) Array, tile size e.g. [256, 256]
                  • resolutions (Required) Array of resolutions (Required) Array of resolutions
                  • extension (Required) file extension (Required) file extension
                  • tileOrigin (Optional) Array, tile origin e.g. [420000, 350000]
                  • tileOriginCorner tl or bl (Defaults to bl)
                  • path_format (Optional) url fragment used to construct the tile location. Can support variable replacement of ${x}, ${y}, ${z} and ${extension}. Defaults to zz/x/y.extension format. You can use multiple \"letters\" to indicate a replaceable pattern (aka, ${zzzz} will ensure the z variable is 0 padded to have a length of AT LEAST 4 characters).
                  "},{"location":"extensions/printing/protocol/#osm","title":"Osm","text":"

                  Type: osm

                  Support the OSM tile layout.

                  • opacity (Defaults to 1.0)
                  • baseURL (Required) Service URL
                  • customParams (Optional) Map, additional URL arguments
                  • maxExtent (Required) Array, extent coordinates [420000, 30000, 900000, 350000]
                  • tileSize (Required) Array, tile size e.g. [256, 256]
                  • resolutions (Required) Array of resolutions
                  • extension (Required) file extension
                  "},{"location":"extensions/printing/protocol/#tilecache","title":"TileCache","text":"

                  Type: tileCache

                  Support for the protocol using directly the content of a TileCache directory.

                  • opacity (Defaults to 1.0)
                  • baseURL (Required) Service URL
                  • customParams (Optional) Map, additional URL arguments
                  • layer (Required)
                  • maxExtent (Required) Array, extent coordinates [420000, 30000, 900000, 350000]
                  • tileSize (Required) Array, tile size e.g. [256, 256]
                  • resolutions (Required) Array of resolutions
                  • extension (Required) file extension
                  "},{"location":"extensions/printing/protocol/#image","title":"Image","text":"

                  Type: image

                  • opacity (Defaults to 1.0)
                  • name (Required)
                  • baseURL (Required) Service URL
                  • extent (Required)
                  "},{"location":"extensions/printing/protocol/#mapserver","title":"MapServer","text":"

                  Type: mapServer

                  Support mapserver WMS server.

                  • opacity (Defaults to 1.0)
                  • baseURL (Required) Service URL
                  • customParams (Optional) Map, additional URL arguments
                  • layers (Required)
                  • format (Required)
                  "},{"location":"extensions/printing/protocol/#kamap","title":"KaMap","text":"

                  Type: kaMap

                  Support for the protocol using the KaMap tiling method

                  • opacity (Defaults to 1.0)
                  • baseURL (Required) Service URL
                  • customParams (Optional) Map, additional URL arguments
                  • map
                  • group
                  • maxExtent (Required) Array, extent coordinates [420000, 30000, 900000, 350000]
                  • tileSize (Required) Array, tile size e.g. [256, 256]
                  • resolutions (Required) Array of resolutions
                  • extension (Required) file extension
                  "},{"location":"extensions/printing/protocol/#kamapcache","title":"KaMapCache","text":"

                  Type: kaMapCache

                  Support for the protocol talking directly to a web-accessible ka-Map cache generated by the precache2.php script.

                  • opacity (Defaults to 1.0)
                  • baseURL (Required) Service URL
                  • customParams (Optional) Map, additional URL arguments
                  • map (Required)
                  • group (Required)
                  • metaTileWidth (Required)
                  • metaTileHeight (Required)
                  • units (Required)
                  • maxExtent (Required) Array, extent coordinates [420000, 30000, 900000, 350000]
                  • tileSize (Required) Array, tile size e.g. [256, 256]
                  • resolutions (Required) Array of resolutions
                  • extension (Required) file extension
                  "},{"location":"extensions/printing/protocol/#google","title":"Google","text":"

                  Type: google or tiledGoogle

                  They used the Google Map Static API, tiledGoogle will create tiles and google only one image.

                  The google map reader has several custom parameters that can be added to the request they are:

                  • opacity (Optional, Defaults to 1.0)
                  • baseURL (Required, should be 'http://maps.google.com/maps/api/staticmap')
                  • customParams (Optional) Map, additional URL arguments
                  • maxExtent (Required, should be [-20037508.34, -20037508.34, 20037508.34, 20037508.34])
                  • resolutions (Required, should be [156543.03390625, 78271.516953125, 39135.7584765625, 19567.87923828125, 9783.939619140625, 4891.9698095703125, 2445.9849047851562, 1222.9924523925781, 611.4962261962891, 305.74811309814453, 152.87405654907226, 76.43702827453613, 38.218514137268066, 19.109257068634033, 9.554628534317017, 4.777314267158508, 2.388657133579254, 1.194328566789627, 0.5971642833948135, 0.29858214169740677, 0.14929107084870338, 0.07464553542435169])
                  • extension (Required, should be png)
                  • client (Optional)
                  • format (Optional)
                  • maptype (Required) - type of map to display: http://code.google.com/apis/maps/documentation/staticmaps/#MapTypes
                  • sensor (Optional) - specifies whether the application requesting the static map is using a sensor to determine the user's location
                  • language (Optional) - language of labels.
                  • markers (Optional) - add markers to the map: http://code.google.com/apis/maps/documentation/staticmaps/#Markers
                  markers: ['color:blue|label:S|46.5195933305192,6.566684726913701']\n
                  • path (Optional) - add a path to the map: http://code.google.com/apis/maps/documentation/staticmaps/#Paths
                  path: 'color:0x0000ff|weight:5|46.5095933305192,6.506684726913701|46.5195933305192,6.526684726913701|46.5395933305192,6.536684726913701|46.5695933305192,6.576684726913701',\n
                  "},{"location":"extensions/printing/protocol/#warranty-disclaimer-and-license","title":"Warranty disclaimer and license","text":"

                  The authors provide these documents \"AS-IS\", without warranty of any kind either expressed or implied.

                  Document under Creative Common License Attribution-Share Alike 2.5 Generic.

                  Authors: MapFish developers.

                  "},{"location":"extensions/querylayer/","title":"Cross-layer filtering","text":"

                  Cross-layer filtering provides the ability to find features from layer A that have a certain relationship to features in layer B. This can be used, for example, to find all bus stops within a given distance from a specified shop, or to find all coffee shops contained in a specified city district.

                  The querylayer module adds filter functions that implement cross-layer filtering. The functions work by querying a secondary layer within a filter being applied to a primary layer. The name of the secondary layer and an attribute to extract from it are provided as arguments, along with an ECQL filter expression to determine which features are of interest. A common use case is to extract a geometry-valued attribute, and then use the value(s) in a spatial predicate against a geometry attribute in the primary layer.

                  Filter functions are widely supported in GeoServer, so cross-layer filtering can be used in SLD rules and WMS and WFS requests, in either XML or CQL filters.

                  "},{"location":"extensions/querylayer/#installing-the-querylayer-module","title":"Installing the querylayer module","text":"
                  • Visit the website download page, locate your release, and download: querylayer

                    ::: warning ::: title Warning :::

                    The version of the extension must match the version of the GeoServer instance :::

                  • Extract the contents of the extension archive into the WEB-INF/lib directory of the GeoServer installation.

                  • To check the module is properly installed request the WFS 1.1 capabilities from the GeoServer home page. The Filter_Capabilities section should contain a reference to a function named queryCollection.
                  ...\n<ogc:Filter_Capabilities>\n    ...\n    <ogc:ArithmeticOperators>\n      ...\n      <ogc:Functions>\n        <ogc:FunctionNames>\n          ...\n          <ogc:FunctionName nArgs=\"-1\">queryCollection</ogc:FunctionName>\n          <ogc:FunctionName nArgs=\"-1\">querySingle</ogc:FunctionName>\n          ...\n        </ogc:FunctionNames>\n      </ogc:Functions>\n    </ogc:ArithmeticOperators>\n  </ogc:Scalar_Capabilities>\n  ...\n</ogc:Filter_Capabilities>\n...\n
                  "},{"location":"extensions/querylayer/#function-reference","title":"Function reference","text":"

                  The extension provides the following filter functions to support cross-layer filtering.

                  Name Arguments Description

                  querySingle layer : String, attribute : String, filter : String Queries the specified layer applying the specified ECQL filter and returns the value of attribute from the first feature in the result set. The layer name must be qualified (e.g. topp:states). If no filtering is desired use the filter INCLUDE.

                  queryCollection layer : String, attribute : String, filter : String Queries the specified layer applying the specified ECQL filter and returns a list containing the value of attribute for every feature in the result set. The layer name must be qualified (e.g. topp:states). If no filtering is desired use the filter INCLUDE. An exception is thrown if too many results are collected (see Memory Limits).

                  collectGeometries geometries: a list of Geometry objects Converts a list of geometries into a single Geometry object. The output of queryCollection must be converted by this function in order to use it in spatial filter expressions (since geometry lists cannot be used directly). An exception is thrown if too many coordinates are collected (see Memory Limits).

                  "},{"location":"extensions/querylayer/#optimizing-performance","title":"Optimizing performance","text":"

                  In the GeoServer 2.1.x series, in order to have cross-layer filters execute with optimal performance it is necessary to specify the following system variable when starting the JVM:

                  -Dorg.geotools.filter.function.simplify=true\n

                  This ensures the functions are evaluated once per query, instead of once per result feature. This flag is not necessary for the GeoServer 2.2.x series. (Hopefully this behavior will become the default in 2.1.x as well.)

                  "},{"location":"extensions/querylayer/#memory-limits","title":"Memory limits","text":"

                  The queryCollection and collectGeometries functions do not perform a true database-style join. Instead they execute a query against the secondary layer every time they are executed, and load the entire result into memory. The functions thus risk using excessive server memory if the query result set is very large, or if the collected geometries are very large. To prevent impacting server stability there are built-in limits to how much data can be processed:

                  • at most 1000 features are collected by queryCollection
                  • at most 37000 coordinates (1MB worth of Coordinate objects) are collected by collectGeometries

                  These limits can be overridden by setting alternate values for the following parameters (this can be done using JVM system variables, servlet context variables, or environment variables):

                  • QUERY_LAYER_MAX_FEATURES controls the maximum number of features collected by queryCollection
                  • GEOMETRY_COLLECT_MAX_COORDINATES controls the maximum number of coordinates collected by collectGeometries
                  "},{"location":"extensions/querylayer/#wms-examples","title":"WMS Examples","text":"

                  The following examples use the sf:bugsites, sf:roads and sf:restricted demo layers available in the standard GeoServer download.

                  • Display only the bug sites overlapping the restricted area whose category is 3:

                  The CQL cross-layer filter on the bugsites layer is

                  INTERSECTS(the_geom, querySingle('restricted', 'the_geom','cat = 3')).

                  The WMS request is:

                  http://localhost:8080/geoserver/wms?LAYERS=sf%3Aroads%2Csf%3Arestricted%2Csf%3Abugsites&STYLES=&FORMAT=image%2Fpng&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&EXCEPTIONS=application%2Fvnd.ogc.se_inimage&SRS=EPSG%3A26713&CQL_FILTER=INCLUDE%3BINCLUDE%3BINTERSECTS(the_geom%2C%20querySingle(%27restricted%27%2C%20%27the_geom%27%2C%27cat%20%3D%203%27))&BBOX=589081.6705629,4914128.1213261,609174.02430924,4928177.0717971&WIDTH=512&HEIGHT=358\n

                  The result is:

                  • Display all bug sites within 200 meters of any road:

                  The CQL cross-layer filter on the bugsites layer is

                  DWITHIN(the_geom, collectGeometries(queryCollection('sf:roads','the_geom','INCLUDE')), 200, meters).

                  The WMS request is:

                  http://localhost:8080/geoserver/wms?LAYERS=sf%3Aroads%2Csf%3Arestricted%2Csf%3Abugsites&STYLES=&FORMAT=image%2Fpng&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&EXCEPTIONS=application%2Fvnd.ogc.se_inimage&SRS=EPSG%3A26713&CQL_FILTER=INCLUDE%3BINCLUDE%3BDWITHIN(the_geom%2C%20collectGeometries(queryCollection(%27sf%3Aroads%27%2C%27the_geom%27%2C%27INCLUDE%27))%2C%20200%2C%20meters)&BBOX=589042.42768447,4914010.3926913,609134.78143081,4928059.3431623&WIDTH=512&HEIGHT=358\n

                  The result is:

                  "},{"location":"extensions/querylayer/#wfs-examples","title":"WFS Examples","text":"

                  The following examples use the sf:bugsites, sf:roads and sf:restricted demo layers available in the standard GeoServer download.

                  • Retrieve only the bug sites overlapping the restricted area whose category is 3:
                  <wfs:GetFeature xmlns:wfs=\"http://www.opengis.net/wfs\"\n                xmlns:sf=\"http://www.openplans.org/spearfish\"\n                xmlns:ogc=\"http://www.opengis.net/ogc\"\n                service=\"WFS\" version=\"1.0.0\">\n  <wfs:Query typeName=\"sf:bugsites\">\n    <ogc:Filter>\n      <ogc:Intersects>\n        <ogc:PropertyName>the_geom</ogc:PropertyName>\n        <ogc:Function name=\"querySingle\">\n           <ogc:Literal>sf:restricted</ogc:Literal>\n           <ogc:Literal>the_geom</ogc:Literal>\n           <ogc:Literal>cat = 3</ogc:Literal>\n        </ogc:Function>\n      </ogc:Intersects>\n    </ogc:Filter>\n  </wfs:Query>\n</wfs:GetFeature>\n
                  • Retrieve all bugsites within 200 meters of any road:
                  <wfs:GetFeature xmlns:wfs=\"http://www.opengis.net/wfs\"\n  xmlns:sf=\"http://www.openplans.org/spearfish\"\n  xmlns:ogc=\"http://www.opengis.net/ogc\"\n  service=\"WFS\" version=\"1.0.0\">\n  <wfs:Query typeName=\"sf:bugsites\">\n    <ogc:Filter>\n      <ogc:DWithin>\n        <ogc:PropertyName>the_geom</ogc:PropertyName>\n        <ogc:Function name=\"collectGeometries\">\n          <ogc:Function name=\"queryCollection\">\n            <ogc:Literal>sf:roads</ogc:Literal>\n            <ogc:Literal>the_geom</ogc:Literal>\n            <ogc:Literal>INCLUDE</ogc:Literal>\n          </ogc:Function>\n        </ogc:Function>\n        <ogc:Distance units=\"meter\">100</ogc:Distance>\n      </ogc:DWithin>\n    </ogc:Filter>\n  </wfs:Query>\n</wfs:GetFeature>\n
                  "},{"location":"extensions/sldservice/","title":"SLD REST Service","text":"

                  The SLD Service is a GeoServer REST service that can be used to create SLD styles on published GeoServer layers doing a classification on the layer data, following user provided directives.

                  The purpose of the service is to allow clients to dynamically publish data and create simple styles on it.

                  All the services are published under the common prefix /rest/sldservice/{layer}, where layer is the layer to classify/query.

                  "},{"location":"extensions/sldservice/#query-vector-data-attributes","title":"Query Vector Data Attributes","text":"

                  /attributes[.<format>]

                  Method Action Status code Formats Default Format GET Gets the list of attributes for the given layer (of vector type) 200 HTML, XML, JSON HTML

                  The service can be used to get the attributes list for the given vector layer. This can be used by a client as a prerequisite for the classify service, to get all the attributes usable for classification and let the user choose one.

                  "},{"location":"extensions/sldservice/#examples","title":"Examples","text":"

                  Get attributes for the states layer, in XML format

                  curl -v -u admin:geoserver -XGET \n  http://localhost:8080/geoserver/rest/sldservice/states/attributes.xml\n
                  <Attributes layer=\"states\">\n  <Attribute>\n    <name>P_FEMALE</name>\n    <type>Double</type>\n  </Attribute>\n  <Attribute>\n    <name>HOUSHOLD</name>\n    <type>Double</type>\n  </Attribute>\n  <Attribute>\n    <name>SERVICE</name>\n    <type>Double</type>\n  </Attribute>\n  ...\n</Attributes>\n

                  Get attributes for the states layer, in JSON format

                  curl -v -u admin:geoserver -XGET \n  http://localhost:8080/geoserver/rest/sldservice/states/attributes.json\n
                  {  \n   \"Attributes\":{  \n      \"@layer\":\"states\",\n      \"Attribute\":[  \n         {  \n            \"name\":\"P_FEMALE\",\n            \"type\":\"Double\"\n         },\n         {  \n            \"name\":\"HOUSHOLD\",\n            \"type\":\"Double\"\n         },\n         {  \n            \"name\":\"SERVICE\",\n            \"type\":\"Double\"\n         },\n         ...\n      ]\n   }\n}\n
                  "},{"location":"extensions/sldservice/#classify-raster-and-vector-data","title":"Classify Raster and Vector Data","text":"

                  /classify[.<format>]

                  Method Action Status code Formats Default Format GET Create a set of SLD Rules for the given layer 200 HTML, XML, JSON HTML

                  The service can be used to create a set of SLD rules for the given vector layer, specifying the attribute used for classification, the classification type (equalInterval, uniqueInterval, quantile, jenks, equalArea, standardDeviation) and one of the predefined color ranges (red, blue, gray, jet, random, custom), together with some other optional parameters.

                  The same can be applied on a raster layer too, in order to classify its contents. Data from the first band is used by default, but a different one can be selected.

                  Using the CUSTOM ColorMap, startColor and endColor (and optionally midColor) have to be specified.

                  The parameters usable to customize the SLD are:

                  Parameter Description Values Default Value intervals Number of intervals (rules) for the SLD integer numeric value 2 attribute (mandatory) Classification attribute For vector layers, one of the layer attribute names, for raster layers, a band number (starting from one, like in the raster symbolizer) No default for vectors, \"1\" for rasters method Classification method equalInterval, uniqueInterval, quantile, jenks, equalArea, standardDeviation (intervals above and below the mean of one standard deviation, available for vectors only) equalInterval open open or closed ranges true, false false reverse normal or inverted ranges true, false false normalize normalize (cast) attribute to double type (needed by some stores to handle integer types correctly) true, false false ramp color ranges to use red, blue, gray, jet, random, custom red startColor starting color for the custom ramp endColor ending color for the custom ramp midColor central color for the custom ramp colors list of comma delimited colors for the custom ramp (use this instead of startColor, endColor and midColor to specify colors in more detail) strokeColor color of the stroke, for points and polygons BLACK strokeWeight weight of the stroke, for points and polygons (use a negative value to not include stroke in style) 1 pointSize size of points 15 fullSLD create a full valid SLD document, instead of the Rules fragment only true or false false cache append caching headers to the responses expire time in seconds, use 0 to disable cache 600 (10 minutes) viewparams allows use of parametric views view parameters in the usual format (:;...;:) customClasses allows specifying a set of custom classes (client driven style); no classes calculation will happen (method, intervals, etc. are ignored) classes in the following format: ,,;...;,,) bbox allows to run the classification on a specific bounding box. Recommended when the overall dataset is too big, and the classification can be performed on a smaller dataset, or to enhance the visualization of a particular subset of data same syntax as WMS/WFS, expected axis order is east/north unless the spatial reference system is explicitly provided, minx,miny,max,maxy[,srsName] stddevs limits the data the classifier is working on to a range of \"stddevs\" standard deviations around the mean value. a positive floating-point number (e.g., '1', '2.5', '3'). env a list of environment variables that the underlying layer may be using to select features/rasters to be classified (e.g., by using the filter in vector and mosaic layer definitions) a semicolon separate list of name to value assignments, e.g. name1:value1;name2:value2;name3:value3;... continuous used only for raster layers, if set to true will generate a raster palette that interpolates linearly between classified values true false percentages allows to obtain percentages of values in each class. For raster layers they will be included in the label of the ColorMapEntry, while for vector layer they will be placed in the rule title; in both cases they will be placed at the end of the text between parentheses. true false percentagesScale number of digits of percentages integer numeric value 1 intervalsForUnique Max number of intervals (rules or ColorMapEntry) that a uniqueIntervalClassification can produce. If the number of classes produced by the classification is greater than the number specified by this parameter, the service will return an error message. integer numeric value -1"},{"location":"extensions/sldservice/#more-on-unique-intervals-classification","title":"More on unique intervals classification","text":"

                  The intervalsForUnique parameter allows the user to control the number of classes generated by the classification, that is important when dealing with large dataset. In this case the check on the classes' number will be made once the unique interval classification has been performed. Additionally it is possible to define a system variable named org.geoserver.sldService.maxUniqueRange to define the maximum number of values that can be collected by the classification (default value is 1024). This control is performed before the unique interval classification is performed on the data. If the number of values is found to be greater than the system variable value, the service will return an error message.

                  "},{"location":"extensions/sldservice/#examples_1","title":"Examples","text":"

                  A default (equalInterval) classification on the states layer LAND_KM attribute using a red based color range.

                  curl -v -u admin:geoserver -XGET \n  http://localhost:8080/geoserver/rest/sldservice/states/classify.xml?attribute=LAND_KM&ramp=red\n
                  <Rules>\n  <Rule>\n    <Title> &gt; 159.1 AND &lt;= 344189.1</Title>\n    <Filter>\n      <And>\n        <PropertyIsGreaterThanOrEqualTo>\n          <PropertyName>LAND_KM</PropertyName>\n          <Literal>159.1</Literal>\n        </PropertyIsGreaterThanOrEqualTo>\n        <PropertyIsLessThanOrEqualTo>\n          <PropertyName>LAND_KM</PropertyName>\n          <Literal>344189.1</Literal>\n        </PropertyIsLessThanOrEqualTo>\n      </And>\n    </Filter>\n    <PolygonSymbolizer>\n      <Fill>\n        <CssParameter name=\"fill\">#680000</CssParameter>\n      </Fill>\n      <Stroke/>\n    </PolygonSymbolizer>\n  </Rule>\n  <Rule>\n    <Title> &gt; 344189.1 AND &lt;= 688219.2</Title>\n    <Filter>\n      <And>\n        <PropertyIsGreaterThan>\n          <PropertyName>LAND_KM</PropertyName>\n          <Literal>344189.1</Literal>\n        </PropertyIsGreaterThan>\n        <PropertyIsLessThanOrEqualTo>\n          <PropertyName>LAND_KM</PropertyName>\n          <Literal>688219.2</Literal>\n        </PropertyIsLessThanOrEqualTo>\n      </And>\n    </Filter>\n    <PolygonSymbolizer>\n      <Fill>\n        <CssParameter name=\"fill\">#B20000</CssParameter>\n      </Fill>\n      <Stroke/>\n    </PolygonSymbolizer>\n  </Rule>\n</Rules>\n

                  A uniqueInterval classification on the states layer SUB_REGION attribute using a red based color range.

                  curl -v -u admin:geoserver -XGET \n  http://localhost:8080/geoserver/rest/sldservice/states/classify.xml?attribute=SUB_REGION&ramp=red&method=uniqueInterval\n
                  <Rules>\n  <Rule>\n    <Title>E N Cen</Title>\n    <Filter>\n      <PropertyIsEqualTo>\n        <PropertyName>SUB_REGION</PropertyName>\n        <Literal>E N Cen</Literal>\n      </PropertyIsEqualTo>\n    </Filter>\n    <PolygonSymbolizer>\n      <Fill>\n        <CssParameter name=\"fill\">#330000</CssParameter>\n      </Fill>\n      <Stroke/>\n    </PolygonSymbolizer>\n  </Rule>\n  <Rule>\n    <Title>E S Cen</Title>\n    <Filter>\n      <PropertyIsEqualTo>\n        <PropertyName>SUB_REGION</PropertyName>\n        <Literal>E S Cen</Literal>\n      </PropertyIsEqualTo>\n    </Filter>\n    <PolygonSymbolizer>\n      <Fill>\n        <CssParameter name=\"fill\">#490000</CssParameter>\n      </Fill>\n      <Stroke/>\n    </PolygonSymbolizer>\n  </Rule>\n  ...\n</Rules>\n

                  A uniqueInterval classification on the states layer SUB_REGION attribute using a red based color range and 3 intervals.

                  curl -v -u admin:geoserver -XGET \n  http://localhost:8080/geoserver/rest/sldservice/states/classify.xml?attribute=SUB_REGION&ramp=red&method=uniqueInterval&intervals=3\n
                  <string>Intervals: 9</string>\n

                  A quantile classification on the states layer PERSONS attribute with a custom color ramp and 3 closed intervals.

                  curl -v -u admin:geoserver -XGET \n  http://localhost:8080/geoserver/rest/sldservice/states/classify.xml?attribute=PERSONS&ramp=CUSTOM&method=quantile&intervals=3&startColor=0xFF0000&endColor=0x0000FF\n
                  <Rules>\n  <Rule>\n    <Title> &gt; 453588.0 AND &lt;= 2477574.0</Title>\n    <Filter>\n      <And>\n        <PropertyIsGreaterThanOrEqualTo>\n          <PropertyName>PERSONS</PropertyName>\n          <Literal>453588.0</Literal>\n        </PropertyIsGreaterThanOrEqualTo>\n        <PropertyIsLessThanOrEqualTo>\n          <PropertyName>PERSONS</PropertyName>\n          <Literal>2477574.0</Literal>\n        </PropertyIsLessThanOrEqualTo>\n      </And>\n    </Filter>\n    <PolygonSymbolizer>\n      <Fill>\n        <CssParameter name=\"fill\">#FF0000</CssParameter>\n      </Fill>\n      <Stroke/>\n    </PolygonSymbolizer>\n  </Rule>\n  <Rule>\n    <Title> &gt; 2477574.0 AND &lt;= 4866692.0</Title>\n    <Filter>\n      <And>\n        <PropertyIsGreaterThan>\n          <PropertyName>PERSONS</PropertyName>\n          <Literal>2477574.0</Literal>\n        </PropertyIsGreaterThan>\n        <PropertyIsLessThanOrEqualTo>\n          <PropertyName>PERSONS</PropertyName>\n          <Literal>4866692.0</Literal>\n        </PropertyIsLessThanOrEqualTo>\n      </And>\n    </Filter>\n    <PolygonSymbolizer>\n      <Fill>\n        <CssParameter name=\"fill\">#AA0055</CssParameter>\n      </Fill>\n      <Stroke/>\n    </PolygonSymbolizer>\n  </Rule>\n  <Rule>\n    <Title> &gt; 4866692.0 AND &lt;= 2.9760021E7</Title>\n    <Filter>\n      <And>\n        <PropertyIsGreaterThan>\n          <PropertyName>PERSONS</PropertyName>\n          <Literal>4866692.0</Literal>\n        </PropertyIsGreaterThan>\n        <PropertyIsLessThanOrEqualTo>\n          <PropertyName>PERSONS</PropertyName>\n          <Literal>2.9760021E7</Literal>\n        </PropertyIsLessThanOrEqualTo>\n      </And>\n    </Filter>\n    <PolygonSymbolizer>\n      <Fill>\n        <CssParameter name=\"fill\">#5500AA</CssParameter>\n      </Fill>\n      <Stroke/>\n    </PolygonSymbolizer>\n  </Rule>\n</Rules>\n

                  A quantile classification on the states layer PERSONS attribute with a custom color ramp and 3 open intervals.

                  curl -v -u admin:geoserver -XGET \n  http://localhost:8080/geoserver/rest/sldservice/states/classify.xml?attribute=PERSONS&ramp=CUSTOM&method=quantile&intervals=3&startColor=0xFF0000&endColor=0x0000FF&open=true\n
                  <Rules>\n  <Rule>\n    <Title> &lt;= 2477574.0</Title>\n    <Filter>\n      <PropertyIsLessThanOrEqualTo>\n        <PropertyName>PERSONS</PropertyName>\n        <Literal>2477574.0</Literal>\n      </PropertyIsLessThanOrEqualTo>\n    </Filter>\n    <PolygonSymbolizer>\n      <Fill>\n        <CssParameter name=\"fill\">#FF0000</CssParameter>\n      </Fill>\n      <Stroke/>\n    </PolygonSymbolizer>\n  </Rule>\n  <Rule>\n    <Title> &gt; 2477574.0 AND &lt;= 4866692.0</Title>\n    <Filter>\n      <And>\n        <PropertyIsGreaterThan>\n          <PropertyName>PERSONS</PropertyName>\n          <Literal>2477574.0</Literal>\n        </PropertyIsGreaterThan>\n        <PropertyIsLessThanOrEqualTo>\n          <PropertyName>PERSONS</PropertyName>\n          <Literal>4866692.0</Literal>\n        </PropertyIsLessThanOrEqualTo>\n      </And>\n    </Filter>\n    <PolygonSymbolizer>\n      <Fill>\n        <CssParameter name=\"fill\">#AA0055</CssParameter>\n      </Fill>\n      <Stroke/>\n    </PolygonSymbolizer>\n  </Rule>\n  <Rule>\n    <Title> &gt; 4866692.0</Title>\n    <Filter>\n      <PropertyIsGreaterThan>\n        <PropertyName>PERSONS</PropertyName>\n        <Literal>4866692.0</Literal>\n      </PropertyIsGreaterThan>\n    </Filter>\n    <PolygonSymbolizer>\n      <Fill>\n        <CssParameter name=\"fill\">#5500AA</CssParameter>\n      </Fill>\n      <Stroke/>\n    </PolygonSymbolizer>\n  </Rule>\n</Rules>\n
                  "},{"location":"extensions/sldservice/#classify-raster-data","title":"Classify Raster Data","text":"

                  This resource is deprecated, as the classify endpoint can now also handle raster data

                  /rasterize[.<format>]

                  Method Action Status code Formats Default Format GET Create a ColorMap SLD for the given layer (of coverage type) 200 HTML, XML, JSON, SLD HTML

                  The service can be used to create a ColorMap SLD for the given coverage, specifying the type of ColorMap (VALUES, INTERVALS, RAMP) and one of the predefined color ranges (RED, BLUE, GRAY, JET, RANDOM, CUSTOM).

                  Using the CUSTOM ColorMap, startColor and endColor (and optionally midColor) have to be specified.

                  The parameters usable to customize the ColorMap are:

                  Parameter Description Values Default Value min Minimum value for classification double numeric value 0.0 max Maximum value for classification double numeric value 100.0 classes Number of classes for the created map integer numeric value 100 digits Number of fractional digits for class limits (in labels) integer numeric value 5 type ColorMap type INTERVALS, VALUES, RAMP RAMP ramp ColorMap color ranges RED, BLUE, GRAY, JET, RANDOM, CUSTOM RED startColor starting color for the CUSTOM ramp endColor ending color for the CUSTOM ramp midColor central color for the CUSTOM ramp cache append caching headers to the responses expire time in seconds, use 0 to disable cache 600 (10 minutes)"},{"location":"extensions/sldservice/#examples_2","title":"Examples","text":"

                  A RED color ramp with 5 classes

                  curl -v -u admin:geoserver -XGET \n  http://localhost:8080/geoserver/rest/sldservice/sfdem/rasterize.sld?min=0&max=100&classes=5&type=RAMP&ramp=RED&digits=1\n
                  <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<sld:StyledLayerDescriptor xmlns=\"http://www.opengis.net/sld\" xmlns:sld=\"http://www.opengis.net/sld\" xmlns:ogc=\"http://www.opengis.net/ogc\" xmlns:gml=\"http://www.opengis.net/gml\" version=\"1.0.0\">\n    <sld:NamedLayer>\n        <sld:Name>Default Styler</sld:Name>\n        <sld:UserStyle>\n            <sld:Name>Default Styler</sld:Name>\n            <sld:FeatureTypeStyle>\n                <sld:Name>name</sld:Name>\n                <sld:FeatureTypeName>gray</sld:FeatureTypeName>\n                <sld:Rule>\n                    <sld:RasterSymbolizer>\n                        <sld:ColorMap>\n                            <sld:ColorMapEntry color=\"#000000\" opacity=\"0\" quantity=\"-1.0E-9\" label=\"transparent\"/>\n                            <sld:ColorMapEntry color=\"#420000\" opacity=\"1.0\" quantity=\"0.0\" label=\"0.0\"/>\n                            <sld:ColorMapEntry color=\"#670000\" opacity=\"1.0\" quantity=\"25.0\" label=\"25.0\"/>\n                            <sld:ColorMapEntry color=\"#8B0000\" opacity=\"1.0\" quantity=\"50.0\" label=\"50.0\"/>\n                            <sld:ColorMapEntry color=\"#B00000\" opacity=\"1.0\" quantity=\"75.0\" label=\"75.0\"/>\n                            <sld:ColorMapEntry color=\"#D40000\" opacity=\"1.0\" quantity=\"100.0\" label=\"100.0\"/>\n                        </sld:ColorMap>\n                    </sld:RasterSymbolizer>\n                </sld:Rule>\n            </sld:FeatureTypeStyle>\n        </sld:UserStyle>\n    </sld:NamedLayer>\n</sld:StyledLayerDescriptor>\n

                  A CUSTOM color ramp with 5 classes, with colors ranging from RED (0xFF0000) to BLUE (0x0000FF).

                  curl -v -u admin:geoserver -XGET \n  http://localhost:8080/geoserver/rest/sldservice/sfdem/rasterize.sld?min=0&max=100&classes=5&type=RAMP&ramp=CUSTOM&digits=1&startColor=0xFF0000&endColor=0x0000FF\n
                  <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<sld:StyledLayerDescriptor xmlns=\"http://www.opengis.net/sld\" xmlns:sld=\"http://www.opengis.net/sld\" xmlns:ogc=\"http://www.opengis.net/ogc\" xmlns:gml=\"http://www.opengis.net/gml\" version=\"1.0.0\">\n    <sld:NamedLayer>\n        <sld:Name>Default Styler</sld:Name>\n        <sld:UserStyle>\n            <sld:Name>Default Styler</sld:Name>\n            <sld:FeatureTypeStyle>\n                <sld:Name>name</sld:Name>\n                <sld:FeatureTypeName>gray</sld:FeatureTypeName>\n                <sld:Rule>\n                    <sld:RasterSymbolizer>\n                        <sld:ColorMap>\n                            <sld:ColorMapEntry color=\"#000000\" opacity=\"0\" quantity=\"-1.0E-9\" label=\"transparent\"/>\n                            <sld:ColorMapEntry color=\"#FF0000\" opacity=\"1.0\" quantity=\"0.0\" label=\"0.0\"/>\n                            <sld:ColorMapEntry color=\"#CC0033\" opacity=\"1.0\" quantity=\"25.0\" label=\"25.0\"/>\n                            <sld:ColorMapEntry color=\"#990066\" opacity=\"1.0\" quantity=\"50.0\" label=\"50.0\"/>\n                            <sld:ColorMapEntry color=\"#660099\" opacity=\"1.0\" quantity=\"75.0\" label=\"75.0\"/>\n                            <sld:ColorMapEntry color=\"#3300CC\" opacity=\"1.0\" quantity=\"100.0\" label=\"100.0\"/>\n                        </sld:ColorMap>\n                    </sld:RasterSymbolizer>\n                </sld:Rule>\n            </sld:FeatureTypeStyle>\n        </sld:UserStyle>\n    </sld:NamedLayer>\n</sld:StyledLayerDescriptor>\n
                  "},{"location":"extensions/sldservice/#capabilities","title":"Capabilities","text":"

                  /capabilities[.<format>]

                  Method Action Status code Formats Default Format GET Returns the supported classification's methods for rasters and vectors 200 JSON, XML JSON

                  The service can be used to retrieve the capabilities of the SldService plugin. At the time of writing the endpoint will simply return a list of supported classification's methods for both raster and vector data. It can be useful i.e. for clients who might be dealing with different GeoServer versions to know which classification methods is available to be used. Follow the service's outputs in json and xml format:

                  {\n\"capabilities\": {\n    \"vector\": {\n        \"classifications\": [\n            \"quantile\",\n            \"jenks\",\n            \"equalArea\",\n            \"equalInterval\",\n            \"uniqueInterval\",\n            \"standardDeviation\"\n        ]\n    },\n    \"raster\": {\n        \"classifications\": [\n            \"quantile\",\n            \"jenks\",\n            \"equalArea\",\n            \"equalInterval\",\n            \"uniqueInterval\"\n        ]\n    }\n}\n}\n
                  <capabilities>\n  <vector>\n      <classifications>quantile</classifications>\n      <classifications>jenks</classifications>\n      <classifications>equalArea</classifications>\n      <classifications>equalInterval</classifications>\n      <classifications>uniqueInterval</classifications>\n      <classifications>standardDeviation</classifications>\n  </vector>\n  <raster>\n      <classifications>quantile</classifications>\n      <classifications>jenks</classifications>\n      <classifications>equalArea</classifications>\n      <classifications>equalInterval</classifications>\n      <classifications>uniqueInterval</classifications>\n  </raster>\n</capabilities>\n
                  "},{"location":"extensions/vectortiles/","title":"Vector Tiles","text":"

                  GeoServer supports \"vector tile\" output in addition to the more standard image tile output. While the standard WMS output will generate a georeferenced map image, a vector tile contains georeferenced vector data, clipped into tiles for easy retrieval.

                  Note

                  This is an output format, not a data source.

                  Note

                  Here are two background video talks about \"Vector Tiles with GeoServer and OpenLayers\":

                  • FOSS4G.NA 2016
                  • FOSS4G 2016
                  • Installing the Vector Tiles Extension
                  • Vector tiles tutorial
                  "},{"location":"extensions/vectortiles/install/","title":"Installing the Vector Tiles Extension","text":"
                  1. From the website download page, locate your release, and download: vectortiles

                    Warning

                    Make sure to match the version of the extension to the version of GeoServer.

                  2. Extract the archive and copy the contents into the GeoServer WEB-INF/lib directory.

                  3. Restart GeoServer.

                  To verify that the extension was installed successfully

                  1. Open the Web administration interface

                  2. Click Layers and select a vector layer

                  3. Click the Tile Caching tab

                  4. Scroll down to the section on Tile Formats. In addition to the standard GIF/PNG/JPEG formats, you should see the following:

                    • application/json;type=geojson
                    • application/json;type=topojson
                    • application/vnd.mapbox-vector-tile

                    Vector tiles tile formats

                    If you don't see these options, the extension did not install correctly.

                  "},{"location":"extensions/vectortiles/tutorial/","title":"Vector tiles tutorial","text":"

                  This tutorial will show how to use the GeoServer vector tiles output.

                  "},{"location":"extensions/vectortiles/tutorial/#why-use-vector-tiles","title":"Why use vector tiles?","text":"

                  The advantages of vector tiles are:

                  • Rendering is done by the client (for example, OpenLayers), not by the server. This allows different maps/applications to style a map differently without having to reconfigure GeoServer.
                  • The size of a vector tile is usually smaller than an image tile, resulting in faster data transfer and lower bandwidth usage.
                  • GeoWebCache, embedded with GeoServer efficiently stores the vector tile data. Since styling is done by the client, not the server, GeoWebCache only needs to store one tile for all different styles.
                  • Because the vector data is available on the client, very high-resolution maps can be drawn without corresponding increases in bandwidth.
                  • The client has native access to the actual feature information (attributes and geometry), allowing for very sophisticated rendering.

                  On the other hand, the main disadvantage of vector tiles is that the geographic data may need to be pre-processed to allow the client to do the drawings it requires (similar to preprocessing data for image maps). With this in mind, vector tiles should only be used for rendering.

                  "},{"location":"extensions/vectortiles/tutorial/#vector-tile-formats","title":"Vector tile formats","text":"

                  GeoServer can also produce vector tiles in three formats: GeoJSON, TopoJSON, and MapBox Vector (MVT). These are also supported by OpenLayers and other clients.

                  • MVT is the preferred format for production.
                  Format MIME Description MapBox Vector (MVT) application/vnd.mapbox-vector-tile Recommended Format This is an efficient binary format that is widely supported by almost all Vector Tile applications. GeoJSON application/json;type=geojson This is a human readable JSON format. Although many geo-spatial applications support GeoJSON datasets, few Vector Tile applications support tiles in this format. Supported by Open Layers 3. TopoJSON application/json;type=topojson This is a very complex, but somewhat human readable JSON format that is good for polygon coverages. It is not a widely supported and very few Vector Tile applications support it. Supported by Open Layers 3."},{"location":"extensions/vectortiles/tutorial/#publish-vector-tiles-in-geowebcache","title":"Publish vector tiles in GeoWebCache","text":"

                  We'll be publishing our vector tiles through GeoWebCache and publishing the layer in a custom OpenLayers application.

                  For this tutorial, we'll be using the layer opengeo:countries to show off the capabilities, though with slight modifications, any layer will do.

                  Note

                  Download the Admin 0 - Countries shapefile and publish the layer as opengeo:countries.

                  1. In the GeoServer admin interface, click Tile Layers under Tile Caching.

                    Tile Layers

                  2. Click opengeo:countries in the list of layers.

                  3. By default the tile formats are image/jpeg and image/png. Check the boxes for the following vector tile formats:

                    • application/json;type=geojson
                    • application/json;type=topojson
                    • application/vnd.mapbox-vector-tile

                    Vector tiles tile formats

                  4. Click Save.

                  Our layer is now ready to be served.

                  "},{"location":"extensions/vectortiles/tutorial/#create-openlayers-application-tms-vector-tiles","title":"Create OpenLayers application - TMS Vector Tiles","text":"
                  1. Create a www/tms-vectortiles directory inside your GeoServer Data Directory.

                  2. Download the latest version of OpenLayers. Download the v-package.zip file`_.

                  3. Extract the following files from the downloaded archive to the directory created in step 1:

                    • v<ol-version>-package/dist/ol.js
                    • v<ol-version>-package/ol.css
                  4. In a text editor, create a new file with the following content:

                    <!DOCTYPE html -->\n<html>\n<head>\n  <title>Vector tiles</title>\n  <script src=\"ol.js\"></script>\n  <link rel=\"stylesheet\" href=\"ol.css\">\n  <style>\n    html, body {\n      font-family: sans-serif;\n      width: 100%;\n    }\n    .map {\n      height: 500px;\n      width: 100%;\n    }\n  </style>\n</head>\n<body>\n  <h3>Mapbox Protobuf - vector tiles TMS</h3>\n  <div id=\"map\" class=\"map\"></div>\n  <script>\n\n  var style_simple = new ol.style.Style({\n    fill: new ol.style.Fill({\n      color: '#ADD8E6'\n    }),\n    stroke: new ol.style.Stroke({\n      color: '#880000',\n      width: 1\n    })\n  });\n\n  function simpleStyle(feature) { \n    return style_simple;\n  }\n\n  var layer = 'opengeo:countries';\n  var projection_epsg_no = '900913';\n  var map = new ol.Map({\n    target: 'map',\n    view: new ol.View({\n      center: [0, 0],\n      zoom: 2\n    }),\n    layers: [new ol.layer.VectorTile({\n      style:simpleStyle,\n      source: new ol.source.VectorTile({\n        tilePixelRatio: 1, // oversampling when > 1\n        tileGrid: ol.tilegrid.createXYZ({maxZoom: 19}),\n        format: new ol.format.MVT(),\n        url: '/geoserver/gwc/service/tms/1.0.0/' + layer +\n            '@EPSG%3A'+projection_epsg_no+'@pbf/{z}/{x}/{-y}.pbf'\n      })\n    })]\n  });\n  </script>\n</body>\n</html>\n
                  5. Save this file in the directory created above as index.html.

                  6. Navigate to http://localhost:8080/geoserver/www/tms-vectortiles/index.html and verify that the output shows without any errors.

                    Note

                    If your GeoServer is deployed at a server other than http://localhost:8080/geoserver/, then please adjust the above URL.

                    Vector tile output

                  7. These tiles are being rendered by the OpenLayers client.

                    "},{"location":"extensions/vectortiles/tutorial/#create-openlayers-application-wms-vector-tiles","title":"Create OpenLayers application - WMS Vector Tiles","text":"

                    Note

                    Vector tiles requested with WMS allows retrieving non-cached vector tiles (server side) by setting the tiled=false parameter on the getMap request. This setting could be particularly useful when serving fast changing source data that should constantly be kept up-to-date for display. However, in terms of rendering performances, vector tiles can be faster than a PNG provided there are few features per tile and a limited amount of attributes in the source vector data. Vice versa, for tiles containing a large number of features with a long list of attributes the PNG may still be the preferred option since it is orders of magnitude smaller in size.

                    1. Create a www/wms-vectortiles directory inside your GeoServer Data Directory.

                    2. Download the latest version of OpenLayers. Download the v-package.zip file.

                    3. Extract the following files from the downloaded archive to the directory created in step 1:

                      • v<ol-version>-package/dist/ol.js
                      • v<ol-version>-package/ol.css
                    4. In a text editor, create a new file with the following content:

                      <!doctype html>\n<html>\n<head>\n  <title>Vector tiles</title>\n  <script src=\"ol.js\"></script>\n  <link rel=\"stylesheet\" href=\"ol.css\">\n  <style>\n    html, body {\n      font-family: sans-serif;\n      width: 100%;\n    }\n    .map {\n      height: 500px;\n      width: 100%;\n    }\n  </style>\n</head>\n<body>\n  <h3>Mapbox Protobuf - vector tiles WMS</h3>\n  <div class=\"refresh-container\">\n  <button id=\"refresh-button\" type=\"button\" onclick=\"updateFunc();\">Refresh/reload cache</button>\n  </div>\n  <div id=\"map\" class=\"map\"></div>\n  <script>\n\n    var layerParams = {'LAYERS': 'opengeo:countries', 'TILED': false, 'FORMAT': 'application/vnd.mapbox-vector-tile'};\n\n  var sourceOptions = {\n      url: '/geoserver/wms?',\n      params: layerParams,\n      serverType: 'geoserver',\n      transition: 0,\n      hidpi: false\n    };\n\n  var WMSTileSource = new ol.source.TileWMS(sourceOptions);\n\n  var mvtVectorSource = new ol.source.VectorTile(\n    Object.assign(\n      sourceOptions,\n      {\n        url: undefined,\n        format: new ol.format.MVT({layerName: '_layer_'}),\n        tileUrlFunction: function(tileCoord, pixelRatio, projection) {\n          return WMSTileSource.tileUrlFunction(tileCoord, pixelRatio, projection);\n        }\n      }\n    )\n  );\n\n\n    var updateFunc = function () {\n    WMSTileSource.updateParams(\n      Object.assign(\n        layerParams,\n        {\n          '_v_' : Date.now()\n        }\n      )\n    );\n    WMSTileSource.tileCache.pruneExceptNewestZ();\n    mvtVectorSource.clear();\n    mvtVectorSource.refresh();\n  };\n\n\n  var layer = new ol.layer.VectorTile({\n    source: mvtVectorSource\n  });\n\n  var map = new ol.Map({\n    target: 'map',\n    view: new ol.View({\n      center: [0,0],\n      zoom: 2\n    }),\n    layers: [layer]\n  });\n\n  </script>\n</body>\n</html>\n
                    5. Save this file in the directory created above as index.html.

                    6. Navigate to http://localhost:8080/geoserver/www/wms-vectortiles/index.html and verify that the output shows without any errors.

                      Note

                      If your GeoServer is deployed at a server other than http://localhost:8080/geoserver/, then please adjust the above URL.

                    7. "},{"location":"extensions/vectortiles/tutorial/#styling-vector-tiles","title":"Styling vector tiles","text":"

                      Since these tiles are rendered in the client, we need only change the styling instructions inside the client application. No changes to GeoServer are required, and tiles will not have to be regenerated.

                      1. Change the fill color to light green:

                        var style_simple = new ol.style.Style({\n  fill: new ol.style.Fill({\n    color: 'lightgreen'\n  }),\n   stroke: new ol.style.Stroke({\n      color: '#880000',\n      width: 1\n    })\n}) ;\n
                      2. Save the file and reload the application.

                        Vector tile output with alternate color

                      3. We can also do attributed-based styling. This dataset contains has a property (region_un) which contains the region the country is in. Let's highlight countries in Africa by adding another style definition below the existing style:

                        var style_highlighted = new ol.style.Style({\n  fill: new ol.style.Fill({\n    color: 'yellow'\n  }),\n  stroke: new ol.style.Stroke({\n    color: '#880000',\n    width: 1\n  })\n});\n
                      4. Replace the existing style function:

                        function simpleStyle(feature) { \n  return style_simple;\n}\n

                        with the following:

                        function simpleStyle(feature) { \n  if (feature.get(\"region_un\") == \"Africa\") {\n    return style_highlighted;\n  }\n  return style_simple;\n}\n
                      5. Save the file and reload the application.

                        Vector tile output with Africa highlighted

                      "},{"location":"extensions/wcs20eo/","title":"Web Coverage Service 2.0 Earth Observation extensions","text":"

                      The WCS 2.0 Earth Observation application profile (EO-WCS, OGC 10-140r1) extends the base WCS 2.0 protocol by adding temporal support and complex coverage structural description to the base WCS 2.0 protocol, in addition to requiring that a number of other extensions are supported - the base GeoServer WCS 2.0 module already supports all of those, such as subsetting and reprojection for example). The full specification can be downloaded from the OGC website.

                      In the WCS 2.0 EO data model we not only have coverages, but also stitched mosaics (sets of coverages making up a mosaic of images, all granules having the same time and elevation) and dataset series, groups of coverages having different times and/or other attributes (elevation, custom dimensions). A dataset series is exposed in the capabilities document (inside the extension section) and its internal structure can be retrieved calling the new DescribeEOCoverageSet call. At the time of writing the EO extension adds support for dataset series, but does not provide direct support for stitched mosaic description.

                      Each grid layer exposing its inner structure will then expose a flag to enable its exposure as a dataset series. At the time of writing, the only grid readers capable of exposing their internal structure are image mosaic and netCDF.

                      "},{"location":"extensions/wcs20eo/#installing-the-wcs-20-eo-extension","title":"Installing the WCS 2.0 EO extension","text":"

                      The steps to install the EO extension as the same as most other extensions:

                      • Go to the website download page, locate the release used
                      • Look among the extensions for WCS 2.0 EO extension package to download: wcs2_0-eo
                      • Stop GeoServer (or the web container hosting it)
                      • Unpack the contents of the zip file in the geoserver WEB-INF/lib folder
                      • Restart GeoServer
                      "},{"location":"extensions/wcs20eo/#exposing-dataset-series","title":"Exposing dataset series","text":"

                      The first step to work with EO is to go into the WCS service panel and enable the EO extensions:

                      Enabling the WCS 2.0 EO extensions

                      The second step is finding and activating the EO extensions for a suitable grid layer, which needs to be one with time dimension support and ability to describe its inner structure. At the time of writing, this means a image mosaic with time support or a netCDF data layer with time dimension. Once the layer is located, the EO extensions for it can be enabled by ticking a checkbox in the publishing tab:

                      Exposing a layer as a dataset

                      Once that is done the capabilities document (e.g. http://localhost:8080/geoserver/ows?service=WCS&version=2.0.1&request=GetCapabilities for WCS 2.0 will contain an indication that a coverage set is present:

                      <wcs:Extension>\n  <wcseo:DatasetSeriesSummary>\n    <ows:WGS84BoundingBox>\n      <ows:LowerCorner>0.2372206885127698 40.562080748421806</ows:LowerCorner>\n      <ows:UpperCorner>14.592757149389236 44.55808294568743</ows:UpperCorner>\n    </ows:WGS84BoundingBox>\n    <wcseo:DatasetSeriesId>nurc__watertemp_dss</wcseo:DatasetSeriesId>\n    <gml:TimePeriod gml:id=\"nurc__watertemp_dss__timeperiod\">\n      <gml:beginPosition>2008-10-31T00:00:00.000Z</gml:beginPosition>\n      <gml:endPosition>2008-11-01T00:00:00.000Z</gml:endPosition>\n   </gml:TimePeriod>\n  </wcseo:DatasetSeriesSummary>\n</wcs:Extension>\n

                      And issuing a DescribeEOCoverageSet (e.g. http://localhost:8080/geoserver/ows?service=WCS&version=2.0.1&request=DescribeEOCoverageSet&eoId=nurc__watertemp_dss) on it will return the following:

                      <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<wcseo:EOCoverageSetDescription xmlns:eop=\"http://www.opengis.net/eop/2.0\" xmlns:gml=\"http://www.opengis.net/gml/3.2\" xmlns:wcsgs=\"http://www.geoserver.org/wcsgs/2.0\" xmlns:gmlcov=\"http://www.opengis.net/gmlcov/1.0\" xmlns:om=\"http://www.opengis.net/om/2.0\" xmlns:swe=\"http://www.opengis.net/swe/2.0\" xmlns:wcs=\"http://www.opengis.net/wcs/2.0\" xmlns:wcseo=\"http://www.opengis.net/wcseo/1.0\" xmlns:xlink=\"http://www.w3.org/1999/xlink\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" numberMatched=\"4\" numberReturned=\"4\" xsi:schemaLocation=\"http://www.opengis.net/wcseo/1.0 http://localhost:8080/geoserver/schemas/wcseo/1.0/wcsEOAll.xsd\">\n  <wcs:CoverageDescriptions>\n    <wcs:CoverageDescription gml:id=\"nurc__watertemp_granule_watertemp.1\">\n      <gml:boundedBy>\n        <gml:EnvelopeWithTimePeriod srsName=\"http://www.opengis.net/def/crs/EPSG/0/4326\" axisLabels=\"Lat Long time\" uomLabels=\"Deg Deg s\" srsDimension=\"2\">\n          <gml:lowerCorner>40.562080748421806 0.23722068851276978</gml:lowerCorner>\n          <gml:upperCorner>44.55808294568743 14.592757149389236</gml:upperCorner>\n          <gml:beginPosition>2008-11-01T00:00:00.000Z</gml:beginPosition>\n          <gml:endPosition>2008-11-01T00:00:00.000Z</gml:endPosition>\n        </gml:EnvelopeWithTimePeriod>\n      </gml:boundedBy>\n      <wcs:CoverageId>nurc__watertemp_granule_watertemp.1</wcs:CoverageId>\n      <gml:coverageFunction>\n        <gml:GridFunction>\n          <gml:sequenceRule axisOrder=\"+2 +1\">Linear</gml:sequenceRule>\n          <gml:startPoint>0 0</gml:startPoint>\n        </gml:GridFunction>\n      </gml:coverageFunction>\n      <gmlcov:metadata>\n        <gmlcov:Extension>\n          <wcsgs:TimeDomain default=\"2008-11-01T00:00:00.000Z\">\n            <gml:TimeInstant gml:id=\"nurc__watertemp_granule_watertemp.1_td_0\">\n              <gml:timePosition>2008-11-01T00:00:00.000Z</gml:timePosition>\n            </gml:TimeInstant>\n          </wcsgs:TimeDomain>\n          <wcseo:EOMetadata>\n            <eop:EarthObservation gml:id=\"nurc__watertemp_metadata\">\n              <om:phenomenonTime>\n                <gml:TimePeriod gml:id=\"nurc__watertemp_tp\">\n                  <gml:beginPosition>2008-11-01T00:00:00.000Z</gml:beginPosition>\n                  <gml:endPosition>2008-11-01T00:00:00.000Z</gml:endPosition>\n                </gml:TimePeriod>\n              </om:phenomenonTime>\n              <om:resultTime>\n                <gml:TimeInstant gml:id=\"nurc__watertemp_rt\">\n                  <gml:timePosition>2008-11-01T00:00:00.000Z</gml:timePosition>\n                </gml:TimeInstant>\n              </om:resultTime>\n              <om:procedure/>\n              <om:observedProperty/>\n              <om:FeatureOfInterest>\n                <eop:Footprint gml:id=\"nurc__watertemp_fp\">\n                  <eop:multiExtentOf>\n                    <gml:MultiSurface gml:id=\"nurc__watertemp_ms\" srsName=\"http://www.opengis.net/def/crs/EPSG/0/4326\">\n                      <gml:surfaceMembers>\n                        <gml:Polygon gml:id=\"nurc__watertemp_msp\">\n                          <gml:exterior>\n                            <gml:LinearRing>\n                              <gml:posList>40.562080748421806 0.23722068851276978 40.562080748421806 14.592757149389236 44.55808294568743 14.592757149389236 44.55808294568743 0.23722068851276978 40.562080748421806 0.23722068851276978</gml:posList>\n                            </gml:LinearRing>\n                          </gml:exterior>\n                        </gml:Polygon>\n                      </gml:surfaceMembers>\n                    </gml:MultiSurface>\n                  </eop:multiExtentOf>\n                  <eop:centerOf>\n                    <gml:Point gml:id=\"nurc__watertemp_co\" srsName=\"http://www.opengis.net/def/crs/EPSG/0/4326\">\n                      <gml:pos>42.56008184705462 7.4149889189510025</gml:pos>\n                    </gml:Point>\n                  </eop:centerOf>\n                </eop:Footprint>\n              </om:FeatureOfInterest>\n              <eop:metaDataProperty>\n                <eop:EarthObservationMetaData>\n                  <eop:identifier>nurc__watertemp</eop:identifier>\n                  <eop:acquisitionType>NOMINAL</eop:acquisitionType>\n                  <eop:status>ARCHIVED</eop:status>\n                </eop:EarthObservationMetaData>\n              </eop:metaDataProperty>\n            </eop:EarthObservation>\n          </wcseo:EOMetadata>\n        </gmlcov:Extension>\n      </gmlcov:metadata>\n      <gml:domainSet>\n        <gml:RectifiedGrid gml:id=\"grid00__nurc__watertemp_granule_watertemp.1\" dimension=\"2\">\n          <gml:limits>\n            <gml:GridEnvelope>\n              <gml:low>0 0</gml:low>\n              <gml:high>24 24</gml:high>\n            </gml:GridEnvelope>\n          </gml:limits>\n          <gml:axisLabels>i j</gml:axisLabels>\n          <gml:origin>\n            <gml:Point gml:id=\"p00_nurc__watertemp_granule_watertemp.1\" srsName=\"http://www.opengis.net/def/crs/EPSG/0/4326\">\n              <gml:pos>44.47816290174212 0.5243314177302991</gml:pos>\n            </gml:Point>\n          </gml:origin>\n          <gml:offsetVector srsName=\"http://www.opengis.net/def/crs/EPSG/0/4326\">0.0 0.5742214584350587</gml:offsetVector>\n          <gml:offsetVector srsName=\"http://www.opengis.net/def/crs/EPSG/0/4326\">-0.159840087890625 0.0</gml:offsetVector>\n        </gml:RectifiedGrid>\n      </gml:domainSet>\n      <gmlcov:rangeType>\n        <swe:DataRecord>\n          <swe:field name=\"GRAY_INDEX\">\n            <swe:Quantity>\n              <swe:description>GRAY_INDEX</swe:description>\n              <swe:uom code=\"W.m-2.Sr-1\"/>\n              <swe:constraint>\n                <swe:AllowedValues>\n                  <swe:interval>-1.7976931348623157E308 1.7976931348623157E308</swe:interval>\n                </swe:AllowedValues>\n              </swe:constraint>\n            </swe:Quantity>\n          </swe:field>\n        </swe:DataRecord>\n      </gmlcov:rangeType>\n      <wcs:ServiceParameters>\n        <wcs:CoverageSubtype>RectifiedGridCoverage</wcs:CoverageSubtype>\n        <wcs:nativeFormat>image/tiff</wcs:nativeFormat>\n      </wcs:ServiceParameters>\n    </wcs:CoverageDescription>\n    <wcs:CoverageDescription gml:id=\"nurc__watertemp_granule_watertemp.2\">\n      <gml:boundedBy>\n        <gml:EnvelopeWithTimePeriod srsName=\"http://www.opengis.net/def/crs/EPSG/0/4326\" axisLabels=\"Lat Long time\" uomLabels=\"Deg Deg s\" srsDimension=\"2\">\n          <gml:lowerCorner>40.562080748421806 0.23722068851276978</gml:lowerCorner>\n          <gml:upperCorner>44.55808294568743 14.592757149389236</gml:upperCorner>\n          <gml:beginPosition>2008-11-01T00:00:00.000Z</gml:beginPosition>\n          <gml:endPosition>2008-11-01T00:00:00.000Z</gml:endPosition>\n        </gml:EnvelopeWithTimePeriod>\n      </gml:boundedBy>\n      <wcs:CoverageId>nurc__watertemp_granule_watertemp.2</wcs:CoverageId>\n      <gml:coverageFunction>\n        <gml:GridFunction>\n          <gml:sequenceRule axisOrder=\"+2 +1\">Linear</gml:sequenceRule>\n          <gml:startPoint>0 0</gml:startPoint>\n        </gml:GridFunction>\n      </gml:coverageFunction>\n      <gmlcov:metadata>\n        <gmlcov:Extension>\n          <wcsgs:TimeDomain default=\"2008-11-01T00:00:00.000Z\">\n            <gml:TimeInstant gml:id=\"nurc__watertemp_granule_watertemp.2_td_0\">\n              <gml:timePosition>2008-11-01T00:00:00.000Z</gml:timePosition>\n            </gml:TimeInstant>\n          </wcsgs:TimeDomain>\n          <wcseo:EOMetadata>\n            <eop:EarthObservation gml:id=\"nurc__watertemp_metadata\">\n              <om:phenomenonTime>\n                <gml:TimePeriod gml:id=\"nurc__watertemp_tp\">\n                  <gml:beginPosition>2008-11-01T00:00:00.000Z</gml:beginPosition>\n                  <gml:endPosition>2008-11-01T00:00:00.000Z</gml:endPosition>\n                </gml:TimePeriod>\n              </om:phenomenonTime>\n              <om:resultTime>\n                <gml:TimeInstant gml:id=\"nurc__watertemp_rt\">\n                  <gml:timePosition>2008-11-01T00:00:00.000Z</gml:timePosition>\n                </gml:TimeInstant>\n              </om:resultTime>\n              <om:procedure/>\n              <om:observedProperty/>\n              <om:FeatureOfInterest>\n                <eop:Footprint gml:id=\"nurc__watertemp_fp\">\n                  <eop:multiExtentOf>\n                    <gml:MultiSurface gml:id=\"nurc__watertemp_ms\" srsName=\"http://www.opengis.net/def/crs/EPSG/0/4326\">\n                      <gml:surfaceMembers>\n                        <gml:Polygon gml:id=\"nurc__watertemp_msp\">\n                          <gml:exterior>\n                            <gml:LinearRing>\n                              <gml:posList>40.562080748421806 0.23722068851276978 40.562080748421806 14.592757149389236 44.55808294568743 14.592757149389236 44.55808294568743 0.23722068851276978 40.562080748421806 0.23722068851276978</gml:posList>\n                            </gml:LinearRing>\n                          </gml:exterior>\n                        </gml:Polygon>\n                      </gml:surfaceMembers>\n                    </gml:MultiSurface>\n                  </eop:multiExtentOf>\n                  <eop:centerOf>\n                    <gml:Point gml:id=\"nurc__watertemp_co\" srsName=\"http://www.opengis.net/def/crs/EPSG/0/4326\">\n                      <gml:pos>42.56008184705462 7.4149889189510025</gml:pos>\n                    </gml:Point>\n                  </eop:centerOf>\n                </eop:Footprint>\n              </om:FeatureOfInterest>\n              <eop:metaDataProperty>\n                <eop:EarthObservationMetaData>\n                  <eop:identifier>nurc__watertemp</eop:identifier>\n                  <eop:acquisitionType>NOMINAL</eop:acquisitionType>\n                  <eop:status>ARCHIVED</eop:status>\n                </eop:EarthObservationMetaData>\n              </eop:metaDataProperty>\n            </eop:EarthObservation>\n          </wcseo:EOMetadata>\n        </gmlcov:Extension>\n      </gmlcov:metadata>\n      <gml:domainSet>\n        <gml:RectifiedGrid gml:id=\"grid00__nurc__watertemp_granule_watertemp.2\" dimension=\"2\">\n          <gml:limits>\n            <gml:GridEnvelope>\n              <gml:low>0 0</gml:low>\n              <gml:high>24 24</gml:high>\n            </gml:GridEnvelope>\n          </gml:limits>\n          <gml:axisLabels>i j</gml:axisLabels>\n          <gml:origin>\n            <gml:Point gml:id=\"p00_nurc__watertemp_granule_watertemp.2\" srsName=\"http://www.opengis.net/def/crs/EPSG/0/4326\">\n              <gml:pos>44.47816290174212 0.5243314177302991</gml:pos>\n            </gml:Point>\n          </gml:origin>\n          <gml:offsetVector srsName=\"http://www.opengis.net/def/crs/EPSG/0/4326\">0.0 0.5742214584350587</gml:offsetVector>\n          <gml:offsetVector srsName=\"http://www.opengis.net/def/crs/EPSG/0/4326\">-0.159840087890625 0.0</gml:offsetVector>\n        </gml:RectifiedGrid>\n      </gml:domainSet>\n      <gmlcov:rangeType>\n        <swe:DataRecord>\n          <swe:field name=\"GRAY_INDEX\">\n            <swe:Quantity>\n              <swe:description>GRAY_INDEX</swe:description>\n              <swe:uom code=\"W.m-2.Sr-1\"/>\n              <swe:constraint>\n                <swe:AllowedValues>\n                  <swe:interval>-1.7976931348623157E308 1.7976931348623157E308</swe:interval>\n                </swe:AllowedValues>\n              </swe:constraint>\n            </swe:Quantity>\n          </swe:field>\n        </swe:DataRecord>\n      </gmlcov:rangeType>\n      <wcs:ServiceParameters>\n        <wcs:CoverageSubtype>RectifiedGridCoverage</wcs:CoverageSubtype>\n        <wcs:nativeFormat>image/tiff</wcs:nativeFormat>\n      </wcs:ServiceParameters>\n    </wcs:CoverageDescription>\n    <wcs:CoverageDescription gml:id=\"nurc__watertemp_granule_watertemp.3\">\n      <gml:boundedBy>\n        <gml:EnvelopeWithTimePeriod srsName=\"http://www.opengis.net/def/crs/EPSG/0/4326\" axisLabels=\"Lat Long time\" uomLabels=\"Deg Deg s\" srsDimension=\"2\">\n          <gml:lowerCorner>40.562080748421806 0.23722068851276978</gml:lowerCorner>\n          <gml:upperCorner>44.55808294568743 14.592757149389236</gml:upperCorner>\n          <gml:beginPosition>2008-10-31T00:00:00.000Z</gml:beginPosition>\n          <gml:endPosition>2008-10-31T00:00:00.000Z</gml:endPosition>\n        </gml:EnvelopeWithTimePeriod>\n      </gml:boundedBy>\n      <wcs:CoverageId>nurc__watertemp_granule_watertemp.3</wcs:CoverageId>\n      <gml:coverageFunction>\n        <gml:GridFunction>\n          <gml:sequenceRule axisOrder=\"+2 +1\">Linear</gml:sequenceRule>\n          <gml:startPoint>0 0</gml:startPoint>\n        </gml:GridFunction>\n      </gml:coverageFunction>\n      <gmlcov:metadata>\n        <gmlcov:Extension>\n          <wcsgs:TimeDomain default=\"2008-10-31T00:00:00.000Z\">\n            <gml:TimeInstant gml:id=\"nurc__watertemp_granule_watertemp.3_td_0\">\n              <gml:timePosition>2008-10-31T00:00:00.000Z</gml:timePosition>\n            </gml:TimeInstant>\n          </wcsgs:TimeDomain>\n          <wcseo:EOMetadata>\n            <eop:EarthObservation gml:id=\"nurc__watertemp_metadata\">\n              <om:phenomenonTime>\n                <gml:TimePeriod gml:id=\"nurc__watertemp_tp\">\n                  <gml:beginPosition>2008-10-31T00:00:00.000Z</gml:beginPosition>\n                  <gml:endPosition>2008-10-31T00:00:00.000Z</gml:endPosition>\n                </gml:TimePeriod>\n              </om:phenomenonTime>\n              <om:resultTime>\n                <gml:TimeInstant gml:id=\"nurc__watertemp_rt\">\n                  <gml:timePosition>2008-10-31T00:00:00.000Z</gml:timePosition>\n                </gml:TimeInstant>\n              </om:resultTime>\n              <om:procedure/>\n              <om:observedProperty/>\n              <om:FeatureOfInterest>\n                <eop:Footprint gml:id=\"nurc__watertemp_fp\">\n                  <eop:multiExtentOf>\n                    <gml:MultiSurface gml:id=\"nurc__watertemp_ms\" srsName=\"http://www.opengis.net/def/crs/EPSG/0/4326\">\n                      <gml:surfaceMembers>\n                        <gml:Polygon gml:id=\"nurc__watertemp_msp\">\n                          <gml:exterior>\n                            <gml:LinearRing>\n                              <gml:posList>40.562080748421806 0.23722068851276978 40.562080748421806 14.592757149389236 44.55808294568743 14.592757149389236 44.55808294568743 0.23722068851276978 40.562080748421806 0.23722068851276978</gml:posList>\n                            </gml:LinearRing>\n                          </gml:exterior>\n                        </gml:Polygon>\n                      </gml:surfaceMembers>\n                    </gml:MultiSurface>\n                  </eop:multiExtentOf>\n                  <eop:centerOf>\n                    <gml:Point gml:id=\"nurc__watertemp_co\" srsName=\"http://www.opengis.net/def/crs/EPSG/0/4326\">\n                      <gml:pos>42.56008184705462 7.4149889189510025</gml:pos>\n                    </gml:Point>\n                  </eop:centerOf>\n                </eop:Footprint>\n              </om:FeatureOfInterest>\n              <eop:metaDataProperty>\n                <eop:EarthObservationMetaData>\n                  <eop:identifier>nurc__watertemp</eop:identifier>\n                  <eop:acquisitionType>NOMINAL</eop:acquisitionType>\n                  <eop:status>ARCHIVED</eop:status>\n                </eop:EarthObservationMetaData>\n              </eop:metaDataProperty>\n            </eop:EarthObservation>\n          </wcseo:EOMetadata>\n        </gmlcov:Extension>\n      </gmlcov:metadata>\n      <gml:domainSet>\n        <gml:RectifiedGrid gml:id=\"grid00__nurc__watertemp_granule_watertemp.3\" dimension=\"2\">\n          <gml:limits>\n            <gml:GridEnvelope>\n              <gml:low>0 0</gml:low>\n              <gml:high>24 24</gml:high>\n            </gml:GridEnvelope>\n          </gml:limits>\n          <gml:axisLabels>i j</gml:axisLabels>\n          <gml:origin>\n            <gml:Point gml:id=\"p00_nurc__watertemp_granule_watertemp.3\" srsName=\"http://www.opengis.net/def/crs/EPSG/0/4326\">\n              <gml:pos>44.47816290174212 0.5243314177302991</gml:pos>\n            </gml:Point>\n          </gml:origin>\n          <gml:offsetVector srsName=\"http://www.opengis.net/def/crs/EPSG/0/4326\">0.0 0.5742214584350587</gml:offsetVector>\n          <gml:offsetVector srsName=\"http://www.opengis.net/def/crs/EPSG/0/4326\">-0.159840087890625 0.0</gml:offsetVector>\n        </gml:RectifiedGrid>\n      </gml:domainSet>\n      <gmlcov:rangeType>\n        <swe:DataRecord>\n          <swe:field name=\"GRAY_INDEX\">\n            <swe:Quantity>\n              <swe:description>GRAY_INDEX</swe:description>\n              <swe:uom code=\"W.m-2.Sr-1\"/>\n              <swe:constraint>\n                <swe:AllowedValues>\n                  <swe:interval>-1.7976931348623157E308 1.7976931348623157E308</swe:interval>\n                </swe:AllowedValues>\n              </swe:constraint>\n            </swe:Quantity>\n          </swe:field>\n        </swe:DataRecord>\n      </gmlcov:rangeType>\n      <wcs:ServiceParameters>\n        <wcs:CoverageSubtype>RectifiedGridCoverage</wcs:CoverageSubtype>\n        <wcs:nativeFormat>image/tiff</wcs:nativeFormat>\n      </wcs:ServiceParameters>\n    </wcs:CoverageDescription>\n    <wcs:CoverageDescription gml:id=\"nurc__watertemp_granule_watertemp.4\">\n      <gml:boundedBy>\n        <gml:EnvelopeWithTimePeriod srsName=\"http://www.opengis.net/def/crs/EPSG/0/4326\" axisLabels=\"Lat Long time\" uomLabels=\"Deg Deg s\" srsDimension=\"2\">\n          <gml:lowerCorner>40.562080748421806 0.23722068851276978</gml:lowerCorner>\n          <gml:upperCorner>44.55808294568743 14.592757149389236</gml:upperCorner>\n          <gml:beginPosition>2008-10-31T00:00:00.000Z</gml:beginPosition>\n          <gml:endPosition>2008-10-31T00:00:00.000Z</gml:endPosition>\n        </gml:EnvelopeWithTimePeriod>\n      </gml:boundedBy>\n      <wcs:CoverageId>nurc__watertemp_granule_watertemp.4</wcs:CoverageId>\n      <gml:coverageFunction>\n        <gml:GridFunction>\n          <gml:sequenceRule axisOrder=\"+2 +1\">Linear</gml:sequenceRule>\n          <gml:startPoint>0 0</gml:startPoint>\n        </gml:GridFunction>\n      </gml:coverageFunction>\n      <gmlcov:metadata>\n        <gmlcov:Extension>\n          <wcsgs:TimeDomain default=\"2008-10-31T00:00:00.000Z\">\n            <gml:TimeInstant gml:id=\"nurc__watertemp_granule_watertemp.4_td_0\">\n              <gml:timePosition>2008-10-31T00:00:00.000Z</gml:timePosition>\n            </gml:TimeInstant>\n          </wcsgs:TimeDomain>\n          <wcseo:EOMetadata>\n            <eop:EarthObservation gml:id=\"nurc__watertemp_metadata\">\n              <om:phenomenonTime>\n                <gml:TimePeriod gml:id=\"nurc__watertemp_tp\">\n                  <gml:beginPosition>2008-10-31T00:00:00.000Z</gml:beginPosition>\n                  <gml:endPosition>2008-10-31T00:00:00.000Z</gml:endPosition>\n                </gml:TimePeriod>\n              </om:phenomenonTime>\n              <om:resultTime>\n                <gml:TimeInstant gml:id=\"nurc__watertemp_rt\">\n                  <gml:timePosition>2008-10-31T00:00:00.000Z</gml:timePosition>\n                </gml:TimeInstant>\n              </om:resultTime>\n              <om:procedure/>\n              <om:observedProperty/>\n              <om:FeatureOfInterest>\n                <eop:Footprint gml:id=\"nurc__watertemp_fp\">\n                  <eop:multiExtentOf>\n                    <gml:MultiSurface gml:id=\"nurc__watertemp_ms\" srsName=\"http://www.opengis.net/def/crs/EPSG/0/4326\">\n                      <gml:surfaceMembers>\n                        <gml:Polygon gml:id=\"nurc__watertemp_msp\">\n                          <gml:exterior>\n                            <gml:LinearRing>\n                              <gml:posList>40.562080748421806 0.23722068851276978 40.562080748421806 14.592757149389236 44.55808294568743 14.592757149389236 44.55808294568743 0.23722068851276978 40.562080748421806 0.23722068851276978</gml:posList>\n                            </gml:LinearRing>\n                          </gml:exterior>\n                        </gml:Polygon>\n                      </gml:surfaceMembers>\n                    </gml:MultiSurface>\n                  </eop:multiExtentOf>\n                  <eop:centerOf>\n                    <gml:Point gml:id=\"nurc__watertemp_co\" srsName=\"http://www.opengis.net/def/crs/EPSG/0/4326\">\n                      <gml:pos>42.56008184705462 7.4149889189510025</gml:pos>\n                    </gml:Point>\n                  </eop:centerOf>\n                </eop:Footprint>\n              </om:FeatureOfInterest>\n              <eop:metaDataProperty>\n                <eop:EarthObservationMetaData>\n                  <eop:identifier>nurc__watertemp</eop:identifier>\n                  <eop:acquisitionType>NOMINAL</eop:acquisitionType>\n                  <eop:status>ARCHIVED</eop:status>\n                </eop:EarthObservationMetaData>\n              </eop:metaDataProperty>\n            </eop:EarthObservation>\n          </wcseo:EOMetadata>\n        </gmlcov:Extension>\n      </gmlcov:metadata>\n      <gml:domainSet>\n        <gml:RectifiedGrid gml:id=\"grid00__nurc__watertemp_granule_watertemp.4\" dimension=\"2\">\n          <gml:limits>\n            <gml:GridEnvelope>\n              <gml:low>0 0</gml:low>\n              <gml:high>24 24</gml:high>\n            </gml:GridEnvelope>\n          </gml:limits>\n          <gml:axisLabels>i j</gml:axisLabels>\n          <gml:origin>\n            <gml:Point gml:id=\"p00_nurc__watertemp_granule_watertemp.4\" srsName=\"http://www.opengis.net/def/crs/EPSG/0/4326\">\n              <gml:pos>44.47816290174212 0.5243314177302991</gml:pos>\n            </gml:Point>\n          </gml:origin>\n          <gml:offsetVector srsName=\"http://www.opengis.net/def/crs/EPSG/0/4326\">0.0 0.5742214584350587</gml:offsetVector>\n          <gml:offsetVector srsName=\"http://www.opengis.net/def/crs/EPSG/0/4326\">-0.159840087890625 0.0</gml:offsetVector>\n        </gml:RectifiedGrid>\n      </gml:domainSet>\n      <gmlcov:rangeType>\n        <swe:DataRecord>\n          <swe:field name=\"GRAY_INDEX\">\n            <swe:Quantity>\n              <swe:description>GRAY_INDEX</swe:description>\n              <swe:uom code=\"W.m-2.Sr-1\"/>\n              <swe:constraint>\n                <swe:AllowedValues>\n                  <swe:interval>-1.7976931348623157E308 1.7976931348623157E308</swe:interval>\n                </swe:AllowedValues>\n              </swe:constraint>\n            </swe:Quantity>\n          </swe:field>\n        </swe:DataRecord>\n      </gmlcov:rangeType>\n      <wcs:ServiceParameters>\n        <wcs:CoverageSubtype>RectifiedGridCoverage</wcs:CoverageSubtype>\n        <wcs:nativeFormat>image/tiff</wcs:nativeFormat>\n      </wcs:ServiceParameters>\n    </wcs:CoverageDescription>\n  </wcs:CoverageDescriptions>\n  <wcseo:DatasetSeriesDescriptions>\n    <wcseo:DatasetSeriesDescription gml:id=\"nurc__watertemp_dss\">\n      <gml:boundedBy>\n        <gml:Envelope srsName=\"http://www.opengis.net/def/crs/EPSG/0/4326\" axisLabels=\"Lat Long\" uomLabels=\"Deg Deg\" srsDimension=\"2\">\n          <gml:lowerCorner>40.562080748421806 0.23722068851276978</gml:lowerCorner>\n          <gml:upperCorner>44.55808294568743 14.592757149389236</gml:upperCorner>\n        </gml:Envelope>\n      </gml:boundedBy>\n      <wcseo:DatasetSeriesId>nurc__watertemp_dss</wcseo:DatasetSeriesId>\n      <gml:TimePeriod gml:id=\"nurc__watertemp_dss_timeperiod\">\n        <gml:beginPosition>2008-10-31T00:00:00.000Z</gml:beginPosition>\n        <gml:endPosition>2008-11-01T00:00:00.000Z</gml:endPosition>\n      </gml:TimePeriod>\n    </wcseo:DatasetSeriesDescription>\n  </wcseo:DatasetSeriesDescriptions>\n</wcseo:EOCoverageSetDescription>\n

                      Any of the inner coverages can be then retrieved via a standard GetCoverage, even if it's not directly part of the capabilities document, for example, to retrieve the first granule in the watertemp layer the request would be:

                      http://localhost:8080/geoserver/ows?service=WCS&version=2.0.1&request=GetCoverage&coverageId=nurc__watertemp_granule_watertemp.1\n
                      "},{"location":"extensions/wmts-multidimensional/","title":"WMTS Multidimensional","text":"

                      This module implements the WMTS multidimensional domain discovery extensions as proposed in this document. It is highly recommended to read the document linked above for a better understanding of the implemented multidimensional domain discovery extensions.

                      • Installing the WMTS multidimensional extension
                      • WMTS Multidimensional usage
                      • WMTS Multidimensional performance
                      "},{"location":"extensions/wmts-multidimensional/install/","title":"Installing the WMTS multidimensional extension","text":"

                      The WMS multidimensional extension is listed among the other extension downloads on the GeoServer download page.

                      The installation process is similar to other GeoServer extensions:

                      1. Download the wmts-multi-dimensional

                        Verify that the version number in the filename corresponds to the version of GeoServer you are running (for example 2.24.2 above).

                      2. Extract the contents of the archive into the WEB-INF/lib directory in GeoServer. Make sure you do not create any sub-directories during the extraction process.

                      3. Restart GeoServer.

                      If installation was successful, the WTMS capabilities document will contain the extra requests provided by the module, e.g.:

                      <ows:Operation name=\"DescribeDomains\">\n  <ows:DCP>\n    <ows:HTTP>\n      <ows:Get xlink:href=\"http://localhost:8080/geoserver/gwc/service/wmts?\">\n        <ows:Constraint name=\"GetEncoding\">\n          <ows:AllowedValues>\n            <ows:Value>KVP</ows:Value>\n          </ows:AllowedValues>\n        </ows:Constraint>\n      </ows:Get>\n    </ows:HTTP>\n  </ows:DCP>\n</ows:Operation>\n<ows:Operation name=\"GetDomainValues\">\n  <ows:DCP>\n    <ows:HTTP>\n      <ows:Get xlink:href=\"http://localhost:8080/geoserver/gwc/service/wmts?\">\n        <ows:Constraint name=\"GetEncoding\">\n          <ows:AllowedValues>\n            <ows:Value>KVP</ows:Value>\n          </ows:AllowedValues>\n        </ows:Constraint>\n      </ows:Get>\n    </ows:HTTP>\n  </ows:DCP>\n</ows:Operation>\n

                      A simple DescribeDomains request can be used to test if the module was correctly installed, the request can be made against any layer known by the WMTS service. For example, using the demo layer tiger:poly_landmarks shipped with GeoServer:

                      http://localhost:8080/geoserver/gwc/service/wmts?REQUEST=DescribeDomains&Version=1.0.0&Layer=tiger:poly_landmarks&TileMatrixSet=EPSG:4326\n

                      The result should be similar to the following, this layer doesn't have any domains:

                      <?xml version=\"1.0\" encoding=\"UTF-8\"?><Domains xmlns=\"http://demo.geo-solutions.it/share/wmts-multidim/wmts_multi_dimensional.xsd\" xmlns:ows=\"http://www.opengis.net/ows/1.1\">\n  <SpaceDomain>\n    <BoundingBox CRS=\"EPSG:4326\" minx=\"0.0\" miny=\"0.0\" maxx=\"-1.0\" maxy=\"-1.0\"/>\n  </SpaceDomain>\n</Domains>\n

                      If the module is not correctly installed the result will be an exception saying that this operation is not available:

                      <ExceptionReport version=\"1.1.0\" xmlns=\"http://www.opengis.net/ows/1.1\"\n  xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\"\n  xsi:schemaLocation=\"http://www.opengis.net/ows/1.1 http://geowebcache.org/schema/ows/1.1.0/owsExceptionReport.xsd\">\n  <Exception exceptionCode=\"OperationNotSupported\" locator=\"request\">\n    <ExceptionText>describedomains is not implemented</ExceptionText>\n  </Exception>\n</ExceptionReport>\n
                      "},{"location":"extensions/wmts-multidimensional/performance/","title":"WMTS Multidimensional performance","text":"

                      The multi-dimensional extension is designed to get quick summary responses, either when providing the full dimensions descriptions, or drilling into a particular sub-context, e.g., finding the times available in a particular bounding box.

                      The extension is often used to drive time sliders and visual tools to quickly drill down into a large multi-dimensional data set: as such, it's important that response times keep up with the user interactive usage.

                      For it to perform well, the typical configurations for relational databases are, in order of increasing complexity:

                      • Indexing all dimensions involved (geometry, time, elevation, and so on).
                      • Clustering the table on the dimensions which are the typical main UI driving factor (e.g. PostgreSQL one-off clustering, Oracle index organized tables).
                      • Partition the table based on the same dimension (e.g., PostgreSQL table partitioning).
                      • Create a summary table and use it for queries instead of the original one. The next section describes this approach.
                      "},{"location":"extensions/wmts-multidimensional/performance/#sidecar-summary-tables-for-vector-data","title":"Sidecar summary tables for vector data","text":"

                      The multidimensional module can be configured to use a sidecar summary table, that will be queried in place of the original table, for any domain extraction purpose:

                      Setting up a sidecar table.

                      Conditions for the sidecar table to work:

                      • Must contain all the same dimension columns as in the primary table, with same name and type.
                      • Must have a significantly smaller number of records (meaning, the primary table has lots of duplicate dimension values).
                      • May have reduced resolution in some dimension, if it's possible to accept reduced accuracy in the domain reports.

                      Querying the sidecar table will bypass all of the main table configurations and security, including:

                      • Property mapping (renaming, type modification, synthetic properties based on expression).
                      • CQL filtering defined in the layer configuration.
                      • Any security restriction (the layer must be public).

                      In summary, the sidecar table is useful for vector layers that are:

                      • Public.
                      • Very large, with significant repetition of dimension values.
                      • Read from the original table without any filtering or mapping.

                      While the documentation above refers to relational databases, it's also possible to use sidecar layers that come from the same data store. For example, given a directory of shapefiles, it would be possible to create a summary shapefile with a summary of a larger shapefile, and use it as the query target in its place.

                      "},{"location":"extensions/wmts-multidimensional/usage/","title":"WMTS Multidimensional usage","text":"

                      All described operations including is optional parameters and other extensions were implemented, only the REST interfaces for the domain discovery operations were not implemented.

                      The GetFeature operation only supports the profile GML 3.1 as feature info format (\"application/gml+xml; version=3.1\") and the GetHistogram operation only supports text/xml as output format.

                      This module support well defined dimensions like elevation and time, but also custom dimensions.

                      "},{"location":"extensions/wmts-multidimensional/usage/#getcapabilities","title":"GetCapabilities","text":"

                      The default behavior of WMTS is to list in the capabilities document all the values available in a certain dimension, something like this:

                      <Dimension>\n  <ows:Identifier>elevation</ows:Identifier>\n  <Default>0.0</Default>\n  <Value>0.0</Value>\n  <Value>200.0</Value>\n  <Value>400.0</Value>\n  <Value>600.0</Value>\n  <Value>800.0</Value>\n  <Value>1000.0</Value>\n  <Value>1200.0</Value>\n  <Value>1400.0</Value>\n  <Value>1600.0</Value>\n  <Value>1800.0</Value>\n  <Value>2000.0</Value>\n  <Value>3000.0</Value>\n  <Value>4000.0</Value>\n  <Value>5000.0</Value>\n  <Value>6000.0</Value>\n  <Value>7000.0</Value>\n  <Value>8000.0</Value>\n  <Value>9000.0</Value>\n</Dimension>\n

                      This module will instead take into account the presentation mode selected by the user:

                      Configuration of a layer dimensions.

                      With the presentation mode select to Continuous interval or Resolution and interval we will instead see something like this:

                      <Dimension>\n  <ows:Identifier>elevation</ows:Identifier>\n  <Default>0.0</Default>\n  <Value>0.0--9000.0</Value>\n</Dimension>\n

                      Descriptions for the new introduced operations and associated formats will also be added to the capabilities document.

                      "},{"location":"extensions/wmts-multidimensional/usage/#operations","title":"Operations","text":"

                      This module adds three new operations to the WMTS service that are described in detail in this document:

                      Operation Description

                      DescribeDomains Describes all the dimension domains in a compact document, along with the restricted bounding box of the two dimensional space intercepted by the request.

                      GetDomainValues Allows to page through domain values (supplements DescribeDomains in case the domain has too many values, and the client still wants to get all of them, one page at a time)

                      GetHistogram Given a scattered domain description and an interval, this operation divides the interval in regular buckets, and provides an item count for each bucket.

                      GetFeature Enumerate the actual dimension possible values combinations, returns a list of features along with dimension values using the same formats as the feature info operation (\"application/gml+xml; version=3.1\").

                      Note that currently there is no restful implementations of this operations.

                      "},{"location":"extensions/wmts-multidimensional/usage/#describedomains","title":"DescribeDomains","text":"

                      This operation is useful to understand which domains are available in our layer dimensions and how they relate to each other. The parameters available for this operation are:

                      Name Mandatory Description

                      Service=WMTS Yes Service type identifier

                      Request=DescribeDomains Yes Operation name

                      Version=1.0.0 Yes Standard and schema version for this operation

                      Layer Yes Layer identifier

                      TileMatrixSet Yes Tile matrix set identifier

                      bbox=minx,miny,maxx,maxy No Bounding box corners (lower left, upper right) in CRS units

                      DimensionIdentifier No At most one per dimension, a range described as min/max, restricting the domain of this dimension

                      Domains No A comma separated list of domain names to be returned, in case only a subset is required. The space domain is identified by \"bbox\".

                      ExpandLimit No A numerical value, greater or equal to zero. If the number of unique domain values is below ExpandLimit then the domain with be represented in full, as a comma separated list of values, otherwise in compact form, as start--end. The server assumes a built-in limit of 200 in case not specified, and allows client to specify a value up to 10000, values can be tuned via the user interface, in the WMTS panel (server defaults) and on a layer by layer basis.

                      Configuration domain expansion limits.

                      The bbox parameter allows the client to restrict the DescribeDomains operation to a certain spatial area, by default the layer extent will be used.

                      The DimensionIdentifier parameter can be used to restrict the domain values of a certain dimension, this is useful to answer questions like which elevations values are available in a specific day.

                      A simple DescribeDomains request will look like this:

                      http://localhost:8080/geoserver/gwc/service/wmts?REQUEST=DescribeDomains&Version=1.0.0&Layer=some_layer&TileMatrixSet=EPSG:4326\n

                      and the result will be similar to this:

                      <Domains xmlns=\"http://demo.geo-solutions.it/share/wmts-multidim/wmts_multi_dimensional.xsd\" xmlns:ows=\"http://www.opengis.net/ows/1.1\">\n  <SpaceDomain>\n    <BoundingBox CRS=\"EPSG:4326\" \n     maxx=\"179.875\" maxy=\"89.9375\" minx=\"-180.125\" miny=\"-90.125\"/>\n  </SpaceDomain>\n  <DimensionDomain>\n    <ows:Identifier>elevation</ows:Identifier>\n    <Domain>0.0,200.0,400.0,600.0,800.0,1000.0</Domain>\n    <Size>6</Size>\n  </DimensionDomain>\n  <DimensionDomain>\n    <ows:Identifier>REFERENCE_TIME</ows:Identifier>\n    <Domain>2016-02-23T00:00:00.000Z,2016-02-24T00:00:00.000Z</Domain>\n    <Size>2</Size>\n  </DimensionDomain>\n  <DimensionDomain>\n    <ows:Identifier>time</ows:Identifier>\n    <Domain>2016-02-23T03:00:00.000Z,2016-02-23T06:00:00.000Z</Domain>\n    <Size>2</Size>\n  </DimensionDomain>\n</Domains>\n

                      Note that if an end attribute has been defined in the layer dimension configuration page, the result will show ranges in place of single values. The result in this case will look like the following:

                      <Domains xmlns=\"http://demo.geo-solutions.it/share/wmts-multidim/wmts_multi_dimensional.xsd\" xmlns:ows=\"http://www.opengis.net/ows/1.1\">\n  <SpaceDomain>\n    <BoundingBox CRS=\"EPSG:4326\" \n     maxx=\"179.875\" maxy=\"89.9375\" minx=\"-180.125\" miny=\"-90.125\"/>\n  </SpaceDomain>\n  <DimensionDomain>\n    <ows:Identifier>elevation</ows:Identifier>\n    <Domain>0.0/50.0,200.0/300.0,400.0/500.0</Domain>\n    <Size>6</Size>\n  </DimensionDomain>\n  <DimensionDomain>\n    <ows:Identifier>REFERENCE_TIME</ows:Identifier>\n    <Domain>2016-02-23T00:00:00.000Z/2016-02-23T23:00:00.000Z,2016-02-24T00:00:00.000Z/2016-02-24T12:00:00.000Z</Domain>\n    <Size>2</Size>\n  </DimensionDomain>\n  <DimensionDomain>\n    <ows:Identifier>time</ows:Identifier>\n    <Domain>2016-02-23T03:00:00.000Z/2016-02-23T06:00:00.000Z,2016-02-23T06:00:00.000Z/2016-02-23T12:00:00.000Z</Domain>\n    <Size>2</Size>\n  </DimensionDomain>\n</Domains>\n

                      From the information above we can see that we have three dimensions time, elevation and REFERENCE_TIME and the respective domains values.

                      Now let's see how elevations relate to time dimension by asking which elevations under 500.0 meters are available at time 2016-02-23T03:00:00.000Z:

                      http://localhost:8080/geoserver/gwc/service/wmts?REQUEST=DescribeDomains&Version=1.0.0&Layer=some_layer&TileMatrixSet=EPSG:4326&elevation=0/500&time=2016-02-23T03:00:00.000Z\n

                      the result will be similar to this:

                      <Domains xmlns=\"http://demo.geo-solutions.it/share/wmts-multidim/wmts_multi_dimensional.xsd\" xmlns:ows=\"http://www.opengis.net/ows/1.1\">\n  <SpaceDomain>\n    <BoundingBox CRS=\"EPSG:4326\" \n     maxx=\"179.875\" maxy=\"89.9375\" minx=\"-180.125\" miny=\"-90.125\"/>\n  </SpaceDomain>\n  <DimensionDomain>\n    <ows:Identifier>elevation</ows:Identifier>\n    <Domain>200.0</Domain>\n    <Size>1</Size>\n  </DimensionDomain>\n  <DimensionDomain>\n    <ows:Identifier>REFERENCE_TIME</ows:Identifier>\n    <Domain>2016-02-23T00:00:00.000Z</Domain>\n    <Size>1</Size>\n  </DimensionDomain>\n  <DimensionDomain>\n    <ows:Identifier>time</ows:Identifier>\n    <Domain>2016-02-23T03:00:00.000Z</Domain>\n    <Size>1</Size>\n  </DimensionDomain>\n</Domains>\n

                      So for time 2016-02-23T03:00:00.000Z there is only values measured at 200.0 meters.

                      In case only the space domain is of interest, the following request will do:

                      http://localhost:8080/geoserver/gwc/service/wmts?REQUEST=DescribeDomains&Version=1.0.0&Layer=some_layer&TileMatrixSet=EPSG:4326&elevation=0/500&time=2016-02-23T03:00:00.000Z&domains=bbox\n

                      and the result will be similar to this:

                      <Domains xmlns=\"http://demo.geo-solutions.it/share/wmts-multidim/wmts_multi_dimensional.xsd\" xmlns:ows=\"http://www.opengis.net/ows/1.1\">\n  <SpaceDomain>\n    <BoundingBox CRS=\"EPSG:4326\" \n     maxx=\"179.875\" maxy=\"89.9375\" minx=\"-180.125\" miny=\"-90.125\"/>\n  </SpaceDomain>\n</Domains>\n
                      "},{"location":"extensions/wmts-multidimensional/usage/#getdomainvalues","title":"GetDomainValues","text":"

                      This operation is useful to page through the values of a given domain, in case the \"multidimensional\" area of interest is too large for DescribeDomain to return them in a single shot.

                      Name Mandatory Description

                      Service=WMTS Yes Service type identifier

                      Request=GetDomainValues Yes Operation name

                      Version=1.0.0 Yes Standard and schema version for this operation

                      Layer Yes Layer identifier

                      bbox=minx,miny,maxx,maxy No Bounding box corners (lower left, upper right) in CRS units

                      DimensionIdentifier No At most one per dimension, a range described as min/max, restricting the domain of this dimension

                      Domain Yes Name of the domain whose values will be returned (one cannot use \"bbox\", only single value dimensions can be enumerated by GetDomainValues, e.g., time, elevation).

                      FromValue No Sets the beginning of domain enumeration, for paging purposes. It's not included in the result

                      FromEnd No If equals to true specifies that the beginning of domain enumeration, set by the FromValue, should be applied to the end attribute. When set to true results will be sorted by end attribute.

                      Sort No Can be \"asc\" or \"desc\", determines if the enumeration is from low to high, or from high to low

                      Limit No Maximum number of values returned by this call. The server assumes a built-in limit of 1000 in case not specified, and allows client to specify a value up to 10000.

                      For example, let's say a \"elevation\" domain has values 1,2,3 and 5, and that we are paging through it by pages of 2 elements. The client will start without providing a \"fromValue\", and will then continue using the last value of the previous page as a reference:

                      http://localhost:8080/geoserver/gwc/service/wmts?request=GetDomainValues&Version=1.0.0&Layer=sampleLayer&domain=elevation&limit=2\n
                      <DomainValues xmlns=\"http://demo.geo-solutions.it/share/wmts-multidim/wmts_multi_dimensional.xsd\" xmlns:ows=\"http://www.opengis.net/ows/1.1\">\n  <ows:Identifier>elevation</ows:Identifier>\n  <Limit>2</Limit>\n  <Sort>asc</Sort>\n  <Domain>1.0,2.0</Domain>\n  <Size>2</Size>\n</DomainValues>\n
                      http://localhost:8080/geoserver/gwc/service/wmts?request=GetDomainValues&Version=1.0.0&Layer=sampleLayer&domain=elevation&limit=2&fromValue=2\n
                      <DomainValues xmlns=\"http://demo.geo-solutions.it/share/wmts-multidim/wmts_multi_dimensional.xsd\" xmlns:ows=\"http://www.opengis.net/ows/1.1\">\n  <ows:Identifier>elevation</ows:Identifier>\n  <Limit>2</Limit>\n  <Sort>asc</Sort>\n  <FromValue>2.0</FromValue>\n  <Domain>3.0,5.0</Domain>\n  <Size>2</Size>\n</DomainValues>\n
                      http://localhost:8080/geoserver/gwc/service/wmts?request=GetDomainValues&Version=1.0.0&Layer=sampleLayer&domain=elevation&limit=2&fromValue=5\n
                      <DomainValues xmlns=\"http://demo.geo-solutions.it/share/wmts-multidim/wmts_multi_dimensional.xsd\" xmlns:ows=\"http://www.opengis.net/ows/1.1\">\n  <ows:Identifier>elevation</ows:Identifier>\n  <Limit>2</Limit>\n  <Sort>asc</Sort>\n  <FromValue>5.0</FromValue>\n  <Domain></Domain>\n  <Size>0</Size>\n</DomainValues>\n

                      For elevations it might not be uncommon to iterate backwards, from the top-most elevation down to the lowest value. The interaction between client and server might then look as follows:

                      http://localhost:8080/geoserver/gwc/service/wmts?request=GetDomainValues&Version=1.0.0&Layer=sampleLayer&domain=elevation&limit=2&sort=desc\n
                      <DomainValues xmlns=\"http://demo.geo-solutions.it/share/wmts-multidim/wmts_multi_dimensional.xsd\" xmlns:ows=\"http://www.opengis.net/ows/1.1\">\n  <ows:Identifier>elevation</ows:Identifier>\n  <Limit>2</Limit>\n  <Sort>asc</Sort>\n  <Domain>5.0,3.0</Domain>\n  <Size>2</Size>\n</DomainValues>\n
                      http://localhost:8080/geoserver/gwc/service/wmts?request=GetDomainValues&Version=1.0.0&Layer=sampleLayer&domain=elevation&limit=2&fromValue=3&sort=desc\n
                      <DomainValues xmlns=\"http://demo.geo-solutions.it/share/wmts-multidim/wmts_multi_dimensional.xsd\" xmlns:ows=\"http://www.opengis.net/ows/1.1\">\n  <ows:Identifier>elevation</ows:Identifier>\n  <Limit>2</Limit>\n  <Sort>asc</Sort>\n  <FromValue>3.0</FromValue>\n  <Domain>2.0,1.0</Domain>\n  <Size>2</Size>\n</DomainValues>\n
                      http://localhost:8080/geoserver/gwc/service/wmts?request=GetDomainValues&Version=1.0.0&Layer=sampleLayer&domain=elevation&limit=2&fromValue=1&sort=desc\n
                      <DomainValues xmlns=\"http://demo.geo-solutions.it/share/wmts-multidim/wmts_multi_dimensional.xsd\" xmlns:ows=\"http://www.opengis.net/ows/1.1\">\n  <ows:Identifier>elevation</ows:Identifier>\n  <Limit>2</Limit>\n  <Sort>asc</Sort>\n  <FromValue>1.0</FromValue>\n  <Domain></Domain>\n  <Size>0</Size>\n</DomainValues>\n

                      Assume now that along with the values 1,2,3,5 we have end attribute values respectively equal to 5,3,4,6.

                      The following request:

                      http://localhost:8080/geoserver/gwc/service/wmts?request=GetDomainValues&Version=1.0.0&Layer=sampleLayer&domain=elevation&limit=2&fromValue=3.5&fromEnd=true\n

                      will return

                      <DomainValues xmlns=\"http://demo.geo-solutions.it/share/wmts-multidim/wmts_multi_dimensional.xsd\" xmlns:ows=\"http://www.opengis.net/ows/1.1\">\n  <ows:Identifier>elevation</ows:Identifier>\n  <Limit>2</Limit>\n  <Sort>asc</Sort>\n  <Domain>3.0/4.0,1.0/5.0,5.0/6.0</Domain>\n  <Size>2</Size>\n</DomainValues>\n

                      The paging approach might seem odd for those used to using \"limit\" and \"offset\". The main reason it's done this way it's performance, paging through unique values via limit and offset means that the data source has to compute and collect the unique values that are not needed (the ones in previous pages) in order to find the ones in the current page. With large domains (typical of time series) this quickly becomes too slow for interactive usage, as one moves forward in the domain.

                      By giving a starting point, the unneeded data points can be skipped via index and the distinct value computation can be performed only on the current page data, stopping it as soon as the desired number of results has been computed. With an index on the dimension being queries, this results in nearly constant response times, regardless of the page being requested.

                      "},{"location":"extensions/wmts-multidimensional/usage/#gethistogram","title":"GetHistogram","text":"

                      This operation can be used to provide information about the data distribution between the minimum and maximum values of a certain dimension.

                      The parameters available for this operation are:

                      Name Mandatory Description

                      Service=WMTS Yes Service type identifier

                      Request=GetHistogram Yes Operation name

                      Version=1.0.0 Yes Standard and schema version for this operation

                      Layer Yes Layer identifier

                      TileMatrixSet Yes Tile matrix set identifier

                      BBOX=minx,miny,maxx,maxy No Bounding box corners (lower left, upper right) in CRS units

                      DimensionIdentifier No At most one per dimension, a range described as min/max, restricting the domain of this dimension

                      Histogram Yes Name of the dimension for which the histogram will be computed

                      Resolution No Suggested size of the histogram bucket. Cannot be provided for enumerated dimensions, will use the period syntax for time (e.g. PT1H), a number for numeric dimensions, or auto to leave the decision to the server

                      Format No The desired output format, default is text/html.

                      The parameters common to the DescribeDomains operation work as already described above. Currently only the text/xml output format is supported.

                      The following example request the histogram for time dimension with a resolution of 8 hours restricting elevations between 500.0 and 1000.0 meters:

                      http://localhost:8080/geoserver/gwc/service/wmts?REQUEST=GetHistogram&Version=1.0.0&Layer=some_layer&TileMatrixSet=EPSG:4326&histogram=time&resolution=PT8H&elevation=500.0/1000.0\n

                      and the result will be similar to this:

                      <Histogram xmlns=\"http://demo.geo-solutions.it/share/wmts-multidim/wmts_multi_dimensional.xsd\" xmlns:ows=\"http://www.opengis.net/ows/1.1\">\n  <ows:Identifier>time</ows:Identifier>\n  <Domain>2016-02-23T00:00:00.000Z/2016-02-25T00:00:00.000Z/PT8H</Domain>\n  <Values>240,0,240,0,0,240</Values>\n</Histogram>\n

                      Looking at the result we can conclude that measurements between 500.0 and 1000.0 meters are typically done during the night.

                      The bucket matching is setup so that each one contains its first value, but not its last value (which is contained in the next bucket instead). This is important to understand the results. Say we have a dataset with regular elevations, from 0 to 100 with a step of 10, and the request calls for elevations between 0 and 20. Then the results will look something like follows:

                      <Histogram xmlns=\"http://demo.geo-solutions.it/share/wmts-multidim/wmts_multi_dimensional.xsd\" xmlns:ows=\"http://www.opengis.net/ows/1.1\">\n  <ows:Identifier>elevation</ows:Identifier>\n  <Domain>0/30/10</Domain>\n  <Values>5,3,8</Values>\n</Histogram>\n

                      That is, there values catch the intervals [0,10[, [10, 20[, and [20, 30[ (to have a bucket for the images/features having elevation exactly matching 20). This will happen only if an extreme value if found, the same request filtering on elevations between 0 and 15 will return this instead:

                      <Histogram xmlns=\"http://demo.geo-solutions.it/share/wmts-multidim/wmts_multi_dimensional.xsd\" xmlns:ows=\"http://www.opengis.net/ows/1.1\">\n  <ows:Identifier>elevation</ows:Identifier>\n  <Domain>0/20/10</Domain>\n  <Values>5,3</Values>\n</Histogram>\n

                      Note that if an end attribute is specified the bucket matching will be applied on ranges rather than on single values. In this case, buckets are filled by the intersection of ranges' values with bucket limits and not by containment. This is done in order to avoid some range values falling outside every bucket, but as a side effect, the same range can match more than one bucket.

                      "},{"location":"extensions/wmts-multidimensional/usage/#getfeature","title":"GetFeature","text":"

                      This operation is capable to enumerate the actual possible values combinations. The output of this operation is similar to the output of the WFS 2.0 GetFeature operation which is a list of features along with dimension values using the same formats as the feature info operation. This output can be used to draw the features on a map for example.

                      The parameters available for this operation are:

                      Name Mandatory Description

                      Service=WMTS Yes Service type identifier

                      Request=GetFeature Yes Operation name

                      Version=1.0.0 Yes Standard and schema version for this operation

                      Layer Yes Layer identifier

                      TileMatrixSet Yes Tile matrix set identifier

                      BBOX=minx,miny,maxx,maxy No Bounding box corners (lower left, upper right) in CRS units

                      DimensionIdentifier No At most one per dimension, a range described as min/max, restricting the domain of this dimension

                      Format Yes The desired output format

                      The parameters common to the DescribeDomains operation work as already described above. Currently only the application/gml+xml; version=3.1 output format is supported.

                      Using the same restrictions parameters we used for the second request used as an example for the DescribeDomains operation a GetFeature request will look like this:

                      http://localhost:8080/geoserver/gwc/service/wmts?REQUEST=GetFeature&Version=1.0.0&Layer=some_layer&TileMatrixSet=EPSG:4326&elevation=0/500&time=2016-02-23T03:00:00.000Z\n

                      and the result will be similar to this:

                      <?xml version=\"1.0\" encoding=\"UTF-8\"?><wmts:FeatureCollection xmlns:xs=\"http://www.w3.org/2001/XMLSchema\" xmlns:gml=\"http://www.opengis.net/gml\" xmlns:wmts=\"http://www.opengis.net/wmts/1.0\">\n  <wmts:feature gml:id=\"FID.1681\">\n    <wmts:footprint>\n      <gml:Polygon xmlns:xs=\"http://www.w3.org/2001/XMLSchema\" xmlns:gml=\"http://www.opengis.net/gml\" xmlns:sch=\"http://www.ascc.net/xml/schematron\" xmlns:xlink=\"http://www.w3.org/1999/xlink\" srsDimension=\"2\" srsName=\"http://www.opengis.net/gml/srs/epsg.xml#4326\">\n        <gml:exterior>\n          <gml:LinearRing srsDimension=\"2\">\n            <gml:posList>-180.125 -90.125 -180.125 89.875 179.875 89.875 179.875 -90.125 -180.125 -90.125</gml:posList>\n          </gml:LinearRing>\n        </gml:exterior>\n      </gml:Polygon>\n    </wmts:footprint>\n    <wmts:dimension name=\"elevation\">200.0</wmts:dimension>\n    <wmts:dimension name=\"time\">2016-02-23T03:00:00.000Z</wmts:dimension>\n    <wmts:dimension name=\"REFERENCE_TIME\">2016-02-23T00:00:00.000Z</wmts:dimension>\n  </wmts:feature>\n</wmts:FeatureCollection>\n

                      Note how this result correlate with the correspondent DescribeDomains operation result.

                      "},{"location":"extensions/wps-download/","title":"WPS Download plugin","text":"

                      WPS Download plugin provides some useful features for easily downloading: * Raster or Vector layer as zip files * Large maps as images * Time based animation The module also provides facilities to control the output file size.

                      "},{"location":"extensions/wps-download/#installing-the-wps-download-extension","title":"Installing the WPS Download extension","text":"

                      The WPS Download extension is listed among the other extension downloads on the GeoServer download page.

                      The installation process is similar to other GeoServer extensions:

                      1. From the website download page, locate your release, and download: wps-download

                        Verify that the version number in the filename corresponds to the version of GeoServer you are running (for example 2.24.2 above).

                      2. Extract the contents of the archive into the WEB-INF/lib directory in GeoServer. Make sure you do not create any sub-directories during the extraction process.

                      3. Restart GeoServer.

                      "},{"location":"extensions/wps-download/#module-description","title":"Module description","text":"

                      This module provides the following WPS process:

                      • gs:Download : can be used for downloading Raster and Vector Layers
                      • gs:DownloadEstimator : can be used for checking if the downloaded file does not exceeds the configured limits.
                      • gs:DownloadMap: allows to download a large map with the same composition found on the client side (eventually along with an asynchronous call)
                      • gs:DownloadAnimation: allows to download a map with the same composition found on the client side, with animation over a give set of times
                      "},{"location":"extensions/wps-download/#configuring-the-limits","title":"Configuring the limits","text":"

                      The user interface provides a way to configure the WPS download in the WPS administration page:

                      Where the available limits are:

                      • Maximum features : maximum number of features to download
                      • Raster size limits : maximum pixel size of the Raster to read (in square pixels, width by height)
                      • Write limits : maximum raw raster size in bytes (a limit of how much space can a raster take in memory). For a given raster, its raw size in bytes is calculated by multiplying pixel number (raster_width x raster_height) with the accumulated sum of each band's pixel sample_type size in bytes, for all bands
                      • Hard output limit : maximum file size to download (will be checked while writing the output, post compression)
                      • ZIP compresion level : compression level for the output zip file
                      • Maximum frames in animation : maximum number of frames allowed (if no limit, the maximum execution time limits will still apply and stop the process in case there are too many)

                      The configuration is stored in a download.properties file found in the root of the GeoServer data directory.

                      # Max #of features\nmaxFeatures=100000\n#8000 px X 8000 px\nrasterSizeLimits=64000000\n#8000 px X 8000 px X 3 bands X 1 byte per band = 192MB\nwriteLimits=192000000\n# 50 MB\nhardOutputLimit=52428800\n# STORE =0, BEST =8\ncompressionLevel=4\n# When set to 0 or below, no limit\nmaxAnimationFrames=1000\n

                      The file can also be manually modified while GeoServer is running, the file is under watch and gets reloaded on modification.

                      The configuration can also be edited via the REST API.

                      "},{"location":"extensions/wps-download/#the-processes-and-their-usage","title":"The processes and their usage","text":"

                      The following describes the various processes, separating raw downloads from rendered downloads:

                      • Raw data download processes
                      • Rendered map/animation download processes
                      "},{"location":"extensions/wps-download/mapAnimationDownload/","title":"Rendered map/animation download processes","text":"

                      These processes allow download large maps and animations.

                      "},{"location":"extensions/wps-download/mapAnimationDownload/#the-rendered-download-processes","title":"The rendered download processes","text":"

                      The map and animation downloads work off a set of common parameters:

                      • bbox : a geo-referenced bounding box, controlling both output area and desired projection
                      • decoration : the name of a decoration layout to be added on top of the map
                      • decorationEnvironment : a valid value for the env parameter used when painting the decoration. Used for dynamic decoration layouts<wms_dynamic_decorations>.
                      • time : a WMS time specification used to drive the selection of times across the layers in the map, and to control the frame generation in the animation
                      • width and height : size of the output map/animation (and in combination with bounding box, also controls the output map scale)
                      • layer: a list of layer specifications, from a client side point of view (thus, a layer can be composed of multiple server side layers). When dwn:DecorationName layer option is used, it allows to define a specific layout that will be used when decorations are applied to the layer. It allows to render more than one Legend on the resulting image, when having more than one Layer declared.
                      • headerheight : height size of a header space allocated at top of rendered map. It's an optional parameter, that forces to shrink the maps view height in order to avoid overlapping header over the maps. In combination with the use of layer specification options allows to group decorators at the top of resulting image.
                      "},{"location":"extensions/wps-download/mapAnimationDownload/#the-layer-specification","title":"The layer specification","text":"

                      A layer specification is a XML structure made of three parts:

                      • Name: a comma separated list of layer names (eventually just one)
                      • Capabilities: link to a capabilities document (optional, used when targetting remote WMS layers)
                      • Parameter (key, value): an extra parameter to be added in the WMS request represented by this layer (e.g., elevation, CQL_FILTER, env)
                      • Opacity: an optional parameter, ranging from 0 to 100, that controls the layer image level of translucency during the merge process. When not set the layer image is fully opaque. Note that this is seperate from the overall map transparent boolean parameter.

                      For example:

                      <wps:ComplexData xmlns:dwn=\"http://geoserver.org/wps/download\">\n  <dwn:Layer>\n    <dwn:Capabilities>http://demo.geo-solutions.it/geoserver/ows?service=wms&amp;version=1.1.1&amp;request=GetCapabilities</dwn:Name>\n    <dwn:Name>topp:states</dwn:Name>\n    <dwn:Parameter key=\"CQL_FILTER\"><![CDATA[PERSONS > 1000000]]></dwn:Parameter>\n    <dwn:Opacity>37</dwn:Opacity>\n  </dwn:Layer>\n</wps:ComplexData>\n
                      "},{"location":"extensions/wps-download/mapAnimationDownload/#decoration-layout","title":"Decoration Layout","text":"

                      The decoration parameter specifies the file name (without extension) of the layout to be used to decorate the map. The layout is a list of decorators that should draw on top of the requested image. The decorators draw on the image one after the other, so the order of the decorators in the layout file is important: the first decorator output will appear under the others.

                      Decorators are described in detail in the WMS Decorations section. It is also possible to use dynamic decoration layouts<wms_dynamic_decorations>, in this case the environment parameters for the decoration will be provided using dwn:Parameter, e.g.:

                      <dwn:Layer>\n  <dwn:Name>theLayer</dwn:Name>\n  <dwn:DecorationName>theDynamicDecoration</dwn:DecorationName>\n  <dwn:Parameter key=\"env\">sla:top,right;bg:#FF0000</dwn:Parameter>\n</dwn:Layer>\n
                      "},{"location":"extensions/wps-download/mapAnimationDownload/#map-download-process","title":"Map Download Process","text":"

                      In addition to the common parameters, the MapDownloadProcess sports an extra boolean parameter, transparent, which can be either true or false, determining if the output map has a transparent or a solid background (animation lacks this parameter, as videos need solid background). The transparent parameter defaults to false[^1].

                      Also, unlike animation, in the map download process the time parameter is optional.

                      The map download process uses the WMS machinery to produce the output, but it's not subject to the WMS service limits (width and height in this process can be limited using the WPS process security).

                      "},{"location":"extensions/wps-download/mapAnimationDownload/#sample-downloadmap-requests","title":"Sample DownloadMap requests","text":"

                      A download map issued against a set of local layers can look as follows:

                      <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<wps:Execute version=\"1.0.0\" service=\"WPS\"\n             xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xmlns=\"http://www.opengis.net/wps/1.0.0\"\n             xmlns:wfs=\"http://www.opengis.net/wfs\" xmlns:wps=\"http://www.opengis.net/wps/1.0.0\"\n             xmlns:ows=\"http://www.opengis.net/ows/1.1\" xmlns:gml=\"http://www.opengis.net/gml\"\n             xmlns:ogc=\"http://www.opengis.net/ogc\" xmlns:wcs=\"http://www.opengis.net/wcs/1.1.1\"\n             xmlns:xlink=\"http://www.w3.org/1999/xlink\"\n             xsi:schemaLocation=\"http://www.opengis.net/wps/1.0.0 http://schemas.opengis.net/wps/1.0.0/wpsAll.xsd\">\n  <ows:Identifier>gs:DownloadMap</ows:Identifier>\n  <wps:DataInputs>\n    <wps:Input>\n      <ows:Identifier>bbox</ows:Identifier>\n      <wps:Data>\n        <wps:BoundingBoxData crs=\"EPSG:4326\">\n          <ows:LowerCorner>0.237 40.562</ows:LowerCorner>\n          <ows:UpperCorner>14.593 44.55</ows:UpperCorner>\n        </wps:BoundingBoxData>\n      </wps:Data>\n    </wps:Input>\n    <wps:Input>\n      <ows:Identifier>time</ows:Identifier>\n      <wps:Data>\n        <wps:LiteralData>2008-10-31T00:00:00.000Z</wps:LiteralData>\n      </wps:Data>\n    </wps:Input>\n    <wps:Input>\n      <ows:Identifier>width</ows:Identifier>\n      <wps:Data>\n        <wps:LiteralData>200</wps:LiteralData>\n      </wps:Data>\n    </wps:Input>\n    <wps:Input>\n      <ows:Identifier>height</ows:Identifier>\n      <wps:Data>\n        <wps:LiteralData>80</wps:LiteralData>\n      </wps:Data>\n    </wps:Input>\n    <wps:Input>\n      <ows:Identifier>layer</ows:Identifier>\n      <wps:Data>\n        <wps:ComplexData xmlns:dwn=\"http://geoserver.org/wps/download\">\n          <dwn:Layer>\n            <dwn:Name>giantPolygon</dwn:Name>\n            <dwn:Parameter key=\"featureId\">giantPolygon.0</dwn:Parameter>\n          </dwn:Layer>\n        </wps:ComplexData>\n      </wps:Data>\n    </wps:Input>\n    <wps:Input>\n      <ows:Identifier>layer</ows:Identifier>\n      <wps:Data>\n        <wps:ComplexData xmlns:dwn=\"http://geoserver.org/wps/download\">\n          <dwn:Layer>\n            <dwn:Name>watertemp</dwn:Name>\n          </dwn:Layer>\n        </wps:ComplexData>\n      </wps:Data>\n    </wps:Input>\n  </wps:DataInputs>\n  <wps:ResponseForm>\n    <wps:RawDataOutput mimeType=\"image/png\">\n      <ows:Identifier>result</ows:Identifier>\n    </wps:RawDataOutput>\n  </wps:ResponseForm>\n</wps:Execute>\n

                      For this example the layers could have been a single one, with a \"Name\" equal to \"giantPolygon,watertermp\".

                      "},{"location":"extensions/wps-download/mapAnimationDownload/#secondary-output-map-metadata","title":"Secondary output: map metadata","text":"

                      The process offers also a secondary output, called metadata, which can be used to determine if there were any issue related to the requested times. The warnings are issued when the layer has a \"nearest match\" behavior activated, with an eventual search range.

                      In case the requested time could not be matched exactly, a warning will be issued that might contain:

                      • An indication that a nearby time has been used, and which time that is.
                      • An indication that no time was found, that was sufficiently close to the requested one, according to the search range specification in the layer \"nearest match\" configuration.

                      In order to get both outputs, the following response form is recommended, which requires a reference (a link) for the map, while the warnings are included inline:

                      <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<wps:Execute version=\"1.0.0\" service=\"WPS\"\n             xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xmlns=\"http://www.opengis.net/wps/1.0.0\"\n             xmlns:wfs=\"http://www.opengis.net/wfs\" xmlns:wps=\"http://www.opengis.net/wps/1.0.0\"\n             xmlns:ows=\"http://www.opengis.net/ows/1.1\" xmlns:gml=\"http://www.opengis.net/gml\"\n             xmlns:ogc=\"http://www.opengis.net/ogc\" xmlns:wcs=\"http://www.opengis.net/wcs/1.1.1\"\n             xmlns:xlink=\"http://www.w3.org/1999/xlink\"\n             xsi:schemaLocation=\"http://www.opengis.net/wps/1.0.0 http://schemas.opengis.net/wps/1.0.0/wpsAll.xsd\">\n  <ows:Identifier>gs:DownloadMap</ows:Identifier>\n  <!-- Inputs section removed for brevity -->\n  <wps:ResponseForm>\n    <wps:ResponseDocument>\n      <wps:Output asReference=\"true\">\n        <ows:Identifier>result</ows:Identifier>\n      </wps:Output>\n      <wps:Output>\n        <ows:Identifier>metadata</ows:Identifier>\n      </wps:Output>\n    </wps:ResponseDocument>\n  </wps:ResponseForm>\n</wps:Execute>\n

                      A sample response, reporting warnings, follows:

                      <?xml version=\"1.0\" encoding=\"UTF-8\"?><wps:ExecuteResponse xmlns:wps=\"http://www.opengis.net/wps/1.0.0\" xmlns:ows=\"http://www.opengis.net/ows/1.1\" xmlns:xlink=\"http://www.w3.org/1999/xlink\" xmlns:xs=\"http://www.w3.org/2001/XMLSchema\" service=\"WPS\" serviceInstance=\"http://localhost:8080/geoserver/ows?\" version=\"1.0.0\" xml:lang=\"en\">\n  <wps:Process wps:processVersion=\"1.0.0\">\n    <ows:Identifier>gs:DownloadMap</ows:Identifier>\n    <ows:Title>Map Download Process</ows:Title>\n    <ows:Abstract>Builds a large map given a set of layer definitions, area of interest, size and eventual target time.</ows:Abstract>\n  </wps:Process>\n  <wps:Status creationTime=\"2021-06-07T16:50:47.391Z\">\n    <wps:ProcessSucceeded>Process succeeded.</wps:ProcessSucceeded>\n  </wps:Status>\n  <wps:ProcessOutputs>\n    <wps:Output>\n      <ows:Identifier>result</ows:Identifier>\n      <ows:Title>The output map</ows:Title>\n      <wps:Reference href=\"http://localhost:8080/geoserver/ows?service=WPS&amp;version=1.0.0&amp;request=GetExecutionResult&amp;executionId=5db686ed-8591-4756-8651-4bd26281bf37&amp;outputId=result.png&amp;mimetype=image%2Fpng\" mimeType=\"image/png\"/>\n    </wps:Output>\n    <wps:Output>\n      <ows:Identifier>metadata</ows:Identifier>\n      <ows:Title>map metadata, including dimension match warnings</ows:Title>\n      <wps:Data>\n        <wps:ComplexData mimeType=\"text/xml\">\n          <DownloadMetadata>\n            <Warnings>\n              <DimensionWarning>\n                <LayerName>sf:bmtime</LayerName>\n                <DimensionName>time</DimensionName>\n                <Value class=\"Date\">2004-02-01T00:00:00.000Z</Value>\n                <WarningType>Nearest</WarningType>\n              </DimensionWarning>\n            </Warnings>\n            <WarningsFound>true</WarningsFound>\n          </DownloadMetadata>\n        </wps:ComplexData>\n      </wps:Data>\n    </wps:Output>\n  </wps:ProcessOutputs>\n</wps:ExecuteResponse>\n
                      "},{"location":"extensions/wps-download/mapAnimationDownload/#animation-download-process","title":"Animation Download Process","text":"

                      The download animation has all the basic parameters with the following variants/additions:

                      • time: The time parameter is required and can be provided either as range with periodicity, start/stop/period, or as a comma separated list of times,t1,t2,...,tn
                      • fps: Frame per seconds (defaults to one)
                      "},{"location":"extensions/wps-download/mapAnimationDownload/#sample-downloadanimation-request","title":"Sample DownloadAnimation request","text":"

                      A sample animation request can look as follows:

                      <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<wps:Execute version=\"1.0.0\" service=\"WPS\"\n             xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xmlns=\"http://www.opengis.net/wps/1.0.0\"\n             xmlns:wfs=\"http://www.opengis.net/wfs\" xmlns:wps=\"http://www.opengis.net/wps/1.0.0\"\n             xmlns:ows=\"http://www.opengis.net/ows/1.1\" xmlns:gml=\"http://www.opengis.net/gml\"\n             xmlns:ogc=\"http://www.opengis.net/ogc\" xmlns:wcs=\"http://www.opengis.net/wcs/1.1.1\"\n             xmlns:xlink=\"http://www.w3.org/1999/xlink\"\n             xsi:schemaLocation=\"http://www.opengis.net/wps/1.0.0 http://schemas.opengis.net/wps/1.0.0/wpsAll.xsd\">\n  <ows:Identifier>gs:DownloadAnimation</ows:Identifier>\n  <wps:DataInputs>\n    <wps:Input>\n      <ows:Identifier>bbox</ows:Identifier>\n      <wps:Data>\n        <wps:BoundingBoxData crs=\"EPSG:4326\">\n          <ows:LowerCorner>-180 -90</ows:LowerCorner>\n          <ows:UpperCorner>180 90</ows:UpperCorner>\n        </wps:BoundingBoxData>\n      </wps:Data>\n    </wps:Input>\n    <wps:Input>\n      <ows:Identifier>decoration</ows:Identifier>\n      <wps:Data>\n        <wps:LiteralData>formattedTimestamper</wps:LiteralData>\n      </wps:Data>\n    </wps:Input>\n    <wps:Input>\n      <ows:Identifier>time</ows:Identifier>\n      <wps:Data>\n        <wps:LiteralData>2004-02-01,2004-03-01,2004-04-01,2004-05-01</wps:LiteralData>\n      </wps:Data>\n    </wps:Input>\n    <wps:Input>\n      <ows:Identifier>width</ows:Identifier>\n      <wps:Data>\n        <wps:LiteralData>271</wps:LiteralData>\n      </wps:Data>\n    </wps:Input>\n    <wps:Input>\n      <ows:Identifier>height</ows:Identifier>\n      <wps:Data>\n        <wps:LiteralData>136</wps:LiteralData>\n      </wps:Data>\n    </wps:Input>\n    <wps:Input>\n      <ows:Identifier>fps</ows:Identifier>\n      <wps:Data>\n        <wps:LiteralData>0.5</wps:LiteralData>\n      </wps:Data>\n    </wps:Input>\n    <wps:Input>\n      <ows:Identifier>layer</ows:Identifier>\n      <wps:Data>\n        <wps:ComplexData xmlns:dwn=\"http://geoserver.org/wps/download\">\n          <dwn:Layer>\n            <dwn:Name>sf:bmtime</dwn:Name>\n          </dwn:Layer>\n        </wps:ComplexData>\n      </wps:Data>\n    </wps:Input>\n  </wps:DataInputs>\n  <wps:ResponseForm>\n    <wps:RawDataOutput mimeType=\"video/mp4\">\n      <ows:Identifier>result</ows:Identifier>\n    </wps:RawDataOutput>\n  </wps:ResponseForm>\n</wps:Execute>\n

                      The formattedTimestamper decoration ensures the frame time is included in the output animation, and looks as follows:

                      <layout>\n  <decoration type=\"text\" affinity=\"bottom,right\" offset=\"6,6\" size=\"auto\">\n    <option name=\"message\"><![CDATA[\n<#setting datetime_format=\"yyyy-MM-dd'T'HH:mm:ss.SSSX\">\n<#setting locale=\"en_US\">\n<#if time??>\n${time?datetime?string[\"dd-MM-yyyy\"]}\n</#if>]]></option>\n    <option name=\"font-family\" value=\"Bitstream Vera Sans\"/>\n    <option name=\"font-size\" value=\"12\"/>\n    <option name=\"halo-radius\" value=\"2\"/>\n  </decoration>\n</layout>\n
                      "},{"location":"extensions/wps-download/mapAnimationDownload/#secondary-output-animation-metadata","title":"Secondary output: animation metadata","text":"

                      The process offers also a secondary output, called metadata, which can be used to determine if there were any issue related to the requested times. The warnings are issued when the layer has a \"nearest match\" behavior activated, with an eventual search range.

                      In case the requested time could not be matched exactly, a warning will be issued that might contain:

                      • An indication that a nearby time has been used, and which time that is.
                      • An indication that no time was found, that was sufficiently close to the requested one, according to the search range specification in the layer \"nearest match\" configuration.

                      In order to get both outputs, the following response form is recommended, which requires a reference (a link) for the animation, while the warnings are included inline:

                      <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<wps:Execute version=\"1.0.0\" service=\"WPS\"\n             xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xmlns=\"http://www.opengis.net/wps/1.0.0\"\n             xmlns:wfs=\"http://www.opengis.net/wfs\" xmlns:wps=\"http://www.opengis.net/wps/1.0.0\"\n             xmlns:ows=\"http://www.opengis.net/ows/1.1\" xmlns:gml=\"http://www.opengis.net/gml\"\n             xmlns:ogc=\"http://www.opengis.net/ogc\" xmlns:wcs=\"http://www.opengis.net/wcs/1.1.1\"\n             xmlns:xlink=\"http://www.w3.org/1999/xlink\"\n             xsi:schemaLocation=\"http://www.opengis.net/wps/1.0.0 http://schemas.opengis.net/wps/1.0.0/wpsAll.xsd\">\n  <ows:Identifier>gs:DownloadAnimation</ows:Identifier>\n  <!-- Inputs section removed for brevity -->\n  <wps:ResponseForm>\n    <wps:ResponseDocument>\n      <wps:Output asReference=\"true\">\n        <ows:Identifier>result</ows:Identifier>\n      </wps:Output>\n      <wps:Output>\n        <ows:Identifier>metadata</ows:Identifier>\n      </wps:Output>\n    </wps:ResponseDocument>\n  </wps:ResponseForm>\n</wps:Execute>\n

                      A sample response, reporting warnings and the frame count where they happened, follows:

                      <?xml version=\"1.0\" encoding=\"UTF-8\"?><wps:ExecuteResponse xmlns:wps=\"http://www.opengis.net/wps/1.0.0\" xmlns:ows=\"http://www.opengis.net/ows/1.1\" xmlns:xlink=\"http://www.w3.org/1999/xlink\" xmlns:xs=\"http://www.w3.org/2001/XMLSchema\" service=\"WPS\" serviceInstance=\"http://localhost:8080/geoserver/ows?\" version=\"1.0.0\" xml:lang=\"en\">\n  <wps:Process wps:processVersion=\"1.0.0\">\n    <ows:Identifier>gs:DownloadAnimation</ows:Identifier>\n    <ows:Title>Animation Download Process</ows:Title>\n    <ows:Abstract>Builds an animation given a set of layer definitions, area of interest, size and a series of times for animation frames.</ows:Abstract>\n  </wps:Process>\n  <wps:Status creationTime=\"2021-06-07T16:50:47.391Z\">\n    <wps:ProcessSucceeded>Process succeeded.</wps:ProcessSucceeded>\n  </wps:Status>\n  <wps:ProcessOutputs>\n    <wps:Output>\n      <ows:Identifier>result</ows:Identifier>\n      <ows:Title>The animation</ows:Title>\n      <wps:Reference href=\"http://localhost:8080/geoserver/ows?service=WPS&amp;version=1.0.0&amp;request=GetExecutionResult&amp;executionId=b98eded5-8122-442b-a6c7-87a872779153&amp;outputId=result.mp4&amp;mimetype=video%2Fmp4\" mimeType=\"video/mp4\"/>\n    </wps:Output>\n    <wps:Output>\n      <ows:Identifier>metadata</ows:Identifier>\n      <ows:Title>Animation metadata, including dimension match warnings</ows:Title>\n      <wps:Data>\n        <wps:ComplexData mimeType=\"text/xml\">\n          <AnimationMetadata>\n            <Warnings>\n              <FrameWarning>\n                <LayerName>sf:bmtime</LayerName>\n                <DimensionName>time</DimensionName>\n                <Value class=\"Date\">2004-02-01T00:00:00.000Z</Value>\n                <WarningType>Nearest</WarningType>\n                <Frame>0</Frame>\n              </FrameWarning>\n              <FrameWarning>\n                <LayerName>sf:bmtime</LayerName>\n                <DimensionName>time</DimensionName>\n                <WarningType>FailedNearest</WarningType>\n                <Frame>1</Frame>\n              </FrameWarning>\n              <FrameWarning>\n                <LayerName>sf:bmtime</LayerName>\n                <DimensionName>time</DimensionName>\n                <Value class=\"Date\">2004-04-01T00:00:00.000Z</Value>\n                <WarningType>Nearest</WarningType>\n                <Frame>2</Frame>\n              </FrameWarning>\n              <FrameWarning>\n                <LayerName>sf:bmtime</LayerName>\n                <DimensionName>time</DimensionName>\n                <Value class=\"Date\">2004-05-01T00:00:00.000Z</Value>\n                <WarningType>Nearest</WarningType>\n                <Frame>3</Frame>\n              </FrameWarning>\n            </Warnings>\n            <WarningsFound>true</WarningsFound>\n          </AnimationMetadata>\n        </wps:ComplexData>\n      </wps:Data>\n    </wps:Output>\n  </wps:ProcessOutputs>\n</wps:ExecuteResponse>\n

                      In the above output, frames 0, 2 and 3 were nearest matched to an available time, being specified in the Value field, while the time requested for frame number 1 was too far away from any available time, resulting in a NearestFail. The frame is still present in the animation, but will likely be blank. In case multiple time based layers are requested in the animation, there might be multiple warnings for each frame.

                      Footnotes

                      [^1]: The default value of transparent can be flipped using a system variable, e.g. -DDOWNLOAD_MAP_TRANSPARENT=true

                      "},{"location":"extensions/wps-download/rawDownload/","title":"Raw data download processes","text":"

                      These processes allow download of vector and raster data in raw form, without rendering.

                      "},{"location":"extensions/wps-download/rawDownload/#download-estimator-process","title":"Download Estimator Process","text":"

                      The Download Estimator Process checks the size of the file to download. This process takes in input the following parameters:

                      • layername : name of the layer to check
                      • ROI : ROI object to use for cropping data
                      • filter : filter for filtering input data
                      • targetCRS : CRS of the final layer if reprojection is needed

                      This process will return a boolean which will be true if the downloaded file will not exceed the configured limits.

                      "},{"location":"extensions/wps-download/rawDownload/#download-process","title":"Download Process","text":"

                      The Download Process calls the Download Estimator Process, checks the file size, and, if the file does not exceed the limits, download the file as a zip. The parameters to set are

                      • layerName : the name of the layer to process/download
                      • filter : a vector filter for filtering input data(optional)
                      • outputFormat : the MIME type of the format of the final file
                      • targetCRS : the CRS of the output file (optional)
                      • RoiCRS : Region Of Interest CRS (optional)
                      • ROI : Region Of Interest object to use for cropping data (optional)
                      • cropToROI : boolean parameter to allow cropping to actual ROI, or its envelope (optional)
                      • interpolation : interpolation function to use when reprojecting / scaling raster data. Values are NEAREST (default), BILINEAR, BICUBIC2, BICUBIC (optional)
                      • targetSizeX : size X in pixels of the output (optional, applies for raster input only)
                      • targetSizeY : size Y in pixels of the output (optional, applies for raster input only)
                      • selectedBands : a set of the band indices of the original raster that will be used for producing the final result (optional, applies for raster input only)
                      • writeParameters : a set of writing parameters (optional, applies for raster input only). See Writing parameters below section for more details on writing parameters defintion.
                      • minimizeReprojections : since 2.17, parameter to control CRS management when dealing with heterogeneous CRS's coverages, in order to minimize reprojections when granules in ROI match the TargetCRS. See RasterDownload of Heterogeneous CRS ImageMosaic below section for more details on this param.
                      • bestResolutionOnMatchingCRS : since 2.17, parameter to control CRS and resolution management when dealing with heterogeneous CRS's coverages. See RasterDownload of Heterogeneous CRS ImageMosaic below section for more details on this param.
                      • targetVerticalCRS : optional TargetVerticalCRS, to be used to transform elevation data from a VerticalCRS to another one. See Vertical data resampling on download below section for more details on this param
                      • resolutionsDifferenceTolerance : the parameter allows to specify a tolerance value to control the use of native resolution of the data, when no target size has been specified and granules are reprojected. If
                        • the percentage difference between original and reprojected coverages resolutions is below the specified tolerance value,
                        • native resolution is the same for all the requested granules,
                        • the unit of measure is the same for native and target CRS,

                      the reprojected coverage will be forced to use native resolutions. For example by specifying a value of 5.0, if the percentage difference between native and reprojected data is below 5%, assuming that also the other two conditions are respected, the native resolutions will be preserved. Default values is 0.

                      The targetCRS and RoiCRS parameters are using EPSG code terminology, so, valid parameters are literals like EPSG:4326 (if we are referring to a the Geogaphic WGS84 CRS), EPSG:3857 (for WGS84 Web Mercator CRS), etc.

                      "},{"location":"extensions/wps-download/rawDownload/#roi-definition","title":"ROI Definition","text":"

                      A ROI parameter is a geometry object which can also be defined if three different forms:

                      • as TEXT, in various geometry textual formats/representations
                      • as REFERENCE, which is the textual result of an HTTP GET/POST request to a specific url
                      • as a SUPPROCESS result: the format produced as result of the process execution must be a compatible geometry textual format.

                      As noted above, in all above forms/cases ROI geometry is defined as text, in specific formats. These can be:

                      • text/xml; subtype=gml/3.1.1: conforming to gml specs 3.1.1
                      • text/xml; subtype=gml/2.1.2: conforming to gml specs 2.1.2
                      • application/wkt: the WKT geometry representation
                      • application/json: the JSON geometry representation
                      • application/gml-3.1.1: conforming to gml specs 3.1.1
                      • application/gml-2.1.2: conforming to gml specs 2.1.2

                      For example, a polygon used as ROI with the following WKT representation:

                      POLYGON (( 500116.08576537756 499994.25579707103, 500116.08576537756 500110.1012210889, 500286.2657688021 500110.1012210889, 500286.2657688021 499994.25579707103, 500116.08576537756 499994.25579707103 ))

                      would be represented in the following forms:

                      • in application/wkt: POLYGON (( 500116.08576537756 499994.25579707103, 500116.08576537756 500110.1012210889, 500286.2657688021 500110.1012210889, 500286.2657688021 499994.25579707103, 500116.08576537756 499994.25579707103 ))
                      • in application/json: {\"type\":\"Polygon\",\"coordinates\":[[[500116.0858,499994.2558],[500116.0858,500110.1012],[500286.2658,500110.1012],[500286.2658,499994.2558],[500116.0858,499994.2558]]]}
                      • in text/xml:500116.08576537756,499994.25579707103 500116.08576537756,500110.1012210889 500286.2657688021,500110.1012210889 500286.2657688021,499994.25579707103 500116.08576537756,499994.25579707103
                      • in application/xml: the following xml
                      <?xml version=\"1.0\" encoding=\"UTF-8\"?><gml:Polygon xmlns:gml=\"http://www.opengis.net/gml\" xmlns:xs=\"http://www.w3.org/2001/XMLSchema\" xmlns:xlink=\"http://www.w3.org/1999/xlink\">\n  <gml:outerBoundaryIs>\n    <gml:LinearRing>\n      <gml:coordinates>500116.08576537756,499994.25579707103 500116.08576537756,500110.1012210889 500286.2657688021,500110.1012210889 500286.2657688021,499994.25579707103 500116.08576537756,499994.25579707103</gml:coordinates>\n    </gml:LinearRing>\n  </gml:outerBoundaryIs>\n</gml:Polygon>\n

                      The general structure of a WPS Download request POST payload consists of two parts: the first (<wps:DataInputs>) contains the input parameters for the process, and the second (<wps:ResponseForm>) contains details about delivering the output. A typical pseudo payload is the following:

                      <?xml version=\"1.0\" encoding=\"UTF-8\"?><wps:Execute version=\"1.0.0\" service=\"WPS\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xmlns=\"http://www.opengis.net/wps/1.0.0\" xmlns:wfs=\"http://www.opengis.net/wfs\" xmlns:wps=\"http://www.opengis.net/wps/1.0.0\" xmlns:ows=\"http://www.opengis.net/ows/1.1\" xmlns:gml=\"http://www.opengis.net/gml\" xmlns:ogc=\"http://www.opengis.net/ogc\" xmlns:wcs=\"http://www.opengis.net/wcs/1.1.1\" xmlns:xlink=\"http://www.w3.org/1999/xlink\" xsi:schemaLocation=\"http://www.opengis.net/wps/1.0.0 http://schemas.opengis.net/wps/1.0.0/wpsAll.xsd\">\n <ows:Identifier>gs:WPS_Process_Name_Here</ows:Identifier>\n <wps:DataInputs>\n  <wps:Input>\n   <ows:Identifier>First_Param_Name</ows:Identifier>\n   <wps:Data>\n     (First_Param_Data)\n   </wps:Data>\n  </wps:Input>\n  ...\n  ...\n </wps:DataInputs>\n <wps:ResponseForm>\n  <wps:RawDataOutput mimeType=\"application/zip\">\n   <ows:Identifier>result</ows:Identifier>\n  </wps:RawDataOutput>\n </wps:ResponseForm>\n</wps:Execute>\n

                      Each parameter for the process is defined in its own <wps:Input> xml block. In case of simple type data, such as layerName, outputFormat, targetCRS, etc, input params xml blocks have the following form:

                      <wps:Input>\n <ows:Identifier>layerName</ows:Identifier>\n <wps:Data>\n  <wps:LiteralData>nurc:Img_Sample</wps:LiteralData>\n </wps:Data>\n</wps:Input>\n

                      Note the <wps:LiteralData> tags wrapping the parameter value. In case of geometry parameters, such as filter, ROI, the parameter's <wps:Input> block is different:

                      <wps:Input>\n  <ows:Identifier>ROI</ows:Identifier>\n  <wps:Data>\n    <wps:ComplexData mimeType=\"application/wkt\"><![CDATA[POLYGON (( 500116.08576537756 499994.25579707103, 500116.08576537756 500110.1012210889, 500286.2657688021 500110.1012210889, 500286.2657688021 499994.25579707103, 500116.08576537756 499994.25579707103 ))]]></wps:ComplexData>\n  </wps:Data>\n</wps:Input>\n

                      Note the <wps:ComplexData> tag, the mimeType=\"application/wkt\" parameter, and the ![CDATA[] wrapping of the actual geometry data (in textual representation), according to the selected MIME type.

                      Note that if the ROI parameter is defined as WKT, you will need to specify a RoiCRS input parameter as well.

                      In case the ROI is defined using a REFERENCE source, the input block is slightly different:

                      <wps:Input>\n  <ows:Identifier>ROI</ows:Identifier>\n  <wps:Reference mimeType=\"application/wkt\" xlink:href=\"url_to_fetch_data\" method=\"GET\"/>\n</wps:Input>\n

                      Note the <wps:Reference> tag replacing <wps:ComplexData> tag, and the extra xlink:href=\"url_to_fetch_data\" parameter, which defines the url to perform the HTTP GET request. For POST request cases, tech method is switched to POST, and a <wps:Body> tag is used to wrap POST data:

                      <wps:Reference mimeType=\"application/wkt\" xlink:href=\"url_to_fetch_data\" method=\"POST\">\n  <wps:Body><![CDATA[request_body_data]]></wps:Body>\n</wps:Reference>\n
                      "},{"location":"extensions/wps-download/rawDownload/#filter-parameter-definition","title":"Filter parameter definition","text":"

                      A filter parameter is a definition of a vector filter operation:

                      • as TEXT, in various textual formats/representations
                      • as REFERENCE, which is the textual result of an HTTP GET/POST request to a specific url
                      • as a SUBPROCESS result: the format produced as result of the process execution must be a compatible geometry textual format.

                      Compatible text formats for filter definitions are:

                      • text/xml; filter/1.0
                      • text/xml; filter/1.1
                      • text/xml; cql

                      For more details on filter formats/languages, one can see ../../filter/syntax and ../../filter/function. Filter parameter applies to vector data. If this is the case with input data, a sample <wps:Input> block of a filter intersecting the polygon we used earlier as an example for ROI definition would be:

                      <wps:Input>\n  <ows:Identifier>filter</ows:Identifier>\n  <wps:Data>\n    <wps:ComplexData mimeType=\"text/plain; subtype=cql\"><![CDATA[<Intersects>\n       <PropertyName>GEOMETRY</PropertyName>\n         <gml:Polygon>\n           <gml:outerBoundaryIs>\n             <gml:LinearRing>\n                <gml:coordinates>500116.08576537756,499994.25579707103 500116.08576537756,500110.1012210889 500286.2657688021,500110.1012210889 500286.2657688021,499994.25579707103 500116.08576537756,499994.25579707103</gml:coordinates>\n              </gml:LinearRing>\n           </gml:outerBoundaryIs>\n         </gml:Polygon>\n     </Intersects>]]></wps:ComplexData>\n  </wps:Data>\n</wps:Input>\n
                      "},{"location":"extensions/wps-download/rawDownload/#sample-request","title":"Sample request","text":""},{"location":"extensions/wps-download/rawDownload/#synchronous-execution","title":"Synchronous execution","text":"

                      The following is a sample WPS request for processing a raster dataset. Suppose we want to use the North America sample imagery (nurc:Img_Sample) layer, to produce an 80x80 pixels downloadable tiff in EPSG:4326

                      Assuming that a local geoserver instance (setup for wps/wps-download support) is running, we issue a POST request to the url:

                      http://127.0.0.1:8080/geoserver/ows?service=wps

                      using the following payload:

                      <?xml version=\"1.0\" encoding=\"UTF-8\"?><wps:Execute version=\"1.0.0\" service=\"WPS\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xmlns=\"http://www.opengis.net/wps/1.0.0\" xmlns:wfs=\"http://www.opengis.net/wfs\" xmlns:wps=\"http://www.opengis.net/wps/1.0.0\" xmlns:ows=\"http://www.opengis.net/ows/1.1\" xmlns:gml=\"http://www.opengis.net/gml\" xmlns:ogc=\"http://www.opengis.net/ogc\" xmlns:wcs=\"http://www.opengis.net/wcs/1.1.1\" xmlns:xlink=\"http://www.w3.org/1999/xlink\" xsi:schemaLocation=\"http://www.opengis.net/wps/1.0.0 http://schemas.opengis.net/wps/1.0.0/wpsAll.xsd\">\n <ows:Identifier>gs:Download</ows:Identifier>\n <wps:DataInputs>\n  <wps:Input>\n   <ows:Identifier>layerName</ows:Identifier>\n   <wps:Data>\n    <wps:LiteralData>nurc:Img_Sample</wps:LiteralData>\n   </wps:Data>\n  </wps:Input>\n  <wps:Input>\n   <ows:Identifier>outputFormat</ows:Identifier>\n   <wps:Data>\n    <wps:LiteralData>image/tiff</wps:LiteralData>\n   </wps:Data>\n  </wps:Input>\n  <wps:Input>\n   <ows:Identifier>targetCRS</ows:Identifier>\n   <wps:Data>\n    <wps:LiteralData>EPSG:4326</wps:LiteralData>\n   </wps:Data>\n  </wps:Input>\n  <wps:Input>\n   <ows:Identifier>targetSizeX</ows:Identifier>\n   <wps:Data>\n    <wps:LiteralData>80</wps:LiteralData>\n   </wps:Data>\n  </wps:Input>\n  <wps:Input>\n   <ows:Identifier>targetSizeY</ows:Identifier>\n   <wps:Data>\n    <wps:LiteralData>80</wps:LiteralData>\n   </wps:Data>\n  </wps:Input>\n </wps:DataInputs>\n <wps:ResponseForm>\n  <wps:RawDataOutput mimeType=\"application/zip\">\n   <ows:Identifier>result</ows:Identifier>\n  </wps:RawDataOutput>\n </wps:ResponseForm>\n</wps:Execute>\n

                      More parameters (from the parameter list above) can be used, for example, we can only select bands 0 and 2 from the original raster:

                      <wps:Input>\n <ows:Identifier>bandIndices</ows:Identifier>\n <wps:Data>\n  <wps:LiteralData>0</wps:LiteralData>\n </wps:Data>\n</wps:Input>\n<wps:Input>\n <ows:Identifier>bandIndices</ows:Identifier>\n <wps:Data>\n  <wps:LiteralData>2</wps:LiteralData>\n </wps:Data>\n</wps:Input>\n

                      Or, use a Region Of Interest to crop the dataset:

                      <wps:Input>\n  <ows:Identifier>ROI</ows:Identifier>\n  <wps:Data>\n    <wps:ComplexData mimeType=\"application/wkt\"><![CDATA[\"POLYGON (( 500116.08576537756 499994.25579707103, 500116.08576537756 500110.1012210889, 500286.2657688021 500110.1012210889, 500286.2657688021 499994.25579707103, 500116.08576537756 499994.25579707103 ))]]></wps:ComplexData>\n  </wps:Data>\n</wps:Input>\n<wps:Input>\n  <ows:Identifier>RoiCRS</ows:Identifier>\n  <wps:Data>\n    <wps:LiteralData>EPSG:32615</wps:LiteralData>\n  </wps:Data>\n</wps:Input>\n

                      The result produced is a zipped file to download.

                      "},{"location":"extensions/wps-download/rawDownload/#asynchronous-execution","title":"Asynchronous execution","text":"

                      The process can also be performed asynchronously. In this case, the second part (wps:ResponseForm) of the wps download payload slightly changes, by using the storeExecuteResponse and status parameters, set to true for the <wps:ResponseDocument>:

                      <wps:ResponseForm>\n  <wps:ResponseDocument storeExecuteResponse=\"true\" status=\"true\">\n    <wps:RawDataOutput mimeType=\"application/zip\">\n      <ows:Identifier>result</ows:Identifier>\n    </wps:RawDataOutput>\n  </wps:ResponseDocument>>\n</wps:ResponseForm>\n

                      In case of asynchronous execution, the initial request to download data returns an xml indication that the process has successfully started:

                      <?xml version=\"1.0\" encoding=\"UTF-8\"?><wps:ExecuteResponse xmlns:xs=\"http://www.w3.org/2001/XMLSchema\" xmlns:ows=\"http://www.opengis.net/ows/1.1\" xmlns:wps=\"http://www.opengis.net/wps/1.0.0\" xmlns:xlink=\"http://www.w3.org/1999/xlink\" xml:lang=\"en\" service=\"WPS\" serviceInstance=\"http://127.0.0.1:8080/geoserver/ows?\" statusLocation=\"http://127.0.0.1:8080/geoserver/ows?service=WPS&amp;version=1.0.0&amp;request=GetExecutionStatus&amp;executionId=dd0d61f5-7da3-41ed-bd3f-15311fa660ba\" version=\"1.0.0\">\n  <wps:Process wps:processVersion=\"1.0.0\">\n      <ows:Identifier>gs:Download</ows:Identifier>\n      <ows:Title>Enterprise Download Process</ows:Title>\n      <ows:Abstract>Downloads Layer Stream and provides a ZIP.</ows:Abstract>\n  </wps:Process>\n  <wps:Status creationTime=\"2016-08-08T11:03:18.167Z\">\n      <wps:ProcessAccepted>Process accepted.</wps:ProcessAccepted>\n  </wps:Status>\n</wps:ExecuteResponse>\n

                      The response contains a <wps:Status> block indicating successful process creation and process start time. However, the important part in this response is the executionId=dd0d61f5-7da3-41ed-bd3f-15311fa660ba attribute in the <wps:ExecuteResponse> tag. The dd0d61f5-7da3-41ed-bd3f-15311fa660ba ID can be used as a reference for this process, in order to issue new GET requests and to check process status. These requests have the form:

                      http://127.0.0.1:8080/geoserver/ows?service=WPS&request=GetExecutionStatus&executionId=277e24eb-365d-42e1-8329-44b8076d4fc0

                      When issued (and process has finished on the server), this GET request returns the result to download/process as a base64 encoded zip:

                      <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<wps:ExecuteResponse xmlns:xs=\"http://www.w3.org/2001/XMLSchema\" xmlns:ows=\"http://www.opengis.net/ows/1.1\" xmlns:wps=\"http://www.opengis.net/wps/1.0.0\" xmlns:xlink=\"http://www.w3.org/1999/xlink\" xml:lang=\"en\" service=\"WPS\" serviceInstance=\"http://127.0.0.1:8080/geoserver/ows?\" statusLocation=\"http://127.0.0.1:8080/geoserver/ows?service=WPS&amp;version=1.0.0&amp;request=GetExecutionStatus&amp;executionId=0c596a4d-7ddb-4a4e-bf35-4a64b47ee0d3\" version=\"1.0.0\">\n  <wps:Process wps:processVersion=\"1.0.0\">\n      <ows:Identifier>gs:Download</ows:Identifier>\n      <ows:Title>Enterprise Download Process</ows:Title>\n      <ows:Abstract>Downloads Layer Stream and provides a ZIP.</ows:Abstract>\n  </wps:Process>\n  <wps:Status creationTime=\"2016-08-08T11:18:46.015Z\">\n      <wps:ProcessSucceeded>Process succeeded.</wps:ProcessSucceeded>\n  </wps:Status>\n  <wps:ProcessOutputs>\n      <wps:Output>\n          <ows:Identifier>result</ows:Identifier>\n          <ows:Title>Zipped output files to download</ows:Title>\n          <wps:Data>\n              <wps:ComplexData encoding=\"base64\" mimeType=\"application/zip\">UEsDBBQACAgIAFdyCEkAAAAAAAAAAAAAAAApAAAAMGEwYmJkYmQtMjdkNi00...(more zipped raster data following, ommited for space saving)...</wps:ComplexData>\n          </wps:Data>\n      </wps:Output>\n  </wps:ProcessOutputs>\n</wps:ExecuteResponse>\n
                      "},{"location":"extensions/wps-download/rawDownload/#asynchronous-execution-output-as-a-reference","title":"Asynchronous execution (output as a reference)","text":"

                      The <wps:ResponseForm> of the previous asynchronous request payload example can be modified to get back a link to the file to be downloaded instead of the base64 encoded data.

                      ...\n<wps:ResponseForm>\n  <wps:ResponseDocument storeExecuteResponse=\"true\" status=\"true\">\n    <wps:Output asReference=\"true\" mimeType=\"application/zip\">\n      <ows:Identifier>result</ows:Identifier>\n    </wps:Output>\n  </wps:ResponseDocument>\n</wps:ResponseForm>\n

                      Note <wps:ResponseDocument> contains a <wps:Output> instead of a <wps:RawDataOutput> being used by previous example. Moreover the attribute asReference set to true has been added to the <wps:Output>.

                      This time, when issued (and process has finished on the server), the GET request returns the result to download as a link as part of <wps:Output><wps:Reference> .

                      <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n  <wps:ExecuteResponse xmlns:xs=\"http://www.w3.org/2001/XMLSchema\" xmlns:ows=\"http://www.opengis.net/ows/1.1\" xmlns:wps=\"http://www.opengis.net/wps/1.0.0\" xmlns:xlink=\"http://www.w3.org/1999/xlink\" xml:lang=\"en\" service=\"WPS\" serviceInstance=\"http://127.0.0.1:8080/geoserver/ows?\" statusLocation=\"http://127.0.0.1:8080/geoserver/ows?service=WPS&amp;version=1.0.0&amp;request=GetExecutionStatus&amp;executionId=c1074100-446a-4963-94ad-cbbf8b8a7fd1\" version=\"1.0.0\">\n  <wps:Process wps:processVersion=\"1.0.0\">\n    <ows:Identifier>gs:Download</ows:Identifier>\n    <ows:Title>Enterprise Download Process</ows:Title>\n    <ows:Abstract>Downloads Layer Stream and provides a ZIP.</ows:Abstract>\n  </wps:Process>\n  <wps:Status creationTime=\"2016-08-08T11:38:34.024Z\">\n    <wps:ProcessSucceeded>Process succeeded.</wps:ProcessSucceeded>\n  </wps:Status>\n  <wps:ProcessOutputs>\n    <wps:Output>\n      <ows:Identifier>result</ows:Identifier>\n      <ows:Title>Zipped output files to download</ows:Title>\n      <wps:Reference href=\"http://127.0.0.1:8080/geoserver/ows?service=WPS&amp;version=1.0.0&amp;request=GetExecutionResult&amp;executionId=c1074100-446a-4963-94ad-cbbf8b8a7fd1&amp;outputId=result.zip&amp;mimetype=application%2Fzip\" mimeType=\"application/zip\" />\n    </wps:Output>\n  </wps:ProcessOutputs>\n</wps:ExecuteResponse>\n
                      "},{"location":"extensions/wps-download/rawDownload/#output-format-and-response-mime-types","title":"Output Format and Response mime-types","text":"

                      By default, downloading vector data results in a Shapefile, compressed in a zip file along with its SLD file. It's also possible to download a GeoPackage file using application/geopackage+sqlite3 as the value for the mimeType parameter.

                      Similarly, for raster data, by default the downloaded raster gets zipped, along with the SLD style associated to the layer. In some cases, this can be unnecessary, especially if the output TIFF already has some type of internal compression or if we simply want to get back the TIFF output file without the ancillary SLD. Let's consider downloading a RGB TIFF: the default raster.sld style won't add anything useful to the output. In that case it's possible to specify image/tiff in the Response's output mimeType: the output TIFF will be provided as is, without extra steps of compression and file management.

                      ...\n<wps:ResponseForm>\n  <wps:ResponseDocument storeExecuteResponse=\"true\" status=\"true\">\n    <wps:Output asReference=\"true\" mimeType=\"image/tiff\">\n      <ows:Identifier>result</ows:Identifier>\n    </wps:Output>\n  </wps:ResponseDocument>\n</wps:ResponseForm>\n

                      It is also possible to download the raster data as a GeoPackage, using application/geopackage+sqlite3 as the value for the mimeType parameter.

                      "},{"location":"extensions/wps-download/rawDownload/#writing-buffering-options","title":"Writing buffering options","text":"

                      By default raster pixels are encoded using a file stream writing through a default 16KB data buffer. Depending on the network and disk setup, you might want to change the size of the buffer to improve performance. This can be done by adding this property to the JAVA_OPTS: -Dorg.geoserver.wps.download.raster.buffer.size=sizeinbytes where sizeinbytes is the actual value to be set, i.e. 1048576 to set a 1MB buffer.

                      Moreover, when copying back data resources from within the WPS machinery to the final file output location, a default 16KB data buffer is being used. It's also possible to change the size of such buffer by adding this property to the JAVA_OPTS: -Dorg.geoserver.wps.copy.buffer.size=sizeinbytes where sizeinbytes is the actual value to be set, i.e. 1048576 to set a 1MB buffer.

                      "},{"location":"extensions/wps-download/rawDownload/#writing_params","title":"Writing parameters","text":"

                      The writeParameters input element of a process execution allows to specify parameters to be applied by the outputFormat encoder when producing the output file. Writing parameters are listed as multiple <dwn:Parameter key=\"writingParameterName\">value</dwn:Parameter> within a <dwn:Parameters> parent element. See the below xml containing full syntax of a valid example for TIFF output format:

                      <wps:Input>\n  <ows:Identifier>writeParameters</ows:Identifier>\n    <wps:Data>\n       <wps:ComplexData xmlns:dwn=\"http://geoserver.org/wps/download\">\n         <dwn:Parameters>\n            <dwn:Parameter key=\"tilewidth\">128</dwn:Parameter>\n            <dwn:Parameter key=\"tileheight\">128</dwn:Parameter>\n            <dwn:Parameter key=\"compression\">JPEG</dwn:Parameter>\n            <dwn:Parameter key=\"quality\">0.75</dwn:Parameter>\n         </dwn:Parameters>\n       </wps:ComplexData>\n    </wps:Data>\n</wps:Input>\n
                      "},{"location":"extensions/wps-download/rawDownload/#geotifftiff-supported-writing-parameters","title":"GeoTIFF/TIFF supported writing parameters","text":"

                      The supported writing parameters are:

                      • tilewidth : Width of internal tiles, in pixels
                      • tileheight : Height of internal tiles, in pixels
                      • compression : Compression type used to store internal tiles. Supported values are:
                        • CCITT RLE (Lossless) (Huffman)
                        • LZW (Lossless)
                        • JPEG (Lossy)
                        • ZLib (Lossless)
                        • PackBits (Lossless)
                        • Deflate (Lossless)
                      • quality : Compression quality. Value is in the range [0 : 1]
                        • for JPEG lossy compression, 0 is for worst quality/higher compression and 1 is for best quality/lower compression. (default is 1).
                        • for Deflate lossless compression, input value in the range [0 : 1] is linearly mapped to output deflate level in the range [1 : 9]: (deflate level = 1 + 8 * (quality)), where level 1 is for best speed and level 9 is for best compression. (default level is 9)
                      • writenodata : Supported value is one of true/false. Note that, by default, a nodata TAG is produced as part of the output GeoTIFF file as soon as a nodata is found in the GridCoverage2D to be written. Therefore, not specifying this parameter will result into writing nodata to preserve default behavior. Setting it to false will avoid writing that TAG.
                      "},{"location":"extensions/wps-download/rawDownload/#direct-download","title":"Direct download","text":"

                      The raster process does its best to identify downloads that are in fact selecting a single, complete source file, and will perform a straight copy of it in such case.

                      Conditions:

                      • A single, complete source file is selected by the request (e.g. full input GeoTIFF, or single full granule out of an image mosaic).
                      • The output format matches the input (e.g. both GeoTIFF)
                      • The write parameters, if present, match the structure of the input file (same compression, same tiling structure)

                      In order to better support opportunities for direct download, it's possible to specify the write parameter compression as auto: it won't interfere with selection of a direct download, if possible, and will fall back to deflate in case the direct download is not possible.

                      "},{"location":"extensions/wps-download/rawDownload/#heterogeneous_imagemosaic","title":"RasterDownload of Heterogeneous CRS ImageMosaic","text":"

                      An ImageMosaic made of granules in different coordinate reference systems (i.e. several DEM files in different UTM zones) is defined as ImageMosaic with Heterogeneous CRS. The ImageMosaic layer will expose a common CRS as the native one (i.e. 4326).

                      By default, mosaicking granules with different CRSs will result into a reprojection from the original CRS of the granules to that common CRS.

                      Since 2.17, a new parameter has been defined: minimizeReprojections

                      It will be used on Raster Download with a defined ROI and a TargetCRS being specified. When set to true, any Granule in the ROI having a nativeCRS matching the TargetCRS will not be affected by reprojection.

                      Since 2.17, a new parameter has been defined: bestResolutionOnMatchingCRS

                      It will be used when minimizeReprojections is enabled too, on Raster Download with a defined ROI and a TargetCRS, without target size being specified. When set to true, the download will aim to preserve the native properties of the underlying granules matching the targetCRS, as much as possible.

                      Back to the example, a RasterDownload specifying UTM32N as TargetCRS and a ROI covering an area containing UTM32N granules will result into getting those UTM32N granules without applying any intermediate reprojection, also providing back best raw resolution available for that CRS. So, if the ImageMosaic is a mix of UTM32N DEMs at 10 km resolution and UTM33N at 100 m resolution, the underlying reading request will use 10 km resolution, being the best resolution available in the targetCRS. When no granules are matching the targetCRS, the best resolution is taken from all the granules.

                      Make sure to configure the ImageMosaic's index to contain both crs and resolution attributes, in order to preserve as much as possible the native properties of the granules.

                      A typical indexer.properties of such ImageMosaic will look like this:

                      GranuleAcceptors=org.geotools.gce.imagemosaic.acceptors.HeterogeneousCRSAcceptorFactory\nGranuleHandler=org.geotools.gce.imagemosaic.granulehandler.ReprojectingGranuleHandlerFactory\nHeterogeneousCRS=true\nMosaicCRS=EPSG\\:XXXX\nSchema=*the_geom:Polygon,location:String,crs:String,resX:double,resY:double\nResolutionXAttribute=resX\nResolutionYAttribute=resY\nCrsAttribute=crs\nPropertyCollectors=CRSExtractorSPI(crs),ResolutionXExtractorSPI(resX),ResolutionYExtractorSPI(resY)\n
                      "},{"location":"extensions/wps-download/rawDownload/#vertical_resampling","title":"Vertical data resampling on download","text":"

                      Coverages containing elevations data (i.e. DTM/DEM/DSM) have pixel values representing elevations/heights referred to a specific VerticalCRS.

                      The associated VerticalCRS can be specified in the layer configuration, at the very bottom of the page, where a new optional Vertical Coordinate Reference System section shows up.

                      The following example shows a DSM layer being configured to specify EPSG:5778 as adopted VerticalCRS.

                      This section will only show up if:

                      • The wps-download module has been deployed in GeoServer
                      • The underlying data is single-band and datatype is at least 16 bit. (i.e.: no Byte datatype, no RGB images, ...)
                      "},{"location":"extensions/wps-download/rawDownload/#wps-download-vertical-resampling","title":"WPS Download - Vertical resampling","text":"

                      Resampling the data to a different VerticalCRS as part of the Raster Download Process is possible by specifying the targetVerticalCRS parameter in the WPS Download request. For example:

                      <wps:Input>\n  <ows:Identifier>targetVerticalCRS</ows:Identifier>\n  <wps:Data>\n    <wps:LiteralData>EPSG:9274</wps:LiteralData>\n  </wps:Data>\n</wps:Input>\n

                      Note

                      An exception will be thrown when specifying a targetVerticalCRS but no source VerticalCRS has been assigned to the requested layer through the above setting.

                      "},{"location":"extensions/wps-download/rawDownload/#custom-verticalcrs-definitions-and-grid-transformations","title":"Custom VerticalCRS definitions and grid transformations","text":"

                      Custom verticalCRS definitions can be specified in GeoServer via properties file as any other Coordinate Reference System, as explained in Custom CRS Definitions page.

                      This is an example of the above VerticalCRS being added as a WKT in the user_projections/epsg.properties file:

                      9274=VERT_CS[\"EVRF2000 Austria height\", \\\n   VERT_DATUM[\"European Vertical Reference Frame 2000 Austria\", \\\n     2000, AUTHORITY[\"EPSG\",\"1261\"]], \\\n   AXIS[\"gravity-related height (H)\",up], \\\n   UNIT[\"m\",1.0], \\\nAUTHORITY[\"EPSG\",\"9274\"]]\n

                      Transformations between VerticalCRSs can be supported through Vertical Grid Offset files (similarly to how NTV2 Grid Shift can be used in support of 2D grid transformation).

                      Custom Coordinate Operations are defined in user_projections/epsg_operations.properties file within the data directory (create it if it doesn't exist).

                      Each line in epsg_operations.properties will describe a coordinate operation consisting of a source CRS, a target CRS, and a math transform with its parameter values. Use the following syntax:

                      <source crs code>,<target crs code>=<WKT math transform>\n

                      The Math Transform is a Vertical Offset by Grid Interpolation requiring 2 parameters:

                      1. A Vertical offset file referring an offset file containing a vertical offset for each pixel of the grid. The referred file need to be available in the user_projections directory,
                      2. An Interpolation CRS code containing the EPSG code of the 2D CoordinateReferenceSystem of the grid file.
                      "},{"location":"extensions/wps-download/rawDownload/#example","title":"Example","text":"

                      Custom Vertical Grid Shift file for the transformation between the above Vertical CRSs :

                      5778,9274=PARAM_MT[\"Vertical Offset by Grid Interpolation\", \\\nPARAMETER[\"Vertical offset file\", \"GV_Hoehengrid_V1.tif\"], \\\nPARAMETER[\"Interpolation CRS code\", 4312]]\n

                      Note

                      Only GeoTIFF vertical offset files are supported at the moment. Vertical resampling will access pixels from that GeoTIFF using tiled loading. Therefore, make sure that the grid file is not striped (a gdalinfo call reporting Band 1 Block = NNN x 1 means a striped file. In that case, consider retiling it for better access before using it as a Vertical Offset File)

                      "},{"location":"extensions/wps-jdbc/","title":"WPS JDBC","text":"

                      The WPS JDBC extension is a WPS status storage for asynchronous requests. Main advantages are:

                      • Asynchronous request status sharing among multiple GeoServer nodes
                      • Ability to retain the status of completed requests even after the GeoServer(s) have been restarted.
                      "},{"location":"extensions/wps-jdbc/#wpsjdbc_install","title":"Installing the WPS JDBC extension","text":"
                      1. From the website download page, locate your release, and download: wps-jdbc

                        Verify that the version number in the filename corresponds to the version of GeoServer you are running (for example 2.24.2 above).

                      2. Extract the contents of the archive into the WEB-INF/lib directory in GeoServer. Make sure you do not create any sub-directories during the extraction process.

                      3. Restart GeoServer.

                      "},{"location":"extensions/wps-jdbc/#configuring-the-wps-jdbc-properties","title":"Configuring the WPS JDBC properties","text":"
                      1. Create a file named jdbcstatusstore.props into the GEOSERVER_DATA_DIR root

                      2. Update the sample content below accordingly to your connection parameters

                        user=postgres\nport=5432\npassword=******\npasswd=******\nhost=localhost\ndatabase=gsstore\ndriver=org.postgresql.Driver\ndbtype=postgis\n
                      3. Restart GeoServer

                      "},{"location":"extensions/wps-jdbc/#share-the-wps-execution-directory-among-the-cluster-nodes","title":"Share the WPS Execution Directory among the cluster nodes","text":"

                      Typically the WPS JDBC plugin is useful when setting up a GeoServer cluster.

                      The plugin allows sharing of the execution status among the nodes of the cluster.

                      Nevertheless, this won't be sufficient. You will need to share the Execution folder too, in order to allow the different instances to correctly retrieve the executions results.

                      1. Create a shared folder that all the nodes can reach somehow, e.g. by using nfs
                      2. From the GeoServer Admin dashboard, go to the WPS menu and edit the Resource Storage Directory accordingly

                      WPS JDBC shared Resource Storage Directory

                      "},{"location":"filter/","title":"Filtering","text":"

                      Filtering allows selecting features that satisfy a specific set of conditions. Filters can be used in several contexts in GeoServer:

                      • in WMS requests, to select which features should be displayed on a map
                      • in WFS requests, to specify the features to be returned
                      • in SLD documents, to apply different symbolization to features on a thematic map.
                      • Supported filter languages
                      • Filter Encoding Reference
                      • ECQL Reference
                      • Filter functions
                      • Filter Function Reference
                      "},{"location":"filter/ecql_reference/","title":"ECQL Reference","text":"

                      This section provides a reference for the syntax of the ECQL language. The full language grammar is documented in the GeoTools ECQL BNF definition

                      "},{"location":"filter/ecql_reference/#syntax-notes","title":"Syntax Notes","text":"

                      The sections below describe the major language constructs. Each construct lists all syntax options for it. Each option is defined as a sequence of other constructs, or recursively in terms of itself.

                      • Symbols which are part of the ECQL language are shown in code font. All other symbols are part of the grammar description.
                      • ECQL keywords are not case-sensitive.
                      • A vertical bar symbol '|' indicates that a choice of keyword can be made.
                      • Brackets '[ ... ]' delimit syntax that is optional.
                      • Braces '{ ... }' delimit syntax that may be present zero or more times.
                      "},{"location":"filter/ecql_reference/#ecql_cond","title":"Condition","text":"

                      A filter condition is a single predicate, or a logical combination of other conditions.

                      Syntax Description

                      Predicate Single predicate expression

                      Condition AND | OR Condition Conjunction or disjunction of conditions

                      NOT Condition Negation of a condition

                      ( | [ Condition ] | ) Bracketing with ( or [ controls evaluation order

                      "},{"location":"filter/ecql_reference/#ecql_pred","title":"Predicate","text":"

                      Predicates are boolean-valued expressions which specify relationships between values.

                      Syntax Description

                      Expression = | <> | < | <= | > | >= Expression Comparison operations

                      Expression [ NOT ] BETWEEN Expression AND Expression Tests whether a value lies in or outside a range (inclusive)

                      Expression [ NOT ] LIKE | ILIKE like-pattern Simple pattern matching. like-pattern uses the % character as a wild-card for any number of characters. ILIKE does case-insensitive matching.

                      Attribute [ NOT ] IN ( Expression { ,Expression } ) Tests whether an attribute value is (not) in a set of values.

                      [ NOT ] IN ( Literal { ,Literal } ) Tests whether a feature ID value is (not) in a given set. ID values are integers or string literals

                      Expression IS [ NOT ] NULL Tests whether a value is (non-)null

                      Attribute EXISTS | DOES-NOT-EXIST Tests whether a featuretype does (not) have a given attribute

                      INCLUDE | EXCLUDE Always include (exclude) features to which this filter is applied

                      "},{"location":"filter/ecql_reference/#ecql_temp","title":"Temporal Predicate","text":"

                      Temporal predicates specify the relationship of a time-valued expression to a time or time period.

                      Syntax Description

                      ecql_expr BEFORE Time <ecql_reference.rst#ecql_literal>_ Tests whether a time value is before a point in time

                      Expression BEFORE OR DURING Time Period Tests whether a time value is before or during a time period

                      Expression DURING Time Period Tests whether a time value is during a time period

                      Expression DURING OR AFTER Time Period Tests whether a time value is during or after a time period

                      ecql_expr AFTER Time <ecql_reference.rst#ecql_literal>_ Tests whether a time value is after a point in time

                      "},{"location":"filter/ecql_reference/#ecql_spat","title":"Spatial Predicate","text":"

                      Spatial predicates specify the relationship between geometric values. Topological spatial predicates (INTERSECTS, DISJOINT, CONTAINS, WITHIN, TOUCHES CROSSES, OVERLAPS and RELATE) are defined in terms of the DE-9IM model described in the OGC Simple Features for SQL specification.

                      Syntax Description

                      INTERSECTS(Expression , Expression ) Tests whether two geometries intersect. The converse of DISJOINT

                      DISJOINT(Expression , Expression ) Tests whether two geometries are disjoint. The converse of INTERSECTS

                      CONTAINS(Expression , Expression ) Tests whether the first geometry topologically contains the second. The converse of WITHIN

                      WITHIN(Expression , Expression ) Tests whether the first geometry is topologically within the second. The converse of CONTAINS

                      TOUCHES(Expression , Expression ) Tests whether two geometries touch. Geometries touch if they have at least one point in common, but their interiors do not intersect.

                      CROSSES(Expression , Expression ) Tests whether two geometries cross. Geometries cross if they have some but not all interior points in common

                      OVERLAPS(Expression , Expression ) Tests whether two geometries overlap. Geometries overlap if they have the same dimension, have at least one point each not shared by the other, and the intersection of the interiors of the two geometries has the same dimension as the geometries themselves

                      EQUALS(Expression , Expression ) Tests whether two geometries are topologically equal

                      RELATE( Expression , Expression , pattern ) Tests whether geometries have the spatial relationship specified by a DE-9IM matrix pattern. A DE-9IM pattern is a string of length 9 specified using the characters *TF012. Example: '1*T***T**'

                      DWITHIN( Expression , Expression , distance , units ) Tests whether the distance between two geometries is no more than the specified distance. distance is an unsigned numeric value for the distance tolerance. units is one of feet, meters, statute miles, nautical miles, kilometers

                      BEYOND( Expression , Expression , distance , units ) Similar to DWITHIN, but tests whether the distance between two geometries is greater than the given distance.

                      BBOX ( Expression , Number , Number , Number , Number [ , CRS ] ) Tests whether a geometry intersects a bounding box specified by its minimum and maximum X and Y values. The optional CRS is a string containing an SRS code (For example, 'EPSG:1234'. The default is to use the CRS of the queried layer)

                      "},{"location":"filter/ecql_reference/#ecql_expr","title":"Expression","text":"

                      An expression specifies a attribute, literal, or computed value. The type of the value is determined by the nature of the expression. The standard PEMDAS order of evaluation is used.

                      Syntax Description

                      Attribute Name of a feature attribute

                      Literal Literal value

                      Expression + | - | * | / Expression Arithmetic operations

                      function ( [ Expression { , Expression } ] ) Value computed by evaluation of a filter function with zero or more arguments.

                      ( | [ Expression ] | ) Bracketing with ( or ```` controls evaluation order

                      "},{"location":"filter/ecql_reference/#ecql_attr","title":"Attribute","text":"

                      An attribute name denotes the value of a feature attribute.

                      • Simple attribute names are sequences of letters and numbers, e.g. [States123``
                      • Attribute names quoted with double-quotes may be any sequence of characters, e.g. \\\"States!@#\\\"
                      • Note: id is one of a few reserved keywords in ECQL and thus an attribute (or database column) named id must be quoted, e.g. \\\"id\\\"
                      "},{"location":"filter/ecql_reference/#ecql_literal","title":"Literal","text":"

                      Literals specify constant values of various types.

                      Type Description

                      Number Integer or floating-point number. Scientific notation is supported.

                      Boolean TRUE or FALSE

                      String String literal delimited by single quotes. To include a single quote in the string use two single-quotes: ''

                      Geometry Geometry in WKT or EWKT format. WKT is defined in the OGC Simple Features for SQL specification. All standard geometry types are supported: POINT, LINESTRING, POLYGON, MULTIPOINT, MULTILINESTRING, MULTIPOLYGON, GEOMETRYCOLLECTION. EWKT allows specifying a geometry spatial reference system by prefixing it with a numerical code, in the form SRID=number;WKT, for example, SRID=4326;POINT (1 2). A custom type of Envelope is also supported with syntax ENVELOPE ( x1 x2 y1 y2 ).

                      Time A UTC date/time value in the format yyyy-mm-hhThh:mm:ss. The seconds value may have a decimal fraction. The time zone may be specified as Z or +/-hh:mm. Example: 2006-11-30T00:30:00Z

                      Duration A time duration specified as P [ y Y m M d D ] T [ h H m M s S ]. The duration can be specified to any desired precision by including only the required year, month, day, hour, minute and second components. Examples: P1Y2M, P4Y2M20D, P4Y2M1DT20H3M36S

                      "},{"location":"filter/ecql_reference/#ecql_period","title":"Time Period","text":"

                      Specifies a period of time, in several different formats.

                      Syntax Description

                      Time / Time Period specified by a start and end time

                      Duration / Time Period specified by a duration before a given time

                      Time / Duration Period specified by a duration after a given time

                      "},{"location":"filter/filter_reference/","title":"Filter Encoding Reference","text":"

                      This is a reference for the Filter Encoding language implemented in GeoServer. The Filter Encoding language uses an XML-based syntax. It is defined by the OGC Filter Encoding standard.

                      Filters are used to select features or other objects from the context in which they are evaluated. They are similar in functionality to the SQL \"WHERE\" clause. A filter is specified using a condition.

                      "},{"location":"filter/filter_reference/#filter_condition","title":"Condition","text":"

                      A condition is a single Predicate element, or a combination of conditions by Logical operators.

                      "},{"location":"filter/filter_reference/#filter_predicate","title":"Predicate","text":"

                      Predicates are boolean-valued expressions which compute relationships between values. A predicate is specified by using a comparison operator or a spatial operator. The operators are used to compare properties of the features being filtered to other feature properties or to literal data.

                      "},{"location":"filter/filter_reference/#comparison-operators","title":"Comparison operators","text":"

                      Comparison operators are used to specify conditions on non-spatial attributes.

                      "},{"location":"filter/filter_reference/#binary-comparison-operators","title":"Binary Comparison operators","text":"

                      The binary comparison operators are:

                      • <PropertyIsEqualTo>
                      • <PropertyIsNotEqualTo>
                      • <PropertyIsLessThan>
                      • <PropertyIsLessThanOrEqualTo>
                      • <PropertyIsGreaterThan>
                      • <PropertyIsGreaterThanOrEqualTo>

                      They contain the elements:

                      Element Required? Description

                      Expression Yes The first value to compare. Often a <PropertyName>.

                      Expression Yes The second value to compare

                      Binary comparison operator elements may include an optional matchCase attribute, with the value true or false. If this attribute is true (the default), string comparisons are case-sensitive. If the attribute is false strings comparisons do not check case.

                      "},{"location":"filter/filter_reference/#propertyislike-operator","title":"PropertyIsLike operator","text":"

                      The <PropertyIsLike> operator matches a string property value against a text pattern. It contains the elements:

                      Element Required? Description

                      <PropertyName> Yes Contains a string specifying the name of the property to test

                      <Literal> Yes Contains a pattern string to be matched

                      The pattern is specified by a sequence of regular characters and three special pattern characters. The pattern characters are defined by the following required attributes of the <PropertyIsLike> element:

                      • wildCard specifies the pattern character which matches any sequence of zero or more string characters
                      • singleChar specifies the pattern character which matches any single string character
                      • escapeChar specifies the escape character which can be used to escape the pattern characters
                      "},{"location":"filter/filter_reference/#propertyisnull-operator","title":"PropertyIsNull operator","text":"

                      The <PropertyIsNull> operator tests whether a property value is null. It contains the element:

                      Element Required? Description

                      <PropertyName> Yes contains a string specifying the name of the property to be tested

                      "},{"location":"filter/filter_reference/#propertyisbetweeen-operator","title":"PropertyIsBetweeen operator","text":"

                      The <PropertyIsBetween> operator tests whether an expression value lies within a range given by a lower and upper bound (inclusive). It contains the elements:

                      Element Required? Description

                      Expression Yes The value to test

                      <LowerBoundary> Yes Contains an Expression giving the lower bound of the range

                      <UpperBoundary> Yes Contains an Expression giving the upper bound of the range

                      "},{"location":"filter/filter_reference/#spatial-operators","title":"Spatial operators","text":"

                      Spatial operators are used to specify conditions on the geometric attributes of a feature. The following spatial operators are available:

                      "},{"location":"filter/filter_reference/#topological-operators","title":"Topological operators","text":"

                      These operators test topological spatial relationships using the standard OGC Simple Features predicates:

                      • <Intersects> - Tests whether two geometries intersect
                      • <Disjoint> - Tests whether two geometries are disjoint (do not interact)
                      • <Contains> - Tests whether a geometry contains another one
                      • <Within> - Tests whether a geometry is within another one
                      • <Touches> - Tests whether two geometries touch
                      • <Crosses> - Tests whether two geometries cross
                      • <Overlaps> - Tests whether two geometries overlap
                      • <Equals> - Tests whether two geometries are topologically equal

                      These contains the elements:

                      Element Required? Description

                      <PropertyName> Yes Contains a string specifying the name of the geometry-valued property to be tested.

                      GML Geometry Yes A GML literal value specifying the geometry to test against

                      "},{"location":"filter/filter_reference/#distance-operators","title":"Distance operators","text":"

                      These operators test distance relationships between a geometry property and a geometry literal:

                      • <DWithin>
                      • <Beyond>

                      They contain the elements:

                      Element Required? Description

                      <PropertyName> Yes Contains a string specifying the name of the property to be tested. If omitted, the default geometry attribute is assumed.

                      GML Geometry Yes A literal value specifying a geometry to compute the distance to. This may be either a geometry or an envelope in GML 3 format

                      <Distance> Yes Contains the numeric value for the distance tolerance. The element may include an optional units attribute.

                      "},{"location":"filter/filter_reference/#bounding-box-operator","title":"Bounding Box operator","text":"

                      The <BBOX> operator tests whether a geometry-valued property intersects a fixed bounding box. It contains the elements:

                      Element Required? Description

                      <PropertyName> No Contains a string specifying the name of the property to be tested. If omitted, the default geometry attribute is assumed.

                      <gml:Box> Yes A GML Box literal value specifying the bounding box to test against

                      "},{"location":"filter/filter_reference/#examples","title":"Examples","text":"
                      • This filter selects features with a geometry that intersects the point (1,1).
                      <Intersects>\n  <PropertyName>GEOMETRY</PropertyName>\n  <gml:Point>\n    <gml:coordinates>1 1</gml:coordinates>\n  </gml:Point>\n</Intersects>\n
                      • This filter selects features with a geometry that overlaps a polygon.
                      <Overlaps>\n  <PropertyName>Geometry</PropertyName>\n  <gml:Polygon srsName=\"http://www.opengis.net/gml/srs/epsg.xml#63266405\">\n    <gml:outerBoundaryIs>\n      <gml:LinearRing>\n         <gml:posList> ... </gml:posList>\n      </gml:LinearRing>\n    </gml:outerBoundaryIs>\n  </gml:Polygon>\n </Overlaps>\n
                      • This filter selects features with a geometry that intersects the geographic extent [-10,0 : 10,10].
                      <BBOX>\n  <PropertyName>GEOMETRY</PropertyName>\n  <gml:Box srsName=\"urn:x-ogc:def:crs:EPSG:4326\">\n    <gml:coord>\n      <gml:X>-10</gml:X> <gml:Y>0</gml:Y>\n    </gml:coord>\n    <gml:coord>\n      <gml:X>10</gml:X> <gml:Y>10</gml:Y>\n    </gml:coord>\n  </gml:Box>\n</BBOX>\n
                      "},{"location":"filter/filter_reference/#filter_logical","title":"Logical operators","text":"

                      Logical operators are used to specify logical combinations of Condition elements (which may be either Predicate elements or other logical operators). They may be nested to any depth.

                      The following logical operators are available:

                      • <And> - computes the logical conjunction of the operands
                      • <Or> - computes the logical disjunction of the operands

                      The content for <And> and <Or> is two operands given by Condition elements.

                      • <Not> - computes the logical negation of the operand

                      The content for <Not> is a single operand given by a Condition element.

                      "},{"location":"filter/filter_reference/#examples_1","title":"Examples","text":"
                      • This filter uses <And> to combine a comparison predicate and a spatial predicate:
                      <And>\n   <PropertyIsEqualTo>\n      <PropertyName>NAME</PropertyName>\n      <Literal>New York</Literal>\n   </PropertyIsEqualTo>\n   <Intersects>\n      <PropertyName>GEOMETRY</PropertyName>\n      <Literal>\n         <gml:Point>\n             <gml:coordinates>1 1</gml:coordinates>\n         </gml:Point>\n      </Literal>\n   </Intersects>\n</And>\n
                      "},{"location":"filter/filter_reference/#filter_expression","title":"Expression","text":"

                      Filter expressions specify constant, variable or computed data values. An expression is formed from one of the following elements (some of which contain sub-expressions, meaning that expressions may be of arbitrary depth):

                      "},{"location":"filter/filter_reference/#arithmetic-operators","title":"Arithmetic operators","text":"

                      The arithmetic operator elements compute arithmetic operations on numeric values.

                      • <Add> - adds the two operands
                      • <Sub> - subtracts the second operand from the first
                      • <Mul> - multiplies the two operands
                      • <Div> - divides the first operand by the second

                      Each arithmetic operator element contains two Expression elements providing the operands.

                      "},{"location":"filter/filter_reference/#function","title":"Function","text":"

                      The <Function> element specifies a filter function to be evaluated. The required name attribute gives the function name. The element contains a sequence of zero or more Expression elements providing the values of the function arguments.

                      See the Filter Function Reference for details of the functions provided by GeoServer.

                      "},{"location":"filter/filter_reference/#property-value","title":"Property Value","text":"

                      The <PropertyName> element refers to the value of a feature attribute. It contains a string or an XPath expression specifying the attribute name.

                      "},{"location":"filter/filter_reference/#literal","title":"Literal","text":"

                      The <Literal> element specifies a constant value. It contains data of one of the following types:

                      Type Description

                      Numeric A string representing a numeric value (integer or decimal).

                      Boolean A boolean value of true or false.

                      String A string value. XML-incompatible text may be included by using character entities or <![CDATA[ ]]> delimiters.

                      Date A string representing a date.

                      Geometry An element specifying a geometry in GML3 format.

                      "},{"location":"filter/filter_reference/#wfs-20-namespaces","title":"WFS 2.0 namespaces","text":"

                      WFS 2.0 does not depend on any one GML version and thus requires an explicit namespace and schemaLocation for GML. In a GET request, namespaces can be placed on a Filter element (that is, filter= the block below, URL-encoded):

                      <fes:Filter\n        xmlns:fes=\"http://www.opengis.net/fes/2.0\"\n        xmlns:gml=\"http://www.opengis.net/gml/3.2\">\n    <fes:Not>\n        <fes:Disjoint>\n            <fes:ValueReference>sf:the_geom</fes:ValueReference>\n            <gml:Polygon\n                    gml:id=\"polygon.1\"\n                    srsName='http://www.opengis.net/def/crs/EPSG/0/26713'>\n                <gml:exterior>\n                    <gml:LinearRing>\n                        <gml:posList>590431 4915204 590430\n                            4915205 590429 4915204 590430\n                            4915203 590431 4915204</gml:posList>\n                    </gml:LinearRing>\n                </gml:exterior>\n            </gml:Polygon>\n        </fes:Disjoint>\n    </fes:Not>\n</fes:Filter>\n
                      "},{"location":"filter/function/","title":"Filter functions","text":"

                      The OGC Filter Encoding specification provides a generic concept of a filter function. A filter function is a named function with any number of arguments, which can be used in a filter expression to perform specific calculations. This provides much richer expressiveness for defining filters. Filter functions can be used in both the XML Filter Encoding language and the textual ECQL language, using the syntax appropriate to the language.

                      GeoServer provides many different kinds of filter functions, covering a wide range of functionality including mathematics, string formatting, and geometric operations. A complete list is provided in the Filter Function Reference.

                      Note

                      The Filter Encoding specification provides a standard syntax for filter functions, but does not mandate a specific set of functions. Servers are free to provide whatever functions they want, so some function expressions may work only in specific software.

                      "},{"location":"filter/function/#examples","title":"Examples","text":"

                      The following examples show how filter functions are used. The first shows enhanced WFS filtering using the geometryType function. The second shows how to use functions in SLD to get improved label rendering.

                      "},{"location":"filter/function/#wfs-filtering","title":"WFS filtering","text":"

                      Let's assume we have a feature type whose geometry field, geom, can contain any kind of geometry. For a certain application we need to extract only the features whose geometry is a simple point or a multipoint. This can be done using a GeoServer-specific filter function named geometryType. Here is the WFS request including the filter function:

                      <wfs:GetFeature service=\"WFS\" version=\"1.0.0\"\n  outputFormat=\"GML2\"\n  xmlns:wfs=\"http://www.opengis.net/wfs\"\n  xmlns:ogc=\"http://www.opengis.net/ogc\"\n  xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\"\n  xsi:schemaLocation=\"http://www.opengis.net/wfs\n                      http://schemas.opengis.net/wfs/1.0.0/WFS-basic.xsd\">\n  <wfs:Query typeName=\"sf:archsites\">\n    <ogc:Filter>\n       <ogc:PropertyIsEqualTo>\n          <ogc:Function name=\"geometryType\">\n             <ogc:PropertyName>geom</ogc:PropertyName>\n          </ogc:Function>\n          <ogc:Literal>Point</ogc:Literal>\n       </ogc:PropertyIsEqualTo>\n    </ogc:Filter>\n    </wfs:Query>\n</wfs:GetFeature>\n
                      "},{"location":"filter/function/#wfs-20-namespaces","title":"WFS 2.0 namespaces","text":"

                      WFS 2.0 does not depend on any one GML version and thus requires an explicit namespace and schemaLocation for GML. This POST example selects features using a spatial query. Note the complete declaration of namespace prefixes. In a GET request, namespaces can be placed on a Filter element.

                      <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<wfs:GetFeature service=\"WFS\" version=\"2.0.0\"\n    xmlns:wfs=\"http://www.opengis.net/wfs/2.0\"\n    xmlns:fes=\"http://www.opengis.net/fes/2.0\"\n    xmlns:gml=\"http://www.opengis.net/gml/3.2\"\n    xmlns:sf=\"http://www.openplans.org/spearfish\"\n    xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\"\n    xsi:schemaLocation=\"http://www.opengis.net/wfs/2.0\n                        http://schemas.opengis.net/wfs/2.0/wfs.xsd\n                        http://www.opengis.net/gml/3.2\n                        http://schemas.opengis.net/gml/3.2.1/gml.xsd\">\n    <wfs:Query typeNames=\"sf:bugsites\">\n        <fes:Filter>\n            <fes:Not>\n                <fes:Disjoint>\n                    <fes:ValueReference>sf:the_geom</fes:ValueReference>\n                    <!-- gml:id is mandatory on GML 3.2 geometry elements -->\n                    <gml:Polygon\n                            gml:id=\"polygon.1\"\n                            srsName='http://www.opengis.net/def/crs/EPSG/0/26713'>\n                        <gml:exterior>\n                            <gml:LinearRing>\n                                <!-- pairs must form a closed ring -->\n                                <gml:posList>590431 4915204 590430\n                                    4915205 590429 4915204 590430\n                                    4915203 590431 4915204</gml:posList>\n                            </gml:LinearRing>\n                        </gml:exterior>\n                    </gml:Polygon>\n                </fes:Disjoint>\n            </fes:Not>\n        </fes:Filter>\n    </wfs:Query>\n</wfs:GetFeature>\n
                      "},{"location":"filter/function/#sld-formatting","title":"SLD formatting","text":"

                      We want to display elevation labels in a contour map. The elevations are stored as floating point values, so the raw numeric values may display with unwanted decimal places (such as \"150.0\" or \"149.999999\"). We want to ensure the numbers are rounded appropriately (i.e. to display \"150\"). To achieve this the numberFormat filter function can be used in the SLD label content expression:

                      ...\n<TextSymbolizer>\n  <Label>\n    <ogc:Function name=\"numberFormat\">\n      <ogc:Literal>##</ogc:Literal>\n      <ogc:PropertyName>ELEVATION</ogc:PropertyName>\n    </ogc:Function>\n  </Label>\n  ...\n</TextSymbolizer>\n...\n
                      "},{"location":"filter/function/#performance-implications","title":"Performance implications","text":"

                      Using filter functions in SLD symbolizer expressions does not have significant overhead, unless the function is performing very heavy computation.

                      However, using functions in WFS filtering or SLD rule expressions may cause performance issues in certain cases. This is usually because specific filter functions are not recognized by a native data store filter encoder, and thus GeoServer must execute the functions in memory instead.

                      For example, given a filter like BBOX(geom,-10,30,20,45) and geometryType(geom) = 'Point' most data stores will split the filter into two separate parts. The bounding box filter will be encoded as a primary filter and executed in SQL, while the geometryType function will be executed in memory on the results coming from the primary filter.

                      "},{"location":"filter/function_reference/","title":"Filter Function Reference","text":"

                      This reference describes all filter functions that can be used in WFS/WMS filtering or in SLD expressions.

                      The list of functions available on a GeoServer instance can be determined by browsing to http://localhost:8080/geoserver/wfs?request=GetCapabilities and searching for ogc:Function_Names (WFS 1.0.0), ogc:FunctionNames (WFS 1.1.0), or fes:Functions (WFS 2.0.0) in the returned XML. If a function is described in the Capabilities document but is not in this reference, then it might mean that the function cannot be used for filtering, or that it is new and has not been documented. Ask for details on the user mailing list.

                      Unless otherwise specified, none of the filter functions in this reference are understood natively by the data stores, and thus expressions using them will be evaluated in-memory.

                      "},{"location":"filter/function_reference/#function-argument-type-reference","title":"Function argument type reference","text":"

                      Type Description

                      Double Floating point number, 8 bytes, IEEE 754. Ranges from 4.94065645841246544e-324d to 1.79769313486231570e+308d

                      Float Floating point number, 4 bytes, IEEE 754. Ranges from 1.40129846432481707e-45 to 3.40282346638528860e+38. Smaller range and less accurate than Double.

                      Integer Integer number, ranging from -2,147,483,648 to 2,147,483,647

                      Long Integer number, ranging from -9,223,372,036,854,775,808 to +9,223,372,036,854,775,807

                      Number A numeric value of any type

                      Object A value of any type

                      String A sequence of characters

                      Timestamp Date and time information

                      "},{"location":"filter/function_reference/#comparison-functions","title":"Comparison functions","text":"

                      Name Arguments Description

                      between num:Number, low:Number, high:Number returns true if low <= num <= high

                      equalTo a:Object, b:Object Can be used to compare for equality two numbers, two strings, two dates, and so on

                      greaterEqualThan x:Object, y:Object Returns true if x >= y. Parameters can be either numbers or strings (in the second case lexicographic ordering is used)

                      greaterThan x:Object, y:Object Returns true if x > y. Parameters can be either numbers or strings (in the second case lexicographic ordering is used)

                      in2, in3, in4, in5, in6, in7, in8, in9, in10 candidate:Object, v1:Object, ..., v9:Object Returns true if candidate is equal to one of the v1, ..., v9 values. Use the function name matching the number of arguments specified.

                      in candidate:Object, v1:Object, v2:Object, ... Works exactly the same as the in2, ..., in10 functions described above, but takes any number of values as input.

                      isLike string:String, pattern:String Returns true if the string matches the specified pattern. For the full syntax of the pattern specification see the Java Pattern class javadocs

                      isNull obj:Object Returns true the passed parameter is null, false otherwise

                      lessThan x:Object, y:Object Returns true if x < y. Parameters can be either numbers or strings (in the second case lexicographic ordering is used

                      lessEqualThan x:Object, y:Object Returns true if x <= y. Parameters can be either numbers or strings (in the second case lexicographic ordering is used

                      not bool:Boolean Returns the negation of bool

                      notEqualTo x:Object, y:Object Returns true if x and y are equal, false otherwise

                      "},{"location":"filter/function_reference/#control-functions","title":"Control functions","text":"

                      Name Arguments Description

                      if_then_else condition:Boolean, x:Object, y: Object Returns x if the condition is true, y otherwise

                      "},{"location":"filter/function_reference/#environment-function","title":"Environment function","text":"

                      This function returns the value of environment variables defined in various contexts. WMS GetMap automatically defines some variables SLD rendering, while others can be provided using the env request parameter. Example usage in e.g. a dynamic symbolizer:

                      ${env('size', 20)}

                      Example usage in a default Symbolizer:

                      <PointSymbolizer uom=\"http://www.opengeospatial.org/se/units/metre\">\n  <Graphic>\n  ...\n    <Size>\n      <ogc:Function name=\"env\">\n        <ogc:Literal>size</ogc:Literal>\n        <ogc:Literal>20</ogc:Literal>\n      </ogc:Function>\n    </Size>\n  </Graphic>\n</PointSymbolizer>\n

                      Name Arguments Description

                      env variable:String Returns the value of the environment variable variable.

                      "},{"location":"filter/function_reference/#feature-functions","title":"Feature functions","text":"

                      Name Arguments Description

                      id feature:Feature returns the identifier of the feature

                      PropertyExists f:Feature, propertyName:String Returns true if f has a property named propertyName

                      property f:Feature, propertyName:String Returns the value of the property propertyName. Allows property names to be computed or specified by Variable substitution in SLD.

                      mapGet f:Feature, map:Map, key:String Get the value of the map map related to the specified key.

                      "},{"location":"filter/function_reference/#spatial-relationship-functions","title":"Spatial Relationship functions","text":"

                      For more information about the precise meaning of the spatial relationships consult the OGC Simple Feature Specification for SQL

                      Name Arguments Description

                      contains a:Geometry, b:Geometry Returns true if the geometry a contains b

                      crosses a:Geometry, b:Geometry Returns true if a crosses b

                      disjoint a:Geometry, b:Geometry Returns true if the two geometries are disjoint, false otherwise

                      equalsExact a:Geometry, b:Geometry Returns true if the two geometries are exactly equal, same coordinates in the same order

                      equalsExactTolerance a:Geometry, b:Geometry, tol:Double Returns true if the two geometries are exactly equal, same coordinates in the same order, allowing for a tol distance in the corresponding points

                      intersects a:Geometry, b:Geometry Returns true if a intersects b

                      isWithinDistance a: Geometry, b:Geometry, distance: Double Returns true if the distance between a and b is less than distance (measured as an euclidean distance)

                      overlaps a: Geometry, b:Geometry Returns true a overlaps with b

                      relate a: Geometry, b:Geometry Returns the DE-9IM intersection matrix for a and b

                      relatePattern a: Geometry, b:Geometry, pattern:String Returns true if the DE-9IM intersection matrix for a and b matches the specified pattern

                      touches a: Geometry, b: Geometry Returns true if a touches b according to the SQL simple feature specification rules

                      within a: Geometry, b:Geometry Returns true is fully contained inside b

                      "},{"location":"filter/function_reference/#geometric-functions","title":"Geometric functions","text":"

                      Name Arguments Description

                      area geometry:Geometry The area of the specified geometry. Works in a Cartesian plane, the result will be in the same unit of measure as the geometry coordinates (which also means the results won't make any sense for geographic data)

                      boundary geometry:Geometry Returns the boundary of a geometry

                      boundaryDimension geometry:Geometry Returns the number of dimensions of the geometry boundary

                      buffer geometry:Geometry, distance:Double Returns the buffered area around the geometry using the specified distance

                      bufferWithSegments geometry:Geometry, distance:Double, segments:Integer Returns the buffered area around the geometry using the specified distance and using the specified number of segments to represent a quadrant of a circle.

                      centroid geometry:Geometry Returns the centroid of the geometry. Can be often used as a label point for polygons, though there is no guarantee it will actually lie inside the geometry

                      convexHull geometry:Geometry Returns the convex hull of the specified geometry

                      difference a:Geometry, b:Geometry Returns all the points that sit in a but not in b

                      dimension a:Geometry Returns the dimension of the specified geometry

                      distance a:Geometry, b:Geometry Returns the euclidean distance between the two geometries

                      endAngle line:LineString Returns the angle of the end segment of the linestring

                      endPoint line:LineString Returns the end point of the linestring

                      envelope geometry:geometry Returns the polygon representing the envelope of the geometry, that is, the minimum rectangle with sides parallels to the axis containing it

                      exteriorRing poly:Polygon Returns the exterior ring of the specified polygon

                      geometryType geometry:Geometry Returns the type of the geometry as a string. May be Point, MultiPoint, LineString, LinearRing, MultiLineString, Polygon, MultiPolygon, GeometryCollection

                      geomFromWKT wkt:String Returns the Geometry represented in the Well Known Text format contained in the wkt parameter

                      geomLength geometry:Geometry Returns the length/perimeter of this geometry (computed in Cartesian space)

                      getGeometryN collection:GeometryCollection, n:Integer Returns the n-th geometry inside the collection

                      getX p:Point Returns the x ordinate of p

                      getY p:Point Returns the y ordinate of p

                      getZ p:Point Returns the z ordinate of p

                      interiorPoint geometry:Geometry Returns a point that is either interior to the geometry, when possible, or sitting on its boundary, otherwise

                      interiorRingN polyg:Polygon, n:Integer Returns the n-th interior ring of the polygon

                      intersection a:Geometry, b:Geometry Returns the intersection between a and b. The intersection result can be anything including a geometry collection of heterogeneous, if the result is empty, it will be represented by an empty collection.

                      isClosed line: LineString Returns true if line forms a closed ring, that is, if the first and last coordinates are equal

                      isEmpty geometry:Geometry Returns true if the geometry does not contain any point (typical case, an empty geometry collection)

                      isometric geometry:Geometry, extrusion:Double Returns a MultiPolygon containing the isometric extrusions of all components of the input geometry. The extrusion distance is extrusion, expressed in the same unit as the geometry coordinates. Can be used to get a pseudo-3d effect in a map

                      isRing line:LineString Returns true if the line is actually a closed ring (equivalent to isRing(line) and isSimple(line))

                      isSimple line:LineString Returns true if the geometry self intersects only at boundary points

                      isValid geometry: Geometry Returns true if the geometry is topologically valid (rings are closed, holes are inside the hull, and so on)

                      numGeometries collection: GeometryCollection Returns the number of geometries contained in the geometry collection

                      numInteriorRing poly: Polygon Returns the number of interior rings (holes) inside the specified polygon

                      numPoint geometry: Geometry Returns the number of points (vertexes) contained in geometry

                      offset geometry: Geometry, offsetX:Double, offsetY:Double Offsets all points in a geometry by the specified X and Y offsets. Offsets are working in the same coordinate system as the geometry own coordinates.

                      pointN geometry: Geometry, n:Integer Returns the n-th point inside the specified geometry

                      startAngle line: LineString Returns the angle of the starting segment of the input linestring

                      startPoint line: LineString Returns the starting point of the input linestring

                      symDifference a: Geometry, b:Geometry Returns the symmetrical difference between a and b (all points that are inside a or b, but not both)

                      toWKT geometry: Geometry Returns the WKT representation of geometry

                      union a: Geometry, b:Geometry Returns the union of a and b (the result may be a geometry collection)

                      vertices geom: Geometry Returns a multi-point made with all the vertices of geom

                      "},{"location":"filter/function_reference/#math-functions","title":"Math functions","text":"

                      Name Arguments Description

                      abs value:Integer The absolute value of the specified Integer value

                      abs_2 value:Long The absolute value of the specified Long value

                      abs_3 value:Float The absolute value of the specified Float value

                      abs_4 value:Double The absolute value of the specified Double value

                      acos angle:Double Returns the arc cosine of an angle in radians, in the range of 0.0 through PI

                      asin angle:Double Returns the arc sine of an angle in radians, in the range of -PI / 2 through PI / 2

                      atan angle:Double Returns the arc tangent of an angle in radians, in the range of -PI/2 through PI/2

                      atan2 x:Double, y:Double Converts a rectangular coordinate (x, y) to polar (r, theta) and returns theta.

                      ceil x: Double Returns the smallest (closest to negative infinity) double value that is greater than or equal to x and is equal to a mathematical integer.

                      cos angle: Double Returns the cosine of an angle expressed in radians

                      double2bool x: Double Returns true if x is zero, false otherwise

                      exp x: Double Returns Euler's number e raised to the power of x

                      floor x: Double Returns the largest (closest to positive infinity) value that is less than or equal to x and is equal to a mathematical integer

                      IEEERemainder x: Double, y:Double Computes the remainder of x divided by y as prescribed by the IEEE 754 standard

                      int2bbool x: Integer Returns true if x is zero, false otherwise

                      int2ddouble x: Integer Converts x to a Double

                      log x: Integer Returns the natural logarithm (base e) of x

                      max, max_3, max_4 x1: Double, x2:Double, x3:Double, x4:Double Returns the maximum between x1, ..., x4

                      min, min_3, min_4 x1: Double, x2:Double, x3:Double, x4:Double Returns the minimum between x1, ..., x4

                      pi None Returns an approximation of pi, the ratio of the circumference of a circle to its diameter

                      pow base:Double, exponent:Double Returns the value of base raised to the power of exponent

                      random None Returns a Double value with a positive sign, greater than or equal to 0.0 and less than 1.0. Returned values are chosen pseudo-randomly with (approximately) uniform distribution from that range.

                      rint x:Double Returns the Double value that is closest in value to the argument and is equal to a mathematical integer. If two double values that are mathematical integers are equally close, the result is the integer value that is even.

                      round_2 x:Double Same as round, but returns a Long

                      round x:Double Returns the closest Integer to x. The result is rounded to an integer by adding \u00bd, taking the floor of the result, and casting the result to type Integer. In other words, the result is equal to the value of the expression (int)floor(a + 0.5)

                      roundDouble x:Double Returns the closest Long to x

                      sin angle: Double Returns the sine of an angle expressed in radians

                      tan angle:Double Returns the trigonometric tangent of angle expressed in radians

                      toDegrees angle:Double Converts an angle expressed in radians into degrees

                      toRadians angle:Double Converts an angle expressed in radians into degrees

                      "},{"location":"filter/function_reference/#string-functions","title":"String functions","text":"

                      String functions generally will accept any type of value for String arguments. Non-string values will be converted into a string representation automatically.

                      Name Arguments Description

                      Concatenate s1:String, s2:String, ... Concatenates any number of strings. Non-string arguments are allowed.

                      strAbbreviate sentence:String, lower:Integer, upper:Integer, append:String Abbreviates the sentence at first space beyond lower (or at upper if no space). Appends append if string is abbreviated.

                      strCapitalize sentence:String Fully capitalizes the sentence. For example, \"HoW aRe YOU?\" will be turned into \"How Are You?\"

                      strConcat a:String, b:String Concatenates the two strings into one

                      strDefaultIfBlank str:String, default:String returns default if str is empty, blank or null

                      strEndsWith string:String, suffix:String Returns true if string ends with suffix

                      strEqualsIgnoreCase a:String, b:String Returns true if the two strings are equal ignoring case considerations

                      strIndexOf string:String, substring:String Returns the index within this string of the first occurrence of the specified substring, or -1 if not found

                      strLastIndexOf string:String, substring:String Returns the index within this string of the last occurrence of the specified substring, or -1 if not found

                      strLength string:String Returns the string length

                      strMatches string:String, pattern:String Returns true if the string matches the specified regular expression. For the full syntax of the pattern specification see the Java Pattern class javadocs

                      strReplace string:String, pattern:String, replacement:String, global: boolean Returns the string with the pattern replaced with the given replacement text. If the global argument is true then all occurrences of the pattern will be replaced, otherwise only the first. For the full syntax of the pattern specification see the Java Pattern class javadocs

                      strStartsWith string:String, prefix:String Returns true if string starts with prefix

                      strStripAccents string:String Removes diacritics (\\~= accents) from a string. The case will not be altered.

                      strSubstring string:String, begin:Integer, end:Integer Returns a new string that is a substring of this string. The substring begins at the specified begin and extends to the character at index endIndex - 1 (indexes are zero-based).

                      strSubstringStart string:String, begin:Integer Returns a new string that is a substring of this string. The substring begins at the specified begin and extends to the last character of the string

                      strToLowerCase string:String Returns the lower case version of the string

                      strToUpperCase string:String Returns the upper case version of the string

                      strTrim string:String Returns a copy of the string, with leading and trailing blank-space omitted

                      "},{"location":"filter/function_reference/#parsing-and-formatting-functions","title":"Parsing and formatting functions","text":"

                      Name Arguments Description

                      dateFormat format:String, date:Timestamp Formats the specified date according to the provided format. The format syntax can be found in the Java SimpleDateFormat javadocs

                      dateParse format:String, dateString:String Parses a date from a dateString formatted according to the format specification. The format syntax can be found in the Java SimpleDateFormat javadocs

                      numberFormat format:String, number:Double, locale:String Formats the number according to the specified format using the default locale or the one provided as an optional argument. The format syntax can be found in the Java DecimalFormat javadocs

                      parseBoolean boolean:String Parses a string into a boolean. The empty string, f, 0.0 and 0 are considered false, everything else is considered true.

                      parseDouble number:String Parses a string into a double. The number can be expressed in normal or scientific form.

                      parseInt number:String Parses a string into an integer.

                      parseLong number:String Parses a string into a long integer

                      "},{"location":"filter/function_reference/#temporal-functions","title":"Temporal functions","text":"

                      Name Arguments Description

                      dateDifference a:Date, b:Date, timeUnits:String Computes the difference between two date (as a-b) and return a result in a specific time units. timeUnits is optional, representing the desired time units result. Default as milliseconds. Possible values are s (seconds), m (minutes), h (hours), d (days).

                      now None Returns the current time as a Date

                      "},{"location":"filter/function_reference/#transformation-functions","title":"Transformation functions","text":"

                      Transformation functions transform values from one data space into another. These functions provide a concise way to compute styling parameters from feature attribute values. See also Styling using Transformation Functions.

                      +-------------+----------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Name | Arguments | Description | +-------------+----------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Recode | lookupValue:Object, | Transforms a lookupValue from a set of discrete data values into another set of values. Any number of data/value pairs may be specified. | | | | | | | data:Object, value:Object, ... | | +-------------+----------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Categorize | lookupValue:Object, value:Object, | Transforms a continuous-valued attribute value into a set of discrete values. lookupValue and value must be an orderable type (typically numeric). The initial value is required. Any number of additional threshold/value pairs may be specified. belongsTo is optional, with the value succeeding or preceding. It defines which interval to use when the lookup value equals a threshold value. | | | | | | | threshold:Object, ... value:Object, | | | | | | | | belongsTo : String | | +-------------+----------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Interpolate | lookupValue:Numeric, | Transforms a continuous-valued attribute value into another continuous range of values. Any number of data/value pairs may be specified. mode is optional, with the value linear, cosine or cubic. It defines the interpolation algorithm to use. method is optional, with the value numeric or color. It defines whether the target values are numeric or RGB color specifications. | | | | | | | data:Numeric, value:Numeric or #RRGGBB, ... | | | | | | | | mode:String, method:String | | +-------------+----------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+

                      "},{"location":"filter/syntax/","title":"Supported filter languages","text":"

                      Data filtering in GeoServer is based on the concepts found in the OGC Filter Encoding Specification.

                      GeoServer accepts filters encoded in two different languages: Filter Encoding and Common Query Language.

                      "},{"location":"filter/syntax/#filter-encoding","title":"Filter Encoding","text":"

                      The Filter Encoding language is an XML-based method for defining filters. XML Filters can be used in the following places in GeoServer:

                      • in WMS GetMap requests, using the filter parameter
                      • in WFS GetFeature requests, using the filter parameter
                      • in SLD Rules, in the Filter element

                      The Filter Encoding language is defined by OGC Filter Encoding Standards:

                      • Filter Encoding 1.0 is used in WFS 1.0 and SLD 1.0
                      • Filter Encoding 1.1 is used in WFS 1.1
                      • Filter Encoding 2.0 is used in WFS 2.0
                      "},{"location":"filter/syntax/#cqlecql","title":"CQL/ECQL","text":"

                      CQL (Common Query Language) is a plain-text language created for the OGC Catalog specification. GeoServer has adapted it to be an easy-to-use filtering mechanism. GeoServer actually implements a more powerful extension called ECQL (Extended CQL), which allows expressing the full range of filters that OGC Filter 1.1 can encode. ECQL is accepted in many places in GeoServer:

                      • in WMS GetMap requests, using the cql_filter parameter
                      • in WFS GetFeature requests, using the cql_filter parameter
                      • in SLD dynamic symbolizers

                      The ECQL Reference describes the features of the ECQL language. The CQL and ECQL tutorial shows examples of defining filters.

                      The CQL and ECQL languages are defined in:

                      • OpenGIS Catalog Services Specification contains the standard definition of CQL
                      • ECQL Grammar is the grammar defining the GeoTools ECQL implementation
                      "},{"location":"geowebcache/","title":"GeoWebCache","text":"

                      GeoWebCache is a tiling server. It runs as a proxy between a map client and map server, caching (storing) tiles as they are requested, eliminating redundant request processing and thus saving large amounts of processing time. GeoWebCache is integrated with GeoServer, though it is also available as a standalone product for use with other map servers.

                      This section will discuss the version of GeoWebCache integrated with GeoServer. The first part will be show how GeoWebCache can be configured through the web admin interface, followed by a detailed discussion of the concepts of the.

                      For information about the standalone product, please see the GeoWebCache homepage.

                      • GeoWebCache settings
                      • Using GeoWebCache
                      • Configuration
                      • Seeding and refreshing
                      • HTTP Response Headers
                      • GeoWebCache REST API
                      • Troubleshooting
                      "},{"location":"geowebcache/config/","title":"Configuration","text":"

                      GeoWebCache is automatically configured for use with GeoServer using the most common options, with no setup required. All communication between GeoServer and GeoWebCache happens by passing messages inside the JVM.

                      By default, all layers served by GeoServer will be known to GeoWebCache. See the Tile Layers page to test the configuration.

                      Note

                      Version 2.2.0 of GeoServer introduced changes to the configuration of the integrated GeoWebCache.

                      "},{"location":"geowebcache/config/#integrated-user-interface","title":"Integrated user interface","text":"

                      GeoWebCache has a full integrated web-based configuration. See the GeoWebCache settings section in the Web administration interface.

                      "},{"location":"geowebcache/config/#determining-tiled-layers","title":"Determining tiled layers","text":"

                      In versions of GeoServer prior to 2.2.0, the GeoWebCache integration was done in a such way that every GeoServer layer and layer group was forced to have an associated GeoWebCache tile layer. In addition, every such tile layer was forcedly published in the EPSG:900913 and EPSG:4326 gridsets with PNG and JPEG output formats.

                      It is possible to selectively turn caching on or off for any layer served through GeoServer. This setting can be configured in the Tile Layers section of the Web administration interface.

                      "},{"location":"geowebcache/config/#configuration-files","title":"Configuration files","text":"

                      It is possible to configure most aspects of cached layers through the GeoWebCache settings section in the Web administration interface or the GeoWebCache REST API.

                      GeoWebCache keeps the configuration for each GeoServer tiled layer separately, inside the <data_dir>/gwc-layers/ directory. There is one XML file for each tile layer. These files contain a different syntax from the <wmsLayer> syntax in the standalone version and are not meant to be edited by hand. Instead you can configure tile layers on the Tile Layers page or through the GeoWebCache REST API.

                      Configuration for the defined gridsets is saved in <data_dir>/gwc/geowebcache.xml` so that the integrated GeoWebCache can continue to serve externally-defined tile layers from WMS services outside GeoServer.

                      If upgrading from a version prior to 2.2.0, a migration process is run which creates a tile layer configuration for all the available layers and layer groups in GeoServer with the old defaults. From that point on, you should configure the tile layers on the Tile Layers page.

                      "},{"location":"geowebcache/config/#changing-the-cache-directory","title":"Changing the cache directory","text":"

                      GeoWebCache will automatically store cached tiles in a gwc directory inside your GeoServer data directory. To set a different directory, stop GeoServer (if it is running) and add the following code to your GeoServer web.xml file (located in the WEB-INF directory):

                      <context-param>\n   <param-name>GEOWEBCACHE_CACHE_DIR</param-name>\n   <param-value>C:\\temp</param-value>\n</context-param>\n

                      Change the path inside <param-value> to the desired cache path (such as C:\\temp or /tmp). Restart GeoServer when done.

                      Note

                      Make sure GeoServer has write access in this directory.

                      "},{"location":"geowebcache/config/#geowebcache-with-multiple-geoserver-instances","title":"GeoWebCache with multiple GeoServer instances","text":"

                      For stability reasons, it is not recommended to use the embedded GeoWebCache with multiple GeoServer instances. If you want to configure GeoWebCache as a front-end for multiple instances of GeoServer, we recommend using the standalone GeoWebCache.

                      "},{"location":"geowebcache/config/#gwc_data_security","title":"GeoServer Data Security","text":"

                      GWC Data Security is an option that can be turned on and turned off through the Caching defaults page. By default it is turned off.

                      When turned on, the embedded GWC will do a data security check before calling GeoWebCache, i.e. verify whether the user actually has access to the layer, and reject the request if this is not the case. In the case of WMS-C requests, there is also limited support for data access limit filters, only with respect to geographic boundaries (all other types of data access limits will be ignored). The embedded GWC will reject requests for which the requested bounding box is (partly) inaccessible. It is only possible to request a tile within a bounding box that is fully accessible. This behaviour is different from the regular WMS, which will filter the data before serving it. However, if the integrated WMS/WMS-C is used, the request will be forwarded back to WMS and give the desired result.

                      When using the default GeoServer security system, rules cannot combine data security with service security. However, when using a security subsystem it may be possible to make such particular combinations. In this case the WMS-C service inherits all security rules from the regular WMS service; while all other GWC services will get their security from rules associated with the 'GWC' service itself.

                      "},{"location":"geowebcache/config/#configuring-in-memory-caching","title":"Configuring In Memory Caching","text":"

                      GWC In Memory Caching is a new feature which allows to cache GWC tiles in memory reducing their access time. User can also choose to avoid to store the files on the disk if needed. For enabling/disabling these features the user may see the related section on the TileCaching Caching defaults page.

                      Actually there are only two Caching methods:

                      • Guava Caching
                      • Hazelcast Caching
                      "},{"location":"geowebcache/config/#guava-cache","title":"Guava Cache","text":"

                      Guava Cache provides a local in-memory cache to use for a single GeoServer instance. For configuring Guava Caching the user must only edit the configuration parameters in the Caching Defaults page.

                      "},{"location":"geowebcache/config/#hazelcast-cache","title":"Hazelcast Cache","text":"

                      Hazelcast is an open-source API for distributed structures like clusters. GWC supports this API for creating a distributed in memory cache. At the time of writing, Hazelcast requires the installation of the gs-gwc-distributed plugin in the WEB_INF/lib directory of your geoserver application. This plugin can be found at the following link.

                      There are 2 ways for configuring distributed caching in GWC:

                      • Using an XML file called hazelcast.xml. This file must be located in a directory indicated by the JVM parameter hazelcast.config.dir
                      • Directly, by configuring a bean inside the GeoServer application context

                      Both the 2 configurations should define the following parameters:

                      1. The Hazelcast configuration requires a Map object with name CacheProviderMap
                      2. Map eviction policy must be LRU or LFU
                      3. Map configuration must have a fixed size defined in Mb
                      4. Map configuration must have USED_HEAP_SIZE as MaxSizePolicy

                      Warning

                      Be careful that all the cluster instances have the same configuration, because different configurations may result in incorrect Hazelcast behaviour.

                      Warning

                      In order to avoid missing tiles, the cluster instances should access the same data.

                      "},{"location":"geowebcache/config/#configuration-with-hazelcastxml","title":"Configuration with hazelcast.xml","text":"

                      Here can be found an example file:

                      <hazelcast xmlns=\"http://www.hazelcast.com/schema/config\"\n           xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\"\n           xsi:schemaLocation=\"http://www.hazelcast.com/schema/config\n                               https://hazelcast.com/schema/config/hazelcast-config-5.3.xsd\">\n  <cluster-name>gsCacheCluster</cluster-name>\n\n  <network>\n    <!--\n        Typical usage: multicast enabled with port auto-increment enabled\n        or tcp-ip enabled with port auto-increment disabled. Note that you \n        must choose between multicast and tcp-ip. Another option could be\n        aws, but will not be described here.\n\n    -->\n    <port auto-increment=\"false\">5701</port>\n        <join>\n             <multicast enabled=\"false\">\n                <multicast-group>224.2.2.3</multicast-group>\n                <multicast-port>54327</multicast-port>\n            </multicast>\n            <tcp-ip enabled=\"true\">\n                <interface>192.168.1.32</interface>     \n                <interface>192.168.1.110</interface> \n            </tcp-ip>\n        </join>\n  </network>\n\n  <map name=\"CacheProviderMap\">\n        <eviction eviction-policy=\"LRU\" max-size-policy=\"USED_HEAP_SIZE\" size=\"16\" />\n  </map>\n\n</hazelcast>\n
                      "},{"location":"geowebcache/config/#configuration-with-applicationcontext","title":"Configuration with ApplicationContext","text":"

                      For configuring caching directly from the GeoServer application context, the user must edit the file geowebcache-distributed.xml inside the gs-gwc jar file. More informations about using Spring with Hazelcast can be found in the Hazelcast related documentation. The modified application context is presented below:

                      <hz:hazelcast id=\"instance1\">\n    <hz:config>\n        <hz:group name=\"dev\" password=\"password\" />\n        <hz:network port=\"5701\" port-auto-increment=\"true\">\n            <hz:join>\n                <hz:multicast enabled=\"true\" multicast-group=\"224.2.2.3\"\n                    multicast-port=\"54327\" />\n            <hz:tcp-ip enabled=\"false\">\n              <hz:members>10.10.1.2, 10.10.1.3</hz:members>\n            </hz:tcp-ip>\n            </hz:join>\n        </hz:network>\n        <hz:map name=\"CacheProviderMap\" max-size=\"16\" eviction-policy=\"LRU\"\n            max-size-policy=\"USED_HEAP_SIZE\" />\n    </hz:config>\n</hz:hazelcast>\n\n<bean id=\"HazelCastLoader1\"\n    class=\"org.geowebcache.storage.blobstore.memory.distributed.HazelcastLoader\">\n    <property name=\"instance\" ref=\"instance1\" />\n</bean>\n\n<bean id=\"HazelCastCacheProvider1\"\n    class=\"org.geowebcache.storage.blobstore.memory.distributed.HazelcastCacheProvider\">\n    <constructor-arg ref=\"HazelCastLoader1\" />\n</bean>\n
                      "},{"location":"geowebcache/config/#optional-configuration-parameters","title":"Optional configuration parameters","text":"

                      In this section are described other available configuration parameters to configure:

                      • Cache expiration time:

                        <map name=\"CacheProviderMap\">\n...\n\n    <time-to-live-seconds>0</time-to-live-seconds>\n    <max-idle-seconds>0</max-idle-seconds>\n\n</map>\n

                        Where time-to-live-seconds indicates how many seconds an entry can stay in cache and max-idle-seconds indicates how many seconds an entry may be not accessed before being evicted.

                      • Near Cache.

                        <map name=\"CacheProviderMap\">\n...\n<near-cache>\n  <!--\n    Same configuration parameters of the Hazelcast Map. Note that size indicates the maximum number of \n    entries in the near cache. A value of Integer.MAX_VALUE indicates no limit on the maximum \n    size.\n  -->\n  <time-to-live-seconds>0</time-to-live-seconds>\n  <max-idle-seconds>60</max-idle-seconds>\n  <eviction eviction-policy=\"LRU\" size=\"5000\" />\n\n  <!--\n    Indicates if a cached entry can be evicted if the same value is modified in the Hazelcast Map. Default is true.\n  -->\n  <invalidate-on-change>true</invalidate-on-change>\n\n  <!--\n    Indicates if local entries must be cached. Default is false.\n  -->\n  <cache-local-entries>false</cache-local-entries>\n</near-cache>\n\n</map>  \n

                        Near Cache is a local cache for each cluster instance which is used for caching entries in the other cluster instances. This behaviour avoids requesting those entries each time by executing a remote call. This feature could be helpful in order to improve Hazelcast Cache performance.

                        ::: note ::: title Note :::

                        A value of max-size bigger or equal to Integer.MAX_VALUE cannot be used in order to avoid an uncontrollable growth of the cache size. :::

                      "},{"location":"geowebcache/responseheaders/","title":"HTTP Response Headers","text":"

                      The GeoWebCache integrated with GeoServer employs special information stored in the header of responses. These headers are available either with direct calls to the GeoWebCache endpoint or with direct WMS integration.

                      "},{"location":"geowebcache/responseheaders/#custom-response-headers","title":"Custom response headers","text":"

                      GeoWebCache returns both standard and custom HTTP response headers when serving a tile request. This aids in the debugging process, as well as adhering to an HTTP 1.1 transfer control mechanism.

                      The response headers can be determined via a utility such as cURL.

                      "},{"location":"geowebcache/responseheaders/#example","title":"Example","text":"

                      Note

                      For all cURL commands below, make sure to replace >/dev/null with >nul if you are running on Windows.

                      This is a sample request and response using cURL:

                      curl -v \"http://localhost:8080/geoserver/gwc/service/wms?LAYERS=sde%3Abmworld&FORMAT=image%2Fpng&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&STYLES=&SRS=EPSG%3A4326&BBOX=-180,-38,-52,90&WIDTH=256&HEIGHT=256&tiled=true\" > /dev/null \n
                      < HTTP/1.1 200 OK\n< geowebcache-tile-index: [0, 1, 2]\n< geowebcache-cache-result: HIT\n< geowebcache-tile-index: [0, 1, 2]\n< geowebcache-tile-bounds: -180.0,-38.0,-52.0,90.0\n< geowebcache-gridset: GlobalCRS84Pixel\n< geowebcache-crs: EPSG:4326\n< Content-Type: image/png\n< Content-Length: 102860\n< Server: Jetty(6.1.8)\n

                      From this, one can learn that the tile was found in the cache (HIT), the requested tile was from the gridset called GlobalCRS84Pixel and had a CRS of EPSG:4326.

                      "},{"location":"geowebcache/responseheaders/#list-of-custom-response-headers","title":"List of custom response headers","text":"

                      The following is the full list of custom response headers. Whenever GeoWebCache serves a tile request, it will write some or all of the following custom headers on the HTTP response.

                      +----------------------------+----------------------------------------------------------------------------------------------------------------------------------------+ | Response Header | Description | +============================+========================================================================================================================================+ | geowebcache-cache-result | Shows whether the GeoWebCache WMS was used. Options are: | | | | | | - HIT: Tile requested was found on the cache | | | - MISS: Tile was not found on the cache but was acquired from the layer's data source | | | - WMS: Request was proxied directly to the origin WMS (for example, for GetFeatureInfo requests) | | | - OTHER: Response was the default white/transparent tile or an error occurred | +----------------------------+----------------------------------------------------------------------------------------------------------------------------------------+ | geowebcache-tile-index | Contains the three-dimensional tile index in x,y,z order of the returned tile image in the corresponding grid space (e.g. [1, 0, 0]) | +----------------------------+----------------------------------------------------------------------------------------------------------------------------------------+ | geowebcache-tile-bounds | Bounds of the returned tile in the corresponding coordinate reference system (e.g. -180,-90,0,90) | +----------------------------+----------------------------------------------------------------------------------------------------------------------------------------+ | geowebcache-gridset | Name of the gridset the tile belongs to (see Gridsets for more information) | +----------------------------+----------------------------------------------------------------------------------------------------------------------------------------+ | geowebcache-crs | Coordinate reference system code of the matching gridset (e.g. EPSG:900913, EPSG:4326, etc). | +----------------------------+----------------------------------------------------------------------------------------------------------------------------------------+

                      "},{"location":"geowebcache/responseheaders/#gwc_lastmodifiedheaders","title":"Last-Modified and If-Modified-Since","text":"

                      Well behaved HTTP 1.1 clients and server applications can make use of Last-Modified and If-Modified-Since HTTP control mechanisms to know when locally cached content is up to date, eliminating the need to download the same content again. This can result in considerable bandwidth savings. (See HTTP 1.1 RFC 2616, sections 14.29 and 14.25, for more information on these mechanisms.)

                      GeoWebCache will write a Last-Modified HTTP response header when serving a tile image. The date is written as an RFC-1123 HTTP-Date:

                      Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT\n

                      Clients connecting to GeoWebCache can create a \"conditional GET\" request with the If-Modified-Since request header. If the tile wasn't modified after the date specified in the Last-Modified response header, GeoWebCache will return a 304 status code indicating that the resource was available and not modified.

                      "},{"location":"geowebcache/responseheaders/#example_1","title":"Example","text":"

                      A query for a specific tile returns the Last-Modified response header:

                      curl -v \"http://localhost:8080/geoserver/gwc/service/wms?LAYERS=img%20states&FORMAT=image%2Fpng&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&STYLES=&EXCEPTIONS=application%2Fvnd.ogc.se_inimage&SRS=EPSG%3A4326&BBOX=-135,45,-90,90&WIDTH=256&HEIGHT=256\" >/dev/null\n
                      > Host: localhost:8080\n> Accept: */*\n>\n< HTTP/1.1 200 OK\n...\n< Last-Modified: Wed, 25 Jul 2012 00:42:00 GMT\n< Content-Type: image/png\n< Content-Length: 31192\n

                      This request has the If-Modified-Since header set to one second after what was returned by Last-Modified:

                      curl --header \"If-Modified-Since: Wed, 25 Jul 2012 00:42:01 GMT\" -v \"http://localhost:8080/geoserver/gwc/service/wms?LAYERS=img%20states&FORMAT=image%2Fpng&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&STYLES=&EXCEPTIONS=application%2Fvnd.ogc.se_inimage&SRS=EPSG%3A4326&BBOX=-135,45,-90,90&WIDTH=256&HEIGHT=256\" >/dev/null\n
                      > Host: localhost:8080\n> Accept: */*\n> If-Modified-Since: Wed, 25 Jul 2012 00:42:01 GMT\n> \n< HTTP/1.1 304 Not Modified\n< Last-Modified: Wed, 25 Jul 2012 00:42:00 GMT\n< Content-Type: image/png\n< Content-Length: 31192\n

                      The response code is 304. As the file hasn't been modified since the time specified in the request, no content is actually transferred. The client is informed that its copy of the tile is up to date.

                      However, if you were to set the If-Modified-Since header to before the time stored in Last-Modified, you will instead receive a 200 status code and the tile will be downloaded.

                      This example sets the If-Modified-Since header to one second before what was returned by Last-Modified:

                      curl --header \"If-Modified-Since: Wed, 25 Jul 2012 00:41:59 GMT\" -v \"http://localhost:8080/geoserver/gwc/service/wms?LAYERS=img%20states&FORMAT=image%2Fpng&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&STYLES=&EXCEPTIONS=application%2Fvnd.ogc.se_inimage&SRS=EPSG%3A4326&BBOX=-135,45,-90,90&WIDTH=256&HEIGHT=256\" >/dev/null\n
                      > Host: localhost:8080\n> Accept: */*\n> If-Modified-Since: Wed, 25 Jul 2012 00:41:59 GMT\n> \n< HTTP/1.1 200 OK\n...\n< Last-Modified: Wed, 25 Jul 2012 00:42:00 GMT\n< Content-Type: image/png\n< Content-Length: 31192\n
                      "},{"location":"geowebcache/seeding/","title":"Seeding and refreshing","text":"

                      The primary benefit to GeoWebCache is that it allows for the acceleration of normal WMS tile request processing by eliminating the need for the tiles to be regenerated for every request. This page discusses tile generation.

                      You can configure seeding processes via the Web administration interface. See the Tile Layers page for more information.

                      "},{"location":"geowebcache/seeding/#generating-tiles","title":"Generating tiles","text":"

                      There are two ways for tiles to be generated by GeoWebCache. The first way for tiles to be generated is during normal map viewing. In this case, tiles are cached only when they are requested from a client, either through map browsing (such as in OpenLayers) or through manual WMS tile requests. The first time a map view is requested it will be roughly at the same speed as a standard GeoServer WMS request. The second and subsequent map viewings will be greatly accelerated as those tiles will have already been generated. The main advantage to this method is that it requires no preprocessing, and that only the data that has been requested will be cached, thus potentially saving disk space as well. The disadvantage to this method is that map viewing will be only intermittently accelerated, reducing the quality of user experience.

                      The other way for tiles to be generated is by seeding. Seeding is the process where map tiles are generated and cached internally from GeoWebCache. When processed in advance, the user experience is greatly enhanced, as the user never has to wait for tiles to be generated. The disadvantage to this process is that seeding can be a very time- and disk-consuming process.

                      In practice, a combination of both methods are usually used, with certain zoom levels (or certain areas of zoom levels) seeded, and the less-likely-viewed tiles are left uncached.

                      "},{"location":"geowebcache/troubleshooting/","title":"Troubleshooting","text":"

                      This section will discuss some common issues with the integrated GeoWebCache and their solutions.

                      "},{"location":"geowebcache/troubleshooting/#grid-misalignment","title":"Grid misalignment","text":"

                      Sometimes errors will occur when requesting data from GeoWebCache endpoints. The error displayed might say that the \"resolution is not supported\" or the \"bounds do not align.\" This is due to the client making WMS requests that do not align with the grid of tiles that GeoWebCache has created, such as differing map bounds or layer bounds, or an unsupported resolution. If you are using OpenLayers as a client, looking at the source code of the included demos may provide more clues to matching up the grid.

                      An alternative workaround is to enable direct WMS integration with the GeoServer WMS. You can set this on the Caching defaults page.

                      "},{"location":"geowebcache/troubleshooting/#direct-wms-integration","title":"Direct WMS integration","text":"

                      Direct integration allows WMS requests served through GeoServer to be cached as if they were received and processed by GeoWebCache. With Direct WMS Integration, a request may either be handled by the GeoServer WMS or GeoWebCache WMS.

                      Sometimes requests that should go to GeoWebCache will instead be passed through to GeoServer, resulting in no tiles saved. That said, it is possible to determine why a request was not handled by GeoWebCache when intended. This is done by using the command-line utility cURL and inspecting the response headers.

                      First, obtain a sample request. This can easily be done by going to the Layer Preview for a given layer, setting the Tiled parameter to Tiled, then right-clicking on an area of the map and copy the full path to the image location. If done correctly, the result will be a GET request that looks something like this:

                      http://localhost:8090/geoserver/nurc/wms?LAYERS=nurc%3AArc_Sample&STYLES=&FORMAT=image%2Fjpeg&TILED=true&TILESORIGIN=-180%2C-90&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&SRS=EPSG%3A4326&BBOX=-45,-45,0,0&WIDTH=256&HEIGHT=256\n

                      You can then paste this URL into a curl request:

                      curl -v \"URL\"\n

                      For example:

                      curl -v \"http://localhost:8090/geoserver/nurc/wms?LAYERS=nurc%3AArc_Sample&STYLES=&FORMAT=image%2Fjpeg&TILED=true&TILESORIGIN=-180%2C-90&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&SRS=EPSG%3A4326&BBOX=-45,-45,0,0&WIDTH=256&HEIGHT=256\"\n

                      Note

                      To omit the raw image output to the terminal, pipe the output to your system's null. On Linux / OS X, append > /dev/null to these requests, and on Windows, append > nul.

                      If the request doesn't go through GeoWebCache's WMS, a reason will be given in a custom response header. Look for the following response headers:

                      • geowebcache-cache-result: Will say HIT if the GeoWebCache WMS processed the request, and MISS otherwise.
                      • geowebcache-miss-reason: If the above shows as MISS, this will generated a short description of why the request wasn't handled by the GeoWebCache WMS.

                      The following are some example requests made along with the responses. These responses have been truncated to show only the information relevant for troubleshooting.

                      "},{"location":"geowebcache/troubleshooting/#successful-request","title":"Successful request","text":"

                      This request was successfully handled by the GeoWebCache WMS.

                      Request:

                      curl -v \"http://localhost:8080/geoserver/topp/wms?TILED=true&LAYERS=states&FORMAT=image/png&REQUEST=GetMap&STYLES=&SRS=EPSG:4326&BBOX=-135,45,-112.5,67.5&WIDTH=256&HEIGHT=256\"\n

                      Response:

                      < HTTP/1.1 200 OK\n< Content-Type: image/png\n< geowebcache-crs: EPSG:4326\n...\n< geowebcache-layer: topp:states\n< geowebcache-gridset: EPSG:4326\n< geowebcache-tile-index: [2, 6, 3]\n...\n< geowebcache-cache-result: HIT\n< geowebcache-tile-bounds: -135.0,45.0,-112.5,67.5\n...\n
                      "},{"location":"geowebcache/troubleshooting/#wrong-height-parameter","title":"Wrong height parameter","text":"

                      The following request is not handled by the GeoWebCache WMS because the image requested (256x257) does not conform to the expected 256x256 tile size.

                      Request:

                      curl -v \"http://localhost:8080/geoserver/topp/wms?TILED=true&LAYERS=states&FORMAT=image/png&REQUEST=GetMap&STYLES=&SRS=EPSG:4326&BBOX=-135,45,-112.5,67.5&WIDTH=256&HEIGHT=257\"\n

                      Response:

                      < HTTP/1.1 200 OK\n< Content-Type: image/png\n< geowebcache-miss-reason: request does not align to grid(s) 'EPSG:4326' \n...\n
                      "},{"location":"geowebcache/troubleshooting/#no-tile-layer-associated","title":"No tile layer associated","text":"

                      The following request is not handled by the GeoWebCache WMS because the layer requested has no tile layer configured.

                      Request:

                      curl -v \"http://localhost:8080/geoserver/topp/wms?TILED=true&LAYERS=tasmania_roads&FORMAT=image/png&REQUEST=GetMap&STYLES=&SRS=EPSG:4326&BBOX=-135,45,-112.5,67.5&WIDTH=256&HEIGHT=256\"\n

                      Response:

                      < HTTP/1.1 200 OK\n< Content-Type: image/png\n< geowebcache-miss-reason: not a tile layer\n...\n
                      "},{"location":"geowebcache/troubleshooting/#missing-parameter-filter","title":"Missing parameter filter","text":"

                      The following request is not handled by the GeoWebCache WMS because the request contains a parameter filter (BGCOLOR) that is not configured for this layer.

                      Request:

                      curl -v \"http://localhost:8080/geoserver/topp/wms?BGCOLOR=0xAAAAAA&TILED=true&LAYERS=states&FORMAT=image/png&REQUEST=GetMap&STYLES=&SRS=EPSG:4326&BBOX=-135,45,-112.5,67.5&WIDTH=256&HEIGHT=256\"\n

                      Response:

                      < HTTP/1.1 200 OK\n< Content-Type: image/png\n< geowebcache-miss-reason: no parameter filter exists for BGCOLOR\n...\n
                      "},{"location":"geowebcache/troubleshooting/#crs-not-defined","title":"CRS not defined","text":"

                      The following request is not handled by the GeoWebCache WMS because the request references a CRS (EPSG:26986) that does not match any of the tile layer gridsets:

                      Request:

                      curl -v \"http://localhost:8080/geoserver/topp/wms?TILED=true&LAYERS=states&FORMAT=image/png&REQUEST=GetMap&STYLES=&SRS=EPSG:26986&BBOX=-135,45,-112.5,67.5&WIDTH=256&HEIGHT=256\"\n

                      Response:

                      < HTTP/1.1 200 OK\n< Content-Type: image/png\n< geowebcache-miss-reason: no cache exists for requested CRS\n...\n
                      "},{"location":"geowebcache/troubleshooting/#workspace-styles","title":"Workspace Styles","text":"

                      If a cached layer uses a style which is tied to a workspace, the layer needs to be viewed in the context of that workspace in order for the style to be visible. Trying to cache such a layer will result in an error.

                      By default, the embeded GeoWebCache uses the global workspace. This can be overridden using a WORKSPACE parameter. To enable this, create a List of Strings Parameter filter for the layer named WORKSPACE. Set the default to the name of the workspace containing the style. Setting the other values will not be useful in most cases.

                      Moving the style to a new workspace will require updating the filter.

                      This parameter only applies to integrated tile layers. If you are adding a GeoServer layer on a remote GeoServer directly to GWC, then specify the workspace as part of the path as you would normally.

                      "},{"location":"geowebcache/using/","title":"Using GeoWebCache","text":"

                      Note

                      For an more in-depth discussion of using GeoWebCache, please see the GeoWebCache documentation.

                      "},{"location":"geowebcache/using/#gwc_directwms","title":"Direct integration with GeoServer WMS","text":"

                      GeoWebCache can be transparently integrated with the GeoServer WMS, and so requires no special endpoint or custom URL. In this way one can have the simplicity of a standard WMS endpoint with the performance of a tiled client.

                      Although this direct integration is disabled by default, it can be enabled by going to the Caching defaults page in the Web administration interface.

                      When this feature is enabled, GeoServer WMS will cache and retrieve tiles from GeoWebCache (via a GetMap request) only if all of the following criteria are followed:

                      • WMS Direct integration is enabled (you can set this on the Caching defaults page)
                      • tiled=true is included in the request (unless the Explicitly require TILED Parameter is unchecked. you can set this on the Caching defaults page)
                      • The request only references a single layer
                      • Caching is enabled for that layer
                      • The image requested is of the same height and width as the size saved in the layer configuration
                      • The requested CRS matches one of the available tile layer gridsets
                      • The image requested lines up with the existing grid bounds
                      • A parameter is included for which there is a corresponding Parameter Filter

                      In addition, when direct integration is enabled, the WMS capabilities document (via a GetCapabilities request) will only return the WMS-C vendor-specific capabilities elements (such as a <TileSet> element for each cached layer/CRS/format combination) if tiled=true is appended to the GetCapabilities request.

                      Note

                      For more information on WMS-C, please see the WMS Tiling Client Recommendation from OSGeo.

                      Note

                      GeoWebCache integration is not compatible with the OpenLayers-based Layer Preview, as the preview does not usually align with the GeoWebCache layer gridset. This is because the OpenLayers application calculates the tileorigin based on the layer's bounding box, which is different from the gridset. It is, possible to create an OpenLayers application that caches tiles; just make sure that the tileorigin aligns with the gridset.

                      "},{"location":"geowebcache/using/#virtual-services","title":"Virtual services","text":"

                      When direct WMS integration is enabled, GeoWebCache will properly handle requests to Virtual Services (/geoserver/<workspace>/wms?tiled=true&...).

                      Virtual services capabilities documents will contain <TileSet> entries only for the layers that belong to that workspace (and global layer groups), and will be referenced by unqualified layer names (no namespace). For example, the layer topp:states will be referred to as <Layers>states</Layers> instead of <Layers>topp:states</Layers>, and GetMap requests to the virtual services endpoint using LAYERS=states will properly be handled.

                      "},{"location":"geowebcache/using/#supported-parameter-filters","title":"Supported parameter filters","text":"

                      With direct WMS integration, the following parameter filters are supported for GetMap requests:

                      • ANGLE
                      • BGCOLOR
                      • BUFFER
                      • CQL_FILTER
                      • ELEVATION
                      • ENV
                      • FEATUREID
                      • FEATUREVERSION
                      • FILTER
                      • FORMAT_OPTIONS
                      • MAXFEATURES
                      • PALETTE
                      • STARTINDEX
                      • TIME
                      • VIEWPARAMS

                      If a request is made using any of the above parameters, the request will be passed to GeoServer, unless a parameter filter has been set up, in which case GeoWebCache will process the request.

                      "},{"location":"geowebcache/using/#gwc_endpoint","title":"GeoWebCache endpoint URL","text":"

                      When not using direct integration, you can point your client directly to GeoWebCache.

                      Warning

                      GeoWebCache is not a true WMS, and so the following is an oversimplification. If you encounter errors, see the Troubleshooting page for help.

                      To direct your client to GeoWebCache (and thus receive cached tiles) you need to change the WMS URL.

                      If your application requests WMS tiles from GeoServer at this URL:

                      http://example.com/geoserver/wms\n

                      You can invoke the GeoWebCache WMS instead at this URL:

                      http://example.com/geoserver/gwc/service/wms\n

                      In other words, add /gwc/service/wms in between the path to your GeoServer instance and the WMS call.

                      This end-point works using either:

                      • WMS-C: A tileset description is included in the WMS GetCapabilities document instructing clients how to retrieve content as a series of tiles (each retrieved by a GetMap request). This technique supports HTTP caching taking advantage of the browser cache and any caching proxies deployed. This technique requires a client to be created with tile server support.

                      • full-wms mode: GeoWebCache behaves as normal WMS supported ad-hoc WMS GetMapRequests. Each WMS Request is handled by obtaining the tiles required and stitching the result into a single image. This technique relies only on internal tile cache, but supports ad-hoc GetMap requests and does not require a client be constructed with tile server support.

                        To enable this mode add the following in geowebcache.xml configuration file:

                        <fullWMS>true</fullWMS>\n

                        The fullWMS setting only effects the /gwc/service/wms endpoint and is not used by direct WMS integration.

                      As soon as tiles are requested through the gwc/service/wms endpoint GeoWebCache automatically starts saving them. The initial requests for each tile will not be accelerated since GeoServer will need to generate the tile and store it from subsequent use. To automate this process of requesting tiles, you can seed the cache. See the section on Seeding and refreshing for more details.

                      "},{"location":"geowebcache/using/#gwc_diskquota","title":"Disk quota","text":"

                      GeoWebCache has a built-in disk quota feature to prevent disk space from growing unbounded. You can set the maximum size of the cache directory, poll interval, and what policy of tile removal to use when the quota is exceeded. Tiles can be removed based on usage (\"Least Frequently Used\" or LFU) or timestamp (\"Least Recently Used\" or LRU).

                      Disk quotas are turned off by default, but can be configured on the Disk Quotas page in the Web administration interface.

                      "},{"location":"geowebcache/using/#integration-with-external-mapping-sites","title":"Integration with external mapping sites","text":"

                      The documentation on the GeoWebCache homepage contains examples for creating applications that integrate with Google Maps, Google Earth, Bing Maps, and more.

                      "},{"location":"geowebcache/using/#support-for-custom-projections","title":"Support for custom projections","text":"

                      The version of GeoWebCache that comes embedded in GeoServer automatically configures every layer served in GeoServer with the two most common projections:

                      • EPSG:4326 (latitude/longitude)
                      • EPSG:900913 (Spherical Mercator, the projection used in Google Maps)

                      You can also set a custom CRS from any that GeoServer recognizes. See the Gridsets page for details.

                      "},{"location":"geowebcache/rest/","title":"GeoWebCache REST API","text":"

                      This section discusses the GeoWebCache REST API, an interface for working programmatically with the integrated GeoWebCache without the need for a GUI.

                      The GeoWebCache REST endpoint when integrated with GeoServer is available at:

                      <GEOSERVER_HOME>/gwc/rest/\n

                      For example:

                      http://example.com:8080/geoserver/gwc/rest/\n
                      • Managing Layers
                      • Seeding and Truncating
                      • Disk Quota
                      "},{"location":"geowebcache/rest/diskquota/","title":"Disk Quota","text":"

                      The GeoWebCache REST API provides a RESTful interface through which users can configure the disk usage limits and expiration policies for a GeoWebCache instance.

                      "},{"location":"geowebcache/rest/diskquota/#operations","title":"Operations","text":"

                      URL: /gwc/rest/diskquota.<format>

                      Method Action Return Code Formats GET Return the global disk quota configuration 200 XML, JSON POST 405 PUT Modify the global disk quota configuration 200 XML, JSON DELETE 405

                      Representations:

                      • XML
                      • JSON

                      The examples below use the cURL tool, though the examples apply to any HTTP-capable tool or library.

                      "},{"location":"geowebcache/rest/diskquota/#retrieving-the-current-configuration","title":"Retrieving the current configuration","text":"

                      The following returns the current disk quota configuration in XML format:

                      curl -u admin:geoserver -v -XGET http://localhost:8080/geoserver/gwc/rest/diskquota.xml\n
                      < HTTP/1.1 200 OK\n< Date: Mon, 21 Mar 2011 13:50:49 GMT\n< Server: Noelios-Restlet-Engine/1.0..8\n< Content-Type: text/xml; charset=ISO-8859-1\n< Content-Length: 422\n< \n<gwcQuotaConfiguration>\n  <enabled>true</enabled>\n  <diskBlockSize>2048</diskBlockSize>\n  <cacheCleanUpFrequency>5</cacheCleanUpFrequency>\n  <cacheCleanUpUnits>SECONDS</cacheCleanUpUnits>\n  <maxConcurrentCleanUps>5</maxConcurrentCleanUps>\n  <globalExpirationPolicyName>LRU</globalExpirationPolicyName>\n  <globalQuota>\n    <value>100</value>\n    <units>MiB</units>\n  </globalQuota>\n  <layerQuotas/>\n</gwcQuotaConfiguration>\n

                      The following returns the current disk quota configuration in JSON format:

                      curl -u admin:geoserver -v -XGET http://localhost:8080/geoserver/gwc/rest/diskquota.json\n
                      < HTTP/1.1 200 OK\n< Date: Mon, 21 Mar 2011 13:53:42 GMT\n< Server: Noelios-Restlet-Engine/1.0..8\n< Content-Type: application/json; charset=ISO-8859-1\n< Content-Length: 241\n< \n* Connection #0 to host localhost left intact\n* Closing connection #0\n{\"gwcQuotaConfiguration\":{\"diskBlockSize\":2048,\"enabled\":true,\"maxConcurrentCleanUps\":5,\"cacheCleanUpFrequency\":5,\"globalExpirationPolicyName\":\"LRU\",\"globalQuota\":{\"value\":\"100\",\"units\":\"MiB\"},\"cacheCleanUpUnits\":\"SECONDS\"}}\n
                      "},{"location":"geowebcache/rest/diskquota/#changing-configuration","title":"Changing configuration","text":"

                      Note

                      The request body for PUT should contain only the desired properties to be modified. For example, the following will only change the maxConcurrentCleanups property in XML format:

                      <gwcQuotaConfiguration><maxConcurrentCleanUps>2</maxConcurrentCleanUps></gwcQuotaConfiguration>\n

                      The following will only change the diskBlockSize, enabled, and globalQuota properties in JSON format:

                      {\"gwcQuotaConfiguration\":{\"diskBlockSize\":2048,\"enabled\":true,\"globalQuota\":{\"value\":\"100\",\"units\":\"MiB\"}}\n

                      The following XML example successfully enables the quota and sets the globalQuota size:

                      curl -v -u admin:geoserver \"http://localhost:8090/geoserver/gwc/rest/diskquota.xml\" -X PUT -d \"<gwcQuotaConfiguration><enabled>true</enabled><globalQuota><value>100</value><units>GiB</units></globalQuota></gwcQuotaConfiguration>\"\n
                      < HTTP/1.1 200 OK\n< Date: Fri, 18 Mar 2011 20:59:31 GMT\n< Server: Noelios-Restlet-Engine/1.0..8\n< Content-Type: text/xml; charset=ISO-8859-1\n< Content-Length: 422\n< \n<gwcQuotaConfiguration>\n  <enabled>true</enabled>\n  <diskBlockSize>2048</diskBlockSize>\n  <cacheCleanUpFrequency>5</cacheCleanUpFrequency>\n  <cacheCleanUpUnits>SECONDS</cacheCleanUpUnits>\n  <maxConcurrentCleanUps>5</maxConcurrentCleanUps>\n  <globalExpirationPolicyName>LFU</globalExpirationPolicyName>\n  <globalQuota>\n    <value>100</value>\n    <units>GiB</units>\n  </globalQuota>\n  <layerQuotas/>\n</gwcQuotaConfiguration>\n

                      The following JSON example changes the globalQuote and expirationPolicyName parameters:

                      curl -v -u admin:geoserver \"http://localhost:8090/geoserver/gwc/rest/diskquota.json\" -X PUT -d \"{\"gwcQuotaConfiguration\":{\"globalQuota\":{\"value\":\"100\",\"units\":\"MiB\"},\"globalExpirationPolicyName\":\"LRU\"}}\"\n
                      < HTTP/1.1 200 OK\n< Date: Fri, 18 Mar 2011 21:02:20 GMT\n< Server: Noelios-Restlet-Engine/1.0..8\n< Content-Type: application/json; charset=ISO-8859-1\n< Content-Length: 241\n< \n* Connection #0 to host localhost left intact\n* Closing connection #0\n{\"gwcQuotaConfiguration\":{\"diskBlockSize\":2048,\"enabled\":true,\"maxConcurrentCleanUps\":5,\"cacheCleanUpFrequency\":5,\"globalExpirationPolicyName\":\"LRU\",\"globalQuota\":{\"value\":\"100\",\"units\":\"MiB\"},\"cacheCleanUpUnits\":\"SECONDS\",\"layerQuotas\":[]}}\n

                      The following invalid XML example has an invalid parameter (maxConcurrentCleanUps must be > 0). It returns a 400 response code and contains an error message as plain text:

                      curl -v -u admin:geoserver \"http://localhost:8090/geoserver/gwc/rest/diskquota.xml\" -X PUT -d \"<gwcQuotaConfiguration><maxConcurrentCleanUps>-1</maxConcurrentCleanUps></gwcQuotaConfiguration>\"\n
                      < HTTP/1.1 400 Bad Request\n< Date: Fri, 18 Mar 2011 20:53:26 GMT\n< Server: Noelios-Restlet-Engine/1.0..8\n< Content-Type: text/plain; charset=ISO-8859-1\n< Content-Length: 53\n< \n* Connection #0 to host localhost left intact\n* Closing connection #0\nmaxConcurrentCleanUps shall be a positive integer: -1\n

                      The following invalid JSON example uses an unknown unit of measure (ZZiB). It returns a 400 response code and contains an error message as plain text:

                      curl -v -u admin:geoserver \"http://localhost:8090/geoserver/gwc/rest/diskquota.json\" -X PUT -d \"{\"gwcQuotaConfiguration\":{\"globalQuota\":{\"value\":\"100\",\"units\":\"ZZiB\"}}}\"\n
                      < HTTP/1.1 400 Bad Request\n< Date: Fri, 18 Mar 2011 20:56:23 GMT\n< Server: Noelios-Restlet-Engine/1.0..8\n< Content-Type: text/plain; charset=ISO-8859-1\n< Content-Length: 601\n< \nNo enum const class org.geowebcache.diskquota.storage.StorageUnit.ZZiB : No enum const class org.geowebcache.diskquota.storage.StorageUnit.ZZiB\n---- Debugging information ----\nmessage             : No enum const class org.geowebcache.diskquota.storage.StorageUnit.ZZiB\ncause-exception     : java.lang.IllegalArgumentException\ncause-message       : No enum const class org.geowebcache.diskquota.storage.StorageUnit.ZZiB\nclass               : org.geowebcache.diskquota.DiskQuotaConfig\nrequired-type       : org.geowebcache.diskquota.storage.Quota\nline number         : -1\n* Connection #0 to host localhost left intact\n* Closing connection #0\n
                      "},{"location":"geowebcache/rest/layers/","title":"Managing Layers","text":"

                      The GeoWebCache REST API provides a RESTful interface through which users can add, modify, or remove cached layers.

                      Note

                      JSON is not recommended for managing layers as the JSON library has a number of issues with multi-valued properties such as \"parameterFilters\".

                      "},{"location":"geowebcache/rest/layers/#layer-list","title":"Layer list","text":"

                      URL: /gwc/rest/layers.xml

                      Method Action Return Code Formats GET Return the list of available layers 200 XML POST 400 PUT 400 DELETE 400

                      The following example will request a full list of layers:

                      curl -u admin:geoserver \"http://localhost:8080/geoserver/gwc/rest/layers\"\n
                      <layers>\n  <layer>\n    <name>img states</name>\n    <atom:link xmlns:atom=\"http://www.w3.org/2005/Atom\" rel=\"alternate\" href=\"http://localhost:8080/geoserver/gwc/rest/layers/img+states.xml\" type=\"text/xml\"/>\n  </layer>\n  <layer>\n    <name>raster test layer</name>\n    <atom:link xmlns:atom=\"http://www.w3.org/2005/Atom\" rel=\"alternate\" href=\"http://localhost:8080/geoserver/gwc/rest/layers/raster+test+layer.xml\" type=\"text/xml\"/>\n  </layer>\n  <layer>\n    <name>topp:states</name>\n    <atom:link xmlns:atom=\"http://www.w3.org/2005/Atom\" rel=\"alternate\" href=\"http://localhost:8080/geoserver/gwc/rest/layers/topp%3Astates.xml\" type=\"text/xml\"/>\n  </layer>\n </layers>\n
                      "},{"location":"geowebcache/rest/layers/#layer-operations","title":"Layer Operations","text":"

                      URL: /gwc/rest/layers/<layer>.xml

                      Note

                      JSON is not recommended for managing layers as the JSON library has a number of issues with multi-valued properties such as \"parameterFilters\".

                      Method Action Return Code Formats GET Return the XML representation of the layer 200 XML POST Modify the definition/configuration of the layer 200 XML PUT Add a new layer 200 XML DELETE Delete the layer 200

                      Note

                      There are two different representations for cached layers, depending on whether the tile layer is created from the GeoServer WMS layer or layer group (GeoServerLayer), or is configured in geowebcache.xml as a regular GWC layer (wmsLayer). A GeoServer layer is referred to as a GeoServerLayer and contains no image data source information such as origin WMS URL.

                      Representations:

                      • GeoWebCache (wmsLayer) XML minimal
                      • GeoWebCache (wmsLayer) XML
                      • GeoServer (GeoServerLayer) XML minimal
                      • GeoServer (GeoServerLayer) XML

                      The examples below use the cURL tool, though the examples apply to any HTTP-capable tool or library.

                      "},{"location":"geowebcache/rest/layers/#adding-a-geowebcache-layer","title":"Adding a GeoWebCache layer","text":"

                      The following example will add a new layer to GeoWebCache:

                      curl -v -u admin:geoserver -XPUT -H \"Content-type: text/xml\" -d @layer.xml  \"http://localhost:8080/geoserver/gwc/rest/layers/newlayer.xml\"\n

                      The layer.xml file is defined as the following:

                      <wmsLayer>\n  <name>newlayer</name>\n  <mimeFormats>\n    <string>image/png</string>\n  </mimeFormats>\n  <gridSubsets>\n    <gridSubset>\n      <gridSetName>EPSG:900913</gridSetName>\n    </gridSubset>\n  </gridSubsets>\n  <wmsUrl>\n    <string>http://localhost:8080/geoserver/wms</string>\n  </wmsUrl>\n  <wmsLayers>topp:states</wmsLayers>\n</wmsLayer>\n

                      Note

                      The addressed resource (newlayer in this example) must match the name of the layer in the XML representation.

                      "},{"location":"geowebcache/rest/layers/#adding-a-geoserver-layer","title":"Adding a GeoServer layer","text":"

                      The following example will add a new layer to both GeoServer and GeoWebCache:

                      curl -v -u admin:geoserver -XPUT -H \"Content-type: text/xml\" -d @poi.xml  \"http://localhost:8080/geoserver/gwc/rest/layers/tiger:poi.xml\"\n

                      The poi.xml file is defined as the following:

                      <GeoServerLayer>\n  <id>LayerInfoImpl--570ae188:124761b8d78:-7fd0</id>\n  <enabled>true</enabled>\n  <name>tiger:poi</name>\n  <mimeFormats>\n    <string>image/png8</string>\n  </mimeFormats>\n  <gridSubsets>\n    <gridSubset>\n      <gridSetName>GoogleCRS84Quad</gridSetName>\n      <zoomStart>0</zoomStart>\n      <zoomStop>14</zoomStop>\n      <minCachedLevel>1</minCachedLevel>\n      <maxCachedLevel>9</maxCachedLevel>\n    </gridSubset>\n  </gridSubsets>\n  <metaWidthHeight>\n    <int>4</int>\n    <int>4</int>\n  </metaWidthHeight>\n  <gutter>50</gutter>\n  <autoCacheStyles>true</autoCacheStyles>\n</GeoServerLayer>\n

                      Note

                      The addressed resource ( tiger:poi in this example) must match the name of the layer in the XML representation, as well as the name of an existing GeoServer layer or layer group.

                      "},{"location":"geowebcache/rest/layers/#modifying-a-layer","title":"Modifying a layer","text":"

                      This example modifies the layer definition via the layer.xml file. The request adds a parameter filter and a grid subset to the existing tiger:poi tile layer:

                      <GeoServerLayer>\n <enabled>true</enabled>\n <name>tiger:poi</name>\n <mimeFormats>\n   <string>image/png8</string>\n </mimeFormats>\n <gridSubsets>\n   <gridSubset>\n     <gridSetName>GoogleCRS84Quad</gridSetName>\n     <zoomStart>0</zoomStart>\n     <zoomStop>14</zoomStop>\n     <minCachedLevel>1</minCachedLevel>\n     <maxCachedLevel>9</maxCachedLevel>\n   </gridSubset>\n   <gridSubset>\n     <gridSetName>EPSG:900913</gridSetName>\n     <extent>\n       <coords>\n         <double>-8238959.403861314</double>\n         <double>4969300.121476209</double>\n         <double>-8237812.689219721</double>\n         <double>4971112.167757057</double>\n       </coords>\n     </extent>\n   </gridSubset>\n </gridSubsets>\n <metaWidthHeight>\n   <int>4</int>\n   <int>4</int>\n </metaWidthHeight>\n <parameterFilters>\n   <floatParameterFilter>\n     <key>ELEVATION</key>\n     <defaultValue>0.0</defaultValue>\n     <values>\n       <float>0.0</float>\n       <float>1.0</float>\n       <float>2.0</float>\n       <float>3.0</float>\n       <float>4.0</float>\n     </values>\n     <threshold>1.0E-3</threshold>\n   </floatParameterFilter>\n </parameterFilters>\n <gutter>50</gutter>\n <autoCacheStyles>true</autoCacheStyles>\n</GeoServerLayer>\n

                      Instead of PUT, use the HTTP POST method instead:

                      curl -v -u admin:geoserver -XPOST -H \"Content-type: text/xml\" -d @poi.xml  \"http://localhost:8080/geoserver/gwc/rest/layers/tiger:poi.xml\"\n
                      "},{"location":"geowebcache/rest/layers/#deleting-a-layer","title":"Deleting a layer","text":"

                      Deleting a GeoWebCache tile layer deletes the layer configuration as well as the layer's disk cache. No tile images will remain in the cache directory after deleting a tile layer.

                      To delete a layer, use the HTTP DELETE method against the layer resource:

                      curl -v -u admin:geoserver -XDELETE \"http://localhost:8080/geoserver/gwc/rest/layers/newlayer.xml\"\n

                      Note

                      If trying to delete a tile layer that is an integrated GeoServerLayer, only the GeoWebCache layer definition will be deleted; the GeoServer definition is left untouched. To delete a layer in GeoServer, use the GeoServer REST to manipulate GeoServer resources.

                      On the other hand, deleting a GeoServer layer via the GeoServer REST API will automatically delete the associated tile layer.

                      "},{"location":"geowebcache/rest/seed/","title":"Seeding and Truncating","text":"

                      The GeoWebCache REST API provides a RESTful interface through which users can add or remove tiles from the cache on a per-layer basis.

                      "},{"location":"geowebcache/rest/seed/#operations","title":"Operations","text":"

                      URL: /gwc/rest/seed/<layer>.<format>

                      Method Action Return Code Formats GET Return the status of the seeding threads 200 JSON POST Issue a seed or truncate task request 200 XML, JSON PUT 405 DELETE 405

                      Representations:

                      • XML
                      • JSON

                      The examples below use the cURL tool, though the examples apply to any HTTP-capable tool or library.

                      "},{"location":"geowebcache/rest/seed/#seeding","title":"Seeding","text":"

                      The following XML request initiates a seeding task:

                      curl -v -u admin:geoserver -XPOST -H \"Content-type: text/xml\" -d '<seedRequest><name>nurc:Arc_Sample</name><srs><number>4326</number></srs><zoomStart>1</zoomStart><zoomStop>12</zoomStop><format>image/png</format><type>truncate</type><threadCount>2</threadCount></seedRequest>'  \"http://localhost:8080/geoserver/gwc/rest/seed/nurc:Arc_Sample.xml\"\n
                      * About to connect() to localhost port 8080 (#0)\n*   Trying 127.0.0.1... connected\n* Connected to localhost (127.0.0.1) port 8080 (#0)\n* Server auth using Basic with user 'admin'\n> POST /geoserver/gwc/rest/seed/nurc:Arc_Sample.xml HTTP/1.1\n> Authorization: Basic YWRtaW46Z2Vvc2VydmVy\n> User-Agent: curl/7.21.3 (x86_64-pc-linux-gnu) libcurl/7.21.3 OpenSSL/0.9.8o zlib/1.2.3.4 libidn/1.18\n> Host: localhost:8080\n> Accept: */*\n> Content-type: text/xml\n> Content-Length: 209\n> \n< HTTP/1.1 200 OK\n

                      The following is a more complete XML fragment for a seed request, including parameter filters:

                      <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<seedRequest>\n  <name>topp:states</name>\n  <bounds>\n    <coords>\n      <double>-2495667.977678598</double>\n      <double>-2223677.196231552</double>\n      <double>3291070.6104286816</double>\n      <double>959189.3312465074</double>\n    </coords>\n  </bounds>\n\n  <!-- These are listed on http://localhost:8080/geoserver/gwc/demo -->\n  <gridSetId>EPSG:2163</gridSetId>\n  <zoomStart>0</zoomStart>\n  <zoomStop>2</zoomStop>\n  <format>image/png</format>\n\n  <!-- type can be seed, reseed, or truncate -->\n  <type>truncate</type> \n\n  <!-- Number of seeding threads to run in parallel. \n       If type == truncate only one thread will be used\n       regardless of this parameter -->\n  <threadCount>1</threadCount>\n  <!-- Parameter filters -->\n  <parameters>\n    <entry>\n      <string>STYLES</string>\n      <string>pophatch</string>\n    </entry>\n    <entry>\n      <string>CQL_FILTER</string>\n      <string>TOTPOP > 10000</string>\n    </entry>\n  </parameters>\n</seedRequest>\n
                      "},{"location":"geowebcache/rest/seed/#truncating","title":"Truncating","text":"

                      The following XML request initiates a truncating task:

                      curl -v -u admin:geoserver -XPOST -H \"Content-type: application/json\" -d \"{'seedRequest':{'name':'topp:states','bounds':{'coords':{ 'double':['-124.0','22.0','66.0','72.0']}},'srs':{'number':4326},'zoomStart':1,'zoomStop':12,'format':'image\\/png','type':'truncate','threadCount':4}}}\"  \"http://localhost:8080/geoserver/gwc/rest/seed/nurc:Arc_Sample.json\"\n
                      * About to connect() to localhost port 8080 (#0)\n*   Trying 127.0.0.1... connected\n* Connected to localhost (127.0.0.1) port 8080 (#0)\n* Server auth using Basic with user 'admin'\n> POST /geoserver/gwc/rest/seed/nurc:Arc_Sample.json HTTP/1.1\n> Authorization: Basic YWRtaW46Z2Vvc2VydmVy\n> User-Agent: curl/7.21.3 (x86_64-pc-linux-gnu) libcurl/7.21.3 OpenSSL/0.9.8o zlib/1.2.3.4 libidn/1.18\n> Host: localhost:8080\n> Accept: */*\n> Content-type: application/json\n> Content-Length: 205\n> \n< HTTP/1.1 200 OK\n< Date: Fri, 14 Oct 2011 22:09:21 GMT\n< Server: Noelios-Restlet-Engine/1.0..8\n< Transfer-Encoding: chunked\n< \n* Connection #0 to host localhost left intact\n* Closing connection #0\n
                      "},{"location":"geowebcache/rest/seed/#querying-running-tasks","title":"Querying running tasks","text":"

                      URL: /gwc/rest/seed[/<layer>].json

                      Method Action Return Code Formats GET Get the global or per layer state of running and pending tasks 200 JSON POST 405 PUT 405 DELETE 405"},{"location":"geowebcache/rest/seed/#getting-current-state-of-the-seeding-threads","title":"Getting current state of the seeding threads","text":"

                      Sending a GET request to the /gwc/rest/seed.json resource returns a list of pending (scheduled) and running tasks for all the layers.

                      Sending a GET request to the /gwc/rest/seed/<layer name>.json resource returns a list of pending (scheduled) and running tasks for that specific layer.

                      The returned content is a JSON array of the form:

                      {\"long-array-array\":[[<long>,<long>,<long>,<long>,<long>],...]}\n

                      If there are no pending or running tasks, the returned array is empty:

                      {\"long-array-array\":[]}\n

                      The returned array of arrays contains one array per seeding/truncating task. The meaning of each long value in each thread array is:

                      [tiles processed, total number of tiles to process, estimated remaining time (in seconds), Task ID, Task status]\n

                      The returned Task Status value will be one of the following:

                      -1 = ABORTED \n 0 = PENDING\n 1 = RUNNING\n 2 = DONE\n

                      The example below returns the current state of tasks for the topp:states layer:

                      curl -u <user>:<password> -v -XGET http://localhost:8080/geoserver/gwc/rest/seed/topp:states.json\n
                      {\"long-array-array\":[[17888,44739250,18319,1,1],[17744,44739250,18468,2,1],[16608,44739250,19733,3,0],[0,1000,1000,4,0]]}\n

                      In the above response, tasks 1 and 2 for the topp:states layer are running, and tasks 3 and 4 are in a pending state waiting for an available thread.

                      The example below returns a list of tasks for all the layers.

                      curl -u <user>:<password> -XGET http://localhost:8080/geoserver/gwc/rest/seed.json\n
                      {\"long-array-array\":[[2240,327426,1564,2,1],[2368,327426,1477,3,1],[2272,327426,1541,4,1],[2176,327426,1611,5,1],[1056,15954794690,79320691,6,1],[1088,15954794690,76987729,7,1],[1040,15954794690,80541010,8,1],[1104,15954794690,75871965,9,1]]}\n
                      "},{"location":"geowebcache/rest/seed/#terminating-running-tasks","title":"Terminating running tasks","text":"

                      URL: /gwc/rest/seed[/<layer>]

                      Method Action Return Code Formats GET 405 POST Issue a kill running and/or pending tasks request 200 PUT 405 DELETE 405

                      A POST request to the /gwc/rest/seed resource terminates pending and/or running tasks for all layers. A POST request to the /gwc/rest/seed/<layername> resource terminates pending and/or running tasks for a specific layer.

                      It is possible to terminate individual or all pending and/or running tasks. Use the parameter kill_all with one of the following values: running, pending, or all.

                      Note

                      For backward compatibility, the kill_all parameter value 1 is also accepted and is equivalent to running.

                      The following request terminates all running seed and truncate tasks.

                      curl -v -u admin:geoserver -d \"kill_all=all\"  \"http://localhost:8080/geoserver/gwc/rest/seed\"\n
                      * About to connect() to localhost port 8080 (#0)\n*   Trying 127.0.0.1... connected\n< HTTP/1.1 200 OK\n< Date: Fri, 14 Oct 2011 22:23:04 GMT\n< Server: Noelios-Restlet-Engine/1.0..8\n< Content-Type: text/html; charset=ISO-8859-1\n< Content-Length: 426\n< \n<html>\n...\n* Connection #0 to host localhost left intact\n* Closing connection #0\n
                      "},{"location":"geowebcache/webadmin/","title":"GeoWebCache settings","text":"

                      This section of the Web administration interface describes how to configure the tile caching options for GeoServer. GeoServer uses GeoWebCache to provide direct and integrated tile caching, and can dramatically increase your server's responsiveness and reliability.

                      The pages in this menu can be accessed on the left side of the screen under the heading Tile Caching.

                      Tile Caching menu

                      • Tile Layers
                      • Demo page
                      • Caching defaults
                      • Gridsets
                      • Disk Quotas
                      • BlobStores
                      "},{"location":"geowebcache/webadmin/blobstores/","title":"BlobStores","text":"

                      BlobStores allow us to configure how and where GeoWebCache will store its cached data on a per-layer basis. This page allows us to define the different BlobStores present in the system. BlobStores can be created, modified and removed from here.

                      "},{"location":"geowebcache/webadmin/blobstores/#general","title":"General","text":""},{"location":"geowebcache/webadmin/blobstores/#identifier","title":"Identifier","text":"

                      Each BlobStore has a unique identifier.

                      "},{"location":"geowebcache/webadmin/blobstores/#blobstore-type","title":"BlobStore Type","text":"

                      There can be different BlobStore types to use different ways of storage. There is only standard support for File BlobStores. Plugins may add additional types.

                      "},{"location":"geowebcache/webadmin/blobstores/#enabled","title":"Enabled","text":"

                      Disabled BlobStores will not be loaded. Disabling a BlobStore will disable caching for all layers and layergroups assigned to that BlobStore.

                      "},{"location":"geowebcache/webadmin/blobstores/#default","title":"Default","text":"

                      There should always be one default BlobStore, which cannot be removed. The default BlobStore will be used by all layers not assigned to a specific BlobStore. Removing a BlobStore will cause all layers assigned to this BlobStore to use the default BlobStore until specified otherwise.

                      "},{"location":"geowebcache/webadmin/blobstores/#file-blobstore","title":"File BlobStore","text":"

                      These store data on a disk in a specified directory.

                      It is also possible to choose the tile file layout:

                      • GeoWebCache default uses a path structure reducing the number of items in each directory, by splitting long lists in groups. In particular, the layout is z/xc_yc/x_y.ext where xc=x/(2^(z/2)), yc=y/(2^(z/2)). In other words, the tiles are split into square areas, the number of square areas growing with the zoom level, and each square being assigned to a intermediate directory. The Y coordinates are numbered from the south northwards.
                      • TMS uses a TMS layout, that is, z/y/x.ext where the Y coordinates are numbered from the south northwards.
                      • XYZ uses a \"slippy map\", or \"Google Maps like\" layout, that is, z/y/x.ext where the Y coordinates originate top left and grow southwards (opposite of TMS and GWC default order).

                      Note

                      When switching file layout type, the tile directories won't be deleted, it's up to the admin to clean up the tiles on the file system, GeoServer/GWC won't do it automatically.

                      "},{"location":"geowebcache/webadmin/blobstores/#base-directory","title":"Base Directory","text":"

                      The directory where the cached data is stored.

                      "},{"location":"geowebcache/webadmin/blobstores/#disk-block-size","title":"Disk block size","text":"

                      This setting determines how the tile cache calculates disk usage. The value for this setting should be equivalent to the disk block size of the storage medium where the cache is located. The default block size is 4096 bytes.

                      "},{"location":"geowebcache/webadmin/defaults/","title":"Caching defaults","text":"

                      The Caching Defaults page shows the global configuration options for the tile caching functionality in GeoServer, an embedded GeoWebCache.

                      "},{"location":"geowebcache/webadmin/defaults/#gwc-provided-services","title":"GWC Provided Services","text":"

                      In addition to the GeoServer endpoints, GeoWebCache provides other endpoints for OGC services. For example, the GeoServer WMS endpoint is available at:

                      http://GEOSERVER_URL/wms?...\n

                      The GeoWebCache WMS endpoint is:

                      http://GEOSERVER_URL/gwc/service/wms?...\n

                      Provided services

                      The following settings describe the different services that can be enabled with GeoWebCache.

                      "},{"location":"geowebcache/webadmin/defaults/#enable-direct-integration-with-geoserver-wms","title":"Enable direct integration with GeoServer WMS","text":"

                      Direct integration allows WMS requests served through GeoServer to be cached as if they were received and processed by GeoWebCache. This provides all the advantages of using a tile server while still employing the more-flexible GeoServer WMS as a fallback. See the section on Using GeoWebCache for more details about this feature.

                      With direct integration, tile caching is enabled for all standard WMS requests that contain the tiled=true parameter and conform to all required parameters.

                      This setting is disabled by default. When enabling this option, it is a good idea to also turn on Disk Quotas as well, to prevent unbounded growth of the stored tiles.

                      "},{"location":"geowebcache/webadmin/defaults/#explicitly-require-tiled-parameter","title":"Explicitly require TILED Parameter","text":"

                      When this parameter is checked direct WMS integration requires that the tiled=true parameter be set in all requests that will be cached. If this parameter is unchecked all incoming requests will be considered for caching, the request must still conform to all required parameters.

                      "},{"location":"geowebcache/webadmin/defaults/#enable-wms-c-service","title":"Enable WMS-C Service","text":"

                      Enables the Cached Web Map Service (WMS-C) service. When this setting is enabled, GeoWebCache will respond to its own WMS-C endpoint:

                      http://GEOSERVER_URL/gwc/service/wms?SERVICE=WMS&VERSION=1.1.1&TILED=true&...\n

                      When the service is disabled, calls to the capabilities document will return a Service is disabled message.

                      "},{"location":"geowebcache/webadmin/defaults/#enable-tms-service","title":"Enable TMS Service","text":"

                      Enables the Tiled Map Service (TMS) endpoint in GeoWebCache. With the TMS service, GeoWebCache will respond to its own TMS endpoint:

                      http://GEOSERVER/URL/gwc/service/tms/1.0.0\n

                      When the service is disabled, calls to the capabilities document will return a Service is disabled message.

                      "},{"location":"geowebcache/webadmin/defaults/#enable-wmts-service","title":"Enable WMTS Service","text":"

                      Enables the Web Map Tiled Service (WMTS) endpoint in GeoWebCache. When this setting is enabled, GeoWebCache will respond to its own WMTS endpoint:

                      http://GEOSERVER/URL/gwc/service/wmts?...\n

                      When the service is disabled, calls to the capabilities document will return a Service is disabled message.

                      HTTP RESTful API is available through the existing GWC integration allowing clients to retrieve the following resources:

                      • capabilities document
                      • tile
                      • feature info

                      For more information read GWC WMTS documentation.

                      "},{"location":"geowebcache/webadmin/defaults/#enable-data-security","title":"Enable Data Security","text":"

                      Enables the GeoServer Data Security in the embedded GeoWebCache.

                      "},{"location":"geowebcache/webadmin/defaults/#default-caching-options-for-geoserver-layers","title":"Default Caching Options for GeoServer Layers","text":"

                      This section describes the configuration of the various defaults and other global options for the tile cache in GeoServer.

                      Default caching options

                      "},{"location":"geowebcache/webadmin/defaults/#automatically-configure-a-geowebcache-layer-for-each-new-layer-or-layer-group","title":"Automatically configure a GeoWebCache layer for each new layer or layer group","text":"

                      This setting, enabled by default, determines how layers in GeoServer are handled via the embedded GeoWebCache. When this setting is enabled, an entry in the GeoWebCache layer listing will be created whenever a new layer or layer group is published in GeoServer. Use this setting to keep the GeoWebCache catalog in sync. (This is enabled by default.)

                      "},{"location":"geowebcache/webadmin/defaults/#automatically-cache-non-default-styles","title":"Automatically cache non-default styles","text":"

                      By default, only requests using the default style for a given layer will be cached. When this setting is enabled, all requests for a given layer, even those that use a non-standard style will be cached. Disabling this may be useful in situations where disk space is an issue, or when only one default style is important.

                      "},{"location":"geowebcache/webadmin/defaults/#default-metatile-size","title":"Default metatile size","text":"

                      A metatile is several tiles combined into a larger one. This larger metatile is generated and then subdivided before being served back (and cached) as standard tiles. The advantage of using metatiling is in situations where a label or geometry lies on a boundary of a tile, which may be truncated or altered. With metatiling, these tile edge issues are greatly reduced.

                      Moreover, with metatiling, the overall time it takes to seed the cache is reduced in most cases, when compared with rendering a full map with single tiles. In fact, using larger metatiling factors is a good way to reduce the time spent in seeding the cache.

                      The disadvantage of metatiling is that at large sizes, memory consumption can be an issue.

                      The size of the default metatile can be adjusted here. By default, GeoServer sets a metatile size of 4x4, which strikes a balance between performance, memory usage, and rendering accuracy.

                      "},{"location":"geowebcache/webadmin/defaults/#default-gutter-size","title":"Default gutter size","text":"

                      The gutter size sets the amount of extra space (in pixels) used when generating a tile. Use this in conjunction with metatiles to reduce problems with labels and features not being rendered incorrectly due to being on a tile boundary.

                      "},{"location":"geowebcache/webadmin/defaults/#default-cache-formats","title":"Default Cache Formats","text":"

                      This setting determines the default image formats that can be cached when tiled requests are made. There are four image formats that can be used when saving tiles:

                      • PNG (24-bit PNG)
                      • PNG8 (8-bit PNG)
                      • JPEG
                      • GIF

                      The default settings are subdivided into vector layers, raster layers, and layer groups. You may select any of the above four formats for each of the three types of layers. Any requests that fall outside of these layer/format combinations will not be cached if sent through GeoServer, and will return an error if sent to the GeoWebCache endpoints.

                      These defaults can be overwritten on a per-layer basis when editing the layer properties.

                      Default image formats

                      "},{"location":"geowebcache/webadmin/defaults/#in-memory-blobstore-options","title":"In Memory BlobStore Options","text":"

                      These options are used for enabling/disabling In Memory Caching for GeoWebCache. This feature can be used for saving GWC tiles directly in memory, for a fast data retrieval.

                      "},{"location":"geowebcache/webadmin/defaults/#enable","title":"Enable","text":"

                      This parameter allows to enable or disable in memory caching. By default it is disabled.

                      "},{"location":"geowebcache/webadmin/defaults/#avoid-persistence","title":"Avoid Persistence","text":"

                      This parameter can be used to prevent the saving of any file in the file system, keeping all the GWC tiles only in memory. By default it is disabled.

                      "},{"location":"geowebcache/webadmin/defaults/#available-caches","title":"Available Caches","text":"

                      This parameter defines which Cache method can be used for In Memory Caching. By default the Guava Caching is used. Note that if a caching method requires an immutable configuration at GeoServer startup like HazelCast, the Hard Memory limit, Eviction Policy, Eviction Time and Concurrency Level parameters are disabled.

                      More information on how to configure a new Cache object can be found in the GeoWebCache Configuration page.

                      "},{"location":"geowebcache/webadmin/defaults/#cache-hard-memory-limit-mb","title":"Cache Hard Memory limit (Mb)","text":"

                      Parameter for configuring in memory cache size in MB.

                      "},{"location":"geowebcache/webadmin/defaults/#cache-eviction-policy","title":"Cache Eviction Policy","text":"

                      Parameter for configuring in memory cache eviction policy, it may be: LRU, LFU, EXPIRE_AFTER_WRITE, EXPIRE_AFTER_ACCESS, NULL

                      This eviction policies may not be supported by all caches implementations. For example, Guava Caching only supports the eviction policies: EXPIRE_AFTER_WRITE, EXPIRE_AFTER_ACCESS and NULL.

                      Note, only the eviction policies accepted by the selected cache will be shown on the UI.

                      "},{"location":"geowebcache/webadmin/defaults/#cache-eviction-time-in-seconds","title":"Cache Eviction Time (in Seconds)","text":"

                      Parameter for configuring in memory cache eviction time. It is in seconds.

                      Note

                      Note that this parameter is also used for configuring an internal thread which performs a periodical cache cleanup.

                      "},{"location":"geowebcache/webadmin/defaults/#cache-concurrency-level","title":"Cache Concurrency Level","text":"

                      Parameter for configuring in memory cache concurrency.

                      "},{"location":"geowebcache/webadmin/defaults/#clear-in-memory-cache","title":"Clear In Memory Cache","text":"

                      Button for clearing all the tiles in the in memory cache.

                      "},{"location":"geowebcache/webadmin/defaults/#cache-statistics","title":"Cache Statistics","text":"

                      Various statistics parameters associated with the in memory cache.

                      "},{"location":"geowebcache/webadmin/defaults/#update-cache-statistics","title":"Update Cache Statistics","text":"

                      Button for updating cache statistics seen above. The statistics are always related to the local cached entries, even in case of distributed in memory caching

                      Note

                      Note that some Caches do not provide all the statistics parameters, in that case the user will only see \"Unavailable\" for those parameters.

                      In Memory BlobStore Options

                      Note

                      Note that in the TileCaching tab for each Layer, you may decide to disable in memory caching for the selected Layer by clicking on the Enable In Memory Caching for this Layer checkbox. This option is disabled for those caches which don't support this feature.

                      "},{"location":"geowebcache/webadmin/defaults/#skip-caching-on-dimension-warnings","title":"Skip caching on dimension warnings","text":"

                      WMS dimension handling can be complex, with ability to return tiles where the specified time was not a match, or when the request contained no time at all. This may not be a good match for tile caching, as it breaks the unique link between URL and tile content.

                      The following settings allow to disable caching when a WMS dimension warning is issued:

                      Skip caching on cache warnings

                      The best settings depend on the type of dataset and disk-quota configurations:

                      • For static datasets with dimensions, the default value skip could be removed, as it's going to generate at most one copy of the tiles. The nearest match and failed nearest could be cached if there is a disk quota (to speed up clients that repeatedly fail to perform an exact time match), but it's best not to cache it if there is no disk quota, as the mismatches can be potentially infinite, leading to an uncontrolled growth of the cache.
                      • For a datasets growing over time, it's better to disable caching on the default value, as it's often the \"latest\", that is, the most recently added to the dataset. This means the tiles contents change based on when they are asked for. The considerations for nearest and failed matches are the same as for the static datasets.

                      Caution is advised if the data ingestion might happen to skip some time/elevation values, to fill them only at a later time. In this case, nearest matches could cause the system to cache a tile for a nearby time value, which would hide the actual values if they get ingested at a later time.

                      "},{"location":"geowebcache/webadmin/defaults/#default-cached-gridsets","title":"Default Cached Gridsets","text":"

                      This section shows the gridsets that will be automatically configured for cached layers. While there are some pre-configured gridsets available, only two are enabled by default. These correspond to the most common and universal cases:

                      • EPSG:4326 (geographic) with 22 maximum zoom levels and 256x256 pixel tiles
                      • EPSG:900913 (spherical Mercator) with 31 maximum zoom levels and 256x256 pixel tiles

                      Default gridsets

                      To add a pre-existing grid set, select it from the Add default grid set menu, and click the Add icon (green circle with plus sign).

                      Adding an existing gridset to the list of defaults

                      These definitions are described in more detail on the Gridsets page.

                      "},{"location":"geowebcache/webadmin/demopage/","title":"Demo page","text":"

                      In addition to the Tile Layers page, there is also a demo page where you can view configured layers, reload the configuration (when changing settings or adding new layers), and seed or refresh the existing cache on a per-layer basis.

                      As this interface is part of the standalone GeoWebCache, some of the functionality here is duplicated from the Tile Layers page.

                      Built-in demo page

                      "},{"location":"geowebcache/webadmin/demopage/#viewing","title":"Viewing","text":"

                      To view the demo page, append /gwc/demo to the address of your GeoServer instance. For example, if your GeoServer is at the following address:

                      http://localhost:8080/geoserver\n

                      The GeoWebCache demo page is accessible here:

                      http://localhost:8080/geoserver/gwc/demo\n

                      If there is a problem loading this page, verify the steps on the Using GeoWebCache page have been carried out successfully.

                      "},{"location":"geowebcache/webadmin/demopage/#reload-configuration","title":"Reload configuration","text":"

                      The demo page contains a list of every layer that GeoWebCache is aware of. This is typically (though not necessarily) identical to the list of layers as published in the GeoServer WMS capabilities document. If configuration changes are made to GeoServer, GeoWebCache will not automatically become aware of them. To ensure that GeoWebCache is using the latest configuration information, click the Reload Configuration button. Reloading the configuration will trigger authentication to GeoServer, and will require an administration username and password. Use the same username and password that you would use to log on to the Web administration interface. After a successful logon, the number of layers found and loaded will be displayed.

                      Reloading the configuration

                      "},{"location":"geowebcache/webadmin/demopage/#layers-and-output-formats","title":"Layers and output formats","text":"

                      For each layer that GeoWebCache serves, links are typically available for a number of different projections and output formats. By default, OpenLayers applications are available using image formats of PNG, PNG8, GIF, and JPEG in both EPSG:4326 (standard lat/lon) and EPSG:900913 (used in Google Maps) projections. In addition, KML output is available (EPSG:4326 only) using the same image formats, plus vector data (\"kml\").

                      Also on the list is an option to seed the layers (Seed this layer). More on this option below.

                      "},{"location":"geowebcache/webadmin/demopage/#seeding","title":"Seeding","text":"

                      You can configure seeding processes via the Web administration interface. See the Tile Layers page for more information.

                      It is also possible to configure seeding process via the Demo page. The page contains a link next to each layer entitled Seed this layer. This link will trigger authentication with the GeoServer configuration. Use the same username and password that you would use to log on to the Web administration interface. After a successful logon, a new page shows up with seeding options.

                      The seeding options page contains various parameters for configuring the way that the layer is seeded.

                      Option Description

                      Number of threads to use Possible values are between 1 and 16.

                      Type of operation Sets the operation. There are three possible values: Seed (creates tiles, but does not overwrite existing ones), Reseed (like Seed, but overwrites existing tiles) and Truncate (deletes all tiles within the given parameters)

                      SRS Specifies the projection to use when creating tiles (default values are EPSG:4326 and EPSG:900913)

                      Format Sets the image format of the tiles. Can be application/vnd.google-earth.kml+xml (Google Earth KML), image/gif (GIF), image/jpeg (JPEG), image/png (24 bit PNG), and image/png8 (8 bit PNG)

                      Zoom start Sets the minimum zoom level. Lower values indicate map views that are more zoomed out. When seeding, GeoWebCache will only create tiles for those zoom levels inclusive of this value and Zoom stop.

                      Zoom stop Sets the maximum zoom level. Higher values indicate map views that are more zoomed in. When seeding, GeoWebCache will only create tiles for those zoom levels inclusive of this value and Zoom start.

                      Bounding box (optional) Allows seeding to occur over a specified extent, instead of the full extent of the layer. This is useful if your layer contains data over a large area, but the application will only request tiles from a subset of that area. The four boxes correspond to Xmin, Ymin, Xmax, and Ymax.

                      Warning

                      Currently there is no progress bar to inform you of the time required to perform the operation, nor is there any intelligent handling of disk space. In short, the process may take a very long time, and the cache may fill up your disk. You may wish to set a Disk quota before running a seed job.

                      "},{"location":"geowebcache/webadmin/diskquotas/","title":"Disk Quotas","text":"

                      The Disk Quotas page manages the disk usage for cached tiles and allows you to set the global disk quota. Individual layer quotas can be set in the layer's properties page.

                      By default, disk usage for cached tiles is unbounded. However, this can cause disk capacity issues, especially when using Direct WMS integration (see Disk Quotas for more on this). Setting a disk quota establishes disk usage limits.

                      When finished making any changes, remember to click Submit.

                      Disk quota

                      "},{"location":"geowebcache/webadmin/diskquotas/#enable-disk-quota","title":"Enable disk quota","text":"

                      When enabled, the disk quota will be set according to the options listed below. The setting is disabled by default.

                      "},{"location":"geowebcache/webadmin/diskquotas/#disk-quota-check-frequency","title":"Disk quota check frequency","text":"

                      This setting determines how often the cache is polled for any overage. Smaller values (more frequent polling) will slightly increase disk activity, but larger values (less frequent polling) may cause the disk quota to be temporarily exceeded. The default is 10 seconds.

                      "},{"location":"geowebcache/webadmin/diskquotas/#maximum-tile-cache-size","title":"Maximum tile cache size","text":"

                      The maximum size for the cache. When this value is exceeded and the cache is polled, tiles will be removed according to the policy. Note that the unit options are mebibytes (MiB) (approx. 1.05MB), gibibytes (GiB) (approx. 1.07GB), and tebibytes (TiB) (approx. 1.10TB). Default is 500 MiB.

                      The graphic below this setting illustrates the size of the cache relative to the disk quota.

                      "},{"location":"geowebcache/webadmin/diskquotas/#tile-removal-policy","title":"Tile removal policy","text":"

                      When the disk quota is exceeded, this policy determines how the tiles to be deleted are identified. Options are Least Frequently Used (removes tiles based on how often the tile was accessed) or Least Recently Used (removes tiles based on date of last access). The optimum configuration is dependent on your data and server usage.

                      "},{"location":"geowebcache/webadmin/gridsets/","title":"Gridsets","text":"

                      A gridset defines a spatial reference system, bounding box (extent), a list of zoom levels (resolutions or scale denominators), and tile dimensions. Tile requests must conform to the gridset matrix, otherwise caching will not occur.

                      This page allows you to edit existing saved gridsets or create new ones. There is a set of pre-configured gridsets, a few legacy ones based on \"EPSG:4326\" and \"EPSG:900913\", and a larger set coming from the OGC Tile Matrix Set specification <http://docs.opengeospatial.org/is/17-083r2/17-083r2.html>. For additional CRS support, new gridsets can be created. Another reason to create a new gridset would be to set a different tile size or different number of zoom levels.

                      Gridsets menu

                      "},{"location":"geowebcache/webadmin/gridsets/#creating-a-new-gridset","title":"Creating a new gridset","text":"

                      To create a new gridset, click Create new gridset. You will then be asked to enter a range of parameters.

                      Creating a new gridset

                      "},{"location":"geowebcache/webadmin/gridsets/#name","title":"Name","text":"

                      The short name of the new gridset.

                      "},{"location":"geowebcache/webadmin/gridsets/#description","title":"Description","text":"

                      Metadata on the gridset.

                      "},{"location":"geowebcache/webadmin/gridsets/#coordinate-reference-system","title":"Coordinate Reference System","text":"

                      The Coordinate Reference System (CRS) to use in the gridset. You can select from any CRS that GeoServer recognizes. After selection, both the units (meters, feet, degrees, etc.) and the number of meters per unit will be displayed.

                      "},{"location":"geowebcache/webadmin/gridsets/#gridset-bounds","title":"Gridset bounds","text":"

                      Sets the maximum extent for the gridset. Typically this is set to be the maximum extent of the CRS used, but a smaller value can be substituted if desired. To populate the max extent in the fields, click Compute from maximum extent of CRS.

                      "},{"location":"geowebcache/webadmin/gridsets/#tile-width-and-height","title":"Tile width and height","text":"

                      Sets the tile dimensions. Default is 256x256 pixels. The tile dimensions can be anything from 16 to 2048 pixels. In addition, the tiles need not be square.

                      "},{"location":"geowebcache/webadmin/gridsets/#tile-matrix-set","title":"Tile matrix set","text":"

                      The tile matrix set (or tile pyramid) is a list of zoom levels containing ever increasing amounts of tiles. This three dimensional collection of tile \"slots\" creates the framework where actual image tiles will be saved. You can define the tile matrix based on resolutions or scale denominators.

                      Click Add zoom level to generate the first zoom level. The parameters will be automatically configured such that the full extent of will be contained by a single pixel's height. The number of pixels in a given zoom level will be displayed, along with the Pixel Size, Scale, and an optional Name, where you can give a name to each zoom level if desired.

                      Typically each additional zoom level is twice as large in each dimension, and so contains four times as many tiles as the previous zoom level. The actual values will be populated automatically during subsequent clicking of the Add zoom level link. These defaults are usually sufficient, and you need only determine the maximum number of zoom levels desired for this gridset.

                      When finished, click Save. Before you will be able to use this new gridset with a layer, you will need to add this gridset to the layer's list of available gridsets. This is done on an individual layer's properties page. You can also add this gridset to the default list on the Caching defaults page.

                      Tile matrix set

                      "},{"location":"geowebcache/webadmin/gridsets/#editing-a-gridset","title":"Editing a gridset","text":"

                      Click an existing gridset to open it for editing. Please note that the built-in gridsets cannot be edited. They can, however, be copied.

                      Editing a gridset

                      This gridset is read-only

                      "},{"location":"geowebcache/webadmin/gridsets/#copying-a-gridset","title":"Copying a gridset","text":"

                      As there are many configuration options for a gridset, it is often more convenient to copy an existing gridset. For any of the existing gridsets, click the Create a copy link to copy the gridset information to a new gridset.

                      "},{"location":"geowebcache/webadmin/gridsets/#removing-a-gridset","title":"Removing a gridset","text":"

                      To remove a gridset, select the check box next to the gridset or gridsets, and click Remove selected gridsets.

                      Warning

                      Removing a gridset definition will remove not only the gridset definition, but also any tiles on any layers generated with this gridset.

                      Removing a gridset

                      "},{"location":"geowebcache/webadmin/layers/","title":"Tile Layers","text":"

                      This page shows a listing of all of the layers known to the integrated GeoWebCache. It is similar to the Layer Preview for GeoWebCache, with many of the same options.

                      Note

                      There is also a link to the GeoWebCache standalone demo page.

                      "},{"location":"geowebcache/webadmin/layers/#layer-information","title":"Layer information","text":"

                      For each layer cached by GeoWebCache, the following information is available.

                      "},{"location":"geowebcache/webadmin/layers/#disk-quota","title":"Disk Quota","text":"

                      The maximum amount of disk space that can be used for this layer. By default, this will be set to N/A (unbounded) unless Disk Quotas are enabled.

                      "},{"location":"geowebcache/webadmin/layers/#disk-used","title":"Disk Used","text":"

                      The current disk space being used by tiles for this particular layer.

                      Note

                      This counter will only be updated if disk quotas are enabled. If disk quotas are not enabled, tiles will still be saved to disk, but the counter will remain as 0.0 B.

                      "},{"location":"geowebcache/webadmin/layers/#enabled","title":"Enabled","text":"

                      Indicates whether tile caching is enabled for this layer. It is possible to have a layer definition here but to not have tile caching enabled (set in the layer properties).

                      "},{"location":"geowebcache/webadmin/layers/#preview","title":"Preview","text":"

                      Similar to Layer Preview, this will generate a simple OpenLayers application populated with tiles from one of the available gridset/image format combinations. Select the desired option from the menu to view in OpenLayers.

                      "},{"location":"geowebcache/webadmin/layers/#seedtruncate","title":"Seed/Truncate","text":"

                      Opens the GeoWebCache page for automatically seeding and truncating the tile cache. Use this if you want to pre-populate some of your cache.

                      "},{"location":"geowebcache/webadmin/layers/#empty","title":"Empty","text":"

                      Will remove all saved tiles from the cache. This is identical to a full truncate operation for the layer.

                      "},{"location":"geowebcache/webadmin/layers/#add-or-remove-cached-layers","title":"Add or remove cached layers","text":"

                      The list of layers displayed on this page is typically the same as, or similar to, the full list of layers known to GeoServer. However, it may not be desirable to have every layer published in GeoServer have a cached layer component. In this case, simply select the box next to the layer to remove, and click Remove selected cached layers. The layer will be removed from GeoWebCache, and the disk cache for this layer will be entirely removed.

                      Warning

                      Deleting the tile cache cannot be undone.

                      Removing a cached layer

                      To add in a layer from GeoServer (if it wasn't set up to be added automatically), click the Add a new cached layer link.

                      Adding a new cached layer

                      "},{"location":"geowebcache/webadmin/layers/#clearing-geowebcache","title":"Clearing GeoWebCache","text":"

                      The Empty all link allows to clear the entire cache, for all layers, grid sets and filter parameters combination.

                      Warning

                      This will truncate all layers in GeoWebCache

                      Confirmation to GeoWebCache

                      A confirmation will appear on the page as message with names of cleared Tile layers.

                      "},{"location":"geowebcache/webadmin/layers/#configuring-a-cached-layer","title":"Configuring a cached layer","text":"

                      You have two options for layer configuration. The first option is to load the layer using the default (global) settings. To do this, select the layer you wish to start caching, and click the Configure selected layers with caching defaults link. The second option is to configure the caching parameters manually, via the layer configuration pages. To do this, just click the layer name itself.

                      "},{"location":"geowebcache/webadmin/layers/#parameter-filters","title":"Parameter Filters","text":"

                      Parameter filters allow GeoWebCache to cache a layer with varying parameters such as STYLES, TIME. One is needed for each parameter to be cached and it needs to know how to recognize valid values to be cached and which values are the same as other values so they only get cached once. There are several different kinds of filter as a result.

                      "},{"location":"geowebcache/webadmin/layers/#adding-a-filter","title":"Adding a Filter","text":"

                      At the bottom of the filter list in the text box beside Add filter specify the name of the parameter. In the drop down box select the kind of filter you want then click the button. For a filter that automatically tracks the layers styles in a parameter named STYLES click the Add Style Filter button.

                      "},{"location":"geowebcache/webadmin/layers/#removing-a-filter","title":"Removing a Filter","text":"

                      To remove a filter, click the button to the right of the filter's entry in the filter list.

                      "},{"location":"geowebcache/webadmin/layers/#types-of-filter","title":"Types of filter","text":"

                      All parameter filters take a default parameter that will be used if the parameter was not specified. Specific types of parameter filter provide different ways of specifying which parameter values are allowed, and which are equivalent to one another and should be cached together.

                      "},{"location":"geowebcache/webadmin/layers/#list-of-strings","title":"List of Strings","text":"

                      The stringParameterFilter takes a collection of plain text strings. If the value matches one of the strings, it is valid, otherwise it is not. Matching can be done in a case sensitive way, or the strings can all be converted to upper or lower case before matching. As case rules vary between languages, the locale to use for case changes can be specified.

                      "},{"location":"geowebcache/webadmin/layers/#regular-expression","title":"Regular Expression","text":"

                      The regexParameterFilter takes a regular expression to match strings. This should be used with caution as it potentially allows an arbitrarily large number of caches to be created. Like the string filter, it can be normalized for case.

                      "},{"location":"geowebcache/webadmin/layers/#list-of-numbers","title":"List of Numbers","text":"

                      The floatParameterFilter is like the string filter in taking a list of values, but it uses floating point numbers rather than arbitrary text strings. A threshold can be given to pull close numbers to a standard value.

                      "},{"location":"geowebcache/webadmin/layers/#list-of-whole-numbers","title":"List of Whole Numbers","text":"

                      The integerParameterFilter is like the float filter but works with integer/whole number values.

                      "},{"location":"geowebcache/webadmin/layers/#styles","title":"Styles","text":"

                      The styleParameterFilter is connected to the GeoServer catalog and knows what styles are available for the layer and when they change. You can specify a default distinct from the normal layer default if you wish, and restrict the range of additional styles available if you do not wish to cache all of them.

                      "},{"location":"gettingstarted/","title":"Getting started","text":"

                      This section contains short tutorials for common tasks in GeoServer to get new users using the system quickly.

                      • Using the web administration interface
                      • Publishing a GeoPackage
                      • Publishing a Image
                      • Publishing a Layer Group
                      • Publishing a style
                      • Publishing a shapefile
                      • Publishing a PostGIS table
                      "},{"location":"gettingstarted/geopkg-quickstart/","title":"Publishing a GeoPackage","text":"

                      This tutorial walks through the steps of publishing a GeoPackage with GeoServer.

                      Note

                      This tutorial assumes that GeoServer is running at http://localhost:8080/geoserver.

                      "},{"location":"gettingstarted/geopkg-quickstart/#data-preparation","title":"Data preparation","text":"

                      First let's gather that the data that we'll be publishing.

                      1. The sample data folder includes data/ne/natural_earth.gpkg
                      2. This file contains small scale 1:110m data:
                        • coastlines
                        • countries
                        • boundary lines
                        • populated places

                      Note

                      This data/ne/natural_earth.gpkg file has been processed from https://www.naturalearthdata.com/downloads/ page, to download the original (much larger) file visit the above page and download GeoPackage link.

                      "},{"location":"gettingstarted/geopkg-quickstart/#creating-a-new-workspace","title":"Creating a new workspace","text":"

                      The next step is to create a workspace for the geopackage. A workspace is a folder used to group similar layers together.

                      Note

                      This step is optional if you'd like to use an existing workspace. Usually, a workspace is created for each project, which can include stores and layers that are related to each other.

                      1. In a web browser, navigate to http://localhost:8080/geoserver.

                      2. Log into GeoServer as described in the Logging In section.

                      3. Navigate to Data \u2192 Workspaces.

                        Workspaces page

                      4. Click the Add new workspace button to display the New Workspace page.

                      5. You will be prompted to enter a workspace Name and Namespace URI.

                        Field Value Name: tutorial Namespace URI http://localhost:8080/geoserver/tutorial

                        Note

                        A workspace name is an identifier describing your project. It must not exceed ten characters or contain spaces.

                        Note

                        A Namespace URI (Uniform Resource Identifier) can usually be a URL associated with your project with an added trailing identifier indicating the workspace. The Namespace URI filed does not need to resolve to an actual valid web address.

                      6. Press the Submit button.

                        New workspace

                      7. The tutorial workspace will be added to the Workspaces list.

                      "},{"location":"gettingstarted/geopkg-quickstart/#create-a-store","title":"Create a store","text":"

                      Once the workspace is created, we are ready to add a new store. The store tells GeoServer how to connect to the geopackage.

                      1. Navigate to Data\u2192Stores.

                        Stores page

                      2. This page displays a list of stores, including the type of store and the workspace that the store belongs to.

                      3. In order to add the geopackage, you need to create a new store. Click the Add new Store button. You will be redirected to a list of the data sources supported by GeoServer. Note that the data sources are extensible, so your list may look slightly different.

                        New data source

                      4. From the list of Vector Data Sources locate and click the GeoPackage link.

                        The New Vector Data Source page will display.

                      5. Begin by configuring the Basic Store Info.

                        Field Value workspace tutorial Data Source Name NaturalEarth Description GeoPackage of NaturalEarth data

                        This information is internal to GeoServer and is not used as part of the web service protocols. We recommend keeping the Data Source Name simple as they will be used to form folders in the data directory (so keep any operating system restrictions on character use in mind).

                        Basic Store info

                      6. Connection parameters are used to establish the connection with your database. As GeoPackage is a file based database this will primarily consist of the geopackage location.

                      7. Under Connection Parameters, browse to the location URL of the geopackage, in our example data/ne.shp.

                        Browse database location

                      8. The Connection Parameters for our geopackage are:

                        Field Value Database file:data/ne/natural_earth.gpkg Read only checked

                        The use of read_only above indicates that we will not be writing to this GeoPackage, allowing GeoServer to avoid managing write locks when accessing this content for greater performance.

                        Connection Parameters

                      9. Press Save.

                      10. You will be redirected to the New Layer page (as this is the most common next step when adding a new data store).

                      "},{"location":"gettingstarted/geopkg-quickstart/#creating-a-layer","title":"Creating a layer","text":"

                      Now that we have connected to the GeoPackage, we can publish the layer.

                      1. On the New Layer page, click Publish beside the countries layer name.

                        New Layer

                      2. The Edit Layer page defines the data and publishing parameters for a layer.

                        Edit Layer Data tab

                      3. There are three critical pieces of information required on the Data tab before we can even save.

                        • Basic Resource Info - describes how the layer is presented to others
                        • Coordinate Reference System - establishes how the spatial data is to be interpreted or drawn on the world
                        • Bounding Boxes - establishes where the dataset is located in the world
                      4. Locate Basic Resource Info and define the layer:

                        Field Value Name countries Title Countries Abstract Sovereign states

                        The naming of a layer is important, and while GeoServer does not offer restrictions many of the individual protocols will only work with very simple names.

                        Basic Resource Info

                      5. Double check the Coordiante Reference Systems information is correct.

                        Field Value Native SRS EPSG:4326 Declaired SRS EPSG:4326 SRS Handling Force declared

                        Coordinate Reference Systems

                      6. Locate Bounding Boxes and generate the layer's bounding boxes by clicking the Compute from data and then Compute from native bounds links.

                        Generating bounding boxes

                      7. Press Apply to save your work thus far without closing the page.

                        This is a good way to check that your information has been entered correctly, GeoServer will provide a warning if any required information is incomplete.

                      8. Scroll to the top of the page and navigate to the Publishing tab.

                      9. Locate the WMS Settings heading, where we can set the style.Ensure that the Default Style is set to `polygon``.

                        WMS Settings

                      10. Press Save to complete your layer edits.

                      "},{"location":"gettingstarted/geopkg-quickstart/#previewing-the-layer","title":"Previewing the layer","text":"

                      In order to verify that the tutorial:countries layer is published correctly, we can preview the layer.

                      1. Navigate to the Data > Layer Preview page and find the tutorial:countries layer.

                        Note

                        Use the Search field with tutorial as shown to limit the number of layers to page through.

                        Layer Preview

                      2. Click the OpenLayers link in the Common Formats column.

                      3. An OpenLayers map will load in a new tab and display the shapefile data with the default line style.

                        You can use this preview map to zoom and pan around the dataset, as well as display the attributes of features.

                        Preview map of countries

                      "},{"location":"gettingstarted/group-quickstart/","title":"Publishing a Layer Group","text":"

                      This tutorial walks through the steps of publishing a layer group combing several layers into a basemap.

                      Note

                      This tutorial assumes that GeoServer is running at http://localhost:8080/geoserver.

                      "},{"location":"gettingstarted/group-quickstart/#data-preparation","title":"Data preparation","text":"

                      First let's gather that the data that we'll be publishing.

                      1. Complete the previous tutorials:
                        • Publishing a GeoPackage defining the tutorial:countries layer
                        • Publishing a Image defining the tutorial:shaded layer
                      "},{"location":"gettingstarted/group-quickstart/#create-a-layer-group","title":"Create a layer group","text":"
                      1. Navigate to Data > Layer Group page.

                        Layer Groups

                      2. This page displays a list of layer groups, workspace that the group belongs to.

                        Note

                        Layer groups are allowed to be \"global\" allowing a map to be created combing layers from several workspaces into a single visual.

                      3. At the top of the list Layer Groups locate and click the Add new layer group link.

                      4. The Layer group editor defines

                        • Basic Resource Info - describes how the layer is presented to others
                        • Coordinate Reference System - establishes how the spatial data is to be interpreted or drawn on the world
                        • Bounding Boxes - establishes where the dataset is located in the world
                        • Layers - the layers to be drawn (listed in draw order)
                      5. Locate Basic Resource Info and define the layer:

                        Name basemap

                        Title Basemap

                        Abstract Plain basemap suitable as a backdrop for geospatial data.

                        Workspace tutorial

                        Basic resource information

                      6. Scroll down to the Layers list which is presently empty.

                      7. Click Add Layer link, select the tutorial:shaded layer first.

                        The raster should be drawn first, as other content will be shown over top of it.

                      8. Click Add Layer link, select the tutorial:countries layer second.

                        This polygon layer will be drawn second.

                      9. Locate the tutorial:countries layer in the list and click the Style entry to change polygon to line.

                        By drawing only the outline of the countries the shaded relief can show through.

                        Layer group layers in drawing order

                      10. Locate the Coordiante Reference Systems and press Generate Bounds.

                        Now that layers are listed we they can be used to determine the corodinate reference system and bounds of the layer group.

                        Coordinate Reference Systems

                      11. Press Save complete your layer group.

                      "},{"location":"gettingstarted/group-quickstart/#previewing-the-layer","title":"Previewing the layer","text":"

                      In order to verify that the tutorial:basemap layer is published correctly, we can preview the layer.

                      1. Navigate to the Data > Layer Preview page and find the tutorial:basemap layer.

                        Note

                        Use the Search field with tutorial as shown to limit the number of layers to page through.

                      2. Click the OpenLayers link in the Common Formats column.

                      3. An OpenLayers map will load in a new tab. This preview is used to zoom and pan around the dataset, as well as display the attributes of features.

                        Preview basemap

                      "},{"location":"gettingstarted/image-quickstart/","title":"Publishing a Image","text":"

                      This tutorial walks through the steps of publishing a World + Image with GeoServer.

                      Note

                      This tutorial assumes that GeoServer is running at http://localhost:8080/geoserver.

                      "},{"location":"gettingstarted/image-quickstart/#data-preparation","title":"Data preparation","text":"

                      First let's gather that the data that we'll be publishing.

                      1. Download the Natural Earth 1:50m Shaded Relief raster:

                        • https://www.naturalearthdata.com/downloads/50m-raster-data/50m-shaded-relief/
                      2. This file contains small scale 1:50m data:

                        • SR_50M.prj
                        • SR_50M.README.html
                        • SR_50M.tfw
                        • SR_50M.tif
                        • SR_50M.VERSION.txt

                        This forms a world (the tfw file) plus image (the tif file).

                      3. Move these files into your GeoServer Data Directory data/ne folder.

                      "},{"location":"gettingstarted/image-quickstart/#creating-a-new-workspace","title":"Creating a new workspace","text":"

                      The next step is to create a workspace for the geopackage. A workspace is a folder used to group similar layers together.

                      Note

                      This step is optional if you'd like to use an existing workspace. Usually, a workspace is created for each project, which can include stores and layers that are related to each other.

                      1. In a web browser, navigate to http://localhost:8080/geoserver.

                      2. Log into GeoServer as described in the Logging In section.

                      3. Navigate to Data \u2192 Workspaces.

                      4. Click the Add new workspace button to display the New Workspace page.

                      5. You will be prompted to enter a workspace Name and Namespace URI.

                        Name: tutorial

                        Namespace URI http://localhost:8080/geoserver/tutorial

                        Note

                        A workspace name is an identifier describing your project. It must not exceed ten characters or contain spaces.

                        Note

                        A Namespace URI (Uniform Resource Identifier) can usually be a URL associated with your project with an added trailing identifier indicating the workspace. The Namespace URI filed does not need to resolve to an actual valid web address.

                      6. Press the Submit button.

                      7. The tutorial workspace will be added to the Workspaces list.

                      "},{"location":"gettingstarted/image-quickstart/#create-a-store","title":"Create a store","text":"

                      Once the workspace is created, we are ready to add a new store. The store tells GeoServer how to connect to the geopackage.

                      1. Navigate to Data\u2192Stores.

                      2. This page displays a list of stores, including the type of store and the workspace that the store belongs to.

                      3. In order to add the geopackage, you need to create a new store. Click the Add new Store button. You will be redirected to a list of the data sources supported by GeoServer. Note that the data sources are extensible, so your list may look slightly different.

                      4. From the list of Raster Data Sources locate and click the WorldImage link.

                        Raster Data Sources

                      5. The New Vector Data Source page will display.

                      6. Begin by configuring the Basic Store Info.

                        workspace tutorial

                        Data Source Name ShadedRelief

                        Description Grayscale shaded relief of land areas.

                        This information is internal to GeoServer and is not used as part of the web service protocols. We recommend keeping the Data Source Name simple as they will be used to form folders in the data directory (so keep any operating system restrictions on character use in mind).

                        Basic Store info

                      7. Connection parameters are used to establish the location of your data.

                      8. Under Connection Parameters, browse to the location URL of the image, in our example file:data/ne/SR_50M.tif.

                      9. The Connection Parameters for our geopackage are:

                        database file:data/ne/SR_50M.tif

                        The use of read_only above indicates that we will not be writing to this GeoPackage, allowing GeoServer to avoid managing write locks when accessing this content for greater performance.

                        Connection Parameters

                      10. Press Save.

                      11. You will be redirected to the New Layer page (as this is the most common next step when adding a new data store).

                      "},{"location":"gettingstarted/image-quickstart/#creating-a-layer","title":"Creating a layer","text":"

                      Now that we have located the image, we can publish this information as a layer.

                      1. On the New Layer page, click Publish beside the SR_50M layer name.

                      2. The Edit Layer page defines the data and publishing parameters for a layer.

                      3. There are three critical pieces of information required on the Data tab before we can even save.

                        • Basic Resource Info - describes how the layer is presented to others
                        • Coordinate Reference System - establishes how the spatial data is to be interpreted or drawn on the world
                        • Bounding Boxes - establishes where the dataset is located in the world
                      4. Locate Basic Resource Info and define the layer:

                        Name shaded

                        Title Shaded Relief

                        Abstract Grayscale shaded relief of land areas.

                        The naming of a layer is important, and while GeoServer does not offer restrictions many of the individual protocols will only work with very simple names.

                        Basic Resource Info

                      5. Check the Coordiante Reference Systems information is as listed below.

                        Note

                        In this case select Force declared to prefer the GeoServer internal EPSG database definition of WGS84 over the prj file provided alongside the same image.

                        Native SRS EPSG:4326

                        Declaired SRS EPSG:4326

                        SRS Handling Force declared

                        Coordinate Reference Systems

                      6. Locate Bounding Boces and generate the layer's bounding boxes by clicking the Compute from SRS bounds and then Compute from native bounds links.

                        Note

                        In this case we are choosing a slightly larger bounding box that fully contains the image.

                        Generating bounding boxes

                      7. Press Apply to save your work thus far without closing the page.

                        This is a good way to check that your information has been entered correctly, GeoServer will provide a warning if any required information is incomplete.

                      8. Scroll to the top of the page and navigate to the Publishing tab.

                      9. Locate the WMS Settings heading, where we can set the style.Ensure that the Default Style is set to raster.

                        WMS Settings

                      10. Press Save to complete your layer edits.

                      "},{"location":"gettingstarted/image-quickstart/#previewing-the-layer","title":"Previewing the layer","text":"

                      In order to verify that the tutorial:shaded layer is published correctly, we can preview the layer.

                      1. Navigate to the Data > Layer Preview page and find the tutorial:shaded layer.

                        Note

                        Use the Search field with tutorial as shown to limit the number of layers to page through.

                      2. Click the OpenLayers link in the Common Formats column.

                      3. An OpenLayers map will load in a new tab and display the imagery with the default raster style.

                        You can use this preview map to zoom and pan around the dataset, as well as display the attributes of features.

                        Preview map of shaded relief

                      "},{"location":"gettingstarted/postgis-quickstart/","title":"Publishing a PostGIS table","text":"

                      This tutorial walks through the steps of publishing a PostGIS table with GeoServer.

                      Note

                      This tutorial assumes that PostgreSQL/PostGIS has been previously installed on the system and responding on localhost on port 5432, and also that GeoServer is running at http://localhost:8080/geoserver.

                      "},{"location":"gettingstarted/postgis-quickstart/#data-preparation","title":"Data preparation","text":"

                      First let's gather that the data that we'll be publishing.

                      1. Download the file nyc_buildings.zip. It contains a PostGIS dump of a dataset of buildings from New York City.

                      2. Create a PostGIS database called nyc. This can be done with the following commands:

                        createdb nyc\npsql -d nyc -c 'CREATE EXTENSION postgis'\n

                        Note

                        You may need to supply a username and password with these commands.

                      3. Extract nyc_buildings.sql from nyc_buildings.zip.

                      4. Import nyc_buildings.sql into the nyc database:

                        psql -f nyc_buildings.sql nyc\n
                      "},{"location":"gettingstarted/postgis-quickstart/#creating-a-new-workspace","title":"Creating a new workspace","text":"

                      The next step is to create a workspace for the data. A workspace is a container used to group similar layers together.

                      Note

                      This step is optional if you'd like to use an existing workspace. Usually, a workspace is created for each project, which can include stores and layers that are related to each other.

                      1. In a web browser, navigate to http://localhost:8080/geoserver.

                      2. Log into GeoServer as described in the Logging In section.

                      3. Navigate to Data \u2192 Workspaces.

                        Workspaces page

                      4. Click the Add new workspace button.

                      5. You will be prompted to enter a workspace Name and Namespace URI.

                        Configure a new workspace

                      6. Enter the Name as nyc and the Namespace URI as http://geoserver.org/nyc.

                        Note

                        A workspace name is an identifier describing your project. It must not exceed ten characters or contain spaces. A Namespace URI (Uniform Resource Identifier) can usually be a URL associated with your project with an added trailing identifier indicating the workspace. The Namespace URI filed does not need to resolve to an actual valid web address.

                      7. Click the Submit button. The nyc workspace will be added to the Workspaces list.

                      "},{"location":"gettingstarted/postgis-quickstart/#creating-a-store","title":"Creating a store","text":"

                      Once the workspace is created, we are ready to add a new store. The store tells GeoServer how to connect to the database.

                      1. Navigate to Data\u2192Stores.

                      2. You should see a list of stores, including the type of store and the workspace that the store belongs to.

                        Adding a new data source

                      3. Create a new store by clicking the PostGIS link.

                      4. Enter the Basic Store Info:

                        • Select the nyc Workspace
                        • Enter the Data Source Name as nyc_buildings
                        • Add a brief Description

                        Basic Store Info

                      5. Specify the PostGIS database Connection Parameters:

                        Option Value dbtype postgis host localhost port 5432 database nyc schema public user postgres passwd (Password for the postgres user) validate connections (Checked)

                        Note

                        Leave all other fields at their default values.

                        Connection Parameters

                      6. Click Save.

                      "},{"location":"gettingstarted/postgis-quickstart/#creating-a-layer","title":"Creating a layer","text":"

                      Now that the store is loaded, we can publish the layer.

                      1. Navigate to Data \u2192 Layers.

                      2. Click Add a new resource.

                      3. From the New Layer chooser menu, select nyc:nyc_buidings.

                        Store selection

                      4. On the resulting layer row, select the layer name nyc_buildings.

                        New layer selection

                      5. The Edit Layer page defines the data and publishing parameters for a layer. Enter a short Title and an Abstract for the nyc_buildings layer.

                        Basic Resource Info

                      6. Generate the layer's bounding boxes by clicking the Compute from data and then Compute from native bounds links.

                        Generating bounding boxes

                      7. Click the Publishing tab at the top of the page.

                      8. We can set the layer's style here. Under WMS Settings, ensure that the Default Style is set to polygon.

                        Select Default Style

                      9. Finalize the layer configuration by scrolling to the bottom of the page and clicking Save.

                      "},{"location":"gettingstarted/postgis-quickstart/#previewing-the-layer","title":"Previewing the layer","text":"

                      In order to verify that the nyc_buildings layer is published correctly, we can preview the layer.

                      1. Navigate to the Layer Preview screen and find the nyc:nyc_buildings layer.

                      2. Click the OpenLayers link in the Common Formats column.

                      3. An OpenLayers map will load in a new tab and display the shapefile data with the default line style. You can use this preview map to zoom and pan around the dataset, as well as display the attributes of features.

                        Preview map of nyc_buildings

                      "},{"location":"gettingstarted/shapefile-quickstart/","title":"Publishing a shapefile","text":"

                      This tutorial walks through the steps of publishing a Shapefile with GeoServer.

                      Note

                      This tutorial assumes that GeoServer is running at http://localhost:8080/geoserver.

                      "},{"location":"gettingstarted/shapefile-quickstart/#data-preparation","title":"Data preparation","text":"

                      First let's gather that the data that we'll be publishing.

                      1. Download the file nyc_roads.zip. This archive contains a shapefile of roads from New York City that will be used during in this tutorial.

                      2. Unzip the nyc_roads.zip into a new directory named nyc_roads. The archive contains the following four files:

                        nyc_roads.shp\nnyc_roads.shx\nnyc_roads.dbf\nnyc_roads.prj\n
                      3. Move the nyc_roads directory into <GEOSERVER_DATA_DIR>/data, where <GEOSERVER_DATA_DIR> is the root of the GeoServer data directory. If no changes have been made to the GeoServer file structure, the path is geoserver/data_dir/data/nyc_roads.

                      "},{"location":"gettingstarted/shapefile-quickstart/#creating-a-new-workspace","title":"Creating a new workspace","text":"

                      The next step is to create a workspace for the shapefile. A workspace is a container used to group similar layers together.

                      Note

                      This step is optional if you'd like to use an existing workspace. Usually, a workspace is created for each project, which can include stores and layers that are related to each other.

                      1. In a web browser, navigate to http://localhost:8080/geoserver.

                      2. Log into GeoServer as described in the Logging In section.

                      3. Navigate to Data \u2192 Workspaces.

                        Workspaces page

                      4. Click the Add new workspace button.

                      5. You will be prompted to enter a workspace Name and Namespace URI.

                        Configure a new workspace

                      6. Enter the Name as nyc and the Namespace URI as http://geoserver.org/nyc.

                        Note

                        A workspace name is an identifier describing your project. It must not exceed ten characters or contain spaces. A Namespace URI (Uniform Resource Identifier) can usually be a URL associated with your project with an added trailing identifier indicating the workspace. The Namespace URI filed does not need to resolve to an actual valid web address.

                        nyc workspace

                      7. Click the Submit button. The nyc workspace will be added to the Workspaces list.

                      "},{"location":"gettingstarted/shapefile-quickstart/#create-a-store","title":"Create a store","text":"

                      Once the workspace is created, we are ready to add a new store. The store tells GeoServer how to connect to the shapefile.

                      1. Navigate to Data\u2192Stores.

                      2. You should see a list of stores, including the type of store and the workspace that the store belongs to.

                      3. In order to add the shapefile, you need to create a new store. Click the Add new Store button. You will be redirected to a list of the data sources supported by GeoServer. Note that the data sources are extensible, so your list may look slightly different.

                        Stores

                      4. Click Shapefile. The New Vector Data Source page will display.

                      5. Begin by configuring the Basic Store Info.

                        • Select the workspace nyc from the drop down menu.
                        • Enter the Data Source Name as NYC Roads
                        • Enter a brief Description (such as \"Roads in New York City\").
                      6. Under Connection Parameters, browse to the location URL of the shapefile, typically nyc_roads/nyc_roads.shp.

                        Basic Store Info and Connection Parameters

                      7. Click Save. You will be redirected to the New Layer page in order to configure the nyc_roads layer.

                      "},{"location":"gettingstarted/shapefile-quickstart/#creating-a-layer","title":"Creating a layer","text":"

                      Now that the store is loaded, we can publish the layer.

                      1. On the New Layer page, click Publish beside the nyc_roads layer name.

                        New layer

                      2. The Edit Layer page defines the data and publishing parameters for a layer. Enter a short Title and an Abstract for the nyc_roads layer.

                        Basic Resource Information

                      3. Generate the layer's bounding boxes by clicking the Compute from data and then Compute from native bounds links.

                        Generating bounding boxes

                      4. Click the Publishing tab at the top of the page.

                      5. We can set the layer's style here. Under WMS Settings, ensure that the Default Style is set to line.

                        Select Default Style

                      6. Finalize the layer configuration by scrolling to the bottom of the page and clicking Save.

                      "},{"location":"gettingstarted/shapefile-quickstart/#previewing-the-layer","title":"Previewing the layer","text":"

                      In order to verify that the nyc_roads layer is published correctly, we can preview the layer.

                      1. Navigate to the Layer Preview screen and find the nyc:nyc_roads layer.

                        Layer Preview

                      2. Click the OpenLayers link in the Common Formats column.

                      3. An OpenLayers map will load in a new tab and display the shapefile data with the default line style. You can use this preview map to zoom and pan around the dataset, as well as display the attributes of features.

                        Preview map of nyc_roads

                      "},{"location":"gettingstarted/style-quickstart/","title":"Publishing a style","text":"

                      This tutorial walks through the steps of defining a style and associating it with a layer for use.

                      Note

                      This tutorial assumes that GeoServer is running at http://localhost:8080/geoserver.

                      "},{"location":"gettingstarted/style-quickstart/#data-preparation","title":"Data preparation","text":"

                      First let's gather that the data that we'll be publishing.

                      1. Complete the previous tutorials:
                        • Publishing a GeoPackage defining the tutorial:countries layer
                        • Publishing a Image defining the tutorial:shaded layer
                        • Publishing a Layer Group defining the tutorial:basemap layer
                      "},{"location":"gettingstarted/style-quickstart/#create-a-style","title":"Create a style","text":"
                      1. Navigate to Data > Style page.

                        Styles

                      2. This page displays a list of styles, including the workspace the style belongs to.

                        Note

                        Styles groups are allowed to be \"global\" allowing a style to be defined that can be used by any layer.

                      3. At the top of the list Styles list, locate and click the Add a new style link.

                      4. Locate Style Data and define the style:

                        Name background

                        Workspace tutorial

                        Format SLD

                        Style data

                      5. Locate Style Content and carefully:

                        • Under Generate a default style select Polygon

                        Style Content configured to generate a polygon default style.

                      6. Under Generate a default style locate and click the Generate link to populate the style editor with a generated outline of a polygion style.

                      7. Press the Apply button to define this style.

                        Now that the style is defined there are more options for interactively working with the style.

                      8. Change to Publishing tab.

                        • Use the search to filter with tutorial to locate tutorial:countries.
                        • Select the Default checkbox for tutorial:countries to use the tutorial:background style the default for this layer.

                        Style publish

                      9. Next to Publishing navigate to the Layer Preview tab.

                        • Locate the Preview on layer and click on the link to select tutorial:countries as a dataset to use when editing the style.

                        Styled editor Layer Preview tab

                      10. Edit your style by inserting fill-opacity value of 0.25.

                        <?xml version=\"1.0\" encoding=\"ISO-8859-1\"?>\n<StyledLayerDescriptor version=\"1.0.0\"\n  xsi:schemaLocation=\"http://www.opengis.net/sld http://schemas.opengis.net/sld/1.0.0/StyledLayerDescriptor.xsd\"\n  xmlns=\"http://www.opengis.net/sld\" xmlns:ogc=\"http://www.opengis.net/ogc\"\n  xmlns:xlink=\"http://www.w3.org/1999/xlink\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\">\n\n  <NamedLayer>\n    <Name>background</Name>\n    <UserStyle>\n      <Title>Background</Title>\n      <FeatureTypeStyle>\n        <Rule>\n          <Title>Background</Title>\n          <PolygonSymbolizer>\n            <Fill>\n              <CssParameter name=\"fill\">#444433</CssParameter>\n              <CssParameter name=\"fill-opacity\">0.25</CssParameter>\n            </Fill>\n            <Stroke>\n              <CssParameter name=\"stroke\">#000000</CssParameter>\n              <CssParameter name=\"stroke-width\">0.25</CssParameter>\n            </Stroke>\n          </PolygonSymbolizer>\n        </Rule>\n      </FeatureTypeStyle>\n    </UserStyle>\n  </NamedLayer>\n</StyledLayerDescriptor>\n
                      11. Press Apply to edit your style and check the resulting visual change in the layer preview.

                      12. Experiment with:

                        • Updating the title information, watching the displayed legend change
                        • Full screen mode for side-by-side editing

                        Full screen mode

                      13. When this style is used as part of the tutorial::basemap the fill-opacity allows the shaded relief detail to be shown.

                        Basemap with background style applied to countries

                      "},{"location":"gettingstarted/web-admin-quickstart/","title":"Using the web administration interface","text":"

                      GeoServer has a browser-based web administration interface application used to configure all aspects of GeoServer, from adding and publishing data to changing service settings.

                      1. The web admin interface is accessed via a web browser at:

                        http://<host>:<port>/geoserver\n
                      2. For a default installation on a server the link is:

                        http://localhost:8080/geoserver\n
                      3. When the application starts, it displays the Welcome page.

                        Welcome Page

                      4. The welcome page provides links describing the web services used to access information.

                        To use copy and paste these links into a Desktop GIS, mobile or web mapping application.

                      Note

                      For more information, please see the Welcome section.

                      "},{"location":"gettingstarted/web-admin-quickstart/#logging_in","title":"Logging In","text":"

                      In order to change any server settings or configure data, a user must first be authenticated.

                      1. Navigate to the upper right of the web interface to log into GeoServer. The default administration credentials are:

                        • User name: admin
                        • Password: geoserver

                        Note

                        These can be changed in the Security section.

                        Login

                      2. Once logged in, the Welcome screen changes to show the available admin functions. These are primarily shown in the menus on the left side of the page.

                        Additional options when logged in

                      "},{"location":"gettingstarted/web-admin-quickstart/#layer-preview","title":"Layer Preview","text":"

                      The Layer Preview page allows you to quickly view the output of published layers.

                      1. Click the Layer Preview link on the menu to go to this page.

                      2. From here, you can find the layer you'd like to preview and click a link for an output format. Click the OpenLayers link for a given layer and the view will display.

                      3. To sort a column alphabetically, click the column header.

                        Unsorted (left) and sorted (right) columns

                      4. Searching can be used to filter the number of items displayed. This is useful for working with data types that contain a large number of items. To search data type items, enter the search string in the search box and click Enter. GeoServer will search the data type for items that match your query, and display a list view showing the search results.

                        Search results for the query \"top\" on the Workspace page

                        Note

                        Sorting and searching apply to all data configuration pages.

                      Note

                      For more information, please see the Layer Preview section.

                      "},{"location":"installation/","title":"Installation","text":"

                      There are many ways to install GeoServer on your system. This section will discuss the various installation paths available.

                      Note

                      To run GeoServer as part of an existing servlet container such as Tomcat, please see the Web archive section.

                      Warning

                      GeoServer requires a Java 11 or Java 17 environment (JRE) to be installed on your system, available from OpenJDK, Adoptium for Windows and macOS installers, or provided by your OS distribution.

                      This must be done prior to installation.

                      • Linux binary
                      • Windows binary
                      • Windows installer
                      • Web archive
                      • Docker Container
                      • Upgrading existing versions
                      "},{"location":"installation/docker/","title":"Docker Container","text":"

                      Geoserver is also packaged as a Docker Container. For more details, see the Geoserver Docker Container Project.

                      See the README.md file for more technical information.

                      "},{"location":"installation/docker/#quick-start","title":"Quick Start","text":"

                      This will run the container, with the data directory included with the container:

                      1. Make sure you have Docker installed.

                      2. Download the container:

                        Nightly Build

                        These instructions are for GeoServer 2.24-SNAPSHOT which is provided as a Nightly release. Testing a Nightly release is a great way to try out new features, and test community modules. Nightly releases change on an ongoing basis and are not suitable for a production environment.

                        docker pull docker.osgeo.org/geoserver: 2.24.x\n

                        Release

                        These instructions are for GeoServer 2.24.2.

                        docker pull docker.osgeo.org/geoserver: 2.24.2\n
                      3. Run the container

                        Release

                        docker run -it -p8080:8080 docker.osgeo.org/geoserver: 2.24.2\n

                        Nightly Build

                        docker run -it -p8080:8080 docker.osgeo.org/geoserver: 2.24.x\n
                      4. In a web browser, navigate to http://localhost:8080/geoserver.

                        If you see the GeoServer Welcome page, then GeoServer is successfully installed.

                        GeoServer Welcome Page

                      5. This setup is a quick test to ensure the software is working, but is difficult to use as file data can only be transferred to the data directory included with the container via the REST API.

                      "},{"location":"installation/docker/#using-your-own-data-directory","title":"Using your own Data Directory","text":"

                      This will run the container with a local data directory. The data directory will be mounted into the docker container.

                      Note

                      Change /MY/DATADIRECTORY to your data directory. If this directory is empty it will be populated with the standard Geoserver Sample Data Directory.

                      1. Make sure you have Docker installed.

                      2. Download the container

                        Release

                        docker pull docker.osgeo.org/geoserver: 2.24.2\n

                        Nightly Build

                        docker pull docker.osgeo.org/geoserver: 2.24.x\n
                      3. Run the container

                        Release

                        docker run \\-\\-mount type=bind,src=/MY/DATADIRECTORY,target=/opt/geoserver_data -it -p8080:8080 docker.osgeo.org/geoserver: 2.24.2\n

                        Nightly Build

                        docker run \\-\\-mount type=bind,src=/MY/DATADIRECTORY,target=/opt/geoserver_data -it -p8080:8080 docker.osgeo.org/geoserver: 2.24.x\n
                      4. In a web browser, navigate to http://localhost:8080/geoserver.

                        If you see the GeoServer Welcome page, then GeoServer is successfully installed.

                        GeoServer Welcome Page

                      5. This setup allows direct management of the file data shared with the container. This setup is also easy to update to use the latest container.

                      "},{"location":"installation/docker/#adding-geoserver-extensions","title":"Adding GeoServer Extensions","text":"

                      You can add GeoServer Extensions - the container will download them during startup.

                      Release

                      docker run -it -p8080:8080 \\\\\n  \\-\\-env INSTALL_EXTENSIONS=true \\\\\n  \\-\\-env STABLE_EXTENSIONS=\"ysld,h2\" \\\\\n  docker.osgeo.org/geoserver: 2.24.2\n

                      Nightly Build

                      docker run -it -p8080:8080 \\\\\n  \\-\\-env INSTALL_EXTENSIONS=true \\\\\n  \\-\\-env STABLE_EXTENSIONS=\"ysld,h2\" \\\\\n  docker.osgeo.org/geoserver: 2.24.x\n

                      This will download and install the YSLD and H2 extension.

                      Here is a list of available extensions (taken from the build server):

                      app-schema   gdal            jp2k          ogr-wps          web-resource\nauthkey      geofence        libjpeg-turbo oracle           wmts-multi-dimensional\ncas          geofence-server mapml         params-extractor wps-cluster-hazelcast\ncharts       geopkg-output   mbstyle       printing         wps-download\ncontrol-flow grib            mongodb       pyramid          wps-jdbc\ncss          gwc-s3          monitor       querylayer       wps\ncsw          h2              mysql         sldservice       xslt\ndb2          imagemap        netcdf-out    sqlserver        ysld\ndxf          importer        netcdf        vectortiles      \nexcel        inspire         ogr-wfs       wcs2_0-eo\n
                      "},{"location":"installation/docker/#testing-geoserver-community-modules","title":"Testing Geoserver Community modules","text":"

                      Working with a Nightly build is a good way to test community modules and provide feedback to developers working on new functionality.

                      To work with community modules you must be using the GeoServer 2.24.x nightly build that matches the community module build:

                      docker run -it -p8080:8080 \\\\\n  \\-\\-env INSTALL_EXTENSIONS=true \\\\\n  \\-\\-env STABLE_EXTENSIONS=\"ysld,h2\" \\\\\n  \\-\\-env COMMUNITY_EXTENSIONS=\"ogcapi-features,ogcapi-images,ogcapi-maps,ogcapi-styles,ogcapi-tiles\" \\\\\n  docker.osgeo.org/geoserver: 2.24.x\n

                      For the current list see GeoServer build server.

                      activeMQ-broker            jdbcconfig                 pgraster                    \nbackup-restore             jdbcstore                  proxy-base-ext              \ncog                        jms-cluster                s3-geotiff                  \ncolormap                   libdeflate                 sec-keycloak             \ncov-json                   mbtiles                    sec-oauth2-geonode          \ndds                        mbtiles-store              sec-oauth2-github           \ndyndimension               mongodb-schemaless         sec-oauth2-google           \nelasticsearch              ncwms                      sec-oauth2-openid-connect   \nfeatures-templating        netcdf-ghrsst              smart-data-loader           \nflatgeobuf                 notification               solr                        \ngdal-wcs                   ogcapi-coverages           spatialjson                 \ngdal-wps                   ogcapi-dggs                stac-datastore              \ngeopkg                     ogcapi-features            taskmanager-core            \ngpx                        ogcapi-images              taskmanager-s3              \ngsr                        ogcapi-maps                vector-mosaic\ngwc-azure-blobstore        ogcapi-styles              vsi                         \ngwc-distributed            ogcapi-tiled-features      webp                        \ngwc-mbtiles                ogcapi-tiles               wps-remote\ngwc-sqlite                 ogr-datastore              rat\nhz-cluster                 opensearch-eo                          \nimporter-jdbc              \njdbc-metrics\n
                      "},{"location":"installation/linux/","title":"Linux binary","text":"

                      Note

                      For installing on Linux with an existing application server such as Tomcat, please see the Web archive section.

                      The platform-independent binary is a GeoServer web application bundled inside Jetty, a lightweight and portable application server. It has the advantages of working very similarly across all operating systems and is very simple to set up.

                      "},{"location":"installation/linux/#installation","title":"Installation","text":"
                      1. Make sure you have a Java Runtime Environment (JRE) installed on your system. GeoServer requires a Java 11 or Java 17 environment, available from OpenJDK, Adoptium, or provided by your OS distribution.

                        Note

                        For more information about Java and GeoServer compatibility, please see the section on Java Considerations.

                      2. Navigate to the GeoServer Download page.

                      3. Select the version of GeoServer that you wish to download. If you're not sure, select Stable release.

                        Nightly Build

                        These instructions are for GeoServer 2.24-SNAPSHOT which is provided as a Nightly release. Testing a Nightly release is a great way to try out new features, and test community modules. Nightly releases change on an ongoing basis and are not suitable for a production environment.

                        Release

                        These instructions are for GeoServer 2.24.2.

                      4. Select Platform Independent Binary on the download page: geoserver-2.24.2-bin.zip

                      5. Download the zip archive and unpack to the directory where you would like the program to be located.

                        Note

                        A suggested location would be /usr/share/geoserver.

                      6. Add an environment variable to save the location of GeoServer by typing the following command:

                        echo \"export GEOSERVER_HOME=/usr/share/geoserver\" >> ~/.profile\n. ~/.profile\n
                      7. Make yourself the owner of the geoserver folder. Type the following command in the terminal window, replacing USER_NAME with your own username :

                        sudo chown -R USER_NAME /usr/share/geoserver/\n
                      8. Start GeoServer by changing into the directory geoserver/bin and executing the startup.sh script:

                        cd geoserver/bin\nsh startup.sh\n
                      9. In a web browser, navigate to http://localhost:8080/geoserver.

                        If you see the GeoServer Welcome page, then GeoServer is successfully installed.

                        GeoServer Welcome Page

                      10. To shut down GeoServer, either close the persistent command-line window, or run the shutdown.sh file inside the bin directory.

                      "},{"location":"installation/linux/#uninstallation","title":"Uninstallation","text":"
                      1. Stop GeoServer (if it is running).
                      2. Delete the directory where GeoServer is installed.
                      "},{"location":"installation/upgrade/","title":"Upgrading existing versions","text":"

                      Warning

                      Be aware that some upgrades are not reversible, meaning that the data directory may be changed so that it is no longer compatible with older versions of GeoServer. See Migrating a data directory between versions for more details.

                      The general GeoServer upgrade process is as follows:

                      1. Back up the current data directory. This can involve simply copying the directory to an additional place.

                      2. Make sure that the current data directory is external to the application (not located inside the application file structure).

                        Check the GeoServer Server status page to double check the data directory location.

                      3. Make a note of any extensions you have installed.

                        • The GeoServer About \u2192 Server Status page provides a Modules tab listing the modules installed.
                        • Some extensions include more than one module, as an example the WPS extension is listed as gs-wps-core and gs-web-wps.
                      4. Uninstall the old version and install the new version.

                        • Download maintenance release to update existing installation
                        • Download stable release when ready to upgrade
                      5. Be sure to download and install each extension used by your prior installation.

                      6. Make sure that the new installation continues to point to the same data directory used by the previous version.

                      "},{"location":"installation/upgrade/#notes-on-upgrading-specific-versions","title":"Notes on upgrading specific versions","text":""},{"location":"installation/upgrade/#freemarker-template-html-auto-escaping-geoserver-225-and-newer","title":"FreeMarker Template HTML Auto-escaping (GeoServer 2.25 and newer)","text":"

                      As of GeoServer 2.25, the FreeMarker library's HTML auto-escaping feature will be enabled by default to prevent cross-site scripting (XSS) vulnerabilities in WMS GetFeatureInfo HTML output when using the default FreeMarker templates and WMS service settings. Some users may experience incorrectly escaped HTML output when using custom templates or if HTML tags are stored in vector data stores.

                      See the FreeMarker Template Auto-escaping page for information about the limitations of this feature and for instructions to disable this feature and delegate to the WMS service setting which defaults to disabling HTML auto-escaping.

                      "},{"location":"installation/upgrade/#spring-security-strict-http-firewall-geoserver-225-and-newer","title":"Spring Security Strict HTTP Firewall (GeoServer 2.25 and newer)","text":"

                      As of GeoServer 2.25, Spring Security's StrictHttpFirewall will be enabled by default which will provide stronger default protection, particularly against potential path traversal vulnerabilities.

                      In some cases valid requests may be blocked if the names of GeoServer resources (e.g., workspaces) contain certain special characters and are included in URL paths. See the Spring Security Firewall page for instructions to disable the strict firewall and revert to the DefaultHttpFirewall used by earlier versions.

                      "},{"location":"installation/upgrade/#wcs-arcgrid-output-format-removal-geoserver-224-and-newer","title":"WCS ArcGRID output format removal (GeoServer 2.24 and newer)","text":"

                      The ArcGRID output format for WCS has been removed in GeoServer 2.24.0. If you have been using this format, you will need to switch to another text based format, such as GML coverage, or can get back the ArcGRID format by installing the WCS GDAL community module and use a configuration like the following (please adapt to your system):

                      <ToolConfiguration>\n  <executable>gdal_translate</executable>\n  <environment>\n    <variable name=\"GDAL_DATA\" value=\"/usr/local/share/gdal\" />\n  </environment>\n  <formats>\n    <Format>\n      <toolFormat>AAIGrid</toolFormat>\n      <geoserverFormat>ArcGrid</geoserverFormat>\n      <fileExtension>.asc</fileExtension>\n      <singleFile>true</singleFile>\n      <mimeType>application/arcgrid</mimeType>\n    </Format>\n  </formats>\n</ToolConfiguration>\n
                      "},{"location":"installation/upgrade/#disk-quota-hsql-db-usage-geoserver-224-and-newer","title":"Disk Quota HSQL DB usage (GeoServer 2.24 and newer)","text":"

                      As of GeoServer 2.24, H2 DB support will be replaced with HSQL DB for Tile Caching / Disk Quota store.

                      • H2 option under \"Disk quota store type\" and \"Target database type\" is replaced with HSQL.
                      • The default store type will be in-process HSQL.
                      • Existing installations with in-process H2 selection will automatically be migrated to in-process HSQL. Old H2 database files will remain in gwc/diskquota_page_store_h2/ under the data directory. You may delete those or leave them for a possible downgrade.
                      • Important: Existing installations with external H2 database selection will not be migrated automatically. You will get an error message at startup and disk quota will be disabled, unless you use a plugin/extension with H2 dependency. But other features of GeoServer will keep working. You can go to Disk Quota page and configure an external HSQL database or switch to in-process HSQL. In case you want to keep using H2 as an in-process/external database, you can add H2 store plugin or any other extension or plugin that has H2 dependency.
                      • GeoServer installations with extensions/plugins having H2 dependency will still have H2 option under \"Disk quota store type\" and \"Target database type\".
                      "},{"location":"installation/upgrade/#remote-requests-control-geoserver-224-and-newer","title":"Remote requests control (GeoServer 2.24 and newer)","text":"

                      As of GeoServer 2.24, remote requests control has been added, and enabled by default, in GeoServer. This feature allows administrators to control which remote requests are allowed to be made to GeoServer. By default, no authorizations are included, thus GeoServer will deny remote requests originating from user interaction. In particular, the following use cases are affected:

                      • WMS operations with remotely fetch styles (sld parameter) and style referencing remote icons (in general, icons outside of the data directory). As a reminder, when a remote icon is not found, GeoServer will fall back to a default icon, a gray square with a black border.
                      • WMS \"feature portrayal\" with dynamic remote WFS references provided in the request (REMOTE_OWS_TYPE and REMOTE_OWS_URL parameters).
                      • WPS remote inputs via either GET or POST request (e.g., remote GeoJSON file source).

                      The list of locations that are safe to contact can be configured using the URL Checks page.

                      "},{"location":"installation/upgrade/#log4j-upgrade-geoserver-221-and-newer","title":"Log4J Upgrade (GeoServer 2.21 and newer)","text":"

                      As of GeoServer 2.21, the logging system used by GeoServer has been upgraded from Log4J 1.2 to Log4J 2.

                      • GeoServer now uses xml files for the built-in logging profiles (previously properties files were used).

                      • The built-in logging profiles are upgraded with xml files:

                        DEFAULT_LOGGING.xml\nDEFAULT_LOGGING.properties.bak\n
                      • A backup of the prior properties files are created during the upgrade process. If you had previously made any customizations to a built-in profiles these backup files may be used as a reference when customizing the xml file.

                      • Log4J 2 does have the ability to read Log4j 1.2 properties files although not all features are supported.

                        Any custom properties files you created will continue to be available for use.

                      • If necessary you can recover a customization you performed to a built-in logging profile by restoring to a different filename. To recover a customization from PRODUCTION_LOGGING.properties.bak rename the file to PRODUCTION_LOGGING.properties.bak to CUSTOM_LOGGING.properties.

                      • If you never plan to customize the built-in logging profiles the UPDATE_BUILT_IN_LOGGING_PROFILES=true system property will always ensure you have our latest recommendation.

                      "},{"location":"installation/upgrade/#jts-type-bindings-geoserver-214-and-newer","title":"JTS Type Bindings (GeoServer 2.14 and newer)","text":"

                      As of GeoServer 2.14, the output produced by REST featuretype and structured coverage requests using a different package name (org.locationtech instead of com.vividsolutions) for geometry type bindings, due to the upgrade to JTS (Java Topology Suite) 1.16.0. For example:

                      Before:

                      ...\n<attribute>\n  <name>geom</name>\n  <minOccurs>0</minOccurs>\n  <maxOccurs>1</maxOccurs>\n  <nillable>true</nillable>\n  <binding>com.vividsolutions.jts.geom.Point</binding>\n</attribute>\n...\n

                      After:

                      ...\n<attribute>\n  <name>geom</name>\n  <minOccurs>0</minOccurs>\n  <maxOccurs>1</maxOccurs>\n  <nillable>true</nillable>\n  <binding>org.locationtech.jts.geom.Point</binding>\n</attribute>\n...\n

                      Any REST clients which rely on this binding information should be updated to support the new names.

                      "},{"location":"installation/upgrade/#geojson-encoding-geoserver-26-and-newer","title":"GeoJSON encoding (GeoServer 2.6 and newer)","text":"

                      As of GeoServer 2.6, the GeoJSON produced by the WFS service no longer uses a non-standard encoding for the CRS. To re-enable this behavior for compatibility purposes, set GEOSERVER_GEOJSON_LEGACY_CRS=true as a system property, context parameter, or environment variable.

                      "},{"location":"installation/war/","title":"Web archive","text":"

                      GeoServer is packaged as a standalone servlet for use with existing application servers such as Apache Tomcat and Jetty.

                      Note

                      GeoServer has been mostly tested using Tomcat, and so is the recommended application server. GeoServer requires a newer version of Tomcat (7.0.65 or later) that implements Servlet 3 and annotation processing. Other application servers have been known to work, but are not guaranteed.

                      "},{"location":"installation/war/#installation","title":"Installation","text":"
                      1. Make sure you have a Java Runtime Environment (JRE) installed on your system. GeoServer requires a Java 11 or Java 17 environment,available from OpenJDK, Adoptium, or provided by your OS distribution.

                        Note

                        For more information about Java and GeoServer compatibility, please see the section on Java Considerations.

                      2. Navigate to the GeoServer Download page.

                      3. Select the version of GeoServer that you wish to download. If you're not sure, select Stable release.

                        Nightly Build

                        These instructions are for GeoServer 2.24-SNAPSHOT which is provided as a Nightly release. Testing a Nightly release is a great way to try out new features, and test community modules. Nightly releases change on an ongoing basis and are not suitable for a production environment.

                        Release

                        These instructions are for GeoServer 2.24.2.

                      4. Select Web Archive on the download page: geoserver-2.24.2-war.zip

                      5. Download and unpack the archive.

                      6. Deploy the web archive as you would normally. Often, all that is necessary is to copy the geoserver.war file to the application server's webapps directory, and the application will be deployed.

                        Note

                        A restart of your application server may be necessary.

                      "},{"location":"installation/war/#tomcat-hardening","title":"Tomcat Hardening","text":"

                      Hide the Tomcat version in error responses and its error details.

                      To remove the Tomcat version, create following file with empty parameters :

                      cd $CATALINA_HOME (where Tomcat binaries are installed)\nmkdir -p ./lib/org/apache/catalina/util/\ncat > ./lib/org/apache/catalina/util/ServerInfo.properties <<EOF\nserver.info=\nserver.number=\nserver.built=\nEOF\n

                      Additionally add to server.xml the ErrorReportValve to disable showReport and showServerInfo. This is used to hide errors handled globally by tomcat in host section.

                      vi ./conf/server.xml

                      Add to <Host name=... section this new ErrorReportValve entry: :

                      ...\n     <Host name=\"localhost\"  appBase=\"webapps\"\n           unpackWARs=\"true\" autoDeploy=\"true\">\n\n       ...\n\n       <Valve className=\"org.apache.catalina.valves.ErrorReportValve\" showReport=\"false\" showServerInfo=\"false\" />\n\n     </Host>\n   </Engine>\n </Service>\n</Server>\n

                      Why, if security by obscurity does not work?

                      Even though this is not the final solution, it at least mitigates the visible eye-catcher of outdated software packages.

                      Let's take the attackers point of view.

                      Response with just HTTP status: :

                      HTTP Status 400 \u2013 Bad Request\n

                      Ok, it looks like a Tomcat is installed.

                      Default full response: :

                      HTTP Status 400 \u2013 Bad Request\nType Status Report\nMessage Invalid URI\nDescription The server cannot or will not process the request due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request message framing, or deceptive request routing).\nApache Tomcat/7.0.67\n

                      Ahh, great, the software is not really maintained. Tomcat is far outdated from Dec. 2015 (6 years old as of today Jan. 2022) with a lot of unfixed vulnerabilities.

                      Notice: For support reason, the local output of version.sh still outputs the current version :

                      $CATALINA_HOME/bin/version.sh\n ...\n Server number:  7.0.67\n ...\n
                      "},{"location":"installation/war/#running","title":"Running","text":"

                      Use your container application's method of starting and stopping webapps to run GeoServer.

                      To access the Web administration interface, open a browser and navigate to http://SERVER/geoserver . For example, with Tomcat running on port 8080 on localhost, the URL would be http://localhost:8080/geoserver.

                      If you see the GeoServer Welcome page, then GeoServer is successfully installed.

                      GeoServer Welcome Page

                      "},{"location":"installation/war/#update","title":"Update","text":"

                      Update regularly at least the container application! And repeat the hardening process.

                      There are a lot of geoserver installations visible with outdated Tomcat versions.

                      "},{"location":"installation/war/#uninstallation","title":"Uninstallation","text":"
                      1. Stop the container application.
                      2. Remove the GeoServer webapp from the container application's webapps directory. This will usually include the geoserver.war file as well as a geoserver directory.
                      "},{"location":"installation/win_binary/","title":"Windows binary","text":"

                      Note

                      For installing on Windows with an existing application server such as Tomcat, please see the Web archive section.

                      The other way of installing GeoServer on Windows is to use the platform-independent binary. This version is a GeoServer web application bundled inside Jetty, a lightweight and portable application server. It has the advantages of working very similarly across all operating systems and is very simple to set up.

                      "},{"location":"installation/win_binary/#installation","title":"Installation","text":"
                      1. Make sure you have a Java Runtime Environment (JRE) installed on your system. GeoServer requires a Java 11 or Java 17 environment, as provided by Adoptium Windows installers.

                        Note

                        For more information about Java and GeoServer, please see the section on Java Considerations.

                      2. Navigate to the GeoServer Download page.

                      3. Select the version of GeoServer that you wish to download. If you're not sure, select Stable release.

                        Nightly Build

                        These instructions are for GeoServer 2.24-SNAPSHOT which is provided as a Nightly release. Testing a Nightly release is a great way to try out new features, and test community modules. Nightly releases change on an ongoing basis and are not suitable for a production environment.

                        Release

                        These instructions are for GeoServer 2.24.2.

                      4. Select Platform Independent Binary on the download page: geoserver-2.24.2-bin.zip

                      5. Download the archive and unpack to the directory where you would like the program to be located.

                        Note

                        A suggested location would be C:\\\\Program Files\\GeoServer.

                      "},{"location":"installation/win_binary/#setting-environment-variables","title":"Setting environment variables","text":"

                      You will need to set the JAVA_HOME environment variable if it is not already set. This is the path to your JRE such that %JAVA_HOME%\\bin\\java.exe exists.

                      1. Navigate to Control Panel \u2192 System \u2192 Advanced \u2192 Environment Variables.
                      2. Under System variables click New.
                      3. For Variable name enter JAVA_HOME. For Variable value enter the path to your JDK/JRE.
                      4. Click OK three times.

                      Note

                      You may also want to set the GEOSERVER_HOME variable, which is the directory where GeoServer is installed, and the GEOSERVER_DATA_DIR variable, which is the location of the GeoServer data directory (which by default is %GEOSERVER_HOME\\data_dir). The latter is mandatory if you wish to use a data directory other than the default location. The procedure for setting these variables is identical to setting the JAVA_HOME variable.

                      "},{"location":"installation/win_binary/#running","title":"Running","text":"

                      Note

                      This can be done either via Windows Explorer or the command line.

                      1. Navigate to the bin directory inside the location where GeoServer is installed.

                      2. Run startup.bat. A command-line window will appear and persist. This window contains diagnostic and troubleshooting information. This window must be left open, otherwise GeoServer will shut down.

                      3. Navigate to http://localhost:8080/geoserver (or wherever you installed GeoServer) to access the GeoServer Web administration interface.

                        If you see the GeoServer Welcome page, then GeoServer is successfully installed.

                        GeoServer Welcome Page

                      "},{"location":"installation/win_binary/#stopping","title":"Stopping","text":"

                      To shut down GeoServer, either close the persistent command-line window, or run the shutdown.bat file inside the bin directory.

                      "},{"location":"installation/win_binary/#uninstallation","title":"Uninstallation","text":"
                      1. Stop GeoServer (if it is running).
                      2. Delete the directory where GeoServer is installed.
                      "},{"location":"installation/win_installer/","title":"Windows installer","text":"

                      The Windows installer provides an easy way to set up GeoServer on your system, as it requires no configuration files to be edited or command line settings.

                      1. Make sure you have a Java Runtime Environment (JRE) installed on your system. GeoServer requires a Java 11 or Java 17 environment, as provided by Adoptium Windows installers.

                        Note

                        For more information about Java and GeoServer, please see the section on Java Considerations.

                      2. Navigate to the GeoServer Download page.

                      3. Select the version of GeoServer that you wish to download. If you're not sure, select Stable release.

                        Nightly Build

                        This documentation covers GeoServer 2.24-SNAPSHOT which is under development and is available as a Nightly release.

                        Nightly releases are used to test out try out new features and test community modules and do not provide a windows installer. When GeoServer 2.24.0 is released a windows installer will be provided.

                        Release

                        These instructions are for GeoServer 2.24.2.

                      4. Click the link for the Windows Installer.

                        Downloading the Windows installer

                      5. After downloading, double-click the file to launch.

                      6. At the Welcome screen, click Next.

                        Welcome screen

                      7. Read the License and click I Agree.

                        GeoServer license

                      8. Select the directory of the installation, then click Next.

                        GeoServer install directory

                      9. Select the Start Menu directory name and location, then click Next.

                        Start menu location

                      10. Enter the path to a valid Java Runtime Environment (JRE). GeoServer requires a valid JRE in order to run, so this step is required. The installer will inspect your system and attempt to automatically populate this box with a JRE if it is found, but otherwise you will have to enter this path manually. When finished, click Next.

                        Note

                        A typical path on Windows would be C:\\Program Files\\Java\\jre8.

                        Note

                        Don't include the \\bin in the JRE path. So if java.exe is located at C:\\Program Files (x86)\\Java\\jre8\\bin\\java.exe, set the path to be C:\\Program Files (x86)\\Java\\jre8.

                        Note

                        For more information about Java and GeoServer, please see the section on Java Considerations.

                        Selecting a valid JRE

                      11. Enter the path to your GeoServer data directory or select the default. If this is your first time using GeoServer, select the Default data directory. When finished, click Next.

                        Setting a GeoServer data directory

                      12. Enter the username and password for administration of GeoServer. GeoServer's Web administration interface requires authentication for management, and what is entered here will become those administrator credentials. The defaults are admin / geoserver. It is recommended to change these from the defaults. When finished, click Next.

                        Setting the username and password for GeoServer administration

                      13. Enter the port that GeoServer will respond on. This affects the location of the GeoServer Web administration interface, as well as the endpoints of the GeoServer services such as Web Map Service (WMS) and Web Feature Service (WFS). The default port is 8080, though any valid and unused port will work. When finished, click Next.

                        Setting the GeoServer port

                      14. Select whether GeoServer should be run manually or installed as a service. When run manually, GeoServer is run like a standard application under the current user. When installed as a service, GeoServer is integrated into Windows Services, and thus is easier to administer. If running on a server, or to manage GeoServer as a service, select Install as a service. Otherwise, select Run manually. When finished, click Next.

                        Installing GeoServer as a service

                      15. Review your selections and click the Back button if any changes need to be made. Otherwise, click Install.

                        Verifying settings

                      16. GeoServer will install on your system.

                        Install progress

                      17. When finished, click Finish to close the installer.

                        Completing

                      18. If you installed GeoServer as a service, it is already running. Otherwise, you can start GeoServer by going to the Start Menu, and clicking Start GeoServer in the GeoServer folder.

                      19. Navigate to http://localhost:8080/geoserver (or wherever you installed GeoServer) to access the GeoServer Web administration interface.

                        If you see the GeoServer Welcome page, then GeoServer is successfully installed.

                        GeoServer Welcome Page

                      "},{"location":"installation/win_installer/#uninstallation","title":"Uninstallation","text":"

                      GeoServer can be uninstalled in two ways: by running the uninstall.exe file in the directory where GeoServer was installed, or by standard Windows program removal.

                      "},{"location":"introduction/","title":"Introduction","text":"

                      This section gives an overview of GeoServer the project, its background, and what it can do for you.

                      For those who wish to get started with GeoServer right away, feel free to skip to the Installation section.

                      • Overview
                      • History
                      • Getting involved
                      • License
                      "},{"location":"introduction/gettinginvolved/","title":"Getting involved","text":"

                      GeoServer exists because of the efforts of people like you.

                      There are many ways that you can help out with the GeoServer project. GeoServer fully embraces an open source development model that does not see a split between user and developer, producer and consumer, but instead sees everyone as a valuable contributor.

                      "},{"location":"introduction/gettinginvolved/#development","title":"Development","text":"

                      Helping to develop GeoServer is the obvious way to help out. Developers usually start with bug fixes and other small patches, and then move into larger contributions as they learn the system. Our developers are more than happy to help out as you learn and get acquainted. We try our hardest to keep our code clean and well documented.

                      You can find the project on GitHub. As part of the GitHub model, anyone can submit patches as pull requests, which will be evaluated by the team. To learn more about contributing to the GeoServer codebase, we highly recommend joining the GeoServer developers mailing list. See details below.

                      "},{"location":"introduction/gettinginvolved/#documentation","title":"Documentation","text":"

                      Another crucial way to help out is with documentation. Whether it's adding tutorials or just correcting mistakes, every contribution serves to make the project more healthy. And the best part is that you do not need to be a developer in order to contribute.

                      Our official documentation is contained as part of our official code repository. As part of the GitHub model, anyone can submit patches as pull requests, which will be evaluated by the team.

                      To learn more about contributing to the GeoServer codebase, we highly recommend joining the GeoServer developers mailing list (see details below). For typos and other small changes, please see our Documentation Guide for how to make quick fixes.

                      "},{"location":"introduction/gettinginvolved/#mailing-lists","title":"Mailing lists","text":"

                      GeoServer maintains two email lists:

                      • GeoServer Users
                      • GeoServer Developers

                      The Users list is mainly for those who have questions relating to the use of GeoServer, and the Developers list is for more code-specific and roadmap-based discussions. If you see a question asked on these lists that you know the answer to, please respond!

                      These lists are publicly available and are a great resource for those who are new to GeoServer, who need a question answered, or who are interested in contributing code.

                      "},{"location":"introduction/gettinginvolved/#irc","title":"IRC","text":"

                      Users can join the IRC channel, #geoserver, on the Freenode network, in order to collaborate in real time. GeoServer developers occasionally will be in this channel as well.

                      "},{"location":"introduction/gettinginvolved/#bug-tracking","title":"Bug tracking","text":"

                      If you have a problem when working with GeoServer, then please let us know through the mailing lists. GeoServer uses JIRA , a bug tracking website, to manage issue reports. In order to submit an issue, you'll need to create an account first.

                      Everyone is encouraged to submit patches and, if possible, fix issues as well. We welcome patches through JIRA, or pull requests to GitHub.

                      Responsible Disclosure

                      Warning

                      If you encounter a security vulnerability in GeoServer please take care to report the issue in a responsible fashion:

                      • Keep exploit details out of issue report (send to developer/PSC privately -- just like you would do for sensitive sample data)
                      • Mark the issue as a vulnerability.
                      • Be prepared to work with Project Steering Committee (PSC) members on a solution

                      Keep in mind PSC members are volunteers and an extensive fix may require fundraising / resources

                      If you are not in position to communicate in public please consider commercial support, contacting a PSC member, or reaching us via the Open Source Geospatial Foundation at info@osgeo.org.

                      "},{"location":"introduction/gettinginvolved/#translation","title":"Translation","text":"

                      We would like GeoServer available in as many languages as possible. The two areas of GeoServer to translate are the text that appears in the Web administration interface and this documentation. If you are interested in helping with this task, please let us know via the mailing lists.

                      "},{"location":"introduction/gettinginvolved/#suggest-improvements","title":"Suggest improvements","text":"

                      If you have suggestions as to how we can make GeoServer better, we would love to hear them. You can contact us through the mailing lists or submit a feature request through JIRA.

                      "},{"location":"introduction/gettinginvolved/#spread-the-word","title":"Spread the word","text":"

                      A further way to help out the GeoServer project is to spread the word. Word-of-mouth information sharing is more powerful than any marketing, and the more people who use our software, the better it will become.

                      "},{"location":"introduction/gettinginvolved/#fund-improvements","title":"Fund improvements","text":"

                      A final way to help out is to push for GeoServer to be used in your own organization. A number of commercial organizations offer support for GeoServer, and any improvements made due to that funding will benefit the entire GeoServer community.

                      "},{"location":"introduction/history/","title":"History","text":"

                      GeoServer was started in 2001 by The Open Planning Project (TOPP), a non-profit technology incubator based in New York. TOPP was creating a suite of tools to enable open democracy and to help make government more transparent. The first of these was GeoServer, which came out of a recognition that a suite of tools to enable citizen involvement in government and urban planning would be greatly enhanced by the ability to share spatial data.

                      The GeoServer founders envisioned a Geospatial Web, analogous to the World Wide Web. With the World Wide Web, one can search for and download text. With the Geospatial Web, one can search for and download spatial data. Data providers would be able to publish their data straight to this web, and users could directly access it, as opposed to the now indirect and cumbersome methods of sharing data that exist today.

                      Those involved with GeoServer founded the GeoTools project, an open source GIS Java toolkit. Through GeoTools, support for shapefiles, Oracle databases, and much more was added.

                      Around the same time as GeoServer was founded, The OpenGIS Consortium (now the Open Geospatial Consortium) was working on the Web Feature Service standard. It specifies a protocol to make spatial data directly available on the web, using GML (Geographic Markup Language), an interoperable data format. A Web Map Service was also created, a protocol for creating and displaying map images created from spatial data.

                      Other projects became interrelated. Refractions Research created PostGIS, a free and open spatial database, which enabled GeoServer to connect to a free database. Also, MetaCarta originally created OpenLayers, an open source browser-based map viewing utility. Together, these tools have all enhanced the functionality of GeoServer.

                      GeoServer can now read data from over a dozen spatial data sources and output to many different formats. Now in its second decade, GeoServer is continuing on its mission to make spatial data more accessible to all.

                      "},{"location":"introduction/license/","title":"License","text":"

                      For complete license information NOTICE.txt.

                      GeoServer is free software and is licensed under the GNU General Public License:

                      GeoServer, open geospatial information server Copyright (C) 2014-2020 Open Source Geospatial Foundation. Copyright (C) 2001-2014 OpenPlans

                      This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version (collectively, \"GPL\").

                      As an exception to the terms of the GPL, you may copy, modify, propagate, and distribute a work formed by combining GeoServer with the EMF, XSD and OSHI Libraries, or a work derivative of such a combination, even if such copying, modification, propagation, or distribution would otherwise violate the terms of the GPL. Nothing in this exception exempts you from complying with the GPL in all respects for all of the code used other than the EMF, XSD and OSHI Libraries. You may include this exception and its grant of permissions when you distribute GeoServer. Inclusion of this notice with such a distribution constitutes a grant of such permissions. If you do not wish to grant these permissions, remove this paragraph from your distribution. \"GeoServer\" means the GeoServer software licensed under version 2 or any later version of the GPL, or a work based on such software and licensed under the GPL. \"EMF, XSD and OSHI Libraries\" means Eclipse Modeling Framework Project and XML Schema Definition software distributed by the Eclipse Foundation and the OSHI library, all licensed under the Eclipse Public License Version 1.0 (\"EPL\"), or a work based on such software and licensed under the EPL.

                      This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

                      You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Suite 500, Boston, MA 02110-1335 USA

                      This product includes software developed by the Apache Software Foundation (http://www.apache.org/) licensed under the Apache License Version 2.0 and Apache License Version 1.1.

                      This product includes software developed by the Eclipse Software Foundation under the Eclipse Public License.

                      "},{"location":"introduction/overview/","title":"Overview","text":"

                      GeoServer is an open source software server written in Java that allows users to share and edit geospatial data. Designed for interoperability, it publishes data from any major spatial data source using open standards.

                      Being a community-driven project, GeoServer is developed, tested, and supported by a diverse group of individuals and organizations from around the world.

                      GeoServer is the reference implementation of the Open Geospatial Consortium (OGC) Web Feature Service (WFS) and Web Coverage Service (WCS) standards, as well as a high performance certified compliant Web Map Service (WMS). GeoServer forms a core component of the Geospatial Web.

                      "},{"location":"introduction/download/GPL/","title":"GPL","text":""},{"location":"introduction/download/GPL/#gnu-general-public-license","title":"GNU GENERAL PUBLIC LICENSE","text":"

                      Version 2, June 1991

                      Copyright (C) 1989, 1991 Free Software Foundation, Inc.  \n51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA\n\nEveryone is permitted to copy and distribute verbatim copies\nof this license document, but changing it is not allowed.\n
                      "},{"location":"introduction/download/GPL/#preamble","title":"Preamble","text":"

                      The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users. This General Public License applies to most of the Free Software Foundation's software and to any other program whose authors commit to using it. (Some other Free Software Foundation software is covered by the GNU Lesser General Public License instead.) You can apply it to your programs, too.

                      When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs; and that you know you can do these things.

                      To protect your rights, we need to make restrictions that forbid anyone to deny you these rights or to ask you to surrender the rights. These restrictions translate to certain responsibilities for you if you distribute copies of the software, or if you modify it.

                      For example, if you distribute copies of such a program, whether gratis or for a fee, you must give the recipients all the rights that you have. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights.

                      We protect your rights with two steps: (1) copyright the software, and (2) offer you this license which gives you legal permission to copy, distribute and/or modify the software.

                      Also, for each author's protection and ours, we want to make certain that everyone understands that there is no warranty for this free software. If the software is modified by someone else and passed on, we want its recipients to know that what they have is not the original, so that any problems introduced by others will not reflect on the original authors' reputations.

                      Finally, any free program is threatened constantly by software patents. We wish to avoid the danger that redistributors of a free program will individually obtain patent licenses, in effect making the program proprietary. To prevent this, we have made it clear that any patent must be licensed for everyone's free use or not licensed at all.

                      The precise terms and conditions for copying, distribution and modification follow.

                      "},{"location":"introduction/download/GPL/#terms-and-conditions-for-copying-distribution-and-modification","title":"TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION","text":"

                      0. This License applies to any program or other work which contains a notice placed by the copyright holder saying it may be distributed under the terms of this General Public License. The \"Program\", below, refers to any such program or work, and a \"work based on the Program\" means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language. (Hereinafter, translation is included without limitation in the term \"modification\".) Each licensee is addressed as \"you\".

                      Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program). Whether that is true depends on what the Program does.

                      1. You may copy and distribute verbatim copies of the Program's source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and give any other recipients of the Program a copy of this License along with the Program.

                      You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee.

                      2. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions:

                      a) You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change.

                      b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.

                      c) If the modified program normally reads commands interactively when run, you must cause it, when started running for such interactive use in the most ordinary way, to print or display an announcement including an appropriate copyright notice and a notice that there is no warranty (or else, saying that you provide a warranty) and that users may redistribute the program under these conditions, and telling the user how to view a copy of this License. (Exception: if the Program itself is interactive but does not normally print such an announcement, your work based on the Program is not required to print an announcement.)

                      These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.

                      Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program.

                      In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License.

                      3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following:

                      a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,

                      b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,

                      c) Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.)

                      The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.

                      If distribution of executable or object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place counts as distribution of the source code, even though third parties are not compelled to copy the source along with the object code.

                      4. You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.

                      5. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Program (or any work based on the Program), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Program or works based on it.

                      6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License.

                      7. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all. For example, if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program.

                      If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply and the section as a whole is intended to apply in other circumstances.

                      It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system, which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice.

                      This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License.

                      8. If the distribution and/or use of the Program is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Program under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License.

                      9. The Free Software Foundation may publish revised and/or new versions of the General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns.

                      Each version is given a distinguishing version number. If the Program specifies a version number of this License which applies to it and \"any later version\", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation.

                      10. If you wish to incorporate parts of the Program into other free programs whose distribution conditions are different, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally.

                      NO WARRANTY

                      11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM \"AS IS\" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.

                      12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

                      "},{"location":"introduction/download/GPL/#end-of-terms-and-conditions","title":"END OF TERMS AND CONDITIONS","text":""},{"location":"introduction/download/GPL/#how-to-apply-these-terms-to-your-new-programs","title":"How to Apply These Terms to Your New Programs","text":"

                      If you develop a new program, and you want it to be of the greatest possible use to the public, the best way to achieve this is to make it free software which everyone can redistribute and change under these terms.

                      To do so, attach the following notices to the program. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the \"copyright\" line and a pointer to where the full notice is found.

                      one line to give the program's name and an idea of what it does.\nCopyright (C) yyyy  name of author\n\nThis program is free software; you can redistribute it and/or\nmodify it under the terms of the GNU General Public License\nas published by the Free Software Foundation; either version 2\nof the License, or (at your option) any later version.\n\nThis program is distributed in the hope that it will be useful,\nbut WITHOUT ANY WARRANTY; without even the implied warranty of\nMERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the\nGNU General Public License for more details.\n\nYou should have received a copy of the GNU General Public License\nalong with this program; if not, write to the Free Software\nFoundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.\n

                      Also add information on how to contact you by electronic and paper mail.

                      If the program is interactive, make it output a short notice like this when it starts in an interactive mode:

                      Gnomovision version 69, Copyright (C) year name of author\nGnomovision comes with ABSOLUTELY NO WARRANTY; for details\ntype `show w'.  This is free software, and you are welcome\nto redistribute it under certain conditions; type `show c' \nfor details.\n

                      The hypothetical commands `show w' and `show c' should show the appropriate parts of the General Public License. Of course, the commands you use may be called something other than `show w' and `show c'; they could even be mouse-clicks or menu items--whatever suits your program.

                      You should also get your employer (if you work as a programmer) or your school, if any, to sign a \"copyright disclaimer\" for the program, if necessary. Here is a sample; alter the names:

                      Yoyodyne, Inc., hereby disclaims all copyright\ninterest in the program `Gnomovision'\n(which makes passes at compilers) written \nby James Hacker.\n\nsignature of Ty Coon, 1 April 1989\nTy Coon, President of Vice\n

                      This General Public License does not permit incorporating your program into proprietary programs. If your program is a subroutine library, you may consider it more useful to permit linking proprietary applications with the library. If this is what you want to do, use the GNU Lesser General Public License instead of this License.

                      "},{"location":"introduction/download/NOTICE/","title":"GeoServer License Notice","text":"

                      GeoServer is distributed under the GNU General Public License Version 2.0 license:

                      GeoServer, open geospatial information server\nCopyright (C) 2014-2020 Open Source Geospatial Foundation.\nCopyright (C) 2001-2014 OpenPlans\n\nThis program is free software; you can redistribute it and/or modify\nit under the terms of the GNU General Public License as published by\nthe Free Software Foundation; either version 2 of the License, or\n(at your option) any later version (collectively, \"GPL\").\n\nAs an exception to the terms of the GPL, you may copy, modify,\npropagate, and distribute a work formed by combining GeoServer with the\nEMF, XSD and OSHI Libraries, or a work derivative of such a combination, even if\nsuch copying, modification, propagation, or distribution would otherwise\nviolate the terms of the GPL. Nothing in this exception exempts you from\ncomplying with the GPL in all respects for all of the code used other\nthan the EMF, XSD and OSHI Libraries. You may include this exception and its grant\nof permissions when you distribute GeoServer.  Inclusion of this notice\nwith such a distribution constitutes a grant of such permissions.  If\nyou do not wish to grant these permissions, remove this paragraph from\nyour distribution. \"GeoServer\" means the GeoServer software licensed\nunder version 2 or any later version of the GPL, or a work based on such\nsoftware and licensed under the GPL. \"EMF, XSD and OSHI Libraries\" means \nEclipse Modeling Framework Project and XML Schema Definition software\ndistributed by the Eclipse Foundation and the OSHI library, all licensed \nunder the Eclipse Public License Version 1.0 (\"EPL\"), or a work based on \nsuch software and licensed under the EPL.\n\nThis program is distributed in the hope that it will be useful,\nbut WITHOUT ANY WARRANTY; without even the implied warranty of\nMERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the\nGNU General Public License for more details.\n\nYou should have received a copy of the GNU General Public License\nalong with this program; if not, write to the Free Software\nFoundation, Inc., 51 Franklin Street, Suite 500, Boston, MA 02110-1335  USA\n

                      For latest contact information of Open Source Geospatial Foundation see the website at https://www.osgeo.org. Current email is info@osgeo.org and address is OSGeo, 14525 SW Millikan #42523, Beaverton, Oregon, United States, 97005-2343.

                      The full GPL license is available in this directory in the file GPL.md

                      "},{"location":"introduction/download/NOTICE/#additional-libraries-and-code-used","title":"Additional Libraries and Code used","text":"

                      GeoServer uses several additional libraries and pieces of code. We are including the appropriate notices in this file. We'd like to thank all the creators of the libraries we rely on, GeoServer would certainly not be possible without them. There are also several LGPL libraries that do not require us to cite them, but we'd like to thank GeoTools - https://geotools.org, JTS - https://locationtech.github.io/jts/ WKB4J https://wkb4j.sourceforge.net, OpenPDF - https://github.com/LibrePDF/OpenPDF, and J. David Eisenberg's PNG encoder https://www.catcode.com/pngencoder/

                      "},{"location":"introduction/download/NOTICE/#neuquant-neural-net-quantization-algorithm","title":"NeuQuant Neural-Net Quantization Algorithm","text":"

                      GeoServer also thanks Anthony Dekker for the NeuQuant Neural-Net Quantization Algorithm. The copyright notice is intact in the source code and also here:

                      /* NeuQuant Neural-Net Quantization Algorithm\n * ------------------------------------------\n *\n * Copyright (c) 1994 Anthony Dekker\n *\n * NEUQUANT Neural-Net quantization algorithm by Anthony Dekker, 1994.\n * See \"Kohonen neural networks for optimal colour quantization\"\n * in \"Network: Computation in Neural Systems\" Vol. 5 (1994) pp 351-367.\n * for a discussion of the algorithm.\n *\n * Any party obtaining a copy of these files from the author, directly or\n * indirectly, is granted, free of charge, a full and unrestricted irrevocable,\n * world-wide, paid up, royalty-free, nonexclusive right and license to deal\n * in this software and documentation files (the \"Software\"), including without\n * limitation the rights to use, copy, modify, merge, publish, distribute, sublicense,\n * and/or sell copies of the Software, and to permit persons who receive\n * copies from any such party to do so, with the only requirement being\n * that this copyright notice remain intact.\n */\n
                      "},{"location":"introduction/download/NOTICE/#gifencoder","title":"GifEncoder","text":"

                      The GeoServer Project also thanks J. M. G. Elliot for his improvements on Jef Poskanzer's GifEncoder. Notice is included below on his Elliot's release to public domain and Poskanzer's original notice (which is new BSD). Source code is included in GeoServer source, with modifications done by David Blasby for The Open Planning Project (now OpenPlans).

                      Since Gif89Encoder includes significant sections of code from Jef Poskanzer's GifEncoder.java, I'm including its notice in this distribution as requested (appended below).

                      As for my part of the code, I hereby release it, on a strictly \"as is\" basis, to the public domain.

                      J. M. G. Elliott 15-Jul-2000

                      ---- from Jef Poskanzer's GifEncoder.java ----

                      // GifEncoder - write out an image as a GIF\n//\n// Transparency handling and variable bit size courtesy of Jack Palevich.\n//\n// Copyright (C) 1996 by Jef Poskanzer <jef@acme.com>.  All rights reserved.\n//\n// Redistribution and use in source and binary forms, with or without\n// modification, are permitted provided that the following conditions\n// are met:\n// 1. Redistributions of source code must retain the above copyright\n//    notice, this list of conditions and the following disclaimer.\n// 2. Redistributions in binary form must reproduce the above copyright\n//    notice, this list of conditions and the following disclaimer in the\n//    documentation and/or other materials provided with the distribution.\n//\n// THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND\n// ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE\n// IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE\n// ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE\n// FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL\n// DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS\n// OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)\n// HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT\n// LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY\n// OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF\n// SUCH DAMAGE.\n//\n// Visit the ACME Labs Java page for up-to-date versions of this and other\n// fine Java utilities: https://www.acme.com/java/\n
                      "},{"location":"introduction/download/NOTICE/#jai-imageio","title":"JAI ImageIO","text":"

                      JAI ImageIO jars from Sun are also included. These are released under a BSD license (new). Notice is below:

                      Initial sources\n\nCopyright (c) 2005 Sun Microsystems, Inc. All  Rights Reserved.\n\nRedistribution and use in source and binary forms, with or without\nmodification, are permitted provided that the following conditions\nare met:\n\n- Redistribution of source code must retain the above copyright \n  notice, this  list of conditions and the following disclaimer.\n\n- Redistribution in binary form must reproduce the above copyright\n  notice, this list of conditions and the following disclaimer in \n  the documentation and/or other materials provided with the\n  distribution.\n\nNeither the name of Sun Microsystems, Inc. or the names of \ncontributors may be used to endorse or promote products derived \nfrom this software without specific prior written permission.\n\nThis software is provided \"AS IS,\" without a warranty of any \nkind. ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND \nWARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, \nFITNESS FOR A PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE HEREBY\nEXCLUDED. SUN MIDROSYSTEMS, INC. (\"SUN\") AND ITS LICENSORS SHALL \nNOT BE LIABLE FOR ANY DAMAGES SUFFERED BY LICENSEE AS A RESULT OF \nUSING, MODIFYING OR DISTRIBUTING THIS SOFTWARE OR ITS\nDERIVATIVES. IN NO EVENT WILL SUN OR ITS LICENSORS BE LIABLE FOR \nANY LOST REVENUE, PROFIT OR DATA, OR FOR DIRECT, INDIRECT, SPECIAL,\nCONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, HOWEVER CAUSED AND\nREGARDLESS OF THE THEORY OF LIABILITY, ARISING OUT OF THE USE OF OR\nINABILITY TO USE THIS SOFTWARE, EVEN IF SUN HAS BEEN ADVISED OF THE\nPOSSIBILITY OF SUCH DAMAGES.\n\nYou acknowledge that this software is not designed or intended for \nuse in the design, construction, operation or maintenance of any \nnuclear facility.\n
                      "},{"location":"introduction/download/NOTICE/#jetty","title":"Jetty","text":"

                      GeoServer also includes binaries and from Jetty, the standard version can be found at https://www.eclipse.org/jetty/, released under an OSI-approved artistic license. We include the license completely, as some versions will be distributed without full source.

                      Jetty License $Revision: 3.7 $ Preamble:

                      The intent of this document is to state the conditions under which the Jetty Package may be copied, such that the Copyright Holder maintains some semblance of control over the development of the package, while giving the users of the package the right to use, distribute and make reasonable modifications to the Package in accordance with the goals and ideals of the Open Source concept as described at https://www.opensource.org.

                      It is the intent of this license to allow commercial usage of the Jetty package, so long as the source code is distributed or suitable visible credit given or other arrangements made with the copyright holders.

                      Definitions:

                      • \"Jetty\" refers to the collection of Java classes that are distributed as a HTTP server with servlet capabilities and associated utilities.

                      • \"Package\" refers to the collection of files distributed by the Copyright Holder, and derivatives of that collection of files created through textual modification.

                      • \"Standard Version\" refers to such a Package if it has not been modified, or has been modified in accordance with the wishes of the Copyright Holder.

                      • \"Copyright Holder\" is whoever is named in the copyright or copyrights for the package. Mort Bay Consulting Pty. Ltd. (Australia) is the \"Copyright Holder\" for the Jetty package.

                      • \"You\" is you, if you're thinking about copying or distributing this Package.

                      • \"Reasonable copying fee\" is whatever you can justify on the basis of media cost, duplication charges, time of people involved, and so on. (You will not be required to justify it to the Copyright Holder, but only to the computing community at large as a market that must bear the fee.)

                      • \"Freely Available\" means that no fee is charged for the item itself, though there may be fees involved in handling the item. It also means that recipients of the item may redistribute it under the same conditions they received it.

                      • The Jetty Package is Copyright \u00a9 Mort Bay Consulting Pty. Ltd. (Australia) and others. Individual files in this package may contain additional copyright notices. The javax.servlet packages are copyright Sun Microsystems Inc.

                      • The Standard Version of the Jetty package is available from https://jetty.mortbay.org.

                      • You may make and distribute verbatim copies of the source form of the Standard Version of this Package without restriction, provided that you include this license and all of the original copyright notices and associated disclaimers.

                      • You may make and distribute verbatim copies of the compiled form of the Standard Version of this Package without restriction, provided that you include this license.

                      • You may apply bug fixes, portability fixes and other modifications derived from the Public Domain or from the Copyright Holder. A Package modified in such a way shall still be considered the Standard Version.

                      • You may otherwise modify your copy of this Package in any way, provided that you insert a prominent notice in each changed file stating how and when you changed that file, and provided that you do at least ONE of the following:

                        a) Place your modifications in the Public Domain or otherwise make them Freely Available, such as by posting said modifications to Usenet or an equivalent medium, or placing the modifications on a major archive site such as ftp.uu.net, or by allowing the Copyright Holder to include your modifications in the Standard Version of the Package.

                        b) Use the modified Package only within your corporation or organization.

                        c) Rename any non-standard classes so the names do not conflict with standard classes, which must also be provided, and provide a separate manual page for each non-standard class that clearly documents how it differs from the Standard Version.

                        d) Make other arrangements with the Copyright Holder.

                      • You may distribute modifications or subsets of this Package in source code or compiled form, provided that you do at least ONE of the following:

                        a) Distribute this license and all original copyright messages, together with instructions (in the about dialog, manual page or equivalent) on where to get the complete Standard Version.

                        b) Accompany the distribution with the machine-readable source of the Package with your modifications. The modified package must include this license and all of the original copyright notices and associated disclaimers, together with instructions on where to get the complete Standard Version.

                        c) Make other arrangements with the Copyright Holder.

                      • You may charge a reasonable copying fee for any distribution of this Package. You may charge any fee you choose for support of this Package. You may not charge a fee for this Package itself. However, you may distribute this Package in aggregate with other (possibly commercial) programs as part of a larger (possibly commercial) software distribution provided that you meet the other distribution requirements of this license.

                      • Input to or the output produced from the programs of this Package do not automatically fall under the copyright of this Package, but belong to whomever generated them, and may be sold commercially, and may be aggregated with this Package.

                      • Any program subroutines supplied by you and linked into this Package shall not be considered part of this Package.

                      • The name of the Copyright Holder may not be used to endorse or promote products derived from this software without specific prior written permission.

                      • This license may change with each release of a Standard Version of the Package. You may choose to use the license associated with version you are using or the license of the latest Standard Version.

                      • THIS PACKAGE IS PROVIDED \"AS IS\" AND WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.

                      • If any superior law implies a warranty, the sole remedy under such shall be , at the Copyright Holders option either a) return of any price paid or b) use or reasonable endeavours to repair or replace the software.

                      • This license shall be read under the laws of Australia.

                      "},{"location":"introduction/download/NOTICE/#prototype-library-mit-license","title":"Prototype library (MIT License)","text":"

                      GeoServer includes a few snippets from the Prototype library (www.prototypejs.org), under a MIT license:

                      Copyright (c) 2005-2007 Sam Stephenson\n\nPermission is hereby granted, free of charge, to any person obtaining a copy\nof this software and associated documentation files (the \"Software\"), to deal\nin the Software without restriction, including without limitation the rights\nto use, copy, modify, merge, publish, distribute, sublicense, and/or sell\ncopies of the Software, and to permit persons to whom the Software is\nfurnished to do so, subject to the following conditions:\n\nTHE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\nIMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\nFITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE\nAUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\nLIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,\nOUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE\nSOFTWARE.\n
                      "},{"location":"introduction/download/NOTICE/#apache-license","title":"Apache License","text":"

                      GeoServer uses a number of libraries licensed under the Apache License, Version 2.0. These include Spring - https://www.springsource.org/, a number of Apache commons libraries - https://jakarta.apache.org/commons/ whose jars we distribute and include in our source tree under lib/. Also included as libraries are log4 https://logging.apache.org/log4j/docs/index.htmlj, batik https://xmlgraphics.apache.org/batik/, and xerces https://xerces.apache.org/xerces-j/.

                      Note there is some disagreement as to whether GPL and Apache 2.0 are compatible see https://www.apache.org/licenses/GPL-compatibility.html for more information. We hope that something will work out, as GeoServer would not be possible without apache libraries.

                      Notice for apache license is included below:

                      Apache License Version 2.0, January 2004 https://www.apache.org/licenses/

                      TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION

                      1. Definitions.

                      \"License\" shall mean the terms and conditions for use, reproduction, and distribution as defined by Sections 1 through 9 of this document.

                      \"Licensor\" shall mean the copyright owner or entity authorized by the copyright owner that is granting the License.

                      \"Legal Entity\" shall mean the union of the acting entity and all other entities that control, are controlled by, or are under common control with that entity. For the purposes of this definition, \"control\" means (i) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (ii) ownership of fifty percent (50%) or more of the outstanding shares, or (iii) beneficial ownership of such entity.

                      \"You\" (or \"Your\") shall mean an individual or Legal Entity exercising permissions granted by this License.

                      \"Source\" form shall mean the preferred form for making modifications, including but not limited to software source code, documentation source, and configuration files.

                      \"Object\" form shall mean any form resulting from mechanical transformation or translation of a Source form, including but not limited to compiled object code, generated documentation, and conversions to other media types.

                      \"Work\" shall mean the work of authorship, whether in Source or Object form, made available under the License, as indicated by a copyright notice that is included in or attached to the work (an example is provided in the Appendix below).

                      \"Derivative Works\" shall mean any work, whether in Source or Object form, that is based on (or derived from) the Work and for which the editorial revisions, annotations, elaborations, or other modifications represent, as a whole, an original work of authorship. For the purposes of this License, Derivative Works shall not include works that remain separable from, or merely link (or bind by name) to the interfaces of, the Work and Derivative Works thereof.

                      \"Contribution\" shall mean any work of authorship, including the original version of the Work and any modifications or additions to that Work or Derivative Works thereof, that is intentionally submitted to Licensor for inclusion in the Work by the copyright owner or by an individual or Legal Entity authorized to submit on behalf of the copyright owner. For the purposes of this definition, \"submitted\" means any form of electronic, verbal, or written communication sent to the Licensor or its representatives, including but not limited to communication on electronic mailing lists, source code control systems, and issue tracking systems that are managed by, or on behalf of, the Licensor for the purpose of discussing and improving the Work, but excluding communication that is conspicuously marked or otherwise designated in writing by the copyright owner as \"Not a Contribution.\"

                      \"Contributor\" shall mean Licensor and any individual or Legal Entity on behalf of whom a Contribution has been received by Licensor and subsequently incorporated within the Work.

                      1. Grant of Copyright License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare Derivative Works of, publicly display, publicly perform, sublicense, and distribute the Work and such Derivative Works in Source or Object form.

                      2. Grant of Patent License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work to which such Contribution(s) was submitted. If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed.

                      3. Redistribution. You may reproduce and distribute copies of the Work or Derivative Works thereof in any medium, with or without modifications, and in Source or Object form, provided that You meet the following conditions:

                        1. You must give any other recipients of the Work or Derivative Works a copy of this License; and

                        2. You must cause any modified files to carry prominent notices stating that You changed the files; and

                        3. You must retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Works; and

                        4. If the Work includes a \"NOTICE\" text file as part of its distribution, then any Derivative Works that You distribute must include a readable copy of the attribution notices contained within such NOTICE file, excluding those notices that do not pertain to any part of the Derivative Works, in at least one of the following places: within a NOTICE text file distributed as part of the Derivative Works; within the Source form or documentation, if provided along with the Derivative Works; or, within a display generated by the Derivative Works, if and wherever such third-party notices normally appear. The contents of the NOTICE file are for informational purposes only and do not modify the License. You may add Your own attribution notices within Derivative Works that You distribute, alongside or as an addendum to the NOTICE text from the Work, provided that such additional attribution notices cannot be construed as modifying the License.

                      You may add Your own copyright statement to Your modifications and may provide additional or different license terms and conditions for use, reproduction, or distribution of Your modifications, or for any such Derivative Works as a whole, provided Your use, reproduction, and distribution of the Work otherwise complies with the conditions stated in this License.

                      1. Submission of Contributions. Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions. Notwithstanding the above, nothing herein shall supersede or modify the terms of any separate license agreement you may have executed with Licensor regarding such Contributions.

                      2. Trademarks. This License does not grant permission to use the trade names, trademarks, service marks, or product names of the Licensor, except as required for reasonable and customary use in describing the origin of the Work and reproducing the content of the NOTICE file.

                      3. Disclaimer of Warranty. Unless required by applicable law or agreed to in writing, Licensor provides the Work (and each Contributor provides its Contributions) on an \"AS IS\" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are solely responsible for determining the appropriateness of using or redistributing the Work and assume any risks associated with Your exercise of permissions under this License.

                      4. Limitation of Liability. In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall any Contributor be liable to You for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising as a result of this License or out of the use or inability to use the Work (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if such Contributor has been advised of the possibility of such damages.

                      5. Accepting Warranty or Additional Liability. While redistributing the Work or Derivative Works thereof, You may choose to offer, and charge a fee for, acceptance of support, warranty, indemnity, or other liability obligations and/or rights consistent with this License. However, in accepting such obligations, You may act only on Your own behalf and on Your sole responsibility, not on behalf of any other Contributor, and only if You agree to indemnify, defend, and hold each Contributor harmless for any liability incurred by, or claims asserted against, such Contributor by reason of your accepting any such warranty or additional liability.

                      END OF TERMS AND CONDITIONS

                      "},{"location":"introduction/download/NOTICE/#eclipse-public-license","title":"Eclipse Public License","text":"

                      GeoServer is build using a number of eclipse libraries including emf and xsd made available under the Eclipse Public License.

                      The notice for EPL license is included below:

                      Copyright (c) 2002-2006 IBM Corporation and others.\nAll rights reserved.   This program and the accompanying materials\nare made available under the terms of the Eclipse Public License v1.0\nwhich accompanies this distribution, and is available at\nhttps://www.eclipse.org/legal/epl-v10.html\n
                      "},{"location":"introduction/download/NOTICE/#java-service-launcher-jsl","title":"Java Service Launcher (JSL)","text":"

                      GeoServer uses the Java Service Launcher (JSL) by Michael Roeschter as a wrapper to install GeoServer as a Windows service. The following license applies to this software (taken from https://roeschter.de/#license):

                      JAVA SERVICE LAUNCHER (JSL) is PUBLIC DOMAIN.\n\nThis means the software is FREE. Free means you may use or reuse \nany part of the software. You may package it with commercial software \nand use it in commercial and business environments. \nYou may NOT claim copyright for the JSL software and it's source code \nor any parts of the software and source. \nAny derived work may retain a copyright or be commercialized as long \nas the JSL parts of it are not covered by this copyright.\n\nYou may distribute derived work in executable form and not include \nthe JSL source code if JSL constitues only a minor part of the \nintellectual work (in other words, you can take the executable and \nembed it in a Java application you distribute commercially), but you \nmay not charge in particular for or discriminate against the use of \nthe parts derived from JSL.\n\nDisclaimer: \nThis software is supplied AS IS with no claim of fitness for purpose.\n
                      "},{"location":"introduction/download/apache-1.1/","title":"Apache 1.1","text":""},{"location":"introduction/download/apache-1.1/#the-apache-software-license-version-11","title":"The Apache Software License, Version 1.1","text":"

                      Copyright \u00a9 2000-2002 The Apache Software Foundation. All rights reserved.

                      Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

                      1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.

                      2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

                      3. The end-user documentation included with the redistribution, if any, must include the following acknowledgment:

                        \"This product includes software developed by the Apache Software Foundation (http://www.apache.org/).\"

                      Alternately, this acknowledgment may appear in the software itself, if and wherever such third-party acknowledgments normally appear.

                      1. The names \"Xerces\" and \"Apache Software Foundation\" must not be used to endorse or promote products derived from this software without prior written permission. For written permission, please contact apache@apache.org.
                      2. Products derived from this software may not be called \"Apache\", nor may \"Apache\" appear in their name, without prior written permission of the Apache Software Foundation.

                      THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

                      "},{"location":"introduction/download/apache-2.0/","title":"Apache License","text":"

                      Version 2.0, January 2004 <http://www.apache.org/licenses/>

                      "},{"location":"introduction/download/apache-2.0/#terms-and-conditions-for-use-reproduction-and-distribution","title":"Terms and Conditions for use, reproduction, and distribution","text":""},{"location":"introduction/download/apache-2.0/#1-definitions","title":"1. Definitions","text":"

                      \u201cLicense\u201d shall mean the terms and conditions for use, reproduction, and distribution as defined by Sections 1 through 9 of this document.

                      \u201cLicensor\u201d shall mean the copyright owner or entity authorized by the copyright owner that is granting the License.

                      \u201cLegal Entity\u201d shall mean the union of the acting entity and all other entities that control, are controlled by, or are under common control with that entity. For the purposes of this definition, \u201ccontrol\u201d means (i) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (ii) ownership of fifty percent (50%) or more of the outstanding shares, or (iii) beneficial ownership of such entity.

                      \u201cYou\u201d (or \u201cYour\u201d) shall mean an individual or Legal Entity exercising permissions granted by this License.

                      \u201cSource\u201d form shall mean the preferred form for making modifications, including but not limited to software source code, documentation source, and configuration files.

                      \u201cObject\u201d form shall mean any form resulting from mechanical transformation or translation of a Source form, including but not limited to compiled object code, generated documentation, and conversions to other media types.

                      \u201cWork\u201d shall mean the work of authorship, whether in Source or Object form, made available under the License, as indicated by a copyright notice that is included in or attached to the work (an example is provided in the Appendix below).

                      \u201cDerivative Works\u201d shall mean any work, whether in Source or Object form, that is based on (or derived from) the Work and for which the editorial revisions, annotations, elaborations, or other modifications represent, as a whole, an original work of authorship. For the purposes of this License, Derivative Works shall not include works that remain separable from, or merely link (or bind by name) to the interfaces of, the Work and Derivative Works thereof.

                      \u201cContribution\u201d shall mean any work of authorship, including the original version of the Work and any modifications or additions to that Work or Derivative Works thereof, that is intentionally submitted to Licensor for inclusion in the Work by the copyright owner or by an individual or Legal Entity authorized to submit on behalf of the copyright owner. For the purposes of this definition, \u201csubmitted\u201d means any form of electronic, verbal, or written communication sent to the Licensor or its representatives, including but not limited to communication on electronic mailing lists, source code control systems, and issue tracking systems that are managed by, or on behalf of, the Licensor for the purpose of discussing and improving the Work, but excluding communication that is conspicuously marked or otherwise designated in writing by the copyright owner as \u201cNot a Contribution.\u201d

                      \u201cContributor\u201d shall mean Licensor and any individual or Legal Entity on behalf of whom a Contribution has been received by Licensor and subsequently incorporated within the Work.

                      "},{"location":"introduction/download/apache-2.0/#2-grant-of-copyright-license","title":"2. Grant of Copyright License","text":"

                      Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare Derivative Works of, publicly display, publicly perform, sublicense, and distribute the Work and such Derivative Works in Source or Object form.

                      "},{"location":"introduction/download/apache-2.0/#3-grant-of-patent-license","title":"3. Grant of Patent License","text":"

                      Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work to which such Contribution(s) was submitted. If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed.

                      "},{"location":"introduction/download/apache-2.0/#4-redistribution","title":"4. Redistribution","text":"

                      You may reproduce and distribute copies of the Work or Derivative Works thereof in any medium, with or without modifications, and in Source or Object form, provided that You meet the following conditions:

                      • (a) You must give any other recipients of the Work or Derivative Works a copy of this License; and
                      • (b) You must cause any modified files to carry prominent notices stating that You changed the files; and
                      • \u00a9 You must retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Works; and
                      • (d) If the Work includes a \u201cNOTICE\u201d text file as part of its distribution, then any Derivative Works that You distribute must include a readable copy of the attribution notices contained within such NOTICE file, excluding those notices that do not pertain to any part of the Derivative Works, in at least one of the following places: within a NOTICE text file distributed as part of the Derivative Works; within the Source form or documentation, if provided along with the Derivative Works; or, within a display generated by the Derivative Works, if and wherever such third-party notices normally appear. The contents of the NOTICE file are for informational purposes only and do not modify the License. You may add Your own attribution notices within Derivative Works that You distribute, alongside or as an addendum to the NOTICE text from the Work, provided that such additional attribution notices cannot be construed as modifying the License.

                      You may add Your own copyright statement to Your modifications and may provide additional or different license terms and conditions for use, reproduction, or distribution of Your modifications, or for any such Derivative Works as a whole, provided Your use, reproduction, and distribution of the Work otherwise complies with the conditions stated in this License.

                      "},{"location":"introduction/download/apache-2.0/#5-submission-of-contributions","title":"5. Submission of Contributions","text":"

                      Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions. Notwithstanding the above, nothing herein shall supersede or modify the terms of any separate license agreement you may have executed with Licensor regarding such Contributions.

                      "},{"location":"introduction/download/apache-2.0/#6-trademarks","title":"6. Trademarks","text":"

                      This License does not grant permission to use the trade names, trademarks, service marks, or product names of the Licensor, except as required for reasonable and customary use in describing the origin of the Work and reproducing the content of the NOTICE file.

                      "},{"location":"introduction/download/apache-2.0/#7-disclaimer-of-warranty","title":"7. Disclaimer of Warranty","text":"

                      Unless required by applicable law or agreed to in writing, Licensor provides the Work (and each Contributor provides its Contributions) on an \u201cAS IS\u201d BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are solely responsible for determining the appropriateness of using or redistributing the Work and assume any risks associated with Your exercise of permissions under this License.

                      "},{"location":"introduction/download/apache-2.0/#8-limitation-of-liability","title":"8. Limitation of Liability","text":"

                      In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall any Contributor be liable to You for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising as a result of this License or out of the use or inability to use the Work (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if such Contributor has been advised of the possibility of such damages.

                      "},{"location":"introduction/download/apache-2.0/#9-accepting-warranty-or-additional-liability","title":"9. Accepting Warranty or Additional Liability","text":"

                      While redistributing the Work or Derivative Works thereof, You may choose to offer, and charge a fee for, acceptance of support, warranty, indemnity, or other liability obligations and/or rights consistent with this License. However, in accepting such obligations, You may act only on Your own behalf and on Your sole responsibility, not on behalf of any other Contributor, and only if You agree to indemnify, defend, and hold each Contributor harmless for any liability incurred by, or claims asserted against, such Contributor by reason of your accepting any such warranty or additional liability.

                      END OF TERMS AND CONDITIONS

                      "},{"location":"introduction/download/apache-2.0/#appendix-how-to-apply-the-apache-license-to-your-work","title":"APPENDIX: How to apply the Apache License to your work","text":"

                      To apply the Apache License to your work, attach the following boilerplate notice, with the fields enclosed by brackets [] replaced with your own identifying information. (Don't include the brackets!) The text should be enclosed in the appropriate comment syntax for the file format. We also recommend that a file or class name and description of purpose be included on the same \u201cprinted page\u201d as the copyright notice for easier identification within third-party archives.

                      Copyright [yyyy] [name of copyright owner]\n\nLicensed under the Apache License, Version 2.0 (the \"License\");\nyou may not use this file except in compliance with the License.\nYou may obtain a copy of the License at\n\n  http://www.apache.org/licenses/LICENSE-2.0\n\nUnless required by applicable law or agreed to in writing, software\ndistributed under the License is distributed on an \"AS IS\" BASIS,\nWITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.\nSee the License for the specific language governing permissions and\nlimitations under the License.\n
                      "},{"location":"introduction/download/epl-1.0/","title":"Epl 1.0","text":""},{"location":"introduction/download/epl-1.0/#eclipse-public-license-v-10","title":"Eclipse Public License -v 1.0","text":"

                      THE ACCOMPANYING PROGRAM IS PROVIDED UNDER THE TERMS OF THIS ECLIPSE PUBLIC LICENSE (\"AGREEMENT\"). ANY USE, REPRODUCTION OR DISTRIBUTION OF THE PROGRAM CONSTITUTES RECIPIENT'S ACCEPTANCE OF THIS AGREEMENT.

                      "},{"location":"introduction/download/epl-1.0/#1-definitions","title":"1. DEFINITIONS","text":"

                      \"Contribution\" means:

                      a) in the case of the initial Contributor, the initial code and documentation distributed under this Agreement, and

                      b) in the case of each subsequent Contributor:

                      i) changes to the Program, and

                      ii) additions to the Program;

                      where such changes and/or additions to the Program originate from and are distributed by that particular Contributor. A Contribution 'originates' from a Contributor if it was added to the Program by such Contributor itself or anyone acting on such Contributor's behalf. Contributions do not include additions to the Program which: (i) are separate modules of software distributed in conjunction with the Program under their own license agreement, and (ii) are not derivative works of the Program.

                      \"Contributor\" means any person or entity that distributes the Program.

                      \"Licensed Patents \" mean patent claims licensable by a Contributor which are necessarily infringed by the use or sale of its Contribution alone or when combined with the Program.

                      \"Program\" means the Contributions distributed in accordance with this Agreement.

                      \"Recipient\" means anyone who receives the Program under this Agreement, including all Contributors.

                      "},{"location":"introduction/download/epl-1.0/#2-grant-of-rights","title":"2. GRANT OF RIGHTS","text":"

                      a) Subject to the terms of this Agreement, each Contributor hereby grants Recipient a non-exclusive, worldwide, royalty-free copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, distribute and sublicense the Contribution of such Contributor, if any, and such derivative works, in source code and object code form.

                      b) Subject to the terms of this Agreement, each Contributor hereby grants Recipient a non-exclusive, worldwide, royalty-free patent license under Licensed Patents to make, use, sell, offer to sell, import and otherwise transfer the Contribution of such Contributor, if any, in source code and object code form. This patent license shall apply to the combination of the Contribution and the Program if, at the time the Contribution is added by the Contributor, such addition of the Contribution causes such combination to be covered by the Licensed Patents. The patent license shall not apply to any other combinations which include the Contribution. No hardware per se is licensed hereunder.

                      c) Recipient understands that although each Contributor grants the licenses to its Contributions set forth herein, no assurances are provided by any Contributor that the Program does not infringe the patent or other intellectual property rights of any other entity. Each Contributor disclaims any liability to Recipient for claims brought by any other entity based on infringement of intellectual property rights or otherwise. As a condition to exercising the rights and licenses granted hereunder, each Recipient hereby assumes sole responsibility to secure any other intellectual property rights needed, if any. For example, if a third party patent license is required to allow Recipient to distribute the Program, it is Recipient's responsibility to acquire that license before distributing the Program.

                      d) Each Contributor represents that to its knowledge it has sufficient copyright rights in its Contribution, if any, to grant the copyright license set forth in this Agreement.

                      "},{"location":"introduction/download/epl-1.0/#3-requirements","title":"3. REQUIREMENTS","text":"

                      A Contributor may choose to distribute the Program in object code form under its own license agreement, provided that:

                      a) it complies with the terms and conditions of this Agreement; and

                      b) its license agreement:

                      i) effectively disclaims on behalf of all Contributors all warranties and conditions, express and implied, including warranties or conditions of title and non-infringement, and implied warranties or conditions of merchantability and fitness for a particular purpose;

                      ii) effectively excludes on behalf of all Contributors all liability for damages, including direct, indirect, special, incidental and consequential damages, such as lost profits;

                      iii) states that any provisions which differ from this Agreement are offered by that Contributor alone and not by any other party; and

                      iv) states that source code for the Program is available from such Contributor, and informs licensees how to obtain it in a reasonable manner on or through a medium customarily used for software exchange.

                      When the Program is made available in source code form:

                      a) it must be made available under this Agreement; and

                      b) a copy of this Agreement must be included with each copy of the Program.

                      Contributors may not remove or alter any copyright notices contained within the Program.

                      Each Contributor must identify itself as the originator of its Contribution, if any, in a manner that reasonably allows subsequent Recipients to identify the originator of the Contribution.

                      "},{"location":"introduction/download/epl-1.0/#4-commercial-distribution","title":"4. COMMERCIAL DISTRIBUTION","text":"

                      Commercial distributors of software may accept certain responsibilities with respect to end users, business partners and the like. While this license is intended to facilitate the commercial use of the Program, the Contributor who includes the Program in a commercial product offering should do so in a manner which does not create potential liability for other Contributors. Therefore, if a Contributor includes the Program in a commercial product offering, such Contributor (\"Commercial Contributor\") hereby agrees to defend and indemnify every other Contributor (\"Indemnified Contributor\") against any losses, damages and costs (collectively \"Losses\") arising from claims, lawsuits and other legal actions brought by a third party against the Indemnified Contributor to the extent caused by the acts or omissions of such Commercial Contributor in connection with its distribution of the Program in a commercial product offering. The obligations in this section do not apply to any claims or Losses relating to any actual or alleged intellectual property infringement. In order to qualify, an Indemnified Contributor must: a) promptly notify the Commercial Contributor in writing of such claim, and b) allow the Commercial Contributor to control, and cooperate with the Commercial Contributor in, the defense and any related settlement negotiations. The Indemnified Contributor may participate in any such claim at its own expense.

                      For example, a Contributor might include the Program in a commercial product offering, Product X. That Contributor is then a Commercial Contributor. If that Commercial Contributor then makes performance claims, or offers warranties related to Product X, those performance claims and warranties are such Commercial Contributor's responsibility alone. Under this section, the Commercial Contributor would have to defend claims against the other Contributors related to those performance claims and warranties, and if a court requires any other Contributor to pay any damages as a result, the Commercial Contributor must pay those damages.

                      "},{"location":"introduction/download/epl-1.0/#5-no-warranty","title":"5. NO WARRANTY","text":"

                      EXCEPT AS EXPRESSLY SET FORTH IN THIS AGREEMENT, THE PROGRAM IS PROVIDED ON AN \"AS IS\" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED INCLUDING, WITHOUT LIMITATION, ANY WARRANTIES OR CONDITIONS OF TITLE, NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Each Recipient is solely responsible for determining the appropriateness of using and distributing the Program and assumes all risks associated with its exercise of rights under this Agreement , including but not limited to the risks and costs of program errors, compliance with applicable laws, damage to or loss of data, programs or equipment, and unavailability or interruption of operations.

                      "},{"location":"introduction/download/epl-1.0/#6-disclaimer-of-liability","title":"6. DISCLAIMER OF LIABILITY","text":"

                      EXCEPT AS EXPRESSLY SET FORTH IN THIS AGREEMENT, NEITHER RECIPIENT NOR ANY CONTRIBUTORS SHALL HAVE ANY LIABILITY FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING WITHOUT LIMITATION LOST PROFITS), HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OR DISTRIBUTION OF THE PROGRAM OR THE EXERCISE OF ANY RIGHTS GRANTED HEREUNDER, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

                      "},{"location":"introduction/download/epl-1.0/#7-general","title":"7. GENERAL","text":"

                      If any provision of this Agreement is invalid or unenforceable under applicable law, it shall not affect the validity or enforceability of the remainder of the terms of this Agreement, and without further action by the parties hereto, such provision shall be reformed to the minimum extent necessary to make such provision valid and enforceable.

                      If Recipient institutes patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Program itself (excluding combinations of the Program with other software or hardware) infringes such Recipient's patent(s), then such Recipient's rights granted under Section 2(b) shall terminate as of the date such litigation is filed.

                      All Recipient's rights under this Agreement shall terminate if it fails to comply with any of the material terms or conditions of this Agreement and does not cure such failure in a reasonable period of time after becoming aware of such noncompliance. If all Recipient's rights under this Agreement terminate, Recipient agrees to cease use and distribution of the Program as soon as reasonably practicable. However, Recipient's obligations under this Agreement and any licenses granted by Recipient relating to the Program shall continue and survive.

                      Everyone is permitted to copy and distribute copies of this Agreement, but in order to avoid inconsistency the Agreement is copyrighted and may only be modified in the following manner. The Agreement Steward reserves the right to publish new versions (including revisions) of this Agreement from time to time. No one other than the Agreement Steward has the right to modify this Agreement. The Eclipse Foundation is the initial Agreement Steward. The Eclipse Foundation may assign the responsibility to serve as the Agreement Steward to a suitable separate entity. Each new version of the Agreement will be given a distinguishing version number. The Program (including Contributions) may always be distributed subject to the version of the Agreement under which it was received. In addition, after a new version of the Agreement is published, Contributor may elect to distribute the Program (including its Contributions) under the new version. Except as expressly stated in Sections 2(a) and 2(b) above, Recipient receives no rights or licenses to the intellectual property of any Contributor under this Agreement, whether expressly, by implication, estoppel or otherwise. All rights in the Program not expressly granted under this Agreement are reserved.

                      This Agreement is governed by the laws of the State of New York and the intellectual property laws of the United States of America. No party to this Agreement will bring a legal action under this Agreement more than one year after the cause of action arose. Each party waives its rights to a jury trial in any resulting litigation.

                      "},{"location":"production/","title":"Running in a production environment","text":"

                      GeoServer is geared towards many different uses, from a simple test server to the enterprise-level data server. While many optimizations for GeoServer are set by default, here are some extra considerations to keep in mind when running GeoServer in a production environment.

                      • Java Considerations
                      • Container Considerations
                      • Configuration Considerations
                      • Data Considerations
                      • Linux init scripts
                      • Other Considerations
                      • Troubleshooting
                      • Make cluster nodes identifiable from the GUI
                      "},{"location":"production/config/","title":"Configuration Considerations","text":""},{"location":"production/config/#use-production-logging","title":"Use production logging","text":"

                      Logging may visibly affect the performance of your server. High logging levels are often necessary to track down issues, but by default you should run with low levels. (You can switch the logging levels while GeoServer is running.)

                      You can change the logging level in the Logging Profile. You will want to choose the PRODUCTION logging configuration, where only problems are written to the log files.

                      "},{"location":"production/config/#logging-configuration-hardening","title":"Logging configuration hardening","text":"

                      For production systems, it is advised to set GEOSERVER_LOG_LOCATION parameter during startup. The value may be defined as either an environment variable, java system property, or servlet context parameter.

                      The location set for GEOSERVER_LOG_LOCATION has priority, causing the value provided using the Admin Console GUI or REST API to be ignored. This approach establishes a separation of responsibility between those setting up and controlling the actual machine, and those configuring the GeoServer application.

                      See Advanced log configuration for more information.

                      "},{"location":"production/config/#set-a-service-strategy","title":"Set a service strategy","text":"

                      A service strategy is the method in which output is served to the client. This is a balance between proper form (being absolutely sure of reporting errors with the proper OGC codes, etc.) and speed (serving output as quickly as possible). This is a decision to be made based on the function that GeoServer is providing. You can configure the service strategy by modifying the web.xml file of your GeoServer instance.

                      The possible strategies are:

                      Strategy Description

                      SPEED Serves output right away. This is the fastest strategy, but proper OGC errors are usually omitted.

                      BUFFER Stores the whole result in memory, and then serves it after the output is complete. This ensures proper OGC error reporting, but delays the response quite a bit and can exhaust memory if the response is large.

                      FILE Similar to BUFFER, but stores the whole result in a file instead of in memory. Slower than BUFFER, but ensures there won't be memory issues.

                      PARTIAL-BUFFER A balance between BUFFER and SPEED, this strategy tries to buffer in memory a few KB of response, then serves the full output.

                      "},{"location":"production/config/#personalize-your-server","title":"Personalize your server","text":"

                      This isn't a performance consideration, but it is just as important. In order to make GeoServer as useful as possible, you should customize the server's metadata to your organization. It may be tempting to skip some of the configuration steps, and leave in the same keywords and abstract as the sample, but this will only confuse potential users.

                      Suggestions:

                      • Fill out the WFS, WMS, and WCS Service Metadata sections (this info will be broadcast as part of the capabilities documents)
                      • Serve your data with your own namespace (and provide a correct URI)
                      • Remove default layers (such as topp:states)
                      "},{"location":"production/config/#configure-service-limits","title":"Configure service limits","text":"

                      Make sure clients cannot request an inordinate amount of resources from your server.

                      In particular:

                      • Set the maximum amount of features returned by each WFS GetFeature request (this can also be set on a per featuretype basis by modifying the layer publishing wfs settings).
                      • Set the WMS request limits so that no request will consume too much memory or too much time
                      • Set WPS limits, so no process will consume too much memory or too much time. You may also limit the size input parameters for further control.
                      "},{"location":"production/config/#set-security-for-data-modification","title":"Set security for data modification","text":"

                      GeoServer includes support for WFS-T (transactions) by default, which lets users modify your data.

                      If you don't want your database modified, you can turn off transactions in the WFS settings. Set the Service Level to Basic. For extra security, we recommend any database access use datastore credentials providing read-only permissions. This will eliminate the possibility of a SQL injection (though GeoServer is generally not vulnerable to that sort of attack).

                      If you would like some users to be able to modify data, set the service level Service Level to Transactional (or Complete) and use Service Security to limit access to the WFS.Transaction operation.

                      If you would like some users to be able to modify some but not all of your data, set the Service Level to Transactional (or Complete), and use Layer security to limit write access to specific layers. Data security can be used to allow write access based on workspace, datastore, or layer security.

                      "},{"location":"production/config/#cache-your-data","title":"Cache your data","text":"

                      Server-side caching of WMS tiles is the best way to increase performance. In caching, pre-rendered tiles will be saved, eliminating the need for redundant WMS calls. There are several ways to set up WMS caching for GeoServer. GeoWebCache is the simplest method, as it comes bundled with GeoServer. (See the section on GeoWebCache for more details.) Another option is TileCache.

                      You can also use a more generic non-spatial caching system, such as OSCache (an embedded cache service) or Squid (a web cache proxy).

                      Caching is also possible for WFS layers, in a very limited fashion. For DataStores that don't have a quick way to determine feature counts (e.g. shapefiles), enabling caching can prevent querying a store twice during a single request. To enable caching, set the Java system property org.geoserver.wfs.getfeature.cachelimit to a positive integer. Any data sets that are smaller than the cache limit will be cached for the duration of a request, which will prevent the dataset from being queried a second time for the feature count. Note that this may adversely affect some types of DataStores, as it bypasses any feature count optimizations that may exist.

                      "},{"location":"production/config/#welcome-page-selectors","title":"Welcome page selectors","text":"

                      The workspace and layer selectors might take a lot of time to fill up against large catalogs. Because of this, GeoServer tries to limit the time taken to fill them (by default, 5 seconds), and the number of items in them (by default, 1000), and will fall back on simple text fields if the time limit is reached.

                      In some situations, that won't be enough and the page might get stuck anyways. The following properties can be used to tweak the behavior:

                      • GeoServerHomePage.selectionMode : can be set to text to always use simple text fields, dropdown to always use dropdowns, or auto to use the default automatic behavior.
                      • GeoServerHomePage.selectionTimeout : the time limit in milliseconds, defaults to 5000.
                      • GeoServerHomePage.selectionMaxItems : the maximum number of items to show in the dropdowns, defaults to 1000.

                      When using text selection mode the page description is static, no longer offering of available workspace and layers.

                      Welcome page text selection mode

                      "},{"location":"production/config/#disable-the-geoserver-web-administration-interface","title":"Disable the GeoServer web administration interface","text":"

                      In some circumstances, you might want to completely disable the web administration interface. There are two ways of doing this:

                      • Set the Java system property GEOSERVER_CONSOLE_DISABLED to true by adding -DGEOSERVER_CONSOLE_DISABLED=true to your container's JVM options
                      • Remove all of the gs-web*-.jar files from WEB-INF/lib
                      "},{"location":"production/config/#disable-the-auto-complete-on-web-administration-interface-login","title":"Disable the Auto-complete on web administration interface login","text":"

                      To disable the Auto Complete on Web Admin login form:

                      • Set the Java system property geoserver.login.autocomplete to off by adding -Dgeoserver.login.autocomplete=off to your container's JVM options
                      • If the browser has already cached the credentials, please consider clearing the cache or form data after setting the JVM option.
                      "},{"location":"production/config/#disable-anonymous-access-to-the-layer-preview-page","title":"Disable anonymous access to the layer preview page","text":"

                      In some circumstances, you might want to provide access to the layer preview page to authenticated users only. The solution is based on adding a new filter chain with a rule matching the path of the layer preview page to GeoServer's Authentication chain. Here are the steps to reproduce:

                      • Under Security -> Authentication -> Filter Chains, add a new HTML chain
                      • Set the new chain's name to webLayerPreview (or likewise)
                      • As Ant pattern, enter the path of the layer preview page, which is /web/wicket/bookmarkable/org.geoserver.web.demo.MapPreviewPage (since it's an Ant pattern, the path could as well be written shorter with wildcards: /web/**/org.geoserver.web.demo.MapPreviewPage)
                      • Check option Allow creation of an HTTP session for storing the authentication token
                      • Under Chain filters, add filters rememberme and form (in that order) to the Selected list on the right side
                      • Close the dialog by clicking the Close button; the new HTML chain has been added to the list of chains as the last entry
                      • Since all chains are processed in turn from top to bottom, in order to have any effect, the new webLayerPreview chain must be positioned before the web chain (which matches paths /web/**,/gwc/rest/web/**,/)
                      • Use the Position arrows on the left side of the list to move the newly added chain upwards accordingly
                      • Save the changes you've made by clicking the Save button at the bottom of the page

                      With that in place, unauthenticated users now just get forwarded to the login page when they click the layer preview menu item link.

                      The above procedure could as well be applied to other pages of the web administration interface that one needs to remove anonymous access for. For example:

                      • Demos -> Demo requests (path: /web/wicket/bookmarkable/org.geoserver.web.demo.DemoRequestsPage)
                      • Demos -> WCS request builder (path: /web/wicket/bookmarkable/org.geoserver.wcs.web.demo.WCSRequestBuilder)

                      Warning

                      Although disabling anonymous access to the layer preview page MAY prevent some unauthenticated users from accessing data with some simple clicks, this is NOT a security feature. In particular, since other more sophisticated users, having the ability to build OGC requests, MAY still access critical data through GeoServer's services, this is NOT a replacement for a well-designed security concept based on data-level or service-level security.

                      "},{"location":"production/config/#x-frame-options-policy","title":"X-Frame-Options Policy","text":"

                      In order to prevent clickjacking attacks GeoServer defaults to setting the X-Frame-Options HTTP header to SAMEORIGIN. This prevents GeoServer from being embedded into an iFrame, which prevents certain kinds of security vulnerabilities. See the OWASP Clickjacking entry for details.

                      If you wish to change this behavior you can do so through the following properties:

                      • geoserver.xframe.shouldSetPolicy: controls whether the X-Frame-Options filter should be set at all. Default is true.
                      • geoserver.xframe.policy: controls what the set the X-Frame-Options header to. Default is SAMEORIGIN valid options are DENY, SAMEORIGIN and ALLOW-FROM [uri]

                      These properties can be set either via Java system property, command line argument (-D), environment variable or web.xml init parameter.

                      "},{"location":"production/config/#x-content-type-options-policy","title":"X-Content-Type-Options Policy","text":"

                      In order to mitigate MIME confusion attacks (which often results in Cross-Site Scripting), GeoServer defaults to setting the X-Content-Type-Options: nosniff HTTP header. See the OWASP X-Content-Type-Options entry for details.

                      If you wish to change this behavior you can do so through the following property:

                      • geoserver.xContentType.shouldSetPolicy: controls whether the X-Content-Type-Options header should be set. Default is true.

                      This property can be set either via Java system property, command line argument (-D), environment variable or web.xml init parameter.

                      "},{"location":"production/config/#ows-serviceexception-xml-mimetype","title":"OWS ServiceException XML mimeType","text":"

                      By default, OWS Service Exception XML responses have content-type set to application/xml.

                      In case you want it set to text/xml instead, you need to setup the Java System properties:

                      • -Dows10.exception.xml.responsetype=text/xml for OWS 1.0.0 version
                      • -Dows11.exception.xml.responsetype=text/xml for OWS 1.1.0 version
                      "},{"location":"production/config/#production_config_freemarker_escaping","title":"FreeMarker Template Auto-escaping","text":"

                      By default, FreeMarker's built-in automatic escaping functionality will be enabled to mitigate potential cross-site scripting (XSS) vulnerabilities in cases where GeoServer uses FreeMarker templates to generate HTML output and administrators are able to modify the templates and/or users have significant control over the output through service requests. When the GEOSERVER_FORCE_FREEMARKER_ESCAPING property is set to false, auto-escaping will delegate either to the feature's default behavior or other settings which allow administrators to enable/disable auto-escaping on a global or per virtual service basis. This property can be set to false either via Java system property, command line argument (-D), environment variable or web.xml init parameter.

                      This setting currently applies to the WMS GetFeatureInfo HTML output format and may be applied to other applicable GeoServer functionality in the future.

                      Warning

                      While enabling auto-escaping will prevent XSS using the default templates and mitigate many cases where template authors are not considering XSS in their template design, it does NOT completely prevent template authors from creating templates that allow XSS (whether this is intentional or not). Additional functionality may be added in the future to mitigate those potential XSS vulnerabilities.

                      "},{"location":"production/config/#production_config_external_entities","title":"External Entities Resolution","text":"

                      When processing XML documents from service requests (POST requests, and GET requests with FILTER and SLD_BODY parameters) XML entity resolution is used to obtain any referenced documents. This is most commonly seen when the XML request provides the location of an XSD schema location for validation).

                      GeoServer provides a number of facilities to control external entity resolution:

                      • By default http and https entity resolution is unrestricted, with access to local file references prevented.

                      • To restrict http and https entity resolution:

                        -DENTITY_RESOLUTION_ALLOWLIST\n

                        The built-in allow list includes w3c, ogc, and inspire schema locations:

                        www.w3.org|schemas.opengis.net|www.opengis.net|inspire.ec.europa.eu/schemas\n

                        In addition the proxy base url is included, if available from global settings.

                        Access to local file references remains restricted.

                      • To allow additional external entity http and https locations use a comma or bar separated list:

                        -DENTITY_RESOLUTION_ALLOWLIST=server1|server2|server3/schemas\n
                      • To turn off all restrictions (allowing http, https, and file references) use the global setting Unrestricted XML External Entity Resolution.

                        This setting prevents ENTITY_RESOLUTION_ALLOWLIST from being used.

                      "},{"location":"production/config/#production_config_spring_firewall","title":"Spring Security Firewall","text":"

                      GeoServer defaults to using Spring Security's StrictHttpFirewall to help improve protection against potentially malicious requests. However, some users will need to disable the StrictHttpFirewall if the names of GeoServer resources (workspaces, layers, styles, etc.) in URL paths need to contain encoded percent, encoded period or decoded or encoded semicolon characters. The GEOSERVER_USE_STRICT_FIREWALL property can be set to false either via Java system property, command line argument (-D), environment variable or web.xml init parameter to use the more lenient DefaultHttpFirewall.

                      "},{"location":"production/config/#static-web-files","title":"Static Web Files","text":"

                      GeoServer by default allows administrators to serve static files by simply placing them in the www``` subdirectory of the GeoServer data directory. If this feature is not being used to serve HTML/JavaScript files or is not being used at all, the ````GEOSERVER_DISABLE_STATIC_WEB_FILES```` property can be set to true to mitigate potential stored XSS issues with that directory. See the \\Serving Static Files \\<../tutorials/staticfiles.rst>``_ page for more details.

                      "},{"location":"production/config/#session-management","title":"Session Management","text":"

                      GeoServer defaults to managing user sessions using cookies with the HttpOnly flag set to prevent attackers from using cross-site scripting (XSS) attacks to steal a user\\'s session token. You can configure the session behavior by modifying the `web.xml` file of your GeoServer instance.

                      It is strongly recommended that production environments also set the Secure flag on session cookies. This can be enabled by uncommenting the following in the `web.xml` file if the web interface is only being accessed through HTTPS but the flag may need to be set by a proxy server if the web interface needs to support both HTTP and HTTPS.

                      <secure>true</secure>\n
                      "},{"location":"production/container/","title":"Container Considerations","text":"

                      Java web containers such as Tomcat or Jetty ship with configurations that allow for fast startup, but don't always deliver the best performance.

                      "},{"location":"production/container/#optimize-your-jvm","title":"Optimize your JVM","text":"

                      Set the following performance settings in the Java virtual machine (JVM) for your container. These settings are not specific to any container.

                      Option Description

                      -Xms128m By starting with a larger heap GeoServer will not need to pause and ask the operating system for more memory during heavy load. The setting -Xms128m will tell the virtual machine to acquire grab a 128m heap memory on initial startup.

                      -Xmx756M Defines an upper limit on how much heap memory Java will request from the operating system (use more if you have excess memory). By default, the JVM will use \u00bc of available system memory. The setting -Xms756m allocates 756MB of memory to GeoServer.

                      -XX:SoftRefLRUPolicyMSPerMB=36000 Increases the lifetime of \"soft references\" in GeoServer. GeoServer uses soft references to cache datastore, spatial reference systems, and other data structures. By increasing this value to 36000 (which is 36 seconds) these values will stay in memory longer increasing the effectiveness of the cache.

                      -XX:+UseParallelGC This garbage collector pauses the application while using several threads to recover memory. Recommended if your GeoServer will be under light load and can tolerate pauses to clean up memory.

                      -XX:+UseParNewGC Enables use of the concurrent mark sweep (CMS) garbage collector uses multiple threads to recover memory while the application is running. Recommended for GeoServer under continuous use, with heap sizes of less than 6GB.

                      \u2013XX:+UseG1GC The default garbage collector since Java 9. Enables use of the Garbage First Garbage Collector (G1) using background threads to scan memory while the application is running prior to cleanup. Recommended for GeoServer under continuous load and heap sizes of 6GB or more. Additionally you may experiment with -XX:+UseStringDeduplicationJVM to ask G1 to better manage common text strings in memory.

                      For more information about JVM configuration, see the article Performance tuning garbage collection in Java and The 4 Java Garbage Collectors.

                      Note

                      You can only use one garbage collector at a time. Please refrain from combining garbage collectors at runtime.

                      Note

                      If you're serving just vector data, you'll be streaming, so having more memory won't increase performance. If you're serving coverages, however, image processing will use a tile cache and benefit from more memory. As an administrator you can configure the portion of memory available as a tile cache (see the Server Config page in the Web administration interface section) - for example to use 0.75 to allocate 75% of the heap as a tile cache.

                      Note

                      You can try out memory settings on the command line to check settings/defaults prior to use.

                      To check settings use java -Xms128m -Xmx756m -XX:+PrintFlagsFinal -version | grep HeapSize:

                      uintx InitialHeapSize   := 134217728     {product}\nuintx MaxHeapSize       := 792723456     {product}\n

                      Which when converted from bytes matches 128 MB initial heap size, and 756 MB max heap size.

                      Check defaults for your hardware using java -XX:+PrintFlagsFinal -version | grep HeapSize:

                      uintx InitialHeapSize   := 268435456     {product}\nuintx MaxHeapSize       := 4294967296    {product}\n

                      The above results (from a 16 GB laptop) amount to initial heap size of 256m, and a max heap size of around 4 GB (or around \u00bc of system memory).

                      "},{"location":"production/container/#production_container.marlin","title":"Use newer Marlin rasterizer","text":"

                      To use a newer version of Marlin than that provided by your JVM, add the following to the JVM startup options:

                      -Xbootclasspath/a:$MARLIN_JAR\n-Dsun.java2d.renderer=org.marlin.pisces.MarlinRenderingEngine\n

                      where $MARLIN_JAR is the location of the marlin*.jar file located in the geoserver/WEB-INF/lib directory or downloaded from the Marlin project.

                      The server status page shows which renderer is being used.

                      "},{"location":"production/container/#production_container.enable_cors","title":"Enable CORS","text":"

                      Enable Cross-Origin Resource Sharing (CORS) to allow JavaScript applications outside of your own domain, or web browsers, to use GeoServer.

                      "},{"location":"production/container/#enable-cors-for-tomcat","title":"Enable CORS for Tomcat","text":"

                      The web archive distribution of GeoServer is tested with Tomcat. Use the following steps to enable CORS for Tomcat, more information on what this does and other options see the Tomcat CORS Filter documentation.

                      1. Uncomment the following <filter> in webapps/geoserver/WEB-INF/web.xml:

                        <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<web-app \n        xmlns=\"http://xmlns.jcp.org/xml/ns/javaee\" \n        xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\"\n        xsi:schemaLocation=\"http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd\"\n        metadata-complete=\"false\"\n        version=\"3.1\">\n    <display-name>GeoServer</display-name>\n\n      <context-param>\n    <param-name>serviceStrategy</param-name>\n    <!-- Meaning of the different values :\n\n         PARTIAL-BUFFER2\n         - Partially buffers the first xKb to disk. Once that has buffered, the the \n           result is streamed to the user. This will allow for most errors to be caught\n           early. \n\n         BUFFER\n         - stores the entire response in memory first, before sending it off to\n           the user (may run out of memory)\n\n         SPEED\n         - outputs directly to the response (and cannot recover in the case of an\n           error)\n\n         FILE\n         - outputs to the local filesystem first, before sending it off to the user\n      -->\n    <param-value>PARTIAL-BUFFER2</param-value>\n  </context-param>\n\n  <context-param>\n    <!-- see comments on the PARTIAL-BUFFER strategy -->\n    <!-- this sets the size of the buffer.  default is \"50\" = 50kb -->\n\n    <param-name>PARTIAL_BUFFER_STRATEGY_SIZE</param-name>\n    <param-value>50</param-value>\n  </context-param>\n\n  <!--Can be true or false (defaults to: false). -->\n  <!--When true the JSONP (text/javascript) output format is enabled -->\n  <!--\n  <context-param>\n    <param-name>ENABLE_JSONP</param-name>\n    <param-value>true</param-value>\n  </context-param>\n  -->\n    <!-- \n    <context-param>\n      <param-name>PROXY_BASE_URL</param-name>\n      <param-value>http://82.58.146.45/geoserver</param-value>\n    </context-param>\n     -->\n\n     <!--\n    <context-param>\n       <param-name>GEOSERVER_DATA_DIR</param-name>\n        <param-value>C:\\eclipse\\workspace\\geoserver_trunk\\cite\\confCiteWFSPostGIS</param-value>\n    </context-param> \n   -->\n\n    <!-- pick up all spring application contexts -->\n    <context-param>\n        <param-name>contextConfigLocation</param-name>\n        <param-value>classpath*:/applicationContext.xml classpath*:/applicationSecurityContext.xml</param-value>\n    </context-param>\n\n    <filter>\n     <filter-name>FlushSafeFilter</filter-name>\n     <filter-class>org.geoserver.filters.FlushSafeFilter</filter-class>\n    </filter>\n\n    <filter>\n      <filter-name>Set Character Encoding</filter-name>\n      <filter-class>org.springframework.web.filter.CharacterEncodingFilter</filter-class>\n      <init-param>\n        <param-name>encoding</param-name>\n        <param-value>UTF-8</param-value>\n      </init-param>\n    </filter>\n\n    <filter>\n     <filter-name>SessionDebugger</filter-name>\n     <filter-class>org.geoserver.filters.SessionDebugFilter</filter-class>\n    </filter>\n\n    <filter>\n    <filter-name>filterChainProxy</filter-name>     \n     <filter-class> org.springframework.web.filter.DelegatingFilterProxy</filter-class>\n    </filter>\n\n    <filter>\n      <filter-name>xFrameOptionsFilter</filter-name>\n      <filter-class>org.geoserver.filters.XFrameOptionsFilter</filter-class>\n    </filter>\n\n   <filter>\n     <filter-name>GZIP Compression Filter</filter-name>\n     <filter-class>org.geoserver.filters.GZIPFilter</filter-class>\n     <init-param>\n         <!-- The compressed-types parameter is a comma-separated list of regular expressions.\n              If a mime type matches any of the regular expressions then it will be compressed.\n              -->\n         <param-name>compressed-types</param-name>\n         <param-value>text/.*,.*xml.*,application/json,application/x-javascript</param-value>\n     </init-param>\n   </filter>\n\n   <filter>\n     <filter-name>Advanced Dispatch Filter</filter-name>\n     <filter-class>org.geoserver.platform.AdvancedDispatchFilter</filter-class>\n     <!-- \n     This filter allows for a single mapping to the spring dispatcher. However using /* as a mapping\n     in a servlet mapping causes the servlet path to be \"/\" of the request. This causes problems with\n     library like wicket and restlet. So this filter fakes the servlet path by assuming the first \n     component of the path is the mapped path. \n     -->\n   </filter>\n\n   <filter>\n    <filter-name>Spring Delegating Filter</filter-name>\n    <filter-class>org.geoserver.filters.SpringDelegatingFilter</filter-class>\n    <!--\n    This filter allows for filters to be loaded via spring rather than \n    registered here in web.xml.  One thing to note is that for such filters \n    init() is not called. INstead any initialization is performed via spring \n    ioc.\n    -->\n   </filter>\n\n   <filter>\n     <filter-name>Thread locals cleanup filter</filter-name>\n     <filter-class>org.geoserver.filters.ThreadLocalsCleanupFilter</filter-class>\n     <!-- \n     This filter cleans up thread locals Geotools is setting up for concurrency and performance\n     reasons \n     -->\n   </filter>\n\n   <!-- Uncomment following filter to enable CORS in Jetty. Do not forget the second config block further down.\n    <filter>\n      <filter-name>cross-origin</filter-name>\n      <filter-class>org.eclipse.jetty.servlets.CrossOriginFilter</filter-class>\n      <init-param>\n        <param-name>chainPreflight</param-name>\n        <param-value>false</param-value>\n      </init-param>\n      <init-param>\n        <param-name>allowedOrigins</param-name>\n        <param-value>*</param-value>\n      </init-param>\n      <init-param>\n        <param-name>allowedMethods</param-name>\n        <param-value>GET,POST,PUT,DELETE,HEAD,OPTIONS</param-value>\n      </init-param>\n      <init-param>\n        <param-name>allowedHeaders</param-name>\n        <param-value>*</param-value>\n      </init-param>\n    </filter>\n    -->\n\n   <!-- Uncomment following filter to enable CORS in Tomcat. Do not forget the second config block further down.\n    <filter>\n      <filter-name>cross-origin</filter-name>\n      <filter-class>org.apache.catalina.filters.CorsFilter</filter-class>\n      <init-param>\n        <param-name>cors.allowed.origins</param-name>\n        <param-value>*</param-value>\n      </init-param>\n      <init-param>\n        <param-name>cors.allowed.methods</param-name>\n        <param-value>GET,POST,PUT,DELETE,HEAD,OPTIONS</param-value>\n      </init-param>\n      <init-param>\n        <param-name>cors.allowed.headers</param-name>\n        <param-value>*</param-value>\n      </init-param>\n    </filter>\n    -->\n\n    <!-- \n      THIS FILTER MAPPING MUST BE THE FIRST ONE, otherwise we end up with ruined chars in the input from the GUI\n      See the \"Note\" in the Tomcat character encoding guide:\n      http://wiki.apache.org/tomcat/FAQ/CharacterEncoding\n    -->\n    <filter-mapping>\n      <filter-name>Set Character Encoding</filter-name>\n      <url-pattern>/*</url-pattern>\n    </filter-mapping>\n\n    <!-- Uncomment following filter-mapping to enable CORS\n    <filter-mapping>\n        <filter-name>cross-origin</filter-name>\n        <url-pattern>/*</url-pattern>\n    </filter-mapping>\n    -->\n\n    <filter-mapping>\n      <filter-name>FlushSafeFilter</filter-name>\n      <url-pattern>/*</url-pattern>\n    </filter-mapping>\n\n    <filter-mapping>\n      <filter-name>SessionDebugger</filter-name>\n      <url-pattern>/*</url-pattern>\n    </filter-mapping>\n\n    <filter-mapping>\n      <filter-name>GZIP Compression Filter</filter-name>\n      <url-pattern>/*</url-pattern>\n    </filter-mapping>\n\n    <filter-mapping>\n      <filter-name>xFrameOptionsFilter</filter-name>\n      <url-pattern>/*</url-pattern>\n    </filter-mapping>\n\n    <!-- \n      If you want to use your security system comment out this one too\n    -->\n    <filter-mapping>\n      <filter-name>filterChainProxy</filter-name>\n      <url-pattern>/*</url-pattern>\n    </filter-mapping>\n\n    <filter-mapping>\n      <filter-name>Advanced Dispatch Filter</filter-name>\n      <url-pattern>/*</url-pattern>\n    </filter-mapping>\n\n    <filter-mapping>\n      <filter-name>Spring Delegating Filter</filter-name>\n      <url-pattern>/*</url-pattern>\n    </filter-mapping>\n\n    <filter-mapping>\n      <filter-name>Thread locals cleanup filter</filter-name>\n      <url-pattern>/*</url-pattern>\n    </filter-mapping>\n\n    <!-- general initializer, should be first thing to execute -->\n    <listener>\n      <listener-class>org.geoserver.GeoserverInitStartupListener</listener-class>\n    </listener>\n\n    <!-- logging initializer, should execute before spring context startup -->\n    <listener>\n      <listener-class>org.geoserver.logging.LoggingStartupContextListener</listener-class>\n    </listener>\n\n    <!--  spring context loader -->\n    <listener>\n      <listener-class>org.geoserver.platform.GeoServerContextLoaderListener</listener-class>\n    </listener>\n\n    <!--  http session listener proxy -->\n    <listener>\n      <listener-class>org.geoserver.platform.GeoServerHttpSessionListenerProxy</listener-class>\n    </listener>\n\n    <!-- request context listener for session-scoped beans -->\n    <listener>\n        <listener-class>org.springframework.web.context.request.RequestContextListener</listener-class>\n    </listener>\n\n    <!-- spring dispatcher servlet, dispatches all incoming requests -->\n    <servlet>\n      <servlet-name>dispatcher</servlet-name>\n      <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>\n    </servlet>\n\n    <!-- single mapping to spring, this only works properly if the advanced dispatch filter is \n         active -->\n    <servlet-mapping>\n        <servlet-name>dispatcher</servlet-name>\n        <url-pattern>/*</url-pattern>\n    </servlet-mapping>\n\n    <session-config>\n        <cookie-config>\n            <http-only>true</http-only>\n            <!-- The Secure flag should be set on session cookies but is commented out by default since it -->\n            <!-- will break non-HTTPS web UI access and may cause problems with some proxy configurations. -->\n            <!-- Uncomment the following line to add the Secure flag to session cookies. -->\n            <!-- <secure>true</secure> -->\n        </cookie-config>\n        <tracking-mode>COOKIE</tracking-mode>\n    </session-config>\n\n    <mime-mapping>\n      <extension>xsl</extension>\n      <mime-type>text/xml</mime-type>\n    </mime-mapping>\n    <mime-mapping>\n      <extension>sld</extension>\n      <mime-type>text/xml</mime-type>\n    </mime-mapping>\n    <mime-mapping>\n      <extension>json</extension>\n      <mime-type>application/json</mime-type>\n    </mime-mapping>\n    <mime-mapping>\n      <extension>yaml</extension>\n      <mime-type>text/plain</mime-type>\n    </mime-mapping>\n\n    <welcome-file-list>\n        <welcome-file>index.html</welcome-file>\n    </welcome-file-list>\n\n</web-app>\n
                      2. Uncomment the following <filter-mapping>:

                            <filter-mapping>\n        <filter-name>cross-origin</filter-name>\n        <url-pattern>/*</url-pattern>\n    </filter-mapping>\n\n    <filter-mapping>\n      <filter-name>filterChainProxy</filter-name>\n      <url-pattern>/*</url-pattern>\n    </filter-mapping>\n\n    <filter-mapping>\n      <filter-name>Advanced Dispatch Filter</filter-name>\n      <url-pattern>/*</url-pattern>\n    </filter-mapping>\n\n    <filter-mapping>\n      <filter-name>Spring Delegating Filter</filter-name>\n      <url-pattern>/*</url-pattern>\n    </filter-mapping>\n\n    <filter-mapping>\n      <filter-name>Thread locals cleanup filter</filter-name>\n      <url-pattern>/*</url-pattern>\n    </filter-mapping>\n\n    <!-- general initializer, should be first thing to execute \n    <listener>\n      <listener-class>org.geoserver.logging.LoggingStartupContextListener</listener-class>\n    </listener>\n\n    <!--  spring context loader \n    <listener>\n      <listener-class>org.geoserver.platform.GeoServerHttpSessionListenerProxy</listener-class>\n    </listener>\n\n    <!-- request context listener for session-scoped beans \n    <servlet>\n      <servlet-name>dispatcher</servlet-name>\n      <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>\n    </servlet>\n\n    <!-- single mapping to spring, this only works properly if the advanced dispatch filter is \n         active \n            <!-- will break non-HTTPS web UI access and may cause problems with some proxy configurations. \n            <!-- <secure>true</secure> \n
                      3. Restart

                      "},{"location":"production/container/#enable-cors-for-jetty-binary-installer","title":"Enable CORS for Jetty / binary installer","text":"

                      The standalone distributions of GeoServer include the Jetty application server. Use the following steps to enable CORS for Jetty, for more information on what this does and other options see the Jetty Cross Origin Filter documentation

                      1. Uncomment the following <filter> in webapps/geoserver/WEB-INF/web.xml:

                        <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<web-app \n        xmlns=\"http://xmlns.jcp.org/xml/ns/javaee\" \n        xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\"\n        xsi:schemaLocation=\"http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd\"\n        metadata-complete=\"false\"\n        version=\"3.1\">\n    <display-name>GeoServer</display-name>\n\n      <context-param>\n    <param-name>serviceStrategy</param-name>\n    <!-- Meaning of the different values :\n\n         PARTIAL-BUFFER2\n         - Partially buffers the first xKb to disk. Once that has buffered, the the \n           result is streamed to the user. This will allow for most errors to be caught\n           early. \n\n         BUFFER\n         - stores the entire response in memory first, before sending it off to\n           the user (may run out of memory)\n\n         SPEED\n         - outputs directly to the response (and cannot recover in the case of an\n           error)\n\n         FILE\n         - outputs to the local filesystem first, before sending it off to the user\n      -->\n    <param-value>PARTIAL-BUFFER2</param-value>\n  </context-param>\n\n  <context-param>\n    <!-- see comments on the PARTIAL-BUFFER strategy -->\n    <!-- this sets the size of the buffer.  default is \"50\" = 50kb -->\n\n    <param-name>PARTIAL_BUFFER_STRATEGY_SIZE</param-name>\n    <param-value>50</param-value>\n  </context-param>\n\n  <!--Can be true or false (defaults to: false). -->\n  <!--When true the JSONP (text/javascript) output format is enabled -->\n  <!--\n  <context-param>\n    <param-name>ENABLE_JSONP</param-name>\n    <param-value>true</param-value>\n  </context-param>\n  -->\n    <!-- \n    <context-param>\n      <param-name>PROXY_BASE_URL</param-name>\n      <param-value>http://82.58.146.45/geoserver</param-value>\n    </context-param>\n     -->\n\n     <!--\n    <context-param>\n       <param-name>GEOSERVER_DATA_DIR</param-name>\n        <param-value>C:\\eclipse\\workspace\\geoserver_trunk\\cite\\confCiteWFSPostGIS</param-value>\n    </context-param> \n   -->\n\n    <!-- pick up all spring application contexts -->\n    <context-param>\n        <param-name>contextConfigLocation</param-name>\n        <param-value>classpath*:/applicationContext.xml classpath*:/applicationSecurityContext.xml</param-value>\n    </context-param>\n\n    <filter>\n     <filter-name>FlushSafeFilter</filter-name>\n     <filter-class>org.geoserver.filters.FlushSafeFilter</filter-class>\n    </filter>\n\n    <filter>\n      <filter-name>Set Character Encoding</filter-name>\n      <filter-class>org.springframework.web.filter.CharacterEncodingFilter</filter-class>\n      <init-param>\n        <param-name>encoding</param-name>\n        <param-value>UTF-8</param-value>\n      </init-param>\n    </filter>\n\n    <filter>\n     <filter-name>SessionDebugger</filter-name>\n     <filter-class>org.geoserver.filters.SessionDebugFilter</filter-class>\n    </filter>\n\n    <filter>\n    <filter-name>filterChainProxy</filter-name>     \n     <filter-class> org.springframework.web.filter.DelegatingFilterProxy</filter-class>\n    </filter>\n\n    <filter>\n      <filter-name>xFrameOptionsFilter</filter-name>\n      <filter-class>org.geoserver.filters.XFrameOptionsFilter</filter-class>\n    </filter>\n\n   <filter>\n     <filter-name>GZIP Compression Filter</filter-name>\n     <filter-class>org.geoserver.filters.GZIPFilter</filter-class>\n     <init-param>\n         <!-- The compressed-types parameter is a comma-separated list of regular expressions.\n              If a mime type matches any of the regular expressions then it will be compressed.\n              -->\n         <param-name>compressed-types</param-name>\n         <param-value>text/.*,.*xml.*,application/json,application/x-javascript</param-value>\n     </init-param>\n   </filter>\n\n   <filter>\n     <filter-name>Advanced Dispatch Filter</filter-name>\n     <filter-class>org.geoserver.platform.AdvancedDispatchFilter</filter-class>\n     <!-- \n     This filter allows for a single mapping to the spring dispatcher. However using /* as a mapping\n     in a servlet mapping causes the servlet path to be \"/\" of the request. This causes problems with\n     library like wicket and restlet. So this filter fakes the servlet path by assuming the first \n     component of the path is the mapped path. \n     -->\n   </filter>\n\n   <filter>\n    <filter-name>Spring Delegating Filter</filter-name>\n    <filter-class>org.geoserver.filters.SpringDelegatingFilter</filter-class>\n    <!--\n    This filter allows for filters to be loaded via spring rather than \n    registered here in web.xml.  One thing to note is that for such filters \n    init() is not called. INstead any initialization is performed via spring \n    ioc.\n    -->\n   </filter>\n\n   <filter>\n     <filter-name>Thread locals cleanup filter</filter-name>\n     <filter-class>org.geoserver.filters.ThreadLocalsCleanupFilter</filter-class>\n     <!-- \n     This filter cleans up thread locals Geotools is setting up for concurrency and performance\n     reasons \n     -->\n   </filter>\n\n   <!-- Uncomment following filter to enable CORS in Jetty. Do not forget the second config block further down.\n    <filter>\n      <filter-name>cross-origin</filter-name>\n      <filter-class>org.eclipse.jetty.servlets.CrossOriginFilter</filter-class>\n      <init-param>\n        <param-name>chainPreflight</param-name>\n        <param-value>false</param-value>\n      </init-param>\n      <init-param>\n        <param-name>allowedOrigins</param-name>\n        <param-value>*</param-value>\n      </init-param>\n      <init-param>\n        <param-name>allowedMethods</param-name>\n        <param-value>GET,POST,PUT,DELETE,HEAD,OPTIONS</param-value>\n      </init-param>\n      <init-param>\n        <param-name>allowedHeaders</param-name>\n        <param-value>*</param-value>\n      </init-param>\n    </filter>\n    -->\n\n   <!-- Uncomment following filter to enable CORS in Tomcat. Do not forget the second config block further down.\n    <filter>\n      <filter-name>cross-origin</filter-name>\n      <filter-class>org.apache.catalina.filters.CorsFilter</filter-class>\n      <init-param>\n        <param-name>cors.allowed.origins</param-name>\n        <param-value>*</param-value>\n      </init-param>\n      <init-param>\n        <param-name>cors.allowed.methods</param-name>\n        <param-value>GET,POST,PUT,DELETE,HEAD,OPTIONS</param-value>\n      </init-param>\n      <init-param>\n        <param-name>cors.allowed.headers</param-name>\n        <param-value>*</param-value>\n      </init-param>\n    </filter>\n    -->\n\n    <!-- \n      THIS FILTER MAPPING MUST BE THE FIRST ONE, otherwise we end up with ruined chars in the input from the GUI\n      See the \"Note\" in the Tomcat character encoding guide:\n      http://wiki.apache.org/tomcat/FAQ/CharacterEncoding\n    -->\n    <filter-mapping>\n      <filter-name>Set Character Encoding</filter-name>\n      <url-pattern>/*</url-pattern>\n    </filter-mapping>\n\n    <!-- Uncomment following filter-mapping to enable CORS\n    <filter-mapping>\n        <filter-name>cross-origin</filter-name>\n        <url-pattern>/*</url-pattern>\n    </filter-mapping>\n    -->\n\n    <filter-mapping>\n      <filter-name>FlushSafeFilter</filter-name>\n      <url-pattern>/*</url-pattern>\n    </filter-mapping>\n\n    <filter-mapping>\n      <filter-name>SessionDebugger</filter-name>\n      <url-pattern>/*</url-pattern>\n    </filter-mapping>\n\n    <filter-mapping>\n      <filter-name>GZIP Compression Filter</filter-name>\n      <url-pattern>/*</url-pattern>\n    </filter-mapping>\n\n    <filter-mapping>\n      <filter-name>xFrameOptionsFilter</filter-name>\n      <url-pattern>/*</url-pattern>\n    </filter-mapping>\n\n    <!-- \n      If you want to use your security system comment out this one too\n    -->\n    <filter-mapping>\n      <filter-name>filterChainProxy</filter-name>\n      <url-pattern>/*</url-pattern>\n    </filter-mapping>\n\n    <filter-mapping>\n      <filter-name>Advanced Dispatch Filter</filter-name>\n      <url-pattern>/*</url-pattern>\n    </filter-mapping>\n\n    <filter-mapping>\n      <filter-name>Spring Delegating Filter</filter-name>\n      <url-pattern>/*</url-pattern>\n    </filter-mapping>\n\n    <filter-mapping>\n      <filter-name>Thread locals cleanup filter</filter-name>\n      <url-pattern>/*</url-pattern>\n    </filter-mapping>\n\n    <!-- general initializer, should be first thing to execute -->\n    <listener>\n      <listener-class>org.geoserver.GeoserverInitStartupListener</listener-class>\n    </listener>\n\n    <!-- logging initializer, should execute before spring context startup -->\n    <listener>\n      <listener-class>org.geoserver.logging.LoggingStartupContextListener</listener-class>\n    </listener>\n\n    <!--  spring context loader -->\n    <listener>\n      <listener-class>org.geoserver.platform.GeoServerContextLoaderListener</listener-class>\n    </listener>\n\n    <!--  http session listener proxy -->\n    <listener>\n      <listener-class>org.geoserver.platform.GeoServerHttpSessionListenerProxy</listener-class>\n    </listener>\n\n    <!-- request context listener for session-scoped beans -->\n    <listener>\n        <listener-class>org.springframework.web.context.request.RequestContextListener</listener-class>\n    </listener>\n\n    <!-- spring dispatcher servlet, dispatches all incoming requests -->\n    <servlet>\n      <servlet-name>dispatcher</servlet-name>\n      <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>\n    </servlet>\n\n    <!-- single mapping to spring, this only works properly if the advanced dispatch filter is \n         active -->\n    <servlet-mapping>\n        <servlet-name>dispatcher</servlet-name>\n        <url-pattern>/*</url-pattern>\n    </servlet-mapping>\n\n    <session-config>\n        <cookie-config>\n            <http-only>true</http-only>\n            <!-- The Secure flag should be set on session cookies but is commented out by default since it -->\n            <!-- will break non-HTTPS web UI access and may cause problems with some proxy configurations. -->\n            <!-- Uncomment the following line to add the Secure flag to session cookies. -->\n            <!-- <secure>true</secure> -->\n        </cookie-config>\n        <tracking-mode>COOKIE</tracking-mode>\n    </session-config>\n\n    <mime-mapping>\n      <extension>xsl</extension>\n      <mime-type>text/xml</mime-type>\n    </mime-mapping>\n    <mime-mapping>\n      <extension>sld</extension>\n      <mime-type>text/xml</mime-type>\n    </mime-mapping>\n    <mime-mapping>\n      <extension>json</extension>\n      <mime-type>application/json</mime-type>\n    </mime-mapping>\n    <mime-mapping>\n      <extension>yaml</extension>\n      <mime-type>text/plain</mime-type>\n    </mime-mapping>\n\n    <welcome-file-list>\n        <welcome-file>index.html</welcome-file>\n    </welcome-file-list>\n\n</web-app>\n
                      2. Uncomment the following <filter-mapping>:

                        <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<web-app \n        xmlns=\"http://xmlns.jcp.org/xml/ns/javaee\" \n        xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\"\n        xsi:schemaLocation=\"http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd\"\n        metadata-complete=\"false\"\n        version=\"3.1\">\n    <display-name>GeoServer</display-name>\n\n      <context-param>\n    <param-name>serviceStrategy</param-name>\n    <!-- Meaning of the different values :\n\n         PARTIAL-BUFFER2\n         - Partially buffers the first xKb to disk. Once that has buffered, the the \n           result is streamed to the user. This will allow for most errors to be caught\n           early. \n\n         BUFFER\n         - stores the entire response in memory first, before sending it off to\n           the user (may run out of memory)\n\n         SPEED\n         - outputs directly to the response (and cannot recover in the case of an\n           error)\n\n         FILE\n         - outputs to the local filesystem first, before sending it off to the user\n      -->\n    <param-value>PARTIAL-BUFFER2</param-value>\n  </context-param>\n\n  <context-param>\n    <!-- see comments on the PARTIAL-BUFFER strategy -->\n    <!-- this sets the size of the buffer.  default is \"50\" = 50kb -->\n\n    <param-name>PARTIAL_BUFFER_STRATEGY_SIZE</param-name>\n    <param-value>50</param-value>\n  </context-param>\n\n  <!--Can be true or false (defaults to: false). -->\n  <!--When true the JSONP (text/javascript) output format is enabled -->\n  <!--\n  <context-param>\n    <param-name>ENABLE_JSONP</param-name>\n    <param-value>true</param-value>\n  </context-param>\n  -->\n    <!-- \n    <context-param>\n      <param-name>PROXY_BASE_URL</param-name>\n      <param-value>http://82.58.146.45/geoserver</param-value>\n    </context-param>\n     -->\n\n     <!--\n    <context-param>\n       <param-name>GEOSERVER_DATA_DIR</param-name>\n        <param-value>C:\\eclipse\\workspace\\geoserver_trunk\\cite\\confCiteWFSPostGIS</param-value>\n    </context-param> \n   -->\n\n    <!-- pick up all spring application contexts -->\n    <context-param>\n        <param-name>contextConfigLocation</param-name>\n        <param-value>classpath*:/applicationContext.xml classpath*:/applicationSecurityContext.xml</param-value>\n    </context-param>\n\n    <filter>\n     <filter-name>FlushSafeFilter</filter-name>\n     <filter-class>org.geoserver.filters.FlushSafeFilter</filter-class>\n    </filter>\n\n    <filter>\n      <filter-name>Set Character Encoding</filter-name>\n      <filter-class>org.springframework.web.filter.CharacterEncodingFilter</filter-class>\n      <init-param>\n        <param-name>encoding</param-name>\n        <param-value>UTF-8</param-value>\n      </init-param>\n    </filter>\n\n    <filter>\n     <filter-name>SessionDebugger</filter-name>\n     <filter-class>org.geoserver.filters.SessionDebugFilter</filter-class>\n    </filter>\n\n    <filter>\n    <filter-name>filterChainProxy</filter-name>     \n     <filter-class> org.springframework.web.filter.DelegatingFilterProxy</filter-class>\n    </filter>\n\n    <filter>\n      <filter-name>xFrameOptionsFilter</filter-name>\n      <filter-class>org.geoserver.filters.XFrameOptionsFilter</filter-class>\n    </filter>\n\n   <filter>\n     <filter-name>GZIP Compression Filter</filter-name>\n     <filter-class>org.geoserver.filters.GZIPFilter</filter-class>\n     <init-param>\n         <!-- The compressed-types parameter is a comma-separated list of regular expressions.\n              If a mime type matches any of the regular expressions then it will be compressed.\n              -->\n         <param-name>compressed-types</param-name>\n         <param-value>text/.*,.*xml.*,application/json,application/x-javascript</param-value>\n     </init-param>\n   </filter>\n\n   <filter>\n     <filter-name>Advanced Dispatch Filter</filter-name>\n     <filter-class>org.geoserver.platform.AdvancedDispatchFilter</filter-class>\n     <!-- \n     This filter allows for a single mapping to the spring dispatcher. However using /* as a mapping\n     in a servlet mapping causes the servlet path to be \"/\" of the request. This causes problems with\n     library like wicket and restlet. So this filter fakes the servlet path by assuming the first \n     component of the path is the mapped path. \n     -->\n   </filter>\n\n   <filter>\n    <filter-name>Spring Delegating Filter</filter-name>\n    <filter-class>org.geoserver.filters.SpringDelegatingFilter</filter-class>\n    <!--\n    This filter allows for filters to be loaded via spring rather than \n    registered here in web.xml.  One thing to note is that for such filters \n    init() is not called. INstead any initialization is performed via spring \n    ioc.\n    -->\n   </filter>\n\n   <filter>\n     <filter-name>Thread locals cleanup filter</filter-name>\n     <filter-class>org.geoserver.filters.ThreadLocalsCleanupFilter</filter-class>\n     <!-- \n     This filter cleans up thread locals Geotools is setting up for concurrency and performance\n     reasons \n     -->\n   </filter>\n\n   <!-- Uncomment following filter to enable CORS in Jetty. Do not forget the second config block further down.\n    <filter>\n      <filter-name>cross-origin</filter-name>\n      <filter-class>org.eclipse.jetty.servlets.CrossOriginFilter</filter-class>\n      <init-param>\n        <param-name>chainPreflight</param-name>\n        <param-value>false</param-value>\n      </init-param>\n      <init-param>\n        <param-name>allowedOrigins</param-name>\n        <param-value>*</param-value>\n      </init-param>\n      <init-param>\n        <param-name>allowedMethods</param-name>\n        <param-value>GET,POST,PUT,DELETE,HEAD,OPTIONS</param-value>\n      </init-param>\n      <init-param>\n        <param-name>allowedHeaders</param-name>\n        <param-value>*</param-value>\n      </init-param>\n    </filter>\n    -->\n\n   <!-- Uncomment following filter to enable CORS in Tomcat. Do not forget the second config block further down.\n    <filter>\n      <filter-name>cross-origin</filter-name>\n      <filter-class>org.apache.catalina.filters.CorsFilter</filter-class>\n      <init-param>\n        <param-name>cors.allowed.origins</param-name>\n        <param-value>*</param-value>\n      </init-param>\n      <init-param>\n        <param-name>cors.allowed.methods</param-name>\n        <param-value>GET,POST,PUT,DELETE,HEAD,OPTIONS</param-value>\n      </init-param>\n      <init-param>\n        <param-name>cors.allowed.headers</param-name>\n        <param-value>*</param-value>\n      </init-param>\n    </filter>\n    -->\n\n    <!-- \n      THIS FILTER MAPPING MUST BE THE FIRST ONE, otherwise we end up with ruined chars in the input from the GUI\n      See the \"Note\" in the Tomcat character encoding guide:\n      http://wiki.apache.org/tomcat/FAQ/CharacterEncoding\n    -->\n    <filter-mapping>\n      <filter-name>Set Character Encoding</filter-name>\n      <url-pattern>/*</url-pattern>\n    </filter-mapping>\n\n    <!-- Uncomment following filter-mapping to enable CORS\n    <filter-mapping>\n        <filter-name>cross-origin</filter-name>\n        <url-pattern>/*</url-pattern>\n    </filter-mapping>\n    -->\n\n    <filter-mapping>\n      <filter-name>FlushSafeFilter</filter-name>\n      <url-pattern>/*</url-pattern>\n    </filter-mapping>\n\n    <filter-mapping>\n      <filter-name>SessionDebugger</filter-name>\n      <url-pattern>/*</url-pattern>\n    </filter-mapping>\n\n    <filter-mapping>\n      <filter-name>GZIP Compression Filter</filter-name>\n      <url-pattern>/*</url-pattern>\n    </filter-mapping>\n\n    <filter-mapping>\n      <filter-name>xFrameOptionsFilter</filter-name>\n      <url-pattern>/*</url-pattern>\n    </filter-mapping>\n\n    <!-- \n      If you want to use your security system comment out this one too\n    -->\n    <filter-mapping>\n      <filter-name>filterChainProxy</filter-name>\n      <url-pattern>/*</url-pattern>\n    </filter-mapping>\n\n    <filter-mapping>\n      <filter-name>Advanced Dispatch Filter</filter-name>\n      <url-pattern>/*</url-pattern>\n    </filter-mapping>\n\n    <filter-mapping>\n      <filter-name>Spring Delegating Filter</filter-name>\n      <url-pattern>/*</url-pattern>\n    </filter-mapping>\n\n    <filter-mapping>\n      <filter-name>Thread locals cleanup filter</filter-name>\n      <url-pattern>/*</url-pattern>\n    </filter-mapping>\n\n    <!-- general initializer, should be first thing to execute -->\n    <listener>\n      <listener-class>org.geoserver.GeoserverInitStartupListener</listener-class>\n    </listener>\n\n    <!-- logging initializer, should execute before spring context startup -->\n    <listener>\n      <listener-class>org.geoserver.logging.LoggingStartupContextListener</listener-class>\n    </listener>\n\n    <!--  spring context loader -->\n    <listener>\n      <listener-class>org.geoserver.platform.GeoServerContextLoaderListener</listener-class>\n    </listener>\n\n    <!--  http session listener proxy -->\n    <listener>\n      <listener-class>org.geoserver.platform.GeoServerHttpSessionListenerProxy</listener-class>\n    </listener>\n\n    <!-- request context listener for session-scoped beans -->\n    <listener>\n        <listener-class>org.springframework.web.context.request.RequestContextListener</listener-class>\n    </listener>\n\n    <!-- spring dispatcher servlet, dispatches all incoming requests -->\n    <servlet>\n      <servlet-name>dispatcher</servlet-name>\n      <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>\n    </servlet>\n\n    <!-- single mapping to spring, this only works properly if the advanced dispatch filter is \n         active -->\n    <servlet-mapping>\n        <servlet-name>dispatcher</servlet-name>\n        <url-pattern>/*</url-pattern>\n    </servlet-mapping>\n\n    <session-config>\n        <cookie-config>\n            <http-only>true</http-only>\n            <!-- The Secure flag should be set on session cookies but is commented out by default since it -->\n            <!-- will break non-HTTPS web UI access and may cause problems with some proxy configurations. -->\n            <!-- Uncomment the following line to add the Secure flag to session cookies. -->\n            <!-- <secure>true</secure> -->\n        </cookie-config>\n        <tracking-mode>COOKIE</tracking-mode>\n    </session-config>\n\n    <mime-mapping>\n      <extension>xsl</extension>\n      <mime-type>text/xml</mime-type>\n    </mime-mapping>\n    <mime-mapping>\n      <extension>sld</extension>\n      <mime-type>text/xml</mime-type>\n    </mime-mapping>\n    <mime-mapping>\n      <extension>json</extension>\n      <mime-type>application/json</mime-type>\n    </mime-mapping>\n    <mime-mapping>\n      <extension>yaml</extension>\n      <mime-type>text/plain</mime-type>\n    </mime-mapping>\n\n    <welcome-file-list>\n        <welcome-file>index.html</welcome-file>\n    </welcome-file-list>\n\n</web-app>\n
                      3. Restart

                      "},{"location":"production/data/","title":"Data Considerations","text":""},{"location":"production/data/#use-an-external-data-directory","title":"Use an external data directory","text":"

                      GeoServer comes with a built-in data directory. However, it is a good idea to separate the data from the application. Using an external data directory allows for much easier upgrades, since there is no risk of configuration information being overwritten. An external data directory also makes it easy to transfer your configuration elsewhere if desired. To point to an external data directory, you only need to edit the web.xml file. If you are new to GeoServer, you can copy (or just move) the data directory that comes with GeoServer to another location.

                      "},{"location":"production/data/#use-a-spatial-database","title":"Use a spatial database","text":"

                      Shapefiles are a very common format for geospatial data. But if you are running GeoServer in a production environment, it is better to use a spatial database such as PostGIS. This is essential if doing transactions (WFS-T). Most spatial databases provide shapefile conversion tools. Although there are many options for spatial databases (see the section on Databases), PostGIS is recommended. Oracle, and DB2 are also supported.

                      "},{"location":"production/data/#pick-the-best-performing-coverage-formats","title":"Pick the best performing coverage formats","text":"

                      There are very significant differences between performance of the various coverage formats.

                      Serving big coverage data sets with good performance requires some knowledge and tuning, since usually data is set up for distribution and archival. The following tips try to provide you with a base knowledge of how data restructuring affects performance, and how to use the available tools to get optimal data serving performance.

                      "},{"location":"production/data/#choose-the-right-format","title":"Choose the right format","text":"

                      The first key element is choosing the right format. Some formats are designed for data exchange, others for data rendering and serving. A good data serving format is binary, allows for multi-resolution extraction, and provides support for quick subset extraction at native resolutions.

                      Examples of such formats are GeoTiff, ECW, JPEG 2000 and MrSid. ArcGrid on the other hand is an example of format that's particularly ill-suited for large dataset serving (it's text based, no multi-resolution, and we have to read it fully even to extract a data subset in the general case).

                      GeoServer supports MrSID, ECW and JPEG 2000 through the GDAL Image Format plugin. MrSID is the easiest to work with, as their reader is now available under a GeoServer compatible open source format. If you have ECW files you have several non-ideal options. If you are only using GeoServer for educational or non-profit purposes you can use the plugin for free. If not you need to buy a license, since it's server software. You could also use GDAL to convert it to MrSID or tiled GeoTiffs. If your files are JPEG 2000 you can use the utilities of ECW and MrSID software. But the fastest is Kakadu, which requires a license.

                      "},{"location":"production/data/#setup-geotiff-data-for-fast-rendering","title":"Setup Geotiff data for fast rendering","text":"

                      As soon as your Geotiffs gets beyond some tens of megabytes you'll want to add the following capabilities:

                      • inner tiling
                      • overviews

                      Inner tiling sets up the image layout so that it's organized in tiles instead of simple stripes (rows). This allows much quicker access to a certain area of the geotiff, and the GeoServer readers will leverage this by accessing only the tiles needed to render the current display area. The following sample command instructs gdal_translate to create a tiled geotiff.

                      gdal_translate -of GTiff -projwin -180 90 -50 -10 -co \"TILED=YES\" bigDataSet.ecw myTiff.tiff\n

                      An overview is a downsampled version of the same image, that is, a zoomed out version, which is usually much smaller. When GeoServer needs to render the Geotiff, it'll look for the most appropriate overview as a starting point, thus reading and converting way less data. Overviews can be added using gdaladdo, or the OverviewsEmbedded command included in Geotools. Here is a sample of using gdaladdo to add overviews that are downsampled 2, 4, 8 and 16 times compared to the original:

                      gdaladdo -r average mytiff.tif 2 4 8 16\n

                      As a final note, Geotiff supports various kinds of compression both lossles as well as lossy. JPEG compression can produce artifacts but it usually produce very good results on RGB or RGBA images if coupled with inner masks. Deflate compression is to be preferred with elevation or similar data when a lossless compressions is needed. Generally speaking, if I/O is the bottleneck, compression can help a lot as it reduces the cost of I/O although at the expenses of some CPU cycles.

                      "},{"location":"production/data/#handling-huge-data-sets","title":"Handling huge data sets","text":"

                      If you have really huge data sets (several gigabytes), odds are that simply adding overviews and tiles does not cut it, making intermediate resolution serving slow. This is because tiling occurs only on the native resolution levels, and intermediate overviews are too big for quick extraction.

                      So, what you need is a way to have tiling on intermediate levels as well. This is supported by the ImagePyramid plugin.

                      This plugin assumes you have create various seamless image mosaics, each for a different resolution level of the original image. In the mosaic, tiles are actual files (for more info about mosaics, see the ImageMosaic). The whole pyramid structures looks like the following:

                      rootDirectory\n    +- pyramid.properties\n    +- 0\n       +- mosaic metadata files\n       +- mosaic_file_0.tiff\n       +- ...\n       +- mosiac_file_n.tiff\n    +- ...\n    +- 32\n       +- mosaic metadata files\n       +- mosaic_file_0.tiff\n       +- ...\n       +- mosiac_file_n.tiff\n

                      Creating a pyramid by hand can theoretically be done with gdal, but in practice it's a daunting task that would require some scripting, since gdal provides no \"tiler\" command to extract regular tiles out of an image, nor one to create a downsampled set of tiles. As an alternative, you can use the geotools PyramidBuilder tool (documentation on how to use this is pending, contact the developers if you need to use it).

                      "},{"location":"production/identify/","title":"Make cluster nodes identifiable from the GUI","text":"

                      When running one or more clusters of GeoServer installations it is useful to identify which cluster (and eventually which node of the cluster) one is working against by just glancing the web administration UI.

                      This is possible by setting one variable, GEOSERVER_NODE_OPTS, with one of the supported mechanisms:

                      • as a system variable
                      • as an environment variable
                      • as a servlet context parameter

                      GEOSERVER_NODE_OPTS is a semicolon separated list of key/value pairs and it can contain the following keys:

                      • id: the string identifying the node, which in turn can be a static string, or include the following substitution tokens
                        • $host_ip The IP address of the node
                        • $host_name The hostname of the node
                        • $host_short_name The hostname truncated to not include the domain (foo.local becomes foo)
                        • $host_compact_name The hostname with all domain parts shortened to their first character (foo.local becomes foo.l)
                      • color: the label color, as a CSS color
                      • background: the background color, as a CSS color

                      Here are some examples:

                      GEOSERVER_NODE_OPTS=\"id:test1;background:black;color:white\"

                      GEOSERVER_NODE_OPTS=\"id:$host_ip\"

                      GEOSERVER_NODE_OPTS=\"id:$host_name\"

                      "},{"location":"production/java/","title":"Java Considerations","text":""},{"location":"production/java/#use-supported-jre","title":"Use supported JRE","text":"

                      GeoServer's speed depends a lot on the chosen Java Runtime Environment (JRE). The latest versions of GeoServer are tested with both Oracle JRE and OpenJDK. Implementations other than those tested may work correctly, but are generally not recommended.

                      Tested:

                      • Java 17 - GeoServer 2.22.x and above (OpenJDK tested, experimental only)
                      • Java 11 - GeoServer 2.15.x and above (OpenJDK tested)
                      • Java 8 - GeoServer 2.9.x to GeoServer 2.22.x (OpenJDK and Oracle JRE tested)
                      • Java 7 - GeoServer 2.6.x to GeoServer 2.8.x (OpenJDK and Oracle JRE tested)
                      • Java 6 - GeoServer 2.3.x to GeoServer 2.5.x (Oracle JRE tested)
                      • Java 5 - GeoServer 2.2.x and earlier (Sun JRE tested)

                      As of GeoServer 2.0, a Java Runtime Environment (JRE) is sufficient to run GeoServer. GeoServer no longer requires a Java Development Kit (JDK).

                      "},{"location":"production/java/#running-on-java-17","title":"Running on Java 17","text":"

                      GeoServer is compatible with Java 17, but requires extra care for running in some environments.

                      Deployment on Tomcat 9.0.55 has been tested with success.

                      The \"bin\" packaging can work too, but requires turning off the Marlin rasterizer integration. This can be done by modifying the scripts, or by simply removing the Marlin jars:

                      rm webapps/geoserver/WEB-INF/lib/marlin-0.9.3.jar\n

                      GeoServer code depends on a variety of libraries trying to access the JDK internals. As reported above, it does not seem to matter when running as a web application. However, in case of need, here is the full list of opens used by the build process:

                      --add-opens=java.base/java.lang=ALL-UNNAMED --add-opens=java.base/java.util=ALL-UNNAMED --add-opens=java.base/java.lang.reflect=ALL-UNNAMED --add-opens=java.base/java.text=ALL-UNNAMED --add-opens=java.desktop/java.awt.font=ALL-UNNAMED  --add-opens=java.desktop/sun.awt.image=ALL-UNNAMED --add-opens=java.naming/com.sun.jndi.ldap=ALL-UNNAMED\n
                      "},{"location":"production/java/#running-on-java-11","title":"Running on Java 11","text":"

                      GeoServer 2.15 will run under Java 11 with no additional configuration on Tomcat 9 or newer and Jetty 9.4.12 or newer.

                      Running GeoServer under Java 11 on other Application Servers may require some additional configuration. Some Application Servers do not support Java 11 yet.

                      • Wildfly 14 supports Java 11, with some additional configuration - in the run configuration, under VM arguments add:

                        --add-modules=java.se

                        Future WildFly releases should support Java 11 with no additional configuration.

                      • GlassFish does not currently Java 11, although the upcoming 5.0.1 release is expected to include support for it.

                      • WebLogic do not yet support Java 11.

                      "},{"location":"production/linuxscript/","title":"Linux init scripts","text":"

                      You will have to adjust the scripts to your environment. Download a script, rename it to geoserver and move it to /etc/init.d. Use chmod to make the script executable and test with /etc/init.d/geoserver.

                      To set different values for environment variables, create a file /etc/default/geoserver and specify your environment.

                      Example settings in /etc/default/geoserver for your environment:

                      USER=geoserver\nGEOSERVER_DATA_DIR=/home/$USER/data_dir\nGEOSERVER_HOME=/home/$USER/geoserver\nJAVA_HOME=/usr/lib/jvm/java-6-sun\nJAVA_OPTS=\"-Xms128m -Xmx512m\"\n
                      "},{"location":"production/linuxscript/#debianubuntu","title":"Debian/Ubuntu","text":"

                      Download the init script

                      "},{"location":"production/linuxscript/#suse","title":"Suse","text":"

                      Download the init script

                      "},{"location":"production/linuxscript/#starting-geoserver-in-tomcat","title":"Starting GeoServer in Tomcat","text":"

                      Download the init script

                      "},{"location":"production/misc/","title":"Other Considerations","text":""},{"location":"production/misc/#host-your-application-separately","title":"Host your application separately","text":"

                      GeoServer includes a few sample applications in the demo section of the Web administration interface. For production instances, we recommend against this bundling of your application. To make upgrades and troubleshooting easier, please use a separate container for your application. It is perfectly fine, though, to use one container manager (such as Tomcat or Jetty) to host both GeoServer and your application.

                      "},{"location":"production/misc/#proxy-your-server","title":"Proxy your server","text":"

                      GeoServer can have the capabilities documents properly report a proxy. You can configure this in the Server configuration section of the Web administration interface and entering the URL of the external proxy in the field labeled Proxy base URL.

                      "},{"location":"production/misc/#publish-your-servers-capabilities-documents","title":"Publish your server's capabilities documents","text":"

                      In order to make it easier to find your data, put a link to your capabilities document somewhere on the web. This will ensure that a search engine will crawl and index it.

                      "},{"location":"production/misc/#set-up-clustering","title":"Set up clustering","text":"

                      Setting up a Cluster is one of the best ways to improve the reliability and performance of your GeoServer installation. All the most stable and high performance GeoServer instances are configured in some sort of cluster. There are a huge variety of techniques to configure a cluster, including at the container level, the virtual machine level, and the physical server level.

                      Andrea Aime is currently working on an overview of what some of the biggest GeoServer users have done, for his 'GeoServer in Production' talk at FOSS4G 2009. In time that information will be migrated to tutorials and white papers.

                      "},{"location":"production/troubleshooting/","title":"Troubleshooting","text":""},{"location":"production/troubleshooting/#checking-wfs-requests","title":"Checking WFS requests","text":"

                      It often happens that users report issues with hand-crafted WFS requests not working as expected. In the majority of the cases the request is malformed, but GeoServer does not complain and just ignores the malformed part (this behaviour is the default to make older WFS clients work fine with GeoServer).

                      If you want GeoServer to validate most WFS XML request you can post it to the following URL:

                      http://host:port/geoserver/ows?strict=true\n

                      Any deviation from the required structure will be noted in an error message. The only request type that is not validated in any case is the INSERT one (this is a GeoServer own limitation).

                      "},{"location":"production/troubleshooting/#leveraging-geoserver-own-log","title":"Leveraging GeoServer own log","text":"

                      GeoServer can generate a quite extensive log of its operations in the $GEOSERVER_DATA_DIR/logs/geoserver.log file. Looking into such file is one of the first things to do when troubleshooting a problem, in particular it's interesting to see the log contents in correspondence of a misbehaving request. The amount of information logged can vary based on the logging profile chosen in the Server Settings configuration page.

                      "},{"location":"production/troubleshooting/#troubleshooting_requests","title":"Logging service requests","text":"

                      GeoServer provides a request logging capability that is inactive by default. When enabled in the global settings GeoServer can log both the requested URL and POST requests contents.

                      Global Settings

                      To track a history of the incoming requests:

                      1. Enable request logging by navigating to Settings > Global page, scroll down to Logging Settings, and Enable Request Logging.

                      2. Enable this feature using Enable Request Logging.

                      3. Optionally select Log Request Bodies to troubleshoot POST or PUT requests (for example WFS Transaction). The Number of characters to log setting will put an upper limit on the amount of data that is logged in order to avoid logging related performance issues.

                      4. Optionally select Log Request Headers to troubleshoot Request Headers (for example when checking security credentials).

                      5. Click Apply to apply these settings.

                      6. This will log request information, resulting in something like the following:

                        08 gen 11:30:13 INFO [geoserver.filters] - 127.0.0.1 \"GET /geoserver/wms?HEIGHT=330&WIDTH=660&LAYERS=nurc%3AArc_Sample&STYLES=&SRS=EPSG%3A4326&FORMAT=image%2Fjpeg&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&EXCEPTIONS=application%2Fvnd.ogc.se_inimage&BBOX=-93.515625,-40.078125,138.515625,75.9375\" \"Mozilla/5.0 (X11; U; Linux i686; it; rv:1.9.0.15) Gecko/2009102815 Ubuntu/9.04 (jaunty) Firefox/3.0.15\" \"http://localhost:8080/geoserver/wms?service=WMS&version=1.1.0&request=GetMap&layers=nurc:Arc_Sample&styles=&bbox=-180.0,-90.0,180.0,90.0&width=660&height=330&srs=EPSG:4326&format=application/openlayers\" \n08 gen 11:30:13 INFO [geoserver.filters] - 127.0.0.1 \"GET /geoserver/wms?HEIGHT=330&WIDTH=660&LAYERS=nurc%3AArc_Sample&STYLES=&SRS=EPSG%3A4326&FORMAT=image%2Fjpeg&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&EXCEPTIONS=application%2Fvnd.ogc.se_inimage&BBOX=-93.515625,-40.078125,138.515625,75.9375\" took 467ms\n08 gen 11:30:14 INFO [geoserver.filters] - 127.0.0.1 \"GET /geoserver/wms?REQUEST=GetFeatureInfo&EXCEPTIONS=application%2Fvnd.ogc.se_xml&BBOX=-93.515625%2C-40.078125%2C138.515625%2C75.9375&X=481&Y=222&INFO_FORMAT=text%2Fhtml&QUERY_LAYERS=nurc%3AArc_Sample&FEATURE_COUNT=50&Layers=nurc%3AArc_Sample&Styles=&Srs=EPSG%3A4326&WIDTH=660&HEIGHT=330&format=image%2Fjpeg\" \"Mozilla/5.0 (X11; U; Linux i686; it; rv:1.9.0.15) Gecko/2009102815 Ubuntu/9.04 (jaunty) Firefox/3.0.15\" \"http://localhost:8080/geoserver/wms?service=WMS&version=1.1.0&request=GetMap&layers=nurc:Arc_Sample&styles=&bbox=-180.0,-90.0,180.0,90.0&width=660&height=330&srs=EPSG:4326&format=application/openlayers\" \n08 gen 11:30:14 INFO [geoserver.filters] - 127.0.0.1 \"GET /geoserver/wms?REQUEST=GetFeatureInfo&EXCEPTIONS=application%2Fvnd.ogc.se_xml&BBOX=-93.515625%2C-40.078125%2C138.515625%2C75.9375&X=481&Y=222&INFO_FORMAT=text%2Fhtml&QUERY_LAYERS=nurc%3AArc_Sample&FEATURE_COUNT=50&Layers=nurc%3AArc_Sample&Styles=&Srs=EPSG%3A4326&WIDTH=660&HEIGHT=330&format=image%2Fjpeg\" took 314ms\n
                      "},{"location":"production/troubleshooting/#server-status-jvm-console","title":"Server Status JVM Console","text":"

                      GeoServer provides a built-in JVM Console used to obtain:

                      • Thread Dump information
                      • Heap Dump information

                      This page can be used to check current status and download the results for careful review.

                      JVM Console

                      "},{"location":"production/troubleshooting/#using-jdk-tools-to-get-stack-and-memory-dumps","title":"Using JDK tools to get stack and memory dumps","text":"

                      The JDK contains three useful command line tools that can be used to gather information about GeoServer instances that are leaking memory or not performing as requested: jps, jstack and jmap.

                      All tools work against a live Java Virtual Machine, the one running GeoServer in particular. In order for them to work properly you'll have to run them with a user that has enough privileges to connect to the JVM process, in particular super user or the same user that's running the JVM usually have the required right.

                      "},{"location":"production/troubleshooting/#jps","title":"jps","text":"

                      jps is a tool listing all the Java processing running. It can be used to retrieve the pid (process id) of the virtual machine that is running GeoServer. For example:

                      > jps -mlv\n\n16235 org.apache.catalina.startup.Bootstrap start -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.util.logging.config.file=/home/aaime/devel/webcontainers/apache-tomcat-6.0.18/conf/logging.properties -Djava.endorsed.dirs=/home/aaime/devel/webcontainers/apache-tomcat-6.0.18/endorsed -Dcatalina.base=/home/aaime/devel/webcontainers/apache-tomcat-6.0.18 -Dcatalina.home=/home/aaime/devel/webcontainers/apache-tomcat-6.0.18 -Djava.io.tmpdir=/home/aaime/devel/webcontainers/apache-tomcat-6.0.18/temp\n11521  -XX:MinHeapFreeRatio=10 -XX:MaxHeapFreeRatio=20 -Djava.library.path=/usr/lib/jni -Dosgi.requiredJavaVersion=1.5 -XX:MaxPermSize=256m -Xms64m -Xmx1024m -XX:CMSClassUnloadingEnabled -XX:CMSPermGenSweepingEnabled -XX:+UseParNewGC\n16287 sun.tools.jps.Jps -mlv -Dapplication.home=/usr/lib/jvm/java-6-sun-1.6.0.16 -Xms8m\n

                      The output shows the pid, the main class name if available, and the parameters passed to the JVM at startup. In this example 16235 is Tomcat hosting GeoServer, 11521 is an Eclipse instance, and 16287 is jps itself. In the common case you'll have only few JVM and the one running GeoServer can be identified by the parameters passed to it.

                      "},{"location":"production/troubleshooting/#jstack","title":"jstack","text":"

                      jstack is a tool for extracting the current stack trace for each thread running in the virtual machine. It can be used to identify scalability issues and to gather what the program is actually doing.

                      It usually requires detailed understanding of the inner workings of GeoServer to properly interpret the jstack output.

                      An example of usage:

                      > jstack -F -l 16235 > /tmp/tomcat-stack.txt\nAttaching to process ID 16235, please wait...\nDebugger attached successfully.\nServer compiler detected.\nJVM version is 14.2-b01\n

                      And the file contents might look like:

                      Deadlock Detection:\n\nNo deadlocks found.\n\nThread 16269: (state = BLOCKED)\n - java.lang.Object.wait(long) @bci=0 (Interpreted frame)\n - org.apache.tomcat.util.threads.ThreadPool$MonitorRunnable.run() @bci=10, line=565 (Interpreted frame)\n - java.lang.Thread.run() @bci=11, line=619 (Interpreted frame)\n\nLocked ownable synchronizers:\n    - None\n\nThread 16268: (state = IN_NATIVE)\n - java.net.PlainSocketImpl.socketAccept(java.net.SocketImpl) @bci=0 (Interpreted frame)\n - java.net.PlainSocketImpl.accept(java.net.SocketImpl) @bci=7, line=390 (Interpreted frame)\n - java.net.ServerSocket.implAccept(java.net.Socket) @bci=60, line=453 (Interpreted frame)\n - java.net.ServerSocket.accept() @bci=48, line=421 (Interpreted frame)\n - org.apache.jk.common.ChannelSocket.accept(org.apache.jk.core.MsgContext) @bci=46, line=306 (Interpreted frame)\n - org.apache.jk.common.ChannelSocket.acceptConnections() @bci=72, line=660 (Interpreted frame)\n - org.apache.jk.common.ChannelSocket$SocketAcceptor.runIt(java.lang.Object[]) @bci=4, line=870 (Interpreted frame)\n - org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run() @bci=167, line=690 (Interpreted frame)\n - java.lang.Thread.run() @bci=11, line=619 (Interpreted frame)\n\nLocked ownable synchronizers:\n    - None\n\nThread 16267: (state = BLOCKED)\n - java.lang.Object.wait(long) @bci=0 (Interpreted frame)\n - java.lang.Object.wait() @bci=2, line=485 (Interpreted frame)\n - org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run() @bci=26, line=662 (Interpreted frame)\n - java.lang.Thread.run() @bci=11, line=619 (Interpreted frame)\n\nLocked ownable synchronizers:\n    - None\n\n...\n
                      "},{"location":"production/troubleshooting/#jmap","title":"jmap","text":"

                      jmap is a tool to gather information about the Java virtual machine. It can be used in a few interesting ways.

                      By running it without arguments (other than the process id of the JVM) it will print out a dump of the native libraries used by the JVM. This can come in handy when one wants to double check GeoServer is actually using a certain version of a native library (e.g., GDAL):

                      > jmap 17251\n\nAttaching to process ID 17251, please wait...\nDebugger attached successfully.\nServer compiler detected.\nJVM version is 14.2-b01\n0x08048000  46K   /usr/lib/jvm/java-6-sun-1.6.0.16/jre/bin/java\n0x7f87f000  6406K /usr/lib/jvm/java-6-sun-1.6.0.16/jre/lib/i386/libNCSEcw.so.0\n0x7f9b2000  928K  /usr/lib/libstdc++.so.6.0.10\n0x7faa1000  7275K /usr/lib/jvm/java-6-sun-1.6.0.16/jre/lib/i386/libgdal.so.1\n0x800e9000  1208K /usr/lib/jvm/java-6-sun-1.6.0.16/jre/lib/i386/libclib_jiio.so\n0x80320000  712K  /usr/lib/jvm/java-6-sun-1.6.0.16/jre/lib/i386/libNCSUtil.so.0\n0x80343000  500K  /usr/lib/jvm/java-6-sun-1.6.0.16/jre/lib/i386/libNCSCnet.so.0\n0x8035a000  53K   /lib/libgcc_s.so.1\n0x8036c000  36K   /usr/lib/jvm/java-6-sun-1.6.0.16/jre/lib/i386/libnio.so\n0x803e2000  608K  /usr/lib/jvm/java-6-sun-1.6.0.16/jre/lib/i386/libawt.so\n0x80801000  101K  /usr/lib/jvm/java-6-sun-1.6.0.16/jre/lib/i386/libgdaljni.so\n0x80830000  26K   /usr/lib/jvm/java-6-sun-1.6.0.16/jre/lib/i386/headless/libmawt.so\n0x81229000  93K   /usr/lib/jvm/java-6-sun-1.6.0.16/jre/lib/i386/libnet.so\n0xb7179000  74K   /usr/lib/jvm/java-6-sun-1.6.0.16/jre/lib/i386/libzip.so\n0xb718a000  41K   /lib/tls/i686/cmov/libnss_files-2.9.so\n0xb7196000  37K   /lib/tls/i686/cmov/libnss_nis-2.9.so\n0xb71b3000  85K   /lib/tls/i686/cmov/libnsl-2.9.so\n0xb71ce000  29K   /lib/tls/i686/cmov/libnss_compat-2.9.so\n0xb71d7000  37K   /usr/lib/jvm/java-6-sun-1.6.0.16/jre/lib/i386/native_threads/libhpi.so\n0xb71de000  184K  /usr/lib/jvm/java-6-sun-1.6.0.16/jre/lib/i386/libjava.so\n0xb7203000  29K   /lib/tls/i686/cmov/librt-2.9.so\n0xb725d000  145K  /lib/tls/i686/cmov/libm-2.9.so\n0xb7283000  8965K /usr/lib/jvm/java-6-sun-1.6.0.16/jre/lib/i386/server/libjvm.so\n0xb7dc1000  1408K /lib/tls/i686/cmov/libc-2.9.so\n0xb7f24000  9K    /lib/tls/i686/cmov/libdl-2.9.so\n0xb7f28000  37K   /usr/lib/jvm/java-6-sun-1.6.0.16/jre/lib/i386/jli/libjli.so\n0xb7f32000  113K  /lib/tls/i686/cmov/libpthread-2.9.so\n0xb7f51000  55K   /usr/lib/jvm/java-6-sun-1.6.0.16/jre/lib/i386/libverify.so\n0xb7f60000  114K  /lib/ld-2.9.so\n

                      It's also possible to get a quick summary of the JVM heap status:

                      > jmap -heap 17251\n\nAttaching to process ID 17251, please wait...\nDebugger attached successfully.\nServer compiler detected.\nJVM version is 14.2-b01\n\nusing thread-local object allocation.\nParallel GC with 2 thread(s)\n\nHeap Configuration:\n   MinHeapFreeRatio = 40\n   MaxHeapFreeRatio = 70\n   MaxHeapSize      = 778043392 (742.0MB)\n   NewSize          = 1048576 (1.0MB)\n   MaxNewSize       = 4294901760 (4095.9375MB)\n   OldSize          = 4194304 (4.0MB)\n   NewRatio         = 8\n   SurvivorRatio    = 8\n   PermSize         = 16777216 (16.0MB)\n   MaxPermSize      = 67108864 (64.0MB)\n\nHeap Usage:\nPS Young Generation\nEden Space:\n   capacity = 42401792 (40.4375MB)\n   used     = 14401328 (13.734176635742188MB)\n   free     = 28000464 (26.703323364257812MB)\n   33.96396076845054% used\nFrom Space:\n   capacity = 4718592 (4.5MB)\n   used     = 2340640 (2.232208251953125MB)\n   free     = 2377952 (2.267791748046875MB)\n   49.60462782118056% used\nTo Space:\n   capacity = 4587520 (4.375MB)\n   used     = 0 (0.0MB)\n   free     = 4587520 (4.375MB)\n   0.0% used\nPS Old Generation\n   capacity = 43188224 (41.1875MB)\n   used     = 27294848 (26.0303955078125MB)\n   free     = 15893376 (15.1571044921875MB)\n   63.19974630121396% used\nPS Perm Generation\n   capacity = 38404096 (36.625MB)\n   used     = 38378640 (36.60072326660156MB)\n   free     = 25456 (0.0242767333984375MB)\n   99.93371540369027% used\n

                      In the result it can be seen that the JVM is allowed to use up to 742MB of memory, and that at the moment the JVM is using 130MB (rough sum of the capacities of each heap section). In case of a persistent memory leak the JVM will end up using whatever is allowed to and each section of the heap will be almost 100% used.

                      To see how the memory is actually being used in a succinct way the following command can be used (on Windows, replace head -25 with more):

                      > jmap -histo:live 17251 | head -25\n\n num     #instances         #bytes  class name\n----------------------------------------------\n   1:         81668       10083280  <constMethodKlass>\n   2:         81668        6539632  <methodKlass>\n   3:         79795        5904728  [C\n   4:        123511        5272448  <symbolKlass>\n   5:          7974        4538688  <constantPoolKlass>\n   6:         98726        3949040  org.hsqldb.DiskNode\n   7:          7974        3612808  <instanceKlassKlass>\n   8:          9676        2517160  [B\n   9:          6235        2465488  <constantPoolCacheKlass>\n  10:         10054        2303368  [I\n  11:         83121        1994904  java.lang.String\n  12:         27794        1754360  [Ljava.lang.Object;\n  13:          9227         868000  [Ljava.util.HashMap$Entry;\n  14:          8492         815232  java.lang.Class\n  15:         10645         710208  [S\n  16:         14420         576800  org.hsqldb.CachedRow\n  17:          1927         574480  <methodDataKlass>\n  18:          8937         571968  org.apache.xerces.dom.ElementNSImpl\n  19:         12898         561776  [[I\n  20:         23122         554928  java.util.HashMap$Entry\n  21:         16910         541120  org.apache.xerces.dom.TextImpl\n  22:          9898         395920  org.apache.xerces.dom.AttrNSImpl\n

                      By the dump we can see most of the memory is used by the GeoServer code itself (first 5 items) followed by the HSQL cache holding a few rows of the EPSG database. In case of a memory leak a few object types will hold the vast majority of the live heap. Mind, to look for a leak the dump should be gathered with the server almost idle. If, for example, the server is under a load of GetMap requests the main memory usage will be the byte[] holding the images while they are rendered, but that is not a leak, it's legitimate and temporary usage.

                      In case of memory leaks a developer will probably ask for a full heap dump to analyze with a high end profiling tool. Such dump can be generated with the following command:

                      > jmap -dump:live,file=/tmp/dump.hprof 17251\nDumping heap to /tmp/dump.hprof ...\nHeap dump file created\n

                      The dump files are generally as big as the memory used so it's advisable to compress the resulting file before sending it to a developer.

                      "},{"location":"production/troubleshooting/#xstream","title":"XStream","text":"

                      GeoServer and GeoWebCache use XStream to read and write XML for configuration and for their REST APIs. In order to do this securely, it needs a list of Java classes that are safe to convert between objects and XML. If a class not on that list is given to XStream, it will generate the error com.thoughtworks.xstream.security.ForbiddenClassException. The specific class that was a problem should also be included. This may be a result of the lists of allowed classes missing a class, which should be reported as a bug, or it may be caused by an extension/plugin not adding its classes to the list (finally, it could be someone trying to perform a \"Remote Execution\" attack, which is what the allow-list is designed to prevent).

                      This can be worked around by setting the system properties GEOSERVER_XSTREAM_WHITELIST for GeoServer or GEOWEBCACHE_XSTREAM_WHITELIST for GeoWebCache to a semicolon separated list of qualified class names. The class names may include wildcards ? for a single character, * for any number of characters not including the separator ., and ** for any number of characters including separators. For instance, org.example.blah.SomeClass; com.demonstration.*; ca.test.** will allow, the specific class org.example.blah.SomeClass, any class immediately within the package com.demonstration, and any class within the package ca.test or any of its descendant packages.

                      GEOSERVER_XSTREAM_WHITELIST and GEOWEBCACHE_XSTREAM_WHITELIST should only be used as a workaround until GeoServer, GWC, or the extension causing the problem has been updated, so please report to the users list the missing classes as soon as possible.

                      "},{"location":"rest/","title":"REST","text":"

                      GeoServer provides a RESTful interface through which clients can retrieve information about an instance and make configuration changes. Using the REST interface's simple HTTP calls, clients can configure GeoServer without needing to use the Web administration interface.

                      REST is an acronym for \"REpresentational State Transfer\". REST adopts a fixed set of operations on named resources, where the representation of each resource is the same for retrieving and setting information. In other words, you can retrieve (read) data in an XML format and also send data back to the server in similar XML format in order to set (write) changes to the system.

                      Operations on resources are implemented with the standard primitives of HTTP: GET to read; and PUT, POST, and DELETE to write changes. Each resource is represented as a URL, such as http://GEOSERVER_HOME/rest/workspaces/topp.

                      "},{"location":"rest/#api","title":"API","text":"

                      Warning

                      The API is documented as Swagger 2.0 files. However, these files have been written by hand back in 2017, and have not always been kept up to date with the evolution of the GeoServer configuration object structure. Also, they have not been tested for proper client generation, and will likely not work for that purpose. Take them only as a form of documentation.

                      The following links provide direct access to the GeoServer REST API documentation, including definitions and examples of each endpoint:

                      • /about/manifests
                      • /about/system-status
                      • /datastores
                      • /coverages
                      • /coveragestores
                      • /featuretypes
                      • /fonts
                      • /layergroups
                      • /layers
                      • /logging
                      • /monitoring
                      • /namespaces
                      • /services/wms|wfs|wcs|wmts/settings
                      • /reload
                      • /resource
                      • /security
                      • /settings
                      • /structuredcoverages
                      • /styles
                      • /templates
                      • /transforms
                      • /wmslayers
                      • /wmsstores
                      • /wmtslayers
                      • /wmtsstores
                      • /workspaces
                      • /usergroup
                      • /roles
                      • GeoWebCache:
                        • /blobstores
                        • /bounds
                        • /diskquota
                        • /filterupdate
                        • /global
                        • /gridsets
                        • /index
                        • /layers
                        • /masstruncate
                        • /statistics
                        • /reload
                        • /seed
                      • Importer extension:
                        • /imports
                        • /imports (tasks)
                        • /imports (transforms)
                        • /imports (data)
                      • Monitor extension:
                        • /monitor
                      • XSLT extension:
                        • /services/wfs/transforms

                      Note

                      You can also view the original REST configuration API reference section.

                      "},{"location":"rest/#examples","title":"Examples","text":"

                      This section contains a number of examples which illustrate some of the most common uses of the REST API. They are grouped by endpoint.

                      "},{"location":"rest/about/","title":"About","text":"

                      The REST API allows you to set and retrieve information about the server itself.

                      Note

                      Read the API reference for /about/manifests <manifests.yaml>__.

                      "},{"location":"rest/about/#retrieving-component-versions","title":"Retrieving component versions","text":"

                      Retrieve the versions of the main components: GeoServer, GeoTools, and GeoWebCache

                      Request

                      curl

                      curl -v -u admin:geoserver -XGET -H \"Accept: text/xml\" http://localhost:8080/geoserver/rest/about/version.xml

                      Response

                      <about>\n <resource name=\"GeoServer\">\n  <Build-Timestamp>11-Dec-2012 17:55</Build-Timestamp>\n  <Git-Revision>e66f8da85521f73d0fd00b71331069a5f49f7865</Git-Revision>\n  <Version>2.3-SNAPSHOT</Version>\n </resource>\n <resource name=\"GeoTools\">\n  <Build-Timestamp>04-Dec-2012 02:31</Build-Timestamp>\n  <Git-Revision>380a2b8545ee9221f1f2d38a4f10ef77a23bccae</Git-Revision>\n  <Version>9-SNAPSHOT</Version>\n </resource>\n <resource name=\"GeoWebCache\">\n  <Git-Revision>2a534f91f6b99e5120a9eaa5db62df771dd01688</Git-Revision>\n  <Version>1.3-SNAPSHOT</Version>\n </resource>\n</about>\n
                      "},{"location":"rest/about/#retrieving-manifests","title":"Retrieving manifests","text":"

                      Retrieve the full manifest and subsets of the manifest as known to the ClassLoader

                      Request

                      curl

                      curl -v -u admin:geoserver -XGET -H \"Accept: text/xml\" http://localhost:8080/geoserver/rest/about/manifest.xml

                      Note

                      The result will be a very long list of manifest information. While this can be useful, it is often desirable to filter this list.

                      Retrieve manifests, filtered by resource name

                      Note

                      This example will retrieve only resources where the name attribute matches gwc-.*.

                      Request

                      curl

                      curl -v -u admin:geoserver -XGET -H \"Accept: text/xml\" http://localhost:8080/geoserver/rest/about/manifest.xml?manifest=gwc-.*

                      Response

                      <about>\n  <resource name=\"gwc-2.3.0\">\n    ...\n  </resource>\n  <resource name=\"gwc-core-1.4.0\">\n    ...\n  </resource>\n  <resource name=\"gwc-diskquota-core-1.4.0\">\n    ...\n  </resource>\n  <resource name=\"gwc-diskquota-jdbc-1.4.0\">\n    ...\n  </resource>\n  <resource name=\"gwc-georss-1.4.0\">\n    ...\n  </resource>\n  <resource name=\"gwc-gmaps-1.4.0\">\n    ...\n  </resource>\n  <resource name=\"gwc-kml-1.4.0\">\n    ...\n  </resource>\n  <resource name=\"gwc-rest-1.4.0\">\n    ...\n  </resource>\n  <resource name=\"gwc-tms-1.4.0\">\n    ...\n  </resource>\n  <resource name=\"gwc-ve-1.4.0\">\n    ...\n  </resource>\n  <resource name=\"gwc-wms-1.4.0\">\n    ...\n  </resource>\n  <resource name=\"gwc-wmts-1.4.0\">\n    ...\n  </resource>\n</about>\n

                      Retrieve manifests, filtered by resource property

                      Note

                      This example will retrieve only resources with a property equal to GeoServerModule.

                      Request

                      curl

                      curl -u admin:geoserver -XGET -H \"Accept: text/xml\" http://localhost:8080/geoserver/rest/about/manifest.xml?key=GeoServerModule

                      Response

                      <about>\n <resource name=\"control-flow-2.3.0\">\n  <GeoServerModule>extension</GeoServerModule>\n  ...\n </resource>\n ...\n <resource name=\"wms-2.3.0\">\n  <GeoServerModule>core</GeoServerModule>\n  ...\n </resource>\n</about>\n

                      Retrieve manifests, filtered by both resource name and property

                      Note

                      This example will retrieve only resources where a property with named GeoServerModule has a value equal to extension.

                      Request

                      curl

                      curl -u admin:geoserver -XGET -H \"Accept: text/xml\" http://localhost:8080/geoserver/rest/about/manifest.xml?key=GeoServerModule&value=extension

                      "},{"location":"rest/about/#system-status","title":"System Status","text":"

                      It is possible to request the available system information (monitoring data) through the GeoServer REST API. The supported formats are XML, JSON and HTML.

                      The available REST endpoints are: :

                      /geoserver/rest/about/system-status\n\n/geoserver/rest/about/system-status.json\n\n/geoserver/rest/about/system-status.xml\n\n/geoserver/rest/about/system-status.html\n

                      The HTML representation of the system data is equal to the System status tab representation:

                      System status

                      The XML and JSON representations are quite similar. For each system information metric, the following attributes will be available:

                      Name Description

                      name name of the metric

                      available TRUE if the system information value is available

                      description description of this system information

                      unit unit of the system information, can be empty

                      category category of this system information

                      priority this value can be used to render the metrics in a predefined order

                      identifier identifies the resource associated with the metric, e.g. file partition name

                      Example of XML representation:

                      <metrics>\n  <metric>\n   <value>99614720</value>\n   <available>true</available>\n   <description>Partition [/dev/nvme0n1p2] total space</description>\n   <name>PARTITION_TOTAL</name>\n   <unit>bytes</unit>\n   <category>FILE_SYSTEM</category>\n   <identifier>/dev/nvme0n1p2</identifier>\n   <priority>507</priority>\n </metric>\n (...)\n

                      Example of JSON representation:

                      {\n    \"metrics\": {\n        \"metric\": [\n            {\n              \"available\": true,\n              \"category\": \"FILE_SYSTEM\",\n              \"description\": \"Partition [/dev/nvme0n1p2] total space\",\n              \"identifier\": \"/dev/nvme0n1p2\",\n              \"name\": \"PARTITION_TOTAL\",\n              \"priority\": 507,\n              \"unit\": \"bytes\",\n              \"value\": 99614720\n            },\n
                      "},{"location":"rest/appschema/","title":"App Schema","text":""},{"location":"rest/appschema/#appschema_upload_create","title":"Uploading an app-schema mapping file","text":"

                      Create a new app-schema store and update the feature type mappings of an existing app-schema store by uploading a mapping configuration file

                      The following request uploads an app-schema mapping file called LandCoverVector.xml to a data store called LandCoverVector. If no LandCoverVector data store existed in workspace lcv prior to the request, it would be created.

                      Request

                      curl

                      curl -v -X PUT -d @LandCoverVector.xml -H \"Content-Type: text/xml\" -u admin:geoserver http://localhost:8080/geoserver/rest/workspaces/lcv/datastores/LandCoverVector/file.appschema?configure=all

                      Response

                      201 Created\n
                      "},{"location":"rest/appschema/#listing-app-schema-store-details","title":"Listing app-schema store details","text":"

                      Request

                      curl

                      curl -v -u admin:geoserver -X GET http://localhost:8080/geoserver/rest/workspaces/lcv/datastores/LandCoverVector.xml

                      Response

                      <dataStore>\n  <name>LandCoverVector</name>\n  <type>Application Schema DataAccess</type>\n  <enabled>true</enabled>\n  <workspace>\n    <name>lcv</name>\n    <atom:link xmlns:atom=\"http://www.w3.org/2005/Atom\" rel=\"alternate\" href=\"http://localhost:8080/geoserver/rest/workspaces/lcv.xml\" type=\"application/xml\"/>\n  </workspace>\n  <connectionParameters>\n    <entry key=\"dbtype\">app-schema</entry>\n    <entry key=\"namespace\">http://inspire.ec.europa.eu/schemas/lcv/3.0</entry>\n    <entry key=\"url\">file:/path/to/data_dir/data/lcv/LandCoverVector/LandCoverVector.appschema</entry>\n  </connectionParameters>\n  <__default>false</__default>\n  <featureTypes>\n    <atom:link xmlns:atom=\"http://www.w3.org/2005/Atom\" rel=\"alternate\" href=\"http://localhost:8080/geoserver/rest/workspaces/lcv/datastores/LandCoverVector/featuretypes.xml\" type=\"application/xml\"/>\n  </featureTypes>\n</dataStore>\n
                      "},{"location":"rest/appschema/#uploading-a-new-app-schema-mapping-configuration-file","title":"Uploading a new app-schema mapping configuration file","text":"

                      Upload a new mapping configuration, stored in the mapping file \"`LandCoverVector_alternative.xml\", to the \"LandCoverVector\" data store

                      Request

                      curl

                      curl -v -X PUT -d @LandCoverVector_alternative.xml -H \"Content-Type: text/xml\" -u admin:geoserver http://localhost:8080/geoserver/rest/workspaces/lcv/datastores/LandCoverVector/file.appschema?configure=none

                      Response

                      200 OK\n

                      Note

                      This time the configure parameter is set to none, because we don't want to configure again the feature types, just replace their mapping configuration.

                      Note

                      If the set of feature types mapped in the new configuration file differs from the set of feature types mapped in the old one (either some are missing, or some are new, or both), the best way to proceed is to delete the data store and create it anew issuing another PUT request, as shown above.

                      "},{"location":"rest/appschema/#uploading-multiple-app-schema-mapping-files","title":"Uploading multiple app-schema mapping files","text":"

                      Create a new app-schema data store based on a complex mapping configuration split into multiple files, and show how to upload application schemas (i.e. XSD files) along with the mapping configuration.

                      Note

                      In the previous example, we have seen how to create a new app-schema data store by uploading a mapping configuration stored in a single file; this time, things are more complicated, since the mappings have been spread over two configuration files: the main configuration file is called geosciml.appschema and contains the mappings for three feature types: GeologicUnit, MappedFeature and GeologicEvent; the second file is called cgi_termvalue.xml and contains the mappings for a single non-feature type, CGI_TermValue.

                      Note

                      As explained in the REST API reference documentation for data stores, when the mapping configuration is spread over multiple files, the extension of the main configuration file must be .appschema.

                      The main configuration file includes the second file:

                      ...\n<includedTypes>\n  <Include>cgi_termvalue.xml</Include>\n</includedTypes>\n...\n

                      We also want to upload to GeoServer the schemas required to define the mapping, instead of having GeoServer retrieve them from the internet (which is especially useful in case our server doesn't have access to the web). The main schema is called geosciml.xsd and is referred to in geosciml.appschema as such:

                      ...\n<targetTypes>\n  <FeatureType>\n    <schemaUri>geosciml.xsd</schemaUri>\n  </FeatureType>\n</targetTypes>\n...\n

                      In this case, the main schema depends on several other schemas:

                      <include schemaLocation=\"geologicUnit.xsd\"/>\n<include schemaLocation=\"borehole.xsd\"/>\n<include schemaLocation=\"vocabulary.xsd\"/>\n<include schemaLocation=\"geologicRelation.xsd\"/>\n<include schemaLocation=\"fossil.xsd\"/>\n<include schemaLocation=\"value.xsd\"/>\n<include schemaLocation=\"geologicFeature.xsd\"/>\n<include schemaLocation=\"geologicAge.xsd\"/>\n<include schemaLocation=\"earthMaterial.xsd\"/>\n<include schemaLocation=\"collection.xsd\"/>\n<include schemaLocation=\"geologicStructure.xsd\"/>\n

                      They don't need to be listed in the targetTypes section of the mapping configuration, but they must be included in the ZIP archive that will be uploaded.

                      Note

                      The GeoSciML schemas listed above, as pretty much any application schema out there, reference the base GML schemas (notably, http://schemas.opengis.net/gml/3.1.1/base/gml.xsd) and a few other remotely hosted schemas (e.g. http://www.geosciml.org/cgiutilities/1.0/xsd/cgiUtilities.xsd). For the example to work in a completely offline environment, one would have to either replace all remote references with local ones, or pre-populate the app-schema cache with a copy of the remote schemas. GeoServer's user manual contains more information on the app-schema cache.

                      To summarize, we'll upload to GeoServer a ZIP archive with the following contents:

                      geosciml.appschema      # main mapping file\ncgi_termvalue.xml       # secondary mapping file\ngeosciml.xsd            # main schema\nborehole.xsd\ncollection.xsd\nearthMaterial.xsd\nfossil.xsd\ngeologicAge.xsd\ngeologicFeature.xsd\ngeologicRelation.xsd\ngeologicStructure.xsd\ngeologicUnit.xsd\nvalue.xsd\nvocabulary.xsd\n

                      Request

                      curl

                      curl -X PUT --data-binary @geosciml.zip -H \"Content-Type: application/zip\" -u admin:geoserver http://localhost:8080/geoserver/rest/workspaces/gsml/datastores/geosciml/file.appschema?configure=all

                      Response

                      200 OK\n

                      A new geosciml data store will be created with three feature types in it:

                      <featureTypes>\n  <featureType>\n    <name>MappedFeature</name>\n    <atom:link xmlns:atom=\"http://www.w3.org/2005/Atom\" rel=\"alternate\" href=\"http://localhost:8080/geoserver/rest/workspaces/gsml/datastores/geosciml/featuretypes/MappedFeature.xml\" type=\"application/xml\"/>\n  </featureType>\n  <featureType>\n    <name>GeologicEvent</name>\n    <atom:link xmlns:atom=\"http://www.w3.org/2005/Atom\" rel=\"alternate\" href=\"http://localhost:8080/geoserver/rest/workspaces/gsml/datastores/geosciml/featuretypes/GeologicEvent.xml\" type=\"application/xml\"/>\n  </featureType>\n  <featureType>\n    <name>GeologicUnit</name>\n    <atom:link xmlns:atom=\"http://www.w3.org/2005/Atom\" rel=\"alternate\" href=\"http://localhost:8080/geoserver/rest/workspaces/gsml/datastores/geosciml/featuretypes/GeologicUnit.xml\" type=\"application/xml\"/>\n  </featureType>\n</featureTypes>\n
                      "},{"location":"rest/appschema/#cleaning-schemas-on-internal-mongodb-stores","title":"Cleaning schemas on internal MongoDB stores","text":"

                      Clean persisted schema on an internal MongoDB Store, allowing it to generate a new one from data.

                      Request template

                      curl

                      curl -v -X POST -u admin:geoserver http://localhost:8080/geoserver/rest/workspaces/{WORKSPACE}/appschemastores/{APP_SCHEMA_STORE_NAME}/datastores/{INTERNAL_STORE_ID}/cleanSchemas

                      Request

                      curl

                      curl -v -X POST -u admin:geoserver http://localhost:8080/geoserver/rest/workspaces/st/appschemastores/AppSchemaStoreName/datastores/store_id/cleanSchemas

                      Response

                      200 OK\n

                      Clean persisted schema on all internal MongoDB Stores, allowing it to generate them from data.

                      Request template

                      curl

                      curl -v -X POST -u admin:geoserver http://localhost:8080/geoserver/rest/workspaces/{WORKSPACE}/appschemastores/{APP_SCHEMA_STORE_NAME}/cleanSchemas

                      Request

                      curl

                      curl -v -X POST -u admin:geoserver http://localhost:8080/geoserver/rest/workspaces/st/appschemastores/AppSchemaStoreName/cleanSchemas

                      Response

                      200 OK\n

                      Rebuild persisted schema on internal MongoDB Store, allowing it to generate them from data and query parameters.

                      Request template

                      curl

                      curl -v -X POST -u admin:geoserver http://localhost:8080/geoserver/rest/workspaces/{WORKSPACE}/appschemastores/{APP_SCHEMA_STORE_NAME}/datastores/{INTERNAL_STORE_ID}/rebuildMongoSchemas?ids={ID_1},{ID_2}&max={MAX_OBJECTS}

                      • ids: Comma separated MongoDB JSON objects ids to query for generating schemas. Not required if the 'max' is setted.
                      • max: Max number of MongoDB JSON objects to get for generating schemas. Not required if the 'ids' is setted.

                      Request

                      curl

                      curl -v -X POST -u admin:geoserver http://localhost:8080/geoserver/rest/workspaces/st/appschemastores/AppSchemaStoreName/datastores/store_id/rebuildMongoSchemas?ids=58e5889ce4b02461ad5af081,58e5889ce4b02461ad5af080&max=5

                      Response

                      200 OK\n

                      Rebuild persisted schema on all internal MongoDB Stores, allowing it to generate them from data and query parameters.

                      Request template

                      curl

                      curl -v -X POST -u admin:geoserver http://localhost:8080/geoserver/rest/workspaces/{WORKSPACE}/appschemastores/{APP_SCHEMA_STORE_NAME}/rebuildMongoSchemas?ids={ID_1},{ID_2}&max={MAX_OBJECTS}

                      • ids: Comma separated MongoDB JSON objects ids to query for generating schemas. Not required if the 'max' is setted.
                      • max: Max number of MongoDB JSON objects to get for generating schemas. Not required if the 'ids' is setted.

                      Request

                      curl

                      curl -v -X POST -u admin:geoserver http://localhost:8080/geoserver/rest/workspaces/st/appschemastores/AppSchemaStoreName/rebuildMongoSchemas?ids=58e5889ce4b02461ad5af081,58e5889ce4b02461ad5af080&max=5

                      Response

                      200 OK\n

                      Note

                      This endpoins are only available when App-Schema and MongoDB modules are installed on Geoserver, and involved app-schema store have internal MongoDB stores in mappings definition.

                      "},{"location":"rest/fonts/","title":"Fonts","text":"

                      The REST API allows you to list---but not modify---fonts available in GeoServer. It can be useful to use this operation to verify if a font used in a style file is available before uploading it.

                      Note

                      Read the API reference for /fonts.

                      "},{"location":"rest/fonts/#getting-a-list-of-all-fonts","title":"Getting a list of all fonts","text":"

                      List all fonts on the server, in JSON format:

                      Request

                      curl

                      curl -u admin:geoserver -XGET http://localhost:8080/geoserver/rest/fonts.json

                      Response

                      {\"fonts\":[\"Calibri Light Italic\",\"Microsoft PhagsPa Bold\",\"Lucida Sans Typewriter Oblique\",\"ChaparralPro-Regular\",\"Californian FB Italic\"]}\n

                      List all fonts on the server, in XML format:

                      Request

                      curl

                      curl -u admin:geoserver -XGET http://localhost:8080/geoserver/rest/fonts.xml

                      Response

                      <root>\n  <fonts>\n    <entry>Calibri Light Italic</entry>\n    <entry>Microsoft PhagsPa Bold</entry>\n    <entry>Lucida Sans Typewriter Oblique</entry>\n    <entry>ChaparralPro-Regular</entry>\n    <entry>Californian FB Italic</entry>\n  </fonts>\n</root>\n
                      "},{"location":"rest/imagemosaic/","title":"Uploading a new image mosaic","text":"

                      Upload a ZIP file containing a mosaic definition and granule(s)

                      Request

                      curl

                      curl -u admin:geoserver -XPUT -H \"Content-type:application/zip\" --data-binary @polyphemus.zip http://localhost:8080/geoserver/rest/workspaces/topp/coveragestores/polyphemus/file.imagemosaic

                      Response

                      200 OK\n
                      "},{"location":"rest/imagemosaic/#updating-an-image-mosaic-contents","title":"Updating an image mosaic contents","text":"

                      Harvest (or reharvest) a single file into the mosaic and update the mosaic index

                      Request

                      curl

                      curl -v -u admin:geoserver -XPOST -H \"Content-type: text/plain\" -d \"file:///path/to/the/file/polyphemus_20130302.nc\" \"http://localhost:8080/geoserver/rest/workspaces/topp/coveragestores/poly-incremental/external.imagemosaic\"

                      Response

                      201 Created\n

                      Harvest (or reharvest) a whole directory into the mosaic and update the mosaic index

                      Request

                      curl

                      curl -v -u admin:geoserver -XPOST -H \"Content-type: text/plain\" -d \"file:///path/to/the/mosaic/folder\" \"http://localhost:8080/geoserver/rest/workspaces/topp/coveragestores/poly-incremental/external.imagemosaic\"

                      Response

                      201 Created\n
                      "},{"location":"rest/imagemosaic/#listing-image-mosaic-details","title":"Listing image mosaic details","text":"

                      Retrieve the image mosaic index structure

                      Request

                      curl

                      curl -v -u admin:geoserver -XGET \"http://localhost:8080/geoserver/rest/workspaces/topp/coveragestores/polyphemus-v1/coverages/NO2/index.xml\"

                      Response

                      <Schema>\n<attributes>\n <Attribute>\n   <name>the_geom</name>\n   <minOccurs>0</minOccurs>\n   <maxOccurs>1</maxOccurs>\n   <nillable>true</nillable>\n   <binding>org.locationtech.jts.geom.Polygon</binding>\n </Attribute>\n <Attribute>\n   <name>location</name>\n   <minOccurs>0</minOccurs>\n   <maxOccurs>1</maxOccurs>\n   <nillable>true</nillable>\n   <binding>java.lang.String</binding>\n </Attribute>\n <Attribute>\n   <name>imageindex</name>\n   <minOccurs>0</minOccurs>\n   <maxOccurs>1</maxOccurs>\n   <nillable>true</nillable>\n   <binding>java.lang.Integer</binding>\n </Attribute>\n <Attribute>\n   <name>time</name>\n   <minOccurs>0</minOccurs>\n   <maxOccurs>1</maxOccurs>\n   <nillable>true</nillable>\n   <binding>java.sql.Timestamp</binding>\n </Attribute>\n <Attribute>\n   <name>elevation</name>\n   <minOccurs>0</minOccurs>\n   <maxOccurs>1</maxOccurs>\n   <nillable>true</nillable>\n   <binding>java.lang.Double</binding>\n </Attribute>\n <Attribute>\n   <name>fileDate</name>\n   <minOccurs>0</minOccurs>\n   <maxOccurs>1</maxOccurs>\n   <nillable>true</nillable>\n   <binding>java.sql.Timestamp</binding>\n </Attribute>\n <Attribute>\n   <name>updated</name>\n   <minOccurs>0</minOccurs>\n   <maxOccurs>1</maxOccurs>\n   <nillable>true</nillable>\n   <binding>java.sql.Timestamp</binding>\n </Attribute>\n</attributes>\n<atom:link xmlns:atom=\"http://www.w3.org/2005/Atom\" rel=\"alternate\" href=\"http://localhost:8080/geoserver/rest/workspaces/topp/coveragestores/polyphemus-v1/coverages/NO2/index/granules.xml\" type=\"application/xml\"/>\n</Schema>\n

                      Retrieve the existing granule information

                      Request

                      curl

                      curl -v -u admin:geoserver -XGET \"http://localhost:8080/geoserver/rest/workspaces/topp/coveragestores/polyphemus-v1/coverages/NO2/index/granules.xml?limit=2\"

                      Response

                      <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<wfs:FeatureCollection xmlns:gf=\"http://www.geoserver.org/rest/granules\" xmlns:ogc=\"http://www.opengis.net/ogc\" xmlns:wfs=\"http://www.opengis.net/wfs\" xmlns:gml=\"http://www.opengis.net/gml\">\n  <gml:boundedBy>\n    <gml:Box srsName=\"http://www.opengis.net/gml/srs/epsg.xml#4326\">\n      <gml:coord>\n        <gml:X>5.0</gml:X>\n        <gml:Y>45.0</gml:Y>\n      </gml:coord>\n      <gml:coord>\n        <gml:X>14.875</gml:X>\n        <gml:Y>50.9375</gml:Y>\n      </gml:coord>\n    </gml:Box>\n  </gml:boundedBy>\n  <gml:featureMember>\n    <gf:NO2 fid=\"NO2.1\">\n      <gf:the_geom>\n        <gml:Polygon>\n          <gml:outerBoundaryIs>\n            <gml:LinearRing>\n              <gml:coordinates>5.0,45.0 5.0,50.9375 14.875,50.9375 14.875,45.0 5.0,45.0</gml:coordinates>\n            </gml:LinearRing>\n          </gml:outerBoundaryIs>\n        </gml:Polygon>\n      </gf:the_geom>\n      <gf:location>polyphemus_20130301.nc</gf:location>\n      <gf:imageindex>336</gf:imageindex>\n      <gf:time>2013-03-01T00:00:00Z</gf:time>\n      <gf:elevation>10.0</gf:elevation>\n      <gf:fileDate>2013-03-01T00:00:00Z</gf:fileDate>\n      <gf:updated>2013-04-11T10:54:31Z</gf:updated>\n    </gf:NO2>\n  </gml:featureMember>\n  <gml:featureMember>\n    <gf:NO2 fid=\"NO2.2\">\n      <gf:the_geom>\n        <gml:Polygon>\n          <gml:outerBoundaryIs>\n            <gml:LinearRing>\n              <gml:coordinates>5.0,45.0 5.0,50.9375 14.875,50.9375 14.875,45.0 5.0,45.0</gml:coordinates>\n            </gml:LinearRing>\n          </gml:outerBoundaryIs>\n        </gml:Polygon>\n      </gf:the_geom>\n      <gf:location>polyphemus_20130301.nc</gf:location>\n      <gf:imageindex>337</gf:imageindex>\n      <gf:time>2013-03-01T00:00:00Z</gf:time>\n      <gf:elevation>35.0</gf:elevation>\n      <gf:fileDate>2013-03-01T00:00:00Z</gf:fileDate>\n      <gf:updated>2013-04-11T10:54:31Z</gf:updated>\n    </gf:NO2>\n  </gml:featureMember>\n</wfs:FeatureCollection>\n
                      "},{"location":"rest/imagemosaic/#removing-image-mosaic-granules","title":"Removing image mosaic granules","text":"

                      Remove all the granules originating from a particular file

                      Request

                      curl

                      curl -v -u admin:geoserver -XDELETE \"http://localhost:8080/geoserver/rest/workspaces/topp/coveragestores/polyphemus-v1/coverages/NO2/index/granules.xml?filter=location='polyphemus_20130301.nc'\"

                      Response

                      200 OK\n
                      "},{"location":"rest/imagemosaic/#uploading-an-empty-mosaic","title":"Uploading an empty mosaic","text":"

                      Upload an archive with the definition of an mosaic, but with no granules

                      Given a empty.zip file containing:

                      • datastore.properties (PostGIS connection parameters)
                      • indexer.xml (Mosaic indexer; note the CanBeEmpty=true parameter)
                      • polyphemus-test.xml (Auxiliary file used by the NetCDF reader to parse schemas and tables)

                      Warning

                      Make sure to update the datastore.properties file with your connection parameters and refresh the ZIP before uploading it.

                      Request

                      curl

                      curl -u admin:geoserver -XPUT -H \"Content-type:application/zip\" --data-binary @empty.zip http://localhost:8080/geoserver/rest/workspaces/topp/coveragestores/empty/file.imagemosaic?configure=none

                      Note

                      The configure=none parameter allows for future configuration after harvesting.

                      Response

                      200 OK\n

                      Configure a coverage on the mosaic

                      Given a coverageconfig.xml:

                      <coverage>\n  <nativeCoverageName>NO2</nativeCoverageName>\n  <name>NO2</name>\n</coverage>\n

                      Request

                      curl

                      curl -v -u admin:geoserver -XPOST -H \"Content-type: text/xml\" -d @\"/path/to/coverageconfig.xml\" \"http://localhost:8080/geoserver/rest/workspaces/topp/coveragestores/empty/coverages\"

                      Note

                      When specifying only the coverage name, the coverage will be automatically configured.

                      Response

                      201 Created\n
                      "},{"location":"rest/layergroups/","title":"Layer groups","text":"

                      The REST API allows you to create and modify layer groups in GeoServer.

                      Note

                      The examples below specify global layer groups, but the examples will work in a workspace-specific construction as well.

                      Note

                      Read the API reference for /layergroups.

                      "},{"location":"rest/layergroups/#creating-a-layer-group","title":"Creating a layer group","text":"

                      Create a new layer group based on already-published layers

                      Given the following content saved as nycLayerGroup.xml:

                      <layerGroup>\n  <name>nyc</name>\n  <layers>\n    <layer>roads</layer>\n    <layer>parks</layer>\n    <layer>buildings</layer>\n  </layers>\n  <styles>\n    <style>roads_style</style>\n    <style>polygon</style>\n    <style>polygon</style>\n  </styles>\n</layerGroup>\n

                      Request

                      curl

                      curl -v -u admin:geoserver -XPOST -d @nycLayerGroup.xml -H \"Content-type: text/xml\" http://localhost:8080/geoserver/rest/layergroups

                      Response

                      201 Created\n

                      Note

                      This layer group can be viewed with a WMS GetMap request:

                      http://localhost:8080/geoserver/wms/reflect?layers=nyc\n
                      "},{"location":"rest/layers/","title":"Layers","text":"

                      The REST API allows you to list, create, upload, update, and delete layers in GeoServer.

                      Note

                      Read the API reference for /layers.

                      "},{"location":"rest/layers/#listing-all-layers","title":"Listing all layers","text":"

                      List all layers on the server, in JSON format:

                      Request

                      curl

                      curl -u admin:geoserver -XGET http://localhost:8080/geoserver/rest/layers.json

                      Response

                      {\n  \"layers\": {\n     \"layer\": [\n         {\n             \"name\": \"giant_polygon\",\n             \"href\": \"http://localhost:8080/geoserver/rest/layers/giant_polygon.json\"\n         },\n         {\n             \"name\": \"poi\",\n             \"href\": \"http://localhost:8080/geoserver/rest/layers/poi.json\"\n         },\n         ...\n      ]\n   }\n}\n

                      List all layers on the server, in XML format:

                      Request

                      curl

                      curl -u admin:geoserver -XGET http://localhost:8080/geoserver/rest/layers.xml

                      Response

                      <layers>\n  <layer>\n    <name>giant_polygon</name>\n    <atom:link xmlns:atom=\"http://www.w3.org/2005/Atom\" rel=\"alternate\" href=\"http://localhost:8080/geoserver/rest/layers/giant_polygon.xml\" type=\"application/xml\"/>\n  </layer>\n  <layer>\n    <name>poi</name>\n    <atom:link xmlns:atom=\"http://www.w3.org/2005/Atom\" rel=\"alternate\" href=\"http://localhost:8080/geoserver/rest/layers/poi.xml\" type=\"application/xml\"/>\n  </layer>\n  ...\n</layers>\n
                      "},{"location":"rest/security/","title":"Security","text":"

                      The REST API allows you to adjust GeoServer security settings.

                      Note

                      Read the API reference for /security.

                      "},{"location":"rest/security/#listing-the-keystore-password","title":"Listing the keystore password","text":"

                      Retrieve the keystore password for the \"root\" account

                      Request

                      curl

                      curl -v -u admin:geoserver -XGET http://localhost:8080/geoserver/rest/security/masterpw.xml

                      "},{"location":"rest/security/#changing-the-keystore-password","title":"Changing the keystore password","text":"

                      Change to a new keystore password

                      Note

                      Requires knowledge of the current keystore password.

                      Given a changes.xml file:

                      <masterPassword>\n   <oldMasterPassword>-\"}3a^Kh</oldMasterPassword>\n   <newMasterPassword>geoserver1</newMasterPassword>\n</masterPassword>\n

                      Request

                      curl

                      curl -v -u admin:geoserver -XPUT -H \"Content-type: text/xml\" -d @change.xml http://localhost:8080/geoserver/rest/security/masterpw.xml

                      Response

                      200 OK\n
                      "},{"location":"rest/security/#listing-the-catalog-mode","title":"Listing the catalog mode","text":"

                      Fetch the current catalog mode

                      Request

                      curl

                      curl -v -u admin:geoserver -XGET http://localhost:8080/geoserver/rest/security/acl/catalog.xml

                      Response

                      <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<catalog>\n    <mode>HIDE</mode>\n</catalog>\n
                      "},{"location":"rest/security/#changing-the-catalog-mode","title":"Changing the catalog mode","text":"

                      Set a new catalog mode

                      Given a newMode.xml file:

                      <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<catalog>\n    <mode>MIXED</mode>\n</catalog>\n

                      Request

                      curl

                      curl -v -u admin:geoserver -XPUT -H \"Content-type: text/xml\" -d @newMode.xml http://localhost:8080/geoserver/rest/security/acl/catalog.xml

                      "},{"location":"rest/security/#listing-access-control-rules","title":"Listing access control rules","text":"

                      Retrieve current list of access control rules

                      Request

                      curl

                      curl -v -u admin:geoserver -XGET http://localhost:8080/geoserver/rest/security/acl/layers.xml

                      Response

                      <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<rules />\n

                      Note

                      The above response shows no rules specified.

                      "},{"location":"rest/security/#changing-access-control-rules","title":"Changing access control rules","text":"

                      Set a new list of access control rules

                      Given a rules.xml file:

                      <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<rules>\n   <rule resource=\"topp.*.r\">ROLE_AUTHORIZED</rule>\n   <rule resource=\"topp.mylayer.w\">ROLE_1,ROLE_2</rule>      \n</rules>\n

                      Request

                      curl

                      curl -v -u admin:geoserver -XPOST -H \"Content-type: text/xml\" -d @rules.xml http://localhost:8080/geoserver/rest/security/acl/layers.xml

                      Response

                      201 Created\n
                      "},{"location":"rest/security/#deleting-access-control-rules","title":"Deleting access control rules","text":"

                      Delete individual access control rule

                      Request

                      curl

                      curl -v -u admin:geoserver -XDELETE http://localhost:8080/geoserver/rest/security/acl/layers/topp.*.r

                      Response

                      200 OK\n
                      "},{"location":"rest/stores/","title":"Stores","text":""},{"location":"rest/stores/#uploading-a-shapefile","title":"Uploading a shapefile","text":"

                      Create a new store \"roads\" by uploading a shapefile \"roads.zip\"

                      Request

                      curl

                      curl -v -u admin:geoserver -XPUT -H \"Content-type: application/zip\" --data-binary @roads.zip http://localhost:8080/geoserver/rest/workspaces/acme/datastores/roads/file.shp

                      Response

                      201 Created\n
                      "},{"location":"rest/stores/#listing-store-details","title":"Listing store details","text":"

                      Retrieve information about a specific store*

                      Request

                      curl

                      curl -v -u admin:geoserver -XGET http://localhost:8080/geoserver/rest/workspaces/acme/datastores/roads.xml

                      python

                      TBD

                      java

                      TBD

                      Response

                      <dataStore>\n  <name>roads</name>\n  <type>Shapefile</type>\n  <enabled>true</enabled>\n  <workspace>\n    <name>acme</name>\n    <atom:link xmlns:atom=\"http://www.w3.org/2005/Atom\" rel=\"alternate\" \n     href=\"http://localhost:8080/geoserver/rest/workspaces/acme.xml\" type=\"application/xml\"/>\n  </workspace>\n  <connectionParameters>\n    <entry key=\"url\">file:/C:/path/to/data_dir/data/acme/roads/</entry>\n    <entry key=\"namespace\">http://acme</entry>\n  </connectionParameters>\n  <__default>false</__default>\n  <featureTypes>\n    <atom:link xmlns:atom=\"http://www.w3.org/2005/Atom\" rel=\"alternate\" \n     href=\"http://localhost:8080/geoserver/rest/workspaces/acme/datastores/roads/featuretypes.xml\" \n     type=\"application/xml\"/>\n  </featureTypes>\n</dataStore>\n

                      Request

                      Note

                      The XML response only provides details about the store itself, so you can use HTML to see the contents of the store.

                      curl -v -u admin:geoserver -XGET \n  http://localhost:8080/geoserver/rest/workspaces/acme/datastores/roads.html\n
                      "},{"location":"rest/stores/#listing-featuretype-details","title":"Listing featuretype details","text":"

                      Note

                      By default when a shapefile is uploaded, a featuretype is automatically created.

                      Request

                      curl

                      curl -v -u admin:geoserver -XGET http://localhost:8080/geoserver/rest/workspaces/acme/datastores/roads/featuretypes/roads.xml

                      python

                      TBD

                      java

                      TBD

                      Response

                      <featureType>\n  <name>roads</name>\n  <nativeName>roads</nativeName>\n  <namespace>\n    <name>acme</name>\n    <atom:link xmlns:atom=\"http://www.w3.org/2005/Atom\" rel=\"alternate\" \n     href=\"http://localhost:8080/geoserver/rest/namespaces/acme.xml\" type=\"application/xml\"/>\n  </namespace>\n  ...\n</featureType>\n
                      "},{"location":"rest/stores/#adding-an-existing-shapefile","title":"Adding an existing shapefile","text":"

                      Publish a shapefile \"rivers.shp\" that already exists on the server without needing to be uploaded

                      Request

                      curl

                      curl -v -u admin:geoserver -XPUT -H \"Content-type: text/plain\" -d \"file:///data/shapefiles/rivers/rivers.shp\" http://localhost:8080/geoserver/rest/workspaces/acme/datastores/rivers/external.shp

                      Note

                      The external.shp part of the request URI indicates that the file is coming from outside the catalog.

                      Response

                      201 Created\n
                      "},{"location":"rest/stores/#adding-a-directory-of-existing-shapefiles","title":"Adding a directory of existing shapefiles","text":"

                      Create a store containing a directory of shapefiles that already exists on the server without needing to be uploaded

                      Request

                      curl

                      curl -v -u admin:geoserver -XPUT -H \"Content-type: text/plain\" -d \"file:///data/shapefiles/\" \"http://localhost:8080/geoserver/rest/workspaces/acme/datastores/shapefiles/external.shp?configure=all\"

                      Note

                      The configure=all query string parameter sets each shapefile in the directory to be loaded and published.

                      Response

                      201 Created\n
                      "},{"location":"rest/stores/#adding-a-postgis-database-store","title":"Adding a PostGIS database store","text":"

                      Add an existing PostGIS database named \"nyc\" as a new store

                      Note

                      This example assumes that a PostGIS database named nyc is present on the local system and is accessible by the user bob.

                      Given the following content saved as nycDataStore.xml:

                      <dataStore> \n  <name>nyc</name>\n  <connectionParameters>\n    <host>localhost</host>\n    <port>5432</port>\n    <database>nyc</database> \n    <user>bob</user>\n    <passwd>postgres</passwd>\n    <dbtype>postgis</dbtype>\n  </connectionParameters>\n</dataStore> \n

                      Request

                      curl

                      curl -v -u admin:geoserver -XPOST -T nycDataStore.xml -H \"Content-type: text/xml\" http://localhost:8080/geoserver/rest/workspaces/acme/datastores

                      Response

                      201 Created\n
                      "},{"location":"rest/stores/#listing-a-postgis-database-store-details","title":"Listing a PostGIS database store details","text":"

                      Retrieve information about a PostGIS store

                      Request

                      curl

                      curl -v -u admin:geoserver -XGET http://localhost:8080/geoserver/rest/workspaces/acme/datastores/nyc.xml

                      Response

                      <dataStore>\n  <name>nyc</name>\n  <type>PostGIS</type>\n  <enabled>true</enabled>\n  <workspace>\n    <name>acme</name>\n    <atom:link xmlns:atom=\"http://www.w3.org/2005/Atom\" rel=\"alternate\" \n     href=\"http://localhost:8080/geoserver/rest/workspaces/acme.xml\" type=\"application/xml\"/>\n  </workspace>\n  <connectionParameters>\n    <entry key=\"port\">5432</entry>\n    <entry key=\"dbtype\">postgis</entry>\n    <entry key=\"host\">localhost</entry>\n    <entry key=\"user\">bob</entry>\n    <entry key=\"database\">nyc</entry>\n    <entry key=\"namespace\">http://acme</entry>\n  </connectionParameters>\n  <__default>false</__default>\n  <featureTypes>\n    <atom:link xmlns:atom=\"http://www.w3.org/2005/Atom\" rel=\"alternate\" \n     href=\"http://localhost:8080/geoserver/rest/workspaces/acme/datastores/nyc/featuretypes.xml\" \n     type=\"application/xml\"/>\n  </featureTypes>\n</dataStore>\n
                      "},{"location":"rest/stores/#publishing-a-table-from-an-existing-postgis-store","title":"Publishing a table from an existing PostGIS store","text":"

                      Publish a new featuretype from a PostGIS store table \"buildings\"

                      Note

                      This example assumes the table has already been created.

                      Request

                      curl

                      curl -v -u admin:geoserver -XPOST -H \"Content-type: text/xml\" -d \"buildings\" http://localhost:8080/geoserver/rest/workspaces/acme/datastores/nyc/featuretypes

                      Note

                      This layer can viewed with a WMS GetMap request:

                      http://localhost:8080/geoserver/wms/reflect?layers=acme:buildings\n
                      "},{"location":"rest/stores/#creating-a-postgis-table","title":"Creating a PostGIS table","text":"

                      Create a new featuretype in GeoServer and simultaneously create a table in PostGIS

                      Given the following content saved as annotations.xml:

                      <featureType>\n  <name>annotations</name>\n  <nativeName>annotations</nativeName>\n  <title>Annotations</title>\n  <srs>EPSG:4326</srs>\n  <attributes>\n    <attribute>\n      <name>the_geom</name>\n      <binding>org.locationtech.jts.geom.Point</binding>\n    </attribute>\n    <attribute>\n      <name>description</name>\n      <binding>java.lang.String</binding>\n    </attribute>\n    <attribute>\n      <name>timestamp</name>\n      <binding>java.util.Date</binding>\n    </attribute>\n  </attributes>\n</featureType>\n

                      Request

                      curl

                      curl -v -u admin:geoserver -XPOST -T annotations.xml -H \"Content-type: text/xml\" http://localhost:8080/geoserver/rest/workspaces/acme/datastores/nyc/featuretypes

                      Note

                      The NYC store must be a PostGIS store for this to succeed.

                      Response

                      201 Created\n

                      A new and empty table named \"annotations\" in the \"nyc\" database will be created as well.

                      "},{"location":"rest/stores/#adding-an-external-wmts-store","title":"Adding an external WMTS Store","text":"

                      Create a new WMTS store \"Basemap-Nat-Geo-Datastore\"

                      Request

                      curl

                      curl -v -u admin:geoserver -XPOST -H \"Content-type: text/xml\" -d \"basemap-nat-geo-datastoreesri-street-maphttps://services.arcgisonline.com/arcgis/rest/services/NatGeo_World_Map/MapServer/WMTS/1.0.0/WMTSCapabilities.xmlWMTS\" http://localhost:8080/geoserver/rest/workspaces/acme/wmtsstores

                      Response

                      201 Created\n
                      "},{"location":"rest/stores/#adding-an-external-wmts-layer","title":"Adding an external WMTS Layer","text":"

                      Publish a new WMTS Layer \"NatGeo_World_Map\" from the WMTS store \"Basemap-Nat-Geo-Datastore\"

                      Request

                      curl

                      curl -v -u admin:geoserver -XPOST -H \"Content-type: text/xml\" -d \"NatGeo_World_Map\" http://localhost:8080/geoserver/rest/workspaces/acme/wmtsstores/Basemap-Nat-Geo-Datastore/layers

                      Response

                      201 Created\n
                      "},{"location":"rest/styles/","title":"Styles","text":"

                      The REST API allows you to list, create, upload, update, and delete styles in GeoServer.

                      Note

                      Read the API reference for /styles.

                      "},{"location":"rest/styles/#listing-all-styles","title":"Listing all styles","text":"

                      List all styles on the server, in JSON format:

                      Request

                      curl

                      curl -u admin:geoserver -XGET http://localhost:8080/geoserver/rest/styles.json

                      Response

                      {\"styles\":{\"style\":[{\"name\":\"burg\",\"href\":\"http:\\/\\/localhost:8080\\/geoserver\\/rest\\/styles\\/burg.json\"},{\"name\":\"capitals\",\"href\":\"http:\\/\\/localhost:8080\\/geoserver\\/rest\\/styles\\/capitals.json\"},{\"name\":\"dem\",\"href\":\"http:\\/\\/localhost:8080\\/geoserver\\/rest\\/styles\\/dem.json\"},{\"name\":\"generic\",\"href\":\"http:\\/\\/localhost:8080\\/geoserver\\/rest\\/styles\\/generic.json\"},{\"name\":\"giant_polygon\",\"href\":\"http:\\/\\/localhost:8080\\/geoserver\\/rest\\/styles\\/giant_polygon.json\"},{\"name\":\"grass\",\"href\":\"http:\\/\\/localhost:8080\\/geoserver\\/rest\\/styles\\/grass.json\"},{\"name\":\"green\",\"href\":\"http:\\/\\/localhost:8080\\/geoserver\\/rest\\/styles\\/green.json\"},{\"name\":\"line\",\"href\":\"http:\\/\\/localhost:8080\\/geoserver\\/rest\\/styles\\/line.json\"},{\"name\":\"poi\",\"href\":\"http:\\/\\/localhost:8080\\/geoserver\\/rest\\/styles\\/poi.json\"},{\"name\":\"point\",\"href\":\"http:\\/\\/localhost:8080\\/geoserver\\/rest\\/styles\\/point.json\"},{\"name\":\"polygon\",\"href\":\"http:\\/\\/localhost:8080\\/geoserver\\/rest\\/styles\\/polygon.json\"},{\"name\":\"poly_landmarks\",\"href\":\"http:\\/\\/localhost:8080\\/geoserver\\/rest\\/styles\\/poly_landmarks.json\"},{\"name\":\"pophatch\",\"href\":\"http:\\/\\/localhost:8080\\/geoserver\\/rest\\/styles\\/pophatch.json\"},{\"name\":\"population\",\"href\":\"http:\\/\\/localhost:8080\\/geoserver\\/rest\\/styles\\/population.json\"},{\"name\":\"rain\",\"href\":\"http:\\/\\/localhost:8080\\/geoserver\\/rest\\/styles\\/rain.json\"},{\"name\":\"raster\",\"href\":\"http:\\/\\/localhost:8080\\/geoserver\\/rest\\/styles\\/raster.json\"},{\"name\":\"restricted\",\"href\":\"http:\\/\\/localhost:8080\\/geoserver\\/rest\\/styles\\/restricted.json\"},{\"name\":\"simple_roads\",\"href\":\"http:\\/\\/localhost:8080\\/geoserver\\/rest\\/styles\\/simple_roads.json\"},{\"name\":\"simple_streams\",\"href\":\"http:\\/\\/localhost:8080\\/geoserver\\/rest\\/styles\\/simple_streams.json\"},{\"name\":\"tiger_roads\",\"href\":\"http:\\/\\/localhost:8080\\/geoserver\\/rest\\/styles\\/tiger_roads.json\"}]}}\n

                      List all styles in a workspace, in XML format:

                      Request

                      curl

                      curl -u admin:geoserver -XGET http://localhost:8080/geoserver/rest/cite/styles.xml

                      Response

                      <styles>\n  <style>\n    <name>citerain</name>\n    <atom:link xmlns:atom=\"http://www.w3.org/2005/Atom\" rel=\"alternate\" href=\"http://localhost:8080/geoserver/rest/workspaces/cite/styles/citerain.xml\" type=\"application/xml\"/>\n  </style>\n</styles>\n
                      "},{"location":"rest/styles/#retrieve-a-style","title":"Retrieve a style","text":"

                      Download the actual style code for a style:

                      Request

                      curl

                      curl -u admin:geoserver -XGET http://localhost:8080/geoserver/rest/styles/rain.sld

                      Response

                      <StyledLayerDescriptor version=\"1.0.0\" xmlns=\"http://www.opengis.net/sld\" xmlns:ogc=\"http://www.opengis.net/ogc\"\n  xmlns:xlink=\"http://www.w3.org/1999/xlink\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\"\n  xsi:schemaLocation=\"http://www.opengis.net/sld http://schemas.opengis.net/sld/1.0.0/StyledLayerDescriptor.xsd\">\n  <NamedLayer>\n    <Name>rain</Name>\n    <UserStyle>\n      <Name>rain</Name>\n      <Title>Rain distribution</Title>\n      <FeatureTypeStyle>\n        <Rule>\n          <RasterSymbolizer>\n            <Opacity>1.0</Opacity>\n            <ColorMap>\n              <ColorMapEntry color=\"#FF0000\" quantity=\"0\" />\n              <ColorMapEntry color=\"#FFFFFF\" quantity=\"100\"/>\n              <ColorMapEntry color=\"#00FF00\" quantity=\"2000\"/>\n              <ColorMapEntry color=\"#0000FF\" quantity=\"5000\"/>\n            </ColorMap>\n          </RasterSymbolizer>\n        </Rule>\n      </FeatureTypeStyle>\n    </UserStyle>\n  </NamedLayer>\n</StyledLayerDescriptor>\n
                      "},{"location":"rest/styles/#creating-a-style","title":"Creating a style","text":"

                      You can create a new style on the server in two ways. In the first way, the creation is done in two steps: the style entry is created in the catalog, and then the style content is uploaded. The second way can add the style to the server in a single step by uploading a ZIP containing the style content:

                      Create a new style in two steps:

                      Request

                      curl

                      curl -v -u admin:geoserver -XPOST -H \"Content-type: text/xml\" -d \"\" http://localhost:8080/geoserver/rest/styles

                      Response

                      201 Created\n

                      Request

                      curl

                      curl -v -u admin:geoserver -XPUT -H \"Content-type: application/vnd.ogc.sld+xml\" -d @roads.sld http://localhost:8080/geoserver/rest/styles/roads_style

                      Response

                      200 OK\n

                      Create a new style in a single step:

                      Request

                      curl

                      curl -u admin:geoserver -XPOST -H \"Content-type: application/zip\" --data-binary @roads_style.zip http://localhost:8080/geoserver/rest/styles

                      Response

                      201 Created\n

                      Create a new style in a single step using CSS:

                      Request

                      curl

                      curl -u admin:geoserver -XPOST -H \"Content-type: application/vnd.geoserver.geocss+css\" -d '* { stroke: red; }' http://localhost:8080/geoserver/rest/styles

                      Response

                      201 Created\n

                      This example will create a new style on the server and populate it the contents of a local SLD file and related images provided in a SLD package. A SLD package is a zip file containing the SLD style and related image files used in the SLD.

                      The following creates a new style named roads_style.

                      Each code block below contains a single command that may be extended over multiple lines.

                      Request

                      curl

                      curl -u admin:geoserver -XPOST -H \"Content-type: application/zip\" --data-binary @roads_style.zip http://localhost:8080/geoserver/rest/styles

                      Response

                      201 OK\n

                      The SLD itself can be downloaded through a a GET request:

                      curl

                      curl -v -u admin:geoserver -XGET http://localhost:8080/geoserver/rest/styles/roads_style.sld

                      "},{"location":"rest/styles/#changing-an-existing-style","title":"Changing an existing style","text":"

                      Edit/reupload the content of an existing style on the server:

                      Request

                      curl

                      curl -u admin:geoserver -XPUT -H \"Content-type: application/vnd.ogc.sld+xml\" -d @roads.sld http://localhost:8080/geoserver/rest/styles/roads_style

                      Response

                      200 OK\n

                      Edit/reupload the content of an existing style on the server when the style is in a workspace:

                      Request

                      curl

                      curl -u admin:geoserver -XPUT -H \"Content-type: application/vnd.ogc.sld+xml\" -d @roads.sld http://localhost:8080/geoserver/rest/workspaces/cite/styles/roads_style

                      Response

                      200 OK\n

                      Edit/reupload the content of an existing style on the server using a ZIP file containing a shapefile:

                      Request

                      curl

                      curl -u admin:geoserver -XPUT -H \"Content-type: application/zip\" --data-binary @roads_style.zip http://localhost:8080/geoserver/rest/styles/roads_style.zip

                      Response

                      200 OK\n
                      "},{"location":"rest/styles/#deleting-a-style","title":"Deleting a style","text":"

                      Remove a style entry from the server, retaining the orphaned style content:

                      Request

                      curl

                      curl -u admin:geoserver -XDELETE http://localhost:8080/geoserver/rest/styles/zoning

                      Response

                      200 OK\n

                      Remove a style entry from the server, deleting the orphaned style content:

                      Request

                      curl

                      curl -u admin:geoserver -XDELETE http://localhost:8080/geoserver/rest/styles/zoning?purge=true

                      Response

                      200 OK\n
                      "},{"location":"rest/workspaces/","title":"Workspaces","text":"

                      The REST API allows you to create and manage workspaces in GeoServer.

                      Note

                      Read the API reference for /workspaces.

                      "},{"location":"rest/workspaces/#adding-a-new-workspace","title":"Adding a new workspace","text":"

                      Creates a new workspace named \"acme\" with a POST request

                      Request

                      curl

                      curl -v -u admin:geoserver -XPOST -H \"Content-type: text/xml\" -d \"acme\" http://localhost:8080/geoserver/rest/workspaces

                      python

                      TBD

                      java

                      TBD

                      Response

                      201 Created\n

                      Note

                      The Location response header specifies the location (URI) of the newly created workspace.

                      "},{"location":"rest/workspaces/#listing-workspace-details","title":"Listing workspace details","text":"

                      Retrieve information about a specific workspace

                      Request

                      curl

                      curl -v -u admin:geoserver -XGET -H \"Accept: text/xml\" http://localhost:8080/geoserver/rest/workspaces/acme

                      Note

                      The Accept header is optional.

                      python

                      TBD

                      java

                      TBD

                      Response

                      <workspace>\n  <name>acme</name>\n  <dataStores>\n    <atom:link xmlns:atom=\"http://www.w3.org/2005/Atom\" rel=\"alternate\" \n     href=\"http://localhost:8080/geoserver/rest/workspaces/acme/datastores.xml\" \n     type=\"application/xml\"/>\n  </dataStores>\n  <coverageStores>\n    <atom:link xmlns:atom=\"http://www.w3.org/2005/Atom\" rel=\"alternate\" \n     href=\"http://localhost:8080/geoserver/rest/workspaces/acme/coveragestores.xml\" \n     type=\"application/xml\"/>\n  </coverageStores>\n  <wmsStores>\n    <atom:link xmlns:atom=\"http://www.w3.org/2005/Atom\" rel=\"alternate\" \n     href=\"http://localhost:8080/geoserver/rest/workspaces/acme/wmsstores.xml\" \n     type=\"application/xml\"/>\n  </wmsStores>\n</workspace>\n

                      This shows that the workspace can contain \"dataStores\" (for vector data), \"coverageStores\" (for raster data), and \"wmsStores\" (for cascaded WMS servers).

                      "},{"location":"rest/api/","title":"REST configuration API reference","text":"

                      This section describes the GeoServer REST configuration API.

                      Note

                      You may also wish to review the hand-written Open API REST documentation. This documentation is not auto-generated and may not exactly match the latest GeoServer. Please treat this resource as documentation only as this is not suitable for client generation.

                      • API details
                      • Global settings
                      • Workspaces
                      • Namespaces
                      • Data stores
                      • Feature types
                      • Coverage stores
                      • Coverages
                      • Styles
                      • Layers
                      • Logging settings
                      • Layer groups
                      • Fonts
                      • Freemarker templates
                      • OWS Services
                      • Reloading configuration
                      • Resource reset
                      • Manifests
                      • Keystore Password
                      • Self admin
                      • Access Control
                      • Users/Groups and Roles
                      • Resources
                      "},{"location":"rest/api/accesscontrol/","title":"Access Control","text":""},{"location":"rest/api/accesscontrol/#securityaclcatalogformat","title":"/security/acl/catalog.<format>","text":"

                      Fetches the catalog mode and allows to change the catalog mode. The mode must be one of

                      • HIDE
                      • MIXED
                      • CHALLENGE
                      Method Action Status code Formats Default Format GET Fetch the catalog mode 200,403 XML, JSON PUT Set the catalog mode 200,403,404,422 XML, JSON

                      Formats:

                      XML

                      <catalog>\n  <mode>HIDE</mode>\n</catalog>\n

                      JSON

                      {\"mode\":\"HIDE\" }\n
                      "},{"location":"rest/api/accesscontrol/#exceptions","title":"Exceptions","text":"Exception Status code No administrative privileges 403 Malformed request 404 Invalid catalog mode 422"},{"location":"rest/api/accesscontrol/#securityacllayersformat","title":"/security/acl/layers.<format>","text":""},{"location":"rest/api/accesscontrol/#securityaclservicesformat","title":"/security/acl/services.<format>","text":""},{"location":"rest/api/accesscontrol/#securityaclrestformat","title":"/security/acl/rest.<format>","text":"

                      API for administering access control for

                      • Layers
                      • Services
                      • The REST API
                      Method Action Status code Formats Default Format GET Fetch all rules 200,403 XML, JSON POST Add a set of rules 200,403,409 XML, JSON PUT Modify a set of rules 200,403,409 XML, JSON DELETE Delete a specific rule 200,404,409 XML, JSON

                      Format for DELETE:

                      The specified rule has to be the last part in the URI:

                      /security/acl/layers/*.*.r\n

                      Note

                      Slashes (\"/\") in a rule name must be encoded with %2F. The REST rule /;GET must be encoded to /security/acl/rest/%2F;GET

                      Formats for GET,POST and PUT:

                      XML

                      <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<rules>\n   <rule resource=\"*.*.r\">*</rule>\n   <rule resource=\"myworkspace.*.w\">ROLE_1,ROLE_2</rule>\n</rules> \n

                      JSON :

                      {\n\"*.*.r\": \"*\",\n\"myworkspace\".*.w\": \"ROLE_1,ROLE_2\"\n}\n

                      The resource attribute specifies a rule. There are three different formats.

                      • For layers: ... The asterisk is a wild card for and . is one of r (read), w (write) or a (administer).
                      • For services: .. The asterisk is a wild card wild card for and . Examples:
                        • wfs.GetFeature
                        • wfs.GetTransaction
                        • wfs.*
                      • For REST: ;. Examples:
                        • /**;GET
                        • /**;POST,DELETE,PUT

                        The content of a rule element is a comma separated list of roles or the asterisk.

                        "},{"location":"rest/api/accesscontrol/#exceptions_1","title":"Exceptions","text":"Exception Status code No administrative privileges 403 POST, adding an already existing rule 409 PUT, modifying a non existing rule 409 DELETE, Deleting a non existing rule 409 Invalid rule specification 422

                        Note

                        When adding a set of rules and only one role does already exist, the whole request is aborted. When modifying a set of rules and only one role does not exist, the whole request is aborted too.

                        "},{"location":"rest/api/coverages/","title":"Coverages","text":"

                        A coverage is a raster data set which originates from a coverage store.

                        Todo

                        JC: \"The second level headings [don't] work so well for the longer paths - maybe another heading format?\"

                        "},{"location":"rest/api/coverages/#workspaceswscoveragestorescscoveragesformat","title":"/workspaces/<ws>/coveragestores/<cs>/coverages[.<format>]","text":"

                        Controls all coverages in a given coverage store and workspace.

                        Method Action Status code Formats Default Format GET List all coverages in coverage store cs 200 HTML, XML, JSON HTML POST Create a new coverage 201 with Location header XML, JSON PUT 405 DELETE 405"},{"location":"rest/api/coverages/#workspaceswscoveragestorescscoveragescformat","title":"/workspaces/<ws>/coveragestores/<cs>/coverages/<c>[.<format>]","text":"

                        Controls a particular coverage in a given coverage store and workspace.

                        Method Action Status code Formats Default Format Parameters GET Return coverage c 200 HTML, XML, JSON HTML quietOnNotFound POST 405 PUT Modify coverage c 200 XML,JSON DELETE Delete coverage c 200 recurse"},{"location":"rest/api/coverages/#exceptions","title":"Exceptions","text":"Exception Status code GET for a coverage that does not exist 404 PUT that changes name of coverage 403 PUT that changes coverage store of coverage 403"},{"location":"rest/api/coverages/#parameters","title":"Parameters","text":""},{"location":"rest/api/coverages/#rest_api_coverages_recurse","title":"recurse","text":"

                        The recurse parameter recursively deletes all layers referenced by the specified coverage. Permitted values for this parameter are \"true\" or \"false\". The default value is \"false\".

                        "},{"location":"rest/api/coverages/#rest_api_coverages_quietOnNotFound","title":"quietOnNotFound","text":"

                        The quietOnNotFound parameter avoids to log an Exception when the coverage is not present. Note that 404 status code will be returned anyway.

                        "},{"location":"rest/api/coverages/#structured-coverages","title":"Structured coverages","text":"

                        Structured coverages are the ones whose content is made of granules, normally associated to attributes, often used to represent time, elevation and other custom dimensions attached to the granules themselves. Image mosaic is an example of a writable structured coverage reader, in which each of the mosaic granules is associated with attributes. NetCDF is an example of a read only one, in which the multidimensional grid contained in the file is exposed as a set of 2D slices, each associated with a different set of variable values.

                        The following API applies exclusively to structured coverage readers.

                        "},{"location":"rest/api/coverages/#workspaceswscoveragestorescscoveragescoverageindexformat","title":"/workspaces/<ws>/coveragestores/<cs>/coverages/<coverage>/index[.<format>]","text":"

                        Declares the set of attributes associated to the specified coverage, their name, type and min/max occurrences.

                        Method Action Status code Formats Default Format Parameters GET Returns the attributes, their names and their types 200 XML, JSON XML POST 405 PUT 405 DELETE 405"},{"location":"rest/api/coverages/#workspaceswscoveragestorescscoveragescoverageindexgranulesformat","title":"/workspaces/<ws>/coveragestores/<cs>/coverages/<coverage>/index/granules.<format>","text":"

                        Returns the full list of granules, each with its attributes vales and geometry, and allows to selectively remove them

                        Method Action Status code Formats Default Format Parameters GET Returns the list of granules and their attributes, either in GML (when XML is used) or GeoJSON (when JSON is used) 200 XML, JSON XML offset, limit, filter POST 405 PUT 405 DELETE Deletes the granules (all, or just the ones selected via the filter parameter) 200 filter"},{"location":"rest/api/coverages/#parameters_1","title":"Parameters","text":""},{"location":"rest/api/coverages/#rest_api_coverages_offset","title":"offset","text":"

                        The offset parameter instructs GeoServer to skip the specified number of first granules when returning the data.

                        "},{"location":"rest/api/coverages/#rest_api_coverages_limit","title":"limit","text":"

                        The limit parameter instructs GeoServer to return at most the specified number of granules when returning the data.

                        "},{"location":"rest/api/coverages/#rest_api_coverages_filter","title":"filter","text":"

                        The filter parameter is a CQL filter that allows to select which granules will be returned based on their attribute values.

                        "},{"location":"rest/api/coverages/#workspaceswscoveragestorescscoveragesmosaicindexgranulesgranuleidformat","title":"/workspaces/<ws>/coveragestores/<cs>/coverages/<mosaic>/index/granules/<granuleId>.<format>","text":"

                        Returns a single granule and allows for its removal.

                        Method Action Status code Formats Default Format Parameters GET Returns the specified of granules and its attributes, either in GML (when XML is used) or GeoJSON (when JSON is used) 200 XML, JSON XML quietOnNotFound POST 405 PUT 405 DELETE Deletes the granule 200"},{"location":"rest/api/coverages/#exceptions_1","title":"Exceptions","text":"Exception Status code GET for a granule that does not exist 404"},{"location":"rest/api/coverages/#parameters_2","title":"Parameters","text":""},{"location":"rest/api/coverages/#rest_api_structuredcoverages_quietOnNotFound","title":"quietOnNotFound","text":"

                        The quietOnNotFound parameter avoids to log an Exception when the granule is not present. Note that 404 status code will be returned anyway.

                        "},{"location":"rest/api/coveragestores/","title":"Coverage stores","text":"

                        A coverage store contains raster format spatial data.

                        "},{"location":"rest/api/coveragestores/#workspaceswscoveragestoresformat","title":"/workspaces/<ws>/coveragestores[.<format>]","text":"

                        Controls all coverage stores in a given workspace.

                        Method Action Status code Formats Default Format GET List all coverage stores in workspace ws 200 HTML, XML, JSON HTML POST Create a new coverage store 201 with Location header XML, JSON PUT 405 DELETE 405"},{"location":"rest/api/coveragestores/#workspaceswscoveragestorescsformat","title":"/workspaces/<ws>/coveragestores/<cs>[.<format>]","text":"

                        Controls a particular coverage store in a given workspace.

                        Method Action Status code Formats Default Format Parameters GET Return coverage store cs 200 HTML, XML, JSON HTML quietOnNotFound POST 405 PUT Modify coverage store cs DELETE Delete coverage store cs recurse, purge"},{"location":"rest/api/coveragestores/#exceptions","title":"Exceptions","text":"Exception Status code GET for a coverage store that does not exist 404 PUT that changes name of coverage store 403 PUT that changes workspace of coverage store 403 DELETE against a coverage store that contains configured coverage 403"},{"location":"rest/api/coveragestores/#parameters","title":"Parameters","text":""},{"location":"rest/api/coveragestores/#rest_api_coveragestores_recurse","title":"recurse","text":"

                        The recurse parameter recursively deletes all layers referenced by the coverage store. Allowed values for this parameter are \"true\" or \"false\". The default value is \"false\".

                        "},{"location":"rest/api/coveragestores/#rest_api_coveragestores_purge","title":"purge","text":"

                        The purge parameter is used to customize the delete of files on disk (in case the underlying reader implements a delete method). It can take one of the three values:

                        • none-(Default) Do not delete any store's file from disk.
                        • metadata-Delete only auxiliary files and metadata. It's recommended when data files (such as granules) should not be deleted from disk.
                        • all-Purge everything related to that store (metadata and granules).
                        "},{"location":"rest/api/coveragestores/#rest_api_coveragestores_quietOnNotFound","title":"quietOnNotFound","text":"

                        The quietOnNotFound parameter avoids to log an Exception when the coverage store is not present. Note that 404 status code will be returned anyway.

                        "},{"location":"rest/api/coveragestores/#workspaceswscoveragestorescsfileextension","title":"/workspaces/<ws>/coveragestores/<cs>/file[.<extension>]","text":"

                        This end point allows a file containing spatial data to be added (via a POST or PUT) into an existing coverage store, or will create a new coverage store if it doesn't already exist. In case of coverage stores containing multiple coverages (e.g., mosaic of NetCDF files) all the coverages will be configured unless configure=false is specified as a parameter.

                        Method Action Status code Formats Default Format Parameters GET Deprecated. Get the underlying files for the coverage store as a zip file with MIME type application/zip. 200 POST If the coverage store is a simple one (e.g. GeoTiff) it will return a 405, if the coverage store is a structured one (e.g., mosaic) it will harvest the specified files into it, which in turn will integrate the files into the store. Harvest meaning is store dependent, for mosaic the new files will be added as new granules of the mosaic, and existing files will get their attribute updated, other stores might have a different behavior. 405 if the coverage store is a simple one, 200 if structured and the harvest operation succeeded recalculate, filename PUT Creates or overwrites the files for coverage store cs 200 See note below configure, coverageName DELETE 405"},{"location":"rest/api/coveragestores/#rest_api_coveragestores_file_put","title":"coveragestores file PUT","text":"

                        A file can be PUT to a coverage store as a standalone or zipped archive file. Standalone files are only suitable for coverage stores that work with a single file such as GeoTIFF store. Coverage stores that work with multiple files, such as the ImageMosaic store, must be sent as a zip archive.

                        When uploading a standalone file, set the Content-type appropriately based on the file type. If you are loading a zip archive, set the Content-type to application/zip.

                        "},{"location":"rest/api/coveragestores/#exceptions_1","title":"Exceptions","text":"Exception Status code GET for a data store that does not exist 404 GET for a data store that is not file based 404"},{"location":"rest/api/coveragestores/#parameters_1","title":"Parameters","text":""},{"location":"rest/api/coveragestores/#extension","title":"extension","text":"

                        The extension parameter specifies the type of coverage store. The following extensions are supported:

                        Extension Coverage store geotiff GeoTIFF worldimage Georeferenced image (JPEG, PNG, TIFF) imagemosaic Image mosaic"},{"location":"rest/api/coveragestores/#rest_api_coveragestores_configure","title":"configure","text":"

                        The configure parameter controls how the coverage store is configured upon file upload. It can take one of the three values:

                        • first---(Default) Only setup the first feature type available in the coverage store.
                        • none---Do not configure any feature types.
                        • all---Configure all feature types.
                        "},{"location":"rest/api/coveragestores/#rest_api_coveragestores_coveragename","title":"coverageName","text":"

                        The coverageName parameter specifies the name of the coverage within the coverage store. This parameter is only relevant if the configure parameter is not equal to \"none\". If not specified the resulting coverage will receive the same name as its containing coverage store.

                        Note

                        At present a one-to-one relationship exists between a coverage store and a coverage. However, there are plans to support multidimensional coverages, so this parameter may change.

                        "},{"location":"rest/api/coveragestores/#rest_api_coveragestores_recalculate","title":"recalculate","text":"

                        The recalculate parameter specifies whether to recalculate any bounding boxes for a coverage. Some properties of coverages are automatically recalculated when necessary. In particular, the native bounding box is recalculated when the projection or projection policy is changed. The lat/long bounding box is recalculated when the native bounding box is recalculated or when a new native bounding box is explicitly provided in the request. (The native and lat/long bounding boxes are not automatically recalculated when they are explicitly included in the request.) In addition, the client may explicitly request a fixed set of fields to calculate by including a comma-separated list of their names in the recalculate parameter. For example:

                        • recalculate= (empty parameter)---Do not calculate any fields, regardless of the projection, projection policy, etc. This might be useful to avoid slow recalculation when operating against large datasets.
                        • recalculate=nativebbox---Recalculate the native bounding box, but do not recalculate the lat/long bounding box.
                        • recalculate=nativebbox,latlonbbox---Recalculate both the native bounding box and the lat/long bounding box.
                        "},{"location":"rest/api/coveragestores/#rest_api_coveragestores_filename","title":"filename","text":"

                        The filename parameter specifies the target file name for a file that needs to harvested as part of a mosaic. This is important to avoid clashes and to make sure the right dimension values are available in the name for multidimensional mosaics to work.

                        • filename=`NCOM_wattemp_000_20081102T0000000_12.tiff` Set the uploaded file name toNCOM_wattemp_000_20081102T0000000_12.tiff``
                        "},{"location":"rest/api/datastores/","title":"Data stores","text":"

                        A data store contains vector format spatial data. It can be a file (such as a shapefile), a database (such as PostGIS), or a server (such as a remote Web Feature Service).

                        "},{"location":"rest/api/datastores/#workspaceswsdatastoresformat","title":"/workspaces/<ws>/datastores[.<format>]","text":"

                        Controls all data stores in a given workspace.

                        Method Action Status code Formats Default Format GET List all data stores in workspace ws 200 HTML, XML, JSON HTML POST Create a new data store 201 with Location header XML, JSON PUT 405 DELETE 405"},{"location":"rest/api/datastores/#workspaceswsdatastoresdsformat","title":"/workspaces/<ws>/datastores/<ds>[.<format>]","text":"

                        Controls a particular data store in a given workspace.

                        Method Action Status code Formats Default Format Parameters GET Return data store ds 200 HTML, XML, JSON HTML quietOnNotFound POST 405 PUT Modify data store ds DELETE Delete data store ds recurse"},{"location":"rest/api/datastores/#exceptions","title":"Exceptions","text":"Exception Status code GET for a data store that does not exist 404 PUT that changes name of data store 403 PUT that changes workspace of data store 403 DELETE against a data store that contains configured feature types 403"},{"location":"rest/api/datastores/#parameters","title":"Parameters","text":""},{"location":"rest/api/datastores/#rest_api_datastores_recurse","title":"recurse","text":"

                        The recurse parameter recursively deletes all layers referenced by the specified data store. Allowed values for this parameter are \"true\" or \"false\". The default value is \"false\".

                        "},{"location":"rest/api/datastores/#rest_api_datastores_quietOnNotFound","title":"quietOnNotFound","text":"

                        The quietOnNotFound parameter avoids to log an Exception when the data store is not present. Note that 404 status code will be returned anyway.

                        "},{"location":"rest/api/datastores/#workspaceswsdatastoresdsfileurlexternalextension","title":"/workspaces/<ws>/datastores/<ds>/[file|url|external][.<extension>]","text":"

                        These endpoints (file, url, and external) allow a file containing either spatial data or a mapping configuration (in case an app-schema data store is targeted), to be added (via a PUT request) into an existing data store, or will create a new data store if it doesn't already exist. The three endpoints are used to specify the method that is used to upload the file:

                        • file---Uploads a file from a local source. The body of the request is the file itself.
                        • url---Uploads a file from an remote source. The body of the request is a URL pointing to the file to upload. This URL must be visible from the server.
                        • external---Uses an existing file on the server. The body of the request is the absolute path to the existing file.
                        Method Action Status code Formats Default Format Parameters GET Deprecated. Retrieve the underlying files for the data store as a zip file with MIME type application/zip 200 POST 405 PUT Uploads files to the data store ds, creating it if necessary 200 See note below configure, target, update, charset DELETE 405"},{"location":"rest/api/datastores/#exceptions_1","title":"Exceptions","text":"Exception Status code GET for a data store that does not exist 404 GET for a data store that is not file based 404"},{"location":"rest/api/datastores/#parameters_1","title":"Parameters","text":""},{"location":"rest/api/datastores/#rest_api_datastores_extension","title":"extension","text":"

                        The extension parameter specifies the type of data being uploaded. The following extensions are supported:

                        Extension Datastore shp Shapefile properties Property file h2 H2 Database appschema App-schema mapping configuration"},{"location":"rest/api/datastores/#rest_api_datastores_file_put","title":"File PUT","text":"

                        A file can be PUT to a data store as a standalone or zipped archive file. Standalone files are only suitable for data stores that work with a single file such as a GML store. Data stores that work with multiple files, such as the shapefile store, must be sent as a zip archive.

                        When uploading a standalone file, set the Content-type appropriately based on the file type. If you are loading a zip archive, set the Content-type to application/zip.

                        "},{"location":"rest/api/datastores/#rest_api_datastores_file_put_appschema","title":"file PUT Application Schema","text":"

                        The app-schema mapping configuration can either be uploaded as a single file, or split in multiple files for reusability and/or mapping constraints (e.g. multiple mappings of the same feature type are needed). If multiple mapping files are uploaded as a zip archive, the extension of the main mapping file (the one including the others via the <includedTypes> tag) must be .appschema, otherwise it will not be recognized as the data store's primary file and publishing will fail.

                        The application schemas (XSD files) required to define the mapping can be added to the zip archive and uploaded along with the mapping configuration. All files contained in the archive are uploaded to the same folder, so the path to the secondary mapping files and the application schemas, as specified in the main mapping file, is simply the file name of the included resource.

                        "},{"location":"rest/api/datastores/#rest_api_datastores_configure","title":"configure","text":"

                        The configure parameter controls how the data store is configured upon file upload. It can take one of the three values:

                        • first---(Default) Only setup the first feature type available in the data store.
                        • none---Do not configure any feature types.
                        • all---Configure all feature types.

                        Note

                        When uploading an app-schema mapping configuration, only the feature types mapped in the main mapping file are considered to be top level features and will be automatically configured when configure=all or configure=first is specified.

                        "},{"location":"rest/api/datastores/#rest_api_datastores_target","title":"target","text":"

                        The target parameter determines what format or storage engine will be used when a new data store is created on the server for uploaded data. When importing data into an existing data store, it is ignored. The allowed values for this parameter are the same as for the extension parameter, except for appschema, which doesn't make sense in this context.

                        "},{"location":"rest/api/datastores/#rest_api_datastores_update","title":"update","text":"

                        The update parameter controls how existing data is handled when the file is PUT into a data store that already exists and already contains a schema that matches the content of the file. The parameter accepts one of the following values:

                        • append---Data being uploaded is appended to the existing data. This is the default.
                        • overwrite---Data being uploaded replaces any existing data.

                        The parameter is ignored for app-schema data stores, which are read-only.

                        "},{"location":"rest/api/datastores/#rest_api_datastores_charset","title":"charset","text":"

                        The charset parameter specifies the character encoding of the file being uploaded (such as \"ISO-8559-1\").

                        "},{"location":"rest/api/details/","title":"API details","text":"

                        This page contains information on the REST API architecture.

                        "},{"location":"rest/api/details/#authentication","title":"Authentication","text":"

                        REST requires that the client be authenticated. By default, the method of authentication used is Basic authentication. See the Security section for how to change the authentication method.

                        "},{"location":"rest/api/details/#status-codes","title":"Status codes","text":"

                        An HTTP request uses a status code to relay the outcome of the request to the client. Different status codes are used for various purposes throughout this document. These codes are described in detail by the HTTP specification.

                        The most common status codes are listed below, along with their descriptions:

                        Status code Description Notes 200 OK The request was successful 201 Created A new resource was successfully created, such as a new feature type or data store 403 Forbidden Often denotes a permissions mismatch 404 Not Found Endpoint or resource was not at the indicated location 405 Method Not Allowed Often denotes an endpoint accessed with an incorrect operation (for example, a GET request where a PUT/POST is indicated) 500 Internal Server Error Often denotes a syntax error in the request"},{"location":"rest/api/details/#formats-and-representations","title":"Formats and representations","text":"

                        A format specifies how a particular resource should be represented. A format is used:

                        • In an operation to specify what representation should be returned to the client
                        • In a POST or PUT operation to specify the representation being sent to the server

                        In a GET operation the format can be specified in two ways.

                        There are two ways to specify the format for a GET operation. The first option uses the Accept header. For example, with the header set to \"Accept: text/xml\" the resource would be returned as XML. The second option of setting the format is via a file extension. For example, given a resource foo, to request a representation of foo as XML, the request URI would end with /foo.xml. To request a representation as JSON, the request URI would end with /foo.json. When no format is specified the server will use its own internal format, usually HTML. When the response format is specified both by the header and by the extension, the format specified by the extension takes precedence.

                        In a POST or PUT operation, the format of content being sent to the server is specified with the Content-type header. For example, to send a representation in XML, use \"Content-type: text/xml\" or \"Content-type: application/xml\". As with GET requests, the representation of the content returned from the server is specified by the Accept header or by the format.

                        The following table defines the Content-type values for each format:

                        Format Content-type XML application/xml JSON application/json HTML application/html SLD application/vnd.ogc.sld+xml ZIP application/zip"},{"location":"rest/api/featuretypes/","title":"Feature types","text":"

                        A feature type is a vector based spatial resource or data set that originates from a data store. In some cases, such as with a shapefile, a feature type has a one-to-one relationship with its data store. In other cases, such as PostGIS, the relationship of feature type to data store is many-to-one, feature types corresponding to a table in the database.

                        "},{"location":"rest/api/featuretypes/#workspaceswsdatastoresdsfeaturetypesformat","title":"/workspaces/<ws>/datastores/<ds>/featuretypes[.<format>]","text":"

                        Controls all feature types in a given data store / workspace.

                        Method Action Status code Formats Default Format Parameters GET List all feature types in data store ds 200 HTML, XML, JSON HTML list POST Create a new feature type, see note below 201 with Location header XML, JSON PUT 405 DELETE 405"},{"location":"rest/api/featuretypes/#rest_api_featuretypes_post","title":"featuretypes POST","text":"

                        When creating a new feature type via POST, if no underlying dataset with the specified name exists an attempt will be made to create it. This will work only in cases where the underlying data format supports the creation of new types (such as a database). When creating a feature type in this manner the client should include all attribute information in the feature type representation.

                        "},{"location":"rest/api/featuretypes/#exceptions","title":"Exceptions","text":"Exception Status code GET for a feature type that does not exist 404 PUT that changes name of feature type 403 PUT that changes data store of feature type 403"},{"location":"rest/api/featuretypes/#parameters","title":"Parameters","text":""},{"location":"rest/api/featuretypes/#rest_api_featuretypes_list","title":"list","text":"

                        The list parameter is used to control the category of feature types that are returned. It can take one of the following values:

                        • configured---Only configured feature types are returned. This is the default value.
                        • available---Only feature types that haven't been configured but are available from the specified data store will be returned.
                        • available_with_geom---Same as available but only includes feature types that have a geometry attribute.
                        • all---The union of configured and available.
                        "},{"location":"rest/api/featuretypes/#workspaceswsdatastoresdsfeaturetypesftformat","title":"/workspaces/<ws>/datastores/<ds>/featuretypes/<ft>[.<format>]","text":"

                        Controls a particular feature type in a given data store and workspace.

                        Method Action Status code Formats Default Format Parameters GET Return feature type ft 200 HTML, XML, JSON HTML quietOnNotFound POST 405 PUT Modify feature type ft 200 XML,JSON recalculate DELETE Delete feature type ft 200 recurse"},{"location":"rest/api/featuretypes/#exceptions_1","title":"Exceptions","text":"Exception Status code GET for a feature type that does not exist 404 PUT that changes name of feature type 403 PUT that changes data store of feature type 403"},{"location":"rest/api/featuretypes/#parameters_1","title":"Parameters","text":""},{"location":"rest/api/featuretypes/#rest_api_featuretypes_recurse","title":"recurse","text":"

                        The recurse parameter recursively deletes all layers referenced by the specified featuretype. Allowed values for this parameter are \"true\" or \"false\". The default value is \"false\". A DELETE request with recurse=false will fail if any layers reference the featuretype.

                        "},{"location":"rest/api/featuretypes/#rest_api_featuretypes_recalculate","title":"recalculate","text":"

                        The recalculate parameter specifies whether to recalculate any bounding boxes for a feature type. Some properties of feature types are automatically recalculated when necessary. In particular, the native bounding box is recalculated when the projection or projection policy are changed, and the lat/long bounding box is recalculated when the native bounding box is recalculated, or when a new native bounding box is explicitly provided in the request. (The native and lat/long bounding boxes are not automatically recalculated when they are explicitly included in the request.) In addition, the client may explicitly request a fixed set of fields to calculate, by including a comma-separated list of their names in the recalculate parameter. For example:

                        • recalculate= (empty parameter): Do not calculate any fields, regardless of the projection, projection policy, etc. This might be useful to avoid slow recalculation when operating against large datasets.
                        • recalculate=nativebbox: Recalculate the native bounding box, but do not recalculate the lat/long bounding box.
                        • recalculate=nativebbox,latlonbbox: Recalculate both the native bounding box and the lat/long bounding box.
                        "},{"location":"rest/api/featuretypes/#projection-policy","title":"Projection Policy","text":"

                        When specifying the Projection Policy in a FeatureType defined in the request body, the internal name should be used instead of the one available on the UI. The following table shows the correspondence between display and internal names:

                        Display Name Internal Name Force declared FORCE_DECLARED Keep native NONE Reproject native to declared REPROJECT_TO_DECLARED"},{"location":"rest/api/featuretypes/#rest_api_featuretypes_quietOnNotFound","title":"quietOnNotFound","text":"

                        The quietOnNotFound parameter avoids to log an Exception when the feature type is not present. Note that 404 status code will be returned anyway.

                        "},{"location":"rest/api/fonts/","title":"Fonts","text":"

                        This operation provides the list of fonts available in GeoServer. It can be useful to use this operation to verify if a font used in a SLD file is available before uploading the SLD.

                        "},{"location":"rest/api/fonts/#fontsformat","title":"/fonts[.<format>]","text":"Method Action Status code Formats Default Format GET Return the fonts available in GeoServer 200 XML, JSON XML POST 405 PUT 405 DELETE 405"},{"location":"rest/api/global/","title":"Global settings","text":"

                        Allows access to GeoServer's global settings.

                        "},{"location":"rest/api/global/#settingsformat","title":"/settings[.<format>]","text":"

                        Controls all global settings.

                        Method Action Status code Formats Default Format GET List all global settings 200 HTML, XML, JSON HTML POST 405 PUT Update global settings 200 XML, JSON DELETE 405"},{"location":"rest/api/global/#settingscontactformat","title":"/settings/contact[.<format>]","text":"

                        Controls global contact information only.

                        Method Action Status code Formats Default Format GET List global contact information 200 HTML, XML, JSON HTML POST 405 PUT Update global contact 200 XML, JSON DELETE 405"},{"location":"rest/api/layergroups/","title":"Layer groups","text":"

                        A layer group is a grouping of layers and styles that can be accessed as a single layer in a WMS GetMap request. A layer group is sometimes referred to as a \"base map\".

                        "},{"location":"rest/api/layergroups/#layergroupsformat","title":"/layergroups[.<format>]","text":"

                        Controls all layer groups.

                        Method Action Status code Formats Default Format GET Return all layer groups 200 HTML, XML, JSON HTML POST Add a new layer group 201, with Location header XML,JSON PUT 405 DELETE 405"},{"location":"rest/api/layergroups/#layergroupslgformat","title":"/layergroups/<lg>[.<format>]","text":"

                        Controls a particular layer group.

                        Method Action Status code Formats Default Format Parameters GET Return layer group lg 200 HTML, XML, JSON HTML quietOnNotFound POST 405 PUT Modify layer group lg 200 XML,JSON DELETE Delete layer group lg 200"},{"location":"rest/api/layergroups/#exceptions","title":"Exceptions","text":"Exception Status code GET for a layer group that does not exist 404 POST that specifies layer group with no layers 400 PUT that changes name of layer group 403"},{"location":"rest/api/layergroups/#parameters","title":"Parameters","text":""},{"location":"rest/api/layergroups/#rest_api_layergroups_quietOnNotFound","title":"quietOnNotFound","text":"

                        The quietOnNotFound parameter avoids to log an Exception when the layergroup is not present. Note that 404 status code will be returned anyway.

                        "},{"location":"rest/api/layergroups/#workspaceswslayergroupsformat","title":"/workspaces/<ws>/layergroups[.<format>]","text":"

                        Controls all layer groups in a given workspace.

                        Method Action Status code Formats Default Format GET Return all layer groups within workspace ws 200 HTML, XML, JSON HTML POST Add a new layer group within workspace ws 201, with Location header XML,JSON PUT 405 DELETE 405"},{"location":"rest/api/layergroups/#workspaceswslayergroupslgformat","title":"/workspaces/<ws>/layergroups/<lg>[.<format>]","text":"

                        Controls a particular layer group in a given workspace.

                        Method Action Status code Formats Default Format GET Return layer group lg within workspace ws 200 HTML, XML, JSON HTML quietOnNotFound POST 405 PUT Modify layer group lg within workspace ws 200 XML,JSON DELETE Delete layer group lg within workspace ws 200"},{"location":"rest/api/layergroups/#exceptions_1","title":"Exceptions","text":"Exception Status code GET for a layer group that does not exist for that workspace 404"},{"location":"rest/api/layers/","title":"Layers","text":"

                        A layer is a published resource (feature type or coverage).

                        "},{"location":"rest/api/layers/#layersformat","title":"/layers[.<format>]","text":"

                        Controls all layers.

                        Method Action Status code Formats Default Format GET Return all layers 200 HTML, XML, JSON HTML POST 405 PUT 405 DELETE 405"},{"location":"rest/api/layers/#layerslformat","title":"/layers/<l>[.<format>]","text":"

                        Controls a particular layer.

                        Method Action Status code Formats Default Format Parameters GET Return layer l 200 HTML, XML, JSON HTML quietOnNotFound POST 405 PUT Modify layer l 200 XML,JSON DELETE Delete layer l 200 recurse"},{"location":"rest/api/layers/#exceptions","title":"Exceptions","text":"Exception Status code GET for a layer that does not exist 404 PUT that changes name of layer 403 PUT that changes resource of layer 403"},{"location":"rest/api/layers/#parameters","title":"Parameters","text":""},{"location":"rest/api/layers/#rest_api_layers_recurse","title":"recurse","text":"

                        The recurse parameter recursively deletes all styles referenced by the specified layer. Allowed values for this parameter are \"true\" or \"false\". The default value is \"false\".

                        "},{"location":"rest/api/layers/#rest_api_layers_quietOnNotFound","title":"quietOnNotFound","text":"

                        The quietOnNotFound parameter avoids to log an Exception when the layer is not present. Note that 404 status code will be returned anyway.

                        "},{"location":"rest/api/layers/#layerslstylesformat","title":"/layers/<l>/styles[.<format>]","text":"

                        Controls all styles in a given layer.

                        Method Action Status code Formats Default Format GET Return all styles for layer l 200 SLD, HTML, XML, JSON HTML POST Add a new style to layer l 201, with Location header XML, JSON PUT 405 DELETE 405"},{"location":"rest/api/logging/","title":"Logging settings","text":"

                        Allows access to GeoServer's logging settings.

                        "},{"location":"rest/api/logging/#loggingformat","title":"/logging[.<format>]","text":"

                        Controls logging settings.

                        Method Action Status code Formats Default Format GET List logging settings 200 HTML, XML, JSON HTML POST 405 PUT Update logging settings 200 XML, JSON DELETE 405"},{"location":"rest/api/manifests/","title":"Manifests","text":"

                        GeoServer provides a REST service to expose a listing of all loaded JARs and resources on the running instance. This is useful for bug reports and to keep track of extensions deployed into the application. There are two endpoints for accessing this information:

                        • about/manifest---Retrieves details on all loaded JARs
                        • about/version---Retrieves details for the high-level components: GeoSever, GeoTools, and GeoWebCache
                        • about/status-Retrieves details for the status of all loaded and configured modules
                        "},{"location":"rest/api/manifests/#aboutmanifestformat","title":"/about/manifest[.<format>]","text":"

                        This endpoint retrieves details on all loaded JARs.

                        All the GeoServer manifest JARs are marked with the property GeoServerModule and classified by type, so you can use filtering capabilities to search for a set of manifests using regular expressions (see the manifest parameter) or a type category (see the key and value parameter).

                        The available types are core, extension, or community. To filter modules by a particular type, append a request with key=GeoServerModule&value=<type>

                        Method Action Status Code Formats Default Format Parameters GET List all manifests into the classpath 200 HTML, XML, JSON HTML manifest, key, value POST 405 PUT 405 DELETE 405"},{"location":"rest/api/manifests/#usage","title":"Usage","text":"

                        The model is very simple and is shared between the version and the resource requests to parse both requests.:

                        <about>\n  <resource name=\"{NAME}\">\n    <{KEY}>{VALUE}<!--{KEY}-->\n    ...\n  </resource>\n  ...\n</about>\n

                        You can customize the results adding a properties file called manifest.properties into the root of the data directory. Below is the default implementation that is used when no custom properties file is present:

                        resourceNameRegex=.+/(.*).(jar|war)\nresourceAttributeExclusions=Import-Package,Export-Package,Class-Path,Require-Bundle\nversionAttributeInclusions=Project-Version:Version,Build-Timestamp,Git-Revision,\n  Specification-Version:Version,Implementation-Version:Git-Revision\n

                        where:

                        • resourceNameRegex---Group(1) will be used to match the attribute name of the resource.
                        • resourceAttributeExclusions---Comma-separated list of properties to exclude (deny-list), used to exclude parameters that are too verbose such that the resource properties list is left open. Users can add their JARs (with custom properties) having the complete list of properties.
                        • versionAttributeInclusions---Comma-separated list of properties to include (allow-list). Also supports renaming properties (using key:replace) which is used to align the output of the versions request to the output of the web page. The model uses a map to store attributes, so the last attribute found in the manifest file will be used.
                        "},{"location":"rest/api/manifests/#rest_api_manifests_manifest","title":"manifest","text":"

                        The manifest parameter is used to filter over resulting resource (manifest) names attribute using Java regular expressions.

                        "},{"location":"rest/api/manifests/#rest_api_manifests_key","title":"key","text":"

                        The key parameter is used to filter over resulting resource (manifest) properties name. It can be combined with the value parameter.

                        "},{"location":"rest/api/manifests/#rest_api_manifests_value","title":"value","text":"

                        The value parameter is used to filter over resulting resource (manifest) properties value. It can be combined with the key parameter.

                        "},{"location":"rest/api/manifests/#aboutversionformat","title":"/about/version[.<format>]","text":"

                        This endpoint shows only the details for the high-level components: GeoServer, GeoTools, and GeoWebCache.

                        Method Action Status Code Formats Default Format Parameters GET List GeoServer, GeoWebCache and GeoTools manifests 200 HTML, XML, JSON HTML manifest, key, value POST 405 PUT 405 DELETE 405"},{"location":"rest/api/manifests/#aboutstatusformat","title":"/about/status[.<format>]","text":"

                        This endpoint shows the status details of all installed and configured modules.Status details always include human readable name, and module name. Optional details include version, availability, status message, and links to documentation.

                        Method Action Status Code Formats Default Format Parameters GET List module statuses 200 HTML, XML, JSON HTML POST 405 PUT 405 DELETE 405"},{"location":"rest/api/masterpassword/","title":"Keystore Password","text":"

                        The keystore password is used to encrypt the GeoServer key store and for an emergency login using the user root.

                        Warning

                        The use of HTTPS is recommended, otherwise all password are sent in plain text.

                        "},{"location":"rest/api/masterpassword/#securitymasterpwformat","title":"/security/masterpw[.<format>]","text":"

                        Fetches the keystore password and allows to change the keystore password

                        Method Action Status code Formats Default Format GET Fetch the keystore password 200,403 XML, JSON PUT Changes the keystore password 200,405,422 XML, JSON

                        Formats for PUT (keystore password change).

                        XML

                        <masterPassword>\n   <oldMasterPassword>oldPassword</oldMasterPassword>\n   <newMasterPassword>newPassword</newMasterPassword>\n</masterPassword>\n

                        JSON

                        { \"oldMasterPassword\":\"oldPassword\",\n  \"newMasterPassword\":\"newPassword\" }\n
                        "},{"location":"rest/api/masterpassword/#exceptions","title":"Exceptions","text":"Exception Status code GET without administrative privileges 403 PUT without administrative privileges 405 PUT with the wrong current keystore password 422 PUT with a new keystore password rejected by the password policy 422"},{"location":"rest/api/namespaces/","title":"Namespaces","text":"

                        A namespace is a uniquely identifiable grouping of feature types. It is identified by a prefix and a URI.

                        "},{"location":"rest/api/namespaces/#namespacesformat","title":"/namespaces[.<format>]","text":"

                        Controls all namespaces.

                        Method Action Status code Formats Default Format GET List all namespaces 200 HTML, XML, JSON HTML POST Create a new namespace 201 with Location header XML, JSON PUT 405 DELETE 405"},{"location":"rest/api/namespaces/#namespacesnsformat","title":"/namespaces/<ns>[.<format>]","text":"

                        Controls a particular namespace.

                        Method Action Status code Formats Default Format Parameters GET Return namespace ns 200 HTML, XML, JSON HTML quietOnNotFound POST 405 PUT 200 Modify namespace ns XML, JSON DELETE 200 Delete namespace ns XML, JSON"},{"location":"rest/api/namespaces/#exceptions","title":"Exceptions","text":"Exception Status code GET for a namespace that does not exist 404 PUT that changes prefix of namespace 403 DELETE against a namespace whose corresponding workspace is non-empty 403"},{"location":"rest/api/namespaces/#parameters","title":"Parameters","text":""},{"location":"rest/api/namespaces/#rest_api_namespaces_quietOnNotFound","title":"quietOnNotFound","text":"

                        The quietOnNotFound parameter avoids to log an Exception when the Namespace is not present. Note that 404 status code will be returned anyway.

                        "},{"location":"rest/api/namespaces/#namespacesdefaultformat","title":"/namespaces/default[.<format>]","text":"

                        Controls the default namespace.

                        Method Action Status code Formats Default Format GET Return default namespace 200 HTML, XML, JSON HTML POST 405 PUT 200 Set default namespace XML, JSON DELETE 405"},{"location":"rest/api/reload/","title":"Reloading configuration","text":"

                        Reloads the GeoServer catalog and configuration from disk. This operation is used in cases where an external tool has modified the on-disk configuration. This operation will also force GeoServer to drop any internal caches and reconnect to all data stores.

                        "},{"location":"rest/api/reload/#reload","title":"/reload","text":"Method Action Status code Formats Default Format GET 405 POST Reload the configuration from disk 200 PUT Reload the configuration from disk 200 DELETE 405"},{"location":"rest/api/reset/","title":"Resource reset","text":"

                        Resets all store, raster, and schema caches. This operation is used to force GeoServer to drop all caches and store connections and reconnect to each of them the next time they are needed by a request. This is useful in case the stores themselves cache some information about the data structures they manage that may have changed in the meantime.

                        "},{"location":"rest/api/reset/#reset","title":"/reset","text":"Method Action Status code Formats Default Format GET 405 POST Reset all store, raster, and schema caches 200 PUT Reset all store, raster, and schema caches 200 DELETE 405"},{"location":"rest/api/resources/","title":"Resources","text":""},{"location":"rest/api/resources/#resourcepathtoresource","title":"/resource</path/to/resource>","text":"

                        Method Action Status code Parameters

                        GET Download a resource, list contents of directory, or show formatted resource metadata. 200 operation (default | metadata); format (html | xml | json)

                        HEAD Show resource metadata in HTTP headers. 200

                        PUT Upload/move/copy a resource, create directories on the fly (overwrite if exists). For move/copy operations, place source path in body. Copying is not supported for directories. 200 (exists) 201 (new) operation (default | copy | move)

                        DELETE Delete a resource (recursively if directory) 200

                        "},{"location":"rest/api/resources/#exceptions","title":"Exceptions","text":"Exception Status code GET or DELETE for a resource that does not exist 404 PUT to directory 405 PUT method=copy with source directory 405 PUT with source path that doesn't exist 404 POST 405"},{"location":"rest/api/resources/#headers","title":"Headers","text":"Header Description Last-Modified When resource was last modified. Content-Type Will guess mime-type from extension or content. Resource-Type (custom) directory Resource-Parent (custom) Path to parent"},{"location":"rest/api/resources/#format","title":"Format","text":"

                        Examples are given in XML. The JSON and HTML formats are analogue.

                        "},{"location":"rest/api/resources/#metadata","title":"Metadata","text":"
                        <ResourceMetaData>\n   <name> nameOfFile </name>\n   <parent> <path> path/to/parent </path>\n        <atom:link xmlns:atom=\"http://www.w3.org/2005/Atom\" rel=\"alternate\"\n   href=\"http://localhost:8080/geoserver/rest/resource/path/to/parent?operation=metadata&format=xml\" \n         type=\"application/xml\"/>\n   </parent>\n   <lastModified> date </lastModified>\n   <type> undefined | resource | directory </type>\n</ResourceMetaData>\n
                        "},{"location":"rest/api/resources/#directories","title":"Directories","text":"
                        <ResourceDirectory>`\n   <name> nameOfDirectory </name>\n   <parent> <path> path/to/parent </path>\n        <atom:link xmlns:atom=\"http://www.w3.org/2005/Atom\" rel=\"alternate\"\n   href=\"http://localhost:8080/geoserver/rest/resource/path/to/parent?operation=metadata&format=xml\" \n         type=\"application/xml\"/>\n   </parent>\n   <lastModified> date </lastModified>\n   <children>\n       <child>\n               <name> ... </name>\n               <atom:link xmlns:atom=\"http://www.w3.org/2005/Atom\" rel=\"alternate\"\n                href=\"http://localhost:8080/geoserver/rest/resource/path/to/child\"/>\n       </child>\n       <child>\n               ...\n       </child>\n       ...\n   </children>` \n</ResourceDirectory>\n
                        "},{"location":"rest/api/selfadmin/","title":"Self admin","text":"

                        Self admin operations allow a user to perform actions on the user's own info.

                        Calls to the self admin operations are disabled by default. You'll have to edit the rest.properties file (more info at the REST services page) and add the line:

                        /rest/security/self/**;GET,POST,PUT,DELETE=ROLE_AUTHENTICATED\n
                        "},{"location":"rest/api/selfadmin/#securityselfpassword","title":"/security/self/password","text":"

                        Allows a user to change own password

                        Warning

                        The use of HTTPS is recommended, otherwise all password are sent in plain text.

                        Method Action Status code Formats Default Format PUT Changes the user password 200,400,424 XML, JSON

                        Formats for PUT (password change).

                        XML

                        <userPassword>\n   <newPassword>newPassword</newPassword>\n</userPassword>\n

                        JSON

                        { \"newPassword\":\"newPassword\" }\n
                        "},{"location":"rest/api/selfadmin/#exceptions","title":"Exceptions","text":"

                        Exception Status code Error string (payload)

                        PUT with an invalid newPassword or bad params 400 Missing 'newPassword'

                        PUT for user not updatable 424 User service does not support changing pw

                        "},{"location":"rest/api/services/","title":"OWS Services","text":"

                        GeoServer includes several types of OGC services like WCS, WFS and WMS, commonly referred to as \"OWS\" services. These services can be global for the whole GeoServer instance or local to a particular workspace. In this last case, they are called virtual services.

                        "},{"location":"rest/api/services/#serviceswcssettingsformat","title":"/services/wcs/settings[.<format>]","text":"

                        Controls Web Coverage Service settings.

                        Method Action Status code Formats Default Format GET Return global WCS settings 200 XML, JSON HTML POST 405 PUT Modify global WCS settings 200 DELETE 405"},{"location":"rest/api/services/#serviceswcsworkspaceswssettingsformat","title":"/services/wcs/workspaces/<ws>/settings[.<format>]","text":"

                        Controls Web Coverage Service settings for a given workspace.

                        Method Action Status code Formats Default Format GET Return WCS settings for workspace ws 200 HTML, XML, JSON HTML POST 405 PUT Create or modify WCS settings for workspace ws 200 XML,JSON DELETE Delete WCS settings for workspace ws 200"},{"location":"rest/api/services/#serviceswfssettingsformat","title":"/services/wfs/settings[.<format>]","text":"

                        Controls Web Feature Service settings.

                        Method Action Status code Formats Default Format GET Return global WFS settings 200 HTML, XML, JSON HTML POST 405 PUT Modify global WFS settings 200 XML,JSON DELETE 405"},{"location":"rest/api/services/#serviceswfsworkspaceswssettingsformat","title":"/services/wfs/workspaces/<ws>/settings[.<format>]","text":"

                        Controls Web Feature Service settings for a given workspace.

                        Method Action Status code Formats Default Format GET Return WFS settings for workspace ws 200 HTML, XML, JSON HTML POST 405 PUT Modify WFS settings for workspace ws 200 XML,JSON DELETE Delete WFS settings for workspace ws 200"},{"location":"rest/api/services/#serviceswmssettingsformat","title":"/services/wms/settings[.<format>]","text":"

                        Controls Web Map Service settings.

                        Method Action Status code Formats Default Format GET Return global WMS settings 200 HTML, XML, JSON HTML POST 405 PUT Modify global WMS settings 200 XML,JSON DELETE 405"},{"location":"rest/api/services/#serviceswmsworkspaceswssettingsformat","title":"/services/wms/workspaces/<ws>/settings[.<format>]","text":"

                        Controls Web Map Service settings for a given workspace.

                        Method Action Status code Formats Default Format GET Return WMS settings for workspace ws 200 HTML, XML, JSON HTML POST 405 PUT Modify WMS settings for workspace ws 200 XML,JSON DELETE Delete WMS settings for workspace ws 200"},{"location":"rest/api/services/#serviceswmtssettingsformat","title":"/services/wmts/settings[.<format>]","text":"

                        Controls Web Map Tile Service settings.

                        Method Action Status code Formats Default Format GET Return global WMTS settings 200 HTML, XML, JSON HTML POST 405 PUT Modify global WMTS settings 200 XML,JSON DELETE 405"},{"location":"rest/api/services/#serviceswmtsworkspaceswssettingsformat","title":"/services/wmts/workspaces/<ws>/settings[.<format>]","text":"

                        Controls Web Map Tile Service settings for a given workspace.

                        Method Action Status code Formats Default Format GET Return WMTS settings for workspace ws 200 HTML, XML, JSON HTML POST 405 PUT Modify WMTS settings for workspace ws 200 XML,JSON DELETE Delete WMTS settings for workspace ws 200

                        Todo

                        WPS?

                        "},{"location":"rest/api/styles/","title":"Styles","text":"

                        A style describes how a resource (feature type or coverage) should be symbolized or rendered by the Web Map Service. In GeoServer styles are specified with SLD.

                        "},{"location":"rest/api/styles/#stylesformat","title":"/styles[.<format>]","text":"

                        Controls all styles.

                        Method Action Status code Formats Default Format Parameters GET Return all styles 200 HTML, XML, JSON HTML POST Create a new style 201 with Location header SLD, XML, JSON, ZIP See note below name raw PUT 405 DELETE 405"},{"location":"rest/api/styles/#rest_api_styles_post_put","title":"Styles POST and PUT","text":"

                        When executing a POST or PUT request with an SLD style, the Content-type header should be set to the mime type identifying the style format. Style formats supported out of the box include:

                        • SLD 1.0 with a mime type of application/vnd.ogc.sld+xml
                        • SLD 1.1 / SE 1.1 with a mime type of application/vnd.ogc.se+xml
                        • SLD package (zip file containing sld and image files used in the style) with a mime type of application/zip

                        Other extensions (such as css) add support for additional formats.

                        "},{"location":"rest/api/styles/#parameters","title":"Parameters","text":""},{"location":"rest/api/styles/#rest_api_styles_name","title":"name","text":"

                        The name parameter specifies the name to be given to the style. This option is most useful when executing a POST request with a style in SLD format, and an appropriate name can be not be inferred from the SLD itself.

                        "},{"location":"rest/api/styles/#rest_api_styles_raw","title":"raw","text":"

                        The raw parameter specifies whether to forgo parsing and encoding of the uploaded style content. When set to \"true\" the style payload will be streamed directly to GeoServer configuration. Use this setting if the content and formatting of the style is to be preserved exactly. Use this setting with care as it may result in an invalid and unusable style. The default is \"false\".

                        "},{"location":"rest/api/styles/#stylessformat","title":"/styles/<s>[.<format>]","text":"

                        Controls a given style.

                        Method Action Status code Formats Default Format Parameters GET Return style s 200 SLD, HTML, XML, JSON HTML quietOnNotFound pretty POST 405 PUT Modify style s 200 SLD, XML, JSON, ZIP See note above raw DELETE Delete style s 200 purge recurse"},{"location":"rest/api/styles/#exceptions","title":"Exceptions","text":"Exception Status code GET for a style that does not exist 404 PUT that changes name of style 403 DELETE against style which is referenced by existing layers 403"},{"location":"rest/api/styles/#parameters_1","title":"Parameters","text":""},{"location":"rest/api/styles/#rest_api_styles_purge","title":"purge","text":"

                        The purge parameter specifies whether the underlying SLD file for the style should be deleted on disk. Allowable values for this parameter are \"true\" or \"false\". When set to \"true\" the underlying file will be deleted.

                        "},{"location":"rest/api/styles/#rest_api_styles_recurse","title":"recurse","text":"

                        The recurse parameter removes references to the specified style in existing layers. Allowed values for this parameter are \"true\" or \"false\". The default value is \"false\".

                        "},{"location":"rest/api/styles/#rest_api_styles_quietOnNotFound","title":"quietOnNotFound","text":"

                        The quietOnNotFound parameter avoids to log an Exception when the style is not present. Note that 404 status code will be returned anyway.

                        "},{"location":"rest/api/styles/#rest_api_styles_pretty","title":"pretty","text":"

                        The pretty parameter returns the style in a human-readable format, with proper blank-space and indentation. This parameter has no effect if you request a style in its native format - in this case the API returns the exact content of the underlying file. The HTML, XML, and JSON formats do not support this parameter.

                        "},{"location":"rest/api/styles/#workspaceswsstylesformat","title":"/workspaces/<ws>/styles[.<format>]","text":"

                        Controls all styles in a given workspace.

                        Method Action Status code Formats Default Format Parameters GET Return all styles within workspace ws 200 HTML, XML, JSON HTML POST Create a new style within workspace ws 201 with Location header SLD, XML, JSON, ZIP See note above name raw PUT 405 DELETE 405 purge"},{"location":"rest/api/styles/#workspaceswsstylessformat","title":"/workspaces/<ws>/styles/<s>[.<format>]","text":"

                        Controls a particular style in a given workspace.

                        Method Action Status code Formats Default Format Parameters GET Return style s within workspace ws 200 SLD, HTML, XML, JSON HTML quietOnNotFound POST 405 PUT Modify style s within workspace ws 200 SLD, XML, JSON, ZIP See note above raw DELETE Delete style s within workspace ws 200"},{"location":"rest/api/styles/#exceptions_1","title":"Exceptions","text":"Exception Status code GET for a style that does not exist for that workspace 404"},{"location":"rest/api/templates/","title":"Freemarker templates","text":"

                        Freemarker is a simple yet powerful template engine that GeoServer uses for user customization of outputs.

                        It is possible to use the GeoServer REST API to manage Freemarker templates for catalog resources.

                        "},{"location":"rest/api/templates/#templatestemplateftl","title":"/templates/<template>.ftl","text":"

                        This endpoint manages a template that is global to the entire catalog.

                        Method Action Status Code Formats Default Format GET Return a template 200 PUT Insert or update a template 405 DELETE Delete a template 405

                        Identical operations apply to the following endpoints:

                        • Workspace templates---/workspaces/<ws>/templates/<template>.ftl
                        • Vector store templates---/workspaces/<ws>/datastores/<ds>/templates/<template>.ftl
                        • Feature type templates---/workspaces/<ws>/datastores/<ds>/featuretypes/<f>/templates/<template>.ftl
                        • Raster store templates---/workspaces/<ws>/coveragestores/<cs>/templates/<template>.ftl
                        • Coverage templates---/workspaces/<ws>/coveragestores/<cs>/coverages/<c>/templates/<template>.ftl
                        "},{"location":"rest/api/templates/#templatesformat","title":"/templates[.<format>]","text":"

                        This endpoint manages all global templates.

                        Method Action Status Code Formats Default Format GET Return templates 200 HTML, XML, JSON HTML

                        Identical operations apply to the following endpoints:

                        • Workspace templates---/workspaces/<ws>/templates[.<format>]
                        • Vector store templates---/workspaces/<ws>/datastores/<ds>/templates[.<format>]
                        • Feature type templates---/workspaces/<ws>/datastores/<ds>/featuretypes/<f>/templates[.<format>]
                        • Raster store templates---/workspaces/<ws>/coveragestores/<cs>/templates[.<format>]
                        • Coverage templates---/workspaces/<ws>/coveragestores/<cs>/coverages/<c>/templates[.<format>]
                        "},{"location":"rest/api/userrole/","title":"Users/Groups and Roles","text":""},{"location":"rest/api/userrole/#security","title":"Security","text":"

                        The Users/Groups and Roles Rest API is only accessible to users with the role ROLE_ADMIN.

                        "},{"location":"rest/api/userrole/#inputoutput","title":"Input/Output","text":""},{"location":"rest/api/userrole/#data-object-transfer","title":"Data Object Transfer","text":"

                        Both XML and JSON are supported for transfer of data objects. The default is XML. Alternatively, JSON may be used by setting the 'content-type' (POST) and 'accept' (GET) http headers to 'application/json' in your requests.

                        Encoding of a user in XML:

                        <user>\n    <userName>..</userName>\n    <password>..</password>\n    <enabled>true/false</enabled>\n</user>\n

                        Encoding of a user in JSON:

                        {\"userName\": \"..\", \"password\": \"..\", enabled: true/false}\n

                        Passwords are left out in results of reading requests.

                        Encoding of a list of users in XML:

                        <users>\n    <user> ... </user>\n    <user> ... </user>\n    ...     \n</users>\n

                        Encoding of a list of users in JSON:

                        {\"users\":[ {..}, {..}, .. ]}\n

                        Encoding of a list of groups in XML:

                        <groups>\n    <group> agroupname </group>\n    <group> bgroupname </group>\n    ...     \n</groups>\n

                        Encoding of a list of groups in JSON:

                        {\"groups\":[ {..}, {..}, .. ]}\n

                        Encoding of a list of roles:

                        <roles>\n    <role> arolename </role>\n    <role> brolename </role>\n    ...     \n</roles>\n

                        Encoding of a list of roles in JSON:

                        {\"roles\":[ {..}, {..}, .. ]}\n
                        "},{"location":"rest/api/userrole/#configuration","title":"Configuration","text":"

                        The default user/group service is by default the service named \"default\". This can be altered in the following manner:

                        1. Start geoserver with the following java system property present:
                          org.geoserver.rest.DefaultUserGroupServiceName=<name_of_usergroupservice>\n
                        "},{"location":"rest/api/userrole/#requests","title":"Requests","text":""},{"location":"rest/api/userrole/#restusergroupserviceservicenameusers","title":"/rest/usergroup/[service/<serviceName>/]users/","text":"

                        Query all users or add a new user in a particular or the default user/group service.

                        Method Action Response

                        GET List all users in service. 200 OK. List of users in XML.

                        POST Add a new user 201 Inserted. Created ID header.

                        "},{"location":"rest/api/userrole/#restusergroupserviceservicenameuseruser","title":"/rest/usergroup/[service/<serviceName>/]user/<user>","text":"

                        Query, modify or delete a specific user in a particular or the default user/group service.

                        Method Action Response

                        GET Read user information 200 OK. User in XML.

                        POST Modify the user, unspecified fields remain unchanged. 200 OK.

                        DELETE Delete the user 200 OK.

                        "},{"location":"rest/api/userrole/#restusergroupserviceservicenamegroups","title":"/rest/usergroup/[service/<serviceName>/]groups/","text":"

                        Query all groups in a particular user/group or the default service.

                        Method Action Response

                        GET List all groups in service. 200 OK. List of groups in XML.

                        "},{"location":"rest/api/userrole/#restusergroupserviceservicenamegroupgroup","title":"/rest/usergroup/[service/<serviceName>/]group/<group>","text":"

                        Add or delete a specific group in a particular or the default user/group service.

                        Method Action Response

                        POST Add the group. 200 OK.

                        DELETE Delete the group. 200 OK.

                        "},{"location":"rest/api/userrole/#restusergroupserviceservicenameuserusergroups","title":"/rest/usergroup/[service/<serviceName>/]user/<user>/groups","text":"

                        Query all groups associated with a user in a particular or the default user/group service.

                        Method Action Response

                        GET List all groups associated with user. 200 OK. List of groups in XML.

                        "},{"location":"rest/api/userrole/#restusergroupserviceservicenamegroupgroupusers","title":"/rest/usergroup/[service/<serviceName>/]group/<group>/users","text":"

                        Query all users associated with a group in a particular or the default user/group service.

                        Method Action Response

                        GET List all users associated with group. 200 OK. List of groups in XML.

                        "},{"location":"rest/api/userrole/#restusergroupserviceservicenameusergroupgroup","title":"/rest/usergroup/[service/<serviceName>/]<user>/group/<group>","text":"

                        Associate or disassociate a specific user with a specific group in a particular or the default user/group service.

                        Method Action Response

                        POST Associate the user with the group. 200 OK.

                        DELETE Disassociate the user from the group. 200 OK.

                        "},{"location":"rest/api/userrole/#restrolesserviceservicename","title":"rest/roles/[service/{serviceName}/]","text":"

                        Query all roles in a particular role service or the active role service.

                        Method Action Response

                        GET List all roles in service. 200 OK. List of roles in XML.

                        "},{"location":"rest/api/userrole/#restrolesserviceservicenamerolerole","title":"/rest/roles/[service/<serviceName>/]role/<role>","text":"

                        Add or delete a specific role in a particular role service or the active role service.

                        Method Action Response

                        POST Add the role. 200 OK.

                        DELETE Delete the role. 200 OK.

                        "},{"location":"rest/api/userrole/#restrolesserviceservicenameservicenameuseruserroles","title":"/rest/roles/[service/<serviceName>/]<serviceName>/user/<user>/roles","text":"

                        Query all roles associated with a user in a particular role service or the active role service.

                        Method Action Response

                        GET List all roles associated with user. 200 OK. List of roles in XML.

                        "},{"location":"rest/api/userrole/#restrolesserviceservicenameroleroleuseruser","title":"/rest/roles/[service/<serviceName>/]role/<role>/user/<user>/","text":"

                        Associate or disassociate a specific user with a specific role in a particular role service or the active role service.

                        Method Action Response

                        POST Associate the user with the role. 200 OK.

                        DELETE Disassociate the user from the role. 200 OK.

                        "},{"location":"rest/api/workspaces/","title":"Workspaces","text":"

                        A workspace is a grouping of data stores. Similar to a namespace, it is used to group data that is related in some way.

                        "},{"location":"rest/api/workspaces/#workspacesformat","title":"/workspaces[.<format>]","text":"

                        Controls all workspaces.

                        Method Action Status code Formats Default Format GET List all workspaces 200 HTML, XML, JSON HTML POST Create a new workspace 201 with Location header XML, JSON PUT 405 DELETE 405"},{"location":"rest/api/workspaces/#workspaceswsformat","title":"/workspaces/<ws>[.<format>]","text":"

                        Controls a specific workspace.

                        Method Action Status code Formats Default Format Parameters GET Return workspace ws 200 HTML, XML, JSON HTML quietOnNotFound POST 405 PUT 200 Modify workspace ws XML, JSON DELETE 200 Delete workspace ws XML, JSON recurse"},{"location":"rest/api/workspaces/#exceptions","title":"Exceptions","text":"Exception Status code GET for a workspace that does not exist 404 PUT that changes name of workspace 403 DELETE against a workspace that is non-empty 403"},{"location":"rest/api/workspaces/#parameters","title":"Parameters","text":""},{"location":"rest/api/workspaces/#rest_api_workspaces_recurse","title":"recurse","text":"

                        The recurse parameter recursively deletes all layers referenced by the specified workspace, including data stores, coverage stores, feature types, and so on. Allowed values for this parameter are \"true\" or \"false\". The default value is \"false\".

                        "},{"location":"rest/api/workspaces/#rest_api_workspaces_quietOnNotFound","title":"quietOnNotFound","text":"

                        The quietOnNotFound parameter avoids to log an Exception when the Workspace is not present. Note that 404 status code will be returned anyway.

                        "},{"location":"rest/api/workspaces/#workspacesdefaultformat","title":"/workspaces/default[.<format>]","text":"

                        Controls the default workspace.

                        Method Action Status code Formats Default Format GET Returns default workspace 200 HTML, XML, JSON HTML POST 405 PUT 200 Set default workspace XML, JSON DELETE 405"},{"location":"rest/api/workspaces/#workspaceswssettingsformat","title":"/workspaces/<ws>/settings[.<format>]","text":"

                        Controls settings on a specific workspace.

                        Method Action Status code Formats Default Format GET Returns workspace settings 200 HTML, XML, JSON HTML POST 405 PUT Creates or updates workspace settings 200 XML, JSON DELETE Deletes workspace settings 200 XML, JSON"},{"location":"security/","title":"Security","text":"

                        This section details the security subsystem in GeoServer, which is based on Spring Security.

                        The first page discusses configuration options in the web administration interface. This is followed with a detailed discussion of the underlying processes.

                        • Security settings
                        • Role system
                        • Authentication
                        • Passwords
                        • Root account
                        • Service Security
                        • Layer security
                        • REST Security
                        • URL Checks
                        • Disabling security
                        • Tutorials
                        "},{"location":"security/disable/","title":"Disabling security","text":"

                        If you are using an external security subsystem, you may want to disable the built-in security to prevent conflicts. Disabling security is possible for each security filter chain individually. The security filter chains are listed on the GeoServer authentication page.

                        Warning

                        Disabling security for a filter chain results in administrator privileges for each HTTP request matching this chain. As an example, disabling security on the web chain gives administrative access to each user accessing the Web administration interface interface.

                        "},{"location":"security/layer/","title":"Layer security","text":"

                        GeoServer allows access to be determined on a per-layer basis.

                        Note

                        Layer security and Service Security cannot be combined. For example, it is not possible to specify access to a specific OWS service, only for one specific layer.

                        Providing access to layers is linked to roles. Layers and roles are linked in a file called layers.properties, which is located in the security directory in your GeoServer data directory. The file contains the rules that control access to workspaces and layers.

                        Note

                        The default layers security configuration in GeoServer allows any anonymous user to read data from any layer but only allows admin users to edit data.

                        "},{"location":"security/layer/#rules","title":"Rules","text":"

                        The syntax for a layer security rule can follow three different patterns ([] denotes optional parameters):

                        globalLayerGroup.permission=role[,role2,...]\nworkspace.layer.permission=role[,role2,...]\nworkspace.workspaceLayerGroup.permission=role[,role2,...]\n

                        The parameters include:

                        • globalLayerGroup--- Name of a global layer group (one without workspace associated to it).

                        • workspace--- Name of the workspace. The wildcard * is used to indicate all workspaces.

                        • layer--- Name of a resource (featuretype/coverage/etc...). The wildcard * is used to indicate all layers.

                        • workspaceLayerGroup--- Name of a workspace specific layer group.

                        • permission--- Type of access permission/mode.

                          • r---Read access
                          • w---Write access
                          • a---Admin access

                          See Access modes for more details.

                        • role[,role2,...] is the name(s) of predefined roles. The wildcard * is used to indicate the permission is applied to all users, including anonymous users.

                        Note

                        If a workspace or layer name is supposed to contain dots, they can be escaped using double backslashes (\\). For example, if a layer is named layer.with.dots the following syntax for a rule may be used:

                        topp.layer\\\\.with\\\\.dots.r=role[,role2,...]\n

                        General rules for layer security:

                        • Each entry must have a unique combination of workspace, layer, and permission values.
                        • If a permission at the global level is not specified, global permissions are assumed to allow read/write access.
                        • If a permission for a workspace is not specified, it inherits permissions from the global specification.
                        • If a permission for a layer is not specified, it inherits permissions from its workspace specification in all protocols except WMS (where layer groups rules play a role, see below).
                        • If a user belongs to multiple roles, the least restrictive permission they inherit will apply.

                        For WMS, layers will be also secured by considering their containing layer groups. In particular:

                        • Rules with Single layer groups only affect the group itself, but not its contents. Single mode is considered just an alias for a list of layers, with no containment.
                        • Rules with other types of groups (Named tree, Container tree, Earth Observation tree) also affect contained layers and nested layer groups. If the group is not accessible, the layers and groups contained in that group will not be accessible either.. The only exception is when another layer group which is accessible contains the same layer or nested group, in that case the layers they will show up under the allowed groups.
                        • Workspace rules gets precedence over global layer group ones when it comes to allow access to layers.
                        • Layer rules get precedence over all layer group rules when it comes to allow access to layers.

                        The following tables summarizes the layer group behavior depending on whether they are used in a public or secured environment:

                        Mode Public behavior Restricted behavior

                        Single Looks like a stand-alone layer, can be requested directly and acts as an alias for a layer list. Layers are also visible at root level Does not control layer access at all

                        Opaque container Looks like a stand-alone layer, can be requested directly and acts as an alias for a layer list. Layers in it are not available for WMS requests Same as public behavior

                        Named tree Contained layers are visible as children in the capabilities document, the name can be used as a shortcut to request all layers. Restricting access to the group restricts also the contained layers, unless another \"tree\" group allows access to the same layer

                        Container tree Same as \"named tree\", but does not have a name published in the capabilities document and thus cannot be requested directly Same as \"named tree\"

                        "},{"location":"security/layer/#catalog-mode","title":"Catalog Mode","text":"

                        The layers.properties file may contain a further directive that specifies how GeoServer will advertise secured layers and behave when a secured layer is accessed without the necessary privileges. The parameter is mode and is commonly referred to as the \"catalog mode\".

                        The syntax is:

                        mode=option\n

                        option may be one of three values:

                        Option Description

                        hide (Default) Hides layers that the user does not have read access to, and behaves as if a layer is read only if the user does not have write permissions. The capabilities documents will not contain the layers the current user cannot access. This is the highest security mode. As a result, it may not work very well with clients such as uDig or Google Earth.

                        challenge Allows free access to metadata, but any attempt at accessing actual data is met by a HTTP 401 code (which forces most clients to show an authentication dialog). The capabilities documents contain the full list of layers. DescribeFeatureType and DescribeCoverage operations work successfully. This mode works fine with clients such as uDig or Google Earth.

                        mixed Hides the layers the user cannot read from the capabilities documents, but triggers authentication for any other attempt to access the data or the metadata. This option is useful if you don't want the world to see the existence of some of your data, but you still want selected people to who have data access links to get the data after authentication.

                        "},{"location":"security/layer/#access_mode","title":"Access modes","text":"

                        The access mode defines what level of access should be granted on a specific workspace/layer to a particular role. There are three types of access mode:

                        • r---Read mode (read data from a workspace/layer)
                        • w---Write mode (write data to a workspace/layer)
                        • a---Admin mode (access and modify the configuration of a workspace/layer)

                        Some notes on the above access modes:

                        • Write does not imply Read, but Admin implies both Write and Read.
                        • Read and Write apply to the data of a layer, while Admin applies to the configuration of a layer.
                        • As Admin mode only refers to the configuration of the layer, it is not required for any OGC service request.

                        Note

                        Currently, it is possible to assign Admin permission only to an entire workspace, and not to specific layers.

                        "},{"location":"security/layer/#examples","title":"Examples","text":"

                        The following examples illustrate some possible layer restrictions and the corresponding rules.

                        "},{"location":"security/layer/#protecting-a-single-workspace-and-a-single-layer","title":"Protecting a single workspace and a single layer","text":"

                        The following example demonstrates how to configure GeoServer as a primarily a read-only server:

                        *.*.r=*\n*.*.w=NO_ONE\nprivate.*.r=TRUSTED_ROLE\nprivate.*.w=TRUSTED_ROLE\ntopp.congress_district.w=STATE_LEGISLATORS\n

                        The mapping of roles to permissions is as follows:

                        Role private. topp. topp.congress_district (all other workspaces)

                        NO_ONE (none) w (none) w

                        TRUSTED_ROLE r/w r r r

                        STATE_LEGISLATORS (none) r r/w r

                        (All other users) (none) r r r

                        Note

                        Specific workspace rule private.*.r=TRUSTED_ROLE will take precedence over the more generic rule *.*.r=*. When a request is made to read a layer private:vulnerable_infrastructure the most specific rule available is used to control access. In this case the workspace rule private.*.r=TRUSTED_ROLE is the most specific and only users that have TRUSTED_ROLE will be granted r access and be able to read the private:vulnerable_infrastructure layer. Other users that do not have the TRUSTED_ROLE will not be granted r access and will be unable to access the private:vulnerable_infrastructure layer.

                        "},{"location":"security/layer/#locking-down-geoserver","title":"Locking down GeoServer","text":"

                        The following example demonstrates how to lock down GeoServer:

                        *.*.r=TRUSTED_ROLE\n*.*.w=TRUSTED_ROLE\ntopp.*.r=*\narmy.*.r=MILITARY_ROLE,TRUSTED_ROLE\narmy.*.w=MILITARY_ROLE,TRUSTED_ROLE\n

                        The mapping of roles to permissions is as follows:

                        Role topp. army. (All other workspaces)

                        TRUSTED_ROLE r/w r/w r/w

                        MILITARY_ROLE r r/w (none)

                        (All other users) r (none) (none)

                        "},{"location":"security/layer/#providing-restricted-administrative-access","title":"Providing restricted administrative access","text":"

                        The following provides administrative access on a single workspace to a specific role, in additional to the full administrator role:

                        *.*.a=ROLE_ADMINISTRATOR\ntopp.*.a=ROLE_TOPP_ADMIN,ROLE_ADMINISTRATOR\n
                        "},{"location":"security/layer/#managing-multi-level-permissions","title":"Managing multi-level permissions","text":"

                        The following example demonstrates how to configure GeoServer with global-, workspace--, and layer-level permissions:

                        *.*.r=TRUSTED_ROLE\n*.*.w=NO_ONE\ntopp.*.r=*\ntopp.states.r=USA_CITIZEN_ROLE,LAND_MANAGER_ROLE,TRUSTED_ROLE\ntopp.states.w=NO_ONE\ntopp.poly_landmarks.w=LAND_MANAGER_ROLE\ntopp.military_bases.r=MILITARY_ROLE\ntopp.military_bases.w=MILITARY_ROLE\n

                        The mapping of roles to permissions is as follows:

                        Role topp.states topp.poly_landmarks topp.military_bases topp.(all other layers) (All other workspaces)

                        NO_ONE w r (none) w w

                        TRUSTED_ROLE r r (none) r r

                        MILITARY_ROLE (none) r r/w r (none)

                        USA_CITIZEN_ROLE r r (none) r (none)

                        LAND_MANAGER_ROLE r r/w (none) r (none)

                        (All other users) (none) r (none) r (none)

                        Note

                        The entry topp.states.w=NO_ONE is not required because this permission would be inherited from the global level (the entry *.*.w=NO_ONE).

                        "},{"location":"security/layer/#invalid-configuration","title":"Invalid configuration","text":"

                        The following examples are invalid because the workspace, layer, and permission combinations are not unique:

                        topp.state.rw=ROLE1\ntopp.state.rw=ROLE2,ROLE3\n
                        "},{"location":"security/layer/#security-by-layer-group-in-wms","title":"Security by layer group in WMS","text":"

                        To clarify, lets assume the following starting situation, in which all layers and groups are visible:

                        root\n+- namedTreeGroupA\n|   |   ws1:layerA\n|   \u2514   ws2:layerB\n+- namedTreeGroupB\n|   |   ws2:layerB\n|   \u2514   ws1:layerC\n+- layerD\n+- singleGroupC (contains ws1:layerA and layerD when requested)\n

                        Here are a few examples of how the structure changes based on different security rules.

                        • Denying access to namedTreeGroupA by:

                          namedTreeGroupA.r=ROLE_PRIVATE\n

                          Will give the following capabilities tree to anonymous users:

                          root\n+- namedTreeGroupB\n|   |   ws2:layerB\n|   \u2514   ws1:layerC\n+- layerD\n+- singleGroupC (contains only layerD when requested)\n
                        • Denying access to namedTreeGroupB by :

                          namedTreeGroupB.r=ROLE_PRIVATE\n

                          Will give the following capabilities tree to anonymous users:

                          root\n+- namedTreeGroupA\n|   |   ws1:layerA\n|   \u2514   ws2:layerB\n+- layerD\n+- singleGroupC (contains ws1:layerA and layerD when requested)\n
                        • Denying access to singleGroupC by:

                          singleGroupC.r=ROLE_PRIVATE\n

                          Will give the following capabilities tree to anonymous users:

                          root\n+- namedTreeGroupA\n|   |   ws1:layerA\n|   \u2514   ws2:layerB\n+- namedTreeGroupB\n|   |   ws2:layerB\n|   \u2514   ws1:layerC\n+- layerD\n
                        • Denying access to everything, but allowing explicit access to namedTreeGroupA by:

                          nameTreeGroupA.r=*\n*.*.r=PRIVATE\n*.*.w=PRIVATE\n

                          Will give the following capabilities tree to anonymous users:

                          root\n+- namedTreeGroupA\n    |   ws1:layerA\n    \u2514   ws2:layerB\n
                        • Denying access to nameTreeGroupA and namedTreeGroupB but explicitly allowing access to ws1:layerA:

                          namedTreeGroupA.r=ROLE_PRIVATE\nnamedTreeGroupB.r=ROLE_PRIVATE\nws1.layerA.r=*\n

                          Will give the following capabilities tree to anonymous users (notice how ws1:layerA popped up to the root):

                          root\n+- ws1:layerA\n+- layerD\n
                        • Denying access to nameTreeGroupA and namedTreeGroupB but explicitly allowing all layers in ws2 (a workspace rule overrides global groups ones):

                          namedTreeGroupA.r=ROLE_PRIVATE\nnamedTreeGroupB.r=ROLE_PRIVATE\nws2.*.r=*\n

                          Will give the following capabilities tree to anonymous users (notice how ws1:layerB popped up to the root):

                          root\n+- ws2:layerB\n+- layerD\n+- singleGroupC\n
                        "},{"location":"security/passwd/","title":"Passwords","text":"

                        Passwords are a central aspect of any security system. This section describes how GeoServer handles passwords.

                        "},{"location":"security/passwd/#security_passwd_encryption","title":"Password encryption","text":"

                        A GeoServer configuration stores two types of passwords:

                        • Passwords for user accounts to access GeoServer resources
                        • Passwords used internally for accessing external services such as databases and cascading OGC services

                        As these passwords are typically stored on disk it is strongly recommended that they be encrypted and not stored as human-readable text. GeoServer security provides four schemes for encrypting passwords: empty, plain text, Digest, and Password-based encryption (PBE).

                        The password encryption scheme is specified as a global setting that affects the encryption of passwords used for external resources, and as an encryption scheme for each user/group service. The encryption scheme for external resources has to be reversible, while the user/group services can use any scheme.

                        "},{"location":"security/passwd/#empty","title":"Empty","text":"

                        The scheme is not reversible. Any password is encoded as an empty string, and as a consequence it is not possible to recalculate the plain text password. This scheme is used for user/group services in combination with an authentication mechanism using a back end system. Examples are user name/password authentication against a LDAP server or a JDBC database. In these scenarios, storing passwords locally to GeoServer does not make sense.

                        "},{"location":"security/passwd/#plain-text","title":"Plain text","text":"

                        Plain text passwords provide no encryption at all. In this case, passwords are human-readable by anyone who has access to the file system. For obvious reasons, this is not recommended for any but the most basic test server. A password mypassword is encoded as plain:mypassword, the prefix uniquely describing the algorithm used for encoding/decoding.

                        "},{"location":"security/passwd/#digest","title":"Digest","text":"

                        Digest encryption is not reversible. It applies, 100,000 times through an iterative process, a SHA-256 cryptographic hash function to passwords. This scheme is \"one-way\" in that it is virtually impossible to reverse and obtain the original password from its hashed representation. Please see the section on Reversible encryption for more information on reversibility.

                        To protect from well known attacks, a random value called a salt is added to the password when generating the key. For each digesting, a separate random salt is used. Digesting the same password twice results in different hashed representations.

                        As an example, the password geoserver is digested to digest1:YgaweuS60t+mJNobGlf9hzUC6g7gGTtPEu0TlnUxFlv0fYtBuTsQDzZcBM4AfZHd. digest1 indicates the usage of digesting. The hashed representation and the salt are base 64 encoded.

                        "},{"location":"security/passwd/#password-based-encryption","title":"Password-based encryption","text":"

                        Password-based encryption (PBE) normally employs a user-supplied password to generate an encryption key. This scheme is reversible. A random salt described in the previous section is used.

                        Note

                        The system never uses passwords specified by users because these passwords tend to be weak. Passwords used for encryption are generated using a secure random generator and stored in the GeoServer key store. The number of possible passwords is 2\\^260 .

                        GeoServer supports two forms of PBE. Weak PBE (the GeoServer default) uses a basic encryption method that is relatively easy to crack. The encryption key is derived from the password using MD5 1000 times iteratively. The encryption algorithm itself is DES (Data Encryption Standard). DES has an effective key length of 56 bits, which is not really a challenge for computer systems in these days.

                        Strong PBE uses a much stronger encryption method based on an AES 256-bit algorithm with CBC. The key length is 256 bit and is derived using SHA-256 instead of MD5. Using Strong PBE is highly recommended.

                        As an example, the password geoserver is encrypted to crypt1:KWhO7jrTz/Gi0oTQRKsVeCmWIZY5VZaD. crypt1 indicates the usage of Weak PBE. The prefix for Strong PBE is crypt2. The ciphertext and the salt are base 64 encoded.

                        "},{"location":"security/passwd/#security_passwd_reversible","title":"Reversible encryption","text":"

                        Password encryption methods can be reversible, meaning that it is possible (and desirable) to obtain the plain-text password from its encrypted version. Reversible passwords are necessary for database connections or external OGC services such as cascading WMS and cascading WFS, since GeoServer must be able to decode the encrypted password and pass it to the external service. Plain text and PBE passwords are reversible.

                        Non-reversible passwords provide the highest level of security, and therefore should be used for user accounts and wherever else possible. Using password digesting is highly recommended, the installation of the unrestricted policy files is not required.

                        "},{"location":"security/passwd/#security_passwd_keystore","title":"Secret keys and the keystore","text":"

                        For a reversible password to provide a meaningful level of security, access to the password must be restricted in some way. In GeoServer, encrypting and decrypting passwords involves the generation of secret shared keys, stored in a typical Java keystore. GeoServer uses its own keystore for this purpose named geoserver.jceks which is located in the security directory in the GeoServer data directory. This file is stored in the JCEKS format rather than the default JKS. JKS does not support storing shared keys.

                        The GeoServer keystore is password protected with a Keystore password. It is possible to access the contents of the keystore with external tools such as keytool. For example, this following command would prompt for the keystore password and list the contents of the keystore:

                        $ keytool -list -keystore geoserver.jceks -storetype \"JCEKS\"\n
                        "},{"location":"security/passwd/#security_master_passwd","title":"Keystore password","text":"

                        It is also possible to set a keystore password for GeoServer. This password serves two purposes:

                        • Protect access to the keystore
                        • Protect access to the GeoServer Root account

                        By default, the keystore password is generated and stored in a file named security/masterpw.info using plain text. When upgrading from an existing GeoServer data directory (versions 2.1.x and lower), the algorithm attempts to figure out the password of a user with the role ROLE_ADMINISTRATOR. If such a password is found and the password length is 8 characters at minimum, GeoServer uses this password as keystore password. Again, the name of the chosen user is found in security/masterpw.info.

                        Warning

                        The file security/masterpw.info is a security risk. The administrator should read this file and verify the keystore password by logging on GeoServer as the root user. On success, this file should be removed.

                        Warning

                        The first thing an Administrator of the System should do is dump the keystore Password generated by GeoServer, store it somewhere not accessible by anyone, and delete security/masterpw.info or whatever file you dumped the password to.

                        Refer to Active keystore password provider for information on how to change the keystore password.

                        Note

                        By default login to the Admin GUI and REST APIs using the Keystore Password is disabled. In order to enable it you will need to manually change the Keystore Password Provider config.xml, usually located in security/masterpw/default/config.xml, by adding the following statement:

                        ``<loginEnabled>true</loginEnabled>``\n
                        "},{"location":"security/passwd/#security_passwd_policy","title":"Password policies","text":"

                        A password policy defines constraints on passwords such as password length, case, and required mix of character classes. Password policies are specified when adding User/group services and are used to constrain passwords when creating new users and when changing passwords of existing users.

                        Each user/group service uses a password policy to enforce these rules. The default GeoServer password policy implementation supports the following optional constraints:

                        • Passwords must contain at least one number
                        • Passwords must contain at least one upper case letter
                        • Passwords must contain at least one lower case letter
                        • Password minimum length
                        • Password maximum length
                        "},{"location":"security/passwd/#parametrized-passwords","title":"Parametrized Passwords","text":"

                        It is possible to parametrize users' passwords in a similar way to the catalog settings (see Parameterize catalog settings). Parametrization is supported when the encryption method used to store the place holder in the password field is plain text or is reversible (pbe, strong pbe). Non reversible encoding for the placeholder (e.g. digest) is not supported. On the contrary the actual value can be defined in the geoserver-environment.properties with any password encoding method supported by GeoServer. Examples are provided below:

                        pwd.one=plain:clear_text_password\npwd.two=digest1:D9miJH/hVgfxZJscMafEtbtliG0ROxhLfsznyWfG38X2pda2JOSV4POi55PQI4tw\npwd.three=crypt1:xZJscMafEtbtliG0ROxhLfsznyWfG38X2pda2JOSV4POi55PQI4tw\n
                        "},{"location":"security/rest/","title":"REST Security","text":"

                        In addition to providing the ability to secure OWS style services, GeoServer also supports securing RESTful services.

                        As with layer and service security, RESTful security configuration is based on security_roles. The mapping of request URI to role is defined in a file named rest.properties, located in the security directory of the GeoServer data directory.

                        "},{"location":"security/rest/#syntax","title":"Syntax","text":"

                        The following syntax defines access control rules for RESTful services (parameters in brackets [] are optional):

                        uriPattern;method[,method,...]=role[,role,...]\n

                        The parameters are:

                        • uriPattern---ant pattern that matches a set of request URIs
                        • method---HTTP request method, one of GET, POST, PUT, POST, DELETE, or HEAD
                        • role---Name of a predefined role. The wildcard '* is used to indicate the permission is applied to all users, including anonymous users.

                        Note

                        • URI patterns should account for the first component of the rest path, usually rest or api
                        • Method and role lists should not contain any spaces
                        "},{"location":"security/rest/#security_rest_ant_patterns","title":"Ant patterns","text":"

                        Ant patterns are commonly used for pattern matching directory and file paths. The examples section contains some basic instructions. The Apache ant user manual contains more sophisticated use cases.

                        "},{"location":"security/rest/#security_rest_examples","title":"Examples","text":"

                        Most of the examples in this section are specific to the GeoServer REST but any RESTful GeoServer service may be configured in the same manner.

                        "},{"location":"security/rest/#allowing-only-authenticated-access","title":"Allowing only authenticated access","text":"

                        The most secure configuration is one that forces any request to be authenticated. The following example locks down access to all requests:

                        /**;GET,POST,PUT,DELETE=ROLE_ADMINISTRATOR\n

                        A less restricting configuration locks down access to operations under the path /rest, but will allow anonymous access to requests that fall under other paths (for example /api):

                        /rest/**;GET,POST,PUT,DELETE=ROLE_ADMINISTRATOR\n

                        The following configuration is similar to the previous one except it grants access to a specific role rather than the administrator:

                        /**;GET,POST,PUT,DELETE=ROLE_TRUSTED\n

                        ROLE_TRUSTED is a role defined in users.properties.

                        "},{"location":"security/rest/#providing-anonymous-read-only-access","title":"Providing anonymous read-only access","text":"

                        The following configuration allows anonymous access when the GET (read) method is used but forces authentication for a POST, PUT, or DELETE (write):

                        /**;GET=IS_AUTHENTICATED_ANONYMOUSLY\n/**;POST,PUT,DELETE=TRUSTED_ROLE\n
                        "},{"location":"security/rest/#securing-a-specific-resource","title":"Securing a specific resource","text":"

                        The following configuration forces authentication for access to a particular resource (in this case a feature type):

                        /rest/**/states*;GET=TRUSTED_ROLE\n/rest/**;POST,PUT,DELETE=TRUSTED_ROLE\n

                        The following secures access to a set of resources (in this case all data stores):

                        /rest/**/datastores/*;GET=TRUSTED_ROLE\n/rest/**/datastores/*.*;GET=TRUSTED_ROLE\n/rest/**;POST,PUT,DELETE=TRUSTED_ROLE\n
                        "},{"location":"security/root/","title":"Root account","text":"

                        The highly configurable nature of GeoServer security may result in an administrator inadvertently disrupting normal authentication, essentially disabling all users including administrative accounts. For this reason, the GeoServer security subsystem contains a root account that is always active, regardless of the state of the security configuration. Much like its UNIX-style counterpart, this account provides \"super user\" status, and is meant to provide an alternative access method for fixing configuration issues.

                        The username for the root account is root. Its name cannot be changed and the password for the root account is the Keystore password.

                        "},{"location":"security/service/","title":"Service Security","text":"

                        GeoServer supports access control at the service level, allowing for the locking down of service operations to only authenticated users who have been granted a particular role. There are two main categories of services in GeoServer. The first is OWS services such as WMS and WFS. The second are RESTful services, such as the GeoServer REST.

                        Note

                        Service-level security and Layer security cannot be combined. For example, it is not possible to specify access to a specific OWS service only for one specific layer.

                        "},{"location":"security/service/#ows-services","title":"OWS services","text":"

                        OWS services support setting security access constraints globally for a particular service, or to a specific operation within that service. A few examples include:

                        • Securing the entire WFS service so only authenticated users have access to all WFS operations.
                        • Allowing anonymous access to read-only WFS operations such as GetCapabilities, but securing write operations such as Transaction.
                        • Disabling the WFS service in effect by securing all operations and not applying the appropriate roles to any users.

                        OWS service security access rules are specified in a file named services.properties, located in the security directory in the GeoServer data directory. The file contains a list of rules that map service operations to defined roles. The syntax for specifying rules is as follows:

                        <service>.<operation|*>=<role>[,<role2>,...]\n

                        The parameters include:

                        • []---Denotes optional parameters
                        • |---Denotes \"or\"
                        • service---Identifier of an OGC service, such as wfs, wms, or wcs
                        • operation---Any operation supported by the service, examples include GetFeature for WFS, GetMap for WMS, * for all operations
                        • role[,role2,...]---List of predefined role names

                        Note

                        It is important that roles specified are actually linked to a user, otherwise the whole service/operation will be accessible to no one except for the Root account. However in some cases this may be the desired effect.

                        The default service security configuration in GeoServer contains no rules and allows any anonymous user to access any operation of any service. The following are some examples of desired security restrictions and the corresponding rules.

                        "},{"location":"security/service/#securing-the-entire-wfs-service","title":"Securing the entire WFS service","text":"

                        This rule grants access to any WFS operation only to authenticated users that have been granted the ROLE_WFS role:

                        wfs.*=ROLE_WFS\n
                        "},{"location":"security/service/#anonymous-wfs-access-only-for-read-only-operations","title":"Anonymous WFS access only for read-only operations","text":"

                        This rule grants anonymous access to all WFS operations (such as GetCapabilities and GetFeature) but restricts Transaction requests to authenticated users that have been granted the ROLE_WFS_WRITE role:

                        wfs.Transaction=ROLE_WFS_WRITE\n
                        "},{"location":"security/service/#securing-data-accessing-wfs-operations-and-write-operations","title":"Securing data-accessing WFS operations and write operations","text":"

                        Used in conjunction, these two rules grant anonymous access to GetCapabilities and DescribeFeatureType, forcing the user to authenticate for the GetFeature operation (must be granted the ROLE_WFS_READ role), and to authenticate to perform transactions (must be granted the ROLE_WFS_WRITE role:

                        wfs.GetFeature=ROLE_WFS_READ\nwfs.Transaction=ROLE_WFS_WRITE\n

                        Note this example does not specify whether a user accessing Transactions would also have access to GetFeature.

                        "},{"location":"security/service/#security_service_rest","title":"REST services","text":"

                        In addition to providing the ability to secure OWS services, GeoServer also allows for the securing of RESTful services.

                        REST service security access rules are specified in a file named rest.properties, located in the security directory of the GeoServer data directory. This file contains a list of rules mapping request URIs to defined roles. The rule syntax is as follows:

                        <uriPattern>;<method>[,<method>,...]=<role>[,<role>,...]\n

                        The parameters include:

                        • []---Denote optional parameters
                        • uriPattern---The ant pattern that matches a set of request URIs
                        • method---HTTP request method, one of GET, POST, PUT, POST, DELETE, or HEAD
                        • role---Name of a predefined role. The wildcard * is used to indicate all users, including anonymous users.

                        Note

                        • URI patterns should account for the first component of the rest path, usually rest or api
                        • method and role lists should not contain any spaces
                        "},{"location":"security/service/#security_service_ant_patterns","title":"Ant patterns","text":"

                        Ant patterns are commonly used for pattern matching directory and file paths. The following examples provide some basic instructions. The Apache ant user manual contains more sophisticated use cases.

                        These examples are specific to GeoServer REST, but any RESTful GeoServer service could be configured in the same manner.

                        "},{"location":"security/service/#disabling-anonymous-access-to-services","title":"Disabling anonymous access to services","text":"

                        The most secure of configurations is one that forces any request, REST or otherwise, to be authenticated. The following will lock down access to all requests to users that are granted the ROLE_ADMINISTRATOR role:

                        /**;GET,POST,PUT,DELETE=ROLE_ADMINISTRATOR\n

                        A less restricting configuration locks down access to operations under the path /rest to users granted the ROLE_ADMINISTRATOR role, but will allow anonymous access to requests that fall under other paths (for example /api):

                        /rest/**;GET,POST,PUT,DELETE=ROLE_ADMINISTRATOR\n
                        "},{"location":"security/service/#allowing-anonymous-read-only-access","title":"Allowing anonymous read-only access","text":"

                        The following configuration grants anonymous access when the GET method is used, but forces authentication for a POST, PUT, or DELETE method:

                        /**;GET=IS_AUTHENTICATED_ANONYMOUSLY\n/**;POST,PUT,DELETE=TRUSTED_ROLE\n
                        "},{"location":"security/service/#securing-a-specific-resource","title":"Securing a specific resource","text":"

                        The following configuration forces authentication for access to a particular resource (in this case the states feature type):

                        /rest/**/states*;GET=TRUSTED_ROLE\n/rest/**;POST,PUT,DELETE=TRUSTED_ROLE\n

                        The following secures access to a set of resources (in this case all data stores).:

                        /rest/**/datastores/*;GET=TRUSTED_ROLE\n/rest/**/datastores/*.*;GET=TRUSTED_ROLE\n/rest/**;POST,PUT,DELETE=TRUSTED_ROLE\n

                        Note the trailing wildcards /* and /*.*.

                        "},{"location":"security/urlchecks/","title":"URL Checks","text":"

                        The URL External Access Checks page controls the checks that are performed on user provided URLs that GeoServer will use to access remote resources.

                        Currently, the checks are performed on the following functionality:

                        • WMS GetMap, GetFeatureInfo and GetLegendGraphic requests with remote SLD stylesheets (sld parameter)
                        • Remote icons referenced by styles (access to icons in the data directory is always allowed)
                        • WMS GetMap and GetFeatureInfo requests in feature portrayal mode (REMOTE_OWS and REMOTE_OWS_TYPE parameters)
                        • WPS remote inputs, either as GET or POST requests

                        External URLs configured by admins in the GUI (e.g. WFS, cascaded WMS & WMTS data stores) are not subject to this check.

                        Please refer back to this page for any additional remote service access checks added in the future.

                        "},{"location":"security/urlchecks/#configuration-of-url-checks","title":"Configuration of URL checks","text":"

                        Navigate to Data > URL Checks page to manage and configure URL Checks.

                        URL Checks table

                        Use the Enable/Disable URL Checks enable this safety feature:

                        • When the URL checks are enabled checkbox is enabled, URL checks are performed to limit GeoServer access to remote resources as outlined above.

                          Enabling URL checks is recommended to limit normal Open Web Service protocols interaction being used for Cross Site Scripting attacks.

                        • When checkbox disabled, URL checks are NOT enabled, GeoServer is provided unrestricted access to remote resources.

                          Disabling URL Checks is not a secure or recommended setting.

                        "},{"location":"security/urlchecks/#adding-a-regular-expression-based-check","title":"Adding a regular expression based check","text":"

                        The buttons for adding and removing URL checks can be found at the top of the URL Check list table.

                        To add a URL Check, press the Add new URL check button. You will be prompted to enter URL check details (as described in Editing a URL Check below).

                        "},{"location":"security/urlchecks/#removing-a-regular-expression-based-check","title":"Removing a regular expression based check","text":"

                        To remove a URL Check, select the checkbox next to one or more rows in the URL Check list table. Press the Remove selected URL checks button to remove. You will be asked to confirm or cancel the removal. Pressing OK removes the selected URL Checks.

                        "},{"location":"security/urlchecks/#security_urlchecks_edit","title":"Editing a URL Check","text":"

                        Regular Expression URL checks can be configured, with the following parameters for each check:

                        Field Description

                        Name Name for the check, used to identify it in the list.

                        Description Description of the check, for later reference.

                        Regular Expression A regular expression used to match allowed URLs

                        Enabled Check box to enable or disable the check

                        Configure Regular Expression URL check

                        "},{"location":"security/urlchecks/#testing-url-checks","title":"Testing URL checks","text":"

                        The Test URL Checks with external URL form allows a URL to be checked, reporting if access is allowed or disallowed.

                        Test URL Checks form:

                        Field Description

                        URL to check Supply URL of external resource to check if access is allowed

                        Press the Test URL button to perform the checks. If at least one URL Check matches the URL, it will be allowed and the test will indicate the URL Check permitting access. Otherwise it will be rejected and the test will indicate that no URL Check matched.

                        Test URL Checks with external URL

                        "},{"location":"security/urlchecks/#example-regex-patterns","title":"Example RegEx Patterns","text":"

                        The most common pattern allows matching a given host name to allow external graphics from a remote server. This pattern uses ^ to mark the start, the host URL, .* to match anything, and $ to end - as shown in the in following pattern:

                        ^https://styles\\.server\\.net/.*$

                        https://styles.server.net/logo.png\n

                        To allow external graphics from a specific directory on a remote server:

                        ^https://styles\\.server\\.net/icons/.*$

                        https://styles.server.net/icons/forest.png\n

                        When working with external graphics making use of SVG parameters use (\\?.*)?$ to optionally allow any query parameters after ?:

                        ^https://styles\\.server\\.net/icons/.*(\\?.*)?$

                        https://styles.server.net/icons/forest.png\nhttps://styles.server.net/icons/forest.svg?color=darkgreen\n

                        When obtaining content from an API \\?.* is used (as there is no need to support relative paths). As an example /geoserver/ows\\? is used below to access the GeoServer Open Web Service API:

                        ^https?://localhost:8080/geoserver/ows\\?.*$

                        http://localhost:8080/geoserver/ows?service=WMS&version=1.3.0&request=GetCapabilities\n

                        To allow for GeoServer virtual web services (\\w+/)? is used for optional workspace name:

                        ^https?://localhost:8080/geoserver/(\\w+/)?ows\\?.*$

                        http://localhost:8080/geoserver/ows?service=WMS&version=1.3.0&request=GetCapabilities\nhttp://localhost:8080/geoserver/ne/ows?service=WMS&version=1.3.0&request=GetCapabilities\n

                        To limit to Web Feature Service ?.*SERVICE=WFS.* is used to restrict query parameter:

                        ^https?://localhost:8080/geoserver/(\\w+/)?ows\\?.*SERVICE=WFS.*?$

                        http://localhost:8080/geoserver/tiger/ows?SERVICE=WFS&VERSION=1.0.0&REQUEST=GetFeature&TYPENAME=giant_polygon\n

                        To allowing WMS REMOTE_OWS data access to an external GeoServer WFS service:

                        ^https://mapping\\.server\\.net/geoserver/(\\w+/)?ows\\?.*SERVICE=WFS.*$

                        https://mapping.server.net/geoserver/ows?SERVICE=WFS&VERSION=1.0.0&REQUEST=GetFeature&TYPENAME=roads\n

                        To allow external graphic access to a remote GeoServer icons:

                        ^https://mapping\\.server\\.net/geoserver/styles/.*(\\?.*)?$

                        https://mapping.server.net/geoserver/styles/grass_fill.png\nhttps://mapping.server.net/geoserver/styles/ne/airport.svg?fill=gray\n

                        File paths can also be checked:

                        ^/var/opt/geoserver/data/.*$

                        /var/opt/geoserver/data/example.tiff\n

                        ^D:\\\\\\\\data\\\\.*$

                        D:\\\\data\\example.tiff\n

                        Note

                        The locations being checked are normalized making it easier to write RegEx patterns:

                        • URLs paths have been normalized to remove any redundant \\. or \\.. paths have been removed
                        • File URLs have been normalized so that file:/ is represented as file:///
                        • File paths have been normalized using / on Linux and \\ on Windows

                        Note

                        Web sites are available to help define a valid Java regular expression pattern. These tools can be used to interpret, explain and test regular expressions. For example:

                        • https://regex101.com/ (enable the Java 8 flavor)
                        • https://www.freeformatter.com/java-regex-tester.html
                        "},{"location":"security/auth/","title":"Authentication","text":"

                        There are three sets of GeoServer resources involved in authentication:

                        • The Web administration interface (also known as web admin)
                        • OWS services (such as WFS and WMS)
                        • REST services

                        The following sections describe how each set of GeoServer resources administers authentication. To configure the authentication settings and providers, please see the section on Authentication in the Web administration interface.

                        • Authentication chain
                        • Authenticating to the Web Admin Interface
                        • Authentication to OWS and REST services
                        • Authentication providers
                        "},{"location":"security/auth/chain/","title":"Authentication chain","text":"

                        Understanding the authentication chain helps explain how GeoServer authentication works. The authentication chain processes requests and applies certain authentication mechanisms. Examples of authentication mechanisms include:

                        • Username/password---Performs authentication by looking up user information in an external user database
                        • Browser cookie---Performs authentication by recognizing previously sent browser cookies (also known as \"Remember Me\")
                        • LDAP---Performs authentication against an LDAP database
                        • Anonymous---Essentially performs no authentication and allows a request to proceed without any credentials

                        Multiple authentication mechanisms may be active within GeoServer at a given time. The following figure illustrates the flow of a generic request.

                        Flow of a request through the authentication system

                        Before dispatching a request to the appropriate service or handler, GeoServer first filters the request through the authentication chain. The request is passed to each mechanism in the chain in order, and each is given the chance to authenticate the request. If one of the mechanisms in the chain is able to successfully authenticate, the request moves to normal processing. Otherwise the request is not routed any further and an authorization error (usually a HTTP 401) is returned to the user.

                        "},{"location":"security/auth/chain/#filter-chain-and-provider-chain","title":"Filter chain and provider chain","text":"

                        In the case of GeoServer, the authentication chain is actually made up of two chains: a filter chain, which determine if further authentication of a request is required, and a provider chain, which performs the actual authentication.

                        Detail of authentication chain, showing filter chain and provider chain

                        The filter chain performs a variety of tasks, including:

                        • Gathering user credentials from a request, for example from Basic and Digest Authentication headers
                        • Handling events such as ending the session (logging out), or setting the \"Remember Me\" browser cookie
                        • Performing session integration, detecting existing sessions and creating new sessions if necessary
                        • Invoking the authentication provider chain to perform actual authentication

                        The filter chain is actually processed twice, before and after the request is handled.

                        The provider chain is concerned solely with performing the underlying authentication of a request. It is invoked by the filter chain when a filter determines that authentication is required.

                        "},{"location":"security/auth/chain/#filter-chain-by-request-type","title":"Filter chain by request type","text":"

                        A different filter chain can be applied to each different type of request in GeoServer. This happens because the administrator can configure a list of different filter chains and a matching rule for each of them. Only the first matching chain of the configured ordered list will be applied to any given request.

                        Matching rules can be applied to:
                        • HTTP Method (GET, POST, etc.)
                        • one or more ANT patterns for the path section of the request (e.g /wms/**); if more than one pattern (comma delimited) is specified, any of them will match
                        • an optional regular expression to match parameters on the query string, for one or more of the specified ANT pattern; if the path matches, also the query string is checked for matching; the regular expression can be specified after the ANT pattern, with a pipe (|) separator
                        ANT Patterns support the following wildcards:
                        • ? matches one character
                          • matches zero or more characters
                        • ** matches zero or more 'directories' in a path

                        Query String regular expressions will match the full query string (\\^ and \\$ terminators are automatically appended), so to match only part of it, remember to prefix and postfix the expression with . (e.g. .request=getcapabilities.*)

                        "},{"location":"security/auth/chain/#examples-of-rules-ant-patterns-and-query-string-regular-expressions","title":"Examples of rules (ANT patterns and query string regular expressions)","text":"

                        Pattern Description

                        /wms, /wms/** simple ANT pattern

                        /wms|.request=GetMap. ANT pattern and querystring regex to match one parameter

                        /wms|(?=.request=getmap)(?=.format=image/png).* ANT pattern and querystring regex to match two parameters in any order

                        /wms|(?=.request=getmap)(?!.format=image/png).* ANT pattern and querystring regex to match one parameters and be sure another one is not matched

                        "},{"location":"security/auth/owsrest/","title":"Authentication to OWS and REST services","text":"

                        OWS and REST services are stateless and have no inherent awareness of \"session\", so the authentication scheme for these services requires the client to supply credentials on every request. That said, \"session integration\" is supported, meaning that if a session already exists on the server (from a concurrent authenticated web admin session) it will be used for authentication. This scheme allows GeoServer to avoid the overhead of session creation for OWS and REST services.

                        The default GeoServer configuration ships with support for HTTP Basic authentication for services.

                        The typical process of authentication is as follows:

                        1. User makes a service request without supplying any credentials
                        2. If the user is accessing an unsecured resource, the request is handled normally
                        3. If the user is accessing a secured resource:
                        • An HTTP 401 status code is sent back to the client, typically forcing the client to prompt for credentials.
                        • The service request is then repeated with the appropriate credentials included, usually in the HTTP header as with Basic Authentication.
                        • If the user has sufficient privileges to access the resource the request is handled normally, otherwise, a HTTP 404 status code is returned to the client.
                        1. Subsequent requests should include the original user credentials
                        "},{"location":"security/auth/owsrest/#examples","title":"Examples","text":"

                        The following describes the authentication chain for an OWS service:

                        The OWS service authentication chain

                        In this example the filter chain consists of three filters:

                        • Session---Handles \"session integration\", recognizing existing sessions (but not creating new sessions)
                        • Basic Auth---Extracts Basic Authentication credentials from request HTTP header
                        • Anonymous---Handles anonymous access

                        The provider chain is made up of two providers:

                        • Root---Root account has a special \"super user\" provider. As this account is rarely used, this provider is rarely invoked.
                        • Username/password---Performs username/password authentication against a user database

                        To illustrate how the elements of the various chains work, here are some example OWS requests.

                        "},{"location":"security/auth/owsrest/#anonymous-wms-getcapabilities-request","title":"Anonymous WMS GetCapabilities request","text":"

                        This example shows the process for when a WMS client makes an anonymous GetCapabilities request.

                        Authentication chain for a WMS client making an anonymous GetCapabilities request

                        The Session filter looks for an existing session, but finds none, so processing continues. The Basic Auth filter looks for the Basic Authorization header in the request, but as the request is anonymous, the filter finds none. Finally, the Anonymous filter executes and authenticates the request anonymously. Since GetCapabilities is a \"discovery\" operation it is typically not locked down, even on a secure server. Assuming this is the case here, the anonymous request succeeds, returning the capabilities response to the client. The provider chain is not invoked.

                        "},{"location":"security/auth/owsrest/#anonymous-wms-getmap-request-for-a-secured-layer","title":"Anonymous WMS GetMap request for a secured layer","text":"

                        This example shows the process invoked when a WMS client makes an anonymous GetMap request for a secured layer

                        The chain executes exactly as described above. The Session filter looks for an existing session, but finds none, so processing continues. The Basic Auth filter looks for the Basic Authorization header in the request, but as the request is anonymous, the filter finds none. Finally, the Anonymous filter executes and authenticates the request anonymously. However, in this case the layer being accessed is a secured resource, so the handling of the GetMap request fails. The server returns an exception accompanied with a HTTP 401 status code, which usually triggers the client presenting the user with a login dialog.

                        "},{"location":"security/auth/owsrest/#wms-getmap-request-with-user-supplied-credentials","title":"WMS GetMap request with user-supplied credentials","text":"

                        This example shows the process invoked when a WMS client gathers credentials from the user and reissues the previous request for a secured layer.

                        Authentication chain for a WMS client making a GetMap request with user-supplied credentials

                        The Session filter executes as described above, and does nothing. The Basic Auth filter finds the authorization header in the request, extracts the credentials for it, and invokes the provider chain. Processing moves to the Username/password provider that does the actual authentication. If the credentials have the necessary privileges to access the layer, the processing of the request continues normally and the GetMap request succeeds, returning the map response. If the credentials are not sufficient, the HTTP 401 status code will be supplied instead, which may again trigger the login dialog on the client side.

                        "},{"location":"security/auth/providers/","title":"Authentication providers","text":"

                        The following authentication providers are available in GeoServer:

                        • Authentication of a username/password against a user/group service
                        • Authentication against an LDAP server
                        • Authentication by connecting to a database through JDBC
                        "},{"location":"security/auth/providers/#security_auth_provider_userpasswd","title":"Username/password authentication","text":"

                        Username and password authentication is the default authentication provider. It uses a user/group service to authenticate.

                        The provider simply takes the username/password from an incoming request (such as a Basic Authentication request), then loads the user information from the user/group service and verifies the credentials.

                        "},{"location":"security/auth/providers/#security_auth_provider_ldap","title":"LDAP authentication","text":"

                        The LDAP authentication provider allows for authentication against a Lightweight Directory Access Protocol (LDAP) server. The provider takes the username/password from the incoming request and attempts to connect to the LDAP server with those credentials.

                        Note

                        Currently only LDAP Bind authentication is supported.

                        "},{"location":"security/auth/providers/#role-assignment","title":"Role assignment","text":"

                        The LDAP provider offers two options for role assignment for authenticated users:

                        • Convert the user's LDAP groups into roles
                        • Employ a user/group service

                        The following LDAP database will illustrate the first option:

                        dn: ou=people,dc=acme,dc=com\nobjectclass: organizationalUnit\nou: people\n\ndn: uid=bob,ou=people,dc=acme,dc=com\nobjectclass: person\nuid: bob\n\ndn: ou=groups,dc=acme,dc=com\nobjectclass: organizationalUnit\nou: groups\n\ndn: cn=workers,ou=groups,dc=acme,dc=com\nobjectclass: groupOfNames\ncn: users\nmember: uid=bob,ou=people,dc=acme,dc=com\n

                        The above scenario defines a user with the uid of bob, and a group named workers of which bob is a member. After authentication, bob will be assigned the role ROLE_WORKERS. The role name is generated by concatenating ROLE_ with the name of the group in upper case.

                        Note

                        When the LDAP server doesn't allow searching in an anonymous context, the bindBeforeGroupSearch option should be enabled to avoid errors.

                        In the case of using a user/group service, the user/group service is queried for the user following authentication, and the role assignment is performed by both the user/group service and the active role service. When using this option, any password defined for the user in the user/group service database is ignored.

                        "},{"location":"security/auth/providers/#security_auth_provider_ldap_secure","title":"Secure LDAP connections","text":"

                        There are two ways to create a secure LDAP connection with the server. The first is to directly specify a secure connection by using the ldaps protocol as part of the Server URL. This typically requires changing the connection port to port 636 rather than 389.

                        The second method involves using STARTTLS (Transport Layer Security) to negotiate a secure connection over a non-secure one. The negotiation takes place over the non-secure URL using the \"ldap\" protocol on port 389. To use this option, the Use TLS flag must be set.

                        Warning

                        Using TLS for connections will prevent GeoServer from being able to pool LDAP connections. This means a new LDAP connection will be created and destroyed for each authentication, resulting in loss of performance.

                        "},{"location":"security/auth/providers/#security_auth_provider_jdbc","title":"JDBC authentication","text":"

                        The JDBC authentication provider authenticates by connecting to a database over JDBC.

                        The provider takes the username/password from the incoming request and attempts to create a database connection using those credentials. Optionally the provider may use a user/group service to load user information after a successful authentication. In this context the user/group service will not be used for password verification, only for role assignment.

                        Note

                        To use the user/group service for password verification, please see the section on Username/password authentication.

                        "},{"location":"security/auth/web/","title":"Authenticating to the Web Admin Interface","text":"

                        The method of authenticating to the Web administration interface application is typical of most web applications that provide login capabilities. The application is based primarily on form-based authentication, in which a user authenticates through a form in a web browser. Upon successful authentication a session is created on the server, eliminating the need for a user to repeat the login process for each page they wish to access. An optional \"Remember Me\" setting is also supported which will store authentication information in a client-side cookie to allow the user to bypass the form-based authentication after the initial session has timed out.

                        The typical process of authentication is as follows:

                        1. User visits the home page of the web admin for the very first time, so neither a session or \"Remember Me\" cookie is present. In this case, the user is anonymously authenticated.
                        2. User accesses a secured page and is presented with a login form.
                        3. Upon successful login a session is created. Depending on the privileges of the account used to log in, the user will either be directed to the requested page or be redirected back to the home page.
                        4. Upon subsequent requests to secured pages, the user is authenticated via browser session until the session expires or the user logs out.
                        "},{"location":"security/auth/web/#examples","title":"Examples","text":"

                        The following shows the default configuration of the authentication chain for the web admin.

                        GeoServer authentication chain, with filter and provider chains

                        In this example the filter chain is made up of the following filters:

                        • Session---Handles session integration, recognizing existing sessions and creating new sessions on demand
                        • Logout---Handles ending sessions (user logout)
                        • Form login---Handles form logins
                        • Remember Me---Handles \"Remember Me\" authentication, reading when the flag is set on a form login, creating the appropriate cookie, and recognizing the cookie on future requests
                        • Anonymous---Handles anonymous access

                        The provider chain is made up of two providers:

                        • Root---The Root account has a special \"super user\" provider. As this account is rarely used, this provider is rarely invoked.
                        • Username/password---Performs username/password authentication against a user database.

                        To following example requests illustrate how the elements of the various chains work.

                        "},{"location":"security/auth/web/#first-time-visit","title":"First time visit","text":"

                        This example describes the process when a user visits the home page of the web admin for the first time.

                        Authentication chain for a first time visit from a user

                        The first filter to execute is the Session filter. It checks for an existing session, but finds none, so processing continues to the next filter in the chain. The Logout filter checks for the case of a user logging out, which also is not the case, so processing continues. The Form login filter checks for a form login, and also finds none. The Remember Me filter determines if this request can be authenticated from a previous session cookie, but in this case it cannot. The final filter to execute is the Anonymous filter which checks if the user specified any credentials. In this case the user has not provided any credentials, so the request is authenticated anonymously. Since no authentication is required to view the home page, the provider chain is not invoked.

                        The last response to the request directs the user to the home page.

                        "},{"location":"security/auth/web/#user-logs-on","title":"User logs on","text":"

                        This examples describes the process invoked when a user logs on to the web admin via the login form.

                        Authentication chain for a user logging in

                        The Session filter finds no existing session, and processing continues. The Logout filter checks for a logout request, finds none, and continues. The Form login filter recognizes the request as a form login and begins the authentication process. It extracts the username and password from the request and invokes the provider chain.

                        In the provider chain, the Root provider checks for the root account login, but doesn't find it so processing continues to the next provider. The Username/password provider checks if the supplied credentials are valid. If they are valid the authentication succeeds, user is redirected to the home page and is considered to be logged on. During the post-processing step the Session filter recognizes that a successful authentication has taken place and creates a new session.

                        If the credentials are invalid, the user will be returned to the login form page and asked to try again.

                        "},{"location":"security/auth/web/#user-visits-another-page","title":"User visits another page","text":"

                        This example describes the process invoked when a user who is already logged on visits another page in the web admin.

                        Authentication chain for a user visiting another page after logging in

                        The Session filter executes and finds an existing session that is still valid. The session contains the authentication details and no further chain processing is required. The response is the page requested by the user.

                        "},{"location":"security/auth/web/#user-returns-after-session-time-out","title":"User returns after session time out","text":"

                        This example describes the process invoked when a user returns to the web admin after the previously created session has timed out.

                        A session will time out after a certain period of time. When the user returns to the web admin, this becomes essentially the same chain of events as the user visiting the web app for the first time (as described previously). The chain proceeds to the Anonymous filter that authenticates anonymously. Since the page requested is likely to be a page that requires authentication, the user is redirected to the home page and is not logged on.

                        "},{"location":"security/auth/web/#user-logs-on-with-remember-me-flag-set","title":"User logs on with \"Remember Me\" flag set","text":"

                        This example describes the process for logging on with the \"Remember Me\" flag set.

                        The chain of events for logging on with \"Remember Me\" set is identical to the process for when the flag is not set, except that after the successful authentication the Form login filter recognizes the \"Remember Me\" flag and triggers the creation of the browser cookie used to persist the authentication information. The user is now logged on and is directed to the home page.

                        "},{"location":"security/auth/web/#user-returns-after-session-time-out-with-remember-me","title":"User returns after session time out (with \"Remember Me\")","text":"

                        This example describes the process invoked when the user returns to the web admin after a period of inactivity, while the \"Remember Me\" flag is set.

                        Authentication chain for a user returning after session time out with the \"Remember Me\" flag

                        Even though the \"Remember Me\" flag is set, the user's session on the server will still time out as normal. As such, the chain proceeds accordingly through the filters, starting with the Session filter, which finds no valid session. The Logout and Form login filters do not apply here. The Remember Me filter recognizes the browser cookie and is able to authenticate the request. The user is directed to whatever page was accessed and remains logged on.

                        "},{"location":"security/tutorials/","title":"Tutorials","text":"
                        • Authentication with LDAP
                        • Authentication with LDAP against ActiveDirectory
                        • Configuring Digest Authentication
                        • Configuring X.509 Certificate Authentication
                        • Configuring J2EE Authentication
                        • Configuring HTTP Header Proxy Authentication
                        • Configuring Apache HTTPD Session Integration
                        • Authentication with CAS
                        "},{"location":"security/tutorials/activedirectory/","title":"Authentication with LDAP against ActiveDirectory","text":"

                        This tutorial explains how to use GeoServer LDAP support to connect to a Windows Domain using ActiveDirectory as an LDAP server. It is recommended that the LDAP authentication section be read before proceeding.

                        "},{"location":"security/tutorials/activedirectory/#windows-server-and-activedirectory","title":"Windows Server and ActiveDirectory","text":"

                        Active Directory is just another LDAP server implementation, but has some features that we must know to successfully use it with GeoServer LDAP authentication. In this tutorial we will assume to have a Windows Server Domain Controller with ActiveDirectory named domain-controller for a domain named ad.local. If your environment uses different names (and it surely will) use your real names where needed.

                        We will also assume that:

                        • a group named GISADMINGROUP exists.
                        • a user named GISADMIN exists, has password secret, and belongs to the GISADMINGROUP group.
                        • a user named GISUSER exists, has password secret, and does NOT belong to the GISADMINGROUP group.

                        Note

                        ADMINISTRATOR cannot be generally used as the admin group name with ActiveDirectory, because Administrator is the root user name in Windows environment.

                        "},{"location":"security/tutorials/activedirectory/#configure-the-ldap-authentication-provider","title":"Configure the LDAP authentication provider","text":"
                        1. Start GeoServer and login to the web admin interface as the admin user.

                        2. Click the Authentication link located under the Security section of the navigation sidebar.

                        3. Scroll down to the Authentication Providers panel and click the Add new link.

                        4. Click the LDAP link.

                        5. Fill in the fields of the settings form as follows:

                          • Set Name to \"ad-ldap\"
                          • Set Server URL to \"
                          • Set Filter used to lookup user to (|(userPrincipalName={0})(sAMAccountName={1}))
                          • Set Format used for user login name to \"{0%7D@ad.local\"
                          • Check Use LDAP groups for authorization
                          • Check Bind user before searching for groups
                          • Set Group to use as ADMIN to \"GISADMINGROUP\"
                          • Set Group search base to \"cn=Users\"
                          • Set Group search filter to \"member={0}\"
                          • Test the LDAP connection by entering the username \"GISADMIN\" and password \"secret\" in the connection test form located on the right and click the Test Connection button.

                            A successful connection should be reported at the top of the page.

                          • Save.

                          • Back on the authentication page scroll down to the Provider Chain panel and move the ad-ldap provider from Available to Selected.

                          • Save.

                          • "},{"location":"security/tutorials/activedirectory/#test-a-ldap-login","title":"Test a LDAP login","text":"
                            1. Navigate to the GeoServer home page and log out of the admin account.
                            "},{"location":"security/tutorials/activedirectory/#login-as-the-user-gisuser-with-the-password-secret","title":". Login as the user \"GISUSER\" with the password \"secret\".","text":"

                            Logging in as GISUSER doesn't yield any administrative functionality because the GISUSER account has not been mapped to the administrator role. In the next section GeoServer will be configured to map groups from the LDAP database to roles.

                            Now we will login with a user having administrative rights.

                            1. Navigate to the GeoServer home page and log out of the account.
                            2. Login as the user \"GISADMIN\" with the password \"secret\".

                            Once logged in full administrative functionality should be available.

                            "},{"location":"security/tutorials/activedirectory/#configure-the-ldap-role-service","title":"Configure the LDAP role service","text":"

                            An additional step permits to configure a role service to get GeoServer roles from the LDAP repository and allow access rights to be assigned to those roles.

                            1. Click the Users,Group,Roles link located under the Security section of the navigation sidebar.

                            2. Click the Add new link under the Role Services section.

                            3. Click the LDAP option under the New Role Service section.

                            4. Enter ldapadrs in the Name text field.

                            5. Enter ldap://domain-controller/dc=ad,dc=local in the Server URL text field.

                            6. Enter CN=Users in the Group search base text field.

                            7. Enter member={1},dc=ad,dc=local in the Group user membership search filter text field.

                            8. Enter objectClass=group in the All groups search filter text field.

                            9. Enter sAMAccountName={0} in the Filter used to lookup user text field.

                            Then we need to a choose a user to authenticate on the server (many LDAP server don't allow anonymous data lookup).

                            1. Check the Authenticate to extract roles checkbox.
                            2. Enter GISADMIN@ad.local in the Username text field.
                            3. Enter secret in the Password text field.
                            4. Save.
                            5. Click the ldapadrs role service item under the Role Services section.
                            6. Select ROLE_DOMAIN ADMINS from the Administrator role combo-box.
                            7. Select ROLE_DOMAIN ADMINS from the Group administrator role combo-box.
                            8. Save again.

                            You should now be able to see and assign the new ActiveDirectory roles wherever an Available Roles list is shown (for example in the Data and Services rules sections.

                            "},{"location":"security/tutorials/cas/","title":"Authentication with CAS","text":"

                            This tutorial introduces GeoServer CAS support and walks through the process of setting up authentication against a CAS server. It is recommended that the Authentication chain section be read before proceeding. Reference information on cas setup is also available CAS integration.

                            "},{"location":"security/tutorials/cas/#cas-server-certificates","title":"CAS server certificates","text":"

                            A running CAS server is needed.

                            The first step is to import the server certificates into the GeoServer JVM.

                            If you need to export the CRT from the CAS server, you must execute the following command on the server JVM:

                            keytool -export -alias <server_name> -keystore <cas_jvm_keystore_path> -file server.crt\n

                            Once you have the server.crt file, the procedure to import the certificate into the JVM is the following one:

                            keytool -import -trustcacerts -alias <server_name> -file server.crt -keystore <path_to_JRE_cacerts>\n

                            Enter the keystore password and confirm the certificate to be trustable.

                            "},{"location":"security/tutorials/cas/#configure-the-cas-authentication-provider","title":"Configure the CAS authentication provider","text":"
                            1. Start GeoServer and login to the web admin interface as the admin user.

                            2. Click the Authentication link located under the Security section of the navigation sidebar.

                            3. Scroll down to the Authentication Filters panel and click the Add new link.

                            4. Click the CAS link.

                            5. Fill in the fields of the settings form as follows:

                            6. Update the filter chains by adding the new CAS filter.

                            7. Select the CAS Filter for each filter chain you want to protect with CAS.

                              Be sure to select and order correctly the CAS Filter.

                            8. Save.

                            "},{"location":"security/tutorials/cas/#test-a-cas-login","title":"Test a CAS login","text":"
                            1. Navigate to the GeoServer home page and log out of the admin account.

                            2. Try to login again, you should be able now to see the external CAS login form.

                            "},{"location":"security/tutorials/cert/","title":"Configuring X.509 Certificate Authentication","text":"

                            Certificate authentication involves the usage of public/private keys to identify oneself. This represents a much more secure alternative to basic username and password schemes.

                            X.509 is a well defined standard for the format of public key certificates. This tutorial walks through the process of setting up X.509 certificate authentication.

                            "},{"location":"security/tutorials/cert/#prerequisites","title":"Prerequisites","text":"

                            This tutorial assumes the following:

                            • A web browser that supports the usage of client certificates for authentication, also referred to as \"two-way SSL\". This tutorial uses Firefox.
                            • An SSL-capable servlet container. This tutorial uses Tomcat.
                            • GeoServer is deployed in Tomcat.
                            "},{"location":"security/tutorials/cert/#configure-the-usergroup-service","title":"Configure the user/group service","text":"

                            Users authenticated via a X.509 certificate must be configured in GeoServer. For this a new user/group service will be added.

                            1. Login to the web admin interface as the admin user.

                            2. Click the Users, Groups, and Roles link located under the Security section of the navigation sidebar.

                            3. Scroll down to the User Group Services panel and click the Add new link.

                            4. Create a new user/group service named cert-ugs and fill out the settings form as follows:

                              • Set Password encryption to Empty since users will not authenticate via password.
                              • Set Password policy to default.

                            5. Click Save.

                            6. Back on the Users, Groups, and Roles page, click the cert-ugs link.

                            7. Select the Users tab and click the Add new user link.

                            8. Add a new user named rod the and assign the ADMIN role.

                            9. Click Save.

                            10. Click the Authentication link located under the Security section of the navigation sidebar.

                            11. Scroll down to the Authentication Filters panel and click the Add new link.

                            12. Click the X.509 link and fill out form as follows:

                              • Set Name to \"cert\"
                              • Set Role source to User group service and set the associated drop-down to cert-ugs

                            13. Click Save.

                            14. Back on the authentication page, scroll down to the Filter Chains panel.

                            15. Click web in the Name column.

                            16. Select the cert filter and position it after the rememberme filter.

                            17. Click Close.

                            18. You will be returned to the previous page. Click Save.

                              Warning

                              This last change requires both Close and then Save to be clicked. You may wish to return to the web dialog to verify that the change was made.

                            "},{"location":"security/tutorials/cert/#download-sample-certificate-files","title":"Download sample certificate files","text":"

                            Rather than demonstrate how to create or obtain valid certificates, which is beyond the scope of this tutorial, sample files available as part of the spring security sample applications will be used.

                            Download and unpack the sample certificate files. This archive contains the following files:

                            • ca.pem is the certificate authority (CA) certificate issued by the \"Spring Security Test CA\" certificate authority. This file is used to sign the server and client certificates.
                            • server.jks is the Java keystore containing the server certificate and private key used by Tomcat and presented to the user during the setup of the SSL connection.
                            • rod.p12 contains the client certificate / key combination used to perform client authentication via the web browser.
                            "},{"location":"security/tutorials/cert/#configure-tomcat-for-ssl","title":"Configure Tomcat for SSL","text":"
                            1. Copy the server.jks file into the conf directory under the root of the Tomcat installation.

                            2. Edit the Tomcat conf/server.xml and add an SSL connector:

                              <Connector port=\"8443\" protocol=\"HTTP/1.1\" SSLEnabled=\"true\" scheme=\"https\" secure=\"true\"\n     clientAuth=\"true\" sslProtocol=\"TLS\" \n     keystoreFile=\"${catalina.home}/conf/server.jks\"\n     keystoreType=\"JKS\" keystorePass=\"password\"\n     truststoreFile=\"${catalina.home}/conf/server.jks\"\n     truststoreType=\"JKS\" truststorePass=\"password\" />\n

                              This enables SSL on port 8443.

                            3. By default, Tomcat has APR enabled. To disable it so the above configuration can work, remove or comment out the following line in the server.xml configuration file

                              <Listener className=\"org.apache.catalina.core.AprLifecycleListener\" SSLEngine=\"on\" />   \n
                            4. Restart Tomcat.

                            "},{"location":"security/tutorials/cert/#install-the-client-certificate","title":"Install the client certificate","text":"
                            1. In Firefox, select Preferences (or Tools \u2192 Options) and navigate to the Advanced panel.

                            2. Select the Encryption tab (or the Certificates tab, depending on your version) and click the View Certificates button.

                            3. On the Your Certificates panel click the Import button and select the rod.p12 file.

                            4. When prompted enter in the password password.

                            5. Click OK and close the Firefox Preferences.

                            "},{"location":"security/tutorials/cert/#test-certificate-login","title":"Test certificate login","text":"
                            1. Navigate to the GeoServer admin on port \"8443\" using HTTPS: https://localhost:8443/geoserver/web

                            2. You will be prompted for a certificate. Select the rod certificate for identification.

                            "},{"location":"security/tutorials/cert/#when-warned-about-the-self-signed-server-certificate-click-add-exception-to-add-a-security-exception","title":". When warned about the self-signed server certificate, click Add Exception to add a security exception.","text":"

                            The result is that the user rod is now logged into the GeoServer admin interface.

                            Note

                            Starting with version 31, Firefox implements a new mechanism for using certificates, which will cause a Issuer certificate is invalid error (sec_error_ca_cert_invalid) error when trying to use a self-signed repository such as the one proposed. To avoid that, you can disable this mechanism by browsing to about:config and setting the security.use_mozillapkix_verification parameter to false.

                            "},{"location":"security/tutorials/credentialsfromheaders/","title":"Configuring Apache HTTPD Session Integration","text":""},{"location":"security/tutorials/credentialsfromheaders/#introduction","title":"Introduction","text":"

                            When using Apache HTTPD as a proxy frontend for GeoServer, it is possible to share authentication with a proper configuration of both.

                            This requires enabling Session for the GeoServer location in Apache HTTPD and adding a custom Request Header with the session content, so that the GeoServer security system can receive user credentials and use them to authenticate the user with its internal filters.

                            To properly parse the received credentials we need to use the Credentials From Request Headers Authentication Filter.

                            Please note that the header containing the password is not sent back and forth to the user browser, but only from Apache HTTPD to GeoServer, so the password is not sent in clear through the public network.

                            This tutorial shows how to configure GeoServer to read user credentials from the Apache HTTPD Session and use them for authentication purposes.

                            "},{"location":"security/tutorials/credentialsfromheaders/#prerequisites","title":"Prerequisites","text":"

                            This tutorial uses the curl utility to issue HTTP request that test authentication. Install curl before proceeding.

                            "},{"location":"security/tutorials/credentialsfromheaders/#configure-the-credentials-from-request-headers-filter","title":"Configure the Credentials From Request Headers filter","text":"
                            1. Start GeoServer and login to the web admin interface as the admin user.

                            2. Click the Authentication link located under the Security section of the navigation sidebar.

                            3. Scroll down to the Authentication Filters panel and click the Add new link.

                            4. Click the Credentials From Headers link.

                            5. Fill in the fields of the settings form as follows:

                              • Set Name to \"apachessesion\"
                              • Set Username Header to \"X-Credentials\"
                              • Set Regular Expression for Username to \"private-user=([\\^&]*)\"
                              • Set Password Header to \"X-Credentials\"
                              • Set Regular Expression for Password to \"private-pw=([\\^&]*)\"

                            6. Save.

                            7. Back on the authentication page scroll down to the Filter Chains panel.

                            8. Click on \"default\" in the chain grid.

                            9. Scroll down and remove all filters from the Selected list and add the apachessesion filter.

                            10. Close.

                            11. Save.

                            "},{"location":"security/tutorials/credentialsfromheaders/#test-a-login","title":"Test a login","text":"
                            1. Execute the following curl command (with a wrong password):

                              curl -v -H \"X-Credentials: private-user=admin&private-pw=wrong\" \"http://localhost:8080/geoserver/wms?service=WMS&version=1.1.1&request=GetCapabilities\"\n

                              The result should be a 403 response signaling that access is denied. The output should look something like the following:

                              * About to connect() to localhost port 8080 (#0)\n*   Trying ::1... connected\n> GET /geoserver/wfs?request=getcapabilities HTTP/1.1\n> User-Agent: curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n> Host: localhost:8080\n> Accept: */*\n> \n< HTTP/1.1 403 Access Denied\n< Content-Type: text/html; charset=iso-8859-1\n< Content-Length: 1407\n< Server: Jetty(6.1.8)\n< \n<html>\n<head>\n<meta http-equiv=\"Content-Type\" content=\"text/html; charset=ISO-8859-1\"/>\n<title>Error 403 Access Denied</title>\n</head>\n    ...\n
                            2. Execute the same command but specify the right password.:

                              curl -v -H \"X-Credentials: private-user=admin&private-pw=geoserver\" \"http://localhost:8080/geoserver/wms?service=WMS&version=1.1.1&request=GetCapabilities\"\n

                              The result should be a successful authentication and contain the normal WMS capabilities response.

                            "},{"location":"security/tutorials/credentialsfromheaders/#configure-apache-httpd-to-forward-an-header-with-authentication-credentials","title":"Configure Apache HTTPD to forward an Header with authentication credentials","text":"

                            This can be done with an HTTPD configuration that looks like the following:

                            <Location  /geoserver>\n    Session On\n    SessionEnv On\n    SessionHeader X-Replace-Session\n    SessionCookieName session path=/\n    SessionCryptoPassphrase secret\n    RequestHeader set X-Credentials \"%{HTTP_SESSION}e\"\n</Location>\n

                            This configuration adds a new X-Credentials Request Header to each GeoServer request. The request header will contain the HTTPD Session information in a special format.

                            An example of the Session content is the following:

                            X-Credentials: private-user=admin&private-pw=geoserver

                            As you can see it contains both the username and password of the user, so the data can be used to authenticate the user in GeoServer.

                            "},{"location":"security/tutorials/digest/","title":"Configuring Digest Authentication","text":""},{"location":"security/tutorials/digest/#introduction","title":"Introduction","text":"

                            Out of the box GeoServer REST and OGC services support authentication via HTTP Basic authentication. One of the major downsides of basic auth is that it sends user passwords in plain text. HTTP Digest authentication offers a more secure alternative that applies a cryptographic hash function to passwords before sending them over the network.

                            This tutorial walks through the process of setting up digest authentication.

                            "},{"location":"security/tutorials/digest/#prerequisites","title":"Prerequisites","text":"

                            This tutorial uses the curl utility to issue HTTP request that test authentication. Install curl before proceeding.

                            Note

                            Any utility that supports both basic and digest authentication can be used in place of curl. Most modern web browsers support both types of authentication.

                            "},{"location":"security/tutorials/digest/#configure-the-digest-authentication-filter","title":"Configure the Digest authentication filter","text":"
                            1. Start GeoServer and login to the web admin interface as the admin user.

                            2. Click the Authentication link located under the Security section of the navigation sidebar.

                            3. Scroll down to the Authentication Filters panel and click the Add new link.

                            4. Click the Digest link.

                            5. Fill in the fields of the settings form as follows:

                              • Set Name to \"digest\"
                              • Set User group service to \"default\"

                            6. Save.

                            7. Back on the authentication page scroll down to the Filter Chains panel.

                            8. Select \"Default\" from the Request type drop down.

                            9. Unselect the basic filter and select the digest filter. Position the the digest filter before the anonymous filter.

                            10. Save.

                            "},{"location":"security/tutorials/digest/#secure-ogc-service-requests","title":"Secure OGC service requests","text":"

                            In order to test the authentication settings configured in the previous section a service or resource must be first secured. The Default filter chain is the chain applied to all OGC service requests so a service security rule must be configured.

                            1. From the GeoServer home page and click the Services link located under the Security section of the navigation sidebar.

                            2. On the Service security page click the Add new rule link and add a catch all rule that secures all OGC service requests requiring the ROLE_ADMINISTRATOR role.

                            3. Save.

                            "},{"location":"security/tutorials/digest/#test-a-digest-authentication-login","title":"Test a digest authentication login","text":"
                            1. Ensure that basic authentication is disabled execute the following curl command:

                              curl -v -u admin:geoserver -G \"http://localhost:8080/geoserve/wfs?request=getcapabilities\"\n

                              The result should be a 401 response signaling that authentication is required. The output should look something like the following:

                              * About to connect() to localhost port 8080 (#0)\n*   Trying 127.0.0.1... connected\n* Connected to localhost (127.0.0.1) port 8080 (#0)\n* Server auth using Basic with user 'admin'\n> GET /geoserver/wfs?request=getcapabilities HTTP/1.1\n> Authorization: Basic YWRtaW46Z2Vvc2VydmVy\n> User-Agent: curl/7.19.7 (universal-apple-darwin10.0) libcurl/7.19.7 OpenSSL/0.9.8r zlib/1.2.3\n> Host: localhost:8080\n> Accept: */*\n> \n< HTTP/1.1 401 Full authentication is required to access this resource\n< Set-Cookie: JSESSIONID=1dn2bi8qqu5qc;Path=/geoserver\n< WWW-Authenticate: Digest realm=\"GeoServer Realm\", qop=\"auth\", nonce=\"MTMzMzQzMDkxMTU3MjphZGIwMWE4MTc1NmRiMzI3YmFiODhmY2NmZGQ2MzEwZg==\"\n< Content-Type: text/html; charset=iso-8859-1\n< Content-Length: 1491\n< Server: Jetty(6.1.8)\n< \n<html>\n<head>\n<meta http-equiv=\"Content-Type\" content=\"text/html; charset=ISO-8859-1\"/>\n<title>Error 401 Full authentication is required to access this resource</title>\n</head>\n...\n
                            2. Execute the same command but specify the --digest option to tell curl to use digest authentication rather than basic authentication:

                              curl --digest -v -u admin:geoserver -G \"http://localhost:8080/geoserver/wfs?request=getcapabilities\"\n

                              The result should be a successful authentication and contain the normal WFS capabilities response.

                            "},{"location":"security/tutorials/httpheaderproxy/","title":"Configuring HTTP Header Proxy Authentication","text":""},{"location":"security/tutorials/httpheaderproxy/#introduction","title":"Introduction","text":"

                            Proxy authentication is used in multi-tier system. The user/principal authenticates at the proxy and the proxy provides the authentication information to other services.

                            This tutorial shows how to configure GeoServer to accept authentication information passed by HTTP header attribute(s). In this scenario GeoServer will do no actual authentication itself.

                            "},{"location":"security/tutorials/httpheaderproxy/#prerequisites","title":"Prerequisites","text":"

                            This tutorial uses the curl utility to issue HTTP request that test authentication. Install curl before proceeding.

                            Note

                            Any utility that supports setting HTTP header attributes can be used in place of curl.

                            "},{"location":"security/tutorials/httpheaderproxy/#configure-the-http-header-filter","title":"Configure the HTTP header filter","text":"
                            1. Start GeoServer and login to the web admin interface as the admin user.

                            2. Click the Authentication link located under the Security section of the navigation sidebar.

                            3. Scroll down to the Authentication Filters panel and click the Add new link.

                            4. Click the HTTP Header link.

                            5. Fill in the fields of the settings form as follows:

                              • Set Name to \"proxy\"
                              • Set Request header attribute to to \"sdf09rt2s\"
                              • Set Role source to \"User group service\"
                              • Set the name of the user group service to \"default\"

                            Additional information about role services is here Role source and role calculation

                            ::: warning ::: title Warning :::

                            The tutorial uses the obscure \"sdf09rt2s\" name for the header attribute. Why not use \"user\" or \"username\" ?. In a proxy scenario a relationship of trust is needed between the proxy and GeoServer. An attacker could easily send an HTTP request with an HTTP header attribute \"user\" and value \"admin\" and operate as an administrator.

                            One possibility is to configure the network infrastructure preventing such requests from all IP addresses except the IP of the proxy.

                            This tutorial uses a obscure header attribute name which should be a shared secret between the proxy and GeoServer. Additionally, the use of SSL is recommended, otherwise the shared secret is transported in plain text. :::

                            1. Save.

                            2. Back on the authentication page scroll down to the Filter Chains panel.

                            3. Select \"Default\" from the Request type drop down.

                            4. Unselect the basic filter and select the proxy filter. Position the the proxy filter before the anonymous filter.

                            5. Save.

                            "},{"location":"security/tutorials/httpheaderproxy/#secure-ogc-service-requests","title":"Secure OGC service requests","text":"

                            In order to test the authentication settings configured in the previous section a service or resource must be first secured. The Default filter chain is the chain applied to all OGC service requests so a service security rule must be configured.

                            1. From the GeoServer home page and click the Services link located under the Security section of the navigation sidebar.

                            2. On the Service security page click the Add new rule link and add a catch all rule that secures all OGC service requests requiring the ADMIN role.

                            3. Save.

                            "},{"location":"security/tutorials/httpheaderproxy/#test-a-proxy-login","title":"Test a proxy login","text":"
                            1. Execute the following curl command:

                              curl -v  -G \"http://localhost:8080/geoserver/wfs?request=getcapabilities\"\n

                              The result should be a 403 response signaling that access is denied. The output should look something like the following:

                              * About to connect() to localhost port 8080 (#0)\n*   Trying ::1... connected\n> GET /geoserver/wfs?request=getcapabilities HTTP/1.1\n> User-Agent: curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n> Host: localhost:8080\n> Accept: */*\n> \n< HTTP/1.1 403 Access Denied\n< Content-Type: text/html; charset=iso-8859-1\n< Content-Length: 1407\n< Server: Jetty(6.1.8)\n< \n<html>\n<head>\n<meta http-equiv=\"Content-Type\" content=\"text/html; charset=ISO-8859-1\"/>\n<title>Error 403 Access Denied</title>\n</head>\n    ...\n
                            2. Execute the same command but specify the --header option.:

                              curl -v --header \"sdf09rt2s: admin\" -G \"http://localhost:8080/geoserver/wfs?request=getcapabilities\"\n

                              The result should be a successful authentication and contain the normal WFS capabilities response.

                            "},{"location":"security/tutorials/j2ee/","title":"Configuring J2EE Authentication","text":"

                            Servlet containers such as Tomcat and Jetty offer their own options for authentication. Often it is desirable for an application such as GeoServer to use that existing authentication mechanisms rather than require its own authentication configuration.

                            J2EE authentication allows GeoServer to delegate to the servlet container for authentication. This tutorial walks through the process of setting up J2EE authentication.

                            "},{"location":"security/tutorials/j2ee/#prerequisites","title":"Prerequisites","text":"

                            This tutorial requires a servlet container capable of doing its own authentication. This tutorial uses Tomcat.

                            Deploy GeoServer in tomcat before proceeding.

                            "},{"location":"security/tutorials/j2ee/#configure-the-j2ee-authentication-filter","title":"Configure the J2EE authentication filter","text":"

                            In order to delegate to the container for authentication a filter must first be configured to recognize the container authentication.

                            1. Login to the GeoServer web admin interface as the admin user.

                            2. Click the Authentication link located under the Security section of the navigation sidebar.

                            3. Scroll down to the Authentication Filter panel and click the Add new link.

                            4. Create a new filter named \"j2ee\" and fill out the settings form as follows:

                              • Set the Role service to \"default\"

                            5. Save

                            6. Back on the authentication page scroll down to the Filter Chains panel.

                            7. Select \"Web UI\" from the Request type drop down.

                            8. Select the j2ee filter and position it after the anonymous filter.

                            9. Save.

                            "},{"location":"security/tutorials/j2ee/#configure-the-role-service","title":"Configure the role service","text":"

                            Since it is not possible to ask a J2EE container for the roles of a principal it is necessary to have all J2EE roles enlisted in a role service. The only J2EE API GeoServer can use is:

                            class: javax.servlet.http.HttpServletRequest\nmethod: boolean isUserInRole(String role)\n

                            The idea is to query all roles from the role service and test each role with the \"isUserInRole\" method.

                            This tutorial assumes a user named \"admin\" with password \"password\" and a J2EE role named \"tomcat\".

                            1. Click the Users, Groups, and Roles link located under the Security section of the navigation sidebar.

                            2. Click on default to work with the role service named \"default\".

                            3. Click on the Roles tab.

                            4. Click on the Add new role link.

                              • Set the Name to \"tomcat\"

                            5. Save

                            "},{"location":"security/tutorials/j2ee/#configure-tomcat-for-authentication","title":"Configure Tomcat for authentication","text":"

                            By default Tomcat does not require authentication for web applications. In this section Tomcat will be configured to secure GeoServer requiring a basic authentication login.

                            1. Shut down Tomcat.

                            2. Edit the conf/tomcat-users.xml under the Tomcat root directory and add a user named \"admin\":

                              <user username=\"admin\" password=\"password\" roles=\"tomcat\"/>\n
                            3. Edit the GeoServer web.xml file located at webapps/geoserver/WEB-INF/web.xml under the Tomcat root directory and add the following at the end of the file directly before the closing </web-app> element:

                              <security-constraint>\n  <web-resource-collection>\n    <url-pattern>/*</url-pattern>\n     <http-method>GET</http-method>\n     <http-method>POST</http-method>\n  </web-resource-collection>\n  <auth-constraint>\n    <role-name>tomcat</role-name>\n  </auth-constraint>\n</security-constraint>\n\n<login-config>\n  <auth-method>BASIC</auth-method>\n</login-config>\n
                            4. Save web.xml and restart Tomcat.

                            Note

                            It is necessary to add all the role names specified in the web.xml to the configured role service. This is duplicate work but there is currently no other solution.

                            "},{"location":"security/tutorials/j2ee/#test-j2ee-login","title":"Test J2EE login","text":"
                            1. Navigate to the GeoServer web admin interface. The result should be a prompt to authenticate.
                            "},{"location":"security/tutorials/j2ee/#enter-in-the-username-admin-and-password-password","title":". Enter in the username \"admin\" and password \"password\"","text":"

                            The result should be the admin user logged into the GeoServer web admin.

                            "},{"location":"security/tutorials/ldap/","title":"Authentication with LDAP","text":"

                            This tutorial introduces GeoServer LDAP support and walks through the process of setting up authentication against an LDAP server. It is recommended that the LDAP authentication section be read before proceeding.

                            "},{"location":"security/tutorials/ldap/#ldap-server-setup","title":"LDAP server setup","text":"

                            A mock LDAP server will be used for this tutorial. Download and run the acme-ldap jar:

                            java -jar acme-ldap.jar\n

                            The output of which should look like the following:

                            Directory contents:\n  ou=people,dc=acme,dc=org\n    uid=bob,ou=people,dc=acme,dc=org\n    uid=alice,ou=people,dc=acme,dc=org\n    uid=bill,ou=people,dc=acme,dc=org\n  ou=groups,dc=acme,dc=org\n  cn=users,ou=groups,dc=acme,dc=org\n    member: uid=bob,ou=people,dc=acme,dc=org\n    member: uid=alice,ou=people,dc=acme,dc=org\n  cn=admins,ou=groups,dc=acme,dc=org\n    member: uid=bill,ou=people,dc=acme,dc=org\n\n  Server running on port 10389\n

                            The following diagram illustrates the hierarchy of the LDAP datatabse:

                            The LDAP tree consists of:

                            • The root domain component, dc=acme,dc=org
                            • Two organizational units (groups) named user and admin
                            • Two users named bob and alice who are members of the user group
                            • One user named bill who is a member of the admin group
                            "},{"location":"security/tutorials/ldap/#configure-the-ldap-authentication-provider","title":"Configure the LDAP authentication provider","text":"
                            1. Start GeoServer and login to the web admin interface as the admin user.

                            2. Click the Authentication link located under the Security section of the navigation sidebar.

                            3. Scroll down to the Authentication Providers panel and click the Add new link.

                            4. Click the LDAP link.

                            5. Fill in the fields of the settings form as follows:

                              • Set Name to \"acme-ldap\"
                              • Set Server URL to \"\"
                              • Set User lookup pattern to \"uid={0},ou=people\"
                              • Test the LDAP connection by entering the username \"bob\" and password \"secret\" in the connection test form located on the right and click the Test Connection button.

                                A successful connection should be reported at the top of the page.

                              • Save.

                              • Back on the authentication page scroll down to the Provider Chain panel and move the acme-ldap provider from Available to Selected.

                              • Save.

                              • "},{"location":"security/tutorials/ldap/#test-a-ldap-login","title":"Test a LDAP login","text":"
                                1. Navigate to the GeoServer home page and log out of the admin account.
                                "},{"location":"security/tutorials/ldap/#login-as-the-user-bob-with-the-password-secret","title":". Login as the user \"bob\" with the password \"secret\".","text":"

                                Logging in as bob doesn't yield any administrative functionality because the bobaccount has not been mapped to the administrator role. In the next section GeoServer will be configured to map groups from the LDAP database to roles.

                                "},{"location":"security/tutorials/ldap/#map-ldap-groups-to-geoserver-roles","title":"Map LDAP groups to GeoServer roles","text":"

                                When using LDAP for authentication GeoServer maps LDAP groups to GeoServer roles by prefixing the group name with ROLE_ and converting the result to uppercase. For example bob and alice are members of the user group so after authentication they would be assigned a role named ROLE_USER. Similarly bill is a member of the admin group so he would be assigned a role named ROLE_ADMIN.

                                1. Log out of the web admin and log back in as the admin user.

                                2. Navigate to the Authentication page.

                                3. Scroll to the Authentication Providers panel and click the acme-ldap link.

                                4. On the settings page fill in the following form fields:

                                  • Set Group search base to \"ou=groups\"
                                  • Set Group search filter to \"member={0}\"

                                  The first field specifies the node of the LDAP directory tree at which groups are located. In this case the organizational unit named groups. The second field specifies the LDAP query filter to use in order to locate those groups that a specific user is a member of. The {0} is a placeholder which is replaced with the uid of the user.

                                  • Set Group to use as ADMIN to \"ADMIN\"
                                  • Set Group to use as GROUP_ADMIN to \"ADMIN\"

                                  If you want support for hierarchical LDAP groups:

                                  • Check Enable Hierarchical groups search box.
                                  • Set Max depth for hierarchical groups search to 10 (-1 for infinite depth, or the depth number you want to support).
                                  • Set Nested group search filter to \"member={0}\"

                                  These settings let users in the LDAP admin group to be recognized as GeoServer administrators.

                                5. Save.

                                At this point the LDAP provider will populate an authenticated user with roles based on the groups the user is a member of.

                                At this point members of the admin LDAP group should be given full administrative privileges once authenticated. Log out of the admin account and log in as \"bill\" with the password \"hello\". Once logged in full administrative functionality should be available.

                                "},{"location":"security/tutorials/ldap/#configure-the-ldap-role-service","title":"Configure the LDAP role service","text":"

                                An additional step permits to configure a role service to get GeoServer roles from the LDAP repository and allow access rights to be assigned to those roles.

                                1. Click the Users,Group,Roles link located under the Security section of the navigation sidebar.

                                2. Click the Add new link under the Role Services section.

                                3. Click the LDAP option under the New Role Service section.

                                4. Enter ldaprs in the Name text field.

                                5. Enter ldap://localhost:10389/dc=acme,dc=org in the Server URL text field.

                                6. Enter ou=groups in the Group search base text field.

                                7. Enter member=uid={0},ou=people,dc=acme,dc=org in the Group user membership search filter text field.

                                8. Enter cn=* in the All groups search filter text field.

                                Then we need to a choose a user to authenticate on the server (many LDAP server don't allow anonymous data lookup).

                                1. Check the Authenticate to extract roles checkbox.
                                2. Enter uid=bill,ou=people,dc=acme,dc=org in the Username text field.
                                3. Enter hello in the Password text field.

                                If we want Hierarchical groups working we need:

                                1. Check the Enable Hierarchical groups search checkbox.
                                2. Enter 10 in the Max depth for hierarchical groups search text field.
                                3. Enter member={1} in the Nested group search filter text field.
                                4. Save.
                                5. Click the ldaprs role service item under the Role Services section.
                                6. Select ROLE_ADMIN from the Administrator role combo-box.
                                7. Select ROLE_ADMIN from the Group administrator role combo-box.
                                8. Save again.

                                You should now be able to see and assign the new ROLE_ADMIN and ROLE_USER roles wherever an Available Roles list is shown (for example in the Data and Services rules sections.

                                "},{"location":"security/usergrouprole/","title":"Role system","text":"

                                Security in GeoServer is based on a role-based system, with roles created to serve particular functions. Examples of roles sporting a particular function are those accessing the Web Feature Service (WFS), administering the Web administration interface, and reading a specific layer. Roles are assigned to users and groups of users, and determine what actions those users or groups are permitted to do. A user is authorized through Authentication.

                                • Users and Groups
                                • User/group services
                                • Roles
                                • Role services
                                • Role source and role calculation
                                • Interaction between user/group and role services
                                "},{"location":"security/usergrouprole/interaction/","title":"Interaction between user/group and role services","text":"

                                The following section describes the interaction between the User/group services and the Role services.

                                "},{"location":"security/usergrouprole/interaction/#calculating-the-roles-of-a-user","title":"Calculating the roles of a user","text":"

                                The diagram below illustrates how a user/group service and a role service interact to calculate user roles.

                                User/group and role service interacting for role calculation

                                On fetching an enabled user from a user/group service, the roles(s) assigned to that user must be identified. The identification procedure is:

                                1. Fetch all enabled groups for the user. If a group is disabled, it is discarded.
                                2. Fetch all roles associated with the user and add the roles to the result set.
                                3. For each enabled group the user is a member of, fetch all roles associated with the group and add the roles to the result set.
                                4. For each role in the result set, fetch all ancestor roles and add those roles to the result set.
                                5. Personalize each role in the result set as required.
                                6. If the result set contains the local admin role, add the role ROLE_ADMINISTRATOR.
                                7. If the result set contains the local group admin role, add the role ROLE_GROUP_ADMIN.

                                Note

                                Role personalization looks for role parameters (key/value pairs) for each role and checks if the user properties (key/value pairs) contain an identical key. If any matches are found, the value of the role parameter is replaced by the value of the user property.

                                "},{"location":"security/usergrouprole/interaction/#authentication-of-user-credentials","title":"Authentication of user credentials","text":"

                                A user/group service is primarily used during authentication. An authentication provider in the Authentication chain may use a user/group service to authenticate user credentials.

                                Using a a user/group service for authentication

                                "},{"location":"security/usergrouprole/interaction/#geoserver-defaults","title":"GeoServer defaults","text":"

                                The following diagram illustrates the default user/group service, role service, and authentication provider in GeoServer:

                                Default GeoServer security configuration

                                Two authentication providers are configured---the Root provider and the Username/password provider. The Root provider authenticates for the GeoServer Root account and does not use a user/group service. The Username/password provider is the default provider and relays username and password credentials to a user/group service.

                                A single user/group service, which persist the user database as XML, is present. The database contains a single user named admin and no groups. Similarly, the role service persists the role database as XML. By default, this contains a single role named ADMIN, which is associated with the admin user. The ADMIN role is mapped to the ROLE_ADMINISTRATOR role and as a result, the admin user is associated with system administrator role during role calculation.

                                "},{"location":"security/usergrouprole/roles/","title":"Roles","text":"

                                GeoServer roles are keys associated with performing certain tasks or accessing particular resources. Roles are assigned to users and groups, authorizing them to perform the actions associated with the role. A GeoServer role includes the following:

                                • Role name
                                • Parent role
                                • Set of key/value pairs

                                GeoServer roles support inheritance---a child role inherits all the access granted to the parent role. For example, suppose you have one role named ROLE_SECRET and another role, ROLE_VERY_SECRET, that extends ROLE_SECRET. ROLE_VERY_SECRET can access everything ROLE_SECRET can access, but not vice versa.

                                Key/value pairs are implementation-specific and may be configured by the role service the user or group belongs to. For example, a role service that assigns roles based on employee organization may wish to associate additional information with the role such as Department Name.

                                GeoServer has a number of system roles, the names of which are reserved. Adding a new GeoServer role with reserved name is not permitted.

                                • ROLE_ADMINISTRATOR---Provides access to all operations and resources
                                • ROLE_GROUP_ADMIN---Special role for administrating user groups
                                • ROLE_AUTHENTICATED---Assigned to every user authenticating successfully
                                • ROLE_ANONYMOUS---Assigned if anonymous authentication is enabled and user does not log on
                                "},{"location":"security/usergrouprole/roleservices/","title":"Role services","text":"

                                A role service provides the following information for roles:

                                • List of roles
                                • Calculation of role assignments for a given user
                                • Mapping of a role to the system role ROLE_ADMINISTRATOR
                                • Mapping of a role to the system role ROLE_GROUP_ADMIN

                                When a user/group service loads information about a user or a group, it delegates to the role service to determine which roles should be assigned to the user or group. Unlike User/group services, only one role service is active at any given time. The default role service is set on the Settings page.

                                By default, GeoServer supports two types of role services:

                                • XML---(Default) role service persisted as XML
                                • JDBC---Role service persisted in a database via JDBC
                                "},{"location":"security/usergrouprole/roleservices/#security_rolesystem_mapping","title":"Mapping roles to system roles","text":"

                                To assign the system role ROLE_ADMINISTRATOR to a user or to a group, a new role with a different name must be created and mapped to the ROLE_ADMINISTRATOR role. The same holds true for the system role ROLE_GROUP_ADMIN. The mapping is stored in the service's config.xml file.

                                <roleService>\n  <id>471ed59f:13915c479bc:-7ffc</id>\n  <name>default</name>\n  <className>org.geoserver.security.xml.XMLRoleService</className>\n  <fileName>roles.xml</fileName>\n  <checkInterval>10000</checkInterval>\n  <validating>true</validating>\n  <adminRoleName>ADMIN</adminRoleName>\n  <groupAdminRoleName>GROUP_ADMIN</groupAdminRoleName>\n</roleService>\n

                                In this example, a user or a group assigned to the role ADMIN is also assigned to the system role ROLE_ADMINISTRATOR. The same holds true for GROUP_ADMIN and ROLE_GROUP_ADMIN.

                                "},{"location":"security/usergrouprole/roleservices/#security_rolesystem_rolexml","title":"XML role service","text":"

                                The XML role service persists the role database in an XML file. This is the default role service for GeoServer. This service represents the user database as XML, and corresponds to this XML schema.

                                Note

                                The XML role file, roles.xml, is located in the GeoServer data directory, security/role/<name>/roles.xml, where <name> is the name of the role service.

                                The service is configured to map the local role ADMIN to the system role ROLE_ADMINISTRATOR. Additionally, GROUP_ADMIN is mapped to ROLE_GROUP_ADMIN. The mapping is stored the config.xml file of each role service.

                                The following provides an illustration of the roles.xml that ships with the default GeoServer configuration:

                                <roleRegistry version=\"1.0\" xmlns=\"http://www.geoserver.org/security/roles\">\n  <roleList>\n    <role id=\"ADMIN\"/>\n    <role id=\"GROUP_ADMIN\"/>\n  </roleList>\n  <userList>\n    <userRoles username=\"admin\">\n      <roleRef roleID=\"ADMIN\"/>\n    </userRoles>\n  </userList>\n  <groupList/>\n</roleRegistry>\n

                                This configuration contains two roles named ADMIN and GROUP_ADMIN. The role ADMIN is assigned to the admin user. Since the ADMIN role is mapped to the system role ROLE_ADMINISTRATOR, the role calculation assigns both roles to the admin user.

                                For further information, please refer to configuring a role service in the Web administration interface.

                                "},{"location":"security/usergrouprole/roleservices/#security_rolesystem_rolej2ee","title":"J2EE role service","text":"

                                The J2EE role service parses roles from the WEB-INF/web.xml file. As a consequence, this service is a read only role service. Roles are extracted from the following XML elements:

                                "},{"location":"security/usergrouprole/roleservices/#security-role","title":"<security-role>","text":"
                                <security-role>\n   <role-name>role1</role-name>\n</security-role>\n<security-role>\n   <role-name>role2</role-name>\n</security-role>  \n<security-role>\n   <role-name>employee</role-name>\n</security-role>\n

                                Roles retrieved:

                                • role1
                                • role2
                                • employee
                                "},{"location":"security/usergrouprole/roleservices/#security-constraint","title":"<security-constraint>","text":"
                                <security-constraint>\n   <web-resource-collection>\n       <web-resource-name>Protected Area</web-resource-name>\n       <url-pattern>/jsp/security/protected/*</url-pattern>\n       <http-method>PUT</http-method>\n       <http-method>DELETE</http-method>\n       <http-method>GET</http-method>\n       <http-method>POST</http-method>\n   </web-resource-collection>\n   <auth-constraint>\n       <role-name>role1</role-name>\n       <role-name>employee</role-name>\n   </auth-constraint>\n</security-constraint>\n

                                Roles retrieved:

                                • role1
                                • employee
                                "},{"location":"security/usergrouprole/roleservices/#security-role-ref","title":"<security-role-ref>","text":"
                                <security-role-ref>\n    <role-name>MGR</role-name>\n    <!-- role name used in code -->\n    <role-link>employee</role-link>\n  </security-role-ref>      \n

                                Roles retrieved:

                                • MGR
                                "},{"location":"security/usergrouprole/roleservices/#security_rolesystem_rolejdbc","title":"JDBC role service","text":"

                                The JDBC role service persists the role database via JDBC, managing the role information in multiple tables. The role database schema is as follows:

                                Field Type Null Key

                                name varchar(64) NO PRI

                                parent varchar(64) YES

                                Table: roles

                                Field Type Null Key

                                rolename varchar(64) NO PRI

                                propname varchar(64) NO PRI

                                propvalue varchar(2048) YES

                                Table: role_props

                                Field Type Null Key

                                username varchar(128) NO PRI

                                rolename varchar(64) NO PRI

                                Table: user_roles

                                Field Type Null Key

                                groupname varchar(128) NO PRI

                                rolename varchar(64) NO PRI

                                Table: group_roles

                                The roles table is the primary table and contains the list of roles. Roles in GeoServer support inheritance, so a role may optionally have a link to a parent role. The role_props table maps additional properties to a role. (See the section on Roles for more details.) The user_roles table maps users to the roles they are assigned. Similarly, the group_roles table maps which groups have been assigned to which roles.

                                The default GeoServer security configuration is:

                                name parent

                                Empty Empty

                                Table: roles

                                rolename propname propvalue

                                Empty Empty Empty

                                Table: role_props

                                username rolename

                                Empty Empty

                                Table: user_roles

                                groupname rolename

                                Empty Empty

                                Table: group_roles

                                For further information, please refer to configuring a role service in the Web administration interface.

                                "},{"location":"security/usergrouprole/roleservices/#ldap-role-service","title":"LDAP role service","text":"

                                The LDAP role service is a read only role service that maps groups from an LDAP repository to GeoServer roles.

                                Groups are extracted from a specific LDAP node, configured as the Groups search base. A role is mapped for every matching group. The role will have a name that is built taking the Group common name (cn attribute), transformed to upper case and with a ROLE_ prefix applied.

                                It is possible to filter extracted groups using an All groups filter (defaults to cn=* that basically extracts all nodes from the configured base). It is also possible to configure the filter for users to roles membership (defaults to member={0}).

                                A specific group can be assigned to the ROLE_ADMINISTRATOR and/or the ROLE_GROUP_ADMIN administrative roles.

                                Groups extraction can be done anonymously or using a given username/password if the LDAP repository requires it.

                                An example of configuration file (config.xml) for this type of role service is the following:

                                <org.geoserver.security.ldap.LDAPRoleServiceConfig>\n  <id>-36dfbd50:1424687f3e0:-8000</id>\n  <name>ldapacme</name>\n  <className>org.geoserver.security.ldap.LDAPRoleService</className>\n  <serverURL>ldap://127.0.0.1:10389/dc=acme,dc=org</serverURL>\n  <groupSearchBase>ou=groups</groupSearchBase>\n  <groupSearchFilter>member=uid={0},ou=people,dc=acme,dc=org</groupSearchFilter>\n  <useTLS>false</useTLS>\n  <bindBeforeGroupSearch>true</bindBeforeGroupSearch>\n  <adminGroup>ROLE_ADMIN</adminGroup>\n  <groupAdminGroup>ROLE_ADMIN</groupAdminGroup>\n  <user>uid=bill,ou=people,dc=acme,dc=org</user>\n  <password>hello</password>\n  <allGroupsSearchFilter>cn=*</allGroupsSearchFilter>\n</org.geoserver.security.ldap.LDAPRoleServiceConfig>\n

                                For further information, please refer to configuring a role service in the Web administration interface.

                                "},{"location":"security/usergrouprole/roleservices/#rest-role-service","title":"REST role service","text":"

                                The REST role service is a read only role service that maps groups and associated users to roles from a remote REST web service.

                                The REST service must support JSON encoding.

                                Here is a listing of significant methods provided by the REST Role Service (based on the LDAP role service, which similarly has to make network calls to work):

                                Method Mandatory

                                getUserNamesForRole(roleName) N (implemented in LDAP, but I don't see actual users of this method besides a utility method that nobody uses)

                                getRolesForUser(user) Y

                                getRolesForGroup(group) N

                                getRoles() Y (used by the UI)

                                getParentRole(role) N

                                getAdminRole() Y

                                getGroupAdminRole() Y

                                getRoleCount() Y (does not seem to be used much, we can trivially implement it from getRoles()

                                Table: roles"},{"location":"security/usergrouprole/roleservices/#rest-apis","title":"REST APIs","text":"

                                The following is an example of the REST API the role service may handle. The JSON and remote endpoints may differ; this is configurable via UI, allowing the REST role service to connect to a generic REST Service

                                From the above we could have the following REST API to talk to

                                ../api/roles

                                Returns the full list of roles (no paging required, we assume it's small). Example response:

                                {\"groups\":[\"r1\",\"r2\",\"r3\"]}\n

                                ../api/adminrole

                                Returns the role of the administrator (yes, just one, it's strange...):

                                {\"adminRole\":[\"root\"]}\n

                                ../api/users/<user>

                                Returns the list of roles for a particular user. Example response:

                                {\"users\": [{\"user\":\"u1\", \"groups\":[\"r1\",\"r2\"]}]}\n
                                "},{"location":"security/usergrouprole/roleservices/#configurable-api","title":"Configurable API","text":"

                                The GeoServerRoleService talking to a remote service provides the following config parameters:

                                • Base URL for the remote service
                                • Configurable URLs for the various calls
                                • JSON paths to the properties that contain the list of roles, and the one admin role

                                The above can be configured via the Web administration interface. The figure below shows the REST role service options configured to be compatible with the sample APIs above:

                                REST based role service configuration panel

                                "},{"location":"security/usergrouprole/rolesource/","title":"Role source and role calculation","text":"

                                Different authentication mechanisms provide different possibilities where to look for the roles of a principal/user. The role source is the base for the calculation of the roles assigned to the authenticated principal.

                                "},{"location":"security/usergrouprole/rolesource/#using-a-usergroup-service","title":"Using a user/group Service","text":"

                                During configuration of an authentication mechanism, the name of a user group service has to be specified. The used role service is always the role service configured as active role service. The role calculation itself is described here Interaction between user/group and role services

                                "},{"location":"security/usergrouprole/rolesource/#using-a-role-service-directly","title":"Using a role service directly","text":"

                                During configuration of an authentication mechanism, the name of a role service has to be specified. The calculation of the roles works as follows:

                                1. Fetch all roles for the user.
                                2. For each role in the result set, fetch all ancestor roles and add those roles to the result set.
                                3. If the result set contains the local admin role, add the role ROLE_ADMINISTRATOR.
                                4. If the result set contains the local group admin role, add the role ROLE_GROUP_ADMIN.

                                This algorithm does not offer the possibility to have personalized roles and it does not consider group memberships.

                                "},{"location":"security/usergrouprole/rolesource/#using-an-http-header-attribute","title":"Using an HTTP header attribute","text":"

                                The roles for a principal are sent by the client in an HTTP header attribute (Proxy authentication). GeoServer itself does no role calculation and extracts the roles from the header attribute. During configuration, the name of the header attribute must be specified. An example with a header attribute named \"roles\":

                                roles: role_a;role_b;role_c\n

                                An example for roles with role parameters:

                                roles: role_a;role_b(pnr=123,nick=max);role_c\n

                                The default syntax is

                                • roles are delimited by ;
                                • a role parameter list starts with ( and ends with )
                                • a role parameter is a key value pair delimited by =
                                • role parameters are delimited by ,
                                "},{"location":"security/usergrouprole/usergroups/","title":"Users and Groups","text":"

                                The definition of a GeoServer user is similar to most security systems. Although the correct Java term is principal---a principal being a human being, computer, software system, and so on---the term user is adopted throughout the GeoServer documentation. For each user the following information is maintained:

                                • User name
                                • Password (optionally stored encrypted)
                                • A flag indicating if the user is enabled (this is the default). A disabled user is prevented from logging on. Existing user sessions are not affected.
                                • Set of key/value pairs

                                Key/value pairs are implementation-specific and may be configured by the user/group service the user or group belongs to. For example, a user/group service that maintains information about a user such as Name, Email address, and so on, may wish to associate those attributes with the user object.

                                A GeoServer group is simply a set of users. For each group the following information is maintained:

                                • Group name
                                • A flag indicating if the group is enabled (this is the default). A disabled group does not contribute to the role calculation for all users contained in this group.
                                • List of users who belong to the group
                                "},{"location":"security/usergrouprole/usergroupservices/","title":"User/group services","text":"

                                A user/group service provides the following information for users and groups:

                                • Listing of users
                                • Listing of groups, including users affiliated with each group
                                • User passwords

                                Many authentication providers will make use of a user/group service to perform authentication. In this case, the user/group service would be the database against which users and passwords are authenticated. Depending on how the Authentication chain is configured, there may be zero, one, or multiple user/group services active at any given time.

                                A user/group service may be read-only, providing access to user information but not allowing new users and groups to be added or altered. This may occur if a user/group service was configured to delegate to an external service for the users and groups database. An example of this would be an external LDAP server.

                                By default, GeoServer support three types of user/group services:

                                • XML<security_rolesystem_usergroupxml>---(Default) User/group service persisted as XML
                                • JDBC<security_rolesystem_usergroupjdbc>---User/group service persisted in database via JDBC
                                • LDAP<security_rolesystem_usergroupldap>---User/group service obtained from an LDAP repository

                                Other services can be added to GeoServer, such as that provided by the AuthKey<authkey> extension.

                                "},{"location":"security/usergrouprole/usergroupservices/#security_rolesystem_usergroupxml","title":"XML user/group service","text":"

                                The XML user/group service persists the user/group database in an XML file. This is the default behavior in GeoServer. This service represents the user database as XML, and corresponds to this XML schema.

                                Note

                                The XML user/group file, users.xml, is located in the GeoServer data directory, security/usergroup/<name>/users.xml, where <name> is the name of the user/group service.

                                The following is the contents of users.xml that ships with the default GeoServer configuration:

                                <userRegistry version=\"1.0\" xmlns=\"http://www.geoserver.org/security/users\">\n  <users>\n    <user enabled=\"true\" name=\"admin\" password=\"crypt1:5WK8hBrtrte9wtImg5i5fjnd8VeqCjDB\"/>\n  </users>\n  <groups/>\n</userRegistry>\n

                                This particular configuration defines a single user, admin, and no groups. By default, stored user passwords are encrypted using the weak PBE method.

                                For further information, please refer to configuring a user/group service in the Web administration interface.

                                "},{"location":"security/usergrouprole/usergroupservices/#security_rolesystem_usergroupjdbc","title":"JDBC user/group service","text":"

                                The JDBC user/group service persists the user/group database via JDBC, managing the user information in multiple tables. The user/group database schema is as follows:

                                Field Type Null Key

                                name varchar(128) NO PRI

                                password varchar(254) YES

                                enabled char(1) NO

                                Table: users

                                Field Type Null Key

                                username varchar(128) NO PRI

                                propname varchar(64) NO PRI

                                propvalue varchar(2048) YES

                                Table: user_props

                                Field Type Null Key

                                name varchar(128) NO PRI

                                enabled char(1) NO

                                Table: groups

                                Field Type Null Key

                                groupname varchar(128) NO PRI

                                username varchar(128) NO PRI

                                Table: group_members

                                The users table is the primary table and contains the list of users with associated passwords. The user_props table maps additional properties to a user. (See Users and Groups for more details.) The groups table lists all available groups, and the group_members table maps which users belong to which groups.

                                The default GeoServer security configuration is:

                                name password enabled

                                Empty Empty Empty

                                Table: users

                                username propname propvalue

                                Empty Empty Empty

                                Table: user_props

                                name enabled

                                Empty Empty

                                Table: groups

                                groupname username

                                Empty Empty

                                Table: group_members

                                For further information, please refer to configuring a user/group service in the Web administration interface.

                                "},{"location":"security/usergrouprole/usergroupservices/#security_rolesystem_usergroupldap","title":"LDAP user/group service","text":"

                                The LDAP user/group service is a read only user/group service that maps users and groups from an LDAP repository to GeoServer users and groups.

                                Users are extracted from a specific LDAP node, configured as the Users search base. Groups are extracted from a specific LDAP node, configured as the Groups search base. A user is mapped for every matching user and a group is mapped for every matching group.

                                It is possible to specify the attributes which contain the name of the group (such as cn), the user (such as uid) as well as the membership relationship between the two (such as member). However, it is also possible to specify specific filters to search for all users/groups (for example cn=*), find a user/group by name (for example cn={0}) and map users to groups (such as member={0}). These filters can also be automatically derived from the attribute names. Alternatively, the attribute names may be left empty if the filters are provided.

                                For users, additional properties (key/value pairs, see Users and Groups) may be populated from the LDAP Server by providing a comma separated list of property names.

                                Retrieving the user/group information can be done anonymously or using a given username/password if the LDAP repository requires it.

                                An example of configuration file (config.xml) for this type of role service is the following:

                                <org.geoserver.security.ldap.LDAPUserGroupServiceConfig>\n  <id>2c3e0e8d:154853796a3:-8000</id>\n  <name>myldapservice</name>\n  <className>org.geoserver.security.ldap.LDAPUserGroupService</className>\n  <serverURL>ldap://127.0.0.1:10389/dc=acme,dc=org</serverURL>\n  <groupSearchBase>ou=groups</groupSearchBase>\n  <groupFilter>cn={0}</groupFilter>\n  <groupNameAttribute>cn</groupNameAttribute>\n  <allGroupsSearchFilter>cn=*</allGroupsSearchFilter>\n  <groupSearchFilter>member={0}</groupSearchFilter>\n  <groupMembershipAttribute>member</groupMembershipAttribute>\n  <userSearchBase>ou=people</userSearchBase>\n  <userFilter>uid</userFilter>\n  <userNameAttribute>uid={0}</userNameAttribute>\n  <allUsersSearchFilter>uid=*</allUsersSearchFilter>\n  <useTLS>false</useTLS>\n  <bindBeforeGroupSearch>true</bindBeforeGroupSearch>\n  <user>admin</user>\n  <password>admin</password>\n  <passwordEncoderName>emptyPasswordEncoder</passwordEncoderName>\n  <passwordPolicyName>default</passwordPolicyName>\n  <populatedAttributes>email, telephone</populatedAttributes>\n</org.geoserver.security.ldap.LDAPUserGroupServiceConfig>\n

                                For further information, please refer to configuring a user/group service in the Web administration interface.

                                "},{"location":"security/webadmin/","title":"Security settings","text":"

                                GeoServer has a robust security subsystem, modeled on Spring Security. Most of the security features are available through the Web administration interface. This section describes how to configure GeoServer security through the web administration interface.

                                • Settings
                                • Authentication
                                • Passwords
                                • Users, Groups, Roles
                                • Data
                                • Services
                                • File Browsing
                                • CSRF Protection
                                "},{"location":"security/webadmin/auth/","title":"Authentication","text":"

                                This page manages the authentication options, including authentication providers and the authentication chain.

                                "},{"location":"security/webadmin/auth/#brute-force-attack-prevention","title":"Brute force attack prevention","text":"

                                GeoServer ships with a delay based brute force attack prevention system.

                                Brute force attack prevention settings

                                Option Description

                                Enabled Whether the brute force attack prevention is enabled. Defaults to true.

                                Minimum delay on failed authentication (seconds) Minimum number of seconds a failed login request will be made to wait before getting a response

                                Maximum delay on failed authentication (seconds) Maximum number of seconds a failed login request will be made to wait before getting a response

                                Excluded network masks Network masks identifying hosts that are excluded from brute force attack prevention. Can be empty, include specific IPs, or a list of network masks. Defaults to 127.0.0.1, the localhost.

                                Maximum number of threads blocked on failed login delay Limits the number of threads that get delayed on failed login, should be set to a value less than the container's available response threads.

                                The mechanism works as follows:

                                • Each failed authentication request is made to wait between min and max seconds before getting an actual response back.
                                • Each attempt to authenticate the same username in parallel fails immediately, regardless of whether the credentials were valid or not, with a message stating concurrent login attempts are not allowed.

                                The first item slows down a single threaded attack to the point of making it ineffective (each failed attempt is logged along with the IP attempting access), the second item breaks multi-threaded attacks ability to scale. Login attempts are slowed down/blocked on all protocols, be either a OGC request, a REST call, or the UI.

                                A user trying to login from the user interface while another request is blocked waiting for the cool-down period to expire will see a message like the following:

                                Error message for parallel user interface login

                                A HTTP request (REST or OGC) will instead get an immediate 401 with a message like:

                                HTTP/1.1 401 User foo, 5896 concurrent login attempt(s) denied during the quiet period

                                A blessed set of IPs that can dodge the mechanism allows legit administrators to take control of the server even during an attack. The system only trusts the actual requestor IP, ignoring \"X-Forwarded-For\" headers, as they can be easily spoofed (this in turn requires the admin to access the system from a local network, without proxies in the middle, for the blessed IP to be recognized).

                                The maximum number of threads blocked configuration allows to setup the system so that an attacker can misuse the system to simply block all service threads, by issuing requests with random usernames (the system cannot determine if a username is valid or not, none of the authentication mechanisms provides this information for security reasons).

                                Considerations on how to setup the system:

                                • A small delay is normally more than enough to stop a brute force attack, resist the temptation of setting high delay values as they might end up blocking too many legitimate accounts and trigger the max blocked threads mechanism.
                                • Ensure that the excluded networks are well protected by other means.
                                • Set the maximum number of blocked threads to a value large allow peak hour legit logins (e.g., early morning when all the users start working) while still leaving room for successful authentication requests.
                                • A clustered/load balanced setup will not share the state of blocked logins, each host tracks its local login failures.
                                "},{"location":"security/webadmin/auth/#authentication-filters","title":"Authentication filters","text":"

                                This section manages the Authentication Filters (adding, removing, and editing). Several authentication filters are configured by default (anonymous, basic, form, rememberme), but others can be added to the list.

                                List of authentication filters

                                "},{"location":"security/webadmin/auth/#anonymous-access","title":"Anonymous access","text":"

                                By default, GeoServer will allow anonymous access to the Web administration interface. Without authentication, users will still be able to view the Layer Preview, capabilities documents, and basic GeoServer details. Anonymous access can by removing the anonymous authentication filter. If removed, anonymous users navigating to the GeoServer page will get an HTTP 401 status code, which typically results in a browser-based request for credentials.

                                "},{"location":"security/webadmin/auth/#credentials-from-headers-filter","title":"Credentials from Headers filter","text":"

                                This filter allows gathering user credentials (username and password) from request headers in a flexible and configurable way.

                                Creating a new authentication filter fetching credentials from request headers

                                Option Description

                                Name Name of the filter

                                Username Header Name of the Request Header containing the username

                                Regular Expression for Username Regular Expression used to extract the username from the related Header. Must define a group that will match the username.

                                Password Header Name of the Request Header containing the password

                                Regular Expression for Password Regular Expression used to extract the password from the related Header. Must define a group that will match the password.

                                Parse Arguments as Uri Components If checked username and password are URI decoded before being used as credentials

                                "},{"location":"security/webadmin/auth/#authentication-providers","title":"Authentication providers","text":"

                                This section manages the security_auth_providers (adding, removing, and editing). The default authentication provider uses basic username/password authentication <../auth/providers.rst#security_auth_provider_userpasswd>_. JDBC and LDAP authentication can also be used.

                                Click Add new to create a new provider. Click an existing provider to edit its parameters.

                                List of authentication providers

                                "},{"location":"security/webadmin/auth/#usernamepassword-provider","title":"Username/password provider","text":"

                                The default new authentication provider uses a user/group service for authentication.

                                Creating a new authentication provider with a username and password

                                Option Description

                                Name Name of the provider

                                User Group Service Name of the user/group service associated with this provider. Can be any one of the active user/group services.

                                "},{"location":"security/webadmin/auth/#jdbc-provider","title":"JDBC provider","text":"

                                The configuration options for the JDBC authentication provider are illustrated below.

                                Configuring the JDBC authentication provider

                                Option Description

                                Name Name of the JDBC connection in GeoServer

                                User Group Service Name of the user/group service to use to load user information after the user is authenticated

                                Driver class name JDBC driver to use for the database connection

                                Connection URL JDBC URL to use when creating the database connection

                                "},{"location":"security/webadmin/auth/#ldap-provider","title":"LDAP provider","text":"

                                The following illustration shows the configuration options for the LDAP authentication provider. The default option is to use LDAP groups for role assignment, but there is also an option to use a user/group service for role assignment. Depending on whether this option is selected, the page itself will have different options.

                                Configuring the LDAP authentication provider using LDAP groups for role assignment

                                Configuring the LDAP authentication provider using user/group service for authentication

                                +------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Option | Description | +==========================================+=============================================================================================================================================================================================================================================================================================================================================================================================================================================================================+ | Name | Name of the LDAP connection in GeoServer | +------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Server URL | URL for the LDAP server connection. It must include the protocol, host, and port, as well as the \"distinguished name\" (DN) for the root of the LDAP tree. | +------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | TLS | Enables a STARTTLS connection. (See the section on Secure LDAP connections.) | +------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | User DN pattern | Search pattern to use to match the DN of the user in the LDAP database. The pattern should contain the placeholder {0} which is injected with the uid of the user. Example: uid={0},ou=people. The root DN specified as port of the Server URL is automatically appended. | +------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | User Filter | LDAP Filter used to extract User data from LDAP database. Used alternatively to User DN pattern and combined with User Format to separate bind and user data extraction handling. Example: (userPrincipalName={0}). Gets user data searching for a single record matching the filter. This may contain two placeholder values: {0}, the full DN of the user, for example uid=bob,ou=people,dc=acme,dc=com {1}, the uid portion of the full DN, for example bob. | +------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | User Format | String formatter used to build username used for binding. Used alternatively to User DN pattern and combined with User Filter to separate bind and user data extraction handling. Example: {0}@domain. Binds user with the username built applying the format. This may contain one placeholder: {0}, the username, for example bob | +------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Use LDAP groups for authorization | Specifies whether to use LDAP groups for role assignment | +------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Bind before group search | Specifies whether to bind to LDAP server with the user credentials before doing group search | +------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Group search base | Relative name of the node in the tree to use as the base for LDAP groups. Example: ou=groups. The root DN specified as port of the Server URL is automatically appended. Only applicable when the Use LDAP groups for authorization( parameter ischecked. | +------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Group search filter | Search pattern for locating the LDAP groups a user belongs to. This may contain two placeholder values: {0}, the full DN of the user, for example uid=bob,ou=people,dc=acme,dc=com {1}, the uid portion of the full DN, for example bob. Only applicable when the Use LDAP groups for authorization( parameter ischecked. | +------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Admin Group | Name of the group to be mapped to Administrator role (defaults to ADMINISTRATOR). Example: ADMIN. Adds the role ROLE_ADMINISTRATOR if the user belongs to a group named ADMIN (case insensitive) | +------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Group Admin Group | Name of the group to be mapped to Group Administrator role (defaults to GROUP_ADMIN). Example: GROUPADMIN. Adds the role ROLE_GROUP_ADMIN if the user belongs to a group named GROUPADMIN (case insensitive) | +------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | User Group Service | The user/group service to use for role assignment. Only applicable when the Use LDAP groups for authorization parameter is cleared. | +------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Enable Hierarchical groups search | Specifies whether to use Hierarchical LDAP groups search for role assignment | +------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Max depth for hierarchical groups search | Specifies the max group search depth level to use with Hierarchical LDAP groups search. Use -1 for no limit. Only applicable when the *Enable Hierarchical groups search( parameter ischecked. | +------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Nested group search filter | Search pattern for locating parent LDAP groups a group belongs to. This may contain two placeholder values: | | | | | | {0}, the full DN of the user, for example cn=it,ou=groups,dc=acme,dc=com | | | | | | {1}, the cn portion of the full DN, for example it. Only applicable when the Enable Hierarchical groups search( parameter ischecked*. | +------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+

                                "},{"location":"security/webadmin/auth/#authentication-chain","title":"Authentication chain","text":"

                                This section selects the authentication chain. Currently, only one default authentication chain is available. For further information about the default chain, please refer to Authentication chain.

                                Selecting the authentication chain

                                "},{"location":"security/webadmin/csrf/","title":"CSRF Protection","text":"

                                The GeoServer web admin employs a CSRF (Cross-Site Request Forgery) protection filter that will block any form submissions that didn't appear to originate from GeoServer. This can sometimes cause problems for certain proxy configurations.

                                Note

                                Symptoms of this problem may include the WPS request builder (and other wicket pages) failing with an HTTP status of 403 and the message \"Origin does not correspond to request\". However, you may need to view the page response in a debugger to see this, to the end user it will appear as if the form section of the page is just missing.

                                To allow-list your proxy with the CSRF filter, you can use the GEOSERVER_CSRF_WHITELIST property. This property is a comma-separated list of domains, of the form <domainname>.<TLD>, and can contain a subdomains. Alternatively, you can disable the CSRF filter by setting the GEOSERVER_CSRF_DISABLED property to true.

                                Each of these properties is set through one of the standard means:

                                • web.xml :

                                  <context-param>\n  <param-name>GEOSERVER_CSRF_WHITELIST</param-name>\n  <param-value>example.org</param-value>\n</context-param>\n
                                • System property :

                                  -DGEOSERVER_CSRF_WHITELIST=example.org\n
                                • Environment variable :

                                  export GEOSERVER_CSRF_WHITELIST=example.org\n
                                "},{"location":"security/webadmin/data/","title":"Data","text":"

                                This section provides access to security settings related to data management and Layer security. Data access is granted to roles, and roles are granted to users and groups.

                                "},{"location":"security/webadmin/data/#rules","title":"Rules","text":"

                                There are two rules available by default, but they don't provide any restrictions on access by default. The first rule *.*.r, applied to all roles, states that any operation in any resource in any workspace can be read. The second rule, *.*.w, also applied to all roles, says the same for write access.

                                Rules for data access

                                Clicking an existing rule will open it for editing, while clicking the Add a new rule link will create a new rule.

                                Creating a new rule

                                Editing a layer group rule

                                Option Description

                                Global layer group rule If checked, switches the editor to create/edit a rule about a global layer group (and will remove the layer configuration as a result)

                                Workspace Sets the allowed workspace for this rule. Options are * (all workspaces), or the name of each workspace.

                                Layer and groups Sets the allowed layer/groups for this rule. Options are * (all layers/groups in the chosen workspace), or the name of each layer in the above workspace. Will be disabled until the workspace is set.

                                Access mode Specifies whether the rule refers to either Read or Write mode

                                Grant access to any role If selected, the rule will apply to all roles, with no need to specify

                                Role list Full list of roles, including a list of roles to which the rule is associated. Association can be toggled here via the arrow buttons. This option is not applied if Grant access to any role is checked.

                                Add a new role Shortcut to adding a new role

                                "},{"location":"security/webadmin/data/#catalog-mode","title":"Catalog Mode","text":"

                                This mode configures how GeoServer will advertise secured layers and behave when a secured layer is accessed without the necessary privileges. There are three options: HIDE, MIXED, and CHALLENGE. For further information on these options, please see the section on Layer security.

                                Catalog mode

                                "},{"location":"security/webadmin/filebrowse/","title":"File Browsing","text":"

                                The GeoServer web admin employs a file browser dialog that will expose locations of the file system other than the GeoServer directory. These locations include the root of the file system and the users home directory. In highly secure and multi-tenant environments disabling this feature may be desired.

                                The property GEOSERVER_FILEBROWSER_HIDEFS can be used to disable this functionality. When set to true only the GeoServer data directory will be exposed through the file browser.

                                The property is set through one of the standard means:

                                • web.xml :

                                  <context-param>\n  <param-name>GEOSERVER_FILEBROWSER_HIDEFS</param-name>\n  <param-value>true</param-value>\n</context-param>\n
                                • System property :

                                  -DGEOSERVER_FILEBROWSER_HIDEFS=true\n
                                • Environment variable :

                                  export GEOSERVER_FILEBROWSER_HIDEFS=true\n
                                "},{"location":"security/webadmin/passwords/","title":"Passwords","text":"

                                This page configures the various options related to Passwords, the Keystore password, and Password policies.

                                Note

                                User passwords may be changed in the Users dialog box accessed from the Users, Groups, Roles page.

                                "},{"location":"security/webadmin/passwords/#security_webadmin_masterpasswordprovider","title":"Active keystore password provider","text":"

                                This option sets the active keystore password provider, via a list of all available keystore password providers.

                                Active keystore password provider

                                To change the keystore password click the Change password link.

                                Changing the keystore password

                                Warning

                                First thing to do as an Administrator of the System, would be to dump the Keystore Password generated by GeoServer, store it somewhere not accessible by anyone, and delete any security/masterpw.info or whatever file you used to dump the password in clear.

                                "},{"location":"security/webadmin/passwords/#keystore-password-providers","title":"Keystore Password Providers","text":"

                                This section provides the options for adding, removing, and editing keystore password providers.

                                Keystore password provider list

                                Note

                                By default the login to Admin GUI and REST APIs with Keystore Password is disabled. In order to enable it you will need to manually change the Keystore Password Provider config.xml, usually located into security/masterpw/default/config.xml, by adding the following statement:

                                ``<loginEnabled>true</loginEnabled>``\n
                                "},{"location":"security/webadmin/passwords/#password-policies","title":"Password policies","text":"

                                This section configures the various Password policies available to users in GeoServer. New password policies can be added or renamed, and existing policies edited or removed.

                                By default there are two password policies in effect, default and root. The default password policy, intended for most GeoServer users, does not have any active password constraints. The keystore password policy, intended for the Root account, specifies a minimum password length of eight characters. Password policies are applied to users via the user/group service.

                                List of password policies

                                Clicking an existing policy enables editing, while clicking the Add new button will create a new password policy.

                                Creating a new password policy

                                "},{"location":"security/webadmin/services/","title":"Services","text":"

                                This section provides access to the settings for Service Security. GeoServer can limit access based on OWS services (WFS, WMS, etc.) and their specific operations (GetCapabilities, GetMap, and so on).

                                By default, no service-based security is in effect in GeoServer. However rules can be added, removed, or edited here.

                                Service access rules list

                                Clicking the Add a new rule link will create a new rule.

                                New service rule

                                Option Description

                                Service Sets the OWS service for this rule. Options are *, meaning all services, wcs, wfs, or wms.

                                Method Sets the specific operation for this rule. Options depend on the Service, but include *, meaning all operations, as well as every service operation known to GeoServer, such as Capabilities, Transaction, GetMap, and more.

                                Grant access to any role If selected, the rule will apply to all roles (no need to specify which ones)

                                Role list Full list of roles, including a list of roles to which the rule is associated. Association can be switched here via the arrow buttons. This option is not applied if Grant access to any role is checked.

                                Add a new role Shortcut to adding a new role

                                "},{"location":"security/webadmin/settings/","title":"Settings","text":"

                                The Settings page controls the global GeoServer security settings.

                                Security Settings page

                                "},{"location":"security/webadmin/settings/#active-role-service","title":"Active role service","text":"

                                This option sets the active role service (provides information about roles). Role services are managed on the Users, Groups, Roles page. There can be only one active role service at one time.

                                "},{"location":"security/webadmin/settings/#encryption","title":"Encryption","text":"

                                The GeoServer user interface (UI) can sometimes expose parameters in plain text inside the URLs. As a result, it may be desirable to encrypt the URL parameters. To enable encryption, select Encrypt web admin URL parameters. This will configure GeoServer to uses a PBE-based Password encryption.

                                For example, with this feature enabled, the page:

                                http://GEOSERVER/web/?wicket:bookmarkablePage=:org.geoserver.security.web.SecuritySettingsPage\n

                                would now be found at the following URL:

                                http://GEOSERVER/web/?x=hrTNYMcF3OY7u4NdyYnRanL6a1PxMdLxTZcY5xK5ZXyi617EFEFCagMwHBWhrlg*ujTOyd17DLSn0NO2JKO1Dw\n
                                "},{"location":"security/webadmin/settings/#password-encryption","title":"Password encryption","text":"

                                This setting allows you to select the type of Password encryption used for passwords. The options are Plain text, Weak PBE, or Strong PBE.

                                If Strong PBE is not available as part of the JVM, a warning will display and the option will be disabled. To enable Strong PBE, you must install external policy JARs that support this form of encryption. See the section on Password encryption for more details about these settings.

                                Warning if Strong PBE is not available

                                "},{"location":"security/webadmin/ugr/","title":"Users, Groups, Roles","text":"

                                This section provides the configuration options for User/group services and Role services. In addition, users, groups, and roles themselves and can be added, edited, or removed. A great deal of configuration can be accomplished in this section and related pages.

                                "},{"location":"security/webadmin/ugr/#security_webadmin_usergroupservices","title":"User Group Services","text":"

                                In this menu, user/group services can be added, removed, or edited. By default, there is one user/group service in GeoServer, which is XML-based. It is encrypted with Weak PBE and uses the default password policy. It is also possible to have a user/group service based on JDBC, with or without JNDI.

                                User/group services

                                Clicking an existing user/group service will enable editing, while clicking the Add new link will configure a new user/group service.

                                There are three tabs for configuration: Settings, Users, and Groups.

                                Note

                                When creating a new user/group service, the form filled out initially can be found under the Settings tab.

                                "},{"location":"security/webadmin/ugr/#add-new-xml-usergroup-service","title":"Add new XML user/group service","text":"

                                To add a new XML user/group service, click the Add new link. XML is the default option. The following figure shows the configuration options for an XML user/group service.

                                Adding an XML user/group service

                                Option Description

                                Name The name of the user/group service

                                Password encryption Sets the type of Password encryption. Options are Plain text, Weak PBE, Strong PBE, and Digest.

                                Password policy Sets the password policy. Options are any active password policies as set in the Passwords section.

                                XML filename Name of the file that will contain the user and group information. Default is users.xml in the security/usergroup/<name_of_usergroupservice> directory.

                                Enable schema validation If selected, forces schema validation to occur every time the XML file is read. This option is useful when editing the XML file by hand.

                                File reload interval Defines the frequency (in milliseconds) in which GeoServer will check for changes to the XML file. If the file is found to have been modified, GeoServer will recreate the user/group database based on the current state of the file. This value is meant to be set in cases where the XML file contents might change \"out of process\" and not directly through the web admin interface. The value is specified in milliseconds. A value of 0 disables any checking of the file.

                                "},{"location":"security/webadmin/ugr/#add-new-jdbc-usergroup-service","title":"Add new JDBC user/group service","text":"

                                To add a new JDBC user/group service, click the Add new link, and then the JDBC option at the top of the following form. The following figure shows the configuration options for a JDBC user/group service.

                                Adding a user/group service via JDBC

                                Option Description

                                Name Name of the JDBC user/group service in GeoServer

                                Password encryption The method to used to encrypt user passwords

                                Password policy The policy to use to enforce constraints on user passwords

                                JNDI When unchecked, specifies a direct connection to the database. When checked, specifies an existing connection located through JNDI.

                                Driver class name JDBC driver to use for the database connection

                                Connection URL Specifies the JDBC URL to use when creating the database connection

                                Username Username to use when connecting to the database

                                Password Password to use when connecting to the database

                                Create database tables Specifies whether to create all the necessary tables in the underlying database

                                Data Definition Language (DDL) file Specifies a custom DDL file to use for creating tables in the underlying database, for cases where the default DDL statements fail on the given database. If left blank, internal defaults are used.

                                Data Manipulation Language (DML) file Specifies a custom DML file to use for accessing tables in the underlying database, for cases where the default DML statements fail on the given database. If left blank, internal defaults are used.

                                In addition to the parameters listed above, the following additional parameter will apply when the JNDI flag is set.

                                Adding a user/group service via JDBC with JNDI

                                Option Description

                                JNDI resource name JNDI name used to locate the database connection.

                                "},{"location":"security/webadmin/ugr/#add-new-ldap-usergroup-service","title":"Add new LDAP user/group service","text":"

                                To add a new LDAP user/group service, click the Add new link, and then the LDAP option at the top of the following form. The following figure shows the configuration options for a LDAP user/group service.

                                Adding a user/group service via LDAP

                                +---------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Option | Description | +===================================================+==============================================================================================================================================================================+ | Name | Name of the LDAP role service in GeoServer | +---------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Password encryption | The method to used to encrypt user passwords | +---------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Password policy | The policy to use to enforce constraints on user passwords | +---------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Server URL | URL for the LDAP server connection. It must include the protocol, host, and port, as well as the \"distinguished name\" (DN) for the root of the LDAP tree. | +---------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | TLS | Enables a STARTTLS connection. (See the section on Secure LDAP connections.) | +---------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Group search base | Relative name of the node in the tree to use as the base for LDAP groups. Example: ou=groups. The root DN specified as port of the Server URL is automatically appended. | +---------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Filter to search all groups | Sets the LDAP filter for search all groups available. Leave blank to derive from attribute. | +---------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Filter to search group by name | Sets the LDAP filter for search a group by its name. Leave blank to derive from attribute. | +---------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Attribute which contains the name of the group | Sets attribute containing the group name. Leave blank to derive from name filter. | +---------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Query format to retrieve the user/group mapping | Query format used for mapping user/group memberships. Leave blank to derive from attribute. This may contain some placeholder values: | | | | | | {0}, the username of the user, for example bob. | | | | | | {1}, the full DN of the user, for example uid=bob,ou=users. | +---------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Attribute name to retrieve the user/group mapping | Attribute name used for mapping user/group memberships. Leave blank to derive from filter. | +---------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | User search base | LDAP search base for users. | +---------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Filter to search all users | Sets the filter for search all available users. Leave blank to derive from attribute. | +---------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Filter to search user by name | Sets the filter format for search a user by its name. Leave blank to derive from attribute. | +---------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Attribute which contains the name of the user | Sets the attribute containing the name for users. Leave blank to derive from name filter. | +---------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | List of attributes to populate | Sets a comma separated list of attributes to populate on users. | +---------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Authenticated onto the LDAP before querying | When checked all LDAP searches will be done in authenticated mode, using the credentials given with the Username and Password options | +---------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Username | Username to use when connecting to the LDAP server. Only applicable when the Authenticated onto the LDAP before querying parameter is checked. | +---------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Password | Password to use when connecting to the LDAP server. Only applicable when the Authenticated onto the LDAP before querying parameter is checked. | +---------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Enable Hierarchical groups search | When checked all LDAP group searches will use hierarchical mode, retrieving LDAP parent groups too. | +---------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Max depth for hierarchical groups search | Max depth number for hierarchical LDAP groups search, use -1 for infinite depth. Only applicable when the Enable Hierarchical groups search parameter is checked. | +---------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Nested group search filter | LDAP search pattern for searching parent groups. Only applicable when the Enable Hierarchical groups search parameter is checked. | +---------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+

                                "},{"location":"security/webadmin/ugr/#edit-usergroup-service","title":"Edit user/group service","text":"

                                Once the new user/group service is added (either XML or JDBC), clicking on it in the list of user/group services will allow additional options to be specified, such as the users and groups associated with the service.

                                There are three tabs in the resulting menu: Settings, Users, and Groups. The Settings tab is identical to that found when creating the user/group service, while the others are described below.

                                The Users tab provides options to configure users in the user/group service.

                                Users tab

                                Clicking a username will allow its parameters to be changed, while clicking the Add new link will create a new user.

                                "},{"location":"security/webadmin/ugr/#security_webadmin_users","title":"Add user","text":"

                                Creating or editing a user

                                Option Description

                                User name The name of the user

                                Enabled When selected, will enable the user to authenticate

                                Password The password for this user. Existing passwords will be obscured when viewed.

                                Confirm password To set or change the password enter the password twice.

                                User properties Key/value pairs associated with the user. Used for associating additional information with the user.

                                Group list Full list of groups, including list of groups to which the user is a member. Membership can be toggled here via the arrow buttons.

                                Add a new group Shortcut to adding a new group. Also available in the Groups tab.

                                Role list Full list of roles, including a list of roles to which the user is associated. Association can be toggled here via the arrow buttons.

                                Add a new role Shortcut to adding a new role

                                List of current roles for the user List of current roles associated with the user. Click a role to enable editing.

                                The Groups tab provides configuration options for groups in this user/group service. There are options to add and remove a group, with an additional option to remove a group and the roles associated with that group.

                                Groups tab

                                "},{"location":"security/webadmin/ugr/#security_webadmin_groups","title":"Remove User","text":"

                                There are two related buttons that are responsible for removing users: Remove Selected, and Remove Selected and remove role associations.

                                • Remove Selected removes user from users.xml and leave untouched roles.xml.
                                • Remove Selected and remove role associations removes user from users.xml and also removes user and associated role to user from roles.xml.

                                Users tab

                                "},{"location":"security/webadmin/ugr/#add-group","title":"Add group","text":"

                                Creating or editing a group

                                Option Description

                                Group name The name of the group

                                Enabled When selected the group will be active

                                Role list Full list of roles, including a list of roles to which the group is associated. Association can be toggled here via the arrow buttons.

                                Add a new role Shortcut to adding a new role

                                In this menu, user/group services can be added, removed, or edited. By default, there is one user/group service in GeoServer, which is XML-based. It is encrypted with Weak PBE and uses the default password policy. It is also possible to have a user/group service based on JDBC with or without JNDI.

                                "},{"location":"security/webadmin/ugr/#security_webadmin_roleservices","title":"Role services","text":"

                                In this menu, role services can be added, removed, or edited. By default, the active role service in GeoServer is XML-based, but it is also possible to have a role service based on JDBC, with or without JNDI.

                                The Administrator role is called ROLE_ADMINISTRATOR.

                                Role services

                                Clicking an existing role service will open it for editing, while clicking the Add new link will configure a new role service.

                                There are two pages for configuration: Settings and Roles.

                                Note

                                When creating a new role service, the form filled out initially can be found under the Settings tab.

                                "},{"location":"security/webadmin/ugr/#add-new-xml-role-service","title":"Add new XML role service","text":"

                                To add a new XML role service, click the Add new link. XML is the default option. The following figure shows the configuration options for an XML role service.

                                Adding an XML role service

                                Option Description

                                Name The name of the role service

                                Administrator role The name of the role that performs the administrator functions

                                XML filename Name of the file that will contain the role information. Default is roles.xml in the security/role/<name_of_roleservice> directory.

                                File reload interval Defines the frequency (in milliseconds) in which GeoServer will check for changes to the XML file. If the file is found to have been modified, GeoServer will recreate the user/group database based on the current state of the file. This value is meant to be set in cases where the XML file contents might change \"out of process\" and not directly through the web admin interface. The value is specified in milliseconds. A value of 0 disables any checking of the file.

                                "},{"location":"security/webadmin/ugr/#add-new-jdbc-role-service","title":"Add new JDBC role service","text":"

                                To add a new XML role service, click the Add new link, and then the JDBC option at the top of the following form. The following figure shows the configuration options for a JDBC role service.

                                Adding a role service via JDBC

                                Option Description

                                Name Name of the JDBC role service in GeoServer

                                Administrator role The name of the role that performs the administrator function

                                JNDI When unchecked, specifies a direct connection to the database. When checked, specifies an existing connection located through JNDI.

                                Driver class name JDBC driver to use for the database connection

                                Connection URL Specifies the JDBC URL to use when creating the database connection

                                Username Username to use when connecting to the database

                                Password Password to use when connecting to the database

                                Create database tables Specifies whether to create all the necessary tables in the underlying database

                                Data Definition Language (DDL) file Specifies a custom DDL file to use for creating tables in the underlying database, for cases where the default DDL statements fail on the given database. If left blank, internal defaults are used.

                                Data Manipulation Language (DML) file Specifies a custom DML file to use for accessing tables in the underlying database, for cases where the default DML statements fail on the given database. If left blank, internal defaults are used.

                                In addition to the parameters listed above, the following additional parameter will apply when the JNDI flag is set.

                                Adding a role service via JDBC with JNDI

                                Option Description

                                JNDI resource name JNDI name used to locate the database connection.

                                "},{"location":"security/webadmin/ugr/#add-new-ldap-role-service","title":"Add new LDAP role service","text":"

                                To add a new LDAP role service, click the Add new link, and then the LDAP option at the top of the following form. The following figure shows the configuration options for a LDAP role service.

                                Adding a role service via LDAP

                                Option Description

                                Name Name of the LDAP role service in GeoServer

                                Administrator role The name of the role that performs the administrator function

                                Group administrator role The name of the role that performs the group administrator function

                                Server URL URL for the LDAP server connection. It must include the protocol, host, and port, as well as the \"distinguished name\" (DN) for the root of the LDAP tree.

                                TLS Enables a STARTTLS connection. (See the section on Secure LDAP connections.)

                                Group search base Relative name of the node in the tree to use as the base for LDAP groups. Example: ou=groups. The root DN specified as port of the Server URL is automatically appended.

                                Group user membership search filter Search pattern for extracting users of a LDAP group a user belongs to. This may contain some placeholder values: {0}, the username of the user, for example bob. {1}, the full DN of the user, for example uid=bob,ou=users. To use this placeholder, the Filter used to lookup user needs to be defined, so that the dn of a user can be extracted from its username.

                                All groups search filter Search pattern for locating the LDAP groups to be mapped to GeoServer roles inside the Group search base root node

                                Filter used to lookup user. optional filter used to extract a user dn, to be used together with Group user membership search filter when the {1} placeholder is specified. This may contain a placeholder value: {0}, the username of the user, for example bob.

                                Role prefix Prefix appended in front of role names extracted from the LDAP. If left blank, no prefix will be inserted.

                                Convert Role To Upper Case If selected all role names extracted from the LDAP will be converted to upper case.

                                Authenticate to extract roles When checked all LDAP searches will be done in authenticated mode, using the credentials given with the Username and Password options

                                Username Username to use when connecting to the LDAP server. Only applicable when the Authenticate to extract roles parameter is checked.

                                Password Password to use when connecting to the LDAP server. Only applicable when the Authenticate to extract roles parameter is checked.

                                Enable Hierarchical groups search When checked all LDAP group searches will use hierarchical mode, retrieving LDAP parent groups too.

                                Max depth for hierarchical groups search Max depth number for hierarchical LDAP groups search, use -1 for infinite depth. Only applicable when the Enable Hierarchical groups search parameter is checked.

                                Nested group search filter LDAP search pattern for searching parent groups. Only applicable when the Enable Hierarchical groups search parameter is checked.

                                "},{"location":"security/webadmin/ugr/#edit-role-service","title":"Edit role service","text":"

                                Once the new role service is added (either XML or JDBC), clicking it in the list of role services will allow the additional options to be specified, such as the roles associated with the service.

                                There are two tabs in the resulting menu: Settings and Roles. The Settings tab is identical to that found when creating the role service, while the Roles tab is described below.

                                Roles tab

                                Clicking a role will allow its parameters to be changed, while clicking the Add new link will create a new role.

                                "},{"location":"security/webadmin/ugr/#security_webadmin_roles","title":"Add role","text":"

                                Creating or editing a role

                                Option Description

                                Role name The name of role. Convention is uppercase, but is not required.

                                Parent roles The role that this role inherits. See the section on Roles for more information on inheritance.

                                Role parameters Key/value pairs associated with the role. Used for associating additional information with the role.

                                "},{"location":"services/","title":"Services","text":"

                                GeoServer serves data using standard protocols established by the Open Geospatial Consortium:

                                • The Web Map Service (WMS) supports requests for map images (and other formats) generated from geographical data.
                                • The Web Feature Service (WFS) supports requests for geographical feature data (with vector geometry and attributes).
                                • The Web Coverage Service (WCS) supports requests for coverage data (rasters).

                                These services are the primary way that GeoServer supplies geospatial information.

                                • Web Map Service (WMS)
                                • Web Feature Service (WFS)
                                • Web Coverage Service (WCS)
                                • Web Processing Service (WPS)
                                • Catalog Services for the Web (CSW)
                                • Web Map Tile Service (WMTS)
                                "},{"location":"services/csw/","title":"Catalog Services for the Web (CSW)","text":"

                                This section discusses the Catalog Services for Web (CSW) optional extension. With this extension, GeoServer supports retrieving and displaying items from the GeoServer catalog using the CSW service.

                                For more information on CSW, please refer to OGC OpenGIS Implementation Specification 07-006r1 and the OGC tutorial on CSW.

                                • Installing Catalog Services for Web (CSW)
                                • Catalog Services for the Web (CSW) features
                                • DirectDownload

                                See the Catalog Services for the Web (CSW) ISO Metadata tutorial for a tutorial on how to use the CSW Metadata Module.

                                "},{"location":"services/csw/directdownload/","title":"DirectDownload","text":"

                                DirectDownload is a new operation (since GeoServer 2.9.x) supported by the CSW service.

                                In the Meteorology, Oceanography and Earth Observation domains, layers are usually based on complex NetCDF/GRIB files. Protocols such as WCS are set up to allow slice, rescale and reprojection of data, but not to preserve the original data as is.

                                This new operation allows direct download of the raw data for that layer. If the DirectDownload capability is enabled for a Coverage layer, the CSW record will be updated to contain links pointing back to the CSW service, using the DirectDownload vendor operation that will assemble the files for the requested resource, zip them, and send the result back to the requester.

                                The download links (one for each data file composing the layer plus a link to get all the files composing the layer) are added as new entries in CSW records:

                                • as additional term-references element for a Dublin Core schema
                                • as additional OnlineResource for ISO Metadata

                                Those links also contain the validity domain for the file such as envelope/time/elevation/custom dimensions (when present) for multidimensional layers.

                                "},{"location":"services/csw/directdownload/#configuration","title":"Configuration","text":"

                                DirectDownload capability can be activated as default for all layers, as global CSW configuration. Go into the CSW service panel and click on the enable DirectDownload checkbox if you want it enabled for all layers:

                                DirectDownload configuration (Service level)

                                From this section you can also set a download size limit value (0 means no limit). The specified value represents the maximum size (in kilobytes) of the sum of the sizes of the raw data referred to by a single download link. (You can think about the case of a download link referring to the whole layer data which may contain a wide set of files).

                                Note that the size check is performed on the raw data files prior to any compression.

                                "},{"location":"services/csw/directdownload/#per-layer-configuration","title":"Per Layer configuration","text":"

                                DirectDownload capability can also be enabled/disabled for a specific layer, which will override the global CSW configuration.

                                Go to the publishing tab of the layer.

                                Layer publishing section

                                Look for the DirectDownload settings section.

                                DirectDownload configuration (Layer level)

                                The configuration of this parameter follows the same rules as shown for the CSW configuration panel.

                                "},{"location":"services/csw/directdownload/#getrecords-example","title":"GetRecords example","text":"

                                A GetRecords response containing a layer with DirectDownload enabled, may result having a piece like this (using ISO Metadata output schema<csw_iso>):

                                ...\n<gmd:CI_OnlineResource>\n  <gmd:linkage>\n    <gmd:URL>\n    http://localhost:8080/geoserver/ows?service=CSW&version=2.0.2&request=DirectDownload&resourceId=geosolutions:Reflectivity_height_above_ground&file=82643c5bf682f67ef8b7de737b90ada759965cd8-samplefile.grib2&ENVELOPE=-2699073.2421875,-1588806.0302734375,2697926.7578125,1588193.9697265625&TIME=2015-06-23T00:00:00.000Z/2015-06-23T00:00:00.000Z&HEIGHT_ABOVE_GROUND=1000.0/4000.0\n    </gmd:URL>\n  </gmd:linkage>\n</gmd:CI_OnlineResource>\n...\n

                                That URL allows the direct download of the indicated file. Note that the filename has a SHA-1 header to avoid publishing the underlying file system structure paths.

                                "},{"location":"services/csw/features/","title":"Catalog Services for the Web (CSW) features","text":""},{"location":"services/csw/features/#supported-operations","title":"Supported operations","text":"

                                The following standard CSW operations are currently supported:

                                • GetCapabilities
                                • GetRecords
                                • GetRecordById
                                • GetDomain
                                • DescribeRecord

                                (Starting with GeoServer 2.9.x, a new vendor operation has been added: DirectDownload)

                                The Internal Catalog Store supports filtering on both full x-paths as well as the \"Queryables\" specified in GetCapabilities.

                                "},{"location":"services/csw/features/#catalog-stores","title":"Catalog stores","text":"

                                The default catalog store is the Internal Catalog Store, which retrieves information from the GeoServer's internal catalog. The Simple Catalog Store (simple-store module) adds an alternative simple store which reads the catalog data directly from files (mainly used for testing).

                                If there are multiple catalog stores present (for example, when the Simple Catalog Store module is loaded), set the Java system property DefaultCatalogStore to make sure that the correct catalog store will be used. To use the Internal Catalog Store, this property must be set to:

                                DefaultCatalogStore=org.geoserver.csw.store.internal.InternalCatalogStore\n

                                To use the Simple Catalog Store:

                                DefaultCatalogStore=org.geoserver.csw.store.simple.GeoServerSimpleCatalogStore\n
                                "},{"location":"services/csw/features/#supported-schemes","title":"Supported schemes","text":"

                                The Internal Catalog Store currently supports two metadata schemes:

                                • Dublin Core, by default.
                                • ISO Metadata Profile, if you install the Catalog Services for the Web (CSW) - ISO Metadata Profile Community Module.
                                "},{"location":"services/csw/features/#csw_mapping_file","title":"Mapping Files","text":"

                                Mapping files are located in the csw directory inside the GeoServer data directory. Assuming that each layer is mapped to a single record, each mapping file has the exact name of the record type name, combined with the .properties extension. For example:

                                • Dublin Core mapping can be found in the file csw/Record.properties inside the data directory.
                                • ISO Metadata mapping can be found in the file csw/MD_Metadata.properties inside the data directory (see Catalog Services for the Web (CSW) - ISO Metadata Profile Community Module).

                                There is also the possibility of having mapping each layer to multiple records. In this case, one would have multiple mapping files per type. Each mapping file will be applied to each layer. For instance, if there are three ISO Metadata mapping files, each layer will generate three ISO Metadata records, one for each mapping file. Practically, the different mapping files must be given unique names, encoded in the file name after the type name, followed by a dash, and before the extension. At most one mapping file per type can be nameless (as in the above example). For instance, one could have the following files in the csw directory:

                                • csw/Record.properties
                                • csw/Record-otherRecord.properties
                                • csw/Record-thirdRecord.properties
                                • csw/MD_Metadata.properties
                                • csw/MD_Metadata-otherRecord.properties
                                • csw/MD_Metadata-thirdRecord.properties

                                In this example, each of the two types have three mapping files: one nameless, one called otherRecord and one called thirdRecord. Each layer will thus generate three records for each type. Geoserver will assume that mappings of different type but with the same name refer to the same record (in another format). (This is only relevant for GetRecords requests where outputSchema and typeNames do not match\u00b8 which is unusual). The user is responsible for ensuring that identifiers are unique accross all mappings of the same record type.

                                The mapping files take the syntax from Java properties files. The left side of the equals sign specifies the target field name or path in the metadata record, paths being separated with dots. The right side of the equals sign specifies any CQL expression that denotes the value of the target property. The CQL expression is applied to each ResourceInfo object in the catalog and can retrieve all properties from this object. These expressions can make use of literals, properties present in the ResourceInfo object, and all normal CQL operators and functions. There is also support for complex data structures such as Maps using the dot notation and Lists using the bracket notation (Example mapping files are given below).

                                The properties in the ResourceInfo object that can be used are:

                                name\nqualifiedName\nnativeName\nqualifiedNativeName\nalias\ntitle\nabstract\ndescription\nmetadata.?\nnamespace\nnamespace.prefix\nnamespace.name\nnamespace.uri\nnamespace.metadata.?\nkeywords\nkeywords[?]\nkeywords[?].value\nkeywords[?].language\nkeywords[?].vocabulary\nkeywordValues\nkeywordValues[?]\nmetadataLinks\nmetadataLinks[?]\nmetadataLinks[?].id\nmetadataLinks[?].about\nmetadataLinks[?].metadataType\nmetadataLinks[?].type\nmetadataLinks[?].content\nlatLonBoundingBox\nlatLonBoundingBox.dimension\nlatLonBoundingBox.lowerCorner\nlatLonBoundingBox.upperCorner\nnativeBoundingBox\nnativeBoundingBox.dimension\nnativeBoundingBox.lowerCorner\nnativeBoundingBox.upperCorner\nsrs\nnativeCrs\nprojectionPolicy\nenabled\nadvertised\ncatalog.defaultNamespace\ncatalog.defaultWorkspace\nstore.name\nstore.description\nstore.type\nstore.metadata.?\nstore.enabled\nstore.workspace\nstore.workspace.name\nstore.metadata.?\nstore.connectionParameters.?\nstore.error\n

                                Depending on whether the resource is a FeatureTypeInfo or a CoverageInfo, additional properties may be taken from their respective object structure. You may use REST to view an xml model of feature types and datastores in which the xml tags represent the available properties in the objects.

                                Some fields in the metadata schemes can have multiple occurrences. They may be mapped to properties in the Catalog model that are also multi-valued, such as for example keywords. It is also possible to use a filter function called list to map multiple single-valued or multi-valued catalog properties to a MetaData field with multiple occurrences (see in ISO MetaData Profile example, mapping for the identificationInfo.AbstractMD_Identification.citation.CI_Citation.alternateTitle field).

                                Placing the @ symbol in front of the field will set that to use as identifier for each metadata record. This may be useful for ID filters. Use a $ sign in front of fields that are required to make sure the mapping is aware of the requirement (specifically for the purpose of property selection).

                                Below is an example of a Dublin Core mapping file:

                                @identifier.value=id\ntitle.value=title\ncreator.value='GeoServer Catalog'\nsubject.value=keywords\nsubject.scheme='http://www.digest.org/2.1'\nabstract.value=abstract\ndescription.value=strConcat('description about ' , title)\ndate.value=\"metadata.date\"\ntype.value='http://purl.org/dc/dcmitype/Dataset'\npublisher.value='Niels Charlier'\n#format.value=\n#language.value=\n#coverage.value=\n#source.value=\n#relation.value=\n#rights.value=\n#contributor.value=\n

                                All fields have the form of <fieldname>.value for the actual value in the field. Additionally <fieldname>.scheme can be specified for the @scheme attribute of this field.

                                Examples of attributes extracted from the ResourceInfo are id, title, and keywords, etc. The attribute metadata.date uses the metadata (java.util.)Map from the Resource object. In this map, it searches for the keyword \"date\".

                                Note that double quotes are necessary in order to preserve this meaning of the dots.

                                "},{"location":"services/csw/installing/","title":"Installing Catalog Services for Web (CSW)","text":"

                                The CSW extension is listed among the other extension downloads on the GeoServer download page.

                                The installation process is similar to other GeoServer extensions:

                                1. Download the csw

                                  Verify that the version number in the filename corresponds to the version of GeoServer you are running (for example 2.24.2 above).

                                2. Extract the contents of the archive into the WEB-INF/lib directory in GeoServer. Make sure you do not create any sub-directories during the extraction process.

                                3. Restart GeoServer or the servlet container, as appropriate to your configuration.

                                4. Verify that the module was installed correctly by navigating to the Welcome page of the Web administration interface and seeing the CSW entry is listed in the Service Capabilities list, and the CSW modules are listed in the Web administration interface Module list.

                                CSW Installation Verification

                                "},{"location":"services/wcs/","title":"Web Coverage Service (WCS)","text":"

                                This section describes the Web Coverage Service (WCS).

                                • WCS settings
                                • WCS basics
                                • GetCapabilities
                                • WCS output formats
                                • WCS Vendor Parameters
                                • WCS configuration
                                • WCS Request Builder
                                "},{"location":"services/wcs/basics/","title":"WCS basics","text":"

                                GeoServer provides support for Open Geospatial Consortium (OGC) Web Coverage Service (WCS) versions 1.0, 1.1 and 2.0. One can think of WCS as the equivalent of Web Feature Service (WFS), but for raster data instead of vector data. It lets you get at the raw coverage information, not just the image. GeoServer is the reference implementation for WCS 1.1.

                                "},{"location":"services/wcs/configuration/","title":"WCS configuration","text":""},{"location":"services/wcs/configuration/#coverage-processing","title":"Coverage processing","text":"

                                The WCS processing chain can be tuned in respect of how raster overviews and read subsampling are used.

                                The overview policy has four possible values:

                                Option Description Version

                                Lower resolution overview Looks up the two overviews with a resolution closest to the one requested and chooses the one at the lower resolution. 2.0.3

                                Don't use overviews Overviews will be ignored, the data at its native resolution will be used instead. This is the default value. 2.0.3

                                Higher resolution overview Looks up the two overviews with a resolution closest to the one requested and chooses the one at the higher resolution. 2.0.3

                                Closest overview Looks up the overview closest to the one requested 2.0.3

                                While reading coverage data at a resolution lower than the one available on persistent storage its common to use subsampling, that is, read one every N pixels as a way to reduce the resolution of the data read in memory. Use subsampling controls whether subsampling is enabled or not.

                                "},{"location":"services/wcs/configuration/#resource-consumption-limits","title":"Resource consumption limits","text":"

                                The request limit options allow the administrator to limit the resources consumed by each WCS GetCoverage request.

                                The request limits limit the size of the image read from the source and the size of the image returned to the client. Both of these limits are to be considered a worst case scenario and are setup to make sure the server never gets asked to deal with too much data.

                                Option Description Version

                                Maximum input memory Sets the maximum amount of memory, in kilobytes, a GetCovearge request might use, at most, to read a coverage from the data source. The memory is computed as rw * rh * pixelsize, where rw and rh are the size of the raster to be read and pixelsize is the dimension or a pixel (e.g., a RGBA image will have 32bit pixels, a batimetry might have 16bit signed int ones) 2.0.3

                                Maximum output memory Sets the maximum amount of memory, in kilobytes, a GetCoverage request might use, at most, to host the resulting raster. The memory is computed as ow * oh * pixelsize, where ow and oh are the size of the raster to be generated in output. 2.0.3

                                Max number of dimension values Sets the maximum number of dimension (time, at least for now) values that a client can request in a GetCoverage request (the work to be done is usually proportional to said number of times, and the list of values is kept in memory during the processing) 2.14.0

                                To understand the limits let's consider a very simplified example in which no tiles and overviews enter the game:

                                • The request hits a certain area of the original raster. Reading it at full resolution requires grabbing a raster of size rw * rh, which has a certain number of bands, each with a certain size. The amount of memory used for the read will be rw * rh * pixelsize. This is the value measured by the input memory limit
                                • The WCS performs the necessary processing: band selection, resolution change (downsampling or upsampling), reprojection
                                • The resulting raster will have size ow * oh and will have a certain number of bands, possibly less than the input data, each with a certain size. The amount of memory used for the final raster will be ow * oh * pixelsize. This is the value measured by the output memory limit.
                                • Finally the resulting raster will be encoded in the output format. Depending on the output format structure the size of the result might be higher than the in memory size (ArcGrid case) or smaller (for example in the case of GeoTIFF output, which is normally LZW compressed)

                                In fact reality is a bit more complicated:

                                • The input source might be tiled, which means there is no need to fully read in memory the region, but it is sufficient to do so one tile at a time. The input limits won't consider inner tiling when computing the limits, but if all the input coverages are tiled the input limits should be designed considering the amount of data to be read from the persistent storage as opposed to the amount of data to be stored in memory
                                • The reader might be using overviews or performing subsampling during the read to avoid actually reading all the data at the native resolution should the output be subsampled
                                • The output format might be tile aware as well (GeoTIFF is), meaning it might be able to write out one tile at a time. In this case not even the output raster will be stored in memory fully at any given time.

                                Only a few input formats are so badly structure that they force the reader to read the whole input data in one shot, and should be avoided. Examples are: * JPEG or PNG images with world file * Single tiled and JPEG compressed GeoTIFF files

                                "},{"location":"services/wcs/configuration/#limited-srs-list","title":"Limited SRS list","text":"

                                Some clients may have problems processing a GetCapabilities document listing the complete list of SRS (projections) that GeoServer supports by default. You may also find some projections are not appropriate for your data products.

                                Use this setting to limit the default list of supported SRS (projections) for the service. This list will be used by default, individual coverages define their own list of SRS (projections).

                                Limited SRS list

                                To limit the service to only the required projections use the Limited SRS List text box to list the desired EPSG codes separated by commas, e.g. 4326,27700 .

                                "},{"location":"services/wcs/outputformats/","title":"WCS output formats","text":"

                                WCS output formats are configured coverage by coverage. The current list of output formats follows:

                                Images:

                                • JPEG - (format=jpeg)
                                • GIF - (format=gif)
                                • PNG - (format=png)
                                • Tiff - (format=tif)
                                • BMP - (format=bmp)

                                Georeferenced formats:

                                • GeoTiff - (format=geotiff)
                                • GML Coverage - (format=application/gml+xml)

                                The GML Coverage format is described by the OGC Coverage Implementation Schema, its components are also used to describe coverage metadata in WCS 2.0 DescribeCoverage responses.

                                "},{"location":"services/wcs/reference/","title":"WCS reference","text":""},{"location":"services/wcs/reference/#introduction","title":"Introduction","text":"

                                The Web Coverage Service (WCS) is a standard created by the OGC that refers to the receiving of geospatial information as 'coverages': digital geospatial information representing space-varying phenomena. One can think of it as Web Feature Service (WFS) for raster data. It gets the 'source code' of the map, but in this case it is not raw vectors but raw imagery.

                                An important distinction must be made between WCS and Web Map Service (WMS). They are similar, and can return similar formats, but a WCS is able to return more information, including valuable metadata and more formats. It additionally allows more precise queries, potentially against multi-dimensional backend formats.

                                "},{"location":"services/wcs/reference/#benefits-of-wcs","title":"Benefits of WCS","text":"

                                WCS provides a standard interface for how to request the raster source of a geospatial image. While a WMS can return an image it is generally only useful as an image. The results of a WCS can be used for complex modeling and analysis, as it often contains more information. It also allows more complex querying - clients can extract just the portion of the coverage that they need.

                                "},{"location":"services/wcs/reference/#operations","title":"Operations","text":"

                                WCS can perform the following operations:

                                Operation Description

                                GetCapabilities Retrieves a list of the server's data, as well as valid WCS operations and parameters

                                DescribeCoverage Retrieves an XML document that fully describes the request coverages.

                                GetCoverage Returns a coverage in a well-known format. Like a WMS GetMap request, but with several extensions to support the retrieval of coverages.

                                Note

                                The following examples show the 1.1 protocol, the full specification for versions 1.0, 1.1 and 2.0 are available on the OGC website

                                "},{"location":"services/wcs/reference/#wCs_getcap","title":"GetCapabilities","text":"

                                The GetCapabilities operation is a request to a WCS server for a list of what operations and services (\"capabilities\") are being offered by that server.

                                A typical GetCapabilities request would look like this (at URL http://www.example.com/wcs):

                                Using a GET request (standard HTTP):

                                http://www.example.com/wcs?\nservice=wcs&\nAcceptVersions=1.1.0&\nrequest=GetCapabilities\n

                                Here there are three parameters being passed to our WCS server, service=wcs, AcceptVersions=1.1.0, and request=GetCapabilities. At a bare minimum, it is required that a WCS request have the service and request parameters. GeoServer relaxes these requirements (setting the default version if omitted), but \"officially\" they are mandatory, so they should always be included. The service key tells the WCS server that a WCS request is forthcoming. The AcceptVersions key refers to which version of WCS is being requested. The request key is where the actual GetCapabilities operation is specified.

                                WCS additionally supports the Sections parameter that lets a client only request a specific section of the Capabilities Document.

                                "},{"location":"services/wcs/reference/#wcs_describecoverage","title":"DescribeCoverage","text":"

                                The purpose of the DescribeCoverage request is to additional information about a Coverage a client wants to query. It returns information about the crs, the metadata, the domain, the range and the formats it is available in. A client generally will need to issue a DescribeCoverage request before being sure it can make the proper GetCoverage request.

                                "},{"location":"services/wcs/reference/#wcs_getcoverage","title":"GetCoverage","text":"

                                The GetCoverage operation requests the actual spatial data. It can retrieve subsets of coverages, and the result can be either the coverage itself or a reference to it. The most powerful thing about a GetCoverage request is its ability to subset domains (height and time) and ranges. It can also do resampling, encode in different data formats, and return the resulting file in different ways.

                                "},{"location":"services/wcs/requestbuilder/","title":"WCS Request Builder","text":"

                                GeoServer includes a request builder for building and testing out WCS requests. Since WCS requests can be cumbersome to author, this tool can make working with WCS much easier.

                                "},{"location":"services/wcs/requestbuilder/#accessing-the-wcs-request-builder","title":"Accessing the WCS Request Builder","text":"

                                To access the WCS Request Builder:

                                1. Navigate to the Web administration interface.
                                2. Click the Demos link on the left side.
                                3. Select WCS Request Builder from the list of demos.

                                WCS request builder in the list of demos

                                "},{"location":"services/wcs/requestbuilder/#using-the-wcs-request-builder","title":"Using the WCS Request Builder","text":"

                                The WCS Request Builder consists of a form which can be used to generate a number of different types of requests.

                                When first opened, the form is short, only including the following options:

                                • WCS Version---Version of WCS to use when crafting the request. Options are 1.0.0 and 1.1.1.

                                • Coverage name---Coverage to use in the request. Any published (raster) layer in GeoServer can be selected.

                                  Note

                                  All other options displayed will be non-functional until Coverage name is selected.

                                WCS request builder in its initial form

                                Once selected, the remainder of the form will be displayed. The following options are available:

                                • Spatial subset---Sets the extent of the GetCoverage request in units of the layer CRS. Defaults to the full extent of the layer.
                                • Coordinate reference system---Source CRS of the layer. Default is the CRS of the layer in GeoServer.
                                • Specify source grid manually (1.0.0 only)---If checked, allows for determining the grid of pixels for the output.
                                • Target coverage layout (1.1.1 only)---Specifies how the dimensions of the output grid will be determined:
                                  • Automatic target layout---Sets that the output grid will be determined automatically.
                                  • Specify grid resolutions---Sets the resolution of the output grid. X and Y resolutions can be set differently.
                                  • Specify \"grid to world\" transformation---Sets the output using latitude/longitude, as well as X and Y scale and shear values.
                                • Target CRS---CRS of the result (output) of the GetCoverage request. If different from the Coordinate reference system, the result will be a reprojection into the target CRS.
                                • Output format---Format of the result (output) of the GetCoverage request. Any valid WCS output format is allowed. Default is GeoTIFF.

                                WCS request builder form (WCS version 1.0.0)

                                WCS request builder form (WCS version 1.1.1)

                                There is also a link for Describe coverage next to the Coverage name which will execute a WCS DescribeCoverage request for the particular layer.

                                At the bottom of the form are two buttons for form submission:

                                • Get Coverage---Executes a GetCoverage request using the parameters in the form. This will usually result in a file which can be downloaded.
                                • Generate GetCoverage XML---Generates the GetCoverage request using the parameters in the form and then, instead of executing it, outputs the request itself to the screen.

                                WCS request builder showing GetCoverage XML

                                "},{"location":"services/wcs/vendor/","title":"WCS Vendor Parameters","text":"

                                WCS vendor parameters are non-standard request parameters that are defined by an implementation to provide enhanced capabilities.

                                "},{"location":"services/wcs/vendor/#general-vendor-options","title":"General Vendor Options","text":"

                                These vendor options are available for all operations.

                                content-disposition ^^^^^^^^^^^^^^^^^^^

                                The content-disposition parameter directs how a web browser directed to handle returned content. The syntax is::

                                content-disposition=

                                Where content-disposition =attachment to direct the browser to save the content to disk.

                                Where content-disposition=inline asks the browser to display the content. Note this may present performance issues when asked to display very large content.

                                filename ^^^^^^^^

                                The filename parameter provides a suggested filename when a browser saves a file (e.g. to Downloads folder). The syntax is::

                                filename=

                                An example of filename use is::

                                filename=features.json

                                When service output is saved as a file, the vendor-option filename is used to provide the file name used.

                                "},{"location":"services/wcs/vendor/#getcoverage-request","title":"GetCoverage Request","text":""},{"location":"services/wcs/vendor/#namespace","title":"namespace","text":"

                                Requests to the WCS GetCapabilities operation can be filtered to only return layers corresponding to a particular namespace.

                                Sample code: :

                                http://example.com/geoserver/wcs?\n   service=wcs&\n   version=1.0.0&\n   request=GetCapabilities&\n   namespace=topp\n

                                Using an invalid namespace prefix will not cause any errors, but the document returned will not contain information on any layers.

                                "},{"location":"services/wcs/vendor/#cql_filter","title":"cql_filter","text":"

                                The cql_filter parameter is similar to same named WMS parameter, and allows expressing a filter using ECQL (Extended Common Query Language). The filter is sent down into readers exposing a Filter read parameter.

                                For example, assume a image mosaic has a tile index with a cloudCover percentage attribute, then it's possible to mosaic only granules with a cloud cover less than 10% using:

                                cql_filter=cloudCover < 10

                                For full details see the ECQL Reference and CQL and ECQL tutorial.

                                "},{"location":"services/wcs/vendor/#sortby","title":"sortBy","text":"

                                The sortBy parameter allows to control the order of granules being mosaicked, using the same syntax as WFS 1.0, that is:

                                • &sortBy=att1 A|D,att2 A|D, ...

                                This maps to a \"SORTING\" read parameter that the coverage reader might expose (image mosaic exposes such parameter).

                                In image mosaic, this causes the first granule found in the sorting will display on top, and then the others will follow.

                                Thus, to sort a scattered mosaic of satellite images so that the most recent image shows on top, and assuming the time attribute is called ingestion in the mosaic index, the specification will be &sortBy=ingestion D.

                                "},{"location":"services/wcs/webadmin/","title":"WCS settings","text":"

                                This page details the configuration options for WCS in the web administration interface.

                                The Web Coverage Service (WCS) provides few options for changing coverage functionality. While various elements can be configured for WFS and WMS requests, WCS allows only metadata information to be edited. This metadata information, entitled Service Metadata, is common to WCS, WFS and WMS requests.

                                WCS Configuration page

                                "},{"location":"services/wcs/webadmin/#workspace","title":"Workspace","text":"

                                Select workspace empty to configure global WCS settings.

                                See section on Workspace Services to override settings used by WCS Virtual Services.

                                "},{"location":"services/wcs/webadmin/#wcs-service-metadata","title":"WCS Service Metadata","text":"

                                For a description of WCS settings, see the section on Service Metadata.

                                "},{"location":"services/wcs/webadmin/#i18n-settings","title":"i18n Settings","text":"

                                Select the default language for the WCS Service.

                                Default language

                                See the Internationalization (i18n) section for a description of how this setting is used.

                                "},{"location":"services/wcs/webadmin/#compression-settings","title":"Compression Settings","text":"

                                Specify the default level for Deflate compression when requesting a coverage in TIFF format with Deflate compression.

                                Default Deflate compression level

                                "},{"location":"services/wfs/","title":"Web Feature Service (WFS)","text":"

                                This section describes the Web Feature Service (WFS).

                                • WFS settings
                                • WFS basics
                                • WFS reference
                                • WFS output formats
                                • WFS vendor parameters
                                • WFS schema mapping
                                • Axis ordering
                                "},{"location":"services/wfs/axis_order/","title":"Axis ordering","text":"

                                The definition of a spatial reference system includes an indication of the axis order used to interpret the coordinates. There are a number of projected spatial reference systems defined in north/east order in the formal EPSG definition, but are interpreted as being in east/north order by earlier versions of the WFS protocol.

                                • WFS 1.0.0: Provides geographic coordinates in east/north and may not be trusted to respect the EPSG definition axis order.
                                • WFS 1.1.0: Respects the axis order defined by the EPSG definition.
                                • WFS 2.0.0: Respects the axis order defined by the EPSG definition.

                                Forcing content into east/north order was intended to be easier for developers where computer displays are defined with an x/y order. However this decision has introduced no end of confusion, and was corrected in later versions of WFS.

                                Note

                                Some spatial reference systems, for example polar stereographic, do not have an east or west as they have a pole in the middle of the axis.

                                These differences may cause difficulties when clients switch between different WFS versions. To minimize confusion and increase interoperability, GeoServer has adopted the following guidelines when specifying spatial reference systems to avoid ambiguity.

                                Representation Axis order Interpretation

                                EPSG:4326 longitude/latitude assumption

                                http://www.opengis.net/gml/srs/epsg.xml#xxxx longitude/latitude strict

                                urn:x-ogc:def:crs:EPSG:xxxx latitude/longitude strict

                                urn:ogc:def:crs:EPSG::4326 latitude/longitude strict

                                "},{"location":"services/wfs/axis_order/#srslist-axis-order","title":"SRSList Axis Order","text":"

                                To compare the spatial reference system definition for EPSG:4326:

                                1. Navigate Demos \u2192 SRS List page and search for 4326.

                                2. Compare the formal EPSG definition of WGS84:

                                  WGS84 EPSG definition

                                3. With the internal definition of WGS84:

                                  WGS84 Internal definition

                                The same approach can be used to check the definition of any spatial reference system supported by GeoServer.

                                Note

                                The formal EPSG definition provides the axis-order used to interpret coordinate values. GeoServer uses an internal representation that does not always respect the EPSG provided axis order.

                                In the example above EPSG:4326 is defined with a north/east axis order, while the internal representation has east/north order.

                                The startup option -Dorg.geotools.referencing.forceXY=true is used to configure GeoServer to prefer an internal representation in east/north axis order. We recommend the default value of true to match a wide range of clients that make this assumption.

                                "},{"location":"services/wfs/axis_order/#layer-axis-order","title":"Layer Axis Order","text":"

                                The default data directory includes the following dataset illustrating this challenge:

                                • shapefile/states.shp`: Data stored in x/y order:

                                  MULTIPOLYGON (((-121.664154 38.169369,-121.781296 38.066856, ...\n
                                • shapefiles/states.prj :

                                  GEOGCS[\"GCS_WGS_1984\",DATUM[\"WGS_1984\",SPHEROID[\"WGS_1984\",6378137,298.257223563]],PRIMEM[\"Greenwich\",0],UNIT[\"Degree\",0.017453292519943295]]\n

                                  Published as topp:states with Spatial Reference System EPSG:4326.

                                To review how this layer has been published:

                                1. Navigate to the Edit Layer page for topp:states.

                                2. Locate Native SRS and click on the GCS_WGS_1984 link to show how GeoServer interpreted the PRJ file above.

                                  The PRJ did not provide an axis-order and GeoSever has filled in an assumption. This describing the data in x/y order which matches our data and we could use it unmodified.

                                  Native SRS for topp:states

                                3. Locate Declared SRS and click on EPSG:WGS 84... link to see the definition used to publish this content.

                                  This is the internal definition of EPSG:4326 as shown in the SRSList above, which also describes the data in x/y order matching our data. This definition provides slightly more readable names along with additional AUTHORITY information that may be helpful to client applications.

                                  Declared SRS for topp:states

                                4. The SRS Handling is set to Force declared to completely ignore the provided Native SRS definition and use the Declared SRS.

                                  Force declared SRS handling for topp:states

                                "},{"location":"services/wfs/axis_order/#wfs-10-axis-order","title":"WFS 1.0 Axis Order","text":"

                                GetCapabilities describes topp:states using:

                                http://localhost:8080/geoserver/ows?service=wfs&version=1.0.0&request=GetCapabilities

                                <FeatureType><Name>topp:states</Name>\n  <Title>USA Population</Title>\n  <Abstract>This is some census data on the states.</Abstract>\n  <Keywords>census, united, boundaries, state, states</Keywords>\n  <SRS>EPSG:4326</SRS>\n  <LatLongBoundingBox minx=\"-124.731422\" miny=\"24.955967\" maxx=\"-66.969849\" maxy=\"49.371735\" />\n</FeatureType> \n

                                WFS 1.0 describes the latitude / longitude bounds with the understanding that you will associate minx and maxx with longitude, and also miny and maxy with latitude.

                                WFS 1.0 GetFeature request defaults to GML2 output, and the default EPSG:4326 spatial reference system used to publish the layer:

                                • WFS 1.0 Default: http://localhost:8080/geoserver/ows?service=WFS&version=1.0.0&request=GetFeature&typeName=topp%3Astates&featureId=states.1

                                  The GML2 output uses http://www.opengis.net/gml/srs/epsg.xml#4326 reference, with data in x/y order:

                                  <gml:MultiPolygon srsName=\"http://www.opengis.net/gml/srs/epsg.xml#4326\">\n  <gml:polygonMember>\n    <gml:Polygon>\n      <gml:outerBoundaryIs><gml:LinearRing>\n        <gml:coordinates decimal=\".\" cs=\",\" ts=\" \">\n          -88.071564,37.51099 -88.087883,37.476273\n
                                "},{"location":"services/wfs/axis_order/#wfs-10-output-format-gml3","title":"WFS 1.0 output format GML3","text":"
                                • GML3.1 (default EPSG:4326):

                                  http://localhost:8080/geoserver/topp/ows?service=WFS&version=1.0.0&request=GetFeature&typeName=topp%3Astates&featureId=states.1&outputFormat=gml3

                                  GML3 output uses http://www.opengis.net/gml/srs/epsg.xml#4326 reference, with data in x/y order:

                                  <gml:MultiSurface srsName=\"http://www.opengis.net/gml/srs/epsg.xml#4326\">\n  <gml:surfaceMember>\n    <gml:Polygon>\n      <gml:exterior>\n        <gml:LinearRing>\n          <gml:posList>\n            -88.071564 37.51099 -88.087883 37.476273\n
                                • GML3.1 reproject to EPSG:4326

                                  http://localhost:8080/geoserver/topp/ows?service=WFS&version=1.0.0&request=GetFeature&typeName=topp%3Astates&featureId=states.1&outputFormat=gml3&srsName=urn:x-ogc:def:crs:EPSG:4326

                                  GML3 output uses http://www.opengis.net/gml/srs/epsg.xml#4326 reference, with data in x/y order:

                                  <gml:MultiSurface srsName=\"http://www.opengis.net/gml/srs/epsg.xml#4326\">\n  <gml:surfaceMember>\n    <gml:Polygon>\n      <gml:exterior>\n        <gml:LinearRing>\n          <gml:posList>\n            -88.071564 37.51099 -88.087883\n
                                • GML 3.1 reproject to urn:x-ogc:def:crs:EPSG:4326

                                  http://localhost:8080/geoserver/topp/ows?service=WFS&version=1.0.0&request=GetFeature&typeName=topp%3Astates&featureId=states.1&outputFormat=gml3&srsName=urn:x-ogc:def:crs:EPSG:4326

                                  GML3.1 output using urn:x-ogc:def:crs:EPSG:4326 reference and data in y/x order:

                                  <gml:MultiSurface srsName=\"urn:x-ogc:def:crs:EPSG:4326\">\n  <gml:surfaceMember>\n    <gml:Polygon>\n      <gml:exterior>\n        <gml:LinearRing>\n          <gml:posList>\n            37.51099 -88.071564 37.476273 -88.087883 \n
                                "},{"location":"services/wfs/axis_order/#wfs-10-output-format-gml32","title":"WFS 1.0 output format GML32","text":"
                                • GML3.2:

                                  http://localhost:8080/geoserver/topp/ows?service=WFS&version=1.0.0&request=GetFeature&typeName=topp%3Astates&featureId=states.1&outputFormat=gml32

                                  The GML32 output uses http://www.opengis.net/gml/srs/epsg.xml#4326 reference, with data in x/y order:

                                  <gml:MultiSurface srsName=\"http://www.opengis.net/gml/srs/epsg.xml#4326\" gml:id=\"states.1.the_geom\">\n  <gml:surfaceMember>\n    <gml:Polygon gml:id=\"states.1.the_geom.1\">\n      <gml:exterior>\n        <gml:LinearRing>\n          <gml:posList>-88.071564 37.51099 -88.087883 37.476273 \n
                                • GML3.2 reproject to EPSG:4326:

                                  http://localhost:8080/geoserver/topp/ows?service=WFS&version=1.0.0&request=GetFeature&typeName=topp%3Astates&featureId=states.1&outputFormat=gml32&srsName=EPSG:4326

                                  The GML32 output uses http://www.opengis.net/gml/srs/epsg.xml#4326 reference, with data in x/y order:

                                  <gml:MultiSurface srsName=\"http://www.opengis.net/gml/srs/epsg.xml#4326\" gml:id=\"states.1.the_geom\">\n  <gml:surfaceMember>\n    <gml:Polygon gml:id=\"states.1.the_geom.1\">\n      <gml:exterior>\n        <gml:LinearRing>\n          <gml:posList>\n            -88.071564 37.51099 -88.087883 37.476273\n
                                • GML3.2 reproject to urn:x-ogc:def:crs:EPSG:4326:

                                  http://localhost:8080/geoserver/topp/ows?service=WFS&version=1.0.0&request=GetFeature&typeName=topp%3Astates&featureId=states.1&outputFormat=gml32&srsName=urn:x-ogc:def:crs:EPSG:4326

                                  GML3.2 output using urn:x-ogc:def:crs:EPSG:4326 reference and data in y/x order:

                                  <gml:MultiSurface srsName=\"urn:ogc:def:crs:EPSG::4326\" gml:id=\"states.1.the_geom\">\n  <gml:surfaceMember>\n    <gml:Polygon gml:id=\"states.1.the_geom.1\">\n      <gml:exterior>\n        <gml:LinearRing><gml:posList>\n          37.51099 -88.071564 37.476273 -88.087883 \n
                                "},{"location":"services/wfs/axis_order/#wfs-11-axis-order","title":"WFS 1.1 Axis Order","text":"

                                GetCapabilities describes topp:states using:

                                http://localhost:8080/geoserver/ows?service=wfs&version=1.1.0&request=GetCapabilities

                                <FeatureType>\n  <Name>topp:states</Name>\n  <Title>USA Population</Title>\n  <Abstract>This is some census data on the states.</Abstract>\n  <ows:Keywords>\n    <ows:Keyword>census</ows:Keyword><ows:Keyword>united</ows:Keyword><ows:Keyword>boundaries</ows:Keyword><ows:Keyword>state</ows:Keyword><ows:Keyword>states</ows:Keyword>\n  </ows:Keywords>\n  <DefaultSRS>urn:x-ogc:def:crs:EPSG:4326</DefaultSRS>\n  <ows:WGS84BoundingBox>\n    <ows:LowerCorner>-124.731422 24.955967</ows:LowerCorner>\n    <ows:UpperCorner>-66.969849 49.371735</ows:UpperCorner>\n  </ows:WGS84BoundingBox></FeatureType>    \n

                                WFS 1.1 describes the WGS84BoundingBox as a lower and upper corner in x/y order.

                                Warning

                                This combination is inconsistent with DefaultSRS definition and the LowerCorner and UpperCorner coordinate order and may confuse client applications.

                                The result matches the WFS 1.1.0 Implementation Specification GetCapabilities examples.

                                WFS 1.1 GetFeature request defaults to GML3 output, and the default urn:x-ogc:def:crs:EPSG:4326 spatial reference system used to publish the layer:

                                • WFS 1.1 Default:

                                  http://localhost:8080/geoserver/ows?service=WFS&version=1.1.0&request=GetFeature&typeName=topp%3Astates&featureId=states.1

                                  The GML3.1 output uses urn:x-ogc:def:crs:EPSG:4326 reference, with data in y/x order:

                                  <gml:MultiSurface srsName=\"urn:x-ogc:def:crs:EPSG:4326\">\n  <gml:surfaceMember>\n    <gml:Polygon>\n      <gml:exterior>\n        <gml:LinearRing>\n          <gml:posList>\n             37.51099 -88.071564 37.476273 -88.087883  \n
                                • WFS 1.1 reproject to EPSG:4326:

                                  http://localhost:8080/geoserver/ows?service=WFS&version=1.1.0&request=GetFeature&typeName=topp%3Astates&featureId=states.1&srsName=EPSG:4326

                                  The GML3.1 output uses http://www.opengis.net/gml/srs/epsg.xml#4326 reference, with data in x/y order:

                                  <gml:MultiSurface srsName=\"http://www.opengis.net/gml/srs/epsg.xml#4326\">\n  <gml:surfaceMember>\n    <gml:Polygon>\n      <gml:exterior>\n        <gml:LinearRing>\n          <gml:posList>\n            -88.071564 37.51099 -88.087883 37.476273\n

                                  Note

                                  The srsName and posList coordinate order are consistent.

                                  This approach can be used to force x/y order.

                                • WFS 1.1 reproject to urn:x-ogc:def:crs:EPSG:4326:

                                  http://localhost:8080/geoserver/ows?service=WFS&version=1.1.0&request=GetFeature&typeName=topp%3Astates&featureId=states.1&srsName=urn:x-ogc:def:crs:EPSG:4326

                                  The GML3.1 output uses http://www.opengis.net/gml/srs/epsg.xml#4326 reference, with data in y/x order:

                                  <gml:MultiSurface srsName=\"http://www.opengis.net/gml/srs/epsg.xml#4326\">\n  <gml:surfaceMember>\n    <gml:Polygon>\n      <gml:exterior>\n        <gml:LinearRing>\n          <gml:posList>\n            37.51099 -88.071564 37.476273 -88.087883\n
                                "},{"location":"services/wfs/axis_order/#wfs-11-output-format-gml2","title":"WFS 1.1 output format GML2","text":"
                                • GML2:

                                  http://localhost:8080/geoserver/topp/ows?service=WFS&version=1.1.0&request=GetFeature&typeName=topp%3Astates&featureId=states.1&outputFormat=gml2

                                  GML2 output uses http://www.opengis.net/gml/srs/epsg.xml#4326 reference, with data in y/x order:

                                  <gml:MultiPolygon srsName=\"http://www.opengis.net/gml/srs/epsg.xml#4326\">\n  <gml:polygonMember>\n    <gml:Polygon><gml:outerBoundaryIs>\n      <gml:LinearRing>\n        <gml:coordinates decimal=\".\" cs=\",\" ts=\" \">\n          37.51099,-88.071564 37.476273,-88.087883\n
                                • GML2 reproject to EPSG:4326:

                                  http://localhost:8080/geoserver/topp/ows?service=WFS&version=1.1.0&request=GetFeature&typeName=topp%3Astates&featureId=states.1&outputFormat=gml2&srsName=EPSG:4326

                                  GML2 output uses http://www.opengis.net/gml/srs/epsg.xml#4326 reference, with data in x/y order:

                                  <gml:MultiPolygon srsName=\"http://www.opengis.net/gml/srs/epsg.xml#4326\">\n  <gml:polygonMember>\n    <gml:Polygon>\n      <gml:outerBoundaryIs>\n        <gml:LinearRing>\n          <gml:coordinates decimal=\".\" cs=\",\" ts=\" \">\n            -88.071564,37.51099 -88.087883,37.476273\n

                                  Note

                                  The srsName and posList coordinate order are consistent.

                                  This approach can be used to force x/y order.

                                "},{"location":"services/wfs/axis_order/#wfs-11-output-format-gml3","title":"WFS 1.1 output format GML3","text":"
                                • GML3:

                                  http://localhost:8080/geoserver/topp/ows?service=WFS&version=1.1.0&request=GetFeature&typeName=topp%3Astates&featureId=states.1&outputFormat=gml3

                                  GML3.1 output uses http://www.opengis.net/gml/srs/epsg.xml#4326 reference, with data in y/x order:

                                  <gml:MultiSurface srsName=\"http://www.opengis.net/gml/srs/epsg.xml#4326\">\n  <gml:surfaceMember>\n    <gml:Polygon>\n      <gml:exterior>\n        <gml:LinearRing>\n          <gml:posList>\n            37.51099 -88.071564 37.476273 -88.087883\n
                                • GML3 reproject to EPSG:4326:

                                  http://localhost:8080/geoserver/topp/ows?service=WFS&version=1.1.0&request=GetFeature&typeName=topp%3Astates&featureId=states.1&outputFormat=gml3&srsName=EPSG:4326

                                  GML3.1 output uses http://www.opengis.net/gml/srs/epsg.xml#4326 reference, but has changed the data to x/y order:

                                  <gml:MultiSurface srsName=\"http://www.opengis.net/gml/srs/epsg.xml#4326\">\n  <gml:surfaceMember>\n    <gml:Polygon>\n      <gml:exterior>\n        <gml:LinearRing>\n          <gml:posList>\n            -88.071564 37.51099 -88.087883 37.476273\n

                                  Note

                                  The srsName and posList coordinate order are consistent.

                                  This approach can be used to force x/y order.

                                • GML3 reproject to urn:x-ogc:def:crs:EPSG:4326

                                  http://localhost:8080/geoserver/topp/ows?service=WFS&version=1.1.0&request=GetFeature&typeName=topp%3Astates&featureId=states.1&outputFormat=gml3&srsName=urn:x-ogc:def:crs:EPSG:4326

                                  GML3.1 output using urn:x-ogc:def:crs:EPSG:4326 reference and data in y/x order:

                                  <gml:MultiSurface srsName=\"http://www.opengis.net/gml/srs/epsg.xml#4326\">\n  <gml:surfaceMember>\n    <gml:Polygon>\n      <gml:exterior>\n        <gml:LinearRing>\n          <gml:posList>\n            -88.071564 37.51099 -88.087883 37.476273\n

                                  Note

                                  The srsName and posList coordinate order are consistent.

                                  This approach can be used to force x/y order.

                                "},{"location":"services/wfs/axis_order/#wfs-11-output-format-gml32","title":"WFS 1.1 output format GML32","text":"
                                • GML3.2:

                                  http://localhost:8080/geoserver/topp/ows?service=WFS&version=1.1.0&request=GetFeature&typeName=topp%3Astates&featureId=states.1&outputFormat=gml32

                                  The GML32 output uses http://www.opengis.net/gml/srs/epsg.xml#4326 reference, with data in y/x order:

                                  <gml:MultiSurface srsName=\"urn:ogc:def:crs:EPSG::4326\" gml:id=\"states.1.the_geom\">\n  <gml:surfaceMember><gml:Polygon gml:id=\"states.1.the_geom.1\">\n    <gml:exterior>\n      <gml:LinearRing>\n        <gml:posList>37.51099 -88.071564 37.476273 -88.087883\n
                                • GML3.2 reproject to EPSG:4326:

                                  http://localhost:8080/geoserver/topp/ows?service=WFS&version=1.0.0&request=GetFeature&typeName=topp%3Astates&featureId=states.1&outputFormat=gml32&srsName=EPSG:4326

                                  The GML32 output uses http://www.opengis.net/gml/srs/epsg.xml#4326 reference, with data in x/y order:

                                  <gml:MultiSurface srsName=\"http://www.opengis.net/gml/srs/epsg.xml#4326\" gml:id=\"states.1.the_geom\">\n  <gml:surfaceMember>\n    <gml:Polygon gml:id=\"states.1.the_geom.1\">\n      <gml:exterior>\n        <gml:LinearRing>\n          <gml:posList>-88.071564 37.51099 -88.087883 37.476273\n
                                • GML3.2 reproject to urn:x-ogc:def:crs:EPSG:4326:

                                  http://localhost:8080/geoserver/topp/ows?service=WFS&version=1.0.0&request=GetFeature&typeName=topp%3Astates&featureId=states.1&outputFormat=gml32&srsName=urn:x-ogc:def:crs:EPSG:4326

                                  GML3.2 output using urn:x-ogc:def:crs:EPSG:4326 reference and data in y/x order:

                                  <gml:MultiSurface srsName=\"urn:ogc:def:crs:EPSG::4326\" gml:id=\"states.1.the_geom\">\n  <gml:surfaceMember>\n    <gml:Polygon gml:id=\"states.1.the_geom.1\">\n      <gml:exterior>\n        <gml:LinearRing><gml:posList>37.51099 -88.071564 37.476273 -88.087883 \n
                                "},{"location":"services/wfs/axis_order/#wfs-20-axis-order","title":"WFS 2.0 Axis Order","text":"

                                GetCapabilities describes topp:states using:

                                http://localhost:8080/geoserver/ows?service=wfs&version=2.0.0&request=GetCapabilities

                                <FeatureType>\n  <Name>topp:states</Name>\n  <Title>USA Population</Title>\n  <Abstract>This is some census data on the states.</Abstract>\n  <ows:Keywords>\n    <ows:Keyword>census</ows:Keyword><ows:Keyword>united</ows:Keyword><ows:Keyword>boundaries</ows:Keyword><ows:Keyword>state</ows:Keyword><ows:Keyword>states</ows:Keyword>\n  </ows:Keywords>\n  <DefaultCRS>urn:ogc:def:crs:EPSG::4326</DefaultCRS>\n  <ows:WGS84BoundingBox>\n    <ows:LowerCorner>-124.731422 24.955967</ows:LowerCorner>\n    <ows:UpperCorner>-66.969849 49.371735</ows:UpperCorner>\n  </ows:WGS84BoundingBox>\n</FeatureType>\n

                                WFS 2.0 describes the WGS84BoundingBox as a lower and upper corner in x/y order.

                                Warning

                                This combination is inconsistent with DefaultSRS definition and the LowerCorner and UpperCorner coordinate order and may confuse client applications.

                                The result matches the WFS 2.0 GetCapabilities examples.

                                WFS 2.0 GetFeature request defaults to GML3.2 output, and the default urn:ogc:def:crs:EPSG::4326 spatial reference system used to publish the layer:

                                • WFS 2.0 Default:

                                  http://localhost:8080/geoserver/ows?service=WFS&version=2.0.0&request=GetFeature&typeNames=topp%3Astates&featureId=states.1

                                  The GML3.2 output uses urn:ogc:def:crs:EPSG::4326 reference, with data in y/x order:

                                  <gml:MultiSurface srsName=\"urn:ogc:def:crs:EPSG::4326\" gml:id=\"states.1.the_geom\">\n  <gml:surfaceMember>\n    <gml:Polygon gml:id=\"states.1.the_geom.1\">\n      <gml:exterior><gml:LinearRing>\n        <gml:posList>\n          37.51099 -88.071564 37.476273 -88.087883  \n
                                • WFS 2.0 reproject to EPSG:4326:

                                  http://localhost:8080/geoserver/ows?service=WFS&version=2.0.0&request=GetFeature&typeNames=topp%3Astates&featureId=states.1&srsName=EPSG:4326

                                  The GML3.2 output uses http://www.opengis.net/gml/srs/epsg.xml#4326 reference, with data in x/y order:

                                  <gml:MultiSurface srsName=\"http://www.opengis.net/gml/srs/epsg.xml#4326\" gml:id=\"states.1.the_geom\">\n  <gml:surfaceMember>\n    <gml:Polygon gml:id=\"states.1.the_geom.1\">\n      <gml:exterior><gml:LinearRing>\n        <gml:posList>\n          -88.071564 37.51099 -88.087883 37.476273 \n
                                • WFS 2.0 reproject to urn:ogc:def:crs:EPSG::4326 http://localhost:8080/geoserver/ows?service=WFS&version=2.0.0&request=GetFeature&typeNames=topp%3Astates&featureId=states.1&srsName=urn:ogc:def:crs:EPSG::4326

                                  The GML3.2 output uses urn:ogc:def:crs:EPSG::4326 reference, with data in y/x order:

                                  <gml:MultiSurface srsName=\"urn:ogc:def:crs:EPSG::4326\" gml:id=\"states.1.the_geom\">\n  <gml:surfaceMember>\n    <gml:Polygon gml:id=\"states.1.the_geom.1\">\n      <gml:exterior><gml:LinearRing>\n        <gml:posList>\n          37.51099 -88.071564 37.476273 -88.087883 37.442852\n
                                "},{"location":"services/wfs/axis_order/#wfs-20-output-format-gml2","title":"WFS 2.0 output format GML2","text":"
                                • GML2:

                                  http://localhost:8080/geoserver/ows?service=WFS&version=2.0.0&request=GetFeature&typeNames=topp%3Astates&featureId=states.1&outputFormat=gml2

                                  <gml:MultiPolygon srsName=\"http://www.opengis.net/gml/srs/epsg.xml#4326\">\n  <gml:polygonMember>\n    <gml:Polygon>\n      <gml:outerBoundaryIs>\n        <gml:LinearRing>\n          <gml:coordinates decimal=\".\" cs=\",\" ts=\" \">\n            37.51099,-88.071564 37.476273,-88.087883 \n
                                • GML2 reproject to EPSG:4326:

                                  http://localhost:8080/geoserver/ows?service=WFS&version=2.0.0&request=GetFeature&typeNames=topp%3Astates&featureId=states.1&outputFormat=gml2&srsName=EPSG:4326

                                  <gml:MultiPolygon srsName=\"http://www.opengis.net/gml/srs/epsg.xml#4326\">\n  <gml:polygonMember>\n    <gml:Polygon>\n      <gml:outerBoundaryIs>\n        <gml:LinearRing>\n          <gml:coordinates decimal=\".\" cs=\",\" ts=\" \">\n            -88.071564,37.51099 -88.087883,37.476273\n

                                  Note

                                  The srsName and posList coordinate order are consistent.

                                  This approach can be used to force x/y order.

                                • GML2 reproject to urn:x-ogc:def:crs:EPSG:4326:

                                  http://localhost:8080/geoserver/ows?service=WFS&version=2.0.0&request=GetFeature&typeNames=topp%3Astates&featureId=states.1&outputFormat=gml2&srsName=urn:x-ogc:def:crs:EPSG:4326

                                  <gml:MultiPolygon srsName=\"http://www.opengis.net/gml/srs/epsg.xml#4326\">\n  <gml:polygonMember>\n    <gml:Polygon>\n      <gml:outerBoundaryIs>\n        <gml:LinearRing>\n          <gml:coordinates decimal=\".\" cs=\",\" ts=\" \">\n            37.51099,-88.071564 37.476273,-88.087883\n
                                "},{"location":"services/wfs/axis_order/#wfs-20-output-format-gml3","title":"WFS 2.0 output format GML3","text":"
                                • GML3:

                                  http://localhost:8080/geoserver/ows?service=WFS&version=2.0.0&request=GetFeature&typeNames=topp%3Astates&featureId=states.1&outputFormat=gml3

                                  <gml:MultiSurface srsName=\"urn:x-ogc:def:crs:EPSG:4326\">\n  <gml:surfaceMember>\n    <gml:Polygon>\n      <gml:exterior>\n        <gml:LinearRing>\n          <gml:posList>\n            37.51099 -88.071564 37.476273 -88.087883 \n
                                • GML3 reproject to EPSG:4326:

                                  http://localhost:8080/geoserver/ows?service=WFS&version=2.0.0&request=GetFeature&typeNames=topp%3Astates&featureId=states.1&outputFormat=gml3&srsName=EPSG:4326

                                  <gml:MultiSurface srsName=\"urn:x-ogc:def:crs:EPSG:4326\">\n  <gml:surfaceMember>\n    <gml:Polygon>\n      <gml:exterior>\n        <gml:LinearRing>\n          <gml:posList>\n            -88.071564 37.51099 -88.087883 37.476273\n

                                  Warning

                                  This combination is inconsistent between srsName and posList coordinate order and may confuse applications expecting a valid GML3 document.

                                  This approach can be used to force x/y order.

                                • GML3 reproject to urn:x-ogc:def:crs:EPSG:4326:

                                  http://localhost:8080/geoserver/ows?service=WFS&version=2.0.0&request=GetFeature&typeNames=topp%3Astates&featureId=states.1&outputFormat=gml3&srsName=urn:x-ogc:def:crs:EPSG:4326

                                  <gml:MultiSurface srsName=\"urn:x-ogc:def:crs:EPSG:4326\">\n  <gml:surfaceMember>\n    <gml:Polygon>\n      <gml:exterior>\n        <gml:LinearRing>\n          <gml:posList>\n            37.51099 -88.071564 37.476273 -88.087883\n
                                "},{"location":"services/wfs/axis_order/#wfs-20-output-format-gml32","title":"WFS 2.0 output format GML32","text":"
                                • GML32:

                                  http://localhost:8080/geoserver/ows?service=WFS&version=2.0.0&request=GetFeature&typeNames=topp%3Astates&featureId=states.1&outputFormat=gml32

                                  <gml:MultiSurface srsName=\"urn:ogc:def:crs:EPSG::4326\" gml:id=\"states.1.the_geom\">\n  <gml:surfaceMember>\n    <gml:Polygon gml:id=\"states.1.the_geom.1\"><gml:exterior>\n      <gml:LinearRing>\n        <gml:posList>\n          37.51099 -88.071564 37.476273 -88.087883 \n
                                • GML32 reproject to EPSG:4326:

                                  http://localhost:8080/geoserver/ows?service=WFS&version=2.0.0&request=GetFeature&typeNames=topp%3Astates&featureId=states.1&outputFormat=gml32&srsName=EPSG:4326

                                  <gml:MultiSurface srsName=\"urn:ogc:def:crs:EPSG::4326\" gml:id=\"states.1.the_geom\">\n  <gml:surfaceMember>\n    <gml:Polygon gml:id=\"states.1.the_geom.1\"><gml:exterior>\n      <gml:LinearRing>\n        <gml:posList>\n          -88.071564 37.51099 -88.087883 37.476273\n

                                  Warning

                                  This combination is inconsistent between srsName and posList coordinate order and may confuse applications expecting a valid GML3 document.

                                  This approach can be used to force x/y order.

                                • GML32 reproject to urn:x-ogc:def:crs:EPSG:4326:

                                  http://localhost:8080/geoserver/ows?service=WFS&version=2.0.0&request=GetFeature&typeNames=topp%3Astates&featureId=states.1&outputFormat=gml32&srsName=urn:x-ogc:def:crs:EPSG:4326

                                  <gml:MultiSurface srsName=\"urn:ogc:def:crs:EPSG::4326\" gml:id=\"states.1.the_geom\">\n  <gml:surfaceMember>\n    <gml:Polygon gml:id=\"states.1.the_geom.1\"><gml:exterior>\n      <gml:LinearRing>\n        <gml:posList>\n          37.51099 -88.071564 37.476273 -88.087883\n
                                "},{"location":"services/wfs/basics/","title":"WFS basics","text":"

                                GeoServer provides support for the Open Geospatial Consortium (OGC) Web Feature Service (WFS) specification, versions 1.0.0, 1.1.0, and 2.0.0. WFS defines a standard for exchanging vector data over the Internet. With a compliant WFS, clients can query both the data structure and the source data. Advanced WFS operations also support feature locking and edit operations.

                                GeoServer is the reference implementation of all three versions of the standard, completely implementing every part of the protocol. This includes the basic operations of GetCapabilities, DescribeFeatureType, and GetFeature, as well as more advanced options such as Transaction. GeoServer WFS is also integrated with its Security system to limit access to data and transactions, and supports a variety of WFS output formats, making the raw data more widely available.

                                "},{"location":"services/wfs/basics/#differences-between-wfs-versions","title":"Differences between WFS versions","text":"

                                The major differences between the WFS versions are:

                                • WFS 1.1.0 and 2.0.0 return GML3 as the default GML, whereas in WFS 1.0.0, the default is GML2. GML3 adopts marginally different ways of specifying a geometry. GeoServer supports requests in both GML3 and GML2 formats.
                                • In WFS 1.1.0 and 2.0.0, the SRS (Spatial Reference System, or projection) is specified with urn:x-ogc:def:crs:EPSG:XXXX, whereas in WFS 1.0.0 the specification was http://www.opengis.net/gml/srs/epsg.xml#XXXX. This change has implications for the axis order of the returned data.
                                • WFS 1.1.0 and 2.0.0 support on-the-fly reprojection of data, which supports returning the data in a SRS other than the native SRS.
                                • WFS 2.0.0 introduces a new version of the filter encoding specification, adding support for temporal filters.
                                • WFS 2.0.0 supports joins via a GetFeature request.
                                • WFS 2.0.0 adds the ability to page results of a GetFeature request via the startIndex and count parameters. GeoServer now supports this functionality in WFS 1.0.0 and 1.1.0.
                                • WFS 2.0.0 supports stored queries, which are regular WFS queries stored on the server such that they may be invoked by passing the appropriate identifier with a WFS request.
                                • WFS 2.0.0 supports SOAP (Simple Object Access Protocol) as an alternative to the OGC interface.

                                Note

                                There are also two changes to parameter names which can cause confusion. WFS 2.0.0 uses the count parameter to limit the number of features returned rather than the maxFeatures parameter used in previous versions. It also changed typeName to typeNames although GeoServer will accept either.

                                "},{"location":"services/wfs/outputformats/","title":"WFS output formats","text":"

                                WFS returns features and feature information in a number of formats. The syntax for specifying an output format is:

                                outputFormat=<format>\n

                                where <format> is one of the following options:

                                Format Syntax Notes

                                GML2 outputFormat=GML2 Default option for WFS 1.0.0

                                GML3 outputFormat=GML3 Default option for WFS 1.1.0 and 2.0.0

                                Shapefile outputFormat=shape-zip ZIP archive will be generated containing the shapefile (see Shapefile output below).

                                JSON outputFormat=application/json Returns a GeoJSON or a JSON output. Note outputFormat=json is only supported for getFeature (for backward compatibility).

                                JSONP outputFormat=text/javascript Returns a JSONP in the form: parseResponse(...json...). See WMS vendor parameters to change the callback name. Note that this format is disabled by default (See Global variables affecting WMS).

                                CSV outputFormat=csv Returns a CSV (comma-separated values) file

                                Note

                                Some additional output formats (such as Excel) are available with the use of an extension. The full list of output formats supported by a particular GeoServer instance can be found by performing a WFS GetCapabilities request.

                                GeoServer provides the format_options vendor-specific parameter to specify parameters that are specific to each format. The syntax is:

                                format_options=param1:value1;param2:value2;...\n
                                "},{"location":"services/wfs/outputformats/#wfs_outputformat_shapezip","title":"Shapefile output","text":"

                                The shapefile format has a number of limitations that would prevent turning data sources into an equivalent shapefile. In order to abide with such limitations the shape-zip output format will automatically apply some transformations on the source data, and eventually split the single collection into multiple shapefiles. In particular, the shape-zip format will:

                                • Reduce attribute names to the DBF accepted length, making sure there are not conflicts (counters being added at the end of the attribute name to handle this).
                                • Fan out multiple geometry type into parallel shapefiles, named after the original feature type, plus the geometry type as a suffix.
                                • Fan out multiple shapefiles in case the maximum size is reached

                                The default max size for both .shp and .dbf file is 2GB, it's possible to modify those limits by setting the GS_SHP_MAX_SIZE and GS_DBF_MAX_SIZE system variables to a different value (as a byte count, the default value being 2147483647).

                                Shapefile output format_options:

                                • format_option=filename:<zipfile>: if a file name is provided, the name is used as the output file name. For example, format_options=filename:roads.zip.
                                "},{"location":"services/wfs/outputformats/#shapefile-filename-customization","title":"Shapefile filename customization","text":"

                                If a file name is not specified, the output file name is inferred from the requested feature type name. The shapefile output format output can be customized by preparing a Freemarker template which will configure the file name of the archive (ZIP file) and the files it contains. The default template is:

                                zip=${typename}\nshp=${typename}${geometryName}${geometryType}\ntxt=wfsrequest\n

                                The zip property is the name of the archive, the shp property is the name of the shapefile for a given feature type, and txt is the dump of the actual WFS request.

                                The properties available in the template are:

                                • typename---Feature type name (for the zip property this will be the first feature type if the request contains many feature types)
                                • geometryName---Name of the geometry attribute. Used only if the original feature type has more than one geometry attribute.
                                • geometryType---Type of geometry contained in the shapefile. This is only used if the output geometry type is generic and the various geometries are stored in one shapefile per type.
                                • workspace---Workspace of the feature type
                                • timestamp---Date object with the request timestamp
                                • iso_timestamp---String (ISO timestamp of the request at GMT) in yyyyMMdd_HHmmss format
                                "},{"location":"services/wfs/outputformats/#json-and-jsonp-output","title":"JSON and JSONP output","text":"

                                The JSON output format (and JSONP if enabled) return feature content as a GeoJSON document. Here is an example of a simple GeoJSON file;

                                {  \"type\": \"Feature\",\n   \"geometry\": {\n      \"type\": \"Point\",\n      \"coordinates\": [125.6, 10.1]\n   },\n   \"properties\": {\n      \"name\": \"Dinagat Islands\"\n   }\n}\n

                                The output properties can include the use of lists and maps:

                                {\n  \"type\": \"Feature\",\n  \"id\": \"example.3\",\n  \"geometry\": {\n    \"type\": \"POINT\",\n    \"coordinates\": [ -75.70742, 38.557476 ],\n  },\n  \"geometry_name\": \"geom\",\n  \"properties\": {\n    \"CONDITION\": \"Orange\",\n    \"RANGE\": {\"min\":\"37\",\"max\":\"93\"}\n  }\n}\n

                                JSON output format_options:

                                • format_options=id_policy:<attribute name>=<attribute|true|false> is used to determine if the id values are included in the output.

                                  Use format_options=id_policy:reference_no for feature id generation using the reference_no attribute, or format_options=id_policy:reference_no=true for default feature id generation, or format_options=id_policy:reference_no=false to suppress feature id output.

                                  If id_policy is not specified the geotools default feature id generation is used.

                                • format_options=callback:<parseResponse> applies only to the JSONP output format. See WMS vendor parameters to change the callback name. Note that this format is disabled by default (See Global variables affecting WMS).

                                • format_option=filename:<file>: if a file name is provided, the name is used as the output file name. The extension json is optional, for example format_options=filename:export or format_options=features.json

                                JSON output system properties:

                                • json.maxDepth=<max_value> is used to determine the max number of allowed JSON nested objects on encoding phase. By default the value is 100.

                                Note

                                Coordinates with a value equal to $\\pm \\infty$ will be encoded with their string representation \"Infinity\" or \"-Infinity\"

                                "},{"location":"services/wfs/outputformats/#csv-output","title":"CSV output","text":"

                                A Default CSV file uses a comma to separate values. Each line of the file is a data record. Each record consists of one or more fields, separated by commas. The separator can be changed using format_options as specified below.

                                csv file output format_options:

                                • format_option=filename:<file>: if a file name is provided, the name is used as the output file name. For example, format_options=filename:roads.csv.
                                • format_option=csvseparator:<csvseparator> (default is `, ```` ): if a separator is provided, it is used to separate values in output csv file. For example, ````format_options=csvseparator:-` is used to get dash separated file.

                                Some special characters need to be handled using keywords as below:

                                • space separated: format_options=csvseparator:space
                                • tab separated: format_options=csvseparator:tab
                                • semicolon separated: format_options=csvseparator:semicolon
                                "},{"location":"services/wfs/reference/","title":"WFS reference","text":"

                                The Web Feature Service (WFS) is a standard created by the Open Geospatial Consortium (OGC) for creating, modifying and exchanging vector format geographic information on the Internet using HTTP. A WFS encodes and transfers information in Geography Markup Language (GML), a subset of XML.

                                The current version of WFS is 2.0.0. GeoServer supports versions 2.0.0, 1.1.0, and 1.0.0. Although there are some important differences between the versions, the request syntax often remains the same.

                                A related OGC specification, the Web Map Service (WMS), defines the standard for exchanging geographic information in digital image format.

                                "},{"location":"services/wfs/reference/#benefits-of-wfs","title":"Benefits of WFS","text":"

                                The WFS standard defines the framework for providing access to, and supporting transactions on, discrete geographic features in a manner that is independent of the underlying data source. Through a combination of discovery, query, locking, and transaction operations, users have access to the source spatial and attribute data in a manner that allows them to interrogate, style, edit (create, update, and delete), and download individual features. The transactional capabilities of WFS also support the development and deployment of collaborative mapping applications.

                                "},{"location":"services/wfs/reference/#operations","title":"Operations","text":"

                                All versions of WFS support these operations:

                                Operation Description

                                GetCapabilities Generates a metadata document describing a WFS service provided by server as well as valid WFS operations and parameters

                                DescribeFeatureType Returns a description of feature types supported by a WFS service

                                GetFeature Returns a selection of features from a data source including geometry and attribute values

                                LockFeature Prevents a feature from being edited through a persistent feature lock

                                Transaction Edits existing feature types by creating, updating, and deleting

                                The following operations are available in version 2.0.0 only:

                                Operation Description

                                GetPropertyValue Retrieves the value of a feature property or part of the value of a complex feature property from the data store for a set of features identified using a query expression

                                GetFeatureWithLock Returns a selection of features and also applies a lock on those features

                                CreateStoredQuery Create a stored query on the WFS server

                                DropStoredQuery Deletes a stored query from the WFS server

                                ListStoredQueries Returns a list of the stored queries on a WFS server

                                DescribeStoredQueries Returns a metadata document describing the stored queries on a WFS server

                                The following operations are available in version 1.1.0 only:

                                Operation Description

                                GetGMLObject Retrieves features and elements by ID from a WFS

                                Note

                                In the examples that follow, the fictional URL http://example.com/geoserver/wfs is used for illustration. To test the examples, substitute the address of a valid WFS. Also, although the request would normally be defined on one line with no breaks, breaks are added for clarity in the examples provided.

                                "},{"location":"services/wfs/reference/#wfs_getcap","title":"GetCapabilities","text":"

                                The GetCapabilities operation is a request to a WFS server for a list of the operations and services, or capabilities, supported by that server.

                                To issue a GET request using HTTP:

                                http://example.com/geoserver/wfs?\n  service=wfs&\n  version=1.1.0&\n  request=GetCapabilities\n

                                The equivalent request using POST:

                                <GetCapabilities\n service=\"WFS\"\n xmlns=\"http://www.opengis.net/wfs\"\n xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\"\n xsi:schemaLocation=\"http://www.opengis.net/wfs          \n http://schemas.opengis.net/wfs/1.1.0/wfs.xsd\"/>\n

                                GET requests are simplest to decode, but the POST requests are equivalent.

                                The parameters for GetCapabilities are:

                                Parameter Required? Description

                                service Yes Service name---Value is WFS

                                version Yes Service version---Value is the current version number. The full version number must be supplied (\"1.1.0\", \"1.0.0\"), not the abbreviated form (\"1\" or \"1.1\").

                                request Yes Operation name---Value is GetCapabilities

                                Although all of the above parameters are technically required as per the specification, GeoServer will provide default values if any parameters are omitted from a request.

                                The GetCapabilities response is a lengthy XML document, the format of which is different for each of the supported versions. There are five main components in a GetCapabilities document:

                                Component Description

                                ServiceIdentification Contains basic header information for the request such as the Title and ServiceType. The ServiceType indicates which version(s) of WFS are supported.

                                ServiceProvider Provides contact information about the company publishing the WFS service, including telephone, website, and email.

                                OperationsMetadata Describes the operations that the WFS server supports and the parameters for each operation. A WFS server may be configured not to respond to the operations listed above.

                                FeatureTypeList Lists the feature types published by a WFS server. Feature types are listed in the form namespace:featuretype. The default projection of the feature type is also listed, along with the bounding box for the data in the stated projection.

                                Filter_Capabilities Lists the filters, or expressions, that are available to form query predicates, for example, SpatialOperators (such as Equals, Touches) and ComparisonOperators (such as LessThan, GreaterThan). The filters themselves are not included in the GetCapabilities document.

                                "},{"location":"services/wfs/reference/#wfs_dft","title":"DescribeFeatureType","text":"

                                DescribeFeatureType requests information about an individual feature type before requesting the actual data. Specifically, the operation will request a list of features and attributes for the given feature type, or list the feature types available.

                                The parameters for DescribeFeatureType are:

                                Parameter Required? Description

                                service Yes Service name---Value is WFS

                                version Yes Service version---Value is the current version number

                                request Yes Operation name---Value is DescribeFeatureType

                                typeNames Yes Name of the feature type to describe (typeName for WFS 1.1.0 and earlier)

                                exceptions No Format for reporting exceptions---default value is application/vnd.ogc.se_xml

                                outputFormat No Defines the scheme description language used to describe feature types

                                To return a list of feature types, the GET request would be as follows. This request will return the list of feature types, sorted by namespace:

                                http://example.com/geoserver/wfs?\n  service=wfs&\n  version=2.0.0&\n  request=DescribeFeatureType\n

                                To list information about a specific feature type called namespace:featuretype, the GET request would be:

                                http://example.com/geoserver/wfs?\n  service=wfs&\n  version=2.0.0&\n  request=DescribeFeatureType&\n  typeNames=namespace:featuretype\n
                                "},{"location":"services/wfs/reference/#wfs_getfeature","title":"GetFeature","text":"

                                The GetFeature operation returns a selection of features from the data source.

                                This request will execute a GetFeature request for a given layer namespace:featuretype:

                                http://example.com/geoserver/wfs?\n  service=wfs&\n  version=2.0.0&\n  request=GetFeature&\n  typeNames=namespace:featuretype\n

                                Executing this command will return the geometries for all features in given a feature type, potentially a large amount of data. To limit the output, you can restrict the GetFeature request to a single feature by including an additional parameter, featureID and providing the ID of a specific feature. In this case, the GET request would be:

                                http://example.com/geoserver/wfs?\n  service=wfs&\n  version=2.0.0&\n  request=GetFeature&\n  typeNames=namespace:featuretype&\n  featureID=feature\n

                                If the ID of the feature is unknown but you still want to limit the number of features returned, use the count parameter for WFS 2.0.0 or the maxFeatures parameter for earlier WFS versions. In the examples below, N represents the number of features to return:

                                http://example.com/geoserver/wfs?\n  service=wfs&\n  version=2.0.0&\n  request=GetFeature&\n  typeNames=namespace:featuretype&\n  count=N\n\nhttp://example.com/geoserver/wfs?\n  service=wfs&\n  version=1.1.0&\n  request=GetFeature&\n  typeName=namespace:featuretype&\n  maxFeatures=N\n

                                Exactly which N features will be returned depends in the internal structure of the data. However, you can sort the returned selection based on an attribute value. In the following example, an attribute is included in the request using the sortBy=attribute parameter (replace attribute with the attribute you wish to sort by):

                                http://example.com/geoserver/wfs?\n   service=wfs&\n   version=2.0.0&\n   request=GetFeature&\n   typeNames=namespace:featuretype&\n   count=N&\n   sortBy=attribute\n

                                The default sort operation is to sort in ascending order. Some WFS servers require the sort order to be specified, even if an ascending order sort if required. In this case, append a +A to the request. Conversely, add a +D to the request to sort in descending order as follows:

                                http://example.com/geoserver/wfs?\n  service=wfs&\n  version=2.0.0&\n  request=GetFeature&\n  typeNames=namespace:featuretype&\n  count=N&\n  sortBy=attribute+D\n

                                There is no obligation to use sortBy with count in a GetFeature request, but they can be used together to manage the returned selection of features more effectively.

                                To restrict a GetFeature request by attribute rather than feature, use the propertyName key in the form propertyName=attribute. You can specify a single attribute, or multiple attributes separated by commas. To search for a single attribute in all features, the following request would be required:

                                http://example.com/geoserver/wfs?\n  service=wfs&\n  version=2.0.0&\n  request=GetFeature&\n  typeNames=namespace:featuretype&\n  propertyName=attribute\n

                                For a single property from just one feature, use both featureID and propertyName:

                                http://example.com/geoserver/wfs?\n  service=wfs&\n  version=2.0.0&\n  request=GetFeature&\n  typeNames=namespace:featuretype&\n  featureID=feature&\n  propertyName=attribute\n

                                For more than one property from a single feature, use a comma-separated list of values for propertyName:

                                http://example.com/geoserver/wfs?\n  service=wfs&\n  version=2.0.0&\n  request=GetFeature&\n  typeNames=namespace:featuretype&\n  featureID=feature&\n  propertyName=attribute1,attribute2\n

                                While the above permutations for a GetFeature request focused on non-spatial parameters, it is also possible to query for features based on geometry. While there are limited options available in a GET request for spatial queries (more are available in POST requests using filters), filtering by bounding box (BBOX) is supported.

                                The BBOX parameter allows you to search for features that are contained (or partially contained) inside a box of user-defined coordinates. The format of the BBOX parameter is bbox=a1,b1,a2,b2,[crs] where a1, b1, a2, and b2 represent the coordinate values. The optional crs parameter is used to name the CRS for the bbox coordinates (if they are different to the featureTypes native CRS.) The order of coordinates passed to the BBOX parameter depends on the coordinate system used (this is why the coordinate syntax isn't represented with x or y.)

                                To specify the coordinate system for the returned features, append srsName=CRS to the WFS request, where CRS is the Coordinate Reference System you wish to use.

                                As for which corners of the bounding box to specify, the only requirement is for a bottom corner (left or right) to be provided first. For example, bottom left and top right, or bottom right and top left.

                                An example request returning features based on a bounding box (using the featureTypes native CRS):

                                http://example.com/geoserver/wfs?\n  service=wfs&\n  version=2.0.0&\n  request=GetFeature&\n  typeNames=namespace:featuretype&\n  srsName=CRS&\n  bbox=a1,b1,a2,b2\n

                                To request features using a bounding box with CRS different from featureTypes native CRS:

                                http://example.com/geoserver/wfs?\n  service=wfs&\n  version=2.0.0&\n  request=GetFeature&\n  typeNames=namespace:featuretype&\n  srsName=CRS&\n  bbox=a1,b1,a2,b2,CRS\n
                                "},{"location":"services/wfs/reference/#lockfeature","title":"LockFeature","text":"

                                A LockFeature operation provides a long-term feature locking mechanism to ensure consistency in edit transactions. If one client fetches a feature and makes some changes before submitting it back to the WFS, locks prevent other clients from making any changes to the same feature, ensuring a transaction that can be serialized. If a WFS server supports this operation, it will be reported in the server's GetCapabilities response.

                                In practice, few clients support this operation.

                                "},{"location":"services/wfs/reference/#wfs_wfst","title":"Transaction","text":"

                                The Transaction operation can create, modify, and delete features published by a WFS. Each transaction will consist of zero or more Insert, Update, and Delete elements, with each transaction element performed in order. Every GeoServer transaction is atomic, meaning that if any of the elements fail, the transaction is abandoned, and the data is unaltered. A WFS server that supports transactions is sometimes known as a WFS-T server. GeoServer fully supports transactions.

                                More information on the syntax of transactions can be found in the WFS specification and in the GeoServer sample requests.

                                "},{"location":"services/wfs/reference/#getgmlobject","title":"GetGMLObject","text":"

                                Note

                                This operation is valid for WFS version 1.1.0 only.

                                A GetGMLObject operation accepts the identifier of a GML object (feature or geometry) and returns that object. This operation is relevant only in situations that require app-schema.complex-features by allowing clients to extract just a portion of the nested properties of a complex feature. As a result, this operation is not widely used by client applications.

                                "},{"location":"services/wfs/reference/#getpropertyvalue","title":"GetPropertyValue","text":"

                                Note

                                This operation is valid for WFS version 2.0.0 only.

                                A GetPropertyValue operation retrieves the value of a feature property, or part of the value of a complex feature property, from a data source for a given set of features identified by a query.

                                This example retrieves the geographic content only of the features in the topp:states layer:

                                http://example.com/geoserver/wfs?\n  service=wfs&\n  version=2.0.0&\n  request=GetPropertyValue&\n  typeNames=topp:states&\n  valueReference=the_geom\n

                                The same example in a POST request:

                                <wfs:GetPropertyValue service='WFS' version='2.0.0'\n xmlns:topp='http://www.openplans.org/topp'\n xmlns:fes='http://www.opengis.net/fes/2.0'\n xmlns:wfs='http://www.opengis.net/wfs/2.0'\n valueReference='the_geom'>\n  <wfs:Query typeNames='topp:states'/>\n</wfs:GetPropertyValue>\n

                                To retrieve value for a different attribute, alter the valueReference parameter.

                                "},{"location":"services/wfs/reference/#getfeaturewithlock","title":"GetFeatureWithLock","text":"

                                Note

                                This operation is valid for WFS version 2.0.0 only.

                                A GetFeatureWithLock operation is similar to a GetFeature operation, except that when the set of features are returned from the WFS server, the features are also locked in anticipation of a subsequent transaction operation.

                                This POST example retrieves the features of the topp:states layer, but in addition locks those features for five minutes.

                                <wfs:GetFeatureWithLock service='WFS' version='2.0.0'\n handle='GetFeatureWithLock-tc1' expiry='5' resultType='results'\n xmlns:topp='http://www.openplans.org/topp'\n xmlns:fes='http://www.opengis.net/fes/2.0'\n xmlns:wfs='http://www.opengis.net/wfs/2.0'\n valueReference='the_geom'>\n  <wfs:Query typeNames='topp:states'/>\n</wfs:GetFeatureWithLock>\n

                                To adjust the lock time, alter the expiry parameter.

                                "},{"location":"services/wfs/reference/#createstoredquery","title":"CreateStoredQuery","text":"

                                Note

                                This operation is valid for WFS version 2.0.0 only.

                                A CreateStoredQuery operation creates a stored query on the WFS server. The definition of the stored query is encoded in the StoredQueryDefinition parameter and is given an ID for a reference.

                                This POST example creates a new stored query (called \"myStoredQuery\") that filters the topp:states layer to those features that are within a given area of interest (${AreaOfInterest}):

                                <wfs:CreateStoredQuery service='WFS' version='2.0.0'\n xmlns:wfs='http://www.opengis.net/wfs/2.0'\n xmlns:fes='http://www.opengis.org/fes/2.0'\n xmlns:gml='http://www.opengis.net/gml/3.2'\n xmlns:myns='http://www.someserver.com/myns'\n xmlns:topp='http://www.openplans.org/topp'>\n  <wfs:StoredQueryDefinition id='myStoredQuery'>\n    <wfs:Parameter name='AreaOfInterest' type='gml:Polygon'/>\n    <wfs:QueryExpressionText\n     returnFeatureTypes='topp:states'\n     language='urn:ogc:def:queryLanguage:OGC-WFS::WFS_QueryExpression'\n     isPrivate='false'>\n      <wfs:Query typeNames='topp:states'>\n        <fes:Filter>\n          <fes:Within>\n            <fes:ValueReference>the_geom</fes:ValueReference>\n             ${AreaOfInterest}\n          </fes:Within>\n        </fes:Filter>\n      </wfs:Query>\n    </wfs:QueryExpressionText>\n  </wfs:StoredQueryDefinition>\n</wfs:CreateStoredQuery>\n
                                "},{"location":"services/wfs/reference/#dropstoredquery","title":"DropStoredQuery","text":"

                                Note

                                This operation is valid for WFS version 2.0.0 only.

                                A DropStoredQuery operation drops a stored query previous created by a CreateStoredQuery operation. The request accepts the ID of the query to drop.

                                This example will drop a stored query with an ID of myStoredQuery:

                                http://example.com/geoserver/wfs?\n  request=DropStoredQuery&\n  storedQuery_Id=myStoredQuery\n

                                The same example in a POST request:

                                <wfs:DropStoredQuery\n xmlns:wfs='http://www.opengis.net/wfs/2.0'\n service='WFS' id='myStoredQuery'/>\n
                                "},{"location":"services/wfs/reference/#liststoredqueries","title":"ListStoredQueries","text":"

                                Note

                                This operation is valid for WFS version 2.0.0 only.

                                A ListStoredQueries operation returns a list of the stored queries currently maintained by the WFS server.

                                This example lists all stored queries on the server:

                                http://example.com/geoserver/wfs?\n  request=ListStoredQueries&\n  service=wfs&\n  version=2.0.0\n

                                The same example in a POST request:

                                <wfs:ListStoredQueries service='WFS'\n version='2.0.0'\n xmlns:wfs='http://www.opengis.net/wfs/2.0'/>\n
                                "},{"location":"services/wfs/reference/#describestoredqueries","title":"DescribeStoredQueries","text":"

                                Note

                                This operation is valid for WFS version 2.0.0 only.

                                A DescribeStoredQuery operation returns detailed metadata about each stored query maintained by the WFS server. A description of an individual query may be requested by providing the ID of the specific query. If no ID is provided, all queries are described.

                                This example describes the existing stored query with an ID of urn:ogc:def:query:OGC-WFS::GetFeatureById:

                                http://example.com/geoserver/wfs?\n  request=DescribeStoredQueries&\n  storedQuery_Id=urn:ogc:def:query:OGC-WFS::GetFeatureById\n

                                The same example in a POST request:

                                <wfs:DescribeStoredQueries\n xmlns:wfs='http://www.opengis.net/wfs/2.0'\n service='WFS'>\n  <wfs:StoredQueryId>urn:ogc:def:query:OGC-WFS::GetFeatureById</wfs:StoredQueryId>\n</wfs:DescribeStoredQueries>\n
                                "},{"location":"services/wfs/reference/#exceptions","title":"Exceptions","text":"

                                WFS also supports a number of formats for reporting exceptions. The supported values for exception reporting are:

                                Format Syntax Description

                                XML exceptions=text/xml (default) XML output

                                JSON exceptions=application/json Simple JSON

                                JSONP exceptions=text/javascript Return a JSONP in the form: parseResponse(...jsonp...). See WMS vendor parameters to change the callback name. Note that this format is disabled by default (See Global variables affecting WMS).

                                "},{"location":"services/wfs/schemamapping/","title":"WFS schema mapping","text":"

                                One of the functions of the GeoServer WFS is to automatically map the internal schema of a dataset to a feature type schema. This mapping is performed according to the following rules:

                                • The name of the feature element maps to the name of the dataset.
                                • The name of the feature type maps to the name of the dataset with the string \"Type\" appended to it.
                                • The name of each attribute of the dataset maps to the name of an element particle contained in the feature type.
                                • The type of each attribute of the dataset maps to the appropriate XML schema type (xsd:int, xsd:double, and so on).

                                For example, a dataset has the following schema:

                                myDataset(intProperty:Integer, stringProperty:String, floatProperty:Float, geometry:Point)\n

                                This schema would be mapped to the following XML schema, available via a DescribeFeatureType request for the topp:myDataset type:

                                <xsd:schema xmlns:xsd=\"http://www.w3.org/2001/XMLSchema\"\n xmlns:gml=\"http://www.opengis.net/gml\"\n xmlns:topp=\"http://www.openplans.org/topp\" \n targetNamespace=\"http://www.openplans.org/topp\"\n elementFormDefault=\"qualified\">\n\n  <xsd:import namespace=\"http://www.opengis.net/gml\"\n   schemaLocation=\"http://localhost:8080/geoserver/schemas/gml/3.1.1/base/gml.xsd\"/>\n\n  <xsd:complexType name=\"myDatasetType\">\n    <xsd:complexContent>\n      <xsd:extension base=\"gml:AbstractFeatureType\">\n        <xsd:sequence>\n          <xsd:element maxOccurs=\"1\" minOccurs=\"0\" name=\"intProperty\" nillable=\"true\" type=\"xsd:int\"/>\n          <xsd:element maxOccurs=\"1\" minOccurs=\"0\" name=\"stringProperty\" nillable=\"true\" type=\"xsd:string\"/>\n          <xsd:element maxOccurs=\"1\" minOccurs=\"0\" name=\"floatProperty\" nillable=\"true\" type=\"xsd:double\"/>\n          <xsd:element maxOccurs=\"1\" minOccurs=\"0\" name=\"geometry\" nillable=\"true\" type=\"gml:PointPropertyType\"/>\n        </xsd:sequence>\n      </xsd:extension>\n    </xsd:complexContent>\n  </xsd:complexType>\n\n  <xsd:element name=\"myDataset\" substitutionGroup=\"gml:_Feature\" type=\"topp:myDatasetType\"/>\n\n</xsd:schema>\n
                                "},{"location":"services/wfs/schemamapping/#schema-customization","title":"Schema customization","text":"

                                The GeoServer WFS supports a limited amount of schema output customization. A custom schema may be useful for the following:

                                • Limiting the attributes which are exposed in the feature type schema
                                • Changing the types of attributes in the schema
                                • Changing the structure of the schema (for example, changing the base feature type)

                                For example, it may be useful to limit the exposed attributes in the example dataset described above. Start by retrieving the default output as a benchmark of the complete schema. With the feature type schema listed above, the GetFeature request would be as follows:

                                <topp:myDataset gml:id=\"myDataset.1\">\n <topp:intProperty>1</topp:intProperty>\n  <topp:stringProperty>one</topp:stringProperty>\n  <topp:floatProperty>1.1</topp:floatProperty>\n  <topp:geometry>\n    <gml:Point srsName=\"urn:x-ogc:def:crs:EPSG:4326\">\n      <gml:pos>1.0 1.0</gml:pos>\n    </gml:Point>\n  </topp:geometry>\n</topp:myDataset>\n

                                To remove floatProperty from the list of attributes, the following steps would be required:

                                1. The original schema is modified to remove the floatProperty, resulting in the following type definition:

                                  <xsd:complexType name=\"myDatasetType\">\n  <xsd:complexContent>\n    <xsd:extension base=\"gml:AbstractFeatureType\">\n      <xsd:sequence>\n        <xsd:element maxOccurs=\"1\" minOccurs=\"0\" name=\"intProperty\" nillable=\"true\" type=\"xsd:int\"/>\n        <xsd:element maxOccurs=\"1\" minOccurs=\"0\" name=\"stringProperty\" nillable=\"true\" type=\"xsd:string\"/>\n        <!-- remove the floatProperty element\n        <xsd:element maxOccurs=\"1\" minOccurs=\"0\" name=\"floatProperty\" nillable=\"true\" type=\"xsd:double\"/>\n        -->\n        <xsd:element maxOccurs=\"1\" minOccurs=\"0\" name=\"geometry\" nillable=\"true\" type=\"gml:PointPropertyType\"/>\n      </xsd:sequence>\n    </xsd:extension>\n    </xsd:complexContent>\n</xsd:complexType>\n
                                2. The modification is saved in a file named schema.xsd.

                                3. The schema.xsd file is copied into the feature type directory for the topp:myDataset which is:

                                  $GEOSERVER_DATA_DIR/workspaces/<workspace>/<datastore>/myDataset/\n

                                  where <workspace> is the name of the workspace containing your data store and <datastore> is the name of the data store which contains myDataset

                                The modified schema will only be available to GeoServer when the configuration is reloaded or GeoServer is restarted.

                                A subsequent DescribeFeatureType request for topp:myDataset confirms the floatProperty element is absent:

                                <xsd:schema xmlns:xsd=\"http://www.w3.org/2001/XMLSchema\"\n xmlns:gml=\"http://www.opengis.net/gml\"\n xmlns:topp=\"http://www.openplans.org/topp\" \n targetNamespace=\"http://www.openplans.org/topp\"\n elementFormDefault=\"qualified\">\n\n  <xsd:import namespace=\"http://www.opengis.net/gml\"\n   schemaLocation=\"http://localhost:8080/geoserver/schemas/gml/3.1.1/base/gml.xsd\"/>\n\n  <xsd:complexType name=\"myDatasetType\">\n    <xsd:complexContent>\n      <xsd:extension base=\"gml:AbstractFeatureType\">\n        <xsd:sequence>\n          <xsd:element maxOccurs=\"1\" minOccurs=\"0\" name=\"intProperty\" nillable=\"true\" type=\"xsd:int\"/>\n          <xsd:element maxOccurs=\"1\" minOccurs=\"0\" name=\"stringProperty\" nillable=\"true\" type=\"xsd:string\"/>\n          <xsd:element maxOccurs=\"1\" minOccurs=\"0\" name=\"geometry\" nillable=\"true\" type=\"gml:PointPropertyType\"/>\n        </xsd:sequence>\n      </xsd:extension>\n    </xsd:complexContent>\n  </xsd:complexType>\n\n  <xsd:element name=\"myDataset\" substitutionGroup=\"gml:_Feature\" type=\"topp:myDatasetType\"/>\n\n</xsd:schema>\n

                                A GetFeature request will now return features that don't include the floatProperty attribute:

                                <topp:myDataset gml:id=\"myDataset.1\">\n  <topp:intProperty>1</topp:intProperty>\n  <topp:stringProperty>one</topp:stringProperty>\n  <topp:geometry>\n    <gml:Point srsName=\"urn:x-ogc:def:crs:EPSG:4326\">\n      <gml:pos>1.0 1.0</gml:pos>\n    </gml:Point>\n  </topp:geometry>\n</topp:myDataset>\n
                                "},{"location":"services/wfs/schemamapping/#wfs_schema_type_changing","title":"Type changing","text":"

                                Schema customization may be used to perform some type changing, although this is limited by the fact that a changed type must be in the same domain as the original type. For example, integer types must be changed to integer types, temporal types to temporal types, and so on.

                                The most common change type requirement is for geometry attributes. In many cases the underlying data set does not have the necessary metadata to report the specific geometry type of a geometry attribute. The automatic schema mapping would result in an element definition similar to the following:

                                <xsd:element maxOccurs=\"1\" minOccurs=\"0\" name=\"geometry\" nillable=\"true\" type=\"gml:GeometryPropertyType\"/>\n

                                However if the specific type of the geometry is known, the element definition above could be altered. For point geometry, the element definition could be altered to :

                                <xsd:element maxOccurs=\"1\" minOccurs=\"0\" name=\"geometry\" nillable=\"true\" type=\"gml:PointPropertyType\"/>\n
                                "},{"location":"services/wfs/vendor/","title":"WFS vendor parameters","text":"

                                WFS vendor parameters are non-standard request parameters defined by an implementation to provide enhanced capabilities. GeoServer supports a variety of vendor-specific WFS parameters.

                                "},{"location":"services/wfs/vendor/#general-vendor-options","title":"General Vendor Options","text":"

                                These vendor options are available for all operations.

                                content-disposition ^^^^^^^^^^^^^^^^^^^

                                The content-disposition parameter directs how a web browser directed to handle returned content. The syntax is::

                                content-disposition=

                                Where content-disposition =attachment to direct the browser to save the content to disk.

                                Where content-disposition=inline asks the browser to display the content. Note this may present performance issues when asked to display very large content.

                                filename ^^^^^^^^

                                The filename parameter provides a suggested filename when a browser saves a file (e.g. to Downloads folder). The syntax is::

                                filename=

                                An example of filename use is::

                                filename=features.json

                                When service output is saved as a file, the vendor-option filename is used to provide the file name used.

                                "},{"location":"services/wfs/vendor/#xml-request-validation","title":"XML request validation","text":"

                                GeoServer is less strict than the WFS specification when it comes to the validity of an XML request. To force incoming XML requests to be valid, use the following parameter:

                                strict=[true|false]\n

                                The default option for this parameter is false.

                                For example, the following request is invalid:

                                <wfs:GetFeature service=\"WFS\" version=\"1.0.0\"\n xmlns:wfs=\"http://www.opengis.net/wfs\">\n  <Query typeName=\"topp:states\"/>\n</wfs:GetFeature>\n

                                The request is invalid for two reasons:

                                • The Query element should be prefixed with wfs:.
                                • The namespace prefix has not been mapped to a namespace URI.

                                That said, the request would still be processed by default. Executing the above command with the strict=true parameter, however, would result in an error. The correct syntax should be:

                                <wfs:GetFeature service=\"WFS\" version=\"1.0.0\"\n xmlns:wfs=\"http://www.opengis.net/wfs\" \n xmlns:topp=\"http://www.openplans.org/topp\">\n  <wfs:Query typeName=\"topp:states\"/>\n</wfs:GetFeature>\n
                                "},{"location":"services/wfs/vendor/#getcapabilities-request","title":"GetCapabilities Request","text":""},{"location":"services/wfs/vendor/#namespace-filter","title":"Namespace filter","text":"

                                WFS GetCapabilities requests may be filtered to return only those layers that correspond to a particular namespace by adding the <namespace> parameter to the request.

                                Note

                                This parameter only affects GetCapabilities requests.

                                To apply this filter, add the following code to your request:

                                namespace=<namespace>\n

                                Although providing an invalid namespace will not result in any errors, the GetCapabilities document returned will not contain any layer information.

                                Warning

                                Using this parameter may result your GetCapabilities document becoming invalid, as the WFS specification requires the document to return at least one layer.

                                Note

                                This filter is related to Virtual Services.

                                "},{"location":"services/wfs/vendor/#getfeature-request","title":"GetFeature Request","text":""},{"location":"services/wfs/vendor/#cql-filters","title":"CQL filters","text":"

                                In WFS GetFeature GET requests, the cql_filter parameter can be used to specify a filter in ECQL (Extended Common Query Language) format. ECQL provides a more compact and readable syntax compared to OGC XML filters.

                                For full details see the ECQL Reference and CQL and ECQL tutorial.

                                The following example illustrates a GET request OGC filter:

                                filter=%3CFilter%20xmlns:gml=%22http://www.opengis.net/gml%22%3E%3CIntersects%3E%3CPropertyName%3Ethe_geom%3C/PropertyName%3E%3Cgml:Point%20srsName=%224326%22%3E%3Cgml:coordinates%3E-74.817265,40.5296504%3C/gml:coordinates%3E%3C/gml:Point%3E%3C/Intersects%3E%3C/Filter%3E\n

                                Using ECQL, the identical filter would be defined as follows:

                                cql_filter=INTERSECTS(the_geom,%20POINT%20(-74.817265%2040.5296504))\n
                                "},{"location":"services/wfs/vendor/#format-options","title":"Format options","text":"

                                The format_options parameter is a container for other parameters that are format-specific. The syntax is:

                                format_options=param1:value1;param2:value2;...\n

                                The supported format option is:

                                • callback (default is parseResponse) - specifies the callback function name for the JSONP response format
                                • id_policy (default is true) - Specifies id generation for the JSON output format. To include feature id in the output, use an attribute name, or use format_options=id_policy:true for feature id generation. To avoid the use of feature id completely use format_options=id_policy:false.
                                • filename (default is features or generated from feature type name)- provide a Content-Disposition header indicating the attachment filename (used as a suggestion by browsers saving content to disk using Save-As). For example format_options=filename:content.txt.
                                • csvseparator (default is `, ``` )- Specifies a separator that can be used in output csv file
                                "},{"location":"services/wfs/vendor/#reprojection","title":"Reprojection","text":"

                                As WFS 1.1.0 and 2.0.0 both support data reprojection, GeoServer can store the data in one projection and return GML in another projection. While not part of the specification, GeoServer supports this using WFS 1.0.0 as well. When submitting a WFS GetFeature GET request, you can add this parameter to specify the reprojection SRS as follows:

                                srsName=<srsName>\n

                                The code for the projection is represented by <srsName>, for example EPSG:4326. For POST requests, you can add the same code to the Query element.

                                "},{"location":"services/wfs/webadmin/","title":"WFS settings","text":"

                                This page details the configuration options for WFS in the web administration interface.

                                "},{"location":"services/wfs/webadmin/#workspace","title":"Workspace","text":"

                                Select workspace empty to configure global WFS settings.

                                See the section on Workspace Services to override settings used by WFS Virtual Services.

                                "},{"location":"services/wfs/webadmin/#service-metadata","title":"Service Metadata","text":"

                                For a description of WFS service options, see the section on Service Metadata.

                                "},{"location":"services/wfs/webadmin/#features","title":"Features","text":"

                                WFS configuration options - Features section

                                The Open Geospatial Consortium (OGC) Web Feature Service (WFS) is a protocol for serving geographic features across the Web. Feature information that is encoded and transported using WFS includes both feature geometry and feature attribute values. Basic Web Feature Service (WFS) supports feature query and retrieval. Feature limits and bounding can be configured on the WFS page.

                                Maximum number of features --- Maximum number of features that a WFS GetFeature operation should generate, regardless of the actual number of query hits. A WFS request can potentially contain a large dataset that is impractical to download to a client, and/or too large for a client's renderer. Maximum feature limits are also available for feature types. The default number is 1000000.

                                Maximum number of features for preview (Values <= 0 use the maximum number of features) - Maximum number of features to use for layer previews. The default is 50 features.

                                Return bounding box with every feature --- When creating the GetFeature GML output, adds an auto-calculated bounds element on each feature type. Not typically enabled, as including bounding box takes up extra bandwidth.

                                Ignore maximum number of features when calculating hits - When calculating the total number of hits, ignore the Maximum number of features setting. This can be used to get the count of matching features, even if they would not be made available for download because they exceed the maximum count specified. On very large data sets, this can slow down the response.

                                Activate complex to simple features conversion - Enables the conversion of complex features to simple features, using only SF-0 (simple) attributes for compatible output formats like CSV, KML, SHAPE-ZIP.

                                "},{"location":"services/wfs/webadmin/#service-levels","title":"Service Levels","text":"

                                WFS configuration options - Service Level section

                                GeoServer is compliant with the full \"Transactional Web Feature Server\" (WFS-T) level of service as defined by the OGC. Specifying the WFS service level limits the capabilities of GeoServer while still remaining compliant. The WFS Service Level setting defines what WFS operations are \"turned on\".

                                Basic --- Basic service levels provides facilities for searching and retrieving feature data with the GetCapabilities, DescribeFeatureType and GetFeature operations. It is compliant with the OGC basic Web Feature Service. This is considered a READ-ONLY web feature service.

                                Transactional --- In addition to all basic WFS operations, transactional service level supports transaction requests. A transaction request facilitates the creation, deletion, and updating of geographic features in conformance with the OGC Transactional Web Feature Service (WFS-T).

                                Complete --- Includes LockFeature support to the suite of transactional level operations. LockFeature operations help resolve links between related resources by processing lock requests on one or more instances of a feature type.

                                "},{"location":"services/wfs/webadmin/#extra-srs-codes-for-wfs-capabilities-generation","title":"Extra SRS codes for WFS capabilities generation","text":"

                                WFS 1.1.0 onwards adds the ability to reproject GetFeature output to a user specified target SRS. The list of applicable target SRS is defined on a feature type basis in the capabilities documents, and GeoServer allows reprojection to any supported SRS in its internal database. To declare that GeoServer would have to add 5000+ otherSRS/otherCRS elements per feature type, which is clearly impractical. As a result, no declaration is made by default.

                                A list of values to be declared in all feature types can be provided in the WFS administration panel, as a comma separated list of EPSG codes:

                                WFS otherSRS/otherCRS configuration

                                The list will be used only for the capabilities document generation. It does not limit the actual target SRS usage in GetFeature requests.

                                "},{"location":"services/wfs/webadmin/#csv","title":"CSV","text":"

                                WFS configuration options - CSV section

                                CSV is still widely used as a format to exchange tabular data. For GeoServer CSV output format, the date field format can specified using the Date Format text box as shown above. Here are some common formatting patterns supported

                                Date and Time Pattern Result

                                yyyy.MM.dd G 'at' HH:mm:ss z 2001.07.04 AD at 12:08:56 PDT

                                EEE, MMM d, ''yy Wed, Jul 4, '01

                                yyyy-MM-dd'T'HH:mm:ss.SSSZ 2001-07-04T12:08:56.235-0700

                                yyyy-MM-dd'T'HH:mm:ss.SSSXXX 2001-07-04T12:08:56.235-07:00

                                Here, yyyy-MM-dd'T'HHss.SSS'Z' pattern represents the year, month, day, hour, minute, second and milliseconds. The components are separated by a hyphen character. A literal 'T' character is used to separate the date and time parts. A literal 'Z' character represents the UTC time zone. For instance, yyyy represents the year with four digits, MM represents the month with leading zeros, dd represents the day with leading zeros, and so on.

                                Similarly, patterns can be formed by using the characters provided below

                                y- Year (four digits) \nyy- Year (two digits) \nyyyy- Year (four digits) \nM- Month (1 or 2 digits) \nMM- Month (2 digits, with leading zero) \nMMM- Month abbreviation (e.g., 'Jan', 'Feb') \nMMMM- Full month name (e.g., 'January', 'February') \nd- Day of the month (1 or 2 digits) \ndd- Day of the month (2 digits, with leading zero) \nE- Day of the week abbreviation (e.g., 'Mon', 'Tue') \nEEEE- Full day of the week (e.g., 'Monday', 'Tuesday') \nH- Hour in 24-hour format (0 to 23) \nHH- Hour in 24-hour format (2 digits, with leading zero) \nh- Hour in 12-hour format (1 to 12) \nhh- Hour in 12-hour format (2 digits, with leading zero) \nm- Minute (1 or 2 digits) \nmm- Minute (2 digits, with leading zero) \ns- Second (1 or 2 digits) \nss- Second (2 digits, with leading zero) \nSSS- Represents the milliseconds in a three-digit format (e.g., 750)\na- AM/PM marker \nn- Nanosecond \nZ- Time zone offset (e.g., '+0800') \nzzzz- Time zone full name (e.g., 'Pacific Standard Time')\n

                                Reference SimpleDateFormat Link : https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/text/SimpleDateFormat.html

                                "},{"location":"services/wfs/webadmin/#configuration-of-output-format-types-allowed-in-getfeature","title":"Configuration of Output Format types allowed in GetFeature","text":"

                                Checking the Enable Output Format type checking checkbox will enable restrictions on the available output formats for GetFeature requests. It will also limit what Output Format types will be displayed as available in GetCapabilities responses. GetFeature requests with Output types not included in the Allowed Output types panel will result in an Invalid Parameter ServiceException response.

                                Note that if the Allowed Output Types panel is left as empty and the Enable Output Format Type checking is checked, all Output types will be restricted.

                                Output Format types configuration

                                "},{"location":"services/wfs/webadmin/#gml","title":"GML","text":"

                                WFS configuration options - GML sections

                                Geography Markup Language (GML) is the XML-based specification defined by the Open Geospatial Consortium (OGC) to express geographical features. GML serves as a modeling language for geographic systems as well as an open interchange format for geographic transactions on the Internet.

                                The older GML standard, GML 2 encodes geographic information, including both spatial and non-spatial properties. GML3 extends GML2 support to 3D shapes (surfaces and solids) as well as other advanced facilities. GML 3 is a modular superset of GML 2 that simplifies and minimizes the implementation size by allowing users to select out necessary parts. Additions in GML 3 include support for complex geometries, spatial and temporal reference systems, topology, units of measure, metadata, gridded data, and default styles for feature and coverage visualization. GML 3 is almost entirely backwards compatible with GML 2.

                                WFS 2.0.0 request return GML 3.2 as the default format, WFS 1.1.0 requests return GML 3 as the default format, and WFS 1.0.0 requests return GML 2 as the default format. For each of the GML formats supported by GeoServer, a different SRS format can be selected.

                                EPSG Code --- Returns the typical EPSG number in the form EPSG:XXXX (e.g. EPSG:4326). This formats the geographic coordinates in longitude/latitude (x/y) order.

                                OGC HTTP URL --- Returns a URL that identifies each EPSG code: http://www.opengis.net/gml/srs/epsg.xml#XXXX (e.g. http://www.opengis.net/gml/srs/epsg.xml#4326). This formats the geographic coordinates in longitude/latitude (x/y) order. This format is the default GML 2 SRS convention.

                                OGC Experimental URN - Returns a URN that identifies each EPSG code: urn:x-ogc:def:crs:EPSG:XXXX (e.g. urn:x-ogc:def:crs:EPSG:4326). This format was the original GML 3 SRS convention.

                                OGC URN --- (WFS 1.1.1 only) Returns the colon delimited SRS formatting: urn:ogc:def:crs:EPSG::XXXX (e.g urn:ogc:def:crs:EPSG::4326). This is the revised GML 3 SRS convention, and is the default for GML 3.2. This formats data in the traditional axis order for geographic and cartographic systems---latitude/longitude (y/x).

                                OGC HTTP URI - Returns a URI that identifies each EPSG code: http://www.opengis.net/def/crs/EPSG/0/XXXX (e.g. http://www.opengis.net/def/crs/EPSG/0/4326).

                                For each GML type, there is also an \"Override GML Attributes\" checkbox. Selecting this (checking the checkbox) will cause attributes to be redefined in the application schema.

                                "},{"location":"services/wfs/webadmin/#override-gml-32-mime-type","title":"Override GML 3.2 MIME type","text":"

                                The default MIME used for GML 3.2 encoded responses is application/gml+xml; version=3.2 which is the MIME type mandated by OGC WFS 2.0 specification. This MIME type is not identified as XML by most common clients such as browsers.

                                Option Override MIME Type allows the selection of the MIME type that should be used for the responses encoded in GML 3.2.

                                The available MIME types are: application/gml+xml; version=3.2, text/xml; subtype=gml/3.2 and text/xml.

                                "},{"location":"services/wfs/webadmin/#configure-xml-entity-expansion-limit-on-wfs-xml-readers","title":"Configure XML Entity Expansion limit on WFS XML readers","text":"

                                By default, the WFS XML reader sets Entity Expansion limit to 100, but it can be configured via the org.geoserver.wfs.xml.entityExpansionLimit system property, or using the web.xml init parameter, or by Environment variable.

                                For example, using the command line the limit can be adjusted using a parameter:

                                -Dorg.geoserver.wfs.xml.entityExpansionLimit=50

                                Or in Tomcat properties file ({TOMCAT_HOME}/conf/catalina.properties) adding the line:

                                org.geoserver.wfs.xml.entityExpansionLimit=50

                                "},{"location":"services/wfs/webadmin/#conformance","title":"Conformance","text":"

                                WFS configuration options - Conformance section

                                Selecting the Encode canonical WFS schema location checkbox modifies the WFS responses to include the canonical schema locations in the xsi:schemaLocation attribute, instead of using the default schema locations on the local GeoServer. Note that turning this option on may result in the client not being able to validate the WFS response, depending on network configuration.

                                "},{"location":"services/wfs/webadmin/#encode-response-with","title":"Encode response with","text":"

                                WFS configuration options - Encode response with

                                The Encode response with radio button group has two selection - One \"featureMembers\" element (the default) or Multiple \"featureMember\" elements. This switches the WFS 1.1.0 encoding accordingly. Use of multiple featureMember elements may be required for Application Schema referencing.

                                "},{"location":"services/wfs/webadmin/#shape-zip-output-format","title":"SHAPE-ZIP output format","text":"

                                WFS configuration options - Encode response with

                                Selecting the Use ESRI WKT format for SHAPE-ZIP generated .prj files checkbox modifies how projections are encoded in the Shapefile zip output format. If this checkbox is not selected, OGC WKT format will be used. If this checkbox is selected, ESRI WKT format will be used.

                                Note: this requires an esri.properties file to be provided in the user_projections subdirectory of the GeoServer data directory. This may be obtained from the GeoTools EPSG extension.

                                Selecting the Include WFS request dump file checkbox specifies if the file 'wfsrequest.txt' will be included in the Shapefile zip output. 'wfsrequest.txt' contains a dump of the full request URL used to get the Shapefile zip output. If this checkbox is not selected, 'wfsrequest.txt' will not be included in the output. If this checkbox is selected, 'wfsrequest.txt' will be included in the output.

                                "},{"location":"services/wfs/webadmin/#stored-queries","title":"Stored Queries","text":"

                                Selecting the Allow Global Stored Queries checkbox determines if global stored queries will included for usage in workspace virtual services, or not. When disabled, only stored queries created inside the workspace will be visible.

                                "},{"location":"services/wfs/webadmin/#i18n-settings","title":"i18n Settings","text":"

                                Select default language for WFS Service.

                                Default language

                                See Internationalization (i18n) section for a how this setting is used.

                                "},{"location":"services/wms/","title":"Web Map Service (WMS)","text":"

                                This section describes the Web Map Service (WMS).

                                • WMS settings
                                • WMS basics
                                • GetCapabilities
                                • Time Support in GeoServer WMS
                                • WMS output formats
                                • WMS vendor parameters
                                • Non Standard AUTO Namespace
                                • WMS configuration
                                • Global variables affecting WMS
                                • GetLegendGraphic
                                • WMS Decorations
                                • Google Earth
                                "},{"location":"services/wms/basics/","title":"WMS basics","text":"

                                GeoServer provides support for Open Geospatial Consortium (OGC) Web Map Service (WMS) versions 1.1.1 and 1.3.0. This is the most widely used standard for generating maps on the web, and it is the primary interface to request map products from GeoServer. Using WMS makes it possible for clients to overlay maps from several different sources in a seamless way.

                                GeoServer's WMS implementation fully supports the standard, and is certified compliant against the OGC's test suite. It includes a wide variety of rendering and labeling options, and is one of the fastest WMS Servers for both raster and vector data.

                                GeoServer WMS supports reprojection to any coordinate reference system in the EPSG database. It is possible to add additional coordinate systems if the Well Known Text definition is known. See Coordinate Reference System Handling for details.

                                GeoServer fully supports the Styled Layer Descriptor (SLD) standard, and uses SLD files as its native styling language. For more information on how to style data in GeoServer see the section Styling

                                "},{"location":"services/wms/basics/#differences-between-wms-versions","title":"Differences between WMS versions","text":"

                                The major differences between versions 1.1.1 and 1.3.0 are:

                                • In 1.1.1 geographic coordinate systems specified with the EPSG namespace are defined to have an axis ordering of longitude/latitude. In 1.3.0 the ordering is latitude/longitude. See Axis Ordering below for more details.
                                • In the GetMap operation the srs parameter is called crs in 1.3.0. GeoServer supports both keys regardless of version.
                                • In the GetFeatureInfo operation the x and y parameters are called i and j in 1.3.0. GeoServer supports both keys regardless of version, except when in CITE-compliance mode.
                                "},{"location":"services/wms/basics/#axis_ordering","title":"Axis Ordering","text":"

                                The WMS 1.3.0 specification mandates using the axis ordering as defined in the EPSG database. For instance, for EPSG:4326 the axis ordering is latitude/longitude, or north/east. This is contrary to the fact that most spatial data is usually in longitude/latitude, or east/north.

                                The WMS 1.1 always uses east/north axis ordering. So when upgrading from WMS 1.1, if the CRS defines north/east axis ordering (e.g. EPSG:4326), the coordinate order in the BBOX parameter must be reversed.

                                For example, consider the WMS 1.1 request using the WGS84 SRS (EPSG:4326):

                                geoserver/wms?VERSION=1.1.1&REQUEST=GetMap&SRS=epsg:4326&BBOX=-180,-90,180,90&...

                                The equivalent WMS 1.3.0 request is:

                                geoserver/wms?VERSION=1.3.0&REQUEST=GetMap&CRS=epsg:4326&BBOX=-90,-180,90,180&...

                                Note that the coordinates specified in the BBOX parameter are reversed.

                                "},{"location":"services/wms/configuration/","title":"WMS configuration","text":""},{"location":"services/wms/configuration/#layer-groups","title":"Layer Groups","text":"

                                A Layer Group is a group of layers that can be referred to by one layer name. For example, if you put three layers (call them layer_A, layer_B, and layer_C) under the one \"Layer Group\" layer, then when a user makes a WMS getMap request for that group name, they will get a map of those three layers.

                                For information on configuring Layer Groups in the Web Administration Interface see Layer Groups

                                "},{"location":"services/wms/configuration/#wms_configuration_limits","title":"Request limits","text":"

                                The request limit options allow the administrator to limit the resources consumed by each WMS GetMap request.

                                The following table shows the option names, a description, and the minimum GeoServer version at which the option is available (older versions will ignore it if set).

                                Option Description Version

                                Max rendering memory (KB) Sets the maximum amount of memory a single GetMap request is allowed to use (in kilobytes). The limit is checked before request execution by estimating how much memory would be required to produce the output in the format requested. For example, for an image format the estimate is based on the size of the required rendering memory (which is determined by the image size, the pixel bit depth, and the number of active FeatureTypeStyles at the requested scale). If the estimated memory size is below the limit, the request is executed; otherwise it is cancelled. 1.7.5

                                Max rendering time (s) Sets the maximum amount of time GeoServer will spend processing a request (in seconds). This time limits the \"blind processing\" portion of the request, that is, the time taken to read data and compute the output result (which may occur concurrently). If the execution time reaches the limit, the request is cancelled. The time required to write results back to the client is not limited by this parameter, since this is determined by the (unknown) network latency between the server and the client. For example, in the case of PNG/JPEG image generation, this option limits the data reading and rendering time, but not the time taken to write the image out. 1.7.5

                                Max rendering errors (count) Sets the maximum amount of rendering errors tolerated by a GetMap request. By default GetMap makes a best-effort attempt to serve the result, ignoring invalid features, reprojection errors and the like. Setting a limit on the number of errors ignored can make it easier to notice issues, and conserves CPU cycles by reducing the errors which must be handled and logged 1.7.5

                                Max number of dimension values Sets the maximum number of dimension (time, elevation, custom) values that a client can request in a GetMap/GetFeatureInfo request (the work to be done is usually proportional to said number of times, and the list of values is kept in memory during the processing) 2.14.0

                                The default value of each limit is 0, which specifies that the limit is not applied.

                                If any of the request limits is exceeded, the GetMap operation is cancelled and a ServiceException is returned to the client.

                                When setting the above limits it is suggested that peak conditions be taken into consideration. For example, under normal circumstances a GetMap request may take less than a second. Under high load it is acceptable for it to take longer, but it's usually not desirable to allow a request to go on for 30 minutes.

                                The following table shows examples of reasonable values for the request limits:

                                Option Value Rationale

                                maxRequestMemory 16384 16MB are sufficient to render a 2048x2048 image at 4 bytes per pixel (full color and transparency), or a 8x8 meta-tile when using GeoWebCache or TileCache. Note that the rendering process uses a separate memory buffer for each FeatureTypeStyle in an SLD, so this also affects the maximum image size. For example, if an SLD contains two FeatureTypeStyle elements in order to draw cased lines for a highway, the maximum image size will be limited to 1448x1448 (the memory requirement increases with the product of the image dimensions, so halving the memory decreases image dimensions by only about 30%)

                                maxRenderingTime 120 A request that processes for a full two minutes is probably rendering too many features, regardless of the current server load. This may be caused by a request against a big layer using a style that does not have suitable scale dependencies

                                maxRenderingErrors 100 Encountering 100 errors is probably the result of a request trying to reproject a big data set into a projection that is not appropriate for the output extent, resulting in many reprojection failures.

                                "},{"location":"services/wms/configuration/#layergroup-capabilities-settings","title":"LayerGroup Capabilities Settings","text":"

                                Option Description

                                Default LayerGroup Style In GetCapabilities Enable/disable the encoding of the default LayerGroup style in GetCapabilties responses for LayerGroup with mode Named Tree, Container Tree, Earth Observation Tree. Single and Opaque groups are not affected by the option and will always show the default style. By default the option is set to enabled.

                                "},{"location":"services/wms/decoration/","title":"WMS Decorations","text":"

                                WMS Decorations provide a framework for visually annotating images from WMS with absolute, rather than spatial, positioning. Examples of decorations include compasses, legends, and watermarks.

                                "},{"location":"services/wms/decoration/#configuration","title":"Configuration","text":"

                                To use decorations in a GetMap request, the administrator must first configure a decoration layout. These layouts are stored in a subdirectory called layouts in the GeoServer data directory as XML files, one file per layout. Each layout file must have the extension .xml. Once a layout foo.xml is defined, users can request it by adding &format_options=layout:foo to the request parameters.

                                Layout files follow a very simple XML structure; a root node named layout containing any number of decoration elements. The order of the decoration elements is the order they are drawn so, in case they are overlapping, the first one will appear under the others.

                                Each decoration element has several attributes:

                                Attribute Meaning

                                type the type of decoration to use (see Decoration Types)

                                affinity the region of the map image to which the decoration is anchored

                                offset how far from the anchor point the decoration is drawn

                                size the maximum size to render the decoration. Note that some decorations may dynamically resize themselves.

                                Each decoration element may also contain an arbitrary number of option elements providing a parameter name and value:

                                <option name=\"foo\" value=\"bar\"/>\n

                                Option interpretation depends on the type of decoration in use.

                                "},{"location":"services/wms/decoration/#wms_decoration_types","title":"Decoration Types","text":"

                                While GeoServer allows for decorations to be added via extension, there is a core set of decorations included in the default installation. These decorations include:

                                The image decoration (type=\"image\") overlays a static image file onto the document. If height and width are specified, the image will be scaled to fit, otherwise the image is displayed at full size.

                                Option Name Meaning

                                url provides the URL or file path to the image to draw (relative to the GeoServer data directory)

                                opacity a number from 0 to 100 indicating how opaque the image should be.

                                The scaleratio decoration (type=\"scaleratio\") overlays a text description of the map's scale ratio onto the document.

                                Option Name Meaning

                                bgcolor the background color for the text. supports RGB or RGBA colors specified as hex values.

                                fgcolor the color for the text and border. follows the color specification from bgcolor.

                                format the number format pattern, specified using Java own DecimalFormat syntax

                                formatLanguage the language used to drive number formatting (applies only if also format is used), using a valid Java Locale

                                The scaleline decoration (type=\"scaleline\") overlays a graphic showing the scale of the map in world units.

                                Option Name Meaning

                                bgcolor the background color, as used in scaleratio

                                fgcolor the foreground color, as used in scaleratio

                                fontsize the size of the font to use

                                transparent if set to true, the background and border won't be painted (false by default)

                                measurement-system can be set to \"metric\" to only show metric units, \"imperial\" to only show imperial units, or \"both\" to show both of them (default)

                                The legend decoration (type=\"legend\") overlays a graphic containing legends for the layers in the map.

                                Option Name Meaning

                                legend_options the list of legend_options used as in GetLegendGraphic

                                opacity the legend opacity with a value between 0 and 1

                                The text decoration (type=\"text\") overlays a parametric, single line text message on top of the map. The parameter values can be fed via the env request parameter, just like SLD environment parameters.

                                Option Name Meaning

                                message the message to be displayed, as plain text or Freemarker template that can use the env map contents to expand variables

                                font-family the name of the font used to display the message, e.g., Arial, defaults to Serif

                                font-size the size of the font to use (can have decimals), defaults to 12

                                font-italic it true the font will be italic, defaults to false

                                font-bold if true the font will be bold, defaults to false

                                font-color the color of the message, in #RRGGBB or #RRGGBBAA format, defaults to black

                                halo-radius the radius of a halo around the message, can have decimals, defaults to 0

                                halo-color the halo fill color, in #RRGGBB or #RRGGBBAA format, defaults to white

                                "},{"location":"services/wms/decoration/#example","title":"Example","text":"

                                A layout configuration file might look like this:

                                <layout>\n    <decoration type=\"image\" affinity=\"bottom,right\" offset=\"6,6\" size=\"80,31\">\n        <option name=\"url\" value=\"pbGS_80x31glow.png\"/>\n    </decoration>\n\n    <decoration type=\"scaleline\" affinity=\"bottom,left\" offset=\"36,6\"/>\n\n    <decoration type=\"legend\" affinity=\"top,left\" offset=\"6,6\" size=\"auto\"/>\n</layout>\n

                                Used against the states layer from the default GeoServer data, this layout produces an image like the following.

                                The default states layer, drawn with the decoration layout above.

                                "},{"location":"services/wms/decoration/#wms_dynamic_decorations","title":"Expressions in decoration attributes and options","text":"

                                Each decoration can have options to control its appearance, as well as attributes controlling its positioning. Option and attribute values are normally static strings specified in the decoration layout.

                                However, it's also possible to make them dynamic using (E)CQL expressions, using the ${cql expression} syntax. The expression can use functions, and in particular it can access env variables provided though the request.

                                For example, this decoration layout:

                                <layout>\n    <decoration type=\"scaleline\" affinity=\"${env('sla', 'bottom,left')}\">\n       <option name=\"bgcolor\" value=\"${env('bg', '#AAAAAA')}\"/>\n    </decoration>\n</layout>\n

                                Would generate a scale line with:

                                • A light gray background, with a GetMap request that does not contain the bg env variable.
                                • A red background, if the request includes a env section like &env=bg:FF0000.
                                • A scaleline positioned on the top right, if the request includes a env section like &env=sla:top,right.

                                All options allow usage of expressions, with one notable exception: the message option in the text decoration. This one option cannot use expressions, as it would allow expansion, and evaluation, of user provided FreeMarker templates. The template can contain control structures, loops and other active elements, as such, allowing its value to be provided via WMS requests is deemed too risky.

                                "},{"location":"services/wms/global/","title":"Global variables affecting WMS","text":"

                                This document details the set of global variables that can affect WMS behaviour. Each global variable can be set as an environment variable, as a servlet context variable, or as a Java system property, just like the well known GEOSERVER_DATA_DIR setting. Refer to Setting the data directory location for details on how a global variable can be specified.

                                "},{"location":"services/wms/global/#max_filter_rules","title":"MAX_FILTER_RULES","text":"

                                A integer number (defaults to 20) When drawing a style containing multiple active rules the renderer combines the filters of the rules in OR and adds them to the standard bounding box filter. This behaviour is active up until the maximum number of filter rules is reached, past that the rule filters are no more added to avoid huge queries. By default up to 20 rules are combined, past 20 rules only the bounding box filter is used. Turning it off (setting it to 0) can be useful if the styles are mostly classifications, detrimental if the rule filters are actually filtering a good amount of data out.

                                "},{"location":"services/wms/global/#optimize_line_width","title":"OPTIMIZE_LINE_WIDTH","text":"

                                Can be true or false (defaults to: false). When true any stroke whose width is less than 1.5 pixels gets slimmed down to \"zero\", which is actually not zero, but a very thin line. That was the behaviour GeoServer used to default to before the 2.0 series. When false the stroke width is not modified and it's possible to specify widths less than one pixel. This is the default behaviour starting from the 2.0.0 release

                                "},{"location":"services/wms/global/#enable_jsonp","title":"ENABLE_JSONP","text":"

                                Can be true or false (defaults to: false). When true the JSONP (text/javascript) output format is enabled.

                                "},{"location":"services/wms/nonstandardautonamespace/","title":"Non Standard AUTO Namespace","text":"

                                The WMS standard supports a small number of \"automatic\" coordinate reference systems that include a user-selected centre of projection. These are specified using:

                                AUTO:auto_crs_id,factor,lon0,lat0\n

                                for example:

                                CRS=AUTO:42003,1,-100,45\n

                                Note

                                in GeoServer 2.8.x AUTO and AUTO2 namespaces are treated identically.

                                Note

                                in GeoServer 2.8.x the factor parameter in the AUTO namespace is ignored. The BBOX parameter to GetMap must therefore be specified in metres.

                                The WMS standard provide projections with IDs in the range 42001 to 42005.

                                ID Projection

                                42001 Universal Transverse Mercator

                                42002 Transverse Mercator

                                42003 Orthographic

                                42004 Equirectangular

                                42005 Mollweide (not supported in GeoServer 2.8.x)

                                GeoServer also supports some non-standard coordinate reference systems. These are

                                ID Projection

                                97001 Gnomonic

                                97002 Stereographic

                                Note

                                the auto stereographic projection uses a sphere. It does this by setting the semi minor axis to the same value as the semi major axis.

                                "},{"location":"services/wms/outputformats/","title":"WMS output formats","text":"

                                WMS returns images in a number of possible formats. This page shows a list of the output formats. The syntax for setting an output format is:

                                format=<format>\n

                                where <format> is any of the options below.

                                Note

                                The list of output formats supported by a GeoServer instance can be found by a WMS GetCapabilities request.

                                Format Syntax Notes

                                PNG format=image/png Default

                                PNG8 format=image/png8 Same as PNG, but computes an optimal 256 color (8 bit) palette, so the image size is usually smaller

                                JPEG format=image/jpeg

                                JPEG-PNG format=image/vnd.jpeg-png A custom format that will decide dynamically, based on the image contents, if it's best to use a JPEG or PNG compression. The images are returned in JPEG format if fully opaque and not paletted. In order to use this format in a meaningful way the GetMap must include a \"&transparent=TRUE\" parameter, as without it GeoServer generates opaque images with the default/requested background color, making this format always return JPEG images (or always PNG, if they are paletted). When using the layer preview to test this format, remember to add \"&transparent=TRUE\" to the preview URL, as normally the preview generates non transparent images.

                                JPEG-PNG8 format=image/vnd.jpeg-png8 Same as JPEG-PNG, but generating a paletted output if the PNG format is chosen

                                GIF format=image/gif

                                TIFF format=image/tiff

                                TIFF8 format=image/tiff8 Same as TIFF, but computes an optimal 256 color (8 bit) palette, so the image size is usually smaller

                                GeoTIFF format=image/geotiff Same as TIFF, but includes extra GeoTIFF metadata

                                GeoTIFF8 format=image/geotiff8 Same as TIFF, but includes extra GeoTIFF metadata and computes an optimal 256 color (8 bit) palette, so the image size is usually smaller

                                SVG format=image/svg

                                PDF format=application/pdf

                                GeoRSS format=rss

                                KML format=kml

                                KMZ format=kmz

                                MapML format=text/mapml

                                MapML HTML Viewer text/html; subtype=mapml

                                OpenLayers format=application/openlayers Generates an OpenLayers HTML application.

                                UTFGrid format=application/json;type=utfgrid Generates an UTFGrid 1.3 JSON response. Requires vector output, either from a vector layer, or from a raster layer turned into vectors by a rendering transformation.

                                "},{"location":"services/wms/reference/","title":"WMS reference","text":""},{"location":"services/wms/reference/#introduction","title":"Introduction","text":"

                                The OGC Web Map Service (WMS) specification defines an HTTP interface for requesting georeferenced map images from a server. GeoServer supports WMS 1.1.1, the most widely used version of WMS, as well as WMS 1.3.0.

                                The relevant OGC WMS specifications are:

                                • OGC Web Map Service Implementation Specification, Version 1.1.1
                                • OGC Web Map Service Implementation Specification, Version 1.3.0

                                GeoServer also supports some extensions to the WMS specification made by the Styled Layer Descriptor (SLD) standard to control the styling of the map output. These are defined in:

                                • OpenGIS Styled Layer Descriptor Profile of the Web Map Service Implementation Specification, Version 1.1.0
                                "},{"location":"services/wms/reference/#benefits-of-wms","title":"Benefits of WMS","text":"

                                WMS provides a standard interface for requesting a geospatial map image. The benefit of this is that WMS clients can request images from multiple WMS servers, and then combine them into a single view for the user. The standard guarantees that these images can all be overlaid on one another as they actually would be in reality. Numerous servers and clients support WMS.

                                "},{"location":"services/wms/reference/#operations","title":"Operations","text":"

                                WMS requests can perform the following operations:

                                Operation Description

                                GetCapabilities Retrieves metadata about the service, including supported operations and parameters, and a list of the available layers

                                GetMap Retrieves a map image for a specified area and content

                                GetFeatureInfo Retrieves the underlying data, including geometry and attribute values, for a pixel location on a map

                                DescribeLayer Indicates the WFS or WCS to retrieve additional information about the layer.

                                GetLegendGraphic Retrieves a generated legend for a map

                                "},{"location":"services/wms/reference/#wms_getcap","title":"GetCapabilities","text":"

                                The GetCapabilities operation requests metadata about the operations, services, and data (\"capabilities\") that are offered by a WMS server.

                                The parameters for the GetCapabilities operation are:

                                Parameter Required? Description

                                service Yes Service name. Value is WMS.

                                version Yes Service version. Value is one of 1.0.0, 1.1.0, 1.1.1, 1.3.0.

                                request Yes Operation name. Value is GetCapabilities.

                                GeoServer provides the following vendor-specific parameters for the GetCapabilities operation. They are fully documented in the WMS vendor parameters section.

                                Parameter Required? Description

                                namespace No limits response to layers in a given namespace

                                format No request the capabilities document in a certain format

                                rootLayer No Flag to enable/disable the standard Root top level Layer element. Values are true or false. When false, the Root element will be included only if there are multiple top level layers, if there is only one, it will be the root layer itself. When specified, will override the global WMS setting or layer / group setting for the same behaviour.

                                A example GetCapabilities request is: :

                                http://localhost:8080/geoserver/wms?\nservice=wms&\nversion=1.1.1&\nrequest=GetCapabilities\n

                                There are three parameters being passed to the WMS server, service=wms, version=1.1.1, and request=GetCapabilities. The service parameter tells the WMS server that a WMS request is forthcoming. The version parameter refers to which version of WMS is being requested. The request parameter specifies the GetCapabilities operation. The WMS standard requires that requests always includes these three parameters. GeoServer relaxes these requirements (by setting the default version if omitted), but for standard-compliance they should always be specified.

                                The response is a Capabilities XML document that is a detailed description of the WMS service. It contains three main sections:

                                Service Contains service metadata such as the service name, keywords, and contact information for the organization operating the server.

                                Request Describes the operations the WMS service provides and the parameters and output formats for each operation. If desired GeoServer can be configured to disable support for certain WMS operations.

                                Layer Lists the available coordinate systems and layers. In GeoServer layers are named in the form \"namespace:layer\". Each layer provides service metadata such as title, abstract and keywords.

                                "},{"location":"services/wms/reference/#wms_getmap","title":"GetMap","text":"

                                The GetMap operation requests that the server generate a map. The core parameters specify one or more layers and styles to appear on the map, a bounding box for the map extent, a target spatial reference system, and a width, height, and format for the output. The information needed to specify values for parameters such as layers, styles and srs can be obtained from the Capabilities document.

                                The response is a map image, or other map output artifact, depending on the format requested. GeoServer provides a wide variety of output formats, described in WMS output formats.

                                The standard parameters for the GetMap operation are:

                                Parameter Required? Description

                                service Yes Service name. Value is WMS.

                                version Yes Service version. Value is one of 1.0.0, 1.1.0, 1.1.1, 1.3.0.

                                request Yes Operation name. Value is GetMap.

                                layers Yes Layers to display on map. Value is a comma-separated list of layer names.

                                styles Yes Styles in which layers are to be rendered. Value is a comma-separated list of style names, or empty if default styling is required. Style names may be empty in the list, to use default layer styling.

                                srs or crs Yes Spatial Reference System for map output. Value is in form EPSG:nnn. crs is the parameter key used in WMS 1.3.0.

                                bbox Yes Bounding box for map extent. Value is minx,miny,maxx,maxy in units of the SRS.

                                width Yes Width of map output, in pixels.

                                height Yes Height of map output, in pixels.

                                format Yes Format for the map output. See WMS output formats for supported values.

                                transparent No Whether the map background should be transparent. Values are true or false. Default is false

                                bgcolor No Background color for the map image. Value is in the form RRGGBB. Default is FFFFFF (white).

                                exceptions No Format in which to report exceptions. Default value is application/vnd.ogc.se_xml.

                                time No Time value or range for map data. See Time Support in GeoServer WMS for more information.

                                sld No A URL referencing a StyledLayerDescriptor XML file which controls or enhances map layers and styling

                                sld_body No A URL-encoded StyledLayerDescriptor XML document which controls or enhances map layers and styling

                                GeoServer provides a number of useful vendor-specific parameters for the GetMap operation. These are documented in the WMS vendor parameters section.

                                Example WMS request for topp:states layer to be output as a PNG map image in SRS EPGS:4326 and using default styling is: :

                                http://localhost:8080/geoserver/wms?\nrequest=GetMap\n&service=WMS\n&version=1.1.1\n&layers=topp%3Astates\n&styles=population\n&srs=EPSG%3A4326\n&bbox=-145.15104058007,21.731919794922,-57.154894212888,58.961058642578&\n&width=780\n&height=330\n&format=image%2Fpng\n

                                The standard specifies many of the parameters as being mandatory, GeoServer provides the WMS Reflector to allow many of them to be optionally specified.

                                Experimenting with this feature is a good way to get to know the GetMap parameters.

                                Example WMS request using a GetMap XML document is:

                                <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<ogc:GetMap xmlns:ogc=\"http://www.opengis.net/ows\"\n            xmlns:gml=\"http://www.opengis.net/gml\"\n   version=\"1.1.1\" service=\"WMS\">\n   <StyledLayerDescriptor version=\"1.0.0\">\n      <NamedLayer>\n        <Name>topp:states</Name>\n        <NamedStyle><Name>population</Name></NamedStyle> \n      </NamedLayer> \n   </StyledLayerDescriptor>\n   <BoundingBox srsName=\"http://www.opengis.net/gml/srs/epsg.xml#4326\">\n      <gml:coord><gml:X>-130</gml:X><gml:Y>24</gml:Y></gml:coord>\n      <gml:coord><gml:X>-55</gml:X><gml:Y>50</gml:Y></gml:coord>\n   </BoundingBox>\n   <Output>\n      <Format>image/png</Format>\n      <Size><Width>550</Width><Height>250</Height></Size>\n   </Output>\n</ogc:GetMap>\n
                                "},{"location":"services/wms/reference/#time","title":"Time","text":"

                                As of GeoServer 2.2.0, GeoServer supports a TIME attribute for WMS GetMap requests as described in version 1.3.0 of the WMS specification. This parameter allows filtering a dataset by temporal slices as well as spatial tiles for rendering. See /services/wms/time for information on its use.

                                "},{"location":"services/wms/reference/#wms_getfeatureinfo","title":"GetFeatureInfo","text":"

                                The GetFeatureInfo operation requests the spatial and attribute data for the features at a given location on a map. It is similar to the WFS GetFeature operation, but less flexible in both input and output. Since GeoServer provides a WFS service we recommend using it instead of GetFeatureInfo whenever possible.

                                The one advantage of GetFeatureInfo is that the request uses an (x,y) pixel value from a returned WMS image. This is easier to use for a naive client that is not able to perform true geographic referencing.

                                The standard parameters for the GetFeatureInfo operation are:

                                Parameter Required? Description

                                service Yes Service name. Value is WMS.

                                version Yes Service version. Value is one of 1.0.0, 1.1.0, 1.1.1, 1.3.0.

                                request Yes Operation name. Value is GetFeatureInfo.

                                layers Yes See GetMap

                                styles Yes See GetMap

                                srs or crs Yes See GetMap

                                bbox Yes See GetMap

                                width Yes See GetMap

                                height Yes See GetMap

                                query_layers Yes Comma-separated list of one or more layers to query.

                                info_format No Format for the feature information response. See below for values.

                                feature_count No Maximum number of features to return. Default is 1.

                                x or i Yes X ordinate of query point on map, in pixels. 0 is left side. i is the parameter key used in WMS 1.3.0.

                                y or j Yes Y ordinate of query point on map, in pixels. 0 is the top. j is the parameter key used in WMS 1.3.0.

                                exceptions No Format in which to report exceptions. The default value is application/vnd.ogc.se_xml.

                                Note: If you are sending a GetFeatureInfo request against a layergroup, all the layers in that layergroup must be set as \"Queryable\" to get a result (See WMS Settings on Layers page<data_webadmin_layers>)

                                GeoServer supports a number of output formats for the GetFeatureInfo response. Server-styled HTML is the most commonly-used format. For maximum control and customisation the client should use GML3 and style the raw data itself. The supported formats are:

                                Format Syntax Notes

                                TEXT info_format=text/plain Simple text output. (The default format)

                                GML 2 info_format=application/vnd.ogc.gml Works only for Simple Features (see app-schema.complex-features)

                                GML 3 info_format=application/vnd.ogc.gml/3.1.1 Works for both Simple and Complex Features (see app-schema.complex-features)

                                HTML info_format=text/html Uses HTML templates that are defined on the server. See HTML output format for information on how to template HTML output.

                                JSON info_format=application/json Simple JSON representation. See GeoJSON output format for information on how to template JSON output.

                                JSONP info_format=text/javascript Returns JSONP in the form: parseResponse(...json...). See WMS vendor parameters to change the callback name. Note that this format is disabled by default (See Global variables affecting WMS).

                                GeoServer provides the following vendor-specific parameters for the GetFeatureInfo operation. They are fully documented in the WMS vendor parameters section.

                                Parameter Required? Description

                                buffer No width of search radius around query point (in pixels).

                                cql_filter No Filter for returned data, in ECQL format

                                filter No Filter for returned data, in OGC Filter format

                                propertyName No Feature properties to be returned

                                exclude_nodata_result No When set to true, a NaN will be returned when the feature's queried pixel value is nodata.

                                An example request for feature information from the topp:states layer in HTML format is: :

                                http://localhost:8080/geoserver/wms?\nrequest=GetFeatureInfo\n&service=WMS\n&version=1.1.1\n&layers=topp%3Astates\n&styles=\n&srs=EPSG%3A4326\n&format=image%2Fpng\n&bbox=-145.151041%2C21.73192%2C-57.154894%2C58.961059\n&width=780\n&height=330\n&query_layers=topp%3Astates\n&info_format=text%2Fhtml\n&feature_count=50\n&x=353\n&y=145\n&exceptions=application%2Fvnd.ogc.se_xml\n

                                An example request for feature information in GeoJSON format is: :

                                http://localhost:8080/geoserver/wms?\n&INFO_FORMAT=application/json\n&REQUEST=GetFeatureInfo\n&EXCEPTIONS=application/vnd.ogc.se_xml\n&SERVICE=WMS\n&VERSION=1.1.1\n&WIDTH=970&HEIGHT=485&X=486&Y=165&BBOX=-180,-90,180,90\n&LAYERS=COUNTRYPROFILES:grp_administrative_map\n&QUERY_LAYERS=COUNTRYPROFILES:grp_administrative_map\n&TYPENAME=COUNTRYPROFILES:grp_administrative_map\n

                                The result will be:

                                {\n\"type\":\"FeatureCollection\",\n\"features\":[\n   {\n      \"type\":\"Feature\",\n      \"id\":\"dt_gaul_geom.fid-138e3070879\",\n      \"geometry\":{\n         \"type\":\"MultiPolygon\",\n         \"coordinates\":[\n            [\n               [\n                  [\n                     XXXXXXXXXX,\n                     XXXXXXXXXX\n                  ],\n                  ...\n                  [\n                     XXXXXXXXXX,\n                     XXXXXXXXXX\n                  ]\n               ]\n            ]\n         ]\n      },\n      \"geometry_name\":\"at_geom\",\n      \"properties\":{\n         \"bk_gaul\":X,\n         \"at_admlevel\":0,\n         \"at_iso3\":\"XXX\",\n         \"ia_name\":\"XXXX\",\n         \"at_gaul_l0\":X,\n         \"bbox\":[\n            XXXX,\n            XXXX,\n            XXXX,\n            XXXX\n         ]\n      }\n   }\n],\n\"crs\":{\n   \"type\":\"EPSG\",\n   \"properties\":{\n      \"code\":\"4326\"\n   }\n},\n\"bbox\":[\n   XXXX,\n   XXXX,\n   XXXX,\n   XXXX\n]\n}\n
                                "},{"location":"services/wms/reference/#wms_describelayer","title":"DescribeLayer","text":"

                                The DescribeLayer operation is used primarily by clients that understand SLD-based WMS. In order to make an SLD one needs to know the structure of the data. WMS and WFS both have operations to do this, so the DescribeLayer operation just routes the client to the appropriate service.

                                The standard parameters for the DescribeLayer operation are:

                                Parameter Required? Description

                                service Yes Service name. Value is WMS.

                                version Yes Service version. Value is 1.1.1.

                                request Yes Operation name. Value is DescribeLayer.

                                layers Yes See GetMap

                                exceptions No Format in which to report exceptions. The default value is application/vnd.ogc.se_xml.

                                GeoServer supports a number of output formats for the DescribeLayer response. Server-styled HTML is the most commonly-used format. The supported formats are:

                                Format Syntax Notes

                                TEXT output_format=text/xml Same as default.

                                GML 2 output_format=application/vnd.ogc.wms_xml The default format.

                                JSON output_format=application/json Simple JSON representation.

                                JSONP output_format=text/javascript Return JSONP in the form: paddingOutput(...jsonp...). See WMS vendor parameters to change the callback name. Note that this format is disabled by default (See Global variables affecting WMS).

                                An example request in XML (default) format on a layer is: :

                                http://localhost:8080/geoserver/topp/wms?service=WMS &version=1.1.1 &request=DescribeLayer &layers=topp:coverage

                                <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<!DOCTYPE WMS_DescribeLayerResponse SYSTEM \"http://localhost:8080/geoserver/schemas/wms/1.1.1/WMS_DescribeLayerResponse.dtd\">\n<WMS_DescribeLayerResponse version=\"1.1.1\">\n   <LayerDescription name=\"topp:coverage\" owsURL=\"http://localhost:8080/geoserver/topp/wcs?\" owsType=\"WCS\">\n      <Query typeName=\"topp:coverage\"/>\n   </LayerDescription>\n</WMS_DescribeLayerResponse>\n

                                An example request for feature description in JSON format on a layer group is: :

                                http://localhost:8080/geoserver/wms?service=WMS\n&version=1.1.1\n&request=DescribeLayer\n&layers=sf:roads,topp:tasmania_roads,nurc:mosaic\n&outputFormat=application/json\n

                                The result will be: :

                                {\n  version: \"1.1.1\",\n  layerDescriptions: [\n    {\n        layerName: \"sf:roads\",\n        owsURL: \"http://localhost:8080/geoserver/wfs/WfsDispatcher?\",\n        owsType: \"WFS\",\n        typeName: \"sf:roads\"\n    },\n    {\n        layerName: \"topp:tasmania_roads\",\n        owsURL: \"http://localhost:8080/geoserver/wfs/WfsDispatcher?\",\n        owsType: \"WFS\",\n        typeName: \"topp:tasmania_roads\"\n    },\n    {\n        layerName: \"nurc:mosaic\",\n        owsURL: \"http://localhost:8080/geoserver/wcs?\",\n        owsType: \"WCS\",\n        typeName: \"nurc:mosaic\"\n    }\n  ]\n
                                "},{"location":"services/wms/reference/#wms_getlegendgraphic","title":"GetLegendGraphic","text":"

                                The GetLegendGraphic operation provides a mechanism for generating legend graphics as images, beyond the LegendURL reference of WMS Capabilities. It generates a legend based on the style defined on the server, or alternatively based on a user-supplied SLD. For more information on this operation and the various options that GeoServer supports see GetLegendGraphic.

                                "},{"location":"services/wms/reference/#exceptions","title":"Exceptions","text":"

                                Formats in which WMS can report exceptions. The supported values for exceptions are:

                                Format Syntax Notes

                                XML EXCEPTIONS=application/vnd.ogc.se_xml XML output. (The default format)

                                INIMAGE EXCEPTIONS=application/vnd.ogc.se_inimage Generates an image

                                BLANK EXCEPTIONS=application/vnd.ogc.se_blank Generates a blank image

                                PARTIALMAP EXCEPTIONS=application/vnd.gs.wms_partial This is a GeoServer vendor parameter and only applicable for GetMap requests. Returns everything that was rendered at the time the rendering process threw an exception. Can be used with the WMS Configuration Limits to return a partial image even if the request is terminated for exceeding one of these limits. It also works with the timeout vendor parameter.

                                JSON EXCEPTIONS=application/json Simple JSON representation.

                                JSONP EXCEPTIONS=text/javascript Return JSONP in the form: paddingOutput(...jsonp...). See WMS vendor parameters to change the callback name. Note that this format is disabled by default (See Global variables affecting WMS).

                                "},{"location":"services/wms/time/","title":"Time Support in GeoServer WMS","text":"

                                GeoServer supports a TIME attribute in GetMap requests for layers that are properly configured with a time dimension. This is used to specify a temporal subset for rendering.

                                For example, you might have a single dataset with weather observations collected over time and choose to plot a single day's worth of observations.

                                The attribute to be used in TIME requests can be set up through the GeoServer web interface by navigating to Layers -> [specific layer] -> Dimensions tab.

                                Note

                                Read more about how to use the web interface to configure an attribute for TIME requests.

                                "},{"location":"services/wms/time/#specifying-a-time","title":"Specifying a time","text":"

                                The format used for specifying a time in the WMS TIME parameter is based on ISO-8601. Times may be specified up to a precision of 1 millisecond; GeoServer does not represent time queries with more precision than this.

                                The parameter is:

                                TIME=<timestring>\n

                                Times follow the general format:

                                yyyy-MM-ddThh:mm:ss.SSSZ\n

                                where:

                                • yyyy: 4-digit year
                                • MM: 2-digit month
                                • dd: 2-digit day
                                • hh: 2-digit hour
                                • mm: 2-digit minute
                                • ss: 2-digit second
                                • SSS: 3-digit millisecond

                                The day and intraday values are separated with a capital T, and the entire thing is suffixed with a Z, indicating UTC for the time zone. (The WMS specification does not provide for other time zones.)

                                GeoServer will apply the TIME value to all temporally enabled layers in the LAYERS parameter of the GetMap request. Layers without a temporal component will be served normally, allowing clients to include reference information like political boundaries along with temporal data.

                                Description Time specification December 12, 2001 at 6:00 PM 2001-12-12T18:00:00.0Z May 5, 1993 at 11:34 PM 1993-05-05T11:34:00.0Z"},{"location":"services/wms/time/#specifying-an-absolute-interval","title":"Specifying an absolute interval","text":"

                                A client may request information over a continuous interval instead of a single instant by specifying a start and end time, separated by a / character.

                                In this scenario the start and end are inclusive; that is, samples from exactly the endpoints of the specified range will be included in the rendered tile.

                                Description Time specification The month of September 2002 2002-09-01T00:00:00.0Z/2002-09-30T23:59:59.999Z The entire day of December 25, 2010 2010-12-25T00:00:00.0Z/2010-12-25T23:59:59.999Z"},{"location":"services/wms/time/#specifying-a-relative-interval","title":"Specifying a relative interval","text":"

                                A client may request information over a relative time interval instead of a set time range by specifying a start or end time with an associated duration, separated by a / character.

                                One end of the interval must be a time value, but the other may be a duration value as defined by the ISO 8601 standard. The special keyword PRESENT may be used to specify a time relative to the present server time.

                                Description Time specification The month of September 2002 2002-09-01T00:00:00.0Z/P1M The entire day of December 25, 2010 2010-12-25T00:00:00.0Z/P1D The entire day preceding December 25, 2010 P1D/2010-12-25T00:00:00.0Z 36 hours preceding the current time PT36H/PRESENT

                                Note

                                The final example could be paired with the KML service to provide a Google Earth network link which is always updated with the last 36 hours of data.

                                "},{"location":"services/wms/time/#reduced-accuracy-times","title":"Reduced accuracy times","text":"

                                The WMS specification also allows time specifications to be truncated by omitting some of the time string. In this case, GeoServer treats the time as a range whose length is equal to the most precise unit specified in the time string.

                                For example, if the time specification omits all fields except year, it identifies a range one year long starting at the beginning of that year.

                                Note

                                GeoServer implements this by adding the appropriate unit, then subtracting 1 millisecond. This avoids surprising results when using an interval that aligns with the actual sampling frequency of the data - for example, if yearly data is natively stored with dates like 2001-01-01T00:00:00.0Z, 2002-01-01T00:00:00Z, etc. then a request for 2001 would include the samples for both 2001 and 2002, which wouldn't be desired.

                                Description Reduced Accuracy Time Equivalent Range The month of September 2002 2002-09 2002-09-01T00:00:00.0Z/2002-09-30T23:59:59.999Z The day of December 25, 2010 2010-12-25 2010-12-25T00:00:00.0Z/2010-12-25T23:59:59.999Z"},{"location":"services/wms/time/#reduced-accuracy-times-with-ranges","title":"Reduced accuracy times with ranges","text":"

                                Reduced accuracy times are also allowed when specifying ranges. In this case, GeoServer effectively expands the start and end times as described above, and then includes any samples from after the beginning of the start interval and before the end of the end interval.

                                Note

                                Again, the ranges are inclusive.

                                Description Reduced Accuracy Time Equivalent Range The months of September through December 2002 2002-09/2002-12 2002-09-01T00:00:00.0Z/2002-12-31T23:59:59.999Z 12PM through 6PM, December 25, 2010 2010-12-25T12/2010-12-25T18 2010-12-25T12:00:00.0Z/2010-12-25T18:59:59.999Z

                                Note

                                In the last example, note that the result may not be intuitive, as it includes all times from 6PM to 6:59PM.

                                "},{"location":"services/wms/time/#specifying-a-list-of-times","title":"Specifying a list of times","text":"

                                GeoServer can also accept a list of discrete time values. This is useful for some applications such as animations, where one time is equal to one frame.

                                The elements of a list are separated by commas.

                                Note

                                GeoServer currently does not support lists of ranges, so all list queries effectively have a resolution of 1 millisecond. If you use reduced accuracy notation when specifying a range, each range will be automatically converted to the instant at the beginning of the range.

                                If the list is evenly spaced (for example, daily or hourly samples) then the list may be specified as a range, using a start time, end time, and period separated by slashes.

                                Description List notation Equivalent range notation Noon every day for August 12-14, 2012 TIME=2012-08-12T12:00:00.0Z,2012-08-13T12:00:00.0Z,2012-08-14T12:00:00.0Z TIME=2012-08-12T12:00:00.0Z/2012-08-18:T12:00:00.0Z/P1D Midnight on the first of September, October, and November 1999 TIME=1999-09-01T00:00:00.0Z,1999-10-01T00:00:00.0Z,1999-11-01T00:00:00.0Z TIME=1999-09-01T00:00:00.0Z/1999-11-01T00:00:00.0Z/P1M"},{"location":"services/wms/time/#specifying-a-periodicity","title":"Specifying a periodicity","text":"

                                The periodicity is also specified in ISO-8601 format: a capital P followed by one or more interval lengths, each consisting of a number and a letter identifying a time unit:

                                Unit Abbreviation Years Y Months M Days D Hours H Minutes M Seconds S

                                The Year/Month/Day group of values must be separated from the Hours/Minutes/Seconds group by a T character. The T itself may be omitted if hours, minutes, and seconds are all omitted. Additionally, fields which contain a 0 may be omitted entirely.

                                Fractional values are permitted, but only for the most specific value that is included.

                                Note

                                The period must divide evenly into the interval defined by the start/end times. So if the start/end times denote 12 hours, a period of 1 hour would be allowed, but a period of 5 hours would not.

                                For example, the multiple representations listed below are all equivalent.

                                • One hour:

                                  P0Y0M0DT1H0M0S\n\nPT1H0M0S\n\nPT1H\n
                                • 90 minutes:

                                  P0Y0M0DT1H30M0S\n\nPT1H30M\n\nP90M\n
                                • 18 months:

                                  P1Y6M0DT0H0M0S\n\nP1Y6M0D\n\nP0Y18M0DT0H0M0S\n\nP18M\n

                                  Note

                                  P1.25Y3M would not be acceptable, because fractional values are only permitted in the most specific value given, which in this case would be months.

                                "},{"location":"services/wms/vendor/","title":"WMS vendor parameters","text":"

                                WMS vendor parameters are non-standard request parameters that are defined by an implementation to provide enhanced capabilities. GeoServer supports a variety of vendor-specific parameters.

                                "},{"location":"services/wms/vendor/#general-vendor-options","title":"General Vendor Options","text":"

                                These vendor options are available for all operations.

                                content-disposition ^^^^^^^^^^^^^^^^^^^

                                The content-disposition parameter directs how a web browser directed to handle returned content. The syntax is::

                                content-disposition=

                                Where content-disposition =attachment to direct the browser to save the content to disk.

                                Where content-disposition=inline asks the browser to display the content. Note this may present performance issues when asked to display very large content.

                                filename ^^^^^^^^

                                The filename parameter provides a suggested filename when a browser saves a file (e.g. to Downloads folder). The syntax is::

                                filename=

                                An example of filename use is::

                                filename=features.json

                                When service output is saved as a file, the vendor-option filename is used to provide the file name used.

                                "},{"location":"services/wms/vendor/#getcapabilities-request","title":"GetCapabilities Request","text":""},{"location":"services/wms/vendor/#format","title":"format","text":"

                                The format parameter can be used to request capabilities documents in a certain format. If the requested format is not supported the default format will be used. Refer to the GetCapabilities response for the list of supported formats, which differs according to the WMS version.

                                An example request:

                                http://localhost:8080/geoserver/ows?service=wms&version=1.1.1&request=GetCapabilities&format=text/xml

                                <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<WMT_MS_Capabilities version=\"1.1.1\" updateSequence=\"247\">\n <Capability>\n     <Request>\n         <GetCapabilities>\n             <Format>application/vnd.ogc.wms_xml</Format>\n             <Format>text/xml</Format>\n...\n

                                Note

                                Currently this parameter can only be used to request WMS 1.1.1 capabilities documents encoded in text/xml, if used with other WMS versions or other formats it will have no effect. application/json is not supported.

                                "},{"location":"services/wms/vendor/#namespace","title":"namespace","text":"

                                The namespace parameter causes WMS GetCapabilities responses to be filtered to only contain layers in a particular namespace. The syntax is:

                                namespace=<namespace>\n

                                where <namespace> is the namespace prefix.

                                Warning

                                Using an invalid namespace prefix will not cause an error, but the capabilities document returned will contain no layers, only layer groups.

                                Note

                                This affects the capabilities document only, not other requests. Other WMS operations will still process all layers, even when a namespace is specified.

                                "},{"location":"services/wms/vendor/#rootlayer","title":"rootLayer","text":"

                                The rootLayer parameter can be used to request capabilities documents to include or not a top level root Layer container. By default this top level root is always included as a parent of the configured layers and groups. The default can be changed at the service (WMS) level, or at the layer / group level.

                                Using this parameter it is possible to exclude the default root when the resulting document has a single top element (e.g. a single group with nested children). To do that, use the false value.

                                The parameter can also be used to override what is defined at the WMS or layer / group level. For example if the service is configure to exclude the Root element, we can force it with rootLayer=true.

                                An example request:

                                http://localhost:8080/geoserver/ows?service=wms&version=1.1.1&request=GetCapabilities&rootLayer=false

                                An example with XML POST:

                                <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<ogc:GetCapabilities xmlns:ogc=\"http://www.opengis.net/ows\"\n            xmlns:gml=\"http://www.opengis.net/gml\"\n   version=\"1.1.1\" service=\"WMS\" rootLayer=\"false\">\n</ogc:GetCapabilities>\n
                                "},{"location":"services/wms/vendor/#getmap-request","title":"GetMap Request","text":""},{"location":"services/wms/vendor/#angle","title":"angle","text":"

                                The angle parameter rotates the output map clockwise around its center. The syntax is:

                                angle=<x>\n

                                where <x> is the number of degrees to rotate by.

                                Map rotation is supported in all raster formats, PDF, and SVG when using the Batik producer (which is the default).

                                "},{"location":"services/wms/vendor/#buffer","title":"buffer","text":"

                                The buffer parameter specifies the number of additional border pixels that are used in the GetMap and GetFeatureInfo operations. The syntax is:

                                buffer=<bufferwidth>\n

                                where <bufferwidth> is the width of the buffer in pixels.

                                In the GetMap operation, buffering includes features that lie outside the request bounding box, but whose styling is thick enough to be visible inside the map area.

                                In the GetFeatureInfo operation, buffering creates a \"search radius\" around the location of the request. Feature info is returned for features intersecting the search area. This is useful when working with an OpenLayers map (such as those generated by the Layer Preview page) since it relaxes the need to click precisely on a point for the appropriate feature info to be returned.

                                In both operations GeoServer attempts to compute the buffer value automatically by inspecting the styles for each layer. All active symbolizers are evaluated, and the size of the largest is used (i.e. largest point symbolizer, thickest line symbolizer). Automatic buffer sizing cannot be computed if:

                                • the SLD contains sizes that are specified as feature attribute values
                                • the SLD contains external graphics and does not specify their size explicitly

                                In this event, the following defaults are used:

                                • 0 pixels for GetMap requests
                                • 5 pixels for GetFeatureInfo requests (a different min value can be set via the org.geoserver.wms.featureinfo.minBuffer system variable, e.g., add -Dorg.geoserver.wms.featureinfo.minBuffer=10 to make the min buffer be 10 pixels)

                                If these are not sufficiently large, the explicit parameter can be used.

                                "},{"location":"services/wms/vendor/#cql_filter","title":"cql_filter","text":"

                                The cql_filter parameter is similar to the standard filter parameter, but the filter is expressed using ECQL (Extended Common Query Language). ECQL provides a more compact and readable syntax compared to OGC XML filters. For full details see the ECQL Reference and CQL and ECQL tutorial.

                                If more than one layer is specified in the layers parameter, then a separate filter can be specified for each layer, separated by semicolons. The syntax is:

                                cql_filter=filter1;filter2...\n

                                An example of a simple CQL filter is:

                                cql_filter=INTERSECTS(the_geom,%20POINT%20(-74.817265%2040.5296504))\n
                                "},{"location":"services/wms/vendor/#sortby","title":"sortBy","text":"

                                The sortBy parameter allows to control the order of features/rasters displayed in the map, using the same syntax as WFS 1.0, that is:

                                • &sortBy=att1 A|D,att2 A|D, ... for a single layer request
                                • &sortBy=(att1Layer1 A|D,att2Layer1 A|D, ...)(att1Layer2 A|D,att2Layer2 A|D, ...)... when requesting multiple layers

                                Care should be taken when using it as it has different behavior for raster layers, vector layers, and layer groups. In particular:

                                • | For raster layers, sortBy maps to a \"SORTING\" read parameter that the reader might expose (image mosaic exposes such parameter). | In image mosaic, this causes the first granule found in the sorting will display on top, and then the others will follow. | Thus, to sort a scattered mosaic of satellite images so that the most recent image shows on top, and assuming the time attribute is called ingestion in the mosaic index, the specification will be &sortBy=ingestion D.

                                • | For vector layers, sortBy maps to a sort by clause in the vector data source, and then painting happens using the normal \"painter model\" rules, so the first item returned is painted first, and then all others on top of it. | Thus, to sort a set of event points so that the most recent event is painted on top, and assuming the attribute is called \"date\" in the vector layer, the specification will be &sortBy=date or &sortBy=date A (ascending direction being the default one).

                                • | For layer groups, the sort specification is going to be copied over all internal layers, so the spec has to be valid for all of them, or an error will be reported. | An empty spec can be used for layer groups in this case, for example, layers=theGroup,theLayer&sortBy=(),(date A)

                                "},{"location":"services/wms/vendor/#env","title":"env","text":"

                                The env parameter defines the set of substitution values that can be used in SLD variable substitution. The syntax is:

                                env=param1:value1;param2:value2;...\n

                                See Variable substitution in SLD for more information.

                                "},{"location":"services/wms/vendor/#featureid","title":"featureid","text":"

                                The featureid parameter filters by feature ID, a unique value given to all features. Multiple features can be selected by separating the featureids by comma, as in this example:

                                featureid=states.1,states.45\n
                                "},{"location":"services/wms/vendor/#filter","title":"filter","text":"

                                The WMS specification allows only limited filtering of data. GeoServer enhances the WMS filter capability to match that provided by WFS. The filter parameter can specify a list of OGC XML filters. The list is enclosed in parentheses: ( ). When used in a GET request, the XML tag brackets must be URL-encoded.

                                If more than one layer is specified in the layers parameter then a separate filter can be specified for each layer.

                                An example of an OGC filter encoded in a GET request is:

                                filter=%3CFilter%20xmlns:gml=%22http://www.opengis.net/gml%22%3E%3CIntersects%3E%3CPropertyName%3Ethe_geom%3C/PropertyName%3E%3Cgml:Point%20srsName=%224326%22%3E%3Cgml:coordinates%3E-74.817265,40.5296504%3C/gml:coordinates%3E%3C/gml:Point%3E%3C/Intersects%3E%3C/Filter%3E\n

                                An example of an OGC filter encoding standard 2.0 in a GET request is:

                                filter=%3Cfes%3AFilter%20xmlns%3Axsi%3D%22http%3A%2F%2Fwww.w3.org%2F2001%2FXMLSchema-instance%22%20xmlns%3Agml%3D%22http%3A%2F%2Fwww.opengis.net%2Fgml%2F3.2%22%20xmlns%3Awfs%3D%22http%3A%2F%2Fwww.opengis.net%2Fwfs%22%20xmlns%3D%22http%3A%2F%2Fwww.opengis.net%2Ffes%2F2.0%22%20xmlns%3Afes%3D%22http%3A%2F%2Fwww.opengis.net%2Ffes%2F2.0%22%3E%3Cfes%3APropertyIsLike%20wildCard%3D%22*%22%20singleChar%3D%22.%22%20escapeChar%3D%22!%22%3E%3Cfes%3AValueReference%3ENAME%3C%2Ffes%3AValueReference%3E%3Cfes%3ALiteral%3E*United*%3C%2Ffes%3ALiteral%3E%3C%2Ffes%3APropertyIsLike%3E%3C%2Ffes%3AFilter%3E\n

                                An example of an OGC filter encoding standard 2.0 :

                                <fes:Filter xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xmlns:gml=\"http://www.opengis.net/gml/3.2\" xmlns:wfs=\"http://www.opengis.net/wfs\" xmlns=\"http://www.opengis.net/fes/2.0\" xmlns:fes=\"http://www.opengis.net/fes/2.0\"><fes:PropertyIsLike wildCard=\"*\" singleChar=\".\" escapeChar=\"!\"><fes:ValueReference>NAME</fes:ValueReference><fes:Literal>*United*</fes:Literal></fes:PropertyIsLike></fes:Filter>\n
                                "},{"location":"services/wms/vendor/#format_options","title":"format_options","text":"

                                The format_options is a container for parameters that are format-specific. The syntax is:

                                format_options=param1:value1;param2:value2;...\n

                                The supported format options are:

                                • antialias (values = on, off, text): controls the use of antialiased rendering in raster output.
                                • callback: specifies the callback function name for the jsonp response format (default is parseResponse).
                                • dpi: sets the rendering DPI (dots-per-inch) for raster outputs. The OGC standard output resolution is 90 DPI. If you need to create high resolution images (e.g for printing) it is advisable to request a larger image size and specify a higher DPI. In general, the image size should be increased by a factor equal to targetDPI/90, with the target dpi set in the format options. For example, to print a 100x100 image at 300 DPI request a 333x333 image with the DPI value set to 300: &width=333&height=333&format_options=dpi:300
                                • layout: specifies a layout name to use. Layouts are used to add decorators such as compasses and legends. This capability is discussed further in the WMS Decorations section.
                                • quantizer (values = octree, mediancut): controls the color quantizer used to produce PNG8 images. GeoServer 2.2.0 provides two quantizers, a fast RGB quantizer called octree that does not handle translucency and a slower but more accurate RGBA quantizer called mediancut. By default the first is used on opaque images, whilst the second is enabled if the client asks for a transparent image (transparent=true). This vendor parameter can be used to manually force the usage of a particular quantizer.
                                • timeout: Apply a timeout value for a getMap request. If the timeout is reached, the getMap request is cancelled and an error is returned. The value used for the timeout will be the minimum of this format option and the global WMS timeout defined in the WMS configuration. A value of zero means no timeout.
                                • kmattr (values = true, false): determines whether the KML returned by GeoServer should include clickable attributes or not. This parameter primarily affects Google Earth rendering.
                                • legend (values = true, false): KML may add the legend.
                                • kmscore (values = between 0 to force raster output and 100 to force vector output): parameter sets whether GeoServer should render KML data as vector or raster. This parameter primarily affects Google Earth rendering.
                                • kmltitle: parameter sets the KML title.
                                • kmlrefresh (values = greater than 0 or expires): Force Network Link reload in refresh mode on interval of seconds. When expires is specified client will refresh whenever the time has elapsed specified in cache expiration headers. The caching time may be set in the Layer configuration under Publishing tab setting HTTP Cache Time. This parameter primarily affects Google Earth rendering and is dependent on being respected by the client. Using a second interval is a more reliable choice.
                                • kmlvisible (values = true, false): Indicates whether layers selected will default to enabled or not. Default behavior is enabled. This parameter primarily affects Google Earth rendering.
                                • advancedProjectionHandling (values = true, false): Enable Disable advanced projection handling, if it is enabled in the GUI. If it is disabled in the GUI, this option has no effect.
                                • mapWrapping (values = true, false): Enable Disable continuous map wrapping, if it is enabled in the GUI. If it is disabled in the GUI, this option has no effect. Continuous map wrapping will also be disabled if advancedProjectionHandling is disabled.
                                • decorationsOnly (values = true, false): Disabled by default. When value is true, it allows to get a transparent sized image for the request on which maps are not rendered, but it keeps the decorations applied (if present).
                                "},{"location":"services/wms/vendor/#maxfeatures-and-startindex","title":"maxFeatures and startIndex","text":"

                                The parameters maxFeatures and startIndex can be used together to provide \"paging\" support. Paging is helpful in situations such as KML crawling, where it is desirable to be able to retrieve the map in sections when there are a large number of features.

                                The startindex=n parameter specifies the index from which to start rendering in an ordered list of features. n must be a positive integer.

                                The maxfeatures=n parameter sets a limit on the amount of features rendered. n must be a positive integer. When used with startindex, the features rendered will be the ones starting at the startindex value.

                                Note that not all layers support paging. For a layer to be queried in this way, the underlying feature source must support paging. This is usually the case for databases (such as PostGIS).

                                "},{"location":"services/wms/vendor/#palette","title":"palette","text":"

                                It is sometimes advisable (for speed and bandwidth reasons) to downsample the bit depth of returned maps. The way to do this is to create an image with a limited color palette, and save it in the palettes directory inside your GeoServer Data Directory. It is then possible to specify the palette parameter of the form:

                                palette=<image>\n

                                where <image> is the filename of the palette image (without the extension). To force a web-safe palette, use the syntax palette=safe. For more information see the tutorial on Paletted Images

                                "},{"location":"services/wms/vendor/#propertyname","title":"propertyName","text":"

                                The propertyName parameter specifies which properties are included in the response of the GetFeatureInfo operation. The syntax is the same as in the WFS GetFeature operation. For a request for a single layer the syntax is:

                                propertyName=name1,...,nameN\n

                                For multiple layers the syntax is:

                                propertyName=(nameLayer11,...,nameLayer1N)...(name1LayerN,...,nameNLayerN)\n

                                The nature of the properties depends on the layer type:

                                • For vector layers the names specify the feature attributes.
                                • For raster layers the names specify the bands.
                                • For cascaded WMS layers the names specify the GML properties to be returned by the remote server.
                                "},{"location":"services/wms/vendor/#tiled","title":"tiled","text":"

                                Meta-tiling prevents issues with duplicated labels when using a tiled client such as OpenLayers. When meta-tiling is used, images are rendered and then split into smaller tiles (by default in a 3x3 pattern) before being served. In order for meta-tiling to work, the tile size must be set to 256x256 pixels, and the tiled and tilesorigin parameters must be specified.

                                The tiled parameter controls whether meta-tiling is used. The syntax is:

                                tiled=[true|false]\n

                                To invoke meta-tiling use tiled=true.

                                "},{"location":"services/wms/vendor/#tilesorigin","title":"tilesorigin","text":"

                                The tilesorigin parameter is also required for meta-tiling. The syntax is:

                                tilesorigin=x,y\n

                                where x and y are the coordinates of the lower left corner (the \"origin\") of the tile grid system.

                                "},{"location":"services/wms/vendor/#openlayers-example","title":"OpenLayers example","text":"

                                In OpenLayers, a good way to specify the tilesorigin is to reference the map extents directly.

                                Warning

                                If the map extents are modified dynamically, the tilesorigin of each meta-tiled layer must be updated accordingly.

                                The following code shows how to specify the meta-tiling parameters:

                                var options = {\n    ...\n    maxExtent: new OpenLayers.Bounds(-180, -90, 180, 90),\n    ...\n};\nmap = new OpenLayers.Map('map', options);\n\ntiled = new OpenLayers.Layer.WMS(\n    \"Layer name\", \"http://localhost:8080/geoserver/wms\",\n    {\n        srs: 'EPSG:4326',\n        width: 391,\n        styles: '',\n        height: 550,\n        layers: 'layerName',\n        format: 'image/png',\n        tiled: true,\n        tilesorigin: map.maxExtent.left + ',' + map.maxExtent.bottom\n    },\n    {buffer: 0} \n);\n
                                "},{"location":"services/wms/vendor/#scalemethod","title":"scaleMethod","text":"

                                The scaleMethod parameter controls how the scale denominator is computed by GeoServer The two possible values are:

                                • OGC (default): the scale denominator is computed according to the OGC SLD specification, which

                                  imposes simplified formulas for the sake of interoperability

                                • Accurate: use the full expressions for computing the scale denominator against geographic

                                  data, taking into account the ellipsoidal shape of Earth

                                The two methods tend to return values rather close to each other near the equator, but they do diverge to larger differences as the latitude approaches the poles.

                                "},{"location":"services/wms/vendor/#wms_vendor_parameter_interpolations","title":"interpolations","text":"

                                The interpolations parameter allows choosing a specific resampling (interpolation) method. It can be used in the GetMap operation.

                                If more than one layer is specified in the layers parameter, then a separate interpolation method can be specified for each layer, separated by commas. The syntax is:

                                interpolations=method1,method2,...\n

                                method values can be one of the following:

                                • nearest neighbor
                                • bilinear
                                • bicubic

                                or empty if the default method has to be used for the related layer.

                                The parameter allows to override the global WMS Raster Rendering Options setting (see WMS Settings for more info), as well as the layer specific Default Interpolation Method publishing parameter (see Layers for more info), on a layer by layer basis.

                                "},{"location":"services/wms/vendor/#clip","title":"clip","text":"

                                The clip parameter can be used to clip WMS response using a Polygon mask represented by a valid WKT String.

                                Here are two examples, the first one using WKT, the second using EWKT:

                                clip=POLYGON((-14.50804652396198 55.579454354599356,34.53492222603802 55.579454354599356,34.53492222603802 32.400173313532584,-14.50804652396198 32.400173313532584,-14.50804652396198 55.579454354599356))\nclip=srid=900913;POLYGON ((-1615028.3514525702 7475148.401208023, 3844409.956787858 7475148.401208023, 3844409.956787858 3815954.983140064, -1615028.3514525702 3815954.983140064, -1615028.3514525702 7475148.401208023))\n

                                Note

                                The Axis order of WKT must be East/North regardless of WMS version. Currently this parameter is ignored for layers with Complex features.

                                "},{"location":"services/wms/webadmin/","title":"WMS settings","text":"

                                This page details the configuration options for WMS in the web administration interface.

                                WMS configuration options

                                "},{"location":"services/wms/webadmin/#workspace","title":"Workspace","text":"

                                Select workspace empty to configure global WMS settings.

                                See section on Workspace Services to override settings used by WMS Virtual Services.

                                "},{"location":"services/wms/webadmin/#service-metadata","title":"Service Metadata","text":"

                                For a description of WMS services, see the section on Service Metadata.

                                "},{"location":"services/wms/webadmin/#services_webadmin_wms_raster_options","title":"Root Layer Information","text":"

                                In this section is possible to define a title and an abstract for the root layer in the WMS capabilities. When these are left empty the WMS service title and abstract are used.

                                It is also possible to set the flag Always include Root Layer in capabilities. This is checked by default, but can be unset so that the root layer is included in capabilities only when there is NOT already a single top level Layer element. This can be useful to allow compatibility with some WMS clients that are not happy with the two or more layer tree levels. This default setting can be overridden at the layer or request level.

                                "},{"location":"services/wms/webadmin/#raster-rendering-options","title":"Raster Rendering Options","text":"

                                The Web Map Service Interface Standard (WMS) provides a simple way to request and serve geo-registered map images. During pan and zoom operations, WMS requests generate map images through a variety of raster rendering processes. Such image manipulation is generally called resampling, interpolation, or down-sampling. GeoServer supports three resampling methods that determine how cell values of a raster are outputted. These sampling methods-Nearest Neighbor, Bilinear Interpolation and Bicubic-are available on the Default Interpolation menu.

                                Nearest Neighbor -Uses the center of nearest input cell to determine the value of the output cell. Original values are retained and no new averages are created. Because image values stay exactly the same, rendering is fast but possibly pixelated from sharp edge detail. Nearest neighbor interpolation is recommended for categorical data such as land use classification.

                                Bilinear -Determines the value of the output cell based by sampling the value of the four nearest cells by linear weighting. The closer an input cell, the higher its influence of on the output cell value. Since output values may differ from nearest input, bilinear interpolation is recommended for continuous data like elevation and raw slope values. Bilinear interpolation takes about five times as long as nearest neighbor interpolation.

                                Bicubic -Looks at the sixteen nearest cells and fits a smooth curve through the points to find the output value. Bicubic interpolation may both change the input value as well as place the output value outside of the range of input values. Bicubic interpolation is recommended for smoothing continuous data, but this incurs a processing performance overhead.

                                "},{"location":"services/wms/webadmin/#dimensions-settings","title":"Dimensions settings","text":"

                                The WMS specification mandates the throwing of an InvalidDimensionValue exception when a dimension value is not valid, and the nearest match is not enabled. This is the default behavior of GeoServer starting with version 2.25, while older versions simply ignored the invalid value and returned empty responses.

                                The behavior can be controlled in the Dimension Settings section, with a choice of three possible values:

                                • Use GS version default. Will return an exception if version is greater or equal than 2.25, otherwise will ignore the invalid value.
                                • Return InvalidDimensionValue. Will return an exception on invalid value, unless nearest neighbor match has been enabled for the layer (standard compliant behavior).
                                • Ignore invalid value. Will ignore invalid values and return an empty map/info (legacy behavior).
                                "},{"location":"services/wms/webadmin/#watermark-settings","title":"Watermark Settings","text":"

                                Watermarking is the process of embedding an image into a map. Watermarks are usually used for branding, copyright, and security measures. Watermarks are configured in the WMS watermarks setting section.

                                Enable Watermark -Turns on watermarking. When selected, all maps will render with the same watermark. It is not currently possible to specify watermarking on a per-layer or per-feature basis.

                                Watermark URL -Location of the graphic for the watermark. The graphic can be referenced as an absolute path (e.g., C:\\GeoServer\\watermark.png), a relative one inside GeoServer's data directory (e.g., watermark.png), or a URL (e.g., http://www.example.com/images/watermark.png).

                                Each of these methods have their own advantages and disadvantages. When using an absolute or relative link, GeoServer keeps a cached copy of the graphic in memory, and won't continually link to the original file. This means that if the original file is subsequently deleted, GeoServer won't register it missing until the watermark settings are edited. Using a URL might seem more convenient, but it is more I/O intensive. GeoServer will load the watermark image for every WMS request. Also, should the URL cease to be valid, the layer will not properly display.

                                Watermark Transparency--Determines the opacity level of the watermark. Numbers range between 0 (opaque) and 100 (fully invisible).

                                Watermark Position -Specifies the position of the watermark relative to the WMS request. The nine options indicate which side and corner to place the graphic (top-left, top-center, top-right, etc). The default watermark position is bottom-right. Note that the watermark will always be displayed flush with the boundary. If extra space is required, the graphic itself needs to change.

                                Because each WMS request renders the watermark, a single tiled map positions one watermark relative to the view window while a tiled map positions the watermark for each tile. The only layer specific aspect of watermarking occurs because a single tile map is one WMS request, whereas a tiled map contains many WMS requests. (The latter watermark display resembles Google Maps faint copyright notice in their Satellite imagery.) The following three examples demonstrate watermark position, transparency and tiling display, respectively.

                                Single tile watermark (aligned top-right, transparency=0)

                                Single tile watermark (aligned top-right, transparency=90)

                                Tiled watermark (aligned top-right, transparency=90)

                                "},{"location":"services/wms/webadmin/#svg-options","title":"SVG Options","text":"

                                The GeoServer WMS supports SVG (Scalable Vector Graphics) as an output format. GeoServer currently supports two SVG renderers, available from the SVG producer menu.

                                1. Simple -Simple SVG renderer. It has limited support for SLD styling, but is very fast.
                                2. Batik -Batik renderer (as it uses the Batik SVG Framework). It has full support for SLD styling, but is slower.

                                Enable Anti-aliasing Anti-aliasing is a technique for making edges appear smoother by filling in the edges of an object with pixels that are between the object's color and the background color. Anti-aliasing creates the illusion of smoother lines and smoother selections. Turning on anti-aliasing will generally make maps look nicer, but will increase the size of the images, and will take longer to return. If you are overlaying the anti-aliased map on top of others, beware of using transparencies as the anti-aliasing process mixes with the colors behind and can create a \"halo\" effect.

                                "},{"location":"services/wms/webadmin/#limited-srs-list","title":"Limited SRS list","text":"

                                Some clients can have problems processing the large list of SRS (projections) that GeoServer can support when they are all listed in the capabilities document. It is possible to add a list of needed projections in the Limited SRS List box. This takes the form of a list of EPSG codes separated by commas, e.g. 4326,27700.

                                A limited SRS list

                                The Output bounding box for every supported CRS flag is only respected if a Limited SRS list has been specified.Setting this flag causes the WMS capabilities document to contain a Bounding Box for each supported CRS, for each Layer. Doing this for every CRS in the EPSG database, for each Layer in the catalog, would result in a impractically huge capabilities document.

                                "},{"location":"services/wms/webadmin/#authorization-headers-forwarding-for-remote-slds","title":"Authorization headers forwarding for remote SLDs","text":"

                                A GetMap request may specify the style by referring a remote URL in the SLD parameter. There might be the case that the remote URL require same authorization headers as the current GetMap request. If that's the case a list of allowed style URLs can be specified using newline as separators (URLs might be long). Authorization headers will be only forwarded to a remote URL when it starts with one of the specified URLs.

                                The list of remote URLs being allowed for authorization headers forwarding.

                                "},{"location":"services/wms/webadmin/#advanced-projection-handling-and-map-wrapping","title":"Advanced projection handling and map wrapping","text":"

                                Advanced projection handling is a set of extra \"smarts\" applied while rendering that help getting a good looking map despite the data touching or crossing \"difficult areas\" in selected map projection. This includes, among others:

                                • Cutting the geometries so that they fit within the area of mathematical stability of the projection math, e.g., it will cut any bit at more than 45 degrees west and east from the central meridian of a transverse Mercator projection, or beyond 85 degrees north or south in a Mercator projection
                                • Make sure both \"ends\" of the world get queried for data when a map in polar stereographic is hitting an area that includes the dateline
                                • Ability to optionally preprocess geometries with a densify operation that allows better results when a reprojection operation causes a lot of deformation in the original geometry. Adding more points to the original geometry produces a more precise reprojected one (e.g. straight lines that become curves when reprojected).

                                Along with advanced projection handling there is the possibility of creating a continuous map across the dateline, wrapping the data on the other side of the longitude range, to get a continuous map. This is called continuous map wrapping, and it's enabled in Mercator and Equirectangular (plate carr\u00e9e) projections. This also uses an heuristic to guess direction of lines that cross the dateline (west to east or east to west). The heuristic can be disabled using the Disable dateline wrapping heuristic option.

                                Advanced projection handling and continuous map wrapping functionalities are rather useful, and enabled by default, but the tendency to generate multiple or-ed bounding boxes (to query both sides of the dateline) can cause extreme slowness in certain databases (e.g. Oracle), and some users might simply not like the wrapping output, thus, it's possible to disable both functions in the WMS UI:

                                Continuous map wrapping is disabled if advanced projection handling is disabled.

                                Automatic densification can slow down rendering, so it's disabled by default, but can be enabled using the Enable automatic densification of geometries option.

                                Advanced projection handling can also be disabled using the advancedProjectionHandling Format Option. Similarly, continuous map wrapping can also be disabled using the mapWrapping Format Option, automatic densification can be enabled using the advancedProjectionHandlingDensification Format Option, and the dateline heuristic can be disabled using the disableDatelineWrappingHeuristic Format Option.

                                "},{"location":"services/wms/webadmin/#restricting-mime-types-for-getmap-and-getfeatureinfo-requests","title":"Restricting MIME types for GetMap and GetFeatureInfo requests","text":"

                                GeoServer supports restricting formats for WMS GetMap and WMS GetFeatureInfo requests. The default is to allow all MIME types for both kinds of request.

                                The following figure shows an example for MIME type restriction. The MIME types image/png and text/html;subtype=openlayers are allowed for GetMap requests, the MIME types text/html and text/plain are allowed for GetFeatureInfo requests. A GetMap/GetFeatureInfo request with a MIME type not allowed will result in a service exception reporting the error.

                                Note

                                Activating MIME type restriction and not allowing at least one MIME type disables the particular request.

                                "},{"location":"services/wms/webadmin/#disabling-usage-of-dynamic-styling-in-getmap-getfeatureinfo-and-getlegendgraphic-requests","title":"Disabling usage of dynamic styling in GetMap, GetFeatureInfo and GetLegendGraphic requests","text":"

                                Dynamic styles can be applied to layers in GetMap, GetFeatureInfo and GetLegendGraphic requests using the SLD or SLD_BODY parameters for GET requests.

                                In addition, GetMap POST requests can contain inline style definition for layers.

                                The usage of dynamic styling can be restricted on a global or per virtual service basis using the Dynamic styling section.

                                When the flag is checked, a GetMap/GetFeatureInfo/GetLegendGraphic request with a dynamic style will result in a service exception reporting the error.

                                "},{"location":"services/wms/webadmin/#disabling-getfeatureinfo-requests-results-reprojection","title":"Disabling GetFeatureInfo requests results reprojection","text":"

                                By default GetFeatureInfo results are reproject to the map coordinate reference system. This behavior can be deactivated on a global or per virtual service basis in the GetFeatureInfo results reprojection section.

                                When the flag is checked, GetFeatureInfo requests results will not be reprojected and will instead used the layer coordinate reference system.

                                "},{"location":"services/wms/webadmin/#services_webadmin_wms_featureinfo_transformation","title":"Disabling GetFeatureInfo requests results transformation","text":"

                                By default GetFeatureInfo results are determined from the output after evaluating rendering transformation on the layer data. This behavior can be changed only for raster sources (i.e., raster-to-raster and raster-to-vector transformations). This behavior can be deactivated on a global or per virtual service basis in the GetFeatureInfo results transformation section. This setting can be overridden for individual FeatureTypeStyle elements using the transformFeatureInfo SLD vendor option (See section Rendering Transformations).

                                When the flag is checked, GetFeatureInfo requests results will not be transformed and will instead use the raw, underlying raster data.

                                Note

                                WMS Specification

                                While this option provides a way to revert to the behavior that was used in older GeoServer versions (<2.21.0), the WMS specification states that \"The GetFeatureInfo operation is designed to provide clients of a WMS with more information about features in the pictures of maps that were returned by previous Map requests\" so using this option might not be the behavior as the specification intended it.

                                "},{"location":"services/wms/webadmin/#enabling-getfeatureinfo-requests-results-html-auto-escaping","title":"Enabling GetFeatureInfo requests results HTML auto-escaping","text":"

                                By default GetFeatureInfo results are printed in the HTML templates without any automatic escaping, which could result in incorrect and potentially malicious results. This behavior can be activated on a global or per virtual service basis in the GetFeatureInfo results auto-escaping section.

                                When the flag is checked, values that are printed in the HTML templates for GetFeatureInfo requests results will be automatically escaped. The default FreeMarker templates can be overridden to enable or disable auto-escaping on a per template, per block or per value basis.

                                Note

                                Auto-escaping is forced to be enabled by default and that property must be disabled for this setting to have any effect. See the FreeMarker Template Auto-escaping page for instructions.

                                "},{"location":"services/wms/webadmin/#setting-remote-style-max-connection-and-request-time","title":"Setting Remote Style max connection and request time","text":"

                                Remote styles max request time and connection timeout can be configured in milliseconds.

                                Timeout in milliseconds -The max connection timeout in milliseconds for remote style requests.

                                Max request time in milliseconds -The max request time limit in milliseconds for remote style requests.

                                "},{"location":"services/wms/webadmin/#mark-factory-precedence","title":"Mark Factory Precedence","text":"

                                Mark factories can be filtered and ordered during the rendering execution. This makes room to optimize the rendering phase by omitting unused mark factories and prioritizing the fastest ones.

                                Enable Mark Factory Precedence -Enables the mark factory precedence setup.

                                Mark Factory Precedence setup -The allowed mark factories to use and its execution order.

                                "},{"location":"services/wms/webadmin/#i18n-settings","title":"i18n Settings","text":"

                                Select default language for WMS Service.

                                Default language

                                See Internationalization (i18n) section for a how this setting is used.

                                "},{"location":"services/wms/get_legend_graphic/","title":"GetLegendGraphic","text":"

                                This chapter describes whether to use the GetLegendGraphics request. The SLD Specifications 1.0.0 gives a good description about GetLegendGraphic requests:

                                The GetLegendGraphic operation itself is optional for an SLD-enabled WMS. It provides a general mechanism for acquiring legend symbols, beyond the LegendURL reference of WMS Capabilities. Servers supporting the GetLegendGraphic call might code LegendURL references as GetLegendGraphic for interface consistency. Vendor-specific parameters may be added to GetLegendGraphic requests and all of the usual OGC-interface options and rules apply. No XML-POST method for GetLegendGraphic is presently defined.

                                Here is an example invocation:

                                http://localhost:8080/geoserver/wms?REQUEST=GetLegendGraphic&VERSION=1.0.0&FORMAT=image/png&WIDTH=20&HEIGHT=20&LAYER=topp:states\n

                                which would produce four 20x20 icons that graphically represent the rules of the default style of the topp:states layer.

                                Sample legend

                                The following table lists the whole set of GetLegendGraphic parameters that can be used.

                                Parameter Required Description

                                REQUEST Required Value must be \"GetLegendGraphic\".

                                LAYER Required Layer for which to produce legend graphic.

                                STYLE Optional Style of layer for which to produce legend graphic. If not present, the default style is selected. The style may be any valid style available for a layer, including non-SLD internally-defined styles.

                                FEATURETYPE Optional Feature type for which to produce the legend graphic. This is not needed if the layer has only a single feature type.

                                RULE Optional Rule of style to produce legend graphic for, if applicable. In the case that a style has multiple rules but no specific rule is selected, then the map server is obligated to produce a graphic that is representative of all of the rules of the style.

                                SCALE Optional In the case that a RULE is not specified for a style, this parameter may assist the server in selecting a more appropriate representative graphic by eliminating internal rules that are out-of-scope. This value is a standardized scale denominator, defined in Section 10.2. Specifying the scale will also make the symbolizers using Unit Of Measure resize according to the specified scale.

                                SLD Optional This parameter specifies a reference to an external SLD document. It works in the same way as the SLD= parameter of the WMS GetMap operation.

                                SLD_BODY Optional This parameter allows an SLD document to be included directly in an HTTP-GET request. It works in the same way as the SLD_BODY= parameter of the WMS GetMap operation.

                                FORMAT Required This gives the MIME type of the file format in which to return the legend graphic. Allowed values are the same as for the FORMAT= parameter of the WMS GetMap request.

                                WIDTH Optional This gives a hint for the width of the returned graphic in pixels. Vector-graphics can use this value as a hint for the level of detail to include.

                                HEIGHT Optional This gives a hint for the height of the returned graphic in pixels.

                                EXCEPTIONS Optional This gives the MIME type of the format in which to return exceptions. Allowed values are the same as for the EXCEPTIONS= parameter of the WMS GetMap request.

                                LANGUAGE Optional Allows setting labels language for style titles and rules titles; needs a correctly localized SLD to work properly; if labels are not available in the requested language, the default text will be used; look at i18N in SLD for further details.

                                "},{"location":"services/wms/get_legend_graphic/#get_legend_graphic_options","title":"Controlling legend appearance with LEGEND_OPTIONS","text":"

                                GeoServer allows finer control over the legend appearance via the vendor parameter LEGEND_OPTIONS. The general format of LEGEND_OPTIONS is the same as FORMAT_OPTIONS, that is:

                                ...&LEGEND_OPTIONS=key1:v1;key2:v2;...;keyn:vn\n

                                Here is a description of the various parameters that can be used in LEGEND_OPTIONS:

                                • fontName (string) the name of the font to be used when generating rule titles. The font must be available on the server
                                • fontStyle (string) can be set to italic or bold to control the text style. Other combinations are not allowed right now but we could implement that as well.
                                • fontSize (integer) allows us to set the Font size for the various text elements. Notice that default size is 12.
                                • fontColor (hex) allows us to set the color for the text of rules and labels (see above for recommendation on how to create values). Values are expressed in 0xRRGGBB format
                                • fontAntiAliasing (true/false) when true enables antialiasing for rule titles
                                • bgColor (hex) background color for the generated legend, values are expressed in 0xRRGGBB format
                                • dpi (integer) sets the DPI for the current request, in the same way as it is supported by GetMap. Setting a DPI larger than 91 (the default) makes all fonts, symbols and line widths grow without changing the current scale, making it possible to get a high resolution version of the legend suitable for inclusion in printouts
                                • forceLabels \"on\" means labels will always be drawn, even if only one rule is available. \"off\" means labels will never be drawn, even if multiple rules are available. Off by default.
                                • forceTitles \"off\" means layer titles will not be drawn for layer groups. On by default.
                                • labelMargin margin (in pixels) to use between icons and labels.
                                • layout sets icons layout to be vertical (default) or horizontal.
                                • columnheight enables multicolumn layout when layout is vertical. Each column height is limited by the columnheight value (in pixels).
                                • rowwidth enables multirow layout when layout is horizontal. Each row width is limited by the rowwidth value (in pixels).
                                • columns enables multicolumn layout when layout is vertical. The value is the maximum columns number of legend. The rows used are equal to the next greater integer of /.
                                • rows enables multirow layout when layout is horizontal. The value is the maximum rows number of legend. The columns used are equal to the next greater integer of /.
                                • grouplayout Orientation of groups of layer, possible values are horizontal and vertical (default if not specified).
                                • countMatched When set to true, adds at the end of each label the number of features matching that rule in the current map. Requires extra parameters, see details in the dedicated section.
                                • hideEmptyRules When set to true hides rules that are not matching any feature.
                                • wrap When set to true word wraps long legend labels, leading to taller legends but less wide ones.
                                • wrap_limit when set, it wraps the legend label with the specified number of pixels.
                                • Here is a sample request sporting most the options:

                                  http://localhost:8080/geoserver/wms?REQUEST=GetLegendGraphic&VERSION=1.0.0&FORMAT=image/png&WIDTH=20&HEIGHT=20&LAYER=topp:states&legend_options=fontName:Times%20New%20Roman;fontAntiAliasing:true;fontColor:0x000033;fontSize:14;bgColor:0xFFFFEE;dpi:180\n

                                  Using LEGEND_OPTIONS to control the output

                                  "},{"location":"services/wms/get_legend_graphic/#controlling-legend-layout","title":"Controlling legend layout","text":"

                                  A set of LEGEND_OPTIONS keys are used to control icons layout in the produced legend images. In particular, a vertical or horizontal layout can be chosen.

                                  Multi column or multi row layouts are possible, and are controlled by the columnheight / rowwidth options (to limit each column / row size) or by the columns / rows options (to fix the # of columns / rows to be used).

                                  Both columnheight / columns and rowwidth / rows can be used to limit the whole size of the produced image (some icons are skipped if they do not fit into the given limits).

                                  In addition, orientation of legends in a layergroup can be configured using the grouplayout option.

                                  "},{"location":"services/wms/get_legend_graphic/#raster-legends-explained","title":"Raster Legends Explained","text":"

                                  This chapter aims to briefly describe the work that I have performed in order to support legends for raster data that draw information taken from the various bits of the SLD 1.0 RasterSymbolizer element. Recall, that up to now there was no way to create legends for raster data, therefore we have tried to fill the gap by providing an implementation of the getLegendGraphic request that would work with the ColorMap element of the SLD 1.0 RasterSymbolizer. Notice that some \"debug\" info about the style, like colormap type and band used are printed out as well.

                                  "},{"location":"services/wms/get_legend_graphic/#whats-a-raster-legend","title":"What's a raster legend","text":"

                                  Here below I have drawn the structure of a typical legend, where some elements of interests are parameterized.

                                  The structure of a typical legend

                                  Take as an instance one of the SLD files attached to this page, each row in the above table draws its essence from the ColorMapEntry element as shown here below:

                                  <ColorMapEntry color=\"#732600\" quantity=\"9888\" opacity=\"1.0\" label=\"<-70 mm\"/>\n

                                  The producer for the raster legend will make use of this elements in order to build the legend, with this in mind, notice that:

                                  • the width of the Color element is driven by the requested width for the GetLegendGraphic request
                                  • the width and height of label and rules is computed accordingly to the used Font and Font size for the prepared text (no new line management for the moment)
                                  • the height of the Color element is driven by the requested width for the GetLegendGraphic request, but notice that for ramps we expand this a little since the goal is to turn the various Color elements into a single long strip
                                  • the height of each row is set to the maximum height of the single elements
                                  • the width of each row is set to the sum of the width of the various elements plus the various paddings
                                  • dx,dy the spaces between elements and rows are set to the 15% of the requested width and height. Notice that dy is ignored for the colormaps of type ramp since they must create a continuous color strip.
                                  • absoluteMargins true/false, used to change the Unit of Measure of dx from percentage (when false) to a fixed number of pixels (when true).
                                  • mx,my the margins from the border of the legends are set to the 1.5% of the total size of the legend

                                  In conclusion, here below I am adding an image of a sample legend with all the various options at work. The request that generated it is the following:

                                  http://localhost:8081/geoserver/wms?REQUEST=GetLegendGraphic&VERSION=1.0.0&FORMAT=image/png&WIDTH=100&HEIGHT=20&LAYER=it.geosolutions:di08031_da&LEGEND_OPTIONS=forceRule:True;dx:0.2;dy:0.2;mx:0.2;my:0.2;fontStyle:bold;borderColor:0000ff;border:true;fontColor:ff0000;fontSize:18\n

                                  Do not worry if it seems like something written in ancient dead language, I am going to explain the various params here below.

                                  Example of a raster legend

                                  "},{"location":"services/wms/get_legend_graphic/#raster-legends-types","title":"Raster legends' types","text":"

                                  As you may know (well, actually you might not since I never wrote any real docs about the RasterSymbolizer work I did) GeoServer supports three types of ColorMaps:

                                  • ramp this is what SLD 1.0 dictates, which means a linear interpolation weighted on values between the colors of the various ColorMapEntries.
                                  • values this is an extension that allows link quantities to colors as specified by the ColorMapEntries quantities. Values not specified are translated into transparent pixels.
                                  • classes this is an extension that allows pure classifications based on intervals created from the ColorMapEntries quantities. Values not specified are translated into transparent pixels.

                                  Here below I am going to list various examples that use the attached styles on a rainfall floating point geotiff.

                                  "},{"location":"services/wms/get_legend_graphic/#colormap-type-is-values","title":"ColorMap type is VALUES","text":"

                                  Refer to the SLD rainfall.sld in attachment.

                                  Raster legend - VALUES type

                                  "},{"location":"services/wms/get_legend_graphic/#colormap-type-is-classes","title":"ColorMap type is CLASSES","text":"

                                  Refer to the SLD rainfall_classes.sld in attachment.

                                  Raster legend - CLASSES type

                                  "},{"location":"services/wms/get_legend_graphic/#colormap-type-is-ramp","title":"ColorMap type is RAMP","text":"

                                  Refer to the SLD rainfall_classes.sld in attachment. Notice that the first legend shows the default border behavior while the second has been forced to draw a border for the breakpoint color of the colormap entry quantity described by the rendered text. Notice that each color element has a part that show the fixed color from the colormap entry it depicts (the lowest part of it, the one that has been outlined by the border in the second legend below) while the upper part of the element has a gradient that connects each element to the previous one to point out the fact that we are using linear interpolation.

                                  Raster legend - RAMP type

                                  "},{"location":"services/wms/get_legend_graphic/#the-various-control-parameters-and-how-to-set-them","title":"The various control parameters and how to set them","text":"

                                  I am now going to briefly explain the various parameters that we can use to control the layout and content of the legend. A request that puts all the various options is shown here:

                                  http://localhost:8081/geoserver/wms?REQUEST=GetLegendGraphic&VERSION=1.0.0&FORMAT=image/png&WIDTH=100&HEIGHT=20&LAYER=it.geosolutions:di08031_da&LEGEND_OPTIONS=forceRule:True;dx:0.2;dy:0.2;mx:0.2;my:0.2;fontStyle:bold;borderColor:0000ff;border:true;fontColor:ff0000;fontSize:18\n

                                  Let's now examine all the interesting elements, one by one. Notice that I am not going to discuss the mechanics of the GetLegendGraphic operation, for that you may want to refer to the SLD 1.0 spec, my goal is to briefly discuss the LEGEND_OPTIONS parameter.

                                  • forceRule (boolean) by default rules for a ColorMapEntry are not drawn to keep the legend small and compact, unless there are no labels at all. You can change this behaviour by setting this parameter to true.
                                  • dx,dy,mx,my (double) can be used to set the margin and the buffers between elements
                                  • border (boolean) activates or deactivates the border on the color elements in order to make the separations clearer. Notice that I decided to always have a line that would split the various color elements for the ramp type of colormap.
                                  • borderColor (hex) allows us to set the color for the border in 0xRRGGBB format
                                  "},{"location":"services/wms/get_legend_graphic/#cql-expressions-and-env","title":"CQL Expressions and ENV","text":"

                                  If CQL expressions are used in ColorMapEntry attributes (see here) to create a dynamic color map taking values from ENV, the same ENV parameters used for GetMap can be given to GetLegendGraphic to get the desired legend entries.

                                  "},{"location":"services/wms/get_legend_graphic/#content-dependent","title":"Content dependent legends","text":"

                                  GeoServer allows building content dependent legend, that is, legends whose contents depend on the currently displayed map. In order to support it the GetLegendGraphic call needs the following extra parameters:

                                  • BBOX
                                  • SRS or CRS (depending on the WMS version, SRS for 1.1.1 and CRS for 1.3.0)
                                  • SRCWIDTH and SRCHEIGHT, the size of the reference map (width and height already have a different meaning in GetLegendGraphic)

                                  Other parameters can also be added to better match the GetMap request, for example, it is recommended to mirror filtering vendor parameters such as, for example, CQL_FILTER,FILTER,FEATUREID,TIME,ELEVATION.

                                  Content dependent evaluation is enabled via the following LEGEND_OPTIONS parameters:

                                  • countMatched: adds the number of features matching the particular rule at the end of the rule label (requires visible labels to work). Applicable only to vector layers.
                                  • hideEmptyRules: hides rules that are not matching any feature. Applicable only if countMatched is true.

                                  For example, let's assume the following layout is added to GeoServer (legend.xml to be placed in GEOSERVER_DATA_DIR/layouts):

                                  <layout>\n    <decoration type=\"legend\" affinity=\"top,right\" offset=\"0,0\" size=\"auto\"/>\n</layout>\n

                                  This will make a legend appear in the GetMap response. The following preview request uses the layout to embed a legend and activates feature counting in it:

                                  http://localhost:8080/geoserver/topp/wms?service=WMS&version=1.1.0&request=GetMap&layers=topp:states&styles=&bbox=-124.73142200000001,24.955967,-66.969849,49.371735&width=768&height=330&srs=EPSG:4326&format=application/openlayers&format_options=layout:legend&legend_options=countMatched:true;fontAntiAliasing:true\n

                                  The result will look as follows:

                                  Embedded legend, full map

                                  Embedded legend, four states

                                  Embedded legend, single state

                                  Embedded legend, single state, hide empty rules

                                  The same can be achieved using a stand-alone GetLegendGraphic request:

                                  http://localhost:8080/geoserver/topp/wms?service=WMS&version=1.1.0&request=GetLegendGraphic&width=20&height=20&layer=topp:states&bbox=-124.73142200000001,24.955967,-66.969849,49.371735&srcwidth=768&srcheight=330&srs=EPSG:4326&format=image/png&legend_options=countMatched:true;fontAntiAliasing:true\n

                                  Direct legend request

                                  Or hide the empty rules using a stand-alone GetLegendGraphic request:

                                  http://localhost:8080/geoserver/topp/wms?service=WMS&version=1.1.0&request=GetLegendGraphic&width=20&height=20&layer=topp:states&bbox=-101.0028076171875,31.025390625,-96.7840576171875,32.838134765625&srcwidth=768&srcheight=330&srs=EPSG:4326&format=image/png&legend_options=countMatched:true;fontAntiAliasing:true;hideEmptyRules:true\n

                                  Direct legend request

                                  "},{"location":"services/wms/get_legend_graphic/#json-output-format","title":"JSON Output Format","text":"

                                  Since version 2.15.0 it has been possible to use application/json as an output format in GetLegendGraphic requests. This allows a JSON aware client to receive a JSON representation of the legend graphic to use for its own rendering requirements.

                                  A simple http request can be used:

                                  http://localhost:9000/geoserver/wms?service=WMS&version=1.1.0&request=GetLegendGraphic&layer=topp:states&format=application/json\n

                                  Which returns a JSON response:

                                  {\"Legend\": [{\n  \"layerName\": \"states\",\n  \"title\": \"USA Population\",\n  \"rules\":   [\n        {\n      \"title\": \"< 2M\",\n      \"filter\": \"[PERSONS < '2000000']\",\n      \"symbolizers\": [{\"Polygon\":       {\n        \"fill\": \"#4DFF4D\",\n        \"fill-opacity\": \"0.7\"\n      }}]\n    },\n        {\n      \"title\": \"2M - 4M\",\n      \"filter\": \"[PERSONS BETWEEN '2000000' AND '4000000']\",\n      \"symbolizers\": [{\"Polygon\":       {\n        \"fill\": \"#FF4D4D\",\n        \"fill-opacity\": \"0.7\"\n      }}]\n    },\n        {\n      \"title\": \"> 4M\",\n      \"filter\": \"[PERSONS > '4000000']\",\n      \"symbolizers\": [{\"Polygon\":       {\n        \"fill\": \"#4D4DFF\",\n        \"fill-opacity\": \"0.7\"\n      }}]\n    },\n        {\n      \"title\": \"Boundary\",\n      \"symbolizers\":       [\n        {\"Line\":         {\n          \"stroke\": \"#000000\",\n          \"stroke-width\": \"0.2\",\n          \"stroke-opacity\": \"1\",\n          \"stroke-linecap\": \"butt\",\n          \"stroke-linejoin\": \"miter\"\n        }},\n        {\"Text\":         {\n          \"label\": \"[STATE_ABBR]\",\n          \"fonts\": [          {\n            \"font-family\": [\"Times New Roman\"],\n            \"font-style\": \"Normal\",\n            \"font-weight\": \"normal\",\n            \"font-size\": \"14\"\n          }],\n          \"label-placement\":           {\n            \"x-anchor\": \"0.5\",\n            \"y-anchor\": \"0.5\",\n            \"rotation\": \"0.0\"\n          }\n        }}\n      ]\n    }\n  ]\n}]}\n

                                  This JSON contains an array of Legends (one for each layer requested) and each legend contains some metadata about the legend and an array of rule objects for each rule within the feature type of the style. Each rule contains the metadata associated with the rule, any filter element and an array of symbolizer objects.

                                  "},{"location":"services/wms/get_legend_graphic/#filters-and-expressions","title":"Filters and Expressions","text":"

                                  Filters are encoded using ECQL, a rule with an ElseFilter has an element \"ElseFilter\" set to the value \"true\". Expressions are also encoded in ECQL (wrapped in []) when encountered in the style.

                                  "},{"location":"services/wms/get_legend_graphic/#symbolizers","title":"Symbolizers","text":"
                                  • PointSymbolizer

                                    A point symbolizer will be represented as a series of elements containing metadata and an array of graphics symbols (see here) , these can be well known marks or external graphics. The point symbolizer also provides an \"URL\" element which allows a client to make a request back to GeoServer to fetch a PNG image of the point symbol.

                                    {\"Point\":     {\n    \"title\": \"title\",\n    \"abstract\": \"abstract\",\n    \"url\": \"http://localhost:9000/geoserver/kml/icon/capitals?0.0.0=\",\n    \"size\": \"6\",\n    \"opacity\": \"1.0\",\n    \"rotation\": \"0.0\",\n    \"graphics\": [      {\n      \"mark\": \"circle\",\n      \"fill\": \"#FFFFFF\",\n      \"fill-opacity\": \"1.0\",\n      \"stroke\": \"#000000\",\n      \"stroke-width\": \"2\",\n      \"stroke-opacity\": \"1\",\n      \"stroke-linecap\": \"butt\",\n      \"stroke-linejoin\": \"miter\"\n    }]}}\n
                                  • LineSymbolizer

                                    A line symbolizer is represented as a list of metadata elements and the stroke parameters <sld_reference_linesymbolizer_css>, it is possible for there to be a graphic-stroke element too.

                                    {\"Line\":     {\n  \"stroke\": \"#AA3333\",\n  \"stroke-width\": \"2\",\n  \"stroke-opacity\": \"1\",\n  \"stroke-linecap\": \"butt\",\n  \"stroke-linejoin\": \"miter\"\n}}\n\n\n{\"Line\":       {\n    \"graphic-stroke\":         {\n      \"url\": \"http://local-test:8080/geoserver/kml/icon/Default Styler\",\n      \"size\": \"6\",\n      \"opacity\": \"0.4\",\n      \"rotation\": \"[(rotation*-1)]\",\n      \"graphics\": [          {\n        \"mark\": \"square\",\n        \"fill\": \"#FFFF00\",\n        \"fill-opacity\": \"1.0\"\n      }]\n    },\n    \"stroke-opacity\": \"1\",\n    \"stroke-linecap\": \"butt\",\n    \"stroke-linejoin\": \"miter\",\n    \"perpendicular-offset\": \"10\"\n  }}  \n
                                  • PolygonSymbolizer

                                    A polygon symbolizer contains stroke parameters <sld_reference_linesymbolizer_css> and fill parameters <sld_reference_fill>.

                                    {\"Polygon\":       {\n  \"stroke\": \"#000000\",\n  \"stroke-width\": \"0.5\",\n  \"stroke-opacity\": \"1\",\n  \"stroke-linecap\": \"butt\",\n  \"stroke-linejoin\": \"miter\",\n  \"fill\": \"#0099CC\",\n  \"fill-opacity\": \"1.0\"\n}}\n

                                    Or a graphic stroke and/or a graphic fill (as described above).

                                    {\"Polygon\":       {\n  \"graphic-stroke\":         {\n    \"url\": \"http://local-test:8080/geoserver/kml/icon/Default Styler\",\n    \"size\": \"6\",\n    \"opacity\": \"0.4\",\n    \"rotation\": \"[(rotation*-1)]\",\n    \"graphics\": [          {\n      \"mark\": \"square\",\n      \"fill\": \"#FFFF00\",\n      \"fill-opacity\": \"1.0\"\n    }]\n  },\n  \"stroke-opacity\": \"1\",\n  \"stroke-linecap\": \"butt\",\n  \"stroke-linejoin\": \"miter\",\n  \"graphic-fill\":         {\n    \"url\": \"http://local-test:8080/geoserver/kml/icon/Default Styler\",\n    \"size\": \"4\",\n    \"opacity\": \"0.4\",\n    \"rotation\": \"[(rotation*-1)]\",\n    \"graphics\": [          {\n      \"mark\": \"circle\",\n      \"fill\": \"#FFFFFF\",\n      \"fill-opacity\": \"1.0\"\n    }]\n  }}}\n
                                  • RasterSymbolizer

                                    Raster symbolizers contain a colormap with an array of entries, each entry contains a label, quantity and color element.

                                    {\"Raster\":   {\n  \"colormap\":     {\n    \"entries\":       [\n              {\n        \"label\": \"values\",\n        \"quantity\": \"0\",\n        \"color\": \"#AAFFAA\"\n      },\n              {\n        \"quantity\": \"1000\",\n        \"color\": \"#00FF00\"\n      },\n              {\n        \"label\": \"values\",\n        \"quantity\": \"1200\",\n        \"color\": \"#FFFF00\"\n      },\n              {\n        \"label\": \"values\",\n        \"quantity\": \"1400\",\n        \"color\": \"#FF7F00\"\n      },\n              {\n        \"label\": \"values\",\n        \"quantity\": \"1600\",\n        \"color\": \"#BF7F3F\"\n      },\n              {\n        \"label\": \"values\",\n        \"quantity\": \"2000\",\n        \"color\": \"#000000\"\n      }\n    ],\n    \"type\": \"ramp\"\n  },\n  \"opacity\": \"1.0\"\n}}\n
                                  • TextSymbolizer

                                    A text symbolizer contains a label expression, followed by an array of fonts and a label-placement object containing details of how the label is placed.

                                    {\"Text\":         {\n    \"label\": \"[STATE_ABBR]\",\n    \"fonts\": [          {\n        \"font-family\": [\"Times New Roman\"],\n        \"font-style\": \"Normal\",\n        \"font-weight\": \"normal\",\n        \"font-size\": \"14\"\n    }],\n    \"label-placement\":           {\n        \"x-anchor\": \"0.5\",\n        \"y-anchor\": \"0.5\",\n        \"rotation\": \"0.0\"\n    }\n}}\n
                                  "},{"location":"services/wms/get_legend_graphic/#vendor-options","title":"Vendor Options","text":"

                                  In any case where one or more vendor options is included in the symbolizer there will be a vendor-options element included in the output. This object will include one line for each vendor option.

                                  \"vendor-options\": {\n  \"labelAllGroup\": \"true\",\n  \"spaceAround\": \"10\",\n  \"followLine\": \"true\",\n  \"autoWrap\": \"50\"\n}\n
                                  "},{"location":"services/wms/googleearth/","title":"Google Earth","text":"

                                  This section contains information on Google Earth support in GeoServer.

                                  Google Earth is a 3-D virtual globe program. A free download from Google, it allows the user to virtually view, pan, and fly around Earth imagery. The imagery on Google Earth is obtained from a variety of sources, mainly from commercial satellite and aerial photography providers.

                                  Google Earth recognizes a markup language called KML (Keyhole Markup Language) for data exchange. GeoServer integrates with Google Earth by supporting KML as a native output format. Any data configured to be served by GeoServer is thus able to take advantage of the full visualization capabilities of Google Earth.

                                  • Overview
                                  • Quickstart
                                  • KML Styling
                                  • Tutorials
                                  • Features
                                  "},{"location":"services/wms/googleearth/kmlstyling/","title":"KML Styling","text":""},{"location":"services/wms/googleearth/kmlstyling/#introduction","title":"Introduction","text":"

                                  Keyhole Markup Langauge (KML), when created and output by GeoServer, is styled using Styled Layer Descriptors (SLD). This is the same approach used to style standard WMS output formats, but is a bit different from how Google Earth is normally styled, behaving more like Cascading Style Sheets (CSS). The style of the map is specified in the SLD file as a series of rules, and then the data matching those rules is styled appropriately in the KML output. For those unfamiliar with SLD, a good place to start is the Introduction to SLD. The remainder of this guide contains information about how to construct SLD documents in order to impact the look of KML produced by GeoServer.

                                  "},{"location":"services/wms/googleearth/kmlstyling/#contents","title":"Contents","text":"

                                  SLD Generation from CSS

                                  Creating SLD by hand

                                  SLD Structure

                                  Points

                                  Lines

                                  Polygons

                                  Text Labels

                                  Descriptions

                                  "},{"location":"services/wms/googleearth/kmlstyling/#kml-styling-basic","title":"SLD Generation from CSS","text":"

                                  The CSS extension provides the facility to generate SLD files using a lightweight \"Cascading Style Sheet\" syntax. The CSS GUI provides a live map preview as you are editing your style in addition to an attribute reference for the current layer.

                                  The generated styles will work seamlessly with KML output from GeoServer.

                                  "},{"location":"services/wms/googleearth/kmlstyling/#kml-styling-sld-hand","title":"Creating SLD by hand","text":"

                                  One can edit the SLD files directly instead of using the CSS extension. For the most complete exploration of editing SLDs see the Styling section. The examples below show how some of the basic styles show up in Google Earth.

                                  "},{"location":"services/wms/googleearth/kmlstyling/#kml-styling-sld-structure","title":"SLD Structure","text":"

                                  The following is a skeleton of a SLD document. It can be used as a base on which to expand upon to create more interesting and complicated styles.

                                  <StyledLayerDescriptor version=\"1.0.0\"\n   xsi:schemaLocation=\"http://www.opengis.net/sld StyledLayerDescriptor.xsd\"\n   xmlns=\"http://www.opengis.net/sld\"\n   xmlns:ogc=\"http://www.opengis.net/ogc\"\n   xmlns:xlink=\"http://www.w3.org/1999/xlink\"\n   xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\">\n   <NamedLayer>\n      <Name>Default Line</Name>\n      <UserStyle>\n         <Title>My Style</Title>\n         <Abstract>A style</Abstract>\n         <FeatureTypeStyle>\n            <Rule>\n\n                  <!-- symbolizers go here -->\n\n            </Rule>\n         </FeatureTypeStyle>\n      </UserStyle>\n   </NamedLayer>\n</StyledLayerDescriptor>\n

                                  Figure 3: Basic SLD structure

                                  In order to test the code snippets in this document, create an SLD with the content as shown in Figure 3, and then add the specific code you wish to test in the space that says <!-- symbolizers go here -->. To view, edit, or add SLD files to GeoServer, navigate to Config -> Data -> Styles.

                                  "},{"location":"services/wms/googleearth/kmlstyling/#kml-styling-points","title":"Points","text":"

                                  In SLD, styles for points are specified via a PointSymbolizer. An empty PointSymbolizer element will result in a default KML style:

                                  <PointSymbolizer>\n</PointSymbolizer>\n

                                  Figure 4: Default point

                                  Three aspects of points that can be specified are color, opacity, and the icon.

                                  "},{"location":"services/wms/googleearth/kmlstyling/#point-color","title":"Point Color","text":"

                                  The color of a point is specified with a CssParameter element and a fill attribute. The color is specified as a six digit hexadecimal code.

                                  <PointSymbolizer>\n   <Graphic>\n      <Mark>\n         <Fill>\n            <CssParameter name=\"fill\">#ff0000</CssParameter>\n         </Fill>\n      </Mark>\n   </Graphic>\n</PointSymbolizer>\n

                                  Figure 5: Setting the point color (#ff0000 = 100% red)

                                  "},{"location":"services/wms/googleearth/kmlstyling/#point-opacity","title":"Point Opacity","text":"

                                  The opacity of a point is specified with a CssParameter element and a fill-opacity attribute. The opacity is specified as a floating point number between 0 and 1, with 0 being completely transparent, and 1 being completely opaque.

                                  <PointSymbolizer>\n   <Graphic>\n      <Mark>\n         <Fill>\n            <CssParameter name=\"fill-opacity\">0.5</CssParameter>\n         </Fill>\n      </Mark>\n   </Graphic>\n</PointSymbolizer>\n

                                  Figure 6: Setting the point opacity (0.5 = 50% opaque)

                                  "},{"location":"services/wms/googleearth/kmlstyling/#point-icon","title":"Point Icon","text":"

                                  An icon different from the default can be specified with the ExternalGraphic element:

                                  <PointSymbolizer>\n   <Graphic>\n      <ExternalGraphic>\n         <OnlineResource xlink:type=\"simple\"\n            xlink:href=\"http://maps.google.com/mapfiles/kml/pal3/icon55.png\"/>\n         <Format>image/png</Format>\n      </ExternalGraphic>\n   </Graphic>\n</PointSymbolizer>\n

                                  Figure 7: A custom icon for points

                                  In Figure 7, the custom icon is specified as a remote URL. It is also possible to place the graphic in the GeoServer styles directory, and then specify the filename only:

                                  <PointSymbolizer>\n   <Graphic>\n      <ExternalGraphic>\n         <OnlineResource xlink:type=\"simple\" xlink:href=\"icon55.png\"/>\n         <Format>image/png</Format>\n      </ExternalGraphic>\n   </Graphic>\n</PointSymbolizer>\n

                                  Figure 8: Specifying a local file for a graphic point

                                  "},{"location":"services/wms/googleearth/kmlstyling/#kml-styling-lines","title":"Lines","text":"

                                  Styles for lines are specified via a LineSymbolizer. An empty LineSymbolizer element will result in a default KML style:

                                  <LineSymbolizer>\n</LineSymbolizer>\n

                                  Figure 9: Default line

                                  The aspects of the resulting line which can be specified via a LineSymbolizer are color, width, and opacity.

                                  "},{"location":"services/wms/googleearth/kmlstyling/#line-color","title":"Line Color","text":"

                                  The color of a line is specified with a CssParameter element and a stroke attribute. The color is specified as a six digit hexadecimal code.

                                  <LineSymbolizer>\n   <Stroke>\n      <CssParameter name=\"stroke\">#ff0000</CssParameter>\n   </Stroke>\n</LineSymbolizer>\n

                                  Figure 10: Line rendered with color #ff0000 (100% red)

                                  "},{"location":"services/wms/googleearth/kmlstyling/#line-width","title":"Line Width","text":"

                                  The width of a line is specified with a CssParameter element and a stroke-width attribute. The width is specified as an integer (in pixels):

                                  <LineSymbolizer>\n   <Stroke>\n      <CssParameter name=\"stroke-width\">5</CssParameter>\n   </Stroke>\n</LineSymbolizer>\n

                                  Figure 11: Line rendered with a width of five (5) pixels

                                  "},{"location":"services/wms/googleearth/kmlstyling/#line-opacity","title":"Line Opacity","text":"

                                  The opacity of a line is specified with a CssParameter element and a fill-opacity attribute. The opacity is specified as a floating point number between 0 and 1, with 0 being completely transparent, and 1 being completely opaque.

                                  <LineSymbolizer>\n   <Stroke>\n      <CssParameter name=\"stroke-opacity\">0.5</CssParameter>\n   </Stroke>\n</LineSymbolizer>\n

                                  Figure 12: A line rendered with 50% opacity

                                  "},{"location":"services/wms/googleearth/kmlstyling/#kml-styling-polygons","title":"Polygons","text":"

                                  Styles for polygons are specified via a PolygonSymbolizer. An empty PolygonSymbolizer element will result in a default KML style:

                                  <PolygonSymbolizer>\n</PolygonSymbolizer>\n

                                  Polygons have more options for styling than points and lines, as polygons have both an inside (\"fill\") and an outline (\"stroke\"). The aspects of polygons that can be specified via a PolygonSymbolizer are stroke color, stroke width, stroke opacity, fill color, and fill opacity.

                                  "},{"location":"services/wms/googleearth/kmlstyling/#polygon-stroke-color","title":"Polygon Stroke Color","text":"

                                  The outline color of a polygon is specified with a CssParameter element and stroke attribute inside of a Stroke element. The color is specified as a 6 digit hexadecimal code:

                                  <PolygonSymbolizer>\n   <Stroke>\n      <CssParameter name=\"stroke\">#0000FF</CssParameter>\n   </Stroke>\n</PolygonSymbolizer>\n

                                  Figure 13: Outline of a polygon (#0000FF or 100% blue)

                                  "},{"location":"services/wms/googleearth/kmlstyling/#polygon-stroke-width","title":"Polygon Stroke Width","text":"

                                  The outline width of a polygon is specified with a CssParameter element and stroke-width attribute inside of a Stroke element. The width is specified as an integer.

                                  <PolygonSymbolizer>\n   <Stroke>\n      <CssParameter name=\"stroke-width\">5</CssParameter>\n   </Stroke>\n</PolygonSymbolizer>\n

                                  Figure 14: Polygon with stroke width of five (5) pixels

                                  "},{"location":"services/wms/googleearth/kmlstyling/#polygon-stroke-opacity","title":"Polygon Stroke Opacity","text":"

                                  The stroke opacity of a polygon is specified with a CssParameter element and stroke attribute inside of a Stroke element. The opacity is specified as a floating point number between 0 and 1, with 0 being completely transparent, and 1 being completely opaque.

                                  <PolygonSymbolizer>\n   <Stroke>\n      <CssParameter name=\"stroke-opacity\">0.5</CssParameter>\n   </Stroke>\n</PolygonSymbolizer>\n

                                  Figure 15: Polygon stroke opacity of 0.5 (50% opaque)

                                  "},{"location":"services/wms/googleearth/kmlstyling/#polygon-fill-color","title":"Polygon Fill Color","text":"

                                  The fill color of a polygon is specified with a CssParameter element and fill attribute inside of a Fill element. The color is specified as a six digit hexadecimal code:

                                  <PolygonSymbolizer>\n   <Fill>\n      <CssParameter name=\"fill\">#0000FF</CssParameter>\n   </Fill>\n</PolygonSymbolizer>\n

                                  Figure 16: Polygon fill color of #0000FF (100% blue)

                                  "},{"location":"services/wms/googleearth/kmlstyling/#polygon-fill-opacity","title":"Polygon Fill Opacity","text":"

                                  The fill opacity of a polygon is specified with a CssParameter element and fill-opacity attribute inside of a Fill element. The opacity is specified as a floating point number between 0 and 1, with 0 being completely transparent, and 1 being completely opaque.

                                  <PolygonSymbolizer>\n   <Fill>\n      <CssParameter name=\"fill-opacity\">0.5</CssParameter>\n   </Fill>\n</PolygonSymbolizer>\n

                                  Figure 17: Polygon fill opacity of 0.5 (50% opaque)

                                  "},{"location":"services/wms/googleearth/kmlstyling/#kml-styling-text-labels","title":"Text Labels","text":"

                                  There are two ways to specify a label for a feature in Google Earth. The first is with Freemarker templates (LINK?), and the second is with a TextSymbolizer. Templates take precedence over symbolizers.

                                  "},{"location":"services/wms/googleearth/kmlstyling/#freemarker-templates","title":"Freemarker Templates","text":"

                                  Specifying labels via a Freemarker template involves creating a special text file called title.ftl and placing it into the workspaces/<ws name>/<datastore name>/<feature type name> directory (inside the GeoServer data directory) for the dataset to be labeled. For example, to create a template to label the states dataset by state name one would create the file here: <data_dir>/workspaces/topp/states_shapefile/states/title.ftl. The content of the file would be:

                                  ${STATE_NAME.value}\n

                                  Figure 18: Using a Freemarker template to display the value of STATE_NAME

                                  For more information on Placemark Templates, please see our full tutorial (LINK FORTHCOMING).

                                  "},{"location":"services/wms/googleearth/kmlstyling/#textsymbolizer","title":"TextSymbolizer","text":"

                                  In SLD labels are specified with the Label element of a TextSymbolizer. (Note the ogc: prefix on the PropertyName element.)

                                  <TextSymbolizer>\n   <Label>\n      <ogc:PropertyName>STATE_NAME</ogc:PropertyName>\n   </Label>\n</TextSymbolizer>\n

                                  Figure 19: Using a TextSymbolizer to display the value of STATE_NAME

                                  The aspects of the resulting label which can be specified via a TextSymbolizer are color and opacity.

                                  "},{"location":"services/wms/googleearth/kmlstyling/#textsymbolizer-color","title":"TextSymbolizer Color","text":"

                                  The color of a label is specified with a CssParameter element and fill attribute inside of a Fill element. The color is specified as a six digit hexadecimal code:

                                  <TextSymbolizer>\n   <Label>\n      <ogc:PropertyName>STATE_NAME</ogc:PropertyName>\n   </Label>\n   <Fill>\n      <CssParameter name=\"fill\">#000000</CssParameter>\n   </Fill>\n</TextSymbolizer>\n

                                  Figure 20: TextSymbolizer with black text color (#000000)

                                  "},{"location":"services/wms/googleearth/kmlstyling/#textsymbolizer-opacity","title":"TextSymbolizer Opacity","text":"

                                  The opacity of a label is specified with a CssParameter element and fill-opacity attribute inside of a Fill element. The opacity is specified as a floating point number between 0 and 1, with 0 being completely transparent, and 1 being completely opaque.

                                  <TextSymbolizer>\n   <Label>\n      <ogc:PropertyName>STATE_NAME</ogc:PropertyName>\n   </Label>\n   <Fill>\n      <CssParameter name=\"fill-opacity\">0.5</CssParameter>\n   </Fill>\n</TextSymbolizer>\n

                                  Figure 21: TextSymbolizer with opacity 0.5 (50% opaque)

                                  "},{"location":"services/wms/googleearth/kmlstyling/#kml-styling-descriptions","title":"Descriptions","text":"

                                  When working with KML, each feature is linked to a description, accessible when the feature is clicked on. By default, GeoServer creates a list of all the attributes and values for the particular feature.

                                  Figure 22: Default description for a feature

                                  It is possible to modify this default behavior. Much like with featureType titles, which are edited by creating a title.ftl template, a custom description can be used by creating template called description.ftl and placing it into the feature type directory (inside the GeoServer data directory) for the dataset. For instance, to create a template to provide a description for the states dataset, one would create the file: <data_dir>/workspaces/topp/states_shapefile/states/description.ftl. As an example, if the content of the description template is:

                                  This is the state of ${STATE_NAME.value}.\n

                                  The resultant description will look like this:

                                  Figure 23: A custom description

                                  It is also possible to create one description template for all featureTypes in a given namespace. To do this, create a description.ftl file as above, and save it as <data_dir>/templates/<workspace>/description.ftl. Please note that if a description template is created for a specific featureType that also has an associated namespace description template, the featureType template (i.e. the most specific template) will take priority.

                                  One can also create more complex descriptions using a combination of HTML and the attributes of the data. A full tutorial on how to use templates to create descriptions is available in our page on KML Placemark Templates. (LINK?)

                                  SLD Generation from CSS SLD Structure Points Lines Polygons Text Labels Descriptions

                                  "},{"location":"services/wms/googleearth/overview/","title":"Overview","text":""},{"location":"services/wms/googleearth/overview/#why-use-geoserver-with-google-earth","title":"Why use GeoServer with Google Earth?","text":"

                                  GeoServer is useful when one wants to put a lot of data on to Google Earth. GeoServer automatically generates KML that can be easily and quickly served and visualized in Google Earth. GeoServer operates entirely through a Network Link, which allows it to selectively return information for the area being viewed. With GeoServer as a robust and powerful server and Google Earth providing rich visualizations, they are a perfect match for sharing your data.

                                  "},{"location":"services/wms/googleearth/overview/#standards-based-implementation","title":"Standards-based implementation","text":"

                                  GeoServer supports Google Earth by providing KML as a Web Map Service (WMS) output format. This means that adding data published by GeoServer is as simple as constructing a standard WMS request and specifying \"application/vnd.google-earth.kml+xml\" as the outputFormat. Since generating KML is just a WMS request, it fully supports Styling via SLD.

                                  See the next section (Quickstart) to view GeoServer and Google Earth in action.

                                  "},{"location":"services/wms/googleearth/quickstart/","title":"Quickstart","text":"

                                  Note

                                  If you are using GeoServer locally, the GEOSERVER_URL is usually http://localhost:8080/geoserver

                                  "},{"location":"services/wms/googleearth/quickstart/#viewing-a-layer","title":"Viewing a layer","text":"

                                  Once GeoServer is installed and running, open up a web browser and go to the web admin console (Web administration interface). Navigate to the Layer Preview by clicking on the Layer Preview link at the bottom of the left sidebar. You will be presented with a list of the currently configured layers in your GeoServer instance. Find the row that says topp:states. To the right of the layer click on the link that says KML.

                                  The Map Preview page

                                  If Google Earth is correctly installed on your computer, you will see a dialog asking how to open the file. Select Open with Google Earth.

                                  Open with Google Earth

                                  When Google Earth is finished loading the result will be similar to below.

                                  The topp:states layer rendered in Google Earth

                                  "},{"location":"services/wms/googleearth/quickstart/#direct-access-to-kml","title":"Direct access to KML","text":"

                                  All of the configured FeatureTypes are available to be output as KML (and thus loaded into Google Earth). The URL structure for KMLs is:

                                  http://GEOSERVER_URL/wms/kml?layers=<layername>\n

                                  For example, the topp:states layer URL is:

                                  http://GEOSERVER_URL/wms/kml?layers=topp:states\n
                                  "},{"location":"services/wms/googleearth/quickstart/#adding-a-network-link","title":"Adding a Network Link","text":"

                                  An alternative to serving KML directly into Google Earth is to use a Network Link. A Network Link allows for better integration into Google Earth. For example, using a Network Link enables the user to refresh the data within Google Earth, without having to retype a URL, or click on links in the GeoServer Map Preview again.

                                  To add a Network Link, pull down the Add menu, and go to Network Link. The New Network Link dialog box will appear. Name your layer in the Name field. (This will show up in My Places on the main Google Earth screen.) Set Link to:

                                  http://GEOSERVER_URL/wms/kml?layers=topp:states\n

                                  (Don't forget to replace the GEOSERVER_URL.) Click OK. You can now save this layer in your My Places.

                                  Adding a network link

                                  Check out the sections on Tutorials and the KML Styling for more information.

                                  "},{"location":"services/wms/googleearth/features/","title":"Features","text":"

                                  This section delves into greater detail about the various functionality and options possible with KML output and Google Earth.

                                  • KML Reflector
                                  • Toggling Placemarks
                                  • Customizing Placemarks
                                  • KML Placemark Placement
                                  • KML Height and Time
                                  • KML Legends
                                  • Filters
                                  • KML Super-Overlays
                                  • KML Regionation
                                  • KML Scoring
                                  "},{"location":"services/wms/googleearth/features/customizingplacemarks/","title":"Customizing Placemarks","text":"

                                  KML output can leverage some powerful visualization abilities in Google Earth. Titles can be displayed on top of the features. Descriptions (custom HTML shown when clicking on a feature) can be added to customize the views of the attribute data. In addition, using Google Earth's time slider, time-based animations can be created. Finally, height of features can be set, as opposed to the default ground overlay. All of these can be accomplished by creating Freemarker templates. Freemarker templates are text files (with limited HTML code), saved in the GeoServer data directory, that utilize variables that link to specific attributes in the data.

                                  "},{"location":"services/wms/googleearth/features/customizingplacemarks/#titles","title":"Titles","text":"

                                  Specifying labels via a template involves creating a special text file called title.ftl and placing it into the featuretypes directory inside the GeoServer data directory for the dataset to be labeled. For instance, to create a template to label the states layer by state name, one would create the file: <data_dir>/workspaces/topp/states_shapefile/states/title.ftl. The content of the file would be:

                                  ${STATE_NAME.value}\n
                                  "},{"location":"services/wms/googleearth/features/customizingplacemarks/#descriptions","title":"Descriptions","text":"

                                  When working with KML, each feature is linked to a description, accessible when the feature is clicked on. By default, GeoServer creates a list of all the attributes and values for the particular feature.

                                  It is possible to modify this default behavior. Much like with featuretype titles, which are edited by creating a title.ftl template, specifying descriptions via a template involves creating a special text file called description.ftl and placing it into the featuretypes directory inside the GeoServer data directory for the dataset to be labeled. For instance, a sample description template would be saved here: <data_dir>/workspaces/topp/states_shapefile/states/description.ftl. The content of the file could be:

                                  This is the state of ${STATE_NAME.value}.\n

                                  The resulting description will look like this:

                                  Warning

                                  Add SS: A custom description

                                  It is also possible to create one description template for all layers in a given namespace. To do this, create a description.ftl file as above, and save it here:

                                  <data_dir>/workspaces/<namespace>/description.ftl.\n

                                  Please note that if a description template is created for a specific layer that also has an associated namespace description template, the layer template (i.e. the most specific template) will take priority.

                                  "},{"location":"services/wms/googleearth/features/filters/","title":"Filters","text":"

                                  Though not specific to Google Earth, GeoServer has the ability to filter data returned from the Web Map Service (WMS). The KML Reflector will pass through any WMS filter or cql_filter parameter to GeoServer to constrain the response.

                                  Note

                                  Filters are basically a translation of a SQL \"WHERE\" statement into web form. Though limited to a single table, this allows users to do logical filters like \"AND\" and \"OR\" to make very complex queries, leveraging numerical and string comparisons, geometric operations (\"bbox\", \"touches\", \"intersects\", \"disjoint\"), \"LIKE\" statements, nulls, and more.

                                  "},{"location":"services/wms/googleearth/features/filters/#filter","title":"Filter","text":"

                                  There simplest filter is very easy to include. It is called the featureid filter, and it lets you filter to a single feature by its ID. The syntax is:

                                  featureid=<feature>\n

                                  where is the feature and its ID. An example would be:

                                  http://localhost:8080/geoserver/wms/kml?layers=topp:states&featureid=states.5\n

                                  This request will output only the state of Maryland. The feature IDs of your data are most easily found by doing WFS or KML requests and examining the resulting output.

                                  "},{"location":"services/wms/googleearth/features/filters/#cql-filter","title":"CQL Filter","text":"

                                  Using filters in a URL can be very unwieldy, as one needs to include URL-encoded XML:

                                  http:/localhost:8080/geoserver/wms/kml?layers=topp:states&FILTER=%3CFilter%3E%3CPropertyIsBetween%3E%3CPropertyName%3Etopp:LAND_KM%3C/PropertyName%3E%3CLowerBoundary%3E%3CLiteral%3E100000%3C/Literal%3E%3C/LowerBoundary%3E%3CUpperBoundary%3E%3CLiteral%3E150000%3C/Literal%3E%3C/UpperBoundary%3E%3C/PropertyIsBetween%3E%3C/Filter%3E\n

                                  Instead, one can use Common Query Language (CQL), which allows one to specify the same statement more succinctly:

                                  http://localhost:8080/geoserver/wms/kml?layers=topp:states&CQL_FILTER=LAND_KM+BETWEEN+100000+AND+150000\n

                                  This query will return all the states in the US with areas between 100,000 and 150,000 km\\^2.

                                  "},{"location":"services/wms/googleearth/features/kmlcentroids/","title":"KML Placemark Placement","text":"

                                  The placemark \"placement\" (also referred to as the \"centroid\") refers to the location of the placemark icon with respect to the feature geometry itself. Historically this placement has been chosen to be simply the centroid of the feature geometry. This section describes options for controlling placement were introduced.

                                  "},{"location":"services/wms/googleearth/features/kmlcentroids/#clipping","title":"Clipping","text":"

                                  The KMCENTROID_CLIP option determines whether the feature geometry should be clipped to the viewport before the centroid is calculated. This will ensure that the placemark icon always falls within the viewport, even in cases part of a geometry falls outside of it.

                                  The option is set to either true or false. The default value isfalse.

                                  As an example consider the following square polygon with its placemark icon. When the polygon is entirely in the viewport the placement is good.

                                  When the polygon moves out of the viewport the icon is lost as in the following figure:

                                  When KMCENTROID_CLIP set to true only the part of the geometry intersecting the viewport is considered.

                                  "},{"location":"services/wms/googleearth/features/kmlcentroids/#sampling-for-internal-point","title":"Sampling for internal point","text":"

                                  The KMCENTROID_CONTAIN option determines whether point chosen for the centroid must fall within the feature geometry. For irregularly shaped geometries (like a \"C\" shaped polygon) the default centroid calculation will fall outside of the geometry. The option is set to either true or false. The default value is false.

                                  In order to find a contained point of a polygon a sampling tequnique is used where a number of points are chosen until one is found that falls within the polygon. The KMCENTROID_SAMPLE option determines how many samples to attempt. The value is an integer with a default value is 5. Note that this option only applies when KMCENTROID_CONTAIN is set to true.

                                  As an example consider the following \"c\" shaped polygon with its placemark icon. By default the icon falls outside of the polygon.

                                  When KMCENTROID_CONTAIN set to true a point within the polygon is chosen.

                                  Note

                                  The sampling tequnique may not always be able to find a suitable point. You can try to increase the number of samples but it is still not a guarantee. Care also must be taken when increasing the sample count since it adds overhead to the overall KML rendering process.

                                  "},{"location":"services/wms/googleearth/features/kmlheighttime/","title":"KML Height and Time","text":""},{"location":"services/wms/googleearth/features/kmlheighttime/#height","title":"Height","text":"

                                  GeoServer by default creates two dimensional overlays in Google Earth. However, GeoServer can output features with height information (also called \"KML extrudes\") if desired. This can have the effect of having features \"float\" above the ground, or create bar graph style structures in the shape of the features. The height of features can be linked to an attribute of the data.

                                  Setting the height of features is determined by using a KML Freemarker template. Create a file called height.ftl, and save it in the same directory as the featuretype in your GeoServer data directory. For example, to create a height template for the states layer, the file should be saved in <data_dir>/workspaces/topp/states_shapefile/states/height.ftl.

                                  To set the height based on an attribute, the syntax is:

                                  ${ATTRIBUTE.value}\n

                                  Replace the word ATTRIBUTE with the name of the height attribute in your data set. For a complete tutorial on working with the height templates see Heights Templates.

                                  "},{"location":"services/wms/googleearth/features/kmlheighttime/#time","title":"Time","text":"

                                  Google Earth also contains a \"time slider\", which can allow animations of data, and show changes over time. As with height, time can be linked to an attribute of the data, as long as the data set has a date/time attribute. Linking this date/time attribute to the time slider in Google Earth is accomplished by creating a Freemarker template. Create a file called time.ftl, and save it in the same directory that contains your data's info.xml.

                                  To set the time based on an attribute the syntax is:

                                  ${DATETIME_ATTRIBUTE.value}\n

                                  Replace the word DATETIME_ATTRIBUTE with the name of the date/time attribute. When creating KML, GeoServer will automatically link the data to the time element in Google Earth. If set successfully, the time slider will automatically appear.

                                  For a full tutorial on using GeoServer with Google Earth's time slider see Time

                                  "},{"location":"services/wms/googleearth/features/kmllegends/","title":"KML Legends","text":"

                                  WMS includes a GetLegendGraphic operation which allows a WMS client to obtain a legend graphic from the server for a particular layer. Combining the legend with KML overlays allows the legend to be viewed inside Google Earth.

                                  To get GeoServer to include a legend with the KML output, append legend=true to the KML reflector request. For example:

                                  http://localhost:8080/geoserver/wms/kml?layers=topp:states&legend=true\n

                                  The resulting Google Earth output looks like this:

                                  "},{"location":"services/wms/googleearth/features/kmlreflector/","title":"KML Reflector","text":"

                                  Standard WMS requests can be quite long and cumbersome. The following is an example of a request for KML output from GeoServer:

                                  http://localhost:8080/geoserver/ows?service=WMS&request=GetMap&version=1.1.1&format=application/vnd.google-earth.kml+XML&width=1024&height=1024&srs=EPSG:4326&layers=topp:states&styles=population&bbox=-180,-90,180,90\n

                                  GeoServer includes an alternate way of requesting KML, and that is to use the KML reflector. The KML reflector is a simpler URL-encoded request that uses sensible defaults for many of the parameters in a standard WMS request. Using the KML reflector one can shorten the above request to:

                                  http://localhost:8080/geoserver/wms/kml?layers=topp:states\n
                                  "},{"location":"services/wms/googleearth/features/kmlreflector/#using-the-kml-reflector","title":"Using the KML reflector","text":"

                                  The only mandatory parameter is the layers parameter. The syntax is as follows:

                                  http://GEOSERVER_URL/wms/kml?layers=<layer>\n

                                  where GEOSERVER_URL is the URL of your GeoServer instance, and <layer> is the name of the featuretype to be served.

                                  The following table lists the default assumptions:

                                  Key Value

                                  request GetMap

                                  service wms

                                  version 1.1.1

                                  srs EPSG:4326

                                  format application/vnd.google-earth.kml+xml

                                  width 2048

                                  height 2048

                                  bbox <layer bounds>

                                  kmattr true

                                  kmplacemark false

                                  kmscore 40

                                  styles [default style for the featuretype]

                                  Any of these defaults can be changed when specifying the request. For instance, to specify a particular style, one can append styles=population to the request:

                                  http://localhost:8080/geoserver/wms/kml?layers=topp:states&styles=population\n

                                  To specify a different bounding box, append the parameter to the request:

                                  http://localhost:8080/geoserver/wms/kml?layers=topp:states&bbox=-124.73,24.96,-66.97,49.37\n
                                  "},{"location":"services/wms/googleearth/features/kmlreflector/#reflector-modes","title":"Reflector modes","text":"

                                  The KML reflector can operate in one of three modes: refresh, superoverlay, and download.

                                  The mode is set by appending the following parameter to the URL:

                                  mode=<mode>\n

                                  where <mode> is one of the three reflector modes. The details for each mode are as follows:

                                  Mode Description

                                  refresh (default for all versions except 1.7.1 through 1.7.5) Returns dynamic KML that can be refreshed/updated by the Google Earth client. Data is refreshed and new data/imagery is downloaded when zooming/panning stops. This mode can return either vector or raster (placemark or overlay) The decision to return either vector or raster data is determined by the value of kmscore. Please see the section on KML Scoring for more information.

                                  superoverlay (default for versions 1.7.1 through 1.7.5) Returns KML as a super-overlay. A super-overlay is a form of KML in which data is broken up into regions. Please see the section on KML Super-Overlays for more information.

                                  download Returns KML which contains the entire data set. In the case of a vector layer, this will include a series of KML placemarks. With raster layers, this will include a single KML ground overlay. This is the only mode that doesn't dynamically request new data from the server, and thus is self-contained KML.

                                  "},{"location":"services/wms/googleearth/features/kmlreflector/#more-about-the-superoverlay-mode","title":"More about the \"superoverlay\" mode","text":"

                                  When requesting KML using the superoverlay mode, there are four additional submodes available regarding how and when data is requested. These options are set by appending the following parameter to the KML reflector request:

                                  superoverlay_mode=<submode>\n

                                  where <submode> is one of the following options:

                                  Submode Description

                                  auto (default) Always returns vector features if the original data is in vector form, and returns raster imagery if the original data is in raster form. This can sometimes be less than optimal if the geometry of the features are very complicated, which can slow down Google Earth.

                                  raster Always returns raster imagery, regardless of the original data. This is almost always faster, but all vector information is lost in this view.

                                  overview Displays either vector or raster data depending on the view. At higher zoom levels, raster imagery will be displayed, and at lower zoom levels, vector features will be displayed. The determination for when to switch between vector and raster is made by the regionation parameters set on the server. See the section on KML Regionation for more information.

                                  hybrid Displays both raster and vector data at all times.

                                  "},{"location":"services/wms/googleearth/features/kmlregionation/","title":"KML Regionation","text":"

                                  Displaying vector features on Google Earth is a very powerful way of creating nicely-styled maps. However, it is not always optimal to display all features at all times. Displaying too many features can create an unsightly map, and can adversely affect Google Earth's performance. To combat this, GeoServer's KML output includes the ability to limit features based on certain criteria. This process is known as regionation. Regionation is active by default when using the superoverlay KML reflector mode.

                                  "},{"location":"services/wms/googleearth/features/kmlregionation/#regionation-attributes","title":"Regionation Attributes","text":"

                                  The most important aspect of regionation is to decide how to determine which features show up more prominently than others. This can be done either by geometry, or by attribute. One should choose the option that best exemplifies the relative \"importance\" of the feature. When choosing to regionate by geometry, only the larger lines and polygons will be displayed at higher zoom levels, with smaller ones being displayed when zooming in. When regionating by an attribute, the higher value of this attribute will make those features show up at higher zoom levels. (Choosing an attribute with a non-numeric value will be ignored, and will instead default to regionation by geometry.)

                                  "},{"location":"services/wms/googleearth/features/kmlregionation/#regionation-strategies","title":"Regionation Strategies","text":"

                                  Regionation strategies sets how to determine which features should be shown at any given time or zoom level. There are five types of regionation strategies:

                                  Strategy Description

                                  best_guess (default) The actual strategy is determined by the type of data being operated on. If the data consists of points, the random strategy is used. If the data consists of lines or polygons, the geometry strategy is used.

                                  external-sorting Creates a temporary auxiliary database within GeoServer. It takes slightly extra time to build the index upon first request.

                                  native-sorting Uses the default sorting algorithm of the backend where the data is hosted. It is faster than external-sorting, but will only work with PostGIS datastores.

                                  geometry Externally sorts by length (if lines) or area (if polygons).

                                  random Uses the existing order of the data and does not sort.

                                  In most cases, the best_guess strategy is sufficient.

                                  "},{"location":"services/wms/googleearth/features/kmlregionation/#setting-regionation-parameters","title":"Setting Regionation Parameters","text":"

                                  Regionation strategies and attributes are featuretype-specific, and therefore are set in the Layers editing page of the Web administration interface. This can be navigated to by selecting 'Layers' on the left sidebar.

                                  "},{"location":"services/wms/googleearth/features/kmlscoring/","title":"KML Scoring","text":"

                                  Note

                                  KML scoring only applies when using the super-overlay mode refresh. See KML Super-Overlays for more information.

                                  GeoServer can return KML in one of two forms. The first is as a number of placemark elements (vectors). Each placemark corresponds to a feature in the underlying dataset. This form only applies to vector datasets.

                                  The second form is as an overlay (image). In this form the rendering is done by the GeoServer WMS and only the resulting graphic is sent to Google Earth. This is the only form available for raster datasets, but can be applied to vector datasets as well.

                                  There are advantages to and disadvantages to each output mode when rendering vector data. Placemarks look nicer, but there can be performance problems with Google Earth if the data set is large. Overlays put less of a strain on Google Earth, but aren't as nice looking.

                                  The following shows the same dataset rendered in Placemark form on the top and Overlay form on the bottom.

                                  KML scoring is the process of determining whether to render features as rasters or as vectors.

                                  "},{"location":"services/wms/googleearth/features/kmlscoring/#the-kmscore-attribute","title":"The kmscore attribute","text":"

                                  GeoServer makes the determination on whether to render a layer as raster or vector based on how many features are in the data set and an attribute called kmscore. The kmscore attribute determines the maximum amount of vector features rendered. It is calculated by this formula:

                                  maximum number of features = 10^(kmscore/15)\n

                                  The following table shows the values of this threshold for various values of the kmscore parameter:

                                  kmscore Maximum # of features

                                  0 Force overlay/raster output

                                  10 4

                                  20 21

                                  30 100

                                  40 Approx. 450

                                  50 (default) Approx. 2150

                                  60 Approx. 10,000

                                  70 Approx. 45,000

                                  80 Approx. 200,000

                                  90 Approx. 1,000,000

                                  100 Force placemark/vector output

                                  The syntax for specifying kmscore is:

                                  kmscore=<value>\n

                                  where <value> is an integer between 0 and 100. For example:

                                  http://localhost:8080/geoserver/wms/kml?layers=topp:states&mode=refresh&kmscore=20\n

                                  The kmscore attribute will be ignored if using a reflector mode other than refresh.

                                  "},{"location":"services/wms/googleearth/features/kmlsuperoverlays/","title":"KML Super-Overlays","text":"

                                  Super-overlays are a form of KML in which data is broken up into regions. This allows Google Earth to refresh/request only particular regions of the map when the view area changes. Super-overlays are used to efficiently publish large sets of data. (Please see Google's page on super-overlays for more information.)

                                  GeoServer supports two types of super-overlays: raster and vector. With raster super-overlays, GeoServer intelligently produces imagery appropriate to the current zoom level and dynamically outputs new imagery when the zoom level changes. With vector super-overlays, feature data is requested for only the visible features and new features are dynamically loaded as necessary. Raster super-overlays require less resources on the client, but vector super-overlays have a higher output quality.

                                  When using the KML Reflector, super-overlays are enabled by default, whether the data in question is raster or vector. For more information on the various options for KML super-overlay output, please see the page on the KML Reflector.

                                  "},{"location":"services/wms/googleearth/features/kmlsuperoverlays/#raster-super-overlays","title":"Raster Super-Overlays","text":"

                                  Consider this image, which is generated from GeoServer. When zoomed out, the data is at a small size.

                                  When zooming in, the image grows larger, but since the image is at low resolution (originally designed to be viewed small), the quality degrades.

                                  However, in a super-overlay, the KML document requests a new image from GeoServer of a higher resolution for that zoom level. As the new image is downloaded, the old image is replaced by the new image.

                                  "},{"location":"services/wms/googleearth/features/kmlsuperoverlays/#raster-super-overlays-and-geowebcache","title":"Raster Super-Overlays and GeoWebCache","text":"

                                  GeoServer implements super-overlays in a way that is compatible with the WMS Tiling Client Recommendation. Super-overlays are generated such that the tiles of the super-overlay are the same tiles that a WMS tiling client would request. One can therefore use existing tile caching mechanisms and reap a potentially large performance benefit.

                                  The easiest way to tile cache a raster super overlay is to use GeoWebCache which is built into GeoServer:

                                  http://GEOSERVER_URL/gwc/service/kml/<layername>.<imageformat>.kmz\n

                                  where GEOSERVER_URL is the URL of your GeoServer instance.

                                  "},{"location":"services/wms/googleearth/features/kmlsuperoverlays/#vector-super-overlays","title":"Vector Super-Overlays","text":"

                                  GeoServer can include the feature information directly in the KML document. This has lots of benefits. It allows the user to select (click on) features to see descriptions, toggle the display of individual features, as well as have better rendering, regardless of zoom level. For large datasets, however, the feature information can take a long time to download and use a lot of client-side resources. Vector super-overlays allow the client to only download part of a dataset, and request more features as necessary.

                                  Vector super-overlays can use the process of KML Regionation to organize features into a hierarchy. The regionation process can operate in a variety of modes. Most of the modes require a \"regionation attribute\" which is used to determine which features should be visible at a particular zoom level. Please see the KML Regionation page for more details.

                                  "},{"location":"services/wms/googleearth/features/kmlsuperoverlays/#vector-super-overlays-and-geowebcache","title":"Vector Super-Overlays and GeoWebCache","text":"

                                  As with raster super-overlays, it is possible to cache vector super-overlays using GeoWebCache. Below is the syntax for generating a vector super-overlay KML document via GeoWebCache:

                                  http://GEOSERVER_URL/gwc/service/kml/<layername>.kml.kmz\n

                                  where GEOSERVER_URL is the URL of your GeoServer instance.

                                  Unlike generating a super-overlay with the standard KML Reflector, it is not possible to specify the regionation properties as part of the URL. These parameters must be set in the Layers configuration which can be navigated to by clicking on 'Layers' in the left hand sidebar and then selecting your vector layer.

                                  "},{"location":"services/wms/googleearth/features/togglingplacemarks/","title":"Toggling Placemarks","text":""},{"location":"services/wms/googleearth/features/togglingplacemarks/#vector-placemarks","title":"Vector Placemarks","text":"

                                  When GeoServer generates KML for a vector dataset, it attaches information from the data to each feature that is created. When clicking on a vector feature, a pop-up window is displayed. This is called a placemark. By default this is a simple list which displays attribute data, although this information can be customized using Freemarker templates.

                                  If you would like this information not to be shown when a feature is clicked (either for security reasons, or simply to have a cleaner user interface), it is possible to disable this functionality. To do so, use the kmattr parameter in a KML request to turn off attribution.

                                  The syntax for kmattr is as follows:

                                  format_options=kmattr:[true|false]\n

                                  Note that kmattr is a \"format option\", so the syntax is slightly different from the usual key-value pair. For example:

                                  http://localhost:8080/geoserver/wms/kml?layers=topp:states&format_options=kmattr:false\n
                                  "},{"location":"services/wms/googleearth/features/togglingplacemarks/#raster-placemarks","title":"Raster Placemarks","text":"

                                  Unlike vector features, where the placemark is enabled by default, placemarks are disabled by default with raster images of features. To enable this feature, you can use the kmplacemark format option in your KML request. The syntax is similar to the kmattr format option specified above:

                                  format_options=kmplacemark:[true|false]\n

                                  For example, using the KML reflector, the syntax would be:

                                  http://localhost:8080/geoserver/wms/kml?layers=topp:states&format_options=kmplacemark:true\n
                                  "},{"location":"services/wms/googleearth/tutorials/","title":"Tutorials","text":"
                                  • KML Placemark Templates
                                  • Heights Templates
                                  • Time
                                  • Super-Overlays and GeoWebCache
                                  "},{"location":"services/wms/googleearth/tutorials/superoverlaysgwc/","title":"Super-Overlays and GeoWebCache","text":""},{"location":"services/wms/googleearth/tutorials/superoverlaysgwc/#overview","title":"Overview","text":"

                                  This tutorial explains how to use GeoWebCache (GWC) to enhance the performance of super-overlays in Google Earth. For more information please see the page on KML Super-Overlays

                                  Conveniently GeoWebCache can generate super-overlays automatically. With the standalone GeoWebCache it takes minimal amount of configuration. Please see the GeoWebCache documentation for more information on the standalone version of GeoWebCache.

                                  We are going to use the plug in version of GeoWebCache where there is no configuration need. For this tutorial we are also using the topp:states layer. Using the GeoWebCache plug in with super-overlays

                                  To access GWC from GeoServer go to http://localhost:8080/geoserver/gwc/demo/. This should return a layer list of similar to below.

                                  To use a super-overlay in GeoWebCache select the KML (vector) option display for each layer. Lets select topp:states.The url would be http://localhost:8080/geoserver/gwc/service/kml/topp:states.kml.kmz After doing so you will be presented with a open option dialog, choose Google Earth.

                                  When Google Earth finishes loading you should be viewing a the topp:states layers.

                                  "},{"location":"services/wms/googleearth/tutorials/heights/heights/","title":"Heights Templates","text":""},{"location":"services/wms/googleearth/tutorials/heights/heights/#introduction","title":"Introduction","text":"

                                  Height Templates in KML allow you to use an attribute of your data as the 'height' of features in Google Earth.

                                  Note

                                  This tutorial assumes that GeoServer is running on http://localhost:8080.

                                  "},{"location":"services/wms/googleearth/tutorials/heights/heights/#getting-started","title":"Getting Started","text":"

                                  For the purposes of this tutorial, you just need to have GeoServer with the release configuration, and Google Earth installed. Google Earth is available for free from <http://earth.google.com/ <http://earth.google.com/>`_.

                                  "},{"location":"services/wms/googleearth/tutorials/heights/heights/#step-one","title":"Step One","text":"

                                  By default GeoServer renders all features with 0 height, so they appear to lay flat on the world's surface in Google Earth.

                                  To view the topp:states layer (packaged with all releases of GeoServer) in Google Earth, the easiest way is to use a network link. In Google Earth, under Places, right-click on Temporary Places, and go to Add \u2192 Network Link. In the dialog box, fill in topp:states as the Name, and the following URL as the Link:

                                  http://localhost:8080/geoserver/wms/reflect?layers=topp:states&format=application/vnd.google-earth.kml+xml\n

                                  topp:states in Google Earth

                                  "},{"location":"services/wms/googleearth/tutorials/heights/heights/#step-two","title":"Step Two","text":"

                                  An interesting value to use for the height would be the population of each state (so that more populated states appear taller on the map). We can do this by creating a file called height.ftl in the GeoServer data directory under workspaces/topp/states_shapefile/states. To set the population value, we enter the following text inside this new file:

                                  ${PERSONS.value}\n

                                  This uses the value of the PERSONS attribute as the height for each feature. To admire our handiwork, we can refresh our view by right-clicking on our temporary place (called topp:states) and selecting Refresh:

                                  Height by Population

                                  "},{"location":"services/wms/googleearth/tutorials/heights/heights/#step-three","title":"Step Three","text":"

                                  Looking at our population map, we see that California dwarfs the rest of the nation, and in general all of the states are too tall for us to see the heights from a convenient angle. In order to scale things down to a more manageable size, we can divide all height values by 100. Just change the template we wrote earlier to read:

                                  ${PERSONS.value / 100}\n

                                  Refreshing our view once again, we see that our height field has disappeared. Looking at the GeoServer log (in the data directory under logs/geoserver.log) we see something like:

                                  Caused by: freemarker.core.NonNumericalException: Error on line 1, column 3 in height.ftl\nExpression PERSONS.value is not numerical\n

                                  However, we know that the PERSONS field is numeric, even if it is declared in the shapefile as a string value. To force a conversion, we can append ?number, like so:

                                  ${PERSONS.value?number / 100}\n

                                  One final Refresh brings us to a nicely sized map of the US:

                                  Scaled Height

                                  "},{"location":"services/wms/googleearth/tutorials/heights/heights/#step-four","title":"Step Four","text":"

                                  There are still a couple of tweaks we can make. The default is to create a 'solid' look for features with height, but Google Earth can also create floating polygons that are disconnected from the ground. To turn off the 'connect to ground' functionality, add a format option called 'extrude' whose value is 'false'. That is, change the Link in the Network Link to be:

                                  http://localhost:8080/geoserver/wms/reflect?layers=topp:states&format=application/vnd.google-earth.kml%2Bxml&format_options=extrude:false\n

                                  We also have a few options for how Google Earth interprets the height field. By default, the height is interpreted as relative to the ground, but we can also set the heights relative to sea level, or to be ignored (useful for reverting to the 'flat' look without erasing your template). This is controlled with a format option named altitudeMode, whose values are summarized below.

                                  altitudeMode Purpose

                                  altitudeMode Interpret height as relative to ground level

                                  absolute Interpret height as relative to sea level

                                  clampToGround Ignore height entirely

                                  "},{"location":"services/wms/googleearth/tutorials/kmlplacemark/","title":"KML Placemark Templates","text":""},{"location":"services/wms/googleearth/tutorials/kmlplacemark/#introduction","title":"Introduction","text":"

                                  In KML a \"Placemark\" is used to mark a position on a map, often visualized with a yellow push pin. A placemark can have a \"description\" which allows one to attach information to it. Placemark descriptions are nothing more than an HTML snippet and can contain anything we want it to.

                                  By default GeoServer produces placemark descriptions which are HTML tables describing all the attributes available for a particular feature in a dataset. In the following image we see the placemark description for the feature representing Idaho state:

                                  The default placemark

                                  This is great, but what about if one wanted some other sort of information to be conveyed in the description. Or perhaps one does not want to show all the attributes of the dataset. The answer is Templates!!

                                  A template is more or less a way to create some output.

                                  "},{"location":"services/wms/googleearth/tutorials/kmlplacemark/#getting-started","title":"Getting Started","text":"

                                  First let us get set up. To complete the tutorial you will need the following:

                                  • A GeoServer install
                                  • A text editor

                                  And thats it. For this tutorial we will assume that GeoServer is running the same configuration ( data directory ) that it does out of the box.

                                  "},{"location":"services/wms/googleearth/tutorials/kmlplacemark/#hello-world","title":"Hello World","text":"

                                  Ok, time to get to creating our first template. We will start off an extremely simple template which, you guessed it, creates the placemark description \"Hello World!\". So lets go.

                                  1. Using the text editor of your choice start a new file called description.ftl

                                  2. Add the following content to the file:

                                    Hello World!\n
                                  3. Save the file in the workspaces/topp/states_shapefile/states directory of your \"data directory\". The data directory is the location of all the GeoServer configuration files. It is normally pointed to by the environment variable GEOSERVER_DATA_DIR.

                                  4. Start GeoServer is it is not already running.

                                  And thats it. We can now test out our template by adding the following network link in google earth:

                                  http://localhost:8080/geoserver/wms/kml?layers=states\n

                                  And voila. Your first template

                                  Hello World template.

                                  Refreshing Templates: One nice aspect of templates is that they are read upon every request. So one can simply edit the template in place and have it picked up by GeoServer as soon as the file is saved. So when after editing and saving a template simply \"Refresh\" the network link in Google Earth to have the new content picked up.

                                  Refresh Template

                                  As stated before template descriptions are nothing more than html. Play around with description.ftl and add some of your own html. Some examples you may want to try:

                                  1. A simple link to the homepage of your organization:
                                    Provided by the <a href=\"http://topp.openplans.org\">The Open Planning Project</a>.\n

                                  Homepage of Topp

                                  Homepage of Topp

                                  1. The logo of your organization:
                                    <img src=\"http://topp.openplans.org/images/logo.jpg\"/>\n

                                  Logo of Topp

                                  Logo of Topp

                                  The possibilities are endless. Now this is all great and everything but these examples are some what lacking in that the content is static. In the next section we will create more realistic template which actually access some the attributes of our data set.

                                  "},{"location":"services/wms/googleearth/tutorials/kmlplacemark/#data-content","title":"Data Content","text":"

                                  The real power of templates is the ability to easily access content, in the case of features this content is the attributes of features.In a KML placemark description template, there are a number of \"template variables\" available.

                                  • The variable \"fid\", which corresponds to the id of the feature
                                  • The variable \"typeName\", which corresponds to the name of the type of the feature
                                  • A sequence of variables corresponding to feature attributes, each named the same name as the attribute

                                  So with this knowledge in hand let us come up with some more examples:

                                  Simple fid/typename access:

                                  This is feature ${fid} of type ${typeName}.\n

                                  This is a feature of 3.1 of type states.

                                  FID

                                  Access to the values of two attributes named STATE_NAME, and PERSONS:

                                  This is ${STATE_NAME.value} state which has a population of ${PERSONS.value}.\n

                                  ID This is Idaho state which has a population of 1.006.749.

                                  Attributes

                                  "},{"location":"services/wms/googleearth/tutorials/kmlplacemark/#attribute-variables","title":"Attribute Variables","text":"

                                  A feature attribute a \"complex object\" which is made up of three parts:

                                  1. A value, given as a default string representation of the actual attribute value feasible to be used directly
                                  2. A rawValue, being the actual value of the attribute, to allow for more specialized customization (for example, ${attribute.value?string(\"Enabled\", \"Disabled\")} for custom representations of boolean attributes, etc).
                                  3. A type, each of which is accessible via ${<attribute_name>.name}, ${<attribute_name>.value}, ${<attribute_name>.rawValue}, ${<attribute_name>.type} respectively. The other variables: fid, and typeName and are \"simple objects\" which are available directly.
                                  "},{"location":"services/wms/googleearth/tutorials/kmlplacemark/#wms-demo-example","title":"WMS Demo Example","text":"

                                  We will base our final example off the \"WMS Example\" demo which ships with GeoServer. To check out the demo visit http://localhost:8080/geoserver/popup_map/index.html in your web browser.

                                  You will notice that hovering the mouse over one of the points on the map displays an image specific to that point. Let us replicate this with a KML placemark description.

                                  1. In the featureTypes/DS_poi_poi directory of the geoserver data directory create the following template:

                                    <img src=\"http://localhost:8080/geoserver/popup_map/${THUMBNAIL.value}\"/>\n
                                  2. Add the following network link in Google Earth:

                                    http://localhost:8080/geoserver/wms/kml?layers=tiger:poi\n

                                  Poi.4

                                  WMS Example

                                  "},{"location":"services/wms/googleearth/tutorials/time/time/","title":"Time","text":"

                                  Warning

                                  The screenshots on this tutorial have not yet been updated for the 2.0.x user interface. But most all the rest of the information should be valid, and the user interface is roughly the same, but a bit more easy to use.

                                  "},{"location":"services/wms/googleearth/tutorials/time/time/#getting-started","title":"Getting Started","text":"

                                  For this tutorial we will using a Shapefile which contains information about the number of Internet users in the countries of Western Europe for a rang of years.

                                  1. Download and unzip inet_weu.zip
                                  2. Configure GeoServer to serve the Shapefile inet_weu.zip. (A tutorial is available Publishing a shapefile.)
                                  3. Add the SLD \"inet_weu.sld to GeoServer. ( A tutorial is available for Styling_)
                                  4. Set the style of the feature type added in step 2 to the style added in step 3

                                  Style

                                  "},{"location":"services/wms/googleearth/tutorials/time/time/#checking-the-setup","title":"Checking the Setup","text":"

                                  If all is configured properly you should be able to navigate to http://localhost:8080/geoserver/wms/kml?layers=topp:inet_weu&format=openlayers&bbox=-33.780,26.266,21.005,56.427 and see the following map:

                                  Setup

                                  "},{"location":"services/wms/googleearth/tutorials/time/time/#creating-the-template","title":"Creating the Template","text":"

                                  Next we will create a template which allows us to specify the temporal aspects of the dataset. The schema of our dataset looks like:

                                  INET_P100n Number of internet users per 100 people

                                  NAME Name of country

                                  RPT_YEAR Year

                                  Geometry Polygon representing the country

                                  The temporal attribute is RPT_YEAR and is the one that matters to us. Ok, time to create the template.

                                  1. In your text editor of choice, create a new text file called time.ftl.
                                  2. Add the following text:
                                  ${RPT_YEAR.value?date('yyyy')}\n
                                  1. Save the file to the <GEOSERVER_DATA_DIR>/workspaces/topp/inet_weu_shapefile/inet_weu directory. Where <GEOSERVER_DATA_DIR> is the location of the \"data directory\" of your GeoServer installation. Usually pointed to via the GEOSERVER_DATA_DIR environment variable.

                                  See the ref:references section for more information about specifying a date format.

                                  "},{"location":"services/wms/googleearth/tutorials/time/time/#trying-it-out","title":"Trying it Out","text":"

                                  Ok time to try it out.

                                  1. Navigate to http://localhost:8080/geoserver/wms/kml?layers=inet_weu&legend=true. This should cause Google Earth to open.

                                  Google Earth

                                  1. In Google Earth, adjust the time bar so that it captures a time interval that is approximately 1 year wide

                                  Google Earth Time Bar

                                  1. Slide the time bar forward in time and notice how the polygon colors change

                                  Sliding the Time Bar

                                  "},{"location":"services/wms/googleearth/tutorials/time/time/#references","title":"References","text":""},{"location":"services/wms/googleearth/tutorials/time/time/#specifying-a-date-format","title":"Specifying a Date Format","text":"

                                  When setting up a time template for your own dataset the most important issue is the format of your temporal data. It may or may not be in a format in which GeoServer can read directly. You can check if the date/time format can be used directly by GeoServer by using the following time template. This is an example time template file (time.ftl) file without explicit formatting.

                                  ${DATETIME_ATTRIBUTE_NAME.value}\n

                                  While GeoServer will try its best to parse the data there are cases in which your data is in a format which it cannot parse. When this occurs it is necessary to explicitly specify the format. Luckily Freemarker provides us with functionality to do just this.

                                  Consider the date time 12:30 on January 01, 2007 specified in the following format: 01?01%2007&12$30!00. When creating the template we need to explicitly tell Freemarker the format the date time is in with the datetime function. This is an example time template file (time.ftl) file with explicit formatting: :

                                  ${DATETIME_ATTRIBUTE_NAME.value?datetime(\"M?d%y&H:m:s\")}\n

                                  The process is similar for dates (no time). The date 01?01%2007 would be specified in a template with explicit formatting:

                                  ${DATETIME_ATTRIBUTE_NAME.value?date(\"M?d%y\")}\n

                                  So when must you specify the date format in this manner? The following table illustrates the date formats that GeoServer can understand. Note that the '-' character can be one of any of the following characters: '/' (forward slash), ' ' (space), '.' (period), ',' (comma)

                                  Date Format Example

                                  yyyy-MM-dd 2007-06-20

                                  yyyy-MMM-dd 2007-Jun-20

                                  MM-dd-yyyy 06-20-2007

                                  MMM-dd-yyyy Jun-20-2007

                                  dd-MM-yyyy 20-06-2007

                                  dd-MMM-yyyy 20-Jun-2007

                                  The set of date time formats which GeoServer can be understand is formed by appending the timestamp formats hh:mm and hh:mm:ss to the entries in the above table:

                                  DateTime Format Example

                                  yyyy-MM-dd hh:mm 2007-06-20 12:30

                                  yyyy-MMM-dd hh:mm 2007-Jun-20 12:30

                                  yyyy-MM-dd hhss 2007-06-20 12:30:00

                                  yyyy-MMM-dd hhss 2007-Jun-20 12:30:00

                                  Warning

                                  Setting the Timezone

                                  Be aware that the KML output for date time formats will reflect the timezone of the java virtual machine, which can be set using the user.timezone parameter in the startup script. For example, the following command starts GeoServer using the Coordinated Universal Time (UTC) timezone.

                                  exec \"$_RUNJAVA\" -DGEOSERVER_DATA_DIR=\"$GEOSERVER_DATA_DIR\"

                                  -Djava.awt.headless=true -DSTOP.PORT=8079 -Duser.timezone=UTC -DSTOP.KEY=geoserver -jar start.jar

                                  If the timezone is not set, it will default to the timezone of the operating system.

                                  "},{"location":"services/wms/googleearth/tutorials/time/time/#specifying-a-date-range","title":"Specifying a Date Range","text":"

                                  In the above example a single time stamp is output for the dataset. GeoServer also supports specifying date ranges via a template. The syntax for ranges is:

                                  <begin>||<end>\n

                                  Where begin is the first date in the range, end is the last date in the range, and || is the delimiter between the two. As an example:

                                  01/01/2007||06/01/2007\n

                                  Would the date range starting at January 1, 2007 and ending June 1, 2007. Date ranges can also be open ended:

                                  ||06/01/2007\n06/01/2007||\n

                                  The first date specifies a date range where the beginning is open-ended. The second specifies a date range where the end is open-ended.

                                  "},{"location":"services/wmts/","title":"Web Map Tile Service (WMTS)","text":"

                                  This section describes the Web Map Tile Service (WMTS).

                                  • WMTS settings
                                  "},{"location":"services/wmts/webadmin/","title":"WMTS settings","text":"

                                  This page details the configuration options for WMTS in the web administration interface.

                                  WMTS configuration options

                                  "},{"location":"services/wmts/webadmin/#workspace","title":"Workspace","text":"

                                  Select workspace empty to configure global WMTS settings.

                                  See the section on Workspace Services to override settings used by WMTS Virtual Services.

                                  "},{"location":"services/wmts/webadmin/#service-metadata","title":"Service Metadata","text":"

                                  For a description of the WMTS service, see the section on Service Metadata.

                                  "},{"location":"services/wps/","title":"Web Processing Service (WPS)","text":"

                                  Web Processing Service (WPS) is an OGC service for the publishing of geospatial processes, algorithms, and calculations. The WPS service is available as an extension for GeoServer providing an execute operation for data processing and geospatial analysis.

                                  WPS is not a part of GeoServer by default but is available as an extension.

                                  The main advantage of GeoServer WPS over a standalone WPS is direct integration with other GeoServer services and the data catalog. This means that it is possible to create processes based on data served in GeoServer, as opposed to sending the entire data source in the request. It is also possible for the results of a process to be stored as a new layer in the GeoServer catalog. In this way, WPS acts as a full remote geospatial analysis tool, capable of reading and writing data from and to GeoServer.

                                  For the official WPS 1.0.0 specification, see OGC Web Processing Service 05-007r7.

                                  • Installing the WPS extension
                                  • WPS Operations
                                  • WPS Service page
                                  • WPS Security and input limits
                                  • WPS Request Builder
                                  • Process Cookbook
                                  • Hazelcast based process status clustering
                                  "},{"location":"services/wps/administration/","title":"WPS Service page","text":"

                                  The Web Processing Service (WPS) page supports the basic metadata for the service, as well as service specific settings

                                  "},{"location":"services/wps/administration/#service-metadata","title":"Service Metadata","text":"

                                  The service metadata section is common among all services. See the section on Service Metadata.

                                  "},{"location":"services/wps/administration/#execution-and-resource-management-options","title":"Execution and resource management options","text":"

                                  Execution settings:

                                  • Connection timeout: the number of seconds the WPS will wait before giving up on a remote HTTP connection used to retrieve complex inputs
                                  • Maximum synchronous executions run parallel: the maximum number of synchronous processes that will run in parallel at a given time. The others will be queued.
                                  • Maximum execution time for synchronous requests: the maximum time a synchronous process is allowed executing. Processes running in synchronous mode will have to complete execution within the set time limit, or they will be dismissed automatically. These requests have the client waiting for a response on a HTTP connection, so choose a relatively short time (e.g., 60 seconds)
                                  • Maximum queue and execution time for synchronous requests: the maximum time a process is allowed in the queue and executing. Processes running in synchronous mode will have to complete within the set time limit, or they will be dismissed automatically. These requests have the client waiting for a response on a HTTP connection, so choose a relatively short time (e.g., 60 seconds)
                                  • Maximum asynchronous executions run parallel: the maximum number of asynchronous processes that will run in parallel at a given time. The others will be queued
                                  • Maximum execution time for asynchronous requests: the maximum time an asysynchronous process is allowed executing. Processes running in asynchronous mode will have to complete within the set time limit, or they will be dismissed automatically
                                  • Maximum queue and execution time for asynchronous requests: the maximum time an asysynchronous process is allowed in the queue and executing. Processes running in asynchronous mode will have to complete within the set time limit, or they will be dismissed automatically

                                  Resource settings:

                                  • Resource expiration timeout: number of seconds the result of a asynchronous execution will be kept available on disk for user to retrieve. Once this time is expired these resources will be eligible for clearing (which happens at regular intervals).
                                  • Resource storage directory: where on disk the input, temporary and output resources associated to a certain process will be kept. By default it will be the temp/wps directory inside the GeoServer data directory
                                  • External output directory: Some processes allow execution outputs to be stored in an external output directory (not subject to Resource expiration timeout). To enable this functionality provide a path to external storage with the understanding that you are responsible for managing the contents of this folder. Leave empty to disable writing outside of the resource storage.
                                  "},{"location":"services/wps/administration/#process-status-page","title":"Process status page","text":"

                                  The process status page, available in the \"About & Status\" section, reports about running, and recently completed, processes:

                                  The table contains several information bits:

                                  • S/A: synchronous or asynchronous execution
                                  • Node: the name of the machine running the process (important in a clustered environment)
                                  • User: user that started the execution
                                  • Process name: the main process being run (chained processes will not appear in this table)
                                  • Created: when the process got created
                                  • Phase: the current phase in the process lifecycle
                                  • Progress: current progress
                                  • Task: what the process is actually doing at the moment

                                  In GeoServer there are the following execution phases:

                                  • QUEUED: the process is waiting to be executed
                                  • RUNNING: the process is either retrieving and parsing the inputs, computing the results, or writing them out
                                  • FAILED: the process execution terminated with a failure
                                  • SUCCESS: the process execution terminated with a success
                                  • DISMISSING: the process execution is being dismissed, depending on the process nature this might take some time, or be instantaneous

                                  All executions listed in the table can be selected, and then dismissed using the \"Dismiss selected processes\" link at the top of the table. Unlike the \"Dismiss\" vendor operation this UI allows to also dismiss synchronous processes. Once the process dismissal is complete, the process execution will disappear from the table (in accordance with the WPS specification).

                                  Completed processes can also be dismissed, this will cause all on disk resources associated to the process to be removed immediately, instead of waiting for the regular time based expiration.

                                  "},{"location":"services/wps/hazelcast-clustering/","title":"Hazelcast based process status clustering","text":"

                                  Starting with version 2.7.0 GeoServer has a new WPS extension point allowing GeoServer nodes in the same cluster to share the status of current WPS requests. This is particularly important for asynchronous ones, as the client polling for the progress/results might not be hitting the same node that's currently running the requests.

                                  The Hazelcast based status sharing module leverages the Hazelcast library to share the information about the current process status using a replicated map.

                                  "},{"location":"services/wps/hazelcast-clustering/#installation","title":"Installation","text":"

                                  The installation of the module follows the usual process for most extensions:

                                  • Stop GeoServer
                                  • Unpack the contents of gs-wps-hazelcast-status.zip into the geoserver/WEB-INF/lib folder
                                  • Restart GeoServer
                                  "},{"location":"services/wps/hazelcast-clustering/#configuration","title":"Configuration","text":"

                                  The module does not require any configuration in case the default behavior is suitable for the deploy environment.

                                  By default, the module will use multicast messages to locate other nodes in the same cluster and will automatically start sharing information about the process status with them.

                                  In case this is not satisfactory, a hazelcast.xml file can be created/edited in the root of the GeoServer data directory to modify the network connection methods.

                                  The file is not using a GeoServer specific syntax, it's instead a regular Hazelcast configuration file with a simple distributed map declaration:

                                  <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<!--\nConfigure Hazelcast for clustering GeoServer's WPS process status.\nFor more information, see:\nhttps://docs.hazelcast.com/hazelcast/5.3/configuration/configuring-declaratively\n-->\n<hazelcast xmlns=\"http://www.hazelcast.com/schema/config\"\n           xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\"\n           xsi:schemaLocation=\"http://www.hazelcast.com/schema/config\n                               https://hazelcast.com/schema/config/hazelcast-config-5.3.xsd\">\n  <cluster-name>gsWpsCluster</cluster-name>\n\n  <!-- \n     Make Hazelcast use log4j2 just like GeoServer. Remember to add\n     a Logger for com.hazelcast with the appropriate logging level\n     in the geoserver logging configuration to see Hazelcast log messages\n  -->\n  <properties>\n    <property name=\"hazelcast.logging.type\">log4j2</property>\n  </properties>\n\n  <!-- Network section, by default it enables multicast, tune it to use tcp in case \n    multicast is not allowed, and list the nodes that make up a reasonable core of the \n    cluster (e.g., machines that will never be all down at the same time) -->\n  <network>\n    <port auto-increment=\"true\">5701</port>\n    <join>\n      <multicast enabled=\"true\">\n        <multicast-group>224.2.2.3</multicast-group>\n        <multicast-port>54327</multicast-port>\n      </multicast>\n      <tcp-ip enabled=\"false\">\n        <interface>127.0.0.1</interface>\n      </tcp-ip>\n      <aws enabled=\"false\">\n        <access-key>my-access-key</access-key>\n        <secret-key>my-secret-key</secret-key>\n        <region>us-east-1</region>\n      </aws>\n    </join>\n  </network>\n\n\n\n  <!-- The WPS status map -->\n  <map name=\"wpsExecutionStatusMap\">\n    <indexes>\n      <!-- Add indexes to support the two most common queries -->\n      <index type=\"HASH\">\n        <attributes>\n          <attribute>executionId</attribute>\n        </attributes>\n      </index>\n      <index type=\"SORTED\">\n        <attributes>\n          <attribute>completionTime</attribute>\n        </attributes>\n      </index>\n    </indexes>\n  </map>\n</hazelcast>\n

                                  In case a TCP based configuration is desired, one just needs to disable the multicast one, enable the tcp-ip one, and add a list of interface addresses in it that will form the core of the cluster. Not all nodes in the cluster need to be listed in said section, but a list long enough to ensure that not all the nodes in the list might go down at the same time: as long as at least one of said nodes lives, the cluster will maintain its integrity.

                                  "},{"location":"services/wps/install/","title":"Installing the WPS extension","text":"

                                  The WPS module is not a part of GeoServer core, but instead must be installed as an extension. To install WPS:

                                  1. Navigate to the GeoServer download page.

                                  2. Find the page that matches the exact version of GeoServer you are running.

                                    Warning

                                    Be sure to match the version of the extension with that of GeoServer, otherwise errors will occur.

                                  3. Download the WPS extension: wps

                                    The download link for WPS will be in the Extensions section under Other.

                                  4. Extract the files in this archive to the WEB-INF/lib directory of your GeoServer installation.

                                  5. Restart GeoServer.

                                  After restarting, load the Web administration interface. If the extension loaded properly, you should see an extra entry for WPS in the Service Capabilities column. If you don't see this entry, check the logs for errors.

                                  A link for the WPS capabilities document will display if installed properly

                                  "},{"location":"services/wps/install/#configuring-wps","title":"Configuring WPS","text":"

                                  WPS processes are subject to the same feature limit as the WFS service. The limit applies to process input, so even processes which summarize data and return few results will be affected if applied to very large datasets. The limit is set on the WFS settings Admin page.

                                  Warning

                                  If the limit is encountered during process execution, no error is given. Any results computed by the process may be incomplete

                                  "},{"location":"services/wps/operations/","title":"WPS Operations","text":"

                                  The WPS 1.0.0 standard defines three operations for the discovery and execution of geospatial processes, and GeoServer extends these with two further vendor or pseudo-operations. The operations are:

                                  Operation Description

                                  GetCapabilities Retrieves details of the service offering, including service metadata and metadata describing the available processes

                                  DescribeProcess Retrieves a description of a WPS process available through the service

                                  Execute A request to perform the process with specified input values and required output data items

                                  Dismiss (vendor extension) Used to cancel the execution of a process

                                  GetExecutions (vendor extension) Retrieves a list of the current Execution Statuses

                                  "},{"location":"services/wps/operations/#wps_getcaps","title":"GetCapabilities","text":"

                                  The GetCapabilities operation requests details of the service offering, including service metadata and metadata describing the available processes. The response is an XML document called the capabilities document.

                                  The required parameters, as in all OGC GetCapabilities requests, are service=WPS, version=1.0.0 and request=GetCapabilities.

                                  An example of a GetCapabilities request is:

                                  http://localhost:8080/geoserver/ows?\n  service=WPS&\n  version=1.0.0&\n  request=GetCapabilities\n
                                  "},{"location":"services/wps/operations/#describeprocess","title":"DescribeProcess","text":"

                                  The DescribeProcess operation requests a description of a WPS process available through the service.

                                  The parameter identifier specifies the process to describe. Multiple processes can be requested, separated by commas (for example, identifier=JTS:buffer,gs:Clip). At least one process must be specified.

                                  Note

                                  As with all OGC parameters, the keys (request, version, etc) are case-insensitive, and the values (GetCapabilities, JTS:buffer, etc.) are case-sensitive. GeoServer is generally more relaxed about case, but it is best to follow the specification.

                                  The response is an XML document containing metadata about each requested process, including the following:

                                  • Process name, title and abstract
                                  • For each input and output parameter: identifier, title, abstract, multiplicity, and supported datatype and format

                                  An example request for the process JTS:buffer is:

                                  http://localhost:8080/geoserver/ows?\n  service=WPS&\n  version=1.0.0&\n  request=DescribeProcess&\n  identifier=JTS:buffer\n

                                  The response XML document contains the following information:

                                  +--------------------+-------------------------------------------------------------------------------------------------------------------------------------------------+ | Title | \"Buffers a geometry using a certain distance\" | +--------------------+-------------------------------------------------------------------------------------------------------------------------------------------------+ | Inputs | geom: \"The geometry to be buffered\" (geometry, mandatory) | | | | | | distance: \"The distance (same unit of measure as the geometry)\" (double, mandatory) | | | | | | quadrant segments: \"Number of quadrant segments. Use > 0 for round joins, 0 for flat joins, < 0 for mitred joins\" (integer, optional) | | | | | | capstyle: \"The buffer cap style, round, flat, square\" (literal value, optional) | +--------------------+-------------------------------------------------------------------------------------------------------------------------------------------------+ | Output formats | One of the GeoServer supported formats for Geometry encoding | +--------------------+-------------------------------------------------------------------------------------------------------------------------------------------------+

                                  In general, GeoServer processes use complex objects as inputs and objects, like geometries, feature collections and raster data.

                                  The formats available for input and output of each of those complex processes are commonly managed by Process Parameter IO classes, generic encoders/decoders that are attached to each process by the WPS machinery.

                                  In the core of GeoServer WPS, the following PPIOs are available:

                                  • For geometries, GML 2 and 3, GeoJSON, Well Known Text.
                                  • For feature collections, GML2 and 3, GeoJSON, Zipped shapefile, and KML.
                                  • For rasters, GeoTIFF, PNG, JPEG.

                                  The set of PPIOs can be extended by installing plugins. For example, the DXF extension<dxf> comes with a PPIO that can encode feature collections in DXF: when plugged in, most processes generating feature collections in output will offer to encode them also in DXF.

                                  "},{"location":"services/wps/operations/#execute","title":"Execute","text":"

                                  The Execute operation is a request to perform the process with specified input values and required output data items. The request may be made as either a GET URL, or a POST with an XML request document. Because the request has a complex structure, the POST form is more typically used.

                                  The inputs and outputs required for the request depend on the process being executed. GeoServer provides a wide variety of processes to process geometry, features, and coverage data. For more information see the section Process Cookbook.

                                  Below is an example of a Execute POST request. The example process (JTS:buffer) takes as input a geometry geom (in this case the point POINT(0 0)), a distance (with the value 10), a quantization factor quadrantSegments (here set to be 1), and a capStyle (specified as flat). The <ResponseForm> element specifies the format for the single output result to be GML 3.1.1.

                                  <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<wps:Execute version=\"1.0.0\" service=\"WPS\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xmlns=\"http://www.opengis.net/wps/1.0.0\" xmlns:wfs=\"http://www.opengis.net/wfs\" xmlns:wps=\"http://www.opengis.net/wps/1.0.0\" xmlns:ows=\"http://www.opengis.net/ows/1.1\" xmlns:gml=\"http://www.opengis.net/gml\" xmlns:ogc=\"http://www.opengis.net/ogc\" xmlns:wcs=\"http://www.opengis.net/wcs/1.1.1\" xmlns:xlink=\"http://www.w3.org/1999/xlink\" xsi:schemaLocation=\"http://www.opengis.net/wps/1.0.0 http://schemas.opengis.net/wps/1.0.0/wpsAll.xsd\">\n  <ows:Identifier>JTS:buffer</ows:Identifier>\n  <wps:DataInputs>\n    <wps:Input>\n      <ows:Identifier>geom</ows:Identifier>\n      <wps:Data>\n        <wps:ComplexData mimeType=\"application/wkt\"><![CDATA[POINT(0 0)]]></wps:ComplexData>\n      </wps:Data>\n    </wps:Input>\n    <wps:Input>\n      <ows:Identifier>distance</ows:Identifier>\n      <wps:Data>\n        <wps:LiteralData>10</wps:LiteralData>\n      </wps:Data>\n    </wps:Input>\n    <wps:Input>\n      <ows:Identifier>quadrantSegments</ows:Identifier>\n      <wps:Data>\n        <wps:LiteralData>1</wps:LiteralData>\n      </wps:Data>\n    </wps:Input>\n    <wps:Input>\n      <ows:Identifier>capStyle</ows:Identifier>\n      <wps:Data>\n        <wps:LiteralData>flat</wps:LiteralData>\n      </wps:Data>\n    </wps:Input>\n  </wps:DataInputs>\n  <wps:ResponseForm>\n    <wps:RawDataOutput mimeType=\"application/gml-3.1.1\">\n      <ows:Identifier>result</ows:Identifier>\n    </wps:RawDataOutput>\n  </wps:ResponseForm>\n</wps:Execute>\n

                                  The process performs a buffer operation using the supplied inputs, and returns the outputs as specified. The response from the request is (with numbers rounded for clarity):

                                  <?xml version=\"1.0\" encoding=\"utf-8\"?>\n<gml:Polygon xmlns:sch=\"http://www.ascc.net/xml/schematron\"\n xmlns:gml=\"http://www.opengis.net/gml\"\n xmlns:xlink=\"http://www.w3.org/1999/xlink\">\n  <gml:exterior>\n    <gml:LinearRing>\n      <gml:posList>\n        10.0 0.0\n        0.0 -10.0\n        -10.0 0.0 \n        0.0 10.0\n        10.0 0.0\n      </gml:posList>\n    </gml:LinearRing>\n  </gml:exterior>\n</gml:Polygon>\n

                                  For help in generating WPS requests you can use the built-in interactive WPS Request Builder.

                                  "},{"location":"services/wps/operations/#dismiss","title":"Dismiss","text":"

                                  Note

                                  This is a vendor extension of the GeoServer WPS Service. This operation is specific to GeoServer.

                                  According to the WPS specification, an asynchronous process execution returns a back link to a status location that the client can ping to get progress report about the process, and eventually retrieve its final results.

                                  In GeoServer this link is implemented as a pseudo-operation called GetExecutionStatus, and the link has the following structure:

                                  http://host:port/geoserver/ows?service=WPS&version=1.0.0&request=GetExecutionStatus&executionId=397e8cbd-7d51-48c5-ad72-b0fcbe7cfbdb\n

                                  The executionId identifies the running request, and can be used in the Dismiss vendor operation in order to cancel the execution of the process:

                                  http://host:port/geoserver/ows?service=WPS&version=1.0.0&request=Dismiss&executionId=397e8cbd-7d51-48c5-ad72-b0fcbe7cfbdb

                                  Upon receipt GeoServer will do its best to stop the running process, and subsequent calls to Dismiss or GetExecutionStatus will report that the executionId is not known anymore. Internally, GeoServer will stop any process that attempts to report progress, and poison input and outputs to break the execution of the process, but the execution of processes that already got their inputs, and are not reporting their progress back, will continue until their natural end.

                                  For example, let's consider the \"\" process, possibly working against a very large input GML geometry, to be fetched from another host. The process itself does a single call to a JTS function, which cannot report progress. Here are three possible scenarios, depending on when the Dismiss operation is invoked:

                                  • Dismiss is invoked while the GML is being retrieved, in this case the execution will stop immediately
                                  • Dismiss is invoked while the process is doing the buffering, in this case, the execution will stop as soon as the buffering is completed
                                  • Dismiss is invoked while the output GML is being encoded, also in this case the execution will stop immediately
                                  "},{"location":"services/wps/operations/#getexecutions","title":"GetExecutions","text":"

                                  Note

                                  This is a vendor extension of the GeoServer WPS Service. This operation is specific to GeoServer.

                                  This operation allows a client to recognize the list of WPS Executions.

                                  The client makes a simple \"GetExecutions\" request to the WPS Server, in order to get back an XML document containing the list of current Execution Statuses.

                                  It is also possible to filter the \"GetExecutions\" request along with simple parameters, in order to refine the output and get back only the executions status we are looking for.

                                  Adding a bit more to this, AUTHORIZATION headers must be sent along with the \"GetExecutions\" request; the WPS Server will be able, if the security subsystem is available and enable on the latter, to prove the list resources to the client itself.

                                  The operation will return only the list of available Executions the logged in user has started, except in the case it is an Administrator. In that case he will be able to get the whole list.

                                  If the \"lineage\" option of the WPS Execute Request has been specified, the client will be able to retrieve the Execute Inputs values provided to the process Identifier.

                                  "},{"location":"services/wps/operations/#statusinfo-document","title":"StatusInfo Document","text":"

                                  Refers to http://docs.opengeospatial.org/is/14-065/14-065.html section 9.5 and extends it.

                                  The StatusInfo document is used to provide identification and status information about jobs on a WPS server. The operation adds additional fields to the StatusInfo Document reporting also the WPS Process Identifier and other information on estimated execution and expiration time.

                                  "},{"location":"services/wps/operations/#getexecutionsoperation","title":"GetExecutionsOperation","text":"

                                  The GetExecutions Operation allows WPS clients to retrieve the list of available process jobs running on a WPS instance. The output is returned in the form of an XML document.

                                  The GetExecutions Operation returns only the list of available Executions the logged in user has started, except in the case it is an Administrator. In that case he will be able to get the whole list.

                                  "},{"location":"services/wps/operations/#getexecutionsrequest","title":"GetExecutionsRequest","text":"

                                  The GetExecutions Request is a common structure for synchronous execution. It inherits basic properties from the RequestBaseType and contains additional elements that allow to filter out, refine and order the list of available Process Jobs.

                                  "},{"location":"services/wps/operations/#getexecutionsresponse","title":"GetExecutionsResponse","text":"

                                  The GetExecutionsResponse it is always in the form of an XML document. Except in case of Exception, the response document will contain a list of StatusInfo elements filtered, refined or ordered accordingly to the specified parameters.

                                  "},{"location":"services/wps/operations/#response-paging","title":"Response paging","text":"

                                  Response paging is the ability of a client to scroll through a set of response values, N values at-a-time much like one scrolls through the response from a search engine one page at a time.

                                  Similar to the WFS 2.0.0 response paging mechanism (see section \"7.7.4.4 Response paging\" of the specification), the output will show to the client the following attributes as part of the response document.

                                  "},{"location":"services/wps/operations/#getexecutionsexceptions","title":"GetExecutionsExceptions","text":"

                                  When a WPS server encounters an error while performing an GetExecutionsResponse, it shall return an exception report as specified in clause 8 of [OGC 06-121r9]. If appropriate, the server shall use additional exception codes as defined in this section.

                                  "},{"location":"services/wps/operations/#retrieve-the-wps-execute-input-values","title":"Retrieve the WPS Execute Input values","text":"

                                  The GetExecutions Operations tries (best-effort) to retrieve the Input values specified from the Execute Request iff the lineage option has been provided to the Execute Request.

                                  Example requests with the lineage option active

                                  <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<wps:Execute version=\"1.0.0\" service=\"WPS\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xmlns=\"http://www.opengis.net/wps/1.0.0\" xmlns:wfs=\"http://www.opengis.net/wfs\" xmlns:wps=\"http://www.opengis.net/wps/1.0.0\" xmlns:ows=\"http://www.opengis.net/ows/1.1\" xmlns:gml=\"http://www.opengis.net/gml\" xmlns:ogc=\"http://www.opengis.net/ogc\" xmlns:wcs=\"http://www.opengis.net/wcs/1.1.1\" xmlns:xlink=\"http://www.w3.org/1999/xlink\" xsi:schemaLocation=\"http://www.opengis.net/wps/1.0.0 http://schemas.opengis.net/wps/1.0.0/wpsAll.xsd\">\n  <ows:Identifier>JTS:convexHull</ows:Identifier>\n  <wps:DataInputs>\n    <wps:Input>\n      <ows:Identifier>geom</ows:Identifier>\n      <wps:Reference mimeType=\"application/wkt\" xlink:href=\"http://www.geo-solutions.it/geoserver/wfs?\" method=\"GET\"/>\n    </wps:Input>\n  </wps:DataInputs>\n  <wps:ResponseForm>\n    <wps:ResponseDocument lineage=\"true\" storeExecuteResponse=\"true\" status=\"true\">\n      <wps:Output asReference=\"false\">\n        <ows:Identifier>result</ows:Identifier>\n      </wps:Output>\n    </wps:ResponseDocument>\n  </wps:ResponseForm>\n</wps:Execute>\n
                                  <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<wps:Execute version=\"1.0.0\" service=\"WPS\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xmlns=\"http://www.opengis.net/wps/1.0.0\" xmlns:wfs=\"http://www.opengis.net/wfs\" xmlns:wps=\"http://www.opengis.net/wps/1.0.0\" xmlns:ows=\"http://www.opengis.net/ows/1.1\" xmlns:gml=\"http://www.opengis.net/gml\" xmlns:ogc=\"http://www.opengis.net/ogc\" xmlns:wcs=\"http://www.opengis.net/wcs/1.1.1\" xmlns:xlink=\"http://www.w3.org/1999/xlink\" xsi:schemaLocation=\"http://www.opengis.net/wps/1.0.0 http://schemas.opengis.net/wps/1.0.0/wpsAll.xsd\">\n  <ows:Identifier>gs:BufferFeatureCollection</ows:Identifier>\n  <wps:DataInputs>\n    <wps:Input>\n      <ows:Identifier>features</ows:Identifier>\n      <wps:Reference mimeType=\"text/xml\" xlink:href=\"http://geoserver/wps\" method=\"POST\">\n        <wps:Body>\n            <wps:Execute version=\"1.0.0\" service=\"WPS\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xmlns=\"http://www.opengis.net/wps/1.0.0\" xmlns:wfs=\"http://www.opengis.net/wfs\" xmlns:wps=\"http://www.opengis.net/wps/1.0.0\" xmlns:ows=\"http://www.opengis.net/ows/1.1\" xmlns:gml=\"http://www.opengis.net/gml\" xmlns:ogc=\"http://www.opengis.net/ogc\" xmlns:wcs=\"http://www.opengis.net/wcs/1.1.1\" xmlns:xlink=\"http://www.w3.org/1999/xlink\" xsi:schemaLocation=\"http://www.opengis.net/wps/1.0.0 http://schemas.opengis.net/wps/1.0.0/wpsAll.xsd\">\n              <ows:Identifier>gs:CollectGeometries</ows:Identifier>\n              <wps:DataInputs>\n                <wps:Input>\n                  <ows:Identifier>features</ows:Identifier>\n                  <wps:Reference mimeType=\"text/xml\" xlink:href=\"http://geoserver/wfs\" method=\"POST\">\n                    <wps:Body>\n                      <wfs:GetFeature service=\"WFS\" version=\"1.0.0\" outputFormat=\"GML2\" xmlns:geonode=\"http://www.geonode.org/\">\n                        <wfs:Query typeName=\"geonode:san_andres_y_providencia_administrative\"/>\n                      </wfs:GetFeature>\n                    </wps:Body>\n                  </wps:Reference>\n                </wps:Input>\n              </wps:DataInputs>\n              <wps:ResponseForm>\n                <wps:RawDataOutput lineage=\"true\" mimeType=\"text/xml; subtype=gml/3.1.1\">\n                  <ows:Identifier>result</ows:Identifier>\n                </wps:RawDataOutput>\n              </wps:ResponseForm>\n            </wps:Execute>\n        </wps:Body>\n      </wps:Reference>\n    </wps:Input>\n    <wps:Input>\n      <ows:Identifier>distance</ows:Identifier>\n      <wps:Data>\n        <wps:LiteralData>0.005</wps:LiteralData>\n      </wps:Data>\n    </wps:Input>\n  </wps:DataInputs>\n  <wps:ResponseForm>\n    <wps:ResponseDocument lineage=\"true\" storeExecuteResponse=\"true\" status=\"true\">\n      <wps:Output asReference=\"false\">\n        <ows:Identifier>result</ows:Identifier>\n      </wps:Output>\n    </wps:ResponseDocument>\n  </wps:ResponseForm>\n</wps:Execute>\n
                                  <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<wps:Execute version=\"1.0.0\" service=\"WPS\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xmlns=\"http://www.opengis.net/wps/1.0.0\" xmlns:wfs=\"http://www.opengis.net/wfs\" xmlns:wps=\"http://www.opengis.net/wps/1.0.0\" xmlns:ows=\"http://www.opengis.net/ows/1.1\" xmlns:gml=\"http://www.opengis.net/gml\" xmlns:ogc=\"http://www.opengis.net/ogc\" xmlns:wcs=\"http://www.opengis.net/wcs/1.1.1\" xmlns:xlink=\"http://www.w3.org/1999/xlink\" xsi:schemaLocation=\"http://www.opengis.net/wps/1.0.0 http://schemas.opengis.net/wps/1.0.0/wpsAll.xsd\">\n  <ows:Identifier>gs:Clip</ows:Identifier>\n  <wps:DataInputs>\n    <wps:Input>\n      <ows:Identifier>features</ows:Identifier>\n      <wps:Reference mimeType=\"text/xml\" xlink:href=\"http://geoserver/wfs\" method=\"POST\">\n        <wps:Body>\n          <wfs:GetFeature service=\"WFS\" version=\"1.0.0\" outputFormat=\"GML2\" xmlns:geonode=\"http://www.geonode.org/\">\n            <wfs:Query typeName=\"geonode:san_andres_y_providencia_administrative\"/>\n          </wfs:GetFeature>\n        </wps:Body>\n      </wps:Reference>\n    </wps:Input>\n    <wps:Input>\n      <ows:Identifier>clip</ows:Identifier>\n      <wps:Data>\n        <wps:ComplexData mimeType=\"application/json\"><![CDATA[{\"type\":\"MultiLineString\",\"coordinates\":[[[-81.8254,12.199],[-81.8162,12.1827],[-81.812,12.1653],[-81.8156,12.1465],[-81.8269,12.1321],[-81.8433,12.123],[-81.8614,12.119],[-81.8795,12.1232],[-81.8953,12.1336],[-81.9049,12.1494],[-81.9087,12.1673],[-81.9054,12.1864],[-81.8938,12.2004],[-81.8795,12.2089],[-81.8593,12.2136],[-81.8399,12.2096],[-81.8254,12.199]],[[-81.6565,12.635],[-81.6808,12.6391],[-81.7085,12.6262],[-81.739,12.6046],[-81.7611,12.5775],[-81.775,12.5397],[-81.7708,12.5207],[-81.7667,12.4971],[-81.7701,12.4748],[-81.7646,12.4504],[-81.739,12.4369],[-81.7022,12.4389],[-81.6835,12.4578],[-81.6794,12.4883],[-81.6676,12.5153],[-81.651,12.541],[-81.66,12.5552],[-81.6489,12.5762],[-81.6274,12.5931],[-81.6309,12.6181],[-81.6565,12.635]],[[-81.2954,13.3496],[-81.3004,13.3132],[-81.3143,13.29],[-81.3413,13.2755],[-81.3731,13.2674],[-81.4058,13.2657],[-81.4335,13.2633],[-81.4531,13.2771],[-81.4574,13.3079],[-81.4663,13.3257],[-81.463,13.3476],[-81.447,13.3674],[-81.4228,13.3879],[-81.412,13.4126],[-81.403,13.4375],[-81.391,13.4582],[-81.3674,13.4687],[-81.3503,13.4574],[-81.3205,13.448],[-81.2941,13.4177],[-81.2846,13.3878],[-81.2954,13.3496]],[[-79.9333,14.9856],[-79.9333,15.5028]]]}]]></wps:ComplexData>\n      </wps:Data>\n    </wps:Input>\n  </wps:DataInputs>\n  <wps:ResponseForm>\n    <wps:ResponseDocument lineage=\"true\" storeExecuteResponse=\"true\" status=\"true\">\n      <wps:Output asReference=\"false\">\n        <ows:Identifier>result</ows:Identifier>\n      </wps:Output>\n    </wps:ResponseDocument>\n  </wps:ResponseForm>\n</wps:Execute>\n
                                  "},{"location":"services/wps/requestbuilder/","title":"WPS Request Builder","text":"

                                  The GeoServer WPS extension includes a request builder for testing out WPS processes through the Web administration interface. This tool can also be used to demonstrate processes, and construct your own examples.

                                  "},{"location":"services/wps/requestbuilder/#accessing-the-request-builder","title":"Accessing the request builder","text":"

                                  To access the WPS Request Builder:

                                  1. Navigate to the main Web administration interface.
                                  2. Click on the Demos link on the left side.
                                  3. Select WPS Request Builder from the list of demos.

                                  WPS request builder in the list of demos

                                  "},{"location":"services/wps/requestbuilder/#using-the-request-builder","title":"Using the request builder","text":"

                                  The WPS Request Builder primarily consists of a selection box listing all of the available processes, and two buttons, one to submit the WPS request, and another to display what the POST request looks like.

                                  Blank WPS request builder form

                                  The display changes depending on the process and input selected. JTS processes have available as inputs any of a GML/WKT-based feature collection, URL reference, or subprocess. GeoServer-specific processes have all these as options and also includes the ability to choose a GeoServer layer as input.

                                  For each process, a form will display based on the required and optional parameters associated with that process, if any.

                                  WPS request builder form to determine the bounds of topp:states

                                  To see the process as a POST request, click the Generate XML from process inputs/outputs button.

                                  Raw WPS POST request for the above process

                                  To execute the process, click the Execute Process button. The response will be displayed in a window or

                                  WPS server response

                                  "},{"location":"services/wps/security/","title":"WPS Security and input limits","text":"

                                  GeoServer service security is normally based on the generic OGC security configuration, however, when it comes to WPS there is also a need to restrict access to individual processes, in the same way that data security restricts access to layers.

                                  WPS security allows access to be determined by process group or by single process. Each process and process group can be enabled/disabled, or subject to access control based on the user roles.

                                  The WPS security page

                                  The WPS security configurations can be changed using the Web administration interface on the WPS security page under Security.

                                  Click to access the WPS security settings

                                  "},{"location":"services/wps/security/#setting-access-roles","title":"Setting access roles","text":"

                                  The list of roles attached to each group or process will determine which users can access which processes. If the list is empty the group/process will be available to all users, unless it has been disabled, in which case it won't be available to anyone.

                                  The roles string must be a list of roles separated by semicolons. The role editor provides auto-completion and also allows quick copy and paste of role lists from one process definition to the other:

                                  Role selector field with auto-complete

                                  "},{"location":"services/wps/security/#access-modes","title":"Access modes","text":"

                                  The process access mode configuration specifies how GeoServer will advertise secured processes and behave when a secured process is accessed without the necessary privileges. The parameter can be one of three values:

                                  • HIDE (default): The processes not available to the current user will be hidden from the user (not listed in the capabilities documents). Direct access will result in GeoServer claiming the process does not exist.
                                  • CHALLENGE: All processes will be shown in the capabilities documents, but an authentication request will be raised if a secured process is specifically requested by a user that does not have sufficient access rights
                                  • MIXED: The secured processes will not be shown in the capabilities documents for users not having sufficient access rights, but an authentication request will still be raised if a secured process is requested.
                                  "},{"location":"services/wps/security/#complex-inputs","title":"Complex Inputs","text":"

                                  By default, Execute requests support loading complex inputs from references to local files and external servers. This behavior can be restricted in the Complex Inputs section. When the flag is checked, an Execute request with an input reference that is not an internal WCS/WFS/WPS request will result in a service exception reporting the error.

                                  "},{"location":"services/wps/security/#input-limits","title":"Input limits","text":"

                                  The amount of resources used by a process is usually related directly to the inputs of the process itself. With this in mind, administrators can set three different type of limits on each process inputs:

                                  • The maximum size of complex inputs

                                  • The range of acceptable values for numeric values

                                  • The maximum multiplicity of repeatable inputs

                                    Note

                                    As an example of the last point, think of contour extraction, where the number of levels for the contours can drastically affect the execution time

                                  GeoServer allows the administrator to configure these limits, and fail requests that don't respect them.

                                  The maximum size can be given a global default on the WPS security page. It is also possible to define limits on a per-process basis by navigating to the process limits editor in the process list.

                                  Note

                                  Processes having a * beside the link have a defined set of limits

                                  The process selector, with access constraints and links to the limits configuration

                                  The process limits editor shows all inputs for which a limit can be provided. An empty field means that limits are disabled for that input.

                                  The process limit page, with input limits configured

                                  Warning

                                  In order for the limits to be saved: click on OK on this Process limits page; and then click OK on the Process selection page; and finally Save on the WPS security page.

                                  "},{"location":"services/wps/processes/","title":"Process Cookbook","text":"

                                  The Web Processing Service describes a method for publishing geospatial processes, but does not specify what those processes should be. Servers that implement WPS therefore have complete leeway in what types of processes to implement, as well as how those processes are implemented. This means that a process request designed for one type of WPS is not expected to work on a different type of WPS.

                                  GeoServer gathers processes into several different categories based on subject. These categories are grouped by prefix:

                                  • geo: geometry processes
                                  • ras: raster processes
                                  • vec: Vector processes
                                  • gs: GeoServer-specific processes

                                  This cookbook provides examples of some of the available process. Unless otherwise stated examples were generated with the WPS Request Builder using the sample data included with each GeoServer release.

                                  • Geometry Processes
                                  • GeoServer processes
                                  • Process chaining

                                  Note

                                  Previous releases of GeoServer grouped processes not by subject, but by the internal library responsible for implementation. The \"JTS\" and \"gt\" prefixes can be enabled to preserve backwards compatibility, or you may safely disable them off - their functionality is correctly sorted into the \"vec\" and \"geo\" categories.

                                  "},{"location":"services/wps/processes/chaining/","title":"Process chaining","text":"

                                  One of the benefits of WPS is its native ability to chain processes. Much like how functions can call other functions, a WPS process can use as its input the output of another process. Many complex functions can thus be combined in to a single powerful request.

                                  For example, let's take some of the sample data that is shipped with GeoServer and use the WPS engine to chain a few of the built in processes, which will allow users to perform geospatial analysis on the fly.

                                  The question we want to answer in this example is the following: How many miles of roads are crossing a protected area?

                                  The data that will be used for this example is included with a standard installation of GeoServer:

                                  • sf:roads: the layer that contains road information
                                  • sf:restricted: the layer representing restricted areas

                                  The restricted areas partially overlap the roads. We would like to know the total length of roads inside the restricted areas, as shown in the next screenshot. The road network is represented in white against a false color DEM (Digital Elevation Model). The restricted areas are represented with a dashed line in dark brown. The portion of the road network that is inside the restricted areas is drawn in red.

                                  Length of total roads inside restricted area

                                  In order to calculate the total length, we will need the following built in WPS processes:

                                  • gs:IntersectionFeatureCollection: returns the intersection between two feature collections adding the attributes from both of them
                                  • gs:CollectGeometries: collects all the default geometries in a feature collection and returns them as a single geometry collection
                                  • JTS:length: calculates the length of a geometry in the same unit of measure as the geometry

                                  The sequence in which these processes are executed is important. The first thing we want to do is intersect the road network with the restricted areas. This gives us the feature collection with all the roads that we are interested in. Then we collect those geometries into a single GeometryCollection so that the length can be calculated with the built in JTS algorithm.

                                  gs:IntersectionFeatureCollection \u2192 gs:CollectGeometries \u2192 JTS:length

                                  The sequence of processes determines how the WPS request is built, by embedding the first process into the second, the second into the third, etc. A process produces some output which will become the input of the next process, resulting in a processing pipeline that can solve complex spatial analysis with a single HTTP request. The advantage of using GeoServer's layers is that data is not being shipped back and forth between processes, resulting in very good performance.

                                  Here is the complete WPS request in XML format:

                                  <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<wps:Execute version=\"1.0.0\" service=\"WPS\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xmlns=\"http://www.opengis.net/wps/1.0.0\" xmlns:wfs=\"http://www.opengis.net/wfs\" xmlns:wps=\"http://www.opengis.net/wps/1.0.0\" xmlns:ows=\"http://www.opengis.net/ows/1.1\" xmlns:gml=\"http://www.opengis.net/gml\" xmlns:ogc=\"http://www.opengis.net/ogc\" xmlns:wcs=\"http://www.opengis.net/wcs/1.1.1\" xmlns:xlink=\"http://www.w3.org/1999/xlink\" xsi:schemaLocation=\"http://www.opengis.net/wps/1.0.0 http://schemas.opengis.net/wps/1.0.0/wpsAll.xsd\">\n\n  <ows:Identifier>JTS:length</ows:Identifier>\n  <wps:DataInputs>\n    <wps:Input>\n      <ows:Identifier>geom</ows:Identifier>\n  <wps:Reference mimeType=\"text/xml; subtype=gml/3.1.1\"\n              xlink:href=\"http://geoserver/wps\" method=\"POST\">\n      <wps:Body>\n        <wps:Execute version=\"1.0.0\" service=\"WPS\">\n          <ows:Identifier>gs:CollectGeometries</ows:Identifier>\n          <wps:DataInputs>\n            <wps:Input>\n              <ows:Identifier>features</ows:Identifier>\n              <wps:Reference mimeType=\"text/xml; subtype=wfs-collection/1.0\" xlink:href=\"http://geoserver/wps\" method=\"POST\">\n                <wps:Body>\n                  <wps:Execute version=\"1.0.0\" service=\"WPS\">\n                    <ows:Identifier>gs:IntersectionFeatureCollection</ows:Identifier>\n                    <wps:DataInputs>\n                      <wps:Input>\n                        <ows:Identifier>first feature collection</ows:Identifier>\n                        <wps:Reference mimeType=\"text/xml; subtype=wfs-collection/1.0\" xlink:href=\"http://geoserver/wfs\" method=\"POST\">\n                          <wps:Body>\n                            <wfs:GetFeature service=\"WFS\" version=\"1.0.0\" outputFormat=\"GML2\">\n                              <wfs:Query typeName=\"sf:roads\"/>\n                            </wfs:GetFeature>\n                          </wps:Body>\n                        </wps:Reference>\n                      </wps:Input>\n                      <wps:Input>\n                        <ows:Identifier>second feature collection</ows:Identifier>\n                        <wps:Reference mimeType=\"text/xml; subtype=wfs-collection/1.0\" xlink:href=\"http://geoserver/wfs\" method=\"POST\">\n                          <wps:Body>\n                            <wfs:GetFeature service=\"WFS\" version=\"1.0.0\" outputFormat=\"GML2\">\n                              <wfs:Query typeName=\"sf:restricted\"/>\n                            </wfs:GetFeature>\n                          </wps:Body>\n                        </wps:Reference>\n                      </wps:Input>\n                      <wps:Input>\n                        <ows:Identifier>first attributes to retain</ows:Identifier>\n                        <wps:Data>\n                          <wps:LiteralData>the_geom cat</wps:LiteralData>\n                        </wps:Data>\n                      </wps:Input>\n                      <wps:Input>\n                        <ows:Identifier>second attributes to retain</ows:Identifier>\n                        <wps:Data>\n                          <wps:LiteralData>cat</wps:LiteralData>\n                        </wps:Data>\n                      </wps:Input>\n                    </wps:DataInputs>\n                    <wps:ResponseForm>\n                      <wps:RawDataOutput mimeType=\"text/xml;\n                     subtype=wfs-collection/1.0\">\n                        <ows:Identifier>result</ows:Identifier>\n                      </wps:RawDataOutput>\n                    </wps:ResponseForm>\n                  </wps:Execute>\n                </wps:Body>\n              </wps:Reference>\n            </wps:Input>\n          </wps:DataInputs>\n          <wps:ResponseForm>\n            <wps:RawDataOutput mimeType=\"text/xml; subtype=gml/3.1.1\">\n              <ows:Identifier>result</ows:Identifier>\n            </wps:RawDataOutput>\n          </wps:ResponseForm>\n        </wps:Execute>\n      </wps:Body>\n    </wps:Reference>\n    </wps:Input>\n  </wps:DataInputs>\n  <wps:ResponseForm>\n    <wps:RawDataOutput>\n      <ows:Identifier>result</ows:Identifier>\n    </wps:RawDataOutput>\n  </wps:ResponseForm>\n</wps:Execute>\n

                                  You can save this XML request in a file called wps-chaining.xml and execute the request using cURL like this:

                                  curl -u admin:geoserver -H 'Content-type: xml' -XPOST -d@'wps-chaining.xml' http://localhost:8080/geoserver/wps

                                  The response is just a number, the total length of the roads that intersect the restricted areas, and should be around 25076.285 meters (the length process returns map units)

                                  To see WPS requests in action, you can use the built-in WPS Request Builder.

                                  "},{"location":"services/wps/processes/geo/","title":"Geometry Processes","text":"

                                  The geometry processes are built using the JTS Topology Suite (JTS). JTS is a Java library of functions for processing geometries in two dimensions. JTS conforms to the Simple Features Specification for SQL published by the Open Geospatial Consortium (OGC), similar to PostGIS. JTS includes common spatial functions such as area, buffer, intersection, and simplify.

                                  GeoServer WPS implements some of these functions as \"geo\" processes. The names and definitions of these processes are subject to change, so they have not been included here. For a full list of JTS processes, please see the GeoServer WPS capabilities document or browse with the WPS Request Builder.

                                  "},{"location":"services/wps/processes/gs/","title":"GeoServer processes","text":"

                                  GeoServer WPS includes a few processes created especially for use with GeoServer. These are usually GeoServer-specific functions, such as bounds and reprojection. They use an internal connection to the GeoServer WFS/WCS, not part of the WPS specification, for reading and writing data.

                                  As with the \"geo\" processes, the names and definitions of these processes are subject to change, so they have not been included here. For a full list of GeoServer-specific processes, please see the GeoServer WPS capabilities document (or browse with the WPS Request Builder.)

                                  "},{"location":"services/wps/processes/gs/#aggregation-process","title":"Aggregation process","text":"

                                  The aggregation process is used to perform common aggregation functions (sum, average, count) on vector data. The available outputs formats for this process are text/xml and application/json.

                                  The process parameters are described in the table bellow:

                                  Parameter Description Mandatory Multiple

                                  features Input feature collection. yes no

                                  aggregationAttribute Attribute on which to perform aggregation. yes no

                                  function An aggregate function to compute. Functions include Count, Average, Max, Median, Min, StdDev, and Sum. yes yes

                                  singlePass If TRUE computes all aggregation values in a single pass. This will defeat DBMS-specific optimizations. If a group by attribute is provided this parameter will be ignored. yes no

                                  groupByAttributes Group by attribute. no yes

                                  Follow some examples of the invocation of this process using GeoServer shipped topp:states layer.

                                  The examples can be tested with CURL:

                                  curl -u admin:geoserver -H 'Content-type: xml' -XPOST -d@'wps-request.xml' http://localhost:8080/geoserver/wps\n

                                  where wps-request.xml is the file that contains the request.

                                  "},{"location":"services/wps/processes/gs/#aggregate-example","title":"Aggregate Example","text":"

                                  Counts the total number of states, sum all the number of persons, computes the average number of persons per state and give the maximum and minimum number of persons in a state.

                                  Request:

                                  <?xml version=\"1.0\" encoding=\"UTF-8\"?><wps:Execute version=\"1.0.0\" service=\"WPS\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xmlns=\"http://www.opengis.net/wps/1.0.0\" xmlns:wfs=\"http://www.opengis.net/wfs\" xmlns:wps=\"http://www.opengis.net/wps/1.0.0\" xmlns:ows=\"http://www.opengis.net/ows/1.1\" xmlns:gml=\"http://www.opengis.net/gml\" xmlns:ogc=\"http://www.opengis.net/ogc\" xmlns:wcs=\"http://www.opengis.net/wcs/1.1.1\" xmlns:xlink=\"http://www.w3.org/1999/xlink\" xsi:schemaLocation=\"http://www.opengis.net/wps/1.0.0 http://schemas.opengis.net/wps/1.0.0/wpsAll.xsd\">\n  <ows:Identifier>gs:Aggregate</ows:Identifier>\n  <wps:DataInputs>\n    <wps:Input>\n      <ows:Identifier>features</ows:Identifier>\n      <wps:Reference mimeType=\"text/xml\" xlink:href=\"http://geoserver/wfs\" method=\"POST\">\n        <wps:Body>\n          <wfs:GetFeature service=\"WFS\" version=\"1.0.0\" outputFormat=\"GML2\" xmlns:sf=\"http://www.openplans.org/spearfish\">\n            <wfs:Query typeName=\"topp:states\"/>\n          </wfs:GetFeature>\n        </wps:Body>\n      </wps:Reference>\n    </wps:Input>\n    <wps:Input>\n      <ows:Identifier>aggregationAttribute</ows:Identifier>\n      <wps:Data>\n        <wps:LiteralData>PERSONS</wps:LiteralData>\n      </wps:Data>\n    </wps:Input>\n    <wps:Input>\n      <ows:Identifier>function</ows:Identifier>\n      <wps:Data>\n        <wps:LiteralData>Count</wps:LiteralData>\n      </wps:Data>\n    </wps:Input>\n    <wps:Input>\n      <ows:Identifier>function</ows:Identifier>\n      <wps:Data>\n        <wps:LiteralData>Average</wps:LiteralData>\n      </wps:Data>\n    </wps:Input>\n    <wps:Input>\n      <ows:Identifier>function</ows:Identifier>\n      <wps:Data>\n        <wps:LiteralData>Sum</wps:LiteralData>\n      </wps:Data>\n    </wps:Input>\n    <wps:Input>\n      <ows:Identifier>function</ows:Identifier>\n      <wps:Data>\n        <wps:LiteralData>Min</wps:LiteralData>\n      </wps:Data>\n    </wps:Input>\n    <wps:Input>\n      <ows:Identifier>function</ows:Identifier>\n      <wps:Data>\n        <wps:LiteralData>Max</wps:LiteralData>\n      </wps:Data>\n    </wps:Input>\n    <wps:Input>\n      <ows:Identifier>singlePass</ows:Identifier>\n      <wps:Data>\n        <wps:LiteralData>false</wps:LiteralData>\n      </wps:Data>\n    </wps:Input>\n  </wps:DataInputs>\n  <wps:ResponseForm>\n    <wps:RawDataOutput mimeType=\"application/json\">\n      <ows:Identifier>result</ows:Identifier>\n    </wps:RawDataOutput>\n  </wps:ResponseForm>\n</wps:Execute>\n

                                  The result:

                                  {\n  \"AggregationAttribute\": \"PERSONS\",\n  \"AggregationFunctions\": [\"Max\", \"Min\", \"Average\", \"Sum\", \"Count\"],\n  \"GroupByAttributes\": [],\n  \"AggregationResults\": [\n    [29760021, 453588, 5038397.020408163, 246881454, 49]\n  ]\n}\n

                                  The value of AggregationResults attribute should be read in a tabular way. The group by attributes come first in the order they appear in GroupByAttributes attribute. After comes the result of the aggregation functions in the order they appear in the AggregationFunctions attribute. In this case there is no group by attributes so the result only contains a row with the aggregation functions results. This is very similar to the result of an SQL query.

                                  This result should be interpreted like this:

                                  Max Min Average Sum Count

                                  29760021 453588 5038397.020408163 246881454 49

                                  To obtain the result in the XML format the request wps:ResponseForm element needs to be changed to:

                                  <wps:ResponseForm>\n  <wps:RawDataOutput mimeType=\"text/xml\">\n    <ows:Identifier>result</ows:Identifier>\n  </wps:RawDataOutput>\n</wps:ResponseForm>\n

                                  The result in XML format:

                                  <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<AggregationResults>\n  <Min>453588.0</Min>\n  <Max>2.9760021E7</Max>\n  <Average>5038397.020408163</Average>\n  <Sum>2.46881454E8</Sum>\n  <Count>49</Count>\n</AggregationResults>\n
                                  "},{"location":"services/wps/processes/gs/#aggregate-groupby-example","title":"Aggregate GroupBy Example","text":"

                                  This example count the number of states and the population average grouped by region.

                                  Request:

                                  <?xml version=\"1.0\" encoding=\"UTF-8\"?><wps:Execute version=\"1.0.0\" service=\"WPS\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xmlns=\"http://www.opengis.net/wps/1.0.0\" xmlns:wfs=\"http://www.opengis.net/wfs\" xmlns:wps=\"http://www.opengis.net/wps/1.0.0\" xmlns:ows=\"http://www.opengis.net/ows/1.1\" xmlns:gml=\"http://www.opengis.net/gml\" xmlns:ogc=\"http://www.opengis.net/ogc\" xmlns:wcs=\"http://www.opengis.net/wcs/1.1.1\" xmlns:xlink=\"http://www.w3.org/1999/xlink\" xsi:schemaLocation=\"http://www.opengis.net/wps/1.0.0 http://schemas.opengis.net/wps/1.0.0/wpsAll.xsd\">\n  <ows:Identifier>gs:Aggregate</ows:Identifier>\n  <wps:DataInputs>\n    <wps:Input>\n      <ows:Identifier>features</ows:Identifier>\n      <wps:Reference mimeType=\"text/xml\" xlink:href=\"http://geoserver/wfs\" method=\"POST\">\n        <wps:Body>\n          <wfs:GetFeature service=\"WFS\" version=\"1.0.0\" outputFormat=\"GML2\" xmlns:sf=\"http://www.openplans.org/spearfish\">\n            <wfs:Query typeName=\"topp:states\"/>\n          </wfs:GetFeature>\n        </wps:Body>\n      </wps:Reference>\n    </wps:Input>\n    <wps:Input>\n      <ows:Identifier>aggregationAttribute</ows:Identifier>\n      <wps:Data>\n        <wps:LiteralData>PERSONS</wps:LiteralData>\n      </wps:Data>\n    </wps:Input>\n    <wps:Input>\n      <ows:Identifier>function</ows:Identifier>\n      <wps:Data>\n        <wps:LiteralData>Count</wps:LiteralData>\n      </wps:Data>\n    </wps:Input>\n    <wps:Input>\n      <ows:Identifier>function</ows:Identifier>\n      <wps:Data>\n        <wps:LiteralData>Average</wps:LiteralData>\n      </wps:Data>\n    </wps:Input>\n    <wps:Input>\n      <ows:Identifier>singlePass</ows:Identifier>\n      <wps:Data>\n        <wps:LiteralData>false</wps:LiteralData>\n      </wps:Data>\n    </wps:Input>\n    <wps:Input>\n      <ows:Identifier>groupByAttributes</ows:Identifier>\n      <wps:Data>\n        <wps:LiteralData>SUB_REGION</wps:LiteralData>\n      </wps:Data>\n    </wps:Input>\n  </wps:DataInputs>\n  <wps:ResponseForm>\n    <wps:RawDataOutput mimeType=\"application/json\">\n      <ows:Identifier>result</ows:Identifier>\n    </wps:RawDataOutput>\n  </wps:ResponseForm>\n</wps:Execute>\n

                                  The result:

                                  { \n  \"AggregationAttribute\": \"PERSONS\",\n  \"AggregationFunctions\": [\"Average\", \"Count\"],\n  \"GroupByAttributes\": [\"SUB_REGION\"], \n  \"AggregationResults\": [ \n    [ \"N Eng\", 2201157.1666666665, 6 ], \n    [ \"W N Cen\", 2522812.8571428573, 7 ], \n    [ \"Pacific\", 12489678, 3 ], \n    [ \"Mtn\", 1690408.25, 8 ], \n    [ \"E S Cen\", 3998821.25, 4 ], \n    [ \"S Atl\", 4837695.666666667, 9 ], \n    [ \"Mid Atl\", 12534095.333333334, 3 ], \n    [ \"E N Cen\", 8209477.2, 5 ], \n    [ \"W S Cen\", 6709575.75, 4 ]\n  ]\n}\n

                                  Since there is a group by attribute the result contains a row for each different value of the group by attribute. Very similar to the result of an SQL query. If there is more that one group by attribute (which is not the case) their values will be in the order they appear in the GroupByAttributes attribute.

                                  This result should be interpreted like this:

                                  Sub Region Average count

                                  N Eng 2201157.1666666665 6

                                  W N Cen 2522812.8571428573 7

                                  Pacific 12489678 3

                                  Mtn 1690408.25 8

                                  E S Cen 3998821.25 4

                                  S Atl 4837695.666666667 9

                                  Mid Atl 12534095.333333334 3

                                  E N Cen 8209477.2 5

                                  W S Cen 6709575.75 4

                                  The result in XML format:

                                  <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<AggregationResults>\n  <GroupByResult>\n    <object-array>\n      <string>N Eng</string>\n      <double>2201157.1666666665</double>\n      <int>6</int>\n    </object-array>\n    <object-array>\n      <string>W N Cen</string>\n      <double>2522812.8571428573</double>\n      <int>7</int>\n    </object-array>\n    <object-array>\n      <string>Pacific</string>\n      <double>1.2489678E7</double>\n      <int>3</int>\n    </object-array>\n    <object-array>\n      <string>Mtn</string>\n      <double>1690408.25</double>\n      <int>8</int>\n    </object-array>\n    <object-array>\n      <string>E S Cen</string>\n      <double>3998821.25</double>\n      <int>4</int>\n    </object-array>\n    <object-array>\n      <string>S Atl</string>\n      <double>4837695.666666667</double>\n      <int>9</int>\n    </object-array>\n    <object-array>\n      <string>Mid Atl</string>\n      <double>1.2534095333333334E7</double>\n      <int>3</int>\n    </object-array>\n    <object-array>\n      <string>E N Cen</string>\n      <double>8209477.2</double>\n      <int>5</int>\n    </object-array>\n    <object-array>\n      <string>W S Cen</string>\n      <double>6709575.75</double>\n      <int>4</int>\n    </object-array>\n  </GroupByResult>\n</AggregationResults>\n
                                  "},{"location":"styling/","title":"Styling","text":"

                                  This section discusses the styling of geospatial data served through GeoServer.

                                  • Styles
                                  • SLD Styling
                                  • Generating SLD styles with QGIS
                                  • CSS Styling
                                  • YSLD Styling
                                  • MBStyle Styling
                                  • Styling Workshop
                                  "},{"location":"styling/css/","title":"CSS Styling","text":"

                                  The CSS extension uses a CSS-derived language instead of SLD. These CSS styles are internally converted to SLD, which is then used as normal by GeoServer. The CSS syntax is duplicated from SVG styling where appropriate, but extended to avoid losing facilities provided by SLD when possible.

                                  CSS is not a part of GeoServer by default, but is available as an extension.

                                  • Installing the GeoServer CSS extension
                                  • Tutorial: Styling data with CSS
                                  • Filter syntax
                                  • Metadata
                                  • Multi-valued properties
                                  • Property listing
                                  • CSS value types
                                  • Directives
                                  • Understanding Cascading in CSS
                                  • Nested rules
                                  • Rendering transformations in CSS
                                  • Styled marks
                                  • CSS Cookbook
                                  • Styling examples
                                  "},{"location":"styling/css/cascading/","title":"Understanding Cascading in CSS","text":"

                                  Cascading Style Sheets are the styling language of the web, use a simple syntax, but sometimes their simplicity can be deceitful if the writer is not aware of how the \"Cascading\" part of it works. The confusion might become greater by looking at the translated SLD, and wondering how all the SLD rules came to be from a much smaller set of CSS rules.

                                  This document tries to clarify how cascading works, how it can be controlled in SLD translation, and for those that would prefer simpler, if more verbose, styles, shows how to turn cascading off for good.

                                  "},{"location":"styling/css/cascading/#css-rules-application","title":"CSS rules application","text":"

                                  Given a certain feature, how are CSS rules applied to it? This is roughly the algorithm:

                                  • Locate all rules whose selector matches the current feature
                                  • Sort them by specificity, less specific to more specific
                                  • Have more specific rules add to and override properties set in less specific rules

                                  As you can see, depending on the feature attributes a new rule is built by the above algorithm, mixing all the applicable rules for that feature.

                                  The core of the algorithm allows to prepare rather succinct style sheets for otherwise very complex rule sets, by setting the common bits in less specific rules, and override them specifying the exceptions to the norm in more specific rules.

                                  "},{"location":"styling/css/cascading/#understanding-specificity","title":"Understanding specificity","text":"

                                  In web pages CSS specificity is setup as a tuple of four numbers called a,b,c,d:

                                  • a: set to 1 if the style is local to an element, that is, defined in the element style attribute
                                  • b: counts the number of ID attributes in the selector
                                  • c: count the number of other attributes and pseudo classes in the selector
                                  • d: count the number of element names or pseudo elements in the selector

                                  a is more important than b, which is more important than c, and so on, so for example, if one rule has a=1 and then second has a=0, the first is more specific, regardless of what values have b, c and d.

                                  Here are some examples from the CSS specification, from less specific to more specific:

                                  *             {}  /* a=0 b=0 c=0 d=0 -> specificity = 0,0,0,0 */\nli            {}  /* a=0 b=0 c=0 d=1 -> specificity = 0,0,0,1 */\nli:first-line {}  /* a=0 b=0 c=0 d=2 -> specificity = 0,0,0,2 */\nul li         {}  /* a=0 b=0 c=0 d=2 -> specificity = 0,0,0,2 */\nul ol+li      {}  /* a=0 b=0 c=0 d=3 -> specificity = 0,0,0,3 */\nh1 + *[rel=up]{}  /* a=0 b=0 c=1 d=1 -> specificity = 0,0,1,1 */\nul ol li.red  {}  /* a=0 b=0 c=1 d=3 -> specificity = 0,0,1,3 */\nli.red.level  {}  /* a=0 b=0 c=2 d=1 -> specificity = 0,0,2,1 */\n#x34y         {}  /* a=0 b=1 c=0 d=0 -> specificity = 0,1,0,0 */\nstyle=\"...\"       /* a=1 b=0 c=0 d=0 -> specificity = 1,0,0,0 */\n

                                  In cartographic CSS there are no HTML elements that could have a local style, so a is always zero. The others are calculated as follows:

                                  • b: number of feature ids in the rule
                                  • c: number of attributes in CQL filters and pseudo-classes (e.g., :mark) used in the selector
                                  • d: 1 if a typename is specified, 0 otherwise

                                  Here are some examples, from less to more specific:

                                  *                  {}  /* a=0 b=0 c=0 d=0 -> specificity = 0,0,0,0 */\ntopp:states        {}  /* a=0 b=0 c=0 d=1 -> specificity = 0,0,0,1 */\n:mark              {}  /* a=0 b=0 c=1 d=0 -> specificity = 0,0,1,0 */\n[a = 1 and b > 10] {}  /* a=0 b=0 c=1 d=0 -> specificity = 0,0,2,0 */\n#states.1          {}  /* a=0 b=1 c=0 d=0 -> specificity = 0,1,0,0 */\n

                                  In case two rules have the same specificity, the last one in the document wins.

                                  "},{"location":"styling/css/cascading/#understanding-css-to-sld-translation-in-cascading-mode","title":"Understanding CSS to SLD translation in cascading mode","text":"

                                  As discussed above, CSS rule application can potentially generate a different rule for each feature, depending on its attributes and how they get matched by the various CSS selectors.

                                  SLD on the other hand starts from the rules, and applies all of them, in turn, to each feature, painting each matching rule. The two evaluation modes are quite different, in order to turn CSS into SLD the translator has to generate every possible CSS rule combination, while making sure the generated SLD rules are mutually exclusive (CSS generated a single rule for a given feature in the end).

                                  The combination of all rules is called a power set, and the exclusivity is guaranteed by negating the filters of all previously generated SLD rules and adding to the current one. As one might imagine, this would result in a lot of rules, with very complex filters.

                                  The translator addresses the above concerns by applying a few basic strategies:

                                  • The generated filters are evaluated in memory, if the filter is found to be \"impossible\", that is, something that could never match an exiting feature, the associated rule is not emitted (e.g., a = 1 and a = 2 or a = 1 and not(a = 1))
                                  • The generated SLD has a vendor option <sld:VendorOption name=\"ruleEvaluation\">first</sld:VendorOption> which forces the renderer to give up evaluating further rules once one of them actually matched a feature

                                  The above is nice and sufficient in theory, while in practice it can break down with very complex CSS styles having a number of orthogonal selectors (e.g., 10 rules controlling the fill on the values of attribute a and 10 rules controlling the stroke on values of attribute b, and another 10 rules controlling the opacity of fill and stroke based on attribute c, resulting in 1000 possible combinations).

                                  For this reason by default the translator will try to generated simplified and fully exclusive rules only if the set of rules is \"small\", and will instead generate the full power set otherwise, to avoid incurring in a CSS to SLD translation time of minutes if not hours.

                                  The translation modes are controlled by the @mode directive, with the following values:

                                  • 'Exclusive': translate the style sheet in a minimum set of SLD rules with simplified selectors, taking whatever time and memory required
                                  • 'Simple': just generated the power set without trying to build a minimum style sheet, ensuring the translation is fast, even if the resulting SLD might look very complex
                                  • 'Auto': this is the default value, it will perform the power set expansion, and then will proceed in Exclusive mode if the power set contains less than 100 derived rules, or in Simple mode otherwise. The rule count threshold can be manually controlled by using the @autoThreshold directive.
                                  "},{"location":"styling/css/cascading/#the-flat-translation-mode","title":"The Flat translation mode","text":"

                                  The @mode directive has one last possible value, Flat, which enables a flat translation mode in which specificity and cascading are not applied.

                                  In this mode the CSS will be translated almost 1:1 into a corresponding SLD, each CSS rule producing and equivalent SLD rule, with the exception of the rules with pseudo-classes specifying how to stroke/fill marks and symbols in general.

                                  Care should be taken when writing rules with pseudo classes, they will be taken into consideration only if their selector matches the one of the preceding rule. Consider this example:

                                  @mode \"Flat\";\n\n[type = 'Capital'] { \n  mark: symbol(circle);\n}\n\n[type = 'Capital'] :mark {\n  fill: white;\n  size: 6px;\n}\n\n:mark {\n  stroke: black;\n  stroke-width: 2px;\n}\n

                                  In the above example, the first rule with the :mark pseudo class will be taken into consideration and merged with the capital one, the second one instead will be ignored. The resulting SLD will thus not contain any stroke specification for the 'circle' mark:

                                  <?xml version=\"1.0\" encoding=\"UTF-8\"?><sld:StyledLayerDescriptor xmlns=\"http://www.opengis.net/sld\" \n      xmlns:sld=\"http://www.opengis.net/sld\" xmlns:ogc=\"http://www.opengis.net/ogc\" \n      xmlns:gml=\"http://www.opengis.net/gml\" version=\"1.0.0\">\n  <sld:NamedLayer>\n    <sld:Name/>\n    <sld:UserStyle>\n      <sld:Name>Default Styler</sld:Name>\n      <sld:FeatureTypeStyle>\n        <sld:Rule>\n          <ogc:Filter>\n            <ogc:PropertyIsEqualTo>\n              <ogc:PropertyName>type</ogc:PropertyName>\n              <ogc:Literal>Capital</ogc:Literal>\n            </ogc:PropertyIsEqualTo>\n          </ogc:Filter>\n          <sld:PointSymbolizer>\n            <sld:Graphic>\n              <sld:Mark>\n                <sld:WellKnownName>circle</sld:WellKnownName>\n                <sld:Fill>\n                  <sld:CssParameter name=\"fill\">#ffffff</sld:CssParameter>\n                </sld:Fill>\n              </sld:Mark>\n              <sld:Size>6</sld:Size>\n            </sld:Graphic>\n          </sld:PointSymbolizer>\n        </sld:Rule>\n      </sld:FeatureTypeStyle>\n    </sld:UserStyle>\n  </sld:NamedLayer>\n</sld:StyledLayerDescriptor>\n

                                  The advantages of flat mode are:

                                  • Easy to understand, the rules are applied in the order they are written
                                  • Legend control, the generated legend contains no surprises as rules are not mixed together and are not reordered

                                  The main disadvantage is that there is no more a way to share common styling bits in general rules, all common bits have to be repeated in all rules.

                                  Note

                                  In the future we hope to add the ability to nest rules, which is going to address some of the limitations of flat mode without introducing the most complex bits of the standard cascading mode

                                  "},{"location":"styling/css/cascading/#comparing-cascading-vs-flat-modes-an-example","title":"Comparing cascading vs flat modes, an example","text":"

                                  Consider the following CSS:

                                  * { stroke: black; stroke-width: 10 }\n\n[cat = 'important'] { stroke: yellow; }\n

                                  If the above style is translated in cascading mode, it will generate two mutually exclusive SLD rules:

                                  • One applying a 10px wide yellow stroke on all features whose cat attribute is 'important'
                                  • One applying a 10px wide black stroke on all feature whose cat attribute is not 'important'

                                  Thus, each feature will be painted by a single line, either yellow or black.

                                  If instead the style contains a @mode 'Flat' directive at the top, it will generated two non mutually exclusive SLD rules:

                                  • One applying a 10px wide black stroke on all features
                                  • One applying a 1px wide yewllow stroke on all feature whose cat attribute is 'important'

                                  Thus, all features will at least be painted 10px black, but the 'important' ones will also have a second 1px yellow line on top of the first one

                                  "},{"location":"styling/css/directives/","title":"Directives","text":"

                                  A directive is a CSS top level declaration that allows control of some aspects of the stylesheet application or translation to SLD. All directives are declared at the beginning of the CSS sheet and follow the same syntax:

                                  @name value;\n

                                  For example:

                                  @mode 'Flat';\n@styleName 'The name';\n@styleTitle 'The title;\n@styleAbstract 'This is a longer description'\n\n* { \n  stroke: black \n}\n\n[cat = 10] { \n  stroke: yellow; stroke-width: 10 \n}\n
                                  "},{"location":"styling/css/directives/#supported-directives","title":"Supported directives","text":"

                                  Directive Type Meaning Accepts Expression?

                                  mode String, Exclusive, Simple, Auto, Flat Controls how the CSS is translated to SLD. Exclusive, Simple and Auto are cascaded modes, Flat turns off cascading and has the CSS behave like a simplified syntax SLD sheet. See Understanding Cascading in CSS for an explanation of how the various modes work false

                                  styleName String The generated SLD style name No

                                  styleTitle String The generated SLD style title No

                                  styleAbstract String The generated SLD style abstract/description No

                                  "},{"location":"styling/css/filters/","title":"Filter syntax","text":"

                                  Filters limit the set of features affected by a rule's properties. There are several types of simple filters, which can be combined to provide more complex filters for rules.

                                  "},{"location":"styling/css/filters/#combining-filters","title":"Combining filters","text":"

                                  Combination is done in the usual CSS way. A rule with two filters separated by a comma affects any features that match either filter, while a rule with two filters separated by only whitespace affects only features that match both filters. Here's an example using a basic attribute filter (described below):

                                  /* Matches places where the lake is flooding */\n[rainfall>12] [lakes>1] {\n    fill: black;\n}\n\n/* Matches wet places */\n[rainfall>12], [lakes>1] {\n    fill: blue;\n}\n

                                  When writing a selector that uses both and and or combinators, remember that the and combinator has higher precedence. For example:

                                  restricted [cat='2'], [cat='3'], [cat='4'] [@sd <= 200k] [@sd > 100k] {\n  fill: #EE0000;\n}\n

                                  The above selector should be read as:

                                  • typename is 'restricted' and cat='2' or
                                  • cat='3' or
                                  • cat='4' and scale is between 100000 and 200000

                                  If instead the intention was to combine in or just the three cat filters, the right syntax would have been:

                                  restricted [cat='2' or cat='3' or cat='4'] [@sd <= 200k] [@sd > 100k] {\n  fill: #EE0000;\n}\n

                                  Which should be read as:

                                  • typename is 'restricted' and
                                  • (cat='2' or cat='3' or cat='4') and
                                  • scale is between 100000 and 200000
                                  "},{"location":"styling/css/filters/#filtering-on-data-attributes","title":"Filtering on data attributes","text":"

                                  An attribute filter matches some attribute of the data (for example, a column in a database table). This is probably the most common type of filter. An attribute filter takes the form of an attribute name and a data value separated by some predicate operator (such as the less-than operator <).

                                  Supported predicate operators include the following:

                                  Operator Meaning

                                  = The property must be exactly equal to the specified value.

                                  <> The property must not be exactly equal to the specified value.

                                  > The property must be greater than (or alphabetically later than) the specified value.

                                  >= The property must be greater than or equal to the specified value.

                                  < The property must be less than (or alphabetically earlier than) the specified value.

                                  <= The property must be less than or equal to the specified value.

                                  LIKE The property must match the pattern described by the specified value. Patterns use _ to indicate a single unspecified character and % to indicate an unknown number of unspecified characters.

                                  For example, to only render outlines for the states whose names start with letters in the first half of the alphabet, the rule would look like:

                                  [STATE_NAME<='M'] {\n    stroke: black;\n}\n

                                  Note

                                  The current implementation of property filters uses ECQL syntax, described on the GeoTools documentation.

                                  "},{"location":"styling/css/filters/#filtering-on-type","title":"Filtering on type","text":"

                                  When dealing with data from multiple sources, it may be useful to provide rules that only affect one of those sources. This is done very simply; just specify the name of the layer as a filter:

                                  states {\n    stroke: black;\n}\n
                                  "},{"location":"styling/css/filters/#filtering-by-id","title":"Filtering by ID","text":"

                                  For layers that provide feature-level identifiers, you can style specific features simply by specifying the ID. This is done by prefixing the ID with a hash sign (#):

                                  #states.2 {\n    stroke: black;\n}\n

                                  Note

                                  In CSS, the . character is not allowed in element ids; and the #states.foo selector matches the element with id states only if it also has the class foo. Since this form of identifier comes up so frequently in GeoServer layers, the CSS module deviates from standard CSS slightly in this regard. Future revisions may use some form of munging to avoid this deviation.

                                  "},{"location":"styling/css/filters/#filtering-by-rendering-context-scale","title":"Filtering by rendering context (scale)","text":"

                                  Often, there are aspects of a map that should change based on the context in which it is being viewed. For example, a road map might omit residential roads when being viewed at the state level, but feature them prominently at the neighborhood level. Details such as scale level are presented as pseudo-attributes; they look like property filters, but the property names start with an @ symbol:

                                  [roadtype = 'Residential'][@sd > 100k] {\n    stroke: black;\n}\n

                                  The context details that are provided are as follows:

                                  Pseudo-Attribute Meaning

                                  @sd The scale denominator for the current rendering. More explicitly, this is the ratio of real-world distance to screen/rendered distance.

                                  @scale Same as above, the scale denominator (not scale) for the current rendering. Supported for backwards compatibility

                                  The scale value can be expressed as a plain number, for for brevity and readability the suffixes k (kilo), M (mega), G (giga) can be used, for example:

                                  [@sd > 100k]\n[@sd < 12M]\n[@sd < 1G]\n

                                  Note

                                  While property filters (currently) use the more complex ECQL syntax, pseudo-attributes cannot use complex expressions and MUST take the form of ."},{"location":"styling/css/filters/#filtering-symbols","title":"Filtering symbols","text":"

                                  When using symbols to create graphics inline, you may want to apply some styling options to them. You can specify style attributes for built-in symbols by using a few special selectors:

                                  PseudoSelector Meaning

                                  :mark specifies that a rule applies to symbols used as point markers

                                  :stroke specifies that a rule applies to symbols used as stroke patterns

                                  :fill specifies that a rule applies to symbols used as fill patterns

                                  :symbol specifies that a rule applies to any symbol, regardless of which context it is used in

                                  :nth-mark(n) specifies that a rule applies to the symbol used for the nth stacked point marker on a feature.

                                  :nth-stroke(n) specifies that a rule applies to the symbol used for the nth stacked stroke pattern on a feature.

                                  :nth-fill(n) specifies that a rule applies to the symbol used for the nth stacked fill pattern on a feature.

                                  :nth-symbol(n) specifies that a rule applies to the symbol used for the nth stacked symbol on a feature, regardless of which context it is used in.

                                  For more discussion on using these selectors, see Styled marks.

                                  "},{"location":"styling/css/filters/#global-rules","title":"Global rules","text":"

                                  Sometimes it is useful to have a rule that matches all features, for example, to provide some default styling for your map (remember, by default nothing is rendered). This is accomplished using a single asterisk * in place of the usual filter. This catch-all rule can be used in complex expressions, which may be useful if you want a rule to provide defaults as well as overriding values for some features:

                                  * {\n    stroke: black;\n}\n
                                  "},{"location":"styling/css/install/","title":"Installing the GeoServer CSS extension","text":"

                                  The CSS extension is listed among the other extension downloads on the GeoServer download page.

                                  The installation process is similar to other GeoServer extensions:

                                  1. Download the css

                                    Verify that the version number in the filename corresponds to the version of GeoServer you are running (for example 2.24.2 above).

                                  2. Extract the contents of the archive into the WEB-INF/lib directory in GeoServer. Make sure you do not create any sub-directories during the extraction process.

                                  3. Restart GeoServer.

                                  If installation was successful, you will see a new CSS entry in the Styles editor.

                                  CSS format in the new style page

                                  After installation, you may wish to read the tutorial: Styling data with CSS.

                                  "},{"location":"styling/css/metadata/","title":"Metadata","text":"

                                  One feature that appears in SLD that has no analog in CSS is the ability to provide metadata for styles and style rules. For example, this SLD embeds a title for its single rule:

                                  <?xml version=\"1.0\" encoding=\"ISO-8859-1\"?>\n<StyledLayerDescriptor version=\"1.0.0\" \n    xmlns=\"http://www.opengis.net/sld\" \n    xmlns:ogc=\"http://www.opengis.net/ogc\"\n    xmlns:xlink=\"http://www.w3.org/1999/xlink\" \n    xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" \n    xmlns:gml=\"http://www.opengis.net/gml\"\n    xsi:schemaLocation=\"http://www.opengis.net/sld \n        http://schemas.opengis.net/sld/1.0.0/StyledLayerDescriptor.xsd\"\n>\n  <NamedLayer>\n    <Name>Country Borders</Name>\n    <UserStyle>\n      <Name>borders</Name>\n      <Title>Country Borders</Title>\n      <Abstract>\n          Borders of countries, in an appropriately sovereign aesthetic.\n      </Abstract>\n      <FeatureTypeStyle>\n        <Rule>\n          <Title>Borders</Title>\n          <LineSymbolizer>\n            <Stroke>\n              <CssParameter name=\"stroke-width\">0.2</CssParameter>\n            </Stroke>\n          </LineSymbolizer>\n        </Rule>\n     </FeatureTypeStyle>\n    </UserStyle>\n  </NamedLayer>\n</StyledLayerDescriptor>\n

                                  Software such as GeoServer can use this metadata to automatically generate nice legend images directly from the style. You don't have to give up this ability when styling maps in CSS; just add comment before your rules including lines that start with @title and @abstract. Here is the analogous style in CSS:

                                  /*\n * @title This is a point layer.\n * @abstract This is an abstract point layer.\n */\n* {\n    mark: mark(circle);\n}\n

                                  Rules can provide either a title, an abstract, both, or neither. The SLD Name for a rule is autogenerated based on the filters from the CSS rules that combined to form it, for aid in troubleshooting.

                                  "},{"location":"styling/css/metadata/#combined-rules","title":"Combined rules","text":"

                                  One thing to keep in mind when dealing with CSS styles is that multiple rules may apply to the same subset of map features, especially as styles get more complicated. Metadata is inherited similarly to CSS properties, but metadata fields are combined instead of overriding less specific rules. That means that when you have a style like this:

                                  /* @title Borders */\n* {\n    stroke: black;\n}\n\n/* @title Parcels */\n[category='parcel'] {\n    fill: blue;\n}\n

                                  The legend entry for parcels will have the title 'Parcels with Borders'. If you don't like this behavior, then only provide titles for the most specific rules in your style. (Or, suggest something better in an issue report!) Rules that don't provide titles are simply omitted from title aggregation.

                                  "},{"location":"styling/css/multivalueprops/","title":"Multi-valued properties","text":"

                                  When rendering maps, it is sometimes useful to draw the same feature multiple times. For example, you might want to stroke a roads layer with a thick line and then a slimmer line of a different color to create a halo effect.

                                  In GeoServer's css module, all properties may have multiple values. There is a distinction between complex properties, and multi-valued properties. Complex properties are separated by spaces, while multi-valued properties are separated by commas. So, this style fills a polygon once:

                                  * {\n    fill: url(\"path/to/img.png\") red;\n}\n

                                  Using red as a fallback color if the image cannot be loaded. If you wanted to draw red on top of the image, you would have to style like so:

                                  * {\n    fill: url(\"path/to/img.png\"), red;\n    /* set a transparency for the second fill,\n       leave the first fully opaque. */\n    fill-opacity: 100%, 20%;\n}\n

                                  For each type of symbolizer (fill, mark, stroke, and label) the number of values determines the number of times the feature will be drawn. For example, you could create a bulls-eye effect by drawing multiple circles on top of each other with decreasing sizes:

                                  * {\n    mark: symbol(circle), symbol(circle), symbol(circle), symbol(circle);\n    mark-size: 40px, 30px, 20px, 10px;\n}\n

                                  If you do not provide the same number of values for an auxiliary property, the list will be repeated as many times as needed to finish. So:

                                  * {\n    mark: symbol(circle), symbol(circle), symbol(circle), symbol(circle);\n    mark-size: 40px, 30px, 20px, 10px;\n    mark-opacity: 12%;\n}\n

                                  makes all those circles 12% opaque. (Note that they are all drawn on top of each other, so the center one will appear 4 times as solid as the outermost one.)

                                  "},{"location":"styling/css/multivalueprops/#inheritance","title":"Inheritance","text":"

                                  For purposes of inheritance/cascading, property lists are treated as indivisible units. For example:

                                  * {\n    stroke: red, green, blue;\n    stroke-width: 10px, 6px, 2px;\n}\n\n[type='special'] {\n    stroke: pink;\n}\n

                                  This style will draw the 'special' features with only one outline. It has stroke-width: 10px, 6px, 2px; so that outline will be 10px wide.

                                  "},{"location":"styling/css/nested/","title":"Nested rules","text":"

                                  Starting with GeoServer 2.10 the CSS modules supports rule nesting, that is, a child rule can be written among properties of a parent rule. The nested rules inherits the parent rule selector and properties, adding its own extra selectors and property overrides.

                                  Each nested rule can be written as normal, however, if other rules or properties follow, it must be terminated with a semicolon (this char being the separator in the CSS language).

                                  Nesting is a pure syntax improvement, as such it does not actually provide extra functionality, besides more compact and hopefully readable styles.

                                  This is an example of a CSS style using only cascading to get a different shape, fill and stroke color for a point symbol in case the type attribute equals to important:

                                  [@sd < 3000] {\n  mark: symbol(circle)\n}\n\n[@sd < 3000] :mark {\n  fill: gray;\n  size: 5\n}\n\n[@sd < 3000] [type = 'important'] {\n  mark: symbol('triangle')\n}\n\n[@sd < 3000] [type = 'important'] :mark {\n  fill: red;\n  stroke: yellow\n}\n

                                  This second version uses rule nesting getting a more compact expression, putting related symbology element close by:

                                  [@sd < 3000] {\n   mark: symbol(circle);\n   :mark {\n      fill: gray;\n      size: 5\n   };\n   [type = 'important'] {\n      mark: symbol(triangle);\n      :mark {\n        fill: red;\n        stroke: yellow\n      }\n   }\n}\n
                                  "},{"location":"styling/css/properties/","title":"Property listing","text":"

                                  This page lists the supported rendering properties. See CSS value types for more information about the value types for each.

                                  "},{"location":"styling/css/properties/#css_properties_point","title":"Point symbology","text":"

                                  Property Type Meaning Accepts Expression?

                                  mark url, symbol The image or well-known shape to render for points yes

                                  mark-composite string The composite mode to be used and the optional opacity separated with a comma. See the full list of available modes. no

                                  mark-mime string (MIME Type) The type of the image referenced by a url() No, defaults to 'image/jpeg'

                                  mark-geometry expression An expression to use for the geometry when rendering features yes

                                  mark-size length The width to assume for the provided image. The height will be adjusted to preserve the source aspect ratio. yes

                                  mark-rotation angle A rotation to be applied (clockwise) to the mark image. yes

                                  z-index integer Controls the z ordering of output no

                                  mark-label-obstacle boolean If true the point symbol will be considered an obstacle for labels, no label will overlap it no

                                  mark-anchor expression The part of the mark to place over the point or middle of the polygon. This takes 2 values - x y where x=0 is the left edge of the label, x=1 is the right edge. y=0 is the bottom edge of the label, y=1 is the top edge. Specify 0.5 0.5 to centre a label. yes

                                  mark-offset expression This is for fine-tuning mark-anchor. x and y values specify pixel offsets to adjust the mark position. yes

                                  "},{"location":"styling/css/properties/#css_properties_line","title":"Line symbology","text":"

                                  Property Type Meaning Accepts Expression?

                                  stroke color, url, symbol The color, graphic, or well-known shape to use to stroke lines or outlines yes

                                  stroke-composite string The composite mode to be used and the optional opacity separated with a comma. See the full list of available modes. no

                                  stroke-geometry expression An expression to use for the geometry when rendering features. yes

                                  stroke-offset expression Draws a parallel line using the specified distance, positive values offset left, negative right. yes

                                  stroke-mime string (MIME Type) The type of the image referenced by a url() No, defaults to 'image/jpeg'

                                  stroke-opacity percentage A value in the range of 0 (fully transparent) to 1.0 (fully opaque) yes

                                  stroke-width length The width to use for stroking the line. yes

                                  stroke-size length An image or symbol used for the stroke pattern will be stretched or squashed to this size before rendering. If this value differs from the stroke-width, the graphic will be repeated or clipped as needed. yes

                                  stroke-rotation angle A rotation to be applied (clockwise) to the stroke image. See also the stroke- repeat property. yes

                                  stroke-linecap keyword: butt, square, round The style to apply to the ends of lines drawn yes

                                  stroke-linejoin keyword: miter, round, bevel The style to apply to the \"elbows\" where segments of multi-line features meet. yes

                                  stroke-dasharray list of lengths The lengths of segments to use in a dashed line. no

                                  stroke-dashoffset length How far to offset the dash pattern from the ends of the lines. yes|

                                  stroke-repeat keyword: repeat, stipple How to use the provided graphic to paint the line. If repeat, then the graphic is repeatedly painted along the length of the line (rotated appropriately to match the line's direction). If stipple, then the line is treated as a polygon to be filled. yes

                                  z-index integer Controls the z ordering of output no

                                  stroke-label-obstacle boolean If true the line will be considered an obstacle for labels, no label will overlap it no

                                  "},{"location":"styling/css/properties/#css_properties_polygon","title":"Polygon symbology","text":"

                                  Property Type Meaning Accepts Expression?

                                  fill color, url, symbol The color, graphic, or well-known shape to use to stroke lines or outlines yes

                                  fill-composite string The composite mode to be used and the optional opacity separated with a comma. See the full list of available modes. no

                                  fill-geometry expression An expression to use for the geometry when rendering features. yes

                                  fill-mime string (MIME Type) The type of the image referenced by a url() No, defaults to 'image/jpeg'

                                  fill-opacity percentage A value in the range of 0 (fully transparent) to 1.0 (fully opaque) yes

                                  fill-size length The width to assume for the image or graphic provided. yes

                                  fill-rotation angle A rotation to be applied (clockwise) to the fill image. yes

                                  z-index integer Controls the z ordering of output no

                                  fill-label-obstacle boolean If true the polygon will be considered an obstacle for labels, no label will overlap it no

                                  graphic-margin List of lengths A list of 1 to 4 values, specifying the space between repeated graphics in a texture paint. One value is uniform spacing in all directions, two values are considered top/bottom and right/left, three values are considered top, right/left, bottom, four values are read as top,right,bottom,left. no

                                  random none,grid,free Activates random distribution of symbols in a texture fill tile. See Fills with randomized symbols for details. Defaults to \"none\" no

                                  random-seed integer number The seed for the random generator. Defaults to 0 no

                                  random-rotation none/free When set to \"free\" activates random rotation of the symbol in addition to random distribution. Defaults to \"none\" no

                                  random-symbol-count positive integer number Number of symbols to be placed in the texture fill tile. May not be respected due to location conflicts (no two symbols are allowed to overlap). Defaults to 16. no

                                  random-tile-size positive integer number Size of the texture paint tile that will be filled with the random symbols. Defaults to 256. no

                                  "},{"location":"styling/css/properties/#css_properties_text1","title":"Text symbology (labelling) - part 1","text":"

                                  Property Type Meaning Accepts Expression?

                                  label string The text to display as labels for features yes

                                  label-geometry expression An expression to use for the geometry when rendering features. yes

                                  label-anchor expression The part of the label to place over the point or middle of the polygon. This takes 2 values - x y where x=0 is the left edge of the label, x=1 is the right edge. y=0 is the bottom edge of the label, y=1 is the top edge. Specify 0.5 0.5 to centre a label. yes

                                  label-offset expression This is for fine-tuning label-anchor. x and y values specify pixels to adjust the label position. For lines, a single value will make the label be parallel to the line, at the given distance, while two values will force a point style placement, with the label painted horizontally at the center of the line (plus the given offsets) yes

                                  label-rotation expression Clockwise rotation of label in degrees. yes

                                  label-z-index expression Used to determine which labels are drawn on top of other labels. Lower z-indexes are drawn on top. yes

                                  shield mark, symbol A graphic to display behind the label, such as a highway shield. yes

                                  shield-mime string (MIME Type) The type of the image referenced by a url() No, defaults to 'image/jpeg'

                                  shield-placement one of label, independent, defaults to label Placement of the shield relative to the label. The default is label, meaning the shield will move along with the label and be centered with it (classic road shield). independent places the shield independently instead, using its own anchor and offset properties. The latter is useful to build \"point and label\" compositions (e.g., city labels) so that the point won't show up if the label does not (as an alternative to a mark and label setup, where the mark will always show up). no

                                  shield-anchor expression The part of the shield to place over the point or middle of the polygon. This takes 2 values - x y where x=0 is the left edge of the label, x=1 is the right edge. y=0 is the bottom edge of the label, y=1 is the top edge. Specify 0.5 0.5 to centre a label. This property activates only if the shield-placement one is set to independent, otherwise the shield will be centered with the label. yes

                                  shield-offset expression This is for fine-tuning shield-anchor. x and y values specify pixels to adjust the shield position. This property activates only if the shield-placement one is set to independent, otherwise the shield will be centered with the label. yes

                                  font-family string The name of the font or font family to use for labels yes

                                  font-fill fill The fill to use when rendering fonts yes

                                  font-style keyword: normal, italic, oblique The style for the lettering yes

                                  font-weight keyword: normal, bold The weight for the lettering yes

                                  font-size length The size for the font to display. yes

                                  font-opacity percentage The opacity of the text, from 0 (fully transparent) to 1.0 (fully opaque). yes

                                  halo-radius length The size of a halo to display around the lettering (to enhance readability). This is required to activate the halo feature. yes

                                  halo-color color The color for the halo yes

                                  halo-opacity percentage The opacity of the halo, from 0 (fully transparent) to 1.0 (fully opaque). yes

                                  label-padding length The amount of 'padding' space to provide around labels. Labels will not be rendered closer together than this threshold. This is equivalent to the spaceAround<labeling_space_around> vendor parameter. no

                                  label-group one of: true or false If true, the render will treat features with the same label text as a single feature for the purpose of labelling. This is equivalent to the group<labeling_group> vendor parameter. no

                                  label-max-displacement length If set, this is the maximum displacement that the renderer will apply to a label. Labels that need larger displacements to avoid collisions will simply be omitted. This is equivalent to the maxDisplacement<labeling_max_displacement> vendor parameter. no

                                  "},{"location":"styling/css/properties/#css_properties_text2","title":"Text symbology (labelling) - part 2","text":"

                                  Property Type Meaning Accepts Expression?

                                  label-min-group-distance length This is equivalent to the minGroupDistance vendor parameter in SLD. no

                                  label-repeat length If set, the renderer will repeat labels at this interval along a line. This is equivalent to the repeat<labeling_repeat> vendor parameter. no

                                  label-all-group one of true or false when using grouping, whether to label only the longest line that could be built by merging the lines forming the group, or also the other ones. This is equivalent to the allGroup<labeling_all_group> vendor parameter. no

                                  label-remove-overlaps one of true or false If enabled, the renderer will remove overlapping lines within a group to avoid duplicate labels. This is equivalent to the removeOverlaps vendor parameter. no

                                  label-allow-overruns one of true or false Determines whether the renderer will show labels that are longer than the lines being labelled. This is equivalent to the allowOverrun vendor parameter. no

                                  label-follow-line one of true or false If enabled, the render will curve labels to follow the lines being labelled. This is equivalent to the followLine<labeling_follow_line> vendor parameter. no

                                  label-max-angle-delta one of true or false The maximum amount of curve allowed between two characters of a label; only applies when 'follow-line: true' is set. This is equivalent to the maxAngleDelta<labeling_max_angle_delta> vendor parameter. no

                                  label-auto-wrap length Labels will be wrapped to multiple lines if they exceed this length in pixels. This is equivalent to the autoWrap<labeling_autowrap> vendor parameter. no

                                  label-force-ltr one of true or false By default, the renderer will flip labels whose normal orientation would cause them to be upside-down. Set this parameter to false if you are using some icon character label like an arrow to show a line's direction. This is equivalent to the forceLeftToRight<labeling_force_left_to_right> vendor parameter. no

                                  label-conflict-resolution one of true or false Set this to false to disable label conflict resolution, allowing overlapping labels to be rendered. This is equivalent to the conflictResolution<labeling_conflict_resolution> vendor parameter. no

                                  label-fit-goodness scale The renderer will omit labels that fall below this \"match quality\" score. The scoring rules differ for each geometry type. This is equivalent to the goodnessOfFit<labeling_goodness_of_fit> vendor parameter. no

                                  label-priority expression Specifies an expression to use in determining which features to prefer if there are labelling conflicts. This is equivalent to the Priority<labeling_priority> SLD extension. yes

                                  "},{"location":"styling/css/properties/#css_properties_text3","title":"Text symbology (labelling) - part 3","text":"

                                  Property Type Meaning Accepts Expression?

                                  shield-resize string, one of none, stretch, or proportional Specifies a mode for resizing label graphics (such as highway shields) to fit the text of the label. The default mode, 'none', never modifies the label graphic. In stretch mode, GeoServer will resize the graphic to exactly surround the label text, possibly modifying the image's aspect ratio. In proportional mode, GeoServer will expand the image to be large enough to surround the text while preserving its original aspect ratio. none

                                  shield-margin list of lengths, one to four elements long. Specifies an extra margin (in pixels) to be applied to the label text when calculating label dimensions for use with the shield-resize option. Similar to the margin shorthand property in CSS for HTML, its interpretation varies depending on how many margin values are provided: 1 = use that margin length on all sides of the label 2 = use the first for top & bottom margins and the second for left & right margins. 3 = use the first for the top margin, second for left & right margins, third for the bottom margin. 4 = use the first for the top margin, second for the right margin, third for the bottom margin, and fourth for the left margin. none

                                  label-underline-text one of true or false If enabled, the renderer will underline labels. This is equivalent to the underlineText vendor parameter. no

                                  label-strikethrough-text one of true or false If enabled, the renderer will strikethrough labels. This is equivalent to the strikethroughText vendor parameter. no

                                  label-char-spacing an amount of pixels, can be negative If present, expands or shrinks the space between subsequent characters in a label according to the value specified no

                                  label-word-spacing an amount of pixels, must be zero or positive If present, expands the space between subsequent words in a label according to the value specified no

                                  "},{"location":"styling/css/properties/#css_properties_raster","title":"Raster symbology","text":"

                                  Property Type Meaning Accepts Expression?

                                  raster-channels string The list of raster channels to be used in the output. It can be \"auto\" to make the renderer choose the best course of action, or a list of band numbers, a single one will generate a gray image, three will generate an RGB one, four will generate a RGBA one. E.g., \"1 3 7\" to choose the first, third and seventh band of the input raster to make an RGB image no

                                  raster-composite string The composite mode to be used and the optional opacity separated with a comma. See the full list of available modes. no

                                  raster-geometry expression The attribute containing the raster to be painted. Normally not needed, but it would work if you had a custom vector data source that contains a GridCoverage attribute, in order to select it yes

                                  raster-opacity floating point A value comprised between 0 and 1, 0 meaning completely transparent, 1 meaning completely opaque. This controls the whole raster transparency. no

                                  raster-contrast-enhancement string Allows to stretch the range of data/colors in order to enhance tiny differences. Possible values are 'normalize', 'histogram' and 'none' no

                                  raster-gamma floating point Gamma adjustment for the output raster no

                                  raster-z-index integer Controls the z ordering of the raster output no

                                  raster-color-map string Applies a color map to single banded input. The contents are a space separate list of color-map-entry(color, value) (opacity assumed to be 1 and label will have a null value), or color-map-entry(color, value, opacity, label). The values must be provided in increasing order. no

                                  raster-color-map-type string Controls how the color map entries are interpreted, the possible values are \"ramp\", \"intervals\" and \"values\", with ramp being the default if no \"raster-color-map-type\" is provided. The default \"ramp\" behavior is to linearly interpolate color between the provided values, and assign the lowest color to all values below the lowest value, and the highest color to all values above the highest value. The \"intervals\" behavior instead assigns solid colors between values, whilst \"values\" only assigns colors to the specified values, every other value in the raster is not painted at all no

                                  raster-color-map-extended string Enables \"extended color map\" mode, which makes the color map use 65536 entries instead of 256, and thus allows for a more precise color mapping. The default is \"false\", which means the color map is limited to 256 entries (if more than 256 colors are used, the extended color map mode is enabled automatically). This property is ignored if the \"raster-color-map\" property is not provided. no

                                  raster-label-fi string Controls if and how color map entry labels are included, as attributes, in the GetFeatureInfo output. Valid values are add, adding the labels as extra attributes, replace, using the labels in place of the actual value, or none (the default) which does not include the labels in the output. no

                                  raster-label-name string If color map entry labels are included in the GetFeatureInfo output, this property controls then name of the attribute that will contain them. no

                                  "},{"location":"styling/css/properties/#css_properties_shared","title":"Shared","text":"

                                  Property Type Meaning Accepts Expression?

                                  composite string The composite mode to be used and the optional opacity separated with a comma. See the full list of available modes. no

                                  composite-base one of true or false This will tell the rendering engine to use that FeatureTypeStyle as the destination, and will compose all subsequent FeatureTypeStyle/Layers on top of it, until another base is found. no

                                  geometry expression An expression to use for the geometry when rendering features. This provides a geometry for all types of symbology, but can be overridden by the symbol-specific geometry properties. yes

                                  sort-by string A comma separated list of sorting directives, att1 A|D, att2 A|D, ... where att? are attribute names, and A or D are an optional direction specification, A is ascending, D is descending. Determines the loading, and thus painting, order of the features no

                                  sort-by-group string Rules with the different z-index but same sort-by-group id have their features sorted as a single group. Useful to z-order across layers or across different feature groups, like roads and rails, especially when using z-index to support casing no

                                  transform function Applies a rendering transformation on the current level. The function syntax is txName(key1:value1,key1:value2). Values can be single ones, or space separated lists. no

                                  "},{"location":"styling/css/properties/#css_properties_symbol","title":"Symbol properties","text":"

                                  These properties are applied only when styling built-in symbols. See Styled marks for details.

                                  Property Type Meaning Accepts Expression?

                                  size length The size at which to render the symbol. yes

                                  rotation angle An angle through which to rotate the symbol. yes

                                  "},{"location":"styling/css/styledmarks/","title":"Styled marks","text":"

                                  GeoServer's CSS module provides a collection of predefined symbols that you can use and combine to create simple marks, strokes, and fill patterns without needing an image editing program. You can access these symbols via the symbol() CSS function. For example, the built-in circle symbol makes it easy to create a simple 'dot' marker for a point layer:

                                  * {\n  mark: symbol(circle);\n}\n

                                  Symbols work anywhere you can use a url() to reference an image (as in, you can use symbols for stroke and fill patterns as well as markers.)

                                  "},{"location":"styling/css/styledmarks/#symbol-names","title":"Symbol names","text":"

                                  GeoServer extensions can add extra symbols (such as the chart:// symbol family which allows the use of charts as symbols via a naming scheme similar to the Google Charts API). However, there are a few symbols that are always available:

                                  • circle
                                  • square
                                  • triangle
                                  • arrow
                                  • cross
                                  • star
                                  • x
                                  • shape://horizline
                                  • shape://vertline
                                  • shape://backslash
                                  • shape://slash
                                  • shape://plus
                                  • shape://times
                                  • windbarbs://default(size)[unit]
                                  "},{"location":"styling/css/styledmarks/#symbol-selectors","title":"Symbol selectors","text":"

                                  Symbols offer some additional styling options beyond those offered for image references. To specify these style properties, just add another rule with a special selector. There are 8 \"pseudoclass\" selectors that are used to style selectors:

                                  • :mark specifies that a rule applies to symbols used as point markers
                                  • :shield specifies that a rule applies to symbols used as label shields (icons displayed behind label text)
                                  • :stroke specifies that a rule applies to symbols used as stroke patterns
                                  • :fill specifies that a rule applies to symbols used as fill patterns
                                  • :symbol specifies that a rule applies to any symbol, regardless of which context it is used in
                                  • :nth-mark(n) specifies that a rule applies to the symbol used for the nth stacked point marker on a feature.
                                  • :nth-shield(n) specifies that a rule applies to the symbol used for the background of the nth stacked label on a feature
                                  • :nth-stroke(n) specifies that a rule applies to the symbol used for the nth stacked stroke pattern on a feature.
                                  • :nth-fill(n) specifies that a rule applies to the symbol used for the nth stacked fill pattern on a feature.
                                  • :nth-symbol(n) specifies that a rule applies to the symbol used for the nth stacked symbol on a feature, regardless of which context it is used in.

                                  These pseudoclass selectors can be used in a top level rule, but starting with GeoServer 2.10, they are more commonly used in sub-rules close to the mark property, to get better readability (see example below).

                                  "},{"location":"styling/css/styledmarks/#symbol-styling-properties","title":"Symbol styling properties","text":"

                                  Styling a built-in symbol is similar to styling a polygon feature. However, the styling options are slightly different from those available to a true polygon feature:

                                  • The mark and label families of properties are unavailable for symbols.
                                  • Nested symbol styling is not currently supported.
                                  • Only the first stroke and fill will be used.
                                  • Additional size (as a length) and rotation (as an angle) properties are available. These are analogous to the (mark|stroke|fill)-size and (mark|stroke|fill)-rotation properties available for true geometry styling.

                                  Note

                                  The various prefixed '-size' and '-rotation' properties on the containing style override those for the symbol if they are present.

                                  "},{"location":"styling/css/styledmarks/#example-styled-symbol","title":"Example styled symbol","text":"

                                  As an example, consider a situation where you are styling a layer that includes data about hospitals in your town. You can create a simple hospital logo by placing a red cross symbol on top of a white circle background:

                                  [usage='hospital'] {\n  mark: symbol('circle'), symbol('cross');\n  :nth-mark(1) {\n    size: 16px;\n    fill: white;\n    stroke: red;\n  };\n  :nth-mark(2) {\n    size: 12px;\n    fill: red;\n  }\n}\n

                                  Also an windbarb example where you get wind speed and direction from your data fields horSpeed and horDir (direction):

                                  * {\n  /* select windbard based on speed( here in meters per second, and south hemisphere) */\n  mark: symbol('windbarbs://default(${horSpeed})[m/s]?hemisphere=s');\n\n  /* rotate windbarb based on horDir property (in degrees) */\n  mark-rotation: [horDir];\n\n  mark-size: 20;\n}\n
                                  "},{"location":"styling/css/transformation/","title":"Rendering transformations in CSS","text":"

                                  Starting with GeoServer 2.10 the CSS modules supports rendering transformations via the transform property.

                                  The property is a function call with a special key/value pair syntax, using the following template:

                                  transformationName(key1:value1,key2:v21 v22 ... v2M,...,keyN:vN)\n

                                  The values can be simple ones, or can be a space separated list. The parameter representing the input layer can be omitted, the engine will automatically recognize input parameters of type feature collection or grid coverage.

                                  The transformation function is subject to cascading like all other properties, but cascading acts at the whole z-level, so if multiple transformations are needed, they need to be associated with two different z-levels.

                                  This is an example of a CSS style extracting contour lines from a DEM, and also showing the single values when a suitable zoom level is reached:

                                  /* @title Levels */\n* {\n  transform: ras:Contour(levels: 1100 1200 1300 1400 1500 1600 1700);\n  z-index: 0;\n  stroke: gray;\n  label: [numberFormat('#', value)];\n  font-size: 12;\n  font-fill: black;\n  font-weight: bold;\n  halo-color: white;\n  halo-radius: 2;\n  label-follow-line: true;\n  label-repeat: 200;\n  label-max-angle-delta: 45;\n  label-priority: 2000;\n}\n\n/* @title Values */\n[@sd < 12000] {\n  transform: ras:RasterAsPointCollection(scale: 0.5);\n  z-index: 1;\n  label: [GRAY_INDEX];\n  label-anchor: 0.5 0.5;\n  font-family: Arial;\n  font-fill: black;\n  font-size: 6;\n  label-priority: 1000;\n}\n

                                  The two transformations in action against a DEM layer

                                  "},{"location":"styling/css/tutorial/","title":"Tutorial: Styling data with CSS","text":"

                                  This tutorial will show using CSS to style a layer, along with the equivalent SLD code.

                                  To use this tutorial, you will need the CSS extension as well as the states layer from the default GeoServer configuration.

                                  "},{"location":"styling/css/tutorial/#creating-a-style-for-the-states-layer","title":"Creating a style for the states layer","text":"

                                  The SLD file for the default states layer looks like this:

                                  <?xml version=\"1.0\" encoding=\"ISO-8859-1\"?>\n<StyledLayerDescriptor\n  version=\"1.0.0\"\n  xmlns=\"http://www.opengis.net/sld\" \n  xmlns:ogc=\"http://www.opengis.net/ogc\"\n  xmlns:xlink=\"http://www.w3.org/1999/xlink\"\n  xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\"\n  xmlns:gml=\"http://www.opengis.net/gml\"\n  xsi:schemaLocation=\"http://www.opengis.net/sld\n    http://schemas.opengis.net/sld/1.0.0/StyledLayerDescriptor.xsd\n\">\n  <NamedLayer>\n    <Name>USA states population</Name>\n    <UserStyle>\n      <Name>population</Name>\n      <Title>Population in the United States</Title>\n      <Abstract>A sample filter that filters the United States into three\n        categories of population, drawn in different colors</Abstract>\n      <FeatureTypeStyle>\n        <Rule>\n          <Title>&lt; 2M</Title>\n          <ogc:Filter>\n            <ogc:PropertyIsLessThan>\n             <ogc:PropertyName>PERSONS</ogc:PropertyName>\n             <ogc:Literal>2000000</ogc:Literal>\n            </ogc:PropertyIsLessThan>\n          </ogc:Filter>\n          <PolygonSymbolizer>\n             <Fill>\n                <!-- CssParameters allowed are fill (the color) and fill-opacity -->\n                <CssParameter name=\"fill\">#4DFF4D</CssParameter>\n                <CssParameter name=\"fill-opacity\">0.7</CssParameter>\n             </Fill>     \n          </PolygonSymbolizer>\n        </Rule>\n        <Rule>\n          <Title>2M - 4M</Title>\n          <ogc:Filter>\n            <ogc:PropertyIsBetween>\n              <ogc:PropertyName>PERSONS</ogc:PropertyName>\n              <ogc:LowerBoundary>\n                <ogc:Literal>2000000</ogc:Literal>\n              </ogc:LowerBoundary>\n              <ogc:UpperBoundary>\n                <ogc:Literal>4000000</ogc:Literal>\n              </ogc:UpperBoundary>\n            </ogc:PropertyIsBetween>\n          </ogc:Filter>\n          <PolygonSymbolizer>\n             <Fill>\n                <!-- CssParameters allowed are fill (the color) and fill-opacity -->\n                <CssParameter name=\"fill\">#FF4D4D</CssParameter>\n                <CssParameter name=\"fill-opacity\">0.7</CssParameter>\n             </Fill>     \n          </PolygonSymbolizer>\n        </Rule>\n        <Rule>\n          <Title>&gt; 4M</Title>\n          <!-- like a linesymbolizer but with a fill too -->\n          <ogc:Filter>\n            <ogc:PropertyIsGreaterThan>\n             <ogc:PropertyName>PERSONS</ogc:PropertyName>\n             <ogc:Literal>4000000</ogc:Literal>\n            </ogc:PropertyIsGreaterThan>\n          </ogc:Filter>\n          <PolygonSymbolizer>\n             <Fill>\n                <!-- CssParameters allowed are fill (the color) and fill-opacity -->\n                <CssParameter name=\"fill\">#4D4DFF</CssParameter>\n                <CssParameter name=\"fill-opacity\">0.7</CssParameter>\n             </Fill>     \n          </PolygonSymbolizer>\n        </Rule>\n        <Rule>\n          <Title>Boundary</Title>\n          <LineSymbolizer>\n            <Stroke>\n              <CssParameter name=\"stroke-width\">0.2</CssParameter>\n            </Stroke>\n          </LineSymbolizer>\n          <TextSymbolizer>\n            <Label>\n              <ogc:PropertyName>STATE_ABBR</ogc:PropertyName>\n            </Label>\n            <Font>\n              <CssParameter name=\"font-family\">Times New Roman</CssParameter>\n              <CssParameter name=\"font-style\">Normal</CssParameter>\n              <CssParameter name=\"font-size\">14</CssParameter>\n            </Font>\n            <LabelPlacement>\n              <PointPlacement>\n                <AnchorPoint>\n                  <AnchorPointX>0.5</AnchorPointX>\n                  <AnchorPointY>0.5</AnchorPointY>\n                </AnchorPoint>\n              </PointPlacement>\n            </LabelPlacement>\n          </TextSymbolizer>\n        </Rule>\n     </FeatureTypeStyle>\n    </UserStyle>\n    </NamedLayer>\n</StyledLayerDescriptor>\n

                                  Now, let's start on a CSS file that accomplishes the same thing.

                                  First, got to the styles page and click on Add a new style link to start a new style. In the \"New style\" page, do the following:

                                  • Name the new style anything you'd like, such as csstutorial
                                  • Choose CSS as the format
                                  • In the Generate a default style dropdown choose Polygon and click on Generate...

                                  Creating a new CSS style

                                  This creates an example style with a source similar to this one (the colors may differ):

                                  /* @title cyan polygon */\n* {\n    stroke: #000000;\n    stroke-width: 0.5;\n    fill: #0099cc;\n}\n

                                  This demonstrates the basic elements of a CSS style:

                                  A selector that identifies some part of the data to style. Here, the selector is *, indicating that all data should use the style properties.

                                  Properties inside curly braces ({}) which specify how the affected features should be styled. Properties consist of name/value pairs separated by colons (:).

                                  We can also see the basics for styling a polygon (fill), and its outline (stroke).

                                  See Also

                                  The Filter syntax and Property listing pages provide more information about the options available in CSS styles.

                                  Before moving on, let's save the style and preview it with the states layer:

                                  • Click on \"Apply\" to save the layer and enable the style preview
                                  • Now on the \"Style Editor page\", switch to the \"layer preview\" tab and click on the \"previewing on layer\" link, then choose the \"states\" layer in the dialog
                                  • The style editor should now show the states layer filled and stroked

                                  Previewing the CSS style with the state layer

                                  Let's use these basics to start translating the states style. The first rule in the SLD applies to states where the PERSONS field is less than two million:

                                  <Rule>\n  <Title>&lt; 2M</Title>\n  <ogc:Filter>\n    <ogc:PropertyIsLessThan>\n     <ogc:PropertyName>PERSONS</ogc:PropertyName>\n     <ogc:Literal>2000000</ogc:Literal>\n    </ogc:PropertyIsLessThan>\n  </ogc:Filter>\n  <PolygonSymbolizer>\n     <Fill>\n        <!-- CssParameters allowed are fill (the color) and fill-opacity -->\n        <CssParameter name=\"fill\">#4DFF4D</CssParameter>\n        <CssParameter name=\"fill-opacity\">0.7</CssParameter>\n     </Fill>     \n  </PolygonSymbolizer>\n</Rule>\n

                                  Using a CQL</tutorials/cql/cql_tutorial>-based selector, and copying the names and values of the CssParameters over, we get:

                                  [PERSONS < 2000000] {\n  fill: #4DFF4D;\n  fill-opacity: 0.7;\n}\n

                                  For the second style, we have a PropertyIsBetween filter, which doesn't directly translate to CSS:

                                  <Rule>\n  <Title>2M - 4M</Title>\n  <ogc:Filter>\n    <ogc:PropertyIsBetween>\n      <ogc:PropertyName>PERSONS</ogc:PropertyName>\n      <ogc:LowerBoundary>\n        <ogc:Literal>2000000</ogc:Literal>\n      </ogc:LowerBoundary>\n      <ogc:UpperBoundary>\n        <ogc:Literal>4000000</ogc:Literal>\n      </ogc:UpperBoundary>\n    </ogc:PropertyIsBetween>\n  </ogc:Filter>\n  <PolygonSymbolizer>\n     <Fill>\n        <!-- CssParameters allowed are fill (the color) and fill-opacity -->\n        <CssParameter name=\"fill\">#FF4D4D</CssParameter>\n        <CssParameter name=\"fill-opacity\">0.7</CssParameter>\n     </Fill>     \n  </PolygonSymbolizer>\n</Rule>\n

                                  However, PropertyIsBetween can easily be replaced by a combination of two comparison selectors. In CSS, you can apply multiple selectors to a rule by simply placing them one after the other. Selectors separated by only blank-space must all be satisfied for a style to apply. Multiple such groups can be attached to a rule by separating them with commas (,). If a feature matches any of the comma-separated groups for a rule then that style is applied. Thus, the CSS equivalent of the second rule is:

                                  [PERSONS >= 2000000] [PERSONS < 4000000] {\n  fill: #FF4D4D;\n  fill-opacity: 0.7;\n}\n

                                  The third rule can be handled in much the same manner as the first:

                                  [PERSONS >= 4000000] {\n  fill: #4D4DFF;\n  fill-opacity: 0.7;\n}\n

                                  The fourth and final rule is a bit different. It applies a label and outline to all the states:

                                  <Rule>\n  <Title>Boundary</Title>\n  <LineSymbolizer>\n    <Stroke>\n      <CssParameter name=\"stroke-width\">0.2</CssParameter>\n    </Stroke>\n  </LineSymbolizer>\n  <TextSymbolizer>\n    <Label>\n      <ogc:PropertyName>STATE_ABBR</ogc:PropertyName>\n    </Label>\n    <Font>\n      <CssParameter name=\"font-family\">Times New Roman</CssParameter>\n      <CssParameter name=\"font-style\">Normal</CssParameter>\n      <CssParameter name=\"font-size\">14</CssParameter>\n    </Font>\n    <LabelPlacement>\n      <PointPlacement>\n        <AnchorPoint>\n          <AnchorPointX>0.5</AnchorPointX>\n          <AnchorPointY>0.5</AnchorPointY>\n        </AnchorPoint>\n      </PointPlacement>\n    </LabelPlacement>\n  </TextSymbolizer>\n</Rule>\n

                                  This introduces the idea of rendering an extracted value (STATE_ABBR) directly into the map, unlike all of the rules thus far. For this, you can use a CQL expression wrapped in square braces ([]) as the value of a CSS property. It is also necessary to surround values containing blank-space, such as Times New Roman, with single- or double-quotes (\", '). With these details in mind, let's write the rule:

                                  * {\n  stroke-width: 0.2;\n  label: [STATE_ABBR];\n  label-anchor: 0.5 0.5;\n  font-family: \"Times New Roman\";\n  font-fill: black;\n  font-style: normal;\n  font-size: 14;\n}\n

                                  Putting it all together, you should now have a style that looks like:

                                  [PERSONS < 2000000] {\n  fill: #4DFF4D;\n  fill-opacity: 0.7;\n}\n\n[PERSONS >= 2000000] [PERSONS < 4000000] {\n  fill: #FF4D4D;\n  fill-opacity: 0.7;\n}\n\n[PERSONS >= 4000000] {\n  fill: #4D4DFF;\n  fill-opacity: 0.7;\n}\n\n* {\n  stroke-width: 0.2;\n  label: [STATE_ABBR];\n  label-anchor: 0.5 0.5;\n  font-family: \"Times New Roman\";\n  font-fill: black;\n  font-style: normal;\n  font-size: 14;\n}\n

                                  Click the Apply button at the bottom of the form to save your changes.

                                  CSS style applied to the states layer

                                  You will see that the borders are missing! In the GeoServer CSS module, each type of symbolizer has a \"key\" property which controls whether it is applied. Without these \"key\" properties, subordinate properties are ignored. These \"key\" properties are:

                                  • fill, which controls whether or not Polygon fills are applied. This specified the color or graphic to use for the fill.
                                  • stroke, which controls whether or not Line and Polygon outline strokes are applied. This specifies the color (or graphic fill) of the stroke.
                                  • mark, which controls whether or not point markers are drawn. This identifies a Well-Known Mark or image URL to use.
                                  • label, which controls whether or not to draw labels on the map. This identifies the text to use for labelling the map, usually as a CQL expression.
                                  • halo-radius, which controls whether or not to draw a halo around labels. This specifies how large such halos should be.

                                  See Also

                                  The Property listing page for information about the other properties.

                                  Since we don't specify a stroke color, no stroke is applied. Let's add it, replacing the final rule so that it will now look like this:

                                  * {\n  stroke: black;\n  stroke-width: 0.2;\n  label: [STATE_ABBR];\n  label-anchor: 0.5 0.5;\n  font-family: \"Times New Roman\";\n  font-fill: black;\n  font-style: normal;\n  font-size: 14;\n}\n

                                  Border added to style

                                  "},{"location":"styling/css/tutorial/#refining-the-style","title":"Refining the style","text":""},{"location":"styling/css/tutorial/#removing-duplicated-properties","title":"Removing duplicated properties","text":"

                                  The style that we have right now is only 23 lines, a nice improvement over the 103 lines of XML that we started with. However, we are still repeating the fill-opacity attribute everywhere.

                                  We can move it into the * rule and have it applied everywhere. This works because the GeoServer CSS module emulates cascading: While SLD uses a \"painter's model\" where each rule is processed independently, a cascading style allows you to provide general style properties and override only specific properties for particular features.

                                  This brings the style down to only 21 lines:

                                  [PERSONS < 2000000] {\n  fill: #4DFF4D;\n}\n\n[PERSONS > 2000000] [PERSONS < 4000000] {\n  fill: #FF4D4D;\n}\n\n[PERSONS > 4000000] {\n  fill: #4D4DFF;\n}\n\n* {\n  fill-opacity: 0.7;\n  stroke-width: 0.2;\n  label: [STATE_ABBR];\n  label-anchor: 0.5 0.5;\n  font-family: \"Times New Roman\";\n  font-fill: black;\n  font-style: normal;\n  font-size: 14;\n}\n
                                  "},{"location":"styling/css/tutorial/#scale-dependent-styles","title":"Scale-dependent styles","text":"

                                  The labels for this style are nice, but at lower zoom levels they seem a little crowded. We can easily move the labels to a rule that doesn't activate until the scale denominator is below 2000000. We do want to keep the stroke and fill-opacity at all zoom levels, so we can separate them from the label properties.

                                  Keep the following properties in the main (*) rule:

                                  * {\n  fill-opacity: 0.7;\n  stroke-width: 0.2;\n}\n

                                  Remove all the rest, moving them into a new rule:

                                  [@sd < 20M] {\n  label: [STATE_ABBR];\n  label-anchor: 0.5 0.5;\n  font-family: \"Times New Roman\";\n  font-fill: black;\n  font-style: normal;\n  font-size: 14;\n}\n
                                  "},{"location":"styling/css/tutorial/#setting-titles-for-the-legend","title":"Setting titles for the legend","text":"

                                  So far, we haven't set titles for any of the style rules. This doesn't really cause any problems while viewing maps, but GeoServer uses the title in auto-generating legend graphics. Without the titles, GeoServer falls back on the names, which in the CSS module are generated from the filters for each rule. Titles are not normally a part of CSS, so GeoServer looks for them in specially formatted comments before each rule. We can add titles like this:

                                  /* @title Population < 2M */\n[PERSONS < 2000000] {\n\n  ...\n\n/* @title 2M < Population < 4M */\n[PERSONS > 2000000] [PERSONS < 4000000] {\n\n  ...\n\n/* @title Population > 4M */\n[PERSONS > 4000000] {\n\n  ...\n\n\n/* @title Boundaries */\n* {\n\n  ...\n

                                  Because of the way that CSS is translated to SLD, each SLD rule is a combination of several CSS rules. This is handled by combining the titles with the word \"with\". If the title is omitted for a rule, then it is simply not included in the SLD output.

                                  The final CSS should look like this:

                                  /* @title Population < 2M */\n[PERSONS < 2000000] {\n  fill: #4DFF4D;\n  fill-opacity: 0.7;\n}\n\n/* @title 2M < Population < 4M */\n[PERSONS >= 2000000] [PERSONS < 4000000] {\n  fill: #FF4D4D;\n  fill-opacity: 0.7;\n}\n\n/* @title Population > 4M */\n[PERSONS >= 4000000] {\n  fill: #4D4DFF;\n  fill-opacity: 0.7;\n}\n\n\n/* @title Boundaries */\n* {\n  stroke: black;\n  stroke-width: 0.2;\n  fill-opacity: 0.7;\n}\n\n[@sd < 20M] {\n  label: [STATE_ABBR];\n  label-anchor: 0.5 0.5;\n  font-family: \"Times New Roman\";\n  font-fill: black;\n  font-style: normal;\n  font-size: 14;\n}\n

                                  Final style with rule names

                                  "},{"location":"styling/css/tutorial/#applying-rule-nesting","title":"Applying rule nesting","text":"

                                  As a final variation, the style can be made more compact by leveraging rule nesting:

                                  * {\n  stroke: black;\n  stroke-width: 0.2;\n  fill-opacity: 0.7;\n\n  /* @title Population < 2M */\n  [PERSONS < 2000000] {\n    fill: #4DFF4D;\n  };\n  /* @title 2M < Population < 4M */\n  [PERSONS >= 2000000] [PERSONS < 4000000] {\n    fill: #FF4D4D;\n  };\n  /* @title Population > 4M */\n  [PERSONS >= 4000000] {\n    fill: #4D4DFF;\n  };\n\n  /* Labelling */\n  [@sd < 20M] {\n    label: [STATE_ABBR];\n    label-anchor: 0.5 0.5;\n    font-family: \"Times New Roman\";\n    font-fill: black;\n    font-style: normal;\n    font-size: 14;\n  }   \n}\n
                                  "},{"location":"styling/css/tutorial/#css-workshop","title":"CSS Workshop","text":"

                                  For more details, visit the next section, the CSS workshop. This workshop has been used in the past for classroom settings to teach the CSS extension and has been ported to the user documentation.

                                  "},{"location":"styling/css/valuetypes/","title":"CSS value types","text":"

                                  This page presents a brief overview of CSS types as used by this project. Note that these can be repeated as described in Multi-valued properties.

                                  "},{"location":"styling/css/valuetypes/#numbers","title":"Numbers","text":"

                                  Numeric values consist of a number, or a number annotated with a measurement value. In general, it is wise to use measurement annotations most of the time, to avoid ambiguity and protect against potential future changes to the default units.

                                  Currently, the supported units include:

                                  • Length
                                    • px pixels
                                    • m meters
                                    • ft feet
                                  • Angle
                                    • deg degrees
                                  • Ratio
                                    • % percentage

                                  When using expressions in place of numeric values, the first unit listed for the type of measure is assumed.

                                  Since the CSS module translates styles to SLD before any rendering occurs, its model of unit-of-measure is tied to that of SLD. In practice, this means that for any particular symbolizer, there only one unit-of-measure applied for the style. Therefore, the CSS module extracts that unit-of-measure from one special property for each symbolizer type. Those types are listed below for reference:

                                  • fill-size determines the unit-of-measure for polygon symbolizers (but that doesn't matter so much since it is the only measure associated with fills)
                                  • stroke-width determines the unit-of-measure for line symbolizers
                                  • mark-size determines the unit-of-measure for point symbolizers
                                  • font-size determines the unit-of-measure for text symbolizers and the associated halos
                                  "},{"location":"styling/css/valuetypes/#strings","title":"Strings","text":"

                                  String values consist of a small snippet of text. For example, a string could be a literal label to use for a subset of roads:

                                  [lanes>20] {\n    label: \"Serious Freaking Highway\";\n}\n

                                  Strings can be enclosed in either single or double quotes. It's easiest to simply use whichever type of quotes are not in your string value, but you can escape quote characters by prefixing them with a backslash `. Backslash characters themselves must also be prefixed. For example,'\\''` is a string value consisting of a single backslash followed by a single quote character.

                                  "},{"location":"styling/css/valuetypes/#labels","title":"Labels","text":"

                                  While labels aren't really a special type of value, they deserve a special mention since labels are more likely to require special string manipulation than other CSS values.

                                  If a label is a simple string value, then it works like any other string would:

                                  [lanes > 20] {\n    label: \"Serious Freaking Highway\";\n}\n

                                  However, if a label has multiple values, all of those values will be concatenated to form a single label:

                                  [lanes > 20] {\n   label: \"Serious \" \"Freaking \" \"Highway\";\n}\n

                                  Note the blank-space within the label strings here; no blank-space is added when concatenating strings, so you must be explicit about where you want it included. You can also mix CQL expressions in with literal string values here:

                                  states {\n   label: [STATE_NAME] \" (\" [STATE_ABBR] \")\";\n}\n

                                  Note

                                  This automatic concatenation is currently a special feature only provided for labels. However, string concatenation is also supported directly in CQL expressions by using the strConcat filter function:

                                  * { fill: [strConcat('#', color_hex)]; }\n

                                  This form of concatenation works with any property that supports expressions.

                                  "},{"location":"styling/css/valuetypes/#colors","title":"Colors","text":"

                                  Color values are relatively important to styling, so there are multiple ways to specify them.

                                  Format Interpretation

                                  #RRGGBB A hexadecimal-encoded color value, with two digits each for red, green, and blue.

                                  #RGB A hexadecimal-encoded color value, with one digits each for red, green, and blue. This is equivalent to the two-digit-per-channel encoding with each digit duplicated.

                                  rgb(r, g, b) A three-part color value with each channel represented by a value in the range 0 to 1, or in the range 0 to 255. 0 to 1 is used if any of the values include a decimal point, otherwise it is 0 to 255.

                                  Simple name The simple English name of the color. A full list of the supported colors is available at http://www.w3.org/TR/SVG/types.html#ColorKeywords

                                  "},{"location":"styling/css/valuetypes/#external-references","title":"External references","text":"

                                  When using external images to decorate map features, it is necessary to reference them by URL. This is done by a call to the url function. The URL value may be wrapped in single or double-quotes, or not at all. The same escaping rules as for string values. The url function is also a special case where the surrounding quote marks can usually be omitted. Some examples:

                                  /* These properties are all equivalent. */\n\n* {\n    stroke: url(\"http://example.com/\");\n    stroke: url('http://example.com/');\n    stroke: url(http://example.com/);\n}\n

                                  Note

                                  While relative URLs are supported, they will be fully resolved during the conversion process to SLD and written out as absolute URLs. This may be cause problems when relocating data directories, etc. The style can be regenerated with the current correct URL by opening it in the demo editor and using the Submit button there.

                                  "},{"location":"styling/css/valuetypes/#well-known-marks","title":"Well-known marks","text":"

                                  As defined in the SLD standard, GeoServer's css module also allows using a certain set of well-known mark types without having to provide graphic resources explicitly. These include:

                                  • circle
                                  • square
                                  • cross
                                  • star
                                  • arrow

                                  And others. Additionally, vendors can provide an extended set of well-known marks, a facet of the standard that is exploited by some GeoTools plugins to provide dynamic map features such as using characters from TrueType fonts as map symbols, or dynamic charting. In support of these extended mark names, the css module provides a symbol function similar to url. The syntax is the same, aside from the function name:

                                  * {\n    mark: symbol(circle);\n    mark: symbol('ttf://Times+New+Roman&char=0x19b2');\n    mark: symbol(\"chart://type=pie&x&y&z\");\n}\n
                                  "},{"location":"styling/css/cookbook/","title":"CSS Cookbook","text":"

                                  The CSS Cookbook is a collection of CSS \"recipes\" for creating various types of map styles. Wherever possible, each example is designed to show off a single CSS feature so that code can be copied from the examples and adapted when creating CSS styles of your own. Most examples are shared with the SLD Cookbook, to make a comparison between the two syntaxes immediate.

                                  The CSS Cookbook is divided into four sections: the first three for each of the vector types (points, lines, and polygons) and the fourth section for rasters. Each example in every section contains a screen-shot showing actual GeoServer WMS output and the full CSS code for reference.

                                  Each section uses data created especially for the Cookbooks (both CSS and SLD), with shapefiles for vector data and GeoTIFFs for raster data. The projection for data is EPSG:4326. All files can be easily loaded into GeoServer in order to recreate the examples.

                                  Data type Shapefile

                                  Point sld_cookbook_point.zip

                                  Line sld_cookbook_line.zip

                                  Polygon sld_cookbook_polygon.zip

                                  Raster sld_cookbook_raster.zip

                                  • Points
                                  • Lines
                                  • Polygons
                                  • Rasters
                                  "},{"location":"styling/css/cookbook/line/","title":"Lines","text":"

                                  While lines can also seem to be simple shapes, having length but no width, there are many options and tricks for making lines display nicely.

                                  "},{"location":"styling/css/cookbook/line/#css_cookbook_lines_attributes","title":"Example lines layer","text":"

                                  The lines layer used in the examples below contains road information for a fictional country. For reference, the attribute table for the points in this layer is included below.

                                  fid (Feature ID) name (Road name) type (Road class)

                                  line.1 Latway highway

                                  line.2 Crescent Avenue secondary

                                  line.3 Forest Avenue secondary

                                  line.4 Longway highway

                                  line.5 Saxer Avenue secondary

                                  line.6 Ridge Avenue secondary

                                  line.7 Holly Lane local-road

                                  line.8 Mulberry Street local-road

                                  line.9 Nathan Lane local-road

                                  line.10 Central Street local-road

                                  line.11 Lois Lane local-road

                                  line.12 Rocky Road local-road

                                  line.13 Fleet Street local-road

                                  line.14 Diane Court local-road

                                  line.15 Cedar Trail local-road

                                  line.16 Victory Road local-road

                                  line.17 Highland Road local-road

                                  line.18 Easy Street local-road

                                  line.19 Hill Street local-road

                                  line.20 Country Road local-road

                                  line.21 Main Street local-road

                                  line.22 Jani Lane local-road

                                  line.23 Shinbone Alley local-road

                                  line.24 State Street local-road

                                  line.25 River Road local-road

                                  Download the lines shapefile

                                  "},{"location":"styling/css/cookbook/line/#css_cookbook_lines_simpleline","title":"Simple line","text":"

                                  This example specifies lines be colored black with a thickness of 3 pixels.

                                  Simple line

                                  "},{"location":"styling/css/cookbook/line/#code","title":"Code","text":"
                                  * { \n  stroke: black;\n  stroke-width: 3px;\n}\n
                                  "},{"location":"styling/css/cookbook/line/#details","title":"Details","text":"

                                  The only rule asks for a black stroke (this attribute is mandatory to get strokes to actually show up), 3 pixels wide.

                                  "},{"location":"styling/css/cookbook/line/#line-with-border","title":"Line with border","text":"

                                  This example shows how to draw lines with borders (sometimes called \"cased lines\"). In this case the lines are drawn with a 3 pixel blue center and a 1 pixel wide gray border.

                                  Line with border

                                  "},{"location":"styling/css/cookbook/line/#code_1","title":"Code","text":"
                                  * { \n  stroke: #333333, #6699FF;\n  stroke-width: 5px, 3px;\n  stroke-linecap: round;\n  z-index: 0, 1;\n}\n
                                  "},{"location":"styling/css/cookbook/line/#details_1","title":"Details","text":"

                                  Lines in CSS have no notion of a \"fill\", only \"stroke\". Thus, unlike points or polygons, it is not possible to style the \"edge\" of the line geometry. It is, however, possible to achieve this effect by drawing each line twice: once with a certain width and again with a slightly smaller width. This gives the illusion of fill and stroke by obscuring the larger lines everywhere except along the edges of the smaller lines.

                                  The style uses the \"multi-valued properties\" CSS support by specifying two strokes and two stroke-widths. This causes each feature to be painted twice, first with a dark gray (#333333) line 5 pixels wide, and then a thinner blue (#6699FF) line 3 pixels wide.

                                  Since every line is drawn twice, the order of the rendering is very important. Without the z-index indication, each feature would first draw the gray stroke and then the blue one, and then the rendering engine would move to the next feature, and so on. This would result in ugly overlaps when lines do cross. By using the z-index property (Line 3) instead, all gray lines will be painted first, and then all blue lines will painted on top, thus making sure the blue lines visually connect.

                                  The \"stroke-linecap\" property is the only one having a single value, this is because the value is the same for both the gray and blue line.

                                  The result is a 3 pixel blue line with a 1 pixel gray border, since the 5 pixel gray line will display 1 pixel on each side of the 3 pixel blue line.

                                  "},{"location":"styling/css/cookbook/line/#dashed-line","title":"Dashed line","text":"

                                  This example alters the Simple line to create a dashed line consisting of 5 pixels of drawn line alternating with 2 pixels of blank space.

                                  Dashed line

                                  "},{"location":"styling/css/cookbook/line/#code_2","title":"Code","text":"
                                  * { \n  stroke: blue;\n  stroke-width: 3px;\n  stroke-dasharray: 5 2;\n}\n
                                  "},{"location":"styling/css/cookbook/line/#details_2","title":"Details","text":"

                                  In this example the we create a blue line, 3 pixels wide, and specify a dash array with value \"5 2\", which creates a repeating pattern of 5 pixels of drawn line, followed by 2 pixels of omitted line.

                                  "},{"location":"styling/css/cookbook/line/#railroad-hatching","title":"Railroad (hatching)","text":"

                                  This example uses hatching to create a railroad style. Both the line and the hatches are black, with a 2 pixel thickness for the main line and a 1 pixel width for the perpendicular hatches.

                                  Railroad (hatching)

                                  "},{"location":"styling/css/cookbook/line/#code_3","title":"Code","text":"
                                  * { \n  stroke: #333333, symbol(\"shape://vertline\");\n  stroke-width: 3px;\n  :nth-stroke(2) {\n    size: 12;\n    stroke: #333333;\n    stroke-width: 1px;\n  }\n}\n
                                  "},{"location":"styling/css/cookbook/line/#details_3","title":"Details","text":"

                                  In this example a multi-valued stroke is used: the fist value makes the renderer paint a dark gray line (3 pixels wide, according to the \"stroke-width\" attribute), whilst the second value makes the line be painted by repeating the \"shape://vertline\" symbol over and over, creating the hatching effect.

                                  In order to specify how the symbol itself should be painted, the \":nth-stroke(2)\" pseudo-selector is used at Line 4 to specify the options for the repeated symbol: in particular with are instructing the renderer to create a 12px wide symbol, with a dark gray stroke 1 pixel wide.

                                  "},{"location":"styling/css/cookbook/line/#spaced-graphic-symbols","title":"Spaced graphic symbols","text":"

                                  This example uses a graphic stroke along with dash arrays to create a \"dot and space\" line type. Adding the dash array specification allows to control the amount of space between one symbol and the next one. Without using the dash array the lines would be densely populated with dots, each one touching the previous one.

                                  Spaced symbols along a line

                                  "},{"location":"styling/css/cookbook/line/#code_4","title":"Code","text":"
                                  * { \n  stroke: symbol(circle);\n  stroke-dasharray: 4 6;\n  :stroke {\n    size: 4;\n    fill: #666666;\n    stroke: #333333;\n    stroke-width: 1px;\n  }\n}\n
                                  "},{"location":"styling/css/cookbook/line/#details_4","title":"Details","text":"

                                  This example, like others before, uses symbol(circle) to place a graphic symbol along a line.

                                  The symbol details are specified in the nested rule at Line 4 using the \":stroke\" pseudo-selector, creating a gray fill circle, 4 pixels wide, with a dark gray outline.

                                  The spacing between symbols is controlled with the stroke-dasharray at line 3, which specifies 4 pixels of pen-down (just enough to draw the circle) and 6 pixels of pen-up, to provide the spacing.

                                  "},{"location":"styling/css/cookbook/line/#css_cookbook_lines_dashoffset","title":"Alternating symbols with dash offsets","text":"

                                  This example shows how to create a complex line style which alternates a dashed line and a graphic symbol. The code builds on features shown in the previous examples:

                                  • stroke-dasharray controls pen-down/pen-up behavior to generate dashed lines
                                  • symbol(...) places symbols along a line combining the two allows control of symbol spacing

                                  This also shows the usage of a dash offset, which controls where rendering starts in the dash array. For example, with a dash array of 5 10 and a dash offset of 7 the renderer starts drawing the pattern 7 pixels from the beginning. It skips the 5 pixels pen-down section and 2 pixels of the pen-up section, then draws the remaining 8 pixels of pen-up, then 5 down, 10 up, and so on.

                                  The example shows how to use these features to create two synchronized sequences of dash arrays, one drawing line segments and the other symbols.

                                  Alternating dash and symbol

                                  "},{"location":"styling/css/cookbook/line/#code_5","title":"Code","text":"
                                  * { \n  stroke: blue, symbol(circle);\n  stroke-width: 1px;\n  stroke-dasharray: 10 10, 5 15;\n  stroke-dashoffset: 0, 7.5;\n  :nth-stroke(2) {\n    stroke: #000033;\n    stroke-width: 1px;\n    size: 5px;\n  }\n}\n
                                  "},{"location":"styling/css/cookbook/line/#details_5","title":"Details","text":"

                                  | This example uses again multi-valued properties to create two subsequent strokes applied to the same lines. | The first stroke is a solid blue line, 1 pixel wide, with a dash array of \"10 10\". | The second one instead is a repeated circle, using a dash array of \"5 15\" and with a dash offset of 7.5. This makes the sequence start with 12.5 pixels of white space, then a circle (which is then centered between the two line segments of the other pattern), then 15 pixels of white space, and so on.

                                  The circle portrayal details are specified using the pseudo selector \"nth-stroke(2)\" at line 6, asking for circles that are 5 pixels wide, not filled, and with a dark blue outline.

                                  "},{"location":"styling/css/cookbook/line/#css_cookbook_lines_defaultlabel","title":"Line with default label","text":"

                                  This example shows a text label on the simple line. This is how a label will be displayed in the absence of any other customization.

                                  Line with default label

                                  "},{"location":"styling/css/cookbook/line/#code_6","title":"Code","text":"
                                  * { \n  stroke: red;\n  label: [name];\n  font-fill: black;\n}\n
                                  "},{"location":"styling/css/cookbook/line/#details_6","title":"Details","text":"

                                  This example paints lines with a red stroke, and then adds horizontal black labels at the center of the line, using the \"name\" attribute to fill the label.

                                  "},{"location":"styling/css/cookbook/line/#css_cookbook_lines_perpendicularlabel","title":"Labels along line with perpendicular offset","text":"

                                  This example shows a text label on the simple line, just like the previous example, but will force the label to be parallel to the lines, and will offset them a few pixels away.

                                  Line with default label

                                  "},{"location":"styling/css/cookbook/line/#code_7","title":"Code","text":"
                                  * { \n  stroke: red;\n  label: [name];\n  label-offset: 7px;\n  font-fill: black;\n}\n
                                  "},{"location":"styling/css/cookbook/line/#details_7","title":"Details","text":"

                                  This example is line by line identical to the previous one, but it add a new attribute \"label-offset\", which in the case of lines, when having a single value, is interpreted as a perpendicular offset from the line. The label is painted along a straight line, parallel to the line orientation in the center point of the label.

                                  "},{"location":"styling/css/cookbook/line/#css_cookbook_lines_labelfollowingline","title":"Label following line","text":"

                                  This example renders the text label to follow the contour of the lines.

                                  Label following line

                                  "},{"location":"styling/css/cookbook/line/#code_8","title":"Code","text":"
                                  * { \n  stroke: red;\n  label: [name];\n  font-fill: black;\n  label-follow-line: true;\n}\n
                                  "},{"location":"styling/css/cookbook/line/#details_8","title":"Details","text":"

                                  As the Line with default label example showed, the default label behavior isn't optimal.

                                  This example is similar to the Line with default label example with the exception of line 5 where the \"label-follow-line\" option is specified, which forces the labels to strickly follow the line.

                                  Not all labels are visible partly because of conflict resolution, and partly because the renderer cannot find a line segment long and \"straight\" enough to paint the label (labels are not painted over sharp turns by default).

                                  "},{"location":"styling/css/cookbook/line/#css_cookbook_lines_optimizedlabel","title":"Optimized label placement","text":"

                                  This example optimizes label placement for lines such that the maximum number of labels are displayed.

                                  Optimized label

                                  "},{"location":"styling/css/cookbook/line/#code_9","title":"Code","text":"
                                  * { \n  stroke: red;\n  label: [name];\n  font-fill: black;\n  label-follow-line: true;\n  label-max-angle-delta: 90;\n  label-max-displacement: 400;\n  label-repeat: 150;\n}\n
                                  "},{"location":"styling/css/cookbook/line/#details_9","title":"Details","text":"

                                  This example is similar to the previous example, Label following line. The only differences are contained in lines 6-8. Line 6 sets the maximum angle that the label will follow. This sets the label to never bend more than 90 degrees to prevent the label from becoming illegible due to a pronounced curve or angle. Line 7 sets the maximum displacement of the label to be 400 pixels. In order to resolve conflicts with overlapping labels, GeoServer will attempt to move the labels such that they are no longer overlapping. This value sets how far the label can be moved relative to its original placement. Finally, line 8 sets the labels to be repeated every 150 pixels. A feature will typically receive only one label, but this can cause confusion for long lines. Setting the label to repeat ensures that the line is always labeled locally.

                                  "},{"location":"styling/css/cookbook/line/#css_cookbook_lines_optimizedstyledlabel","title":"Optimized and styled label","text":"

                                  This example improves the style of the labels from the Optimized label placement example.

                                  Optimized and styled label

                                  "},{"location":"styling/css/cookbook/line/#code_10","title":"Code","text":"
                                  * { \n  stroke: red;\n  label: [name];\n  font-family: Arial;\n  font-weight: bold;\n  font-fill: black;\n  font-size: 10;\n  halo-color: white;\n  halo-radius: 1;\n  label-follow-line: true;\n  label-max-angle-delta: 90;\n  label-max-displacement: 400;\n  label-repeat: 150;\n}\n
                                  "},{"location":"styling/css/cookbook/line/#details_10","title":"Details","text":"

                                  This example is similar to the Optimized label placement. The only differences are:

                                  • The font family and weight have been specified
                                  • In order to make the labels easier to read, a white \"halo\" has been added. The halo draws a thin 1 pixel white border around the text, making it stand out from the background.
                                  "},{"location":"styling/css/cookbook/line/#attribute-based-line","title":"Attribute-based line","text":"

                                  This example styles the lines differently based on the \"type\" (Road class) attribute.

                                  Attribute-based line

                                  "},{"location":"styling/css/cookbook/line/#code_11","title":"Code","text":"
                                  [type = 'local-road'] {\n  stroke: #009933;\n  stroke-width: 2;\n  z-index: 0;\n}\n\n[type = 'secondary'] {\n  stroke: #0055CC;\n  stroke-width: 3;\n  z-index: 1;\n}\n\n[type = 'highway'] {\n  stroke: #FF0000;\n  stroke-width: 6;\n  z-index: 2;\n}\n
                                  "},{"location":"styling/css/cookbook/line/#details_11","title":"Details","text":"

                                  Note

                                  Refer to the Example lines layer to see the attributes for the layer. This example has eschewed labels in order to simplify the style, but you can refer to the example Optimized and styled label to see which attributes correspond to which points.

                                  There are three types of road classes in our fictional country, ranging from back roads to high-speed freeways: \"highway\", \"secondary\", and \"local-road\". In order to make sure the roads are rendered in the proper order of importance, a \"z-index\" attribute has been placed in each rule.

                                  The three rules are designed as follows:

                                  Rule order Rule name / type Color Size

                                  1 local-road #009933 (green) 2

                                  2 secondary #0055CC (blue) 3

                                  3 highway #FF0000 (red) 6

                                  Lines 1-5 comprise the first rule, the filter matches all roads that the \"type\" attribute has a value of \"local-road\". If this condition is true for a particular line, the rule renders it dark green, 2 pixels wide. All these lines are rendered first, and thus sit at the bottom of the final map.

                                  Lines 7-11 match the \"secondary\" roads, painting them dark blue, 3 pixels wide. Given the \"z-index\" is 1, they are rendered after the local roads, but below the highways.

                                  Lines 13-17 match the \"highway\" roads, painting them red 6 pixels wide. These roads are pained last, thus, on top of all others.

                                  "},{"location":"styling/css/cookbook/line/#zoom-based-line","title":"Zoom-based line","text":"

                                  This example alters the Simple line style at different zoom levels.

                                  Zoom-based line: Zoomed in

                                  Zoom-based line: Partially zoomed

                                  Zoom-based line: Zoomed out

                                  "},{"location":"styling/css/cookbook/line/#code_12","title":"Code","text":"
                                  * {\n  stroke: #009933;\n}\n\n[@sd < 180M] {\n  stroke-width: 6;\n}\n\n[@sd > 180M] [@sd < 360M] {\n  stroke-width: 4;\n}\n\n[@sd > 360M] {\n  stroke-width: 2;\n}\n
                                  "},{"location":"styling/css/cookbook/line/#details_12","title":"Details","text":"

                                  It is often desirable to make shapes larger at higher zoom levels when creating a natural-looking map. This example varies the thickness of the lines according to the zoom level (or more accurately, scale denominator). Scale denominators refer to the scale of the map. A scale denominator of 10,000 means the map has a scale of 1:10,000 in the units of the map projection.

                                  Note

                                  Determining the appropriate scale denominators (zoom levels) to use is beyond the scope of this example.

                                  This style contains three rules. The three rules are designed as follows:

                                  Rule order Rule name Scale denominator Line width

                                  1 Large 1:180,000,000 or less 6

                                  2 Medium 1:180,000,000 to 1:360,000,000 4

                                  3 Small Greater than 1:360,000,000 2

                                  The order of these rules does not matter since the scales denominated in each rule do not overlap.

                                  The first rule provides the stroke color used at all zoom levels, dark gray, while the other three rules cascade over it applying the different stroke widths based on the current zoom level leveraging the \"@sd\" pseudo attribute. The \"@sd\" pseudo attribute can only be compared using the \"<\" and \">\" operators, using any other operator will result in errors.

                                  The result of this style is that lines are drawn with larger widths as one zooms in and smaller widths as one zooms out.

                                  "},{"location":"styling/css/cookbook/point/","title":"Points","text":"

                                  While points are seemingly the simplest type of shape, possessing only position and no other dimensions, there are many different ways that a point can be styled in CSS.

                                  "},{"location":"styling/css/cookbook/point/#css_cookbook_points_attributes","title":"Example points layer","text":"

                                  The points layer used for the examples below contains name and population information for the major cities of a fictional country. For reference, the attribute table for the points in this layer is included below.

                                  fid (Feature ID) name (City name) pop (Population)

                                  point.1 Borfin 157860

                                  point.2 Supox City 578231

                                  point.3 Ruckis 98159

                                  point.4 Thisland 34879

                                  point.5 Synopolis 24567

                                  point.6 San Glissando 76024

                                  point.7 Detrania 205609

                                  Download the points shapefile

                                  "},{"location":"styling/css/cookbook/point/#css_cookbook_points_simplepoint","title":"Simple point","text":"

                                  This example specifies points be styled as red circles with a diameter of 6 pixels.

                                  Simple point

                                  "},{"location":"styling/css/cookbook/point/#code","title":"Code","text":"
                                  * { \n  mark: symbol(circle); \n  mark-size: 6px;\n  :mark {\n    fill: red;\n  }\n}\n
                                  "},{"location":"styling/css/cookbook/point/#details","title":"Details","text":"

                                  There are two rules in this CSS, the outer one matches all features, and asks them to be depicted with a circular mark, 6 pixels wide. The nested rule uses a symbol selector, :mark, which selects all marks, and allows to specify how to fill the contents of the circle, in this case, with a solid red fill (a stand alone fill property would have been interpreted as the request to fill all polygons in the input with solid red instead).

                                  "},{"location":"styling/css/cookbook/point/#css_cookbook_points_simplepointwithstroke","title":"Simple point with stroke","text":"

                                  This example adds a stroke (or border) around the Simple point, with the stroke colored black and given a thickness of 2 pixels.

                                  Simple point with stroke

                                  "},{"location":"styling/css/cookbook/point/#code_1","title":"Code","text":"
                                  * { \n  mark: symbol(circle); \n  mark-size: 6px;\n  :mark {\n    fill: red;\n    stroke: black;\n    stroke-width: 2px;\n  }\n}\n
                                  "},{"location":"styling/css/cookbook/point/#details_1","title":"Details","text":"

                                  This example is similar to the Simple point example, in this case a stroke and a stroke width have been specified in the mark selector in order to apply them to the circle symbols.

                                  "},{"location":"styling/css/cookbook/point/#rotated-square","title":"Rotated square","text":"

                                  This example creates a square instead of a circle, colors it green, sizes it to 12 pixels, and rotates it by 45 degrees.

                                  Rotated square

                                  "},{"location":"styling/css/cookbook/point/#code_2","title":"Code","text":"
                                  * { \n  mark: symbol(square); \n  mark-size: 12px;\n  mark-rotation: 45;\n  :mark {\n    fill: #009900;\n  }\n}\n
                                  "},{"location":"styling/css/cookbook/point/#details_2","title":"Details","text":"

                                  In this example, line 2 sets the shape to be a square, with line 6 setting the color to a dark green (#009900). Line 3 sets the size of the square to be 12 pixels, and line 4 set the rotation is to 45 degrees.

                                  "},{"location":"styling/css/cookbook/point/#transparent-triangle","title":"Transparent triangle","text":"

                                  This example draws a triangle, creates a black stroke identical to the Simple point with stroke example, and sets the fill of the triangle to 20% opacity (mostly transparent).

                                  Transparent triangle

                                  "},{"location":"styling/css/cookbook/point/#code_3","title":"Code","text":"
                                  * { \n  mark: symbol(triangle); \n  mark-size: 12;\n  :mark {\n    fill: #009900;\n    fill-opacity: 0.2;\n    stroke: black;\n    stroke-width : 2px;\n  }\n}\n
                                  "},{"location":"styling/css/cookbook/point/#details_3","title":"Details","text":"

                                  In this example, line 2 once again sets the shape, in this case to a triangle, where line 3 sets the mark size to 12 pixels. Line 5 sets the fill color to a dark green (#009900) and line 6 sets the opacity to 0.2 (20% opaque). An opacity value of 1 means that the shape is drawn 100% opaque, while an opacity value of 0 means that the shape is drawn 0% opaque, or completely transparent. The value of 0.2 (20% opaque) means that the fill of the points partially takes on the color and style of whatever is drawn beneath it. In this example, since the background is white, the dark green looks lighter. Were the points imposed on a dark background, the resulting color would be darker. Line 8 set the stroke color to black and width to 2 pixels.

                                  "},{"location":"styling/css/cookbook/point/#point-as-graphic","title":"Point as graphic","text":"

                                  This example styles each point as a graphic instead of as a simple shape.

                                  Point as graphic

                                  "},{"location":"styling/css/cookbook/point/#code_4","title":"Code","text":"
                                  * { \n  mark: url(smileyface.png); \n  mark-mime: \"image/png\";\n}\n
                                  "},{"location":"styling/css/cookbook/point/#details_4","title":"Details","text":"

                                  This style uses a graphic instead of a simple shape to render the points. Line 2 sets the path and file name of the graphic, while line 3 indicates the format (MIME type) of the graphic (image/png). In this example, the graphic is contained in the same directory as the SLD, so no path information is necessary, although a full URL could be used if desired.

                                  Graphic used for points

                                  "},{"location":"styling/css/cookbook/point/#css_cookbook_points_pointwithdefaultlabel","title":"Point with default label","text":"

                                  This example shows a text label on the Simple point that displays the \"name\" attribute of the point. This is how a label will be displayed in the absence of any other customization.

                                  Point with default label

                                  "},{"location":"styling/css/cookbook/point/#code_5","title":"Code","text":"
                                  * { \n  mark: symbol(circle);\n  mark-size: 6px;\n  label: [name];\n  font-fill: black;\n  :mark {\n    fill: red;\n  }\n}\n
                                  "},{"location":"styling/css/cookbook/point/#details_5","title":"Details","text":"

                                  This style is quite similar to the Simple point, but two new properties have been added to specify the labelling options. Line 4 indicates that the label contents come from the \"name\" attribute (anything in square brackets is a CQL expression, the attribute name being the simplest case) while Line 5 sets the label color to black.

                                  "},{"location":"styling/css/cookbook/point/#css_cookbook_points_pointwithstyledlabel","title":"Point with styled label","text":"

                                  This example improves the label style from the Point with default label example by centering the label above the point and providing a different font name and size.

                                  Point with styled label

                                  "},{"location":"styling/css/cookbook/point/#code_6","title":"Code","text":"
                                  * { \n  mark: symbol(circle);\n  mark-size: 6px;\n  label: [name];\n  font-fill: black;\n  font-family: Arial;\n  font-size: 12;\n  font-weight: bold;\n  label-anchor: 0.5 0;\n  label-offset: 0 5;\n  :mark {\n    fill: red;\n  }\n\n}\n
                                  "},{"location":"styling/css/cookbook/point/#details_6","title":"Details","text":"

                                  This example expands on Point with default label and specifies the font attributes, in particular, the text is Aria, bold, 12px wide. Moreover, the label is moved on top of the point, by specifying an anchor of 0.5 0, which sets the point to be centered (0.5) horizontally axis and bottom aligned (0.0) vertically with the label, and an offset which moves the label 5 pixels up vertically.

                                  The result is a centered bold label placed slightly above each point.

                                  "},{"location":"styling/css/cookbook/point/#point-with-rotated-label","title":"Point with rotated label","text":"

                                  This example builds on the previous example, Point with styled label, by rotating the label by 45 degrees, positioning the labels farther away from the points, and changing the color of the label to purple.

                                  Point with rotated label

                                  "},{"location":"styling/css/cookbook/point/#code_7","title":"Code","text":"
                                  * { \n  mark: symbol(circle);\n  mark-size: 6px;\n  label: [name];\n  font-fill: #990099;\n  font-family: Arial;\n  font-size: 12;\n  font-weight: bold;\n  label-anchor: 0.5 0;\n  label-offset: 0 25;\n  label-rotation: -45;\n  :mark {\n    fill: red;\n  }\n}\n
                                  "},{"location":"styling/css/cookbook/point/#details_7","title":"Details","text":"

                                  This example is similar to the Point with styled label, but there are three important differences. Line 10 specifies 25 pixels of vertical displacement. Line 11 specifies a rotation of \"-45\" or 45 degrees counter-clockwise. (Rotation values increase clockwise, which is why the value is negative.) Finally, line 5 sets the font color to be a shade of purple (#99099).

                                  Note that the displacement takes effect before the rotation during rendering, so in this example, the 25 pixel vertical displacement is itself rotated 45 degrees.

                                  "},{"location":"styling/css/cookbook/point/#attribute-based-point","title":"Attribute-based point","text":"

                                  This example alters the size of the symbol based on the value of the population (\"pop\") attribute.

                                  Attribute-based point

                                  "},{"location":"styling/css/cookbook/point/#code_8","title":"Code","text":"
                                  * {\n  mark: symbol(circle);\n  :mark {\n    fill: #0033CC;\n  };\n  [pop < 50000] {\n    mark-size: 8;\n  };\n  [pop >= 50000] [pop < 100000] {\n    mark-size: 12;\n  };\n  [pop >= 100000] {\n    mark-size: 16;\n  }\n}\n
                                  "},{"location":"styling/css/cookbook/point/#details_8","title":"Details","text":"

                                  Note

                                  Refer to the Example points layer to see the attributes for this data. This example has eschewed labels in order to simplify the style, but you can refer to the example Point with styled label to see which attributes correspond to which points.

                                  This style shows how the basic mark setup (red circle, default size) can be overridden via cascading/nesting, changing the size depending on the pop attribute value, with smaller values yielding a smaller circle, and larger values yielding a larger circle.

                                  The three rules are designed as follows:

                                  Rule order Rule name Population (\"pop\") Size

                                  1 SmallPop Less than 50,000 8

                                  2 MediumPop 50,000 to 100,000 12

                                  3 LargePop Greater than 100,000 16

                                  The result of this style is that cities with larger populations have larger points. In particular, the rule at Line 6 matches all features whose \"pop\" attribute is less than 50000, the rule at Line 9 matches all features whose \"pop\" attribute is between 50000 and 100000 (mind the space between the two predicates, it is equivalent to and AND, if we had used a comma it would have been an OR instead), while the rule at Line 12 matches all features with more than 100000 inhabitants.

                                  "},{"location":"styling/css/cookbook/point/#zoom-based-point","title":"Zoom-based point","text":"

                                  This example alters the style of the points at different zoom levels.

                                  Zoom-based point: Zoomed in

                                  Zoom-based point: Partially zoomed

                                  Zoom-based point: Zoomed out

                                  "},{"location":"styling/css/cookbook/point/#code_9","title":"Code","text":"
                                  * {\n  mark: symbol(circle);\n}\n\n:mark {\n  fill: #CC3300;\n}\n\n[@sd < 16M] {\n  mark-size: 12;\n}\n\n[@sd > 16M] [@sd < 32M] {\n  mark-size: 8;\n}\n\n[@sd > 32M] {\n  mark-size: 4;\n}\n
                                  "},{"location":"styling/css/cookbook/point/#details_9","title":"Details","text":"

                                  It is often desirable to make shapes larger at higher zoom levels when creating a natural-looking map. This example styles the points to vary in size based on the zoom level (or more accurately, scale denominator). Scale denominators refer to the scale of the map. A scale denominator of 10,000 means the map has a scale of 1:10,000 in the units of the map projection.

                                  Note

                                  Determining the appropriate scale denominators (zoom levels) to use is beyond the scope of this example.

                                  This style contains three rules matching the scale. The three rules are designed as follows:

                                  Rule order Rule name Scale denominator Point size

                                  1 Large 1:16,000,000 or less 12

                                  2 Medium 1:16,000,000 to 1:32,000,000 8

                                  3 Small Greater than 1:32,000,000 4

                                  The order of these rules does not matter since the scales denominated in each rule do not overlap.

                                  The rules use the \"@sd\" pseudo-attribute, which refers to the current scale denominator, and which can be compared using the '<' and '>' operators only (using any other operator or function will result in errors).

                                  The result of this style is that points are drawn larger as one zooms in and smaller as one zooms out.

                                  While this example uses on purpose cascading to show a different possible setup, the same style could be written as:

                                  * {\n  mark: symbol(circle);\n  :mark {\n    fill: #CC3300;\n  };\n  [@sd < 16M] {\n    mark-size: 12;\n  };\n  [@sd > 16M] [@sd < 32M] {\n    mark-size: 8;\n  };\n  [@sd > 32M] {\n    mark-size: 4;\n  }\n}\n
                                  "},{"location":"styling/css/cookbook/polygon/","title":"Polygons","text":"

                                  Polygons are two dimensional shapes that contain both an outer edge (or \"stroke\") and an inside (or \"fill\"). A polygon can be thought of as an irregularly-shaped point and is styled in similar ways to points.

                                  "},{"location":"styling/css/cookbook/polygon/#css_cookbook_polygons_attributes","title":"Example polygons layer","text":"

                                  The polygons layer used below contains county information for a fictional country. For reference, the attribute table for the polygons is included below.

                                  fid (Feature ID) name (County name) pop (Population)

                                  polygon.1 Irony County 412234

                                  polygon.2 Tracker County 235421

                                  polygon.3 Dracula County 135022

                                  polygon.4 Poly County 1567879

                                  polygon.5 Bearing County 201989

                                  polygon.6 Monte Cristo County 152734

                                  polygon.7 Massive County 67123

                                  polygon.8 Rhombus County 198029

                                  Download the polygons shapefile

                                  "},{"location":"styling/css/cookbook/polygon/#css_cookbook_polygons_simplepolygon","title":"Simple polygon","text":"

                                  This example shows a polygon filled in blue.

                                  Simple polygon

                                  "},{"location":"styling/css/cookbook/polygon/#code","title":"Code","text":"
                                  * { \n  fill: #000080; \n}\n
                                  "},{"location":"styling/css/cookbook/polygon/#details","title":"Details","text":"

                                  This simple rule applies a dark blue (#000080) fill to all the polygons in the dataset.

                                  Note

                                  The light-colored borders around the polygons in the figure are artifacts of the renderer caused by the polygons being adjacent. There is no border in this style.

                                  "},{"location":"styling/css/cookbook/polygon/#css_cookbook_polygons_simplepolygonwithstroke","title":"Simple polygon with stroke","text":"

                                  This example adds a 2 pixel white stroke to the Simple polygon example.

                                  Simple polygon with stroke

                                  "},{"location":"styling/css/cookbook/polygon/#code_1","title":"Code","text":"
                                  * { \n  fill: #000080; \n  stroke: #FFFFFF;\n  stroke-width: 2;\n}\n
                                  "},{"location":"styling/css/cookbook/polygon/#details_1","title":"Details","text":"

                                  This example is similar to the Simple polygon example above, with the addition of the \"stroke\" and \"stroke-width\" attributes, that add a white, 2 pixels wide border around each polygon.

                                  "},{"location":"styling/css/cookbook/polygon/#transparent-polygon","title":"Transparent polygon","text":"

                                  This example builds on the Simple polygon with stroke example and makes the fill partially transparent by setting the opacity to 50%.

                                  Transparent polygon

                                  "},{"location":"styling/css/cookbook/polygon/#code_2","title":"Code","text":"
                                  * { \n  fill: #000080; \n  fill-opacity: 0.5;\n  stroke: #FFFFFF;\n  stroke-width: 2;\n}\n
                                  "},{"location":"styling/css/cookbook/polygon/#details_2","title":"Details","text":"

                                  This example is similar to the Simple polygon with stroke example, save for defining the fill's opacity in line 3. The value of 0.5 results in partially transparent fill that is 50% opaque. An opacity value of 1 would draw the fill as 100% opaque, while an opacity value of 0 would result in a completely transparent (0% opaque) fill. In this example, since the background is white, the dark blue looks lighter. Were the points imposed on a dark background, the resulting color would be darker.

                                  "},{"location":"styling/css/cookbook/polygon/#css_cookbook_polygons_graphicfill","title":"Graphic fill","text":"

                                  This example fills the polygons with a tiled graphic.

                                  Graphic fill

                                  "},{"location":"styling/css/cookbook/polygon/#code_3","title":"Code","text":"
                                  * { \n  fill: url(\"colorblocks1.png\");\n  fill-mime: 'image/png';\n}\n
                                  "},{"location":"styling/css/cookbook/polygon/#details_3","title":"Details","text":"

                                  This style fills the polygon with a tiled graphic. The graphic is selected providing a url for the fill, which in this case is meant to the relative to the styles directory contained within the data directory (an absolute path could have been provided, as well as a internet reference). Line 3 specifies that the image itself is a png (by default the code assumes jpegs are used and will fail to parse the file unless we specify its mime type). The size of the image is not specified, meaning the native size is going to be used. In case a rescale is desired, the \"fill-size\" attribute can be used to force a different size.

                                  Graphic used for fill

                                  "},{"location":"styling/css/cookbook/polygon/#hatching-fill","title":"Hatching fill","text":"

                                  This example fills the polygons with a hatching pattern.

                                  Hatching fill

                                  "},{"location":"styling/css/cookbook/polygon/#code_4","title":"Code","text":"
                                  * { \n  fill: symbol(\"shape://times\");\n  :fill {\n    size: 16;\n    stroke: #990099;\n    stroke-width: 1px;\n  }\n}\n
                                  "},{"location":"styling/css/cookbook/polygon/#details_4","title":"Details","text":"

                                  In this example the fill is specified to be the \"shape://times\" symbol, which is going to be tiled creating a cross-hatch effect.

                                  The details of the hatch are specified at line 3*, where the pseudo-selector \":fill\" is used to match the contents of the fill, and specify that we want a symbol large 16 pixels (the larger the symbol, the coarser the cross hatch will be), and painted with a 1 pixel wide purple stroke.

                                  "},{"location":"styling/css/cookbook/polygon/#css_cookbook_polygons_polygonwithdefaultlabel","title":"Polygon with default label","text":"

                                  This example shows a text label on the polygon. In the absence of any other customization, this is how a label will be displayed.

                                  Polygon with default label

                                  "},{"location":"styling/css/cookbook/polygon/#code_5","title":"Code","text":"
                                  * { \n  fill: #40FF40;\n  stroke: white;\n  stroke-width: 2;\n  label: [name];\n  font-fill: black;\n}\n
                                  "},{"location":"styling/css/cookbook/polygon/#details_5","title":"Details","text":"

                                  The single rule in the CSS applies to all feature: first it fills all polygons a light green with white outline, and then applies the \"name\" attribute as the label, using the default font (Times), with black color and default font size (10 px).

                                  "},{"location":"styling/css/cookbook/polygon/#label-halo","title":"Label halo","text":"

                                  This example alters the look of the Polygon with default label by adding a white halo to the label.

                                  Label halo

                                  "},{"location":"styling/css/cookbook/polygon/#code_6","title":"Code","text":"
                                  * { \n  fill: #40FF40;\n  stroke: white;\n  stroke-width: 2;\n  label: [name];\n  font-fill: black;\n  halo-color: white;\n  halo-radius: 3;\n}\n
                                  "},{"location":"styling/css/cookbook/polygon/#details_6","title":"Details","text":"

                                  This example builds on Polygon with default label, with the addition of a halo around the labels on lines 7-8. A halo creates a color buffer around the label to improve label legibility. Line 9 sets the radius of the halo, extending the halo 3 pixels around the edge of the label, and line 8 sets the color of the halo to white. Since halos are most useful when set to a sharp contrast relative to the text color, this example uses a white halo around black text to ensure optimum readability.

                                  "},{"location":"styling/css/cookbook/polygon/#css_cookbook_polygons_polygonwithstyledlabel","title":"Polygon with styled label","text":"

                                  This example improves the label style from the Polygon with default label example by centering the label on the polygon, specifying a different font name and size, and setting additional label placement optimizations.

                                  Polygon with styled label

                                  "},{"location":"styling/css/cookbook/polygon/#code_7","title":"Code","text":"
                                  * { \n  fill: #40FF40;\n  stroke: white;\n  stroke-width: 2;\n  label: [name];\n  font-family: Arial;\n  font-size: 11px;\n  font-style: normal;\n  font-weight: bold;\n  font-fill: black;\n  label-anchor: 0.5 0.5;\n  label-auto-wrap: 60;\n  label-max-displacement: 150;\n}\n
                                  "},{"location":"styling/css/cookbook/polygon/#details_7","title":"Details","text":"

                                  This example is similar to the Polygon with default label example, with additional styling options for the labels.

                                  The font is setup to be Arial, 11 pixels, \"normal\" (as opposed to \"italic\") and bold.

                                  The \"label-anchor\" affects where the label is placed relative to the centroid of the polygon, centering the label by positioning it 50% (or 0.5) of the way horizontally along the centroid of the polygon, as well as vertically in exactly the same way.

                                  Finally, there are two added touches for label placement optimization: The \"label-auto-wrap\" attribute ensures that long labels are split across multiple lines by setting line wrapping on the labels to 60 pixels, whilst the \"label-max-displacement\" allows the label to be displaced by up to 150 pixels. This ensures that labels are compacted and less likely to spill over polygon boundaries. Notice little Massive County in the corner, whose label is now displayed.

                                  "},{"location":"styling/css/cookbook/polygon/#attribute-based-polygon","title":"Attribute-based polygon","text":"

                                  This example styles the polygons differently based on the \"pop\" (Population) attribute.

                                  Attribute-based polygon

                                  "},{"location":"styling/css/cookbook/polygon/#code_8","title":"Code","text":"
                                  [parseLong(pop) < 200000] {\n  fill: #66FF66;\n}\n\n[parseLong(pop) >= 200000] [parseLong(pop) < 500000] {\n  fill: #33CC33;\n}\n\n[parseLong(pop) >= 500000] {\n  fill: #009900;\n}\n
                                  "},{"location":"styling/css/cookbook/polygon/#details_8","title":"Details","text":"

                                  Note

                                  Refer to the Example polygons layer to see the attributes for the layer. This example has eschewed labels in order to simplify the style, but you can refer to the example Polygon with styled label to see which attributes correspond to which polygons.

                                  Each polygon in our fictional country has a population that is represented by the population (\"pop\") attribute. This style contains three rules that alter the fill based on the value of \"pop\" attribute, with smaller values yielding a lighter color and larger values yielding a darker color.

                                  The three rules are designed as follows:

                                  Rule order Rule name Population (\"pop\") Color

                                  1 SmallPop Less than 200,000 #66FF66

                                  2 MediumPop 200,000 to 500,000 #33CC33

                                  3 LargePop Greater than 500,000 #009900

                                  The order of the rules does not matter in this case, since each shape is only rendered by a single rule.

                                  The first rule fills light green all polygons whose \"pop\" attribute is below 200,000, the second paints medium green all poygons whose \"pop\" attribute is between 200,000 and 500,000, while the third rule paints dark green the remaining polygons.

                                  What's interesting in the filters is the use of the \"parseLong\" filter function: this function is necessary because the \"pop\" attribute is a string, leaving it as is we would have a string comparison, whilst the function turns it into a number, ensuring proper numeric comparisons instead.

                                  "},{"location":"styling/css/cookbook/polygon/#zoom-based-polygon","title":"Zoom-based polygon","text":"

                                  This example alters the style of the polygon at different zoom levels.

                                  Zoom-based polygon: Zoomed in

                                  Zoom-based polygon: Partially zoomed

                                  Zoom-based polygon: Zoomed out

                                  "},{"location":"styling/css/cookbook/polygon/#code_9","title":"Code","text":"
                                  * {\n  fill: #0000CC;\n  stroke: black;\n}\n\n[@sd < 100M] {\n   stroke-width: 7;\n   label: [name];\n   label-anchor: 0.5 0.5;\n   font-fill: white;\n   font-family: Arial;\n   font-size: 14;\n   font-weight: bold;\n}\n\n[@sd > 100M] [@sd < 200M] {\n   stroke-width: 4;\n}\n\n[@sd > 200M] {\n   stroke-width: 1;\n}\n
                                  "},{"location":"styling/css/cookbook/polygon/#details_9","title":"Details","text":"

                                  It is often desirable to make shapes larger at higher zoom levels when creating a natural-looking map. This example varies the thickness of the lines according to the zoom level. Polygons already do this by nature of being two dimensional, but another way to adjust styling of polygons based on zoom level is to adjust the thickness of the stroke (to be larger as the map is zoomed in) or to limit labels to only certain zoom levels. This is ensures that the size and quantity of strokes and labels remains legible and doesn't overshadow the polygons themselves.

                                  Zoom levels (or more accurately, scale denominators) refer to the scale of the map. A scale denominator of 10,000 means the map has a scale of 1:10,000 in the units of the map projection.

                                  Note

                                  Determining the appropriate scale denominators (zoom levels) to use is beyond the scope of this example.

                                  This style contains three rules, defined as follows:

                                  Rule order Rule name Scale denominator Stroke width Label display?

                                  1 Large 1:100,000,000 or less 7 Yes

                                  2 Medium 1:100,000,000 to 1:200,000,000 4 No

                                  3 Small Greater than 1:200,000,000 2 No

                                  The first rule (lines 1-4) defines the attributes that are not scale dependent: dark blue fill, black outline.

                                  The second (lines 6-14) rule provides specific overrides for the higher zoom levels, asking for a large stroke (7 pixels) and a label, which is only visible at this zoom level. The label is white, bold, Arial 14 pixels, its contents are coming form the \"name\" attribute.

                                  The third rule (lines 16-18) specifies a stroke width of 4 pixels for medium zoom levels, whilst for low zoom levels the stroke width is set to 1 pixel by the last rule (lines 20-22).

                                  The resulting style produces a polygon stroke that gets larger as one zooms in and labels that only display when zoomed in to a sufficient level.

                                  "},{"location":"styling/css/cookbook/raster/","title":"Rasters","text":"

                                  Rasters are geographic data displayed in a grid. They are similar to image files such as PNG files, except that instead of each point containing visual information, each point contains geographic information in numerical form. Rasters can be thought of as a georeferenced table of numerical values.

                                  One example of a raster is a Digital Elevation Model (DEM) layer, which has elevation data encoded numerically at each georeferenced data point.

                                  "},{"location":"styling/css/cookbook/raster/#example-raster","title":"Example raster","text":"

                                  The raster layer that is used in the examples below contains elevation data for a fictional world. The data is stored in EPSG:4326 (longitude/latitude) and has a data range from 70 to 256. If rendered in grayscale, where minimum values are colored black and maximum values are colored white, the raster would look like this:

                                  Raster file as rendered in grayscale

                                  Download the raster file

                                  "},{"location":"styling/css/cookbook/raster/#css_cookbook_raster_twocolorgradient","title":"Two-color gradient","text":"

                                  This example shows a two-color style with green at lower elevations and brown at higher elevations.

                                  Two-color gradient

                                  "},{"location":"styling/css/cookbook/raster/#code","title":"Code","text":"
                                  * {\n  raster-channels: auto;\n  raster-color-map: \n                    color-map-entry(#008000, 70)\n                    color-map-entry(#663333, 256);\n}\n
                                  "},{"location":"styling/css/cookbook/raster/#details","title":"Details","text":"

                                  There is a single rule which applies a color map to the raster data.

                                  The \"raster-channels\" attribute activates raster symbolization, the \"auto\" value is indicates that we are going to use the default choice of bands to symbolize the output (either gray or RBG/RGBA depending on the input data). There is also the possibility of providing a band name or a list of band names in case we want to choose specific bands out of a multiband input, e.g., \"1\" or \"1 3 7\".

                                  The \"raster-color-map\" attribute builds a smooth gradient between two colors corresponding to two elevation values. Each \"color-map-entry\" represents one entry or anchor in the gradient:

                                  • The first argument is the color
                                  • The second argument is the value at which we anchor the color
                                  • An optional third argument could specify the opacity of the pixels, as a value between 0 (fully transparent) and 1 (fully opaque). The default, when not specified, is 1, fully opaque.

                                  Line 4 sets the lower value of 70, which is styled a opaque dark green (#008000), and line 5 sets the upper value of 256, which is styled a opaque dark brown (#663333). All data values in between these two quantities will be linearly interpolated: a value of 163 (the midpoint between 70 and 256) will be colored as the midpoint between the two colors (in this case approximately #335717, a muddy green).

                                  "},{"location":"styling/css/cookbook/raster/#transparent-gradient","title":"Transparent gradient","text":"

                                  This example creates the same two-color gradient as in the Two-color gradient as in the example above but makes the entire layer mostly transparent by setting a 30% opacity.

                                  Transparent gradient

                                  "},{"location":"styling/css/cookbook/raster/#code_1","title":"Code","text":"
                                  * {\n  raster-channels: auto;\n  raster-opacity: 0.3;\n  raster-color-map: color-map-entry(#008000, 70)\n                    color-map-entry(#663333, 256);\n}\n
                                  "},{"location":"styling/css/cookbook/raster/#details_1","title":"Details","text":"

                                  This example is similar to the Two-color gradient example save for the addition of line 3, which sets the opacity of the layer to 0.3 (or 30% opaque). An opacity value of 1 means that the shape is drawn 100% opaque, while an opacity value of 0 means that the shape is rendered as completely transparent. The value of 0.3 means that the raster partially takes on the color and style of whatever is drawn beneath it. Since the background is white in this example, the colors generated from the \"raster-color-map\" look lighter, but were the raster imposed on a dark background the resulting colors would be darker.

                                  "},{"location":"styling/css/cookbook/raster/#brightness-and-contrast","title":"Brightness and contrast","text":"

                                  This example normalizes the color output and then increases the brightness by a factor of 2.

                                  Brightness and contrast

                                  "},{"location":"styling/css/cookbook/raster/#code_2","title":"Code","text":"
                                  * {\n  raster-channels: auto;\n  raster-contrast-enhancement: normalize;\n  raster-gamma: 0.5;\n  raster-color-map: color-map-entry(#008000, 70)\n                    color-map-entry(#663333, 256);\n}\n
                                  "},{"location":"styling/css/cookbook/raster/#details_2","title":"Details","text":"

                                  This example is similar to the Two-color gradient, save for the addition of the contrast enhancement and gamma attributes on lines 3-4. Line 3 normalizes the output by increasing the contrast to its maximum extent. Line 4 then adjusts the brightness by a factor of 0.5. Since values less than 1 make the output brighter, a value of 0.5 makes the output twice as bright.

                                  "},{"location":"styling/css/cookbook/raster/#three-color-gradient","title":"Three-color gradient","text":"

                                  This example creates a three-color gradient in primary colors. In addition, we want to avoid displaying data outside of the chosen range, leading some data not to be rendered at all.

                                  Three-color gradient

                                  "},{"location":"styling/css/cookbook/raster/#code_3","title":"Code","text":"
                                  * {\n  raster-channels: auto;\n  raster-color-map: \n                    color-map-entry(black, 150, 0)\n                    color-map-entry(blue, 150)\n                    color-map-entry(yellow, 200)\n                    color-map-entry(red, 250)\n                    color-map-entry(black, 250, 0)\n}\n
                                  "},{"location":"styling/css/cookbook/raster/#details_3","title":"Details","text":"

                                  This example creates a three-color gradient, with two extra rules to make ranges of color disappear. The color map behavior is such that any value below the lowest entry gets the same color as that entry, and any value above the last entry gets the same color as the last entry, while everything in between is linearly interpolated (all values must be provided from lower to higher). Line 4 associates value 150 and below with a transparent color (0 opacity, that is, fully transparent), and so does line 8, which makes transparent every value above 250. The lines in the middle create a gradient going from blue, to yellow, to red.

                                  "},{"location":"styling/css/cookbook/raster/#alpha-channel","title":"Alpha channel","text":"

                                  This example creates an \"alpha channel\" effect such that higher values are increasingly transparent.

                                  Alpha channel

                                  "},{"location":"styling/css/cookbook/raster/#code_4","title":"Code","text":"
                                  * {\n  raster-channels: auto;\n  raster-color-map: color-map-entry(#008000, 70)\n                    color-map-entry(#663333, 256, 0);\n}\n
                                  "},{"location":"styling/css/cookbook/raster/#details_4","title":"Details","text":"

                                  An alpha channel is another way of referring to variable transparency. Much like how a gradient maps values to colors, each entry in a \"raster-color-map\" can have a value for opacity (with the default being 1.0 or completely opaque).

                                  In this example, there is a \"raster-color-map\" with two entries: line 3 specifies the lower bound of 70 be colored dark green (#008000), while line 4 specifies the upper bound of 256 also be colored dark green but with an opacity value of 0. This means that values of 256 will be rendered at 0% opacity (entirely transparent). Just like the gradient color, the opacity is also linearly interpolated such that a value of 163 (the midpoint between 70 and 256) is rendered at 50% opacity.

                                  "},{"location":"styling/css/cookbook/raster/#discrete-colors","title":"Discrete colors","text":"

                                  This example shows a gradient that is not linearly interpolated but instead has values mapped precisely to one of three specific colors.

                                  Discrete colors

                                  "},{"location":"styling/css/cookbook/raster/#code_5","title":"Code","text":"
                                  * {\n  raster-channels: auto;\n  raster-color-map-type: intervals;\n  raster-color-map: color-map-entry(#008000, 150)\n                    color-map-entry(#663333, 256);\n}\n
                                  "},{"location":"styling/css/cookbook/raster/#details_5","title":"Details","text":"

                                  Sometimes color bands in discrete steps are more appropriate than a color gradient. The \"raster-color-map-type: intervals\" attribute sets the display to output discrete colors instead of a gradient. The values in each entry correspond to the upper bound for the color band such that colors are mapped to values less than the value of one entry but greater than or equal to the next lower entry. For example, line 4 colors all values less than 150 to dark green (#008000) and line 5 colors all values less than 256 but greater than or equal to 150 to dark brown (#663333).

                                  "},{"location":"styling/css/cookbook/raster/#many-color-gradient","title":"Many color gradient","text":"

                                  This example shows a gradient interpolated across eight different colors.

                                  Many color gradient

                                  "},{"location":"styling/css/cookbook/raster/#code_6","title":"Code","text":"
                                  * {\n  raster-channels: auto;\n  raster-color-map: \n          color-map-entry(black, 95)\n          color-map-entry(blue, 110)\n          color-map-entry(green, 135)\n          color-map-entry(red, 160)\n          color-map-entry(purple, 185)\n          color-map-entry(yellow, 210)\n          color-map-entry(cyan, 235)\n          color-map-entry(white, 256)\n}\n
                                  "},{"location":"styling/css/cookbook/raster/#details_6","title":"Details","text":"

                                  This example is similar to the previous ones, and creates a color gradient between 8 colors as reported in the following table

                                  Entry number Value Color

                                  1 95 Black

                                  2 110 Blue

                                  3 135 Green

                                  4 160 Red

                                  5 185 Purple

                                  6 210 Yellow

                                  7 235 Cyan

                                  8 256 White

                                  "},{"location":"styling/css/examples/","title":"Styling examples","text":"

                                  The following pages contain CSS styling examples grouped by specific topics.

                                  • Fills with randomized symbols
                                  • Using transformation functions
                                  • Example of 2.5D extrusion
                                  • KML
                                  • Miscellaneous
                                  "},{"location":"styling/css/examples/extrude/","title":"Example of 2.5D extrusion","text":""},{"location":"styling/css/examples/extrude/#extruding-a-geometry","title":"Extruding a geometry","text":"

                                  In this example, a 2.5D style is applied to the US States Population default layer. To achieve the 2.5D look two styling components need to work together, named isometric for the extrusion effect, and offset to add a rooftop or top surface. In order to draw states with a larger population on top, a sort-by using the PERSONS field was added. Also note that the same z-order was given to maintain the draw order of each state.

                                  The flat mode directive was used to ensure that cascading is not applied. This enables the style to treat each CSS rule the same as an SLD rule which means rules can overlay on-top of each other with later rules being drawn first.

                                  The extrusion part of the CSS produces the darker grey areas. The isometric function (see /filter/function_reference) was used to give the extrusion effect based on the US state's population size.

                                  The last step was to add an offset to the geometry producing the lighter grey areas as a top surface. The extrusion above works on each state from the ground up based on the population size. It is therefore necessary to offset the geometry in the Y axis with the same height used for the geometry extrusion. This adds the geometry at the top of the extrusion giving the effect of a top surface.

                                  @mode \"Flat\";\n/* EXTRUDING THE POLYGON */\n* {\n  fill: #7B7B7B;\n  fill-geometry: [isometric(the_geom, PERSONS/8M)];\n  stroke: #636363;\n  stroke-geometry: [isometric(the_geom, PERSONS/8M)];\n  stroke-opacity:0.7;\n  sort-by: PERSONS;  \n  z-index:0;\n}\n/* ADDING TOP SURFACE */\n* {\n  fill-geometry: [offset(the_geom, 0, PERSONS/8M)];\n  stroke-geometry: [offset(the_geom, 0, PERSONS/8M)];\n  fill: #CACCCD;\n  stroke: #000000;\n  stroke-opacity: 0.7;\n  sort-by: PERSONS;\n  z-index:0;\n  label: [STATE_ABBR];\n  font-family: 'Dialog';\n  font-weight: 'Bold';\n  halo-color: white;\n  halo-radius: 1;\n}\n

                                  "},{"location":"styling/css/examples/extrude/#footnote","title":"Footnote","text":"

                                  Using the population size to sort the rendering order causes some states (e.g. New York) to almost entirely overlay another state (in this case, Pennsylvania.) A better implementation might be to add a field containing the x value of the centroid and use this field in the sort-by clause in descending order i.e. (sort-by: centroid_x D).

                                  "},{"location":"styling/css/examples/kml/","title":"KML","text":""},{"location":"styling/css/examples/kml/#detecting-raster-to-vector-switch-in-kml","title":"Detecting raster to vector switch in KML","text":"

                                  GeoServer 2.4 added a new icon server that KML output uses to make sure the point symbolisers look the same as in a normal WMS call no matter what scale they are looked at.

                                  This may pose some issue when working in the default KML generation mode, where the map is a ground overlay up to a certain scale, and switches to a vector, clickable representation once the number of features in the visualization fall below a certain scale (as controlled by the KMSCORE parameter): the end user is not informed \"visually\" that the switch happened.

                                  There is however a custom environment variable, set by the KML generator, that styles can leverage to know whether the KML generation is happening in ground overlay or vector mode.

                                  The following example leverages this function to show a larger point symbol when points become clickable:

                                  * { \n  mark: symbol(\"circle\");\n}\n\n:mark [env('kmlOutputMode') = 'vector'] {\n  size: 8;\n}\n\n:mark {\n  size: 4;\n  fill: yellow;\n  stroke: black;\n}\n

                                  This will result in the following output:

                                  Raster output, points are not yet clickable

                                  Vector output, points are clickable and painted as larger icons

                                  One important bit about the above CSS is that the order of the rules is important. The CSS to SLD translator uses specificity to decide which rule overrides which other one, and the specificity is driven, at the time of writing, only by scale rules and access to attributes. The filter using the kmlOutputMode filter is not actually using any feature attribute, so it has the same specificity as the catch all :mark rule. Putting it first ensures that it overrides the catch all rule anyways, while putting it second would result in the output size being always 4.

                                  "},{"location":"styling/css/examples/kml/#getting-kml-marks-similar-to-the-old-kml-encoder","title":"Getting KML marks similar to the old KML encoder","text":"

                                  The old KML generator (prior to GeoServer 2.4) was not able to truly respect the marks own shape, and as a result, was simply applying the mark color to a fixed bull's eye like icon, for example:

                                  Starting with GeoServer 2.4 the KML engine has been rewritten, and among other things, it can produce an exact representation of the marks, respecting not only color, but also shape and stroking. However, what if one want to reproduce the old output look?

                                  The solution is to leverage the ability to respect marks appearance to the letter, and combine two superimposed marks to generate the desired output:

                                  * { \n  mark: symbol('circle'), symbol('circle');\n  mark-size: 12, 4;\n}\n\n:nth-mark(1) {\n  fill: red;\n  stroke: black; \n  stroke-width: 2;\n}\n\n:nth-mark(2) {\n  fill: black;\n}\n

                                  Which results in the following Google Earth output:

                                  "},{"location":"styling/css/examples/misc/","title":"Miscellaneous","text":""},{"location":"styling/css/examples/misc/#markers-sized-by-an-attribute-value","title":"Markers sized by an attribute value","text":"

                                  The following produces square markers at each point, but these are sized such that the area of each marker is proportional to the REPORTS attribute. When zoomed in (when there are less points in view) the size of the markers is doubled to make the smaller points more noticeable.

                                  * {\n  mark: symbol(square);\n}\n\n[@sd > 1M] :mark {\n  size: [sqrt(REPORTS)];\n}\n\n/* So that single-report points can be more easily seen */\n[@sd < 1M] :mark {\n  size: [sqrt(REPORTS)*2];\n}\n

                                  This example uses the sqrt function. There are many functions available for use in CSS and SLD. For more details read - /filter/function_reference

                                  "},{"location":"styling/css/examples/misc/#specifying-a-geometry-attribute","title":"Specifying a geometry attribute","text":"

                                  In some cases, typically when using a database table with multiple geometry columns, it's necessary to specify which geometry to use. For example, let's suppose you have a table containing routes start and end both containing point geometries. The following CSS will style the start with a triangle mark, and the end with a square.

                                  * {\n    geometry: [start],          [end];\n    mark:     symbol(triangle), symbol(square);\n}\n
                                  "},{"location":"styling/css/examples/misc/#generating-a-geometry-geometry-transformations","title":"Generating a geometry (Geometry Transformations)","text":"

                                  Taking the previous example a bit further, we can also perform computations on-the-fly to generate the geometries that will be drawn. Any operation that is available for GeoServer Geometry transformations in SLD is also available in CSS styles. To use them, we simply provide a more complex expression in the geometry property. For example, we could mark the start and end points of all the paths in a line layer (you can test this example out with any line layer, such as the sf:streams layer that is included in GeoServer's default data directory.)

                                  * {\n    geometry: [startPoint(the_geom)], [endPoint(the_geom)];\n    mark:     symbol(triangle),       symbol(square);\n}\n
                                  "},{"location":"styling/css/examples/misc/#rendering-different-geometry-types-linespoints-with-a-single-style","title":"Rendering different geometry types (lines/points) with a single style","text":"

                                  As one more riff on the geometry examples, we'll show how to render both the original line and the start/endpoints in a single style. This is accomplished by using stroke-geometry and mark-geometry to specify that different geometry expressions should be used for symbols compared with strokes.

                                  * {\n    stroke-geometry: [the_geom];\n    stroke:          blue;\n    mark-geometry: [startPoint(the_geom)], [endPoint(the_geom)];\n    mark:          symbol(triangle),       symbol(square);\n}\n
                                  "},{"location":"styling/css/examples/randomfills/","title":"Fills with randomized symbols","text":"

                                  It is possible to generate fills by randomly repeating a symbol in the polygons to be filled. Please refer to the equivalent SLD chapter for details on the meaning of the various options.

                                  "},{"location":"styling/css/examples/randomfills/#simple-random-distribution","title":"Simple random distribution","text":"

                                  Here is an example distributing up to 50 small \"slash\" symbols in a 100x100 pixel tile (in case of conflicts the symbol will be skipped), enabling random symbol rotation), and setting the seed to \"5\" to get a distribution different than the default one:

                                  * {\n  fill: symbol(\"shape://slash\");\n  :fill {\n    size: 8;\n    stroke: blue;\n    stroke-width: 4;\n    stroke-linecap: round;\n  };\n  stroke: black;\n  fill-random: grid;\n  fill-random-seed: 5;\n  fill-random-rotation: free;\n  fill-random-symbol-count: 50;\n  fill-random-tile-size: 100;\n}\n

                                  Random distribution of a diagonal line

                                  "},{"location":"styling/css/examples/randomfills/#thematic-map-using-point-density","title":"Thematic map using point density","text":"

                                  Randomized distributions can also be used for thematic mapping, for example, here is the SLD for a version of topp:states that displays the number of inhabitant\u00ecs varying the density of a random point distribution:

                                  * { \n  fill: symbol(\"circle\");\n  stroke: black;\n  fill-random: grid; \n  fill-random-tile-size: 100;\n\n  :fill {\n    size: 2;\n    fill: darkgray;\n  };\n  /* @title low */\n  [PERSONS < 2000000] {\n    fill-random-symbol-count: 50;\n  };\n  /* @title mid */\n  [PERSONS >= 2000000] [PERSONS < 4000000] {\n    fill-random-symbol-count: 150;\n  };\n  /* @title high */\n  [PERSONS >= 4000000] {\n    fill-random-symbol-count: 500;\n  }\n}\n

                                  Thematic map via point density approach

                                  "},{"location":"styling/css/examples/transformation/","title":"Using transformation functions","text":"

                                  The transformation functions supported described in SLD and described in the equivalent SLD chapter are also available in CSS, the following shows examples of how they can be used.

                                  "},{"location":"styling/css/examples/transformation/#recode","title":"Recode","text":"

                                  The Recode filter function transforms a set of discrete values for an attribute into another set of values, by applying a (input, output) mapping onto the values of the variable/expression that is provided as the first input of the function.

                                  Consider a chloropleth map of the US states dataset using the fill color to indicate the topographic regions for the states. The dataset has an attribute SUB_REGION containing the region code for each state. The Recode function is used to map each region code into a different color.

                                  Note

                                  It is to be noted that the following example specifies colors as hex string as opposed to native CSS color names, this is because the function syntax is expressed in CQL, which does not have support for native CSS color names.

                                  * { \n  fill: [recode(strTrim(SUB_REGION),\n         'N Eng', '#6495ED',\n         'Mid Atl', '#B0C4DE',\n         'S Atl', '#00FFFF',\n         'E N Cen', '#9ACD32',\n         'E S Cen', '#00FA9A',\n         'W N Cen', '#FFF8DC',\n         'W S Cen', '#F5DEB3',\n         'Mtn', '#F4A460',\n         'Pacific', '#87CEEB')];\n  stroke: lightgrey;\n  label: [STATE_ABBR];\n  font-family: 'Arial';\n  font-fill: black;\n  label-anchor: 0.5 0.5;\n}\n

                                  "},{"location":"styling/css/examples/transformation/#categorize","title":"Categorize","text":"

                                  The Categorize filter function transforms a continuous-valued attribute into a set of discrete values by assiging ranges of values and turning them into a color, size, width, opacity, etc.

                                  In the following example a coropleth map is build associating a color to the state population density in the ranges [ <= 20], [20 - 100], and [ > 100].

                                  * { \n  fill: [categorize(\n         PERSONS / LAND_KM,\n         '#87CEEB',\n         20,\n         '#FFFACD',\n         100,\n         '#F08080')];\n  stroke : lightgrey;\n  label: [STATE_ABBR];\n  font-family: 'Arial';\n  font-fill: black;\n  label-anchor: 0.5 0.5; \n}\n

                                  "},{"location":"styling/css/examples/transformation/#interpolate","title":"Interpolate","text":"

                                  The Interpolate filter function transforms a continuous-valued attribute into another continuous range of values by applying piecewise interpolation.

                                  The result will work for numeric values such as size, width, opacity when operating in numeric interpolation method (the default), and for colors when working in color mode.

                                  The type of curve fitting the specified points can be either linear (the default), cubic or cosine, these values are known as the interpolation mode.

                                  Both the interpolation method and mode are optional, and if provided, they are added at the end of the input list.

                                  In the following example the state population is mapped to a continuous color scale in a rather compact way using the interpolate function:

                                  * { \n  fill: [Interpolate(\n         PERSONS,\n         0, '#FEFEEE',\n         9000000, '#00FF00',\n         23000000, '#FF0000',\n         'color',\n         'linear')];\n  stroke : lightgrey;\n  label: [STATE_ABBR];\n  font-family: 'Arial';\n  font-fill: black;\n  label-anchor: 0.5 0.5; \n}\n

                                  "},{"location":"styling/mbstyle/","title":"MBStyle Styling","text":"

                                  This module allows GeoServer to use Mapbox style documents directly.

                                  A Mapbox style document is a JSON based language that defines the visual appearance of a map, what data is drawn, and the order data and styling to use when drawing.

                                  A Mapbox style document is an alternative to SLD, with different strengths and weaknesses:

                                  • Both Mapbox style and SLD documents can define an entire Map, selecting what data is drawn and in what order.

                                    As both these documents define the order in which layers are drawn they can be used to define a Layer Group (using the Add Style Group link).

                                  • Mapbox style documents provide less control then the GeoServer SLD vendor options or accomplish a result using a different approach.

                                    A GeoServer SLD TextSymbolizers allows a label priority used when drawing labels. This priority can even be generated on the fly using an expression. A MapBox style document producing the same effect would use several symbol layers, each drawing labels of different importance, and rely on draw order to ensure that the most important labels are drawn first (and are thus shown).

                                  • The key advantage of Mapbox style documents is their compatibility with Mapbox GL JS and OpenLayers.

                                    GeoServer publishes the styles used for rendering, web mapping clients or mobile apps to make use of the same Mapbox style document used by GeoServer.

                                  • Feel free to experiment with Mapbox style documents, use the GeoServer REST API to convert to SLD (complete with GeoServer vendor options).

                                  Mapbox style document support is not a part of GeoServer by default, but is available as an optional extension to install.

                                  • Installing the GeoServer MBStyle extension
                                  • Publishing a GeoServer Layer for use with Mapbox Styles
                                  • MBStyle references
                                  • MBStyle Cookbook
                                  "},{"location":"styling/mbstyle/installing/","title":"Installing the GeoServer MBStyle extension","text":"

                                  The MBStyle extension is listed on the GeoServer download page.

                                  To install MBStyle extension:

                                  1. Download the mbstyle

                                    Verify that the version number in the filename corresponds to the version of GeoServer you are running (for example 2.24.2 above).

                                  2. Extract the contents of the archive into the WEB-INF/lib directory in GeoServer. This extension includes two jars.

                                  3. Restart GeoServer.

                                  4. To confirm successful installation, check for a new MBStyle format option in the Styles editor.

                                  "},{"location":"styling/mbstyle/source/","title":"Publishing a GeoServer Layer for use with Mapbox Styles","text":"

                                  GeoServer can be configured to serve layers as vector tiles to be used as sources for Mapbox styles rendered by client-side applications such as OpenLayers.

                                  1. production_container.enable_cors in GeoServer.
                                  2. Install the Vector Tiles <vectortiles.install> extension.
                                  3. Follow the vectortiles.tutorial to publish your layers in application/vnd.mapbox-vector-tile format (You only need to do the \"Publish vector tiles in GeoWebCache\" step).

                                  Once these steps are complete, you will be able to use your GeoServer layers in any Mapbox-compatible client application that can access your GeoServer.

                                  "},{"location":"styling/mbstyle/source/#source","title":"Source","text":"

                                  The source syntax to use these GeoServer layers in your MapBox Style is:

                                  \"<source-name>\": {\n  \"type\": \"vector\",\n  \"tiles\": [\n    \"http://localhost:8080/geoserver/gwc/service/wmts?REQUEST=GetTile&SERVICE=WMTS\n        &VERSION=1.0.0&LAYER=<workspace>:<layer>&STYLE=&TILEMATRIX=EPSG:900913:{z}\n        &TILEMATRIXSET=EPSG:900913&FORMAT=application/vnd.mapbox-vector-tile\n        &TILECOL={x}&TILEROW={y}\"\n  ],\n  \"minZoom\": 0,\n  \"maxZoom\": 14\n}\n

                                  Note

                                  <workspace> and <layer> should be replaced by the workspace and name of the layer in question. {x}, {y}, and {z} are placeholder values for the tile indices and should be preserved as written.

                                  Note

                                  <source-name> should be replaced by a source name of your choice. It will be used to refer to the source when defining a layer in the Mapbox Style.

                                  Note

                                  If geoserver is not being served from localhost:8080, update the domain accordingly.

                                  "},{"location":"styling/mbstyle/cookbook/","title":"MBStyle Cookbook","text":"

                                  The MBStyle Cookbook is a collection of MBStyle \"recipes\" for creating various types of map styles. Wherever possible, each example is designed to show off a single MBStyle layer so that code can be copied from the examples and adapted when creating MBStyles of your own. While not an exhaustive reference like the MBStyle reference the MBStyle cookbook is designed to be a practical reference, showing common style templates that are easy to understand.

                                  The MBStyle Cookbook is divided into four sections: the first three for each of the vector types (points, lines, and polygons) and the fourth section for rasters to come. Each example in every section contains a screenshot showing actual GeoServer WMS output, a snippet of the MBStyle code for reference, and a link to download the full MBStyle.

                                  Each section uses data created especially for the MBStyle Cookbook, with shapefiles for vector data and GeoTIFFs for raster data.

                                  Data Type Shapefile

                                  Point mbstyle_cookbook_point.zip

                                  Line mbstyle_cookbook_line.zip

                                  Polygon mbstyle_cookbook_polygon.zip

                                  • Points
                                  • Lines
                                  • Polygons
                                  "},{"location":"styling/mbstyle/cookbook/lines/","title":"Lines","text":"

                                  While lines can also seem to be simple shapes, having length but no width, there are many options and tricks for making lines display nicely.

                                  "},{"location":"styling/mbstyle/cookbook/lines/#mbstyle_cookbook_lines_attributes","title":"Example lines layer","text":"

                                  The lines layer used in the examples below contains road information for a fictional country. For reference, the attribute table for the points in this layer is included below.

                                  fid (Feature ID) name (Road name) type (Road class)

                                  line.1 Latway highway

                                  line.2 Crescent Avenue secondary

                                  line.3 Forest Avenue secondary

                                  line.4 Longway highway

                                  line.5 Saxer Avenue secondary

                                  line.6 Ridge Avenue secondary

                                  line.7 Holly Lane local-road

                                  line.8 Mulberry Street local-road

                                  line.9 Nathan Lane local-road

                                  line.10 Central Street local-road

                                  line.11 Lois Lane local-road

                                  line.12 Rocky Road local-road

                                  line.13 Fleet Street local-road

                                  line.14 Diane Court local-road

                                  line.15 Cedar Trail local-road

                                  line.16 Victory Road local-road

                                  line.17 Highland Road local-road

                                  line.18 Easy Street local-road

                                  line.19 Hill Street local-road

                                  line.20 Country Road local-road

                                  line.21 Main Street local-road

                                  line.22 Jani Lane local-road

                                  line.23 Shinbone Alley local-road

                                  line.24 State Street local-road

                                  line.25 River Road local-road

                                  Download the lines shapefile

                                  "},{"location":"styling/mbstyle/cookbook/lines/#mbstyle_cookbook_lines_simpleline","title":"Simple line","text":"

                                  This example specifies lines be colored black with a thickness of 3 pixels.

                                  Simple line

                                  "},{"location":"styling/mbstyle/cookbook/lines/#code","title":"Code","text":"

                                  Download the \"Simple line\" MBStyle

                                  {\n  \"version\": 8,\n  \"name\": \"simple-line\",\n  \"layers\": [\n    {\n      \"id\": \"simple-line\",\n      \"type\": \"line\",\n      \"paint\": {\n        \"line-color\": \"#000000\",\n        \"line-width\": 3\n      }\n    }\n  ]\n}\n
                                  "},{"location":"styling/mbstyle/cookbook/lines/#details","title":"Details","text":"

                                  There is one layer style for this MBStyle, which is the simplest possible situation. Styling lines is accomplished using the line layer. Line 9 specifies the color of the line to be black (\"#000000\"), while line 10 specifies the width of the lines to be 3 pixels.

                                  "},{"location":"styling/mbstyle/cookbook/lines/#line-with-border","title":"Line with border","text":"

                                  This example shows how to draw lines with borders (sometimes called \"cased lines\"). In this case the lines are drawn with a 3 pixel blue center and a 1 pixel wide gray border.

                                  Line with border

                                  "},{"location":"styling/mbstyle/cookbook/lines/#code_1","title":"Code","text":"

                                  Download the \"Line with border\" MBStyle

                                  {\n  \"version\": 8,\n  \"name\": \"simple-borderedline\",\n  \"layers\": [\n    {\n      \"id\": \"simple-borderedline\",\n      \"type\": \"line\",\n      \"layout\": {\n        \"line-cap\": \"round\"\n      },\n      \"paint\": {\n        \"line-color\": \"#333333\",\n        \"line-width\": 5\n      }\n    },\n    {\n      \"id\": \"simple-line\",\n      \"type\": \"line\",\n      \"layout\": {\n        \"line-cap\": \"round\"\n      },\n      \"paint\": {\n        \"line-color\": \"#6699FF\",\n        \"line-width\": 3\n      }\n    }\n  ]\n}\n
                                  "},{"location":"styling/mbstyle/cookbook/lines/#details_1","title":"Details","text":"

                                  In this example we are drawing the lines twice to achieve the appearance of a line with a border. Since every line is drawn twice, the order of the rendering is very important. GeoServer renders layers in the order that they are presented in the MBStyle. In this style, the gray border lines are drawn first via the first layer style, followed by the blue center lines in a second layer style. This ensures that the blue lines are not obscured by the gray lines, and also ensures proper rendering at intersections, so that the blue lines \"connect\".

                                  In this example, lines 5-15 comprise the first layer style, which is the outer line (or \"stroke\"). Line 12 specifies the color of the line to be dark gray (\"#333333\"), line 13 specifies the width of this line to be 5 pixels, and in the layout line 9 a line-cap parameter of round renders the ends of the line as rounded instead of flat. (When working with bordered lines using a round line cap ensures that the border connects properly at the ends of the lines.)

                                  Lines 16-26 comprise the second layer, which is the inner line (or \"fill\"). Line 23 specifies the color of the line to be a medium blue (\"#6699FF\"), line 24 specifies the width of this line to be 3 pixels, and in the layout line 20 again renders the edges of the line to be rounded instead of flat.

                                  The result is a 3 pixel blue line with a 1 pixel gray border, since the 5 pixel gray line will display 1 pixel on each side of the 3 pixel blue line.

                                  "},{"location":"styling/mbstyle/cookbook/lines/#dashed-line","title":"Dashed line","text":"

                                  This example alters the Simple line to create a dashed line consisting of 5 pixels of drawn line alternating with 2 pixels of blank space.

                                  Dashed line

                                  "},{"location":"styling/mbstyle/cookbook/lines/#code_2","title":"Code","text":"

                                  Download the \"Dashed line\" MBStyle

                                  {\n  \"version\": 8,\n  \"name\": \"simple-dashedline\",\n  \"layers\": [\n    {\n      \"id\": \"simple-dashedline\",\n      \"type\": \"line\",\n      \"paint\": {\n        \"line-color\": \"#0000FF\",\n        \"line-width\": 3,\n        \"line-dasharray\": [5, 2]\n      }\n    }\n  ]\n}\n
                                  "},{"location":"styling/mbstyle/cookbook/lines/#details_2","title":"Details","text":"

                                  In this example, line 9 sets the color of the lines to be blue (\"#0000FF\") and line 10 sets the width of the lines to be 3 pixels. Line 11 determines the composition of the line dashes. The value of [5, 2] creates a repeating pattern of 5 pixels of drawn line, followed by 2 pixels of omitted line.

                                  "},{"location":"styling/mbstyle/cookbook/lines/#offset-line","title":"Offset line","text":"

                                  This example alters the Simple line to add a perpendicular offset line on the left side of the line, at five pixels distance.

                                  Dashed line

                                  "},{"location":"styling/mbstyle/cookbook/lines/#code_3","title":"Code","text":"

                                  Download the \"Offset line\" MBStlye

                                  {\n  \"version\": 8,\n  \"name\": \"simple-offsetline\",\n  \"layers\": [\n    {\n      \"id\": \"simple-line\",\n      \"type\": \"line\",\n      \"paint\": {\n        \"line-color\": \"#000000\",\n        \"line-width\": 1\n      }\n    },\n    {\n      \"id\": \"simple-offsetline\",\n      \"type\": \"line\",\n      \"paint\": {\n        \"line-color\": \"#FF0000\",\n        \"line-width\": 1,\n        \"line-dasharray\": [5, 2],\n        \"line-offset\": 5\n      }\n    }\n  ]\n}\n
                                  "},{"location":"styling/mbstyle/cookbook/lines/#details_3","title":"Details","text":"

                                  In this example, lines 5-11 draw a simple black line like in the Simple line example. Lines 13-21 draw a red dashed line like in the above Dashed line example. Line 20 modifies the dashed line with a 5 pixel offset from the line geometry.

                                  "},{"location":"styling/mbstyle/cookbook/points/","title":"Points","text":"

                                  Points are seemingly the simplest type of shape, possessing only position and no other dimensions. MBStyle has a circle type that can be styled to represent a point.

                                  "},{"location":"styling/mbstyle/cookbook/points/#mbstyle_cookbook_points_attributes","title":"Example points layer","text":"

                                  The points layer used for the examples below contains name and population information for the major cities of a fictional country. For reference, the attribute table for the points in this layer is included below.

                                  fid (Feature ID) name (City name) pop (Population)

                                  point.1 Borfin 157860

                                  point.2 Supox City 578231

                                  point.3 Ruckis 98159

                                  point.4 Thisland 34879

                                  point.5 Synopolis 24567

                                  point.6 San Glissando 76024

                                  point.7 Detrania 205609

                                  Download the points shapefile

                                  "},{"location":"styling/mbstyle/cookbook/points/#mbstyle_cookbook_points_simplepoint","title":"Simple point","text":"

                                  This example specifies points be styled as red circles with a diameter of 6 pixels.

                                  Simple point

                                  "},{"location":"styling/mbstyle/cookbook/points/#code","title":"Code","text":"

                                  Download the \"Simple point\" MBStyle JSON

                                  {\n  \"version\": 8,\n  \"name\": \"point-circle-test\",\n  \"layers\": [\n    {\n      \"id\": \"point\",\n      \"type\": \"circle\",\n      \"paint\": {\n        \"circle-radius\": 3,\n        \"circle-color\": \"#FF0000\",\n        \"circle-pitch-scale\": \"map\"\n      }\n    }\n  ]\n}\n
                                  "},{"location":"styling/mbstyle/cookbook/points/#details","title":"Details","text":"

                                  There is one layer in this MBStyle, which is the simplest possible situation. The \"version\" must always be set to 8. Layers is required for any MBStyle as an array. \"id\" is required and is a unique name for that layer. For our examples we will be setting the \"type\" to \"circle\".

                                  "},{"location":"styling/mbstyle/cookbook/points/#mbstyle_cookbook_points_simplepointwithstroke","title":"Simple point with stroke","text":"

                                  This example adds a stroke (or border) around the Simple point, with the stroke colored black and given a thickness of 2 pixels.

                                  Simple point with stroke

                                  "},{"location":"styling/mbstyle/cookbook/points/#code_1","title":"Code","text":"

                                  Download the \"Simple point with stroke\" MBStyle JSON

                                  {\n  \"version\": 8,\n  \"name\": \"point-circle-test\",\n  \"layers\": [\n    {\n      \"id\": \"point\",\n      \"type\": \"circle\",\n      \"paint\": {\n        \"circle-radius\": 3,\n        \"circle-color\": \"#FF0000\",\n        \"circle-pitch-scale\": \"map\",\n        \"circle-stroke-color\": \"#000000\",\n        \"circle-stroke-width\": 2\n      }\n    }\n  ]\n}\n
                                  "},{"location":"styling/mbstyle/cookbook/points/#details_1","title":"Details","text":"

                                  This example is similar to the Simple point example. Lines 12-13 specify the stroke, with line 12 setting the color to black ('#000000') and line 13 setting the width to 2 pixels.

                                  "},{"location":"styling/mbstyle/cookbook/polygons/","title":"Polygons","text":"

                                  Polygons are two dimensional shapes that contain both an outer stroke (or \"outline\") and an inside (or \"fill\"). A polygon can be thought of as an irregularly-shaped point and is styled in similar ways to circles.

                                  "},{"location":"styling/mbstyle/cookbook/polygons/#mbstyle_cookbook_polygons_attributes","title":"Example polygons layer","text":"

                                  The polygons layer used below contains county information for a fictional country. For reference, the attribute table for the polygons is included below.

                                  fid (Feature ID) name (County name) pop (Population)

                                  polygon.1 Irony County 412234

                                  polygon.2 Tracker County 235421

                                  polygon.3 Dracula County 135022

                                  polygon.4 Poly County 1567879

                                  polygon.5 Bearing County 201989

                                  polygon.6 Monte Cristo County 152734

                                  polygon.7 Massive County 67123

                                  polygon.8 Rhombus County 198029

                                  Download the polygons shapefile

                                  "},{"location":"styling/mbstyle/cookbook/polygons/#mbstyle_cookbook_polygons_simplepolygon","title":"Simple polygon","text":"

                                  This example shows a polygon filled in blue.

                                  Simple polygon

                                  "},{"location":"styling/mbstyle/cookbook/polygons/#code","title":"Code","text":"

                                  Download the \"Simple polygon\" MBStyle

                                  {\n  \"version\": 8,\n  \"name\": \"simple-polygon\",\n  \"layers\": [\n    {\n      \"id\": \"polygon\",\n      \"type\": \"fill\",\n      \"paint\": {\n        \"fill-color\": \"#000080\"\n      }\n    }\n  ]\n}\n
                                  "},{"location":"styling/mbstyle/cookbook/polygons/#details","title":"Details","text":"

                                  There is one layer for this style, which is the simplest possible situation. Styling polygons is accomplished via the fill type (line 7). Line 9 specifies dark blue ('#000080') as the polygon's fill color.

                                  Note

                                  The light-colored outlines around the polygons in the figure are artifacts of the renderer caused by the polygons being adjacent. There is no outline in this style.

                                  "},{"location":"styling/mbstyle/cookbook/polygons/#mbstyle_cookbook_polygons_simplepolygonwithstroke","title":"Simple polygon with stroke","text":"

                                  This example adds a 1 pixel white outline to the Simple polygon example.

                                  Simple polygon with stroke

                                  "},{"location":"styling/mbstyle/cookbook/polygons/#code_1","title":"Code","text":"

                                  Download the \"Simple polygon with stroke\" MBStyle

                                  {\n  \"version\": 8,\n  \"name\": \"simple-polygon-outline\",\n  \"layers\": [\n    {\n      \"id\": \"polygon-outline\",\n      \"type\": \"fill\",\n      \"paint\": {\n        \"fill-outline-color\": \"#FFFFFF\",\n        \"fill-color\": \"#000080\"\n      }\n    }\n  ]\n}\n
                                  "},{"location":"styling/mbstyle/cookbook/polygons/#details_1","title":"Details","text":"

                                  This example is similar to the Simple polygon example above, with the addition of fill-outline paint parameter (line 9). Line 9 also sets the color of stroke to white ('#FFFFFF'), the \"fill-outline-color\" can only be 1 pixel, a limitation of MBStyle.

                                  "},{"location":"styling/mbstyle/cookbook/polygons/#transparent-polygon","title":"Transparent polygon","text":"

                                  This example builds on the Simple polygon with stroke example and makes the fill partially transparent by setting the opacity to 50%.

                                  Transparent polygon

                                  "},{"location":"styling/mbstyle/cookbook/polygons/#code_2","title":"Code","text":"

                                  Download the \"Transparent polygon\" MBStyle

                                  {\n  \"version\": 8,\n  \"name\": \"simple-polygon-transparent\",\n  \"layers\": [\n    {\n      \"id\": \"polygon-transparent\",\n      \"type\": \"fill\",\n      \"paint\": {\n        \"fill-outline-color\": \"#FFFFFF\",\n        \"fill-color\": \"#000080\",\n        \"fill-opacity\": 0.5\n      }\n    }\n  ]\n}\n
                                  "},{"location":"styling/mbstyle/cookbook/polygons/#details_2","title":"Details","text":"

                                  This example is similar to the Simple polygon with stroke example, save for defining the fill's opacity in line 11. The value of 0.5 results in partially transparent fill that is 50% opaque. An opacity value of 1 would draw the fill as 100% opaque, while an opacity value of 0 would result in a completely transparent (0% opaque) fill. In this example, since the background is white, the dark blue looks lighter. Were the fill imposed on a dark background, the resulting color would be darker.

                                  "},{"location":"styling/mbstyle/reference/","title":"MBStyle references","text":"

                                  As MBstyle is heavily modeled on JSON, it may be useful to refer to the JSON-Schema documentation for basic syntax.

                                  "},{"location":"styling/mbstyle/reference/#mapbox-style-specification","title":"Mapbox Style Specification","text":"

                                  For an extended reference to these styles check out the Mapbox Style Specifications.

                                  "},{"location":"styling/mbstyle/reference/#geotools-mbstyle-extension","title":"GeoTools MBStyle extension","text":"

                                  The implementation used by GeoServer is documented here. The GeoTools project is responsible for the parser/encoder to convert between Mapbox Styles and GeoServer style objects.

                                  This documentation is actively maintained and matches the capabilities in GeoServer:

                                  • Specification

                                  When reading the above reference keep in mind the specification is written in an additive fashion, where new features are documented along with the version number range for which they are supported.

                                  As an example the basic functionality of background-color support is added in GeoTools 23.0, as shown in the following table:

                                  Support Mapbox GeoTools OpenLayers

                                  basic functionality >= 0.10.0 Not yet supported >= 2.4.0

                                  "},{"location":"styling/qgis/","title":"Generating SLD styles with QGIS","text":"

                                  QGIS includes a sophisticated style editor with many map rendering possibilities. Styles generated with QGIS can then be exported (with limitations) to SLD for usage with GeoServer.

                                  QGIS style exporting abilities have been evolving over time, as a reference:

                                  • For vector data QGIS exports SLD 1.1 styles that can be read by GeoServer. In order to get the suitable results it's important to use QGIS 3.0 or newer, and GeoServer 2.13.x or newer.
                                  • Raster data styling export is new in QGIS 3.4.5 (yet to be released at the time of writing). This new version exports SLD 1.0 styles with vendor extensions to support contrast stretching that most recent GeoServer versions support properly. For older QGIS versions limited export functionality is available using the SLD4Raster plugin.

                                  For the export it is advised to use the Save As functionality available in the style dialog, as indicated below in this guide. Other plugins exist that streamline the export process, but they may ruin the style trying to adapt it to older GeoServer versions (e.g., translating it down to SLD 1.0 by simple text processing means), or rewrite it entirely.

                                  Warning

                                  Despite the progress in the last years, it is known that not all QGIS rendering options are supported by SLD and/or by GeoServer (e.g. shapeburst symbology), and that support for exporting some parts is simply missing (e.g.. expression based symbology is supported in SLD, but QGIS won't export it). If you are interested, both projects would welcome sponsoring to improve the situation.

                                  "},{"location":"styling/qgis/#exporting-vector-symbology","title":"Exporting vector symbology","text":"

                                  This is a step by step guide to style a GeoServer demo layer, sfdem.

                                  1. Open QGIS (minimum version 3.0)

                                  2. Load the states.shp dataset from the GeoServer data directory, <GEOSERVER_DATA_DIR>/data/shapefiles/states.shp

                                  3. Double click the layer to open the Properties dialog and switch to the Symbology page.

                                  4. Choose a Graduated rendering, on the PERSONS column, and click on Classify button to generate 1.5 standard deviations, select the spectral color ramp, switch mode to Quantile and finally and click on the Classify button to generate a 5 classes map, as shown in figure.

                                    QGIS vector styling

                                  5. Switch to the Labels page, choose Single labels````, label with the ````STATE NAME` attribute and choose your preferred text rendering options, as shown in figure

                                    ![](images/qgis-label-style.png)\n*QGIS labelling*\n
                                  6. The layer renders as follows:

                                    ![](images/qgis-vector-render.png)\n*QGIS raster styling*\n
                                  7. Go back At the Properties dialog, from the bottom of the Styles page, choose Style --> Save Style.

                                    ![](images/qgis-vector-saveas.png)\n*Export using Save As...*\n
                                  8. Choose export in the SLD format, placing the file in the desired location.

                                    ![](images/qgis-choose-format.png)\n*Choosing export format...*\n
                                  9. Go in GeoServer, create a new style, use the Upload a new style dialog to choose the exported file, and click on upload link.

                                    ![](images/gs-vector-upload.png)\n*Uploading style in GeoServer...*\n
                                  10. Click on guilabel:Apply.

                                  11. Change to the Layer preview tab, click on the Preview on Layer link to choose topp:states to verify proper rendering.

                                    ![](images/gs-vector-preview.png)\n*Previewing style in GeoServer...*\n
                                  12. Eventually switch to the Publishing tab, search for states, and select Default or Associated checkbox to publish the layer to use the new style permanently.

                                    ![](images/gs-vector-associate.png)\n*Associating style in GeoServer...*\n
                                  "},{"location":"styling/qgis/#exporting-raster-symbology","title":"Exporting raster symbology","text":"

                                  The following are a couple of examples on how to export raster layers\\' symbology in QGIS and how to use the resulting SLD to style layers in GeoServer.

                                  Warning

                                  As mentioned above, this functionality has some limitations:

                                  • Hillshading vendor options are not fully supported by GeoServer so you can\\'t choose the Band and the position of the sun (Altitude and Azimuth), the Multidirectional option is not supported too
                                  • GeoServer is not able to interpret the Color Rendering options yet

                                  This is a step by step guide to style a GeoServer demo layer, sfdem.

                                  1. Open QGIS (minimum version 3.4.5)

                                  2. Load the `sfdem.tif` raster from the GeoServer data directory, `\\<GEOSERVER_DATA_DIR>/data/sf/sfdem.tif`

                                  3. Double click the layer to open the Properties dialog and switch to the Symbology page.

                                  4. Choose a Singleband pseudocolor rendering, Generate Min / Max Value Settings using Mean \u00b1 standard deviation with using 1.5 standard deviations. Generate a 5 classes Linear interpolated map, as shown in figure.

                                    ![](images/qgis-raster-style.png)\n*QGIS raster styling*\n
                                  5. The layer renders as follows:

                                    ![](images/qgis-raster-render.png)\n*QGIS raster styling*\n
                                  6. Return to the layer\\'s Properties dialog Symbology page, at the bottom of the page choose Style --> Save Style.

                                    ![](images/qgis-raster-saveas.png)\n*Export using Save As...*\n
                                  7. Choose export in the SLD format, placing the file in the desired location

                                    ![](images/qgis-choose-format.png)\n*Choosing export format...*\n
                                  8. Go in GeoServer, create a new style, use the Upload a new style dialog to choose the exported file, and click on upload link.

                                    ![](images/gs-raster-upload.png)\n*Uploading style in GeoServer...*\n
                                  9. Click on guilabel:Apply then change to the Layer preview tab. Click on the Preview on Layer link to choose sfdem to verify proper rendering.

                                    ![](images/gs-raster-preview.png)\n*Previewing style in GeoServer...*\n
                                  10. Finally switch to the Publishing tab, search for sfdem layer, and select Default or Associated checkbox to publish sfdem with the new style.

                                    ![](images/gs-raster-associate.png)\n*Associating style in GeoServer...*\n

                                  The next example shows how to style an aerial image instead.

                                  1. Download an aerial image (for example from USGS Landsat image archives) if you do not already have one. Give it a name (aerial in this example) and save it as GeoTIFF

                                    ![](images/landsat_usgs_sentinel2.png)\n*aerial.tiff*\n
                                  2. Open GeoServer, create a new Store (see Add a Store), add a GeoTIFF Raster Data Source to the Store and connect it to your aerial.tif file

                                  3. In GeoServer, create a new Layer (see Add a Layer) choosing the Store you have created in the previous step

                                  4. Open QGIS (minimum version 3.4.5)

                                  5. Load the aerial.tif raster

                                  6. Double click the layer to open the Properties dialog and switch to the Symbology page

                                  7. Choose a Multiband color rendering, set the bands (Red band == Band 1 (red), Green band == Band 2 (Green), Blue band == Band 3 (Blue)), generate Min / Max Value Settings using 5,0 - 95,0 % range of Cumulative count cut and select Stretch to MinMax as Contrast enhancement option, as shown in the picture below

                                    ![](images/qgis-sentinel2-raster-style.png)\n*QGIS layer properties - Symbology*\n
                                  8. The layer renders as follows:

                                    ![](images/qgis-sentinel2-raster-rendering.png)\n*QGIS layer rendering*\n
                                  9. Save the Style as SLD

                                  10. Go in GeoServer, use the generated SLD to create a new style, choose the aerial layer through the Preview on Layer link and verify if the layer is properly rendered (see the previous example for further details)

                                    ![](images/gs-sentinel2-raster-rendering.png)\n*GeoServer layer rendering*\n
                                  11. Finally Publish the aerial layer with the new style as described in the previous example.

                                  "},{"location":"styling/sld/","title":"SLD Styling","text":"

                                  This section discusses styling of geospatial data using \"Style Layer Descriptor\" XML files.

                                  • Introduction to SLD
                                  • Working with SLD
                                  • SLD Cookbook
                                  • SLD Reference
                                  • SLD Extensions in GeoServer
                                  • SLD Tips and Tricks
                                  • i18N in SLD
                                  "},{"location":"styling/sld/introduction/","title":"Introduction to SLD","text":"

                                  Geospatial data has no intrinsic visual component. In order to see data, it must be styled. Styling specifies color, thickness, and other visible attributes used to render data on a map.

                                  In GeoServer, styling is accomplished using a markup language called Styled Layer Descriptor, or SLD for short. SLD is an XML-based markup language and is very powerful, although somewhat complex. This page gives an introduction to the capabilities of SLD and how it works within GeoServer.

                                  Note

                                  Since GeoServer uses SLD exclusively for styling, the terms \"SLD\" and \"style\" will often be used interchangeably.

                                  "},{"location":"styling/sld/introduction/#sld-concepts","title":"SLD Concepts","text":"

                                  In GeoServer styling is most often specified using XML SLD style documents. Style documents are associated with GeoServer layers (featuretypes) to specify how they should be rendered. A style document specifies a single named layer and a user style for it. The layer and style can have metadata elements such as a name identifying them, a title for displaying them, and an abstract describing them in detail. Within the top-level style are one or more feature type styles, which act as \"virtual layers\" to provide control over rendering order (allowing styling effects such as cased lines for roads). Each feature type style contains one or more rules, which control how styling is applied based on feature attributes and zoom level. Rules select applicable features by using filters, which are logical conditions containing predicates, expressions and filter functions. To specify the details of styling for individual features, rules contain any number of symbolizers. Symbolizers specify styling for points, lines and polygons, as well as rasters and text labels.

                                  For more information refer to the SLD Reference.

                                  "},{"location":"styling/sld/introduction/#types-of-styling","title":"Types of styling","text":"

                                  Vector data that GeoServer can serve consists of three classes of shapes: Points, lines, and polygons. Lines (one dimensional shapes) are the simplest, as they have only the edge to style (also known as \"stroke\"). Polygons, two dimensional shapes, have an edge and an inside (also known as a \"fill\"), both of which can be styled differently. Points, even though they lack dimension, have both an edge and a fill (not to mention a size) that can be styled. For fills, color can be specified; for strokes, color and thickness can be specified.

                                  GeoServer also serves raster data. This can be styled with a wide variety of control over color palette, opacity, contrast and other parameters.

                                  More advanced styling is possible as well. Points can be specified with well-known shapes like circles, squares, stars, and even custom graphics or text. Lines can be styled with a dash styles and hashes. Polygons can be filled with a custom tiled graphics. Styling can be based on attributes in the data, so that certain features are styled differently. Text labels on features are possible as well. Styling can also be determined by zoom level, so that features are displayed in a way appropriate to their apparent size. The possibilities are vast.

                                  "},{"location":"styling/sld/introduction/#a-basic-style-example","title":"A basic style example","text":"

                                  A good way to learn about SLD is to study styling examples. The following is a simple SLD that can be applied to a layer that contains points, to style them as red circles with a size of 6 pixels. (This is the first example in the Points section of the SLD Cookbook.)

                                  <?xml version=\"1.0\" encoding=\"ISO-8859-1\"?>\n<StyledLayerDescriptor version=\"1.0.0\" \n    xsi:schemaLocation=\"http://www.opengis.net/sld StyledLayerDescriptor.xsd\" \n    xmlns=\"http://www.opengis.net/sld\" \n    xmlns:ogc=\"http://www.opengis.net/ogc\" \n    xmlns:xlink=\"http://www.w3.org/1999/xlink\" \n    xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\">\n  <NamedLayer>\n    <Name>Simple point</Name>\n    <UserStyle>\n      <Title>GeoServer SLD Cook Book: Simple point</Title>\n      <FeatureTypeStyle>\n        <Rule>\n          <PointSymbolizer>\n            <Graphic>\n              <Mark>\n                <WellKnownName>circle</WellKnownName>\n                <Fill>\n                  <CssParameter name=\"fill\">#FF0000</CssParameter>\n                </Fill>\n              </Mark>\n              <Size>6</Size>\n            </Graphic>\n          </PointSymbolizer>\n        </Rule>\n      </FeatureTypeStyle>\n    </UserStyle>\n  </NamedLayer>\n</StyledLayerDescriptor>\n

                                  Although the example looks long, only a few lines are really important to understand. Line 14 states that a \"PointSymbolizer\" is to be used to style data as points. Lines 15-17 state that points are to be styled using a graphic shape specified by a \"well known name\", in this case a circle. SLD provides names for many shapes such as \"square\", \"star\", \"triangle\", etc. Lines 18-20 specify the shape should be filled with a color of #FF0000 (red). This is an RGB color code, written in hexadecimal, in the form of #RRGGBB. Finally, line 22 specifies that the size of the shape is 6 pixels in width. The rest of the structure contains metadata about the style, such as a name identifying the style and a title for use in legends.

                                  Note

                                  In SLD documents some tags have prefixes, such as ogc:. This is because they are defined in XML namespaces. The top-level StyledLayerDescriptor tag (lines 2-7) specifies two XML namespaces, one called xmlns, and one called xmlns:ogc. The first namespace is the default for the document, so tags belonging to it do not need a prefix. Tags belonging to the second require the prefix ogc:. In fact, the namespace prefixes can be any identifier. The first namespace could be called xmlns:sld (as it often is) and then all the tags in this example would require an sld: prefix. The key point is that tags need to have the prefix for the namespace they belong to.

                                  See the SLD Cookbook for more examples of styling with SLD.

                                  "},{"location":"styling/sld/language/","title":"i18N in SLD","text":"

                                  This section describes how to specify metadata (titles and abstracts) in different languages in SLD documents.

                                  "},{"location":"styling/sld/language/#metadata-in-different-languages","title":"Metadata in different languages","text":"

                                  GeoServer extends Title and Abstract sections, so that text in different languages can be included.

                                  This is an example of the syntax to use:

                                  <Title>This is the default title\n  <Localized lang=\"en\">English title</Localized>\n  <Localized lang=\"it\">Titolo in italiano</Localized>\n</Title>\n

                                  A default text (This is the default title in the example) and a set of Localized sections, one for each language that you want to support.

                                  Each Localized section specifies the language (using a two letter abbreviation in the lang attribute) and the related text.

                                  Currently, GeoServer supports localized text in SLD in WMS GetLegendGraphic requests (legends that contain labels are rendered using the requested language, if a LANGUAGE parameter is added to the request, e.g. LANGUAGE=it).

                                  "},{"location":"styling/sld/language/#using-the-language-function","title":"Using the language function","text":"

                                  GeoServer provides a language function that can be used to get the LANGUAGE requested in GetMap or GetFeatureInfo request. The function can be used to generate maps whose symbology is language dependent.

                                  Here is an example providing labels in multiple languages, integrating the language function with Recode e.g:

                                  <TextSymbolizer>\n       <Label>\n         <ogc:Function name=\"Recode\">\n           <ogc:Function name=\"language\"/>\n           <ogc:Literal/>\n           <ogc:PropertyName>name_default</ogc:PropertyName>\n           <ogc:Literal>en</ogc:Literal>\n           <ogc:PropertyName>name_en</ogc:PropertyName>\n           <ogc:Literal>it</ogc:Literal>\n           <ogc:PropertyName>name_it</ogc:PropertyName>\n           <ogc:Literal>fr</ogc:Literal>\n           <ogc:PropertyName>name_fr</ogc:PropertyName>\n         </ogc:Function>\n       </Label>\n       <Fill>\n         <CssParameter name=\"fill\">#000000</CssParameter>\n       </Fill>\n</TextSymbolizer>\n

                                  The empty <ogc:Literal/> elements acts as the default language, matching a value with a missing language parameter. If there is no default value,the default language will be returned. See Internationalization (i18n) for details on Default Language.

                                  It is also possible to use the language function in a rule filter, filtering rules for both rendering and legend production purposes. This one shows how to refer to different symbols based on the current language:

                                  <Rule>\n  <ogc:Filter>\n    <ogc:PropertyIsEqualTo>\n      <ogc:Function name=\"language\"/>\n      <ogc:Literal>it</ogc:Literal>\n    </ogc:PropertyIsEqualTo>\n  </ogc:Filter>\n  <PointSymbolizer>\n    <Graphic>\n      <ExternalGraphic>\n        <OnlineResource xlink:type=\"simple\" xlink:href=\"it_symbol.png\"/>\n        <Format>image/png</Format>\n      </ExternalGraphic>\n      <Size>32</Size>\n    </Graphic>\n  </PointSymbolizer>\n</Rule>\n<Rule>\n  <ogc:Filter>\n    <ogc:PropertyIsEqualTo>\n      <ogc:Function name=\"language\"/>\n      <ogc:Literal>de</ogc:Literal>\n    </ogc:PropertyIsEqualTo>\n  </ogc:Filter>\n  <PointSymbolizer>\n    <Graphic>\n      <ExternalGraphic>\n        <OnlineResource xlink:type=\"simple\" xlink:href=\"de_symbol.png\"/>\n        <Format>image/png</Format>\n      </ExternalGraphic>\n      <Size>32</Size>\n    </Graphic>\n  </PointSymbolizer>\n</Rule>\n

                                  Specifically for the external graphics, if the external symbols are all co-located, and follow a naming convention including the language identifier, then it's also possible to embed the language in the symbol URL:

                                  <Rule>\n  <PointSymbolizer>\n    <Graphic>\n      <ExternalGraphic>\n        <OnlineResource xlink:type=\"simple\" xlink:href=\"${language()}_symbol.png\"/>\n        <Format>image/png</Format>\n      </ExternalGraphic>\n      <Size>32</Size>\n    </Graphic>\n  </PointSymbolizer>\n</Rule>\n
                                  "},{"location":"styling/sld/working/","title":"Working with SLD","text":"

                                  This section describes how to create, view and troubleshoot SLD styling in GeoServer.

                                  "},{"location":"styling/sld/working/#creating","title":"Creating","text":"

                                  GeoServer comes with some basic styles defined in its catalog. Any number of new styles can be added to the catalog. Styles can also be specified externally to the server, either to define a complete map, or to extend the server style catalog using library mode.

                                  "},{"location":"styling/sld/working/#catalog-styles","title":"Catalog Styles","text":"

                                  Styles in the catalog can be viewed, edited and validated via the Styles page menu of the Web administration interface. They may also be created and accessed via the REST Styles API.

                                  There are two types of Catalog Styles: Symbology Encoding styles (the default) and Style Layer Descriptor styles.

                                  "},{"location":"styling/sld/working/#symbology-encoding-styles","title":"Symbology Encoding Styles","text":"

                                  A Symbology Encoding style consists of a Symbology Encoding document used to specify the styling of a single layer. In GeoServer, this is more commonly referred to as a style.

                                  GeoServer supports the use of a StyledLayerDescriptor document containing a single <NamedLayer> element, which contains a single <UserStyle> element to specify the styling.

                                  • When used in this fashion the layer name is ignored, since the style may be applied to many different layers.
                                  • When using an StyledLayerDescriptor generated by another application keep in mind only the first <NamedLayer> is used, any subsequent content is ignored.

                                  Every layer (featuretype) registered with GeoServer must have at least one symbology encoding style associated with it, which is the default style for rendering the layer. Any number of additional styles can be associated with a layer. This allows layers to have appropriate styles advertised in the WMS GetCapabilities document. A layer's styles can be changed using the Layers page of the Web administration interface.

                                  Note

                                  When adding a layer and a style for it to GeoServer at the same time, the style should be added first, so that the new layer can be associated with the style immediately.

                                  "},{"location":"styling/sld/working/#style-layer-descriptor-styles","title":"Style Layer Descriptor Styles","text":"

                                  A Style Layer Descriptor is a StyledLayerDescriptor document containing any number of <NamedLayer> and <UserLayer> elements, each of which may contain any number of <UserStyle> or <NamedStyle> elements.

                                  Within a Style Layer Descriptor document, the name of any <NamedLayer> elements should match a layer (or layer group) in the catalog. Likewise, any <NamedStyle> elements should refer to a style in the catalog.

                                  Style Layer Descriptor styles can define new layers of styled data, by using the InlineFeature element to provide feature data.

                                  Within GeoServer, when Style Layer Descriptor styles are used they are typically in the form of style groups. Style groups can be added to layer groups as an alternative way of defining a collection of styled layers, using either the Web Administration interface or the REST API.

                                  Style Layer Descriptor styles can still be assigned to layers and used like a layer style, in which case only the first <NamedLayer> will be used. Style Layer Descriptor styles can also be used as an External Style, via the geoserver styles endpoint (/geoserver/styles) or the geoserver REST api.

                                  "},{"location":"styling/sld/working/#external-styles","title":"External Styles","text":"

                                  Styling can be defined externally to the server in a number of ways:

                                  • An internet-accessible SLD document can be provided via the SLD=url parameter in a WMS GetMap GET request
                                  • An SLD document can be provided directly in a WMS GetMap GET request using the SLD_BODY=style parameter. The SLD XML must be URL-encoded.
                                  • A StyledLayerDescriptor element can be included in a WMS GetMap POST request XML document.

                                  In all of these cases, if the WMS layers parameter is not supplied then the map content is defined completely by the layers and styles present in the external SLD. If the layers parameter is present, then styling operates in Library Mode.

                                  The structure of an external style is the same as a Style Layer Descriptor style, as described above.

                                  External styles can define new layers of styled data, by using the SLD InlineFeature element to provide feature data. This can be used to implement dynamic feature highlighting, for example.

                                  External styling may be generated dynamically by client applications, This provides a powerful way for clients to control styling effects.

                                  "},{"location":"styling/sld/working/#sld_library_mode","title":"Library Mode","text":"

                                  In library mode externally-defined styles are treated as a style library, which acts as an extension to the server style catalog. Library mode occurs when map layers and styles are specified using the layers and styles WMS parameters, and additional styling is supplied externally using one of the methods described in the previous section. The styles in the external style document take precedence over the catalog styles during rendering.

                                  Style lookup in library mode operates as follows:

                                  • For each layer in the layers list, the applied style is either a named style specified in the styles list (if present), or the layer default style
                                  • For a named style, if the external style document has a <NamedLayer>...<UserStyle> with matching layer name and style name, then it is used. Otherwise, the style name is searched for in the catalog. If it is not found there, an error occurs.
                                  • For a default style, the external style document is searched to find a <NamedLayer> element with the layer name. If it contains a <UserStyle> with the <IsDefault> element having the value 1 then that style is used. Otherwise, the default server style for the layer (which must exist) is used.

                                  Generally it is simpler and more performant to use styles from the server catalog. However, library mode can be useful if it is required to style a map containing many layers and where only a few of them need to have their styling defined externally.

                                  "},{"location":"styling/sld/working/#viewing","title":"Viewing","text":"

                                  Once a style has been associated with a layer, the resulting rendering of the layer data can be viewed by using the Layer Preview. The most convenient output format to use is the built-in OpenLayers viewer. Styles can be modified while the view is open, and their effect is visible as soon as the map view is panned or zoomed. Alternate styles can be viewed by specifying them in the styles WMS request parameter.

                                  To view the effect of compositing multiple styled layers, several approaches are available:

                                  • Create a layer group for the desired layers using the Layer Groups page, and preview it. Non-default styles can be specified for layers if required.
                                  • Submit a WMS GetMap GET request specifying multiple layers in the layers parameter, and the corresponding styles in the styles parameter (if non-default styles are required).
                                  • Submit a WMS GetMap POST request containing a StyledLayerDescriptor element specifying server layers, optional layers of inline data, and either named catalog styles or user-defined styling for each layer.
                                  "},{"location":"styling/sld/working/#troubleshooting","title":"Troubleshooting","text":"

                                  SLD is a type of programming language, not unlike creating a web page or building a script. As such, problems may arise that may require troubleshooting.

                                  "},{"location":"styling/sld/working/#syntax-errors","title":"Syntax Errors","text":"

                                  To minimize syntax errors when creating the SLD, it is recommended to use a text editor that is designed to work with XML (such as the Style Editor provided in the GeoServer UI). XML editors can make finding syntax errors easier by providing syntax highlighting and (sometimes) built-in error checking.

                                  The GeoServer Style Editor allows validating a document against the SLD XML schema. This is not mandatory, but is recommended to do before saving styles.

                                  "},{"location":"styling/sld/working/#semantic-errors","title":"Semantic Errors","text":"

                                  Semantic errors cannot be caught by SLD validation, but show up when a style is applied during map rendering. Most of the time this will result in a map displaying no features (a blank map), but some errors will prevent the map from rendering at all.

                                  The easiest way to fix semantic errors in an SLD is to try to isolate the error. If the SLD is long with many rules and filters, try temporarily removing some of them to see if the errors go away.

                                  In some cases the server will produce a WMS Exception document which may help to identify the error. It is also worth checking the server log to see if any error messages have been recorded.

                                  "},{"location":"styling/sld/cookbook/","title":"SLD Cookbook","text":"

                                  The SLD Cookbook is a collection of SLD \"recipes\" for creating various types of map styles. Wherever possible, each example is designed to show off a single SLD feature so that code can be copied from the examples and adapted when creating SLDs of your own. While not an exhaustive reference like the SLD Reference or the OGC SLD 1.0 specification the SLD Cookbook is designed to be a practical reference, showing common style templates that are easy to understand.

                                  The SLD Cookbook is divided into four sections: the first three for each of the vector types (points, lines, and polygons) and the fourth section for rasters. Each example in every section contains a screenshot showing actual GeoServer WMS output, a snippet of the SLD code for reference, and a link to download the full SLD.

                                  Each section uses data created especially for the SLD Cookbook, with shapefiles for vector data and GeoTIFFs for raster data. The projection for data is EPSG:4326. All files can be easily loaded into GeoServer in order to recreate the examples.

                                  Data Type Shapefile

                                  Point sld_cookbook_point.zip

                                  Line sld_cookbook_line.zip

                                  Polygon sld_cookbook_polygon.zip

                                  Raster sld_cookbook_raster.zip

                                  • Points
                                  • Lines
                                  • Polygons
                                  • Rasters
                                  "},{"location":"styling/sld/cookbook/lines/","title":"Lines","text":"

                                  While lines can also seem to be simple shapes, having length but no width, there are many options and tricks for making lines display nicely.

                                  Warning

                                  The code examples shown on this page are not the full SLD code, as they omit the SLD header and footer information for the sake of brevity. Please use the links to download the full SLD for each example.

                                  "},{"location":"styling/sld/cookbook/lines/#sld_cookbook_lines_attributes","title":"Example lines layer","text":"

                                  The lines layer used in the examples below contains road information for a fictional country. For reference, the attribute table for the points in this layer is included below.

                                  fid (Feature ID) name (Road name) type (Road class)

                                  line.1 Latway highway

                                  line.2 Crescent Avenue secondary

                                  line.3 Forest Avenue secondary

                                  line.4 Longway highway

                                  line.5 Saxer Avenue secondary

                                  line.6 Ridge Avenue secondary

                                  line.7 Holly Lane local-road

                                  line.8 Mulberry Street local-road

                                  line.9 Nathan Lane local-road

                                  line.10 Central Street local-road

                                  line.11 Lois Lane local-road

                                  line.12 Rocky Road local-road

                                  line.13 Fleet Street local-road

                                  line.14 Diane Court local-road

                                  line.15 Cedar Trail local-road

                                  line.16 Victory Road local-road

                                  line.17 Highland Road local-road

                                  line.18 Easy Street local-road

                                  line.19 Hill Street local-road

                                  line.20 Country Road local-road

                                  line.21 Main Street local-road

                                  line.22 Jani Lane local-road

                                  line.23 Shinbone Alley local-road

                                  line.24 State Street local-road

                                  line.25 River Road local-road

                                  Download the lines shapefile

                                  "},{"location":"styling/sld/cookbook/lines/#sld_cookbook_lines_simpleline","title":"Simple line","text":"

                                  This example specifies lines be colored black with a thickness of 3 pixels.

                                  Simple line

                                  "},{"location":"styling/sld/cookbook/lines/#code","title":"Code","text":"

                                  View and download the full \"Simple line\" SLD

                                  <FeatureTypeStyle>\n  <Rule>\n    <LineSymbolizer>\n      <Stroke>\n        <CssParameter name=\"stroke\">#000000</CssParameter>\n        <CssParameter name=\"stroke-width\">3</CssParameter>    \n      </Stroke>\n    </LineSymbolizer>\n  </Rule>\n</FeatureTypeStyle>\n
                                  "},{"location":"styling/sld/cookbook/lines/#details","title":"Details","text":"

                                  There is one <Rule> in one <FeatureTypeStyle> for this SLD, which is the simplest possible situation. (All subsequent examples will contain one <Rule> and one <FeatureTypeStyle> unless otherwise specified.) Styling lines is accomplished via the <LineSymbolizer> (lines 3-8). Line 5 specifies the color of the line to be black (#000000), while line 6 specifies the width of the lines to be 3 pixels.

                                  "},{"location":"styling/sld/cookbook/lines/#line-with-border","title":"Line with border","text":"

                                  This example shows how to draw lines with borders (sometimes called \"cased lines\"). In this case the lines are drawn with a 3 pixel blue center and a 1 pixel wide gray border.

                                  Line with border

                                  "},{"location":"styling/sld/cookbook/lines/#code_1","title":"Code","text":"

                                  View and download the full \"Line with border\" SLD

                                  <FeatureTypeStyle>\n   <Rule>\n    <LineSymbolizer>\n      <Stroke>\n        <CssParameter name=\"stroke\">#333333</CssParameter>                           \n        <CssParameter name=\"stroke-width\">5</CssParameter>    \n        <CssParameter name=\"stroke-linecap\">round</CssParameter>    \n      </Stroke> \n    </LineSymbolizer>\n  </Rule>\n</FeatureTypeStyle>\n<FeatureTypeStyle>\n   <Rule>\n    <LineSymbolizer>\n    <Stroke>\n        <CssParameter name=\"stroke\">#6699FF</CssParameter>                           \n        <CssParameter name=\"stroke-width\">3</CssParameter> \n        <CssParameter name=\"stroke-linecap\">round</CssParameter>  \n      </Stroke>\n    </LineSymbolizer>                                          \n   </Rule>\n</FeatureTypeStyle>\n
                                  "},{"location":"styling/sld/cookbook/lines/#details_1","title":"Details","text":"

                                  Lines in SLD have no notion of a \"fill\", only \"stroke\". Thus, unlike points or polygons, it is not possible to style the \"edge\" of the line geometry. It is, however, possible to achieve this effect by drawing each line twice: once with a certain width and again with a slightly smaller width. This gives the illusion of fill and stroke by obscuring the larger lines everywhere except along the edges of the smaller lines.

                                  Since every line is drawn twice, the order of the rendering is very important. GeoServer renders <FeatureTypeStyle>s in the order that they are presented in the SLD. In this style, the gray border lines are drawn first via the first <FeatureTypeStyle>, followed by the blue center lines in a second <FeatureTypeStyle>. This ensures that the blue lines are not obscured by the gray lines, and also ensures proper rendering at intersections, so that the blue lines \"connect\".

                                  In this example, lines 1-11 comprise the first <FeatureTypeStyle>, which is the outer line (or \"stroke\"). Line 5 specifies the color of the line to be dark gray (#333333), line 6 specifies the width of this line to be 5 pixels, and in line 7 a stroke-linecap parameter of round renders the ends of the line as rounded instead of flat. (When working with bordered lines using a round line cap ensures that the border connects properly at the ends of the lines.)

                                  Lines 12-22 comprise the second <FeatureTypeStyle>, which is the inner line (or \"fill\"). Line 16 specifies the color of the line to be a medium blue (#6699FF), line 17 specifies the width of this line to be 3 pixels, and line 18 again renders the edges of the line to be rounded instead of flat.

                                  The result is a 3 pixel blue line with a 1 pixel gray border, since the 5 pixel gray line will display 1 pixel on each side of the 3 pixel blue line.

                                  "},{"location":"styling/sld/cookbook/lines/#dashed-line","title":"Dashed line","text":"

                                  This example alters the Simple line to create a dashed line consisting of 5 pixels of drawn line alternating with 2 pixels of blank space.

                                  Dashed line

                                  "},{"location":"styling/sld/cookbook/lines/#code_2","title":"Code","text":"

                                  View and download the full \"Dashed line\" SLD

                                  <FeatureTypeStyle>\n  <Rule>\n    <LineSymbolizer>\n      <Stroke>\n        <CssParameter name=\"stroke\">#0000FF</CssParameter>\n        <CssParameter name=\"stroke-width\">3</CssParameter>\n        <CssParameter name=\"stroke-dasharray\">5 2</CssParameter>\n      </Stroke>\n    </LineSymbolizer>\n  </Rule>\n</FeatureTypeStyle>\n
                                  "},{"location":"styling/sld/cookbook/lines/#details_2","title":"Details","text":"

                                  In this example, line 5 sets the color of the lines to be blue (#0000FF) and line 6 sets the width of the lines to be 3 pixels. Line 7 determines the composition of the line dashes. The value of 5 2 creates a repeating pattern of 5 pixels of drawn line, followed by 2 pixels of omitted line.

                                  "},{"location":"styling/sld/cookbook/lines/#offset-line","title":"Offset line","text":"

                                  This example alters the Simple line to add a perpendicular offset line on the left side of the line, at five pixels distance.

                                  Offset line

                                  "},{"location":"styling/sld/cookbook/lines/#code_3","title":"Code","text":"

                                  View and download the full \"Dashed line\" SLD

                                  <FeatureTypeStyle>\n  <Rule>\n    <LineSymbolizer>\n      <Stroke>\n        <CssParameter name=\"stroke\">#000000</CssParameter>\n      </Stroke>\n    </LineSymbolizer>\n    <LineSymbolizer>\n      <Stroke>\n        <CssParameter name=\"stroke\">#FF0000</CssParameter>\n        <CssParameter name=\"stroke-dasharray\">5 2</CssParameter>\n      </Stroke>\n      <PerpendicularOffset>5</PerpendicularOffset>\n    </LineSymbolizer>\n  </Rule>\n</FeatureTypeStyle>\n
                                  "},{"location":"styling/sld/cookbook/lines/#details_3","title":"Details","text":"

                                  In this example, the first line symbolizer just paints the lines black. line 8 begins a second lines symbolizer, sets the color of the lines to be red (#FF0000) at line 10 and determines the composition of the line dashes at Line 11. Line 13 finally specifies a perpendicular offset of 5 pixels (positive, thus on the left side).

                                  "},{"location":"styling/sld/cookbook/lines/#railroad-hatching","title":"Railroad (hatching)","text":"

                                  This example uses hatching to create a railroad style. Both the line and the hatches are black, with a 2 pixel thickness for the main line and a 1 pixel width for the perpendicular hatches.

                                  Note

                                  This example leverages an SLD extension in GeoServer. Hatching is not part of the standard SLD 1.0 specification.

                                  Railroad (hatching)

                                  "},{"location":"styling/sld/cookbook/lines/#code_4","title":"Code","text":"

                                  View and download the full \"Railroad (hatching)\" SLD

                                  <FeatureTypeStyle>\n  <Rule>\n    <LineSymbolizer>\n      <Stroke>\n        <CssParameter name=\"stroke\">#333333</CssParameter>\n        <CssParameter name=\"stroke-width\">3</CssParameter>\n      </Stroke>\n    </LineSymbolizer> \n    <LineSymbolizer>\n      <Stroke>\n        <GraphicStroke>\n          <Graphic>\n            <Mark>\n              <WellKnownName>shape://vertline</WellKnownName>\n              <Stroke>\n                <CssParameter name=\"stroke\">#333333</CssParameter>\n                <CssParameter name=\"stroke-width\">1</CssParameter>\n              </Stroke>\n            </Mark>\n            <Size>12</Size>\n          </Graphic>\n        </GraphicStroke>\n      </Stroke>\n    </LineSymbolizer>\n  </Rule>\n</FeatureTypeStyle>\n
                                  "},{"location":"styling/sld/cookbook/lines/#details_4","title":"Details","text":"

                                  In this example there are two <LineSymbolizer>s. The first symbolizer, on lines 3-8, draws a standard line, with line 5 drawing the lines as dark gray (#333333) and line 6 setting the width of the lines to be 2 pixels.

                                  The hatching is invoked in the second symbolizer, on lines 9-24. Line 14 specifies that the symbolizer draw a vertical line hatch (shape://vertline) perpendicular to the line geometry. Lines 16-17 set the hatch color to dark gray (#333333) and width to 1 pixel. Finally, line 20 specifies both the length of the hatch and the distance between each hatch to both be 12 pixels.

                                  "},{"location":"styling/sld/cookbook/lines/#spaced-graphic-symbols","title":"Spaced graphic symbols","text":"

                                  This example uses a graphic stroke along with dash arrays to create a \"dot and space\" line type. Adding the dash array specification allows to control the amount of space between one symbol and the next one. Without using the dash array the lines would be densely populated with dots, each one touching the previous one.

                                  Note

                                  This example may not work in other systems using SLD, since they may not support combining the use of stroke-dasharray and GraphicStroke. While the SLD is spec-compliant, the SLD specification does not state what this combination is supposed to produce.

                                  Spaced symbols along a line

                                  "},{"location":"styling/sld/cookbook/lines/#code_5","title":"Code","text":"

                                  View and download the full \"Spaced symbols\" SLD

                                  <FeatureTypeStyle>\n  <Rule>\n    <LineSymbolizer>\n      <Stroke>\n        <GraphicStroke>\n          <Graphic>\n            <Mark>\n              <WellKnownName>circle</WellKnownName>\n              <Fill>\n                <CssParameter name=\"fill\">#666666</CssParameter>  \n              </Fill>\n              <Stroke>\n                <CssParameter name=\"stroke\">#333333</CssParameter>\n                <CssParameter name=\"stroke-width\">1</CssParameter>\n              </Stroke>\n            </Mark>\n            <Size>4</Size>\n          </Graphic>\n        </GraphicStroke>\n        <CssParameter name=\"stroke-dasharray\">4 6</CssParameter>\n      </Stroke>\n    </LineSymbolizer>\n  </Rule>\n</FeatureTypeStyle>\n
                                  "},{"location":"styling/sld/cookbook/lines/#details_5","title":"Details","text":"

                                  This example, like others before, uses a GraphicStroke to place a graphic symbol along a line. The symbol, defined at lines 7-16 is a 4 pixel gray circle with a dark gray outline. The spacing between symbols is controlled with the stroke-dasharray at line 20, which specifies 4 pixels of pen-down (just enough to draw the circle) and 6 pixels of pen-up, to provide the spacing.

                                  "},{"location":"styling/sld/cookbook/lines/#sld_cookbook_lines_defaultlabel","title":"Alternating symbols with dash offsets","text":"

                                  This example shows how to create a complex line style which alternates a dashed line and a graphic symbol. The code builds on features shown in the previous examples:

                                  • stroke-dasharray controls pen-down/pen-up behavior to generate dashed lines
                                  • GraphicStroke places symbols along a line
                                  • combining the two allows control of symbol spacing

                                  This also shows the usage of a dash offset, which controls where rendering starts in the dash array. For example, with a dash array of 5 10 and a dash offset of 7 the renderer starts drawing the pattern 7 pixels from the beginning. It skips the 5 pixels pen-down section and 2 pixels of the pen-up section, then draws the remaining 8 pixels of pen-up, then 5 down, 10 up, and so on.

                                  The example shows how to use these features to create two synchronized sequences of dash arrays, one drawing line segments and the other symbols.

                                  Note

                                  This example may not work in other systems using SLD, since they may not support combining the use of stroke-dasharray and GraphicStroke. While the SLD is spec-compliant, the SLD specification does not state what this combination is supposed to produce.

                                  Alternating dash and symbol

                                  "},{"location":"styling/sld/cookbook/lines/#code_6","title":"Code","text":"

                                  View and download the full \"Spaced symbols\" SLD

                                  <FeatureTypeStyle>\n  <Rule>\n    <LineSymbolizer>\n      <Stroke>\n        <CssParameter name=\"stroke\">#0000FF</CssParameter>\n        <CssParameter name=\"stroke-width\">1</CssParameter>\n        <CssParameter name=\"stroke-dasharray\">10 10</CssParameter>\n      </Stroke>\n    </LineSymbolizer>\n    <LineSymbolizer>\n      <Stroke>\n        <GraphicStroke>\n          <Graphic>\n            <Mark>\n              <WellKnownName>circle</WellKnownName>\n              <Stroke>\n                <CssParameter name=\"stroke\">#000033</CssParameter>\n                <CssParameter name=\"stroke-width\">1</CssParameter>\n              </Stroke>\n            </Mark>\n            <Size>5</Size>\n          </Graphic>\n        </GraphicStroke>\n        <CssParameter name=\"stroke-dasharray\">5 15</CssParameter>\n        <CssParameter name=\"stroke-dashoffset\">7.5</CssParameter>\n      </Stroke>\n    </LineSymbolizer>\n  </Rule>\n</FeatureTypeStyle>\n
                                  "},{"location":"styling/sld/cookbook/lines/#details_6","title":"Details","text":"

                                  In this example two LineSymbolizers use stroke-dasharray and different symbology to produce a sequence of alternating dashes and symbols. The first symbolizer (lines 3-9) is a simple dashed line alternating 10 pixels of pen-down with 10 pixels of pen-up. The second symbolizer (lines 10-27) alternates a 5 pixel empty circle with 15 pixels of white space. The circle symbol is produced by a Mark element, with its symbology specified by stroke parameters (lines 17-18). The spacing between symbols is controlled with the stroke-dasharray (line 24), which specifies 5 pixels of pen-down (just enough to draw the circle) and 15 pixels of pen-up. In order to have the two sequences positioned correctly the second one uses a stroke-dashoffset of 7.5 (line 25). This makes the sequence start with 12.5 pixels of white space, then a circle (which is then centered between the two line segments of the other pattern), then 15 pixels of white space, and so on.

                                  "},{"location":"styling/sld/cookbook/lines/#line-with-default-label","title":"Line with default label","text":"

                                  This example shows a text label on the simple line. This is how a label will be displayed in the absence of any other customization.

                                  Line with default label

                                  "},{"location":"styling/sld/cookbook/lines/#code_7","title":"Code","text":"

                                  View and download the full \"Line with default label\" SLD

                                  <FeatureTypeStyle>\n  <Rule>\n    <LineSymbolizer>\n      <Stroke>\n        <CssParameter name=\"stroke\">#FF0000</CssParameter>\n      </Stroke>\n    </LineSymbolizer>\n    <TextSymbolizer>\n      <Label>\n        <ogc:PropertyName>name</ogc:PropertyName>\n      </Label>\n      <LabelPlacement>\n        <LinePlacement />\n      </LabelPlacement>\n      <Fill>\n        <CssParameter name=\"fill\">#000000</CssParameter>\n      </Fill>\n    </TextSymbolizer>\n  </Rule>\n</FeatureTypeStyle>\n
                                  "},{"location":"styling/sld/cookbook/lines/#details_7","title":"Details","text":"

                                  In this example, there is one rule with a <LineSymbolizer> and a <TextSymbolizer>. The <LineSymbolizer> (lines 3-7) draws red lines (#FF0000). Since no width is specified, the default is set to 1 pixel. The <TextSymbolizer> (lines 8-15) determines the labeling of the lines. Lines 9-11 specify that the text of the label will be determined by the value of the \"name\" attribute for each line. (Refer to the attribute table in the Example lines layer section if necessary.) Line 13 sets the text color to black. All other details about the label are set to the renderer default, which here is Times New Roman font, font color black, and font size of 10 pixels.

                                  "},{"location":"styling/sld/cookbook/lines/#sld_cookbook_lines_labelfollowingline","title":"Label following line","text":"

                                  This example renders the text label to follow the contour of the lines.

                                  Note

                                  Labels following lines is an SLD extension specific to GeoServer. It is not part of the SLD 1.0 specification.

                                  Label following line

                                  "},{"location":"styling/sld/cookbook/lines/#code_8","title":"Code","text":"

                                  View and download the full \"Label following line\" SLD

                                  <FeatureTypeStyle>\n  <Rule>\n    <LineSymbolizer>\n      <Stroke>\n        <CssParameter name=\"stroke\">#FF0000</CssParameter>\n      </Stroke>\n    </LineSymbolizer>\n    <TextSymbolizer>\n      <Label>\n        <ogc:PropertyName>name</ogc:PropertyName>\n      </Label>\n      <LabelPlacement>\n        <LinePlacement />\n      </LabelPlacement>\n      <Fill>\n        <CssParameter name=\"fill\">#000000</CssParameter>\n      </Fill>\n      <VendorOption name=\"followLine\">true</VendorOption>\n    </TextSymbolizer>\n  </Rule>\n</FeatureTypeStyle>\n
                                  "},{"location":"styling/sld/cookbook/lines/#details_8","title":"Details","text":"

                                  As the Alternating symbols with dash offsets example showed, the default label behavior isn't optimal. The label is displayed at a tangent to the line itself, leading to uncertainty as to which label corresponds to which line.

                                  This example is similar to the Alternating symbols with dash offsets example with the exception of lines 12-18. Line 18 sets the option to have the label follow the line, while lines 12-14 specify that the label is placed along a line. If <LinePlacement /> is not specified in an SLD, then <PointPlacement /> is assumed, which isn't compatible with line-specific rendering options.

                                  Note

                                  Not all labels are shown due to label conflict resolution. See the next section on Optimized label placement for an example of how to maximize label display.

                                  "},{"location":"styling/sld/cookbook/lines/#sld_cookbook_lines_optimizedlabel","title":"Optimized label placement","text":"

                                  This example optimizes label placement for lines such that the maximum number of labels are displayed.

                                  Note

                                  This example uses options that are specific to GeoServer and are not part of the SLD 1.0 specification.

                                  Optimized label

                                  "},{"location":"styling/sld/cookbook/lines/#code_9","title":"Code","text":"

                                  View and download the full \"Optimized label\" SLD

                                  <FeatureTypeStyle>\n  <Rule>\n    <LineSymbolizer>\n      <Stroke>\n        <CssParameter name=\"stroke\">#FF0000</CssParameter>\n      </Stroke>\n    </LineSymbolizer>\n    <TextSymbolizer>\n      <Label>\n        <ogc:PropertyName>name</ogc:PropertyName>\n      </Label>\n      <LabelPlacement>\n         <LinePlacement />\n      </LabelPlacement>\n      <Fill>\n        <CssParameter name=\"fill\">#000000</CssParameter>\n      </Fill>\n      <VendorOption name=\"followLine\">true</VendorOption>\n      <VendorOption name=\"maxAngleDelta\">90</VendorOption>\n      <VendorOption name=\"maxDisplacement\">400</VendorOption>\n      <VendorOption name=\"repeat\">150</VendorOption>\n    </TextSymbolizer>\n  </Rule>\n</FeatureTypeStyle>\n
                                  "},{"location":"styling/sld/cookbook/lines/#details_9","title":"Details","text":"

                                  GeoServer uses \"conflict resolution\" to ensure that labels aren't drawn on top of other labels, obscuring them both. This accounts for the reason why many lines don't have labels in the previous example, Label following line. While this setting can be toggled, it is usually a good idea to leave it on and use other label placement options to ensure that labels are drawn as often as desired and in the correct places. This example does just that.

                                  This example is similar to the previous example, Label following line. The only differences are contained in lines 18-21. Line 19 sets the maximum angle that the label will follow. This sets the label to never bend more than 90 degrees to prevent the label from becoming illegible due to a pronounced curve or angle. Line 20 sets the maximum displacement of the label to be 400 pixels. In order to resolve conflicts with overlapping labels, GeoServer will attempt to move the labels such that they are no longer overlapping. This value sets how far the label can be moved relative to its original placement. Finally, line 21 sets the labels to be repeated every 150 pixels. A feature will typically receive only one label, but this can cause confusion for long lines. Setting the label to repeat ensures that the line is always labeled locally.

                                  "},{"location":"styling/sld/cookbook/lines/#sld_cookbook_lines_optimizedstyledlabel","title":"Optimized and styled label","text":"

                                  This example improves the style of the labels from the Optimized label placement example.

                                  Optimized and styled label

                                  "},{"location":"styling/sld/cookbook/lines/#code_10","title":"Code","text":"

                                  View and download the full \"Optimized and styled label\" SLD

                                  <FeatureTypeStyle>\n  <Rule>\n    <LineSymbolizer>\n      <Stroke>\n        <CssParameter name=\"stroke\">#FF0000</CssParameter>\n      </Stroke>\n    </LineSymbolizer>\n    <TextSymbolizer>\n      <Label>\n        <ogc:PropertyName>name</ogc:PropertyName>\n      </Label>\n      <LabelPlacement>\n        <LinePlacement />\n      </LabelPlacement>\n      <Fill>\n        <CssParameter name=\"fill\">#000000</CssParameter>\n      </Fill>\n      <Font>\n        <CssParameter name=\"font-family\">Arial</CssParameter>\n        <CssParameter name=\"font-size\">10</CssParameter>\n        <CssParameter name=\"font-style\">normal</CssParameter>\n        <CssParameter name=\"font-weight\">bold</CssParameter>\n      </Font>\n      <VendorOption name=\"followLine\">true</VendorOption>\n      <VendorOption name=\"maxAngleDelta\">90</VendorOption>\n      <VendorOption name=\"maxDisplacement\">400</VendorOption>\n      <VendorOption name=\"repeat\">150</VendorOption>\n    </TextSymbolizer>\n  </Rule>\n</FeatureTypeStyle>\n
                                  "},{"location":"styling/sld/cookbook/lines/#details_10","title":"Details","text":"

                                  This example is similar to the Optimized label placement. The only difference is in the font information, which is contained in lines 18-23. Line 19 sets the font family to be \"Arial\", line 20 sets the font size to 10, line 21 sets the font style to \"normal\" (as opposed to \"italic\" or \"oblique\"), and line 22 sets the font weight to \"bold\" (as opposed to \"normal\").

                                  "},{"location":"styling/sld/cookbook/lines/#attribute-based-line","title":"Attribute-based line","text":"

                                  This example styles the lines differently based on the \"type\" (Road class) attribute.

                                  Attribute-based line

                                  "},{"location":"styling/sld/cookbook/lines/#code_11","title":"Code","text":"

                                  View and download the full \"Attribute-based line\" SLD

                                  <FeatureTypeStyle>\n  <Rule>\n    <Name>local-road</Name>\n    <ogc:Filter>\n      <ogc:PropertyIsEqualTo>\n        <ogc:PropertyName>type</ogc:PropertyName>\n        <ogc:Literal>local-road</ogc:Literal>\n      </ogc:PropertyIsEqualTo>\n    </ogc:Filter>\n    <LineSymbolizer>\n      <Stroke>\n        <CssParameter name=\"stroke\">#009933</CssParameter>\n        <CssParameter name=\"stroke-width\">2</CssParameter>\n      </Stroke>\n    </LineSymbolizer>\n  </Rule>\n</FeatureTypeStyle>\n<FeatureTypeStyle>\n  <Rule>\n    <Name>secondary</Name>\n    <ogc:Filter>\n      <ogc:PropertyIsEqualTo>\n        <ogc:PropertyName>type</ogc:PropertyName>\n        <ogc:Literal>secondary</ogc:Literal>\n      </ogc:PropertyIsEqualTo>\n    </ogc:Filter>\n    <LineSymbolizer>\n      <Stroke>\n        <CssParameter name=\"stroke\">#0055CC</CssParameter>\n        <CssParameter name=\"stroke-width\">3</CssParameter>\n      </Stroke>\n    </LineSymbolizer>\n  </Rule>\n</FeatureTypeStyle>\n<FeatureTypeStyle>\n  <Rule>\n  <Name>highway</Name>\n    <ogc:Filter>\n      <ogc:PropertyIsEqualTo>\n        <ogc:PropertyName>type</ogc:PropertyName>\n        <ogc:Literal>highway</ogc:Literal>\n      </ogc:PropertyIsEqualTo>\n    </ogc:Filter>\n    <LineSymbolizer>\n      <Stroke>\n        <CssParameter name=\"stroke\">#FF0000</CssParameter>\n        <CssParameter name=\"stroke-width\">6</CssParameter>\n      </Stroke>\n    </LineSymbolizer>\n  </Rule>\n</FeatureTypeStyle>\n
                                  "},{"location":"styling/sld/cookbook/lines/#details_11","title":"Details","text":"

                                  Note

                                  Refer to the Example lines layer to see the attributes for the layer. This example has eschewed labels in order to simplify the style, but you can refer to the example Optimized and styled label to see which attributes correspond to which points.

                                  There are three types of road classes in our fictional country, ranging from back roads to high-speed freeways: \"highway\", \"secondary\", and \"local-road\". In order to handle each case separately, there is more than one <FeatureTypeStyle>, each containing a single rule. This ensures that each road type is rendered in order, as each <FeatureTypeStyle> is drawn based on the order in which it appears in the SLD.

                                  The three rules are designed as follows:

                                  Rule order Rule name / type Color Size

                                  1 local-road #009933 (green) 2

                                  2 secondary #0055CC (blue) 3

                                  3 highway #FF0000 (red) 6

                                  Lines 2-16 comprise the first <Rule>. Lines 4-9 set the filter for this rule, such that the \"type\" attribute has a value of \"local-road\". If this condition is true for a particular line, the rule is rendered according to the <LineSymbolizer> which is on lines 10-15. Lines 12-13 set the color of the line to be a dark green (#009933) and the width to be 2 pixels.

                                  Lines 19-33 comprise the second <Rule>. Lines 21-26 set the filter for this rule, such that the \"type\" attribute has a value of \"secondary\". If this condition is true for a particular line, the rule is rendered according to the <LineSymbolizer> which is on lines 27-32. Lines 29-30 set the color of the line to be a dark blue (#0055CC) and the width to be 3 pixels, making the lines slightly thicker than the \"local-road\" lines and also a different color.

                                  Lines 36-50 comprise the third and final <Rule>. Lines 38-43 set the filter for this rule, such that the \"type\" attribute has a value of \"primary\". If this condition is true for a particular line, the rule is rendered according to the <LineSymbolizer> which is on lines 44-49. Lines 46-47 set the color of the line to be a bright red (#FF0000) and the width to be 6 pixels, so that these lines are rendered on top of and thicker than the other two road classes. In this way, the \"primary\" roads are given priority in the map rendering.

                                  "},{"location":"styling/sld/cookbook/lines/#zoom-based-line","title":"Zoom-based line","text":"

                                  This example alters the Simple line style at different zoom levels.

                                  Zoom-based line: Zoomed in

                                  Zoom-based line: Partially zoomed

                                  Zoom-based line: Zoomed out

                                  "},{"location":"styling/sld/cookbook/lines/#code_12","title":"Code","text":"

                                  View and download the full \"Zoom-based line\" SLD

                                  <FeatureTypeStyle>\n  <Rule>\n    <Name>Large</Name>\n    <MaxScaleDenominator>180000000</MaxScaleDenominator>\n    <LineSymbolizer>\n      <Stroke>\n        <CssParameter name=\"stroke\">#009933</CssParameter>\n        <CssParameter name=\"stroke-width\">6</CssParameter>\n      </Stroke>\n    </LineSymbolizer>\n  </Rule>\n  <Rule>\n    <Name>Medium</Name>\n    <MinScaleDenominator>180000000</MinScaleDenominator>\n    <MaxScaleDenominator>360000000</MaxScaleDenominator>\n    <LineSymbolizer>\n      <Stroke>\n        <CssParameter name=\"stroke\">#009933</CssParameter>\n        <CssParameter name=\"stroke-width\">4</CssParameter>\n      </Stroke>\n    </LineSymbolizer>\n  </Rule>\n  <Rule>\n    <Name>Small</Name>\n    <MinScaleDenominator>360000000</MinScaleDenominator>\n    <LineSymbolizer>\n      <Stroke>\n        <CssParameter name=\"stroke\">#009933</CssParameter>\n        <CssParameter name=\"stroke-width\">2</CssParameter>\n      </Stroke>\n    </LineSymbolizer>\n  </Rule>\n</FeatureTypeStyle>\n
                                  "},{"location":"styling/sld/cookbook/lines/#details_12","title":"Details","text":"

                                  It is often desirable to make shapes larger at higher zoom levels when creating a natural-looking map. This example varies the thickness of the lines according to the zoom level (or more accurately, scale denominator). Scale denominators refer to the scale of the map. A scale denominator of 10,000 means the map has a scale of 1:10,000 in the units of the map projection.

                                  Note

                                  Determining the appropriate scale denominators (zoom levels) to use is beyond the scope of this example.

                                  This style contains three rules. The three rules are designed as follows:

                                  Rule order Rule name Scale denominator Line width

                                  1 Large 1:180,000,000 or less 6

                                  2 Medium 1:180,000,000 to 1:360,000,000 4

                                  3 Small Greater than 1:360,000,000 2

                                  The order of these rules does not matter since the scales denominated in each rule do not overlap.

                                  The first rule (lines 2-11) is the smallest scale denominator, corresponding to when the view is \"zoomed in\". The scale rule is set on line 4, so that the rule will apply to any map with a scale denominator of 180,000,000 or less. Line 7-8 draws the line to be dark green (#009933) with a width of 6 pixels.

                                  The second rule (lines 12-22) is the intermediate scale denominator, corresponding to when the view is \"partially zoomed\". Lines 14-15 set the scale such that the rule will apply to any map with scale denominators between 180,000,000 and 360,000,000. (The <MinScaleDenominator> is inclusive and the <MaxScaleDenominator> is exclusive, so a zoom level of exactly 360,000,000 would not apply here.) Aside from the scale, the only difference between this rule and the previous is the width of the lines, which is set to 4 pixels on line 19.

                                  The third rule (lines 23-32) is the largest scale denominator, corresponding to when the map is \"zoomed out\". The scale rule is set on line 25, so that the rule will apply to any map with a scale denominator of 360,000,000 or greater. Again, the only other difference between this rule and the others is the width of the lines, which is set to 2 pixels on line 29.

                                  The result of this style is that lines are drawn with larger widths as one zooms in and smaller widths as one zooms out.

                                  "},{"location":"styling/sld/cookbook/points/","title":"Points","text":"

                                  While points are seemingly the simplest type of shape, possessing only position and no other dimensions, there are many different ways that a point can be styled in SLD.

                                  Warning

                                  The code examples shown on this page are not the full SLD code, as they omit the SLD header and footer information for the sake of brevity. Please use the links to download the full SLD for each example.

                                  "},{"location":"styling/sld/cookbook/points/#sld_cookbook_points_attributes","title":"Example points layer","text":"

                                  The points layer used for the examples below contains name and population information for the major cities of a fictional country. For reference, the attribute table for the points in this layer is included below.

                                  fid (Feature ID) name (City name) pop (Population)

                                  point.1 Borfin 157860

                                  point.2 Supox City 578231

                                  point.3 Ruckis 98159

                                  point.4 Thisland 34879

                                  point.5 Synopolis 24567

                                  point.6 San Glissando 76024

                                  point.7 Detrania 205609

                                  Download the points shapefile

                                  "},{"location":"styling/sld/cookbook/points/#sld_cookbook_points_simplepoint","title":"Simple point","text":"

                                  This example specifies points be styled as red circles with a diameter of 6 pixels.

                                  Simple point

                                  "},{"location":"styling/sld/cookbook/points/#code","title":"Code","text":"

                                  View and download the full \"Simple point\" SLD

                                  <FeatureTypeStyle>\n  <Rule>\n    <PointSymbolizer>\n      <Graphic>\n        <Mark>\n          <WellKnownName>circle</WellKnownName>\n          <Fill>\n            <CssParameter name=\"fill\">#FF0000</CssParameter>\n          </Fill>\n        </Mark>\n        <Size>6</Size>\n      </Graphic>\n    </PointSymbolizer>\n  </Rule>\n</FeatureTypeStyle>\n
                                  "},{"location":"styling/sld/cookbook/points/#details","title":"Details","text":"

                                  There is one <Rule> in one <FeatureTypeStyle> for this SLD, which is the simplest possible situation. (All subsequent examples will contain one <Rule> and one <FeatureTypeStyle> unless otherwise specified.) Styling points is accomplished via the <PointSymbolizer> (lines 3-13). Line 6 specifies the shape of the symbol to be a circle, with line 8 determining the fill color to be red (#FF0000). Line 11 sets the size (diameter) of the graphic to be 6 pixels.

                                  "},{"location":"styling/sld/cookbook/points/#sld_cookbook_points_simplepointwithstroke","title":"Simple point with stroke","text":"

                                  This example adds a stroke (or border) around the Simple point, with the stroke colored black and given a thickness of 2 pixels.

                                  Simple point with stroke

                                  "},{"location":"styling/sld/cookbook/points/#code_1","title":"Code","text":"

                                  View and download the full \"Simple point with stroke\" SLD

                                  <FeatureTypeStyle>\n  <Rule>\n    <PointSymbolizer>\n      <Graphic>\n        <Mark>\n          <WellKnownName>circle</WellKnownName>\n          <Fill>\n            <CssParameter name=\"fill\">#FF0000</CssParameter>\n          </Fill>\n          <Stroke>\n            <CssParameter name=\"stroke\">#000000</CssParameter>\n            <CssParameter name=\"stroke-width\">2</CssParameter>\n          </Stroke>\n        </Mark>\n        <Size>6</Size>\n      </Graphic>\n    </PointSymbolizer>\n  </Rule>\n</FeatureTypeStyle>\n
                                  "},{"location":"styling/sld/cookbook/points/#details_1","title":"Details","text":"

                                  This example is similar to the Simple point example. Lines 10-13 specify the stroke, with line 11 setting the color to black (#000000) and line 12 setting the width to 2 pixels.

                                  "},{"location":"styling/sld/cookbook/points/#rotated-square","title":"Rotated square","text":"

                                  This example creates a square instead of a circle, colors it green, sizes it to 12 pixels, and rotates it by 45 degrees.

                                  Rotated square

                                  "},{"location":"styling/sld/cookbook/points/#code_2","title":"Code","text":"

                                  View and download the full \"Rotated square\" SLD

                                  <FeatureTypeStyle>\n  <Rule>\n    <PointSymbolizer>\n      <Graphic>\n        <Mark>\n          <WellKnownName>square</WellKnownName>\n          <Fill>\n            <CssParameter name=\"fill\">#009900</CssParameter>\n          </Fill>\n        </Mark>\n        <Size>12</Size>\n        <Rotation>45</Rotation>\n      </Graphic>\n    </PointSymbolizer>\n  </Rule>\n</FeatureTypeStyle>\n
                                  "},{"location":"styling/sld/cookbook/points/#details_2","title":"Details","text":"

                                  In this example, line 6 sets the shape to be a square, with line 8 setting the color to a dark green (#009900). Line 11 sets the size of the square to be 12 pixels, and line 12 set the rotation is to 45 degrees.

                                  "},{"location":"styling/sld/cookbook/points/#transparent-triangle","title":"Transparent triangle","text":"

                                  This example draws a triangle, creates a black stroke identical to the Simple point with stroke example, and sets the fill of the triangle to 20% opacity (mostly transparent).

                                  Transparent triangle

                                  "},{"location":"styling/sld/cookbook/points/#code_3","title":"Code","text":"

                                  View and download the full \"Transparent triangle\" SLD

                                  <FeatureTypeStyle>\n  <Rule>\n    <PointSymbolizer>\n      <Graphic>\n        <Mark>\n          <WellKnownName>triangle</WellKnownName>\n          <Fill>\n            <CssParameter name=\"fill\">#009900</CssParameter>\n            <CssParameter name=\"fill-opacity\">0.2</CssParameter>\n          </Fill>\n          <Stroke>\n            <CssParameter name=\"stroke\">#000000</CssParameter>\n            <CssParameter name=\"stroke-width\">2</CssParameter>\n          </Stroke>\n        </Mark>\n        <Size>12</Size>\n      </Graphic>\n    </PointSymbolizer>\n  </Rule>\n</FeatureTypeStyle>\n
                                  "},{"location":"styling/sld/cookbook/points/#details_3","title":"Details","text":"

                                  In this example, line 6 once again sets the shape, in this case to a triangle. Line 8 sets the fill color to a dark green (#009900) and line 9 sets the opacity to 0.2 (20% opaque). An opacity value of 1 means that the shape is drawn 100% opaque, while an opacity value of 0 means that the shape is drawn 0% opaque, or completely transparent. The value of 0.2 (20% opaque) means that the fill of the points partially takes on the color and style of whatever is drawn beneath it. In this example, since the background is white, the dark green looks lighter. Were the points imposed on a dark background, the resulting color would be darker. Lines 12-13 set the stroke color to black (#000000) and width to 2 pixels. Finally, line 16 sets the size of the point to be 12 pixels in diameter.

                                  "},{"location":"styling/sld/cookbook/points/#point-as-graphic","title":"Point as graphic","text":"

                                  This example styles each point as a graphic instead of as a simple shape.

                                  Point as graphic

                                  "},{"location":"styling/sld/cookbook/points/#code_4","title":"Code","text":"

                                  View and download the full \"Point as graphic\" SLD

                                  <FeatureTypeStyle>\n  <Rule>\n    <PointSymbolizer>\n      <Graphic>\n        <ExternalGraphic>\n          <OnlineResource\n            xlink:type=\"simple\"\n            xlink:href=\"smileyface.png\" />\n          <Format>image/png</Format>\n        </ExternalGraphic>\n        <Size>32</Size>\n      </Graphic>\n    </PointSymbolizer>\n  </Rule>\n</FeatureTypeStyle>\n
                                  "},{"location":"styling/sld/cookbook/points/#details_4","title":"Details","text":"

                                  This style uses a graphic instead of a simple shape to render the points. In SLD, this is known as an <ExternalGraphic>, to distinguish it from the commonly-used shapes such as squares and circles that are \"internal\" to the renderer. Lines 5-10 specify the details of this graphic. Line 8 sets the path and file name of the graphic, while line 9 indicates the format (MIME type) of the graphic (image/png). In this example, the graphic is contained in the same directory as the SLD, so no path information is necessary in line 8, although a full URL could be used if desired. Line 11 determines the size of the displayed graphic; this can be set independently of the dimensions of the graphic itself, although in this case they are the same (32 pixels). Should a graphic be rectangular, the <Size> value will apply to the height of the graphic only, with the width scaled proportionally.

                                  Graphic used for points

                                  "},{"location":"styling/sld/cookbook/points/#sld_cookbook_points_pointwithdefaultlabel","title":"Point with default label","text":"

                                  This example shows a text label on the Simple point that displays the \"name\" attribute of the point. This is how a label will be displayed in the absence of any other customization.

                                  Point with default label

                                  "},{"location":"styling/sld/cookbook/points/#code_5","title":"Code","text":"

                                  View and download the full \"Point with default label\" SLD

                                  <FeatureTypeStyle>\n  <Rule>\n    <PointSymbolizer>\n      <Graphic>\n        <Mark>\n          <WellKnownName>circle</WellKnownName>\n          <Fill>\n            <CssParameter name=\"fill\">#FF0000</CssParameter>\n          </Fill>\n        </Mark>\n        <Size>6</Size>\n      </Graphic>\n    </PointSymbolizer>\n    <TextSymbolizer>\n      <Label>\n        <ogc:PropertyName>name</ogc:PropertyName>\n      </Label>\n      <Fill>\n        <CssParameter name=\"fill\">#000000</CssParameter>\n      </Fill>\n    </TextSymbolizer>\n  </Rule>\n</FeatureTypeStyle>\n
                                  "},{"location":"styling/sld/cookbook/points/#details_5","title":"Details","text":"

                                  Lines 3-13, which contain the <PointSymbolizer>, are identical to the Simple point example above. The label is set in the <TextSymbolizer> on lines 14-27. Lines 15-17 determine what text to display in the label, which in this case is the value of the \"name\" attribute. (Refer to the attribute table in the Example points layer section if necessary.) Line 19 sets the text color. All other details about the label are set to the renderer default, which here is Times New Roman font, font color black, and font size of 10 pixels. The bottom left of the label is aligned with the center of the point.

                                  "},{"location":"styling/sld/cookbook/points/#sld_cookbook_points_pointwithstyledlabel","title":"Point with styled label","text":"

                                  This example improves the label style from the Point with default label example by centering the label above the point and providing a different font name and size.

                                  Point with styled label

                                  "},{"location":"styling/sld/cookbook/points/#code_6","title":"Code","text":"

                                  View and download the full \"Point with styled label\" SLD

                                  <FeatureTypeStyle>\n  <Rule>\n    <PointSymbolizer>\n      <Graphic>\n        <Mark>\n          <WellKnownName>circle</WellKnownName>\n          <Fill>\n            <CssParameter name=\"fill\">#FF0000</CssParameter>\n          </Fill>\n        </Mark>\n        <Size>6</Size>\n      </Graphic>\n    </PointSymbolizer>\n    <TextSymbolizer>\n      <Label>\n        <ogc:PropertyName>name</ogc:PropertyName>\n      </Label>\n      <Font>\n        <CssParameter name=\"font-family\">Arial</CssParameter>\n        <CssParameter name=\"font-size\">12</CssParameter>\n        <CssParameter name=\"font-style\">normal</CssParameter>\n        <CssParameter name=\"font-weight\">bold</CssParameter>\n      </Font>\n      <LabelPlacement>\n        <PointPlacement>\n          <AnchorPoint>\n            <AnchorPointX>0.5</AnchorPointX>\n            <AnchorPointY>0.0</AnchorPointY>\n          </AnchorPoint>\n          <Displacement>\n            <DisplacementX>0</DisplacementX>\n            <DisplacementY>5</DisplacementY>\n          </Displacement>\n        </PointPlacement>\n      </LabelPlacement>\n      <Fill>\n        <CssParameter name=\"fill\">#000000</CssParameter>\n      </Fill>\n    </TextSymbolizer>\n  </Rule>\n</FeatureTypeStyle>\n
                                  "},{"location":"styling/sld/cookbook/points/#details_6","title":"Details","text":"

                                  In this example, lines 3-13 are identical to the Simple point example above. The <TextSymbolizer> on lines 14-39 contains many more details about the label styling than the previous example, Point with default label. Lines 15-17 once again specify the \"name\" attribute as text to display. Lines 18-23 set the font information: line 19 sets the font family to be \"Arial\", line 20 sets the font size to 12, line 21 sets the font style to \"normal\" (as opposed to \"italic\" or \"oblique\"), and line 22 sets the font weight to \"bold\" (as opposed to \"normal\"). Lines 24-35 (<LabelPlacement>) determine the placement of the label relative to the point. The <AnchorPoint> (lines 26-29) sets the point of intersection between the label and point, which here (line 27-28) sets the point to be centered (0.5) horizontally axis and bottom aligned (0.0) vertically with the label. There is also <Displacement> (lines 30-33), which sets the offset of the label relative to the line, which in this case is 0 pixels horizontally (line 31) and 5 pixels vertically (line 32). Finally, line 37 sets the font color of the label to black (#000000).

                                  The result is a centered bold label placed slightly above each point.

                                  "},{"location":"styling/sld/cookbook/points/#point-with-rotated-label","title":"Point with rotated label","text":"

                                  This example builds on the previous example, Point with styled label, by rotating the label by 45 degrees, positioning the labels farther away from the points, and changing the color of the label to purple.

                                  Point with rotated label

                                  "},{"location":"styling/sld/cookbook/points/#code_7","title":"Code","text":"

                                  View and download the full \"Point with rotated label\" SLD

                                  <FeatureTypeStyle>\n  <Rule>\n    <PointSymbolizer>\n      <Graphic>\n        <Mark>\n          <WellKnownName>circle</WellKnownName>\n          <Fill>\n            <CssParameter name=\"fill\">#FF0000</CssParameter>\n          </Fill>\n        </Mark>\n        <Size>6</Size>\n      </Graphic>\n    </PointSymbolizer>\n    <TextSymbolizer>\n      <Label>\n        <ogc:PropertyName>name</ogc:PropertyName>\n      </Label>\n      <Font>\n        <CssParameter name=\"font-family\">Arial</CssParameter>\n        <CssParameter name=\"font-size\">12</CssParameter>\n        <CssParameter name=\"font-style\">normal</CssParameter>\n        <CssParameter name=\"font-weight\">bold</CssParameter>\n      </Font>\n      <LabelPlacement>\n        <PointPlacement>\n          <AnchorPoint>\n            <AnchorPointX>0.5</AnchorPointX>\n            <AnchorPointY>0.0</AnchorPointY>\n          </AnchorPoint>\n          <Displacement>\n            <DisplacementX>0</DisplacementX>\n            <DisplacementY>25</DisplacementY>\n          </Displacement>\n          <Rotation>-45</Rotation>\n        </PointPlacement>\n      </LabelPlacement>\n      <Fill>\n        <CssParameter name=\"fill\">#990099</CssParameter>\n      </Fill>\n    </TextSymbolizer>\n  </Rule>\n</FeatureTypeStyle>\n
                                  "},{"location":"styling/sld/cookbook/points/#details_7","title":"Details","text":"

                                  This example is similar to the Point with styled label, but there are three important differences. Line 32 specifies 25 pixels of vertical displacement. Line 34 specifies a rotation of \"-45\" or 45 degrees counter-clockwise. (Rotation values increase clockwise, which is why the value is negative.) Finally, line 38 sets the font color to be a shade of purple (#99099).

                                  Note that the displacement takes effect before the rotation during rendering, so in this example, the 25 pixel vertical displacement is itself rotated 45 degrees.

                                  "},{"location":"styling/sld/cookbook/points/#attribute-based-point","title":"Attribute-based point","text":"

                                  This example alters the size of the symbol based on the value of the population (\"pop\") attribute.

                                  Attribute-based point

                                  "},{"location":"styling/sld/cookbook/points/#code_8","title":"Code","text":"

                                  View and download the full \"Attribute-based point\" SLD

                                  <FeatureTypeStyle>\n  <Rule>\n    <Name>SmallPop</Name>\n    <Title>1 to 50000</Title>\n    <ogc:Filter>\n      <ogc:PropertyIsLessThan>\n        <ogc:PropertyName>pop</ogc:PropertyName>\n        <ogc:Literal>50000</ogc:Literal>\n      </ogc:PropertyIsLessThan>\n    </ogc:Filter>\n    <PointSymbolizer>\n      <Graphic>\n        <Mark>\n          <WellKnownName>circle</WellKnownName>\n          <Fill>\n            <CssParameter name=\"fill\">#0033CC</CssParameter>\n          </Fill>\n        </Mark>\n        <Size>8</Size>\n      </Graphic>\n    </PointSymbolizer>\n  </Rule>\n  <Rule>\n    <Name>MediumPop</Name>\n    <Title>50000 to 100000</Title>\n    <ogc:Filter>\n      <ogc:And>\n        <ogc:PropertyIsGreaterThanOrEqualTo>\n          <ogc:PropertyName>pop</ogc:PropertyName>\n          <ogc:Literal>50000</ogc:Literal>\n        </ogc:PropertyIsGreaterThanOrEqualTo>\n        <ogc:PropertyIsLessThan>\n          <ogc:PropertyName>pop</ogc:PropertyName>\n          <ogc:Literal>100000</ogc:Literal>\n        </ogc:PropertyIsLessThan>\n      </ogc:And>\n    </ogc:Filter>\n    <PointSymbolizer>\n      <Graphic>\n        <Mark>\n          <WellKnownName>circle</WellKnownName>\n          <Fill>\n            <CssParameter name=\"fill\">#0033CC</CssParameter>\n          </Fill>\n        </Mark>\n        <Size>12</Size>\n      </Graphic>\n    </PointSymbolizer>\n  </Rule>\n  <Rule>\n    <Name>LargePop</Name>\n    <Title>Greater than 100000</Title>\n    <ogc:Filter>\n      <ogc:PropertyIsGreaterThanOrEqualTo>\n        <ogc:PropertyName>pop</ogc:PropertyName>\n        <ogc:Literal>100000</ogc:Literal>\n      </ogc:PropertyIsGreaterThanOrEqualTo>\n    </ogc:Filter>\n    <PointSymbolizer>\n      <Graphic>\n        <Mark>\n          <WellKnownName>circle</WellKnownName>\n          <Fill>\n            <CssParameter name=\"fill\">#0033CC</CssParameter>\n          </Fill>\n        </Mark>\n        <Size>16</Size>\n      </Graphic>\n    </PointSymbolizer>\n  </Rule>\n</FeatureTypeStyle>\n
                                  "},{"location":"styling/sld/cookbook/points/#details_8","title":"Details","text":"

                                  Note

                                  Refer to the Example points layer to see the attributes for this data. This example has eschewed labels in order to simplify the style, but you can refer to the example Point with styled label to see which attributes correspond to which points.

                                  This style contains three rules. Each <Rule> varies the style based on the value of the population (\"pop\") attribute for each point, with smaller values yielding a smaller circle, and larger values yielding a larger circle.

                                  The three rules are designed as follows:

                                  Rule order Rule name Population (\"pop\") Size

                                  1 SmallPop Less than 50,000 8

                                  2 MediumPop 50,000 to 100,000 12

                                  3 LargePop Greater than 100,000 16

                                  The order of the rules does not matter in this case, since each shape is only rendered by a single rule.

                                  The first rule, on lines 2-22, specifies the styling of those points whose population attribute is less than 50,000. Lines 5-10 set this filter, with lines 6-9 setting the \"less than\" filter, line 7 denoting the attribute (\"pop\"), and line 8 the value of 50,000. The symbol is a circle (line 14), the color is dark blue (#0033CC, on line 16), and the size is 8 pixels in diameter (line 19).

                                  The second rule, on lines 23-49, specifies a style for points whose population attribute is greater than or equal to 50,000 and less than 100,000. The population filter is set on lines 26-37. This filter is longer than in the first rule because two criteria need to be specified instead of one: a \"greater than or equal to\" and a \"less than\" filter. Notice the And on line 27 and line 36. This mandates that both filters need to be true for the rule to be applicable. The size of the graphic is set to 12 pixels on line 46. All other styling directives are identical to the first rule.

                                  The third rule, on lines 50-70, specifies a style for points whose population attribute is greater than or equal to 100,000. The population filter is set on lines 53-58, and the only other difference is the size of the circle, which in this rule (line 67) is 16 pixels.

                                  The result of this style is that cities with larger populations have larger points.

                                  "},{"location":"styling/sld/cookbook/points/#zoom-based-point","title":"Zoom-based point","text":"

                                  This example alters the style of the points at different zoom levels.

                                  Zoom-based point: Zoomed in

                                  Zoom-based point: Partially zoomed

                                  Zoom-based point: Zoomed out

                                  "},{"location":"styling/sld/cookbook/points/#code_9","title":"Code","text":"

                                  View and download the full \"Zoom-based point\" SLD

                                  <FeatureTypeStyle>\n  <Rule>\n    <Name>Large</Name>\n    <MaxScaleDenominator>160000000</MaxScaleDenominator>\n    <PointSymbolizer>\n      <Graphic>\n        <Mark>\n          <WellKnownName>circle</WellKnownName>\n          <Fill>\n            <CssParameter name=\"fill\">#CC3300</CssParameter>\n          </Fill>\n        </Mark>\n        <Size>12</Size>\n      </Graphic>\n    </PointSymbolizer>\n  </Rule>\n  <Rule>\n    <Name>Medium</Name>\n    <MinScaleDenominator>160000000</MinScaleDenominator>\n    <MaxScaleDenominator>320000000</MaxScaleDenominator>\n    <PointSymbolizer>\n      <Graphic>\n        <Mark>\n          <WellKnownName>circle</WellKnownName>\n          <Fill>\n            <CssParameter name=\"fill\">#CC3300</CssParameter>\n          </Fill>\n        </Mark>\n        <Size>8</Size>\n      </Graphic>\n    </PointSymbolizer>\n  </Rule>\n  <Rule>\n    <Name>Small</Name>\n    <MinScaleDenominator>320000000</MinScaleDenominator>\n    <PointSymbolizer>\n      <Graphic>\n        <Mark>\n          <WellKnownName>circle</WellKnownName>\n          <Fill>\n            <CssParameter name=\"fill\">#CC3300</CssParameter>\n          </Fill>\n        </Mark>\n        <Size>4</Size>\n      </Graphic>\n    </PointSymbolizer>\n  </Rule>\n</FeatureTypeStyle>\n
                                  "},{"location":"styling/sld/cookbook/points/#details_9","title":"Details","text":"

                                  It is often desirable to make shapes larger at higher zoom levels when creating a natural-looking map. This example styles the points to vary in size based on the zoom level (or more accurately, scale denominator). Scale denominators refer to the scale of the map. A scale denominator of 10,000 means the map has a scale of 1:10,000 in the units of the map projection.

                                  Note

                                  Determining the appropriate scale denominators (zoom levels) to use is beyond the scope of this example.

                                  This style contains three rules. The three rules are designed as follows:

                                  Rule order Rule name Scale denominator Point size

                                  1 Large 1:160,000,000 or less 12

                                  2 Medium 1:160,000,000 to 1:320,000,000 8

                                  3 Small Greater than 1:320,000,000 4

                                  The order of these rules does not matter since the scales denominated in each rule do not overlap.

                                  The first rule (lines 2-16) is for the smallest scale denominator, corresponding to when the view is \"zoomed in\". The scale rule is set on line 4, so that the rule will apply to any map with a scale denominator of 160,000,000 or less. The rule draws a circle (line 8), colored red (#CC3300 on line 10) with a size of 12 pixels (line 13).

                                  The second rule (lines 17-32) is the intermediate scale denominator, corresponding to when the view is \"partially zoomed\". The scale rules are set on lines 19-20, so that the rule will apply to any map with a scale denominator between 160,000,000 and 320,000,000. (The <MinScaleDenominator> is inclusive and the <MaxScaleDenominator> is exclusive, so a zoom level of exactly 320,000,000 would not apply here.) Aside from the scale, the only difference between this rule and the first is the size of the symbol, which is set to 8 pixels on line 29.

                                  The third rule (lines 33-47) is the largest scale denominator, corresponding to when the map is \"zoomed out\". The scale rule is set on line 35, so that the rule will apply to any map with a scale denominator of 320,000,000 or more. Again, the only other difference between this rule and the others is the size of the symbol, which is set to 4 pixels on line 44.

                                  The result of this style is that points are drawn larger as one zooms in and smaller as one zooms out.

                                  "},{"location":"styling/sld/cookbook/polygons/","title":"Polygons","text":"

                                  Polygons are two dimensional shapes that contain both an outer edge (or \"stroke\") and an inside (or \"fill\"). A polygon can be thought of as an irregularly-shaped point and is styled in similar ways to points.

                                  Warning

                                  The code examples shown on this page are not the full SLD code, as they omit the SLD header and footer information for the sake of brevity. Please use the links to download the full SLD for each example.

                                  "},{"location":"styling/sld/cookbook/polygons/#sld_cookbook_polygons_attributes","title":"Example polygons layer","text":"

                                  The polygons layer used below contains county information for a fictional country. For reference, the attribute table for the polygons is included below.

                                  fid (Feature ID) name (County name) pop (Population)

                                  polygon.1 Irony County 412234

                                  polygon.2 Tracker County 235421

                                  polygon.3 Dracula County 135022

                                  polygon.4 Poly County 1567879

                                  polygon.5 Bearing County 201989

                                  polygon.6 Monte Cristo County 152734

                                  polygon.7 Massive County 67123

                                  polygon.8 Rhombus County 198029

                                  Download the polygons shapefile

                                  "},{"location":"styling/sld/cookbook/polygons/#sld_cookbook_polygons_simplepolygon","title":"Simple polygon","text":"

                                  This example shows a polygon filled in blue.

                                  Simple polygon

                                  "},{"location":"styling/sld/cookbook/polygons/#code","title":"Code","text":"

                                  View and download the full \"Simple polygon\" SLD

                                  <FeatureTypeStyle>\n  <Rule>\n    <PolygonSymbolizer>\n      <Fill>\n        <CssParameter name=\"fill\">#000080</CssParameter>\n      </Fill>\n    </PolygonSymbolizer>\n  </Rule>\n</FeatureTypeStyle>\n
                                  "},{"location":"styling/sld/cookbook/polygons/#details","title":"Details","text":"

                                  There is one <Rule> in one <FeatureTypeStyle> for this style, which is the simplest possible situation. (All subsequent examples will share this characteristic unless otherwise specified.) Styling polygons is accomplished via the <PolygonSymbolizer> (lines 3-7). Line 5 specifies dark blue (#000080) as the polygon's fill color.

                                  Note

                                  The light-colored borders around the polygons in the figure are artifacts of the renderer caused by the polygons being adjacent. There is no border in this style.

                                  "},{"location":"styling/sld/cookbook/polygons/#sld_cookbook_polygons_simplepolygonwithstroke","title":"Simple polygon with stroke","text":"

                                  This example adds a 2 pixel white stroke to the Simple polygon example.

                                  Simple polygon with stroke

                                  "},{"location":"styling/sld/cookbook/polygons/#code_1","title":"Code","text":"

                                  View and download the full \"Simple polygon with stroke\" SLD

                                  <FeatureTypeStyle>\n  <Rule>\n    <PolygonSymbolizer>\n      <Fill>\n        <CssParameter name=\"fill\">#000080</CssParameter>\n      </Fill>\n      <Stroke>\n        <CssParameter name=\"stroke\">#FFFFFF</CssParameter>\n        <CssParameter name=\"stroke-width\">2</CssParameter>\n      </Stroke>\n    </PolygonSymbolizer>\n  </Rule>\n</FeatureTypeStyle>\n
                                  "},{"location":"styling/sld/cookbook/polygons/#details_1","title":"Details","text":"

                                  This example is similar to the Simple polygon example above, with the addition of the <Stroke> tag (lines 7-10). Line 8 sets the color of stroke to white (#FFFFFF) and line 9 sets the width of the stroke to 2 pixels.

                                  "},{"location":"styling/sld/cookbook/polygons/#transparent-polygon","title":"Transparent polygon","text":"

                                  This example builds on the Simple polygon with stroke example and makes the fill partially transparent by setting the opacity to 50%.

                                  Transparent polygon

                                  "},{"location":"styling/sld/cookbook/polygons/#code_2","title":"Code","text":"

                                  View and download the full \"Transparent polygon\" SLD

                                  <FeatureTypeStyle>\n  <Rule>\n    <PolygonSymbolizer>\n      <Fill>\n        <CssParameter name=\"fill\">#000080</CssParameter>\n        <CssParameter name=\"fill-opacity\">0.5</CssParameter>\n      </Fill>\n      <Stroke>\n        <CssParameter name=\"stroke\">#FFFFFF</CssParameter>\n        <CssParameter name=\"stroke-width\">2</CssParameter>\n      </Stroke>\n    </PolygonSymbolizer>\n  </Rule>\n</FeatureTypeStyle>\n
                                  "},{"location":"styling/sld/cookbook/polygons/#details_2","title":"Details","text":"

                                  This example is similar to the Simple polygon with stroke example, save for defining the fill's opacity in line 6. The value of 0.5 results in partially transparent fill that is 50% opaque. An opacity value of 1 would draw the fill as 100% opaque, while an opacity value of 0 would result in a completely transparent (0% opaque) fill. In this example, since the background is white, the dark blue looks lighter. Were the points imposed on a dark background, the resulting color would be darker.

                                  "},{"location":"styling/sld/cookbook/polygons/#sld_cookbook_polygons_offset","title":"Offset inner lines","text":"

                                  Shows how to draw inner buffer lines inside a polygon.

                                  Offset buffer

                                  "},{"location":"styling/sld/cookbook/polygons/#code_3","title":"Code","text":"

                                  View and download the full \"Inner offset lines\" SLD

                                  <FeatureTypeStyle>\n  <Rule>\n    <PolygonSymbolizer>\n      <Stroke>\n        <CssParameter name=\"stroke\">#000000</CssParameter>\n        <CssParameter name=\"stroke-width\">2</CssParameter> \n      </Stroke>\n    </PolygonSymbolizer>\n    <LineSymbolizer>\n      <Stroke>\n        <CssParameter name=\"stroke\">#AAAAAA</CssParameter>\n        <CssParameter name=\"stroke-width\">3</CssParameter>\n      </Stroke>\n      <PerpendicularOffset>-2</PerpendicularOffset>\n    </LineSymbolizer>\n  </Rule>\n</FeatureTypeStyle>\n
                                  "},{"location":"styling/sld/cookbook/polygons/#details_3","title":"Details","text":"

                                  This example is similar to the Simple polygon with stroke example, save for defining adding a <LineSymbolizer>> at line 9, where a light gray (line 11) 3 pixels wide (line 12) line is drawn as a inner buffer inside the polygon. Line 14 controls the buffering distance, setting a inner buffer of 2 pixels.

                                  "},{"location":"styling/sld/cookbook/polygons/#sld_cookbook_polygons_graphicfill","title":"Graphic fill","text":"

                                  This example fills the polygons with a tiled graphic.

                                  Graphic fill

                                  "},{"location":"styling/sld/cookbook/polygons/#code_4","title":"Code","text":"

                                  View and download the full \"Graphic fill\" SLD

                                  <FeatureTypeStyle>\n  <Rule>\n    <PolygonSymbolizer>\n      <Fill>\n        <GraphicFill>\n          <Graphic>\n            <ExternalGraphic>\n              <OnlineResource\n                xlink:type=\"simple\"\n                xlink:href=\"colorblocks.png\" />\n              <Format>image/png</Format>\n            </ExternalGraphic>\n          <Size>93</Size>\n          </Graphic>\n        </GraphicFill>\n      </Fill>\n    </PolygonSymbolizer>\n  </Rule>\n</FeatureTypeStyle>\n
                                  "},{"location":"styling/sld/cookbook/polygons/#details_4","title":"Details","text":"

                                  This style fills the polygon with a tiled graphic. This is known as an <ExternalGraphic> in SLD, to distinguish it from commonly-used shapes such as squares and circles that are \"internal\" to the renderer. Lines 7-12 specify details for the graphic, with line 10 setting the path and file name of the graphic and line 11 indicating the file format (MIME type) of the graphic (image/png). Although a full URL could be specified if desired, no path information is necessary in line 11 because this graphic is contained in the same directory as the SLD. Line 13 determines the height of the displayed graphic in pixels; if the value differs from the height of the graphic then it will be scaled accordingly while preserving the aspect ratio.

                                  Graphic used for fill

                                  "},{"location":"styling/sld/cookbook/polygons/#hatching-fill","title":"Hatching fill","text":"

                                  This example fills the polygons with a hatching pattern.

                                  Note

                                  This example leverages an SLD extension in GeoServer. Hatching is not part of the standard SLD 1.0 specification.

                                  Hatching fill

                                  "},{"location":"styling/sld/cookbook/polygons/#code_5","title":"Code","text":"

                                  View and download the full \"Hatching fill\" SLD

                                  <FeatureTypeStyle>\n  <Rule>\n    <PolygonSymbolizer>\n      <Fill>\n        <GraphicFill>\n          <Graphic>\n            <Mark>\n              <WellKnownName>shape://times</WellKnownName>\n              <Stroke>\n                <CssParameter name=\"stroke\">#990099</CssParameter>\n                <CssParameter name=\"stroke-width\">1</CssParameter>\n              </Stroke>\n            </Mark>\n            <Size>16</Size>\n          </Graphic>\n        </GraphicFill>\n      </Fill>\n    </PolygonSymbolizer>\n  </Rule>\n</FeatureTypeStyle>\n
                                  "},{"location":"styling/sld/cookbook/polygons/#details_5","title":"Details","text":"

                                  In this example, there is a <GraphicFill> tag as in the Graphic fill example, but a <Mark> (lines 7-13) is used instead of an <ExternalGraphic>. Line 8 specifies a \"times\" symbol (an \"x\") be tiled throughout the polygon. Line 10 sets the color to purple (#990099), line 11 sets the width of the hatches to 1 pixel, and line 14 sets the size of the tile to 16 pixels. Because hatch tiles are always square, the <Size> sets both the width and the height.

                                  "},{"location":"styling/sld/cookbook/polygons/#sld_cookbook_polygons_polygonwithdefaultlabel","title":"Polygon with default label","text":"

                                  This example shows a text label on the polygon. In the absence of any other customization, this is how a label will be displayed.

                                  Polygon with default label

                                  "},{"location":"styling/sld/cookbook/polygons/#code_6","title":"Code","text":"

                                  View and download the full \"Polygon with default label\" SLD

                                  <FeatureTypeStyle>\n  <Rule>\n    <PolygonSymbolizer>\n      <Fill>\n        <CssParameter name=\"fill\">#40FF40</CssParameter>\n      </Fill>\n      <Stroke>\n        <CssParameter name=\"stroke\">#FFFFFF</CssParameter>\n        <CssParameter name=\"stroke-width\">2</CssParameter>\n      </Stroke>\n    </PolygonSymbolizer>        \n    <TextSymbolizer>\n      <Label>\n        <ogc:PropertyName>name</ogc:PropertyName>\n      </Label>            \n    </TextSymbolizer>\n  </Rule>\n</FeatureTypeStyle>\n
                                  "},{"location":"styling/sld/cookbook/polygons/#details_6","title":"Details","text":"

                                  In this example there is a <PolygonSymbolizer> and a <TextSymbolizer>. Lines 3-11 comprise the <PolygonSymbolizer>. The fill of the polygon is set on line 5 to a light green (#40FF40) while the stroke of the polygon is set on lines 8-9 to white (#FFFFFF) with a thickness of 2 pixels. The label is set in the <TextSymbolizer> on lines 12-16, with line 14 determining what text to display, in this case the value of the \"name\" attribute. (Refer to the attribute table in the Example polygons layer section if necessary.) All other details about the label are set to the renderer default, which here is Times New Roman font, font color black, and font size of 10 pixels.

                                  "},{"location":"styling/sld/cookbook/polygons/#label-halo","title":"Label halo","text":"

                                  This example alters the look of the Polygon with default label by adding a white halo to the label.

                                  Label halo

                                  "},{"location":"styling/sld/cookbook/polygons/#code_7","title":"Code","text":"

                                  View and download the full \"Label halo\" SLD

                                  <FeatureTypeStyle>\n  <Rule>\n    <PolygonSymbolizer>\n      <Fill>\n        <CssParameter name=\"fill\">#40FF40</CssParameter>\n      </Fill>\n      <Stroke>\n        <CssParameter name=\"stroke\">#FFFFFF</CssParameter>\n        <CssParameter name=\"stroke-width\">2</CssParameter>\n      </Stroke>\n    </PolygonSymbolizer>        \n    <TextSymbolizer>\n      <Label>\n        <ogc:PropertyName>name</ogc:PropertyName>\n      </Label>\n      <Halo>\n        <Radius>3</Radius>\n        <Fill>\n          <CssParameter name=\"fill\">#FFFFFF</CssParameter>\n        </Fill>\n      </Halo>\n    </TextSymbolizer>\n  </Rule>\n</FeatureTypeStyle>\n
                                  "},{"location":"styling/sld/cookbook/polygons/#details_7","title":"Details","text":"

                                  This example is similar to the Polygon with default label, with the addition of a halo around the labels on lines 16-21. A halo creates a color buffer around the label to improve label legibility. Line 17 sets the radius of the halo, extending the halo 3 pixels around the edge of the label, and line 19 sets the color of the halo to white (#FFFFFF). Since halos are most useful when set to a sharp contrast relative to the text color, this example uses a white halo around black text to ensure optimum readability.

                                  "},{"location":"styling/sld/cookbook/polygons/#sld_cookbook_polygons_polygonwithstyledlabel","title":"Polygon with styled label","text":"

                                  This example improves the label style from the Polygon with default label example by centering the label on the polygon, specifying a different font name and size, and setting additional label placement optimizations.

                                  Note

                                  The label placement optimizations discussed below (the <VendorOption> tags) are SLD extensions that are custom to GeoServer. They are not part of the SLD 1.0 specification.

                                  Polygon with styled label

                                  "},{"location":"styling/sld/cookbook/polygons/#code_8","title":"Code","text":"

                                  View and download the full \"Polygon with styled label\" SLD

                                  <FeatureTypeStyle>\n  <Rule>\n    <PolygonSymbolizer>\n      <Fill>\n        <CssParameter name=\"fill\">#40FF40</CssParameter>\n      </Fill>\n      <Stroke>\n        <CssParameter name=\"stroke\">#FFFFFF</CssParameter>\n        <CssParameter name=\"stroke-width\">2</CssParameter>\n      </Stroke>\n    </PolygonSymbolizer>        \n    <TextSymbolizer>\n      <Label>\n        <ogc:PropertyName>name</ogc:PropertyName>\n      </Label>\n      <Font>\n        <CssParameter name=\"font-family\">Arial</CssParameter>\n        <CssParameter name=\"font-size\">11</CssParameter>\n        <CssParameter name=\"font-style\">normal</CssParameter>\n        <CssParameter name=\"font-weight\">bold</CssParameter>\n      </Font>\n      <LabelPlacement>\n        <PointPlacement>\n          <AnchorPoint>\n            <AnchorPointX>0.5</AnchorPointX>\n            <AnchorPointY>0.5</AnchorPointY>\n          </AnchorPoint>\n        </PointPlacement>\n      </LabelPlacement>\n      <Fill>\n        <CssParameter name=\"fill\">#000000</CssParameter>\n      </Fill>\n      <VendorOption name=\"autoWrap\">60</VendorOption>\n      <VendorOption name=\"maxDisplacement\">150</VendorOption>\n    </TextSymbolizer>\n  </Rule>\n</FeatureTypeStyle>\n
                                  "},{"location":"styling/sld/cookbook/polygons/#details_8","title":"Details","text":"

                                  This example is similar to the Polygon with default label example, with additional styling options within the <TextSymbolizer> on lines 12-35. Lines 16-21 set the font styling. Line 17 sets the font family to be Arial, line 18 sets the font size to 11 pixels, line 19 sets the font style to \"normal\" (as opposed to \"italic\" or \"oblique\"), and line 20 sets the font weight to \"bold\" (as opposed to \"normal\").

                                  The <LabelPlacement> tag on lines 22-29 affects where the label is placed relative to the centroid of the polygon. Line 21 centers the label by positioning it 50% (or 0.5) of the way horizontally along the centroid of the polygon. Line 22 centers the label vertically in exactly the same way.

                                  Finally, there are two added touches for label placement optimization: line 33 ensures that long labels are split across multiple lines by setting line wrapping on the labels to 60 pixels, and line 34 allows the label to be displaced by up to 150 pixels. This ensures that labels are compacted and less likely to spill over polygon boundaries. Notice little Massive County in the corner, whose label is now displayed.\"

                                  "},{"location":"styling/sld/cookbook/polygons/#attribute-based-polygon","title":"Attribute-based polygon","text":"

                                  This example styles the polygons differently based on the \"pop\" (Population) attribute.

                                  Attribute-based polygon

                                  "},{"location":"styling/sld/cookbook/polygons/#code_9","title":"Code","text":"

                                  View and download the full \"Attribute-based polygon\" SLD

                                  <FeatureTypeStyle>\n  <Rule>\n    <Name>SmallPop</Name>\n    <Title>Less Than 200,000</Title>\n    <ogc:Filter>\n      <ogc:PropertyIsLessThan>\n        <ogc:PropertyName>pop</ogc:PropertyName>\n        <ogc:Literal>200000</ogc:Literal>\n      </ogc:PropertyIsLessThan>\n    </ogc:Filter>\n    <PolygonSymbolizer>\n      <Fill>\n        <CssParameter name=\"fill\">#66FF66</CssParameter>\n      </Fill>\n    </PolygonSymbolizer>\n  </Rule>\n  <Rule>\n    <Name>MediumPop</Name>\n    <Title>200,000 to 500,000</Title>\n    <ogc:Filter>\n      <ogc:And>\n        <ogc:PropertyIsGreaterThanOrEqualTo>\n          <ogc:PropertyName>pop</ogc:PropertyName>\n          <ogc:Literal>200000</ogc:Literal>\n        </ogc:PropertyIsGreaterThanOrEqualTo>\n        <ogc:PropertyIsLessThan>\n          <ogc:PropertyName>pop</ogc:PropertyName>\n          <ogc:Literal>500000</ogc:Literal>\n        </ogc:PropertyIsLessThan>\n      </ogc:And>\n    </ogc:Filter>\n    <PolygonSymbolizer>\n      <Fill>\n        <CssParameter name=\"fill\">#33CC33</CssParameter>\n      </Fill>\n    </PolygonSymbolizer>\n  </Rule>\n  <Rule>\n    <Name>LargePop</Name>\n    <Title>Greater Than 500,000</Title>\n    <ogc:Filter>\n      <ogc:PropertyIsGreaterThan>\n        <ogc:PropertyName>pop</ogc:PropertyName>\n        <ogc:Literal>500000</ogc:Literal>\n      </ogc:PropertyIsGreaterThan>\n    </ogc:Filter>\n    <PolygonSymbolizer>\n      <Fill>\n        <CssParameter name=\"fill\">#009900</CssParameter>\n      </Fill>\n    </PolygonSymbolizer>\n  </Rule>\n</FeatureTypeStyle>\n
                                  "},{"location":"styling/sld/cookbook/polygons/#details_9","title":"Details","text":"

                                  Note

                                  Refer to the Example polygons layer to see the attributes for the layer. This example has eschewed labels in order to simplify the style, but you can refer to the example Polygon with styled label to see which attributes correspond to which polygons.

                                  Each polygon in our fictional country has a population that is represented by the population (\"pop\") attribute. This style contains three rules that alter the fill based on the value of \"pop\" attribute, with smaller values yielding a lighter color and larger values yielding a darker color.

                                  The three rules are designed as follows:

                                  Rule order Rule name Population (\"pop\") Color

                                  1 SmallPop Less than 200,000 #66FF66

                                  2 MediumPop 200,000 to 500,000 #33CC33

                                  3 LargePop Greater than 500,000 #009900

                                  The order of the rules does not matter in this case, since each shape is only rendered by a single rule.

                                  The first rule, on lines 2-16, specifies the styling of polygons whose population attribute is less than 200,000. Lines 5-10 set this filter, with lines 6-9 setting the \"less than\" filter, line 7 denoting the attribute (\"pop\"), and line 8 the value of 200,000. The color of the polygon fill is set to a light green (#66FF66) on line 13.

                                  The second rule, on lines 17-37, is similar, specifying a style for polygons whose population attribute is greater than or equal to 200,000 but less than 500,000. The filter is set on lines 20-31. This filter is longer than in the first rule because two criteria need to be specified instead of one: a \"greater than or equal to\" and a \"less than\" filter. Notice the And on line 21 and line 30. This mandates that both filters need to be true for the rule to be applicable. The color of the polygon fill is set to a medium green on (#33CC33) on line 34.

                                  The third rule, on lines 38-52, specifies a style for polygons whose population attribute is greater than or equal to 500,000. The filter is set on lines 41-46. The color of the polygon fill is the only other difference in this rule, which is set to a dark green (#009900) on line 49.

                                  "},{"location":"styling/sld/cookbook/polygons/#zoom-based-polygon","title":"Zoom-based polygon","text":"

                                  This example alters the style of the polygon at different zoom levels.

                                  Zoom-based polygon: Zoomed in

                                  Zoom-based polygon: Partially zoomed

                                  Zoom-based polygon: Zoomed out

                                  "},{"location":"styling/sld/cookbook/polygons/#code_10","title":"Code","text":"

                                  View and download the full \"Zoom-based polygon\" SLD

                                  <FeatureTypeStyle>\n  <Rule>\n    <Name>Large</Name>\n    <MaxScaleDenominator>100000000</MaxScaleDenominator>\n    <PolygonSymbolizer>\n      <Fill>\n        <CssParameter name=\"fill\">#0000CC</CssParameter>\n      </Fill>\n      <Stroke>\n        <CssParameter name=\"stroke\">#000000</CssParameter>\n        <CssParameter name=\"stroke-width\">7</CssParameter>\n      </Stroke>\n    </PolygonSymbolizer>\n    <TextSymbolizer>\n      <Label>\n        <ogc:PropertyName>name</ogc:PropertyName>\n      </Label>  \n      <Font>\n        <CssParameter name=\"font-family\">Arial</CssParameter>\n        <CssParameter name=\"font-size\">14</CssParameter>\n        <CssParameter name=\"font-style\">normal</CssParameter>\n        <CssParameter name=\"font-weight\">bold</CssParameter>\n      </Font>\n      <LabelPlacement>\n        <PointPlacement>\n          <AnchorPoint>\n            <AnchorPointX>0.5</AnchorPointX>\n            <AnchorPointY>0.5</AnchorPointY>\n          </AnchorPoint>\n        </PointPlacement>\n      </LabelPlacement>\n      <Fill>\n        <CssParameter name=\"fill\">#FFFFFF</CssParameter>\n      </Fill>\n    </TextSymbolizer>\n  </Rule>\n  <Rule>\n    <Name>Medium</Name>\n    <MinScaleDenominator>100000000</MinScaleDenominator>\n    <MaxScaleDenominator>200000000</MaxScaleDenominator>\n    <PolygonSymbolizer>\n      <Fill>\n        <CssParameter name=\"fill\">#0000CC</CssParameter>\n      </Fill>\n      <Stroke>\n        <CssParameter name=\"stroke\">#000000</CssParameter>\n        <CssParameter name=\"stroke-width\">4</CssParameter>\n      </Stroke>\n    </PolygonSymbolizer>\n  </Rule>\n  <Rule>\n    <Name>Small</Name>\n    <MinScaleDenominator>200000000</MinScaleDenominator>\n    <PolygonSymbolizer>\n      <Fill>\n        <CssParameter name=\"fill\">#0000CC</CssParameter>\n      </Fill>\n      <Stroke>\n        <CssParameter name=\"stroke\">#000000</CssParameter>\n        <CssParameter name=\"stroke-width\">1</CssParameter>\n      </Stroke>\n    </PolygonSymbolizer>\n  </Rule>\n</FeatureTypeStyle>\n
                                  "},{"location":"styling/sld/cookbook/polygons/#details_10","title":"Details","text":"

                                  It is often desirable to make shapes larger at higher zoom levels when creating a natural-looking map. This example varies the thickness of the lines according to the zoom level. Polygons already do this by nature of being two dimensional, but another way to adjust styling of polygons based on zoom level is to adjust the thickness of the stroke (to be larger as the map is zoomed in) or to limit labels to only certain zoom levels. This is ensures that the size and quantity of strokes and labels remains legible and doesn't overshadow the polygons themselves.

                                  Zoom levels (or more accurately, scale denominators) refer to the scale of the map. A scale denominator of 10,000 means the map has a scale of 1:10,000 in the units of the map projection.

                                  Note

                                  Determining the appropriate scale denominators (zoom levels) to use is beyond the scope of this example.

                                  This style contains three rules, defined as follows:

                                  Rule order Rule name Scale denominator Stroke width Label display?

                                  1 Large 1:100,000,000 or less 7 Yes

                                  2 Medium 1:100,000,000 to 1:200,000,000 4 No

                                  3 Small Greater than 1:200,000,000 2 No

                                  The first rule, on lines 2-36, is for the smallest scale denominator, corresponding to when the view is \"zoomed in\". The scale rule is set on line 40 such that the rule will apply only where the scale denominator is 100,000,000 or less. Line 7 defines the fill as blue (#0000CC). Note that the fill is kept constant across all rules regardless of the scale denominator. As in the Polygon with default label or Polygon with styled label examples, the rule also contains a <TextSymbolizer> at lines 14-35 for drawing a text label on top of the polygon. Lines 19-22 set the font information to be Arial, 14 pixels, and bold with no italics. The label is centered both horizontally and vertically along the centroid of the polygon on by setting <AnchorPointX> and <AnchorPointY> to both be 0.5 (or 50%) on lines 27-28. Finally, the color of the font is set to white (#FFFFFF) in line 33.

                                  The second rule, on lines 37-50, is for the intermediate scale denominators, corresponding to when the view is \"partially zoomed\". The scale rules on lines 39-40 set the rule such that it will apply to any map with a scale denominator between 100,000,000 and 200,000,000. (The <MinScaleDenominator> is inclusive and the <MaxScaleDenominator> is exclusive, so a zoom level of exactly 200,000,000 would not apply here.) Aside from the scale, there are two differences between this rule and the first: the width of the stroke is set to 4 pixels on line 47 and a <TextSymbolizer> is not present so that no labels will be displayed.

                                  The third rule, on lines 51-63, is for the largest scale denominator, corresponding to when the map is \"zoomed out\". The scale rule is set on line 53 such that the rule will apply to any map with a scale denominator of 200,000,000 or greater. Again, the only differences between this rule and the others are the width of the lines, which is set to 1 pixel on line 60, and the absence of a <TextSymbolizer> so that no labels will be displayed.

                                  The resulting style produces a polygon stroke that gets larger as one zooms in and labels that only display when zoomed in to a sufficient level.

                                  "},{"location":"styling/sld/cookbook/rasters/","title":"Rasters","text":"

                                  Rasters are geographic data displayed in a grid. They are similar to image files such as PNG files, except that instead of each point containing visual information, each point contains geographic information in numerical form. Rasters can be thought of as a georeferenced table of numerical values.

                                  One example of a raster is a Digital Elevation Model (DEM) layer, which has elevation data encoded numerically at each georeferenced data point.

                                  Warning

                                  The code examples shown on this page are not the full SLD code, as they omit the SLD header and footer information for the sake of brevity. Please use the links to download the full SLD for each example.

                                  "},{"location":"styling/sld/cookbook/rasters/#example-raster","title":"Example raster","text":"

                                  The raster layer that is used in the examples below contains elevation data for a fictional world. The data is stored in EPSG:4326 (longitude/latitude) and has a data range from 70 to 256. If rendered in grayscale, where minimum values are colored black and maximum values are colored white, the raster would look like this:

                                  Raster file as rendered in grayscale

                                  Download the raster shapefile

                                  "},{"location":"styling/sld/cookbook/rasters/#sld_cookbook_raster_twocolorgradient","title":"Two-color gradient","text":"

                                  This example shows a two-color style with green at lower elevations and brown at higher elevations.

                                  Two-color gradient

                                  "},{"location":"styling/sld/cookbook/rasters/#code","title":"Code","text":"

                                  View and download the full \"Two-color gradient\" SLD

                                  <FeatureTypeStyle>\n  <Rule>\n    <RasterSymbolizer>\n      <ColorMap>\n        <ColorMapEntry color=\"#008000\" quantity=\"70\" />\n        <ColorMapEntry color=\"#663333\" quantity=\"256\" />\n      </ColorMap>\n    </RasterSymbolizer>\n  </Rule>\n</FeatureTypeStyle>\n
                                  "},{"location":"styling/sld/cookbook/rasters/#details","title":"Details","text":"

                                  There is one <Rule> in one <FeatureTypeStyle> for this example, which is the simplest possible situation. All subsequent examples will share this characteristic. Styling of rasters is done via the <RasterSymbolizer> tag (lines 3-8).

                                  This example creates a smooth gradient between two colors corresponding to two elevation values. The gradient is created via the <ColorMap> on lines 4-7. Each entry in the <ColorMap> represents one entry or anchor in the gradient. Line 5 sets the lower value of 70 via the quantity parameter, which is styled a dark green (#008000). Line 6 sets the upper value of 256 via the quantity parameter again, which is styled a dark brown (#663333). All data values in between these two quantities will be linearly interpolated: a value of 163 (the midpoint between 70 and 256) will be colored as the midpoint between the two colors (in this case approximately #335717, a muddy green).

                                  "},{"location":"styling/sld/cookbook/rasters/#transparent-gradient","title":"Transparent gradient","text":"

                                  This example creates the same two-color gradient as in the Two-color gradient as in the example above but makes the entire layer mostly transparent by setting a 30% opacity.

                                  Transparent gradient

                                  "},{"location":"styling/sld/cookbook/rasters/#code_1","title":"Code","text":"

                                  View and download the full \"Transparent gradient\" SLD

                                  <FeatureTypeStyle>\n  <Rule>\n    <RasterSymbolizer>\n      <Opacity>0.3</Opacity>\n      <ColorMap>\n        <ColorMapEntry color=\"#008000\" quantity=\"70\" />\n        <ColorMapEntry color=\"#663333\" quantity=\"256\" />\n      </ColorMap>\n    </RasterSymbolizer>\n  </Rule>\n</FeatureTypeStyle>\n
                                  "},{"location":"styling/sld/cookbook/rasters/#details_1","title":"Details","text":"

                                  This example is similar to the Two-color gradient example save for the addition of line 4, which sets the opacity of the layer to 0.3 (or 30% opaque). An opacity value of 1 means that the shape is drawn 100% opaque, while an opacity value of 0 means that the shape is rendered as completely transparent. The value of 0.3 means that the raster partially takes on the color and style of whatever is drawn beneath it. Since the background is white in this example, the colors generated from the <ColorMap> look lighter, but were the raster imposed on a dark background the resulting colors would be darker.

                                  "},{"location":"styling/sld/cookbook/rasters/#brightness-and-contrast","title":"Brightness and contrast","text":"

                                  This example normalizes the color output and then increases the brightness by a factor of 2.

                                  Brightness and contrast

                                  "},{"location":"styling/sld/cookbook/rasters/#code_2","title":"Code","text":"

                                  View and download the full \"Brightness and contrast\" SLD

                                  <FeatureTypeStyle>\n  <Rule>\n    <RasterSymbolizer>\n      <ContrastEnhancement>\n        <Normalize />\n        <GammaValue>0.5</GammaValue>\n      </ContrastEnhancement>\n      <ColorMap>\n        <ColorMapEntry color=\"#008000\" quantity=\"70\" />\n        <ColorMapEntry color=\"#663333\" quantity=\"256\" />\n      </ColorMap>\n    </RasterSymbolizer>\n  </Rule>\n</FeatureTypeStyle>\n
                                  "},{"location":"styling/sld/cookbook/rasters/#details_2","title":"Details","text":"

                                  This example is similar to the Two-color gradient, save for the addition of the <ContrastEnhancement> tag on lines 4-7. Line 5 normalizes the output by increasing the contrast to its maximum extent. Line 6 then adjusts the brightness by a factor of 0.5. Since values less than 1 make the output brighter, a value of 0.5 makes the output twice as bright.

                                  As with previous examples, lines 8-11 determine the <ColorMap>, with line 9 setting the lower bound (70) to be colored dark green (#008000) and line 10 setting the upper bound (256) to be colored dark brown (#663333).

                                  "},{"location":"styling/sld/cookbook/rasters/#three-color-gradient","title":"Three-color gradient","text":"

                                  This example creates a three-color gradient in primary colors.

                                  Three-color gradient

                                  "},{"location":"styling/sld/cookbook/rasters/#code_3","title":"Code","text":"

                                  View and download the full \"Three-color gradient\" SLD

                                  <FeatureTypeStyle>\n  <Rule>\n    <RasterSymbolizer>\n      <ColorMap>\n        <ColorMapEntry color=\"#0000FF\" quantity=\"150\" />\n        <ColorMapEntry color=\"#FFFF00\" quantity=\"200\" />\n        <ColorMapEntry color=\"#FF0000\" quantity=\"250\" />\n      </ColorMap>\n    </RasterSymbolizer>\n  </Rule>\n</FeatureTypeStyle>\n
                                  "},{"location":"styling/sld/cookbook/rasters/#details_3","title":"Details","text":"

                                  This example creates a three-color gradient based on a <ColorMap> with three entries on lines 4-8: line 5 specifies the lower bound (150) be styled in blue (#0000FF), line 6 specifies an intermediate point (200) be styled in yellow (#FFFF00), and line 7 specifies the upper bound (250) be styled in red (#FF0000).

                                  Since our data values run between 70 and 256, some data points are not accounted for in this style. Those values below the lowest entry in the color map (the range from 70 to 149) are styled the same color as the lower bound, in this case blue. Values above the upper bound in the color map (the range from 251 to 256) are styled the same color as the upper bound, in this case red.

                                  "},{"location":"styling/sld/cookbook/rasters/#alpha-channel","title":"Alpha channel","text":"

                                  This example creates an \"alpha channel\" effect such that higher values are increasingly transparent.

                                  Alpha channel

                                  "},{"location":"styling/sld/cookbook/rasters/#code_4","title":"Code","text":"

                                  View and download the full \"Alpha channel\" SLD

                                  <FeatureTypeStyle>\n  <Rule>\n    <RasterSymbolizer>\n      <ColorMap>\n        <ColorMapEntry color=\"#008000\" quantity=\"70\" />\n        <ColorMapEntry color=\"#008000\" quantity=\"256\" opacity=\"0\"/>\n      </ColorMap>\n    </RasterSymbolizer>\n  </Rule>\n</FeatureTypeStyle>\n
                                  "},{"location":"styling/sld/cookbook/rasters/#details_4","title":"Details","text":"

                                  An alpha channel is another way of referring to variable transparency. Much like how a gradient maps values to colors, each entry in a <ColorMap> can have a value for opacity (with the default being 1.0 or completely opaque).

                                  In this example, there is a <ColorMap> with two entries: line 5 specifies the lower bound of 70 be colored dark green (#008000), while line 6 specifies the upper bound of 256 also be colored dark green but with an opacity value of 0. This means that values of 256 will be rendered at 0% opacity (entirely transparent). Just like the gradient color, the opacity is also linearly interpolated such that a value of 163 (the midpoint between 70 and 256) is rendered at 50% opacity.

                                  "},{"location":"styling/sld/cookbook/rasters/#discrete-colors","title":"Discrete colors","text":"

                                  This example shows a gradient that is not linearly interpolated but instead has values mapped precisely to one of three specific colors.

                                  Note

                                  This example leverages an SLD extension in GeoServer. Discrete colors are not part of the standard SLD 1.0 specification.

                                  Discrete colors

                                  "},{"location":"styling/sld/cookbook/rasters/#code_5","title":"Code","text":"

                                  View and download the full \"Discrete colors\" SLD

                                  <FeatureTypeStyle>\n  <Rule>\n    <RasterSymbolizer>\n      <ColorMap type=\"intervals\">\n        <ColorMapEntry color=\"#008000\" quantity=\"150\" />\n        <ColorMapEntry color=\"#663333\" quantity=\"256\" />\n      </ColorMap>\n    </RasterSymbolizer>\n  </Rule>\n</FeatureTypeStyle>\n
                                  "},{"location":"styling/sld/cookbook/rasters/#details_5","title":"Details","text":"

                                  Sometimes color bands in discrete steps are more appropriate than a color gradient. The type=\"intervals\" parameter added to the <ColorMap> on line 4 sets the display to output discrete colors instead of a gradient. The values in each entry correspond to the upper bound for the color band such that colors are mapped to values less than the value of one entry but greater than or equal to the next lower entry. For example, line 5 colors all values less than 150 to dark green (#008000) and line 6 colors all values less than 256 but greater than or equal to 150 to dark brown (#663333).

                                  "},{"location":"styling/sld/cookbook/rasters/#many-color-gradient","title":"Many color gradient","text":"

                                  This example shows a gradient interpolated across eight different colors.

                                  Many color gradient

                                  "},{"location":"styling/sld/cookbook/rasters/#code_6","title":"Code","text":"

                                  View and download the full \"Many color gradient\" SLD

                                  <FeatureTypeStyle>\n  <Rule>\n    <RasterSymbolizer>\n      <ColorMap>\n        <ColorMapEntry color=\"#000000\" quantity=\"95\" />\n        <ColorMapEntry color=\"#0000FF\" quantity=\"110\" />\n        <ColorMapEntry color=\"#00FF00\" quantity=\"135\" />\n        <ColorMapEntry color=\"#FF0000\" quantity=\"160\" />\n        <ColorMapEntry color=\"#FF00FF\" quantity=\"185\" />\n        <ColorMapEntry color=\"#FFFF00\" quantity=\"210\" />\n        <ColorMapEntry color=\"#00FFFF\" quantity=\"235\" />\n        <ColorMapEntry color=\"#FFFFFF\" quantity=\"256\" />\n      </ColorMap>\n    </RasterSymbolizer>\n  </Rule>\n</FeatureTypeStyle>\n
                                  "},{"location":"styling/sld/cookbook/rasters/#details_6","title":"Details","text":"

                                  A <ColorMap> can include up to 255 <ColorMapEntry> elements. This example has eight entries (lines 4-13):

                                  Entry number Value Color RGB code

                                  1 95 Black #000000

                                  2 110 Blue #0000FF

                                  3 135 Green #00FF00

                                  4 160 Red #FF0000

                                  5 185 Purple #FF00FF

                                  6 210 Yellow #FFFF00

                                  7 235 Cyan #00FFFF

                                  8 256 White #FFFFFF

                                  "},{"location":"styling/sld/extensions/","title":"SLD Extensions in GeoServer","text":"

                                  GeoServer provides a number of vendor-specific extensions to SLD 1.0. Although not portable to other applications, these extensions make styling more powerful and concise and allow for the generation of better-looking maps.

                                  • Geometry transformations in SLD
                                  • Rendering Transformations
                                  • Graphic symbology in GeoServer
                                  • Variable substitution in SLD
                                  • Specifying symbolizer sizes in ground units
                                  • Label Obstacles
                                  • Adding space around graphic fills
                                  • Fills with randomized symbols
                                  • Color compositing and color blending
                                  • Z ordering features within and across feature types and layers
                                  • Rendering Selection
                                  "},{"location":"styling/sld/extensions/geometry-transformations/","title":"Geometry transformations in SLD","text":"

                                  SLD symbolizers may contain an optional <Geometry> element, which allows specifying which geometry attribute is to be rendered. In the common case of a featuretype with a single geometry attribute this element is usually omitted, but it is useful when a featuretype has multiple geometry-valued attributes.

                                  SLD 1.0 requires the <Geometry> content to be a <ogc:PropertyName>. GeoServer extends this to allow a general SLD expression to be used. The expression can contain filter functions that manipulate geometries by transforming them into something different. This facility is called SLD geometry transformations.

                                  GeoServer provides a number of filter functions that can transform geometry. A full list is available in the Filter Function Reference. They can be used to do things such as extracting line vertices or endpoints, offsetting polygons, or buffering geometries.

                                  Geometry transformations are computed in the geometry's original coordinate reference system, before any reprojection and rescaling to the output map is performed. For this reason, transformation parameters must be expressed in the units of the geometry CRS. This must be taken into account when using geometry transformations at different screen scales, since the parameters will not change with scale.

                                  "},{"location":"styling/sld/extensions/geometry-transformations/#examples","title":"Examples","text":"

                                  Let's look at some examples.

                                  "},{"location":"styling/sld/extensions/geometry-transformations/#extracting-vertices","title":"Extracting vertices","text":"

                                  Here is an example that allows one to extract all the vertices of a geometry, and make them visible in a map, using the vertices function:

                                  <PointSymbolizer>\n  <Geometry>\n    <ogc:Function name=\"vertices\">\n       <ogc:PropertyName>the_geom</ogc:PropertyName>\n    </ogc:Function>\n  </Geometry>\n  <Graphic>\n    <Mark>\n      <WellKnownName>square</WellKnownName>\n      <Fill>\n        <CssParameter name=\"fill\">#FF0000</CssParameter>\n      </Fill>\n    </Mark>\n    <Size>6</Size>\n  </Graphic>\n</PointSymbolizer>\n

                                  View the full \"Vertices\" SLD

                                  Applied to the sample tasmania_roads layer this will result in:

                                  Extracting and showing the vertices out of a geometry

                                  "},{"location":"styling/sld/extensions/geometry-transformations/#start-and-end-point","title":"Start and end point","text":"

                                  The startPoint and endPoint functions can be used to extract the start and end point of a line.

                                  ``` {.xml linenos=\" the_geom square 0x00FF00 1.5 8 the_geom circle 0xFF0000 4 \"}

                                  [View the full \"StartEnd\" SLD](artifacts/startend.sld)\n\nApplied to the sample ``tasmania_roads`` layer this will result in:\n\n![](images/startend.png)\n*Extracting start and end point of a line*\n\n### Drop shadow\n\nThe ``offset`` function can be used to create drop shadow effects below polygons. Notice that the offset values reflect the fact that the data used in the example is in a geographic coordinate system.\n\n``` {.xml linenos=\"\"}\n<PolygonSymbolizer>\n  <Geometry>\n     <ogc:Function name=\"offset\">\n        <ogc:PropertyName>the_geom</ogc:PropertyName>\n        <ogc:Literal>0.00004</ogc:Literal>\n        <ogc:Literal>-0.00004</ogc:Literal>\n     </ogc:Function>\n  </Geometry>\n  <Fill>\n    <CssParameter name=\"fill\">#555555</CssParameter>\n  </Fill>\n</PolygonSymbolizer>\n

                                  View the full \"Shadow\" SLD

                                  Applied to the sample tasmania_roads layer this will result in:

                                  Dropping building shadows

                                  "},{"location":"styling/sld/extensions/geometry-transformations/#performance-tips","title":"Performance tips","text":"

                                  GeoServer's filter functions contain a number of set-related or constructive geometric functions, such as buffer, intersection, difference and others. These can be used as geometry transformations, but they be can quite heavy in terms of CPU consumption so it is advisable to use them with care. One strategy is to activate them only at higher zoom levels, so that fewer features are processed.

                                  Buffering can often be visually approximated by using very large strokes together with round line joins and line caps. This avoids incurring the performance cost of a true geometric buffer transformation.

                                  "},{"location":"styling/sld/extensions/geometry-transformations/#adding-new-transformations","title":"Adding new transformations","text":"

                                  Additional filter functions can be developed in Java and then deployed in a JAR file as a GeoServer plugin. A guide is not available at this time, but see the GeoTools main module for examples.

                                  "},{"location":"styling/sld/extensions/label-obstacles/","title":"Label Obstacles","text":"

                                  GeoServer implements an algorithm for label conflict resolution, to prevent labels from overlapping one another. By default this algorithm only considers conflicts with other labels. This can result in labels overlapping other symbolizers, which may produce an undesirable effect.

                                  no-border

                                  GeoServer supports a vendor option called labelObstacle that allows marking a symbolizer as an obstacle. This tells the labeller to avoid rendering labels that overlap it.

                                  Warning

                                  Beware of marking a line or poly symbolizer as a label obstacle. The label conflict resolving routine is based on the bounding box so marking as a label obstacle will result in no label overlapping not only the geometry itself, but its bounding box as well.

                                  <?xml version=\"1.0\" encoding=\"ISO-8859-1\"?>\n<StyledLayerDescriptor version=\"1.0.0\" xmlns=\"http://www.opengis.net/sld\" xmlns:ogc=\"http://www.opengis.net/ogc\"\n  xmlns:xlink=\"http://www.w3.org/1999/xlink\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\">\n  <NamedLayer>\n    <UserStyle>\n\n      <FeatureTypeStyle>\n        <Rule>\n          <PointSymbolizer>\n            <Graphic>\n              <ExternalGraphic>\n                <OnlineResource\n                  xlink:type=\"simple\"\n                  xlink:href=\"smileyface.png\" />\n                <Format>image/png</Format>\n              </ExternalGraphic>\n              <Size>32</Size>\n            </Graphic>\n            <VendorOption name=\"labelObstacle\">true</VendorOption>\n          </PointSymbolizer>\n        </Rule>\n      </FeatureTypeStyle>\n\n    </UserStyle>\n  </NamedLayer>\n</StyledLayerDescriptor>\n

                                  no-border

                                  Applying the obstacle to a regular point style:

                                  <PointSymbolizer>\n  <Graphic>\n    <ExternalGraphic>\n      <OnlineResource\n        xlink:type=\"simple\"\n        xlink:href=\"smileyface.png\" />\n      <Format>image/png</Format>\n    </ExternalGraphic>\n    <Size>32</Size>\n  </Graphic>\n  <VendorOption name=\"labelObstacle\">true</VendorOption>\n</PointSymbolizer>\n

                                  no-border

                                  Applying the obstacle to line/polygon style:

                                  no-border

                                  "},{"location":"styling/sld/extensions/margins/","title":"Adding space around graphic fills","text":"

                                  Starting with GeoServer 2.3.4 it is possible to add white space around symbols used inside graphic fills, effectively allowing to control the density of the symbols in the map.

                                  <PolygonSymbolizer>\n  <Fill>\n    <GraphicFill>\n      <Graphic>\n        <ExternalGraphic>\n          <OnlineResource xlink:type=\"simple\" xlink:href=\"./rockFillSymbol.png\"/>\n          <Format>image/png</Format>\n        </ExternalGraphic>\n      </Graphic>\n    </GraphicFill>\n  </Fill>\n  <VendorOption name=\"graphic-margin\">10</VendorOption>\n</PolygonSymbolizer>\n

                                  The above forces 10 pixels of white space above, below and on either side of the symbol, effectively adding 20 pixels of white space between the symbols in the fill. The graphic-margin can be expressed, just like the CSS margin, in four different ways:

                                  • top,right,bottom,left (one explicit value per margin)
                                  • top,right-left,bottom (three values, with right and left sharing the same value)
                                  • top-bottom,right-left (two values, top and bottom sharing the same value)
                                  • top-right-bottom-left (single value for all four margins)

                                  The ability to specify different margins allows to use more than one symbol in a fill, and synchronize the relative positions of the various symbols to generate a composite fill:

                                  <PolygonSymbolizer>\n  <Fill>\n    <GraphicFill>\n      <Graphic>\n        <ExternalGraphic>\n          <OnlineResource xlink:type=\"simple\" xlink:href=\"./boulderGeometry.png\"/>\n          <Format>image/png</Format>\n        </ExternalGraphic>\n      </Graphic>\n    </GraphicFill>\n  </Fill>\n  <VendorOption name=\"graphic-margin\">35 17 17 35</VendorOption>\n</PolygonSymbolizer>\n<PolygonSymbolizer>\n  <Fill>\n    <GraphicFill>\n      <Graphic>\n        <ExternalGraphic>\n          <OnlineResource xlink:type=\"simple\" xlink:href=\"./roughGrassFillSymbol.png\"/>\n          <Format>image/png</Format>\n        </ExternalGraphic>\n      </Graphic>\n    </GraphicFill>\n  </Fill>\n  <VendorOption name=\"graphic-margin\">16 16 32 32</VendorOption>\n</PolygonSymbolizer>\n

                                  no-border

                                  "},{"location":"styling/sld/extensions/pointsymbols/","title":"Graphic symbology in GeoServer","text":"

                                  Graphic symbology is supported via the SLD <Graphic> element. This element can appear in several contexts in SLD:

                                  • in a PointSymbolizer, to display symbols at points
                                  • in the <Stroke>/<GraphicStroke> element of a LineSymbolizer and PolygonSymbolizer, to display repeated symbols along lines and polygon boundaries.
                                  • in the <Stroke>/<GraphicFill> element of a LineSymbolizer and PolygonSymbolizer, to fill lines and polygon boundaries with tiled symbols.
                                  • in the <Fill>/<GraphicFill> element of a PolygonSymbolizer, to fill polygons with tiled symbols (stippling).
                                  • in a TextSymbolizer to display a graphic behind or instead of text labels (this is a GeoServer extension).

                                  <Graphic> contains either a <Mark> or an <ExternalGraphic> element. Marks are pure vector symbols whose geometry is predefined but with stroke and fill defined in the SLD itself. External Graphics are external files (such as PNG images or SVG graphics) that contain the shape and color information defining how to render a symbol.

                                  In standard SLD the <Mark> and <ExternalGraphic> names are fixed strings. GeoServer extends this by providing dynamic symbolizers, which allow computing symbol names on a per-feature basis by embedding CQL expressions in them.

                                  "},{"location":"styling/sld/extensions/pointsymbols/#marks","title":"Marks","text":"

                                  GeoServer supports the standard SLD <Mark> symbols, a user-expandable set of extended symbols, and also TrueType Font glyphs. The symbol names are specified in the <WellKnownName> element.

                                  See also the PointSymbolizer reference for further details, as well as the examples in the Points Cookbook section.

                                  "},{"location":"styling/sld/extensions/pointsymbols/#standard-symbols","title":"Standard symbols","text":"

                                  The SLD specification mandates the support of the following symbols:

                                  Name Description

                                  square A square

                                  circle A circle

                                  triangle A triangle pointing up

                                  star five-pointed star

                                  cross A square cross with space around (not suitable for hatch fills)

                                  x A square X with space around (not suitable for hatch fills)

                                  "},{"location":"styling/sld/extensions/pointsymbols/#shape-symbols","title":"Shape symbols","text":"

                                  The shape symbols set adds extra symbols that are not part of the basic set.

                                  1. To enable ensure that the WMS Settings ****Mark Factory PrecedencehasShapeMarkFactory`` selected.

                                  2. The shape symbols are prefixed by shape://

                                    Name Description

                                    shape://vertline A vertical line (suitable for hatch fills or to make railroad symbols)

                                    shape://horline A horizontal line (suitable for hatch fills)

                                    shape://slash A diagonal line leaning forwards like the \"slash\" keyboard symbol (suitable for diagonal hatches)

                                    shape://backslash Same as shape://slash, but oriented in the opposite direction

                                    shape://dot A very small circle with space around

                                    shape://plus A + symbol, without space around (suitable for cross-hatch fills)

                                    shape://times A \"X\" symbol, without space around (suitable for cross-hatch fills)

                                    shape://oarrow An open arrow symbol (triangle without one side, suitable for placing arrows at the end of lines)

                                    shape://carrow A closed arrow symbol (closed triangle, suitable for placing arrows at the end of lines)

                                  "},{"location":"styling/sld/extensions/pointsymbols/#weather-symbols","title":"Weather Symbols","text":"

                                  The weather symbols are prefixed by the extshape:// protocol in the SLD:

                                  1. To enable ensure that the WMS Settings ****Mark Factory PrecedencehasMeteoMarkFactory`` selected.

                                  2. These symbols are:

                                    Name Description Produces

                                    extshape://triangle cold front

                                    extshape://emicircle warm front

                                    extshape://triangleemicircle stationary front

                                  3. You can use extshape:// for a few additional built-in shapes:

                                    extshape://narrow North Arrow

                                    extshape://sarrow South Arrow

                                  More complex symbols like Wind Barbs can be created with the windbarbs:// prefix.

                                  1. To enable ensure that the WMS Settings ****Mark Factory PrecedencehasWindBarbsmFactory`` selected.

                                  2. There are some examples:

                                    Name Description

                                    windbarbs://default(15)[kts] 15 wind intensity with [kts] unit of measure

                                    windbarbs://default(9)[m/s]?hemisphere=s 9 wind intensity with [m/s] unit of measure, in the south hemisphere

                                  "},{"location":"styling/sld/extensions/pointsymbols/#custom-wkt-shapes","title":"Custom WKT Shapes","text":"

                                  Custom shapes can be defined using your own Geometry, to enable use WMS Settings ****Mark Factory Precedenceto selectWKTMarkFactory. Geometry is defined using the same well-known-text format used for CQL_FILTER. .. code-block:: xml <LineSymbolizer> <Stroke> <GraphicStroke> <Graphic> <Mark> <WellKnownName>wkt://MULTILINESTRING((-0.25 -0.25, -0.125 -0.25), (0.125 -0.25, 0.25 -0.25), (-0.25 0.25, -0.125 0.25), (0.125 0.25, 0.25 0.25))</WellKnownName> <Fill> <CssParameter name=\"fill\">#0000ff</CssParameter> </Fill> <Stroke> <CssParameter name=\"stroke\">#0000ff</CssParameter> <CssParameter name=\"stroke-width\">1</CssParameter> </Stroke> </Mark> <Size>6</Size> </Graphic> </GraphicStroke> </Stroke> </LineSymbolizer> Which produces double dashed line: .. image:: images/double-dashed-line.png You can also make use of curves when defining WKT: .. code-block:: xml <LineSymbolizer> <Stroke> <GraphicStroke> <Graphic> <Mark> <WellKnownName>wkt://COMPOUNDCURVE((0 0, 0.25 0), CIRCULARSTRING(0.25 0, 0.5 0.5, 0.75 0), (0.75 0, 1 0))</WellKnownName> <Fill> <CssParameter name=\"fill\">#0000ff</CssParameter> </Fill> <Stroke> <CssParameter name=\"stroke\">#0000ff</CssParameter> <CssParameter name=\"stroke-width\">1</CssParameter> </Stroke> </Mark> <Size>10</Size> </Graphic> </GraphicStroke> </Stroke> </LineSymbolizer> Producing an \"emi circle\" line: .. image:: images/emicircle-line.png Bulk TTF marks ~~~~~~~~~~~~~~ It is possible to create a mark using glyphs from any decorative or symbolic True Type Font, such as Wingdings, WebDings, or the many symbol fonts available on the internet. To enable use WMS Settings ****Mark Factory Precedence to select TTFMarkFactory.

                                  The syntax for specifying this is:

                                  ttf://<fontname>#<hexcode>\n

                                  where fontname is the full name of a TTF font available to GeoServer, and hexcode is the hexadecimal code of the symbol. To get the hex code of a symbol, use the \"Char Map\" utility available in most operating systems (Windows and Linux Gnome both have one).

                                  For example, to use the \"shield\" symbol contained in the WebDings font, the Gnome charmap reports the symbol hex code as shown:

                                  Selecting a symbol hex code in the Gnome char map

                                  The SLD to use the shield glyph as a symbol is:

                                  <PointSymbolizer>\n    <Graphic>\n      <Mark>\n        <WellKnownName>ttf://Webdings#0x0064</WellKnownName>\n        <Fill>\n          <CssParameter name=\"fill\">#AAAAAA</CssParameter>\n        </Fill>\n        <Stroke/>\n      </Mark>\n    <Size>16</Size>\n  </Graphic>\n</PointSymbolizer>\n

                                  This results in the following map display:

                                  Shield symbols rendered on the map

                                  "},{"location":"styling/sld/extensions/pointsymbols/#extending-the-mark-subsystem-using-java","title":"Extending the Mark subsystem using Java","text":"

                                  The Mark subsystem is user-extensible. To do this using Java code, implement the MarkFactory interface and declare the implementation in the META-INF/services/org.geotools.renderer.style.MarkFactory file.

                                  For further information see the Javadoc of the GeoTools MarkFactory, along with the following example code:

                                  • The factory SPI registration file
                                  • The TTFMarkFactory implementation
                                  • The ShapeMarkFactory implementation
                                  "},{"location":"styling/sld/extensions/pointsymbols/#external-graphics","title":"External Graphics","text":"

                                  <ExternalGraphic> is the other way to define point symbology. Unlike marks, external graphics are used as-is, so the specification is somewhat simpler. The element content specifies a graphic <OnlineResource> using a URL or file path, and the graphic <Format> using a MIME type:

                                  <PointSymbolizer>\n    <Graphic>\n       <ExternalGraphic>\n          <OnlineResource xlink:type=\"simple\" xlink:href=\"http://mywebsite.com/pointsymbol.png\" />\n          <Format>image/png</Format>\n       </ExternalGraphic>\n    </Graphic>\n</PointSymbolizer>\n

                                  As with <Mark>, a <Size> element can be optionally specified. When using images as graphic symbols it is better to avoid resizing, as that may blur their appearance. Use images at their native resolution by omitting the <Size> element. In contrast, for SVG graphics specifying a <Size> is recommended. SVG files are a vector-based format describing both shape and color, so they scale cleanly to any size.

                                  If the path of the symbol file is relative, the file is looked for under $GEOSERVER_DATA_DIR/styles. For example:

                                  <PointSymbolizer>\n  <Graphic>\n    <ExternalGraphic>\n      <OnlineResource xlink:type=\"simple\" xlink:href=\"burg02.svg\" />\n      <Format>image/svg+xml</Format>\n    </ExternalGraphic>\n    <Size>20</Size>\n  </Graphic>\n</PointSymbolizer>\n

                                  In this example an SVG graphic is being used, so the size is specified explicitly.

                                  "},{"location":"styling/sld/extensions/pointsymbols/#svg-parameters","title":"SVG Parameters","text":"

                                  GeoServer can handle SVG images in which parts of the SVG-attributes are named parameters, as outlined the SVG Parameters 1.0 specification. This capability is also supported by QGIS.

                                  SVG Parameters are represented in a file like: poi_peak.svg as:

                                  <svg enable-background=\"new 0 0 580 580\" height=\"580\" viewBox=\"0 0 580 580\" width=\"580\" xmlns=\"http://www.w3.org/2000/svg\">\n<path d=\"m290.565 67.281l-255.498 442.534-1.087 1.885 511.229.393 2.18.002z\" fill=\"param(fill)\" \n fill-opacity=\"param(fill-opacity)\" stroke=\"param(outline)\" stroke-opacity=\"param(outline-opacity)\" stroke-width=\"param(outline-width)\"/>\n</svg>\n

                                  The 'param'-constructs mean that you can define the parameters: fill, fill-opacity, outline, outline-opacity and outline-width as part of an SVG URL reference, where a reference to this image with red fill would be: poi_peak.svg?fill=#FF0000.

                                  Note: When editng SVG files (e.g. in Inkscape) save using 'simple svg' format.

                                  Default behaviour:

                                  • OnlineResource href URI without any parameters.

                                    <se:OnlineResource xlink:href=\"poi_peak.svg\" xlink:type=\"simple\"/>\n
                                  • Displays poi_peak.svg with the default black fill.

                                    SVG image with default black fill

                                  Using #ff000 red parameter:

                                  • OnlineResource href URI with parameter:

                                    <se:OnlineResource xlink:href=\"poi_peak.svg?fill=#ff0000\" xlink:type=\"simple\"/>\n
                                  • Displays poi_peak.svg with supplied red fill.

                                    SVG image with fill provided by parameter

                                  To define several parameters, the query-parameters should be url-encoded.

                                  • A green peak with 25% opacity: ?fill=#00ff00&opacity=0.25, requires encoding both the '#' ( %23 ) and the '&' ( &amp; ) signs:

                                    <se:OnlineResource xlink:href=\"poi_peak.svg?fill=%2300ff00&amp;opacity=0.25\" xlink:type=\"simple\"/>\n
                                  • Displayed with white fill, red outlined peaks:

                                    SVG image with fill and outline provided by parameters

                                  Parameters names are defined by the SVG file:

                                  • The parameter 'stroke' above is called 'outline' in the original svg file:

                                    stroke=\"param(outline)\"\n
                                  • OnlineResource href URI referencing parameters fill, outline and outline-width:

                                    <se:OnlineResource xlink:href=\"poi_peak.svg?fill=%23ffffff&amp;outline=%23ff0000&amp;outline-width=5\" xlink:type=\"simple\"/>\n
                                  • Displayed as:

                                    SVG image with fill

                                  The use of SVG parameters can be combinded with dynamic symbolizers (covered below) to supply SVG parameter values based on feature attribute data and expressions.

                                  • OnlineResource href URI referencing SVG Parameter with dynamic CQL expression:

                                    <se:OnlineResource xlink:href=\"poi_peak.svg?fill=${COLOR}\" xlink:type=\"simple\"/>\n
                                  • Display depends on the feature attribute COLOR.

                                  "},{"location":"styling/sld/extensions/pointsymbols/#bulk-wkt-shapes","title":"Bulk WKT Shapes","text":"

                                  It is possible to create a symbol set of your own custom marks using a property file.

                                  Here is an example.properties:

                                  zig=LINESTRING(0.0 0.25, 0.25 0.25, 0.5 0.75, 0.75 0.25, 1.00 0.25)\nblock=POLYGON((0 0, 1 0, 1 1, 0 1, 0 0))\n

                                  The SLD to use the symbols defined in example.properties is:

                                  <PointSymbolizer>\n  <Graphic>\n    <ExternalGraphic>\n      <OnlineResource \n        xlink:type=\"simple\"\n        xlink:href=\"example.properties#zig\" />\n      <Format>wkt</Format>\n    </ExternalGraphic>\n    <Size>20</Size>\n  </Graphic>\n</PointSymbolizer>\n
                                  "},{"location":"styling/sld/extensions/pointsymbols/#symbol-positioning","title":"Symbol Positioning","text":"

                                  Graphic symbols are rendered so that the center of the graphic extent lies on the placement point (or points, in the case of repeated or tiled graphics). If it is desired to have a graphic offset from a point (such as a symbol which acts as a pointer) it is necessary to offset the visible portion of the graphic within the overall extent. For images this can be accomplished by extending the image with transparent pixels. For SVG graphics this can be done by surrounding the shape with an invisible rectangle with the desired relative position.

                                  "},{"location":"styling/sld/extensions/pointsymbols/#dynamic-symbolizers","title":"Dynamic symbolizers","text":"

                                  In standard SLD, the Mark/WellKnowName element and the ExternalGraphic/OnlineResource/@xlink:href attribute are fixed strings. This means they have the same value for all rendered features. When the symbols to be displayed vary depending on feature attributes this restriction leads to very verbose styling, as a separate Rule and Symbolizer must be used for each different symbol.

                                  GeoServer improves this by allowing CQL expressions<filter_ecql_reference> to be embedded inside the content of both WellKnownName and OnlineResource/@xlink:href. When the names of the symbols can be derived from the feature attribute values, this provides much more compact styling. CQL expressions can be embedded in a <WellKnownName> content string or an <OnlineResource> xlink:href attribute by using the syntax:

                                  ${<cql expression>}\n

                                  Note

                                  Currently xlink:href strings must be valid URLs before expression expansion is performed. This means that the URL cannot be completely provided by an expression. The xlink:href string must explicitly include at least the prefix http://

                                  The simplest form of expression is a single attribute name, such as ${STATE_ABBR}. For example, suppose we want to display the flags of the US states using symbols whose file names match the state name. The following style specifies the flag symbols using a single rule:

                                  <ExternalGraphic>\n   <OnlineResource xlink:type=\"simple\" \n                   xlink:href=\"http://mysite.com/tn_${STATE_ABBR}.jpg\"/>\n   <Format>image/jpeg</Format>\n</ExternalGraphic>\n

                                  If manipulation of the attribute values is required a full CQL expression can be specified. For example, if the values in the STATE_ABBR attribute are uppercase but the URL requires a lowercase name, the CQL strToLowerCase function can be used:

                                  <ExternalGraphic>\n   <OnlineResource xlink:type=\"simple\"\n            xlink:href=\"http://mysite.com/tn_${strToLowerCase(STATE_ABBR)}.jpg\" />\n   <Format>image/jpeg</Format>\n</ExternalGraphic>\n
                                  "},{"location":"styling/sld/extensions/randomized/","title":"Fills with randomized symbols","text":"

                                  Starting with GeoServer 2.4.2 it is possible to generate fills by randomly repeating a symbol in the polygons to be filled. Or, to be more precise, generate the usual texture fill by repeating over and over a tile, whose contents is the random repetition of a fill. The random distribution is stable, so it will be the same across calls and tiles, and it's controlled by the seed used to generate the distribution.

                                  The random fill is generated by specifying a GraphicFill with a Mark or ExternalGraphic, and then adding vendor options to control how the symbol is randomly repeated. Here is a table with options, default values, and possible values:

                                  Option Default value Description

                                  random none Activates random distribution of symbol. Possible values are none, free, grid. none disables random distribution, free generates a completely random distribution, grid will generate a regular grid of positions, and only randomizes the position of the symbol around the cell centers, providing a more even distribution in space

                                  random-tile-size 256 Size the texture fill tile that will contain the randomly distributed symbols

                                  random-rotation none Activates random symbol rotation. Possible values are none (no rotation) or free

                                  random-symbol-count 16 The number of symbols in the tile. The number of symbols actually painted can be lower, as the distribution will ensure no two symbols overlap with each other.

                                  random-seed 0 The \"seed\" used to generate the random distribution. Changing this value will result in a different symbol distribution

                                  Here is an example:

                                  <sld:PolygonSymbolizer>\n <sld:Fill>\n   <sld:GraphicFill>\n     <sld:Graphic>\n       <sld:Mark>\n         <sld:WellKnownName>shape://slash</sld:WellKnownName>\n         <sld:Stroke>\n           <sld:CssParameter name=\"stroke\">#0000ff</sld:CssParameter>\n           <sld:CssParameter name=\"stroke-linecap\">round</sld:CssParameter>\n           <sld:CssParameter name=\"stroke-width\">4</sld:CssParameter>\n         </sld:Stroke>\n       </sld:Mark>\n       <sld:Size>8</sld:Size>\n     </sld:Graphic>\n   </sld:GraphicFill>\n </sld:Fill>\n <sld:VendorOption name=\"random-seed\">5</sld:VendorOption>\n <sld:VendorOption name=\"random\">grid</sld:VendorOption>\n <sld:VendorOption name=\"random-tile-size\">100</sld:VendorOption>\n <sld:VendorOption name=\"random-rotation\">free</sld:VendorOption>\n <sld:VendorOption name=\"random-symbol-count\">50</sld:VendorOption>\n</sld:PolygonSymbolizer>\n

                                  Random distribution of a diagonal line

                                  Randomized distributions can also be used for thematic mapping, for example, here is the SLD for a version of topp:states that displays the number of inhabitant\u00ecs varying the density of a random point distribution:

                                  <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<sld:UserStyle xmlns=\"http://www.opengis.net/sld\" xmlns:sld=\"http://www.opengis.net/sld\" xmlns:ogc=\"http://www.opengis.net/ogc\" xmlns:gml=\"http://www.opengis.net/gml\">\n  <sld:Name>Default Styler</sld:Name>\n  <sld:FeatureTypeStyle>\n    <sld:Name>name</sld:Name>\n    <sld:Rule>\n      <ogc:Filter>\n        <ogc:And>\n          <ogc:Not>\n            <ogc:PropertyIsLessThan>\n              <ogc:PropertyName>PERSONS</ogc:PropertyName>\n              <ogc:Literal>2000000</ogc:Literal>\n            </ogc:PropertyIsLessThan>\n          </ogc:Not>\n          <ogc:Not>\n            <ogc:PropertyIsGreaterThanOrEqualTo>\n              <ogc:PropertyName>PERSONS</ogc:PropertyName>\n              <ogc:Literal>4000000</ogc:Literal>\n            </ogc:PropertyIsGreaterThanOrEqualTo>\n          </ogc:Not>\n        </ogc:And>\n      </ogc:Filter>\n      <sld:PolygonSymbolizer>\n        <sld:Fill>\n          <sld:GraphicFill>\n            <sld:Graphic>\n              <sld:Mark>\n                <sld:WellKnownName>circle</sld:WellKnownName>\n                <sld:Fill>\n                  <sld:CssParameter name=\"fill\">#a9a9a9</sld:CssParameter>\n                </sld:Fill>\n              </sld:Mark>\n              <sld:Size>2</sld:Size>\n            </sld:Graphic>\n          </sld:GraphicFill>\n        </sld:Fill>\n        <sld:VendorOption name=\"random\">grid</sld:VendorOption>\n        <sld:VendorOption name=\"random-tile-size\">100</sld:VendorOption>\n        <sld:VendorOption name=\"random-symbol-count\">150</sld:VendorOption>\n      </sld:PolygonSymbolizer>\n      <sld:LineSymbolizer>\n        <sld:Stroke/>\n      </sld:LineSymbolizer>\n    </sld:Rule>\n    <sld:Rule>\n      <ogc:Filter>\n        <ogc:PropertyIsLessThan>\n          <ogc:PropertyName>PERSONS</ogc:PropertyName>\n          <ogc:Literal>2000000</ogc:Literal>\n        </ogc:PropertyIsLessThan>\n      </ogc:Filter>\n      <sld:PolygonSymbolizer>\n        <sld:Fill>\n          <sld:GraphicFill>\n            <sld:Graphic>\n              <sld:Mark>\n                <sld:WellKnownName>circle</sld:WellKnownName>\n                <sld:Fill>\n                  <sld:CssParameter name=\"fill\">#a9a9a9</sld:CssParameter>\n                </sld:Fill>\n              </sld:Mark>\n              <sld:Size>2</sld:Size>\n            </sld:Graphic>\n          </sld:GraphicFill>\n        </sld:Fill>\n        <sld:VendorOption name=\"random\">grid</sld:VendorOption>\n        <sld:VendorOption name=\"random-tile-size\">100</sld:VendorOption>\n        <sld:VendorOption name=\"random-symbol-count\">50</sld:VendorOption>\n      </sld:PolygonSymbolizer>\n      <sld:LineSymbolizer>\n        <sld:Stroke/>\n      </sld:LineSymbolizer>\n    </sld:Rule>\n    <sld:Rule>\n      <ogc:Filter>\n        <ogc:PropertyIsGreaterThanOrEqualTo>\n          <ogc:PropertyName>PERSONS</ogc:PropertyName>\n          <ogc:Literal>4000000</ogc:Literal>\n        </ogc:PropertyIsGreaterThanOrEqualTo>\n      </ogc:Filter>\n      <sld:PolygonSymbolizer>\n        <sld:Fill>\n          <sld:GraphicFill>\n            <sld:Graphic>\n              <sld:Mark>\n                <sld:WellKnownName>circle</sld:WellKnownName>\n                <sld:Fill>\n                  <sld:CssParameter name=\"fill\">#a9a9a9</sld:CssParameter>\n                </sld:Fill>\n              </sld:Mark>\n              <sld:Size>2</sld:Size>\n            </sld:Graphic>\n          </sld:GraphicFill>\n        </sld:Fill>\n        <sld:VendorOption name=\"random\">grid</sld:VendorOption>\n        <sld:VendorOption name=\"random-tile-size\">100</sld:VendorOption>\n        <sld:VendorOption name=\"random-symbol-count\">500</sld:VendorOption>\n      </sld:PolygonSymbolizer>\n      <sld:LineSymbolizer>\n        <sld:Stroke/>\n      </sld:LineSymbolizer>\n    </sld:Rule>\n  </sld:FeatureTypeStyle>\n</sld:UserStyle>\n

                                  Thematic map via point density approach

                                  "},{"location":"styling/sld/extensions/rendering-selection/","title":"Rendering Selection","text":"

                                  GeoServer provides a VendorOption to define whether a particular element Rule, FeatureTypeStyle or Symbolizer should be applied to a getLegendGraphic output or to a getMap output.

                                  This allows to generate legends from the SLD that can be better looking and more expressive, without the underlying complexity of the actual rendered style. Other systems have a dedicated language to build legends instead. The advantage of using the same language is that dynamic behaviors, like rule removal based on the area being rendered, can be easily retained.

                                  The vendor option is named inclusion, e.g.:

                                  • legendOnly
                                  • mapOnly

                                  Valid values are:

                                  • legendOnly the element will be skipped when applying the style to the data to render map.
                                  • mapOnly the element will be skipped when applying the style to the data to render legend.
                                  • normal will have the same effect then omitting the VendorOption: the SLD element will be used for both map and legend (same effect as not specifying the vendor option).

                                  Take as an example the following style: for each Rule two symbolizers are defined one that will be skipped when rendering the legend and one that will be skipped when rendering the map and loads the legend icon from an external svg file.

                                  <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<StyledLayerDescriptor xmlns=\"http://www.opengis.net/sld\" xmlns:ogc=\"http://www.opengis.net/ogc\" xmlns:xlink=\"http://www.w3.org/1999/xlink\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" version=\"1.0.0\" xsi:schemaLocation=\"http://www.opengis.net/sld http://schemas.opengis.net/sld/1.0.0/StyledLayerDescriptor.xsd\">\n  <NamedLayer>\n     <Name>Style example</Name>\n     <UserStyle>\n        <FeatureTypeStyle>\n           <Rule>\n              <ogc:Filter>\n                 <ogc:PropertyIsLessThan>\n                    <ogc:PropertyName>numericValue</ogc:PropertyName>\n                    <ogc:Literal>90</ogc:Literal>\n                 </ogc:PropertyIsLessThan>\n              </ogc:Filter>\n              <PointSymbolizer>\n                 <Graphic>\n                    <Mark>\n                       <WellKnownName>circle</WellKnownName>\n                       <Fill>\n                          <CssParameter name=\"fill\">0xFF0000</CssParameter>\n                       </Fill>\n                    </Mark>\n                    <Size>32</Size>\n                 </Graphic>\n                 <VendorOption name=\"inclusion\">mapOnly</VendorOption>\n              </PointSymbolizer>\n              <PointSymbolizer>\n                 <Graphic>\n                    <ExternalGraphic>\n                       <OnlineResource xlink:type=\"simple\" xlink:href=\"my-custom-legend-icon1.svg\" />\n                       <Format>image/svg+xml</Format>\n                    </ExternalGraphic>\n                    <Size>20</Size>\n                 </Graphic>\n                 <VendorOption name=\"inclusion\">legendOnly</VendorOption>\n              </PointSymbolizer>\n           </Rule>\n           <Rule>\n              <ogc:Filter>\n                 <ogc:And>\n                    <ogc:PropertyIsGreaterThanOrEqualTo>\n                       <ogc:PropertyName>numericValue</ogc:PropertyName>\n                       <ogc:Literal>90</ogc:Literal>\n                    </ogc:PropertyIsGreaterThanOrEqualTo>\n                    <ogc:PropertyIsLessThan>\n                       <ogc:PropertyName>numericValue</ogc:PropertyName>\n                       <ogc:Literal>180</ogc:Literal>\n                    </ogc:PropertyIsLessThan>\n                 </ogc:And>\n              </ogc:Filter>\n              <PointSymbolizer>\n                 <Graphic>\n                    <Mark>\n                       <WellKnownName>circle</WellKnownName>\n                       <Fill>\n                          <CssParameter name=\"fill\">#6495ED</CssParameter>\n                       </Fill>\n                    </Mark>\n                    <Size>32</Size>\n                 </Graphic>\n                 <VendorOption name=\"inclusion\">mapOnly</VendorOption>\n              </PointSymbolizer>\n              <PointSymbolizer>\n                 <Graphic>\n                    <ExternalGraphic>\n                       <OnlineResource xlink:type=\"simple\" xlink:href=\"my-custom-legend-icon2.svg\" />\n                       <Format>image/svg+xml</Format>\n                    </ExternalGraphic>\n                    <Size>20</Size>\n                 </Graphic>\n                 <VendorOption name=\"inclusion\">legendOnly</VendorOption>\n              </PointSymbolizer>\n           </Rule>\n        </FeatureTypeStyle>\n     </UserStyle>\n  </NamedLayer>\n</StyledLayerDescriptor>\n

                                  The same result could have been obtained by defining each rule two time each one with a single symbolizer, and defining the vendor options at the rule level.

                                  <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<StyledLayerDescriptor xmlns=\"http://www.opengis.net/sld\" xmlns:ogc=\"http://www.opengis.net/ogc\" xmlns:xlink=\"http://www.w3.org/1999/xlink\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" version=\"1.0.0\" xsi:schemaLocation=\"http://www.opengis.net/sld http://schemas.opengis.net/sld/1.0.0/StyledLayerDescriptor.xsd\">\n <NamedLayer>\n    <Name>Style example</Name>\n    <UserStyle>\n       <FeatureTypeStyle>\n          <Rule>\n             <ogc:Filter>\n                <ogc:PropertyIsLessThan>\n                   <ogc:PropertyName>numericValue</ogc:PropertyName>\n                   <ogc:Literal>90</ogc:Literal>\n                </ogc:PropertyIsLessThan>\n             </ogc:Filter>\n             <PointSymbolizer>\n                <Graphic>\n                   <Mark>\n                      <WellKnownName>circle</WellKnownName>\n                      <Fill>\n                         <CssParameter name=\"fill\">0xFF0000</CssParameter>\n                      </Fill>\n                   </Mark>\n                   <Size>32</Size>\n                </Graphic>\n             </PointSymbolizer>\n             <VendorOption name=\"inclusion\">mapOnly</VendorOption>\n          </Rule>\n          <Rule>\n             <ogc:Filter>\n                <ogc:And>\n                   <ogc:PropertyIsGreaterThanOrEqualTo>\n                      <ogc:PropertyName>numericValue</ogc:PropertyName>\n                      <ogc:Literal>90</ogc:Literal>\n                   </ogc:PropertyIsGreaterThanOrEqualTo>\n                   <ogc:PropertyIsLessThan>\n                      <ogc:PropertyName>numericValue</ogc:PropertyName>\n                      <ogc:Literal>180</ogc:Literal>\n                   </ogc:PropertyIsLessThan>\n                </ogc:And>\n             </ogc:Filter>\n             <PointSymbolizer>\n                <Graphic>\n                   <Mark>\n                      <WellKnownName>circle</WellKnownName>\n                      <Fill>\n                         <CssParameter name=\"fill\">#6495ED</CssParameter>\n                      </Fill>\n                   </Mark>\n                   <Size>32</Size>\n                </Graphic>\n                <VendorOption name=\"inclusion\">mapOnly</VendorOption>\n             </PointSymbolizer>\n          </Rule>\n          <Rule>\n             <ogc:Filter>\n                <ogc:PropertyIsLessThan>\n                   <ogc:PropertyName>numericValue</ogc:PropertyName>\n                   <ogc:Literal>90</ogc:Literal>\n                </ogc:PropertyIsLessThan>\n             </ogc:Filter>\n             <PointSymbolizer>\n                <Graphic>\n                   <ExternalGraphic>\n                      <OnlineResource xlink:type=\"simple\" xlink:href=\"my-custom-legend-icon1.svg\" />\n                      <Format>image/svg+xml</Format>\n                   </ExternalGraphic>\n                   <Size>20</Size>\n                </Graphic>\n                <VendorOption name=\"inclusion\">legendOnly</VendorOption>\n             </PointSymbolizer>\n          </Rule>\n          <Rule>\n             <ogc:Filter>\n                <ogc:And>\n                   <ogc:PropertyIsGreaterThanOrEqualTo>\n                      <ogc:PropertyName>numericValue</ogc:PropertyName>\n                      <ogc:Literal>90</ogc:Literal>\n                   </ogc:PropertyIsGreaterThanOrEqualTo>\n                   <ogc:PropertyIsLessThan>\n                      <ogc:PropertyName>numericValue</ogc:PropertyName>\n                      <ogc:Literal>180</ogc:Literal>\n                   </ogc:PropertyIsLessThan>\n                </ogc:And>\n             </ogc:Filter>\n             <PointSymbolizer>\n                <Graphic>\n                   <ExternalGraphic>\n                      <OnlineResource xlink:type=\"simple\" xlink:href=\"my-custom-legend-icon2.svg\" />\n                      <Format>image/svg+xml</Format>\n                   </ExternalGraphic>\n                   <Size>20</Size>\n                </Graphic>\n                <VendorOption name=\"inclusion\">legendOnly</VendorOption>\n             </PointSymbolizer>\n          </Rule>\n       </FeatureTypeStyle>\n    </UserStyle>\n </NamedLayer>\n</StyledLayerDescriptor>\n

                                  A third way to obtain the same result could be to define vendor options at the FeatureTypeStyle level.

                                  <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<StyledLayerDescriptor xmlns=\"http://www.opengis.net/sld\" xmlns:ogc=\"http://www.opengis.net/ogc\" xmlns:xlink=\"http://www.w3.org/1999/xlink\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" version=\"1.0.0\" xsi:schemaLocation=\"http://www.opengis.net/sld http://schemas.opengis.net/sld/1.0.0/StyledLayerDescriptor.xsd\">\n<NamedLayer>\n   <Name>Style example</Name>\n   <UserStyle>\n   <FeatureTypeStyle>\n         <Rule>\n            <ogc:Filter>\n               <ogc:PropertyIsLessThan>\n                  <ogc:PropertyName>numericValue</ogc:PropertyName>\n                  <ogc:Literal>90</ogc:Literal>\n               </ogc:PropertyIsLessThan>\n            </ogc:Filter>\n            <PointSymbolizer>\n               <Graphic>\n                  <Mark>\n                     <WellKnownName>circle</WellKnownName>\n                     <Fill>\n                        <CssParameter name=\"fill\">0xFF0000</CssParameter>\n                     </Fill>\n                  </Mark>\n                  <Size>32</Size>\n               </Graphic>\n            </PointSymbolizer>\n         </Rule>\n         <Rule>\n            <ogc:Filter>\n               <ogc:And>\n                  <ogc:PropertyIsGreaterThanOrEqualTo>\n                     <ogc:PropertyName>numericValue</ogc:PropertyName>\n                     <ogc:Literal>90</ogc:Literal>\n                  </ogc:PropertyIsGreaterThanOrEqualTo>\n                  <ogc:PropertyIsLessThan>\n                     <ogc:PropertyName>numericValue</ogc:PropertyName>\n                     <ogc:Literal>180</ogc:Literal>\n                  </ogc:PropertyIsLessThan>\n               </ogc:And>\n            </ogc:Filter>\n            <PointSymbolizer>\n               <Graphic>\n                  <Mark>\n                     <WellKnownName>circle</WellKnownName>\n                     <Fill>\n                        <CssParameter name=\"fill\">#6495ED</CssParameter>\n                     </Fill>\n                  </Mark>\n                  <Size>32</Size>\n               </Graphic>\n            </PointSymbolizer>\n         </Rule>\n         <VendorOption name=\"inclusion\">mapOnly</VendorOption>\n      </FeatureTypeStyle>\n      <FeatureTypeStyle>\n         <Rule>\n            <ogc:Filter>\n               <ogc:PropertyIsLessThan>\n                  <ogc:PropertyName>numericValue</ogc:PropertyName>\n                  <ogc:Literal>90</ogc:Literal>\n               </ogc:PropertyIsLessThan>\n            </ogc:Filter>\n            <PointSymbolizer>\n               <Graphic>\n                  <ExternalGraphic>\n                     <OnlineResource xlink:type=\"simple\" xlink:href=\"my-custom-legend-icon1.svg\" />\n                     <Format>image/svg+xml</Format>\n                  </ExternalGraphic>\n                  <Size>20</Size>\n               </Graphic>\n            </PointSymbolizer>\n         </Rule>\n         <Rule>\n            <ogc:Filter>\n               <ogc:And>\n                  <ogc:PropertyIsGreaterThanOrEqualTo>\n                     <ogc:PropertyName>numericValue</ogc:PropertyName>\n                     <ogc:Literal>90</ogc:Literal>\n                  </ogc:PropertyIsGreaterThanOrEqualTo>\n                  <ogc:PropertyIsLessThan>\n                     <ogc:PropertyName>numericValue</ogc:PropertyName>\n                     <ogc:Literal>180</ogc:Literal>\n                  </ogc:PropertyIsLessThan>\n               </ogc:And>\n            </ogc:Filter>\n            <PointSymbolizer>\n               <Graphic>\n                  <ExternalGraphic>\n                     <OnlineResource xlink:type=\"simple\" xlink:href=\"my-custom-legend-icon2.svg\" />\n                     <Format>image/svg+xml</Format>\n                  </ExternalGraphic>\n                  <Size>20</Size>\n               </Graphic>\n            </PointSymbolizer>\n         </Rule>\n         <VendorOption name=\"inclusion\">legendOnly</VendorOption>\n      </FeatureTypeStyle>\n   </UserStyle>\n</NamedLayer>\n</StyledLayerDescriptor>\n
                                  "},{"location":"styling/sld/extensions/rendering-transform/","title":"Rendering Transformations","text":"

                                  Rendering Transformations allow processing to be carried out on datasets within the GeoServer rendering pipeline. A typical transformation computes a derived or aggregated result from the input data, allowing various useful visualization effects to be obtained. Transformations may transform data from one format into another (i.e vector to raster or vice-versa), to provide an appropriate format for display.

                                  The following table lists examples of various kinds of rendering transformations available in GeoServer:

                                  Type Examples

                                  Raster-to-Vector Contour extracts contours from a DEM raster. RasterAsPointCollections extracts a vector field from a multi-band raster

                                  Vector-to-Raster BarnesSurfaceInterpolation computes a surface from scattered data points. Heatmap computes a heatmap surface from weighted data points.

                                  Vector-to-Vector PointStacker aggregates dense point data into clusters.

                                  Rendering transformations are invoked within SLD styles. Parameters may be supplied to control the appearance of the output. The rendered output for the layer is produced by applying the styling rules and symbolizers in the SLD to the result of transformation.

                                  Rendering transformations are implemented using the same mechanism as Process Cookbook. They can thus also be executed via the WPS protocol, if required. Conversely, any WPS process can be executed as a transformation, as long as the input and output are appropriate for use within an SLD.

                                  This section is a general guide to rendering transformation usage in GeoServer. For details of input, parameters, and output for any particular rendering transformation, refer to its own documentation.

                                  "},{"location":"styling/sld/extensions/rendering-transform/#installation","title":"Installation","text":"

                                  Using Rendering Transformations requires the WPS extension to be installed. See Installing the WPS extension.

                                  Note

                                  The WPS service does not need to be enabled to use Rendering Transformations. To avoid unwanted consumption of server resources it may be desirable to disable the WPS service if it is not being used directly.

                                  "},{"location":"styling/sld/extensions/rendering-transform/#usage","title":"Usage","text":"

                                  Rendering Transformations are invoked by adding the <Transformation> element to a <FeatureTypeStyle> element in an SLD document. This element specifies the name of the transformation process, and usually includes parameter values controlling the operation of the transformation.

                                  The <Transformation> element syntax leverages the OGC Filter function syntax. The content of the element is a <ogc:Function> with the name of the rendering transformation process. Transformation processes may accept some number of parameters, which may be either required (in which case they must be specified), or optional (in which case they may be omitted if the default value is acceptable). Parameters are supplied as name/value pairs. Each parameter's name and value are supplied via another function <ogc:Function name=\"parameter\">. The first argument to this function is an <ogc:Literal> containing the name of the parameter. The optional following arguments provide the value for the parameter (if any). Some parameters accept only a single value, while others may accept a list of values. As with any filter function argument, values may be supplied in several ways:

                                  • As a literal value
                                  • As a computed expression
                                  • As an SLD environment variable, whose actual value is supplied in the WMS request (see Variable substitution in SLD).
                                  • As a predefined SLD environment variable (which allows obtaining values for the current request such as output image width and height).

                                  The order of the supplied parameters is not significant.

                                  Most rendering transformations take as input a dataset to be transformed. This is supplied via a special named parameter which does not have a value specified. The name of the parameter is determined by the particular transformation being used. When the transformation is executed, the input dataset is passed to it via this parameter.

                                  The input dataset is determined by the same query mechanism as used for all WMS requests, and can thus be filtered in the request if required.

                                  In rendering transformations which take as input a featuretype (vector dataset) and convert it to a raster dataset, in order to pass validation the SLD needs to mention the geometry attribute of the input dataset (even though it is not used). This is done by specifying the attribute name in the symbolizer <Geometry> element.

                                  The output of the rendering transformation is styled using symbolizers appropriate to its format: PointSymbolizer, LineSymbolizer, PolygonSymbolizer, and TextSymbolizer for vector data, and RasterSymbolizer for raster coverage data.

                                  If it is desired to display the input dataset in its original form, or transformed in another way, there are two options:

                                  • Another <FeatureTypeStyle> can be used in the same SLD
                                  • Another SLD can be created, and the layer displayed twice using the different SLDs
                                  "},{"location":"styling/sld/extensions/rendering-transform/#notes","title":"Notes","text":"
                                  • Rendering transformations may not work correctly in tiled mode, unless they have been specifically written to accommodate it.
                                  "},{"location":"styling/sld/extensions/rendering-transform/#examples","title":"Examples","text":""},{"location":"styling/sld/extensions/rendering-transform/#contour-extraction","title":"Contour extraction","text":"

                                  ras:Contour is a Raster-to-Vector rendering transformation which extracts contour lines at specified levels from a raster DEM. The following SLD invokes the transformation and styles the contours as black lines.

                                  <?xml version=\"1.0\" encoding=\"ISO-8859-1\"?>\n<StyledLayerDescriptor version=\"1.0.0\" \n  xsi:schemaLocation=\"http://www.opengis.net/sld StyledLayerDescriptor.xsd\" \n  xmlns=\"http://www.opengis.net/sld\" \n  xmlns:ogc=\"http://www.opengis.net/ogc\" \n  xmlns:xlink=\"http://www.w3.org/1999/xlink\" \n  xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\">\n  <NamedLayer>\n    <Name>contour_dem</Name>\n    <UserStyle>\n      <Title>Contour DEM</Title>\n      <Abstract>Extracts contours from DEM</Abstract>\n      <FeatureTypeStyle>\n        <Transformation>\n          <ogc:Function name=\"ras:Contour\">\n            <ogc:Function name=\"parameter\">\n              <ogc:Literal>data</ogc:Literal>\n            </ogc:Function>\n            <ogc:Function name=\"parameter\">\n              <ogc:Literal>levels</ogc:Literal>\n              <ogc:Literal>1100</ogc:Literal>\n              <ogc:Literal>1200</ogc:Literal>\n              <ogc:Literal>1300</ogc:Literal>\n              <ogc:Literal>1400</ogc:Literal>\n              <ogc:Literal>1500</ogc:Literal>\n              <ogc:Literal>1600</ogc:Literal>\n              <ogc:Literal>1700</ogc:Literal>\n              <ogc:Literal>1800</ogc:Literal>\n            </ogc:Function>\n          </ogc:Function>\n        </Transformation>\n        <Rule>\n          <Name>rule1</Name>\n          <Title>Contour Line</Title>\n          <LineSymbolizer>\n            <Stroke>\n              <CssParameter name=\"stroke\">#000000</CssParameter>\n              <CssParameter name=\"stroke-width\">1</CssParameter>\n            </Stroke>\n          </LineSymbolizer>\n          <TextSymbolizer>\n            <Label>\n              <ogc:PropertyName>value</ogc:PropertyName>\n            </Label>\n            <Font>\n              <CssParameter name=\"font-family\">Arial</CssParameter>\n              <CssParameter name=\"font-style\">Normal</CssParameter>\n              <CssParameter name=\"font-size\">10</CssParameter>\n            </Font>\n            <LabelPlacement>\n              <LinePlacement/>\n            </LabelPlacement>\n            <Halo>\n              <Radius>\n                <ogc:Literal>2</ogc:Literal>\n              </Radius>\n              <Fill>\n                <CssParameter name=\"fill\">#FFFFFF</CssParameter>\n                <CssParameter name=\"fill-opacity\">0.6</CssParameter>        \n              </Fill>\n            </Halo>\n            <Fill>\n              <CssParameter name=\"fill\">#000000</CssParameter>\n            </Fill>\n            <Priority>2000</Priority>\n            <VendorOption name=\"followLine\">true</VendorOption>\n            <VendorOption name=\"repeat\">100</VendorOption>\n            <VendorOption name=\"maxDisplacement\">50</VendorOption>\n            <VendorOption name=\"maxAngleDelta\">30</VendorOption>\n          </TextSymbolizer>\n        </Rule>\n      </FeatureTypeStyle>\n    </UserStyle>\n  </NamedLayer>\n </StyledLayerDescriptor>\n

                                  Key aspects of the SLD are:

                                  • Lines 14-15 define the rendering transformation, using the process ras:Contour.
                                  • Lines 16-18 supply the input data parameter, named data in this process.
                                  • Lines 19-29 supply values for the process's levels parameter, which specifies the elevation levels for the contours to extract.
                                  • Lines 35-40 specify a LineSymbolizer to style the contour lines.
                                  • Lines 41-70 specify a TextSymbolizer to show the contour levels along the lines.

                                  The result of using this transformation is shown in the following map image (which also shows the underlying DEM raster):

                                  "},{"location":"styling/sld/extensions/rendering-transform/#heatmap-generation","title":"Heatmap generation","text":"

                                  vec:Heatmap is a Vector-to-Raster rendering transformation which generates a heatmap surface from weighted point data. The following SLD invokes a Heatmap rendering transformation on a featuretype with point geometries and an attribute pop2000 supplying the weight for the points (in this example, a dataset of world urban areas is used). The output is styled using a color ramp across the output data value range [0 .. 1].

                                  <?xml version=\"1.0\" encoding=\"ISO-8859-1\"?>\n<StyledLayerDescriptor version=\"1.0.0\" \n    xsi:schemaLocation=\"http://www.opengis.net/sld StyledLayerDescriptor.xsd\" \n    xmlns=\"http://www.opengis.net/sld\" \n    xmlns:ogc=\"http://www.opengis.net/ogc\" \n    xmlns:xlink=\"http://www.w3.org/1999/xlink\" \n    xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\">\n  <NamedLayer>\n    <Name>Heatmap</Name>\n    <UserStyle>\n      <Title>Heatmap</Title>\n      <Abstract>A heatmap surface showing population density</Abstract>\n      <FeatureTypeStyle>\n        <Transformation>\n          <ogc:Function name=\"vec:Heatmap\">\n            <ogc:Function name=\"parameter\">\n              <ogc:Literal>data</ogc:Literal>\n            </ogc:Function>\n            <ogc:Function name=\"parameter\">\n              <ogc:Literal>weightAttr</ogc:Literal>\n              <ogc:Literal>pop2000</ogc:Literal>\n            </ogc:Function>\n            <ogc:Function name=\"parameter\">\n              <ogc:Literal>radiusPixels</ogc:Literal>\n              <ogc:Function name=\"env\">\n                <ogc:Literal>radius</ogc:Literal>\n                <ogc:Literal>100</ogc:Literal>\n              </ogc:Function>\n            </ogc:Function>\n            <ogc:Function name=\"parameter\">\n              <ogc:Literal>pixelsPerCell</ogc:Literal>\n              <ogc:Literal>10</ogc:Literal>\n            </ogc:Function>\n            <ogc:Function name=\"parameter\">\n              <ogc:Literal>outputBBOX</ogc:Literal>\n              <ogc:Function name=\"env\">\n                <ogc:Literal>wms_bbox</ogc:Literal>\n              </ogc:Function>\n            </ogc:Function>\n            <ogc:Function name=\"parameter\">\n              <ogc:Literal>outputWidth</ogc:Literal>\n              <ogc:Function name=\"env\">\n                <ogc:Literal>wms_width</ogc:Literal>\n              </ogc:Function>\n            </ogc:Function>\n            <ogc:Function name=\"parameter\">\n              <ogc:Literal>outputHeight</ogc:Literal>\n              <ogc:Function name=\"env\">\n                <ogc:Literal>wms_height</ogc:Literal>\n              </ogc:Function>\n            </ogc:Function>\n          </ogc:Function>\n        </Transformation>\n       <Rule>\n         <RasterSymbolizer>\n         <!-- specify geometry attribute to pass validation -->\n           <Geometry>\n             <ogc:PropertyName>the_geom</ogc:PropertyName></Geometry>\n           <Opacity>0.6</Opacity>\n           <ColorMap type=\"ramp\" >\n             <ColorMapEntry color=\"#FFFFFF\" quantity=\"0\" label=\"nodata\" \n               opacity=\"0\"/>\n             <ColorMapEntry color=\"#FFFFFF\" quantity=\"0.02\" label=\"nodata\" \n               opacity=\"0\"/>\n             <ColorMapEntry color=\"#4444FF\" quantity=\".1\" label=\"nodata\"/>\n             <ColorMapEntry color=\"#FF0000\" quantity=\".5\" label=\"values\" />\n             <ColorMapEntry color=\"#FFFF00\" quantity=\"1.0\" label=\"values\" />\n           </ColorMap>\n         </RasterSymbolizer>\n        </Rule>\n      </FeatureTypeStyle>\n    </UserStyle>\n  </NamedLayer>\n </StyledLayerDescriptor>\n

                                  Key aspects of the SLD are:

                                  • Lines 14-15 define the rendering transformation, using the process vec:Heatmap.
                                  • Lines 16-18 supply the input data parameter, named data in this process.
                                  • Lines 19-22 supply a value for the process's weightAttr parameter, which specifies the input attribute providing a weight for each data point.
                                  • Lines 23-29 supply the value for the radiusPixels parameter, which controls the \"spread\" of the heatmap around each point. In this SLD the value of this parameter may be supplied by a SLD substitution variable called radius, with a default value of 100 pixels.
                                  • Lines 30-33 supply the pixelsPerCell parameter, which controls the resolution at which the heatmap raster is computed.
                                  • Lines 34-38 supply the outputBBOX parameter, which is given the value of the standard SLD environment variable wms_bbox.
                                  • Lines 40-45 supply the outputWidth parameter, which is given the value of the standard SLD environment variable wms_width.
                                  • Lines 46-52 supply the outputHeight parameter, which is given the value of the standard SLD environment variable wms_height.
                                  • Lines 55-70 specify a RasterSymbolizer to style the computed raster surface. The symbolizer contains a ramped color map for the data range [0..1].
                                  • Line 58 specifies the geometry attribute of the input featuretype, which is necessary to pass SLD validation.

                                  This transformation styles a layer to produce a heatmap surface for the data in the requested map extent, as shown in the image below. (The map image also shows the original input data points styled by another SLD, as well as a base map layer.)

                                  "},{"location":"styling/sld/extensions/rendering-transform/#running-map-algebra-on-the-fly-using-jiffle","title":"Running map algebra on the fly using Jiffle","text":"

                                  The Jiffle rendering transformation allows to run map algebra on the bands of an input raster layer using the Jiffle language. For example, the following style computes the NDVI index from a 13 bands Sentinel 2 image, in which the red and NIR bands are the forth and eight bands (Jiffle band indexes are zero based), and then displays the resulting index with a color map:

                                  <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<StyledLayerDescriptor xmlns=\"http://www.opengis.net/sld\" xmlns:ogc=\"http://www.opengis.net/ogc\" xmlns:xlink=\"http://www.w3.org/1999/xlink\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xsi:schemaLocation=\"http://www.opengis.net/sld\nhttp://schemas.opengis.net/sld/1.0.0/StyledLayerDescriptor.xsd\" version=\"1.0.0\">\n  <NamedLayer>\n    <Name>Sentinel2 NDVI</Name>\n    <UserStyle>\n      <Title>NDVI</Title>\n      <FeatureTypeStyle>\n        <Transformation>\n          <ogc:Function name=\"ras:Jiffle\">\n            <ogc:Function name=\"parameter\">\n              <ogc:Literal>coverage</ogc:Literal>\n            </ogc:Function>\n            <ogc:Function name=\"parameter\">\n              <ogc:Literal>script</ogc:Literal>\n              <ogc:Literal>\n                nir = src[7];\n                vir = src[3];\n                dest = (nir - vir) / (nir + vir);\n              </ogc:Literal>\n            </ogc:Function>\n          </ogc:Function>\n        </Transformation>\n        <Rule>\n          <RasterSymbolizer>\n            <Opacity>1.0</Opacity>\n            <ColorMap>\n              <ColorMapEntry color=\"#000000\" quantity=\"-1\"/>\n              <ColorMapEntry color=\"#0000ff\" quantity=\"-0.75\"/>\n              <ColorMapEntry color=\"#ff00ff\" quantity=\"-0.25\"/>\n              <ColorMapEntry color=\"#ff0000\" quantity=\"0\"/>\n              <ColorMapEntry color=\"#ffff00\" quantity=\"0.5\"/>\n              <ColorMapEntry color=\"#00ff00\" quantity=\"1\"/>\n            </ColorMap>\n          </RasterSymbolizer>\n        </Rule>\n      </FeatureTypeStyle>\n    </UserStyle>\n  </NamedLayer>\n</StyledLayerDescriptor>\n

                                  Here are a view of the area, using the visible color bands:

                                  and then the display of the NDVI index computed with the above style:

                                  "},{"location":"styling/sld/extensions/rendering-transform/#group-candidate-selection","title":"Group candidate selection","text":"

                                  vec:GroupCandidateSelection is a Vector-to-Vector rendering transformation which filters a FeatureCollection according to the aggregate operation chosen (MIN or MAX) and the groups defined through attribute names. Given a feature collection, groups according to the defined grouping attributes, and returns the feature having the MIN or MAX value for the chosen attribute. One feature will be chosen for each group. The following SLD invokes the transformation:

                                  <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n    <sld:StyledLayerDescriptor xmlns:sld=\"http://www.opengis.net/sld\" xmlns=\"http://www.opengis.net/sld\" xmlns:st=\"http://www.stations.org/1.0\" xmlns:gml=\"http://www.opengis.net/gml\" xmlns:ogc=\"http://www.opengis.net/ogc\" xmlns:xlink=\"http://www.w3.org/1999/xlink\" version=\"1.0.0\">\n     <sld:UserLayer>\n     <sld:UserStyle>\n         <sld:Name>Default Styler</sld:Name>\n         <sld:Title>Default Styler</sld:Title>\n         <sld:FeatureTypeStyle>\n             <Transformation>\n                 <ogc:Function name=\"vec:GroupCandidateSelection\">\n                     <ogc:Function name=\"parameter\">\n                         <ogc:Literal>data</ogc:Literal>\n                     </ogc:Function>\n                     <ogc:Function name=\"parameter\">\n                         <ogc:Literal>operationAttribute</ogc:Literal>\n                         <ogc:Literal>st:numericAttribute</ogc:Literal>\n                     </ogc:Function>\n                     <ogc:Function name=\"parameter\">\n                         <ogc:Literal>aggregation</ogc:Literal>\n                         <ogc:Literal>MIN</ogc:Literal>\n                     </ogc:Function>\n                     <ogc:Function name=\"parameter\">\n                         <ogc:Literal>groupingAttributes</ogc:Literal>\n                         <ogc:Literal>st:inferredAttribute</ogc:Literal>\n                         <ogc:Literal>st:inferredAttribute2</ogc:Literal>\n                     </ogc:Function>\n                 </ogc:Function>\n             </Transformation>\n             <sld:rule>\n                 <sld:Title>Stations Selected Candidate</sld:Title>\n                 <sld:PointSymbolizer>\n                     <Stroke>\n                         <CssParameter name=\"stroke\">#000000</CssParameter>\n                     </Stroke>\n                 </sld:PointSymbolizer>\n             </sld:rule>\n         </sld:FeatureTypeStyle>\n     </sld:UserStyle>\n  </sld:UserLayer>\n</sld:StyledLayerDescriptor>\n

                                  Where st:numericAttribute, st:inferredAttribute and st:inferredAttribute2 are attributes of the current layer being rendered, in this case, a layer based complex features, having the attributes used for rendering in the http://www.stations.org/1.0 namespace.

                                  This vector process accepts four parameters:

                                  • data: the data on which perform the computation.
                                  • aggregation: the type of operation required to filter data (MIN or MAX).
                                  • operationAttribute: the xpath to the attribute whose value will be used to perform the MIN or MAX operation.
                                  • groupingAttributes: a lists of xpath pointing to the attributes defining the features' groups for which perform the filtering process.
                                  "},{"location":"styling/sld/extensions/rendering-transform/#disabling-getfeatureinfo-requests-results-transformation","title":"Disabling GetFeatureInfo requests results transformation","text":"

                                  By default GetFeatureInfo results are determined from the output after evaluating rendering transformation on the layer data. This behavior can be changed only for raster sources (i.e., raster-to-raster and raster-to-vector transformations). See section Disabling GetFeatureInfo requests results transformation to disable this behavior on a global or per virtual service basis. The WMS setting can be overridden for individual FeatureTypeStyle elements using the transformFeatureInfo SLD vendor option (either true or false).

                                  <VendorOption name=\"transformFeatureInfo\">true</VendorOption>\n
                                  "},{"location":"styling/sld/extensions/substitution/","title":"Variable substitution in SLD","text":"

                                  Variable substitution in SLD is a GeoServer extension (starting in version 2.0.2) that allows passing values from WMS requests into SLD styles. This allows dynamically setting values such as colors, fonts, sizes and filter thresholds.

                                  Variables are specified in WMS GetMap requests by using the env request parameter followed by a list of name:value pairs separated by semicolons:

                                  ...&env=name1:value1;name2=value2&...\n

                                  In an SLD the variable values are accessed using the env function. The function retrieves a substitution variable value specified in the current request:

                                  <ogc:Function name=\"env\">\n   <ogc:Literal>size</ogc:Literal>\n</ogc:Function>       \n

                                  A default value can be provided. It will be used if the variable was not specified in the request:

                                  <ogc:Function name=\"env\">\n   <ogc:Literal>size</ogc:Literal>\n   <ogc:Literal>6</ogc:Literal>\n</ogc:Function>  \n

                                  The env function can be used in an SLD anywhere an OGC expression is allowed. For example, it can be used in CSSParameter elements, in size and offset elements, and in rule filter expressions. It is also accepted in some places where full expressions are not allowed, such as in the Mark/WellKnownName element.

                                  "},{"location":"styling/sld/extensions/substitution/#predefined-variables","title":"Predefined Variables","text":"

                                  GeoServer has predefined variables which provide information about specific properties of the request output. These are useful when SLD parameters need to depend on output dimensions. The predefined variables are:

                                  Name Type Description

                                  wms_bbox ReferencedEnvelope the georeferenced extent of the request output

                                  wms_crs CoordinateReferenceSystem the definition of the output coordinate reference system

                                  wms_srs String the code for the output coordinate reference system

                                  wms_width Integer the width (in pixels) of the output image

                                  wms_height Integer the height (in pixels) of the output image

                                  wms_scale_denominator Integer the denominator of the output map scale

                                  kmlOutputMode Either vector or empty this variable gets set to vector when the kml generator is writing out vector features as placemarks, as opposed to ground overlays

                                  "},{"location":"styling/sld/extensions/substitution/#example","title":"Example","text":"

                                  The following SLD symbolizer has been parameterized in three places, with default values provided in each case:

                                  <PointSymbolizer>\n  <Graphic>\n    <Mark>\n      <WellKnownName><ogc:Function name=\"env\">\n            <ogc:Literal>name</ogc:Literal>\n            <ogc:Literal>square</ogc:Literal>\n         </ogc:Function>\n      </WellKnownName>\n      <Fill>\n        <CssParameter name=\"fill\">\n          #<ogc:Function name=\"env\">\n            <ogc:Literal>color</ogc:Literal>\n            <ogc:Literal>FF0000</ogc:Literal>\n         </ogc:Function>\n        </CssParameter>\n      </Fill>\n    </Mark>\n    <Size>\n       <ogc:Function name=\"env\">\n          <ogc:Literal>size</ogc:Literal>\n          <ogc:Literal>6</ogc:Literal>\n       </ogc:Function>\n    </Size>\n  </Graphic>\n</PointSymbolizer>\n

                                  Download the full SLD style

                                  When no variables are provided in the WMS request, the SLD uses the default values and renders the sample sf:bugsites dataset as shown:

                                  Default rendering

                                  If the request is changed to specify the following variable values:

                                  &env=color:00FF00;name:triangle;size:12\n

                                  the result is instead:

                                  Rendering with variables supplied

                                  "},{"location":"styling/sld/extensions/uom/","title":"Specifying symbolizer sizes in ground units","text":"

                                  The SLD 1.0 specification allows giving symbolizer sizes in a single unit of measure: pixels. This means that the size of symbolizers is the same at all zoom levels (which is usually the desired behaviour).

                                  The Symbology Encoding 1.1 specification provides a uom attribute on Symbolizer elements. This allows specifying styling parameter sizes in ground units of metres or feet, as well as the default which is screen pixels. When ground units are used, the screen size of styled elements increases as the map is zoomed in to larger scales. GeoServer supports the SE 1.1 uom attribute in its extended SLD 1.0 support.

                                  Note

                                  This extended feature is officially supported in GeoServer 2.1.0. It is available in GeoServer 2.0.3 if the -DenableDpiUomRescaling=true system variable is specified for the JVM.

                                  The value of the uom attribute is a URI indicating the desired unit. The units of measure supported are those given in the SE 1.1 specification:

                                  http://www.opengeospatial.org/se/units/metre\nhttp://www.opengeospatial.org/se/units/foot\nhttp://www.opengeospatial.org/se/units/pixel\n

                                  Note

                                  The px override modifier for parameters values is not currently supported.

                                  "},{"location":"styling/sld/extensions/uom/#example","title":"Example","text":"

                                  The following SLD shows the uom attribute used to specify the width of a LineSymbolizer in metres:

                                  <?xml version=\"1.0\" encoding=\"ISO-8859-1\"?>\n<StyledLayerDescriptor version=\"1.0.0\" xmlns=\"http://www.opengis.net/sld\" xmlns:ogc=\"http://www.opengis.net/ogc\"\n  xmlns:xlink=\"http://www.w3.org/1999/xlink\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\">\n  <NamedLayer>\n    <Name>5m blue line</Name>\n    <UserStyle>\n      <Title>tm blue line</Title>\n      <Abstract>Default line style, 5m wide blue</Abstract>\n\n      <FeatureTypeStyle>\n        <Rule>\n          <Title>Blue Line, 5m large</Title>\n          <LineSymbolizer uom=\"http://www.opengeospatial.org/se/units/metre\">\n            <Stroke>\n              <CssParameter name=\"stroke\">#0000FF</CssParameter>\n              <CssParameter name=\"stroke-width\">5</CssParameter>\n            </Stroke>\n          </LineSymbolizer>\n        </Rule>\n\n      </FeatureTypeStyle>\n    </UserStyle>\n  </NamedLayer>\n</StyledLayerDescriptor>\n

                                  Applying the style to the tiger:tiger_roads dataset shows how the line widths increase as the map is zoomed in:

                                  "},{"location":"styling/sld/extensions/composite-blend/","title":"Color compositing and color blending","text":"

                                  It is possible to perform color blending and compositing, either between feature type styles or by associating blending operations with each symbolizer.

                                  GeoServer implements most of the color compositing and blending modes suggested by the SVG compositing and blending level 1 specification. Either set of operations allows one to control how two overlapping layers/symbols are merged together to form a final map (as opposed to the normal behavior of just stacking images on top of each other).

                                  This section will use the following definitions for the common terms \"source\" and \"destination\":

                                  • Source : Image currently being painted on top of the map
                                  • Destination: Background image that the source image is being drawn on
                                  • Specifying compositing and blending in SLD
                                  • Composite and blending modes
                                  • Compositing and blending example
                                  "},{"location":"styling/sld/extensions/composite-blend/example/","title":"Compositing and blending example","text":"

                                  Let's say we want to draw the topp:states layer so that the polygons are not filled with the population keyed colors, but only an inner border inside the polygon should appear, leaving the internal fully transparent.

                                  This is the destination:

                                  topp:states layer

                                  Using alpha blending, this can be achieved by creating a mask around the state borders with a thick stroke, and then using a \"destination-in\" alpha compositing.

                                  This is the source (mask):

                                  Layer mask

                                  The SLD will contain three FeatureTypeStyles. The first one would be the standard rules (states colored by population) and the last one will contain the label rules. The second (middle) one is where the blending will occur:

                                  ...\n<FeatureTypeStyle>\n  <!-- Usual states rules, skipped for brevity -->\n</FeatureTypeStyle>\n<FeatureTypeStyle>\n  <Rule>\n    <LineSymbolizer>\n      <Stroke>\n        <CssParameter name=\"stroke-width\">10</CssParameter>\n        <CssParameter name=\"stroke\">#000000</CssParameter>\n      </Stroke>\n    </LineSymbolizer>\n  </Rule>\n  <VendorOption name=\"composite\">destination-in</VendorOption>\n</FeatureTypeStyle>\n<FeatureTypeStyle>\n  <!-- The label rules, skipped for brevity -->\n</FeatureTypeStyle>\n...\n

                                  This is the result of the composition:

                                  Now, if for example someone makes a WMS call in which the another layer is drawn below this one, the result will look like this:

                                  This other background layer is hardly visible, because it has been cut by the mask. This shows the risks of using alpha compositing without care in a WMS setting.

                                  In order to achieve the desired result no matter how the client composes the request, the first FeatureTypeStyle that draws the polygons (the states themselves) needs to be set as a compositing base, ensuring the mask will only be applied to it.

                                  <VendorOption name=\"composite-base\">true</VendorOption>\n

                                  The result will look like the following (though a multiply blend was added to the base to ensure a nice visual transparency effect on the border lines):

                                  Download the final style

                                  Note

                                  See the full list of available modes.

                                  "},{"location":"styling/sld/extensions/composite-blend/modes/","title":"Composite and blending modes","text":"

                                  There are two types of modes: alpha composite and color blending.

                                  Alpha compositing controls how two images are merged together by using the alpha levels of the two. No color mixing is being performed, only pure binary selection (either one or the other).

                                  Color blending modes mix the colors of source and destination in various ways. Each pixel in the result will be some sort of combination between the source and destination pixels.

                                  The following page shows the full list of available modes. (See the syntax page for more details.) To aid in comprehension, two source and two destination images will be used to show visually how each mode works:

                                  +-----------------------------------+-----------------------------------+ | Source 1 | Source 2 | +===================================+===================================+ | | | +-----------------------------------+-----------------------------------+

                                  +-----------------------------------+-----------------------------------+ | Destination 1 | Destination 2 | +===================================+===================================+ | | | +-----------------------------------+-----------------------------------+

                                  "},{"location":"styling/sld/extensions/composite-blend/modes/#alpha-compositing-modes","title":"Alpha compositing modes","text":""},{"location":"styling/sld/extensions/composite-blend/modes/#copy","title":"copy","text":"

                                  Only the source will be present in the output.

                                  +-----------------------------------+-----------------------------------+ | Example 1 | Example 2 | +===================================+===================================+ | | | +-----------------------------------+-----------------------------------+

                                  "},{"location":"styling/sld/extensions/composite-blend/modes/#destination","title":"destination","text":"

                                  Only the destination will be present in the output

                                  +------------------------------------+------------------------------------+ | Example 1 | Example 2 | +====================================+====================================+ | | | +------------------------------------+------------------------------------+

                                  "},{"location":"styling/sld/extensions/composite-blend/modes/#source-over","title":"source-over","text":"

                                  The source is drawn over the destination, and the destination is visible where the source is transparent. Opposite of destination-over.

                                  +------------------------------------+------------------------------------+ | Example 1 | Example 2 | +====================================+====================================+ | | | +------------------------------------+------------------------------------+

                                  "},{"location":"styling/sld/extensions/composite-blend/modes/#destination-over","title":"destination-over","text":"

                                  The source is drawn below the destination, and is visible only when the destination is transparent. Opposite of source-over.

                                  +-----------------------------------------+-----------------------------------------+ | Example 1 | Example 2 | +=========================================+=========================================+ | | | +-----------------------------------------+-----------------------------------------+

                                  "},{"location":"styling/sld/extensions/composite-blend/modes/#source-in","title":"source-in","text":"

                                  The source is visible only when overlapping some non-transparent pixel of the destination. This allows the background map to act as a mask for the layer/feature being drawn. Opposite of destination-in.

                                  +-----------------------------------+-----------------------------------+ | Example 1 | Example 2 | +===================================+===================================+ | | | +-----------------------------------+-----------------------------------+

                                  "},{"location":"styling/sld/extensions/composite-blend/modes/#destination-in","title":"destination-in","text":"

                                  The destination is retained only when overlapping some non transparent pixel in the source. This allows the layer/feature to be drawn to act as a mask for the background map. Opposite of source-in.

                                  +---------------------------------------+---------------------------------------+ | Example 1 | Example 2 | +=======================================+=======================================+ | | | +---------------------------------------+---------------------------------------+

                                  "},{"location":"styling/sld/extensions/composite-blend/modes/#source-out","title":"source-out","text":"

                                  The source is retained only in areas where the destination is transparent. This acts as a reverse mask when compared to source-in.

                                  +-----------------------------------+-----------------------------------+ | Example 1 | Example 2 | +===================================+===================================+ | | | +-----------------------------------+-----------------------------------+

                                  "},{"location":"styling/sld/extensions/composite-blend/modes/#destination-out","title":"destination-out","text":"

                                  The destination is retained only in areas where the source is transparent. This acts as a reverse mask when compared to destination-in.

                                  +----------------------------------------+----------------------------------------+ | Example 1 | Example 2 | +========================================+========================================+ | | | +----------------------------------------+----------------------------------------+

                                  "},{"location":"styling/sld/extensions/composite-blend/modes/#source-atop","title":"source-atop","text":"

                                  The destination is drawn fully, while the source is drawn only where it intersects the destination.

                                  +------------------------------------+------------------------------------+ | Example 1 | Example 2 | +====================================+====================================+ | | | +------------------------------------+------------------------------------+

                                  "},{"location":"styling/sld/extensions/composite-blend/modes/#destination-atop","title":"destination-atop","text":"

                                  The source is drawn fully, and the destination is drawn over the source and only where it intersects it.

                                  +-----------------------------------------+-----------------------------------------+ | Example 1 | Example 2 | +=========================================+=========================================+ | | | +-----------------------------------------+-----------------------------------------+

                                  "},{"location":"styling/sld/extensions/composite-blend/modes/#xor","title":"xor","text":"

                                  \"Exclusive Or\" mode. Each pixel is rendered only if either the source or the destination is not blank, but not both.

                                  +-----------------------------------+-----------------------------------+ | Example 1 | Example 2 | +===================================+===================================+ | | | +-----------------------------------+-----------------------------------+

                                  "},{"location":"styling/sld/extensions/composite-blend/modes/#color-blending-modes","title":"Color blending modes","text":""},{"location":"styling/sld/extensions/composite-blend/modes/#multiply","title":"multiply","text":"

                                  The source color is multiplied by the destination color and replaces the destination. The resulting color is always at least as dark as either the source or destination color. Multiplying any color with black results in black. Multiplying any color with white preserves the original color.

                                  +-----------------------------------+-----------------------------------+ | Example 1 | Example 2 | +===================================+===================================+ | | | +-----------------------------------+-----------------------------------+

                                  "},{"location":"styling/sld/extensions/composite-blend/modes/#screen","title":"screen","text":"

                                  Multiplies the complements of the source and destination color values, then complements the result. The end result color is always at least as light as either of the two constituent colors. Screening any color with white produces white; screening with black leaves the original color unchanged.

                                  The effect is similar to projecting multiple photographic slides simultaneously onto a single screen.

                                  +-----------------------------------+-----------------------------------+ | Example 1 | Example 2 | +===================================+===================================+ | | | +-----------------------------------+-----------------------------------+

                                  "},{"location":"styling/sld/extensions/composite-blend/modes/#overlay","title":"overlay","text":"

                                  Multiplies (screens) the colors depending on the destination color value. Source colors overlay the destination while preserving its highlights and shadows. The backdrop color is not replaced but is mixed with the source color to reflect the lightness or darkness of the backdrop.

                                  +-----------------------------------+-----------------------------------+ | Example 1 | Example 2 | +===================================+===================================+ | | | +-----------------------------------+-----------------------------------+

                                  "},{"location":"styling/sld/extensions/composite-blend/modes/#darken","title":"darken","text":"

                                  Selects the darker of the destination and source colors. The destination is replaced with the source only where the source is darker.

                                  +-----------------------------------+-----------------------------------+ | Example 1 | Example 2 | +===================================+===================================+ | | | +-----------------------------------+-----------------------------------+

                                  "},{"location":"styling/sld/extensions/composite-blend/modes/#lighten","title":"lighten","text":"

                                  Selects the lighter of the destination and source colors. The destination is replaced with the source only where the source is lighter.

                                  +-----------------------------------+-----------------------------------+ | Example 1 | Example 2 | +===================================+===================================+ | | | +-----------------------------------+-----------------------------------+

                                  "},{"location":"styling/sld/extensions/composite-blend/modes/#color-dodge","title":"color-dodge","text":"

                                  Brightens the destination color to reflect the source color. Drawing with black produces no changes.

                                  +------------------------------------+------------------------------------+ | Example 1 | Example 2 | +====================================+====================================+ | | | +------------------------------------+------------------------------------+

                                  "},{"location":"styling/sld/extensions/composite-blend/modes/#color-burn","title":"color-burn","text":"

                                  Darkens the destination color to reflect the source color. Drawing with white produces no change.

                                  +-----------------------------------+-----------------------------------+ | Example 1 | Example 2 | +===================================+===================================+ | | | +-----------------------------------+-----------------------------------+

                                  "},{"location":"styling/sld/extensions/composite-blend/modes/#hard-light","title":"hard-light","text":"

                                  Multiplies or screens the colors, depending on the source color value. The effect is similar to shining a harsh spotlight on the destination.

                                  +-----------------------------------+-----------------------------------+ | Example 1 | Example 2 | +===================================+===================================+ | | | +-----------------------------------+-----------------------------------+

                                  "},{"location":"styling/sld/extensions/composite-blend/modes/#soft-light","title":"soft-light","text":"

                                  Darkens or lightens the colors, depending on the source color value. The effect is similar to shining a diffused spotlight on the destination.

                                  +-----------------------------------+-----------------------------------+ | Example 1 | Example 2 | +===================================+===================================+ | | | +-----------------------------------+-----------------------------------+

                                  "},{"location":"styling/sld/extensions/composite-blend/modes/#difference","title":"difference","text":"

                                  Subtracts the darker of the two constituent colors from the lighter color. White inverts the destination color; black produces no change.

                                  +-----------------------------------+-----------------------------------+ | Example 1 | Example 2 | +===================================+===================================+ | | | +-----------------------------------+-----------------------------------+

                                  "},{"location":"styling/sld/extensions/composite-blend/modes/#exclusion","title":"exclusion","text":"

                                  Produces an effect similar to that of difference but lower in contrast. White inverts the destination color; black produces no change.

                                  +-----------------------------------+-----------------------------------+ | Example 1 | Example 2 | +===================================+===================================+ | | | +-----------------------------------+-----------------------------------+

                                  "},{"location":"styling/sld/extensions/composite-blend/syntax/","title":"Specifying compositing and blending in SLD","text":""},{"location":"styling/sld/extensions/composite-blend/syntax/#composites","title":"Composites","text":"

                                  Both compositing and blending can be specified in SLD by adding the following VendorOption to either the end of a Symbolizer or FeatureTypeStyle:

                                  <VendorOption name=\"composite\">multiply</VendorOption>        \n

                                  In case a custom opacity is desired, it can be added after the operation name separated with a comma:

                                  <VendorOption name=\"composite\">multiply, 0.5</VendorOption>\n

                                  Note

                                  See the full list of available modes.

                                  Warning

                                  Blending against symbolizers causes exceptions inside the JDK when using OpenJDK. The issue is known and has been reportedly fixed, but only in OpenJDK 9.

                                  One way to get around this issue with OpenJDK \u215e is to install the Marlin renderer. This replaces the OpenJDK core renderer and does not suffer from the same issue.

                                  Oracle JDK 7 or 8 does not show this issue.

                                  "},{"location":"styling/sld/extensions/composite-blend/syntax/#composite-bases","title":"Composite bases","text":"

                                  For FeatureTypeStyles an additional vendor option can be added to control compositing groups:

                                  <VendorOption name=\"composite-base\">true</VendorOption>\n

                                  This will tell the rendering engine to use that FeatureTypeStyle as the destination, and will compose all subsequent FeatureTypeStyle/Layers on top of it, until another base is found. Once the full set of layers against a base is composed, then the base itself will be composed against the next set of composed layers, using its own compositing operator, if present.

                                  Without this setting, the destination will be the full stack of all previous FeatureTypeStyles and layers drawn before the current one. This can be limiting for two reasons:

                                  • It limits the usefulness of alpha-composite masking operations
                                  • It breaks the WMS model, where the client can decide freely how to stack layers (the desired compositing effects will be achieved only when a certain stack of layers is used)

                                  Consider the following example:

                                  In this example, the first two layers are drawn on top of each other, forming \"Merge1\".

                                  The third layer is a composite base, as such it won't be merged on top of the already drawn map immediately, but it will be drawn to an off-screen buffer, and layer 4 and 5 will be drawn/composited on top of it. Once that happens, \"Merge2\" is ready, and gets drawn on top of \"Merge1\",

                                  The next layer is another base, so \"Base2\" will be again drawn to an off-screen buffer, and layer 7 and 8 will be drawn/composited on top of it, forming Merge3. Once Merge3 is ready, it will be drawn/composited on top of the already fused Merge1/Merge2, generating the final map.

                                  "},{"location":"styling/sld/extensions/z-order/","title":"Z ordering features within and across feature types and layers","text":"

                                  Starting with GeoServer 2.8.0 it is possible to control the order in which the features are being loaded and painted on the map, thus replicating the same above/below relationships found in the reality.

                                  • Enabling z-ordering in a single FeatureTypeStyle
                                  • Z ordering single layer example
                                  "},{"location":"styling/sld/extensions/z-order/example/","title":"Z ordering single layer example","text":"

                                  The OpenStreetMap dataset uses extensively a z_order attribute to model the above/below relationships between elements in the real world.

                                  A small downloadable shapefile is provided that shows a small area with a rich set of different z-orders, where roads and rails go above and below each other. For reference, this is the dataset schema:

                                  Name Type Notes

                                  osm_id numeric

                                  type string The type of the segment, can be \"mainroads\", \"minorroads\", \"railways\", ...

                                  bridge numeric 0 or 1

                                  ref numeric 0 or 1

                                  tunnel numeric

                                  oneway numeric 0 or 1

                                  z_order numeric

                                  class string

                                  The dataset contains several different values for z_order, in particular: -10, -7, -5, -3, -1, 0, 3, 4, 5, 7, 9, 10, 13, 14, 15, 17, 19.

                                  Here is a sample CSS style using z-ordering, but not groups, to perform the display. Road casing is achieved by multiple FeatureTypeStyle, or z-index values in CSS:

                                  [class = 'railways' and bridge = 1] {\n  stroke: #333333;\n  stroke-width: 8;\n  z-index: 0;\n}\n\n[class = 'minorroads'] {\n  stroke: #a69269;\n  stroke-width: 3;\n  z-index: 0;\n}\n\n[class = 'mainroads'] {\n  stroke: #ff0000;\n  stroke-width: 5;\n  z-index: 0;\n}\n\n[class = 'motorways'] {\n  stroke: #990000;\n  stroke-width: 8;\n  z-index: 0;\n}\n\n[class = 'railways' and bridge = 1] {\n  stroke: #ffffff;\n  stroke-width: 6;\n  z-index: 1;\n}\n\n[class = 'railways'] {\n  stroke: #333333;\n  stroke-width: 3;\n  z-index: 2;\n}\n\n[class = 'railways'] {\n  stroke: #ffffff;\n  stroke-width: 1.5;\n  stroke-dasharray: 5, 5;\n  z-index: 3;\n}\n\n[class = 'motorways'] {\n  stroke: #ff6666;\n  stroke-width: 6;\n  stroke-linecap: round;\n  z-index: 3;\n}\n\n[class = 'minorroads'] {\n  stroke: #ffffff;\n  stroke-width: 2,5;\n  stroke-linecap: round;\n  z-index: 3;\n}\n\n[class = 'mainroads'] {\n  stroke: #ff9999;\n  stroke-width: 4;\n  stroke-linecap: round;\n  z-index: 3;\n}\n\n* {\n sort-by: \"z_order\";\n}\n

                                  The sorting is achieved by using the sort-by property, which translates into a sortBy VendorOption in SLD. A full equivalent SLD is available for download.

                                  This is the resulting map:

                                  As one can see, there are evident issues:

                                  • Roads and rails are not showing any evident z-ordering, in fact, all rails are below roads, but their dashed white center shows a mix of below and above roads
                                  • The rails bridges (depicted with a third thicker line around the rail symbol) are consistently below some other road or rail, while they should be above.

                                  This is mostly happening because the various FeatureTypeStyle elements are not put doctor in a single group.

                                  A slight change in the CSS, grouping all levels in the same sortByGroup, solves the issues above:

                                  [class = 'railways' and bridge = 1] {\n  stroke: #333333;\n  stroke-width: 8;\n  z-index: 0;\n}\n\n[class = 'minorroads'] {\n  stroke: #a69269;\n  stroke-width: 3;\n  z-index: 0;\n}\n\n[class = 'mainroads'] {\n  stroke: #ff0000;\n  stroke-width: 5;\n  z-index: 0;\n}\n\n[class = 'motorways'] {\n  stroke: #990000;\n  stroke-width: 8;\n  z-index: 0;\n}\n\n[class = 'railways' and bridge = 1] {\n  stroke: #ffffff;\n  stroke-width: 6;\n  z-index: 1;\n}\n\n[class = 'railways'] {\n  stroke: #333333;\n  stroke-width: 3;\n  z-index: 2;\n}\n\n[class = 'railways'] {\n  stroke: #ffffff;\n  stroke-width: 1.5;\n  stroke-dasharray: 5, 5;\n  z-index: 3;\n}\n\n[class = 'motorways'] {\n  stroke: #ff6666;\n  stroke-width: 6;\n  stroke-linecap: round;\n  z-index: 3;\n}\n\n[class = 'minorroads'] {\n  stroke: #ffffff;\n  stroke-width: 2,5;\n  stroke-linecap: round;\n  z-index: 3;\n}\n\n[class = 'mainroads'] {\n  stroke: #ff9999;\n  stroke-width: 4;\n  stroke-linecap: round;\n  z-index: 3;\n}\n\n* {\n sort-by: \"z_order\";\n sort-by-group: \"roadsGroup\";\n}\n

                                  A full equivalent SLD is also available for download.

                                  The result now shows proper z-ordering:

                                  "},{"location":"styling/sld/extensions/z-order/syntax/","title":"Enabling z-ordering in a single FeatureTypeStyle","text":"

                                  The z-ordering is implemented as a new FeatureTypeStyle vendor option, sortBy, which controls in which order the features are extracted from the data source, and thus painted. The sortBy syntax is the same as the WFS one, that is, a list of comma separated field names, with an optional direction modifier (ascending being the default):

                                  field1 [A|D], field2 [A|D], ... , fieldN [A|D]\n

                                  Some examples:

                                  • \"z\": sorts the features based on the z field, ascending (lower z values are painted first, higher later)
                                  • \"cat,z D\": sorts the features on the cat attribute, with ascending order, and for those that have the same cat value, the sorting is on descending z
                                  • \"cat D,z D\": sorts the features on the cat attribute, with descending order, and for those that have the same cat value, the sorting is on descending z

                                  So, if we wanted to order features based on a single \"elevation\" attribute we'd be using the following SLD snippet:

                                  ...\n<sld:FeatureTypeStyle>\n  <sld:Rule>\n    ...\n    <!-- filters and symbolizers here -->\n    ...\n  </sld:Rule>\n  <sld:VendorOption name=\"sortBy\">elevation</sld:VendorOption>\n</sld:FeatureTypeStyle>\n...\n
                                  "},{"location":"styling/sld/extensions/z-order/syntax/#z-ordering-across-featuretypestyle","title":"z-ordering across FeatureTypeStyle","text":"

                                  It is a common need to perform road casing against a complex road network, which can have its own z-ordering needs (e.g., over and under passes). Casing is normally achieved by using two separate two FeatureTypeStyle, one drawing a thick line, one drawing a thin one.

                                  Let's consider a simple data set, made of just three roads:

                                  _=geom:LineString:404000,z:int\nLine.1=LINESTRING(0 4, 10 4)|1\nLine.2=LINESTRING(0 6, 10 6)|3\nLine.3=LINESTRING(7 0, 7 10)|1\n

                                  Adding a \"sortBy\" rule to both FeatureTypeStyle objects will achieve no visible result:

                                  <?xml version=\"1.0\" encoding=\"ISO-8859-1\"?>\n<StyledLayerDescriptor version=\"1.0.0\"\n  xsi:schemaLocation=\"http://www.opengis.net/sld StyledLayerDescriptor.xsd\"\n  xmlns=\"http://www.opengis.net/sld\" xmlns:ogc=\"http://www.opengis.net/ogc\"\n  xmlns:xlink=\"http://www.w3.org/1999/xlink\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\">\n  <!-- a named layer is the basic building block of an sld document -->\n\n  <NamedLayer>\n    <UserStyle>\n      <FeatureTypeStyle>\n        <Rule>\n          <LineSymbolizer>\n            <Stroke>\n              <CssParameter name=\"stroke\">#FF0000</CssParameter>\n              <CssParameter name=\"stroke-width\">8</CssParameter>\n            </Stroke>\n          </LineSymbolizer>\n        </Rule>\n        <sld:VendorOption name=\"sortBy\">z</sld:VendorOption>\n      </FeatureTypeStyle>\n      <FeatureTypeStyle>\n        <Rule>\n          <LineSymbolizer>\n            <Stroke>\n              <CssParameter name=\"stroke\">#FFFFFF</CssParameter>\n              <CssParameter name=\"stroke-width\">6</CssParameter>\n            </Stroke>\n          </LineSymbolizer>\n        </Rule>\n        <sld:VendorOption name=\"sortBy\">z</sld:VendorOption>\n      </FeatureTypeStyle>\n    </UserStyle>\n  </NamedLayer>\n</StyledLayerDescriptor>\n

                                  The result will be the following:

                                  This is happening because while the roads are loaded in the right order, Line.1,Line.3,Line.2, they are all painted with the tick link first, and then the code will start over, and paint them all with the thin line.

                                  In order to get both casing and z-ordering to work a new vendor option, sortByGroup, needs to be added to both FeatureTypeStyle, grouping them in a single z-ordering paint.

                                  <?xml version=\"1.0\" encoding=\"ISO-8859-1\"?>\n<StyledLayerDescriptor version=\"1.0.0\"\n  xsi:schemaLocation=\"http://www.opengis.net/sld StyledLayerDescriptor.xsd\"\n  xmlns=\"http://www.opengis.net/sld\" xmlns:ogc=\"http://www.opengis.net/ogc\"\n  xmlns:xlink=\"http://www.w3.org/1999/xlink\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\">\n  <!-- a named layer is the basic building block of an sld document -->\n\n  <NamedLayer>\n    <UserStyle>\n      <FeatureTypeStyle>\n        <Rule>\n          <LineSymbolizer>\n            <Stroke>\n              <CssParameter name=\"stroke\">#FF0000</CssParameter>\n              <CssParameter name=\"stroke-width\">8</CssParameter>\n            </Stroke>\n          </LineSymbolizer>\n        </Rule>\n        <sld:VendorOption name=\"sortBy\">z</sld:VendorOption>\n        <sld:VendorOption name=\"sortByGroup\">roads</sld:VendorOption>\n      </FeatureTypeStyle>\n      <FeatureTypeStyle>\n        <Rule>\n          <LineSymbolizer>\n            <Stroke>\n              <CssParameter name=\"stroke\">#FFFFFF</CssParameter>\n              <CssParameter name=\"stroke-width\">6</CssParameter>\n            </Stroke>\n          </LineSymbolizer>\n        </Rule>\n        <sld:VendorOption name=\"sortBy\">z</sld:VendorOption>\n        <sld:VendorOption name=\"sortByGroup\">roads</sld:VendorOption>\n      </FeatureTypeStyle>\n    </UserStyle>\n  </NamedLayer>\n</StyledLayerDescriptor>\n

                                  The result will be the following:

                                  When grouping is used, the code will first paint Line.1,Line3 with the thick line, then track back and paint them with the thin line, then move to paint Line.2 with the thick line, and finally Line.2 with the thin line, achieving the desired result.

                                  "},{"location":"styling/sld/extensions/z-order/syntax/#z-ordering-across-layers","title":"z-ordering across layers","text":"

                                  Different layers, such for example roads and rails, can have their features z-ordered together by putting all the FeatureTypeStyle in their styles in the same sortByGroup, provided the following conditions are met:

                                  • The layers are side by side in the WMS request/layer group. In other words, the z-ordering allows to break the WMS specified order only if the layers are directly subsequent in the request. This can be extended to any number of layers, provided the progression of FeatureTypeStyle in the same group is not broken
                                  • There is no FeatureTypeStyle in the layer style that's breaking the sequence

                                  Let's consider an example, with a rails layer having two FeatureTypeStyle, one with a group, the other not:

                                  FeatureTypeStyle id SortByGroup id

                                  rails1 linework

                                  rails2 none

                                  We then have a roads layer with two FeatureTypeStyle, both in the same group:

                                  FeatureTypeStyle id SortByGroup id

                                  road1 linework

                                  road2 linework

                                  If the WMS request asks for &layers=roads,rails, then the expanded FeatureTypeStyle list will be:

                                  FeatureTypeStyle id SortByGroup id

                                  road1 linework

                                  road2 linework

                                  rails1 linework

                                  rails2 none

                                  As a result, the road1,road2,rails1 will form a single group, and this will result in the rails be merged with the roads when z-ordering.

                                  If instead the WMS request asks for &layers=rails,roads````, then the expanded ````FeatureTypeStyle` list will be:

                                  FeatureTypeStyle id SortByGroup id

                                  rails1 linework

                                  rails2 none

                                  road1 linework

                                  road2 linework

                                  The rails2 feature type style breaks the sequence, as a result, the rails will not be z-ordered in the same group as the roads.

                                  "},{"location":"styling/sld/reference/","title":"SLD Reference","text":"

                                  The OGC Styled Layer Descriptor (SLD) standard defines a language for expressing styling of geospatial data. GeoServer uses SLD as its primary styling language.

                                  SLD 1.0.0 is defined in the following specification:

                                  • OGC Styled Layer Descriptor Implementation Specification, Version 1.0.0

                                  Subsequently the functionality of SLD has been split into two specifications:

                                  • OGC Symbology Encoding Implementation Specification, Version 1.1.0
                                  • OGC Styled Layer Descriptor profile of the Web Map Service Implementation Specification, Version 1.1.0

                                  GeoServer implements the SLD 1.0.0 standard, as well as some parts of the SE 1.1.0 and WMS-SLD 1.1.0 standards.

                                  Elements of SLD

                                  The following sections describe the SLD elements implemented in GeoServer.

                                  The root element for an SLD is <StyledLayerDescriptor>. It contains a Layers and Styles elements which describe how a map is to be composed and styled.

                                  • StyledLayerDescriptor
                                  • Layers
                                  • Styles

                                  Styles contain Rules and Filters to determine sets of features to be styled with specific symbology. Rules may also specify the scale range in which the feature styling is visible.

                                  • Rules
                                  • Filters

                                  Rules contain Symbolizers to specify how features are styled. There are 5 types of symbolizers:

                                  • PointSymbolizer, which styles features as points
                                  • LineSymbolizer, which styles features as lines
                                  • PolygonSymbolizer, which styles features as polygons
                                  • TextSymbolizer, which styles text labels for features
                                  • RasterSymbolizer, which styles raster coverages

                                  Each symbolizer type has its own parameters to control styling.

                                  • PointSymbolizer
                                  • LineSymbolizer
                                  • PolygonSymbolizer
                                  • TextSymbolizer
                                  • Labeling
                                  • RasterSymbolizer
                                  "},{"location":"styling/sld/reference/filters/","title":"Filters","text":"

                                  A filter is the mechanism in SLD for specifying conditions. They are similar in functionality to the SQL \"WHERE\" clause. Filters are used within Rules to determine which styles should be applied to which features in a data set. The filter language used by SLD follows the OGC Filter Encoding standard. It is described in detail in the Filter Encoding Reference.

                                  A filter condition is specified by using a comparison operator or a spatial operator, or two or more of these combined by logical operators. The operators are usually used to compare properties of the features being filtered to other properties or to literal data.

                                  "},{"location":"styling/sld/reference/filters/#comparison-operators","title":"Comparison operators","text":"

                                  Comparison operators are used to specify conditions on the non-spatial attributes of a feature. The following binary comparison operators are available:

                                  • <PropertyIsEqualTo>
                                  • <PropertyIsNotEqualTo>
                                  • <PropertyIsLessThan>
                                  • <PropertyIsLessThanOrEqualTo>
                                  • <PropertyIsGreaterThan>
                                  • <PropertyIsGreaterThanOrEqualTo>

                                  These operators contain two filter expressions to be compared. The first operand is often a <PropertyName>, but both operands may be any expression, function or literal value.

                                  Binary comparison operators may include a matchCase attribute with the value true or false. If this attribute is true (which is the default), string comparisons are case-sensitive. If the attribute is specified and has the value false strings comparisons do not check case.

                                  Other available value comparison operators are:

                                  • <PropertyIsLike>
                                  • <PropertyIsNull>
                                  • <PropertyIsBetween>

                                  <PropertyIsLike> matches a string property value against a text pattern. It contains a <PropertyName> element containing the name of the property containing the string to be matched and a <Literal> element containing the pattern. The pattern is specified by a sequence of regular characters and three special pattern characters. The pattern characters are defined by the following required attributes of the <PropertyIsLike> element:

                                  • wildCard specifies a pattern character which matches any sequence of zero or more characters
                                  • singleChar specifies a pattern character which matches any single character
                                  • escapeChar specifies an escape character which can be used to escape these pattern characters

                                  <PropertyIsNull> tests whether a property value is null. It contains a single <PropertyName> element containing the name of the property containing the value to be tested.

                                  <PropertyIsBetween> tests whether an expression value lies within a range. It contains a filter expression providing the value to test, followed by the elements <LowerBoundary> and <UpperBoundary>, each containing a filter expression.

                                  "},{"location":"styling/sld/reference/filters/#examples","title":"Examples","text":"
                                  • The following filter selects features whose NAME attribute has the value of \"New York\":
                                  <PropertyIsEqualTo>\n   <PropertyName>NAME</PropertyName>\n   <Literal>New York</Literal>\n</PropertyIsEqualTo>\n
                                  • The following filter selects features whose geometry area is greater than 1,000,000:
                                  <PropertyIsGreaterThan>\n   <ogc:Function name=\"area\"> \n     <PropertyName>GEOMETRY</PropertyName>\n   </ogc:Function>\n   <Literal>1000000</Literal>\n</PropertyIsGreaterThan>\n
                                  "},{"location":"styling/sld/reference/filters/#spatial-operators","title":"Spatial operators","text":"

                                  Spatial operators are used to specify conditions on the geometric attributes of a feature. The following spatial operators are available:

                                  Topological Operators

                                  These operators test topological spatial relationships using the standard OGC Simple Features predicates:

                                  • <Intersects>
                                  • <Equals>
                                  • <Disjoint>
                                  • <Touches>
                                  • <Within>
                                  • <Overlaps>
                                  • <Crosses>
                                  • <Contains>

                                  The content for these operators is a <PropertyName> element for a geometry-valued property and a GML geometry literal.

                                  Distance Operators

                                  These operators compute distance relationships between geometries:

                                  • <DWithin>
                                  • <Beyond>

                                  The content for these elements is a <PropertyName> element for a geometry-valued property, a GML geometry literal, and a <Distance> element containing the value for the distance tolerance. The <Distance> element may include an optional units attribute.

                                  Bounding Box Operator

                                  This operator tests whether a feature geometry attribute intersects a given bounding box:

                                  • <BBOX>

                                  The content is an optional <PropertyName> element, and a GML envelope literal. If the PropertyName is omitted the default geometry attribute is assumed.

                                  "},{"location":"styling/sld/reference/filters/#examples_1","title":"Examples","text":"
                                  • The following filter selects features with a geometry that intersects the point (1,1):
                                  <Intersects>\n   <PropertyName>GEOMETRY</PropertyName>\n   <Literal>\n      <gml:Point>\n         <gml:coordinates>1 1</gml:coordinates>\n      </gml:Point>\n   </Literal>\n</Intersects>\n
                                  • The following filter selects features with a geometry that intersects the box [-10,0 : 10,10]:
                                  <ogc:BBOX>\n  <ogc:PropertyName>GEOMETRY</ogc:PropertyName>\n  <gml:Box srsName=\"urn:x-ogc:def:crs:EPSG:4326\">\n    <gml:coord>\n      <gml:X>-10</gml:X> <gml:Y>0</gml:Y>\n    </gml:coord>\n    <gml:coord>\n      <gml:X>10</gml:X> <gml:Y>10</gml:Y>\n    </gml:coord>\n  </gml:Box>\n</ogc:BBOX>\n
                                  "},{"location":"styling/sld/reference/filters/#logical-operators","title":"Logical operators","text":"

                                  Logical operators are used to create logical combinations of other filter operators. They may be nested to any depth. The following logical operators are available:

                                  • <And>
                                  • <Or>
                                  • <Not>

                                  The content for <And> and <Or> is two filter operator elements. The content for <Not> is a single filter operator element.

                                  "},{"location":"styling/sld/reference/filters/#examples_2","title":"Examples","text":"
                                  • The following filter uses <And> to combine a comparison operator and a spatial operator:
                                  <And>\n   <PropertyIsEqualTo>\n      <PropertyName>NAME</PropertyName>\n      <Literal>New York</Literal>\n   </PropertyIsEqualTo>\n   <Intersects>\n      <PropertyName>GEOMETRY</PropertyName>\n      <Literal>\n         <gml:Point>\n             <gml:coordinates>1 1</gml:coordinates>\n         </gml:Point>\n      </Literal>\n   </Intersects>\n</And>\n
                                  "},{"location":"styling/sld/reference/filters/#sld_filter_expression","title":"Filter Expressions","text":"

                                  Filter expressions allow performing computation on data values. The following elements can be used to form expressions.

                                  Arithmetic Operators

                                  These operators perform arithmetic on numeric values. Each contains two expressions as sub-elements.

                                  • <Add>
                                  • <Sub>
                                  • <Mul>
                                  • <Div>

                                  Functions

                                  The <Function> element specifies a filter function to be evaluated. The name attribute gives the function name. The element contains a sequence of zero or more filter expressions providing the function arguments. See the Filter Function Reference for details of the functions provided by GeoServer.

                                  Feature Property Values

                                  The <PropertyName> element allows referring to the value of a given feature attribute. It contains a string specifying the attribute name.

                                  Literals

                                  The <Literal> element allows specifying constant values of numeric, boolean, string, date or geometry type.

                                  "},{"location":"styling/sld/reference/labeling/","title":"Labeling","text":"

                                  This section discusses the details of controlling label placement via the standard SLD options. It also describes a number of GeoServer enhanced options for label placement that provide better cartographic output.

                                  "},{"location":"styling/sld/reference/labeling/#labelplacement","title":"LabelPlacement","text":"

                                  The SLD specification defines two alternative label placement strategies which can be used in the <LabelPlacement> element:

                                  • <PointPlacement> places labels at a single point
                                  • <LinePlacement> places labels along a line
                                  "},{"location":"styling/sld/reference/labeling/#pointplacement","title":"PointPlacement","text":"

                                  When <PointPlacement> is used the geometry is labelled at a single label point. For lines, this point lies at the middle of the visible portion of the line. For polygons, the point is the centroid of the visible portion of the polygon. The position of the label relative to the label point can be controlled by the following sub-elements:

                                  Element Description

                                  <AnchorPoint> Determines the placement of the label relative to the label point. Values given as decimals between 0-1.

                                  <Displacement> Offsets the label from the anchor point. Values given in pixels.

                                  <Rotation> Rotates the label clockwise by a given number of degrees.

                                  The best way to explain these options is with examples.

                                  "},{"location":"styling/sld/reference/labeling/#anchorpoint","title":"AnchorPoint","text":"

                                  The anchor point determines where the label is placed relative to the label point.

                                  <AnchorPoint>\n  <AnchorPointX>\n    0.5\n  </AnchorPointX>\n  <AnchorPointY>\n    0.5\n  </AnchorPointY>\n</AnchorPoint>\n

                                  The anchor point values---listed here as (X, Y) ordered pairs---are specified relative to the bounding box of the label, with values from 0 to 1 inclusive. For example:

                                  • (Default) Bottom left of the box is (0, 0)
                                  • Top right is (1, 1)
                                  • Center is (0.5, 0.5)

                                  So to have the anchor location centered just below the label (label top-centered), use (0.5, 0):

                                  <AnchorPoint>\n  <AnchorPointX>\n    0.5\n  </AnchorPointX>\n  <AnchorPointY>\n    0\n  </AnchorPointY>\n</AnchorPoint>\n

                                  The following examples show how changing the anchor point affects the position of labels:

                                  (0, 0.5) places the label to the right of the label point

                                  (0.5, 0.5) places the center of the label at the label point

                                  (1, 0.5) places the label to the left of the label point

                                  (0.5, 0) places the label horizontally centered above the label point

                                  "},{"location":"styling/sld/reference/labeling/#displacement","title":"Displacement","text":"

                                  Displacement allows fine control of the placement of the label. The displacement values offset the location of the label from the anchor point by a specified number of pixels. The element syntax is:

                                  <Displacement>\n  <DisplacementX>\n     10\n  </DisplacementX>\n  <DisplacementY>\n      0\n  </DisplacementY>\n</Displacement>\n

                                  Examples:

                                  Displacement of X=10 pixels (compare with default anchor point of (X=0, Y=0.5) shown above)

                                  Displacement of Y=-10 pixels (compare with anchor point (X= 0.5, Y=1.0) - not shown)

                                  "},{"location":"styling/sld/reference/labeling/#rotation","title":"Rotation","text":"

                                  The optional <Rotation> element specifies that labels should be rotated clockwise by a given number of degrees

                                  <Rotation>\n  45\n</Rotation>\n

                                  The examples below show how the rotation interacts with anchor points and displacements.

                                  45 degree rotation

                                  45 degree rotation with anchor point (X=0.5, Y=0.5)

                                  45 degree rotation with 40-pixel X displacement

                                  45 degree rotation with 40-pixel Y displacement with anchor point (X=0.5, Y=0.5)

                                  "},{"location":"styling/sld/reference/labeling/#lineplacement","title":"LinePlacement","text":"

                                  To label linear features (such as a road or river), the <LinePlacement> element can be specified. This indicates that the styler should determine the best placement and rotation for the labels along the lines.

                                  The standard SLD LinePlacement element provides one optional sub-element, <PerpendicularOffset>. GeoServer provides much more control over line label placement via vendor-specific options; see below for details.

                                  "},{"location":"styling/sld/reference/labeling/#perpendicularoffset","title":"PerpendicularOffset","text":"

                                  The optional <PerpendicularOffset> element allows you to position a label above or below a line. (This is similar to the <DisplacementY> for label points described above.) The displacement value is specified in pixels. A positive value displaces upwards, a negative value downwards.

                                  <LabelPlacement>\n  <LinePlacement>\n    <PerpendicularOffset>\n       10\n    </PerpendicularOffset>           \n  </LinePlacement>\n</LabelPlacement>\n

                                  Examples:

                                  PerpendicularOffset = 0 (default)

                                  PerpendicularOffset = 10

                                  "},{"location":"styling/sld/reference/labeling/#composing-labels-from-multiple-attributes","title":"Composing labels from multiple attributes","text":"

                                  The <Label> element in <TextSymbolizer> allows mixed content. This means its content can be a mixture of plain text and Filter Expressions. The mix gets interepreted as a concatenation. You can leverage this to create complex labels out of multiple attributes.

                                  For example, if you want both a state name and its abbreviation to appear in a label, you can do the following:

                                  <Label>\n  <ogc:PropertyName>STATE_NAME</ogc:PropertyName> (<ogc:PropertyName>STATE_ABBR</ogc:PropertyName>)\n</Label>\n

                                  and you'll get a label looking like Texas (TX).

                                  If you need to add extra white space or newline, you'll stumble into an XML oddity. The whitespace handling in the Label element is following a XML rule called \"collapse\", in which all leading and trailing whitespaces have to be removed, whilst all whitespaces (and newlines) in the middle of the xml element are collapsed into a single whitespace.

                                  So, what if you need to insert a newline or a sequence of two or more spaces between your property names? Enter CDATA. CDATA is a special XML section that has to be returned to the interpreter as-is, without following any whitespace handling rule. So, for example, if you wanted to have the state abbreviation sitting on the next line you'd use the following:

                                  <Label>\n  <ogc:PropertyName>STATE_NAME</ogc:PropertyName><![CDATA[\n]]>(<ogc:PropertyName>STATE_ABBR</ogc:PropertyName>)\n</Label>\n
                                  "},{"location":"styling/sld/reference/labeling/#geoserver-enhanced-options","title":"GeoServer Enhanced Options","text":"

                                  GeoServer provides a number of label styling options as extensions to the SLD specification. Using these options gives more control over how the map looks, since the SLD standard isn't expressive enough to provide all the options one might want.

                                  These options are specified as subelements of <TextSymbolizer>.

                                  "},{"location":"styling/sld/reference/labeling/#labeling_priority","title":"Priority Labeling","text":"

                                  The optional <Priority> element allows specifying label priority. This controls how conflicts (overlaps) between labels are resolved during rendering. The element content may be an expression to retrieve or calculate a relative priority value for each feature in a layer. Alternatively, the content may be a constant value, to set the priority of a layer's labels relative to other layers on a rendered map.

                                  The default priority for labels is 1000.

                                  Note

                                  Standard SLD Conflict Resolution

                                  If the <Priority> element is not present, or if a group of labels all have the same priority, then standard SLD label conflict resolution is used. Under this strategy, the label to display out of a group of conflicting labels is chosen essentially at random.

                                  For example, take the following dataset of cities:

                                  City Name   | population\n------------+------------\nYonkers     |     197,818\nJersey City |     237,681\nNewark      |     280,123\nNew York    |   8,107,916\n

                                  City locations (large scale map)

                                  More people know where New York City is than where Jersey City is. Thus we want to give the label \"New York\" priority so it will be visible when in conflict with (overlapping) \"Jersey City\". To do this we include the following code in the <TextSymbolizer>:

                                  <Priority>\n    <ogc:PropertyName>population</ogc:PropertyName>\n</Priority>\n

                                  This ensures that at small scales New York is labeled in preference to the less populous cities nearby:

                                  City locations (small scale map)

                                  Without priority labeling, Jersey City could be labeled in preference to New York, making it difficult to interpret the map. At scales showing many features, priority labeling is essential to ensure that larger cities are more visible than smaller cities.

                                  "},{"location":"styling/sld/reference/labeling/#labeling_group","title":"Grouping Features (group)","text":"

                                  The group option allows displaying a single label for multiple features in a logical group.

                                  <VendorOption name=\"group\">yes</VendorOption>\n

                                  Grouping works by collecting all features with the same label text, then choosing a representative geometry for the group, according to the following rules:

                                  Geometry Label Point

                                  Point Set The first point inside the view rectangle is used.

                                  Line Set Lines are joined together, clipped to the view rectangle, and the longest path is used.

                                  Polygon Set Polygons are clipped to the view rectangle, and the largest polygon is used.

                                  If desired the labeller can be forced to label every element in a group by specifying the labelAllGroup option.

                                  Warning

                                  Be careful that the labels truly indicate features that should be grouped together. For example, grouping on city name alone might end up creating a group containing both Paris (France) and Paris (Texas).

                                  Road data is a classic example to show why grouping is useful. It is usually desirable to display only a single label for all of \"Main Street\", not a label for every block of \"Main Street.\"

                                  When the group option is off (the default), grouping is not performed and every block feature is labeled (subject to label deconfliction):

                                  When the group option is used, geometries with the same label are grouped together and the label position is determined from the entire group. This produces a much less cluttered map:

                                  "},{"location":"styling/sld/reference/labeling/#labeling_all_group","title":"labelAllGroup","text":"

                                  The labelAllGroup option can be used in conjunction with the group option (see Grouping Features (group)). It causes all of the disjoint paths in a line group to be labeled, not just the longest one.

                                  <VendorOption name=\"labelAllGroup\">true</VendorOption>\n
                                  "},{"location":"styling/sld/reference/labeling/#labeling_space_around","title":"Overlapping and Separating Labels (spaceAround)","text":"

                                  By default GeoServer will not render labels \"on top of each other\". By using the spaceAround option you can either allow labels to overlap, or add extra space around labels. The value supplied for the option is a positive or negative size, in pixels.

                                  <VendorOption name=\"spaceAround\">10</VendorOption>\n

                                  Using the default value of 0, the bounding box of a label cannot overlap the bounding box of another label:

                                  With a negative spaceAround value, overlapping is allowed:

                                  With a positive spaceAround value of 10, each label is at least 20 pixels apart from others:

                                  Positive spaceAround values actually provide twice the space that you might expect. This is because you can specify a spaceAround for one label as 5, and for another label (in another TextSymbolizer) as 3. The total distance between them is 8. Two labels in the first symbolizer (\"5\") will each be 5 pixels apart from each other, for a total of 10 pixels.

                                  Note

                                  Interaction between values in different TextSymbolizers

                                  You can have multiple TextSymbolizers in your SLD file, each with a different spaceAround option. If all the spaceAround options are >=0, this will do what you would normally expect. If you have negative values ('allow overlap') then these labels can overlap labels that you've said should not be overlapping. If you don't like this behavior, it's not difficult to change - feel free to submit a patch!

                                  "},{"location":"styling/sld/reference/labeling/#labeling_follow_line","title":"followLine","text":"

                                  The followLine option forces a label to follow the curve of the line. To use this option add the following to the <TextSymbolizer>.

                                  Note

                                  Straight Lines

                                  You don't need to use followLine for straight lines. GeoServer will automatically follow the orientation of the line. However in this case followLine can be used to ensure the text isn't rendered if longer than the line.

                                  <VendorOption name=\"followLine\">true</VendorOption>  \n

                                  It is required to use <LinePlacement> along with this option to ensure that labels are placed along lines:

                                  <LabelPlacement>\n  <LinePlacement/>\n</LabelPlacement>\n
                                  "},{"location":"styling/sld/reference/labeling/#labeling_max_displacement","title":"maxDisplacement","text":"

                                  The maxDisplacement option controls the displacement of the label along a line, around a point and inside a polygon.

                                  For lines, normally GeoServer labels a line at its center point only. If this label conflicts with another one it may not be displayed at all. When this option is enabled the labeller will attempt to avoid conflic by using an alternate location within maxDisplacement pixels along the line from the pre-computed label point.

                                  If used in conjunction with repeat, the value for maxDisplacement should always be lower than the value for repeat.

                                  For points this causes the renderer to start circling around the point in search of a empty stop to place the label, step by step increasing the size of the circle until the max displacement is reached. The same happens for polygons, around the polygon labelling point (normally the centroid).

                                  <VendorOption name=\"maxDisplacement\">10</VendorOption> \n
                                  "},{"location":"styling/sld/reference/labeling/#labeling_repeat","title":"repeat","text":"

                                  The repeat option determines how often GeoServer displays labels along a line. Normally GeoServer labels each line only once, regardless of length. Specifying a positive value for this option makes the labeller attempt to draw the label every repeat pixels. For long or complex lines (such as contour lines) this makes labeling more informative.

                                  <VendorOption name=\"repeat\">100</VendorOption>\n
                                  "},{"location":"styling/sld/reference/labeling/#labeling_max_angle_delta","title":"maxAngleDelta","text":"

                                  When used in conjunction with followLine, the maxAngleDelta option sets the maximum angle, in degrees, between two subsequent characters in a curved label. Large angles create either visually disconnected words or overlapping characters. It is advised not to use angles larger than 30.

                                  <VendorOption name=\"maxAngleDelta\">15</VendorOption>\n
                                  "},{"location":"styling/sld/reference/labeling/#labeling_autowrap","title":"autoWrap","text":"

                                  The autoWrap option wraps labels when they exceed the given width (in pixels). The size should be wide enough to accommodate the longest word, otherwise single words will be split over multiple lines.

                                  <VendorOption name=\"autoWrap\">50</VendorOption>\n

                                  Labeling with autoWrap enabled

                                  "},{"location":"styling/sld/reference/labeling/#labeling_force_left_to_right","title":"forceLeftToRight","text":"

                                  The renderer tries to draw labels along lines so that the text is upright, for maximum legibility. This means a label may not follow the line orientation, but instead may be rotated 180\u00b0 to display the text the right way up. In some cases altering the orientation of the label is not desired; for example, if the label is a directional arrow showing the orientation of the line.

                                  The forceLeftToRight option can be set to false to disable label flipping, making the label always follow the inherent orientation of the line being labelled:

                                  <VendorOption name=\"forceLeftToRight\">false</VendorOption>\n
                                  "},{"location":"styling/sld/reference/labeling/#labeling_conflict_resolution","title":"conflictResolution","text":"

                                  By default labels are subject to conflict resolution, meaning the renderer will not allow any label to overlap with a label that has been already drawn. Setting the conflictResolution option to false causes this label to bypass conflict resolution. This means the label will be drawn even if it overlaps with other labels, and other labels drawn after it may overlap it.

                                  <VendorOption name=\"conflictResolution\">false</VendorOption>\n
                                  "},{"location":"styling/sld/reference/labeling/#labeling_goodness_of_fit","title":"goodnessOfFit","text":"

                                  GeoServer will remove labels if they are a particularly bad fit for the geometry they are labeling.

                                  Geometry Goodness of Fit Algorithm

                                  Point Always returns 1.0 since the label is at the point

                                  Line Always returns 1.0 since the label is always placed on the line.

                                  Polygon The label is sampled approximately at every letter. The distance from these points to the polygon is determined and each sample votes based on how close it is to the polygon. (see LabelCacheDefault#goodnessOfFit())

                                  The default value is 0.5, but it can be modified using:

                                  <VendorOption name=\"goodnessOfFit\">0.3</VendorOption>\n
                                  "},{"location":"styling/sld/reference/labeling/#polygonalign","title":"polygonAlign","text":"

                                  GeoServer normally tries to place labels horizontally within a polygon, and gives up if the label position is busy or if the label does not fit enough in the polygon. This option allows GeoServer to try alternate rotations for the labels.

                                  <VendorOption name=\"polygonAlign\">mbr</VendorOption>\n

                                  Option Description

                                  manual The default value. Only a rotation manually specified in the <Rotation> tag will be used

                                  ortho If the label does not fit horizontally and the polygon is taller than wider then vertical alignment will also be tried

                                  mbr If the label does not fit horizontally the minimum bounding rectangle will be computed and a label aligned to it will be tried out as well

                                  "},{"location":"styling/sld/reference/labeling/#labeling_graphic_resize","title":"graphic-resize","text":"

                                  When a <Graphic> is specified for a label by default it is displayed at its native size and aspect ratio. The graphic-resize option instructs the renderer to magnify or stretch the graphic to fully contain the text of the label. If this option is used the graphic-margin option may also be specified.

                                  <VendorOption name=\"graphic-resize\">stretch</VendorOption>\n

                                  Option Description

                                  none Graphic is displayed at its native size (default)

                                  proportional Graphic size is increased uniformly to contain the label text

                                  stretch Graphic size is increased anisotropically to contain the label text

                                  no-border

                                  Labeling with a Graphic Mark \"square\" - L) at native size; R) with \"graphic-resize\"=stretch and \"graphic-margin\"=3

                                  "},{"location":"styling/sld/reference/labeling/#labeling_graphic_margin","title":"graphic-margin","text":"

                                  The graphic-margin options specifies a margin (in pixels) to use around the label text when the graphic-resize option is specified.

                                  <VendorOption name=\"graphic-margin\">margin</VendorOption>\n
                                  "},{"location":"styling/sld/reference/labeling/#partials","title":"partials","text":"

                                  The partials options instructs the renderer to render labels that cross the map extent, which are normally not painted since there is no guarantee that a map put on the side of the current one (tiled rendering) will contain the other half of the label. By enabling \"partials\" the style editor takes responsibility for the other half being there (maybe because the label points have been placed by hand and are assured not to conflict with each other, at all zoom levels).

                                  <VendorOption name=\"partials\">true</VendorOption>\n
                                  "},{"location":"styling/sld/reference/labeling/#labeling_underline_text","title":"underlineText","text":"

                                  The underlineText option instruct the renderer to underline labels. The underline will work like a typical word processor text underline. The thickness and position of the underline will be defined by the font and color will be the same as the text. Spaces will also be underlined.

                                  <VendorOption name=\"underlineText\">true</VendorOption>\n

                                  Some underlines examples:

                                  "},{"location":"styling/sld/reference/labeling/#labeling_strikethrough_text","title":"strikethroughText","text":"

                                  The strikethroughText option instruct the renderer to strikethrough labels. The strikethrough will work like a typical word processor text strikethrough. The thickness and position of the line will be defined by the font and color will be the same as the text. Spaces will also be stroken.

                                  <VendorOption name=\"strikethroughText\">true</VendorOption>\n

                                  Some strikethrough examples:

                                  "},{"location":"styling/sld/reference/labeling/#charspacing","title":"charSpacing","text":"

                                  The charSpacing option controls the amount of space between characters, a positive value increases it, a negative value shrinks it (and will eventually make characters overlap). The value is specified in pixels.

                                  <VendorOption name=\"charSpacing\">3</VendorOption>\n

                                  Example of adding 3 extra pixels of space between chars on road names:

                                  "},{"location":"styling/sld/reference/labeling/#wordspacing","title":"wordSpacing","text":"

                                  The wordSpacing option controls the amount of space between words, for this option only positive values (or zero) are accepted. The value is specified in pixels.

                                  <VendorOption name=\"wordSpacing\">5</VendorOption>\n

                                  Example of adding 5 extra pixels of space between words on road names:

                                  "},{"location":"styling/sld/reference/labeling/#displacementmode","title":"displacementMode","text":"

                                  Comma separated list of label displacement directions for point/polygon labels (used along with maxDisplacement). The indicated directions will be tried in turn. Valid values are cardinal directions abbreviations, in particular, N, W, E, S, NW, NE, SW, SE.

                                  The following example sets the typical \"diagonal displacement\" typically used for points:

                                  <VendorOption name=\"displacementMode\">NE, NW, SW, SE</VendorOption>\n

                                  While this one allows displacement only in the vertical direction:

                                  <VendorOption name=\"displacementMode\">N, S</VendorOption>\n
                                  "},{"location":"styling/sld/reference/layers/","title":"Layers","text":"

                                  An SLD document contains a sequence of layer definitions indicating the layers to be styled. Each layer definition is either a NamedLayer reference or a supplied UserLayer.

                                  "},{"location":"styling/sld/reference/layers/#namedlayer","title":"NamedLayer","text":"

                                  A NamedLayer specifies an existing layer to be styled, and the styling to apply to it. The styling may be any combination of catalog styles and explicitly-defined styles. If no style is specified, the default style for the layer is used.

                                  The <NamedLayer> element contains the following elements:

                                  Tag Required? Description

                                  <Name> Yes The name of the layer to be styled. (Ignored in catalog styles.)

                                  <Description> No The description for the layer.

                                  <NamedStyle> 0..N The name of a catalog style to apply to the layer.

                                  <UserStyle> 0..N The definition of a style to apply to the layer. See Styles

                                  "},{"location":"styling/sld/reference/layers/#userlayer","title":"UserLayer","text":"

                                  A UserLayer defines a new layer to be styled, and the styling to apply to it. The data for the layer is provided directly in the layer definition using the <InlineFeature> element. Since the layer is not known to the server, the styling must be explicitly specified as well.

                                  The <UserLayer> element contains the following elements:

                                  Tag Required? Description

                                  <Name> No The name for the layer being defined

                                  <Description> No The description for the layer

                                  <InlineFeature> No One or more feature collections providing the layer data, specified using GML.

                                  <UserStyle> 1..N The definition of the style(s) to use for the layer. See Styles

                                  A common use is to define a geometry to be rendered to indicate an Area Of Interest.

                                  "},{"location":"styling/sld/reference/layers/#sld_reference_inlinefeature","title":"InlineFeature","text":"

                                  An InlineFeature element contains data defining a layer to be styled. The element contains one or more <FeatureCollection> elements defining the data. Each Feature Collection can contain any number of <featureMember> elements, each containing a feature specified using GML markup. The features can contain any type of geometry (point, line or polygon, and collections of these). They may also contain scalar-valued attributes, which can be useful for labelling.

                                  "},{"location":"styling/sld/reference/layers/#example","title":"Example","text":"

                                  The following style specifies a named layer using the default style, and a user-defined layer with inline data and styling. It displays the US States layer, with a labelled red box surrounding the Pacific NW.

                                  <sld:StyledLayerDescriptor xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\"\n   xsi:schemaLocation=\"http://www.opengis.net/sld StyledLayerDescriptor.xsd\"\n   xmlns:gml=\"http://www.opengis.net/gml/3.2\" xmlns:ogc=\"http://www.opengis.net/ogc\"\n   xmlns:sld=\"http://www.opengis.net/sld\" version=\"1.0.0\">\n   <sld:NamedLayer>\n      <sld:Name>usa:states</sld:Name>\n   </sld:NamedLayer>\n   <sld:UserLayer>\n      <sld:Name>Inline</sld:Name>\n      <sld:InlineFeature>\n         <sld:FeatureCollection>\n            <sld:featureMember>\n              <feature>\n                <geometryProperty>\n                  <gml:Polygon>\n                     <gml:outerBoundaryIs>\n                        <gml:LinearRing>\n                           <gml:coordinates>\n           -127.0,51.0 -110.0,51.0 -110.0,41.0 -127.0,41.0 -127.0,51.0   \n                           </gml:coordinates>\n                        </gml:LinearRing>\n                     </gml:outerBoundaryIs>\n                  </gml:Polygon>\n                </geometryProperty>\n                <title>Pacific NW </title>\n              </feature>\n            </sld:featureMember>\n         </sld:FeatureCollection>\n      </sld:InlineFeature>\n      <sld:UserStyle>\n         <sld:FeatureTypeStyle>\n            <sld:Rule>\n              <sld:PolygonSymbolizer>\n                <Stroke>\n                  <CssParameter name=\"stroke\">#FF0000</CssParameter>\n                  <CssParameter name=\"stroke-width\">2</CssParameter>\n                </Stroke>\n              </sld:PolygonSymbolizer>\n              <sld:TextSymbolizer>\n                <sld:Label>\n                  <ogc:PropertyName>title</ogc:PropertyName>\n                </sld:Label>\n                <sld:Fill>\n                  <sld:CssParameter name=\"fill\">#FF0000</sld:CssParameter>\n                </sld:Fill>\n              </sld:TextSymbolizer>\n            </sld:Rule>\n         </sld:FeatureTypeStyle>\n      </sld:UserStyle>\n   </sld:UserLayer>\n</sld:StyledLayerDescriptor>\n
                                  "},{"location":"styling/sld/reference/linesymbolizer/","title":"LineSymbolizer","text":"

                                  A LineSymbolizer styles features as lines. Lines are one-dimensional geometries that have both position and length. Each line is comprised of one or more line segments, and has either two ends or none (if it is closed).

                                  "},{"location":"styling/sld/reference/linesymbolizer/#syntax","title":"Syntax","text":"

                                  A <LineSymbolizer> contains an optional <Geometry> element, and a required <Stroke> element specifying the line symbology.

                                  Tag Required? Description

                                  <Geometry> No Specifies the geometry to be rendered.

                                  <Stroke> Yes Specifies the styling for the line.

                                  <PerpendicularOffset> No Specifies the perpendicular offset for the current line

                                  "},{"location":"styling/sld/reference/linesymbolizer/#geometry","title":"Geometry","text":"

                                  The <Geometry> element is optional. If present, it specifies the featuretype property from which to obtain the geometry to style using the PropertyName element. See also Geometry transformations in SLD for GeoServer extensions for specifying geometry.

                                  Any kind of geometry may be styled with a <LineSymbolizer>. Point geometries are treated as lines of zero length, with a horizontal orientation. For polygonal geometries the boundary (or boundaries) are used as the lines, each line being a closed ring with no ends.

                                  "},{"location":"styling/sld/reference/linesymbolizer/#sld_reference_stroke","title":"Stroke","text":"

                                  The <Stroke> element specifies the styling of a line. There are three elements that can be included inside the <Stroke> element.

                                  Tag Required? Description

                                  <GraphicFill> No Renders the pixels of the line with a repeated pattern.

                                  <GraphicStroke> No Renders the line with a repeated linear graphic.

                                  <CssParameter> 0..N Determines the stroke styling parameters.

                                  "},{"location":"styling/sld/reference/linesymbolizer/#graphicfill","title":"GraphicFill","text":"

                                  The <GraphicFill> element specifies that the pixels of the line are to be filled with a repeating graphic image or symbol. The graphic is specified by a <Graphic> sub-element, which is described in the PointSymbolizer Graphic section.

                                  "},{"location":"styling/sld/reference/linesymbolizer/#sld_reference_linesymbolizer_graphicstroke","title":"GraphicStroke","text":"

                                  The <GraphicStroke> element specifies the line is to be drawn using a repeated graphic image or symbol following the line. The graphic is specified by a <Graphic> sub-element, which is described in the PointSymbolizer Graphic section.

                                  The spacing of the graphic symbol can be specified using the <Size> element in the <Graphic> element, or the <CSSParameter name=\"stroke-dasharray\"> in the Stroke element.

                                  "},{"location":"styling/sld/reference/linesymbolizer/#sld_reference_linesymbolizer_css","title":"CssParameter","text":"

                                  The <CssParameter> elements describe the basic styling of the line. Any number of <CssParameter> elements can be specified.

                                  The name attribute indicates what aspect of styling an element specifies, using the standard CSS/SVG styling model. The content of the element supplies the value of the styling parameter. The value may contain expressions.

                                  The following parameters are supported:

                                  Parameter Required? Description

                                  name=\"stroke\" No Specifies the solid color given to the line, in the form #RRGGBB. Default is black (#000000).

                                  name=\"stroke-width\" No Specifies the width of the line in pixels. Default is 1.

                                  name=\"stroke-opacity\" No Specifies the opacity (transparency) of the line. The value is a number are between 0 (completely transparent) and 1 (completely opaque). Default is 1.

                                  name=\"stroke-linejoin\" No Determines how lines are rendered at intersections of line segments. Possible values are mitre (sharp corner), round (rounded corner), and bevel (diagonal corner). Default is mitre.

                                  name=\"stroke-linecap\" No Determines how lines are rendered at their ends. Possible values are butt (sharp square edge), round (rounded edge), and square (slightly elongated square edge). Default is butt.

                                  name=\"stroke-dasharray\" No Encodes a dash pattern as a series of numbers separated by spaces. Odd-indexed numbers (first, third, etc) determine the length in pxiels to draw the line, and even-indexed numbers (second, fourth, etc) determine the length in pixels to blank out the line. Default is an unbroken line. Starting from version 2.1 dash arrays can be combined with graphic strokes to generate complex line styles with alternating symbols or a mix of lines and symbols.

                                  name=\"stroke-dashoffset\" No Specifies the distance in pixels into the dasharray pattern at which to start drawing. Default is 0.

                                  "},{"location":"styling/sld/reference/linesymbolizer/#perpendicularoffset","title":"PerpendicularOffset","text":"

                                  The <PerpendicularOffset> element is optional. It is native to the SE 1.1 specification, but supported also in SLD 1.0 as a vendor extension.

                                  If present, it makes the renderer draw a line parallel to the original one, at the given distance. When applied on lines, positive values generate a parallel line on the left hand side, negative values on the right hand side. When applied on polygons instead, positive is interpreted as outwards, negative as inwards.

                                  As most properties, <PerpendicularOffset> accepts expressions.

                                  Care should be taken when using it, as it might become a performance bottleneck. When offsetting lines a fast offset algorithm is used, which works well at small distances, but can generate visible artifacts at higher values. When working against polygons the fast offset line algorithm is used up to 3 pixels away from the original geometry, after that a full buffer algorithm is used instead, which always provides correct results, but is significantly more expensive.

                                  "},{"location":"styling/sld/reference/linesymbolizer/#basic-example","title":"Basic Example","text":"

                                  The following symbolizer is taken from the Lines section in the SLD Cookbook.

                                  <LineSymbolizer>\n  <Stroke>\n    <CssParameter name=\"stroke\">#0000FF</CssParameter>\n    <CssParameter name=\"stroke-width\">3</CssParameter>\n    <CssParameter name=\"stroke-dasharray\">5 2</CssParameter>\n  </Stroke>\n</LineSymbolizer>\n

                                  The symbolizer styles a feature as a dashed blue line of width 3 pixels.

                                  Dashed blue line

                                  "},{"location":"styling/sld/reference/linesymbolizer/#offsetting-lines","title":"Offsetting lines","text":"

                                  The following style excerpt generates a solid line, and then a dashed blue line 3 pixels on the left of it.

                                  <LineSymbolizer>\n  <Stroke>\n    <CssParameter name=\"stroke\">#000000</CssParameter>\n    <CssParameter name=\"stroke-width\">2</CssParameter>\n  </Stroke>\n</LineSymbolizer>\n<LineSymbolizer>\n  <Stroke>\n    <CssParameter name=\"stroke\">#0000FF</CssParameter>\n    <CssParameter name=\"stroke-width\">3</CssParameter>\n    <CssParameter name=\"stroke-dasharray\">5 2</CssParameter>\n  </Stroke>\n  <PerpendicularOffset>3</PerpendicularOffset>\n</LineSymbolizer>\n

                                  Left offset dashed line

                                  "},{"location":"styling/sld/reference/linesymbolizer/#offsetting-polygons","title":"Offsetting polygons","text":"

                                  The following style excerpt builds a inward offset line for polygons.

                                  <PolygonSymbolizer>\n  <Stroke>\n    <CssParameter name=\"stroke\">#000000</CssParameter>\n    <CssParameter name=\"stroke-width\">2</CssParameter> \n  </Stroke>\n</PolygonSymbolizer>\n<LineSymbolizer>\n  <Stroke>\n    <CssParameter name=\"stroke\">#AAAAAA</CssParameter>\n    <CssParameter name=\"stroke-width\">3</CssParameter>\n  </Stroke>\n  <PerpendicularOffset>-2</PerpendicularOffset>\n</LineSymbolizer>\n

                                  Inwards offset line

                                  "},{"location":"styling/sld/reference/pointsymbolizer/","title":"PointSymbolizer","text":"

                                  A PointSymbolizer styles features as points. Points are depicted as graphic symbols at a single location on the map.

                                  "},{"location":"styling/sld/reference/pointsymbolizer/#syntax","title":"Syntax","text":"

                                  A <PointSymbolizer> contains an optional <Geometry> element, and a required <Graphic> element specifying the point symbology.

                                  Tag Required? Description

                                  <Geometry> No Specifies the geometry to be rendered.

                                  <Graphic> Yes Specifies the styling for the point symbol.

                                  "},{"location":"styling/sld/reference/pointsymbolizer/#geometry","title":"Geometry","text":"

                                  The <Geometry> element is optional. If present, it specifies the featuretype property from which to obtain the geometry to style using a <PropertyName> element. See also Geometry transformations in SLD for GeoServer extensions for specifying geometry.

                                  Any kind of geometry may be styled with a <PointSymbolizer>. For non-point geometries, a representative point is used (such as the centroid of a line or polygon).

                                  "},{"location":"styling/sld/reference/pointsymbolizer/#sld_reference_graphic","title":"Graphic","text":"

                                  Symbology is specified using a <Graphic> element. The symbol is specified by either an <ExternalGraphic> or a <Mark> element. External Graphics are image files (in a format such as PNG or SVG) that contain the shape and color information defining how to render a symbol. Marks are vector shapes whose stroke and fill are defined explicitly in the symbolizer.

                                  There are five possible sub-elements of the <Graphic> element. One of <ExternalGraphic> or <Mark> must be specified; the others are optional.

                                  Tag Required? Description

                                  <ExternalGraphic> No (when using <Mark>) Specifies an external image file to use as the symbol.

                                  <Mark> No (when using <ExternalGraphic>) Specifies a named shape to use as the symbol.

                                  <Opacity> No Specifies the opacity (transparency) of the symbol. Values range from 0 (completely transparent) to 1 (completely opaque). Value may contain expressions. Default is 1 (opaque).

                                  <Size> No Specifies the size of the symbol, in pixels. When used with an image file, this specifies the height of the image, with the width being scaled accordingly. if omitted the native symbol size is used. Value may contain expressions.

                                  <Rotation> No Specifies the rotation of the symbol about its center point, in decimal degrees. Positive values indicate rotation in the clockwise direction, negative values indicate counter-clockwise rotation. Value may contain expressions. Default is 0.

                                  "},{"location":"styling/sld/reference/pointsymbolizer/#externalgraphic","title":"ExternalGraphic","text":"

                                  External Graphics are image files (in formats such as PNG or SVG) that contain the shape and color information defining how to render a symbol. For GeoServer extensions for specifying external graphics, see Graphic symbology in GeoServer.

                                  The <ExternalGraphic> element has the sub-elements:

                                  Tag Required? Description

                                  <OnlineResource> Yes The xlink:href attribute specifies the location of the image file. The value can be either a URL or a local pathname relative to the SLD directory. The value can contain CQL expressions delimited by ${ }. The attribute xlink:type=\"simple\" is also required. The element does not contain any content.

                                  <Format> Yes The MIME type of the image format. Most standard web image formats are supported. Common MIME types are image/png, image/jpeg, image/gif, and image/svg+xml

                                  "},{"location":"styling/sld/reference/pointsymbolizer/#mark","title":"Mark","text":"

                                  Marks are predefined vector shapes identified by a well-known name. Their fill and stroke can be defined explicitly in the SLD. For GeoServer extensions for specifying mark symbols, see Graphic symbology in GeoServer.

                                  The <Mark> element has the sub-elements:

                                  Tag Required? Description

                                  <WellKnownName> No The name of the shape. Standard SLD shapes are circle, square, triangle, star, cross, or x. Default is square.

                                  <Fill> No Specifies how the symbol should be filled (for closed shapes). Options are to use <CssParameter name=\"fill\"> to specify a solid fill color, or using <GraphicFill> for a tiled graphic fill. See the PolygonSymbolizer Fill for the full syntax.

                                  <Stroke> No Specifies how the symbol linework should be drawn. Some options are using <CssParameter name=\"stroke\"> to specify a stroke color, or using <GraphicStroke> for a repeated graphic. See the LineSymbolizer Stroke for the full syntax.

                                  "},{"location":"styling/sld/reference/pointsymbolizer/#example","title":"Example","text":"

                                  The following symbolizer is taken from the Points section in the SLD Cookbook.

                                  <PointSymbolizer>\n  <Graphic>\n    <Mark>\n  <WellKnownName>circle</WellKnownName>\n      <Fill>\n    <CssParameter name=\"fill\">#FF0000</CssParameter>\n  </Fill>\n    </Mark>\n    <Size>6</Size>\n  </Graphic>\n</PointSymbolizer>\n

                                  The symbolizer contains the required <Graphic> element. Inside this element is the <Mark> element and <Size> element, which are the minimum required element inside <Graphic> (when not using the <ExternalGraphic> element). The <Mark> element contains the <WellKnownName> element and a <Fill> element. No other element are required. In summary, this example specifies the following:

                                  1. Features will be rendered as points
                                  2. Points will be rendered as circles
                                  3. Circles will be rendered with a diameter of 6 pixels and filled with the color red

                                  The next example uses an external graphic loaded from the file system:

                                  <PointSymbolizer>\n  <Graphic>\n    <ExternalGraphic>\n      <OnlineResource xlink:type=\"simple\" \n                      xlink:href=\"file:///var/www/htdocs/sun.png\" />\n      <Format>image.png</Format>\n    </ExternalGraphic>\n  </Graphic>\n</PointSymbolizer>\n

                                  For file:// URLs, the file must be readable by the user the GeoServer process is running as. You can also use href:// URLs to reference remote graphics.

                                  Further examples can be found in the Points section of the SLD Cookbook.

                                  "},{"location":"styling/sld/reference/pointsymbolizer/#sld_reference_parameter_expressions","title":"Using expressions in parameter values","text":"

                                  Many SLD parameters allow their values to be of mixed type. This means that the element content can be:

                                  • a constant value expressed as a string
                                  • a filter expression
                                  • any combination of strings and filter expressions.

                                  Using expressions in parameter values provides the ability to determine styling dynamically on a per-feature basis, by computing parameter values from feature properties. Using computed parameters is an alternative to using rules in some situations, and may provide a more compact SLD document.

                                  GeoServer also supports using substitution variables provided in WMS requests. This is described in Variable substitution in SLD.

                                  "},{"location":"styling/sld/reference/polygonsymbolizer/","title":"PolygonSymbolizer","text":"

                                  A PolygonSymbolizer styles features as polygons. Polygons are two-dimensional geometries. They can be depicted with styling for their interior (fill) and their border (stroke). Polygons may contain one or more holes, which are stroked but not filled. When rendering a polygon, the fill is rendered before the border is stroked.

                                  "},{"location":"styling/sld/reference/polygonsymbolizer/#syntax","title":"Syntax","text":"

                                  A <PolygonSymbolizer> contains an optional <Geometry> element, and two elements <Fill> and <Stroke> for specifying styling:

                                  Tag Required? Description

                                  <Geometry> No Specifies the geometry to be rendered.

                                  <Fill> No Specifies the styling for the polygon interior.

                                  <Stroke> No Specifies the styling for the polygon border.

                                  "},{"location":"styling/sld/reference/polygonsymbolizer/#geometry","title":"Geometry","text":"

                                  The <Geometry> element is optional. If present, it specifies the featuretype property from which to obtain the geometry to style using the PropertyName element. See also Geometry transformations in SLD for GeoServer extensions for specifying geometry.

                                  Any kind of geometry may be styled with a <PolygonSymbolizer>. Point geometries are treated as small orthonormal square polygons. Linear geometries are closed by joining their ends.

                                  "},{"location":"styling/sld/reference/polygonsymbolizer/#stroke","title":"Stroke","text":"

                                  The <Stroke> element specifies the styling for the border of a polygon. The syntax is described in the <LineSymbolizer> Stroke section.

                                  "},{"location":"styling/sld/reference/polygonsymbolizer/#sld_reference_fill","title":"Fill","text":"

                                  The <Fill> element specifies the styling for the interior of a polygon. It can contain the sub-elements:

                                  Tag Required? Description

                                  <GraphicFill> No Renders the fill of the polygon with a repeated pattern.

                                  <CssParameter> 0..N Specifies parameters for filling with a solid color.

                                  "},{"location":"styling/sld/reference/polygonsymbolizer/#graphicfill","title":"GraphicFill","text":"

                                  The <GraphicFill> element contains a <Graphic> element, which specifies a graphic image or symbol to use for a repeated fill pattern. The syntax is described in the PointSymbolizer Graphic section.

                                  "},{"location":"styling/sld/reference/polygonsymbolizer/#cssparameter","title":"CssParameter","text":"

                                  The <CssParameter> elements describe the styling of a solid polygon fill. Any number of <CssParameter> elements can be specified.

                                  The name attribute indicates what aspect of styling an element specifies, using the standard CSS/SVG styling model. The content of the element supplies the value of the styling parameter. The value may contain expressions.

                                  The following parameters are supported:

                                  Parameter Required? Description

                                  name=\"fill\" No Specifies the fill color, in the form #RRGGBB. Default is grey (#808080).

                                  name=\"fill-opacity\" No Specifies the opacity (transparency) of the fill. The value is a decimal number between 0 (completely transparent) and 1 (completely opaque). Default is 1.

                                  "},{"location":"styling/sld/reference/polygonsymbolizer/#example","title":"Example","text":"

                                  The following symbolizer is taken from the Polygons section in the SLD Cookbook.

                                  <PolygonSymbolizer>\n  <Fill>\n    <CssParameter name=\"fill\">#000080</CssParameter>\n  </Fill>\n</PolygonSymbolizer>\n

                                  This symbolizer contains only a <Fill> element. Inside this element is a <CssParameter> that specifies the fill color for the polygon to be #000080 (a muted blue).

                                  Further examples can be found in the Polygons section of the SLD Cookbook.

                                  "},{"location":"styling/sld/reference/rastersymbolizer/","title":"RasterSymbolizer","text":"

                                  GeoServer supports the ability to display raster data in addition to vector data.

                                  Raster data is not merely a picture, rather it can be thought of as a grid of georeferenced information, much like a graphic is a grid of visual information (with combination of reds, greens, and blues). Unlike graphics, which only contain visual data, each point/pixel in a raster grid can have many different attributes (bands), with possibly none of them having an inherently visual component.

                                  With the above in mind, one needs to choose how to visualize the data, and this, like in all other cases, is done by using an SLD. The analogy to vector data is evident in the naming of the tags used. Vectors, consisting of points, line, and polygons, are styled by using the <PointSymbolizer>, <LineSymbolizer>, and <PolygonSymbolizer> tags. It is therefore not very surprising that raster data is styled with the tag ."},{"location":"styling/sld/reference/rastersymbolizer/#syntax","title":"Syntax","text":"

                                  The following elements can be used inside the <RasterSymbolizer> element.

                                  • <Opacity>
                                  • <ColorMap>
                                  • <ChannelSelection>
                                  • <ContrastEnhancement>
                                  • <ShadedRelief> *
                                  • <OverlapBehavior> *
                                  • <ImageOutline> *

                                  Warning

                                  The starred (*) elements are not yet implemented in GeoServer.

                                  "},{"location":"styling/sld/reference/rastersymbolizer/#opacity","title":"Opacity","text":"

                                  The <Opacity> element sets the transparency level for the entire rendered image. As is standard, the values range from zero (0) to one (1), with zero being transparent, and one being opaque. The syntax is:

                                  <Opacity>0.5</Opacity>\n

                                  where, in this case, the raster is rendered at 50% opacity.

                                  "},{"location":"styling/sld/reference/rastersymbolizer/#colormap","title":"ColorMap","text":"

                                  The <ColorMap> element defines the color values for the pixels of a raster image, as either color gradients, or a mapping of specific values to fixed colors.

                                  A color map is defined by a sequence of <ColorMapEntry> elements. Each <ColorMapEntry> element specifies a color and a quantity attribute. The quantity refers to the value of a raster pixel. The color value is denoted in standard hexadecimal RGB format (#RRGGBB). <ColorMapEntry> elements can also have opacity and label attributes. The opacity attribute overrides the global <Opacity> value. The label attribute is used to provide text for legends. A color map can contain up to 255 <ColorMapEntry> elements.

                                  The simplest <ColorMap> has two color map entries. One specifyies a color for the \"bottom\" of the dataset, and the other specifyies a color for the \"top\" of the dataset. Pixels with values equal to or less than the minimum value are rendered with the bottom color (and opacity). Pixels with values equal to or great than the maximum value are rendered with the top color and opacity. The colors for values in between are automatically interpolated, making creating color gradients easy.

                                  A color map can be refined by adding additional intermediate entries. This is useful if the dataset has discrete values rather than a gradient, or if a multi-colored gradient is desired. One entry is added for each different color to be used, along with the corresponding quantity value.

                                  For example, a simple ColorMap can define a color gradient from color #323232 to color #BBBBBB over quantity values from -300 to 200:

                                  <ColorMap>\n    <ColorMapEntry color=\"#323232\" quantity=\"-300\" label=\"label1\" opacity=\"1\"/>\n    <ColorMapEntry color=\"#BBBBBB\" quantity=\"200\" label=\"label2\" opacity=\"1\"/>\n</ColorMap>\n

                                  A more refined example defines a color gradient from color #FFCC32 through color #BBBBBB, running through color #3645CC and color #CC3636. The bottom color #FFCC32 is defined to be transparent This simulates an alpha channel, since pixels with values of -300 and below will not be rendered. Notice that the default opacity is 1 (opaque) when not specified.

                                  <ColorMap>\n    <ColorMapEntry color=\"#FFCC32\" quantity=\"-300\" label=\"label1\" opacity=\"0\"/>\n    <ColorMapEntry color=\"#3645CC\" quantity=\"0\" label=\"label2\" opacity=\"1\"/>\n    <ColorMapEntry color=\"#CC3636\" quantity=\"100\" label=\"label3\" opacity=\"1\"/>\n    <ColorMapEntry color=\"#BBBBBB\" quantity=\"200\" label=\"label4\" opacity=\"1\"/>\n</ColorMap>\n

                                  GeoServer extends the <ColorMap> element to allow two attributes: type and extended.

                                  "},{"location":"styling/sld/reference/rastersymbolizer/#type","title":"type","text":"

                                  The <ColorMap> type attribute specifies the kind of ColorMap to use. There are three different types of ColorMaps that can be specified: ramp, intervals and values.

                                  type=\"ramp\" is the default ColorMap type. It specifies that colors should be interpolated for values between the color map entries. The result is shown in the following example.

                                  <ColorMap type=\"ramp\">\n        <ColorMapEntry color=\"#EEBE2F\" quantity=\"-300\" label=\"label\" opacity=\"0\"/>\n        <ColorMapEntry color=\"#2851CC\" quantity=\"0\" label=\"values\" opacity=\"1\"/>\n        <ColorMapEntry color=\"#211F1F\" quantity=\"50\" label=\"label\" opacity=\"1\"/>\n        <ColorMapEntry color=\"#EE0F0F\" quantity=\"100\" label=\"label\" opacity=\"1\"/>\n        <ColorMapEntry color=\"#AAAAAA\" quantity=\"200\" label=\"label\" opacity=\"1\"/>\n        <ColorMapEntry color=\"#6FEE4F\" quantity=\"250\" label=\"label\" opacity=\"1\"/>\n        <ColorMapEntry color=\"#3ECC1B\" quantity=\"300\" label=\"label\" opacity=\"1\"/>\n        <ColorMapEntry color=\"#886363\" quantity=\"350\" label=\"label\" opacity=\"1\"/>\n        <ColorMapEntry color=\"#5194CC\" quantity=\"400\" label=\"label\" opacity=\"1\"/>\n        <ColorMapEntry color=\"#2C58DD\" quantity=\"450\" label=\"label\" opacity=\"1\"/>\n        <ColorMapEntry color=\"#DDB02C\" quantity=\"600\" label=\"label\" opacity=\"1\"/>\n</ColorMap>\n

                                  type=\"values\" means that only pixels with the specified entry quantity values are rendered. Pixels with other values are not rendered. Using the example set of color map entries:

                                  <ColorMap type=\"values\">\n        <ColorMapEntry color=\"#EEBE2F\" quantity=\"-300\" label=\"label\" opacity=\"0\"/>\n        ...\n        <ColorMapEntry color=\"#DDB02C\" quantity=\"600\" label=\"label\" opacity=\"1\"/>\n</ColorMap>\n

                                  The result image is:

                                  type=\"intervals\" value means that each interval defined by two entries is rendered using the color of the first (lowest-value) entry. No color interpolation is applied across the intervals. Using the example set of color map entries:

                                  <ColorMap type=\"intervals\" extended=\"true\">\n        <ColorMapEntry color=\"#EEBE2F\" quantity=\"-300\" label=\"label\" opacity=\"0\"/>\n        ...\n        <ColorMapEntry color=\"#DDB02C\" quantity=\"600\" label=\"label\" opacity=\"1\"/>\n</ColorMap>   \n

                                  The result image is:

                                  The color map type is also reflected in the legend graphic. A typical request for a raster legend is (using the forceRule:true option to force output of the color map):

                                  http://localhost:8080/geoserver/wms?REQUEST=GetLegendGraphic&VERSION=1.0.0&&STYLE=raster100&FORMAT=image/png&WIDTH=50&HEIGHT=20&LEGEND_OPTIONS=forceRule:true&LAYER=it.geosolutions:di08032_da\n

                                  The legends returned for the different types are:

                                  "},{"location":"styling/sld/reference/rastersymbolizer/#extended","title":"extended","text":"

                                  The extended attribute specifies whether the color map gradient uses 256 (8-bit) or 65536 (16-bit) colors. The value false (the default) specifies that the color scale is calculated using 8-bit color, and true specifies using 16-bit color.

                                  "},{"location":"styling/sld/reference/rastersymbolizer/#sld_reference_rastersymbolizer_colormap_cql","title":"CQL Expressions","text":"

                                  All of the ColorMapEntry attributes (color, quantity, label and opacity) can be defined using cql expressions, with the \\${...expression...} syntax.

                                  CQL expressions are useful to make the color map dynamic, using values taken from the client:

                                  <ColorMapEntry color=\"#00FF00\" quantity=\"${env('low',3)}\" label=\"Low\" opacity=\"1\"/>\n<ColorMapEntry color=\"#FFFF00\" quantity=\"${env('medium',10)}\" label=\"Medium\" opacity=\"1\"/>\n<ColorMapEntry color=\"#FF0000\" quantity=\"${env('high',1000)}\" label=\"High\" opacity=\"1\"/>\n

                                  In this example quantity values are not fixed, but can be specified by the client using the ENV request parameter:

                                  http://localhost:8080/geoserver/wms?REQUEST=GetMap&VERSION=1.0.0&...&ENV=low:10;medium:100;high:500

                                  For a complete reference of CQL capabilities, see here

                                  "},{"location":"styling/sld/reference/rastersymbolizer/#channelselection","title":"ChannelSelection","text":"

                                  The <ChannelSelection> element specifies how dataset bands are mapped to image color channels. Named dataset bands may be mapped to red, green and blue channels, or a single named band may be mapped to a grayscale channel.

                                  The following example maps source channels 1, 2 and 3 to the red, green, and blue color channels.

                                  <ChannelSelection>\n  <RedChannel>\n        <SourceChannelName>1</SourceChannelName>\n  </RedChannel>\n  <GreenChannel>\n        <SourceChannelName>2</SourceChannelName>\n  </GreenChannel>\n  <BlueChannel>\n        <SourceChannelName>3</SourceChannelName>\n  </BlueChannel>\n</ChannelSelection>\n

                                  The next example shows selecting a single band of an RGB image as a grayscale channel, and re-colorizing it via a ColorMap:

                                  <RasterSymbolizer>\n        <Opacity>1.0</Opacity>\n        <ChannelSelection>\n            <GrayChannel>\n                <SourceChannelName>1</SourceChannelName>\n            </GrayChannel>\n        </ChannelSelection>\n        <ColorMap extended=\"true\">\n            <ColorMapEntry color=\"#0000ff\" quantity=\"3189.0\"/>\n            <ColorMapEntry color=\"#009933\" quantity=\"6000.0\"/>\n            <ColorMapEntry color=\"#ff9900\" quantity=\"9000.0\" />\n            <ColorMapEntry color=\"#ff0000\" quantity=\"14265.0\"/>\n        </ColorMap>\n</RasterSymbolizer>\n

                                  "},{"location":"styling/sld/reference/rastersymbolizer/#channelselection-expressions","title":"ChannelSelection Expressions","text":"

                                  Since the previous approach supports Strings only and therefore is static and not suitable when dealing with multispectral imagery that has more than four bands and hyperspectral imagery (hyperspectral sensors have typically hundreds of bands), a dynamical approach is needed.

                                  By replacing Strings with Expressions in <SourceChannelName>, context free functions like env can be used to indicate which bands are to be used in a particular rendering session.

                                  The following example shows how to set the Red, Green and Blue channels and to map them into the desired bands. Here below, the env function will set, by default in the WMS request, the RedChannel on the second band, the GreenChannel on the fifth band and the BlueChannel on the seventh band.

                                  <RasterSymbolizer>\n<ChannelSelection>\n    <RedChannel>\n    <SourceChannelName>\n        <ogc:Function name=\"env\">\n            <ogc:Literal>B1</ogc:Literal>\n            <ogc:Literal>1</ogc:Literal>\n        </ogc:Function>\n    </SourceChannelName>\n    </RedChannel>\n    <GreenChannel>\n    <SourceChannelName>\n        <ogc:Function name=\"env\">\n            <ogc:Literal>B2</ogc:Literal>\n            <ogc:Literal>2</ogc:Literal>\n        </ogc:Function>\n    </SourceChannelName>\n    </GreenChannel>\n    <BlueChannel>\n    <SourceChannelName>\n        <ogc:Function name=\"env\">\n            <ogc:Literal>B3</ogc:Literal>\n            <ogc:Literal>3</ogc:Literal>\n        </ogc:Function>\n    </SourceChannelName>\n    </BlueChannel>\n</ChannelSelection>\n<RasterSymbolizer>\n

                                  The style Schema supports also the SLD 1.1 and CSS. As a CSS examples:

                                  * { raster-channels: [env('B1','1')] '2' '3'; }\n\n* { raster-channels: @B1(1)  '2' '3';}\n

                                  One can specify the env request parameters in the WMS request to switch the bands and render the raster layer using the desired bands, for example the 4, 2, 3 as the following:

                                  http://localhost:8083/geosolutions/wms?service=WMS&version=1.1.0&request=GetMap&layers=geosolutions:raster_multichannel&styles=&bbox=-180.0,-90.5,180.0,90.5&width=768&height=386&srs=EPSG:4326&format=application/openlayers&env=B1:4;B2:2;B3:3\n

                                  Now let us suppose that we want to work on a single band and to exclude all the remaining bands in order to render a monochromatic raster. As an SLD example:

                                  <RasterSymbolizer>\n  <Opacity>1.0</se:Opacity>\n  <ChannelSelection>\n    <GrayChannel>\n      <SourceChannelName>\n            <Function name=\"env\">\n             <ogc:Literal>B1</ogc:Literal>\n             <ogc:Literal>7</ogc:Literal>\n          </ogc:Function>\n      </SourceChannelName>\n    </GrayChannel>\n  </ChannelSelection>\n</RasterSymbolizer>\n

                                  The Schema above will render the channel \"7\" by default. As before, you can choose to render any channel of the raster by calling the env function in your WMS request and setting the desired band. By adding to the request &env=B1:3 for example:

                                  http://localhost:8083/geoserver/wms?service=WMS&version=1.1.0&request=GetMap&layers=geosolutions:usa&styles=&bbox=-130.85168,20.7052,-62.0054,54.1141&width=768&height=372&srs=EPSG:4326&format=application/openlayers&env=B1:3\n

                                  Finally, you can add a ColorMap on the selected channel as the following:

                                  <RasterSymbolizer>\n <Opacity>1.0</Opacity>\n <ChannelSelection>\n   <GrayChannel>\n     <SourceChannelName>\n        <ogc:Function name=\"env\">\n            <ogc:Literal>B1</ogc:Literal>\n            <ogc:Literal>7</ogc:Literal>\n         </ogc:Function>\n     </SourceChannelName>\n   </GrayChannel>\n </ChannelSelection>\n <ColorMap>\n     <ColorMapEntry color=\"#0000ff\" quantity=\"50.0\"/>\n     <ColorMapEntry color=\"#009933\" quantity=\"100.0\"/>\n     <ColorMapEntry color=\"#ff9900\" quantity=\"150.0\" />\n     <ColorMapEntry color=\"#ff0000\" quantity=\"200.0\"/>\n </ColorMap>\n</RasterSymbolizer>     \n

                                  "},{"location":"styling/sld/reference/rastersymbolizer/#contrastenhancement","title":"ContrastEnhancement","text":"

                                  The <ContrastEnhancement> element is used to adjust the relative brightness of the image data. A <ContrastEnhancement> element can be specified for the entire image, or in individual Channel elements. In this way, different enhancements can be used on each channel.

                                  There are three types of enhancements possible:

                                  • Normalize
                                  • Histogram
                                  • GammaValue

                                  <Normalize> means to expand the contrast so that the minimum quantity is mapped to minimum brightness, and the maximum quantity is mapped to maximum brightness.

                                  <Histogram> is similar to Normalize, but the algorithm used attempts to produce an image with an equal number of pixels at all brightness levels.

                                  <GammaValue> is a scaling factor that adjusts the brightness of the image. A value less than one (1) darkens the image, and a value greater than one (1) brightens it. The default is 1 (no change).

                                  These examples turn on Normalize and Histogram, respectively:

                                  <ContrastEnhancement>\n    <Normalize/>\n</ContrastEnhancement>\n
                                  <ContrastEnhancement>\n    <Histogram/>\n</ContrastEnhancement>\n

                                  This example increases the brightness of the image by a factor of two.

                                  <ContrastEnhancement>\n    <GammaValue>2</GammaValue>\n</ContrastEnhancement>\n

                                  It is also possible to customize Normalize Contrast Enhancement element for the RasterSymbolizer. 3 new VendorOptions are supported:

                                  • ALGORITHM_NAME to control the algorithm to apply
                                  • MIN_VALUE to control the min value for the algorithm
                                  • MAX_VALUE to control the max value for the algorithm

                                  Supported algorithms are:

                                  • StretchToMinimumMaximum it will linearly stretch the source raster by linearly mapping values within the [MIN_VALUE, MAX_VALUE] range to [0,255]. This will also automatically result into a clip of the values outside the specified input range.
                                  • ClipToMinimumMaximum it will result into a clamp operation. Values smaller than MIN_VALUE will be forced to MIN_VALUE. Values greater than MAX_VALUE will be forced to MAX_VALUE. Values in the [MIN_VALUE, MAX_VALUE] range will passthrough unchanged.
                                  • ClipToZero is similar to ClipToMinimumMaximum. However, values outside the [MIN_VALUE, MAX_VALUE] range will be forced to be 0.

                                  Note

                                  The target data type for the stretch algorithm is always byte (this might change in the future). This means that if the MAX_VALUE for the Clip oriented algorithms is greater than 255 an implicit clamp will apply anyway to clamp to 255.

                                  Here below some examples

                                  <ContrastEnhancement>\n  <Normalize>\n   <VendorOption name=\"algorithm\">StretchToMinimumMaximum</VendorOption>\n   <VendorOption name=\"minValue\">50</VendorOption>\n   <VendorOption name=\"maxValue\">100</VendorOption>\n  </Normalize>\n</ContrastEnhancement>\n

                                  This example will apply a Normalized ContrastEnhancement by linearly stretch from pixel values [50, 100] to [0, 255]

                                  <ContrastEnhancement>\n  <Normalize>\n   <VendorOption name=\"algorithm\">ClipToMinimumMaximum</VendorOption>\n   <VendorOption name=\"minValue\">50</VendorOption>\n   <VendorOption name=\"maxValue\">100</VendorOption>\n  </Normalize>\n</ContrastEnhancement>\n
                                  <ContrastEnhancement>\n  <Normalize>\n   <VendorOption name=\"algorithm\">ClipToMinimumMaximum</VendorOption>\n   <VendorOption name=\"minValue\">50</VendorOption>\n   <VendorOption name=\"maxValue\">100</VendorOption>\n  </Normalize>\n</ContrastEnhancement>  \n

                                  Here below a more complex example that shows the possibility to control the values from a client using env functions. This is extremely interesting for interactive applications.

                                  ...\n<ContrastEnhancement>\n    <Normalize>\n     <VendorOption name=\"algorithm\">\n       <ogc:Function name=\"env\">\n         <ogc:Literal>algorithm</ogc:Literal>\n         <ogc:Literal>StretchToMinimumMaximum</ogc:Literal>\n       </ogc:Function>                                       \n     </VendorOption>\n     <VendorOption name='minValue'>\n       <ogc:Function name=\"env\">\n         <ogc:Literal>minValue</ogc:Literal>\n         <ogc:Literal>10</ogc:Literal>\n       </ogc:Function>\n     </VendorOption>\n     <VendorOption name='maxValue'>\n       <ogc:Function name=\"env\">\n         <ogc:Literal>maxValue</ogc:Literal>\n         <ogc:Literal>1200</ogc:Literal>\n       </ogc:Function>                                       \n     </VendorOption>\n    </Normalize>\n</ContrastEnhancement>\n...\n
                                  "},{"location":"styling/sld/reference/rastersymbolizer/#shadedrelief","title":"ShadedRelief","text":"

                                  Warning

                                  Support for this element has not been implemented yet.

                                  The <ShadedRelief> element can be used to create a 3-D effect, by selectively adjusting brightness. This is a nice effect to use on an elevation dataset. There are two types of shaded relief possible.

                                  • BrightnessOnly
                                  • ReliefFactor

                                  BrightnessOnly, which takes no parameters, applies shading in WHAT WAY? ReliefFactor sets the amount of exaggeration of the shading (for example, to make hills appear higher). According to the OGC SLD specification, a value of around 55 gives \"reasonable results\" for Earth-based datasets:

                                  <ShadedRelief>\n    <BrightnessOnly />\n    <ReliefFactor>55</ReliefFactor>\n</ShadedRelief>\n

                                  The above example turns on Relief shading in WHAT WAY?

                                  "},{"location":"styling/sld/reference/rastersymbolizer/#overlapbehavior","title":"OverlapBehavior","text":"

                                  Warning

                                  Support for this element has not been implemented yet.

                                  Sometimes raster data is comprised of multiple image sets. Take, for example, a satellite view of the Earth at night . As all of the Earth can't be in nighttime at once, a composite of multiple images are taken. These images are georeferenced, and pieced together to make the finished product. That said, it is possible that two images from the same dataset could overlap slightly, and the OverlapBehavior element is designed to determine how this is handled. There are four types of OverlapBehavior:

                                  • AVERAGE
                                  • RANDOM
                                  • LATEST_ON_TOP
                                  • EARLIEST_ON_TOP

                                  AVERAGE takes each overlapping point and displays their average value. RANDOM determines which image gets displayed according to chance (which can sometimes result in a crisper image). LATEST_ON_TOP and EARLIEST_ON_TOP sets the determining factor to be the internal timestamp on each image in the dataset. None of these elements have any parameters, and are all called in the same way:

                                  <OverlapBehavior>\n    <AVERAGE />\n</OverlapBehavior>\n

                                  The above sets the OverlapBehavior to AVERAGE.

                                  "},{"location":"styling/sld/reference/rastersymbolizer/#imageoutline","title":"ImageOutline","text":"

                                  Warning

                                  Support for this element has not been implemented yet.

                                  Given the situation mentioned previously of the image composite, it is possible to style each image so as to have an outline. One can even set a fill color and opacity of each image; a reason to do this would be to \"gray-out\" an image. To use ImageOutline, you would define a or inside of the element:

                                  <ImageOutline>\n    <LineSymbolizer>\n        <Stroke>\n                <CssParameter name=\"stroke\">#0000ff</CssParameter>\n        </Stroke>\n    </LineSymbolizer>\n</ImageOutline>\n

                                  The above would create a border line (colored blue with a one pixel default thickness) around each image in the dataset.

                                  "},{"location":"styling/sld/reference/rules/","title":"Rules","text":"

                                  Styling rules define the portrayal of features. A rule combines a filter with any number of symbolizers. Features for which the filter condition evaluates as true are rendered using the symbolizers in the rule.

                                  "},{"location":"styling/sld/reference/rules/#syntax","title":"Syntax","text":"

                                  The <Rule> element contains the following elements:

                                  Tag Required? Description

                                  <Name> No Specifies a name for the rule.

                                  <Title> No Specifies a title for the rule. The title is used in display lists and legends.

                                  <Abstract> No Specifies an abstract describing the rule.

                                  <Filter> No Specifies a filter controlling when the rule is applied. See Filters

                                  <MinScaleDenominator> No Specifies the minimum scale denominator (inclusive) for the scale range in which this rule applies. If present, the rule applies at the given scale and all smaller scales.

                                  <MaxScaleDenominator> No Specifies the maximum scale denominator (exclusive) for the scale range in which this rule applies. If present, the rule applies at scales larger than the given scale.

                                  <PointSymbolizer> 0..N Specifies styling as points. See PointSymbolizer

                                  <LineSymbolizer> 0..N Specifies styling as lines. See LineSymbolizer

                                  <PolygonSymbolizer> 0..N Specifies styling as polygons. See PolygonSymbolizer

                                  <TextSymbolizer> 0..N Specifies styling for text labels. See TextSymbolizer

                                  <RasterSymbolizer> 0..N Specifies styling for raster data. See RasterSymbolizer

                                  "},{"location":"styling/sld/reference/rules/#scale-selection","title":"Scale Selection","text":"

                                  Rules support scale selection to allow specifying the scale range in which a rule may be applied (assuming the filter condition is satisfied as well, if present). Scale selection allows for varying portrayal of features at different map scales. In particular, at smaller scales it is common to use simpler styling for features, or even prevent the display of some features altogether.

                                  Scale ranges are specified by using scale denominators. These values correspond directly to the ground distance covered by a map, but are inversely related to the common \"large\" and \"small\" terminology for map scale. In other words:

                                  • large scale maps cover less area and have a smaller scale denominator
                                  • small scale maps cover more area and have a larger scale denominator

                                  Two optional elements specify the scale range for a rule:

                                  Tag Required? Description

                                  <MinScaleDenominator> No Specifies the minimum scale denominator (inclusive) for the scale range in which this rule applies. If present, the rule applies at the given scale and all smaller scales.

                                  <MaxScaleDenominator> No Specifies the maximum scale denominator (exclusive) for the scale range in which this rule applies. If present, the rule applies at scales larger than the given scale.

                                  Note

                                  The current scale can also be obtained via the wms_scale_denominator SLD environment variable. This allows including scale dependency in Filter Expressions.

                                  The following example shows the use of scale selection in a pair of rules. The rules specify that:

                                  • at scales above 1:20,000 (larger scales, with scale denominators smaller than 20,000) features are symbolized with 10-pixel red squares,
                                  • at scales at or below 1:20,000 (smaller scales, with scale denominators larger than 20,000) features are symbolized with 4-pixel blue triangles.
                                  <Rule>\n   <MaxScaleDenominator>20000</MaxScaleDenominator>\n   <PointSymbolizer>\n     <Graphic>\n       <Mark>\n         <WellKnownName>square</WellKnownName>\n         <Fill><CssParameter name=\"fill\">#FF0000</CssParameter>\n       </Mark>\n       <Size>10</Size>\n     </Graphic>\n   </PointSymbolizer>\n</Rule>\n<Rule>\n   <MinScaleDenominator>20000</MinScaleDenominator>\n   <PointSymbolizer>\n     <Graphic>\n       <Mark>\n         <WellKnownName>triangle</WellKnownName>\n         <Fill><CssParameter name=\"fill\">#0000FF</CssParameter>\n       </Mark>\n       <Size>4</Size>\n     </Graphic>\n   </PointSymbolizer>\n</Rule>\n
                                  "},{"location":"styling/sld/reference/rules/#evaluation-order","title":"Evaluation Order","text":"

                                  Within an SLD document each <FeatureTypeStyle> can contain many rules. Multiple-rule SLDs are the basis for thematic styling. In GeoServer each <FeatureTypeStyle> is evaluated once for each feature processed. The rules within it are evaluated in the order they occur. A rule is applied when its filter condition (if any) is true for a feature and the rule is enabled at the current map scale. The rule is applied by rendering the feature using each symbolizer within the rule, in the order in which they occur. The rendering is performed into the image buffer for the parent <FeatureTypeStyle>. Thus symbolizers earlier in a FeatureTypeStyle and Rule are rendered before symbolizers occurring later in the document (this is the \"Painter's Model\" method of rendering).

                                  "},{"location":"styling/sld/reference/rules/#examples","title":"Examples","text":"

                                  The following rule applies only to features which have a POPULATION attribute greater than 100,000, and symbolizes the features as red points.

                                  <Rule>\n   <ogc:Filter>\n     <ogc:PropertyIsGreaterThan>\n       <ogc:PropertyName>POPULATION</ogc:PropertyName>\n       <ogc:Literal>100000</ogc:Literal>\n     </ogc:PropertyIsGreaterThan>\n   </ogc:Filter>\n   <PointSymbolizer>\n     <Graphic>\n       <Mark>\n         <Fill><CssParameter name=\"fill\">#FF0000</CssParameter>\n       </Mark>\n     </Graphic>\n   </PointSymbolizer>\n</Rule>\n

                                  An additional rule can be added which applies to features whose POPULATION attribute is less than 100,000, and symbolizes them as green points.

                                  <Rule>\n  <ogc:Filter>\n    <ogc:PropertyIsLessThan>\n      <ogc:PropertyName>POPULATION</ogc:PropertyName>\n      <ogc:Literal>100000</ogc:Literal>\n    </ogc:PropertyIsLessThan>\n  </ogc:Filter>\n  <PointSymbolizer>\n    <Graphic>\n      <Mark>\n        <Fill><CssParameter name=\"fill\">#0000FF</CssParameter>\n      </Mark>\n    </Graphic>\n  </PointSymbolizer>\n</Rule>\n
                                  "},{"location":"styling/sld/reference/sld/","title":"StyledLayerDescriptor","text":"

                                  The root element for an SLD is <StyledLayerDescriptor>. It contains a sequence of Layers defining the styled map content.

                                  The <StyledLayerDescriptor> element contains the following elements:

                                  Tag Required? Description

                                  <NamedLayer> 0..N A reference to a named layer in the server catalog

                                  <UserLayer> 0..N A layer defined in the style itself

                                  "},{"location":"styling/sld/reference/styles/","title":"Styles","text":"

                                  The style elements specify the styling to be applied to a layer.

                                  "},{"location":"styling/sld/reference/styles/#userstyle","title":"UserStyle","text":"

                                  The UserStyle element defines styling for a layer.

                                  The <UserStyle> element contains the following elements:

                                  Tag Required? Description

                                  <Name> No The name of the style, used to reference it externally. (Ignored for catalog styles.)

                                  <Title> No The title of the style.

                                  <Abstract> No The description for the style.

                                  <IsDefault> No Whether the style is the default one for a named layer. Used in SLD Library Mode. Values are 1 or 0 (default).

                                  <FeatureTypeStyle> 1..N Defines the symbology for rendering a single feature type.

                                  "},{"location":"styling/sld/reference/styles/#featuretypestyle","title":"FeatureTypeStyle","text":"

                                  The FeatureTypeStyle element specifies the styling that is applied to a single feature type of a layer. It contains a list of rules which determine the symbology to be applied to each feature of a layer.

                                  The <FeatureTypeStyle> element contains the following elements:

                                  Tag Required? Description

                                  <Name> No Not used at present

                                  <Title> No The title for the style.

                                  <Abstract> No The description for the style.

                                  <FeatureTypeName> No Identifies the feature type the style is to be applied to. Omitted if the style applies to all features in a layer.

                                  <Rule> 1..N A styling rule to be evaluated. See Rules

                                  Usually a layer contains only a single feature type, so the <FeatureTypeName> is omitted.

                                  Any number of <FeatureTypeStyle> elements can be specified in a style. In GeoServer each one is rendered into a separate image buffer. After all features are rendered the buffers are composited to form the final layer image. The compositing is done in the order the FeatureTypeStyles are given in the SLD, with the first one on the bottom (the \"Painter's Model\"). This effectively creates \"virtual layers\", which can be used to achieve styling effects such as cased lines.

                                  "},{"location":"styling/sld/reference/textsymbolizer/","title":"TextSymbolizer","text":"

                                  A TextSymbolizer styles features as text labels. Text labels are positioned either at points or along linear paths derived from the geometry being labelled.

                                  Labelling is a complex operation, and effective labelling is crucial to obtaining legible and visually pleasing cartographic output. For this reason SLD provides many options to control label placement. To improve quality even more GeoServer provides additional options and parameters. The usage of the standard and extended options are described in greater detail in the following section on Labeling.

                                  "},{"location":"styling/sld/reference/textsymbolizer/#syntax","title":"Syntax","text":"

                                  A <TextSymbolizer> contains the following elements:

                                  Tag Required? Description

                                  <Geometry> No The geometry to be labelled.

                                  <Label> No The text content for the label.

                                  <Font> No The font information for the label.

                                  <LabelPlacement> No Sets the position of the label relative to its associated geometry.

                                  <Halo> No Creates a colored background around the label text, for improved legibility.

                                  <Fill> No The fill style of the label text.

                                  <Graphic> No A graphic to be displayed behind the label text. See Graphic for content syntax.

                                  <Priority> No The priority of the label during conflict resolution. Content may contains expressions. See also Priority Labeling.

                                  <VendorOption> 0..N A GeoServer-specific option. See Labeling for descriptions of the available options. Any number of options may be specified.

                                  "},{"location":"styling/sld/reference/textsymbolizer/#geometry","title":"Geometry","text":"

                                  The <Geometry> element is optional. If present, it specifies the featuretype property from which to obtain the geometry to label, using a <PropertyName> element. See also Geometry transformations in SLD for GeoServer extensions for specifying geometry.

                                  Any kind of geometry may be labelled with a <TextSymbolizer>. For non-point geometries, a representative point is used (such as the centroid of a line or polygon).

                                  "},{"location":"styling/sld/reference/textsymbolizer/#label","title":"Label","text":"

                                  The <Label> element specifies the text that will be rendered as the label. It allows content of mixed type, which means that the content can be a mixture of string data and Filter Expressions. These are concatenated to form the final label text. If a label is provided directly by a feature property, the content is a single <PropertyName>. Multiple properties can be included in the label, and property values can be manipulated by filter expressions and functions. Additional \"boilerplate\" text can be provided as well. Whitespace can be preserved by surrounding it with XML <![CDATA[ ]]> delimiters.

                                  If this element is omitted, no label is rendered.

                                  "},{"location":"styling/sld/reference/textsymbolizer/#font","title":"Font","text":"

                                  The <Font> element specifies the font to be used for the label. A set of <CssParameter> elements specify the details of the font.

                                  The name attribute indicates what aspect of the font is described, using the standard CSS/SVG font model. The content of the element supplies the value of the font parameter. The value may contain expressions.

                                  "},{"location":"styling/sld/reference/textsymbolizer/#labelplacement","title":"LabelPlacement","text":"

                                  The <LabelPlacement> element specifies the placement of the label relative to the geometry being labelled. There are two possible sub-elements: <PointPlacement> or <LinePlacement>. Exactly one of these must be specified.

                                  Tag Required? Description

                                  <PointPlacement> No Labels a geometry at a single point

                                  <LinePlacement> No Labels a geometry along a linear path

                                  "},{"location":"styling/sld/reference/textsymbolizer/#pointplacement","title":"PointPlacement","text":"

                                  The <PointPlacement> element indicates the label is placed at a labelling point derived from the geometry being labelled. The position of the label relative to the labelling point may be controlled by the following sub-elements:

                                  Tag Required? Description

                                  <AnchorPoint> No The location within the label bounding box that is aligned with the label point. The location is specified by <AnchorPointX> and <AnchorPointY> sub-elements, with values in the range [0..1]. Values may contain expressions.

                                  <Displacement> No Specifies that the label point should be offset from the original point. The offset is specified by <DisplacementX> and <DisplacementY> sub-elements, with values in pixels. Values may contain expressions. Default is (0, 0).

                                  <Rotation> No The rotation of the label in clockwise degrees (negative values are counterclockwise). Value may contain expressions. Default is 0.

                                  The anchor point justification, displacement offsetting, and rotation are applied in that order.

                                  "},{"location":"styling/sld/reference/textsymbolizer/#lineplacement","title":"LinePlacement","text":"

                                  The <LinePlacement> element indicates the label is placed along a linear path derived from the geometry being labelled. The position of the label relative to the linear path may be controlled by the following sub-element:

                                  Tag Required? Description

                                  <PerpendicularOffset> No The offset from the linear path, in pixels. Positive values offset to the left of the line, negative to the right. Value may contain expressions. Default is 0.

                                  The appearance of text along linear paths can be further controlled by the vendor options followLine, maxDisplacement, repeat, labelAllGroup, and maxAngleDelta. These are described in Labeling.

                                  "},{"location":"styling/sld/reference/textsymbolizer/#halo","title":"Halo","text":"

                                  A halo creates a colored background around the label text, which improves readability in low contrast situations. Within the <Halo> element there are two sub-elements which control the appearance of the halo:

                                  Tag Required? Description

                                  <Radius> No The halo radius, in pixels. Value may contain expressions. Default is 1.

                                  <Fill> No The color and opacity of the halo via CssParameter elements for fill and fill-opacity. See Fill for full syntax. The parameter values may contain expressions. Default is a white fill (#FFFFFF) at 100% opacity.

                                  "},{"location":"styling/sld/reference/textsymbolizer/#fill","title":"Fill","text":"

                                  The <Fill> element specifies the fill style for the label text. The syntax is the same as that of the PolygonSymbolizer Fill element. The default fill color is black (#FFFFFF) at 100% opacity..

                                  "},{"location":"styling/sld/reference/textsymbolizer/#graphic","title":"Graphic","text":"

                                  The <Graphic> element specifies a graphic symbol to be displayed behind the label text (if any). A classic use for this is to display \"highway shields\" behind road numbers provided by feature attributes. The element content has the same syntax as the <PointSymbolizer> Graphic element. Graphics can be provided by internal mark symbols, or by external images or SVG files. Their size and aspect ratio can be changed to match the text displayed with them by using the vendor options graphic-resize and graphic-margin.

                                  "},{"location":"styling/sld/reference/textsymbolizer/#example","title":"Example","text":"

                                  The following symbolizer is taken from the Points section in the SLD Cookbook.

                                  <TextSymbolizer>\n  <Label>\n    <ogc:PropertyName>name</ogc:PropertyName>\n  </Label>\n  <Font>\n    <CssParameter name=\"font-family\">Arial</CssParameter>\n    <CssParameter name=\"font-size\">12</CssParameter>\n    <CssParameter name=\"font-style\">normal</CssParameter>\n    <CssParameter name=\"font-weight\">bold</CssParameter>\n  </Font>\n  <LabelPlacement>\n    <PointPlacement>\n      <AnchorPoint>\n        <AnchorPointX>0.5</AnchorPointX>\n        <AnchorPointY>0.0</AnchorPointY>\n      </AnchorPoint>\n      <Displacement>\n        <DisplacementX>0</DisplacementX>\n        <DisplacementY>25</DisplacementY>\n      </Displacement>\n      <Rotation>-45</Rotation>\n    </PointPlacement>\n  </LabelPlacement>\n  <Fill>\n    <CssParameter name=\"fill\">#990099</CssParameter>\n  </Fill>\n</TextSymbolizer>\n

                                  The symbolizer labels features with the text from the name property. The font is Arial in bold at 12 pt size, filled in purple. The labels are centered on the point along their lower edge, then displaced 25 pixels upwards, and finally rotated 45 degrees counterclockwise.

                                  The displacement takes effect before the rotation during rendering, so the 25 pixel vertical displacement is itself rotated 45 degrees.

                                  Point with rotated label

                                  "},{"location":"styling/sld/reference/textsymbolizer/#scalable-font-size","title":"Scalable Font Size","text":"

                                  The font size can also be set depending on the scale denominator as follows:

                                  <CssParameter name=\"font-size\">\n  <ogc:Function name=\"Categorize\">\n    <!-- Value to transform -->\n    <ogc:Function name=\"env\">\n      <ogc:Literal>wms_scale_denominator</ogc:Literal>\n    </ogc:Function>\n    <!-- Output values and thresholds -->\n    <!-- Ranges: -->\n    <!-- [scale <= 300, font 12] -->\n    <!-- [scale 300 - 2500, font 10] -->\n    <!-- [scale > 2500, font 8] -->\n    <ogc:Literal>12</ogc:Literal>\n    <ogc:Literal>300</ogc:Literal>\n    <ogc:Literal>10</ogc:Literal>\n    <ogc:Literal>2500</ogc:Literal>\n    <ogc:Literal>8</ogc:Literal>\n  </ogc:Function>\n</CssParameter>\n

                                  The above example would display text at different sizes depending on the scale denominator setting. A font size of 12 for scale denominator of less than or equal to 300, a font size of 10 for scale denominator from 300-2500 and a font size of 8 for scale denominator greater than 2500.

                                  "},{"location":"styling/sld/tipstricks/","title":"SLD Tips and Tricks","text":"

                                  This section details various advanced strategies for working with SLD.

                                  • Styling mixed geometry types
                                  • Styling using Transformation Functions
                                  "},{"location":"styling/sld/tipstricks/mixed-geometries/","title":"Styling mixed geometry types","text":"

                                  On occasion one might need to style a geometry column whose geometry type can be different for each feature (some are polygons, some are points, etc), and use different styling for different geometry types.

                                  SLD 1.0 does not provide a clean solution for dealing with this situation. Point, Line, and Polygon symbolizers do not select geometry by type, since each can apply to all geometry types:

                                  • Point symbolizers apply to any kind of geometry. If the geometry is not a point, the centroid of the geometry is used.
                                  • Line symbolizers apply to both lines and polygons. For polygons the boundary is styled.
                                  • Polygon symbolizers apply to lines, by adding a closing segment connecting the first and last points of the line.

                                  There is also no standard filter predicate to identify geometry type which could be used in rules.

                                  This section suggests a number of ways to accomplish styling by geometry type. They require either data restructuring or the use of non-standard filter functions.

                                  "},{"location":"styling/sld/tipstricks/mixed-geometries/#restructuring-the-data","title":"Restructuring the data","text":"

                                  There are a few ways to restructure the data so that it can be styled by geometry type using only standard SLD constructs.

                                  "},{"location":"styling/sld/tipstricks/mixed-geometries/#split-the-table","title":"Split the table","text":"

                                  The first and obvious one is to split the original table into a set of separate tables, each one containing a single geometry type. For example, if table findings has a geometry column that can contain point, lines, and polygons, three tables can be created, each one containing a single geometry type.

                                  "},{"location":"styling/sld/tipstricks/mixed-geometries/#separate-geometry-columns","title":"Separate geometry columns","text":"

                                  A second way is to use one table and separate geometry columns. So, if the table findings has a geom column, the restructured table will have point, line and polygon columns, each of them containing just one geometry type. After the restructuring, the symbolizers will refer to a specific geometry, for example:

                                  <PolygonSymbolizer>\n    <Geometry><ogc:PropertyName>polygon</ogc:PropertyName></Geometry>\n</PolygonSymbolizer>\n

                                  This way each symbolizer will match only the geometry types it is supposed to render, and skip over the rows that contain a null value.

                                  "},{"location":"styling/sld/tipstricks/mixed-geometries/#add-a-geometry-type-column","title":"Add a geometry type column","text":"

                                  A third way is to add a geometry type column allowing standard filtering constructs to be used, and then build a separate rule per geometry type. In the example above a new attribute, gtype will be added containing the values Point, Line and Polygon. The following SLD template can be used after the change:

                                  <Rule>\n   <ogc:Filter>\n      <ogc:PropertyIsEqualTo>\n         <ogc:PropertyName>gtype</ogc:PropertyName>\n         <ogc:Literal>Point</ogc:Literal>\n      </ogc:PropertyIsEqualTo>\n   </ogc:Filter>\n   <PointSymbolizer>\n      ...\n   </PointSymbolizer>\n</Rule>\n<Rule>\n   <ogc:Filter>\n      <ogc:PropertyIsEqualTo>\n         <ogc:PropertyName>gtype</ogc:PropertyName>\n         <ogc:Literal>Line</ogc:Literal>\n      </ogc:PropertyIsEqualTo>\n   </ogc:Filter>\n   <LineSymbolizer>\n      ...\n   </LineSymbolizer>\n</Rule>\n<Rule>\n   <ogc:Filter>\n      <ogc:PropertyIsEqualTo>\n         <ogc:PropertyName>gtype</ogc:PropertyName>\n         <ogc:Literal>Polygon</ogc:Literal>\n      </ogc:PropertyIsEqualTo>\n   </ogc:Filter>\n   <PolygonSymbolizer>\n      ...\n   </PolygonSymbolizer>\n</Rule>\n

                                  The above suggestions assume that restructuring the data is technically possible. This is usually true in spatial databases that provide functions that allow determining the geometry type.

                                  "},{"location":"styling/sld/tipstricks/mixed-geometries/#create-views","title":"Create views","text":"

                                  A less invasive way to get the same results without changing the structure of the table is to create views that have the required structure. This allows the original data to be kept intact, and the views may be used for rendering.

                                  "},{"location":"styling/sld/tipstricks/mixed-geometries/#using-sld-rules-and-filter-functions","title":"Using SLD rules and filter functions","text":"

                                  SLD 1.0 uses the OGC Filter 1.0 specification for filtering out the data to be styled by each rule. Filters can contain Filter functions to compute properties of geometric values. In GeoServer, filtering by geometry type can be done using the geometryType or dimension filter functions.

                                  Note

                                  The Filter Encoding specification provides a standard syntax for filter functions, but does not mandate a specific set of functions. SLDs using these functions may not be portable to other styling software.

                                  "},{"location":"styling/sld/tipstricks/mixed-geometries/#geometrytype-function","title":"geometryType function","text":"

                                  The geometryType function takes a geometry property and returns a string, which (currently) is one of the values Point, LineString, LinearRing, Polygon, MultiPoint, MultiLineString, MultiPolygon and GeometryCollection.

                                  Using this function, a Rule matching only single points can be written as:

                                  <Rule>\n   <ogc:PropertyIsEqualTo>\n      <ogc:Function name=\"geometryType\">\n         <ogc:PropertyName>geom</ogc:PropertyName>\n      </ogc:Function>\n      <ogc:Literal>Point</ogc:Literal>\n   </ogc:PropertyIsEqualTo>\n   <PointSymbolizer>\n     ...\n   </PointSymbolizer>\n</Rule>\n

                                  The filter is more complex if it has to match all linear geometry types. In this case, it looks like:

                                  <Rule>\n   <ogc:Filter>\n     <ogc:PropertyIsEqualTo>\n       <ogc:Function name=\"in3\">\n          <ogc:Function name=\"geometryType\">\n              <ogc:PropertyName>geom</ogc:PropertyName>\n          </ogc:Function>\n          <ogc:Literal>LineString</ogc:Literal>\n          <ogc:Literal>LinearRing</ogc:Literal>\n          <ogc:Literal>MultiLineString</ogc:Literal>\n       </ogc:Function>\n       <ogc:Literal>true</ogc:Literal>\n     </ogc:PropertyIsEqualTo>\n   </ogc:Filter>\n   <LineSymbolizer>\n     ...\n   </LineSymbolizer>\n</Rule>\n

                                  This filter is read as geometryType(geom) in (\"LineString\", \"LinearRing\", \"MultiLineString\"). Filter functions in Filter 1.0 have a fixed number of arguments, so there is a series of in functions whose names correspond to the number of arguments they accept: in2, in3, ..., in10.

                                  "},{"location":"styling/sld/tipstricks/mixed-geometries/#dimension-function","title":"dimension function","text":"

                                  A slightly simpler alternative is to use the geometry dimension function to select geometries of a desired dimension. Dimension 0 selects Points and MultiPoints, dimension 1 selects LineStrings, LinearRings and MultiLineStrings, and dimension 2 selects Polygons and MultiPolygons. The following example shows how to select linear geometries:

                                  <Rule>\n   <ogc:PropertyIsEqualTo>\n      <ogc:Function name=\"dimension\">\n         <ogc:PropertyName>geom</ogc:PropertyName>\n      </ogc:Function>\n      <ogc:Literal>1</ogc:Literal>\n   </ogc:PropertyIsEqualTo>\n   <LineSymbolizer>\n     ...\n   </LineSymbolizer>\n</Rule>\n
                                  "},{"location":"styling/sld/tipstricks/transformation-func/","title":"Styling using Transformation Functions","text":"

                                  The Symbology Encoding 1.1 specification defines the following transformation functions:

                                  • Recode transforms a set of discrete attribute values into another set of values
                                  • Categorize transforms a continuous-valued attribute into a set of discrete values
                                  • Interpolate transforms a continuous-valued attribute into another continuous range of values

                                  These functions provide a concise way to compute styling parameters from feature attribute values. GeoServer implements them as Filter functions with the same names.

                                  Note

                                  The GeoServer function syntax is slightly different to the SE 1.1 definition, since the specification defines extra syntax elements which are not available in GeoServer functions.

                                  These functions can make style documents more concise, since they express logic which would otherwise require many separate rules or complex Filter expressions, They even allow logic which is impossible to express any other way. A further advantage is that they often provide superior performance to explicit rules.

                                  One disadvantage of using these functions for styling is that they are not displayed in WMS legend graphics.

                                  "},{"location":"styling/sld/tipstricks/transformation-func/#recode","title":"Recode","text":"

                                  The Recode filter function transforms a set of discrete values for an attribute into another set of values. The function can be used within SLD styling parameters to convert the value of a feature attribute into specific values for a parameter such as color, size, width, opacity, etc.

                                  The recoding is defined by a set of (input, output) value pairs.

                                  "},{"location":"styling/sld/tipstricks/transformation-func/#example","title":"Example","text":"

                                  Consider a chloropleth map of the US states dataset using the fill color to indicate the topographic regions for the states. The dataset has an attribute SUB_REGION containing the region code for each state. The Recode function is used to map each region code into a different color.

                                  The symbolizer for this style is:

                                  <PolygonSymbolizer>\n   <Fill>\n     <CssParameter name=\"fill\">\n       <ogc:Function name=\"Recode\">\n         <!-- Value to transform -->\n         <ogc:Function name=\"strTrim\">\n           <ogc:PropertyName>SUB_REGION</ogc:PropertyName>\n         </ogc:Function>\n\n         <!-- Map of input to output values -->\n         <ogc:Literal>N Eng</ogc:Literal>\n         <ogc:Literal>#6495ED</ogc:Literal>\n\n         <ogc:Literal>Mid Atl</ogc:Literal>\n         <ogc:Literal>#B0C4DE</ogc:Literal>\n\n         <ogc:Literal>S Atl</ogc:Literal>\n         <ogc:Literal>#00FFFF</ogc:Literal>  \n\n         <ogc:Literal>E N Cen</ogc:Literal>\n         <ogc:Literal>#9ACD32</ogc:Literal>\n\n         <ogc:Literal>E S Cen</ogc:Literal>\n         <ogc:Literal>#00FA9A</ogc:Literal>\n\n         <ogc:Literal>W N Cen</ogc:Literal>\n         <ogc:Literal>#FFF8DC</ogc:Literal>\n\n         <ogc:Literal>W S Cen</ogc:Literal>\n         <ogc:Literal>#F5DEB3</ogc:Literal>\n\n         <ogc:Literal>Mtn</ogc:Literal>\n         <ogc:Literal>#F4A460</ogc:Literal>\n\n         <ogc:Literal>Pacific</ogc:Literal>\n         <ogc:Literal>#87CEEB</ogc:Literal>\n       </ogc:Function>  \n     </CssParameter>\n   </Fill>\n</PolygonSymbolizer>\n

                                  This style produces the following output:

                                  "},{"location":"styling/sld/tipstricks/transformation-func/#categorize","title":"Categorize","text":"

                                  The Categorize filter function transforms a continuous-valued attribute into a set of discrete values. The function can be used within SLD styling parameters to convert the value of a feature attribute into specific values for a parameter such as color, size, width, opacity, etc.

                                  The categorization is defined by a list of alternating output values and data thresholds. The threshold values define the breaks between the input ranges. Inputs are converted into output values depending on which range they fall in.

                                  "},{"location":"styling/sld/tipstricks/transformation-func/#example_1","title":"Example","text":"

                                  Consider a chloropleth map of the US states dataset using the fill color to indicate a categorization of the states by population. The dataset has attributes PERSONS and LAND_KM from which the population density is computed using the Div operator. This value is input to the Categorize function, which is used to assign different colors to the density ranges [ <= 20], [20 - 100], and [ > 100].

                                  The symbolizer for this style is:

                                  <PolygonSymbolizer>\n   <Fill>\n     <CssParameter name=\"fill\">\n       <ogc:Function name=\"Categorize\">\n         <!-- Value to transform -->\n         <ogc:Div>\n           <ogc:PropertyName>PERSONS</ogc:PropertyName>\n           <ogc:PropertyName>LAND_KM</ogc:PropertyName>\n         </ogc:Div>\n\n         <!-- Output values and thresholds -->\n         <ogc:Literal>#87CEEB</ogc:Literal>\n         <ogc:Literal>20</ogc:Literal>\n         <ogc:Literal>#FFFACD</ogc:Literal>\n         <ogc:Literal>100</ogc:Literal>\n         <ogc:Literal>#F08080</ogc:Literal>\n\n       </ogc:Function>  \n     </CssParameter>\n   </Fill>\n</PolygonSymbolizer>\n

                                  This style produces the following output:

                                  "},{"location":"styling/sld/tipstricks/transformation-func/#interpolate","title":"Interpolate","text":"

                                  The Interpolate filter function transforms a continuous-valued attribute into another continuous range of values. The function can be used within SLD styling parameters to convert the value of a feature attribute into a continuous-valued parameter such as color, size, width, opacity, etc.

                                  The transformation is defined by a set of (input, output) control points chosen along a desired mapping curve. Piecewise interpolation along the curve is used to compute an output value for any input value.

                                  The function is able to compute either numeric or color values as output. This is known as the interpolation method, and is specified by an optional parameter with a value of numeric (the default) or color.

                                  The shape of the mapping curve between control points is specified by the interpolation mode, which is an optional parameter with values of linear (the default), cubic, or cosine.

                                  "},{"location":"styling/sld/tipstricks/transformation-func/#example_2","title":"Example","text":"

                                  Interpolating over color ranges allows concise definition of continuously-varying colors for chloropleth (thematic) maps. As an example, consider a map of the US states dataset using the fill color to indicate the population of the states. The dataset has an attribute PERSONS containing the population of each state. The population values lie in the range 0 to around 30,000,000. The interpolation curve is defined by three control points which assign colors to the population levels 0, 9,000,000 and 23,000,000. The colors for population values are computed by piecewise linear interpolation along this curve. For example, a state with a population of 16,000,000 is displayed with a color midway between the ones for the middle and upper control points. States with populations greater than 23,000,000 are displayed with the last color.

                                  Because the interpolation is being performed over color values, the method parameter is supplied, with a value of color. Since the default linear interpolation is used, no interpolation mode is supplied,

                                  The symbolizer for this style is:

                                  <PolygonSymbolizer>\n   <Fill>\n     <CssParameter name=\"fill\">\n       <ogc:Function name=\"Interpolate\">\n         <!-- Property to transform -->\n         <ogc:PropertyName>PERSONS</ogc:PropertyName>\n\n         <!-- Mapping curve definition pairs (input, output) -->\n         <ogc:Literal>0</ogc:Literal>\n         <ogc:Literal>#fefeee</ogc:Literal>\n\n         <ogc:Literal>9000000</ogc:Literal>\n         <ogc:Literal>#00ff00</ogc:Literal>\n\n         <ogc:Literal>23000000</ogc:Literal>\n         <ogc:Literal>#ff0000</ogc:Literal>\n\n         <!-- Interpolation method -->\n         <ogc:Literal>color</ogc:Literal>\n\n         <!-- Interpolation mode - defaults to linear -->\n       </ogc:Function>  \n     </CssParameter>\n   </Fill>\n</PolygonSymbolizer>\n

                                  This symbolizer produces the following output:

                                  "},{"location":"styling/webadmin/","title":"Styles","text":"

                                  This section will detail how to work with the styles pages in the Web administration interface. For more information on styles and syntax, please see the main section on Styling.

                                  Styles are used to control the appearance of geospatial data. Styles for GeoServer are written in a number of different formats:

                                  • Styled Layer Descriptor (SLD): An OGC standard for geospatial styling. Available by default.
                                  • Cascading Style Sheets (CSS): A CSS-like syntax. Available via an extension.
                                  • YSLD: An SLD-equivalent based on YAML for improved authoring. Available via the ysld extension .
                                  • MBStyle: A syntax based on JSON for improved interoperability. Available via the mbstyle extension .
                                  "},{"location":"styling/webadmin/#styling_webadmin_styles","title":"Styles page","text":"

                                  On the Styles page, you can add a new style, remove a style, or view or edit an existing style.

                                  Styles page

                                  "},{"location":"styling/webadmin/#styling_webadmin_add","title":"Add a Style","text":"

                                  The buttons for adding and removing a style can be found at the top of the Styles page.

                                  Adding or removing a style

                                  To add a new style, click Add a new style button. You will be redirected to the new style page, which is the same as the Style Editor Data tab.

                                  The editor page provides several options for submitting a new style:

                                  • Type the style definition directly into the editor.

                                  • Generate a new default style based on an internal template:

                                    Generating a new default style.

                                  • Copy the contents of an existing style into the editor:

                                    Copying an existing Style from GeoServer

                                  • Upload a local file that contains the style:

                                    Uploading an file from the local system

                                  When creating a style, only the Data tab will be available. Click Apply on the new style to stay on the Style Editor page and gain access to all tabs.

                                  "},{"location":"styling/webadmin/#styling_webadmin_remove","title":"Remove a Style","text":"

                                  To remove a style, click the check box next to the style. Multiple styles can be selected at the same time. Click the Remove selected style(s) link at the top of the page. You will be asked for confirmation:

                                  Confirmation prompt for removing styles

                                  Click OK to remove the selected style(s).

                                  "},{"location":"styling/webadmin/#styling_webadmin_edit","title":"Style Editor","text":"

                                  On the Styles page, click a style name to open the Style Editor.

                                  The Style Editor page presents the style definition. The page contains four tabs with many configuration options:

                                  • Data: Includes basic style information, the ability to generate a style, and legend details
                                  • Publishing: Displays which layers are using this style
                                  • Layer Preview: Previews the style with an associated layer while editing
                                  • Layer Attributes: Displays a list of attributes for the associated layer

                                  Style Editor tabs

                                  At the bottom of the Style Editor page is a number of options:

                                  Option Description

                                  Validate Will test the current style for correctness according to the Format option selected. For SLD styles, it will check compliance against the SLD schema. Mind, the parser might be able to read and work with a formally incorrect style.

                                  Save Makes the changes to the style and returns to the Styles page

                                  Apply Makes the changes to the style and remain on the Style Editor page. This is useful to update the Layer Preview tab.

                                  Cancel Cancels all changes to the style and returns to the Styles page

                                  Style Editor options

                                  "},{"location":"styling/webadmin/#styling_webadmin_edit_definition","title":"Style definition","text":"

                                  On all tabs, the Style Editor will display the style definition at the bottom, allowing for direct editing of the style. Switch between the tabs in order to facilitate style creation and editing.

                                  Style editor

                                  The style editor supports line numbering, automatic indentation, and real-time syntax highlighting. You can also increase or decrease the font size of the editor.

                                  Button Description

                                  Undo

                                  Redo

                                  Go to line

                                  Find in style text (CTRL-F)

                                  Find next occurrence in style text (CTRL-G/Cmd-G)

                                  Find and replace in style text (CTRL-SHIFT-F/Cmd-Option-F). First enter the search term, press ENTER, then type the replace term and press ENTER again. It is also possible to run \"replace all\" using CTRL-SHIFT-R/Cmd-Shift-Option-F.

                                  Auto-format the editor contents

                                  Change the font size in the editor

                                  Insert image into style (choose existing or upload)

                                  Change height of style editor (disabled in full screen mode)

                                  During editing and especially after editing is complete, you will want to check validation of the syntax. This can be done by clicking the Validate button at the bottom.

                                  If no errors are found, you will see this message:

                                  No validation errors

                                  If any validation errors are found, they will be displayed:

                                  Validation error message

                                  "},{"location":"styling/webadmin/#styling_webadmin_edit_data","title":"Style Editor: Data tab","text":"

                                  The Data tab includes basic style information, the ability to generate a style, and legend details.

                                  The Style Data area has mandatory basic style information:

                                  Option Description

                                  Name Name of the style

                                  Workspace Workspace in which the style is contained. Styles can be inside workspaces, but can also be \"global\" (no workspace).

                                  Format Format of the style. Options are SLD, CSS, and YSLD, MBStyle depending on availability.

                                  Style Data area

                                  The Style Content area allows you to generate a style, copy an existing style, or upload an existing style:

                                  Option Description

                                  Generate a default style Selects a generic style based on geometry. Options are Point, Line, Polygon, Raster, and Generic. Click Generate when selected.

                                  Copy from existing style Selects an existing style in GeoServer and copy its contents to this style. Any style in GeoServer is available as an option. Not all styles will work with all layers. Click Copy when selected.

                                  Upload a style file Selects a plain text file on your local system to add as the style. Click Upload when selected.

                                  Style Content area

                                  The Legend area allows you to add, modify, or delete a custom style, and preview the legend for the style. By default GeoServer will generate a legend based on your style file, but this can be customized here:

                                  Option Description

                                  Add legend Allows you to use a custom legend

                                  Online Resource Path to the custom legend graphic to use. Can be a URL or a local path (relative to the style file path). See Structure of the data directory for a description of the styles directory.

                                  Auto-detect image size and type Populates the Width, Height, and Format options for the Online Resource

                                  Width Width of the custom legend graphic

                                  Height Height of the custom legend graphic

                                  Format Mime type of the custom legend graphic

                                  Discard legend Will remove the settings for the custom legend graphic and will instead use the default generated legend.

                                  Preview legend Previews the legend based on the current settings

                                  Choose Image Insert image into style (choose existing or upload)

                                  Legend area

                                  Choose Image Dialog

                                  "},{"location":"styling/webadmin/#styling_webadmin_edit_publishing","title":"Style Editor: Publishing tab","text":"

                                  The Publishing tab displays a list of all layers on the server, with the purpose of showing which layers are associated with the current style. Layers can set a single default style and have any number of additional styles. If this style is set to be either of these options for a layer, it will be shown with a check box in the table.

                                  Option Description

                                  Workspace Workspace of the layer

                                  Layer Name of the layer

                                  Default Shows whether the style being edited is the default for a given layer

                                  Associated Shows whether the style being edited is an additional style for a given layer

                                  Publishing tab

                                  "},{"location":"styling/webadmin/#styling_webadmin_edit_preview","title":"Style Editor: Layer Preview tab","text":"

                                  It is very common to have to iterate your styles and test how the visualization changes over time. The Layer Preview tab allows you to make changes to the style and see them without having to navigate away from the page.

                                  The Layer Preview tab shows a single image. GeoServer tries to identify which layer should be shown (for example, a layer for which this style is the default), but if the layer being previewed is not the desired one, click the layer name above the preview box and select a layer.

                                  Layer Preview tab

                                  "},{"location":"styling/webadmin/#styling_webadmin_edit_attributes","title":"Style Editor: Layer Attributes tab","text":"

                                  Most styles utilize the specific values of certain attributes of the associated layer in order to create more detailed and useful styles. (For example: styling all large cities different from small cities based on a particular attribute.)

                                  The Layer Attributes tab will display a list of attributes for the given associated layer. GeoServer tries to identify which layer should be shown (for example, a layer for which this style is the default), but if the layer being previewed is not the desired one, click the layer name above the table and select a layer.

                                  Option Description

                                  name Name of the attribute

                                  type Type of the attribute. Can be a numeric (such as \"Long\"), a string (\"String\"), or a geometry (such as \"Point\").

                                  sample Sample value of the attribute taken from the data

                                  min Minimum value of the attribute in the data set, if applicable

                                  max Minimum value of the attribute in the data set, if applicable

                                  computeStats Click Compute to calculate the min and max values for that attribute, if applicable

                                  Layer Attributes tab

                                  "},{"location":"styling/webadmin/#style-editor-full-screen-side-by-side-mode","title":"Style Editor: full screen side by side mode","text":"

                                  The style editor page has now a \"outwards arrows\" button on the top right side of the window:

                                  The new fullscreen functionality

                                  Pressing it will cause the editor and preview to go side by side and use the entire browser window space:

                                  Side by side style editing

                                  The button turns into a \"inwards arrows\" icon, pressing it resumes the original editing mode.

                                  "},{"location":"styling/workshop/","title":"Styling Workshop","text":"

                                  This workshop will explore how GeoServer styling can be used for a range of creative effects. This workshop also introduces both the CSS and YSLD extensions, which provide alternate styling languages to SLD.

                                  The following material will be covered in this workshop:

                                  setup/index

                                  Workshop materials and setup

                                  design/index

                                  Overview of map design (i.e. cartography) considerations. Select color palette with colorbrewer.

                                  css/index

                                  Introduction to GeoServer styling followed by easy styling with the CSS module.

                                  ysld/index

                                  Introduction to GeoServer styling followed by easy styling with the YSLD module.

                                  mbstyle/index

                                  Introduction to GeoServer styling followed by easy styling with the MBStyle module.

                                  "},{"location":"styling/workshop/css/","title":"CSS Styling Workbook","text":"

                                  GeoServer styling can be used for a range of creative effects. This section introduces the CSS Extension which can be used to quickly generate SLD files.

                                  • CSS Quickstart
                                  • Lines
                                  • Polygons
                                  • Points
                                  • Rasters
                                  • CSS Workbook Conclusion
                                  "},{"location":"styling/workshop/css/css/","title":"CSS Quickstart","text":"

                                  In the last section, we saw how the OGC defines style using XML documents (called SLD files).

                                  We will now explore GeoServer styling in greater detail using a tool to generate our SLD files. The Cascading Style Sheet (CSS) GeoServer extension is used to generate SLD files using a syntax more familiar to web developers.

                                  Using the CSS extension to define styles results in shorter examples that are easier to understand. At any point we will be able to review the generated SLD file.

                                  "},{"location":"styling/workshop/css/css/#syntax","title":"Syntax","text":"

                                  This section provides a quick introduction to CSS syntax for mapping professionals who may not be familiar with web design.

                                  "},{"location":"styling/workshop/css/css/#key-properties","title":"Key properties","text":"

                                  As we work through CSS styling examples you will note the use of key properties. These properties are required to trigger the creation of an appropriate symbolizer in SLD.

                                  stroke Color (or graphic) for LineString or Polygon border fill Color (or graphic) for Polygon Fill mark Well-known Mark or graphic used for Point label Text expression labeling halo-radius Size of halo used to outline label

                                  Using just these key properties and the selector *, you will be able to visualize vector data.

                                  For example, here is the key property stroke providing a gray representation for line or polygon data:

                                  * {\n   stroke: gray;\n}\n

                                  Here is the key property fill providing a blue fill for polygon data:

                                  * {\n   fill: #2020ED;\n}\n

                                  Here is the key property mark showing the use of the well-known symbol square:

                                  * {\n   mark: symbol(square);\n}\n

                                  Here is the key property label generating labels using the CITY_NAME feature attribute:

                                  * {\n   label: [CITY_NAME];\n}\n

                                  Here is the key property halo-radius providing an outline around generated label:

                                  * {\n   label: [NAME];\n   halo-radius: 1;\n}\n

                                  Reference:

                                  • CSS Cookbook
                                  • CSS Examples
                                  "},{"location":"styling/workshop/css/css/#rules","title":"Rules","text":"

                                  We have already seen a CSS style composed of a single rule:

                                  * {\n  mark: symbol(circle);\n}\n

                                  We can also make a rule that only applies to a specific FeatureType:

                                  populated_places {\n  mark: symbol(triangle);\n}\n

                                  We can make a style consisting of more than one rule, carefully choosing the selector for each rule. In this case we are using a selector to style capital cities with a star, and non-capital with a circle:

                                  [ FEATURECLA = 'Admin-0 capital' ] {\n  mark: symbol(star);\n  mark-size: 6px;\n}\n\n[ FEATURECLA <> 'Admin-0 capital' ] {\n  mark: symbol(circle);\n  mark-size: 6px;\n}\n

                                  The feature attribute test performed above uses Constraint Query Language (CQL). This syntax can be used to define filters to select content, similar to how the SQL WHERE statement is used. It can also be used to define expressions to access attribute values allowing their use when defining style properties.

                                  Rule selectors can also be triggered based on the state of the rendering engine. In this example we are only applying labels when zoomed in:

                                  [@scale < 20000000] {\n   label: [ NAME ];\n}\n

                                  In the above example the label is defined using the CQL Expression NAME. This results in a dynamic style that generates each label on a case-by-case basis, filling in the label with the feature attribute NAME.

                                  Reference:

                                  • Filter Syntax
                                  • ECQL Reference
                                  "},{"location":"styling/workshop/css/css/#cascading","title":"Cascading","text":"

                                  In the above example feature attribute selection we repeated information. An alternate approach is to make use of CSS Cascading and factor out common properties into a general rule:

                                  [ FEATURECLA = 'Admin-0 capital' ] {\n  mark: symbol(star);\n}\n\n[ FEATURECLA <> 'Admin-0 capital' ] {\n  mark: symbol(circle);\n}\n\n* {\n  mark-size: 6px;\n}\n
                                  "},{"location":"styling/workshop/css/css/#pseudo-selector","title":"Pseudo-selector","text":"

                                  Up to this point we have been styling individual features, documenting how each shape is represented.

                                  When a shape is represented using a symbol, we have a second challenge: documenting the colors and appearance of the symbol. The CSS extension provides a pseudo-selector allowing further properties to be applied to a symbol.

                                  Example of using a pseudo-selector:

                                  * {\n  mark: symbol(circle);\n}\n\n:mark {\n  fill: black;\n  stroke: white;\n}\n

                                  In this example the :mark pseudo-selector is used select the circle mark, and provides a fill and stroke for use when rendering.

                                  Pseudo-selector Use of symbol :mark point markers :stroke stroke patterns :fill fill patterns :shield label shield :symbol any use

                                  The above pseudo-selectors apply to all symbols, but to be specific the syntax nth-symbol(1) can be used:

                                  * {\n  mark: symbol(circle);\n}\n\n:nth-mark(1) {\n  fill: black;\n  stroke: white;\n}\n

                                  Reference:

                                  • Styled Marks (User Guide)
                                  "},{"location":"styling/workshop/css/css/#compare-css-to-sld","title":"Compare CSS to SLD","text":"

                                  The CSS extension is built with the same GeoServer rendering engine in mind, providing access to all the functionality of SLD (along with vendor options for fine control of labeling). The two approaches use slightly different terminology: SLD uses terms familiar to mapping professionals, CSS uses ideas familiar to web developers.

                                  "},{"location":"styling/workshop/css/css/#sld-style","title":"SLD Style","text":"

                                  SLD makes use of a series of Rules to select content for display. Content is selected using filters that support attribute, spatial and temporal queries.

                                  Once selected, content is transformed into a shape and drawn using symbolizers. Symbolizers are configured using CSS Properties to document settings such as \"fill\" and \"opacity\".

                                  Content can be drawn by more than one rule, allowing for a range of effects.

                                  Here is an example SLD file for reference:

                                  <?xml version=\"1.0\" encoding=\"ISO-8859-1\"?>\n<StyledLayerDescriptor version=\"1.0.0\"\n xsi:schemaLocation=\"http://www.opengis.net/sld StyledLayerDescriptor.xsd\"\n xmlns=\"http://www.opengis.net/sld\"\n xmlns:ogc=\"http://www.opengis.net/ogc\"\n xmlns:xlink=\"http://www.w3.org/1999/xlink\"\n xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\">\n  <NamedLayer>\n    <Name>airports</Name>\n    <UserStyle>\n      <Title>Airports</Title>\n      <FeatureTypeStyle>\n        <Rule>\n          <Name>airports</Name>\n          <Title>Airports</Title>\n            <PointSymbolizer>\n              <Graphic>\n                <ExternalGraphic>\n                  <OnlineResource xlink:type=\"simple\"\n                  xlink:href=\"airport.svg\" />\n                  <Format>image/svg</Format>\n                </ExternalGraphic>\n                <ExternalGraphic>\n                  <OnlineResource xlink:type=\"simple\"\n                  xlink:href=\"airport.png\" />\n                  <Format>image/png</Format>\n                </ExternalGraphic>\n                <Mark>\n                  <WellKnownName>triangle</WellKnownName>\n                  <Fill>\n                    <CssParameter name=\"fill\">#000000</CssParameter>\n                  </Fill>\n                  <Stroke>\n                    <CssParameter name=\"stroke\">#FFFFFF</CssParameter>\n                    <CssParameter name=\"stroke-opacity\">0.50</CssParameter>\n                  </Stroke>\n                </Mark>\n              <Size>16</Size>\n            </Graphic>\n          </PointSymbolizer>\n        </Rule>\n      </FeatureTypeStyle>\n    </UserStyle>\n  </NamedLayer>\n</StyledLayerDescriptor>\n
                                  "},{"location":"styling/workshop/css/css/#css-style","title":"CSS Style","text":"

                                  CSS also makes use of rules, each rule making use of selectors to shortlist content for display. Each selector uses a CQL filter that supports attribute, spatial and temporal queries. Once selected, CSS Properties are used to describe how content is rendered.

                                  Content is not drawn by more than one rule. When content satisfies the conditions of more than one rule the resulting properties are combined using a process called inheritance. This technique of having a generic rule that is refined for specific cases is where the Cascading in Cascading Style Sheet comes from.

                                  Here is an example using CSS:

                                  * {\n  mark: url(airport.svg);\n  mark-mime: \"image/svg\";\n}\n

                                  In this rule the selector * is used to match all content. The rule defines properties indicating how this content is to be styled. The property mark is used to indicate we want this content drawn as a Point. The value url(airport.svg) is a URL reference to the image file used to represent each point. The mark-mime property indicates the expected format of this image file.

                                  "},{"location":"styling/workshop/css/css/#tour","title":"Tour","text":"

                                  To confirm everything works, let's reproduce the airports style above.

                                  1. Navigate to the Styles page.

                                  2. Each time we edit a style, the contents of the associated SLD file are replaced. Rather than disrupt any of our existing styles we will create a new style. Click Add a new style and choose the following:

                                    Name: airport0

                                    Workspace: (none specified)

                                    Format: CSS

                                  3. Replace the initial YSLD definition with our airport CSS example and click Apply:

                                    * {\n  mark: url(airport.svg);\n  mark-mime: \"image/svg\";\n}\n
                                  4. Click the Layer Preview tab to preview the style. We want to preview on the airports layer, so click the name of the current layer and select ne:airports from the list that appears. You can use the mouse buttons to pan and scroll wheel to change scale.

                                    Choosing the airports layer

                                    Layer preview

                                  5. Click Layer Data for a summary of the selected data.

                                    Layer attributes

                                  "},{"location":"styling/workshop/css/css/#bonus","title":"Bonus","text":"

                                  Finished early? For now please help your neighbour so we can proceed with the workshop.

                                  If you are really stuck please consider the following challenge rather than skipping ahead.

                                  "},{"location":"styling/workshop/css/css/#explore-data","title":"Explore Data","text":"
                                  1. Return to the Data tab and use the Compute link to determine the minimum and maximum for the scalerank attribute.
                                  "},{"location":"styling/workshop/css/css/#challenge-compare-sld-generation","title":"Challenge Compare SLD Generation","text":"

                                  # The rest API can be used to review your CSS file directly.

                                  Browser:

                                  • Command line:

                                    curl -v -u admin:geoserver -XGET http://localhost:8080/geoserver/rest/styles/airports0.css\n
                                    1. The REST API can also be used generate an SLD file:

                                      Browser:

                                      • Command line:

                                        curl -v -u admin:geoserver -XGET http://localhost:8080/geoserver/rest/styles/airports0.sld?pretty=true\n
                                        1. Compare the generated SLD differ above with the handwritten SLD file used as an example?

                                          Challenge: What differences can you spot?

                                          Instructor Notes

                                          Generated SLD does not include name or title information; this can be added by students using an annotation. Encourage students to look this up in the reference material provided.

                                          The second difference is with the use of a fallback Mark when defining a PointSymbolizer. The CSS extension does not bother with a fallback as it knows the capabilities of the GeoServer rendering engine (and is not trying to create a reusable style).

                                        "},{"location":"styling/workshop/css/done/","title":"CSS Workbook Conclusion","text":"

                                        We hope you have enjoyed this styling workshop.

                                        Additional resources:

                                        • CSS Extension
                                        • CSS Cookbook
                                        "},{"location":"styling/workshop/css/done/#css-workbook-answer-key","title":"CSS Workbook Answer Key","text":"

                                        The following questions were listed throughout the workshop as an opportunity to explore the material in greater depth. Please do your best to consider the questions in detail prior to checking here for the answer. Questions are provided to teach valuable skills, such as a chance to understand how feature type styles are used to control z-order, or where to locate information in the user manual.

                                        "},{"location":"styling/workshop/css/done/#css.line.a0","title":"SLD Generation","text":"

                                        Answer for Challenge SLD Generation <css.line.q0>:

                                        1. Generate the SLD for the following CSS.

                                          * {\n  stroke: black;\n}\n
                                        2. Challenge: What is unusual about the generated SLD? Can you explain why it still works as expected?

                                          The generated SLD does not contain any stroke properties, even though black was specified:

                                          <sld:LineSymbolizer>\n  <sld:Stroke/>\n</sld:LineSymbolizer>\n

                                          SLD considers black the default stroke color for a LineSymbolizer, so no further detail was required.

                                        "},{"location":"styling/workshop/css/done/#css.line.a1","title":"Classification","text":"

                                        Answer for Challenge Classification <css.line.q1>:

                                        1. Challenge: Create a new style adjust road appearance based on type.

                                          Hint: The available values are 'Major Highway','Secondary Highway','Road' and 'Unknown'.

                                        2. Here is an example:

                                          [type = 'Major Highway' ] {\n    stroke: #000088;\n    stroke-width: 1.25;\n}\n[type = 'Secondary Highway' ]{\n    stroke: #8888AA;\n    stroke-width: 0.75;\n}\n[type = 'Road']{\n    stroke: #888888;\n    stroke-width: .75;\n}\n[type = 'Unknown' ]{\n    stroke: #888888;\n    stroke-width: 0.5;\n}\n* {\n   stroke: #AAAAAA;\n   stroke-opacity: 0.25;\n   stroke-width: 0.5;\n}\n
                                        "},{"location":"styling/workshop/css/done/#css.line.a2","title":"SLD Z-Index Generation","text":"

                                        Answer for Challenge SLD Z-Index Generation <css.line.q2>:

                                        1. Review the SLD generated by the z-index example.

                                          * {\n  stroke: black, #8080E6;\n  stroke-width: 5px, 3px;\n  z-index: 0, 1;\n}\n
                                        2. Challenge: There is an interesting trick in the generated SLD, can you explain how it works?

                                        3. The Z-Order example produces multiple FeatureTypeSytle definitions, each acting like an \"inner layer\".

                                          Each FeatureTypeStyle is rendered into its own raster, and the results merged in order. The legend shown in the map preview also provides a hint, as the rule from each FeatureType style is shown.

                                        "},{"location":"styling/workshop/css/done/#css.line.a3","title":"Label Shields","text":"

                                        Answer for Challenge Label Shields <css.line.q2>:

                                        1. The traditional presentation of roads in the US is the use of a shield symbol, with the road number marked on top.

                                        1. Challenge: Have a look at the documentation and reproduce this technique.

                                        2. The use of a label shield is a vendor specific capability of the GeoServer rendering engine. The tricky part of this exercise is finding the documentation online ( i.e. Styled Marks in CSS).

                                          * {\n    stroke: black,lightgray;\n    stroke-width: 3,2;\n    label: [name];\n    font-family: 'Ariel';\n    font-size: 10;\n    font-fill: black;\n    shield: symbol(square);\n}\n:shield {\n    fill: white;\n    stroke: black;\n    size: 18;\n}\n
                                        "},{"location":"styling/workshop/css/done/#css.polygon.a1","title":"Antialiasing","text":"

                                        Answer for Explore Antialiasing <css.polygon.q1>:

                                        1. When we rendered our initial preview, without a stroke, thin white gaps (or slivers) are visible between our polygons.

                                          This effect is made more pronounced by the rendering engine making use of the Java 2D sub-pixel accuracy. This technique is primarily used to prevent an aliased (stair-stepped) appearance on diagonal lines.

                                        2. Explore: Experiment with fill and stroke settings to eliminate slivers between polygons.

                                          The obvious approach works - setting both values to the same color:

                                          symbolizers:\n- polygon:\n    stroke-color: 'lightgrey'\n    stroke-width: 1\n    fill-color: 'lightgrey'\n
                                        "},{"location":"styling/workshop/css/done/#css.polygon.a2","title":"Categorize","text":"

                                        Answer for Explore Categorize <css.polygon.q2>:

                                        1. An exciting use of the GeoServer shape symbols is the theming by changing the size used for pattern density.

                                        2. Explore: Use the Categorize function to theme by datarank.

                                          Example:

                                          .. code-block:: css\n\n   * {\n     fill: symbol('shape://slash');\n     fill-size: [\n        Categorize(datarank,\n         4, 4,\n         5, 6,\n         8, 10,\n        10)\n     ];\n     stroke: black;\n   }\n   :fill {\n     stroke: darkgray;\n   }\n
                                        "},{"location":"styling/workshop/css/done/#css.polygon.a4","title":"Halo","text":"

                                        Answer for Challenge Halo <css.polygon.q4>:

                                        1. The halo example used the fill color and opacity for a muted halo, while this improved readability it did not bring attention to our labels.

                                          A common design choice for emphasis is to outline the text in a contrasting color.

                                        2. Challenge: Produce a map that uses a white halo around black text.

                                          Here is an example:

                                          * {  stroke: gray;\n     fill: #7EB5D3;\n     label: [name];\n     label-anchor: 0.5 0.5;\n     font-fill: black;\n     font-family: \"Arial\";\n     font-size: 14;\n     halo-radius: 1;\n     halo-color: white;\n   }\n
                                        "},{"location":"styling/workshop/css/done/#css.polygon.a5","title":"Theming using Multiple Attributes","text":"

                                        Answer for Challenge Theming using Multiple Attributes <css.polygon.q5>:

                                        1. A powerful tool is theming using multiple attributes. This is an important concept allowing map readers to perform \"integration by eyeball\" (detecting correlations between attribute values information).

                                        2. Challenge: Combine the mapcolor9 and datarank examples to reproduce the following map.

                                          This should be a cut and paste using the recode example, and categorize examples already provided.

                                          * {\n   fill: [\n    recode(mapcolor9,\n      1,'#8dd3c7', 2,'#ffffb3', 3,'#bebada',\n      4,'#fb8072', 5,'#80b1d3', 6,'#fdb462',\n      7,'#b3de69', 8,'#fccde5', 9,'#d9d9d9')\n   ], symbol('shape://slash');\n\n   fill-size: '',[\n      Categorize(datarank,\n       6, 4,\n       8, 6,\n      10, 10,\n      12)\n   ];\n   stroke: black;\n}\n:fill {\n   stroke: black;\n}\n
                                        "},{"location":"styling/workshop/css/done/#css.polygon.a6","title":"Use of Use of Z-Index","text":"

                                        Answer for Challenge Use of Z-Index <css.polygon.q6>:

                                        1. Earlier we looked at using z-index to simulate line string casing. The line work was drawn twice, once with thick line, and then a second time with a thinner line. The resulting effect is similar to text halos - providing breathing space around complex line work allowing it to stand out.

                                        2. Challenge: Use what you know of LineString z-index to reproduce the following map:

                                          This is a tricky challenge. While it is easy enough to introduce z-index to control stroke what is not immediately obvious is that z-order also controls fill order. The previous examples illustrate how to introduce z-order, some thought is required to untangle fill and stroke z-order (dummy stroke definitions need to be introduced using empty commas).

                                          * {\n  fill: lightgray, symbol('shape://slash');\n  fill-size: 8px;\n  stroke: '','',lightgray, black;\n  stroke-width: '','',6,1.5;\n  z-index: 1,2,3,4;\n}\n:fill {\n  stroke: black;\n  stroke-width: 0.75;\n}\n

                                          The included legend should be a large clue about what is going on.

                                        "},{"location":"styling/workshop/css/done/#css.point.a1","title":"Geometry Location","text":"

                                        Answer for Challenge Geometry Location <css.point.q1>:

                                        1. The mark property can be used to render any geometry content.

                                        2. Challenge: Try this yourself by rendering a polygon layer using a mark property.

                                          This can be done one of two ways:

                                          • Changing the association of a polygon layer, such as ne:states_provinces_shp to point_example and using the layer preview page.
                                          • Changing the Layer Preview tab to a polygon layer, such as ne:states_provinces_shp.

                                          The important thing to notice is that the centroid of each polygon is used as a point location.

                                        "},{"location":"styling/workshop/css/done/#css.point.a2","title":"Dynamic Symbolization","text":"

                                        Answer for Explore Dynamic Symbolization <css.point.q2>:

                                        1. SLD Mark and ExternalGraphic provide an opportunity for dynamic symbolization.

                                          This is accomplished by embedding a small CQL expression in the string passed to symbol or url. This sub-expression is isolated with \\${ } as shown:

                                          - point:\n    symbols:\n    - mark:\n        shape: ${if_then_else(equalTo(FEATURECLA,'Admin-0 capital'),'star','circle')}\n
                                        2. Challenge: Use this approach to rewrite the Dynamic Styling example.

                                          Example available here point_example.css

                                          [@scale < 4000000]{ mark: symbol(

                                          \"\\${if_then_else(equalTo(FEATURECLA,'Admin-0 capital'),'star','circle')}\"

                                          ); mark-size: [13-SCALERANK]; label: [NAME]; label-offset: 0 [13-SCALERANK];

                                          }

                                        "},{"location":"styling/workshop/css/done/#css.point.a3","title":"Layer Group","text":"

                                        Answer for Challenge Layer Group <css.point.q3>:

                                        1. Use a Layer Group to explore how symbology works together to form a map.

                                          • ne:NE1
                                          • ne:states_provincces_shp
                                          • ne:populated_places
                                        2. This background is relatively busy and care must be taken to ensure both symbols and labels are clearly visible.

                                        3. Challenge: Do your best to style populated_places over this busy background.

                                          Here is an example with labels for inspiration:

                                          This should be an opportunity to revisit label halo settings from Polygons.

                                          * {\n   mark-size: [5+((10-SCALERANK)/3)];\n\n   font-fill: black;\n   font-family: \"Arial\";\n   font-size: 10;\n\n   label-anchor: 0.5 1;\n   label-offset: 0 [-12+SCALERANK];\n\n   halo-radius: 2;\n   halo-color: lightgray;\n   halo-opacity:0.7;\n\n   mark-label-obstacle: true;\n   label-max-displacement: 90;\n   label-priority: [0 - LABELRANK];\n}\n:symbol {\n  fill: black;\n  stroke: white;\n  stroke-opacity:0.75;\n}\n

                                          Using a lightgray halo, 0.7 opacity and radius 2 fades out the complexity immediately surrounding the label text improving legibility.

                                        "},{"location":"styling/workshop/css/done/#css.raster.a1","title":"Contrast Enhancement","text":"

                                        Discussion for Explore Contrast Enhancement <css.raster.q1>:

                                        1. A special effect that is effective with grayscale information is automatic contrast adjustment.

                                        2. Make use of a simple contrast enhancement with usgs:dem:

                                          * {\n    raster-channels: auto;\n    raster-contrast-enhancement: normalize;\n}\n
                                        3. Can you explain what happens when zoom in to only show a land area (as indicated with the bounding box below)?

                                          What happens is insanity, normalize stretches the palette of the output image to use the full dynamic range. As long as we have ocean on the screen (with value 0) the land area was shown with roughly the same presentation.

                                          Once we zoom in to show only a land area, the lowest point on the screen (say 100) becomes the new black, radically altering what is displayed on the screen.

                                        "},{"location":"styling/workshop/css/done/#css.raster.a2","title":"Intervals","text":"

                                        Answer for Challenge Intervals <css.raster.q2>:

                                        1. The color-map type property dictates how the values are used to generate a resulting color.

                                          • ramp is used for quantitative data, providing a smooth interpolation between the provided color values.
                                          • intervals provides categorization for quantitative data, assigning each range of values a solid color.
                                          • values is used for qualitative data, each value is required to have a color-map entry or it will not be displayed.
                                        2. Challenge: Update your DEM example to use intervals for presentation. What are the advantages of using this approach for elevation data?

                                          By using intervals it becomes very clear how relatively flat most of the continent is. The ramp presentation provided lots of fascinating detail which distracted from this fact.

                                          Here is style for you to cut and paste:

                                          * {\n  raster-channels: auto;\n  raster-color-map:\n     color-map-entry(#014636,   0,0)\n     color-map-entry(#014636,   1)\n     color-map-entry(#016c59, 500)\n     color-map-entry(#02818a,1000)\n     color-map-entry(#3690c0,1500)\n     color-map-entry(#67a9cf,2000)\n     color-map-entry(#a6bddb,2500)\n     color-map-entry(#d0d1e6,3000)\n     color-map-entry(#ece2f0,3500)\n     color-map-entry(#fff7fb,4000);\n  raster-color-map-type: intervals;\n}\n
                                        "},{"location":"styling/workshop/css/done/#css.raster.a3","title":"Clear Digital Elevation Model Presentation","text":"

                                        Answer for Challenge Clear Digital Elevation Model Presentation <css.raster.q3>:

                                        1. Now that you have seen the data on screen and have a better understanding how would you modify our initial gray-scale example?

                                        2. Challenge: Use what you have learned to present the usgs:dem clearly.

                                          The original was a dark mess. Consider making use of mid-tones (or adopting a sequential palette from color brewer) in order to fix this. In the following example the ocean has been left dark, allowing the mountains stand out more.

                                          * {\n  raster-channels: auto;\n  raster-color-map: color-map-entry(#000000, 0)\n                    color-map-entry(#444444, 1)\n                    color-map-entry(#FFFFFF, 3000);\n}\n
                                        "},{"location":"styling/workshop/css/done/#css.raster.a4","title":"Raster Opacity","text":"

                                        Discussion for Challenge Clear Digital Elevation Model Presentation <css.raster.q3>:

                                        1. There is a quick way to make raster data transparent, raster opacity property works in the same fashion as with vector data. The raster as a whole will be drawn partially transparent allow content from other layers to provide context.

                                        2. Challenge: Can you think of an example where this would be useful?

                                          This is difficult as raster data is usually provided for use as a basemap, with layers being drawn over top.

                                          The most obvious example here is the display of weather systems, or model output such as fire danger. By drawing the raster with some transparency, the landmass can be shown for context.

                                        "},{"location":"styling/workshop/css/linestring/","title":"Lines","text":"

                                        We will start our tour of CSS styling by looking at the representation of lines.

                                        LineString Geometry

                                        Review of line symbology:

                                        • Lines are used to represent physical details that are too small to be represented at the current scale. Line work can also be used to model non-physical ideas such as network connectivity, or the boundary between land-use classifications. The visual width of lines do not change depending on scale.
                                        • Lines are recording as LineStrings or Curves depending on the geometry model used.
                                        • SLD uses a LineSymbolizer record how the shape of a line is drawn. The primary characteristic documented is the Stroke used to draw each segment between vertices.
                                        • Labeling of line work is anchored to the midpoint of the line. GeoServer provides an option to allow label rotation aligned with line segments.

                                        For our exercises we are going to be using simple CSS documents, often consisting of a single rule, in order to focus on the properties used for line symbology.

                                        Each exercise makes use of the ne:roads layer.

                                        Reference:

                                        • Line Symbology (User Manual | CSS Property Listing)
                                        • Lines (User Manual | CSS Cookbook)
                                        • LineString (User Manual | SLD Reference )
                                        "},{"location":"styling/workshop/css/linestring/#stroke","title":"Stroke","text":"

                                        The only mandatory property for representation of linework is stroke. This is a key property; its presence triggers the generation of an appropriate LineSymbolizer.

                                        Basic Stroke Properties

                                        The use of stroke as a key property prevents CSS from having the idea of a default line color (as the stroke information must be supplied each time).

                                        1. Navigate to the CSS Styles page.

                                        2. Click Choose a different layer and select ne:roads from the list.

                                        3. Click Create a new style and choose the following:

                                          Workspace for new layer: No workspace

                                          New style name: line_example

                                        4. Replace the generated CSS definition with the following stroke example:

                                          /* @title Line\n * @abstract Example line symbolization\n */\n * {\n   stroke: blue;\n }\n
                                        5. Click Submit and then the Map tab for an initial preview.

                                          You can use this tab to follow along as the style is edited, it will refresh each time Submit is pressed.

                                        6. You can look at the SLD tab at any time to see the generated SLD. Currently it is showing a straight forward LineSymbolizer generated from the CSS stroke property:

                                          <sld:UserStyle>\n   <sld:Name>Default Styler</sld:Name>\n   <sld:FeatureTypeStyle>\n      <sld:Name>name</sld:Name>\n      <sld:Rule>\n         <sld:Title>Line</sld:Title>\n         <sld:Abstract>Example line symboloization</sld:Abstract>\n         <sld:LineSymbolizer>\n            <sld:Stroke>\n               <sld:CssParameter name=\"stroke\">#0000ff</sld:CssParameter>\n            </sld:Stroke> \n         </sld:LineSymbolizer>\n      </sld:Rule>\n   </sld:FeatureTypeStyle>\n</sld:UserStyle>\n
                                        7. Additional properties cane be used fine-tune appearance. Use stroke-width to specify the width of the line.

                                          /* @title Line\n * @abstract Example line symbolization\n */\n * {\n   stroke: blue;\n   stroke-width: 2px;\n }\n
                                        8. The stroke-dasharray is used to define breaks rendering the line as a dot dash pattern.

                                          /* @title Line\n * @abstract Example line symbolization\n */\n * {\n   stroke: blue;\n   stroke-width: 2px;\n   stroke-dasharray: 5 2;\n }\n
                                        9. Check the Map tab to preview the result.

                                        Note

                                        The GeoServer rendering engine is quite sophisticated and allows the use of units of measure (such as m or ft). While we are using pixels in this example, real world units will be converted using the current scale.

                                        "},{"location":"styling/workshop/css/linestring/#z-index","title":"Z-Index","text":"

                                        The next exercise shows how to work around a limitation when using multiple strokes to render a line.

                                        Use of Z-Index

                                        1. Providing two strokes is often used to provide a contrasting edge (called casing) to thick line work.

                                          Update line_example with the following:

                                          * {\n  stroke: black, #8080E6;\n  stroke-width: 5px, 3px;\n}\n
                                        2. If you look carefully you can see a problem with our initial attempt. The junctions of each line show that the casing outlines each line individually, making the lines appear randomly overlapped. Ideally we would like to control this process, only making use of this effect for overpasses.

                                        3. The z-index parameter allows a draw order to be supplied. This time all the thick black lines are dawn first (at z-index 0) followed by the thinner blue lines (at z-index 1).

                                          * {\n  stroke: black, #8080E6;\n  stroke-width: 5px, 3px;\n  z-index: 0, 1;\n}\n
                                        4. If you look carefully you can see the difference.

                                        5. By using z-index we have been able to simulate line casing.

                                        "},{"location":"styling/workshop/css/linestring/#label","title":"Label","text":"

                                        Our next example is significant as it introduces the how text labels are generated.

                                        Use of Label Property

                                        This is also our first example making use of a dynamic style (where the value of a property is defined by an attribute from your data).

                                        1. To enable LineString labeling we will need to use the key properties for both stroke and label.

                                          Update line_example with the following:

                                          * {\n  stroke: blue;\n  label: [name];\n}\n
                                        2. The SLD standard documents the default label position for each kind of Geometry. For LineStrings the initial label is positioned on the midway point of the line.

                                        3. We have used an expression to calculate a property value for label. The label property is generated dynamically from the name attribute. Expressions are supplied within square brackets, making use of Constraint Query Language (CQL) syntax.

                                          * {\n  stroke: blue;\n  label: [name];\n}\n
                                        4. Additional properties can be supplied to fine-tune label presentation:

                                          * {\n  stroke: blue;\n  label: [name];\n  font-fill: black;\n  label-offset: 7px;\n}\n
                                        5. The font-fill property is set to black provides the label color.

                                          * {\n  stroke: blue;\n  label: [name];\n  font-fill: black;\n  label-offset: 7px;\n}\n
                                        6. The label-offset property is used to adjust the starting position used for labeling.

                                          Normally the displacement offset is supplied using two numbers (allowing an x and y offset from the midway point used for LineString labeling).

                                          When labeling a LineString there is a special twist: by specifying a single number for label-offset we can ask the rendering engine to position our label a set distance away from the LineString.

                                          * {\n  stroke: blue;\n  label: [name];\n  font-fill: black;\n  label-offset: 7px;\n}\n
                                        7. When used in this manner the rotation of the label will be adjusted automatically to match the LineString.

                                        "},{"location":"styling/workshop/css/linestring/#how-labeling-works","title":"How Labeling Works","text":"

                                        The rendering engine collects all the generated labels during the rendering of each layer. Then, during labeling, the engine sorts through the labels performing collision avoidance (to prevent labels overlapping). Finally the rendering engine draws the labels on top of the map. Even with collision avoidance you can spot areas where labels are so closely spaced that the result is hard to read.

                                        To take greater control over the GeoServer rendering engine we can use extra parameters.

                                        1. The ability to take control of the labeling process is exactly the kind of hint a extra parameter is intended for.

                                          Update line_example with the following:

                                          * {\n  stroke: blue;\n  label: [name];\n  font-fill: black;\n  label-offset: 7px;\n  label-padding: 10;\n}\n
                                        2. The parameter label-padding provides additional space around our label for use in collision avoidance.

                                          * {\n  stroke: blue;\n  label: [name];\n  font-fill: black;\n  label-offset: 7px;\n  label-padding: 10;\n}\n
                                        3. Each label is now separated from its neighbor, improving legibility.

                                        "},{"location":"styling/workshop/css/linestring/#scale","title":"Scale","text":"

                                        This section explores the use of attribute selectors and the @scale selector together to simplify the road dataset for display.

                                        1. Replace the line_example CSS definition with:

                                          [scalerank < 4] {\n  stroke: black;\n}\n
                                        2. And use the Map tab to preview the result.

                                        3. The scalerank attribute is provided by the Natural Earth dataset to allow control of the level of detail based on scale. Our selector short-listed all content with scalerank 4 or lower, providing a nice quick preview when we are zoomed out.

                                        4. In addition to testing feature attributes, selectors can also be used to check the state of the rendering engine.

                                          Replace your CSS with the following:

                                          [@scale > 35000000] {\n   stroke: black;\n}\n[@scale < 35000000] {\n   stroke: blue;\n}\n
                                        5. As you adjust the scale in the Map preview (using the mouse scroll wheel) the color will change between black and blue. You can read the current scale in the bottom right corner, and the legend will change to reflect the current style.

                                        6. Putting these two ideas together allows control of level detail based on scale:

                                          [@scale < 9000000] [scalerank > 7] {\n  stroke: #888888;\n}\n\n[@scale < 17000000] [scalerank = 7] {\n  stroke: #777777;\n}\n\n[@scale < 35000000] [scalerank = 6] {\n  stroke: #444444;\n}\n\n[@scale > 9000000] [@scale < 70000000] [scalerank = 5] {\n  stroke: #000055;\n}\n[@scale < 9000000] [scalerank = 5] {\n  stroke: #000055;\n  stroke-width: 2\n}\n\n[@scale > 35000000] [scalerank < 4] {\n  stroke: black;\n}\n[@scale > 9000000] [@scale <= 35000000] [scalerank < 4] {\n  stroke: black;\n  stroke-width: 2\n}\n[@scale <= 9000000] [scalerank < 4] {\n  stroke: black;\n  stroke-width: 4\n}\n
                                        7. As shown above selectors can be combined in the same rule:

                                          • Selectors separated by blank-space are combined CQL Filter AND
                                          • Selectors separated by a comma are combined using CQL Filter OR

                                          Our first rule [[@scale < 9000000] [scalerank > 7]]{.title-ref} checks that the scale is less than 9M AND scalerank is greater than 7.

                                        "},{"location":"styling/workshop/css/linestring/#bonus","title":"Bonus","text":"

                                        Finished early? Here are some opportunities to explore what we have learned, and extra challenges requiring creativity and research.

                                        In a classroom setting please divide the challenges between teams (this allows us to work through all the material in the time available).

                                        Instructor Notes

                                        As usual the Explore section invites readers to reapply the material covered in a slightly different context or dataset.

                                        The use of selectors using the roads type attribute provides this opportunity.

                                        "},{"location":"styling/workshop/css/linestring/#explore-follow-line-option","title":"Explore Follow Line Option","text":"

                                        Options can be used to enable some quite useful effects, while still providing a style that can be used by other applications.

                                        1. Update line_example with the following:

                                          * {\n  stroke: #ededff;\n  stroke-width: 10;\n  label: [level] \" \" [name];\n  font-fill: black;\n  label-follow-line: true;\n}\n
                                        2. The property stroke-width has been used to make our line thicker in order to provide a backdrop for our label.

                                          * {\n  stroke: #ededff;\n  stroke-width: 10;\n  label: [level] \" \" [name];\n  font-fill: black;\n  label-follow-line: true;\n}\n
                                        3. The label property combines combine several CQL expressions together for a longer label.

                                          * {\n  stroke: #ededff;\n  stroke-width: 10;\n  label: [level] \" \" [name];\n  font-fill: black;\n  label-follow-line: true;\n}\n

                                          The combined label property:

                                          [level] \" \" [name]\n

                                          Is internally represented with the Concatenate function:

                                          [Concatenate(level,' #', name)]\n
                                        4. The property label-follow-line provides the ability of have a label exactly follow a LineString character by character.

                                          * {\n  stroke: #ededff;\n  stroke-width: 10;\n  label: [level] \" \" [name];\n  font-fill: black;\n  label-follow-line: true;\n}\n
                                        5. The result is a new appearance for our roads.

                                        "},{"location":"styling/workshop/css/linestring/#css.line.q0","title":"Challenge SLD Generation","text":"
                                        1. Generate the SLD for the following CSS.

                                          * {\n  stroke: black;\n}\n

                                          What is unusual about the SLD code for this example?

                                        2. Challenge: What is unusual about the generated SLD? Can you explain why it still works as expected?

                                          Note

                                          Answer provided <css.line.a0> at the end of the workbook.

                                        "},{"location":"styling/workshop/css/linestring/#css.line.q1","title":"Challenge Classification","text":"
                                        1. The roads type attribute provides classification information.

                                          You can Layer Preview to inspect features to determine available values for type.

                                        2. Challenge: Create a new style adjust road appearance based on type.

                                          Hint: The available values are 'Major Highway','Secondary Highway','Road' and 'Unknown'.

                                          Note

                                          Answer provided <css.line.a1> at the end of the workbook.

                                        "},{"location":"styling/workshop/css/linestring/#css.line.q2","title":"Challenge SLD Z-Index Generation","text":"
                                        1. Review the SLD generated by the z-index example.

                                          * {\n  stroke: black, #8080E6;\n  stroke-width: 5px, 3px;\n  z-index: 0, 1;\n}\n
                                        2. Challenge: There is an interesting trick in the generated SLD, can you explain how it works?

                                          Note

                                          Answer provided <css.line.a2> at the end of the workbook.

                                        "},{"location":"styling/workshop/css/linestring/#css.line.q3","title":"Challenge Label Shields","text":"
                                        1. The traditional presentation of roads in the US is the use of a shield symbol, with the road number marked on top.

                                        2. Challenge: Have a look at the documentation and reproduce this technique.

                                          Note

                                          Answer provided <css.line.a3> at the end of the workbook.

                                        "},{"location":"styling/workshop/css/point/","title":"Points","text":"

                                        The next stop of the CSS styling tour is the representation of points.

                                        Review of point symbology:

                                        • Points are used to represent a location only, and do not form a shape. The visual width of lines do not change depending on scale.
                                        • SLD uses a PointSymbolizer record how the shape of a line is drawn.
                                        • Labeling of points is anchored to the point location.

                                        As points have no inherent shape of their own, emphasis is placed on marking locations with an appropriate symbol.

                                        Reference:

                                        • Point Symbology (User Manual | CSS Property Listing)
                                        • Points (User Manual | CSS Cookbook)
                                        • Styled Marks (User Manual | CSS Styling )
                                        • Point (User Manual | SLD Reference )

                                        This exercise makes use of the ne:populated_places layer.

                                        1. Navigate to the Styles page.

                                        2. Click Add a new style and choose the following:

                                          Name: point_example

                                          Workspace: No workspace

                                          Format: CSS

                                        3. Replace the initial CSS definition with the following and click apply:

                                          * {\n  mark: symbol(circle);\n}\n
                                        4. And use the Layer Preview tab to preview the result.

                                        "},{"location":"styling/workshop/css/point/#mark","title":"Mark","text":"

                                        Points are represented with the mandatory property mark.

                                        The SLD standard provides \"well-known\" symbols for use with point symbology: circle, square, triangle, arrow, cross, star, and x.

                                        1. As a key property the presence mark triggers the generation of an appropriate PointSymbolizer.

                                          * {\n mark: symbol(square);\n}\n
                                        2. Map Preview:

                                        3. Before we continue we will use a selector to cut down the amount of data shown to a reasonable level.

                                          [ SCALERANK < 1 ] {\n  mark: symbol(square);\n}\n
                                        4. Resulting in a considerably cleaner image:

                                        5. Additional properties are available to control a mark's presentation:

                                          The mark-size property is used to control symbol size.

                                          The mark-rotation property controls orientation, accepting input in degrees.

                                          Trying these two settings together:

                                          [ SCALERANK < 1 ] {\n  mark: symbol(square);\n  mark-size: 8;\n  mark-rotation: 45;\n}\n
                                        6. Results in each location being marked with a diamond:

                                        7. Now that we have assigned our point location a symbol we can make use of a pseudo-selector to style the resulting shape.

                                          :symbol - provides styling for all the symbols in the CSS document.

                                          :mark - provides styling for all the mark symbols in the CSS document.

                                          This form of pseudo-selector is used for all marks:

                                          [ SCALERANK < 1 ] {\n  mark: symbol(square);\n  mark-size: 8;\n  mark-rotation: 45;\n}\n:mark{\n   fill: white;\n   stroke: black;\n}\n
                                        8. Updating the mark to a white square with a black outline.

                                        9. The second approach is used to individual configure symbols in the same document.

                                          :nth-symbol(1) - if needed we could specify which symbol in the document we wish to modify.

                                          :nth-mark(1) - provides styling for the first mark symbol in the CSS document.

                                          Using this approach marks can be composed of multiple symbols, each with its own settings:

                                          [ SCALERANK < 1 ] {\n  mark: symbol(square),symbol(cross);\n  mark-size: 16,14;\n  mark-rotation: 0,45;\n}\n:nth-mark(1){\n   fill: red;\n   stroke: black;\n}\n:nth-mark(2){\n   fill: black;\n   stroke: white;\n}\n
                                        10. Producing an interesting compound symbol effect:

                                        "},{"location":"styling/workshop/css/point/#graphic","title":"Graphic","text":"

                                        Symbols can also be supplied by an external graphic,

                                        This technique was shown with the initial ` CSS example.

                                        1. To use an external graphic two pieces of information are required.

                                          mark property is defined with a url reference to image.

                                          mark-mime property is used to tell the rendering engine what file format to expect

                                          This technique is used to reference files placed in the styles directory.

                                          [ SCALERANK < 1 ] {\n  mark: url(port.svg);\n  mark-mime: \"image/svg\";\n}\n
                                        2. Drawing the provided shape in each location:

                                        3. The mark property url reference can also be used to reference external images. We can make use of the GeoServer logo.

                                          [ SCALERANK < 1 ] {\n     mark: url(\"http://localhost:8080/geoserver/web/wicket/resource/org.geoserver.web.GeoServerBasePage/img/logo.png\");\n     mark-mime: \"image/png\";\n     mark-size: 16;\n}\n
                                        4. As shown in the map preview.

                                        "},{"location":"styling/workshop/css/point/#label","title":"Label","text":"

                                        Labeling is now familiar from our experience with LineString and Polygons.

                                        The key properties mark and label are required to label Point locations.

                                        1. Replace point_example with the following:

                                          [ SCALERANK < 1 ] {\n  mark: symbol(circle);\n  label: [NAME];\n}\n
                                        2. Confirm the result in Map preview.

                                        3. Each label is drawn starting from the provided point - which is unfortunate as it assures each label will overlap with the symbol used. To fix this limitation we will make use of the SLD controls for label placement:

                                          label-anchor provides two values expressing how a label is aligned with respect to the starting label position.

                                          label-offset is be used to provide an initial displacement using and x and y offset. For points this offset is recommended to adjust the label position away for the area used by the symbol.

                                          Note

                                          The property label-anchor defines an anchor position relative to the bounding box formed by the resulting label. This anchor position is snapped to the label position generated by the point location and displacement offset.

                                        4. Using these two facilities together we can center our labels below the symbol, taking care that the displacement used provides an offset just outside the area required for the symbol size.

                                          [ SCALERANK < 1 ] {\n  mark: symbol(circle);\n  mark-size: 10;\n\n  label: [NAME];\n  label-offset: 0 -12;\n  label-anchor: 0.5 1.0;\n\n  font-fill: black;\n}\n
                                        5. Each label is now placed under the mark.

                                        6. One remaining issue is the overlap between labels and symbols.

                                          GeoServer provides a vendor specific parameter to allow symbols to take part in label conflict resolution, preventing labels from overlapping any symbols. This severely limits the area available for labeling and is best used in conjunction with a large maximum displacement vendor option.

                                          mark-label-obstacle vendor parameter asks the rendering engine to avoid drawing labels over top of the indicated symbol.

                                          label-max-displacement vendor parameter provides the rendering engine a maximum distance it is allowed to move labels during conflict resolution.

                                          label-padding vendor parameter tells the rendering engine to provide a minimum distance between the labels on the map, ensuring they do not overlap.

                                          Update our example to use these settings:

                                          [ SCALERANK < 1 ] {\n  mark: symbol(circle);\n  mark-size: 10;\n\n  label: [NAME];\n  label-offset: 0 -12;\n  label-anchor: 0.5 1.0;\n\n  font-fill: black;\n\n  mark-label-obstacle: true;\n  label-max-displacement: 100;\n  label-padding: 2;\n}\n
                                        7. Resulting in a considerably cleaner image:

                                        "},{"location":"styling/workshop/css/point/#dynamic-styling","title":"Dynamic Styling","text":"
                                        1. We will quickly use scalerank to select content based on @scale selectors.

                                          [@scale < 4000000] {\n   mark: symbol(circle);\n}\n[@scale > 4000000] [@scale < 8000000] [SCALERANK < 7] {\n   mark: symbol(circle);\n}\n\n[@scale > 8000000] [@scale < 17000000] [SCALERANK < 5] {\n   mark: symbol(circle);\n}\n\n[@scale > 17000000] [@scale < 35000000] [SCALERANK < 4] {\n   mark: symbol(circle);\n}\n\n[@scale > 35000000] [@scale < 70000000][SCALERANK < 3] {\n   mark: symbol(circle);\n}\n\n[@scale > 70000000] [@scale < 140000000][SCALERANK < 2] {\n   mark: symbol(circle);\n}\n\n[@scale > 140000000] [SCALERANK < 1] {\n  mark: symbol(circle);\n}\n\n* {\n  mark-size: 6;\n}\n
                                        2. Click Submit to update the Map after each step.

                                        3. To add labeling we must use both the key properties mark and label in each scale selector, using rule cascading to define the mark-size and font information once.

                                          [@scale < 4000000] {\n   mark: symbol(circle);\n   label: [NAME];\n}\n[@scale > 4000000] [@scale < 8000000] [SCALERANK < 7] {\n   mark: symbol(circle);\n   label: [NAME];\n}\n\n[@scale > 8000000] [@scale < 17000000] [SCALERANK < 5] {\n   mark: symbol(circle);\n   label: [NAME];\n}\n\n[@scale > 17000000] [@scale < 35000000] [SCALERANK < 4] {\n   mark: symbol(circle);\n   label: [NAME];\n}\n\n[@scale > 35000000] [@scale < 70000000][SCALERANK < 3] {\n   mark: symbol(circle);\n   label: [NAME];\n}\n\n[@scale > 70000000] [@scale < 140000000][SCALERANK < 2] {\n   mark: symbol(circle);\n   label: [NAME];\n}\n\n[@scale > 140000000] [SCALERANK < 1] {\n   mark: symbol(circle);\n   label: [NAME];\n}\n\n* {\n  mark-size: 6;\n\n  font-fill: black;\n  font-family: \"Arial\";\n  font-size: 10;\n}\n

                                        4. We will use label-offset and label-anchor to position the label above each symbol.

                                          Add the following two lines to the * selector:

                                          * {\n  mark-size: 6;\n\n  font-fill: black;\n  font-family: \"Arial\";\n  font-size: 10;\n\n  label-anchor: 0.5 0;\n  label-offset: 0 6;\n}\n

                                        5. A little bit of work with vendor specific parameters will prevent our labels from colliding with each symbol, while giving the rendering engine some flexibility in how far it is allowed to relocate a label.

                                          Add the following vendor options to the * selector:

                                          * {\n  mark-size: 6;\n\n  font-fill: black;\n  font-family: \"Arial\";\n  font-size: 10;\n\n  label-anchor: 0.5 0;\n  label-offset: 0 6;\n\n  mark-label-obstacle: true;\n  label-max-displacement: 90;\n  label-padding: 2;\n}\n

                                        6. Now that we have clearly labeled our cities, zoom into an area you are familiar with and we can look at changing symbology on a case-by-case basis.

                                          We have used expressions previous to generate an appropriate label. Expressions can also be used for many other property settings.

                                          The ne:populated_places layer provides several attributes specifically to make styling easier:

                                          • SCALERANK: we have already used this attribute to control the level of detail displayed
                                          • LABELRANK: hint used for conflict resolution, allowing important cities such as capitals to be labeled even when they are close to a larger neighbor.
                                          • FEATURECLA: used to indicate different types of cities. We will check for Admin-0 capital cities.

                                          The first thing we will do is calculate the mark-size using a quick expression:

                                          [10-(SCALERANK/2)]\n

                                          This expression should result in sizes between 5 and 9 and will need to be applied to both mark-size and label-offset.

                                          Rather than the \"first come first served\" default to resolve labeling conflicts we can manually provide GeoServer with a label priority. The expression provided is calculated for each label, in the event of a conflict the label with the highest priority takes precedence.

                                          The LABELRANK attribute goes from 1 through 10 and needs to be flipped around before use as a GeoServer label priority:

                                          [10 - LABELRANK]\n

                                          This expression will result in values between 0 and 10 and will be used for the label-priority.

                                          * {\n  mark-size: [10-(SCALERANK/2)];\n\n  font-fill: black;\n  font-family: \"Arial\";\n  font-size: 10;\n\n  label-anchor: 0.5 0;\n  label-offset: 0 [10-(SCALERANK/2)];\n\n  mark-label-obstacle: true;\n  label-max-displacement: 90;\n  label-padding: 2;\n  label-priority: [10 - LABELRANK];\n}\n

                                        7. Next we can use FEATURECLA to check for capital cities.

                                          Adding a selector for capital cities at the top of the file:

                                          /* capitals */\n[@scale < 70000000]\n[FEATURECLA = 'Admin-0 capital']  {\n   mark: symbol(star);\n   label: [NAME];\n}\n[@scale > 70000000] [SCALERANK < 2]\n[FEATURECLA = 'Admin-0 capital']  {\n   mark: symbol(star);\n   label: [NAME];\n}\n

                                          And updating the populated places selectors to ignore capital cities:

                                          /* populated places */\n[@scale < 4000000]\n[FEATURECLA <> 'Admin-0 capital'] {\n   mark: symbol(circle);\n   label: [NAME];\n}\n[@scale > 4000000] [@scale < 8000000] [SCALERANK < 7]\n[FEATURECLA <> 'Admin-0 capital'] {\n   mark: symbol(circle);\n   label: [NAME];\n}\n\n[@scale > 8000000] [@scale < 17000000] [SCALERANK < 5]\n[FEATURECLA <> 'Admin-0 capital'] {\n   mark: symbol(circle);\n   label: [NAME];\n}\n\n[@scale > 17000000] [@scale < 35000000] [SCALERANK < 4]\n[FEATURECLA <> 'Admin-0 capital'] {\n   mark: symbol(circle);\n   label: [NAME];\n}\n\n[@scale > 35000000] [@scale < 70000000][SCALERANK < 3]\n[FEATURECLA <> 'Admin-0 capital'] {\n   mark: symbol(circle);\n   label: [NAME];\n}\n\n[@scale > 70000000] [@scale < 140000000][SCALERANK < 2]\n[FEATURECLA <> 'Admin-0 capital'] {\n   mark: symbol(circle);\n   label: [NAME];\n}\n\n[@scale > 140000000] [SCALERANK < 1]\n[FEATURECLA <> 'Admin-0 capital'] {\n   mark: symbol(circle);\n   label: [NAME];\n}\n

                                        8. Finally we can fill in the capital city symbols using a combination of a selector to detect capital cities, and pseudo selector to provide mark styling.

                                          [FEATURECLA = 'Admin-0 capital'] :mark {\n  fill: black;\n}\n\n:symbol {\n  fill: gray;\n  stroke: black;\n}\n

                                        9. If you would like to check your work the final file is here: point_example.css

                                        "},{"location":"styling/workshop/css/point/#bonus","title":"Bonus","text":"

                                        Instructor Notes

                                        The exercise section does not review the examples above, instead it explores the use of:

                                        • scale and attribute selectors
                                        • recode to map from attribute to symbol
                                        • interpolate to change size by population
                                        "},{"location":"styling/workshop/css/point/#css.point.q1","title":"Challenge Geometry Location","text":"

                                        Instructor Notes

                                        As usual Explore invites readers to reapply the material covered in a slightly different context or dataset.

                                        The use of selectors using the roads type attribute provides this opportunity.

                                        1. The mark property can be used to render any geometry content.

                                        2. Challenge: Try this yourself by rendering a polygon layer using a mark property.

                                          Note

                                          Answer discussed <ysld.point.a1> at the end of the workbook.

                                        "},{"location":"styling/workshop/css/point/#css.point.q2","title":"Explore Dynamic Symbolization","text":"
                                        1. We went to a lot of work to set up selectors to choose between symbol(star) and symbol(circle) for capital cities.

                                          This approach is straightforward when applied in isolation:

                                          [FEATURECLA = 'Admin-0 capital'] {\n   mark: symbol(star);\n}\n[FEATURECLA <> 'Admin-0 capital'] {\n   mark: symbol(circle);\n}\n

                                          When combined with checking another attribute, or checking @scale as in our example, this approach can quickly lead to many rules which can be difficult to keep straight.

                                        2. Taking a closer look both symbol() and url() can actually be expressed using a string:

                                          [FEATURECLA = 'Admin-0 capital'] {\n   mark: symbol(\"star\");\n}\n

                                          Which is represented in SLD as:

                                          <sld:PointSymbolizer>\n  <sld:Graphic>\n     <sld:Mark>\n        <sld:WellKnownName>star</sld:WellKnownName>\n        <sld:Fill/>\n        <sld:Stroke/>\n     </sld:Mark>\n  </sld:Graphic>\n</sld:PointSymbolizer>\n
                                        3. GeoServer recognizes this limitation of SLD Mark and ExternalGraphic and provides an opportunity for dynamic symbolization.

                                          This is accomplished by embedding a small CQL expression in the string passed to symbol or url. This sub-expression is isolated with \\${ } as shown:

                                          * {\n   mark: symbol(\n     \"${if_then_else(equalTo(FEATURECLA,'Admin-0 capital'),'star','circle')}\"\n   );\n}\n

                                          Which is represented in SLD as:

                                          <sld:PointSymbolizer>\n  <sld:Graphic>\n     <sld:Mark>\n        <sld:WellKnownName>${if_then_else(equalTo(FEATURECLA,'Admin-0 capital'),'star','circle')}</sld:WellKnownName>\n        <sld:Fill/>\n        <sld:Stroke/>\n     </sld:Mark>\n  </sld:Graphic>\n</sld:PointSymbolizer>\n
                                        4. Challenge: Use this approach to rewrite the Dynamic Styling example.

                                          Note

                                          Answer provided <ysld.point.a2> at the end of the workbook.

                                        1. Challenge: Use the Interpolate function to smoothly change mark-size based on city population.
                                        "},{"location":"styling/workshop/css/point/#css.point.q3","title":"Challenge Layer Group","text":"
                                        1. Use a Layer Group to explore how symbology works together to form a map.

                                          • ne:NE1
                                          • ne:states_provincces_shp
                                          • ne: populated_places
                                        2. To help start things out here is a style for ne:states_provinces_shp:

                                          * {     \n   fill: white,[\n    recode(mapcolor9,\n      1,'#8dd3c7', 2,'#ffffb3', 3,'#bebada',\n      4,'#fb8072', 5,'#80b1d3', 6,'#fdb462',\n      7,'#b3de69', 8,'#fccde5', 9,'#d9d9d9')\n   ];\n   fill-opacity: 05%,50%;\n\n   stroke: black;\n   stroke-width: 0.25;\n   stroke-opacity: 50%;\n}\n
                                        3. This background is relatively busy and care must be taken to ensure both symbols and labels are clearly visible.

                                        4. Challenge: Do your best to style populated_places over this busy background.

                                          Here is an example with labels for inspiration:

                                          Note

                                          Answer provided <ysld.point.a3> at the end of the workbook.

                                        "},{"location":"styling/workshop/css/point/#explore-true-type-fonts","title":"Explore True Type Fonts","text":"
                                        1. In addition to image formats GeoServer can make use other kinds of graphics, such as True Type fonts:

                                          * {\n   mark: symbol(\"ttf://Webdings#0x0064\");\n}\n:mark {\n   stroke: blue;\n}\n
                                        2. Additional fonts dropped in the styles directory are available for use.

                                        "},{"location":"styling/workshop/css/point/#explore-custom-graphics","title":"Explore Custom Graphics","text":"
                                        1. The GeoServer rendering engine allows Java developers to hook in additional symbol support.

                                          This facility is used by GeoServer to offer the shapes used for pattern fills. Community extensions allow the use of simple custom shapes and even charts.

                                        2. Support has been added for custom graphics using the WKT Geometry representation.

                                          * {\n   mark: symbol(\"wkt://MULTILINESTRING((-0.25 -0.25, -0.125 -0.25), (0.125 -0.25, 0.25 -0.25), (-0.25 0.25, -0.125 0.25), (0.125 0.25, 0.25 0.25))\");\n}\n:mark {\n   stroke: blue;\n} \n
                                        "},{"location":"styling/workshop/css/polygon/","title":"Polygons","text":"

                                        Next we look at how CSS styling can be used to represent polygons.

                                        Polygon Geometry

                                        Review of polygon symbology:

                                        • Polygons offer a direct representation of physical extent or the output of analysis.

                                        • The visual appearance of polygons reflects the current scale.

                                        • Polygons are recorded as a LinearRing describing the polygon boundary. Further LinearRings can be used to describe any holes in the polygon if present.

                                          The Simple Feature for SQL Geometry model (used by GeoJSON) represents these areas as Polygons, the ISO 19107 geometry model (used by GML3) represents these areas as Surfaces.

                                        • SLD uses a PolygonSymbolizer to describe how the shape of a polygon is drawn. The primary characteristic documented is the Fill used to shade the polygon interior. The use of a Stroke to describe the polygon boundary is optional.

                                        • Labeling of a polygon is anchored to the centroid of the polygon. GeoServer provides a vendor option to allow labels to line wrap to remain within the polygon boundaries.

                                        For our Polygon exercises we will try and limit our CSS documents to a single rule, in order to showcase the properties used for rendering.

                                        Reference:

                                        • Polygon Symbology (User Manual | CSS Property Listing)
                                        • Polygons (User Manual | CSS Cookbook)
                                        • Polygons (User Manual | SLD Reference )

                                        This exercise makes use of the ne:states_provinces_shp layer.

                                        1. Navigate to Styles.

                                        2. Create a new style polygon_example.

                                          Name: polygon_example

                                          Workspace: No workspace

                                          Format: CSS

                                        3. Enter the following style and click ****Apply`` to save:

                                          * { fill: lightgrey; }\n
                                        4. Click on the tab Layer Preview to preview.

                                        5. Set ne:states_provinces_shp as the preview layer.

                                        "},{"location":"styling/workshop/css/polygon/#stroke-and-fill","title":"Stroke and Fill","text":"

                                        The key property for polygon data is fill.

                                        The fill property is used to provide the color, or pattern, used to draw the interior of a polygon.

                                        1. Replace the contents of polygon_example with the following fill example:

                                          * {\n   fill: gray;\n}\n
                                        2. The Map tab can be used preview the change:

                                        3. To draw the boundary of the polygon the stroke property is used:

                                          The stroke property is used to provide the color, or pattern, for the polygon boundary. It is effected by the same parameters (and vendor specific parameters) as used for LineStrings.

                                          * {\n   fill: gray;\n   stroke: black;\n   stroke-width: 2;\n}\n

                                          Note

                                          Technically the boundary of a polygon is a specific case of a LineString where the first and last vertex are the same, forming a closed LinearRing.

                                        4. The effect of adding stroke is shown in the map preview:

                                        5. An interesting technique when styling polygons in conjunction with background information is to control the fill opacity.

                                          The fill-opacity property is used to adjust transparency (provided as range from 0.0 to 1.0). Use of fill-opacity to render polygons works well in conjunction with a raster base map. This approach allows details of the base map to shown through.

                                          The stroke-opacity property is used in a similar fashion, as a range from 0.0 to 1.0.

                                          * {\n   fill: white;\n   fill-opacity: 50%;\n   stroke: lightgrey;\n   stroke-width: 0.25;\n   stroke-opacity: 50%;\n}\n
                                        6. As shown in the map preview:

                                        7. This effect can be better appreciated using a layer group.

                                          Where the transparent polygons is used lighten the landscape provided by the base map.

                                        Instructor Notes

                                        In this example we want to ensure readers know the key property for polygon data.

                                        It is also our first example of using opacity.

                                        "},{"location":"styling/workshop/css/polygon/#pattern","title":"Pattern","text":"

                                        In addition to color, the fill property can also be used to provide a pattern.

                                        The fill pattern is defined by repeating one of the built-in symbols, or making use of an external image.

                                        1. We have two options for configuring a fill with a repeating graphic:

                                          Using url to reference to an external graphic. Used in conjunction with fill-mime property.

                                          Use of symbol to access a predefined shape. SLD provides several well-known shapes (circle, square, triangle, arrow, cross, star, and x). GeoServer provides additional shapes specifically for use as fill patterns.

                                          Update polygon_example with the following built-in symbol as a repeating fill pattern:

                                          * {\n   fill: symbol(square);\n}\n
                                        2. The map preview (and legend) will show the result:

                                        3. Add a black stroke:

                                          * {\n   fill: symbol(square);\n   stroke: black;\n}\n
                                        4. To outline the individual shapes:

                                        5. Additional fill properties allow control over the orientation and size of the symbol.

                                          The fill-size property is used to adjust the size of the symbol prior to use.

                                          The fill-rotation property is used to adjust the orientation of the symbol.

                                          Adjust the size and rotation as shown:

                                          * {\n   fill: symbol(square);\n   fill-size: 22px;\n   fill-rotation: 45;\n   stroke: black;\n}\n
                                        6. The size of each symbol is increased, and each symbol rotated by 45 degrees.

                                          Note

                                          Does the above look correct? There is an open request GEOT-4642 to rotate the entire pattern, rather than each individual symbol.

                                          Instructor Notes

                                          Prior to GeoServer 2.5 a toRadians call was required as described in GEOT-4641.

                                          * {\n   fill: symbol(square);\n   fill-size: 22px;\n   fill-rotation: [toRadians(45)];\n}\n
                                        7. The size and rotation properties just affect the size and placement of the symbol, but do not alter the symbol's design. In order to control the color we need to make use of a pseudo-selector. We have two options for referencing to our symbol above:

                                          :symbol provides styling for all the symbols in the CSS document.

                                          :fill provides styling for all the fill symbols in the CSS document.

                                        8. Replace the contents of polygon_example with the following:

                                          * {\n   fill: symbol(square);\n}\n:fill {\n   fill: green;\n   stroke: darkgreen;\n}\n
                                        9. This change adjusts the appearance of our grid of squares.

                                        10. If you have more than one symbol:

                                          :nth-symbol(1) is used to specify which symbol in the document we wish to modify.

                                          :nth-fill(1) provides styling for the indicated fill symbol

                                          To rewrite our example to use this approach:

                                          * {\n   fill: symbol(square);\n}\n:nth-fill(1) {\n   fill: green;\n   stroke: darkgreen;\n}\n
                                        11. Since we only have one fill in our CSS document the map preview looks identical.

                                        12. The well-known symbols are more suited for marking individual points. Now that we understand how a pattern can be controlled it is time to look at the patterns GeoServer provides.

                                          shape://horizline horizontal hatching shape://vertline vertical hatching shape://backslash right hatching pattern shape://slash left hatching pattern shape://plus vertical and horizontal hatching pattern shape://times cross hatch pattern

                                          Update the example to use shape://slash for a pattern of left hatching.

                                          * {\n   fill: symbol('shape://slash');\n   stroke: black;\n}\n:fill {\n  stroke: gray;\n}\n
                                        13. This approach is well suited to printed output or low color devices.

                                        14. To control the size of the symbol produced use the fill-size property.

                                          * {\n   fill: symbol('shape://slash');\n   fill-size: 8;\n   stroke: black;\n}\n:fill {\n   stroke: green;\n}\n
                                        15. This results in a tighter pattern shown:

                                        16. Another approach (producing the same result is to use the size property on the appropriate pseudo-selector.

                                          * {\n   fill: symbol('shape://slash');\n   stroke: black;\n}\n:fill {\n   stroke: green;\n   size: 8;\n}\n
                                        17. This produces the same visual result:

                                        18. Multiple fills can be combined by supplying more than one fill as part of the same rule.

                                          Note the use of a comma to separate fill-size values (including the first fill-size value which is empty). This was the same approach used when combining strokes.

                                          * {\n   fill: #DDDDFF, symbol('shape://slash');\n   fill-size: '','8';\n   stroke: black;\n}\n:fill {\n   stroke: black;\n   stroke-width: 0.5;\n}\n
                                        19. The resulting image has a solid fill, with a pattern drawn overtop.

                                        "},{"location":"styling/workshop/css/polygon/#label","title":"Label","text":"

                                        Labeling polygons follows the same approach used for LineStrings.

                                        The key properties fill and label are used to enable Polygon label generation.

                                        1. By default labels are drawn starting at the centroid of each polygon.

                                        2. Try out label and fill together by replacing our polygon_example with the following:

                                          * {\n  stroke: blue;\n  fill: #7EB5D3;\n  label: [name];\n  font-fill: black;\n}\n
                                        3. Each label is drawn from the lower-left corner as shown in the Map preview.

                                        4. We can adjust how the label is drawn at the polygon centroid.

                                          The property label-anchor provides two numbers expressing how a label is aligned with respect to the centroid. The first value controls the horizontal alignment, while the second value controls the vertical alignment. Alignment is expressed between 0.0 and 1.0 as shown in the following table.

                                                   Left      Center    Right\n

                                          Top 0.0 1.0 0.5 1.0 1.0 1.0

                                          Middle 0.0 0.5 0.5 0.5 1.0 0.5

                                          Bottom 0.0 0.0 0.5 0.0 1.0 0.0

                                          Adjusting the label-anchor is the recommended approach to positioning your labels.

                                        5. Using the label-anchor property we can center our labels with respect to geometry centroid.

                                          To align the center of our label we select 50% horizontally and 50% vertically, by filling in 0.5 and 0.5 below:

                                          * {  stroke: blue;\n     fill: #7EB5D3;\n     label: [name];\n     font-fill: black;\n     label-anchor: 0.5 0.5;\n}\n
                                        6. The labeling position remains at the polygon centroid. We adjust alignment by controlling which part of the label we are \"snapping\" into position.

                                        7. The property label-offset can be used to provide an initial displacement using and x and y offset.

                                        8. This offset is used to adjust the label position relative to the geometry centroid resulting in the starting label position.

                                          * {  stroke: blue;\n     fill: #7EB5D3;\n     label: [name];\n     font-fill: black;\n     label-offset: 0 7;\n}\n
                                        9. Confirm this result in the map preview.

                                        10. These two settings can be used together.

                                          The rendering engine starts by determining the label position generated from the geometry centroid and the label-offset displacement. The bounding box of the label is used with the label-anchor setting align the label to this location.

                                          Step 1: starting label position = centroid + displacement

                                          Step 2: snap the label anchor to the starting label position

                                        11. To move our labels down (allowing readers to focus on each shape) we can use displacement combined with followed by horizontal alignment.

                                          * {  stroke: blue;\n     fill: #7EB5D3;\n     label: [name];\n     font-fill: black;\n     label-anchor: 0.5 1;\n     label-offset: 0 -7;\n }\n
                                        12. As shown in the map preview.

                                        "},{"location":"styling/workshop/css/polygon/#legibility","title":"Legibility","text":"

                                        When working with labels a map can become busy very quickly, and difficult to read.

                                        1. GeoServer provides extensive vendor parameters directly controlling the labelling process.

                                          Many of these parameters focus on controlling conflict resolution (when labels would otherwise overlap).

                                        2. Two common properties for controlling labeling are:

                                          label-max-displacement indicates the maximum distance GeoServer should displace a label during conflict resolution.

                                          label-auto-wrap allows any labels extending past the provided width will be wrapped into multiple lines.

                                        3. Using these together we can make a small improvement in our example:

                                          * {  stroke: blue;\n     fill: #7EB5D3;\n     label: [name];\n     font-fill: black;\n     label-anchor: 0.5 0.5;\n\n     label-max-displacement: 40;\n     label-auto-wrap: 70;\n   }\n
                                        4. As shown in the following preview.

                                        5. Even with this improved spacing between labels, it is difficult to read the result against the complicated line work.

                                          Use of a halo to outline labels allows the text to stand out from an otherwise busy background. In this case we will make use of the fill color, to provide some space around our labels. We will also change the font to Arial.

                                          * {  stroke: blue;\n     fill: #7EB5D3;\n     label: [name];\n     label-anchor: 0.5 0.5;\n     font-fill: black;\n     font-family: \"Arial\";\n     font-size: 14;\n     halo-radius: 2;\n     halo-color: #7EB5D3;\n     halo-opacity:0.8;\n\n     label-max-displacement: 40;\n     label-auto-wrap: 70;\n   }\n
                                        6. By making use of halo-opacity we still allow stroke information to show through, but prevent the stroke information from making the text hard to read.

                                        7. And advanced technique for manually taking control of conflict resolution is the use of the label-priority.

                                          This property takes an expression which is used in the event of a conflict. The label with the highest priority \"wins.\"

                                        8. The Natural Earth dataset we are using includes a labelrank intended to control what labels are displayed based on zoom level.

                                          The values for labelrank go from 0 (for zoomed out) to 20 (for zoomed in). To use this value for label-priority we need to swap the values around so a scalerank of 1 is given the highest priority.

                                          * {  stroke: blue;\n     fill: #7EB5D3;\n     label: [name];\n     label-anchor: 0.5 0.5;\n     font-fill: black;\n     font-family: \"Arial\";\n     font-size: 14;\n     halo-radius: 2;\n     halo-color: #7EB5D3;\n     halo-opacity:0.8;\n\n     label-max-displacement: 40;\n     label-auto-wrap: 70;\n     label-priority: [20-labelrank];\n   }\n
                                        9. In the following map East Flanders will take priority over Zeeland when the two labels overlap.

                                        "},{"location":"styling/workshop/css/polygon/#theme","title":"Theme","text":"

                                        A thematic map (rather than focusing on representing the shape of the world) uses elements of style to illustrate differences in the data under study. This section is a little more advanced and we will take the time to look at the generated SLD file.

                                        Instructor Notes

                                        This instruction section follows our pattern with LineString. Building on the examples and exploring how selectors can be used.

                                        • For LineString we explored the use of @scale, in this section we are going to look at theming by attribute.
                                        • We also unpack how cascading occurs, and what the result looks like in the generated XML.
                                        • care is being taken to introduce the symbology encoding functions as an option for theming ( placing equal importance on their use).

                                        Checklist:

                                        • filter vs function for theming
                                        • Cascading
                                        1. We can use a site like ColorBrewer to explore the use of color theming for polygon symbology. In this approach the fill color of the polygon is determined by the value of the attribute under study.

                                          This presentation of a dataset is known as \"theming\" by an attribute.

                                        2. For our ne:states_provinces_shp dataset, a mapcolor9 attribute has been provided for this purpose. Theming by mapcolor9 results in a map where neighbouring countries are visually distinct.

                                          +----------------------------+---------+---------+ | > Qualitative 9-class Set3 | | | +----------------------------+---------+---------+ | #8dd3c7 | #fb8072 | #b3de69 | +----------------------------+---------+---------+ | #ffffb3 | #80b1d3 | #fccde5 | +----------------------------+---------+---------+ | #bebada | #fdb462 | #d9d9d9 | +----------------------------+---------+---------+

                                          If you are unfamiliar with theming you may wish to visit http://colorbrewer2.org to learn more. The i icons provide an adequate background on theming approaches for qualitative, sequential and diverging datasets.

                                        3. The first approach we will take is to directly select content based on colormap, providing a color based on the 9-class Set3 palette above:

                                          [mapcolor9=1] {\n   fill: #8dd3c7;\n}\n[mapcolor9=2] {\n   fill: #ffffb3;\n}\n[mapcolor9=3] {\n   fill: #bebada;\n}\n[mapcolor9=4] {\n   fill: #fb8072;\n}\n[mapcolor9=5] {\n   fill: #80b1d3;\n}\n[mapcolor9=6] {\n   fill: #fdb462;\n}\n[mapcolor9=7] {\n   fill: #b3de69;\n}\n[mapcolor9=8] {\n   fill: #fccde5;\n}\n[mapcolor9=9] {\n   fill: #d9d9d9;\n}\n* {\n  stroke: gray;\n  stroke-width: 0.5;\n}\n
                                        4. The Map tab can be used to preview this result.

                                        5. This CSS makes use of cascading to avoid repeating the stroke and stroke-width information multiple times.

                                          As an example the mapcolor9=2 rule, combined with the * rule results in the following collection of properties:

                                          [mapcolor9=2] {\n  fill: #ffffb3;\n  stroke: gray;\n  stroke-width: 0.5;\n}\n
                                        6. Reviewing the generated SLD shows us this representation:

                                          <sld:Rule>\n   <ogc:Filter>\n      <ogc:PropertyIsEqualTo>\n         <ogc:PropertyName>mapcolor9</ogc:PropertyName>\n         <ogc:Literal>2</ogc:Literal>\n      </ogc:PropertyIsEqualTo>\n   </ogc:Filter>\n   <sld:PolygonSymbolizer>\n      <sld:Fill>\n         <sld:CssParameter name=\"fill\">#ffffb3</sld:CssParameter>\n      </sld:Fill>\n   </sld:PolygonSymbolizer>\n   <sld:LineSymbolizer>\n      <sld:Stroke>\n         <sld:CssParameter name=\"stroke\">#808080</sld:CssParameter>\n         <sld:CssParameter name=\"stroke-width\">0.5</sld:CssParameter>\n      </sld:Stroke>\n   </sld:LineSymbolizer>\n</sld:Rule>\n
                                        7. There are three important functions, defined by the Symbology Encoding specification, that are often easier to use for theming than using rules.

                                          • Recode: Used the theme qualitative data. Attribute values are directly mapped to styling property such as fill or stroke-width.
                                          • Categorize: Used the theme quantitative data. Categories are defined using min and max ranges, and values are sorted into the appropriate category.
                                          • Interpolate: Used to smoothly theme quantitative data by calculating a styling property based on an attribute value.

                                          Theming is an activity, producing a visual result allow map readers to learn more about how an attribute is distributed spatially. We are free to produce this visual in the most efficient way possible.

                                        8. Swap out mapcolor9 theme to use the Recode function:

                                          * {\n  fill:[\n    recode(mapcolor9,\n      1,'#8dd3c7', 2,'#ffffb3', 3,'#bebada',\n      4,'#fb8072', 5,'#80b1d3', 6,'#fdb462',\n      7,'#b3de69', 8,'#fccde5', 9,'#d9d9d9')\n  ]; \n  stroke: gray;\n  stroke-width: 0.5;\n}\n
                                        9. The Map tab provides the same preview.

                                        10. The Generated SLD tab shows where things get interesting. Our generated style now consists of a single Rule:

                                          <sld:Rule>\n   <sld:PolygonSymbolizer>\n      <sld:Fill>\n         <sld:CssParameter name=\"fill\">\n            <ogc:Function name=\"Recode\">\n               <ogc:PropertyName>mapcolor9</ogc:PropertyName>\n               <ogc:Literal>1</ogc:Literal>\n                  <ogc:Literal>#8dd3c7</ogc:Literal>\n               <ogc:Literal>2</ogc:Literal>\n                  <ogc:Literal>#ffffb3</ogc:Literal>\n               <ogc:Literal>3</ogc:Literal>\n                  <ogc:Literal>#bebada</ogc:Literal>\n               <ogc:Literal>4</ogc:Literal>\n                  <ogc:Literal>#fb8072</ogc:Literal>\n               <ogc:Literal>5</ogc:Literal>\n                  <ogc:Literal>#80b1d3</ogc:Literal>\n               <ogc:Literal>6</ogc:Literal>\n                  <ogc:Literal>#fdb462</ogc:Literal>\n               <ogc:Literal>7</ogc:Literal>\n                  <ogc:Literal>#b3de69</ogc:Literal>\n               <ogc:Literal>8</ogc:Literal>\n                  <ogc:Literal>#fccde5</ogc:Literal>\n               <ogc:Literal>9</ogc:Literal>\n                  <ogc:Literal>#d9d9d9</ogc:Literal>\n         </ogc:Function>\n         </sld:CssParameter>\n      </sld:Fill>\n   </sld:PolygonSymbolizer>\n   <sld:LineSymbolizer>\n      <sld:Stroke>\n         <sld:CssParameter name=\"stroke\">#808080</sld:CssParameter>\n         <sld:CssParameter name=\"stroke-width\">0.5</sld:CssParameter>\n      </sld:Stroke>\n   </sld:LineSymbolizer>\n</sld:Rule>\n
                                        "},{"location":"styling/workshop/css/polygon/#bonus","title":"Bonus","text":"

                                        The following optional explore and challenge activities offer a chance to review and apply the ideas introduced here. The challenge activities require a bit of creativity and research to complete.

                                        In a classroom setting you are encouraged to team up into groups, with each group taking on a different challenge.

                                        "},{"location":"styling/workshop/css/polygon/#css.polygon.q1","title":"Explore Antialiasing","text":"
                                        1. When we rendered our initial preview, without a stroke, thin white gaps (or slivers) are visible between our polygons.

                                          This effect is made more pronounced by the rendering engine making use of the Java 2D sub-pixel accuracy. This technique is primarily used to prevent an aliased (stair-stepped) appearance on diagonal lines.

                                        2. Clients can turn this feature off using a GetMap format option:

                                          format_options=antialiasing=off;\n

                                          The LayerPreview provides access to this setting from the Open Layers Options Toolbar:

                                        3. Explore: Experiment with fill and stroke settings to eliminate slivers between polygons.

                                          Note

                                          Answer provided <css.polygon.a1> at the end of the workbook.

                                        "},{"location":"styling/workshop/css/polygon/#css.polygon.q2","title":"Explore Categorize","text":"

                                        Instructor Notes

                                        This section reviews use of the Symbology Encoding Categorize function for something else other than color. Goal is to have readers reach for SE Functions as often as selectors when styling.

                                        Additional exercise ideas:

                                        • Control size using Interpolate: While Recode offers an alternative for selectors (matching discrete values) Interpolate brings something new to the table - gradual color (or value) progression. The best of example of this is controlling width using the ne:rivers data layer (which is not yet available).
                                        1. The Categorize function can be used to generate property values based on quantitative information. Here is an example using Categorize to color states according to size.

                                          * {\n   fill: [\n      Categorize(Shape_Area,\n         '#08519c', 0.5,\n         '#3182bd', 1,\n         '#6baed6', 5,\n         '#9ecae1', 60,\n         '#c6dbef', 80,\n         '#eff3ff')\n   ];\n}\n

                                        2. An exciting use of the GeoServer shape symbols is the theming by changing the fill-size used for pattern density.

                                        3. Explore: Use the Categorize function to theme by datarank.

                                          Note

                                          Answer provided <css.polygon.a2> at the end of the workbook.

                                        "},{"location":"styling/workshop/css/polygon/#css.polygon.q3","title":"Challenge Goodness of Fit","text":"
                                        1. A subject we touched on during labeling was the conflict resolution GeoServer performs to ensure labels do not overlap.

                                        2. In addition to the vendor parameter for max displacement you can experiment with different values for \"goodness of fit\". These settings control how far GeoServer is willing to move a label to avoid conflict, and under what terms it simply gives up:

                                          label-fit-goodness: 0.3;\nlabel-max-displacement: 130;\n
                                        3. You can also experiment with turning off this facility completely:

                                          label-conflict-resolution: false;\n
                                        4. Challenge: Construct your own example using max displacement and fit-goodness.

                                        "},{"location":"styling/workshop/css/polygon/#css.polygon.q4","title":"Challenge Halo","text":"
                                        1. The halo example used the fill color and opacity for a muted halo, while this improved readability it did not bring attention to our labels.

                                          A common design choice for emphasis is to outline the text in a contrasting color.

                                        2. Challenge: Produce a map that uses a white halo around black text.

                                          Note

                                          Answer provided <css.polygon.a4> at the end of the workbook.

                                        "},{"location":"styling/workshop/css/polygon/#css.polygon.q5","title":"Challenge Theming using Multiple Attributes","text":"
                                        1. A powerful tool is theming using multiple attributes. This is an important concept allowing map readers to perform \"integration by eyeball\" (detecting correlations between attribute values information).

                                        2. Challenge: Combine the mapcolor9 and datarank examples to reproduce the following map.

                                          Note

                                          Answer provided <css.polygon.a5> at the end of the workbook.

                                        "},{"location":"styling/workshop/css/polygon/#css.polygon.q6","title":"Challenge Use of Z-Index","text":"
                                        1. Earlier we looked at using z-index to simulate line string casing. The line work was drawn twice, once with thick line, and then a second time with a thinner line. The resulting effect is similar to text halos - providing breathing space around complex line work allowing it to stand out.

                                        2. Challenge: Use what you know of LineString z-index to reproduce the following map:

                                        ::: note ::: title Note :::

                                        Answer provided <css.polygon.a6> at the end of the workbook. :::

                                        "},{"location":"styling/workshop/css/raster/","title":"Rasters","text":"

                                        Finally we will look at using CSS styling for the portrayal of raster data.

                                        Raster Symbology

                                        Review of raster symbology:

                                        • Raster data is Grid Coverage where values have been recorded in a regular array. In OGC terms a Coverage can be used to look up a value or measurement for each location.

                                        • When queried with a \"sample\" location:

                                          • A grid coverage can determine the appropriate array location and retrieve a value. Different techniques may be used interpolate an appropriate value from several measurements (higher quality) or directly return the \"nearest neighbor\" (faster).
                                          • A vector coverages would use a point-in-polygon check and return an appropriate attribute value.
                                          • A scientific model can calculate a value for each sample location
                                        • Many raster formats organize information into bands of content. Values recorded in these bands and may be mapped into colors for display (a process similar to theming an attribute for vector data).

                                          For imagery the raster data is already formed into red, green and blue bands for display.

                                        • As raster data has no inherent shape, the format is responsible for describing the orientation and location of the grid used to record measurements.

                                        These raster examples use a digital elevation model consisting of a single band of height measurements. The imagery examples use an RGB image that has been hand coloured for use as a base map.

                                        Reference:

                                        • Raster Symbology (User Manual | CSS Property Listing )
                                        • Rasters (User Manual | CSS Cookbook );
                                        • Point (User Manual | SLD Reference )

                                        The exercise makes use of the usgs:dem and ne:ne1 layers.

                                        "},{"location":"styling/workshop/css/raster/#image","title":"Image","text":"

                                        The raster-channels is the key property for display of images and raster data. The value auto is recommended, allowing the image format to select the appropriate red, green and blue channels for display.

                                        1. Navigate to the Styles page.

                                        2. Click Add a new style and choose the following:

                                          Name: image_example

                                          Workspace: No workspace

                                          Format: CSS

                                        3. Replace the initial CSS definition with:

                                          * {\n  raster-channels: auto;\n}\n
                                        4. And use the Layer Preview tab to preview the result.

                                        5. If required a list three band numbers can be supplied (for images recording in several wavelengths) or a single band number can be used to view a grayscale image.

                                          * {\n  raster-channels: 2;\n}\n
                                        6. Isolating just the green band (it will be drawn as a grayscale image):

                                        "},{"location":"styling/workshop/css/raster/#dem","title":"DEM","text":"

                                        A digital elevation model is an example of raster data made up of measurements, rather than colors information.

                                        The usgs:dem layer used for this exercise:

                                        1. Return to the Styles page.

                                        2. Click Add a new style and choose the following:

                                          Name: raster_example

                                          Workspace: No workspace

                                          Format: CSS

                                        3. When we use the raster-channels property set to auto the rendering engine will select our single band of raster content, and do its best to map these values into a grayscale image. Replace the content of the style with:

                                          * {\n  raster-channels: auto;\n}\n
                                        4. Use the Layer Preview tab to preview the result. The range produced in this case from the highest and lowest values.

                                        5. We can use a bit of image processing to emphasis the generated color mapping by making use raster-contrast-enhancement.

                                          * {\n  raster-channels: 1;\n  raster-contrast-enhancement: histogram;\n}\n
                                        6. Image processing of this sort should be used with caution as it does distort the presentation (in this case making the landscape look more varied then it is in reality.

                                        "},{"location":"styling/workshop/css/raster/#color-map","title":"Color Map","text":"

                                        The approach of mapping a data channel directly to a color channel is only suitable to quickly look at quantitative data.

                                        For qualitative data (such as land use) or simply to use color, we need a different approach:

                                        1. Apply the following CSS to our usgs:DEM layer:

                                          * {\n  raster-channels: auto;\n  raster-color-map: color-map-entry(#9080DB, 0)\n                    color-map-entry(#008000, 1)\n                    color-map-entry(#105020, 255)\n                    color-map-entry(#FFFFFF, 4000);\n}\n
                                        2. Resulting in this artificial color image:

                                        3. An opacity value can also be used with color-map-entry.

                                          * {\n  raster-channels: auto;\n  raster-color-map: color-map-entry(#9080DB, 0, 0.0)\n                    color-map-entry(#008000, 1, 1.0)\n                    color-map-entry(#105020, 200, 1.0)\n                    color-map-entry(#FFFFFF, 4000, 1.0);\n}\n
                                        4. Allowing the areas of zero height to be transparent:

                                        5. Raster format for GIS work often supply a \"no data\" value, or contain a mask, limiting the dataset to only the locations with valid information.

                                        "},{"location":"styling/workshop/css/raster/#custom","title":"Custom","text":"

                                        We can use what we have learned about color maps to apply a color brewer palette to our data.

                                        This exploration focuses on accurately communicating differences in value, rather than strictly making a pretty picture. Care should be taken to consider the target audience and medium used during palette selection.

                                        1. Restore the raster_example CSS style to the following:

                                          * {\n  raster-channels: auto;\n}\n
                                        2. Producing the following map preview.

                                        3. To start with we can provide our own grayscale using two color map entries.

                                          * {\n  raster-channels: auto;\n  raster-color-map: color-map-entry(#000000, 0)\n                    color-map-entry(#FFFFFF, 4000);\n}\n
                                        4. Use the Map tab to zoom in and take a look.

                                          This is much more direct representation of the source data. We have used our knowledge of elevations to construct a more accurate style.

                                        5. While our straightforward style is easy to understand, it does leave a bit to be desired with respect to clarity.

                                          The eye has a hard time telling apart dark shades of black (or bright shades of white) and will struggle to make sense of this image. To address this limitation we are going to switch to the ColorBrewer 9-class PuBuGn palette. This is a sequential palette that has been hand tuned to communicate a steady change of values.

                                        6. Update your style with the following:

                                          * {\n  raster-channels: auto;\n  raster-color-map:\n     color-map-entry(#014636,   0)\n     color-map-entry(#016c59, 500)\n     color-map-entry(#02818a,1000)\n     color-map-entry(#3690c0,1500)\n     color-map-entry(#67a9cf,2000)\n     color-map-entry(#a6bddb,2500)\n     color-map-entry(#d0d1e6,3000)\n     color-map-entry(#ece2f0,3500)\n     color-map-entry(#fff7fb,4000);\n}\n

                                        7. A little bit of work with alpha (to mark the ocean as a no-data section):

                                          * {\n  raster-channels: auto;\n  raster-color-map:\n     color-map-entry(#014636,   0,0)\n     color-map-entry(#014636,   1)\n     color-map-entry(#016c59, 500)\n     color-map-entry(#02818a,1000)\n     color-map-entry(#3690c0,1500)\n     color-map-entry(#67a9cf,2000)\n     color-map-entry(#a6bddb,2500)\n     color-map-entry(#d0d1e6,3000)\n     color-map-entry(#ece2f0,3500)\n     color-map-entry(#fff7fb,4000);\n}\n
                                        8. And we are done:

                                        "},{"location":"styling/workshop/css/raster/#bonus","title":"Bonus","text":""},{"location":"styling/workshop/css/raster/#css.raster.q1","title":"Explore Contrast Enhancement","text":"
                                        1. A special effect that is effective with grayscale information is automatic contrast adjustment.

                                        2. Make use of a simple contrast enhancement with usgs:dem:

                                          * {\n    raster-channels: auto;\n    raster-contrast-enhancement: normalize;\n}\n
                                        3. Can you explain what happens when zoom in to only show a land area (as indicated with the bounding box below)?

                                          Note

                                          Discussion provided <ysld.raster.a1> at the end of the workbook.

                                        "},{"location":"styling/workshop/css/raster/#css.raster.q2","title":"Challenge Intervals","text":"
                                        1. The raster-color-map-type property dictates how the values are used to generate a resulting color.

                                          • ramp is used for quantitative data, providing a smooth interpolation between the provided color values.
                                          • intervals provides categorization for quantitative data, assigning each range of values a solid color.
                                          • values is used for qualitative data, each value is required to have a color-map-entry or it will not be displayed.
                                        2. Challenge: Update your DEM example to use intervals for presentation. What are the advantages of using this approach for elevation data?

                                          Note

                                          Answer provided <ysld.raster.a2> at the end of the workbook.

                                          Instructor Notes

                                          By using intervals it becomes very clear how relatively flat most of the continent is. The ramp presentation provided lots of fascinating detail which distracted from this fact.

                                          Here is style for you to cut and paste:

                                          * {\n  raster-channels: auto;\n  raster-color-map:\n     color-map-entry(#014636,   0,0)\n     color-map-entry(#014636,   1)\n     color-map-entry(#016c59, 500)\n     color-map-entry(#02818a,1000)\n     color-map-entry(#3690c0,1500)\n     color-map-entry(#67a9cf,2000)\n     color-map-entry(#a6bddb,2500)\n     color-map-entry(#d0d1e6,3000)\n     color-map-entry(#ece2f0,3500)\n     color-map-entry(#fff7fb,4000);\n  raster-color-map-type: intervals;\n}\n

                                        "},{"location":"styling/workshop/css/raster/#explore-image-processing","title":"Explore Image Processing","text":"

                                        Additional properties are available to provide slight image processing during visualization.

                                        Note

                                        In this section are we going to be working around a preview issue where only the top left corner of the raster remains visible during image processing. This issue has been reported as GEOS-6213.

                                        Image processing can be used to enhance the output to highlight small details or to balance images from different sensors allowing them to be compared.

                                        1. The raster-contrast-enhancement property is used to turn on a range of post processing effects. Settings are provided for normalize or histogram or none;

                                          * {\n    raster-channels: auto;\n    raster-contrast-enhancement: normalize;\n}\n
                                        2. Producing the following image:

                                        3. The raster-gamma property is used adjust the brightness of raster-contrast-enhancement output. Values less than 1 are used to brighten the image while values greater than 1 darken the image.

                                          * {\n   raster-channels: auto;\n   raster-contrast-enhancement: none;\n   raster-gamma: 1.5;\n}\n
                                        4. Providing the following effect:

                                        "},{"location":"styling/workshop/css/raster/#css.raster.q3","title":"Challenge Clear Digital Elevation Model Presentation","text":"
                                        1. Now that you have seen the data on screen and have a better understanding how would you modify our initial gray-scale example?

                                        2. Challenge: Use what you have learned to present the usgs:dem clearly.

                                          Note

                                          Answer provided <ysld.raster.a3> at the end of the workbook.

                                          Instructor Notes

                                          The original was a dark mess, students will hopefully make use of the mid-tones (or even check color brewer) in order to fix this. I have left the ocean dark so the mountains can stand out more.

                                          * {\n  raster-channels: auto;\n  raster-color-map: color-map-entry(#000000, 0)\n                    color-map-entry(#444444, 1)\n                    color-map-entry(#FFFFFF, 3000);\n}\n

                                        "},{"location":"styling/workshop/css/raster/#css.raster.q4","title":"Challenge Raster Opacity","text":"
                                        1. There is a quick way to make raster data transparent, raster-opacity property works in the same fashion as with vector data. The raster as a whole will be drawn partially transparent allow content from other layers to provide context.

                                        2. Challenge: Can you think of an example where this would be useful?

                                          Note

                                          Discussion provided <ysld.raster.a4> at the end of the workbook.

                                        "},{"location":"styling/workshop/design/","title":"Design","text":"

                                        This section introduces mapping as a tool for visual communication.

                                        • Symbology
                                        • Style

                                        Note

                                        This section uses Open Geospatial Consortium (OGC) terminology in our description of geometry and spatial data. While the terms we use here are general purpose, they may differ slightly from those you are familiar with.

                                        References:

                                        • Geographic Markup Language
                                        • OGC Reference Model (OGC Portal)
                                        • ISO 19107 Geographic information -- Spatial schema (ISO)
                                        • How to Lie with Maps
                                        • Cartography And Map Terminologies
                                        "},{"location":"styling/workshop/design/style/","title":"Style","text":"

                                        The design choices made to represent content is a key aspect of cartography. The style used when rendering data into a visualisation is the result of these choices.

                                        The Open Geospatial Consortium standard for recording style is divided into two parts:

                                        • Symbology Encoding (SE): Records a \"feature type style\" documenting how individual features are drawn using a series of rules.
                                        • Style Layer Descriptor (SLD): Records which \"feature type styles\" may be used with a layer.

                                        The Symbology Encoding standard provides the terms we will be using to describe style:

                                        • Stroke: borders and outlines of shapes
                                        • Fill: interior of shapes
                                        "},{"location":"styling/workshop/design/style/#line-symbolizer","title":"Line symbolizer","text":"

                                        A line symbolizer documents how individual strokes are used to draw a line string, including color and line width.

                                        The SLD specification provides a default stroke used when drawing line strings. These values for color and width will be used if needed.

                                        <LineSymbolizer>\n  <Stroke/>\n</LineSymbolizer>\n

                                        GeoServer includes a default line.sld file providing a blue stroke. This file is used when you initially set up a linestring layer.

                                        From GeoServer's line.sld style:

                                        <LineSymbolizer>\n  <Stroke>\n    <CssParameter name=\"stroke\">#0000FF</CssParameter>\n  </Stroke>\n</LineSymbolizer>\n
                                        "},{"location":"styling/workshop/design/style/#polygon-symbolizer","title":"Polygon symbolizer","text":"

                                        A polygon symbolizer documents both the stroke in addition to the fill used to draw a polygon. A fill can consist of a color, pattern, or other texture:

                                        The SLD specification provides a default gray fill, but does not supply a stroke. These values will be used if you do not provide an alternative.

                                        GeoServer includes a default polygon.sld file providing a gray fill and a black outline. This file will be used when you initially create a polygon layer.

                                        From GeoServer's polygon.sld style:

                                        <PolygonSymbolizer>\n  <Fill>\n    <CssParameter name=\"fill\">#AAAAAA</CssParameter>\n  </Fill>\n  <Stroke>\n    <CssParameter name=\"stroke\">#000000</CssParameter>\n    <CssParameter name=\"stroke-width\">1</CssParameter>\n  </Stroke>\n</PolygonSymbolizer>\n
                                        "},{"location":"styling/workshop/design/style/#point-symbolizer","title":"Point symbolizer","text":"

                                        A point symbolizer documents the \"mark\" used to represent a point. A mark may be defined by a glyph (icon) or a common mark (circle, square, etc.). The point symbolizer records the stroke and fill used to draw the mark.

                                        From GeoServer's default point.sld style:

                                        <PointSymbolizer>\n  <Graphic>\n    <Mark>\n      <WellKnownName>square</WellKnownName>\n      <Fill>\n        <CssParameter name=\"fill\">#FF0000</CssParameter>\n      </Fill>\n    </Mark>\n    <Size>6</Size>\n  </Graphic>\n</PointSymbolizer>\n
                                        "},{"location":"styling/workshop/design/style/#text-symbolizer","title":"Text symbolizer","text":"

                                        A text symbolizer provides details on how labels are to be drawn, including font, size, and color information.

                                        From the populated_places.sld style:

                                        <sld:TextSymbolizer>\n    <sld:Label>\n        <ogc:PropertyName>NAME</ogc:PropertyName>\n    </sld:Label>\n    <sld:Font>\n        <sld:CssParameter name=\"font-family\">Arial</sld:CssParameter>\n        <sld:CssParameter name=\"font-size\">10.0</sld:CssParameter>\n        <sld:CssParameter name=\"font-style\">normal</sld:CssParameter>\n        <sld:CssParameter name=\"font-weight\">bold</sld:CssParameter>\n    </sld:Font>\n    <sld:Halo>\n        <sld:Radius>1</sld:Radius>\n        <sld:Fill>\n            <sld:CssParameter name=\"fill\">#FFFFFF</sld:CssParameter>\n        </sld:Fill>\n    </sld:Halo>\n    <sld:Fill>\n        <sld:CssParameter name=\"fill\">#000000</sld:CssParameter>\n    </sld:Fill>\n</sld:TextSymbolizer>\n

                                        Note

                                        The Style Layer Descriptor standard makes use of the Filter Encoding specification to create small expressions as shown above to access the NAME of each city:

                                        <ogc:PropertyName>NAME</ogc:PropertyName>\n

                                        This same approach can be used to dynamically generate any values needed for styling.

                                        "},{"location":"styling/workshop/design/style/#raster-symbolizer","title":"Raster symbolizer","text":"

                                        A raster symbolizer provides a mapping from raster values to colors displayed. This can be provided by a color table, function, or directly mapping bands of data to use for the display channels.

                                        From GeoServer's dem.sld style:

                                        <RasterSymbolizer>\n  <Opacity>1.0</Opacity>\n  <ColorMap>\n    <ColorMapEntry color=\"#000000\" quantity=\"-500\" label=\"nodata\" opacity=\"0.0\" />\n    <ColorMapEntry color=\"#AAFFAA\" quantity=\"0\" label=\"values\" />\n    <ColorMapEntry color=\"#00FF00\" quantity=\"1000\"/>\n    <ColorMapEntry color=\"#FFFF00\" quantity=\"1200\" label=\"values\" />\n    <ColorMapEntry color=\"#FF7F00\" quantity=\"1400\" label=\"values\" />\n    <ColorMapEntry color=\"#BF7F3F\" quantity=\"1600\" label=\"values\" />\n    <ColorMapEntry color=\"#000000\" quantity=\"2000\" label=\"values\" />\n  </ColorMap>\n</RasterSymbolizer>\n
                                        "},{"location":"styling/workshop/design/symbology/","title":"Symbology","text":"

                                        In cartography, symbology is the practice of representing information using shapes, colors and symbols on a map.

                                        A map legend, offers a quick summary of the symbology used for a map.

                                        The symbology for each layer should be distinct, allowing readers to clearly understand the information being presented. Care should be taken to consider the situation in which the map will be used, such as:

                                        • Screen size of the output device
                                        • Ability of target device to reproduce color
                                        • Allowances for disabilities such as color blindness
                                        "},{"location":"styling/workshop/design/symbology/#theme","title":"Theme","text":"

                                        For thematic maps, the symbology is changed on a feature-by-feature basis in order to illustrate the attribute values being presented.

                                        The same data set may be represented in different maps, themed by a different attribute each time.

                                        "},{"location":"styling/workshop/design/symbology/#using-multiple-themes","title":"Using Multiple Themes","text":"

                                        A single map can be produced showing two datasets (each themed by a different attribute) allowing readers to look for any interesting patterns.

                                        As an example there may be a relationship between a country's growing region and annual rainfall.

                                        "},{"location":"styling/workshop/design/symbology/#map-icons","title":"Map Icons","text":"

                                        The use of map icons (pictograms, glyphs or symbology sets) is a special case where we have a gap in terminology between Cartography and GIS.

                                        As an example we may wish to represent a point-of-interest data set with each location marked by a different symbol.

                                        In cartography, each \"type\" is presented to the user as a clearly distinct data set with its own visual representation in the map legend.

                                        This is contrasted with GIS, where the \"points of interest\" are managed as a single layer and complex styling is used to produce the desired cartographic output.

                                        Technically the data set is themed by an attribute to produce this effect:

                                        • Often an attribute named type is introduced, and styling rules are used to associated each value with a distinct graphic mark.
                                        • Another common solution is to distribute the \"symbology set\" as TrueType font. A character attribute is introduced, the value of which is the appropriate letter to draw.
                                        "},{"location":"styling/workshop/design/symbology/#map-design","title":"Map Design","text":"

                                        The choice of how to present content is the subject of map design. Cartography, like any venue for design, is a human endeavor between art and science. In this exercise we are going to explore the trade offs in the use of color for effective communication.

                                        It is a challenge to explore cartography without getting stuck in the details of configuring style (which we will cover next). In order to side-step these details, we will be using a web application for this section: Color Brewer by Cynthia Brewer of Pennsylvania State University.

                                        Selection of an appropriate color palette is difficult, with a tension between what looks good and what can be understood. The research project that produced the color palettes used by Color Brewer was based on comprehension tests.

                                        1. Navigate to: http://colorbrewer2.org/

                                          The website provides a generic data set which we can use to determine how effective each choice is in communicating attribute differences. We will be using this website to explore how to effectively theme an attribute.

                                          Color Brewer

                                        2. The decisions we make when theming depend entirely on what point we are trying to communicate.

                                          In this scenario, we are going to communicate a vaccination schedule, county by county. Care should be taken to ensure each county appears equally important, and we should stay clear of red for anyone squeamish about needles. We need to ensure readers can quickly locate their county and look at the appropriate calendar entry.

                                        3. The first step is determining how many attribute values you are looking to communicate. Set Number of data classes to 5.

                                          Number of data classes

                                        4. Color brewer offers palettes using three different color schemes:

                                          Sequential

                                          Diverging

                                          Qualitative

                                          The nature of our data is qualitative (each attribute value is attached an equal importance, and there is no implied order that wish to communicate with color).

                                        5. Set Nature of your data to Qualitative. This change drastically reduces the number of color schemes listed.

                                          Qualitative color scheme

                                        6. The initial 5-class Accent color scheme does reasonably well.

                                          5-class accent

                                        7. One of our requirements is to help readers locate their county. To assist with that let's turn on roads and cities.

                                          Adding context

                                        8. The map is now starting to look a little busy:

                                          Lots of context

                                        9. Now that we have seen what we are up against, we can try a strategy to help the text and roads stand out while still communicating our vaccination schedule. Change to one of the pastel color schemes.

                                          Pastel color scheme

                                        10. Change the borders and roads to gray.

                                          Gray borders and roads

                                        11. The result is fairly clear symbology and provides context.

                                          Finished with context

                                        12. Using our current \"pastel\" design, set the Number of data classes to 9. At values larger than this, the distinctions between colors becomes so subtle that readers will have trouble clearly distinguishing the content.

                                        13. Make a note of these colors (we will be using them in the exercise on styling next).

                                          Category Color 1 #fbb4ae 2 #b3cde3 3 #ccebc5 4 #decbe4 5 #fed9a6 6 #ffffcc 7 #e5d8bd 8 #fddaec 9 #f2f2f2

                                          Color palette

                                        "},{"location":"styling/workshop/design/symbology/#bonus","title":"Bonus","text":"

                                        Finished early? While waiting take a moment to explore this topic in more detail, and if you are feeling creative there is a challenge to try.

                                        Note

                                        In a classroom setting please divide the challenges between teams.

                                        This allows us to work through all the material in the time available.

                                        Explore Device Differences

                                        1. Different output devices provide limitations in the amount of color information they can portray.

                                        2. Explore: How does changing to a printed map affect the number of classes you can communicate using the current \"pastel\" approach?

                                          Instructor Notes

                                          The answer is five, but to be really sure four. Read the tool tips to determine fitness for purpose.

                                        Explore Accessibility

                                        1. Communication is a two way street, both in presenting information through design choices, and also perceiving information.

                                          Disabled readers will have a diminished ability to comprehend maps based on color.

                                        2. Explore: What approach can be used to cater to color-blind map readers?

                                          Instructor Notes

                                          Select a color-blind-safe palette, or make use of texture or pattern to communicate attribute changes.

                                        Explore Color Choice

                                        1. The Color Brewer application provides a lot of helpful information using the small \"information\" icons in each section.

                                          Information icons

                                        2. Explore: Using this information which color scheme would you choose for a digital elevation model?

                                          Instructor Notes

                                          Sequential scheme to communicate elevation differences with equal emphasis. If a reader wants to use diverging to emphasis the extremes, that is fine as long as they are doing it on purpose.

                                        Challenge Adjusted Colour Scheme

                                        1. Some datasets included a critical value or threshold that should be communicated clearly.

                                        2. Challenge: How would you adjust a diverging color scheme to be suitable for a digital elevation model that includes bathymetry information (ocean depth)?

                                          Hint: For a target audience of humans sea-level would be considered a critical value.

                                          Instructor Notes

                                          The answer is provided by a Learn more link in the application:

                                          • http://colorbrewer2.org/js/learnmore/schemes_full.html#diverging

                                          Remove colors until the critical value is at sea-level.

                                        "},{"location":"styling/workshop/mbstyle/","title":"MBStyle Styling Workbook","text":"

                                        GeoServer styling can be used for a range of creative effects. This section introduces the MBStyle Extension which can be used as alternative to SLD files.

                                        • MBStyle Quickstart
                                        • Lines
                                        • Polygons
                                        • Points
                                        • Rasters
                                        • MBStyle Workbook Conclusion
                                        "},{"location":"styling/workshop/mbstyle/done/","title":"MBStyle Workbook Conclusion","text":"

                                        We hope you have enjoyed this styling workshop.

                                        Additional resources:

                                        • MBStyle Extension
                                        • MBStyle Reference
                                        "},{"location":"styling/workshop/mbstyle/done/#mbstyle-tips-and-tricks","title":"MBStyle Tips and Tricks","text":""},{"location":"styling/workshop/mbstyle/done/#mbstyle-workshop-answer-key","title":"MBStyle Workshop Answer Key","text":"

                                        The following questions were listed throughout the workshop as an opportunity to explore the material in greater depth. Please do your best to consider the questions in detail prior to checking here for the answer. Questions are provided to teach valuable skills, such as a chance to understand how feature type styles are used to control z-order, or where to locate information in the user manual.

                                        Note

                                        Coming Soon

                                        "},{"location":"styling/workshop/mbstyle/done/#mbstyle.line.a1","title":"Classification","text":"

                                        Answer for Challenge Classification <mbstyle.line.q1>:

                                        1. Challenge: Create a new style adjust road appearance based on type.

                                          Hint: The available values are 'Major Highway','Secondary Highway','Road' and 'Unknown'.

                                        2. Here is an example:

                                          {\n \"version\": 8,\n \"name\": \"line_example\",\n \"layers\": [\n   {\n     \"id\": \"line_hwy1\",\n     \"source-layer\": \"ne:roads\",\n     \"type\": \"line\",\n     \"filter\": [\"==\", \"type\", \"Major Highway\"],\n     \"paint\": {\n       \"line-color\": \"#000088\",\n       \"line-width\": 1.25,\n       \"line-opacity\": 0.25 \n     }\n   },\n   {\n     \"id\": \"line_hwy2\",\n     \"source-layer\": \"ne:roads\",\n     \"type\": \"line\",\n     \"filter\": [\"==\", \"type\", \"Secondary Highway\"],\n     \"paint\": {\n       \"line-color\": \"#8888AA\",\n       \"line-width\": 0.75,\n       \"line-opacity\": 0.25\n     }\n   },\n   {\n     \"id\": \"line_road\",\n     \"source-layer\": \"ne:roads\",\n     \"type\": \"line\",\n     \"filter\": [\"==\", \"type\", \"Road\"],\n     \"paint\": {\n       \"line-color\": \"#888888\",\n       \"line-width\": 0.75,\n       \"line-opacity\": 0.25\n     }\n   },\n   {\n     \"id\": \"line_unk\",\n     \"source-layer\": \"ne:roads\",\n     \"type\": \"line\",\n     \"filter\": [\"==\", \"type\", \"Unknown\"],\n     \"paint\": {\n       \"line-color\": \"#888888\",\n       \"line-width\": 0.5,\n       \"line-opacity\": 0.25\n     }\n   }\n ]\n}\n
                                        "},{"location":"styling/workshop/mbstyle/done/#mbstyle.line.a2","title":"One Rule Classification","text":"

                                        Answer for Challenge One Rule Classification <mbstyle.line.q2>:

                                        1. Challenge: Create a new style and classify the roads based on their scale rank using expressions in a single rule instead of multiple rules with filters.
                                        2. This exercise requires looking up information in the MBstyle user guide.
                                          • The Mapbox Style specification functions provides details.
                                        "},{"location":"styling/workshop/mbstyle/done/#mbstyle.line.a3","title":"Label Shields","text":"

                                        Answer for Challenge Label Shields <mbstyle.line.q3>:

                                        1. Challenge: Have a look at the documentation for putting a graphic on a text symbolizer in SLD and reproduce this technique in MBStyle.

                                        2. The use of a label shield is a vendor specific capability of the GeoServer rendering engine. The tricky part of this exercise is finding which symbol layout parameters give the desired behavior, mainly icon-text-fit but also the various placement and overlap parameters to allow the text to be drawn atop the labels ( see symbol layer).

                                          {\n  \"version\": 8,\n  \"name\": \"line_example\",\n  \"sprite\": \"http://localhost:8080/geoserver/styles/sprites\",\n  \"layers\": [\n    {\n      \"id\": \"line_casing\",\n      \"source-layer\": \"ne:roads\",\n      \"type\": \"line\",\n      \"paint\": {\n        \"line-color\": \"#000000\",\n        \"line-width\": 3,\n      }\n    },\n    {\n      \"id\": \"line_inner\",\n      \"source-layer\": \"ne:roads\",\n      \"type\": \"line\",\n      \"paint\": {\n        \"line-color\": \"#D3D3D3\",\n        \"line-width\": 2,\n      }\n    },\n    {\n      \"id\": \"label\",\n      \"source-layer\": \"ne:roads\",\n      \"type\": \"symbol\",\n      \"layout\": {\n        \"icon-image\": \"white_square16\",\n        \"icon-text-fit\": \"width\",\n        \"icon-text-fit-padding\": [2, 2, 2, 2],\n        \"text-field\": \"{name}\",\n        \"text-font\": [\"Ariel\"],\n        \"text-font-size\": 10,\n        \"text-ignore-placement\": true,\n        \"text-allow-overlap\": true,\n        \"icon-ignore-placement\": true,\n        \"icon-allow-overlap\": true,\n        \"symbol-placement\": \"line\",\n        \"symbol-spacing\": 0\n\n      }\n      \"paint\": {\n        \"text-color\": \"black\"\n      }\n    }\n  ]\n}\n
                                        "},{"location":"styling/workshop/mbstyle/done/#mbstyle.polygon.a2","title":"Interval","text":"

                                        Answer for Explore Interval <mbstyle.polygon.q2>:

                                        1. An exciting use of the GeoServer fill-pattern symbols is theming by changing the pattern used.

                                        2. Explore: Use the interval function to theme by datarank.

                                          Example:

                                          {\n \"version\": 8,\n \"name\": \"polygon_example\",\n \"sprite\": \"http://localhost:8080/geoserver/styles/sprites\",\n \"layers\": [\n   {\n     \"id\": \"polygon\",\n     \"source-layer\": \"ne:states_provinces_shp\",\n     \"type\": \"fill\",\n     \"paint\": {\n       \"fill-pattern\": {\n         \"property\": \"datarank\",\n         \"type\": \"interval\",\n         \"stops\": [\n           [4, \"grey_diag8\"],\n           [6, \"grey_diag16\"]\n         ]\n       }\n     }\n   }\n ]\n}\n
                                        "},{"location":"styling/workshop/mbstyle/done/#mbstyle.polygon.a4","title":"Halo","text":"

                                        Answer for Challenge Halo <mbstyle.polygon.q4>:

                                        1. The halo example used the fill color and opacity for a muted halo, while this improved readability it did not bring attention to our labels.

                                          A common design choice for emphasis is to outline the text in a contrasting color.

                                        2. Challenge: Produce a map that uses a white halo around black text.

                                          Here is an example:

                                          {\n  \"version\": 8,\n  \"name\": \"polygon_example\",\n  \"layers\": [\n    {\n      \"id\": \"polygon_fill\",\n      \"source-layer\": \"ne:states_provinces_shp\",\n      \"type\": \"fill\",\n      \"paint\": {\n        \"fill-color\": \"#7EB5D3\",\n        \"fill-outline-color\": \"gray\"\n      }\n    },\n    {\n      \"id\": \"polygon_label\",\n      \"source-layer\": \"ne:states_provinces_shp\",\n      \"type\": \"symbol\",\n      \"layout\": {\n        \"text-field\": \"{name}\",\n        \"text-anchor\": \"center\"\n        \"text-max-width\": 14,\n        \"text-font\": [\"Arial\"]\n      },\n      \"paint\": {\n        \"text-color\": \"white\",\n        \"text-halo-color\": \"black\",\n        \"text-halo-width\": 1\n\n      }\n    }\n  ]\n}\n
                                        "},{"location":"styling/workshop/mbstyle/done/#mbstyle.polygon.a5","title":"Theming using Multiple Attributes","text":"

                                        Answer for Challenge Theming using Multiple Attributes <mbstyle.polygon.q5>:

                                        1. A powerful tool is theming using multiple attributes. This is an important concept allowing map readers to perform \"integration by eyeball\" (detecting correlations between attribute values information).

                                        2. Challenge: Combine the mapcolor9 and datarank examples to reproduce the following map.

                                          This should be a cut and paste using the categorical example, and interval examples already provided.

                                          {\n  \"version\": 8,\n  \"name\": \"polygon_example\",\n  \"sprite\": \"http://localhost:8080/geoserver/styles/sprites\",\n  \"layers\": [\n    {\n      \"id\": \"polygon\",\n      \"source-layer\": \"ne:states_provinces_shp\",\n      \"type\": \"fill\",\n      \"paint\": {\n        \"fill-color\": {\n          \"property\": \"mapcolor9\",\n          \"type\": \"categorical\",\n          \"stops\": [\n            [1, \"#8dd3c7\"],\n            [2, \"#ffffb3\"],\n            [3, \"#bebada\"],\n            [4, \"#fb8072\"],\n            [5, \"#80b1d3\"],\n            [6, \"#fdb462\"],\n            [7, \"#b3de69\"],\n            [8, \"#fccde5\"],\n            [9, \"#d9d9d9\"]\n          ]\n        },\n        \"fill-outline-color\": \"gray\"\n      }\n    },\n    {\n      \"id\": \"polygon\",\n      \"source-layer\": \"ne:states_provinces_shp\",\n      \"type\": \"fill\",\n      \"paint\": {\n        \"fill-pattern\": {\n          \"property\": \"datarank\",\n          \"type\": \"interval\",\n          \"stops\": [\n            [4, \"grey_diag8\"],\n            [6, \"grey_diag16\"]\n          ]\n        }\n      }\n    }\n  ]\n}\n
                                        "},{"location":"styling/workshop/mbstyle/done/#mbstyle.polygon.a6","title":"Use of Z-Index","text":"

                                        Answer for Challenge Use of Z-Index <mbstyle.polygon.q6>:

                                        1. Using multiple layers to simulate line string casing. The resulting effect is similar to text halos - providing breathing space around complex line work allowing it to stand out.

                                        2. Challenge: Use what you know of LineString rendering order to reproduce the following map:

                                          This is much easier when using MBStyle, where z-order is controlled by layer.

                                          {\n   \"version\": 8,\n   \"name\": \"polygon_example\",\n   \"sprite\": \"http://localhost:8080/geoserver/styles/sprites\",\n   \"layers\": [\n     {\n       \"id\": \"polygon_fill\",\n       \"source-layer\": \"ne:states_provinces_shp\",\n       \"type\": \"fill\",\n       \"paint\": {\n         \"fill-color\": \"lightgrey\",\n       }\n     },\n     {\n       \"id\": \"polygon_pattern\",\n       \"source-layer\": \"ne:states_provinces_shp\",\n       \"type\": \"fill\",\n       \"paint\": {\n         \"fill-pattern\": \"grey_diag16\"\n       }\n     }\n     {\n       \"id\": \"polygon_casing\",\n       \"source-layer\": \"ne:states_provinces_shp\",\n       \"type\": \"line\",\n       \"paint\": {\n         \"line-color\": \"lightgrey\",\n         \"line-width\": 6\n       }\n     },\n     {\n       \"id\": \"polygon_outline\",\n       \"source-layer\": \"ne:states_provinces_shp\",\n       \"type\": \"line\",\n       \"paint\": {\n         \"line-color\": \"black\",\n         \"line-width\": 1.5\n       }\n     }\n   ]\n }\n

                                          The structure of the legend graphic provides an indication on what is going on.

                                        "},{"location":"styling/workshop/mbstyle/done/#mbstyle.point.a1","title":"Geometry Location","text":"

                                        Answer for Challenge Geometry Location <mbstyle.point.q1>:

                                        1. The symbol layer can be used to render any geometry content.

                                        2. Challenge: Try this yourself by rendering polygon data using a symbol layer.

                                          This can be done one of two ways:

                                          • Changing the association of a polygon layer, such as ne:states_provinces_shp to point_example and using the layer preview page.
                                          • Changing the Layer Preview tab to a polygon layer, such as ne:states_provinces_shp.

                                          The important thing to notice is that the centroid of each polygon is used as a point location.

                                        "},{"location":"styling/workshop/mbstyle/done/#mbstyle.point.a2","title":"Dynamic Symbolization","text":"

                                        Answer for Explore Dynamic Symbolization <mbstyle.point.q2>:

                                        1. icon-image provides an opportunity for dynamic symbolization.

                                          This is accomplished by using a function for the value of icon-image:

                                          {\n  \"version\": 8,\n  \"name\": \"point_example\",\n  \"sprite\": \"http://localhost:8080/geoserver/styles/sprites\",\n  \"layers\": [\n    {\n      \"id\": \"point_capital\",\n      \"type\": \"symbol\",\n      \"source-layer\": \"ne:populated_places\",\n      \"layout\": {\n        \"icon-image\": {\n          \"type\": \"categorical\",\n          \"property\": \"FEATURECLA\",\n          \"default\": \"grey_circle\",\n          \"stops\": [\n            [\"Admin-0 capital\", \"star\"]\n          ]\n        }\n      }\n    }\n  ]\n}\n
                                        2. Challenge: Use this approach to rewrite the Dynamic Styling example.

                                          Example available here point_example.json :

                                          {

                                          \"id\": \"point_example\", \"type\": \"symbol\", \"source-layer\": \"ne:populated_places\", \"layout\": { \"icon-image\": { \"type\": \"categorical\", \"property\": \"FEATURECLA\", \"default\": \"grey_circle\", \"stops\": [ [\"Admin-0 capital\", \"star\"] ] }, \"icon-size\": { \"property\": \"SCALERANK\", \"type\": \"exponential\", \"stops\": [ [0, 2.5], [10, 1] ] }, }

                                          }

                                        "},{"location":"styling/workshop/mbstyle/done/#mbstyle.raster.a4","title":"Raster Opacity","text":"

                                        Discussion for Challenge Raster Opacity <mbstyle.raster.q4>:

                                        1. There is a quick way to make raster data transparent, raster opacity property works in the same fashion as with vector data. The raster as a whole will be drawn partially transparent allow content from other layers to provide context.

                                        2. Challenge: Can you think of an example where this would be useful?

                                          This is difficult as raster data is usually provided for use as a basemap, with layers being drawn over top.

                                          The most obvious example here is the display of weather systems, or model output such as fire danger. By drawing the raster with some transparency, the landmass can be shown for context.

                                        "},{"location":"styling/workshop/mbstyle/linestring/","title":"Lines","text":"

                                        We will start our tour of MBStyle styling by looking at the representation of lines.

                                        LineString Geometry

                                        Review of line symbology:

                                        • Lines can be used to represent either abstract concepts with length but not width such as networks and boundaries, or long thin features with a didth that is too smallt o represent on the map. This means that the visual width of line symbols do not normally change depending on scale.
                                        • Lines are recorded as LineStrings or Curves depending on the geometry model used.
                                        • SLD uses a LineSymbolizer to record how the shape of a line is drawn. The primary characteristic documented is the Stroke used to draw each segment between vertices.
                                        • Labeling of line work is anchored to the midpoint of the line. GeoServer provides a vendor option to allow label rotation aligned with line segments.

                                        For our exercises we are going to be using simple MBStyle documents, often consisting of a single layer, in order to focus on the properties used for line symbology.

                                        Each exercise makes use of the ne:roads layer.

                                        Reference:

                                        • MBStyle Reference
                                        • MapBox Style Spec Line Layer
                                        • LineString (User Manual | SLD Reference )
                                        "},{"location":"styling/workshop/mbstyle/linestring/#line","title":"Line","text":"

                                        A line layer is represented by the line type.

                                        Basic Stroke Properties

                                        1. Navigate to the Styles page.

                                        2. Click Add a new style and choose the following:

                                          New style name: line_example

                                          Workspace for new layer: Leave blank

                                          Format: MBStyle

                                        3. Fill in the style editor

                                          {\n  \"version\": 8,\n  \"name\": \"line_example\",\n  \"layers\": [\n      {\n          \"id\": \"line_example\",\n          \"source-layer\": \"ne:roads\",\n          \"type\": \"line\",\n      }\n  ]\n}\n
                                        4. Click Apply

                                        5. Click Layer Preview to see your new style applied to a layer.

                                          You can use this tab to follow along as the style is edited, it will refresh each time Apply is pressed.

                                        6. You can see the equivalent SLD by requesting http://localhost:8080/geoserver/rest/styles/line_example.sld?pretty=true which will currently show the default line symbolizer we created.

                                          <?xml version=\"1.0\" encoding=\"UTF-8\"?><sld:StyledLayerDescriptor xmlns=\"http://www.opengis.net/sld\" xmlns:sld=\"http://www.opengis.net/sld\" xmlns:gml=\"http://www.opengis.net/gml\" xmlns:ogc=\"http://www.opengis.net/ogc\" version=\"1.0.0\">\n  <sld:NamedLayer>\n    <sld:Name>line_example</sld:Name>\n    <sld:UserStyle>\n      <sld:Name>line_example</sld:Name>\n      <sld:FeatureTypeStyle>\n        <sld:Name>name</sld:Name>\n        <sld:Rule>\n          <sld:LineSymbolizer/>\n        </sld:Rule>\n      </sld:FeatureTypeStyle>\n    </sld:UserStyle>\n  </sld:NamedLayer>\n</sld:StyledLayerDescriptor>\n

                                        We only specified the line layer, so all of the boilerplate around was generated for us.

                                        1. Additional properties cane be used fine-tune appearance. Use line-color to specify the colour and width of the line.

                                          {\n  \"paint\": {\n    \"line-color\": \"blue\"\n  }\n}\n
                                        2. line-width lets us make the line wider

                                          {\n  \"paint\": {\n    \"line-color\": \"blue\",\n    \"line-width\": 2\n  }\n}\n
                                        3. line-dasharray applies a dot dash pattern.

                                          {\n  \"paint\": {\n    \"line-color\": \"blue\",\n    \"line-width\": 2,\n    \"line-dasharray\": [5, 2]\n  }\n}\n
                                        4. Check the Map tab to preview the result.

                                        "},{"location":"styling/workshop/mbstyle/linestring/#multiple-layers","title":"Multiple Layers","text":"

                                        Providing two strokes is often used to provide a contrasting edge (called casing) to thick lines. This can be created using two layers.

                                        1. Start by filling in a bit of boilerplate that we'll be using

                                          {\n  \"version\": 8,\n  \"name\": \"line_example\",\n  \"layers\": [\n    {\n      \"id\": \"line_example\",\n      \"source-layer\": \"ne:roads\",\n      \"type\": \"line\",\n      \"paint\": {\n        \"line-color\": \"#8080E6\",\n        \"line-width\": 3,\n      }\n    }\n  ]\n}\n
                                        2. Add a second layer to the rule

                                          {\n  \"version\": 8,\n  \"name\": \"line_example\",\n  \"layers\": [\n    {\n      \"id\": \"line_casing\",\n      \"source-layer\": \"ne:roads\",\n      \"type\": \"line\",\n      \"paint\": {\n        \"line-color\": \"black\",\n        \"line-width\": 5,\n      }\n    },\n    {\n      \"id\": \"line_center\",\n      \"source-layer\": \"ne:roads\",\n      \"type\": \"line\",\n      \"paint\": {\n        \"line-color\": \"#8080E6\",\n        \"line-width\": 3,\n      }\n    }\n  ]\n}\n

                                          The wider black line is first so it is drawn first, then the thinner blue line drawn second and so over top of the black line. This is called the painter's algorithm.

                                        "},{"location":"styling/workshop/mbstyle/linestring/#label","title":"Label","text":"

                                        Our next example is significant as it introduces how text labels are generated.

                                        Use of Label Property

                                        This is also our first example making use of a dynamic style (where a value comes from an attribute from your data).

                                        1. To enable LineString labeling we add a symbol layer with a text-field.

                                          Update line_example with the following:

                                          {\n  \"version\": 8,\n  \"name\": \"line_example\",\n  \"layers\": [\n    {\n      \"id\": \"line\",\n      \"source-layer\": \"ne:roads\",\n      \"type\": \"line\",\n      \"paint\": {\n        \"line-color\": \"blue\",\n        \"line-width\": 1,\n      }\n    },\n    {\n      \"id\": \"label\",\n      \"source-layer\": \"ne:roads\",\n      \"type\": \"symbol\",\n      \"layout\": {\n        \"text-field\": \"{name}\"\n      }\n    }\n  ]\n}\n
                                        2. The SLD standard documents the default label position for each kind of Geometry. For LineStrings the initial label is positioned on the midway point of the line.

                                        3. We have used a feature property calculate a value for the label. The label is generated dynamically from the name attribute. Feature properties are supplied within curly braces, and must match the name of a property of the feature type.

                                          {\n \"version\": 8,\n \"name\": \"line_example\",\n \"layers\": [\n   {\n     \"id\": \"line\",\n     \"source-layer\": \"ne:roads\",\n     \"type\": \"line\",\n     \"paint\": {\n       \"line-color\": \"blue\",\n       \"line-width\": 1,\n     }\n   },\n   {\n     \"id\": \"label\",\n     \"source-layer\": \"ne:roads\",\n     \"type\": \"symbol\",\n     \"layout\": {\n       \"text-field\": \"{name}\"\n     }\n   }\n ]\n}\n
                                        4. Additional keys can be supplied to fine-tune label presentation:

                                          {\n  \"version\": 8,\n  \"name\": \"line_example\",\n  \"layers\": [\n    {\n      \"id\": \"line\",\n      \"source-layer\": \"ne:roads\",\n      \"type\": \"line\",\n      \"paint\": {\n        \"line-color\": \"blue\",\n        \"line-width\": 1,\n      }\n    },\n    {\n      \"id\": \"label\",\n      \"source-layer\": \"ne:roads\",\n      \"type\": \"symbol\",\n      \"layout\": {\n        \"text-field\": \"{name}\",\n        \"symbol-placement\": \"line\",\n        \"text-offset\": [0, -8]\n      }\n      \"paint\": {\n        \"text-color\": \"black\"\n      }\n    }\n  ]\n}\n
                                        5. The text-color property is set to black to provide the colour of the text. Notice how this is a paint property, unlike all the others which are layout properties.

                                          {\n  \"version\": 8,\n  \"name\": \"line_example\",\n  \"layers\": [\n    {\n      \"id\": \"line\",\n      \"source-layer\": \"ne:roads\",\n      \"type\": \"line\",\n      \"paint\": {\n        \"line-color\": \"blue\",\n        \"line-width\": 1,\n      }\n    },\n    {\n      \"id\": \"label\",\n      \"source-layer\": \"ne:roads\",\n      \"type\": \"symbol\",\n      \"layout\": {\n        \"text-field\": \"{name}\",\n        \"symbol-placement\": \"line\",\n        \"text-offset\": [0, -8]\n      }\n      \"paint\": {\n        \"text-color\": \"black\"\n      }\n    }\n  ]\n}\n
                                        6. The symbol-placement property is used to set how the label is placed with respect to the line. By default it is point which causes the label to be placed next to the midpoint as it would be for a point feature. When set to line it is placed along the line instead. text-offset specifies how far from the anchor the label should be placed, in both the x and y directions.

                                          {\n  \"version\": 8,\n  \"name\": \"line_example\",\n  \"layers\": [\n    {\n      \"id\": \"line\",\n      \"source-layer\": \"ne:roads\",\n      \"type\": \"line\",\n      \"paint\": {\n        \"line-color\": \"blue\",\n        \"line-width\": 1,\n      }\n    },\n    {\n      \"id\": \"label\",\n      \"source-layer\": \"ne:roads\",\n      \"type\": \"symbol\",\n      \"layout\": {\n        \"text-field\": \"{name}\",\n        \"symbol-placement\": \"line\",\n        \"text-offset\": [0, -8]\n      }\n      \"paint\": {\n        \"text-color\": \"black\"\n      }\n    }\n  ]\n}\n

                                        "},{"location":"styling/workshop/mbstyle/linestring/#how-labeling-works","title":"How Labeling Works","text":"

                                        The rendering engine collects all the generated labels during the rendering of each layer. Then, during labeling, the engine sorts through the labels performing collision avoidance (to prevent labels overlapping). Finally the rendering engine draws the labels on top of the map. Even with collision avoidance you can spot areas where labels are so closely spaced that the result is hard to read.

                                        1. The parameter text-padding provides additional space around our label for use in collision avoidance.

                                          {\n  \"version\": 8,\n  \"name\": \"line_example\",\n  \"layers\": [\n    {\n      \"id\": \"line\",\n      \"source-layer\": \"ne:roads\",\n      \"type\": \"line\",\n      \"paint\": {\n        \"line-color\": \"blue\",\n        \"line-width\": 1,\n      }\n    },\n    {\n      \"id\": \"label\",\n      \"source-layer\": \"ne:roads\",\n      \"type\": \"symbol\",\n      \"layout\": {\n        \"text-field\": \"{name}\",\n        \"symbol-placement\": \"line\",\n        \"text-offset\": [0, -8],\n        \"text-padding\": \"10\"\n      }\n      \"paint\": {\n        \"text-color\": \"black\"\n      }\n    }\n  ]\n}\n
                                        2. Each label is now separated from its neighbor, improving legibility.

                                        "},{"location":"styling/workshop/mbstyle/linestring/#zoom","title":"Zoom","text":"

                                        This section explores the use of rules with filters and zoom restrictions.

                                        1. Replace the line_example MBStyle definition with:

                                          {\n  \"version\": 8,\n  \"name\": \"line_example\",\n  \"layers\": [\n    {\n      \"id\": \"line_example\",\n      \"source-layer\": \"ne:roads\",\n      \"type\": \"line\",\n      \"filter\": [\"<\", \"scalerank\", 4],\n      \"paint\": {\n        \"line-color\": \"black\",\n        \"line-width\": 1\n      }\n    }\n  ]\n}\n
                                        2. And use the Map tab to preview the result.

                                        3. The scalerank attribute is provided by the Natural Earth dataset to allow control of the level of detail based on scale. Our filter short-listed all content with scalerank 4 or lower, providing a nice quick preview when we are zoomed out.

                                        4. In addition to testing feature attributes, selectors can also be used to check the state of the rendering engine.

                                          Replace your MBStyle with the following:

                                          {\n  \"version\": 8,\n  \"name\": \"line_example\",\n  \"layers\": [\n    {\n      \"id\": \"line_black\",\n      \"source-layer\": \"ne:roads\",\n      \"type\": \"line\",\n      \"maxzoom\": 3,\n      \"paint\": {\n        \"line-color\": \"black\",\n        \"line-width\": 1\n      }\n    },\n    {\n      \"id\": \"line_blue\",\n      \"source-layer\": \"ne:roads\",\n      \"type\": \"line\",\n      \"minzoom\": 3,\n      \"paint\": {\n        \"line-color\": \"blue\",\n        \"line-width\": 1\n      }\n    }\n  ]\n}\n
                                        5. As you adjust the scale in the Map preview (using the mouse scroll wheel) the color will change between black and blue. You can read the current scale in the bottom right corner, and the legend will change to reflect the current style.

                                        6. Putting these two ideas together allows control of level detail based on scale:

                                          {\n  \"version\": 8,\n  \"name\": \"line_example\",\n  \"layers\": [\n    {\n      \"id\": \"line_else\",\n      \"source-layer\": \"ne:roads\",\n      \"type\": \"line\",\n      \"filter\": [\">\", \"scalerank\", 7],\n      \"minzoom\": 7,\n      \"paint\": {\n        \"line-color\": \"#888888\",\n        \"line-width\": 1\n      }\n    },\n    {\n      \"id\": \"line_7\",\n      \"source-layer\": \"ne:roads\",\n      \"type\": \"line\",\n      \"filter\": [\"==\", \"scalerank\", 7],\n      \"minzoom\": 6,\n      \"paint\": {\n        \"line-color\": \"#777777\",\n        \"line-width\": 1\n      }\n    },\n    {\n      \"id\": \"line_6\",\n      \"source-layer\": \"ne:roads\",\n      \"type\": \"line\",\n      \"filter\": [\"==\", \"scalerank\", 6],\n      \"minzoom\": 5,\n      \"paint\": {\n        \"line-color\": \"#444444\",\n        \"line-width\": 1\n      }\n    },\n    {\n      \"id\": \"line_5_1\",\n      \"source-layer\": \"ne:roads\",\n      \"type\": \"line\",\n      \"filter\": [\"==\", \"scalerank\", 5],\n      \"minzoom\": 4,\n      \"maxzoom\": 7\n      \"paint\": {\n        \"line-color\": \"#000055\",\n        \"line-width\": 1\n      }\n    },\n    {\n      \"id\": \"line_5_2\",\n      \"source-layer\": \"ne:roads\",\n      \"type\": \"line\",\n      \"filter\": [\"==\", \"scalerank\", 5],\n      \"minzoom\": 7,\n      \"paint\": {\n        \"line-color\": \"#000055\",\n        \"line-width\": 2\n      }\n    },\n    {\n      \"id\": \"line_5_1\",\n      \"source-layer\": \"ne:roads\",\n      \"type\": \"line\",\n      \"filter\": [\"<=\", \"scalerank\", 4],\n      \"maxzoom\": 5,\n      \"paint\": {\n        \"line-color\": \"black\",\n        \"line-width\": 1\n      }\n    },\n    {\n      \"id\": \"line_5_2\",\n      \"source-layer\": \"ne:roads\",\n      \"type\": \"line\",\n      \"filter\": [\"<=\", \"scalerank\", 4],\n      \"minzoom\": 5,\n      \"maxzoom\": 7\n      \"paint\": {\n        \"line-color\": \"black\",\n        \"line-width\": 2\n      }\n    },\n    {\n      \"id\": \"line_5_4\",\n      \"source-layer\": \"ne:roads\",\n      \"type\": \"line\",\n      \"filter\": [\"<=\", \"scalerank\", 4],\n      \"minzoom\": 7,\n      \"paint\": {\n        \"line-color\": \"black\",\n        \"line-width\": 4\n      }\n    }\n  ]\n}\n
                                        7. When a rule has both a filter and a scale, it will trigger when both are true.

                                        "},{"location":"styling/workshop/mbstyle/linestring/#bonus","title":"Bonus","text":"

                                        Finished early? Here are some opportunities to explore what we have learned, and extra challenges requiring creativity and research.

                                        In a classroom setting please divide the challenges between teams (this allows us to work through all the material in the time available).

                                        Instructor Notes

                                        As usual the Explore section invites readers to reapply the material covered in a slightly different context or dataset.

                                        The use of selectors using the roads type attribute provides this opportunity.

                                        "},{"location":"styling/workshop/mbstyle/linestring/#mbstyle.line.q1","title":"Challenge Classification","text":"
                                        1. The roads type attribute provides classification information.

                                          You can Layer Preview to inspect features to determine available values for type.

                                        2. Challenge: Create a new style adjust road appearance based on type.

                                          Note

                                          The available values are 'Major Highway','Secondary Highway','Road' and 'Unknown'.

                                          Note

                                          Answer provided <mbstyle.line.a1> at the end of the workbook.

                                        "},{"location":"styling/workshop/mbstyle/linestring/#mbstyle.line.q2","title":"Challenge One Rule Classification","text":"
                                        1. You can save a lot of typing by doing your classification in an expression using arithmetic or the Recode function

                                        2. Challenge: Create a new style and classify the roads based on their scale rank using expressions in a single rule instead of multiple rules with filters.

                                          Note

                                          Answer provided <mbstyle.line.a2> at the end of the workbook.

                                        "},{"location":"styling/workshop/mbstyle/linestring/#mbstyle.line.q3","title":"Challenge Label Shields","text":"
                                        1. The traditional presentation of roads in the US is the use of a shield symbol, with the road number marked on top.

                                        2. Challenge: Have a look at the documentation for putting a graphic on a text symbolizer in SLD and reproduce this technique in MBStyle.

                                          Note

                                          Answer provided <mbstyle.line.a3> at the end of the workbook.

                                        "},{"location":"styling/workshop/mbstyle/mbstyle/","title":"MBStyle Quickstart","text":"

                                        In the last section, we saw how the OGC defines style using XML documents (called SLD files).

                                        We will now explore GeoServer styling in greater detail using a tool to generate our SLD files. The MBStyle GeoServer extension is used to generate SLD files using the MabBox Style styling language. Styles written in this language can also be used to style vector tiles in client-side applications.

                                        Using the MBStyle extension to define styles results in shorter examples that are easier to understand. At any point we will be able to review the generated SLD file.

                                        Reference:

                                        • MBStyle Reference
                                        "},{"location":"styling/workshop/mbstyle/mbstyle/#mbstyle-syntax","title":"MBStyle Syntax","text":"

                                        This section provides a quick introduction to MBStyle syntax for mapping professionals who may not be familiar with JSON.

                                        "},{"location":"styling/workshop/mbstyle/mbstyle/#json-syntax","title":"JSON Syntax","text":"

                                        All MBStyles consist of a JSON document. There are three types of structures in a JSON document:

                                        1. Object, a collection of key-value pairs. All JSON documents are JSON objects.
                                        2. Array, a collection of values.
                                        3. Value, the value in a key-value pair, or an entry in an array. Values can be objects, arrays, strings, numbers, true, false, or null.
                                        Object A collection of key-value pairs, enclosed by curly braces and delimited by commas. Keys are surrounded by quotes and seperarted from values by a colon. Array A collection values, enclosed by square brackets and delimited by commas. String Text value. Must be surrounded by quotes. Number Numerical value. Must not be surrounded by quotes. Boolean true or false. Null null. Represents an undefined or unset value."},{"location":"styling/workshop/mbstyle/mbstyle/#mbstyle-specification","title":"MBStyle Specification","text":"

                                        The Mapbox Style specification defines a number of additional rules that MBStyles must follow.

                                        "},{"location":"styling/workshop/mbstyle/mbstyle/#root-level-properties","title":"Root-level Properties","text":"

                                        Root level properties of a Mapbox style specify the map's layers, tile sources and other resources, and default values for the initial camera position when not specified elsewhere.

                                        The following root-level properties are required for all MBStyles. Additional root-level properties which are supported but not required can be found in the spec.

                                        version The version of the Mapbox Style specification to use. Must be set to 8. name The name of the style. sources An object defining the source data. Not used by GeoServer. layers An array of layer style objects

                                        For example: :

                                        {\n    \"version\": 8,\n    \"name\": \"Streets\",\n    \"sources\": {...},\n    \"layers\": [...]\n}\n
                                        "},{"location":"styling/workshop/mbstyle/mbstyle/#sources","title":"Sources","text":"

                                        The sources parameter consists of a collection of named sources which define vector tile data the style is to be applied to. This is only used for MBStyles used in client-side applications, and is ignored by GeoServer. If you are only using MBStyles to style your layers within GeoServer, you don't need a sources parameter. However, if you also want to use your MBStyles for client-side styling, you will need the sources parameter.

                                        A GeoServer vector tile source would be defined like this:

                                        {\n  \"cookbook\": {\n    \"type\": \"vector\",\n    \"tiles\": [\n      \"http://localhost:8080/geoserver/gwc/service/wmts?REQUEST=GetTile&SERVICE=WMTS&VERSION=1.0.0&LAYER=cookbook&STYLE=&TILEMATRIX=EPSG:900913:{z}&TILEMATRIXSET=EPSG:900913&FORMAT=application/vnd.mapbox-vector-tile&TILECOL={x}&TILEROW={y}\"\n    ],\n    \"minZoom\": 0,\n    \"maxZoom\": 14\n  }\n}\n
                                        "},{"location":"styling/workshop/mbstyle/mbstyle/#layers","title":"Layers","text":"

                                        The layers parameter contains the primary layout and styling information in the MBStyle. Each layer in the layers list is a self-contained block of styling information. Layers are applied in order, so the last layer in the layers list will be rendered at the top of the image.

                                        Reference:

                                        • MBStyle Styling (User Guide)
                                        • Mapbox Style specification
                                        "},{"location":"styling/workshop/mbstyle/mbstyle/#compare-mbstyle-to-sld","title":"Compare MBStyle to SLD","text":"

                                        The MBStyle extension is built with the same GeoServer rendering engine in mind, providing access to most of the functionality of SLD. The two approaches use slightly different terminology: SLD uses terms familiar to mapping professionals, while MBStyle uses ideas more familiar to web developers.

                                        "},{"location":"styling/workshop/mbstyle/mbstyle/#sld-style","title":"SLD Style","text":"

                                        Here is an example SLD file for reference:

                                        <?xml version=\"1.0\" encoding=\"ISO-8859-1\"?>\n<StyledLayerDescriptor version=\"1.0.0\"\n xsi:schemaLocation=\"http://www.opengis.net/sld StyledLayerDescriptor.xsd\"\n xmlns=\"http://www.opengis.net/sld\"\n xmlns:ogc=\"http://www.opengis.net/ogc\"\n xmlns:xlink=\"http://www.w3.org/1999/xlink\"\n xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\">\n  <NamedLayer>\n    <Name>airports</Name>\n    <UserStyle>\n      <Title>Airports</Title>\n      <FeatureTypeStyle>\n        <Rule>\n          <Name>airports</Name>\n          <Title>Airports</Title>\n          <PointSymbolizer>\n            <Graphic>\n              <ExternalGraphic>\n                <OnlineResource xlink:type=\"simple\"\n                xlink:href=\"airport.svg\" />\n                <Format>image/svg</Format>\n              </ExternalGraphic>\n              <Size>16</Size>\n            </Graphic>\n          </PointSymbolizer>\n        </Rule>\n      </FeatureTypeStyle>\n    </UserStyle>\n  </NamedLayer>\n</StyledLayerDescriptor>\n
                                        "},{"location":"styling/workshop/mbstyle/mbstyle/#mbstyle-style","title":"MBStyle Style","text":"

                                        Here is the same example as MBStyle:

                                        {\n  \"version\": 8,\n  \"name\": \"airports\",\n  \"sprite\": \"http://localhost:8080/geoserver/styles/sprites\",\n  \"layers\": [\n      {\n          \"id\": \"airports\",\n          \"type\": \"symbol\",\n          \"layout\": {\n              \"icon-image\": \"airport\"\n          }\n      }\n  ]\n}\n

                                        We use a point symbolizer to indicate we want this content drawn as a Point (line 16 in the SLD, line 8 in the MBStyle). The point symbolizer declares an external graphic, which contains the URL airports.svg indicating the image that should be drawn (line 20 in the SLD, line 10 in the MBStyle).

                                        Note

                                        Rather than refer to many diffferent icons separately, MBStyles use a single sprite-sheet containing all the necessary icons for the style. This is defined by the sprite property at the top-level of the style.

                                        "},{"location":"styling/workshop/mbstyle/mbstyle/#tour","title":"Tour","text":"

                                        To confirm everything works, let's reproduce the airports style above.

                                        1. Navigate to the Styles page.

                                        2. Each time we edit a style, the contents of the associated SLD file are replaced. Rather than disrupt any of our existing styles we will create a new style. Click Add a new style and choose the following:

                                          Name: airports0

                                          Workspace: (leave empty)

                                          Format: MBStyle

                                        3. Replace the initial MBStyle definition with our airport MBStyle example and click Apply:

                                          {% \n  include \"../files/airports0.json\"\n%}\n
                                        4. Click the Layer Preview tab to preview the style. We want to preview on the airports layer, so click the name of the current layer and select ne:airports from the list that appears. You can use the mouse buttons to pan and scroll wheel to change scale.

                                          Choosing the airports layer

                                          Layer preview

                                        5. Click Layer Data for a summary of the selected data.

                                          Layer attributes

                                        "},{"location":"styling/workshop/mbstyle/mbstyle/#bonus","title":"Bonus","text":"

                                        Finished early? For now please help your neighbour so we can proceed with the workshop.

                                        If you are really stuck please consider the following challenge rather than skipping ahead.

                                        "},{"location":"styling/workshop/mbstyle/mbstyle/#explore-data","title":"Explore Data","text":"
                                        1. Return to the Data tab and use the Compute link to determine the minimum and maximum for the scalerank attribute.

                                          Instructor Notes

                                          Should be 2 and 9 respectively.

                                        "},{"location":"styling/workshop/mbstyle/mbstyle/#challenge-compare-sld-generation","title":"Challenge Compare SLD Generation","text":"
                                        1. The rest API can be used to review your YAML file directly.

                                        Browser:

                                        • Command line:

                                          curl -v -u admin:geoserver -XGET http://localhost:8080/geoserver/rest/styles/airports0.json\n
                                          1. The REST API can also be used generate an SLD file:

                                            Browser:

                                            • Command line:

                                              curl -v -u admin:geoserver -XGET http://localhost:8080/geoserver/rest/styles/airports0.sld?pretty=true\n
                                              1. Compare the generated SLD differ above with the handwritten SLD file used as an example?

                                                Challenge: What differences can you spot?

                                                Instructor Notes

                                                Generated SLD does not include name or title information; this can of course be added. Please check the MBStyle reference for details.

                                                The second difference is with the use of a fallback Mark when defining a PointSymbolizer.

                                              "},{"location":"styling/workshop/mbstyle/point/","title":"Points","text":"

                                              The next stop of the mbstyle styling tour is the representation of points.

                                              Review of point symbology:

                                              • Points are used to represent a location only, and do not form a shape. The visual width of lines do not change depending on scale.
                                              • SLD uses a PointSymbolizer record how the shape of a line is drawn.
                                              • Labeling of points is anchored to the point location.

                                              As points have no inherent shape of their own, emphasis is placed on marking locations with an appropriate symbol.

                                              Reference:

                                              • MBStyle Reference
                                              • MapBox Style Spec Symbol Layer
                                              • MapBox Style Spec Circle Layer
                                              • Point (User Manual | SLD Reference )

                                              This exercise makes use of the ne:populated_places layer.

                                              1. Navigate to the Styles page.

                                              2. Click Add a new style and choose the following:

                                                Name: point_example

                                                Workspace: No workspace

                                                Format: MBStyle

                                              3. Replace the initial MBStyle definition with the following and click apply:

                                                {\n  \"version\": 8,\n  \"name\": \"point_example\",\n  \"sprite\": \"http://localhost:8080/geoserver/styles/sprites\"\n  \"layers\": [\n    {\n      \"id\": \"point_example\",\n      \"type\": \"symbol\",\n      \"source-layer\": \"ne:populated_places\",\n      \"layout\": {\n        \"icon-image\": \"grey_circle\",\n      }\n    }\n  ]\n}\n
                                              4. And use the Layer Preview tab to preview the result.

                                              "},{"location":"styling/workshop/mbstyle/point/#sprite","title":"Sprite","text":"

                                              The symbol layer controls the display of point data. Points are typically represented with an icon-image.

                                              MBStyle uses a sprite-sheet defined at the top-level of the style to define a set of icons. You can view the names of all the icons in the sprite-sheet by looking at its json definition, at http://localhost:8080/geoserver/styles/sprites.json.

                                              1. Change the symbol used by the style to a square:

                                                {\n  \"version\": 8,\n  \"name\": \"point_example\",\n  \"sprite\": \"http://localhost:8080/geoserver/styles/sprites\"\n  \"layers\": [\n    {\n      \"id\": \"point_example\",\n      \"type\": \"symbol\",\n      \"source-layer\": \"ne:populated_places\",\n      \"layout\": {\n        \"icon-image\": \"grey_square16\",\n      }\n    }\n  ]\n}\n
                                              2. Map Preview:

                                              3. Before we continue we will use a selector to cut down the amount of data shown to a reasonable level.

                                                {\n  \"version\": 8,\n  \"name\": \"point_example\",\n  \"sprite\": \"http://localhost:8080/geoserver/styles/sprites\"\n  \"layers\": [\n    {\n      \"id\": \"point_example\",\n      \"type\": \"symbol\",\n      \"source-layer\": \"ne:populated_places\",\n      \"filter\": [\"<\", \"SCALERANK\", 1],\n      \"layout\": {\n        \"icon-image\": \"grey_square16\",\n      }\n    }\n  ]\n}\n
                                              4. Resulting in a considerably cleaner image:

                                              5. Additional properties are available to control an icon's presentation:

                                                The icon-size property is used to control symbol size.

                                                The icon-rotate property controls orientation, accepting input in degrees.

                                                Trying these two settings together:

                                                {\n  \"version\": 8,\n  \"name\": \"point_example\",\n  \"sprite\": \"http://localhost:8080/geoserver/styles/sprites\"\n  \"layers\": [\n    {\n      \"id\": \"point_example\",\n      \"type\": \"symbol\",\n      \"source-layer\": \"ne:populated_places\",\n      \"filter\": [\"<\", \"SCALERANK\", 1],\n      \"layout\": {\n        \"icon-image\": \"grey_square16\",\n        \"icon-size\": 0.75,\n        \"icon-rotate\": 45\n      }\n    }\n  ]\n}\n
                                              6. Results in each location being marked with a diamond:

                                              "},{"location":"styling/workshop/mbstyle/point/#circle","title":"Circle","text":"

                                              Another way of displaying point data is using the circle layer. Rather than rendering an icon from a preset sprite sheet, the circle layer lets us chose size and color for a simple circle.

                                              1. Modify the style to render a grey circle using the circle layer:

                                                {\n  \"version\": 8,\n  \"name\": \"point_example\",\n  \"layers\": [\n    {\n      \"id\": \"point_example\",\n      \"type\": \"circle\",\n      \"source-layer\": \"ne:populated_places\",\n      \"paint\": {\n        \"circle-color\": \"gray\",\n        \"circle-radius\": 8\n        \"circle-stroke-color\": \"black\",\n        \"circle-stroke-width\": 1\n      }\n    }\n  ]\n}\n
                                              2. And use the Layer Preview tab to preview the result.

                                              "},{"location":"styling/workshop/mbstyle/point/#label","title":"Label","text":"

                                              Labeling is now familiar from our experience with LineString and Polygons.

                                              The symbol layer with the label property are used to label Point Locations.

                                              1. Replace point_example with the following:

                                                {\n  \"version\": 8,\n  \"name\": \"point_example\",\n  \"layers\": [\n     {\n      \"id\": \"point_circle\",\n      \"type\": \"circle\",\n      \"source-layer\": \"ne:populated_places\",\n      \"paint\": {\n        \"circle-color\": \"gray\",\n        \"circle-radius\": 8\n        \"circle-stroke-color\": \"black\",\n        \"circle-stroke-width\": 1\n      }\n    },\n    {\n      \"id\": \"point_label\",\n      \"source-layer\": \"ne:populated_places\",\n      \"filter\": [\"<\", \"SCALERANK\", 1],\n      \"type\": \"symbol\",\n      \"layout\": {\n        \"text-field\": \"{NAME}\" \n      },\n      \"paint\": {\n        \"text-color\": \"gray\" \n      }\n    }\n  ]\n}\n
                                              2. Confirm the result in Map preview.

                                              3. Each label is drawn starting from the provided point - which is unfortunate as it assures each label will overlap with the symbol used. To fix this limitation we will make use of the MBStyle controls for label placement:

                                                text-anchor provides a value expressing how a label is aligned with respect to the starting label position.

                                                text-translate is used to provide an initial displacement using and x and y offset. For points this offset is recommended to adjust the label position away for the area used by the symbol.

                                                Note

                                                The property text-anchor defines an anchor position relative to the bounding box formed by the resulting label. This anchor position is snapped to the label position generated by the point location and displacement offset.

                                              4. Using these two facilities together we can center our labels below the symbol, taking care that the displacement used provides an offset just outside the area required for the symbol size.

                                                {\n  \"version\": 8,\n  \"name\": \"point_example\",\n  \"layers\": [\n    {\n      \"id\": \"point_circle\",\n      \"type\": \"circle\",\n      \"source-layer\": \"ne:populated_places\",\n      \"paint\": {\n        \"circle-color\": \"gray\",\n        \"circle-radius\": 8\n        \"circle-stroke-color\": \"black\",\n        \"circle-stroke-width\": 1\n      }\n    },\n    {\n      \"id\": \"point_label\",\n      \"source-layer\": \"ne:populated_places\",\n      \"filter\": [\"<\", \"SCALERANK\", 1],\n      \"type\": \"symbol\",\n      \"layout\": {\n        \"text-field\": \"{NAME}\",\n        \"text-anchor\": \"top\"\n      },\n      \"paint\": {\n        \"text-color\": \"black\",\n        \"text-translate\": [0, 12]\n      }\n    }\n  ]\n}\n
                                              5. Each label is now placed under the mark.

                                              6. One remaining issue is the overlap between labels and symbols.

                                                MBStyle provides various parameters to control label rendering and conflict resolution, preventing labels from overlapping any symbols.

                                                icon-allow-overlap and text-allow-overlap allows the rendering engine to draw the indicated symbol atop previous labels and icons.

                                                icon-ignore-placement and text-ignore-placement allows the rendering engine to draw labels and icons over top of the indicated symbol.

                                                icon-padding and text-padding tells the rendering engine to provide a minimum distance between the icons and text on the map, ensuring they do not overlap with other labels or icons.

                                                The -allow-overlap and -ignore-placement parameters are false by default, which is the behavior we want. Update our example to use text-padding:

                                                {\n  \"version\": 8,\n  \"name\": \"point_example\",\n  \"layers\": [\n    {\n      \"id\": \"point_circle\",\n      \"type\": \"circle\",\n      \"source-layer\": \"ne:populated_places\",\n      \"paint\": {\n        \"circle-color\": \"gray\",\n        \"circle-radius\": 8\n        \"circle-stroke-color\": \"black\",\n        \"circle-stroke-width\": 1\n      }\n    },\n    {\n      \"id\": \"point_label\",\n      \"source-layer\": \"ne:populated_places\",\n      \"filter\": [\"<\", \"SCALERANK\", 1],\n      \"type\": \"symbol\",\n      \"layout\": {\n        \"text-field\": \"{NAME}\",\n        \"text-anchor\": \"top\",\n        \"text-padding\": 2\n      },\n      \"paint\": {\n        \"text-color\": \"black\",\n        \"text-translate\": [0, 12]\n      }\n    }\n  ]\n}\n
                                              7. Resulting in a considerably cleaner image:

                                              "},{"location":"styling/workshop/mbstyle/point/#dynamic-styling","title":"Dynamic Styling","text":"
                                              1. We will quickly use minzoom and maxzoom to select content based on SCALERANK selectors.

                                                {\n  \"version\": 8,\n  \"name\": \"point_example\",\n  \"layers\": [\n    {\n      \"id\": \"point_7\",\n      \"type\": \"circle\",\n      \"source-layer\": \"ne:populated_places\",\n      \"filter\": [\"<\", \"SCALERANK\", 7],\n      \"minzoom\": 6,\n      \"maxzoom\": 7,\n      \"paint\": {\n        \"circle-color\": \"gray\",\n        \"circle-radius\": 8\n        \"circle-stroke-color\": \"black\",\n        \"circle-stroke-width\": 1\n      }\n    },\n    {\n      \"id\": \"point_5\",\n      \"type\": \"circle\",\n      \"source-layer\": \"ne:populated_places\",\n      \"filter\": [\"<\", \"SCALERANK\", 5],\n      \"minzoom\": 5,\n      \"maxzoom\": 6,\n      \"paint\": {\n        \"circle-color\": \"gray\",\n        \"circle-radius\": 8\n        \"circle-stroke-color\": \"black\",\n        \"circle-stroke-width\": 1\n      }\n    },\n    {\n      \"id\": \"point_4\",\n      \"type\": \"circle\",\n      \"source-layer\": \"ne:populated_places\",\n      \"filter\": [\"<\", \"SCALERANK\", 4],\n      \"minzoom\": 4,\n      \"maxzoom\": 5,\n      \"paint\": {\n        \"circle-color\": \"gray\",\n        \"circle-radius\": 8\n        \"circle-stroke-color\": \"black\",\n        \"circle-stroke-width\": 1\n      }\n    },\n    {\n      \"id\": \"point_3\",\n      \"type\": \"circle\",\n      \"source-layer\": \"ne:populated_places\",\n      \"filter\": [\"<\", \"SCALERANK\", 3],\n      \"minzoom\": 3,\n      \"maxzoom\": 4,\n      \"paint\": {\n        \"circle-color\": \"gray\",\n        \"circle-radius\": 8\n        \"circle-stroke-color\": \"black\",\n        \"circle-stroke-width\": 1\n      }\n    },\n    {\n      \"id\": \"point_2\",\n      \"type\": \"circle\",\n      \"source-layer\": \"ne:populated_places\",\n      \"filter\": [\"<\", \"SCALERANK\", 2],\n      \"minzoom\": 2,\n      \"maxzoom\": 3,\n      \"paint\": {\n        \"circle-color\": \"gray\",\n        \"circle-radius\": 8\n        \"circle-stroke-color\": \"black\",\n        \"circle-stroke-width\": 1\n      }\n    },\n    {\n      \"id\": \"point_1\",\n      \"type\": \"circle\",\n      \"source-layer\": \"ne:populated_places\",\n      \"filter\": [\"<\", \"SCALERANK\", 1],\n      \"maxzoom\": 2,\n      \"paint\": {\n        \"circle-color\": \"gray\",\n        \"circle-radius\": 8\n        \"circle-stroke-color\": \"black\",\n        \"circle-stroke-width\": 1\n      }\n    },\n    {\n      \"id\": \"point_0\",\n      \"type\": \"circle\",\n      \"source-layer\": \"ne:populated_places\",\n      \"minzoom\": 7,\n      \"paint\": {\n        \"circle-color\": \"gray\",\n        \"circle-radius\": 8\n        \"circle-stroke-color\": \"black\",\n        \"circle-stroke-width\": 1\n      }\n    }\n  ]\n}\n
                                              2. Click Submit to update the Map after each step.

                                              3. To add labeling we can add a symbol layer for each of the existing circle layers.

                                                {\n   \"version\": 8,\n   \"name\": \"point_example\",\n   \"layers\": [\n     {\n       \"id\": \"point_7\",\n       \"type\": \"circle\",\n       \"source-layer\": \"ne:populated_places\",\n       \"filter\": [\"<\", \"SCALERANK\", 7],\n       \"minzoom\": 6,\n       \"maxzoom\": 7,\n       \"paint\": {\n         \"circle-color\": \"gray\",\n         \"circle-radius\": 8\n         \"circle-stroke-color\": \"black\",\n         \"circle-stroke-width\": 1\n       }\n     },\n     {\n       \"id\": \"point_7_text\",\n       \"type\": \"symbol\",\n       \"source-layer\": \"ne:populated_places\",\n       \"filter\": [\"<\", \"SCALERANK\", 7],\n       \"minzoom\": 6,\n       \"maxzoom\": 7,\n       \"layout\": {\n         \"text-field\": \"{NAME}\",\n         \"text-font\": [\"Arial\"],\n         \"text-size\": 10\n       },\n       \"paint\": {\n         \"text-color\": \"black\"\n       }\n     },\n     {\n       \"id\": \"point_5\",\n       \"type\": \"circle\",\n       \"source-layer\": \"ne:populated_places\",\n       \"filter\": [\"<\", \"SCALERANK\", 5],\n       \"minzoom\": 5,\n       \"maxzoom\": 6,\n       \"paint\": {\n         \"circle-color\": \"gray\",\n         \"circle-radius\": 8\n         \"circle-stroke-color\": \"black\",\n         \"circle-stroke-width\": 1\n       }\n     },\n     {\n       \"id\": \"point_5_text\",\n       \"type\": \"symbol\",\n       \"source-layer\": \"ne:populated_places\",\n       \"filter\": [\"<\", \"SCALERANK\", 5],\n       \"minzoom\": 5,\n       \"maxzoom\": 6,\n       \"layout\": {\n         \"text-field\": \"{NAME}\",\n         \"text-font\": [\"Arial\"],\n         \"text-size\": 10\n       },\n       \"paint\": {\n         \"text-color\": \"black\"\n       }\n     },\n     {\n       \"id\": \"point_4\",\n       \"type\": \"circle\",\n       \"source-layer\": \"ne:populated_places\",\n       \"filter\": [\"<\", \"SCALERANK\", 4],\n       \"minzoom\": 4,\n       \"maxzoom\": 5,\n       \"paint\": {\n         \"circle-color\": \"gray\",\n         \"circle-radius\": 8\n         \"circle-stroke-color\": \"black\",\n         \"circle-stroke-width\": 1\n       }\n     },\n     {\n       \"id\": \"point_4_text\",\n       \"type\": \"symbol\",\n       \"source-layer\": \"ne:populated_places\",\n       \"filter\": [\"<\", \"SCALERANK\", 4],\n       \"minzoom\": 4,\n       \"maxzoom\": 5,\n       \"layout\": {\n         \"text-field\": \"{NAME}\",\n         \"text-font\": [\"Arial\"],\n         \"text-size\": 10\n       },\n       \"paint\": {\n         \"text-color\": \"black\"\n       }\n     },\n     {\n       \"id\": \"point_3\",\n       \"type\": \"circle\",\n       \"source-layer\": \"ne:populated_places\",\n       \"filter\": [\"<\", \"SCALERANK\", 3],\n       \"minzoom\": 3,\n       \"maxzoom\": 4,\n       \"paint\": {\n         \"circle-color\": \"gray\",\n         \"circle-radius\": 8\n         \"circle-stroke-color\": \"black\",\n         \"circle-stroke-width\": 1\n       }\n     },\n     {\n       \"id\": \"point_3_text\",\n       \"type\": \"symbol\",\n       \"source-layer\": \"ne:populated_places\",\n       \"filter\": [\"<\", \"SCALERANK\", 3],\n       \"minzoom\": 3,\n       \"maxzoom\": 4,\n       \"layout\": {\n         \"text-field\": \"{NAME}\",\n         \"text-font\": [\"Arial\"],\n         \"text-size\": 10\n       },\n       \"paint\": {\n         \"text-color\": \"black\"\n       }\n     },\n     {\n       \"id\": \"point_2\",\n       \"type\": \"circle\",\n       \"source-layer\": \"ne:populated_places\",\n       \"filter\": [\"<\", \"SCALERANK\", 2],\n       \"minzoom\": 2,\n       \"maxzoom\": 3,\n       \"paint\": {\n         \"circle-color\": \"gray\",\n         \"circle-radius\": 8\n         \"circle-stroke-color\": \"black\",\n         \"circle-stroke-width\": 1\n       }\n     },\n     {\n       \"id\": \"point_2_text\",\n       \"type\": \"symbol\",\n       \"source-layer\": \"ne:populated_places\",\n       \"filter\": [\"<\", \"SCALERANK\", 2],\n       \"minzoom\": 2,\n       \"maxzoom\": 3,\n       \"layout\": {\n         \"text-field\": \"{NAME}\",\n         \"text-font\": [\"Arial\"],\n         \"text-size\": 10\n       },\n       \"paint\": {\n         \"text-color\": \"black\"\n       }\n     },\n     {\n       \"id\": \"point_1\",\n       \"type\": \"circle\",\n       \"source-layer\": \"ne:populated_places\",\n       \"filter\": [\"<\", \"SCALERANK\", 1],\n       \"maxzoom\": 2,\n       \"paint\": {\n         \"circle-color\": \"gray\",\n         \"circle-radius\": 8\n         \"circle-stroke-color\": \"black\",\n         \"circle-stroke-width\": 1\n       }\n     },\n     {\n       \"id\": \"point_1_text\",\n       \"type\": \"symbol\",\n       \"source-layer\": \"ne:populated_places\",\n       \"filter\": [\"<\", \"SCALERANK\", 1],\n       \"maxzoom\": 2,\n       \"layout\": {\n         \"text-field\": \"{NAME}\",\n         \"text-font\": [\"Arial\"],\n         \"text-size\": 10\n       },\n       \"paint\": {\n         \"text-color\": \"black\"\n       }\n     },\n     {\n       \"id\": \"point_0\",\n       \"type\": \"circle\",\n       \"source-layer\": \"ne:populated_places\",\n       \"minzoom\": 7,\n       \"paint\": {\n         \"circle-color\": \"gray\",\n         \"circle-radius\": 8\n         \"circle-stroke-color\": \"black\",\n         \"circle-stroke-width\": 1\n       }\n     },\n     {\n       \"id\": \"point_0_text\",\n       \"type\": \"symbol\",\n       \"source-layer\": \"ne:populated_places\",\n       \"minzoom\": 7,\n       \"layout\": {\n         \"text-field\": \"{NAME}\",\n         \"text-font\": [\"Arial\"],\n         \"text-size\": 10\n       },\n       \"paint\": {\n         \"text-color\": \"black\"\n       }\n     }\n   ]\n }\n

                                              4. We will use text-offset to position the label above each symbol, and text-padding to give some extra space around our labels.

                                                Add the following line to each layer:

                                                {\n  \"id\": \"point_example\",\n  \"type\": \"symbol\",\n  \"source-layer\": \"ne:populated_places\",\n  \"minzoom\": 7,\n  \"layout\": {\n    \"text-field\": \"{NAME}\",\n    \"text-font\": [\"Arial\"],\n    \"text-size\": 10,\n    \"text-padding\": 2\n  },\n  \"paint\": {\n    \"text-color\": \"black\",\n    \"text-translate\": [0, -12]\n  }\n}\n

                                              5. Now that we have clearly labeled our cities, zoom into an area you are familiar with and we can look at changing symbology on a case-by-case basis.

                                                We have used expressions previous to generate an appropriate label. Expressions can also be used for many other property settings.

                                                The ne:populated_places layer provides several attributes specifically to make styling easier:

                                                • SCALERANK: we have already used this attribute to control the level of detail displayed
                                                • FEATURECLA: used to indicate different types of cities. We will check for Admin-0 capital cities.

                                                The first thing we will do is calculate the point size using a quick expression:

                                                {\n  \"property\": \"SCALERANK\",\n  \"type\": \"exponential\",\n  \"stops\": [\n    [0, 4.5],\n    [10, 2.5]\n  ]\n},\n

                                                This expression should result in sizes between 5 and 9 and will need to be applied to both point size and label displacement.

                                                {\n  \"id\": \"point_0\",\n  \"type\": \"circle\",\n  \"source-layer\": \"ne:populated_places\",\n  \"minzoom\": 7,\n  \"paint\": {\n    \"circle-color\": \"gray\",\n    \"circle-radius\": {\n      \"property\": \"SCALERANK\",\n      \"type\": \"exponential\",\n      \"stops\": [\n        [0, 4.5],\n        [10, 2.5]\n      ]\n    },\n    \"circle-stroke-color\": \"black\",\n    \"circle-stroke-width\": 1\n  }\n}\n
                                                {\n  \"id\": \"point_0_text\",\n  \"type\": \"symbol\",\n  \"source-layer\": \"ne:populated_places\",\n  \"minzoom\": 7,\n  \"layout\": {\n    \"text-field\": \"{NAME}\",\n    \"text-font\": [\"Arial\"],\n    \"text-size\": 10,\n    \"text-padding\": 2\n  },\n  \"paint\": {\n    \"text-color\": \"black\",\n    \"text-translate\": {\n      \"property\": \"SCALERANK\",\n      \"type\": \"exponential\",\n      \"stops\": [\n        [0, [0, -8]],\n        [10, [0, -6]]\n      ]\n    },\n  }\n}\n

                                              6. Next we can use FEATURECLA to check for capital cities.

                                                Adding a selector for capital cities at the top of the rules list:

                                                {\n  \"id\": \"point_capital\",\n  \"type\": \"symbol\",\n  \"source-layer\": \"ne:populated_places\",\n  \"filter\": [\"all\",[\"<\", \"SCALERANK\", 2], [\"==\", \"FEATURECLA\", \"Admin-0 capital\"]]\n  \"minzoom\": 2,\n  \"layout\": {\n    \"icon-image\": \"star\",\n    \"text-field\": \"{NAME}\",\n    \"text-font\": [\"Arial\"],\n    \"text-size\": 10,\n    \"text-padding\": 2\n  },\n  \"paint\": {\n    \"text-color\": \"black\",\n    \"text-translate\": [0, -12]\n  }\n}\n

                                                Also add the sprite-sheet url to the top of the style if it is not present:

                                                {\n  \"version\": 8,\n  \"name\": \"point_example\",\n  \"sprite\": \"http://localhost:8080/geoserver/styles/sprites\",\n}\n

                                                And updating the populated places selectors to ignore capital cities:

                                                {\n  \"id\": \"point_7\",\n  \"type\": \"circle\",\n  \"source-layer\": \"ne:populated_places\",\n  \"filter\": [\"all\", [\"<\", \"SCALERANK\", 7], [\"!=\", \"FEATURECLA\", \"Admin-0 capital\"]],\n  \"minzoom\": 6,\n  \"maxzoom\": 7,\n  \"paint\": {\n    \"circle-color\": \"gray\",\n    \"circle-radius\": {\n      \"property\": \"SCALERANK\",\n      \"type\": \"exponential\",\n      \"stops\": [\n        [0, 4.5],\n        [10, 2.5]\n      ]\n    },\n    \"circle-stroke-color\": \"black\",\n    \"circle-stroke-width\": 1\n  }\n}\n
                                                {\n  \"id\": \"point_7_text\",\n  \"type\": \"symbol\",\n  \"source-layer\": \"ne:populated_places\",\n  \"filter\": [\"all\", [\"<\", \"SCALERANK\", 7], [\"!=\", \"FEATURECLA\", \"Admin-0 capital\"]],\n  \"minzoom\": 6,\n  \"maxzoom\": 7,\n  \"layout\": {\n    \"text-field\": \"{NAME}\",\n    \"text-font\": [\"Arial\"],\n    \"text-size\": 10,\n    \"text-padding\": 2\n  },\n  \"paint\": {\n    \"text-color\": \"black\",\n    \"text-translate\": {\n      \"property\": \"SCALERANK\",\n      \"type\": \"exponential\",\n      \"stops\": [\n        [0, [0, -8]],\n        [10, [0, -6]]\n      ]\n    }\n  }\n}\n
                                                {\n  \"id\": \"point_5\",\n  \"type\": \"circle\",\n  \"source-layer\": \"ne:populated_places\",\n  \"filter\": [\"all\", [\"<\", \"SCALERANK\", 5], [\"!=\", \"FEATURECLA\", \"Admin-0 capital\"]],\n  \"minzoom\": 5,\n  \"maxzoom\": 6,\n  \"paint\": {\n    \"circle-color\": \"gray\",\n    \"circle-radius\": {\n      \"property\": \"SCALERANK\",\n      \"type\": \"exponential\",\n      \"stops\": [\n        [0, 4.5],\n        [10, 2.5]\n      ]\n    },\n    \"circle-stroke-color\": \"black\",\n    \"circle-stroke-width\": 1\n  }\n}\n
                                                {\n  \"id\": \"point_5_text\",\n  \"type\": \"symbol\",\n  \"source-layer\": \"ne:populated_places\",\n  \"filter\": [\"all\", [\"<\", \"SCALERANK\", 5], [\"!=\", \"FEATURECLA\", \"Admin-0 capital\"]],\n  \"minzoom\": 5,\n  \"maxzoom\": 6,\n  \"layout\": {\n    \"text-field\": \"{NAME}\",\n    \"text-font\": [\"Arial\"],\n    \"text-size\": 10,\n    \"text-padding\": 2\n  },\n  \"paint\": {\n    \"text-color\": \"black\",\n    \"text-translate\": {\n      \"property\": \"SCALERANK\",\n      \"type\": \"exponential\",\n      \"stops\": [\n        [0, [0, -8]],\n        [10, [0, -6]]\n      ]\n    }\n  }\n}\n
                                                {\n  \"id\": \"point_4\",\n  \"type\": \"circle\",\n  \"source-layer\": \"ne:populated_places\",\n  \"filter\": [\"all\", [\"<\", \"SCALERANK\", 4], [\"!=\", \"FEATURECLA\", \"Admin-0 capital\"]],\n  \"minzoom\": 4,\n  \"maxzoom\": 5,\n  \"paint\": {\n    \"circle-color\": \"gray\",\n    \"circle-radius\": {\n      \"property\": \"SCALERANK\",\n      \"type\": \"exponential\",\n      \"stops\": [\n        [0, 4.5],\n        [10, 2.5]\n      ]\n    },\n    \"circle-stroke-color\": \"black\",\n    \"circle-stroke-width\": 1\n  }\n}\n
                                                {\n  \"id\": \"point_4_text\",\n  \"type\": \"symbol\",\n  \"source-layer\": \"ne:populated_places\",\n  \"filter\": [\"all\", [\"<\", \"SCALERANK\", 4], [\"!=\", \"FEATURECLA\", \"Admin-0 capital\"]],\n  \"minzoom\": 4,\n  \"maxzoom\": 5,\n  \"layout\": {\n    \"text-field\": \"{NAME}\",\n    \"text-font\": [\"Arial\"],\n    \"text-size\": 10,\n    \"text-padding\": 2\n  },\n  \"paint\": {\n    \"text-color\": \"black\",\n    \"text-translate\": {\n      \"property\": \"SCALERANK\",\n      \"type\": \"exponential\",\n      \"stops\": [\n        [0, [0, -8]],\n        [10, [0, -6]]\n      ]\n    }\n  }\n}\n
                                                {\n  \"id\": \"point_3\",\n  \"type\": \"circle\",\n  \"source-layer\": \"ne:populated_places\",\n  \"filter\": [\"all\", [\"<\", \"SCALERANK\", 3], [\"!=\", \"FEATURECLA\", \"Admin-0 capital\"]],\n  \"minzoom\": 3,\n  \"maxzoom\": 4,\n  \"paint\": {\n    \"circle-color\": \"gray\",\n    \"circle-radius\": 8\n    \"circle-stroke-color\": \"black\",\n    \"circle-stroke-width\": 1\n  }\n}\n
                                                {\n  \"id\": \"point_3_text\",\n  \"type\": \"symbol\",\n  \"source-layer\": \"ne:populated_places\",\n  \"filter\": [\"all\", [\"<\", \"SCALERANK\", 3], [\"!=\", \"FEATURECLA\", \"Admin-0 capital\"]],\n  \"minzoom\": 3,\n  \"maxzoom\": 4,\n  \"layout\": {\n    \"text-field\": \"{NAME}\",\n    \"text-font\": [\"Arial\"],\n    \"text-size\": 10,\n    \"text-padding\": 2\n  },\n  \"paint\": {\n    \"text-color\": \"black\",\n    \"text-translate\": {\n      \"property\": \"SCALERANK\",\n      \"type\": \"exponential\",\n      \"stops\": [\n        [0, [0, -8]],\n        [10, [0, -6]]\n      ]\n    }\n  }\n}\n
                                                {\n  \"id\": \"point_2\",\n  \"type\": \"circle\",\n  \"source-layer\": \"ne:populated_places\",\n  \"filter\": [\"all\", [\"<\", \"SCALERANK\", 2], [\"!=\", \"FEATURECLA\", \"Admin-0 capital\"]],\n  \"minzoom\": 2,\n  \"maxzoom\": 3,\n  \"paint\": {\n    \"circle-color\": \"gray\",\n    \"circle-radius\": {\n      \"property\": \"SCALERANK\",\n      \"type\": \"exponential\",\n      \"stops\": [\n        [0, 4.5],\n        [10, 2.5]\n      ]\n    },\n    \"circle-stroke-color\": \"black\",\n    \"circle-stroke-width\": 1\n  }\n}\n
                                                {\n  \"id\": \"point_2_text\",\n  \"type\": \"symbol\",\n  \"source-layer\": \"ne:populated_places\",\n  \"filter\": [\"all\", [\"<\", \"SCALERANK\", 2], [\"!=\", \"FEATURECLA\", \"Admin-0 capital\"]],\n  \"minzoom\": 2,\n  \"maxzoom\": 3,\n  \"layout\": {\n    \"text-field\": \"{NAME}\",\n    \"text-font\": [\"Arial\"],\n    \"text-size\": 10,\n    \"text-padding\": 2\n  },\n  \"paint\": {\n    \"text-color\": \"black\",\n    \"text-translate\": {\n      \"property\": \"SCALERANK\",\n      \"type\": \"exponential\",\n      \"stops\": [\n        [0, [0, -8]],\n        [10, [0, -6]]\n      ]\n    }\n  }\n}\n
                                                {\n  \"id\": \"point_1\",\n  \"type\": \"circle\",\n  \"source-layer\": \"ne:populated_places\",\n  \"filter\": [\"<\", \"SCALERANK\", 1],\n  \"maxzoom\": 2,\n  \"paint\": {\n    \"circle-color\": \"gray\",\n    \"circle-radius\": {\n      \"property\": \"SCALERANK\",\n      \"type\": \"exponential\",\n      \"stops\": [\n        [0, 4.5],\n        [10, 2.5]\n      ]\n    },\n    \"circle-stroke-color\": \"black\",\n    \"circle-stroke-width\": 1\n  }\n}\n
                                                {\n  \"id\": \"point_1_text\",\n  \"type\": \"symbol\",\n  \"source-layer\": \"ne:populated_places\",\n  \"filter\": [\"<\", \"SCALERANK\", 1],\n  \"maxzoom\": 2,\n  \"layout\": {\n    \"text-field\": \"{NAME}\",\n    \"text-font\": [\"Arial\"],\n    \"text-size\": 10,\n    \"text-padding\": 2\n  },\n  \"paint\": {\n    \"text-color\": \"black\",\n    \"text-translate\": {\n      \"property\": \"SCALERANK\",\n      \"type\": \"exponential\",\n      \"stops\": [\n        [0, [0, -8]],\n        [10, [0, -6]]\n      ]\n    }\n  }\n}\n
                                                {\n  \"id\": \"point_0\",\n  \"type\": \"circle\",\n  \"source-layer\": \"ne:populated_places\",\n  \"filter\": [\"!=\", \"FEATURECLA\", \"Admin-0 capital\"],\n  \"minzoom\": 7,\n  \"paint\": {\n    \"circle-color\": \"gray\",\n    \"circle-radius\": {\n      \"property\": \"SCALERANK\",\n      \"type\": \"exponential\",\n      \"stops\": [\n        [0, 4.5],\n        [10, 2.5]\n      ]\n    },\n    \"circle-stroke-color\": \"black\",\n    \"circle-stroke-width\": 1\n  }\n}\n
                                                {\n  \"id\": \"point_0_text\",\n  \"type\": \"symbol\",\n  \"source-layer\": \"ne:populated_places\",\n  \"filter\": [\"!=\", \"FEATURECLA\", \"Admin-0 capital\"],\n  \"minzoom\": 7,\n  \"layout\": {\n    \"text-field\": \"{NAME}\",\n    \"text-font\": [\"Arial\"],\n    \"text-size\": 10,\n    \"text-padding\": 2\n  },\n  \"paint\": {\n    \"text-color\": \"black\",\n    \"text-translate\": {\n      \"property\": \"SCALERANK\",\n      \"type\": \"exponential\",\n      \"stops\": [\n        [0, [0, -8]],\n        [10, [0, -6]]\n      ]\n    }\n  }\n}\n

                                              7. If you would like to check your work the final file is here: point_example.mbstyle

                                              "},{"location":"styling/workshop/mbstyle/point/#bonus","title":"Bonus","text":"

                                              Instructor Notes

                                              The exercise section does not review the examples above, instead it explores the use of:

                                              • rules using min/max scale and rules using attribute filters
                                              • recode to map from attribute to symbol
                                              • interpolate to change size by population
                                              "},{"location":"styling/workshop/mbstyle/point/#mbstyle.point.q1","title":"Challenge Geometry Location","text":"

                                              Instructor Notes

                                              As usual Explore invites readers to reapply the material covered in a slightly different context or dataset.

                                              The use of filters using the roads type attribute provides this opportunity.

                                              1. The mark property can be used to render any geometry content.

                                              2. Challenge: Try this yourself by rendering a polygon layer using a mark property.

                                                Note

                                                Answer discussed <mbstyle.point.a1> at the end of the workbook.

                                              "},{"location":"styling/workshop/mbstyle/point/#mbstyle.point.q2","title":"Explore Dynamic Symbolization","text":"
                                              1. We went to a lot of work to set up selectors to choose between star and circle for capital cities.

                                                This approach is straightforward when applied in isolation:

                                                {\n  \"version\": 8,\n  \"name\": \"point_example\",\n  \"sprite\": \"http://localhost:8080/geoserver/styles/sprites\",\n  \"layers\": [\n    {\n      \"id\": \"point_capital\",\n      \"type\": \"symbol\",\n      \"source-layer\": \"ne:populated_places\",\n      \"filter\": [\"==\", \"FEATURECLA\", \"Admin-0 capital\"]\n      \"minzoom\": 2,\n      \"layout\": {\n        \"icon-image\": \"star\",\n      }\n    },\n    {\n      \"id\": \"point_0\",\n      \"type\": \"circle\",\n      \"source-layer\": \"ne:populated_places\",\n      \"filter\": [\"!=\", \"FEATURECLA\", \"Admin-0 capital\"],\n      \"minzoom\": 7,\n      \"paint\": {\n        \"circle-color\": \"gray\",\n        \"circle-radius\": 4,\n        \"circle-stroke-color\": \"black\",\n        \"circle-stroke-width\": 1\n      }\n    }\n  ]\n}\n

                                                When combined with checking another attribute, or checking @scale as in our example, this approach can quickly lead to many rules which can be difficult to keep straight.

                                              2. Taking a closer look, icon-image is expressed using a string:

                                                {\n  \"id\": \"point_capital\",\n  \"type\": \"symbol\",\n  \"source-layer\": \"ne:populated_places\",\n  \"filter\": [\"==\", \"FEATURECLA\", \"Admin-0 capital\"]\n  \"minzoom\": 2,\n  \"layout\": {\n    \"icon-image\": \"star\",\n  }\n}\n

                                                Which is represented in SLD as:

                                                <sld:PointSymbolizer uom=\"http://www.opengeospatial.org/se/units/pixel\">\n  <sld:Graphic>\n    <sld:ExternalGraphic>\n      <sld:OnlineResource xmlns:xlink=\"http://www.w3.org/1999/xlink\" xlink:type=\"simple\" xlink:href=\"http://localhost:8080/geoserver/styles/sprites#icon=${strURLEncode('star')}&size=${strURLEncode(1.0)}\"/>\n      <sld:Format>mbsprite</sld:Format>\n    </sld:ExternalGraphic>\n  </sld:Graphic>\n</sld:PointSymbolizer>\n
                                              3. MBStyle provides an opportunity for dynamic symbolization.

                                                This is accomplished by using a function for the value of the icon-image:

                                                {\n  \"version\": 8,\n  \"name\": \"point_example\",\n  \"sprite\": \"http://localhost:8080/geoserver/styles/sprites\",\n  \"layers\": [\n    {\n      \"id\": \"point_capital\",\n      \"type\": \"symbol\",\n      \"source-layer\": \"ne:populated_places\",\n      \"layout\": {\n        \"icon-image\": {\n          \"type\": \"categorical\",\n          \"property\": \"FEATURECLA\",\n          \"default\": \"grey_circle\",\n          \"stops\": [\n            [\"Admin-0 capital\", \"star\"]\n          ]\n        }\n      }\n    }\n  ]\n}\n

                                                Which is represented in SLD as:

                                                <sld:PointSymbolizer uom=\"http://www.opengeospatial.org/se/units/pixel\">\n  <sld:Graphic>\n    <sld:ExternalGraphic>\n      <sld:OnlineResource xmlns:xlink=\"http://www.w3.org/1999/xlink\" xlink:type=\"simple\" xlink:href=\"http://localhost:8080/geoserver/styles/sprites#icon=${strURLEncode(DefaultIfNull(Recode(FEATURECLA,'Admin-0 capital','star'),'grey_circle'))}&size=${strURLEncode(1.0)}\"/>\n      <sld:Format>mbsprite</sld:Format>\n    </sld:ExternalGraphic>\n  </sld:Graphic>\n</sld:PointSymbolizer>\n
                                              4. Challenge: Use this approach to rewrite the Dynamic Styling example.

                                                Note

                                                Answer provided <mbstyle.point.a2> at the end of the workbook.

                                              1. Challenge: Use the Interpolate function to smoothly change the mark size based on city population.
                                              "},{"location":"styling/workshop/mbstyle/polygon/","title":"Polygons","text":"

                                              Next we look at how MBStyle styling can be used to represent polygons.

                                              Polygon Geometry

                                              Review of polygon symbology:

                                              • Polygons offer a direct representation of physical extent or the output of analysis.

                                              • The visual appearance of polygons reflects the current scale.

                                              • Polygons are recorded as a LinearRing describing the polygon boundary. Further LinearRings can be used to describe any holes in the polygon if present.

                                                The Simple Feature for SQL Geometry model (used by GeoJSON) represents these areas as Polygons, the ISO 19107 geometry model (used by GML3) represents these areas as Surfaces.

                                              • SLD uses a PolygonSymbolizer to describe how the shape of a polygon is drawn. The primary characteristic documented is the Fill used to shade the polygon interior. The use of a Stroke to describe the polygon boundary is optional.

                                              • Labeling of a polygon is anchored to the centroid of the polygon. GeoServer provides a vendor-option to allow labels to line wrap to remain within the polygon boundaries.

                                              For our Polygon exercises we will try and limit our MBStyle documents to a single rule, in order to showcase the properties used for rendering.

                                              Reference:

                                              • MBStyle Reference
                                              • MapBox Style Spec Fill Layer
                                              • Polygons (User Manual | SLD Reference )

                                              This exercise makes use of the ne:states_provinces_shp layer.

                                              1. Navigate to Styles.

                                              2. Create a new style polygon_example.

                                                Name: polygon_example

                                                Workspace: No workspace

                                                Format: MBStyle

                                              3. Enter the following style and click ****Apply`` to save:

                                                {\n  \"version\": 8,\n  \"name\": \"polygon_example\",\n  \"layers\": [\n    {\n      \"id\": \"polygon_example\",\n      \"source-layer\": \"ne:states_provinces_shp\",\n      \"type\": \"fill\",\n      \"paint\": {\n        \"fill-color\": \"lightgrey\"\n      }\n    }\n  ]\n}\n
                                              4. Click on the tab Layer Preview to preview.

                                              5. Set ne:states_provinces_shp as the preview layer.

                                              "},{"location":"styling/workshop/mbstyle/polygon/#fill-and-outline","title":"Fill and Outline","text":"

                                              The fill layer controls the display of polygon data.

                                              The fill-color property is used to provide the color used to draw the interior of a polygon.

                                              1. Replace the contents of polygon_example with the following fill example:

                                                {\n  \"version\": 8,\n  \"name\": \"polygon_example\",\n  \"layers\": [\n    {\n      \"id\": \"polygon_example\",\n      \"source-layer\": \"ne:states_provinces_shp\",\n      \"type\": \"fill\",\n      \"paint\": {\n        \"fill-color\": \"gray\"\n      }\n    }\n  ]\n}\n
                                              2. The Map tab can be used preview the change:

                                              3. To draw the boundary of the polygon the fill-outline property is used:

                                                The fill-outline property is used to provide the color of the polygon boundary. For more advanced boundary styling, use a separate line layer.

                                                {\n  \"version\": 8,\n  \"name\": \"polygon_example\",\n  \"layers\": [\n    {\n      \"id\": \"polygon_example\",\n      \"source-layer\": \"ne:states_provinces_shp\",\n      \"type\": \"fill\",\n      \"paint\": {\n        \"fill-color\": \"gray\",\n        \"fill-outline-color\": \"black\"\n      }\n    }\n  ]\n}\n

                                                Note

                                                Technically the boundary of a polygon is a specific case of a LineString where the first and last vertex are the same, forming a closed LinearRing.

                                              4. The effect of adding fill-outline is shown in the map preview:

                                              5. An interesting technique when styling polygons in conjunction with background information is to control the fill opacity.

                                                The fill-opacity property is used to adjust transparency (provided as range from 0.0 to 1.0). Use of fill-opacity to render polygons works well in conjunction with a raster base map. This approach allows details of the base map to shown through. fill-opacity affects both the fill and the fill outline.

                                                The stroke-opacity property is used in a similar fashion, as a range from 0.0 to 1.0.

                                                {\n  \"version\": 8,\n  \"name\": \"polygon_example\",\n  \"layers\": [\n    {\n      \"id\": \"polygon_example\",\n      \"source-layer\": \"ne:states_provinces_shp\",\n      \"type\": \"fill\",\n      \"paint\": {\n        \"fill-opacity\": 0.5,\n        \"fill-color\": \"white\",\n        \"fill-outline-color\": \"lightgrey\"\n      }\n    }\n  ]\n}\n
                                              6. As shown in the map preview:

                                              7. This effect can be better appreciated using a layer group.

                                                Where the transparent polygons is used lighten the landscape provided by the base map.

                                              Instructor Notes

                                              In this example we want to ensure readers know the key property for polygon data.

                                              It is also our first example of using opacity.

                                              "},{"location":"styling/workshop/mbstyle/polygon/#pattern","title":"Pattern","text":"

                                              The fill-pattern property can be used to provide a pattern.

                                              The fill pattern is defined by repeating an image defined in a sprite-sheet.

                                              1. Update polygon_example with the following sprite as a repeating fill pattern:

                                                {\n  \"version\": 8,\n  \"name\": \"polygon_example\",\n  \"sprite\": \"http://localhost:8080/geoserver/styles/sprites\"\n  \"layers\": [\n    {\n      \"id\": \"polygon_example\",\n      \"source-layer\": \"ne:states_provinces_shp\",\n      \"type\": \"fill\",\n      \"paint\": {\n        \"fill-pattern\": \"grey_square16\" \n      }\n    }\n  ]\n}\n
                                              2. The map preview (and legend) will show the result:

                                              3. You can view the names of all the icons in the sprite-sheet by looking at its json definition, at http://localhost:8080/geoserver/styles/sprites.json.

                                                {\n    \"white_square16\": {\n        \"height\": 16,\n        \"pixelRatio\": 1,\n        \"width\": 16,\n        \"x\": 1,\n        \"y\": 1\n    },\n    \"grey_square8\": {\n        \"height\": 8,\n        \"pixelRatio\": 1,\n        \"width\": 8,\n        \"x\": 24,\n        \"y\": 18\n    },\n    \"grey_square16\": {\n        \"height\": 16,\n        \"pixelRatio\": 1,\n        \"width\": 16,\n        \"x\": 18,\n        \"y\": 1\n    },\n    \"grey_square22\": {\n        \"height\": 22,\n        \"pixelRatio\": 1,\n        \"width\": 22,\n        \"x\": 1,\n        \"y\": 18\n    },\n    \"green_square16\": {\n        \"height\": 16,\n        \"pixelRatio\": 1,\n        \"width\": 16,\n        \"x\": 35,\n        \"y\": 1\n    },\n    \"grey_x\": {\n        \"height\": 30,\n        \"pixelRatio\": 1,\n        \"width\": 30,\n        \"x\": 1,\n        \"y\": 41\n    },\n    \"grey_diag8\": {\n        \"height\": 8,\n        \"pixelRatio\": 1,\n        \"width\": 8,\n        \"x\": 24,\n        \"y\": 27\n    },\n    \"grey_diag16\": {\n        \"height\": 16,\n        \"pixelRatio\": 1,\n        \"width\": 16,\n        \"x\": 35,\n        \"y\": 18\n    },\n    \"grey_circle\": {\n        \"height\": 17,\n        \"pixelRatio\": 1,\n        \"width\": 17,\n        \"x\": 36,\n        \"y\": 36\n    },\n    \"airport\": {\n        \"height\": 16,\n        \"pixelRatio\": 1,\n        \"width\": 16,\n        \"x\": 52,\n        \"y\": 18\n    },\n    \"port\": {\n        \"height\": 16,\n        \"pixelRatio\": 1,\n        \"width\": 16,\n        \"x\": 52,\n        \"y\": 1\n    },\n    \"star\": {\n        \"height\": 16,\n        \"pixelRatio\": 1,\n        \"width\": 16,\n        \"x\": 69,\n        \"y\": 1\n    }\n}\n

                                                Update the example to use grey_diag16 for a pattern of left hatching.

                                                {\n  \"version\": 8,\n  \"name\": \"polygon_example\",\n  \"sprite\": \"http://localhost:8080/geoserver/styles/sprites\"\n  \"layers\": [\n    {\n      \"id\": \"polygon_example\",\n      \"source-layer\": \"ne:states_provinces_shp\",\n      \"type\": \"fill\",\n      \"paint\": {\n        \"fill-pattern\": \"grey_diag16\" \n      }\n    }\n  ]\n}\n
                                              4. This approach is well suited to printed output or low color devices.

                                              5. Multiple fills can be applied by using a separate layer for each fill.

                                                {\n  \"version\": 8,\n  \"name\": \"polygon_example\",\n  \"sprite\": \"http://localhost:8080/geoserver/styles/sprites\"\n  \"layers\": [\n    {\n      \"id\": \"polygon_background\",\n      \"source-layer\": \"ne:states_provinces_shp\",\n      \"type\": \"fill\",\n      \"paint\": {\n        \"fill-color\": \"#DDDDFF\",\n        \"fill-outline-color\": \"black\"\n      }\n    },\n    {\n      \"id\": \"polygon_pattern\",\n      \"source-layer\": \"ne:states_provinces_shp\",\n      \"type\": \"fill\",\n      \"paint\": {\n        \"fill-pattern\": \"grey_diag8\" \n      }\n    }\n  ]\n}\n
                                              6. The resulting image has a solid fill, with a pattern drawn overtop.

                                              "},{"location":"styling/workshop/mbstyle/polygon/#label","title":"Label","text":"

                                              Labeling polygons follows the same approach used for LineStrings.

                                              1. By default labels are drawn starting at the centroid of each polygon.

                                              2. Try out text-field and text-color by replacing our polygon_example with the following:

                                                {\n  \"version\": 8,\n  \"name\": \"polygon_example\",\n  \"layers\": [\n    {\n      \"id\": \"polygon_fill\",\n      \"source-layer\": \"ne:states_provinces_shp\",\n      \"type\": \"fill\",\n      \"paint\": {\n        \"fill-color\": \"#7EB5D3\",\n        \"fill-outline-color\": \"blue\"\n      }\n    },\n    {\n      \"id\": \"polygon_label\",\n      \"source-layer\": \"ne:states_provinces_shp\",\n      \"type\": \"symbol\",\n      \"layout\": {\n        \"text-field\": \"{name}\" \n      },\n      \"paint\": {\n        \"text-color\": \"black\" \n      }\n    }\n  ]\n}\n
                                              3. Each label is drawn from the lower-left corner as shown in the Map preview.

                                              4. We can adjust how the label is drawn at the polygon centroid.

                                                The property text-anchor provides two numbers expressing how a label is aligned with respect to the centroid. Adjusting the text-anchor is the recommended approach to positioning your labels.

                                              5. Using the text-anchor property we can center our labels with respect to geometry centroid.

                                                To align the center of our label we select \"center\" below:

                                                {\n  \"version\": 8,\n  \"name\": \"polygon_example\",\n  \"layers\": [\n    {\n      \"id\": \"polygon_fill\",\n      \"source-layer\": \"ne:states_provinces_shp\",\n      \"type\": \"fill\",\n      \"paint\": {\n        \"fill-color\": \"#7EB5D3\",\n        \"fill-outline-color\": \"blue\"\n      }\n    },\n    {\n      \"id\": \"polygon_label\",\n      \"source-layer\": \"ne:states_provinces_shp\",\n      \"type\": \"symbol\",\n      \"layout\": {\n        \"text-field\": \"{name}\",\n        \"text-anchor\": \"center\"\n      },\n      \"paint\": {\n        \"text-color\": \"black\" \n      }\n    }\n  ]\n}\n
                                              6. The labeling position remains at the polygon centroid. We adjust alignment by controlling which part of the label we are \"snapping\" into position.

                                              7. The property text-translate can be used to provide an initial displacement using and x and y offset.

                                              8. This offset is used to adjust the label position relative to the geometry centroid resulting in the starting label position.

                                                {\n  \"version\": 8,\n  \"name\": \"polygon_example\",\n  \"layers\": [\n    {\n      \"id\": \"polygon_fill\",\n      \"source-layer\": \"ne:states_provinces_shp\",\n      \"type\": \"fill\",\n      \"paint\": {\n        \"fill-color\": \"#7EB5D3\",\n        \"fill-outline-color\": \"blue\"\n      }\n    },\n    {\n      \"id\": \"polygon_label\",\n      \"source-layer\": \"ne:states_provinces_shp\",\n      \"type\": \"symbol\",\n      \"layout\": {\n        \"text-field\": \"{name}\",\n      },\n      \"paint\": {\n        \"text-color\": \"black\",\n        \"text-translate\": [0, -7]\n      }\n    }\n  ]\n}\n
                                              9. Confirm this result in the map preview.

                                              10. These two settings can be used together.

                                                The rendering engine starts by determining the label position generated from the geometry centroid and the text-translate displacement. The bounding box of the label is used with the text-anchor setting align the label to this location.

                                                Step 1: starting label position = centroid + displacement

                                                Step 2: snap the label anchor to the starting label position

                                              11. To move our labels down (allowing readers to focus on each shape) we can use displacement combined with followed by horizontal alignment.

                                                {\n  \"version\": 8,\n  \"name\": \"polygon_example\",\n  \"layers\": [\n    {\n      \"id\": \"polygon_fill\",\n      \"source-layer\": \"ne:states_provinces_shp\",\n      \"type\": \"fill\",\n      \"paint\": {\n        \"fill-color\": \"#7EB5D3\",\n        \"fill-outline-color\": \"blue\"\n      }\n    },\n    {\n      \"id\": \"polygon_label\",\n      \"source-layer\": \"ne:states_provinces_shp\",\n      \"type\": \"symbol\",\n      \"layout\": {\n        \"text-field\": \"{name}\",\n        \"text-anchor\": \"left\"\n      },\n      \"paint\": {\n        \"text-color\": \"black\",\n        \"text-translate\": [0, -7]\n      }\n    }\n  ]\n}\n
                                              12. As shown in the map preview.

                                              "},{"location":"styling/workshop/mbstyle/polygon/#legibility","title":"Legibility","text":"

                                              When working with labels a map can become busy very quickly, and difficult to read.

                                              1. MBStyle extensive properties for controlling the labelling process.

                                                One common property for controlling labeling is text-max-width, which allows any labels extending past the provided width will be wrapped into multiple lines.

                                              2. Using this we can make a small improvement in our example:

                                                {\n  \"version\": 8,\n  \"name\": \"polygon_example\",\n  \"layers\": [\n    {\n      \"id\": \"polygon_fill\",\n      \"source-layer\": \"ne:states_provinces_shp\",\n      \"type\": \"fill\",\n      \"paint\": {\n        \"fill-color\": \"#7EB5D3\",\n        \"fill-outline-color\": \"blue\"\n      }\n    },\n    {\n      \"id\": \"polygon_label\",\n      \"source-layer\": \"ne:states_provinces_shp\",\n      \"type\": \"symbol\",\n      \"layout\": {\n        \"text-field\": \"{name}\",\n        \"text-anchor\": \"center\"\n        \"text-max-width\": 14\n      },\n      \"paint\": {\n        \"text-color\": \"black\",\n      }\n    }\n  ]\n}\n
                                              3. As shown in the following preview.

                                              4. Even with this improved spacing between labels, it is difficult to read the result against the complicated line work.

                                                Use of a halo to outline labels allows the text to stand out from an otherwise busy background. In this case we will make use of the fill color, to provide some space around our labels. We will also change the font to Arial.

                                                {\n  \"version\": 8,\n  \"name\": \"polygon_example\",\n  \"layers\": [\n    {\n      \"id\": \"polygon_fill\",\n      \"source-layer\": \"ne:states_provinces_shp\",\n      \"type\": \"fill\",\n      \"paint\": {\n        \"fill-color\": \"#7EB5D3\",\n        \"fill-outline-color\": \"blue\"\n      }\n    },\n    {\n      \"id\": \"polygon_label\",\n      \"source-layer\": \"ne:states_provinces_shp\",\n      \"type\": \"symbol\",\n      \"layout\": {\n        \"text-field\": \"{name}\",\n        \"text-anchor\": \"center\"\n        \"text-max-width\": 14,\n        \"text-font\": [\"Arial\"]\n      },\n      \"paint\": {\n        \"text-color\": \"black\",\n        \"text-halo-color\": \"#7EB5D3\",\n        \"text-halo-width\": 2\n\n      }\n    }\n  ]\n}\n

                                              "},{"location":"styling/workshop/mbstyle/polygon/#theme","title":"Theme","text":"

                                              A thematic map (rather than focusing on representing the shape of the world) uses elements of style to illustrate differences in the data under study. This section is a little more advanced and we will take the time to look at the generated SLD file.

                                              Instructor Notes

                                              This instruction section follows our pattern with LineString. Building on the examples and exploring how selectors can be used.

                                              • For LineString we explored the use of @scale, in this section we are going to look at theming by attribute.
                                              • We also unpack how cascading occurs, and what the result looks like in the generated XML.
                                              • care is being taken to introduce the symbology encoding functions as an option for theming (placing equal importance on their use).

                                              Checklist:

                                              • filter vs function for theming
                                              • Cascading
                                              1. We can use a site like ColorBrewer to explore the use of color theming for polygon symbology. In this approach the fill color of the polygon is determined by the value of the attribute under study.

                                                This presentation of a dataset is known as \"theming\" by an attribute.

                                              2. For our ne:states_provinces_shp dataset, a mapcolor9 attribute has been provided for this purpose. Theming by mapcolor9 results in a map where neighbouring countries are visually distinct.

                                                +----------------------------+---------+---------+ | > Qualitative 9-class Set3 | | | +----------------------------+---------+---------+ | #8dd3c7 | #fb8072 | #b3de69 | +----------------------------+---------+---------+ | #ffffb3 | #80b1d3 | #fccde5 | +----------------------------+---------+---------+ | #bebada | #fdb462 | #d9d9d9 | +----------------------------+---------+---------+

                                                If you are unfamiliar with theming you may wish to visit http://colorbrewer2.org to learn more. The i icons provide an adequate background on theming approaches for qualitative, sequential and diverging datasets.

                                              3. The first approach we will take is to directly select content based on colormap, providing a color based on the 9-class Set3 palette above:

                                                {\n  \"version\": 8,\n  \"name\": \"polygon_example\",\n  \"layers\": [\n    {\n      \"id\": \"polygon_1\",\n      \"filter\": [\"==\", \"mapcolor9\", 1],\n      \"source-layer\": \"ne:states_provinces_shp\",\n      \"type\": \"fill\",\n      \"paint\": {\n        \"fill-color\": \"#8DD3C7\",\n        \"fill-outline-color\": \"gray\"\n      }\n    },\n    {\n      \"id\": \"polygon_2\",\n      \"filter\": [\"==\", \"mapcolor9\", 2],\n      \"source-layer\": \"ne:states_provinces_shp\",\n      \"type\": \"fill\",\n      \"paint\": {\n        \"fill-color\": \"#FFFFB3\",\n        \"fill-outline-color\": \"gray\"\n      }\n    },\n    {\n      \"id\": \"polygon_3\",\n      \"filter\": [\"==\", \"mapcolor9\", 3],\n      \"source-layer\": \"ne:states_provinces_shp\",\n      \"type\": \"fill\",\n      \"paint\": {\n        \"fill-color\": \"#BEBADA\",\n        \"fill-outline-color\": \"gray\"\n      }\n    },\n    {\n      \"id\": \"polygon_4\",\n      \"filter\": [\"==\", \"mapcolor9\", 4],\n      \"source-layer\": \"ne:states_provinces_shp\",\n      \"type\": \"fill\",\n      \"paint\": {\n        \"fill-color\": \"#FB8072\",\n        \"fill-outline-color\": \"gray\"\n      }\n    },\n    {\n      \"id\": \"polygon_5\",\n      \"filter\": [\"==\", \"mapcolor9\", 5],\n      \"source-layer\": \"ne:states_provinces_shp\",\n      \"type\": \"fill\",\n      \"paint\": {\n        \"fill-color\": \"#80B1D3\",\n        \"fill-outline-color\": \"gray\"\n      }\n    },\n    {\n      \"id\": \"polygon_6\",\n      \"filter\": [\"==\", \"mapcolor9\", 6],\n      \"source-layer\": \"ne:states_provinces_shp\",\n      \"type\": \"fill\",\n      \"paint\": {\n        \"fill-color\": \"#FDB462\",\n        \"fill-outline-color\": \"gray\"\n      }\n    },\n    {\n      \"id\": \"polygon_7\",\n      \"filter\": [\"==\", \"mapcolor9\", 7],\n      \"source-layer\": \"ne:states_provinces_shp\",\n      \"type\": \"fill\",\n      \"paint\": {\n        \"fill-color\": \"#B3DE69\",\n        \"fill-outline-color\": \"gray\"\n      }\n    },\n    {\n      \"id\": \"polygon_8\",\n      \"filter\": [\"==\", \"mapcolor9\", 8],\n      \"source-layer\": \"ne:states_provinces_shp\",\n      \"type\": \"fill\",\n      \"paint\": {\n        \"fill-color\": \"#FCCDE5\",\n        \"fill-outline-color\": \"gray\"\n      }\n    },\n    {\n      \"id\": \"polygon_9\",\n      \"filter\": [\"==\", \"mapcolor9\", 9],\n      \"source-layer\": \"ne:states_provinces_shp\",\n      \"type\": \"fill\",\n      \"paint\": {\n        \"fill-color\": \"#D9D9D9\",\n        \"fill-outline-color\": \"gray\"\n      }\n    }\n  ]\n}\n
                                              4. The Map tab can be used to preview this result.

                                              5. Property functions can be used to make theming substantially easier, by directly mapping property values to style values using an array of stops. MBStyle supports three types of function interpolation, which is used to define the behavior between these stops:

                                                • categorical: Used the theme qualitative data. Attribute values are directly mapped to styling property such as fill or stroke-width. Equivalent to the SLD Recode function.
                                                • interval: Used the theme quantitative data. Categories are defined using min and max ranges, and values are sorted into the appropriate category. Equivalent to the SLD Categorize function.
                                                • exponential: Used to smoothly theme quantitative data by calculating a styling property based on an attribute value. Supports a base attribute for controlling the steepness of interpolation. When base is 1, this is equivalent to the SLD Interpolate function.

                                                Theming is an activity, producing a visual result allow map readers to learn more about how an attribute is distributed spatially. We are free to produce this visual in the most efficient way possible.

                                              6. Swap out mapcolor9 theme to use the categorical function:

                                                {\n  \"version\": 8,\n  \"name\": \"polygon_example\",\n  \"layers\": [\n    {\n      \"id\": \"polygon\",\n      \"source-layer\": \"ne:states_provinces_shp\",\n      \"type\": \"fill\",\n      \"paint\": {\n        \"fill-color\": {\n          \"property\": \"mapcolor9\",\n          \"type\": \"categorical\",\n          \"stops\": [\n            [1, \"#8dd3c7\"],\n            [2, \"#ffffb3\"],\n            [3, \"#bebada\"],\n            [4, \"#fb8072\"],\n            [5, \"#80b1d3\"],\n            [6, \"#fdb462\"],\n            [7, \"#b3de69\"],\n            [8, \"#fccde5\"],\n            [9, \"#d9d9d9\"]\n          ]\n        },\n        \"fill-outline-color\": \"gray\"\n      }\n    }\n  ]\n}\n
                                              7. The Map tab provides the same preview.

                                              8. The Generated SLD tab shows where things get interesting. Our generated style now consists of a single Rule:

                                                <sld:Rule>\n   <sld:PolygonSymbolizer>\n      <sld:Fill>\n         <sld:CssParameter name=\"fill\">\n            <ogc:Function name=\"Recode\">\n               <ogc:PropertyName>mapcolor9</ogc:PropertyName>\n               <ogc:Literal>1</ogc:Literal>\n                  <ogc:Literal>#8dd3c7</ogc:Literal>\n               <ogc:Literal>2</ogc:Literal>\n                  <ogc:Literal>#ffffb3</ogc:Literal>\n               <ogc:Literal>3</ogc:Literal>\n                  <ogc:Literal>#bebada</ogc:Literal>\n               <ogc:Literal>4</ogc:Literal>\n                  <ogc:Literal>#fb8072</ogc:Literal>\n               <ogc:Literal>5</ogc:Literal>\n                  <ogc:Literal>#80b1d3</ogc:Literal>\n               <ogc:Literal>6</ogc:Literal>\n                  <ogc:Literal>#fdb462</ogc:Literal>\n               <ogc:Literal>7</ogc:Literal>\n                  <ogc:Literal>#b3de69</ogc:Literal>\n               <ogc:Literal>8</ogc:Literal>\n                  <ogc:Literal>#fccde5</ogc:Literal>\n               <ogc:Literal>9</ogc:Literal>\n                  <ogc:Literal>#d9d9d9</ogc:Literal>\n         </ogc:Function>\n         </sld:CssParameter>\n      </sld:Fill>\n   </sld:PolygonSymbolizer>\n   <sld:LineSymbolizer>\n      <sld:Stroke>\n         <sld:CssParameter name=\"stroke\">#808080</sld:CssParameter>\n         <sld:CssParameter name=\"stroke-width\">0.5</sld:CssParameter>\n      </sld:Stroke>\n   </sld:LineSymbolizer>\n</sld:Rule>\n
                                              "},{"location":"styling/workshop/mbstyle/polygon/#bonus","title":"Bonus","text":"

                                              The following optional explore and challenge activities offer a chance to review and apply the ideas introduced here. The challenge activities enquire a bit of creativity and research to complete.

                                              In a classroom setting you are encouraged to team up into groups, with each group taking on a different challenge.

                                              "},{"location":"styling/workshop/mbstyle/polygon/#mbstyle.polygon.q2","title":"Explore Interval","text":"

                                              Instructor Notes

                                              This section reviews use of the Symbology Encoding Categorize function for something else other than color. Goal is to have readers reach for SE Functions as often as selectors when styling.

                                              Additional exercise ideas:

                                              • Control size using Interpolate: While Recode offers an alternative for selectors (matching discrete values) Interpolate brings something new to the table - gradual color (or value) progression. The best of example of this is controlling width using the ne:rivers data layer (which is not yet available).
                                              1. The interval function can be used to generate property values based on quantitative information. Here is an example using interval to color states according to size.

                                                {\n \"version\": 8,\n \"name\": \"polygon_example\",\n \"layers\": [\n   {\n     \"id\": \"polygon\",\n     \"source-layer\": \"ne:states_provinces_shp\",\n     \"type\": \"fill\",\n     \"paint\": {\n       \"fill-color\": {\n         \"property\": \"Shape_Area\",\n         \"type\": \"interval\",\n         \"stops\": [\n           [0, \"#08519c\"],\n           [0.5, \"#3182bd\"],\n           [1, \"#6baed6\"],\n           [5, \"#9ecae1\"],\n           [60, \"#c6dbef\"],\n           [80, \"#eff3ff\"]\n         ]\n       }\n     }\n   }\n ]\n}\n

                                              2. An exciting use of the GeoServer shape symbols is the theming by changing the size used for pattern density.

                                              3. Explore: Use the interval function to theme by datarank.

                                                Note

                                                Answer provided <mbstyle.polygon.a2> at the end of the workbook.

                                              "},{"location":"styling/workshop/mbstyle/polygon/#mbstyle.polygon.q4","title":"Challenge Halo","text":"
                                              1. The halo example used the fill color and opacity for a muted halo, while this improved readability it did not bring attention to our labels.

                                                A common design choice for emphasis is to outline the text in a contrasting color.

                                              2. Challenge: Produce a map that uses a white halo around black text.

                                                Note

                                                Answer provided <mbstyle.polygon.a4> at the end of the workbook.

                                              "},{"location":"styling/workshop/mbstyle/polygon/#mbstyle.polygon.q5","title":"Challenge Theming using Multiple Attributes","text":"
                                              1. A powerful tool is theming using multiple attributes. This is an important concept allowing map readers to perform \"integration by eyeball\" (detecting correlations between attribute values information).

                                              2. Challenge: Combine the mapcolor9 and datarank examples to reproduce the following map.

                                                Note

                                                Answer provided <mbstyle.polygon.a5> at the end of the workbook.

                                              "},{"location":"styling/workshop/mbstyle/polygon/#mbstyle.polygon.q6","title":"Challenge Use of Z-Index","text":"
                                              1. Earlier we looked at using multiple layers to simulate line string casing. The line work was drawn twice, once with thick line, and then a second time with a thinner line. The resulting effect is similar to text halos - providing breathing space around complex line work allowing it to stand out.

                                              2. Challenge: Use what you know of rendering order to reproduce the following map:

                                                Note

                                                Answer provided <mbstyle.polygon.a6> at the end of the workbook.

                                              "},{"location":"styling/workshop/mbstyle/raster/","title":"Rasters","text":"

                                              Finally we will look at using MBStyle styling for the portrayal of raster data.

                                              Raster Symbology

                                              Review of raster symbology:

                                              • Raster data is Grid Coverage where values have been recorded in a regular array. In OGC terms a Coverage can be used to look up a value or measurement for each location.

                                              • When queried with a \"sample\" location:

                                                • A grid coverage can determine the appropriate array location and retrieve a value. Different techniques may be used interpolate an appropriate value from several measurements (higher quality) or directly return the \"nearest neighbor\" (faster).
                                                • A vector coverages would use a point-in-polygon check and return an appropriate attribute value.
                                                • A scientific model can calculate a value for each sample location
                                              • Many raster formats organize information into bands of content. Values recorded in these bands and may be mapped into colors for display (a process similar to theming an attribute for vector data).

                                                For imagery the raster data is already formed into red, green and blue bands for display.

                                              • As raster data has no inherent shape, the format is responsible for describing the orientation and location of the grid used to record measurements.

                                              These raster examples use a digital elevation model consisting of a single band of height measurements. The imagery examples use an RGB image that has been hand coloured for use as a base map.

                                              Since MBStyle is primarily intended for client-side styling, it doesn't have much ability to style raster data when compared with SLD, so this section will be much shorter than the equivalent raster sections for CSS and YSLD.

                                              Reference:

                                              • MBStyle Reference
                                              • MapBox Style Spec Raster Layer
                                              • Point (User Manual | SLD Reference )

                                              The exercise makes use of the usgs:dem and ne:ne1 layers.

                                              "},{"location":"styling/workshop/mbstyle/raster/#image","title":"Image","text":"

                                              The raster layer controls the display of raster data.

                                              1. Navigate to the Styles page.

                                              2. Click Add a new style and choose the following:

                                                Name: image_example

                                                Workspace: No workspace

                                                Format: MBStyle

                                              3. Replace the initial MBStyle definition with:

                                                {\n  \"name\": \"image_example\",\n  \"version\": 8,\n  \"layers\": [\n    {\n      \"id\": \"image_example\",\n      \"type\": \"raster\",\n      \"source-layer\": \"ne:ne1\",\n      \"paint\": {\n        \"raster-opacity\": 1\n      }\n    }\n  ]\n}\n
                                              4. And use the Layer Preview tab to preview the result.

                                              "},{"location":"styling/workshop/mbstyle/raster/#dem","title":"DEM","text":"

                                              A digital elevation model is an example of raster data made up of measurements, rather than color information.

                                              The usgs:dem layer used for this exercise:

                                              1. Return to the Styles page.

                                              2. Click Add a new style and choose the following:

                                                Name: raster_example

                                                Workspace: No workspace

                                                Format: MBStyle

                                              3. The rendering engine will select our single band of raster content, and do its best to map these values into a grayscale image. Replace the content of the style with:

                                                {\n  \"name\": \"raster_example\",\n  \"version\": 8,\n  \"layers\": [\n    {\n      \"id\": \"raster_example\",\n      \"type\": \"raster\",\n      \"source-layer\": \"usgs:dem\",\n      \"paint\": {\n        \"raster-opacity\": 1\n      }\n    }\n  ]\n}\n
                                              4. Use the Layer Preview tab to preview the result. The range produced in this case from the highest and lowest values.

                                              "},{"location":"styling/workshop/mbstyle/raster/#bonus","title":"Bonus","text":""},{"location":"styling/workshop/mbstyle/raster/#mbstyle.raster.q4","title":"Challenge Raster Opacity","text":"
                                              1. There is a quick way to make raster data transparent, raster opacity property works in the same fashion as with vector data. The raster as a whole will be drawn partially transparent allow content from other layers to provide context.

                                              2. Challenge: Can you think of an example where this would be useful?

                                                Note

                                                Discussion provided <mbstyle.raster.a4> at the end of the workbook.

                                              "},{"location":"styling/workshop/setup/","title":"Workshop Setup","text":"

                                              Content:

                                              • Extension Install
                                              • Course Data
                                              "},{"location":"styling/workshop/setup/data/","title":"Course Data","text":""},{"location":"styling/workshop/setup/data/#natural-earth","title":"Natural Earth","text":"

                                              The Natural Earth dataset is a free collection of vector and raster data published by the North American Cartographic Information Society to encourage mapping.

                                              For this course we will be using the Natural Earth cultural and physical vector layers backed by a raster shaded relief dataset.

                                              Natural Earth

                                              The quickstart Natural Earth styling has been exported from QGIS and cleaned up in uDig for use in GeoServer.

                                              "},{"location":"styling/workshop/setup/data/#digital-elevation-model","title":"Digital Elevation Model","text":"

                                              A digital elevation model records height information for visualisation and analysis. We are using a dataset derived from the USGS GTOPO30 dataset.

                                              Digital Elevation Model

                                              The GeoServer \"dem\" styling has been used for this dataset.

                                              "},{"location":"styling/workshop/setup/data/#configuration","title":"Configuration","text":"

                                              Note

                                              In a classroom setting GeoServer has been preconfigured with the appropriate data directory.

                                              To set up GeoServer yourself:

                                              1. Download and unzip the following into your data directory:

                                                • styling-workshop-vector.zip
                                                • styling-workshop-raster.zip

                                                This will produce a raster and vector folder referenced in the following steps.

                                                Optional default SLD styles:

                                                • styling-workshop-sld.zip
                                              2. Use the Importer to add and publish -

                                                the following TIF Coverage Stores:

                                                • dem/W100N40.TIF
                                                • ne/ne1/NE1_HR_LC_SR.tif

                                                the following directories of shape files:

                                                • ne/ne1/physical
                                                • ne/ne1/cultural

                                              3. Cleaning up the published vector layers:

                                                • Layer names have been shortened for publication - the ne_10m_admin_1_states_provinces_lines_ship.shp is published named states_provinces_shp
                                                • Use EPSG:4326 as the spatial reference system
                                                • Optional: Appropriate SLD styles have been provided (from the uDig project)

                                              4. To clean up the published raster layers:

                                                • The NE1 GeoTiff is styled with the default raster style
                                                • The usgs:dem GeoTiff is styled with the default DEM style

                                              5. Optional: create a basemap group layer consisting of:

                                                This offers a combined layer, forming a cohesive base map.

                                              "},{"location":"styling/workshop/setup/install/","title":"Extension Install","text":"

                                              This workshop course requires GeoServer with a few additional extensions.

                                              • CSS Styling: Quickly and easily generate SLD files
                                              • YSLD Styling: An alternative styling language to SLD
                                              • Importer: Wizard for bulk import of data

                                              On Windows the following is recommended:

                                              • FireFox
                                              • Notepad++

                                              The CSS extension is distributed as a supported GeoServer extension. Extensions are unpacked into the libs folder of the GeoServer application. The YSLD extension is a new addition to geoserver and is distributed as an unsupported GeoServer extension.

                                              Note

                                              In a classroom setting these extensions have already been installed.

                                              "},{"location":"styling/workshop/setup/install/#manual-install","title":"Manual Install","text":"

                                              To download and install the required extensions by hand:

                                                • From the download page download:
                                                • css
                                                • ysld

                                                It is important to download the version that matches the GeoServer you are running.

                                              1. Stop the GeoServer application.

                                              2. Navigate into the webapps/geoserver/WEB-INF/lib folder.

                                                These files make up the running GeoServer application.

                                              3. Unzip the contents of the three zip files into the lib folder.

                                              4. Restart the Application Server.

                                              5. Login to the Web Administration application. Select Styles from the naviagion menu. Click Create a new style and ensure both CSS and YSLD are available in the formats dropdown. Click Cancel to return to the Styles page without saving.

                                              "},{"location":"styling/workshop/ysld/","title":"YSLD Styling Workbook","text":"

                                              GeoServer styling can be used for a range of creative effects. This section introduces the YSLD Extension which can be used as alternative to SLD files.

                                              • YSLD Quickstart
                                              • Lines
                                              • Polygons
                                              • Points
                                              • Rasters
                                              • YSLD Workbook Conclusion
                                              "},{"location":"styling/workshop/ysld/done/","title":"YSLD Workbook Conclusion","text":"

                                              We hope you have enjoyed this styling workshop.

                                              Additional resources:

                                              • YSLD Extension
                                              • YSLD Reference
                                              "},{"location":"styling/workshop/ysld/done/#ysld-tips-and-tricks","title":"YSLD Tips and Tricks","text":""},{"location":"styling/workshop/ysld/done/#converting-to-ysld","title":"Converting to YSLD","text":"

                                              The REST API can be used to convert any of your existing CSS or SLD styles to YSLD.

                                              1. Navigate to the rest api endpoint for styles:

                                                • Note

                                                  Using view-source: in chrome or firefox allows us to focus on page content.

                                                • Click on one of the styles (for example states.html)

                                                • Click on the link to the style contents

                                                  • Change the URL with ?pretty=true for human readable XML.

                                                    • Change the URL with yaml to convert to YSLD.

                                                      • The original SLD file is convert to YSLD:

                                                        name: states\ntitle: Population in the United States\nabstract: |-\n  A sample filter that filters the United States into three\n          categories of population, drawn in different colors\nfeature-styles:\n- name: name\n  rules:\n  - name: Population < 2M\n    title: Population < 2M\n    filter: ${PERSONS < '2000000'}\n    scale: [min, max]\n    symbolizers:\n    - polygon:\n        fill-color: '#A6CEE3'\n        fill-opacity: 0.7\n  - name: Population 2M-4M\n    title: Population 2M-4M\n    filter: ${PERSONS BETWEEN '2000000' AND '4000000'}\n    scale: [min, max]\n    symbolizers:\n    - polygon:\n        fill-color: F78B4\n        fill-opacity: 0.7\n  - name: '> 4M'\n    title: Population > 4M\n    filter: ${PERSONS > '4000000'}\n    scale: [min, max]\n    symbolizers:\n    - polygon:\n        fill-color: '#B2DF8A'\n        fill-opacity: 0.7\n  - name: State Outlines\n    title: State Outlines\n    scale: [min, max]\n    symbolizers:\n    - line:\n        stroke-color: '#8CADBF'\n        stroke-width: 0.1\n  - name: State Abbreviations\n    title: State Abbreviations\n    scale: ['1.75E7', '3.5E7']\n    symbolizers:\n    - text:\n        label: ${STATE_ABBR}\n        font-family: SansSerif\n        font-size: 12\n        font-style: Normal\n        font-weight: normal\n        placement: point\n        anchor: [0.5, 0.5]\n  - name: State Names\n    title: State Names\n    scale: [min, '1.75E7']\n    symbolizers:\n    - text:\n        label: ${STATE_NAME}\n        font-family: SansSerif\n        font-size: 12\n        font-style: Normal\n        font-weight: normal\n        placement: point\n        anchor: [0.5, 0.5]\n        x-maxDisplacement: 100\n        x-goodnessOfFit: 0.9\n
                                                        "},{"location":"styling/workshop/ysld/done/#ysld-workshop-answer-key","title":"YSLD Workshop Answer Key","text":"

                                                        The following questions were listed throughout the workshop as an opportunity to explore the material in greater depth. Please do your best to consider the questions in detail prior to checking here for the answer. Questions are provided to teach valuable skills, such as a chance to understand how feature type styles are used to control z-order, or where to locate information in the user manual.

                                                        "},{"location":"styling/workshop/ysld/done/#ysld.line.a1","title":"Classification","text":"

                                                        Answer for Challenge Classification <ysld.line.q1>:

                                                        1. Challenge: Create a new style adjust road appearance based on type.

                                                          Hint: The available values are 'Major Highway','Secondary Highway','Road' and 'Unknown'.

                                                        2. Here is an example:

                                                          define: &common\n  stroke-opacity: 0.25\n\nrules:\n- filter: ${type = 'Major Highway'}\n  symbolizers:\n  - line:\n      stroke-color: '#000088'\n      stroke-width: 1.25\n      <<: *common\n- filter: ${type = 'Secondary Highway'}\n  symbolizers:\n  - line:\n      stroke-color: '#8888AA'\n      stroke-width: 0.75\n      <<: *common\n- filter: ${type = 'Road'}\n  symbolizers:\n  - line:\n      stroke-color: '#888888'\n      stroke-width: 0.75\n      <<: *common\n- filter: ${type = 'Unknown'}\n  symbolizers:\n  - line:\n      stroke-color: '#888888'\n      stroke-width: 0.5\n      <<: *common\n- else: true\n  symbolizers:\n  - line:\n      stroke-color: '#AAAAAA'\n      stroke-width: 0.5\n      <<: *common\n
                                                        "},{"location":"styling/workshop/ysld/done/#ysld.line.a2","title":"One Rule Classification","text":"

                                                        Answer for Challenge One Rule Classification <ysld.line.q2>:

                                                        1. Challenge: Create a new style and classify the roads based on their scale rank using expressions in a single rule instead of multiple rules with filters.
                                                        2. This exercise requires looking up information in the user guide, the search term recode provides several examples.
                                                          • The YSLD Reference theming functions provides a clear example.
                                                        "},{"location":"styling/workshop/ysld/done/#ysld.line.a3","title":"Label Shields","text":"

                                                        Answer for Challenge Label Shields <ysld.line.q3>:

                                                        1. Challenge: Have a look at the documentation for putting a graphic on a text symbolizer in SLD and reproduce this technique in YSLD.

                                                        2. The use of a label shield is a vendor specific capability of the GeoServer rendering engine. The tricky part of this exercise is finding the documentation online ( i.e. TextSymbolizer - Graphic).

                                                          symbolizers:\n- line:\n    stroke-color: '#000000'\n    stroke-width: 3\n- line:\n    stroke-color: '#D3D3D3'\n    stroke-width: 2\n- text:\n    label: ${name}\n    fill-color: '#000000'\n    font-family: Ariel\n    font-size: 10\n    font-style: normal\n    font-weight: normal\n    placement: point\n    graphic:\n      size: 18\n      symbols:\n      - mark:\n          shape: square\n          stroke-color: '#000000'\n          stroke-width: 1\n          fill-color: '#FFFFFF'\n
                                                        "},{"location":"styling/workshop/ysld/done/#ysld.polygon.a1","title":"Antialiasing","text":"

                                                        Answer for Explore Antialiasing <ysld.polygon.q1>:

                                                        1. When we rendered our initial preview, without a stroke, thin white gaps (or slivers) are visible between our polygons.

                                                          This effect is made more pronounced by the rendering engine making use of the Java 2D sub-pixel accuracy. This technique is primarily used to prevent an aliased (stair-stepped) appearance on diagonal lines.

                                                        2. Explore: Experiment with fill and stroke settings to eliminate slivers between polygons.

                                                          The obvious approach works - setting both values to the same color:

                                                          symbolizers:\n- polygon:\n    stroke-color: 'lightgrey'\n    stroke-width: 1\n    fill-color: 'lightgrey'\n
                                                        "},{"location":"styling/workshop/ysld/done/#ysld.polygon.a2","title":"Categorize","text":"

                                                        Answer for Explore Categorize <ysld.polygon.q2>:

                                                        1. An exciting use of the GeoServer shape symbols is the theming by changing the size used for pattern density.

                                                        2. Explore: Use the Categorize function to theme by datarank.

                                                          Example:

                                                          symbolizers:\n- polygon:\n    stroke-color: 'black'\n    stroke-width: 1\n    fill-color: 'gray'\n    fill-graphic:\n      size: ${Categorize(datarank,'4','4','5','6','8','10','10')}\n      symbols:\n      - mark:\n          shape: shape://slash\n          stroke-color: 'darkgray'\n          stroke-width: 1\n
                                                        "},{"location":"styling/workshop/ysld/done/#ysld.polygon.a4","title":"Halo","text":"

                                                        Answer for Challenge Halo <ysld.polygon.q4>:

                                                        1. The halo example used the fill color and opacity for a muted halo, while this improved readability it did not bring attention to our labels.

                                                          A common design choice for emphasis is to outline the text in a contrasting color.

                                                        2. Challenge: Produce a map that uses a white halo around black text.

                                                          Here is an example:

                                                          symbolizers:\n- polygon:\n    stroke-color: 'gray'\n    stroke-width: 1\n    fill-color: '#7EB5D3'\n- text:\n    label: ${name}\n    fill-color: 'black'\n    halo:\n      fill-color: 'white'\n      radius: 1\n    font-family: Arial\n    font-size: 14\n    font-style: normal\n    font-weight: normal\n    anchor: [0.5, 0.5]\n
                                                        "},{"location":"styling/workshop/ysld/done/#ysld.polygon.a5","title":"Theming using Multiple Attributes","text":"

                                                        Answer for Challenge Theming using Multiple Attributes <ysld.polygon.q5>:

                                                        1. A powerful tool is theming using multiple attributes. This is an important concept allowing map readers to perform \"integration by eyeball\" (detecting correlations between attribute values information).

                                                        2. Challenge: Combine the mapcolor9 and datarank examples to reproduce the following map.

                                                          This should be a cut and paste using the recode example, and categorize examples already provided.

                                                          symbolizers:\n- polygon:\n    stroke-color: 'black'\n    stroke-width: 1\n    fill-color: ${Recode(mapcolor9,\n      '1','#8dd3c7',\n      '2','#ffffb3',\n      '3','#bebada',\n      '4','#fb8072',\n      '5','#80b1d3',\n      '6','#fdb462',\n      '7','#b3de69',\n      '8','#fccde5',\n      '9','#d9d9d9')}\n- polygon:\n    stroke-color: 'black'\n    stroke-width: 1\n    fill-color: 'gray'\n    fill-graphic:\n      size: ${Categorize(datarank,'6','4','8','6','10','10','12')}\n      symbols:\n      - mark:\n          shape: shape://slash\n          stroke-color: 'black'\n          stroke-width: 1\n          fill-color: 'gray'\n
                                                        "},{"location":"styling/workshop/ysld/done/#ysld.polygon.a6","title":"Use of Feature styles","text":"

                                                        Answer for Challenge Use of Feature styles <ysld.polygon.q6>:

                                                        1. Using multiple feature-styles to simulate line string casing. The resulting effect is similar to text halos - providing breathing space around complex line work allowing it to stand out.

                                                        2. Challenge: Use what you know of LineString feature-styles to reproduce the following map:

                                                          This is much easier when using YSLD, where z-order is controlled by feature-style order. In this instance, multiple symbolizers within a feature-style will not work, as the order within a feature-style is only consistent per-feature (not per-layer).

                                                          feature-styles:\n- rules:\n  - symbolizers:\n    - polygon:\n        stroke-width: 1.0\n        fill-color: 'lightgrey'\n- rules:\n  - symbolizers:\n    - polygon:\n        stroke-width: 1.0\n        fill-color: 'gray'\n        fill-graphic:\n          size: 8\n          symbols:\n          - mark:\n              shape: shape://slash\n              stroke-color: 'black'\n              stroke-width: 0.75\n- rules:\n  - symbolizers:\n    - line:\n        stroke-color: 'lightgrey'\n        stroke-width: 6\n- rules:\n  - symbolizers:\n    - line:\n        stroke-color: 'black'\n        stroke-width: 1.5\n

                                                          The structure of the legend graphic provides an indication on what is going on.

                                                        "},{"location":"styling/workshop/ysld/done/#ysld.point.a1","title":"Geometry Location","text":"

                                                        Answer for Challenge Geometry Location <ysld.point.q1>:

                                                        1. The mark property can be used to render any geometry content.

                                                        2. Challenge: Try this yourself by rendering a polygon layer using a mark property.

                                                          This can be done one of two ways:

                                                          • Changing the association of a polygon layer, such as ne:states_provinces_shp to point_example and using the layer preview page.
                                                          • Changing the Layer Preview tab to a polygon layer, such as ne:states_provinces_shp.

                                                          The important thing to notice is that the centroid of each polygon is used as a point location.

                                                        "},{"location":"styling/workshop/ysld/done/#ysld.point.a2","title":"Dynamic Symbolization","text":"

                                                        Answer for Explore Dynamic Symbolization <ysld.point.q2>:

                                                        1. SLD Mark and ExternalGraphic provide an opportunity for dynamic symbolization.

                                                          This is accomplished by embedding a small CQL expression in the string passed to symbol or url. This sub-expression is isolated with \\${ } as shown:

                                                          - point:\n    symbols:\n    - mark:\n        shape: ${if_then_else(equalTo(FEATURECLA,'Admin-0 capital'),'star','circle')}\n
                                                        2. Challenge: Use this approach to rewrite the Dynamic Styling example.

                                                          Example available here point_example.css :

                                                          define: &point

                                                          size: \\${10-(SCALERANK/2)} symbols:

                                                          • mark:
                                                          shape: \\${if_then_else(equalTo(FEATURECLA,'Admin-0 capital'),'star','circle')} stroke-color: 'black' stroke-width: 1 fill-color: 'gray'

                                                          x-labelObstacle: true

                                                        "},{"location":"styling/workshop/ysld/done/#ysld.point.a3","title":"Layer Group","text":"

                                                        Answer for Challenge Layer Group <ysld.point.q3>:

                                                        1. Use a Layer Group to explore how symbology works together to form a map.

                                                          • ne:NE1
                                                          • ne:states_provincces_shp
                                                          • ne:populated_places
                                                        2. This background is relatively busy and care must be taken to ensure both symbols and labels are clearly visible.

                                                        3. Challenge: Do your best to style populated_places over this busy background.

                                                          Here is an example with labels for inspiration:

                                                          This is opportunity to revisit label halo settings from Polygons: :

                                                          symbolizers:\n- point:\n    size: ${'5' + '10' - SCALERANK / '3'}\n    symbols:\n    - mark:\n        shape: circle\n        stroke-color: 'white'\n        stroke-width: 1\n        stroke-opacity: 0.75\n        fill-color: 'black'\n        x-labelObstacle: true\n    - text:\n        label: ${name}\n        fill-color: 'black'\n        font-family: Arial\n        font-size: 14\n        anchor: [0.5, 1]\n        offset: [0 ${'-12' + SCALERANK}]\n        halo:\n          fill-color: `lightgray`\n          radius: 2\n          opacity: 0.7\n        priority: ${`0` - LABELRANK}\n        x-maxDisplacement: 90\n

                                                          Using a lightgray halo, 0.7 opacity and radius 2 fades out the complexity immediately surrounding the label text improving legibility.

                                                        "},{"location":"styling/workshop/ysld/done/#ysld.raster.a1","title":"Contrast Enhancement","text":"

                                                        Discussion for Explore Contrast Enhancement <ysld.raster.q1>:

                                                        1. A special effect that is effective with grayscale information is automatic contrast adjustment.

                                                        2. Make use of a simple contrast enhancement with usgs:dem:

                                                          symbolizers:\n- raster:\n    opacity: 1.0\n    contrast-enhancement:\n      mode: normalize\n
                                                        3. Can you explain what happens when zoom in to only show a land area (as indicated with the bounding box below)?

                                                          What happens is insanity, normalize stretches the palette of the output image to use the full dynamic range. As long as we have ocean on the screen (with value 0) the land area was shown with roughly the same presentation.

                                                          Once we zoom in to show only a land area, the lowest point on the screen (say 100) becomes the new black, radically altering what is displayed on the screen.

                                                        "},{"location":"styling/workshop/ysld/done/#ysld.raster.a2","title":"Intervals","text":"

                                                        Answer for Challenge Intervals <ysld.raster.q2>:

                                                        1. The color-map type property dictates how the values are used to generate a resulting color.

                                                          • ramp is used for quantitative data, providing a smooth interpolation between the provided color values.
                                                          • intervals provides categorization for quantitative data, assigning each range of values a solid color.
                                                          • values is used for qualitative data, each value is required to have a color-map entry or it will not be displayed.
                                                        2. Challenge: Update your DEM example to use intervals for presentation. What are the advantages of using this approach for elevation data?

                                                          By using intervals it becomes very clear how relatively flat most of the continent is. The ramp presentation provided lots of fascinating detail which distracted from this fact.

                                                          Here is style for you to cut and paste:

                                                          symbolizers:\n- raster:\n    opacity: 1.0\n    color-map:\n      type: intervals\n      entries:\n      - ['#014636', 0, 0, null]\n      - ['#014636', 1.0, 1, null]\n      - ['#016C59', 1.0, 500, null]\n      - ['#02818A', 1.0, 1000, null]\n      - ['#3690C0', 1.0, 1500, null]\n      - ['#67A9CF', 1.0, 2000, null]\n      - ['#A6BDDB', 1.0, 2500, null]\n      - ['#D0D1E6', 1.0, 3000, null]\n      - ['#ECE2F0', 1.0, 3500, null]\n      - ['#FFF7FB', 1.0, 4000, null]\n
                                                        "},{"location":"styling/workshop/ysld/done/#ysld.raster.a3","title":"Clear Digital Elevation Model Presentation","text":"

                                                        Answer for Challenge Clear Digital Elevation Model Presentation <ysld.raster.q3>:

                                                        1. Now that you have seen the data on screen and have a better understanding how would you modify our initial gray-scale example?

                                                        2. Challenge: Use what you have learned to present the usgs:dem clearly.

                                                          The original was a dark mess. Consider making use of mid-tones (or adopting a sequential palette from color brewer) in order to fix this. In the following example the ocean has been left dark, allowing the mountains stand out more.

                                                          symbolizers:\n- raster:\n    opacity: 1.0\n    color-map:\n      type: ramp\n      entries:\n      - ['#000000', 1.0, 0, null]\n      - ['#444444', 1.0, 1, null]\n      - ['#FFFFFF', 1.0, 3000, null]\n
                                                        "},{"location":"styling/workshop/ysld/done/#ysld.raster.a4","title":"Raster Opacity","text":"

                                                        Discussion for Challenge Clear Digital Elevation Model Presentation <ysld.raster.q3>:

                                                        1. There is a quick way to make raster data transparent, raster opacity property works in the same fashion as with vector data. The raster as a whole will be drawn partially transparent allow content from other layers to provide context.

                                                        2. Challenge: Can you think of an example where this would be useful?

                                                          This is difficult as raster data is usually provided for use as a basemap, with layers being drawn over top.

                                                          The most obvious example here is the display of weather systems, or model output such as fire danger. By drawing the raster with some transparency, the landmass can be shown for context.

                                                        "},{"location":"styling/workshop/ysld/linestring/","title":"Lines","text":"

                                                        We will start our tour of YSLD styling by looking at the representation of lines.

                                                        LineString Geometry

                                                        Review of line symbology:

                                                        • Lines can be used to represent either abstract concepts with length but not width such as networks and boundaries, or long thin features with a width that is too small to represent on the map. This means that the visual width of line symbols do not normally change depending on scale.
                                                        • Lines are recorded as LineStrings or Curves depending on the geometry model used.
                                                        • SLD uses a LineSymbolizer to record how the shape of a line is drawn. The primary characteristic documented is the Stroke used to draw each segment between vertices.
                                                        • Labeling of line work is anchored to the midpoint of the line. GeoServer provides a vendor option to allow label rotation aligned with line segments.

                                                        For our exercises we are going to be using simple YSLD documents, often consisting of a single rule, in order to focus on the properties used for line symbology.

                                                        Each exercise makes use of the ne:roads layer.

                                                        Reference:

                                                        • YSLD Reference
                                                        • YSLD Reference Line symbolizer (User Manual | YSLD Reference)
                                                        • LineString (User Manual | SLD Reference )
                                                        "},{"location":"styling/workshop/ysld/linestring/#line","title":"Line","text":"

                                                        A line symbolizer is represented by a line key. You can make a completely default symbolizer by giving it an empty map

                                                        line:\n

                                                        Basic Stroke Properties

                                                        1. Navigate to the Styles page.

                                                        2. Click Add a new style and choose the following:

                                                          New style name: line_example

                                                          Workspace for new layer: Leave blank

                                                          Format: YSLD

                                                        3. Choose line from the Generate a default style dropdown and click generate.

                                                        4. The style editor should look like below:

                                                          title: dark yellow line\nsymbolizers:\n- line:\n    stroke-width: 1.0\n    stroke-color: '#99cc00'\n

                                                        Note

                                                        The title and value for stroke-color may be different.

                                                        1. Click Apply

                                                        2. Click Layer Preview to see your new style applied to a layer.

                                                          You can use this tab to follow along as the style is edited, it will refresh each time Apply is pressed.

                                                        3. You can see the equivalent SLD by requesting http://localhost:8080/geoserver/rest/styles/line_example.sld?pretty=true which will currently show the default line symbolizer we created.

                                                          <?xml version=\"1.0\" encoding=\"UTF-8\"?><sld:StyledLayerDescriptor xmlns=\"http://www.opengis.net/sld\" xmlns:sld=\"http://www.opengis.net/sld\" xmlns:gml=\"http://www.opengis.net/gml\" xmlns:ogc=\"http://www.opengis.net/ogc\" version=\"1.0.0\">\n <sld:NamedLayer>\n  <sld:Name>line_example</sld:Name>\n  <sld:UserStyle>\n    <sld:Name>line_example</sld:Name>\n    <sld:Title>dark yellow line</sld:Title>\n    <sld:FeatureTypeStyle>\n      <sld:Name>name</sld:Name>\n      <sld:Rule>\n        <sld:LineSymbolizer>\n          <sld:Stroke>\n            <sld:CssParameter name=\"stroke\">#99CC00</sld:CssParameter>\n          </sld:Stroke>\n        </sld:LineSymbolizer>\n      </sld:Rule>\n    </sld:FeatureTypeStyle>\n  </sld:UserStyle>\n </sld:NamedLayer>\n</sld:StyledLayerDescriptor>\n

                                                        We only specified the line symbolizer, so all of the boilerplate around was generated for us.

                                                        1. Additional properties can be used fine-tune appearance. Use stroke-color to specify the colour of the line.

                                                          line:\n  stroke-color: blue\n
                                                        2. stroke-width lets us make the line wider

                                                          line:\n  stroke-color: blue\nstroke-width: 2px\n
                                                        3. stroke-dasharray applies a dot dash pattern.

                                                          line:\n  stroke-color: blue\nstroke-width: 2px\n  stroke-dasharray: 5 2\n
                                                        4. Check the Layer Preview tab to preview the result.

                                                        Note

                                                        The GeoServer rendering engine is quite sophisticated and allows the use of units of measure (such as m or ft). While we are using pixels in this example, real world units will be converted using the current scale, allowing for lines that change width with the scale.

                                                        "},{"location":"styling/workshop/ysld/linestring/#multiple-symbolizers","title":"Multiple Symbolizers","text":"

                                                        Providing two strokes is often used to provide a contrasting edge (called casing) to thick lines. This can be created using two symbolizers.

                                                        1. Start by filling in a bit of boilerplate that we'll be using

                                                          feature-styles:\n- rules:\n  - symbolizers:\n    - line:\n        stroke-color: '#8080E6'\n        stroke-width: 3px\n

                                                          The line symbolizer is inside a rule, which is inside a feature style.

                                                        2. Add a second symbolizer to the rule

                                                          feature-styles:\n- rules:\n  - symbolizers:\n    - line:\n        stroke-color: black\n        stroke-width: 5px\n    - line:\n        stroke-color: '#8080E6'\n        stroke-width: 3px\n

                                                          The wider black line is first so it is drawn first, then the thinner blue line drawn second and so over top of the black line. This is called the painter's algorithm.

                                                        3. If you look carefully you can see a problem with our initial attempt. The junctions of each line show that the casing outlines each line individually, making the lines appear randomly overlapped. Ideally we would like to control this process, only making use of this effect for overpasses.

                                                          This is because the black and blue symbolizers are being drawn on a feature by feature basis. For nice line casing, we want all of the black symbols, and then all of the blue symbols.

                                                        4. Create a new feature style and move the second symbolizer there.

                                                          feature-styles:\n- rules:\n  - symbolizers:\n    - line:\n        stroke-color: black\n        stroke-width: 5px\n- rules:\n  - symbolizers:\n    - line:\n        stroke-color: '#8080E6'\n        stroke-width: 3px\n

                                                          Again we are using painter's algorithm order: the first feature style is drawn first then the second so the second is drawn on top of the first. The difference is that for each feature style, all of the features are drawn before the next feature style is drawn.

                                                        5. If you look carefully you can see the difference.

                                                        6. By using feature styles we have been able to simulate line casing.

                                                        "},{"location":"styling/workshop/ysld/linestring/#label","title":"Label","text":"

                                                        Our next example is significant as it introduces how text labels are generated.

                                                        Use of Label Property

                                                        This is also our first example making use of a dynamic style (where a value comes from an attribute from your data).

                                                        1. To enable LineString labeling we add a text symbolizer witrh a label.

                                                          Update line_example with the following:

                                                          symbolizers:\n- line:\n    stroke-color: blue\n    stroke-width: 1px\n- text:\n    label: ${name}\n
                                                        2. The SLD standard documents the default label position for each kind of Geometry. For LineStrings the initial label is positioned on the midway point of the line.

                                                        3. We have used an expression to calculate a property value for label. The label is generated dynamically from the name attribute. Expressions are supplied within curly braces preceded with a dollar sign, and use Extended Constraint Query Language (ECQL) syntax.

                                                          symbolizers:\n- line:\n    stroke-color: blue\n    stroke-width: 1px\n- text:\n    label: ${name}\n
                                                        4. Additional keys can be supplied to fine-tune label presentation:

                                                          symbolizers:\n- line:\n    stroke-color: blue\n    stroke-width: 1px\n- text:\n    label: ${name}\n    fill-color: black\nplacement: line\n    offset: 7px\n
                                                        5. The fill-color property is set to black to provide the colour of the text.

                                                          symbolizers:\n- line:\n    stroke-color: blue\n    stroke-width: 1px\n- text:\n    label: ${name}\n    fill-color: black\n    placement: line\n    offset: 7px\n
                                                        6. The placement property is used to set how the label is placed with respect to the line. By default it is point which causes the label to be placed next to the midpoint as it would be for a point feature. When set to line it is placed along the line instead. offset specifies how far from the line the label should be placed.

                                                          symbolizers:\n- line:\n    stroke-color: blue\n    stroke-width: 1px\n- text:\n    label: ${name}\n    fill-color: black\n    placement: line\n    offset: 7px\n

                                                        7. When using point placement, you can shift the position of the label using displacement instead of offset. This takes an x value and a y value.

                                                          symbolizers:\n- line:\n    stroke-color: blue\n    stroke-width: 1px\n- text:\n    label: ${name}\n    fill-color: black\n    displacement: [5px, -10px]\n
                                                        "},{"location":"styling/workshop/ysld/linestring/#how-labeling-works","title":"How Labeling Works","text":"

                                                        The rendering engine collects all the generated labels during the rendering of each layer. Then, during labeling, the engine sorts through the labels performing collision avoidance (to prevent labels overlapping). Finally the rendering engine draws the labels on top of the map. Even with collision avoidance you can spot areas where labels are so closely spaced that the result is hard to read.

                                                        The parameters provided by SLD are general purpose and should be compatible with any rendering engine.

                                                        To take greater control over the GeoServer rendering engine we can use \"vendor specific\" parameters. These hints are used specifically for the GeoServer rendering engine and will be ignored by other systems. In YSLD vendor specific parameters start with the prefix x-.

                                                        1. The ability to take control of the labeling process is exactly the kind of hint a vendor specific parameter is intended for.

                                                          Update line_example with the following:

                                                          symbolizers:\n- line:\n    stroke-color: blue\n    stroke-width: 1px\n- text:\n    label: ${name}\n    fill-color: black\n    placement: line\n    offset: 7px\nx-label-padding: 10\n
                                                        2. The parameter x-label-padding provides additional space around our label for use in collision avoidance.

                                                          symbolizers:\n- line:\n    stroke-color: blue\n    stroke-width: 1px\n- text:\n    label: ${name}\n    fill-color: black\n    placement: line\n    offset: 7px\nx-label-padding: 10\n
                                                        3. Each label is now separated from its neighbor, improving legibility.

                                                        "},{"location":"styling/workshop/ysld/linestring/#scale","title":"Scale","text":"

                                                        This section explores the use of rules with filters and scale restrictions.

                                                        1. Replace the line_example YSLD definition with:

                                                          rules:\n- filter: ${scalerank < 4}\n  symbolizers:\n  - line:\n      stroke-color: black\n      stroke-width: 1\n
                                                        2. And use the Layer Preview tab to preview the result.

                                                        3. The scalerank attribute is provided by the Natural Earth dataset to allow control of the level of detail based on scale. Our filter short-listed all content with scalerank 4 or lower, providing a nice quick preview when we are zoomed out.

                                                        4. In addition to testing feature attributes, selectors can also be used to check the state of the rendering engine.

                                                          Replace your YSLD with the following:

                                                          rules:\n- scale: [35000000, max]\n  symbolizers:\n  - line:\n      stroke-color: black\n      stroke-width: 1\n- scale: [min, 35000000]\n  symbolizers:\n  - line:\n      stroke-color: blue\n      stroke-width: 1\n
                                                        5. As you adjust the scale in the Layer Preview (using the mouse scroll wheel) the color will change between black and blue. You can read the current scale in the bottom right corner, and the legend will change to reflect the current style.

                                                        6. Putting these two ideas together allows control of level detail based on scale:

                                                          define: &primaryStyle\n  stroke-color: black\ndefine: &primaryFilter ${scalerank <= 4}\n\ndefine: &secondaryStyle\n  stroke-color: '#000055'\ndefine: &secondaryFilter ${scalerank = 5}\n\nrules:\n\n  - else: true\n    scale: [min, 9000000]\n    symbolizers:\n    - line:\n        stroke-color: '#888888'\n        stroke-width: 1\n\n  - filter: ${scalerank = 7}\n    scale: [min, 17000000]\n    symbolizers:\n    - line:\n        stroke-color: '#777777'\n        stroke-width: 1\n\n  - filter: ${scalerank = 6}\n    scale: [min, 35000000]\n    symbolizers:\n    - line:\n        stroke-color: '#444444'\n        stroke-width: 1\n\n  - filter: *secondaryFilter\n    scale: [9000000, 70000000]\n    symbolizers:\n    - line:\n        <<: *secondaryStyle\n        stroke-width: 1\n  - filter: *secondaryFilter\n    scale: [min, 9000000]\n    symbolizers:\n    - line:\n        <<: *secondaryStyle\n        stroke-width: 2\n\n  - filter: *primaryFilter\n    scale: [35000000, max]\n    symbolizers:\n    - line:\n        <<: *primaryStyle\n        stroke-width: 1\n  - filter: *primaryFilter\n    scale: [9000000, 35000000]\n    symbolizers:\n    - line:\n        <<: *primaryStyle\n        stroke-width: 2\n  - filter: *primaryFilter\n    scale: [min, 9000000]\n    symbolizers:\n    - line:\n        <<: *primaryStyle\n        stroke-width: 4\n
                                                        7. When a rule has both a filter and a scale, it will trigger when both are true.

                                                          The first rule has else: true instead of a filter. This causes it to be applied after all other rules have been checked if none of them worked.

                                                          Since there are some things we need to specify more than once like the colour and filter for primary and secondary roads, even as they change size at different scales, they are given names with define so they can be reused. The filters are inserted inline using *name while the style is inserted as a block with <<: *name

                                                        "},{"location":"styling/workshop/ysld/linestring/#bonus","title":"Bonus","text":"

                                                        Finished early? Here are some opportunities to explore what we have learned, and extra challenges requiring creativity and research.

                                                        In a classroom setting please divide the challenges between teams (this allows us to work through all the material in the time available).

                                                        Instructor Notes

                                                        As usual the Explore section invites readers to reapply the material covered in a slightly different context or dataset.

                                                        The use of selectors using the roads type attribute provides this opportunity.

                                                        "},{"location":"styling/workshop/ysld/linestring/#explore-vendor-option-follow-line","title":"Explore Vendor Option Follow Line","text":"

                                                        Vendor options can be used to enable some quite spectacular effects, while still providing a style that can be used by other applications.

                                                        1. Update line_example with the following:

                                                          symbolizers:\n- line:\n    stroke-color: '#EDEDFF'\n    stroke-width: 10\n- text:\n    label: '${level} #${name}'\n    fill-color: '#000000'\n    x-followLine: true\n

                                                          The \\# character is the comment character in YAML, so we have to quote strings that contain it like colours and in this expression.

                                                        2. The property stroke-width has been used to make our line thicker in order to provide a backdrop for our label.

                                                          symbolizers:\n- line:\n    stroke-color: '#EDEDFF'\n    stroke-width: 10\n- text:\n    label: '${level} #${name}'\n    fill-color: '#000000'\n    placement: point\n    x-followLine: true\n
                                                        3. The label property combine several CQL expressions together for a longer label.

                                                          symbolizers:\n- line:\n    stroke-color: '#EDEDFF'\n    stroke-width: 10\n- text:\n    label: '${level} #${name}'\n    fill-color: '#000000'\n    x-followLine: true\n

                                                          The expressions in the label property:

                                                          ${level} #${name}\n

                                                          are inserted into the text by combining them with the text between them using Concatenate function:

                                                          [Concatenate(level,' #', name)]\n

                                                          This happens silently in the background.

                                                        4. The property x-followLine provides the ability of have a label exactly follow a LineString character by character.

                                                          symbolizers:\n- line:\n    stroke-color: '#EDEDFF'\n    stroke-width: 10\n- text:\n    label: ${level}  ${name}\n    fill-color: '#000000'\n    x-followLine: true\n
                                                        5. The result is a new appearance for our roads.

                                                        "},{"location":"styling/workshop/ysld/linestring/#ysld.line.q1","title":"Challenge Classification","text":"
                                                        1. The roads type attribute provides classification information.

                                                          You can Layer Preview to inspect features to determine available values for type.

                                                        2. Challenge: Create a new style adjust road appearance based on type.

                                                          note:: The available values are 'Major Highway','Secondary Highway','Road' and 'Unknown'.

                                                          note:: Answer provided <ysld.line.a1> at the end of the workbook.

                                                        "},{"location":"styling/workshop/ysld/linestring/#ysld.line.q2","title":"Challenge One Rule Classification","text":"
                                                        1. You can save a lot of typing by doing your classification in an expression using arithmetic or the Recode function

                                                        2. Challenge: Create a new style and classify the roads based on their scale rank using expressions in a single rule instead of multiple rules with filters.

                                                          Note

                                                          Answer provided <ysld.line.a2> at the end of the workbook.

                                                        "},{"location":"styling/workshop/ysld/linestring/#ysld.line.q3","title":"Challenge Label Shields","text":"
                                                        1. The traditional presentation of roads in the US is the use of a shield symbol, with the road number marked on top.

                                                        2. Challenge: Have a look at the documentation for putting a graphic on a text symbolizer in SLD and reproduce this technique in YSLD.

                                                          Note

                                                          Answer provided <ysld.line.a3> at the end of the workbook.

                                                        "},{"location":"styling/workshop/ysld/point/","title":"Points","text":"

                                                        The next stop of the ysld styling tour is the representation of points.

                                                        Review of point symbology:

                                                        • Points are used to represent a location only, and do not form a shape. The visual width of lines do not change depending on scale.
                                                        • SLD uses a PointSymbolizer record how the shape of a line is drawn.
                                                        • Labeling of points is anchored to the point location.

                                                        As points have no inherent shape of their own, emphasis is placed on marking locations with an appropriate symbol.

                                                        Reference:

                                                        • YSLD Reference
                                                        • YSLD Reference Point symbolizer (User Manual | YSLD Reference)
                                                        • Point (User Manual | SLD Reference )

                                                        This exercise makes use of the ne:populated_places layer.

                                                        1. Navigate to the Styles page.

                                                        2. Click Add a new style and choose the following:

                                                          Name: point_example

                                                          Workspace: No workspace

                                                          Format: YSLD

                                                        3. Choose point from the Generate a default style dropdown and click generate.

                                                        4. Replace the initial YSLD definition with the following and click apply:

                                                          symbolizers:\n- point:\n    symbols:\n    - mark:\n        shape: circle\n        stroke-width: 1\n
                                                        5. And use the Layer Preview tab to preview the result.

                                                        "},{"location":"styling/workshop/ysld/point/#mark","title":"Mark","text":"

                                                        The point symbolizer controls the display of point data. Points are represented with the mandatory property mark.

                                                        The SLD standard provides \"well-known\" symbols for use with point symbology: circle, square, triangle, arrow, cross, star, and x.

                                                        1. Change the symbol used by the style to a square:

                                                          symbolizers:\n- point:\n    symbols:\n    - mark:\n        shape: square\n        stroke-width: 1\n
                                                        2. Map Preview:

                                                        3. Before we continue we will use a filter to cut down the amount of data shown to a reasonable level.

                                                          rules:\n- filter: ${SCALERANK < '1'}\n  scale: [min, max]\n  symbolizers:\n  - point:\n      symbols:\n      - mark:\n          shape: square\n          stroke-width: 1\n

                                                        Note

                                                        symbolizers has been indented under rules

                                                        1. Resulting in a considerably cleaner image:

                                                        2. Additional properties are available to control a mark's presentation:

                                                          The size property is used to control symbol size.

                                                          The rotation property controls orientation, accepting input in degrees.

                                                          Trying these two settings together:

                                                          rules:\n- filter: ${SCALERANK < '1'}\n  scale: [min, max]\n  symbolizers:\n  - point:\n      size: 8\n      rotation: 45.0\n      symbols:\n      - mark:\n          shape: square\n          stroke-width: 1\n
                                                        3. Results in each location being marked with a diamond:

                                                        4. The mark property provides parameters to style the point symbol. Let's change the fill-color to gray.

                                                          rules:\n- filter: ${SCALERANK < '1'}\n  scale: [min, max]\n  symbolizers:\n  - point:\n      size: 8\n      rotation: 45.0\n      symbols:\n      - mark:\n          shape: square\n          stroke-color: 'black'\n          stroke-width: 1\n          fill-color: 'gray'\n
                                                        5. Updating the mark to a gray square with a black outline.

                                                        6. You can add more symbolizers to apply additional point styles.

                                                          Using this approach marks can be composed of multiple symbols, each with its own settings:

                                                          rules:\n- filter: ${SCALERANK < '1'}\n  scale: [min, max]\n  symbolizers:\n  - point:\n      size: 16\n      symbols:\n      - mark:\n          shape: square\n          stroke-color: 'black'\n          stroke-width: 1\n          fill-color: 'red'\n  - point:\n      size: 14\n      rotation: 45.0\n      symbols:\n      - mark:\n          shape: cross\n          stroke-color: 'white'\n          stroke-width: 1\n          fill-color: 'black'\n
                                                        7. Producing an interesting compound symbol effect:

                                                        "},{"location":"styling/workshop/ysld/point/#graphic","title":"Graphic","text":"

                                                        Symbols can also be supplied by an external graphic,

                                                        This technique was shown with the initial airport.svg YSLD example.

                                                        1. To use an external graphic two pieces of information are required.

                                                          url property is defined with a url reference to image.

                                                          format property is used to tell the rendering engine what file format to expect

                                                          This technique is used to reference files placed in the styles directory.

                                                          rules:\n- filter: ${SCALERANK < '1'}\n  scale: [min, max]\n  symbolizers:\n  - point:\n      symbols:\n      - external:\n          url: file:/path/to/geoserver/data_dir/styles/port.svg\n          format: image/svg\n
                                                        2. Drawing the provided shape in each location:

                                                        3. The property url reference can also be used to reference external images. We can make use of the GeoServer logo.

                                                          rules:\n- filter: ${SCALERANK < '1'}\n  scale: [min, max]\n  symbolizers:\n  - point:\n      size: 16\n      symbols:\n      - external:\n          url: http://localhost:8080/geoserver/web/wicket/resource/org.geoserver.web.GeoServerBasePage/img/logo.png\n          format: image/png\n
                                                        4. As shown in the map preview.

                                                        "},{"location":"styling/workshop/ysld/point/#label","title":"Label","text":"

                                                        Labeling is now familiar from our experience with LineString and Polygons.

                                                        The text symbolizer with the label property are required to label Point Locations.

                                                        1. Replace point_example with the following:

                                                          rules:\n- filter: ${SCALERANK < '1'}\n  scale: [min, max]\n  symbolizers:\n  - point:\n      symbols:\n      - mark:\n          shape: circle\n          stroke-color: 'black'\n          stroke-width: 1\n          fill-color: 'gray'\n  - text:\n      label: ${NAME}\n      fill-color: 'gray'\n      placement: point\n
                                                        2. Confirm the result in Layer Preview preview.

                                                        3. Each label is drawn starting from the provided point - which is unfortunate as it assures each label will overlap with the symbol used. To fix this limitation we will make use of the YSLD controls for label placement:

                                                          anchor provides two values expressing how a label is aligned with respect to the starting label position.

                                                          displacement is be used to provide an initial displacement using and x and y offset. For points this offset is recommended to adjust the label position away for the area used by the symbol.

                                                          Note

                                                          The property anchor defines an anchor position relative to the bounding box formed by the resulting label. This anchor position is snapped to the label position generated by the point location and displacement offset.

                                                          Using these two facilities together we can center our labels below the symbol, taking care that the displacement used provides an offset just outside the area required for the symbol size.

                                                          rules:\n- filter: ${SCALERANK < '1'}\n  scale: [min, max]\n  symbolizers:\n  - point:\n      size: 10\n      symbols:\n      - mark:\n          shape: circle\n          stroke-color: 'black'\n          stroke-width: 1\n          fill-color: 'gray'\n  - text:\n      label: ${NAME}\n      fill-color: 'black'\n      placement: point\n      anchor: [0.5, 1.0]\n      displacement: [0, -12]\n
                                                        4. Each label is now placed under the mark.

                                                        5. One remaining issue is the overlap between labels and symbols.

                                                          GeoServer provides a vendor specific parameter to allow symbols to take part in label conflict resolution, preventing labels from overlapping any symbols. This severely limits the area available for labeling and is best used in conjunction with a large maximum displacement vendor option.

                                                          x-labelObstacle vendor parameter asks the rendering engine to avoid drawing labels over top of the indicated symbol. This applies to the point symbolizer.

                                                          x-maxDisplacement vendor parameter provides the rendering engine a maximum distance it is allowed to move labels during conflict resolution. This applies to the text symbolizer.

                                                          x-spaceAround vendor parameter tells the rendering engine to provide a minimum distance between the labels on the map, ensuring they do not overlap. This applies to the text symbolizer.

                                                          Update our example to use these settings:

                                                          rules:\n- filter: ${SCALERANK < '1'}\n  scale: [min, max]\n  symbolizers:\n  - point:\n      size: 10\n      symbols:\n      - mark:\n          shape: circle\n          stroke-color: 'black'\n          stroke-width: 1\n          fill-color: 'gray'\n      x-labelObstacle: true\n  - text:\n      label: ${NAME}\n      fill-color: 'black'\n      placement: point\n      anchor: [0.5, 1.0]\n      displacement: [0, -12]\n      x-maxDisplacement: 100\n      x-spaceAround: 2\n
                                                        6. Resulting in a considerably cleaner image:

                                                        "},{"location":"styling/workshop/ysld/point/#dynamic-styling","title":"Dynamic Styling","text":"
                                                        1. We will quickly use scalerank to select content based on @scale filters.

                                                          define: &point\n  size: 6\n  symbols:\n  - mark:\n      shape: circle\n      stroke-color: 'black'\n      stroke-width: 1\n      fill-color: 'gray'\nrules:\n- filter: ${SCALERANK < '7'}\n  scale: ['4000000.0', '8000000.0']\n  symbolizers:\n  - point:\n      <<: *point\n- filter: ${SCALERANK < '5'}\n  scale: ['8000000.0', '1.7E7']\n  symbolizers:\n  - point:\n      <<: *point\n- filter: ${SCALERANK < '4'}\n  scale: ['1.7E7', '3.5E7']\n  symbolizers:\n  - point:\n      <<: *point\n- filter: ${SCALERANK < '3'}\n  scale: ['3.5E7', '7.0E7']\n  symbolizers:\n  - point:\n      <<: *point\n- filter: ${SCALERANK < '2'}\n  scale: ['7.0E7', '1.4E8']\n  symbolizers:\n  - point:\n      <<: *point\n- filter: ${SCALERANK < '1'}\n  scale: ['1.4E8', max]\n  symbolizers:\n  - point:\n      <<: *point\n- scale: [min, '4000000.0']\n  symbolizers:\n  - point:\n      <<: *point\n
                                                        2. Click Apply to update the Layer Preview after each step.

                                                          Note

                                                          This YSLD makes use of a define to avoid repeating the point symbolizer content multiple times. As an example the [scale: [min, '4000000.0']]{.title-ref} rule, combined with the define: results in the following collection of properties:

                                                          - scale: [min, '4000000.0']\n  symbolizers:\n  - point:\n      size: 6\n      symbols:\n      - mark:\n          shape: circle\n          stroke-color: 'black'\n          stroke-width: 1\n          fill-color: 'gray'\n
                                                        3. To add labeling we must use both a point and text symbolizer in each scale filter.

                                                          define: &point\n  size: 6\n  symbols:\n  - mark:\n      shape: circle\n      stroke-color: 'black'\n      stroke-width: 1\n      fill-color: 'gray'\ndefine: &label\n  label: ${NAME}\n  fill-color: 'black'\n  font-family: Arial\n  font-size: 10\n  font-style: normal\n  font-weight: normal\n  placement: point\nrules:\n- filter: ${SCALERANK < '7'}\n  scale: ['4000000.0', '8000000.0']\n  symbolizers:\n  - point:\n      <<: *point\n  - text:\n      <<: *label\n- filter: ${SCALERANK < '5'}\n  scale: ['8000000.0', '1.7E7']\n  symbolizers:\n  - point:\n      <<: *point\n  - text:\n      <<: *label\n- filter: ${SCALERANK < '4'}\n  scale: ['1.7E7', '3.5E7']\n  symbolizers:\n  - point:\n      <<: *point\n  - text:\n      <<: *label\n- filter: ${SCALERANK < '3'}\n  scale: ['3.5E7', '7.0E7']\n  symbolizers:\n  - point:\n      <<: *point\n  - text:\n      <<: *label\n- filter: ${SCALERANK < '2'}\n  scale: ['7.0E7', '1.4E8']\n  symbolizers:\n  - point:\n      <<: *point\n  - text:\n      <<: *label\n- filter: ${SCALERANK < '1'}\n  scale: ['1.4E8', max]\n  symbolizers:\n  - point:\n      <<: *point\n  - text:\n      <<: *label\n- scale: [min, '4000000.0']\n  symbolizers:\n  - point:\n      <<: *point\n  - text:\n      <<: *label\n

                                                        4. We will use displacement and anchor to position the label above each symbol.

                                                          Add the following two lines to the label define:

                                                          define: &label\n  label: ${NAME}\n  fill-color: 'black'\n  font-family: Arial\n  font-size: 10\n  font-style: normal\n  font-weight: normal\n  placement: point\n  anchor: [0.5, 0]\n  displacement: [0, 6]\n

                                                        5. A little bit of work with vendor specific parameters will prevent our labels from colliding with each symbol, while giving the rendering engine some flexibility in how far it is allowed to relocate a label.

                                                          Add the following vendor options to the label define:

                                                          define: &label\n  label: ${NAME}\n  fill-color: 'black'\n  font-family: Arial\n  font-size: 10\n  font-style: normal\n  font-weight: normal\n  placement: point\n  anchor: [0.5, 0]\n  displacement: [0, 6]\n  x-maxDisplacement: 90\n  x-spaceAround: 2\n

                                                          Add the following vendor option to the point define:

                                                          define: &point\n  size: 6\n  symbols:\n  - mark:\n      shape: circle\n      stroke-color: 'black'\n      stroke-width: 1\n      fill-color: 'gray'\n  x-labelObstacle: true\n

                                                        6. Now that we have clearly labeled our cities, zoom into an area you are familiar with and we can look at changing symbology on a case-by-case basis.

                                                          We have used expressions previous to generate an appropriate label. Expressions can also be used for many other property settings.

                                                          The ne:populated_places layer provides several attributes specifically to make styling easier:

                                                          • SCALERANK: we have already used this attribute to control the level of detail displayed
                                                          • LABELRANK: hint used for conflict resolution, allowing important cities such as capitals to be labeled even when they are close to a larger neighbor.
                                                          • FEATURECLA: used to indicate different types of cities. We will check for Admin-0 capital cities.

                                                          The first thing we will do is calculate the point size using a quick expression:

                                                          ${10-(SCALERANK/2)}\n

                                                          This expression should result in sizes between 5 and 9 and will need to be applied to both point size and label displacement.

                                                          Rather than the \"first come first served\" default to resolve labeling conflicts we can manually provide GeoServer with a label priority. The expression provided is calculated for each label, in the event of a conflict the label with the highest priority takes precedence.

                                                          The LABELRANK attribute goes from 1 through 10 and needs to be flipped around before use as a GeoServer label priority:

                                                          ${10 - LABELRANK}\n

                                                          This expression will result in values between 0 and 10 and will be used for the priority.

                                                          define: &point\n  size: ${10-(SCALERANK/2)}\n  symbols:\n  - mark:\n      shape: circle\n      stroke-color: 'black'\n      stroke-width: 1\n      fill-color: 'gray'\n  x-labelObstacle: true\ndefine: &label\n  label: ${NAME}\n  fill-color: 'black'\n  font-family: Arial\n  font-size: 10\n  font-style: normal\n  font-weight: normal\n  placement: point\n  anchor: [0.5, 0]\n  displacement: [0, '${''10'' - SCALERANK / ''2''}']\n  priority: ${'10' - LABELRANK}\n  x-maxDisplacement: 90\n  x-spaceAround: 2\n

                                                        7. Next we can use FEATURECLA to check for capital cities.

                                                          Adding a filter for capital cities at the top of the rules list:

                                                          - filter: ${SCALERANK < '2' AND FEATURECLA = 'Admin-0 capital'}\n  scale: ['7.0E7', max]\n  name: capitals\n  symbolizers:\n  - point:\n      symbols:\n      - mark:\n          shape: star\n          stroke-color: 'black'\n          stroke-width: 1\n          fill-color: 'gray'\n  - text:\n      label: ${NAME}\n      fill-color: 'gray'\n      placement: point\n- filter: ${FEATURECLA = 'Admin-0 capital'}\n  scale: [min, '7.0E7']\n  name: capitals\n  symbolizers:\n  - point:\n      symbols:\n      - mark:\n          shape: star\n          stroke-color: 'black'\n          stroke-width: 1\n          fill-color: 'gray'\n  - text:\n      label: ${NAME}\n      fill-color: 'gray'\n      placement: point\n

                                                          And updating the populated places filters to ignore capital cities:

                                                          - filter: ${SCALERANK < '7' AND FEATURECLA <> 'Admin-0 capital'}\n  scale: ['4000000.0', '8000000.0']\n  symbolizers:\n  - point:\n      <<: *point\n  - text:\n      <<: *label\n- filter: ${SCALERANK < '5' AND FEATURECLA <> 'Admin-0 capital'}\n  scale: ['8000000.0', '1.7E7']\n  symbolizers:\n  - point:\n      <<: *point\n  - text:\n      <<: *label\n- filter: ${SCALERANK < '4' AND FEATURECLA <> 'Admin-0 capital'}\n  scale: ['1.7E7', '3.5E7']\n  symbolizers:\n  - point:\n      <<: *point\n  - text:\n      <<: *label\n- filter: ${SCALERANK < '3' AND FEATURECLA <> 'Admin-0 capital'}\n  scale: ['3.5E7', '7.0E7']\n  symbolizers:\n  - point:\n      <<: *point\n  - text:\n      <<: *label\n- filter: ${SCALERANK < '2' AND FEATURECLA <> 'Admin-0 capital'}\n  scale: ['7.0E7', '1.4E8']\n  symbolizers:\n  - point:\n      <<: *point\n  - text:\n      <<: *label\n- filter: ${SCALERANK < '1' AND FEATURECLA <> 'Admin-0 capital'}\n  scale: ['1.4E8', max]\n  symbolizers:\n  - point:\n      <<: *point\n  - text:\n      <<: *label\n- scale: [min, '4000000.0']\n  symbolizers:\n  - point:\n      <<: *point\n  - text:\n      <<: *label\n

                                                        8. If you would like to check your work the final file is here: point_example.ysld

                                                        "},{"location":"styling/workshop/ysld/point/#bonus","title":"Bonus","text":"

                                                        Instructor Notes

                                                        The exercise section does not review the examples above, instead it explores the use of:

                                                        • rules using min/max scale and rules using attribute filters
                                                        • recode to map from attribute to symbol
                                                        • interpolate to change size by population
                                                        "},{"location":"styling/workshop/ysld/point/#ysld.point.q1","title":"Challenge Geometry Location","text":"

                                                        Instructor Notes

                                                        As usual Explore invites readers to reapply the material covered in a slightly different context or dataset.

                                                        The use of filters using the roads type attribute provides this opportunity.

                                                        1. The mark property can be used to render any geometry content.

                                                        2. Challenge: Try this yourself by rendering a polygon layer using a mark property.

                                                          Note

                                                          Answer discussed <ysld.point.a1> at the end of the workbook.

                                                        "},{"location":"styling/workshop/ysld/point/#ysld.point.q2","title":"Explore Dynamic Symbolization","text":"
                                                        1. We went to a lot of work to set up filters to choose between star and circle for capital cities.

                                                          This approach is straightforward when applied in isolation:

                                                          rules:\n- filter: ${FEATURECLA = 'Admin-0 capital'}\n  scale: [min, max]\n  symbolizers:\n  - point:\n      symbols:\n      - mark:\n          shape: star\n          stroke-color: 'black'\n          stroke-width: 1\n          fill-color: 'gray'\n- filter: ${FEATURECLA <> 'Admin-0 capital'}\n  scale: [min, max]\n  symbolizers:\n  - point:\n      symbols:\n      - mark:\n          shape: circle\n          stroke-color: 'black'\n          stroke-width: 1\n          fill-color: 'gray'\n

                                                          When combined with checking another attribute, or checking @scale as in our example, this approach can quickly lead to many rules which can be difficult to keep straight.

                                                        2. Taking a closer look, shape can actually be expressed using a string:

                                                          rules:\n- filter: ${FEATURECLA = 'Admin-0 capital'}\n  scale: [min, max]\n  symbolizers:\n  - point:\n      symbols:\n      - mark:\n          shape: 'star'\n          stroke-color: 'black'\n          stroke-width: 1\n          fill-color: 'gray'\n

                                                          Which is represented in SLD as:

                                                          <sld:PointSymbolizer>\n  <sld:Graphic>\n     <sld:Mark>\n        <sld:WellKnownName>star</sld:WellKnownName>\n        <sld:Fill/>\n        <sld:Stroke/>\n     </sld:Mark>\n  </sld:Graphic>\n</sld:PointSymbolizer>\n
                                                        3. GeoServer recognizes this limitation of SLD Mark and ExternalGraphic and provides an opportunity for dynamic symbolization.

                                                          This is accomplished by embedding a small CQL expression in the string passed to symbol or url. This sub-expression is isolated with \\${ } as shown:

                                                          - point:\n    symbols:\n    - mark:\n        shape: ${if_then_else(equalTo(FEATURECLA,'Admin-0 capital'),'star','circle')}\n

                                                          Which is represented in SLD as:

                                                          <sld:PointSymbolizer>\n  <sld:Graphic>\n     <sld:Mark>\n        <sld:WellKnownName>${if_then_else(equalTo(FEATURECLA,'Admin-0 capital'),'star','circle')}</sld:WellKnownName>\n        <sld:Fill/>\n        <sld:Stroke/>\n     </sld:Mark>\n  </sld:Graphic>\n</sld:PointSymbolizer>\n
                                                        4. Challenge: Use this approach to rewrite the Dynamic Styling example.

                                                          Note

                                                          Answer provided <ysld.point.a2> at the end of the workbook.

                                                        1. Challenge: Use the Interpolate function to smoothly change the mark size based on city population.
                                                        "},{"location":"styling/workshop/ysld/point/#ysld.point.q3","title":"Challenge Layer Group","text":"
                                                        1. Use a Layer Group to explore how symbology works together to form a map.

                                                          • ne:NE1
                                                          • ne:states_provincces_shp
                                                          • ne:populated_places
                                                        2. To help start things out here is a style for ne:states_provinces_shp:

                                                          symbolizers:\n- polygon:\n    stroke-color: 'black'\n    stroke-width: 0.25\n    stroke-opacity: 0.5\n    fill-color: 'white'\n    fill-opacity: 0.05\n- polygon:\n    stroke-color: 'black'\n    stroke-width: 0.25\n    stroke-opacity: 0.5\n    fill-color: ${Recode(mapcolor9,'1','#8dd3c7','2','#ffffb3','3','#bebada','4','#fb8072','5','#80b1d3','6','#fdb462','7','#b3de69','8','#fccde5','9','#d9d9d9')}\n    fill-opacity: 0.5\n
                                                        3. This background is relatively busy and care must be taken to ensure both symbols and labels are clearly visible.

                                                        4. Challenge: Do your best to style populated_places over this busy background.

                                                          Here is an example with labels for inspiration:

                                                          Note

                                                          Answer provided <ysld.point.a3> at the end of the workbook.

                                                        "},{"location":"styling/workshop/ysld/point/#explore-true-type-fonts","title":"Explore True Type Fonts","text":"
                                                        1. In addition to image formats GeoServer can make use other kinds of graphics, such as True Type fonts:

                                                          symbolizers:\n- point:\n    symbols:\n    - mark:\n        shape: ttf://Webdings#0x0064\n        stroke-color: 'blue'\n        stroke-width: 1\n
                                                        2. Additional fonts dropped in the styles directory are available for use.

                                                        "},{"location":"styling/workshop/ysld/point/#explore-custom-graphics","title":"Explore Custom Graphics","text":"
                                                        1. The GeoServer rendering engine allows Java developers to hook in additional symbol support.

                                                          This facility is used by GeoServer to offer the shapes used for pattern fills. Community extensions allow the use of simple custom shapes and even charts.

                                                        2. Support has been added for custom graphics using the WKT Geometry representation.

                                                          symbolizers:\n- point:\n    symbols:\n    - mark:\n        shape: wkt://MULTILINESTRING((-0.25 -0.25, -0.125 -0.25), (0.125 -0.25, 0.25 -0.25), (-0.25 0.25, -0.125 0.25), (0.125 0.25, 0.25 0.25))\n        stroke-color: 'blue'\n        stroke-width: 1\n
                                                        "},{"location":"styling/workshop/ysld/polygon/","title":"Polygons","text":"

                                                        Next we look at how YSLD styling can be used to represent polygons.

                                                        Polygon Geometry

                                                        Review of polygon symbology:

                                                        • Polygons offer a direct representation of physical extent or the output of analysis.

                                                        • The visual appearance of polygons reflects the current scale.

                                                        • Polygons are recorded as a LinearRing describing the polygon boundary. Further LinearRings can be used to describe any holes in the polygon if present.

                                                          The Simple Feature for SQL Geometry model (used by GeoJSON) represents these areas as Polygons, the ISO 19107 geometry model (used by GML3) represents these areas as Surfaces.

                                                        • SLD uses a PolygonSymbolizer to describe how the shape of a polygon is drawn. The primary characteristic documented is the Fill used to shade the polygon interior. The use of a Stroke to describe the polygon boundary is optional.

                                                        • Labeling of a polygon is anchored to the centroid of the polygon. GeoServer provides a vendor-option to allow labels to line wrap to remain within the polygon boundaries.

                                                        For our Polygon exercises we will try and limit our YSLD documents to a single rule, in order to showcase the properties used for rendering.

                                                        Reference:

                                                        • YSLD Reference
                                                        • YSLD Reference Polygon symbolizer (User Manual | YSLD Reference)
                                                        • Polygons (User Manual | SLD Reference )

                                                        This exercise makes use of the ne:states_provinces_shp layer.

                                                        1. Navigate to Styles.

                                                        2. Create a new style polygon_example.

                                                          Name: polygon_example

                                                          Workspace: No workspace

                                                          Format: YSLD

                                                        3. Choose polygon from the Generate a default style dropdown and click generate.

                                                        4. Replace the generated style with the following style and click Apply to save:

                                                          symbolizers:\n- polygon:\n    fill-color: 'lightgrey'\n
                                                        5. Click on the tab Layer Preview to preview.

                                                        6. Set ne:states_provinces_shp as the preview layer.

                                                        "},{"location":"styling/workshop/ysld/polygon/#stroke-and-fill","title":"Stroke and Fill","text":"

                                                        The polygon symbolizer controls the display of polygon data.

                                                        The fill-color property is used to provide the color used to draw the interior of a polygon.

                                                        1. Replace the contents of polygon_example with the following fill example:

                                                          symbolizers:\n- polygon:\n    fill-color: 'gray'\n
                                                        2. The Layer Preview tab can be used preview the change:

                                                        3. To draw the boundary of the polygon the stroke property is used:

                                                          The stroke property is used to provide the color and size of the polygon boundary. It is effected by the same parameters (and vendor specific parameters) as used for LineStrings.

                                                          symbolizers:\n- polygon:\n    fill-color: 'gray'\n    stroke-color: 'black'\n    stroke-width: 2\n

                                                          Note

                                                          Technically the boundary of a polygon is a specific case of a LineString where the first and last vertex are the same, forming a closed LinearRing.

                                                        4. The effect of adding stroke is shown in the map preview:

                                                        5. An interesting technique when styling polygons in conjunction with background information is to control the fill opacity.

                                                          The fill-opacity property is used to adjust transparency (provided as range from 0.0 to 1.0). Use of fill-opacity to render polygons works well in conjunction with a raster base map. This approach allows details of the base map to shown through.

                                                          The stroke-opacity property is used in a similar fashion, as a range from 0.0 to 1.0.

                                                          symbolizers:\n- polygon:\n    fill-color: 'white'\n    fill-opacity: 0.5\n    stroke-color: 'lightgrey'\n    stroke-width: 0.25\n    stroke-opacity: 0.5\n
                                                        6. As shown in the map preview:

                                                        7. This effect can be better appreciated using a layer group.

                                                          Where the transparent polygons is used lighten the landscape provided by the base map.

                                                        Instructor Notes

                                                        In this example we want to ensure readers know the key property for polygon data.

                                                        It is also our first example of using opacity.

                                                        "},{"location":"styling/workshop/ysld/polygon/#pattern","title":"Pattern","text":"

                                                        The fill-graphic property can be used to provide a pattern.

                                                        The fill pattern is defined by repeating one of the built-in symbols, or making use of an external image.

                                                        1. We have two options for configuring a fill-graphic with a repeating graphic:

                                                          Using external to reference to an external graphic.

                                                          Use of mark to access a predefined shape. SLD provides several well-known shapes (circle, square, triangle, arrow, cross, star, and x). GeoServer provides additional shapes specifically for use as fill patterns.

                                                          Update polygon_example with the following built-in symbol as a repeating fill pattern:

                                                          symbolizers:\n- polygon:\n    fill-graphic:\n      symbols:\n      - mark:\n          shape: square\n          fill-color: 'gray'\n          stroke-color: 'black'\n          stroke-width: 1\n
                                                        2. The map preview (and legend) will show the result:

                                                        3. Add a black stroke:

                                                          symbolizers:\n- polygon:\n    stroke-color: 'black'\n    stroke-width: 1\n    fill-graphic:\n      symbols:\n      - mark:\n          shape: square\n          fill-color: 'gray'\n          stroke-color: 'black'\n          stroke-width: 1\n
                                                        4. To outline the individual shapes:

                                                        5. Additional fill properties allow control over the orientation and size of the symbol.

                                                          The size property is used to adjust the size of the symbol prior to use.

                                                          The rotation property is used to adjust the orientation of the symbol.

                                                          Adjust the size and rotation as shown:

                                                          symbolizers:\n- polygon:\n    stroke-color: 'black'\n    stroke-width: 1\n    fill-graphic:\n      size: 22\n      rotation: 45.0\n      symbols:\n      - mark:\n          shape: square\n          fill-color: 'gray'\n          stroke-color: 'black'\n          stroke-width: 1\n
                                                        6. The size of each symbol is increased, and each symbol rotated by 45 degrees.

                                                          Note

                                                          Does the above look correct? There is an open request GEOT-4642 to rotate the entire pattern, rather than each individual symbol.

                                                        7. The size and rotation properties just affect the size and placement of the symbol, but do not alter the symbol's design. In order to control the color we set the fill-color and stroke-color properties of the mark.

                                                        8. Replace the contents of polygon_example with the following:

                                                          symbolizers:\n- polygon:\n    fill-graphic:\n      symbols:\n      - mark:\n          shape: square\n          fill-color: '#008000'\n          stroke-color: '#006400'\n          stroke-width: 1\n
                                                        9. This change adjusts the appearance of our grid of squares.

                                                        10. The well-known symbols are more suited for marking individual points. Now that we understand how a pattern can be controlled it is time to look at the patterns GeoServer provides.

                                                          shape://horizline horizontal hatching shape://vertline vertical hatching shape://backslash right hatching pattern shape://slash left hatching pattern shape://plus vertical and horizontal hatching pattern shape://times cross hatch pattern

                                                          Update the example to use shape://slash for a pattern of left hatching.

                                                          symbolizers:\n- polygon:\n    stroke-color: 'black'\n    stroke-width: 1\n    fill-graphic:\n      symbols:\n      - mark:\n          shape: 'shape://slash'\n          stroke-color: 'gray'\n
                                                        11. This approach is well suited to printed output or low color devices.

                                                        12. To control the size of the symbol produced use the size property of the fill-graphic.

                                                          symbolizers:\n- polygon:\n    stroke-color: 'black'\n    stroke-width: 1\n    fill-graphic:\n      size: 8\n      symbols:\n      - mark:\n          shape: 'shape://slash'\n          stroke-color: 'gray'\n
                                                        13. This results in a tighter pattern shown:

                                                        14. Multiple fills can be applied by using a separate symbolizer for each fill as part of the same rule.

                                                          symbolizers:\n- polygon:\n    stroke-color: 'black'\n    stroke-width: 1\n    fill-color: '#DDDDFF'\n- polygon:\n    fill-graphic:\n      size: 8\n      symbols:\n      - mark:\n          shape: shape://slash\n          stroke-color: 'black'\n          stroke-width: 0.5\n
                                                        15. The resulting image has a solid fill, with a pattern drawn overtop.

                                                        "},{"location":"styling/workshop/ysld/polygon/#label","title":"Label","text":"

                                                        Labeling polygons follows the same approach used for LineStrings.

                                                        The key properties fill and label are used to enable Polygon label generation.

                                                        1. By default labels are drawn starting at the centroid of each polygon.

                                                        2. Try out label and fill together by replacing our polygon_example with the following:

                                                          symbolizers:\n- polygon:\n    stroke-color: 'blue'\n    stroke-width: 1\n    fill-color: '#7EB5D3'\n- text:\n    label: ${name}\n    fill-color: 'black'\n
                                                        3. Each label is drawn from the lower-left corner as shown in the Layer Preview preview.

                                                        4. We can adjust how the label is drawn at the polygon centroid.

                                                          The property anchor provides two numbers expressing how a label is aligned with respect to the centroid. The first value controls the horizontal alignment, while the second value controls the vertical alignment. Alignment is expressed between 0.0 and 1.0 as shown in the following table.

                                                                   Left      Center    Right\n

                                                          Top 0.0 1.0 0.5 1.0 1.0 1.0

                                                          Middle 0.0 0.5 0.5 0.5 1.0 0.5

                                                          Bottom 0.0 0.0 0.5 0.0 1.0 0.0

                                                          Adjusting the anchor is the recommended approach to positioning your labels.

                                                        5. Using the anchor property we can center our labels with respect to geometry centroid.

                                                          To align the center of our label we select 50% horizontally and 50% vertically, by filling in 0.5 and 0.5 below:

                                                          symbolizers:\n- polygon:\n    stroke-color: 'blue'\n    stroke-width: 1\n    fill-color: '#7EB5D3'\n- text:\n    label: ${name}\n    fill-color: 'black'\n    anchor: [0.5, 0.5]\n
                                                        6. The labeling position remains at the polygon centroid. We adjust alignment by controlling which part of the label we are \"snapping\" into position.

                                                        7. The property displacement can be used to provide an initial displacement using and x and y offset.

                                                        8. This offset is used to adjust the label position relative to the geometry centroid resulting in the starting label position.

                                                          symbolizers:\n- polygon:\n    stroke-color: 'blue'\n    stroke-width: 1\n    fill-color: '#7EB5D3'\n- text:\n    label: ${name}\n    fill-color: 'black'\n    displacement: [0, 7]\n
                                                        9. Confirm this result in the map preview.

                                                        10. These two settings can be used together.

                                                          The rendering engine starts by determining the label position generated from the geometry centroid and the label-offset displacement. The bounding box of the label is used with the label-anchor setting align the label to this location.

                                                          Step 1: starting label position = centroid + displacement

                                                          Step 2: snap the label anchor to the starting label position

                                                        11. To move our labels down (allowing readers to focus on each shape) we can use displacement combined with followed by horizontal alignment.

                                                          symbolizers:\n- polygon:\n    stroke-color: 'blue'\n    stroke-width: 1\n    fill-color: '#7EB5D3'\n- text:\n    label: ${name}\n    fill-color: 'black'\n    anchor: [0.5, 1]\n    displacement: [0, -7]\n
                                                        12. As shown in the map preview.

                                                        "},{"location":"styling/workshop/ysld/polygon/#legibility","title":"Legibility","text":"

                                                        When working with labels a map can become busy very quickly, and difficult to read.

                                                        1. GeoServer provides extensive vendor parameters directly controlling the labelling process.

                                                          Many of these parameters focus on controlling conflict resolution (when labels would otherwise overlap).

                                                        2. Two common properties for controlling labeling are:

                                                          x-maxDisplacement indicates the maximum distance GeoServer should displace a label during conflict resolution.

                                                          x-autoWrap allows any labels extending past the provided width will be wrapped into multiple lines.

                                                        3. Using these together we can make a small improvement in our example:

                                                          symbolizers:\n- polygon:\n    stroke-color: 'blue'\n    stroke-width: 1\n    fill-color: '#7EB5D3'\n- text:\n    label: ${name}\n    fill-color: 'black'\n    anchor: [0.5, 0.5]\n    x-maxDisplacement: 40\n    x-autoWrap: 70\n
                                                        4. As shown in the following preview.

                                                        5. Even with this improved spacing between labels, it is difficult to read the result against the complicated line work.

                                                          Use of a halo to outline labels allows the text to stand out from an otherwise busy background. In this case we will make use of the fill color, to provide some space around our labels. We will also change the font to Arial.

                                                          symbolizers:\n- polygon:\n    stroke-color: 'blue'\n    stroke-width: 1\n    fill-color: '#7EB5D3'\n- text:\n    label: ${name}\n    fill-color: 'black'\n    anchor: [0.5, 0.5]\n    font-family: Arial\n    font-size: 14\n    font-style: normal\n    font-weight: normal\n    halo:\n      fill-color: '#7EB5D3'\n      fill-opacity: 0.8\n      radius: 2\n    x-maxDisplacement: 40\n    x-autoWrap: 70\n
                                                        6. By making use of fill-opacity on the halo we still allow stroke information to show through, but prevent the stroke information from making the text hard to read.

                                                        7. And advanced technique for manually taking control of conflict resolution is the use of the priority.

                                                          This property takes an expression which is used in the event of a conflict. The label with the highest priority \"wins.\"

                                                        8. The Natural Earth dataset we are using includes a labelrank intended to control what labels are displayed based on zoom level.

                                                          The values for labelrank go from 0 (for zoomed out) to 20 (for zoomed in). To use this value for priority we need to swap the values around so a scalerank of 1 is given the highest priority.

                                                          symbolizers:\n- polygon:\n    stroke-color: 'blue'\n    stroke-width: 1\n    fill-color: '#7EB5D3'\n- text:\n    label: ${name}\n    fill-color: 'black'\n    anchor: [0.5, 0.5]\n    font-family: Arial\n    font-size: 14\n    font-style: normal\n    font-weight: normal\n    halo:\n      fill-color: '#7EB5D3'\n      fill-opacity: 0.8\n      radius: 2\n    x-maxDisplacement: 40\n    x-autoWrap: 70\n    priority: ${'20' - labelrank}\n
                                                        9. In the following map East Flanders will take priority over Zeeland when the two labels overlap.

                                                        "},{"location":"styling/workshop/ysld/polygon/#theme","title":"Theme","text":"

                                                        A thematic map (rather than focusing on representing the shape of the world) uses elements of style to illustrate differences in the data under study. This section is a little more advanced and we will take the time to look at the generated SLD file.

                                                        Instructor Notes

                                                        This instruction section follows our pattern with LineString. Building on the examples and exploring how selectors can be used.

                                                        • For LineString we explored the use of @scale, in this section we are going to look at theming by attribute.
                                                        • We also unpack how cascading occurs, and what the result looks like in the generated XML.
                                                        • care is being taken to introduce the symbology encoding functions as an option for theming ( placing equal importance on their use).

                                                        Checklist:

                                                        • filter vs function for theming
                                                        • Cascading
                                                        1. We can use a site like ColorBrewer to explore the use of color theming for polygon symbology. In this approach the fill color of the polygon is determined by the value of the attribute under study.

                                                          This presentation of a dataset is known as \"theming\" by an attribute.

                                                        2. For our ne:states_provinces_shp dataset, a mapcolor9 attribute has been provided for this purpose. Theming by mapcolor9 results in a map where neighbouring countries are visually distinct.

                                                          +----------------------------+---------+---------+ | > Qualitative 9-class Set3 | | | +----------------------------+---------+---------+ | #8dd3c7 | #fb8072 | #b3de69 | +----------------------------+---------+---------+ | #ffffb3 | #80b1d3 | #fccde5 | +----------------------------+---------+---------+ | #bebada | #fdb462 | #d9d9d9 | +----------------------------+---------+---------+

                                                          If you are unfamiliar with theming you may wish to visit http://colorbrewer2.org to learn more. The i icons provide an adequate background on theming approaches for qualitative, sequential and diverging datasets.

                                                        3. The first approach we will take is to directly select content based on colormap, providing a color based on the 9-class Set3 palette above:

                                                          define: &stroke\n  stroke-color: 'gray'\n  stroke-width: 0.5\nrules:\n  - filter: ${mapcolor9 = '1'}\n    scale: [min, max]\n    symbolizers:\n    - polygon:\n        <<: *stroke\n        fill-color: '#8DD3C7'\n  - filter: ${mapcolor9 = '2'}\n    scale: [min, max]\n    symbolizers:\n    - polygon:\n        <<: *stroke\n        fill-color: '#FFFFB3'\n  - filter: ${mapcolor9 = '3'}\n    scale: [min, max]\n    symbolizers:\n    - polygon:\n        <<: *stroke\n        fill-color: '#BEBADA'\n  - filter: ${mapcolor9 = '4'}\n    scale: [min, max]\n    symbolizers:\n    - polygon:\n        <<: *stroke\n        fill-color: '#FB8072'\n  - filter: ${mapcolor9 = '5'}\n    scale: [min, max]\n    symbolizers:\n    - polygon:\n        <<: *stroke\n        fill-color: '#80B1D3'\n  - filter: ${mapcolor9 = '6'}\n    scale: [min, max]\n    symbolizers:\n    - polygon:\n        <<: *stroke\n        fill-color: '#FDB462'\n  - filter: ${mapcolor9 = '7'}\n    scale: [min, max]\n    symbolizers:\n    - polygon:\n        <<: *stroke\n        fill-color: '#B3DE69'\n  - filter: ${mapcolor9 = '8'}\n    scale: [min, max]\n    symbolizers:\n    - polygon:\n        <<: *stroke\n        fill-color: '#FCCDE5'\n  - filter: ${mapcolor9 = '9'}\n    scale: [min, max]\n    symbolizers:\n    - polygon:\n        <<: *stroke\n        fill-color: '#D9D9D9'\n  - filter: ${mapcolor9 <> '1' AND mapcolor9 <> '2' AND mapcolor9 <> '3' AND mapcolor9 <> '4' AND mapcolor9 <> '5' AND mapcolor9 <> '6' AND mapcolor9 <> '7' AND mapcolor9 <> '8' AND mapcolor9 <> '9'}\n    scale: [min, max]\n    symbolizers:\n    - line:\n        <<: *stroke\n
                                                        4. The Layer Preview tab can be used to preview this result.

                                                        5. This YSLD makes use of a define to avoid repeating the stroke-color and stroke-width information multiple times.

                                                          As an example the \\${mapcolor9 = '2'} rule, combined with the define: results in the following collection of properties:

                                                          - filter: ${mapcolor9 = '2'}\n    scale: [min, max]\n    symbolizers:\n    - polygon:\n        stroke-color: 'gray'\n        stroke-width: 0.5\n        fill-color: '#FFFFB3'\n
                                                        6. Reviewing the generated SLD shows us this representation:

                                                          <sld:Rule>\n   <ogc:Filter>\n      <ogc:PropertyIsEqualTo>\n         <ogc:PropertyName>mapcolor9</ogc:PropertyName>\n         <ogc:Literal>2</ogc:Literal>\n      </ogc:PropertyIsEqualTo>\n   </ogc:Filter>\n   <sld:PolygonSymbolizer>\n      <sld:Fill>\n         <sld:CssParameter name=\"fill\">#ffffb3</sld:CssParameter>\n      </sld:Fill>\n   </sld:PolygonSymbolizer>\n   <sld:LineSymbolizer>\n      <sld:Stroke>\n         <sld:CssParameter name=\"stroke\">#808080</sld:CssParameter>\n         <sld:CssParameter name=\"stroke-width\">0.5</sld:CssParameter>\n      </sld:Stroke>\n   </sld:LineSymbolizer>\n</sld:Rule>\n
                                                        7. There are three important functions, defined by the Symbology Encoding specification, that are often easier to use for theming than using rules.

                                                          • Recode: Used the theme qualitative data. Attribute values are directly mapped to styling property such as fill or stroke-width.
                                                          • Categorize: Used the theme quantitative data. Categories are defined using min and max ranges, and values are sorted into the appropriate category.
                                                          • Interpolate: Used to smoothly theme quantitative data by calculating a styling property based on an attribute value.

                                                          Theming is an activity, producing a visual result allow map readers to learn more about how an attribute is distributed spatially. We are free to produce this visual in the most efficient way possible.

                                                        8. Swap out mapcolor9 theme to use the Recode function:

                                                          symbolizers:\n- polygon:\n    stroke-color: 'gray'\n    stroke-width: 0.5\n    fill-color: ${Recode(mapcolor9,\n      '1','#8dd3c7',\n      '2','#ffffb3',\n      '3','#bebada',\n      '4','#fb8072',\n      '5','#80b1d3',\n      '6','#fdb462',\n      '7','#b3de69',\n      '8','#fccde5',\n      '9','#d9d9d9')}\n
                                                        9. The Layer Preview tab provides the same preview.

                                                        10. The Generated SLD tab shows where things get interesting. Our generated style now consists of a single Rule:

                                                          <sld:Rule>\n   <sld:PolygonSymbolizer>\n      <sld:Fill>\n         <sld:CssParameter name=\"fill\">\n            <ogc:Function name=\"Recode\">\n               <ogc:PropertyName>mapcolor9</ogc:PropertyName>\n               <ogc:Literal>1</ogc:Literal>\n                  <ogc:Literal>#8dd3c7</ogc:Literal>\n               <ogc:Literal>2</ogc:Literal>\n                  <ogc:Literal>#ffffb3</ogc:Literal>\n               <ogc:Literal>3</ogc:Literal>\n                  <ogc:Literal>#bebada</ogc:Literal>\n               <ogc:Literal>4</ogc:Literal>\n                  <ogc:Literal>#fb8072</ogc:Literal>\n               <ogc:Literal>5</ogc:Literal>\n                  <ogc:Literal>#80b1d3</ogc:Literal>\n               <ogc:Literal>6</ogc:Literal>\n                  <ogc:Literal>#fdb462</ogc:Literal>\n               <ogc:Literal>7</ogc:Literal>\n                  <ogc:Literal>#b3de69</ogc:Literal>\n               <ogc:Literal>8</ogc:Literal>\n                  <ogc:Literal>#fccde5</ogc:Literal>\n               <ogc:Literal>9</ogc:Literal>\n                  <ogc:Literal>#d9d9d9</ogc:Literal>\n         </ogc:Function>\n         </sld:CssParameter>\n      </sld:Fill>\n   </sld:PolygonSymbolizer>\n   <sld:LineSymbolizer>\n      <sld:Stroke>\n         <sld:CssParameter name=\"stroke\">#808080</sld:CssParameter>\n         <sld:CssParameter name=\"stroke-width\">0.5</sld:CssParameter>\n      </sld:Stroke>\n   </sld:LineSymbolizer>\n</sld:Rule>\n
                                                        "},{"location":"styling/workshop/ysld/polygon/#bonus","title":"Bonus","text":"

                                                        The following optional explore and challenge activities offer a chance to review and apply the ideas introduced here. The challenge activities require a bit of creativity and research to complete.

                                                        In a classroom setting you are encouraged to team up into groups, with each group taking on a different challenge.

                                                        "},{"location":"styling/workshop/ysld/polygon/#ysld.polygon.q1","title":"Explore Antialiasing","text":"
                                                        1. When we rendered our initial preview, without a stroke, thin white gaps (or slivers) are visible between our polygons.

                                                          This effect is made more pronounced by the rendering engine making use of the Java 2D sub-pixel accuracy. This technique is primarily used to prevent an aliased (stair-stepped) appearance on diagonal lines.

                                                        2. Clients can turn this feature off using a GetMap format option:

                                                          format_options=antialiasing=off;\n

                                                          The LayerPreview provides access to this setting from the Open Layers Options Toolbar:

                                                        3. Explore: Experiment with fill and stroke settings to eliminate slivers between polygons.

                                                          Note

                                                          Answer provided <ysld.polygon.a1> at the end of the workbook.

                                                        "},{"location":"styling/workshop/ysld/polygon/#ysld.polygon.q2","title":"Explore Categorize","text":"

                                                        Instructor Notes

                                                        This section reviews use of the Symbology Encoding Categorize function for something else other than color. Goal is to have readers reach for SE Functions as often as selectors when styling.

                                                        Additional exercise ideas:

                                                        • Control size using Interpolate: While Recode offers an alternative for selectors (matching discrete values) Interpolate brings something new to the table - gradual color (or value) progression. The best of example of this is controlling width using the ne:rivers data layer (which is not yet available).
                                                        1. The Categorize function can be used to generate property values based on quantitative information. Here is an example using Categorize to color states according to size.

                                                          symbolizers:\n- polygon:\n    fill-color: ${Categorize(Shape_Area,\n      '#08519c','0.5',\n      '#3182bd','1',\n      '#6baed6','5',\n      '#9ecae1','60',\n      '#c6dbef','80',\n      '#eff3ff')}\n

                                                        2. An exciting use of the GeoServer shape symbols is the theming by changing the size used for pattern density.

                                                        3. Explore: Use the Categorize function to theme by datarank.

                                                          Note

                                                          Answer provided <ysld.polygon.a2> at the end of the workbook.

                                                        "},{"location":"styling/workshop/ysld/polygon/#ysld.polygon.q3","title":"Challenge Goodness of Fit","text":"
                                                        1. A subject we touched on during labeling was the conflict resolution GeoServer performs to ensure labels do not overlap.

                                                        2. In addition to the vendor parameter for max displacement you can experiment with different values for \"goodness of fit\". These settings control how far GeoServer is willing to move a label to avoid conflict, and under what terms it simply gives up:

                                                          x-goodnessOfFit: 0.3\nx-maxDisplacement: 130\n
                                                        3. You can also experiment with turning off this facility completely:

                                                          x-conflictResolution: false\n
                                                        4. Challenge: Construct your own example using maxDisplacement and goodnessOfFit.

                                                        "},{"location":"styling/workshop/ysld/polygon/#ysld.polygon.q4","title":"Challenge Halo","text":"
                                                        1. The halo example used the fill color and opacity for a muted halo, while this improved readability it did not bring attention to our labels.

                                                          A common design choice for emphasis is to outline the text in a contrasting color.

                                                        2. Challenge: Produce a map that uses a white halo around black text.

                                                          Note

                                                          Answer provided <ysld.polygon.a4> at the end of the workbook.

                                                        "},{"location":"styling/workshop/ysld/polygon/#ysld.polygon.q5","title":"Challenge Theming using Multiple Attributes","text":"
                                                        1. A powerful tool is theming using multiple attributes. This is an important concept allowing map readers to perform \"integration by eyeball\" (detecting correlations between attribute values information).

                                                        2. Challenge: Combine the mapcolor9 and datarank examples to reproduce the following map.

                                                          Note

                                                          Answer provided <ysld.polygon.a5> at the end of the workbook.

                                                        "},{"location":"styling/workshop/ysld/polygon/#ysld.polygon.q6","title":"Challenge Use of Z-Index","text":"
                                                        1. Earlier we looked at using multiple feature-styles to simulate line string casing. The line work was drawn twice, once with thick line, and then a second time with a thinner line. The resulting effect is similar to text halos - providing breathing space around complex line work allowing it to stand out.

                                                        2. Challenge: Use what you know of LineString feature-styles to reproduce the following map:

                                                          Note

                                                          Answer provided <ysld.polygon.a6> at the end of the workbook.

                                                        "},{"location":"styling/workshop/ysld/raster/","title":"Rasters","text":"

                                                        Finally we will look at using YSLD styling for the portrayal of raster data.

                                                        Raster Symbology

                                                        Review of raster symbology:

                                                        • Raster data is Grid Coverage where values have been recorded in a regular array. In OGC terms a Coverage can be used to look up a value or measurement for each location.

                                                        • When queried with a \"sample\" location:

                                                          • A grid coverage can determine the appropriate array location and retrieve a value. Different techniques may be used interpolate an appropriate value from several measurements (higher quality) or directly return the \"nearest neighbor\" (faster).
                                                          • A vector coverages would use a point-in-polygon check and return an appropriate attribute value.
                                                          • A scientific model can calculate a value for each sample location
                                                        • Many raster formats organize information into bands of content. Values recorded in these bands and may be mapped into colors for display (a process similar to theming an attribute for vector data).

                                                          For imagery the raster data is already formed into red, green and blue bands for display.

                                                        • As raster data has no inherent shape, the format is responsible for describing the orientation and location of the grid used to record measurements.

                                                        These raster examples use a digital elevation model consisting of a single band of height measurements. The imagery examples use an RGB image that has been hand coloured for use as a base map.

                                                        Reference:

                                                        • YSLD Reference
                                                        • Raster (YSLD Reference | Raster symbolizer)
                                                        • Raster (User Manual | SLD Reference )

                                                        The exercise makes use of the usgs:dem and ne:ne1 layers.

                                                        "},{"location":"styling/workshop/ysld/raster/#image","title":"Image","text":"

                                                        The raster symbolizer controls the display of raster data. By default, the raster symbolizer automatically selects the appropriate red, green and blue channels for display.

                                                        1. Navigate to the Styles page.

                                                        2. Click Add a new style and choose the following:

                                                          Name: image_example

                                                          Workspace: No workspace

                                                          Format: YSLD

                                                        3. Choose raster from the Generate a default style dropdown and click generate.

                                                        4. Replace the initial YSLD definition with:

                                                          symbolizers:\n- raster:\n    opacity: 1.0\n
                                                        5. And use the Layer Preview tab to preview the result.

                                                        6. The channels property can be used to provide a list three band numbers (for images recording in several wavelengths) or a single band number can be used to view a grayscale image.

                                                          symbolizers:\n- raster:\n    opacity: 1.0\n    channels:\n      gray:\n        name: '2'\n
                                                        7. Isolating just the green band (it will be drawn as a grayscale image):

                                                        "},{"location":"styling/workshop/ysld/raster/#dem","title":"DEM","text":"

                                                        A digital elevation model is an example of raster data made up of measurements, rather than color information.

                                                        The usgs:dem layer used for this exercise:

                                                        1. Return to the Styles page.

                                                        2. Click Add a new style and choose the following:

                                                          Name: raster_example

                                                          Workspace: No workspace

                                                          Format: YSLD

                                                        3. Choose raster from the Generate a default style dropdown and click generate.

                                                        4. The rendering engine will select our single band of raster content, and do its best to map these values into a grayscale image. Replace the content of the style with:

                                                          symbolizers:\n- raster:\n    opacity: 1.0\n
                                                        5. Use the Layer Preview tab to preview the result. The range produced in this case from the highest and lowest values.

                                                        6. We can use a bit of image processing to emphasis the generated color mapping by making use of contrast-enhancement.

                                                          symbolizers:\n- raster:\n    opacity: 1.0\n    channels:\n      gray:\n        name: '1'\n        contrast-enhancement:\n          mode: histogram\n
                                                        7. Image processing of this sort should be used with caution as it does distort the presentation (in this case making the landscape look more varied then it is in reality.

                                                        "},{"location":"styling/workshop/ysld/raster/#color-map","title":"Color Map","text":"

                                                        The approach of mapping a data channel directly to a color channel is only suitable to quickly look at quantitative data.

                                                        For qualitative data (such as land use) or simply to use color, we need a different approach:

                                                        Note

                                                        We can use a color map to artificially color a single band raster introducing smooth graduations for elevation or temperature models or clear differentiation for qualitative data.

                                                        1. Apply the following YAML to our usgs:DEM layer:

                                                          symbolizers:\n- raster:\n    opacity: 1.0\n    color-map:\n      type: ramp\n      entries:\n      - ['#9080DB', 1.0, 0, null]\n      - ['#008000', 1.0, 1, null]\n      - ['#105020', 1.0, 255, null]\n      - ['#FFFFFF', 1.0, 4000, null]\n
                                                        2. Resulting in this artificial color image:

                                                        3. An opacity value can also be used with each color-map entry.

                                                          symbolizers:\n- raster:\n    opacity: 1.0\n    color-map:\n      type: ramp\n      entries:\n      - ['#9080DB', 0.0, 0, null]\n      - ['#008000', 1.0, 1, null]\n      - ['#105020', 1.0, 255, null]\n      - ['#FFFFFF', 1.0, 4000, null]\n
                                                        4. Allowing the areas of zero height to be transparent:

                                                        Note

                                                        Raster format for GIS work often supply a \"no data\" value, or contain a mask, limiting the dataset to only the locations with valid information.

                                                        "},{"location":"styling/workshop/ysld/raster/#custom","title":"Custom","text":"

                                                        We can use what we have learned about color maps to apply a color brewer palette to our data.

                                                        This exploration focuses on accurately communicating differences in value, rather than strictly making a pretty picture. Care should be taken to consider the target audience and medium used during palette selection.

                                                        1. Restore the raster_example YSLD style to the following:

                                                          symbolizers:\n- raster:\n    opacity: 1.0\n
                                                        2. Producing the following map preview.

                                                        3. To start with we can provide our own grayscale using two color map entries.

                                                          symbolizers:\n- raster:\n    opacity: 1.0\n    color-map:\n      type: ramp\n      entries:\n      - ['#000000', 1.0, 0, null]\n      - ['#FFFFFF', 1.0, 4000, null]\n
                                                        4. Use the Layer Preview tab to zoom in and take a look.

                                                          This is much more direct representation of the source data. We have used our knowledge of elevations to construct a more accurate style.

                                                        5. While our straightforward style is easy to understand, it does leave a bit to be desired with respect to clarity.

                                                          The eye has a hard time telling apart dark shades of black (or bright shades of white) and will struggle to make sense of this image. To address this limitation we are going to switch to the ColorBrewer 9-class PuBuGn palette. This is a sequential palette that has been hand tuned to communicate a steady change of values.

                                                        6. Update your style with the following:

                                                          symbolizers:\n- raster:\n    opacity: 1.0\n    color-map:\n      type: ramp\n      entries:\n      - ['#014636', 1.0, 0, null]\n      - ['#016C59', 1.0, 500, null]\n      - ['#02818A', 1.0, 1000, null]\n      - ['#3690C0', 1.0, 1500, null]\n      - ['#67A9CF', 1.0, 2000, null]\n      - ['#A6BDDB', 1.0, 2500, null]\n      - ['#D0D1E6', 1.0, 3000, null]\n      - ['#ECE2F0', 1.0, 3500, null]\n      - ['#FFF7FB', 1.0, 4000, null]\n

                                                        7. A little bit of work with alpha (to mark the ocean as a no-data section):

                                                          symbolizers:\n- raster:\n    opacity: 1.0\n    color-map:\n      type: ramp\n      entries:\n      - ['#014636', 0, 0, null]\n      - ['#014636', 1.0, 1, null]\n      - ['#016C59', 1.0, 500, null]\n      - ['#02818A', 1.0, 1000, null]\n      - ['#3690C0', 1.0, 1500, null]\n      - ['#67A9CF', 1.0, 2000, null]\n      - ['#A6BDDB', 1.0, 2500, null]\n      - ['#D0D1E6', 1.0, 3000, null]\n      - ['#ECE2F0', 1.0, 3500, null]\n      - ['#FFF7FB', 1.0, 4000, null]\n
                                                        8. And we are done:

                                                        "},{"location":"styling/workshop/ysld/raster/#bonus","title":"Bonus","text":""},{"location":"styling/workshop/ysld/raster/#ysld.raster.q1","title":"Explore Contrast Enhancement","text":"
                                                        1. A special effect that is effective with grayscale information is automatic contrast adjustment.
                                                        2. Make use of a simple contrast enhancement with usgs:dem:
                                                        symbolizers:\n- raster:\n    opacity: 1.0\n    contrast-enhancement:\n      mode: normalize\n
                                                        1. Can you explain what happens when zoom in to only show a land area (as indicated with the bounding box below)?

                                                          Note

                                                          Discussion provided <ysld.raster.a1> at the end of the workbook.

                                                        "},{"location":"styling/workshop/ysld/raster/#ysld.raster.q2","title":"Challenge Intervals","text":"
                                                        1. The color-map type property dictates how the values are used to generate a resulting color.

                                                          • ramp is used for quantitative data, providing a smooth interpolation between the provided color values.
                                                          • intervals provides categorization for quantitative data, assigning each range of values a solid color.
                                                          • values is used for qualitative data, each value is required to have a color-map entry or it will not be displayed.
                                                        2. Challenge: Update your DEM example to use intervals for presentation. What are the advantages of using this approach for elevation data?

                                                          Note

                                                          Answer provided <ysld.raster.a2> at the end of the workbook.

                                                        "},{"location":"styling/workshop/ysld/raster/#explore-image-processing","title":"Explore Image Processing","text":"

                                                        Additional properties are available to provide slight image processing during visualization.

                                                        Note

                                                        In this section are we going to be working around a preview issue where only the top left corner of the raster remains visible during image processing. This issue has been reported as GEOS-6213.

                                                        Image processing can be used to enhance the output to highlight small details or to balance images from different sensors allowing them to be compared.

                                                        1. The contrast-enhancement property is used to turn on a range of post processing effects. Settings are provided for normalize or histogram or none;
                                                        symbolizers:\n- raster:\n    opacity: 1.0\n    contrast-enhancement:\n      mode: normalize\n
                                                        1. Producing the following image:

                                                        2. The raster-gamma property is used adjust the brightness of contrast-enhancement output. Values less than 1 are used to brighten the image while values greater than 1 darken the image.

                                                        symbolizers:\n- raster:\n    opacity: 1.0\n    contrast-enhancement:\n      gamma: 1.5\n
                                                        1. Providing the following effect:

                                                        "},{"location":"styling/workshop/ysld/raster/#ysld.raster.q3","title":"Challenge Clear Digital Elevation Model Presentation","text":"
                                                        1. Now that you have seen the data on screen and have a better understanding how would you modify our initial gray-scale example?

                                                        2. Challenge: Use what you have learned to present the usgs:dem clearly.

                                                          Note

                                                          Answer provided <ysld.raster.a3> at the end of the workbook.

                                                        "},{"location":"styling/workshop/ysld/raster/#ysld.raster.q4","title":"Challenge Raster Opacity","text":"
                                                        1. There is a quick way to make raster data transparent, raster opacity property works in the same fashion as with vector data. The raster as a whole will be drawn partially transparent allow content from other layers to provide context.

                                                        2. Challenge: Can you think of an example where this would be useful?

                                                          Note

                                                          Discussion provided <ysld.raster.a4> at the end of the workbook.

                                                        "},{"location":"styling/workshop/ysld/ysld/","title":"YSLD Quickstart","text":"

                                                        In the last section, we saw how the OGC defines style using XML documents (called SLD files).

                                                        We will now explore GeoServer styling in greater detail using a tool to generate our SLD files. The YSLD GeoServer extension is used to generate SLD files using a clearer, more concise language based on YAML. Unlike CSS, the YSLD styling language has a one-to-one correspondence to SLD, meaning that each line of YSLD translates directly to one or more lines of SLD. Additionally, A YSLD style can be converted to SLD and back without loss of information.

                                                        Using the YSLD extension to define styles results in shorter examples that are easier to understand. At any point we will be able to review the generated SLD file.

                                                        Reference:

                                                        • YSLD Reference
                                                        "},{"location":"styling/workshop/ysld/ysld/#syntax","title":"Syntax","text":"

                                                        This section provides a quick introduction to YSLD syntax for mapping professionals who may not be familiar with YAML.

                                                        "},{"location":"styling/workshop/ysld/ysld/#property-syntax","title":"Property Syntax","text":"

                                                        Individual statements (or directives) in a YSLD styling document are designed as key-value, or property-value pairs of the following form:

                                                        <property>: <value>\n

                                                        The <property> is a string denoting the property name, while the <value> can be one of a number of different types depending on context.

                                                        Integer Numerical value. May be surrounded by quotes. Float Numerical value. May be surrounded by quotes. Text Text value. If value is ambiguous, use single quotes. Color Hexadecimal color of the form '#RRGGBB'. Tuple A list of values in brackets. e.g. [[0, 1]]{.title-ref} Expression CQL expression surrounded by \\${ }"},{"location":"styling/workshop/ysld/ysld/#mappings-and-lists","title":"Mappings and lists","text":"

                                                        There are three types of objects in a YSLD document:

                                                        1. Scalar, a simple value

                                                        2. Mapping, a collection of key-value (property-value) pairs

                                                        3. List, any collection of objects. A list can contain mappings, scalars, and even other lists.

                                                          Lists require dashes for every entry, while mappings do not.

                                                        For example, a symbolizer block is a list, so every entry requires its own dash:

                                                        • symbolizer:

                                                          • polygon:

                                                            ...

                                                          • text:

                                                            ...

                                                        The polygon: and text: objects (the individual symbolizers themselves) are mappings, and as such, the contents do not require dashes, only indents:

                                                        - polygon:\n    stroke-color: '#808080'\n    fill-color: '#FF0000'\n

                                                        The dash next to polygon means that the item itself is contained in a list, not that it contains a list. And the placement of the dash is at the same level of indentation as the list title.

                                                        If you have a list that contains only one item, and there is no other content at higher levels of the list, you may omit the enclosing elements. For example, the following are equivalent:

                                                        feature-styles:\n- rules:\n  - symbolizers:\n    - point:\n        symbols:\n        - mark:\n            shape: circle\n            fill-color: 'gray'\n
                                                        point:\n  symbols:\n  - mark:\n      shape: circle\n      fill-color: 'gray'\n

                                                        This is useful for making your styles more concise.

                                                        "},{"location":"styling/workshop/ysld/ysld/#indentation","title":"Indentation","text":"

                                                        Indentation is very important in YSLD. All directives must be indented to its proper place to ensure proper hierarchy. Improper indentation will cause a style to be rendered incorrectly, or not at all.

                                                        For example, the polygon symbolizer, since it is a mapping, contains certain parameters inside it, such as the color of the fill and stroke. These must be indented such that they are \"inside\" the polygon block.

                                                        In this example, the following markup is correct:

                                                        - polygon:\n    fill-color: '#808080'\n    fill-opacity: 0.5\n    stroke-color: black\n    stroke-opacity: 0.75\n

                                                        The parameters inside the polygon (symbolizer) are indented, meaning that they are referencing the symbolizer and are not \"outside it.\"

                                                        Compare to the following incorrect markup:

                                                        - polygon:\n  fill-color: '#808080'\n  fill-opacity: 0.5\n  stroke-color: black\n  stroke-opacity: 0.75\n
                                                        "},{"location":"styling/workshop/ysld/ysld/#rules","title":"Rules","text":"

                                                        We have already seen a CSS style composed of a single rule:

                                                        point:\n  symbols:\n  - mark:\n      shape: circle\n      fill-color: 'gray'\n

                                                        We can make a style consisting of more than one rule, carefully choosing the selector for each rule. In this case we are using a selector to style capital cities with a star, and non-capital with a circle:

                                                        rules:\n  - filter: ${FEATURECLA = 'Admin-0 capital'}\n    scale: [min, max]\n    symbolizers:\n    - point:\n        size: 6\n        symbols:\n        - mark:\n            shape: star\n            stroke-color: 'black'\n            stroke-width: 1\n            fill-color: 'gray'\n  - filter: ${FEATURECLA <> 'Admin-0 capital'}\n    scale: [min, max]\n    symbolizers:\n    - point:\n        size: 6\n        symbols:\n        - mark:\n            shape: circle\n            stroke-color: 'black'\n            stroke-width: 1\n            fill-color: 'gray'\n

                                                        The feature attribute test performed above uses Constraint Query Language (CQL). This syntax can be used to define filters to select content, similar to how the SQL WHERE statement is used. It can also be used to define expressions to access attribute values allowing their use when defining style properties.

                                                        Rule selectors can also be triggered based on the state of the rendering engine. In this example we are only applying labels when zoomed in:

                                                        rules:\n  - scale: [min, '2.0E7']\n    symbolizers:\n    - text:\n        label: ${NAME}\n        fill-color: 'gray'\n

                                                        In the above example the label is defined using the CQL Expression NAME. This results in a dynamic style that generates each label on a case-by-case basis, filling in the label with the feature attribute NAME.

                                                        Reference:

                                                        • Filter Syntax (YSLD Reference)
                                                        • ECQL Reference (User Guide)
                                                        "},{"location":"styling/workshop/ysld/ysld/#variables","title":"Variables","text":"

                                                        Up to this point we have been styling individual features, documenting how each shape is represented.

                                                        When styling multiple features, or using filters to style individual features in different years, you may need to repeat styling information.

                                                        Variables in YSLD allow for a certain directive or block of directives to be defined by name and later reused. This can greatly simplify the styling document.

                                                        The two most-common use cases for using variables are:

                                                        • To create a more-friendly name for a value (such as using myorange instead of #EE8000)
                                                        • To define a block of directives to remove redundant content and to decrease file length

                                                        It is customary, but not required, to place all definitions at the very top of the YSLD file.

                                                        The syntax for defining a variable as a single value is:

                                                        define: &variable <value>\n

                                                        The defined variable can then be used as a value by variable name with a *:

                                                        <directive>: *variable\n

                                                        The syntax for defining a variable as a content block is:

                                                        define: &varblock\n  <directive>: <value>\n  <directive>: <value>\n  ...\n  <block>:\n  - <directive>: <value>\n    <directive>: <value>\n  ...\n

                                                        The syntax for using a variable block is to prepend the variable name with <<: *. For example:

                                                        <block>:\n- <directive>: <value>\n  <<: *varblock\n
                                                        • Variables (YSLD Reference)
                                                        "},{"location":"styling/workshop/ysld/ysld/#compare-ysld-to-sld","title":"Compare YSLD to SLD","text":"

                                                        As noted above, YSLD has a one-to-one correspondence with SLD, it merely uses a different markup language to display the same content. We can compare a SLD style with a YSLD style to see this correspondence:

                                                        "},{"location":"styling/workshop/ysld/ysld/#sld-style","title":"SLD Style","text":"

                                                        Here is an example SLD file for reference:

                                                        <?xml version=\"1.0\" encoding=\"ISO-8859-1\"?>\n<StyledLayerDescriptor version=\"1.0.0\"\n xsi:schemaLocation=\"http://www.opengis.net/sld StyledLayerDescriptor.xsd\"\n xmlns=\"http://www.opengis.net/sld\"\n xmlns:ogc=\"http://www.opengis.net/ogc\"\n xmlns:xlink=\"http://www.w3.org/1999/xlink\"\n xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\">\n  <NamedLayer>\n    <Name>airports</Name>\n    <UserStyle>\n      <Title>Airports</Title>\n      <FeatureTypeStyle>\n        <Rule>\n          <Name>airports</Name>\n          <Title>Airports</Title>\n          <PointSymbolizer>\n            <Graphic>\n              <ExternalGraphic>\n                <OnlineResource xlink:type=\"simple\"\n                xlink:href=\"airport.svg\" />\n                <Format>image/svg</Format>\n              </ExternalGraphic>\n              <Size>16</Size>\n            </Graphic>\n          </PointSymbolizer>\n        </Rule>\n      </FeatureTypeStyle>\n    </UserStyle>\n  </NamedLayer>\n</StyledLayerDescriptor>\n
                                                        "},{"location":"styling/workshop/ysld/ysld/#ysld-style","title":"YSLD Style","text":"

                                                        Here is the same example as YSLD:

                                                        name: airports\ntitle: Airports\nscale: [min, max]\nsymbolizers:\n- point:\n    size: 16\n    symbols:\n    - external:\n        url: airport.svg\n        format: image/svg\n

                                                        We use a point symbolizer to indicate we want this content drawn as a Point (line 16 in the SLD, line 5 in the YSLD). The point symbolizer declares an external graphic, which contains the URL airports.svg indicating the image that should be drawn (line 20 in the SLD, line 9 in the YSLD).

                                                        "},{"location":"styling/workshop/ysld/ysld/#tour","title":"Tour","text":"

                                                        To confirm everything works, let's reproduce the airports style above.

                                                        1. Navigate to the Styles page.

                                                        2. Each time we edit a style, the contents of the associated SLD file are replaced. Rather than disrupt any of our existing styles we will create a new style. Click Add a new style and choose the following:

                                                          Name: airports0

                                                          Workspace: (leave empty)

                                                          Format: YSLD

                                                        3. Replace the initial YSLD definition with our airport YSLD example and click Apply:

                                                          {% \n  include \"../files/airports0.ysld\"\n%}\n
                                                        4. Click the Layer Preview tab to preview the style. We want to preview on the airports layer, so click the name of the current layer and select ne:airports from the list that appears. You can use the mouse buttons to pan and scroll wheel to change scale.

                                                          Choosing the airports layer

                                                          Layer preview

                                                        5. Click Layer Data for a summary of the selected data.

                                                          Layer attributes

                                                        "},{"location":"styling/workshop/ysld/ysld/#bonus","title":"Bonus","text":"

                                                        Finished early? For now please help your neighbour so we can proceed with the workshop.

                                                        If you are really stuck please consider the following challenge rather than skipping ahead.

                                                        "},{"location":"styling/workshop/ysld/ysld/#explore-data","title":"Explore Data","text":"
                                                        1. Return to the Data tab and use the Compute link to determine the minimum and maximum for the scalerank attribute.

                                                          Instructor Notes

                                                          Should be 2 and 9 respectively.

                                                        "},{"location":"styling/workshop/ysld/ysld/#challenge-compare-sld-generation","title":"Challenge Compare SLD Generation","text":"

                                                        # The rest API can be used to review your YAML file directly.

                                                        Browser:

                                                        • Command line:

                                                          curl -v -u admin:geoserver -XGET http://localhost:8080/geoserver/rest/styles/airports0.yaml\n
                                                          1. The REST API can also be used generate an SLD file:

                                                            Browser:

                                                            • Command line:

                                                              curl -v -u admin:geoserver -XGET http://localhost:8080/geoserver/rest/styles/airports0.sld?pretty=true\n
                                                              1. Compare the generated SLD differ above with the handwritten SLD file used as an example?

                                                                Challenge: What differences can you spot?

                                                                Instructor Notes

                                                                Generated SLD does not include name or title information; this can of course be added. Please check the YSLD reference for details.

                                                                The second difference is with the use of a fallback Mark when defining a PointSymbolizer.

                                                              "},{"location":"styling/ysld/","title":"YSLD Styling","text":"

                                                              This module adds support for the YSLD styling language.

                                                              YSLD is a YAML based language which closely matches the structure of SLD, and the internal data model that GeoServer's renderer uses. For details on YSLD syntax see the reference below or the GeoTools documentation.

                                                              YSLD is not a part of GeoServer by default, but is available as an optional install.

                                                              • Installing the GeoServer YSLD extension
                                                              • GeoServer Specific Extensions
                                                              • YSLD reference
                                                              • YSLD Cookbook
                                                              "},{"location":"styling/ysld/gs-extensions/","title":"GeoServer Specific Extensions","text":""},{"location":"styling/ysld/gs-extensions/#geowebcache-integration","title":"GeoWebCache Integration","text":"

                                                              When defining rules in terms of zoom levels, you can use the zoom level from a gridset defined in the integrated GeoWebCache instance.

                                                              For instance, if your GWC had a gridset named CanadaLCCQuad and you wanted a style rule to apply to levels 0-2 of that gridset you could use the following:

                                                              grid:\n  name: CanadaLCCQuad\nrules:\n- zoom: [0,2]\n  point:\n    ...\n
                                                              "},{"location":"styling/ysld/installing/","title":"Installing the GeoServer YSLD extension","text":"

                                                              The YSLD extension is listed on the GeoServer download page.

                                                              To install:

                                                              1. Download the ysld

                                                                Verify that the version number in the filename corresponds to the version of GeoServer you are running (for example 2.24.2 above).

                                                              2. Extract the contents of the archive into the WEB-INF/lib directory in GeoServer. Make sure you do not create any sub-directories during the extraction process.

                                                              3. Restart GeoServer.

                                                              4. To confirm successful installation, check for a new YSLD entry in the Styles editor.

                                                              "},{"location":"styling/ysld/cookbook/","title":"YSLD Cookbook","text":"

                                                              The YSLD Cookbook is a collection of YSLD \"recipes\" for creating various types of map styles. Wherever possible, each example is designed to show off a single YSLD feature so that code can be copied from the examples and adapted when creating YSLDs of your own. While not an exhaustive reference like the YSLD reference the YSLD cookbook is designed to be a practical reference, showing common style templates that are easy to understand.

                                                              The YSLD Cookbook is divided into four sections: the first three for each of the vector types (points, lines, and polygons) and the fourth section for rasters. Each example in every section contains a screenshot showing actual GeoServer WMS output, a snippet of the YSLD code for reference, and a link to download the full YSLD.

                                                              Each section uses data created especially for the YSLD Cookbook, with shapefiles for vector data and GeoTIFFs for raster data. The projection for data is EPSG:4326.

                                                              Data Type Shapefile

                                                              Point ysld_cookbook_point.zip

                                                              Line ysld_cookbook_line.zip

                                                              Polygon ysld_cookbook_polygon.zip

                                                              Raster ysld_cookbook_raster.zip

                                                              • Points
                                                              • Lines
                                                              • Polygons
                                                              • Rasters
                                                              "},{"location":"styling/ysld/cookbook/lines/","title":"Lines","text":"

                                                              While lines can also seem to be simple shapes, having length but no width, there are many options and tricks for making lines display nicely.

                                                              "},{"location":"styling/ysld/cookbook/lines/#ysld_cookbook_lines_attributes","title":"Example lines layer","text":"

                                                              The lines layer used in the examples below contains road information for a fictional country. For reference, the attribute table for the points in this layer is included below.

                                                              fid (Feature ID) name (Road name) type (Road class)

                                                              line.1 Latway highway

                                                              line.2 Crescent Avenue secondary

                                                              line.3 Forest Avenue secondary

                                                              line.4 Longway highway

                                                              line.5 Saxer Avenue secondary

                                                              line.6 Ridge Avenue secondary

                                                              line.7 Holly Lane local-road

                                                              line.8 Mulberry Street local-road

                                                              line.9 Nathan Lane local-road

                                                              line.10 Central Street local-road

                                                              line.11 Lois Lane local-road

                                                              line.12 Rocky Road local-road

                                                              line.13 Fleet Street local-road

                                                              line.14 Diane Court local-road

                                                              line.15 Cedar Trail local-road

                                                              line.16 Victory Road local-road

                                                              line.17 Highland Road local-road

                                                              line.18 Easy Street local-road

                                                              line.19 Hill Street local-road

                                                              line.20 Country Road local-road

                                                              line.21 Main Street local-road

                                                              line.22 Jani Lane local-road

                                                              line.23 Shinbone Alley local-road

                                                              line.24 State Street local-road

                                                              line.25 River Road local-road

                                                              Download the lines shapefile

                                                              "},{"location":"styling/ysld/cookbook/lines/#ysld_cookbook_lines_simpleline","title":"Simple line","text":"

                                                              This example specifies lines be colored black with a thickness of 3 pixels.

                                                              Simple line

                                                              "},{"location":"styling/ysld/cookbook/lines/#code","title":"Code","text":"

                                                              Download the \"Simple line\" YSLD

                                                              title: 'YSLD Cook Book: Simple Line'\nfeature-styles:\n- name: name\n  rules:\n  - symbolizers:\n    - line:\n        stroke-color: '#000000'\n        stroke-width: 3\n
                                                              "},{"location":"styling/ysld/cookbook/lines/#details","title":"Details","text":"

                                                              There is one rule in one feature style for this YSLD, which is the simplest possible situation. (All subsequent examples will contain one rule and one feature style unless otherwise specified.) Styling lines is accomplished via the line symbolizer (lines 5-8). Line 7 specifies the color of the line to be black ('#000000'), while line 8 specifies the width of the lines to be 3 pixels.

                                                              "},{"location":"styling/ysld/cookbook/lines/#line-with-border","title":"Line with border","text":"

                                                              This example shows how to draw lines with borders (sometimes called \"cased lines\"). In this case the lines are drawn with a 3 pixel blue center and a 1 pixel wide gray border.

                                                              Line with border

                                                              "},{"location":"styling/ysld/cookbook/lines/#code_1","title":"Code","text":"

                                                              Download the \"Line with border\" YSLD

                                                              title: 'YSLD Cook Book: Line with border'\nfeature-styles:\n- name: name\n  rules:\n  - symbolizers:\n    - line:\n        stroke-color: '#333333'\n        stroke-width: 5\n        stroke-linecap: round\n- name: name\n  rules:\n  - symbolizers:\n    - line:\n        stroke-color: '#6699FF'\n        stroke-width: 3\n        stroke-linecap: round\n
                                                              "},{"location":"styling/ysld/cookbook/lines/#details_1","title":"Details","text":"

                                                              Lines in YSLD have no notion of a \"fill\", only \"stroke\". Thus, unlike points or polygons, it is not possible to style the \"edge\" of the line geometry. It is, however, possible to achieve this effect by drawing each line twice: once with a certain width and again with a slightly smaller width. This gives the illusion of fill and stroke by obscuring the larger lines everywhere except along the edges of the smaller lines.

                                                              Since every line is drawn twice, the order of the rendering is very important. GeoServer renders feature-styles in the order that they are presented in the YSLD. In this style, the gray border lines are drawn first via the first feature style, followed by the blue center lines in a second feature style. This ensures that the blue lines are not obscured by the gray lines, and also ensures proper rendering at intersections, so that the blue lines \"connect\".

                                                              In this example, lines 3-9 comprise the first feature style, which is the outer line (or \"stroke\"). Line 7 specifies the color of the line to be dark gray ('#333333'), line 8 specifies the width of this line to be 5 pixels, and in line 9 a stroke-linecap parameter of round renders the ends of the line as rounded instead of flat. (When working with bordered lines using a round line cap ensures that the border connects properly at the ends of the lines.)

                                                              Lines 10-16 comprise the second feature-style, which is the inner line (or \"fill\"). Line 14 specifies the color of the line to be a medium blue ('#6699FF'), line 15 specifies the width of this line to be 3 pixels, and line 16 again renders the edges of the line to be rounded instead of flat.

                                                              The result is a 3 pixel blue line with a 1 pixel gray border, since the 5 pixel gray line will display 1 pixel on each side of the 3 pixel blue line.

                                                              "},{"location":"styling/ysld/cookbook/lines/#dashed-line","title":"Dashed line","text":"

                                                              This example alters the Simple line to create a dashed line consisting of 5 pixels of drawn line alternating with 2 pixels of blank space.

                                                              Dashed line

                                                              "},{"location":"styling/ysld/cookbook/lines/#code_2","title":"Code","text":"

                                                              Download the \"Dashed line\" YSLD

                                                              title: 'YSLD Cook Book: Dashed line'\nfeature-styles:\n- name: name\n  rules:\n  - symbolizers:\n    - line:\n        stroke-color: '#0000FF'\n        stroke-width: 3\n        stroke-dasharray: 5 2\n
                                                              "},{"location":"styling/ysld/cookbook/lines/#details_2","title":"Details","text":"

                                                              In this example, line 8 sets the color of the lines to be blue ('#0000FF') and line 8 sets the width of the lines to be 3 pixels. Line 9 determines the composition of the line dashes. The value of 5 2 creates a repeating pattern of 5 pixels of drawn line, followed by 2 pixels of omitted line.

                                                              "},{"location":"styling/ysld/cookbook/lines/#offset-line","title":"Offset line","text":"

                                                              This example alters the Simple line to add a perpendicular offset line on the left side of the line, at five pixels distance.

                                                              Dashed line

                                                              "},{"location":"styling/ysld/cookbook/lines/#code_3","title":"Code","text":"

                                                              Download the \"Offset line\" YSLD

                                                              title: 'YSLD Cook Book: Dashed line'\nfeature-styles:\n- name: name\n  rules:\n  - symbolizers:\n    - line:\n        stroke-color: '#000000'\n        stroke-width: 2\n    - line:\n        stroke-color: '#0000FF'\n        stroke-width: 3\n        stroke-dasharray: 5 2\n        offset: 3\n
                                                              "},{"location":"styling/ysld/cookbook/lines/#details_3","title":"Details","text":"

                                                              In this example, lines 6-8 draw a simple black line like in the Simple line example. Lines 9-12 draw a blue dashed line like in the above Dashed line example. Line 13 modifies the dashed line with a 3 pixel offset from the line geometry.

                                                              "},{"location":"styling/ysld/cookbook/lines/#railroad-hatching","title":"Railroad (hatching)","text":"

                                                              This example uses hatching to create a railroad style. Both the line and the hatches are black, with a 2 pixel thickness for the main line and a 1 pixel width for the perpendicular hatches.

                                                              Railroad (hatching)

                                                              "},{"location":"styling/ysld/cookbook/lines/#code_4","title":"Code","text":"

                                                              Download the \"Railroad (hatching)\" YSLD

                                                              title: 'YSLD Cook Book: Railroad (hatching)'\nfeature-styles:\n- name: name\n  rules:\n  - symbolizers:\n    - line:\n        stroke-color: '#333333'\n        stroke-width: 3\n    - line:\n        stroke-color: '#333333'\n        stroke-width: 1\n        stroke-graphic:\n          size: 12\n          symbols:\n          - mark:\n              shape: shape://vertline\n              stroke-color: '#333333'\n              stroke-width: 1\n
                                                              "},{"location":"styling/ysld/cookbook/lines/#details_4","title":"Details","text":"

                                                              In this example there are two line symbolizers. The first symbolizer, on lines 6-8, draws a standard line, with line 7 drawing the lines as dark gray ('#333333') and line 8 setting the width of the lines to be 2 pixels.

                                                              The hatching is invoked in the second symbolizer, on lines 9-18. Line 16 specifies that the symbolizer draw a vertical line hatch (shape://vertline) perpendicular to the line geometry. Lines 17-18 set the hatch color to dark gray ('#333333') and width to 1 pixel. Finally, line 13 specifies both the length of the hatch and the distance between each hatch to both be 12 pixels.

                                                              "},{"location":"styling/ysld/cookbook/lines/#spaced-graphic-symbols","title":"Spaced graphic symbols","text":"

                                                              This example uses a graphic stroke along with dash arrays to create a \"dot and space\" line type. Adding the dash array specification allows to control the amount of space between one symbol and the next one. Without using the dash array the lines would be densely populated with dots, each one touching the previous one.

                                                              Spaced symbols along a line

                                                              "},{"location":"styling/ysld/cookbook/lines/#code_5","title":"Code","text":"

                                                              Download the \"Spaced symbols\" YSLD

                                                              name: Default Styler\ntitle: 'YSLD Cook Book: Dash/Space line'\nfeature-styles:\n- name: name\n  rules:\n  - symbolizers:\n    - line:\n        stroke-color: '#333333'\n        stroke-width: 1\n        stroke-dasharray: 4 6\n        stroke-graphic:\n          size: 4\n          symbols:\n          - mark:\n              shape: circle\n              stroke-color: '#333333'\n              stroke-width: 1\n              fill-color: '#666666'\n
                                                              "},{"location":"styling/ysld/cookbook/lines/#details_5","title":"Details","text":"

                                                              This example, like others before, uses a stroke-graphic to place a graphic symbol along a line. The symbol, defined on lines 14-18 is a 4 pixel gray circle with a dark gray outline. The spacing between symbols is controlled with the stroke-dasharray at line 9, which specifies 4 pixels of pen-down (just enough to draw the circle) and 6 pixels of pen-up, to provide the spacing.

                                                              "},{"location":"styling/ysld/cookbook/lines/#ysld_cookbook_lines_defaultlabel","title":"Alternating symbols with dash offsets","text":"

                                                              This example shows how to create a complex line style which alternates a dashed line and a graphic symbol. The code builds on features shown in the previous examples:

                                                              • stroke-dasharray controls pen-down/pen-up behavior to generate dashed lines
                                                              • stroke-graphic places symbols along a line
                                                              • combining the two allows control of symbol spacing

                                                              This also shows the usage of a dash offset, which controls where rendering starts in the dash array. For example, with a dash array of 5 10 and a dash offset of 7 the renderer starts drawing the pattern 7 pixels from the beginning. It skips the 5 pixels pen-down section and 2 pixels of the pen-up section, then draws the remaining 8 pixels of pen-up, then 5 down, 10 up, and so on.

                                                              The example shows how to use these features to create two synchronized sequences of dash arrays, one drawing line segments and the other symbols.

                                                              Alternating dash and symbol

                                                              "},{"location":"styling/ysld/cookbook/lines/#code_6","title":"Code","text":"

                                                              Download the \"Spaced symbols\" YSLD

                                                              title: 'YSLD Cook Book: Dash/Symbol line'\nfeature-styles:\n- name: name\n  rules:\n  - symbolizers:\n    - line:\n        stroke-color: '#0000FF'\n        stroke-width: 1\n        stroke-dasharray: 10 10\n    - line:\n        stroke-color: '#000033'\n        stroke-width: 1\n        stroke-dasharray: 5 15\n        stroke-dashoffset: 7.5\n        stroke-graphic:\n          size: 5\n          symbols:\n          - mark:\n              shape: circle\n              stroke-color: '#000033'\n              stroke-width: 1\n
                                                              "},{"location":"styling/ysld/cookbook/lines/#details_6","title":"Details","text":"

                                                              In this example two line symbolizers use stroke-dasharray and different symbology to produce a sequence of alternating dashes and symbols. The first symbolizer (lines 6-9) is a simple dashed line alternating 10 pixels of pen-down with 10 pixels of pen-up. The second symbolizer (lines 10-21) alternates a 5 pixel empty circle with 15 pixels of white space. The circle symbol is produced by a mark element, with its symbology specified by stroke parameters (lines 20-21). The spacing between symbols is controlled with the stroke-dasharray (line 13), which specifies 5 pixels of pen-down (just enough to draw the circle) and 15 pixels of pen-up. In order to have the two sequences positioned correctly the second one uses a stroke-dashoffset of 7.5 (line 14). This makes the sequence start with 12.5 pixels of white space, then a circle (which is then centered between the two line segments of the other pattern), then 15 pixels of white space, and so on.

                                                              "},{"location":"styling/ysld/cookbook/lines/#line-with-default-label","title":"Line with default label","text":"

                                                              This example shows a text label on the simple line. This is how a label will be displayed in the absence of any other customization.

                                                              Line with default label

                                                              "},{"location":"styling/ysld/cookbook/lines/#code_7","title":"Code","text":"

                                                              Download the \"Line with default label\" YSLD

                                                              name: Default Styler\ntitle: 'YSLD Cook Book: Line with default label'\nfeature-styles:\n- name: name\n  rules:\n  - symbolizers:\n    - line:\n        stroke-color: '#FF0000'\n        stroke-width: 1\n    - text:\n        label: ${name}\n        fill-color: '#000000'\n        font-family: Serif\n        font-size: 10\n        font-style: normal\n        font-weight: normal\n        placement: point\n
                                                              "},{"location":"styling/ysld/cookbook/lines/#details_7","title":"Details","text":"

                                                              In this example, there is one rule with a line symbolizer and a text symbolizer. The line symbolizer (lines 6-8) draws red lines ('#FF0000'). The text symbolizer (lines 10-17) determines the labeling of the lines. Line 10 specifies that the text of the label will be determined by the value of the \"name\" attribute for each line. (Refer to the attribute table in the Example lines layer section if necessary.) Line 11 sets the text color to black. All other details about the label are set to the renderer default, which here is Times New Roman font, font color black, and font size of 10 pixels.

                                                              "},{"location":"styling/ysld/cookbook/lines/#ysld_cookbook_lines_labelfollowingline","title":"Label following line","text":"

                                                              This example renders the text label to follow the contour of the lines.

                                                              Label following line

                                                              "},{"location":"styling/ysld/cookbook/lines/#code_8","title":"Code","text":"

                                                              Download the \"Label following line\" YSLD

                                                              title: 'YSLD Cook Book: Label following line'\nfeature-styles:\n- name: name\n  rules:\n  - symbolizers:\n    - line:\n        stroke-color: '#FF0000'\n        stroke-width: 1\n    - text:\n        label: ${name}\n        fill-color: '#000000'\n        placement: line\n        offset: 0\n        x-followLine: true\n
                                                              "},{"location":"styling/ysld/cookbook/lines/#details_8","title":"Details","text":"

                                                              As the Alternating symbols with dash offsets example showed, the default label behavior isn't optimal. The label is displayed at a tangent to the line itself, leading to uncertainty as to which label corresponds to which line.

                                                              This example is similar to the Alternating symbols with dash offsets example with the exception of lines 12-14. Line 14 sets the option to have the label follow the line, while lines 12-13 specify that the label is placed along a line. If placement: line is not specified in an YSLD, then placement: point is assumed, which isn't compatible with line-specific rendering options.

                                                              Note

                                                              Not all labels are shown due to label conflict resolution. See the next section on Optimized label placement for an example of how to maximize label display.

                                                              "},{"location":"styling/ysld/cookbook/lines/#ysld_cookbook_lines_optimizedlabel","title":"Optimized label placement","text":"

                                                              This example optimizes label placement for lines such that the maximum number of labels are displayed.

                                                              Optimized label

                                                              "},{"location":"styling/ysld/cookbook/lines/#code_9","title":"Code","text":"

                                                              Download the \"Optimized label\" YSLD

                                                              title: 'YSLD Cook Book: Optimized label placement'\nfeature-styles:\n- name: name\n  rules:\n  - symbolizers:\n    - line:\n        stroke-color: '#FF0000'\n        stroke-width: 1\n    - text:\n        label: ${name}\n        fill-color: '#000000'\n        placement: line\n        offset: 0\n        x-followLine: true\n        x-maxAngleDelta: 90\n        x-maxDisplacement: 400\n        x-repeat: 150\n
                                                              "},{"location":"styling/ysld/cookbook/lines/#details_9","title":"Details","text":"

                                                              GeoServer uses \"conflict resolution\" to ensure that labels aren't drawn on top of other labels, obscuring them both. This accounts for the reason why many lines don't have labels in the previous example, Label following line. While this setting can be toggled, it is usually a good idea to leave it on and use other label placement options to ensure that labels are drawn as often as desired and in the correct places. This example does just that.

                                                              This example is similar to the previous example, Label following line. The only differences are contained in lines 15-17. Line 15 sets the maximum angle that the label will follow. This sets the label to never bend more than 90 degrees to prevent the label from becoming illegible due to a pronounced curve or angle. Line 16 sets the maximum displacement of the label to be 400 pixels. In order to resolve conflicts with overlapping labels, GeoServer will attempt to move the labels such that they are no longer overlapping. This value sets how far the label can be moved relative to its original placement. Finally, line 17 sets the labels to be repeated every 150 pixels. A feature will typically receive only one label, but this can cause confusion for long lines. Setting the label to repeat ensures that the line is always labeled locally.

                                                              "},{"location":"styling/ysld/cookbook/lines/#ysld_cookbook_lines_optimizedstyledlabel","title":"Optimized and styled label","text":"

                                                              This example improves the style of the labels from the Optimized label placement example.

                                                              Optimized and styled label

                                                              "},{"location":"styling/ysld/cookbook/lines/#code_10","title":"Code","text":"

                                                              Download the \"Optimized and styled label\" YSLD

                                                              title: 'YSLD Cook Book: Optimized and styled label'\nfeature-styles:\n- name: name\n  rules:\n  - symbolizers:\n    - line:\n        stroke-color: '#FF0000'\n        stroke-width: 1\n    - text:\n        label: ${name}\n        fill-color: '#000000'\n        font-family: Arial\n        font-size: 10\n        font-style: normal\n        font-weight: bold\n        placement: line\n        offset: 0\n        x-followLine: true\n        x-maxAngleDelta: 90\n        x-maxDisplacement: 400\n        x-repeat: 150\n
                                                              "},{"location":"styling/ysld/cookbook/lines/#details_10","title":"Details","text":"

                                                              This example is similar to the Optimized label placement. The only difference is in the font information, which is contained in lines 12-15. Line 12 sets the font family to be \"Arial\", line 13 sets the font size to 10, line 14 sets the font style to \"normal\" (as opposed to \"italic\" or \"oblique\"), and line 15 sets the font weight to \"bold\" (as opposed to \"normal\").

                                                              "},{"location":"styling/ysld/cookbook/lines/#attribute-based-line","title":"Attribute-based line","text":"

                                                              This example styles the lines differently based on the \"type\" (Road class) attribute.

                                                              Attribute-based line

                                                              "},{"location":"styling/ysld/cookbook/lines/#code_11","title":"Code","text":"

                                                              Download the \"Attribute-based line\" YSLD

                                                              title: 'YSLD Cook Book: Attribute-based line'\nfeature-styles:\n- name: name\n  rules:\n  - name: local-road\n    filter: ${type = 'local-road'}\n    symbolizers:\n    - line:\n        stroke-color: '#009933'\n        stroke-width: 2\n- name: name\n  rules:\n  - name: secondary\n    filter: ${type = 'secondary'}\n    symbolizers:\n    - line:\n        stroke-color: '#0055CC'\n        stroke-width: 3\n- name: name\n  rules:\n  - name: highway\n    filter: ${type = 'highway'}\n    symbolizers:\n    - line:\n        stroke-color: '#FF0000'\n        stroke-width: 6\n
                                                              "},{"location":"styling/ysld/cookbook/lines/#details_11","title":"Details","text":"

                                                              Note

                                                              Refer to the Example lines layer to see the attributes for the layer. This example has eschewed labels in order to simplify the style, but you can refer to the example Optimized and styled label to see which attributes correspond to which points.

                                                              There are three types of road classes in our fictional country, ranging from back roads to high-speed freeways: \"highway\", \"secondary\", and \"local-road\". In order to handle each case separately, there is more than one feature style, each containing a single rule. This ensures that each road type is rendered in order, as each feature style is drawn based on the order in which it appears in the YSLD.

                                                              The three rules are designed as follows:

                                                              Rule order Rule name / type Color Size

                                                              1 local-road #009933 (green) 2

                                                              2 secondary #0055CC (blue) 3

                                                              3 highway #FF0000 (red) 6

                                                              Lines 3-10 comprise the first rule. Line 6 sets the filter for this rule, such that the \"type\" attribute has a value of \"local-road\". If this condition is true for a particular line, the rule is rendered according to the line symbolizer which is on lines 8-10. Lines 9-10 set the color of the line to be a dark green ('#009933') and the width to be 2 pixels.

                                                              Lines 11-18 comprise the second rule. Line 14 sets the filter for this rule, such that the \"type\" attribute has a value of \"secondary\". If this condition is true for a particular line, the rule is rendered according to the line symbolizer which is on lines 16-18. Lines 17-18 set the color of the line to be a dark blue ('#0055CC') and the width to be 3 pixels, making the lines slightly thicker than the \"local-road\" lines and also a different color.

                                                              Lines 19-26 comprise the third and final rule. Line 22 sets the filter for this rule, such that the \"type\" attribute has a value of \"primary\". If this condition is true for a particular line, the rule is rendered according to the line symbolizer which is on lines 24-26. Lines 25-26 set the color of the line to be a bright red ('#FF0000') and the width to be 6 pixels, so that these lines are rendered on top of and thicker than the other two road classes. In this way, the \"primary\" roads are given priority in the map rendering.

                                                              "},{"location":"styling/ysld/cookbook/lines/#zoom-based-line","title":"Zoom-based line","text":"

                                                              This example alters the Simple line style at different zoom levels.

                                                              Zoom-based line: Zoomed in

                                                              Zoom-based line: Partially zoomed

                                                              Zoom-based line: Zoomed out

                                                              "},{"location":"styling/ysld/cookbook/lines/#code_12","title":"Code","text":"

                                                              Download the \"Zoom-based line\" YSLD

                                                              title: 'YSLD Cook Book: Zoom-based line'\nfeature-styles:\n- name: name\n  rules:\n  - name: Large\n    scale: [min,1.8e8]\n    symbolizers:\n    - line:\n        stroke-color: '#009933'\n        stroke-width: 6\n  - name: Medium\n    scale: [1.8e8,3.6e8]\n    symbolizers:\n    - line:\n        stroke-color: '#009933'\n        stroke-width: 4\n  - name: Small\n    scale: [3.6e8,max]\n    symbolizers:\n    - line:\n        stroke-color: '#009933'\n        stroke-width: 2\n
                                                              "},{"location":"styling/ysld/cookbook/lines/#details_12","title":"Details","text":"

                                                              It is often desirable to make shapes larger at higher zoom levels when creating a natural-looking map. This example varies the thickness of the lines according to the zoom level (or more accurately, scale denominator). Scale denominators refer to the scale of the map. A scale denominator of 10,000 means the map has a scale of 1:10,000 in the units of the map projection.

                                                              Note

                                                              Determining the appropriate scale denominators (zoom levels) to use is beyond the scope of this example.

                                                              This style contains three rules. The three rules are designed as follows:

                                                              Rule order Rule name Scale denominator Line width

                                                              1 Large 1:180,000,000 or less 6

                                                              2 Medium 1:180,000,000 to 1:360,000,000 4

                                                              3 Small Greater than 1:360,000,000 2

                                                              The order of these rules does not matter since the scales denominated in each rule do not overlap.

                                                              The first rule (lines 5-10) is the smallest scale denominator, corresponding to when the view is \"zoomed in\". The scale rule is set on line 6, so that the rule will apply to any map with a scale denominator of 180,000,000 or less. Lines 9-10 draw the line to be dark green ('#009933') with a width of 6 pixels.

                                                              The second rule (lines 11-16) is the intermediate scale denominator, corresponding to when the view is \"partially zoomed\". Lines 12 set the scale such that the rule will apply to any map with scale denominators between 180,000,000 and 360,000,000. (The lower bound is inclusive and the upper bound is exclusive, so a zoom level of exactly 360,000,000 would not apply here.) Aside from the scale, the only difference between this rule and the previous is the width of the lines, which is set to 4 pixels on line 16.

                                                              The third rule (lines 17-22) is the largest scale denominator, corresponding to when the map is \"zoomed out\". The scale rule is set on line 18, so that the rule will apply to any map with a scale denominator of 360,000,000 or greater. Again, the only other difference between this rule and the others is the width of the lines, which is set to 2 pixels on line 22.

                                                              The result of this style is that lines are drawn with larger widths as one zooms in and smaller widths as one zooms out.

                                                              "},{"location":"styling/ysld/cookbook/points/","title":"Points","text":"

                                                              While points are seemingly the simplest type of shape, possessing only position and no other dimensions, there are many different ways that a point can be styled in YSLD.

                                                              "},{"location":"styling/ysld/cookbook/points/#ysld_cookbook_points_attributes","title":"Example points layer","text":"

                                                              The points layer used for the examples below contains name and population information for the major cities of a fictional country. For reference, the attribute table for the points in this layer is included below.

                                                              fid (Feature ID) name (City name) pop (Population)

                                                              point.1 Borfin 157860

                                                              point.2 Supox City 578231

                                                              point.3 Ruckis 98159

                                                              point.4 Thisland 34879

                                                              point.5 Synopolis 24567

                                                              point.6 San Glissando 76024

                                                              point.7 Detrania 205609

                                                              Download the points shapefile

                                                              "},{"location":"styling/ysld/cookbook/points/#ysld_cookbook_points_simplepoint","title":"Simple point","text":"

                                                              This example specifies points be styled as red circles with a diameter of 6 pixels.

                                                              Simple point

                                                              "},{"location":"styling/ysld/cookbook/points/#code","title":"Code","text":"

                                                              Download the \"Simple point\" YSLD

                                                              title: 'YSLD Cook Book: Simple Point'\nfeature-styles:\n- name: name\n  rules:\n  - symbolizers:\n    - point:\n        size: 6\n        symbols:\n        - mark:\n            shape: circle\n            fill-color: '#FF0000'\n
                                                              "},{"location":"styling/ysld/cookbook/points/#details","title":"Details","text":"

                                                              There is one rule in one feature style for this YSLD, which is the simplest possible situation. (All subsequent examples will contain one rule and one feature style unless otherwise specified.) Styling points is accomplished via the point symbolizer (lines 6-11). Line 10 specifies the shape of the symbol to be a circle, with line 11 determining the fill color to be red ('#FF0000'). Line 7 sets the size (diameter) of the graphic to be 6 pixels.

                                                              "},{"location":"styling/ysld/cookbook/points/#ysld_cookbook_points_simplepointwithstroke","title":"Simple point with stroke","text":"

                                                              This example adds a stroke (or border) around the Simple point, with the stroke colored black and given a thickness of 2 pixels.

                                                              Simple point with stroke

                                                              "},{"location":"styling/ysld/cookbook/points/#code_1","title":"Code","text":"

                                                              Download the \"Simple point with stroke\" YSLD

                                                              title: 'YSLD Cook Book: Simple point with stroke'\nfeature-styles:\n- name: name\n  rules:\n  - symbolizers:\n    - point:\n        size: 6\n        symbols:\n        - mark:\n            shape: circle\n            stroke-color: '#000000'\n            stroke-width: 2\n            fill-color: '#FF0000'\n
                                                              "},{"location":"styling/ysld/cookbook/points/#details_1","title":"Details","text":"

                                                              This example is similar to the Simple point example. Lines 11-12 specify the stroke, with line 11 setting the color to black ('#000000') and line 12 setting the width to 2 pixels.

                                                              "},{"location":"styling/ysld/cookbook/points/#rotated-square","title":"Rotated square","text":"

                                                              This example creates a square instead of a circle, colors it green, sizes it to 12 pixels, and rotates it by 45 degrees.

                                                              Rotated square

                                                              "},{"location":"styling/ysld/cookbook/points/#code_2","title":"Code","text":"

                                                              Download the \"Rotated square\" YSLD

                                                              title: 'YSLD Cook Book: Rotated square'\nfeature-styles:\n- name: name\n  rules:\n  - symbolizers:\n    - point:\n        size: 12\n        rotation: 45\n        symbols:\n        - mark:\n            shape: square\n            fill-color: '#009900'\n
                                                              "},{"location":"styling/ysld/cookbook/points/#details_2","title":"Details","text":"

                                                              In this example, line 11 sets the shape to be a square, with line 12 setting the color to a dark green (009900). Line 7 sets the size of the square to be 12 pixels, and line 8 sets the rotation to 45 degrees.

                                                              "},{"location":"styling/ysld/cookbook/points/#transparent-triangle","title":"Transparent triangle","text":"

                                                              This example draws a triangle, creates a black stroke identical to the Simple point with stroke example, and sets the fill of the triangle to 20% opacity (mostly transparent).

                                                              Transparent triangle

                                                              "},{"location":"styling/ysld/cookbook/points/#code_3","title":"Code","text":"

                                                              Download the \"Transparent triangle\" YSLD

                                                              title: 'YSLD Cook Book: Transparent triangle'\nfeature-styles:\n- name: name\n  rules:\n  - symbolizers:\n    - point:\n        size: 12\n        symbols:\n        - mark:\n            shape: triangle\n            stroke-color: '#000000'\n            stroke-width: 2\n            fill-color: '#009900'\n            fill-opacity: 0.2\n
                                                              "},{"location":"styling/ysld/cookbook/points/#details_3","title":"Details","text":"

                                                              In this example, line 10 once again sets the shape, in this case to a triangle. Line 13 sets the fill color to a dark green ('#009900') and line 14 sets the opacity to 0.2 (20% opaque). An opacity value of 1 means that the shape is drawn 100% opaque, while an opacity value of 0 means that the shape is drawn 0% opaque, or completely transparent. The value of 0.2 (20% opaque) means that the fill of the points partially takes on the color and style of whatever is drawn beneath it. In this example, since the background is white, the dark green looks lighter. Were the points imposed on a dark background, the resulting color would be darker. Lines 11-12 set the stroke color to black ('#000000') and width to 2 pixels. Finally, line 7 sets the size of the point to be 12 pixels in diameter.

                                                              "},{"location":"styling/ysld/cookbook/points/#point-as-graphic","title":"Point as graphic","text":"

                                                              This example styles each point as a graphic instead of as a simple shape.

                                                              Point as graphic

                                                              "},{"location":"styling/ysld/cookbook/points/#code_4","title":"Code","text":"

                                                              Download the \"Point as graphic\" YSLD

                                                              title: 'YSLD Cook Book: Point as graphic'\nfeature-styles:\n- name: name\n  rules:\n  - symbolizers:\n    - point:\n        size: 32\n        symbols:\n        - external:\n            url: smileyface.png\n            format: image/png\n
                                                              "},{"location":"styling/ysld/cookbook/points/#details_4","title":"Details","text":"

                                                              This style uses a graphic instead of a simple shape to render the points. In YSLD, this is known as an external, to distinguish it from the commonly-used shapes such as squares and circles that are \"internal\" to the renderer. Lines 9-11 specify the details of this graphic. Line 10 sets the path and file name of the graphic, while line 11 indicates the format (MIME type) of the graphic (image/png). In this example, the graphic is contained in the same directory as the YSLD, so no path information is necessary in line 10, although a full URL could be used if desired. Line 7 determines the size of the displayed graphic; this can be set independently of the dimensions of the graphic itself, although in this case they are the same (32 pixels). Should a graphic be rectangular, the size value will apply to the height of the graphic only, with the width scaled proportionally.

                                                              Graphic used for points

                                                              "},{"location":"styling/ysld/cookbook/points/#ysld_cookbook_points_pointwithdefaultlabel","title":"Point with default label","text":"

                                                              This example shows a text label on the Simple point that displays the \"name\" attribute of the point. This is how a label will be displayed in the absence of any other customization.

                                                              Point with default label

                                                              "},{"location":"styling/ysld/cookbook/points/#code_5","title":"Code","text":"

                                                              Download the \"Point with default label\" YSLD

                                                              title: 'YSLD Cook Book: Point with default label'\nfeature-styles:\n- name: name\n  rules:\n  - symbolizers:\n    - point:\n        size: 6\n        symbols:\n        - mark:\n            shape: circle\n            fill-color: '#FF0000'\n    - text:\n        label: ${name}\n        fill-color: '#000000'\n        font-family: Serif\n        font-size: 10\n        font-style: normal\n        font-weight: normal\n        placement: point\n
                                                              "},{"location":"styling/ysld/cookbook/points/#details_5","title":"Details","text":"

                                                              Lines 2-11, which contain the point symbolizer, are identical to the Simple point example above. The label is set in the text symbolizer on lines 12-19. Line 13 determines what text to display in the label, which in this case is the value of the \"name\" attribute. (Refer to the attribute table in the Example points layer section if necessary.) Line 15 sets the text color. All other details about the label are set to the renderer default, which here is Times New Roman font, font color black, and font size of 10 pixels. The bottom left of the label is aligned with the center of the point.

                                                              "},{"location":"styling/ysld/cookbook/points/#ysld_cookbook_points_pointwithstyledlabel","title":"Point with styled label","text":"

                                                              This example improves the label style from the Point with default label example by centering the label above the point and providing a different font name and size.

                                                              Point with styled label

                                                              "},{"location":"styling/ysld/cookbook/points/#code_6","title":"Code","text":"

                                                              Download the \"Point with styled label\" YSLD

                                                              title: 'YSLD Cook Book: Point with styled label'\nfeature-styles:\n- name: name\n  rules:\n  - symbolizers:\n    - point:\n        size: 6\n        symbols:\n        - mark:\n            shape: circle\n            fill-color: '#FF0000'\n    - text:\n        label: ${name}\n        fill-color: '#000000'\n        font-family: Arial\n        font-size: 12\n        font-style: normal\n        font-weight: bold\n        placement: point\n        anchor: [0.5,0.0]\n        displacement: [0,5]\n
                                                              "},{"location":"styling/ysld/cookbook/points/#details_6","title":"Details","text":"

                                                              In this example, lines 2-11 are identical to the Simple point example above. The <TextSymbolizer> on lines 12-21 contains many more details about the label styling than the previous example, Point with default label. Line 13 once again specifies the \"name\" attribute as text to display. Lines 15-18 set the font information: line 15 sets the font family to be \"Arial\", line 16 sets the font size to 12, line 17 sets the font style to \"normal\" (as opposed to \"italic\" or \"oblique\"), and line 18 sets the font weight to \"bold\" (as opposed to \"normal\"). Lines 19-21 determine the placement of the label relative to the point. The anchor (line 20) sets the point of intersection between the label and point, which here sets the point to be centered (0.5) horizontally axis and bottom aligned (0.0) vertically with the label. There is also displacement (line 21), which sets the offset of the label relative to the line, which in this case is 0 pixels horizontally and 5 pixels vertically . Finally, line 14 sets the font color of the label to black ('#000000').

                                                              The result is a centered bold label placed slightly above each point.

                                                              "},{"location":"styling/ysld/cookbook/points/#point-with-rotated-label","title":"Point with rotated label","text":"

                                                              This example builds on the previous example, Point with styled label, by rotating the label by 45 degrees, positioning the labels farther away from the points, and changing the color of the label to purple.

                                                              Point with rotated label

                                                              "},{"location":"styling/ysld/cookbook/points/#code_7","title":"Code","text":"

                                                              Download the \"Point with rotated label\" YSLD

                                                              title: 'YSLD Cook Book: Point with rotated label'\nfeature-styles:\n- name: name\n  rules:\n  - symbolizers:\n    - point:\n        size: 6\n        symbols:\n        - mark:\n            shape: circle\n            fill-color: '#FF0000'\n    - text:\n        label: ${name}\n        fill-color: '#990099'\n        font-family: Arial\n        font-size: 12\n        font-style: normal\n        font-weight: bold\n        placement: point\n        anchor: [0.5,0.0]\n        displacement: [0,25]\n        rotation: -45\n
                                                              "},{"location":"styling/ysld/cookbook/points/#details_7","title":"Details","text":"

                                                              This example is similar to the Point with styled label, but there are three important differences. Line 21 specifies 25 pixels of vertical displacement. Line 22 specifies a rotation of \"-45\" or 45 degrees counter-clockwise. (Rotation values increase clockwise, which is why the value is negative.) Finally, line 14 sets the font color to be a shade of purple ('#99099').

                                                              Note that the displacement takes effect before the rotation during rendering, so in this example, the 25 pixel vertical displacement is itself rotated 45 degrees.

                                                              "},{"location":"styling/ysld/cookbook/points/#attribute-based-point","title":"Attribute-based point","text":"

                                                              This example alters the size of the symbol based on the value of the population (\"pop\") attribute.

                                                              Attribute-based point

                                                              "},{"location":"styling/ysld/cookbook/points/#code_8","title":"Code","text":"

                                                              Download the \"Attribute-based point\" YSLD

                                                              title: 'YSLD Cook Book: Attribute-based point'\nfeature-styles:\n- name: name\n  rules:\n  - name: SmallPop\n    title: 1 to 50000\n    filter: ${pop < '50000'}\n    symbolizers:\n    - point:\n        size: 8\n        symbols:\n        - mark:\n            shape: circle\n            fill-color: '#0033CC'\n  - name: MediumPop\n    title: 50000 to 100000\n    filter: ${pop >= '50000' AND pop < '100000'}\n    symbolizers:\n    - point:\n        size: 12\n        symbols:\n        - mark:\n            shape: circle\n            fill-color: '#0033CC'\n  - name: LargePop\n    title: Greater than 100000\n    filter: ${pop >= '100000'}\n    symbolizers:\n    - point:\n        size: 16\n        symbols:\n        - mark:\n            shape: circle\n            fill-color: '#0033CC'\n
                                                              "},{"location":"styling/ysld/cookbook/points/#details_8","title":"Details","text":"

                                                              Note

                                                              Refer to the Example points layer to see the attributes for this data. This example has eschewed labels in order to simplify the style, but you can refer to the example Point with styled label to see which attributes correspond to which points.

                                                              This style contains three rules. Each rule varies the style based on the value of the population (\"pop\") attribute for each point, with smaller values yielding a smaller circle, and larger values yielding a larger circle.

                                                              The three rules are designed as follows:

                                                              Rule order Rule name Population (pop) Size

                                                              1 SmallPop Less than 50,000 8

                                                              2 MediumPop 50,000 to 100,000 12

                                                              3 LargePop Greater than 100,000 16

                                                              The order of the rules does not matter in this case, since each shape is only rendered by a single rule.

                                                              The first rule, on lines 5-14, specifies the styling of those points whose population attribute is less than 50,000. Line 7 sets this filter, denoting the attribute (\"pop\") to be \"less than\" the value of 50,000. The symbol is a circle (line 13), the color is dark blue ('#0033CC', on line 15), and the size is 8 pixels in diameter (line 18).

                                                              The second rule, on lines 15-24, specifies a style for points whose population attribute is greater than or equal to 50,000 and less than 100,000. The population filter is set on line 17. This filter specifies two criteria instead of one: a \"greater than or equal to\" and a \"less than\" filter. These criteria are joined by AND, which mandates that both filters need to be true for the rule to be applicable. The size of the graphic is set to 12 pixels on line 20. All other styling directives are identical to the first rule.

                                                              The third rule, on lines 25-34, specifies a style for points whose population attribute is greater than or equal to 100,000. The population filter is set on line 27, and the only other difference is the size of the circle, which in this rule (line 30) is 16 pixels.

                                                              The result of this style is that cities with larger populations have larger points.

                                                              "},{"location":"styling/ysld/cookbook/points/#zoom-based-point","title":"Zoom-based point","text":"

                                                              This example alters the style of the points at different zoom levels.

                                                              Zoom-based point: Zoomed in

                                                              Zoom-based point: Partially zoomed

                                                              Zoom-based point: Zoomed out

                                                              "},{"location":"styling/ysld/cookbook/points/#code_9","title":"Code","text":"

                                                              Download the \"Zoom-based point\" YSLD

                                                              title: 'YSLD Cook Book: Zoom-based point'\nfeature-styles:\n- name: name\n  rules:\n  - name: Large\n    scale: [min,1.6e8]\n    symbolizers:\n    - point:\n        size: 12\n        symbols:\n        - mark:\n            shape: circle\n            fill-color: '#CC3300'\n  - name: Medium\n    scale: [1.6e8,3.2e8]\n    symbolizers:\n    - point:\n        size: 8\n        symbols:\n        - mark:\n            shape: circle\n            fill-color: '#CC3300'\n  - name: Small\n    scale: [3.2e8,max]\n    symbolizers:\n    - point:\n        size: 4\n        symbols:\n        - mark:\n            shape: circle\n            fill-color: '#CC3300'\n
                                                              "},{"location":"styling/ysld/cookbook/points/#details_9","title":"Details","text":"

                                                              It is often desirable to make shapes larger at higher zoom levels when creating a natural-looking map. This example styles the points to vary in size based on the zoom level (or more accurately, scale denominator). Scale denominators refer to the scale of the map. A scale denominator of 10,000 means the map has a scale of 1:10,000 in the units of the map projection.

                                                              Note

                                                              Determining the appropriate scale denominators (zoom levels) to use is beyond the scope of this example.

                                                              This style contains three rules. The three rules are designed as follows:

                                                              Rule order Rule name Scale denominator Point size

                                                              1 Large 1:160,000,000 or less 12

                                                              2 Medium 1:160,000,000 to 1:320,000,000 8

                                                              3 Small Greater than 1:320,000,000 4

                                                              The order of these rules does not matter since the scales denominated in each rule do not overlap.

                                                              The first rule (lines 5-13) is for the smallest scale denominator, corresponding to when the view is \"zoomed in\". The scale rule is set on line 6, so that the rule will apply to any map with a scale denominator of 160,000,000 or less. The rule draws a circle (line 12), colored red (#CC3300 on line 13) with a size of 12 pixels (line 9).

                                                              The second rule (lines 14-22) is the intermediate scale denominator, corresponding to when the view is \"partially zoomed\". The scale rules is set on line 15, so that the rule will apply to any map with a scale denominator between 160,000,000 and 320,000,000. (The lower bound is inclusive and the upper bound is exclusive, so a zoom level of exactly 320,000,000 would not apply here.) Aside from the scale, the only difference between this rule and the first is the size of the symbol, which is set to 8 pixels on line 18.

                                                              The third rule (lines 23-31) is the largest scale denominator, corresponding to when the map is \"zoomed out\". The scale rule is set on line 24, so that the rule will apply to any map with a scale denominator of 320,000,000 or more. Again, the only other difference between this rule and the others is the size of the symbol, which is set to 4 pixels on line 27.

                                                              The result of this style is that points are drawn larger as one zooms in and smaller as one zooms out.

                                                              "},{"location":"styling/ysld/cookbook/polygons/","title":"Polygons","text":"

                                                              Polygons are two dimensional shapes that contain both an outer edge (or \"stroke\") and an inside (or \"fill\"). A polygon can be thought of as an irregularly-shaped point and is styled in similar ways to points.

                                                              "},{"location":"styling/ysld/cookbook/polygons/#ysld_cookbook_polygons_attributes","title":"Example polygons layer","text":"

                                                              The polygons layer used below contains county information for a fictional country. For reference, the attribute table for the polygons is included below.

                                                              fid (Feature ID) name (County name) pop (Population)

                                                              polygon.1 Irony County 412234

                                                              polygon.2 Tracker County 235421

                                                              polygon.3 Dracula County 135022

                                                              polygon.4 Poly County 1567879

                                                              polygon.5 Bearing County 201989

                                                              polygon.6 Monte Cristo County 152734

                                                              polygon.7 Massive County 67123

                                                              polygon.8 Rhombus County 198029

                                                              Download the polygons shapefile

                                                              "},{"location":"styling/ysld/cookbook/polygons/#ysld_cookbook_polygons_simplepolygon","title":"Simple polygon","text":"

                                                              This example shows a polygon filled in blue.

                                                              Simple polygon

                                                              "},{"location":"styling/ysld/cookbook/polygons/#code","title":"Code","text":"

                                                              Download the \"Simple polygon\" YSLD

                                                              title: 'YSLD Cook Book: Simple polygon'\nfeature-styles:\n- name: name\n  rules:\n  - symbolizers:\n    - polygon:\n        fill-color: '#000080'\n
                                                              "},{"location":"styling/ysld/cookbook/polygons/#details","title":"Details","text":"

                                                              There is one rule in one feature style for this style, which is the simplest possible situation. (All subsequent examples will share this characteristic unless otherwise specified.) Styling polygons is accomplished via the polygon symbolizer (lines 6-7). Line 7 specifies dark blue ('#000080') as the polygon's fill color.

                                                              Note

                                                              The light-colored borders around the polygons in the figure are artifacts of the renderer caused by the polygons being adjacent. There is no border in this style.

                                                              "},{"location":"styling/ysld/cookbook/polygons/#ysld_cookbook_polygons_simplepolygonwithstroke","title":"Simple polygon with stroke","text":"

                                                              This example adds a 2 pixel white stroke to the Simple polygon example.

                                                              Simple polygon with stroke

                                                              "},{"location":"styling/ysld/cookbook/polygons/#code_1","title":"Code","text":"

                                                              Download the \"Simple polygon with stroke\" YSLD

                                                              title: 'YSLD Cook Book: Simple polygon with stroke'\nfeature-styles:\n- name: name\n  rules:\n  - symbolizers:\n    - polygon:\n        stroke-color: '#FFFFFF'\n        stroke-width: 2\n        fill-color: '#000080'\n
                                                              "},{"location":"styling/ysld/cookbook/polygons/#details_1","title":"Details","text":"

                                                              This example is similar to the Simple polygon example above, with the addition of stroke parameters (lines 7-8). Line 7 sets the color of stroke to white ('#FFFFFF') and line 8 sets the width of the stroke to 2 pixels.

                                                              "},{"location":"styling/ysld/cookbook/polygons/#transparent-polygon","title":"Transparent polygon","text":"

                                                              This example builds on the Simple polygon with stroke example and makes the fill partially transparent by setting the opacity to 50%.

                                                              Transparent polygon

                                                              "},{"location":"styling/ysld/cookbook/polygons/#code_2","title":"Code","text":"

                                                              Download the \"Transparent polygon\" YSLD

                                                              title: 'YSLD Cook Book: Transparent polygon'\nfeature-styles:\n- name: name\n  rules:\n  - symbolizers:\n    - polygon:\n        stroke-color: '#FFFFFF'\n        stroke-width: 2\n        fill-color: '#000080'\n        fill-opacity: 0.5\n
                                                              "},{"location":"styling/ysld/cookbook/polygons/#details_2","title":"Details","text":"

                                                              This example is similar to the Simple polygon with stroke example, save for defining the fill's opacity in line 10. The value of 0.5 results in partially transparent fill that is 50% opaque. An opacity value of 1 would draw the fill as 100% opaque, while an opacity value of 0 would result in a completely transparent (0% opaque) fill. In this example, since the background is white, the dark blue looks lighter. Were the points imposed on a dark background, the resulting color would be darker.

                                                              "},{"location":"styling/ysld/cookbook/polygons/#ysld_cookbook_polygons_graphicfill","title":"Graphic fill","text":"

                                                              This example fills the polygons with a tiled graphic.

                                                              Graphic fill

                                                              "},{"location":"styling/ysld/cookbook/polygons/#code_3","title":"Code","text":"

                                                              Download the \"Graphic fill\" YSLD

                                                              title: 'YSLD Cook Book: Graphic fill'\nfeature-styles:\n- name: name\n  rules:\n  - symbolizers:\n    - polygon:\n        fill-color: '#808080'\n        fill-graphic:\n          size: 93\n          symbols:\n          - external:\n              url: colorblocks.png\n              format: image/png\n
                                                              "},{"location":"styling/ysld/cookbook/polygons/#details_3","title":"Details","text":"

                                                              This style fills the polygon with a tiled graphic. This is known as an external in YSLD, to distinguish it from commonly-used shapes such as squares and circles that are \"internal\" to the renderer. Lines 11-13 specify details for the graphic, with line 12 setting the path and file name of the graphic and line 13 indicating the file format (MIME type) of the graphic (image/png). Although a full URL could be specified if desired, no path information is necessary in line 12 because this graphic is contained in the same directory as the YSLD. Line 9 determines the height of the displayed graphic in pixels; if the value differs from the height of the graphic then it will be scaled accordingly while preserving the aspect ratio.

                                                              Graphic used for fill

                                                              "},{"location":"styling/ysld/cookbook/polygons/#hatching-fill","title":"Hatching fill","text":"

                                                              This example fills the polygons with a hatching pattern.

                                                              Hatching fill

                                                              "},{"location":"styling/ysld/cookbook/polygons/#code_4","title":"Code","text":"

                                                              Download the \"Hatching fill\" YSLD

                                                              title: 'YSLD Cook Book: Hatching fill'\nfeature-styles:\n- name: name\n  rules:\n  - symbolizers:\n    - polygon:\n        fill-color: '#808080'\n        fill-graphic:\n          size: 16\n          symbols:\n          - mark:\n              shape: shape://times\n              stroke-color: '#990099'\n              stroke-width: 1\n
                                                              "},{"location":"styling/ysld/cookbook/polygons/#details_4","title":"Details","text":"

                                                              In this example, there is a fill-graphic parameter as in the Graphic fill example, but a mark (lines 11-14) is used instead of an external. Line 12 specifies a \"times\" symbol (an \"x\") be tiled throughout the polygon. Line 13 sets the color to purple ('#990099'), line 14 sets the width of the hatches to 1 pixel, and line 9 sets the size of the tile to 16 pixels. Because hatch tiles are always square, the size sets both the width and the height.

                                                              "},{"location":"styling/ysld/cookbook/polygons/#ysld_cookbook_polygons_polygonwithdefaultlabel","title":"Polygon with default label","text":"

                                                              This example shows a text label on the polygon. In the absence of any other customization, this is how a label will be displayed.

                                                              Polygon with default label

                                                              "},{"location":"styling/ysld/cookbook/polygons/#code_5","title":"Code","text":"

                                                              Download the \"Polygon with default label\" YSLD

                                                              title: 'YSLD Cook Book: Polygon with default label'\nfeature-styles:\n- name: name\n  rules:\n  - symbolizers:\n    - polygon:\n        stroke-color: '#FFFFFF'\n        stroke-width: 2\n        fill-color: '#40FF40'\n    - text:\n        label: ${name}\n        placement: point\n
                                                              "},{"location":"styling/ysld/cookbook/polygons/#details_5","title":"Details","text":"

                                                              In this example there is a polygon symbolizer and a text symbolizer. Lines 6-9 comprise the polygon symbolizer. The fill of the polygon is set on line 7 to a light green ('#40FF40') while the stroke of the polygon is set on lines 8-9 to white ('#FFFFFF') with a thickness of 2 pixels. The label is set in the text symbolizer on lines 10-12, with line 11 determining what text to display, in this case the value of the \"name\" attribute. (Refer to the attribute table in the Example polygons layer section if necessary.) All other details about the label are set to the renderer default, which here is Times New Roman font, font color black, and font size of 10 pixels.

                                                              "},{"location":"styling/ysld/cookbook/polygons/#label-halo","title":"Label halo","text":"

                                                              This example alters the look of the Polygon with default label by adding a white halo to the label.

                                                              Label halo

                                                              "},{"location":"styling/ysld/cookbook/polygons/#code_6","title":"Code","text":"

                                                              Download the \"Label halo\" YSLD

                                                              title: 'YSLD Cook Book: Label halo'\nfeature-styles:\n- name: name\n  rules:\n  - symbolizers:\n    - polygon:\n        stroke-color: '#FFFFFF'\n        stroke-width: 2\n        fill-color: '#40FF40'\n    - text:\n        label: ${name}\n        halo:\n          fill-color: '#FFFFFF'\n          radius: 3\n        placement:\n          type: point\n
                                                              "},{"location":"styling/ysld/cookbook/polygons/#details_6","title":"Details","text":"

                                                              This example is similar to the Polygon with default label, with the addition of a halo around the labels on lines 12-14. A halo creates a color buffer around the label to improve label legibility. Line 14 sets the radius of the halo, extending the halo 3 pixels around the edge of the label, and line 13 sets the color of the halo to white ('#FFFFFF'). Since halos are most useful when set to a sharp contrast relative to the text color, this example uses a white halo around black text to ensure optimum readability.

                                                              "},{"location":"styling/ysld/cookbook/polygons/#ysld_cookbook_polygons_polygonwithstyledlabel","title":"Polygon with styled label","text":"

                                                              This example improves the label style from the Polygon with default label example by centering the label on the polygon, specifying a different font name and size, and setting additional label placement optimizations.

                                                              Polygon with styled label

                                                              "},{"location":"styling/ysld/cookbook/polygons/#code_7","title":"Code","text":"

                                                              Download the \"Polygon with styled label\" YSLD

                                                              title: 'YSLD Cook Book: Polygon with styled label'\nfeature-styles:\n- name: name\n  rules:\n  - symbolizers:\n    - polygon:\n        stroke-color: '#FFFFFF'\n        stroke-width: 2\n        fill-color: '#40FF40'\n    - text:\n        label: ${name}\n        fill-color: '#000000'\n        font-family: Arial\n        font-size: 11\n        font-style: normal\n        font-weight: bold\n        placement: point\n        anchor: [0.5,0.5]\n        x-autoWrap: 60\n        x-maxDisplacement: 150\n
                                                              "},{"location":"styling/ysld/cookbook/polygons/#details_7","title":"Details","text":"

                                                              This example is similar to the Polygon with default label example, with additional styling options within the text symbolizer on lines 13-21. Lines 13-16 set the font styling. Line 13 sets the font family to be Arial, line 14 sets the font size to 11 pixels, line 15 sets the font style to \"normal\" (as opposed to \"italic\" or \"oblique\"), and line 16 sets the font weight to \"bold\" (as opposed to \"normal\").

                                                              The anchor parameter on line 18 centers the label by positioning it 50% (or 0.5) of the way horizontally and vertically along the centroid of the polygon.

                                                              Finally, there are two added touches for label placement optimization: line 20 ensures that long labels are split across multiple lines by setting line wrapping on the labels to 60 pixels, and line 21 allows the label to be displaced by up to 150 pixels. This ensures that labels are compacted and less likely to spill over polygon boundaries. Notice little Massive County in the corner, whose label is now displayed.\"

                                                              "},{"location":"styling/ysld/cookbook/polygons/#attribute-based-polygon","title":"Attribute-based polygon","text":"

                                                              This example styles the polygons differently based on the \"pop\" (Population) attribute.

                                                              Attribute-based polygon

                                                              "},{"location":"styling/ysld/cookbook/polygons/#code_8","title":"Code","text":"

                                                              Download the \"Attribute-based polygon\" YSLD

                                                              title: 'YSLD Cook Book: Attribute-based polygon'\nfeature-styles:\n- name: name\n  rules:\n  - name: SmallPop\n    title: Less Than 200,000\n    filter: ${pop < '200000'}\n    symbolizers:\n    - polygon:\n        fill-color: '#66FF66'\n  - name: MediumPop\n    title: 200,000 to 500,000\n    filter: ${pop >= '200000' AND pop < '500000'}\n    symbolizers:\n    - polygon:\n        fill-color: '#33CC33'\n  - name: LargePop\n    title: ${Greater Than 500,000}\n    filter: pop > '500000'\n    symbolizers:\n    - polygon:\n        fill-color: '#009900'\n
                                                              "},{"location":"styling/ysld/cookbook/polygons/#details_8","title":"Details","text":"

                                                              Note

                                                              Refer to the Example polygons layer to see the attributes for the layer. This example has eschewed labels in order to simplify the style, but you can refer to the example Polygon with styled label to see which attributes correspond to which polygons.

                                                              Each polygon in our fictional country has a population that is represented by the population (\"pop\") attribute. This style contains three rules that alter the fill based on the value of \"pop\" attribute, with smaller values yielding a lighter color and larger values yielding a darker color.

                                                              The three rules are designed as follows:

                                                              Rule order Rule name Population (pop) Color

                                                              1 SmallPop Less than 200,000 #66FF66

                                                              2 MediumPop 200,000 to 500,000 #33CC33

                                                              3 LargePop Greater than 500,000 #009900

                                                              The order of the rules does not matter in this case, since each shape is only rendered by a single rule.

                                                              The first rule, on lines 5-10, specifies the styling of polygons whose population attribute is less than 200,000. Line 7 sets this filter, denoting the attribute (\"pop\"), to be \"less than\" the value of 200,000. The color of the polygon fill is set to a light green ('#66FF66') on line 10.

                                                              The second rule, on lines 11-16, is similar, specifying a style for polygons whose population attribute is greater than or equal to 200,000 but less than 500,000. The filter is set on line 13. This filter specifies two criteria instead of one: a \"greater than or equal to\" and a \"less than\" filter. These criteria are joined by AND, which mandates that both filters need to be true for the rule to be applicable. The color of the polygon fill is set to a medium green on ('#33CC33') on line 16.

                                                              The third rule, on lines 17-22, specifies a style for polygons whose population attribute is greater than or equal to 500,000. The filter is set on line 19. The color of the polygon fill is the only other difference in this rule, which is set to a dark green ('#009900') on line 22.

                                                              "},{"location":"styling/ysld/cookbook/polygons/#zoom-based-polygon","title":"Zoom-based polygon","text":"

                                                              This example alters the style of the polygon at different zoom levels.

                                                              Zoom-based polygon: Zoomed in

                                                              Zoom-based polygon: Partially zoomed

                                                              Zoom-based polygon: Zoomed out

                                                              "},{"location":"styling/ysld/cookbook/polygons/#code_9","title":"Code","text":"

                                                              Download the \"Zoom-based polygon\" YSLD

                                                              title: 'YSLD Cook Book: Zoom-based polygon'\nfeature-styles:\n- name: name\n  rules:\n  - name: Large\n    scale: [min,1.0e8]\n    symbolizers:\n    - polygon:\n        stroke-color: '#000000'\n        stroke-width: 7\n        fill-color: '#0000CC'\n    - text:\n        label: ${name}\n        fill-color: '#FFFFFF'\n        font-family: Arial\n        font-size: 14\n        font-style: normal\n        font-weight: bold\n        placement: point\n        anchor: [0.5,0.5]\n  - name: Medium\n    scale: [1.0e8,2.0e8]\n    symbolizers:\n    - polygon:\n        stroke-color: '#000000'\n        stroke-width: 4\n        fill-color: '#0000CC'\n  - name: Small\n    scale: [2.0e8,max]\n    symbolizers:\n    - polygon:\n        stroke-color: '#000000'\n        stroke-width: 1\n        fill-color: '#0000CC'\n
                                                              "},{"location":"styling/ysld/cookbook/polygons/#details_9","title":"Details","text":"

                                                              It is often desirable to make shapes larger at higher zoom levels when creating a natural-looking map. This example varies the thickness of the lines according to the zoom level. Polygons already do this by nature of being two dimensional, but another way to adjust styling of polygons based on zoom level is to adjust the thickness of the stroke (to be larger as the map is zoomed in) or to limit labels to only certain zoom levels. This is ensures that the size and quantity of strokes and labels remains legible and doesn't overshadow the polygons themselves.

                                                              Zoom levels (or more accurately, scale denominators) refer to the scale of the map. A scale denominator of 10,000 means the map has a scale of 1:10,000 in the units of the map projection.

                                                              Note

                                                              Determining the appropriate scale denominators (zoom levels) to use is beyond the scope of this example.

                                                              This style contains three rules, defined as follows:

                                                              Rule order Rule name Scale denominator Stroke width Label display?

                                                              1 Large 1:100,000,000 or less 7 Yes

                                                              2 Medium 1:100,000,000 to 1:200,000,000 4 No

                                                              3 Small Greater than 1:200,000,000 2 No

                                                              The first rule, on lines 5-20, is for the smallest scale denominator, corresponding to when the view is \"zoomed in\". The scale rule is set on line 6 such that the rule will apply only where the scale denominator is 100,000,000 or less. Line 11 defines the fill as blue ('#0000CC'). Note that the fill is kept constant across all rules regardless of the scale denominator. As in the Polygon with default label or Polygon with styled label examples, the rule also contains a text symbolizer at lines 12-20 for drawing a text label on top of the polygon. Lines 15-18 set the font information to be Arial, 14 pixels, and bold with no italics. The label is centered both horizontally and vertically along the centroid of the polygon on by setting anchor to be [0.5, 0.5] (or 50%) on line 20. Finally, the color of the font is set to white ('#FFFFFF') in line 14.

                                                              The second rule, on lines 21-27, is for the intermediate scale denominators, corresponding to when the view is \"partially zoomed\". The scale rules on lines 22 set the rule such that it will apply to any map with a scale denominator between 100,000,000 and 200,000,000. (The lower bound is inclusive and the upper bound is exclusive, so a zoom level of exactly 200,000,000 would not apply here.) Aside from the scale, there are two differences between this rule and the first: the width of the stroke is set to 4 pixels on line 26 and a text symbolizer is not present so that no labels will be displayed.

                                                              The third rule, on lines 28-34, is for the largest scale denominator, corresponding to when the map is \"zoomed out\". The scale rule is set on line 29 such that the rule will apply to any map with a scale denominator of 200,000,000 or greater. Again, the only differences between this rule and the others are the width of the lines, which is set to 1 pixel on line 33, and the absence of a text symbolizer so that no labels will be displayed.

                                                              The resulting style produces a polygon stroke that gets larger as one zooms in and labels that only display when zoomed in to a sufficient level.

                                                              "},{"location":"styling/ysld/cookbook/rasters/","title":"Rasters","text":"

                                                              Rasters are geographic data displayed in a grid. They are similar to image files such as PNG files, except that instead of each point containing visual information, each point contains geographic information in numerical form. Rasters can be thought of as a georeferenced table of numerical values.

                                                              One example of a raster is a Digital Elevation Model (DEM) layer, which has elevation data encoded numerically at each georeferenced data point.

                                                              "},{"location":"styling/ysld/cookbook/rasters/#example-raster","title":"Example raster","text":"

                                                              The raster layer that is used in the examples below contains elevation data for a fictional world. The data is stored in EPSG:4326 (longitude/latitude) and has a data range from 70 to 256. If rendered in grayscale, where minimum values are colored black and maximum values are colored white, the raster would look like this:

                                                              Raster file as rendered in grayscale

                                                              Download the raster shapefile

                                                              "},{"location":"styling/ysld/cookbook/rasters/#ysld_cookbook_raster_twocolorgradient","title":"Two-color gradient","text":"

                                                              This example shows a two-color style with green at lower elevations and brown at higher elevations.

                                                              Two-color gradient

                                                              "},{"location":"styling/ysld/cookbook/rasters/#code","title":"Code","text":"

                                                              Download the \"Two-color gradient\" YSLD

                                                              title: 'YSLD Cook Book: Two color gradient'\nfeature-styles:\n- name: name\n  rules:\n  - symbolizers:\n    - raster:\n        opacity: 1.0\n        color-map:\n          type: ramp\n          entries:\n          - ['#008000',1,70,'']\n          - ['#663333',1,256,'']\n
                                                              "},{"location":"styling/ysld/cookbook/rasters/#details","title":"Details","text":"

                                                              There is one rule in one feature style for this example, which is the simplest possible situation. All subsequent examples will share this characteristic. Styling of rasters is done via the raster symbolizer (lines 2-7).

                                                              This example creates a smooth gradient between two colors corresponding to two elevation values. The gradient is created via the color-map on lines 8-12. Each entry in the color-map represents one entry or anchor in the gradient. Line 11 sets the lower value of 70 and color to a dark green ('#008000'). Line 12 sets the upper value of 256 and color to a dark brown ('#663333'). Line 9 sets the type to ramp, which means that all data values in between these two quantities will be linearly interpolated: a value of 163 (the midpoint between 70 and 256) will be colored as the midpoint between the two colors (in this case approximately '#335717', a muddy green).

                                                              "},{"location":"styling/ysld/cookbook/rasters/#transparent-gradient","title":"Transparent gradient","text":"

                                                              This example creates the same two-color gradient as in the Two-color gradient as in the example above but makes the entire layer mostly transparent by setting a 30% opacity.

                                                              Transparent gradient

                                                              "},{"location":"styling/ysld/cookbook/rasters/#code_1","title":"Code","text":"

                                                              Download the \"Transparent gradient\" YSLD

                                                              title: 'YSLD Cook Book: Transparent gradient'\nfeature-styles:\n- name: name\n  rules:\n  - symbolizers:\n    - raster:\n        opacity: 0.3\n        color-map:\n          type: ramp\n          entries:\n          - ['#008000',1,70,'']\n          - ['#663333',1,256,'']\n
                                                              "},{"location":"styling/ysld/cookbook/rasters/#details_1","title":"Details","text":"

                                                              This example is similar to the Two-color gradient example save for the addition of line 7, which sets the opacity of the layer to 0.3 (or 30% opaque). An opacity value of 1 means that the shape is drawn 100% opaque, while an opacity value of 0 means that the shape is rendered as completely transparent. The value of 0.3 means that the raster partially takes on the color and style of whatever is drawn beneath it. Since the background is white in this example, the colors generated from the color-map look lighter, but were the raster imposed on a dark background the resulting colors would be darker.

                                                              "},{"location":"styling/ysld/cookbook/rasters/#brightness-and-contrast","title":"Brightness and contrast","text":"

                                                              This example normalizes the color output and then increases the brightness by a factor of 2.

                                                              Brightness and contrast

                                                              "},{"location":"styling/ysld/cookbook/rasters/#code_2","title":"Code","text":"

                                                              Download the \"Brightness and contrast\" YSLD

                                                              title: 'YSLD Cook Book: Brightness and contrast'\nfeature-styles:\n- name: name\n  rules:\n  - symbolizers:\n    - raster:\n        opacity: 1\n        color-map:\n          type: ramp\n          entries:\n          - ['#008000',1,70,'']\n          - ['#663333',1,256,'']\n        contrast-enhancement:\n          mode: normalize\n          gamma: 0.5\n
                                                              "},{"location":"styling/ysld/cookbook/rasters/#details_2","title":"Details","text":"

                                                              This example is similar to the Two-color gradient, save for the addition of the contrast-enhancement parameter on lines 13-15. Line 14 normalizes the output by increasing the contrast to its maximum extent. Line 15 then adjusts the brightness by a factor of 0.5. Since values less than 1 make the output brighter, a value of 0.5 makes the output twice as bright.

                                                              As with previous examples, lines 8-12 determine the color-map, with line 11 setting the lower bound (70) to be colored dark green ('#008000') and line 12 setting the upper bound (256) to be colored dark brown ('#663333').

                                                              "},{"location":"styling/ysld/cookbook/rasters/#three-color-gradient","title":"Three-color gradient","text":"

                                                              This example creates a three-color gradient in primary colors.

                                                              Three-color gradient

                                                              "},{"location":"styling/ysld/cookbook/rasters/#code_3","title":"Code","text":"

                                                              Download the \"Three-color gradient\" YSLD

                                                              title: 'YSLD Cook Book: Three color gradient'\nfeature-styles:\n- name: name\n  rules:\n  - symbolizers:\n    - raster:\n        opacity: 1\n        color-map:\n          type: ramp\n          entries:\n          - ['#0000FF',1,150,'']\n          - ['#FFFF00',1,200,'']\n          - ['#FF0000',1,250,'']\n
                                                              "},{"location":"styling/ysld/cookbook/rasters/#details_3","title":"Details","text":"

                                                              This example creates a three-color gradient based on a color-map with three entries on lines 8-13: line 11 specifies the lower bound (150) be styled in blue ('#0000FF'), line 12 specifies an intermediate point (200) be styled in yellow ('#FFFF00'), and line 13 specifies the upper bound (250) be styled in red ('#FF0000').

                                                              Since our data values run between 70 and 256, some data points are not accounted for in this style. Those values below the lowest entry in the color map (the range from 70 to 149) are styled the same color as the lower bound, in this case blue. Values above the upper bound in the color map (the range from 251 to 256) are styled the same color as the upper bound, in this case red.

                                                              "},{"location":"styling/ysld/cookbook/rasters/#alpha-channel","title":"Alpha channel","text":"

                                                              This example creates an \"alpha channel\" effect such that higher values are increasingly transparent.

                                                              Alpha channel

                                                              "},{"location":"styling/ysld/cookbook/rasters/#code_4","title":"Code","text":"

                                                              Download the \"Alpha channel\" YSLD

                                                              title: 'YSLD Cook Book: Alpha channel'\nfeature-styles:\n- name: name\n  rules:\n  - symbolizers:\n    - raster:\n        opacity: 1\n        color-map:\n          type: ramp\n          entries:\n          - ['#008000',1,70,'']\n          - ['#008000',0,256,'']\n
                                                              "},{"location":"styling/ysld/cookbook/rasters/#details_4","title":"Details","text":"

                                                              An alpha channel is another way of referring to variable transparency. Much like how a gradient maps values to colors, each entry in a color-map can have a value for opacity (with the default being 1.0 or completely opaque).

                                                              In this example, there is a color-map with two entries: line 11 specifies the lower bound of 70 be colored dark green ('#008000'), while line 13 specifies the upper bound of 256 also be colored dark green but with an opacity value of 0. This means that values of 256 will be rendered at 0% opacity (entirely transparent). Just like the gradient color, the opacity is also linearly interpolated such that a value of 163 (the midpoint between 70 and 256) is rendered at 50% opacity.

                                                              "},{"location":"styling/ysld/cookbook/rasters/#discrete-colors","title":"Discrete colors","text":"

                                                              This example shows a gradient that is not linearly interpolated but instead has values mapped precisely to one of three specific colors.

                                                              Discrete colors

                                                              "},{"location":"styling/ysld/cookbook/rasters/#code_5","title":"Code","text":"

                                                              Download the \"Discrete colors\" YSLD

                                                              title: 'YSLD Cook Book: Discrete colors'\nfeature-styles:\n- name: name\n  rules:\n  - symbolizers:\n    - raster:\n        opacity: 1\n        color-map:\n          type: intervals\n          entries:\n          - ['#008000',1,150,'']\n          - ['#663333',1,256,'']\n
                                                              "},{"location":"styling/ysld/cookbook/rasters/#details_5","title":"Details","text":"

                                                              Sometimes color bands in discrete steps are more appropriate than a color gradient. The type: intervals parameter added to the color-map on line 9 sets the display to output discrete colors instead of a gradient. The values in each entry correspond to the upper bound for the color band such that colors are mapped to values less than the value of one entry but greater than or equal to the next lower entry. For example, line 11 colors all values less than 150 to dark green ('#008000') and line 12 colors all values less than 256 but greater than or equal to 150 to dark brown ('#663333').

                                                              "},{"location":"styling/ysld/cookbook/rasters/#many-color-gradient","title":"Many color gradient","text":"

                                                              This example shows a gradient interpolated across eight different colors.

                                                              Many color gradient

                                                              "},{"location":"styling/ysld/cookbook/rasters/#code_6","title":"Code","text":"

                                                              Download the \"Many color gradient\" YSLD

                                                              title: 'YSLD Cook Book: Many color gradient'\nfeature-styles:\n- name: name\n  rules:\n  - symbolizers:\n    - raster:\n        opacity: 1\n        color-map:\n          type: ramp\n          entries:\n          - ['#000000',1,95,'']\n          - ['#0000FF',1,110,'']\n          - ['#00FF00',1,135,'']\n          - ['#FF0000',1,160,'']\n          - ['#FF00FF',1,185,'']\n          - ['#FFFF00',1,210,'']\n          - ['#00FFFF',1,235,'']\n          - ['#FFFFFF',1,256,'']\n
                                                              "},{"location":"styling/ysld/cookbook/rasters/#details_6","title":"Details","text":"

                                                              A color-map can include up to 255 entries. This example has eight entries (lines 11-18):

                                                              Entry number Value Color RGB code

                                                              1 95 Black '#000000'

                                                              2 110 Blue '#0000FF'

                                                              3 135 Green '#00FF00'

                                                              4 160 Red '#FF0000'

                                                              5 185 Purple '#FF00FF'

                                                              6 210 Yellow '#FFFF00'

                                                              7 235 Cyan '#00FFFF'

                                                              8 256 White '#FFFFFF'

                                                              "},{"location":"styling/ysld/reference/","title":"YSLD reference","text":"

                                                              This section will detail the usage and syntax of the YSLD markup language.

                                                              As YSLD is heavily modeled on YAML, it may be useful to refer to the YAML specification for basic syntax.

                                                              • Structure
                                                              • Feature Styles
                                                              • Rules
                                                              • Symbolizers
                                                              • Line symbolizer
                                                              • Polygon symbolizer
                                                              • Point symbolizer
                                                              • Raster symbolizer
                                                              • Text symbolizer
                                                              • Scale and zoom
                                                              • Filters
                                                              • Functions
                                                              • Define and reuse YAML Variables
                                                              • Transforms
                                                              "},{"location":"styling/ysld/reference/featurestyles/","title":"Feature Styles","text":"

                                                              In YSLD, a Feature Style is a block of styling Rules. The Feature Style is applied to a single feature type and drawn in an off-screen buffer.

                                                              The feature style element

                                                              The purpose of a Feature Style is to specify drawing order. The buffer for the first Feature Style will be drawn first, while buffer for the second Feature Style will be processed after that, etc. When drawing is complete the buffers will composed into the final drawn map.

                                                              A Feature Style is a top-level element in a YSLD style.

                                                              Consider the following hierarchy:

                                                              • Feature Style 1
                                                                • Rule 1a
                                                                • Rule 1b
                                                              • Feature Style 2
                                                                • Rule 2a
                                                                • Rule 2b
                                                                • Rule 2c

                                                              In this case, the rules contained inside Feature Style 1 will be processed and their symbolizers drawn first. After Rule 1a and 1b are processed, the renderer will move on to Feature Style 2, where Rule 2a, 2b, and 2c will then be processed and their symbolizers drawn.

                                                              Feature style order

                                                              "},{"location":"styling/ysld/reference/featurestyles/#drawing-order","title":"Drawing order","text":"

                                                              The order of feature styles is significant, and also the order of rules inside feature styles is significant.

                                                              Rules inside a feature style are all applied to each feature at once. After all of the rules in a feature style have been applied to each feature, the next feature style will start again, applying rules to each feature.

                                                              The off-screen buffer for each feature style is merged together during composition. These buffers are merged in the order defined by the feature styles. In this way, using multiple feature styles is a way of specifying z-order.

                                                              Consider the same hierarchy as above. Given a layer that contains three features, the rules will be applied as follows:

                                                              Feature style 1 will draw an off-screen buffer:

                                                              1. Rule 1a is applied to the first feature, followed by rule 1b
                                                              2. Rule 1a is applied to the second feature, followed by rule 1b
                                                              3. Rule 1a is applied to the third feature, followed by rule 1b

                                                              Feature style 1 buffer

                                                              Feature style 2 will draw an off-screen buffer:

                                                              1. Rule 2a is applied to the first feature, followed by rule 2b and then rule 2c
                                                              2. Rule 2a is applied to the second feature, followed by rule 2b and then rule 2c
                                                              3. Rule 2a is applied to the third feature, followed by rule 2b and then rule 2c

                                                              Feature style 2 buffer

                                                              This final map is produced by composition:

                                                              1. The buffer for feature style 1 is drawn
                                                              2. The buffer for feature style 2 is drawn
                                                              3. Any labeling is drawn on top

                                                              Composition of both feature styles

                                                              If you need a rule to apply on top of other rules, use a second feature style. A useful case for this is for lines representing bridges or overpasses. In order to ensure that the bridge lines always display on \"top\" of other lines (which in a display that includes, they would need to be applied using a second feature style.)

                                                              "},{"location":"styling/ysld/reference/featurestyles/#syntax","title":"Syntax","text":"

                                                              The following is the basic syntax of a feature style. Note that the contents of the block are not all expanded here.

                                                              feature-styles:\n- name: <text>\n  title: <text>\n  abstract: <text>\n  transform:\n    ...\n  rules:\n  - ...\n  x-ruleEvaluation: <text>\n  x-composite: <text>\n  x-composite-base: <boolean>\n  x-inclusion: <text>\n

                                                              where:

                                                              Property Required? Description Default value

                                                              name No Internal reference to the feature style. It is recommended that the value be lower case and contain no spaces. Blank

                                                              title No Human-readable name of the feature style. Exposed as a name for the group of rules contained in the feature style. Blank

                                                              abstract No Longer description of the feature style. Blank

                                                              transform No Rendering transformation information. N/A

                                                              rules Yes List of styling rules. N/A

                                                              The following properties are equivalent to SLD \"vendor options\".

                                                              Property Required? Description Default value

                                                              x-ruleEvaluation No When equals to first - stops rule evaluation after the first match. Can make the rendering more efficient by reducing the number of rules that need to be traversed by features, as well as simplyfing the rule filters. all

                                                              x-composite No Allows for both alpha compositing and color blending options between buffers. There are many options; see below. N/A

                                                              x-composite-base No Allows the rendering engine to use that feature-style as a \"base\", and will compose all subsequent feature-styles and layers on top of it, until another base is found. Once the full set of layers against a base is composed, then the base itself will be composed against the next set of composed layers using its own compositing operator, if present. This is useful to fine-tune the use of x-composite, and to make sure that only the desired content is composited/blended and not all of the drawn content. false

                                                              x-inclusion No Define if rule should be included in style for legendOnly or mapOnly (see Rendering Selection) normal

                                                              "},{"location":"styling/ysld/reference/featurestyles/#ysld_reference_featurestyles_composite","title":"Compositing and blending","text":"

                                                              By default, multiple feature styles are drawn with one buffer on top of the other. However, using the x-composite and x-composite-base options, one can customize the way that buffers are displayed.

                                                              The following two tables show the possible alpha compositing and color blending values for the x-composite option. Note that in the tables below, source refers to the buffer that is drawn on top, while destination refers to the buffer that the source is drawn on top of.

                                                              Todo

                                                              Add image showing source and destination

                                                              Alpha compositing

                                                              Alpha compositing controls how buffers are merged using the transparent areas of each buffer.

                                                              +--------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Value | Description | +====================+=============================================================================================================================================================================================================+ | copy | Only the source will be present in the output. | | | | | | | +--------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | destination | Only the destination will be present in the output. | | | | | | | +--------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | source-over | The source is drawn over the destination, and the destination is visible where the source is transparent. Opposite of destination-over. This is the default value for x-composite. | | | | | | | +--------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | destination-over | The source is drawn below the destination, and is visible only when the destination is transparent. Opposite of source-over. | | | | | | | +--------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | source-in | The source is visible only when overlapping some non-transparent pixel of the destination. This allows the background map to act as a mask for the layer/feature being drawn. Opposite of destination-in. | | | | | | | +--------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | destination-in | The destination is retained only when overlapping some non transparent pixel in the source. This allows the layer/feature to be drawn to act as a mask for the background map. Opposite of source-in. | | | | | | | +--------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | source-out | The source is retained only in areas where the destination is transparent. This acts as a reverse mask when compared to source-in. | | | | | | | +--------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | destination-out | The destination is retained only in areas where the source is transparent. This acts as a reverse mask when compared to destination-in. | | | | | | | +--------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | source-atop | The destination is drawn fully, while the source is drawn only where it intersects the destination. | | | | | | | +--------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | destination-atop | The source is drawn fully, and the destination is drawn over the source only where it intersects it. | | | | | | | +--------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | xor | \"Exclusive Or\" mode. Each pixel is rendered only if either the source or the destination is not blank, but not both. | | | | | | | +--------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+

                                                              Color blending

                                                              Color blending allows buffers to be mixed during composition.

                                                              +---------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Value | Description | +===============+========================================================================================================================================================================================================================================================================================================+ | multiply | The source color is multiplied by the destination color and replaces the destination. The resulting color is always at least as dark as either the source or destination color. Multiplying any color with black results in black. Multiplying any color with white preserves the original color. | | | | | | | +---------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | screen | Multiplies the complements of the source and destination color values, then complements the result. The end result color is always at least as light as either of the two constituent colors. Screening any color with white produces white; screening with black leaves the original color unchanged. | | | | | | | +---------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | overlay | Multiplies the colors depending on the destination color value. Source colors overlay the destination while preserving highlights and shadows. The backdrop color is not replaced but is mixed with the source color to reflect the lightness or darkness of the backdrop. | | | | | | | +---------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | darken | Selects the darker of the destination and source colors. The destination is replaced with the source only where the source is darker. | | | | | | | +---------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | lighten | Selects the lighter of the destination and source colors. The destination is replaced with the source only where the source is lighter. | | | | | | | +---------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | color-dodge | Brightens the destination color to reflect the source color. Drawing with black produces no changes. | | | | | | | +---------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | color-burn | Darkens the destination color to reflect the source color. Drawing with white produces no change. | | | | | | | +---------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | hard-light | Multiplies the colors, depending on the source color value. The effect is similar to shining a harsh spotlight on the destination. | | | | | | | +---------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | soft-light | Darkens or lightens the colors, depending on the source color value. The effect is similar to a diffused spotlight on the destination. | | | | | | | +---------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | difference | Subtracts the darker of the two constituent colors from the lighter color. White inverts the destination color; black produces no change. | | | | | | | +---------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | exclusion | Produces an effect similar to that of difference but lower in contrast. White inverts the destination color; black produces no change. | | | | | | | +---------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+

                                                              Note

                                                              For more details about the compositing and blending options, please see Composite and blending modes.

                                                              "},{"location":"styling/ysld/reference/featurestyles/#short-syntax","title":"Short syntax","text":"

                                                              When a style has a single feature style, it is possible to omit the syntax for the feature style and start at the first parameter inside.

                                                              So the following complete styles are both equivalent:

                                                              feature-styles:\n- rules:\n  - name: rule1\n    scale: [min,50000]\n    symbolizers:\n    - line:\n        stroke-color: '#000000'\n        stroke-width: 2\n  - name: rule2\n    scale: [50000,max]\n    symbolizers:\n    - line:\n        stroke-color: '#000000'\n        stroke-width: 1\n
                                                              rules:\n- name: rule1\n  scale: [min,50000]\n  symbolizers:\n  - line:\n      stroke-color: '#000000'\n      stroke-width: 2\n- name: rule2\n  scale: [50000,max]\n  symbolizers:\n  - line:\n      stroke-color: '#000000'\n      stroke-width: 1\n
                                                              "},{"location":"styling/ysld/reference/featurestyles/#examples","title":"Examples","text":""},{"location":"styling/ysld/reference/featurestyles/#road-casing","title":"Road casing","text":"

                                                              This example shows how a smaller line can be drawn on top of a larger line, creating the effect of lines being drawn with a border or \"casing\":

                                                              feature-styles:\n- name: outer\n  title: Outer line\n  rules:\n  - name: outer_rule\n    symbolizers:\n    - line:\n        stroke-color: '#808080'\n        stroke-width: 8\n- name: inner\n  title: Inner line\n  rules:\n  - name: inner_rule\n    symbolizers:\n    - line:\n        stroke-color: '#44FF88'\n        stroke-width: 6\n

                                                              To draw the inner lines always on top of the outer lines we need to control the z-order. The outer_rule is encased in its own feature style and drawn into a distinct \"Outer line\" buffer. Next the inner_rule is encased in its own feature style and drawn into a distinct \"Inner line\" buffer.

                                                              Feature style buffers

                                                              During composition these two off-screen buffers are combined into the final map.

                                                              Final map composition

                                                              When drawn, the outer line has a width of 8 pixels and the inner line has a width of 6 pixels, so the line \"border\" is 1 pixel (on each side).

                                                              Example showing road casing

                                                              "},{"location":"styling/ysld/reference/featurestyles/#first-match","title":"First match","text":"

                                                              Given a style that has many rules with distinct outcomes, it may be advantageous to employ x-ruleEvaluation: first so as to improve rendering efficiency and simplify those rules.

                                                              This first example shows the standard way of creating rules for a dataset. There are villages, towns, and cities (type = 'village', type = 'town' or type = 'city') and they have an industry which could be either fishing or other values.

                                                              Note

                                                              In order to simplify this example, the specifics of the point symbolizers have been replaced by Define and reuse YAML Variables. In a real-world example, these would need to be defined in the YSLD as well.

                                                              feature-styles:\n- name: without_first_match\n  rules:\n  - name: fishing_town\n    filter: ${type = 'town' AND industry = 'fishing'}\n    symbolizers:\n    - point:\n        <<: *fishingtown\n  - name: fishing_city\n    filter: ${type = 'city' AND industry = 'fishing'}\n    symbolizers:\n    - point:\n        <<: *fishingcity\n  - name: other_towns_cities\n    filter: ${type IN ('town', 'city') AND industry <> 'fishing'}\n    symbolizers:\n    - point:\n        <<: *othertownscities\n  - name: other\n    else: true\n    symbolizers:\n    - point:\n        <<: *allotherplaces\n

                                                              Using the x-ruleEvaluation: first parameter, the style is simplified:

                                                              feature-styles:\n- name: with_first_match\n  x-ruleEvaluation: first\n  rules:\n  - name: fishing_town\n    filter: ${type = 'town' AND industry = 'fishing'}\n    symbolizers:\n    - point:\n        <<: *fishingtown\n  - name: fishing_city\n    filter: ${type = 'city' AND industry = 'fishing'}\n    symbolizers:\n    - point:\n        <<: *fishingcity\n  - name: other_towns_cities\n    filter: ${type IN ('town', 'city')}\n    symbolizers:\n    - point:\n        <<: *othertownscities\n  - name: other\n    else: true\n    symbolizers:\n    - point:\n        <<: *allotherplaces\n

                                                              Specifically, the third rule no longer needs the extra AND industry <> 'fishing', because the previous two rules imply that any features remaining by this rule have that condition.

                                                              "},{"location":"styling/ysld/reference/featurestyles/#layer-mask","title":"Layer mask","text":"

                                                              Given two layers (in this case, two three-band rasters), one can mask or \"knock out\" the other, making visible what's beneath.

                                                              Top/source layer

                                                              Bottom/destination layer

                                                              Note

                                                              Screenshots show data provided by Natural Earth.

                                                              Layer 1 (top/source):

                                                              feature-styles:\n- rules:\n  - title: Top/source\n    symbolizers:\n    - raster:\n        opacity: 1.0\n  x-composite: xor\n

                                                              Layer 2 (bottom/destination):

                                                              feature-styles:\n- rules:\n  - title: Bottom/destination\n    symbolizers:\n    - raster:\n        opacity: 1.0\n

                                                              Layer as mask

                                                              "},{"location":"styling/ysld/reference/featurestyles/#color-inversion","title":"Color inversion","text":"

                                                              Given the same two layers as the previous example, one can display the difference of the colors of layers, which can have the effect of a color \"inversion\".

                                                              Layer 1 (top/source):

                                                              feature-styles:\n- rules:\n  - title: Top/source\n    symbolizers:\n    - raster:\n        opacity: 1.0\n  x-composite: difference\n

                                                              Layer 2 (bottom/destination):

                                                              feature-styles:\n- rules:\n  - title: Bottom/destination\n    symbolizers:\n    - raster:\n        opacity: 1.0\n

                                                              Layer as color inversion

                                                              "},{"location":"styling/ysld/reference/filters/","title":"Filters","text":"

                                                              Filters are predicates that allow rules to be applied selectively.

                                                              A filter can take a great many different forms.

                                                              Note

                                                              A scale is a type of filter, but is discussed separately.

                                                              Note

                                                              For more information, please see the GeoTools CQL documentation and GeoServer CQL tutorial.

                                                              "},{"location":"styling/ysld/reference/filters/#syntax","title":"Syntax","text":"

                                                              The basic syntax of a filter is:

                                                              rules:\n  ...\n  filter: ${<expression>}\n  ...\n

                                                              where <expression> is any valid CQL/ECQL filter.

                                                              Note

                                                              Be aware that filters are applied to rules and so appear inside them, but outside of any symbolizers.

                                                              "},{"location":"styling/ysld/reference/filters/#types-of-filters","title":"Types of filters","text":"

                                                              As mentioned above, the filter can be any valid construction made with CQL/ECQL (Extended/Contextual Query Language).

                                                              CQL is written using a familiar text-based syntax with strong similarities to SQL statements. One can think of a CQL expression as the \"WHERE\" clause of a SQL statement.

                                                              The following are all standard filter constructions:

                                                              "},{"location":"styling/ysld/reference/filters/#object-comparison","title":"Object comparison","text":"

                                                              This filter will test to see if a comparison to an attribute is true. It has the following form:

                                                              ${<attribute> <operator> <value>}\n

                                                              where:

                                                              Attribute Required? Description Default value

                                                              <attribute> Yes That to which something is going to be compared. Typically an attribute name. May be case sensitive. N/A

                                                              <operator> Yes Method of comparison. Valid operators are =, <, >, <=, >=, <>, LIKE, ILIKE, BETWEEN, IS NULL, IN. NOT can be added to invert the comparison. N/A

                                                              <value> Yes That which the <attribute> is being compared to. Typically a static value such as a string or scalar, though can be an expression that evaluates to a static value. Can include mathematical operators such as +, -, *, /. Use single quotes for strings, as double-quotes will be interpreted as an attribute name. Omit quotes for scalar values. N/A

                                                              The following is a description of all available operators:

                                                              Operator Description

                                                              = Equals

                                                              < Less than (non-inclusive)

                                                              > Greater than (non-inclusive)

                                                              <= Less than or equal to (inclusive)

                                                              >= Greater than or equal to (inclusive)

                                                              LIKE Fuzzy matching for strings and other non-numeric attributes. Add % for multi-character wildcards, and _ for single-character wildcards.

                                                              ILIKE Case-insensitive version of LIKE

                                                              BETWEEN Tests if a value that is between two given values

                                                              IS NULL For testing against a NULL value

                                                              IN Used when specifying a list. Must be contained in the list for the statement to be true.

                                                              NOT Negates a boolean (true/false) condition. Can be used with an additional operator such as NOT LIKE or NOT BETWEEN.

                                                              <> Not equal (used when comparing a string or numeric value only)

                                                              Note

                                                              These operators are not case sensitive, but are shown here in all caps for legibility and consistency.

                                                              "},{"location":"styling/ysld/reference/filters/#spatial-filters","title":"Spatial filters","text":"

                                                              Filters can be spatial in nature. Any valid spatial construction in WKT (Well Known Text) can be used. Spatial filters include INTERSECTS, DISJOINT, CONTAINS, WITHIN, TOUCHES, CROSSES, EQUALS, DWITHIN, and BBOX. NOT can be added to negate the condition.

                                                              For more details about these spatial filters and their syntax, please see the GeoServer ECQL reference or uDig CQL reference.

                                                              "},{"location":"styling/ysld/reference/filters/#compound-statements","title":"Compound statements","text":"

                                                              The filter can be a combination of statements. A common case is testing if the value of an attribute is greater than one value but less than another.

                                                              The syntax for creating compound statements is to use standard Boolean notation such as AND, OR, and NOT along with relevant parentheses.

                                                              For example, a filter where both statements need to be true would be:

                                                              filter: ${<statement1> AND <statement2>}\n

                                                              A filter where either statement would need to be true would be:

                                                              filter: ${<statement1> OR <statement2>}\n

                                                              Larger filters can be built up in this way:

                                                              filter: ${(<statement1> OR <statement2>) AND <statement3> OR NOT <statement4>}\n

                                                              In these examples, every <statement> is a valid filter.

                                                              In terms of precedence, AND is evaluated first, followed by OR, unless modified by parentheses. So, in the last example above, (<statement1> OR <statement2>) will be evaluated first, followed by the result of that AND <statement3>, and finally the result of that with OR NOT <statement4>.

                                                              "},{"location":"styling/ysld/reference/filters/#examples","title":"Examples","text":"

                                                              Filter size based on an attribute

                                                              Filters are used to style different features of a layer based on certain conditions. The ILIKE operator is used to compare two strings (ignoring case) to see if they are similar. When using LIKE or ILIKE, the % character matches any number of letters (So %hwy matches any streetname ending in hwy). This example uses filters to distinguish between Highways, Roads, and other streets, and draw them using different colors and sizes:

                                                              feature-styles:\n- rules:\n  - filter: ${streetname ILIKE '%hwy'}\n      symbolizers:\n      - line:\n          stroke-color: '#007799'\n          stroke-width: 8\n  - filter: ${streetname ILIKE '%rd'}\n      symbolizers:\n      - line:\n          stroke-color: '#00AA00'\n          stroke-width: 4\n  - else: true\n      symbolizers:\n      - line:\n          stroke-color: black\n          stroke-width: 2\n

                                                              Filter based on road types

                                                              Filter color based on attribute value

                                                              Filters can also be used to color a map based on attributes of the data. The following example uses the YEARBLT attribute to color different lots based on the year they were built. The else rule applies only if no other filter rule applies

                                                              Note

                                                              The Recode function can perform the same functionality in a more compact syntax.

                                                              name: Year Built Filter feature-styles: - rules: - filter: ${YEARBLT > 2000} symbolizers: - polygon: stroke-color: '#000000' stroke-width: 0.5 fill-color: '#00FF00' - filter: ${YEARBLT > 1990 AND YEARBLT < 2000} symbolizers: - polygon: stroke-color: '#000000' stroke-width: 0.5 fill-color: '#22DD00' - filter: ${YEARBLT > 1980 AND YEARBLT < 1990} symbolizers: - polygon: stroke-color: '#000000' stroke-width: 0.5 fill-color: '#44BB00' - filter: ${YEARBLT > 1970 AND YEARBLT < 1980} symbolizers: - polygon: stroke-color: '#000000' stroke-width: 0.5 fill-color: '#668800' - else: true symbolizers: - polygon: stroke-color: '#000000' stroke-width: 0.5 fill-color: '#DD4400'

                                                              Filter based on attribute value

                                                              Filter by bounding box

                                                              Spatial filters can be used to filter a layer based on its geometry. The bbox filter can be used to select features that are contained within a bounding box. This example colors polygons orange within the bounding box, and blue outside the bounding box:

                                                              name: Spatial Filter\nfeature-styles:\n- name: name\n  rules:\n  - filter: bbox(the_geom, -122.9, 42.36, -122.85, 42.28)\n    symbolizers:\n    - polygon:\n         fill-color: '#99CC00'\n  - else: true\n    symbolizers:\n    - polygon:\n         fill-color: '#0099CC'\n

                                                              Detail of bbox filter

                                                              Filter by arbitrary geometries

                                                              Spatial filters can also be used to compare layer geometries against arbitrary geometries, not just bounding boxes. In this example, the within filter is used to select all buildings inside a triangular region defined using Well-Known Text (WKT) and color them green. All other features are colored blue:

                                                              feature-styles:\n- name: name\n  rules:\n  - filter: within(the_geom, POLYGON ((-122.9075 42.3625, -122.8225 42.3625, -122.8268 42.2803, -122.9075 42.3625)))\n    symbolizers:\n    - polygon:\n        fill-color: '#00CC00'\n  - else: true\n    symbolizers:\n    - polygon:\n        fill-color: '#0099CC'\n

                                                              Filter using within

                                                              "},{"location":"styling/ysld/reference/functions/","title":"Functions","text":"

                                                              Functions are additional operations that can be employed when calculating values for YSLD parameters. In most cases, a value for a parameter can be the output (result) of a function.

                                                              Functions can be used in most places in a style document.

                                                              "},{"location":"styling/ysld/reference/functions/#syntax","title":"Syntax","text":"

                                                              Functions aren't a parameter to itself, but instead are used as a part of the values of a parameter, or indeed in any expression. So the syntax is very general, for example:

                                                              <parameter>: ${<function>}\n

                                                              Functions are evaluated at rendering time, so the output is passed as the parameter value and then rendered accordingly.

                                                              "},{"location":"styling/ysld/reference/functions/#list-of-functions","title":"List of functions","text":"

                                                              A reference list of functions can be found in the GeoServer User Manual and is also available in raw form in the GeoTools User Manual Function List.

                                                              The functions can be broken up loosely into categories such as geometric, math, and string functions.

                                                              "},{"location":"styling/ysld/reference/functions/#ysld_reference_functions_theming","title":"Theming functions","text":"

                                                              There are three important functions that are often easier to use for theming than using rules, and can vastly simplify your style documents: Recode, Categorize, and Interpolate.

                                                              Recode: Attribute values are directly mapped to styling properties:

                                                              recode(attribute,value1,result1,value2,result2,value3,result3,...)\n

                                                              This is equivalent to creating multiple rules with similar filters:

                                                              rules:\n- ...\n  filter: ${attribute = value1}\n  - ...\n    <property>: result1\n- ...\n  filter: ${attribute = value2}\n  - ...\n    <property>: result2\n- ...\n  filter: ${attribute = value3}\n  - ...\n    <property>: result3\n

                                                              Categorize: Categories are defined using minimum and maximum ranges, and attribute values are sorted into the appropriate category:

                                                              categorize(attribute,category0,value1,category1,value2,category2,...,belongsTo)\n

                                                              This would create a situation where the attribute value, if less than value1 will be given the result of category0; if between value1 and value2, will be given the result of category1; if between value2 and value3, will be given the result of category2, etc. Values must be in ascending order.

                                                              The belongsTo argument is optional, and can be either succeeding or preceding. It defines which interval to use when the lookup value equals the attribute value. If the attribute value is equal to value1 and suceeding is used, then the result will be category1. If preceding is used then the result will be category0. The default is succeeding.

                                                              This is equivalent to creating the following multiple rules:

                                                              rules:\n- ...\n  filter: ${attribute < value1}\n  - ...\n    <property>: category0\n- ...\n  filter: ${attribute >= value1 AND attribute < value2}\n  - ...\n    <property>: category1\n- ...\n  filter: ${attribute >= value2}\n  - ...\n    <property>: category2\n

                                                              Interpolate: Used to smoothly theme quantitative data by calculating a styling property based on an attribute value. This is similar to Categorize, except that the values are continuous and not discrete:

                                                              interpolate(attribute,value1,entry1,value2,entry2,...,mode,method)\n

                                                              This would create a situation where the attribute value, if equal to value1 will be given the result of entry1; if halfway between value1 and value2 will be given a result of halfway in between entry1 and entry2; if three-quarters between value1 and value2 will be given a result of three-quarters in between entry1 and entry2, etc.

                                                              The mode argument is optional, and can be either linear, cosine, or cubic. It defines the interpolation algorithm to use, and defaults to linear.

                                                              The method argument is optional, and can be either numeric or color. It determines whether entry1, entry2, ... are numbers or colors, and defaults to numeric.

                                                              There is no equivalent to this function in vector styling. The closest to this in raster styling is the color ramp.

                                                              The three theming functions can be neatly summarized by this table:

                                                              Function Type of input Type of output Recode Discrete Discrete Categorize Continuous Discrete Interpolate Continuous Continuous"},{"location":"styling/ysld/reference/functions/#examples","title":"Examples","text":""},{"location":"styling/ysld/reference/functions/#display-rotated-arrows-at-line-endpoints","title":"Display rotated arrows at line endpoints","text":"

                                                              The startPoint(geom) and endPoint(geom) functions take a geometry as an argument and returns the start and end points of the geometry respectively. The startAngle(geom) and endAngle(geom) functions take a geometry as an argument and return the angle of the line terminating at the start and end points of the geometry respectively. These functions can be used to display an arrow at the end of a line geometry, and rotate it to match the direction of the line:

                                                              feature-styles:\n- rules:\n  - symbolizers:\n      - line:\n          stroke-width: 1\n      - point:\n          geometry: ${endPoint(geom)}\n          rotation: ${endAngle(geom)}\n          size: 24\n          symbols:\n          - mark:\n              shape: 'shape://carrow'\n              fill-color: '#000000'\n

                                                              Endpoint arrows

                                                              "},{"location":"styling/ysld/reference/functions/#drop-shadow","title":"Drop shadow","text":"

                                                              The offset(geom, x, y) function takes a geometry and two values, and displaces the geometry by those values in the x and y directions. This can be used to create a drop-shadow effect:

                                                              feature-styles:\n- name: shadow\n  rules:\n  - symbolizers:\n    - polygon:\n        stroke-width: 0.0\n        fill-color: '#000000'\n        fill-opacity: 0.75\n        geometry: ${offset(geom, 0.0001, -0.0001)}\n- name: fill\n  rules:\n  - symbolizers:\n    - polygon:\n      stroke-width: 0.0\n      fill-color: '#00FFFF'\n

                                                              Drop shadow

                                                              "},{"location":"styling/ysld/reference/functions/#different-colored-outline","title":"Different-colored outline","text":"

                                                              The buffer(geom, buffer) function takes a geometry and a value as arguments, and returns a polygon geometry with a boundary equal to the original geometry plus the value. This can be used to generate an extended outline filled with a different color, for example to style a shoreline:

                                                              feature-styles:\n- name: shoreline\n  rules:\n  - polygon:\n      fill-color: '#00BBFF'\n      geometry: ${buffer(geom, 0.00025)}\n- name: land\n  rules:\n  - polygon:\n      fill-color: '#00DD00'\n

                                                              Buffered outline

                                                              See also:

                                                              • convexHull(geom)
                                                              • octagonalEnvelope(geom)
                                                              • mincircle(geom)
                                                              • minrectangle(geom)
                                                              • minimumdiameter(geom)
                                                              "},{"location":"styling/ysld/reference/functions/#display-vertices-of-a-line","title":"Display vertices of a line","text":"

                                                              The vertices(geom) function takes a geometry and returns a collection of points representing the vertices of the geometry. This can be used to convert a polygon or line geometry into a point geometry:

                                                              point:\n  geometry: vertices(geom)\n

                                                              Endpoint arrows

                                                              See also:

                                                              • boundary(geom)
                                                              • centroid(geom)
                                                              "},{"location":"styling/ysld/reference/functions/#angle-between-two-points","title":"Angle between two points","text":"

                                                              The atan2(x, y) function calculates the arctangent of (y/x) and so is able to determine the angle (in radians) between two points. This function uses the signs of the x and y values to determine the computed angle, so it is preferable over atan(). The getX(point_geom) and getY(point_geom) extracts the x and y ordinates from a geometry respectively, while toDegrees(value) converts from radians to degrees:

                                                              point:\n  symbols:\n  - mark:\n      shape: triangle\n  rotation: ${toDegrees(atan2(\n    getX(startPoint(the_geom))-getX(endPoint(the_geom)),\n    getY(startPoint(the_geom))-getY(endPoint(the_geom))))}\n

                                                              See also:

                                                              • sin(value)
                                                              • cos(value)
                                                              • tan(value)
                                                              • asin(value)
                                                              • acos(value)
                                                              • atan(value)
                                                              • toRadians(value)
                                                              • pi()
                                                              "},{"location":"styling/ysld/reference/functions/#scale-objects-based-on-a-large-range-of-values","title":"Scale objects based on a large range of values","text":"

                                                              The log(value) function returns the natural logarithm of the provided value. Use log(value)/log(base) to specify a different base.

                                                              For example, specifying log(population)/log(2) will make the output increase by 1 when the value of population doubles. This allows one to display relative sizes on a consistent scale while still being able to represent very small and very large populations:

                                                              point:\n  symbols:\n  - mark:\n      shape: circle\n  size: ${log(population)/log(2)}\n

                                                              See also:

                                                              • exp(val)
                                                              • pow(base,exponent)
                                                              • sqrt(val)
                                                              "},{"location":"styling/ysld/reference/functions/#combine-several-strings-into-one","title":"Combine several strings into one","text":"

                                                              The Concatenate(string1, string2, ...) function takes any number of strings and combines them to form a single string. This can be used to display more than one attribute within a single label:

                                                              text:\n  label: ${Concatenate(name, ', ', population)}\n
                                                              "},{"location":"styling/ysld/reference/functions/#capitalize-words","title":"Capitalize words","text":"

                                                              The strCapitalize(string) function takes a single string and capitalizes the first letter of each word in the string. This could be used to capitalize labels created from lower case text:

                                                              text:\n  label: ${strCapitalize(name)}\n

                                                              See also:

                                                              • strToLowerCase(string)
                                                              • strToUpperCase(string)
                                                              "},{"location":"styling/ysld/reference/functions/#color-based-on-discrete-values","title":"Color based on discrete values","text":"

                                                              In certain cases, theming functions can be used in place of filters to produce similar output much more simply. For example, the Recode function can take an attribute and output a different value based on an attribute value. So instead of various filters, the entire constructions can be done in a single line. For example, this could be used to color different types of buildings:

                                                              feature-styles:\n- name: name\n  rules:\n  - symbolizers:\n    - polygon:\n        fill-color: \n          ${recode(zone, \n          'I-L', '#FF7700', \n          'I-H', '#BB6600', \n          'C-H', '#0077BB', \n          'C-R', '#00BBDD', \n          'C-C', '#00DDFF', \n          '', '#777777')}\n

                                                              In the above example, the attribute is zone , and then each subsequent pair consists of an attribute value followed by a color.

                                                              Recode Function

                                                              "},{"location":"styling/ysld/reference/functions/#color-based-on-categories","title":"Color based on categories","text":"

                                                              The Categorize function returns a different value depending on which range (category) an attribute value matches. This can also make a style much more simple by reducing the number of filters. This example uses categorize to color based on certain values of the YEARBLT attribute:

                                                              feature-styles:\n- name: name\n  rules:\n  - symbolizers:\n     - polygon:\n        stroke-color: '#000000'\n        stroke-width: 0.5\n        fill-color:\n          ${categorize(YEARBLT, '#DD4400', \n          1950,'#AA4400',\n          1960,'#886600',\n          1970,'#668800',\n          1980,'#44BB00',\n          1990,'#22DD00',\n          2000,'#00FF00')}\n

                                                              Categorize Function

                                                              "},{"location":"styling/ysld/reference/functions/#choropleth-map","title":"Choropleth map","text":"

                                                              The interpolate function can be used to create a continuous set of values by interpolating between attribute values. This can be used to create a choropleth map which shows different colors for regions based on some continuous attribute such as area or population:

                                                              feature-styles:\n- name: name\n  rules:\n  - title: fill-graphic\n    symbolizers:  \n    - polygon:\n        stroke-width: 1\n        fill-color: ${interpolate(PERSONS, 0.0, '#00FF00', 1e7,'#FF0000', 'color')}\n

                                                              Choropleth Map

                                                              "},{"location":"styling/ysld/reference/rules/","title":"Rules","text":"

                                                              A rule is a collection of styling directives, primarily consisting of symbolizers combined with optional conditional statements.

                                                              • If a conditional statement exists in a rule, then the styling directives will only be carried out if the conditional returns true. Otherwise, the rule will be skipped.
                                                              • If no conditional statement exists in a rule, then the styling directive will always be carried out.

                                                              Todo

                                                              FIGURE NEEDED

                                                              The types of conditional statements available to rules are:

                                                              • Filters for attribute-based rendering
                                                              • Scale for scale-based rendering

                                                              Rules are contained within feature styles. There is no limit on the number of rules that can be created, and there is no restriction that all rules must be mutually exclusive (as in, some rules may apply to the same features).

                                                              "},{"location":"styling/ysld/reference/rules/#syntax","title":"Syntax","text":"

                                                              The following is the basic syntax of a rule. Note that the contents of the block are not all expanded; see the other sections for the relevant syntax.

                                                              rules:\n- name: <text>\n  title: <text>\n  filter: <filter>\n  else: <boolean>\n  scale: [<min>,<max>]\n  symbolizers:\n  - ...\n  x-inclusion: <text>\n

                                                              where:

                                                              Property Required? Description Default value

                                                              name No Internal reference to the feature style. It is recommended that the value be lower case and contain no spaces. Blank

                                                              title No Human-readable description of what the rule accomplishes. Blank

                                                              filter No Filter expression which will need to evaluate to be true for the symbolizer(s) to be applied. Cannot be used with else. Blank (meaning that the rule will apply to all features)

                                                              else No Specifies whether the rule will be an \"else\" rule. An else rule applies when, after scale and filters are applied, no other rule applies. To make an else rule, set this option to true. Cannot be used with filter. false

                                                              scale No Scale boundaries showing at what scales (related to zoom levels) the rule will be applied. Visible at all scales

                                                              symbolizers Yes Block containing one or more symbolizers. These contain the actual visualization directives. If the filter returns true and the view is within the scale boundaries, these symbolizers will be drawn. N/A

                                                              x-inclusion No Define if rule should be included in style for legendOnly or mapOnly (see Rendering Selection) normal

                                                              "},{"location":"styling/ysld/reference/rules/#short-syntax","title":"Short syntax","text":"

                                                              When a style has a single rule inside a single feature style, it is possible to omit the syntax for both and start at the first parameter inside.

                                                              So the following complete styles are equivalent:

                                                              feature-styles:\n- rules:\n  - symbolizers:\n    - line:\n        stroke-color: '#000000'\n        stroke-width: 2\n\nline:\n  stroke-color: '#000000'\n  stroke-width: 2\n
                                                              "},{"location":"styling/ysld/reference/rules/#examples","title":"Examples","text":""},{"location":"styling/ysld/reference/rules/#else-filter","title":"Else filter","text":"

                                                              Using filter and else together:

                                                              rules:\n- name: small\n  title: Small features\n  filter: ${type = 'small'}\n  symbolizers:\n  - ...\n- name: large\n  title: Large features\n  filter: ${type = 'large'}\n  symbolizers:\n  - ...\n- name: else\n  title: All other features\n  else: true\n  symbolizers:\n  - ...\n

                                                              In the above situation:

                                                              • If a feature has a value of \"small\" in its type attribute, it will be styled with the \"small\" rule.
                                                              • If a feature has a value of \"large\" in its type attribute, it will be styled with the \"large\" rule.
                                                              • If a feature has a value of \"medium\" (or anything else) in its type attribute, it will be styled with the \"else\" rule.
                                                              "},{"location":"styling/ysld/reference/rules/#else-with-scale","title":"Else with scale","text":"

                                                              Using filter, else, and scale together:

                                                              rules:\n- name: small_zoomin\n  scale: [min,10000]\n  title: Small features when zoomed in\n  filter: ${type = 'small'}\n  symbolizers:\n  - ...\n- name: small_zoomout\n  scale: [10000,max]\n  title: Small features when zoomed out\n  filter: ${type = 'small'}\n  symbolizers:\n  - ...\n- name: else_zoomin\n  scale: [min,10000]\n  title: All other features when zoomed in\n  else: true\n  symbolizers:\n  - ...\n- name: else_zoomout\n  scale: [10000,max]\n  title: All other features when zoomed out\n  else: true\n  symbolizers:\n  - ...\n

                                                              In the above situation:

                                                              • If a feature has a value of \"small\" in its type attribute, and the map is a scale level less than 10,000, it will be styled with the \"small_zoomin\" rule.
                                                              • If a feature has a value of anything else other than \"small\" in its type attribute, and the map is a scale level less than 10,000, it will be styled with the \"else_zoomin\" rule.
                                                              • If a feature has a value of \"small\" in its type attribute, and the map is a scale level greater than 10,000, it will be styled with the \"small_zoomout\" rule.
                                                              • If a feature has a value of anything else other than \"small\" in its type attribute, and the map is a scale level greater than 10,000, it will be styled with the \"else_zoomout\" rule.
                                                              "},{"location":"styling/ysld/reference/scalezoom/","title":"Scale and zoom","text":"

                                                              It is common for different rules to be applied at different zoom levels on a web map.

                                                              For example, on a roads layer, you would not want to display every single road when viewing the whole world. Or perhaps you may wish to styles the same features differently depending on the zoom level. For example: a cities layer styled using points at low zoom levels (when \"zoomed out\") and with polygon borders at higher zoom levels (\"zoomed in\").

                                                              Todo

                                                              ADD FIGURE

                                                              YSLD allows rules to be applied depending on the scale or zoom level. You can specify by scale, or you can define zoom levels in terms of scales and specify by zoom level.

                                                              Warning

                                                              Be aware that scales for a layer (where a style is applied) may interact differently when the layer is contained in a map, if the map has a different coordinate reference system from the layer.

                                                              "},{"location":"styling/ysld/reference/scalezoom/#scale-syntax","title":"Scale syntax","text":"

                                                              The syntax for using a scale conditional parameter in a rule is:

                                                              rules:\n- ...\n  scale: [<min>,<max>]\n  ...\n

                                                              where:

                                                              Attribute Required? Description Default value

                                                              min Yes The minimum scale (inclusive) for which the rule will be applied. Value is a number, either decimal or integer. N/A

                                                              max Yes The maximum scale (exclusive) for which the rule will be applied. Value is a number, either decimal or integer. N/A

                                                              Note

                                                              It is not possible to use an expression for any of these values.

                                                              Use the literal strings min and max to denote where there are no lower or upper scale boundaries. For example, to denote that the scale is anything less than some <max> value:

                                                              scale: [min,<max>]\n

                                                              To denote that the scale is anything greater than or equal to some <min> value:

                                                              scale: [<min>,max]\n

                                                              Note

                                                              In the above examples, min and max are always literals, entered exactly like that, while <min> and <max> would be replaced by actual scalar values.

                                                              If the scale parameter is omitted entirely, then the rule will apply at all scales.

                                                              "},{"location":"styling/ysld/reference/scalezoom/#scale-examples","title":"Scale examples","text":"

                                                              Three rules, all applicable at different scales:

                                                              rule:\n- name: large_scale\n  scale: [min,100000]\n  symbolizers:\n  - line:\n      stroke-width: 3\n      stroke-color: '#0165CD'\n- name: medium_scale\n  scale: [100000,200000]\n  symbolizers:\n  - line:\n      stroke-width: 2\n      stroke-color: '#0165CD'\n- name: small_scale\n  scale: [200000,max]\n  symbolizers:\n  - line:\n      stroke-width: 1\n      stroke-color: '#0165CD'\n

                                                              This example will display lines with:

                                                              • A stroke width of 3 at scales less than 100,000 (large_scale)
                                                              • A stroke width of 2 at scales between 100,000 and 200,000 (medium_scale)
                                                              • A stroke width of 1 at scales greater than 200,000 (small_scale)

                                                              Given the rules above, the following arbitrary sample scales would map to the rules as follows:

                                                              Scale Rule 50000 large_scale 100000 medium_scale 150000 medium_scale 200000 small_scale 300000 small_scale

                                                              Note the edge cases, since the min value is inclusive and the max value is exclusive.

                                                              "},{"location":"styling/ysld/reference/scalezoom/#scientific-notation-for-scales","title":"Scientific notation for scales","text":"

                                                              To make comprehension easier and to lessen the chance of errors, scale values can be expressed in scientific notation.

                                                              So a scale of 500000000, which is equal to 5 \u00d7 10\\^8 (a 5 with eight zeros), can be replaced by 5e8.

                                                              "},{"location":"styling/ysld/reference/scalezoom/#relationship-between-scale-and-zoom","title":"Relationship between scale and zoom","text":"

                                                              When working with web maps, often it is more convenient to talk about zoom levels instead of scales. The relationship between zoom and scale is context dependent.

                                                              For example, for EPSG:4326 with world boundaries, zoom level 0 (completely zoomed out) corresponds to a scale of approximately 279,541,000 with each subsequent zoom level having half the scale value. For EPSG:3857 (Web Mercator) with world boundaries, zoom level 0 corresponds to a scale of approximately 559,082,000, again with each subsequent zoom level having half the scale value.

                                                              But since zoom levels are discrete (0, 1, 2, etc.) and scale levels are continuous, it's actually a range of scale levels that corresponds to a given zoom level.

                                                              For example, if you have a situation where a zoom level 0 corresponds to a scale of 1,000,000 (and each subsequent zoom level is half that scale, as is common), you can set the scale values of your rules to be:

                                                              • scale: [750000,1500000] (includes 1,000,000)
                                                              • scale: [340000,750000] (includes 500,000)
                                                              • scale: [160000,340000] (includes 250,000)
                                                              • scale: [80000,160000] (includes 125,000)
                                                              • etc.

                                                              Also be aware of the inverse relationship between scale and zoom; as the zoom level increases, the scale decreases.

                                                              "},{"location":"styling/ysld/reference/scalezoom/#zoom-syntax","title":"Zoom syntax","text":"

                                                              In certain limited cases, it can be more useful to specify scales by way of zoom levels for predefined gridsets. These can be any predefined gridsets in GeoServer.

                                                              Inside a rule, the syntax for using zoom levels is:

                                                              rules:\n- ...\n  zoom: [<min>, <max>]\n  ...\n

                                                              where:

                                                              Attribute Required? Description Default value

                                                              min Yes The minimum zoom level for which the rule will be applied. Value is an integer. N/A

                                                              max Yes The maximum zoom level for which the rule will be applied. Value is an integer. N/A

                                                              Note

                                                              It is not possible to use an expression for any of these values.

                                                              As with scales, use the literal strings min and max to denote where there are no lower or upper scale boundaries. For example, to denote that the zoom level is anything less than some <max> value:

                                                              zoom: [min,<max>]\n

                                                              To denote that the zoom level is anything greater than or equal to some <min> value:

                                                              zoom: [<min>,max]\n

                                                              Note

                                                              In the above examples, min and max are always literals, entered exactly like that, while <min> and <max> would be replaced by actual scalar values.

                                                              The scale and zoom parameters should not be used together in a rule (but if used, scale takes priority over zoom).

                                                              "},{"location":"styling/ysld/reference/scalezoom/#specifying-a-grid","title":"Specifying a grid","text":"

                                                              While every web map can have zoom levels, the specific relationship between a zoom level and its scale is dependent on the gridset (spatial reference system, extent, etc.) used.

                                                              So when specifying zoom levels in YSLD, you should also specify the grid.

                                                              The grid parameter should remain at the top of the YSLD content, above any Feature Styles or Rules. The syntax is:

                                                              grid:\n  name: <string>\n

                                                              where:

                                                              Property Required? Description Default value

                                                              name No WGS84, WebMercator, or a name of a predefined gridset in GeoServer. WebMercator

                                                              Note

                                                              As many web maps use \"web mercator\" (also known as EPSG:3857 or EPSG:900913), this is assumed to be the default if no grid is specified.

                                                              Warning

                                                              As multiple gridsets can contain the same SRS, we recommend naming custom gridsets by something other than the EPSG code.

                                                              "},{"location":"styling/ysld/reference/scalezoom/#zoom-examples","title":"Zoom examples","text":""},{"location":"styling/ysld/reference/scalezoom/#default-gridset","title":"Default gridset","text":"

                                                              Given the default of web mercator (also known as EPSG:3857 or EPSG:900913), which requires no grid designation, this defines zoom levels as the following scale levels (rounded to the nearest whole number below):

                                                              Scale Zoom level 559082264 0 279541132 1 139770566 2 69885283 3 34942641 4 17471321 5 8735660 6 4367830 7 2183915 8 <previous_scale> / 2 <previous_zoom> + 1"},{"location":"styling/ysld/reference/scalezoom/#named-gridsets","title":"Named gridsets","text":"

                                                              For the existing gridset of WGS84 (often known as EPSG:4326):

                                                              grid:\n  name: WGS84\n

                                                              This defines zoom levels as the following scale levels (rounded to the nearest whole number below):

                                                              Scale Zoom level 559082264 0 279541132 1 139770566 2 69885283 3 34942641 4 17471321 5 8735660 6 4367830 7 2183915 8 <previous_scale> / 2 <previous_zoom> + 1

                                                              Given a custom named gridset called NYLongIslandFtUS, defined by a CRS of EPSG:2263 and using its full extent:

                                                              grid:\n  name: NYLongIslandFtUS\n

                                                              This defines zoom levels as the following (rounded to the nearest whole number below):

                                                              Scale Zoom level 4381894 0 2190947 1 1095473 2 547736 3 273868 4 136934 5 68467 6 34234 7 17117 8 <previous_scale> / 2 <previous_zoom> + 1

                                                              Note

                                                              These scale values can be verified in GeoServer on the Gridsets page under the definition for the gridset:

                                                              Gridset defined in GeoServer

                                                              Specifically, note the Scale values under Tile Matrix Set.

                                                              "},{"location":"styling/ysld/reference/structure/","title":"Structure","text":"

                                                              Here is a simple example of a YSLD style containing a single rule inside a single feature style:

                                                              name: style_example\ntitle: An example of YSLD styling\nabstract: Used in the User Manual of GeoServer\nfeature-styles:\n- rules:\n  - name: all\n    title: Every feature will be styled this way\n    symbolizers:\n    - polygon:\n        fill-color: '#808080'\n        fill-opacity: 0.5\n        stroke-color: '#000000'\n        stroke-opacity: 0.75\n

                                                              This would style every polygon feature in a given layer with the given RGB color codes (a medium gray for a fill and black for the outline), with the given opacities for both fill and stroke being given in decimals indicating percentage (so 0.5 is 50% opaque).

                                                              Note

                                                              For more details on syntax, please see the section on symbolizers.

                                                              The structure of a typical YSLD file is as follows:

                                                              +--------------------------------------+-----------------------------------------------------------------------------------------------------+ | Structure | Description | +======================================+=====================================================================================================+ | Variable definitions | For common style settings | +--------------------------------------+-----------------------------------------------------------------------------------------------------+ | Scale grid / zoom levels | Used to define style based on tile set zoom level | +--------------------------------------+-----------------------------------------------------------------------------------------------------+ | style header | Document name, title, and abstract followed by feature-styles | | | | | | | +--------------------------------------+-----------------------------------------------------------------------------------------------------+ | feature style | Independent block that can contain one or many rules. | | | | | | | +--------------------------------------+-----------------------------------------------------------------------------------------------------+ | rule | Directive that can contain one or many symbolizers. | | | | | | | +--------------------------------------+-----------------------------------------------------------------------------------------------------+ | filter | A rule \"includes\" all features unless made to be selective by the use of a filter. | | | | | | | +--------------------------------------+-----------------------------------------------------------------------------------------------------+ | symbolizers | basic unit of a style containing the actual visualization instructions for individual features. | +--------------------------------------+-----------------------------------------------------------------------------------------------------+

                                                              The structure YSLD files is outlined using indentation.

                                                              Structure of YSLD style_example

                                                              "},{"location":"styling/ysld/reference/structure/#property-syntax","title":"Property syntax","text":"

                                                              Individual statements (or directives) in a YSLD styling document are designed as key-value, or property-value pairs of the following form:

                                                              <property>: <value>\n

                                                              The <property> is a string denoting the property name, while the <value> can be one of a number of different types depending on context. These different types require slightly different markup, as shown in the following table:

                                                              +-------------------------------------------+------------------------------+----------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Type | Syntax | Example | Notes | +===========================================+==============================+======================+=========================================================================================================================================================================================================================================================================================================================+ | Integer | Value only | 12 | Quotes allowed as well | +-------------------------------------------+------------------------------+----------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Float | Value only | 0.75 | Quotes allowed as well | +-------------------------------------------+------------------------------+----------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Text | Quotes | Title | Spaces, colons, and other special characters are allowed. If value is ambiguous, use single quotes. | +-------------------------------------------+------------------------------+----------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Color | - '# + six digits' (hex) | - '#FF00FF' | Used when specifying RGB colors. For hex, use '#RRGGBB' with each two character pair having a value from 00 to FF. For decimal, use rgb(rrr,ggg,bbb) with each ordinate having a value from 0 to 255. Quotes are not required when using named colors. | | | - rgb(r,g,b) (decimal) | - rgb(255,0,255) | | | | - Text (named colors) | - fuchsia | | +-------------------------------------------+------------------------------+----------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Tuple | Brackets | [0,15000] | Use two single quotes to denote blank entries in the tuple (for example: ['#FFFFFF',0,0,'']). | +-------------------------------------------+------------------------------+----------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Filter or other expression | \\${} | ${type = road} | If attribute name is ambiguous, encase in brackets (for example: ${[type] = road}). If value is ambiguous, use single quotes (${type = 'road'}). | +-------------------------------------------+------------------------------+----------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+"},{"location":"styling/ysld/reference/structure/#expressions","title":"Expressions","text":"

                                                              Throughout the reference guide, there are references to values that are denoted by <expression>. An expression is a flexible term meaning that the value can be one of the following kinds of objects:

                                                              • Literal (scalar or string)
                                                              • Attribute name
                                                              • Function

                                                              If using a function, it must evaluate to match the type expected by the property.

                                                              "},{"location":"styling/ysld/reference/structure/#mappings-and-lists","title":"Mappings and lists","text":"

                                                              Note

                                                              The following discussion is taken from basic YAML syntax. Please refer to the YAML specification if necessary.

                                                              There are three types of objects in a YSLD document:

                                                              1. Scalar, a simple value
                                                              2. Mapping, a collection of key-value (property-value) pairs
                                                              3. List, any collection of objects. A list can contain mappings, scalars, and even other lists.

                                                              Lists require dashes for every entry, while mappings do not.

                                                              For example, a symbolizer block is a list, so every entry requires its own dash:

                                                              - symbolizer:\n  - polygon:\n      ...\n  - text:\n      ...\n

                                                              The point: and text: objects (the individual symbolizers themselves) are mappings, and as such, the contents do not require dashes, only indents:

                                                              - polygon:\n    stroke-color: '#808080'\n    fill-color: '#FF0000'\n

                                                              The dash next to polygon means that the item itself is contained in a list, not that it contains a list. And the placement of the dash is at the same level of indentation as the list title.

                                                              It is sometimes not obvious whether an object should be a list (and use dashes) or a mapping (and not use dashes), so please refer to this table if unsure:

                                                              Object Type Feature style List Rule List Symbolizer List Individual symbolizers (contents) Mapping Transform Mapping Color table (for raster symbolizers) List"},{"location":"styling/ysld/reference/structure/#ysld_reference_structure_indentation","title":"Indentation","text":"

                                                              Indentation is very important in YSLD. All directives must be indented to its proper place to ensure proper hierarchy. Improper indentation will cause a style to be rendered incorrectly, or not at all.

                                                              For example, the polygon symbolizer, since it is a mapping, contains certain parameters inside it, such as the color of the fill and stroke. These must be indented such that they are \"inside\" the polygon block.

                                                              In this example, the following markup is correct:

                                                              - polygon:\n    fill-color: '#808080'\n    fill-opacity: 0.5\n    stroke-color: black\n    stroke-opacity: 0.75\n

                                                              The parameters inside the polygon (symbolizer) are indented, meaning that they are referencing the symbolizer and are not \"outside it.\"

                                                              Compare to the following incorrect markup:

                                                              - polygon:\n  fill-color: '#808080'\n  fill-opacity: 0.5\n  stroke-color: black\n  stroke-opacity: 0.75\n

                                                              The parameters that are relevant to the polygon block here need to be contained inside that block. Without the parameters being indented, they are at the same \"level\" as the polygon block, and so will not be interpreted correctly.

                                                              Note

                                                              For more details on symbolizer syntax, please see the section on symbolizers.

                                                              "},{"location":"styling/ysld/reference/structure/#wrapped-lines","title":"Wrapped lines","text":"

                                                              Long lines can be wrapped by indenting each subsequent line in the text block. New line characters will be converted to spaces, so each line should not end with a space.

                                                              So in a situation with a long value:

                                                              - name: shortname\n  title: Longer name\n  abstract: This is a really long abstract that in no way is ever likely to fit on a single line on most people's displays.\n

                                                              This can be altered to look like:

                                                              - name: shortname\n  title: Longer name\n  abstract: This is a really long abstract that in no way\n            is ever likely to fit on a single line on most\n            people's displays.\n

                                                              In both cases, the value for abstract is unchanged.

                                                              Wrapped lines can be done between properties and values as well. So this single line:

                                                              stroke-width: ${roadwidth / 500}\n

                                                              Can be altered to look like:

                                                              stroke-width:\n  ${roadwidth / 500}\n

                                                              The only constraint with using wrapped lines is that the subsequent lines need to be indented.

                                                              "},{"location":"styling/ysld/reference/structure/#comments","title":"Comments","text":"

                                                              Comments are allowed in YSLD, both for descriptive reasons and to remove certain styling directives without deleting them outright. Comments are indicated by a # as the first non-blank-space character in a line. For example:

                                                              # This is a line symbolizer\n- line:\n    stroke-color: '#000000'\n    stroke-width: 2\n#   stroke-width: 3\n

                                                              The above would display the lines with width of 2; the line showing a width of 3 is commented out.

                                                              Comment blocks do not exist, so each line of a comment will need to be indicated as such:

                                                              - line:\n    stroke-color: '#000000'\n    stroke-width: 2\n#- line:\n#    stroke-color: '#FF0000'\n#    stroke-width: 3\n

                                                              Note

                                                              Comments are not preserved when converting to SLD.

                                                              "},{"location":"styling/ysld/reference/transforms/","title":"Transforms","text":"

                                                              YSLD allows for the use of rendering transformations. Rendering transformations are processes on the server that are executed inside the rendering pipeline, to allow for dynamic data transformations. In GeoServer, rendering transformations are typically exposed as WPS processes.

                                                              For example, one could create a style that applies to a point layer, and applies a Heatmap process as a rendering transformation, making the output a (raster) heatmap.

                                                              Because rendering transformations can change the geometry type, it is important to make sure that the symbolizer used matches the output of the rendering transformation, not the input. In the above heatmap example, the appropriate symbolizer would be a raster symbolizer, as the output of a heatmap is a raster.

                                                              "},{"location":"styling/ysld/reference/transforms/#syntax","title":"Syntax","text":"

                                                              The full syntax for using a rendering transformation is:

                                                              feature-styles\n  ...\n  transform:\n    name: <text>\n    params: <options>\n  rules:\n    ...\n

                                                              where:

                                                              Property Required? Description Default value

                                                              name Yes Full name of the rendering transform including any prefixes (such as vec:Heatmap) N/A

                                                              params Yes All input parameters for the rendering transformation. Content will vary greatly based on the amount and type of parameters needed. N/A

                                                              The values in the params options typically include values, strings, or attributes. However, it can be useful with a transformation to include environment parameters that concern the position and size of the map when it is rendered. For example, the following are common reserved environment parameters:

                                                              Environment parameter Description

                                                              env('wms_bbox') The bounding box of the request

                                                              env('wms_width') The width of the request

                                                              env('wms_height') The height of the request

                                                              With this in mind, the following params are assumed unless otherwise specified:

                                                              params:\n  ...\n  outputBBOX: ${env('wms_bbox')}\n  outputWidth: ${env('wms_width')}\n  outputHeight: ${env('wms_height')}\n  ...\n

                                                              Note

                                                              Be aware that the transform happens outside of the rules and symbolizers, but inside the feature styles.

                                                              "},{"location":"styling/ysld/reference/transforms/#examples","title":"Examples","text":""},{"location":"styling/ysld/reference/transforms/#heatmap","title":"Heatmap","text":"

                                                              The following uses the vec:Heatmap process to convert a point layer to a heatmap raster:

                                                              title: Heatmap\nfeature-styles:\n- transform:\n    name: vec:Heatmap\n    params:\n      weightAttr: pop2000\n      radiusPixels: 100\n      pixelsPerCell: 10\n  rules:\n  - symbolizers:\n    - raster:\n        opacity: 0.6\n        color-map:\n          type: ramp\n          entries:\n          - ['#FFFFFF',0,0.0,nodata]\n          - ['#4444FF',1,0.1,nodata]\n          - ['#FF0000',1,0.5,values]\n          - ['#FFFF00',1,1.0,values]\n
                                                              "},{"location":"styling/ysld/reference/transforms/#point-stacker","title":"Point Stacker","text":"

                                                              The point stacker transform can be used to combine points that are close together. This transform acts on a point geometry layer, and combines any points that are within a single cell as specified by the cellSize parameter. The resulting geometry has attributes geom (the geometry), count (the number of features represented by this point) and countUnique (the number of unique features represented by this point). These attributes can be used to size and label the points based on how many points are combined together:

                                                              title: pointstacker\nfeature-styles:\n- transform:\n    name: vec:PointStacker\n    params:\n    cellSize: 100\n  rules:\n  - symbolizers:\n    - point:\n        size: ${8*sqrt(count)}\n        symbols:\n        - mark:\n            shape: circle\n            fill-color: '#EE0000'\n  - filter: count > 1\n    symbolizers:\n    - text:\n          fill-color: '#FFFFFF'\n          font-family: Arial\n          font-size: 10\n          font-weight: bold\n          label: ${count}\n          placement:\n              anchor: [0.5,0.75]\n

                                                              Point stacker

                                                              "},{"location":"styling/ysld/reference/variables/","title":"Define and reuse YAML Variables","text":"

                                                              Variables in YSLD that allow for a certain directive or block of directives to be defined by name and later reused. This can greatly simplify the styling document.

                                                              The two most-common use cases for using variables are:

                                                              • To create a more-friendly name for a value (such as using myorange instead of #EE8000)
                                                              • To define a block of directives to remove redundant content and to decrease file length

                                                              It is customary, but not required, to place all definitions at the very top of the YSLD file, above all header information, feature styles, or rules.

                                                              "},{"location":"styling/ysld/reference/variables/#syntax","title":"Syntax","text":""},{"location":"styling/ysld/reference/variables/#define-a-single-value","title":"Define a single value","text":"

                                                              The syntax for defining a variable as a single value is:

                                                              define: &variable <value>\n

                                                              where:

                                                              Attribute Required? Description Default value

                                                              define Yes Starts the definition block. N/A

                                                              &variable Yes The name of the variable being defined. The & is not part of the variable name. N/A

                                                              <value> Yes A single value, such as 512 or '#DD0000' N/A

                                                              The syntax for using this variable is to prepend the variable name with a *:

                                                              <directive>: *variable\n

                                                              This variable can be used in any place where its type is expected.

                                                              "},{"location":"styling/ysld/reference/variables/#define-a-directive-block","title":"Define a directive block","text":"

                                                              The syntax for defining a variable as a content block is:

                                                              define: &varblock\n  <directive>: <value>\n  <directive>: <value>\n  ...\n  <block>:\n  - <directive>: <value>\n    <directive>: <value>\n  ...\n

                                                              Any number of directives or blocks of directives can be inside the definition block. Moreover, any type of directive that is valid YSLD can be included in the definition, so long as the content block could be substituted for the variable without modification.

                                                              Note

                                                              It is also possible to have nested definitions.

                                                              The syntax for using this variable is to prepend the variable name with <<: *. For example:

                                                              <block>:\n- <directive>: <value>  \n  <<: *varblock\n

                                                              The line that contains the variable will be replaced with the contents of the definition.

                                                              "},{"location":"styling/ysld/reference/variables/#examples","title":"Examples","text":""},{"location":"styling/ysld/reference/variables/#define-variables-to-reuse-colors","title":"Define variables to reuse colors","text":"

                                                              Name background color for both polygon fill and halo outline:

                                                              define: &background_color '#998088'\ndefine: &text_color \"#111122\"\n\nfeature-styles:\n- rules:\n  - symbolizers:\n    - polygon:\n        stroke-width: 1\n        fill-color: *background_color\n    - text:\n        label: ${name}\n        fill-color: *text_color\n        halo:\n           radius: 2\n           fill-color: *background_color\n           fill-opacity: 0.8\n
                                                              "},{"location":"styling/ysld/reference/variables/#define-block-to-reuse-stroke","title":"Define block to reuse stroke","text":"

                                                              Define a block of stroke parameters for reuse in each rule:

                                                              define: &stroke_style\n  stroke: '#FF0000'\n  stroke-width: 2\n  stroke-opacity: 0.5\n\nfeature-styles:\n- rules:\n  - filter: ${pop < '200000'}\n    symbolizers:\n    - polygon:\n        <<: *stroke_style\n        fill-color: '#66FF66'\n  - filter: ${pop BETWEEN '200000' AND '500000'}\n    symbolizers:\n    - polygon:\n        <<: *stroke_style\n        fill-color: '#33CC33'\n  - filter: ${pop > '500000'}\n    symbolizers:\n    - polygon:\n        <<: *stroke_style\n        fill-color: '009900'\n
                                                              "},{"location":"styling/ysld/reference/symbolizers/","title":"Symbolizers","text":"

                                                              The basic unit of visualization is the symbolizer. There are five types of symbolizers: Point, Line, Polygon, Raster, and Text.

                                                              Symbolizers are contained inside rules. A rule can contain one or many symbolizers.

                                                              Note

                                                              The most common use case for multiple symbolizers is a geometry (point/line/polygon) symbolizer to draw the features plus a text symbolizer for labeling these features.

                                                              Use of multiple symbolizers

                                                              "},{"location":"styling/ysld/reference/symbolizers/#drawing-order","title":"Drawing order","text":"

                                                              The order of symbolizers significant, and also the order of your data.

                                                              For each feature the rules are evaluated resulting in a list of symbolizers that will be used to draw that feature. The symbolizers are drawn in the order provided.

                                                              Consider the following two symbolizers:

                                                              symbolizers:\n- point:\n    symbols:\n    - mark:\n        shape: square\n        fill-color: '#FFCC00'\n- point:\n    symbols:\n    - mark:\n        shape: triangle\n        fill-color: '#FF3300'\n

                                                              When drawing three points these symbolizers will be applied in order on each feature:

                                                              1. Feature 1 is drawn as a square, followed by a triangle:

                                                                Feature 1 buffer rendering

                                                              2. Feature 2 is drawn as a square, followed by a triangle. Notice the slight overlap with Feature 1:

                                                                Feature 2 buffer rendering

                                                              3. Feature 3 is drawn as a square, followed by a triangle:

                                                                Feature 3 buffer rendering

                                                              Note

                                                              In the final image, Feature 1 and Feature 2 have a slight overlap. This overlap is determined by data order which we have no control over. If you need to control the overlap review the Feature Styles section on managing \"z-order\".

                                                              Feature style controlling z-order

                                                              "},{"location":"styling/ysld/reference/symbolizers/#matching-symbolizers-and-geometries","title":"Matching symbolizers and geometries","text":"

                                                              It is common to match the symbolizer with the type of geometries contained in the layer, but this is not required. The following table illustrates what will happen when a geometry symbolizer is matched up with another type of geometry.

                                                              Points Lines Polygon Raster Point Symbolizer Points Midpoint of the lines Centroid of the polygons Centroid of the raster Line Symbolizer n/a Lines Outline (stroke) of the polygons Outline (stroke) of the raster Polygon Symbolizer n/a Will \"close\" the line and style as a polygon Polygons Will \"outline\" the raster and style as a polygon Raster Symbolizer n/a n/a n/a Transform raster values to color channels for display Text Symbolizer Label at point location Label at midpoint of lines Label at centroid of polygons Label at centroid of raster outline"},{"location":"styling/ysld/reference/symbolizers/#syntax","title":"Syntax","text":"

                                                              The following is the basic syntax common to all symbolizers. Note that the contents of the block are not all expanded here and that each kind of symbolizer provides additional syntax.

                                                              geometry: <cql>\nuom: <text>\n..\nx-composite: <text>\nx-composite-base: <boolean>\nx-inclusion: <text>\n

                                                              Where:

                                                              .. list-table:: :class: non-responsive :header-rows: 1 :stub-columns: 1 :widths: 20 10 50 20

                                                                • Property
                                                                • Required?
                                                                • Description
                                                                • Default value
                                                                • geometry
                                                                • No
                                                                • Specifies which attribute to use as the geometry (see :ref:geometry_transformations)
                                                                • First geometry attribute found (usually named geom or the_geom)
                                                                • uom
                                                                • No
                                                                • Unit of measure used for width calculations (see :ref:unit_of_measure)
                                                                • pixel

                                                              Additional \"vendor options\" properties for :ref:sld-extensions_composite-blend:

                                                              .. list-table:: :class: non-responsive :header-rows: 1 :stub-columns: 1 :widths: 20 10 50 20

                                                                • Property
                                                                • Required?
                                                                • Description
                                                                • Default value
                                                                • x-composite
                                                                • No
                                                                • Allows for both alpha compositing and color blending options between symbolizers.
                                                                • N/A
                                                                • x-composite-base
                                                                • No
                                                                • Allows the rendering engine to use the symbolizer mapping to define a \"base\" buffer for subsequent compositing and blending using x-composite. See the section on :ref:Feature Styles <ysld_reference_featurestyles_composite> for more details.
                                                                • false

                                                              Additional \"vendor options\" properties for :ref:rendering_selection:

                                                              .. list-table:: :class: non-responsive :header-rows: 1 :stub-columns: 1 :widths: 20 10 50 20

                                                                • Property
                                                                • Required?
                                                                • Description
                                                                • Default value
                                                                • x-inclusion
                                                                • No
                                                                • Define if rule should be included in style for legendOnly or mapOnly.
                                                                • normal
                                                              "},{"location":"styling/ysld/reference/symbolizers/line/","title":"Line symbolizer","text":"

                                                              The line symbolizer is used to style linear (1-dimensional) features. It is in some ways the simplest of the symbolizers because it only contains facilities for the stroke (outline) of a feature.

                                                              "},{"location":"styling/ysld/reference/symbolizers/line/#syntax","title":"Syntax","text":"

                                                              The full syntax of a line symbolizer is:

                                                              symbolizers:\n- line:\n    stroke-color: <color>\n    stroke-width: <expression>\n    stroke-opacity: <expression>\n    stroke-linejoin: <expression>\n    stroke-linecap: <expression>\n    stroke-dasharray: <float list>\n    stroke-dashoffset: <expression>\n    stroke-graphic: \n      <graphic_options>\n    stroke-graphic-fill: \n      <graphic_options>\n    offset: <expression>\n    geometry: <expression>\n    uom: <text>\n    x-labelObstacle: <boolean>\n    x-composite-base: <boolean>\n    x-composite: <text>\n    x-inclusion: <text>\n

                                                              where:

                                                              .. list-table:: :class: non-responsive :header-rows: 1 :stub-columns: 1 :widths: 20 10 50 20

                                                                • Property
                                                                • Required?
                                                                • Description
                                                                • Default value
                                                                • stroke-color
                                                                • No
                                                                • Color of line features.
                                                                • '#000000' (black)
                                                                • stroke-width
                                                                • No
                                                                • Width of line features, measured in pixels.
                                                                • 1
                                                                • stroke-opacity
                                                                • No
                                                                • Opacity of line features. Valid values are a decimal value between 0 (completely transparent) and 1 (completely opaque).
                                                                • 1
                                                                • stroke-linejoin
                                                                • No
                                                                • How line segments are joined together. Options are mitre (sharp corner), round (round corner), and bevel (diagonal corner).
                                                                • mitre
                                                                • stroke-linecap
                                                                • No
                                                                • How line features are rendered at their ends. Options are butt (sharp square edge), round (rounded edge), and square (slightly elongated square edge).
                                                                • butt
                                                                • stroke-dasharray
                                                                • No
                                                                • A numeric list signifying length of lines and gaps, creating a dashed effect. Units are pixels, so \"2 3\" would be a repeating pattern of 2 pixels of drawn line followed by 3 pixels of blank space. If only one number is supplied, this will mean equal amounts of line and gap.
                                                                • No dash
                                                                • stroke-dashoffset
                                                                • No
                                                                • Number of pixels into the dasharray to offset the drawing of the dash, used to shift the location of the lines and gaps in a dash.
                                                                • 0
                                                                • stroke-graphic
                                                                • No
                                                                • A design or pattern to be used along the stroke. Output will always be a linear repeating pattern, and as such is not tied to the value of stroke-width. Can either be a mark consisting of a common shape or a URL that points to a graphic. The <graphic_options> should consist of a mapping containing symbols: followed by an external: or mark:, with appropriate parameters as detailed in the :ref:ysld_reference_symbolizers_point section. Cannot be used with stroke-graphic-fill.
                                                                • N/A
                                                                • stroke-graphic-fill
                                                                • No
                                                                • A design or pattern to be used for the fill of the stroke. The area that is to be filled is tied directly to the value of stroke-width. Can either be a mark consisting of a common shape or a URL that points to a graphic. The <graphic_options> should consist of a mapping containing symbols: followed by an external: or mark:, with appropriate parameters as detailed in the :ref:ysld_reference_symbolizers_point section. Cannot be used with stroke-graphic.
                                                                • N/A

                                                              Property Required? Description Default value

                                                              offset No Value in pixels for moving the drawn line relative to the location of the feature. 0

                                                              .. list-table:: :class: non-responsive :header-rows: 1 :stub-columns: 1 :widths: 20 10 50 20

                                                                • Property
                                                                • Required?
                                                                • Description
                                                                • Default value
                                                                • geometry
                                                                • No
                                                                • Specifies which attribute to use as the geometry (see :ref:geometry_transformations)
                                                                • First geometry attribute found (usually named geom or the_geom)
                                                                • uom
                                                                • No
                                                                • Unit of measure used for width calculations (see :ref:unit_of_measure)
                                                                • pixel

                                                              Additional \"vendor options\" property for :ref:label_obstacles:

                                                              .. list-table:: :class: non-responsive :header-rows: 1 :stub-columns: 1 :widths: 20 10 50 20

                                                                • Property
                                                                • Required?
                                                                • Description
                                                                • Default value
                                                                • x-labelObstacle
                                                                • No
                                                                • Marks the symbolizer as an obstacle such that labels drawn via a :ref:text symbolizer <ysld_reference_symbolizers_text> will not be drawn over top of these features. Options are true or false. Note that the bounding boxes of features are used when calculating obstacles, so unintended effects may occur when marking a line or polygon symbolizer as an obstacle.
                                                                • false

                                                              Additional \"vendor options\" properties for :ref:sld-extensions_composite-blend:

                                                              .. list-table:: :class: non-responsive :header-rows: 1 :stub-columns: 1 :widths: 20 10 50 20

                                                                • Property
                                                                • Required?
                                                                • Description
                                                                • Default value
                                                                • x-composite
                                                                • No
                                                                • Allows for both alpha compositing and color blending options between symbolizers.
                                                                • N/A
                                                                • x-composite-base
                                                                • No
                                                                • Allows the rendering engine to use the symbolizer mapping to define a \"base\" buffer for subsequent compositing and blending using x-composite. See the section on :ref:Feature Styles <ysld_reference_featurestyles_composite> for more details.
                                                                • false

                                                              Additional \"vendor options\" properties for :ref:rendering_selection:

                                                              .. list-table:: :class: non-responsive :header-rows: 1 :stub-columns: 1 :widths: 20 10 50 20

                                                                • Property
                                                                • Required?
                                                                • Description
                                                                • Default value
                                                                • x-inclusion
                                                                • No
                                                                • Define if rule should be included in style for legendOnly or mapOnly.
                                                                • normal
                                                              "},{"location":"styling/ysld/reference/symbolizers/line/#examples","title":"Examples","text":""},{"location":"styling/ysld/reference/symbolizers/line/#basic-line-with-styled-ends","title":"Basic line with styled ends","text":"

                                                              The linejoin and linecap properties can be used to style the joins and ends of any stroke. This example draws lines with partially transparent black lines with rounded ends and sharp (mitred) corners:

                                                              feature-styles:\n- rules:\n  - symbolizers:\n    - line:\n        stroke-color: '#000000'\n        stroke-width: 8\n        stroke-opacity: 0.5\n        stroke-linejoin: mitre\n        stroke-linecap: round\n

                                                              Basic line with styled ends

                                                              "},{"location":"styling/ysld/reference/symbolizers/line/#railroad-pattern","title":"Railroad pattern","text":"

                                                              Todo

                                                              Fix this example

                                                              Many maps use a hatched pattern to represent railroads. This can be accomplished by using two line symbolizers, one solid and one dashed. Specifically, the stroke-dasharray property is used to create a dashed line of length 1 every 24 pixels:

                                                              name: railroad\nfeature-styles:\n- name: name\n  rules:\n  - symbolizers:\n    - line:\n        stroke-color: '#000000'\n        stroke-width: 1\n    - line:\n        stroke-color: '#000000'\n        stroke-width: 12\n        stroke-dasharray: '1 24'\n

                                                              Railroad pattern

                                                              "},{"location":"styling/ysld/reference/symbolizers/line/#specifying-sizes-in-units","title":"Specifying sizes in units","text":"

                                                              The units for stroke-width, size, and other similar attributes default to pixels, meaning that graphics remain a constant size at different zoom levels. Alternately, units (feet or meters) can be specified for values, so graphics will scale as you zoom in or out. This example draws roads with a fixed width of 8 meters:

                                                              feature-styles:\n- rules:\n  - symbolizers:\n    - line:\n        stroke-color: '#000000'\n        stroke-width: '8 m'\n

                                                              Line width measured in meters (zoomed out)

                                                              Line width measured in meters (zoomed in)

                                                              The default unit of measure for the symbolizer is defined using uom. This example uses a default of meters to supply distances for stroke-width and stroke-dasharray using meters.

                                                              line:\n  uom: metre\n  stroke-color: '#000000'\n  stroke-width: '8'\n  stroke-dasharray: '20 3'\n

                                                              Line width and spacing in meters

                                                              "},{"location":"styling/ysld/reference/symbolizers/point/","title":"Point symbolizer","text":"

                                                              The point symbolizer is used to style point features or centroids of non-point features.

                                                              "},{"location":"styling/ysld/reference/symbolizers/point/#syntax","title":"Syntax","text":"

                                                              The full syntax of a point symbolizer is:

                                                              symbolizers:\n- point:\n    symbols:\n    - external:\n        url: <text>\n        format: <text>\n    - mark:\n        shape: <shape>\n        fill-color: <color>\n        fill-opacity: <expression>\n        fill-graphic: \n          <graphic_options>\n        stroke-color: <color>\n        stroke-width: <expression>\n        stroke-opacity: <expression>\n        stroke-linejoin: <expression>\n        stroke-linecap: <expression>\n        stroke-dasharray: <float list>\n        stroke-dashoffset: <expression>\n        stroke-graphic: \n          <graphic_options>\n        stroke-graphic-fill: \n          <graphic_options>\n    size: <expression>\n    anchor: <tuple>\n    displacement: <tuple>\n    opacity: <expression>\n    rotation: <expression>\n    geometry: <expression>\n    uom: <text>\n    x-labelObstacle: <boolean>\n    x-composite-base: <boolean>\n    x-composite: <text>\n    x-inclusion: <text>\n

                                                              where:

                                                              .. list-table:: :class: non-responsive :header-rows: 1 :stub-columns: 1 :widths: 20 10 50 20

                                                                • Property
                                                                • Required?
                                                                • Description
                                                                • Default value
                                                                • stroke-color
                                                                • No
                                                                • Color of line features.
                                                                • '#000000' (black)
                                                                • stroke-width
                                                                • No
                                                                • Width of line features, measured in pixels.
                                                                • 1
                                                                • stroke-opacity
                                                                • No
                                                                • Opacity of line features. Valid values are a decimal value between 0 (completely transparent) and 1 (completely opaque).
                                                                • 1
                                                                • stroke-linejoin
                                                                • No
                                                                • How line segments are joined together. Options are mitre (sharp corner), round (round corner), and bevel (diagonal corner).
                                                                • mitre
                                                                • stroke-linecap
                                                                • No
                                                                • How line features are rendered at their ends. Options are butt (sharp square edge), round (rounded edge), and square (slightly elongated square edge).
                                                                • butt
                                                                • stroke-dasharray
                                                                • No
                                                                • A numeric list signifying length of lines and gaps, creating a dashed effect. Units are pixels, so \"2 3\" would be a repeating pattern of 2 pixels of drawn line followed by 3 pixels of blank space. If only one number is supplied, this will mean equal amounts of line and gap.
                                                                • No dash
                                                                • stroke-dashoffset
                                                                • No
                                                                • Number of pixels into the dasharray to offset the drawing of the dash, used to shift the location of the lines and gaps in a dash.
                                                                • 0
                                                                • stroke-graphic
                                                                • No
                                                                • A design or pattern to be used along the stroke. Output will always be a linear repeating pattern, and as such is not tied to the value of stroke-width. Can either be a mark consisting of a common shape or a URL that points to a graphic. The <graphic_options> should consist of a mapping containing symbols: followed by an external: or mark:, with appropriate parameters as detailed in the :ref:ysld_reference_symbolizers_point section. Cannot be used with stroke-graphic-fill.
                                                                • N/A
                                                                • stroke-graphic-fill
                                                                • No
                                                                • A design or pattern to be used for the fill of the stroke. The area that is to be filled is tied directly to the value of stroke-width. Can either be a mark consisting of a common shape or a URL that points to a graphic. The <graphic_options> should consist of a mapping containing symbols: followed by an external: or mark:, with appropriate parameters as detailed in the :ref:ysld_reference_symbolizers_point section. Cannot be used with stroke-graphic.
                                                                • N/A

                                                              .. list-table:: :class: non-responsive :header-rows: 1 :stub-columns: 1 :widths: 20 10 50 20

                                                                • Property
                                                                • Required?
                                                                • Description
                                                                • Default value
                                                                • fill-color
                                                                • No
                                                                • Color of inside of features.
                                                                • '#808080' (gray)
                                                                • fill-opacity
                                                                • No
                                                                • Opacity of the fill. Valid values are a decimal value between 0 (completely transparent) and 1 (completely opaque).
                                                                • 1
                                                                • fill-graphic
                                                                • No
                                                                • A design or pattern to be used for the fill of the feature. Can either be a mark consisting of a common shape or a URL that points to a graphic. The <graphic_options> should consist of a mapping containing symbols: followed by an external: or mark:, with appropriate parameters as detailed in the :ref:ysld_reference_symbolizers_point section.
                                                                • None

                                                              The use of fill-graphic allows for the following extra options:

                                                              .. list-table:: :class: non-responsive :header-rows: 1 :stub-columns: 1 :widths: 20 10 50 20

                                                                • Property
                                                                • Required?
                                                                • Description
                                                                • Default value
                                                                • x-graphic-margin
                                                                • No
                                                                • Used to specify margins (in pixels) around the graphic used in the fill. Possible values are a list of four (top, right, bottom, left), a list of three (top, right and left, bottom), a list of two (top and bottom, right and left), or a single value.
                                                                • N/A
                                                                • x-random
                                                                • No
                                                                • Activates random distribution of symbols. Possible values are free or grid. free generates a completely random distribution, and grid will generate a regular grid of positions, and only randomize the position of the symbol around the cell centers, providing a more even distribution.
                                                                • N/A
                                                                • x-random-tile-size
                                                                • No
                                                                • When used with x-random, determines the size of the grid (in pixels) that will contain the randomly distributed symbols.
                                                                • 256
                                                                • x-random-rotation
                                                                • No
                                                                • When used with x-random, activates random symbol rotation. Possible values are none or free.
                                                                • none
                                                                • x-random-symbol-count
                                                                • No
                                                                • When used tih x-random, determines the number of symbols drawn. Increasing this number will generate a more dense distribution of symbols
                                                                • 16
                                                                • x-random-seed
                                                                • No
                                                                • Determines the \"seed\" used to generate the random distribution. Changing this value will result in a different symbol distribution.
                                                                • 0

                                                              .. todo:: Add examples using random

                                                              Property Required? Description Default value

                                                              external No Specifies an image to use to style the point. N/A

                                                              url Yes Location of the image. Can either be an actual URL or a file path (relative to where the style file is saved in the GeoServer data directory). Should be enclosed in single quotes. N/A

                                                              format Yes Format of the image. Must be a valid MIME type (such as image/png for PNG, image/jpeg for JPG, image/svg+xml for SVG) N/A

                                                              mark No Specifies a regular shape to use to style the point. N/A

                                                              shape No Shape of the mark. Options are square, circle, triangle, cross, x, and star. square

                                                              size No Size of the mark in pixels. If the aspect ratio of the mark is not 1:1 (square), will apply to the height of the graphic only, with the width scaled proportionally. 16

                                                              anchor No Specify the center of the symbol relative to the feature location. Value is an [x,y] tuple with decimal values from 0-1, with [0,0] meaning that the symbol is anchored to the top left, and [1,1] meaning anchored to bottom right. [0.5,0.5]

                                                              displacement No Specifies a distance to which to move the symbol relative to the feature. Value is an [x,y] tuple with values expressed in pixels, so [10,5] will displace the symbol 10 pixels to the right and 5 pixels down. [0,0]

                                                              opacity No Specifies the level of transparency. Value of 0 means entirely transparent, while 1 means entirely opaque. Only affects graphics referenced by the external parameter; the opacity of mark symbols is controlled by the fill-opacity and stroke-opacity of the mark. 1

                                                              rotation No Value (in degrees) or rotation of the mark. Larger values increase counter-clockwise rotation. A value of 180 will make the mark upside-down. 0

                                                              .. list-table:: :class: non-responsive :header-rows: 1 :stub-columns: 1 :widths: 20 10 50 20

                                                                • Property
                                                                • Required?
                                                                • Description
                                                                • Default value
                                                                • geometry
                                                                • No
                                                                • Specifies which attribute to use as the geometry (see :ref:geometry_transformations)
                                                                • First geometry attribute found (usually named geom or the_geom)
                                                                • uom
                                                                • No
                                                                • Unit of measure used for width calculations (see :ref:unit_of_measure)
                                                                • pixel

                                                              The following properties are equivalent to SLD \"vendor options\".

                                                              Additional \"vendor options\" property for :ref:label_obstacles:

                                                              .. list-table:: :class: non-responsive :header-rows: 1 :stub-columns: 1 :widths: 20 10 50 20

                                                                • Property
                                                                • Required?
                                                                • Description
                                                                • Default value
                                                                • x-labelObstacle
                                                                • No
                                                                • Marks the symbolizer as an obstacle such that labels drawn via a :ref:text symbolizer <ysld_reference_symbolizers_text> will not be drawn over top of these features. Options are true or false. Note that the bounding boxes of features are used when calculating obstacles, so unintended effects may occur when marking a line or polygon symbolizer as an obstacle.
                                                                • false

                                                              Additional \"vendor options\" properties for Color compositing and color blending:

                                                              Additional \"vendor options\" properties for :ref:sld-extensions_composite-blend:

                                                              .. list-table:: :class: non-responsive :header-rows: 1 :stub-columns: 1 :widths: 20 10 50 20

                                                                • Property
                                                                • Required?
                                                                • Description
                                                                • Default value
                                                                • x-composite
                                                                • No
                                                                • Allows for both alpha compositing and color blending options between symbolizers.
                                                                • N/A
                                                                • x-composite-base
                                                                • No
                                                                • Allows the rendering engine to use the symbolizer mapping to define a \"base\" buffer for subsequent compositing and blending using x-composite. See the section on :ref:Feature Styles <ysld_reference_featurestyles_composite> for more details.
                                                                • false

                                                              Additional \"vendor options\" properties for Rendering Selection:

                                                              Additional \"vendor options\" properties for :ref:rendering_selection:

                                                              .. list-table:: :class: non-responsive :header-rows: 1 :stub-columns: 1 :widths: 20 10 50 20

                                                                • Property
                                                                • Required?
                                                                • Description
                                                                • Default value
                                                                • x-inclusion
                                                                • No
                                                                • Define if rule should be included in style for legendOnly or mapOnly.
                                                                • normal
                                                              "},{"location":"styling/ysld/reference/symbolizers/point/#examples","title":"Examples","text":""},{"location":"styling/ysld/reference/symbolizers/point/#basic-point","title":"Basic point","text":"

                                                              A point symbolizer draws a point at the center of any geometry. It is defined by an external image or a symbol, either of which can be sized and rotated. A mark is a pre-defined symbol that can be drawn at the location of a point. Similar to polygons, marks have both a fill and a stroke. This example shows a point symbolizer that draws semi-transparent red diamonds with black outlines:

                                                              feature-styles:\n- name: name\n  rules:\n  - title: red point\n    symbolizers:\n    - point:\n        symbols:\n        - mark:\n            shape: square\n            fill-color: '#FF0000'\n            fill-opacity: 0.75\n            stroke-color: '#000000'\n            stroke-width: 1.5\n            stroke-opacity: 1\n        size: 20\n        rotation: 45\n

                                                              Basic point

                                                              "},{"location":"styling/ysld/reference/symbolizers/point/#point-as-image","title":"Point as image","text":"

                                                              Sometimes it may be useful to use an image to represent certain points. This can be accomplished using the external symbol property, which requires a url and a format. The url should be enclosed in single quotes. The format property is a MIME type image. This example shows a point symbolizer that draws an image centered on each point:

                                                              name: point\nfeature-styles:\n- name: name\n  rules:\n  - symbolizers:\n    - point:\n        symbols:\n        - external:\n            url: 'geoserver.png'\n            format: image/png\n        size: 16\n

                                                              Point as image

                                                              "},{"location":"styling/ysld/reference/symbolizers/point/#point-composition","title":"Point composition","text":"

                                                              Using more than one point symbolizer allows the composition of more complex symbology. This example shows two symbolizers along with the x-composite parameter in order to subtract a shape from a square mark, allowing the background to show through.

                                                              symbolizers:\n- point:\n    symbols:\n    - mark:\n        shape: square\n        fill-color: '#222222'\n    size: 40\n- point:\n    symbols:\n    - external:\n        url: 'stamp.png'\n        format: image/png\n    x-composite: xor\n    size: 40\n

                                                              Point composition

                                                              "},{"location":"styling/ysld/reference/symbolizers/point/#points-as-arrow-heads","title":"Points as arrow heads","text":"

                                                              Sometimes it is useful to generate a point using a CQL expression. The following example generates a point at the end of each line in the shape of an arrow, rotated such that it matches the orientation of the line.

                                                              name: arrow\nsymbolizers:\n- line:\n   stroke-color: '#808080'\n   stroke-width: 3\n- point:\n    geometry: ${endPoint(the_geom)}\n    symbols:\n    - mark:\n        shape: shape://oarrow\n        fill-color: '#808080'\n    size: 30\n    rotation: ${endAngle(the_geom)}\n

                                                              Point as arrow head

                                                              "},{"location":"styling/ysld/reference/symbolizers/polygon/","title":"Polygon symbolizer","text":"

                                                              The polygon symbolizer styles polygon (2-dimensional) features. It contains facilities for the stroke (outline) of a feature as well as the fill (inside) of a feature.

                                                              "},{"location":"styling/ysld/reference/symbolizers/polygon/#syntax","title":"Syntax","text":"

                                                              The full syntax of a polygon symbolizer is:

                                                              symbolizers:\n- polygon:\n    fill-color: <color>\n    fill-opacity: <expression>\n    fill-graphic: \n      <graphic_options>\n    stroke-color: <color>\n    stroke-width: <expression>\n    stroke-opacity: <expression>\n    stroke-linejoin: <expression>\n    stroke-linecap: <expression>\n    stroke-dasharray: <float list>\n    stroke-dashoffset: <expression>\n    stroke-graphic:\n      <graphic_options>\n    stroke-graphic-fill: \n      <graphic_options>\n    offset: <expression>\n    displacement: <expression>\n    geometry: <expression>\n    uom: <text>\n    x-labelObstacle: <boolean>\n    x-composite-base: <boolean>\n    x-composite: <text>\n    x-inclusion: <text>\n

                                                              where:

                                                              .. list-table:: :class: non-responsive :header-rows: 1 :stub-columns: 1 :widths: 20 10 50 20

                                                                • Property
                                                                • Required?
                                                                • Description
                                                                • Default value
                                                                • stroke-color
                                                                • No
                                                                • Color of line features.
                                                                • '#000000' (black)
                                                                • stroke-width
                                                                • No
                                                                • Width of line features, measured in pixels.
                                                                • 1
                                                                • stroke-opacity
                                                                • No
                                                                • Opacity of line features. Valid values are a decimal value between 0 (completely transparent) and 1 (completely opaque).
                                                                • 1
                                                                • stroke-linejoin
                                                                • No
                                                                • How line segments are joined together. Options are mitre (sharp corner), round (round corner), and bevel (diagonal corner).
                                                                • mitre
                                                                • stroke-linecap
                                                                • No
                                                                • How line features are rendered at their ends. Options are butt (sharp square edge), round (rounded edge), and square (slightly elongated square edge).
                                                                • butt
                                                                • stroke-dasharray
                                                                • No
                                                                • A numeric list signifying length of lines and gaps, creating a dashed effect. Units are pixels, so \"2 3\" would be a repeating pattern of 2 pixels of drawn line followed by 3 pixels of blank space. If only one number is supplied, this will mean equal amounts of line and gap.
                                                                • No dash
                                                                • stroke-dashoffset
                                                                • No
                                                                • Number of pixels into the dasharray to offset the drawing of the dash, used to shift the location of the lines and gaps in a dash.
                                                                • 0
                                                                • stroke-graphic
                                                                • No
                                                                • A design or pattern to be used along the stroke. Output will always be a linear repeating pattern, and as such is not tied to the value of stroke-width. Can either be a mark consisting of a common shape or a URL that points to a graphic. The <graphic_options> should consist of a mapping containing symbols: followed by an external: or mark:, with appropriate parameters as detailed in the :ref:ysld_reference_symbolizers_point section. Cannot be used with stroke-graphic-fill.
                                                                • N/A
                                                                • stroke-graphic-fill
                                                                • No
                                                                • A design or pattern to be used for the fill of the stroke. The area that is to be filled is tied directly to the value of stroke-width. Can either be a mark consisting of a common shape or a URL that points to a graphic. The <graphic_options> should consist of a mapping containing symbols: followed by an external: or mark:, with appropriate parameters as detailed in the :ref:ysld_reference_symbolizers_point section. Cannot be used with stroke-graphic.
                                                                • N/A

                                                              .. list-table:: :class: non-responsive :header-rows: 1 :stub-columns: 1 :widths: 20 10 50 20

                                                                • Property
                                                                • Required?
                                                                • Description
                                                                • Default value
                                                                • fill-color
                                                                • No
                                                                • Color of inside of features.
                                                                • '#808080' (gray)
                                                                • fill-opacity
                                                                • No
                                                                • Opacity of the fill. Valid values are a decimal value between 0 (completely transparent) and 1 (completely opaque).
                                                                • 1
                                                                • fill-graphic
                                                                • No
                                                                • A design or pattern to be used for the fill of the feature. Can either be a mark consisting of a common shape or a URL that points to a graphic. The <graphic_options> should consist of a mapping containing symbols: followed by an external: or mark:, with appropriate parameters as detailed in the :ref:ysld_reference_symbolizers_point section.
                                                                • None

                                                              The use of fill-graphic allows for the following extra options:

                                                              .. list-table:: :class: non-responsive :header-rows: 1 :stub-columns: 1 :widths: 20 10 50 20

                                                                • Property
                                                                • Required?
                                                                • Description
                                                                • Default value
                                                                • x-graphic-margin
                                                                • No
                                                                • Used to specify margins (in pixels) around the graphic used in the fill. Possible values are a list of four (top, right, bottom, left), a list of three (top, right and left, bottom), a list of two (top and bottom, right and left), or a single value.
                                                                • N/A
                                                                • x-random
                                                                • No
                                                                • Activates random distribution of symbols. Possible values are free or grid. free generates a completely random distribution, and grid will generate a regular grid of positions, and only randomize the position of the symbol around the cell centers, providing a more even distribution.
                                                                • N/A
                                                                • x-random-tile-size
                                                                • No
                                                                • When used with x-random, determines the size of the grid (in pixels) that will contain the randomly distributed symbols.
                                                                • 256
                                                                • x-random-rotation
                                                                • No
                                                                • When used with x-random, activates random symbol rotation. Possible values are none or free.
                                                                • none
                                                                • x-random-symbol-count
                                                                • No
                                                                • When used tih x-random, determines the number of symbols drawn. Increasing this number will generate a more dense distribution of symbols
                                                                • 16
                                                                • x-random-seed
                                                                • No
                                                                • Determines the \"seed\" used to generate the random distribution. Changing this value will result in a different symbol distribution.
                                                                • 0

                                                              .. todo:: Add examples using random

                                                              Property Required? Description Default value

                                                              offset No Value in pixels for moving the drawn line relative to the location of the feature. 0

                                                              displacement No Specifies a distance to which to move the symbol relative to the feature. Value is an [x,y] tuple with values expressed in pixels, so [10,5] will displace the symbol 10 pixels to the right, and 5 pixels down. [0,0]

                                                              .. list-table:: :class: non-responsive :header-rows: 1 :stub-columns: 1 :widths: 20 10 50 20

                                                                • Property
                                                                • Required?
                                                                • Description
                                                                • Default value
                                                                • geometry
                                                                • No
                                                                • Specifies which attribute to use as the geometry (see :ref:geometry_transformations)
                                                                • First geometry attribute found (usually named geom or the_geom)
                                                                • uom
                                                                • No
                                                                • Unit of measure used for width calculations (see :ref:unit_of_measure)
                                                                • pixel

                                                              The following properties are equivalent to SLD \"vendor options\".

                                                              Additional \"vendor options\" property for :ref:label_obstacles:

                                                              .. list-table:: :class: non-responsive :header-rows: 1 :stub-columns: 1 :widths: 20 10 50 20

                                                                • Property
                                                                • Required?
                                                                • Description
                                                                • Default value
                                                                • x-labelObstacle
                                                                • No
                                                                • Marks the symbolizer as an obstacle such that labels drawn via a :ref:text symbolizer <ysld_reference_symbolizers_text> will not be drawn over top of these features. Options are true or false. Note that the bounding boxes of features are used when calculating obstacles, so unintended effects may occur when marking a line or polygon symbolizer as an obstacle.
                                                                • false

                                                              Additional \"vendor options\" properties for Color compositing and color blending:

                                                              Additional \"vendor options\" properties for :ref:sld-extensions_composite-blend:

                                                              .. list-table:: :class: non-responsive :header-rows: 1 :stub-columns: 1 :widths: 20 10 50 20

                                                                • Property
                                                                • Required?
                                                                • Description
                                                                • Default value
                                                                • x-composite
                                                                • No
                                                                • Allows for both alpha compositing and color blending options between symbolizers.
                                                                • N/A
                                                                • x-composite-base
                                                                • No
                                                                • Allows the rendering engine to use the symbolizer mapping to define a \"base\" buffer for subsequent compositing and blending using x-composite. See the section on :ref:Feature Styles <ysld_reference_featurestyles_composite> for more details.
                                                                • false

                                                              Additional \"vendor options\" properties for Rendering Selection:

                                                              Additional \"vendor options\" properties for :ref:rendering_selection:

                                                              .. list-table:: :class: non-responsive :header-rows: 1 :stub-columns: 1 :widths: 20 10 50 20

                                                                • Property
                                                                • Required?
                                                                • Description
                                                                • Default value
                                                                • x-inclusion
                                                                • No
                                                                • Define if rule should be included in style for legendOnly or mapOnly.
                                                                • normal
                                                              "},{"location":"styling/ysld/reference/symbolizers/polygon/#examples","title":"Examples","text":""},{"location":"styling/ysld/reference/symbolizers/polygon/#basic-polygon","title":"Basic polygon","text":"

                                                              Polygon symbolizers have both a stroke and a fill, similar to marks for point symbolizers. The following example draws a polygon symbolizer with a red fill and black stroke with beveled line joins for the stroke:

                                                              feature-styles:\n- name: name\n  rules:\n  - title: fill-graphic\n    symbolizers:  \n    - polygon:\n        fill-color: '#FF0000'\n        fill-opacity: 0.9\n        stroke-color: '#000000'\n        stroke-width: 8\n        stroke-opacity: 1\n        stroke-linejoin: bevel\n

                                                              "},{"location":"styling/ysld/reference/symbolizers/polygon/#fill-with-graphic","title":"Fill with graphic","text":"

                                                              The fill-graphic property is used to fill a geometry with a repeating graphic. This can be a mark or an external image. The x-graphic-margin option can be used to specify top, right, bottom, and left margins around the graphic used in the fill. This example uses two sets of repeating squares with different offset values to draw a checkerboard pattern:

                                                              name: checkers\nfeature-styles:\n- name: name\n  rules:\n  - title: fill-graphic\n    symbolizers:  \n    - polygon:\n        stroke-width: 1\n        fill-graphic:\n          symbols:\n          - mark:\n              shape: square\n              fill-color: '#000000'\n          size: 8\n        x-graphic-margin: 16 16 0 0\n    - polygon:\n        stroke-width: 1\n        fill-graphic:\n          symbols:\n          - mark:\n              shape: square\n              fill-color: '#000000'\n          size: 8\n        x-graphic-margin: 0 0 16 16\n

                                                              Checkered fill

                                                              "},{"location":"styling/ysld/reference/symbolizers/polygon/#randomized-graphic-fill","title":"Randomized graphic fill","text":"

                                                              Normally, the graphic used for the fill-graphic property is tiled. Alternatively, one can scatter this image randomly across the fill area using the x-random option and associated other options. This could be used to create a speckled pattern, as in the following example:

                                                              name: speckles\nfeature-styles:\n- name: name\n  rules:\n  - title: fill-graphic\n    symbolizers:  \n    - polygon:\n        stroke-width: 1\n        fill-graphic:\n          symbols:\n            - mark:\n                shape: circle\n                fill-color: '#000000'\n          size: 3\n          x-random: grid\n          x-random-seed: 2\n          x-random-tile-size: 1000\n          x-random-rotation: free\n          x-random-symbol-count: 1000\n

                                                              Randomized graphic fill

                                                              "},{"location":"styling/ysld/reference/symbolizers/raster/","title":"Raster symbolizer","text":"

                                                              The raster symbolizer styles raster (coverage) layers. A raster is an array of information with each cell in the array containing one or more values, stored as \"bands\".

                                                              The full syntax of a raster symbolizer is:

                                                              symbolizers:\n- raster:\n    opacity: <expression>\n    channels:\n      gray: \n        <channel_options>\n      red:\n        <channel_options>\n      green:\n        <channel_options>\n      blue:\n        <channel_options>\n    color-map:\n      type: <ramp|interval|values>\n      entries:\n      - [color, entry_opacity, band_value, text_label]\n    contrast-enhancement: \n      mode: <normalize|histogram>\n      gamma: <expression>\n    x-inclusion: <text>\n

                                                              where:

                                                              Property Required? Description Default value

                                                              opacity No Opacity of the entire display. Valid values are a decimal between 0 (completely transparent) and 1 (completely opaque). 1

                                                              channels No Selects the band(s) to display and the display method. N/A

                                                              gray No Display a single band as a grayscale image. Cannot be used with red, green, and blue. The <channel_options> can be the band name or a mapping containing name: and contrast-enhancement: (optional). 1

                                                              red No Display three bands as an RGB image. Must be used with green, and blue. Cannot be used with gray. The <channel_options> can be the band name or a mapping containing name: and contrast-enhancement: (optional). 1

                                                              green No Display three bands as an RGB image. Must be used with red, and blue. Cannot be used with gray. The <channel_options> can be the band name or a mapping containing name: and contrast-enhancement: (optional). 2

                                                              blue No Display three bands as an RGB image. Must be used with red, and green. Cannot be used with gray. The <channel_options> can be the band name or a mapping containing name: and contrast-enhancement: (optional). See examples below. 3

                                                              color-map No Creates a mapping of colors to grid values. Can only be used with a single band. N/A

                                                              type No Type of color mapping. Options are ramp, an interpolated list of values; interval, a non-interpolated list of values; and values, where values need to match exactly to be drawn. ramp

                                                              entries No Values for the color mapping. Syntax is a list of tuples. N/A

                                                              color Yes Color for the particular color map entry. Value is a standard color value. N/A

                                                              entry_opacity Yes Opacity of the particular color map entry. Valid values are a decimal between 0 (completely transparent) and 1 (completely opaque). N/A

                                                              band_value Yes Grid value to use for the particular color map entry. Values are data-dependent. Behavior at or around this value is determined by the color ramp type. N/A

                                                              text_label No Label for the particular color map entry Blank

                                                              contrast-enhancement No Modifies the contrast of the display N/A

                                                              mode No Type of contrast enhancement. Options are normalize (stretches contrast so that the smallest and largest values are set to black and white, respectively) or histogram (produces equal number of content in the image at each brightness level). normalize

                                                              gamma No Multiplier value for contrast adjustment. A value greater than 1 will increase darkness, while a value less than 1 will decrease darkness. 1

                                                              Additional \"vendor options\" properties for Color compositing and color blending:

                                                              Additional \"vendor options\" properties for :ref:sld-extensions_composite-blend:

                                                              .. list-table:: :class: non-responsive :header-rows: 1 :stub-columns: 1 :widths: 20 10 50 20

                                                                • Property
                                                                • Required?
                                                                • Description
                                                                • Default value
                                                                • x-composite
                                                                • No
                                                                • Allows for both alpha compositing and color blending options between symbolizers.
                                                                • N/A
                                                                • x-composite-base
                                                                • No
                                                                • Allows the rendering engine to use the symbolizer mapping to define a \"base\" buffer for subsequent compositing and blending using x-composite. See the section on :ref:Feature Styles <ysld_reference_featurestyles_composite> for more details.
                                                                • false

                                                              Additional \"vendor options\" properties for Rendering Selection:

                                                              Additional \"vendor options\" properties for :ref:rendering_selection:

                                                              .. list-table:: :class: non-responsive :header-rows: 1 :stub-columns: 1 :widths: 20 10 50 20

                                                                • Property
                                                                • Required?
                                                                • Description
                                                                • Default value
                                                                • x-inclusion
                                                                • No
                                                                • Define if rule should be included in style for legendOnly or mapOnly.
                                                                • normal
                                                              "},{"location":"styling/ysld/reference/symbolizers/raster/#examples","title":"Examples","text":"

                                                              Todo

                                                              All examples need figures

                                                              "},{"location":"styling/ysld/reference/symbolizers/raster/#enhanced-contrast","title":"Enhanced contrast","text":"

                                                              This example takes a given raster and lightens the output by a factor of 2:

                                                              symbolizers:\n- raster:\n    contrast-enhancement: \n      gamma: 0.5\n

                                                              Lightened image

                                                              "},{"location":"styling/ysld/reference/symbolizers/raster/#normalized-output","title":"Normalized output","text":"

                                                              This example takes a given raster and adjusts the contrast so that the smallest values are darkest and the highest values are lightest:

                                                              symbolizers:\n- raster:\n    contrast-enhancement: \n      mode: normalize\n

                                                              Normalized image

                                                              "},{"location":"styling/ysld/reference/symbolizers/raster/#band-selection","title":"Band selection","text":"

                                                              This example takes a raster with multiple bands and outputs band 2 as a grayscale image (This could be used to select a single band in a multi-band image to use with color-map):

                                                              name: raster\nfeature-styles:\n- name: name\n  rules:\n  - symbolizers:\n    - raster:\n        opacity: 1.0\n        channels:\n          gray: 2\n

                                                              Grayscale band selection

                                                              "},{"location":"styling/ysld/reference/symbolizers/raster/#band-selection-with-contrast","title":"Band selection with contrast","text":"

                                                              This example takes an RGB raster, doubles the intensity of the red, and normalizes the green band:

                                                              name: raster\nfeature-styles:\n- name: name\n  rules:\n  - symbolizers:\n    - raster:\n        channels:\n          red:\n            name: 1\n            contrast-enhancement:\n              gamma: .5\n          green:\n            name: 2\n            contrast-enhancement:\n              mode: normalize\n          blue:\n            name: 3\n

                                                              Band selection with contrast enhancement

                                                              "},{"location":"styling/ysld/reference/symbolizers/raster/#color-ramp","title":"Color ramp","text":"

                                                              This example shows a color ramp from red to green to blue, with raster band values from 0-200:

                                                              symbolizers:\n- raster:\n    color-map:\n      type: ramp\n      entries:\n      - ['#FF0000', 1, 0, red]\n      - ['#00FF00', 1, 100, green]\n      - ['#0000FF', 1, 200, blue]\n

                                                              In this example, the grid values will have the following colors applied:

                                                              • Less than or equal to 0 will have an output color of solid red
                                                              • Between 0 and 100 will have an output color interpolated between red and green
                                                              • Between 100 and 200 will have an output color interpolated between green and blue
                                                              • Greater than 200 will have an output color of solid blue

                                                              Color map with ramp

                                                              "},{"location":"styling/ysld/reference/symbolizers/raster/#color-intervals","title":"Color intervals","text":"

                                                              The same example as above, but with the color-map type set to intervals:

                                                              symbolizers:\n- raster:\n    color-map:\n      type: intervals\n      entries:\n      - ['#FF0000', 1, 0, red]\n      - ['#00FF00', 1, 100, green]\n      - ['#0000FF', 1, 200, blue]\n

                                                              In this example, the grid values will have the following colors applied:

                                                              • Less than or equal to 0 will have an output color of solid red
                                                              • Between 0 and 100 will have an output color of solid green
                                                              • Between 100 and 200 will have an output color of solid blue
                                                              • Greater than 200 will not be colored at all (transparent)

                                                              Color map with intervals

                                                              "},{"location":"styling/ysld/reference/symbolizers/raster/#color-values","title":"Color values","text":"

                                                              The same example as above, but with the color-map type set to values:

                                                              symbolizers:\n- raster:\n    color-map:\n      type: values\n      entries:\n      - ['#FF0000', 1, 0, red]\n      - ['#00FF00', 1, 100, green]\n      - ['#0000FF', 1, 200, blue]\n

                                                              In this example, the grid values will have the following colors applied:

                                                              • Equal to 0 will have an output color of solid red
                                                              • Equal to 100 will have an output color of solid green
                                                              • Equal to 200 will have an output color of solid blue

                                                              Any other values (even those in between the above values) will not be colored at all.

                                                              Color map with values

                                                              "},{"location":"styling/ysld/reference/symbolizers/text/","title":"Text symbolizer","text":"

                                                              The text symbolizer styles labels of vector features. Labels can consist of text strings and/or graphics.

                                                              "},{"location":"styling/ysld/reference/symbolizers/text/#syntax","title":"Syntax","text":"

                                                              The full syntax of a text symbolizer is:

                                                              symbolizers:\n- text:\n    fill-color: <color>\n    fill-opacity: <expression>\n    fill-graphic: \n      <graphic_options>\n    stroke-graphic: \n      <graphic_options>\n    stroke-graphic-fill: \n      <graphic_options>\n    label: <expression>\n    font-family: <expression>\n    font-size: <expression>\n    font-style: <expression>\n    font-weight: <expression>\n    placement: <point|line>\n    offset: <expression>\n    anchor: <tuple>\n    displacement: <tuple>\n    rotation: <expression>\n    priority: <expression>\n    halo:\n      radius: <expression>\n      fill-color: <color>\n      fill-opacity: <expression>\n      fill-graphic:\n        <graphic_options>\n    graphic:\n      symbols:\n        <graphic_options>\n      size: <expression>\n      opacity: <expression>\n      rotation: <expression>\n    geometry: <expression>\n    uom: <text>\n    x-composite-base: <boolean>\n    x-composite: <text>\n    x-allowOverruns: <boolean>\n    x-autoWrap: <expression>\n    x-conflictResolution: <boolean>\n    x-followLine: <boolean>\n    x-forceLeftToRight: <boolean>\n    x-goodnessOfFit: <expression>\n    x-graphic-margin: <expression>\n    x-graphic-resize: <none|proportional|stretch>\n    x-group: <boolean>\n    x-labelAllGroup: <boolean>\n    x-repeat: <expression>\n    x-maxAngleDelta: <expression>\n    x-maxDisplacement: <expression>\n    x-minGroupDistance: <expression>\n    x-partials: <boolean>\n    x-polygonAlign: <boolean>\n    x-spaceAround: <expression>\n    x-underlineText: <boolean>\n    x-strikethroughText: <boolean>\n    x-charSpacing: <expression>\n    x-wordSpacing: <expression>\n    x-inclusion: <text>\n

                                                              where:

                                                              Property Required? Description Default value

                                                              fill-color No Color of inside of the label. '#808080' (gray)

                                                              fill-opacity No Opacity of fill of the label text. Valid values are a decimal value between 0 (completely transparent) and 1 (completely opaque). 1

                                                              fill-graphic No A design to be used for the fill of the text label. Can either be a mark consisting of a common shape or a URL that points to a graphic. The <graphic_options> should consist of a mapping containing symbols: followed by an external: or mark:, with appropriate parameters as detailed in the Point symbolizer section. None

                                                              stroke-graphic No A design or pattern to be used along the stroke around the label text. the output will always be a linear repeating pattern, and as such is not tied to the value of stroke-width. Can either be a mark consisting of a common shape or a URL that points to a graphic. The <graphic_options> should consist of a mapping containing symbols: followed by an external: or mark:, with appropriate parameters. Cannot be used with stroke-graphic-fill. N/A

                                                              stroke-graphic-fill No A design or pattern to be used for the fill of the stroke around the label text. This area that is to be filled is tied directly to the value of stroke-width. Can either be a mark consisting of a common shape or a URL that points to a graphic. The <graphic_options> should consist of a mapping containing symbols: followed by an external: or mark:, with appropriate parameters as detailed in the Point symbolizer section. Cannot be used with stroke-graphic. N/A

                                                              Property Required? Description Default value

                                                              label Yes Text to display. Often taken from an attribute but any valid expression that constructs a string will do. N/A

                                                              font-family No Type of font to be used for the label. Options are system dependent; the full list of fonts available can be found via the GeoServer Server Status page. serif

                                                              font-size No Size of the font. 10

                                                              font-style No Style of the font. Options are normal, italic, and oblique. normal

                                                              font-weight No Weight of the font. Options are normal and bold. normal

                                                              placement No Determines whether the label is to be drawn derived from a point or a line. point

                                                              offset No Value (in pixels) for moving the drawn label relative to the location of the feature. A positive value will shift the label in the direction of its top, while a negative value will shift the label in the direction of its bottom. Only valid for when type is set to line. 0

                                                              anchor No Specify the center of the symbol relative to the feature location (centroid for lines and polygons). Value is an [x,y] tuple with decimal values from 0-1, with [0,0] meaning that the symbol is anchored to the bottom left of the label, and [1,1] meaning anchored to the top right of the label. [0,0]

                                                              displacement No Specifies a distance (in pixels) to which to move the label relative to the feature. Value is an [x,y] tuple with values expressed in pixels, so [10,5] will displace the label 10 pixels to the right and 5 pixels up. Only valid for when type is set to point. [0,0]

                                                              rotation No Value (in degrees) or rotation of the label. Larger values increase counter-clockwise rotation. A value of 180 will make the label upside-down. Only valid for when type is set to point. 0

                                                              priority No The priority used when choosing which labels to display during conflict resolution. Higher priority values take precedence over lower priority values. 1000

                                                              halo No Creates a shaded area around the label for easier legibility No halo

                                                              radius No Size (in pixels) of the halo 1

                                                              fill-color No Color of the halo '#808080'

                                                              fill-opacity No Specifies the level of transparency for the halo. Value of 0 means entirely transparent, while 1 means entirely opaque. 1

                                                              The following properties allow for a graphic to be displayed in addition to just a label. This is used when drawing \"shields\" (text over top of a graphic) such as in road signs.

                                                              Property Required? Description Default value

                                                              graphic No Specifies whether a graphic is to be drawn for the label. N/A (no graphic)

                                                              symbols No The details of the graphic. Consists of an external: or mark: section, with appropriate parameters as detailed in the Point symbolizer section. N/A

                                                              size No Size of the graphic in pixels. If the aspect ratio is not 1:1 (square), will apply to the height of the graphic only, with the width scaled proportionally. 16

                                                              opacity No Specifies the level of transparency for the graphic. Value of 0 means entirely transparent, while 1 means entirely opaque. 1

                                                              rotation No Value (in degrees) or rotation of the graphic. Larger values increase counter-clockwise rotation. A value of 180 will make the graphic upside-down. 0

                                                              .. list-table:: :class: non-responsive :header-rows: 1 :stub-columns: 1 :widths: 20 10 50 20

                                                                • Property
                                                                • Required?
                                                                • Description
                                                                • Default value
                                                                • geometry
                                                                • No
                                                                • Specifies which attribute to use as the geometry (see :ref:geometry_transformations)
                                                                • First geometry attribute found (usually named geom or the_geom)
                                                                • uom
                                                                • No
                                                                • Unit of measure used for width calculations (see :ref:unit_of_measure)
                                                                • pixel

                                                              The following properties are equivalent to SLD \"vendor options\".

                                                              Property Required? Description Default value

                                                              x-allowOverruns No Allows labels on lines to move slightly beyond the beginning or end of the line. true

                                                              x-autoWrap No The number of pixels beyond which a label will be wrapped over multiple lines. Cannot use with x-followLine. 0

                                                              x-conflictResolution No Enables conflict resolution, meaning no two labels will be allowed to overlap. Without conflict resolution, symbolizers can overlap with other labels. true

                                                              x-followLine No On linear geometries, the label will follow the shape of the current line, as opposed to being drawn at a tangent. Will override false

                                                              x-forceLeftToRight No Forces labels to a readable orientation, otherwise will follow the line orientation, possibly making the label look upside-down. This setting is useful when using symbol fonts to add direction markers along a line. false

                                                              x-goodnessOfFit No Percentage (expressed as a decimal between 0-1) of the label that must fit inside the geometry to permit the label to be drawn. Works only on polygon features. 0.5

                                                              x-graphic-margin No Number of pixels between the stretched graphic and the text. Only applies when x-graphic-resize is set to stretch or proportional. 0

                                                              x-graphic-resize No Allows for stretching the graphic underneath a label to fit the label size. Options are none, stretch or proportional. Used in conjunction with x-graphic-margin.. none

                                                              x-group No Geometries with identical labels will be considered a single entity to be labeled. Used to control repeated labels. false

                                                              x-labelAllGroup No Used in conjunction with x-group. When true all items in a group are labeled. When false, only the largest geometry in the group is labeled. Valid for lines only. false

                                                              x-repeat No Desired distance (in pixels) between labels drawn on a group. If zero, only one label will be drawn. Used in conjunction with x-group. Valid for lines only. 0

                                                              x-maxAngleDelta No Maximum allowed angle (in degrees) between two characters in a curved label. Used in conjunction with x-followLine. Values higher than 30 may cause loss of legibility of the label. 22.5

                                                              x-maxDisplacement No Distance (in pixels) a label can be displaced from its natural position in an attempt to eliminate conflict with other labels. 0

                                                              x-minGroupDistance No Minimum distance (in pixels) between two labels in the same label group. Used in conjunction with displacement or repeat to avoid having two labels too close to each other No minimum distance

                                                              x-partials No Will display partial labels (truncated on the border of the display area). false

                                                              x-polygonAlign No Overrides manual rotation to align label rotation automatically. Valid for polygons only. false

                                                              x-spaceAround No Minimum distance (in pixels) between two labels. A negative value specifies the maximum overlap between two labels. 0

                                                              x-underlineText No Instruct the renderer to underline labels. false

                                                              x-strikethroughText No Instruct the renderer to strikethrough labels. false

                                                              x-charSpacing No The option controls the amount of space between characters, a positive value increases it, a negative value shrinks it (and will eventually make characters overlap). The value is specified in pixels. 0

                                                              x-wordSpacing No The option controls the amount of space between words, for this option only positive values (or zero) are accepted. The value is specified in pixels. 0

                                                              Additional \"vendor options\" properties for :ref:sld-extensions_composite-blend:

                                                              .. list-table:: :class: non-responsive :header-rows: 1 :stub-columns: 1 :widths: 20 10 50 20

                                                                • Property
                                                                • Required?
                                                                • Description
                                                                • Default value
                                                                • x-composite
                                                                • No
                                                                • Allows for both alpha compositing and color blending options between symbolizers.
                                                                • N/A
                                                                • x-composite-base
                                                                • No
                                                                • Allows the rendering engine to use the symbolizer mapping to define a \"base\" buffer for subsequent compositing and blending using x-composite. See the section on :ref:Feature Styles <ysld_reference_featurestyles_composite> for more details.
                                                                • false
                                                              "},{"location":"styling/ysld/reference/symbolizers/text/#examples","title":"Examples","text":""},{"location":"styling/ysld/reference/symbolizers/text/#basic-label","title":"Basic label","text":"

                                                              Text symbolizers are used to draw labels on objects. The label text is usually linked to some attribute of the layer. Font options are available in the font-family, font-size, font-style, and font-weight properties. The following example draws a label using the name attribute of the layer, and with a SansSerif font of size 12, gray color, bold and italic:

                                                              feature-styles:\n- name: name\n  rules:\n  - title: fill-graphic\n    symbolizers:\n    - text:\n        label: ${name}\n        fill-color: '#555555'\n        font-family: SansSerif\n        font-size: 12\n        font-style: italic\n        font-weight: bold\n

                                                              Basic label

                                                              "},{"location":"styling/ysld/reference/symbolizers/text/#label-with-wrap","title":"Label with wrap","text":"

                                                              Wrapping long labels can improve how well they fit on maps. This can be accomplished using the x-autoWrap property. This example wraps lines longer than 70 pixels:

                                                              feature-styles:\n- name: name\n  rules:\n  - symbolizers:\n    - polygon:\n        stroke-width: 1\n        fill-color: '#00DD77'\n    - text:\n        label: ${name}\n        font-size: 12\n        x-autoWrap: 70\n        x-maxDisplacement: 100\n        anchor: [0.5,-1]\n

                                                              Label with wrap

                                                              "},{"location":"styling/ysld/reference/symbolizers/text/#label-with-halo","title":"Label with halo","text":"

                                                              Surrounding labels with a halo will allow them to be visible even on complex maps with various background features. This can be accomplished using the halo family of properties. This example surrounds the label in a partially transparent white halo of radius 2:

                                                              feature-styles:\n- name: name\n  rules:\n  - symbolizers:  \n    - polygon:\n        stroke-width: 1\n        fill-color: '#00DD77'\n    - text:\n        label: ${name}\n        font-size: 12\n        x-autoWrap: 70\n        x-maxDisplacement: 100\n        halo:\n           radius: 2\n           fill-color: '#FFFFFF'\n           fill-opacity: 0.8\n        anchor: [0.5,-1]\n

                                                              Label with halo

                                                              "},{"location":"styling/ysld/reference/symbolizers/text/#grouped-labels","title":"Grouped labels","text":"

                                                              Grouping and other properties can be used to better control where labels are placed. The x-group option combines all labels with identical text into a single label. This can be useful to show only a single label for a street rather than having a label on every block of the street. The x-goodnesOfFit option determines whether or not to draw labels based on how well they fit into the available space. The x-maxDisplacement option determines the maximum distance a label can be moved to avoid overlaps.

                                                              The following example uses x-group to ensure only one label is drawn for each feature, and sets x-goodnesOfFit to zero so that labels will be drawn even if they have a poor fit:

                                                              feature-styles:\n- name: name\n  rules:\n  - title: fill-graphic\n    symbolizers:\n    - text:\n        label: ${name}\n        fill-color: '#555555'\n        font-family: SansSerif\n        font-size: 12\n        font-style: italic\n        font-weight: bold\n        x-group: true\n        x-goodnessOfFit: 0.0\n        x-maxDisplacement: 400\n

                                                              Grouped labels

                                                              "},{"location":"styling/ysld/reference/symbolizers/text/#labels-following-lines","title":"Labels following lines","text":"

                                                              In order to have a label follow a line (and not be drawn tangent to a line), the x-followLine option can be set. Other properties can be used in conjunction with this to achieve the best visual result. The following example has street names following the line of the street, with a maximum angle of 90 degrees, repeating every 150 pixels:

                                                              feature-styles:\n- rules:\n  - symbolizers:\n    - line:\n        stroke-color: '#EDEDFF'\n        stroke-width: 10\n    - text:\n        label: name\n        x-followLine: true\n        x-maxAngleDelta: 90\n        x-maxDisplacement: 400\n        x-repeat: 150\n

                                                              Labels following lines

                                                              "},{"location":"styling/ysld/reference/symbolizers/text/#labels-avoiding-obstacles","title":"Labels avoiding obstacles","text":"

                                                              The x-labelObstacle option is used to mark a different symbolizer as an obstacle that labels should avoid. This example draws labels and points on a line geometry, and also uses a point symbolizer to draw the vertices of the lines as points. It is those points which are set to be treated as obstacles to be avoided:

                                                              feature-styles:\n- rules:\n  - symbolizers:\n      - line:\n          stroke-color: '#00BBDD'\n          stroke-width: 10\n- rules:\n  - symbolizers:\n      - point:\n          geometry: ${vertices(the_geom)}\n          x-labelObstacle: true\n          symbols:\n          - mark:\n              shape: circle\n              stroke-color: '#000000'\n              fill-color: '#007777'\n      - text:\n          label: ${streetname}\n          x-maxDisplacement: 400\n          x-followLine: true\n

                                                              Labels avoiding obstacles

                                                              "},{"location":"styling/ysld/reference/symbolizers/text/#road-shields","title":"Road Shields","text":"

                                                              The graphic option is used to display a symbol behind a label. A common use for this is to display \"highway shields\" behind road numbers. This example uses a circle shape to draw state shields, and an external image to draw interstate shields, then draws road names on top. The x-graphic-resize and x-graphic-margin options are used to resize the graphics to fit the label text:

                                                              feature-styles:\n- name: state\n  rules:\n  - filter: ${level ilike 'State'}\n    symbolizers:\n    - line:\n        stroke-color: '#AAEE00'\n        stroke-width: 4\n        stroke-linecap: round\n    - text:\n        label: ${name}\n        anchor: [0.5, 0.5]\n        fill-color: black\n        font-family: SansSerif\n        font-weight: bold\n        font-size: 8\n        x-graphic-resize: stretch\n        x-graphic-margin: 6\n        graphic:\n          symbols:\n          - mark: \n              shape: circle\n              fill-color: white\n              stroke-color: black \n- name: interstate\n  rules:\n  - filter: ${level ilike 'Interstate'}\n    symbolizers:\n    - line:\n        stroke-color: '#99CC00'\n        stroke-width: 6\n        stroke-linecap: round\n    - text:\n        label: ${name}\n        anchor: [0.5, 0.5]\n        fill-color: white\n        font-family: SansSerif\n        font-weight: bold\n        font-size: 8\n        x-graphic-resize: stretch\n        x-graphic-margin: 6\n        graphic:\n          symbols:\n          - external:\n              url: interstate.png\n              format: image/png\n

                                                              Road Shields

                                                              "},{"location":"tutorials/","title":"Tutorials","text":"

                                                              Quickstart:

                                                              • Using the web administration interface
                                                              • Publishing a shapefile
                                                              • Publishing a GeoPackage
                                                              • Publishing a PostGIS table

                                                              Template:

                                                              • Freemarker Templates
                                                              • GeoRSS
                                                              • GetFeatureInfo Templates

                                                              WMS Tutorials:

                                                              • Paletted Images
                                                              • Serving Static Files
                                                              • WMS Reflector
                                                              • CQL and ECQL

                                                              Styling:

                                                              • CSS Quickstart
                                                              • MBStyle Styling Workbook
                                                              • YSLD Styling Workbook

                                                              Imagery tutorials:

                                                              • Using the ImageMosaic plugin for raster time-series data
                                                              • Using the ImageMosaic plugin for raster with time and elevation data
                                                              • Using the ImageMosaic plugin with footprint management
                                                              • Building and using an image pyramid

                                                              Imagery tutorials:

                                                              • Using the GeoTools feature-pregeneralized module

                                                              Catalogue tutorials:

                                                              • INSPIRE metadata configuration using metadata and CSW

                                                              Application server tutorials:

                                                              • Setting up a JNDI connection pool with Tomcat
                                                              • geoserver on JBoss
                                                              • Running GeoServer in Cloud Foundry
                                                              "},{"location":"tutorials/freemarker/","title":"Freemarker Templates","text":""},{"location":"tutorials/freemarker/#introduction","title":"Introduction","text":"

                                                              This tutorial will introduce you to a more in depth view of what FreeMarker templates are and how you can use the data provided to templates by GeoServer.

                                                              Freemarker is a simple yet powerful template engine that GeoServer uses to allow user customization of outputs. In particular, at the time of writing it's used to allow customization of GetFeatureInfo, GeoRSS and KML outputs.

                                                              Freemarker allows for simple variable expansions, as in ${myVarName}, expansion of nested properties, such as in ${feature.myAtt.value}, up to little programs using loops, ifs and variables. Most of the relevant information about how to approach template writing is included in the Freemarker's Designer guide and won't be repeated here: the guide, along with the KML Placemark Templates and GetFeatureInfo Templates tutorials should be good enough to give you a good grip on how a template is built.

                                                              "},{"location":"tutorials/freemarker/#template-lookup","title":"Template Lookup","text":"

                                                              GeoServer looks up templates in three different places, allowing for various levels of customization. For example given the content.ftl template used to generate WMS GetFeatureInfo content:

                                                              • Look into GEOSERVER_DATA_DIR/workspaces/<workspace>/<datastore>/<featuretype>/content.ftl to see if there is a feature type specific template
                                                              • Look into GEOSERVER_DATA_DIR/workspaces/<workspace>/<datastore>/content.ftl to see if there is a store specific template
                                                              • Look into GEOSERVER_DATA_DIR/workspaces/<workspace>/content.ftl to see if there is a workspace specific template
                                                              • Look into GEOSERVER_DATA_DIR/workspaces/content.ftl looking for a global override
                                                              • Look into GEOSERVER_DATA_DIR/templates/content.ftl looking for a global override
                                                              • Look into the GeoServer classpath and load the default template

                                                              Each templated output format tutorial should provide you with the template names, and state whether the templates can be type specific, or not. If you can't find the source files for the default template, look in the service jar of the geoserver distribution (for example, wms-x.y.z.jar). You just have to unzip it, and you'll find the xxx.ftl files GeoServer is using as the default templates.

                                                              "},{"location":"tutorials/freemarker/#common-data-models","title":"Common Data Models","text":"

                                                              Freemarker calls \"data model\" the set of data provided to the template. Each output format used by GeoServer will inject a different data model according to the information it's managing. There are three very common elements that appear in almost every template: Feature, FeatureType and FeatureCollection. Here we provide a data model of each.

                                                              The data model is a sort of tree, where each element has a name and a type. Besides basic types, we'll use:

                                                              • list: a flat list of items that you can scan thru using the FreeMarker <#list> directive;
                                                              • map: a key/value map, that you usually access using the dot notation, as in ${myMap.myKey}, and can be nested;
                                                              • listMap: a special construct that is, at the same time, a Map, and a list of the values.

                                                              Here are the data models (as you can see there are redundancies, in particular in attributes, we chose this approach to make template building easier):

                                                              FeatureType (map)

                                                              • name (string): the type name
                                                              • attributes (listMap): the type attributes
                                                                • name (string): attribute name
                                                                • namespace (string): attribute namespace URI
                                                                • prefix (string): attribute namespace prefix
                                                                • type (string): attribute type, the fully qualified Java class name
                                                                • isGeometry (boolean): true if the attribute is geometric, false otherwise

                                                              Feature (map)

                                                              • fid (string): the feature ID (WFS feature id)
                                                              • typeName (string): the type name
                                                              • attributes (listMap): the list of attributes (both data and metadata)
                                                                • name (string): attribute name
                                                                • namespace (string): attribute namespace URI
                                                                • prefix (string): attribute namespace prefix
                                                                • isGeometry (boolean): true if the attribute is geometric, false otherwise
                                                                • value: a string representation of the attribute value
                                                                • isComplex (boolean): true if the attribute is a feature (see app-schema.complex-features), false otherwise
                                                                • type (string or FeatureType): attribute type: if isComplex is false, the fully qualified Java class name; if isComplex is true, a FeatureType
                                                                • rawValue: the actual attribute value (is isComplex is true rawValue is a Feature)
                                                              • type (map)
                                                                • name (string): the type name (same as typeName)
                                                                • namespace (string): attribute namespace URI
                                                                • prefix (string): attribute namespace prefix
                                                                • title (string): The title configured in the admin console
                                                                • abstract (string): The abstract for the type
                                                                • description (string): The description for the type
                                                                • keywords (list): The keywords for the type
                                                                • metadataLinks (list): The metadata URLs for the type
                                                                • SRS (string): The layer's SRS
                                                                • nativeCRS (string): The layer's coordinate reference system as WKT

                                                              FeatureCollection (map)

                                                              • features (list of Feature, see above)
                                                              • type (FeatureType, see above)

                                                              request (map)

                                                              Contains the GetFeatureInfo request parameters and related values.

                                                              environment (map)

                                                              Allows accessing several environment variables, in particular those defined in:

                                                              • JVM system properties
                                                              • OS environment variables
                                                              • web.xml context parameters

                                                              Math (map)

                                                              Allows accessing math functions.

                                                              "},{"location":"tutorials/freemarker/#examples","title":"Examples","text":"

                                                              request

                                                              • \\${request.LAYERS}
                                                              • \\${request.ENV.PROPERTY}

                                                              environment

                                                              • \\${environment.GEOSERVER_DATA_DIR}
                                                              • \\${environment.WEB_SITE_URL}

                                                              Math

                                                              • \\${Math.max(request.NUMBER1,request.NUMBER2)}
                                                              "},{"location":"tutorials/staticfiles/","title":"Serving Static Files","text":"

                                                              You can place static files in the www subdirectory of the GeoServer data directory, and they will be served at http:/myhost:8080/geoserver/www. This means you can deploy HTML, images, or JavaScript, and have GeoServer serve them directly on the web.

                                                              This approach has some limitations:

                                                              • This approach does not make use of accelerators such as the Tomcat APR library. If you have many static files to be served at high speed, you may wish to create your own web app to be deployed along with GeoServer or use a separate web server to serve the content.

                                                              The GEOSERVER_DISABLE_STATIC_WEB_FILES property can be set to true convert the text/html and application/javascript content types to text/plain in the Content-Type HTTP response header which will prevent web pages from being served through the www directory. This will help to prevent stored cross-site scripting vulnerabilities if the www directory is not being used at all or if it is only used to serve files other than web pages, such as PDF or Word documents. The default behavior is to NOT convert these content types. This property can be set either via Java system property, command line argument (-D), environment variable or web.xml init parameter.

                                                              "},{"location":"tutorials/wmsreflector/","title":"WMS Reflector","text":""},{"location":"tutorials/wmsreflector/#overview","title":"Overview","text":"

                                                              Standard WMS requests can be quite long and verbose. For instance the following, which returns an OpenLayers application with an 800x600 image set to display the feature topp:states, with bounds set to the northwestern hemisphere by providing the appropriate bounding box:

                                                              http://localhost:8080/geoserver/wms?service=WMS&request=GetMap&version=1.1.1&format=application/openlayers&width=800&height=600&srs=EPSG:4326&layers=topp:states&styles=population&bbox=-180,0,0,90\n

                                                              Typing into a browser, or HTML editor, can be quite cumbersome and error prone. The WMS Reflector solves this problem nicely by using good default values for the options that you do not specify. Using the reflector one can shorten the above request to:

                                                              http://localhost:8080/geoserver/wms/reflect?format=application/openlayers&layers=topp:states&width=800\n

                                                              This request only specifies that you want the reflector (wms/reflect) to return an OpenLayers application (format=application/openlayers), that you want it to display the feature \"topp:states\" (layers=topp:states) and that the width should be 800 pixels (width=800). However, this will not return the exact same value as above. Instead, the reflector will zoom to the bounds of the feature and return a map that is 800 pixels wide, but with the height adjusted to the aspect ratio of the feature.

                                                              "},{"location":"tutorials/wmsreflector/#using-the-wms-reflector","title":"Using the WMS Reflector","text":"

                                                              To use the WMS reflector all one must do is specify wms/reflect? as opposed to wms? in a request. The only mandatory parameter to a WMS reflector call is the layers parameter. As stated above the reflector fills in sensible defaults for the rest of the parameters. The following table lists all the defaults used:

                                                              request getmap

                                                              service wms

                                                              version 1.1.1

                                                              format image/png

                                                              width 512

                                                              height 512 if width is not specified

                                                              srs EPSG:4326

                                                              bbox bounds of layer(s)

                                                              Any of these defaults can be overridden when specifying the request. The styles parameter is derived by using the default style as configured by GeoServer for each layer specified in the layers parameter.

                                                              Any parameter you send with a WMS request is also legitimate when requesting data from the reflector. Its strength is what it does with the parameters you do not specify, which is explored in the next section.

                                                              layers: This is the only mandatory parameter. It is a comma separated list of the layers you wish to include in your image or OpenLayers application.

                                                              format: The default output format is image/png. Alternatives include image/jpeg (good for raster backgrounds), image/png8 (8 bit colors, smaller files) and image/gif

                                                              width: Describes the width of the image, alternatively the size of the map in an OpenLayers. It defaults to 512 pixels and can be calculated based on the height and the aspect ratio of the bounding box.

                                                              height: Describes the height of the image, alternatively the map in an OpenLayers. It can be calculated based on the width and the aspect ratio of the bounding box.

                                                              bbox: The bounding box is automatically determined by taking the union of the bounds of the specified layers. In essence, it determines the extent of the map. By default, if you do not specify bbox, it will show you everything. If you have one layer of Los Angeles, and another of New York, it show you most of the United States. The bounding box, automatically set or specified, also determines the aspect ratio of the map. If you only specify one of width or height, the other will be determined based on the aspect ratio of the bounding box.

                                                              Warning

                                                              If you specify height, width and bounding box there are zero degrees of freedom, and if the aspect ratios do not match your image will be warped.

                                                              styles: You can override the default styles by providing a comma separated list with the names of styles which must be known by the server.

                                                              srs: The spatial reference system (SRS) parameter is somewhat difficult. If not specified the WMS Reflector will use EPSG:4326 / WGS84. It will support the native SRS of the layers as well, provided all layers share the same one.

                                                              "},{"location":"tutorials/wmsreflector/#example-1","title":"Example 1","text":"

                                                              Request the layer topp:states , it will come back with the default style (demographic), width (512 pixels) and height (adjusted to aspect ratio):

                                                              http://localhost:8080/geoserver/wms/reflect?layers=topp:states\n
                                                              "},{"location":"tutorials/wmsreflector/#example-2","title":"Example 2","text":"

                                                              Request the layers topp:states and sf:restricted, it will come back with the default styles, and the specified width (640 pixels) and the height automatically adjusted to the aspect ratio:

                                                              http://localhost:8080/geoserver/wms/reflect?layers=topp:states,sf:restricted&width=640\n
                                                              "},{"location":"tutorials/wmsreflector/#example-3","title":"Example 3","text":"

                                                              In the example above the sf:restricted layer is very difficult to see, because it is so small compared to the United States. To give the user a chance to get a better view, if they choose, we can return an OpenLayers application instead. Zoom in on South Dakota (SD) to see the restricted areas:

                                                              http://localhost:8080/geoserver/wms/reflect?format=application/openlayers&layers=topp:states,sf:restricted&width=640\n
                                                              "},{"location":"tutorials/wmsreflector/#example-4","title":"Example 4","text":"

                                                              Now, if you mainly want to show the restricted layer, but also provide the context, you can set the bounding box for the request. The easiest way to obtain the coordinates is to use the application in example three and the coordinates at the bottom right of the map. The coordinates displayed in OpenLayers are x , y , the reflector service expects to be given bbox=minx,miny,maxx,maxy . Make sure it contains no whitespaces and users a period (\".\") as the decimal separator. In our case, it will be bbox=-103.929,44.375,-103.633,44.500 :

                                                              http://localhost:8080/geoserver/wms/reflect?format=application/openlayers&layers=topp:states,sf:restricted&width=640&bbox=-103.929,44.375,-103.633,44.500\n
                                                              "},{"location":"tutorials/wmsreflector/#outputting-to-a-webpage","title":"Outputting to a Webpage","text":"

                                                              Say you have a webpage and you wish to include a picture that is 400 pixels wide and that shows the layer topp:states, on this page.

                                                              <img src=\"http://localhost:8080/geoserver/wms/reflect?layers=topp:states&width=400\" />\n

                                                              If you want the page to render in the browser before GeoServer is done, you should specify the height and width of the picture. You could just pick any approximate value, but it may be a good idea to look at the generated image first and then use those values. In the case of the layer above, the height becomes 169 pixels, so we can specify that as an attribute in the tag:

                                                              <img src=\"http://localhost:8080/geoserver/wms/reflect?layers=topp:states&width=400\" height=\"169\" width=\"400\"/>\n

                                                              If you are worried that the bounds of the layer may change, so that the height changes relative to the width, you may also want to specify the height in the URL to the reflector. This ensures the layer will always be centered and fit on the 400x169 canvas.

                                                              The reflector can also create a simple instance of OpenLayers that shows the layers you specify in your request. One possible application is to turn the image above into a link that refers to the OpenLayers instance for the same feature, which is especially handy if you think a minority of your users will want to take closer look. To link to this JavaScript application, you need to specify the output format of the reflector: format=application/OpenLayers:

                                                              http://localhost:8080/geoserver/wms/reflect?format=application/openlayers&width=400\n

                                                              The image above then becomes

                                                              <a href=\"http://localhost:8080/geoserver/wms/reflect?format=application/openlayers&layers=topp:states\">\n<img src=\"http://localhost:8080/geoserver/wms/reflect?layers=topp:states&width=400\" height=\"169\" width=\"400\" />\n</a>\n

                                                              (The a-tags are on separate lines for clarity, they will in fact result in a space in front and after the image).

                                                              "},{"location":"tutorials/wmsreflector/#openlayers-in-an-iframe","title":"OpenLayers in an iframe","text":"

                                                              Many people do not like iframes, and for good reasons, but they may be appropriate in this case. The following example will run OpenLayers in an iframe.

                                                              <iframe src =\"http://localhost:8080/geoserver/wms/reflect?format=application/openlayers&layers=topp:states\" width=\"100%\">\n</iframe>\n

                                                              Alternatively, you can open OpenLayers in a separate webpage and choose \"View Source code\" in your browser. By copying the HTML you can insert the OpenLayers client in your own page without using an iframe.

                                                              "},{"location":"tutorials/GetFeatureInfo/","title":"GetFeatureInfo Templates","text":"

                                                              This tutorial describes how to use GeoServer to create custom GetFeatureInfo responses.

                                                              "},{"location":"tutorials/GetFeatureInfo/#introduction","title":"Introduction","text":"

                                                              GetFeatureInfo is a WMS standard call that allows you to retrieve information about features and coverages displayed in a map. The map can be composed of various layers, and GetFeatureInfo can be instructed to return multiple feature descriptions, which may be of different types. GetFeatureInfo can generate output in various formats: GML2, plain text, GeoJSON and HTML. Templating is concerned with the HTML and GeoJSON ones. While raster layers have a few more specific customization capabilities.

                                                              • HTML output format
                                                              • GeoJSON output format
                                                              • Raster GetFeatureInfo Response Customization
                                                              "},{"location":"tutorials/GetFeatureInfo/geojson/","title":"GeoJSON output format","text":"

                                                              The default GeoJSON output uses the WFS GeoJSON encoding mechanism, producing a fixed output, it is however possible to customize the output using FreeMarker templates. GeoServer will lookup for json templates following the same rules defined for the html output, but the template files have to be named appending _json to the usual name, as below:

                                                              • header_json.ftl
                                                              • content_json.ftl
                                                              • footer_json.ftl

                                                              Moreover, unlike the html case, all three template files must be provided. In case of a multi-layer request, GeoServer will act in the following way:

                                                              • content template will be searched following the usual rules;
                                                              • since there are no default templates for GeoJSON, header and footer will be looked up in the templates directory;
                                                              • features with no content template will be encoded with the normal GeoJSON encoding, along with the customized ones.

                                                              Follow examples of json template for each type.

                                                              The header json template:

                                                              {\n \"header\":\"this is the header\",\n \"type\":\"FeatureCollection\",\n \"features\":[\n

                                                              The footer json template:

                                                              ],\n\"footer\" : \"this is the footer\"\n}\n

                                                              The content json template:

                                                              <#list features as feature>\n{\n\"content\" : \"this is the content\",\n\"type\": \"Feature\",\n\"id\" : \"${feature.fid}\",\n<#list feature.attributes as attribute>\n<#if attribute.isGeometry>\n\"geometry\": ${geoJSON.geomToGeoJSON(attribute.rawValue)},\n<!--#if-->\n<!--#list-->\n\"properties\": {\n<#list feature.attributes?filter(a -> !a.isGeometry) as attribute>\n\"${attribute.name}\": \"${attribute.value}\"\n<#if attribute_has_next>\n,\n<!--#if-->\n<!--#list-->\n}\n}\n<#if feature_has_next>\n,\n<!--#if-->\n<!--#list-->\n

                                                              As it is possible to see from the content template, a new static model geoJSON, which has the geomToGeoJSON method has been provided. It can be used to encode a valid geoJSON geometry by passing to it the raw value of the geometry attribute in the following way: ${geoJSON.geomToGeoJSON(attribute.rawValue)}.

                                                              Placing the above templates in the directory of layer tiger_roads and issuing this request, :

                                                              http://localhost:8080/geoserver/tiger/wms?SERVICE=WMS&VERSION=1.1.1&REQUEST=GetFeatureInfo&FORMAT=application/json&TRANSPARENT=true&QUERY_LAYERS=tiger:tiger_roads&LAYERS=tiger:tiger_roads&exceptions=application/vnd.ogc.se_inimage&INFO_FORMAT=application/json&FEATURE_COUNT=50&X=50&Y=50&SRS=EPSG:4326&STYLES=&WIDTH=101&HEIGHT=101&BBOX=-73.96894311918004,40.78191518783569,-73.96460866941197,40.78624963760376\n

                                                              will produce the output:

                                                              {\n  \"header\":\"this is the header\",\n  \"type\":\"FeatureCollection\",\n  \"features\":[\n     {\n        \"content\":\"this is the content\",\n        \"type\":\"Feature\",\n        \"id\":\"tiger_roads.7752\",\n        \"geometry\":{\n           \"type\":\"MultiLineString\",\n           \"coordinates\":[\n              [\n                 [\n                    -73.9674,\n                    40.7844\n                 ],\n                 [\n                    -73.9642,\n                    40.7832\n                 ],\n                 [\n                    -73.9628,\n                    40.7813\n                 ]\n              ]\n           ]\n        },\n        \"properties\":{\n           \"CFCC\":\"A41\",\n           \"NAME\":\"85th St Transverse\"\n        }\n     }\n  ],\n  \"footer\":\"this is the footer\"\n}\n

                                                              While taking care of moving header_json.ftl and footer_json.ftl into the templates directory and performing the following request against the layer group tiger-ny :

                                                              http://localhost:8080/geoserver/wms?SERVICE=WMS&VERSION=1.1.1&REQUEST=GetFeatureInfo&FORMAT=application/json&TRANSPARENT=true&QUERY_LAYERS=tiger-ny&LAYERS=tiger-ny&exceptions=application/vnd.ogc.se_inimage&INFO_FORMAT=application/json&FEATURE_COUNT=50&X=50&Y=50&SRS=EPSG:4326&STYLES=&WIDTH=101&HEIGHT=101&BBOX=-74.01161170018896,40.70833468424098,-74.00944447530493,40.710501909125014\n

                                                              will return the following result:

                                                              {\n  \"header\":\"this is the header\",\n  \"type\":\"FeatureCollection\",\n  \"features\":[\n     {\n        \"type\":\"Feature\",\n        \"id\":\"giant_polygon.1\",\n        \"geometry\":{\n           \"type\":\"MultiPolygon\",\n           \"coordinates\":[\n              [\n                 [\n                    [\n                       -180,\n                       -90\n                    ],\n                    [\n                       -180,\n                       90\n                    ],\n                    [\n                       180,\n                       90\n                    ],\n                    [\n                       180,\n                       -90\n                    ],\n                    [\n                       -180,\n                       -90\n                    ]\n                 ]\n              ]\n           ]\n        },\n        \"properties\":{\n           \"@featureType\":\"giant_polygon\",\n           \"the_geom\":{\n              \"type\":\"MultiPolygon\",\n              \"coordinates\":[\n                 [\n                    [\n                       [\n                          -180,\n                          -90\n                       ],\n                       [\n                          -180,\n                          90\n                       ],\n                       [\n                          180,\n                          90\n                       ],\n                       [\n                          180,\n                          -90\n                       ],\n                       [\n                          -180,\n                          -90\n                       ]\n                    ]\n                 ]\n              ]\n           }\n        }\n     },\n     {\n        \"content\":\"this is the content\",\n        \"type\":\"Feature\",\n        \"id\":\"tiger_roads.7672\",\n        \"geometry\":{\n           \"type\":\"MultiLineString\",\n           \"coordinates\":[\n              [\n                 [\n                    -74.0108,\n                    40.7093\n                 ],\n                 [\n                    -74.0105,\n                    40.7096\n                 ]\n              ]\n           ]\n        },\n        \"properties\":{\n           \"CFCC\":\"A41\",\n           \"NAME\":\"Broadway\"\n        }\n     },\n     {\n        \"type\":\"Feature\",\n        \"id\":\"poi.3\",\n        \"geometry\":{\n           \"type\":\"Point\",\n           \"coordinates\":[\n              -74.01053,\n              40.709387\n           ]\n        },\n        \"properties\":{\n           \"@featureType\":\"poi\",\n           \"the_geom\":{\n              \"type\":\"Point\",\n              \"coordinates\":[\n                 -74.01053,\n                 40.709387\n              ]\n           },\n           \"NAME\":\"art\",\n           \"THUMBNAIL\":\"pics/22037856-Ti.jpg\",\n           \"MAINPAGE\":\"pics/22037856-L.jpg\"\n        }\n     }\n  ],\n  \"footer\":\"this is the footer\"\n}\n

                                                              As it is possible to see, the json output comprises a mix of the output mediated by a content_json.ftl for the tiger_roads feature, and the normal output for the other features, while header and footer have been kept respectively at the top and at the bottom.

                                                              "},{"location":"tutorials/GetFeatureInfo/html/","title":"HTML output format","text":"

                                                              The default HTML output is a sequence of titled tables, each one for a different layer. The following example shows the default output for the tiger-ny basemap (included in the above cited releases, and onwards).

                                                              Default Output

                                                              "},{"location":"tutorials/GetFeatureInfo/html/#standard-templates","title":"Standard Templates","text":"

                                                              The following assumes you're already up to speed with FreeMarker templates. If you're not, read the Freemarker Templates tutorial, and the KML Placemark Templates page, which has simple examples.

                                                              The default output is generated by the standard templates, which are three:

                                                              • header.ftl
                                                              • content.ftl
                                                              • footer.ftl

                                                              The header template is invoked just once, and usually contains the start of the HTML page, along with some CSS. The default header template looks like this (as you can see, it's completely static, and it's in fact not provided with any variable you could expand):

                                                              <#-- \nHeader section of the GetFeatureInfo HTML output. Should have the <head> section, and\na starter of the <body>. It is advised that eventual css uses a special class for featureInfo,\nsince the generated HTML may blend with another page changing its aspect when using generic classes\nlike td, tr, and so on. \n-->\n<html>\n  <head>\n    <title>GeoServer GetFeatureInfo output</title>\n  </head>\n  <style type=\"text/css\">\n    table.featureInfo, table.featureInfo td, table.featureInfo th {\n        border:1px solid #ddd;\n        border-collapse:collapse;\n        margin:0;\n        padding:0;\n        font-size: 90%;\n        padding:.2em .1em;\n    }\n    table.featureInfo th{\n        padding:.2em .2em;\n        text-transform:uppercase;\n        font-weight:bold;\n        background:#eee;\n    }\n    table.featureInfo td{\n        background:#fff;\n    }\n    table.featureInfo tr.odd td{\n        background:#eee;\n    }\n    table.featureInfo caption{\n        text-align:left;\n        font-size:100%;\n        font-weight:bold;\n        text-transform:uppercase;\n        padding:.2em .2em;\n    }\n  </style>\n  <body>\n

                                                              The footer template is similar, a static template used to close the HTML document properly:

                                                              <#-- \nFooter section of the GetFeatureInfo HTML output. Should close the body and the html tag.\n-->\n  </body>\n</html>\n

                                                              The content template is the one that turns feature objects into actual HTML tables. The template is called multiple times: each time it's fed with a different feature collection, whose features all have the same type. In the above example, the template has been called once for the roads, and once for the points of interest (POI). Here is the template source:

                                                              <#-- \nBody section of the GetFeatureInfo template, it's provided with one feature collection, and\nwill be called multiple times if there are various feature collections\n-->\n<table class=\"featureInfo\">\n  <caption class=\"featureInfo\">${type.name}</caption>\n  <tr>\n<#list type.attributes as attribute>\n  <#if !attribute.isGeometry>\n    <th >${attribute.name}</th>\n  <!--#if-->\n<!--#list-->\n  </tr>\n\n<#assign odd = false>\n<#list features as feature>\n  <#if odd>\n    <tr class=\"odd\">\n  <#else>\n    <tr>\n  <!--#if-->\n  <#assign odd = !odd>\n\n  <#list feature.attributes as attribute>\n    <#if !attribute.isGeometry>\n      <td>${attribute.value}</td>\n    <!--#if-->\n  <!--#list-->\n  </tr>\n<!--#list-->\n</table>\n<br/>\n

                                                              As you can see, there is a first loop scanning type and outputting its attributes into the table header, then a second loop going over each feature in the collection (features). From each feature, the attribute collections are accessed to dump the attribute value. In both cases, geometries are skipped, since there is not much point in including them in the tabular report. In the table building code you can also see how odd rows are given the \"odd\" class, so that their background colors improve readability.

                                                              "},{"location":"tutorials/GetFeatureInfo/html/#custom-templates","title":"Custom Templates","text":"

                                                              So, what do you have to do if you want to override the custom templates? Well, it depends on which template you want to override.

                                                              header.ftl and footer.ftl are type independent, so if you want to override them you have to place a file named header.ftl or footer.ftl in the templates directory, located in your GeoServer GeoServer data directory. On the contrary, content.ftl may be generic, or specific to a feature type.

                                                              For example, let's say you would prefer a bulleted list appearance for your feature info output, and you want this to be applied to all GetFeatureInfo HTML output. In that case you would drop the following content.ftl in the templates directory:

                                                              <ul>\n<#list features as feature>\n  <li><b>Type: ${type.name}</b> (id: <em>${feature.fid}</em>):\n  <ul>\n  <#list feature.attributes as attribute>\n    <#if !attribute.isGeometry>\n      <li>${attribute.name}: ${attribute.value}</li>\n    <!--#if-->\n  <!--#list-->\n  </ul>\n  </li>\n<!--#list-->\n</ul>\n

                                                              With this template in place, the output would be:

                                                              Bulleted List Output

                                                              Looking at the output we notice that point of interest features refer to image files, which we know are stored inside the default GeoServer distribution in the demo_app/pics path. So, we could provide a POI specific override that actually loads the images.

                                                              This is easy: just put the following template in the feature type folder, which in this case is workspaces/topp/DS_poi/poi (you should refer to your Internet visible server address instead of localhost, or its IP if you have fixed IPs):

                                                              <ul>\n<#list features as feature>\n  <li><b>Point of interest, \"${feature.NAME.value}\"</b>: <br/>\n  <img src=\"http://localhost:8080/geoserver/popup_map/${feature.THUMBNAIL.value}\"/>\n  </li>\n<!--#list-->\n</ul>\n

                                                              With this additional template, the output is:

                                                              Output with Thumbnail Image

                                                              As you can see, roads are still using the generic template, whilst POI is using its own custom template.

                                                              "},{"location":"tutorials/GetFeatureInfo/html/#advanced-formatting","title":"Advanced Formatting","text":"

                                                              The value property of Feature attribute values are given by geoserver in String form, using a sensible default depending on the actual type of the attribute value. If you need to access the raw attribute value in order to apply a custom format (for example, to output \"Enabled\" or \"Disabled\" for a given boolean property, instead of the default true/false, you can just use the rawValue property instead of value. For example: ${attribute.rawValue?string(\"Enabled\", \"Disabled\")} instead of just ${attribute.value}.

                                                              "},{"location":"tutorials/GetFeatureInfo/html/#auto-escaping","title":"Auto-Escaping","text":"

                                                              Auto-escaping can be used to escape special characters so that they are displayed correctly in clients and to prevent injection. GeoServer administrators can enable or disable auto-escaping for FreeMarker template values for the HTML output format on a global or per virtual service basis. Template authors are able to override the WMS service setting to enable or disable escaping on a per template, per block or per value basis. See Auto-escaping for more information.

                                                              "},{"location":"tutorials/GetFeatureInfo/html/#accessing-static-methods","title":"Accessing static methods","text":"

                                                              It is possible to call static methods and variables from within Freemarker templates to enable more sophisticated templates. But please be aware that generally static method calls are a security liability, which can be used to make harmful things, especially when template authors can not be fully trusted. So by default this feature is disabled. The configuration parameter org.geoserver.htmlTemplates.staticMemberAccess has to specified to enabled it, for example as system property. The parameter takes a comma separated list of fully qualified class names. GeoServer allows access to static member of these classes from within templates using their simple, unqualified class name as the example below demonstrates.

                                                              The following system property enables selective access:

                                                              -Dorg.geoserver.htmlTemplates.staticMemberAccess=java.lang.String\n

                                                              This exposes the static members of java.lang.String using the variable name String in the template, which can be used in templates as follows:

                                                              <ul>\n<#list features as feature>\n  <li>${feature.NAME.value}: ${String.format(\"%.2f \u20ac\", feature.AMOUNT.rawValue)}\n  </li>\n<!--#list-->\n</ul>\n

                                                              In case of granting access to multiple classes with the same simple name, the later specified classes will be exposed with a number suffix. For example when specifying -Dorg.geoserver.htmlTemplates.staticMemberAccess=java.lang.String,com.acme.String, the statics of java.lang.String will be exposed as String while the statics of com.acme.String will be exposed as String2 and so on.

                                                              You can also enable unrestricted access by specifying a * as the next example demonstrates.

                                                              The following system property enables unrestricted access:

                                                              -Dorg.geoserver.htmlTemplates.staticMemberAccess=*\n

                                                              In this case GeoServer exposes a statics variable you can use in templates to access static members as follows:

                                                              <#assign String=statics['java.lang.String']>\n<ul>\n<#list features as feature>\n  <li>${feature.NAME.value}: ${String.format(\"%.2f \u20ac\", feature.AMOUNT.rawValue)}\n  </li>\n<!--#list-->\n</ul>\n

                                                              Note

                                                              Unrestricted access as shown above is only recommended if you can fully trust your template authors.

                                                              "},{"location":"tutorials/GetFeatureInfo/raster/","title":"Raster GetFeatureInfo Response Customization","text":"

                                                              The default output for a GetFeatureInfo request on a raster layer contains just the value of the selected pixel, one for each band of the image. For instance, in case of an application/json output format:

                                                              {\n\"type\": \"FeatureCollection\",\n\"features\": [\n  {\n    \"type\": \"Feature\",\n    \"id\": \"\",\n    \"geometry\": null,\n    \"properties\": {\n      \"GRAY_INDEX\": 124,\n    }\n  }\n],\n\"totalFeatures\": \"unknown\",\n\"numberReturned\": 1,\n\"timeStamp\": \"2021-03-19T11:33:52.587Z\",\n\"crs\": null\n}\n

                                                              If the raster layer is associated with a Style based on a ColorMap, GeoServer allows to include in the output the labels of each ColorMapEntry matching the pixel. This is controlled by a VendorOption, that needs to be added inside the RasterSymbolizer holding the ColorMap.

                                                              <sld:RasterSymbolizer>\n   <sld:ColorMap>\n       <sld:ColorMapEntry color=\"#0000FF\" quantity=\"1.0\" label=\"low\"/>\n       <sld:ColorMapEntry color=\"#FFFF00\" quantity=\"124.81173566700335\" label=\"mid\"/>\n       <sld:ColorMapEntry color=\"#FF7F00\" quantity=\"559.2041949413946\" label=\"high\"/>\n       <sld:ColorMapEntry color=\"#FF0000\" quantity=\"55537.0\" label=\"veryhigh\"/>\n   </sld:ColorMap>\n   <sld:ContrastEnhancement/>\n   <VendorOption name=\"labelInFeatureInfo\">add</VendorOption>\n</sld:RasterSymbolizer>\n

                                                              The output produced by the above RasterSymbolizer looks as follows:

                                                              {\n\"type\": \"FeatureCollection\",\n\"features\": [ \n  { \n    \"type\": \"Feature\",\n    \"id\": \"\",\n    \"geometry\": null,\n    \"properties\": {\n      \"GRAY_INDEX\": 124,\n      \"Label_GRAY_INDEX\": \"mid\"\n    }\n  }\n],\n\"totalFeatures\": \"unknown\",\n\"numberReturned\": 1,\n\"timeStamp\": \"2021-03-19T11:33:52.587Z\",\n\"crs\": null\n}\n

                                                              As it's possible to see, the label's value has been added to the output with attribute name Label_GRAY_INDEX.

                                                              The VendorOption labelInFeatureInfo supports the following values:

                                                              • add the label value is added to the normal GetFeatureInfo output.
                                                              • replace the label value replaces the pixel value in the output.
                                                              • none no label is added to the output. We obtain a normal GetFeatureInfo response.

                                                              Additionally, it is possible to customize the attribute name of the label value, by means of a second VendorOption: <VendorOption name=\"labelAttributeName\">your custom name</VendorOption>.

                                                              Assuming to have a RasterSymbolizer like this

                                                              <sld:RasterSymbolizer>\n   <sld:ColorMap>\n       <sld:ColorMapEntry color=\"#0000FF\" quantity=\"1.0\" label=\"low\"/>\n       <sld:ColorMapEntry color=\"#FFFF00\" quantity=\"124.81173566700335\" label=\"mid\"/>\n       <sld:ColorMapEntry color=\"#FF7F00\" quantity=\"559.2041949413946\" label=\"high\"/>\n       <sld:ColorMapEntry color=\"#FF0000\" quantity=\"55537.0\" label=\"very high\"/>\n   </sld:ColorMap>\n   <sld:ContrastEnhancement/>\n   <VendorOption name=\"labelInFeatureInfo\">add</VendorOption>\n   <VendorOption name=\"labelAttributeName\">custom name</VendorOption>\n</sld:RasterSymbolizer>\n

                                                              we would obtain the following output, where the attribute name of the label value has been replaced by the one specified in the labelAttributeName VendorOption:

                                                              {\n \"type\": \"FeatureCollection\",\n \"features\": [\n   {\n     \"type\": \"Feature\",\n     \"id\": \"\",\n     \"geometry\": null,\n     \"properties\": {\n       \"GRAY_INDEX\": 159,\n       \"custom name\": \"mid\"\n     }\n   }\n ],\n \"totalFeatures\": \"unknown\",\n \"numberReturned\": 1,\n \"timeStamp\": \"2021-03-19T11:50:32.433Z\",\n \"crs\": null\n}\n

                                                              We have been using the JSON output format for the example above, but the two VendorOptions work for all other GetFeatureInfo output formats.

                                                              "},{"location":"tutorials/cloud-foundry/run_cf/","title":"Running GeoServer in Cloud Foundry","text":"

                                                              Many organizations are moving applications and databases workload to cloud providers. One target platform for apps is Cloud Foundry. While it is not the best environment for intense usage of GeoServer, it is sufficient for simple usage. This tutorial is a simple guide on a basic deployment.

                                                              For more advanced deployments, refer to section Advanced Topics

                                                              "},{"location":"tutorials/cloud-foundry/run_cf/#java-environment","title":"Java Environment","text":"

                                                              Cloud Foundry runs micro services written in multiple languages using the abstraction concept of language buildpacks. The java buildpack supports OpenJDK and proprietary JREs and tomcat from version 6.0.0 to 9.x.y

                                                              "},{"location":"tutorials/cloud-foundry/run_cf/#cloud-foundry-client","title":"Cloud Foundry client","text":"

                                                              To interact with Cloud Foundry, install the command line tool for your platform.

                                                              "},{"location":"tutorials/cloud-foundry/run_cf/#get-a-cloud-foundry-trial-account-or-use-your-organization-paid-plan","title":"Get a Cloud Foundry trial account (or use your organization paid plan)","text":"

                                                              Register for a free trial account with SAP or IBM.

                                                              Warning At this time, IBM doesn't allow more 64 MB of memory in free instances which prevents from starting the geoserver. The tutorial will be updated if this changes, however, the Cloud Foundry commands and manifest files are identical because Cloud Foundry truly is multi cloud!

                                                              "},{"location":"tutorials/cloud-foundry/run_cf/#cloud-foundry-on-sap-cloud-platform","title":"Cloud Foundry on SAP Cloud Platform","text":"

                                                              Logon to your cockpit and select your trial organization

                                                              Notice the field organization name and the Cloud Foundry API endpoint.

                                                              Use those 2 values to login with the command line:

                                                              $ cf login -a https://api.cf.eu10.hana.ondemand.com -o your_org_name_trial\nAPI endpoint: https://api.cf.eu10.hana.ondemand.com\n\nEmail: your.email@here.com\n\nPassword: \nAuthenticating...\nOK\n\nTargeted org your_org_name_trial\n\nTargeted space dev\n\n\n\nAPI endpoint:   https://api.cf.eu10.hana.ondemand.com (API version: 3.88.0)\nUser:           your.email@here.com\nOrg:            your_org_name_trial\nSpace:          dev\n

                                                              And now that you are logged in, you can list the apps:

                                                              cf apps\nGetting apps in org your_org_name_trial / space dev as your.email@here.com...\nOK\n\nNo apps found\n
                                                              "},{"location":"tutorials/cloud-foundry/run_cf/#publish-geoserver","title":"Publish GeoServer","text":"

                                                              Now that you are logged in to a Cloud Foundry space, you can publish GeoServer as a servlet. Download GeoServer as a war file. Create a deployment configuration file called manifest.yml:

                                                              ---\napplications:\n- name: geoserver\npath: ./geoserver.war\nhealth-check-type: process\nrandom-route: true\nbuildpacks:\n    - java_buildpack\n

                                                              The default behavior is to use the latest OpenJRE and tomcat versions. And voil\u00e0, you're ready to publish GeoServer!:

                                                              $ cf push -f manifest.yml\nPushing from manifest to org your.email@here.com / space dev as your.email@here.com...\nUsing manifest file manifest.yml\nGetting app info...\n[...]\nPackaging files to upload...\nUploading files...\n    45.38 MiB / 45.38 MiB [=================================================================] 100.00% 3m59s\n[...]\nWaiting for app to start...\n[...]\n

                                                              This should take two minutes the first time then you can check your application status by running:

                                                              $ cf apps\nGetting apps in org 2d2950f1trial / space dev as your.email@here.com...\nOK\n\nname        requested state   instances   memory   disk   urls\ngeoserver   started           1/1         1G       1G     geoserver-humble-puku-pi.cfapps.eu10.hana.ondemand.com\n

                                                              You can open the url in your browser. HTTP is automatically redirected to HTTPS and traffic is encrypted using the Cloud Foundry platform certificates which are trusted by most browsers.

                                                              "},{"location":"tutorials/cloud-foundry/run_cf/#advanced-topics","title":"Advanced Topics","text":""},{"location":"tutorials/cloud-foundry/run_cf/#changing-the-memory-limit","title":"Changing the memory limit","text":"

                                                              Use the command cf scale, for instance to set the limit at 2Gigabytes, execute:

                                                              $cf scale geoserver -m 2G -f\nScaling app geoserver in org 2d2950f1trial / space dev as your.email@here.com...\n

                                                              This restarts the application and displays the new limit:

                                                              state     since                    cpu    memory         disk           details\n#0   running   2020-11-13 01:54:56 PM   0.4%   470.8M of 2G   250.2M of 1G\n

                                                              As for most parameters, resource limits can also be set in the manifest file

                                                              "},{"location":"tutorials/cloud-foundry/run_cf/#changing-the-manifest-file","title":"Changing the manifest file","text":"The manifest file allows you to configure:
                                                              • Resource limits (memory and cpu)
                                                              • configure the route URL
                                                              • Set environment variables, for instance to set a specific tomcat version
                                                              ---\napplications:\n- name: geoserver\npath: ./geoserver.war\nhealth-check-type: process\nrandom-route: true\nbuildpacks:\n    - https://github.com/cloudfoundry/java-buildpack.git\nenv:\n    JBP_CONFIG_TOMCAT: '{ tomcat: { version: 8.0.+ } }'\n
                                                              "},{"location":"tutorials/cloud-foundry/run_cf/#scaling-challenges","title":"Scaling challenges","text":"

                                                              Total Memory limit of 8 GB. The goal of Cloud Foundry as a micro service platform is to break a monolithic application into smaller blocks. The containers are restricted to 8 GB in IBM and SAP platforms.

                                                              "},{"location":"tutorials/cql/cql_tutorial/","title":"CQL and ECQL","text":"

                                                              CQL (Common Query Language) is a query language created by the OGC for the Catalogue Web Services specification. Unlike the XML-based Filter Encoding language, CQL is written using a familiar text-based syntax. It is thus more readable and better-suited for manual authoring.

                                                              However, CQL has some limitations. For example it cannot encode id filters, and it requires an attribute to be on the left side of any comparison operator. For this reason, GeoServer provides an extended version of CQL called ECQL. ECQL removes the limitations of CQL, providing a more flexible language with stronger similarities with SQL.

                                                              GeoServer supports the use of both CQL and ECQL in WMS and WFS requests, as well as in GeoServer's SLD dynamic symbolizers. Whenever the documentation refers to CQL, ECQL syntax can be used as well (and if not, please report that as a bug!).

                                                              This tutorial introduces the CQL/ECQL language by example. For a full reference, refer to the ECQL Reference.

                                                              "},{"location":"tutorials/cql/cql_tutorial/#getting-started","title":"Getting started","text":"

                                                              The following examples use the topp:states sample layer shipped with GeoServer. They demonstrate how CQL filters work by using the WMS CQL_FILTER vendor parameter<wms_vendor_parameters> to alter the data displayed by WMS requests. The easiest way to follow the tutorial is to open the GeoServer Map Preview for the topp:states layer. Click on the Options button at the top of the map preview to open the advanced options toolbar. The example filters can be entered in the Filter: CQL box.

                                                              topp:states preview with advanced toolbar open.

                                                              The attributes used in the filter examples are those included in the layer. For example, the following are the attribute names and values for the Colorado feature:

                                                              Attribute states.6 STATE_NAME Colorado STATE_FIPS 08 SUB_REGION Mtn STATE_ABBR CO LAND_KM 268659.501 WATER_KM 960.364 PERSONS 3294394.0 FAMILIES 854214.0 HOUSHOLD 1282489.0 MALE 1631295.0 FEMALE 1663099.0 WORKERS 1233023.0 DRVALONE 1216639.0 CARPOOL 210274.0 PUBTRANS 46983.0 EMPLOYED 1633281.0 UNEMPLOY 99438.0 SERVICE 421079.0 MANUAL 181760.0 P_MALE 0.495 P_FEMALE 0.505 SAMP_POP 512677.0"},{"location":"tutorials/cql/cql_tutorial/#simple-comparisons","title":"Simple comparisons","text":"

                                                              Let's get started with a simple example. In CQL arithmetic and comparisons are expressed using plain text. The filter PERSONS > 15000000 will select states that have more than 15 million inhabitants:

                                                              PERSONS > 15000000

                                                              The full list of comparison operators is: =, <>, >, >=, <, <=.

                                                              To select a range of values the BETWEEN operator can be used: PERSONS BETWEEN 1000000 AND 3000000:

                                                              PERSONS BETWEEN 1000000 AND 3000000

                                                              Comparison operators also support text values. For instance, to select only the state of California, the filter is STATE_NAME = 'California'. More general text comparisons can be made using the LIKE operator. STATE_NAME LIKE 'N%' will extract all states starting with an \"N\":

                                                              STATE_NAME LIKE 'N%'

                                                              It is also possible to compare two attributes with each other. MALE > FEMALE selects the states in which the male population surpasses the female one (a rare occurrence):

                                                              MALE > FEMALE

                                                              Arithmetic expressions can be computed using the +, -, *, / operators. The filter UNEMPLOY / (EMPLOYED + UNEMPLOY) > 0.07 selects all states whose unemployment ratio is above 7% (remember the sample data is very old, so don't draw any conclusion from the results!)

                                                              UNEMPLOY / (EMPLOYED + UNEMPLOY) > 0.07

                                                              "},{"location":"tutorials/cql/cql_tutorial/#id-and-list-comparisons","title":"Id and list comparisons","text":"

                                                              If we want to extract only the states with specific feature ids we can use the IN operator without specifying any attribute, as in IN ('states.1', 'states.12'):

                                                              IN ('states.1', 'states.12')

                                                              If instead we want to extract the states whose name is in a given list we can use the IN operator specifying an attribute name, as in STATE_NAME IN ('New York', 'California', 'Montana', 'Texas'):

                                                              STATE_NAME IN ('New York', 'California', 'Montana', 'Texas')

                                                              Warning

                                                              Note: id is one of a few reserved keywords in ECQL and thus an attribute (or database column) named id must be quoted, e.g. \"id\"

                                                              "},{"location":"tutorials/cql/cql_tutorial/#filter-functions","title":"Filter functions","text":"

                                                              CQL/ECQL can use any of the filter functions available in GeoServer. This greatly increases the power of CQL expressions.

                                                              For example, suppose we want to find all states whose name contains an \"m\", regardless of letter case. We can use the strToLowerCase to turn all the state names to lowercase and then use a like comparison: strToLowerCase(STATE_NAME) like '%m%':

                                                              strToLowerCase(STATE_NAME) like '%m%'

                                                              "},{"location":"tutorials/cql/cql_tutorial/#geometric-filters","title":"Geometric filters","text":"

                                                              CQL provides a full set of geometric filter capabilities. Say, for example, you want to display only the states that intersect the (-90,40,-60,45) bounding box. The filter will be BBOX(the_geom, -90, 40, -60, 45)

                                                              BBOX(the_geom, -90, 40, -60, 45)

                                                              Conversely, you can select the states that do not intersect the bounding box with the filter: DISJOINT(the_geom, POLYGON((-90 40, -90 45, -60 45, -60 40, -90 40))):

                                                              DISJOINT(the_geom, POLYGON((-90 40, -90 45, -60 45, -60 40, -90 40)))

                                                              The full list of geometric predicates is: EQUALS, DISJOINT, INTERSECTS, TOUCHES, CROSSES, WITHIN, CONTAINS, OVERLAPS, RELATE, DWITHIN, BEYOND.

                                                              "},{"location":"tutorials/feature-pregeneralized/feature-pregeneralized_tutorial/","title":"Using the GeoTools feature-pregeneralized module","text":"

                                                              Warning

                                                              The screenshots on this tutorial have not yet been updated for the 2.0.x user interface. But most all the rest of the information should be valid, and the user interface is roughly the same, but a bit more easy to use.

                                                              "},{"location":"tutorials/feature-pregeneralized/feature-pregeneralized_tutorial/#introduction","title":"Introduction","text":"

                                                              This tutorial shows how to use the geotools feature-pregeneralized module in GeoServer. The feature-pregeneralized module is used to improve performance and lower memory usage and IO traffic.

                                                              Note

                                                              Vector generalization reduces the number of vertices of a geometry for a given purpose. It makes no sense drawing a polygon with 500000 vertices on a screen. A much smaller number of vertices is enough to draw a topological correct picture of the polygon.

                                                              This module needs features with already generalized geometries, selecting the best fit geometry on demand.

                                                              The full documentation is available in GeoTools Pregeneralized Plugin documentation.

                                                              This tutorial will show two possible scenarios, explaining step by step what to do for using this module in GeoServer.

                                                              "},{"location":"tutorials/feature-pregeneralized/feature-pregeneralized_tutorial/#getting-started","title":"Getting Started","text":"

                                                              First, find the location of the GEOSERVER_DATA_DIR. This info is contained in the log file when starting GeoServer.:

                                                              ----------------------------------\n- GEOSERVER_DATA_DIR: /home/mcr/geoserver-1.7.x/1.7.x/data/release\n----------------------------------\n

                                                              Within this directory, we have to place the shape files. There is already a sub directory data which will be used. Within this sub directory, create a directory streams.

                                                              Within {GEOSERVER_DATA_DIR}/data/streams create another sub directory called 0. ( 0 meaning \"no generalized geometries\").

                                                              This tutorial is based on a shape file, which you can download from here Streams. Unzip this file into {GEOSERVER_DATA_DIR}/data/streams/0.

                                                              Look for the WEB-INF/lib/ directory of your GeoServer installation. There must be a file called gt-feature-pregeneralized-{version}-jar. This jar file includes a tool for generalizing shape files. Open a cmd line and execute the following:

                                                              cd <GEOSERVER_DATA_DIR>/data/streams/0\njava -jar <GEOSERVER_INSTALLATION>/WEB-INF/lib/gt-feature-pregeneralized-{version}.jar generalize 0/streams.shp . 5,10,20,50\n

                                                              You should see the following output:

                                                              Shape file            0/streams.shp\nTarget directory      .\nDistances             5,10,20,50\n% |################################|\n

                                                              Now there are four additional directories 5.0 , 10.0 , 20.0 , 50.0 . Look at the size of files with the extension shp within these directories, increasing the generalization distance reduces the file size.

                                                              Note

                                                              The generalized geometries can be stored in additional properties of a feature or the features can be duplicated. Mixed variations are also possible. Since we are working with shape files we have to duplicate the features.

                                                              There are two possibilities how we can deploy our generalized shape files.

                                                              1. Deploy hidden (not visible to the user)
                                                              2. Deploy each generalized shape file as a separate GeoServer feature
                                                              "},{"location":"tutorials/feature-pregeneralized/feature-pregeneralized_tutorial/#hidden-deployment","title":"Hidden Deployment","text":"

                                                              First we need a XML config file

                                                              <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<GeneralizationInfos version=\"1.0\">\n  <GeneralizationInfo dataSourceName=\"file:data/streams/0/streams.shp\"  featureName=\"GenStreams\" baseFeatureName=\"streams\" geomPropertyName=\"the_geom\">\n      <Generalization dataSourceName=\"file:data/streams/5.0/streams.shp\"  distance=\"5\" featureName=\"streams\" geomPropertyName=\"the_geom\"/>\n      <Generalization dataSourceName=\"file:data/streams/10.0/streams.shp\"  distance=\"10\" featureName=\"streams\" geomPropertyName=\"the_geom\"/>\n      <Generalization dataSourceName=\"file:data/streams/20.0/streams.shp\"  distance=\"20\" featureName=\"streams\" geomPropertyName=\"the_geom\"/>\n      <Generalization dataSourceName=\"file:data/streams/50.0/streams.shp\"  distance=\"50\" featureName=\"streams\" geomPropertyName=\"the_geom\"/>      \n  </GeneralizationInfo>\n</GeneralizationInfos>\n

                                                              Save this file as geninfo_shapefile.xml into {GEOSERVER_DATA_DIR}/data/streams.

                                                              Note

                                                              The dataSourceName attribute in the XML config is not interpreted as a name, it could be the URL for a shape file or for a property file containing properties for data store creation (e. g. jdbc connect parameters). Remember, this is a hidden deployment and no names are needed. The only official name is the value of the attribute featureName in the GeneralizationInfo Element.

                                                              Start GeoServer and go to Config\u2192Data\u2192DataStores\u2192New and fill in the form

                                                              Press Submit.

                                                              The next form you see is

                                                              Note

                                                              RepositoryClassName and GeneralizationInfosProviderClassName have default values which suit for GeoTools, not for GeoServer. Change GeoTools to GeoServer in the package names to instantiate the correct objects for GeoServer. GeneralizationInfosProviderParam could be an URL or a datastore from the GeoServer catalog. A datastore is referenced by using workspacename:datastorename. This makes sense if you have your own implementation for the GeneralizationInfosProvider interface and this implementation reads the infos from a database.

                                                              The configuration should look like this

                                                              Press Submit, afterward a form for the feature type opens.

                                                              Alter the Style to line, SRS is 26713 and press the Generate button labeled by Bounding Box.

                                                              Afterward, press Submit, Apply and Save.

                                                              Examine the result by pressing \"My GeoServer, Demo and Map Preview. In this list there must be an entry topp:GenStreams. Press it and you will see

                                                              Now start zooming in and out and look at the log file of GeoServer. If the deployment is correct you should see something like this:

                                                              May 20, 2009 4:53:05 PM org.geotools.data.gen.PreGeneralizedFeatureSource logDistanceInfo\nINFO: Using generalizsation: file:data/streams/20.0/streams.shp streams the_geom 20.0\nMay 20, 2009 4:53:41 PM org.geotools.data.gen.PreGeneralizedFeatureSource logDistanceInfo\nINFO: Using generalizsation: file:data/streams/5.0/streams.shp streams the_geom 5.0\nMay 20, 2009 4:54:08 PM org.geotools.data.gen.PreGeneralizedFeatureSource logDistanceInfo\nINFO: Using generalizsation: file:data/streams/5.0/streams.shp streams the_geom 5.0\nMay 20, 2009 4:54:09 PM org.geotools.data.gen.PreGeneralizedFeatureSource logDistanceInfo\nINFO: Using generalizsation: file:data/streams/20.0/streams.shp streams the_geom 20.0\n
                                                              "},{"location":"tutorials/feature-pregeneralized/feature-pregeneralized_tutorial/#public-deployment","title":"Public Deployment","text":"

                                                              First we have to configure all our shape files

                                                              The Feature Data Set ID for the other shape files is

                                                              1. Streams_5
                                                              2. Streams_10
                                                              3. Streams_20
                                                              4. Streams_50

                                                              The URL needed for the other shape files

                                                              1. file:data/streams/5.0/streams.shp
                                                              2. file:data/streams/10.0/streams.shp
                                                              3. file:data/streams/20.0/streams.shp
                                                              4. file:data/streams/50.0/streams.shp

                                                              Each feature needs an Alias, here it is streams_0. For the other shape files use

                                                              1. streams_5
                                                              2. streams_10
                                                              3. streams_20
                                                              4. streams_50

                                                              Check the result by pressing My GeoServer, Demo and Map Preview. You should see your additional layers.

                                                              No we need another XML configuration file

                                                              <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<GeneralizationInfos version=\"1.0\">\n  <GeneralizationInfo dataSourceNameSpace=\"topp\" dataSourceName=\"Streams_0\"  featureName=\"GenStreams2\" baseFeatureName=\"streams\" geomPropertyName=\"the_geom\">\n      <Generalization dataSourceNameSpace=\"topp\" dataSourceName=\"Streams_5\"  distance=\"5\" featureName=\"streams\" geomPropertyName=\"the_geom\"/>\n      <Generalization dataSourceNameSpace=\"topp\" dataSourceName=\"Streams_10\"  distance=\"10\" featureName=\"streams\" geomPropertyName=\"the_geom\"/>\n      <Generalization dataSourceNameSpace=\"topp\" dataSourceName=\"Streams_20\"  distance=\"20\" featureName=\"streams\" geomPropertyName=\"the_geom\"/>\n      <Generalization dataSourceNameSpace=\"topp\" dataSourceName=\"Streams_50\"  distance=\"50\" featureName=\"streams\" geomPropertyName=\"the_geom\"/>       \n  </GeneralizationInfo>\n</GeneralizationInfos>\n

                                                              Save this file as geninfo_shapefile2.xml into {GEOSERVER_DATA_DIR}/data/streams.

                                                              Create the pregeneralized datastore

                                                              Now we use the CatalogRepository class to find our needed data stores

                                                              Last step

                                                              In the Map Preview you should find topp:GenStreams2 and all other generalizations. Test in the same manner we discussed in the hidden deployment and you should see something like this in the GeoServer log:

                                                              May 20, 2009 6:11:06 PM org.geotools.data.gen.PreGeneralizedFeatureSource logDistanceInfo\nINFO: Using generalizsation: Streams_20 streams the_geom 20.0\nMay 20, 2009 6:11:08 PM org.geotools.data.gen.PreGeneralizedFeatureSource logDistanceInfo\nINFO: Using generalizsation: Streams_10 streams the_geom 10.0\nMay 20, 2009 6:11:12 PM org.geotools.data.gen.PreGeneralizedFeatureSource logDistanceInfo\nINFO: Using generalizsation: Streams_10 streams the_geom 10.0\n
                                                              "},{"location":"tutorials/feature-pregeneralized/feature-pregeneralized_tutorial/#conclusion","title":"Conclusion","text":"

                                                              This is only a very simple example using shape files. The plugin architecture allows you to get your data and generalizations from anywhere. The used dataset is a very small one, so you will not feel a big difference in response time. Having big geometries (in the sense of many vertices) and creating maps with some different layers will show the difference.

                                                              "},{"location":"tutorials/georss/georss/","title":"GeoRSS","text":"

                                                              GeoServer supports GeoRSS as an output format allowing you to serve features as an RSS feed.

                                                              "},{"location":"tutorials/georss/georss/#quick-start","title":"Quick Start","text":"

                                                              If you are using a web browser which can render RSS feeds simply visit the URL http://localhost:8080/geoserver/wms/reflect?layers=states&format=rss in your browser. This is assuming a local GeoServer instance is running with an out of the box configuration. You should see a result that looks more or less like this:

                                                              topp:states rss feed

                                                              "},{"location":"tutorials/georss/georss/#templating","title":"Templating","text":"

                                                              GeoServer uses FreeMarker templates to customize the returned GeoRSS feed. If you are not familiar with FreeMarker templates you may wish to read the Freemarker Templates tutorial, and the KML Placemark Templates page, which has simple examples.

                                                              Three template files are currently supported:

                                                              • title.ftl
                                                              • description.ftl
                                                              • link.ftl

                                                              Each of these files may be used to customize the associated field in the GeoRSS feed.

                                                              "},{"location":"tutorials/georss/georss/#ajax-map-mashups","title":"Ajax Map Mashups","text":"

                                                              Note

                                                              For Ajax map mashups to work, the GeoServer instance must be visible to the Internet (i.e. using the address localhost will not work).

                                                              "},{"location":"tutorials/georss/georss/#google-maps","title":"Google Maps","text":"

                                                              How to create a Google Maps mashup with a GeoRSS overlay produced by GeoServer.

                                                              1. Obtain a Google Maps API Key from Google.

                                                              2. Create an html file called gmaps.html:

                                                                <!DOCTYPE html PUBLIC \"-//W3C//DTD XHTML 1.0 Strict//EN\" \"http://www.w3.org    R/xhtml1/DTD/xhtml1-strict.dtd\">\n<html xmlns=\"http://www.w3.org/1999/xhtml\">\n    <head>\n    <meta http-equiv=\"content-type\" content=\"text/html; charset=utf-8\"/>\n    <title>Google Maps JavaScript API Example<    itle>\n    <script src=\"http://maps.google.com/maps?file=api&amp;v=2.x&amp;key=<INSERT MAPS API KEY HERE>\" type=\"text/javascript\"></script>\n\n    <script type=\"text/javascript\">\n    //<![CDATA[\n        function load() {\n            if (GBrowserIsCompatible()) {\n                var map = new GMap2(document.getElementById(\"map\"));\n                map.addControl(new GLargeMapControl());\n                map.setCenter(new GLatLng(40,-98), 4);\n                var geoXml = new GGeoXml(\"<INSERT GEOSERVER URL HERE>/geoserver/wms/reflect?layers=states&format=rss\");\n                map.addOverlay(geoXml);\n            }\n        }\n    //]]>\n    </script>\n\n    </head>\n    <body onload=\"load()\" onunload=\"GUnload()\">\n        <div id=\"map\" style=\"width: 800px; height: 600px\"></div>\n    </body>\n</html>\n
                                                              3. Visit gmaps.html in your web browser.

                                                              Note

                                                              The version of the google maps api must be 2.x, and not just 2 You must insert your specific maps api key, and geoserver base url

                                                              "},{"location":"tutorials/georss/georss/#yahoo-maps","title":"Yahoo Maps","text":"

                                                              How to create a Yahoo! Maps mashup with a GeoRSS overlay produced by GeoServer.

                                                              1. Obtain a <Yahoo Maps Application ID <http://search.yahooapis.com/webservices/register_application>`_ from Yahoo.

                                                              2. Create an html file called ymaps.html:

                                                                <html>\n    <head>\n    <title>Yahoo! Maps GeoRSS Overlay Example<    itle>\n    <script src=\"http://api.maps.yahoo.com/ajaxymap?v=3.0&appid=<INSERT APPLICATION ID HERE>\" type=\"text/javascript\"></script>\n    <script type=\"text/javascript\" language=\"JavaScript\">\n\n        function StartYMap() {\n            var map = new YMap(document.getElementById('ymap')); \n            map.addPanControl();\n            map.addZoomShort();\n\n            function doStart(eventObj) {\n                var defaultEventObject = eventObj;\n                //eventObj.ThisMap [map object]\n                //eventObj.URL [argument]\n                //eventObj.Data [processed input]\n            }\n\n            function doEnd(eventObj) {\n                var defaultEventObject = eventObj;\n                //eventObj.ThisMap [map object]\n                //eventObj.URL [argument]\n                //eventObj.Data [processed input]\n                map.smoothMoveByXY(new YCoordPoint(10,50));\n            }\n\n            YEvent.Capture(map,EventsList.onStartGeoRSS, function(eventObj) { doStart(eventObj); });\n            YEvent.Capture(map,EventsList.onEndGeoRSS, function(eventObj) { doEnd(eventObj); });\n\n            map.addOverlay(new YGeoRSS('http://<INSERT GEOSERVER URL HERE>/geoserver/wms/reflect?layers=states&format=rss'));\n        }\n\n    window.onload = StartYMap;\n     </script>\n      </head>\n      <body>\n           <div id=\"ymap\" style=\"width: 800px; height: 600px; left:2px; top:2px\"></div>\n     </body>\n</html>\n
                                                              3. Visit ymaps.html in your web browser.

                                                              Note

                                                              The version of the yahoo maps api must be 3.0 You must insert your specific application id, and geoserver base url

                                                              "},{"location":"tutorials/georss/georss/#microsoft-virtual-earth","title":"Microsoft Virtual Earth","text":"

                                                              Note

                                                              Non Internet Explorer Users*: GeoRSS overlays are only supported in Internet Explorer, versions greater than 5.5.

                                                              How to create a Microsoft Virtual Earth mashup with a GeoRSS overlay produced by GeoServer.

                                                              Note

                                                              To access a GeoRSS feed from Microsoft Virtual Earth the file (ve.html) must be accessed from a Web Server, IE. It will not work if run from local disk.

                                                              1. Create an html file called ve.html. Note: You must insert your specific maps api key, and geoserver base url:

                                                                <html>\n  <head>\n    <script src=\"http://dev.virtualearth.net/mapcontrol/v4/mapcontrol.js\"></script>\n    <script>\n     var map;\n\n     function OnPageLoad()\n     {\n        map = new VEMap('map');\n        map.LoadMap();\n\n        var veLayerSpec = new VELayerSpecification();\n        veLayerSpec.Type = VELayerType.GeoRSS;\n        veLayerSpec.ID = 'Hazards';\n    veLayerSpec.LayerSource = 'http://<INSERT GEOSERVER URL HERE>/geoserver/wms/reflect?layers=states&format=rss';\n    veLayerSpec.Method = 'get';\n    map.AddLayer(veLayerSpec);\n    }\n   </script>\n </head>\n <body onload=\"OnPageLoad();\">\n    <div id=\"map\" style=\"position:relative;width:800px;height:600px;\"></div>\n  </body>\n\n</html>\n
                                                              2. Visit ve.html in your web browser. You should see the following:

                                                              Virtual Earth

                                                              "},{"location":"tutorials/imagemosaic_footprint/imagemosaic_footprint/","title":"Using the ImageMosaic plugin with footprint management","text":""},{"location":"tutorials/imagemosaic_footprint/imagemosaic_footprint/#introduction","title":"Introduction","text":"

                                                              This step-by-step tutorial describes how to associate Footprint to a raster data using the ImageMosaic plugin.

                                                              Footprint is a Shape used as a Mask for the mosaic. Masking can be useful for hiding pixels which are meaningless, or for enhancing only few regions of the image in respect to others.

                                                              This tutorial assumes knowledge of the concepts explained in ImageMosaic section.

                                                              This tutorial contains two sections:

                                                              • The first section, Configuration, describes the possible configurations needed to set up an ImageMosaic with footprint.
                                                              • The second section, Examples, provides examples of configuration of an ImageMosaic with footprint.
                                                              "},{"location":"tutorials/imagemosaic_footprint/imagemosaic_footprint/#configuration","title":"Configuration","text":"

                                                              Footprint can be configured in three different ways:

                                                              1. By using for each mosaic granule a Sidecar File, a Shapefile with the same name of the granule which contains the footprint for it;
                                                              2. By using a single Shapefile called footprints.shp which contains all the footprints for each granule; each footprint is associated to a granule with the location attribute;
                                                              3. By using a file called footprints.properties .

                                                              The last option should be used when the first two are not available and requires to write the following piece of code inside the footprints.properties file:

                                                              footprint_source=*location of the Shapefile*\nfootprint_filter=*filter on the Shapefile searching for the attribute associated to each granule*\n

                                                              For example if a Shapefile called fakeShapeFile stores the various footprints in a table like this, where each Name attribute is referred to a granule file:

                                                              And the associated granules are:

                                                              • ortho_1-1_1n_s_la087_2010_1.tif
                                                              • ortho_2-2_1n_s_la075_2010_1.tif
                                                              • ortho_1-1_1n_s_la103_2010_1.tif
                                                              • and so on ...

                                                              The associated footprints.properties file must be like this:

                                                              footprint_source=fakeShapeFile.shp\nfootprint_filter=Name=strSubstring(granule.location, 0, strLength(granule.location) - 4)\n

                                                              The substring operation is done for comparing the footprint attribute names and the granule names without the .tif extension.

                                                              There are three possible behaviours for Footprint:

                                                              • None: simply doesn't use the Footprint and behaves like a standard ImageMosaic layer;
                                                              • Transparent: adds an alpha band of 0s on the image portions outside of the Footprint making them transparent, typically used for RGB data;
                                                              • Cut: set the background value on the image portions outside of the Footprint, typically used for GrayScale data.

                                                              The behaviour must be set directly on the Layer configuration page.

                                                              Another feature of the Footprint is the possibility to calculate an Inset of the image. Inset is a reduction of the footprint border by a value defined by the user which is typically used for removing the compression artifacts. This feature can be achieved by adding the following code inside footprints.properties (in case of the first two configurations this file must be added):

                                                              footprint_inset=*value in the shapefile u.o.m.*\nfootprint_inset_type=*full/border*\n

                                                              Full inset type calculates the inset for each footprint side while Border does the same operation but those straight lines that overlap the image bounds are avoided; this last parameter is useful for images already cut in a regular grid.

                                                              Each modification of the footprints.properties file requires to Reload GeoServer. This operation can be achieved by going to Server Status and clicking on the Reload button on the bottom-right side of the page.

                                                              The two datasets used in the tutorial can be downloaded here: Mosaic with a single image which represents Boulder (Colorado), Mosaic with multiple images which represents Italy. The first can be used for testing footprint configuration with a Sidecar File and the second for the other two configurations.

                                                              "},{"location":"tutorials/imagemosaic_footprint/imagemosaic_footprint/#examples","title":"Examples","text":"

                                                              Here are presented a few steps for configuring a new ImageMosaic layer with footprint.

                                                              "},{"location":"tutorials/imagemosaic_footprint/imagemosaic_footprint/#step-1-create-a-new-imagemosaic-layer","title":"Step 1: Create a new ImageMosaic Layer","text":"

                                                              As seen before an ImageMosaic data store can be created by going to Stores \u2192 Add New Store \u2192 ImageMosaic.

                                                              An associated Layer can be created by going to Layers \u2192 Add New Resource, choosing the name of the data store created above and then clicking on the publish button.

                                                              "},{"location":"tutorials/imagemosaic_footprint/imagemosaic_footprint/#step-2-configuring-a-new-layer-for-the-mosaic","title":"Step 2: Configuring a new Layer for the Mosaic","text":"

                                                              Inside the new page the only field which is interesting for this tutorial is FootprintBehavior:

                                                              The user can set one of the three values for the Footprint behaviour as described above.

                                                              After that, the user must confirm the modification by clicking on the Save button on the bottom side of the page.

                                                              "},{"location":"tutorials/imagemosaic_footprint/imagemosaic_footprint/#step-3-example-results","title":"Step 3: Example Results","text":"

                                                              Here are presented the results for each dataset.

                                                              "},{"location":"tutorials/imagemosaic_footprint/imagemosaic_footprint/#footprint-configured-with-sidecar-file","title":"Footprint configured with Sidecar File","text":"

                                                              This is an example of mosaic without applying Footprint:

                                                              And this is the result of setting FootprintBehavior to Cut:

                                                              Background is gray because in this example the BackgroundValues field has been set to -20000.

                                                              If an Inset is added, the final mosaic is:

                                                              The footprints.properties file is:

                                                              footprint_inset=0.01\nfootprint_inset_type=full\n

                                                              Note

                                                              Remember that each modification on footprints.properties requires a Reload of GeoServer for seeing the results.

                                                              Note

                                                              When configuring this mosaic you must set the declared CRS field to \"EPSG:4326\".

                                                              "},{"location":"tutorials/imagemosaic_footprint/imagemosaic_footprint/#footprint-configured-with-footprintsshp","title":"Footprint configured with footprints.shp","text":"

                                                              This is another example of mosaic without Footprint:

                                                              And now after setting FootprintBehavior to Transparent (no Inset is used) on the Layer:

                                                              "},{"location":"tutorials/imagemosaic_footprint/imagemosaic_footprint/#footprint-configured-with-footprintsproperties","title":"Footprint configured with footprints.properties","text":"

                                                              Note

                                                              For testing this functionality the user must rename all the footprints.xxx files to mask.xxx.

                                                              The result of setting FootprintBehavior to Transparent, Inset type to border and Inset value to 0.00001 is:

                                                              The footprints.properties file is:

                                                              footprint_source=mask.shp\nfootprint_inset=0.00001\nfootprint_inset_type=border\n
                                                              "},{"location":"tutorials/imagemosaic_footprint/imagemosaic_footprint/#raster-masking","title":"Raster Masking","text":"

                                                              From 2.8.x version, GeoServer is able to support also Raster Masks. Those masks can be internal or external (in which case the mask files should use the .msk extension), for each file. It is crucial that mask files should have the same pixel size, georeferencing and CRS as the image they are masking.

                                                              It must be pointed out that external/internal masks may have overviews like the related original images.

                                                              More information about Mask bands may be found at the GDAL Mask Band Page

                                                              A footprints.properties file that would exploit raster masks would be as follows:

                                                              footprint_source=raster\n

                                                              Note

                                                              Raster masks do not support to control inset.

                                                              Below you may find an example of configuring a Mosaic with Raster masks:

                                                              "},{"location":"tutorials/imagemosaic_footprint/imagemosaic_footprint/#step-1-create-a-new-imagemosaic-layer_1","title":"Step 1: Create a new ImageMosaic Layer","text":"

                                                              Download data from the following link and configure an ImageMosaic layer called rastermask without changing default configuration parameters.

                                                              Zip file contains two images and their related .msk files. For this example the two masks are two simple squares.

                                                              "},{"location":"tutorials/imagemosaic_footprint/imagemosaic_footprint/#step-2-watch-the-layer-using-layerpreview","title":"Step 2: Watch the layer using LayerPreview","text":"

                                                              Go to LayerPreview \u2192 rastermask \u2192 OpenLayers. The result should be similar to the one below.

                                                              "},{"location":"tutorials/imagemosaic_footprint/imagemosaic_footprint/#step-3-change-the-footprint-behavior","title":"Step 3: Change the Footprint Behavior","text":"

                                                              Change the FootprintBehavior parameter to Transparent. Cut value should not be used since the files are RGB.

                                                              "},{"location":"tutorials/imagemosaic_footprint/imagemosaic_footprint/#step-4-check-the-result","title":"Step 4: Check the result","text":"

                                                              Go to LayerPreview \u2192 rastermask \u2192 OpenLayers. The result should be changed now.

                                                              "},{"location":"tutorials/imagemosaic_footprint/imagemosaic_footprint/#multilevel-geometry-masking","title":"Multilevel Geometry Masking","text":"

                                                              From 2.14.x version, GeoServer is able to support also multilevel overviews geometries (A geometry footprint for each overview, being stored on a separate sidecar file).

                                                              A footprints.properties file that would exploit multiple WKB sidecar files would be as follows:

                                                              footprint_source=multisidecar\nfootprintLoaderSPI=org.geotools.coverage.grid.io.footprint.WKBLoaderSPI\noverviewsFootprintLoaderSPI=org.geotools.coverage.grid.io.footprint.WKBLoaderSPI\noverviewsRoiInRasterSpace=True\noverviewsSuffixFormat=_%d\n

                                                              Notes:

                                                              • footprintLoaderSPI: Contains the fully qualified name of the SPI implementation for main footprint loading (Optional property. When not specified, the proper footprint loader will be automatically found by scanning the available SPIs). Currently supported values are:

                                                                • org.geotools.coverage.grid.io.footprint.WKBLoaderSPI for WKB overviews
                                                                • org.geotools.coverage.grid.io.footprint.WKTLoaderSPI for WKT overviews
                                                                • org.geotools.gce.imagemosaic.catalog.ShapeFileLoaderSPI for Shapefile overviews
                                                              • overviewsFootprintLoaderSPI: Contains the fully qualified name of the SPI implementation for overviews footprints loading (Optional property. When not specified, same loader as footprintLoaderSpi will be used if provided);

                                                              • overviewsRoiInRasterSpace: Specifies whether the overviews ROI footprint geometrys are in raster space or model space coordinates. (Optional property. Default is False, meaning that overviews footprints are in model space);

                                                              • overviewsSuffixFormat: Specifies the String format syntax used to define the suffix of the overviews footprints file name. (Optional property. Default is %d). To give an example, if granule file is R1C1.tif and related 1st overview footprint is stored into R1C1_1.wkt, overviewsSuffixFormat should be %d. In case 1st overview footprint is stored into R1C1-Ov1.wkt, overviewsSuffixFormat should be -Ov%d.

                                                              Same steps of previous section are required to configure an ImageMosaic layer with footprint management.

                                                              "},{"location":"tutorials/imagemosaic_timeseries/imagemosaic_time-elevationseries/","title":"Using the ImageMosaic plugin for raster with time and elevation data","text":""},{"location":"tutorials/imagemosaic_timeseries/imagemosaic_time-elevationseries/#introduction","title":"Introduction","text":"

                                                              This tutorial is the following of Using the ImageMosaic plugin for raster time-series data and explains how manage an ImageMosaic using both Time and Elevation attributes.

                                                              The dataset used is a set of raster images used in weather forecast, representing the temperature in a certain zone at different times and elevations.

                                                              All the steps explained in chapter Configurations of ImageMosaic section are still the same.

                                                              This tutorial explains just how to configure the elevationregex.properties that is an additional configuration file needed, and how to modify the indexer.properties.

                                                              The dataset used is different so also a fix to the timeregex.properties used in the previous tutorial is needed.

                                                              Will be shown also how query GeoServer asking for layers specifying both time and elevation dimensions.

                                                              The dataset used in the tutorial can be downloaded Here

                                                              "},{"location":"tutorials/imagemosaic_timeseries/imagemosaic_time-elevationseries/#configuration-examples","title":"Configuration examples","text":"

                                                              The additional configurations needed in order to handle also the elevation attributes are:

                                                              • Improve the previous version of the indexer.properties file
                                                              • Add the elevationregex.properties file in order to extract the elevation dimension from the filename
                                                              "},{"location":"tutorials/imagemosaic_timeseries/imagemosaic_time-elevationseries/#indexerproperties","title":"indexer.properties:","text":"

                                                              Here the user can specify the information that needs GeoServer for creating the table in the database.

                                                              In this case the time values are stored in the column ingestion as shown in the previous tutorial but now is mandatory specify the elevation column too.

                                                              Caching=false\nTimeAttribute=ingestion\nElevationAttribute=elevation\nSchema=*the_geom:Polygon,location:String,ingestion:java.util.Date,elevation:Double\nPropertyCollectors=TimestampFileNameExtractorSPI[timeregex](ingestion),DoubleFileNameExtractorSPI[elevationregex](elevation)\n
                                                              "},{"location":"tutorials/imagemosaic_timeseries/imagemosaic_time-elevationseries/#elevationregexproperties","title":"elevationregex.properties:","text":"

                                                              Remember that every tif file must follow this naming convention:

                                                              {coveragename}_{timestamp}_[{elevation}].tif\n

                                                              As in the timeregex property file the user must specify the pattern that the elevation in the file name looks like. In this example it consists of 4 digits, a dot '.' and other 3 digits.

                                                              an example of filename, that is used in this tutorial is:

                                                              gfs50kmTemperature20130310T180000000Z_0600.000_.tiff\n

                                                              The GeoServer ImageMosaic plugin scans the filename and search for the first occurrence that match with the pattern specified. Here the content of elevationregex.properties:

                                                              regex=(?<=_)(\\\\d{4}\\\\.\\\\d{3})(?=_)\n
                                                              "},{"location":"tutorials/imagemosaic_timeseries/imagemosaic_time-elevationseries/#timeregexproperties","title":"timeregex.properties:","text":"

                                                              As you can see the time in this dataset is specified as ISO8601 format:

                                                              20130310T180000000Z\n

                                                              Instead of the form yyyymmdd as in the previous tutorial. So the regex to specify in timeregex.properties is:

                                                              regex=[0-9]{8}T[0-9]{9}Z(\\?!.\\*[0-9]{8}T[0-9]{9}Z.\\*)\n
                                                              "},{"location":"tutorials/imagemosaic_timeseries/imagemosaic_time-elevationseries/#coverage-based-on-filestore","title":"Coverage based on filestore","text":"

                                                              Once the mosaic configuration is ready the store mosaic could be loaded on GeoServer.

                                                              The steps needed are the same shown the previous chapter. After the store is loaded and a layer published note the differences in WMS Capabilities document and in the table on postgres.

                                                              "},{"location":"tutorials/imagemosaic_timeseries/imagemosaic_time-elevationseries/#wms-capabilities-document","title":"WMS Capabilities document","text":"

                                                              The WMS Capabilities document is a bit different, now there is also the dimension elevation. In this example both time and elevation dimension are set to List .

                                                              <Dimension name=\"time\" default=\"current\" units=\"ISO8601\">\n    2013-03-10T00:00:00.000Z,2013-03-11T00:00:00.000Z,2013-03-12T00:00:00.000Z,2013-03-13T00:00:00.000Z,2013-03-14T00:00:00.000Z,2013-03-15T00:00:00.000Z,2013-03-16T00:00:00.000Z,2013-03-17T00:00:00.000Z,2013-03-18T00:00:00.000Z\n</Dimension>\n<Dimension name=\"elevation\" default=\"200.0\" units=\"EPSG:5030\" unitSymbol=\"m\">\n    200.0,300.0,500.0,600.0,700.0,850.0,925.0,1000.0\n</Dimension>\n
                                                              "},{"location":"tutorials/imagemosaic_timeseries/imagemosaic_time-elevationseries/#the-table-on-postgres","title":"The table on postgres","text":"

                                                              With the elevation support enabled the table on postgres has, for each image, the field elevation filled with the elevation value.

                                                              Note

                                                              The user must create manually the index on the table in order to speed up the search by attribute.

                                                              "},{"location":"tutorials/imagemosaic_timeseries/imagemosaic_time-elevationseries/#query-layer-on-timestamp","title":"Query layer on timestamp:","text":"

                                                              In order to display a snapshot of the map at a specific time instant and elevation you have to pass in the request those parameters.

                                                              • &time= < pattern > , as shown before,
                                                              • &elevation= < pattern > where you pass the value of the elevation.

                                                              For example if an user wants to obtain the temperature coverage images for the day 2013-03-10 at 6 PM at elevation 200 meters must append to the request:

                                                              &time=2013-03-10T00:00:00.000Z&elevation=200.0\n

                                                              Same day at elevation 300.0 meters:

                                                              &time=2013-03-10T00:00:00.000Z&elevation=300.0\n

                                                              Note that if just the time dimension is append to the request will be displayed the elevation 200 meters (if present) because of the default attribute of the tag <Dimension name=\"elevation\" ... in the WMS Capabilities document is set to 200

                                                              "},{"location":"tutorials/imagemosaic_timeseries/imagemosaic_timeseries/","title":"Using the ImageMosaic plugin for raster time-series data","text":""},{"location":"tutorials/imagemosaic_timeseries/imagemosaic_timeseries/#introduction","title":"Introduction","text":"

                                                              This step-by-step tutorial describes how to build a time-series coverage using the ImageMosaic plugin. The ImageMosaic plugin allows the creation of a time-series layer of a raster dataset. The single images are held in a queryable structure to allow access to a specific dataset with a temporal filter.

                                                              This tutorial assumes knowledge of the concepts explained in ImageMosaic section.

                                                              This tutorial contains four sections:

                                                              • The first section, Configuration, describes the configuration files needed to set up an ImageMosaic store from GeoServer.
                                                              • The second section, Configuration examples, providing examples of the configuration files needed.
                                                              • The last two sections, Coverage based on filestore and Coverage based on database describe, once the previous configurations steps are done, how to create and configure an ImageMosaic store using the GeoServer GUI.

                                                              The dataset used in the tutorial can be downloaded Here. It contains 3 image files and a .sld file representing a style needed for correctly render the images.

                                                              "},{"location":"tutorials/imagemosaic_timeseries/imagemosaic_timeseries/#configuration","title":"Configuration","text":"

                                                              To support time-series layers, GeoServer needs to be run in a web container that has the timezone properly configured. To set the time zone to be Coordinated Universal Time (UTC), add this switch when launching the java process:

                                                              -Duser.timezone=GMT\n

                                                              If using a shapefile as the mosaic index store (see next section), another java process option is needed to enable support for timestamps in shapefile stores:

                                                              -Dorg.geotools.shapefile.datetime=true\n

                                                              Note

                                                              Support for timestamp is not part of the DBF standard (used in shapefile for attributes). The DBF standard only supports Date, and only few applications understand it. As long as shapefiles are only used for GeoServer input that is not a problem, but the above setting will cause issues if you have WFS enabled and users also download shapefiles as GetFeature output: if the feature type extracted has timestamps, then the generated shapefile will have as well, making it difficult to use the generated shapefile in desktop applications. As a rule of thumb, if you also need WFS support it is advisable to use an external store (PostGIS, Oracle) instead of shapefile. Of course, if all that's needed is a date, using shapefile as an index without the above property is fine as well.

                                                              In order to load a new CoverageStore from the GeoServer GUI two steps are needed:

                                                              1. Create a new directory in which you store all the raster files (the mosaic granules) and three configuration files. This directory represents the MOSAIC_DIR.
                                                              2. Install and setup a DBMS instance, this DB is that one where the mosaic indexes will be stored.
                                                              "},{"location":"tutorials/imagemosaic_timeseries/imagemosaic_timeseries/#mosaic_dir-and-the-configuration-files","title":"MOSAIC_DIR and the Configuration Files","text":"

                                                              The user can name and place the MOSAIC_DIR as and where they want.

                                                              The MOSAIC_DIR contains all mosaic granules files and the 3 needed configuration files. The files are in .properties format.

                                                              Note

                                                              Every tif file must follow the same naming convention. In this tutorial will be used {coveragename}_{timestamp}.tif

                                                              In a properties file you specify your properties in a key-value manner: e.g. myproperty=myvalue

                                                              The configuration files needed are:

                                                              1. datastore.properties: contains all relevant information responsible for connecting to the database in which the spatial indexes of the mosaic will be stored
                                                              2. indexer.properties: specifies the name of the time-variant attribute, the elevation attribute and the type of the attributes
                                                              3. timeregex.properties: specifies the regular expression used to extract the time information from the filename.

                                                              All the configuration files must be placed in the root of the MOSAIC_DIR. The granule images could be placed also in MOSAIC_DIR subfolders.

                                                              Please note that datastore.properties isn't mandatory. The plugin provides two possibilities to access to time series data:

                                                              • Using a shapefile in order to store the granules indexes. That's the default behavior without providing the datastore.properties file.
                                                              • Using a DBMS, which maps the timestamp to the corresponding raster source. The former uses the time attribute for access to the granule from the mapping table.

                                                              For production installation is strong recommended the usage of a DBMS instead of shapefile in order to improve performances.

                                                              Otherwise the usage of a shapefile could be useful in development and test environments due to less configurations are needed.

                                                              "},{"location":"tutorials/imagemosaic_timeseries/imagemosaic_timeseries/#datastoreproperties","title":"datastore.properties","text":"

                                                              Here is shown an example of datastore.properties suitable for Postgis.

                                                              Parameter Mandatory Description

                                                              SPI Y The factory class used for the datastore e.g. org.geotools.data.postgis.PostgisNGDataStoreFactory

                                                              host Y The host name of the database.

                                                              port Y The port of the database

                                                              database Y The name/instance of the database.

                                                              schema Y The name of the database schema.

                                                              user Y The database user.

                                                              passwd Y The database password.

                                                              Loose bbox N default 'false' Boolean value to specify if loosing the bounding box.

                                                              Estimated extend N default 'true' Boolean values to specify if the extent of the data should be estimated.

                                                              validate connections N default 'true' Boolean value to specify if the connection should be validated.

                                                              Connection timeout N default '20' Specifies the timeout in minutes.

                                                              preparedStatements N default 'false' Boolean flag that specifies if for the database queries prepared statements should be used. This improves performance, because the database query parser has to parse the query only once

                                                              Note

                                                              The first 8 parameters are valid for each DBMS used, the last 4 may vary from different DBMS. for more information see :geotoolsGeoTools JDBC documentation <jdbc/index.html>.

                                                              "},{"location":"tutorials/imagemosaic_timeseries/imagemosaic_timeseries/#indexerproperties","title":"indexer.properties","text":"

                                                              Parameter Mandatory Description

                                                              TimeAttribute N Specifies the name of the time-variant attribute

                                                              ElevationAttribute N Specifies the name of the elevation attribute.

                                                              Schema Y A comma separated sequence that describes the mapping between attribute and the data type.

                                                              PropertyCollectors Y Specifies the extractor classes.

                                                              Warning

                                                              TimeAttribute is not a mandatory param but for the purpose of this tutorial is needed.

                                                              "},{"location":"tutorials/imagemosaic_timeseries/imagemosaic_timeseries/#timeregexproperties","title":"timeregex.properties","text":"

                                                              Parameter Mandatory Description

                                                              regex Y Specifies the pattern used for extracting the information from the file

                                                              After this you can create a new ImageMosaic datastore.

                                                              "},{"location":"tutorials/imagemosaic_timeseries/imagemosaic_timeseries/#install-and-setup-a-dbms-instance","title":"Install and setup a DBMS instance","text":"

                                                              First of all, note that the usage of a DBMS to store the mosaic indexes is not mandatory. If the user does not create a datastore.properties file in the MOSAIC_DIR, then the plugin will use a shapefile. The shapefile will be created in the MOSAIC_DIR.

                                                              Anyway, especially for large dataset, the usage of a DBMS is strongly recommended. The ImageMosaic plugin supports all the most used DBMS.

                                                              The configuration needed are the basics: create a new empty DB with geospatial extensions, a new schema and configure the user with W/R grants.

                                                              If the user wants to avoid to manually create the DB, it will be automatically generated by the ImageMosaic plugin taking the information defined inside the datastore.properties file.

                                                              Note

                                                              In case of automatic DB creation with PostgreSQL the user must check the PostgreSQL and PostGIS versions: if the first is lower than 9.1 and the second is lower than 2.0, the user have to add the following string of code inside the datastore.properties file :

                                                              create\\ database\\ params=WITH\\ TEMPLATE\\=template_postgis\n

                                                              (Specifying the proper PostGIS template... in this example: template_postgis).

                                                              This tutorial shows use of PostgreSQL 9.1 together with PostGIS 2.0.

                                                              "},{"location":"tutorials/imagemosaic_timeseries/imagemosaic_timeseries/#configuration-examples","title":"Configuration examples","text":"

                                                              As example is used a set of data that represents hydrological data in a certain area in South Tyrol, a region in northern Italy. The origin data was converted from asc format to TIFF using the GDAL gdal translate utility.

                                                              For this running example we will create a layer named snow.

                                                              As mentioned before the files could located in any part of the file system.

                                                              In this tutorial the chosen MOSAIC_DIR directory is called hydroalp and is placed under the root of the GEOSERVER_DATA_DIR.

                                                              "},{"location":"tutorials/imagemosaic_timeseries/imagemosaic_timeseries/#configure-the-mosaic_dir","title":"Configure the MOSAIC_DIR:","text":"

                                                              This part showsn an entire MOSAIC_DIR configuration.

                                                              "},{"location":"tutorials/imagemosaic_timeseries/imagemosaic_timeseries/#datastoreproperties_1","title":"datastore.properties:","text":"
                                                              SPI=org.geotools.data.postgis.PostgisNGDataStoreFactory\nhost=localhost\nport=5432\ndatabase=db\nschema=public\nuser=dbuser\npasswd=dbpasswd\nLoose\\ bbox=true\nEstimated\\ extends=false\nvalidate\\ connections=true\nConnection\\ timeout=10\npreparedStatements=true\n

                                                              Note

                                                              In case of a missing datastore.properties file a shape file is created to hold the indexes.

                                                              "},{"location":"tutorials/imagemosaic_timeseries/imagemosaic_timeseries/#granules-naming-convention","title":"Granules Naming Convention","text":"

                                                              Here an example of the granules naming that satisfies the rule shown before:

                                                              $ls hydroalp/snow/*.tif\n\nsnow/snow_20091001.tif\nsnow/snow_20091101.tif\nsnow/snow_20091201.tif\nsnow/snow_20100101.tif\nsnow/snow_20100201.tif\nsnow/snow_20100301.tif\nsnow/snow_20100401.tif\nsnow/snow_20100501.tif\nsnow/snow_20100601.tif\nsnow/snow_20100701.tif\nsnow/snow_20100801.tif\nsnow/snow_20100901.tif\n
                                                              "},{"location":"tutorials/imagemosaic_timeseries/imagemosaic_timeseries/#timeregexproperties_1","title":"timeregex.properties:","text":"

                                                              In the timeregex property file you specify the pattern describing the date(time) part of the file names. In this example it consists simply of 8 digits as specified below.

                                                              regex=[0-9]{8}\n
                                                              "},{"location":"tutorials/imagemosaic_timeseries/imagemosaic_timeseries/#indexerproperties_1","title":"indexer.properties:","text":"

                                                              Here the user can specify the information that GeoServer uses to create the index table in the database. In this example, the time values are stored in the column ingestion.

                                                              TimeAttribute=ingestion\nElevationAttribute=elevation\nSchema=*the_geom:Polygon,location:String,ingestion:java.util.Date,elevation:Integer\nPropertyCollectors=TimestampFileNameExtractorSPI[timeregex](ingestion)\n
                                                              "},{"location":"tutorials/imagemosaic_timeseries/imagemosaic_timeseries/#create-and-publish-an-imagemosaic-store","title":"Create and Publish an ImageMosaic store:","text":""},{"location":"tutorials/imagemosaic_timeseries/imagemosaic_timeseries/#step-1-create-new-imagemosaic-data-store","title":"Step 1: Create new ImageMosaic data store","text":"

                                                              We create a new data store of type raster data and choose ImageMosaic.

                                                              Note

                                                              Be aware that GeoServer creates a table which is identical with the name of your layer. If the table already exists, it will not be dropped from the DB and the following error message will appear. The same message will appear if the generated property file already exists in the directory or there are incorrect connection parameters in datastore.properties file.

                                                              "},{"location":"tutorials/imagemosaic_timeseries/imagemosaic_timeseries/#step-2-specify-layer","title":"Step 2: Specify layer","text":"

                                                              We specify the directory that contains the property and TIFF files (path must end with a slash) and add the layer.

                                                              "},{"location":"tutorials/imagemosaic_timeseries/imagemosaic_timeseries/#step-3-set-coverage-parameters","title":"Step 3: Set coverage parameters","text":"

                                                              The relevant parameters are AllowMultithreading and USE_JAI_IMAGEREAD. Do not forget to specify the background value according to your the value in your tif file. If you want to control which granule is displayed when a number of images match the time period specified then set the SORTING parameter to the variable name you want to use for sorting followed by a space and either D or A for descending or ascending. Descending values will mean that the latest image in a series that occurs in the time period requested is shown.

                                                              Remember that for display correctly the images contained in the provided dataset a custom style is needed.

                                                              Set as default style the snow_style.sld contained in the dataset archive.

                                                              More information about raster styling can be found in chapter Rasters

                                                              "},{"location":"tutorials/imagemosaic_timeseries/imagemosaic_timeseries/#step-4-set-temporal-properties","title":"Step 4: Set temporal properties","text":"

                                                              In the Dimensions tab you can specify how the time attributes are represented.

                                                              By enabling the Time or Elevation checkbox you can specify the how these dimensions will be presented. In this example, queries are only over the time attribute.

                                                              Below is shown a snippet of the Capabilities document for each presentation case:

                                                              Setting the presentation to List, all mosaic times are listed:

                                                              <Dimension name=\"time\" default=\"current\" units=\"ISO8601\">\n    2009-10-01T00:00:00.000Z,2009-11-01T00:00:00.000Z,2009-12-01T00:00:00.000Z,2010-01-01T00:00:00.000Z,2010-02-01T00:00:00.000Z,2010-03-01T00:00:00.000Z,2010-04-01T00:00:00.000Z,2010-05-01T00:00:00.000Z,2010-06-01T00:00:00.000Z,2010-07-01T00:00:00.000Z,2010-08-01T00:00:00.000Z,2010-09-01T00:00:00.000Z,2010-10-01T00:00:00.000Z,2010-11-01T00:00:00.000Z,2010-12-01T00:00:00.000Z,2011-01-01T00:00:00.000Z,2011-02-01T00:00:00.000Z,2011-03-01T00:00:00.000Z,2011-04-01T00:00:00.000Z,2011-05-01T00:00:00.000Z,2011-06-01T00:00:00.000Z,2011-07-01T00:00:00.000Z,2011-08-01T00:00:00.000Z,2011-09-01T00:00:00.000Z\n</Dimension>\n

                                                              Setting the presentation to Continuous interval only the start, end and interval extent times are listed:

                                                              <Dimension name=\"time\" default=\"current\" units=\"ISO8601\">\n    2009-10-01T00:00:00.000Z/2011-09-01T00:00:00.000Z/P1Y11MT10H\n</Dimension>\n

                                                              Setting the presentation to Interval and resolutions gives to user the possibility to specify the resolutions of the interval:

                                                              <Dimension name=\"time\" default=\"current\" units=\"ISO8601\">\n    2009-10-01T00:00:00.000Z/2011-09-01T00:00:00.000Z/P1DT12H\n</Dimension>\n

                                                              In this case the resolution is set to 1.5 days.

                                                              Note

                                                              To visualize the GetCapabilities document, go to the GeoServer homepage, and click on the WMS 1.3.0 link under the tab labeled Service Capabilities.

                                                              For this tutorial the Presentation attribute is set to List

                                                              After this steps the new layer is available in GeoServer. GeoServer will create a property file in the source directory. GeoServer will either create a shapefile for the mosaic indexes, or will create a table on the database (named the same as the layer name) for the index.

                                                              "},{"location":"tutorials/imagemosaic_timeseries/imagemosaic_timeseries/#generated-property-file","title":"Generated property file:","text":"
                                                              #-Automagically created from GeoTools-\n#Sat Oct 13 10:47:08 CEST 2012\nLevels=100.0,100.0\nHeterogeneous=false\nElevationAttribute=elevation\nTimeAttribute=ingestion\nAbsolutePath=false\nName=snow\nCaching=false\nExpandToRGB=false\nLocationAttribute=location\nSuggestedSPI=it.geosolutions.imageioimpl.plugins.tiff.TIFFImageReaderSpi\nLevelsNum=1\n

                                                              Note

                                                              The parameter Caching=false is important to allow the user is to update manually the mosaic, by adding to and removing granules from MOSAIC_DIR and updating the appropriate database entry.

                                                              "},{"location":"tutorials/imagemosaic_timeseries/imagemosaic_timeseries/#generated-table","title":"Generated table:","text":"

                                                              Note

                                                              The user must create manually the index on the table in order to speed up the search by attribute.

                                                              "},{"location":"tutorials/imagemosaic_timeseries/imagemosaic_timeseries/#step-5-query-layer-on-timestamp","title":"Step 5: query layer on timestamp:","text":"

                                                              In order to display a snapshot of the map at a specific time instant you have to pass in the request an additional time parameter with a specific notation &time= < pattern > where you pass a value that corresponds to them in the filestore. The only thing is the pattern of the time value is slightly different.

                                                              For example if an user wants to obtain the snow coverage images from the months Oct,Nov,Dec 2009, pass in each request &time=2009-10-01, &time=2009-11-01 and &time=2009-12-01. You can recognize in the three images how the snow coverage changes. Here the color blue means a lot of snow.

                                                              "},{"location":"tutorials/imagemosaic_timeseries/imagemosaic_timeseries/#create-and-publish-a-layer-from-mosaic-indexes","title":"Create and publish a Layer from mosaic indexes:","text":"

                                                              After the previous steps it is also possible to create a layer that represents the spatial indexes of the mosaic. This is an useful feature when handling a large dataset of mosaics with high resolutions granules, since the user can easily get the footprints of the images. In this case will be rendered only the geometries stored on the indexes tables.

                                                              "},{"location":"tutorials/imagemosaic_timeseries/imagemosaic_timeseries/#step-1-add-a-postgis-datastore","title":"Step 1: add a postgis datastore:","text":"

                                                              and specify the connection parameters

                                                              "},{"location":"tutorials/imagemosaic_timeseries/imagemosaic_timeseries/#step-2-add-database-layer","title":"Step 2: add database layer:","text":"

                                                              Choose from the created datastore the table that you want to publish as a layer.

                                                              "},{"location":"tutorials/imagemosaic_timeseries/imagemosaic_timeseries/#step-3-specify-dimension","title":"Step 3: specify dimension:","text":"

                                                              In the tab Dimension specify the time-variant attribute and the form of presentation.

                                                              That's it. Now is possible query this layer too.

                                                              "},{"location":"tutorials/imagepyramid/imagepyramid/","title":"Building and using an image pyramid","text":"

                                                              GeoServer can efficiently deal with large TIFF with overviews, as long as the TIFF is below the 2GB size limit.

                                                              Once the image size goes beyond such limit it's time to start considering an image pyramid instead.

                                                              An image pyramid builds multiple mosaics of images, each one at a different zoom level, making it so that each tile is stored in a separate file. This comes with a composition overhead to bring back the tiles into a single image, but can speed up image handling as each overview is tiled, and thus a sub-set of it can be accessed efficiently (as opposed to a single GeoTIFF, where the base level can be tiled, but the overviews never are).

                                                              This tutorial shows how to build an image pyramid with open source utilities and how to load it into GeoServer. The tutorial assumes you're running at least GeoServer 2.0.2.

                                                              "},{"location":"tutorials/imagepyramid/imagepyramid/#building-a-pyramid","title":"Building a pyramid","text":"

                                                              For this tutorial we have prepared a sample BlueMarble TNG subset in GeoTIFF form. The image is tiled and JPEG compressed, without overviews. Not exactly what you'd want to use for high performance data serving, but good for redistribution and as a starting point to build a pyramid.

                                                              In order to build the pyramid we'll use the gdal_retile.py utility, part of the GDAL command line utilities and available for various operating systems (if you're using Microsoft Windows look for FWTools).

                                                              The following commands will build a pyramid on disk:

                                                              mkdir bmpyramid\ngdal_retile.py -v -r bilinear -levels 4 -ps 2048 2048 -co \"TILED=YES\" -co \"COMPRESS=JPEG\" -targetDir bmpyramid bmreduced.tiff\n

                                                              The gdal_retile.py user guide provides a detailed explanation for all the possible parameters, here is a description of the ones used in the command line above:

                                                              • -v: verbose output, allows the user to see each file creation scroll by, thus knowing progress is being made (a big pyramid construction can take hours)
                                                              • -r bilinear: use bilinear interpolation when building the lower resolution levels. This is key to get good image quality without asking GeoServer to perform expensive interpolations in memory
                                                              • -levels 4: the number of levels in the pyramid
                                                              • -ps 2048 2048: each tile in the pyramid will be a 2048x2048 GeoTIFF
                                                              • -co \"TILED=YES\": each GeoTIFF tile in the pyramid will be inner tiled
                                                              • -co \"COMPRESS=JPEG\": each GeoTIFF tile in the pyramid will be JPEG compressed (trades small size for higher performance, try out it without this parameter too)
                                                              • -targetDir bmpyramid: build the pyramid in the bmpyramid directory. The target directory must exist and be empty
                                                              • bmreduced.tiff: the source file

                                                              This will produce a number of TIFF files in bmpyramid along with the sub-directories 1, 2, 3, and 4.

                                                              Once that is done, and assuming the GeoServer image pyramid plug-in is already installed, it's possible to create the coverage store by pointing at the directory containing the pyramid and clicking save:

                                                              Configuring a image pyramid store

                                                              When clicking save the store will look into the directory, recognize a gdal_retile generated structure and perform some background operations:

                                                              • move all tiff files in the root to a newly create directory 0
                                                              • create an image mosaic in all sub-directories (shapefile index plus property file)
                                                              • create the root property file describing the whole pyramid structure

                                                              Once that is done the user will be asked to choose a coverage, which will be named after the pyramid root directory:

                                                              Choosing the coverage for publishing

                                                              Publish the layer, and then setup the layer parameter USE_JAI_IMAGEREAD to false to get better scalability:

                                                              Tuning the pyramid parameters

                                                              Submit and go to the preview, the pyramid should be ready to use:

                                                              Previewing the pyramid

                                                              "},{"location":"tutorials/imagepyramid/imagepyramid/#notes-on-big-pyramids","title":"Notes on big pyramids","text":"

                                                              The code that is auto-creating the pyramid indexes and metadata files might take time to run, especially if:

                                                              • the pyramid zero level is composed of many thousands of files
                                                              • the system is busy with the disk already and that results in higher times to move all the files to the 0 directory

                                                              If the delay is too high the request to create the store will time out and might break the pyramid creation. So, in case of very big pyramids consider loosing some of the comfort and creating the 0 directory and moving the files by hand:

                                                              cd bmpyramid\nmkdir 0\nmv *.tiff 0\n
                                                              "},{"location":"tutorials/jboss/jboss_tutorial/","title":"geoserver on JBoss","text":"

                                                              This tutorial documents how to install various versions of geoserver onto various versions of JBoss.

                                                              "},{"location":"tutorials/jboss/jboss_tutorial/#geoserver-270-on-jboss-as-51","title":"geoserver 2.7.0 on JBoss AS 5.1","text":"

                                                              To install geoserver onto JBoss AS 5.1, the following is required:

                                                              1. Create the file jboss-classloading.xml with the following content then copy it into the WEB-INF directory in the geoserver.war:
                                                              <classloading xmlns=\"urn:jboss:classloading:1.0\"\n    name=\"geoserver.war\"\n    domain=\"GeoServerDomain\">\n</classloading>\n
                                                              1. Extract the hsqldb-2.2.8.jar file from the WEB-INF/lib directory from the geoserver.war and copy it as hsqldb.jar to the common/lib directory in the JBoss deployment.
                                                              2. Add the following text to the WEB-INF/web.xml file in the geoserver.war so that JBoss logging does not end up in the geoserver.log:
                                                              <context-param>\n    <param-name>RELINQUISH_LOG4J_CONTROL</param-name>\n    <param-value>true</param-value>\n</context-param>    \n
                                                              "},{"location":"tutorials/metadata/","title":"INSPIRE metadata configuration using metadata and CSW","text":"

                                                              The INSPIRE directive requires exposure of fairly complex metadata schemes based on the ISO Metadata Profile. This exposure is supported by the built-in Catalog Services for the Web (CSW) service (can be harvested by GeoNetwork), while the Metadata community module allows adding any amount of customized metadata fields to layers that may be required for your particular case.

                                                              Creating all the needed configuration files in both modules can be a tedious task. Therefore we have added this example configuration.

                                                              "},{"location":"tutorials/metadata/#metadata-configuration","title":"Metadata configuration","text":"

                                                              Place the following files in the metadata folder:

                                                              UI configuration metadata-ui.yaml

                                                              Translate keys to labels metadata.properties

                                                              Translate keys to Dutch labels metadata_nl.properties

                                                              Content for gemet-concept dropdown keyword-gemet-concept.csv

                                                              Content for reference-system requirebox keyword-gemet-concept.csv

                                                              Content for inspire-theme-label & inspire-theme-ref keyword-inspire-theme.csv

                                                              Geonetwork mapping metadata-mapping.yaml

                                                              Namespaces for geonetwork mapping metadata-mapping.yaml

                                                              Geonetwork endpoints metadata-geonetwork.yaml

                                                              Synchronize native fields metadata-native-mapping.yaml

                                                              Open any layer: navigate to Layers \u2192 Choose the layer \u2192 Metadata tab.

                                                              The metadata fields are available in the panel Metadata fields.

                                                              You may now add custom metadata to your layers.

                                                              "},{"location":"tutorials/metadata/#csw-configuration","title":"CSW configuration","text":"

                                                              Map metadata attributes to xml MD_Metadata.properties

                                                              Map Feature Catalogue attributes to xml FC_FeatureCatalogue.properties

                                                              Map Record attributes to xml Record.properties

                                                              You may now see your custom metadata exposed by the built-in CSW service:

                                                              e.g. https://my.host/geoserver/csw?service=CSW&version=2.0.2&request=GetRecords&typeNames=gmd:MD_Metadata&resultType=results&elementSetName=full&outputSchema=http://www.isotc211.org/2005/gmd.

                                                              "},{"location":"tutorials/metadata/#geonetwork-configuration","title":"GeoNetwork configuration","text":"

                                                              Create a GeoNetwork CSW harvester that points to your to Geoserver's CSW endpoint:

                                                              e.g. https://my.host/geoserver/csw?Service=CSW&Request=Getcapabilities.

                                                              You may now start harvesting!

                                                              "},{"location":"tutorials/palettedimage/palettedimage/","title":"Paletted Images","text":"

                                                              GeoServer has the ability to output high quality 256 color images. This tutorial introduces you to the palette concepts, the various image generation options, and offers a quality/resource comparison of them in different situations.

                                                              "},{"location":"tutorials/palettedimage/palettedimage/#what-are-paletted-images","title":"What are Paletted Images?","text":"

                                                              Some image formats, such as GIF or PNG, can use a palette, which is a table of (usually) 256 colors to allow for better compression. Basically, instead of representing each pixel with its full color triplet, which takes 24bits (plus eventual 8 more for transparency), they use a 8 bit index that represent the position inside the palette, and thus the color.

                                                              This allows for images that are 3-4 times smaller than the standard images, with the limitation that only 256 different colors can appear on the image itself. Depending of the actual map, this may be a very stringent limitation, visibly degrading the image quality, or it may be that the output cannot be differentiated from a full color image. For many maps, one can easily find 256 representative colors.

                                                              In the latter case, the smaller footprint of paletted images is usually a big gain in both performance and costs, because more data can be served with the same internet connection, and the clients will obtain responses faster.

                                                              "},{"location":"tutorials/palettedimage/palettedimage/#formats-and-antialiasing","title":"Formats and Antialiasing","text":"

                                                              Internet standards offer a variety of image formats, all having different strong and weak points. The three most common formats are:

                                                              • JPEG: a lossy format with tunable compression. JPEG is best suited for imagery layers, where the pixel color varies continuously from one pixel to the next one, and allows for the best compressed outputs. On the contrary, it's not suited to most vector layers, because even slight compression generates visible artifacts on uniform color areas.
                                                              • PNG: a non lossy format allowing for both full color and paletted. In full color images each pixel is encoded as a 24bits integer with full transparency information (so PNG images can be translucent), in paletted mode each pixel is an 8 bit index into a 256 color table (the palette). This format is best suited to vector layers, especially in the paletted version. The full color version is sometimes referred as PNG24, the paletted version as PNG8.
                                                              • GIF: a non lossy format with a 256 color palette, best suited for vector layers. Does not support translucency, but allows for fully transparent pixels.

                                                              So, as it turns out, paletted images can be used with profit on vector data sets, either using the PNG8 or GIF formats.

                                                              Antialiasing plays a role too. Let's take a road layer, where each road is depicted by a solid gray line, 2 pixels thick. One may think this layer needs only 2 colors: the background one (eventually transparent) and gray. In fact, this is true only if no antialiasing is enabled. Antialiasing will smooth the borders of the line giving a softer, better looking shape, and it will do so by adding pixels with an intermediate color, thus increasing the number of colors that are needed to fully display the image.

                                                              The following zoom of an image shows antialiasing in action:

                                                              Antialiasing

                                                              These output formats, if no other parameters are provided, do compute the optimal palette on the fly. As you'll see, this is an expensive process (CPU bound), but as you'll see, depending on the speed of the network connecting the server and the client, the extra cost can be ignored (especially if the bottleneck can be found in the network instead of the server CPU).

                                                              Optimal palette computation is anyways a repetitive work that can be done up front: a user can compute the optimal palette once, and tell GeoServer to use it. There are three ways to do so:

                                                              1. Use the internet safe palette, a standard palette built in into GeoServer, by appending palette=safe to the GetMap request.

                                                              2. Provide a palette by example. In this case, the user will generate an 256 color images using an external program (such as Photoshop), and then will save it into the $GEOSERVER_DATA_DIR/palettes directory. The sample file can be either in GIF or PNG format. If the file is named mypalette.gif or mypalette.png, the user will be able to refer it appending palette=mypalette to the GetMap request. GeoServer will load the palette from the file and use it.

                                                              3. Provide a palette file. The palette file must be in JASC-PAL format, and have a .pal extension. This file type can be generated by applications such as Paint Shop Pro and IrfanView, but also can be generated manually in a text editor. The process is just as before, but this time only the palette file will be stored into $GEOSERVER_DATA_DIR/palettes.

                                                                Note

                                                                GeoServer does not support palette files in Microsoft Palette format, despite having the same .pal file extension.

                                                              "},{"location":"tutorials/palettedimage/palettedimage/#an-example-with-vector-data","title":"An Example with Vector Data","text":"

                                                              Enough theory, let's have a look at how to deal with paletted images in practice. We'll use the tiger-ny basemap to gather some numbers, and in particular the following map request:

                                                              http://localhost:8080/geoserver/wms?SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&LAYERS=tiger-ny&BBOX=-74.022019,40.701196,-73.992366,40.720964&HEIGHT=400&WIDTH=600&FORMAT=image/png

                                                              And we'll change various parameters in order to play with formats and palettes. Here goes the sampler:

                                                              Parameters:FORMAT=image/png | Size: 257 KB | Map generation time: 0.3s

                                                              The standard PNG full color output

                                                              Parameters:FORMAT=image/png8 | Size: 60 KB | Map generation time: 0.6s

                                                              The PNG8 output

                                                              Parameters:FORMAT=image/png | Size: 257 KB | Map generation time: 0.3s

                                                              PNG + internet safe palette

                                                              Parameters:FORMAT=image/png & palette=nyp | Size: 56KB | Map generation time: 0.3s

                                                              PNG + custom palette <http://geoserver.org/download/attachments/1278244/nyp.pal?version=1>_

                                                              The attachments include also the GIF outputs, whose size, appearance and generation time does not differ significantly from the PNG outputs.

                                                              As we can see, depending on the choice we have a variation on the image quality, size and generation time (which has been recorded using the FasterFox Firefox extension timer, with the browser sitting on the same box as the server). Using palette=xxx provides the best match in speed and size, though using the built-in internet safe palette altered the colors. Then again, the real gain can be seen only by assuming a certain connection speed between the server and the client, and adding the time required to move the image to the client. The following table provides some results:

                                                              Configuration GT(s) File size (kb) TT 256kbit/s TT 1MBit/s TT 4MBit/s TT 20MBit/s

                                                              tiger-ny-png 0,36 257 8,39 2,42 0,87 0,46

                                                              tyger-ny-png8 0,6 60 2,48 1,08 0,72 0,62

                                                              tiger-ny-png + safe palette 0,3 56 22,05 0,75 0,41 0,32

                                                              tiger-ny-png + custom palette 0,3 59 2,14 0,77 0,42 0,32

                                                              Legend:

                                                              • GT: map generation time on the same box
                                                              • TT <speed>: total time needed for a client to show the image, assuming an internet connection of the given speed. This time is a sum of the image generation time and the transfer time, that is, GT + sizeInKbytes * 8/ speedInKbits.

                                                              As the table shows, the full color PNG image takes usually a lot more time than other formats, unless it's being served over a fast network (and even in this case, one should consider network congestion as well). The png8 output format proves to be a good choice if the connection is slow, whilst the extra work done in looking up an optimal palette always pays back in faster map delivery.

                                                              "},{"location":"tutorials/palettedimage/palettedimage/#generating-the-custom-palette","title":"Generating the custom palette","text":"

                                                              The nyp.pal file has been generated using IrfanView, on Windows:

                                                              • open the png 24 bit version of the image
                                                              • use Image/Decrease Color Depth and set 256 colors
                                                              • use Image/Palette/Export to save the palette
                                                              "},{"location":"tutorials/palettedimage/palettedimage/#an-example-with-raster-data","title":"An example with raster data","text":"

                                                              To give you an example when paletted images may not fit the bill, let's consider the sf:dem coverage from the sample data, and repeat the same operation as before.

                                                              Parameters:FORMAT=image/png Size: 117 KB | Map generation time: 0.2s

                                                              The standard PNG full color output.

                                                              Parameters:FORMAT=image/jpeg Size: 23KB | Map generation time: 0.12s

                                                              JPEG output

                                                              Parameters:FORMAT=image/png8 Size: 60 KB | Map generation time: 0.5s

                                                              The PNG8 output.

                                                              Parameters:FORMAT=image/png & palette=dem-png8 Size: 48KB | Map generation time: 0.15s

                                                              PNG + custom palette (using the png8 output as the palette).

                                                              Parameters:FORMAT=image/png & palette=safe Size: 17KB | Map generation time: 0.15s

                                                              PNG + internet safe palette.

                                                              As the sample shows, the JPEG output has the same quality as the full color image, is generated faster and uses only \u2155 of its size. On the other hand, the version using the internet safe palette is fast and small, but the output is totally ruined. Everything considered, JPEG is the clear winner, sporting good quality, fast image generation and a size that's half of the best png output we can get.

                                                              "},{"location":"tutorials/tomcat-jndi/tomcat-jndi/","title":"Setting up a JNDI connection pool with Tomcat","text":"

                                                              This tutorial walks the reader through the procedures necessary to setup a Oracle JNDI connection pool in Tomcat 6 and how to retrieve it from GeoServer. In the last section other two examples of configuration are described with PostGIS and SQLServer.

                                                              "},{"location":"tutorials/tomcat-jndi/tomcat-jndi/#tomcat-setup","title":"Tomcat setup","text":"

                                                              In order to setup a connection pool Tomcat needs a JDBC driver and the necessary pool configurations.

                                                              First off, you need to find the JDBC driver for your database. Most often it is distributed on the website of your DBMS provider, or available in the installed version of your database. For example, a Oracle XE install on a Linux system provides the driver at /usr/lib/oracle/xe/app/oracle/product/10.2.0/server/jdbc/lib/ojdbc14.jar, and that file needs to be moved into Tomcat shared libs directory, {TOMCAT_HOME}/lib

                                                              Note

                                                              be careful to remove the jdbc driver from the GeoServer WEB-INF/lib folder when copied to the Tomcat shared libs, to avoid issues in JNDI DataStores usage.

                                                              Once that is done, the Tomcat configuration file {TOMCAT_HOME}/conf/context.xml needs to be edited in order to setup the connection pool. In the case of a local Oracle XE the setup might look like:

                                                              <Context>\n   ...\n   <Resource name=\"jdbc/oralocal\"\n      auth=\"Container\"\n      type=\"javax.sql.DataSource\"\n      driverClassName=\"oracle.jdbc.driver.OracleDriver\"\n      url=\"jdbc:oracle:thin:@localhost:1521:xe\"\n      username=\"xxxxx\" password=\"xxxxxx\"\n      maxTotal=\"20\"\n      initialSize=\"0\"\n      minIdle=\"0\"\n      maxIdle=\"8\"\n      maxWait=\"10000\"\n      timeBetweenEvictionRunsMillis=\"30000\"\n      minEvictableIdleTimeMillis=\"60000\"\n      testWhileIdle=\"true\"\n      poolPreparedStatements=\"true\"\n      maxOpenPreparedStatements=\"100\"\n      validationQuery=\"SELECT SYSDATE FROM DUAL\"\n      maxAge=\"600000\"\n      rollbackOnReturn=\"true\"\n      />\n </Context>\n

                                                              Note

                                                              The above configuration is valid for Tomcat 8+, while Tomcat 7.x would use maxActive in place of maxTotal.

                                                              The example sets up a connection pool connecting to the local Oracle XE instance. The pool configuration shows is quite full-fledged:

                                                              • at most 20 active connections (max number of connection that will ever be used in parallel)
                                                              • at most 3 connections kept in the pool unused
                                                              • prepared statement pooling (very important for good performance)
                                                              • at most 100 prepared statements in the pool
                                                              • a validation query that double checks the connection is still alive before actually using it (this is not necessary if there is guarantee the connections will never drop, either due to the server forcefully closing them, or to network/maintenance issues).

                                                              Warning

                                                              Modify following settings only if you really know what you are doing. Using too low values for removedAbandonedTimeout and minEvictableIdleTimeMillis may result in connection failures, if so try to setup logAbandoned to true and check your catalina.out log file.

                                                              Other parameters to setup connection pool:

                                                              • timeBetweenEvictionRunsMillis (default -1) The number of milliseconds to sleep between runs of the idle object evictor thread. When non-positive, no idle object evictor thread will be run.
                                                              • numTestsPerEvictionRun (default 3) The number of objects to examine during each run of the idle object evictor thread (if any).
                                                              • minEvictableIdleTimeMillis (default 1000 * 60 * 30) The minimum amount of time an object may sit idle in the pool before it is eligible for eviction by the idle object evictor (if any).
                                                              • removeAbandoned (default false) Flag to remove abandoned connections if they exceed the removeAbandonedTimout. If set to true a connection is considered abandoned and eligible for removal if it has been idle longer than the removeAbandonedTimeout. Setting this to true can recover db connections from poorly written applications which fail to close a connection.
                                                              • removeAbandonedTimeout (default 300) Timeout in seconds before an abandoned connection can be removed.
                                                              • logAbandoned (default false) Flag to log stack traces for application code which abandoned a Statement or Connection.

                                                              For more information about the possible parameters and their values refer to the DBCP documentation.

                                                              "},{"location":"tutorials/tomcat-jndi/tomcat-jndi/#geoserver-setup","title":"GeoServer setup","text":"

                                                              Login into the GeoServer web administration interface and configure the datastore.

                                                              First, choose the Oracle (JNDI) datastore and give it a name:

                                                              Choosing a JNDI enabled datastore

                                                              Then, configure the connection parameters so that the JNDI path matches the one specified in the Tomcat configuration:

                                                              Configuring the JNDI connection

                                                              When you are doing this, make sure the schema is properly setup, or the datastore will list all the tables it can find in the schema it can access. In the case of Oracle the schema is usually the user name, upper cased.

                                                              Once the datastore is accepted the GeoServer usage proceeds as normal.

                                                              "},{"location":"tutorials/tomcat-jndi/tomcat-jndi/#other-examples","title":"Other examples","text":""},{"location":"tutorials/tomcat-jndi/tomcat-jndi/#configuring-a-postgresql-connection-pool","title":"Configuring a PostgreSQL connection pool","text":"

                                                              In this example a PostgreSQL connection pool will be configured.

                                                              For configuring the JNDI pool you need to move the Postgres JDBC driver (it should be named postgresql-XX.X.X.jar) from the GeoServer WEB-INF/lib folder and put it into the {TOMCAT_HOME}/lib folder.

                                                              Then the following code must be added to the Tomcat configuration file {TOMCAT_HOME}/conf/context.xml inside a Context tag.

                                                              <Context>\n    <Resource name=\"jdbc/postgres\"\n      auth=\"Container\"\n      type=\"javax.sql.DataSource\"\n      driverClassName=\"org.postgresql.Driver\"\n      url=\"jdbc:postgresql://localhost:5432/test\"\n      username=\"xxxxx\" password=\"xxxxxx\"\n      maxTotal=\"20\"\n      initialSize=\"0\"\n      minIdle=\"0\"\n      maxIdle=\"8\"\n      maxWait=\"10000\"\n      timeBetweenEvictionRunsMillis=\"30000\"\n      minEvictableIdleTimeMillis=\"60000\"\n      testWhileIdle=\"true\"\n      validationQuery=\"SELECT 1\"\n      maxAge=\"600000\"\n      rollbackOnReturn=\"true\"\n    />\n</Context>\n
                                                              "},{"location":"tutorials/tomcat-jndi/tomcat-jndi/#geoserver-setup_1","title":"GeoServer setup","text":"

                                                              Login into the GeoServer web administration interface.

                                                              First, choose the PostGIS (JNDI) datastore and give it a name:

                                                              Then configure the associated parameters. The value for jndiReferenceName corresponds to the Resource name given in {TOMCAT_HOME}/conf/context.xml.

                                                              "},{"location":"tutorials/tomcat-jndi/tomcat-jndi/#configuring-a-sqlserver-connection-pool","title":"Configuring a SQLServer connection pool","text":"

                                                              For configuring the connection pool for SQLServer you need to configure the SQLServer drivers as explained in the Microsoft SQL Server section and put the jar file into the {TOMCAT_HOME}/lib folder.

                                                              Then the following code must be written in the Tomcat configuration file {TOMCAT_HOME}/conf/context.xml

                                                              <Context>\n   ...\n      <Resource name=\"jdbc/sqlserver\"\n      auth=\"Container\"\n      type=\"javax.sql.DataSource\"\n      driverClassName=\"com.microsoft.sqlserver.jdbc.SQLServerDriver\"\n      url=\"jdbc:sqlserver://localhost:1433;databaseName=test;user=admin;password=admin;\"\n      username=\"admin\" password=\"admin\"\n      maxTotal=\"20\"\n      initialSize=\"0\"\n      minIdle=\"0\"\n      maxIdle=\"8\"\n      maxWait=\"10000\"\n      timeBetweenEvictionRunsMillis=\"30000\"\n      minEvictableIdleTimeMillis=\"60000\"\n      testWhileIdle=\"true\"\n      poolPreparedStatements=\"true\"\n      maxOpenPreparedStatements=\"100\"\n      validationQuery=\"SELECT 1\"\n      maxAge=\"600000\"\n      rollbackOnReturn=\"true\"\n      />\n</Context>\n

                                                              Note

                                                              Note that database name, username and password must be defined directly in the URL.

                                                              "},{"location":"tutorials/tomcat-jndi/tomcat-jndi/#geoserver-setup_2","title":"GeoServer setup","text":"

                                                              Login into the GeoServer web administration interface.

                                                              First, choose the Microsoft SQL Server (JNDI) datastore and give it a name:

                                                              Then configure the associated params:

                                                              "},{"location":"webadmin/","title":"Web administration interface","text":"

                                                              The Web administration interface is a web-based tool for configuring all aspects of GeoServer, from adding data to changing service settings. In a default GeoServer installation, this interface is accessed via a web browser at http://localhost:8080/geoserver/web. However, this URL may vary depending on your local installation.

                                                              Web admin interface

                                                              The following sections detail the menu options available in GeoServer. Unless otherwise specified, you will need to be logged in with administrative credentials to see the complete list of pages.

                                                              "},{"location":"webadmin/#welcome","title":"Welcome","text":"
                                                              • The Welcome page lists the web services published by GeoServer.

                                                                When logged in with administrative credentials a configuration overview is provided, along with any information or warning notifications.

                                                              "},{"location":"webadmin/#about-status","title":"About & Status","text":"

                                                              The About & Status section provides access to GeoServer diagnostic and configuration tools, and can be particularly useful for debugging.

                                                              • The Status page shows a summary of server configuration parameters and run-time status.

                                                              • The GeoServer Logs page shows the GeoServer log output. This is useful for determining errors without having to leave the browser.

                                                              • The Contact Information page sets the public contact information available in the Capabilities document of the WMS server.

                                                              • The About GeoServer Page section provides links to the GeoServer documentation, homepage and bug tracker.

                                                                You do not need to be logged into GeoServer to access this page.

                                                              "},{"location":"webadmin/#data","title":"Data","text":"

                                                              The Data management section contains configuration options for all the different data-related settings.

                                                              • The Layer Preview page provides links to layer previews in various output formats, including the common OpenLayers and KML formats. This page helps to visually verify and explore the configuration of a particular layer.

                                                                You do not need to be logged into GeoServer to access the Layer Preview.

                                                              • The Workspaces page displays a list of workspaces, with the ability to add, edit, and delete. Also shows which workspace is the default for the server.

                                                              • The Stores page displays a list of stores, with the ability to add, edit, and delete. Details include the workspace associated with the store, the type of store (data format), and whether the store is enabled.

                                                              • The Layers page displays a list of layers, with the ability to add, edit, and delete. Details include the workspace and store associated with the layer, whether the layer is enabled, and the spatial reference system (SRS) of the layer.

                                                              • The Layer Groups page displays a list of layer groups, with the ability to add, edit, and delete. Details include the associated workspace (if any).

                                                              • The Styles page displays a list of styles, with the ability to add, edit, and delete. Details include the associated workspace (if any).

                                                              In each of these pages that contain a table, there are three different ways to locate an object: sorting, searching, and paging. To alphabetically sort a data type, click on the column header. For simple searching, enter the search criteria in the search box and hit Enter. And to page through the entries (25 at a time), use the arrow buttons located on the bottom and top of the table.

                                                              These pages are shown to administrators, and users that have data admin permissions.

                                                              "},{"location":"webadmin/#services","title":"Services","text":"

                                                              The Services section is for configuring the services published by GeoServer.

                                                              • The Web Coverage Service (WCS) page manages metadata, resource limits, and SRS availability for WCS.
                                                              • The Web Feature Service (WFS) page manages metadata, feature publishing, service level options, and data-specific output for WFS.
                                                              • The Web Map Service (WMS) page manages metadata, resource limits, SRS availability, and other data-specific output for WMS.
                                                              • The Web Processing Service (WPS) page manages metadata and resource limits for WPS.
                                                              "},{"location":"webadmin/#settings","title":"Settings","text":"

                                                              The Settings section contains configuration settings that apply to the entire server.

                                                              • The Global Settings page configures messaging, logging, character and proxy settings for the entire server.
                                                              • The Image Processing page configures several JAI parameters, used by both WMS and WCS operations.
                                                              • The Coverage Access page configures settings related to loading and publishing coverages.
                                                              "},{"location":"webadmin/#tile-caching","title":"Tile Caching","text":"

                                                              The Tile Caching section configures the embedded GeoWebCache.

                                                              • The Tile Layers page shows which layers in GeoServer are also available as tiled (cached)layers, with the ability to add, edit, and delete.
                                                              • The Caching Defaults page sets the global options for the caching service.
                                                              • The Gridsets page shows all available gridsets for the tile caches, with the ability to add, edit, and delete.
                                                              • The Disk Quota page sets the options for tile cache management on disk, including strategies to reduce file size when necessary.
                                                              • The BlobStores pages manages the different blobstores (tile cache sources) known to the embedded GeoWebCache.
                                                              "},{"location":"webadmin/#security","title":"Security","text":"

                                                              The Security section configures the built-in security subsystem.

                                                              • The Settings page manages high-level options for the security subsystem.
                                                              • The Authentication page manages authentication filters, filter chains, and providers.
                                                              • The Passwords page manages the password policies for users and the root account.
                                                              • The Users, Groups, Roles page manages the users, groups, and roles, and how they are all associated with each other. Passwords for user accounts can be changed here.
                                                              • The Data page manages the data-level security options, allowing workspaces and layers to be restricted by role.
                                                              • The Services page manages the service-level security options, allowing services and operations to be restricted by role.
                                                              "},{"location":"webadmin/#demos","title":"Demos","text":"

                                                              The Demos section contains links to example WMS, WCS, and WFS requests for GeoServer as well as a listing all SRS info known to GeoServer. In addition, there is a reprojection console for converting coordinates between spatial reference systems, and a request builder for WCS requests.

                                                              You do not need to be logged into GeoServer to access these pages.

                                                              "},{"location":"webadmin/#tools","title":"Tools","text":"

                                                              The Tools section contains administrative tools.

                                                              • The Web Resource tool provides management of data directory icons, fonts, and configuration files.
                                                              • The Catalog Bulk Load Tool can bulk copy configuration for testing
                                                              "},{"location":"webadmin/#extensions","title":"Extensions","text":"

                                                              GeoServer extensions can add functionality and extra options to the web interface. Details can be found in the section for each extension.

                                                              "},{"location":"webadmin/#user-interface","title":"User interface","text":""},{"location":"webadmin/#navigation","title":"Navigation","text":"

                                                              A navigation menu is provided along the left-hand-side of the screen listing configuration pages.

                                                              To return to the main Welcome click on the GeoServer logo at the top of the navigation menu.

                                                              "},{"location":"webadmin/#user-login","title":"User login","text":"

                                                              The upper right of the web administration interface provides options to login.

                                                              GeoServer will share only the web services and layers available to the current user.

                                                              "},{"location":"webadmin/#choosing-the-ui-language","title":"Choosing the UI language","text":"

                                                              The administration interface is displayed using the browser's preferred language when available, otherwise it will fall back to English. The drop-down chooser on the side of the login/logout button allows selection of a different language.

                                                              The language choice is saved in the session, as well as in a cookie, to retain the language choice across user sessions.

                                                              "},{"location":"webadmin/about/","title":"About GeoServer Page","text":"

                                                              The About Page provides information about GeoServer along with useful documentation links.

                                                              About GeoServer Page

                                                              "},{"location":"webadmin/welcome/","title":"Welcome","text":"

                                                              The Welcome Page lists the web services published by GeoServer for mapping, data access and processing.

                                                              "},{"location":"webadmin/welcome/#welcome_webservices","title":"Web Services","text":"

                                                              The welcome page lists the global web services (accessing the complete list of layers).

                                                              Welcome Page Global Services

                                                              To use copy-and-paste the web services URLs into your Desktop GIS or web mapping application.

                                                              QGIS Desktop GIS WMS Connection

                                                              QGIS Desktop GIS Add WMS Layer

                                                              QGIS Desktop GIS Map

                                                              Opening these URLs in the browser download or display machine readable the service description.

                                                              WMS 1.3.0 GetCapabilities Document

                                                              If global web services are disabled the initial welcome page web services will not be available.

                                                              "},{"location":"webadmin/welcome/#workspace-web-services","title":"Workspace Web Services","text":"

                                                              Use workspace select at the top of the welcome page to choose a workspace. The welcome page contact information and web services are updated to match the workspace selected.

                                                              Welcome Workspace Web Services

                                                              The web service links provided may be used in your Desktop GIS or web mapping application to access the workspace layers.

                                                              "},{"location":"webadmin/welcome/#layer-web-services","title":"Layer Web Services","text":"

                                                              Use the layer select at the top of the welcome page to choose a layer or layer group.

                                                              Welcome Workspace Web Services

                                                              The workspace select, along with the page contact information and web services are updated to match the layer selected.

                                                              "},{"location":"webadmin/welcome/#server-overview-administrators","title":"Server Overview (Administrators)","text":"

                                                              When logged in with administrative credentials a configuration overview is provided, along with any information or warning notifications.

                                                              Welcome Administrator Feedback

                                                              Click Layers summary link to navigate to the Layers page, press Add layers to create a new layer.

                                                              Click Stores summary link to navigate to the Stores page, press Add stores to create a new store.

                                                              Click Workspaces summary link to navigate to the Workspaces page, press Add workspaces to create a new workspace.

                                                              "},{"location":"webadmin/welcome/#information-and-warnings","title":"Information and Warnings","text":"

                                                              GeoServer status information messages provide feedback on normal operation.

                                                              Warnings describe configuration issues to be addressed, often with a short-cut to the configuration page used to address the issue.

                                                              "}]} \ No newline at end of file +{"config":{"lang":["en"],"separator":"[\\s\\-]+","pipeline":["stopWordFilter"]},"docs":[{"location":"","title":"GeoServer User Manual","text":"

                                                              GeoServer is an open source software server written in Java that allows users to share and edit geospatial data. Designed for interoperability, it publishes data from any major spatial data source using open standards.

                                                              This User Manual is a comprehensive guide to all aspects of using GeoServer. Whether you are a novice or a veteran user of this software, we hope that this documentation will be a helpful reference.

                                                              Introduction

                                                              Learn about GeoServer.

                                                              Installation

                                                              Install GeoServer for your platform.

                                                              Getting started

                                                              Tutorials to help you get started with GeoServer.

                                                              Web administration interface

                                                              Navigate the GeoServer graphical interface.

                                                              Data management

                                                              Load and publish data from a variety of sources.

                                                              Styling

                                                              Styling and visualization for published layers in GeoServer.

                                                              Services

                                                              OGC services, the primary method of publishing data in GeoServer.

                                                              Filtering

                                                              Filter your requests and responses to increase efficiency.

                                                              Server configuration

                                                              Configuration options for GeoServer administrators.

                                                              GeoServer data directory

                                                              Settings and configuration files for GeoServer.

                                                              Running in a production environment

                                                              Best practices for using GeoServer.

                                                              REST

                                                              Interact programmatically with GeoServer without using the graphical interface.

                                                              Security

                                                              Secure and restrict access to data and services.

                                                              GeoWebCache

                                                              Accelerate your GeoServer with tile caching.

                                                              Extensions

                                                              Add extra functionality to GeoServer with extensions.

                                                              Community modules

                                                              Add cutting-edge functionality to GeoServer with community modules.

                                                              Tutorials

                                                              Other tips and tricks for getting the most out of your GeoServer instance.

                                                              "},{"location":"community/","title":"Community modules","text":"

                                                              This section is devoted to GeoServer community modules. Community modules are considered \"pending\" in that they are not officially part of the GeoServer releases. They are however built along with the nightly builds, so you can download and play with them.

                                                              Warning

                                                              Community modules are generally considered experimental in nature and are often under constant development. For that reason documentation in this section should not be considered solid or final and will be subject to change.

                                                              Note

                                                              Unlike the official extensions, these modules are not released and stored on SourceForge when an official GeoServer release is produced. As a consequence, using a module built against the nightly build of GeoServer with an official release won't probably work.

                                                              If you need a community module for an official release, the only way is to build it with the sources of the GitHub tag matching the release.

                                                              • Backup and Restore Documentation
                                                              • COG (Cloud Optimized GeoTIFF) Documentation
                                                              • Dynamic colormap generation
                                                              • CoverageJSON output format
                                                              • DDS/BIL(World Wind Data Formats) Extension
                                                              • Elasticsearch data store
                                                              • Features-Templating Extension
                                                              • WFS FlatGeobuf output format
                                                              • GDAL based WCS Output Format
                                                              • GeoMesa data store
                                                              • GeoPackage Extension
                                                              • GeoStyler
                                                              • Graticule Extension
                                                              • GSR Extension
                                                              • GWC Azure BlobStore plugin
                                                              • GWC Distributed Caching community module
                                                              • GWC MBTiles layer plugin
                                                              • GWC SQLite Plugin
                                                              • SAP HANA
                                                              • Imagemap
                                                              • Importer JDBC storage
                                                              • JDBCConfig
                                                              • JDBCStore
                                                              • Introduction
                                                              • Keycloak extension
                                                              • Libdeflate
                                                              • MBTiles Extension
                                                              • Monitoring Hibernate storage
                                                              • Monitoring Kafka storage
                                                              • ncWMS WMS extensions support
                                                              • GHRSST NetCDF output
                                                              • Notification community module Plugin Documentation
                                                              • Authentication with OAuth2
                                                              • OGC API modules
                                                              • OGR datastore
                                                              • OpenSearch for EO
                                                              • PGRaster
                                                              • Proxy Base Extension
                                                              • Raster Attribute Table support
                                                              • WPS Remote community module
                                                              • S3 Support for GeoTiff
                                                              • Schemaless Features Plugin
                                                              • Smart Data Loader Extension
                                                              • SpatialJSON WFS Output Format Extension
                                                              • STAC Datastore extension
                                                              • SOLR data store
                                                              • Geoserver Task Manager
                                                              • Vector Mosaic datastore
                                                              • VSI Virtual File System Support
                                                              • XSLT WFS output format module
                                                              • HTTP Based Authorization plug-in
                                                              • WMS WebP output format
                                                              • WPS longitudinal profile process
                                                              "},{"location":"community/imagemap/","title":"Imagemap","text":"

                                                              HTML ImageMaps have been used for a long time to create interactive images in a light way. Without using Flash, SVG or VML you can simply associate different links or tooltips to different regions of an image. Why can't we use this technique to achieve the same result on a GeoServer map? The idea is to combine a raster map (png, gif, jpeg, ...) with an HTML ImageMap overlay to add links, tooltips, or mouse events behavior to the map.

                                                              An example of an ImageMap adding tooltips to a map:

                                                              <img src=\"...\" usemap=\"#mymap\"/>\n<map name=\"mymap\">\n     <area shape=\"poly\" coords=\"536,100 535,100 534,101 533,101 532,102\"  title=\"This is a tooltip\"/>\n     <area shape=\"poly\" coords=\"518,113 517,114 516,115 515,114\"  title=\"Another tooltip\"/>\n</map>\n

                                                              An example of an ImageMap adding links to a map:

                                                              <img src=\"...\" usemap=\"#mymap\"/>\n<map name=\"mymap\">\n     <area shape=\"poly\" coords=\"536,100 535,100 534,101 533,101 532,102\"  href=\"http://www.mylink.com\"/>\n     <area shape=\"poly\" coords=\"518,113 517,114 516,115 515,114\"  href=\"http://www.mylink2.com\"/>\n</map>\n

                                                              A more complex example adding interactive behaviour on mouse events:

                                                              <img src=\"...\" usemap=\"#mymap\"/>\n<map name=\"mymap\">\n     <area shape=\"poly\" coords=\"536,100 535,100 534,101 533,101 532,102\"  onmouseover=\"onOver('<featureid>')\" onmouseout=\"onOut('<featureid>')\"/>\n     <area shape=\"poly\" coords=\"518,113 517,114 516,115 515,114\"   onmouseover=\"onOver('<featureid>')\" onmouseout=\"onOut('<featureid>')\"/>\n</map>\n

                                                              To realize this in GeoServer some great community contributors developed an HTMLImageMap GetMapProducer for GeoServer, able to render an HTMLImageMap in response to a WMS GetMap request.

                                                              The GetMapProducer is associated to the text/html mime type. It produces, for each requested layer, a ... section containing the geometries of the layer as distinct tags. Due to the limitations in the shape types supported by the tag, a single geometry can be split into multiple ones. This way almost any complex geometry can be rendered transforming it into simpler ones.

                                                              To add interactive attributes we use styling. In particular, an SLD Rule containing a TextSymbolizer with a Label definition can be used to define dynamic values for the tags attributes. The Rule name will be used as the attribute name.

                                                              As an example, to define a title attribute (associating a tooltip to the geometries of the layer) you can use a rule like the following one:

                                                              <Rule>\n   <Name>title</Name>\n   <TextSymbolizer>\n      <Label><PropertyName>MYPROPERTY</PropertyName></Label>\n   </TextSymbolizer>\n</Rule>\n

                                                              To render multiple attributes, just define multiple rules, with different names (href, onmouseover, etc.)

                                                              Styling support is not limited to TextSymbolizers, you can currently use other symbolizers to detail rendering. For example you can:

                                                              • use a PointSymbolizer with a Size property to define point sizes.
                                                              • use LineSymbolizer with a stroke-width CssParameter to create thick lines.
                                                              "},{"location":"community/backuprestore/","title":"Backup and Restore Documentation","text":"

                                                              This section describes the GeoServer Backup and Restore plugin functionality and APIs.

                                                              • Installation
                                                              • Usage Via GeoServer's User Interface
                                                              • Usage Via GeoServer's REST API
                                                              • Backup and Restore Extension for the management of ImageMosaic indexers
                                                              • Use Cases
                                                              "},{"location":"community/backuprestore/extensions/","title":"Backup and Restore Extension for the management of ImageMosaic indexers","text":""},{"location":"community/backuprestore/extensions/#introduction","title":"Introduction","text":"

                                                              ImageMosaics CoverageStores make use of several .properties files instructing the reader on how to create the mosaic index.

                                                              What we want to achieve is to allow the GeoServer Backup & Restore module to inject environment properties on indexers allowing the ImageMosaic to be automatically ported among different environments.

                                                              "},{"location":"community/backuprestore/extensions/#technical-details","title":"Technical Details","text":"

                                                              The GeoServer Backup & Restore module actually provides an extension point on reading / writing allowing GeoServer to handle additional resources related to a particular ResourceInfo.

                                                              The interfaces :

                                                              public interface CatalogAdditionalResourcesWriter<T> {\n\n    public boolean canHandle(Object item);\n\n    public void writeAdditionalResources(Backup backupFacade, Resource base, T item)\n            throws IOException;\n\n}\n\npublic interface CatalogAdditionalResourcesReader<T> {\n\n    public boolean canHandle(Object item);\n\n    public void readAdditionalResources(Backup backupFacade, Resource base, T item)\n            throws IOException;\n\n}\n

                                                              Is invoked by the CatalogFileWriter (when doing a Backup) and the CatalogItemWriter (when doing a Restore) after a successful write of the resource configuration on the, respectively, target backup folder and in-memory catalog.

                                                              The idea is the following one allowing the CatalogItemWriter to:

                                                              1. Restore the ImageMosaic Indexer Properties injecting environment properties
                                                              2. Check if the Mosaic index physically exist and if not create an empty one

                                                              In order to do that we envisage the following technical approach

                                                              On a BACKUP operation

                                                              1. The Additional Resource Writer checks if the ResourceInfo is an ImageMosaic Coverage Store.
                                                              2. The Additional Resource Writer looks for *.template files on the ImageMosaic index directory. It must store them into the zip archive by reading the path from the Coverage Store.
                                                              3. The Additional Resource Writer stores the *.template along with the *.properties files on the target backup folder. Same as above.

                                                              On a RESTORE operation

                                                              1. The Additional Resource Reader checks if the ResourceInfo is an ImageMosaic Coverage Store.
                                                              2. The Additional Resource Reader looks for *.template files on the ImageMosaic index directory. It will try to restore them by using the path read from the Coverage Store configuration.
                                                              3. The Additional Resource Reader overwrites the *.properties files by resolving all the environment properties declared on the templates.
                                                              4. The Additional Resource Reader checks if the empty mosaic must be created or not.
                                                              "},{"location":"community/backuprestore/installation/","title":"Installation","text":""},{"location":"community/backuprestore/installation/#manual-install","title":"Manual Install","text":"

                                                              To download and install the required extensions by hand:

                                                              1. Download the geoserver- 2.24.2-backup-restore-plugin.zip from:

                                                                • Community Builds (GeoServer WebSite)

                                                                It is important to download the version that matches the GeoServer you are running.

                                                              2. Stop the GeoServer application.

                                                              3. Navigate into the webapps/geoserver/WEB-INF/lib folder.

                                                                These files make up the running GeoServer application.

                                                              4. Unzip the contents of the zip file into the lib folder.

                                                              5. Restart the Application Server.

                                                              6. Login to the Web Administration application. Select Data from the naviagion menu. Click Backup and Restore and ensure the page is rendered correctly and without errors.

                                                              Backup and Restore plugin can be used both via user interface and via HTTP REST interface. For more details please see the next sections.

                                                              "},{"location":"community/backuprestore/usagegui/","title":"Usage Via GeoServer's User Interface","text":"

                                                              At the end on Backup and Restore plugin installation you will see a new section in GeoServer UI

                                                              Clicking on the Backup and Restore label will give you access to the Backup and Restore configuration settings:

                                                              Here you'll be able to specify various parameters for the Backup / Restore procedure:

                                                              1. Archive full path: Path on the file system to the archive created by the backup procedure, in case a Backup is executed, or the archive to restore from, in case of a Restore procedure.

                                                              2. Filter by Workspace: Optional parameter that allows you to restrict the scope of the Backup / Restore to workspaces that meet the specified filter.

                                                              3. Backup Options:

                                                                1. Overwrite Existing Archive: When enabled the backup procedure will overwrite any previously existing archive
                                                                2. Skip Failing Resources: If enabled and errors are found during the backup of existing resources, skip the resource and go ahead with the backup procedure
                                                              4. Backup Executions: Report of running and previously run backups

                                                              5. Restore Options:

                                                                1. Dry Run: Test the restore procedure using the provided archive but do not apply any changes to current configuration. Useful to test archives before actually performing a Restore
                                                                2. Skip Failing Resources: If enabled and errors are found during the restore of resources, skip the resource and go ahead with the restore procedure
                                                              6. Restore Executions: Report of running and previously run restore

                                                              "},{"location":"community/backuprestore/usagegui/#performing-a-full-backup-via-ui","title":"Performing a full backup via UI","text":"

                                                              In order to perform a full backup, provide the full path of the target .zip archive where to store the configuration data.

                                                              Note

                                                              Please notice that the backup will store just the configuration files and not the original data.

                                                              It is also possible to use the Browse instrument to navigate the server folders. In any case the backup procedure won't start until it find a valid .zip path archive.

                                                              It is possible to select the backup options by enabling the appropriate checkboxes before starting the backup procedure.

                                                              Note

                                                              Please notice that while performing a backup or restore task, GeoServer won't allow users to access other sections by locking the catalog and configuration until the process has finished. Although it is always possible to stop or abandon a backup or restore procedure.

                                                              At the end of the backup, the user will be redirected to an Execution Summary page

                                                              The same page can be accessed also later by clicking an execution link from the main page.

                                                              Note

                                                              Please notice that the list of executions is not persisted and therefore it will be reset after a GeoServer container restart.

                                                              At the bottom of the Execution Details page, it's possible to download the .zip archive directly by clicking on the Download Archive File link.

                                                              In case some running exceptions or warning have been catched by the process, they will be presented on the execution summary. The Error Detail Level allows to inspect the causes by exposing the stack trace for each of them.

                                                              "},{"location":"community/backuprestore/usagegui/#restoring-via-ui","title":"Restoring via UI","text":"

                                                              The steps are almost the same of the backup. Just select the .zip archive full path before launching the restore process.

                                                              Warning

                                                              Please notice that a non-dry-run restore will lose all your current GeoServer configuration by replacing it with the new one, so be careful and be sure to backup everything before starting a restore.

                                                              DRY-RUN RESTORE

                                                              Dry Run option allows a user to test a .zip archive before actually performing a full restore.

                                                              ::: note ::: title Note :::

                                                              Please notice that the dry run should always being executed when trying to restore a new configuration. :::

                                                              A failing restore dry-run will appear like this

                                                              If some exception occurs, it will be listed on the execution summary page. The original cause can be inspected by rising up the errors details level and refreshing

                                                              "},{"location":"community/backuprestore/usagegui/#savingrestoring-only-specific-workspaces","title":"Saving/restoring only specific workspaces","text":"

                                                              It is possible to backup or restore only a subset of the available workspaces in the catalog. From the WEB interface is currently possible to select all or just one workspace to backup/restore

                                                              Through the REST APIs it is possible to filter out also more than one workspaces as explained in the next sections.

                                                              Note

                                                              Please notice that from a backup archive containing filtered workspaces won't be possible to restore also the missing ones. In order to do that it is advisable to backup the whole catalog and then restore only the workspaces needed.

                                                              "},{"location":"community/backuprestore/usagerest/","title":"Usage Via GeoServer's REST API","text":"

                                                              The Backup and Restore REST API consists of a few resources meant to be used in an asynchronous fashion:

                                                              Resource Method Parameters and Notes /rest/br/backup/ POST Post a JSON/XML document with the backup parameters, see below /rest/br/backup/backupId GET Returns a json/xml representation of the backup operation. See below /rest/br/backup/backupId DELETE Cancels the backup operation /rest/br/restore POST Post a JSON/XML document with the restore parameters, see below /rest/br/restore/restoreId GET Returns a json/xml representation of the backup operation, see below /rest/br/restore/restoreId DELETE Cancels the restore operation"},{"location":"community/backuprestore/usagerest/#usage-example","title":"Usage Example","text":"

                                                              We are going to use the command line tool cURL to send HTTP REST requests to GeoServer.

                                                              The /rest/br/backup/ and /rest/br/restore endpoints accept an optional format suffix that allows the Backup / Restore archive to be streamed to / from the client instead of being written on / read from the file system.

                                                              Initiate a Backup

                                                              Prepare a file containing with a JSON object representing the Backup procedure configuration.

                                                              backup_post.json:

                                                              {\n   \"backup\":{\n      \"archiveFile\":\"/home/sg/BackupAndRestore/test_rest_1.zip\",\n      \"overwrite\":true,\n      \"options\":{\n      }\n   }\n}\n

                                                              In this case we did not specify any options in the backup configuration so default values will be used.

                                                              Available options are:

                                                              1. BK_BEST_EFFORT: Skip any failing resources and proceed with the backup procedure. Default: false.
                                                              2. BK_PARAM_PASSWORDS: Whether outgoing store passwords should be parameterized in the backup. With this option set all store passwords will be replaced with a token that looks like \\${workspaceName:storeName.passwd.encryptedValue}. See also BK_PASSWORD_TOKENS for the Restore command.
                                                              3. BK_SKIP_SECURITY: This will exclude security settings from the backup. Default: true.
                                                              4. BK_SKIP_SETTINGS: This will attempt to exclude global settings from the backup, as well as security settings. Default: true.
                                                              5. BK_SKIP_GWC: This option will avoid backup / restore the GWC catalog and folders. Default: false.
                                                              6. BK_CLEANUP_TEMP: This will attempt to delete temporary folder at the end of the execution. Default: true.
                                                              7. exclude.file.path: A ; separated list of paths relative to the GEOSERVER_DATA_DIR (e.g.: 'exclude.file.path=/data/geonode;/monitoring;/geofence'). If exist, the backup / restore will skip the path listed. Default: [[]]{.title-ref}. WARNING: security and workspaces are treated differently. This option should be used only for custom external resources located under the GEOSERVER_DATA_DIR.

                                                              Also an optional Filter can be passed to restrict the scope of the restore operation to a list of workspaces.

                                                              For example:

                                                              {\n   \"backup\":{\n      \"archiveFile\":\"/home/sg/BackupAndRestore/test_rest_1.zip\",\n\"overwrite\":true,\n      \"options\":{\n        \"option\": [\"BK_BEST_EFFORT=true\"] \n      },\n\"filter\": \"name IN ('topp','geosolutions-it')\"\n   }\n}\n

                                                              Backup procedure will be initiated.

                                                              Here is a sample response:

                                                              HTTP/1.1 201 Created\nDate: Mon, 01 Aug 2016 14:35:44 GMT\nLocation: http://mygeoserver/geoserver/rest/br/backup/1\nServer: Noelios-Restlet-Engine/1.0..8\nContent-Type: application/json\nTransfer-Encoding: chunked\n
                                                              {\n   \"backup\":{\n      \"totalNumberOfSteps\":9,\n      \"execution\":{\n         \"id\":1,\n         \"version\":1,\n         \"stepExecutions\":{\n            \"@class\":\"java.util.concurrent.CopyOnWriteArraySet\"\n         },\n         \"status\":[\n            \"STARTED\"\n         ],\n         \"startTime\":\"2016-08-01 14:35:44.802 UTC\",\n         \"createTime\":\"2016-08-01 14:35:44.798 UTC\",\n         \"lastUpdated\":\"2016-08-01 14:35:44.803 UTC\",\n         \"exitStatus\":{\n            \"exitCode\":\"UNKNOWN\",\n            \"exitDescription\":\"\"\n         },\n         \"progress\":\"1\\/9\"\n      },\n      \"options\":{\n         \"@class\":\"synchList\",\n         \"option\":[\n            \"OVERWRITE=true\"\n         ]\n      },\n      \"warningsList\":{\n         \"@class\":\"synchList\"\n      },\n      \"archiveFile\":{\n         \"@class\":\"resource\",\n         \"$\":\"\\/home\\/sg\\/BackupAndRestore\\/test_rest_1.zip\"\n      },\n      \"overwrite\":true\n   }\n}\n

                                                              At the end of the backup procedure you'll be able to download the generated archive to your local file system by making an HTTP GET request to the same endpoint, using the backup ID as above and adding the .zip at the end.

                                                              curl -u \"admin:geoserver\" -i -X GET  \"http://mygeoserver/geoserver/rest/br/backup/1.zip\" -o 1.zip\n

                                                              Query status of Backup executions

                                                              Status of the operation can be queried making an HTTP GET request to the location listed in the response.

                                                              ``http://mygeoserver/geoserver/rest/br/backup/$ID.{json/xml}``\n

                                                              Replace $ID with the ID of the backup operation you'd like to inspect.

                                                              curl -u \"admin:geoserver\" http://mygeoserver/geoserver/rest/br/backup/1.json\n

                                                              or

                                                              curl -u \"admin:geoserver\" http://mygeoserver/geoserver/rest/br/backup/1.xml\n

                                                              GeoServer will respond with the status of the backup job corresponding to that ID

                                                              Here you are able to see the status of all the steps involved in the backup procedure with creation time, start time, end time, exit status etc.

                                                              Cancel a Backup

                                                              Cancel an in progress Backup by sending an HTTP DELETE request with the ID of the task

                                                              curl -v -XDELETE -u \"admin:geoserver\" http://mygeoserver/geoserver/rest/br/backup/$ID\n

                                                              Replace $ID with the ID of the backup operation you'd like to cancel.

                                                              Initiate a Restore

                                                              Prepare a file with a JSON object representing the Restore procedure configuration

                                                              restore_post.json:

                                                              {\n   \"restore\":{\n      \"archiveFile\":\"/home/sg/BackupAndRestore/test_rest_1.zip\",\n      \"options\":{\n      }\n   }\n}\n

                                                              In this case we did not specify any options in the restore configuration so default values will be used.

                                                              Available Options are:

                                                              1. BK_DRY_RUN: Only test the archive do not persist the restored configuration. Default: false.

                                                              2. BK_BEST_EFFORT: Skip any failing resources and proceed with the restore procedure. Default: false.

                                                              3. BK_PASSWORD_TOKENS: A comma separated list of equal sign separated key/values to be replaced in data store passwords in an incoming backup. For example:

                                                                BK_PASSWORD_TOKENS=${workspace:store1.passwd.encryptedValye}=foo,${workspace:store2.passwd.encryptedValue}=bar\n
                                                              4. BK_SKIP_SECURITY: This will exclude security settings from the restore. Default: true.

                                                              5. BK_SKIP_SETTINGS: This will attempt to exclude global settings from the backup, as well as security settings. Default: true.

                                                              6. BK_PURGE_RESOURCES: If 'false' this parameter will avoid deleting incoming resources where possible. In particular, existing workspaces will not be deleted during the restore. Default: true.

                                                              7. BK_SKIP_GWC: This option will avoid backup / restore the GWC catalog and folders. Default: false.

                                                              8. BK_CLEANUP_TEMP: This will attempt to delete temporary folder at the end of the execution. Default: true.

                                                              9. exclude.file.path: A ; separated list of paths relative to the GEOSERVER_DATA_DIR (e.g.: 'exclude.file.path=/data/geonode;/monitoring;/geofence'). If exist, the backup / restore will skip the path listed. Default: [[]]{.title-ref}. WARNING: security and workspaces are treated differently. This option should be used only for custom external resources located under the GEOSERVER_DATA_DIR.

                                                              Also an optional Filter can be passed to restrict the scope of the restore operation to a list of workspaces.

                                                              For example:

                                                              {\n   \"restore\":{\n      \"archiveFile\":\"/home/sg/BackupAndRestore/test_rest_1.zip\",\n      \"options\":{\n        \"option\": [\"BK_DRY_RUN=true\"] \n      },\n\"filter\": \"name IN ('topp','geosolutions-it')\"\n   }\n}\n

                                                              If archiveFile is specified, the archive specified on that path of the remote file system will be used to initiate the restore procedure. Otherwise the archive needs to be uploaded from your local system.

                                                              Then make a POST HTTP request to GeoServer's REST interface endpoint for the restore procedure

                                                              curl -u \"admin:geoserver\" -i -H \"Content-Type: application/json\" -X POST --data @restore_post.json http://mygeoserver/geoserver/rest/br/restore/\n

                                                              Restore procedure will be initiated.

                                                              Here is a sample response:

                                                              HTTP/1.1 201 Created\nDate: Mon, 01 Aug 2016 15:07:29 GMT\nLocation: http://mygeoserver/geoserver/rest/br/restore/2\nServer: Noelios-Restlet-Engine/1.0..8\nContent-Type: application/json\nTransfer-Encoding: chunked\n
                                                              {\n   \"restore\":{\n      \"totalNumberOfSteps\":9,\n      \"execution\":{\n         \"id\":2,\n         \"version\":1,\n         \"stepExecutions\":{\n            \"@class\":\"java.util.concurrent.CopyOnWriteArraySet\"\n         },\n         \"status\":[\n            \"STARTED\"\n         ],\n         \"startTime\":\"2016-08-01 15:07:29.398 UTC\",\n         \"createTime\":\"2016-08-01 15:07:29.393 UTC\",\n         \"lastUpdated\":\"2016-08-01 15:07:29.398 UTC\",\n         \"exitStatus\":{\n            \"exitCode\":\"UNKNOWN\",\n            \"exitDescription\":\"\"\n         },\n         \"progress\":\"0\\/9\"\n      },\n      \"options\":{\n         \"@class\":\"synchList\"\n      },\n      \"warningsList\":{\n         \"@class\":\"synchList\"\n      },\n      \"archiveFile\":{\n         \"@class\":\"resource\",\n         \"$\":\"\\/home\\/sg\\/BackupAndRestore\\/test_rest_1.zip\"\n      }\n   }\n}\n

                                                              To upload the archive from our local system instead, omit the archiveFile parameter in the JSON object and pass the --upload-file parameter to cURL:

                                                              restore_post.json:

                                                              {\n   \"restore\":{\n      \"options\":{\n      },\n   }\n}\n
                                                              curl -u \"admin:geoserver\" -i -H \"Content-Type: application/json\" --upload-file \"archive_to_restore.zip\" -X POST --data @restore_post.json http://localhost:8081/geoserver/rest/br/restore/\n

                                                              Local archive_to_restore.zip archive will be uploaded and used by the restore procedure.

                                                              Query for status of Restore operations

                                                              http://mygeoserver/geoser/restore/$ID.{json/xml}:

                                                              {\n   \"restore\":{\n      \"execution\":{\n         \"hash\":2,\n         \"key\":{\n            \"@class\":\"long\",\n            \"$\":\"2\"\n         },\n         \"val\":{\n            \"@class\":\"restore\",\n            \"totalNumberOfSteps\":9,\n            \"execution\":{\n               \"id\":2,\n               \"version\":2,\n               \"stepExecutions\":{\n                  \"@class\":\"java.util.concurrent.CopyOnWriteArraySet\",\n                  \"step\":[\n                     {\n                        \"name\":\"restoreNamespaceInfos\",\n                        \"status\":\"COMPLETED\",\n                        \"exitStatus\":{\n                           \"exitCode\":\"COMPLETED\",\n                           \"exitDescription\":\"\"\n                        },\n                        \"startTime\":\"8\\/1\\/16 3:07 PM\",\n                        \"endTime\":\"8\\/1\\/16 3:07 PM\",\n                        \"lastUpdated\":\"8\\/1\\/16 3:07 PM\",\n                        \"parameters\":{\n                           \"input.file.path\":\"file:\\/\\/\\/opt\\/tomcat-geoserver-2.9.x\\/temp\\/tmpbbe2388a-f26d-4f26-a20f-88c653d88aec\",\n                           \"time\":1470064049392\n                        },\n                        \"readCount\":1,\n                        \"writeCount\":1,\n                        \"failureExceptions\":\"\"\n                     },\n                    ...\n                     {\n                        \"name\":\"restoreGeoServerSecurityManager\",\n                        \"status\":\"COMPLETED\",\n                        \"exitStatus\":{\n                           \"exitCode\":\"COMPLETED\",\n                           \"exitDescription\":\"\"\n                        },\n                        \"startTime\":\"8\\/1\\/16 3:07 PM\",\n                        \"endTime\":\"8\\/1\\/16 3:07 PM\",\n                        \"lastUpdated\":\"8\\/1\\/16 3:07 PM\",\n                        \"parameters\":{\n                           \"input.file.path\":\"file:\\/\\/\\/opt\\/tomcat-geoserver-2.9.x\\/temp\\/tmpbbe2388a-f26d-4f26-a20f-88c653d88aec\",\n                           \"time\":1470064049392\n                        },\n                        \"readCount\":0,\n                        \"writeCount\":0,\n                        \"failureExceptions\":\"\"\n                     }\n                  ]\n               },\n               \"status\":\"COMPLETED\",\n               \"startTime\":\"2016-08-01 15:07:29.398 UTC\",\n               \"createTime\":\"2016-08-01 15:07:29.393 UTC\",\n               \"endTime\":\"2016-08-01 15:07:30.356 UTC\",\n               \"lastUpdated\":\"2016-08-01 15:07:30.772 UTC\",\n               \"exitStatus\":{\n                  \"exitCode\":\"COMPLETED\",\n                  \"exitDescription\":\"\"\n               },\n               \"progress\":\"9\\/9\"\n            },\n            \"options\":{\n               \"@class\":\"synchList\"\n            },\n            \"warningsList\":{\n               \"@class\":\"synchList\"\n            },\n            \"archiveFile\":{\n               \"@class\":\"resource\",\n               \"$\":\"\\/home\\/sg\\/BackupAndRestore\\/test_rest_1.zip\"\n            }\n         }\n      }\n      ...\n

                                                              Here you are able to see the status of all the steps involved in the restore procedure with creation time, start time, end time, exit status etc.

                                                              Cancel a Restore

                                                              Cancel an in-progress Restore by sending an HTTP DELETE request:

                                                              curl -v -XDELETE -u \"admin:geoserver\" http://mygeoserver/geoserver/rest/br/restore/$ID\n

                                                              Replace $ID with the ID of the restore operation you'd like to cancel.

                                                              "},{"location":"community/backuprestore/usecases/","title":"Use Cases","text":""},{"location":"community/backuprestore/usecases/#database-vs-shapefile-based-indexer","title":"Database vs. Shapefile based indexer","text":"

                                                              When using a DataBase as backend storage for the mosaic index, a datastore.properties file is present on the mosaic folder containing the connection parameters.

                                                              In case the user wants to parametrize this, he must create a .template datastore properties file containing all the properties of the original one but using placemarks as parametric values.

                                                              As an instance:

                                                              host=${mosaic1.jdbc.host}\nport=${mosaic1.jdbc.port}\n...\n

                                                              The backup and restore extension will save on the archive both the original .properties and the .template

                                                              When restoring, the extension will overwrite the .properties by using the .template and substituting the placemarks with the correct environment property values.

                                                              When using a shapefile as backend for the index the shapefile itself will be created once again by the mosaic when performing the first harvest operation.

                                                              "},{"location":"community/backuprestore/usecases/#database-connection-parameters-vs-jndi","title":"Database Connection Parameters vs. JNDI","text":"

                                                              This use case is similar to the previous one, except for the fact that instead of parameters like host and port we will have a parametric JNDI name.

                                                              "},{"location":"community/backuprestore/usecases/#indexer-files-and-regex","title":"Indexer files and regex","text":"

                                                              The approach will be exactly the same of the datastore.properties.

                                                              It's worth notice that the backup extension will overwrite only the files having a corresponding .template prototype.

                                                              "},{"location":"community/backuprestore/usecases/#granules-stored-on-the-same-mosaic-folder-vs-absolute-path","title":"Granules stored on the same mosaic folder vs. absolute path","text":"

                                                              This won't impact the backup and restore at all, since it will never dumps data into the final archive.

                                                              It is important, however, that the absolute paths are parametric similar to the connection parameters explained above.

                                                              "},{"location":"community/backuprestore/usecases/#dealing-with-non-existing-indexes-on-the-target-restored-environment","title":"Dealing with non-existing indexes on the target restored environment","text":"

                                                              It is possible that when restoring the ImageMosaic the index does not exist on the target environment.

                                                              The backup and restore extension should perform a double check once restored the datastore.properties file trying to access the index store.

                                                              1. In case of failure, i.e. the extension cannot connect to the datastore, the resource will fail.
                                                              2. In case the datastore is accessible but the index does not exist, the plugin will create an empty mosaic on the catalog instead of failing.
                                                              "},{"location":"community/cog/","title":"COG (Cloud Optimized GeoTIFF) Documentation","text":"

                                                              This section describes the COG plugin usage and it also contains an example on how to configure an ImageMosaic on top of remote COG datasets and harvest them.

                                                              • COG (Cloud Optimized GeoTIFF) Support
                                                              • ImageMosaic example with Modis COG datasets
                                                              • COG ImageMosaic from local storage to S3
                                                              "},{"location":"community/cog/cog/","title":"COG (Cloud Optimized GeoTIFF) Support","text":"

                                                              COG (Cloud Optimized GeoTIFF) is a regular GeoTIFF file, aimed at being hosted on a HTTP file server, whose internal organization is friendly for consumption by clients issuing HTTP GET range requests. The COG module allows to set configuration params to connect to a Cloud GeoTIFF, as well as adding JARs to the classpath needed to support that connection.

                                                              "},{"location":"community/cog/cog/#installation","title":"Installation","text":"

                                                              As a community module, the package needs to be downloaded from the nightly builds, picking the community folder of the corresponding GeoServer series (e.g. if working on the GeoServer main development branch nightly builds, pick the zip file form main/community-latest).

                                                              To install the module, unpack the zip file contents into the GeoServer WEB-INF/lib directory and restart GeoServer.

                                                              "},{"location":"community/cog/cog/#cog-geotiff-configuration-panel","title":"COG GeoTIFF Configuration Panel","text":"

                                                              The COG plugin does not add new stores, instead, it adds COG support to existing ones.

                                                              When configuring a GeoTIFF store, a new checkbox is available: Cloud Optimized GeoTIFF (COG). Setting that will open a new section presenting the COG configuration parameters for this COG Store.

                                                              COG Connection params

                                                              Checking the Cloud Optimized GeoTIFF (COG) checkbox will provide new options:

                                                              Option Description URL (prefixed by cog://) representing the connection URL to the COG Dataset. Range Reader Settings Which type of Range Reader implementation. Values currently supported are HTTP, GoogleCloud, Azure, S3 the latter using an S3 Client User Name / Access Key ID / Account Name Optional user name (HTTP) or Access Key ID (S3) or Account Name (Azure) in case the COG dataset requires authentication Password / Secret Access Key / Account Key Password (HTTP) or Secret Access Key (S3) or Account Key (Azure) for the previous credential"},{"location":"community/cog/cog/#cog-imagemosaic-configuration","title":"COG ImageMosaic Configuration","text":"

                                                              Additional configuration parameters can be specified in the ImageMosaic indexer configuration, in order to properly configure a COG based ImageMosaic.

                                                              "},{"location":"community/cog/cog/#indexerproperties","title":"indexer.properties","text":"Parameter Mandatory? Description Cog Y A boolean flag (true/false) to be set (Cog=true) in order to signal that the ImageMosaic is a COG data mosaic. CogRangeReader N Specifies the desired RangeReader implementation performing the Range Reads requests. CogUser N Credential to be set whenever basic HTTP authentication is needed to access the COG Datasets or an S3 Access KeyID is required or an Azure AccountName is required CogPassword N Password for the above user OR Secret Access Key for the above S3 KeyId or AccountKey for the above Azure AccountName."},{"location":"community/cog/cog/#cog_plugin_rangereader","title":"COG RangeReader","text":"

                                                              The following table provides the values for the CogRangeReader based on the type of target storage:

                                                              Storage type Class name HTTP Can be omitted, or set to it.geosolutions.imageioimpl.plugins.cog.HttpRangeReader AWS S3 it.geosolutions.imageioimpl.plugins.cog.S3RangeReader Google Cloud it.geosolutions.imageioimpl.plugins.cog.GSRangeReader Azure it.geosolutions.imageioimpl.plugins.cog.AzureRangeReader"},{"location":"community/cog/cog/#cog-global-settings","title":"COG Global Settings","text":"

                                                              The GeoServer Global Settings page contains the default COG settings presented when setting up a new COG GeoTIFF Store.

                                                              Default Global COG Settings

                                                              "},{"location":"community/cog/cog/#image-locations","title":"Image locations","text":"

                                                              For images served by a HTTP server, a HTTP URL must be used. For images served by S3 or Google Cloud, it's possible to use both the public HTTP URL, or the idiomatic URIS, for example:

                                                              • s3://landsat-pds/c1/L8/153/075/LC08_L1TP_153075_20190515_20190515_01_RT/LC08_L1TP_153075_20190515_20190515_01_RT_B2.TIF
                                                              • gs://gcp-public-data-landsat/LC08/01/044/034/LC08_L1GT_044034_20130330_20170310_01_T2/LC08_L1GT_044034_20130330_20170310_01_T2_B11.TIF
                                                              "},{"location":"community/cog/cog/#http-client-okhttp-configuration","title":"HTTP Client (OkHttp) configuration","text":"

                                                              HTTP client configuration (based on OkHttp client) can be specified through Environment variables.

                                                              Environment Variable Description IIO_HTTP_MAX_REQUESTS The maximum number of requests to execute concurrently. Above this requests queue in memory, waiting for the running calls to complete. (Default 128) IIO_HTTP_MAX_REQUESTS_PER_HOST The maximum number of requests for each host to execute concurrently. (Default 5) IIO_HTTP_MAX_IDLE_CONNECTIONS The maximum number of idle connections. (Default 5) IIO_HTTP_KEEP_ALIVE_TIME The Keep alive time (in seconds), representing maximum time that excess idle threads will wait for new tasks before terminating. (Default 60)"},{"location":"community/cog/cog/#aws-s3-client-configuration","title":"AWS S3 Client configuration","text":"

                                                              A single S3 Asynchronous Client will be used for the same region and alias (url schema, i.e. http, https). The following Environment Variables can be set to customize the pool for the asynchronous client for that particular alias. On the table below, replace the \"\\$ALIAS\\$\" template with HTTP or HTTPS or S3 if you are configuring properties for these schema.

                                                              Environment Variable Description IIO_\\$ALIAS\\$_AWS_CORE_POOL_SIZE The core pool size for the S3 Client (Default 50) IIO_\\$ALIAS\\$_AWS_MAX_POOL_SIZE The maximum number of thread to allow in the pool for the S3 Client (Default 128) IIO_\\$ALIAS\\$_AWS_KEEP_ALIVE_TIME The Keep alive time (in seconds), representing maximum time that excess idle threads will wait for new tasks before terminating. (Default 10) IIO_\\$ALIAS\\$_AWS_USER Default user (access key ID) for AWS basic authentication credentials IIO_\\$ALIAS\\$_AWS_PASSWORD Default password (secret access key) for AWS basic authentication credentials IIO_\\$ALIAS\\$_AWS_REGION Default AWS region IIO_\\$ALIAS\\$_AWS_ENDPOINT Endpoint to Amazon service or any other S3-compatible service run by a third-party"},{"location":"community/cog/cog/#google-cloud-storage-configuration","title":"Google Cloud storage configuration","text":"

                                                              The credentials to access Google Cloud cannot be provided as username and password (an authentication method that Google Cloud does not support), but need to be provided via a system variable pointing to the key file:

                                                              set GOOGLE_APPLICATION_CREDENTIALS=/path/to/the/key-file.json\nexport GOOGLE_APPLICATION_CREDENTIALS\n
                                                              "},{"location":"community/cog/cog/#azure-configuration","title":"Azure configuration","text":"

                                                              A single Azure Client will be used for the same container. Account and container will be retrieved from the provided Azure URL. The following System Properties can be set to customize client properties where missing.

                                                              System property Description azure.reader.accountName The Azure Account Name azure.reader.accountKey The Azure Account Key for the above Account azure.reader.container The default container for the above Account azure.reader.prefix The optional prefix containing blobs azure.reader.maxConnections The max number of connections supported by the underlying Azure client"},{"location":"community/cog/cog/#client-configuration-system-properties","title":"Client configuration (System Properties)","text":"

                                                              Note that all the IIO settings reported in the previous tables can also be specified using System Properties instead of Environment variables. You just need to replace UPPER CASE words with lower case words and underscores with dots. So, the value for Maximum HTTP requests can be specified by setting either a IIO_HTTP_MAX_REQUESTS Environment variable or a iio.http.max.requests Java System Property alternatively (Environment variables are checked first).

                                                              By default, when accessing a COG, an initial chunk of 16 KB is read in attempt to parse the header so that the reader will have the offset and length of the available tiles. When dealing with files hosting many tiles, it is possible that the whole header won't fit in the initial chunk. In this case additional reads (chunks of the same size) will be progressively made to complete loading the header. A it.geosolutions.cog.default.header.length system property can be configured to set the length (in bytes) of the reading chunk. Tuning this so that the header is read with few extra requests can help improve performance. A value too large can cause memory consumption issues and will reduce efficiency, as un-necessary data will be read.

                                                              "},{"location":"community/cog/mosaic/","title":"ImageMosaic example with Modis COG datasets","text":""},{"location":"community/cog/mosaic/#introduction","title":"Introduction","text":"

                                                              This tutorial provide some hints on configuring an ImageMosaic on top of some MODIS Vegetation Index datasets available at NASA EarthData

                                                              "},{"location":"community/cog/mosaic/#imagemosaic-configuration-files","title":"ImageMosaic Configuration files","text":"

                                                              We need a couple of configuration files to have an ImageMosaic properly set. Configuration is based on these key points:

                                                              • The ImageMosaic will be initially created empty without any data. Data will be harvested as a second step.
                                                              • A Time dimension will be used, based on the date contained in the file's name.

                                                              More details on ImageMosaic configuration are available on the dedicated documentation section: ImageMosaic configuration

                                                              Based on the above key points, we can setup the following configuration files:

                                                              "},{"location":"community/cog/mosaic/#indexerproperties","title":"indexer.properties:","text":"

                                                              This contains the main configuration to index the datasets composing the ImageMosaic.

                                                              Cog=true\nPropertyCollectors=TimestampFileNameExtractorSPI[timeregex](time)\nTimeAttribute=time\nSchema=*the_geom:Polygon,location:String,time:java.util.Date\nCanBeEmpty=true\nName=modisvi\n

                                                              Relevant parts:

                                                              • Cog flag specifying that the ImageMosaic is a Mosaic of COG Datasets
                                                              • PropertyCollectors, TimeAttribute and Schema are used to define the ImageMosaic index columns and how to populate them
                                                              • CanBeEmpty allows to define an empty ImageMosaic. It will be populated afterwards
                                                              • Name is the name for this mosaic
                                                              "},{"location":"community/cog/mosaic/#timeregexproperties","title":"timeregex.properties:","text":"

                                                              The previous indexer refers to a time dimension and the related time column in the index's schema that will get populated by extracting the time value from the filename (the 8 digits, representing YEAR, MONTH, DAY) using the regex specified in the timeregex.properties file. An example of sample file for this collection as stored on the S3 bucket is 2018.01.01.tif so the time regex will reflect that. Note the 3 groups of digits and the 'format' of the date.

                                                              . literalinclude:: src/modisvi/timeregex.properties

                                                              "},{"location":"community/cog/mosaic/#datastoreproperties","title":"datastore.properties:","text":"

                                                              Due to the amount of available datasets, storing the ImageMosaic index on a DBMS is recommended, i.e. a PostGIS DB. See **`datastore.properties** <../../data/raster/imagemosaic/configuration.rst#mosaic_datastore_properties>`_ section of the ImageMosaic documentation for more info. Make sure that a DB with the name reported in the datastore is available

                                                              user=postgres\nport=5432\npasswd=postgres\nurl=jdbc\\:postgresql\\:modisvi\nhost=localhost\ndatabase=modisvi\ndriver=org.postgresql.Driver\nschema=public\nSPI=org.geotools.data.postgis.PostgisNGDataStoreFactory\nfetch\\ size=1000\nmax\\ connections=20\nmin\\ connections=5\nvalidate\\ connections=true\nLoose\\ bbox=true\nExpose\\ primary\\ key=false\nMax\\ open\\ prepared\\ statements=50\npreparedStatements=false\nEstimated\\ extends=false\nConnection\\ timeout=20\n

                                                              Once the 3 files have been setup, create a zip archive with them and let's name it modisvi.zip. (Note that the files need to be in the root of the zip files, not into a subdirectory)

                                                              You are now ready to use REST calls to start the ImageMosaic creation.

                                                              "},{"location":"community/cog/mosaic/#imagemosaic-rest-operations","title":"ImageMosaic REST operations","text":"

                                                              On the next steps we assume:

                                                              • An existing GeoServer instance is running on port 8080 of localhost.
                                                              • A workspace named \"test\" exists on that GeoServer.
                                                              • REST credentials are user=admin password=geoserver.
                                                              • A default aws region is defined on JAVA System Property, using the flag -Diio.https.aws.region=us-west-2.

                                                              Make sure to update the incoming URLs accordingly, based on your actual installation.

                                                              Create an empty ImageMosaic without configuring it

                                                              curl request

                                                              curl -u admin:geoserver -XPUT --write-out %{http_code} -H \"Content-type:application/zip\" --data-binary @modisvi.zip http://localhost:8080/geoserver/rest/workspaces/test/coveragestores/modisvi/file.imagemosaic?configure=none

                                                              Response

                                                              201 OK\n

                                                              Providing sample prototyping granules

                                                              Next step is providing a prototype dataset for the coverage to be supported.

                                                              curl request

                                                              curl -u admin:geoserver -XPOST -H \"Content-type: text/plain\" --write-out %{http_code} -d \"https://modis-vi-nasa.s3-us-west-2.amazonaws.com/MOD13A1.006/2018.01.01.tif\" \"http://localhost:8080/geoserver/rest/workspaces/test/coveragestores/modisvi/remote.imagemosaic\"

                                                              Response

                                                              202 Accepted\n

                                                              Initializing the store (Listing available coverages)

                                                              Once a prototype has been provided we need to initialize the store by querying it for the available coverages.

                                                              curl request

                                                              curl -v -u admin:geoserver -XGET http://localhost:8080/geoserver/rest/workspaces/test/coveragestores/modisvi/coverages.xml?list=all

                                                              Response

                                                              <List>\n  <coverageName>modisvi</coverageName>\n</list>\n

                                                              Configuring the coverage

                                                              Once we get the list of available coverages, we need to configure a coverage by sending the config through REST.

                                                              curl request

                                                              curl -v -u admin:geoserver -XPOST -H \"Content-type: text/xml\" -d @\"coverage.xml\" \"http://localhost:8080/geoserver/rest/workspaces/test/coveragestores/modisvi/coverages\"

                                                              where coverage.xml has this content:

                                                              <coverage>\n  <name>modisvi</name>\n  <nativeName>modisvi</nativeName>\n  <enabled>true</enabled>\n  <metadata>\n    <entry key=\"time\">\n      <dimensionInfo>\n        <enabled>true</enabled>\n        <presentation>LIST</presentation>\n        <units>ISO8601</units>\n        <defaultValue>\n          <strategy>MAXIMUM</strategy>\n        </defaultValue>\n      </dimensionInfo>\n    </entry>\n  </metadata>\n</coverage>\n

                                                              Adding more granules

                                                              Now that we have a coverageStore ready and a coverage layer configured we can start adding more granules.

                                                              curl request

                                                              curl -u admin:geoserver -XPOST -H \"Content-type: text/plain\" --write-out %{http_code} -d \"https://modis-vi-nasa.s3-us-west-2.amazonaws.com/MOD13A1.006/2018.01.17.tif\" \"http://localhost:8080/geoserver/rest/workspaces/test/coveragestores/modisvi/remote.imagemosaic\"

                                                              Setting Style

                                                              That MODIS data has 2 bands representing (Normalized Difference Vegetation Index) (NDVI) and Enhanced Vegetation Index (EVI). Let's add this ndvi.sld style to apply a proper colormap to the NDVI band (copy this content to a file named ndvi.sld to be used by the next REST call):

                                                              <StyledLayerDescriptor xmlns=\"http://www.opengis.net/sld\" xmlns:sld=\"http://www.opengis.net/sld\" xmlns:gml=\"http://www.opengis.net/gml\" xmlns:ogc=\"http://www.opengis.net/ogc\" version=\"1.0.0\">\n  <NamedLayer>\n    <Name>Default Styler</Name>\n    <UserStyle>\n      <Name>ndvi</Name>\n      <Title>ndvi</Title>\n      <FeatureTypeStyle>\n        <Name>name</Name>\n        <Rule>\n          <RasterSymbolizer>\n            <ChannelSelection>\n              <GrayChannel>\n                <SourceChannelName>1</SourceChannelName>\n              </GrayChannel>\n            </ChannelSelection>\n            <ColorMap>\n              <ColorMapEntry color=\"#000000\" quantity=\"-1\"/>\n              <ColorMapEntry color=\"#0000ff\" quantity=\"-0.75\"/>\n              <ColorMapEntry color=\"#ff00ff\" quantity=\"-0.25\"/>\n              <ColorMapEntry color=\"#ff0000\" quantity=\"0\"/>\n              <ColorMapEntry color=\"#ffff00\" quantity=\"0.5\"/>\n              <ColorMapEntry color=\"#00ff00\" quantity=\"1\"/>\n            </ColorMap>\n            <ContrastEnhancement/>\n          </RasterSymbolizer>\n        </Rule>\n      </FeatureTypeStyle>\n    </UserStyle>\n  </NamedLayer>\n</StyledLayerDescriptor>\n

                                                              curl request to create the style

                                                              curl -v -u admin:geoserver -XPOST -H \"Content-type: application/vnd.ogc.sld+xml\" -d @ndvi.sld http://localhost:8080/geoserver/rest/styles

                                                              curl request to set the style as default style of the layer

                                                              :

                                                              curl -v -u admin:geoserver -XPUT -H \"Content-type: text/xml\" -d \"<layer><defaultStyle><name>ndvi</name></defaultStyle></layer>\" http://localhost:8080/geoserver/rest/layers/modisvi.xml\n
                                                              "},{"location":"community/cog/mosaic/#final-preview","title":"Final preview","text":"

                                                              This is how a layer preview will looks like:

                                                              NDVI COG dataset

                                                              "},{"location":"community/cog/update/","title":"COG ImageMosaic from local storage to S3","text":""},{"location":"community/cog/update/#introduction","title":"Introduction","text":"

                                                              This tutorial provides instructions to update an existing ImageMosaic built on top of local granules to a COG ImageMosaic with granules stored on S3 bucket. It is aimed to users that want to move COG granules of an ImageMosaic to a remote bucket without the need of re-harvesting the whole collection of granules.

                                                              "},{"location":"community/cog/update/#assumptions","title":"Assumptions","text":"
                                                              • An ImageMosaic store already exists, with its index based on a DB (i.e. PostGIS).
                                                              • Local GeoTIFF granules are already valid COGs.
                                                              • User has experience with uploading data on S3.
                                                              "},{"location":"community/cog/update/#verifying-data-is-valid-cog","title":"Verifying data is valid COG","text":"

                                                              Verifying that a sample GeoTIFF is a valid COG can be achieved using COG validator service.

                                                              1. Store a sample GeoTIFF to the target bucket (or to the server location) you will use for remote serving and copy its full URL location, i.e. https://modis-vi-nasa.s3-us-west-2.amazonaws.com/MOD13A1.006/2018.01.01.tif.
                                                              2. Go to COG Validator
                                                              3. Paste the sample COG URL in the text box and hit the submit button.
                                                              4. In case the sample file is a valid COG, you will get a message like this:

                                                              Cloud Optimized GeoTIFF Validator: result Validation succeeded ! https://sample.s3.eu-central-1.amazonaws.com/test/cog.tif is a valid Cloud Optimized GeoTIFF.

                                                              In case the file isn't a valid COG, you can use GDAL 3.1 or above to convert your file to COG format. See the related GDAL documentation for further details.

                                                              Once the data has been verified, all of your granules need to be stored to an S3 bucket.

                                                              "},{"location":"community/cog/update/#imagemosaic-update","title":"ImageMosaic update","text":"

                                                              Next step is updating both the ImageMosaic's config as well as the index.

                                                              "},{"location":"community/cog/update/#imagemosaic-configuration-update","title":"ImageMosaic configuration update","text":"

                                                              A few new properties need to be added to the ImageMosaic configuration to support COG.

                                                              Locate the .properties file containing the mosaic configuration. It's usually a .properties file having the same name of the parent folder. You may recognize it since it's usually being autogenerated during first ImageMosaic configuration and it contains this header:

                                                              #-Automagically created from GeoTools-.

                                                              Let's assume it's named mosaic.properties for simplicity for future references in this documentation. Once located, edit that file by adding these new properties:

                                                              • Cog=true
                                                              • SuggestedSPI=it.geosolutions.imageioimpl.plugins.cog.CogImageReaderSpi

                                                              When storing your granules on a public bucket, you may stick with the default RangeReader implementation so no other flags are needed and you can skip to the ImageMosaic index update paragraph.

                                                              In case you are using a private bucket instead, you need to specify additional properties to the mosaic.properties file:

                                                              • CogRangeReader=it.geosolutions.imageioimpl.plugins.cog.S3RangeReader
                                                              • CogUser=S3AccessKeyID
                                                              • CogPassword=S3SecretAccessKey

                                                              Where the S3AccessKeyID and S3SecretAccessKey are the actual values needed to access that bucket.

                                                              "},{"location":"community/cog/update/#imagemosaic-index-update","title":"ImageMosaic index update","text":"

                                                              The next step is updating the ImageMosaic index which is a catalog of all the granules composing the mosaic. We need to update the location values to refer to remote URLs instead of local paths on disk. The location attribute initially contains the path of each granule on disk, which can be either a relative or an absolute path. Relative paths are relative to the ImageMosaic parent configuration folder whilst absolute paths are full paths.

                                                              The mosaic.properties file contains a PathType property set to RELATIVE or ABSOLUTE. On old mosaics, that property might be missing and AbsolutePath property exists instead with a boolean value true/false. Based on that, note that all the paths of the same mosaic will be either relative or absolute.

                                                              To give you an example, an ImageMosaic stored at /var/data/imageMosaic/mosaic with a granule at /var/data/imageMosaic/mosaic/2018.01.01.tif may have a record in the database with location attribute equal to :

                                                              • 2018.01.01.tif in case of relative path
                                                              • /var/data/imageMosaic/mosaic/2018.01.01.tif in case of absolute path.

                                                              The type of path affects the query to be executed to update the index.

                                                              Note

                                                              Make sure to backup your table for a quick recovery in case of messes with the updating query.

                                                              For this example, we are going to use the same public datasets from S3 Urls being used in the previous ImageMosaic example with Modis COG datasets section.

                                                              For location with relative paths a simple replacing query could be like this:

                                                              UPDATE schema.table SET location=CONCAT(\n'https://modis-vi-nasa.s3-us-west-2.amazonaws.com/MOD13A1.006/', location);\n

                                                              So we are basically prepending the S3 bucket URL to the location value. By this way, based on the above examples, location=2018.01.01.tif will become location='https://modis-vi-nasa.s3-us-west-2.amazonaws.com/MOD13A1.006/2018.01.01.tif

                                                              For location with absolute path, a replacing query may be like this (for our example):

                                                              UPDATE schema.table SET location=REPLACE(location,'/var/data/imageMosaic/mosaic/',\n'https://modis-vi-nasa.s3-us-west-2.amazonaws.com/MOD13A1.006/');\n
                                                              "},{"location":"community/cog/update/#geoserver-reload","title":"GeoServer reload","text":"

                                                              Once everything is done, reload the GeoServer configuration.

                                                              "},{"location":"community/colormap/","title":"Dynamic colormap generation","text":"

                                                              ras:DynamicColorMap is a Raster-to-Raster rendering transformation which applies a dynamic color map to a Raster on top of its statistics and a set of colors.

                                                              "},{"location":"community/colormap/#installing-the-dynamic-colormap-community-extension","title":"Installing the dynamic colormap community extension","text":"
                                                              1. Download the extension from the nightly GeoServer community module builds.

                                                                ::: warning ::: title Warning :::

                                                                Make sure to match the version of the extension to the version of the GeoServer instance! :::

                                                              2. Extract the contents of the archive into the WEB-INF/lib directory of the GeoServer installation.

                                                              "},{"location":"community/colormap/#usage","title":"Usage","text":"

                                                              The following SLD invokes a Dynamic Color Map rendering transformation on a Coverage using colorMaps created on top of QuantumGIS SVG files. Dynamic Color Map Rendering Transformation takes data as first parameter (the coverage) and ColorRamp as second parameter which is a colorMap.

                                                              <?xml version=\"1.0\" encoding=\"ISO-8859-1\"?>\n<StyledLayerDescriptor version=\"1.0.0\"\n    xsi:schemaLocation=\"http://www.opengis.net/sld StyledLayerDescriptor.xsd\"\n    xmlns=\"http://www.opengis.net/sld\"\n    xmlns:ogc=\"http://www.opengis.net/ogc\"\n    xmlns:xlink=\"http://www.w3.org/1999/xlink\"\n    xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\">\n  <NamedLayer>\n    <Name>DynamicColorMap</Name>\n    <UserStyle>\n      <Title>DynamicColorMap</Title>\n      <Abstract>A DynamicColorMap</Abstract>\n      <FeatureTypeStyle>\n        <Transformation>\n          <ogc:Function name=\"ras:DynamicColorMap\">\n            <ogc:Function name=\"parameter\">\n              <ogc:Literal>data</ogc:Literal>\n            </ogc:Function>\n            <ogc:Function name=\"parameter\">\n              <ogc:Literal>colorRamp</ogc:Literal>\n              <ogc:Function name=\"colormap\">\n                <ogc:Literal>gmt\\GMT_panoply</ogc:Literal>\n                <ogc:Function name=\"gridCoverageStats\"><ogc:Literal>minimum</ogc:Literal></ogc:Function>\n                <ogc:Function name=\"gridCoverageStats\"><ogc:Literal>maximum</ogc:Literal></ogc:Function>\n              </ogc:Function>\n            </ogc:Function>\n          </ogc:Function>\n        </Transformation>\n        <Rule>\n         <Name>rule1</Name>\n         <RasterSymbolizer>\n           <Opacity>1.0</Opacity>\n         </RasterSymbolizer>\n        </Rule>\n      </FeatureTypeStyle>\n    </UserStyle>\n  </NamedLayer>\n </StyledLayerDescriptor>\n

                                                              Key aspects of the SLD are:

                                                              • Lines 14-15 define the rendering transformation, using the process ras:DynamicColorMap.

                                                              • Lines 16-18 supply the input data parameter, named data in this process.

                                                              • Lines 19-21 supply a value for the process's colorRamp parameter which specifies a colorMap.

                                                              • Lines 22-23 supply the value for the colorMap parameter. In this case it's a reference to a SVG containing a LinearGradient definition.

                                                                A sample of QuantumGIS SVG LinearGradient subelement is:

                                                                <linearGradient id=\"GMT_panoply\" gradientUnits=\"objectBoundingBox\" spreadMethod=\"pad\" x1=\"0%\" x2=\"100%\" y1=\"0%\" y2=\"0%\">\n    <stop offset=\"0.00%\" stop-color=\"rgb(4,14,216)\" stop-opacity=\"1.0000\"/>\n    <stop offset=\"6.25%\" stop-color=\"rgb(4,14,216)\" stop-opacity=\"1.0000\"/>\n    <stop offset=\"6.25%\" stop-color=\"rgb(32,80,255)\" stop-opacity=\"1.0000\"/>\n    <stop offset=\"12.50%\" stop-color=\"rgb(32,80,255)\" stop-opacity=\"1.0000\"/>\n    <stop offset=\"12.50%\" stop-color=\"rgb(65,150,255)\" stop-opacity=\"1.0000\"/>\n    <stop offset=\"18.75%\" stop-color=\"rgb(65,150,255)\" stop-opacity=\"1.0000\"/>\n    <stop offset=\"18.75%\" stop-color=\"rgb(109,193,255)\" stop-opacity=\"1.0000\"/>\n    <stop offset=\"25.00%\" stop-color=\"rgb(109,193,255)\" stop-opacity=\"1.0000\"/>\n    <stop offset=\"25.00%\" stop-color=\"rgb(134,217,255)\" stop-opacity=\"1.0000\"/>\n    <stop offset=\"31.25%\" stop-color=\"rgb(134,217,255)\" stop-opacity=\"1.0000\"/>\n    <stop offset=\"31.25%\" stop-color=\"rgb(156,238,255)\" stop-opacity=\"1.0000\"/>\n    <stop offset=\"37.50%\" stop-color=\"rgb(156,238,255)\" stop-opacity=\"1.0000\"/>\n    <stop offset=\"37.50%\" stop-color=\"rgb(175,245,255)\" stop-opacity=\"1.0000\"/>\n    <stop offset=\"43.75%\" stop-color=\"rgb(175,245,255)\" stop-opacity=\"1.0000\"/>\n    <stop offset=\"43.75%\" stop-color=\"rgb(206,255,255)\" stop-opacity=\"1.0000\"/>\n    <stop offset=\"50.00%\" stop-color=\"rgb(206,255,255)\" stop-opacity=\"1.0000\"/>\n    <stop offset=\"50.00%\" stop-color=\"rgb(255,254,71)\" stop-opacity=\"1.0000\"/>\n    <stop offset=\"56.25%\" stop-color=\"rgb(255,254,71)\" stop-opacity=\"1.0000\"/>\n    <stop offset=\"56.25%\" stop-color=\"rgb(255,235,0)\" stop-opacity=\"1.0000\"/>\n    <stop offset=\"62.50%\" stop-color=\"rgb(255,235,0)\" stop-opacity=\"1.0000\"/>\n    <stop offset=\"62.50%\" stop-color=\"rgb(255,196,0)\" stop-opacity=\"1.0000\"/>\n    <stop offset=\"68.75%\" stop-color=\"rgb(255,196,0)\" stop-opacity=\"1.0000\"/>\n    <stop offset=\"68.75%\" stop-color=\"rgb(255,144,0)\" stop-opacity=\"1.0000\"/>\n    <stop offset=\"75.00%\" stop-color=\"rgb(255,144,0)\" stop-opacity=\"1.0000\"/>\n    <stop offset=\"75.00%\" stop-color=\"rgb(255,72,0)\" stop-opacity=\"1.0000\"/>\n    <stop offset=\"81.25%\" stop-color=\"rgb(255,72,0)\" stop-opacity=\"1.0000\"/>\n    <stop offset=\"81.25%\" stop-color=\"rgb(255,0,0)\" stop-opacity=\"1.0000\"/>\n    <stop offset=\"87.50%\" stop-color=\"rgb(255,0,0)\" stop-opacity=\"1.0000\"/>\n    <stop offset=\"87.50%\" stop-color=\"rgb(213,0,0)\" stop-opacity=\"1.0000\"/>\n    <stop offset=\"93.75%\" stop-color=\"rgb(213,0,0)\" stop-opacity=\"1.0000\"/>\n    <stop offset=\"93.75%\" stop-color=\"rgb(158,0,0)\" stop-opacity=\"1.0000\"/>\n    <stop offset=\"100.00%\" stop-color=\"rgb(158,0,0)\" stop-opacity=\"1.0000\"/>\n</linearGradient>\n

                                                                Which should be rendered like this:

                                                              • Lines 24 supplies the minimum parameter which is determined through a FilterFunction which takes the minimum value from the GridCoverage statistics,

                                                              • Lines 25 supplies the maximum parameter which is determined through a FilterFunction which takes the maximum value from the GridCoverage statistics,

                                                                The resulting image may look like this (you may note the STEPs across colors due to color intervals):

                                                                Using an GMT_drywet SVG, the resulting image may look like this, which uses a smoother color ramp:

                                                              Alternatively, a ColorMap may be specified this way:

                                                              ..........\n           <ogc:Function name=\"ras:DynamicColorMap\">\n             <ogc:Function name=\"parameter\">\n               <ogc:Literal>data</ogc:Literal>\n             </ogc:Function>\n             <ogc:Function name=\"parameter\">\n               <ogc:Literal>colorRamp</ogc:Literal>\n               <ogc:Function name=\"colormap\">\n                 <ogc:Literal>#0000FF;#00FF00;#FF0000</ogc:Literal>\n                 <ogc:Function name=\"gridCoverageStats\"><ogc:Literal>minimum</ogc:Literal></ogc:Function>\n                 <ogc:Function name=\"gridCoverageStats\"><ogc:Literal>maximum</ogc:Literal></ogc:Function>\n               </ogc:Function>\n             </ogc:Function>\n           </ogc:Function>\n...........\n

                                                              or

                                                              ..........\n           <ogc:Function name=\"ras:DynamicColorMap\">\n             <ogc:Function name=\"parameter\">\n               <ogc:Literal>data</ogc:Literal>\n             </ogc:Function>\n             <ogc:Function name=\"parameter\">\n               <ogc:Literal>colorRamp</ogc:Literal>\n               <ogc:Function name=\"colormap\">\n                 <ogc:Literal>rgb(0,0,255);rgb(0,255,0);rgb(255,0,0)</ogc:Literal>\n                 <ogc:Function name=\"gridCoverageStats\"><ogc:Literal>minimum</ogc:Literal></ogc:Function>\n                 <ogc:Function name=\"gridCoverageStats\"><ogc:Literal>maximum</ogc:Literal></ogc:Function>\n               </ogc:Function>\n             </ogc:Function>\n           </ogc:Function>\n...........\n

                                                              In these cases a RAMP will be used with the indicated colors.

                                                              The resulting image may look like this:

                                                              "},{"location":"community/colormap/#dynamiccolormap-requirements","title":"DynamicColorMap Requirements","text":"
                                                              • A preliminar gdalinfo -stats command needs to be run against the coverages in order to create the PAM Auxiliary file containing statistics and metadata.
                                                              • In order to setup colorMap from QuantumGIS, you should have copied the QuantumGIS SVG resources folder from apps/qgis/resources/cpt-city-XXXXX within the GEOSERVER_DATA_DIR as a styles/ramps subfolder.
                                                              • The underlying reader should support statistics retrieval by adding a PAMDataset object as a property of the returned coverage. For this reason the user should take care of setting the CheckAuxiliaryMetadata flag to true inside the indexer.properties or update the .properties file generated by GeoServer with that flag in case of already configured stores (You also need to reload the configuration in that case).
                                                              "},{"location":"community/cov-json/","title":"CoverageJSON output format","text":"

                                                              CoverageJSON is a format for encoding geotemporal coverage data like grids and time series. For example, it can be as output format for a WCS2.0 getCoverage requesting a TimeSeries on a specific coordinate. As per the specification, the format to be specified to get back a cov-json output is application/prs.coverage+json.

                                                              "},{"location":"community/cov-json/#installation","title":"Installation","text":"

                                                              As a community module, the cov-json package needs to be downloaded from the nightly builds, picking the community folder of the corresponding GeoServer series (e.g. if working on the GeoServer main development branch nightly builds, pick the zip file form main/community-latest).

                                                              To install the module, unpack the zip file contents into GeoServer own WEB-INF/lib directory and restart GeoServer.

                                                              "},{"location":"community/cov-json/#example-wcs-20-timeseries","title":"Example: WCS 2.0 - TimeSeries","text":"

                                                              Let test:timeseries be a sample layer related to a coverage with time dimensions enabled. Suppose we want to get the coverage values for a specific time period on a specific lat/lon coordinate. That will be a slicing on lat/lon coordinate and trimming on time dimension.

                                                              A getCoverage request can be posted with a similar content to http://server:port/geoserver/wcs:

                                                              <wcs:GetCoverage service=\"WCS\" version=\"2.0.1\"\nxmlns:wcs=\"http://www.opengis.net/wcs/2.0\"\nxmlns:gml=\"http://www.opengis.net/gml/3.2\" \nxmlns:crs=\"http://www.opengis.net/spec/WCS_service-extension_crs/1.0\"\nxmlns:rsub=\"http://www.opengis.net/spec/wcs_service-extension_range-subsetting/1.0\"\nxmlns:scal=\"http://www.opengis.net/spec/WCS_service-extension_scaling/1.0/\"\nxmlns:wcsgeotiff=\"http://www.opengis.net/wcs/geotiff/1.0\"\nxmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\"\nxsi:schemaLocation=\"http://www.opengis.net/wcs/2.0 http://schemas.opengis.net/wcs/2.0/wcsAll.xsd\">\n\n  <wcs:CoverageId>test__timeseries</wcs:CoverageId>\n  <wcs:format>application/prs.coverage+json</wcs:format>\n  <wcs:DimensionSlice>\n    <wcs:Dimension>Long</wcs:Dimension>\n    <wcs:SlicePoint>56</wcs:SlicePoint>\n  </wcs:DimensionSlice>\n  <wcs:DimensionSlice>\n    <wcs:Dimension>Lat</wcs:Dimension>\n    <wcs:SlicePoint>0</wcs:SlicePoint>\n  </wcs:DimensionSlice>\n  <wcs:DimensionTrim>\n    <wcs:Dimension>Time</wcs:Dimension>\n    <wcs:TrimLow>2014-01-01T00:00:00.000Z</wcs:TrimLow>\n    <wcs:TrimHigh>2017-01-01T00:00:00.000Z</wcs:TrimHigh>\n  </wcs:DimensionTrim>\n</wcs:GetCoverage>\n

                                                              The outcome will be something like this:

                                                              {\n  \"type\": \"Coverage\",\n  \"domain\": {\n  \"type\": \"Domain\",\n  \"domainType\": \"PointSeries\",\n  \"axes\": {\n    \"x\": {\n    \"values\": [\n      56.0\n    ]\n    },\n    \"y\": {\n    \"values\": [\n      1.0112359550561785\n    ]\n    },\n    \"t\": {\n    \"values\": [\n      \"2014-01-01T00:00:00Z\",\n      \"2015-01-01T00:00:00Z\",\n      \"2016-01-01T00:00:00Z\",\n      \"2017-01-01T00:00:00Z\"\n    ]\n    }\n  },\n  \"referencing\": [\n    {\n    \"coordinates\": [\n      \"x\",\n      \"y\"\n    ],\n    \"system\": {\n      \"type\": \"GeographicCRS\",\n      \"id\": \"http://www.opengis.net/def/crs/EPSG/0/4326\"\n    }\n    },\n    {\n    \"coordinates\": [\n      \"t\"\n    ],\n    \"system\": {\n      \"type\": \"TemporalRS\",\n      \"calendar\": \"Gregorian\"\n    }\n    }\n  ]\n  },\n  \"parameters\": {\n  \"TIMESERIES\": {\n    \"type\": \"Parameter\",\n    \"description\": {\n    \"en\": \"timeseries\"\n    },\n    \"observedProperty\": {\n    \"label\": {\n      \"en\": \"timeseries\"\n    }\n    }\n  }\n  },\n  \"ranges\": {\n  \"TIMESERIES\": {\n    \"type\": \"NdArray\",\n    \"dataType\": \"float\",\n    \"axisNames\": [\n    \"t\",\n    \"y\",\n    \"x\"\n    ],\n    \"shape\": [\n    4,\n    1,\n    1\n    ],\n    \"values\": [\n    25.5,\n    24.76,\n    26.06,\n    23.22\n    ]\n  }\n  }\n}\n

                                                              Note the domainType = PointSeries where x,y axes have a single and the t axis has 4 times in the values. Also note the ranges property is reporting 4 values.

                                                              "},{"location":"community/dds/","title":"DDS/BIL(World Wind Data Formats) Extension","text":"

                                                              This output module allows GeoServer to output imagery and terrain in formats understood by NASA World Wind. The mime-types supported are:

                                                              1. Direct Draw Surface (DDS) - image/dds. This format allows efficient loading of textures to the GPU and takes the task off the WorldWind client CPU in converting downloaded PNG, JPEG or TIFF tiles. The DDS compression is done using DXT3 with help from the worldwind library on server side.
                                                              2. Binary Interleaved by Line(BIL) - image/bil. This is actually a very simple raw binary format produced using the RAW Image Writer. The supplied GridCoverage2D undergoes appropriate subsampling, reprojection and bit-depth conversion. The output can be requested as 16bit Int or 32bit Float.
                                                              "},{"location":"community/dds/#installing-the-ddsbil-extension","title":"Installing the DDS/BIL extension","text":"
                                                              1. Download the DDS/BIL extension from the nightly GeoServer community module builds. A prebuilt version for GeoServer 2.0.x can be found on Jira - GEOS-3586.

                                                                Warning

                                                                Make sure to match the version of the extension to the version of the GeoServer instance!

                                                              2. Extract the contents of the archive into the WEB-INF/lib directory of the GeoServer installation.

                                                              "},{"location":"community/dds/#checking-if-the-extension-is-enabled","title":"Checking if the extension is enabled","text":"

                                                              Once the extension is installed, the provided mime-types should appear in the layer preview dropbox as shown:

                                                              The mime-types will also be listed in the GetCapabilities document:

                                                              <Format>image/bil</Format>\n<Format>image/dds</Format>\n
                                                              "},{"location":"community/dds/#configuring-the-bil-format","title":"Configuring the BIL format","text":"

                                                              For a client application to use a BIL layer, it must know the data encoding of the BIL file (e.g. 16-bit integer, 32-bit floating point, etc), the byte order of the data, and the value that indicates missing data. BIL files do not contain this metadata, so it may be necessary to configure the server to produce BIL files in the format that a client application expects.

                                                              The BIL output format can be configured for each layer in the Publishing tab of the layer configuration. The plugin supports the following options:

                                                              Option Description Default encoding The data encoding to use if the request does not specify an encoding. For example, application/bil does not specify the response encoding, while application/bil16 does specify an encoding. Default: use same encoding as layer source files. Byte order Byte order of the response. Default: network byte order (big endian). No Data value The value that indicates missing data. If this option is set, missing data values will be recoded to this value. Default: no data translation.

                                                              For compatibility with the default behavior of NASA World Wind, use these settings:

                                                              • Default encoding: application/bil16
                                                              • Byte order: Little endian
                                                              • No data: -9999
                                                              "},{"location":"community/dds/#configuring-world-wind-to-access-imageryterrain-from-geoserver","title":"Configuring World Wind to access Imagery/Terrain from GeoServer","text":"

                                                              Please refer to the WorldWind Forums for instructions on how to setup World Wind to work with layers published via GeoServer. For image layers(DDS) the user need to create a WMSTiledImageLayer either via XML configuration or programmatically. For terrain layers (BIL) the equivalent class is WMSBasicElevationModel.

                                                              "},{"location":"community/elasticsearch/","title":"Elasticsearch data store","text":"

                                                              Elasticsearch is a popular distributed search and analytics engine that enables complex search features in near real-time. Default field type mappings support string, numeric, boolean and date types and allow complex, hierarchical documents. Custom field type mappings can be defined for geospatial document fields. The geo_point type supports point geometries that can be specified through a coordinate string, geohash or coordinate array. The geo_shape type supports Point, LineString, Polygon, MultiPoint, MultiLineString, MultiPolygon and GeometryCollection GeoJSON types as well as envelope and circle types. Custom options allow configuration of the type and precision of the spatial index.

                                                              This data store allows features from an Elasticsearch index to be published through GeoServer. Both geo_point and geo_shape type mappings are supported. OGC filters are converted to Elasticsearch queries and can be combined with native Elasticsearch queries in WMS and WFS requests.

                                                              "},{"location":"community/elasticsearch/#configuration","title":"Configuration","text":""},{"location":"community/elasticsearch/#config_elasticsearch","title":"Configuring data store","text":"

                                                              Once the Elasticsearch GeoServer extension is installed, Elasticsearch index will be an available vector data source format when creating a new data store.

                                                              The Elasticsearch data store configuration panel includes connection parameters and search settings.

                                                              Available data store configuration parameters are summarized in the following table:

                                                              +--------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Parameter | Description | +--------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------+ | elasticsearch_host | Host (IP) for connecting to Elasticsearch. HTTP scheme and port can optionally be included to override the defaults. Multiple hosts can be provided. Examples: | | | | | | localhost | | | localhost:9200 | | | http://localhost | | | http://localhost:9200 | | | https://localhost:9200 | | | https://somehost.somedomain:9200,https://anotherhost.somedomain:9200 | +--------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------+ | elasticsearch_port | Default HTTP port for connecting to Elasticsearch. Ignored if the hostname includes the port. | +--------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------+ | user | Elasticsearch user. Must have superuser privilege on index. | +--------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------+ | passwd | Elasticsearch user password | +--------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------+ | runas_geoserver_user | Whether to submit requests on behalf of the authenticated GeoServer user | +--------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------+ | proxy_user | Elasticsearch user for document queries. If not provided then admin user credentials are used for all requests. | +--------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------+ | proxy_passwd | Elasticsearch proxy user password | +--------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------+ | index_name | Index name or alias (wildcards supported) | +--------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------+ | reject_unauthorized | Whether to validate the server certificate during the SSL handshake for https connections | +--------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------+ | default_max_features | Default used when maxFeatures is unlimited | +--------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------+ | source_filtering_enabled | Whether to enable filtering of the _source field | +--------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------+ | scroll_enabled | Enable the Elasticsearch scan and scroll API | +--------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------+ | scroll_size | Number of documents per shard when using the scroll API | +--------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------+ | scroll_time | Search context timeout when using the scroll API | +--------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------+ | array_encoding | Array encoding strategy. Allowed values are JSON (keep arrays) and CSV (keep first array element). | +--------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------+ | grid_size | Hint for Geohash grid size (numRows*numCols) | +--------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------+ | grid_threshold | Geohash grid aggregation precision will be the minimum necessary so that actual_grid_size/grid_size > grid_threshold | +--------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------+ | response_buffer_limit | Maximum number of bytes to buffer in memory when reading responses from Elasticsearch | +--------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------+

                                                              "},{"location":"community/elasticsearch/#configuring-authentication","title":"Configuring authentication","text":"

                                                              Basic authentication is supported through the user and passwd credential parameters. The provided user must have superuser privilege on the index to enable the mapping and alias requests performed during store initialization. Note that aliases must already be present on the Elasticsearch index. If you enter an alias which is not present, the plugin will not generate it for you. Optional proxy_user and proxy_passwd parameters can be used to specify an alternate user for document search (OGC service) requests. The proxy user can have restricted privileges on the index through document level security. If not provided the default user is used for all requests.

                                                              The runas_geoserver_user flag can be used to enable Elasticsearch requests to be submitted on behalf of the authenticated GeoServer user. When the run-as mechanism is configured the plugin will add the es-security-runas-user header with the authenticated GeoServer username. See X-Pack run-as documentation for more information. Note the run-as mechanism is applied only to document search requests.

                                                              For added security it is recommended to define proxy_user and proxy_passwd when using the run-as mechanism. The proxy user will be used when submitting requests on behalf of the GeoServer user and can have restricted privileges enabling access only to documents that all users can have access to. The plugin can optionally be deployed to require user credentials and proxy credentials and to force the use of runas_geoserver_user by setting the environment variable org.geoserver.elasticsearch.xpack.force-runas:

                                                              $ export JAVA_OPTS=\"-Dorg.geoserver.elasticsearch.xpack.force-runas $JAVA_OPTS\"\n
                                                              "},{"location":"community/elasticsearch/#configuring-httpsssl","title":"Configuring HTTPS/SSL","text":"

                                                              System properties are supported for SSL/TLS configuration:

                                                              javax.net.ssl.trustStore\njavax.net.ssl.trustStorePassword\njavax.net.ssl.keyStore\njavax.net.ssl.keyStorePassword\n

                                                              See HttpClientBuilder documentation for available properties.

                                                              For example, use javax.net.ssl.trustStore[Password] to validate server certificate:

                                                              $ export JAVA_OPTS=\"-Djavax.net.ssl.trustStore=/path/to/truststore.jks -Djavax.net.ssl.trustStorePassword=changeme $JAVA_OPTS \"\n
                                                              "},{"location":"community/elasticsearch/#configuring-layer","title":"Configuring layer","text":"

                                                              The initial layer configuration panel for an Elasticsearch layer will include an additional pop-up showing a table of available fields.

                                                              Item Description Use All Use all fields in the layer feature type Use Used to select the fields that will make up the layer feature type Name Name of the field Type Type of the field, as derived from the Elasticsearch schema. For geometry types, you have the option to provide a more specific data type. Order Integer order values are used to sort fields, where fields with smaller order are returned first Custom Name Provides the option to give the field a custom name Default Geometry Indicates if the geometry field is the default one. Useful if the documents contain more than one geometry field, as SLDs and spatial filters will hit the default geometry field unless otherwise specified Stored Indicates whether the field is stored in the index Analyzed Indicates whether the field is analyzed SRID Native spatial reference ID of the geometries. Currently only EPSG:4326 is supported. Valid Date Formats Possible valid date formats used for parsing field values and printing filter elements Refresh If the field mappings or Elasticsearch schema has changed since this page was loaded, use this button to update the field configuration list.

                                                              To return to the field table after it has been closed, click the \"Configure Elasticsearch fields\" button below the \"Feature Type Details\" panel on the layer configuration page.

                                                              "},{"location":"community/elasticsearch/#configuring-logging","title":"Configuring logging","text":"

                                                              Logging is configurable through Log4j. The data store includes logging such as the query object being sent to Elasticsearch, which is logged at a lower level than may be enabled by default. To enable these logs, add the following lines to the GeoServer logging configuration file (see GeoServer Global Settings):

                                                              log4j.category.org.geoserver.data.elasticsearch=DEBUG \nlog4j.category.org.geoserver.process.elasticsearch=DEBUG\n

                                                              The logging configuration file will be in the logs subdirectory in the GeoServer data directory. Check GeoServer global settings for which logging profile is being used (e.g. DEFAULT_LOGGING, etc.).

                                                              "},{"location":"community/elasticsearch/#filtering","title":"Filtering","text":"

                                                              Filtering capabilities include OpenGIS simple comparisons, temporal comparisons, as well as other common filter comparisons. Elasticsearch natively supports numerous spatial filter operators, depending on the type:

                                                              • geo_shape types natively support BBOX/Intersects, Within and Disjoint binary spatial operators
                                                              • geo_point types natively support BBOX and Within binary spatial operators, as well as the DWithin and Beyond distance buffer operators

                                                              Requests involving spatial filter operators not natively supported by Elasticsearch will include an additional filtering operation on the results returned from the query, which may impact performance.

                                                              "},{"location":"community/elasticsearch/#native-queries","title":"Native queries","text":"

                                                              Native Elasticsearch queries can be applied in WMS feature requests through a custom rendering transformation, vec:GeoHashGrid, which translates aggregation response data into a raster for display. If supplied, the query is combined with the query derived from the request bbox, CQL or OGC filter using the AND logical binary operator.

                                                              "},{"location":"community/elasticsearch/#examples","title":"Examples","text":"

                                                              BBOX and CQL filter:

                                                              http://localhost:8080/geoserver/test/wms?service=WMS&version=1.1.0&request=GetMap\n     &layers=test:active&styles=&bbox=-1,-1,10,10&width=279&height=512\n     &srs=EPSG:4326&format=application/openlayers&maxFeatures=1000\n     &cql_filter=standard_ss='IEEE 802.11b'\n

                                                              BBOX and native query:

                                                              http://localhost:8080/geoserver/test/wms?service=WMS&version=1.1.0&request=GetMap\n     &layers=test:active&styles=NativeQueryStyle&bbox=-1,-1,10,10&width=279&height=512\n     &srs=EPSG:4326&format=application/openlayers&maxFeatures=1000\n\n\n<StyledLayerDescriptor version=\"1.0.0\"\n   xsi:schemaLocation=\"http://www.opengis.net/sld StyledLayerDescriptor.xsd\"\n   xmlns=\"http://www.opengis.net/sld\"\n   xmlns:ogc=\"http://www.opengis.net/ogc\"\n   xmlns:xlink=\"http://www.w3.org/1999/xlink\"\n   xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\">\n <NamedLayer>\n   <Name>test</Name>\n   <UserStyle>\n     <Title>Test</Title>\n     <Abstract>Test Native Query</Abstract>\n     <FeatureTypeStyle>\n       <Transformation>\n         <ogc:Function name=\"vec:GeoHashGrid\">\n           <ogc:Function name=\"parameter\">\n             <ogc:Literal>data</ogc:Literal>\n           </ogc:Function>\n           <ogc:Function name=\"parameter\">\n             <ogc:Literal>queryDefinition</ogc:Literal>\n             <ogc:Literal>{\"term\":{\"standard_ss\":\"IEEE 802.11b\"}}\n           </ogc:Function>\n           <ogc:Function name=\"parameter\">\n             <ogc:Literal>outputBBOX</ogc:Literal>\n             <ogc:Function name=\"env\">\n               <ogc:Literal>wms_bbox</ogc:Literal>\n             </ogc:Function>\n           </ogc:Function>\n           <ogc:Function name=\"parameter\">\n             <ogc:Literal>outputWidth</ogc:Literal>\n             <ogc:Function name=\"env\">\n               <ogc:Literal>wms_width</ogc:Literal>\n             </ogc:Function>\n           </ogc:Function>\n           <ogc:Function name=\"parameter\">\n             <ogc:Literal>outputHeight</ogc:Literal>\n             <ogc:Function name=\"env\">\n               <ogc:Literal>wms_height</ogc:Literal>\n             </ogc:Function>\n           </ogc:Function>\n         </ogc:Function>\n       </Transformation>\n       <Rule>\n        <RasterSymbolizer>\n          <Geometry>\n            <!-- Actual geometry property name in feature source -->\n            <ogc:PropertyName>geo</ogc:PropertyName></Geometry>\n          <Opacity>0.6</Opacity>\n          <ColorMap type=\"ramp\" >\n            <ColorMapEntry color=\"#FFFFFF\" quantity=\"0\" label=\"nodata\" opacity=\"0\"/>\n            <ColorMapEntry color=\"#2851CC\" quantity=\"1\" label=\"values\"/>\n            <ColorMapEntry color=\"#211F1F\" quantity=\"2\" label=\"label\"/>\n            <ColorMapEntry color=\"#EE0F0F\" quantity=\"3\" label=\"label\"/>\n            <ColorMapEntry color=\"#AAAAAA\" quantity=\"4\" label=\"label\"/>\n            <ColorMapEntry color=\"#6FEE4F\" quantity=\"5\" label=\"label\"/>\n            <ColorMapEntry color=\"#DDB02C\" quantity=\"10\" label=\"label\"/>\n          </ColorMap>\n        </RasterSymbolizer>\n       </Rule>\n     </FeatureTypeStyle>\n   </UserStyle>\n </NamedLayer>\n</StyledLayerDescriptor>\n
                                                              "},{"location":"community/elasticsearch/#aggregations","title":"Aggregations","text":"

                                                              Elasticsearch aggregations are supported through WMS requests by including the query in WMS requests through a custom rendering transformation, vec:GeoHashGrid, which translates aggregation response data into a raster for display.

                                                              Note that size is set to zero when an aggregation is supplied so only aggregation features are returned (e.g. maxFeatures is ignored and there will be no search hit results). See FAQ for common issues using aggregations.

                                                              "},{"location":"community/elasticsearch/#geohash-grid-aggregations","title":"Geohash grid aggregations","text":"

                                                              Geohash grid aggregation support includes dynamic precision updating and a custom rendering transformation for visualization. Geohash grid aggregation precision is updated dynamically to approximate the specified grid_size based on current bbox extent and the additional grid_threshold parameter as described above.

                                                              Geohash grid aggregation visualization is supported in WMS requests through a custom rendering transformation, vec:GeoHashGrid, which translates aggregation response data into a raster for display. By default, raster values correspond to the aggregation bucket doc_count. The following shows an example GeoServer style that uses the GeoHashGrid rendering transformation:

                                                              <StyledLayerDescriptor version=\"1.0.0\"\n    xsi:schemaLocation=\"http://www.opengis.net/sld StyledLayerDescriptor.xsd\"\n    xmlns=\"http://www.opengis.net/sld\"\n    xmlns:ogc=\"http://www.opengis.net/ogc\"\n    xmlns:xlink=\"http://www.w3.org/1999/xlink\"\n    xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\">\n  <NamedLayer>\n    <Name>GeoHashGrid</Name>\n    <UserStyle>\n      <Title>GeoHashGrid</Title>\n      <Abstract>GeoHashGrid aggregation</Abstract>\n      <FeatureTypeStyle>\n        <Transformation>\n          <ogc:Function name=\"vec:GeoHashGrid\">\n            <ogc:Function name=\"parameter\">\n              <ogc:Literal>data</ogc:Literal>\n            </ogc:Function>\n            <ogc:Function name=\"parameter\">\n              <ogc:Literal>gridStrategy</ogc:Literal>\n              <ogc:Literal>Basic</ogc:Literal>\n            </ogc:Function>\n            <ogc:Function name=\"parameter\">\n              <ogc:Literal>outputBBOX</ogc:Literal>\n              <ogc:Function name=\"env\">\n                <ogc:Literal>wms_bbox</ogc:Literal>\n              </ogc:Function>\n            </ogc:Function>\n            <ogc:Function name=\"parameter\">\n              <ogc:Literal>outputWidth</ogc:Literal>\n              <ogc:Function name=\"env\">\n                <ogc:Literal>wms_width</ogc:Literal>\n              </ogc:Function>\n            </ogc:Function>\n            <ogc:Function name=\"parameter\">\n              <ogc:Literal>outputHeight</ogc:Literal>\n              <ogc:Function name=\"env\">\n                <ogc:Literal>wms_height</ogc:Literal>\n              </ogc:Function>\n            </ogc:Function>\n          </ogc:Function>\n        </Transformation>\n        <Rule>\n         <RasterSymbolizer>\n           <Geometry>\n             <!-- Actual geometry property name in feature source -->\n             <ogc:PropertyName>geo</ogc:PropertyName></Geometry>\n           <Opacity>0.6</Opacity>\n           <ColorMap type=\"ramp\" >\n             <ColorMapEntry color=\"#FFFFFF\" quantity=\"0\" label=\"nodata\" opacity=\"0\"/>\n             <ColorMapEntry color=\"#2851CC\" quantity=\"1\" label=\"values\"/>\n             <ColorMapEntry color=\"#211F1F\" quantity=\"2\" label=\"label\"/>\n             <ColorMapEntry color=\"#EE0F0F\" quantity=\"3\" label=\"label\"/>\n             <ColorMapEntry color=\"#AAAAAA\" quantity=\"4\" label=\"label\"/>\n             <ColorMapEntry color=\"#6FEE4F\" quantity=\"5\" label=\"label\"/>\n             <ColorMapEntry color=\"#DDB02C\" quantity=\"10\" label=\"label\"/>\n           </ColorMap>\n         </RasterSymbolizer>\n        </Rule>\n      </FeatureTypeStyle>\n    </UserStyle>\n  </NamedLayer>\n </StyledLayerDescriptor>\n

                                                              Example WMS request including Geohash grid aggregation with the above custom style:

                                                              http://localhost:8080/geoserver/test/wms?service=WMS&version=1.1.0&request=GetMap\n     &layers=test:active&styles=geohashgrid&bbox=0.0,0.0,24.0,44.0&srs=EPSG:4326\n     &width=418&height=768&format=application/openlayers\n

                                                              The Elasticsearch aggregation definition can be computed automatically, or provided as an explicit parameter, for example:

                                                              <ogc:Function name=\"parameter\">\n  <ogc:Literal>aggregationDefinition</ogc:Literal>\n  <ogc:Literal>{\"agg\": {\"geohash_grid\": {\"field\": \"_ogr_geometry_.coordinates\", \"precision\": 3}}}</ogc:Literal>\n</ogc:Function>\n

                                                              The store may update the precision to a smaller value, if it finds it goes beyond the aggregation limits setup in its configuration, see grid_size and grid_threshold above.

                                                              "},{"location":"community/elasticsearch/#grid-strategy","title":"Grid Strategy","text":"

                                                              gridStrategy: Parameter to identify the org.geoserver.process.elasticsearch.GeoHashGrid implementation that will be used to convert each geohashgrid bucket into a raster value (number).

                                                              Name gridStrategy gridStrategyArgs Description Basic basic no Raster value is geohashgrid bucket doc_count. Metric metric yes Raster value is geohashgrid bucket metric value. Nested nested_agg yes Extract raster value from nested aggregation results.

                                                              gridStrategyArgs: (Optional) Parameter used to specify an optional argument list for the grid strategy.

                                                              emptyCellValue: (Optional) Parameter used to specify the value for empty grid cells. By default, empty grid cells are set to 0.

                                                              scaleMin, scaleMax: (Optional) Parameters used to specify a scale applied to all raster values. Each tile request is scaled according to the min and max values for that tile. It is best to use a non-tiled layer with this parameter to avoid confusing results.

                                                              useLog: (Optional) Flag indicating whether to apply logarithm to raster values (applied prior to scaling, if applicable)

                                                              "},{"location":"community/elasticsearch/#basic","title":"Basic","text":"

                                                              Raster value is geohashgrid bucket doc_count.

                                                              Example Aggregation:

                                                              {\n  \"agg\": {\n    \"geohash_grid\": {\n      \"field\": \"geo\"\n    }\n  }\n}\n

                                                              Example bucket:

                                                              {\n  \"key\" : \"xv\",\n  \"doc_count\" : 1\n}\n

                                                              Extracted raster value: 1

                                                              "},{"location":"community/elasticsearch/#metric","title":"Metric","text":"

                                                              Raster value is geohashgrid bucket metric value.

                                                              Argument Index Default Value Description 0 metric Key used to pluck metric object from top level bucket. Empty string results in plucking doc_count. 1 value Key used to pluck the value from the metric object.

                                                              Example Aggregation:

                                                              {\n  \"agg\": {\n    \"geohash_grid\": {\n      \"field\": \"geo\"\n    },\n    \"aggs\": {\n      \"metric\": {\n        \"max\": {\n          \"field\": \"magnitude\"\n        }\n      }\n    }\n  }\n}\n

                                                              Example bucket:

                                                              {\n  \"key\" : \"xv\",\n  \"doc_count\" : 1,\n  \"metric\" : {\n    \"value\" : 4.9\n  }\n}\n

                                                              Extracted raster value: 4.9

                                                              "},{"location":"community/elasticsearch/#nested","title":"Nested","text":"

                                                              Extract raster value from nested aggregation results.

                                                              Argument Index Default Value Description 0 nested Key used to pluck nested aggregation results from the geogrid bucket. 1 empty string Key used to pluck metric object from each nested aggregation bucket. Empty string results in plucking doc_count. 2 value Key used to pluck the value from the metric object. 3 largest largest 4 value key 5 null (Optional) Map used to convert String keys into numeric values. Use the format key1:1;key2:2. Only utilized when raster strategy is key.

                                                              Example Aggregation:

                                                              {\n  \"agg\": {\n    \"geohash_grid\": {\n      \"field\": \"geo\"\n    },\n    \"aggs\": {\n      \"nested\": {\n        \"histogram\": {\n          \"field\": \"magnitude\",\n          \"interval\": 1,\n          \"min_doc_count\": 1\n        }\n      }\n    }\n  }\n}\n

                                                              Example Parameters:

                                                              <ogc:Function name=\"parameter\">\n  <ogc:Literal>gridStrategyArgs</ogc:Literal>\n  <ogc:Literal>nested</ogc:Literal>\n  <ogc:Literal></ogc:Literal>\n  <ogc:Literal></ogc:Literal>\n  <ogc:Literal>largest</ogc:Literal>\n  <ogc:Literal>key</ogc:Literal>\n</ogc:Function>\n

                                                              Example bucket:

                                                              {\n  \"key\" : \"xv\",\n  \"doc_count\" : 1729,\n  \"nested\" : {\n    \"buckets\" : [\n      {\n        \"key\" : 2.0,\n        \"doc_count\" : 5\n      },\n      {\n        \"key\" : 3.0,\n        \"doc_count\" : 107\n      },\n      {\n        \"key\" : 4.0,\n        \"doc_count\" : 1506\n      },\n      {\n        \"key\" : 5.0,\n        \"doc_count\" : 100\n      },\n      {\n        \"key\" : 6.0,\n        \"doc_count\" : 11\n      }\n    ]\n  }\n}\n

                                                              Extracted raster value: 4.0

                                                              "},{"location":"community/elasticsearch/#implementing-a-custom-grid-strategy","title":"Implementing a custom Grid Strategy","text":"

                                                              By default the raster values computed in the geohash grid aggregation rendering transformation correspond to the top level doc_count. Adding an additional strategy for computing the raster values from bucket data currently requires source code updates to the gt-elasticsearch-process module as described below.

                                                              First create a custom implementation of org.geoserver.process.elasticsearch.GeoHashGrid and provide an implementation of the computeCellValue method, which takes the raw bucket data and returns the raster value. For example, the default basic implementation simply returns the doc_count:

                                                              public class BasicGeoHashGrid extends GeoHashGrid {\n    @Override\n    public Number computeCellValue(Map<String,Object> bucket) {\n        return (Number) bucket.get(\"doc_count\");\n    }\n}\n

                                                              Then update org.geoserver.process.elasticsearch.GeoHashGridProcess and add a new entry to the Strategy enum to point to the custom implementation.

                                                              After deploying the customized plugin, the new geohash grid computer can be used by updating the gridStrategy parameter in the GeoServer style:

                                                              <StyledLayerDescriptor version=\"1.0.0\"\n    ...\n        <Transformation>\n          <ogc:Function name=\"vec:GeoHashGrid\">\n            ...\n            <ogc:Function name=\"parameter\">\n              <ogc:Literal>gridStrategy</ogc:Literal>\n              <ogc:Literal>NewName</ogc:Literal>\n            </ogc:Function>\n
                                                              "},{"location":"community/elasticsearch/#FAQ","title":"FAQ","text":"
                                                              • By default, arrays are returned directly, which is suitable for many output formats including GeoJSON. When using CSV output format with layers containing arrays it's necessary to set the array_encoding store parameter to CSV. Note however when using the CSV array encoding that only the first value will be returned.
                                                              • When updating from pre-2.11.0 versions of the plugin it may be necessary to reload older layers to enable full aggregation and time support. Missing aggregation data or errors of the form IllegalArgumentException: Illegal pattern component indicate a layer reload is necessary. In this case the layer must be removed and re-added to GeoServer (e.g. a feature type reload will not be sufficient).
                                                              • Commas in the native query and aggregation body must be escaped with a backslash. Additionally, body may need to be URL encoded.
                                                              • Geometry property name in the aggregation SLD RasterSymbolizer must be a valid geometry property in the layer
                                                              • PropertyIsEqualTo maps to an Elasticsearch term query, which will return documents that contain the supplied term. When searching on an analyzed string field, ensure that the search values are consistent with the analyzer used in the index. For example, values may need to be lowercase when querying fields analyzed with the default analyzer. See the Elasticsearch term query documentation for more information.
                                                              • PropertyIsLike maps to either a query string query or a regexp query, depending on whether the field is analyzed or not. Reserved characters should be escaped as applicable. Note case sensitive and insensitive searches may not be supported for analyzed and not analyzed fields, respectively. See Elasticsearch query string and regexp query documentation for more information.
                                                              • Date conversions are handled using the valid date formats from the associated type mapping, or date_optional_time if not found. Note that UTC timezone is used for both parsing and printing of dates.
                                                              • Filtering on Elasticsearch object types is supported. By default, field names will include the full path to the field (e.g. \"parent.child.field_name\"), but this can be changed in the GeoServer layer configuration.
                                                                • When referencing fields with path elements using cql_filter, it may be necessary to quote the name (e.g. cql_filter=\"parent.child.field_name\"='value')
                                                              • Filtering on Elasticsearch nested types is supported only for non-geospatial fields.
                                                              • Circle geometries are approximate and may not be fully consistent with the implementation in Elasticsearch, especially at extreme latitudes (see #86).
                                                              • The joda-shaded module may need to be excluded when importing the project into Eclipse. Otherwise modules may have build errors of the form DateTimeFormatter cannot be resolved to a type.
                                                              • When updating from Elasticgeo 2.16.0, note that the Short Names feature has been removed as it is not compatible with Elasticsearch 2.0 and beyond. Previous fields which used the short names will be reverted to the full name, but you can still use aliasing to accomplish the same effect.
                                                              "},{"location":"community/features-templating/","title":"Features-Templating Extension","text":"

                                                              The Features Templating plug-in works by allowing us to define a What You See Is What You Get template, that will be applied on a stream of features respecting the defined content negotiation rules. Both Simple and Complex features are supported. The following services and operations are supported:

                                                              Service Operation WFS GetFeature WMS GetFeatureInfo OGCAPI Features Collection

                                                              The following output formats are supported:

                                                              • GeoJSON
                                                              • GML
                                                              • JSON-LD JSON-LD is a Linked Data format, based on JSON format, and revolves around the concept of \"context\" to provide additional mappings from JSON to an RDF model.
                                                              • HTML

                                                              The first part of the plug-in documentation will go through the template syntax. The second one will show how to configure the template to apply it to a vector layer. The third part shows the backwards mapping functionality.

                                                              • Installing the GeoServer FEATURES-TEMPLATING extension
                                                              • Template Directives
                                                              • Template Configuration
                                                              • Backward Mapping
                                                              • Features Templatring Rest API
                                                              "},{"location":"community/features-templating/configuration/","title":"Template Configuration","text":"

                                                              This part of the documentation explains how to add new templates to GeoServer and how to define rules from the layer configuration page for when a template should be applied.

                                                              "},{"location":"community/features-templating/configuration/#add-features-templates-to-geoserver","title":"Add Features Templates to GeoServer","text":"

                                                              Once the plug-in is installed, the left panel of the GeoServer UI will show a new option Feature Templating under the Data section. Clicking on that option will open a table with the available templates.

                                                              Clicking on the add New button will open the configuration page.

                                                              In the first tab the user can specify the following values:

                                                              • the Template Name. This name will be used for the template file name when saved in the data directory.

                                                              • the Template File Type (file extension) of the template, by selecting one among those available.

                                                              • the Workspace if the user wants to limit the usage of the template to the vector layers available in a specific workspace.

                                                                • the Layer Name if the user wants to limit the usage of the template to only a specific vector layer. Selecting a Layer Name will not cause the template to be applied to that Layer. This option is intended to make the template usable only by the selected Layer. In order to apply a template content negotiation rules need to be configured on a per layer basis (see section below).

                                                              The Workspace and Layer Name values, if specified, will also affect where the template will be saved:

                                                              • if neither is specified the template will be saved inside the features-templating directory.
                                                              • if a Workspace is specified the template will be saved in that workspace folder.
                                                              • if a Layer Name is specified the template will be saved in that layer folder.

                                                              The Template Content section is where the template is actually defined.

                                                              • The template can be uploaded from a file, and in that case the Template Name and Template File Type fields are automatically populated from the file.
                                                              • Otherwise the template can be written from scratch into the template editor.

                                                              By clicking on the Preview tab the user can specify parameters to test the template and preview the result. The preview will only return a single feature.

                                                              Warning

                                                              When previewing a template the template will be saved/updated in the data directory. This is due the fact that the preview works by issuing a WFS request. This implies that the previous state is lost, but also that any modification is immediately visible to a user that might be accessing the layer.

                                                              • The user must specify one value among the Available Output Formats
                                                              • The user must specify values among those available for the Workspace and Layer Name fields.
                                                              • If the user specified a Workspace for the template in the Data tab the preview Workspace will be automatically set from that workspace.
                                                              • If the user specified a Layer Name for the template in the Data tab the preview Layer Name will be automatically set from that layer.
                                                              • The user can specify a Feature ID to obtain a preview for the specified feature.
                                                              • The user can specify a CQL Filter to obtain a preview for a feature matching the filter.

                                                              The Validate button acts differently according to the output format:

                                                              • In the GML case, it will trigger a schema validation based on the Schema Location specified in the template.
                                                              • In the JSON-LD case, it will perform a JSON-LD @context validation.
                                                              • In the GeoJSON case no validation will occur.
                                                              "},{"location":"community/features-templating/configuration/#add-templates-rules-to-a-layer","title":"Add Templates Rules to a Layer","text":"

                                                              To inform GeoServer when to apply a template, the user needs to specify the rules on a per layer basis. The most basic rule is one that binds a template to a specific output format. Request CQL Functions allow specifying more advanced rules.

                                                              When the plug-in is installed a new tab will be available in the Layer configuration page, allowing for the definition of Template rules.

                                                              Once the form is filled the user needs to press the Add button to add the rule to the rules table. The rules will be then persisted to the layer configuration only when the Save button is pressed.

                                                              The following values can be specified:

                                                              • the Priority needed to inform GeoServer which rule should be applied if more than one rule matches the GetFeature request.
                                                              • the Template Name that indicates which template should be applied. If the template has a global scope the dropdown will present it with the template name value only. If a Workspace has been defined at template configuration time, the format will be {workspace name}:{template name}. If a Layer Name has been specified at template configuration time, the format will be {workspace name}:{layer name}:{template name}.
                                                              • the Supported Output Formats dropdown shows the output formats for which a template can be invoked. The user can choose one to indicate which output format the selected template should be applied to. If the GML value is selected, the template will be applied to all GML version output formats. If different GML templates should be applied for different GML versions, it is possible to define a condition on the MIME Type using the mimeType() function.
                                                              • the Request CQL filter area allows defining a generic CQL filter to evaluate against the request to determine if the template should be t. The available request functions to be used are listed on the right side of the form.
                                                              • the Profile CQL Filter allows defining a CQL filter allowing a content negotiation to be done per profile. The available request functions to be used are listed on the right side of the form. There is several approaches for content negotiations per profile, for example one of them is the W3C recommended approach where the profile is provided as an HTTP header. This will translate in a CQL filter similar to this one header('Accept-Profile')='http://my-profile/geo+json'.

                                                              An example CQL filter might be the following:

                                                              • `requestParam('myParameter')`` = 'use this template'
                                                              • mimeType() = 'application/geo+json'
                                                              • requestMatchRegex('^.*matchedPart.*$') = true
                                                              • header('testHeader') = 'myHeaderValue'

                                                              Every rule must define either a value from the Supported Output Formats dropdown or a Request CQL filter with a filter on the mimeType() value, or both.

                                                              Once rules are defined, if an incoming GetFeature request is matched the template corresponding to the matched rule will be applied to the output.

                                                              "},{"location":"community/features-templating/configuration/#data-directory-configuration","title":"Data Directory configuration","text":"

                                                              A features template can be configured directly from the GeoServer data dir without any UI usage. In this case the template needs to be placed in the Feature Type directory. When configuring templates in this way only one feature template per Feature Type is supported and the name is fixed for each output format as shown in the list below:

                                                              • GML 2 = gml2-template.xml
                                                              • GML 3.1 = gml31-template.xml
                                                              • GML 3.2 = gml32-template.xml
                                                              • JSON-LD = json-ld-template.json
                                                              • GEOJSON = geojson-template.json
                                                              • HTML = html-template.xhtml
                                                              "},{"location":"community/features-templating/directives/","title":"Template Directives","text":"

                                                              This part of the documentation is an introduction explaining the different template directives. Examples will be provided for both Simple Features and Complex Features. The syntax of the directives varies slightly between XML based templates and JSON based templates.

                                                              The examples will be provided mainly for GeoJSON and GML. However the syntax defined for GeoJSON output, unless otherwise specified, is valid for JSON-LD templates

                                                              "},{"location":"community/features-templating/directives/#template-directive-summary","title":"Template directive summary","text":"

                                                              The following constitutes a summary of all the template directives and it is meant to be used for quick reference. Each directive is explained in detail in the sections below.

                                                              "},{"location":"community/features-templating/directives/#json-based-templates","title":"JSON based templates","text":"

                                                              The following are the directives available in JSON based templates.

                                                              Usage Syntax Description property interpolation \\${property} specify it as an attribute value (\"json_attribute\":\"${property}\") cql evaluation \\$\\${cql} specify it as an element value (\"json_attribute\":\"$${cql}\") setting the evaluation context for child attributes. \\${source}. specify it as the first nested object in arrays ({\"$source\":\"property\"}) or as an attribute in objects (\"$source\":\"property\") filter the array, object, attribute \\$filter specify it inside the first nested object in arrays ({\"$filter\":\"condition\"}) or as an attribute in objects (\"$filter\":\"condition\") or in an attribute next to the attribute value separated by a , (\"attribute\":\"$filter{condition}, ${property}\") defines options to customize the output outside of a feature scope \\$options specify it at the top of the JSON template as a JSON object (GeoJSON options: \"$options\":{\"flat_output\":true, \"separator\":\".\"}; JSON-LD options: \"$options\":{\"@context\": \"the context json\", \"encode_as_string\": true, \"@type\":\"schema:SpecialAnnouncement\", \"collection_name\":\"customCollectionName\"}). allows including a template into another \\$include, \\$includeFlat specify the $include option as an attribute value (\"attribute\":\"$include{subProperty.json}\") and the $includeFlat as an attribute name with the included template path as a value (\"$includeFlat\":\"included.json\") allows a template to extend another template \\$merge specify the $merge directive as an attribute name containing the path to the extended template (:code: \"\\$merged\":\"base_template.json\"). allows null values to be encoded. default is not encoded. \\${property}! or \\$\\${expression}! ! at the end of a property interpolation or cql directive (\"attribute\":\"${property}!\" or \"attribute\":\"$${expression}!\")."},{"location":"community/features-templating/directives/#xml-based-templates","title":"XML based templates","text":"

                                                              The following are the directives available in XML based templates.

                                                              Usage Syntax Description property interpolation \\${property} specify it either as an element value (<element>${property}</element>) or as an xml attribute value (<element attribute:\"${property}\"/>) cql evaluation \\$\\${cql} specify them either as an element value (<element>$${cql}</element>) or as an xml attribute value (<element attribute:\"$${cql}\"/>) setting the evaluation context for property interpolation and cql evaluation in child elements. gft:source specify it as an xml attribute (<element gft:source:\"property\">) filter the element to which is applied based on the defined condition gft:filter specify it as an XML attribute on the element to be filtered (<element gft:filter:\"condition\">) marks the beginning of an XML template. gft:Template It has to be the root element of an XML template (<gft:Template> Template content</gft:Template>) defines options to customize the output outside of a feature scope gft:Options specify it as an element at the beginning of the xml document after the <gft:Template> one (<gft:Options></gft:Options>). GML options: <gtf:Namespaces>,<gtf:SchemaLocation>. HTML options: <script>, :code: <script type=\"application/ld+json\"/>, <style>, :code: <link>. allows including a template into another \\$include, gft:includeFlat specify the $include option as an element value (<element>$include{included.xml}</element>) and the gft:includeFlat as an element having the included template as text content (<gft:includeFlat>included.xml</gft:includeFlat>) allows null values to be encoded. default is not encoded. \\${property}! specify it either as an element value (<element>${property}!</element>) or as an xml attribute value (<element attribute:\"${property}!\"/>)"},{"location":"community/features-templating/directives/#a-step-by-step-introduction-to-features-templating-syntax","title":"A step by step introduction to features-templating syntax","text":"

                                                              This introduction is meant to illustrate the different directives that can be used in a template. For clarity the documentation will start with a Simple Feature example and then progress through a Complex Feature example. However all the directives that will be shown are available for both Simple and Complex Features. GeoJSON and GML examples will be used mostly. For JSON-LD output format the rules to define a template are the same as the GeoJSON template with two exceptions:

                                                              • A @context needs to be specified (see the options section below).
                                                              • The standard mandates that attributes' values are all strings.
                                                              "},{"location":"community/features-templating/directives/#property-and-cql-directive-simple-feature-example","title":"\\${property} and \\$\\${cql} directive (Simple Feature example)","text":""},{"location":"community/features-templating/directives/#geojson","title":"GeoJSON","text":"

                                                              Assume that we want to change the default geojson output of the topp:states layer. A single feature in the default output is like the following:

                                                              {\n \"type\": \"Feature\",\n  \"id\": \"states.1\",\n  \"geometry\": {},\n  \"geometry_name\": \"the_geom\",\n  \"properties\": {\n  \"STATE_NAME\": \"Illinois\",\n  \"STATE_FIPS\": \"17\",\n  \"SUB_REGION\": \"E N Cen\",\n  \"STATE_ABBR\": \"IL\",\n  \"LAND_KM\": 143986.61,\n  \"WATER_KM\": 1993.335,\n  \"PERSONS\": 11430602,\n  \"FAMILIES\": 2924880,\n  \"HOUSHOLD\": 4202240,\n  \"MALE\": 5552233,\n  \"FEMALE\": 5878369,\n  \"WORKERS\": 4199206,\n  \"DRVALONE\": 3741715,\n  \"CARPOOL\": 652603,\n  \"PUBTRANS\": 538071,\n  \"EMPLOYED\": 5417967,\n  \"UNEMPLOY\": 385040,\n  \"SERVICE\": 1360159,\n  \"MANUAL\": 828906,\n  \"P_MALE\": 0.486,\n  \"P_FEMALE\": 0.514,\n  \"SAMP_POP\": 1747776\n  }\n}\n

                                                              In particular we want to include in the final output only certain properties (e.g. the geometry, the state name, the code, values about population, male, female and workers). We want also to change some attribute names and to have them lower cased. Finally we want to have a string field having a wkt representation of the geometry. The desired output is like the following:

                                                              {\n  \"type\":\"Feature\",\n  \"id\":\"states.1\",\n  \"geometry\":{\n     \"type\":\"MultiPolygon\",\n     \"coordinates\":\"[....]\"   \n  },\n  \"properties\":{\n     \"name\":\"Illinois\",\n     \"region\":\"E N Cen\",\n     \"code\":\"IL\",\n     \"population_data\":{\n        \"population\":114306027,\n        \"males\":5552233.0,\n        \"females\":5878369.0,\n        \"active_population\":4199206.0\n     },\n     \"wkt_geom\":\"MULTIPOLYGON (((37.51099000000001 -88.071564, [...])))\"\n  }\n}\n

                                                              A template like this will allows us to produce the above output:

                                                              {\n\"type\": \"Feature\",\n\"id\": \"${@id}\",\n\"geometry\": \"${the_geom}\",\n\"properties\": {\n    \"name\": \"${STATE_NAME}\",\n    \"region\": \"${SUB_REGION}\",\n    \"code\": \"${STATE_ABBR}\",\n    \"population_data\":{\n        \"population\": \"${PERSONS}\",\n        \"males\": \"${MALE}\",\n        \"females\": \"${FEMALE}\",\n        \"active_population\": \"${WORKERS}\"\n    },\n    \"wkt_geom\":\"$${toWKT(the_geom)}\"\n}\n}\n

                                                              As it is possible to see the new output has the attribute names defined in the template. Moreover the population related attributes have been placed inside a nested json object. Finally a wkt_geom attribute with the WKT geometry representation has been added.

                                                              "},{"location":"community/features-templating/directives/#gml","title":"GML","text":"

                                                              The same template mechanism can be applied to a GML output format. This is an example GML template, again for the topp:states layer

                                                              <gft:Template>\n <gft:Options>\n   <gft:Namespaces xmlns:topp=\"http://www.openplans.org/topp\"/>\n   <gft:SchemaLocation xsi:schemaLocation=\"http://www.opengis.net/wfs/2.0 http://brgm-dev.geo-solutions.it/geoserver/schemas/wfs/2.0/wfs.xsd http://www.opengis.net/gml/3.2 http://schemas.opengis.net/gml/3.2.1/gml.xsd\"/>\n </gft:Options>\n <topp:states gml:id=\"${@id}\">\n   <topp:name code=\"${STATE_ABBR}\">${STATE_NAME}</topp:name>\n   <topp:region>${SUB_REGION}</topp:region>\n   <topp:population>${PERSONS}</topp:population>\n   <topp:males>${MALE}</topp:males>\n   <topp:females>${FEMALE}</topp:females>\n   <topp:active_population>${WORKERS}</topp:active_population>\n   <topp:wkt_geom>$${toWKT(the_geom)}</topp:wkt_geom>\n </topp:states>\n</gft:Template>\n

                                                              And this is how a feature will appear:

                                                              <topp:states gml:id=\"states.10\">\n   <topp:name code=\"MO\">Missouri</topp:name>\n   <topp:region>W N Cen</topp:region>\n   <topp:population>5117073.0</topp:population>\n   <topp:males>2464315.0</topp:males>\n   <topp:females>2652758.0</topp:females>\n   <topp:active_population>1861192.0</topp:active_population>\n   <topp:wkt_geom>MULTIPOLYGON (([....])))</topp:wkt_geom>\n </topp:states>\n

                                                              As it is possible to see the geometry is being encoded only as a wkt, moreover the STATE_ATTR value is now present as an xml attribute of the element topp:states. Finally elements that were not defined in the template did not show up.

                                                              Looking at these examples it is possible to see additional directives that can customize the output:

                                                              • Property interpolation can be invoked using the directive ${property_name}.
                                                              • In case complex operation are needed a CQL expression can be used thought a $${cql} syntax (all CQL functions are supported).
                                                              • Simple text values are reproduced in the final output as they are.
                                                              • Finally the GML template needs the actual template content to be wrapped into a gft:Template element. The gft doesn't needs to be bound to a namespace. It is used just as marker of a features-templating related element and will not be present in the final output.
                                                              • There is also another element, the gft:Options, with two more elements inside. It will be explained in a later dedicated section.
                                                              "},{"location":"community/features-templating/directives/#source-and-filter-complex-feature-example","title":"Source and filter (Complex Feature example)","text":""},{"location":"community/features-templating/directives/#geojson_1","title":"GeoJSON","text":"

                                                              Let's assume now that an AppSchema layer has been configured and customization of the complex features output is needed. The Meteo Stations use case will be used as an example. For a description of the use case check the documentation at Smart Data Loader Extension. This is the domain model of the use case:

                                                              The default GeoJSON output format produces features like the following:

                                                              {\n  \"type\":\"Feature\",\n  \"id\":\"MeteoStationsFeature.7\",\n  \"geometry\":{\n\n  },\n  \"properties\":{\n     \"@featureType\":\"MeteoStations\",\n     \"id\":7,\n     \"code\":\"BOL\",\n     \"common_name\":\"Bologna\",\n     \"meteoObservations\":[\n        {\n           \"id\":3,\n           \"time\":\"2016-12-19T11:28:31Z\",\n           \"value\":35,\n           \"meteoParameters\":[\n              {\n                 \"id\":1,\n                 \"param_name\":\"temperature\",\n                 \"param_unit\":\"C\"\n              }\n           ]\n        },\n        {\n           \"id\":4,\n           \"time\":\"2016-12-19T11:28:55Z\",\n           \"value\":25,\n           \"meteoParameters\":[\n              {\n                 \"id\":1,\n                 \"param_name\":\"temperature\",\n                 \"param_unit\":\"C\"\n              }\n           ]\n        },\n        {\n           \"id\":5,\n           \"time\":\"2016-12-19T11:29:24Z\",\n           \"value\":80,\n           \"meteoParameters\":[\n              {\n                 \"id\":2,\n                 \"param_name\":\"wind speed\",\n                 \"param_unit\":\"Km/h\"\n              }\n           ]\n        },\n        {\n           \"id\":6,\n           \"time\":\"2016-12-19T11:30:26Z\",\n           \"value\":1019,\n           \"meteoParameters\":[\n              {\n                 \"id\":3,\n                 \"param_name\":\"pressure\",\n                 \"param_unit\":\"hPa\"\n              }\n           ]\n        },\n        {\n           \"id\":7,\n           \"time\":\"2016-12-19T11:30:51Z\",\n           \"value\":1015,\n           \"meteoParameters\":[\n              {\n                 \"id\":3,\n                 \"param_name\":\"pressure\",\n                 \"param_unit\":\"hPa\"\n              }\n           ]\n        }\n     ]\n  }\n}\n

                                                              The above JSON has a data structure where:

                                                              • Station object has a nested array of Observations.
                                                              • Each Observation has a an array of parameter that describe the type of Observation.

                                                              Now let's assume that a different output needs to be produced where instead of having a generic array of observation nested into the root object, arrays are provided separately for each type of parameter e.g. Temperatures, Pressures and Winds_speed observations. In other words instead of having the Observation type defined inside a nested Parameter object that information should be provided directly in the attribute name. The desired output looks like the following:

                                                              {\n \"type\":\"FeatureCollection\",\n \"features\":[\n    {\n       \"Identifier\":\"MeteoStationsFeature.7\",\n       \"geometry\":{\n          \"type\":\"Point\",\n          \"coordinates\":[\n             44.5,\n             11.34\n          ]\n       },\n       \"properties\":{\n          \"Name\":\"Bologna\",\n          \"Code\":\"STATION-BOL\",\n          \"Location\":\"POINT (44.5 11.34)\",\n          \"Temperatures\":[\n             {\n                \"Timestamp\":\"2016-12-19T11:28:31.000+00:00\",\n                \"Value\":35.0\n             },\n             {\n                \"Timestamp\":\"2016-12-19T11:28:55.000+00:00\",\n                \"Value\":25.0\n             }\n          ],\n          \"Pressures\":[\n             {\n                \"Timestamp\":\"2016-12-19T11:30:26.000+00:00\",\n                \"Value\":1019.0\n             },\n             {\n                \"Timestamp\":\"2016-12-19T11:30:51.000+00:00\",\n                \"Value\":1015.0\n             }\n          ],\n          \"Winds_speed\":[\n             {\n                \"Timestamp\":\"2016-12-19T11:29:24.000+00:00\",\n                \"Value\":80.0\n             }\n          ]\n       }\n    }\n ],\n \"totalFeatures\":3,\n \"numberMatched\":3,\n \"numberReturned\":1,\n \"timeStamp\":\"2021-07-13T14:00:19.457Z\",\n \"crs\":{\n    \"type\":\"name\",\n    \"properties\":{\n       \"name\":\"urn:ogc:def:crs:EPSG::4326\"\n    }\n }\n}\n

                                                              A template like this will allow to produce such an output:

                                                              {\n     \"$source\":\"st:MeteoStationsFeature\",\n     \"Identifier\":\"${@id}\",\n     \"geometry\":\"${st:position}\",\n     \"properties\":{\n     \"Name\":\"${st:common_name}\",\n     \"Code\":\"$${strConcat('STATION-', xpath('st:code'))}\",\n     \"Location\":\"$${toWKT(xpath('st:position'))}\",\n     \"Temperatures\":[\n       {\n         \"$source\":\"st:meteoObservations/st:MeteoObservationsFeature\",\n         \"$filter\":\"xpath('st:meteoParameters/st:MeteoParametersFeature/st:param_name') = 'temperature'\"\n       },\n       {\n         \"Timestamp\": \"${st:time}\",\n         \"Value\": \"${st:value}\"\n       }\n     ],\n     \"Pressures\":[\n       {\n         \"$source\":\"st:meteoObservations/st:MeteoObservationsFeature\",\n         \"$filter\":\"xpath('st:meteoParameters/st:MeteoParametersFeature/st:param_name') = 'pressure'\"\n       },\n       {\n         \"Timestamp\": \"${st:time}\",\n         \"Value\": \"${st:value}\"\n       }\n     ],\n     \"Winds_speed\":[\n       {\n         \"$source\":\"st:meteoObservations/st:MeteoObservationsFeature\",\n         \"$filter\":\"xpath('st:meteoParameters/st:MeteoParametersFeature/st:param_name') = 'wind speed'\"\n       },\n       {\n         \"Timestamp\": \"${st:time}\",\n         \"Value\": \"${st:value}\"\n       }\n     ]\n   }\n  }\n

                                                              In addition to the ${property} and $${cql} directives seen before, there are two more:

                                                              • In the example above the xpath('xpath') function is used to reference property. When dealing with Complex Features it must be used when referencing properties inside a $filter or a $${cql} directive.
                                                              • $source which is meant to provide the context against which evaluated nested element properties and xpaths. In this case the \"$source\":\"st:meteoObservations/st:MeteoObservationsFeature\" provides the context for the nested attributes angainst which the directives will be evaluated. When defining a $source for a JSON array it should be provided in a JSONObject separated from the JSON Object mapping the nested feature attributes as in the example above. When defining the $source for a JSONObject it can be simply added as an object attribute (see below examples).
                                                              • When using ${property} directive or an xpath('xpath') function it is possible to reference a property bounded to an upper $source using a ../ notation eg. ${../previousContextValue}.
                                                              • $filter provides the possibility to filter the value that will be included in the element to which is applied, in this case a json array. For instance the filter $filter\":\"xpath('st:meteoParameters/st:MeteoParametersFeature/st:param_name') = 'wind speed' in the Winds_speed array allows filtering the element that will be included in this array according to the param_name value.

                                                              One note aboute the Source. It is strictly needed only when referencing a nested feature. This means that in the GeoJSON template example the \"$source\":\"st:MeteoStationsFeature\" could have been omitted. This not apply for nested elements definition where the \"$source\":\"st:meteoObservations/st:MeteoObservationsFeature\" is mandatory.

                                                              Follows a list of JSON template bits showing filters definition in context different from a JSON array, as well as $source definition for a JSONObject.

                                                              • Object (encode the JSON object only if the st:value is greater than 75.3).
                                                              {\n  \"Observation\":\n        {\n          \"$source\":\"st:MeteoObservationsFeature\",\n          \"$filter\":\"st:value > 75.3 \",\n          \"Timestamp\":\"${st:time}\",\n          \"Value\":\"${st:value}\"\n       }\n}\n
                                                              • Attribute (encode the Timestamp attribute only if the st:value is greater than 75.3).
                                                              {\n\"Observation\":\n       {\n         \"$source\":\"st:MeteoObservationsFeature\",\n         \"Timestamp\":\"$filter{st:value > 75.3}, ${st:time}\",\n         \"Value\":\"${st:value}\"\n      }\n}\n
                                                              • Static attribute (encode the Static_value attribute only if the st:value is greater than 75.3).
                                                              {\n\"Observation\":\n      {\n        \"$source\":\"st:MeteoObservationsFeature\",\n        \"Timestamp\":\"${st:time}\",\n        \"Static_value\":\"$filter{st:value > 75.3}, this Observation has a value > 75.3\",\n        \"Value\":\"${st:value}\"\n     }\n}\n

                                                              As it is possible to see from the previous example in the array and object cases the filter syntax expected a \"$filter\" key followed by an attribute with the filter to evaluate. In the attribute case, instead, the filter is being specified inside the value as \"$filter{...}\", followed by the CQL expression, or by the static content, with a comma separating the two.

                                                              "},{"location":"community/features-templating/directives/#gml_1","title":"GML","text":"

                                                              filter and source are available as well in GML templates. Assuming that the desired output is the corresponding GML equivalent of the GeoJSON output above e.g.:

                                                              <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<wfs:FeatureCollection xmlns:st=\"http://www.stations.org/1.0\" xmlns:xs=\"http://www.w3.org/2001/XMLSchema\" xmlns:wfs=\"http://www.opengis.net/wfs/2.0\" xmlns:xlink=\"http://www.w3.org/1999/xlink\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xmlns:gml=\"http://www.opengis.net/gml/3.2\" numberMatched=\"3\" numberReturned=\"0\" timeStamp=\"2021-07-13T15:09:28.620Z\">\n<wfs:member>\n <st:MeteoStations gml:id=\"MeteoStationsFeature.7\">\n   <st:code>Station_BOL</st:code>\n   <st:name>Bologna</st:name>\n   <st:geometry>\n     <gml:Point srsName=\"urn:ogc:def:crs:EPSG::4326\" srsDimension=\"2\" gml:id=\"smdl-stations.1.geom\">\n       <gml:pos>11.34 44.5</gml:pos>\n     </gml:Point>\n   </st:geometry>\n   <st:temperature>\n     <st:temperature>\n       <st:Temperature>\n         <st:time>2016-12-19T11:28:31.000Z</st:time>\n         <st:value>35.0</st:value>\n       </st:Temperature>\n     </st:temperature>\n     <st:temperature>\n       <st:Temperature>\n         <st:time>2016-12-19T11:28:55.000Z</st:time>\n         <st:value>25.0</st:value>\n       </st:Temperature>\n     </st:temperature>\n   </st:temperature>\n   <st:pressure>\n     <st:pressure>\n       <st:Pressure>\n         <st:time>2016-12-19T11:30:26.000Z</st:time>\n         <st:value>1019.0</st:value>\n       </st:Pressure>\n     </st:pressure>\n     <st:pressure>\n       <st:Pressure>\n         <st:time>2016-12-19T11:30:51.000Z</st:time>\n         <st:value>1015.0</st:value>\n       </st:Pressure>\n     </st:pressure>\n   </st:pressure>\n   <st:wind_speed>\n     <st:wind_speed>\n       <st:Wind_speed>\n         <st:time>2016-12-19T11:29:24.000Z</st:time>\n         <st:value>80.0</st:value>\n       </st:Wind_speed>\n     </st:wind_speed>\n   </st:wind_speed>\n </st:MeteoStations>\n</wfs:member>\n</wfs:FeatureCollection>\n

                                                              The following GML template will produce the above output:

                                                              <gft:Template>\n<gft:Options>\n  <gft:Namespaces xmlns:st=\"http://www.stations.org/1.0\"/>\n</gft:Options>\n<st:MeteoStations gml:id=\"${@id}\">\n<st:code>$${strConcat('Station_',st:code)}</st:code>\n<st:name>${st:common_name}</st:name>\n<st:geometry>${st:position}</st:geometry>\n<st:temperature gft:isCollection=\"true\" gft:source=\"st:meteoObservations/st:MeteoObservationsFeature\" gft:filter=\"xpath('st:meteoParameters/st:MeteoParametersFeature/st:param_name') = 'temperature'\">\n<st:Temperature>\n  <st:time>${st:time}</st:time>\n  <st:value>${st:value}</st:value>\n</st:Temperature>\n</st:temperature>\n<st:pressure gft:isCollection=\"true\" gft:source=\"st:meteoObservations/st:MeteoObservationsFeature\"  gft:filter=\"xpath('st:meteoParameters/st:MeteoParametersFeature/st:param_name') = 'pressure'\">\n<st:Pressure>\n  <st:time>${st:time}</st:time>\n  <st:value>${st:value}</st:value>\n</st:Pressure>\n</st:pressure>\n<st:wind_speed gft:isCollection=\"true\" gft:source=\"st:meteoObservations/st:MeteoObservationsFeature\"  gft:filter=\"xpath('st:meteoParameters/st:MeteoParametersFeature/st:param_name') = 'wind speed'\">\n<st:Wind_speed>\n  <st:time>${st:time}</st:time>\n  <st:value>${st:value}</st:value>\n</st:Wind_speed>\n</st:wind_speed>\n</st:MeteoStations>\n</gft:Template>\n

                                                              In the GML case filter and source directives are defined in a slightly different manner from the JSON usecase.

                                                              • The filter needs to be defined as an attribute gft:filter in the element that is meant to be filtered.
                                                              • The source needs to be defined as an attribute gft:source in the element that will set the source for its child elements.
                                                              • The attribute gft:isCollection=\"true\" defines a directive meant to be used in GML templates to mark collection elements: this directive is needed since XML doesn't have the array concept and the template mechanism needs to be informed if an element should be repeated because it represent a collection element.

                                                              As for the GeoJSON case the source is not needed for the top level feature. In this case we indeed omitted it for the st:MeteoStations element. Instead, as stated above, it is mandatory for nested elements like Temperature, Pressure and Winds_speed. All of them show indeed a gft:source=\"st:meteoObservations/st:MeteoObservationsFeature\".

                                                              "},{"location":"community/features-templating/directives/#more-on-xpath-function","title":"More on XPath Function","text":"

                                                              The xpath('xpath') function is meant to provide the possibility to reference a Feature's properties no matter how nested, in a template, providing also the possibility to reference the previous context value through ../.

                                                              Check the following template from the GeoJSON Stations use case.

                                                              {\n\"$source\":\"st:MeteoStationsFeature\",\n\"properties\":{\n   \"Code\":\"$${strConcat('STATION-', xpath('st:code'))}\",\n   \"Location\":\"$${toWKT(xpath('st:position'))}\",\n   \"Temperatures\":[\n    {\n       \"$source\":\"st:meteoObservations/st:MeteoObservationsFeature\",\n       \"$filter\":\"xpath('st:meteoParameters/st:MeteoParametersFeature/st:param_name') = 'temperature'\"\n    },\n    {\n      \"Value\": \"${st:value}\",\n      \"StillCode\":\"$${strConcat('STATION-', xpath('../st:code'))}\"\n     }\n ]\n}\n

                                                              In the Temperatures array a StillCode attribute has been defined that through ../ references not the \"$source\":\"st:meteoObservations/st:MeteoObservationsFeature\", but the previous one \"$source\":\"st:MeteoStationsFeature\".

                                                              The same can be achieved with the property interpolation directive if a cql function evaluation is not needed: \"StillCode\":\"$${strConcat('STATION-', xpath('../st:code'))}\".

                                                              Warning

                                                              the xpath('some xpath) cql function is meant to be used in the scope of this plugin. For general usage please refer to the property function.

                                                              "},{"location":"community/features-templating/directives/#template-options","title":"Template Options","text":"

                                                              The directives seen so far allow control of the output in the scope of a Feature element. The options directive, instead, allows customizing the output for part of the output outside the Feature scope or to define general modifications to the overall output. The available options vary according to the output format.

                                                              "},{"location":"community/features-templating/directives/#geojson_2","title":"GeoJSON","text":"

                                                              In the context of a GeoJSON template two options are available: flat_output and separator. These options are meant to provide a GeoJSON output encoded following INSPIRE rule for alternative feature GeoJSON encoding (see also). To use the functionality an \"$options\" JSON object can be added on top of a JSON template, like in the following example:

                                                              {\n     \"$options\":{\n       \"flat_output\":true,\n       \"separator\": \".\"\n     },\n     \"$source\":\"st:MeteoStationsFeature\",\n     \"Identifier\":\"${@id}\",\n     \"geometry\":\"${st:position}\",\n     \"properties\":{\n     \"Name\":\"${st:common_name}\",\n     \"Code\":\"$${strConcat('STATION-', xpath('st:code'))}\",\n     \"Location\":\"$${toWKT(xpath('st:position'))}\",\n     \"Temperatures\":[\n       {\n         \"$source\":\"st:meteoObservations/st:MeteoObservationsFeature\",\n         \"$filter\":\"xpath('st:meteoParameters/st:MeteoParametersFeature/st:param_name') = 'temperature'\"\n       },\n       {\n         \"Timestamp\": \"${st:time}\",\n         \"Value\": \"${st:value}\"\n       }\n     ],\n     \"Pressures\":[\n       {\n         \"$source\":\"st:meteoObservations/st:MeteoObservationsFeature\",\n         \"$filter\":\"xpath('st:meteoParameters/st:MeteoParametersFeature/st:param_name') = 'pressure'\"\n       },\n       {\n         \"Timestamp\": \"${st:time}\",\n         \"Value\": \"${st:value}\"\n       }\n     ],\n     \"Winds_speed\":[\n       {\n         \"$source\":\"st:meteoObservations/st:MeteoObservationsFeature\",\n         \"$filter\":\"xpath('st:meteoParameters/st:MeteoParametersFeature/st:param_name') = 'wind speed'\"\n       },\n       {\n         \"Timestamp\": \"${st:time}\",\n         \"Value\": \"${st:value}\"\n       }\n     ]\n   }\n  }\n

                                                              The flat_output will act in the following way:

                                                              • The encoding of nested arrays and objects will be skipped, by encoding only their attributes.
                                                              • Object attribute names will be concatenated with the names of their json attributes.
                                                              • Arrays' attribute names will be concatenated as well with the one of the json attributes of their inner object. In addition an index value will be added after the array's attribute name for each nested object.
                                                              • The separator specifies the separator of the attributes' names. Default is _.
                                                              • The final output will have a flat list of attributes with names produced by the concatenation, like the following.
                                                              "},{"location":"community/features-templating/directives/#json-ld","title":"JSON-LD","text":"

                                                              A JSON-LD template can be defined as a GeoJSON template since it is a JSON based output as well. However it needs to have a @context attribute, object or array at the beginning of it in order to conform to the standard. Moreover each JSON Object must have an @type defining a type through a vocabulary term. To accomplish these requirements it is possible to specify several $options on the template:

                                                              • @context providing a full JSON-LD @context.
                                                              • @type providing a type term for the root JSON object in the final output (by default the value is FeatureCollection).
                                                              • collection_name providing an alternative name for the features array in the final output (by default features is used). The option is useful in case the user wants to use a features attribute name equals to a specific term defined in a vocabulary.
                                                              {\n \"$options\":{\n    \"encode_as_string\": true,\n    \"collection_name\":\"stations\",\n    \"@type\":\"schema:Thing\",\n    \"@context\":[\n       \"https://opengeospatial.github.io/ELFIE/contexts/elfie-2/elf-index.jsonld\",\n       \"https://opengeospatial.github.io/ELFIE/contexts/elfie-2/gwml2.jsonld\",\n       {\n          \"gsp\":\"http://www.opengis.net/ont/geosparql#\",\n          \"sf\":\"http://www.opengis.net/ont/sf#\",\n          \"schema\":\"https://schema.org/\",\n          \"st\":\"http://www.stations.org/1.0\",\n          \"wkt\":\"gsp:asWKT\",\n          \"Feature\":\"gsp:Feature\",\n          \"geometry\":\"gsp:hasGeometry\",\n          \"point\":\"sf:point\",\n          \"features\":{\n             \"@container\":\"@set\",\n             \"@id\":\"schema:hasPart\"\n          }\n       }\n    ]\n },\n \"$source\":\"st:MeteoStationsFeature\",\n \"Identifier\":\"${@id}\",\n \"Name\":\"${st:common_name}\",\n \"Code\":\"$${strConcat('STATION-', xpath('st:code'))}\",\n \"Location\":\"$${toWKT(st:position)}\",\n \"Temperatures\":[\n    {\n       \"$source\":\"st:meteoObservations/st:MeteoObservationsFeature\",\n       \"$filter\":\"xpath('st:meteoParameters/st:MeteoParametersFeature/st:param_name') = 'temperature' AND 'yes' = env('showTemperatures','yes')\"\n    },\n    {\n       \"Timestamp\":\"${st:time}\",\n       \"Value\":\"${st:value}\"\n    }\n ],\n \"Pressures\":[\n    {\n       \"$source\":\"st:meteoObservations/st:MeteoObservationsFeature\",\n       \"$filter\":\"xpath('st:meteoParameters/st:MeteoParametersFeature/st:param_name') = 'pressure' AND 'yes' = env('showPressures','yes')\"\n    },\n    {\n       \"Timestamp\":\"${st:time}\",\n       \"Value\":\"${st:value}\"\n    }\n ],\n \"Winds speed\":[\n    {\n       \"$source\":\"st:meteoObservations/st:MeteoObservationsFeature\",\n       \"$filter\":\"xpath('st:meteoParameters/st:MeteoParametersFeature/st:param_name') = 'wind speed' AND 'yes' = env('showWinds','yes')\"\n    },\n    {\n       \"Timestamp\":\"${st:time}\",\n       \"Value\":\"${st:value}\"\n    }\n ]\n}\n

                                                              The @context will show up at the beginning of the JSON-LD output:

                                                              {\n  \"@context\":[\n     \"https://opengeospatial.github.io/ELFIE/contexts/elfie-2/elf-index.jsonld\",\n     \"https://opengeospatial.github.io/ELFIE/contexts/elfie-2/gwml2.jsonld\",\n     {\n        \"gsp\":\"http://www.opengis.net/ont/geosparql#\",\n        \"sf\":\"http://www.opengis.net/ont/sf#\",\n        \"schema\":\"https://schema.org/\",\n        \"st\":\"http://www.stations.org/1.0\",\n        \"wkt\":\"gsp:asWKT\",\n        \"Feature\":\"gsp:Feature\",\n        \"geometry\":\"gsp:hasGeometry\",\n        \"point\":\"sf:point\",\n        \"features\":{\n           \"@container\":\"@set\",\n           \"@id\":\"schema:hasPart\"\n        }\n     }\n  ],\n  \"type\":\"FeatureCollection\",\n  \"@type\":\"schema:Thing\",\n  \"stations\":[\n     {\n        \"Identifier\":\"MeteoStationsFeature.7\",\n        \"Name\":\"Bologna\",\n        \"Code\":\"STATION-BOL\",\n        \"Location\":\"POINT (44.5 11.34)\",\n        \"Temperatures\":[\n           {\n              \"Timestamp\":\"2016-12-19T11:28:31.000+00:00\",\n              \"Value\":\"35.0\"\n           },\n           {\n              \"Timestamp\":\"2016-12-19T11:28:55.000+00:00\",\n              \"Value\":\"25.0\"\n           }\n        ],\n        \"Pressures\":[\n           {\n              \"Timestamp\":\"2016-12-19T11:30:26.000+00:00\",\n              \"Value\":\"1019.0\"\n           },\n           {\n              \"Timestamp\":\"2016-12-19T11:30:51.000+00:00\",\n              \"Value\":\"1015.0\"\n           }\n        ],\n        \"Winds speed\":[\n           {\n              \"Timestamp\":\"2016-12-19T11:29:24.000+00:00\",\n              \"Value\":\"80.0\"\n           }\n        ]\n     }\n  ]\n}\n

                                                              The above template defines, along with the @context, also the option encode_as_string. The option is used to request a JSON-LD output where all the attributes are encoded as text. By default attributes are instead encoded as in GeoJSON output format.

                                                              When dealing with a GetFeatureInfo request over a LayerGroup asking for a JSON-LD output the plug-in will perform a union of the JSON-LD @context (when different) defined in the template of each contained layer. This means that in case of conflicting attributes name the attributes name will override each other according to the processing order of the layers. The user can prevent this behaviour by taking advantage of the include directive, explained below, defining a single @context included in the template of each contained layer. In this way all the layer will share the same context definition.

                                                              "},{"location":"community/features-templating/directives/#gml_2","title":"GML","text":"

                                                              GML output has two options: Namespaces and SchemaLocation, that define the namespaces and the SchemaLocation attribute that will be included in the FeatureCollection element in the resulting output. These options needs to be specified inside a gft:Options element at the beginning of the template right after the gft:Template element, e.g.

                                                              <gft:Template>\n <gft:Options>\n   <gft:Namespaces xmlns:st=\"http://www.stations.org/1.0\"/>\n   <gft:SchemaLocation xsi:schemaLocation=\"http://www.stations.org/1.0 http://www.stations.org/stations/1.0/xsd/stations.xsd\"/>\n </gft:Options>\n <st:MeteoStations gml:id=\"${@id}\">\n<st:code>$${strConcat('Station_',st:code)}</st:code>\n<st:name>${st:common_name}</st:name>\n<st:geometry>${st:position}</st:geometry>\n<st:temperature gft:isCollection=\"true\" gft:source=\"st:meteoObservations/st:MeteoObservationsFeature\" gft:filter=\"xpath('st:meteoParameters/st:MeteoParametersFeature/st:param_name') = 'temperature'\">\n<st:Temperature>\n  <st:time>${st:time}</st:time>\n  <st:value>${st:value}</st:value>\n</st:Temperature>\n</st:temperature>\n<st:pressure gft:isCollection=\"true\" gft:source=\"st:meteoObservations/st:MeteoObservationsFeature\"  gft:filter=\"xpath('st:meteoParameters/st:MeteoParametersFeature/st:param_name') = 'pressure'\">\n<st:Pressure>\n  <st:time>${st:time}</st:time>\n  <st:value>${st:value}</st:value>\n</st:Pressure>\n</st:pressure>\n<st:wind_speed gft:isCollection=\"true\" gft:source=\"st:meteoObservations/st:MeteoObservationsFeature\"  gft:filter=\"xpath('st:meteoParameters/st:MeteoParametersFeature/st:param_name') = 'wind speed'\">\n<st:Wind_speed>\n  <st:time>${st:time}</st:time>\n  <st:value>${st:value}</st:value>\n</st:Wind_speed>\n</st:wind_speed>\n</st:MeteoStations>\n</gft:Template>\n
                                                              "},{"location":"community/features-templating/directives/#html","title":"HTML","text":"

                                                              HTML templates can use several options:

                                                              • <script> allows defining whatever javascript is needed, e.g. to create a tree view (as in the example below) or an openlayers map client.

                                                              • code

                                                                <script type=\"application/ld+json\"/> allows to inject the JSON-LD representation of the features being templated in the <head>. In order to have the option working properly a JSON-LD template must be configured for the layer, or GeoServer will return an error message.

                                                              • <style> allows defining css content.

                                                              • <link> allows linking to external resources.

                                                              The content of <script> and <style> needs to be provided as <![CDATA[.

                                                              The following is an example of a HTML template that will output the Stations features as a tree view. Also in this example we are using the same filter on st:meteoObservations as in the other template examples.:

                                                              <gft:Template>\n  <gft:Options>\n     <style>\n     <![CDATA[ul, #myUL {\n     list-style-type: none;\n     }\n     #myUL {\n     margin: 0;\n     padding: 0;\n     }\n     .caret {\n     cursor: pointer;\n     -webkit-user-select: none; /* Safari 3.1+ */\n     -moz-user-select: none; /* Firefox 2+ */\n     -ms-user-select: none; /* IE 10+ */\n     user-select: none;\n     }\n     .caret::before {\n     content: \"\\25B6\";\n     color: black;\n     display: inline-block;\n     margin-right: 6px;\n     }\n     .caret-down::before {\n     -ms-transform: rotate(90deg); /* IE 9 */\n     -webkit-transform: rotate(90deg); /* Safari */'\n     transform: rotate(90deg);  \n     }\n     .nested {\n     display: none;\n     }\n     .active {\n     display: block;\n     }]]></style>\n     <script><![CDATA[window.onload = function() {\n     var toggler = document.getElementsByClassName(\"caret\");\n     for (let item of toggler){\n     item.addEventListener(\"click\", function() {\n     this.parentElement.querySelector(\".nested\").classList.toggle(\"active\");\n     this.classList.toggle(\"caret-down\");\n     });\n     }\n     }]]></script>\n     <script type=\"application/ld+json\"/>\n     </gft:Options>\n     <ul id=\"myUL\">\n      <li>\n        <span class=\"caret\">MeteoStations</span>\n        <ul class=\"nested\">\n           <li>\n              <span class=\"caret\">Code</span>\n              <ul class=\"nested\">\n                 <li>$${strConcat('Station_',st:code)}</li>\n              </ul>\n           </li>\n           <li>\n              <span class=\"caret\">Name</span>\n              <ul class=\"nested\">\n                 <li>${st:common_name}</li>\n              </ul>\n           </li>\n           <li>\n              <span class=\"caret\">Geometry</span>\n              <ul class=\"nested\">\n                 <li>${st:position}</li>\n              </ul>\n           </li>\n           <li gft:isCollection=\"true\" gft:source=\"st:meteoObservations/st:MeteoObservationsFeature\" gft:filter=\"xpath('st:meteoParameters/st:MeteoParametersFeature/st:param_name') = 'temperature'\">\n              <span class=\"caret\">Temperature</span>\n              <ul class=\"nested\">\n                 <li>\n                    <span class=\"caret\">Time</span>\n                    <ul class=\"nested\">\n                       <li>${st:time}</li>\n                    </ul>\n                 </li>\n                 <li>\n                    <span class=\"caret\">Value</span>\n                    <ul class=\"nested\">\n                       <li>${st:time}</li>\n                    </ul>\n                 </li>\n              </ul>\n           </li>\n           <li gft:isCollection=\"true\" gft:source=\"st:meteoObservations/st:MeteoObservationsFeature\" gft:filter=\"xpath('st:meteoParameters/st:MeteoParametersFeature/st:param_name') = 'pressure'\">\n              <span class=\"caret\">Pressure</span>\n              <ul class=\"nested\">\n                 <li>\n                    <span class=\"caret\">Time</span>\n                    <ul class=\"nested\">\n                       <li>${st:time}</li>\n                    </ul>\n                 </li>\n                 <li>\n                    <span class=\"caret\">Value</span>\n                    <ul class=\"nested\">\n                       <li>${st:time}</li>\n                    </ul>\n                 </li>\n              </ul>\n           </li>\n           <li gft:isCollection=\"true\" gft:source=\"st:meteoObservations/st:MeteoObservationsFeature\" gft:filter=\"xpath('st:meteoParameters/st:MeteoParametersFeature/st:param_name') = 'wind speed'\">\n              <span class=\"caret\">Wind Speed</span>\n              <ul class=\"nested\">\n                 <li>\n                    <span class=\"caret\">Time</span>\n                    <ul class=\"nested\">\n                       <li>${st:time}</li>\n                    </ul>\n                 </li>\n                 <li>\n                    <span class=\"caret\">Value</span>\n                    <ul class=\"nested\">\n                       <li>${st:time}</li>\n                    </ul>\n                 </li>\n              </ul>\n           </li>\n        </ul>\n     </li>\n  </ul>\n</gft:Template>\n

                                                              The output of the template will be the following:

                                                              "},{"location":"community/features-templating/directives/#including-other-templates","title":"Including other templates","text":"

                                                              While developing a group of templates, it's possible to notice sections that repeat across different template instances. Template inclusion allows sharing the common parts, extracting them in a re-usable building block.

                                                              Inclusion can be performed using two directives:

                                                              • include allows including a separate template as is.
                                                              • includeFlat allows including a separate template, stripping the top-most container.

                                                              As for other directives the syntax varies slightly between JSON based template and XML based ones.

                                                              The two directives need to specify a path to the template to be included. Template names can be plain, as in this example, refer to sub-directories, or be absolute. Examples of valid template references are:

                                                              • subProperty.json
                                                              • ./subProperty.json
                                                              • ./blocks/aBlock.json
                                                              • /templates/test/aBlock.json

                                                              However it's currently not possible to climb up the directory hierarchy using relative references, so a reference like ../myParentBlock.json will be rejected.

                                                              "},{"location":"community/features-templating/directives/#json-based-templates-geojson-json-ld","title":"JSON based templates (GeoJSON, JSON-LD)","text":"

                                                              In this context the two directives can be defined as:

                                                              • $include.
                                                              • $includeFlat.

                                                              Regarding the $includeFlat option is worth mentioning that in a JSON context:

                                                              • If a JSON object is included, then its properties are directly included in-place, which makes sense only within another object.
                                                              • If instead a JSON array is included, then its values are directly included in-place, which makes sense only within another array.

                                                              The following JSON snippet shows the four possible syntax options for template inclusion:

                                                              {\n   \"aProperty\": \"$include{subProperty.json}\", \n   \"$includeFlat\": \"propsInAnObject.json\", \n   \"anArray\" : [\n      \"$include{arrayElement.json}\", \n      \"$includeFlat{subArray.json}\" \n   ],\n  \"$includeFlat\": \"${property}\"\n}\n

                                                              Notes:

                                                              1) The subProperty.json template (line 2) can be both an object or an array, it will be used as the new value of aProperty 2) The propsInAnObject.json template (line 3) is required to be a JSON object, its properties will be directly included in-place where the $includeFlat directive is 3) The arrayElement.json template (line 5) can be both an object or an array, the value will be replaced directly as the new element in anArray. This allows creation of a JSON object as the array element, or the creation of a nested array. 4) The subArray.json template (line 6) must be an array itself, the container array will be stripped and its values directly integrated inside anArray.

                                                              In case an includeFlat directive is specified and it's attribute value is a property interpolation directive, if the property name evaluates to a json it gets included flat in the final output e.g

                                                              including json:

                                                              {\n   \"property\":\"${property}\", \n   \"bProperty\":\"15\",\n   \"cProperty\":\"30\"\n}\n

                                                              \\${property} value:

                                                              {\n   \"aProperty\": \"10\", \n   \"bProperty\": \"20\"\n}\n

                                                              result:

                                                              {\n   \"aProperty\":\"10\", \n   \"bProperty\":\"20\",\n   \"cProperty\":\"30\"\n}\n

                                                              The ${property} directive evaluates to a JSON that will be merged with the including one. In case the including JSON as an attribute with the name equal to one of the attributes in the included JSON, the included will override the property with the same name in the including one.

                                                              In case an includeFlat directive is specified inside a JSON Array with a Feature property and the property evaluate to a JSON Array, the container array will be stripped and its values included directly inside the container Array:

                                                              [\n   \"value1\",\n   \"value2\",\n   \"value3\",\n   \"$includeFlat{${property}}\"\n]\n

                                                              \\${property} value:

                                                              [\n   \"value4\", \n   \"value5\"\n]\n

                                                              result:

                                                              [\n   \"value1\",\n   \"value2\",\n   \"value3\",\n   \"value4\",\n   \"value5\"\n]\n
                                                              "},{"location":"community/features-templating/directives/#xml-based-templates-gml","title":"XML based templates (GML)","text":"

                                                              In an XML context the two directives needs to be defined in the following way:

                                                              • <gft:includeFlat>path/to/included.xml</gft:includeFlat>.
                                                              • <gsml:specification gft:source=\"gsml:specification\">$include{includedTemplate.xml}</gsml:specification>.

                                                              In the first case the included template will replace the <gft:includeFlat> element. In the second one the included template will be placed inside the <gsml:specification> element.

                                                              "},{"location":"community/features-templating/directives/#extending-other-templates-via-merge-json-based-templates-only","title":"Extending other templates via merge (JSON based templates only)","text":"

                                                              Templates inclusion, described above, allows importing a block into another template, as is. The $merge directive instead allows getting an object and use it as a base, that will be overridden by the properties of the object it is merged into.

                                                              For example, let's assume this is a base JSON template:

                                                              {\n  \"a\": 10,\n  \"b\": \"${attribute1}\",\n  \"c\": \"${attribute2}\",\n  \"array\": [1, 2, 3]\n}\n

                                                              and this is a template extending it:

                                                              {\n  \"$merge\": \"base.json\",\n  \"a\": {\n    \"a1\": 1,\n    \"a2\": 2\n  },\n  \"b\": null,\n  \"d\": \"${customAttribute}\"\n}\n

                                                              The template actually being processed would look as follows:

                                                              {\n  \"a\": {\n    \"a1\": 1,\n    \"a2\": 2\n  },\n  \"c\": \"${attribute2}\",\n  \"array\": [1, 2, 3]\n  \"d\": \"${customAttribute}\"\n}\n

                                                              The general rules for object merging are:

                                                              • Overridden simple properties are replaced.
                                                              • Properties set to null are removed.
                                                              • Nested objects available in both trees are drilled down, being recursively merged.
                                                              • Arrays are replaced as-is, with no merging. The eventual top level features array is the only exception to this rule.
                                                              • While order of the keys is not important in JSON, the merge is processed so that the base property names are included first in the merged result, and the new ones included in the override are added after them.
                                                              • If in the overalay JSON template, are present attributes with a property interpolation directive or an expression that in turn returns a JSON, the JSON attribute tree will be merged too with the corresponding one in the base JSON tree.

                                                              The $merge directive can be used in any object, making it the root for the merge operation. This could be used as an alternative to inclusion when local customizations are needed.

                                                              "},{"location":"community/features-templating/directives/#environment-parametrization","title":"Environment parametrization","text":"

                                                              A template configuration can also be manipulated on the fly, replacing existing attributes, attributes' names and sources using the env parameter. To achieve this the attribute name, the attribute, or the source should be replaced by the env function in the following way $${env('nameOfTheEnvParameter','defaultValue')}. If in the request it is specified an env query parameter env='nameOfTheEnvParameter':'newValue', the default value will be replaced in the final output with the one specified in the request.

                                                              The functionality allows also to manipulate dynamically filters and expression. For example it is possible to change Filter arguments: \"$filter\":\"xpath('gsml:name') = env('nameOfTheEnvParameter','defaultValue').

                                                              Xpaths can be manipulated as well to be totally or partially replaced: $${xpath(env('xpath','gsml:ControlledConcept/gsml:name')} or $${xpath(strConcat('env('gsml:ControlledConcept',xpath','/gsml:name')))}.

                                                              "},{"location":"community/features-templating/directives/#dynamic-keys","title":"Dynamic keys","text":"

                                                              Keys in JSON output can also be fully dependent on feature attributes, for example:

                                                              {\n   \"${attributeA}\" : \"${attributeB}\",\n   \"$${strSubstring(attributeC, 0, 3)}\": \"$${att1 * att2}\"\n}\n

                                                              Using a key depending on feature attributes has however drawbacks: it won't be possible to use it for filtering in WFS and for queriables generation in OGC APIs, as it does not have a stable value.

                                                              "},{"location":"community/features-templating/directives/#json-based-properties","title":"JSON based properties","text":"

                                                              Certain databases have native support for JSON fields. For example, PostgreSQL has both a JSON and a JSONB type. The JSON templating machinery can recognize these fields and export them as JSON blocks, for direct substitution in the output.

                                                              It is also possible to pick a JSON attribute and use the jsonPointer function to extract either a property or a whole JSON subtree from it. See the JSON Pointer RFC for more details about valid expressions.

                                                              Here is an example of using JSON properties:

                                                              {\n   \"assets\": \"${assets}\",\n   \"links\": [\n     \"$${jsonPointer(others, '/fullLink')}\",\n     {\n       \"href\": \"$${jsonPointer(others, '/otherLink/href')}\",\n       \"rel\": \"metadata\",\n       \"title\": \"$${jsonPointer(others, '/otherLink/title')}\",\n       \"type\": \"text/xml\"\n     }\n   ]\n}\n

                                                              Some references:

                                                              • Line 1 uses assets, a property that can contain a JSON tree of any shape, which will be expanded in place.
                                                              • Line 4 inserts a full JSON object in the array. The object is a sub-tree of the others property, which is a complex JSON document with several extra properties (could be a generic containers for properties not fitting the fixed database schema).
                                                              • Line 6 and Line 8 extract from the others property specific string values.
                                                              "},{"location":"community/features-templating/directives/#array-based-properties-json-based-templates-only","title":"Array based properties (JSON based templates only)","text":"

                                                              Along JSON properties, it's not rare to find support for array based attributes in modern databases. E.g. varchar[] is a attributes containing an array of strings.

                                                              The array properties can be used as-is, and they will be expanded into a JSON array. Let's assume the keywords database column contains a list of strings, then the following template:

                                                              {\n   \"keywords\": \"${keywords}\"\n}\n

                                                              May expand into:

                                                              {\n   \"keywords\": [\"features\", \"templating\"]\n}\n

                                                              It is also possible to use an array as the source of iteration, referencing the current array item using the ${.} XPath. For example:

                                                              {\n   \"metadata\": [\n      {\n         \"$source\": \"keywords\"\n      },\n      {\n         \"type\": \"keyword\",\n         \"value\": \"${.}\"\n      }\n   ]\n}\n

                                                              The above may expand into:

                                                              {\n   \"metadata\": [\n      {\n         \"type\": \"keyword\",\n         \"value\": \"features\"\n      },\n      {\n         \"type\": \"keyword\",\n         \"value\": \"templating\"\n      }\n   ]\n}\n

                                                              In case a specific item of an array needs to be retrieved, the item function can be used, for example, the following template extracts the second item in an array (would fail if not present):

                                                              {\n   \"second\": \"$${item(keywords, 1)}\"\n}\n

                                                              There is currently no explicit support for array based columns in GML templates.

                                                              "},{"location":"community/features-templating/directives/#simplified-property-access","title":"Simplified Property Access","text":"

                                                              The features-templating plug-in provides the possibility to directly reference domain name when dealing with Complex Features and using property interpolation in a template. As an example let's use again the meteo stations use case. This is the ER diagram of the Database table involved.

                                                              The following is a GeoJSON template that directly reference table names and column name, instead of referencing the target Xpath in the AppSchema mappings.

                                                              {\n  \"$source\":\"meteo_stations\",\n  \"Identifier\":\"${id}\",\n  \"Name\":\"${common_name}\",\n  \"Code\":\"$${strConcat('STATION-', xpath('code'))}\",\n  \"Location\":\"$${toWKT(position)}\",\n  \"Temperatures\":[\n     {\n        \"$source\":\"meteo_observations\",\n        \"$filter\":\"propertyPath('->meteo_parameters.param_name') = 'temperature' AND 'yes' = env('showTemperatures','yes')\"\n     },\n     {\n        \"Timestamp\":\"${time}\",\n        \"Value\":\"${value}\"\n     }\n  ],\n  \"Pressures\":[\n     {\n        \"$source\":\"meteo_observations\",\n        \"$filter\":\"propertyPath('->meteo_parameters.param_name') = 'pressure' AND 'yes' = env('showPressures','yes')\"\n     },\n     {\n        \"Timestamp\":\"${time}\",\n        \"Value\":\"${value}\"\n     }\n  ],\n  \"Winds speed\":[\n     {\n        \"$source\":\"meteo_observations\",\n        \"$filter\":\"propertyPath('->meteo_parameters.param_name') = 'wind speed' AND 'yes' = env('showWinds','yes')\"\n     },\n     {\n        \"Timestamp\":\"${time}\",\n        \"Value\":\"${value}\"\n     }\n  ]\n}\n

                                                              As it is possible to see this template has some differences comparing to the one seen above:

                                                              • Property interpolation (${property}) and cql evaluation ($${cql}) directives are referencing the column name of the attribute that is meant to be included in the final output. The names match the ones of the columns and no namespaces prefix is being used.
                                                              • Inside the \\$\\${cql} directive instead of using an xpath function the propertyPath function is being use. It must be used when the property references domain names inside a $${cql} directive. Paths in this case are no more separated by a / but by a . dot.
                                                              • The $source directive references the table names.
                                                              • When a column/property in a table/source is referenced from the context of the upper table/source, as in all the filters in the template, the table name needs to be prefixed with a -> symbol, and column name can come next separated by a . dot. Putting it in another way: the -> signals that the next path part is a table joined to the last source defined.

                                                              Warning

                                                              the propertyPath('propertyPath') cql function is meant to be used only in the scope of this plugin. It is not currently possible to reference domain property outside the context of a template file.

                                                              This functionality is particularly useful when defining templates on top of Smart Data Loader based Complex Features.

                                                              "},{"location":"community/features-templating/directives/#controlling-attributes-with-n-cardinality","title":"Controlling Attributes With N Cardinality","text":"

                                                              When a property interpolation targets an attribute with multiple cardinality in a Complex Feature, feature templating will output the result as an array. This default behaviour can be controlled and modified with the usage of a set of CQL functions that are available in the plug-in, which allow to control how the list should be encoded in the template.

                                                              • aggregate: takes as arguments an expression (a property name or a function) that returns a list of values and a literal with the aggregation type eg. aggregate(my.property.name,'MIN'). The supported aggregation type are the following:

                                                                • MIN will return the minimum value from a list of numeric values.
                                                                • MAX will return the max value from a list of numeric values.
                                                                • AVG will return the average value from a list of numeric values.
                                                                • UNIQUE will remove duplicates values from a list of values.
                                                                • JOIN will concatenate the list of values in a single string. It accepts a parameter to specify the separator that by default is blank space: aggregate(my.property.name,'JOIN(,)') .
                                                              • stream: takes an undefined number of expressions as parameters and chain them so that each expression evaluate on top of the output of the previous expression: eg. stream(aPropertyName,aFunction,anotherPropertyName) while evaluate the aFunction on the output of aPropertyName evaluation and finally anotherPropertyName will evaluate on top of the result of aFunction.

                                                              • filter: takes a literal cql filter as a parameter and evaluates it. Every string literal value in the cql filter must be between double quotes escaped: eg. filter('aProperty = \"someValue\"').

                                                              • sort: sort the list of values in ascending or descending order. It accepts as a parameter the sort order (ASC,DESC) and optionally a property name to target the property on which the sorting should be executed. If no property name is defined the sorting will be applied on the current node on which the function evaluates: sort('DESC',nested.property), sort('ASC').

                                                              The above functions can be combined allowing fine grained control over the encoding of list values in a template. Assuming to write a template for the meteo stations use case, these are some example of the usage of the functions (simplified property access is used in the example below):

                                                              • aggregate(stream(->meteo_observations,filter('value > 35')),AVG) will compute and return the average value of all the Observation nested feature value attribute.
                                                              • aggregate(stream(->meteo_observations.->meteo_parameters,sort(\"ASC\",param_name),param_unit),JOIN(,)) will pick up the meteo_parameter nested features for each station feature, will sort them in ascending order based on the value of the param_name and will concatenate the param_unit values in a single string, comma separated.
                                                              "},{"location":"community/features-templating/directives/#template-validation","title":"Template Validation","text":"

                                                              There are two kind of validation available. The first one is done automatically every time a template is requested for the first time or after modifications occurred. It is done automatically by GeoServer and validates that all the property names being used in the template applies to the Feature Type. The second type of validation can be issued from the UI (see the configuration section) in case a JSON-LD or a GML output are request. The GML validation will validate the output against the provided SchemaLocation values. The JSON-LD validation is detailed below.

                                                              "},{"location":"community/features-templating/directives/#json-ld-validation","title":"JSON-LD Validation","text":"

                                                              The plugin provides a validation for the json-ld output against the @context defined in the template. It is possible to require it by specifying a new query parameter in the request: validation=true. The validation takes advantage form the json-ld api and performs the following steps:

                                                              • the expansion algorithm is executed against the json-ld output, expanding each features' attribute name to IRIs, removing those with no reference in the @context and the @context itself;
                                                              • the compaction algorithm is then executed on the expansion result, putting back the @context and shortens to the terms the expanded attribute names as in the original output;
                                                              • finally the result of the compaction process is compared to the original json-ld and if some attributes are missing it means that they were not referenced in the @context. An exception is thrown with a message pointing to the missing attributes.
                                                              "},{"location":"community/features-templating/installing/","title":"Installing the GeoServer FEATURES-TEMPLATING extension","text":"
                                                              1. Download the Features Templating community module from features-templating.

                                                                ::: warning ::: title Warning :::

                                                                Make sure to match the version of the extension to the version of the GeoServer instance! :::

                                                              2. Extract the contents of the archive into the WEB-INF/lib directory of the GeoServer installation.

                                                              3. The full package requires the OGC API - Features service to be available. If the server does not include it, the jar gs-features-templating-ogcapi-<version>.jar should be removed from WEB-INF/lib

                                                              "},{"location":"community/features-templating/querying/","title":"Backward Mapping","text":"

                                                              When performing queries, using CQL filters, against layers that support a templated output, it will be possible to reference the template attributes in the CQL expressions. The plugin will take care of interpreting the CQL filter and translate it, when possible, to a data source native filter. For example, if that data source is a relational database, the CQL filter will be translated to one or multiple SQL queries that will be used to retrieve only the needed data.

                                                              Consider the following GML output example:

                                                              <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<wfs:FeatureCollection xmlns:wfs=\"http://www.opengis.net/wfs\" xmlns:gml=\"http://www.opengis.net/gml\" xmlns:st=\"http://www.stations.org/1.0\" xmlns:xlink=\"http://www.w3.org/1999/xlink\" xmlns:xs=\"http://www.w3.org/2001/XMLSchema\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" numberOfFeature=\"0\" timeStamp=\"2021-07-16T08:38:50.735Z\">\n  <gml:featureMember>\n     <st:MeteoStations gml:id=\"MeteoStationsFeature.7\">\n        <st:code>Station_BOL</st:code>\n        <st:name>Bologna</st:name>\n        <st:geometry>\n           <gml:Point srsName=\"EPSG:4326\" srsDimension=\"2\">\n              <gml:pos>11.34 44.5</gml:pos>\n           </gml:Point>\n        </st:geometry>\n        <st:temperature>\n           <st:Temperature>\n              <st:time>2016-12-19T11:28:31.000Z</st:time>\n              <st:value>35.0</st:value>\n           </st:Temperature>\n        </st:temperature>\n        <st:temperature>\n           <st:Temperature>\n              <st:time>2016-12-19T11:28:55.000Z</st:time>\n              <st:value>25.0</st:value>\n           </st:Temperature>\n        </st:temperature>\n        <st:pressure>\n           <st:Pressure>\n              <st:time>2016-12-19T11:30:26.000Z</st:time>\n              <st:value>1019.0</st:value>\n           </st:Pressure>\n        </st:pressure>\n        <st:pressure>\n           <st:Pressure>\n              <st:time>2016-12-19T11:30:51.000Z</st:time>\n              <st:value>1015.0</st:value>\n           </st:Pressure>\n        </st:pressure>\n        <st:wind_speed>\n           <st:Wind_speed>\n              <st:time>2016-12-19T11:29:24.000Z</st:time>\n              <st:value>80.0</st:value>\n           </st:Wind_speed>\n        </st:wind_speed>\n     </st:MeteoStations>\n  </gml:featureMember>\n  <gml:featureMember>\n     <st:MeteoStations gml:id=\"MeteoStationsFeature.13\">\n        <st:code>Station_ALS</st:code>\n        <st:name>Alessandria</st:name>\n        <st:geometry>\n           <gml:Point srsName=\"EPSG:4326\" srsDimension=\"2\">\n              <gml:pos>8.63 44.92</gml:pos>\n           </gml:Point>\n        </st:geometry>\n        <st:temperature>\n           <st:Temperature>\n              <st:time>2016-12-19T11:26:40.000Z</st:time>\n              <st:value>20.0</st:value>\n           </st:Temperature>\n        </st:temperature>\n        <st:wind_speed>\n           <st:Wind_speed>\n              <st:time>2016-12-19T11:27:13.000Z</st:time>\n              <st:value>155.0</st:value>\n           </st:Wind_speed>\n        </st:wind_speed>\n     </st:MeteoStations>\n  </gml:featureMember>\n  <gml:featureMember>\n     <st:MeteoStations gml:id=\"MeteoStationsFeature.21\">\n        <st:code>Station_ROV</st:code>\n        <st:name>Rovereto</st:name>\n        <st:geometry>\n           <gml:Point srsName=\"EPSG:4326\" srsDimension=\"2\">\n              <gml:pos>11.05 45.89</gml:pos>\n           </gml:Point>\n        </st:geometry>\n     </st:MeteoStations>\n  </gml:featureMember>\n</wfs:FeatureCollection>\n

                                                              The following are valid CQL_FILTERS

                                                              • st:name = 'Station_BOL'.
                                                              • st:temperature.st:Temperature.st:value < 25.

                                                              Given this underlying GML template:

                                                              <gft:Template>\n<gft:Options>\n  <gft:Namespaces xmlns:st=\"http://www.stations.org/1.0\"/>\n</gft:Options>\n<st:MeteoStations gml:id=\"${@id}\">\n<st:code>$${strConcat('Station_',st:code)}</st:code>\n<st:name>${st:common_name}</st:name>\n<st:geometry>${st:position}</st:geometry>\n<st:temperature gft:isCollection=\"true\" gft:source=\"st:meteoObservations/st:MeteoObservationsFeature\" gft:filter=\"xpath('st:meteoParameters/st:MeteoParametersFeature/st:param_name') = 'temperature'\">\n  <st:Temperature>\n      <st:time>${st:time}</st:time>\n      <st:value>${st:value}</st:value>\n  </st:Temperature>\n</st:temperature>\n<st:pressure gft:isCollection=\"true\" gft:source=\"st:meteoObservations/st:MeteoObservationsFeature\"  gft:filter=\"xpath('st:meteoParameters/st:MeteoParametersFeature/st:param_name') = 'pressure'\">\n  <st:Pressure>\n      <st:time>${st:time}</st:time>\n      <st:value>${st:value}</st:value>\n  </st:Pressure>\n</st:pressure>\n<st:wind_speed gft:isCollection=\"true\" gft:source=\"st:meteoObservations/st:MeteoObservationsFeature\"  gft:filter=\"xpath('st:meteoParameters/st:MeteoParametersFeature/st:param_name') = 'wind speed'\">\n  <st:Wind_speed>\n      <st:time>${st:time}</st:time>\n      <st:value>${st:value}</st:value>\n  </st:Wind_speed>\n</st:wind_speed>\n</st:MeteoStations>\n</gft:Template>\n

                                                              The above cql_filter will be internally translated to:

                                                              • strConcat('Station_',st:code) = 'Station_BOL'.
                                                              • st:meteoObservations/st:MeteoObservationsFeature/st:MeteoParametersFeature/st:value < 25 AND st:meteoObservations/st:MeteoObservationsFeature/st:MeteoParametersFeature/st:param_name = 'temperature'.

                                                              As it is possible to see from the second example, if a template filter is defined for the value we want to filter by, the filter will be automatically included in the query.

                                                              Backwards mapping capability is available for all the output formats. Consider the following JSON-LD output example:

                                                              The following are example of valid CQL filters:

                                                              • gsml:GeologicUnit.description = 'some string value'
                                                              • name in (\"MERCIA MUDSTONE\", \"UKNOWN\")
                                                              • gsml:positionalAccuracy.valueArray1 = \"100\"
                                                              {\n  \"@context\": {\n      \"gsp\": \"http://www.opengis.net/ont/geosparql#\",\n      \"sf\": \"http://www.opengis.net/ont/sf#\",\n      \"schema\": \"https://schema.org/\",\n      \"dc\": \"http://purl.org/dc/terms/\",\n      \"Feature\": \"gsp:Feature\",\n      \"FeatureCollection\": \"schema:Collection\",\n      \"Point\": \"sf:Point\",\n      \"wkt\": \"gsp:asWKT\",\n      \"features\": {\n          \"@container\": \"@set\",\n          \"@id\": \"schema:hasPart\"\n      },\n      \"geometry\": \"sf:geometry\",\n      \"description\": \"dc:description\",\n      \"title\": \"dc:title\",\n      \"name\": \"schema:name\"\n  },\n  \"type\": \"FeatureCollection\",\n  \"features\": [\n      {\n          \"@id\": \"mf2\",\n          \"@type\": [\n              \"Feature\",\n              \"gsml:MappedFeature\",\n              \"http://vocabulary.odm2.org/samplingfeaturetype/mappedFeature\"\n          ],\n          \"name\": \"MERCIA MUDSTONE GROUP\",\n          \"gsml:positionalAccuracy\":{\n              \"value\":\"100\",\n              \"valueArray\": [\"100\",\"someStaticVal\"]\n          },\n          \"gsml:GeologicUnit\": {\n              \"@id\": \"gu.25678\",\n              \"description\": \"Olivine basalt, tuff, microgabbro, minor sedimentary rocks\",\n              \"gsml:geologicUnitType\": \"urn:ogc:def:nil:OGC::unknown\",\n              \"gsml:composition\": [\n                  {\n                      \"gsml:compositionPart\": [\n                          {\n                              \"gsml:role\": {\n                                  \"value\": \"interbedded component\",\n                                  \"@codeSpace\": \"urn:cgi:classi...\"\n                              },\n                              \"proportion\": {\n                                  \"@dataType\": \"CGI_ValueProperty\",\n                                  \"CGI_TermValue\": {\n                                      \"@dataType\": \"CGI_TermValue\",\n                                      \"value\": {\n                                          \"value\": \"significant\",\n                                          \"@codeSpace\": \"some:uri\"\n                                      }\n                                  }\n                              },\n                              \"lithology\": [\n                                  {\n                                      \"@id\": \"cc.3\",\n                                      \"name\": {\n                                          \"value\": \"name_cc_3\",\n                                          \"@lang\": \"en\"\n                                      },\n                                      \"vocabulary\": {\n                                          \"@href\": \"urn:ogc:def:nil:OGC::missing\"\n                                      }\n                                  }\n                              ]\n                          }\n                      ]\n                  },\n                  {\n                      \"gsml:compositionPart\": [\n                          {\n                              \"gsml:role\": {\n                                  \"value\": \"interbedded component\",\n                                  \"@codeSpace\": \"urn:cgi:class...\"\n                              },\n                              \"proportion\": {\n                                  \"@dataType\": \"CGI_ValueProperty\",\n                                  \"CGI_TermValue\": {\n                                      \"@dataType\": \"CGI_TermValue\",\n                                      \"value\": {\n                                          \"value\": \"minor\",\n                                          \"@codeSpace\": \"some:uri\"\n                                      }\n                                  }\n                              },\n                              \"lithology\": [\n                                  {\n                                      \"@id\": \"cc.4\",\n                                      \"name\": {\n                                          \"value\": \"name_cc_4\",\n                                          \"@lang\": \"en\"\n                                      },\n                                      \"vocabulary\": {\n                                          \"@href\": \"urn:ogc:def:nil:OGC::missing\"\n                                      }\n                                  }\n                              ]\n                          }\n                      ]\n                  }\n              ],\n              \"geometry\": {\n                  \"@type\": \"Polygon\",\n                  \"wkt\": \"POLYGON ((52.5 -1.3, 52.6 -1.3, 52.6 -1.2,...))\"\n              }\n          }\n      }\n  ]\n  }\n

                                                              The following are example of valid CQL filters:

                                                              • gsml:GeologicUnit.description = 'some string value'
                                                              • name in (\"MERCIA MUDSTONE\", \"UKNOWN\")
                                                              • gsml:positionalAccuracy.valueArray1 = \"100\"

                                                              As the last example shows, to refer to elements in arrays listing simple attributes, the index of the attribute is needed, starting from 1, in the form {attributeName}{index}, as in features.gsml:positionalAccuracy.valueArray1.

                                                              "},{"location":"community/features-templating/rest/","title":"Features Templatring Rest API","text":""},{"location":"community/features-templating/rest/#introduction","title":"Introduction","text":"

                                                              The Features Templating Rest API allows performing CRUD operation over Features Templates and Template Layer Rules.

                                                              "},{"location":"community/features-templating/rest/#template-configuration","title":"Template Configuration","text":"

                                                              /rest/featurestemplates

                                                              Finds all templates in the global (features-templating) directory or creates a new template in the global directory.

                                                              +--------+-------------------------------------------------------------------------------------------------+------------------------------------+-------------------------------------------------------------------------------------------------------------------+----------------------------------------------------------------------------------------+------------------------------------+ | Method | Consumes | Produces | Action | Supported parameters | Response | +========+=================================================================================================+====================================+===================================================================================================================+========================================================================================+====================================+ | GET | | application/xml, application/json. | List of all the templates available in the features-templating directory. | | 200. List of rules in XML or JSON. | +--------+-------------------------------------------------------------------------------------------------+------------------------------------+-------------------------------------------------------------------------------------------------------------------+----------------------------------------------------------------------------------------+------------------------------------+ | POST | application/xml, text/xml, application/json, text/json, application/xhtml+xml, application/zip. | text/plain. | Add the template in the request body (text or zip file) as a new Template in the features-templating directory. | templateName (mandatory when posting a raw template, optional when posting a zip file) | 201. Created Location header. | +--------+-------------------------------------------------------------------------------------------------+------------------------------------+-------------------------------------------------------------------------------------------------------------------+----------------------------------------------------------------------------------------+------------------------------------+

                                                              /rest/workspaces/<workspace name>/featurestemplates

                                                              Finds all templates in the workspace directory or creates a new template in the workspace directory.

                                                              +--------+-------------------------------------------------------------------------------------------------+------------------------------------+---------------------------------------------------------------------------------------------------------+----------------------------------------------------------------------------------------+------------------------------------+ | Method | Consumes | Produces | Action | Supported parameters | Response | +========+=================================================================================================+====================================+=========================================================================================================+========================================================================================+====================================+ | GET | | application/xml, application/json. | List of all the templates available in the workspace directory | | 200. List of rules in XML or JSON. | +--------+-------------------------------------------------------------------------------------------------+------------------------------------+---------------------------------------------------------------------------------------------------------+----------------------------------------------------------------------------------------+------------------------------------+ | POST | application/xml, text/xml, application/json, text/json, application/xhtml+xml, application/zip. | text/plain. | Add the template in the request body (text or zip file) as a new Template in the workspace directory. | templateName (mandatory when posting a raw template, optional when posting a zip file) | 201. Created Location header. | +--------+-------------------------------------------------------------------------------------------------+------------------------------------+---------------------------------------------------------------------------------------------------------+----------------------------------------------------------------------------------------+------------------------------------+

                                                              /rest/workspaces/<workspace name>/featuretypes/<featureType name>/featurestemplates

                                                              Finds all templates in the featuretype directory or creates a new template in the featuretype directory.

                                                              +--------+-------------------------------------------------------------------------------------------------+------------------------------------+------------------------------------------------------------------------------------------------------------+----------------------------------------------------------------------------------------+------------------------------------+ | Method | Consumes | Produces | Action | Supported parameters | Response | +========+=================================================================================================+====================================+============================================================================================================+========================================================================================+====================================+ | GET | | application/json, application/xml. | List of all the templates available in the featuretype directory | | 200. List of rules in XML or JSON. | +--------+-------------------------------------------------------------------------------------------------+------------------------------------+------------------------------------------------------------------------------------------------------------+----------------------------------------------------------------------------------------+------------------------------------+ | POST | application/xml, text/xml, application/json, text/json, application/xhtml+xml, application/zip. | text/plain. | Add the template in the request body (text or zip file) as a new Template in the Feature Type directory. | templateName (mandatory when posting a raw template, optional when posting a zip file) | 201. Created Location header. | +--------+-------------------------------------------------------------------------------------------------+------------------------------------+------------------------------------------------------------------------------------------------------------+----------------------------------------------------------------------------------------+------------------------------------+

                                                              /rest/featurestemplates/<template name>

                                                              If the template with the specified name exists in the global (features-templating) directory, returns the template or replaces the template content with the one in the request body.

                                                              +--------+-------------------------------------------------------------------------------------------------+-----------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------+--------------------+ | Method | Consumes | Produces | Action | Response | +========+=================================================================================================+===========================================================+=================================================================================================================================+====================+ | GET | | application/xml, application/json, application/xhtml+xml. | the template with the specified name if present in the features-templating directory. | 200. The template. | +--------+-------------------------------------------------------------------------------------------------+-----------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------+--------------------+ | PUT | application/xml, text/xml, application/json, text/json, application/xhtml+xml, application/zip. | text/plain. | replace the template, if found in the features-templating directory with the template in the request body (text or zip file). | 201. | +--------+-------------------------------------------------------------------------------------------------+-----------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------+--------------------+ | DELETE | | | delete the template, if found in the features-templating directory. | 204. | +--------+-------------------------------------------------------------------------------------------------+-----------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------+--------------------+

                                                              /rest/workspaces/<workspace name>/featurestemplates/<template name>

                                                              If the template with the specified name exists in the workspace directory, returns the template or replaces the template content with the one in the request body.

                                                              +--------+-------------------------------------------------------------------------------------------------+-----------------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------+--------------------+ | Method | Consumes | Produces | Action | Response | +========+=================================================================================================+===========================================================+================================================================================================================================+====================+ | GET | | application/xml, application/json, application/xhtml+xml. | the template with the specified name if present in the workspace directory. | 200. The template. | +--------+-------------------------------------------------------------------------------------------------+-----------------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------+--------------------+ | PUT | application/xml, text/xml, application/json, text/json, application/xhtml+xml, application/zip. | text/plain. | replace the existing template, if found in the workspace directory with the template in the request body (text or zip file). | 201. | +--------+-------------------------------------------------------------------------------------------------+-----------------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------+--------------------+ | DELETE | | | delete the template, if found in the workspace directory. | 204. | +--------+-------------------------------------------------------------------------------------------------+-----------------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------+--------------------+

                                                              /rest/workspaces/<workspace name>/featuretypes/<featureType name> /featurestemplates/<template name>

                                                              If the template with the specified name exists in the featuretype directory, returns the template or replaces the template content with the one in the request body.

                                                              +--------+-------------------------------------------------------------------------------------------------+-----------------------------------------------------------+----------------------------------------------------------------------------------------------------------------------------------+--------------------+ | Method | Consumes | Produces | Action | Response | +========+=================================================================================================+===========================================================+==================================================================================================================================+====================+ | GET | | application/xml, application/json, application/xhtml+xml. | the template with the specified name if present in the featuretype directory. | 200. The template. | +--------+-------------------------------------------------------------------------------------------------+-----------------------------------------------------------+----------------------------------------------------------------------------------------------------------------------------------+--------------------+ | PUT | application/xml, text/xml, application/json, text/json, application/xhtml+xml, application/zip. | text/plain. | replace the existing template, if found in the featuretype directory with the template in the request body (text or zip file). | 201. | +--------+-------------------------------------------------------------------------------------------------+-----------------------------------------------------------+----------------------------------------------------------------------------------------------------------------------------------+--------------------+ | DELETE | | | delete the template, if found in the featuretype directory. | 204. | +--------+-------------------------------------------------------------------------------------------------+-----------------------------------------------------------+----------------------------------------------------------------------------------------------------------------------------------+--------------------+

                                                              "},{"location":"community/features-templating/rest/#template-rule-configuration","title":"Template Rule Configuration","text":"

                                                              /rest/workspaces/<workspace name>/featuretypes/<featureType name>/templaterules

                                                              Finds all the configured template rules for the featuretype or creates a new one.

                                                              +--------+---------------------------------------------------------+------------------------------------+-----------------------------------------------------------------+------------------------------------+ | Method | Consumes | Produces | Action | Response | +========+=========================================================+====================================+=================================================================+====================================+ | GET | | application/xml, application/json. | List of all the template rules available for the featuretype. | 200. List of rules in XML or JSON. | +--------+---------------------------------------------------------+------------------------------------+-----------------------------------------------------------------+------------------------------------+ | POST | application/xml, text/xml, application/json, text/json. | text/plain. | Add the template rule in the request body. | 201. Created Location header. | +--------+---------------------------------------------------------+------------------------------------+-----------------------------------------------------------------+------------------------------------+

                                                              /rest/workspaces/<workspace name>/featuretypes/<featureType name> /templaterules/<rule identifier>

                                                              Finds, replaces, updates or deletes the template rule with the specified identifier.

                                                              +--------+---------------------------------------------------------+------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------------+ | Method | Consumes | Produces | Action | Response | +========+=========================================================+====================================+=========================================================================================================================================================================================================================+====================================+ | GET | | application/xml, application/json. | The rule with the specified rule identifier. | 200. List of rules in XML or JSON. | +--------+---------------------------------------------------------+------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------------+ | PUT | application/xml, text/xml, application/json, text/json. | text/plain. | Replace the rule with the specified id with the one provided in the request body. | 201. | +--------+---------------------------------------------------------+------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------------+ | PATCH | application/xml, text/xml, application/json, text/json. | text/plain. | Allows partial updates of the rule with the specified id using the fields specified in the rule provided in the request body. It uses a JSON merge patch like strategy | 201. | +--------+---------------------------------------------------------+------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------------+ | DELETE | | | Delete the rule with the specified id. | 204. | +--------+---------------------------------------------------------+------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------------+

                                                              "},{"location":"community/features-templating/rest/#data-object-transfer","title":"Data Object Transfer","text":"

                                                              Both XML and JSON are supported for transfer of data objects.

                                                              Encoding of a template rule in XML:

                                                              <Rule>\n    <ruleId>..</ruleId>\n    <priority>..</priority>\n    <templateName>..</templateName>\n    <outputFormat>..</outputFormat>\n    <cqlFilter>..</cqlFilter>\n<profileFilter>...</profileFilter>\n</Rule>\n

                                                              Encoding of a rule in JSON:

                                                              {\"Rule\": {\"ruleId\":..,\"priority\":..,\"templateName\":\"..\",\"outputFormat\":\"..\",\"cqlFilter\":\"..\",\"profileFilter\":\"..\"}}\n

                                                              When applying partial updates missing attributes/element in incoming object are left unchanged. Properties can be set to null. E.g. the following example will allow to set the profileFilter to null:

                                                              XML:

                                                              <Rule>\n  <profileFilter xsi:nil=\"true\"/>\n</Rule>\n

                                                              JSON:

                                                              {\"Rule\":{\"profileFilter\":null}}\n
                                                              "},{"location":"community/flatgeobuf/","title":"WFS FlatGeobuf output format","text":"

                                                              This section discusses the WFS FlatGeobuf output format.

                                                              • Installing WFS FlatGeobuf output format
                                                              "},{"location":"community/flatgeobuf/installing/","title":"Installing WFS FlatGeobuf output format","text":"

                                                              To install the WFS FlatGeobuf output format extension:

                                                              1. Download the flatgeobuf community extension from the appropriate nightly build. The file name is called geoserver-*-flatgeobuf-plugin.zip, where * matches the version number of GeoServer you are using.
                                                              2. Extract this these files and place the JARs in WEB-INF/lib.
                                                              3. Perform any configuration required by your servlet container, and then restart.
                                                              "},{"location":"community/gdal/","title":"GDAL based WCS Output Format","text":"

                                                              The gdal_translate based output format leverages the availability of the gdal_translate command to allow the generation of more output formats than GeoServer can natively produce. The basic idea is to dump to the file system a file that gdal_translate can translate, invoke it, zip and return the output of the translation.

                                                              This extension is thus the equivalent of the OGR extension for raster data.

                                                              "},{"location":"community/gdal/#out-of-the-box-behaviour","title":"Out of the box behaviour","text":"

                                                              Out of the box the plugin assumes the following:

                                                              • gdal_translate is available in the path
                                                              • the GDAL_DATA variable is pointing to the GDAL data directory (which stores the spatial reference information for GDAL)

                                                              In the default configuration the following formats are supported:

                                                              • JPEG-2000 part 1 (ISO/IEC 15444-1)
                                                              • Geospatial PDF
                                                              • Arc/Info ASCII Grid
                                                              • ASCII Gridded XYZ

                                                              The list might be shorter if gdal_translate has not been built with support for the above formats (for example, the default JPEG-2000 format relies on the JasPer-based GDAL driver).

                                                              Once installed in GeoServer, a bunch of new supported formats will be listed in the ServiceMetadata section of the WCS 2.0 GetCapabilities document, e.g. image/jp2 and application/pdf.

                                                              "},{"location":"community/gdal/#gdal_translate-conversion-abilities","title":"gdal_translate conversion abilities","text":"

                                                              The gdal_translate utility is usually able to convert more formats than the default setup of this output format allows for, but the exact list depends on how the utility was built from sources. To get a full list of the formats available by your ogr2ogr build just run:

                                                              gdal_translate --long-usage\n

                                                              and you'll get the full set of options usable by the program, along with the supported formats.

                                                              For example, the above produces the following output using gdal 1.11.2 compiled with libgeotiff 1.4.0, libpng 1.6, libjpeg-turbo 1.3.1, libjasper 1.900.1 and libecwj2 3.3::

                                                              Usage: gdal_translate [--help-general] [--long-usage] [-ot {Byte/Int16/UInt16/UInt32/Int32/Float32/Float64/ CInt16/CInt32/CFloat32/CFloat64}] [-strict] [-of format] [-b band] [-mask band] [-expand {gray|rgb|rgba}] [-outsize xsize[%] ysize[%]] [-unscale] [-scale[_bn] [src_min src_max [dst_min dst_max]]] [-exponent[_bn] exp_val] [-srcwin xoff yoff xsize ysize] [-projwin ulx uly lrx lry] [-epo] [-eco] [-a_srs srs_def] [-a_ullr ulx uly lrx lry] [-a_nodata value] [-gcp pixel line easting northing [elevation]] [-mo \"META-TAG=VALUE\"] [-q] [-sds] [-co \"NAME=VALUE\"]* [-stats] [-norat] src_dataset dst_dataset

                                                              GDAL 1.11.2, released 2015/02/10

                                                              The following format drivers are configured and support output: VRT: Virtual Raster GTiff: GeoTIFF NITF: National Imagery Transmission Format HFA: Erdas Imagine Images (.img) ELAS: ELAS AAIGrid: Arc/Info ASCII Grid DTED: DTED Elevation Raster PNG: Portable Network Graphics JPEG: JPEG JFIF MEM: In Memory Raster GIF: Graphics Interchange Format (.gif) XPM: X11 PixMap Format BMP: MS Windows Device Independent Bitmap PCIDSK: PCIDSK Database File PCRaster: PCRaster Raster File ILWIS: ILWIS Raster Map SGI: SGI Image File Format 1.0 SRTMHGT: SRTMHGT File Format Leveller: Leveller heightfield Terragen: Terragen heightfield ISIS2: USGS Astrogeology ISIS cube (Version 2) ERS: ERMapper .ers Labelled ECW: ERDAS Compressed Wavelets (SDK 3.x) JP2ECW: ERDAS JPEG2000 (SDK 3.x) FIT: FIT Image JPEG2000: JPEG-2000 part 1 (ISO/IEC 15444-1) RMF: Raster Matrix Format RST: Idrisi Raster A.1 INGR: Intergraph Raster GSAG: Golden Software ASCII Grid (.grd) GSBG: Golden Software Binary Grid (.grd) GS7BG: Golden Software 7 Binary Grid (.grd) R: R Object Data Store PNM: Portable Pixmap Format (netpbm) ENVI: ENVI .hdr Labelled EHdr: ESRI .hdr Labelled PAux: PCI .aux Labelled MFF: Vexcel MFF Raster MFF2: Vexcel MFF2 (HKV) Raster BT: VTP .bt (Binary Terrain) 1.3 Format LAN: Erdas .LAN/.GIS IDA: Image Data and Analysis LCP: FARSITE v.4 Landscape File (.lcp) GTX: NOAA Vertical Datum .GTX NTv2: NTv2 Datum Grid Shift CTable2: CTable2 Datum Grid Shift KRO: KOLOR Raw ARG: Azavea Raster Grid format USGSDEM: USGS Optional ASCII DEM (and CDED) ADRG: ARC Digitized Raster Graphics BLX: Magellan topo (.blx) Rasterlite: Rasterlite PostGISRaster: PostGIS Raster driver SAGA: SAGA GIS Binary Grid (.sdat) KMLSUPEROVERLAY: Kml Super Overlay XYZ: ASCII Gridded XYZ HF2: HF2/HFZ heightfield raster PDF: Geospatial PDF ZMap: ZMap Plus Grid

                                                              The full list of formats that gdal_translate is able to support is available on the GDAL site. Mind that this output format can handle only outputs that are file based and that do support creation. So, for example, you won't be able to use the PostGIS Raster output (since it's database based) or the Arc/Info Binary Grid (creation not supported).

                                                              "},{"location":"community/gdal/#customisation","title":"Customisation","text":"

                                                              If gdal_translate is not available in the default path, the GDAL_DATA environment variable is not set, or if the output formats needs tweaking, a gdal_translate.xml configuration file can be created to customize the output format. The file should be put inside a gdal folder in the root of the GeoServer data directory.

                                                              Note

                                                              GeoServer will automatically detect any change to the file and reload the configuration, without a need to restart.

                                                              The default configuration is equivalent to the following xml file:

                                                              <ToolConfiguration>\n  <executable>gdal_translate</executable>\n  <environment>\n    <variable name=\"GDAL_DATA\" value=\"/usr/local/share/gdal\" />\n  </environment>\n  <formats>\n    <Format>\n      <toolFormat>JPEG2000</toolFormat>\n      <geoserverFormat>GDAL-JPEG2000</geoserverFormat>\n      <fileExtension>.jp2</fileExtension>\n      <singleFile>true</singleFile>\n      <mimeType>image/jp2</mimeType>\n      <type>binary</type> <!-- not really needed, it's the default -->\n  <option>-co</option>\n  <option>FORMAT=JP2</option>\n    </Format>\n    <Format>\n      <toolFormat>PDF</toolFormat>\n      <geoserverFormat>GDAL-PDF</geoserverFormat>\n      <fileExtension>.pdf</fileExtension>\n      <singleFile>true</singleFile>\n      <mimeType>application/pdf</mimeType>\n      <formatAdapters>\n         <GrayAlphaToRGBA/>\n         <PalettedToRGB/>\n      </formatAdapters>\n    </Format>\n    <Format>\n      <toolFormat>AAIGrid</toolFormat>\n      <geoserverFormat>GDAL-ArcInfoGrid</geoserverFormat>\n      <fileExtension>.asc</fileExtension>\n      <singleFile>false</singleFile>\n    </Format>\n    <Format>\n      <toolFormat>XYZ</toolFormat>\n      <geoserverFormat>GDAL-XYZ</geoserverFormat>\n      <fileExtension>.txt</fileExtension>\n      <singleFile>true</singleFile>\n      <mimeType>text/plain</mimeType>\n      <type>text</type>\n    </Format>\n  </formats>\n</ToolConfiguration>\n

                                                              The file showcases all possible usage of the configuration elements:

                                                              • executable can be just gdal_translate if the command is in the path, otherwise it should be the full path to the executable. For example, on a Linux box with a custom build GDAL library might be:

                                                                <executable>/usr/local/bin/gdal_translate</executable>\n
                                                              • environment contains a list of variable elements, which can be used to define environment variables that should be set prior to invoking gdal_translate. For example, to setup a GDAL_DATA environment variable pointing to the GDAL data directory, the configuration might be:

                                                                <environment>\n <variable name=\"GDAL_DATA\" value=\"/usr/local/share/gdal\" />\n</environment>\n
                                                              • Format defines a single format, which is defined by the following tags:

                                                                • toolFormat: the name of the format to be passed to gdal_translate with the -of option (case insensitive).
                                                                • geoserverFormat: is the name of the output format as advertised by GeoServer
                                                                • fileExtension: is the extension of the file generated after the translation, if any (can be omitted)
                                                                • option: can be used to add one or more options to the gdal_translate command line. As you can see by the JPEG2000 example, each item must be contained in its own option tag. You can get a full list of options by running gdal_translate --help or by visiting the GDAL website). Also, consider that each format supports specific creation options, listed in the description page for each format (for example, here is the JPEG2000 one).
                                                                • singleFile: if true the output of the conversion is supposed to be a single file that can be streamed directly back without the need to wrap it into a zip file
                                                                • mimeType: the mime type of the file returned when using singleFile. If not specified application/octet-stream will be used as a default.
                                                                • formatAdapters: transformations on the coverage that might need to be applied in order to successfully encode the output. The transformations are applied only if their input conditions are met.

                                                              The available format adapters are:

                                                              • GrayAlphaToRGBA: expands a gray image with alpha channel to RGBA (mandatory for geospatial PDF for example)
                                                              • PallettedToRGB: expands a paletted image RGB(A) (mandatory for geospatial PDF for example)
                                                              "},{"location":"community/geomesa/","title":"GeoMesa data store","text":"

                                                              GeoMesa provides a GeoTools DataStore to access SimpleFeatures stored in Apache Accumulo.

                                                              "},{"location":"community/geopkg/","title":"GeoPackage Extension","text":"

                                                              This plugin brings in the ability to write GeoPackage files in GeoServer using WPS. Reading GeoPackage files is part of the core functionality of GeoServer, and does not require this extension.

                                                              For WMS and WFS GeoPackage output, see the GeoPKG Output<geopkgoutput> extension.

                                                              GeoPackage is an SQLite based standard format that is able to hold multiple vector and raster data layers in a single file.

                                                              The GeoServer GeoPackage extension also allows to create a completely custom made GeoPackage with multiple layers, using the GeoPackage process.

                                                              • Installing the GeoServer GeoPackage extension
                                                              • GeoPackage WPS Process
                                                              "},{"location":"community/geopkg/installing/","title":"Installing the GeoServer GeoPackage extension","text":"
                                                              1. If you haven't done already, install the WPS extension: Installing the WPS extension.

                                                              2. Download the Geopkg extension from the nightly GeoServer community module builds.

                                                                ::: warning ::: title Warning :::

                                                                Make sure to match the version of the extension to the version of the GeoServer instance! :::

                                                              3. Extract the contents of the archive into the WEB-INF/lib directory of the GeoServer installation.

                                                              "},{"location":"community/geopkg/output/","title":"GeoPackage WPS Process","text":"

                                                              A custom GeoPackage can be created with any number of tiles and features layers using the GeoPackage WPS Process (see Process Cookbook).

                                                              Warning

                                                              While the process generates a compliant GeoPackage, some abilities like generalization, style and part of the metadata export are based on unofficial extensions discussed in the Testbed 16 GeoPackage engineering report.

                                                              The WPS process takes in one parameter: contents which is an XML schema that represents the desired output.

                                                              General outline of a contents scheme:

                                                              <geopackage name=\"mygeopackage\" xmlns=\"http://www.opengis.net/gpkg\">\n    <features name=\"myfeaturelayer\" identifier=\"L01\">\n        <description>describe the layer</description>\n        <srs>EPSG:4216</srs>\n        <bbox>\n            <minx>-180</minx>\n            <miny>-90</miny>\n            <maxx>180</maxx>\n            <maxy>90</maxy>\n        </bbox>\n        <!-- ... -->\n    </features>\n\n    <tiles name=\"mytileslayer\" identifier=\"L02\">\n        <description>describe the layer</description>\n        <srs>..</srs>\n        <bbox>..</bbox>\n        <!-- ... -->\n    </tiles>\n</geopackage>\n

                                                              Each GeoPackage has a mandatory name, which will be the name of the file (with the extension .gpkg added). Each layer (features or tiles) has the following properties:

                                                              • name (mandatory): the name of the layer in the GeoPackage;
                                                              • identifier (optional): an identifier for the layer;
                                                              • description (optional): a description for the layer;
                                                              • srs ( mandatory for tiles, optional for features): coordinate reference system; for features the default is the SRS of the feature type;
                                                              • bbox ( mandatory for tiles, optional for features): the bounding box; for features the default is the bounding box of the feature type.

                                                              Outline of the features layer:

                                                              <features name=\"myfeaturelayer\" identifier=\"L01\">\n    <description>..</description>\n    <srs>..</srs>\n    <bbox>..</bbox>\n    <featuretype>myfeaturetype</featuretype>\n    <propertynames>property1, property2</propertynames>\n    <filter>..</filter>\n    <indexed>true</indexed>\n    <styles>true</styles>\n    <metadata>true</metadata>\n    <overviews>...</overviews>\n    <sort xmlns:fes=\"http://www.opengis.net/fes/2.0\">\n        <fes:SortProperty>\n            <fes:ValueReference>theGeom</fes:ValueReference>\n        </fes:SortProperty>\n    </sort>\n</features>\n
                                                              Each features layer has the following properties:
                                                              • featuretype (mandatory): the feature type
                                                              • propertynames (optional): list of comma-separated names of properties in feature type to be included (default is all properties)
                                                              • filter (optional): any OGC filter that will be applied on features before output
                                                              • indexed (optional): include spatial indexes in the output (true/false)
                                                              • styles (optional): include styles in the output (true/false). The exported structure uses the portrayal and semantic annotation extensions, as described in Testbed 16 E/R
                                                              • metadata (optional): embed metadata referred by the layer metadata links into the GeoPackage (true/false). The base metadata tables are filled with contents, while semantic annotations might be used to add extra information about the metadata itself.
                                                              • overviews (optional): adds overview tables that can speed up rendering. See more at Creating generalized tables
                                                              • sort (optional): a filter encoding fes:SortByType which allows sorting the table contents on one or more attributes. If the chosen attribute is a geometry, the table will be sorted on its GeoHash, improving access locality when using spatial indexes.

                                                              Outline of the tiles layer:

                                                              <tiles name=\"mytileslayer\" identifier=\"L02\">\n    <description>...</description>\n    <srs>..</srs>\n    <bbox>..</bbox>\n    <layers>layer1, layer2</styles>\n    <styles>style1, style2</styles>\n    <sld>path/to/file.sld</sld>\n    <sldBody>..</sldBody>\n    <format>mime/type</format>\n    <bgcolor>ffffff</bgcolor>\n    <transparent>true</transparent>\n    <coverage>\n        <minZoom>5</minZoom>\n        <maxZoom>50</maxZoom>\n        <minColumn>6</minColumn>\n        <maxColumn>60</maxColumn>\n        <minRow>7</minRow>\n        <maxRow>70</maxRow>\n    </coverage>\n    <gridset>\n        ...\n    </gridset>\n    <parameters>\n      <parameter name=\"...\">value</parameter>\n    <parameters>\n</tiles>\n
                                                              Each tiles layer has the following properties:
                                                              • layers (mandatory): comma-separated list of layers that will be included

                                                              • styles, sld, and sldbody are mutually exclusive, having one is mandatory
                                                                • styles: list of comma-separated styles to be used
                                                                • sld: path to SLD style file
                                                                • sldbody: inline SLD style file
                                                              • format (optional): mime-type of image format of tiles (image/png or image/jpeg)

                                                              • bgcolor (optional): background colour as a six-digit hexadecimal RGB value

                                                              • transparent (optional): transparency (true or false)

                                                              • coverage (optional)

                                                              • minzoom, maxzoom, minColumn, maxColumn, minRow, maxRow (all optional): set the minimum and maximum zoom level, column, and rows

                                                              • gridset (optional): see below

                                                              • parameters (optional): list of other parameters that can be used in a GetMap to produce tiles (open to all GeoServer vendor parameters)

                                                              Gridset can take on two possible (mutually exclusive) forms:

                                                              <gridset>\n    <name>mygridset</name>\n</gridset>\n

                                                              where the name of a known gridset is specified; or a custom gridset may be defined as follows:

                                                              <gridset>\n    <grids>\n        <grid>\n            <zoomlevel>1</zoomlevel>\n            <tileWidth>256</tileWidth>\n            <tileHeight>256</tileHeight>\n            <matrixWidth>4</matrixWidth>\n            <matrixHeight>4</matrixHeight>\n            <pixelXSize>0.17</pixelXSize>\n            <pixelYSize>0.17</pixelYSize>\n        </grid>\n        <grid>...</grid>\n        <!-- ... -->\n    </grids>\n</gridset>\n
                                                              "},{"location":"community/geopkg/output/#overviews","title":"Creating generalized tables","text":"

                                                              The process can create generalized tables, as described in Testbed 16 generalized tables extension.

                                                              Generalized tables are sidecar tables that typically contain less records than the original table, with the option to also generalize their geometry. These are created by adding a list of overview directives in a feature layer description, each one containing:

                                                              • name (mandatory): the generalized table name
                                                              • distance (optional): the generalization distance to create simplified geometries
                                                              • scaleDenominator: the scale denominator at which the table starts being used, in preference to the original table, and other tables with a lower scale denominator value
                                                              • filter (optional): an OGC filter removing features that are not meant to be rendered at the target scale denominator

                                                              Here is an example:

                                                              <features name=\"woodland\" identifier=\"woodland\">\n  <description>woodland</description>\n  <srs>EPSG:27700</srs>\n  <featuretype>oszoom:woodland</featuretype>\n  <indexed>true</indexed>\n  <styles>true</styles>\n  <overviews>\n    <overview>\n      <name>woodland_g1</name>\n      <scaleDenominator>80000</scaleDenominator>\n      <filter xmlns:fes=\"http://www.opengis.net/fes/2.0\">\n        <fes:Or>\n          <fes:PropertyIsEqualTo>\n            <fes:ValueReference>type</fes:ValueReference>\n            <fes:Literal>National</fes:Literal>\n          </fes:PropertyIsEqualTo>\n          <fes:PropertyIsEqualTo>\n            <fes:ValueReference>type</fes:ValueReference>\n            <fes:Literal>Regional</fes:Literal>\n          </fes:PropertyIsEqualTo>\n        </fes:Or>\n      </filter>\n    </overview>\n    <overview>\n      <name>woodland_g2</name>\n      <scaleDenominator>320000</scaleDenominator>\n      <filter xmlns:fes=\"http://www.opengis.net/fes/2.0\">\n        <fes:PropertyIsEqualTo>\n          <fes:ValueReference>type</fes:ValueReference>\n          <fes:Literal>National</fes:Literal>\n        </fes:PropertyIsEqualTo>\n      </filter>\n    </overview>\n  </overviews>\n</features>\n
                                                              "},{"location":"community/geostyler/","title":"GeoStyler","text":"

                                                              Note: This plugin is maintained and hosted externally on GitHub.

                                                              It creates an extra tab in the style editor with a graphical style editor.

                                                              The GeoStyler is a set of JavaScript packages that can be used to edit and convert various style formats.

                                                              When editing a style in the GeoStyler the SLD code editor is automatically refreshed and vice versa, so you can just edit the style and then apply/save it as usual.

                                                              If you run into trouble using the GeoStyler module or have some suggestions feel free to open an issue in the GeoStyler repository.

                                                              "},{"location":"community/graticules/","title":"Graticule Extension","text":"

                                                              This module allows GeoServer to add graticules or grids to a WMS (or to allow them to be downloaded as WFS). The extension includes a vector process that can transform the grid lines to label points based on a bounding box, to allow adding labels in WMS images (this reqiures the WPS module to be present).

                                                              "},{"location":"community/graticules/#installing-the-graticule-extension","title":"Installing the graticule extension","text":"
                                                              1. Download the graticule extension from the nightly GeoServer community module builds.

                                                                ::: warning ::: title Warning :::

                                                                Make sure to match the version of the extension to the version of the GeoServer instance! :::

                                                              2. Extract the contents of the archive into the WEB-INF/lib directory of the GeoServer installation.

                                                              "},{"location":"community/graticules/#checking-if-the-extension-is-enabled","title":"Checking if the extension is enabled","text":"

                                                              Once the extension is installed, the new graticule store should show up in the New data source page:

                                                              "},{"location":"community/graticules/#creating-a-graticule-data-source","title":"Creating a Graticule Data Source","text":"

                                                              A new graticule store is created by providing a name, optional description and the a bounding box (which can be calculated automatically from the CRS), a Coordinate Reference System and a series of steps separated by commas.

                                                              The bounding box will set the limits of the grid when the user has zoomed out to small scales, while the CRS will be used to determine the values of the grid lines. The list of steps will be used to provide a more detailed grid as the user zooms in to larger scale maps. Each step is used to define a level of grid with a gap of step units between the gaps.

                                                              "},{"location":"community/graticules/#creating-a-new-style-for-graticule","title":"Creating a new style for graticule","text":"

                                                              Displaying a graticule in a sensible way will require creating a custom style to control the line appearance, the labels, and the visualization hierarchy if multiple levels of graticule are used. This can lead to complex styles, which can be tamed by leveraging the available attributes along with filter functions.

                                                              Let's assume one has a graticule with 5 levels of lines at different resolutions (e.g., 1, 5, 10, 20 and 30 degrees spacing), and wants to display them as follows:

                                                              • level 0: scale denominator lower than 1M
                                                              • level 1: scale denominator between 1M and 20M
                                                              • level 2: scale denominator between 20M and 100M
                                                              • level 3: scale denominator between 10M and 400M
                                                              • level 4: scale denominator higher than 400M

                                                              The following style would be used, using a single Rule, by leveraging the Categorize function along with the wms_scale_denominator environment variable (Variable substitution in SLD):

                                                              <?xml version=\"1.0\" encoding=\"ISO-8859-1\"?>\n<StyledLayerDescriptor version=\"1.0.0\"\n                       xsi:schemaLocation=\"http://www.opengis.net/sld http://schemas.opengis.net/sld/1.0.0/StyledLayerDescriptor.xsd\"\n                       xmlns=\"http://www.opengis.net/sld\" xmlns:ogc=\"http://www.opengis.net/ogc\"\n                       xmlns:xlink=\"http://www.w3.org/1999/xlink\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\">\n\n  <NamedLayer>\n    <Name>graticule</Name>\n    <UserStyle>\n      <FeatureTypeStyle>\n        <Name>name</Name>\n        <Rule>\n          <ogc:Filter>\n            <ogc:PropertyIsEqualTo>\n              <ogc:PropertyName>level</ogc:PropertyName>\n              <ogc:Function name=\"Categorize\">\n                <ogc:Function name=\"env\"><ogc:Literal>wms_scale_denominator</ogc:Literal></ogc:Function>\n                <ogc:Literal>0</ogc:Literal>\n                <ogc:Literal>1000000</ogc:Literal>\n                <ogc:Literal>1</ogc:Literal>\n                <ogc:Literal>20000000</ogc:Literal>\n                <ogc:Literal>2</ogc:Literal>\n                <ogc:Literal>100000000</ogc:Literal>\n                <ogc:Literal>3</ogc:Literal>\n                <ogc:Literal>400000000</ogc:Literal>\n                <ogc:Literal>4</ogc:Literal>\n              </ogc:Function>\n            </ogc:PropertyIsEqualTo>\n          </ogc:Filter>\n          <LineSymbolizer>\n            <Stroke>\n              <CssParameter name=\"stroke\">#666666</CssParameter>\n              <CssParameter name=\"stroke-dasharray\">2.0 2.0</CssParameter>\n            </Stroke>\n          </LineSymbolizer>\n        </Rule>        \n      </FeatureTypeStyle>\n\n    </UserStyle>\n  </NamedLayer>\n</StyledLayerDescriptor>\n

                                                              If some important lines are meant to be displayed with solid line rather than dashed, it's possible to use a function to keep the style compact, rather than duplicating the whole rule. The following example makes the equator and the prime meridian solid lines, while keeping the rest dashed:

                                                              <LineSymbolizer>\n  <Stroke>\n    <CssParameter name=\"stroke\">#666666</CssParameter>\n    <CssParameter name=\"stroke-dasharray\">\n      <ogc:Function name=\"if_then_else\">\n        <ogc:Function name=\"equalTo\">\n          <ogc:PropertyName>value</ogc:PropertyName>\n          <ogc:Literal>0</ogc:Literal>\n        </ogc:Function>  \n        <ogc:Literal>0</ogc:Literal>\n        <ogc:Literal>3 3</ogc:Literal>\n      </ogc:Function>\n    </CssParameter>\n  </Stroke>\n</LineSymbolizer>\n

                                                              Finally, labelling can be a tricky job. A rendering transform is provided to help with this, vec:GraticuleLabelPoint, which will take the grid lines and return a point at ends of each gridline, preserving the attributes of the original line, but adding extra ones that can be used to simplify the labelling process:

                                                              • \"top\" indicates if a label is at the top of the line (true) or at the bottom (false) of a vertical line
                                                              • \"left\" indicates if a label is at the left of the line (true) or at the right (false) of a horizontal line
                                                              • \"anchorX\", \"anchorY\" provides a suitable value to anchor the label inside the grid
                                                              • \"offsetX\" and \"offsetY\" provides a suitable value to offset the label from the anchor point, again to keep labels inside the grid

                                                              The process itself takes the following parameters:

                                                              • \"grid\" is the grid lines being processed (the graticule layer).
                                                              • \"boundingBox\" is the bounding box of the map being rendered, which is used to clip lines and to calculate the label points. This parameter is optional, if missing the labels will be generated at the end of the graticule lines no matter what the display area is. For un-tiled maps, the usage of \"boundingBox\" helps having the labels as a reference in every map, while for tiled maps it's better to omit it, or the labels will be repeated at the border of every (meta)tile.
                                                              • \"offset\" is the offset of the label from the grid line (used to compute the values of \"offsetX\" and \"offsetY\"), which can be provided using the current request bounding box using the wms_bbox environment variable (Variable substitution in SLD).
                                                              • \"positions\" indicates which groups of labels should be generated, and can be one of \"top\", \"bottom\", \"left\", \"right\" or \"topleft\", \"topright\", \"bottomleft\", \"bottomright\", or the default value \"both\" which generates labels on all four sides of the map.

                                                              Leveraging this process, the labels can be generated using the following style:

                                                              <FeatureTypeStyle>\n  <Name>label</Name>\n  <Transformation>\n    <ogc:Function name=\"vec:GraticuleLabelPoint\">\n      <ogc:Function name=\"parameter\">\n        <ogc:Literal>grid</ogc:Literal>\n      </ogc:Function>\n      <ogc:Function name=\"parameter\">\n        <ogc:Literal>boundingBox</ogc:Literal>\n        <ogc:Function name=\"env\">\n          <ogc:Literal>wms_bbox</ogc:Literal>\n        </ogc:Function>\n      </ogc:Function>\n      <ogc:Function name=\"parameter\">\n        <ogc:Literal>offset</ogc:Literal>\n        <ogc:Literal>4</ogc:Literal>\n      </ogc:Function>\n    </ogc:Function>\n  </Transformation>\n  <Rule>\n    <TextSymbolizer>\n      <Label>\n        <ogc:PropertyName>label</ogc:PropertyName>\n      </Label>\n      <Font>\n        <CssParameter name=\"font-family\">Noto Sans</CssParameter>\n        <CssParameter name=\"font-size\">12</CssParameter>\n        <CssParameter name=\"font-style\">normal</CssParameter>\n      </Font>\n      <LabelPlacement>\n        <PointPlacement>\n          <AnchorPoint>\n            <AnchorPointX><ogc:PropertyName>anchorX</ogc:PropertyName></AnchorPointX>\n            <AnchorPointY><ogc:PropertyName>anchorY</ogc:PropertyName></AnchorPointY>\n          </AnchorPoint>\n          <Displacement>\n            <DisplacementX><ogc:PropertyName>offsetX</ogc:PropertyName></DisplacementX>\n            <DisplacementY><ogc:PropertyName>offsetY</ogc:PropertyName></DisplacementY>\n          </Displacement>\n        </PointPlacement>\n      </LabelPlacement>\n      <Halo>\n        <Radius>1</Radius>\n        <Fill>\n          <CssParameter name=\"fill\">#FFFFFF</CssParameter>\n        </Fill>\n      </Halo>\n      <Fill>\n        <CssParameter name=\"fill\">#000000</CssParameter>\n      </Fill>\n      <VendorOption name=\"partials\">true</VendorOption>\n    </TextSymbolizer>\n  </Rule>      \n</FeatureTypeStyle>\n
                                                              "},{"location":"community/gsr/","title":"GSR Extension","text":"

                                                              This plugin provides a GeoService REST compatibility API. Please reference http://geoservices.github.io/ for authoritative information on the GeoServices API. This document describes only the GeoServer extension.

                                                              • Installing the GeoServer GSR extension
                                                              • GSR Usage
                                                              • Functionality
                                                              • Examples
                                                              "},{"location":"community/gsr/dynamicMapLayer/","title":"Dynamic Map Layer Examples","text":""},{"location":"community/gsr/dynamicMapLayer/#dynamic-map-layer","title":"Dynamic Map Layer","text":"
                                                              <html>\n<head>\n    <meta charset=\"utf-8\">\n    <meta name=\"viewport\" content=\"initial-scale=1,maximum-scale=1,user-scalable=no\">\n    <title>MapImageLayer - create dynamic map layers - 4.5</title>\n\n    <link rel=\"stylesheet\" href=\"https://js.arcgis.com/4.5/esri/css/main.css\">\n    <script src=\"https://js.arcgis.com/4.5/\"></script>\n\n    <style>\n        html,\n        body,\n        #viewDiv {\n            padding: 0;\n            margin: 0;\n            height: 100%;\n            width: 100%;\n        }\n\n        #info-div {\n            background-color: white;\n            border-radius: 8px;\n            padding: 8px;\n            opacity: 0.92;\n        }\n    </style>\n\n    <script>\n        require([\"esri/config\"], function (esriConfig) {\n            esriConfig.request.corsEnabledServers.push(\"localhost:8080\");\n        });\n        require([\n            \"esri/Map\",\n            \"esri/views/MapView\",\n            \"esri/layers/MapImageLayer\",\n            \"esri/widgets/Legend\",\n            \"dojo/domReady!\"\n        ], function (Map, MapView, MapImageLayer, Legend) {\n\n            var layer = new MapImageLayer({\n                url: \"http://localhost:8080/geoserver/gsr/services/topp/MapServer/3\",\n                title: \"Topp\"\n            });\n\n            /*****************************************************************\n             * Add the layer to a map\n             *****************************************************************/\n\n            var map = new Map({\n                layers: [layer]\n            });\n\n            var view = new MapView({\n                container: \"viewDiv\",\n                map: map,\n                extent: { // autocasts as new Extent()\n                    xmin: 143.83482400000003,\n                    ymin: -43.648056,\n                    xmax: 148.47914100000003,\n                    ymax: -39.573891,\n                    spatialReference: 4326\n                }\n            });\n        });\n    </script>\n\n</head>\n\n<body>\n<div id=\"viewDiv\"></div>\n<div id=\"info-div\">\n</div>\n</body>\n\n</html>\n\n<!-- Esri\u00ae, ArcGIS\u00ae and ArcGIS Online\u00ae  are trademarks, registered trademarks, or service marks of Esri in the United States, the European Community, or certain other jurisdictions. Other companies and products mentioned may be trademarks of their respective owners.-->\n
                                                              "},{"location":"community/gsr/dynamicMapLayer/#dynamic-map-layer-wholeservice","title":"Dynamic Map Layer Wholeservice","text":"
                                                              <html>\n<head>\n    <meta charset=\"utf-8\">\n    <meta name=\"viewport\" content=\"initial-scale=1,maximum-scale=1,user-scalable=no\">\n    <title>MapImageLayer - create dynamic map layers - 4.5</title>\n\n    <link rel=\"stylesheet\" href=\"https://js.arcgis.com/4.5/esri/css/main.css\">\n    <script src=\"https://js.arcgis.com/4.5/\"></script>\n\n    <style>\n        html,\n        body,\n        #viewDiv {\n            padding: 0;\n            margin: 0;\n            height: 100%;\n            width: 100%;\n        }\n\n        #info-div {\n            background-color: white;\n            border-radius: 8px;\n            padding: 8px;\n            opacity: 0.92;\n        }\n    </style>\n\n    <script>\n        require([\"esri/config\"], function (esriConfig) {\n            esriConfig.request.corsEnabledServers.push(\"localhost:8080\");\n        });\n        require([\n            \"esri/Map\",\n            \"esri/views/MapView\",\n            \"esri/layers/MapImageLayer\",\n            \"esri/widgets/Legend\",\n            \"dojo/domReady!\"\n        ], function (Map, MapView, MapImageLayer, Legend) {\n\n            var layer = new MapImageLayer({\n                url: \"http://localhost:8080/geoserver/gsr/services/tiger/MapServer\",\n                title: \"Census Demographics\"\n            });\n\n            /*****************************************************************\n             * Add the layer to a map\n             *****************************************************************/\n\n            var map = new Map({\n                layers: [layer]\n            });\n\n            var view = new MapView({\n                container: \"viewDiv\",\n                map: map,\n                extent: { // autocasts as new Extent()\n                    xmin: -74.0118315772888,\n                    ymin: 40.70754683896324,\n                    xmax: -74.00153046439813,\n                    ymax: 40.719885123828675,\n                    spatialReference: 4326\n                }\n            });\n        });\n    </script>\n\n</head>\n\n<body>\n<div id=\"viewDiv\"></div>\n<div id=\"info-div\">\n    Select a demographic variable<br><br>\n    <select id=\"layer-select\">\n        <option value=\"0\">Population density</option>\n        <option value=\"1\" selected>Renter occupied units</option>\n        <option value=\"2\">Median age</option>\n    </select>\n</div>\n</body>\n\n</html>\n\n<!-- Esri\u00ae, ArcGIS\u00ae and ArcGIS Online\u00ae  are trademarks, registered trademarks, or service marks of Esri in the United States, the European Community, or certain other jurisdictions. Other companies and products mentioned may be trademarks of their respective owners.-->\n
                                                              "},{"location":"community/gsr/examples/","title":"Examples","text":"

                                                              Follows a list of examples using the official JS client.

                                                              • Feature Layer Examples
                                                              • Dynamic Map Layer Examples
                                                              • Feature Table Example
                                                              "},{"location":"community/gsr/featureLayer/","title":"Feature Layer Examples","text":""},{"location":"community/gsr/featureLayer/#fema-example","title":"Fema example","text":"
                                                              <html>\n<head>\n    <meta charset=\"utf-8\">\n    <meta name=\"viewport\" content=\"initial-scale=1,maximum-scale=1,user-scalable=no\">\n    <title>FeatureLayer - 4.5</title>\n\n    <link rel=\"stylesheet\" href=\"https://js.arcgis.com/4.11/esri/css/main.css\">\n    <script src=\"https://js.arcgis.com/4.11/\"></script>\n\n    <style>\n        html,\n        body,\n        #viewDiv {\n            padding: 0;\n            margin: 0;\n            height: 100%;\n            width: 100%;\n        }\n    </style>\n\n    <script>\n        require([\n                \"esri/Map\",\n                \"esri/views/MapView\",\n                \"esri/layers/FeatureLayer\",\n                \"dojo/domReady!layers-featurelayer\"\n            ],\n            function (Map, MapView,\n                      FeatureLayer) {\n\n                var map = new Map({});\n\n                var view = new MapView({\n                    container: \"viewDiv\",\n                    map: map,\n                    extent: { // autocasts as new Extent()\n                        xmin: -107.97,\n                        ymin: 25.46,\n                        xmax: -91.28,\n                        ymax: 37.74,\n                        spatialReference: 4326\n                    }\n                });\n\n                /********************\n                 * Add feature layer\n                 ********************/\n                var featureLayer2 = new FeatureLayer({\n                    url: \"http://localhost:8080/geoserver/gsr/services/cite/FeatureServer/0\",\n                    outFields: [\"*\"]\n                });\n\n                map.add(featureLayer2);\n\n            });\n\n        require([\"esri/config\"], function (esriConfig) {\n            esriConfig.request.corsEnabledServers.push(\"localhost:8080\");\n        });\n    </script>\n</head>\n\n<body>\n<div id=\"viewDiv\"></div>\n</body>\n\n</html>\n\n<!-- Esri\u00ae, ArcGIS\u00ae and ArcGIS Online\u00ae  are trademarks, registered trademarks, or service marks of Esri in the United States, the European Community, or certain other jurisdictions. Other companies and products mentioned may be trademarks of their respective owners.-->\n
                                                              "},{"location":"community/gsr/featureLayer/#point-example","title":"Point example","text":"
                                                              <html>\n<head>\n    <meta charset=\"utf-8\">\n    <meta name=\"viewport\" content=\"initial-scale=1,maximum-scale=1,user-scalable=no\">\n    <title>FeatureLayer - 4.5</title>\n\n    <link rel=\"stylesheet\" href=\"https://js.arcgis.com/4.5/esri/css/main.css\">\n    <script src=\"https://js.arcgis.com/4.5/\"></script>\n\n    <style>\n        html,\n        body,\n        #viewDiv {\n            padding: 0;\n            margin: 0;\n            height: 100%;\n            width: 100%;\n        }\n    </style>\n\n    <script>\n        require([\n                \"esri/Map\",\n                \"esri/views/MapView\",\n                \"esri/layers/FeatureLayer\",\n                \"dojo/domReady!layers-featurelayer\"\n            ],\n            function (Map, MapView,\n                      FeatureLayer) {\n\n                var map = new Map({});\n\n                var view = new MapView({\n                    container: \"viewDiv\",\n                    map: map,\n\n                    extent: { // autocasts as new Extent()\n                        xmin: -103.8725637911543,\n                        ymin: 44.37740330855979,\n                        xmax: -103.63794182141925,\n                        ymax: 44.48804280772808,\n                        spatialReference: 4326\n                    }\n                });\n\n                /********************\n                 * Add feature layer\n                 ********************/\n\n                    // Carbon storage of trees in Warren Wilson College.\n                var featureLayer = new FeatureLayer({\n                        url: \"http://localhost:8080/geoserver/gsr/services/sf/FeatureServer/0\"\n                    });\n\n                map.add(featureLayer);\n\n            });\n\n        require([\"esri/config\"], function (esriConfig) {\n            esriConfig.request.corsEnabledServers.push(\"localhost:8080\");\n        });\n    </script>\n</head>\n\n<body>\n<div id=\"viewDiv\"></div>\n</body>\n\n</html>\n\n<!-- Esri\u00ae, ArcGIS\u00ae and ArcGIS Online\u00ae  are trademarks, registered trademarks, or service marks of Esri in the United States, the European Community, or certain other jurisdictions. Other companies and products mentioned may be trademarks of their respective owners.-->\n
                                                              "},{"location":"community/gsr/featureLayer/#polygon-example","title":"Polygon example","text":"
                                                              <html>\n<head>\n    <meta charset=\"utf-8\">\n    <meta name=\"viewport\" content=\"initial-scale=1,maximum-scale=1,user-scalable=no\">\n    <title>FeatureLayer - 4.5</title>\n\n    <link rel=\"stylesheet\" href=\"https://js.arcgis.com/4.5/esri/css/main.css\">\n    <script src=\"https://js.arcgis.com/4.5/\"></script>\n\n    <style>\n        html,\n        body,\n        #viewDiv {\n            padding: 0;\n            margin: 0;\n            height: 100%;\n            width: 100%;\n        }\n    </style>\n\n    <script>\n        require([\n                \"esri/Map\",\n                \"esri/views/MapView\",\n                \"esri/layers/FeatureLayer\",\n                \"dojo/domReady!layers-featurelayer\"\n            ],\n            function (Map, MapView,\n                      FeatureLayer) {\n\n                var map = new Map({});\n\n                var view = new MapView({\n                    container: \"viewDiv\",\n                    map: map,\n                    extent: { // autocasts as new Extent()\n                        xmin: -74.255591362951,\n                        ymin: 40.4961153956091,\n                        xmax: -73.7000090634675,\n                        ymax: 40.915532775817,\n                        spatialReference: 4326\n                    }\n                });\n\n                /********************\n                 * Add feature layer\n                 ********************/\n                var featureLayer2 = new FeatureLayer({\n                    url: \"http://localhost:8080/geoserver/gsr/services/cite/FeatureServer/0\",\n                    outFields: [\"*\"]\n                });\n\n                map.add(featureLayer2);\n\n            });\n\n        require([\"esri/config\"], function (esriConfig) {\n            esriConfig.request.corsEnabledServers.push(\"localhost:8080\");\n        });\n    </script>\n</head>\n\n<body>\n<div id=\"viewDiv\"></div>\n</body>\n\n</html>\n\n<!-- Esri\u00ae, ArcGIS\u00ae and ArcGIS Online\u00ae  are trademarks, registered trademarks, or service marks of Esri in the United States, the European Community, or certain other jurisdictions. Other companies and products mentioned may be trademarks of their respective owners.-->\n
                                                              "},{"location":"community/gsr/featureLayer/#polygon-non-cors-example","title":"Polygon non cors example","text":"
                                                              <html>\n<head>\n    <meta charset=\"utf-8\">\n    <meta name=\"viewport\" content=\"initial-scale=1,maximum-scale=1,user-scalable=no\">\n    <title>FeatureLayer - 4.5</title>\n\n    <link rel=\"stylesheet\" href=\"https://js.arcgis.com/4.5/esri/css/main.css\">\n    <script src=\"https://js.arcgis.com/4.5/\"></script>\n\n    <style>\n        html,\n        body,\n        #viewDiv {\n            padding: 0;\n            margin: 0;\n            height: 100%;\n            width: 100%;\n        }\n    </style>\n\n    <script>\n        require([\n                \"esri/Map\",\n                \"esri/views/MapView\",\n                \"esri/layers/FeatureLayer\",\n                \"dojo/domReady!layers-featurelayer\"\n            ],\n            function (Map, MapView,\n                      FeatureLayer) {\n\n                var map = new Map({});\n\n                var view = new MapView({\n                    container: \"viewDiv\",\n                    map: map,\n                    extent: { // autocasts as new Extent()\n                        xmin: -74.255591362951,\n                        ymin: 40.4961153956091,\n                        xmax: -73.7000090634675,\n                        ymax: 40.915532775817,\n                        spatialReference: 4326\n                    }\n                });\n\n                /********************\n                 * Add feature layer\n                 ********************/\n\n                var featureLayer2 = new FeatureLayer({\n                    url: \"http://localhost:9191/geoserver/gsr/services/cite/FeatureServer/0\",\n                    outFields: [\"*\"]\n                });\n\n                map.add(featureLayer2);\n\n            });\n    </script>\n</head>\n\n<body>\n<div id=\"viewDiv\"></div>\n</body>\n\n</html>\n\n<!-- Esri\u00ae, ArcGIS\u00ae and ArcGIS Online\u00ae  are trademarks, registered trademarks, or service marks of Esri in the United States, the European Community, or certain other jurisdictions. Other companies and products mentioned may be trademarks of their respective owners.-->\n
                                                              "},{"location":"community/gsr/featureTable/","title":"Feature Table Example","text":"
                                                              <html>\n<head>\n  <meta charset=\"utf-8\">\n  <meta name=\"viewport\" content=\"initial-scale=1,maximum-scale=1,user-scalable=no\">\n  <title>Intro to PopupTemplate - 4.8</title>\n\n  <style>\n    html,\n    body,\n    #viewDiv {\n      padding: 0;\n      margin: 0;\n      height: 100%;\n      width: 100%;\n    }\n  </style>\n\n  <link rel=\"stylesheet\" href=\"https://js.arcgis.com/4.8/esri/css/main.css\">\n  <script src=\"https://js.arcgis.com/4.8/\"></script>\n\n  <script>\n    require([\n      \"esri/Map\",\n      \"esri/layers/FeatureLayer\",\n      \"esri/views/MapView\",\n      \"dojo/domReady!\"\n    ], function(\n      Map,\n      FeatureLayer,\n      MapView\n    ) {\n\n      // Create the map\n      var map = new Map({\n        basemap: \"osm\"\n      });\n\n      // Create the MapView\n      var view = new MapView({\n        container: \"viewDiv\",\n        map: map,\n        extent: { // autocasts as new Extent()\n            xmin: -74.255591362951,\n            ymin: 40.4961153956091,\n            xmax: -73.7000090634675,\n            ymax: 40.915532775817,\n            spatialReference: 4326\n        },\n      });\n\n      /*************************************************************\n       * The PopupTemplate content is the text that appears inside the\n       * popup. {fieldName} can be used to reference the value of an\n       * attribute of the selected feature. HTML elements can be used\n       * to provide structure and styles within the content. The\n       * fieldInfos property is an array of objects (each object representing\n       * a field) that is use to format number fields and customize field\n       * aliases in the popup and legend.\n       **************************************************************/\n\n      var template = { // autocasts as new PopupTemplate()\n        title: \"Boroughs in NY\",\n        content: [{\n          // It is also possible to set the fieldInfos outside of the content\n          // directly in the popupTemplate. If no fieldInfos is specifically set\n          // in the content, it defaults to whatever may be set within the popupTemplate.\n          type: \"fields\",\n          fieldInfos: [{\n            fieldName: \"boro_name\",\n            label: \"Borough Name\",\n            visible: true\n          }, {\n            fieldName: \"shape_area\",\n            label: \"Borough Area\",\n            visible: true,\n            format: {\n              digitSeparator: true,\n              places: 0\n            }\n          }, {\n            fieldName: \"shape_leng\",\n            label: \"Borough Length\",\n            visible: true,\n            format: {\n              digitSeparator: true,\n              places: 0\n            }\n          }]\n        }]\n      };\n\n      // Reference the popupTemplate instance in the\n      // popupTemplate property of FeatureLayer\n      var featureLayer = new FeatureLayer({\n        url: \"http://localhost:8080/geoserver/gsr/services/cite/FeatureServer/0\",\n        outFields: [\"*\"],\n        popupTemplate: template\n      });\n      map.add(featureLayer);\n    });\n    require([\"esri/config\"], function (esriConfig) {\n            esriConfig.request.corsEnabledServers.push(\"localhost:8080\");\n        });\n  </script>\n</head>\n\n<body>\n  <div id=\"viewDiv\"></div>\n</body>\n\n</html>\n\n<!-- Esri\u00ae, ArcGIS\u00ae and ArcGIS Online\u00ae  are trademarks, registered trademarks, or service marks of Esri in the United States, the European Community, or certain other jurisdictions. Other companies and products mentioned may be trademarks of their respective owners.-->\n
                                                              "},{"location":"community/gsr/functionality/","title":"Functionality","text":""},{"location":"community/gsr/functionality/#formats","title":"Formats","text":"

                                                              While the ArcGIS\u00ae implementation of GeoServices supports multiple file formats, all responses from the GeoServer plugin use JSON (for example, browser-friendly HTML is not provided). The ?f=json parameter specifying JSON is still required. Moreover, since at the moment there is no support for pjson output format, if client specifies a f=pjson parameter a normal JSON will be returned.

                                                              Note

                                                              Esri\u00ae, ArcGIS\u00ae and ArcGIS Online\u00ae are trademarks, registered trademarks, or service marks of Esri in the United States, the European Community, or certain other jurisdictions. Other companies and products mentioned may be trademarks of their respective owners.

                                                              "},{"location":"community/gsr/functionality/#capabilities","title":"Capabilities","text":"
                                                              • Catalog: yes
                                                              • Map:
                                                                • All layers and tables. Supported.
                                                                • Attachment. Not supported.
                                                                • Attachment info. Not supported.
                                                                • Dynamic Layer/Table. Not supported.
                                                                • Estimate export tile size. Not supported.
                                                                • Export map. Not supported.
                                                                • Export tiles. Not supported.
                                                                • Service extension. Not supported.
                                                                • Feature (dynamic layer). Not supported.
                                                                • Feature (layer). Not supported.
                                                                • Find. Not supported.
                                                                • Generate KML. Not supported.
                                                                • Generate renderer (Dynamic layer). Not supported.
                                                                • Generate renderer (Layer). Not supported.
                                                                • HTML Popup (Dynamic layer). Not supported.
                                                                • HTML Popup (Layer). Not supported.
                                                                • Identify. Not supported.
                                                                • Image. Not supported.
                                                                • KML Image. Not supported.
                                                                • Layer/Table. Supported.
                                                                • Legend. Supported.
                                                                • Map tile. Not supported.
                                                                • Map service input. Not supported.
                                                                • Map service job. Not supported.
                                                                • Map service result. Not supported.
                                                                • Non-geospatial filters. Not supported
                                                                • Requests to feature layers in non-native spatial reference systems. Not supported.
                                                                • Query (Dynamic layer.) Not supported.
                                                                • Query (Layer.) Supported.
                                                                • Query related records (Dynamic layer.) Not supported.
                                                                • Query related records (Layer.) Not supported.
                                                                • WMTS. Not supported. (GeoServer does support this, but via GeoWebCache integration rather than the GeoServices extension.)
                                                                • WMTS Capabilities. Not supported. (GeoServer does support this, but via GeoWebCache integration rather than the GeoServices extension.)
                                                                • WMTS Tile. Not supported. (GeoServer does support this, but via GeoWebCache integration rather than the GeoServices extension.)
                                                              "},{"location":"community/gsr/functionality/#technical-limitations","title":"Technical Limitations","text":""},{"location":"community/gsr/functionality/#features","title":"Features","text":"

                                                              While GeoServer supports fields of arbitrary type (determined by the data store) the GeoServices REST API constrains field types to a short list of types.

                                                              The GeoServer plugin maintains a mapping between these types and native Java classes in the FieldTypeEnum class. Fields whose types are not translatable will be omitted from responses.

                                                              "},{"location":"community/gsr/functionality/#layer","title":"Layer","text":"

                                                              GeoServer does not model layers the same way that they are presented in the GeoServices REST API. GeoServer layers may have multiple associated styles, while GeoServices allows for one style per layer. The GeoServer plugin uses the \"default\" style for the layer and ignores any alternative styles. GeoServer also has no concept corresponding to the \"sublayers\" supported by GeoServices.

                                                              "},{"location":"community/gsr/functionality/#styles","title":"Styles","text":"

                                                              GeoServer does not model styles the same way that they are presented in the GeoServices REST API. GeoServer styles use the SLD format, which allows a wide variety of conditional styling, while \"Renderers\" in the GeoServices REST API are much more constrained. The GeoServices plugin checks for SLD styles conforming to a small number of patterns and converts these to equivalent renderers, but when an SLD uses capabilities with no analog in GeoServices a simple default style will be advertised instead.

                                                              "},{"location":"community/gsr/installing/","title":"Installing the GeoServer GSR extension","text":"
                                                              1. Download the extension from the nightly GeoServer community module builds gsr.

                                                                ::: warning ::: title Warning :::

                                                                Make sure to match the version of the extension to the version of the GeoServer instance! :::

                                                              2. Extract the contents of the archive into the WEB-INF/lib directory of the GeoServer installation.

                                                              "},{"location":"community/gsr/usage/","title":"GSR Usage","text":"

                                                              Currently basic FeatureServer and MapServer functionality work. Each GeoServer workspace is considered an ArcGIS\u00ae \"service\" for the purposes of the API. ArcGIS\u00ae URLs look like this in GeoServer:

                                                              http://localhost:8080/geoserver/gsr/services/topp/MapServer/ http://localhost:8080/geoserver/gsr/services/topp/FeatureServer/

                                                              Where topp is the workspace name.

                                                              Note

                                                              Esri\u00ae, ArcGIS\u00ae and ArcGIS Online\u00ae are trademarks, registered trademarks, or service marks of Esri in the United States, the European Community, or certain other jurisdictions. Other companies and products mentioned may be trademarks of their respective owners.

                                                              "},{"location":"community/gsr/usage/#cors","title":"CORS","text":"

                                                              When using the official JS API, CORS detection does not work correctly. You will need to add your server manually to the list of CORS enabled servers:

                                                              require([\"esri/config\"], function (esriConfig) {\n  esriConfig.request.corsEnabledServers.push(\"localhost:9191\");\n});\n

                                                              CORS support also needs to be enabled on the server. Without these settings, it will attempt to use JSONP, which may not be as well supported.

                                                              For information on enabling CORS in GeoServer, see here.

                                                              "},{"location":"community/gsr/usage/#web-mercator-spatial-reference","title":"Web Mercator Spatial Reference","text":"

                                                              The official APIs use Spatial Reference 102100 as Web Mercator. In order for this to work, add the following custom projection to your data_dir/user_projections/epsg.properties file:

                                                              102100=PROJCS[\"WGS 84 / Pseudo-Mercator\",GEOGCS[\"Popular Visualisation CRS\", DATUM[\"Popular_Visualisation_Datum\",SPHEROID[\"Popular Visualisation Sphere\",6378137,0, AUTHORITY[\"EPSG\",\"7059\"]],TOWGS84[0,0,0,0,0,0,0],AUTHORITY[\"EPSG\",\"6055\"]], PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.01745329251994328, AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\",\"4055\"]],UNIT[\"metre\",1,AUTHORITY[\"EPSG\",\"9001\"]], PROJECTION[\"Mercator_1SP\"],PARAMETER[\"central_meridian\",0],PARAMETER[\"scale_factor\",1], PARAMETER[\"false_easting\",0],PARAMETER[\"false_northing\",0],AUTHORITY[\"EPSG\",\"3785\"], AXIS[\"X\",EAST],AXIS[\"Y\",NORTH]]

                                                              "},{"location":"community/gwc-azure-blob/","title":"GWC Azure BlobStore plugin","text":"

                                                              This plugin supports the use of the Azure BLOB storage. as storage medium for GeoWebCache settings.

                                                              "},{"location":"community/gwc-azure-blob/#installing-the-azure-blobstore-plugin","title":"Installing the Azure BlobStore plugin","text":"
                                                              1. Download the extension from the nightly GeoServer community module builds.

                                                                ::: warning ::: title Warning :::

                                                                Make sure to match the version of the extension to the version of the GeoServer instance! :::

                                                              2. Extract the contents of the archive into the WEB-INF/lib directory of the GeoServer installation.

                                                              "},{"location":"community/gwc-azure-blob/#configuring-the-azure-blobstore-plugin","title":"Configuring the Azure BlobStore plugin","text":"

                                                              Once the plugin has been installed, one or more Azure BlobStores may be configured through BlobStores. Afterwards, cached layers can be explicitly assigned to it or one blobstore could be marked as 'default' to use it for all unassigned layers.

                                                              "},{"location":"community/gwc-azure-blob/#container","title":"Container","text":"

                                                              The name of the Azure storage container where the tiles are stored.

                                                              "},{"location":"community/gwc-azure-blob/#account-name","title":"Account name","text":"

                                                              Azure storage account name

                                                              "},{"location":"community/gwc-azure-blob/#account-key","title":"Account key","text":"

                                                              Azure storage Account Key.

                                                              "},{"location":"community/gwc-azure-blob/#azure-object-key-prefix","title":"Azure Object Key Prefix","text":"

                                                              A prefix path to use as the root to store tiles under the container (optional).

                                                              "},{"location":"community/gwc-azure-blob/#maximum-connections","title":"Maximum Connections","text":"

                                                              The maximum number of allowed open HTTP connections.

                                                              "},{"location":"community/gwc-azure-blob/#use-https","title":"Use HTTPS","text":"

                                                              When enabled, a HTTPS connection will be used. When disabled, a regular HTTP connection will be used.

                                                              "},{"location":"community/gwc-azure-blob/#proxy-host","title":"Proxy Host","text":"

                                                              Proxy host the client will connect through (optional).

                                                              "},{"location":"community/gwc-azure-blob/#proxy-port","title":"Proxy Port","text":"

                                                              Proxy port the client will connect through (optional).

                                                              "},{"location":"community/gwc-azure-blob/#proxy-username","title":"Proxy Username","text":"

                                                              User name the client will use if connecting through a proxy (optional).

                                                              "},{"location":"community/gwc-azure-blob/#proxy-password","title":"Proxy Password","text":"

                                                              Password the client will use if connecting through a proxy (optional).

                                                              Note

                                                              Unlike AWS, Azure storage controls whether tiles can be accessed by the public at the container level. If you desire to build a public tile cache that can be directly accessed by clients as static files, set the container access level to \"public\" or \"BLOB\" and fully seed the cache.

                                                              "},{"location":"community/gwc-distributed/","title":"GWC Distributed Caching community module","text":"

                                                              GWC Distributed Caching module provides support for distributed in Memory caching using the Hazelcast API.

                                                              "},{"location":"community/gwc-distributed/#installing-the-wps-download-module","title":"Installing the WPS download module","text":"
                                                              1. Download the GWC Distributed module from the nightly GeoServer community module builds.

                                                                Warning

                                                                Make sure to match the version of the extension to the version of the GeoServer instance.

                                                              2. Extract the contents of the archive into the WEB-INF/lib directory of the GeoServer installation.

                                                              "},{"location":"community/gwc-distributed/#module-description","title":"Module description","text":"

                                                              More information about Caching Configuration can be found at the Configuration and Caching defaults pages.

                                                              "},{"location":"community/gwc-mbtiles/","title":"GWC MBTiles layer plugin","text":"

                                                              This plugin allows adding a GWC MBTiles Layer to GeoServer's cached Tile Layers configuration so that GeoServer can load cached tiles from ready-to-use MBTiles.

                                                              "},{"location":"community/gwc-mbtiles/#installation","title":"Installation","text":"

                                                              As a community module, make sure you have downloaded the gwc-mbtiles

                                                              To install the module, unpack the zip file contents into the GeoServer WEB-INF/lib directory and restart GeoServer.

                                                              "},{"location":"community/gwc-mbtiles/#configuring-a-mbtileslayer","title":"Configuring a MBTilesLayer","text":"

                                                              The configuration of a new MBTilesLayer can be done by editing the geowebcache configuration file located in <data_dir>/gwc/geowebcache.xml

                                                              Locate the layers section of the config or add it if missing.

                                                              Then define a new mbTilesLayer node for each new MBTilesLayer you want to add. A GWC configuration containing a configured MBTiles Layer would look like this:

                                                              <gwcConfiguration>\n  <!-- ... -->\n  <layers>\n    <!-- Other layer definitions may be here -->\n    <mbtilesLayer>\n      <tilesPath>D:\\Data\\mbtiles\\countries-raster.mbtiles</tilesPath>\n      <tileSize>256</tileSize>\n      <name>countries</name>\n      <metaInformation>\n        <title>Countries</title>\n        <description>Raster Layer with Countries</description>\n      </metaInformation>\n    </mbtilesLayer>\n    <!-- Other layer definitions may be here -->\n  </layers>\n</gwcConfiguration>\n

                                                              A few note on the above configuration elements of an mbtilesLayer definition:

                                                              • tilesPath (mandatory) is the path to the MBTiles file containing the tiles.
                                                              • tileSize is the size of the tiles stored on the MBTiles file. When not set, it will be defaulted to 256.
                                                              • name (optional) represents the name to be assigned to the layer. If not specified, the name field of the metadata table stored in the MBTiles file will be used. Make sure to define it in case the MBTiles metadata is missing it.
                                                              • metaInformation with title and description are optional tags. They will be exposed in the capabilities document when available.
                                                              "},{"location":"community/gwc-sqlite/","title":"GWC SQLite Plugin","text":"

                                                              This plugin provides integration with GWC SQLite based blob stores. At the moment only one blob store of this type is available, the MBTiles blob store.

                                                              "},{"location":"community/gwc-sqlite/#mbtiles-blob-store","title":"MBTiles Blob Store","text":"

                                                              This blob store allow us to store tiles using the MBTiles specification (version 1.1) which defines a schema for storing tiles in an SQLite database with some restrictions regarding tiles formats and projections.

                                                              MBTiles specification only supports JPEG and PNG formats and projection EPSG:3857 is assumed. The implemented blob store will read and write MBTiles files compliant with the specification but will also be able to write and read MBTiles files that use others formats and projections.

                                                              Using the MBTiles blob store will bring several benefits at the cost of some performance loss. The MBTiles storage uses a significantly smaller number of files, which results in easier data handling (e.g., backups, moving tiles between environments). In some cases the stored data will be more compact reducing the size of the data on disk.

                                                              When compared to the file blob store this store has two limitations:

                                                              • This store does not integrate with disk quota, this is a consequence of using database files.
                                                              • This store cannot be shared among several GeoWebCache instances.

                                                              Note

                                                              If disk quota is activated the stored stats will not make much sense and will not reflect the actual disk usage, the size of the database files cannot be really controlled.

                                                              Database files cannot be managed as simple files. When connections to a database are open the associated file should not be deleted, moved or switched or the database file may become corrupted. Databases files can also become fragmented after deleting an huge amount of data or after frequent inserts, updates or delete operations.

                                                              "},{"location":"community/gwc-sqlite/#file-path-templates","title":"File Path Templates","text":"

                                                              An MBTiles file will correspond to an SQLite database file. In order to limit the amount of contention on each single database file users will be allowed to decide the granularity of the databases files. When GeoWebCache needs to map a tile to a database file it will only look at the databases files paths, it will not take in account the MBTiles metadata (this is why this store is able to handle others formats and projections).

                                                              To configure the databases files granularity the user needs to provide a file path template. The default file path template for the MBTiles blob store is this one:

                                                              {layer}/{grid}{format}{params}/{z}-{x}-{y}.sqlite\n

                                                              This file template will stores all the tiles belonging to a certain layer in a single folder that will contain sub folders for each given format, projection and set of parameters and will group tiles with the same zoom level, column range and row range in a SQLite file. The column and row range values are passed by configuration, by default those values are equal to 250. The provided files paths templates will always be considered relative to the root directory provided as a configuration option.

                                                              Follows an example of what the blob store root directory structure may look like when using the default path template:

                                                              .\n|-- nurc_Pk50095\n|   `-- EPSG_4326image_pngnull\n|       |-- 11_2000_1500.sqlite\n|       `-- 12_4250_3000.sqlite\n`-- topp_states\n    |-- EPSG_900913image_jpeg7510004a12f49fdd49a2ba366e9c4594be7e4358\n    |   |-- 6_250_500.sqlite\n    |   `-- 7_0_0.sqlite\n    `-- EPSG_900913image_jpegnull\n        |-- 3_500_0.sqlite\n        |-- 4_0_250.sqlite\n        `-- 8_750_500.sqlite\n

                                                              If no parameters were provided null string will be used. Is the responsibility of the user to define a file path template that will avoid collisions.

                                                              The terms that can be used in the file path template are:

                                                              • grid: the grid set id
                                                              • layer: the name of the layer
                                                              • format: the image format of the tiles
                                                              • params: parameters unique hash
                                                              • x: column range, computed based on the column range count configuration property
                                                              • y: row range, computed based on the row range count configuration property
                                                              • z: the zoom level

                                                              It is also possible to use parameters values, like style for example. If the parameter is not present null will be used.

                                                              Note

                                                              Characters and `/` can be used as path separator, they will be translated to the operating system specific one ( for Linux and / for Windows). Any special char like `,/,:` or empty space used in a term value will be substituted with an underscore.

                                                              "},{"location":"community/gwc-sqlite/#mbtiles-metadata","title":"MBTiles Metadata","text":"

                                                              A valid MBTiles file will need some metadata, the image format and layer name will be automatically added when an MBTiles file is created. The user can provide the remaining metadata using a properties file whose name must follow this pattern:

                                                              <layerName>.metadata\n

                                                              As an example, to add metadata description and attribution entries to layer tiger_roads a file named tiger_roads.properties with the following content should be present in the metadata directory:

                                                              description=ny_roads\nattribution=geoserver\n

                                                              The directory that contains this metadata files is defined by a configuration property.

                                                              "},{"location":"community/gwc-sqlite/#expiration-rules","title":"Expiration Rules","text":"

                                                              The MBTiles specification don't give information about when a tile was created. To allow expire rules, an auxiliary table is used to store tile creation time. In the presence of an MBTiles file generated by a third party tool it is assumed that the creation time of a tile was the first time it was accessed. This feature can be activated or deactivated by configuration. Note that this will not break the MBTiles specification compliance.

                                                              "},{"location":"community/gwc-sqlite/#eager-truncate","title":"Eager Truncate","text":"

                                                              When performing a truncate of the cache the store will try to remove the whole database file avoiding to create fragmented space. This is not suitable for all the situations and is highly dependent on the database files granularity. The configuration property eagerDelete allows the user to disable or deactivate this feature which is disabled by default.

                                                              When a truncate request by tile range is received all the databases files that contains tiles that belong to the tile range are identified. If eager delete is set to true those databases files are deleted otherwise a single delete query for each file is performed.

                                                              "},{"location":"community/gwc-sqlite/#configuration-example","title":"Configuration Example","text":"

                                                              Follows as an example the default configuration of the MBTiles store:

                                                              The rootDirectory property defines the location where all the files produced by this store will be created. The templatePath property is used to control the granularity of the database files (see section above). Properties rowRangeCount and columnRangeCount will be used by the path template to compute tile ranges.

                                                              The poolSize property allows to control the max number of open database files, when defining this property the user should take in account the number open files allowed by the operating system. The poolReaperIntervalMs property controls how often the pool size will be checked to see if some database files connections need to be closed.

                                                              Property eagerDelete controls how the truncate operation is performed (see section above). The property useCreateTime can be used to activate or deactivate the insertion of the tile creation time (see section above). Property executorConcurrency controls the parallelism used to perform certain operations, like the truncate operation for example. Property mbtilesMetadataDirectory defines the directory where the store will look for user provided MBTiles metadata.

                                                              Note

                                                              Since the connection pool eviction happens at a certain interval, it means that the number of files open concurrently can go above the threshold limit for a certain amount of time.

                                                              "},{"location":"community/gwc-sqlite/#replace-operation","title":"Replace Operation","text":"

                                                              As said before, if the cache is running SQLite files cannot be simply switched, first all connections need to be closed. The replace operation was created for this propose. The replace operation will first copy the new file side by side the old one, then block the requests to the old file, close the connections tot he old file, delete the old one, rename the new file to current one, reopen the new db file and start serving requests again. Should be almost instant.

                                                              A REST entry point for this operation is available, it will be possible to submit a ZIP file or a single file along with the request. The replace operation can also use an already present file or directory. When using a directory the directory structure will be used to find the destination of each file, all the paths will be assumed to be relative to the store root directory. This means that is possible to replace a store content with another store content (a seeded one for example) by zipping the second store root directory and send it as a replacement.

                                                              Note

                                                              When using a local directory or submitting a zip file all the file present in the directory will be considered.

                                                              There is four ways to invoke this operation. Follows an example of all those variants invocations using CURL.

                                                              Replace a single file uploading the replacement file:

                                                              curl -u admin:geoserver -H 'Content-Type: multipart/form-data'\n  -F \"file=@tiles_0_0.sqlite\"\n  -F \"destination=EPSG_4326/sf_restricted/image_png/null/10/tiles_0_0.sqlite\"\n  -F \"layer=sf:restricted\"\n  -XPOST 'http://localhost:8080/geoserver/gwc/rest/sqlite/replace'\n

                                                              Replace a single file using a file already present on the system:

                                                              curl -u admin:geoserver -H 'Content-Type: multipart/form-data'\n  -F \"source=/tmp/tiles_0_0.sqlite\"\n  -F \"destination=EPSG_4326/sf_restricted/image_png/null/10/tiles_0_0.sqlite\"\n  -F \"layer=sf:restricted\"\n  -XPOST 'http://localhost:8080/geoserver/gwc/rest/sqlite/replace'\n

                                                              Replace multiple files uploading a ZIP file:

                                                              curl -u admin:geoserver -H 'Content-Type: multipart/form-data'\n  -F \"file=@tiles.zip\"\n  -F \"layer=sf:restricted\"\n  -XPOST 'http://localhost:8080/geoserver/gwc/rest/sqlite/replace'\n

                                                              Replace multiple files using a directory already present on the system:

                                                              curl -u admin:geoserver -H 'Content-Type: multipart/form-data'\n  -F \"source=/tmp/tiles\"\n  -F \"layer=sf:restricted\"\n  -XPOST 'http://localhost:8080/geoserver/gwc/rest/sqlite/replace'\n

                                                              The layer parameter identifies the layer whose associated blob store content should be replaced. The file parameter is used to upload a single file or a ZIP file. The source parameter is used to reference an already present file or directory. The destination parameter is used to define the file that should be replaced with the provided file.

                                                              This are the only valid combinations of this parameters other combinations will ignore some of the provided parameters or will throw an exception.

                                                              "},{"location":"community/hana/","title":"SAP HANA","text":""},{"location":"community/hana/#supported-versions","title":"Supported versions","text":"

                                                              The module supports

                                                              • SAP HANA 1 SPS 12
                                                              • SAP HANA 2 (all SPS including the free express edition)
                                                              • SAP HANA Cloud
                                                              "},{"location":"community/hana/#hana_install","title":"Installing SAP HANA support","text":"

                                                              GeoServer has no built-in support for SAP HANA. You can enable SAP HANA support by adding the HANA GeoTools module and the HANA JDBC driver to your GeoServer installation.

                                                              "},{"location":"community/hana/#installing-the-hana-geotools-module","title":"Installing the HANA GeoTools module","text":"

                                                              Identify the GeoTools version your GeoServer installation is using by navigating to the webapps/geoserver/WEB-INF/lib/ folder in your GeoServer installation and locating the file gt-jdbc-{<version>}.jar as shown in the image below. In the example below the GeoServer version is 22.0.

                                                              Finding the GeoTools version

                                                              Download the GeoTools archive with the version used by GeoServer from the GeoTools website. You need the geotools-{<version>}-bin.zip file. Copy the gt-jdbc-hana-{<version>}.jar file to the webapps/geoserver/WEB-INF/lib/ folder of your GeoServer installation.

                                                              Locating the GeoTools HANA module

                                                              "},{"location":"community/hana/#installing-the-hana-jdbc-driver","title":"Installing the HANA JDBC driver","text":"

                                                              Browse to the SAP Development Tools website and download the JDBC component to the webapps/geoserver/WEB-INF/lib/ folder of your GeoServer installation.

                                                              Downloading ngdbc.jar from the SAP Development Tools website

                                                              Afterwards restart your GeoServer instance.

                                                              "},{"location":"community/hana/#adding-a-sap-hana-database","title":"Adding a SAP HANA database","text":"

                                                              After both modules have been installed, SAP HANA will show up as an option when creating a new data store.

                                                              HANA in the list of vector data sources

                                                              "},{"location":"community/hana/#configuring-a-sap-hana-data-store","title":"Configuring a SAP HANA data store","text":"

                                                              Configuring a SAP HANA data store

                                                              The following options are relevant for SAP HANA:

                                                              host The machine name or IP address to connect to. port The port to connect to. If set and different from 0, the parameters instance and database are ignored. If not set or 0, the instance parameter must be set. instance The instance to connect to. This parameter is ignored if a port is set. The instance field is at the bottom of the configuration form in case you have difficulties locating it. database The database to connect to. Leave empty in case of single-container databases. Set to SYSTEMDB to connect to the system database of a multi-container database. This parameter is ignored if a port is set. schema The database schema to access. If left blank, the user-specific database schema is accessed. user The database user used to connect to the database. passwd The password used to connect to the database. use ssl If checked the TLS/SSL cryptographic protocol is used to establish a secure connection with the database."},{"location":"community/importer-jdbc/","title":"Importer JDBC storage","text":"

                                                              This plugin allows sharing the state of imports in a relational database supported by GeoTools. Compared to the default in-memory storage, this helps in two ways:

                                                              • The state of the imports is persisted and survives restarts
                                                              • If an external database, such as PostgreSQL/PostGIS, is used, then it's possible to run multiple imports on different GeoServer nodes in load balancing and get a consolidated view of their state
                                                              "},{"location":"community/importer-jdbc/#installation","title":"Installation","text":"

                                                              The module zip just need to be unpacked in the GeoServer WEB-INF\\lib. On startup the module will create by default a H2 database in a \"importer\" folder inside the data directory, as well as a configuration file at ${GEOSERVER_DATA_DIR}/jdbc-import-store.properties.

                                                              The property file can be modified to point to an external database, for example, the following contents are suitable for a PostGIS database (PostGIS extensions mandatory, even if not used):

                                                              dbtype=postgis\nuser=myUserName\npasswd=myPassword\ndatabase=databaseName\nport=5432\nhost=localhost\nschema=public\n

                                                              On connection the code will create one table and the suitable indexes to track the imports. In case the user above is not allowed to create tables, the following SQL statement can be used (adapt to the specific database):

                                                              CREATE TABLE public.import_context\n(\n  fid serial,\n  context text,\n  created timestamp,\n  updated timestamp,\n  \"user\" character varying,\n  state character varying,\n  CONSTRAINT import_context_pkey PRIMARY KEY (fid)\n);\nCREATE INDEX import_context_state ON import_context(state);\nCREATE INDEX import_context_user ON import_context(\"user\");\n

                                                              Note

                                                              The store has been tested with H2 and Postgresql with PostGIS extensions, it may work with other relational databases too assuming that they have a corresponding GeoTools data store plugin installed and the database is not changing the name of the columns (Oracle will most likely not work).

                                                              Note

                                                              With some light extra development and testing the code could be extended to save the status of imports in any GeoTools supported store, e.g., SOLR, MongoDB.

                                                              "},{"location":"community/jdbcconfig/","title":"JDBCConfig","text":"

                                                              The JDBCConfig module enhances the scalability performance of the GeoServer Catalog. It allows externalising the storage of the Catalog configuration objects (such as workspaces, stores, layers) to a Relational Database Management System, rather than using xml files in the GeoServer data directory. This way the Catalog can support access to unlimited numbers of those configuration objects efficiently.

                                                              • Installing JDBCConfig
                                                              • JDBCConfig configuration
                                                              "},{"location":"community/jdbcconfig/configuration/","title":"JDBCConfig configuration","text":"

                                                              The JDBCConfig module is configured in the file jdbcconfig/jdbcconfig.properties inside the GeoServer data directory. The following properties may be set:

                                                              • enabled: Use JDBCConfig. Turn off to use the data directory for all configuration instead.
                                                              • initdb: Initialize an empty database if this is set on true.
                                                              • import : The import configuration option tells GeoServer whether to import the current catalog from the file system to the database or not. If set to true, it will be imported and the config option will be set the value 'false' for the next start up to avoid trying to re-import the catalog configuration.
                                                              • repopulate: The repopulate configuration option tells GeoServer to repopulate the queryable field values in the database. These are the fields of catalog objects jdbcconfig can query via the database, i.e. much faster than via post-filtering in memory. May be necessary after jdbcconfig upgrades or if someone manually adds queryable fields to the database. (In such cases, if the values were not properly repopulated, queries might give incorrect results.)
                                                              • initScript: Path to initialisation script .sql file. Only used if initdb = true.
                                                              "},{"location":"community/jdbcconfig/configuration/#jndi","title":"JNDI","text":"

                                                              Get the database connection from the application server via JNDI lookup.

                                                              • jndiName: The JNDI name for the data source. Only set this if you want to use JNDI, the JDBC configuration properties may still be set for in case the JNDI Lookup fails.
                                                              "},{"location":"community/jdbcconfig/configuration/#direct-jdbc-connection","title":"Direct JDBC Connection","text":"

                                                              Provide the connection parameters directly in the configuration file. This includes the password in the clear which is a potential security risk. To avoid this use JNDI instead.

                                                              • jdbcUrl: JDBC direct connection parameters.
                                                              • username: JDBC connection username.
                                                              • password: JDBC connection password.
                                                              • pool.minIdle: minimum connections in pool
                                                              • pool.maxActive: maximum connections in pool
                                                              • pool.poolPreparedStatements: whether to pool prepared statements
                                                              • pool.maxOpenPreparedStatements: size of prepared statement cache, only used if pool.poolPreparedStatements is true
                                                              • pool.testOnBorrow: whether to validate connections when obtaining from the pool
                                                              • pool.validationQuery: validation query for connections from pool, must be set when pool.testOnBorrow is true
                                                              • pool.testWhileIdle: whether to validate idle connections, used in conjunction with the idle timer below
                                                              • pool.setTimeBetweenEvictionRunsMillis: period in millseconds for the idle object evictor, -1 to disable
                                                              "},{"location":"community/jdbcconfig/installing/","title":"Installing JDBCConfig","text":"

                                                              To install the JDBCConfig module:

                                                              1. Visit the website download page and download jdbcconfig.
                                                              2. Extract this file and place the JARs in WEB-INF/lib.
                                                              3. Perform any configuration required by your servlet container, and then restart. On startup, JDBCConfig will create a configuration directory jdbcconfig in the GeoServer data directory.
                                                              4. Verify that the configuration directory was created to be sure installation worked then turn off GeoServer.
                                                              5. Configure JDBCConfig (JDBCConfig configuration), being sure to set enabled, initdb, and import to true, and to provide the connection information for an empty database.
                                                              6. Start GeoServer again. This time JDBCConfig will connect to the specified database, initialize it, import the old catalog into it, and take over from the old catalog. Subsequent start ups will skip the initialize and import steps unless you re-enable them in jdbcconfig.properties.
                                                              7. Log in as admin and a message should appear on the welcome page:

                                                              "},{"location":"community/jdbcstore/","title":"JDBCStore","text":"

                                                              The JDBCStore module allows efficient sharing of configuration data in a clustered deployment of GeoServer. It allows externalising the storage of all configuration resources to a Relational Database Management System, rather than using the default File System based GeoServer data directory. This way the multiple instances of GeoServer can use the same Database and therefore share in the same configuration.

                                                              • Installing JDBCStore
                                                              • JDBCStore configuration
                                                              "},{"location":"community/jdbcstore/configuration/","title":"JDBCStore configuration","text":"

                                                              The JDBCStore module is configured in the file jdbcstore/jdbcstore.properties inside the GeoServer data directory. The following properties may be set:

                                                              • enabled: Use JDBCStore. Turn off to use the data directory for all configuration instead.
                                                              • initdb: Initialize an empty database if this is set on true.
                                                              • import : The import configuration option tells GeoServer whether to import the current GeoServer data directory from the file system to the database or not. If set to true, it will be imported and the config option will be set the value 'false' for the next start up to avoid trying to re-import the catalog configuration.
                                                              • initScript: Path to initialisation script .sql file. Only used if initdb is true.
                                                              • ignoreDirs: specify all subdirectories of the GeoServer data directory that should be ignored by the JDBCStore, in a comma-separate list. These subdirectories will not be imported and while JDBCStore is running, all access to these subdirectories and their contents will be redirected to the default file system store. This is usually done with the data directory (which holds data rather than metadata such as images and shapefiles), temporary directories (which are not used for permanent storage) and the catalog directories (when using JDBCConfig, these are unused anyway and they need not be copied into the JDBCStore).
                                                              • cachedDirs: specify all subdirectories of the datadir that should be automatically cached on the file system by the JDBCStore, in a comma-separate list. These subdirectories will be stored in the database, but an up-to-date copy will be stored on the hard drive at all times. This is handy for files that are used by tools that do not support jdbcstore (such as Application Schemas <../../data/app-schema/index.rst>_ for example) but still need to be synced between nodes.
                                                              • deleteDestinationOnRename: allow automatic overwriting of existing destinations on move and rename operations (linux-style versus windows-style - the default store is platform dependant).
                                                              "},{"location":"community/jdbcstore/configuration/#jndi","title":"JNDI","text":"

                                                              Get the database connection from the application server via JNDI lookup.

                                                              • jndiName: The JNDI name for the data source. Only set this if you want to use JNDI, the JDBC configuration properties may still be set for in case the JNDI Lookup fails.
                                                              "},{"location":"community/jdbcstore/configuration/#direct-jdbc-connection","title":"Direct JDBC Connection","text":"

                                                              Provide the connection parameters directly in the configuration file. This includes the password in the clear which is a potential security risk. To avoid this use JNDI instead.

                                                              • jdbcUrl: JDBC direct connection parameters.
                                                              • username: JDBC connection username.
                                                              • password: JDBC connection password.
                                                              • pool.minIdle: minimum connections in pool
                                                              • pool.maxActive: maximum connections in pool
                                                              • pool.poolPreparedStatements: whether to pool prepared statements
                                                              • pool.maxOpenPreparedStatements: size of prepared statement cache, only used if pool.poolPreparedStatements is true
                                                              • pool.testOnBorrow: whether to validate connections when obtaining from the pool
                                                              • pool.validationQuery: validation query for connections from pool, must be set when pool.testOnBorrow is true
                                                              • pool.testWhileIdle: whether to validate idle connections, used in conjunction with the idle timer below
                                                              • pool.setTimeBetweenEvictionRunsMillis: period in millseconds for the idle object evictor, -1 to disable
                                                              "},{"location":"community/jdbcstore/installing/","title":"Installing JDBCStore","text":"

                                                              To install the JDBCStore module:

                                                              1. Download the module: jdbcstore

                                                                The JDBCStore plug-in automatically includes the JDBCConfig plugin as well which will generally be run at the same time.

                                                              2. Extract this file and place the JARs in WEB-INF/lib.

                                                              3. Perform any configuration required by your servlet container, and then restart. On startup, JDBCStore will create a configuration directory jdbcstore and JDBCConfig will create a configuration directory jdbcconfig in the GeoServer data directory .

                                                              4. Verify that the configuration directories were created to be sure installation worked then turn off GeoServer.

                                                              5. If you want to use JDBCConfig as well, configure it first, being sure to set enabled, initdb, and import to true, and to provide the connection information for an empty database. Start GeoServer to initialize the JDBCConfig database, import the old catalog into it, and take over from the old catalog. Subsequent start ups will skip the initialize and import steps unless you re-enable them in jdbcconfig.properties.

                                                              6. Now configure JDBCStore in a similar fashion (JDBCStore configuration), being sure to set enabled, initdb, and import to true, and to provide the connection information for an empty database. Start GeoServer again. This time JDBCStore will connect to the specified database, initialize it, import the old GeoServer data directory into it, and take over from the old GeoServer data directory. Subsequent start ups will skip the initialize and import steps unless you re-enable them in jdbcstore.properties.

                                                              "},{"location":"community/jms-cluster/","title":"JMS based Clustering","text":""},{"location":"community/jms-cluster/#introduction","title":"Introduction","text":"

                                                              The are several approaches to implement a clustered deployment with GeoServer, based on different mixes of data directory sharing plus configuration reload. The JMS based clustering module architecture is depicted in the following diagram:

                                                              This module implements a robust Primary/Replica approach which leverages on a Message Oriented Middleware (MOM) where:

                                                              • The Primaries accept changes to the internal configuration, persist them on their own data directory but also forward them to the Replicas via the MOM
                                                              • The Replicas should not be used to change their configuration from either REST or the User Interface, since are configured to inject configuration changes disseminated by the Primary(s) via the MOM
                                                              • The MOM is used to make the Primary and the Replicas exchange messages in a durable fashion
                                                              • Each Replicas has its own data directory and it is responsible for keeping it aligned with the Primary's one. In case a Replicas goes down when it goes up again he might receive a bunch of JMS messages to align its configuration to the Primary's one.
                                                              • A Node can be both Primary and Replica at the same time, this means that we don't have a single point of failure, i.e. the Primary itself

                                                              Summarizing, the Primary as well as each Replicas use a private data directory, Replicas receive changes from the Primary, which is the only one where configuration changes are allowed, via JMS messages. Such messages transport GeoServer configuration objects that the Replicas inject directly in their own in-memory configuration and then persist on disk on their data directory, completely removing the need for a configuration reload for each configuration change.

                                                              To make things simpler, in the default configuration the MOM is actually embedded and running inside each GeoServer, using multicast to find its peers and thus allowing for a clustering installation without the need to have a separate MOM deploy.

                                                              "},{"location":"community/jms-cluster/#description","title":"Description","text":"

                                                              The GeoServer Primary/Replica integration is implemented using JMS, Spring and a MOM (Message Oriented Middleware), in particular ActiveMQ. The schema in Illustration represents a complete high level design of Primary/Replica platform. It is composed by 3 distinct actors:

                                                              1. GeoServer Primary
                                                              2. GeoServer Replicas
                                                              3. The MOM (ActiveMQ)

                                                              This structure allows to have:

                                                              1. Queue fail-over components (using MOM).
                                                              2. Replica down are automatically handled using durable topic (which will store message to re-synch changes happens if one of the replicas is down when the message was made available)
                                                              3. Primary down will not affect any replicas synchronization process.

                                                              This full blown deployment is composed by:

                                                              • A pure Primary GeoServer(s), this instance can only send events to the topic. It cannot act as a replica
                                                              • A set of GeoServer which can work as both Primary and Replica. These instances can send and receive messages to/from the topic. They can work as Primaries (sending message to other subscribers) as well as Replicas (these instances are also subscribers of the topic).
                                                              • A set of pure Replicas GeoServer instances whic can only receive messages from the topic.
                                                              • A set of MOM brokers so that each GeoServer instance is configured with a set of available brokers (failover). Each broker use the shared database as persistence. Doing so if a broker fails for some reason, messages can still be written and read from the shared database.

                                                              All the produced code is based on spring-jms to ensure portability amongst different MOM, but if you look at the schema, we are also leveraging ActiveMQ VirtualTopics to get dynamic routing (you can dynamically attach primary and replica).

                                                              The VirtualTopics feature has also other advantages explained here: http://activemq.apache.org/virtual-destinations.html

                                                              As said above, in the default configuration the MOM runs inside GeoServer itself, simplifying the topology and the setup effort.

                                                              "},{"location":"community/jms-cluster/#installation","title":"Installation","text":"

                                                              To install the jms cluster modules into an existing GeoServer refer to the jms.installation page

                                                              "},{"location":"community/jms-cluster/#how-to-configure-geoserver-instances","title":"How to configure GeoServer Instances","text":"

                                                              The configuration for the GeoServer is very simple and can be performed using the provided GUI or modifying the cluster.properties file which is stored into the GEOSERVER_DATA_DIR under the cluster folder (e.g. ${GEOSERVER_DATA_DIR}/cluster).

                                                              To override the default destination of this configuration file you have to setup the CLUSTER_CONFIG_DIR variable defining the destination folder of the cluster.properties file. This is mandatory when you want to share the same GEOSERVER_DATA_DIR, but not required if you are giving each GeoServer its own data directory.

                                                              In case of shared data directory, it will be necessary to add a different system variable to each JVM running a GeoServer, e.g.:

                                                              • -DCLUSTER_CONFIG_DIR=/var/geoserver/clusterConfig/1 to the JVM running the first node
                                                              • -DCLUSTER_CONFIG_DIR=/var/geoserver/clusterConfig/2 to the JVM running the second node
                                                              • and so on

                                                              If the directories are missing, GeoServer will create them and provide a initial cluster.properties with reasonable defaults.

                                                              "},{"location":"community/jms-cluster/#instance-name","title":"Instance name","text":"

                                                              The instance.name is used to distinguish from which GeoServer instance the message is coming from, so each GeoServer instance should use a different, unique (for a single cluster) name.

                                                              "},{"location":"community/jms-cluster/#broker-url","title":"Broker URL","text":"

                                                              The broker.url field is used to instruct the internal JMS machinery where to publish messages to (primary GeoServer installation) or where to consume messages from (replica GeoServer installation). Many options are available for configuring the connection between the GeoServer instance and the JMS broker, for a complete list, please, check http://activemq.apache.org/configuring-transports.html. In case when (recommended) failover set up is put in place multiple broker URLs can be used. See http://activemq.apache.org/failover-transport-reference.html for more information about how to configure that. Note GeoServer will not complete the start-up phase until the target broker is correctly activated and reachable.

                                                              "},{"location":"community/jms-cluster/#limitations-and-future-extensions","title":"Limitations and future extensions","text":""},{"location":"community/jms-cluster/#data","title":"Data","text":"

                                                              NO DATA IS SENT THROUGH THE JMS CHANNEL The clustering solution we have put in place is specific for managing the GeoServer internal configuration, no data is transferred between primary and replicas. For that purpose use external mechanisms (ref. [GeoServer REST]). In principle this is not a limitation per se since usually in a clustered environment data is stored in shared locations outside the data directory. With our solution this is a requirement since each replicas will have its own private data directory.

                                                              "},{"location":"community/jms-cluster/#things-to-avoid","title":"Things to avoid","text":"
                                                              • NEVER RELOAD THE GEOSERVER CATALOG ON A PRIMARY: Each primary instance should never call the catalog reload since this propagates the creation of all the resources, styles, etc to all the connected replicas.
                                                              • NEVER CHANGE CONFIGURATION USING A PURE REPLICA: This will make the configuration of the specific replica out of synch with the others.
                                                              "},{"location":"community/jms-cluster/#refs","title":"Refs:","text":"
                                                              • Installation of the JMS Cluster modules
                                                              • HOWTO configure ActiveMQ broker
                                                              • JDBC Primary/Replica
                                                              • Shared File System Primary/Replica
                                                              "},{"location":"community/jms-cluster/#bibliography","title":"Bibliography:","text":"

                                                              [JMS specs] Sun microsystens - Java Message Service - Version 1.1 April 12, 2002

                                                              [JMS] Snyder Bosanac Davies - ActiveMQ in action - Manning

                                                              [GeoServer] http://docs.geoserver.org/

                                                              [GeoServer REST] http://docs.geoserver.org/latest/en/user/rest/index.html#rest

                                                              [ActiveMQ] http://activemq.apache.org/

                                                              "},{"location":"community/jms-cluster/installation/","title":"Installation","text":"

                                                              jms.installation

                                                              "},{"location":"community/jms-cluster/installation/#jms.installation","title":"Installation of the JMS Cluster modules","text":"

                                                              To install the JMS Cluster modules you simply have to:

                                                              • Download the geoserver-jms-cluster-<version>.zip file from the nightly builds, community section
                                                              • Stop GeoServer
                                                              • Unpack the zip file in webapps/geoserver/WEB-INF/lib
                                                              • Start again GeoServer

                                                              .. warning:

                                                              In GeoServer versions 2.10.4, 2.11.1 and 2.12-beta default topic name was renamed from VirtualTopic.>, which has a special meaning in ActiveMQ, to VirtualTopic.geoserver. When upgrading to one of this versions or above the virtual topic name will be automatically updated. Note that only GeoServer instances that use the same topic name will be synchronized.

                                                              As a recommendation, for the first tests try to run the cluster module on a cluster of GeoServer all having their own data directory.

                                                              If you want to use the clustering extension while sharing the same data dir that's also possible, but you'll have to remember to use the CLUSTER_CONFIG_DIR system variable, and set it to a different folder for each instance, e.g.:

                                                              • set -DCLUSTER_CONFIG_DIR=/path/to/cluster/config/dir/1 on the first node,
                                                              • set -DCLUSTER_CONFIG_DIR=/path/to/cluster/config/dir/2 on the second node
                                                              • and so on

                                                              The directories do not need to exist, GeoServer will create and populate them on startup automatically.

                                                              "},{"location":"community/jms-cluster/activemq/JDBC/","title":"JDBC Primary/Replica","text":"

                                                              If you are using pure JDBC and not using the high performance journal then you are generally relying on your database as your single point of failure and persistence engine. If you do not have really high performance requirements this approach can make a lot of sense as you have a single persistence engine to backup and manage etc.

                                                              "},{"location":"community/jms-cluster/activemq/JDBC/#startup","title":"Startup","text":"

                                                              When using just JDBC as the data source you can use a Primary/Replica approach, running as many brokers as you wish as this diagram shows. On startup one primary grabs an exclusive lock in the broker database - all other brokers are replicas and pause waiting for the exclusive lock.

                                                              Clients should be using the Failover Transport to connect to the available brokers. e.g. using a URL something like the following failover:(tcp://broker1:61616,tcp://broker2:61616,tcp://broker3:61616) Only the primary broker starts up its transport connectors and so the clients can only connect to the primary.

                                                              "},{"location":"community/jms-cluster/activemq/JDBC/#primary-failure","title":"Primary failure","text":"

                                                              If the primary looses connection to the database or looses the exclusive lock then it immediately shuts down. If a primary shuts down or fails, one of the other replicas will grab the lock and so the topology switches to the following diagram

                                                              One of the other replicas immediately grabs the exclusive lock on the database to then commences becoming the primary, starting all of its transport connectors. Clients lose connection to the stopped primary and then the failover transport tries to connect to the available brokers - of which the only one available is the new primary. Primary restart At any time you can restart other brokers which join the cluster and start as replicas waiting to become a primary if the primary is shutdown or a failure occurs. So the following topology is created after a restart of an old primary...

                                                              "},{"location":"community/jms-cluster/activemq/JDBC/#configuring-jdbc-primaryreplica","title":"Configuring JDBC Primary/Replica","text":"

                                                              By default if you use the to avoid the high performance journal you will be using JDBC Primary/Replica by default. You just need to run more than one broker and point the client side URIs to them to get primary/replica. This works because they both try an acquire an exclusive lock on a shared table in the database and only one will succeed.

                                                              The following example shows how to configure the ActiveMQ broker in JDBC Primary/Replica mode

                                                              <beans>\n\n  <!-- Allows us to use system properties as variables in this configuration file -->\n  <bean class=\"org.springframework.beans.factory.config.PropertyPlaceholderConfigurer\"/>\n\n  <broker xmlns=\"http://activemq.apache.org/schema/core\">\n\n    <destinationPolicy>\n  <policyMap><policyEntries>\n\n      <policyEntry topic=\"FOO.>\">\n        <dispatchPolicy>\n      <strictOrderDispatchPolicy />\n        </dispatchPolicy>\n        <subscriptionRecoveryPolicy>\n      <lastImageSubscriptionRecoveryPolicy />\n        </subscriptionRecoveryPolicy>\n      </policyEntry>\n\n  </policyEntries></policyMap>\n    </destinationPolicy>\n\n\n    <persistenceAdapter>\n    <jdbcPersistenceAdapter dataDirectory=\"${activemq.base}/activemq-data\"/>\n\n    <!-- \n    <jdbcPersistenceAdapter dataDirectory=\"activemq-data\" dataSource=\"#oracle-ds\"/>\n    --> \n    </persistenceAdapter>\n\n    <transportConnectors>\n  <transportConnector name=\"default\" uri=\"tcp://localhost:61616\"/>\n    </transportConnectors>\n\n  </broker>\n\n  <!--  This xbean configuration file supports all the standard spring xml configuration options -->\n\n  <!-- Postgres DataSource Sample Setup -->\n  <!-- \n  <bean id=\"postgres-ds\" class=\"org.postgresql.ds.PGPoolingDataSource\">\n    <property name=\"serverName\" value=\"localhost\"/>\n    <property name=\"databaseName\" value=\"activemq\"/>\n    <property name=\"portNumber\" value=\"0\"/>\n    <property name=\"user\" value=\"activemq\"/>\n    <property name=\"password\" value=\"activemq\"/>\n    <property name=\"dataSourceName\" value=\"postgres\"/>\n    <property name=\"initialConnections\" value=\"1\"/>\n    <property name=\"maxConnections\" value=\"10\"/>\n  </bean>\n  -->\n\n  <!-- MySql DataSource Sample Setup -->\n  <!-- \n  <bean id=\"mysql-ds\" class=\"org.apache.commons.dbcp.BasicDataSource\" destroy-method=\"close\">\n    <property name=\"driverClassName\" value=\"com.mysql.jdbc.Driver\"/>\n    <property name=\"url\" value=\"jdbc:mysql://localhost/activemq?relaxAutoCommit=true\"/>\n    <property name=\"username\" value=\"activemq\"/>\n    <property name=\"password\" value=\"activemq\"/>\n    <property name=\"poolPreparedStatements\" value=\"true\"/>\n  </bean>\n  -->  \n\n  <!-- Oracle DataSource Sample Setup -->\n  <!--\n  <bean id=\"oracle-ds\" class=\"org.apache.commons.dbcp.BasicDataSource\" destroy-method=\"close\">\n    <property name=\"driverClassName\" value=\"oracle.jdbc.driver.OracleDriver\"/>\n    <property name=\"url\" value=\"jdbc:oracle:thin:@localhost:1521:AMQDB\"/>\n    <property name=\"username\" value=\"scott\"/>\n    <property name=\"password\" value=\"tiger\"/>\n    <property name=\"poolPreparedStatements\" value=\"true\"/>\n  </bean>\n  -->\n\n  <!-- Embedded Derby DataSource Sample Setup -->\n  <!-- \n  <bean id=\"derby-ds\" class=\"org.apache.derby.jdbc.EmbeddedDataSource\">\n    <property name=\"databaseName\" value=\"derbydb\"/>\n    <property name=\"createDatabase\" value=\"create\"/>\n  </bean>\n  -->  \n\n</beans>\n
                                                              "},{"location":"community/jms-cluster/activemq/SharedFolder/","title":"Shared File System Primary/Replica","text":"

                                                              Basically you can run as many brokers as you wish from the same shared file system directory. The first broker to grab the exclusive lock on the file is the primary broker. If that broker dies and releases the lock then another broker takes over. The replica brokers sit in a loop trying to grab the lock from the primary broker. The following example shows how to configure a broker for Shared File System Primary/Replica where /sharedFileSystem is some directory on a shared file system. It is just a case of configuring a file based store to use a shared directory.

                                                              <persistenceAdapter>\n  <kahaDB directory=\"/sharedFileSystem/sharedBrokerData\"/>\n</persistenceAdapter>\n

                                                              or:

                                                              <persistenceAdapter>\n  <levelDB directory=\"/sharedFileSystem/sharedBrokerData\"/>\n</persistenceAdapter>\n

                                                              or:

                                                              <persistenceAdapter>\n  <amqPersistenceAdapter directory=\"/sharedFileSystem/sharedBrokerData\"/>\n</persistenceAdapter>\n
                                                              "},{"location":"community/jms-cluster/activemq/SharedFolder/#startup","title":"Startup","text":"

                                                              On startup one primary grabs an exclusive lock on the broker file directory - all other brokers are replicas and pause waiting for the exclusive lock.

                                                              Clients should be using the Failover Transport to connect to the available brokers. e.g. using a URL something like the following

                                                              failover:(tcp://broker1:61616,tcp://broker2:61616,tcp://broker3:61616)\n

                                                              Only the primary broker starts up its transport connectors and so the clients can only connect to the primary.

                                                              "},{"location":"community/jms-cluster/activemq/SharedFolder/#primary-failure","title":"Primary failure","text":"

                                                              If the primary looses the exclusive lock then it immediately shuts down. If a primary shuts down or fails, one of the other replicas will grab the lock and so the topology switches to the following diagram

                                                              One of the other replicas immediately grabs the exclusive lock on the file system to them commences becoming the primary, starting all of its transport connectors. Clients lose connection to the stopped primary and then the failover transport tries to connect to the available brokers - of which the only one available is the new primary.

                                                              "},{"location":"community/jms-cluster/activemq/SharedFolder/#primary-restart","title":"Primary restart","text":"

                                                              At any time you can restart other brokers which join the cluster and start as replicas waiting to become a primary if the primary is shutdown or a failure occurs. So the following topology is created after a restart of an old primary...

                                                              Note

                                                              If you have a SAN or shared file system it can be used to provide high availability such that if a broker is killed, another broker can take over immediately.

                                                              Ensure your shared file locks work

                                                              Note that the requirements of this failover system are a distributed file system like a SAN for which exclusive file locks work reliably. If you do not have such a thing available then consider using Primary/Replica instead which implements something similar but working on commodity hardware using local file systems which ActiveMQ does the replication.

                                                              OCFS2 Warning

                                                              Was testing using OCFS2 and both brokers thought they had the primary lock - this is because \"OCFS2 only supports locking with 'fcntl' and not 'lockf and flock', therefore mutex file locking from Java isn't supported.\"

                                                              From http://sources.redhat.com/cluster/faq.html#gfs_vs_ocfs2 :

                                                              OCFS2: No cluster-aware flock or POSIX locks

                                                              GFS: fully supports Cluster-wide flocks and POSIX locks and is supported.

                                                              NFSv3 Warning

                                                              In the event of an abnormal NFSv3 client termination (i.e., the ActiveMQ primary broker), the NFSv3 server will not timeout the lock that is held by that client. This effectively renders the ActiveMQ data directory inaccessible because the ActiveMQ replica broker can't acquire the lock and therefore cannot start up. The only solution to this predicament with NFSv3 is to reboot all ActiveMQ instances to reset everything.

                                                              Use of NFSv4 is another solution because it's design includes timeouts for locks. When using NFSv4 and the client holding the lock experiences an abnormal termination, by design, the lock is released after 30 seconds, allowing another client to grab the lock. For more information about this, see this blog entry.

                                                              "},{"location":"community/jms-cluster/activemq/activemqBroker/","title":"HOWTO configure ActiveMQ broker","text":"

                                                              Deploy the produced activemqBroker.war in your tomcat instance and check the extracted webapp. You may locate a file called activemq-jmx.properties which will help you to configure your instance with the most important parameters. Anyhow it is only an example and we encourage you to also check the ApplicationContext.xml file deployed to activemq/WEB-INF/classes/ApplicationContext.xml which is the complete configuration:

                                                              ...\n<!-- The transport connectors expose ActiveMQ over a given protocol to \n  clients and other brokers. \n  For more information, see: http://activemq.apache.org/configuring-transports.html -->\n<transportConnectors>\n    <transportConnector name=\"openwire\" uri=\"tcp://192.168.1.XXX:61616\" />\n</transportConnectors>\n...\n
                                                              "},{"location":"community/jms-cluster/activemq/activemqBroker/#persistence-configuration","title":"Persistence Configuration","text":"

                                                              It is possible to enable persistence for messages that cannot be delivered right away (e.g. all consumers are down). Detailed information can be found here, we are simply going to provide basic information on how to achieve that. To configure the persistence for the messages to deliver you need to setup the node in the same file as above and then configure a proper datasource in your DBMS of choice.

                                                              ...\n<persistenceAdapter>\n<!-- <kahaDB directory=\"${activemq.base}/data/kahadb\"/> --> \n  <jdbcPersistenceAdapter dataDirectory=\"activemq-data\" \n    dataSource=\"#postgres-ds\" lockKeepAlivePeriod=\"0\"/>\n</persistenceAdapter>\n...\n

                                                              In the above section we defined a jdbcPersistenceAdapter connected to a dataSource called #postgres-ds that forces the broker to use PostgreSQL for persisting its messages when the delivery cannot be guaranteed (e.g. a replica goes down unexpectedly). You now need to configure your own datasource as specified in the following section which are specific for different DBMS.

                                                              "},{"location":"community/jms-cluster/activemq/activemqBroker/#oracle-datasource","title":"Oracle datasource","text":"

                                                              To configure the broker to use an oracle database as datasource you need to uncomment and modify the following peace into the ApplicationContext.xml file:

                                                              ...\n<bean id=\"oracle-ds\" class=\"org.apache.commons.dbcp.BasicDataSource\" destroy-method=\"close\">\n  <property name=\"driverClassName\" value=\"oracle.jdbc.driver.OracleDriver\"/>\n  <property name=\"url\" value=\"jdbc:oracle:thin:@localhost:1521:AMQDB\"/>\n  <property name=\"username\" value=\"oracle\"/>\n  <property name=\"password\" value=\" oracle \"/>\n  <property name=\"poolPreparedStatements\" value=\"true\"/>\n</bean>\n...\n

                                                              In addition, you need to make sure that the jar containing the driver for Oracle is correctly deployed inside the WEB-INF/lib for the activemq war file. At the same time the database referred in provided instructions as well as the user must be already present.

                                                              "},{"location":"community/jms-cluster/activemq/activemqBroker/#postgres-datasource","title":"Postgres datasource","text":"

                                                              Configuring PostgreSQL as the datasource to use for the persistence of the messages for the ActiveMQ broker follows the same pattern as above. See below for some examples.

                                                              ...\n<bean id=\"postgres-ds\" class=\"org.postgresql.ds.PGPoolingDataSource\">\n    <property name=\"serverName\" value=\"192.168.1.XXX\"/>\n    <property name=\"databaseName\" value=\"activemq\"/>\n    <property name=\"portNumber\" value=\"5432\"/>\n    <property name=\"user\" value=\"postgres\"/>\n    <property name=\"password\" value=\"postgres\"/>\n    <property name=\"dataSourceName\" value=\"postgres\"/>\n    <property name=\"initialConnections\" value=\"15\"/>\n    <property name=\"maxConnections\" value=\"30\"/>\n</bean>\n...\n

                                                              In addition, you need to make sure that the jar containing the driver for PostgreSQL is correctly deployed inside the WEB-INF/lib for the activemq war file. At the same time the database referred in provided instructions as well as the user must be already present.

                                                              Note

                                                              The above ApplicationContext.xml file contains some unused sections which are intentionally commented out to show different types of configurations [Ref. ActiveMQ].

                                                              "},{"location":"community/jms-cluster/activemq/activemqBroker/#kaha-datasource-embedded-database","title":"Kaha datasource (Embedded database)","text":"

                                                              Besides using server DBMS as indicated above we can use embedded database for simpler uses cases of demoing since this usually largely simplify the configuration. At this link all the information needed for achieving this result can be found; basically we need to uncomment the related datasource and then reference it from the persistenceAdapter.

                                                              "},{"location":"community/jms-cluster/activemq/activemqBroker/#control-instances-using-jmx","title":"Control instances using JMX","text":"

                                                              Be sure to edit the activemq-jmx.properties (or via the environment variables) setting different JMX ports for different broker instances. Deploy as explained the instances into 2 different webapplication container (f.e. Tomcat) and start both application (on different port f.e. 8081 and 8082). Now run jconsole to connect to the brokers via JMX:

                                                              \\${JAVA_HOME}/bin/jconsole

                                                              After you connect to the brokers you may see something like this:

                                                              You may look at the console, as you can see the 2nd instance of the broker cannot take the look on the file (the example uses KahaDB); this is also visible in the JMX console into the widhow on the right side.

                                                              If now you select the 'operation' (on the left side window) you will see:

                                                              Using that console we are able to perform many operation, so to simulate a broker down we try to click on the 'stop()' button.

                                                              Doing so, the first broker instance will stop and the JMX connection will be closed, and the second instance (on the right side) will keep the control of the DB.

                                                              "},{"location":"community/keycloak/","title":"Keycloak extension","text":"

                                                              The Keycloak module allows GeoServer to work with a keycloak service to authenticate users and establish authorization using roles.

                                                              • Installing Keycloak
                                                              • Authentication with Keycloak
                                                              • Keycloak Role Service
                                                              "},{"location":"community/keycloak/authentication/","title":"Authentication with Keycloak","text":"

                                                              This tutorial introduces GeoServer Keycloak support and walks through the process of setting up authentication against an Keycloak provider. It is recommended that the Authentication chain section be read before proceeding.

                                                              The GeoServer Keycloak-authn/authz plugin will allow you to use an instance of Keycloak to control access to resources within GeoServer.

                                                              "},{"location":"community/keycloak/authentication/#configuration-instructions","title":"Configuration Instructions","text":"

                                                              As the Keycloak Admin:

                                                              Note

                                                              In this example the Keycloak service runs on port 8080 while GeoServer runs on port 8181

                                                              1. Create a new client for GeoServer named geoserver-client.

                                                              2. Make sure to add the base URL of GeoServer to the list of acceptable redirect paths, and add also the Keycloak OIDC endpoint base URI.

                                                                eg:
                                                                • http://localhost:8181/geoserver*
                                                                • http://localhost:8080/auth/realms/demo/broker/keycloak-oidc/endpoint*
                                                                ![](images/keycloak_client002.png)\n
                                                              3. Set the access-type of client as appropriate. If your GeoServer instance is depending on another service for authentication (eg: NGINX auth plugin) then you should probably select bearer-only. Otherwise, you should select confidential.

                                                              4. Add the ADMINISTRATOR and AUTHENTICATED client-role to the geoserver-client in Keycloak.

                                                                In this phase you will need to map GeoServer Roles to the geoserver-client ones in Keycloak.

                                                                Use the AUTHENTICATED one for generic users. Assign this role ADMINISTRATOR to the users/groups who should have administrative access to GeoServer.

                                                              5. Obtain the installation-configuration for the geoserver-client in JSON, and provide this to the GeoServer Admin for the next steps.

                                                              As the GeoServer Admin:

                                                              Note

                                                              In this example the Keycloak service runs on port 8080 while GeoServer runs on port 8181

                                                              1. Under the Authentication UI, add a new authentication-filter. Select Keycloak from the list of provided options, and name your new filter keycloak_adapter. Paste the installation-configuration from the Keycloak-server in the text area provided.

                                                                If not present, be sure to add the following options before clicking Save:

                                                                \"use-resource-role-mappings\": true\n

                                                                The Enable redirect to Keycloak Login page checkbox should be checked if the desired behaviour is to authenticate on the web ui only through keycloak. Note that in this case the keycloak filter should be the only one available in the /web filter chain. On the contrary if the keycloak filter needs to coexists with other filters on the filter chain and reach it must be unchecked.

                                                                The Role Source drop down enable the selection of the desired role source for the user being authenticated through keycloak. If none is selected by default the Active Role Service will be used.

                                                              2. Add the keycloak_adapter to the web filter-chain if you want to protect the Admin GUI, as an instance. If you have checked Enable redirect to Keycloak Login page on the filter configuration to be redirected every time to Keycloak, then remove all of the others chain filters (basic, form, rememberme, anonymous).

                                                              3. Once done navigate to the GeoServer UI. If at filter configuration time the checkbox Enable redirect to Keycloak Login page was kept unchecked and the keycloak filter cohexists on the /web chain with the form and anonymous filter you will see a keycloak login button that allows the user to reach the keycloak login page.

                                                              Otherwise the user will be directly redirected to the Keycloak login-page, and after logging-in redirected back to the actual GeoServer UI page.

                                                              You should verify that the message logged in as <USERNAME> is posted in the top right corner before continuing.

                                                              Warning

                                                              Workaround in the event of a 403 unauthorized response after logging-in.

                                                              Enforce the algorithm RS256 in the keycloak client.

                                                              Copy the public key for the RS256 algorithm from the Realm Settings into the adapter config as:

                                                              \"realm-public-key\": XXXXXXX\n

                                                              "},{"location":"community/keycloak/installation/","title":"Installing Keycloak","text":"

                                                              To install the keycloak module:

                                                              1. To obtain the keycloak community module:

                                                                • If working with a 2.24.2 nightly build, download the module: keycloak

                                                                  Verify that the version number in the filename corresponds to the version of GeoServer you are running (for example 2.24.2 above).

                                                                • Community modules are not yet ready for distribution with GeoServer release.

                                                                  To compile the keycloak community module yourself download the src bundle for your GeoServer version and compile:

                                                                  cd src/community\nmvn install -PcommunityRelease -DskipTests\n

                                                                  And package:

                                                                  cd src/community\nmvn assembly:single -N\n
                                                                  2. Place the JARs in WEB-INF/lib. 3. Restart GeoServer.

                                                              "},{"location":"community/keycloak/keycloak_role_service/","title":"Keycloak Role Service","text":"

                                                              This tutorial walks through how to set up Keycloak as a role service for GeoServer.

                                                              Note

                                                              In this example the Keycloak service runs on port 8080 while GeoServer runs on port 8181.

                                                              The Keycloak Role Service uses the Keycloak REST api in order to retrieve the roles for its various operations. By default it will retrieve roles with realm scope. However it can be configured to retrieve roles with a client scope in a specific realm.

                                                              "},{"location":"community/keycloak/keycloak_role_service/#keycloak-client-configuration","title":"Keycloak Client Configuration","text":"

                                                              Follow the Authentication with Keycloak guide to configure GeoServer to allow logging in via Keycloak. The Keycloak Role Service needs a client to be configured on Keycloak side having Access Type set to confidential.

                                                              If for your Keycloak Authentication Filter you have used a different Access Type i.e. barer-only, a separate client will have then to be configured for the Keycloak Role Service.

                                                              For the client, ensure that:

                                                              • Standard flow, implicit flow, and direct access grants are enabled
                                                              • The base URL is set to http://localhost:8181/geoserver/web
                                                              • The following redirect URIs are enabled:
                                                                • http://localhost:8181/geoserver*
                                                                • http://localhost:8080/auth/realms/master/broker/keycloak-oidc/endpoint*
                                                              • The Access Type is set to confidential and the Service Accounts Enabled option is enabled.

                                                              • Under the Service Account Roles tab, ensure that the realm-admin, from the realm-management client role is addedd to the Assigned roles.

                                                              To assign a user a role:

                                                              1. Under the users section in Keycloak, click the user's ID (if there are missing users, click \"View all users\").
                                                              2. In the role mappings tab, select the GeoStore client from the client roles dropdown.
                                                              3. Select the role from the available roles, and click add selected.

                                                              An example set of role mappings for a user.

                                                              When creating custom roles, ensure they begin with ROLE_ e.g. ROLE_STAFF.

                                                              "},{"location":"community/keycloak/keycloak_role_service/#geoserver-configuration-for-role-syncing","title":"GeoServer Configuration for Role Syncing","text":"

                                                              Role syncing with Keycloak will be tied to the confidential client.

                                                              1. In GeoServer as an admin, on the 'Users, Groups, Roles' page, add a new role service.
                                                              2. Select Keycloak from the list of provided options. All fillable fields are required, excluding the Comma separated list of ID of client (not client-id).
                                                                • Base URL for Keycloak is the keycloak host name eg. http://localhost:8080.
                                                                • The Realm Name is the realm from which the roles should be retrieved eg. master.
                                                                • The Client ID can be retrieved from the Settings tab of the client configuration on Keycloak.
                                                                • The Client secret can be retrieved from the Credentials tab of the client configuration on Keycloak.
                                                                • The Comma separated list of ID of client (not client-id) is meant to allow the Role Service to retrieve also roles with client scope. By default indeed the Keycloak Role Service will retrieve realm roles only. The id of a client can be retrieved from the URL when viewing the client configuration page in Keycloak. URL format: eg. /auth/admin/master/console/#/realms/master/clients/{ID of client}

                                                              Administrator Role and Group administator role dropdown should be empty at the beginning. They can be filled once saved the role service with the Keycloak role that we want to map to the GeoServer ADMIN and GROUP ADMIN.

                                                              1. Ensure you click save to create the Keycloak role service.
                                                              2. Once the Role Service has been created and configured to have it active:
                                                                • it can be assigned as a RoleSource to the Keycloak Filter,
                                                                • it can be set as the Active Role Service in the Security Settings page.

                                                              An example of a fully configured Keycloak role service.

                                                              "},{"location":"community/keycloak/keycloak_role_service/#geoserver-configuration-for-keycloak-authentication-filters","title":"GeoServer Configuration for Keycloak Authentication Filters","text":"

                                                              Under the Authentication section of GeoServer:

                                                              • Add the Keycloak authentication filter to the top of the web and default filter chains.
                                                              • Add keycloak to the selected provider chains, and place it above the default.
                                                              "},{"location":"community/libdeflate/","title":"Libdeflate","text":"

                                                              Support for alternative Deflate encoder/decoder provided through libdeflate JNI bindings for Java which provides better performance.

                                                              • Reading can be 10% - 20% faster
                                                              • Writing can be 40% - 60% faster

                                                              (Tests have been made on deflate input data stored on SSD disk so neither Disk I/O, nor Network transfer was the bottleneck)

                                                              "},{"location":"community/libdeflate/#installation","title":"Installation","text":"

                                                              As a community module, the package needs to be downloaded from the nightly builds, picking the community folder of the corresponding GeoServer series (e.g. if working on the GeoServer main development branch nightly builds, pick the zip file form main/community-latest).

                                                              To install the module, unpack the zip file contents into the GeoServer WEB-INF/lib directory and restart GeoServer.

                                                              When the community module is not installed, the TIFF Deflate compression/decompression goes through ZLIB based ZIP Deflater and Inflater counterpart. Once the community module plugin is installed, TIFF Deflate compression/decompression goes through libdeflate by default. This can be however customized, by changing the plugin priority in the Global Settings page of GeoServer.

                                                              "},{"location":"community/libdeflate/#global-settings","title":"Global Settings","text":"

                                                              Default ZIP Deflater compression plugin has priority 50. Libdeflate compression plugin has default priority 80 for both compression and decompression. Is it possible to fallback to the old plugin for either compression, decompression or both. Go to the Global Settings and set the priority to a value lower than 50.

                                                              Default Libdeflate compression Settings

                                                              Finally, during testing phases, we found that, at compression level 9, the old plugin is faster than the new one. By default, when priority is higher, the Libdeflate compression will be only used for compression levels in the range 1 to 8. These settings can be modified in the above Global Settings too.

                                                              "},{"location":"community/libdeflate/#current-limitations","title":"Current limitations","text":"

                                                              The current available version is 0.1.0-beta which only contains linux libraries.

                                                              "},{"location":"community/mbtiles/","title":"MBTiles Extension","text":"

                                                              This plugin brings in the ability to read and write MBTiles files in GeoServer. MBTiles is an SQLite based standard format that is able to hold a single tiles map layer in a file.

                                                              MBTiles can both be used as a raster input datastore as well as an WMS GetMap output format.

                                                              • Installing the GeoServer MBTiles extension
                                                              • MBTiles Raster and Vector Data Stores
                                                              • MBTiles Output Format
                                                              "},{"location":"community/mbtiles/input/","title":"MBTiles Raster and Vector Data Stores","text":""},{"location":"community/mbtiles/input/#adding-an-mbtiles-mosaic-raster-data-source","title":"Adding an MBTiles Mosaic Raster Data Source","text":"

                                                              When the extension has been installed, :guilabel:MBTiles` will be an option in the Raster Data Sources list when creating a new data store.

                                                              MBTiles in the list of raster data sources

                                                              Configuring an MBTiles data source

                                                              Option Description Workspace Name of the workspace to contain the MBTiles Mosaic store. This will also be the prefix of the raster layers created from the store. Data Source Name Name of the MBTiles Store as it will be known to GeoServer. This can be different from the filename. Description A full free-form description of the MBTiles store. Enabled If checked, it enables the store. If unchecked (disabled), no data in the GeoPackage Mosaic Store will be served from GeoServer. URL Location of the MBTiles file. This can be an absolute path (such as file:C:\\Data\\landbase.mbtiles) or a path relative to GeoServer's data directory (such as file:data/landbase.mbtiles)."},{"location":"community/mbtiles/input/#adding-an-mbtiles-vector-tiles-data-store","title":"Adding an MBTiles vector tiles Data Store","text":"

                                                              When the extension has been installed, MBTiles with vector tiles will be an option in the Vector Data Sources list when creating a new data store.

                                                              MBTiles in the list of vector data sources

                                                              Configuring an MBTiles data store

                                                              Option Description database Path to the MBTiles file user Optional username passwd Optional password

                                                              After configuration the store will allow setting up the layers, as they get described in the json entry of the metadata table.

                                                              Configuring layers out of a MBTiles store

                                                              Each vector tile contains data for all the layers described, the store maintains a \"soft cache\" of parsed tiles to avoid re-parsing them from the binary on multi-layer rendering operations.

                                                              "},{"location":"community/mbtiles/installing/","title":"Installing the GeoServer MBTiles extension","text":"

                                                              Warning

                                                              Make sure to match the version of the extension to the version of the GeoServer instance!

                                                              1. Download the extensions from the nightly GeoServer community module builds.

                                                                1. Download the mbtiles-store-plugin from mbtiles-store if you simply want to read MBTiles files.
                                                                2. Download the mbtiles-plugin from mbtiles if you also want to use the WMS output format generaring MBTiles and the WPS process doing the same. Make sure to install corresponding WPS extension for GeoServer instance before installing this plugin, or GeoServer won't start.
                                                              2. Extract the contents of the archive into the WEB-INF/lib directory of the GeoServer installation.

                                                              "},{"location":"community/mbtiles/output/","title":"MBTiles Output Format","text":""},{"location":"community/mbtiles/output/#mbtiles-wms-output-format","title":"MBTiles WMS Output Format","text":"

                                                              Any WMS GetMap request can be returned in the form of a Geopackage by specifying format=mbtiles as output format (see WMS output formats). The returned result will be an MBTiles file with a single tile layer.

                                                              The following additional parameters can be passed on using format_options:
                                                              • tileset_name: name to be used for tileset in mbtiles file (default is name of layer(s)).
                                                              • min_zoom, max_zoom, min_column, max_column, min_row, max_row: set the minimum and maximum zoom level, column, and rows
                                                              • gridset: name of gridset to use (otherwise default for CRS is used)

                                                              Warning

                                                              The GetMap request won't be subject to any execution time limit, a client can thus make request that will takes very long times to execute by providing a high max_zoom value.

                                                              "},{"location":"community/mbtiles/output/#mbtiles-wps-process","title":"MBTiles WPS Process","text":"

                                                              It is possible to generate an mbtiles file by calling the WPS process gs:MBTiles. This process requires the following parameters:

                                                              • layername: Name of the input layer.
                                                              • format : format of the final images composing the file.
                                                              • minZoom, maxZoom, minColumn, maxColumn, minRow, maxRow: (Optional) set the minimum and maximum zoom level, column, and rows.
                                                              • boundingbox: (Optional) Bounding box of the final mbtiles. If CRS is not set, the layer native one is used.
                                                              • filename: (Optional) name of the mbtiles file created.
                                                              • bgColor: (Optional) value associated to the background colour.
                                                              • transparency: (Optional) parameter indicating if the transparency must be present.
                                                              • stylename, stylepath, stylebody: (Optional) style to associate to the layer. Only one of these 3 parameters can be used.

                                                              The process returns an URL containing the path of the generated file.

                                                              Warning

                                                              The process implementation does not currently support cancellation, a client can thus make request that will takes very long times to execute by providing a high max_zoom value.

                                                              "},{"location":"community/monitor-hibernate/","title":"Monitoring Hibernate storage","text":"

                                                              The monitor hibernate storage allows to track the requests made against a GeoServer instance in a relational database, as opposed to keeping the data in memory for a short time, or logging it on a audit file.

                                                              • Installing the Hibernate Monitor Extension
                                                              • Hibernate storage Configuration
                                                              • Database Persistence
                                                              • Upgrading
                                                              "},{"location":"community/monitor-hibernate/configuration/","title":"Hibernate storage Configuration","text":"

                                                              Many aspects of the monitor extension are configurable. The configuration files are stored in the data directory under the monitoring directory:

                                                              <data_directory>\n    monitoring/\n        db.properties\n        hibernate.properties\n

                                                              In particular: * db.properties - Database configuration when using database persistence. * hibernate.properties - Hibernate configuration when using database persistence.

                                                              "},{"location":"community/monitor-hibernate/configuration/#monitor-storage","title":"Monitor Storage","text":"

                                                              How request data is persisted is configurable via the storage property defined in the monitor.properties file. The following values are supported for the storage property:

                                                              • memory - Request data is to be persisted in memory alone.
                                                              • hibernate - Request data is to be persisted in a relational database via Hibernate.

                                                              The default value is memory, in order to use hibernate the storage configuration needs to be switced to hibernate.

                                                              "},{"location":"community/monitor-hibernate/db/","title":"Database Persistence","text":"

                                                              The monitor extension is capable of persisting request data to a database via the Hibernate library.

                                                              Note

                                                              In order to utilize hibernate persistence the hibernate extension must be installed on top of the core monitoring extension. See the Installing the Monitor Extension for details.

                                                              "},{"location":"community/monitor-hibernate/db/#configuration","title":"Configuration","text":""},{"location":"community/monitor-hibernate/db/#general","title":"General","text":"

                                                              In order to activate hibernate persistence the storage parameter must be set to the value \"hibernate\":

                                                              storage=hibernate\n

                                                              The hibernate storage backend supports both the history and live modes however care should be taken when enabling the live mode as it results in many transactions with the database over the life of a request. Unless updating the database in real time is required the history mode is recommended.

                                                              "},{"location":"community/monitor-hibernate/db/#database","title":"Database","text":"

                                                              The file db.properties in the <GEOSERVER_DATA_DIR>/monitoring directory specifies the Hibernate database. By default an embedded H2 database located in the monitoring directory is used. This can be changed by editing the db.properties file:

                                                              # default configuration is for h2 \ndriver=org.h2.Driver\nurl=jdbc:h2:file:${GEOSERVER_DATA_DIR}/monitoring/monitoring\n

                                                              For example to store request data in an external PostgreSQL database, set db.properties to:

                                                              driver=org.postgresql.Driver \nurl=jdbc:postgresql://192.168.1.124:5432/monitoring\nusername=bob\npassword=foobar\ndefaultAutoCommit=false\n

                                                              In addition to db.properties file is the hibernate.properties file that contains configuration for Hibernate itself. An important parameter of this file is the hibernate dialect that informs hibernate of the type of database it is talking to.

                                                              When changing the type of database both the databasePlatform and database parameters must be updated. For example to switch to PostgreSQL:

                                                              # hibernate dialect\ndatabasePlatform=org.hibernate.dialect.PostgreSQLDialect\ndatabase=POSTGRESQL\n\n# other hibernate configuration\nhibernate.use_sql_comments=true\ngenerateDdl=true\nhibernate.format_sql=true\nshowSql=false\nhibernate.generate_statistics=true\nhibernate.session_factory_name=SessionFactory\nhibernate.hbm2ddl.auto=update\nhibernate.bytecode.use_reflection_optimizer=true\nhibernate.show_sql=false\n
                                                              "},{"location":"community/monitor-hibernate/db/#hibernate","title":"Hibernate","text":"

                                                              As mentioned in the previous section the hibernate.properties file contains the configuration for Hibernate itself. Aside from the database dialect parameters it is not recommended that you change this file unless you are an experienced Hibernate user.

                                                              "},{"location":"community/monitor-hibernate/installation/","title":"Installing the Hibernate Monitor Extension","text":"

                                                              Note

                                                              If performing an upgrade of the monitor extension please see Upgrading.

                                                              As a community module, the package needs to be downloaded from the nightly builds, picking the community folder of the corresponding GeoServer series (e.g. if working on GeoServer main development branch nightly builds, pick the zip file form main/community-latest).

                                                              To install the module, unpack the zip file contents into GeoServer own WEB-INF/lib directory and restart GeoServer.

                                                              For the module to work, the Monitoring extensions must also be installed.

                                                              "},{"location":"community/monitor-hibernate/upgrade/","title":"Upgrading","text":"

                                                              The monitoring extension uses Hibernate to persist request data. Changes to the extension over time affect the structure of the underlying database, which should be taken into consideration before performing an upgrade. Depending on the nature of changes in an upgrade, it may involve manually making changes to the underlying database before deploying a new version of the extension.

                                                              The sections below provides a history of such changes, and recommended actions that should be taken as part of the upgrade. Upgrades are grouped into two categories:

                                                              • minor upgrades that occur during a minor GeoServer version change, for example going from 2.1.2 to 2.1.3. These changes are backward compatible in that no action is specifically required but potentially recommended. In these cases performing an upgrade without any action still result in the monitoring extension continuing to function.
                                                              • major upgrades that occur during a major GeoServer version change, for example going from 2.1.2 to 2.2.0. These changes may be backward compatible, but not necessarily. In these cases performing an upgrade without any action could potentially result in the monitoring extension ceasing to function, and may result in significant changes to the underlying database.

                                                              For each change the following information is maintained:

                                                              • The released version containing the change
                                                              • The date of the change
                                                              • The subversion revision of the change
                                                              • The jira issue referring to the change

                                                              The date and subversion revision are especially useful if a nightly build of the extension is being used.

                                                              "},{"location":"community/monitor-hibernate/upgrade/#minor-upgrades","title":"Minor upgrades","text":""},{"location":"community/monitor-hibernate/upgrade/#column-resource-renamed-to-name-in-request_resources-table","title":"Column resource renamed to name in request_resources table","text":"
                                                              • Version: n/a, extension still community status
                                                              • Date: Dec 09, 2011
                                                              • Subversion revision: 16632
                                                              • Reference: GEOS-4871

                                                              Upgrading without performing any action will result in the name column being added to the request_resources table, leaving the resource column intact. From that point forward the resource column will essentially be ignored. However no data from the resource column will be migrated, which will throw off reports, resource access statistics, etc... If you wish to migrate the data perform one of the following actions two actions.

                                                              The first is a pre upgrade action that involves simply renaming the column before deploying the new monitoring extension:

                                                              ALTER TABLE request_resources RENAME COLUMN resource to name;\n

                                                              Alternatively the migration may occur post upgrade:

                                                              UPDATE TABLE request_resources SET name = resource where name is NULL;\nALTER TABLE request_resources DROP COLUMN resource;\n
                                                              "},{"location":"community/monitor-hibernate/upgrade/#column-remote_user_agent-added-to-request-table","title":"Column remote_user_agent added to request table","text":"
                                                              • Version: n/a, extension still community status
                                                              • Date: Dec 09, 2011
                                                              • Subversion revision: 16634
                                                              • Reference: GEOS-4872

                                                              No action should be required here as Hibernate will simply append the new column to the table. If for some reason this does not happen the column can be added manually:

                                                              ALTER TABLE request ADD COLUMN remote_user_agent VARCHAR(1024);\n
                                                              "},{"location":"community/monitor-hibernate/upgrade/#major-upgrades","title":"Major upgrades","text":""},{"location":"community/monitor-kafka/","title":"Monitoring Kafka storage","text":"

                                                              The Monitor Kafka storage extension allows to track the requests made against a GeoServer instance in an Apache Kafka topic, as opposed to keeping the data in memory for a short time, or logging it on a audit file.

                                                              • Installing the Kafka Monitor Extension
                                                              • Kafka storage Configuration
                                                              • Usage of Monitoring Kafka extension
                                                              • Message keys are not supported. This means that the messages will be distributed in a round robbin fashion between the partitions.
                                                              • The extension tries to connect and describe the topic at startup, if the topic does not exist or the connection cannot be established the extension will fail to start and disable itself. Subsequent requests to this instance will not be logged. The timeout for the describe command is set to 10 seconds.
                                                              • The only used serialization format is avro. Avro might be used in other extensions like geomesa where a conflict with the version of kafka-avro library might be possible.
                                                              Permissions

                                                              The Kafka extension needs the following permissions on the Kafka topic in order to work:

                                                              • DESCRIBE
                                                              • WRITE
                                                              "},{"location":"community/monitor-kafka/configuration/","title":"Kafka storage Configuration","text":"

                                                              Many aspects of the monitor extension are configurable. The configuration files are stored in the data directory under the monitoring directory:

                                                              <data_directory>\n    monitoring/\n        monitor.properties\n

                                                              In particular:

                                                              • monitor.properties - Can be extended to set the connection details to Apache Kafka.
                                                              "},{"location":"community/monitor-kafka/configuration/#monitor-storage","title":"Monitor Storage","text":"

                                                              How request data is persisted is configurable via the storage property defined in the monitor.properties file. The following values are supported for the storage property:

                                                              • memory - Request data is to be persisted in memory alone.
                                                              • hibernate - Request data is to be persisted in a relational database via Hibernate.
                                                              • kafka - Request data is to be persisted in Apache Kafka.

                                                              The default value is memory, in order to use Apache Kafka the storage configuration needs to be switched to kafka.

                                                              In addition you can set the topic name with the kafka.topic property. The default value is geoserver-monitor.

                                                              You can set all the Kafka properties for a kafka producer by prefixing it with the kafka keyword e.g. set the acks to 1 with kafka.acks=1. For further details on the Kafka producer properties see the Kafka documentation.

                                                              The following is an example of the monitor.properties file configured to use Apache Kafka:

                                                              storage=kafka\n... other properties ...\nkafka.bootstrap.servers=localhost:9092\nkafka.topic=monitor\nkafka.acks=1\nkafka.retries=3\nkafka.batch.size=65536\nkafka.linger.ms=200\nkafka.compression.type=snappy\nkafka.schema.registry.url=http://localhost:8081\n

                                                              In order to use Confluent Cloud you need to configure these properties:

                                                              storage=kafka\n... other properties ...\nkafka.bootstrap.servers=pkc-def12.europe-west.gcp.confluent.cloud:9092\nkafka.topic=monitor\nkafka.security.protocol=SASL_SSL\nkafka.sasl.mechanism=PLAIN\nkafka.sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required username='KAFKA_API_KEY' password='KAFKA_SECRET';\nkafka.schema.registry.url=https://psrc-abc12.europe-west.gcp.confluent.cloud\nkafka.schema.registry.basic.auth.credentials.source=USER_INFO\nkafka.schema.registry.basic.auth.user.info=SR_API_KEY:SR_API_SECRET\n\nkafka.acks=1\nkafka.retries=0\nkafka.batch.size=65536\nkafka.linger.ms=200\nkafka.compression.type=snappy\n

                                                              It might be a good idea to set the kafka.linger.ms to avoid too many requests to the Kafka broker and get the benefits from batching and compression. One request can cause multiple messages to be sent to Kafka as a load of multiple tiles may does. Also the compressions should be quite effective as the messages repeat some data. Make sure to also set the kafka.compression.type.

                                                              "},{"location":"community/monitor-kafka/installation/","title":"Installing the Kafka Monitor Extension","text":"

                                                              As a community module, the package needs to be downloaded from the nightly builds, picking the community folder of the corresponding GeoServer series (e.g. if working on GeoServer main development branch nightly builds, pick the zip file form main/community-latest).

                                                              To install the module, unpack the zip file contents into GeoServer own WEB-INF/lib directory and restart GeoServer.

                                                              For the module to work, the Monitoring extensions must also be installed.

                                                              "},{"location":"community/monitor-kafka/usage/","title":"Usage of Monitoring Kafka extension","text":"

                                                              To try out there is a docker-compose.yml file in the test/resources directory. This will start up a Kafka broker and a schema registry instance. To start it up you need docker and docker-compose installed then run:

                                                              # start kafka\ncd src/community/monitor-kafka/src/test/resources\ndocker-compose up -d\n

                                                              This will start up the Kafka broker and the schema registry.

                                                              Once Kafka is running start geoserver with monitor and monitor-kafka extension from src/web/app:

                                                              mvn jetty:run -P monitor,monitor-kafka\n

                                                              This will initialize the data directory in src/web/app/src/main/webapp/data and start up geoserver. Stop the geoserver again.

                                                              With this you will get the default monitor config installed automatically in src/web/app/src/main/webapp/data/monitoring/. Edit it to use the Kafka storage.

                                                              Then you need to configure the monitor-kafka extension for it with:

                                                              storage=kafka\nkafka.bootstrap.servers=localhost:9092\nkafka.schema.registry.url=http://localhost:8081\n

                                                              Create your topic with:

                                                              docker exec -ti broker kafka-topics --bootstrap-server localhost:9092 --create --topic geoserver-monitor --partitions 1 --replication-factor 1 --if-not-exists\n

                                                              Start geoserver again with:

                                                              mvn jetty:run -P monitor,monitor-kafka\n

                                                              Check that the monitoring extension is actually enabled by looking for the following log line:

                                                              INFO   [geoserver.monitor] - Kafka connection established and topic geoserver-monitor exists\n

                                                              Head over to http://localhost:8080/geoserver and hit some map, so you get some data into the topic.

                                                              If you want to consume the data you need a consumer which has the right Deserializer configured (io.confluent.kafka.serializers.KafkaAvroDeserializer).

                                                              The easiest way to do this is to enter the schema registry container with:

                                                              docker exec -ti schema-registry bash\n# from within the container run:\n  kafka-avro-console-consumer \\\n    --bootstrap-server broker:29092 \\\n    --topic geoserver-monitor \\\n    --from-beginning\n\n# or directly from the host machine so you can pipe it into jq or a file...\ndocker exec -ti schema-registry kafka-avro-console-consumer \\\n    --bootstrap-server broker:29092 \\\n    --topic geoserver-monitor \\\n    --from-beginning | tee >(grep -E \"^{\" | jq) | grep -vE \"^{\"\n

                                                              Then you will see messages like this:

                                                              {\n    \"id\": 2,\n    \"status\": \"FINISHED\",\n    \"category\": \"OWS\",\n    \"path\": \"/tiger/wms\",\n    \"queryString\": \"SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&FORMAT=image/png&TRANSPARENT=true&STYLES&LAYERS=tiger:giant_polygon&exceptions=application/vnd.ogc.se_inimage&SRS=EPSG:4326&WIDTH=768&HEIGHT=384&BBOX=3.7958354296875,-40.4131489453125,71.2627583203125,-6.6962260546875\",\n    \"body\": \"\",\n    \"bodyContentLength\": 0,\n    \"bodyContentType\": \"\",\n    \"httpMethod\": \"GET\",\n    \"startTime\": 1697172148809,\n    \"endTime\": 1697172148902,\n    \"totalTime\": 93,\n    \"remoteAddress\": \"[0:0:0:0:0:0:0:1]\",\n    \"remoteHost\": \"0:0:0:0:0:0:0:1\",\n    \"host\": \"localhost\",\n    \"internalHost\": \"client\",\n    \"remoteUser\": \"anonymous\",\n    \"remoteUserAgent\": \"Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/117.0.0.0 Safari/537.36\",\n    \"remoteCountry\": \"\",\n    \"remoteCity\": \"\",\n    \"remoteLat\": 0.0,\n    \"remoteLon\": 0.0,\n    \"service\": \"WMS\",\n    \"operation\": \"GetMap\",\n    \"owsVersion\": \"1.1.1\",\n    \"subOperation\": \"\",\n    \"resources\": [\n        \"tiger:giant_polygon\"\n    ],\n    \"responseLength\": 6594,\n    \"responseContentType\": \"image/png\",\n    \"errorMessage\": \"\",\n    \"responseStatus\": 0,\n    \"httpReferer\": \"\",\n    \"coordinateReferenceSystem\": \"EPSG:WGS 84\",\n    \"minx\": 3.7958354296875,\n    \"miny\": -40.4131489453125,\n    \"maxx\": 71.2627583203125,\n    \"maxy\": -6.6962260546875,\n    \"cacheResult\": \"\",\n    \"missReason\": \"\",\n    \"resourceProcessingTimes\": [],\n    \"labelingProcessingTime\": 0\n}\n{\n    \"id\": 3,\n    \"status\": \"FINISHED\",\n    \"category\": \"OWS\",\n    \"path\": \"/tiger/wms\",\n    \"queryString\": \"SERVICE=WMS&VERSION=1.1.1&REQUEST=GetFeatureInfo&FORMAT=image/png&TRANSPARENT=true&QUERY_LAYERS=tiger:giant_polygon&STYLES&LAYERS=tiger:giant_polygon&exceptions=application/vnd.ogc.se_inimage&INFO_FORMAT=text/html&FEATURE_COUNT=50&X=50&Y=50&SRS=EPSG:4326&WIDTH=101&HEIGHT=101&BBOX=39.23891004908502,-32.22561743843973,48.11586317408502,-23.348664313439727\",\n    \"body\": \"\",\n    \"bodyContentLength\": 0,\n    \"bodyContentType\": \"\",\n    \"httpMethod\": \"GET\",\n    \"startTime\": 1697172178181,\n    \"endTime\": 1697172178213,\n    \"totalTime\": 32,\n    \"remoteAddress\": \"[0:0:0:0:0:0:0:1]\",\n    \"remoteHost\": \"\",\n    \"host\": \"localhost\",\n    \"internalHost\": \"client\",\n    \"remoteUser\": \"anonymous\",\n    \"remoteUserAgent\": \"Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/117.0.0.0 Safari/537.36\",\n    \"remoteCountry\": \"\",\n    \"remoteCity\": \"\",\n    \"remoteLat\": 0.0,\n    \"remoteLon\": 0.0,\n    \"service\": \"WMS\",\n    \"operation\": \"GetFeatureInfo\",\n    \"owsVersion\": \"1.1.1\",\n    \"subOperation\": \"\",\n    \"resources\": [\n        \"giant_polygon\"\n    ],\n    \"responseLength\": 803,\n    \"responseContentType\": \"text/html;charset=utf-8\",\n    \"errorMessage\": \"\",\n    \"responseStatus\": 0,\n    \"httpReferer\": \"\",\n    \"coordinateReferenceSystem\": \"EPSG:WGS 84\",\n    \"minx\": 43.63344129908502,\n    \"miny\": -27.743195563439727,\n    \"maxx\": 43.63344129908502,\n    \"maxy\": -27.743195563439727,\n    \"cacheResult\": \"\",\n    \"missReason\": \"\",\n    \"resourceProcessingTimes\": [],\n    \"labelingProcessingTime\": 0\n}\n
                                                              "},{"location":"community/ncwms/","title":"ncWMS WMS extensions support","text":"

                                                              The ncWMS module adds to GeoServer the ability to support some of the ncWMS extensions to the WMS protocol and configuration. In particular:

                                                              • Ability to create a named style by simply providing a list of colors, that will adapt to the layer in use based on request parameters and its statistics
                                                              • Ability to control the palette application in GetMap via a number of extra parameters
                                                              • GetTimeSeries operation, which can retrieve a CSV or an xy chart of a time series of values on a certain point

                                                              At the time of writing the extra calls to extract elevation series, transects and NetCDF metadata are not supported. The extension is however not NetCDF specific, but can be used with any single banded raster layer instead.

                                                              "},{"location":"community/ncwms/#the-dynamic-palette-style-format","title":"The Dynamic Palette style format","text":"

                                                              A new \"Dynamic palette\" style format has been added that accepts a palette, one color per line, defining a color progression to be applied on raster data. Each color can be defined using these possible syntaxes (same as ncWMS):

                                                              • #RRGGBB
                                                              • #AARRGGBB
                                                              • 0xRRGGBB
                                                              • 0xAARRGGBB

                                                              Comments can be added in the file by starting the line by a percentage sign. For example, a red to blue progression might look like:

                                                              % Red to blue progression\n#FF0000\n#0000FF\n

                                                              Configuring a dynamic palette style

                                                              Several ready to use palettes coming from the popular \"color brewer\" site are available in the ncWMS source code repository.

                                                              The palette translates on the fly into a SLD with rendering transformation using the Dynamic colormap generation module, in particular, the above style translates to the following style:

                                                              <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<sld:StyledLayerDescriptor xmlns=\"http://www.opengis.net/sld\" xmlns:sld=\"http://www.opengis.net/sld\" xmlns:gml=\"http://www.opengis.net/gml\" xmlns:ogc=\"http://www.opengis.net/ogc\" version=\"1.0.0\">\n  <sld:NamedLayer>\n    <sld:Name/>\n    <sld:UserStyle>\n      <sld:Name/>\n      <sld:FeatureTypeStyle>\n        <sld:Transformation>\n          <ogc:Function name=\"ras:DynamicColorMap\">\n            <ogc:Function name=\"parameter\">\n              <ogc:Literal>data</ogc:Literal>\n            </ogc:Function>\n            <ogc:Function name=\"parameter\">\n              <ogc:Literal>opacity</ogc:Literal>\n              <ogc:Function name=\"env\">\n                <ogc:Literal>OPACITY</ogc:Literal>\n                <ogc:Literal>1.0</ogc:Literal>\n              </ogc:Function>\n            </ogc:Function>\n            <ogc:Function name=\"parameter\">\n              <ogc:Literal>colorRamp</ogc:Literal>\n              <ogc:Function name=\"colormap\">\n                <ogc:Literal>rgb(255,0,0);rgb(0,0,255)</ogc:Literal>\n                <ogc:Function name=\"env\">\n                  <ogc:Literal>COLORSCALERANGE_MIN</ogc:Literal>\n                  <ogc:Function name=\"bandStats\">\n                    <ogc:Literal>0</ogc:Literal>\n                    <ogc:Literal>minimum</ogc:Literal>\n                  </ogc:Function>\n                </ogc:Function>\n                <ogc:Function name=\"env\">\n                  <ogc:Literal>COLORSCALERANGE_MAX</ogc:Literal>\n                  <ogc:Function name=\"bandStats\">\n                    <ogc:Literal>0</ogc:Literal>\n                    <ogc:Literal>maximum</ogc:Literal>\n                  </ogc:Function>\n                </ogc:Function>\n                <ogc:Function name=\"env\">\n                  <ogc:Literal>BELOWMINCOLOR</ogc:Literal>\n                  <ogc:Literal>rgba(0,0,0,0)</ogc:Literal>\n                </ogc:Function>\n                <ogc:Function name=\"env\">\n                  <ogc:Literal>ABOVEMAXCOLOR</ogc:Literal>\n                  <ogc:Literal>rgba(0,0,0,0)</ogc:Literal>\n                </ogc:Function>\n                <ogc:Function name=\"env\">\n                  <ogc:Literal>LOGSCALE</ogc:Literal>\n                  <ogc:Literal>false</ogc:Literal>\n                </ogc:Function>\n                <ogc:Function name=\"env\">\n                  <ogc:Literal>NUMCOLORBANDS</ogc:Literal>\n                  <ogc:Literal>254</ogc:Literal>\n                </ogc:Function>\n              </ogc:Function>\n            </ogc:Function>\n          </ogc:Function>\n        </sld:Transformation>\n        <sld:Rule>\n          <sld:RasterSymbolizer/>\n        </sld:Rule>\n      </sld:FeatureTypeStyle>\n    </sld:UserStyle>\n  </sld:NamedLayer>\n</sld:StyledLayerDescriptor>\n

                                                              The above explains a bit of how the palette is applied:

                                                              • By default a palette of 254 colors is generated between a min and max value, plus one color for anything below the minimum and another for anything above the maximum
                                                              • It is possible to pass the minimum and maximum values using the GetMap env parameter, if not provided, they are fetched from the configured band statistics (as found in the layer configuration)
                                                              • The overall opacity of the palette can be controlled (using a value between 0 and 1 to conform with the SLD opacity description)
                                                              • The scale can be either linear, or logarithmic

                                                              Editing the defaults for min/max scale range values in the GeoServer layer editor

                                                              The above parameters can all be used at will to control the palette generation using the typical environment variable approach. However, it's also possible to use ncWMS own extensions, which are adding direct parameters in the request. See the following section for details.

                                                              "},{"location":"community/ncwms/#ncwms-getmap-extensions","title":"ncWMS GetMap extensions","text":"

                                                              This module also adds a dynamic translator taking the ncWMS GetMap vendor parameters and mapping them to the dynamic palette expectations. In particular (copying the parameter description from the ncWMS manual, with GeoServer specific annotations):

                                                              • COLORSCALERANGE: Of the form min,max this is the scale range used for plotting the data (mapped to the COLORSCALERANGE_MIN and COLORSCALERANGE_MAX env vars)
                                                              • NUMCOLORBANDS: The number of discrete colours to plot the data. Must be between 2 and 250 (mapped to the NUMCOLORBANDS env variable)
                                                              • ABOVEMAXCOLOR: The colour to plot values which are above the maximum end of the scale range. Colours are of the form 0xRRGGBB or 0xAARRGGBB, and it also accepts \"transparent\" and \"extend\"
                                                              • BELOWMINCOLOR: The colour to plot values which are below the minimum end of the scale range. Colours are of the form 0xRRGGBB or 0xAARRGGBB, and it also accepts \"transparent\" and \"extend\"
                                                              • LOGSCALE: \"true\" or \"false\" - whether to plot data with a logarithmic scale
                                                              • OPACITY: The percentage opacity of the final output image as a number between 0 and 100 (maps to OPACITY env var by translating it to a number between 0 and 1)
                                                              • ANIMATION: \"true\" or \"false\" - whether to generate an animation. The ncWMS documentation states that TIME has to be of the form starttime/endtime, but currently TIME needs to be a list of discrete times instead. Animation requires using the \"image/gif\" as the response format (as the only format supporting animation)

                                                              Here are a few examples based on the \"ArcSample\" arcgrid sample layer, containing annual precipitation data. The one band provided by this layer has been configured with a default range of 0 to 6000.

                                                              • Default output with the \"redblue\" palette:

                                                                http://localhost:8080/geoserver/wms?STYLES=redblue&LAYERS=nurc%3AArc_Sample&FORMAT=image%2Fpng&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&SRS=EPSG%3A4326&BBOX=-180,-90,180,90&WIDTH=500&HEIGHT=250

                                                              • Adopting a logarithmic scale by adding &COLORSCALERANGE=1,6000&LOGSCALE=true (a logarithmic scale needs a positive minimum)

                                                              • Using just 5 colors in logarithmic mode by adding &COLORSCALERANGE=1,6000&LOGSCALE=true&NUMCOLORBANDS=5

                                                              • Limiting the range and specifying other colors above (gray) and below (yellow) by adding &COLORSCALERANGE=100,2000&BELOWMINCOLOR=0xFFFF00&ABOVEMAXCOLOR=0xAAAAAA

                                                              "},{"location":"community/ncwms/#ncwms-getcapabilities-extensions","title":"ncWMS GetCapabilities extensions","text":"

                                                              ncWMS allows users to filter the contents of a capabilities document by adding a &dataset=datasetName parameter to the request.

                                                              While GeoServer does not have a concept of dataset, the ncWMS extension allows to use the same parameter to filter on workspaces, layers and layer groups, by name.

                                                              For example:

                                                              • Getting everything in the \"topp\" workspace: http://localhost:8080/geoserver/ows?service=wms&version=1.3.0&request=GetCapabilities&dataset=topp
                                                              • Getting only the \"topp:states\" layer: http://localhost:8080/geoserver/ows?service=wms&version=1.3.0&request=GetCapabilities&dataset=topp:states
                                                              • Getting the \"tasmania\" layer group: http://localhost:8080/geoserver/ows?service=wms&version=1.3.0&request=GetCapabilities&dataset=tasmania
                                                              "},{"location":"community/ncwms/#ncwms-gettimeseries-operation","title":"ncWMS GetTimeSeries operation","text":"

                                                              ncWMS provides a GetTimeSeries operation, which can retrieve a time series of values on a certain point, using a syntax similar to the GetFeatureInfo operation. The time series can be retrieved as a chart in PNG or JPEG image, or as a CSV.

                                                              For example:

                                                              • Getting a time series as CSV: http://localhost:8080/geoserver/wms?SERVICE=WMS&VERSION=1.1.1&REQUEST=GetTimeSeries&FORMAT=image%2Fjpeg&TIME=2008-10-31T00:00:00.000Z/2008-11-01T00:00:00.000Z&QUERY_LAYERS=watertemp&STYLES&LAYERS=watertemp&INFO_FORMAT=text%2Fcsv&FEATURE_COUNT=50&X=50&Y=50&SRS=EPSG%3A4326&WIDTH=101&HEIGHT=101&BBOX=3.724365234375%2C40.81420898437501%2C5.943603515625%2C43.03344726562501
                                                              • Getting a time series as PNG: http://localhost:8080/geoserver/wms?SERVICE=WMS&VERSION=1.1.1&REQUEST=GetTimeSeries&FORMAT=image%2Fjpeg&TIME=2008-10-31T00:00:00.000Z/2008-11-01T00:00:00.000Z&QUERY_LAYERS=watertemp&STYLES&LAYERS=watertemp&INFO_FORMAT=image%2Fpng&FEATURE_COUNT=50&X=50&Y=50&SRS=EPSG%3A4326&WIDTH=101&HEIGHT=101&BBOX=3.724365234375%2C40.81420898437501%2C5.943603515625%2C43.03344726562501
                                                              • Getting a time series as JPG: http://localhost:8080/geoserver/wms?SERVICE=WMS&VERSION=1.1.1&REQUEST=GetTimeSeries&FORMAT=image%2Fjpeg&TIME=2008-10-31T00:00:00.000Z/2008-11-01T00:00:00.000Z&QUERY_LAYERS=watertemp&STYLES&LAYERS=watertemp&INFO_FORMAT=image%2Fjpg&FEATURE_COUNT=50&X=50&Y=50&SRS=EPSG%3A4326&WIDTH=101&HEIGHT=101&BBOX=3.724365234375%2C40.81420898437501%2C5.943603515625%2C43.03344726562501

                                                              The INFO_FORMAT accepts the following values: image/png, image/jpg and text/csv

                                                              The TIME parameter accepts a time range as defined for other operations in the WMS standard (see Annex D of the 06-042 Web Map Server Implementation Specification). Examples:

                                                              • TIME=2008-10-31T00:00:00.000Z/2008-11-01T00:00:00.000Z
                                                              • TIME=2008-10-31T00:00:00.000Z/2008-10-31T00:00:00.000Z

                                                              Since GeoServer 2.17, TIME parameter also supports 2 additional syntax even if not expressly supported by ncWMS specification:

                                                              1. A List of Times:
                                                                • Example: TIME=2014-01,2015-01,2016-01,2017-01,2018-01
                                                                • Example: TIME=2017-01-01T00:00:00Z,2017-02-01T00:00:00Z,2017-01-03T00:00:00Z
                                                              2. A periodic time within a range:
                                                                • Example: TIME=2015-01/2019-01/P1Y

                                                              ::: note ::: title Note :::

                                                              • Shortened time specifications in a list are parsed as time ranges by GeoServer. Therefore, a Time like 2014-01 will represent the whole month of January 2014, so a time range: 2014-01-01T00:00:00/2014-01-31T23:59:59.

                                                              • Months and Years expressed through a Period specification (as an instance P2M, P1Y) are considered made of 30 days and 365.25 days respectively. Therefore a periodic interval like 2000-04/2000-12/P1M will be parsed as the list of time instants starting from April 2000 through December 2000 with a period of 30 days:

                                                                • Apr 01 00:00:00 2000
                                                                • May 01 00:00:00 2000
                                                                • May 31 00:00:00 2000
                                                                • Jun 30 00:00:00 2000
                                                                • Jul 30 00:00:00 2000
                                                                • Aug 29 00:00:00 2000
                                                                • Sep 28 00:00:00 2000
                                                                • Oct 28 00:00:00 2000
                                                                • Nov 27 00:00:00 2000
                                                                • Dec 27 00:00:00 2000
                                                                • Therefore if your original dataset has an entry for the first day of each month, this request will only return 2 values: Apr 01 and May 01. In that case, you might consider enabling nearest match on Layer's time dimension. :::

                                                              Sample CSV output:

                                                              # Latitude: 40.396728515625\n# Longitude: -0.6921386718750019\nTime (UTC),Temperature (degrees)\n2014-01-01T00:00:00.000Z,0.4194810092449188\n2014-02-01T00:00:00.000Z,0.8373379707336426\n2014-03-01T00:00:00.000Z,3.1670899391174316\n2014-04-01T00:00:00.000Z,4.932330131530762\n

                                                              Sample chart output:

                                                              Note: Since GeoServer 2.17, nodata pixels will not be reported in the result chart. Moreover, entries in CSV list related to nodata pixels will report time but will have no pixel value reported, as in the example below for times 2014-02-01 and 2014-05-01:

                                                              # Latitude: 40.396728515625\n# Longitude: -0.6921386718750019\nTime (UTC),Temperature (degrees)\n2014-01-01T00:00:00.000Z,0.4194810092449188\n2014-02-01T00:00:00.000Z,\n2014-03-01T00:00:00.000Z,3.1670899391174316\n2014-04-01T00:00:00.000Z,4.932330131530762\n2014-05-01T00:00:00.000Z,\n2014-06-01T00:00:00.000Z,0.8373379707336426\n
                                                              "},{"location":"community/ncwms/#ncwms-extension-configuration","title":"ncWMS extension configuration","text":"

                                                              The ncWMS extension adds a panel at the bottom of the WMS administration page:

                                                              Option Description GetTimeSeries thread pool size Size of the thread pool used to compute GetTimeSeries results (parallelized to speed up computation) Maximum number of times in GetTimeSeries Maximum number of times tha GetTimeSeries will process. A user asking for more times will get back a service exception. The configuration is set the first time the admin hits save in the WMS page, even with a value of 0 (from that point on, GetTimeSeries will be independent on the WMS max dimensions setting)."},{"location":"community/netcdf-ghrsst/","title":"GHRSST NetCDF output","text":"

                                                              GHRSST is Group for High Resolution Sea Surface Temperature. Among its various activities it issued a specification on how sea surface temperature data should be organized in NetCDF files.

                                                              The NetCDF GHRSST module allows to generate complaint GHRSST files as WCS outputs, given a compliant GHRSST input.

                                                              "},{"location":"community/netcdf-ghrsst/#installation","title":"Installation","text":"

                                                              As a community module, the package needs to be downloaded from the nightly builds, picking the community folder of the corresponding GeoServer series (e.g. if working on the GeoServer main development branch nightly builds, pick the zip file form main/community-latest).

                                                              To install the module, unpack the zip file contents into GeoServer own WEB-INF/lib directory and restart GeoServer.

                                                              For the module to work, the NetCDF and NetCDF Output Format extensions must also be installed.

                                                              "},{"location":"community/netcdf-ghrsst/#input-preparation","title":"Input preparation","text":"

                                                              A GHRSST file contains multiple variables that are related with each other, and should be explored together in order to better understand the data. Thus, it is assumed that the source GHRSST file is published as a single coverage view holding all the variables as bands, retaining their native name (this is important for the plugin to work):

                                                              Setting up a coverage view with all variables as bands

                                                              A GHRSST output must also have a time, so the time dimension of this layer should be enabled (the output generation will fail with an error otherwise).

                                                              At the time of writing a coverage view requires the source bands to be of uniform data type, and the data sources might not be. In case setting up the view is not possible with the data available, a NCML file can be used to reprocess the source NetCDF into one that has bands with uniform data type. A downloadable example has been provided to facilitate setting up the view.

                                                              Download the reference NCML transformation

                                                              The GHRSST may also have to be setup in a image mosaic in order to provide a deep temporal layer that users can select data from. The image mosaic setup can be complex, so a downloadable example has been provided for it as well (will require some changes, at a minimum, fix the paths at the bottom of indexer.xml, and the database connection parameters in the two datastore properties files).

                                                              Download the sample mosaic configuration files

                                                              "},{"location":"community/netcdf-ghrsst/#configuring-ghrsst-output","title":"Configuring GHRSST output","text":"

                                                              The normal WCS NetCDF output will pick the first band of a coverage and generate a single variable NetCDF output. When the GHRSST plugin is installed, a new UI element will show up that enables GHRSST output:

                                                              Enabling GHRSST output mode

                                                              Notes about the configuration UI:

                                                              • Various normal configurations such as variable name, unit of measure, and data packing will be ignored (each variable in GHRSST has its own assigned data type and packing, as from specification)
                                                              • For the output to be compliant, enable copy of both global and per variable attributes
                                                              • The RDAC, Processing Level, SST Type and Product String have to be filled in order to generate a valid GHRSST file name in output. The user interface provides auto-complete with names picked from the specification, but others can be inputed as well.

                                                              For the output to generate correctly the coverage band names have to follow exactly the expected specification variable names (which comes naturally if the input is valid GHRSST), variable will be re-packed in output according to specification, so even if the inputs are all floats, the output will follow the expected data types.

                                                              Any extra coverage band not present in the specification will be copied from input to output un-modified.

                                                              "},{"location":"community/notification/","title":"Notification community module Plugin Documentation","text":"

                                                              The notification community module is meant to be a pluggable system to listen, summarize and notify events triggered by GeoServer data and configuration manipulation to some external source, in some agreed upon format.

                                                              The events of interest are:

                                                              1. Catalog configuration changes (insert/update/removal of layers, styles, workspaces, stores, groups and so on)
                                                              2. Data changes via WFS-T (anything that can affect the data precise bounding box)

                                                              The system is completely pluggable in terms of notification destinations, potential targets can be direct HTTP calls to external system, message queues, log files, email. The message format can also vary depending on the target and intended usage, both in terms of contents, e.g., it could be full of details or simply an indication of what changed, and encoding, e.g., xml, json, text, html.

                                                              "},{"location":"community/notification/#overall-architecture","title":"Overall architecture","text":"

                                                              The overall architecture is depicted in the following diagram:

                                                              The system basically generates a set of events, has a configuration to match them with a desired tool to send the message out (the processor). The sender can be conceived as a the combination of an \"encoder\" that generates the message payload and a \"sender\".

                                                              Each message is combined with its processor and send into a destination queue, where a thread pool picks the events and runs their processor. For some type of events, like catalog ones, the thread pool will have to be configured with just one thread to make sure the events are sent in the right order to the destinations.

                                                              "},{"location":"community/notification/#installing-the-extension","title":"Installing the extension","text":"
                                                              1. Download the Notification extension from the nightly GeoServer community module builds.
                                                              2. Download the Notification Common extension from the nightly GeoServer community module builds.
                                                              3. (optional) If you want use sender/encoder provided for GeoNode, download the Notification Geonode extension from the nightly GeoServer community module builds.
                                                              4. Place the JARs into the WEB-INF/lib directory of the GeoServer installation.
                                                              "},{"location":"community/notification/#usage","title":"Usage","text":"

                                                              The usage of the extensions is based on two components that defines its behavior and logic:

                                                              • A configuration file named notifier.xml that must be present on a \"notifier\" subfolder of Geoserver root data directory (if extensions found no one notifier.xml file under notifier folder, will create a new one with default values)
                                                              • A JAR that implements the specific logic of sender/encoder
                                                              "},{"location":"community/notification/#configuration-file","title":"Configuration file","text":"

                                                              The configuration file will be parsed by XStream framework to instantiate the right classes. An example of notifier.xml have the follow content:

                                                              <notificationConfiguration>\n<queueSize>1000</queueSize>\n  <notificator>\n    <messageFilter>type='Catalog'</messageFilter>\n    <queueSize>1000</queueSize>\n    <processorThreads>1</processorThreads>    \n    <genericProcessor>\n      <geonodeEncoder />\n      <fanoutSender>\n        <username>guest</username>\n        <password>guest</password>\n        <host>localhost</host>\n        <port>4432</port>\n        <virtualHost></virtualHost>\n        <exchangeName>testExchange</exchangeName>\n        <routingKey>testRouting</routingKey>\n      </fanoutSender>\n    </genericProcessor>\n  </notificator>\n  <notificator>\n  ...\n  </notificator>\n</notificationConfiguration>\n

                                                              notificationConfiguration -> queueSize = the size of queue that store all the notification messages.

                                                              notificationConfiguration -> notificator = is possible to have one or more notificator.

                                                              notificationConfiguration -> notificator -> messageFilter = the is a CQL filter, only notification message that satisfy this filter, will be processed by this notificator. Possible values are:

                                                              • type='Catalog'
                                                              • type='Data'

                                                              notificationConfiguration -> notificator -> queueSize = the size of queue to store the notification messages for specific notificator, only the notification that satisfy the CQL filter specified on <messageFilter> element will be pushed in this queue.

                                                              notificationConfiguration -> notificator -> processorThreads = number of threads that will be work to encode and send the notification messages. Note that for 'Catalog' type event, this will have to be valued as 1 to make sure the events are sent in the right order to the destinations.

                                                              notificationConfiguration -> notificator -> genericProcessor = configurations for the encoder and sender components

                                                              notificationConfiguration -> notificator -> geonodeEncoder = this is a placeholder tag that must match with the alias used to map the implementation class for encoder. Based on custom implementation, additional attributes or child tags can be provided.

                                                              Note

                                                              is mandatory that one and only one implementation of encoder match with each alias.

                                                              notificationConfiguration -> notificator -> fanoutSender = this is a placeholder tag that must match with the alias used to map the implementation class for sender. Based on custom implementation, additional attributes or child tags can be provided.

                                                              Note

                                                              is mandatory that one and only one implementation of sender match with each alias.

                                                              For the case of AMQP Fanout (RabbitMQ) based sender implementation, the additional parameters are:

                                                              • host : the IP/DNS to which the underlying TCP connection is made
                                                              • port : port number to which the underlying TCP connection is made
                                                              • virtualhost (optional) : a path which acts as a namespace
                                                              • username (optional) : if present is used for SASL exchange
                                                              • password (optional) : if present is used for SASL exchange
                                                              • exchangeName : the name of exchange to publish the message to
                                                              • routingKey : identify the queue to publish the message to (ignored by fanout type)
                                                              "},{"location":"community/notification/#sender-and-encoder-implementations","title":"Sender and encoder implementations","text":"

                                                              This plugin allow the pluggability of sender/encoder implementation, multiple implementation plugins are allowed.

                                                              The core notification extension will be resolve the implementations of the interfaces:

                                                              • org.geoserver.notification.common.NotificationEncoder
                                                              • org.geoserver.notification.common.NotificationProcessor
                                                              • org.geoserver.notification.common.NotificationXStreamInitializer

                                                              Based on the match between the tag names on configuration file (notifier.xml) and the aliases define in NotificationXStreamInitializer, the notification core will be use the right implementation of NotificationEncoder / NotificationProcessor.

                                                              An example of this implementation is provided by the Notification Geonode extension.

                                                              The minimal dependencies of this kind of plugin are (see pom.xml of Notification Geonode extension):

                                                              • gs-notification-common
                                                              • gs-main

                                                              The plugin must be extends/implements almost the three classes/interfaces:

                                                              NotificationXStreamDefaultInitializer: is a utility implementation of NotificationXStreamInitializer to define the match between NotificationEncoder / NotificationProcessor and configuration aliases:

                                                              • getEncoderName : this method must be return the alias for encoder
                                                              • getSenderName : this method must be return the alias for sender
                                                              • getEncoderClass : this method must be return the class for encoder
                                                              • getSenderClass : this method must be return the class for sender
                                                              "},{"location":"community/oauth2/","title":"Authentication with OAuth2","text":"

                                                              This tutorial introduces GeoServer OAuth2 support and walks through the process of setting up authentication against an OAuth2 provider. It is recommended that the Authentication chain section be read before proceeding.

                                                              • Installing an OAuth2 Protocol
                                                              • Configure the Google authentication provider
                                                              • Configure the GeoServer OAuth2 filter
                                                              • OpenID connect authentication
                                                              "},{"location":"community/oauth2/google/","title":"Configure the Google authentication provider","text":"

                                                              The first thing to do is to configure the OAuth2 Provider and obtain Client ID and Client Secret keys.

                                                              1. Obtain OAuth 2.0 credentials from the Google API Console.

                                                                Visit the Google API Console to obtain OAuth 2.0 credentials such as a client ID and client secret that are known to both Google and your application. The set of values varies based on what type of application you are building. For example, a JavaScript application does not require a secret, but a web server application does.

                                                                • Login with a valid Google Account

                                                                • Click on APIs & Services

                                                                • Click on Credentials

                                                                  Note

                                                                  The first time you land here, Google will ask to create at least one project

                                                                  For the purpose of this tutorial we will create a sample project. You are free to create other projects or update existing ones through the Google API Console later.

                                                                  If no Credentials are present, you will be asked to create new one.

                                                              2. Select an existing (or create a new one) OAuth Client ID

                                                              3. Configure a new Web application

                                                                • If it is the first time you create an OAuth Client ID, you will be asked to create a new consent screen

                                                                • Customize the consent screen

                                                                  Warning

                                                                  This step is mandatory only if it's the first time you are defining a Web application on a new project. If you don't have an organization, you can only choose type External from the screen below.

                                                                • Fill the form below and click on save and continue untill all tabs are filled.

                                                                  Note

                                                                  It can be edited and updated also later (see last point of this section below)

                                                                • From the credentials page, click on CREATE CREDENTIALS> OAuth Client ID and select Application type -> Web application

                                                                  Warning

                                                                  This step is mandatory only if it's the first time you are defining a Web application on a new project.

                                                                • Add a Name and the Authorized redirect URIs like shown here below.

                                                                  Note

                                                                  This sample creates a client working on the default local URL http://localhost:8080/geoserver. Of course this will work only on a local instance and can't be used for a production system.

                                                                  However it is possible to add as many Authorized redirect URIs you need to a new Web application.

                                                                  It is also possible to create many Client credentials with customised consent screen and Web application, depending on your specific needs. Every public GeoServer instance (or cluster of GeoServer belonging to a specific project) should have its own specific Client credentials.

                                                                  Note

                                                                  Always add two entries for each URI. One without the ending / and another one with it.

                                                              4. Click on Create and take note of the Client ID and the Client Secret.

                                                                At the end of the procedure Google will show-up a small dialog box with the Client ID and the Client Secret. That info can be always accessed and updated from the Google API Console

                                                              5. Optionally customize the OAuth consent screen.

                                                                At any time it is possible to update and customize the OAuth consent screen. You can put here your logo, app name, ToS and so on.

                                                              "},{"location":"community/oauth2/installing/","title":"Installing an OAuth2 Protocol","text":"

                                                              This module allows GeoServer to authenticate against the OAuth2 Protocol.

                                                              In order to let the module work, it is mandatory to setup and configure an oauth2-xxxx-extension:

                                                              • sec-oauth2-google
                                                              • sec-oauth2-geonode
                                                              • sec-oauth2-github
                                                              • sec-oauth2-openid-connect

                                                              Each ZIP files contains the oauth2-core extension, and the jars and the jars for the provider.

                                                              The first one contains the necessary dependencies of the OAuth2 core module. This module contains the GeoServer security filter, the base classes for the OAuth2 Token services and the GeoServer GUI panel.

                                                              The second one provides the OAuth2 implementation for each provider. Since in almost all cases the only difference between OAuth2 Providers are the endpoint URIs and the client connection information (not only the keys -public and secret - but also the user profile representations). In order to allow GeoServer to connect to a specific OAuth2 provider it is sufficient to install the OAuth2 Core module plugin (and correctly configure the parameters through the GeoServer GUI - see next section for the details) and the concrete implementation of the OAuth2 REST token template and resource details.

                                                              Currently this module is shipped with a sample extension for Google OAuth2 Provider. This is a particular case since the Google JWT response is not standard and therefore we had to define and inject also a GoogleUserAuthenticationConverter taking the Google REST response against a valid access_token and converting it to an OAuth2 standard one.

                                                              Other than this the most interesting part is the implementation of the base class GeoServerOAuth2SecurityConfiguration.

                                                              The latter contains the Google implementation of the OAuth2RestTemplate.

                                                              In the next section we will see how to install and configure the OAuth2 security filter on GeoServer authenticating against Google OAuth2 Provider.

                                                              "},{"location":"community/oauth2/oauth2/","title":"Configure the GeoServer OAuth2 filter","text":"
                                                              1. Start GeoServer and login to the web admin interface as the admin user.

                                                              2. Click the Authentication link located under the Security section of the navigation sidebar.

                                                              3. Scroll down to the Authentication Filters panel and click the Add new link.

                                                              4. Click the OAuth2 link.

                                                              5. Fill in the fields of the settings form as follows:

                                                                The default values provided with the plugin are valid for the Google OAuth2 Provider and are the following:

                                                                \"Enable Redirect Authentication EntryPoint\" = False\n\"Access Token URI\" = https://accounts.google.com/o/oauth2/token\n\"User Authorization URI\" = https://accounts.google.com/o/oauth2/auth\n\"Redirect URI\" = http://localhost:8080/geoserver\n\"Check Token Endpoint URL\" = https://www.googleapis.com/oauth2/v1/tokeninfo\n\"Logout URI\" = https://accounts.google.com/logout\n\"Scopes\" = https://www.googleapis.com/auth/userinfo.email,https://www.googleapis.com/auth/userinfo.profile\n

                                                                Note

                                                                1. Client ID and Client Secret are the ones Google provided
                                                                2. Choose a Role Service able to recognize user emails as IDs. By default a connected user will have ROLE_USER role

                                                                Warning

                                                                A few words on the Enable Redirect Authentication EntryPoint option

                                                                This option allows you to decide whether or not to force automatic redirection to OAuth2 Access Token URI or not for authentication.

                                                                What does that mean?

                                                                • Enable Redirect Authentication EntryPoint = True

                                                                  If not already authenticated (or no valid Access Token is provided in the query string), this option will force a redirection to the OAuth2 Provider Login page.

                                                                  This may cause unwanted behavior since it will override every other explicit login method like form. In other words if the filter is applied for instance to the web endpoint, it won't be possible to access to the GeoServer Admin GUI using the standard login method via browser.

                                                                • Enable Redirect Authentication EntryPoint = False

                                                                  In order to avoid the above issue, by disabling this option you will be forced to use an explicit Authentication Endpoint to login via the OAuth2 Provider login page.

                                                                  If not already authenticated (or no valid Access Token is provided in the query string), you must authenticate through the following URLs:

                                                                  1. GeoServer OAuth2 Authorization Endpoint; http://<host:port>/geoserver/j_spring_oauth2_login

                                                                  2. OAuth2 Provider Explicit User Authorization Endpoint; this must be adapted for your specific OAuth2 Provider, the protocol stated that it should be

                                                                    https://<USER_AUTHORIZATION_URI>?scope=<SCOPES>&response_type=code&redirect_uri=<REDIRECT_URI>&client_id=<CLIENT_ID>\n

                                                                    For Google OAuth2 Provider is:

                                                                    https://accounts.google.com/o/oauth2/auth?scope%3Dhttps://www.googleapis.com/auth/userinfo.email%2Bhttps://www.googleapis.com/auth/userinfo.profile%26response_type%3Dcode%26redirect_uri%3D<REDIRECT_URI>%26client_id%3D<CLIENT_ID>\n
                                                              6. Update the filter chains by adding the new OAuth2 filter.

                                                                Once everything has been configured you should be able to see the new oauth2 filter available among the Authentication Filters list

                                                                Through this it will be always possible to modify / update the filter options, or create more of them.

                                                                The next step is to add the filter to the Filter Chains you want to protect with OAuth2 also

                                                              7. Select the OAuth2 Filter for each filter chain you want to protect with OAuth2.

                                                                If you need to protect all the GeoServer services and the GeoServer Admin GUI too with OAuth2, you need to add the oauth2 filter to all the following chains

                                                                • web
                                                                • rest
                                                                • gwc
                                                                • default

                                                                The order of the authentication filters depends basically on which method you would like GeoServer to try first.

                                                                Note

                                                                During the authentication process, the authentication filters of a Filter Chain are executed serially until one succeed (for more details please see the section Authentication chain)

                                                                Warning

                                                                If Enable Redirect Authentication EntryPoint = True for OAuth2 Filter, the web chain won't be able to login through the form method.

                                                                Note

                                                                Remember that the anonymous filter must be always the last one.

                                                              8. Save.

                                                              It's now possible to test the authentication:

                                                              1. Navigate to the GeoServer home page and log out of the admin account.

                                                              2. Try to login again, you should be able now to see the external Google login form.

                                                              "},{"location":"community/oauth2/oidc/","title":"OpenID connect authentication","text":"

                                                              The OAuth2 OpenID Connect (OIDC) authentication is working in a way quite similar to Google (and GitHub) authentications, the only difference is that the authentication page cannot propose default values for the various endpoints, which have to be configured manually.

                                                              In case the web login will not be used, the client ID and client secret are not actually needed, and can be filled with two made up values (the validation just checks they are present, but they will be used only in the \"authorisation flow\", but not when doing OGC requests where the client is supposed to have autonomously retrieved a valid bearer token).

                                                              The configuration GUI supports OpenID Discovery documents. If the server supports them it's sufficient to provide the path to the document, or to the authentication service root, and the GUI will auto-fill itself based on the document contents:

                                                              The UI allow to set also the Post Logout Redirect URI which will be used to populate the post_logout_redirect_uri request param, when doing the global logout from the GeoServer UI. The OpenId provider will use the URI to redirect to the desired app page.

                                                              In addition, the OpenID connect authentication is able to extract the user roles from either the ID token or the Access Token:

                                                              The chosen attribute must be present in either the Access Token or in the Id token, and be either a string or an array of strings.

                                                              From UI it is also possible to set the Response Mode value. The field can be kept empty but it is needed when the OpenId server used as Identity Provider doesn't send by default the authorization code as a query string (that is mandatory in order to allow GeoServer and OpenId integration to work properly).

                                                              Finally the admin can allow the sending of the client_secret during an access_token request trough the Send Client Secret in Token Request. Some OpenId implementation requires it for the Authorization Code flow when the client app is a confidential client and can safely store the client_secret.

                                                              "},{"location":"community/oauth2/oidc/#logging-oauth2-activity","title":"Logging OAuth2 Activity","text":"

                                                              The plugin includes an OIDC_LOGGING profile which is installed on startup. This logging profile quiets most GeoServer logging activity, while enabling trace logging for OAuth2 functionality.

                                                              The module also includes an additional connection setting to include the token details as additinoal log messages. This is intended to assist in troubleshooting durring development and initial setup.

                                                              Log sensitive information

                                                              This setting can obviously used to access sensitive information and you are advised clear logs after use.

                                                              To setup for troubleshooting OIDC activity:

                                                              1. Navigate to Settings \u2192 Global

                                                              2. Select the logging profile OIDC_LOGGING

                                                              3. Navigate Security \u2192 Authentication

                                                              4. Setup your OAuth2 OpenID Connect configuration with Log Sensitive Information (do not use in production) checked

                                                              5. With these settings each individual steps of the OAuth2 authentication is shown. The logging senstive information setting logs access token and id token (the content of these token may be decoded using https://jwt.io ).

                                                                DEBUG  [security.oauth2] - OIDC: - CLIENT_SECRET: squirrel\nDEBUG  [security.oauth2] - OIDC: received a CODE from Identity Provider - handing it in for ID/Access Token\nDEBUG  [security.oauth2] - OIDC: CODE=...\nDEBUG  [security.oauth2] - OIDC: Identity Provider returned Token, type=Bearer\nDEBUG  [security.oauth2] - OIDC: SCOPES=openid geocat\nDEBUG  [security.oauth2] - OIDC: ACCESS TOKEN: .... \nDEBUG  [security.oauth2] - OIDC: ID  TOKEN: ... \nDEBUG  [security.oauth2] - OIDC: Getting Roles from UserGroupService, location=null\nDEBUG  [security.oauth2] - OIDC: Geoserver Roles: ADMIN\nDEBUG  [security.oauth2] - OIDC: Geoserver Roles: ROLE_ADMINISTRATOR\n
                                                              "},{"location":"community/oauth2/oidc/#openid-connect-with-attached-access-bearer-tokens","title":"OpenID Connect With Attached Access Bearer Tokens","text":"

                                                              The OpenID Connect plugin allows the use of Attached Bearer Access Tokens. This is typically used by automated (i.e. desktop or external Web Service) to access the Geoserver REST API.

                                                              Bearer Tokens

                                                              The setup process is as follows:

                                                              1. Setup your OAuth2 OpenID Connect configuration as normal
                                                              2. On the OpenID Connect configuration screen (bottom), makes sure \"Allow Attached Bearer Tokens\" is checked
                                                              3. You can not use ID Tokens as a Role Source for the attached Bearer Tokens (see below)

                                                              To Use:

                                                              1. Obtain an Access Token from the underlying IDP
                                                              2. Attach the access token to your HTTP request headers

                                                              Authorization: Bearer <token>

                                                              The Access Token (JWT) is validated;

                                                              1. The Access Token is used to get the \"userinfo\" endpoint. The underlying IDP will verify the token (i.e. signature and expiry)
                                                              2. The Audience of the Token is checked that it contains the GeoServer configured Client Id. This make sure an Access Token for another application is not being inappropriately reused in GeoServer (cf. AudienceAccessTokenValidator.java).
                                                              3. The Subject of the userinfo and Access Token are verified to be about the same person. The OpenID specification recommends checking this (cf. SubjectTokenValidator.java).

                                                              For KeyCloak, consider using the \"userinfo endpoint\" role source and configure Keycloak to put groups in the \"userinfo.\"

                                                              For Azure AD, configure Azure to allow access to the MS Graph API (memberOf) and use the \"Microsoft Graph API (Azure AD)\" role source.

                                                              To configure Azure AD for \"memberOf\" (\"GroupMember.Read.All\" permission) access;

                                                              1. Go to your application in Azure AD (in the portal)
                                                              2. On the left, go to \"API permissions\"
                                                              3. Click \"Add a permission\"
                                                              4. press \"Microsoft Graph\"
                                                              5. press \"Delegated permission\"
                                                              6. Scroll down to \"GroupMember\"
                                                              7. Choose \"GroupMemeber.Read.All\"
                                                              8. Press \"Add permission\"
                                                              9. On the API Permission screen, press the \"Grant admin consent for ...\" text

                                                              This has been tested with KeyCloak (with groups in the userinfo endpoint response), and with MS Azure AD (with the groups from the GraphAPI). This should work with other IDPs - however, make sure that the Subject and Audience token verification works with their tokens.

                                                              If you do not need Bearer Token functionality, it is recommended to turn this off.

                                                              "},{"location":"community/oauth2/oidc/#proof-key-of-code-exchange-pkce","title":"Proof Key of Code Exchange (PKCE)","text":"

                                                              The OpenID Connect plugin allows the use of Proof Key of Code Exchange (PKCE).

                                                              Proof Key of Code Echange

                                                              The setup process is as follows:

                                                              1. Setup your OAuth2 OpenID Connect configuration as normal
                                                              2. On the OpenID Connect configuration screen (bottom), makes sure \"Use PKCE\" is checked

                                                              To prevent client side refequest forgery:

                                                              • Step 1: GeoServer will include a code_challenge during initial authorization code request

                                                              • Step 2: GeoServer will include a code_verifer during the access token request.

                                                                The authentication server will confirm that code_verifier hash matches the initial code_challenge in order the confirm the client is the same as in Step 1.

                                                              Log output of this exchange is as follows:

                                                              DEBUG  [oauth2.pkce] - Generate code_verifier: yQat4Y.....\nDEBUG  [oauth2.pkce] - CODE_CHALLENGE: 5HiD...\nDEBUG  [oauth2.pkce] - CODE_CHALLENGE_METHOD: S256\nDEBUG  [oauth2.pkce] - CLIENT_SECRET: squirrel\nDEBUG  [oauth2.pkce] - CODE_VERIFIER: yQat4Y...\n

                                                              Reference:

                                                              • rfc7636 Proof Key for Code Exchange by OAuth Public Clients
                                                              "},{"location":"community/oauth2/oidc/#json-web-key-set-uri","title":"JSON Web Key set URI","text":"

                                                              The JSON Web Key set URI provides the location of a document of public keys that can be used to check the signature of the provided accessToken.

                                                              Optional: It is no longer required to use Check Token Endpoint URL - if you leave that field blank you may rely only on the JSON Web Key set URI signature check. When use in this manner roles cannot be extracted from access token.

                                                              "},{"location":"community/oauth2/oidc/#azure-ad-and-adfs-setup","title":"Azure AD and ADFS setup","text":"

                                                              To make the OpenIdConnect filter to work properly with an Azure AD or ADFS server via the OpenId protocol, the user must set, in addition to the other configuration parameters, the Response Mode to query (otherwise by default ADFS will return a url fragment) and check the checkbox Send Client Secret in Token Request (the client_secret is mandatory in token request according to the Microsoft documentation).

                                                              "},{"location":"community/oauth2/oidc/#ssl-trusted-certificates","title":"SSL Trusted Certificates","text":"

                                                              When using a custom Keystore or trying to access a non-trusted or self-signed SSL-protected OAuth2 Provider from a non-SSH connection, you will need to add the certificates to the JVM Keystore.

                                                              In order to do this you can follow the next steps:

                                                              In this example we are going to

                                                              1. Retrieve SSL certificates from Google domains:

                                                                \"Access Token URI\" = https://accounts.google.com/o/oauth2/token therefore we need to trust https://accounts.google.com or (accounts.google.com:443) \"Check Token Endpoint URL\" = https://www.googleapis.com/oauth2/v1/tokeninfo therefore we need to trust https://www.googleapis.com or (www.googleapis.com:443)

                                                                ::: note ::: title Note :::

                                                                You will need to get and trust certificates from every different HTTPS URL used on OAuth2 Endpoints. :::

                                                              2. Store SSL Certificates on local hard disk

                                                              3. Add SSL Certificates to the Java Keystore

                                                              4. Enable the JVM to check for SSL Certificates from the Keystore

                                                              1. Retrieve the SSL Certificates from Google domains

                                                                Use the openssl command in order to dump the certificate

                                                                For https://accounts.google.com

                                                                openssl s_client -connect accounts.google.com:443\n

                                                                And for https://www.googleapis.com

                                                                openssl s_client -connect www.googleapis.com:443\n

                                                              2. Store SSL Certificates on local hard disk

                                                                Copy-and-paste the two sections -BEGIN CERTIFICATE-, -END CERTIFICATE- and save them into two different .cert files

                                                                Note

                                                                .cert file are plain text files containing the ASCII characters included on the -BEGIN CERTIFICATE-, -END CERTIFICATE- sections

                                                                google.cert (or whatever name you want with .cert extension)

                                                                google-apis.cert (or whatever name you want with .cert extension)

                                                              3. Add SSL Certificates to the Java Keystore

                                                                You can use the Java command keytool like this

                                                                google.cert (or whatever name you want with .cert extension)

                                                                keytool -import -noprompt -trustcacerts -alias google -file google.cert -keystore ${KEYSTOREFILE} -storepass ${KEYSTOREPASS}\n

                                                                google-apis.cert (or whatever name you want with .cert extension)

                                                                keytool -import -noprompt -trustcacerts -alias google-apis -file google-apis.cert -keystore ${KEYSTOREFILE} -storepass ${KEYSTOREPASS}\n

                                                                or, alternatively, you can use some graphic tool which helps you managing the SSL Certificates and Keystores, like Portecle

                                                                java -jar c:\\apps\\portecle-1.9\\portecle.jar\n

                                                              4. Enable the JVM to check for SSL Certificates from the Keystore

                                                                In order to do this, you need to pass a JAVA_OPTION to your JVM:

                                                                -Djavax.net.ssl.trustStore=F:\\tmp\\keystore.key\n
                                                              5. Restart your server

                                                              Note

                                                              Here below you can find a bash script which simplifies the Keystore SSL Certificates importing. Use it at your convenience.

                                                              HOST=myhost.example.com\nPORT=443\nKEYSTOREFILE=dest_keystore\nKEYSTOREPASS=changeme\n\n# get the SSL certificate\nopenssl s_client -connect ${HOST}:${PORT} </dev/null \\\n    | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > ${HOST}.cert\n\n# create a keystore and import certificate\nkeytool -import -noprompt -trustcacerts \\\n    -alias ${HOST} -file ${HOST}.cert \\\n    -keystore ${KEYSTOREFILE} -storepass ${KEYSTOREPASS}\n\n# verify we've got it.\nkeytool -list -v -keystore ${KEYSTOREFILE} -storepass ${KEYSTOREPASS} -alias ${HOST}\n
                                                              "},{"location":"community/ogc-api/","title":"OGC API modules","text":"

                                                              This plugin includes implementation of a set of OGC API service implementations

                                                              • Configuring the GeoServer OGC API module
                                                              • OGC API - Features
                                                              • OGC API - Tiles
                                                              • OGC API - Maps
                                                              • OGC API - Coverages
                                                              • OGC API - Styles
                                                              • OGC API - Tiled features demonstration
                                                              • OGC Testbed Experiments

                                                              Warning

                                                              The OGC API services are still in heavy development, most of the specs and extensions are still in draft form and their behavior are subject to change in the coming months/years.

                                                              How to help

                                                              The modules are still in their infancy, there is a set of activities that could help their development:

                                                              • Implementation of additional draft API services, such as the Maps API, the Coverages API, the Records API and the Process API.
                                                              • Implementation of new draft extensions not yet covered, like the OGC Features API Transaction extension.
                                                              • Improvement of the HTML representation of resources, both in terms of looks and functionality (the specification makes no mandate for these pages, so they may be implemented as we see fit).
                                                              • Testing and improvement of the OpenAPI documents generated by each service, with particular focus on automatic generation of clients.
                                                              • General testing, reporting and bug fixing.

                                                              Check documentation pages for \"implementation status\" outlining present state of development.

                                                              "},{"location":"community/ogc-api/configure/","title":"Configuring the GeoServer OGC API module","text":"

                                                              The OGC API modules provide additional services along side the existing Open Web Services (OWS).

                                                              "},{"location":"community/ogc-api/configure/#service","title":"Service","text":"

                                                              The OGC API modules primarily use the same configurations as their equivalent OWS services. So, for example, setting the WFS limited SRS list will also limit the SRS list for OGC API - Features.

                                                              In addition, the OGC API modules will have some unique configuration options.

                                                              "},{"location":"community/ogc-api/configure/#security","title":"Security","text":"
                                                              • Data security: Data security is managed independently of web service. The same data security restrictions placed on a workspace or layer content are enforced for both OWS services and OGC API web services

                                                              • Service security: OGC API web services are managed directly in Security > Services page. New access rules can be defined for OGC API services.

                                                                Service rule for OGC API Features getLandingPage

                                                              "},{"location":"community/ogc-api/configure/#collections","title":"Collections","text":"

                                                              OGCAPI web services provides a collections resource describing the published content.

                                                              As an example OGC API - Features collections lists:

                                                              • links: Links and metadata
                                                              • collections: List of individual collections available
                                                              • crs: List of coordinate reference systems defined by WFS settings
                                                              "},{"location":"community/ogc-api/configure/#custom-links-for-the-collections-resource","title":"Custom links for the \"collections\" resource","text":"

                                                              The collections resource can have a number of additional links, beyond the basic ones that the service code already includes. Navigate to *Settings > Global``. The links are configured under heading*OGC API Settings.

                                                              Links used to indicate global Creative Commons license

                                                              Link editor column description:

                                                              • rel: the link relation type, as per the OGC API - Features specification
                                                              • Mime type: the mime type for the resource found following the link
                                                              • URL: the link URL
                                                              • Title: the link title (optional)
                                                              • Service: the service for which the link is valid (optional, defaults to all)

                                                              Common links relationships that could be added for the collections resource are:

                                                              • enclosure, in case there is a package delivering all the collections (e.g. a GeoPackage, a ZIP full of shapefiles).
                                                              • describedBy, in case there is a document describing all the collections (e.g. a JSON or XML schema).
                                                              • license, if all collection data is under the same license.

                                                              Example from OGC API - Features service (http://localhost:8080/geoserver/ogc/features/v1/collections/?f=application%2Fjson):

                                                              {\n  \"href\": \"https://creativecommons.org/licenses/by/3.0/\",\n  \"rel\": \"license\",\n  \"type\": \"text/html\",\n  \"title\": \"Creative Commons - Attribution\"\n}\n
                                                              "},{"location":"community/ogc-api/configure/#custom-links-for-workspace-collections","title":"Custom links for workspace collections","text":"

                                                              Additional custom collections links can also be defined for an individual workspace. Navigate to *Workspaces > Edit Workspace``. Links are configured on the*Basic Info tab.

                                                              Links used to indicate public domain license for ne workspace

                                                              In this example the license is changed to reflect the natural earth terms of use (overriding the license defined in global settings).

                                                              Example from workspace OGC API - Features service ( http://localhost:8080/geoserver/ne/ogc/features/v1/collections/?f=application%2Fjson):

                                                              {\n  \"href\": \"https://www.naturalearthdata.com/about/terms-of-use/\",\n  \"rel\": \"license\",\n  \"type\": \"text/html\",\n  \"title\": \"Public Domain\"\n}\n
                                                              "},{"location":"community/ogc-api/configure/#single-collection","title":"Single collection","text":"

                                                              Each GeoServer layer is published is represented in OGC API as a single collection.

                                                              As an example OGC API - Features collections lists:

                                                              • id: Layer name
                                                              • title: Layer title
                                                              • description: Layer abstract
                                                              • extent: Layer bounds
                                                              • links: Links to access content and metadata
                                                              • crs
                                                              • storageCrs
                                                              "},{"location":"community/ogc-api/configure/#custom-links-for-single-collection","title":"Custom links for single collection","text":"

                                                              Additional custom links can be provided for an individual layer. Use the Layer Editor *Publishing`` tab, and locate the heading for*OGC API.

                                                              Links used to define enclosure download for ne:counteries layer

                                                              The relationships are the same as for the collections resource, but used in case there is anything that is specific to the collection (e.g., the schema for the single collection). In addition, other relations can be specified, like the tag relation, to link to the eventual INSPIRE feature concept dictionary entry.

                                                              Example from workspace ne:counteries collection providing enclosure for download:

                                                              {\n  \"href\": \"https://www.naturalearthdata.com/http//www.naturalearthdata.com/download/10m/cultural/ne_10m_admin_0_countries.zip\",\n  \"rel\": \"enclosure\",\n  \"type\": \"application/zip\",\n  \"title\": \"ne_10m_admin_0_countries.zip\"\n}\n
                                                              "},{"location":"community/ogc-api/testbed/","title":"OGC Testbed Experiments","text":"

                                                              The following modules are part of the OGC Testbed experiments.

                                                              "},{"location":"community/ogc-api/testbed/#images-and-changesets","title":"Images and Changesets","text":"

                                                              A couple of extra API, images and changesets, based on engineering reports of Testbed 15, allowing to update a image mosaic and get a list of tiles affected by the change.

                                                              To install these modules:

                                                              1. Download the OGC API nightly GeoServer community module from ogcapi-images.

                                                                Warning

                                                                Verify that the version number in the filename corresponds to the version of GeoServer you are running (for example geoserver- 2.24.2-ogcapi-images-plugin.zip above).

                                                              2. Extract the contents of the archive into the WEB-INF/lib directory of the GeoServer installation.

                                                              3. On restart the services are listed at http://localhost:8080/geoserver

                                                              "},{"location":"community/ogc-api/testbed/#dggs","title":"DGGS","text":"

                                                              The DGGS functionality exposes data structured as DGGS, based on either H2 or rHealPix, based on engineering reports of Testbed 18.

                                                              To make full usage of the DGGS functionality, a ClickHouse installation is also needed.

                                                              To install these modules:

                                                              1. Download the OGC API nightly GeoServer community module from ogcapi-dggs.

                                                                Warning

                                                                Verify that the version number in the filename corresponds to the version of GeoServer you are running (for example geoserver- 2.24.2-ogcapi-dggs-plugin.zip above).

                                                              2. Extract the contents of the archive into the WEB-INF/lib directory of the GeoServer installation.

                                                              3. On restart the services are listed at http://localhost:8080/geoserver

                                                              "},{"location":"community/ogc-api/coverages/","title":"OGC API - Coverages","text":"

                                                              A OGC API - Coverages based on an earlier specification draft, delivering partial functionality:

                                                              • Collection listing
                                                              • Download in the same formats supported by WCS
                                                              • Spatial and temporal subsetting
                                                              • Mosaic index filtering (GeoServer extension)
                                                              • Domain set description in JSON

                                                              Missing functionality at the time of writing, and known issues:

                                                              • Full coverage JSON support
                                                              • Scaling
                                                              • CRS transformation
                                                              "},{"location":"community/ogc-api/coverages/#ogc-api-coverages-implementation-status","title":"OGC API - Coverages Implementation status","text":"OGC API - Coverages Version Implementation status Part 1: Core Draft Implementation based on early specification draft, not yet updated to final version"},{"location":"community/ogc-api/coverages/#installing-the-geoserver-ogc-api-coverages-module","title":"Installing the GeoServer OGC API - Coverages module","text":"
                                                              1. Download the OGC API nightly GeoServer community module from ogcapi-coverages.

                                                                Warning

                                                                Verify that the version number in the filename corresponds to the version of GeoServer you are running (for example geoserver- 2.24.2-ogcapi-coverages-plugin.zip above).

                                                              2. Extract the contents of the archive into the WEB-INF/lib directory of the GeoServer installation.

                                                              3. On restart the services are listed at http://localhost:8080/geoserver

                                                              "},{"location":"community/ogc-api/coverages/#configuration-of-ogc-api-covearges-module","title":"Configuration of OGC API - Covearges module","text":"

                                                              The module is based on the GeoServer WCS one, follows the same configuration and exposes the same coverages.

                                                              "},{"location":"community/ogc-api/features/","title":"OGC API - Features","text":"

                                                              An OGC Features API publishing feature data using an OpenAPI web service.

                                                              "},{"location":"community/ogc-api/features/#features-implementation-status","title":"Features Implementation status","text":"OGC API - Features Version Implementation status Part 1: Core 1.0.0 Passes compliance tests Part 2: Coordinate Systems by Reference 1.0.0 Passes compliance tests Part 3: Filtering Draft Draft implemented (mind, the draft does not include a filtering language) Part 4: Create, Replace, Update and Delete Draft Not implemented (volunteers/sponsoring wanted) Common Query Language (CQL2) Draft Implements an earlier draft for for both text and JSON encodings. To be updated. Part n: Query by IDs Proposal Proposal implemented, but syntax and semantic is subject to change in a future release. Thus said, usage should be carefully considered."},{"location":"community/ogc-api/features/#installing-the-geoserver-ogc-api-features-module","title":"Installing the GeoServer OGC API Features module","text":"
                                                              1. Download the OGC API nightly GeoServer community module from ogcapi-features.

                                                                Warning

                                                                Verify that the version number in the filename corresponds to the version of GeoServer you are running (for example geoserver- 2.24.2-ogcapi-features-plugin.zip above).

                                                              2. Extract the contents of the archive into the WEB-INF/lib directory of the GeoServer installation.

                                                              3. On restart the services are listed at http://localhost:8080/geoserver

                                                              "},{"location":"community/ogc-api/features/#use-of-ogc-api-features-service","title":"Use of OGC API - Features service","text":"

                                                              The OGC API Features Service is accessed via the FEATURES version 1.0 link on the home page.

                                                              "},{"location":"community/ogc-api/features/#capabilities","title":"Capabilities","text":"

                                                              The service is self described using:

                                                              • html: A collection of web pages, with links for navigation between content (and that can be indexed by search engines for discoverability).

                                                                OGC API Features service

                                                              • application/json: A collection of json documents, with reference between each document for programmatic access by web developers.

                                                                {\n  \"title\": \"GeoServer Web Feature Service\",\n  \"description\": \"This is the reference implementation of WFS 1.0.0 and WFS 1.1.0, supports all WFS operations including Transaction.\",\n  \"links\": [\n    {\n      \"href\": \"http://localhost:8080/geoserver/ogc/features/?f=application%2Fx-yaml\",\n      \"rel\": \"alternate\",\n      \"type\": \"application/x-yaml\",\n      \"title\": \"This document as application/x-yaml\"\n    },\n    {\n      \"href\": \"http://localhost:8080/geoserver/ogc/features/?f=application%2Fjson\",\n      \"rel\": \"self\",\n      \"type\": \"application/json\",\n      \"title\": \"This document\"\n    },\n    {\n      \"href\": \"http://localhost:8080/geoserver/ogc/features/?f=text%2Fhtml\",\n      \"rel\": \"alternate\",\n      \"type\": \"text/html\",\n      \"title\": \"This document as text/html\"\n    }\n
                                                              • application/x-yaml: A collection of yaml documents, with references between each document for programmatic access.

                                                                title: GeoServer Web Feature Service\ndescription: This is the reference implementation of WFS 1.0.0 and WFS 1.1.0, supports\n  all WFS operations including Transaction.\nlinks:\n- href: http://localhost:8080/geoserver/ogc/features/?f=application%2Fx-yaml\n  rel: self\n  type: application/x-yaml\n  title: This document\n- href: http://localhost:8080/geoserver/ogc/features/?f=application%2Fjson\n  rel: alternate\n  type: application/json\n  title: This document as application/json\n- href: http://localhost:8080/geoserver/ogc/features/?f=text%2Fhtml\n  rel: alternate\n  type: text/html\n  title: This document as text/html\n

                                                              The service title and description are provided by the existing Web Feature Service (WFS) settings.

                                                              "},{"location":"community/ogc-api/features/#open-api","title":"Open API","text":"

                                                              For programmatic access an OpenAPI description of the service is provided, that may be browsed as documentation, or used to generate a client to access the web services.

                                                              OGC API Features OpenAPI Document

                                                              "},{"location":"community/ogc-api/features/#collections","title":"Collections","text":"

                                                              The collection of feature types being published by the service.

                                                              Each collection entry is described using the layer details of title, description, geographic extent.

                                                              Data can be browsed as web pages, or downloaded in a range of formats such as GeoJSON and GML documents.

                                                              Collection sf:roads download formats

                                                              "},{"location":"community/ogc-api/features/#conformance","title":"Conformance","text":"

                                                              Lists the operations this service can perform, each \"conformance class\" documents supported functionality.

                                                              OGC API Features Conformance

                                                              "},{"location":"community/ogc-api/features/#contact-information","title":"Contact information","text":"

                                                              Advertises contact information for the service.

                                                              Defined by defined in by Contact Information.

                                                              "},{"location":"community/ogc-api/features/#configuration-of-ogc-api-features-module","title":"Configuration of OGC API - Features module","text":"

                                                              The service does not require any additional configuration to use. The service is configured using:

                                                              • The existing Web Feature Service (WFS) settings to define title, abstract, and output formats.

                                                                This is why the service page is titled GeoServer Web Feature Service by default.

                                                              • Built-in templates used for html generation

                                                              • Extra links can be added on a per-service or per-collection basis as indicated in Configuring the GeoServer OGC API module.

                                                              "},{"location":"community/ogc-api/features/#html-templates","title":"HTML Templates","text":"

                                                              To override an OGC API Features template:

                                                              1. Create a directory ogc/features in the location you wish to override:

                                                                • GEOSERVER_DATA_DIR/templates/ogc/features/v1
                                                                • GEOSERVER_DATA_DIR/workspace/{workspace}/ogc/features/v1
                                                                • GEOSERVER_DATA_DIR/workspace/{workspace}/{datastore}/ogc/features/v1
                                                                • GEOSERVER_DATA_DIR/workspace/{workspace}/{datastore}/{featuretype}/ogc/features/v1
                                                              2. Create a file in this location, using the GeoServer 2.24.2 examples below:

                                                                • ogc/features/v1/collection.ftl
                                                                • ogc/features/v1/collection_include.ftl
                                                                • ogc/features/v1/collections.ftl
                                                                • ogc/features/v1/queryables.ftl
                                                                • ogc/features/v1/functions.ftl

                                                                The above built-in examples are for GeoServer 2.24.2, please check for any changes when upgrading GeoServer.

                                                              The templates for listing feature content are shared between OGC API services. To override a template used to list features:

                                                              1. Use the directory in the location you wish to override:

                                                                • GEOSERVER_DATA_DIR/templates
                                                                • GEOSERVER_DATA_DIR/workspace/{workspace}
                                                                • GEOSERVER_DATA_DIR/workspace/{workspace}/{datastore}
                                                                • GEOSERVER_DATA_DIR/workspace/{workspace}/{datastore}/{featuretype}
                                                                • ogc/features/landingPage.ftl
                                                              2. Create a file in this location, using the GeoServer 2.24.2 examples below:

                                                                • ogc/features/getfeature-complex-content.ftl
                                                                • ogc/features/getfeature-content.ftl
                                                                • ogc/features/getfeature-empty.ftl
                                                                • ogc/features/getfeature-footer.ftl
                                                                • ogc/features/getfeature-header.ftl

                                                                The above built-in examples are for GeoServer 2.24.2, please check for any changes when upgrading GeoServer.

                                                              As an example customize how collections are listed:

                                                              1. The file ogc/features/collections.ftl lists published collection:

                                                                <#global pagecrumbs=\"<li class='breadcrumb-item'><a href='\"+serviceLink(\"\")+\"'>Home</a></li><li class='breadcrumb-item active'>Collections</li>\">\n<#include \"common-header.ftl\">\n\n  <h1>GeoServer Feature Collections</h1>\n  <p class=\"my-4\">\n    This document lists all the collections available in the Features service.<br/>\n  </p>\n\n  <div class=\"row\">\n    <#list model.collections as collection>\n    <div class=\"col-xs-12 col-md-6 col-lg-4 pb-4\">\n      <div class=\"card h-100\">\n        <div class=\"card-header\">\n          <h2><a href=\"${serviceLink(\"collections/${collection.id}\")}\">${collection.id}</a></h2>\n        </div>\n        <#include \"collection_include.ftl\">\n      </div>\n    </div>\n    </#list>\n  </div>\n\n<#include \"common-footer.ftl\">\n
                                                              2. Save file to GEOSERVER_DATA_DIR/workspace/templates/ogc/collections.ftl, and rewrite as:

                                                                <#include \"common-header.ftl\">\n       <h2>OGC API Feature Collections</h2>\n       <p>List of collections published.</p>\n       <p>See also: <#list model.getLinksExcept(null, \"text/html\") as link>\n          <a href=\"${link.href}\">${link.type}</a><#if link_has_next>, </#if></#list>.</p>\n\n     <#list model.collections as collection>\n       <h2><a href=\"${serviceLink(\"collections/${collection.id}\")}\">${collection.id}</a></h2>\n       <#include \"collection_include.ftl\">\n     </#list>\n<#include \"common-footer.ftl\">\n
                                                              3. Many templates are constructed using #include, for example collection.ftl above uses <#include \"common-header.ftl\"> located next to collections.ftl.

                                                                Presently each family of templates manages its own common-header.ftl (as shown in the difference between ogc/features service templates, and getfeature templates above).

                                                              4. A restart is required, as templates are cached.

                                                                Template collections.ftl override applied

                                                              5. Language codes are appended for internationalization. For French create the file GEOSERVER_DATA_DIR/workspace/{workspace}/ogc/collections_fr.ftl and translate contents:

                                                                <#include \"common-header.ftl\">\n       <h2>OGC API Feature Service</h2>\n       <p>Liste des collections publi\u00e9es.</p>\n       <p>Voir \u00e9galement: <#list model.getLinksExcept(null, \"text/html\") as link>\n          <a href=\"${link.href}\">${link.type}</a><#if link_has_next>, </#if></#list>.</p>\n\n     <#list model.collections as collection>\n       <h2><a href=\"${serviceLink(\"collections/${collection.id}\")}\">${collection.id}</a></h2>\n       <#include \"collection_include.ftl\">\n     </#list>\n<#include \"common-footer.ftl\">\n
                                                              6. For details on how to write templates see Freemarker Templates tutorial.

                                                              "},{"location":"community/ogc-api/maps/","title":"OGC API - Maps","text":"

                                                              A OGC API - Maps based on the current early specification draft, delivering partial functionality:

                                                              • Collection listing
                                                              • Styles per collection
                                                              • Map and info support for single collection

                                                              Missing functionality at the time of writing, and known issues:

                                                              • API definition
                                                              • Maps specific metadata (e.g., scale ranges)
                                                              • Support for multi-collection map representation
                                                              • HTML representation of a map with OpenLayers is only partially functional
                                                              "},{"location":"community/ogc-api/maps/#ogc-api-maps-implementation-status","title":"OGC API - Maps Implementation status","text":"OGC API - Maps Version Implementation status Part 1: Core Draft Implementation based on early specification draft. Part 2: Partitioning Draft Implementation based on early specification draft."},{"location":"community/ogc-api/maps/#installing-the-geoserver-ogc-api-maps-module","title":"Installing the GeoServer OGC API - Maps module","text":"
                                                              1. Download the OGC API nightly GeoServer community module from ogcapi-maps.

                                                                Warning

                                                                Verify that the version number in the filename corresponds to the version of GeoServer you are running (for example geoserver- 2.24.2-ogcapi-maps-plugin.zip above).

                                                              2. Extract the contents of the archive into the WEB-INF/lib directory of the GeoServer installation.

                                                              3. On restart the services are listed at http://localhost:8080/geoserver

                                                              "},{"location":"community/ogc-api/maps/#configuration-of-ogc-api-maps-module","title":"Configuration of OGC API - Maps module","text":"

                                                              The module is based on the GeoServer WMS one, follows the same configuration and exposes the same layers. As a significant difference, Maps does not have a concept of layer tree, so only individual layers and groups can be exposed.

                                                              "},{"location":"community/ogc-api/styles/","title":"OGC API - Styles","text":"

                                                              A OGC Styles API based on the early draft of this specification.

                                                              This service describes, retrieves and updates the styles present on the server. Styles are cross linked with their associated collections in both the Features and Tiles API.

                                                              "},{"location":"community/ogc-api/styles/#ogc-api-styles-implementation-status","title":"OGC API - Styles Implementation status","text":"OGC API - Styles Version Implementation status Part 1: Core Draft Implementation based on early specification draft."},{"location":"community/ogc-api/styles/#installing-the-geoserver-ogc-api-styles-module","title":"Installing the GeoServer OGC API - Styles module","text":"
                                                              1. Download the OGC API nightly GeoServer community module from ogcapi-styles.

                                                                Warning

                                                                Verify that the version number in the filename corresponds to the version of GeoServer you are running (for example geoserver- 2.24.2-ogcapi-styles-features-plugin.zip above).

                                                              2. Extract the contents of the archive into the WEB-INF/lib directory of the GeoServer installation.

                                                              3. On restart the services are listed at http://localhost:8080/geoserver

                                                              "},{"location":"community/ogc-api/styles/#configuration-of-ogc-api-styles-module","title":"Configuration of OGC API - Styles module","text":"

                                                              At the time of writing the module has no configuration, it's simply exposing all available GeoServer styles.

                                                              "},{"location":"community/ogc-api/tiled-features/","title":"OGC API - Tiled features demonstration","text":"

                                                              This module provides an example of extending the OGC API - Features module with a building block from OGC API - Tiles, used for tiled access to raw vector data (the vector tiles modules is included).

                                                              This module is not required to use vector tiles, it's also possible to use OGC API - Tiles directly, see OGC API - Tiles, along with the installation of the vector tiles extension.

                                                              "},{"location":"community/ogc-api/tiled-features/#installing-the-geoserver-ogc-api-tiled-features-module","title":"Installing the GeoServer OGC API tiled features module","text":"
                                                              1. Download the OGC API nightly GeoServer community module from ogcapi-tiled-features.

                                                                Warning

                                                                Verify that the version number in the filename corresponds to the version of GeoServer you are running (for example geoserver- 2.24.2-ogcapi-tiled-features-plugin.zip above).

                                                              2. Extract the contents of the archive into the WEB-INF/lib directory of the GeoServer installation.

                                                              3. On restart the services are listed at http://localhost:8080/geoserver

                                                              "},{"location":"community/ogc-api/tiled-features/#extensions","title":"Extensions","text":"

                                                              Upon installation, the OGC API - Features API will show the following extensions:

                                                              • Conformance classes are expanded with OGC API - Tiles ones

                                                              • Tile matrix sets links from the home page

                                                                Tile matrix EPSG:4326 definition

                                                              • Collections with vector tiles enabled will have a \"data tiles\" link pointing at the tiles endpoint

                                                                Data tiles link

                                                              "},{"location":"community/ogc-api/tiles/","title":"OGC API - Tiles","text":"

                                                              A OGC Tiles API delivering both tiled data (vector tiles) and tiled maps (classic map tiles).

                                                              GeoServer implementation is based on an ealier specification draft (the specification is now finalized).

                                                              "},{"location":"community/ogc-api/tiles/#ogc-api-tiles-implementation-status","title":"OGC API - Tiles Implementation status","text":"OGC API - Tiles Version Implementation status Part 1: Core Draft Implementation based on early specification draft, not yet updated to final version"},{"location":"community/ogc-api/tiles/#installing-the-geoserver-ogc-api-tiles-module","title":"Installing the GeoServer OGC API - Tiles module","text":"
                                                              1. Download the OGC API nightly GeoServer community module from ogcapi-tiles.

                                                                Warning

                                                                Verify that the version number in the filename corresponds to the version of GeoServer you are running (for example geoserver- 2.24.2-ogcapi-tiles-plugin.zip above).

                                                              2. Extract the contents of the archive into the WEB-INF/lib directory of the GeoServer installation.

                                                              3. On restart the services are listed at http://localhost:8080/geoserver

                                                              "},{"location":"community/ogc-api/tiles/#configuration-of-ogc-api-tiles-module","title":"Configuration of OGC API - Tiles module","text":"

                                                              The module exposes all Tiled layers configured for GeoWebCache using the OGC API - Tiles specification.

                                                              As such, it follows the same WMTS and Tile Caching configuration used to manage GeoWebCache.

                                                              "},{"location":"community/ogr-store/","title":"OGR datastore","text":"

                                                              The OGR datastore module allows to use the GDAL/OGR <https://gdal.org/> native library to access a wide variety of vector spatial formats and publish them in GeoServer.

                                                              This library is recommended to use when a particular data source does not have a GeoServer pure Java datastore fulfilling the same needs, in particular, compared to built in sources, it has the following limitations:

                                                              • Generally slower than the existing pure Java counterparts, especially for map rendering (the GeoServer stores can help rendering by providing reduced resolution version of the geometries, OGR provides no such facility)
                                                              • Less scalable than the pure Java counterparts, as the DataSource objects used to access data are not thread safe (see the pooling options below)
                                                              • More risky than the pure java counterparts, a SEGFAULT occurring inside OGR will take down the entire GeoServer process (while a pure Java exception is managed and reported, but won't have consequences on the server itself)

                                                              The OGR store has been tested with GDAL 2.2.x, but might be working with other versions as well. In case of malfunctions, you can try to remove the gdal-<version>.jar file from the GeoServer installation package, and replace it with the specific version jar instead, which you should find in your GDAL installation.

                                                              "},{"location":"community/ogr-store/#installing","title":"Installing","text":"

                                                              This is a community module, which means that it will not be available in the GeoServer official releases and needs to be installed manually.

                                                              This module can be installed following these steps:

                                                              1. Download this module package from the nightly builds, the module version should match the desired GeoServer version.
                                                              2. Extract the contents of the package into the WEB-INF/lib directory of the GeoServer installation.
                                                              3. Make sure that the GDAL library as well as the GDAL JNI native library are available in the GeoServer path (see below).
                                                              "},{"location":"community/ogr-store/#linux-installation-details","title":"Linux installation details","text":"

                                                              On Linux the native librariers are commonly available via packages such as gdal and gdal-java, which, on installation, make available the required libraries on the file system (the specific name may vary):

                                                              /usr/lib/libgdal.so\n/usr/lib/jni/libgdaljni.so\n

                                                              Normally these directories are already in the PATH, so no further configuration is required.

                                                              If using a custom build instead, the LD_LIBRARY_PATH and GDAL_DATA directories:

                                                              export LD_LIBRARY_PATH /path/to/gdal/libraries\nexport GDAL_DATA /path/to/gdal/data\n

                                                              See also the GDAL FAQ about the GDAL_DATA setup.

                                                              "},{"location":"community/ogr-store/#windows-installation-details","title":"Windows installation details","text":"

                                                              On windows the files in question might look like:

                                                              gdal204.dll\ngdalalljni.dll\n

                                                              Locating a pre-build GDAL that includes Java support might be difficult. One option is to download the gisinternals.com packages, in particular the release zip packages including both mapserver and GDAL (these are rather complete and include the necessary libraries, whilst the MSI installers are typically missing the Java support).

                                                              Once the package is available on disk, one has to set the following environment variables before starting GeoServer (the path might change depending on the package that is being downloaded):

                                                              set PATH=%PATH%;C:\\path\\to\\release-1900-x64-gdal-2-4-0-mapserver-7-2-1\\bin;C:\\tmp\\release-1900-x64-gdal-2-4-0-mapserver-7-2-1\\bin\\gdal\\java\nset GDAL_DRIVER_PATH=C:\\path\\to\\release-1900-x64-gdal-2-4-0-mapserver-7-2-1\\bin\\gdal\\plugins\nset GDAL_DATA=C:\\path\\to\\release-1900-x64-gdal-2-4-0-mapserver-7-2-1\\bin\\gdal-data\n
                                                              "},{"location":"community/ogr-store/#configuring-a-store","title":"Configuring a store","text":"

                                                              If the library is properly installed you will get the \"OGR\" data store among the supported stores in the \"new store\" page. In case it's not there, check the logs, they might be reporting that the GDAL/OGR native libs are missing, if the error is not there, check that the jars have been unpacked in the right position instead.

                                                              Creating a new store requires configuration of only the DatasourceName field, any other parameter is optional:

                                                              The OGR datasore configuration page

                                                              The DatasourceName can be a reference to a file, a directory, or a set of connection parameters to a server. For example, to connect to a PostGIS database the connection parameters could be:

                                                              PG:user=theUser password=thePassword dbname=theDatabase

                                                              Notice how, unlike documented in the OGR page, single quotes are not needed (and actually harmful) around the user/password/dbname section. The Browse button can be used to quickly peek files or directories from the file system.

                                                              The Driver parameter is optional, OGR should be able to recognize the appropriate driver automatically, but it's useful to force a specific choice when multiple competing drivers are available for the same data source (e.g., OpenFileGDB vs FileGDB).

                                                              The pooling parameters, similar to those found in a database, merit an explanation. OGR exposes access to data through DataSource objects, which are not thread safe, so only one request at a time can use them. At the same time, they can be expensive to create and hold onto useful state, like in memory data caches, spatial indexes and the like. As such, they have been stored in a pool much like relational database connections.

                                                              The Prime DataSources option can be enabled to force a full read of the source data before the GDAL DataSource object is used. In some formats this allows the creation of useful support data structures, like an in memory spatial index in the OpenFileGDB format. Since the full read can be expensive, care should be taken to configure the pooling options so that it gets reused as much as possible (e.g., setting a higher min connections, eventually setting it to the same value as max connections).

                                                              "},{"location":"community/opensearch-eo/","title":"OpenSearch for EO","text":"
                                                              • Introduction to OpenSearch for EO
                                                              • Installing the OpenSearch for EO module
                                                              • Configuring the OpenSearch module
                                                              • The JDBC store database structure
                                                              • Automation with the administration REST API
                                                              • The STAC extension
                                                              • OpenSearch/STAC JSON templates
                                                              • Upgrading from previous version
                                                              "},{"location":"community/opensearch-eo/STAC/","title":"The STAC extension","text":"

                                                              The OpenSeach for EO subsystem exposes also a STAC service, implemented as a OGC API Features conformant STAC API.

                                                              The landing page of the STAC API is linked from the GeoServer home page, and available at $HOST:$PORT/geoserver/ogc/stac. The API exposes the OpenSearch for EO contents, restructuring them as needed:

                                                              • The collections table is mapped to STAC collections
                                                              • The products table is mapped to STAC items

                                                              Given the differences in names and structures the STAC resources are created using templates, in particular:

                                                              • The HTML representation is built using Freemarker templates
                                                              • The GeoJSON representation is built using GeoJSON features templates

                                                              The default templates work against the default PostGIS database structure and can be customized to include new properties to follow eventual database modifications.

                                                              All built-in templates are copied over to the data directory for customization, and placed in the $GEOSERER_DATA_DIR/templates/ogc/stac folder:

                                                              • collection.ftl
                                                              • collection_include.ftl
                                                              • collections.ftl
                                                              • collections.json
                                                              • item.ftl
                                                              • item_include.ftl
                                                              • items-content.ftl
                                                              • items-empty.ftl
                                                              • items-footer.ftl
                                                              • items-header.ftl
                                                              • items.json
                                                              • landingPage.ftl
                                                              • queryables-collection.ftl
                                                              • queryables-common.ftl
                                                              • queryables-global.ftl
                                                              • search-content.ftl
                                                              • search-empty.ftl
                                                              • search-footer.ftl
                                                              • search-header.ftl

                                                              Specifically for the JSON output:

                                                              • \\$GEOSERVER_DATA_DIR/templates/ogc/stac/v1/collections.json is the collections template
                                                              • \\$GEOSERVER_DATA_DIR/templates/ogc/stac/v1/items.json is the items template

                                                              The JSON templates in the case of STAC also drive database querying, the exposed STAC properties are back-mapped into database properties by interpreting the template. It is advised to keep property mapping as simple as possible to allow usage of native SQL queries and indexes while accessing the database through the STAC API.

                                                              For both items and collections, collection specific templates can also be provided, which would contain directives and mappings unique to that collection. A collection specific template can be placed in the same templates directory as above, using the naming convention items-<COLLECTION_ID>.json or collections-<COLLECTION_ID>.json, where <COLLECTION_ID> is the collection identifier. For example, if the collection is named SENTINEL2:

                                                              • The collections specific template for it is named collections-SENTINEL2.json
                                                              • The items template specific for it is named items-SENTINEL2.json
                                                              "},{"location":"community/opensearch-eo/STAC/#fields-fragments","title":"Fields fragments","text":"

                                                              When dealing with JSON output for GET requests in the context of STAC service, the module supports the selection of fields based on the inclusion and exclusion semantic described in the field fragments specification. According to the current specification:

                                                              • If no fields query parameter is specified all the item's attribute are returned.
                                                              • If a fields attribute is specified with no values, only the item's default values (the one necessary to have a valid STAC entity) are returned: id,type,geometry,bbox,links,assets,properties.datetime,properties.created.
                                                              • If fields value is specified GeoServer will return always the default attributes, if the user doesn't target them as excluded. Eg. assets will always be present if not exluced explicitly (fields=-assets,...).
                                                              • If only include is specified, these attributes are added to the default set of attributes (set union operation).
                                                              • If only exclude is specified, these attributes are subtracted from the union of the default set of attributes and the include attributes (set difference operation). This will result in an entity that is not a valid Item if any of the excluded attributes are in the default set of attributes, but no error message will be raised by GeoServer.
                                                              • If a attribute is included, e.g. properties, but one or more of the nested attributes is excluded, e.g. -properties.datetime, then the excluded nested attributes will not appear in properties.
                                                              • If an attribute is excluded, e.g. -properties.nestedObj, but one of more of the nested attributes is included, e.g. properties.nestedObject.attribute, then nestedObject will appear in the output with the included attributes only.
                                                              "},{"location":"community/opensearch-eo/STAC/#datacube-extension-support","title":"Datacube Extension Support","text":"

                                                              Support for the STAC Datacube Extension \"cube_dimensions\" elements is available in HTML and JSON templates via the eoSummaries function. eoSummaries supports presenting the following collection-wide summary statistics:

                                                              • min - The minimum value of the field in the collection
                                                              • max - The maximum value of the field in the collection
                                                              • distinct - An array of distinct values of the field in the collection
                                                              • bounds - Minimum and maximum dimension values of the spatial bounding box of the collection (either x or y, presented as a two value array or xmin, xmax, ymin, ymax presented as individual dimension values)

                                                              eoSummaries has three arguments:

                                                              • aggregate - The type of summary statistic. One of \"min\", \"max\", \"distinct\", or \"bounds\".

                                                              • collectionIdentifier - The name of the collection that is being summarized.

                                                              • property - The name of the property being summarized.

                                                                • Note that for the \"bounds\" aggregate, this value should either be \"x\",\"y\",\"xmin\",\"ymin\",\"xmax\", or \"ymax\".

                                                              JSON Template Example:

                                                              \"extent\": {\n  \"spatial\": {\n    \"bbox\": [\n      [\n        \"$${eoSummaries('bounds',eo:parentIdentifier,'xmin')}\",\n        \"$${eoSummaries('bounds',eo:parentIdentifier,'ymin')}\",\n        \"$${eoSummaries('bounds',eo:parentIdentifier,'xmax')}\",\n        \"$${eoSummaries('bounds',eo:parentIdentifier,'ymax')}\"\n      ]\n    ]\n  },\n  \"cube:dimensions\"\\: {\n   \"x\": {\n      \"type\": \"spatial\",\n      \"axis\": \"x\",\n      \"extent\": \"$${eoSummaries('bounds',eo:parentIdentifier,'x')}\",\n      \"reference_system\": 4326},\n          \"y\": {\n          \"type\": \"spatial\",\n          \"axis\": \"y\",\n          \"extent\": \"$${eoSummaries('bounds',eo:parentIdentifier,'y')}\",\n          \"reference_system\": 4326},\n          \"time\": \n              {\"type\": \"temporal\",\n              \"extent\": \n                  [\"$${eoSummaries('min',eo:parentIdentifier,'timeStart')}\",\n              \"$${eoSummaries('min',eo:parentIdentifier,'timeEnd')}\"]\n              }\n      }\n

                                                              HTML/FTL Example:

                                                              <li><b>Extents</b>:\n     <ul>\n    <li data-tid='gbounds'>Geographic (WGS84):\n                ${model.eoSummaries(\"bounds\",a.name.value,\"x\")[0]}, \n                ${model.eoSummaries(\"bounds\",a.name.value,\"y\")[0]}, \n                ${model.eoSummaries(\"bounds\",a.name.value,\"x\")[1]}, \n                ${model.eoSummaries(\"bounds\",a.name.value,\"y\")[1]}.\n            </li>\n            <li data-tid='tbounds'>Temporal: \n                ${model.eoSummaries(\"min\",a.name.value,\"timeStart\")}/\n                ${model.eoSummaries(\"max\",a.name.value,\"timeEnd\")}\n            </li> \n        </ul>\n</li>\n
                                                              "},{"location":"community/opensearch-eo/automation/","title":"Automation with the administration REST API","text":"

                                                              The OpenSearch module supports full automation REST API that can be used to create collections, ingest products and eventually their granules. The full API is available at this URL:

                                                              • /oseo

                                                              In general terms, one would:

                                                              • Create a collection, along with thumbnail, OGC links
                                                              • Then create a product, along with thumbnail, OGC links
                                                              • Finally, and optionally, specify the granules composing the product (actually needed only if the OpenSearch subsystem is meant to be used for publishing OGC services layers too, instead of being a simple search engine.
                                                              "},{"location":"community/opensearch-eo/automation/#understanding-the-zip-file-uploads","title":"Understanding the zip file uploads","text":"

                                                              The description of a collection and product is normally made of various components, in order to expedite data creation and reduce protocol chattines, it is possible to bulk-upload all files composing the description of collections and products as a single zip file.

                                                              "},{"location":"community/opensearch-eo/automation/#collection-components","title":"Collection components","text":"

                                                              A collection.zip, sent as a PUT request to rest/collections would contain the following files:

                                                              Name Optional Description collection.json N The collection attributes, matching the database structure (the prefixes are separated with a colon in this document) description.html Y The HTML description for the collection thumbnail.png, thumbnail.jpg or thumbnail.jpeg Y The collection thumbnail owsLinks.json Y The list of OWS links to OGC services providing access to the collection contents (typically as a time enabled layer)"},{"location":"community/opensearch-eo/automation/#product-components","title":"Product components","text":"

                                                              A product.zip, sent as a POST request to rest/collections/<theCollection>/products would contain the following files:

                                                              Name Optional Description product.json N The product attributes, matching the database structure (the prefixes are separated with a colon in this JSON document) description.html Y The HTML description for the product thumbnail.png, thumbnail.jpg or thumbnail.jpeg Y The collection thumbnail owsLinks.json Y The list of OWS links to OGC services providing access to the product contents (typically, a specific time slice in the collection layer, but other organizations are possible too) granules.json Y The list of actual files making up the product, along with their bounding boxes, file location and eventual band name, for products splitting bands in different files. Could be a single file, a list of files split by area, or a list of files representing the various bands of a multispectral product.

                                                              It is also possible to send the zip file on the rest/collections/<theCollection>/products/<theProduct> resource as a PUT request, it will update an existing product by replacing the parts contained in the file. Parts missing from the file will be kept unchanged, to remove them run an explicit DELETE request on their respective REST resources.

                                                              "},{"location":"community/opensearch-eo/automation/#usage-of-the-api-for-search-and-integrated-ogc-service-publishing","title":"Usage of the API for search and integrated OGC service publishing","text":"

                                                              In this case the user intend to both use the OpenSearch module for search purposes, but also to publish actual mosaics for each collection.

                                                              In this case the following approach should is recommended:

                                                              • Create a collection via the REST API, using the ZIP file POST upload
                                                              • Create at least one product in the collection in the REST API, using the ZIP file POST upload and providing a full granules.json content with all the granules of said product
                                                              • Post a layer publishing description file to /oseo/collection/{COLLECTION}/layers to have the module setup a set of mosaic configuration files, store, layer with eventual coverage view and style

                                                              A collection can have multiple layers:

                                                              • Getting the /oseo/collection/{COLLECTION}/layers resource returns a list of the available ones
                                                              • /oseo/collection/{COLLECTION}/layers/{layer} returns the specific configuration (PUT can be used to modify it, and DELETE to remove it).
                                                              • Creation of a layer configuration can be done either by post-ing to /oseo/collection/{COLLECTION}/layers or by put-int to /oseo/collection/{COLLECTION}/layers/{layer}.

                                                              The layer configuration fields are:

                                                              Attribute Description workspace The workspace that will contain the store and layer to be published layer The name of the layer that will be created separateBands A boolean value, true if the underlying granule table has the \"band\" column populated with values, meaning the product bands are split among different files, false if a single product is stored in a single file heterogeneousCRS A boolean value, indicating if the products in the collection share the same CRS (false) or are expressed in different CRSses (true) timeRanges A boolean value, indicating if the products are associated to a single time (false) or have have a time range of validity (true) bands The list of bands used in this layer (to be specified only if \"separateBands\" is used) browseBands An array of 1 or 3 band names used to create the default display for the layer mosaicCRS The identifier of the CRS used by the mosaic (must match the granules table one) defaultLayer A flag indicating if the layer is considered the default one for the collection (thus also appearing at /oseo/collection/{COLLECTION}/layer

                                                              The layer configuration specification will have different contents depending on the collection structure:

                                                              • Single CRS, non band split, RGB or RGBA files, time configured as an \"instant\" (only timeStart used):

                                                                {\n    \"workspace\": \"gs\",\n    \"layer\": \"test123\",\n    \"separateBands\": false,\n    \"heterogeneousCRS\": false,\n    \"timeRanges\": false\n}\n
                                                              • Single CRS, multiband in single file, with a gray browse style, product time configured as a range between timeStart and timeEnd:

                                                                {\n    \"workspace\": \"gs\",\n    \"layer\": \"test123\",\n    \"separateBands\": false,\n    \"browseBands\": [\"test123[0]\"],\n    \"heterogeneousCRS\": false,\n    \"timeRanges\": true\n}\n
                                                              • Heterogeneous CRS, multi-band split across files, with a RGB browse style (\"timeRanges\" not specified, implying it's handled as an instant):

                                                                {\n    \"workspace\": \"gs\",\n    \"layer\": \"test123\",\n    \"separateBands\": true,\n    \"bands\": [\n        \"VNIR\",\n        \"QUALITY\",\n        \"CLOUDSHADOW\",\n        \"HAZE\",\n        \"SNOW\"\n    ],\n    \"browseBands\": [\n        \"VNIR[0]\", \"VNIR[1]\", \"SNOW\"\n    ],\n    \"heterogeneousCRS\": true,\n    \"mosaicCRS\": \"EPSG:4326\"\n}\n

                                                              In terms of band naming the \"bands\" parameter contains coverage names as used in the \"band\" column of the granules table, in case a granule contains multiple bands, they can be referred by either using the full name, in which case they will be all picked, or by using zero-based indexes like BANDNAME[INDEX], which allows to pick a particular band.

                                                              The same syntax is meant to be used in the browseBands property. In case the source is not split band, the browseBands can still be used to select specific bands, using the layer name as the coverage name, e.g. \"test123[0]\" to select the first band of the coverage.

                                                              "},{"location":"community/opensearch-eo/automation/#cog-mosaic-creation","title":"COG Mosaic creation","text":"

                                                              It's also possible to configure a layer on top of a COG ImageMosaic, provided that the COG (Cloud Optimized GeoTIFF) Support plugin has been installed in GeoServer.

                                                              Additional fields for the layer configuration are:

                                                              Attribute Description cog Set it to true to specify the layer is made of COG datasets cogUser (Optional) Credential to be set whenever basic HTTP authentication is needed to access the COG Datasets or an S3 Access KeyID is required cogPassword (Optional) Password for the above user OR Secret Access Key for the above S3 KeyId. cogRangeReader (Optional) Specify the desired RangeReader implementation. (default is HTTP based)

                                                              See COG RangeReader from the COG plugin documentation, for the list of supported RangeReader implementations.

                                                              "},{"location":"community/opensearch-eo/configuration/","title":"Configuring the OpenSearch module","text":"

                                                              The OpenSearch module needs to know upon which database perform the searches.

                                                              Follow these steps:

                                                              • Setup a standard PostGIS database pointing to the database and schema created above from the SQL file. Note down the full name of the store (e.g. test:metadata where test is the workspace and metadata is the store name). Besides filling the connection parameters, remember to set \"expose primary keys\" to true.

                                                              • Create a new store of type \"JDBC based OpenSearch store\" and configure the fully qualified name of the basic PostGIS store in its \"store\" parameter.

                                                              • Go into the \"OS-EO\" service configuration page and configure the \"OpenSearch\" store

                                                                • (Optional) You can also configure how long values will be cached for performance purposes for templates that require collection level aggregate statistics by adjusting the cache time to live duration and time units.

                                                              • Global Queryables (applicable to the STAC API to define queryable fields for all Collections) can be configured

                                                              using a comma delimited list in the text box under OpenSearch specific metadata

                                                              "},{"location":"community/opensearch-eo/configuration/#advanced-adding-product-classes","title":"Advanced: adding product classes","text":"

                                                              The design of the OpenSearch module is \"data driven\", meaning that one can materialize new search properties by just adding new columns to the product and collection tables.

                                                              In particular, both tables have a \"prefix based\" convention linking the properties to their respective product types, and the engine will advertise for a particular product only the properties relevant to it. For example, in an optical product, the properties starting with \"opt\" will be listed, but not those starting with \"sar\".

                                                              Here is a table of the product classes known out of the box:

                                                              Name Prefix Namespace Description eop_generic eop http://www.opengis.net/eop/2.1 Base properties shared among all EO products. Never remove this class. optical opt http://www.opengis.net/opt/2.1 Optical products properties radar sar http://www.opengis.net/sar/2.1 Radar products properties Altimetric alt http://www.opengis.net/alt/2.1 Altimetric products properties Atmospheric atm http://www.opengis.net/atm/2.1 Atmospheric products properties Limb lmb http://www.opengis.net/lmb/2.1 Limb products properties ssp ssp http://www.opengis.net/ssp/2.1 SSP products properties

                                                              The various properties have different usages:

                                                              • The name is used in the collection to define the type of sensor (eoSensorType column)
                                                              • The prefix is used in the product table as a prefix to column name in order to associate them to a particular product type, shows up as-is in the JSON representations of the REST API, as well as the prefix in XML outputs
                                                              • The namespace is used in XML output, along with the prefix (e.g., xmlns:opt=\"http://www.opengis.net/opt/2.1\")

                                                              It is possible to add new product classes as well as changing the built-in ones, but care should be taken to keep product classes and database aligned. After any change to the database structure remember to \"reset\" the GeoServer configuration to make it re-scan the table structures.

                                                              "},{"location":"community/opensearch-eo/configuration/#oseo_html_templates","title":"HTML templates","text":"

                                                              The Freemarker templates for collections and products can be found in $GEOSERVER_DATA_DIRECTORY/templates/os-eo:

                                                              • generic-header.ftl receives SearchResults, Query, organization, title, updated(date), builder and encodes a generic header Atom HTML description for it.
                                                              • generic-footer.ftl exists simple for having a closing tag.
                                                              • product.ftl receives an OpenSearch product, updated(date), dcDate(date), offerings and encodes the Atom HTML description for it.
                                                              • collection.ftl receives an OpenSearch collection, updated(date), dcDate(date), offerings and encodes the Atom HTML description for it.

                                                              The default templates, linked above, report the time range for the product/collection, and link to other pertinent OpenSearch resources (metadata, self link, quicklooks).

                                                              Collection specific templates can be set up in the data directory, appending the collection identifier to the file name, e.g. collection-SENTINEL2.ftl or product-SENTINEL2.ftl.

                                                              The templates can use a oseoLink function to build links pointing back to the OpenSearch service. The function receives the following parameters:

                                                              • The first argument is a path segment under the oseo service path.
                                                              • The other arguments, optional, are couple of keys and values, used to encode the link's query string.
                                                              "},{"location":"community/opensearch-eo/configuration/#oseo_metadata_templates","title":"Metadata templates","text":"

                                                              The Freemarker metadata templates for collections and products can be found in $GEOSERVER_DATA_DIRECTORY/templates/os-eo:

                                                              • product-metadata.ftl receives an OpenSearch product and encodes the Atom HTML description for it.
                                                              • collection-metadata.ftl receives an OpenSearch collection and encodes the Atom HTML description for it.

                                                              The default templates, linked above, generate respectively a ISO metadata sheet for collections, and a EO O&M product metadata sheet for products.

                                                              The templates can use a oseoLink function to build links pointing back to the OpenSearch service. The function receives the following parameters:

                                                              • The first argument is a path segment under the oseo service path.
                                                              • The other arguments, optional, are couple of keys and values, used to encode the link's query string.

                                                              The templates can also use a gml function that generates a GML 3.2 representation of a geometry (mind, the output must be forced not to be escaped, using ?no_esc, as well as minx, miny, maxx, maxy that can be used to extract the bounding box corner values. All these function expect a geometry as input.

                                                              Finally templates can use a loadJSON function to read a JSON from a file inside the GeoServer data directory. The path to the JSON file can be absolute eg. \"${loadJSON('/path/to/read.json')}\", or a plain file name, in case the JSON file is present in the GeoServer root directory eg. \"${loadJSON('read.json')}\".

                                                              The function returns a string JSON that can be parsed using the ?eval_json free marker built-in function: <#assign loadedJSON = \"${loadJSON('readAndEval.json')}\"> <#assign evalJSON = loadedJSON?eval_json>

                                                              More information about writing templates can be found in the templates guide.

                                                              "},{"location":"community/opensearch-eo/configuration/#geojson-output-templates","title":"GeoJSON output templates","text":"

                                                              The module supports GeoJSON encoding of collections and products according to the <https://docs.opengeospatial.org/is/17-047r1/17-047r1.html>>_.

                                                              Give the structure required in output, it's not possible to use the simple features GeoJSON encoders. The module is instead using two dedicated features templates, that the user can customize to match the database structure.

                                                              The default templates are part of the GeoServer distribution, and are automatically copied to the data directory on startup, to allow for customization:

                                                              • \\$GEOSERVER_DATA_DIR/templates/os-eo/products.json is the products template
                                                              • \\$GEOSERVER_DATA_DIR/templates/os-eo/collections.json is the collections template

                                                              The default templates work against the default PostGIS database structure and can be customized to include new properties to follow eventual database modifications.

                                                              Collection specific templates can also be provided, which would contain directives and mappings unique to that collection. A collection specific template can be placed in the same templates directory as above, called either collections-<COLLECTION_ID>.json or products-<COLLECTION_ID>.json where <COLLECTION_ID> is the collection identifier. For example, if the collection is named SENTINEL2 a products template specific for it will be named products-SENTINEL2.json, while the collection template will be named collections-SENTINEL2.json.

                                                              More information about writing templates can be found in the templates guide.

                                                              "},{"location":"community/opensearch-eo/database/","title":"The JDBC store database structure","text":"

                                                              The JDBC store uses a conventional relational structure, depicted in the following picture:

                                                              So a collection has its own primary search attributes, as well as:

                                                              • Zero or more OGC links pointing to where the collection is published
                                                              • Layer publishing information (for auto-generation of mosaic, layer and eventual coverage view in case the actual data resides locally)
                                                              • One or more products

                                                              A product in turn is associated to:

                                                              • A thumbnail image, in PNG or JPEG format
                                                              • Zero or more OGC links pointing to where the product is published

                                                              The granule table is designed to contain per product file information in case there is a desire to publish the actual data from the same local GeoServer (but in general, OGC services might be missing or provided by a separate server).

                                                              "},{"location":"community/opensearch-eo/database/#collections","title":"Collections","text":"

                                                              The collection table currently looks as follows (check the SQL file in the installation instructions for a more up to date version of it):

                                                              create table collection (\n  \"id\" serial primary key,\n  \"name\" varchar,\n  \"primary\" boolean,\n  \"htmlDescription\" text,\n  \"footprint\" geography(Polygon, 4326),\n  \"timeStart\" timestamp,\n  \"timeEnd\" timestamp,\n  \"productCqlFilter\" varchar,\n  \"masked\" boolean,\n  \"eoIdentifier\" varchar unique,\n  \"eoProductType\" varchar,\n  \"eoPlatform\" varchar,\n  \"eoPlatformSerialIdentifier\" varchar,\n  \"eoInstrument\" varchar,\n  \"eoSensorType\" varchar check (\"eoSensorType\" in ('OPTICAL', 'RADAR', 'ALTIMETRIC', 'ATMOSPHERIC', 'LIMB')),\n  \"eoCompositeType\" varchar,\n  \"eoProcessingLevel\" varchar,\n  \"eoOrbitType\" varchar,\n  \"eoSpectralRange\" varchar,\n  \"eoWavelength\" int,\n  \"eoSecurityConstraints\" boolean,\n  \"eoDissemination\" varchar,\n  \"eoAcquisitionStation\" varchar,\n  \"queryables\" varchar[],\n  \"workspaces\" varchar[]\n);\n

                                                              Most of the attributes should be rather self-explanatory to those familiar with OGC Earth Observation terminology. Each attribute prefixed by \"eo\" is exposed as a search attribute in OpenSearch, the structure can be modified by adding extra attributes and they will show up and made searchable.

                                                              Specific attributes notes:

                                                              • A primary collection is normally linked to a particular satellite/sensor and contains its own products. Setting \"primary\" to false makes the collection \"virtual\" and the productCQLFilter field should be filled with a CQL filter that will collect all the products in the collection (warning, virtual collections are largely untested at the moment)
                                                              • The footprint field is used for spatial searches, while timeStart and timeEnd are used for temporal ones
                                                              • The htmlDescription drives the generation of the visible part of the Atom OpenSearch response, see the dedicated section later to learn more about filling it
                                                              • The workspaces field is an array used to specify the GeoServer workspaces that the collection is associated with. If the field is left empty or null, or if the array contains a null value, the collection will be associated with all workspaces. If the field is populated, the collection will only be associated with the specified workspaces and will be hidden from workspace specific STAC calls.

                                                              The collection_ogclink table contains the OGC links towards the services providing visualization and download access to the collection contents. See the \"OGC links\" section to gather more information about it.

                                                              "},{"location":"community/opensearch-eo/database/#products","title":"Products","text":"

                                                              The product table currently looks as follows (check the SQL file in the installation instructions for a more up to date version of it):

                                                              -- the products and attributes describing them\ncreate table product (\n  \"id\" serial primary key,\n  \"htmlDescription\" text,\n  \"footprint\" geography(Polygon, 4326),\n  \"timeStart\" timestamp,\n  \"timeEnd\" timestamp,\n  \"originalPackageLocation\" varchar,\n  \"originalPackageType\" varchar,\n  \"thumbnailURL\" varchar,\n  \"quicklookURL\" varchar,\n  \"crs\" varchar,\n  \"eoIdentifier\" varchar unique,\n  \"eoParentIdentifier\" varchar references collection(\"eoIdentifier\") on delete cascade,\n  \"eoProductionStatus\" varchar,\n  \"eoAcquisitionType\" varchar check (\"eoAcquisitionType\" in ('NOMINAL', 'CALIBRATION', 'OTHER')),\n  \"eoOrbitNumber\" int,\n  \"eoOrbitDirection\" varchar check (\"eoOrbitDirection\" in ('ASCENDING', 'DESCENDING')),\n  \"eoTrack\" int,\n  \"eoFrame\" int,\n  \"eoSwathIdentifier\" text,\n  \"optCloudCover\" int check (\"optCloudCover\" between 0 and 100),\n  \"optSnowCover\" int check (\"optSnowCover\" between 0 and 100),\n  \"eoProductQualityStatus\" varchar check (\"eoProductQualityStatus\" in ('NOMINAL', 'DEGRADED')),\n  \"eoProductQualityDegradationStatus\" varchar,\n  \"eoProcessorName\" varchar,\n  \"eoProcessingCenter\" varchar,\n  \"eoCreationDate\" timestamp,\n  \"eoModificationDate\" timestamp,\n  \"eoProcessingDate\" timestamp,\n  \"eoSensorMode\" varchar,\n  \"eoArchivingCenter\" varchar,\n  \"eoProcessingMode\" varchar,\n  \"eoAvailabilityTime\" timestamp,\n  \"eoAcquisitionStation\" varchar,\n  \"eoAcquisitionSubtype\" varchar,\n  \"eoStartTimeFromAscendingNode\" int,\n  \"eoCompletionTimeFromAscendingNode\" int,\n  \"eoIlluminationAzimuthAngle\" float,\n  \"eoIlluminationZenithAngle\" float,\n  \"eoIlluminationElevationAngle\" float,\n  \"sarPolarisationMode\" varchar check (\"sarPolarisationMode\" in ('S', 'D', 'T', 'Q', 'UNDEFINED')),\n  \"sarPolarisationChannels\" varchar check (\"sarPolarisationChannels\" in ('horizontal', 'vertical')),\n  \"sarAntennaLookDirection\" varchar check (\"sarAntennaLookDirection\" in ('LEFT', 'RIGHT')),\n  \"sarMinimumIncidenceAngle\" float,\n  \"sarMaximumIncidenceAngle\" float,\n  \"sarDopplerFrequency\" float,\n  \"sarIncidenceAngleVariation\" float,\n  \"eoResolution\" float\n);\n

                                                              Notes on the attributes:

                                                              • The footprint field is used for spatial searches, while timeStart and timeEnd are used for temporal ones
                                                              • The htmlDescription drives the generation of the visible part of the Atom OpenSearch response, see the dedicated section later to learn more about filling it
                                                              • The crs attribute is optional and is used only for automatic layer publishing for collections having heterogeneous CRS products. It must contain a \"EPSG:XYWZ\" expression (but the product footprint still need to be expressed in WGS84, east/north oriented).
                                                              • The EO search attributes need to be filled according to the nature of the product, eo prefixes generic EOP attributes, opt optical ones, sar radar ones, atm altimetric, lmb limbic, ssp Synthesis and Systematic Product. New attributes can be added based on the above prefixes (at the time of writing only optical and sar attributes have been tested)

                                                              The product_thumb table contains the product thumbnail, in PNG or JPEG format, for display in the OpenSearch Atom output.

                                                              The product_ogclink table contains the OGC links towards the services providing visualization and download access to the collection contents. See the \"OGC links\" section to gather more information about it.

                                                              "},{"location":"community/opensearch-eo/database/#ogc-links","title":"OGC links","text":"

                                                              The OpenSearch module implements \"OGC cross linking\" by adding pointers to OGC services for to collection/product visualization and download.

                                                              -- links for collections\ncreate table collection_ogclink (\n  \"lid\" serial primary key,\n  \"collection_id\" int references collection(\"id\") on delete cascade,\n  \"offering\" varchar,\n  \"method\" varchar,\n  \"code\" varchar,\n  \"type\" varchar,\n  \"href\" varchar\n);\n\n-- links for products\ncreate table product_ogclink (\n  \"lid\" serial primary key,\n  \"product_id\" int references product(\"id\") on delete cascade,\n  \"offering\" varchar,\n  \"method\" varchar,\n  \"code\" varchar,\n  \"type\" varchar,\n  \"href\" varchar\n);\n

                                                              This is done by adding a set of owc:offering elements in the Atom response, mapping directly from the table contents:

                                                              <owc:offering code=\"http://www.opengis.net/spec/owc/1.0/req/atom/wcs\">\n  <owc:operation method=\"GET\" code=\"GetCapabilities\" href=\"http://localhost/sentinel2/sentinel2-TCI/ows?service=WCS&amp;version=2.0.1&amp;request=GetCapabilities\" type=\"application/xml\"/>\n</owc:offering>\n<owc:offering code=\"http://www.opengis.net/spec/owc/1.0/req/atom/wmts\">\n  <owc:operation method=\"GET\" code=\"GetCapabilities\" href=\"http://localhost/sentinel2/sentinel2-TCI/gwc/service/wmts?REQUEST=GetCapabilities\" type=\"application/xml\"/>\n</owc:offering>\n<owc:offering code=\"http://www.opengis.net/spec/owc/1.0/req/atom/wms\">\n  <owc:operation method=\"GET\" code=\"GetCapabilities\" href=\"http://localhost/sentinel2/sentinel2-TCI/ows?service=wms&amp;version=1.3.0&amp;request=GetCapabilities\" type=\"application/xml\"/>\n  <owc:operation method=\"GET\" code=\"GetMap\" href=\"http://localhost/sentinel2/sentinel2:sentinel2-TCI/wms?SERVICE=WMS&amp;VERSION=1.1.1&amp;REQUEST=GetMap&amp;FORMAT=image%2Fjpeg&amp;STYLES&amp;LAYERS=sentinel2%3Asentinel2-TCI&amp;SRS=EPSG%3A4326&amp;WIDTH=800&amp;HEIGHT=600&amp;BBOX=-180%2C-90%2C180%2C90\" type=\"image/jpeg\"/>\n</owc:offering>\n

                                                              The contents of the tables need to be filled with the sane named elements of a OWC offering, the href one can contain a ${BASE_URL} variable that GeoServer will replace with its own base URL.

                                                              "},{"location":"community/opensearch-eo/database/#the-granule-table","title":"The granule table","text":"

                                                              The granule table can be filled with information about the actual raster files making up a certain product in order to publish the collection as a GeoServer image mosaic:

                                                              -- the granules table (might be abstract, and we can use partitioning)\ncreate table granule (\n  \"gid\" serial primary key,\n  \"product_id\" int not null references product(\"id\") on delete cascade,\n  \"band\" varchar,\n  \"location\" varchar not null,\n  \"the_geom\" geometry(Polygon, 4326) not null\n);\n

                                                              The granules associated to a product can have different topologies:

                                                              • A single raster file containing all the information about the product
                                                              • Multiple raster files splitting the products spatially in regular tiles
                                                              • Multiple raster files splitting the product wavelength wise
                                                              • A mix of the two above

                                                              Notes about the columns:

                                                              • The band column need to be filled only for products split in several files by bands, at the time of writing it needs to be a progressive integer starting from 1 (the module will hopefully allow more meaningful band names in the future)
                                                              • The location is the absolute path of the file
                                                              • The the_geom field is a polygon in WGS84, regardless of what the actual footprint of the file is. The polygon must represent the rectangular extend of the raster file, not its valid area (masking is to be treated separately, either with sidecar mask files or with NODATA pixels)
                                                              "},{"location":"community/opensearch-eo/installation/","title":"Installing the OpenSearch for EO module","text":"

                                                              The installation of the module requires four steps:

                                                              • Setting up a PostGIS database with the required schema
                                                              • Install the OpenSearch for EO plugin and configure it
                                                              • Fill the database with information about collection and metadata
                                                              "},{"location":"community/opensearch-eo/installation/#setting-up-the-postgis-database","title":"Setting up the PostGIS database","text":"

                                                              Create a PostgreSQL database and run the following SQL script:

                                                              https://raw.githubusercontent.com/geoserver/geoserver/main/src/community/oseo/oseo-core/src/test/resources/postgis.sql\n
                                                              "},{"location":"community/opensearch-eo/installation/#downloading-and-installing-the-opensearch-extension","title":"Downloading and installing the OpenSearch extension","text":"

                                                              The module is a community one, and thus available among the nightly builds of the desired series (the module works for 2.12.x onwards):

                                                              • Check the download page <http://geoserver.org/download/> for the desired series (development, stable or maintenance)

                                                              • Follow the nightly build links

                                                              • Check the community-latest folder

                                                              • Download the geoserver-<VERSION>-SNAPSHOT-opensearch-eo-plugin.zip file, and unzip its contents in the GeoServer unpacked WAR lib directory, e.g., \"geoserver/WEB-INF/lib\"

                                                              • Restart GeoServer

                                                                The GeoServer home page after the OpenSearch for EO module installation.

                                                              "},{"location":"community/opensearch-eo/intro/","title":"Introduction to OpenSearch for EO","text":"

                                                              This plugin adds support for the OpenSearch for Earth Observation protocol to GeoServer. References:

                                                              • OpenSearch
                                                              • OpenSearch parameter extension
                                                              • OpenSearch Geo and Time extension
                                                              • OpenSearch for Earth Observation

                                                              The OpenSearch plugin organizes data in \"Collections\" and \"Products\":

                                                              • A collection is a set of products with some uniformity, described by some search attributes and a ISO metadata sheet
                                                              • A product is a set of images (and ancillary information), describe by some search attributes and a O&M metadata sheet

                                                              The system allows the common EO \"two level\" searches, that is:

                                                              • Firsts lookup for the desired collection of data on the main OSDD document
                                                              • Once the collection is located, a second OSDD providing access to the product search is delivered

                                                              If the database contains also the OGC cross links, the Atom search outputs will also contain links allowing a client to jump from the data search to the actual data visualization and exploitation on OGC services.

                                                              "},{"location":"community/opensearch-eo/intro/#search-engine-storage","title":"Search engine storage","text":"

                                                              The OpenSearch protocol implementation relies on an extension of GeoTools DataAccess called OpenSearchAccess. At the time of writing a single implementation of such interface exists, called JDBCOpenSearchAccess, built and tested to work against a specific PostGIS database schema.

                                                              Note

                                                              The JDBCOpenSearchAccess is written in general enough terms that other databases should be usable as well, but it's likely some code improvements will be required to deal with certain databases naming restrictions (e.g., Oracle).

                                                              In the future we hope to see other implementations as well, based on storage that might be more suitable for large scale search engine such as SOLR or ElasticSearch.

                                                              "},{"location":"community/opensearch-eo/templates/","title":"OpenSearch/STAC JSON templates","text":"

                                                              General rules for writing the (Geo)JSON templates:

                                                              • Single // and multiline /* ... */ comments are allowed in the input, for the editor's convenience. and will be discarded in the output.
                                                              • The properties follow the same names as the OpenSearch queryables:
                                                                • If the column in the database has no prefix, use none in the template too (e.g. startTime).
                                                                • If the column has a prefix, it gets transformed, so for example, eoInstrument in the database becomes eo:instrument in the template.
                                                                • The \"eo\" prefix has a special rule, when it's used in the products table, it's called eop in the template. For example the column eoSensorMode in the products tables becomes eop:sensorMode.
                                                              • Two special CQL functions assist in the creation of links:
                                                                • serviceLink takes a URL template using the Java Formatter syntax and all the subsequent parameters are meant to be replaced in the template, one by one. This is used for links that are built on the fly based on product/collection attributes only.
                                                                • templateLink takes a URL template using a single ${BASE_URL} placeholder, and replaces it with the base URL of the request. This is already used by RSS output, and assumes the links are contained database fields, like the OGC links.

                                                              For information about building feature templates, refer to the features templating documentation.

                                                              "},{"location":"community/opensearch-eo/upgrading/","title":"Upgrading from previous version","text":""},{"location":"community/opensearch-eo/upgrading/#removal-of-htmldescription","title":"Removal of htmlDescription","text":"

                                                              Starting with version 2.20 the OpenSearch module dropped the HTML template columns in the database, and switched to freemarker templates instead. This relieves the database from a significant burden, especially on the products table.

                                                              The default templates are automatically used, and the old htmlDescription columns ignored (they should therefore be removed).

                                                              In order for the default collection.ftl to work, two new fields, title and description, should be added to the database structure, if not already present.

                                                              As a result of these changes, the REST resources previously used to manage the description templates have been removed, and residual HTML description templates included in product or collection zips will be ignored.

                                                              The replacement Freemarker templates are located in the data directory<oseo_html_templates> and can be thus managed via the /resource REST API.

                                                              "},{"location":"community/opensearch-eo/upgrading/#removal-of-collection_metadata-and-product_metadata","title":"Removal of collection_metadata and product_metadata","text":"

                                                              Starting with version 2.20 the OpenSearch module dropped the metadata storage tables from the database, and switched to freemarker templates instead. This relieves the database from a significant burden, especially on the products metadata table.

                                                              The default templates are automatically used, and the old metadata tables are ignored (they should therefore be removed).

                                                              As a result of these changes, the REST resources previously used to manage the metadata have been removed, and residual metadata xml files included in product or collection zips will be ignored.

                                                              The replacement Freemarker templates are located in the data directory<oseo_metadata_templates> and can be thus managed via the /resource REST API.

                                                              "},{"location":"community/pgraster/pgraster/","title":"PGRaster","text":"

                                                              The PGRaster geoserver module adds the ability to simplify the configuration of a PostGis Raster based ImageMosaic-JDBC store. Before proceeding, make sure to take a look to the PostGis Raster plugin documentation for background information. Note that configuration files, table creations and raster imports explained in that documentation, will be automatically handled by this module.

                                                              This module allows to do the following steps automatically:

                                                              1. use raster2pgsql (optionally) to import raster tiles previously configured with gdal_retile
                                                              2. create a metadata table (optionally) referring to tiles tables created through raster2pgsql
                                                              3. create the imageMosaic JDBC XML configuration containing PostGis database connection parameters, attributes mapping and coverage configuration.
                                                              4. configure the imageMosaic JDBC on top of the newly configured XML.
                                                              "},{"location":"community/pgraster/pgraster/#requirements","title":"Requirements","text":"
                                                              • You must have a PostGIS 2.0 database where your raster tiles will be stored.
                                                              • Raster tiles should have been previously created using gdal_retile since this module will simply import them and configure the store. The ImageMosaic JDBC setup example documentation provides examples of how to do that.
                                                              • In case you want to perform automatic import of the raster tiles into the database, you need to have raster2pgsql and psql executables installed on your machine and configured on your PATH. (In case your PostGIS 2.0 installation is on the same machine where you will run GeoServer, the executables should be already available).
                                                              "},{"location":"community/pgraster/pgraster/#installation","title":"Installation","text":""},{"location":"community/pgraster/pgraster/#download-the-pgraster-community-module-for-your-version-of-geoserver-from-the-pre-220-download-page-or-from-the-220-download-page","title":". Download the pgraster community module for your version of GeoServer from the pre 2.20 download page or from the 2.20+ download page.","text":"
                                                              1. Unzip the archive into the WEB-INF/lib directory of the GeoServer installation.

                                                                Note

                                                                On Windows, make sure to add a RASTER2PGSQL_PATH=Drive:\\Path\\to\\bin\\folder\\containing_raster2pgsqlExecutable property to the JAVA_OPTS as an instance: JAVA_OPTS=-DRASTER2PGSQL_PATH=C:\\work\\programs\\PostgreSQL\\9.2\\bin

                                                              2. Restart GeoServer.

                                                              "},{"location":"community/pgraster/pgraster/#usage","title":"Usage","text":"
                                                              1. As for any other store configuration, go to Stores->Add new Store

                                                              2. Select ImageMosaicJDBC. You will see the usual \"Add Raster Data Source\" form.

                                                                For backward compatibility, you may still configure an ImageMosaicJDBC in the old-way, by specifying the URL of a valid XML configuration file, as done in the past (Where all the components of the ImageMosaicJDBC need to be configured by hand by the user).

                                                              3. Notice the presence of a checkBox which allows to proceed with the PGRaster automatic configuration parameters specification. Once Clicking on it, you will see a set of new parameters for the automatic configuration step. When enabling that checkBox, the URL parameter needs to point to the main folder containing the rasters which have been previously produced using gdal_retile.

                                                                Other parameters are explained below:

                                                              Name Description PostGIS server The PostGIS server IP PostGIS port The PostGIS server port User The PostGIS DB user Password The PostGIS DB password Database The PostGIS Database (should have already been created) Schema The schema where the table will be created (default is public. The schema need to be already defined into the Database before the import) Table The name of the metadata table which contains all the references to File extension The extension of the raster files to be imported (such as png). It may not be specified when raster tiles have been already manually imported into the database by the user raster2pgsql import options The raster2pgsql script importing options (as an instance \"-t 128x128\" for raster tiles of 128x128). It may not be specified when raster tiles have been already manually imported into the database by the user EPSG Code The EPSG code which will be configured in the coverage configuration xml. (Default is 4326)"},{"location":"community/pgraster/pgraster/#limitations","title":"Limitations","text":"

                                                              Right now it doesn't allow to import data folders which have been created with the gdal_retile's useDirForEachRow option.

                                                              "},{"location":"community/proxy-base-ext/","title":"Proxy Base Extension","text":"

                                                              This extension allows the replacement of URLs in the response of a web service request with a different URL. This is useful in order to proxy a web service request to a different server, while still retaining the original URL in the response.

                                                              • Installing the Proxy Base extension
                                                              • Using the Proxy Base Extension module
                                                              "},{"location":"community/proxy-base-ext/install/","title":"Installing the Proxy Base extension","text":"

                                                              The Proxy Base extension is listed among the other extension downloads on the GeoServer download page.

                                                              The installation process is similar to other GeoServer extensions:

                                                              1. Visit the website download page, locate your release, and download: proxy-base-ext

                                                                Verify that the version number in the filename (for example 2.24.2 above) corresponds to the version of GeoServer you are running.

                                                              2. Extract the contents of the archive into the WEB-INF/lib directory in GeoServer. Make sure not to create any sub-directories during the extraction process.

                                                              3. Restart GeoServer.

                                                              On successful installation, a new Proxy Base Extension entry will appear in the left menu, under \"Settings\".

                                                              The Proxy Base Extension menu entry

                                                              "},{"location":"community/proxy-base-ext/usage/","title":"Using the Proxy Base Extension module","text":"

                                                              This extension allows the replacement of URLs in the response of a web service request with a different URL. This is useful in order to proxy a web service request to a different server, while still retaining the original URL in the response. An example of this is proxying a WMS request to a different server, but wanting to keep the original URL in the elements of the GetCapabilities response. E.g., rather than exposing WMS at: http://myserver/geoserver/wms The module allows exposing the service at: http://wms.mycompany.com/ and making sure all backlinks in the Capabilities document point to such host.

                                                              "},{"location":"community/proxy-base-ext/usage/#proxy-base-extension-rules","title":"Proxy Base Extension Rules","text":"

                                                              Proxy Base Extension rules allow the matching of the URLs for alteration based on their path elements and followed by the specification a replacement for the entire URL.

                                                              A Proxy Base Extension rule is defined by three mandatory attributes:

                                                              Attribute Description Position The priority of the rule, the lower the number the higher the priority. Rules are applied on a first match basis. Matcher The pattern used to match against paths. Regular expressions can be used to achieve matches. Transformer The transformation that will be applied to the entire URL. Literal expressions can be used to achieve transformations based on matching header values.

                                                              The following example shows a rule that will match any URL contains the substring wfs in the path (the example matcher value is .*/wfs) and replace the full URL (the example transformer value is https://wfs.eastern.com/${myCollection}/${yourFeature}) with https://wfs.eastern.com/ABigCollection/AnImportantFeature if the myCollection header is set to ABigCollection and the yourFeature header is set to AnImportantFeature. Note that if one or more of the headers referenced in the transformer by literal expressions are not present the rule will not be applied.

                                                              Example of a Proxy Base Extension rule:

                                                              Example of a Proxy Base Extension rule defined in the UI

                                                              This rule will transform the URL (when the myCollection and yourFeature headers are set):

                                                              http://localhost:8080/geoserver/wfs\n

                                                              to:

                                                              https://wfs.eastern.com/ABigCollection/AnImportantFeature\n
                                                              "},{"location":"community/proxy-base-ext/usage/#rules-management","title":"Rules Management","text":"

                                                              Rules can be managed and tested with simulated headers in the rules management UI. Besides the basic operations like add, remove and update is also possible to activate or deactivate rules. A deactivated rule will be ignored by this module.

                                                              Rules management UI

                                                              Attribute Description Position The priority of the rule, the lower the number the higher the priority. Rules are applied on a first match basis. Matcher The pattern used to match against paths. Regular expressions can be used to achieve matches. Transformer The transformation that will be applied to the entire URL. Literal expressions can be used to achieve transformations based on matching header values. Active When this box is checked, the rule will be applied. Edit Click to launch an editor for this specific rule. Input The input URL to be tested against the rules listed above. Headers If the rule to be tested has literal expressions, simulated headers for the test can be entered here in Properties File Format (equal sign separated, with each header on a new line). Output The result of applying the rules to the input URL will be displayed here after the Test button is clicked."},{"location":"community/proxy-base-ext/usage/#rest-api","title":"REST API","text":"

                                                              The rules can also be managed by means of a REST API found at geoserver/rest/proxy-base-ext. Documentation for it is available in Swagger format

                                                              "},{"location":"community/rat/","title":"Raster Attribute Table support","text":"

                                                              A GDAL Raster Attribute Table (RAT) is a data structure associated with a raster dataset, providing a way to associate attribute information for individual pixel values within the raster. Essentially, it acts as a tabular data structure that links each cell value in the raster to one or more attributes.

                                                              The RAT consists of rows and columns, where each row corresponds to a unique cell value in the raster, and each column represents a different attribute or property of those cells. These attributes can be numerical, categorical, text-based and may include information like land cover types, elevation values, or any other relevant data, but may also contain color information that can be used to render the raster in a more visually appealing way.

                                                              The RAT is stored in a separate file from the raster data itself, and is typically stored in a \".aux.xml\" file, as part of a a PAMDataset. Each of the bands in the PAM can contain a separate RAT, allowing for different attributes to be associated with each band.

                                                              One example of RAT usage is the NOAA Bluetopo dataset, which contains 3 floating points bands:

                                                              • The first band contains bathymetry data
                                                              • The second band contains a measure of uncertainty
                                                              • The third band, dubbed \"contributor\", links to a RAT that contains various information about the source of the data, such as the name of the source institution, the source license, date of survey, and more.

                                                              In this section:

                                                              • Installing the RAT module
                                                              • Using the RAT Module
                                                              "},{"location":"community/rat/installing/","title":"Installing the RAT module","text":"

                                                              To install the Raster Attribute Table support:

                                                              1. Download the rat community extension from the appropriate nightly build. The file name is called geoserver-*-rat-plugin.zip, where * matches the version number of GeoServer you are using.
                                                              2. Extract this these files and place the JARs in WEB-INF/lib.
                                                              3. Perform any configuration required by your servlet container, and then restart.
                                                              "},{"location":"community/rat/using/","title":"Using the RAT Module","text":"

                                                              The RAT modules adds facilities to explore a Raster Attribute Table, and generate styles based on a classification column of choice.

                                                              If the source raster contains a RAT, a new panel will appear in the Publishing tab of the layer.

                                                              The table allows for exploration of the attribute table, while the toolbar at the top allows to generate styles based on the table contents:

                                                              • The Band dropdown allows to select a raster band.
                                                              • The Classification dropdown allows to select a column to use for classification.
                                                              • The Style name controls the name of the style to be generated. It's automatically filled with a naming convention of <layer>_b<band>_<classification>, but can be customized.
                                                              • The Create style button generates the style based on the chosen classification, eventually using colors if available in the table, otherwise generating random colors. The geneated style will also be included among the \"alternate styles\" of the layer.

                                                              The generated style will match all the values in the raster attribute table, and ensure the chosen classification column is used for both styling, legend generation, and GetFeatureInfo output.

                                                              Here is an example style:

                                                              <?xml version=\"1.0\" encoding=\"UTF-8\"?><sld:StyledLayerDescriptor xmlns:sld=\"http://www.opengis.net/sld\" xmlns:gml=\"http://www.opengis.net/gml\" xmlns:ogc=\"http://www.opengis.net/ogc\" xmlns=\"http://www.opengis.net/sld\" version=\"1.0.0\">\n  <sld:NamedLayer>\n    <sld:Name>Class</sld:Name>\n    <sld:UserStyle>\n      <sld:Name>Class</sld:Name>\n      <sld:FeatureTypeStyle>\n        <sld:Rule>\n          <sld:Name>Class</sld:Name>\n          <sld:RasterSymbolizer>\n            <sld:ColorMap type=\"intervals\">\n              <sld:ColorMapEntry color=\"#000A64\" opacity=\"1.0\" quantity=\"-1.0E25\" label=\"zero\"/>\n              <sld:ColorMapEntry color=\"#641400\" opacity=\"1.0\" quantity=\"3.0E12\" label=\"one\"/>\n              <sld:ColorMapEntry color=\"#C81E32\" opacity=\"1.0\" quantity=\"1.0E20\" label=\"two\"/>\n              <sld:ColorMapEntry color=\"#FFFFFF\" opacity=\"0.0\" quantity=\"5.0E25\"/>\n            </sld:ColorMap>\n            <sld:VendorOption name=\"addAttributeTable\">true</sld:VendorOption>\n          </sld:RasterSymbolizer>\n        </sld:Rule>\n      </sld:FeatureTypeStyle>\n    </sld:UserStyle>\n  </sld:NamedLayer>\n</sld:StyledLayerDescriptor>\n

                                                              This is a map generated using the style, with the GetFeatureInfo containing the classification as an extra attribute:

                                                              "},{"location":"community/rat/using/#rest-api","title":"REST API","text":"

                                                              A REST API is available, to fetch the full PAM dataset attached to a raster, and to create styles out of RAT classfication fields:

                                                              • /rat
                                                              "},{"location":"community/remote-wps/","title":"WPS Remote community module","text":"

                                                              The GeoServer WPS remote module allows to discover, run and monitor processes running on one or more remote machines, exposing them via the WPS protocol and allowing both synchronous and asynchronous runs of the same, with eventual progress monitoring.

                                                              The remote process can be anything, from a Python script or a command line executable. The only constraint is to have a remote component able to handle few RPCs, like run, progress, complete (which means collect and send the outcome to the GeoServer machine), execution error (which means if any error occurs report the exception) and kill. On GeoServer side the module manages the same RPCs in order to perform the integration with the WPS. All the communications and command take place over the XMPP protocol, as a suitable cross-language communication system

                                                              A reference implementation of the remote end is available at https://github.com/geoserver/wps-remote, a configurable Python/XMPP wrapper for remote commands. The Python XMPP wrapper resides into the remote machine and is able to send a presentation of the remote process through an XMPP message by JSON-encoding into the body the process inputs/outputs parameter descriptors along with their type. On the GeoServer side the WPS Remote module automatically recognizes and loads an XMPP implementation of the RemoteClient. The GeoServer plugin is able to inquire for new available services, un-marshall their inputs and outputs and build appropriate process wrapper for GeoServer WPS to use. At execution time, the new Process is able to interact with the RemoteClient plug-in implementation in order to send a request to the Service.py, follow the status of the remote process and get the outputs at the end.

                                                              "},{"location":"community/remote-wps/#orchestrating-remote-executable-through-geoserver-wps-and-xmpp","title":"Orchestrating remote executable through GeoServer WPS and XMPP","text":"

                                                              The Remote WPS infrastructure is designed to run external programs asynchronously through the standard OGC WPS protocol interface on remote machines and to track their progress through the XMPP Protocols.

                                                              The infrastructure relies on an XMPP Server (which can be external or embedded) in order to implement a message passing distributed infrastructure that uses the XMPP protocols for exchanging control and status messages between the GeoServer instances and the executables running on remote machines.

                                                              A Python based framework, along with addoc GeoServer plugins, manages and translates the XMPP messages by decoupling the custom mechanism of launching external executables running on remote machines from the standard way of invoking OGC WPS compliant processes in GeoServer.

                                                              The OGC WPS process I/O map is automatically generated by the Remote WPS GeoServer plug-ins at runtime. Every time the framework recognizes a new external executable declared on the XMPP channel, the Remote WPS GeoServer plug-in creates the equivalent OGC WPS compliant interface and establishes the communication between GeoServer and the external executable. Every time a GeoServer user starts a new OGC WPS compliant process run, the infrastructure performs a call to the external executable and takes care of managing the communication between the two entities asynchronously.

                                                              The Remote WPS GeoServer plug-ins provide a new ProcessFactory which is responsible to register/unregister the OGC WPS compliant processes automatically and at runtime. Orchestration will be performed by the newly created GeoServer ProcessFactory upon a WPS execution request with the help of the XMPP Server which provides out-of-the-box nodes presence discovery and load balancing capabilities for the remote node through the interaction with the Python framework.

                                                              The orchestrator will also be responsible for redirecting the messages generated by running executables on the remote machines to the correct GeoServer process and vice versa for control messages. Executables running on the remote hosts through the Python framework wrappers, will generate progress information which will be sent back to the orchestrator via XMPP.

                                                              It is important to note that there are two levels of load balancing. One on the GeoServer side and one on the remote processing nodes side. The GeoServer load balancer will know which user has requested the processing and will be able to enforce system and resources limitations associated to it; as an instance, a user won't be able to run more than M processes in parallel and a quota for both the inputs and outputs will be assigned to its executions. The Orchestrator will be responsible, in cooperation with the XMPP service, for balancing the load for a certain executables on the remote hosts and for deciding where to send a new execution request in case a certain executable has been deployed on multiple remote machines.

                                                              Also note that the GeoServer instances comprising the cluster will share a specific directory where the WPS specific resources will be stored.

                                                              "},{"location":"community/remote-wps/#invoking-remote-processes-and-consuming-the-results","title":"Invoking remote processes and consuming the results","text":"

                                                              The executables on the remote hosts will be invoked through the command line by the Python framework wrappers in response to execution commands, received via the Orchestrator XMPP messages, as the result of a GeoServer WPS Execute call.

                                                              On the remote machines the Python framework wrappers and scripts will act as XMPP clients providing the ability to:

                                                              • launch command-line executables using the inputs provided by the end user from the GeoServer process orchestrator
                                                              • send back to the orchestrator status messages with the progress and status of the execution
                                                              • receive eventual control messages from the orchestrator to tentatively kill running executions
                                                              • perform clean-up operations like looking for zombie executions and killing them or removing stale files on the file system from old executions
                                                              • perform runtime discovery of new remote executable

                                                              The illustration below shows the interaction between the GeoServer Remote WPS plug-in and the Python framework wrappers. The whole communication is achieved through the XMPP protocols. The Python framework makes available a set of scripts and wrappers allowing to invoke the external executables and manage the entire execution by translating commands and outputs into XMPP messages to be sent and received by GeoServer.

                                                              As mentioned above the remote executables should adhere to a certain contract in order to fully support all these functionalities. As an example the ability to kill an existing execution heavily relies on the fact that the current process accounted for this functionality, otherwise we would have to try and kill it using operating system calls. This might require the end user to create wrappers around the legacy executables in certain cases.

                                                              Runtime discovery of new remote executable will be supported through adding new Properties files to a location known to the Python modules. A new OGC WPS compliant process will be directly exposed to GeoServer without restarting the GeoServer itself for the new remote executable since the Python wrappers will communicate the existence of a new executable by interacting with the GeoServer Orchestrator via XMPP messages. The end user will see as many OGC WPS compliant processes as properties configuration files on the remote machines thanks to the functionalities implemented by the Python framework scripts.

                                                              An example of such a properties file can be like below:

                                                              [Description]\nservice = Service\nnamespace = default\ndescription = A dummy service, replace with your own description\nexecutable = process.py\nprocess_buffer = 0\nresult_size = 0\nactive = True\n\n[Options]\ncustomargs = --path=D:\\user\\\nargformat = --key=value\ndebug = True\n\n[Input]\nname = {\"type\": \"string\", \"description\": \"A person name\", \"enum\": [\"Hans\", \"Peter\", \"Alex\", \"Michi\"],\n\"default\": \"Hans\", \"max\": 1}\nsurname = {\"type\": \"string\", \"description\": \"A persons surname\", \"max\": 1, \"default\": \"Meier\"}\nchild = {\"type\": \"string\", \"description\": \"A child name\", \"min\": 0, \"max\": 10}\n\n[Output]\nwelcome = {\"type\": \"string\", \"description\": \"A welcome message\"}\ngoodbye = {\"type\": \"string\", \"description\": \"A goodbye message\"}\n

                                                              Warning

                                                              the configuration above is a simplified and non-working example of a Remote Process wrapper configuration. The scope of the example above is just for better understand of the high-level scenario and is not meant to be used in a real use case.

                                                              "},{"location":"community/remote-wps/#deploy-diagram","title":"Deploy Diagram","text":"

                                                              The illustration shows a deploy diagram of a Change Detection executable running on a remote machine and exposed as a GeoServer WPS Process thought the WPS Remote Plug-in.

                                                              • The external users issue a processing request through GeoServer using the OGC WPS compliant protocol.
                                                              • The GeoServer Remote WPS plug-in, thanks to the WPS RemoteProcessFactory, will be able to expose the processes I/O map along with the process descriptors, and take care of the entire execution by providing feedbacks to the users in an OGC compliant way.
                                                              • On the remote machines, where the executables rely and where the real computation takes place, the Python framework, through the use of wrappers and ad h.o.c. scripts, handles transparently the communication with the Remote plug-in through the XMPP protocols.
                                                              • The XMPP Server, in the middle, handles the secured communication channels ensuring that the endpoints are correctly registered to the system and are able to exchange messages.
                                                              • The outcomes are exchanged through a shared folder.
                                                              "},{"location":"community/remote-wps/#installation-and-configuration-steps","title":"Installation and Configuration Steps","text":"

                                                              The following sections will guide the user to the deployment and configuration of an example GDAL CONTOUR command exposed as a GeoServer WPS Process through the WPS Remote Plugin.

                                                              The examples will show step-by-step procedures to configure and deploy the whole example on two different machines:

                                                              • Commands to deploy GeoServer with the WPS Remote Plug-in and an OpenFire XMPP Server, will be executed on a CentOS Minimal machine
                                                              • Commands to deploy the WPS Remote XMPP Python Wrapper and GDAL, will be executed on a Windows 7+ machine
                                                              • Deployment And Setup Of GeoServer With WPS Remote Plugin
                                                              • Installation Of OpenFire XMPP Server To Exchange Messages
                                                              • Deployment And Setup Of The XMPP Python Wrappers
                                                              • A Remote \"Gdal Contour\" Process Binding Example
                                                              "},{"location":"community/remote-wps/install_geoserver/","title":"Deployment And Setup Of GeoServer With WPS Remote Plugin","text":"

                                                              The following commands will prepare a CentOS 7 Minimal ISO machine for the deployment of:

                                                              • GeoServer with the following plugins:

                                                                • GeoServer WPS
                                                                • GeoServer Remote WPS Orchestrator
                                                                • GeoServer Importer

                                                              The OS iso has been downloaded from::

                                                              http://isoredirect.centos.org/centos/7/isos/x86_64/CentOS-7-x86_64-Minimal-1503-01.iso\n
                                                              "},{"location":"community/remote-wps/install_geoserver/#preparation-of-the-system-standard-and-basic-os-packages","title":"Preparation of the system: standard and basic OS packages","text":""},{"location":"community/remote-wps/install_geoserver/#hostname-and-other-useful-packages","title":"Hostname and other useful packages","text":"

                                                              Update the file /etc/hosts making sure that the ip addresses matches the name of the machine.

                                                              # as root\n\n$> yum -y install man vim openssh-clients mc zip unzip wget net-tools\n
                                                              "},{"location":"community/remote-wps/install_geoserver/#configure-the-java-virtual-environment","title":"Configure the Java Virtual Environment","text":"
                                                              # as root\n\n$> wget --no-check-certificate --no-cookies --header \"Cookie: oraclelicense=accept-securebackupcookie\" http://download.oracle.com/otn-pub/java/jdk/8u65-b17/jdk-8u74-linux-x64.tar.gz\n\n$> tar xzvf jdk-8u65-linux-x64.tar.gz\n$> mkdir /usr/java\n$> mv jdk1.8.0_65/ /usr/java/\n\n$> alternatives --install /usr/bin/java java /usr/java/jdk1.8.0_65/bin/java 20000\n\n$> alternatives --install /usr/bin/javac javac /usr/java/jdk1.8.0_65/bin/javac 20000\n\n$> alternatives --install /usr/bin/jar jar /usr/java/jdk1.8.0_65/bin/jar 20000\n\n$> alternatives --install /usr/bin/javaws javaws /usr/java/jdk1.8.0_65/bin/javaws 20000\n\n$> alternatives --set java /usr/java/jdk1.8.0_65/bin/java\n$> alternatives --set javac /usr/java/jdk1.8.0_65/bin/javac\n$> alternatives --set jar /usr/java/jdk1.8.0_65/bin/jar\n$> alternatives --set javaws /usr/java/jdk1.8.0_65/bin/javaws\n\n# Verify the proper installation on the JDK\n\n$> java -version\n  java version \"1.8.0_65\"\n  Java(TM) SE Runtime Environment (build 1.8.0_65-b17)\n  Java HotSpot(TM) 64-Bit Server VM (build 25.65-b01, mixed mode)\n\n$> javac -version\n  javac 1.8.0_65\n
                                                              "},{"location":"community/remote-wps/install_geoserver/#installing-apache-tomcat","title":"Installing Apache Tomcat","text":"
                                                              # as root\n\n$> yum -y install tomcat-webapps\n$> systemctl disable tomcat.service\n\n$> cp /etc/sysconfig/tomcat /etc/sysconfig/geoserver\n$> ln -s /usr/share/tomcat/ /opt/tomcat\n

                                                              Creating apache tomcat HOME context

                                                              Creating base template directory

                                                              # as root\n\n$> mkdir -p /var/lib/tomcat/geoserver/{bin,conf,logs,temp,webapps,work}\n\n$> cp -Rf /opt/tomcat/conf/* /var/lib/tomcat/geoserver/conf/\n

                                                              Creating geoserver apache tomcat BASE context

                                                              Make sure you already:

                                                              • installed tomcat (Installing apache tomcat)
                                                              • created the base catalina template (Creating apache tomcat HOME context)

                                                              Edit server.xml file

                                                              GeoServer is the first tomcat instance we are installing in this VM, so we can keep the default ports:

                                                              • 8005 for commands to catalina instance
                                                              • 8009 for the AJP connection port
                                                              • 8080 for the HTTP connection port

                                                              Remember that you may change these ports in the file /var/lib/tomcat/geoserver/conf/server.xml

                                                              Final configurations

                                                              Set the ownership of the geoserver/ related directories to user tomcat

                                                              # as root\n\n$> chown tomcat: -R /var/lib/tomcat/geoserver\n$> cp /etc/tomcat/tomcat.conf /etc/tomcat/geoserver.conf\n\n$> vi /etc/tomcat/geoserver.conf\n\n  # This variable is used to figure out if config is loaded or not.\n  TOMCAT_CFG_LOADED=\"1\"\n\n  # In new-style instances, if CATALINA_BASE isn't specified, it will\n  # be constructed by joining TOMCATS_BASE and NAME.\n  TOMCATS_BASE=\"/var/lib/tomcats/\"\n\n  # Where your java installation lives\n  #JAVA_HOME=\"/usr/lib/jvm/jre\"\n  JAVA_HOME=\"/usr/java/jdk1.7.0_71\"\n\n  # Where your tomcat installation lives\n  CATALINA_HOME=\"/usr/share/tomcat\"\n  CATALINA_BASE=\"/var/lib/tomcat/geoserver\"\n  CATALINA_PID=$CATALINA_BASE/work/pidfile.pid\n\n  # System-wide tmp\n  CATALINA_TMPDIR=\"/var/cache/tomcat/temp\"\n\n  # You can pass some parameters to java here if you wish to\n  #JAVA_OPTS=\"-Xminf0.1 -Xmaxf0.3\"\n  # Use JAVA_OPTS to set java.library.path for libtcnative.so\n  #JAVA_OPTS=\"-Djava.library.path=/usr/lib\"\n  JAVA_OPTS=\"-server -XX:SoftRefLRUPolicyMSPerMB=36000 -Xms1024m -Xmx2048m\n  -XX:PermSize=64m -XX:+UseConcMarkSweepGC -XX:NewSize=48m -DGEOSERVER_DATA_DIR=/storage/data/\n  -DENABLE_ADVANCED_PROJECTION=false -Dorg.geotools.shapefile.datetime=true -Duser.timezone=GMT\n  -Dorg.geotools.filter.function.simplify=true -DGEOMETRY_COLLECT_MAX_COORDINATES=50000\"\n\n  # You can change your tomcat locale here\n  #LANG=\"en_US\"\n  # Run tomcat under the Java Security Manager\n  SECURITY_MANAGER=\"false\"\n\n$> cp /usr/lib/systemd/system/tomcat.service /usr/lib/systemd/system/geoserver.service\n\n$> vi /usr/lib/systemd/system/geoserver.service\n\n  EnvironmentFile=/etc/tomcat/geoserver.conf\n\n$> systemctl enable geoserver.service\n$> systemctl restart geoserver.service\n\n# Follow the server startup procedure and make sure everything goes smoothly through the following command\n\n$> tail -F /var/lib/tomcat/geoserver/logs/catalina.YYYY-MM-DD.log\n
                                                              "},{"location":"community/remote-wps/install_geoserver/#deploy-and-configure-geoserver","title":"Deploy And Configure GeoServer","text":"

                                                              First deployment

                                                              # as root\n\n# Git and Maven must be installed on the system\n$> yum -y install git\n$> yum -y install maven\n\n# Verify the Maven installation and double check that the JDK recognized is the Java Sun 1.7+\n$> mvn -version\n\n  Apache Maven 3.0.5 (Red Hat 3.0.5-16)\n  Maven home: /usr/share/maven\n  Java version: 1.8.0_65, vendor: Oracle Corporation\n  Java home: /usr/java/jdk1.8.0_65/jre\n  Default locale: en_US, platform encoding: UTF-8\n  OS name: \"linux\", version: \"3.10.0-229.el7.x86_64\", arch: \"amd64\", family: \"unix\"\n\n# The following procedures allow to collect and compile the source code from the GIT repository.\n$> cd\n\n$> git clone https://github.com/geosolutions-it/geoserver.git geoserver.src\n\n$> cd geoserver.src/src\n\n$> git checkout wps-remote\n$> git pull\n\n$> mvn clean install -Pwps,wps-remote,importer,security,rest-ext -DskipTests\n\n$> mv web/app/target/geoserver.war /var/lib/tomcat/geoserver/webapps/\n\n$> chown -Rf tomcat: /var/lib/tomcat/geoserver\n\n$> mv /var/lib/tomcat/geoserver/webapps/geoserver/data/ /storage/\n\n$> chown -Rf tomcat: /storage\n\n$> vim /storage/data/remoteProcess.properties\n\n  # Default Properties\n  remoteProcessStubCycleSleepTime = 100\n\n  # Base path where uploaded files are stored\n  # . This is used only when a remote uploader is enabled on the Python\n  # . WPS Agent. This property represents the local base path (on the filesystem\n  # . of GeoServer) where to search for uploaded files.\n  # . If not file has been found here (or this option is not enabled), GeoServer\n  # . looks for absolute path and/or paths relative to the GEOSERVER DATA DIR.\n  #uploadedFilesBasePath = /tmp\n\n  # Full path to the template used to generate the OWS WMC Json output\n  # . This property is used only when a \"application/owc\" output type on\n  # . the Python WPS Agent.\n  #owc_wms_json_template = absolute_path/to/wmc_template.json\n\n  # Specific kvps for {@link RemoteProcessClient) implementations\n  xmpp_server = localhost\n  xmpp_server_embedded = false\n  xmpp_server_embedded_secure = true\n  xmpp_server_embedded_certificate_file = bogus_mina_tls.cert\n  xmpp_server_embedded_certificate_password = boguspw\n  xmpp_port = 5222\n\n  xmpp_manager_username = admin\n  xmpp_manager_password = R3m0T3wP5\n\n  # domain and MUC service name of the XMPP Server\n  xmpp_domain = geoserver.org\n  xmpp_bus = conference\n\n  # name, user and password of the management room\n  xmpp_management_channel = management\n  xmpp_management_channel_user = admin\n  xmpp_management_channel_pwd = R3m0T3wP5\n\n  # comma separated list of available rooms for services. Those rooms'names will be equal to the service and WPS Process namespace\n  # Avoid spaces\n  xmpp_service_channels = default,geosolutions\n\n  # millis\n  xmpp_packet_reply_timeout = 500\n\n  # connection keep alive\n  xmpp_connection_ping_interval = 30000\n  xmpp_connection_ping_timeout = 10000\n  xmpp_connection_ping_initial_delay = 20000\n\n  # Thresholds indicating overloaded resources\n  xmpp_cpu_perc_threshold = 82.5\n  xmpp_mem_perc_threshold = 84.6\n\n# Restart GeoServer\n\n$> service geoserver restart\n

                                                              Warning

                                                              GeoServer won't connect to XMPP Server until it has been correctly configured and started as explained in the next section Installation Of OpenFire XMPP Server To Exchange Messages.

                                                              "},{"location":"community/remote-wps/install_python/","title":"Deployment And Setup Of The XMPP Python Wrappers","text":""},{"location":"community/remote-wps/install_python/#remote-wps-python-wrapper-framework","title":"Remote WPS Python Wrapper Framework","text":"

                                                              The Remote WPS Python framework source code is available on a public GitHub Repository of GeoSolutions S.A.S.

                                                              Users can install the \"wps-remote\" Python package by using the PyPi distribution :

                                                              pip install wps-remote==2.11.0\n

                                                              The source code repository is available at the following address:

                                                              https://github.com/geoserver/wps-remote

                                                              The source code is available on the main development (main) branch.

                                                              "},{"location":"community/remote-wps/install_python/#how-the-system-works","title":"How The System Works","text":"

                                                              This setup will configure the Remote WPS Python Wrapper to launch a Python executable called test.py that performs a gdal_contour on a GeoTIFF DEM.

                                                              The test.py executable takes in input just two parameters:

                                                              • -i; \"--interval\", nargs='?', default=\"10\", help=\"Elevation interval between contours.\"
                                                              • -w; \"--workdir\", nargs='?', default=\"\", help=\"Remote process sandbox working directory.\"

                                                              The paths of the command line and GeoTIFF to process (provided with the source code as sample data), are hard-coded into the Python code and must be changed accordingly to the system settings as explained later in the docs:

                                                              • gdalContour = r'/usr/bin/gdal_contour'
                                                              • src = r'/share/xmpp_data/resource_dir/srtm_39_04/srtm_39_04_c.tif'

                                                              The assumptions are that during the execution, the algorithms send logging and progress info to the standard output in a form similar to the following one:

                                                              2016-02-15 15:18:03,594 - main.create_logger - [INFO] ProgressInfo:100%\n

                                                              The log format has been configured through the logger_test.properties file:

                                                              [loggers]\nkeys=root\n\n[handlers]\nkeys=consoleHandler\n\n[formatters]\nkeys=simpleFormatter\n\n[logger_root]\nlevel=DEBUG\nhandlers=consoleHandler\n\n[handler_consoleHandler]\nclass=StreamHandler\nlevel=DEBUG\nformatter=simpleFormatter\nargs=(sys.stdout,)\n\n[formatter_simpleFormatter]\nformat=%(asctime)s - %(name)s - [%(levelname)s] %(message)s\ndatefmt=\n

                                                              The role of the Remote WPS Python wrapper is to take care of the communication between GeoServer WPS and the test.py executable.

                                                              The Python wrapper must be configured by specifying the number and type of input and output parameters of the executable, other than the connection parameter of the remote XMPP Server. The Python wrapper knows how to invoke the executables from the command line and how to parse and interpret the logging information thanks to some properties files containing a set of regular expressions which will be presented in details further in this document.

                                                              There must be a running instance of the Python wrapper for each executable, every one with its own specific configuration and XMPP user. The wrapper instances will connect automatically to the XMPP Server and GeoServer will send an \"invite\" message as soon it recognizes a new authenticated user appearing on the XMPP communication channels. In order to register the WPS Process into the GeoServer through the Remote Process Factory, the Python wrapper must reply to the invitation with a \"register\" message containing all the details about the I/O params of the executable. All those passages are managed automatically and transparently to the users by the Remote WPS Python framework.

                                                              Every time a user issues a new GeoServer WPS execute request, the Python wrapper starts a new thread calling the executables with the input parameters coming from GeoServer itself. The two running instances are connected through a unique \"process execution ID\" generated by GeoServer Remote Process Factory.

                                                              From now on, the Python wrapper thread follows the entire execution and takes care of sending feedbacks and logging information to the GeoServer Remote Process Factory, which are translated and forwarded to the GeoServer WPS Execution Manager. From the outside the users will experience a standard execution of an OGC WPS compliant process.

                                                              "},{"location":"community/remote-wps/install_python/#summary-of-the-configuration-steps","title":"Summary Of The Configuration Steps","text":"

                                                              Connecting a new executable instance to GeoServer through the Python wrapper requires few configuration steps summarized here below:

                                                              1. Clone a structure of .properties files containing:
                                                                • The connection parameter to the XMPP Server
                                                                • The descriptor of the executable command line
                                                                • The descriptor of the process I/O parameters
                                                                • The logging informations
                                                              2. Update the remote.config file with the correct XMPP Server information:
                                                                • Provide remote host and port parameters
                                                                • Provide domain and XMPP communication secured channels details
                                                                • Provide pointers to the shared folder
                                                              3. Update the logger.properties file with the full path to the service.log file.

                                                              4. Update the service.config file with the executables parameters:
                                                                • The service name and the namespace
                                                                    !!! note\n\n        there must exist an user on the XMPP Server named as `namespace.serviceName` and a communication channel with the same identified of the service namespace.\n\n        e.g.:\n\n        -   service = gdalContour\n        -   namespace = default\n\n        means that on the XMPP Server we are looking for a communication channel named `default` and we will try to connect with the username `default.gdalContour`.\n\n        Both of them must be defined before running the Python wrapper daemon.\n\n-   The description of the service and the full path to the main executable\n\n-   Other secondary parameters like the local output folder (where to store temporary results of the execution) and the max running time\n\n-   The description of the Inputs and the actions to be taken\n\n-   The description of the Outputs and the actions to be taken\n\n-   The description of the logging information and the actions to be taken\n
                                                              "},{"location":"community/remote-wps/install_python/#installation-and-configuration-steps","title":"Installation and Configuration Steps","text":""},{"location":"community/remote-wps/install_python/#basic-environment-preparation","title":"Basic Environment Preparation","text":"

                                                              The following commands will prepare a MS Windows 7+, Windows 2008+ Server ISO machine for the deployment of:

                                                              1. Remote WPS Python wrapper
                                                              2. Sample configuration and testing of a sample executable test.py running the gdal_contour on a GeoTIFF DEM

                                                              Preparation of the system: standard and basic OS packages

                                                              Python

                                                              The system requires Python 2.7.9+ with few packages in order to work correctly. The installation of Python on a Windows system is quite fast

                                                              # as administrator\n\n#.1 Download the Python 2.7.9 installation package from the browser, choosing the best suitable distribution accordingly to the OS\n\n  https://www.python.org/downloads/release/python-279/\n\n#.2 Define the following System Environment Variables\n\nPATH=%PATH%;C:\\Python27;C:\\Python27\\Scripts\nPYTHONPATH=.\\;C:\\Python27;C:\\work\\RemoteWPS\n

                                                              Other Mandatory Python Packages

                                                              # as administrator\n\n# From a Command Line prompt\n\n$> pip install wps-remote==2.11.0\n

                                                              Configure the RemoteWPS Environment

                                                              NFS Shared Folder

                                                              Link the shared folder to the C:/share through the NFS protocol. This is possible simply by turning on the NFS Services of the MS Windows functionalities and creating a client NFS connection to the NFS server.

                                                              Warning

                                                              \"Services for NFS\" have been removed on Windows 10. They are available only on Windows 10 Enterprise edition. For older Windows versions you can use the following procedure in order to enable NFS Client

                                                              Installing the client

                                                              1. Go to Control Panel \u2192 Programs \u2192 Programs and Features
                                                              2. Select: Turn Windows features on or off\" from the left hand navigation.
                                                              3. Scroll down to \"Services for NFS\" and click the \"plus\" on the left
                                                              4. Check \"Client for NFS\"
                                                              5. Select \"Ok\"
                                                              6. Windows should install the client. Once the client package is install you will have the \"mount\" command available.

                                                              Mounting the export

                                                              This assumes the following:

                                                              • You know and can ping the hostname of the machine with the NFS exports
                                                              • The name of the exported filesystem ( eg. /export, /home/users, /some/cool/file/path )
                                                                • Open a command prompt. ( Win + R, enter \"cmd\" and press OK )

                                                                The file systems are properly exported and accessible

                                                                • Type:

                                                                  mount \\\\{machinename}\\{filesystem} {driveletter}

                                                              Examples:

                                                              mount \\\\filehost\\home\\users H:\nmount \\\\server1234\\long\\term\\file\\storage S:\nmount \\\\nas324\\exports E:\n

                                                              Note

                                                              It is important that the shared folder structure is fully replicated on the Windows machine and the folder writable by the Windows processes.

                                                              | /share\n|\n|-- xmpp_data\n|\n|-- -- output\n|\n|-- -- resource_dir\n
                                                              "},{"location":"community/remote-wps/install_python/#first-deploy-of-the-remotewps-python-framework","title":"First Deploy Of The RemoteWPS Python Framework","text":"

                                                              The wps-remote WHL archive contains a folder with a sample configuration :

                                                              xmpp_data\n

                                                              Extract this folder and proceed with the next steps.

                                                              The files can also be downloaded from the GitHub source repository.

                                                              To clone the RemoteWPS Python Framework into a working folder, e.g.:

                                                              $> cd C:\\work\n\n$> git clone https://github.com/geoserver/wps-remote RemoteWPS\n

                                                              Setting Up The remote.config

                                                              # Edit the file xmpp_data/configs/remote.config\n\n  [DEFAULT]\n\n  bus_class_name = xmppBus.XMPPBus\n\n  port = 5223\n  address =  127.0.0.1\n  domain = geoserver.org\n\n  # . Those are the connection parameters to the XMPP Server.\n  # . The user must exists on the Server and its name must be\n  # . equal to the service name.\n  user = default.GdalContour\n  password = R3m0T3wP5\n\n  mucService = conference.%(domain)s\n  mucServicePassword = admin\n\n  resource_file_dir = /share/xmpp_data/resource_dir\n\n  # . Configure this option (along with 'backup_on_wps_execution_shared_dir' \n  # . on single outputs of 'service.config') in order to make a copy\n  # . of the results into a shared folder before sending messages to XMPP\n  # . WARNING: this option takes precedence on \"UPLOADER\" option\n  # wps_execution_shared_dir = /share/xmpp_data/share\n\n  # . This section is used to configure the uploader class and connection\n  # . parameters.\n  # . This is necessary in order to let the 'upload_data' option work on\n  # . single outputs of 'service.config'\n  [UPLOADER]\n  # There are different implementations of the FTP Uploader available right now:\n  # . Plain standard FTP Protocol (based on ftplib)\n  #       ftpUpload.FtpUpload\n  # . FTP over TLS (FTPS) Protocol (based on ftplib)\n  #       ftpsUpload.FtpsUpload\n  # . S-FTP Protocol (based on paramiko Python lib)\n  #       sftpUpload.SFtpUpload\n  uploader_class_name = ftpUpload.FtpUpload\n  uploader_host = ftp.<your_host_here>:<your_port_here_default_21>\n  uploader_username = <ftp_username>\n  uploader_password = <ftp_password_encrypted>\n\n  # . \"encryptor\" you can use encrypted passwords with a private/public key couple\n  #\n  # . To generate a new private key use the following command:\n  #     openssl genrsa -out myTestKey.pem -passout pass:\"f00bar\" -des3 2048\n  #\n  # . To generate a new public key use the following command:\n  #     openssl rsa -pubout -in myTestKey.pem -passin pass:\"f00bar\" -out myTestKey.pub\n  #\n  # . To encrypt your password use the following utility\n  #     python encrypt.py password path/to/rsakey.pub passphrase\n  #\n  # . To double check the password is correct use the following utility\n  #     python decrypt.py password path/to/rsakey.pem passphrase\n  uploader_private_rsa_key = /share/xmpp_data/ssl/myTestKey.pem\n  uploader_passphrase = f00bar\n

                                                              The requisites for this configuration to work properly are:

                                                              1. Make sure the <XMPP_server_ip_address> is reachable and the port 5223 is allowed by the Firewall
                                                              2. Make sure the default.GdalContour user exists into the XMPP Server and that the password is correct

                                                              1. The MUC Service and the MUC Service Password are correct
                                                              2. The resource dir and the shared folder exists and are writable

                                                              Setting Up The logger.properties

                                                              # Edit the file xmpp_data/configs/logger.properties\n\n[loggers]\nkeys=root\n\n[handlers]\nkeys=consoleHandler,file\n\n[formatters]\nkeys=simpleFormatter,consoleFormatter\n\n[logger_root]\nlevel=DEBUG\nhandlers=file, consoleHandler\n\n[handler_consoleHandler]\nclass=StreamHandler\nlevel=DEBUG\nformatter=consoleFormatter\nargs=(sys.stdout,)\nfilter=\n\n[handler_file]\nclass=handlers.TimedRotatingFileHandler\ninterval=midnight\nbackupCount=5\nformatter=simpleFormatter\nlevel=DEBUG\nargs=('/share/xmpp_data/service.log',)\n\n[formatter_simpleFormatter]\nformat=%(asctime)s - %(name)s - %(levelname)s - %(message)s\ndatefmt=\n\n[formatter_consoleFormatter]\nformat=%(asctime)s [%(levelname)s] %(message)s\ndatefmt=\n

                                                              The requisites for this configuration to work properly are:

                                                              1. Make sure the \"C:/share/xmpp_data/\" exists and is writable

                                                              Setting Up The service.config

                                                              # Edit the file xmpp_data/configs/myservice/service.config\n\n  # This is a INI file to be read with python ConfigParser (https://docs.python.org/2/library/configparser.html)\n  # Is possible to reference another variable in the ini file using the format %(<variable name>)s (note the 's' at the end)\n\n  # ########################################### #\n  # Default Service Params                      #\n  # ########################################### #\n\n  [DEFAULT]\n  service = GdalContour\n  namespace = default\n  description = GDAL Contour Remote Service\n  executable_path = /share/xmpp_data/configs/myservice/code\n  executable_cmd = python %(executable_path)s/test.py\n  output_dir = /share/xmpp_data/output/\n  unique_execution_id = %(unique_exe_id)s\n  workdir = %(output_dir)s/%(unique_execution_id)s\n  active = True\n  max_running_time_seconds = 300\n\n  # . This option allows you to set the CPU and Memory average load scan time.\n  # . It is espressed in 'minutes' and if disabled here it will be set by default\n  # . to 15 minutes.\n  load_average_scan_minutes = 1\n\n  # . Use this option to completely avoid using this host (and prevent starting a new\n  # . 'processbot') whenever one of the following process names are running.\n  # . In other words, if one of the following processes are currently running on this machine,\n  # . GeoServer won't send any WPS execute request until they are finished.\n  process_blacklist = [resource consuming process name1, resource consuming process name2]\n\n  # ########################################### #\n  # Inputs and Actions Declaration              #\n  # ########################################### #\n\n  [Input1]\n  class = param\n  name = interval\n  title = Elevation Interval\n  type = int\n  description = Elevation interval between contours.\n  min = 1\n  max = 1\n  default = 200\n\n  [Action1]\n  class = cmdline\n  input_ref = interval\n  alias = i\n  template = -name value\n\n  [Const1]\n  class = const\n  name = workdir\n  type = string\n  description = Remote process sandbox working directory\n  value = %(workdir)s\n\n\n  [Action2]\n  class = cmdline\n  input_ref = workdir\n  alias = w\n  template = -name value\n\n  # ########################################### #\n  # Output Parameters Declaration               #\n  # ########################################### #\n\n  [Output1]\n  name = result1\n  type = application/zip\n  description = WPS Resource Binary File\n  title = SRTM\n  filepath = %(workdir)s/contour.zip\n  publish_as_layer = true\n  publish_default_style = polygon\n  publish_target_workspace = it.geosolutions\n  publish_layer_name = contour\n\n  # . Enable this option in order to perform a backup of this output\n  # . before sending it to GeoServer.\n  # . WARNING: This option works only along with 'wps_execution_shared_dir'\n  # .          option on 'remote.config', and takes precedence on 'upload_data'\n  # backup_on_wps_execution_shared_dir = true\n\n  # . Enable this option if you want the output to be uploaded on remote host.\n  # . Notice that you must also configure uploader parameters on 'remote.config'\n  # upload_data = true\n\n  # . Optionally it is possible to specify a root folder if the uploader class supports it.\n  # upload_data_root = /remote-wps/default\n\n  [Output2]\n  name = result2\n  type = application/x-netcdf\n  description = NetCDF Binary File\n  title = flexpart\n  filepath = %(output_dir)s/flexpart.nc\n  publish_as_layer = true\n  publish_default_style = raster\n  publish_target_workspace = it.geosolutions\n  publish_layer_name = flexpart\n\n  # . Enable this option in order to perform a backup of this output\n  # . before sending it to GeoServer.\n  # . WARNING: This option works only along with 'wps_execution_shared_dir'\n  # .          option on 'remote.config', and takes precedence on 'upload_data'\n  # backup_on_wps_execution_shared_dir = true\n\n  # . Enable this option if you want the output to be uploaded on remote host.\n  # . Notice that you must also configure uploader parameters on 'remote.config'\n  # upload_data = true\n\n  # . Optionally it is possible to specify a root folder if the uploader class supports it.\n  # upload_data_root = /remote-wps/default\n\n  [Output3]\n  name = result3\n  type = application/owc\n  description = WPS OWC Json MapContext\n  layers_to_publish = result2\n  publish_as_layer = true\n  publish_layer_name = owc_json_ctx\n  publish_metadata = /share/xmpp_data/resource_dir/owc_json_ctx.json\n\n  # ########################################### #\n  # Logging Options Declaration                 #\n  # ########################################### #\n\n  [Logging]\n  stdout_parser = [.*\\[DEBUG\\](.*), .*\\[INFO\\] ProgressInfo\\:([-+]?[0-9]*\\.?[0-9]*)\\%, .*\\[(INFO)\\](.*), .*\\[(WARN)\\](.*), .*\\[(ERROR)\\](.*), .*\\[(CRITICAL)\\](.*)]\n  stdout_action = [ignore,          progress,                                          log,              log,              abort,               abort]\n

                                                              The requisites for this configuration to work properly are:

                                                              1. Make sure the default.GdalContour user exists into the XMPP Server and that the password is correct

                                                              2. Make sure the default channel exists on the XMPP Server

                                                              3. Make sure the executable path and command are correct

                                                              4. Make sure the output_dir exists and is writable

                                                              5. Make sure the max_running_time_seconds have been set to a value high enough to allow the executables to complete the jobs.

                                                                The GeoServer instance must also respect the WPS execution timings which must be configured accordingly. In order to do that access to the GeoServer Web Admin GUI.

                                                                http://host:8080/geoserver/web/

                                                                login as administrator (default credentials are admin/geoserver which should be changed anyway).

                                                                From the Web Processing Service settings page

                                                                The timeouts and the number of parallel executions (both async and sync) must be tuned accordingly to the execution needs.

                                                              6. Make sure the inputs have been configured correctly for the command line execution

                                                                [Input1]\nclass = param\nname = interval\ntitle = Elevation Interval\ntype = int\ndescription = Elevation interval between contours.\nmin = 1\nmax = 1\ndefault = 200\n\n[Action1]\nclass = cmdline\ninput_ref = interval\nalias = i\ntemplate = -name value\n

                                                                The configuration above sets an input of type int (the expected value will be interpreted as text and declared as Literal to the WPS), which is mandatory (min = 1) and can have a single value (max = 1).

                                                                The [Action1] is connected to the input through the input_ref which is equal to the [Input1].name.

                                                                In the example above the action simply gets the input value specified by the user and forward it to the command line.

                                                                The final result will be something lihe this:

                                                                $> /work/RemoteWPS/xmpp_data/configs/myservice/code/test.py <input_value_here>\n

                                                                The [Action1].template property allows to specify the name of the option if required by the executable.

                                                                As an instance the following value for the [Action1].template:

                                                                alias = i\ntemplate = -name value\n

                                                                will result in something like this:

                                                                $> /work/RemoteWPS/xmpp_data/configs/myservice/code/test.py -i <input_value>\n

                                                                There exists other types of input and actions.

                                                                As an instance it is possible to specify constant input types like the following one:

                                                                [Const1]\nclass = const\nname = workdir\ntype = string\ndescription = Remote process sandbox working directory\nvalue = %(workdir)s\n\n[Action2]\nclass = cmdline\ninput_ref = workdir\nalias = w\ntemplate = -name value\n

                                                                The [Const1].value can be a constant value or a reference to the configuration file properties.

                                                                In the example above we are going to pass to the command line the full path of the process workind directory, which is a unique folder created at runtime where the RemoteWPS framework stores temporary and intermediate results of the process execution.

                                                                Enabling the constant input above, the resulting command line will be something like the following one:

                                                                $> /work/RemoteWPS/xmpp_data/configs/myservice/code/test.py -i <input_value> -w /share/xmpp_data/output/<exec_id>\n

                                                                ::: note ::: title Note :::

                                                                The is known at runtime only. :::

                                                              7. Make sure the outputs have been configured correctly for the command line execution

                                                                [Output1]\nname = result1\ntype = application/zip\ndescription = WPS Resource Binary File\ntitle = SRTM\nfilepath = %(workdir)s/contour.zip\npublish_as_layer = true\npublish_default_style = polygon\npublish_target_workspace = it.geosolutions\npublish_layer_name = contour\n

                                                                In the example above we declare to the WPS only one output of type application/zip.

                                                                In this case the RemoteWPS framework expects to find a contour.zip file at the end of the execution into the working directory (see above).

                                                                There are many kind of possible outputs which can be defined here. As an instance it is possible to define an output of type string which can read the outcome from a file and stream it out as plain text.

                                                                It is also possible to define several kind of binary outputs depending on the executable outcomes. For more details please refer to the Remote WPS Python framework specific documentation at the end of this section.

                                                              8. Make sure the regular expressions of the \"stdout_parser\" are correct and valid accordingly to the output of the executable

                                                                [Logging]\nstdout_parser = [.*\\[DEBUG\\](.*), .*\\[INFO\\] ProgressInfo\\:([-+]?[0-9]*\\.?[0-9]*)\\%, .*\\[(INFO)\\](.*), .*\\[(WARN)\\](.*), .*\\[(ERROR)\\](.*), .*\\[(CRITICAL)\\](.*)]\nstdout_action = [ignore,          progress,                                          log,              log,              log,               abort]\n

                                                                The example configuration above:

                                                                • Ignores all STDOUT debug logs received from test.py
                                                                • Translates as progress info message any number parsed by the regex from STDOUT and sends it to GeoServer WPS.
                                                                • Logs all STDOUT info, warn and error logs received from test.py
                                                                • Translates as abort message any keyword CRITICAL parsed by the regex from STDOUT and sends it to GeoServer WPS.

                                                                At least progress and abort messages are mandatory in order to take track of the process execution progress and fault state.

                                                              9. "},{"location":"community/remote-wps/install_python/#a-running-example","title":"A Running Example","text":"

                                                                In the section A Remote \"Gdal Contour\" Process Binding Example will show how to run the example and how to parse the results in GeoServer.

                                                                "},{"location":"community/remote-wps/install_python/#annex-a-remote-wps-python-wrapper-reference","title":"ANNEX A: Remote WPS Python Wrapper Reference","text":"

                                                                This section is meant to be a summary of the current possible options for the RemoteWPS Python Wrapper service.config configuration.

                                                                "},{"location":"community/remote-wps/install_python/#default-section","title":"Default Section","text":"
                                                                # ########################################### #\n# Default Service Params                      #\n# ########################################### #\n\n[DEFAULT]\nservice = GdalContour\nnamespace = default\ndescription = GDAL Contour Remote Service\nexecutable_path = /work/RemoteWPS/xmpp_data/configs/myservice/code\nexecutable_cmd = python %(executable_path)s/test.py\noutput_dir = /share/xmpp_data/output/\nunique_execution_id = %(unique_exe_id)s\nworkdir = %(output_dir)s/%(unique_execution_id)s\nsharedir = /home/myproc/repository/default\nactive = True\nmax_running_time_seconds = 300\nload_average_scan_minutes = 1\nprocess_blacklist = [resource consuming process name1, resource consuming process name2]\n
                                                                • service; The name of the WPS service. On GeoServer the WPS Process will be represented as namespace.service

                                                                  Note

                                                                  The XMPP Server must have a registered user named like the fully qualified service name namespace.service

                                                                • namespace; The namespace (or prefix) of the service. Along with the service parameter, it represents the fully qualified name of the service.

                                                                • description; This contains the textual description of the GeoServer WPS Process.

                                                                • executable_path; Full path of the executable to wrap.

                                                                • executable_cmd; Executable command.

                                                                • output_dir; The base output folder where the Python wrapper stores logs and temporary files.

                                                                • unique_execution_id; The unique ID generated by GeoServer and sent to the process via the REQUEST command message.

                                                                • workdir; Temporary folder where to store the outcomes and log files.

                                                                • sharedir; Shared folder where to backup outcomes with backup_on_wps_execution_shared_dir property equal true

                                                                • active; Boolean which enables or disables the service.

                                                                • max_running_time_seconds; After this time the Python Wrapper tries to shutdown the process and send a FAILED message to GeoServer.

                                                                • load_average_scan_minutes; This option allows you to set the CPU and Memory average load scan time. It is espressed in 'minutes' and if disabled here it will be set by default to 15 minutes.

                                                                • process_blacklist; Use this option to completely avoid using this host (and prevent starting a new 'processbot') whenever one of the following process names are running. In other words, if one of the following processes are currently running on this machine, GeoServer won't send any WPS execute request until they are finished.

                                                                "},{"location":"community/remote-wps/install_python/#inputs-section","title":"Inputs Section","text":"
                                                                # ########################################### #\n# Inputs and Actions Declaration              #\n# ########################################### #\n\n[Input1]\nclass = param\nname = interval\ntitle = Elevation Interval\ntype = int\ndescription = Elevation interval between contours.\nmin = 1\nmax = 1\ndefault = 200\n\n[Action1]\nclass = cmdline\ninput_ref = interval\nalias = i\ntemplate = -name value\n\n[Const1]\nclass = const\nname = workdir\ntype = string\ndescription = Remote process sandbox working directory\nvalue = %(workdir)s\n\n[Action2]\nclass = cmdline\ninput_ref = workdir\nalias = w\ntemplate = -name value\n

                                                                The Inputs Section can contain three type of objects:

                                                                1. [Input#]; Descriptor of the corresponding GeoServer WPS Input parameter.
                                                                2. [Action#]; 1..n actions of the Python Wrapper associated to an [Input]. The reference is done through the input_ref property.
                                                                3. [Const#]; Constant values passed to the executable and transparent to the GeoServer WPS.

                                                                [Input#]

                                                                • class; Uses introspection to instantiate an Input parameter. Currently the only value admitted is param
                                                                • name; The name of the input parameter. This will be also the name of the GeoServer Input parameter.
                                                                • title; The title of the input parameter. To be used as internal descriptor.
                                                                • description; The description of the input parameter. This will be also the description of the GeoServer Input parameter.
                                                                • type; The type of the input parameter. Allowed types are:
                                                                  1. string; Simple text input. Invalid characters will be automatically removed.
                                                                  2. int; Integer numeric input value.
                                                                  3. float; Float numeric input value.
                                                                  4. url; Must contain a valid URL. Invalid characters will be automatically removed.
                                                                  5. application/json; Threated as a JSON string. It will be parsed by the Python Wrapper and converted into a complex object.
                                                                  6. datetime; Converted into a Python datetime object accordingly to the formatter property containing the date pattern and which must also be provided.
                                                                • min; Optional parameter which sets the minimum set of inputs of this type allowed by the GeoServer WPS. 0 by default.
                                                                • max; Optional parameter which sets the maximum set of inputs of this type allowed by the GeoServer WPS. 0 (alias infinite) by default.
                                                                • default; Optional parameter for setting the default value of this input if a value has not provided.
                                                                • formatter; Optional parameter to be used along with datetime inputs. Defines the date pattern to be applied to the input string (e.g.: %Y-%m-%d %H:%M:%S)

                                                                [Action#]

                                                                • class; Uses introspection to instantiate the type of Action.

                                                                  1. cmdline; The value of the associated input will be passed to the executable as a key-value pair accordingly to the template specified (e.g.: --name=value).

                                                                    • template; Template of the key-value pair format (e.g.: template = -name value)
                                                                    • alias; Alias of the key (e.g.: alias = i will be translated as -i value)
                                                                  2. createJSONfile; The value of the associated input will be dumped to a JSON file and the reference to the file passed to the executable.

                                                                    • target_filepath; PATH Where to store the JSON file.
                                                                    • json_schema; The PATH to the JSON Schema to be used to validate the input values.
                                                                  3. updateJSONfile; The value of the associated input will be substituted into a target template JSON file, which then will be passed to the executbale as reference.

                                                                    • source_filepath; PATH of the source JSON template file.
                                                                    • target_filepath; PATH of the target JSON file.
                                                                    • json_path_expr; JSON path expression used to subsitute the values.
                                                                  4. copyfile; The value of the associated input will be interpreted as a path to a source file. The content of the file will be copied into a temporary file and then passed to the executbale as reference.

                                                                    • source_filepath; PATH of the source JSON template file.
                                                                    • target_filepath; PATH of the target JSON file.
                                                                  5. updateINIfile; The value of the associated input will be substituted into a target template INI file, which then will be passed to the executbale as reference.

                                                                    • source_filepath; PATH of the source JSON template file.
                                                                    • target_filepath; PATH of the target JSON file.
                                                                    • section; Section of the INI file where to store key-value pair entries.
                                                                  6. updateINIfileList; The value of the associated input will be parsed as a list and substituted into a target template INI file, which then will be passed to the executbale as reference.

                                                                    • source_filepath; PATH of the source JSON template file.
                                                                    • target_filepath; PATH of the target JSON file.
                                                                    • section; Section of the INI file where to store key-value pair entries.
                                                                • input_ref; name of the input parameter referenced by this Action.

                                                                [Const#]

                                                                • class = const
                                                                • name; Name of the input parameter, used by an action as reference.
                                                                • type; May be one of the [Input#].type ones.
                                                                • description; Internal description of the parameter.
                                                                • value; Fixed value parsed by the referencing Action.
                                                                "},{"location":"community/remote-wps/install_python/#outputs-section","title":"Outputs Section","text":"
                                                                # ########################################### #\n# Output Parameters Declaration               #\n# ########################################### #\n\n# WARNING: the name must start with the keyword \"result\"\n\n[Output1]     \nname = result1\ntype = string\ndescription = WPS Resource Plain Text\nfilepath = %(workdir)s/geoserverLayerOutput.xml\n\n[Output2]\nname = result2\ntype = image/geotiff\ndescription = WPS Resource Binary File\ntitle = SRTM\nfilepath = %(workdir)s/srtm_39_04_c.tif\nbackup_on_wps_execution_shared_dir = true\npublish_as_layer = true\npublish_default_style = raster\npublish_target_workspace = it.geosolutions\npublish_layer_name = srtm_39_04_c\n# Such metadata is a JSON snippet itself (/tmp/resource_dir/result2.json) with a small particularity. \n# Since you cannot know a-priori some of the final Layer properties, \n# you can use inside the json (/tmp/resource_dir/result2.json) some keywords which will be updated \n# automatically by the RemoteWPS which are the following ones:\n#\n# ${type} \n# ${name}\n# ${title}  \n# ${description} \n# ${lastUpdated} \n# ${getMapBaseUrl} \n# ${srs} \n# ${bbox} \n# ${workspace} \n# ${layers} \n# ${styles} \npublish_metadata = /<path_to>/resource_dir/result2.json\n\n[Output3]\nname = result3\ntype = image/geotiff;stream\ndescription = WPS Resource Binary Stream\ntitle = This Is A GeoTIFF Layer\nfilepath = %(workdir)s/srtm_39_04_c.tif\npublish_as_layer = true\npublish_default_style = raster\npublish_target_workspace = it.geosolutions\npublish_layer_name = srtm_39_04_c\n\n[Output4]\nname = result4\ntype = application/x-netcdf\ndescription = NetCDF Binary File\ntitle = Wind\nfilepath = %(workdir)s/RS1_STB_1FSCLS20111003_175545_00000018xS2x_16bxx_83066_29447_wind.nc\nbackup_on_wps_execution_shared_dir = true\npublish_as_layer = true\npublish_default_style = raster\npublish_target_workspace = it.geosolutions\npublish_layer_name = wind\n# Such metadata is a JSON snippet itself (/tmp/resource_dir/result3.json) with a small particularity. \n# Since you cannot know a-priori some of the final Layer properties, \n# you can use inside the json (/tmp/resource_dir/result4.json) some keywords which will be updated \n# automatically by the RemoteWPS which are the following ones:\n#\n# ${type} \n# ${name}\n# ${title}  \n# ${description} \n# ${lastUpdated} \n# ${getMapBaseUrl} \n# ${srs} \n# ${bbox} \n# ${workspace} \n# ${layers} \n# ${styles} \npublish_metadata = /<path_to>/resource_dir/result4.json\n\n# ########################################### #\n# GML Possible type values are                #\n#  text/xml;subtype=gml/3.1.1                 #\n#  text/xml;subtype=gml/2.1.2                 #\n#  application/gml-3.1.1                      #\n#  application/gml-2.1.2                      #\n# ########################################### #\n[Output5]\nname = result5\ntype = text/xml;subtype=gml/3.1.1\ndescription = WPS Resource GML\nfilepath = %(workdir)s/geoserverLoadLayerOutput.xml\n\n[Output6]\nname = result6\ntype = video/mp4\ndescription = Video MP4 Binary File\ntitle = Wind\nfilepath = %(workdir)s/RS1_STB_1FSCLS20111003_175545_00000018xS2x_16bxx_83066_29447_wind.mp4\nbackup_on_wps_execution_shared_dir = false\n\n[Output7]\nname = result7\ntype = application/owc\ndescription = WPS OWC Json MapContext\nlayers_to_publish = result2;result4\npublish_as_layer = true\npublish_layer_name = owc_json_ctx\npublish_metadata = /<path_to>/resource_dir/owc_json_ctx.json\n

                                                                The examples above represents all the possible types of Outputs currently supported by the Remote WPS Wrapper.

                                                                • type = string

                                                                  The content of the file specified by the filepath is read and sent to the WPS. The GeoServer WPS declares this as a text/plain output type.

                                                                • type = image/geotiff

                                                                  The content of the binary GeoTIFF specified by the filepath is read and sent to the WPS. The GeoServer WPS declares this as a otput binary RAW FILE output type.

                                                                • type = image/geotiff;stream

                                                                  The content of the binary GeoTIFF specified by the filepath is read and sent to the WPS. The GeoServer WPS declares this as a otput binary RAW STREAM output type.

                                                                • type = application/x-netcdf

                                                                  The content of the binary NetCDF specified by the filepath is read and sent to the WPS. The GeoServer WPS declares this as a otput binary RAW FILE output type.

                                                                • type = text/xml;subtype=gml/3.1.1

                                                                  The content of the file specified by the filepath is read and sent to the WPS. The GeoServer WPS declares this as a text/xml output type.

                                                                • type = video/mp4

                                                                  The content of the binary MPEG-4 specified by the filepath is read and sent to the WPS. The GeoServer WPS declares this as a otput binary RAW FILE output type.

                                                                • type = application/owc

                                                                  This is a particular type of output. From the GeoServer WPS point of view is a text/plain JSON output type describing a Web Mapping Context.

                                                                  The Remote WPS Plugin on GeoServer side takes care of publishing the layers specified by layers_to_publish = result2;result4 and render the templates specified by publish_metadata of each output.

                                                                  The outcome will be a complex JSON WMC describing the map to publish.

                                                                  In order to activate this funcionality, update the GeoServer remoteProcess.properties on the GEOSERVER_DATA_DIR with a new option:

                                                                  # full path to the template used to generate the OWS WMC Json output\n\nowc_wms_json_template = /tmp/resource_dir/wmc_template.json\n

                                                                  Sample wmc_template.json

                                                                  {\n  \"type\": \"FeatureCollection\",\n  \"id\": \"GeoServer OWC Map Context: version of 2015-07-14\",\n  \"geometry\": {\n              \"type\":\"Polygon\",\n              \"coordinates\": ${renderingArea}\n    },\n    \"features\" : [\n            <#list featureList?keys as key>\n            {\n                \"type\": \"Feature\",\n                \"id\": \"${featureList[key].name}\",\n                \"geometry\": \n                {\n                \"type\" : \"Polygon\",\n                \"coordinates\" : ${featureList[key].geometryCoords}\n            },\n            \"properties\": {\n                <#if featureList[key].owcProperties != \"\">${featureList[key].owcProperties},</#if>\n                \"offerings\" : [\n                    {\n                      \"code\" : \"http://www.opengis.net/spec/owc-atom/1.0/req/wms\",\n                      \"operations\" : [{\n                          \"code\" : \"GetCapabilities\",\n                          \"method\" : \"GET\",\n                          \"type\" : \"application/xml\",\n                          \"href\" : \"${featureList[key].getMapBaseUrl}?SERVICE=WMS&VERSION=1.3.0&REQUEST=GetCapabilities\",\n                          \"request\":{},\n                          \"result\":{}\n                        },{\n                          \"code\" : \"GetMap\",\n                          \"method\" : \"GET\",\n                          \"type\" : \"image/png\",\n                          \"href\" : \"${featureList[key].getMapBaseUrl}?SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&SRS=${featureList[key].srs}&BBOX=${featureList[key].bbox}&WIDTH=500&HEIGHT=500&LAYERS=${featureList[key].layers}&STYLES=${featureList[key].styles}&FORMAT=image/png&BGCOLOR=0xffffff&TRANSPARENT=TRUE&EXCEPTIONS=application/vnd.ogc.se_xml\",\n                          \"request\":{},\n                          \"result\":{}\n                        }],\n                      \"contents\" : []\n                    }\n                <#if featureList[key].type == \"VECTOR\">\n                    ,{\n                      \"code\" : \"http://www.opengis.net/spec/owc-atom/1.0/req/wfs\",\n                      \"operations\" : [{\n                          \"code\" : \"DescribeFeatureType\",\n                          \"method\" : \"GET\",\n                          \"type\" : \"application/xml\",\n                          \"href\" : \"${featureList[key].getMapBaseUrl}?SERVICE=WFS&VERSION=1.1.0&REQUEST=DescribeFeatureType&TYPENAME=${featureList[key].layers}\",\n                          \"request\":{},\n                          \"result\":{}\n                        },{\n                          \"code\" : \"GetFeature\",\n                          \"method\" : \"GET\",\n                          \"type\" : \"application/xml\",\n                          \"href\" : \"${featureList[key].getMapBaseUrl}?SERVICE=WFS&VERSION=1.1.0&REQUEST=GetFeature&TYPENAME=${featureList[key].layers}\",\n                          \"request\":{},\n                          \"result\":{}\n                        }],\n                      \"contents\" : []\n                    }\n            <#elseif featureList[key].type == \"RASTER\">\n                    ,{\n                      \"code\" : \"http://www.opengis.net/spec/owc-atom/1.0/req/wcs\",\n                      \"operations\" : [{\n                          \"code\" : \"DescribeCoverage\",\n                          \"method\" : \"GET\",\n                          \"type\" : \"application/xml\",\n                          \"href\" : \"${featureList[key].getMapBaseUrl}?SERVICE=WCS&VERSION=1.1.0&REQUEST=GetCapabilities&IDENTIFIER=${featureList[key].layers}\",\n                          \"request\":{},\n                          \"result\":{}\n                        },{\n                          \"code\" : \"GetCoverage\",\n                          \"method\" : \"GET\",\n                          \"type\" : \"image/tiff\",\n                          \"href\" : \"${featureList[key].getMapBaseUrl}?SERVICE=WCS&VERSION=1.1.0&REQUEST=GetCoverage&IDENTIFIER=${featureList[key].layers}&BOUNDINGBOX=${featureList[key].bbox}&FORMAT=GeoTIFF\",\n                          \"request\":{},\n                          \"result\":{}\n                        }],\n                      \"contents\" : []\n                    }\n            </#if>\n            ]\n           }\n         }<#if key_has_next>,</#if>\n     </#list>\n     ]\n  , \n\n  \"properties\" : {\n            ${owcProperties}\n      }      \n\n}\n

                                                                  Sample owc_json_ctx.json

                                                                  \"lang\" : \"en\",\n\"title\" : \"Sample Title goes here\",\n\"subtitle\" : \"Sample sub-title goes here\",\n\"generator\" : \"Sample generator\",\n\"rights\" : \"Sample Legal Constraints and CopyRights (C)\",\n\"authors\" : [{\"name\" : \"Author1 Name\"}, {\"name\" : \"Author2 Name\"}],\n\"contributors\" : [{\"name\" : \"Contrib1 Name\"}, {\"name\" : \"Contrib2 Name\"}],\n\"categories\" : [{\n        \"term\" : \"wms\",\n        \"label\" : \"This file is compliant with version 1.0 of OGC Context\"\n    },{\n        \"term\" : \"maps\",\n        \"label\" : \"This file contains maps\"\n}],\n\"links\" : [{\n        \"rel\" : \"profile\",\n        \"href\" : \"http://www.opengis.net/spec/owc-atom/1.0/req/core\",\n        \"title\" : \"This file is compliant with version 1.0 of OGC Context\"\n    },{\n        \"rel\" : \"via\",\n        \"type\" : \"application/xml\",\n        \"href\" : \"http://www.opengis.uab.cat/wms/satcat/metadades/EPSG_23031/Cat_20110301.htm\",\n        \"title\" : \"HMTL metadata in Catalan\"\n    }]\n

                                                                  Sample result#.json

                                                                  \"title\" : \"Result 2\",\n\"updated\" : \"${lastUpdated}\",\n\"content\" : \"Sample Content Description for result 2 goes here\",\n\"authors\" : [\n    {\n      \"name\" : \"GeoServer Administrator\",\n      \"email\" : \"info@sample.author.com\"\n    }\n],\n\"authors\" : [{\"name\" : \"Author2.1 Name\"}, {\"name\" : \"Author2.2 Name\"}],\n\"contributors\" : [{\"name\" : \"Contrib2.1 Name\"}, {\"name\" : \"Contrib2.2 Name\"}],\n\"categories\" : [{\"name\" : \"Category2.1 Name\"}, {\"name\" : \"Category2.2 Name\"}],\n\"links\" : [\n    {\n     \"rel\" : \"enclosure\",\n     \"type\" : \"image/png\",\n     \"title\" : \"WMS output for ${title}\",\n     \"href\" : \"${getMapBaseUrl}?SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&SRS=${srs}&BBOX=${bbox}&WIDTH=500&HEIGHT=500&LAYERS=${layers}&FORMAT=image/png&BGCOLOR=0xffffff&TRANSPARENT=TRUE&EXCEPTIONS=application/vnd.ogc.se_xml\"\n    },\n    {\n     \"rel\" : \"icon\",\n     \"type\" : \"image/png\",\n     \"title\" : \"Preview for ${title}\",\n     \"href\" : \"${getMapBaseUrl}?SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&SRS=${srs}&BBOX=${bbox}&WIDTH=100&HEIGHT=100&LAYERS=${layers}&STYLES=${styles}&FORMAT=image/png&BGCOLOR=0xffffff&TRANSPARENT=TRUE&EXCEPTIONS=application/vnd.ogc.se_xml\"\n    },\n    {\n     \"rel\" : \"via\",\n     \"type\" : \"application/vnd.ogc.wms_xml\",\n     \"title\" : \"Original GetCapabilities document\",\n     \"href\" : \"${getMapBaseUrl}?SERVICE=WMS&VERSION=1.1.1&REQUEST=GetCapabilities\"\n    }\n]\n

                                                                Other options for the Outputs

                                                                • backup_on_wps_execution_shared_dir; This is a boolean which tells to the Remote WPS to store first the outcome into the sharedir defined into the [DEFAULT] section before streaming out to GeoServer. This allows the Remote WPS to preserve the outcomes even when the resources are cleaned out.

                                                                • upload_data; This is a boolean which tells to the Remote WPS to upload first the outcome into the host defined into the [UPLOADER] section before streaming out to GeoServer. This allows the Remote WPS to preserve the outcomes even when the resources are cleaned out.

                                                                  ::: warning ::: title Warning :::

                                                                  If both enabled for a certain output, the backup_on_wps_execution_shared_dir takes precedence to the upload_data one. :::

                                                                • publish_as_layer; A boolean to instruct GeoServer Remote WPS to try to automatically publish the outcome as a new Layer through the GeoServer Importer Plugin.

                                                                • publish_default_style; The default style to use when publishing the Layer.

                                                                • publish_target_workspace; The default workspace to use when publishing the Layer.

                                                                • publish_layer_name; The default name to use when publishing the Layer.

                                                                "},{"location":"community/remote-wps/install_python/#logging-section","title":"Logging Section","text":"
                                                                # ########################################### #\n# Logging RegEx and Levels                    #\n# ########################################### #\n\n[Logging]\nstdout_parser = [.*\\[DEBUG\\](.*), .*\\[INFO\\] ProgressInfo\\:([-+]?[0-9]*\\.?[0-9]*)\\%, .*\\[(INFO)\\](.*), .*\\[(WARN)\\](.*), .*\\[(ERROR)\\](.*), .*\\[(CRITICAL)\\](.*)]\nstdout_action = [ignore,          progress,                                          log,              log,              log,               abort]\n
                                                                • stdout_parser

                                                                  This property must contain a list of regular expressions matching the possible executable STDOUT logging messages the user wants to forward to GeoServer.

                                                                  As an instance

                                                                  .*\\[DEBUG\\](.*)\n

                                                                  Matches all the messages containing the keyword [DEBUG] and forwards to the corresponding stdout_action (see below) the content of the first matching group (.*)

                                                                  In this case everything after [DEBUG] is forwarded to the action.

                                                                  Another example

                                                                  .*\\[INFO\\] ProgressInfo\\:([-+]?[0-9]*\\.?[0-9]*)\\%\n

                                                                  Matches all the messages containing the keyword [INFO] ProgressInfo:<any_number>% and forwards to the corresponding stdout_action (see below) the content of the first matching group ([-+]?[0-9]*\\.?[0-9]*)

                                                                  In this case the expression extracts a float number form the text along with the sign [-+]

                                                                • stdout_action

                                                                  This property must contain a list of keywords associated to a particular action which will take the content of the corresponding regular expression and forwards it to GeoServer packaged ad a specific XMPP message.

                                                                  As an instance

                                                                  • progress; gets the content of the match and sends a PROGRESS XMPP message to GeoServer. The PROGRESS messgae must always contain a number.
                                                                  • abort; gets the content of the match and sends a ABORT XMPP message to GeoServer. This will cause GeoServer to mark the WPS Process as FAILED.
                                                                  • ignore; simply throws out everything matching the corresponding regular expression.
                                                                  • log; sends a LOG message to GeoServer with the content of the match. This will appear into the GeoServer Log file.
                                                                "},{"location":"community/remote-wps/install_xmpp/","title":"Installation Of OpenFire XMPP Server To Exchange Messages","text":"

                                                                The following commands will prepare a CentOS 7 Minimal ISO machine for the deployment of:

                                                                • Openfire XMPP Server
                                                                • NFS shared file-system

                                                                Note

                                                                Prerequisite to this section, is the basic preparation of the CentOS machine as described on the section Deployment And Setup Of GeoServer With WPS Remote Plugin.

                                                                "},{"location":"community/remote-wps/install_xmpp/#setup-and-configuration-of-openfire-xmpp-server","title":"Setup and configuration of Openfire XMPP Server","text":"

                                                                Originally named Jabber, XMPP is the new label for Extensible Messaging and Presence Protocol. and it is associated mostly with instant messaging.

                                                                "},{"location":"community/remote-wps/install_xmpp/#setting-up-postgresql-database-backend","title":"Setting up PostgreSQL database backend","text":"

                                                                For the purposes of running a private XMPP communication platform, we can safely stick with PostgreSQL 9.2 which is stable and comes in CentOS 7 by default.

                                                                # as root\n\n$> yum install -y postgresql postgresql-server postgresql-devel postgresql-libs\n\n# After PostgreSQL packages are installed, enable PostgreSQL to start after each reboot.\n\n$> systemctl enable postgresql.service\n\n# Initialize directory structure and postgres system database.\n\n$> postgresql-setup initdb\n\n# And start the service.\n\n$> systemctl start postgresql.service\n

                                                                Postgres installation is now up and running, lets proceed with setting up the specific database and the dedicated user for OpenFire, together with authentication method and administration password.

                                                                For full administration access, switch to postgres user.

                                                                su postgres\n\n# as postgres\n\n$> createdb openfire\n$> createuser -P openfire\n\n# The '-P' parameter ensures that the shell will explicitly ask for user's password and you will need to type it in. Enter the password twice\n\n   R3m0T3wP5\n\n$> psql -U postgres -d postgres -c \"ALTER USER postgres WITH PASSWORD 'R3m0T3wP5';\"\n

                                                                Postgres user is secured with the new password. Lets put authentication methods in practice and force every application or shell login to prompt for these passwords.

                                                                # as postgres\n\n$> vim /var/lib/pgsql/data/pg_hba.conf\n\n# Scroll down to the bottom of the file and replace all peer and ident strings with md5 string.\n# The configuration should look like this:\n\n   # TYPE DATABASE USER CIDR-ADDRESS METHOD\n\n   # \"local\" is for Unix domain socket connections only\n\n   local      all         all                 md5\n\n   # IPv4 local connections:\n\n   host       all         all 127.0.0.1/32    md5\n\n   # IPv6 local connections:\n\n   host       all         all      ::1/128    md5\n

                                                                Go back from postgres shell (Ctrl+D) and restart postgresql service as root.

                                                                # as root\n\n$> systemctl restart postgresql.service\n
                                                                "},{"location":"community/remote-wps/install_xmpp/#download-and-install-openfire-from-ignite-realtime","title":"Download and install Openfire from Ignite Realtime","text":"

                                                                Since OpenFire RPM package is not included in any major RHEL / CentOS / Fedora distribution repositories, it must be downloaded directly from Ignite Realtime website.

                                                                # as root\n\n$> wget http://www.igniterealtime.org/downloadServlet?filename=openfire/openfire-3.10.0-1.i386.rpm -O openfire-3.10.0-1.i386.rpm\n\n# This package come in 32bit version only, so in case we run this installation on x86_64 system, we need to make sure to install corresponding 32bit libraries as well.\n\n$> yum install -y /root/openfire-3.9.3-1.i386.rpm\n\n$> yum install -y glibc.i686\n

                                                                Enable the openfire service and start it

                                                                # as root\n\n$> chkconfig openfire on\n\n$> systemctl start openfire.service\n\n# We need to open the firewall ports in order to expose the gui to the outside\n\n$> firewall-cmd --permanent --zone=public --add-port=9090/tcp\n$> firewall-cmd --permanent --zone=public --add-port=9091/tcp\n$> firewall-cmd --reload\n

                                                                Configuration of Openfire server

                                                                Move the browser to the url

                                                                http://YOUR-SERVER-IP:9090

                                                                Choose preferable language and hit Contine

                                                                Specify the server Domain as

                                                                geoserver.org

                                                                Choose the Standard Database Connection in the next section

                                                                Provide the Database connection parameters for the PostgreSQL DB in the standard connection section.

                                                                The password for the user openfire is the same provided in the PostgreSQL DB setup (see above).

                                                                Note

                                                                Be sure the openfire database and user have been correctly created on PostgreSQL and the passwords provided (see above for instructions).

                                                                If there are no connection issues, choose Default value on the users profile settings section.

                                                                Create the Administrator account in the next section.

                                                                The password must match the one specified in the remoteProcess.properties file

                                                                R3m0T3wP5

                                                                The initial setup is now complete. Log into the system using the newly created admin account.

                                                                Move to the Server Certificates section of the Server Settings tab panel.

                                                                Warning

                                                                This passage is not needed anymnore on Openfire 4.0+. At least the management of the certificates is a bit different. Please refer to the specific Openfire documentation for more information.

                                                                Make sure that the self-signed certificates have been correctly generated and click on here in order to restart the server

                                                                Warning

                                                                This passage is not needed anymnore on Openfire 4.0+. At least the management of the certificates is a bit different. Please refer to the specific Openfire documentation for more information.

                                                                The same section now shows the server certificates and won't ask for another restart unless the certificates are generated again.

                                                                Update the Security Settings in order to allow the server accepting self-signed certificates on secured connections.

                                                                Warning

                                                                This passage is not needed anymnore on Openfire 4.0+. At least the management of the certificates is a bit different. Please refer to the specific Openfire documentation for more information.

                                                                Create the default channel as shown in the next figure.

                                                                Create the management channel as shown in the next figure. Pay attention to the Room Options and specify the password for the channel

                                                                R3m0T3wP5

                                                                Double check that the channels have been correctly created and they appear in the Group Chat Rooms.

                                                                Restart GeoServer

                                                                # as root\n\n$> systemctl restart geoserver\n

                                                                After the GeoServer has successfully restarted, double check that it is connected to the server using the admin credentials.

                                                                It is very important that the user is shown as Authenticated.

                                                                Check also that the user is registered to the XMPP channels created above.

                                                                "},{"location":"community/remote-wps/install_xmpp/#firewall-rules-for-xmpp-ports","title":"Firewall Rules For XMPP Ports","text":"

                                                                By default the TCP Ports where the XMPP Server is listening for incoming connection are closed to the outside. Therefore it is necessary to enable the Firewall rules at least for the Openfire default secured port 5223 unless it has been changed by the user during the server setup.

                                                                In order to do that issue the following commands:

                                                                # as root\n\n# We need to open the firewall ports in order to expose the gui to the outside\n\n$> firewall-cmd --permanent --zone=public --add-port=5222/tcp\n$> firewall-cmd --permanent --zone=public --add-port=5223/tcp\n\n$> firewall-cmd --reload\n
                                                                "},{"location":"community/remote-wps/install_xmpp/#forward-proxy-to-apache-httpd-server","title":"Forward Proxy to Apache HTTPD Server","text":"

                                                                The procedures described in this section allows to expose GeoServer via HTTPD through Apache HTTPD Server.

                                                                Those steps are not mandatory and the procedure may change accordingly to the final deployment on production systems.

                                                                In order to install Apache HTTPD Server proceed as follows:

                                                                # as root\n\n$> yum -y install httpd mod_ssl\n\n$> vi /etc/httpd/conf.d/forward-proxy.conf\n\n   ProxyRequests Off\n\n   ProxyPass /geoserver ajp://localhost:8009/geoserver\n   ProxyPassReverse /geoserver ajp://localhost:8009/geoserver\n\n$> systemctl enable httpd.service\n\n$> service httpd restart\n

                                                                Selinux, enabled by default, needs to be instructed to allow http network connections. This can be done by running the command:

                                                                # as root\n\n$> /usr/sbin/setsebool -P httpd_can_network_connect 1\n
                                                                "},{"location":"community/remote-wps/install_xmpp/#shared-folder-through-the-nfs-protocol","title":"Shared Folder through the NFS protocol","text":"

                                                                The next steps describe how to setup the system in order to expose a Shared Network Folder which will be used to store the outcomes of the remote processing.

                                                                The following procedures are not mandatory and the final deployment on the production system may be configured to use different protocols and frameworks to expose shared file-systems.

                                                                The setup and initial configuration of the NFS packages can be done by following the next procedure:

                                                                # as root\n\n$> yum -y install nfs-utils\n\n$> vi /etc/idmapd.conf\n\n   # The following should be set to the local NFSv4 domain name\n\n   # The default is the host's DNS domain name.\n   Domain = geoserver.org\n

                                                                Note

                                                                The domain specified above maybe different depending on the final system deployment and the production environment setup.

                                                                Creating and exposing a shared folder is possible by following the next steps:

                                                                1. as root
                                                                2. Create the physical folder structure to be exposed via the Network Filesystem
                                                                $> mkdir /share\n$> mkdir /share/xmpp_data\n$> mkdir /share/xmpp_data/output\n$> mkdir /share/xmpp_data/resource_dir\n
                                                                1. Modify the rights in order to allow

                                                                  $> chmod -Rf 777 /share\n
                                                                2. Once the physical folder is ready it must be exposed via the exports

                                                                $> vi /etc/exports\n
                                                                1. write settings for NFS exports
                                                                /share host_ip/24(rw,no_root_squash)\n
                                                                1. Restart the NFS services
                                                                $> systemctl start rpcbind nfs-server\n\n$> systemctl enable rpcbind nfs-server\n

                                                                Note

                                                                The host_ip must be the one of the host exposing the shared folder.

                                                                Selinux, enabled by default, needs to be instructed to allow NFS connections. This can be done by running the following commands:

                                                                # as root\n\n$> setsebool -P httpd_use_nfs=1\n\n$> setsebool -P samba_share_nfs=1\n\n$> setsebool -P samba_export_all_ro=1\n\n$> setsebool -P samba_export_all_rw=1\n
                                                                "},{"location":"community/remote-wps/running_example/","title":"A Remote \"Gdal Contour\" Process Binding Example","text":"

                                                                Before continue reading this section, please be sure to have fully understood and successfully completed all the passages at sections:

                                                                • Deployment And Setup Of GeoServer With WPS Remote Plugin
                                                                • Installation Of OpenFire XMPP Server To Exchange Messages
                                                                • Deployment And Setup Of The XMPP Python Wrappers
                                                                "},{"location":"community/remote-wps/running_example/#running-the-python-wps-agent","title":"Running the Python WPS Agent","text":"

                                                                In order to start the RemoteWPS Python Wrapper, we need to run an instance of the wpsagent.py using the configuration files defined at section Deployment And Setup Of The XMPP Python Wrappers

                                                                $> cd C:\\work\\RemoteWPS\n\n$> python wpsagent.py -r .\\xmpp_data\\configs\\remote.config -s .\\xmpp_data\\configs\\myservice\\service.config service\n

                                                                Few instants after the execution of the command, you should be able to see con invite message on the prompt

                                                                and the default.GdalContour instance successfully connected and authenticated into the XMPP Server channels

                                                                The new GeoServer WPS Process should be now available among the GeoServer Processes

                                                                The GeoServer Remote Process Factory automatically creates the WPS interface for the new process, exposing through the OGC WPS Protocol the Inputs and Outputs definitions like shown in the illustration below

                                                                At the Execute Request the Remote WPS Python framework starts a new thread and assigns to it the unique execution_id provided by GeoServer.

                                                                The logs of the execution are stored into the working directory

                                                                From the log file is possible to recognize the full command line executed by the Remote WPS Python wrapper along with the lines received through the standard output

                                                                The main window shows the received XMPP messages and the actions taken accordingly

                                                                Note

                                                                The same information can be found into the log file specified into the \"logger.properties\" file (see above).

                                                                On GeoServer side, it is possible to follow the process execution by following the messages sent via XMPP to the GeoServer logs

                                                                $> tail -F -n 200 /storage/data/logs/geoserver.log\n

                                                                "},{"location":"community/s3-geotiff/","title":"S3 Support for GeoTiff","text":"

                                                                Support for GeoTiffs hosted on Amazon S3 or on other Amazon S3 compatible services, via a custom GeoTools GridFormat.

                                                                "},{"location":"community/s3-geotiff/#whats-in-the-box","title":"What's in the Box?","text":"
                                                                • org.geotools.s3.geotiff: S3 GeoTiff Format/FormatFactory/GridCoverage2dReader implementations based off of the GeoTiff versions. Only very minor changes to their parent classes.
                                                                • org.geotools.s3.cache: Very basic caching of images from S3 based off of EhCache.
                                                                • S3ImageInputStreamImpl: An implementation of ImageInputStream from JAI for reading imagery from S3. This class mainly contains the logic of stream position and chunking, while the cache package handles the actual S3 reads.
                                                                "},{"location":"community/s3-geotiff/#geotiffs-hosted-on-amazon-s3","title":"GeoTiffs hosted on Amazon S3","text":""},{"location":"community/s3-geotiff/#configuration","title":"Configuration","text":"

                                                                Almost all configuration is currently done via system properties. For caching configuration, please see the class org.geotools.s3.cache.CacheConfig.

                                                                "},{"location":"community/s3-geotiff/#usage","title":"Usage","text":"

                                                                S3GeoTiff uses s3:// style URLs to operate. The only twist is that S3GeoTiff uses query string parameters to configure certain parameters

                                                                • awsRegion: Controls the region to use when connecting. Needs to be in Java enum format eg. US_WEST_2
                                                                • useAnon: Controls whether to authenticate anonymously. This needs to be used to connect anonymous buckets

                                                                For example:

                                                                s3://landsat-pds/L8/001/002/LC80010022016230LGN00/LC80010022016230LGN00_B1.TIF?useAnon=true&awsRegion=US_WEST_2

                                                                "},{"location":"community/s3-geotiff/#credentials","title":"Credentials","text":"

                                                                Unless S3_USE_ANON is set to true the default AWS client credential chain is used.

                                                                "},{"location":"community/s3-geotiff/#geotiffs-hosted-on-other-amazon-s3-compatible-services","title":"GeoTiffs hosted on other Amazon S3 compatible services","text":"

                                                                Access geotiffs on S3 servers not hosted on Amazon, e.g. https://www.minio.io/ or other. There are 2 steps to access the geofiff files. configure the server in the s3.properties file and then you can use the prefix as an alias to access the file in the S3GeoTiff module for geoserver.

                                                                "},{"location":"community/s3-geotiff/#configuration_1","title":"Configuration","text":"

                                                                The S3 endpoints are configured in the s3.properties file. The following properties are needed for each endpoint. The prefix alias can be any value you choose in order to configure multiple endpoints.

                                                                • alias.s3.endpoint=http://your-s3-server/
                                                                • alias.s3.user=your-user-name
                                                                • alias.s3.password=your-password
                                                                "},{"location":"community/s3-geotiff/#usage_1","title":"Usage","text":"

                                                                Using the above configuration in the s3.properties file, the files on the S3 service can be accessed with the following URL style configuration in geoserver:

                                                                alias://bucketname/filename.tiff

                                                                • alias: The prefix you choose for the configuration of the endpoint
                                                                • bucketname: The path to the folder where the geotiffs are stored
                                                                • filename.tif: The name of the geotiff file
                                                                "},{"location":"community/schemaless-features/","title":"Schemaless Features Plugin","text":"

                                                                This plugin includes support for serving complex features directly from Schemaless Feature sources.

                                                                Warning

                                                                At the time of writing only MongoDB support is provided. The plug-in supports only the following services/operation with the indicated output formats:

                                                                • WMS:
                                                                  • GetMap (all the formats)
                                                                  • GetFeatureInfo (GeoJSON and HTML outputs only)
                                                                • WFS:
                                                                  • GetFeature (GeoJSON output only)
                                                                • Installing the Schemaless Mongo module
                                                                • MongoDB Schemaless Support
                                                                "},{"location":"community/schemaless-features/install/","title":"Installing the Schemaless Mongo module","text":"
                                                                1. Download mongodb-schemaless nightly GeoServer community module.

                                                                  Warning

                                                                  Verify that the version number in the filename corresponds to the version of GeoServer you are running (for example geoserver- 2.24.2-schemaless-features-plugin.zip above).

                                                                2. Extract the contents of the archive into the WEB-INF/lib directory of the GeoServer installation.

                                                                3. On restart the MongoDB Schemaless vector source option will be available from the New Data Source page:

                                                                "},{"location":"community/schemaless-features/schemaless-mongo/","title":"MongoDB Schemaless Support","text":"

                                                                By clicking on MongoDB Schemaless we land on the store configuration page. The only needed parameters are the workspace and the MongoDBURI. For a description of the available MongoDB URI format check here .

                                                                After saving, it will be possible to serve every MongoDB collection found in the database as a layer, by the layer configuration page.

                                                                The default geometry can be defined by setting a geometry index on the desired geometry attribute in the MongoDB collection.

                                                                As an example of the obtained output we will use the Stations use case. In the MongoDB collection we have the following document among the others being served:

                                                                {\n\"_id\": {\n \"$oid\": \"58e5889ce4b02461ad5af080\"\n},\n\"id\": \"1\",\n\"name\": \"station 1\",\n\"numericValue\": 20,\n\"contact\": {\n \"mail\": \"station1@mail.com\"\n},\n\"geometry\": {\n \"coordinates\": [\n   50,\n   60\n ],\n \"type\": \"Point\"\n},\n\"measurements\": [\n {\n   \"name\": \"temp\",\n   \"unit\": \"c\",\n   \"values\": [\n     {\n       \"time\": 1482146800,\n       \"value\": 20\n     }\n   ]\n },\n {\n   \"name\": \"wind\",\n   \"unit\": \"km/h\",\n   \"values\": [\n     {\n       \"time\": 1482146833,\n       \"value\": 155\n     }\n   ]\n }\n]\n}\n

                                                                The GeoJSON output for that specific document will be the following feature:

                                                                {\n \"type\": \"Feature\",\n \"id\": \"58e5889ce4b02461ad5af080\",\n \"geometry\": {\n   \"type\": \"Point\",\n   \"coordinates\": [\n     50,\n     60\n   ]\n },\n \"properties\": {\n   \"@featureType\": \"stations\",\n   \"_id\": \"58e5889ce4b02461ad5af080\",\n   \"name\": \"station 1\",\n   \"numericValue\": 20,\n   \"contact\": {\n     \"type\": \"Feature\",\n     \"id\": \"fid-3087ff95_17844d87c61_-7aad\",\n     \"geometry\": null,\n     \"properties\": {\n       \"@featureType\": \"Contact\",\n       \"mail\": \"station1@mail.com\"\n     }\n   },\n   \"id\": \"1\",\n   \"measurements\": [\n     {\n       \"values\": [\n         {\n           \"value\": 20,\n           \"time\": 1482146800\n         }\n       ],\n       \"name\": \"temp\",\n       \"unit\": \"c\"\n     },\n     {\n       \"values\": [\n         {\n           \"value\": 155,\n           \"time\": 1482146833\n         }\n       ],\n       \"name\": \"wind\",\n       \"unit\": \"km/h\"\n     }\n   ]\n  }\n}\n

                                                                As it is possible to see, the feature object is very close to the appearance of the corresponding MongoDB document.

                                                                "},{"location":"community/schemaless-features/schemaless-mongo/#simplified-property-access","title":"Simplified Property Access","text":"

                                                                Behind the scenes the module builds a complex feature schema on the fly automatically along with the complex features being served. Every array or object in the document is considered to be a nested feature. This might result in a hard time trying to foreseen the xpath needed to access a feature property for styling or filtering purpose, because the internal nested feature representation follows the GML object property model.

                                                                To clarify this lets assume that we want to filter the stations features on a measurements value greater than 100. According to the above GeoJSON feature representation the whole filter will look like: measurements.MeasurementsFeature.values.ValuesFeature.value > 100.

                                                                The property path needs to specify for each nested complex attribute the property name and the feature name. The former coincides with the original attribute name in the document, while the latter with that attribute name with the first letter upper cased and the Feature suffix.

                                                                To avoid users needing to deal with this complexity, simplified property access support has been implemented. This allows referencing a property with a path that matches the GeoJSON output format or the document structure.

                                                                The previously defined filter could then be: measurements.values.value > 100.

                                                                As can be seen, the property path can be easily inferred both from the GeoJSON output and from the MongoDB document.

                                                                "},{"location":"community/smart-data-loader/","title":"Smart Data Loader Extension","text":"

                                                                This plugin allows automation of the configuration for Application-Schema based complex features, by providing a data source that will automatically generate the required XSD definition and App-Schema mappings files.

                                                                Warning

                                                                The current version only supports PostGIS datasources.

                                                                • Installing the Smart Data Loader extension
                                                                • Smart Data Loader
                                                                "},{"location":"community/smart-data-loader/data-store/","title":"Smart Data Loader","text":""},{"location":"community/smart-data-loader/data-store/#data-store","title":"Data Store","text":"

                                                                In addition to the parameters common to each DataStore configuration such as workspace, name and description, the page shows the following connection parameters in the dedicated section:

                                                                • Data store name: the name of the PostGIS DataStore already created under the same workspace. It will be used to access the database and build xsd and mappings file based on the database metadata.
                                                                • Root entity: the name of the DB table to be used as the root FeatureType to build the xsd and the mapping file.

                                                                Once selected the root entity a diagram of the entities available will appear. Uncheck the attributes that should not be included in the XSD and the mapping file.

                                                                "},{"location":"community/smart-data-loader/data-store/#meteo-stations-example","title":"Meteo Stations example","text":"

                                                                This section provides an example of configuring the DataStore with weather station information.

                                                                Note

                                                                This example is intended to be illustrative of a general approach, and does not reflect a formally defined schema or information model. Also, more complicated scenarios may require significantly more work.

                                                                A diagram of the entities involved is shown below:

                                                                Entities diagram

                                                                As shown, the dataset consists of:

                                                                • A One to Many relationship between the meteo_stations and meteo_observations tables.
                                                                • A Many to Many relationship between the meteo_stations and meteo_maintainers tables, mapped by the relation table meteo_stations_maintainers.
                                                                • A Many to One relationship between the meteo_observations and the meteo_parameters tables.

                                                                Assuming a PostGIS datastore named meteos-simple under the st workspace, by opening the Smart Data Loader page we will have to select the desired workspace and the postgis datastore belonging to the selected workspace, in this case the meteos-postgis one:

                                                                Smart Data Loader configuration page

                                                                After having selected the root entity as meteo-stations, a schema, which will be used to generate the XSD and mappings file, will appear. Each attribute/entity can be unchecked to avoid it being included in the generated mappings.

                                                                ..figure:: images/store-relations.png

                                                                Smart Data Loader configuration page - entities' tree

                                                                After pressing the save button, the files will be generated automatically in the store data-dir directory under app-schema-mappings directory.

                                                                The generated mappings file for this example are explained below.

                                                                GML schema definition:

                                                                <?xml version=\"1.0\" encoding=\"UTF-8\"?><xs:schema xmlns:gml=\"http://www.opengis.net/gml/3.2\" xmlns:st=\"http://www.stations.org/1.0\" xmlns:xs=\"http://www.w3.org/2001/XMLSchema\" attributeFormDefault=\"unqualified\" elementFormDefault=\"qualified\" targetNamespace=\"http://www.stations.org/1.0\" version=\"1.0\">\n<xs:import namespace=\"http://www.opengis.net/gml/3.2\" schemaLocation=\"http://schemas.opengis.net/gml/3.2.1/gml.xsd\"/>\n<xs:complexType name=\"MeteoStationsType\">\n  <xs:complexContent>\n    <xs:extension base=\"gml:AbstractFeatureType\">\n      <xs:sequence>\n        <xs:element maxOccurs=\"1\" minOccurs=\"0\" name=\"id\" type=\"xs:int\"/>\n        <xs:element maxOccurs=\"1\" minOccurs=\"0\" name=\"code\" type=\"xs:string\"/>\n        <xs:element maxOccurs=\"1\" minOccurs=\"0\" name=\"common_name\" type=\"xs:string\"/>\n        <xs:element maxOccurs=\"1\" minOccurs=\"0\" name=\"position\" type=\"gml:GeometryPropertyType\"/>\n        <xs:element maxOccurs=\"unbounded\" minOccurs=\"0\" name=\"meteoObservations\" type=\"st:MeteoObservationsPropertyType\"/>\n        <xs:element maxOccurs=\"unbounded\" minOccurs=\"0\" name=\"meteoStationsMaintainers\" type=\"st:MeteoStationsMaintainersPropertyType\"/>\n      </xs:sequence>\n    </xs:extension>\n  </xs:complexContent>\n</xs:complexType>\n<xs:element name=\"MeteoStationsFeature\" substitutionGroup=\"gml:AbstractFeature\" type=\"st:MeteoStationsType\"/>\n<xs:complexType name=\"MeteoObservationsType\">\n  <xs:complexContent>\n    <xs:extension base=\"gml:AbstractFeatureType\">\n      <xs:sequence>\n        <xs:element maxOccurs=\"1\" minOccurs=\"0\" name=\"id\" type=\"xs:int\"/>\n        <xs:element maxOccurs=\"1\" minOccurs=\"0\" name=\"time\" type=\"xs:dateTime\"/>\n        <xs:element maxOccurs=\"1\" minOccurs=\"0\" name=\"value\" type=\"xs:double\"/>\n        <xs:element maxOccurs=\"unbounded\" minOccurs=\"0\" name=\"meteoParameters\" type=\"st:MeteoParametersPropertyType\"/>\n      </xs:sequence>\n    </xs:extension>\n  </xs:complexContent>\n</xs:complexType>\n<xs:element name=\"MeteoObservationsFeature\" substitutionGroup=\"gml:AbstractFeature\" type=\"st:MeteoObservationsType\"/>\n<xs:complexType name=\"MeteoObservationsPropertyType\">\n  <xs:sequence minOccurs=\"0\">\n    <xs:element ref=\"st:MeteoObservationsFeature\"/>\n  </xs:sequence>\n  <xs:attributeGroup ref=\"gml:AssociationAttributeGroup\"/>\n</xs:complexType>\n<xs:complexType name=\"MeteoParametersType\">\n  <xs:complexContent>\n    <xs:extension base=\"gml:AbstractFeatureType\">\n      <xs:sequence>\n        <xs:element maxOccurs=\"1\" minOccurs=\"0\" name=\"id\" type=\"xs:int\"/>\n        <xs:element maxOccurs=\"1\" minOccurs=\"0\" name=\"param_name\" type=\"xs:string\"/>\n        <xs:element maxOccurs=\"1\" minOccurs=\"0\" name=\"param_unit\" type=\"xs:string\"/>\n      </xs:sequence>\n    </xs:extension>\n  </xs:complexContent>\n</xs:complexType>\n<xs:element name=\"MeteoParametersFeature\" substitutionGroup=\"gml:AbstractFeature\" type=\"st:MeteoParametersType\"/>\n<xs:complexType name=\"MeteoParametersPropertyType\">\n  <xs:sequence minOccurs=\"0\">\n    <xs:element ref=\"st:MeteoParametersFeature\"/>\n  </xs:sequence>\n  <xs:attributeGroup ref=\"gml:AssociationAttributeGroup\"/>\n</xs:complexType>\n<xs:complexType name=\"MeteoStationsMaintainersType\">\n  <xs:complexContent>\n    <xs:extension base=\"gml:AbstractFeatureType\">\n      <xs:sequence>\n        <xs:element maxOccurs=\"1\" minOccurs=\"0\" name=\"id\" type=\"xs:int\"/>\n        <xs:element maxOccurs=\"unbounded\" minOccurs=\"0\" name=\"meteoMaintainers\" type=\"st:MeteoMaintainersPropertyType\"/>\n      </xs:sequence>\n    </xs:extension>\n  </xs:complexContent>\n</xs:complexType>\n<xs:element name=\"MeteoStationsMaintainersFeature\" substitutionGroup=\"gml:AbstractFeature\" type=\"st:MeteoStationsMaintainersType\"/>\n<xs:complexType name=\"MeteoStationsMaintainersPropertyType\">\n  <xs:sequence minOccurs=\"0\">\n    <xs:element ref=\"st:MeteoStationsMaintainersFeature\"/>\n  </xs:sequence>\n  <xs:attributeGroup ref=\"gml:AssociationAttributeGroup\"/>\n</xs:complexType>\n<xs:complexType name=\"MeteoMaintainersType\">\n  <xs:complexContent>\n    <xs:extension base=\"gml:AbstractFeatureType\">\n      <xs:sequence>\n        <xs:element maxOccurs=\"1\" minOccurs=\"0\" name=\"id\" type=\"xs:int\"/>\n        <xs:element maxOccurs=\"1\" minOccurs=\"0\" name=\"name\" type=\"xs:string\"/>\n        <xs:element maxOccurs=\"1\" minOccurs=\"0\" name=\"surname\" type=\"xs:string\"/>\n        <xs:element maxOccurs=\"1\" minOccurs=\"0\" name=\"company\" type=\"xs:string\"/>\n      </xs:sequence>\n    </xs:extension>\n  </xs:complexContent>\n</xs:complexType>\n<xs:element name=\"MeteoMaintainersFeature\" substitutionGroup=\"gml:AbstractFeature\" type=\"st:MeteoMaintainersType\"/>\n<xs:complexType name=\"MeteoMaintainersPropertyType\">\n  <xs:sequence minOccurs=\"0\">\n    <xs:element ref=\"st:MeteoMaintainersFeature\"/>\n  </xs:sequence>\n  <xs:attributeGroup ref=\"gml:AssociationAttributeGroup\"/>\n</xs:complexType>\n</xs:schema>\n

                                                                App-Schema mappings file:

                                                                <?xml version=\"1.0\" encoding=\"UTF-8\"?><ns3:AppSchemaDataAccess xmlns:ns2=\"http://www.opengis.net/ogc\" xmlns:ns3=\"http://www.geotools.org/app-schema\">\n<namespaces>\n  <Namespace>\n    <prefix>gml</prefix>\n    <uri>http://www.opengis.net/gml/3.2</uri>\n  </Namespace>\n  <Namespace>\n    <prefix>st</prefix>\n    <uri>http://www.stations.org/1.0</uri>\n  </Namespace>\n</namespaces>\n<includedTypes/>\n<targetTypes>\n  <FeatureType>\n    <schemaUri>./meteo_stations-gml.xsd</schemaUri>\n  </FeatureType>\n</targetTypes>\n<typeMappings>\n  <FeatureTypeMapping>\n    <sourceDataStore>smartappschematest</sourceDataStore>\n    <sourceType>meteo_stations</sourceType>\n    <targetElement>st:MeteoStationsFeature</targetElement>\n    <attributeMappings>\n      <AttributeMapping>\n        <targetAttribute>st:MeteoStationsFeature</targetAttribute>\n        <idExpression>\n          <OCQL>strConcat('MeteoStationsFeature.',id)</OCQL>\n        </idExpression>\n      </AttributeMapping>\n      <AttributeMapping>\n        <targetAttribute>st:id</targetAttribute>\n        <sourceExpression>\n          <OCQL>id</OCQL>\n        </sourceExpression>\n      </AttributeMapping>\n      <AttributeMapping>\n        <targetAttribute>st:code</targetAttribute>\n        <sourceExpression>\n          <OCQL>code</OCQL>\n        </sourceExpression>\n      </AttributeMapping>\n      <AttributeMapping>\n        <targetAttribute>st:common_name</targetAttribute>\n        <sourceExpression>\n          <OCQL>common_name</OCQL>\n        </sourceExpression>\n      </AttributeMapping>\n      <AttributeMapping>\n        <targetAttribute>st:position</targetAttribute>\n        <sourceExpression>\n          <OCQL>position</OCQL>\n        </sourceExpression>\n      </AttributeMapping>\n      <AttributeMapping>\n        <targetAttribute>meteoObservations</targetAttribute>\n        <sourceExpression>\n          <linkField>FEATURE_LINK[1]</linkField>\n          <linkElement>st:MeteoObservationsFeature</linkElement>\n          <OCQL>id</OCQL>\n        </sourceExpression>\n      </AttributeMapping>\n      <AttributeMapping>\n        <targetAttribute>meteoStationsMaintainers</targetAttribute>\n        <sourceExpression>\n          <linkField>FEATURE_LINK[1]</linkField>\n          <linkElement>st:MeteoStationsMaintainersFeature</linkElement>\n          <OCQL>id</OCQL>\n        </sourceExpression>\n      </AttributeMapping>\n    </attributeMappings>\n  </FeatureTypeMapping>\n  <FeatureTypeMapping>\n    <sourceDataStore>smartappschematest</sourceDataStore>\n    <sourceType>meteo_observations</sourceType>\n    <targetElement>st:MeteoObservationsFeature</targetElement>\n    <attributeMappings>\n      <AttributeMapping>\n        <targetAttribute>FEATURE_LINK[1]</targetAttribute>\n        <sourceExpression>\n          <OCQL>station_id</OCQL>\n        </sourceExpression>\n      </AttributeMapping>\n      <AttributeMapping>\n        <targetAttribute>st:MeteoObservationsFeature</targetAttribute>\n        <idExpression>\n          <OCQL>strConcat('MeteoObservationsFeature.',id)</OCQL>\n        </idExpression>\n      </AttributeMapping>\n      <AttributeMapping>\n        <targetAttribute>st:id</targetAttribute>\n        <sourceExpression>\n          <OCQL>id</OCQL>\n        </sourceExpression>\n      </AttributeMapping>\n      <AttributeMapping>\n        <targetAttribute>st:time</targetAttribute>\n        <sourceExpression>\n          <OCQL>time</OCQL>\n        </sourceExpression>\n      </AttributeMapping>\n      <AttributeMapping>\n        <targetAttribute>st:value</targetAttribute>\n        <sourceExpression>\n          <OCQL>value</OCQL>\n        </sourceExpression>\n      </AttributeMapping>\n      <AttributeMapping>\n        <targetAttribute>meteoParameters</targetAttribute>\n        <sourceExpression>\n          <linkField>FEATURE_LINK[1]</linkField>\n          <linkElement>st:MeteoParametersFeature</linkElement>\n          <OCQL>parameter_id</OCQL>\n        </sourceExpression>\n      </AttributeMapping>\n    </attributeMappings>\n  </FeatureTypeMapping>\n  <FeatureTypeMapping>\n    <sourceDataStore>smartappschematest</sourceDataStore>\n    <sourceType>meteo_parameters</sourceType>\n    <targetElement>st:MeteoParametersFeature</targetElement>\n    <attributeMappings>\n      <AttributeMapping>\n        <targetAttribute>FEATURE_LINK[1]</targetAttribute>\n        <sourceExpression>\n          <OCQL>id</OCQL>\n        </sourceExpression>\n      </AttributeMapping>\n      <AttributeMapping>\n        <targetAttribute>st:MeteoParametersFeature</targetAttribute>\n        <idExpression>\n          <OCQL>strConcat('MeteoParametersFeature.',id)</OCQL>\n        </idExpression>\n      </AttributeMapping>\n      <AttributeMapping>\n        <targetAttribute>st:id</targetAttribute>\n        <sourceExpression>\n          <OCQL>id</OCQL>\n        </sourceExpression>\n      </AttributeMapping>\n      <AttributeMapping>\n        <targetAttribute>st:param_name</targetAttribute>\n        <sourceExpression>\n          <OCQL>param_name</OCQL>\n        </sourceExpression>\n      </AttributeMapping>\n      <AttributeMapping>\n        <targetAttribute>st:param_unit</targetAttribute>\n        <sourceExpression>\n          <OCQL>param_unit</OCQL>\n        </sourceExpression>\n      </AttributeMapping>\n    </attributeMappings>\n  </FeatureTypeMapping>\n  <FeatureTypeMapping>\n    <sourceDataStore>smartappschematest</sourceDataStore>\n    <sourceType>meteo_stations_maintainers</sourceType>\n    <targetElement>st:MeteoStationsMaintainersFeature</targetElement>\n    <attributeMappings>\n      <AttributeMapping>\n        <targetAttribute>FEATURE_LINK[1]</targetAttribute>\n        <sourceExpression>\n          <OCQL>station_id</OCQL>\n        </sourceExpression>\n      </AttributeMapping>\n      <AttributeMapping>\n        <targetAttribute>st:MeteoStationsMaintainersFeature</targetAttribute>\n        <idExpression>\n          <OCQL>strConcat('MeteoStationsMaintainersFeature.',id)</OCQL>\n        </idExpression>\n      </AttributeMapping>\n      <AttributeMapping>\n        <targetAttribute>st:id</targetAttribute>\n        <sourceExpression>\n          <OCQL>id</OCQL>\n        </sourceExpression>\n      </AttributeMapping>\n      <AttributeMapping>\n        <targetAttribute>meteoMaintainers</targetAttribute>\n        <sourceExpression>\n          <linkField>FEATURE_LINK[1]</linkField>\n          <linkElement>st:MeteoMaintainersFeature</linkElement>\n          <OCQL>maintainer_id</OCQL>\n        </sourceExpression>\n      </AttributeMapping>\n    </attributeMappings>\n  </FeatureTypeMapping>\n  <FeatureTypeMapping>\n    <sourceDataStore>smartappschematest</sourceDataStore>\n    <sourceType>meteo_maintainers</sourceType>\n    <targetElement>st:MeteoMaintainersFeature</targetElement>\n    <attributeMappings>\n      <AttributeMapping>\n        <targetAttribute>FEATURE_LINK[1]</targetAttribute>\n        <sourceExpression>\n          <OCQL>id</OCQL>\n        </sourceExpression>\n      </AttributeMapping>\n      <AttributeMapping>\n        <targetAttribute>st:MeteoMaintainersFeature</targetAttribute>\n        <idExpression>\n          <OCQL>strConcat('MeteoMaintainersFeature.',id)</OCQL>\n        </idExpression>\n      </AttributeMapping>\n      <AttributeMapping>\n        <targetAttribute>st:id</targetAttribute>\n        <sourceExpression>\n          <OCQL>id</OCQL>\n        </sourceExpression>\n      </AttributeMapping>\n      <AttributeMapping>\n        <targetAttribute>st:name</targetAttribute>\n        <sourceExpression>\n          <OCQL>name</OCQL>\n        </sourceExpression>\n      </AttributeMapping>\n      <AttributeMapping>\n        <targetAttribute>st:surname</targetAttribute>\n        <sourceExpression>\n          <OCQL>surname</OCQL>\n        </sourceExpression>\n      </AttributeMapping>\n      <AttributeMapping>\n        <targetAttribute>st:company</targetAttribute>\n        <sourceExpression>\n          <OCQL>company</OCQL>\n        </sourceExpression>\n      </AttributeMapping>\n    </attributeMappings>\n  </FeatureTypeMapping>\n</typeMappings>\n<sourceDataStores>\n  <DataStore>\n    <id>smartappschematest</id>\n    <parameters>\n      <Parameter>\n        <name>schema</name>\n        <value>smartappschematest</value>\n      </Parameter>\n      <Parameter>\n        <name>database</name>\n        <value>mock?sslmode=DISABLE&amp;binaryTransferEnable=bytea</value>\n      </Parameter>\n      <Parameter>\n        <name>port</name>\n        <value>5432</value>\n      </Parameter>\n      <Parameter>\n        <name>passwd</name>\n        <value>postgres</value>\n      </Parameter>\n      <Parameter>\n        <name>Expose primary keys</name>\n        <value>true</value>\n      </Parameter>\n      <Parameter>\n        <name>dbtype</name>\n        <value>postgis</value>\n      </Parameter>\n      <Parameter>\n        <name>host</name>\n        <value>localhost</value>\n      </Parameter>\n      <Parameter>\n        <name>user</name>\n        <value>postgres</value>\n      </Parameter>\n    </parameters>\n  </DataStore>\n</sourceDataStores>\n</ns3:AppSchemaDataAccess>\n
                                                                "},{"location":"community/smart-data-loader/data-store/#customize-smart-data-loader-generated-mappings-and-xsd-definition","title":"Customize smart-data-loader generated mappings and xsd definition","text":"

                                                                The Smart Data Loader does not allow direct modification of the mappings and XSD type definition. However it can be used as a starting point to generate configuration files that can be customized as required. This is the suggested workflow for such a use case:

                                                                • Create a new smart-data-loader store, select the desired PostGIS store, and then the root entity and save it.
                                                                • Go to the geoserver datadir and identify the Smart Data Loader store folder under the workspace that was selected while configuring it. An app-schema-mappings directory should be in that store folder.
                                                                • Copy and paste the files contained in that directory to another directory and modify them as needed.
                                                                • Delete the Smart Data Loader store, and create a new App-Schema store with a uri parameter pointing to the folder containing the modified files.
                                                                "},{"location":"community/smart-data-loader/install/","title":"Installing the Smart Data Loader extension","text":"

                                                                The Smart Data Loader extension is listed among the other extension downloads on the GeoServer download page.

                                                                The installation process is similar to other GeoServer extensions:

                                                                1. Download the Smart Data Loader nightly GeoServer community module from smart-data-loader.

                                                                  Verify that the version number in the filename corresponds to the version of GeoServer you are running (for example 2.24.2 above).

                                                                2. Make sure you have downloaded and installed the app-schema extension.

                                                                3. Extract the contents of the archive into the WEB-INF/lib directory in GeoServer. Make sure you do not create any sub-directories during the extraction process.

                                                                4. Restart GeoServer.

                                                                If installation was successful, you will see a new Smart Data Loader entry in the \"new Data Source\" menu.

                                                                Smart Data Loader entry

                                                                "},{"location":"community/solr/","title":"SOLR data store","text":"

                                                                SOLR is a popular search platform based on Apache Lucene project. Its major features include powerful full-text search, hit highlighting, faceted search, near real-time indexing, dynamic clustering, database integration, rich document (e.g., Word, PDF) handling, and most importantly for the GeoServer integration, geospatial search.

                                                                The latest versions of SOLR can host most basic types of geometries (points, lines and polygons) as WKT and index them with a spatial index.

                                                                Note

                                                                GeoServer does not come built-in with support for SOLR; it must be installed through this community module.

                                                                The GeoServer SOLR extension has been tested with SOLR version 4.8, 4.9, and 4.10.

                                                                The extension supports all WKT geometry types (all linear types, point, lines and polygons, SQL/MMcurves are not supported), plus \"bounding box\" (available starting SOLR 4.10). It does not support the solr.LatLonType type yet.

                                                                The following pages shows how to use the SOLR data store.

                                                                • SOLR layer configuration
                                                                • Loading spatial data into SOLR
                                                                • Optimize rendering of complex polygons
                                                                "},{"location":"community/solr/configure/","title":"SOLR layer configuration","text":""},{"location":"community/solr/configure/#mapping-documents-to-layers","title":"Mapping documents to layers","text":"

                                                                SOLR indexes almost free form documents, the SOLR instance has a collection of fields, and each document can contain any field, in any combination. On the other side, GeoServer organizes data in fixed structure feature types, and exposes data in separate layers. This leaves the question of how documents in the index should be organized into layers.

                                                                By default the store exposes a single layer, normally named after the SOLR collection the store is connected to, by publishing it one can decide which fields to include, and eventually add a filter to select which attributes it will contain.

                                                                This single layer can be published multiple times, giving each published layer a different name, set of selected attributes, and a different filter to select the documents contained in the layer.

                                                                "},{"location":"community/solr/configure/#installing-the-solr-extension","title":"Installing the SOLR extension","text":"
                                                                1. Download the SOLR extension from the nightly GeoServer community module builds.

                                                                  Warning

                                                                  Make sure to match the version of the extension to the version of the GeoServer instance.

                                                                2. If GeoServer is running, stop it.

                                                                3. Extract the contents of the archive into the WEB-INF/lib directory of the GeoServer installation.

                                                                4. Restart GeoServer, the SOLR data store should show up as an option when going through the new store creation workflow.

                                                                "},{"location":"community/solr/configure/#connecting-to-a-solr-server","title":"Connecting to a SOLR server","text":"

                                                                Once the extension is properly installed SOLR will show up as an option when creating a new data store.

                                                                SOLR in the list of vector data sources

                                                                "},{"location":"community/solr/configure/#community_solr_configure_store","title":"Configuring a SOLR data store","text":"

                                                                Configuring a SOLR data store

                                                                solr_url Provide a link to the SOLR server that provides the documents

                                                                Once the parameters are entered and confirmed, GeoServer will contact the SOLR server and fetch a list of layer names and fill the layer chooser page accordingly:

                                                                List of layers available in the SOLR server

                                                                "},{"location":"community/solr/configure/#configuring-a-new-solr-base-layer","title":"Configuring a new SOLR base layer","text":"

                                                                Once the layer name is chosen, the usual layer configuration panel will appear, with a pop-up showing in a table the fields available:

                                                                The layer field list configuration

                                                                Is empty Read only fields, checked if the field has no values in the documents associated to this layer Use Used to select the fields that will make up this layer features Name Name of the field Type Type of the field, as derived from the SOLR schema. For geometry types, you have the option to provide a more specific data type SRID Native spatial reference ID of the geometries Default geometry Indicates if the geometry field is the default one. Useful if the documents contain more than one geometry field, as SLDs and spatial filters will hit the default geometry field unless otherwise specified Identifier Check if the field can be used as the feature identifier

                                                                By default the list will contain only the fields that have at least one non null value in the documents associated to the layer, but it is possible to get the full list by un-checking the \"Hide field if empty\" check-box:

                                                                Showing all fields available in SOLR

                                                                Once the table is filled with the all the required parameters, press the \"Apply\" button to confirm and go back to the main layer configuration panel. Should the choice of fields be modified, you can click the \"Configure SOLR fields\" just below the \"Feature Type Details\" panel.

                                                                Going back to the field list editor

                                                                The rest of the layer configuration works as normal, once all the fields are provided you'll be able to save and use the layer in WMS and WFS.

                                                                Warning

                                                                In order to compute the bounding box GeoServer will have to fetch all the geometries making up the layer out of SOLR, this operation might take some time, you're advised to manually entered the native bounding box when configuring a layer out of a large document set

                                                                "},{"location":"community/solr/configure/#custom-q-and-fq-parameters","title":"Custom q and fq parameters","text":"

                                                                The SOLR store will translate most OGC filters, as specified in SLD, CQL Filter or OGC filter, down into the SOLR engine for native filtering, using the fq parameter. However, in some occasions you might need to specify manually either q or fq, to leverage some native SOLR filtering ability that cannot be expressed via OGC filters.

                                                                This can be done by specifying those as viewparams, pretty much like in parametric sql views atop relational databases.

                                                                For example, the following URL:

                                                                http://localhost:8080/geoserver/nurc/wms?service=WMS&version=1.1.0&request=GetMap\n     &layers=nurc:active&styles=geo2&bbox=0.0,0.0,24.0,44.0&width=279&height=512\n     &srs=EPSG:4326&format=application/openlayers\n     &viewparams=fq:security_ss:WEP\n

                                                                Will send down to SOLR a query looking like:

                                                                omitHeader=true&fl=geo,id&q=*:*&rows=2147483647&sort=id asc\n&fq=status_s:active AND geo:\"Intersects(POLYGON ((-0.125 -0.5333333333333333, -0.125 44.53333333333333, \n24.125 44.53333333333333, 24.125 -0.5333333333333333, -0.125 -0.5333333333333333)))\"\n&fq=security_ss:WEP&cursorMark=*\n

                                                                You can notice that:

                                                                • Only the columns needed for the display (in this case, a single geometry) are retrieved
                                                                • The bbox and layer identification filters are specified in the first fq
                                                                • The custom fq is passed as a second fq parameter (SOLR will treat it as being and-ed with the previous one)
                                                                "},{"location":"community/solr/load/","title":"Loading spatial data into SOLR","text":"

                                                                This section provides a simple example on how to convert and load a shapefile into a SOLR instance. For more advanced needs and details about spatial support in SOLR consult the SOLR documentation, making sure to read the one associated to the version at hand (spatial support is still rapidly evolving).

                                                                The current example has been developed and tested using GDAL 1.11 and SOLR 4.8, different versions of the tools and server might require a different syntax for upload.

                                                                The SOLR instance is supposed to have the following definitions in its schema:

                                                                <field name=\"geo\" type=\"location_rpt\" indexed=\"true\" stored=\"true\" multiValued=\"true\" />  \n<dynamicField name=\"*_i\"  type=\"int\"    indexed=\"true\"  stored=\"true\"/>\n<dynamicField name=\"*_s\"  type=\"string\"  indexed=\"true\"  stored=\"true\" />\n

                                                                The above defines \"geo\" as explicit fields, leaving the other types to dynamic field interpretation.

                                                                The SpatialRecursivePrefixTreeFieldType accepts geometries as WKT, so as a preparation for the import we are going to turn a shapefile into a CSV file with WKT syntax for the geometry. Let's also remember that SOLR needs a unique id field for the records, and that the coordinates are supposed to be in WGS84. The shapefile in question is instead in UTM, has a linestring geometry, and some fields, cat,id and label.

                                                                The following command translates the shapefile in CSV (the command should be typed in a single line, it has been split over multiple lines for ease of reading):

                                                                ogr2ogr  -f CSV \n         -sql 'select FID as id, cat as cat_i, label as label_s, \n              \"roads\" as layer FROM roads' \n         -lco geometry=AS_WKT -s_srs \"EPSG:26713\" -t_srs \"EPSG:4326\"  \n         /tmp/roads.csv roads.shp\n

                                                                Some observations:

                                                                • The SQL is used mostly to include the special FID field into the results (a unique field is required)
                                                                • The reprojection is performed to ensure the output geometries are in WGS84
                                                                • The layer_s dynamic field is added to

                                                                This will generate a CSV file looking as follows:

                                                                WKT,id,cat_i,label_s,layer\n\"LINESTRING (-103.763291353072518 44.375039982911382,-103.763393874038698 44.375282535746727,-103.764152625689903 44.376816068582023,-103.763893508430911 44.377653708326527,-103.76287152579593 44.378473197876396,-103.762075892308829 44.379009292692757,-103.76203441159079 44.379195585236509,-103.762124217456204 44.379295262047272,-103.762168141872152 44.379399997909999,-103.762326134985983 44.379527769244149,-103.763328403265064 44.380245486928708,-103.764011871363465 44.381295133519728,-103.76411460103661 44.381526706124056,-103.764953940327757 44.382396618315049,-103.765097289111338 44.382919576408355,-103.765147974157941 44.383073790503197,-103.76593766187851 44.384162856249255,-103.765899236602976 44.384607239970421,-103.765854384388703 44.384597320206453)\",0,5,unimproved road,roads\n\"LINESTRING (-103.762930948900078 44.385847721442218,-103.763012156628747 44.386002223293282,-103.763510654805799 44.386297912655408,-103.763869052966967 44.386746022746649,-103.763971116268394 44.387444295314552,-103.764244098825387 44.387545690358827,-103.764264649212294 44.387677659170357,-103.764160551326043 44.387951214930865,-103.764540576800869 44.388042632912118,-103.764851624437995 44.388149874425885,-103.764841258550391 44.388303515682807,-103.76484332449354 44.388616502755184,-103.765188923261391 44.388927221995502,-103.765110961905023 44.389448103450221,-103.765245311197177 44.389619574129583,-103.765545516097987 44.389907903843323,-103.765765403056434 44.390420596862072,-103.766285436779711 44.391655378673697,-103.766354640463163 44.39205684519964,-103.76638734105434 44.392364628456725,-103.766410556756725 44.392776645318136,-103.765934443919321 44.393365174368313,-103.766220869020188 44.393571013181166,-103.766661604125247 44.393684955690581,-103.767294323528063 44.393734806102117,-103.767623238680557 44.394127721518785,-103.769273719703676 44.394900867042516,-103.769609703946827 44.395326786724503,-103.769732072038536 44.395745219647871,-103.769609607364416 44.396194309461826,-103.769310708537489 44.396691166475954,-103.768865902286791 44.397236074649896)\",1,5,unimproved road,roads\n

                                                                At this point the CSV can be imported into SOLR using CURL:

                                                                curl \"http://solr.geo-solutions.it/solr/collection1/update/csv?commit=true&separator=%2C&fieldnames=geo,id,cat_i,label_s,layer_s&header=true\" \n     -H 'Content-type:text/csv; charset=utf-8' --data-binary @/tmp/roads.csv\n

                                                                Some observations:

                                                                • The files gets uploaded as a text/csv file, older versions might require a text/plain mime type
                                                                • The fieldnames overrides the CSV header and allows us to specify the field name as expected by SOLR

                                                                At this point it's possible to configure a layer showing only the roads in the GeoServer UI:

                                                                Setting up the roads layer

                                                                After setting the bounding box and the proper style, the layer preview will show the roads stored in SOLR:

                                                                Preview roads from SOLR layer

                                                                "},{"location":"community/solr/optimize/","title":"Optimize rendering of complex polygons","text":"

                                                                Rendering large maps with complex polygons, to show the overall distribution of the data, can take a significant toll, especially if GeoServer cannot connect to the SOLR server via a high speed network.

                                                                A common approach to handle this issue is to add a second geometry to the SOLR documents, representing the centroid of the polygon, and using that one to render the features when fairly zoomed out.

                                                                Once the SOLR documents have been updated with a centroid column, and it has been populated, the column can be added as a secondary geometry. Make sure to keep the polygonal geometry as the default one:

                                                                ... (other fields omitted)

                                                                Configuring a layer with multiple geometries

                                                                With this setup the polygonal geometry will still be used for all spatial filters, and for rendering, unless the style otherwise specifical demands for the centroid.

                                                                Then, a style with scale dependencies can be setup in order to fetch only then centroids when fairly zoomed out, like in the following CSS example: :

                                                                [@scale > 50000] {\n  geometry: [centroid];\n  mark: symbol(square);\n}\n:mark {\n  fill: red;\n  size: 3;\n}\u200b\n[@scale <= 50000] {\n  fill: red;\n  stroke: black;\n}\n

                                                                Using this style the spatial field will still be used to resolve the BBOX filter implicit in the WMS requests, but only the much smaller centroid one will be transferred to GeoServer for rendering.

                                                                "},{"location":"community/spatialjson/","title":"SpatialJSON WFS Output Format Extension","text":"

                                                                This module adds the SpatialJSON WFS output format. The SpatialJSON format is a more compact and memory-friendly variant of GeoServer's GeoJSON format. It aims to save space by applying several optimizations to traditional GeoJSON format for simple feature results. Most of these optimizations work by removing redundand information from the JSON-encoded features.

                                                                A service exception is thrown if the result contains complex features as the SpatialJSON format does not handle those.

                                                                Note

                                                                The SpatialJSON format is not compatible with GeoJSON. A SpatialJSON enabled reader is required to decode features transferred in SpatialJSON format.

                                                                This module adds two additional WFS output formats for requesting simple features in SpatialJSON format:

                                                                • application/json; subtype=json/spatial for requesting SpatialJSON
                                                                • text/javascript; subtype=json/spatial for requesting SpatialJSON as a JSONP request

                                                                Warning

                                                                At the time of writing, this format is still work in progress and changes may be applied in the future.

                                                                • Installation
                                                                • Development Status
                                                                • Opt. 1: Removing Redundant Schema Information
                                                                • Opt. 2: Removing Redundant Attribute Values
                                                                "},{"location":"community/spatialjson/attributes/","title":"Opt. 2: Removing Redundant Attribute Values","text":""},{"location":"community/spatialjson/attributes/#shared-string-table","title":"Shared String Table","text":"

                                                                A SpatialJSON response may contain a Shared String Table, which may contain strings that are referenced by some features' properties. Only properties expressed as JSON strings can be stored in a shared string table (at current, temporal values, like Dates and Timestamps, which are expressed as strings as well, are not stored in a shared string table).

                                                                If present, a new \"sharedStrings\" property is available in the top-level \"FeatureCollection\" object:

                                                                {\n  \"type\": \"FeatureCollection\",\n\n  \"$note\": \" /* remaining properties go here */ \",\n\n  \"schemaInformation\": {\n    \"propertyNames\": [\"str_1\", \"num_2\", \"str_3\", \"str_4\", \"bool_5\"],\n    \"geometryName\": \"the_geom\"\n  },\n  \"sharedStrings\": {\n    \"indexes\": [0, 2, 3],\n    \"table\": [\"Lorem ipsum dolor sit amet,\",\n              \"consetetur sadipscing elitr,\",\n              \"sed diam nonumy eirmod tempor invidunt ut labore\",\n              \"et dolore magna aliquyam erat,\",\n              \"sed diam voluptua.\"]\n  }\n}\n

                                                                It contains these two properties:

                                                                • \"table\" - Contains the shared strings. These are referenced by their index in the array.
                                                                • \"indexes\" - Contains the zero-based indexes of feature properties that may be stored in this shared string table.

                                                                In SpatialJSON, a feature's properties are basically stored in an array only (in contrast to GeoJSON which stores properties in an object). The \"indexes\" array contains the indexes in these properties arrays that may have their values stored in the shared string table. In a feature's property array, such a value may actually be either null, a regular JSON string or a JSON number (integral number). In the latter case, the property's value is actually stored in the shared string table, the value being used as the index into the shared string table.

                                                                These examples show how some feature's properties arrays are evaluated using the above string table:

                                                                /* showing properties array of feature #1 */\nproperties: [\"foo\", 23, 2, null, true]\n\n/* gets evaluated to */\nproperties: {\n  \"str_1\": \"foo\",\n  \"num_2\": 23,\n  \"str_3\": \"sed diam nonumy eirmod tempor invidunt ut labore\",\n  \"str_4\": null,\n  \"bool_5\": true\n}\n\n/* showing properties array of feature #2 */\nproperties: [1, 32, \"K\", 3, false]\n\n/* gets evaluated to */\nproperties: {\n  \"str_1\": \"consetetur sadipscing elitr\",\n  \"num_2\": 32,\n  \"str_3\": \"K\",\n  \"str_4\": \"et dolore magna aliquyam erat\",\n  \"bool_5\": false\n}\n

                                                                As the examples show, there is no guarantee that all strings of a property whose index is part of the sharedStrings.indexes array are actually stored in the shared string table.

                                                                "},{"location":"community/spatialjson/attributes/#spatialjson-writer-implementation","title":"SpatialJSON Writer Implementation","text":"

                                                                It is completely up to the SpatialJSON writer to decide, which strings to add to the shared string table. Several strategies can be used. However, the current implementation in this module makes no attempt to create an optimal shared string table. In order to be fast, strings are added as they come when features are serialized. Building an optimal table would likely require iterating features several times, calculating frequencies of strings, etc.

                                                                Nevertheless, this module's SpatialJSON writer has some simple rules for building the shared string table. Even for worst case scenarios, these try (at least) not to use (much) more bytes than needed for the same result without using a shared string table. (In theory, there are cases in which the shared string table adds some extra bytes to the result.) However, for most real world datasets, this strategy could save a moderate to significant number of bytes.

                                                                These are the rules that prevent a string from being added to the shared string table:

                                                                • The string's UTF-8 encoded byte length is less than a hard-coded minimum (currently 2, may be configurable in the future)
                                                                • The shared sting table is full, that is, it contains 2,147,483,647 entries (not really expected)
                                                                • The string's UTF-8 encoded byte length (including quotes) is less than the number of digits of it's designated index

                                                                Obviously, most savings can be achieved if a dataset contains only a few different large strings. That may be the case for attributes, that contain values of an enumeration, for example. The more often a certain string is used in the dataset, the more space can be saved by using a shared string table. In contrast, if every string in the set of encoded features is used only once (e. g. attributes that contain random or UUID-like strings), no savings will be achieved (in fact, using a shared string table in that case will produce even slightly bigger results).

                                                                "},{"location":"community/spatialjson/attributes/#shared-strings-per-request-customization","title":"Shared Strings per Request Customization","text":"

                                                                By default, the current implementation will add all JSON string encoded properties to the shared string table. (Except temporal values, like Dates and Timestamps, which in JSON technically are strings as well. However, we do not expect much redundancy in temporal values.) With the format_options vendor parameter it is possible to specify which properties can store values in the shared string table or to completely skip the creation of such a table.

                                                                The supported format option is:

                                                                • sharedstrings (default is *) - Specify false or leave empty (e. g. format_options=sharedstrings:) to skip shared string table generation, or true or * to create a table including all JSON string encoded properties (that is the default behavior). Alternatively, a comma-separated list of property names could specify the set of properties that may store their values in the shared string table.

                                                                When a comma-separated list of property names is specified for the sharedstrings format option, these additional rules apply:

                                                                • Commas in property names (really?) may be escaped with a backslash character ``.

                                                                • The prefix re: may be prepended to the list in order to designate each item a Java Regular Expression: (e. g. format_options=sharedstrings:re:adm_.*,\\d\\d_[a-z]+$). See Java Pattern class.

                                                                  Specifying an invalid regular expression results in a Service Exception.

                                                                • The prefix glob: may be prepended to the list in order to designate each item a glob pattern: (e. g. format_options=sharedstrings:glob:adm_*,[0-9][0-9]_*name). See glob patterns.

                                                                  Specifying an invalid glob pattern results in a Service Exception.

                                                                Although the SpatialJSON Shared String Table feature works fine and typically saves a moderate number of bytes for arbitrary datasets in its default configuration, that is without specifying the sharedstrings format option, this parameter provides a solid handle for advanced fine tuning of the string table's creation process.

                                                                "},{"location":"community/spatialjson/development/","title":"Development Status","text":"

                                                                The SpatialJSON format is still a playground for implementing several optimizations to transfer even huge amounts of spatial data from the server to the client efficiently:

                                                                1. Opt. 1: Removing redundant schema information, see topic
                                                                2. Opt. 2: Removing redundant attribute values (e. g. shared string table), see topic
                                                                3. Opt. 3: Handling sparse rows (most values are NULL) more efficiently
                                                                4. Opt. 4: Reducing space required for geometries (e. g. differential coordinates)

                                                                Bold items have already been implemented.

                                                                The shown optimizations are ordered from simple to implement to hard to implement (not really hard, however). That's also the intended order of implementation. Although some optimizations are optional, all optimizations could be in effect at the same time. Then, each optimization contributes his part to lower the space required for encoding a certain set of features.

                                                                In some cases, however, it may be useful to specify which optimizations shall be used for a request. Several techniques are available to give a client the ability to specify the set of SpatialJSON optimizations it is able or willing to use (e. g. parameter format_options, additional outputFormat parameters). It's still not clear how this will be implemented and how fine grained that will be.

                                                                "},{"location":"community/spatialjson/installation/","title":"Installation","text":""},{"location":"community/spatialjson/installation/#manual-installation","title":"Manual Installation","text":"

                                                                To download and install the required extensions by hand:

                                                                1. Download the geoserver- 2.24.2-spatialjson-plugin.zip from:

                                                                  • Community Builds (GeoServer WebSite)

                                                                  It is important to download the version that matches the GeoServer you are running.

                                                                2. Stop the GeoServer application.

                                                                3. Navigate into the webapps/geoserver/WEB-INF/lib folder.

                                                                  These files make up the running GeoServer application.

                                                                4. Unzip the contents of the zip file into the lib folder.

                                                                5. Restart the Application Server.

                                                                After restarting the Application Server the SpatialJSON WFS output format is available and ready to use.

                                                                "},{"location":"community/spatialjson/schema/","title":"Opt. 1: Removing Redundant Schema Information","text":"

                                                                In traditional GeoJSON, every feature in a (simple feature) feature collection has its own schema information. That is, every feature contains all its (not necessarily short) attribute names. Except the geometry name, these names are used as the keys in the \"properties\" map:

                                                                {\n  \"type\": \"FeatureCollection\",\n  \"features\": [\n    {\n      \"type\": \"Feature\",\n      \"id\": \"areas.1\",\n      \"geometry\": {\n        \"type\": \"Point\",\n        \"coordinates\": [590529, 4914625]\n      },\n      \"geometry_name\": \"the_geom\",\n      \"properties\": {\n        \"area_no\": 12,\n        \"area_name\": \"Mainland\",\n        \"area_description\": \"grassland\",\n        \"area_cost_center\": \"0815\"\n      }\n    },\n    {\n      \"type\": \"Feature\",\n      \"id\": \"areas.2\",\n      \"geometry\": {\n        \"type\": \"Point\",\n        \"coordinates\": [590215, 4913987]\n      },\n      \"geometry_name\": \"the_geom\",\n      \"properties\": {\n        \"area_no\": 17,\n        \"area_name\": \"South region\",\n        \"area_description\" : \"meadow, pasture\",\n        \"area_cost_center\": \"0812\"\n      }\n    }\n  ],\n  \"totalFeatures\": 2,\n  \"numberMatched\": 2,\n  \"numberReturned\": 2,\n  \"timeStamp\": \"2022-10-17T08:12:45.248Z\",\n  \"crs\": {\n    \"type\": \"name\",\n    \"properties\": {\n      \"name\": \"urn:ogc:def:crs:EPSG::26713\"\n    }\n  }\n}\n

                                                                Since all features have the same schema information, SpatialJSON does not write attribute names for every feature. Instead, a single \"schemaInformation\" property is added to the end of the top-level \"FeatureCollection\" object:

                                                                {\n  \"type\": \"FeatureCollection\",\n  \"features\": [\n    {\n      \"type\": \"Feature\",\n      \"id\": \"areas.1\",\n      \"geometry\": {\n        \"type\": \"Point\",\n        \"coordinates\": [590529, 4914625]\n      },\n      \"properties\": [12, \"Mainland\", \"grassland\", \"0815\"]\n    },\n    {\n      \"type\": \"Feature\",\n      \"id\": \"areas.2\",\n      \"geometry\": {\n        \"type\": \"Point\",\n        \"coordinates\": [590215, 4913987]\n      },\n      \"properties\": [17, \"South region\", \"meadow, pasture\", \"0812\"]\n    }\n  ],\n  \"totalFeatures\": 2,\n  \"numberMatched\": 2,\n  \"numberReturned\": 2,\n  \"timeStamp\": \"2022-10-17T08:14:36.521Z\",\n  \"crs\": {\n    \"type\": \"name\",\n    \"properties\": {\n      \"name\": \"urn:ogc:def:crs:EPSG::26713\"\n    }\n  },\n  \"schemaInformation\": {\n    \"propertyNames\": [\"area_no\", \"area_name\", \"area_description\", \"area_cost_center\"],\n    \"geometryName\": \"the_geom\"\n  }\n}\n

                                                                With SpatialJSON, each feature's \"properties\" map becomes an ordered list (array) whose index corresponds to the \"propertyNames\" array that holds the attribute names in the new \"schemaInformation\" object. Additionally, the repeated property \"geometry_name\" is replaced by a single property named \"geometryName\" in the new schema information object.

                                                                "},{"location":"community/spatialjson/schema/#evaluation","title":"Evaluation","text":"

                                                                In the above example, without whitespaces and line breaks, savings in space are only about 5%. With much more features savings could reach almost 27% (the ratio of the sizes of a GeoJSON and a SpatialJSON feature object), that is, the size of the SpatialJSON response is only 73% of the size of a traditional GeoJSON response. More savings are possible with more attributes per feature. Savings basically depend on the ratio between schema information size and data size. In tests requesting several thousands of simple features with 200+ columns/attributes savings up to 70% have been achieved.

                                                                These savings drop to between \\~50% and \\~3% when a compressing content encoding method (like gzip, deflate or brotli) is used on the wire. However, it's not all about transfer size. The smaller the uncompressed JSON response, the lesser characters the client has to parse. Smaller uncompressed responses are also much more memory-friendly on both the server and the client side.

                                                                "},{"location":"community/stac-datastore/","title":"STAC Datastore extension","text":"

                                                                This plugin adds a vector data store that can connect to a STAC API, delivering collections as feeare types, and items as features.

                                                                Warning

                                                                The current version requires a STAC API RC1 with the \"search\" conformance class. It will works best if the API supports field selection, sorting and CQL2 filtering, but can fall back on in-memory operations if they are not natively supported.

                                                                • Installing the STAC data store
                                                                • STAC data store
                                                                "},{"location":"community/stac-datastore/data-store/","title":"STAC data store","text":""},{"location":"community/stac-datastore/data-store/#configuring-a-store","title":"Configuring a Store","text":"

                                                                In addition to the parameters common to each DataStore configuration such as workspace, name and description, and the common HTTP connector parameters, such as connection pooling, using GZIP, user name and password, the page shows the following connection parameters in the dedicated section:

                                                                • landingPage: this should point to the landing page of the target STAC API
                                                                • fetchSize: how many items the store will try to fetch per page. The actual number is in control of the server, the store will simply try to suggest this value.
                                                                • featureTypeItems: how many items to read in order to guess the structure of the feature type (GeoServer in general needs a predictable structure)
                                                                • hardLimit: maximum amount of items to fetch from the STAC store, in any request (it's a good idea to pose a limit, as many STAC APIs host millions of items, and the data transfer is not particularly efficient due to the large size of items, and the paged transfer)

                                                                STAC datastore configuration

                                                                STAC items are multi-temporal, so it's advisable to configure the time dimension when setting up the layer, using the datetime attribute. This will allow time navigation and reduce the number of items returned to a more manageable subset:

                                                                Setting up time for the layers

                                                                "},{"location":"community/stac-datastore/data-store/#mosaicking-images-from-a-stac-store","title":"Mosaicking images from a STAC store","text":"

                                                                STAC items may point to actual image files among its \"assets\" data structure. Assets are a top level object, not part of the Feature properties, that the store makes available to the image mosaic for image mosaicking purposes. The images in question must be Cloud Optimized GeoTIFFs and the COG plugin must be installed in GeoServer.

                                                                The STAC store can then be used as the index of an image mosaic, setting up two configuration files:

                                                                • A datastore.properties pointing at the configured STAC server.
                                                                • A indexer.properties indicating the collection to use, setup for the COG usage, and the location of the asset providing the images.
                                                                "},{"location":"community/stac-datastore/data-store/#simple-mosaic-setup","title":"Simple mosaic setup","text":"

                                                                Here is an example datastore.properties, pointing at an existing STAC store already configured in GeoServer:

                                                                StoreName=stac\\:dlr-eoc\n

                                                                And here is an indexer.properties:

                                                                MosaicCRS=EPSG\\:4326\nTimeAttribute=datetime\nAbsolutePath=true\nName=WSF_2019\nCog=true\nHeterogeneous=true\nHeterogeneousCRS=false\nTypeName=WSF_2019\nUseExistingSchema=true\nLocationAttribute=assets/wsf2019/href\nMaxInitTiles=10\n

                                                                Notes about the file contents:

                                                                • The time dimension is set up and linked to the datetime attribute
                                                                • The mosaic is setup to allow heterogeneous resolution images, but in this particular case, assumes that all images are in the same CRS.
                                                                • The TypeName property points to the target STAC collection.
                                                                • The LocationAttribute uses a JSONPointer to the desired asset URL.
                                                                • MaxInitTiles is configured so that the image mosaic does not try to scan the entire index to figure out a common image structure, only the first 10 items returned by the STAC API will be used for auto-configuration.
                                                                "},{"location":"community/stac-datastore/data-store/#multi-band-mosaic-setup","title":"Multi-band mosaic setup","text":"

                                                                It's also possible to mosaic images whose bands are offered as separate images and in different coordinate reference systems, with a more complex setup. Here is an example for a false color Sentinel 2 mosaic, using a coverage view to merge the images back into a single RGB composite.

                                                                The datastore.properties configures two new properties, enabling query caching (as the coverage view machinery will load each band in turn, repeating the same queries):

                                                                StoreName=stac\\:dlr-loose\nQueryCacheMaxAge=10000\nQueryCacheMaxFeatures=1000\n

                                                                The indexer must instead be provided in XML format, to configure multiple coverage and their attributes:

                                                                <?xml version=\"1.0\" encoding=\"UTF-8\" standalone=\"yes\"?>\n<Indexer>\n  <domains>\n     <domain name=\"time\">\n       <attributes><attribute>datetime</attribute></attributes>\n     </domain>\n     <domain name=\"crs\">\n       <attributes><attribute>proj:epsg</attribute></attributes>\n     </domain>\n  </domains>\n  <coverages>\n    <coverage>\n      <name>B04</name>\n      <domains>\n        <domain ref=\"time\" />\n        <domain ref=\"crs\" />\n      </domains>\n      <parameters>\n          <parameter name=\"LocationAttribute\" value=\"assets/B04/href\" />\n      </parameters>\n    </coverage>\n    <coverage>\n      <name>B03</name>\n      <domains>\n        <domain ref=\"time\" />\n        <domain ref=\"crs\" />\n      </domains>\n      <parameters>\n          <parameter name=\"LocationAttribute\" value=\"assets/B03/href\" />\n      </parameters>\n    </coverage>\n    <coverage>\n      <name>B02</name>\n      <domains>\n        <domain ref=\"time\" />\n        <domain ref=\"crs\" />\n      </domains>\n      <parameters>\n          <parameter name=\"LocationAttribute\" value=\"assets/B02/href\" />\n      </parameters>\n    </coverage>\n  </coverages>\n  <parameters>\n      <parameter name=\"MosaicCRS\" value=\"EPSG:4326\" />\n      <parameter name=\"AbsolutePath\" value=\"true\" />\n      <parameter name=\"Cog\" value=\"true\" />\n      <parameter name=\"Heterogeneous\" value=\"true\" />\n      <parameter name=\"HeterogeneousCRS\" value=\"true\" />\n      <parameter name=\"UseExistingSchema\" value=\"true\" />\n      <parameter name=\"TypeName\" value=\"S2_L2A_MSI_COG\" />\n      <parameter name=\"MaxInitTiles\" value=\"10\"/>\n  </parameters>\n</Indexer>\n

                                                                Some notes about the configuration:

                                                                • The time and crs attributes are declared as dimensions.
                                                                • Each coverage has a different LocationAttribute specification.
                                                                • The mosaic heterogeneous CRS support is enabled.

                                                                Once the mosaic is configured in GeoServer, create a new coverage view setting up the bands according to the desired order:

                                                                Creating a coverage view from a multi-band mosaic

                                                                Also remember to configure the time dimension for this layer, for the same reasons explained in the vector data section above.

                                                                "},{"location":"community/stac-datastore/install/","title":"Installing the STAC data store","text":"

                                                                The STAC store community module is listed among the other community modules on the GeoServer download page.

                                                                The installation process is similar to other GeoServer extensions:

                                                                1. Download the STAC store nightly GeoServer community module from stac-datastore.

                                                                  Verify that the version number in the filename corresponds to the version of GeoServer you are running (for example 2.24.2 above).

                                                                2. Extract the contents of the archive into the WEB-INF/lib directory in GeoServer. Make sure you do not create any sub-directories during the extraction process.

                                                                3. Restart GeoServer.

                                                                If installation was successful, you will see a new STAC datastore entry in the \"new Data Source\" menu.

                                                                STAC datastore entry

                                                                "},{"location":"community/taskmanager/","title":"Geoserver Task Manager","text":"

                                                                The GeoServer Task Manager is a tool that allows scheduled tasks and batches to run inside a GeoServer instance. The initial purpose of the task manager was to synchronize data and metadata between different geoserver instances and their data sources, as to automise and assist a particular workflow within an organisation that includes pre-tested publications and frequent updates. However, the task manager offers an extensive and flexible API that makes it possible to write any kind of extensions and customisations, allowing other purposes as well.

                                                                • Basic Concepts
                                                                • TaskManager User Guide
                                                                • Developer's Guide
                                                                "},{"location":"community/taskmanager/basic/","title":"Basic Concepts","text":"

                                                                The two main kinds of objects of the Task Manager are configurations and batches. Task Manager also allows the creation of Templates for configurations.

                                                                "},{"location":"community/taskmanager/basic/#configurations","title":"Configurations","text":"

                                                                The configuration is the central object in the Task Manager. A configuration is typically linked to a data object, such as a GeoServer layer, and serves as an entry point to the tasks and batches related to this data object.

                                                                A configuration has a unique name, a description and a workspace. It contains three groups of objects:

                                                                • Attributes: The attributes contain information about this configuration that can be shared between the different tasks of this configuration. An attribute has a name and a value. Each attribute is associated with at least one task parameter (see below). Attributes inherit their validation properties from their associated parameters, such as its accepted values and whether it is required.
                                                                • Tasks: Each task configures an operation that can be executed on this configuration. Each task has a name that is unique within the configuration, a type and a list of parameters with each a name and a value. The full name of a task is donated as configuration-name/task-name (which serves as a unique identifier for the task). The task's type is chosen from a list of available task types which define different kinds of operations (for example: copy a database table, publish a layer, ..) and expects a list of parameters that each has a name and a type. A parameter may or may not be required. The parameter type defines the accepted values of the parameter. Parameter types are dependent types when the list of accepted values depends on the value of another parameter (for example: tables inside a database). A parameter value is either a literal or a reference to an attribute of the form ${attribute-name}.
                                                                • Batches.
                                                                "},{"location":"community/taskmanager/basic/#batches","title":"Batches","text":"

                                                                A batch is made of an ordered sequence of tasks that can either be run on demand or be scheduled to run repeatedly at specific times. There are two kinds of batches:

                                                                • Configuration batches: these are batches that belong to a configuration. All of the tasks inside this batch are tasks that belong to that same configuration.
                                                                • Independent batches: these are batches that do not belong to a configuration. They may contains tasks from any existing configuration.

                                                                A batch has a name, a description and a workspace. The name of a batch must be unique amongst its configuration or amongst all independent batches. The full name of a batch is denoted as [configuration-name:]batch-name which serves as a unique identifier for the batch.

                                                                Configuration batches that have a name starting with a @, are hidden from the general batch overview and are only accessible from their configuration. Hidden batch names may be reserved for special functions. At this point, there is only one such case (see Initializing templates).

                                                                A batch can be run manually if the following conditions are met:

                                                                • the list of tasks is non-empty;
                                                                • the operating user has the security rights to do so (see Security).

                                                                A batch will be run automatically on its scheduled time if the following conditions are met:

                                                                • the list of tasks is non-empty;
                                                                • the batch is enabled;
                                                                • the batch has a frequency configured other than NEVER;
                                                                • the batch is independent or its configuration has been completed, i.e. validated without errors (in some cases a configuration may be saved before it is validated, see Initializing templates).
                                                                "},{"location":"community/taskmanager/basic/#running-a-batch","title":"Running a batch","text":"

                                                                The batch is executed in two phases:

                                                                • RUN phase: tasks are executed in the defined order. If an error occurs or the run is manually intermitted, cease execution and go to ROLLBACK phase. If all tasks finish successfully, go to COMMIT phase.
                                                                • COMMIT/ROLLBACK phase: tasks are committed or rollbacked in the opposite order.

                                                                Consider a batch with three tasks

                                                                B = T1 -> T2 -> T3.

                                                                A normal run would then be

                                                                run T1 -> run T2 -> run T3 -> commit T3 -> commit T2 -> commit T1.

                                                                However, if T2 fails, the run would be

                                                                run T1 -> run T2 (failure) -> rollback T1.

                                                                Most tasks support COMMIT/ROLLBACK by creating temporary objects that only become definite objects after a COMMIT. The ROLLBACK phase then simply cleans up those temporary objects. However, some particular task types may not support the COMMIT/ROLLBACK mechanism (in which case running them is definite).

                                                                The commit phase happens in opposite order because dependencies in the old version of the data often requires this. A concrete example may clear things up. Imagine that T1 copies a database table R from one database to another, while T2 creates a view V based on that table, so V depends on R. If the table and view already exist in older versions (R_old and V_old), they must not be removed until the COMMIT phase, so that their original state remains in the case of a ROLLBACK. During the COMMIT phase, R_old and V_old are removed, but it is not possible to remove R_old until V_old is removed. Therefore it is necessary to commit T2 before T1.

                                                                The COMMIT phase typically replaces old objects with the new objects that have a temporary name. Since tasks often create objects that depend on objects of the previous tasks, these objects contain references to temporary names. Which means that when the temporary object is committed and becomes the real object, references in depending objects must also be updated. For this purpose, a tasks that uses a temporary object from a previous task registers a dependency, which is essentially an update added to the commit phase of that previous task.

                                                                If T3 has a dependency on task T1 that we call D1, the following happens:

                                                                run T1 -> run T2 -> run T3, register D1 -> commit T3 -> commit T2 -> commit T1, update D1.

                                                                Let's make it clearer again using an example. During the RUN phase T1 creates table R1_temp and T2 creates V1_temp that depends on R1_temp, this dependency will be registered. During the commit phase, T2 will replace V1 by V1_temp. Then, T1 will replace T1 by T1_temp. However, V1 may still reference T1_temp which no longer exists. Therefore, T1 will use the registered dependency to update V1 to refer to T1 instead of T1_temp.

                                                                Within a batch run, each task that has yet started has a status. These are the possible statuses:

                                                                • RUNNING: the task is currently running.
                                                                • WAITING_TO_COMMIT: the task has finished running, but is waiting to commit (or rollback) while other tasks are running or committing (or rolling back).
                                                                • COMMITTING: the task is currently committing.
                                                                • ROLLING_BACK: the task is currently rolling back.
                                                                • COMMITTED: the task was successfully committed.
                                                                • ROLLED_BACK: the task was successfully rolled back.
                                                                • NOT_COMMITTED: the task was supposed to commit but failed during the commit phase.
                                                                • NOT_ROLLED_BACK: the task was supposed to roll back but failed during roll back phase.

                                                                A task is consired finished if its status is not RUNNING, WAITING_TO_COMMIT, ROLLING_BACK or COMMITTING. A batch run does not have its own status, but it takes on the status of the last task that has started but is not COMMITTED or ROLLED_BACK. A batch run is considered finished if its status is not RUNNING, WAITING_TO_COMMIT or COMMITTING.

                                                                There is concurrency protection both on the level of tasks and batches. A single batch can never run simultaneously in multiple runs (the second run will wait for the first one to finish). A single task can never run simultaneously in multiple runs, even if part of a different batch. A single task can also not commit simultaneously in multiple runs.

                                                                "},{"location":"community/taskmanager/basic/#templates","title":"Templates","text":"

                                                                Templates are in every way identical to configurations, with the exception of:

                                                                • they are never validated when saved (their attributes need not be filled in) and
                                                                • their tasks and batches can never be executed.

                                                                A template is used as a blueprint for the creation of configurations that are very similar to each other. Typically, the tasks are all the same but the attribute values are different. However, a template may also have attribute values filled in that serve as defaults.

                                                                Once a configuration is created from a template, it is independent from that template (changes to the template do not affect it). The configuration can then be modified like any other configuration, including the removal, addition and manipulation of tasks.

                                                                "},{"location":"community/taskmanager/basic/#initializing-templates","title":"Initializing templates","text":"

                                                                An initializing template is any template that has a batch named @Initialize (case sensitive), which configures special behaviour. The purpose of this batch is to execute some tasks that must have been done at least once until some other tasks can actually be configured. For example, you may want to create a vector layer based on that table copied from a source database, then synchronise this layer to a target geoserver. The task that synchronizes a layer to the external geoserver will expect an existing configured layer, which you cannot create until you have copied the table first. The @Initialize batch would in this case copy the table from the source and create a layer in the local geoserver.

                                                                When creating a configuration from this template, configuration happens in two phases

                                                                • (1) Initially, only attributes related to tasks in the @Initialize batch must be configured. When the configuration is saved, the @Initialize batch is automatically executed.

                                                                • (2) Now, all other attributes and tasks must be configured and the configuration must be saved again.

                                                                This is the only case that a configuration can be saved before all the required attributes are filled in. Mind that batches will not be scheduled or visible in the general overview until the batch has been saved again (and the attributes have thus been validated).

                                                                "},{"location":"community/taskmanager/developer/","title":"Developer's Guide","text":"
                                                                • Task Types - write your own operations
                                                                • Actions - extend the GUI for your tasks
                                                                • Reporting - choose the content and destination of your batch reports
                                                                "},{"location":"community/taskmanager/developer/#task-types","title":"Task Types","text":"

                                                                Task manager can be extended with custom made task types. Make your own implementation of the interface TaskType and let it be a spring bean. The name provided via the Named interface is used as a reference.

                                                                /**\n * A Task Type.\n * \n */\npublic interface TaskType extends Named {\n\n    /**\n     * Return parameter info for this task type.\n     * It is recommended to use a LinkedHashMap and add the parameters in a intuitive order.\n     * This order will be preserved to present parameters to the user. \n     *\n     * @return the parameter info\n     */\n    Map<String, ParameterInfo> getParameterInfo();\n\n    /**\n     * Run a task, based on these parameter values.\n     * @param ctx task context\n     * @return the task result\n     */\n    TaskResult run(TaskContext ctx) throws TaskException;\n\n    /**\n     * Do a clean-up for this task (for example, if this task publishes something, remove it).\n     * @param ctx task context\n     * @throws TaskException \n     */\n    void cleanup(TaskContext ctx) throws TaskException;\n\n    /**\n     * task type can specify whether it supports clean-up or not\n     * \n     * @return true if clean-up is supported\n     */\n    default boolean supportsCleanup() {\n        return true;\n    }\n\n}\n

                                                                A ParameterInfo object contains a name, a type, whether they are required, and which other parameters they depend on (for example, a database table depends on a database).

                                                                The Task context looks as follows:

                                                                /**\n * Task Context used during batch run or task clean-up.\n * \n */\npublic interface TaskContext {\n\n    /**\n     * @return the task\n     */\n    Task getTask();\n\n    /**     \n     * @return the batch context, null if this is a clean-up\n     */\n    BatchContext getBatchContext();\n\n    /**\n     * \n     * @return the parameter values, lazy loaded from task and configuration.\n     * \n     * @throws TaskException\n     */\n    Map<String, Object> getParameterValues() throws TaskException;\n\n    /**\n     * Tasks can call this function to check if the user wants to interrupt the batch\n     * and interrupt themselves.\n     * If they do, they should still return a TaskResult that implements a roll back\n     * of what was already done.\n     * \n     * @return whether the batch run should be interrupted, false if this is a clean-up\n     */\n    boolean isInterruptMe();\n\n}\n

                                                                The batch context looks as follows:

                                                                /**\n * During run, tasks create temporary objects that are committed to real objects during\n * the commit phase (such as a table name) This maps real objects\n * to temporary objects during a single batch run. Tasks should save and look up temporary \n * objects so that tasks within a batch can work together.\n * \n */\npublic interface BatchContext {\n\n    public static interface Dependency {\n        public void revert() throws TaskException;\n    }    \n\n    Object get(Object original);\n\n    Object get(Object original, Dependency dependency);\n\n    /**\n     * Whatever is put here in the task, must be removed in the commit!\n     * \n     * @param original\n     * @param temp\n     */\n    void put(Object original, Object temp);\n\n    void delete(Object original) throws TaskException;\n\n    BatchRun getBatchRun();\n\n}\n

                                                                The task result looks as follows:

                                                                /**\n * A handle of a task that was run but must still be committed or rolled back.\n * \n *\n */\npublic interface TaskResult {\n\n    /**\n     * finalize and clean-up resources any roll-back data\n     */\n    void commit() throws TaskException;\n\n    /**\n     * batch has failed - cancel all changes\n     */\n    void rollback() throws TaskException;\n\n}\n

                                                                This is an example of how a task type can create temporary object:

                                                                //inside TaskType.run method\n\nctx.getBatchContext().put(originalObject, tempObject)\n\n...\n\nreturn new TaskResult() {\n   @Override\n   public void commit() throws TaskException {\n       //this MUST be done!!!\n       ctx.getBatchContext.delete(originalObject)\n   } \n\n       ...\n\n}\n

                                                                Another task type would use this temporary object as follows:

                                                                //inside TaskType.run method\n\nObject tempObject = ctx.getBatchContext().get(originalObject, new Dependency() {\n  @Override\n  public void revert() {\n      Object object = ctx.getBatchContext().get(originalObject);\n\n      mySomething.setMyProperty(object);\n      mySomething.save();\n  }\n});\n\nmySomething.setMyProperty(tempObject);\nmySomething.save();\n
                                                                "},{"location":"community/taskmanager/developer/#parameter-types","title":"Parameter Types","text":"

                                                                Custom task types may use existing or define new parameter types. They handle parameter validation, parsing parameter Strings into other object types, and provide information to the GUI about the parameters.

                                                                Existing regular Parameter Types (static members of ParameterType interface):

                                                                • STRING
                                                                • INTEGER
                                                                • BOOLEAN
                                                                • URI
                                                                • SQL (protects against ';' hacking)

                                                                External Parameter Types (members of ExtTypes spring bean): * dbName: database name * tableName: table name (parameter must depend on parameter of dbName type) * extGeoserver: external geoserver * internalLayer: layer from geoserver catalog * name: name qualified with namespace from geoserver catalog * fileService: file service * file: reference to file (parameter must dpend of parameter of fileService type)

                                                                Defining a new Parameter Type:

                                                                /**\n * \n * A Parameter Type For a Task\n * \n */\npublic interface ParameterType {\n\n    /**\n     * List possible values for this parameter (when applicable).\n     * Include an empty string if custom value is also allowed.\n     * \n     * @param dependsOnRawValues raw values of depending parameters.\n     * @return list of possible values, null if not applicable.\n     */\n    public List<String> getDomain(List<String> dependsOnRawValues);\n\n    /**\n     * Validate and parse a parameter value for this parameter (at run time).\n     * \n     * @param value the raw value.\n     * @param dependsOnRawValues raw values of depending parameters.\n     * @return the parsed value, NULL if the value is invalid.\n     */\n    public Object parse(String value, List<String> dependsOnRawValues);\n\n    /**\n     * Validate a parameter value (at configuration time).\n     * \n     * @param value the raw value.\n     * @param dependsOnRawValues raw values of depending parameters.\n     * @return true if the value is considered valid at configuration time (may still be considered\n     * invalid at parse time)\n     */\n    public default boolean validate(String value, List<String> dependsOnRawValues) {\n        return parse(value, dependsOnRawValues) != null;\n    }\n\n    /**\n     * Returns a list of web actions related to this type\n     * \n     * @return list of web actions\n     */\n    public default List<String> getActions() {\n        return Collections.emptyList();\n    }\n\n}\n
                                                                "},{"location":"community/taskmanager/developer/#actions","title":"Actions","text":"

                                                                Actions are extensions to the taskmanager webGUI attached to particular parameter types.

                                                                public interface Action extends Named, Serializable {\n\n    /**\n     * Execute this action.\n     * \n     * @param onPage the configuration page.\n     * @param target the target of the ajax request that executed this action.\n     * @param valueModel the value of the attribute, for reading and writing.\n     * @param dependsOnRawValues raw values of depending attributes. \n     */\n    void execute(ConfigurationPage onPage, AjaxRequestTarget target, IModel<String> valueModel, List<String> dependsOnRawValues);\n\n    /**\n     * Check whether this action can be executed with current values.\n     * \\\n     * @param value the value of the attribute.\n     * @param dependsOnRawValues raw values of depending attributes. \n     * @return whether this action accepts these values.\n     */\n    default boolean accept(String value, List<String> dependsOnRawValues) {\n        return true;\n    }\n\n}\n

                                                                In order to be linked to parameter types, an action must be spring bean. The name provided via the Named interface is used as a reference.

                                                                "},{"location":"community/taskmanager/developer/#reporting","title":"Reporting","text":""},{"location":"community/taskmanager/developer/#report-builders","title":"Report builders","text":"

                                                                Reports are user friendly representations of finished batch runs, that are sent to some destination right after the batch run has finished. A report has a type (FAILED, CANCELLED or SUCCESS), a title and a content. Use spring to configure a single report builder.

                                                                /**\n * A report builder generates a report from a batch.\n * One could write a custom one.\n *\n */\npublic interface ReportBuilder {\n\n    Report buildBatchRunReport(BatchRun batchRun);\n\n}\n
                                                                "},{"location":"community/taskmanager/developer/#report-services","title":"Report services.","text":"

                                                                Use spring to configure any number of report services.

                                                                /**\n * A report service sends a report to a particular destination.\n * One can add an unlimited amount of report services which will all be used.\n *\n */\npublic interface ReportService {\n\n    /**\n     * Enumeration for filter.\n     *\n     */\n    public enum Filter {\n        /** All batch runs are reported **/\n        ALL (Report.Type.FAILED, Report.Type.CANCELLED, Report.Type.SUCCESS),\n        /** Only failed and cancelled batch runs are reported **/\n        FAILED_AND_CANCELLED (Report.Type.FAILED, Report.Type.CANCELLED), \n        /** Only failed batch runs are reported **/\n        FAILED_ONLY (Report.Type.FAILED);\n\n        Report.Type[] types;\n\n        private Filter(Report.Type... types) {\n            this.types = types;\n        }\n\n        public boolean matches(Report.Type type) {\n            return ArrayUtils.contains(types, type);\n        }\n\n    }\n\n    /**\n     * Return the filter of the report.\n     * \n     * @return the filter of the report.\n     */\n    public Filter getFilter();\n\n    /**\n     * Send a report.\n     * \n     * @param report the report.\n     */\n    public void sendReport(Report report);\n\n}\n
                                                                "},{"location":"community/taskmanager/user/","title":"TaskManager User Guide","text":""},{"location":"community/taskmanager/user/#installation","title":"Installation","text":"

                                                                To install the GeoServer Task Manager extension:

                                                                1. Download the extension from the GeoServer Download Page <download> release page: taskmanager-core. For S3 support, also install the plugin taskmanager-s3
                                                                2. Extract this file and place the JARs in WEB-INF/lib.
                                                                3. Perform any configuration required by your servlet container, and then restart. On startup, Task Manager will create a configuration directory taskmanager in the GeoServer Data Directory. You will be able to see the Task Manager configuration pages from the GeoServer WebGUI menu.
                                                                "},{"location":"community/taskmanager/user/#server-configuration","title":"Server Configuration","text":""},{"location":"community/taskmanager/user/#configuration-database-clustering","title":"Configuration Database & Clustering","text":"

                                                                By default, Task Manager will create a H2 database in its configuration directory. This can be easily changed to any JDBC resource via the taskmanager.properties file.

                                                                The configuration directory also contains a Spring configuration file called taskManager-applicationContext.xml which allows more advanced configuration.

                                                                TaskManager uses Quartz Scheduler. If you are running Task Manager in a clustered environment, you must configure Quartz to use a database as well as Task Manager. See the commented block in the Spring configuration and the Quartz documentation for further instructions. SQL Scripts to create the required database structures for Quartz can be found here. Task Manager can create its database automatically, or alternatively this script can be used (note: the script was made for postgresql. For any other DBMS, the script might need to be modified, or alternatively, the database could be automatically created in a development environment and then copied for a production environment). It is fine to use a single database both for Quartz and Task Manager.

                                                                Furthermore, a property should be added to the taskmanager.properties file each of the nodes except for one: batchJobService.init=false. This is necessary because otherwise all of the nodes will attempt to load all of the same batches in to the clustered quartz database at the same time at start-up, which is likely to cause issues. This initialisation needs to happen only once for the entire cluster.

                                                                "},{"location":"community/taskmanager/user/#taskmanager_user_databases","title":"Databases","text":"

                                                                Task Manager allows any number of databases to be used both as sources and targets for data transfer operations. These are configured via the Spring configuration file. Currently only PostGIS is supported as a target (as well as a source), either via JNDI or directly via JDBC.

                                                                <bean class=\"org.geoserver.taskmanager.external.impl.PostgisDbSourceImpl\"> \n    <property name=\"name\" value=\"mypostgisdb\"/> \n    <property name=\"host\" value=\"hostname\" /> \n    <property name=\"db\" value=\"dbname\" /> \n    <!-- optional --> <property name=\"schema\" value=\"schema\" /> \n    <property name=\"username\" value=\"username\" />\n    <property name=\"password\" value=\"password\" /> \n    <!-- optional, for security purposes -->\n    <property name=\"roles\">\n      <list>\n       <value>ROLE1</value>\n       <value>ROLE2</value>\n      </list>\n    </property>\n</bean>\n
                                                                <bean class=\"org.geoserver.taskmanager.external.impl.PostgisJndiDbSourceImpl\">\n    <property name=\"name\" value=\"mypostgisjndidb\" />\n    <property name=\"jndiName\" value=\"java:/comp/env/jdbc/my-jndi-source\" />\n    <!-- optional --> <property name=\"schema\" value=\"schema\" /> \n    <!-- optional, if database has different jndi name on target geoserver servers -->  \n     <property name=\"targetJndiNames\">\n     <map>\n        <entry key=\"mygs\" value=\"java:/comp/env/jdbc/my-jndi-source-on-mygs\" />\n     </map>\n    </property>\n    <!-- optional, for security purposes -->\n    <property name=\"roles\">\n      <list>\n       <value>ROLE1</value>\n       <value>ROLE2</value>\n      </list>\n    </property>\n</bean>\n

                                                                Roles can be specified for security purposes.

                                                                Other database systems should generally work as a source database (not for publishing) using the GenericDbSourceImpl (this has been tested with MS SQL).

                                                                <bean class=\"org.geoserver.taskmanager.external.impl.GenericDbSourceImpl\">\n    <property name=\"name\" value=\"mysqldb\" />\n    <property name=\"driver\" value=\"com.microsoft.sqlserver.jdbc.SQLServerDriver\"/> \n    <property name=\"connectionUrl\" value=\"jdbc:sqlserver://mysqldbhost:1433;database=mydb\" /> \n    <property name=\"username\" value=\"username\" />\n    <property name=\"password\" value=\"password\" /> \n    <property name=\"schema\" value=\"dbo\" /> \n</bean>\n

                                                                There is also specific support for Informix as a source database (not for publishing).

                                                                <bean class=\"org.geoserver.taskmanager.external.impl.InformixDbSourceImpl\">\n    <property name=\"name\" value=\"myinformixdb\" />\n    <property name=\"driver\" value=\"com.informix.jdbc.IfxDriver\"/> \n    <property name=\"connectionUrl\" value=\"jdbc:informix-sqli://informix-server:1539\" /> \n    <property name=\"username\" value=\"username\" />\n    <property name=\"password\" value=\"password\" /> \n</bean>\n

                                                                It is also possible to use a source that does not support geometries, and translate them automatically from some raw type. To do this, one must create a table in the database that contains a list of all geometry columns that need to be translated. This can be configured as follows:

                                                                <bean name=\"geomtable\" class=\"org.geoserver.taskmanager.external.impl.GeometryTableImpl\">\n    <!-- the name of your metadata table -->\n   <property name=\"nameTable\" value=\"Metadata_Geo\" />\n    <!-- the attribute name that contains table name -->\n   <property name=\"attributeNameTable\" value=\"table_name\" />\n    <!-- the attribute name that contains column name -->\n   <property name=\"attributeNameGeometry\" value=\"column_name\" />\n    <!-- the attribute name that contains geometry type -->\n   <property name=\"attributeNameType\" value=\"geometry_type\" />\n    <!-- the attribute name that contains SRID code -->\n   <property name=\"attributeNameSrid\" value=\"srid\" />\n    <!-- the type of conversion: WKT (string to geometry), WKB (binary to geometry), WKB_HEX (hex string to geometry) -->\n   <property name=\"type\" value=\"WKB_HEX\" />\n</bean>\n\n<bean class=\"org.geoserver.taskmanager.external.impl.GenericDbSourceImpl\">\n    ....  \n    <property name=\"rawGeometryTable\" ref=\"geomtable\"/>\n</bean>\n
                                                                "},{"location":"community/taskmanager/user/#taskmanager_user_external_geoserver","title":"External GeoServers","text":"

                                                                Task Manager allows any number of external geoservers to be used as targets for layer publications. These are configured via the Spring configuration file.

                                                                <bean class=\"org.geoserver.taskmanager.external.impl.ExternalGSImpl\"> \n    <property name=\"name\" value=\"mygs\"/> \n    <property name=\"url\" value=\"http://my.geoserver/geoserver\" /> \n    <property name=\"username\" value=\"admin\" />\n    <property name=\"password\" value=\"geoserver\" />\n    <property name=\"supportMetadata\" value=\"true\" />\n</bean>\n

                                                                The ''supportsMetadata'' field indicates whether this target geoserver contains the the Metadata Community Module, which provides additional support for it in certain tasks.

                                                                The configuration above will log-in to geoserver using basic authentication. Task Manager also supports geoservers protected with keycloak:

                                                                <bean class=\"org.geoserver.taskmanager.external.impl.ExternalKeycloakGSImpl\">\n    <property name=\"name\" value=\"keycloakgs\"/>\n    <property name=\"url\" value=\"http://my.geoserver/geoserver\"/>\n    <property name=\"username\" value=\"keycloak_admin\"/>\n    <property name=\"password\" value=\"keycloak_password\"/>\n    <property name=\"clientId\" value=\"my clientid\"/>\n    <property name=\"clientSecret\" value=\"my clientsecret\"/>\n    <property name=\"real\" value=\"my realm\"/>\n    <property name=\"authUrl\" value=\"http://my.keycloak.server/auth\"/>\n    <property name=\"supportMetadata\" value=\"true\" />\n</bean>\n
                                                                "},{"location":"community/taskmanager/user/#taskmanager_user_file_services","title":"File Services","text":"

                                                                File Services are used to upload and access files such as raster layers or vector files. They are configured via the Spring configuration file.

                                                                "},{"location":"community/taskmanager/user/#regular-file-service","title":"Regular File Service","text":"

                                                                Regular file services provide support for rasters and vector files that are stored on the hard drive.

                                                                <bean class=\"org.geoserver.taskmanager.external.impl.FileServiceImpl\">\n    <property name=\"rootFolder\" value=\"/tmp\"/>\n    <property name=\"name\" value=\"Temporary Directory\"/>\n    <property name=\"roles\">\n      <list>\n       <value>ROLE1</value>\n       <value>ROLE2</value>\n      </list>\n    </property>\n</bean>\n

                                                                Roles can be specified for security purposes.

                                                                Non-absolute paths as rootFolder will be relative to the GeoServer Data Directory.

                                                                Alternatively, it is also possible to use ResourceFileServiceImpl (same properties). This one only accepts relative paths and will use the data directory via the geoserver resource store, so that alternative implementations such as JDBC Store can be used. This might be useful for Application Schemas, for example.

                                                                "},{"location":"community/taskmanager/user/#s3-file-service","title":"S3 File Service","text":"

                                                                S3 File Services provide support for rasters that are stored on an S3 compatible server.

                                                                They do not need to be configured via the application context, but are taken from the properties file provided via the property s3.properties.location (see S3 DataStore).

                                                                A service will be created for each service and each bucket. We must add one line per alias to the s3.properties file:

                                                                alias.s3.rootfolder=comma,separated,list,of,buckets

                                                                The above example will create five s3 file services: alias-comma, alias-separated, alias-list, alias-of and alias-buckets.

                                                                Roles can optionally be specified for security purposes as follows:

                                                                alias.bucket.s3.roles=comma,separated,list,of,roles

                                                                "},{"location":"community/taskmanager/user/#aws-file-service","title":"AWS File Service","text":"

                                                                Amazon AWS S3 buckets are also supported.

                                                                <bean class=\"org.geoserver.taskmanager.external.impl.AWSFileServiceImpl\">\n    <property name=\"rootFolder\" value=\"/tmp\"/>\n    <property name=\"anonymous\" value=\"false\"/>\n    <property name=\"awsRegion\" value=\"us-west-1\"/>\n    <property name=\"roles\">\n      <list>\n       <value>ROLE1</value>\n       <value>ROLE2</value>\n      </list>\n    </property>\n</bean>\n

                                                                Unless anonymous is set to true, the default AWS client credential chain is used.

                                                                "},{"location":"community/taskmanager/user/#prepare-script","title":"Prepare script","text":"

                                                                The task manager GUI allows immediate upload of files to file services for local publication. It may be handy to perform some preprocessing tasks on the uploaded data before publication (such as GDAL commands). You may do this by creating a file in the taskmanager configuration directory named prepare.sh. If the user ticks the prepare checkbox in the upload dialog, this script will be run with the uploaded file as its first parameter.

                                                                "},{"location":"community/taskmanager/user/#security","title":"Security","text":"

                                                                Each configuration and each independent batch is associated with a workspace in GeoServer (when the workspace field is empty, it is automatically associated with the default workspace in geoserver). The configuration or batch takes its security permissions directly from this workspace.

                                                                • If the user has reading permissions on the workspace, they may view the configuration or batch.
                                                                • If the user has writing permissions on the workspace, they may run the batch or the batches in the configuration.
                                                                • If the user has administrative permissions on the workspace, they may edit the configuration/batch.

                                                                Each Database or File Service may be associated with a list of roles. If you do so, only users with those roles will have access to the database or file service in question. If you want to disable security restrictions, do not include the roles property at all (because an empty list will result in no access.)

                                                                "},{"location":"community/taskmanager/user/#graphical-user-interface","title":"Graphical User Interface","text":"

                                                                Currently GeoServer Task Manager can only be configured and operated from the GeoServer WebGUI.

                                                                "},{"location":"community/taskmanager/user/#templates","title":"Templates","text":"

                                                                From the templates page, new templates can be created (or copied from existing templates), existing templates can be edited and removed.

                                                                templates

                                                                Once you open a new or existing template, attributes, tasks and batches can be edited. The attribute table adjusts automatically based on the information in the tasks table; and only the values must be filled in. In the task table, the name and parameters of each task can be edited, and new tasks can be created. Batches can be created and edited from here as well, however the template must exist in order to be able to do that (in case of a new template, you must click apply once before you can create new batches). New tasks must also be saved (again, via the apply button) before they can be added to a batch.

                                                                template db workflow

                                                                "},{"location":"community/taskmanager/user/#configurations","title":"Configurations","text":"

                                                                From the configurations page, new configurations can be created from scratch or from templates (or copied from existing configurations), existing configurations can be edited and removed.

                                                                configurations

                                                                When removing a configuration, you have to option to do a clean-up, which will attempt to remove all resources (database tables, files, layers) that were created by (tasks of) this configuration. If this (partially) fails, the configuration will still be removed and the user will be notified.

                                                                Once you open a new or existing configuration, attributes, tasks and batches can be edited.

                                                                workflow config 2

                                                                The attribute table adjusts automatically based on the information in the tasks table; and only the values must be filled in. In the task table, the name and parameters of each task can be edited, and new tasks can be created. Tasks can only be removed if they are not part of a batch any longer. Batches can only be removed if they are not running anywhere. When removing a task, you have to option to do a clean-up, which will attempt to remove all resources (database tables, files, layers) that were created by this task. If this (partially) fails, the task will still be removed and the user will be notified.

                                                                Batches can be created and edited from here as well, however the configuration must exist in order to be able to do that (in case of a new configuration, you must click apply once before you can create new batches). New tasks must also be saved (again, via the apply button) before they can be added to a batch. In case that the conditions are met, batch runs can be started, and the status/history of current and past batch runs can be displayed. Current batch runs can be interrupted (which is not guaranteed to happen immediately).

                                                                "},{"location":"community/taskmanager/user/#importexport","title":"Import/Export","text":"

                                                                It is also possible to import/export entire configurations to XML, for example to transfer them from one geoserver to another. The import button is on the configurations page, while the export button is on the page of a specific configuration. The user is responsible for making sure that the configuration is compatible with the other geoserver (available task extensions, attribute values,...).

                                                                "},{"location":"community/taskmanager/user/#batches","title":"Batches","text":"

                                                                From the batches page, new independent batches (not associated with a configuration) can be created, existing batches can be edited and removed. All existing batches - independent as well as belonging to a configuration - are shown, unless they are special (if they start with a @) or if the configuration has not yet been completed (see initializing templates).

                                                                batches

                                                                In case that the conditions are met, batch runs can be started, and the status/history of current and past batch runs can be displayed. Current batch runs can be interrupted (which is not guaranteed to happen immediately).

                                                                batchruns

                                                                batchrun

                                                                Once you open a new or existing batch, one can add or remove tasks from it and change the order of the tasks. You can also enable/disable the batch (if disabled, the batch is not scheduled) and choose the scheduling time. The user can choose between a daily schedule (with time), weekly (with day of week and time), monthly (with day of month and time) or specify a custom cron expression.

                                                                batch synchronize

                                                                "},{"location":"community/taskmanager/user/#task-types","title":"Task Types","text":"
                                                                • CopyTableTask Copy a database table from one database to another. The user can specify a source database, source table name, target database and target table name. The source table name may also be a view. If the source does not contain a primary key column (f.e. if it is a view), an additional column 'generated_id', with an automatically generated primary key will be added to the destination table. The task will also copy all existing indexes. If the source table contains a geometry column but not a spatial index (f.e. if it is a view), a spatial index will automatically be added to the destination table. Supports commit/rollback by creating a temporary table.
                                                                • CreateViewTask Create a view based on a single table. The user can specify the database, the table name, the selected fields and (optionally) a where condition. Supports commit/rollback by creating a temporary view.
                                                                • CreateComplexViewTask Create a view based on a multiple tables. The user can specify the database and a whole query, where it can use any other configuration attribute in the form of '\\${placeholder}'. Supports commit/rollback by creating a temporary view.
                                                                • CopyFileTask Copy a file from one file service to another. Commit/rollback is supported by a versioning system, where the version of the file is inserted into the file name. The location of the version number is specified in the path as ### (or set auto-versioned to true to add the placeholder automatically before the extension dot). On commit, the older version is removed. On rollback, the newer version is removed. The publication tasks will automatically publish the latest version.
                                                                • LocalDbPublicationTask Publish a database layer locally. The user can specify database, table and a layer name. Supports commit/rollback by advertising or removing the layer it created.
                                                                • RemoteDbPublicationTask Publish a database layer to another geoserver. The user can specify a target geoserver, a source layer and a target database. All information is taken from the source layer except for the target database which may be different. Supports commit/rollback through creating a temporary (unadvertised) layer. This task also supports the version place holder or auto-versioning, in order to combine with the CopyFileTask.
                                                                • LocalFilePublicationTask Publish a file layer locally (raster or shapefile). The user can specify a file service, a file (which can be uploaded unto the service) and a layer name. Supports commit/rollback by advertising or removing the layer it created.
                                                                • RemoteFilePublicationTask Publish a file layer locally (taster or shapefile). The user can specify a target geoserver, a source layer and a target file service and path (optional). All information is taken from the source layer except for the file service and path which may be different. Supports commit/rollback through creating a temporary (unadvertised) layer.
                                                                • MetaDataSyncTask Synchronise the metadata between a local layer and a layer on another geoserver (without re-publishing). The user can specify a target geoserver, a local and a remote layer. Does not support commit/rollback. If the target geoserver supports the Metadata Community Module native metadata attributes mapped to custom metadata attributes will be updated. Note that all of the publication tasks will synchronize metadata in the same way.
                                                                • ConfigureCachedLayer Configure caching for a layer on a remote geoserver with internal GWC, synchronise the settings with the local geoserver. This task may turn caching on or off depending on local configuration.
                                                                • ClearCachedLayer Clear (truncate) all tiles of a cached layer on a remote geoserver with internal GWC.
                                                                • LocalAppSchemaPublicationTask Publish an Application Schema layer locally. This is exactly the same as LocalFilePublicationTask with the Application Schema mapping file as the file being published, and two additional features.
                                                                  • The mapping file may be provided as a template, with placeholders in the form of ${placeholder}. The placeholders are replaced by the values of the connection parameters of the database that is provided as parameter to the task. This makes it possible to fill in the underlying source database for different geoservers. For example: specify ${jndiReferenceName} as source database connection parameter in the mapping file.
                                                                  • Multiple mapping files may be provided for a single layer (when the layer mapping uses included types), in the form of a ZIP file. The main mapping file and the ZIP file must have the same name before the extension.
                                                                • RemoteAppSchemaPublicationTask Publish an Application Schema layer remotely. This is exactly the same as LocalFilePublicationTask with the Application Schema mapping file as the file being published, and two additional features:
                                                                  • The mapping file may be provided as a template, with placeholders in the form of ${placeholder}. The placeholders are replaced by the values of the connection parameters of the database that is provided as parameter to the task. This makes it possible to fill in the underlying source database for different geoservers. For example: specify ${jndiReferenceName} as source database connection parameter in the mapping file.
                                                                  • Multiple mapping files may be provided for a single layer (when the layer mapping uses included types), in the form of a ZIP file. The main mapping file and the ZIP file must have the same name before the extension.
                                                                • LayerSecuritySync this task will synchronise all data access security rules associated with a layer to the external geoserver. Warning: the task assumes that the same roles exist on both geoservers. Does not support commit/rollback.
                                                                • WorkspaceSecuritySync this task will synchronise all data access security rules associated with a workspace to the external geoserver. Warning: the task assumes that the same roles exist on both geoservers. Does not support commit/rollback.
                                                                • TimeStamp update a time stamp in a layer's metadata that represents the last time a layer's data has been updated. Since the data timestamp is part of the metadata, a metadata timestamp can also be updated. The task must be configured through its Spring Bean properties timeStampTaskType.dataTimestampProperty and timeStampTaskType.metadataTimestampProperty which represent the key (or key path) in the layer's resource metadata. If you are using the Metadata Community Module you should set timeStampTaskType.metadataTimestampProperty=custom._timestamp.
                                                                • MetadataTemplateSync this task requires the Metadata Community Module and the taskmanager-metadata submodule. It will synchronize all metadata linked to a specific metadata template. Useful when you change the template.
                                                                "},{"location":"community/taskmanager/user/#bulk-operations","title":"Bulk Operations","text":"

                                                                The task manager provides a number of bulk operation tools via an additional page in the GUI. The import tool is also available via a REST service.

                                                                "},{"location":"community/taskmanager/user/#run-batches","title":"Run Batches","text":"

                                                                A whole series of batches may be scheduled all at once. You specify a workspace, configuration name and batch name pattern to select the series of batches you want to schedule. You may specify how long to wait before starting to execute the batches. You may specify how long to wait in between execution of each batch. This option is strongly recommended not to overload your software and cause failures.

                                                                "},{"location":"community/taskmanager/user/#import-configurations","title":"Import Configurations","text":"

                                                                The import tool allows bulk creation of an unlimited amount of configurations on the basis of a template and a CSV file with attribute values. Contrary to the rest of the configuration, this function is only exposed via a REST service and not via the GUI. The import tool will generate a new configuration for each line in the CSV file, except for the first. The first line must specify the attribute names which should all match attributes that exist in the template, plus name (required), description (optional) and workspace (optional) for the configuration metadata. The CSV file mustspecify a valid attribute value for each required attribute.

                                                                Optionally, you may skip validation (at your own risk).

                                                                As an alternative to using the GUI page, you may POST your CSV file to http://{geoserver-host}/geoserver/taskmanager-import/{template}[validate=false]

                                                                "},{"location":"community/taskmanager/user/#initialize-configurations","title":"Initialize Configurations","text":"

                                                                If you have imported configurations in bulk based on an Initializing template, you may also want to initialize them in bulk. This works similarly to running batches in bulk. The configurations will be validated after initialization.

                                                                "},{"location":"community/taskmanager/user/#examples","title":"Examples","text":"

                                                                Consider the following setup.

                                                                Three geoservers:

                                                                • work geoserver: a geoserver only available in the local network, only used by administrators. New and updated data is published here as layers for the first time, to test both the validity of data and the publication configuration.
                                                                • internal geoserver: a geoserver only available in the local network, for internal users.
                                                                • public geoserver: a geoserver available on the internet, for the general public.

                                                                Several databases:

                                                                • multiple source databases: these are databases provided by partners that provide new and updated data. they are not used to directly publish on a geoserver.
                                                                • work database: database used by the work geoserver where its vector data is stored.
                                                                • internal database: database used by the internal geoserver where its vector data is stored.
                                                                • public database: database used by the public geoserver where its vector data is stored.

                                                                A typical workflow for a new layer goes as follows:

                                                                1. A new table is copied from a source database to the work database and then published on the work geoserver
                                                                2. After testing, the table is either copied to the internal database and published on the internal geoserver or copied to the public database and published on the public geoserver.
                                                                3. Every week, data is synchronised between the three databases and metadata is synchronised between the two geoservers.

                                                                Taskmanager should be installed only on the work geoserver. Then we could make the following template:

                                                                template db workflow

                                                                with the following batches:

                                                                template db workflow batches

                                                                The @Initialize batch:

                                                                batch initialize

                                                                The PublishRemotely batch:

                                                                batch publish remotely

                                                                The Synchronize batch:

                                                                batch synchronize

                                                                When we now create a new configuration based on this template we choose a source database, table name and layer name:

                                                                workflow config

                                                                After clicking apply, the configuration is being initialized (the layer is created locally)...

                                                                initializing...

                                                                We can now fill in the rest of the details, save, and make the remote publication. The synchronization is scheduled weekly.

                                                                workflow config 2

                                                                "},{"location":"community/vector-mosaic/","title":"Vector Mosaic datastore","text":"

                                                                The Vector Mosaic datastore is a datastore that mosaics several vector datasets into a single layer. This provides the convenience of not having to create separate stores and layers for each constituent granule vector dataset. The datastore uses the index table as an index to speed up cross dataset queries (e.g., finding the granules that match the current bbox and opening only those ones). Vector Mosaic datastore layers will have a feature type that incorporates the index table attributes (with the exception of geometry and connection parameters) combined with the vector granule attributes.

                                                                • Installing Vector Mosaic Datastore
                                                                • Vector Mosaic Datastore configuration
                                                                • Vector Mosaic Datastore Delegate Requirements
                                                                "},{"location":"community/vector-mosaic/configuration/","title":"Vector Mosaic Datastore configuration","text":"

                                                                When the extension has been installed, Vector Mosaic Data Store will be an option in the Vector Data Sources list when creating a new data store.

                                                                Vector Mosaic Data Store in the list of vector data sources

                                                                Configuring an Vector Mosaic data source

                                                                Option Description Workspace Name of the workspace to contain the Vector Mosaic store. Data Source Name Name of the Vector Mosaic Store as it will be known to GeoServer. Description A full free-form description of the Vector Mosaic store. Enabled If checked, it enables the store. If unchecked (disabled), no data in the Vector Mosaic Store will be served from GeoServer. delegateStoreName The data source name of the data store previously created that holds the index information about the constituent vector granules. See here for more details about delegate store requirements. connectionParameterKey The delegate store has a mandatory field called \"params\". Params can either be a URI pointing at the granule resource location or it can be a configuration string in .properties format. (See Java Properties file for more details about the format) In the latter case this optional parameter specifies which key points at the location of the granule. Accepted values are \"file\" and \"url\". preferredDataStoreSPI This optional parameter can serve as an optimization to speed up the lookup of granule data stores. Instead of attempting to use the mandatory delegate params field (See delegate requirements for more details about delegate store requirements.) to look up supported data store types, the Vector Mosaic data store will use the data store SPI specified in this field to identify the correct type."},{"location":"community/vector-mosaic/delegate/","title":"Vector Mosaic Datastore Delegate Requirements","text":"

                                                                The Vector Mosaic Datastore Delegate is a datastore that contains references to the vector granule datastores, bounding polygon or multipolygon geometry to delineate the index area, and optionally other attributes that can be queried in order to return vector granules.

                                                                The delegate datastore can be in any format that GeoServer supports but there are two required fields:

                                                                • There must be a geometry field representing the index spatial area in either Polygon or MultiPolygon form. There are not requirements on the name of such field.
                                                                • There should be a field called params, in text format, that contains either:
                                                                  • The name of a store already configured in GeoServer (useful to handle few granule stores, and avoid re-creating the store at every read). The string is considered a potential name if it does not contain an equal sign (making it a candidate for property format) or a colon or having path separators (making it a candidate for URI/URL).
                                                                  • The URI/URL pointing at granule resources like shapefiles, GeoPackage, FlatGeobuf, etc. (for simplicity).
                                                                  • A configuration string in .properties format. (See Java Properties file for more details about the format).

                                                                In addition to that, the following fields are optional: * type indicates the typename to be used when querying the granule store. Useful when the target store can contain multiple feature types. If not present, it's recommended to target a store with a single feature type (e.g., Shapefile, FlatGeoBuf). * filter is a (E)CQL filter that can be used to cherry pick the features to be read from the delegate store. This is useful when the delegate store contains a large number of features, and only a subset of them are of interest for the given set of index record attributes.

                                                                Any other field beyond the two required can serve as queryable/filterable attribute, and will be used to narrow the number of potential granule vectors that are searched by a query. The non-required parameters will be combined with the vector granule parameters to create the output feature type.

                                                                An example of a delegate in property datastore format can be found here. The name field can be used to filter the granules, while params` contains the location of the granule file andgeomits footprint. Thetypefield can be used for filtering, but also indicates the name of the feature type to be used when querying the granule store (in this case, happens to match the name of the target shapefile). Creating an Index with ogrtindex ================================ The `ogrtindex <https://gdal.org/programs/ogrtindex.html>`_ commandline tool from the GDAL library can be used to collect all data sets in a directory, and create an index table for it. The format of the location is slightly different than the one GeoServer expects, as it uses alocation,tableIndexformat, so a quick SQL needs to be run to make it match. Here is an example that generates a delegate shapefile from a directory of shapefiles. The third step below usesogr2ogrcommandline to trim a comma and number thatogrtindexappends to the end of the granule reference, and to turn the file location into a valid URL. #. Switch to directory with the shapefiles #. ogrtindex -write_absolute_path -tileindex \"params\" delegate_raw.shp \\*.shp #. ogr2ogr delegate.shp delegate_raw.shp -dialect SQLite -sql \"SELECT Geometry,'file://'||SUBSTR(params,1,LENGTH(params)-2) AS params from delegate_raw\" Thedelegate.shpshapefile can then be published as a store in GeoServer (no need to publish the layer), and then the mosaic store can be created, referencing to it: For example, let's say one downloads the `TIGER shapefile <https://www.census.gov/geographies/mapping-files/time-series/geo/tiger-line-file.html>`_ for thePLACEtheme, providing a shapefile with urban areas for each of the US states: .. code-block:: raw_markdown ![](images/places-files.png) Scripts exist that help with the bulk download of the files for a given theme and year, e.g. `get-tiger <https://github.com/fitnr/get-tiger>`_.ogrtindexandogr2ogrcan be used to generate a index shapefile, which will be then configured in GeoServer, and then serve as the base for mosaic store: .. code-block:: raw_markdown ![](images/places-stores.png) *The store containing the delegate/index table, and the mosaic store* .. code-block:: raw_markdown ![](images/places-mosaic-config.png) *The mosaic store refers to the delegate store by name* TheconnectionParameterKeyisurl, as that's what the Shapefile datastore is looking for, a parameter namedurlwith the location of the shapefile to open. The preferred SPI is setup to the Shapefile store to speed up the lookup of the granule store (it can be omitted, with a small performance drop). The mosaic layer can then be published in GeoServer, rendering all the required shapefiles in a single map: .. code-block:: raw_markdown ![](images/places-mosaic.png) Creating FlatGeobuf Granules with ogr2ogr and ogrtindex ====================================================================== `FlatGeobuf <https://flatgeobuf.org>`_ files make for an excellent option for cloud storage of granule data due the built in support for R-Tree indices and the use of `HTTP Range requests <https://developer.mozilla.org/en-US/docs/Web/HTTP/Range_requests>`_ to limit the amount of data streamed over the network.ogr2ogrcan be used to convert a directory of shapefiles into a directory of indexed Flatgeobufs using a simple bash script like below .. code-block:: bash #!/bin/bash shopt -s nullglob FILES=\"/data/tiger/*.shp\" for f in $FILES do fgbfilename=\"$(basename $f .shp).fgb\" ogr2ogr -f FlatGeobuf $fgbfilename $f -nlt PROMOTE_TO_MULTI -lco SPATIAL_INDEX=YES done Here is an example that generates a delegate shapefile from the directory of FlatGeobufs. The third step below usesogr2ogrcommandline to trim a comma and number thatogrtindexappends to the end of the granule reference, and to turn the file location into a valid URL. Note the exclusion of thewrite_absolute_path. Instead we append the AWS S3 bucket URL to the generated filename. #. Switch to directory with the FlatGeoBufs. #. ogrtindex -tileindex \"params\" delegate_raw.shp \\*.fgb #. ogr2ogr delegate.shp delegate_raw.shp -dialect SQLite -sql \"SELECT Geometry,'https://mybucketname.s3.amazonaws.com/'||SUBSTR(params,1,LENGTH(params)-2) AS params from delegate_raw\" #. Upload FlatGeobuf granule files to the S3 bucket referenced in the earlier step (and confirm that the bucket contents are publicly available). At this point you can publish thedelegate.shp`shapefile as a store in GeoServer as described in the previous example or you can load it into PostGIS before publication (see \\`Smart Data Loader \\<../smart-data-loader/data-store.html\\>_ for a tool for creating the PostGIS store). A PostGIS delegate is especially useful mosaics that might change over time due to support for concurrent edits, high rate loading and transactions. Note that because the granule references in the index are HTTPS URLs the index FlatgeoBuf can be hosted anywhere that your GeoServer installation can access.

                                                                "},{"location":"community/vector-mosaic/installing/","title":"Installing Vector Mosaic Datastore","text":"

                                                                To install the Vector Mosaic datastore:

                                                                1. Download the module: vector-mosaic
                                                                2. Extract this file and place the JARs in WEB-INF/lib.
                                                                3. Perform any configuration required by your servlet container, and then restart.
                                                                "},{"location":"community/vsi/","title":"VSI Virtual File System Support","text":"

                                                                Support for GDAL's virtual file systems, accessible via a /vsi-prefixed path.

                                                                "},{"location":"community/vsi/#configuration","title":"Configuration","text":"

                                                                All configuration parameters are specified in a vsi.properties file. Any configuration option listed in GDAL's documentation. is available as a key in this file. You can specify its location on your system with the -Dvsi.properties.location option. An example configuration providing OpenStack credentials may look like:

                                                                OS_IDENTITY_API_VERSION = 3\nOS_AUTH_URL = https://swift.provider.com/v3\nOS_PROJECT_NAME = test-project\nOS_USERNAME = user@example.com\nOS_PASSWORD = example-password\nOS_USER_DOMAIN_NAME = Default\nOS_PROJECT_DOMAIN_NAME = default\n
                                                                "},{"location":"community/vsi/#usage","title":"Usage","text":"

                                                                This extension adds 'VSI Virtual File System' as a possible raster data store type. The only values required when choosing this type is a connection path. This is identical to the connection paths specified in GDAL's documentation. You may also chain GDAL drivers together by concatenating their prefixes, as in the example below.

                                                                VSI Virtual File System data store configuration

                                                                "},{"location":"community/web-service-auth/","title":"HTTP Based Authorization plug-in","text":"

                                                                This plugin brings the possibility to authenticate users using an external authentication service.

                                                                • Installing the HTTP Based Authorization plug-in
                                                                • HTTP Based Authorization configuration
                                                                "},{"location":"community/web-service-auth/configuration/","title":"HTTP Based Authorization configuration","text":"

                                                                The HTTP Based Authorization plug-in will try to authenticate the user on an configured external authentication service. The username and the password will be sent to the service in one of the following ways:

                                                                • In a Header named X-HTTP-AUTHORIZATION.
                                                                • As a query parameters or as request path. For this use case the url needs to be configured by inseritng two placeholder, namely {user} and {password} , where the username and password are expected to be provided eg. https://my-auth-service?username={username}&password={password}.

                                                                The Authentication Provider will perform a GET request, sending credential Base64 encoded. If the response status returned by the external service is different from 200 the user will not be authenticated.

                                                                In case the external authentication service is returning the authenticated user's roles in the response body, it is possible to define a regular expression to extract them, allowing for their usage for authorization. There is no limitation to a specific content type.

                                                                Once the plug-in is installed, it can be configured by:

                                                                • Opening the Authentication option in the Security menu
                                                                • Choosing Authentication provider and then add new.
                                                                • Choose the Web Service Authentication option

                                                                Clicking on Web Service Authentication offers the possibility to enter the provider settings.

                                                                Where:

                                                                • Service URL is the URL of the external service meant to be used for authentication.
                                                                • Timeout is the connection timeout.
                                                                • Read Timeout is the timeout on waiting to read response data.
                                                                • The Send credentials in X-HTTP-AUTHORIZATION Header checkbox is meant to be flagged if credentials have to be sent through the authorization header. If unchecked (default) GeoServer expects to find placeholders for username and password as {user} and {password} in the provided URL instead.
                                                                • The Allow HTTP connection checkbox if flagged will allow authentication request to be performed toward an external service that uses HTTP protocol. By default only HTTPS is allowed.
                                                                • In the Authorization section the radio button allows to define whether to use a GeoServer RoleService to read roles or if roles are meant to be returned by the external authentication service.
                                                                • In case Read Roles from Web Response is chosen, a regular expression to extract the roles from the authentication service response needs to be provided.

                                                                Once the settings are saved the new AuthenticationProvider is added to the list and needs to be added into the list of the providers' chain

                                                                "},{"location":"community/web-service-auth/install/","title":"Installing the HTTP Based Authorization plug-in","text":"
                                                                1. Download the nightly GeoServer community module from web-service-auth.

                                                                  ::: warning ::: title Warning :::

                                                                  Make sure to match the version of the extension to the version of the GeoServer instance! :::

                                                                1. Extract the contents of the archive into the WEB-INF/lib directory of the GeoServer installation.
                                                                "},{"location":"community/webp/","title":"WMS WebP output format","text":"

                                                                This module adds the WebP WMS output format.

                                                                WMS GetMap Request: FORMAT=image/webp

                                                                Advantages of the WebP image format compared to other formats:

                                                                • | WebP lossy images are about 30% smaller than comparable JPEG images.

                                                                • | WebP supports transparency, typically providing 3x smaller file sizes compared to PNG.

                                                                • | WebP supports paletted images, typically providing 20% smaller file sizes compared to PNG.

                                                                Attention! Unfortunately, all the advantages of the WebP format regarding file size are negated by a more complex, time and energy-consuming processing.

                                                                However, the WebP format could serve as an input format for the GWC and then play out the advantages again. Work is in progress.

                                                                Read more about it here: WebP processing

                                                                Only in exceptional cases where a slow internet connection is given (e.g. G3) this format makes sense.

                                                                WebP is supported by all modern browsers (caniuse). However, backwards compatibility can be built in on the client side. Use Google's recommended function to detect with Javascript if the browser supports WebP. Be aware that the used image-loading is non-blocking and asynchronous. Any code that depends should preferably be put in the callback function.

                                                                Example for OpenLayers v7 WebP browser support check via javascript:

                                                                ...\nimport ImageLayer from 'ol/layer/Image';\nimport ImageWMS from 'ol/source/ImageWMS';\n...\nfunction check_webp_feature(feature, callback) {\n... // code from google link above\n}\ncheck_webp_feature('lossless', function (feature, isSupported) {\n  let wmsoutputformat = 'image/webp'\n  if (!isSupported) {\n     wmsoutputformat = 'image/png'\n  }\n  var wmsLayerSource = new ImageWMS({\n    params: {'LAYERS': 'yourLayerName','FORMAT': wmsoutputformat},\n    ...\n  });\n  ... // your OL code\n});\n

                                                                Because native libraries are used, not all platforms are supported. For those supported, no additional native library needs to be installed though. The plugin is based on Java ImageIO WebP support, here you can find further information. If your platform is not supported, there are instructions for compiling the native library. In this case, do not forget to contribute.

                                                                • Installing WMS WebP output format
                                                                • WebP Processing
                                                                "},{"location":"community/webp/installing/","title":"Installing WMS WebP output format","text":"

                                                                To install the WMS WebP output format extension:

                                                                1. Download the webp community extension from the appropriate nightly build. The file name is called geoserver-*-webp-plugin.zip, where * matches the version number of GeoServer you are using.
                                                                2. Extract this these files and place the JARs in WEB-INF/lib.
                                                                3. Perform any configuration required by your servlet container, and then restart.
                                                                "},{"location":"community/webp/webp_processing/","title":"WebP Processing","text":"

                                                                WebP achieves better compression rates by being more complex. The cost of this complexity is that it's slower, particularly at encoding.

                                                                \"Therefore, it's not usually advisable to convert images to WebP on the fly. WebP files should be generated in advance.\" (@webmproject.org)

                                                                Detailed information about this image format can be obtained from Googles WebP Website and the WebP Discussion Group.

                                                                A simpler representative representation can be found at Learn Images! WebP.

                                                                Results based on the standard libraries and the ImageIO WebP extension

                                                                +---------------------+--------------------+-------------------------+-----------------------+ | tile size [pixel] | ImageIO PNG [ms] | ImageIO Ext WebP [ms] | LibWebP encode [ms] | +=====================+====================+=========================+=======================+ | > 128 | > 5 | > 67 | > 11.2 | +---------------------+--------------------+-------------------------+-----------------------+ | > 256 | > 15 | > 304 | > 30.1 | +---------------------+--------------------+-------------------------+-----------------------+ | > 512 | > 64 | > 1034 | > 91.4 | +---------------------+--------------------+-------------------------+-----------------------+ | > 1024 | > 177 | > 2089 | > 440.5 | +---------------------+--------------------+-------------------------+-----------------------+ | > 2048 | > 1068 | > 8027 | > 1595.9 | +---------------------+--------------------+-------------------------+-----------------------+

                                                                Table 1: Comparison of the processing time for different tile sizes and image formats. For the ImageIO images, the average of 1000 .write functions was calculated. With LibWebP, the average of the encoding duration was calculated for 10 passes. For WebP processing, the default settings were used (lossy, q=75) and Version 1.0.0. GeoserverRequest for image (256*256).

                                                                +---------------------+--------------+-------------+------------------+---------+ | tile size [pixel] | PNG original | ImageIO PNG | ImageIO Ext WebP | LibWebP | +=====================+==============+=============+==================+=========+ | > 128 | > 14 | > 13 | > 5 | > 5 | +---------------------+--------------+-------------+------------------+---------+ | > 256 | > 64 | > 60 | > 25 | > 25 | +---------------------+--------------+-------------+------------------+---------+ | > 512 | > 223 | > 204 | > 106 | > 106 | +---------------------+--------------+-------------+------------------+---------+ | > 1024 | > 805 | > 769 | > 352 | > 352 | +---------------------+--------------+-------------+------------------+---------+ | > 2048 | > 2283 | > 2171 | > 1062 | > 1062 | +---------------------+--------------+-------------+------------------+---------+

                                                                Table 2: Comparison of the size in KB for different tile sizes and image formats (see table above).

                                                                It is obvious that WebP can never match the performance of PNG images due to its encoding time.

                                                                However, this does not explain the much worse results of the ImageIO WebP extension. Unfortunately, the original repository is not available any more, and the main fork webp_imageio is outdated and unmaintained. The Geoserver plugin is based on the fork from GOTSON. A hopeful new pure Java implementation is TwelveMonkeysImageIO WebP, but so far only supports read access. Scrimage Webp produced mostly faster results, but does not fit in Geoservers ImageIO ecosystem. Google itself provides for Android libwebp Java bindings.

                                                                WebP supports lossless compression (for graphics) and lossy compression (for photos). Default is lossy with compression quality 75.

                                                                • | Lossy compression: A small compression quality factor (q) produces a smaller file with lower quality (best quality q=100).

                                                                • | Lossless compression: A small factor enables faster compression speed, but produces a larger file (maximum compression q=100).

                                                                +-------+-----------------+-----------------+--------------+--------------+ | q | lossless [ms] | lossless [kb] | lossy [ms] | lossy [kb] | +=======+=================+=================+==============+==============+ | > 0.0 | > 48 | > 57 | > 18.6 | > 25 | +-------+-----------------+-----------------+--------------+--------------+ | > 0.1 | > 48.8 | > 57 | > 19.5 | > 26 | +-------+-----------------+-----------------+--------------+--------------+ | > 0.2 | > 48.7 | > 57 | > 19.7 | > 27 | +-------+-----------------+-----------------+--------------+--------------+ | > 0.3 | > 82.6 | > 45 | > 20.4 | > 27 | +-------+-----------------+-----------------+--------------+--------------+ | > 0.4 | > 84.6 | > 45 | > 20.6 | > 28 | +-------+-----------------+-----------------+--------------+--------------+ | > 0.5 | > 85.6 | > 45 | > 20.8 | > 29 | +-------+-----------------+-----------------+--------------+--------------+ | > 0.6 | > 89.1 | > 45 | > 20.8 | > 29 | +-------+-----------------+-----------------+--------------+--------------+ | > 0.7 | > 93.9 | > 45 | > 21.2 | > 30 | +-------+-----------------+-----------------+--------------+--------------+ | > 0.8 | > 99.3 | > 45 | > 21.4 | > 32 | +-------+-----------------+-----------------+--------------+--------------+ | > 0.9 | > 99.3 | > 45 | > 22.5 | > 36 | +-------+-----------------+-----------------+--------------+--------------+ | > 1.0 | > 1425 | > 44 | > 25.3 | > 46 | +-------+-----------------+-----------------+--------------+--------------+

                                                                Table 3: Comparison of the lossy/lossless mode and compression factor (q) for LibWebP encoding time and file size. Input image, see below. The average of the encoding duration was calculated for 10 passes.

                                                                +-------+-----------------+-----------------+--------------+--------------+ | q | lossless [ms] | lossless [kb] | lossy [ms] | lossy [kb] | +=======+=================+=================+==============+==============+ | > 0.0 | > 242 | > 57 | > 113 | > 25 | +-------+-----------------+-----------------+--------------+--------------+ | > 0.1 | > 211 | > 57 | > 145 | > 26 | +-------+-----------------+-----------------+--------------+--------------+ | > 0.2 | > 236 | > 57 | > 137 | > 27 | +-------+-----------------+-----------------+--------------+--------------+ | > 0.3 | > 370 | > 45 | > 150 | > 27 | +-------+-----------------+-----------------+--------------+--------------+ | > 0.4 | > 376 | > 45 | > 140 | > 28 | +-------+-----------------+-----------------+--------------+--------------+ | > 0.5 | > 308 | > 45 | > 128 | > 29 | +-------+-----------------+-----------------+--------------+--------------+ | > 0.6 | > 375 | > 45 | > 123 | > 29 | +-------+-----------------+-----------------+--------------+--------------+ | > 0.7 | > 529 | > 45 | > 126 | > 30 | +-------+-----------------+-----------------+--------------+--------------+ | > 0.8 | > 468 | > 45 | > 125 | > 32 | +-------+-----------------+-----------------+--------------+--------------+ | > 0.9 | > 424 | > 45 | > 130 | > 36 | +-------+-----------------+-----------------+--------------+--------------+ | > 1.0 | > 3106 | > 44 | > 184 | > 46 | +-------+-----------------+-----------------+--------------+--------------+

                                                                Table 4: Comparison of the lossy/lossless mode and compression factor (q) for ImageIO WebP extension .write time and file size. Input image, see below. The average of 1000 .write functions was calculated.

                                                                Figure 1: Input image for comparison in table 3 and 4 (PNG 256 * 256 px, 73 kb).

                                                                Unfortunately, the best result regarding speed and size is not really usable (see below).

                                                                Figure 2: Image of the best result (lossy, q=0).

                                                                In general, the default values (lossy, q=0.75) are a good choice.

                                                                The significantly longer duration regarding the ImageIO Extension cannot be explained by the writing process alone (compare tables 3 & 4).

                                                                Processing time & energy consumption

                                                                The increased processing time correlates with increased energy consumption.

                                                                Measured with a commercial power meter on a local PC for one hour (multiple times).

                                                                Stack:

                                                                • | Windows10

                                                                • | Java11

                                                                • | Tomcat9

                                                                • | Chrome Browser

                                                                • | OpenLayers Client

                                                                • | random WMS GetMap requests every 0.5 seconds

                                                                Result:

                                                                • | PNG 0.067 kWh

                                                                • | WebP 0.071 kWh

                                                                • | NoRequests 0.047 kWh

                                                                This also applies to the JPEG format in a weakened way.

                                                                Browser rendering energy impact for different image formats

                                                                +--------------+----------------+ | Image Format | Energie impact | +==============+================+ | > WebP | > 0.4532 | +--------------+----------------+ | > PNG | > 0.4545 | +--------------+----------------+ | > PNG8 | > 0.457 | +--------------+----------------+ | > JPEG | > 0.4414 | +--------------+----------------+

                                                                Table 5: Comparison of the rendering energy consumption for different image formats in Firefox. Average of 1000 WMS GetMap requests.

                                                                Firefox \"Energy Impact\" (about:processes page) shows the processing power being used by the CPU.

                                                                Despite the different file sizes of the image formats, no really significant differences can be seen. Of course, more complex coding also requires more complex decoding.

                                                                "},{"location":"community/wps-longitudinal-profile/","title":"WPS longitudinal profile process","text":"

                                                                WPS longitudinal profile process provides the ability to calculate an altitude profile for the specified linestring.

                                                                In addition, the process can:

                                                                • Reproject result to different CRS
                                                                • Adjust altitude profile based on additional layer
                                                                "},{"location":"community/wps-longitudinal-profile/#installing-the-wps-longitudinal-profile-process","title":"Installing the WPS longitudinal profile process","text":"
                                                                1. If you haven't done already, install the WPS extension: Installing the WPS extension.

                                                                2. Download the WPS longitudinal profile process extension from the nightly GeoServer community module builds.

                                                                  ::: warning ::: title Warning :::

                                                                  Make sure to match the version of the extension to the version of the GeoServer instance! :::

                                                                3. Extract the contents of the archive into the WEB-INF/lib directory of the GeoServer installation.

                                                                "},{"location":"community/wps-longitudinal-profile/#module-description","title":"Module description","text":"

                                                                This module provides longitudinal profile process. The process splits provided geometry (for example linestring) into segments of no more then provided distance length. Then evaluates altitude for each point and builds longitudinal profile. If adjustment layer name is provided, altitude will be adjusted by searching feature that contains corresponding point, and getting it's altitude attribute, further subtracting it from altitude received from coverage. If targetProjection parameter is provided, points of profile will be reprojected to target CRS, otherwise to CRS of provided ewkt geometry.

                                                                Process accepts following parameters:

                                                                Required:

                                                                1. layerName - name of the raster layer (coverage) which will be used for altitude profile creation
                                                                2. geometry - geometry in wkt or ewkt format, along which the altitude profile will be created. If wkt is used, its CRS will be assumed as CRS of coverage.
                                                                3. distance - maximal distance between points of altitude profile

                                                                Optional:

                                                                1. adjustmentLayerName - name of the layer with altitude, which will be used to adjust altitude values. Layer should have polygon or multipolygon geometry, and altitude attribute. Layer should be configured in the GeoServer
                                                                2. targetProjection - target CRS of result
                                                                3. altitudeIndex - index of altitude field in the array of coverage coordinates (0 by default)
                                                                4. altitudeName - name of the altitude attribute on adjustment layer feature type

                                                                Response contains following objects:

                                                                1. profile - contains array of points of the profile
                                                                2. infos - general info on process result

                                                                The profile object contains an array of points.

                                                                Each point has following values:

                                                                1. totalDistanceToThisPoint - distance to this point from the beginning of the profile (first point) in units of CRS
                                                                2. x - x coordinate of point
                                                                3. y - y coordinate of point
                                                                4. altitude - altitude of this point
                                                                5. slope - slope between previous and current altitude

                                                                Infos object fields:

                                                                1. altitudePositive - sum of positive altitudes on this profile
                                                                2. altitudeNegative - sum of negative altitudes on this profile
                                                                3. distance - total length of profile
                                                                4. firstpointX - x coordinate of first point
                                                                5. firstpointY - y coordinate of first point
                                                                6. lastpointX - x coordinate of last point
                                                                7. lastpointY - y coordinate of last point
                                                                8. representation - target CRS of resulting points
                                                                9. processedpoints - total number of processed points
                                                                10. executedtime - duration of process execution in milliseconds

                                                                Note

                                                                It's possible to set wpsLongitudinalMaxThreadPoolSize (integer value) environment variable to limit the size of the extension's thread pool. It's possible to set wpsLongitudinalVerticesChunkSize (integer value) environment variable to define number of vertices processed in a chunk.

                                                                "},{"location":"community/xslt/","title":"XSLT WFS output format module","text":"

                                                                The xslt module for GeoServer is a WFS output format generator which brings together a base output, such as GML, and a XSLT 1.0 style sheet to generate a new textual output format of user choosing.

                                                                The configuration for this output format can be either performed directly on disk, or via a REST API.

                                                                "},{"location":"community/xslt/#manual-configuration","title":"Manual configuration","text":"

                                                                All the configuration for the output resides in the $GEOSERVER_DATA_DIR/wfs/transform folder, which is going to be created on startup when missing if the XSLT output format has been installed in GeoServer.

                                                                Each XSLT transformation must be configured with its own xml file in the $GEOSERVER_DATA_DIR/wfs/transform folder, which in turn points to a xslt file for the transformation. While the names can be freeform, it is suggested to follow a simple naming convention:

                                                                • .xml for the xml config file
                                                                • .xslt for the xslt tile

                                                                  Transformations can be either global, and thus applicable to any feature type, or type specific, in which case the transformation knows about the specific attributes of the transformed feature type.

                                                                  "},{"location":"community/xslt/#global-transformation-example","title":"Global transformation example","text":"

                                                                  Here is an example of a global transformation setup. The $GEOSERVER_DATA_DIR/wfs/transform/global.xml file will look like:

                                                                  <transform>\n  <sourceFormat>text/xml; subtype=gml/2.1.2</sourceFormat>\n  <outputFormat>HTML</outputFormat>\n  <outputMimeType>text/html</outputMimeType>\n  <fileExtension>html</fileExtension>\n  <xslt>global.xslt</xslt>\n</transform>\n

                                                                  Here is an explanation of each element:

                                                                  • sourceFormat (mandatory): the output format used as the source of the XSLT transformation
                                                                  • outputFormat (mandatory): the output format generated by the transformation
                                                                  • outputMimeType (optional): the mime type for the generated output. In case it's missing, the outputFormat is assumed to be a mime type and used for the purpose.
                                                                  • fileExtension (optional): the file extension for the generated output. In case it's missing txt will be used.
                                                                  • xslt (mandatory): the name of XSLT 1.0 style sheet used for the transformation

                                                                  The associated XSLT file will be $GEOSERVER_DATA_DIR/wfs/transform/global.xslt folder, and it will be able to transform any GML2 input into a corresponding HTML file. Here is an example:

                                                                  <?xml version=\"1.0\" encoding=\"ISO-8859-1\"?>\n<xsl:stylesheet version=\"1.0\" xmlns:wfs=\"http://www.opengis.net/wfs\"\n  xmlns:tiger=\"http://www.census.gov\" xmlns:gml=\"http://www.opengis.net/gml\"\n  xmlns:xsl=\"http://www.w3.org/1999/XSL/Transform\">\n  <xsl:template match=\"/\">\n    <html>\n      <body>\n      <xsl:for-each select=\"wfs:FeatureCollection/gml:featureMember/*\">\n        <h2><xsl:value-of select=\"@fid\"/></h2>\n        <table border=\"1\">\n          <tr>\n            <th>Attribute</th>\n            <th>Value</th>\n          </tr>\n            <!-- [not(*)] strips away all nodes having \n                 children, in particular, geometries -->\n            <xsl:for-each select=\"./*[not(*)]\">\n            <tr>\n              <td>\n                <xsl:value-of select=\"name()\" />\n              </td>\n              <td>\n                <xsl:value-of select=\".\" />\n              </td>\n            </tr>\n            </xsl:for-each>\n        </table>\n     </xsl:for-each>\n     </body>\n   </html>\n  </xsl:template>\n</xsl:stylesheet>\n
                                                                  "},{"location":"community/xslt/#type-specific-transformations","title":"Type specific transformations","text":"

                                                                  Type specific transformations can refer to a specific type and leverage its attributes directly. While not required, it is good practice to setup a global transformation that can handle any feature type (since the output format is declared in the capabilities document as being general, not type specific) and then override it for specific feature types in order to create special transformations for them.

                                                                  Here is an example of a transformation declaration that is type specific, that will be located at $GEOSERVER_DATA_DIR/wfs/transform/html_bridges.xml

                                                                  <transform>\n  <sourceFormat>text/xml; subtype=gml/2.1.2</sourceFormat>\n  <outputFormat>HTML</outputFormat>\n  <outputMimeType>text/html</outputMimeType>\n  <fileExtension>html</fileExtension>\n  <xslt>html_bridges.xslt</xslt>\n  <featureType>\n    <id>cite:Bridges</id>\n  </featureType>\n</transform>\n

                                                                  The extra featureType element associates the transformation to the specific feature type

                                                                  The associated xslt file will be located at $GEOSERVER_DATA_DIR/wfs/transform/html_bridges.xslt and will leveraging knowledge about the input attributes:

                                                                  <?xml version=\"1.0\" encoding=\"ISO-8859-1\"?>\n<xsl:stylesheet version=\"1.0\" xmlns:wfs=\"http://www.opengis.net/wfs\"\n  xmlns:cite=\"http://www.opengis.net/cite\" xmlns:gml=\"http://www.opengis.net/gml\"\n  xmlns:xsl=\"http://www.w3.org/1999/XSL/Transform\">\n  <xsl:template match=\"/\">\n    <html>\n      <body>\n        <h2>Bridges</h2>\n        <xsl:for-each\n            select=\"wfs:FeatureCollection/gml:featureMember/cite:Bridges\">\n        <ul>\n          <li>ID: <xsl:value-of select=\"@fid\" /></li>\n          <li>FID: <xsl:value-of select=\"cite:FID\" /></li>\n          <li>Name: <xsl:value-of select=\"cite:NAME\" /></li>\n        </ul>\n        <p/>\n        </xsl:for-each>\n      </body>\n    </html>\n  </xsl:template>\n</xsl:stylesheet>\n

                                                                  Note

                                                                  While writing the XSLT always remember to declare all prefixes used in the sheet in the stylesheet element, otherwise you might encounter hard to understand error messages

                                                                  A specific feature type can be associated to multiple output formats. While uncommon, the same xslt file can also be associated to multiple feature types by creating multiple xml configuration files, and associating a different feature type in each.

                                                                  "},{"location":"community/xslt/#rest-configuration","title":"Rest configuration","text":"

                                                                  Transformations can be created, updated and deleted via the REST api (normally, this requires administrator privileges). Each transformation is represented with the same XML format used on disk, but with two variants:

                                                                  • a new name attribute appears, which matches the XML file name
                                                                  • the featureType element contains also a link to the resource representing the feature type in the REST config tree

                                                                  For example:

                                                                  <transform>\n  <name>test</name>\n  <sourceFormat>text/xml; subtype=gml/2.1.2</sourceFormat>\n  <outputFormat>text/html</outputFormat>\n  <fileExtension>html</fileExtension>\n  <xslt>test-tx.xslt</xslt>\n  <featureType>\n    <name>tiger:poi</name>\n    <atom:link xmlns:atom=\"http://www.w3.org/2005/Atom\" rel=\"alternate\" href=\"http://localhost:8080/geoserver/rest/workspaces/cite/datastores/cite/featuretypes/bridges.xml\" type=\"application/xml\"/>\n  </featureType>\n</transform>\n

                                                                  Here is a list of resources and the HTTP methods that can be used on them.

                                                                  /rest/services/wfs/transforms[.<format>]

                                                                  Method Action Return Code Formats Default Format Parameters GET List all available transforms 200 HTML, XML, JSON HTML POST Add a new transformation 201, with Location header XML, JSON name, sourceFormat, outputFormat, outputMimeType PUT Update global settings 200 XML, JSON DELETE 405

                                                                  The POST method can be used to create a transformation in two ways:

                                                                  • if the content type used is application/xml the server will assume a <transform> definition is being posted, and the XSLT will have to be uploaded separately using a PUT request with content type application/xslt+xml against the transformation resource
                                                                  • if the content type used is application/xslt+xml the server will assume the XSLT itself is being posted, and the name, sourceFormat, outputFormat, outputMimeType query parameters will be used to fill in the transform configuration instead

                                                                  /rest/services/wfs/transforms/<transform>[.<format>]

                                                                  Method Action Return Code Formats Default Format GET Returns the transformation 200 HTML, XML, XSLT HTML POST 405 PUT Updates either the transformation configuration, or its XSLT, depending on the mime type used 200 XML, XSLT DELETE Deletes the transformation 200

                                                                  The PUT operation behaves differently depending on the content type used in the request:

                                                                  • if the content type used is application/xml the server will assume a <transform> definition is being sent and will update it
                                                                  • if the content type used is application/xslt+xml the server will assume the XSLT itself is being posted, as such the configuration won't be modified, but the XSLT associated to it will be overwritten instead
                                                                  "},{"location":"configuration/","title":"Server configuration","text":"

                                                                  This page will detail how to set various configuration options in GeoServer as well as test out the services in GeoServer. It also describes how to view the GeoServer instance status.

                                                                  • Status
                                                                  • Contact Information
                                                                  • Service Metadata
                                                                  • Global Settings
                                                                  • Image Processing
                                                                  • Raster Access
                                                                  • REST Configuration
                                                                  • Advanced log configuration
                                                                  • Coordinate Reference System Handling
                                                                  • Virtual Services
                                                                  • Internationalization (i18n)
                                                                  • Demos
                                                                  • Tools
                                                                  "},{"location":"configuration/REST/","title":"REST Configuration","text":"

                                                                  Note

                                                                  For more information, please see the section on REST.

                                                                  The RESTful API allows to create new stores and append new granules to mosaics via file uploads. By default the new stores and granules are saved with the following directory structure:

                                                                  $GEOSERVER_DATA_DIR/data/<workspace>/<store>[/<file>]\n

                                                                  For changing the Root Directory from \\$GEOSERVER_DATA_DIR/data to another directory, the user can define a parameter called Root Directory path inside Global Settings Page and Workspace Settings Page.

                                                                  In order to avoid cross workspace contamination, the final path will always be:

                                                                  ${rootDirectory}/workspace/store[/<file>]\n

                                                                  Path remapping is achieved by using the default implementation of the RESTUploadPathMapper interface. This interface gives the possibility to also map the file position inside the store, which could be useful for harvesting files into an existing mosaic DataStore.

                                                                  "},{"location":"configuration/contact/","title":"Contact Information","text":"

                                                                  The Contact Information is used in the `Capabilities`` document of the WMS and other web services, and is publicly accessible.

                                                                  Contact information supports Internationalization (i18n) allowing services to be described in the requested locale.

                                                                  "},{"location":"configuration/contact/#organization","title":"Organization","text":"

                                                                  Complete this form with the organization details.

                                                                  Contact Information Organization

                                                                  The welcome message is displayed in the welcome page header as an introduction to the GeoServer web services. The organization name and online resource, if provided, are used in the welcome page header for the For more information visit link.

                                                                  Contact information fields:

                                                                  Field Description Organization Name of the organization with which the contact is affiliated Online Resource Website for organization Welcome Introduction displayed on the welcome page"},{"location":"configuration/contact/#primary-contact","title":"Primary contact","text":"

                                                                  Complete this form with the relevant contact information.

                                                                  Contact Information Primary Contact

                                                                  The email address, if provided, is used to provide a Contact administrator link for the welcome page footer.

                                                                  Contact information fields:

                                                                  Field Description Contact Contact information for webmaster Position Position of the contact within their organization Email Contact email address Telephone Contact phone number Fax Contact Fax number"},{"location":"configuration/contact/#address","title":"Address","text":"

                                                                  Complete this form with the relevant physical address information.

                                                                  Contact Information Address

                                                                  Address information fields:

                                                                  Address Type Type of address specified, such as postal Address Actual street address City City of the address State State or province of the address Zip code Postal code for the address Country Country of the address"},{"location":"configuration/globalsettings/","title":"Global Settings","text":"

                                                                  The Global Setting page configures messaging, logging, character, and proxy settings for the entire server.

                                                                  "},{"location":"configuration/globalsettings/#ogc-services","title":"OGC Services","text":"

                                                                  Global Settings are used to configure how OGC Web Services function.

                                                                  Global Settings Service Configuration

                                                                  "},{"location":"configuration/globalsettings/#service-settings","title":"Service Settings","text":""},{"location":"configuration/globalsettings/#config_globalsettings_proxy_base","title":"Proxy Base URL","text":"

                                                                  GeoServer can have the capabilities documents report a proxy properly. \"The Proxy Base URL\" field is the base URL seen beyond a reverse proxy.

                                                                  The Proxy Base URL field support environment parametrization (see Parameterize catalog settings ) by activating the JVM parameter:

                                                                  -DALLOW_ENV_PARAMETRIZATION=true\n

                                                                  Once activated the environment parametrization Proxy Base URL can be parameters placeholders like:

                                                                  ${proxy.base.url}\n
                                                                  "},{"location":"configuration/globalsettings/#config_globalsettings_proxy_headers","title":"Use headers for Proxy URL","text":"

                                                                  Checking this box allows a by-request modification of the proxy URL using templates (templates based on HTTP proxy headers).

                                                                  The supported proxy headers are:

                                                                  1. X-Forwarded-Proto The protocol used by the request
                                                                  2. X-Forwarded-Host The hostname and port of the proxy URL
                                                                  3. X-Forwarded-For The client IP address
                                                                  4. X-Forwarded-Path The path of the proxy URL (this is not an official HTTP header, although it is supported by some web-servers)
                                                                  5. Forwarded Header that supersedes the \"X-Forwarded-*\" headers above. It has these components: \"by\", \"for\", \"host\", \"proto\", \"path\" (this component is not official, but added for consistency with X-Forwarded-Path)
                                                                  6. Host Same as X-Forwarded

                                                                  For instance, to allow different protocols (http and https) and different hostnames, the proxy base URL field may be changed to: ${X-Forwarded-Proto}://${X-Forwarded-Host}/geoserver The use of the Forwarded header is a tad more complex, as its components have to be referenced in templates with the dot-notation, as in: {Forwarded.proto}://${Forwarded.host}/geoserver.

                                                                  Multiple templates can be put into the \"Proxy Base URL\". These templates provide fall-backs, since only the first one that is fully matched is used. For instance, a Proxy Base URL of http://${X-Forwarded-Host}/geoserver http://www.foo.org/geoserver (note: templates are space-separated) can result in either: http://www.example.com/geoserver (if X-Forwarded-Host is set to www.example.com) or http://www.foo.org/geoserver (if X-Forwarded-Host is not set.)

                                                                  Both header names and the appended path (e.g. /geoserver) in templates are case-insensitive.

                                                                  When environment parametrization is activated with headers support for Proxy URL, the order of evaluation is:

                                                                  1. Environment parametrization placeholders replacement (if placeholder is not found on environment variables, it remains untouched).
                                                                  2. Headers placeholders replacements.
                                                                  "},{"location":"configuration/globalsettings/#config_globalsettings_global","title":"Enable Global Services","text":"

                                                                  When enabled, allows access to both global services and virtual services. When disabled, clients will only be able to access virtual services. Disabling is useful if GeoServer is hosting a large number of layers and you want to ensure that client always request limited layer lists. Disabling is also useful for security reasons.

                                                                  "},{"location":"configuration/globalsettings/#config_globalsettings_stored_queries","title":"Allow Per-Workspace Stored Queries","text":"

                                                                  When enabled, allows to persist Stored queries per workspace, making queries created inside a workspace available in the workspace virtual service only.

                                                                  "},{"location":"configuration/globalsettings/#service-request-settings","title":"Service Request Settings","text":""},{"location":"configuration/globalsettings/#config_globalsettings_external_entities","title":"Unrestricted XML External Entity Resolution","text":"

                                                                  XML Requests sent to GeoServer can include references to other XML documents. Since these files are processed by GeoServer the facility could be used to access files on the server, which is a security concern.

                                                                  • Enable the Unrestricted XML External Entity Resolution option when using the application schema extension to allow use of local XSD definition.

                                                                    This option disables all other External Entity Resolution restrictions (see External Entities Resolution)

                                                                  "},{"location":"configuration/globalsettings/#service-response-settings","title":"Service Response Settings","text":""},{"location":"configuration/globalsettings/#config_globalsettings_charset","title":"Character Set","text":"

                                                                  Specifies the global character encoding that will be used in XML responses. Default is UTF-8, which is recommended for most users. A full list of supported character sets is available on the IANA Charset Registry.

                                                                  "},{"location":"configuration/globalsettings/#config_globalsettings_decimals","title":"Number of Decimals","text":"

                                                                  Refers to the number of decimal places returned in a GML GetFeature response. Also useful in optimizing bandwidth. Default is 8.

                                                                  "},{"location":"configuration/globalsettings/#config_globalsettings_verbose_xml","title":"Verbose XML output","text":"

                                                                  Verbose Messages, when enabled, will cause GeoServer to return XML with newlines and indents.

                                                                  Because such XML responses contain a larger amount of data, and in turn requires a larger amount of bandwidth, it is recommended to use this option only for testing purposes.

                                                                  "},{"location":"configuration/globalsettings/#service-error-settings","title":"Service Error Settings","text":""},{"location":"configuration/globalsettings/#config_globalsettings_service_problems","title":"How to handle data and configuration problems","text":"

                                                                  This setting determines how GeoServer will respond when a layer becomes inaccessible for some reason.

                                                                  By default, when a layer has an error (for example, when the default style for the layer is deleted), a service exception is printed as part of the capabilities document, making the document invalid. For clients that rely on a valid capabilities document, this can effectively make a GeoServer appear to be \"offline\".

                                                                  An administrator may prefer to configure GeoServer to simply omit the problem layer from the capabilities document, thus retaining the document integrity and allowing clients to connect to other published layers.

                                                                  There are two options:

                                                                  • OGC_EXCEPTION_REPORT: This is the default behavior. Any layer errors will show up as Service Exceptions in the capabilities document, making it invalid.

                                                                  • SKIP_MISCONFIGURED_LAYERS: With this setting, GeoServer will elect simply to not describe the problem layer at all, removing it from the capabilities document, and preserving the integrity of the rest of the document.

                                                                    Note that having a layer \"disappear\" may cause other errors in client functionality.

                                                                    This is the default setting starting with GeoServer 2.11 and allows for faster startups, as the stores connectivity does not need to be checked in advance.

                                                                  "},{"location":"configuration/globalsettings/#config_globalsettings_service_exceptions","title":"Include stack trace in service exceptions","text":"

                                                                  Verbose exception reporting returns service exceptions with full java stack traces (similar to how they appear in geoserver log file).

                                                                  By default, this setting is disabled, and GeoServer returns single-line error messages.

                                                                  This setting is only recommended for local troubleshooting and debugging. The excessive level of detail, can act as security vulnerability (for example a file not found exception revealing folder structure of your server).

                                                                  "},{"location":"configuration/globalsettings/#internal-settings","title":"Internal Settings","text":"

                                                                  Global Settings are also used to control the GeoServer application as a whole.

                                                                  Global Settings Internal Configuration

                                                                  "},{"location":"configuration/globalsettings/#logging-settings","title":"Logging Settings","text":""},{"location":"configuration/globalsettings/#config_globalsettings_log_location","title":"Log Location","text":"

                                                                  Sets the written output location for the logs. A log location may be a directory or a file, and can be specified as an absolute path (e.g., C:\\GeoServer\\GeoServer.log) or a relative one (for example, geoserver.log). Relative paths are relative to the GeoServer data directory. Default is logs/geoserver.log.

                                                                  This Log location setting can be overridden by GEOSERVER_LOG_LOCATION property, see Advanced log configuration for details (this setting is applied FileAppender or RollingFile geoserverlogfile appender).

                                                                  "},{"location":"configuration/globalsettings/#config_globalsettings_log_profile","title":"Logging Profile","text":"

                                                                  Select a Logging profile to determine the amount of detail GeoServer logs during operation.

                                                                  The built-in logging profiles available on the global settings page are:

                                                                  • Default Logging (DEFAULT_LOGGING) --- Provides a good mix of detail without being too verbose.

                                                                    Default logging enables CONFIG and INFO messages, with a few (chatty) GeoServer and GeoTools packages reduced to WARN.

                                                                    This logging level is useful for seeing the incoming requests to GeoServer in order to double check that requests being received have been parsed correctly.

                                                                  • GeoServer Developer Logging (GEOSERVER_DEVELOPER_LOGGING) - A verbose logging profile that includes DEBUG information for GeoServer activities.

                                                                    This developer profile is recommended for active debugging of GeoServer.

                                                                  • GeoTools Developer Logging (GEOTOOLS_DEVELOPER_LOGGING) - A verbose logging profile that includes DEBUG messages for the GeoTools library.

                                                                    This developer profile is recommended for active debugging of GeoTools. This is especially good for troubleshooting rendering and data access issues.

                                                                  • Production Logging (PRODUCTION_LOGGING) - Minimal logging profile, with only WARN log messages.

                                                                    With production level logging, only problems are written to the log files.

                                                                  • Quiet Logging (QUIET_LOGGING) - Turns off logging.

                                                                  • Verbose Logging (VERBOSE_LOGGING) - Provides more detail by enabling DEBUG messages.

                                                                    This profile is only useful when troubleshooting.

                                                                  Each profile corresponds to a log4j configuration file in the GeoServer data directory (Apache log4j is a Java-based logging utility). Additional customized profiles can be added by copying one of the built-in profiles above, in the logs folder, and editing the log4j file. Use of log4j can be disabled using RELINQUISH_LOG4J_CONTROL property. See Advanced log configuration for more information.

                                                                  "},{"location":"configuration/globalsettings/#config_globalsettings_log_stdout","title":"Log to StdOut","text":"

                                                                  Standard output determines where a program writes its output data. In GeoServer, the Log to StdOut setting enables logging to the text terminal that initiated the program.

                                                                  If you are running GeoServer in a large J2EE container, you might not want your container-wide logs filled with GeoServer information. Clearing this option will suppress most GeoServer logging, with only FATAL exceptions still output to the console log.

                                                                  This setting can be overridden by system property, see Advanced log configuration for details (this setting removes Console stdout appender).

                                                                  "},{"location":"configuration/globalsettings/#config_globalsettings_log_request","title":"Enable Request Logging","text":"

                                                                  These settings enable the logging of the requested URL, and optionally request headers and the POST requests' contents, for all requests sent to GeoServer.

                                                                  • Enable Request Logging: Select to enable logging of incoming requests, this will include the operation (GET,POST,etc...) and the URL requested.
                                                                  • Log Request Bodies: Select to enable logging the body of the incoming request. Text content will be logged, or the number of bytes for binary content, based on the setting Number of characters to log for incoming requests setting below.
                                                                  • Number of characters to log for incoming POST requests: In more verbose logging levels, GeoServer will log the body of incoming requests. It will only log the initial part of the request though, since it has to store (buffer) everything that gets logged for use in the parts of GeoServer that use it normally. This setting sets the size of this buffer, in characters. A setting of 0 will disable logging the body of the request.
                                                                  • Log Request Headers: Select to enable logging of request header information.

                                                                  We recommend leaving these settings disabled in day to day operations. For more information on applying these settings and their use in troubleshooting see troubleshooting.

                                                                  "},{"location":"configuration/globalsettings/#catalog-settings","title":"Catalog Settings","text":""},{"location":"configuration/globalsettings/#config_globalsettings_type_cache","title":"Feature type cache size","text":"

                                                                  GeoServer can cache datastore connections and schemas in memory for performance reasons. The cache size should generally be greater than the number of distinct featuretypes that are expected to be accessed simultaneously. If possible, make this value larger than the total number of featuretypes on the server, but a setting too high may produce out-of-memory errors. On the other hand, a value lower than the total number of your registered featuretypes may clear and reload the resource-cache more often, which can be expensive and e.g. delay WFS-Requests in the meantime. The default value for the Feature type cache size is 100.

                                                                  "},{"location":"configuration/globalsettings/#config_globalsettings_locking","title":"File Locking","text":"

                                                                  This configuration settings allows control of the type of file locking used when accessing the GeoServer Data Directory. This setting is used to protect the GeoServer configuration from being corrupted by multiple parties editing simultaneously. File locking should be employed when using the REST API to configure GeoServer, and can protected GeoServer when more than one administrator is making changes concurrently.

                                                                  There are three options:

                                                                  • NIO File locking: Uses Java New IO File Locks suitable for use in a clustered environment (with multiple GeoServers sharing the same data directory).
                                                                  • In-process locking: Used to ensure individual configuration files cannot be modified by two web administration or REST sessions at the same time.
                                                                  • Disable Locking: No file locking is used.
                                                                  "},{"location":"configuration/globalsettings/#webui-settings","title":"WebUI Settings","text":""},{"location":"configuration/globalsettings/#config_globalsettings_webui","title":"WebUI Mode","text":"

                                                                  This configuration setting allows control over WebUI redirecting behaviour. By default, when the user loads a page that contains input, a HTTP 302 Redirect response is returned that causes a reload of that same with a generated session ID in the request parameter. This session ID allows the state of the page to be remembered after a refresh and prevents any occurrence of the 'double submit problem'. However, this behaviour is incompatible with clustering of multiple geoserver instances.

                                                                  There are three options:

                                                                  • DEFAULT: Use redirecting unless a clustering module has been loaded.
                                                                  • REDIRECT: Always use redirecting (incompatible with clustering).
                                                                  • DO_NOT_REDIRECT: Never use redirecting (does not remember state when reloading a page and may cause double submit).

                                                                  Note that a restart of GeoServer is necessary for a change in the setting to have effect.

                                                                  "},{"location":"configuration/globalsettings/#other-settings","title":"Other Settings","text":"

                                                                  Additional settings for GeoServer:

                                                                  "},{"location":"configuration/globalsettings/#other-settings_1","title":"Other settings","text":""},{"location":"configuration/globalsettings/#config_globalsettings_rest_notfound","title":"REST Disable Resource not found Logging","text":"

                                                                  This parameter can be used to mute exception logging when doing REST operations and the requested Resource is not present. This default setting can be overridden by adding to a REST call the following parameter: quietOnNotFound=true/false.

                                                                  "},{"location":"configuration/globalsettings/#config_globalsettings_rest_root_dir","title":"REST PathMapper Root directory path","text":"

                                                                  This parameter is used by the RESTful API as the Root Directory for the newly uploaded files, following the structure:

                                                                  ${rootDirectory}/workspace/store[/<file>]\n
                                                                  "},{"location":"configuration/globalsettings/#config_globalsettings_display_creation","title":"Display creation timestamps on administration lists","text":"

                                                                  These check boxes can be used to toggle Date of Creation on Workspaces, Stores, Layers, Layer Groups and Styles administration list pages.

                                                                  Time of Creation can be seen by hovering the mouse cursor over the dates.

                                                                  "},{"location":"configuration/globalsettings/#config_globalsettings_display_modify","title":"Display modification timestamps on administration lists","text":"

                                                                  These check boxes can be used to toggle Date of Modification on Workspaces, Stores, Layers, Layer Groups and Styles administration list pages.

                                                                  Time of Modification can be seen by hovering the mouse cursor over the dates.

                                                                  "},{"location":"configuration/globalsettings/#match-urls-with-trailing-slash","title":"Match URLs with trailing slash","text":"

                                                                  This setting determine whether GeoServer matches URLs whether or not the request has a trailing slash. If enabled a request mapped to \"/ogc/collections\" also matches \"/ogc/collections/\". A restart is required for a change to this setting to take effect.

                                                                  Note that trailing slash matches may be removed entirely in future versions of GeoServer due to introduced ambiguities that can lead to security vulnerabilities. Discussion of the issue can be found in this Spring issue.

                                                                  "},{"location":"configuration/logging/","title":"Advanced log configuration","text":"

                                                                  GeoServer uses the Log4J framework for logging, which is configured by selecting a logging profile (in the global settings).

                                                                  The GeoServer logging profiles assign logging levels to specific server operations:

                                                                  • GeoServer loggers record server function and the activity of individual services.
                                                                  • GeoWebCache loggers record the activity of the tile protocol library used by GeoServer.
                                                                  • GeoTools loggers record the activity of the data access and rendering library used by GeoServer.
                                                                  • The appender stdout is setup as a Console appender sending information to standard output, based on Log to Stdout global settings.
                                                                  • The appender geoserverlogfile is setup as a FileAppender or RollingFile appender sending information to the Log location global settings.
                                                                  • Logging levels range from:
                                                                    • Failure (FATAL, ERROR, WARN) levels
                                                                    • Operational (INFO, CONFIG) levels
                                                                    • Verbose (DEBUG, TRACE, FINEST) levels

                                                                  In addition to the built-in profiles you may setup a custom logging profile, or override the logging configuration completely (even to use another logging library altogether).

                                                                  "},{"location":"configuration/logging/#built-in-logging-profiles","title":"Built-in logging profiles","text":"

                                                                  GeoServer includes several built-in logging profiles:

                                                                  • DEFAULT_LOGGING
                                                                  • GEOSERVER_DEVELOPER_LOGGING
                                                                  • GEOTOOLS_DEVELOPER_LOGGING
                                                                  • PRODUCTION_LOGGING
                                                                  • QUIET_LOGGING
                                                                  • VERBOSE_LOGGING

                                                                  The built-in logging profiles are installed into your data directory the first time the application is run. If you have customized (see the next section) these files and wish to restore the original contents:

                                                                  • Use the startup parameter -DUPDATE_BUILT_IN_LOGGING_PROFILES=true, the built-in logging profiles will be checked and updated if required; or
                                                                  • Delete the file and restart GeoServer, the missing file will be restored; or
                                                                  • Copy the contents from the download links above

                                                                  For a description of these logging profiles see Logging Profile. Additional built-in logging profiles are supplied by installed extensions (example IMPORTER_LOGGING profile is built into the importer extension).

                                                                  "},{"location":"configuration/logging/#custom-logging-profiles","title":"Custom logging profiles","text":"

                                                                  Anyone can write a new logging profile by adding a Log4J configuration file to the list of files already available in the $GEOSERVER_DATA_DIR/logs folder.

                                                                  Profiles in this folder that match *_LOGGING.* will be listed on the global settings page as available for use. The name of the file, excluding the extension, will be presented as the profile name.

                                                                  Here is an example, taken from the DEFAULT_LOGGING.xml configuration, which enables additional GeoServer log messages to be included in the logs:

                                                                  <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<!-- This log4j configuration file needs to stay here, and is used as the default logging setup -->\n<!-- during data_dir upgrades and in case the chosen logging config isn't available.            -->\n<Configuration name=\"DEFAULT_LOGGING\" status=\"fatal\" dest=\"out\">\n    <Appenders>\n        <Console name=\"stdout\" target=\"SYSTEM_OUT\">\n            <PatternLayout pattern=\"%date{dd MMM HH:mm:ss} %-6level [%logger{2}] - %msg%n%throwable{filters(org.junit,org.apache.maven,sun.reflect,java.lang.reflect)}\"/>\n        </Console>\n        <RollingFile name=\"geoserverlogfile\">\n            <filename>logs/geoserver.log</filename>\n            <filePattern>logs/geoserver-%i.log</filePattern>\n            <PatternLayout pattern=\"%date{dd MMM HH:mm:ss} %-6level [%logger{2}] - %msg%n%throwable{filters(org.junit,org.apache.maven,sun.reflect,java.lang.reflect)}\"/>\n            <Policies>\n                <SizeBasedTriggeringPolicy size=\"20 MB\" />\n            </Policies>\n            <DefaultRolloverStrategy max=\"3\" fileIndex=\"min\"/>\n        </RollingFile>\n    </Appenders>\n    <Loggers>\n        <Logger name=\"org.geotools\" level=\"warn\" additivity=\"false\">\n            <AppenderRef ref=\"stdout\"/>\n            <AppenderRef ref=\"geoserverlogfile\"/>\n        </Logger>\n        <Logger name=\"org.geotools.factory\" level=\"warn\" additivity=\"false\">\n            <AppenderRef ref=\"stdout\"/>\n            <AppenderRef ref=\"geoserverlogfile\"/>\n        </Logger>\n        <Logger name=\"org.geoserver\" level=\"CONFIG\" additivity=\"false\">\n            <AppenderRef ref=\"stdout\"/>\n            <AppenderRef ref=\"geoserverlogfile\"/>\n        </Logger>\n        <Logger name=\"org.vfny.geoserver\" level=\"CONFIG\" additivity=\"false\">\n            <AppenderRef ref=\"stdout\"/>\n            <AppenderRef ref=\"geoserverlogfile\"/>\n        </Logger>\n\n        <Logger name=\"org.springframework\" level=\"warn\" additivity=\"false\">\n            <AppenderRef ref=\"stdout\"/>\n            <AppenderRef ref=\"geoserverlogfile\"/>\n        </Logger>\n\n        <Logger name=\"org.geowebcache\" level=\"CONFIG\" additivity=\"false\">\n            <AppenderRef ref=\"stdout\"/>\n            <AppenderRef ref=\"geoserverlogfile\"/>\n        </Logger>\n        <Logger name=\"org.geowebcache.seed\" level=\"warn\" additivity=\"false\">\n            <AppenderRef ref=\"stdout\"/>\n            <AppenderRef ref=\"geoserverlogfile\"/>\n        </Logger>\n        <Root level=\"warn\">\n            <AppenderRef ref=\"stdout\"/>\n            <AppenderRef ref=\"geoserverlogfile\"/>\n        </Root>\n    </Loggers>\n</Configuration>\n

                                                                  Any custom configuration can be setup to enable specific packages to emit logs at the desired logging level.

                                                                  There are however a few rules to follow:

                                                                  • Custom levels are available for CONFIG and FINEST levels.
                                                                  • Appenders are used to output logging information, with GeoServer providing external configuration for appenders named geoserverlogfile and stdout.

                                                                    • Always include a geoserverlogfile FileAppender or RollingFile appender that GeoServer will configure to work against the location configured in the global settings.

                                                                      Care is taken to preserve your file extension when updating <filename> location, so if you wish to log to access_logs.txt you may do so, and the txt extension will be preserved.

                                                                    • When setting geoserverlogfile appender as RollingFile appender, care is taken to preserve your <filePattern> extensions, which must align with the roll over strategies configured.

                                                                      As an example -%i is used with DefaultRolloverStrategy to produce a maximum of 3 backup files.

                                                                      <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<!-- This log4j configuration file needs to stay here, and is used as the default logging setup -->\n<!-- during data_dir upgrades and in case the chosen logging config isn't available.            -->\n<Configuration name=\"DEFAULT_LOGGING\" status=\"fatal\" dest=\"out\">\n    <Appenders>\n        <Console name=\"stdout\" target=\"SYSTEM_OUT\">\n            <PatternLayout pattern=\"%date{dd MMM HH:mm:ss} %-6level [%logger{2}] - %msg%n%throwable{filters(org.junit,org.apache.maven,sun.reflect,java.lang.reflect)}\"/>\n        </Console>\n        <RollingFile name=\"geoserverlogfile\">\n            <filename>logs/geoserver.log</filename>\n            <filePattern>logs/geoserver-%i.log</filePattern>\n            <PatternLayout pattern=\"%date{dd MMM HH:mm:ss} %-6level [%logger{2}] - %msg%n%throwable{filters(org.junit,org.apache.maven,sun.reflect,java.lang.reflect)}\"/>\n            <Policies>\n                <SizeBasedTriggeringPolicy size=\"20 MB\" />\n            </Policies>\n            <DefaultRolloverStrategy max=\"3\" fileIndex=\"min\"/>\n        </RollingFile>\n    </Appenders>\n    <Loggers>\n        <Logger name=\"org.geotools\" level=\"warn\" additivity=\"false\">\n            <AppenderRef ref=\"stdout\"/>\n            <AppenderRef ref=\"geoserverlogfile\"/>\n        </Logger>\n        <Logger name=\"org.geotools.factory\" level=\"warn\" additivity=\"false\">\n            <AppenderRef ref=\"stdout\"/>\n            <AppenderRef ref=\"geoserverlogfile\"/>\n        </Logger>\n        <Logger name=\"org.geoserver\" level=\"CONFIG\" additivity=\"false\">\n            <AppenderRef ref=\"stdout\"/>\n            <AppenderRef ref=\"geoserverlogfile\"/>\n        </Logger>\n        <Logger name=\"org.vfny.geoserver\" level=\"CONFIG\" additivity=\"false\">\n            <AppenderRef ref=\"stdout\"/>\n            <AppenderRef ref=\"geoserverlogfile\"/>\n        </Logger>\n\n        <Logger name=\"org.springframework\" level=\"warn\" additivity=\"false\">\n            <AppenderRef ref=\"stdout\"/>\n            <AppenderRef ref=\"geoserverlogfile\"/>\n        </Logger>\n\n        <Logger name=\"org.geowebcache\" level=\"CONFIG\" additivity=\"false\">\n            <AppenderRef ref=\"stdout\"/>\n            <AppenderRef ref=\"geoserverlogfile\"/>\n        </Logger>\n        <Logger name=\"org.geowebcache.seed\" level=\"warn\" additivity=\"false\">\n            <AppenderRef ref=\"stdout\"/>\n            <AppenderRef ref=\"geoserverlogfile\"/>\n        </Logger>\n        <Root level=\"warn\">\n            <AppenderRef ref=\"stdout\"/>\n            <AppenderRef ref=\"geoserverlogfile\"/>\n        </Root>\n    </Loggers>\n</Configuration>\n
                                                                    • a Console appender writing to the standard output should be called stdout and again GeoServer will enable/disable it according to the configuration set in the global settings

                                                                      <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<!-- This log4j configuration file needs to stay here, and is used as the default logging setup -->\n<!-- during data_dir upgrades and in case the chosen logging config isn't available.            -->\n<Configuration name=\"DEFAULT_LOGGING\" status=\"fatal\" dest=\"out\">\n    <Appenders>\n        <Console name=\"stdout\" target=\"SYSTEM_OUT\">\n            <PatternLayout pattern=\"%date{dd MMM HH:mm:ss} %-6level [%logger{2}] - %msg%n%throwable{filters(org.junit,org.apache.maven,sun.reflect,java.lang.reflect)}\"/>\n        </Console>\n        <RollingFile name=\"geoserverlogfile\">\n            <filename>logs/geoserver.log</filename>\n            <filePattern>logs/geoserver-%i.log</filePattern>\n            <PatternLayout pattern=\"%date{dd MMM HH:mm:ss} %-6level [%logger{2}] - %msg%n%throwable{filters(org.junit,org.apache.maven,sun.reflect,java.lang.reflect)}\"/>\n            <Policies>\n                <SizeBasedTriggeringPolicy size=\"20 MB\" />\n            </Policies>\n            <DefaultRolloverStrategy max=\"3\" fileIndex=\"min\"/>\n        </RollingFile>\n    </Appenders>\n    <Loggers>\n        <Logger name=\"org.geotools\" level=\"warn\" additivity=\"false\">\n            <AppenderRef ref=\"stdout\"/>\n            <AppenderRef ref=\"geoserverlogfile\"/>\n        </Logger>\n        <Logger name=\"org.geotools.factory\" level=\"warn\" additivity=\"false\">\n            <AppenderRef ref=\"stdout\"/>\n            <AppenderRef ref=\"geoserverlogfile\"/>\n        </Logger>\n        <Logger name=\"org.geoserver\" level=\"CONFIG\" additivity=\"false\">\n            <AppenderRef ref=\"stdout\"/>\n            <AppenderRef ref=\"geoserverlogfile\"/>\n        </Logger>\n        <Logger name=\"org.vfny.geoserver\" level=\"CONFIG\" additivity=\"false\">\n            <AppenderRef ref=\"stdout\"/>\n            <AppenderRef ref=\"geoserverlogfile\"/>\n        </Logger>\n\n        <Logger name=\"org.springframework\" level=\"warn\" additivity=\"false\">\n            <AppenderRef ref=\"stdout\"/>\n            <AppenderRef ref=\"geoserverlogfile\"/>\n        </Logger>\n\n        <Logger name=\"org.geowebcache\" level=\"CONFIG\" additivity=\"false\">\n            <AppenderRef ref=\"stdout\"/>\n            <AppenderRef ref=\"geoserverlogfile\"/>\n        </Logger>\n        <Logger name=\"org.geowebcache.seed\" level=\"warn\" additivity=\"false\">\n            <AppenderRef ref=\"stdout\"/>\n            <AppenderRef ref=\"geoserverlogfile\"/>\n        </Logger>\n        <Root level=\"warn\">\n            <AppenderRef ref=\"stdout\"/>\n            <AppenderRef ref=\"geoserverlogfile\"/>\n        </Root>\n    </Loggers>\n</Configuration>\n
                                                                      - Loggers are used to collect messages from geoserver components, and individual libraries used. - GeoServer Logger names match up with the package names in the project javadocs overview (available for download).

                                                                      As an example package org.geoserver.wms is listed, allowing level of WMS service logging to be controlled:

                                                                      <Logger name=\"org.geoserver.wms\" level=\"debug\" additivity=\"false\">\n    <AppenderRef ref=\"stdout\"/>\n    <AppenderRef ref=\"geoserverlogfile\"/>\n</Logger>\n
                                                                    • GeoTools Logger names match up with the package names in the project javadocs overview.

                                                                      As an example package org.geotools.data.shapefile is listed, allowing level of shapefile logging to be controlled:

                                                                      <Logger name=\"org.geotools.data.shapefile\" level=\"debug\" additivity=\"false\">\n    <AppenderRef ref=\"stdout\"/>\n    <AppenderRef ref=\"geoserverlogfile\"/>\n</Logger>\n
                                                                    • Assign a level to each logger indicating the level of detail you wish to record:

                                                                      Level Description OFF Turn off all logging FATAL A serious problem has occurred, application may be crashing or in need of restart ERROR Problem has occurred, application unable to perform requested operation WARN Potential problem, application will try and continue INFO Normal function indicating what application is doing. CONFIG Normal application function during application startup and configuration DEBUG Internal messages intended for debugging TRACE Metod by method tracing of execution FINEST Really detailed troubleshooting of an algorithm ALL Turn on all logging

                                                                      The more verbose logging levels potentially include a stack-trace showing where the message occurred.

                                                                    • Use additivity=\"false\" to prevent a message collected from one logger from being passed to the next.

                                                                      If you end up with double log messages chances check for this common misconfiguration.

                                                                    • The Root logger is last in the list and should collect everything.

                                                                  "},{"location":"configuration/logging/#example-of-console-only-logging","title":"Example of console only logging","text":"

                                                                  Copy built-in logging profile and customize:

                                                                  1. Copy an example such as QUIET_LOGGING.xml to CONSOLE_LOGGING.xml:

                                                                  2. Update the initial part of CONSOLE_LOGGING.xml with the new name:

                                                                    <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<Configuration name=\"CONSOLE_LOGGING\" status=\"fatal\" dest=\"out\">\n
                                                                  3. Double check the Console appender configuration:

                                                                    <Appenders>\n    <Console name=\"stdout\" target=\"SYSTEM_OUT\">\n        <PatternLayout pattern=\"%date{dd mmm HH:mm:ss} %-6level [%logger{2}] - %msg%n%\"/>\n    </Console>\n</Appenders>\n
                                                                  4. Add appenders for geoserver (and any others you wish to track):

                                                                    <Logger name=\"org.geoserver\" level=\"ERROR\" additivity=\"false\">\n    <AppenderRef ref=\"stdout\"/>\n</Logger>\n<Logger name=\"org.vfny.geoserver\" level=\"ERROR\" additivity=\"false\">\n    <AppenderRef ref=\"stdout\"/>\n</Logger>\n
                                                                  5. Double check the root logger:

                                                                    <Root level=\"FATAL\">\n    <AppenderRef ref=\"stdout\"/>\n</Root>\n
                                                                  6. This result provides minimal feedback to the console, only reporting when GeoServer encounters an error.

                                                                  "},{"location":"configuration/logging/#overriding-the-log-location-setup-in-the-geoserver-configuration","title":"Overriding the log location setup in the GeoServer configuration","text":"

                                                                  When setting up a cluster of GeoServer machines it is common to share a single data directory among all the cluster nodes.

                                                                  There is however a gotcha, all nodes would end up writing the logs in the same file, which would cause various kinds of troubles depending on the operating system file locking rules (a single server might be able to write, or all together in an uncontrolled manner resulting in an unreadable log file).

                                                                  A common choice could be to use the machine name as a distinction, setting values such as logs/geoserver_node1.log, logs/geoserver_node2.log and so on: in this case all the log files would still be contained in the data directory and properly rotated, but each server would have its own separate log file to write on.

                                                                  In this case it is convenient to set a separate log location for each GeoServer node:

                                                                  • The GEOSERVER_LOG_LOCATION parameter can be set as system property, environment variables, or servlet context parameters:

                                                                    GEOSERVER_LOG_LOCATION=<the location of the file>\n

                                                                    This setting overrides global setting, and is applied to geoserverlogfile appender as a template for filename and filePattern.

                                                                  • This same effect may be obtained using Log4J property substitution, where a wide range of property lookups are available.

                                                                    <RollingFile name=\"geoserverlogfile\">\n    <filename>logs/geoserver-${hostName}.log</filename>\n    <filePattern>logs/geoserver-${hostName}-%d{yyyy-MM-dd-HH}-%i.zip</filePattern>\n    <PatternLayout pattern=\"%date{dd mmm HH:mm:ss} %-6level [%logger{2}] - %msg%n\"/>\n    <Policies>\n      <OnStartupTriggeringPolicy />\n      <SizeBasedTriggeringPolicy size=\"20 MB\" />\n      <TimeBasedTriggeringPolicy />\n    </Policies>\n    <DefaultRolloverStrategy max=\"9\" fileIndex=\"min\"/>\n</RollingFile>\n

                                                                    Where ${hostName} is the current system host name or ip address.

                                                                  "},{"location":"configuration/logging/#forcing-geoserver-to-relinquish-log4j-control","title":"Forcing GeoServer to relinquish Log4J control","text":"

                                                                  GeoServer internally overrides the Log4J configuration by using the current logging configuration as a template and applying the log location and standard output settings configured by the administrator.

                                                                  If you wish GeoServer not to override the normal Log4J behavior you can set the following parameter among the JVM system variables, environment variables, or servlet context parameters:

                                                                  RELINQUISH_LOG4J_CONTROL=true\n

                                                                  This can be combined with log4j2.configurationFile system property to configure Log4J externally :

                                                                  -DRELINQUISH_LOG4J_CONTROL=true -Dlog4j2.configurationFile=logging_configuration.xml\n
                                                                  "},{"location":"configuration/logging/#forcing-geoserver-to-use-an-alternate-logging-redirection","title":"Forcing GeoServer to use an alternate logging redirection","text":"

                                                                  GeoServer uses the GeoTools logging framework, which in turn is based on Java Logging, but allowing to redirect all messages to an alternate framework of the user's choice.

                                                                  By default GeoServer setups a Log4J redirection, but it is possible to configure GeoServer to use plain Java Logging, or Commons Logging instead (support for other loggers is also possible by using some extra programming).

                                                                  If you wish to force GeoServer to use a different logging mechanism set the following parameters among the JVM system variables, environment variables, or servlet context parameters:

                                                                  GT2_LOGGING_REDIRECTION=[CommonsLogging,JavaLogging,Log4J,Log4J2,LogBack]\nRELINQUISH_LOG4J_CONTROL=true\n

                                                                  As noted in the example you'll also have to demand that GeoServer does not exert control over the Log4J configuration.

                                                                  "},{"location":"configuration/logging/#force-java-logging-example","title":"Force java logging example","text":"

                                                                  As an example to configure java logging:

                                                                  -DRELINQUISH_LOG4J_CONTROL=true -DGT2_LOGGING_REDIRECTION=JavaLogging -Djava.util.logging.config.file=logging.properties\n

                                                                  With java util logging configuration provided by logging.properties:

                                                                  handlers=java.util.logging.ConsoleHandler\n\njava.util.logging.ConsoleHandler.level = ALL\njava.util.logging.ConsoleHandler.formatter = org.geotools.util.logging.MonolineFormatter\norg.geotools.util.logging.MonolineFormatter.source = class:short\n\n.level= ALL\norg.geoserver.level = CONFIG\norg.vfny.geoserver.level = WARN\n\norg.geotools.level = WARN\norg.geotools.factory.level = WARN\n
                                                                  "},{"location":"configuration/raster_access/","title":"Raster Access","text":"

                                                                  The Coverage Access Settings page in the Server menu in the Web administration interface provides configuration options to customize thread pool executors and ImageIO caching memory.

                                                                  Raster Access Settings

                                                                  "},{"location":"configuration/raster_access/#ImageIO_settings","title":"Memory Use","text":"

                                                                  WMS requests usually produce relatively small images whilst WCS requests may frequently deal with bigger datasets. Caching the image in memory before encoding it may be helpful when the size of the image isn't too big. For a huge image (as one produced by a big WCS request) it would be better instead caching through a temporary file with respect to caching in memory. This section allows to specify a threshold image size to let GeoServer decide whether to use a MemoryCacheImageOutputStream or FileCacheImageOutputStream when encoding the images.

                                                                  ImageIO Cache Memory Threshold---Sets the threshold size (expressed in KiloBytes) which will make GeoServer choose between file cache vs memory based cache. If the estimated size of the image to be encoded is smaller than the threshold value, a MemoryCacheImageOutputStream will be used resulting into caching the image in memory. If the estimated size of the image to be encoded is greater than the threshold value, a FileCacheImageOutputStream will be used.

                                                                  "},{"location":"configuration/raster_access/#cpu-use","title":"CPU Use","text":"

                                                                  The imageMosaic reader may load, in parallel, different files that make up the mosaic by means of a ThreadPoolExecutor . A global ThreadPoolExecutor instance is shared by all the readers supporting and using concurrent reads. This section of the Coverage Access Settings administration page allows configuration of the Executor parameters.

                                                                  Core Pool Size---Sets the core pool size of the thread pool executor. A positive integer must be specified.

                                                                  Maximum Pool Size---Sets the maximum pool size of the thread pool executor. A positive integer must be specified.

                                                                  Keep Alive Time---Sets the time to be wait by the executor before terminating an idle thread in case there are more threads than corePoolSize.

                                                                  Queue Type---The executor service uses a BlockingQueue to manage submitted tasks. Using an unbounded queue is recommended which allows to queue all the pending requests with no limits (Unbounded). With a direct type, incoming requests will be rejected when there are already maximumPoolSize busy threads.

                                                                  Note

                                                                  If a new task is submitted to the list of tasks to be executed, and less than corePoolSize threads are running, a new thread is created to handle the request. Incoming tasks are queued in case corePoolSize or more threads are running.

                                                                  Note

                                                                  If a request can't be queued or there are less than corePoolSize threads running, a new thread is created unless this would exceed maximumPoolSize.

                                                                  Note

                                                                  If the pool currently has more than corePoolSize threads, excess threads will be terminated if they have been idle for more than the keepAliveTime.

                                                                  Note

                                                                  If a new task is submitted to the list of tasks to be executed and there are more than corePoolSize but less than maximumPoolSize threads running, a new thread will be created only if the queue is full. This means that when using an Unbounded queue, no more threads than corePoolSize will be running and keepAliveTime has no influence.

                                                                  Note

                                                                  If corePoolSize and maximumPoolSize are the same, a fixed-size thread pool is used.

                                                                  "},{"location":"configuration/raster_access/#system-properties-configuration","title":"System Properties Configuration","text":"

                                                                  There are some additional global configuration parameters involved in raster access which can be specified through System properties.

                                                                  "},{"location":"configuration/raster_access/#max-oversampling-factor","title":"Max Oversampling Factor","text":"

                                                                  When dealing with reprojection, the underlying raster read operation might do some oversampling in order to provide the requested output resolution. Depending on the reprojection and the requested area, the oversampling factor might be high.

                                                                  Consider an untiled whole world request of an EPSG:4326 raster, towards EPSG:3857, filling a 1024x768 image. Due to the big distortion introduced by the Mercator Projection at high latitudes, the underlying read operation may result in actually reading 20000x8000 pixels, in other words, an oversampling factor of almost 20. Image processing operations will work on that big input image before returning back the desired 1024x768 image.

                                                                  This can be very time consuming (you may notice long rendering time for that). It's possible to put a limit on the maximum oversampling factor by adding the following java option to GeoServer startup script and restart it:

                                                                  -Dorg.geotools.coverage.max.oversample=N

                                                                  With N a number representing the maximum oversampling factor. By this way, the underlying read operation will use a reading resolution within that limit, making the rendering faster. The speed gain has however a penalty, output quality decrease at the poles. So you may want to play a bit with this value to find the optimal trade-off between speed and quality. For example, you could start trying with a value of 3 and check the results, and then slowly increase it until the output matches the desired quality within an acceptable rendering time.

                                                                  "},{"location":"configuration/status/","title":"Status","text":"

                                                                  The Server Status page has two tabs to summarize the current status of GeoServer. The Status tab provides a summary of server configuration parameters and run-time status. The modules tab provides the status of the various modules installed on the server. This page provides a useful diagnostic tool in a testing environment.

                                                                  "},{"location":"configuration/status/#server-status","title":"Server Status","text":"

                                                                  Status Page (default tab)

                                                                  "},{"location":"configuration/status/#status-field-descriptions","title":"Status Field Descriptions","text":"

                                                                  The following table describes the current status indicators.

                                                                  +-----------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Option | Description | +=============================+======================================================================================================================================================================================================================================================================================================================================================================================================================+ | Data directory | Shows the path to the GeoServer data directory (GEOSERVER_DATA_DIR property). | +-----------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Locks | A WFS has the ability to lock features to prevent more than one person from updating the feature at one time. If data is locked, edits can be performed by a single WFS editor. When the edits are posted, the locks are released and features can be edited by other WFS editors. A zero in the locks field means all locks are released. If locks is non-zero then a client has reserved some content for editing. | | | | | | Press Free locks to release all feature locks currently held by the server and update the field value to zero. | +-----------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Connections | Refers to the numbers of stores GeoServer is connected to, in the above case 9, that are enabled and available. | +-----------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Memory Usage | The amount of memory currently used by GeoServer. In the above example, 174 MB of memory used out of a total of 3.56 GB available to Java. | | | | | | Press Free Memory to recycle unused memory by running the garbage collector. | +-----------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | JVM Version | Denotes which version of the JVM (Java Virtual Machine) is being used to power the server. Here the JVM is AdoptOpenJDK 1.8.0_282. | +-----------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Java Rendering Engine | Shows the rendering engine used for vector operations. | +-----------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Available Fonts | Shows the number of fonts available. Selecting the link will show the full list. | +-----------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Native JAI | GeoServer uses Java Advanced Imaging (JAI) framework for image rendering and coverage manipulation. | | | | | | We recommend the use of JAI-EXT operations for greater stability. | +-----------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Native JAI ImageIO | GeoServer uses JAI Image IO (JAI) framework for raster data loading and image encoding. | | | | | | We recommend use of libjpeg-turbo for those interested in increasing encoding performance. | +-----------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | JAI Maximum Memory | The amount of memory available for the image processing tile cache, in this case 1.78 GB. | +-----------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | JAI Memory Usage | Run-time amount of memory is used for the tile cache. | | | | | | Press Free Memory to clear available JAI memory by flushing the tile cache. | +-----------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | JAI Memory Threshold | Refers to the percentage, e.g. 75, of cache memory to retain during tile removal. | +-----------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Number of JAI Tile Threads | The number of parallel threads used by the scheduler to handle tiles. | +-----------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | JAI Tile Thread Priority | Schedules the global tile scheduler priority. The priority value defaults to 5, and must fall between 1 and 10. | +-----------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Thread Pool Core Pool Size | Number of threads that the ThreadPoolExecutor will create. This is underlying Java runtime functionality - see the Java documentation for ThreadPoolExecutor for more information. | +-----------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Thread Pool Max Pool Size | Maximum number of threads that the ThreadPoolExecutor will create. This is underlying Java runtime functionality - see the Java documentation for ThreadPoolExecutor for more information. | +-----------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Thread Pool Keep Alive Time | Timeout for threads to be terminated if they are idle and more than the core pool number exist. This is underlying Java runtime functionality - see the Java documentation for ThreadPoolExecutor for more information. | +-----------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Update Sequence | Refers to the number of times, e.g. 157, the server configuration has been modified. | +-----------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Resource cache | GeoServer maintains a resource cache with connections to stores, feature type definitions, external graphics, font definitions, and CRS definitions. This includes custom CRS definitions defined in data directory user_projections/epsg.properties. | | | | | | Press Clear to empty the resource cache. This will force GeoServer to reconnect to stores, reconnect to databases, re-read icon and font information, and reload custom CRS definitions. | +-----------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Configuration and catalog | GeoServer keeps its configuration data in memory. | | | | | | Press Reload to force GeoServer to reload all of its configuration from disk. This is useful if for any reason that configuration information has become stale (e.g., an external utility has modified the configuration on disk). | +-----------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+

                                                                  "},{"location":"configuration/status/#config_serverstatus_module","title":"Module Status","text":"

                                                                  The Modules tab provides a summary of the status of all installed modules in the running server.

                                                                  Module Status

                                                                  "},{"location":"configuration/status/#field-descriptions","title":"Field Descriptions","text":"

                                                                  +-----------------+----------------------------------------------------------------------------------------------------------------------+ | Module Name | Human readable name of the module, this links to a popup containing the full details and messages of the module | +=================+======================================================================================================================+ | Module ID | The internal package name of the module | +-----------------+----------------------------------------------------------------------------------------------------------------------+ | Available | Whether the module is available to GeoServer. | | | | | | A database extension requiring a third-party database driver to be installed would not be available for use. | +-----------------+----------------------------------------------------------------------------------------------------------------------+ | Enabled | Whether the module is enabled in the current GeoServer configuration | +-----------------+----------------------------------------------------------------------------------------------------------------------+ | Component | Functional component provided by the module. | +-----------------+----------------------------------------------------------------------------------------------------------------------+ | Version | The version of the installed module | +-----------------+----------------------------------------------------------------------------------------------------------------------+ | Message (popup) | Status message such as what Java rendering engine is in use, or the library path if the module/driver is unavailable | +-----------------+----------------------------------------------------------------------------------------------------------------------+

                                                                  Module Status popup

                                                                  "},{"location":"configuration/status/#config_serverstatus_system","title":"System Status","text":"

                                                                  The System Status tab provides extra information about the system environment GeoServer is running in. This provides an overview of the status of the GeoServer instance.

                                                                  System status

                                                                  This information is also available via the REST API to troubleshoot remote systems. The library OSHI is used to retrieve system-level information without depending on native libraries or DLLs, relying solely on Apache JNA. Major operating systems (Linux, Windows and MacOS) are supported out of the box.

                                                                  Use the checkbox Enable All Statistics to start and stop the collecting and displaying system status information. Disabling is useful if GeoServer is generating a high CPU load due to system status collection.

                                                                  The available system information is:

                                                                  Info Example Description Operating system Linux Mint 18 Name of the operating system and the used version Uptime 08:34:50 Up time of the system System average load 1 minute 0.90 System average load for the last minute System average load 5 minutes 1.12 System average load for the last five minute System average load 15 minute 0.68 System average load for the last fifteen minute Number of physical CPUs 4 Number of physical CPUs / cores available Number of logical CPUs 8 Number of logical CPUs / cores available Number of running process 316 Total number of process running in the system Number of running threads 1094 Total number of threads running in the system CPU load average 4.12 % Average load of the CPU in the last second CPU * load 11.43 % Load of a specific core in the last second Used physical memory 31.58 % Percentage of the system memory used Total physical memory 31.4 GiB System total memory Free physical memory 21.4 GiB System memory available for use Used swap memory 0.00% Percentage of swap memory used Total swap memory 32.0 GiB System total swap memory Free swap memory 32.0 GiB Free swap memory File system usage 65.47 % File system usage taking in account all partitions Partition * used space 54.8 % Percentage of space used in a specific partition Partition * total space 338.9 GiB Total space of a specific partition Partition * free space 117.0 GiB Free space on a specific partition Network interfaces send 42.0 MiB Data send through all the available network interfaces Network interfaces received 700.4 MiB Data received through all the available network interfaces Network interface * send 25.0 MiB Data send through a specific network interface Network interface * received 250.4 MiB Data received through a specific network interface CPU temperature 52.00 \u00baC CPU temperature CPU voltage 1.5 V CPU voltage GeoServer CPU usage 3.5 % Percentage of CPU used by GeoServer in the last second GeoServer threads 49 Number of threads created by GeoServer GeoServer JVM memory usage 5.83 % Percentage of the JVM memory used by GeoServer

                                                                  If some information is not available the special term NOT AVAILABLE will appear. Values will be automatically converted to best human readable unit.

                                                                  "},{"location":"configuration/status/#config_serverstatus_jvm","title":"JVM Console","text":"

                                                                  For information on the live Java Runtime Environment the JVM Console tab provides access to two useful troubleshooting tools.

                                                                  Press Thread Dump for a summary of all active threads. This is primarily used to troubleshoot performance issues and a non-responsive system. This can be used to identify when significant work is happening in the background, or if threads are stuck waiting on a resource.

                                                                  Thread Dump console output

                                                                  Press Heap Dump for an overview of memory use. This can be used to troubleshoot systems that are encountering a memory leak over time. .. code-block:: raw_markdown

                                                                  ! Heap Dump console output

                                                                  • Click Download link to download the JVM Console contents.

                                                                  For more information on effective use see Troubleshooting.

                                                                  "},{"location":"configuration/virtual-services/","title":"Virtual Services","text":"

                                                                  The different types of services in GeoServer include WFS, WMS, and WCS, commonly referred to as \"Open Web Services (OWS)\" services. These services are global in that each service publishes every layer configured on the server. WFS publishes all vector layer (feature types), WCS publishes all raster layers (coverages), and WMS publishes everything.

                                                                  A virtual service is a view of the global service that consists only of a subset of the layers. Virtual services are based on GeoServer workspaces. For each workspace that exists a virtual service exists along with it. The virtual service publishes only those layers that fall under the corresponding workspace.

                                                                  Warning

                                                                  Virtual services only apply to the core OWS services, and not OWS services accessed through GeoWebCache. It also does not apply to other subsystems such as REST.

                                                                  When a client accesses a virtual service that client only has access to those layers published by that virtual service. Access to layers in the global service via the virtual service will result in an exception. This makes virtual services ideal for compartmentalizing access to layers. A service provider may wish to create multiple services for different clients handing one service url to one client, and a different service url to another client. Virtual services allow the service provider to achieve this with a single GeoServer instance.

                                                                  "},{"location":"configuration/virtual-services/#filtering-by-workspace","title":"Filtering by workspace","text":"

                                                                  Consider the following snippets of the WFS capabilities document from the GeoServer release configuration that list all the feature types:

                                                                  http://localhost:8080/geoserver/wfs?request=GetCapabilities\n\n<wfs:WFS_Capabilities>\n\n  <FeatureType xmlns:tiger=\"http://www.census.gov\">\n   <Name>tiger:poly_landmarks</Name>\n--\n  <FeatureType xmlns:tiger=\"http://www.census.gov\">\n   <Name>tiger:poi</Name>\n--\n  <FeatureType xmlns:tiger=\"http://www.census.gov\">\n   <Name>tiger:tiger_roads</Name>\n--\n  <FeatureType xmlns:sf=\"http://www.openplans.org/spearfish\">\n   <Name>sf:archsites</Name>\n--\n  <FeatureType xmlns:sf=\"http://www.openplans.org/spearfish\">\n   <Name>sf:bugsites</Name>\n--\n  <FeatureType xmlns:sf=\"http://www.openplans.org/spearfish\">\n   <Name>sf:restricted</Name>\n--\n  <FeatureType xmlns:sf=\"http://www.openplans.org/spearfish\">\n   <Name>sf:roads</Name>\n--\n  <FeatureType xmlns:sf=\"http://www.openplans.org/spearfish\">\n   <Name>sf:streams</Name>\n--\n  <FeatureType xmlns:topp=\"http://www.openplans.org/topp\">\n   <Name>topp:tasmania_cities</Name>\n--\n  <FeatureType xmlns:topp=\"http://www.openplans.org/topp\">\n   <Name>topp:tasmania_roads</Name>\n--\n  <FeatureType xmlns:topp=\"http://www.openplans.org/topp\">\n   <Name>topp:tasmania_state_boundaries</Name>\n--\n  <FeatureType xmlns:topp=\"http://www.openplans.org/topp\">\n   <Name>topp:tasmania_water_bodies</Name>\n--\n  <FeatureType xmlns:topp=\"http://www.openplans.org/topp\">\n   <Name>topp:states</Name>\n--\n  <FeatureType xmlns:tiger=\"http://www.census.gov\">\n   <Name>tiger:giant_polygon</Name>\n\n</wfs:WFS_Capabilities>\n

                                                                  The above document lists every feature type configured on the server. Now consider the following capabilities request:

                                                                  http://localhost:8080/geoserver/topp/wfs?request=GetCapabilities\n

                                                                  The part of interest in the above request is the \"topp\" prefix to the wfs service. The above url results in the following feature types in the capabilities document:

                                                                  <wfs:WFS_Capabilities>\n\n   <FeatureType xmlns:topp=\"http://www.openplans.org/topp\">\n    <Name>topp:tasmania_cities</Name>\n --\n   <FeatureType xmlns:topp=\"http://www.openplans.org/topp\">\n    <Name>topp:tasmania_roads</Name>\n --\n   <FeatureType xmlns:topp=\"http://www.openplans.org/topp\">\n    <Name>topp:tasmania_state_boundaries</Name>\n --\n   <FeatureType xmlns:topp=\"http://www.openplans.org/topp\">\n    <Name>topp:tasmania_water_bodies</Name>\n --\n   <FeatureType xmlns:topp=\"http://www.openplans.org/topp\">\n    <Name>topp:states</Name>\n\n </wfs:WFS_Capabilities>\n

                                                                  The above feature types correspond to those configured on the server as part of the \"topp\" workspace.

                                                                  The consequence of a virtual service is not only limited to the capabilities document of the service. When a client accesses a virtual service it is restricted to only those layers for all operations. For instance, consider the following WFS feature request:

                                                                  http://localhost:8080/geoserver/topp/wfs?request=GetFeature&typename=tiger:roads\n

                                                                  The above request results in an exception. Since the request feature type \"tiger:roads\" is not in the \"topp\" workspace the client will receive an error stating that the requested feature type does not exist.

                                                                  "},{"location":"configuration/virtual-services/#filtering-by-layer","title":"Filtering by layer","text":"

                                                                  It is possible to further filter a global service by specifying the name of layer as part of the virtual service. For instance consider the following capabilities document:

                                                                  http://localhost:8080/geoserver/topp/states/wfs?request=GetCapabilities\n

                                                                  The part of interest is the \"states\" prefix to the wfs service. The above url results in the following capabilities document that contains a single feature type:

                                                                  <wfs:WFS_Capabilities>\n\n  <FeatureType xmlns:topp=\"http://www.openplans.org/topp\">\n   <Name>topp:states</Name>\n\n<wfs:WFS_Capabilities>\n
                                                                  "},{"location":"configuration/virtual-services/#global_services_off","title":"Turning off global services","text":"

                                                                  It is possible to completely restrict access to the global OWS services by setting a configuration flag. When global access is disabled OWS services may only occur through a virtual service. Any client that tries to access a service globally will receive an exception.

                                                                  To disable global services, log into the GeoServer web administration interface and navigate to \"Global Settings\". Uncheck the \"Enable Global Services\" check box.

                                                                  "},{"location":"configuration/virtual-services/#workspace_isolated","title":"Isolated Workspaces","text":"

                                                                  Isolated workspaces content is only visible and queryable in the context of a virtual service bound to the isolated workspace. This means that isolated workspaces content will not show up in global capabilities documents and global services cannot query isolated workspaces contents. Note that these restrictions do not apply to the REST API.

                                                                  A workspace can be made isolated by checking the Isolated Workspace checkbox when creating or editing a workspace.

                                                                  Making a workspace isolated

                                                                  An isolated workspace will be able to reuse a namespace already used by another workspace, but its resources (layers, styles, etc ...) can only be retrieved when using that workspace virtual services and will only show up in those virtual services capabilities documents.

                                                                  It is only possible to create two or more workspaces with the same namespace in GeoServer if only one of them is non isolated, i.e. isolated workspaces have no restrictions in namespaces usage but two non isolated workspaces can't use the same namespace.

                                                                  The following situation will be valid:

                                                                  • Prefix: st1 Namespace: http://www.stations.org/1.0 Isolated: false
                                                                  • Prefix: st2 Namespace: http://www.stations.org/1.0 Isolated: true
                                                                  • Prefix: st3 Namespace: http://www.stations.org/1.0 Isolated: true

                                                                  But not the following one:

                                                                  • Prefix: st1 Namespace: http://www.stations.org/1.0 Isolated: false
                                                                  • Prefix: st2 Namespace: http://www.stations.org/1.0 Isolated: false
                                                                  • Prefix: st3 Namespace: http://www.stations.org/1.0 Isolated: true

                                                                  At most only one non isolated workspace can use a certain namespace.

                                                                  Consider the following image which shows to workspaces (st1 and st2) that use the same namespace (http://www.stations.org/1.0) and several layers contained by them:

                                                                  Two workspaces using the same namespace, one of them is isolated.

                                                                  In the example above st2 is the isolated workspace. Consider the following WFS GetFeature requests:

                                                                  1. http://localhost:8080/geoserver/ows?service=WFS&version=2.0.0&request=DescribeFeatureType&typeName=layer2
                                                                  2. http://localhost:8080/geoserver/st2/ows?service=WFS&version=2.0.0&request=DescribeFeatureType&typeName=layer2
                                                                  3. http://localhost:8080/geoserver/ows?service=WFS&version=2.0.0&request=DescribeFeatureType&typeName=st1:layer2
                                                                  4. http://localhost:8080/geoserver/st2/ows?service=WFS&version=2.0.0&request=DescribeFeatureType&typeName=st2:layer2
                                                                  5. http://localhost:8080/geoserver/ows?service=WFS&version=2.0.0&request=DescribeFeatureType&typeName=st2:layer2
                                                                  6. http://localhost:8080/geoserver/ows?service=WFS&version=2.0.0&request=DescribeFeatureType&typeName=layer5

                                                                  The first request is targeting WFS global service and requesting layer2, this request will use layer2 contained by workspace st1. The second request is targeting st2 workspace WFS virtual service, layer2 belonging to workspace st2 will be used. Request three and four will use layer2 belonging to workspace, respectively, st1 and st2. The last two requests will fail saying that the feature type was not found, isolated workspaces content is not visible globally.

                                                                  The rule of thumb is that resources (layers, styles, etc ...) belonging to an isolated workspace can only be retrieved when using that workspaces virtual services and will only show up in those virtual services capabilities documents.

                                                                  "},{"location":"configuration/crshandling/","title":"Coordinate Reference System Handling","text":"

                                                                  This section describes how coordinate reference systems (CRS) are handled in GeoServer, as well as what can be done to extend GeoServer's CRS handling abilities.

                                                                  • Coordinate Reference System Configuration
                                                                  • Custom CRS Definitions
                                                                  • Coordinate Operations
                                                                  • Manually editing the EPSG database
                                                                  "},{"location":"configuration/crshandling/configurecrs/","title":"Coordinate Reference System Configuration","text":"

                                                                  When adding data, GeoServer tries to inspect data headers looking for an EPSG code:

                                                                  • If the data has a CRS with an explicit EPSG code and the full CRS definition behind the code matches the one in GeoServer, the CRS will be already set for the data.
                                                                  • If the data has a CRS but no EPSG code, you can use the Find option on the Layers page to make GeoServer perform a lookup operation where the data CRS is compared against every other known CRS. If this succeeds, an EPSG code will be selected. The common case for a CRS that has no EPSG code is shapefiles whose .PRJ file contains a valid WKT string without the EPSG identifiers (as these are optional).

                                                                  If an EPSG code cannot be found, then either the data has no CRS or it is unknown to GeoServer. In this case, there are a few options:

                                                                  • Force the declared CRS, ignoring the native one. This is the best solution if the native CRS is known to be wrong.
                                                                  • Reproject from the native to the declared CRS. This is the best solution if the native CRS is correct, but cannot be matched to an EPSG number. (An alternative is to add a custom EPSG code that matches exactly the native SRS. See the section on Custom CRS Definitions for more information.)

                                                                  If your data has no native CRS information, the only option is to specify/force an EPSG code.

                                                                  "},{"location":"configuration/crshandling/configurecrs/#increasing-comparison-tolerance","title":"Increasing Comparison Tolerance","text":"

                                                                  Decimal numbers comparisons are made using a comparison tolerance. This means, as an instance, that an ellipsoid's semi_major axis equals a candidate EPSG's ellipsoid semi_major axis only if their difference is within that tolerance. Default value is 10\\^-9 although it can be changed by setting a COMPARISON_TOLERANCE Java System property to your container's JVM to specify a different value.

                                                                  Warning

                                                                  The default value should be changed only if you are aware of use cases which require a wider tolerance. Don't change it unless really needed (See the following example).

                                                                  "},{"location":"configuration/crshandling/configurecrs/#example","title":"Example","text":"
                                                                  • Your sample dataset is known to be a LambertConformalConic projection and the related EPSG code defines latitude_of_origin value = 25.0.
                                                                  • The coverageStore plugin is exposing raster projection details through a third party library which provides projection parameter definitions as float numbers.
                                                                  • Due to the underlying math computations occurring in that third party library, the exposed projection parameters are subject to some accuracy loss, so that the provided latitude_of_origin is something like 25.0000012 whilst all the other params match the EPSG definition.
                                                                  • You notice that the native CRS isn't properly recognized as the expected EPSG due to that small difference in latitude_of_origin

                                                                  In that case you could consider increasing a bit the tolerance.

                                                                  "},{"location":"configuration/crshandling/coordtransforms/","title":"Coordinate Operations","text":"

                                                                  Coordinate operations are used to convert coordinates from a source CRS to a target CRS.

                                                                  If source and target CRSs are referred to a different datum, a datum transform has to be applied. Datum transforms are not exact, they are determined empirically. For the same pair of CRS, there can be many datum transforms and versions, each one with its own domain of validity and an associated transform error. Given a CRS pair, GeoServer will automatically pick the most accurate datum transform from the EPSG database, unless a custom operation is declared.

                                                                  • Coordinate operations can be queried and tested using the Reprojection Console.
                                                                  • To enable higher accuracy Grid Shift transforms, see Add Grid Shift Transform files.
                                                                  • See Define a custom Coordinate Operation to declare new operations. Custom operations will take precedence over the EPSG ones.
                                                                  "},{"location":"configuration/crshandling/coordtransforms/#reprojection-console","title":"Reprojection Console","text":"

                                                                  The reprojection console (available in Demos) lets you quickly test coordinate operations. Use it to convert a single coordinate or WKT geometry, and to see the operation details GeoServer is using. It is also useful to learn by example when you have to Define a custom Coordinate Operation.

                                                                  Read more about the Reprojection console.

                                                                  "},{"location":"configuration/crshandling/coordtransforms/#add-grid-shift-transform-files","title":"Add Grid Shift Transform files","text":"

                                                                  GeoServer supports NTv2 and NADCON grid shift transforms. Grid files are not shipped out with GeoServer. They need to be downloaded, usually from your National Mapping Agency website.

                                                                  Warning

                                                                  Grid Shift files are only valid in the specific geographic domain for which they where made; trying to transform coordinates outside this domain will result in no trasformation at all. Make sure that the Grid Shift files are valid in the area you want to transform.

                                                                  1. Search for the Grid File Name(s) int the tables below, which are extracted from EPSG version 7.9.0. If you need to use a Grid Shift transform not declared in EPSG, you will need to Define a custom Coordinate Operation.
                                                                  2. Get the Grid File(s) from your National Mapping Agency (NTv2) or the US National Geodetic Survey (NADCON).
                                                                  3. Copy the Grid File(s) in the user_projections directory inside your data directory.
                                                                  4. Use the Reprojection Console to test the new transform.
                                                                  "},{"location":"configuration/crshandling/coordtransforms/#list-of-available-grid-shift-transforms","title":"List of available Grid Shift transforms","text":"

                                                                  The list of Grid Shift transforms declared in EPSG version 7.9.0 is:

                                                                  "},{"location":"configuration/crshandling/coordtransforms/#ntv2","title":"NTv2","text":"Source CRS Target CRS Grid File Name Source Info 4122 4326 NB7783v2.gsb OGP 4122 4326 NS778301.gsb OGP 4122 4326 PE7783V2.gsb OGP 4122 4617 NB7783v2.gsb New Brunswick Geographic Information Corporation land and water information standards manual. 4122 4617 NS778301.gsb Nova Scotia Geomatics Centre - Contact aflemmin@linux1.nsgc.gov.ns.ca or telephone 902-667-6409 4122 4617 PE7783V2.gsb PEI Department of Transportation & Public Works 4149 4150 CHENyx06a.gsb Bundesamt f\u00fcr Landestopografie swisstopo; www.swisstopo.ch 4149 4151 CHENyx06_ETRS.gsb Bundesamt f\u00fcr Landestopografie swisstopo; www.swisstopo.ch 4149 4258 CHENyx06_ETRS.gsb Bundesamt f\u00fcr Landestopografie swisstopo; www.swisstopo.ch 4149 4326 CHENyx06_ETRS.gsb IOGP 4171 4275 rgf93_ntf.gsb ESRI 4202 4283 A66 National (13.09.01).gsb GDA Technical Manual. http://www.icsm.gov.au/gda 4202 4283 SEAust_21_06_00.gsb Office of Surveyor General Victoria; http://www.land.vic.gov.au/ 4202 4283 nt_0599.gsb GDA Technical Manual. http://www.icsm.gov.au/gda 4202 4283 tas_1098.gsb http://www.delm.tas.gov.au/osg/Geodetic_transform.htm 4202 4283 vic_0799.gsb Office of Surveyor General Victoria; http://www.land.vic.gov.au/ 4202 4326 A66 National (13.09.01).gsb OGP 4203 4283 National 84 (02.07.01).gsb GDA Technical Manual. http://www.icsm.gov.au/gda 4203 4283 wa_0700.gsb Department of Land Information, Government of Western Australia; http://www.dola.wa.gov.au/ 4203 4326 National 84 (02.07.01).gsb OGP 4207 4258 DLx_ETRS89_geo.gsb Instituto Geografico Portugues; http://www.igeo.pt 4225 4326 CA7072_003.gsb OGP 4225 4674 CA7072_003.gsb IBGE. 4230 4258 100800401.gsb Geodesy Unit, Cartographic Institute of Catalonia (ICC); http://www.icc.cat 4230 4258 SPED2ETV2.gsb Instituto Geogr\u00e1fico Nacional, www.cnig.es 4230 4326 SPED2ETV2.gsb OGP 4258 4275 rgf93_ntf.gsb OGP 4267 4269 NTv2_0.gsb http://www.geod.nrcan.gc.ca/products/html-public/GSDapps/English/NTv2_Fact_Sheet.html 4267 4269 QUE27-83.gsb Geodetic Service of Quebec. Contact alain.bernard@mrn.gouv.qc.ca 4267 4326 NTv2_0.gsb OGP 4267 4326 QUE27-98.gsb OGP 4267 4326 SK27-98.gsb OGP 4267 4617 NB2783v2.gsb \"Generation of a NAD27-NAD83(CSRS) NTv2-type Grid Shift File for New Brunswick\", Marcelo C. Santos and Carlos A. Garcia, Department of Geodesy and Geomatics Engineering, University of New Brunswick, October, 2011 via Service New Brunswick. 4267 4617 QUE27-98.gsb Geodetic Service of Quebec. Contact alain.bernard@mrn.gouv.qc.ca 4267 4617 SK27-98.gsb Dir Geodetic Surveys; SaskGeomatics Div.; Saskatchewan Property Management Company. 4269 4326 AB_CSRS.DAC OGP 4269 4326 NAD83-98.gsb OGP 4269 4326 SK83-98.gsb OGP 4269 4617 AB_CSRS.DAC Geodetic Control Section; Land and Forest Svc; Alberta Environment; http://www3.gov.ab.ca/env/land/dos/ 4269 4617 NAD83-98.gsb Geodetic Service of Quebec. Contact alain.bernard@mrn.gouv.qc.ca 4269 4617 SK83-98.gsb Dir Geodetic Surveys; SaskGeomatics Div.; Saskatchewan Property Management Company. 4272 4167 nzgd2kgrid0005.gsb Land Information New Zealand: LINZS25000 Standard for New Zealand Geodetic Datum 2000; 16 November 2007. 4272 4326 nzgd2kgrid0005.gsb OGP 4274 4258 D73_ETRS89_geo.gsb Instituto Geografico Portugues; http://www.igeo.pt 4277 4258 OSTN02_NTv2.gsb Ordnance Survey of Great Britain, http://www.gps.gov.uk 4277 4258 OSTN15_NTv2_OSGBtoETRS.gsb Ordnance Survey of Great Britain. 4277 4326 OSTN02_NTv2.gsb OGP 4277 4326 OSTN15_NTv2_OSGBtoETRS.gsb IOGP 4283 7844 COCOS_C_V1.gsb GDA2020 Technical Manual (http://www.icsm.gov.au) 4283 7844 GDA94_GDA2020_conformal.gsb GDA2020 Technical Manual and ICSM Datum Technical Fact Sheet TN1 (http://www.icsm.gov.au). 4283 7844 GDA94_GDA2020_conformal_and_distortion.gsb GDA2020 Technical Manual and ICSM Datum Technical Fact Sheet TN1 (http://www.icsm.gov.au). 4283 7844 XMAS_C_V1.gsb GDA2020 Technical Manual (http://www.icsm.gov.au). 4289 4258 rdtrans2008.gsb Kadaster and Rijkswaterstaat CIV, working together under the name RDNAP. 4300 4258 tm75_etrs89.gsb ESRI Ireland. 4300 4326 tm75_etrs89.gsb OGP 4301 4612 tky2jgd.gsb ESRI 4301 6668 tky2jgd.gsb OGP 4312 4258 AT_GIS_GRID.gsb Federal Office of Metrology and Surveying (BEV); http://www.bev.gv.at 4313 4258 bd72lb72_etrs89lb08.gsb IGN Brussels www.ngi.be 4314 4258 BETA2007.gsb BKG via EuroGeographics http://crs.bkg.bund.de/crs-eu/ 4314 4326 BETA2007.gsb OGP 4326 4275 rgf93_ntf.gsb OGP 4608 4269 May76v20.gsb Geodetic Survey of Canada http://www.geod.nrcan.gc.ca/ 4608 4326 May76v20.gsb OGP 4609 4269 CGQ77-83.gsb Geodetic Service of Quebec. Contact alain.bernard@mrn.gouv.qc.ca 4609 4326 CGQ77-98.gsb OGP 4609 4617 CGQ77-98.gsb Geodetic Service of Quebec. Contact alain.bernard@mrn.gouv.qc.ca 4612 6668 touhokutaiheiyouoki2011.gsb ESRI 4618 4326 SAD69_003.gsb OGP 4618 4674 SAD69_003.gsb IBGE. 4745 4258 NTv2_SN.gsb Saxony State Spatial Data and Land Survey Corporation (GeoSN). 4745 4326 BETA2007.gsb OGP 4746 4326 BETA2007.gsb OGP 4749 4644 RGNC1991_NEA74Noumea.gsb ESRI 4749 4662 RGNC1991_IGN72GrandeTerre.gsb ESRI 5524 4326 CA61_003.gsb OGP 5524 4674 CA61_003.gsb IBGE. 5527 4326 SAD96_003.gsb OGP 5527 4674 SAD96_003.gsb IBGE."},{"location":"configuration/crshandling/coordtransforms/#nadcon","title":"NADCON","text":"Source CRS Target CRS Version Latitude shift file Longitude shift file 4135 4269 NGS-Usa HI hawaii.las hawaii.los 4136 4269 NGS-Usa AK StL stlrnc.las stlrnc.los 4137 4269 NGS-Usa AK StP stpaul.las stpaul.los 4138 4269 NGS-Usa AK StG stgeorge.las stgeorge.los 4139 4269 NGS-PRVI prvi.las prvi.los 4169 4152 NGS-Asm E eshpgn.las eshpgn.los 4169 4152 NGS-Asm W wshpgn.las wshpgn.los 4267 4269 NGS-Usa AK alaska.las alaska.los 4267 4269 NGS-Usa Conus conus.las conus.los 4269 4152 NGS-Usa AL alhpgn.las alhpgn.los 4269 4152 NGS-Usa AR arhpgn.las arhpgn.los 4269 4152 NGS-Usa AZ azhpgn.las azhpgn.los 4269 4152 NGS-Usa CA n cnhpgn.las cnhpgn.los 4269 4152 NGS-Usa CO cohpgn.las cohpgn.los 4269 4152 NGS-Usa CA s cshpgn.las cshpgn.los 4269 4152 NGS-Usa ID MT e emhpgn.las emhpgn.los 4269 4152 NGS-Usa TX e ethpgn.las ethpgn.los 4269 4152 NGS-Usa FL flhpgn.las flhpgn.los 4269 4152 NGS-Usa GA gahpgn.las gahpgn.los 4269 4152 NGS-Usa HI hihpgn.las hihpgn.los 4269 4152 NGS-Usa IA iahpgn.las iahpgn.los 4269 4152 NGS-Usa IL ilhpgn.las ilhpgn.los 4269 4152 NGS-Usa IN inhpgn.las inhpgn.los 4269 4152 NGS-Usa KS kshpgn.las kshpgn.los 4269 4152 NGS-Usa KY kyhpgn.las kyhpgn.los 4269 4152 NGS-Usa LA lahpgn.las lahpgn.los 4269 4152 NGS-Usa DE MD mdhpgn.las mdhpgn.los 4269 4152 NGS-Usa ME mehpgn.las mehpgn.los 4269 4152 NGS-Usa MI mihpgn.las mihpgn.los 4269 4152 NGS-Usa MN mnhpgn.las mnhpgn.los 4269 4152 NGS-Usa MO mohpgn.las mohpgn.los 4269 4152 NGS-Usa MS mshpgn.las mshpgn.los 4269 4152 NGS-Usa NE nbhpgn.las nbhpgn.los 4269 4152 NGS-Usa NC nchpgn.las nchpgn.los 4269 4152 NGS-Usa ND ndhpgn.las ndhpgn.los 4269 4152 NGS-Usa NewEng nehpgn.las nehpgn.los 4269 4152 NGS-Usa NJ njhpgn.las njhpgn.los 4269 4152 NGS-Usa NM nmhpgn.las nmhpgn.los 4269 4152 NGS-Usa NV nvhpgn.las nvhpgn.los 4269 4152 NGS-Usa NY nyhpgn.las nyhpgn.los 4269 4152 NGS-Usa OH ohhpgn.las ohhpgn.los 4269 4152 NGS-Usa OK okhpgn.las okhpgn.los 4269 4152 NGS-Usa PA pahpgn.las pahpgn.los 4269 4152 NGS-PRVI pvhpgn.las pvhpgn.los 4269 4152 NGS-Usa SC schpgn.las schpgn.los 4269 4152 NGS-Usa SD sdhpgn.las sdhpgn.los 4269 4152 NGS-Usa TN tnhpgn.las tnhpgn.los 4269 4152 NGS-Usa UT uthpgn.las uthpgn.los 4269 4152 NGS-Usa VA vahpgn.las vahpgn.los 4269 4152 NGS-Usa WI wihpgn.las wihpgn.los 4269 4152 NGS-Usa ID MT w wmhpgn.las wmhpgn.los 4269 4152 NGS-Usa OR WA wohpgn.las wohpgn.los 4269 4152 NGS-Usa TX w wthpgn.las wthpgn.los 4269 4152 NGS-Usa WV wvhpgn.las wvhpgn.los 4269 4152 NGS-Usa WY wyhpgn.las wyhpgn.los 4675 4152 NGS-Gum guhpgn.las guhpgn.los 8351 4156 UGKK-Svk Slovakia_JTSK03_to_JTSK.LAS.las Slovakia_JTSK03_to_JTSK.LAS.los 8351 4156 UGKK-Svk Slovakia_JTSK03_to_JTSK.LOS.las Slovakia_JTSK03_to_JTSK.LOS.los"},{"location":"configuration/crshandling/coordtransforms/#define-a-custom-coordinate-operation","title":"Define a custom Coordinate Operation","text":"

                                                                  Custom Coordinate Operations are defined in epsg_operations.properties file. This file has to be placed into the user_projections directory, inside your data directory (create it if it doesn't exist).

                                                                  Each line in epsg_operations.properties will describe a coordinate operation consisting of a source CRS, a target CRS, and a math transform with its parameter values. Use the following syntax:

                                                                  <source crs code>,<target crs code>=<WKT math transform>\n

                                                                  Math transform is described in Well-Known Text syntax. Parameter names and value ranges are described in the EPSG Geodetic Parameter Registry.

                                                                  Note

                                                                  Use the Reprojection Console to learn from example and to test your custom definitions.

                                                                  "},{"location":"configuration/crshandling/coordtransforms/#examples","title":"Examples","text":"

                                                                  Custom NTv2 file:

                                                                  4230,4258=PARAM_MT[\"NTv2\", \\\n  PARAMETER[\"Latitude and longitude difference file\", \"100800401.gsb\"]]\n

                                                                  Geocentric transformation, preceded by an ellipsoid to geocentric conversion, and back geocentric to ellipsoid. The results is a concatenation of three math transforms:

                                                                  4230,4258=CONCAT_MT[ \\\n  PARAM_MT[\"Ellipsoid_To_Geocentric\", \\\n    PARAMETER[\"dim\", 2], \\\n    PARAMETER[\"semi_major\", 6378388.0], \\\n    PARAMETER[\"semi_minor\", 6356911.9461279465]], \\\n  PARAM_MT[\"Position Vector transformation (geog2D domain)\", \\\n    PARAMETER[\"dx\", -116.641], \\\n    PARAMETER[\"dy\", -56.931], \\\n    PARAMETER[\"dz\", -110.559], \\\n    PARAMETER[\"ex\", 0.8925078166311858], \\\n    PARAMETER[\"ey\", 0.9207660950870382], \\\n    PARAMETER[\"ez\", -0.9166407989620964], \\\n    PARAMETER[\"ppm\", -3.5200000000346066]], \\\n  PARAM_MT[\"Geocentric_To_Ellipsoid\", \\\n    PARAMETER[\"dim\", 2], \\\n    PARAMETER[\"semi_major\", 6378137.0], \\\n    PARAMETER[\"semi_minor\", 6356752.314140356]]]\n

                                                                  You can make use of existing grid shift files such as this explicit transformation from NAD27 to WGS84 made up of a NADCON transform from NAD27 to NAD83 followed by a Molodenski transform converting from the GRS80 Ellipsoid (used by NAD83) to the WGS84 Ellipsoid:

                                                                  4267,4326=CONCAT_MT[ \\\n  PARAM_MT[\"NADCON\", \\\n    PARAMETER[\"Latitude difference file\", \"conus.las\"], \\\n    PARAMETER[\"Longitude difference file\", \"conus.los\"]], \\\n  PARAM_MT[\"Molodenski\", \\\n    PARAMETER[\"dim\", 2], \\\n    PARAMETER[\"dx\", 0.0], \\\n    PARAMETER[\"dy\", 0.0], \\\n    PARAMETER[\"dz\", 0.0], \\\n    PARAMETER[\"src_semi_major\", 6378137.0], \\\n    PARAMETER[\"src_semi_minor\", 6356752.314140356], \\\n    PARAMETER[\"tgt_semi_major\", 6378137.0], \\\n    PARAMETER[\"tgt_semi_minor\", 6356752.314245179]]]\n

                                                                  Affine 2D transform operating directly in projected coordinates:

                                                                  23031,25831=PARAM_MT[\"Affine\", \\\n  PARAMETER[\"num_row\", 3], \\\n  PARAMETER[\"num_col\", 3], \\\n  PARAMETER[\"elt_0_0\", 1.0000015503712145], \\\n  PARAMETER[\"elt_0_1\", 0.00000758753979846734], \\\n  PARAMETER[\"elt_0_2\", -129.549], \\\n  PARAMETER[\"elt_1_0\", -0.00000758753979846734], \\\n  PARAMETER[\"elt_1_1\", 1.0000015503712145], \\\n  PARAMETER[\"elt_1_2\", -208.185]]\n

                                                                  Each operation can be described in a single line, or can be split in several lines for readability, adding a backslash \"\\\" at the end of each line, as in the former examples.

                                                                  "},{"location":"configuration/crshandling/customcrs/","title":"Custom CRS Definitions","text":""},{"location":"configuration/crshandling/customcrs/#add-a-custom-crs","title":"Add a custom CRS","text":"

                                                                  This example shows how to add a custom projection in GeoServer.

                                                                  1. The projection parameters need to be provided as a WKT (well known text) definition. The code sample below is just an example:

                                                                    PROJCS[\"NAD83 / Austin\",\n  GEOGCS[\"NAD83\",\n    DATUM[\"North_American_Datum_1983\",\n      SPHEROID[\"GRS 1980\", 6378137.0, 298.257222101],\n      TOWGS84[0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]],\n    PRIMEM[\"Greenwich\", 0.0],\n    UNIT[\"degree\", 0.017453292519943295],\n    AXIS[\"Lon\", EAST],\n    AXIS[\"Lat\", NORTH]],\n  PROJECTION[\"Lambert_Conformal_Conic_2SP\"],\n  PARAMETER[\"central_meridian\", -100.333333333333],\n  PARAMETER[\"latitude_of_origin\", 29.6666666666667],\n  PARAMETER[\"standard_parallel_1\", 31.883333333333297],\n  PARAMETER[\"false_easting\", 2296583.333333],\n  PARAMETER[\"false_northing\", 9842500.0],\n  PARAMETER[\"standard_parallel_2\", 30.1166666666667],\n  UNIT[\"m\", 1.0],\n  AXIS[\"x\", EAST],\n  AXIS[\"y\", NORTH],\n  AUTHORITY[\"EPSG\",\"100002\"]]\n

                                                                    Note

                                                                    This code sample has been formatted for readability. The information will need to be provided on a single line instead, or with backslash characters at the end of every line (except the last one).

                                                                  2. Go into the user_projections directory inside your data directory, and open the epsg.properties file. If this file doesn't exist, you can create it.

                                                                  3. Insert the code WKT for the projection at the end of the file (on a single line or with backslash characters):

                                                                    100002=PROJCS[\"NAD83 / Austin\", \\\n  GEOGCS[\"NAD83\", \\\n    DATUM[\"North_American_Datum_1983\", \\\n      SPHEROID[\"GRS 1980\", 6378137.0, 298.257222101], \\\n      TOWGS84[0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]], \\\n    PRIMEM[\"Greenwich\", 0.0], \\\n    UNIT[\"degree\", 0.017453292519943295], \\\n    AXIS[\"Lon\", EAST], \\\n    AXIS[\"Lat\", NORTH]], \\\n  PROJECTION[\"Lambert_Conformal_Conic_2SP\"], \\\n  PARAMETER[\"central_meridian\", -100.333333333333], \\\n  PARAMETER[\"latitude_of_origin\", 29.6666666666667], \\\n  PARAMETER[\"standard_parallel_1\", 31.883333333333297], \\\n  PARAMETER[\"false_easting\", 2296583.333333], \\\n  PARAMETER[\"false_northing\", 9842500.0], \\\n  PARAMETER[\"standard_parallel_2\", 30.1166666666667], \\\n  UNIT[\"m\", 1.0], \\\n  AXIS[\"x\", EAST], \\\n  AXIS[\"y\", NORTH], \\\n  AUTHORITY[\"EPSG\",\"100002\"]]\n

                                                                  Note

                                                                  Note the number that precedes the WKT. This will determine the EPSG code. So in this example, the EPSG code is 100002.

                                                                  1. Save the file.
                                                                  2. Restart GeoServer.
                                                                  3. Verify that the CRS has been properly parsed by navigating to the SRS List page in the Web administration interface.
                                                                  4. If the projection wasn't listed, examine the logs for any errors.
                                                                  "},{"location":"configuration/crshandling/customcrs/#override-an-official-epsg-code","title":"Override an official EPSG code","text":"

                                                                  In some situations it is necessary to override an official EPSG code with a custom definition. A common case is the need to change the TOWGS84 parameters in order to get better reprojection accuracy in specific areas.

                                                                  The GeoServer referencing subsystem checks the existence of another property file, epsg_overrides.properties, whose format is the same as epsg.properties. Any definition contained in epsg_overrides.properties will override the EPSG code, while definitions stored in epsg.proeprties can only add to the database.

                                                                  Special care must be taken when overriding the Datum parameters, in particular the TOWGS84 parameters. To make sure the override parameters are actually used the code of the Datum must be removed, otherwise the referencing subsystem will keep on reading the official database in search of the best Datum shift method (grid, 7 or 5 parameters transformation, plain affine transform).

                                                                  For example, if you need to override the official TOWGS84 parameters of EPSG:23031:

                                                                  PROJCS[\"ED50 / UTM zone 31N\", \n  GEOGCS[\"ED50\", \n    DATUM[\"European Datum 1950\", \n      SPHEROID[\"International 1924\", 6378388.0, 297.0, AUTHORITY[\"EPSG\",\"7022\"]], \n      TOWGS84[-157.89, -17.16, -78.41, 2.118, 2.697, -1.434, -1.1097046576093785],\n      AUTHORITY[\"EPSG\",\"6230\"]], \n    PRIMEM[\"Greenwich\", 0.0, AUTHORITY[\"EPSG\",\"8901\"]], \n    UNIT[\"degree\", 0.017453292519943295], \n    AXIS[\"Geodetic longitude\", EAST], \n    AXIS[\"Geodetic latitude\", NORTH], \n    AUTHORITY[\"EPSG\",\"4230\"]], \n PROJECTION[\"Transverse_Mercator\"], \n  PARAMETER[\"central_meridian\", 3.0], \n  PARAMETER[\"latitude_of_origin\", 0.0], \n  PARAMETER[\"scale_factor\", 0.9996], \n  PARAMETER[\"false_easting\", 500000.0], \n  PARAMETER[\"false_northing\", 0.0], \n  UNIT[\"m\", 1.0], \n  AXIS[\"Easting\", EAST], \n  AXIS[\"Northing\", NORTH], \n  AUTHORITY[\"EPSG\",\"23031\"]]\n

                                                                  You should write the following (in a single line, here it's reported formatted over multiple lines for readability):

                                                                  23031=\n PROJCS[\"ED50 / UTM zone 31N\", \n   GEOGCS[\"ED50\", \n     DATUM[\"European Datum 1950\", \n       SPHEROID[\"International 1924\", 6378388.0, 297.0, AUTHORITY[\"EPSG\",\"7022\"]], \n       TOWGS84[-136.65549, -141.4658, -167.29848, 2.093088, 0.001405, 0.107709, 11.54611], \n       AUTHORITY[\"EPSG\",\"6230\"]], \n     PRIMEM[\"Greenwich\", 0.0, AUTHORITY[\"EPSG\",\"8901\"]], \n     UNIT[\"degree\", 0.017453292519943295], \n     AXIS[\"Geodetic longitude\", EAST], \n     AXIS[\"Geodetic latitude\", NORTH]], \n  PROJECTION[\"Transverse_Mercator\"], \n   PARAMETER[\"central_meridian\", 3.0], \n   PARAMETER[\"latitude_of_origin\", 0.0], \n   PARAMETER[\"scale_factor\", 0.9996], \n   PARAMETER[\"false_easting\", 500000.0], \n   PARAMETER[\"false_northing\", 0.0], \n   UNIT[\"m\", 1.0], \n   AXIS[\"Easting\", EAST], \n   AXIS[\"Northing\", NORTH], \n   AUTHORITY[\"EPSG\",\"23031\"]]\n

                                                                  The definition has been changed in two places, the TOWGS84 paramerers, and the Datum code, AUTHORITY[\"EPSG\",\"4230\"], has been removed.

                                                                  "},{"location":"configuration/crshandling/manualepsg/","title":"Manually editing the EPSG database","text":"

                                                                  Warning

                                                                  These instructions are very advanced, and are here mainly for the curious who want to know details about the EPSG database subsystem.

                                                                  To define a custom projection, edit the EPSG.sql file, which is used to create the cached EPSG database.

                                                                  1. Navigate to the WEB-INF/lib directory

                                                                  2. Uncompress the gt2-epsg-h.jar file. On Linux, the command is:

                                                                    jar xvf gt2-epsg-h.jar\n
                                                                  3. Open org/geotools/referencing/factory/epsg/EPSG.sql with a text editor. To add a custom projection, these entries are essential:

                                                                    1. An entry in the EPSG_COORDINATEREFERENCESYSTEM table:

                                                                      (41111,'WGC 84 / WRF Lambert',1324,'projected',4400,NULL,4326,20000,NULL,NULL,'US Nat. scale mapping.','Entered by Alex Petkov','Missoula Firelab WRF','WRF','2000-10-19','',1,0),\n

                                                                      where:

                                                                      • 1324 is the EPSG_AREA code that describes the area covered by my projection
                                                                      • 4400 is the EPSG_COORDINATESYSTEM code for my projection
                                                                      • 20000 is the EPSG_COORDOPERATIONPARAMVALUE key for the array that contains my projection parameters
                                                                    2. An entry in the EPSG_COORDOPERATIONPARAMVALUE table:

                                                                      (20000,9802,8821,40,'',9102),    //latitude of origin\n(20000,9802,8822,-97.0,'',9102), //central meridian\n(20000,9802,8823,33,'',9110),    //st parallel 1\n(20000,9802,8824,45,'',9110),    //st parallel 2\n(20000,9802,8826,0.0,'',9001),   //false easting\n(20000,9802,8827,0.0,'',9001)    //false northing\n

                                                                      where:

                                                                      • 9802 is the EPSG_COORDOPERATIONMETHOD key for the Lambert Conic Conformal (2SP) formula
                                                                    3. An entry in the EPSG_COORDOPERATION table:

                                                                      (20000,'WRF Lambert','conversion',NULL,NULL,'',NULL,1324,'Used for weather forecasting.',0.0,9802,NULL,NULL,'Used with the WRF-Chem model for weather forecasting','Firelab in Missoula, MT','EPSG','2005-11-23','2005.01',1,0)

                                                                      where:

                                                                      • 1324 is the EPSG_AREA code that describes the area covered by my projection
                                                                      • 9802 is the EPSG_COORDOPERATIONMETHOD key for the Lambert Conic Conformal (2SP) formula

                                                                  Note

                                                                  Observe the commas. If you enter a line that is at the end of an INSERT statement, the comma is omitted (make sure the row before that has a comma at the end). Otherwise, add a comma at the end of your entry.

                                                                  1. After all edits, save the file and exit.

                                                                  2. Compress the gt2-epsg-h.jar file. On Linux, the command is:

                                                                    jar -Mcvf gt2-epsg-h.jar META-INF org\n
                                                                  3. Remove the cached copy of the EPSG database, so that can be recreated. On Linux, the command is:

                                                                    rm -rf /tmp/Geotools/Databases/HSQL\n
                                                                  4. Restart GeoServer.

                                                                  The new projection will be successfully parsed. Verify that the CRS has been properly parsed by navigating to the SRS List page in the Web administration interface.

                                                                  "},{"location":"configuration/demos/","title":"Demos","text":"

                                                                  This page contains helpful links to various information pages regarding GeoServer and its features. You do not need to be logged into GeoServer to access this page.

                                                                  The page contains the following options

                                                                  • Demo Requests
                                                                  • SRS List
                                                                  • Reprojection console
                                                                  • WCS Request Builder

                                                                  Demos page

                                                                  If you have the WPS extension installed, you will see an additional option:

                                                                  • WPS Request Builder

                                                                  Demos page with WPS extension installed

                                                                  "},{"location":"configuration/demos/#demos_demorequests","title":"Demo Requests","text":"

                                                                  This page has example WMS, WCS, and WFS requests for GeoServer that you can use, examine, and change. Select a request from the drop down list.

                                                                  Selecting demo requests

                                                                  Both Web Feature Service (WFS) as well as Web Coverage Service (WCS) requests will display the request URL and the XML body. Web Map Service (WMS) requests will only display the request URL.

                                                                  WFS 1.1 DescribeFeatureType sample request

                                                                  Click Submit to send the request to GeoServer. For WFS and WCS requests, GeoServer will automatically generate an XML response.

                                                                  XML response from a WFS 1.1 DescribeFeatureType sample request

                                                                  Submitting a WMS GetMap request displays an image based on the provided geographic data.

                                                                  OpenLayers WMS GetMap request

                                                                  WMS GetFeatureInfo requests retrieve information regarding a particular feature on the map image.

                                                                  WMS GetFeatureInfo request

                                                                  "},{"location":"configuration/demos/#srs_list","title":"SRS List","text":"

                                                                  GeoServer natively supports almost 4,000 Spatial Referencing Systems (SRS), also known as projections, and more can be added. A spatial reference system defines an ellipsoid, a datum using that ellipsoid, and either a geocentric, geographic or projection coordinate system. This page lists all SRS info known to GeoServer.

                                                                  Listing of all Spatial Referencing Systems (SRS) known to GeoServer

                                                                  The Code column refers to the unique integer identifier defined by the author of that spatial reference system. Each code is linked to a more detailed description page, accessed by clicking on that code.

                                                                  Details for SRS EPSG:2000

                                                                  The title of each SRS is composed of the author name and the unique integer identifier (code) defined by the Author. In the above example, the author is the European Petroleum Survey Group (EPSG) and the Code is 2000. The fields are as follows:

                                                                  Description---A short text description of the SRS

                                                                  WKT---A string describing the SRS. WKT stands for \"Well Known Text\"

                                                                  Area of Validity---The bounding box for the SRS

                                                                  "},{"location":"configuration/demos/#demos_reprojectionconsole","title":"Reprojection console","text":"

                                                                  The reprojection console allows you to calculate and test coordinate transformation. You can input a single coordinate or WKT geometry, and transform it from one CRS to another.

                                                                  For example, you can use the reprojection console to transform a bounding box (as a WKT polygon or line) between different CRSs.

                                                                  Reprojection console showing a transformed bounding box

                                                                  Use Forward transformation to convert from source CRS to target CRS, and Backward transformation to convert from target CRS to source CRS.

                                                                  You can also view the underlying calculation GeoServer is using to perform the transformation.

                                                                  Reprojection console showing operation details

                                                                  Read more about Coordinate Reference System Handling.

                                                                  "},{"location":"configuration/demos/#demos_wcsrequestbuilder","title":"WCS Request Builder","text":"

                                                                  The WCS Request Builder is a tool for generating and executing WCS requests. Since WCS requests can be cumbersome to author, this tool can make working with WCS much easier.

                                                                  Read more about the WCS Request Builder.

                                                                  "},{"location":"configuration/demos/#demos_wpsrequestbuilder","title":"WPS Request Builder","text":"

                                                                  GeoServer with the WPS extension installed includes a request builder for generating and executing WPS processes. Since WPS requests can be cumbersome to author, this tool can make working with WPS much easier.

                                                                  Read more about the WPS Request Builder.

                                                                  "},{"location":"configuration/image_processing/","title":"Image Processing","text":"

                                                                  Java Advanced Imaging (JAI) is an image processing library built by Sun Microsystems. JAI Image I/O Tools provides reader, writer, and stream plug-ins for the standard Java Image I/O Framework.

                                                                  Several JAI parameters, used by both WMS and WCS operations, can be configured in the Image Processing page.

                                                                  Image Processing

                                                                  "},{"location":"configuration/image_processing/#memory-tiling","title":"Memory & Tiling","text":"

                                                                  When supporting large images it is efficient to work on image subsets without loading everything to memory. A widely used approach is tiling which basically builds a tessellation of the original image so that image data can be read in parts rather than whole. Since very often processing one tile involves surrounding tiles, tiling needs to be accompanied by a tile-caching mechanism. The following JAI parameters allow you to manage the JAI cache mechanism for optimized performance.

                                                                  Memory Capacity---For memory allocation for tiles, JAI provides an interface called TileCache. Memory Capacity sets the global JAI TileCache as a percentage of the available heap. A number between 0 and 1 exclusive. If the Memory Capacity is smaller than the current capacity, the tiles in the cache are flushed to achieve the desired settings. If you set a large amount of memory for the tile cache, interactive operations are faster but the tile cache fills up very quickly. If you set a low amount of memory for the tile cache, the performance degrades.

                                                                  Memory Threshold---Sets the global JAI TileCache Memory threshold. Refers to the fractional amount of cache memory to retain during tile removal. JAI Memory Threshold value must be between 0.0 and 1.0. The Memory Threshold visible on the Status page.

                                                                  Tile Threads---JAI utilizes a TileScheduler for tile calculation. Tile computation may make use of multithreading for improved performance. The Tile Threads parameter sets the TileScheduler, indicating the number of threads to be used when loading tiles.

                                                                  Tile Threads Priority---Sets the global JAI Tile Scheduler thread priorities. Values range from 1 (Min) to 10 (Max), with default priority set to 5 (Normal).

                                                                  Tile Recycling---Enable/Disable JAI Cache Tile Recycling. If selected, Tile Recycling allows JAI to re-use already loaded tiles, which can provide significant performance improvement.

                                                                  Native Acceleration---To improve the computation speed of image processing applications, the JAI comes with both Java Code and native code for many platform. If the Java Virtual Machine (JVM) finds the native code, then that will be used. If the native code is not available, the Java code will be used. As such, the JAI package is able to provide optimized implementations for different platforms that can take advantage of each platform's capabilities.

                                                                  JPEG Native Acceleration---Enables/disable JAI JPEG Native Acceleration. When selected, enables JPEG native code, which may speed performance, but compromise security and crash protection.

                                                                  PNG Encoder Type---Provides a selection of the PNG encoder between the Java own encoder, the JAI ImageIO native one, and a PNGJ based one:

                                                                  • The Java standard encoder is always set to maximum compression. It provides the smallest output images, balanced by a high performance cost (up to six times slower than the other two alternatives).
                                                                  • The ImageIO native encoder, available only when the ImageIO native extensions are installed, provided higher performance, but also generated significantly larger PNG images
                                                                  • The PNGJ based encoder provides the best performance and generated PNG images that are just slightly larger than the Java standard encoder. It is the recommended choice, but it's also newer than the other two, so in case of misbehavior the other two encoders are left as an option for the administrator.

                                                                  Mosaic Native Acceleration---To reduce the overhead of handling them, large data sets are often split into smaller chunks and then combined to create an image mosaic. An example of this is aerial imagery which usually comprises thousands of small images at very high resolution. Both native and JAI implementations of mosaic are provided. When selected, Mosaic Native Acceleration use the native implementation for creating mosaics.

                                                                  Warp Native Acceleration---Also for the Warp operation are provided both native and JAI implementations. If the checkbox is enabled, then the native operation is used for the warp operation.

                                                                  It is quite important to remember that faster encoders are not necessarily going to visibly improve performance, if data loading and processing/rendering are dominating the response time, choosing a better encoder will likely not provide the expected benefits.

                                                                  "},{"location":"configuration/image_processing/#JAIEXT","title":"JAI-EXT","text":"

                                                                  The JAI-EXT library is open-source project which aims to replace closed source JAI project provided by Sun. The main difference between JAI and JAI-EXT operations is the support for external Region of Interests (ROI) and image NoData in JAI-EXT.

                                                                  The following panel is be available at the bottom of the JAI Settings page

                                                                  JAI/JAIEXT Setup panel

                                                                  This panel can be used to selectively enable/disable JAI-EXT operations in favor of JAI ones.

                                                                  By default, JAI-EXT operations are enabled. In case of misbehavior add the following java option to GeoServer startup script and restart GeoServer to disable them.

                                                                  -Dorg.geotools.coverage.jaiext.enabled=false

                                                                  Warning

                                                                  Users should take care that JAI native libraries are not supported by JAI-EXT, since JAI-EXT is a pure Java API.

                                                                  "},{"location":"configuration/internationalization/","title":"Internationalization (i18n)","text":"

                                                                  GeoServer supports returning a GetCapabilities document in various languages. The functionality is available for the following services:

                                                                  • WMS 1.1 and 1.3
                                                                  • WFS 2.0
                                                                  • WCS 2.0
                                                                  "},{"location":"configuration/internationalization/#configuration","title":"Configuration","text":"

                                                                  GeoServer provides an i18n editor for the title and abstract of:

                                                                  • Layers configuration page.
                                                                  • Layergroups configuration page.
                                                                  • WMS, WFS, WCS service configuration pages.
                                                                  • For Styles i18n configuration see i18N in SLD.

                                                                  The editor is disabled by default and can be enabled from the i18n checkbox:

                                                                  In the Contact Information page all the fields can be internationalized:

                                                                  "},{"location":"configuration/internationalization/#service-getcapabilities","title":"Service GetCapabilities","text":"

                                                                  The GetCapabilities document language can be selected using the AcceptLanguages request parameter. The GeoServer response will vary based on the following rules:

                                                                  • The internationalized elements will be titles, abstracts and keywords.

                                                                  • If a single language code is specified, e.g. AcceptLanguages=en GeoServer will try to return the content in that language.

                                                                    If no content is found in the requested language a ServiceExceptionReport will be returned.

                                                                  • If multiple language codes are specified, e.g. AcceptLanguages=en fr or AcceptLanguages=en,fr, for each internationalizable content GeoServer will try to return it in one of the specified language.

                                                                    If no content is found for any of the requested languages ServiceExceptionReport will be returned.

                                                                  • Languages can be configured and requested also according to local language variants (e.g. AcceptLanguages=en fr-CA or AcceptLanguages=en,fr-CA).

                                                                    If any i18n content has been specified with a local variant and the request parameters specifies only the language code the content will be encoded in the response. Keep in mind that the inverse situation content is recorded using a language code will not be available for local variant requests.

                                                                    Example: If the i18n content is specified with the local variant fr-CA and the requested only specifies a language code AcceptLanguages=fr` the local variantfr-CAcontent will be used. Example: If the i18n content is specified with the language codefrand the requested only specifies the local variantAcceptLanguages=fr-CAthe language codefr` content is unavailable.

                                                                  • If a * is present among the parameter values, e.g. AcceptLanguages=en fr * or AcceptLanguages=en,fr,*, GeoServer will try to return the content in one of the specified language code.

                                                                    If no content is found content will be returned in a language among those available.

                                                                  • If not all the configurable elements have i18n title and abstract available for the requested language, GeoServer will encode those attributes only for services, layers, layergroups and styles that have them defined.

                                                                    In case the missing value is the tile, in place of the missing internationalized content an error message like the following, will appear: DID NOT FIND i18n CONTENT FOR THIS ELEMENT.

                                                                  • When using AcceptLanguages parameter GeoServer will encode URL present in the response adding language parameter with the first value retrieved from the AcceptLanguages parameter.

                                                                  "},{"location":"configuration/internationalization/#default-language","title":"Default Language","text":"

                                                                  GeoServer allows defining a default language to be used when international content has been set in services', layers' and groups' configuration pages, but no AcceptLanguages parameter has been specified in a GetCapabilities request. The default language can be set from the services' configuration pages (WMS, WFS, WCS) or from global settings from a dropdown as shown below:

                                                                  It is also possible to set an i18n entry with empty language for each configurable field, acting as the default translation.

                                                                  When international content is requested, for each internationalized field, GeoServer will behave as follows:

                                                                  • The service specific default language, if present, will be used.
                                                                  • If not found, the global default language, if present, will be used.
                                                                  • If not found the i18n content empty language value, if present, will be used.
                                                                  • If not found the first i18n value found for the field will be used.
                                                                  "},{"location":"configuration/service-metadata/","title":"Service Metadata","text":"

                                                                  Open Web Services (WCS, WFS, WMS, and WPS) use common metadata definitions to describe the service offered and indicate any restrictions on use.

                                                                  WMS Service Metadata

                                                                  These elements are described in the following table. Though these field types are the same regardless of service, their values are not shared. As such, parameter definitions below refer to the respective service. For example, enable on the WFS Service page, enables WFS service requests and has no effect on WCS or WMS requests.

                                                                  Field Description Enabled Specifies whether the respective services --WCS, WFS or WMS-- should be enabled or disabled. When disabled, the respective service requests will not be processed. Strict CITE compliance When selected, enforces strict OGC Compliance and Interoperability Testing Initiative (CITE) conformance. Recommended for use when running conformance tests. Maintainer Name of the responsible party (organization, company, or person) that maintains the service instance. Online Resource Defines the top-level HTTP URL of the service. Typically the Online Resource is the URL of the service \"home page.\" (Required) Title A human-readable title to briefly identify this service in menus to clients. (Required) Abstract Provides a descriptive narrative with more information about the service. Fees Indicates any fees imposed by the service provider for usage of the service. The keyword NONE is reserved to mean no fees and fits most cases. Access Constraints Describes any constraints imposed by the service provider on the service. The keyword NONE is reserved to indicate no access constraints are imposed and fits most cases. Keywords List of terms that are associated with the service to aid in cataloging and searching."},{"location":"configuration/tools/","title":"Tools","text":"

                                                                  This page contains helpful tools for administrators to manage or automate configuration. You need to be logged into GeoServer to access this page.

                                                                  • Bulk Load tool
                                                                  • Resource Browser tool
                                                                  "},{"location":"configuration/tools/bulk/","title":"Bulk Load tool","text":"

                                                                  The Catalog Bulk Load Tool is used to duplicate GeoServer configuration (workspaces, stores, layers) for testing. The tool can also be used to make a single duplicate for experimenting with configuration and optimization.

                                                                  Catalog Bulk Load Tool

                                                                  "},{"location":"configuration/tools/bulk/#duplicating-configuration","title":"Duplicating Configuration","text":"
                                                                  1. Navigate to Tools \u2192 Catalog Bulk Load Tool
                                                                  2. Select the item to copy:
                                                                    • Workspace and Namespace
                                                                    • Store
                                                                    • Resource and Layer
                                                                  3. Fill in the # of times to duplicate.
                                                                  4. Provide a Suffix to append
                                                                  5. Choose to recursively copy:
                                                                    • Recursively copying a workspace will duplicate all stores and layers contained in the workspace
                                                                    • Recursively copying a store will copy all layers published by the store
                                                                  6. Press Start to begin duplicating
                                                                  "},{"location":"configuration/tools/resource/","title":"Resource Browser tool","text":"

                                                                  Tools page to manage data directory resources including icons, fonts, and configuration files.

                                                                  • Installing the GeoServer Web Resource extension
                                                                  • Resource Browser
                                                                  • Resource Browser Examples
                                                                  "},{"location":"configuration/tools/resource/browser/","title":"Resource Browser","text":"

                                                                  The Resource Browser provides a tree showing configuration folders, along with actions to edit and manage resources.

                                                                  Resource Browser

                                                                  User interface elements:

                                                                  • Resource tree is used to explore configuration folders and resource items.

                                                                  • Upload uploads files to GeoServer. Select a directory to enable this tool.

                                                                    Upload a resource

                                                                  • Download is used to download a selected resource from GeoServer as a file.

                                                                  • New resource creates a new text file in the selected directory. The Edit Resource dialog is used to record the resource location, and the contents.

                                                                    Edit a Resource (New File)

                                                                  • Edit a selected resource.

                                                                    Edit a Resource (Existing File)

                                                                  • Use Cut, Copy, and Paste to move resources between folders.

                                                                    Paste a Resource

                                                                  • Rename to rename a selected resource.

                                                                    Rename a Resource

                                                                  • Delete to remove a selected resource.

                                                                    Delete a resource

                                                                  "},{"location":"configuration/tools/resource/browser/#before-you-start","title":"Before you start","text":"

                                                                  The resource browser is used to manage configuration resources in environments that do not provide direct disk access:

                                                                  • When running GeoServer on a remote machine it can be difficult mange the icons and fonts used for effective styling
                                                                  • Some cloud deployments of GeoServer operate without a data directory. In these environments the resource browser is used to manage items stored in a database or cloud storage rather than a file system.
                                                                  • Folders are visual only, when creating or uploading a resource you can type a path and folders will be created as needed.

                                                                  Warning

                                                                  Please use this tool with caution:

                                                                  • Configuration files managed by the web administration application can be reviewed and even modified using this tool.
                                                                  • It is not advised to edit these files directly as GeoServer must reload its Catalog to notice these changes.
                                                                  "},{"location":"configuration/tools/resource/examples/","title":"Resource Browser Examples","text":""},{"location":"configuration/tools/resource/examples/#uploading-an-icon-to-a-styles-folder","title":"Uploading an icon to a styles folder","text":"

                                                                  To upload a file to the global styles folder:

                                                                  1. Use Resource Browser to select / \u2192 styles in the resource tree.

                                                                    Resource Browser styles folder

                                                                  2. Click Upload button to open Upload a Resource dialog.

                                                                  3. Use Browse to select a file from the local file system.

                                                                    Upload icon to styles folder

                                                                  4. Press OK to upload the file.

                                                                    Resource Browser icon

                                                                  "},{"location":"configuration/tools/resource/examples/#creating-a-control-flow-configuration-file","title":"Creating a control-flow configuration file","text":"

                                                                  Many extensions, such as Control flow module, are managed using a configuration file.

                                                                  To create a controlflow.properties file:

                                                                  1. Use Resource Browser to select the root / folder in the resource tree.

                                                                    This can be tricky as the label is not very long.

                                                                    Resource Browser root folder

                                                                  2. Click New resource button to open Edit a Resource dialog.

                                                                    • Resource: controlflow.properties

                                                                    • Content: file contents

                                                                      {% \n  include \"../../../extensions/controlflow/controlflow.properties\"\n%}\n
                                                                  3. Press OK to create the resource.

                                                                    Edit a Resource controlflow.properties

                                                                  "},{"location":"configuration/tools/resource/install/","title":"Installing the GeoServer Web Resource extension","text":"

                                                                  The Resource Brower tool is provided by the web-resource extension is listed on the GeoServer download page.

                                                                  To install web-resource extension:

                                                                  1. From the GeoServer Download page locate the release used and download: web-resource

                                                                    Verify that the version number in the filename corresponds to the version of GeoServer you are running (for example 2.24.2 above).

                                                                  2. Extract the contents of the archive into the WEB-INF/lib directory in GeoServer.

                                                                    This extension includes two jars.

                                                                  3. Restart GeoServer.

                                                                  4. To confirm successful installation, navigate to Tools page and confirm the availability of Resource Browser tool.

                                                                  "},{"location":"data/","title":"Data management","text":"

                                                                  GeoServer connects to and publishes data from a wide variety of sources. This section will discuss how to use the GeoServer web interface to accomplish most common tasks, along with the different data formats served by GeoServer.

                                                                  Note

                                                                  There are many more data sources available through Extensions and Community modules. If you are looking for a specific data format and not finding it here, please check those sections.

                                                                  • Data settings
                                                                  • Vector data
                                                                  • Raster data
                                                                  • Databases
                                                                  • Cascaded service data
                                                                  • Application schemas
                                                                  "},{"location":"data/app-schema/","title":"Application schemas","text":"

                                                                  The application schema support (app-schema) extension provides support for app-schema.complex-features in GeoServer WFS.

                                                                  Note

                                                                  You must install the app-schema plugin to use Application Schema Support.

                                                                  GeoServer provides support for a broad selection of simple feature data stores, including property files, shapefiles, and JDBC data stores such as PostGIS and Oracle Spatial. The app-schema module takes one or more of these simple feature data stores and applies a mapping to convert the simple feature types into one or more complex feature types conforming to a GML application schema.

                                                                  Three tables in a database are accessed using GeoServer simple feature support and converted into two complex feature types.

                                                                  The app-schema module looks to GeoServer just like any other data store and so can be loaded and used to service WFS requests. In effect, the app-schema data store is a wrapper or adapter that converts a simple feature data store into complex features for delivery via WFS. The mapping works both ways, so queries against properties of complex features are supported.

                                                                  • Complex Features
                                                                  • Installation
                                                                  • WFS Service Settings
                                                                  • Configuration
                                                                  • Mapping File
                                                                  • Application Schema Resolution
                                                                  • Supported GML Versions
                                                                  • Secondary Namespaces
                                                                  • CQL functions
                                                                  • Property Interpolation
                                                                  • Data Stores
                                                                  • Feature Chaining
                                                                  • Polymorphism
                                                                  • Data Access Integration
                                                                  • WMS Support
                                                                  • WFS 2.0 Support
                                                                  • Joining Support For Performance
                                                                  • Tutorial
                                                                  • MongoDB Tutorial
                                                                  • Apache Solr Tutorial
                                                                  "},{"location":"data/app-schema/app-schema-resolution/","title":"Application Schema Resolution","text":"

                                                                  To be able to encode XML responses conforming to a GML application schema, the app-schema plugin must be able to locate the application schema files (XSDs) that define the schema. This page describes the schema resolution process.

                                                                  "},{"location":"data/app-schema/app-schema-resolution/#schema-downloading-is-now-automatic-for-most-users","title":"Schema downloading is now automatic for most users","text":"

                                                                  GeoServer will automatically download and cache (see Cache below) all the schemas it needs the first time it starts if:

                                                                  1. All the application schemas you use are accessed via http/https URLs, and
                                                                  2. Your GeoServer instance is deployed on a network that permits it to download them.

                                                                  Note

                                                                  This is the recommended way of using GeoServer app-schema for most users.

                                                                  If cached downloading is used, no manual handling of schemas will be required. The rest of this page is for those with more complicated arrangements, or who wish to clear the cache.

                                                                  "},{"location":"data/app-schema/app-schema-resolution/#resolution-order","title":"Resolution order","text":"

                                                                  The order of sources used to resolve application schemas is:

                                                                  1. OASIS Catalog
                                                                  2. Classpath
                                                                  3. Cache

                                                                  Every attempt to load a schema works down this list, so imports can be resolved from sources other than that used for the originating document. For example, an application schema in the cache that references a schema found in the catalog will use the version in the catalog, rather than caching it. This allows users to supply unpublished or modified schemas sourced from, for example, the catalog, at the cost of interoperability (how do WFS clients get them?).

                                                                  "},{"location":"data/app-schema/app-schema-resolution/#oasis-catalog","title":"OASIS Catalog","text":"

                                                                  An OASIS XML Catalog is a standard configuration file format that instructs an XML processing system how to process entity references. The GeoServer app-schema resolver uses catalog URI semantics to locate application schemas, so uri or rewriteURI entries should be present in your catalog. The optional mapping file catalog element provides the location of the OASIS XML Catalog configuration file, given as a path relative to the mapping file, for example:

                                                                  <catalog>../../../schemas/catalog.xml</catalog>\n

                                                                  Earlier versions of the app-schema plugin required all schemas to be present in the catalog. This is no longer the case. Because the catalog is searched first, existing catalog-based deployments will continue to work as before.

                                                                  To migrate an existing GeoServer app-schema deployment that uses an OASIS Catalog to instead use cached downloads (see Cache below), remove all catalog elements from your mapping files and restart GeoServer.

                                                                  "},{"location":"data/app-schema/app-schema-resolution/#classpath","title":"Classpath","text":"

                                                                  Java applications such as GeoServer can load resources from the Java classpath. GeoServer app-schema uses a simple mapping from an http or https URL to a classpath resource location. For example, an application schema published at http://schemas.example.org/exampleml/exml.xsd would be found on the classpath if it was stored either:

                                                                  • at /org/example/schemas/exampleml/exml.xsd in a JAR file on the classpath (for example, a JAR file in WEB-INF/lib) or,
                                                                  • on the local filesystem at WEB-INF/classes/org/example/schemas/exampleml/exml.xsd .

                                                                  The ability to load schemas from the classpath is intended to support testing, but may be useful to users whose communities supply JAR files containing their application schemas.

                                                                  "},{"location":"data/app-schema/app-schema-resolution/#app-schema-cache","title":"Cache","text":"

                                                                  If an application schema cannot be found in the catalog or on the classpath, it is downloaded from the network and stored in a subdirectory app-schema-cache of the GeoServer data directory.

                                                                  • Once schemas are downloaded into the cache, they persist indefinitely, including over GeoServer restarts.
                                                                  • No attempt will be made to retrieve new versions of cached schemas.
                                                                  • To clear the cache, remove the subdirectory app-schema-cache of the GeoServer data directory and restart GeoServer.

                                                                  GeoServer app-schema uses a simple mapping from an http or https URL to local filesystem path. For example, an application schema published at http://schemas.example.org/exampleml/exml.xsd would be downloaded and stored as app-schema-cache/org/example/schemas/exampleml/exml.xsd . Note that:

                                                                  • Only http and https URLs are supported.
                                                                  • Port numbers, queries, and fragments are ignored.

                                                                  If your GeoServer instance is deployed on a network whose firewall rules prevent outgoing TCP connections on port 80 (http) or 443 (https), schema downloading will not work. (For security reasons, some service networks [\"demilitarised zones\"] prohibit such outgoing connections.) If schema downloading is not permitted on your network, there are three solutions:

                                                                  1. Either: Install and configure GeoServer on another network that can make outgoing TCP connections, start GeoServer to trigger schema download, and then manually copy the app-schema-cache directory to the production server. This is the easiest option because GeoServer automatically downloads all the schemas it needs, including dependencies.
                                                                  2. Or: Deploy JAR files containing all required schema files on the classpath (see Classpath above).
                                                                  3. Or: Use a catalog (see OASIS Catalog above).

                                                                  Warning

                                                                  System property \"schema.cache.dir\" with a cache directory location is required for using a mapping file from a remote URL with 'http://' or 'https://' protocol.

                                                                  "},{"location":"data/app-schema/complex-features/","title":"Complex Features","text":"

                                                                  To understand complex features, and why you would want use them, you first need to know a little about simple features.

                                                                  "},{"location":"data/app-schema/complex-features/#simple-features","title":"Simple features","text":"

                                                                  A common use of GeoServer WFS is to connect to a data source such as a database and access one or more tables, where each table is treated as a WFS simple feature type. Simple features contain a list of properties that each have one piece of simple information such as a string or number. (Special provision is made for geometry objects, which are treated like single items of simple data.) The Open Geospatial Consortium (OGC) defines three Simple Feature profiles; SF-0, SF-1, and SF-2. GeoServer simple features are close to OGC SF-0, the simplest OGC profile.

                                                                  GeoServer WFS simple features provide a straightforward mapping from a database table or similar structure to a \"flat\" XML representation, where every column of the table maps to an XML element that usually contains no further structure. One reason why GeoServer WFS is so easy to use with simple features is that the conversion from columns in a database table to XML elements is automatic. The name of each element is the name of the column, in the namespace of the data store. The name of the feature type defaults to the name of the table. GeoServer WFS can manufacture an XSD type definition for every simple feature type it serves. Submit a DescribeFeatureType request to see it.

                                                                  "},{"location":"data/app-schema/complex-features/#benefits-of-simple-features","title":"Benefits of simple features","text":"
                                                                  • Easy to implement
                                                                  • Fast
                                                                  • Support queries on properties, including spatial queries on geometries
                                                                  "},{"location":"data/app-schema/complex-features/#drawbacks-of-simple-features","title":"Drawbacks of simple features","text":"
                                                                  • When GeoServer automatically generates an XSD, the XML format is tied to the database schema.
                                                                  • To share data with GeoServer simple features, participants must either use the same database schema or translate between different schemas.
                                                                  • Even if a community could agree on a single database schema, as more data owners with different data are added to a community, the number of columns in the table becomes unmanageable.
                                                                  • Interoperability is difficult because simple features do not allow modification of only part of the schema.
                                                                  "},{"location":"data/app-schema/complex-features/#simple-feature-example","title":"Simple feature example","text":"

                                                                  For example, if we had a database table stations containing information about GPS stations:

                                                                  | id | code |      name      |         location         |\n+----+------+----------------+--------------------------+\n| 27 | ALIC | Alice Springs  | POINT(133.8855 -23.6701) |\n| 4  | NORF | Norfolk Island | POINT(167.9388 -29.0434) |\n| 12 | COCO | Cocos          | POINT(96.8339 -12.1883)  |\n| 31 | ALBY | Albany         | POINT(117.8102 -34.9502) |\n

                                                                  GeoServer would then be able to create the following simple feature WFS response fragment:

                                                                  <gps:stations gml:id=\"stations.27\">\n    <gps:code>ALIC</gps:code>\n    <gps:name>Alice Springs</gps:name>\n    <gps:location>\n        <gml:Point srsName=\"urn:x-ogc:def:crs:EPSG:4326\">\n            <gml:pos>-23.6701 133.8855</gml:pos>\n        </gml:Point>\n    </gps:location>\n</gps:stations>\n
                                                                  • Every row in the table is converted into a feature.
                                                                  • Every column in the table is converted into an element, which contains the value for that row.
                                                                  • Every element is in the namespace of the data store.
                                                                  • Automatic conversions are applied to some special types like geometries, which have internal structure, and include elements defined in GML.
                                                                  "},{"location":"data/app-schema/complex-features/#complex-features_1","title":"Complex features","text":"

                                                                  Complex features contain properties that can contain further nested properties to arbitrary depth. In particular, complex features can contain properties that are other complex features. Complex features can be used to represent information not as an XML view of a single table, but as a collection of related objects of different types.

                                                                  Simple feature Complex feature Properties are single data item, e.g. text, number, geometry Properties can be complex, including complex features XML view of a single table Collection of related identifiable objects Schema automatically generated based on database Schema agreed by community One large type Multiple different types Straightforward Richly featured data standards Interoperability relies on simplicity and customisation Interoperability through standardization"},{"location":"data/app-schema/complex-features/#benefits-of-complex-features","title":"Benefits of complex features","text":"
                                                                  • Can define information model as an object-oriented structure, an application schema.
                                                                  • Information is modelled not as a single table but as a collection of related objects whose associations and types may vary from feature to feature (polymorphism), permitting rich expression of content.
                                                                  • By breaking the schema into a collection of independent types, communities need only extend those types they need to modify. This simplifies governance and permits interoperability between related communities who can agree on common base types but need not agree on application-specific subtypes..
                                                                  "},{"location":"data/app-schema/complex-features/#drawbacks-of-complex-features","title":"Drawbacks of complex features","text":"
                                                                  • More complex to implement
                                                                  • Complex responses might slower if more database queries are required for each feature.
                                                                  • Information modelling is required to standardize an application schema. While this is beneficial, it requires effort from the user community.
                                                                  "},{"location":"data/app-schema/complex-features/#complex-feature-example","title":"Complex feature example","text":"

                                                                  Let us return to our stations table and supplement it with a foreign key gu_id that describes the relationship between the GPS station and the geologic unit to which it is physically attached:

                                                                  | id | code |      name      |         location         | gu_id |\n+----+------+----------------+--------------------------+-------+\n| 27 | ALIC | Alice Springs  | POINT(133.8855 -23.6701) | 32785 |\n| 4  | NORF | Norfolk Island | POINT(167.9388 -29.0434) | 10237 | \n| 12 | COCO | Cocos          | POINT(96.8339 -12.1883)  | 19286 |\n| 31 | ALBY | Albany         | POINT(117.8102 -34.9502) | 92774 |\n

                                                                  The geologic unit is stored in the table geologicunit:

                                                                  | gu_id |                       urn             |         text        |\n+-------+---------------------------------------+---------------------+\n| 32785 | urn:x-demo:feature:GeologicUnit:32785 | Metamorphic bedrock |\n...\n

                                                                  The simple features approach would be to join the stations table with the geologicunit table into one view and then deliver \"flat\" XML that contained all the properties of both. The complex feature approach is to deliver the two tables as separate feature types. This allows the relationship between the entities to be represented while preserving their individual identity.

                                                                  For example, we could map the GPS station to a sa:SamplingPoint with a gsml:GeologicUnit. The these types are defined in the following application schemas respectively:

                                                                  • http://schemas.opengis.net/sampling/1.0.0/sampling.xsd

                                                                    • Documentation: OGC 07-002r3: http://portal.opengeospatial.org/files/?artifact_id=22467
                                                                  • http://www.geosciml.org/geosciml/2.0/xsd/geosciml.xsd

                                                                    • Documentation: http://www.geosciml.org/geosciml/2.0/doc/

                                                                  The complex feature WFS response fragment could then be encoded as:

                                                                  <sa:SamplingPoint gml:id=\"stations.27>\n  <gml:name codeSpace=\"urn:x-demo:SimpleName\">Alice Springs</gml:name>\n  <gml:name codeSpace=\"urn:x-demo:IGS:ID\">ALIC</gml:name>\n  <sa:sampledFeature>\n     <gsml:GeologicUnit gml:id=\"geologicunit.32785\">\n         <gml:description>Metamorphic bedrock</gml:description>\n         <gml:name codeSpace=\"urn:x-demo:Feature\">urn:x-demo:feature:GeologicUnit:32785</gml:name>\n     </gsml:GeologicUnit>\n  </sa:sampledFeature>\n  <sa:relatedObservation xlink:href=\"urn:x-demo:feature:GeologicUnit:32785\" />\n  <sa:position>\n      <gml:Point srsName=\"urn:x-ogc:def:crs:EPSG:4326\">\n          <gml:pos>-23.6701 133.8855</gml:pos>\n      </gml:Point>\n  </sa:position>\n</sa:SamplingPoint>\n
                                                                  • The property sa:sampledFeature can reference any other feature type, inline (included in the response) or by reference (an xlink:href URL or URN). This is an example of the use of polymorphism.
                                                                  • The property sa:relatedObservation refers to the same GeologicUnit as sa:sampledFeature, but by reference.
                                                                  • Derivation of new types provides an extension point, allowing information models to be reused and extended in a way that supports backwards compatibility.
                                                                  • Multiple sampling points can share a single GeologicUnit. Application schemas can also define multivalued properties to support many-to-one or many-to-many associations.
                                                                  • Each GeologicUnit could have further properties describing in detail the properties of the rock, such as colour, weathering, lithology, or relevant geologic events.
                                                                  • The GeologicUnit feature type can be served separately, and could be uniquely identified through its properties as the same instance seen in the SamplingPoint.
                                                                  "},{"location":"data/app-schema/complex-features/#portrayal-complex-features-sf0","title":"Portrayal complex features (SF0)","text":"

                                                                  Portrayal schemas are standardized schemas with flat attributes, also known as simple feature level 0 (SF0). Because a community schema is still required (e.g. GeoSciML-Portrayal), app-schema plugin is still used to map the database columns to the attributes.

                                                                  • WFS CSV output format is supported for complex features with portrayal schemas. At the moment, propertyName selection is not yet supported with csv outputFormat, so it always returns the full set of attributes.
                                                                  • Complex features with nesting and multi-valued properties are not supported with WFS CSV output format.
                                                                  "},{"location":"data/app-schema/configuration/","title":"Configuration","text":"

                                                                  Configuration of an app-schema complex feature type requires manual construction of a GeoServer data directory that contains an XML mapping file and a datastore.xml that points at this mapping file. The data directory also requires all the other ancillary configuration files used by GeoServer for simple features. GeoServer can serve simple and complex features at the same time.

                                                                  "},{"location":"data/app-schema/configuration/#workspace-layout","title":"Workspace layout","text":"

                                                                  The GeoServer data directory contains a folder called workspaces with the following structure:

                                                                  workspaces\n    - gsml\n        - SomeDataStore\n            - SomeFeatureType\n                - featuretype.xml\n            - datastore.xml\n            - SomeFeatureType-mapping-file.xml\n

                                                                  Note

                                                                  The folder inside workspaces must have a name (the workspace name) that is the same as the namespace prefix (gsml in this example).

                                                                  "},{"location":"data/app-schema/configuration/#datastore","title":"Datastore","text":"

                                                                  Each data store folder contains a file datastore.xml that contains the configuration parameters of the data store. To create an app-schema feature type, the data store must be configured to load the app-schema service module and process the mapping file. These options are contained in the connectionParameters:

                                                                  • namespace defines the XML namespace of the complex feature type.
                                                                  • url is a file: URL that gives the location of the app-schema mapping file relative to the root of the GeoServer data directory.
                                                                  • dbtype must be app-schema to trigger the creation of an app-schema feature type.
                                                                  "},{"location":"data/app-schema/cql-functions/","title":"CQL functions","text":"

                                                                  CQL functions enable data conversion and conditional behaviour to be specified in mapping files. Some of these functions are provided by the app-schema plugin specifically for this purpose.

                                                                  • The uDig manual includes a list of CQL functions:

                                                                    • http://udig.refractions.net/confluence/display/EN/Constraint%20Query%20Language.html
                                                                  • CQL string literals are enclosed in single quotes, for example 'urn:ogc:def:nil:OGC:missing'.

                                                                  • Single quotes are represented in CQL string literals as two single quotes, just as in SQL. For example, 'yyyy-MM-dd''T''HH:mm:ss''Z''' for the string yyyy-MM-dd'T'HH:mm:ss'Z'.

                                                                  "},{"location":"data/app-schema/cql-functions/#vocabulary-translation","title":"Vocabulary translation","text":"

                                                                  This section describes how to serve vocabulary translations using some function expressions in application schema mapping file. If you're not familiar with application schema mapping file, read app-schema.mapping-file.

                                                                  "},{"location":"data/app-schema/cql-functions/#recode","title":"Recode","text":"

                                                                  This is similar to if_then_else function, except that there is no default clause. You have to specify a translation value for every vocabulary key.

                                                                  Syntax:

                                                                  Recode(COLUMN_NAME, key1, value1, key2, value2,...)\n
                                                                  • COLUMN_NAME: column name to get values from

                                                                  Example:

                                                                  <AttributeMapping>\n  <targetAttribute>gml:name</targetAttribute>\n  <sourceExpression>\n      <OCQL>Recode(ABBREVIATION, '1GRAV', 'urn:cgi:classifier:CGI:SimpleLithology:2008:gravel',\n                                 '1TILL', 'urn:cgi:classifier:CGI:SimpleLithology:2008:diamictite',\n                                 '6ALLU', 'urn:cgi:classifier:CGI:SimpleLithology:2008:sediment')\n      </OCQL>\n  </sourceExpression>\n</AttributeMapping>\n

                                                                  The above example will map gml:name value to urn:cgi:classifier:CGI:SimpleLithology:2008:gravel if the ABBREVIATION column value is 1GRAV.

                                                                  "},{"location":"data/app-schema/cql-functions/#categorize","title":"Categorize","text":"

                                                                  This is more suitable for numeric keys, where the translation value is determined by the key's position within the thresholds.

                                                                  Syntax:

                                                                  Categorize(COLUMN_NAME, default_value, threshold 1, value 1, threshold 2, value 2, ..., [preceding/succeeding])\n
                                                                  • COLUMN_NAME: data source column name

                                                                  • default_value: default value to be mapped if COLUMN_NAME value is not within the threshold

                                                                  • threshold(n): threshold value

                                                                  • value(n): value to be mapped if the threshold is met

                                                                  • preceding/succeeding:
                                                                    • optional, succeeding is used by default if not specified.
                                                                    • not case sensitive.
                                                                    • preceding: value is within threshold if COLUMN_NAME value > threshold
                                                                    • succeeding: value is within threshold if COLUMN_NAME value >= threshold

                                                                  Example:

                                                                  <AttributeMapping>\n  <targetAttribute>gml:description</targetAttribute>\n  <sourceExpression>\n      <OCQL>Categorize(CGI_LOWER_RANGE, 'missing_value', 1000, 'minor', 5000, 'significant')</OCQL>\n  </sourceExpression>\n</AttributeMapping>\n

                                                                  The above example means gml:description value would be significant if CGI_LOWER_RANGE column value is >= 5000.

                                                                  "},{"location":"data/app-schema/cql-functions/#vocab","title":"Vocab","text":"

                                                                  This function is more useful for bigger vocabulary pairs. Instead of writing a long key-to-value pairs in the function, you can keep them in a separate properties file. The properties file serves as a lookup table to the function. It has no header, and only contains the pairs in ''='' format.

                                                                  Syntax:

                                                                  Vocab(COLUMN_NAME, properties file)\n
                                                                  • COLUMN_NAME: column name to get values from
                                                                  • properties file: absolute path of the properties file

                                                                  Example:

                                                                  Properties file:

                                                                  1GRAV=urn:cgi:classifier:CGI:SimpleLithology:2008:gravel\n1TILL=urn:cgi:classifier:CGI:SimpleLithology:2008:diamictite\n6ALLU=urn:cgi:classifier:CGI:SimpleLithology:2008:sediment\n

                                                                  Mapping file:

                                                                  <AttributeMapping>\n  <targetAttribute>gml:name</targetAttribute>\n  <sourceExpression>\n      <OCQL>Vocab(ABBREVIATION, strconcat('${config.parent}', '/mapping.properties'))</OCQL>\n  </sourceExpression>\n</AttributeMapping>\n

                                                                  The above example will map gml:name to urn:cgi:classifier:CGI:SimpleLithology:2008:gravel if ABBREVIATION value is 1GRAV.

                                                                  This example uses the config.parent predefined interpolation property to specify a vocabulary properties file in the same directory as the mapping file. See app-schema.property-interpolation for details.

                                                                  "},{"location":"data/app-schema/cql-functions/#geometry-creation","title":"Geometry creation","text":""},{"location":"data/app-schema/cql-functions/#todirectposition","title":"toDirectPosition","text":"

                                                                  This function converts double values to DirectPosition geometry type. This is needed when the data store doesn't have geometry type columns. This function expects:

                                                                  Literal

                                                                  'SRS_NAME' (optional)

                                                                  Expression

                                                                  expression of SRS name if 'SRS_NAME' is present as the first argument

                                                                  Expression

                                                                  name of column pointing to first double value

                                                                  Expression

                                                                  name of column pointing to second double value (optional, only for 2D)

                                                                  "},{"location":"data/app-schema/cql-functions/#toenvelope","title":"ToEnvelope","text":"

                                                                  ToEnvelope function can take in the following set of parameters and return as either Envelope or ReferencedEnvelope type:

                                                                  Option 1 (1D Envelope):

                                                                  ToEnvelope(minx,maxx)\n

                                                                  Option 2 (1D Envelope with crsname):

                                                                  ToEnvelope(minx,maxx,crsname)\n

                                                                  Option 3 (2D Envelope):

                                                                  ToEnvelope(minx,maxx,miny,maxy)\n

                                                                  Option 4 (2D Envelope with crsname):

                                                                  ToEnvelope(minx,maxx,miny,maxy,crsname)\n
                                                                  "},{"location":"data/app-schema/cql-functions/#topoint","title":"toPoint","text":"

                                                                  This function converts double values to a 2D Point geometry type. This is needed when the data store doesn't have geometry type columns. This function expects:

                                                                  Literal

                                                                  'SRS_NAME' (optional)

                                                                  Expression

                                                                  expression of SRS name if 'SRS_NAME' is present as the first argument

                                                                  Expression

                                                                  name of column pointing to first double value

                                                                  Expression

                                                                  name of column pointing to second double value

                                                                  Expression

                                                                  expression of gml:id (optional)

                                                                  "},{"location":"data/app-schema/cql-functions/#tolinestring","title":"toLineString","text":"

                                                                  This function converts double values to 1D LineString geometry type. This is needed to express 1D borehole intervals with custom (non EPSG) CRS.

                                                                  Literal

                                                                  'SRS_NAME' (EPSG code or custom SRS)

                                                                  Expression

                                                                  name of column pointing to first double value

                                                                  Expression

                                                                  name of column pointing to second double value

                                                                  "},{"location":"data/app-schema/cql-functions/#reference","title":"Reference","text":""},{"location":"data/app-schema/cql-functions/#toxlinkhref","title":"toXlinkHref","text":"

                                                                  This function redirects an attribute to be encoded as xlink:href, instead of being encoded as a full attribute. This is useful in polymorphism, where static client property cannot be used when the encoding is conditional. This function expects:

                                                                  Expression

                                                                  REFERENCE_VALUE (could be another function or literal)

                                                                  "},{"location":"data/app-schema/cql-functions/#datetime-formatting","title":"Date/time formatting","text":""},{"location":"data/app-schema/cql-functions/#formatdatetimezone","title":"FormatDateTimezone","text":"

                                                                  A function to format a date/time using a SimpleDateFormat pattern in a time zone supported by Java. This function improves on dateFormat, which formats date/time in the server time zone and can produce unintended results. Note that the term \"date\" is derived from a Java class name; this class represents a date/time, not just a single day.

                                                                  Syntax:

                                                                  FormatDateTimezone(pattern, date, timezone)\n
                                                                  pattern

                                                                  formatting pattern supported by SimpleDateFormat, for example 'yyyy-MM-dd'. Use two single quotes to include a literal single quote in a CQL string literal, for example 'yyyy-MM-dd''T''HH:mm:ss''Z'''.

                                                                  date

                                                                  the date/time to be formatted or its string representation, for example '1948-01-01T00:00:00Z'. An exception will be returned if the date is malformed (and not null). Database types with time zone information are recommended.

                                                                  timezone

                                                                  the name of a time zone supported by Java, for example 'UTC' or 'Canada/Mountain'. Note that unrecognised timezones will silently be converted to UTC.

                                                                  This function returns null if any parameter is null.

                                                                  This example formats date/times from a column POSITION in UTC for inclusion in a csml:TimeSeries:

                                                                  <AttributeMapping>\n    <targetAttribute>csml:timePositionList</targetAttribute>                    \n    <sourceExpression>\n        <OCQL>FormatDateTimezone('yyyy-MM-dd''T''HH:mm:ss''Z''', POSITION, 'UTC')</OCQL>\n    </sourceExpression>\n    <isList>true</isList>\n</AttributeMapping>\n
                                                                  "},{"location":"data/app-schema/data-access-integration/","title":"Data Access Integration","text":"

                                                                  This page assumes prior knowledge of Application schemas and app-schema.feature-chaining. To use feature chaining, the nested features can come from any complex feature data access, as long as:

                                                                  • it has valid data referred by the \"container\" feature type,
                                                                  • the data access is registered via DataAccessRegistry,
                                                                  • if FEATURE_LINK is used as the link field, the feature types were created via ComplexFeatureTypeFactoryImpl

                                                                  However, the \"container\" features must come from an application schema data access. The rest of this article describes how we can create an application data access from an existing non-application schema data access, in order to \"chain\" features. The input data access referred in this article is assumed to be the non-application schema data access.

                                                                  "},{"location":"data/app-schema/data-access-integration/#how-to-connect-to-the-input-data-access","title":"How to connect to the input data access","text":"

                                                                  Configure the data store connection in \"sourceDataStores\" tag as usual, but also specify the additional \"isDataAccess\" tag. This flag marks that we want to get the registered complex feature source of the specified \"sourceType\", when processing the source data store. This assumes that the input data access is registered in DataAccessRegistry upon creation, for the system to find it.

                                                                  Example:

                                                                  <sourceDataStores>\n  <DataStore>\n  <id>EarthResource</id>\n  <parameters>\n     <Parameter>\n       <name>directory</name>\n       <value>file:./</value>\n     </Parameter>\n  </parameters>\n  <isDataAccess>true</isDataAccess>\n  </DataStore>\n</sourceDataStores>\n...\n<typeMappings>\n  <FeatureTypeMapping>\n    <sourceDataStore>EarthResource</sourceDataStore>\n  <sourceType>EarthResource</sourceType>\n...\n
                                                                  "},{"location":"data/app-schema/data-access-integration/#how-to-configure-the-mapping","title":"How to configure the mapping","text":"

                                                                  Use \"inputAttribute\" in place of \"OCQL\" tag inside \"sourceExpression\", to specify the input XPath expressions.

                                                                  Example:

                                                                  <AttributeMapping>\n  <targetAttribute>gsml:classifier/gsml:ControlledConcept/gsml:preferredName</targetAttribute>\n  <sourceExpression>\n      <inputAttribute>mo:classification/mo:MineralDepositModel/mo:mineralDepositGroup</inputAttribute>\n  </sourceExpression>\n</AttributeMapping>\n
                                                                  "},{"location":"data/app-schema/data-access-integration/#how-to-chain-features","title":"How to chain features","text":"

                                                                  Feature chaining works both ways for the re-mapped complex features. You can chain other features inside these features, and vice-versa. The only difference is to use \"inputAttribute\" for the input XPath expressions, instead of \"OCQL\" as mentioned above.

                                                                  Example:

                                                                  <AttributeMapping>\n  <targetAttribute>gsml:occurence</targetAttribute>\n  <sourceExpression>\n      <inputAttribute>mo:commodityDescription</inputAttribute>\n      <linkElement>gsml:MappedFeature</linkElement>\n      <linkField>gml:name[2]</linkField>\n  </sourceExpression>\n  <isMultiple>true</isMultiple>\n</AttributeMapping>\n
                                                                  "},{"location":"data/app-schema/data-access-integration/#how-to-use-filters","title":"How to use filters","text":"

                                                                  From the user point of view, filters are configured as per normal, using the mapped/output target attribute XPath expressions. However, when one or more attributes in the expression is a multi-valued property, we need to specify a function such as \"contains_text\" in the filter. This is because when multiple values are returned, comparing them to a single value would only return true if there is only one value returned, and it is the same value. Please note that the \"contains_text\" function used in the following example is not available in GeoServer API, but defined in the database.

                                                                  Example:

                                                                  Composition is a multi-valued property:

                                                                  <ogc:Filter>\n  <ogc:PropertyIsEqualTo>\n    <ogc:Function name=\"contains_text\">\n        <ogc:PropertyName>gsml:composition/gsml:CompositionPart/gsml:proportion/gsml:CGI_TermValue/gsml:value</ogc:PropertyName>\n        <ogc:Literal>Olivine basalt, tuff, microgabbro, minor sedimentary rocks</ogc:Literal>\n    </ogc:Function>\n    <ogc:Literal>1</ogc:Literal>\n  </ogc:PropertyIsEqualTo>\n</ogc:Filter>\n
                                                                  "},{"location":"data/app-schema/data-stores/","title":"Data Stores","text":"

                                                                  The app-schema app-schema.mapping-file requires you to specify your data sources in the sourceDataStores section. For GeoServer simple features, these are configured using the web interface, but because app-schema lacks a web configuration interface, data stores must be configured by editing the mapping file.

                                                                  Many configuration options may be externalised through the use of app-schema.property-interpolation.

                                                                  "},{"location":"data/app-schema/data-stores/#the-datastore-element","title":"The DataStore element","text":"

                                                                  A DataStore configuration consists of

                                                                  • an id, which is an opaque identifier used to refer to the data store elsewhere in a mapping file, and
                                                                  • one or more Parameter elements, which each contain the name and value of one parameter, and are used to configure the data store.

                                                                  An outline of the DataStore element:

                                                                  <DataStore>\n     <id>datastore</id>\n     <parameters>\n         <Parameter>\n             <name>...</name>\n             <value>...</value>\n         </Parameter>\n         ...\n     </parameters>\n</DataStore>\n

                                                                  Parameter order is not significant.

                                                                  "},{"location":"data/app-schema/data-stores/#database-options","title":"Database options","text":"

                                                                  Databases such as PostGIS and Oracle share some common or similar configuration options.

                                                                  name Meaning value examples dbtype Database type postgisng, Oracle host Host name or IP address of database server database.example.org, 192.168.3.12 port database schema user passwd TCP port on database server PostGIS/Oracle database The database schema The user name used to login to the database server The password used to login to the database server Default if omitted: 1521 (Oracle), 5432 (PostGIS) Expose primary keys Columns with primary keys available for mapping Default is false, set to true to use primary key columns in mapping"},{"location":"data/app-schema/data-stores/#postgis","title":"PostGIS","text":"

                                                                  Set the parameter dbtype to postgisng to use the PostGIS NG (New Generation) driver bundled with GeoServer 2.0 and later.

                                                                  Example:

                                                                  <DataStore>\n    <id>datastore</id>\n    <parameters>\n        <Parameter>\n            <name>dbtype</name>\n            <value>postgisng</value>\n        </Parameter>\n        <Parameter>\n            <name>host</name>\n            <value>postgresql.example.org</value>\n        </Parameter>\n        <Parameter>\n            <name>port</name>\n            <value>5432</value>\n        </Parameter>\n        <Parameter>\n            <name>database</name>\n            <value>test</value>\n        </Parameter>\n        <Parameter>\n            <name>user</name>\n            <value>test</value>\n        </Parameter>\n        <Parameter>\n            <name>passwd</name>\n            <value>test</value>\n        </Parameter>\n    </parameters>\n</DataStore>\n

                                                                  Note

                                                                  PostGIS support is included in the main GeoServer bundle, so a separate plugin is not required.

                                                                  "},{"location":"data/app-schema/data-stores/#oracle","title":"Oracle","text":"

                                                                  Set the parameter dbtype to Oracle to use the Oracle Spatial NG (New Generation) driver compatible with GeoServer 2.0 and later.

                                                                  Example:

                                                                  <DataStore>\n    <id>datastore</id>\n    <parameters>\n        <Parameter>\n            <name>dbtype</name>\n            <value>Oracle</value>\n        </Parameter>\n        <Parameter>\n            <name>host</name>\n            <value>oracle.example.org</value>\n        </Parameter>\n        <Parameter>\n            <name>port</name>\n            <value>1521</value>\n        </Parameter>\n        <Parameter>\n            <name>database</name>\n            <value>demodb</value>\n        </Parameter>\n        <Parameter>\n            <name>user</name>\n            <value>orauser</value>\n        </Parameter>\n        <Parameter>\n            <name>passwd</name>\n            <value>s3cr3t</value>\n        </Parameter>\n    </parameters>\n</DataStore>\n

                                                                  Note

                                                                  You must install the Oracle plugin to connect to Oracle Spatial databases.

                                                                  "},{"location":"data/app-schema/data-stores/#shapefile","title":"Shapefile","text":"

                                                                  Shapefile data sources are identified by the presence of a parameter url, whose value should be the file URL for the .shp file.

                                                                  In this example, only the url parameter is required. The others are optional:

                                                                  <DataStore>\n    <id>shapefile</id>\n    <parameters>\n        <Parameter>\n            <name>url</name>\n            <value>file:/D:/Workspace/shapefiles/VerdeRiverBuffer.shp</value>\n        </Parameter>\n        <Parameter>\n            <name>memory mapped buffer</name>\n            <value>false</value>\n        </Parameter>\n        <Parameter>\n            <name>create spatial index</name>\n            <value>true</value>\n        </Parameter>\n        <Parameter>\n            <name>charset</name>\n            <value>ISO-8859-1</value>\n        </Parameter>\n    </parameters>\n</DataStore>\n

                                                                  Note

                                                                  The url in this case is an example of a Windows filesystem path translated to URL notation.

                                                                  Note

                                                                  Shapefile support is included in the main GeoServer bundle, so a separate plugin is not required.

                                                                  "},{"location":"data/app-schema/data-stores/#property-file","title":"Property file","text":"

                                                                  Property files are configured by specifying a directory that is a file: URI.

                                                                  • If the directory starts with file:./ it is relative to the mapping file directory. (This is an invalid URI, but it works.)

                                                                  For example, the following data store is used to access property files in the same directory as the mapping file:

                                                                  <DataStore>\n    <id>propertyfile</id>\n    <parameters>\n        <Parameter>\n            <name>directory</name>\n            <value>file:./</value>\n        </Parameter>\n    </parameters>\n</DataStore>\n

                                                                  A property file data store contains all the feature types stored in .properties files in the directory. For example, if the directory contained River.properties and station.properties, the data store would be able to serve them as the feature types River and station. Other file extensions are ignored.

                                                                  Note

                                                                  Property file support is included in the main GeoServer bundle, so a separate plugin is not required.

                                                                  "},{"location":"data/app-schema/data-stores/#jndi","title":"JNDI","text":"

                                                                  Defining a JDBC data store with a jndiReferenceName allows you to use a connection pool provided by your servlet container. This allows detailed configuration of connection pool parameters and sharing of connections between data sources, and even between servlets.

                                                                  To use a JNDI connection provider:

                                                                  1. Specify a dbtype parameter to indicate the database type. These values are the same as for the non-JNDI examples above.
                                                                  2. Give the jndiReferenceName you set in your servlet container. Both the abbreviated form jdbc/oracle form, as in Tomcat, and the canonical form java:comp/env/jdbc/oracle are supported.

                                                                  This example uses JNDI to obtain Oracle connections:

                                                                  <DataStore>\n    <id>datastore</id>\n    <parameters>\n        <Parameter>\n            <name>dbtype</name>\n            <value>Oracle</value>\n        </Parameter>\n        <Parameter>\n            <name>jndiReferenceName</name>\n            <value>jdbc/oracle</value>\n        </Parameter>\n    </parameters>\n</DataStore>\n

                                                                  Your servlet container my require you to add a resource-ref section at the end of your geoserver/WEB-INF/web.xml. (Tomcat requires this, Jetty does not.) For example:

                                                                  <resource-ref>\n    <description>Oracle Spatial Datasource</description>\n    <res-ref-name>jdbc/oracle</res-ref-name>\n    <res-type>javax.sql.DataSource</res-type>\n    <res-auth>Container</res-auth>\n</resource-ref>\n

                                                                  Here is an example of a Tomcat 6 context in /etc/tomcat6/server.xml that includes an Oracle connection pool:

                                                                  <Context\n    path=\"/geoserver\"\n    docBase=\"/usr/local/geoserver\"\n    crossContext=\"false\"\n    reloadable=\"false\">\n    <Resource\n        name=\"jdbc/oracle\"\n        auth=\"Container\"\n        type=\"javax.sql.DataSource\"\n        url=\"jdbc:oracle:thin:@YOUR_DATABASE_HOSTNAME:1521:YOUR_DATABASE_NAME\"\n        driverClassName=\"oracle.jdbc.driver.OracleDriver\"\n        username=\"YOUR_DATABASE_USERNAME\"\n        password=\"YOUR_DATABASE_PASSWORD\"\n        maxActive=\"20\"\n        maxIdle=\"10\"\n        minIdle=\"0\"\n        maxWait=\"10000\"\n        minEvictableIdleTimeMillis=\"300000\"\n        timeBetweenEvictionRunsMillis=\"300000\"\n        numTestsPerEvictionRun=\"20\"\n        poolPreparedStatements=\"true\"\n        maxOpenPreparedStatements=\"100\"\n        testOnBorrow=\"true\"\n        validationQuery=\"SELECT SYSDATE FROM DUAL\" />\n</Context>\n

                                                                  Firewall timeouts can silently sever idle connections to the database and cause GeoServer to hang. If there is a firewall between GeoServer and the database, a connection pool configured to shut down idle connections before the firewall can drop them will prevent GeoServer from hanging. This JNDI connection pool is configured to shut down idle connections after 5 to 10 minutes.

                                                                  See also Setting up a JNDI connection pool with Tomcat.

                                                                  "},{"location":"data/app-schema/data-stores/#expose-primary-keys","title":"Expose primary keys","text":"

                                                                  By default, GeoServer conceals the existence of database columns with a primary key. To make such columns available for use in app-schema mapping files, set the data store parameter Expose primary keys to true:

                                                                  <Parameter>\n    <name>Expose primary keys</name>\n   <value>true</value>\n</Parameter>\n

                                                                  This is known to work with PostGIS, Oracle, and JNDI data stores.

                                                                  "},{"location":"data/app-schema/data-stores/#mongodb","title":"MongoDB","text":"

                                                                  The data store configuration for a MongoDB data base will look like this:

                                                                  <sourceDataStores>\n    <DataStore>\n        <id>data_source</id>\n        <parameters>\n            <Parameter>\n                <name>data_store</name>\n                <value>MONGO_DB_URL</value>\n            </Parameter>\n            <Parameter>\n                <name>namespace</name>\n                <value>NAME_SPACE</value>\n            </Parameter>\n            <Parameter>\n                <name>schema_store</name>\n                <value>SCHEMA_STORE</value>\n            </Parameter>\n            <Parameter>\n                <name>data_store_type</name>\n                <value>complex</value>\n            </Parameter>\n        </parameters>\n    </DataStore>\n</sourceDataStores>\n

                                                                  Check MongoDB Tutorial for a more detailed description about how to use MongoDB with app-schema.

                                                                  Note

                                                                  You must install the MongoDB plugin to connect to MongoDB databases.

                                                                  "},{"location":"data/app-schema/feature-chaining/","title":"Feature Chaining","text":""},{"location":"data/app-schema/feature-chaining/#scope","title":"Scope","text":"

                                                                  This page describes the use of \"Feature Chaining\" to compose complex features from simpler components, and in particular to address some requirements that have proven significant in practice.

                                                                  • Handling multiple cases of multi-valued properties within a single Feature Type
                                                                  • Handing nesting of multi-valued properties within other multi-valued properties
                                                                  • Linking related (through association) Feature Types, and in particular allowing re-use of the related features types (for example the O&M pattern has relatedObservation from a samplingFeature, but Observation may be useful in its own right)
                                                                  • Encoding the same referenced property object as links when it appears in multiple containing features
                                                                  • Eliminating the need for large denormalized data store views of top level features and their related features. Denormalized views would still be needed for special cases, such as many-to-many relationships, but won't be as large.

                                                                  For non-application schema configurations, please refer to app-schema.data-access-integration.

                                                                  "},{"location":"data/app-schema/feature-chaining/#mapping-steps","title":"Mapping steps","text":""},{"location":"data/app-schema/feature-chaining/#create-a-mapping-file-for-every-complex-type","title":"Create a mapping file for every complex type","text":"

                                                                  We need one mapping file per complex type that is going to be nested, including non features, e.g. gsml:CompositionPart.

                                                                  Non-feature types that cannot be individually accessed (eg. CompositionPart as a Data Type) can still be mapped separately for its reusability. For this case, the containing feature type has to include these types in its mapping file. The include tag should contain the nested mapping file path relative to the location of the containing type mapping file. In GeologicUnit_MappingFile.xml:

                                                                  <includedTypes>   \n    <Include>CGITermValue_MappingFile.xml</Include>\n    <Include>CompositionPart_MappingFile.xml</Include>\n</includedTypes>\n

                                                                  Feature types that can be individually accessed don't need to be explicitly included in the mapping file, as they would be configured for GeoServer to find. Such types would have their mapping file associated with a corresponding datastore.xml file, which means that it can be found from the data store registry. In other words, if the type is associated with a datastore.xml file, it doesn't need to be explicitly included if referred from another mapping file.

                                                                  Example:

                                                                  For this output: MappedFeature_Output.xml, here are the mapping files:

                                                                  • MappedFeature_MappingFile.xml
                                                                  • GeologicUnit_MappingFile.xml
                                                                  • CompositionPart_MappingFile.xml
                                                                  • GeologicEvent_MappingFile.xml
                                                                  • CGITermValue_MappingFile.xml

                                                                  GeologicUnit type

                                                                  You can see within GeologicUnit features, both gml:composition (CompositionPart type) and gsml:geologicHistory (GeologicEvent type) are multi-valued properties. It shows how multiple cases of multi-valued properties can be configured within a single Feature Type. This also proves that you can \"chain\" non-feature type, as CompositionPart is a Data Type.

                                                                  GeologicEvent type

                                                                  Both gsml:eventEnvironment (CGI_TermValue type) and gsml:eventProcess (also of CGI_TermValue type) are multi-valued properties. This also shows that \"chaining\" can be done on many levels, as GeologicEvent is nested inside GeologicUnit. Note that gsml:eventAge properties are configured as inline attributes, as there can only be one event age per geologic event, thus eliminating the need for feature chaining.

                                                                  "},{"location":"data/app-schema/feature-chaining/#configure-nesting-on-the-nested-feature-type","title":"Configure nesting on the nested feature type","text":"

                                                                  In the nested feature type, make sure we have a field that can be referenced by the parent feature. If there isn't any existing field that can be referred to, the system field FEATURE_LINK can be mapped to hold the foreign key value. This is a multi-valued field, so more than one instances can be mapped in the same feature type, for features that can be nested by different parent types. Since this field doesn't exist in the schema, it wouldn't appear in the output document.

                                                                  In the source expression tag:

                                                                  • OCQL: the value of this should correspond to the OCQL part of the parent feature

                                                                  Example One: Using FEATURE_LINK in CGI TermValue type, which is referred by GeologicEvent as gsml:eventProcess and gsml:eventEnvironment.

                                                                  In GeologicEvent (the container feature) mapping:

                                                                  <AttributeMapping>\n  <targetAttribute>gsml:eventEnvironment</targetAttribute>\n  <sourceExpression>\n      <OCQL>id</OCQL>\n      <linkElement>gsml:CGI_TermValue</linkElement>\n      <linkField>FEATURE_LINK[1]</linkField>\n  </sourceExpression>\n  <isMultiple>true</isMultiple>\n</AttributeMapping>\n<AttributeMapping>\n  <targetAttribute>gsml:eventProcess</targetAttribute>\n  <sourceExpression>\n      <OCQL>id</OCQL>\n      <linkElement>gsml:CGI_TermValue</linkElement>\n      <linkField>FEATURE_LINK[2]</linkField>\n  </sourceExpression>\n  <isMultiple>true</isMultiple>\n</AttributeMapping>\n

                                                                  In CGI_TermValue (the nested feature) mapping:

                                                                  <AttributeMapping>\n  <!-- FEATURE_LINK[1] is referred by geologic event as environment -->\n  <targetAttribute>FEATURE_LINK[1]</targetAttribute>\n  <sourceExpression>\n      <OCQL>ENVIRONMENT_OWNER</OCQL>\n  </sourceExpression>\n</AttributeMapping>\n<AttributeMapping>\n  <!-- FEATURE_LINK[2] is referred by geologic event as process -->\n  <targetAttribute>FEATURE_LINK[2]</targetAttribute>\n  <sourceExpression><\n      <OCQL>PROCESS_OWNER</OCQL>\n  </sourceExpression>\n</AttributeMapping>\n

                                                                  The ENVIRONMENT_OWNER column in CGI_TermValue view corresponds to the ID column in GeologicEvent view.

                                                                  Geologic Event property file:

                                                                  id GEOLOGIC_UNIT_ID:String ghminage:String ghmaxage:String ghage_cdspace:String ge.26931120 gu.25699 Oligocene Paleocene ge.26930473 gu.25678 Holocene Pleistocene ge.26930960 gu.25678 Pliocene Miocene ge.26932959 gu.25678 LowerOrdovician LowerOrdovician

                                                                  CGI Term Value property file:

                                                                  id VALUE:String PROCESS_OWNER:String ENVIRONMENT_OWNER:String 3 fluvial NULL ge.26931120 4 swamp/marsh/bog NULL ge.26930473 5 marine NULL ge.26930960 6 submarine fan NULL ge.26932959 7 hemipelagic NULL ge.26932959 8 detrital deposition still water ge.26930473 NULL 9 water [process] ge.26932959 NULL 10 channelled stream flow ge.26931120 NULL 11 turbidity current ge.26932959 NULL

                                                                  The system field FEATURE_LINK doesn't get encoded in the output:

                                                                  <gsml:GeologicEvent>                      \n  <gml:name codeSpace=\"urn:cgi:classifierScheme:GSV:GeologicalUnitId\">gu.25699</gml:name>\n  <gsml:eventAge>\n    <gsml:CGI_TermRange>\n       <gsml:lower>\n          <gsml:CGI_TermValue>   \n            <gsml:value codeSpace=\"urn:cgi:classifierScheme:ICS:StratChart:2008\">Oligocene</gsml:value>\n          </gsml:CGI_TermValue>\n       </gsml:lower>\n       <gsml:upper>\n          <gsml:CGI_TermValue>\n            <gsml:value codeSpace=\"urn:cgi:classifierScheme:ICS:StratChart:2008\">Paleocene</gsml:value>\n          </gsml:CGI_TermValue>\n       </gsml:upper>\n    </gsml:CGI_TermRange>\n  </gsml:eventAge>\n  <gsml:eventEnvironment>\n    <gsml:CGI_TermValue>\n       <gsml:value>fluvial</gsml:value>\n    </gsml:CGI_TermValue>\n  </gsml:eventEnvironment>\n  <gsml:eventProcess>\n    <gsml:CGI_TermValue>\n       <gsml:value>channelled stream flow</gsml:value>\n    </gsml:CGI_TermValue>\n  </gsml:eventProcess>\n

                                                                  Example Two: Using existing field (gml:name) to hold the foreign key, see MappedFeature_MappingFile.xml:

                                                                  gsml:specification links to gml:name in GeologicUnit:

                                                                  <AttributeMapping>\n  <targetAttribute>gsml:specification</targetAttribute> \n  <sourceExpression>\n    <OCQL>GEOLOGIC_UNIT_ID</OCQL> \n    <linkElement>gsml:GeologicUnit</linkElement> \n    <linkField>gml:name[3]</linkField> \n  </sourceExpression>\n</AttributeMapping>\n

                                                                  In GeologicUnit_MappingFile.xml:

                                                                  GeologicUnit has 3 gml:name properties in the mapping file, so each has a code space to clarify them:

                                                                  <AttributeMapping>\n  <targetAttribute>gml:name[1]</targetAttribute> \n  <sourceExpression>\n    <OCQL>ABBREVIATION</OCQL> \n  </sourceExpression>\n  <ClientProperty>\n    <name>codeSpace</name> \n    <value>'urn:cgi:classifierScheme:GSV:GeologicalUnitCode'</value> \n  </ClientProperty>\n</AttributeMapping>\n<AttributeMapping>\n  <targetAttribute>gml:name[2]</targetAttribute> \n  <sourceExpression>\n    <OCQL>NAME</OCQL> \n  </sourceExpression>\n  <ClientProperty>\n    <name>codeSpace</name> \n    <value>'urn:cgi:classifierScheme:GSV:GeologicalUnitName'</value> \n  </ClientProperty>\n</AttributeMapping>\n<AttributeMapping>\n  <targetAttribute>gml:name[3]</targetAttribute> \n  <sourceExpression>\n    <OCQL>id</OCQL> \n  </sourceExpression>\n  <ClientProperty>\n    <name>codeSpace</name> \n    <value>'urn:cgi:classifierScheme:GSV:MappedFeatureReference'</value> \n  </ClientProperty>\n</AttributeMapping>\n

                                                                  The output with multiple gml:name properties and their code spaces:

                                                                  <gsml:specification>\n  <gsml:GeologicUnit gml:id=\"gu.25678\">\n      <gml:description>Olivine basalt, tuff, microgabbro, minor sedimentary rocks</gml:description>\n      <gml:name codeSpace=\"urn:cgi:classifierScheme:GSV:GeologicalUnitCode\">-Py</gml:name>\n      <gml:name codeSpace=\"urn:cgi:classifierScheme:GSV:GeologicalUnitName\">Yaugher Volcanic Group</gml:name>\n      <gml:name codeSpace=\"urn:cgi:classifierScheme:GSV:MappedFeatureReference\">gu.25678</gml:name>\n

                                                                  If this is the \"one\" side of a one-to-many or many-to-one database relationship, we can use the feature id as the source expression field, as you can see in above examples. See one_to_many_relationship.JPG as an illustration.

                                                                  If we have a many-to-many relationship, we have to use one denormalized view for either side of the nesting. This means we can either use the feature id as the referenced field, or assign a column to serve this purpose. See many_to_many_relationship.JPG as an illustration.

                                                                  Note

                                                                  • For many-to-many relationships, we can't use the same denormalized view for both sides of the nesting.

                                                                  Test this configuration by running a getFeature request for the nested feature type on its own.

                                                                  "},{"location":"data/app-schema/feature-chaining/#configure-nesting-on-the-containing-feature-type","title":"Configure nesting on the \"containing\" feature type","text":"

                                                                  When nesting another complex type, you need to specify in your source expression:

                                                                  • OCQL: OGC's Common Query Language expression of the data store column

                                                                  • linkElement:
                                                                    • the nested element name, which is normally the targetElement or mappingName of the corresponding type.
                                                                    • on some cases, it has to be an OCQL function (see app-schema.polymorphism)
                                                                  • linkField: the indexed XPath attribute on the nested element that OCQL corresponds to

                                                                  Example: Nesting composition part in geologic unit feature.

                                                                  In Geologic Unit mapping file:

                                                                  <AttributeMapping>\n    <targetAttribute>gsml:composition</targetAttribute>\n    <sourceExpression>\n        <OCQL>id</OCQL>\n        <linkElement>gsml:CompositionPart</linkElement>\n        <linkField>FEATURE_LINK</linkField>\n    </sourceExpression>\n    <isMultiple>true</isMultiple>\n</AttributeMapping>\n
                                                                  • OCQL: id is the geologic unit id
                                                                  • linkElement: links to gsml:CompositionPart type
                                                                  • linkField: FEATURE_LINK, the linking field mapped in gsml:CompositionPart type that also stores the geologic unit id. If there are more than one of these attributes in the nested feature type, make sure the index is included, e.g. FEATURE_LINK[2].

                                                                  Geologic Unit property file:

                                                                  id ABBREVIATAION:String NAME:String TEXTDESCRIPTION:String gu.25699 -Py Yaugher Volcanic Group Olivine basalt, tuff, microgabbro, minor sedimentary rocks gu.25678 -Py Yaugher Volcanic Group Olivine basalt, tuff, microgabbro, minor sedimentary rocks

                                                                  Composition Part property file:

                                                                  id COMPONENT_ROLE:String PROPORTION:String GEOLOGIC_UNIT_ID:String cp.167775491936278812 interbedded component significant gu.25699 cp.167775491936278856 interbedded component minor gu.25678 cp.167775491936278844 sole component major gu.25678

                                                                  Run the getFeature request to test this configuration. Check that the nested features returned in Step 2 are appropriately lined inside the containing features. If they are not there, or exceptions are thrown, scroll down and read the \"Trouble Shooting\" section.

                                                                  "},{"location":"data/app-schema/feature-chaining/#multiple-mappings-of-the-same-type","title":"Multiple mappings of the same type","text":"

                                                                  At times, you may find the need to have different FeatureTypeMapping instances for the same type. You may have two different attributes of the same type that need to be nested. For example, in gsml:GeologicUnit, you have gsml:exposureColor and gsml:outcropCharacter that are both of gsml:CGI_TermValue type.

                                                                  This is when the optional mappingName tag mentioned in app-schema.mapping-file comes in. Instead of passing in the nested feature type's targetElement in the containing type's linkElement, specify the corresponding mappingName.

                                                                  Note

                                                                  • The mappingName is namespace aware and case sensitive. * When the referred mappingName contains special characters such as '-', it must be enclosed with single quotes in the linkElement. E.g. 'observation-method'. * Each mappingName must be unique against other mappingName and targetElement tags across the application. * The mappingName is only to be used to identify the chained type from the nesting type. It is not a solution for multiple FeatureTypeMapping instances where > 1 of them can be queried as top level features. * When queried as a top level feature, the normal targetElement is to be used. Filters involving the nested type should still use the targetElement in the PropertyName part of the query. * You can't have more than 1 FeatureTypeMapping of the same type in the same mapping file if one of them is a top level feature. This is because featuretype.xml would look for the targetElement and wouldn't know which one to get.

                                                                  The solution for the last point above is to break them up into separate files and locations with only 1 featuretype.xml in the intended top level feature location. E.g.

                                                                  • You can have 2 FeatureTypeMapping instances in the same file for gsml:CGI_TermValue type since it's not a feature type.
                                                                  • You can have 2 FeatureTypeMapping instances for gsml:MappedFeature, but they have to be broken up into separate files. The one that can be queried as top level feature type would have featuretype.xml in its location.
                                                                  "},{"location":"data/app-schema/feature-chaining/#nesting-simple-properties","title":"Nesting simple properties","text":"

                                                                  You don't need to chain multi-valued simple properties and map them separately. The original configuration would still work.

                                                                  "},{"location":"data/app-schema/feature-chaining/#filtering-nested-attributes-on-chained-features","title":"Filtering nested attributes on chained features","text":"

                                                                  Filters would work as usual. You can supply the full XPath of the attribute, and the code would handle this. E.g. You can run the following filter on gsml:MappedFeatureUseCase2A:

                                                                  <ogc:Filter>\n      <ogc:PropertyIsEqualTo>\n          <ogc:Function name=\"contains_text\">\n              <ogc:PropertyName>gsml:specification/gsml:GeologicUnit/gml:description</ogc:PropertyName>\n              <ogc:Literal>Olivine basalt, tuff, microgabbro, minor sedimentary rocks</ogc:Literal>\n          </ogc:Function>\n          <ogc:Literal>1</ogc:Literal>\n      </ogc:PropertyIsEqualTo>\n</ogc:Filter>\n
                                                                  "},{"location":"data/app-schema/feature-chaining/#multi-valued-properties-by-reference-xlinkhref","title":"Multi-valued properties by reference (xlink:href)","text":"

                                                                  You may want to use feature chaining to set multi-valued properties by reference. This is particularly handy to avoid endless loop in circular relationships. For example, you may have a circular relationship between gsml:MappedFeature and gsml:GeologicUnit. E.g.

                                                                  • gsml:MappedFeature has gsml:GeologicUnit as gsml:specification
                                                                  • gsml:GeologicUnit has gsml:MappedFeature as gsml:occurrence

                                                                  Obviously you can only encode one side of the relationship, or you'll end up with an endless loop. You would need to pick one side to \"chain\" and use xlink:href for the other side of the relationship.

                                                                  For this example, we are nesting gsml:GeologicUnit in gsml:MappedFeature as gsml:specification.

                                                                  • Set up nesting on the container feature type mapping as usual:

                                                                    <AttributeMapping>\n  <targetAttribute>gsml:specification</targetAttribute>\n  <sourceExpression>\n      <OCQL>GEOLOGIC_UNIT_ID</OCQL>\n    <linkElement>gsml:GeologicUnit</linkElement>\n    <linkField>gml:name[2]</linkField>\n  </sourceExpression>\n</AttributeMapping>\n
                                                                  • Set up xlink:href as client property on the other mapping file:

                                                                    <AttributeMapping>\n  <targetAttribute>gsml:occurrence</targetAttribute>      \n  <sourceExpression>\n    <OCQL>id</OCQL>\n    <linkElement>gsml:MappedFeature</linkElement>\n    <linkField>gsml:specification</linkField>\n  </sourceExpression>                               \n  <isMultiple>true</isMultiple>                                       \n  <ClientProperty>\n     <name>xlink:href</name>\n     <value>strConcat('urn:cgi:feature:MappedFeature:', ID)</value>\n  </ClientProperty>       \n</AttributeMapping>\n

                                                                  As we are getting the client property value from a nested feature, we have to set it as if we are chaining the feature; but we also add the client property containing xlink:href in the attribute mapping. The code will detect the xlink:href setting, and will not proceed to build the nested feature's attributes, and we will end up with empty attributes with xlink:href client properties.

                                                                  This would be the encoded result for gsml:GeologicUnit:

                                                                  <gsml:GeologicUnit gml:id=\"gu.25678\">\n         <gsml:occurrence xlink:href=\"urn:cgi:feature:MappedFeature:mf2\"/>\n         <gsml:occurrence xlink:href=\"urn:cgi:feature:MappedFeature:mf3\"/>\n

                                                                  Note

                                                                  • Don't forget to add XLink in your mapping file namespaces section, or you could end up with a StackOverflowException as the xlink:href client property won't be recognized and the mappings would chain endlessly. * app-schema.resolve may be used to force app-schema to do full feature chaining up to a certain level, even if an xlink reference is specified.
                                                                  "},{"location":"data/app-schema/installation/","title":"Installation","text":"

                                                                  Application schema support is a GeoServer extension and is downloaded separately.

                                                                  • Download the app-schema plugin zip file for the same version of GeoServer.
                                                                  • Unzip the app-schema plugin zip file to obtain the jar files inside. Do not unzip the jar files.
                                                                  • Place the jar files in the WEB-INF/lib directory of your GeoServer installation.
                                                                  • Restart GeoServer to load the extension (although you might want to configure it first [see below]).
                                                                  "},{"location":"data/app-schema/joining/","title":"Joining Support For Performance","text":"

                                                                  App-schema joining is a optional configuration parameter that tells app-schema to use a different implementation for app-schema.feature-chaining, which in many cases can improve performance considerably, by reducing the amount of SQL queries sent to the DBMS.

                                                                  "},{"location":"data/app-schema/joining/#conditions","title":"Conditions","text":"

                                                                  In order to use App-schema Joining, the following configuration conditions must be met:

                                                                  • All feature mappings used must be mapped to JDBC datastores.
                                                                  • All feature mappings that are chained to each other must map to the same physical database.
                                                                  • In your mappings, there are restrictions on the CQL expressions specified in the of both the referencing field in the parent feature as well as the referenced field in the nested feature (like FEATURE_LINK). Any operators or functions used in this expression must be supported by the filter capabilities, i.e. geotools must be able to translate them directly to SQL code. This can be different for each DBMS, though as a general rule it can assumed that comparison operators, logical operators and arithmetic operators are all supported but functions are not. Using simple field names for feature chaining is guaranteed to always work.

                                                                    Failing to comply with any of these three restrictions when turning on Joining will result in exceptions thrown at run-time.

                                                                    When using app-schema with Joining turned on, the following restrictions exist with respect to normal behaviour:

                                                                    • XPaths specified inside Filters do not support handling referenced features (see app-schema.feature-chaining-by-reference) as if they were actual nested features, i.e. XPaths can only be evaluated when they can be evaluated against the actual XML code produced by WFS according to the XPath standard.
                                                                    "},{"location":"data/app-schema/joining/#configuration","title":"Configuration","text":"

                                                                    Joining is turned on by default. It is disabled by adding this simple line to your app-schema.properties file (see app-schema.property-interpolation) :

                                                                    app-schema.joining = false\n

                                                                    Or, alternatively, by setting the value of the Java System Property \"app-schema.joining\" to \"false\", for example :

                                                                    java -DGEOSERVER_DATA_DIR=... -Dapp-schema.joining=false Start\n

                                                                    Not specifying \"app-schema.joining\" parameter will enable joining by default.

                                                                    "},{"location":"data/app-schema/joining/#database-design-guidelines","title":"Database Design Guidelines","text":"
                                                                    • Databases should be optimised for fast on-the-fly joining and ordering.
                                                                    • Make sure to put indexes on all fields used as identifiers and for feature chaining, unique indexes where possible. Lack of indices may result in data being encoded in the wrong order or corrupted output when feature chaining is involved.
                                                                    • Map your features preferably to normalised tables.
                                                                    • It is recommended to apply feature chaining to regular one-to-many relationships, i.e. there should be a unique constraint defined on one of the fields used for the chaining, and if possible a foreign key constraint defined on the other field.
                                                                    "},{"location":"data/app-schema/joining/#effects-on-performance","title":"Effects on Performance","text":"

                                                                    Typical curves of response time for configurations with and without joining against the amount of features produced will be shaped like this:

                                                                    In the default implementation, response time increases rapidly with respect to the amount of produced features. This is because feature chaining is implemented by sending multiple SQL requests to the DBMS per feature, so the amount of requests increases with the amount of features produced. When Joining is turned on, response time will be almost constant with respect to the number of features. This is because in this implementation a small amount of larger queries is sent to the DBMS, independent of the amount of features produced. In summary, difference in performance becomes greater as the amount of features requested gets bigger. General performance of joining will be dependant on database and mapping design (see above) and database size.

                                                                    Using joining is strongly recommended when a large number of features need to be produced, for example when producing maps with WMS (see app-schema.wms-support).

                                                                    Optimising the performance of the database will maximise the benefit of using joining, including for small queries.

                                                                    "},{"location":"data/app-schema/joining/#native-encoding-of-filters-on-nested-attributes","title":"Native Encoding of Filters on Nested Attributes","text":"

                                                                    When App-Schema Joining is active, filters operating on nested attributes (i.e. attributes of features that are joined to the queried type via app-schema.feature-chaining) are translated to SQL and executed directly in the database backend, rather than being evaluated in memory after all features have been loaded (which was standard behavior in earlier versions of GeoServer). Native encoding can yield significant performance improvements, especially when the total number of features in the database is high (several thousands or more), but only a few of them would satisfy the filter.

                                                                    There are, however, a few limitations in the current implementation:

                                                                    1. Joining support must not have been explicitly disabled and all its pre-conditions must be met (see above)
                                                                    2. Only binary comparison operators (e.g. PropertyIsEqualTo, PropertyIsGreaterThan, etc...), PropertyIsLike and PropertyIsNull filters are translated to SQL
                                                                    3. Filters involving conditional polymorphic mappings are evaluated in memory
                                                                    4. Filters comparing two or more different nested attributes are evaluated in memory
                                                                    5. Filters matching multiple nested attribute mappings are evaluated in memory

                                                                    Much like joining support, native encoding of nested filters is turned on by default, and it is disabled by adding to your app-schema.properties file the line :

                                                                    app-schema.encodeNestedFilters = false\n

                                                                    Or, alternatively, by setting the value of the Java System Property \"app-schema.encodeNestedFilters\" to \"false\", for example :

                                                                    java -DGEOSERVER_DATA_DIR=... -Dapp-schema.encodeNestedFilters=false Start\n
                                                                    "},{"location":"data/app-schema/joining/#union-performance-improvement-for-or-conditions","title":"UNION performance improvement for OR conditions","text":"

                                                                    OR conditions are difficult to optimize for postgresql and are usually slow. App-Schema improves OR condition performance using UNION clauses instead OR for nested filter subqueries.

                                                                    With UNION improvement enabled main OR binary operator on nested filter subquery will rebuild normal OR query like:

                                                                    SELECT id, name FROM table WHERE name = \"A\" OR name = \"B\"\n

                                                                    to:

                                                                    SELECT id, name FROM table WHERE name = \"A\" UNION SELECT id, name FROM table WHERE name = \"B\"\n

                                                                    UNION improvement is enabled by default, and it is disabled by adding to your app-schema.properties file the line :

                                                                    app-schema.orUnionReplace = false\n

                                                                    Or, alternatively, by setting the value of the Java System Property \"app-schema.orUnionReplace\" to \"false\", for example :

                                                                    java -DGEOSERVER_DATA_DIR=... -Dapp-schema.orUnionReplace=false Start\n

                                                                    Note

                                                                    This optimization will only be applied when a PostgresSQL database is being used.

                                                                    "},{"location":"data/app-schema/mapping-file/","title":"Mapping File","text":"

                                                                    An app-schema feature type is configured using a mapping file that defines the data source for the feature and the mappings from the source data to XPaths in the output XML.

                                                                    "},{"location":"data/app-schema/mapping-file/#outline","title":"Outline","text":"

                                                                    Here is an outline of a mapping file:

                                                                    <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<as:AppSchemaDataAccess xmlns:as=\"http://www.geotools.org/app-schema\"\n    xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\"\n    xsi:schemaLocation=\"http://www.geotools.org/app-schema AppSchemaDataAccess.xsd\">\n    <namespaces>...</namespaces>\n    <includedTypes>...</includedTypes>\n    <sourceDataStores>...</sourceDataStores>\n    <catalog>...</catalog>\n    <targetTypes...</targetTypes>\n    <typeMappings>...</typeMappings>\n</as:AppSchemaDataAccess>\n
                                                                    • namespaces defines all the namespace prefixes used in the mapping file.
                                                                    • includedTypes (optional) defines all the included non-feature type mapping file locations that are referred in the mapping file.
                                                                    • sourceDataStores provides the configuration information for the source data stores.
                                                                    • catalog is the location of the OASIS Catalog used to resolve XML Schema locations.
                                                                    • targetTypes is the location of the XML Schema that defines the feature type.
                                                                    • typeMappings give the relationships between the fields of the source data store and the elements of the output complex feature.
                                                                    "},{"location":"data/app-schema/mapping-file/#mapping-file-schema","title":"Mapping file schema","text":"
                                                                    • AppSchemaDataAccess.xsd is optional because it is not used by GeoServer. The presence of AppSchemaDataAccess.xsd in the same folder as the mapping file enables XML editors to observe its grammar and provide contextual help.
                                                                    "},{"location":"data/app-schema/mapping-file/#settings","title":"Settings","text":""},{"location":"data/app-schema/mapping-file/#namespaces","title":"namespaces","text":"

                                                                    The namespaces section defines all the XML namespaces used in the mapping file:

                                                                    <Namespace>\n    <prefix>gsml</prefix>\n    <uri>urn:cgi:xmlns:CGI:GeoSciML:2.0</uri>\n</Namespace>\n<Namespace>\n    <prefix>gml</prefix>\n    <uri>http://www.opengis.net/gml</uri>\n</Namespace>\n<Namespace>\n    <prefix>xlink</prefix>\n    <uri>http://www.w3.org/1999/xlink</uri>\n</Namespace>\n
                                                                    "},{"location":"data/app-schema/mapping-file/#includedtypes-optional","title":"includedTypes (optional)","text":"

                                                                    Non-feature types (eg. gsml:CompositionPart is a data type that is nested in gsml:GeologicUnit) may be mapped separately for its reusability, but we don't want to configure it as a feature type as we don't want to individually access it. Related feature types don't need to be explicitly included here as it would have its own workspace configuration for GeoServer to find it. The location path in Include tag is relative to the mapping file. For an example, if gsml:CompositionPart configuration file is located in the same directory as the gsml:GeologicUnit configuration:

                                                                    <includedTypes>\n    <Include>gsml_CompositionPart.xml</Include>\n</includedTypes>\n
                                                                    "},{"location":"data/app-schema/mapping-file/#sourcedatastores","title":"sourceDataStores","text":"

                                                                    Every mapping file requires at least one data store to provide data for features. app-schema reuses GeoServer data stores, so there are many available types. See app-schema.data-stores for details of data store configuration. For example:

                                                                    <sourceDataStores>\n    <DataStore>\n        <id>datastore</id>\n        <parameters>\n            ...\n        </parameters>\n    </DataStore>\n    ...\n</sourceDataStores>\n

                                                                    If you have more than one DataStore in a mapping file, be sure to give them each a distinct id.

                                                                    "},{"location":"data/app-schema/mapping-file/#catalog-optional","title":"catalog (optional)","text":"

                                                                    The location of an OASIS XML Catalog configuration file, given as a path relative to the mapping file. See app-schema.app-schema-resolution for more information. For example:

                                                                    <catalog>../../../schemas/catalog.xml</catalog>\n
                                                                    "},{"location":"data/app-schema/mapping-file/#targettypes","title":"targetTypes","text":"

                                                                    The targetTypes section lists all the application schemas required to define the mapping. Typically only one is required. For example:

                                                                    <targetTypes>\n    <FeatureType>\n        <schemaUri>http://www.geosciml.org/geosciml/2.0/xsd/geosciml.xsd</schemaUri>\n    </FeatureType>\n</targetTypes>\n
                                                                    "},{"location":"data/app-schema/mapping-file/#mappings","title":"Mappings","text":""},{"location":"data/app-schema/mapping-file/#typemappings-and-featuretypemapping","title":"typeMappings and FeatureTypeMapping","text":"

                                                                    The typeMappings section is the heart of the app-schema module. It defines the mapping from simple features to the nested structure of one or more simple features. It consists of a list of FeatureTypeMapping elements, which each define one output feature type. For example:

                                                                    <typeMappings>\n    <FeatureTypeMapping>\n        <mappingName>mappedfeature1</mappingName>\n        <sourceDataStore>datastore</sourceDataStore>\n        <sourceType>mappedfeature</sourceType>\n        <targetElement>gsml:MappedFeature</targetElement>\n        <isDenormalised>true</isDenormalised>\n        <defaultGeometry>gsml:MappedFeature/gsml:shape/gml:Polygon</defaultGeometry>\n        <attributeMappings>\n            <AttributeMapping>\n                ...\n
                                                                    • mappingName is an optional tag, to identify the mapping in app-schema.feature-chaining when there are multiple FeatureTypeMapping instances for the same type. This is solely for feature chaining purposes, and would not work for identifying top level features.

                                                                    • sourceDataStore must be an identifier you provided when you defined a source data store the sourceDataStores section.

                                                                    • sourceType is the simple feature type name. For example:

                                                                      • a table or view name, lowercase for PostGIS, uppercase for Oracle.
                                                                      • a property file name (without the .properties suffix)
                                                                    • targetElement is the element name in the target application schema. This is the same as the WFS feature type name.

                                                                    • isDenormalised is an optional tag (default true) to indicate whether this type contains denormalised data or not. If data is not denormalised, then app-schema will build a more efficient query to apply the global feature limit. When combined with a low global feature limit (via Services --> WFS), setting this option to false can prevent unnecessary processing and database lookups from taking place.

                                                                    • defaultGeometry can be used to explicitly define the attribute of the feature type that should be used as the default geometry, this is more relevant in WMS than WFS. The default geometry XML path can reference any attribute of the feature type, exactly the same path that would be used to reference the desired property in a OGC filter. The path can reference a nested attribute belonging to a chained feature having a zero or one relationship with the root feature type.

                                                                    "},{"location":"data/app-schema/mapping-file/#attributemappings-and-attributemapping","title":"attributeMappings and AttributeMapping","text":"

                                                                    attributeMappings comprises a list of AttributeMapping elements:

                                                                    <AttributeMapping>\n    <targetAttribute>...</targetAttribute>\n    <idExpression>...</idExpression>\n    <sourceExpression>...</sourceExpression>\n    <targetAttributeNode>...</targetAttributeNode>\n    <isMultiple>...</isMultiple>\n    <ClientProperty>...</ClientProperty>\n</AttributeMapping>\n
                                                                    "},{"location":"data/app-schema/mapping-file/#targetattribute","title":"targetAttribute","text":"

                                                                    targetAttribute is the XPath to the output element, in the context of the target element. For example, if the containing mapping is for a feature, you should be able to map a gml:name property by setting the target attribute:

                                                                    <targetAttribute>gml:name</targetAttribute>\n

                                                                    Multivalued attributes resulting from app-schema.denormalised-sources are automatically encoded. If you wish to encode multivalued attributes from different input columns as a specific instance of an attribute, you can use a (one-based) index. For example, you can set the third gml:name with:

                                                                    <targetAttribute>gml:name[3]</targetAttribute>\n

                                                                    The reserved name FEATURE_LINK is used to map data that is not encoded in XML but is required for use in app-schema.feature-chaining.

                                                                    "},{"location":"data/app-schema/mapping-file/#idexpression-optional","title":"idExpression (optional)","text":"

                                                                    A CQL expression that is used to set the custom gml:id of the output feature type. This should be the name of a database column on its own. Using functions would cause an exception because it is not supported with the default joining implementation.

                                                                    Note

                                                                    Every feature must have a gml:id. This requirement is an implementation limitation (strictly, gml:id is optional in GML).

                                                                    • If idExpression is unspecified, gml:id will be <the table name>.<primary key>, e.g. MAPPEDFEATURE.1.
                                                                    • In the absence of primary keys, this will be <the table name>.<generated gml id>, e.g. MAPPEDFEATURE.fid--46fd41b8_1407138b56f_-7fe0.
                                                                    • If using property files instead of database tables, the default gml:id will be the row key found before the equals (\"=\") in the property file, e.g. the feature with row mf1=Mudstone|POINT(1 2)|... will have gml:id mf1.

                                                                    Note

                                                                    gml:id must be an NCName.

                                                                    "},{"location":"data/app-schema/mapping-file/#sourceexpression-optional","title":"sourceExpression (optional)","text":"

                                                                    Use a sourceExpression tag to set the element content from source data. For example, to set the element content from a column called DESCRIPTION:

                                                                    <sourceExpression><OCQL>DESCRIPTION</OCQL></sourceExpression>\n

                                                                    If sourceExpression is not present, the generated element is empty (unless set by another mapping).

                                                                    You can use CQL expressions to calculate the content of the element. This example concatenated strings from two columns and a literal:

                                                                    <sourceExpression>\n    <OCQL>strConCat(FIRST , strConCat(' followed by ', SECOND))</OCQL>\n</sourceExpression>\n

                                                                    You can also use app-schema.cql-functions for vocabulary translations.

                                                                    Warning

                                                                    Avoid use of CQL expressions for properties that users will want to query, because the current implementation cannot reverse these expressions to generate efficient SQL, and will instead read all features to calculate the property to find the features that match the filter query. Falling back to brute force search makes queries on CQL-calculated expressions very slow. If you must concatenate strings to generate content, you may find that doing this in your database is much faster.

                                                                    "},{"location":"data/app-schema/mapping-file/#linkelement-and-linkfield-optional","title":"linkElement and linkField (optional)","text":"

                                                                    The presence of linkElement and linkField change the meaning of sourceExpression to a app-schema.feature-chaining mapping, in which the source of the mapping is the feature of type linkElement with property linkField matching the expression. For example, the following sourceExpression uses as the result of the mapping the (possibly multivalued) gsml:MappedFeature for which gml:name[2] is equal to the value of URN for the source feature. This is in effect a foreign key relation:

                                                                    <sourceExpression>\n    <OCQL>URN</OCQL>\n    <linkElement>gsml:MappedFeature</linkElement>\n    <linkField>gml:name[2]</linkField>\n</sourceExpression>\n

                                                                    The feature type gsml:MappedFeature might be defined in another mapping file. The linkField can be FEATURE_LINK if you wish to relate the features by a property not exposed in XML. See app-schema.feature-chaining for a comprehensive discussion.

                                                                    For special cases, linkElement could be an OCQL function, and linkField could be omitted. See app-schema.polymorphism for further information.

                                                                    "},{"location":"data/app-schema/mapping-file/#targetattributenode-optional","title":"targetAttributeNode (optional)","text":"

                                                                    targetAttributeNode is required wherever a property type contains an abstract element and app-schema cannot determine the type of the enclosed attribute.

                                                                    In this example, om:result is of xs:anyType, which is abstract. We can use targetAttributeNode to set the type of the property type to a type that encloses a non-abstract element:

                                                                    <AttributeMapping>\n      <targetAttribute>om:result</targetAttribute>\n      <targetAttributeNode>gml:MeasureType</targetAttributeNode>\n      <sourceExpression>\n          <OCQL>TOPAGE</OCQL>\n      </sourceExpression>\n      <ClientProperty>\n          <name>xsi:type</name>\n          <value>'gml:MeasureType'</value>\n      </ClientProperty>\n      <ClientProperty>\n          <name>uom</name> \n          <value>'http://www.opengis.net/def/uom/UCUM/0/Ma'</value>\n      </ClientProperty> \n</AttributeMapping>\n

                                                                    If the casting type is complex, the specific type is implicitly determined by the XPath in targetAttribute and targetAttributeNode is not required. E.g., in this example om:result is automatically specialised as a MappedFeatureType:

                                                                    <AttributeMapping>\n      <targetAttribute>om:result/gsml:MappedFeature/gml:name</targetAttribute>\n      <sourceExpression>\n          <OCQL>NAME</OCQL>\n      </sourceExpression>\n</AttributeMapping>\n

                                                                    Although it is not required, we may still specify targetAttributeNode for the root node, and map the children attributes as per normal. This mapping must come before the mapping for the enclosed elements. By doing this, app-schema will report an exception if a mapping is specified for any of the children attributes that violates the type in targetAttributeNode. E.g.:

                                                                    <AttributeMapping>\n      <targetAttribute>om:result</targetAttribute>\n      <targetAttributeNode>gsml:MappedFeatureType<targetAttributeNode>\n</AttributeMapping> \n<AttributeMapping>\n      <targetAttribute>om:result/gsml:MappedFeature/gml:name</targetAttribute>\n      <sourceExpression>\n          <OCQL>NAME</OCQL>\n      </sourceExpression>\n</AttributeMapping>\n

                                                                    Note that the GML encoding rules require that complex types are never the direct property of another complex type; they are always contained in a property type to ensure that their type is encoded in a surrounding element. Encoded GML is always type/property/type/property. This is also known as the GML \"striping\" rule. The consequence of this for app-schema mapping files is that targetAttributeNode must be applied to the property and the type must be set to the XSD property type, not to the type of the contained attribute (gsml:CGI_TermValuePropertyType not gsml:CGI_TermValueType). Because the XPath refers to a property type not the encoded content, targetAttributeNode appears in a mapping with targetAttribute and no other elements when using with complex types.

                                                                    The XML encoder will encode nested complex features that are mapped to a complex type that does not respect the GML striping rule. The Java configuration property encoder.relaxed can be set to false to disable this behavior.

                                                                    "},{"location":"data/app-schema/mapping-file/#encodeifempty-optional","title":"encodeIfEmpty (optional)","text":"

                                                                    The encodeIfEmpty element will determine if an attribute will be encoded if it contains a null or empty value. By default encodeIfEmpty is set to false therefore any attribute that does not contain a value will be skipped:

                                                                    <encodeIfEmpty>true</encodeIfEmpty>\n

                                                                    encodeIfEmpty can be used to bring up attributes that only contain client properties such as xlink:title.

                                                                    "},{"location":"data/app-schema/mapping-file/#ismultiple-optional","title":"isMultiple (optional)","text":"

                                                                    The isMultiple element states whether there might be multiple values for this attribute, coming from denormalised rows. Because the default value is false and it is omitted in this case, it is most usually seen as:

                                                                    <isMultiple>true</isMultiple>\n

                                                                    For example, the table below is denormalised with NAME column having multiple values:

                                                                    ID NAME DESCRIPTION gu.25678 Yaugher Volcanic Group 1 Olivine basalt, tuff, microgabbro gu.25678 Yaugher Volcanic Group 2 Olivine basalt, tuff, microgabbro

                                                                    The configuration file specifies isMultiple for gml:name attribute that is mapped to the NAME column:

                                                                    <AttributeMapping>\n    <targetAttribute>gml:name</targetAttribute>                       \n    <sourceExpression>\n        <OCQL>NAME</OCQL>\n</sourceExpression>                 \n<isMultiple>true</isMultiple>\n<ClientProperty>\n    <name>codeSpace</name>\n    <value>'urn:ietf:rfc:2141'</value>\n</ClientProperty>\n</AttributeMapping>\n

                                                                    The output produces multiple gml:name attributes for each feature grouped by the id:

                                                                    <gsml:GeologicUnit gml:id=\"gu.25678\">\n    <gml:description>Olivine basalt, tuff, microgabbro</gml:description>\n    <gml:name codeSpace=\"urn:ietf:rfc:2141\">Yaugher Volcanic Group 1</gml:name>\n    <gml:name codeSpace=\"urn:ietf:rfc:2141\">Yaugher Volcanic Group 2</gml:name>\n ...\n
                                                                    "},{"location":"data/app-schema/mapping-file/#islist-optional","title":"isList (optional)","text":"

                                                                    The isList element states whether there might be multiple values for this attribute, concatenated as a list. The usage is similar with isMultiple, except the values appear concatenated inside a single node instead of each value encoded in a separate node. Because the default value is false and it is omitted in this case, it is most usually seen as:

                                                                    <isList>true</isList>\n

                                                                    For example, the table below has multiple POSITION for each feature:

                                                                    +-------+-----------+ | ID | POSITION | +=======+===========+ | ID1.2 | > 1948-05 | +-------+-----------+ | ID1.2 | > 1948-06 | +-------+-----------+ | ID1.2 | > 1948-07 | +-------+-----------+ | ID1.2 | > 1948-08 | +-------+-----------+ | ID1.2 | > 1948-09 | +-------+-----------+

                                                                    The configuration file uses isList on timePositionList attribute mapped to POSITION column:

                                                                    <AttributeMapping>\n    <targetAttribute>csml:timePositionList</targetAttribute>\n    <sourceExpression>\n    <OCQL>POSITION</OCQL>\n    </sourceExpression>\n    <isList>true</isList>\n</AttributeMapping>\n

                                                                    The output produced:

                                                                    <csml:pointSeriesDomain>\n    <csml:TimeSeries gml:id=\"ID1.2\">\n        <csml:timePositionList>1949-05 1949-06 1949-07 1949-08 1949-09</csml:timePositionList>\n    </csml:TimeSeries>\n</csml:pointSeriesDomain>\n
                                                                    "},{"location":"data/app-schema/mapping-file/#clientproperty-optional-multivalued","title":"ClientProperty (optional, multivalued)","text":"

                                                                    A mapping can have one or more ClientProperty elements which set XML attributes on the mapping target. Each ClientProperty has a name and a value that is an arbitrary CQL expression. No OCQL element is used inside value.

                                                                    This example of a ClientProperty element sets the codeSpace XML attribute to the literal string urn:ietf:rfc:2141. Note the use of single quotes around the literal string. This could be applied to any target attribute of GML CodeType:

                                                                    <ClientProperty>\n    <name>codeSpace</name>\n    <value>'urn:ietf:rfc:2141'</value>\n</ClientProperty>\n

                                                                    When the GML association pattern is used to encode a property by reference, the xlink:href attribute is set and the element is empty. This ClientProperty element sets the xlink:href XML attribute to the value of the RELATED_FEATURE_URN field in the data source (for example, a column in an Oracle database table). This mapping could be applied to any property type, such a gml:FeaturePropertyType, or other type modelled on the GML association pattern:

                                                                    <ClientProperty>\n    <name>xlink:href</name>\n    <value>RELATED_FEATURE_URN</value>\n</ClientProperty>\n

                                                                    See the discussion in app-schema.feature-chaining for the special case in which xlink:href is created for multivalued properties by reference.

                                                                    "},{"location":"data/app-schema/mapping-file/#cql","title":"CQL","text":"

                                                                    CQL functions enable data conversion and conditional behaviour to be specified in mapping files.

                                                                    • See app-schema.cql-functions for information on additional functions provided by the app-schema plugin.

                                                                    • The uDig manual includes a list of CQL functions:

                                                                      • http://udig.refractions.net/confluence/display/EN/Constraint+Query+Language
                                                                    • CQL string literals are enclosed in single quotes, for example 'urn:ogc:def:nil:OGC:missing'.

                                                                    "},{"location":"data/app-schema/mapping-file/#database-identifiers","title":"Database identifiers","text":"

                                                                    When referring to database table/view names or column names, use:

                                                                    • lowercase for PostGIS
                                                                    • UPPERCASE for Oracle Spatial
                                                                    "},{"location":"data/app-schema/mapping-file/#app-schema.denormalised-sources","title":"Denormalised sources","text":"

                                                                    Multivalued properties from denormalised sources (the same source feature ID appears more than once) are automatically encoded. For example, a view might have a repeated id column with varying name so that an arbitrarily large number of gml:name properties can be encoded for the output feature.

                                                                    Warning

                                                                    Denormalised sources must grouped so that features with duplicate IDs are provided without any intervening features. This can be achieved by ensuring that denormalised source features are sorted by ID. Failure to observe this restriction will result in data corruption. This restriction is however not necessary when using app-schema.joining because then ordering will happen automatically.

                                                                    "},{"location":"data/app-schema/mapping-file/#attributes-with-cardinality-1n","title":"Attributes with cardinality 1..N","text":"

                                                                    Consider the following two tables, the first table contains information related to meteorological stations:

                                                                    ID NAME st.1 Station 1 st.2 Station 2

                                                                    The second table contains tags that are associated with meteorological stations:

                                                                    ID STATION_ID TAG CODE tg.1 st.1 temperature X1Y tg.2 st.1 wind X2Y tg.3 st.2 pressure X3Y

                                                                    A station can have multiple tags, establishing a one to many relationship between stations and tags, the GML representation of the first station should look like this:

                                                                    (...)\n<st:Station gml:id=\"st.1\">\n  <st:name>Station 1</st:name>\n  <st:tag st:code=\"X1Y\">temperature</st:tag>\n  <st:tag st:code=\"X2Y\">wind</st:tag>\n</st:Station_gml32>\n(...)\n

                                                                    Mappings with a one to many relationship are supported with a custom syntax in JDBC based data stores and Apache Solr data store.

                                                                    "},{"location":"data/app-schema/mapping-file/#sql-based-data-stores","title":"SQL based data stores","text":"

                                                                    When using JDBC based data stores attributes with a 1..N relationship can be mapped like this:

                                                                    (...)\n<AttributeMapping>\n  <targetAttribute>st:tag</targetAttribute>\n  <jdbcMultipleValue>\n    <sourceColumn>ID</sourceColumn>\n    <targetTable>TAGS</targetTable>\n    <targetColumn>STATION_ID</targetColumn>\n    <targetValue>TAG</targetValue>\n  </jdbcMultipleValue>\n  <ClientProperty>\n    <name>st:code</name>\n    <value>CODE</value>\n  </ClientProperty>\n</AttributeMapping>\n(...)\n

                                                                    The targetValue refers to the value of the <st:tag> element, the client property is mapped with the usual syntax. Behind the scenes App-Schema will take care of associating the st:code attribute value with the correct tag.

                                                                    Another variant of this feature can be used for nested elements on an unbounded anonymous sequence, Using 'anonymousAttribute' element definition for generating child elements and values inside an anonymous umbounded sequence:

                                                                    (...)\n<AttributeMapping>\n  <targetAttribute>st:tag</targetAttribute>\n  <jdbcMultipleValue>\n    <sourceColumn>ID</sourceColumn>\n    <targetTable>TAGS</targetTable>\n    <targetColumn>STATION_ID</targetColumn>\n  </jdbcMultipleValue>\n  <anonymousAttribute>\n    <name>st:code</name>\n    <value>CODE</value>\n  </anonymousAttribute>\n</AttributeMapping>\n(...)\n

                                                                    In this case 'st:code' element children will be generated with the computed client property value:

                                                                    (...)\n<st:Station gml:id=\"st.1\">\n  <st:name>Station 1</st:name>\n  <st:tag>\n    <st:code>X1Y</st:code>\n    <st:code>X2Y</st:code>\n  </st:tag>\n</st:Station_gml32>\n(...)\n

                                                                    Having an schema with anonymous unbounded sequence like :

                                                                    <xs:complexType name=\"StationType\">\n  <xs:complexContent>\n    <xs:extension base=\"gml:AbstractFeatureType\">\n      <xs:sequence>\n        <xs:element name=\"name\" type=\"xs:string\"/>\n        <xs:element name=\"contact\" type=\"st:ContactPropertyType\"/>\n        <xs:element name=\"location\" type=\"gml:GeometryPropertyType\"/>\n        <xs:element maxOccurs=\"unbounded\" minOccurs=\"0\" name=\"tag\" type=\"st:TagType\"/>\n        <xs:element name=\"measurements\" type=\"ms:MeasurementPropertyType\" minOccurs=\"0\" maxOccurs=\"unbounded\"/>\n        <xs:element name=\"maintainer\" minOccurs=\"0\">\n          <xs:complexType>\n            <xs:sequence maxOccurs=\"unbounded\">\n              <xs:element name=\"name\" type=\"xs:string\"/>\n              <xs:element name=\"level\" type=\"xs:integer\" nillable=\"true\"/>\n              <xs:element name=\"classType\" />\n            </xs:sequence>\n          </xs:complexType>\n        </xs:element>\n      </xs:sequence>\n    </xs:extension>\n  </xs:complexContent>\n</xs:complexType>\n

                                                                    We could define the following mapping :

                                                                    <FeatureTypeMapping>\n <sourceDataStore>stations_gml32</sourceDataStore>\n <sourceType>stations_gml32</sourceType>\n <targetElement>st_gml32:Station_gml32</targetElement>\n <attributeMappings>\n   <AttributeMapping>\n     <targetAttribute>st_gml32:Station_gml32</targetAttribute>\n     <idExpression>\n       <OCQL>ID</OCQL>\n     </idExpression>\n   </AttributeMapping>\n   <AttributeMapping>\n     <targetAttribute>st_gml32:name</targetAttribute>\n     <sourceExpression>\n       <OCQL>NAME</OCQL>\n     </sourceExpression>\n   </AttributeMapping>\n   <AttributeMapping>\n     <targetAttribute>st_gml32:location</targetAttribute>\n     <sourceExpression>\n       <OCQL>LOCATION</OCQL>\n     </sourceExpression>\n   </AttributeMapping>\n   <AttributeMapping>\n     <targetAttribute>st_gml32:maintainer</targetAttribute>\n     <jdbcMultipleValue>\n       <sourceColumn>ID</sourceColumn>\n       <targetTable>MAINTAINERS_GML32</targetTable>\n       <targetColumn>OWNER</targetColumn>\n     </jdbcMultipleValue>\n     <anonymousAttribute>\n       <name>st_gml32:name</name>\n       <value>NAME</value>\n     </anonymousAttribute>\n     <anonymousAttribute>\n       <name>st_gml32:level</name>\n       <value>LEVEL</value>\n     </anonymousAttribute>\n     <anonymousAttribute>\n       <name>st_gml32:classType</name>\n       <value>CLASSTYPE</value>\n     </anonymousAttribute>\n   </AttributeMapping>\n   <AttributeMapping>\n     <targetAttribute>st_gml32:measurements</targetAttribute>\n     <sourceExpression>\n       <OCQL>ID</OCQL>\n       <linkElement>ms_gml32:Measurement_gml32</linkElement>\n       <linkField>FEATURE_LINK[1]</linkField>\n     </sourceExpression>\n   </AttributeMapping>\n </attributeMappings>\n</FeatureTypeMapping>\n

                                                                    So Geoserver will produce GML like this :

                                                                    <st_gml32:Station_gml32 gml:id=\"st.2\">\n  <st_gml32:name>station2</st_gml32:name>\n  <st_gml32:location>\n    <gml:Point srsDimension=\"2\" srsName=\"urn:ogc:def:crs:EPSG::4326\">\n      <gml:pos>-3 -2</gml:pos>\n    </gml:Point>\n  </st_gml32:location>\n  <st_gml32:measurements>\n    <ms_gml32:Measurement_gml32 gml:id=\"ms.3\">\n      <ms_gml32:name>pressure</ms_gml32:name>\n      <ms_gml32:tag>pressure_tag</ms_gml32:tag>\n    </ms_gml32:Measurement_gml32>\n  </st_gml32:measurements>\n  <st_gml32:maintainer>\n    <st_gml32:name>mnt_c</st_gml32:name>\n    <st_gml32:level>73</st_gml32:level>\n    <st_gml32:classType>st_2_mnt_c</st_gml32:classType>\n    <st_gml32:name>mnt_d</st_gml32:name>\n    <st_gml32:level>74</st_gml32:level>\n    <st_gml32:classType>st_2_mnt_d</st_gml32:classType>\n    <st_gml32:name>mnt_e</st_gml32:name>\n    <st_gml32:level>75</st_gml32:level>\n    <st_gml32:classType>st_2_mnt_e</st_gml32:classType>\n  </st_gml32:maintainer>\n</st_gml32:Station_gml32>\n
                                                                    "},{"location":"data/app-schema/mapping-file/#apache-solr","title":"Apache Solr","text":"

                                                                    When using Apache Solr data stores, 1..N relationships can be handled with multiValued fields and mapped like this:

                                                                    (...)\n<AttributeMapping>\n  <targetAttribute>st:tag</targetAttribute>\n  <solrMultipleValue>TAG</solrMultipleValue>\n  <ClientProperty>\n    <name>st:code</name>\n    <value>CODE</value>\n  </ClientProperty>\n</AttributeMapping>\n(...)\n
                                                                    "},{"location":"data/app-schema/mapping-file/#external-apache-solr-index","title":"External Apache Solr Index","text":"

                                                                    Is possible to use an external Apache Solr index to speed up text based searches. Consider the following WFS GetFeatureRequest:

                                                                    <wfs:GetFeature service=\"WFS\" version=\"2.0.0\" xmlns:fes=\"http://www.opengis.net/fes/2.0\" xmlns:gml=\"http://www.opengis.net/gml/3.2.1\" xmlns:wfs=\"http://www.opengis.net/wfs/2.0\">\n  <wfs:Query typeNames=\"st:Station\">\n    <fes:Filter>\n      <fes:PropertyIsLike escapeChar=\"!\" singleChar=\".\" wildCard=\"*\">\n        <fes:ValueReference>st:Station/st:measurement/st:Measurement/st:description</fes:ValueReference>\n        <fes:Literal>*high*</fes:Literal>\n      </fes:PropertyIsLike>\n    </fes:Filter>\n  </wfs:Query>\n</wfs:GetFeature>\n

                                                                    This request will return all the stations that have at least one measurement that contains the text high in its description. This type of text based queries are (usually) quite expensive to execute in relational data bases.

                                                                    Apache Solr is a well known open source project that aims to solve those type of performance issues, it allow us to index several fields and efficiently query those fields. Although Apache Solr allow us to index several types of fields, e.g. numbers or even latitudes longitudes, where it really shines is when dealing with text fields and text based queries.

                                                                    The goal of external indexes is to allow App-Schema to take advantage of Apache Solr text searches performance and at the same time to take advantage of relational databases relational capabilities. In practice, this means that the full data will be stored in the relational database and we will only need to index in Apache Solr the fields we need to improve our text based queries.

                                                                    Using the stations use case as an example, our data will be stored in a relational database, e.g. PostgreSQL, and we will index the possible descriptions measurements values in an Apache Solr index.

                                                                    Our mapping file will look like this:

                                                                    <as:AppSchemaDataAccess xmlns:as=\"http://www.geotools.org/app-schema\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xsi:schemaLocation=\"http://www.geotools.org/app-schema AppSchemaDataAccess.xsd\">\n  <namespaces>\n    <Namespace>\n      <prefix>gml</prefix>\n      <uri>http://www.opengis.net/gml/3.2</uri>\n    </Namespace>\n    <Namespace>\n      <prefix>st</prefix>\n      <uri>http://www.stations.org/1.0</uri>\n    </Namespace>\n  </namespaces>\n  <sourceDataStores>\n    <SolrDataStore>\n      <id>stations_solr</id>\n      <url>http://localhost:8983/solr/stations_index</url>\n      <index name=\"stations_index\"/>\n    </SolrDataStore>\n    <DataStore>\n      <id>stations_db</id>\n      <parameters>\n        <Parameter>\n          <name>dbtype</name>\n          <value>postgisng</value>\n        </Parameter>\n      </parameters>\n    </DataStore>\n  </sourceDataStores>\n  <targetTypes>\n    <FeatureType>\n      <schemaUri>./stations.xsd</schemaUri>\n    </FeatureType>\n  </targetTypes>\n  <typeMappings>\n    <FeatureTypeMapping>\n      <sourceDataStore>stations_db</sourceDataStore>\n      <sourceType>stations</sourceType>\n      <targetElement>st:Station</targetElement>\n      <!-- configure the index data store for this feature type -->\n      <indexDataStore>stations_solr</indexDataStore>\n      <indexType>stations_index</indexType>\n      <attributeMappings>\n        <AttributeMapping>\n          <targetAttribute>st:Station</targetAttribute>\n          <idExpression>\n            <OCQL>id</OCQL>\n          </idExpression>\n          <!-- the Solr index field that matches this feature type table primary key -->\n          <indexField>id</indexField>\n        </AttributeMapping>\n        <AttributeMapping>\n          <targetAttribute>st:name</targetAttribute>\n          <sourceExpression>\n            <OCQL>name</OCQL>\n          </sourceExpression>\n        </AttributeMapping>\n        <AttributeMapping>\n          <targetAttribute>st:measurement</targetAttribute>\n          <sourceExpression>\n            <OCQL>id</OCQL>\n            <linkElement>st:Measurement</linkElement>\n            <linkField>FEATURE_LINK[1]</linkField>\n          </sourceExpression>\n          <isMultiple>true</isMultiple>\n        </AttributeMapping>\n      </attributeMappings>\n    </FeatureTypeMapping>\n    <FeatureTypeMapping>\n      <sourceDataStore>stations_db</sourceDataStore>\n      <sourceType>measurements</sourceType>\n      <targetElement>st:Measurement</targetElement>\n      <attributeMappings>\n        <AttributeMapping>\n          <targetAttribute>st:Measurement</targetAttribute>\n          <idExpression>\n            <OCQL>id</OCQL>\n          </idExpression>\n        </AttributeMapping>\n        <AttributeMapping>\n          <targetAttribute>st:description</targetAttribute>\n          <sourceExpression>\n            <OCQL>description</OCQL>\n          </sourceExpression>\n          <!-- the Solr index field that indexes the description possible values -->\n          <indexField>description_txt</indexField>\n        </AttributeMapping>\n        <AttributeMapping>\n          <targetAttribute>FEATURE_LINK[1]</targetAttribute>\n          <sourceExpression>\n            <OCQL>station_id</OCQL>\n          </sourceExpression>\n        </AttributeMapping>\n      </attributeMappings>\n    </FeatureTypeMapping>\n  </typeMappings>\n</as:AppSchemaDataAccess>\n

                                                                    To be able to use an external Apache Solr index, we need at least to:

                                                                    • declare the Solr data store and the index: this is done in the root feature type mapping, e.g. st:Station.
                                                                    • map the Solr index field that matches the database primary key: this is done id mapping of the root feature type, e.g.<indexField>id</indexField>.
                                                                    • map each attribute that is indexed in Apache Solr: this is done using the indexField element, e.g <indexField>description_txt</indexField>.

                                                                    Is worth mentioning that if an external Solr index was defined, App-Schema will always query the external Solr index first and then query the relational database.

                                                                    "},{"location":"data/app-schema/mongo-tutorial/","title":"MongoDB Tutorial","text":"

                                                                    This tutorial demonstrates how to use app-schema plugin with a MongoDB data store. This tutorial will focus on the MongoDB data store specificities is highly recommended to read the app-schema documentation before.

                                                                    "},{"location":"data/app-schema/mongo-tutorial/#use-case","title":"Use Case","text":"

                                                                    The use case for this tutorial will be to serve through app-schema the information about some meteorological stations stored in a MongoDB database. Note that this use case is completely fictional and only used to demonstrate the MongoDB and app-schema integration.

                                                                    First of all let's insert some test data in a MongoDB data store:

                                                                    db.stations.insert({\n    \"id\": \"1\",\n    \"name\": \"station 1\",\n    \"contact\": {\n        \"mail\": \"station1@mail.com\"\n    },\n    \"geometry\": {\n        \"coordinates\": [\n            50,\n            60\n        ],\n        \"type\": \"Point\"\n    },\n    \"measurements\": [\n        {\n            \"name\": \"temp\",\n            \"unit\": \"c\",\n            \"values\": [\n                {\n                    \"time\": 1482146800,\n                    \"value\": 20\n                }\n            ]\n        },\n        {\n            \"name\": \"wind\",\n            \"unit\": \"km/h\",\n            \"values\": [\n                {\n                    \"time\": 1482146833,\n                    \"value\": 155\n                }\n            ]\n        }\n    ]\n})\n\ndb.stations.insert({\n    \"id\": \"2\",\n    \"name\": \"station 2\",\n    \"contact\": {\n        \"mail\": \"station2@mail.com\"\n    },\n    \"geometry\": {\n        \"coordinates\": [\n            100,\n            -50\n        ],\n        \"type\": \"Point\"\n    },\n    \"measurements\": [\n        {\n            \"name\": \"temp\",\n            \"unit\": \"c\",\n            \"values\": [\n                {\n                    \"time\": 1482146911,\n                    \"value\": 35\n                },\n                {\n                    \"time\": 1482146935,\n                    \"value\": 25\n                }\n            ]\n        },\n        {\n            \"name\": \"wind\",\n            \"unit\": \"km/h\",\n            \"values\": [\n                {\n                    \"time\": 1482146964,\n                    \"value\": 80\n                }\n            ]\n        },\n        {\n            \"name\": \"pression\",\n            \"unit\": \"pa\",\n            \"values\": [\n                {\n                    \"time\": 1482147026,\n                    \"value\": 1019\n                },\n                {\n                    \"time\": 1482147051,\n                    \"value\": 1015\n                }\n            ]\n        }\n    ]\n})\n\ndb.stations.createIndex({\n    \"geometry\": \"2dsphere\"\n})\n

                                                                    This is the schema that will be used to do the mappings in app-schema:

                                                                    <xs:schema version=\"1.0\" xmlns:xs=\"http://www.w3.org/2001/XMLSchema\"\n           xmlns:gml=\"http://www.opengis.net/gml\"\n           xmlns:st=\"http://www.stations.org/1.0\"\n           targetNamespace=\"http://www.stations.org/1.0\"\n           elementFormDefault=\"qualified\" attributeFormDefault=\"unqualified\">\n\n  <xs:import namespace=\"http://www.opengis.net/gml\"\n             schemaLocation=\"http://schemas.opengis.net/gml/3.2.1/gml.xsd\"/>\n\n  <xs:complexType name=\"ContactType\">\n    <xs:sequence>\n      <xs:element name=\"mail\" minOccurs=\"0\" maxOccurs=\"1\" type=\"xs:string\"/>\n    </xs:sequence>\n  </xs:complexType>\n\n  <xs:complexType name=\"MeasurementPropertyType\">\n    <xs:sequence minOccurs=\"0\">\n      <xs:element ref=\"st:Measurement\"/>\n    </xs:sequence>\n    <xs:attributeGroup ref=\"gml:AssociationAttributeGroup\"/>\n  </xs:complexType>\n\n  <xs:complexType name=\"MeasurementType\" abstract=\"true\">\n    <xs:sequence>\n      <xs:element name=\"name\" minOccurs=\"1\" maxOccurs=\"1\" type=\"xs:string\"/>\n      <xs:element name=\"unit\" minOccurs=\"1\" maxOccurs=\"1\" type=\"xs:string\"/>\n      <xs:element name=\"values\" minOccurs=\"1\" maxOccurs=\"unbounded\" type=\"st:ValuePropertyType\"/>\n    </xs:sequence>\n  </xs:complexType>\n\n  <xs:complexType name=\"ValuePropertyType\">\n    <xs:sequence minOccurs=\"0\">\n      <xs:element ref=\"st:Value\"/>\n    </xs:sequence>\n    <xs:attributeGroup ref=\"gml:AssociationAttributeGroup\"/>\n  </xs:complexType>\n\n  <xs:complexType name=\"ValueType\">\n    <xs:sequence>\n      <xs:element name=\"timestamp\" minOccurs=\"1\" maxOccurs=\"1\" type=\"xs:long\"/>\n      <xs:element name=\"value\" minOccurs=\"1\" maxOccurs=\"1\" type=\"xs:double\"/>\n    </xs:sequence>\n  </xs:complexType>\n\n  <xs:complexType name=\"StationFeatureType\">\n    <xs:complexContent>\n      <xs:extension base=\"gml:AbstractFeatureType\">\n        <xs:sequence>\n          <xs:element name=\"name\" minOccurs=\"1\" maxOccurs=\"1\" type=\"xs:string\"/>\n          <xs:element name=\"contact\" minOccurs=\"0\" maxOccurs=\"1\" type=\"st:ContactType\"/>\n          <xs:element name=\"measurement\" minOccurs=\"0\" maxOccurs=\"unbounded\" type=\"st:MeasurementPropertyType\"/>\n          <xs:element name=\"geometry\" type=\"gml:GeometryPropertyType\" minOccurs=\"0\" maxOccurs=\"1\"/>\n        </xs:sequence>\n      </xs:extension>\n    </xs:complexContent>\n  </xs:complexType>\n\n  <xs:element name=\"StationFeature\" type=\"st:StationFeatureType\"  substitutionGroup=\"gml:_Feature\"/>\n  <xs:element name=\"Measurement\" type=\"st:MeasurementType\"  substitutionGroup=\"gml:_Feature\"/>\n  <xs:element name=\"Value\" type=\"st:ValueType\"  substitutionGroup=\"gml:_Feature\"/>\n\n</xs:schema>\n
                                                                    "},{"location":"data/app-schema/mongo-tutorial/#mappings","title":"Mappings","text":""},{"location":"data/app-schema/mongo-tutorial/#mongodb-store","title":"MongoDB Store","text":"

                                                                    When configuring app-schema mappings for a MongoDB source some connection parameters tweaks might be needed, in order to ensure that the full set of recognized and made available to the mapping. The setup of a MongoDB Store implies the creation of a Mongo schema, inferred from the db collection. This process by default will use a random Mongo object from the collection. If that object doesn't contain all attributes of interest, the result will be an incomplete schema. This behaviour can thus be controlled by means of the following two parameters, which should be provided inside the <parameters> element under the <DataStore> node:

                                                                    • objs_id_schema, which specifies a comma separated list of MongoDB JSON object to be used to build the schema (not needed if max_objs_schema is present).
                                                                    <Parameter>\n  <name>objs_id_schema</name>\n  <value>6eb85d889396eb0475f815ef,6eb85d889396eb0475f815eg</value>\n</Parameter>\n
                                                                    • max_objs_schema, which specifies the max number of MongoDB JSON object to be used to build the schema and where a value of -1 means all the objects present in the collection (not needed if objs_id_schema is present).
                                                                    <Parameter>\n  <name>max_objs_schema</name>\n  <value>-1</value>\n</Parameter>\n

                                                                    Both parameters can also be specified via the REST API, see Cleaning schemas on internal MongoDB stores for more details.

                                                                    "},{"location":"data/app-schema/mongo-tutorial/#nested-elements","title":"Nested elements","text":"

                                                                    MongoDB objects may contain nested elements and nested collections. The following three functions make possible to select nested elements and link nested collections using a JSON path:

                                                                    Function Example Description jsonSelect jsonSelect('contact.mail') Used to retrieve the value for the mapping from a MongoDB object. collectionLink collectionLink('measurements.values') Used when chaining entities with a nested collection. collectionId collectionId() Instructs the mapper to generate a ID for the nested collection. nestedCollectionLink nestedCollectionLink() Used on the nested collection to create a link with the parent feature."},{"location":"data/app-schema/mongo-tutorial/#mappings-file-example","title":"Mappings file example","text":"

                                                                    A station data is composed of some meta-information about the station and a list of measurements. Each measurement as some meta-information and contains a list of values. The mappings will contain three top entities: the station, the measurements and the values.

                                                                    Follows a the complete mappings file:

                                                                    <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<as:AppSchemaDataAccess xmlns:as=\"http://www.geotools.org/app-schema\"\n                      xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\"\n                      xsi:schemaLocation=\"http://www.geotools.org/app-schema AppSchemaDataAccess.xsd\">\n<namespaces>\n  <Namespace>\n    <prefix>st</prefix>\n    <uri>http://www.stations.org/1.0</uri>\n  </Namespace>\n  <Namespace>\n    <prefix>gml</prefix>\n    <uri>http://www.opengis.net/gml</uri>\n  </Namespace>\n</namespaces>\n\n<sourceDataStores>\n  <DataStore>\n    <id>data_source</id>\n    <parameters>\n      <Parameter>\n        <name>data_store</name>\n        <value>mongodb://{mongoHost}:{mongoPort}/{dataBaseName}</value>\n      </Parameter>\n      <Parameter>\n        <name>namespace</name>\n        <value>http://www.stations.org/1.0</value>\n      </Parameter>\n      <Parameter>\n        <name>schema_store</name>\n        <value>file:{schemaStore}</value>\n      </Parameter>\n      <Parameter>\n        <name>data_store_type</name>\n        <value>complex</value>\n      </Parameter>\n      <Parameter>\n          <name>max_objs_schema</name>\n          <value>-1</value>\n      </Parameter>\n    </parameters>\n  </DataStore>\n</sourceDataStores>\n\n<targetTypes>\n  <FeatureType>\n    <schemaUri>stations.xsd</schemaUri>\n  </FeatureType>\n</targetTypes>\n\n<typeMappings>\n  <FeatureTypeMapping>\n    <sourceDataStore>data_source</sourceDataStore>\n    <sourceType>{collectionName}</sourceType>\n    <targetElement>st:StationFeature</targetElement>\n    <attributeMappings>\n      <AttributeMapping>\n        <targetAttribute>st:StationFeature</targetAttribute>\n        <idExpression>\n          <OCQL>jsonSelect('id')</OCQL>\n        </idExpression>\n      </AttributeMapping>\n      <AttributeMapping>\n        <targetAttribute>st:name</targetAttribute>\n        <sourceExpression>\n          <OCQL>jsonSelect('name')</OCQL>\n        </sourceExpression>\n      </AttributeMapping>\n      <AttributeMapping>\n        <targetAttribute>st:contact/st:mail</targetAttribute>\n        <sourceExpression>\n          <OCQL>jsonSelect('contact.mail')</OCQL>\n        </sourceExpression>\n      </AttributeMapping>\n      <AttributeMapping>\n        <targetAttribute>st:measurement</targetAttribute>\n        <sourceExpression>\n          <OCQL>collectionLink('measurements')</OCQL>\n          <linkElement>aaa</linkElement>\n          <linkField>FEATURE_LINK[1]</linkField>\n        </sourceExpression>\n        <isMultiple>true</isMultiple>\n      </AttributeMapping>\n      <AttributeMapping>\n        <targetAttribute>st:geometry</targetAttribute>\n        <sourceExpression>\n          <OCQL>jsonSelect('geometry')</OCQL>\n        </sourceExpression>\n      </AttributeMapping>\n    </attributeMappings>\n  </FeatureTypeMapping>\n  <FeatureTypeMapping>\n    <sourceDataStore>data_source</sourceDataStore>\n    <sourceType>{collectionName}</sourceType>\n    <mappingName>aaa</mappingName>\n    <targetElement>st:Measurement</targetElement>\n    <attributeMappings>\n      <AttributeMapping>\n        <targetAttribute>st:Measurement</targetAttribute>\n        <idExpression>\n          <OCQL>collectionId()</OCQL>\n        </idExpression>\n      </AttributeMapping>\n      <AttributeMapping>\n        <targetAttribute>st:name</targetAttribute>\n        <sourceExpression>\n          <OCQL>jsonSelect('name')</OCQL>\n        </sourceExpression>\n      </AttributeMapping>\n      <AttributeMapping>\n        <targetAttribute>st:unit</targetAttribute>\n        <sourceExpression>\n          <OCQL>jsonSelect('unit')</OCQL>\n        </sourceExpression>\n      </AttributeMapping>\n      <AttributeMapping>\n        <targetAttribute>st:values</targetAttribute>\n        <sourceExpression>\n          <OCQL>collectionLink('values')</OCQL>\n          <linkElement>st:Value</linkElement>\n          <linkField>FEATURE_LINK[2]</linkField>\n        </sourceExpression>\n        <isMultiple>true</isMultiple>\n      </AttributeMapping>\n      <AttributeMapping>\n        <targetAttribute>FEATURE_LINK[1]</targetAttribute>\n        <sourceExpression>\n          <OCQL>nestedCollectionLink()</OCQL>\n        </sourceExpression>\n      </AttributeMapping>\n    </attributeMappings>\n  </FeatureTypeMapping>\n  <FeatureTypeMapping>\n    <sourceDataStore>data_source</sourceDataStore>\n    <sourceType>{collectionName}</sourceType>\n    <targetElement>st:Value</targetElement>\n    <attributeMappings>\n      <AttributeMapping>\n        <targetAttribute>st:Value</targetAttribute>\n        <idExpression>\n          <OCQL>collectionId()</OCQL>\n        </idExpression>\n      </AttributeMapping>\n      <AttributeMapping>\n        <targetAttribute>st:timestamp</targetAttribute>\n        <sourceExpression>\n          <OCQL>jsonSelect('time')</OCQL>\n        </sourceExpression>\n      </AttributeMapping>\n      <AttributeMapping>\n        <targetAttribute>st:value</targetAttribute>\n        <sourceExpression>\n          <OCQL>jsonSelect('value')</OCQL>\n        </sourceExpression>\n      </AttributeMapping>\n      <AttributeMapping>\n        <targetAttribute>FEATURE_LINK[2]</targetAttribute>\n        <sourceExpression>\n          <OCQL>nestedCollectionLink()</OCQL>\n        </sourceExpression>\n      </AttributeMapping>\n    </attributeMappings>\n  </FeatureTypeMapping>\n</typeMappings>\n\n</as:AppSchemaDataAccess>\n

                                                                    The mappings for the attributes are straightforward, for example the following mapping:

                                                                    <AttributeMapping>\n    <targetAttribute>st:contact/st:mail</targetAttribute>\n    <sourceExpression>\n        <OCQL>jsonSelect('contact.mail')</OCQL>\n    </sourceExpression>\n</AttributeMapping>\n

                                                                    The mapping above defines that the contact mail for a station will be available at the JSON path contact.mail and that the correspondent XML schema element is the XPATH st:contact/st:mail.

                                                                    The feature chaining is a little bit more complex. Let's take as an example the chaining between StationFeature and Measurement features. In the StationFeature feature type the link to the Measurement entity is defined with the following mapping:

                                                                    <AttributeMapping>\n    <targetAttribute>st:measurement</targetAttribute>\n    <sourceExpression>\n        <OCQL>collectionLink('measurements')</OCQL>\n        <linkElement>st:Measurement</linkElement>\n        <linkField>FEATURE_LINK[1]</linkField>\n    </sourceExpression>\n    <isMultiple>true</isMultiple>\n</AttributeMapping>\n

                                                                    and in the Measurement feature type the link to the parent feature is defined with the following mapping:

                                                                    <AttributeMapping>\n    <targetAttribute>FEATURE_LINK[1]</targetAttribute>\n    <sourceExpression>\n        <OCQL>nestedCollectionLink()</OCQL>\n    </sourceExpression>\n</AttributeMapping>\n

                                                                    With the two mapping above we tie the two features types together. When working with a MongoDB data store this mappings will always be petty much the same, only the nested collection path and the feature link index need to be updated. Note that the JSON path of the nested collections attributes are relative to the parent.

                                                                    "},{"location":"data/app-schema/mongo-tutorial/#querying","title":"Querying","text":"

                                                                    To create an MongoDB app-schema layer in GeoServer, the app-schema extension and the mongo-complex extension needs to be installed.

                                                                    A workspace for each name space declared in the mappings file needs to be created, in this case the workspace st with URI http://www.stations.org/1.0 needs to be created. No need to create a gml workspace.

                                                                    Creating a MongoDB app-schema layer is similar to any other app-schema layer, just create an app-schema store pointing to the correct mappings file and select the layer correspondent to the top entity, in this case st:StationFeature.

                                                                    Is possible to query with WFS complex features encoded in GML and GeoJson using complex features filtering capabilities. For example, querying all the stations that have a measurement value with a time stamp superior to 1482146964:

                                                                    <wfs:Query typeName=\"st:StationFeature\">\n    <ogc:Filter>\n        <ogc:Filter>\n            <ogc:PropertyIsGreaterThan>\n                    <ogc:PropertyName>  \n                        st:StationFeature/st:measurement/st:values/st:timestamp\n                    </ogc:PropertyName>\n                    <ogc:Literal>\n                        1482146964\n                    </ogc:Literal>\n                </ogc:PropertyIsGreaterThan>\n        </ogc:Filter>\n    </ogc:Filter>\n</wfs:Query>\n
                                                                    "},{"location":"data/app-schema/polymorphism/","title":"Polymorphism","text":"

                                                                    Polymorphism in this context refers to the ability of an attribute to have different forms. Depending on the source value, it could be encoded with a specific structure, type, as an xlink:href reference, or not encoded at all. To achieve this, we reuse feature chaining syntax and allow OCQL functions in the linkElement tag. Read more about app-schema.feature-chaining, if you're not familiar with the syntax.

                                                                    "},{"location":"data/app-schema/polymorphism/#data-type-polymorphism","title":"Data-type polymorphism","text":"

                                                                    You can use normal feature chaining to get an attribute to be encoded as a certain type. For example:

                                                                    <AttributeMapping>                                                                                                                                                                                                                                                                                                                                                                                                    \n    <targetAttribute>ex:someAttribute</targetAttribute>\n    <sourceExpression>\n        <OCQL>VALUE_ID</OCQL>\n      <linkElement>NumericType</linkElement>\n      <linkField>FEATURE_LINK</linkField>\n    </sourceExpression>\n</AttributeMapping>\n<AttributeMapping>\n    <targetAttribute>ex:someAttribute</targetAttribute>\n    <sourceExpression>\n      <OCQL>VALUE_ID</OCQL>\n      <linkElement>gsml:CGI_TermValue</linkElement>\n      <linkField>FEATURE_LINK</linkField>\n    </sourceExpression>\n</AttributeMapping>\n

                                                                    Note: NumericType here is a mappingName, whereas gsml:CGI_TermValue is a targetElement.

                                                                    In the above example, ex:someAttribute would be encoded with the configuration in NumericType if the foreign key matches the linkField. Both instances would be encoded if the foreign key matches the candidate keys in both linked configurations. Therefore this would only work for 0 to many relationships.

                                                                    Functions can be used for single attribute instances. See useful functions for a list of commonly used functions. Specify the function in the linkElement, and it would map it to the first matching FeatureTypeMapping. For example:

                                                                    <AttributeMapping>\n    <targetAttribute>ex:someAttribute</targetAttribute>   \n    <sourceExpression>\n      <OCQL>VALUE_ID</OCQL>   \n      <linkElement>\n        Recode(CLASS_TEXT, 'numeric', 'NumericType', 'literal', 'gsml:CGI_TermValue')\n        </linkElement>\n      <linkField>FEATURE_LINK</linkField>\n    </sourceExpression>                   \n    <isMultiple>true</isMultiple>\n</AttributeMapping>\n

                                                                    The above example means, if the CLASS_TEXT value is 'numeric', it would link to 'NumericType' FeatureTypeMapping, with VALUE_ID as foreign key to the linked type. It would require all the potential matching types to have a common attribute that is specified in linkField. In this example, the linkField is FEATURE_LINK, which is a fake attribute used only for feature chaining. You can omit the linkField and OCQL if the FeatureTypeMapping being linked to has the same sourceType with the container type. This would save us from unnecessary extra queries, which would affect performance. For example:

                                                                    FeatureTypeMapping of the container type:

                                                                    <FeatureTypeMapping>\n    <sourceDataStore>PropertyFiles</sourceDataStore>\n    <sourceType>PolymorphicFeature</sourceType>\n

                                                                    FeatureTypeMapping of NumericType points to the same table:

                                                                    <FeatureTypeMapping>\n    <mappingName>NumericType</mappingName>\n    <sourceDataStore>PropertyFiles</sourceDataStore>\n    <sourceType>PolymorphicFeature</sourceType>\n

                                                                    FeatureTypeMapping of gsml:CGI_TermValue also points to the same table:

                                                                    <FeatureTypeMapping>\n    <sourceDataStore>PropertyFiles</sourceDataStore>\n    <sourceType>PolymorphicFeature</sourceType>\n    <targetElement>gsml:CGI_TermValue</targetElement>\n

                                                                    In this case, we can omit linkField in the polymorphic attribute mapping:

                                                                    <AttributeMapping>\n    <targetAttribute>ex:someAttribute</targetAttribute>   \n    <sourceExpression>\n      <linkElement>\n        Recode(CLASS_TEXT, 'numeric', 'NumericType', 'literal', 'gsml:CGI_TermValue')\n        </linkElement>\n    </sourceExpression>                   \n    <isMultiple>true</isMultiple>\n</AttributeMapping>\n
                                                                    "},{"location":"data/app-schema/polymorphism/#referential-polymorphism","title":"Referential polymorphism","text":"

                                                                    This is when an attribute is set to be encoded as an xlink:href reference on the top level. When the scenario only has reference cases in it, setting a function in Client Property will do the job. E.g.:

                                                                    <AttributeMapping>\n  <targetAttribute>ex:someAttribute</targetAttribute>\n  <ClientProperty>\n    <name>xlink:href</name>\n    <value>if_then_else(isNull(NUMERIC_VALUE), 'urn:ogc:def:nil:OGC:1.0:missing', strConcat('#', NUMERIC_VALUE))</value>\n    </ClientProperty>\n</AttributeMapping>\n

                                                                    The above example means, if NUMERIC_VALUE is null, the attribute should be encoded as:

                                                                    <ex:someAttribute xlink:href=\"urn:ogc:def:nil:OGC:1.0:missing\">\n

                                                                    Otherwise, it would be encoded as:

                                                                    <ex:someAttribute xlink:href=\"#123\">\n    where NUMERIC_VALUE = '123'\n

                                                                    However, this is not possible when we have cases where a fully structured attribute is also a possibility. The toxlinkhref function can be used for this scenario. E.g.:

                                                                    <AttributeMapping>\n    <targetAttribute>ex:someAttribute</targetAttribute> \n    <sourceExpression>\n      <linkElement>\n        if_then_else(isNull(NUMERIC_VALUE), toXlinkHref('urn:ogc:def:nil:OGC:1.0:missing'), \n              if_then_else(lessEqualThan(NUMERIC_VALUE, 1000), 'numeric_value', toXlinkHref('urn:ogc:def:nil:OGC:1.0:missing'))) \n        </linkElement>\n    </sourceExpression> \n</AttributeMapping>\n

                                                                    The above example means, if NUMERIC_VALUE is null, the output would be encoded as:

                                                                    <ex:someAttribute xlink:href=\"urn:ogc:def:nil:OGC:1.0:missing\">\n

                                                                    Otherwise, if NUMERIC_VALUE is less or equal than 1000, it would be encoded with attributes from FeatureTypeMapping with 'numeric_value' mappingName. If NUMERIC_VALUE is greater than 1000, it would be encoded as the first scenario.

                                                                    "},{"location":"data/app-schema/polymorphism/#useful-functions","title":"Useful functions","text":""},{"location":"data/app-schema/polymorphism/#if_then_else-function","title":"if_then_else function","text":"

                                                                    Syntax:

                                                                    if_then_else(BOOLEAN_EXPRESSION, value, default value)\n
                                                                    • BOOLEAN_EXPRESSION: could be a Boolean column value, or a Boolean function
                                                                    • value: the value to map to, if BOOLEAN_EXPRESSION is true
                                                                    • default value: the value to map to, if BOOLEAN_EXPRESSION is false
                                                                    "},{"location":"data/app-schema/polymorphism/#recode-function","title":"Recode function","text":"

                                                                    Syntax:

                                                                    Recode(EXPRESSION, key1, value1, key2, value2,...)\n
                                                                    • EXPRESSION: column name to get values from, or another function

                                                                    • key-n:
                                                                      • key expression to map to value-n
                                                                      • if the evaluated value of EXPRESSION doesn't match any key, nothing would be encoded for the attribute.
                                                                    • value-n: value expression which translates to a mappingName or targetElement

                                                                    "},{"location":"data/app-schema/polymorphism/#lessequalthan","title":"lessEqualThan","text":"

                                                                    Returns true if ATTRIBUTE_EXPRESSION evaluates to less or equal than LIMIT_EXPRESSION.

                                                                    Syntax:

                                                                    lessEqualThan(ATTRIBUTE_EXPRESSION, LIMIT_EXPRESSION)\n
                                                                    • ATTRIBUTE_EXPRESSION: expression of the attribute being evaluated.
                                                                    • LIMIT_EXPRESSION: expression of the numeric value to be compared against.
                                                                    "},{"location":"data/app-schema/polymorphism/#lessthan","title":"lessThan","text":"

                                                                    Returns true if ATTRIBUTE_EXPRESSION evaluates to less than LIMIT_EXPRESSION.

                                                                    Syntax:

                                                                    lessThan(ATTRIBUTE_EXPRESSION, LIMIT_EXPRESSION)\n
                                                                    • ATTRIBUTE_EXPRESSION: expression of the attribute being evaluated.
                                                                    • LIMIT_EXPRESSION: expression of the numeric value to be compared against.
                                                                    "},{"location":"data/app-schema/polymorphism/#equalto","title":"equalTo","text":"

                                                                    Compares two expressions and returns true if they're equal.

                                                                    Syntax:

                                                                    equalTo(LHS_EXPRESSION, RHS_EXPRESSION)\n
                                                                    "},{"location":"data/app-schema/polymorphism/#isnull","title":"isNull","text":"

                                                                    Returns a Boolean that is true if the expression evaluates to null.

                                                                    Syntax:

                                                                    isNull(EXPRESSION)\n
                                                                    • EXPRESSION: expression to be evaluated.
                                                                    "},{"location":"data/app-schema/polymorphism/#toxlinkhref","title":"toXlinkHref","text":"

                                                                    Special function written for referential polymorphism and feature chaining, not to be used outside of linkElement. It infers that the attribute should be encoded as xlink:href.

                                                                    Syntax:

                                                                    toXlinkHref(XLINK_HREF_EXPRESSION)\n
                                                                    • XLINK_HREF_EXPRESSION:
                                                                      • could be a function or a literal
                                                                      • has to be wrapped in single quotes if it's a literal

                                                                    Note

                                                                    • To get toXlinkHref function working, you need to declare xlink URI in the namespaces.
                                                                    "},{"location":"data/app-schema/polymorphism/#other-functions","title":"Other functions","text":"

                                                                    Please refer to Filter Function Reference.

                                                                    "},{"location":"data/app-schema/polymorphism/#combinations","title":"Combinations","text":"

                                                                    You can combine functions, but it might affect performance. E.g.:

                                                                    if_then_else(isNull(NUMERIC_VALUE), toXlinkHref('urn:ogc:def:nil:OGC:1.0:missing'), \n    if_then_else(lessEqualThan(NUMERIC_VALUE, 1000), 'numeric_value', toXlinkHref('urn:ogc:def:nil:OGC:1.0:missing')))\n

                                                                    Note

                                                                    • When specifying a mappingName or targetElement as a value in functions, make sure they're enclosed in single quotes. * Some functions have no null checking, and will fail when they encounter null. * The workaround for this is to wrap the expression with isNull() function if null is known to exist in the data set.
                                                                    "},{"location":"data/app-schema/polymorphism/#null-or-missing-value","title":"Null or missing value","text":"

                                                                    To skip the attribute for a specific case, you can use Expression.NIL as a value in if_then_else or not include the key in Recode function . E.g.:

                                                                    if_then_else(isNull(VALUE), Expression.NIL, 'gsml:CGI_TermValue')\n    means the attribute would not be encoded if VALUE is null.\n\nRecode(VALUE, 'term_value', 'gsml:CGI_TermValue')\n    means the attribute would not be encoded if VALUE is anything but 'term_value'.\n

                                                                    To encode an attribute as xlink:href that represents missing value on the top level, see Referential Polymorphism.

                                                                    "},{"location":"data/app-schema/polymorphism/#any-type","title":"Any type","text":"

                                                                    Having xs:anyType as the attribute type itself infers that it is polymorphic, since they can be encoded as any type.

                                                                    If the type is pre-determined and would always be the same, we might need to specify app-schema.mapping-file.targetAttributeNode. E.g.:

                                                                    <AttributeMapping>\n      <targetAttribute>om:result</targetAttribute>\n      <targetAttributeNode>gml:MeasureType<targetAttributeNode>\n      <sourceExpression>\n          <OCQL>TOPAGE</OCQL>\n      </sourceExpression>\n      <ClientProperty>\n          <name>xsi:type</name>\n          <value>'gml:MeasureType'</value>\n      </ClientProperty>\n      <ClientProperty>\n          <name>uom</name> \n          <value>'http://www.opengis.net/def/uom/UCUM/0/Ma'</value>\n      </ClientProperty> \n</AttributeMapping>\n

                                                                    If the casting type is complex, this is not a requirement as app-schema is able to automatically determine the type from the XPath in targetAttribute. E.g., in this example om:result is automatically specialised as a MappedFeatureType:

                                                                    <AttributeMapping>\n      <targetAttribute>om:result/gsml:MappedFeature/gml:name</targetAttribute>\n      <sourceExpression>\n          <OCQL>NAME</OCQL>\n      </sourceExpression>\n</AttributeMapping>\n

                                                                    Alternatively, we can use feature chaining. For the same example above, the mapping would be:

                                                                    <AttributeMapping>\n  <targetAttribute>om:result</targetAttribute>\n  <sourceExpression>\n    <OCQL>LEX_D</OCQL>\n    <linkElement>gsml:MappedFeature</linkElement>\n    <linkField>gml:name</linkField>\n  </sourceExpression>\n</AttributeMapping>\n

                                                                    If the type is conditional, the mapping style for such attributes is the same as any other polymorphic attributes. E.g.:

                                                                    <AttributeMapping>\n  <targetAttribute>om:result</targetAttribute>\n  <sourceExpression>\n    <linkElement>\n       Recode(NAME, Expression.Nil, toXlinkHref('urn:ogc:def:nil:OGC::missing'),'numeric',\n               toXlinkHref(strConcat('urn:numeric-value::', NUMERIC_VALUE)), 'literal', 'TermValue2')\n    </linkElement>\n  </sourceExpression>\n</AttributeMapping>\n
                                                                    "},{"location":"data/app-schema/polymorphism/#filters","title":"Filters","text":"

                                                                    Filters should work as usual, as long as the users know what they want to filter. For example, when an attribute could be encoded as gsml:CGI_TermValue or gsml:CGI_NumericValue, users can run filters with property names of:

                                                                    • ex:someAttribute/gsml:CGI_TermValue/gsml:value to return matching attributes that are encoded as gsml:CGI_TermValue and satisfy the filter.
                                                                    • likewise, ex:someAttribute/gsml:CGI_NumericValue/gsml:principalValue should return matching gsml:CGI_NumericValue attributes.

                                                                    Another limitation is filtering attributes of an xlink:href attribute pointing to an instance outside of the document.

                                                                    "},{"location":"data/app-schema/property-interpolation/","title":"Property Interpolation","text":"

                                                                    Interpolation in this context means the substitution of variables into strings. GeoServer app-schema supports the interpolation of properties (the Java equivalent of environment variables) into app-schema mapping files. This can be used, for example, to simplify the management of database connection parameters that would otherwise be hardcoded in a particular mapping file. This enables data directories to be given to third parties without inapplicable authentication or system configuration information. Externalising these parameters make management easier.

                                                                    "},{"location":"data/app-schema/property-interpolation/#defining-properties","title":"Defining properties","text":"
                                                                    • If the system property app-schema.properties is not set, properties are loaded from WEB-INF/classes/app-schema.properties (or another resource /app-schema.properties on the classpath).

                                                                    • If the system property app-schema.properties is set, properties are loaded from the file named as the value of the property. This is principally intended for debugging, and is designed to be used in an Eclipse launch configuration.

                                                                      • For example, if the JVM is started with -Dapp-schema.properties=/path/to/some/local.properties, properties are loaded from /path/to/some/local.properties.
                                                                    • System properties override properties defined in a configuration file, so if you define -Dsome.property at the java command line, it will override a value specified in the app-schema.properties file. This is intended for debugging, so you can set a property file in an Eclipse launch configuration, but override some of the properties contained in the file by setting them explicitly as system properties.

                                                                    • All system properties are available for interpolation in mapping files.

                                                                    "},{"location":"data/app-schema/property-interpolation/#predefined-properties","title":"Predefined properties","text":"

                                                                    If not set elsewhere, the following properties are set for each mapping file:

                                                                    • config.file is set to the name of the mapping file
                                                                    • config.parent is set to the name of the directory containing the mapping file
                                                                    "},{"location":"data/app-schema/property-interpolation/#using-properties","title":"Using properties","text":"
                                                                    • Using ${some.property} anywhere in the mapping file will cause it to be replaced by the value of the property some.property.
                                                                    • It is an error for a property that has not been set to be used for interpolation.
                                                                    • Interpolation is performed repeatedly, so values can contain new interpolations. Use this behaviour with caution because it may cause an infinite loop.
                                                                    • Interpolation is performed before XML parsing, so can be used to include arbitrary chunks of XML.
                                                                    "},{"location":"data/app-schema/property-interpolation/#example-of-property-interpolation","title":"Example of property interpolation","text":"

                                                                    This example defines an Oracle data store, where the connection parameter are interpolated from properties:

                                                                    <sourceDataStores>\n    <DataStore>\n        <id>datastore</id>\n        <parameters>\n            <Parameter>\n                <name>dbtype</name>\n                <value>Oracle</value>\n            </Parameter>\n            <Parameter>\n                <name>host</name>\n                <value>${example.host}</value>\n            </Parameter>\n            <Parameter>\n                <name>port</name>\n                <value>1521</value>\n            </Parameter>\n            <Parameter>\n                <name>database</name>\n                <value>${example.database}</value>\n            </Parameter>\n            <Parameter>\n                <name>user</name>\n                <value>${example.user}</value>\n            </Parameter>\n            <Parameter>\n                <name>passwd</name>\n                <value>${example.passwd}</value>\n            </Parameter>\n        </parameters>\n    </DataStore>\n</sourceDataStores>\n
                                                                    "},{"location":"data/app-schema/property-interpolation/#example-property-file","title":"Example property file","text":"

                                                                    This sample property file gives the property values that are interpolated into the mapping file fragment above. These properties can be installed in WEB-INF/classes/app-schema.properties in your GeoServer installation:

                                                                    example.host = database.example.com\nexample.database = example\nexample.user = dbuser\nexample.passwd = s3cr3t\n
                                                                    "},{"location":"data/app-schema/secondary-namespaces/","title":"Secondary Namespaces","text":""},{"location":"data/app-schema/secondary-namespaces/#what-is-a-secondary-namespace","title":"What is a secondary namespace?","text":"

                                                                    A secondary namespace is one that is referenced indirectly by the main schema, that is, one schema imports another one as shown below:

                                                                    a.xsd imports b.xsd\nb.xsd imports c.xsd\n

                                                                    (using a, b and c as the respective namespace prefixes for a.xsd, b.xsd and c.xsd):

                                                                    a.xsd declares b:prefix\nb.xsd declares c:prefix\n

                                                                    The GeoTools encoder does not honour these namespaces and writes out:

                                                                    \"a:\" , \"b:\" but NOT \"c:\"\n

                                                                    The result is c's element being encoded as:

                                                                    <null:cElement/>\n
                                                                    "},{"location":"data/app-schema/secondary-namespaces/#when-to-configure-for-secondary-namespaces","title":"When to configure for secondary namespaces","text":"

                                                                    If your application spans several namespaces which may be very common in application schemas.

                                                                    A sure sign that calls for secondary namespace configuration is when prefixes for namespaces are printed out as the literal string \"null\" or error messages like:

                                                                    java.io.IOException: The prefix \"null\" for element \"null:something\" is not bound.\n

                                                                    Note

                                                                    When using secondary namespaces, requests involving complex featuretypes must be made to the global OWS service only, not to Virtual Services. This is because virtual services are restricted to a single namespace, and thus are not able to access secondary namespaces.

                                                                    In order to allow GeoServer App-Schema to support secondary namespaces, please follow the steps outlined below:

                                                                    Using the sampling namespace as an example.

                                                                    "},{"location":"data/app-schema/secondary-namespaces/#step-1create-the-secondary-namespace-folder","title":"Step 1:Create the Secondary Namespace folder","text":"

                                                                    Create a folder to represent the secondary namespace in the data/workspaces directory, in our example that will be the \"sa\" folder.

                                                                    "},{"location":"data/app-schema/secondary-namespaces/#step-2create-files","title":"Step 2:Create files","text":"

                                                                    Create two files below in the \"sa\" folder:

                                                                    1. namespace.xml
                                                                    2. workspace.xml
                                                                    "},{"location":"data/app-schema/secondary-namespaces/#step-3edit-content-of-files","title":"Step 3:Edit content of files","text":"

                                                                    Contents of these files are as follows:

                                                                    namespace.xml(uri is a valid uri for the secondary namespace, in this case the sampling namespace uri):

                                                                    <namespace>\n    <id>sa_workspace</id>   \n    <prefix>sa</prefix>\n    <uri>http://www.opengis.net/sampling/1.0</uri>\n</namespace>\n

                                                                    workspace.xml:

                                                                    <workspace>\n    <id>sa_workspace</id>   \n    <name>sa</name>\n</workspace>\n

                                                                    That's it.

                                                                    Your workspace is now configured to use a Secondary Namespace.

                                                                    "},{"location":"data/app-schema/solr-tutorial/","title":"Apache Solr Tutorial","text":"

                                                                    This tutorial demonstrates how to use the App-Schema plugin with a Apache Solr data store. This tutorial will focus on the Apache Solr data store specific aspects, and the App-Schema documentation should be read first.

                                                                    The use case for this tutorial will be to serve through App-Schema the information about some meteorological stations index in an Apache Solr core. Note that this use case is completely fictional and only used to demonstrate the Apache Solr and App-Schema integration.

                                                                    A station data is composed of some meta-information about the station, e.g. it's name and position. The only extra different configuration we need to provide when using Apache Solr as a data source is the configuration of the data store itself.

                                                                    Apache Solr data source configuration as a specific syntax and allow us to specify geometry attributes and to explicitly set the default geometry:

                                                                    <sourceDataStores>\n  <SolrDataStore>\n    <id>stations</id>\n    <url>http://localhost:8983/solr/stations</url>\n    <index name=\"stations\">\n      <geometry default=\"true\">\n        <name>location</name>\n        <srid>4326</srid>\n        <type>POINT</type>\n      </geometry>\n    </index>\n  </SolrDataStore>\n</sourceDataStores>\n

                                                                    In this particular case the location attribute contains a point geometry and will be the default geometry.

                                                                    The complete mapping file is:

                                                                    <?xml version=\"1.0\" encoding=\"UTF-8\" standalone=\"yes\"?>\n<as:AppSchemaDataAccess xmlns:as=\"http://www.geotools.org/app-schema\">\n    <namespaces>\n        <Namespace>\n            <prefix>st</prefix>\n            <uri>http://www.stations.org/1.0</uri>\n        </Namespace>\n        <Namespace>\n            <prefix>gml</prefix>\n            <uri>http://www.opengis.net/gml/3.2</uri>\n        </Namespace>\n    </namespaces>\n    <sourceDataStores>\n        <SolrDataStore>\n            <id>stations</id>\n            <url>http://localhost:8983/solr/stations</url>\n            <index name=\"stations\">\n                <geometry default=\"true\">\n                    <name>location</name>\n                    <srid>4326</srid>\n                    <type>POINT</type>\n                </geometry>\n            </index>\n        </SolrDataStore>\n    </sourceDataStores>\n    <targetTypes>\n        <FeatureType>\n            <schemaUri>stations.xsd</schemaUri>\n        </FeatureType>\n    </targetTypes>\n    <typeMappings>\n        <FeatureTypeMapping>\n            <mappingName>stations_solr</mappingName>\n            <sourceDataStore>stations</sourceDataStore>\n            <sourceType>stations</sourceType>\n            <targetElement>st:Station</targetElement>\n            <attributeMappings>\n                <AttributeMapping>\n                    <targetAttribute>st:Station</targetAttribute>\n                    <idExpression>\n                        <OCQL>station_id</OCQL>\n                    </idExpression>\n                </AttributeMapping>\n                <AttributeMapping>\n                    <targetAttribute>st:stationName</targetAttribute>\n                    <sourceExpression>\n                        <OCQL>station_name</OCQL>\n                    </sourceExpression>\n                </AttributeMapping>\n                <AttributeMapping>\n                    <targetAttribute>st:position</targetAttribute>\n                    <sourceExpression>\n                        <OCQL>station_location</OCQL>\n                    </sourceExpression>\n                </AttributeMapping>\n            </attributeMappings>\n        </FeatureTypeMapping>\n    </typeMappings>\n</as:AppSchemaDataAccess>\n

                                                                    The mappings for the attributes are straightforward and follow the normal App-Schema attributes mappings syntax. Currently multi valued fields are not supported.

                                                                    "},{"location":"data/app-schema/solr-tutorial/#using-solr-as-app-schema-indexes","title":"Using Solr as App-Schema Indexes","text":"

                                                                    App-Schema Indexes is an extension for mapping that allows to use Apache Solr as Index for queries and retrieving data from normal App-Schema datasource (SQL DB, MongoDB, ... ).

                                                                    The only requirement to use it is having Geoserver App-Schema extension and Solr extension installed.

                                                                    "},{"location":"data/app-schema/solr-tutorial/#how-index-layer-works","title":"How Index layer works","text":"

                                                                    When App-Schema detects the index layer is activated for a FeatureType, it will use Solr configured fields for every query incoming from Geoserver OWS requests. If the incoming query uses only indexed fields App-Schema will query only on Solr data source for retrieving matching features IDs and will connect to normal data source to get all in depth data but exclusively for matching IDs.

                                                                    Warning

                                                                    note that both Primary Keys (solr index core and data source) should match to get Index layer working.

                                                                    "},{"location":"data/app-schema/solr-tutorial/#linking-an-index-only-store","title":"Linking an index only store","text":"

                                                                    Begin creating the SolrDataStore definition as usual along with the Postgis store definition:

                                                                    (...)\n<sourceDataStores>\n(...)\n    <SolrDataStore>\n        <id>stations_index</id>\n        <url>http://localhost:8983/solr/stations</url>\n        <index name=\"stations\">\n            <geometry default=\"true\">\n                <name>location</name>\n                <srid>4326</srid>\n                <type>POINT</type>\n            </geometry>\n        </index>\n    </SolrDataStore>\n     <DataStore>\n          <id>postgis_dataStore</id>\n          <parameters>\n              <Parameter>\n                  <name>Connection timeout</name>\n                  <value>20</value>\n              </Parameter>\n              <Parameter>\n                  <name>port</name>\n                  <value>5432</value>\n              </Parameter>\n              <Parameter>\n                  <name>passwd</name>\n                  <value>postgres</value>\n              </Parameter>\n              <Parameter>\n                  <name>dbtype</name>\n                  <value>postgis</value>\n              </Parameter>\n(...)\n

                                                                    Link a solr index as index layer on FeatureTypeMapping setting:

                                                                    • indexDataStore : The SolrDataStore id property from the store you use as index layer only.
                                                                    • indexType : The solr core to use.
                                                                    <typeMappings>\n(...)\n    <FeatureTypeMapping>\n        <mappingName>Stations</mappingName>\n        <sourceDataStore>postgis_dataStore</sourceDataStore>\n        <sourceType>meteo_stations</sourceType>\n        <targetElement>st:Station</targetElement>\n        <defaultGeometry>st:position</defaultGeometry>\n        <indexDataStore>stations_index</indexDataStore>\n        <indexType>stations</indexType>\n        <attributeMappings>\n        (...)\n
                                                                    "},{"location":"data/app-schema/solr-tutorial/#linking-an-index-enabled-attribute","title":"Linking an index enabled attribute","text":"

                                                                    To link a solr core field as index for an AttributeMapping you only need to add an indexField definition with this format:

                                                                    <AttributeMapping>\n(...)\n  <indexField>${SOLR_FIELD_NAME}</indexField>\n(...)\n</AttributeMapping>\n
                                                                    • \\${SOLR_FIELD_NAME} : The field name from solr core to use in index layer.

                                                                    For example if you need to use solr fields: station_id and station_name; you will write on mapping:

                                                                    <AttributeMapping>\n    <targetAttribute>st:Station</targetAttribute>\n    <idExpression>\n        <OCQL>id</OCQL>\n    </idExpression>\n    <indexField>station_id</indexField>\n</AttributeMapping>\n<AttributeMapping>\n    <targetAttribute>st:stationName</targetAttribute>\n    <sourceExpression>\n        <OCQL>strConcat('1_', common_name)</OCQL>\n    </sourceExpression>\n    <indexField>station_name</indexField>\n</AttributeMapping>\n
                                                                    "},{"location":"data/app-schema/supported-gml-versions/","title":"Supported GML Versions","text":""},{"location":"data/app-schema/supported-gml-versions/#gml-311","title":"GML 3.1.1","text":"
                                                                    • GML 3.1.1 application schemas are supported for WFS 1.1.0.
                                                                    • Clients must specify WFS 1.1.0 in requests because the GeoServer default is WFS 2.0.0.
                                                                    • GET URLs must contain version=1.1.0 to set the WFS version to 1.1.0.
                                                                    "},{"location":"data/app-schema/supported-gml-versions/#gml-321","title":"GML 3.2.1","text":"
                                                                    • GML 3.2.1 application schemas are supported for WFS 1.1.0 and (incomplete) WFS 2.0.0.
                                                                    • Some WFS 2.0.0 features not in WFS 1.1.0 such as GetFeatureById are not yet supported.
                                                                    • Clients using WFS 1.1.0 must specify WFS 1.1.0 in requests and select the gml32 output format for GML 3.2.1.
                                                                    • To use WFS 1.1.0 for GML 3.2.1, GET URLs must contain version=1.1.0 to set the WFS version to 1.1.0 and outputFormat=gml32 to set the output format to GML 3.2.1.
                                                                    • The default WFS version is 2.0.0, for which the default output format is GML 3.2.1.
                                                                    • All GML 3.2.1 responses are contained in a WFS 2.0.0 FeatureCollection element, even for WFS 1.1.0 requests, because a WFS 1.1.0 FeatureCollection cannot contain GML 3.2.1 features.
                                                                    "},{"location":"data/app-schema/supported-gml-versions/#secondary-namespace-for-gml-321-required","title":"Secondary namespace for GML 3.2.1 required","text":"

                                                                    GML 3.2.1 WFS responses are delivered in a WFS 2.0.0 FeatureCollection. Unlike WFS 1.1.0, WFS 2.0.0 does not depend explicitly on any GML version. As a consequence, the GML namespace is secondary and must be defined explicitly as a secondary namespace. See app-schema.secondary-namespaces for details.

                                                                    For example, to use the prefix gml for GML 3.2, create workspaces/gml/namespace.xml containing:

                                                                    <namespace>\n    <id>gml_namespace</id>\n    <prefix>gml</prefix>\n    <uri>http://www.opengis.net/gml/3.2</uri>\n</namespace>\n

                                                                    and workspaces/gml/workspace.xml containing:

                                                                    <workspace>\n    <id>gml_workspace</id>\n    <name>gml</name>\n</workspace>\n

                                                                    Failure to define the gml namespace prefix with a secondary namespace will result in errors like:

                                                                    java.io.IOException: The prefix \"null\" for element \"null:name\" is not bound.\n

                                                                    while encoding a response (in this case one containing gml:name), even if the namespace prefix is defined in the mapping file.

                                                                    "},{"location":"data/app-schema/supported-gml-versions/#gml-321-geometries-require-gmlid","title":"GML 3.2.1 geometries require gml:id","text":"

                                                                    GML 3.2.1 requires that all geometries have a gml:id. While GeoServer will happily encode WFS responses without gml:id on geometries, these will be schema-invalid. Encoding a gml:id on a geometry can be achieved by setting an idExpression in the mapping for the geometry property. For example, gsml:shape is a geometry property and its gml:id might be generated with:

                                                                    <AttributeMapping>\n    <targetAttribute>gsml:shape</targetAttribute>\n    <idExpression>\n        <OCQL>strConcat('shape.', getId())</OCQL>\n    </idExpression>\n    <sourceExpression>\n        <OCQL>SHAPE</OCQL>\n    </sourceExpression>\n</AttributeMapping>\n

                                                                    In this example, getId() returns the gml:id of the containing feature, so each geometry will have a unique gml:id formed by appending the gml:id of the containing feature to the string \"shape.\".

                                                                    If a multigeometry (such as a MultiPoint or MultiSurface) is assigned a gml:id of (for example) parentid, to permit GML 3.2.1 schema-validity, each geometry that the multigeometry contains will be automatically assigned a gml:id of the form parentid.1, parentid.2, ... in order.

                                                                    "},{"location":"data/app-schema/supported-gml-versions/#gml-33","title":"GML 3.3","text":"

                                                                    The proposed GML 3.3 is itself a GML 3.2.1 application schema; preliminary testing with drafts of GML 3.3 indicates that it works with app-schema as expected.

                                                                    "},{"location":"data/app-schema/tutorial/","title":"Tutorial","text":"

                                                                    This tutorial demonstrates how to configure two complex feature types using the app-schema plugin and data from two property files.

                                                                    "},{"location":"data/app-schema/tutorial/#geosciml","title":"GeoSciML","text":"

                                                                    This example uses Geoscience Markup Language (GeoSciML) 2.0, a GML 3.1 application schema:

                                                                    \"GeoSciML is an application schema that specifies a set of feature-types and supporting structures for information used in the solid-earth geosciences.\"

                                                                    The tutorial defines two feature types:

                                                                    1. gsml:GeologicUnit, which describes \"a body of material in the Earth\".
                                                                    2. gsml:MappedFeature, which describes the representation on a map of a feature, in this case gsml:GeologicUnit.

                                                                    Because a single gsml:GeologicUnit can be observed at several distinct locations on the Earth's surface, it can have a multivalued gsml:occurrence property, each being a gsml:MappedFeature.

                                                                    "},{"location":"data/app-schema/tutorial/#installation","title":"Installation","text":"
                                                                    • Install GeoServer as usual.

                                                                    • Install the app-schema plugin geoserver-*-app-schema-plugin.zip:

                                                                      • Place the jar files in WEB-INF/lib.

                                                                      • The tutorial folder contains the GeoServer configuraration (data directory) used for this tutorial.

                                                                        • Either replace your existing data directory with the tutorial data directory,
                                                                        • Or edit WEB-INF/web.xml to set GEOSERVER_DATA_DIR to point to the tutorial data directory. (Be sure to uncomment the section that sets GEOSERVER_DATA_DIR.)
                                                                    • Perform any configuration required by your servlet container, and then start the servlet. For example, if you are using Tomcat, configure a new context in server.xml and then restart Tomcat.

                                                                    • The first time GeoServer starts with the tutorial configuration, it will download all the schema (XSD) files it needs and store them in the app-schema-cache folder in the data directory. You must be connected to the internet for this to work.

                                                                    "},{"location":"data/app-schema/tutorial/#datastorexml","title":"datastore.xml","text":"

                                                                    Each data store configuration file datastore.xml specifies the location of a mapping file and triggers its loading as an app-schema data source. This file should not be confused with the source data store, which is specified inside the mapping file.

                                                                    For gsml_GeologicUnit the file is workspaces/gsml/gsml_GeologicUnit/datastore.xml:

                                                                    <dataStore>\n    <id>gsml_GeologicUnit_datastore</id>\n    <name>gsml_GeologicUnit</name>\n    <enabled>true</enabled>\n    <workspace>\n        <id>gsml_workspace</id>\n    </workspace>\n    <connectionParameters>\n        <entry key=\"namespace\">urn:cgi:xmlns:CGI:GeoSciML:2.0</entry>\n        <entry key=\"url\">file:workspaces/gsml/gsml_GeologicUnit/gsml_GeologicUnit.xml</entry>\n        <entry key=\"dbtype\">app-schema</entry>\n    </connectionParameters>\n</dataStore>\n

                                                                    For gsml:MappedFeature the file is workspaces/gsml/gsml_MappedFeature/datastore.xml:

                                                                    <dataStore>\n    <id>gsml_MappedFeature_datastore</id>\n    <name>gsml_MappedFeature</name>\n    <enabled>true</enabled>\n    <workspace>\n        <id>gsml_workspace</id>\n    </workspace>\n    <connectionParameters>\n        <entry key=\"namespace\">urn:cgi:xmlns:CGI:GeoSciML:2.0</entry>\n        <entry key=\"url\">file:workspaces/gsml/gsml_MappedFeature/gsml_MappedFeature.xml</entry>\n        <entry key=\"dbtype\">app-schema</entry>\n    </connectionParameters>\n</dataStore>\n

                                                                    Note

                                                                    Ensure that there is no blank-space inside an entry element.

                                                                    "},{"location":"data/app-schema/tutorial/#mapping-files","title":"Mapping files","text":"

                                                                    Configuration of app-schema feature types is performed in mapping files:

                                                                    • workspaces/gsml/gsml_GeologicUnit/gsml_GeologicUnit.xml
                                                                    • workspaces/gsml/gsml_MappedFeature/gsml_MappedFeature.xml
                                                                    "},{"location":"data/app-schema/tutorial/#namespaces","title":"Namespaces","text":"

                                                                    Each mapping file contains namespace prefix definitions:

                                                                    <Namespace>\n    <prefix>gml</prefix>\n    <uri>http://www.opengis.net/gml</uri>\n</Namespace>\n<Namespace>\n    <prefix>gsml</prefix>\n    <uri>urn:cgi:xmlns:CGI:GeoSciML:2.0</uri>\n</Namespace>\n<Namespace>\n    <prefix>xlink</prefix>\n    <uri>http://www.w3.org/1999/xlink</uri>\n</Namespace>\n

                                                                    Only those namespace prefixes used in the mapping file need to be declared, so the mapping file for gsml:GeologicUnit has less.

                                                                    "},{"location":"data/app-schema/tutorial/#source-data-store","title":"Source data store","text":"

                                                                    The data for this tutorial is contained in two property files:

                                                                    • workspaces/gsml/gsml_GeologicUnit/gsml_GeologicUnit.properties
                                                                    • workspaces/gsml/gsml_MappedFeature/gsml_MappedFeature.properties

                                                                    Java Properties describes the format of property files.

                                                                    For this example, each feature type uses an identical source data store configuration. This directory parameter indicates that the source data is contained in property files named by their feature type, in the same directory as the corresponding mapping file:

                                                                    <sourceDataStores>\n     <DataStore>\n         <id>datastore</id>\n         <parameters>\n             <Parameter>\n                 <name>directory</name>\n                 <value>file:./</value>\n             </Parameter>\n         </parameters>\n     </DataStore>\n </sourceDataStores>\n

                                                                    See app-schema.data-stores for a description of how to use other types of data stores such as databases.

                                                                    "},{"location":"data/app-schema/tutorial/#target-types","title":"Target types","text":"

                                                                    Both feature types are defined by the same XML Schema, the top-level schema for GeoSciML 2.0. This is specified in the targetTypes section. The type of the output feature is defined in targetElement in the typeMapping section below:

                                                                    <targetTypes>\n    <FeatureType>\n        <schemaUri>http://www.geosciml.org/geosciml/2.0/xsd/geosciml.xsd</schemaUri>\n    </FeatureType>\n</targetTypes>\n

                                                                    In this case the schema is published, but because the OASIS XML Catalog is used for schema resolution, a private or modified schema in the catalog can be used if desired.

                                                                    "},{"location":"data/app-schema/tutorial/#mappings","title":"Mappings","text":"

                                                                    The typeMappings element begins with configuration elements. From the mapping file for gsml:GeologicUnit:

                                                                    <typeMappings>\n    <FeatureTypeMapping>\n        <sourceDataStore>datastore</sourceDataStore>\n        <sourceType>gsml_GeologicUnit</sourceType>\n        <targetElement>gsml:GeologicUnit</targetElement>\n
                                                                    • The mapping starts with sourceDataStore, which gives the arbitrary identifier used above to name the source of the input data in the sourceDataStores section.
                                                                    • sourceType gives the name of the source simple feature type. In this case it is the simple feature type gsml_GeologicUnit, sourced from the rows of the file gsml_GeologicUnit.properties in the same directory as the mapping file.
                                                                    • When working with databases sourceType is the name of a table or view. Database identifiers must be lowercase for PostGIS or uppercase for Oracle Spatial.
                                                                    • targetElement is the name of the output complex feature type.
                                                                    "},{"location":"data/app-schema/tutorial/#gmlid-mapping","title":"gml:id mapping","text":"

                                                                    The first mapping sets the gml:id to be the feature id specified in the source property file:

                                                                    <AttributeMapping>\n    <targetAttribute>\n        gsml:GeologicUnit\n    </targetAttribute>\n    <idExpression>\n        <OCQL>ID</OCQL>\n    </idExpression>\n</AttributeMapping>\n
                                                                    • targetAttribute is the XPath to the element for which the mapping applies, in this case, the top-level feature type.
                                                                    • idExpression is a special form that can only be used to set the gml:id on a feature. Any field or CQL expression can be used, if it evaluates to an NCName.
                                                                    "},{"location":"data/app-schema/tutorial/#ordinary-mapping","title":"Ordinary mapping","text":"

                                                                    Most mappings consist of a target and source. Here is one from gsml:GeologicUnit:

                                                                    <AttributeMapping>\n    <targetAttribute>\n        gml:description\n        </targetAttribute>\n    <sourceExpression>\n        <OCQL>DESCRIPTION</OCQL>\n    </sourceExpression>\n</AttributeMapping>\n
                                                                    • In this case, the value of gml:description is just the value of the DESCRIPTION field in the property file.
                                                                    • For a database, the field name is the name of the column (the table/view is set in sourceType above). Database identifiers must be lowercase for PostGIS or uppercase for Oracle Spatial.
                                                                    • CQL expressions can be used to calculate content. Use caution because queries on CQL-calculated values prevent the construction of efficient SQL queries.
                                                                    • Source expressions can be CQL literals, which are single-quoted.
                                                                    "},{"location":"data/app-schema/tutorial/#client-properties","title":"Client properties","text":"

                                                                    In addition to the element content, a mapping can set one or more \"client properties\" (XML attributes). Here is one from gsml:MappedFeature:

                                                                    <AttributeMapping>\n    <targetAttribute>\n        gsml:specification\n    </targetAttribute>\n    <ClientProperty>\n        <name>xlink:href</name>\n        <value>GU_URN</value>\n    </ClientProperty>\n</AttributeMapping>\n
                                                                    • This mapping leaves the content of the gsml:specification element empty but sets an xlink:href attribute to the value of the GU_URN field.
                                                                    • Multiple ClientProperty mappings can be set.

                                                                    In this example from the mapping for gsml:GeologicUnit both element content and an XML attribute are provided:

                                                                    <AttributeMapping>\n    <targetAttribute>\n        gml:name[1]\n        </targetAttribute>\n    <sourceExpression>\n        <OCQL>NAME</OCQL>\n    </sourceExpression>\n    <ClientProperty>\n        <name>codeSpace</name>\n        <value>'urn:x-test:classifierScheme:TestAuthority:GeologicUnitName'</value>\n    </ClientProperty>\n</AttributeMapping>\n
                                                                    • The codespace XML attribute is set to a fixed value by providing a CQL literal.
                                                                    • There are multiple mappings for gml:name, and the index [1] means that this mapping targets the first.
                                                                    "},{"location":"data/app-schema/tutorial/#targetattributenode","title":"targetAttributeNode","text":"

                                                                    If the type of a property is abstract, a targetAttributeNode mapping must be used to specify a concrete type. This mapping must occur before the mapping for the content of the property.

                                                                    Here is an example from the mapping file for gsml:MappedFeature:

                                                                    <AttributeMapping>\n    <targetAttribute>gsml:positionalAccuracy</targetAttribute>\n    <targetAttributeNode>gsml:CGI_TermValuePropertyType</targetAttributeNode>\n</AttributeMapping>\n<AttributeMapping>\n    <targetAttribute>gsml:positionalAccuracy/gsml:CGI_TermValue/gsml:value</targetAttribute>\n    <sourceExpression>\n        <OCQL>'urn:ogc:def:nil:OGC:missing'</OCQL>\n    </sourceExpression>\n    <ClientProperty>\n        <name>codeSpace</name>\n        <value>'urn:ietf:rfc:2141'</value>\n    </ClientProperty>\n</AttributeMapping>\n
                                                                    • gsml:positionalAccuracy is of type gsml:CGI_TermValuePropertyType, which is abstract, so must be mapped to its concrete subtype gsml:CGI_TermValuePropertyType with a targetAttributeNode mapping before its contents can be mapped.
                                                                    • This example also demonstrates that mapping can be applied to nested properties to arbitrary depth. This becomes unmanageable for deep nesting, where feature chaining is preferred.
                                                                    "},{"location":"data/app-schema/tutorial/#feature-chaining","title":"Feature chaining","text":"

                                                                    In feature chaining, one feature type is used as a property of an enclosing feature type, by value or by reference:

                                                                    <AttributeMapping>\n    <targetAttribute>\n        gsml:occurrence\n    </targetAttribute>\n    <sourceExpression>\n        <OCQL>URN</OCQL>\n        <linkElement>gsml:MappedFeature</linkElement>\n        <linkField>gml:name[2]</linkField>\n    </sourceExpression>\n    <isMultiple>true</isMultiple>\n</AttributeMapping>\n
                                                                    • In this case from the mapping for gsml:GeologicUnit, we specify a mapping for its gsml:occurrence.
                                                                    • The URN field of the source gsml_GeologicUnit simple feature is use as the \"foreign key\", which maps to the second gml:name in each gsml:MappedFeature.
                                                                    • Every gsml:MappedFeature with gml:name[2] equal to the URN of the gsml:GeologicUnit under construction is included as a gsml:occurrence property of the gsml:GeologicUnit (by value).
                                                                    "},{"location":"data/app-schema/tutorial/#wfs-response","title":"WFS response","text":"

                                                                    When GeoServer is running, test app-schema WFS in a web browser. If GeoServer is listening on localhost:8080 you can query the two feature types using these links:

                                                                    • http://localhost:8080/geoserver/wfs?request=GetFeature&version=1.1.0&typeName=gsml:GeologicUnit
                                                                    • http://localhost:8080/geoserver/wfs?request=GetFeature&version=1.1.0&typeName=gsml:MappedFeature
                                                                    "},{"location":"data/app-schema/tutorial/#gsmlgeologicunit","title":"gsml:GeologicUnit","text":"

                                                                    Feature chaining has been used to construct the multivalued property gsml:occurrence of gsml:GeologicUnit. This property is a gsml:MappedFeature. The WFS response for gsml:GeologicUnit combines the output of both feature types into a single response. The first gsml:GeologicUnit has two gsml:occurrence properties, while the second has one. The relationships between the feature instances are data driven.

                                                                    Because the mapping files in the tutorial configuration do not contain attribute mappings for all mandatory properties of these feature types, the WFS response is not schema-valid against the GeoSciML 2.0 schemas. Schema-validity can be achieved by adding more attribute mappings to the mapping files.

                                                                    Note

                                                                    These feature types are defined in terms of GML 3.1 (the default for WFS 1.1.0); other GML versions will not work.

                                                                    Warning

                                                                    The web interface does not yet support app-schema store or layer administration.

                                                                    "},{"location":"data/app-schema/tutorial/#acknowledgements","title":"Acknowledgements","text":"

                                                                    gsml_GeologicUnit.properties and gsml_MappedFeature.properties are derived from data provided by the Department of Primary Industries, Victoria, Australia. For the purposes of this tutorial, this data has been modified to the extent that it has no real-world meaning.

                                                                    "},{"location":"data/app-schema/wfs-2.0-support/","title":"WFS 2.0 Support","text":""},{"location":"data/app-schema/wfs-2.0-support/#resolving","title":"Resolving","text":"

                                                                    Local resolve is supported in app-schema. This can be done by setting the 'resolve' parameter to either 'local' or 'all'. (Remote Resolving is not supported.) The parameter 'resolveDepth' specifies how many levels of references will be resolved. The parameter 'resolveTimeOut' may be used to specify, in seconds, an upper limit to how long app-schema should search for the feature needed for resolving. If the time out limit is reached, the feature is not resolved.

                                                                    When resolving without Feature Chaining (see below), a GML ID is extracted from the x-link reference and a brute force is done on all feature types to find a feature with this GML ID. The extraction of this GML ID from the Xlink Reference is done using the following rules:

                                                                    • In case of a URN: The GML ID comes after last colon in the URN. Make sure that the full GML ID is included after the last colon (including a possible feature type prefix).
                                                                    • In case of a URL: The GML ID comes after the # symbol.

                                                                    Failing to respect one of these rules will result in failure of resolve.

                                                                    "},{"location":"data/app-schema/wfs-2.0-support/#resolving-and-feature-chaining-by-reference","title":"Resolving and Feature Chaining By Reference","text":"

                                                                    The 'resolve' and 'resolveDepth' parameters may also be used in the case of app-schema.feature-chaining-by-reference. In this case, no brute force will take place, but resolving will instruct App-Schema to do full feature chaining rather than inserting a reference. The URI will not be used to find the feature, but the feature chaining parameters specified in the mapping, as with normal feature chaining. Because of this, the parameter 'resolveTimeOut' will be ignored in this case.

                                                                    However, be aware that every feature can only appear once in a response. If resolving would break this rule, for example with circular references, the encoder will change the resolved feature back to an (internal) x-link reference.

                                                                    "},{"location":"data/app-schema/wfs-2.0-support/#getpropertyvalue","title":"GetPropertyValue","text":"

                                                                    The GetPropertyValue request is now fully supported. Resolving is also possible in this request, following the same rules as described above.

                                                                    "},{"location":"data/app-schema/wfs-2.0-support/#paging","title":"Paging","text":"

                                                                    Paging is now supported in App-Schema. There are a few exceptions:

                                                                    • Paging is only supported for data stores with JDBC back ends and will not work for data stores with property files. It has been tested with Oracle and PostGIS databases.
                                                                    • Paging with filters involving attributes that are mapped to functions will not be supported, as this cannot be translated into SQL.

                                                                    For more efficient SQL queries generation, please set isDenormalised to false where applicable (when a one to one database table is used). See app-schema.mapping-file.

                                                                    "},{"location":"data/app-schema/wfs-2.0-support/#numbermatched","title":"NumberMatched","text":"

                                                                    The numberMatched valued in a GetFeature response contains the number of features that matches the criterion of the request. App-Schema supports it in the following cases:

                                                                    • When the App-Schema underlying dataStores are JDBC dataStore, with the exception of the cases where the query has a filter that cannot be translated to SQL query and PropertyName points to a nested attribute.
                                                                    • When the App-Schema underlying dataStores are different from JDBC dataStore and the query doesn't have filters.
                                                                    "},{"location":"data/app-schema/wfs-service-settings/","title":"WFS Service Settings","text":"

                                                                    There are two GeoServer WFS service settings that are strongly recommended for interoperable complex feature services. These can be enabled through the Services \u2192 WFS page on the GeoServer web interface or by manually editing the wfs.xml file in the data directory,

                                                                    "},{"location":"data/app-schema/wfs-service-settings/#canonical-schema-location","title":"Canonical schema location","text":"

                                                                    The default GeoServer behaviour is to encode WFS responses that include a schemaLocation for the WFS schema that is located on the GeoServer instance. A client will not know without retrieving the schema whether it is identical to the official schema hosted at schemas.opengis.net. The solution is to encode the schemaLocation for the WFS schema as the canonical location at schemas.opengis.net.

                                                                    To enable this option, choose one of these:

                                                                    1. Either: On the Service \u2192 WFS page under Conformance check Encode canonical WFS schema location.

                                                                    2. Or: Insert the following line before the closing tag in wfs.xml:

                                                                      <canonicalSchemaLocation>true</canonicalSchemaLocation>\n
                                                                    "},{"location":"data/app-schema/wfs-service-settings/#encode-using-featuremember","title":"Encode using featureMember","text":"

                                                                    By default GeoServer will encode WFS 1.1 responses with multiple features in a single gml:featureMembers element. This will cause invalid output if a response includes a feature at the top level that has already been encoded as a nested property of an earlier feature, because there is no single element that can be used to encode this feature by reference. The solution is to encode responses using gml:featureMember.

                                                                    To enable this option, choose one of these:

                                                                    1. Either: On the Service \u2192 WFS page under Encode response with select Multiple \"featureMember\" elements.

                                                                    2. Or: Insert the following line before the closing tag in wfs.xml:

                                                                      <encodeFeatureMember>true</encodeFeatureMember>\n
                                                                    "},{"location":"data/app-schema/wms-support/","title":"WMS Support","text":"

                                                                    App-schema supports WMS requests as well as WFS requests. This page provides some useful examples for configuring the WMS service to work with complex features.

                                                                    Note that the rendering performance of WMS can be significantly slower when using app-schema data stores. We strongly recommend employing app-schema.joining when using WMS with feature chaining, which can make response time for large data requests several orders of magnitude faster.

                                                                    "},{"location":"data/app-schema/wms-support/#configuration","title":"Configuration","text":"

                                                                    For WMS to be applicable to complex feature data, it is necessary that the complex feature types are recognised by GeoServer as layers. This must be configured by adding an extra configuration file named 'layer.xml' in the data directory of each feature type that we want to use as a WMS layer.

                                                                    This will expand the structure of the workspaces folder in the GeoServer data directory as follows (workspaces) (see app-schema.configuration): :

                                                                    workspaces\n    - gsml\n        - SomeDataStore\n            - SomeFeatureType\n                - featuretype.xml\n        - layer.xml\n            - datastore.xml\n            - SomeFeatureType-mapping-file.xml\n

                                                                    The file layer.xml must have the following contents: :

                                                                    <layer>\n<id>[mylayerid]</id>\n<name>[mylayername]</name>\n<path>/</path>\n<type>VECTOR</type>\n<defaultStyle>\n    <name>[mydefaultstyle]</name>\n</defaultStyle>\n<resource class=\"featureType\">\n    <id>[myfeaturetypeid]</id>\n</resource>\n<enabled>true</enabled>\n<attribution>\n    <logoWidth>0</logoWidth>\n    <logoHeight>0</logoHeight>\n</attribution>\n</layer>\n

                                                                    Replace the fields in between brackets with the following values:

                                                                    • [mylayerid] must be a custom id for the layer.
                                                                    • [mylayername] must be a custom name for the layer.
                                                                    • [mydefaultstyle] the default style used for this layer (when a style is not specified in the wms request). The style must exist in the GeoServer configuration.
                                                                    • [myfeaturetypeid] is the id of the feature type. This must the same as the id specified in the file featuretype.xml of the same directory.
                                                                    "},{"location":"data/app-schema/wms-support/#getmap","title":"GetMap","text":"

                                                                    Read GetMap for general information on the GetMap request. Read Styling for general information on how to style WMS maps with SLD files. When styling complex features, you can use XPaths to specify nested properties in your filters, as explained in app-schema.filtering-nested. However, in WMS styling filters X-paths do not support handling referenced features (see app-schema.feature-chaining-by-reference) as if they were actual nested features (because the filters are applied after building the features rather than before.) The prefix/namespace context that is used in the XPath expression is defined locally in the XML tags of the style file. This is an example of a Style file for complex features:

                                                                    <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<StyledLayerDescriptor version=\"1.0.0\" \n    xsi:schemaLocation=\"http://www.opengis.net/sld StyledLayerDescriptor.xsd\" \n    xmlns:ogc=\"http://www.opengis.net/ogc\" \n    xmlns:xlink=\"http://www.w3.org/1999/xlink\" \n    xmlns:gml=\"http://www.opengis.net/gml\" \n    xmlns:gsml=\"urn:cgi:xmlns:CGI:GeoSciML:2.0\"\n    xmlns:sld=\"http://www.opengis.net/sld\"\n    xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\">\n <sld:NamedLayer>\n  <sld:Name>geology-lithology</sld:Name>\n  <sld:UserStyle>\n    <sld:Name>geology-lithology</sld:Name>\n    <sld:Title>Geological Unit Lithology Theme</sld:Title>\n    <sld:Abstract>The colour has been creatively adapted from Moyer,Hasting\n         and Raines, 2005 (http://pubs.usgs.gov/of/2005/1314/of2005-1314.pdf) \n         which provides xls spreadsheets for various color schemes. \n         plus some creative entries to fill missing entries.\n    </sld:Abstract>\n    <sld:IsDefault>1</sld:IsDefault>\n    <sld:FeatureTypeStyle>\n      <sld:Rule>\n        <sld:Name>acidic igneous material</sld:Name>\n        <sld:Abstract>Igneous material with more than 63 percent SiO2.  \n                       (after LeMaitre et al. 2002)\n        </sld:Abstract>\n        <ogc:Filter>\n          <ogc:PropertyIsEqualTo>\n            <ogc:PropertyName>gsml:specification/gsml:GeologicUnit/gsml:composition/\n                 gsml:CompositionPart/gsml:lithology/@xlink:href</ogc:PropertyName>\n            <ogc:Literal>urn:cgi:classifier:CGI:SimpleLithology:200811:\n                         acidic_igneous_material</ogc:Literal>\n          </ogc:PropertyIsEqualTo>\n        </ogc:Filter>\n        <sld:PolygonSymbolizer>\n          <sld:Fill>\n            <sld:CssParameter name=\"fill\">#FFCCB3</sld:CssParameter>\n          </sld:Fill>\n        </sld:PolygonSymbolizer>\n      </sld:Rule>\n      <sld:Rule>\n        <sld:Name>acidic igneous rock</sld:Name>\n        <sld:Abstract>Igneous rock with more than 63 percent SiO2.  \n                     (after LeMaitre et al. 2002)\n        </sld:Abstract>\n        <ogc:Filter>\n          <ogc:PropertyIsEqualTo>\n            <ogc:PropertyName>gsml:specification/gsml:GeologicUnit/gsml:composition/\n                 gsml:CompositionPart/gsml:lithology/@xlink:href</ogc:PropertyName>\n            <ogc:Literal>urn:cgi:classifier:CGI:SimpleLithology:200811:\n                         acidic_igneous_rock</ogc:Literal>\n            </ogc:PropertyIsEqualTo>\n        </ogc:Filter>\n        <sld:PolygonSymbolizer>\n          <sld:Fill>\n            <sld:CssParameter name=\"fill\">#FECDB2</sld:CssParameter>\n          </sld:Fill>\n        </sld:PolygonSymbolizer>\n      </sld:Rule>\n      ...\n    </sld:FeatureTypeStyle>\n  </sld:UserStyle>\n </sld:NamedLayer>\n</sld:StyledLayerDescriptor>\n
                                                                    "},{"location":"data/app-schema/wms-support/#getfeatureinfo","title":"GetFeatureInfo","text":"

                                                                    Read GetFeatureInfo for general information on the GetFeatureInfo request. Read the tutorial on GetFeatureInfo Templates for information on how to template the html output. If you want to store a separate standard template for complex feature collections, save it under the filename complex_content.ftl in the template directory.

                                                                    Read the tutorial on Freemarker Templates for more information on how to use the freemarker templates. Freemarker templates support recursive calls, which can be useful for templating complex content. For example, the following freemarker template creates a table of features with a column for each property, and will create another table inside each cell that contains a feature as property: :

                                                                    <#-- \nMacro's used for content\n-->\n\n<#macro property node>\n    <#if !node.isGeometry>\n      <#if node.isComplex>      \n      <td> <@feature node=node.rawValue type=node.type /> </td>  \n      <#else>\n      <td>${node.value?string}</td>\n      <!--#if-->\n    <!--#if-->\n<!--#macro-->\n\n<#macro header typenode>\n<caption class=\"featureInfo\">${typenode.name}</caption>\n  <tr>\n  <th>fid</th>\n<#list typenode.attributes as attribute>\n  <#if !attribute.isGeometry>\n    <#if attribute.prefix == \"\">      \n        <th >${attribute.name}</th>\n    <#else>\n        <th >${attribute.prefix}:${attribute.name}</th>\n    <!--#if-->\n  <!--#if-->\n<!--#list-->\n  </tr>\n<!--#macro-->\n\n<#macro feature node type>\n<table class=\"featureInfo\">\n  <@header typenode=type />\n  <tr>\n  <td>${node.fid}</td>    \n  <#list node.attributes as attribute>\n      <@property node=attribute />\n  <!--#list-->\n  </tr>\n</table>\n<!--#macro-->\n\n<#-- \nBody section of the GetFeatureInfo template, it's provided with one feature collection, and\nwill be called multiple times if there are various feature collections\n-->\n<table class=\"featureInfo\">\n  <@header typenode=type />\n\n<#assign odd = false>\n<#list features as feature>\n  <#if odd>\n    <tr class=\"odd\">\n  <#else>\n    <tr>\n  <!--#if-->\n  <#assign odd = !odd>\n\n  <td>${feature.fid}</td>    \n  <#list feature.attributes as attribute>\n    <@property node=attribute />\n  <!--#list-->\n  </tr>\n<!--#list-->\n</table>\n<br/>\n
                                                                    "},{"location":"data/cascaded/","title":"Cascaded service data","text":"

                                                                    This section discusses how GeoServer can proxy external OGC services. This is known as cascading services.

                                                                    GeoServer supports cascading the following services:

                                                                    • External Web Feature Server
                                                                    • Cascaded Web Feature Service Stored Queries
                                                                    • External Web Map Server
                                                                    • External Web Map Tile Server
                                                                    "},{"location":"data/cascaded/stored_query/","title":"Cascaded Web Feature Service Stored Queries","text":"

                                                                    Stored query is a feature of Web Feature Services. It allows servers to serve pre-configured filter queries or even queries that cannot be expressed as GetFeature filter queries. This feature of GeoServer allows to create cascaded layers out of stored queries.

                                                                    Stored queries are read-only, and layers derived from cascaded stored queries cannot be updated with WFS-T.

                                                                    "},{"location":"data/cascaded/stored_query/#cascaded-stored-query-parameters","title":"Cascaded stored query parameters","text":"

                                                                    The relationship between stored query parameters and the schema returned by the query is not well defined. For cascaded stored queries to work, the relationship between the query received by GeoServer and the parameters passed to the stored query must be defined.

                                                                    When you set up a layer based on a stored query, you have to select which stored query to cascade and what values are passed to each parameter. Cascaded stored queries can leverage view parameters passed to the query. This is similar to how arbitrary parameters are passed to SQL Views. GeoServer supports multiple strategies to pass these values. See below for a full list.

                                                                    Parameter type Explanation No mapping The value of the view parameter will be passed as is to the stored query. No parameter will be passed if there is no view parameter of the same name. Blocked This parameter will never be passed to the stored query Default The specified value is used unless overwritten by a view parameter Static The specified value is always used (view parameter value will be ignored) CQL Expression An expression that will be evaluated on every request (see below for more details)

                                                                    See Using a parametric SQL View for more details how clients pass view parameters to GeoServer.

                                                                    "},{"location":"data/cascaded/stored_query/#cql-expressions","title":"CQL expressions","text":"

                                                                    Parameter mappings configured as CQL expressions are evaluated for each request using a context derived from the request query and the view parameters. General information on CQL expressions is available here Expression.

                                                                    The context contains the following properties that may be used in the expressions:

                                                                    Property name Explanation bboxMinX bboxMinY bboxMaxX bboxMaxY Evaluates to a corner coordinate of the full extent of the query defaultSRS Evaluates to the default SRS of the feature type viewparam:name Evaluates to the value of the view parameter name in this query"},{"location":"data/cascaded/stored_query/#configuring-a-cascaded-stored-query-layer","title":"Configuring a cascaded stored query layer","text":"

                                                                    In order to create a cascaded stored query layer the administrator invokes the Create new layer page. When an External Web Feature Server is selected, the usual list of tables and views available for publication appears, a link Configure Cascaded Stored Query... also appears:

                                                                    Selecting the Configure Cascaded Stored Query... link opens a new page where the parameter mapping is set up. By default all parameters are set up as No mapping.

                                                                    "},{"location":"data/cascaded/wfs/","title":"External Web Feature Server","text":"

                                                                    GeoServer has the ability to load data from a remote Web Feature Server (WFS). This is useful if the remote WFS lacks certain functionality that GeoServer contains. For example, if the remote WFS is not also a Web Map Server (WMS), data from the WFS can be cascaded through GeoServer to utilize GeoServer's WMS. If the remote WFS has a WMS but that WMS cannot output KML, data can be cascaded through GeoServer's WMS to output KML.

                                                                    "},{"location":"data/cascaded/wfs/#adding-an-external-wfs","title":"Adding an external WFS","text":"

                                                                    To connect to an external WFS, it is necessary to load it as a new datastore. To start, navigate to Stores \u2192 Add a new store \u2192 Web Feature Server.

                                                                    Adding an external WFS as a store

                                                                    Option Description Workspace Name of the workspace to contain the store. This will also be the prefix of all of the layer names created from the store. Data Source Name Name of the store as known to GeoServer. Description Description of the store. Enabled Enables the store. If disabled, no data from the external WFS will be served. GET_CAPABILITIES_URL URL to access the capabilities document of the remote WFS. PROTOCOL When checked, connects with POST, otherwise uses GET. USERNAME The user name to connect to the external WFS. PASSWORD The password associated with the above user name. ENCODING The character encoding of the XML requests sent to the server. Defaults to UTF-8. TIMEOUT Time (in milliseconds) before timing out. Default is 3000. BUFFER_SIZE Specifies a buffer size (in number of features). Default is 10 features. TRY_GZIP Specifies that the server should transfer data using compressed HTTP if supported by the server. LENIENT When checked, will try to render features that don't match the appropriate schema. Errors will be logged. MAXFEATURES Maximum number of features to retrieve for each featuretype. Default is no limit. AXIS_ORDER Axis order used in result coordinates (It applies only to WFS 1.x.0 servers). Default is Compliant. AXIS_ORDER_FILTER Axis order used in filter (It applies only to WFS 1.x.0 servers). Default is Compliant. OUTPUTFORMAT Output format to request (instead of the default remote service one) e.g. JSON. GML_COMPLIANCE_LEVEL OCG GML compliance level. i.e. (simple feature) 0, 1 or 2. Default is 0. GML_COMPATIBLE_TYPENAMES Use GML Compatible TypeNames (replace : by _). Default is no false. USE_HTTP_CONNECTION_POOLING Use connection pooling to connect to the remote WFS service. Also enables digest authentication.

                                                                    When finished, click Save.

                                                                    "},{"location":"data/cascaded/wfs/#configuring-external-wfs-layers","title":"Configuring external WFS layers","text":"

                                                                    When properly loaded, all layers served by the external WFS will be available to GeoServer. Before they can be served, however, they will need to be individually configured as new layers. See the section on Layers for how to add and edit new layers.

                                                                    "},{"location":"data/cascaded/wfs/#connecting-to-an-external-wfs-layer-via-a-proxy-server","title":"Connecting to an external WFS layer via a proxy server","text":"

                                                                    In a corporate environment it may be necessary to connect to an external WFS through a proxy server. To achieve this, various java variables need to be set.

                                                                    For a Windows install running GeoServer as a service, this is done by modifying the wrapper.conf file. For a default Windows install, modify C:\\Program Files\\GeoServer x.x.x\\wrapper\\wrapper.conf similarly to the following.

                                                                    # Java Additional Parameters\n\nwrapper.java.additional.1=-Djetty.home=.\nwrapper.java.additional.2=-DGEOSERVER_DATA_DIR=\"%GEOSERVER_DATA_DIR%\"\nwrapper.java.additional.3=-Dhttp.proxySet=true\nwrapper.java.additional.4=-Dhttp.proxyHost=maitproxy\nwrapper.java.additional.5=-Dhttp.proxyPort=8080\nwrapper.java.additional.6=-Dhttps.proxyHost=maitproxy\nwrapper.java.additional.7=-Dhttps.proxyPort=8080\nwrapper.java.additional.8=-Dhttp.nonProxyHosts=\"mait*|dpi*|localhost\"\n

                                                                    Note that the http.proxySet=true parameter is required. Also, the parameter numbers must be consecutive - i.e. no gaps.

                                                                    For a Windows install not running GeoServer as a service, modify startup.bat so that the java command runs with similar -D parameters.

                                                                    For a Linux/UNIX install, modify startup.sh so that the java command runs with similar -D parameters.

                                                                    "},{"location":"data/cascaded/wms/","title":"External Web Map Server","text":"

                                                                    GeoServer has the ability to proxy a remote Web Map Service (WMS). Supported WMS versions are 1.1.1 and 1.3.0. This process is sometimes known as Cascading WMS. Loading a remote WMS is useful for many reasons. If you don't manage or have access to the remote WMS, you can now manage its output as if it were local. Even if the remote WMS is not GeoServer, you can use GeoServer features to treat its output (watermarking, decoration, printing, etc).

                                                                    To access a remote WMS, it is necessary to load it as a store in GeoServer. GeoServer must be able to access the capabilities document of the remote WMS for the store to be successfully loaded.

                                                                    "},{"location":"data/cascaded/wms/#adding-an-external-wms","title":"Adding an external WMS","text":"

                                                                    To connect to an external WMS, it is necessary to load it as a new store. To start, in the Web administration interface, navigate to Stores \u2192 Add a new store \u2192 WMS. The option is listed under Other Data Sources.

                                                                    Adding an external WMS as a store

                                                                    Configuring a new external WMS store

                                                                    Option Description Workspace Name of the workspace to contain the store. This will also be the prefix of all of the layer names published from the store. The workspace name on the remote WMS is not cascaded. Data Source Name Name of the store as known to GeoServer. Description Description of the store. Enabled Enables the store. If disabled, no data from the remote WMS will be served. Capabilities URL The URL to access the capabilities document of the remote WMS. If URL contains just server address \"https://host.org/wms\" the required WMS GetCapabilities query parameters will be added automatically. Alternatively URL can be a full URL to access the capabilities document \"https://host.org/wms?service=WMS&version=1.1.1&request=GetCapabilities\". User Name If the WMS requires authentication, the user name to connect as. Password If the WMS requires authentication, the password to connect with. Max concurrent connections The maximum number of persistent connections to keep for this WMS.

                                                                    When finished, click Save.

                                                                    "},{"location":"data/cascaded/wms/#configuring-external-wms-layers","title":"Configuring external WMS layers","text":"

                                                                    When properly loaded, all layers served by the external WMS will be available to GeoServer. Before they can be served, however, they will need to be individually configured (published) as new layers. See the section on Layers for how to add and edit new layers. Once published, these layers will show up in the Layer Preview and as part of the WMS capabilities document.

                                                                    "},{"location":"data/cascaded/wms/#features","title":"Features","text":"

                                                                    Connecting a remote WMS allows for the following features:

                                                                    • Dynamic reprojection. While the default projection for a layer is cascaded, it is possible to pass the SRS parameter through to the remote WMS. Should that SRS not be valid on the remote server, GeoServer will dynamically reproject the images sent to it from the remote WMS.
                                                                    • GetFeatureInfo. WMS GetFeatureInfo requests will be passed to the remote WMS. If the remote WMS supports the application/vnd.ogc.gml format the request will be successful.
                                                                    • Full REST Configuration. See the REST section for more information about the GeoServer REST interface.
                                                                    "},{"location":"data/cascaded/wms/#cascaded-wms-settings","title":"Cascaded WMS Settings","text":"

                                                                    Making use of Remotely advertised styles and supported image formats.

                                                                    • Remote Styles Configuration. Remote Styles advertised in WMS capability document under tag, can also be used. A default style and additionally supported styles can be selected. By default no remote style is selected which indicates Geoserver to use whatever style is configured remotely and all available styles are selected. This means that remote styles can be passed in a GetMap request just like local styles. If the styles on remote WMS server have changed, please re-save the layer from UI.
                                                                    • Remote Image Format. Preferred image format(s) can be selected. It is possible to select a preferred image format and additionally supported image formats. This configuration works looks at the requested image format in local GetMap, if the GetMap format is either the preferred remote format or one of the many selected remote formats, the passed image format will be relayed in the remote WMS request. If the image format requested in local GetMap is neither the preferred remote image format nor in the list of Selected formats, the remote WMS format will use the preferred remote image format. This setting only works for image formats and ignore other advertised formats such as JSON, KML and SVG etc
                                                                    • Scale Denominators. Min and Max scale denominators can be applied to WMS layers. The effects of this configurations on the WMS layer are similar to that of scale denominators used in SLD as filters. See Rules
                                                                    • Respect Advertised Bounds. It is possible to ignore remote WMS requests with bounding box completely outside the advertised bounds of remote WMS layer. Some external WMS providers might respond with error instead of empty transparent image for WMS requests outside their advertised bounds, in such cases enable the check box to bar Geoserver from making empty WMS requests to WMS provider.
                                                                    • "},{"location":"data/cascaded/wms/#limitations","title":"Limitations","text":"

                                                                      Layers served through an external WMS have some, but not all of the functionality of a local WMS.

                                                                      • Layers cannot be styled with SLD.
                                                                      • Alternate (local) styles cannot be used.
                                                                      • Extra request parameters (time, elevation, cql_filter, etc.) cannot be used.
                                                                      • Image format cannot be specified. GeoServer will attempt to request PNG images, and if that fails will use the remote server's default image format.
                                                                      "},{"location":"data/cascaded/wmts/","title":"External Web Map Tile Server","text":"

                                                                      GeoServer has the ability to proxy a remote Web Map Tile Service (WMTS). This process is sometimes known as Cascading WMTS, even if the incoming requests follow the WMS protocol and the backing service follows the WMTS one; the WMTS cascading functionality is more like a \"protocol translator\", where the different handled data (capabilities documents, images) are translated by the \"WMTS cascading\" logic.

                                                                      Loading a remote WMTS is useful for many reasons. If you don't manage or have access to the remote WMTS, you can now manage its output as if it were local. Even if you don't have any control on the remote WMTS, you can use GeoServer features to treat its output (watermarking, decoration, printing, etc).

                                                                      To access a remote WMTS, it is necessary to load it as a store in GeoServer. GeoServer must be able to access the capabilities document of the remote WMTS for the store to be successfully loaded.

                                                                      "},{"location":"data/cascaded/wmts/#adding-an-external-wmts","title":"Adding an external WMTS","text":"

                                                                      To connect to an external WMTS, it is necessary to load it as a new store. To start, in the Web administration interface, navigate to Stores \u2192 Add a new store \u2192 WMTS. The option is listed under Other Data Sources.

                                                                      Adding an external WMTS as a store

                                                                      Configuring a new external WTMS store

                                                                      Option Description Workspace Name of the workspace to contain the store. This will also be the prefix of all of the layer names published from the store. Data Source Name Name of the store as known to GeoServer. Description Description of the store. Enabled Enables the store. If disabled, no data from the remote WMTS will be served. Capabilities URL The full URL to access the capabilities document of the remote WMTS. User Name If the WMTS requires authentication, the user name to connect as. Password If the WMTS requires authentication, the password to connect with. HTTP header name If the WMTS requires a custom HTTP header, the header name. HTTP header value If the WMTS requires a custom HTTP header, the header value. Max concurrent connections The maximum number of persistent connections to keep for this WMTS.

                                                                      When finished, click Save.

                                                                      "},{"location":"data/cascaded/wmts/#configuring-external-wmts-layers","title":"Configuring external WMTS layers","text":"

                                                                      When properly loaded, all layers served by the external WMTS will be available to GeoServer. Before they can be served, however, they will need to be individually configured (published) as new layers. See the section on Layers for how to add and edit new layers. Once published, these layers will show up in the Layer Preview and as part of the WMS capabilities document. If the WMTS layer has additional dimensions (e.g. time), related info will be reported on the WMS capabilities as well.

                                                                      "},{"location":"data/cascaded/wmts/#features","title":"Features","text":"

                                                                      Connecting a remote WMTS allows for the following features:

                                                                      • Dynamic reprojection. While the default projection for a layer is cascaded, it is possible to pass the SRS parameter through to the remote WMS. Should that SRS not be valid on the remote server, GeoServer will dynamically reproject the tiles sent to it from the remote WMTS.
                                                                      • Full REST Configuration. See the REST section for more information about the GeoServer REST interface.
                                                                      "},{"location":"data/cascaded/wmts/#limitations","title":"Limitations","text":"

                                                                      Layers served through an external WMTS have some, but not all of the functionality of a local layer.

                                                                      • Layers cannot be styled with SLD.
                                                                      • Alternate (local) styles cannot be used.
                                                                      • GetFeatureInfo requests aren't supported.
                                                                      • GetLegendGraphic requests aren't supported.
                                                                      • Image format cannot be specified. GeoServer will attempt to request PNG images, and if that fails will use the remote server's default image format.
                                                                      "},{"location":"data/cascaded/wmts/#images-output-discrepancies-in-a-cascaded-wmts-layer","title":"Images output discrepancies in a cascaded WMTS Layer","text":"

                                                                      WMTS it is a service that serves tiles and they have been generated for a concrete resolution/scale denominator. Asking a WMTS cascaded layer to generate WMS GetMap images or other WMTS tiles, with other scale denominators, will require image re-sampling:

                                                                      • If the image is stretched (scaled out) and the scale difference is notable, the borders, lines, and labels that appear in it could be blurred.
                                                                      • On the other hand if shrunk, the same object and shape could appear smaller than the original size and will be similarly appear blurred.

                                                                      This figure compares the resulting image from a WMTS to a cascaded layer which has been slightly stretched or scaled outLeft image shows a original wmts layer at its defined zoom level 4 which scale denominator is about 4M Right image shows a cascaded wmts layer as wms layer with at different scale denominator (the closest to its homologous cascaded layer) which is about 5M

                                                                      "},{"location":"data/database/","title":"Databases","text":"

                                                                      This section discusses the database data sources that GeoServer can access.

                                                                      The standard GeoServer installation supports accessing the following databases:

                                                                      • PostGIS
                                                                      • H2

                                                                      Other data sources are supplied as GeoServer extensions. Extensions are downloadable modules that add functionality to GeoServer. Extensions are available at the GeoServer download page.

                                                                      Warning

                                                                      The extension version must match the version of the GeoServer instance.

                                                                      • Db2
                                                                      • MySQL
                                                                      • Oracle
                                                                      • Microsoft SQL Server and SQL Azure

                                                                      GeoServer provides extensive facilities for controlling how databases are accessed. These are covered in the following sections.

                                                                      • Database Connection Pooling
                                                                      • JNDI
                                                                      • SQL Views
                                                                      • Controlling feature ID generation in spatial databases
                                                                      • Custom SQL session start/stop scripts
                                                                      "},{"location":"data/database/connection-pooling/","title":"Database Connection Pooling","text":"

                                                                      When serving data from a spatial database connection pooling is an important aspect of achieving good performance. When GeoServer serves a request that involves loading data from a database table, a connection must first be established with the database. This connection comes with a cost as it takes time to set up such a connection.

                                                                      The purpose served by a connection pool is to maintain connection to an underlying database between requests. The benefit of which is that connection setup only need to occur once on the first request. Subsequent requests use existing connections and achieve a performance benefit as a result.

                                                                      Whenever a data store backed by a database is added to GeoServer an internal connection pool is created. This connection pool is configurable.

                                                                      "},{"location":"data/database/connection-pooling/#connection-pool-options","title":"Connection pool options","text":"max connections The maximum number of connections the pool can hold. When the maximum number of connections is exceeded, additional requests that require a database connection will be halted until a connection from the pool becomes available. The maximum number of connections limits the number of concurrent requests that can be made against the database. min connections The minimum number of connections the pool will hold. This number of connections is held even when there are no active requests. When this number of connections is exceeded due to serving requests additional connections are opened until the pool reaches its maximum size (described above). validate connections Flag indicating whether connections from the pool should be validated before they are used. A connection in the pool can become invalid for a number of reasons including network breakdown, database server timeout, etc.. The benefit of setting this flag is that an invalid connection will never be used which can prevent client errors. The downside of setting the flag is that a performance penalty is paid in order to validate connections. fetch size The number of records read from the database in each network exchange. If set too low (<50) network latency will affect negatively performance, if set too high it might consume a significant portion of GeoServer memory and push it towards an Out Of Memory error. Defaults to 1000. connection timeout Time, in seconds, the connection pool will wait before giving up its attempt to get a new connection from the database. Defaults to 20 seconds. Test while idle Periodically test if the connections are still valid also while idle in the pool. Sometimes performing a test query using an idle connection can make the datastore unavailable for a while. Often the cause of this troublesome behaviour is related to a network firewall placed between GeoServer and the Database that force the closing of the underlying idle TCP connections. Evictor run periodicity Number of seconds between idle object evictor runs. Max connection idle time Number of seconds a connection needs to stay idle before the evictor starts to consider closing it. Evictor tests per run Number of connections checked by the idle connection evictor for each of its runs."},{"location":"data/database/db2/","title":"Db2","text":"

                                                                      Note

                                                                      GeoServer does not come built-in with support for Db2; it must be installed through an extension. Proceed to Installing the Db2 extension for installation details.

                                                                      The Db2 spatial support implements the OGC specification \"Simple Features for SQL using types and functions\" and the ISO \"SQL/MM Part 3 Spatial\" standard. When installing Db2 on Linux, Unix and Windows platforms, the \"custom\" option must be selected and the server spatial support included.

                                                                      A free of charge copy of Db2 can be downloaded from https://www.ibm.com/analytics/db2/trials.

                                                                      "},{"location":"data/database/db2/#Db2_install","title":"Installing the Db2 extension","text":"

                                                                      Warning

                                                                      Due to licensing requirements, not all files are included with the extension. To install Db2 support, it is necessary to download additional files. Just installing the Db2 extension will have no effect.

                                                                      "},{"location":"data/database/db2/#geoserver-files","title":"GeoServer files","text":"
                                                                      1. From the download page locate the release of GeoServer you are running and download the Db2 extension: db2

                                                                        Warning

                                                                        Ensure to match plugin (example 2.24.2 above) version to the version of the GeoServer instance.

                                                                      2. Extract the contents of the archive into the WEB-INF/lib directory of the GeoServer installation.

                                                                      "},{"location":"data/database/db2/#required-external-files","title":"Required external files","text":"

                                                                      The Db2 JDBC driver is not packaged with the GeoServer extension: db2jcc4.jar. This file should be available in the java subdirectory of your Db2 installation directory. Copy this file to the WEB-INF/lib directory of the GeoServer installation.

                                                                      After all GeoServer files and external files have been downloaded and copied, restart GeoServer.

                                                                      "},{"location":"data/database/db2/#adding-a-db2-data-store","title":"Adding a Db2 data store","text":"

                                                                      When properly installed, Db2 will be an option in the Vector Data Sources list when creating a new data store.

                                                                      Db2 in the list of raster data stores

                                                                      "},{"location":"data/database/db2/#configuring-a-db2-data-store","title":"Configuring a Db2 data store","text":"

                                                                      Configuring a Db2 data store

                                                                      "},{"location":"data/database/db2/#configuring-a-db2-data-store-with-jndi","title":"Configuring a Db2 data store with JNDI","text":""},{"location":"data/database/db2/#notes-on-usage","title":"Notes on usage","text":"

                                                                      Db2 schema, table, and column names are all case-sensitive when working with GeoTools/GeoServer. When working with Db2 scripts and the Db2 command window, the default is to treat these names as upper-case unless enclosed in double-quote characters but this is not the case in GeoServer.

                                                                      "},{"location":"data/database/h2/","title":"H2","text":"

                                                                      Note

                                                                      GeoServer does not come built-in with support for H2; it must be installed through an extension. Proceed to Installing the H2 extension for installation details.

                                                                      "},{"location":"data/database/h2/#h2_install","title":"Installing the H2 extension","text":"
                                                                      1. Visit the website download page, locate your release, and download: h2

                                                                        Warning

                                                                        Ensure to match plugin (example 2.24.2 above) version to the version of the GeoServer instance.

                                                                      2. Extract the contents of the archive into the WEB-INF/lib directory of the GeoServer installation.

                                                                      "},{"location":"data/database/h2/#adding-an-h2-data-store","title":"Adding an H2 data store","text":"

                                                                      Once the extension is properly installed H2 will be an option in the Vector Data Sources list when creating a new data store.

                                                                      H2 in the list of vector data stores

                                                                      "},{"location":"data/database/h2/#configuring-an-h2-data-store","title":"Configuring an H2 data store","text":"

                                                                      Configuring an H2 data store

                                                                      "},{"location":"data/database/h2/#configuring-an-h2-data-store-with-jndi","title":"Configuring an H2 data store with JNDI","text":"

                                                                      See JNDI.

                                                                      "},{"location":"data/database/jndi/","title":"JNDI","text":"

                                                                      Many data stores and connections in GeoServer have the option of utilizing Java Naming and Directory Interface on JNDI. JNDI allows for components in a Java system to look up other objects and data by a predefined name.

                                                                      A common use of JNDI is to store a JDBC data source globally in a container. This has a few benefits. First, it can lead to a much more efficient use of database resources. Database connections in Java are very resource-intensive objects, so usually they are pooled. If each component that requires a database connection is responsible for creating their own connection pool, resources will stack up fast. In addition, often those resources are under-utilized and a component may not size its connection pool accordingly. A more efficient method is to set up a global pool at the servlet container level, and have every component that requires a database connection use that.

                                                                      Furthermore, JNDI consolidates database connection configuration, as not every component that requires a database connection needs to know any more details than the JNDI name. This is very useful for administrators who may have to change database parameters in a running system, as it allows the change to occur in a single place.

                                                                      "},{"location":"data/database/mysql/","title":"MySQL","text":"

                                                                      Note

                                                                      GeoServer does not come built-in with support for MySQL; it must be installed through an extension. Proceed to Installing the MySQL extension for installation details.

                                                                      Warning

                                                                      Currently the MySQL extension is unmaintained and carries unsupported status. While still usable, do not expect the same reliability as with other extensions.

                                                                      MySQL is an open source relational database with some limited spatial functionality.

                                                                      "},{"location":"data/database/mysql/#mysql_install","title":"Installing the MySQL extension","text":"
                                                                      1. Visit the website download page, locate your release, and download: mysql

                                                                        Warning

                                                                        Ensure to match plugin (example 2.24.2 above) version to the version of the GeoServer instance.

                                                                      2. Extract the contents of the archive into the WEB-INF/lib directory of the GeoServer installation.

                                                                      "},{"location":"data/database/mysql/#adding-a-mysql-database","title":"Adding a MySQL database","text":"

                                                                      Once the extension is properly installed MySQL will show up as an option when creating a new data store.

                                                                      MySQL in the list of data sources

                                                                      "},{"location":"data/database/mysql/#configuring-a-mysql-data-store","title":"Configuring a MySQL data store","text":"

                                                                      Configuring a MySQL data store

                                                                      +------------------------+------------------------------------------------------------------------------------------------------------------------------+ | host | The mysql server host name or ip address. | +------------------------+------------------------------------------------------------------------------------------------------------------------------+ | port | The port on which the mysql server is accepting connections. | +------------------------+------------------------------------------------------------------------------------------------------------------------------+ | database | The name of the database to connect to. Can also contain a suffix with a connection URL query, such as mydbname?useSSL=false | +------------------------+------------------------------------------------------------------------------------------------------------------------------+ | user | The name of the user to connect to the mysql database as. | +------------------------+------------------------------------------------------------------------------------------------------------------------------+ | password | The password to use when connecting to the database. Left blank for no password. | +------------------------+------------------------------------------------------------------------------------------------------------------------------+ | max connections | Connection pool configuration parameters. See the Database Connection Pooling section for details. | | | | | min connections | | | | | | validate connections | | +------------------------+------------------------------------------------------------------------------------------------------------------------------+

                                                                      "},{"location":"data/database/oracle/","title":"Oracle","text":"

                                                                      Note

                                                                      GeoServer does not come built-in with support for Oracle; it must be installed through an extension. Proceed to Installing the Oracle extension for installation details.

                                                                      Oracle Spatial and Locator are the spatial components of Oracle. Locator is provided with all Oracle versions, but has limited spatial functions. Spatial is Oracle's full-featured spatial offering, but requires a specific license to use.

                                                                      "},{"location":"data/database/oracle/#oracle_install","title":"Installing the Oracle extension","text":"
                                                                      1. Visit the website download page, locate your release, and download: oracle

                                                                        Warning

                                                                        Ensure to match plugin (example 2.24.2 above) version to the version of the GeoServer instance.

                                                                      2. Extract the contents of the archive into the WEB-INF/lib directory of the GeoServer installation.

                                                                      "},{"location":"data/database/oracle/#adding-an-oracle-datastore","title":"Adding an Oracle datastore","text":"

                                                                      Once the extension is properly installed Oracle appears as an option in the Vector Data Sources list when creating a new data store.

                                                                      Oracle in the list of data sources

                                                                      "},{"location":"data/database/oracle/#configuring-an-oracle-datastore","title":"Configuring an Oracle datastore","text":"

                                                                      Configuring an Oracle datastore

                                                                      Option Description host The Oracle server host name or IP address. port The port on which the Oracle server is accepting connections (often this is port 1521). database The name of the database to connect to. By default this is interpreted as a SID name. To connect to a Service, prefix the name with a /. schema The database schema to access tables from. Setting this value greatly increases the speed at which the data store displays its publishable tables and views, so it is advisable to set this. user The name of the user to use when connecting to the database. password The password to use when connecting to the database. Leave blank for no password. max connections min connections fetch size Connection timeout validate connections Connection pool configuration parameters. See Database Connection Pooling for details. Loose bbox Controls how bounding box filters are made against geometries in the database. See the Using loose bounding box section below. Metadata bbox Flag controlling the use of MDSYS.USER_SDO_GEOM_METADATA or MDSYS.ALL_SDO_GEOM_METADATA table for bounding box calculations, this brings a better performance if the views access is fast and the bounds are configured right in the tables default is false Get remarks Boolean flag specifies whether REMARKS metadata will be returned."},{"location":"data/database/oracle/#connecting-to-an-oracle-cluster","title":"Connecting to an Oracle cluster","text":"

                                                                      In order to connect to an Oracle RAC one can use an almost full JDBC url as the database, provided it starts with ( it will be used verbatim and options \"host\" and \"port\" will be ignored. Here is an example \"database\" value used to connect to an Oracle RAC:

                                                                      (DESCRIPTION=(LOAD_BALANCE=on)(ADDRESS=(PROTOCOL=TCP)(HOST=host1) (PORT=1521))(ADDRESS=(PROTOCOL=TCP)(HOST=host2) (PORT=1521))(CONNECT_DATA=(SERVICE_NAME=service)))\n

                                                                      More information about this syntax can be found in the Oracle documentation.

                                                                      "},{"location":"data/database/oracle/#connecting-to-a-sid-or-a-service","title":"Connecting to a SID or a Service","text":"

                                                                      Recent versions of Oracle support connecting to a database via either a SID name or a Service name. A SID connection descriptor has the form: host:port:database, while a Service connection descriptor has the format host:port/database. GeoServer uses the SID form by default. To connect via a Service, prefix the database name configuration entry with a /.

                                                                      "},{"location":"data/database/oracle/#connecting-to-database-through-ldap","title":"Connecting to database through LDAP","text":"

                                                                      For instance if you want to establish a connection with the jdbc thin driver through LDAP, you can use following connect string for the input field database ldap://[host]:[Port]/[db],cn=OracleContext,dc=[oracle_ldap_context].

                                                                      If you are using referrals, enable it by placing a jndi.properties file in geoserver's CLASSPATH, which is in geoserver/WEB-INF/classes. This property file contains:

                                                                      java.naming.referral=follow

                                                                      "},{"location":"data/database/oracle/#oracle_loose_bbox","title":"Using loose bounding box","text":"

                                                                      When the Loose bbox option is set, only the bounding box of database geometries is used in spatial queries. This results in a significant performance gain. The downside is that some geometries may be reported as intersecting a BBOX when they actually do not.

                                                                      If the primary use of the database is through the Web Map Service (WMS) this flag can be set safely, since querying more geometries does not have any visible effect. However, if using the Web Feature Service (WFS) and making use of BBOX filtering capabilities, this flag should not be set.

                                                                      "},{"location":"data/database/oracle/#using-the-geometry-metadata-table","title":"Using the geometry metadata table","text":"

                                                                      The Oracle data store by default looks at the MDSYS.USER_SDO* and MDSYS.ALL_SDO* views to determine the geometry type and native SRID of each geometry column. Those views are automatically populated with information about the geometry columns stored in tables that the current user owns (for the MDSYS.USER_SDO* views) or can otherwise access (for the MDSYS.ALL_SDO* views).

                                                                      There are a few issues with this strategy:

                                                                      • if the connection pool user cannot access the tables (because impersonation is used) the MDSYS views will be empty, making it impossible to determine both the geometry type and the native SRID
                                                                      • the geometry type can be specified only while building the spatial indexes, as an index constraint. However such information is often not included when creating the indexes
                                                                      • the views are populated dynamically based on the current user. If the database has thousands of tables and users the views can become very slow

                                                                      Starting with GeoServer 2.1.4 the administrator can address the above issues by manually creating a geometry metadata table describing each geometry column. Its presence is indicated via the Oracle datastore connection parameter named Geometry metadata table (which may be a simple table name or a schema-qualified one). The table has the following structure (the table name is flexible, just specify the one chosen in the data store connection parameter):

                                                                      CREATE TABLE GEOMETRY_COLUMNS(\n   F_TABLE_SCHEMA VARCHAR(30) NOT NULL, \n   F_TABLE_NAME VARCHAR(30) NOT NULL, \n   F_GEOMETRY_COLUMN VARCHAR(30) NOT NULL, \n   COORD_DIMENSION INTEGER, \n   SRID INTEGER NOT NULL, \n   TYPE VARCHAR(30) NOT NULL,\n   UNIQUE(F_TABLE_SCHEMA, F_TABLE_NAME, F_GEOMETRY_COLUMN),\n   CHECK(TYPE IN ('POINT','LINE', 'POLYGON', 'COLLECTION', 'MULTIPOINT', 'MULTILINE', 'MULTIPOLYGON', 'GEOMETRY') ));\n

                                                                      When the table is present the store first searches it for information about each geometry column to be classified, and falls back on the MDSYS views only if the table does not contain any information.

                                                                      "},{"location":"data/database/oracle/#configuring-an-oracle-database-with-jndi","title":"Configuring an Oracle database with JNDI","text":"

                                                                      See Setting up a JNDI connection pool with Tomcat for a guide on setting up an Oracle connection using JNDI.

                                                                      "},{"location":"data/database/postgis/","title":"PostGIS","text":"

                                                                      PostGIS is an open source spatial database based on PostgreSQL, and is currently one of the most popular open source spatial databases today.

                                                                      "},{"location":"data/database/postgis/#adding-a-postgis-database","title":"Adding a PostGIS database","text":"

                                                                      As with all formats, adding a shapefile to GeoServer involves adding a new store to the existing Stores through the Web administration interface.

                                                                      "},{"location":"data/database/postgis/#using-default-connection","title":"Using default connection","text":"

                                                                      To begin, navigate to Stores \u2192 Add a new store \u2192 PostGIS NG.

                                                                      Fill in the Basic Store Info used to identify the database when managing layers.

                                                                      Adding a PostGIS database

                                                                      Basic Store Info Description Workspace Name of the workspace to contain the database. This will also be the prefix of any layer names created from tables in the database. Data Source Name Name of the database. This can be different from the name as known to PostgreSQL/PostGIS. Description Description of the database/store. Enabled Enables the store. If disabled, no data in the database will be served.

                                                                      Move on to the connection parameters used to connect and interact with the database.

                                                                      PostGIS connection parameters

                                                                      The dbtype and namespace connection parameters are not directly editable. The dbtype parameter is for internal use only (and only accessible via the REST API).

                                                                      Connection Parameter Description dbtype Type of database. Internal value, leave this value as the default. namespace Namespace to be associated with the database. This field is altered by changing the workspace name.

                                                                      Connection parameters establishing a database connection (see Database Connection Pooling):

                                                                      Connection Parameter Description host Host name where the database exists. port Port number to connect to the above host. database Name of the database as known on the host. schema Schema in the above database. user Username to connect to the database. passwd Password associated with the above user. max connections Maximum amount of open connections to the database. min connections Minimum number of pooled connections. fetch size Number of records read with each interaction with the database. Connection timeout Time (in seconds) the connection pool will wait before timing out. validate connections Checks the connection is alive before using it. Evictor run periodicity Number of seconds between idle object evictor runs. Max connection idle time Number of seconds a connection needs to stay idle before the evictor starts to consider closing it. Evictor tests per run Number of connections checked by the idle connection evictor for each of its runs.

                                                                      Connection parameters managing SQL generation:

                                                                      Connection Parameter Description Expose primary keys Expose primary key columns as values suitable for filtering. Primary key metadata table Provide table defining how primary keys values are generated (see Controlling feature ID generation in spatial databases) Session startup SQL SQL applied to connection before use (see Custom SQL session start/stop scripts) Session close-up SQL SQL applied to connection after use (see Custom SQL session start/stop scripts) preparedStatements Enables prepared statements for SQL generation, rather than text substitution. Max open prepared statements Number of prepared statements available.

                                                                      Connection parameters managing database interaction:

                                                                      Connection Parameter Description Loose bbox Performs only the primary filter on the bounding box. See the section on Using loose bounding box for details. Estimated extends Use spatial index to quickly estimate bounds, rather than check every row. Encode functions Generate supported filter functions into their SQL equivalent. Support on the fly geometry simplification Enables use of PostGIS geometry simplification

                                                                      Connection parameters supporting initial database creation:

                                                                      Connection Parameter Description create database Enable to define a new database on connection create database params Additional CREATE DATABASE definition, example WITH TEMPLATE=postgis

                                                                      When finished, click Save.

                                                                      "},{"location":"data/database/postgis/#using-jndi","title":"Using JNDI","text":"

                                                                      GeoServer can also connect to a PostGIS database using JNDI (Java Naming and Directory Interface).

                                                                      To begin, navigate to Stores \u2192 Add a new store \u2192 PostGIS NG (JNDI).

                                                                      Adding a PostGIS database (using JNDI)

                                                                      Option Description Workspace Name of the workspace to contain the store. This will also be the prefix of all of the layer names created from the store. Data Source Name Name of the database. This can be different from the name as known to PostgreSQL/PostGIS. Description Description of the database/store. Enabled Enables the store. If disabled, no data in the database will be served. dbtype Type of database. Leave this value as the default. jndiReferenceName JNDI path to the database. schema Schema for the above database. namespace Namespace to be associated with the database. This field is altered by changing the workspace name.

                                                                      When finished, click Save.

                                                                      "},{"location":"data/database/postgis/#configuring-postgis-layers","title":"Configuring PostGIS layers","text":"

                                                                      When properly loaded, all tables in the database will be visible to GeoServer, but they will need to be individually configured before being served by GeoServer. See the section on Layers for how to add and edit new layers.

                                                                      "},{"location":"data/database/postgis/#postgis_loose_bbox","title":"Using loose bounding box","text":"

                                                                      When the option loose bbox is enabled, only the bounding box of a geometry is used. This can result in a significant performance gain, but at the expense of total accuracy; some geometries may be considered inside of a bounding box when they are technically not.

                                                                      If primarily connecting to this data via WMS, this flag can be set safely since a loss of some accuracy is usually acceptable. However, if using WFS and especially if making use of BBOX filtering capabilities, this flag should not be set.

                                                                      "},{"location":"data/database/postgis/#publishing-a-postgis-view","title":"Publishing a PostGIS view","text":"

                                                                      Publishing a view follows the same process as publishing a table. The only additional step is to manually ensure that the view has an entry in the geometry_columns table.

                                                                      For example consider a table with the schema:

                                                                      my_table( id int PRIMARY KEY, name VARCHAR, the_geom GEOMETRY )\n

                                                                      Consider also the following view:

                                                                      CREATE VIEW my_view as SELECT id, the_geom FROM my_table;\n

                                                                      Before this view can be served by GeoServer, the following step is necessary to manually create the geometry_columns entry:

                                                                      INSERT INTO geometry_columns VALUES ('','public','my_view','my_geom', 2, 4326, 'POINT' );\n
                                                                      "},{"location":"data/database/postgis/#performance-considerations","title":"Performance considerations","text":""},{"location":"data/database/postgis/#geos","title":"GEOS","text":"

                                                                      GEOS (Geometry Engine, Open Source) is an optional component of a PostGIS installation. It is recommended that GEOS be installed with any PostGIS instance used by GeoServer, as this allows GeoServer to make use of its functionality when doing spatial operations. When GEOS is not available, these operations are performed internally which can result in degraded performance.

                                                                      "},{"location":"data/database/postgis/#spatial-indexing","title":"Spatial indexing","text":"

                                                                      It is strongly recommended to create a spatial index on tables with a spatial component (i.e. containing a geometry column). Any table of which does not have a spatial index will likely respond slowly to queries.

                                                                      "},{"location":"data/database/postgis/#common-problems","title":"Common problems","text":""},{"location":"data/database/postgis/#primary-keys","title":"Primary keys","text":"

                                                                      In order to enable transactional extensions on a table (for transactional WFS), the table must have a primary key. A table without a primary key is considered read-only to GeoServer.

                                                                      GeoServer has an option to expose primary key values (to make filters easier). Please keep in mind that these values are only exposed for your convenience - any attempted to modify these values using WFS-T update will be silently ignored. This restriction is in place as the primary key value is used to define the FeatureId. If you must change the FeatureId you can use WFS-T delete and add in a single Transaction request to define a replacement feature.

                                                                      "},{"location":"data/database/postgis/#multi-line","title":"Multi-line","text":"

                                                                      To insert multi-line text (for use with labeling) remember to use escaped text:

                                                                      INSERT INTO place VALUES (ST_GeomFromText('POINT(-71.060316 48.432044)', 4326), E'Westfield\\nTower');\n
                                                                      "},{"location":"data/database/postgis/#jsonpointer-function-support","title":"JsonPointer Function support","text":"

                                                                      GeoServer is able to translate the jsonPointer function to a query using PostgreSQL support for JSON types. The following are the main characteristics of the implementation:

                                                                      • The jsonPointer function syntax is like the following: jsonPointer(attributeName,'/path/to/json/attribute').
                                                                      • The function is able to select attributes inside json arrays by specifying the index of the target element in the json path eg. '/path/to/array/element/0'.
                                                                      • When accessing a JSON property it is implicitly assumed that the same property will have the same type on all features, otherwise a cast exception will be thrown by the database.
                                                                      • GeoServer will perform a cast automatically to the expect type from the evaluation; the cast is completely delegated to the database.
                                                                      • If the property doesn't exists no errors will be issued, but the features that have that property will be excluded; hence the property we wish to query is not mandatory in all features.
                                                                      "},{"location":"data/database/postgis/#examples","title":"Examples","text":"

                                                                      Having a json column storing jsonvalues like the following,

                                                                      { \"name\": \"city name\",

                                                                      \"description\": \"the city description\", \"districts\": [ { \"name\":\"district1\", \"population\": 2000 }, { \"name\":\"district2\", \"population\": 5000 } ] \"population\":{ \"average_age\": 35, \"toal\": 50000 }

                                                                      }

                                                                      and assuming an attribute name as city, valid jsonPointer functions would be:

                                                                      • jsonPointer(city, '/name').
                                                                      • jsonPointer(city, '/population/average_age').
                                                                      • jsonPointer(city, '/districts/0/name').

                                                                      An example cql_filter would then be jsonPointer(city, '/population/average_age') > 30.

                                                                      While an example rule in a sld style sheet could be:

                                                                      <Rule>\n  <Name>Cities</Name>\n     <ogc:Filter>\n       <ogc:PropertyIsEqualTo>\n         <ogc:Function name=\"jsonPointer\">\n           <ogc:PropertyName>city</ogc:PropertyName>\n           <ogc:Literal>/population/average_age</ogc:Literal>\n         </ogc:Function>\n         <ogc:Literal>35</ogc:Literal>\n       </ogc:PropertyIsEqualTo>\n       </ogc:Filter>          \n     <PointSymbolizer>\n       <Graphic>\n         <Mark>\n           <WellKnownName>square</WellKnownName>\n             <Fill>\n               <CssParameter name=\"fill\">#FF0000</CssParameter>\n             </Fill>\n         </Mark>\n         <Size>16</Size>\n       </Graphic>\n    </PointSymbolizer>\n </Rule>\n
                                                                      "},{"location":"data/database/postgis/#datatypes","title":"DataTypes","text":"

                                                                      PostgreSQL defines two JSON datatypes:

                                                                      • json that stores an exact copy of the input text.
                                                                      • jsonb which store the value in a decomposed binary format.

                                                                      The jsonPointer function supports both, as well as the text format if it contains a valid json representation. Anyways, the PostgreSQL documentation recommends usage of jsonb, as it is faster to process.

                                                                      PostgreSQL supports also indexing on json types. And index on a specific json attribute can be created as follow:

                                                                      CREATE INDEX description_index ON table_name ((column_name -> path -> to ->> json_attribute )).

                                                                      Index can also be specified in partial way:

                                                                      CREATE INDEX description_index ON table_name ((column_name -> path -> to ->> json_attribute )) WHERE (column_name -> path -> to ->> json_attribute) IS NOT NULL.

                                                                      "},{"location":"data/database/primarykey/","title":"Controlling feature ID generation in spatial databases","text":""},{"location":"data/database/primarykey/#introduction","title":"Introduction","text":"

                                                                      All spatial database data stores (PostGIS, Oracle, MySQL and so on) normally derive the feature ID from the table primary key and assume certain conventions on how to locate the next value for the key in case a new feature needs to be generated (WFS insert operation).

                                                                      Common conventions rely on finding auto-increment columns (PostGIS) or finding a sequence that is named after a specific convention such as <table>_<column>_SEQUENCE (Oracle case).

                                                                      In case none of the above is found, normally the store will fall back on generating random feature IDs at each new request, making the table unsuitable for feature ID based searches and transactions.

                                                                      "},{"location":"data/database/primarykey/#metadata-table-description","title":"Metadata table description","text":"

                                                                      These defaults can be overridden manually by creating a primary key metadata table that specifies which columns to use and what strategy to use to generate new primary key values. The (schema qualified) table can be created with this SQL statement (this one is valid for PostGIS and ORACLE, adapt it to your specific database, you may remove the check at the end if you want to):

                                                                      --PostGIS DDL\n\nCREATE TABLE my_schema.gt_pk_metadata (\n  table_schema VARCHAR(32) NOT NULL,\n  table_name VARCHAR(32) NOT NULL,\n  pk_column VARCHAR(32) NOT NULL,\n  pk_column_idx INTEGER,\n  pk_policy VARCHAR(32),\n  pk_sequence VARCHAR(64),\n  unique (table_schema, table_name, pk_column),\n  check (pk_policy in ('sequence', 'assigned', 'autogenerated'))\n)\n\n\n--ORACLE DDL\n\nCREATE TABLE gt_pk_metadata (\n  table_schema VARCHAR2(32) NOT NULL,\n  table_name VARCHAR2(32) NOT NULL,\n  pk_column VARCHAR2(32) NOT NULL,\n  pk_column_idx NUMBER(38),\n  pk_policy VARCHAR2(32),\n  pk_sequence VARCHAR2(64),\n  constraint  chk_pk_policy check (pk_policy in ('sequence', 'assigned', 'autogenerated')));\n\nCREATE UNIQUE INDEX gt_pk_metadata_table_idx01 ON gt_pk_metadata (table_schema, table_name, pk_column);\n

                                                                      The table can be given a different name. In that case, the (schema qualified) name of the table must be specified in the primary key metadata table configuration parameter of the store.

                                                                      The following table describes the meaning of each column in the metadata table.

                                                                      Column Description table_schema Name of the database schema in which the table is located. table_name Name of the table or view to be published pk_column Name of a column used to form the feature IDs pk_column_idx Index of the column in a multi-column key, else NULL. In case multi column keys are needed, multiple records with the same table schema and table name will be used. pk_policy The new value generation policy, used in case a new feature needs to be added in the table (following a WFS-T insert operation). pk_sequence The name of the database sequence to be used when generating a new value for the pk_column.

                                                                      The possible values for pk_policy are:

                                                                      • assigned. The value of the attribute in the newly inserted feature will be used (this assumes the \"expose primary keys\" flag has been enabled)
                                                                      • sequence. The value of the attribute will be generated from the next value of a sequence indicated in the pk_sequence column.
                                                                      • autogenerated. The column is an auto-increment one, the next value in the auto-increment will be used.
                                                                      "},{"location":"data/database/primarykey/#using-the-metadata-table-with-views","title":"Using the metadata table with views","text":"

                                                                      GeoServer can publish spatial views without issues, but normally results in two side effects:

                                                                      • the view is treated as read only
                                                                      • the feature IDs are randomly generated

                                                                      The metadata table can also refer to views, just use the view name in the table_name column: this will result in stable ids, and in databases supporting updatable views, it will also make the code treat the view as writable (thus, enabling usage of WFS-T on it).

                                                                      "},{"location":"data/database/sqlserver/","title":"Microsoft SQL Server and SQL Azure","text":"

                                                                      Note

                                                                      GeoServer does not come built-in with support for SQL Server; it must be installed through an extension. Proceed to Installing the SQL Server extension for installation details.

                                                                      Microsoft's SQL Server is a relational database with spatial functionality. SQL Azure is the database option provided in the Azure cloud solution which is in many respects similar to SQL Server.

                                                                      "},{"location":"data/database/sqlserver/#supported-versions","title":"Supported versions","text":"

                                                                      The extension supports SQL Server 2008 - 2019 and SQL Azure.

                                                                      "},{"location":"data/database/sqlserver/#sqlserver_install","title":"Installing the SQL Server extension","text":""},{"location":"data/database/sqlserver/#geoserver-files","title":"GeoServer files","text":"
                                                                      1. Visit the website download page, locate your release, and download: sqlserver

                                                                        Warning

                                                                        Ensure to match plugin (example 2.24.2 above) version to the version of the GeoServer instance.

                                                                      2. Extract the contents of the archive into the WEB-INF/lib directory of the GeoServer installation.

                                                                      3. Restart the GeoServer to load the extension.

                                                                      "},{"location":"data/database/sqlserver/#adding-a-sql-server-database","title":"Adding a SQL Server database","text":"

                                                                      Once the extension is properly installed SQL Server will show up as an option when creating a new data store.

                                                                      SQL Server in the list of vector data sources

                                                                      "},{"location":"data/database/sqlserver/#configuring-a-sql-server-data-store","title":"Configuring a SQL Server data store","text":"

                                                                      Configuring a SQL Server data store

                                                                      +-------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | host | The sql server instance host name or ip address, only. Note that server\\instance notation is not accepted - specify the port below, instead, if you have a non-default instance. | +-------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | port | The port on which the SQL server instance is accepting connections. See the note below. | +-------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | database | The name of the database to connect to. Might be left blank if the user connecting to SQL Server has a \"default database\" set in the user configuration | +-------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | schema | The database schema to access tables from (optional). | +-------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | user | The name of the user to connect to the database as. | +-------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | password | The password to use when connecting to the database. Leave blank for no password. | +-------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | max connections | Connection pool configuration parameters. See the Database Connection Pooling section for details. If you are connecting to SQL Azure make sure to set the validate connections flag as SQL Azure closes inactive connections after a very short delay. | | | | | min connections | | +-------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+

                                                                      "},{"location":"data/database/sqlserver/#port_notes","title":"Determining the port used by the SQL Server instance","text":"

                                                                      You can determine the port in use by connecting to your SQL server instance using some other software, and then using netstat to display details on network connections. In the following example on a Windows PC, the port is 2646 :

                                                                      C:>netstat -a | find \"sql1\"\nTCP   DPI908194:1918   maittestsql1.dpi.nsw.gov.au:2646   ESTABLISHED\n
                                                                      "},{"location":"data/database/sqlserver/#using-the-geometry-metadata-table","title":"Using the geometry metadata table","text":"

                                                                      The SQL server data store can determine the geometry type and native SRID of a particular column only by data inspection, by looking at the first row in the table. Of course this is error prone, and works only if there is data in the table. The administrator can address the above issue by manually creating a geometry metadata table describing each geometry column. Its presence is indicated via the SQL Server datastore connection parameter named Geometry metadata table (which may be a simple table name or a schema-qualified one). The table has the following structure (the table name is flexible, just specify the one chosen in the data store connection parameter):

                                                                      CREATE TABLE GEOMETRY_COLUMNS(\n   F_TABLE_SCHEMA VARCHAR(30) NOT NULL,\n   F_TABLE_NAME VARCHAR(30) NOT NULL,\n   F_GEOMETRY_COLUMN VARCHAR(30) NOT NULL,\n   COORD_DIMENSION INTEGER,\n   SRID INTEGER NOT NULL,\n   TYPE VARCHAR(30) NOT NULL,\n   UNIQUE(F_TABLE_SCHEMA, F_TABLE_NAME, F_GEOMETRY_COLUMN),\n   CHECK(TYPE IN ('POINT', 'LINESTRING', 'POLYGON', 'MULTIPOINT', 'MULTILINESTRING', 'MULTIPOLYGON', 'GEOMETRYCOLLECTION') ));\n

                                                                      When the table is present the store first searches it for information about each geometry column to be classified, and falls back on data inspection only if the table does not contain any information.

                                                                      "},{"location":"data/database/sqlsession/","title":"Custom SQL session start/stop scripts","text":"

                                                                      Starting with version 2.1.4 GeoServer support custom SQL scripts that can be run every time GeoServer grabs a connection from the connection pool, and every time the session is returned to the pool.

                                                                      These scripts can be parametrized with the expansion of environment variables, which can be in turn set into the OGC request parameters with the same mechanism as Variable substitution in SLD.

                                                                      In addition to the parameters provided via the request the GSUSER variable is guaranteed to contain the current GeoServer user, or be null if no authentication is available. This is useful if the SQL sessions scripts are used to provide tight control over database access

                                                                      The SQL script can expand environment variables using the ${variableName, defaultValue} syntax, for example the following alters the current database user to be the same as the GeoServer current user, or geoserver in case no user was authenticated

                                                                      SET SESSION AUTHORIZATION \\${GSUSER,geoserver}

                                                                      "},{"location":"data/database/sqlsession/#using-sql-session-scripts-to-control-authorizations-at-the-database-level","title":"Using SQL session scripts to control authorizations at the database level","text":"

                                                                      GeoServer connects to a database via a connection pool, using the same rights as the user that is specified in the connection pool setup. In a setup that provides a variety of services and tables the connection pool user must have a rather large set of rights, such as table selection (WMS), table insert/update/delete (WFS-T) and even table creation (data upload via RESTConfig, WPS Import process and eventual new processes leveraging direct database connections).

                                                                      What a user can do can be controlled by means of the GeoServer security subsystem, but in high security setups this might not be considered enough, and a database level access control be preferred instead. In these setups normally the connection pool user has limited access, such as simple read only access, while specific users are allowed to perform more operations.

                                                                      When setting up such a solution remember the following guidelines:

                                                                      • The connection pool user must be able to access all table metadata regardless of whether it is able to actually perform a select on the tables (dictionary tables/describe functionality must be always accessible)
                                                                      • The connection pool must see each and every column of tables and views, in other words, the structure of the tables must not change as the current user changes
                                                                      • the database users and the GeoServer user must be kept in synch with some external tools, GeoServer provides no out of the box facilities
                                                                      • during the GeoServer startup the code will access the database to perform some sanity checks, in that moment there is no user authenticated in GeoServer so the code will run under whatever user was specified as the \"default value\" for the GSUSER variable.
                                                                      • The user that administers GeoServer (normally admin, but it can be renamed, and other users given the administration roles too) must also be a database user, all administrative access on the GeoServer GUI will have that specific user controlling the session

                                                                      Typical use cases:

                                                                      • Give insert/update/delete rights only to users that must use WFS-T
                                                                      • Only allow the administrator to create new tables
                                                                      • Limit what rows of a table a user can see by using dynamic SQL views taking into account the current user to decide what rows to return

                                                                      To make a point in case, if we want the PostgreSQL session to run with the current GeoServer user credentials the following scripts will be used:

                                                                      Setting up session authorization for PostgreSQL

                                                                      The first command makes the database session use either the current GeoServer user, or the geoserver user if no authentication was available (anonymous user, or startup situation). The second command resets the session to the rights of the connection pool user.

                                                                      "},{"location":"data/database/sqlview/","title":"SQL Views","text":"

                                                                      The traditional way to access database data is to configure layers against either tables or database views. Starting with GeoServer 2.1.0, layers can also be defined as SQL Views. SQL Views allow executing a custom SQL query on each request to the layer. This avoids the need to create a database view for complex queries.

                                                                      Even more usefuly, SQL View queries can be parameterized via string substitution. Parameter values can be supplied in both WMS and WFS requests. Default values can be supplied for parameters, and input values can be validated by Regular Expressions to eliminate the risk of SQL injection attacks.

                                                                      Note

                                                                      SQL Views are read-only, and thus cannot be updated by WFS-T transactions.

                                                                      "},{"location":"data/database/sqlview/#creating-a-sql-view","title":"Creating a SQL View","text":"

                                                                      In order to create a SQL View the administrator invokes the Create new layer page. When a database store is selected, the usual list of tables and views available for publication appears, A link Configure new SQL view... also appears:

                                                                      Selecting the Configure new SQL view... link opens a new page where the SQL view query can be specified:

                                                                      Note

                                                                      The query can be any SQL statement that is valid as a subquery in a FROM clause (that is, select * from (<the sql view>) [as] vtable). This is the case for most SQL statements, but in some databases special syntax may be needed to call stored procedures. Also, all the columns returned by the SQL statement must have names. In some databases alias names are required for function calls.

                                                                      When a valid SQL query has been entered, press the Refresh link in the Attributes table to get the list of the attribute columns determined from the query:

                                                                      GeoServer attempts to determine the geometry column type and the native SRID, but these should be verified and corrected if necessary.

                                                                      Note

                                                                      Having a correct SRID (spatial reference id) is essential for spatial queries to work. In many spatial databases the SRID is equal to the EPSG code for the specific spatial reference system, but this is not always the case (for instance, Oracle has a number of non-EPSG SRID codes).

                                                                      If stable feature ids are desired for the view's features, one or more columns providing a unique id for the features should be checked in the Identifier column. Always ensure these attributes generate a unique key, or filtering and WFS requests will not work correctly.

                                                                      Once the query and the attribute details are defined, press Save. The usual New Layer configuration page will appear. If further changes to the view are required, the page has a link to the SQL View editor at the bottom of the Data tab:

                                                                      Once created, the SQL view layer is used in the same way as a conventional table-backed layer, with the one limitation of being read-only.

                                                                      Warning

                                                                      Saving the SQL view definition here is not sufficient, the layer containing it must be saved as well for the change to have any effect. This is because the SQL view definition is actually just one component of the layer/featuretype/coverage attributes.

                                                                      "},{"location":"data/database/sqlview/#parameterizing-sql-views","title":"Parameterizing SQL Views","text":"

                                                                      A parametric SQL view is based on a SQL query containing named parameters. The values for the parameters can be provided dynamically in WMS and WFS requests using the viewparams request parameter. Parameters can have default values specified, to handle the situation where they are not supplied in a request. Validation of supplied parameter values is supported by specifying validation regular expressions. Parameter values are only accepted if they match the regular expression defined for them. Appropriate parameter validation should always be used to avoid the risk of SQL injection attacks.

                                                                      Warning

                                                                      SQL View parameter substitution should be used with caution, since improperly validated parameters open the risk of SQL injection attack. Where possible, consider using safer methods such as dynamic filtering in the request, or Variable substitution in SLD.

                                                                      "},{"location":"data/database/sqlview/#defining-parameters","title":"Defining parameters","text":"

                                                                      Within the SQL View query, parameter names are delimited by leading and trailing % signs. The parameters can occur anywhere within the query text, including such uses as within SQL string constants, in place of SQL keywords, or representing entire SQL clauses.

                                                                      Here is an example of a SQL View query for a layer called popstates with two parameters, low and high:

                                                                      Each parameter needs to be defined with its name, an optional default value, and a validation expression. The Guess parameters from SQL link can be clicked to infer the query parameters automatically, or they can be entered manually. The result is a table filled with the parameter names, default values and validation expressions:

                                                                      In this case the default values should be specified, since the query cannot be executed without values for the parameters (because the expanded query select gid, state_name, the_geom from pgstates where persons between and is invalid SQL). Since the use of the parameters in the SQL query requires their values to be positive integer numbers, the validation regular expressions are specified to allow only numeric input (i.e. ^[\\d]+$):

                                                                      Once the parameters have been defined, the Attributes Refresh link is clicked to parse the query and retrieve the attribute columns. The computed geometry type and column identifier details can be corrected if required. From this point on the workflow is the same as for a non-parameterized query.

                                                                      "},{"location":"data/database/sqlview/#using_a_parametric_sql_view","title":"Using a parametric SQL View","text":"

                                                                      The SQL view parameters are specified by adding the viewparams parameter to the WMS GetMap or the WFS GetFeature request. The viewparams argument is a list of key:value pairs, separated by semicolons:

                                                                      viewparams=p1:v1;p2:v2;...

                                                                      If the values contain semicolons or commas these must be escaped with a backslash (e.g. \\, and \\;).

                                                                      For example, the popstates SQL View layer can be displayed by invoking the Layer Preview. Initially no parameter values are supplied, so the defaults are used and all the states are displayed.

                                                                      To display all states having more than 20 million inhabitants the following parameter is added to the GetMap request: &viewparams=low:20000000

                                                                      To display all states having between 2 and 5 million inhabitants the view parameters are: &viewparams=low:2000000;high:5000000

                                                                      Parameters can be provided for multiple layers by separating each parameter map with a comma:

                                                                      &viewparams=l1p1:v1;l1p2:v2,l2p1:v1;l2p2:v2,...

                                                                      The number of parameter maps must match the number of layers (featuretypes) included in the request.

                                                                      "},{"location":"data/database/sqlview/#using-xml-view-parameters-format","title":"Using XML View parameters format","text":"

                                                                      Aside the default SQL view parameters format, an XML format is available by using the request parameter/value:

                                                                      &viewParamsFormat=XML

                                                                      XML alternative format example:

                                                                      &viewParams=<VP><PS><P n=\"m1\">8302,802,8505</P><P n=\"m2\">22,44</P></PS><PS/><PS><P n=\"csvInput\">acv,rrp;1,0;0,7;22,1</P></PS></VP>

                                                                      viewParamsFormat new optional parameter definition:
                                                                      • Selects the view parameters format, valid implementation values are CharSeparated (default) and XML.
                                                                      • It's an optional parameter, if not set the default character separated format will be used supporting backward compatibility.
                                                                      XML tags/attributes definition:
                                                                      • VP: the root XML element tag for View Params. This ensures XML validity (an XML document must have a single root element).
                                                                      • PS: contains the parameters for a given layer (by position). If there are no parameters for the current layer this must be set as an empty element, e.g. <PS/>
                                                                      • P: the parameter definition XML element, including the parameter name as the n attribute and the value as its text content.
                                                                      • n: the parameter name attribute inside the P element.

                                                                      If a layer doesn't have parameters to be set, just provide an empty PS element : <PS/>

                                                                      Note: XML view parameters can be used only in GET requests.

                                                                      "},{"location":"data/database/sqlview/#parameters-and-validation","title":"Parameters and validation","text":"

                                                                      The value of a SQL View parameter can be an arbitrary string of text. The only constraint is that the attribute names and types returned by the view query must never change. This makes it possible to create views containing parameters representing complex SQL fragments. For example, using the view query select * from pgstates %where% allows specifying the WHERE clause of the query dynamically. However, this would likely require an empty validation expression. which presents a serious risk of SQL injection attacks. This technique should only be used if access to the server is restricted to trusted clients.

                                                                      In general, SQL parameters must be used with care. They should always include validation regular expressions that accept only the intended parameter values. Note that while validation expressions should be constructed to prevent illegal values, they do not necessarily have to ensure the values are syntactically correct, since this will be checked by the database SQL parser. For example:

                                                                      • ^[\\d\\.\\+-eE]+$ checks that a parameter value contains valid characters for floating-point numbers (including scientific notation), but does not check that the value is actually a valid number
                                                                      • [^;']+ checks that a parameter value does not contain quotes or semicolons. This prevents common SQL injection attacks, but otherwise does not impose much limitation on the actual value
                                                                      "},{"location":"data/database/sqlview/#resources-for-validation-regular-expressions","title":"Resources for Validation Regular expressions","text":"

                                                                      Defining effective validation regular expressions is important for security. Regular expressions are a complex topic that cannot be fully addressed here. The following are some resources for constructing regular expressions:

                                                                      • GeoServer uses the standard Java regular expression engine. The Pattern class Javadocs contain the full specification of the allowed syntax.
                                                                      • http://www.regular-expressions.info has many tutorials and examples of regular expressions.
                                                                      • The myregexp applet can be used to test regular expressions online.
                                                                      "},{"location":"data/database/sqlview/#place-holder-for-the-sql-where-clause","title":"Place holder for the SQL WHERE clause","text":"

                                                                      The SQL WHERE clause produced by GeoServer using the context filters, e.g. the bounding box filter of a WMS query, will be added around the SQL view definition. This comes handy (better performance) when we have extra operations that can be done on top of the rows filtered with the GeoServer produced filter first.

                                                                      A typical use case for this functionality is the execution of analytic functions on top of the filtered results:

                                                                      SELECT STATION_NAME,\n       MEASUREMENT,\n       MEASUREMENT_TYPE,\n       LOCATION\nFROM\n  (SELECT STATION_NAME,\n          MEASUREMENT,\n          MEASUREMENT_TYPE,\n          LOCATION,\n          ROW_NUMBER() OVER(PARTITION BY STATION_ID, MEASUREMENT_TYPE\n                            ORDER BY TIME DESC) AS RANK\n   FROM\n     (SELECT st.id AS STATION_ID,\n             st.common_name AS STATION_NAME,\n             ob.value AS MEASUREMENT,\n             pr.param_name AS MEASUREMENT_TYPE,\n             ob.time AS TIME,\n             st.position AS LOCATION\n      FROM meteo.meteo_stations st\n      LEFT JOIN meteo.meteo_observations ob ON st.id = ob.station_id\n      LEFT JOIN meteo.meteo_parameters pr ON ob.parameter_id = pr.id\n\n      -- SQL WHERE clause place holder for GeoServer\n      WHERE 1 = 1 :where_clause:) AS stations_filtered) AS stations\n\nWHERE RANK = 1;\n

                                                                      A few restrictions apply when using the explicit :where_clause: place holder:

                                                                      • it needs to be added in a position where all the attributes known by GeoServer are already present
                                                                      • the :where_clause: can only appear once

                                                                      When a WHERE clause place holder is present, GeoServer will always add an explicit AND at the beginning of the produced WHERE clause. This allows the injection of the produced WHERE in the middle of complex expressions if needed.

                                                                      "},{"location":"data/raster/","title":"Raster data","text":"

                                                                      This section discusses the raster (coverage) data sources that GeoServer can access.

                                                                      The standard GeoServer installation supports the loading and serving of the following data formats:

                                                                      • GeoTIFF
                                                                      • WorldImage
                                                                      • ImageMosaic
                                                                      • GeoPackage

                                                                      Other data sources are supplied as GeoServer extensions. Extensions are downloadable modules that add functionality to GeoServer. Extensions are available at the GeoServer download page.

                                                                      Warning

                                                                      The extension version must match the version of the GeoServer instance.

                                                                      • ArcGrid
                                                                      • GDAL Image Formats
                                                                      • ImagePyramid

                                                                      GeoServer provides extensive facilities for controlling how rasters are accessed. These are covered in the following sections.

                                                                      • Coverage Views
                                                                      "},{"location":"data/raster/arcgrid/","title":"ArcGrid","text":"

                                                                      ArcGrid is a coverage file format created by ESRI.

                                                                      "},{"location":"data/raster/arcgrid/#adding-an-arcgrid-data-store","title":"Adding an ArcGrid data store","text":"

                                                                      By default, ArcGrid will be an option in the Raster Data Sources list when creating a new data store.

                                                                      ArcGrid in the list of raster data stores

                                                                      "},{"location":"data/raster/arcgrid/#configuring-a-arcgrid-data-store","title":"Configuring a ArcGrid data store","text":"

                                                                      Configuring an ArcGrid data store

                                                                      Option Description Workspace Data Source Name Description Enabled URL"},{"location":"data/raster/coverageview/","title":"Coverage Views","text":"

                                                                      Starting with GeoServer 2.6.0, You can define a new raster layer as a Coverage View. Coverage Views allow defining a View made of different bands originally available inside coverages (either bands of the same coverage or different coverages) of the same Coverage Store.

                                                                      "},{"location":"data/raster/coverageview/#creating-a-coverage-view","title":"Creating a Coverage View","text":"

                                                                      In order to create a Coverage View the administrator invokes the Create new layer page. When a Coverage store is selected, the usual list of coverages available for publication appears. A link Configure new Coverage view... also appears:

                                                                      Selecting the Configure new Coverage view... link opens a new page where you can configure the coverage view:

                                                                      The upper text box allows to specify the name to be assigned to this coverage view. (In the following picture we want to create as example, a currents view merging together both u and v components of the currents, which are exposed as separated 1band coverages).

                                                                      Next step is defining the output bands to be put in the coverage view. It is possible to specify which input coverage bands need to be put on the view by selecting them from the Composing coverages/bands....

                                                                      Once selected, they needs to be added to the output bands of the coverage view, using the add button.

                                                                      Optionally, is it possible to remove the newly added bands using the remove and remove all buttons. Once done, clicking on the save button will redirect to the standard Layer configuration page.

                                                                      Scrolling down to the end of the page, is it possible to see the bands composing the coverage (and verify they are the one previously selected).

                                                                      At any moment, the Coverage View can be refined and updated by selecting the Edit Coverage view... link available before the Coverage Bands details section.

                                                                      Once all the properties of the layer have been configured, by selecting the Save button, the coverage will be saved in the catalog and it will become visible as a new layer.

                                                                      "},{"location":"data/raster/coverageview/#heterogeneous-coverage-views","title":"Heterogeneous coverage views","text":"

                                                                      In case the various coverages bound in the view have different resolution, the UI will present two extra controls:

                                                                      The coverage envelope policy defines how the bounding box of the output is calculated for metadata purposes. Having different resolutions, the coverages are unlikely to share the same bounding box. The possible values are:

                                                                      • Intersect envelopes: Use the intersection of all input coverage envelopes
                                                                      • Union envelopes: Use the union of all input coverage envelopes

                                                                      The coverage resolution policy defines which target resolution is used when generating outputs:

                                                                      • Best: Use the best resolution available among the chosen bands (e.g., in a set having 60m, 20m and 10m the 10m resolution will be chosen)
                                                                      • Worst: Use the worst resolution available among the chosen bands (e.g., in a set having 60m, 20m and 10m the 60m resolution will be chosen)

                                                                      The coverage resolution policy is context sensitive. Assume the input is a 12 bands Sentinel 2 dataset at three different resolution, 10, 20 and 30 meters, and a false color image is generated by performing a band selection in the SLD. If the policy is best and the SLD selects only bands at 20 and 60 meters, the output will be at 20 meters instead of 10 meters.

                                                                      "},{"location":"data/raster/coverageview/#coverage-view-in-action","title":"Coverage View in action","text":"

                                                                      A Layer preview of the newly created coverage view will show the rendering of the view. Note that clicking on a point on the map will result into a GetFeatureInfo call which will report the values of the bands composing the coverage view.

                                                                      "},{"location":"data/raster/gdal/","title":"GDAL Image Formats","text":"

                                                                      GeoServer can leverage the ImageI/O-Ext GDAL libraries to read selected coverage formats. GDAL is able to read many formats, but for the moment GeoServer supports only a few general interest formats and those that can be legally redistributed and operated in an open source server.

                                                                      The following image formats can be read by GeoServer using GDAL:

                                                                      • DTED, Military Elevation Data (.dt0, .dt1, .dt2): http://www.gdal.org/frmt_dted.html
                                                                      • EHdr, ESRI .hdr Labelled: <http://www.gdal.org/frmt_various.html#EHdr>
                                                                      • ENVI, ENVI .hdr Labelled Raster: <http://www.gdal.org/frmt_various.html#ENVI>
                                                                      • HFA, Erdas Imagine (.img): <http://www.gdal.org/frmt_hfa.html>
                                                                      • JP2MrSID, JPEG2000 (.jp2, .j2k): <http://www.gdal.org/frmt_jp2mrsid.html>
                                                                      • MrSID, Multi-resolution Seamless Image Database: <http://www.gdal.org/frmt_mrsid.html>
                                                                      • NITF: <http://www.gdal.org/frmt_nitf.html>
                                                                      • ECW, ERDAS Compressed Wavelets (.ecw): <http://www.gdal.org/frmt_ecw.html>
                                                                      • JP2ECW, JPEG2000 (.jp2, .j2k): http://www.gdal.org/frmt_jp2ecw.html
                                                                      • AIG, Arc/Info Binary Grid: <http://www.gdal.org/frmt_various.html#AIG>
                                                                      • JP2KAK, JPEG2000 (.jp2, .j2k): <http://www.gdal.org/frmt_jp2kak.html>
                                                                      "},{"location":"data/raster/gdal/#installing-gdal-extension","title":"Installing GDAL extension","text":"

                                                                      From GeoServer version 2.2.x, GDAL must be installed as an extension. To install it:

                                                                      1. Visit the website download page, locate your release, and download: gdal

                                                                        Warning

                                                                        Ensure to match plugin (example 2.24.2 above) version to the version of the GeoServer instance.

                                                                      2. The download link for GDAL will be in the Extensions section under Coverage Format.

                                                                      • Extract the files in this archive to the WEB-INF/lib directory of your GeoServer installation. On Windows You may be prompted for confirmation to overwrite existing files, confirm the replacement of the files

                                                                      Moreover, in order for GeoServer to leverage these libraries, the GDAL (binary) libraries must be installed through your host system's OS. Once they are installed, GeoServer will be able to recognize GDAL data types. See below for more information.

                                                                      "},{"location":"data/raster/gdal/#installing-gdal-native-libraries","title":"Installing GDAL native libraries","text":"

                                                                      Starting with GeoServer 2.21.x the imageio-ext plugin is tested with GDAL version 3.x (tested in particular with 3.2.x and 3.4.x).

                                                                      The imageio-ext plugin is tested with the GDAL 3.2 SWIG bindings, included in the extension download as gdal-3.2.0.jar.

                                                                      "},{"location":"data/raster/gdal/#in-case-of-version-mismatch","title":"In case of version mismatch","text":"

                                                                      We recommend matching the version gdal jar to the version of gdal available in your environment:

                                                                      gdalinfo --version\n
                                                                      GDAL 3.4.1, released 2021/12/27\n

                                                                      If you are using a version of GDAL that does not match the one expected by GeoServer, you can go and replace the gdal-3.2.0.jar file with the equivalent java binding jar (typically named either gdal-<version>.jar) included with your GDAL version:

                                                                      • If your GDAL version does not include a bindings jar, it was probably not compiled with the java bindings and will not work with GeoServer.
                                                                      • You may also search for the correct gdal jar here: https://search.maven.org/artifact/org.gdal/gdal
                                                                      "},{"location":"data/raster/gdal/#windows-packages-and-setup","title":"Windows packages and setup","text":"

                                                                      For Windows, gisinternals.com provides complete packages, with Java bindings support, in the release-<version>-GDAL-<version>-mapserver-<version>.zip packages (the GDAL binary downloads at the time of writing do not include Java support).

                                                                      Unpack the zip file in a suitable location, and then set the following variables before starting up GeoServer:

                                                                      set PATH=%PATH%;C:\\<unzipped_package>\\bin;C:\\<unzipped_package>\\bin\\gdal\\java\nset GDAL_DRIVER_PATH=C:\\<unzipped_package>\\bin\\gdal\\plugins\nset GDAL_DATA=C:\\<unzipped_package>\\bin\\gdal-data\n

                                                                      There are a few optional drivers that you can find in [file:C:\\](file:%60C:\\)<unzipped_package>bingdalplugins-extra and C:<unzipped_package>bingdalplugins-optional. Include these paths in `GDAL_DRIVER_PATH enables the additional formats.

                                                                      Warning

                                                                      Before adding the extra formats please make sure that you are within your rights to use them in a server environment (some packages are specifically forbidden from free usage on the server side and require a commercial licence, e.g., ECW).

                                                                      Note

                                                                      Depending on the version of the underlying operating system you will have to pick up the right one. You can google around for the one you need. Also make sure you download the 32 bit version if you are using a 32 bit version of Windows or the 64 bit version (has a \"-x64\" suffix in the name of the zip file) if you are running a 64 bit version of Windows. Again, pick the one that matches your infrastructure.

                                                                      "},{"location":"data/raster/gdal/#note-on-running-geoserver-as-a-service-on-windows","title":"Note on running GeoServer as a Service on Windows","text":"

                                                                      Deploying the GDAL ImageI/O-Ext native libraries in a location referred by the PATH environment variable (like, as an instance, the JDK/bin folder) will not allow the GeoServer service to use GDAL. As a result, during the service startup, GeoServer log will likely report the following message:

                                                                      it.geosolutions.imageio.gdalframework.GDALUtilities loadGDAL\nWARNING: Native library load failed.java.lang.UnsatisfiedLinkError: no gdaljni in java.library.path\n

                                                                      Taking a look at the jsl74.ini configuration file available inside the GeoServer installation , there is this useful entry:

                                                                      ;The java command line\n;The entry method below using a parameter list still works but the command line variant is more convenient.\n;Everything separated by whitespace on a java command line is broken down into a parameter here. \n;You don't need to care about quotes\n;around strings containing spaces here. e.g. \ncmdline = -cp \"..\\src\" com.roeschter.jsl.TelnetEcho\n

                                                                      To allow the GDAL native DLLs to be loaded:

                                                                      1. Edit the command line to include -Djava.library.path with the location of your GDAL libraries.
                                                                      "},{"location":"data/raster/gdal/#linux-packages-and-setup","title":"Linux packages and setup","text":"

                                                                      For common LTS Linux distribution there are packages for GDAL and the associated Java bindings, e.g., on Ubuntu and derivatives you can install them using:

                                                                      sudo apt-get install gdal-bin libgdal-java\n

                                                                      The libraries as installed above are already in the search path, so no extra setup is normally needed. In case setting up the GDAL_DATA is required to handle certain projections, it's normally found in /usr/share/gdal/<version>, so you can execute the following prior to start GeoServer, e.g:

                                                                      export GDAL_DATA=/usr/share/gdal/<version>\n

                                                                      In case you decide to build from sources instead, remember to run configure with --with-java, and after the main build and install, get into the swig/java and run a build and install there. For more information about building GDAL see:

                                                                      • General build information
                                                                      • Specific info to build GDAL Java bindings

                                                                      After the build and installation, export the following variables to make GeoServer use the GDAL custom build:

                                                                      export LD_LIBRARY_PATH=/<path_to_gdal_install>/lib\nexport GDAL_DATA=/<path_to_gdal_install>/share/gdal\n
                                                                      "},{"location":"data/raster/gdal/#testing-the-installation","title":"Testing the installation","text":"

                                                                      Once these steps have been completed, restart GeoServer.

                                                                      Navigate to About > Server Status page, and change to the Modules tab, and click **** link for status information.

                                                                      ImageI/O GDAL Coverage Extension Module Status

                                                                      This information can be used to verify that the extension is active, the version of GDAL used, and the version of the SWIG bindings used.

                                                                      If all the steps have been performed correctly, new data formats will be in the Raster Data Sources list when creating a new data store in the Stores section as shown here below.

                                                                      GDAL image formats in the list of raster data stores

                                                                      If new formats do not appear in the GUI and you see the following message in the log file:

                                                                      it.geosolutions.imageio.gdalframework.GDALUtilities loadGDAL WARNING: Native library load failed.java.lang.UnsatisfiedLinkError: no gdaljni in java.library.path WARNING: Native library load failed.java.lang.UnsatisfiedLinkError: no gdalalljni in java.library.path*

                                                                      This means that the extension was installed, bu twas not able to access your gdal library for some reason.

                                                                      "},{"location":"data/raster/gdal/#configuring-a-dted-data-store","title":"Configuring a DTED data store","text":"

                                                                      Configuring a DTED data store

                                                                      "},{"location":"data/raster/gdal/#configuring-a-ehdr-data-store","title":"Configuring a EHdr data store","text":"

                                                                      Configuring a EHdr data store

                                                                      "},{"location":"data/raster/gdal/#configuring-a-erdasimg-data-store","title":"Configuring a ERDASImg data store","text":"

                                                                      Configuring a ERDASImg data store

                                                                      "},{"location":"data/raster/gdal/#configuring-a-jp2mrsid-data-store","title":"Configuring a JP2MrSID data store","text":"

                                                                      Configuring a JP2MrSID data store

                                                                      "},{"location":"data/raster/gdal/#configuring-a-nitf-data-store","title":"Configuring a NITF data store","text":"

                                                                      Configuring a NITF data store

                                                                      "},{"location":"data/raster/gdal/#supporting-vector-footprints","title":"Supporting vector footprints","text":"

                                                                      Starting with version 2.9.0, GeoServer supports vector footprints. A footprint is a shape used as a mask to hide those pixels that are outside of the mask, hence making that part of the parent image transparent. The currently supported footprint formats are WKB, WKT and Shapefile. By convention, the footprint file should be located in the same directory as the raster data that the footprint applies to.

                                                                      Note

                                                                      In the examples of this section and related subsections, we will always use .wkt as extension, representing a WKT footprint, although both .wkb and .shp are supported too.

                                                                      For example, supposing you have a MrSID file located at /mnt/storage/data/landsat/N-32-40_2000.sid to be masked, you just need to place a WKT file on the same folder, as /mnt/storage/data/landsat/N-32-40_2000.wkt Note that the footprint needs to have same path and name of the original data file, with .wkt extension.

                                                                      This is how the sample footprint geometry looks:

                                                                      A sample geometry stored as WKT, rendered on OpenJump

                                                                      Once footprint file has been added, you need to change the FootprintBehavior parameter from None (the default value) to Transparent, from the layer configuration.

                                                                      Setting the FootprintBehavior parameter

                                                                      The next image depicts 2 layer previews for the same layer: the left one has no footprint, the right one has a footprint available and FootprintBehavior set to transparent.

                                                                      No Footprint VS FootprintBehavior = Transparent

                                                                      "},{"location":"data/raster/gdal/#external-footprints-data-directory","title":"External Footprints data directory","text":"

                                                                      As noted above, the footprint file should be placed in the same directory as the raster file. However in some cases this may not be possible. For example, the folder containing the raster data may be read only.

                                                                      As an alternative, footprint files can be located in a common directory, the footprints data directory. The subdirectories and file names under that directory must match the original raster path and file names. The footprints data directory is specified as a Java System Property or an Environment Variable, by setting the FOOTPRINTS_DATA_DIR property/variable to the directory to be used as base folder.

                                                                      "},{"location":"data/raster/gdal/#example","title":"Example","text":"

                                                                      Suppose you have 3 raster files with the following paths:

                                                                      • /data/raster/charts/nitf/italy_2015.ntf
                                                                      • /data/raster/satellite/ecw/orthofoto_2014.ecw
                                                                      • /data/raster/satellite/landsat/mrsid/N-32-40_2000.sid

                                                                      They can be represented by this tree:

                                                                      /data\n \\---raster\n     +---charts\n     |   \\---nitf\n     |           italy_2015.ntf\n     |\n     \\---satellite\n         +---ecw\n         |       orthofoto_2014.ecw\n         |\n         \\---landsat\n             \\---mrsid\n                     N-32-40_2000.sid\n

                                                                      In order to support external footprints you should

                                                                      1. Create a /footprints (as an example) directory on disk
                                                                      2. Set the FOOTPRINTS_DATA_DIR=/footprints variable/property.
                                                                      3. Replicate the rasters folder hierarchy inside the specified folder, using the full paths.
                                                                      4. Put the 3 WKT files in the proper locations:

                                                                      5. /footprints/data/raster/charts/nitf/italy_2015.wkt

                                                                      6. /footprints/data/raster/satellite/ecw/orthofoto_2014.wkt
                                                                      7. /footprints/data/raster/satellite/landsat/mrsid/N-32-40_2000.wkt

                                                                      Which can be represented by this tree:

                                                                      /footprints\n \\---data\n     \\---raster\n         +---charts\n         |   \\---nitf\n         |           italy_2015.wkt\n         |\n         \\---satellite\n             +---ecw\n             |       orthofoto_2014.wkt\n             |\n             \\---landsat\n                 \\---mrsid\n                         N-32-40_2000.wkt\n

                                                                      Such that, in the end, you will have the following folders hierarchy tree:

                                                                      +---data\n|   \\---raster\n|       +---charts\n|       |   \\---nitf\n|       |           italy_2015.ntf\n|       |\n|       \\---satellite\n|           +---ecw\n|           |       orthofoto_2014.ecw\n|           |\n|           \\---landsat\n|               \\---mrsid\n|                       N-32-40_2000.sid\n|\n\\---footprints\n    \\---data\n        \\---raster\n            +---charts\n            |   \\---nitf\n            |           italy_2015.wkt\n            |\n            \\---satellite\n                +---ecw\n                |       orthofoto_2014.wkt\n                |\n                \\---landsat\n                    \\---mrsid\n                            N-32-40_2000.wkt\n

                                                                      Note the parallel mirrored folder hierarchy, with the only differences being a /footprints prefix at the beginning of the path, and the change in suffix.

                                                                      "},{"location":"data/raster/geopkg/","title":"GeoPackage","text":"

                                                                      GeoPackage is an SQLite based standard format that is able to hold multiple vector and raster data layers in a single file.

                                                                      GeoPackage files can be used both as Vector Data Stores as well as Raster Data Stores (so that both kinds of layers can published).

                                                                      "},{"location":"data/raster/geopkg/#adding-a-geopackage-raster-mosaic-data-store","title":"Adding a GeoPackage Raster (Mosaic) Data Store","text":"

                                                                      By default, GeoPackage (mosaic) will be an option in the Raster Data Sources list when creating a new data store.

                                                                      GeoPackage (mosaic) in the list of raster data stores

                                                                      Configuring a GeoPackage (mosaic) data store

                                                                      Option Description Workspace Name of the workspace to contain the GeoPackage Mosaic store. This will also be the prefix of the raster layers created from the store. Data Source Name Name of the GeoPackage Mosaic Store as it will be known to GeoServer. This can be different from the filename. ) Description A full free-form description of the GeoPackage Mosaic Store. Enabled If checked, it enables the store. If unchecked (disabled), no data in the GeoPackage Mosaic Store will be served from GeoServer. URL Location of the GeoPackage file. This can be an absolute path (such as file:C:\\Data\\landbase.gpkg) or a path relative to GeoServer's data directory (such as file:data/landbase.gpkg).

                                                                      When finished, click Save.

                                                                      "},{"location":"data/raster/geotiff/","title":"GeoTIFF","text":"

                                                                      A GeoTIFF is a georeferenced TIFF (Tagged Image File Format) file.

                                                                      "},{"location":"data/raster/geotiff/#adding-a-geotiff-data-store","title":"Adding a GeoTIFF data store","text":"

                                                                      By default, GeoTIFF will be an option in the Raster Data Sources list when creating a new data store.

                                                                      GeoTIFF in the list of raster data stores

                                                                      "},{"location":"data/raster/geotiff/#configuring-a-geotiff-data-store","title":"Configuring a GeoTIFF data store","text":"

                                                                      Configuring a GeoTIFF data store

                                                                      Option Description Workspace Name of the workspace to contain the GeoTIFF store. This will also be the prefix of the raster layer created from the store. Data Source Name Name of the GeoTIFF as it will be known to GeoServer. This can be different from the filename. The combination of the workspace name and this name will be the full layer name (ex: world:landbase) Description A full free-form description of the GeoTIFF store. Enabled If checked, it enables the store. If unchecked (disabled), no data in the GeoTIFF will be served from GeoServer. URL Location of the GeoTIFF file. This can be an absolute path (such as file:C:\\Data\\landbase.tif) or a path relative to GeoServer's data directory (such as file:data/landbase.tif).

                                                                      Note

                                                                      Notice that the GeoTiff plugin is able to handle internal/external overviews and internal/external masks.

                                                                      "},{"location":"data/raster/geotiff/#custom-crs-definition","title":"Custom CRS definition","text":"

                                                                      Creating an auxiliary .prj file that contains coordinate reference system information as described in the Custom CRS Definitions chapter will override internal CRS tags that are included in the original GeoTIFF file. This can be used to work-around problematic source files without making modifications to the file.

                                                                      "},{"location":"data/raster/imagepyramid/","title":"ImagePyramid","text":"

                                                                      Note

                                                                      GeoServer does not come built-in with support for Image Pyramid; it must be installed through an extension. Proceed to Installing the ImagePyramid extension for installation details.

                                                                      An image pyramid is several layers of an image rendered at various image sizes, to be shown at different zoom levels.

                                                                      "},{"location":"data/raster/imagepyramid/#imagepyramid_install","title":"Installing the ImagePyramid extension","text":"
                                                                      1. Visit the website download page, locate your release, and download: pyramid

                                                                        Warning

                                                                        Ensure to match plugin (example 2.24.2 above) version to the version of the GeoServer instance.

                                                                      2. Extract the contents of the archive into the WEB-INF/lib directory of the GeoServer installation.

                                                                      "},{"location":"data/raster/imagepyramid/#adding-an-imagepyramid-data-store","title":"Adding an ImagePyramid data store","text":"

                                                                      Once the extension is properly installed ImagePyramid will be an option in the Raster Data Sources list when creating a new data store.

                                                                      ImagePyramid in the list of raster data stores

                                                                      "},{"location":"data/raster/imagepyramid/#configuring-an-imagepyramid-data-store","title":"Configuring an ImagePyramid data store","text":"

                                                                      Configuring an ImagePyramid data store

                                                                      Option Description Workspace Data Source Name Description Enabled URL"},{"location":"data/raster/worldimage/","title":"WorldImage","text":"

                                                                      A world file is a plain text file used to georeference raster map images. This file (often with an extension of .jgw or .tfw) accompanies an associated image file (.jpg or .tif). Together, the world file and the corresponding image file is known as a WorldImage in GeoServer.

                                                                      "},{"location":"data/raster/worldimage/#adding-a-worldimage-data-store","title":"Adding a WorldImage data store","text":"

                                                                      By default, WorldImage will be an option in the Raster Data Sources list when creating a new data store.

                                                                      WorldImage in the list of raster data stores

                                                                      "},{"location":"data/raster/worldimage/#configuring-a-worldimage-data-store","title":"Configuring a WorldImage data store","text":"

                                                                      Configuring a WorldImage data store

                                                                      Option Description Workspace Data Source Name Description Enabled URL"},{"location":"data/raster/imagemosaic/","title":"ImageMosaic","text":"

                                                                      The ImageMosaic data store allows the creation of a mosaic from a number of georeferenced rasters.

                                                                      The mosaic operation creates a mosaic from two or more source images. This operation could be used to assemble a set of overlapping geospatially rectified images into a contiguous image. It could also be used to create a montage of photographs such as a panorama.

                                                                      The plugin can be used with GeoTIFFs, as well as rasters accompanied by a world file (.wld, .pgw for PNG files, .jgw for JPG files, etc.). In addition, if imageIO-ext GDAL extension is properly installed, the plugin can also serve all the formats supported by it such as MrSID, ECW, JPEG2000. It also supports NetCDF and GRIB.

                                                                      • ImageMosaic configuration
                                                                      • Using the ImageMosaic extension
                                                                      "},{"location":"data/raster/imagemosaic/configuration/","title":"ImageMosaic configuration","text":""},{"location":"data/raster/imagemosaic/configuration/#granules","title":"Granules","text":"

                                                                      Each individual image is commonly referred to as a granule. In recent releases of GeoServer the similarities requirements for the granules have been dropped significantly, including:

                                                                      • The granules do not need to share the same coordinate reference system (see the multi-CRS mosaic tutorial)
                                                                      • The granules can be in different color models, with an allowance of mixing gray, RGB, RGBA and indexed color granules (it is however not possible to mix colored granules with scientific data types like as float/double). In order to benefit of mixed color models JAI-Ext support must be enabled, see the JAI-EXT support documentation.

                                                                      In addition it is worth remarking on the fact that currently the ImageMosaic is able to handle raster data whose grid-to-world transformation is a scale and translate transformation, hence no rotation or skew.

                                                                      "},{"location":"data/raster/imagemosaic/configuration/#index-and-configuration-file-creation","title":"Index and configuration file creation","text":"

                                                                      When a new store is created, an index shapefile will be generated to associate each granule file with its bounding box. The index creation respects directory trees as well as single directories. All you need to do is point the store to the root of the hierarchy, and all images will be considered for inclusion in the ImageMosaic.

                                                                      The index will contain the enclosing polygon for each raster file (in an appropriate coordinate reference system) and the path to each of these files. The location attribute can be relative to the configuration folder or absolute. By default, the name of this attribute is location, but this can be changed in the main configuration file.

                                                                      If you already have these files generated, GeoServer will respect them and not generate a new index. By default, a shapefile is used for the index, but PostGIS, H2, and Oracle are also supported, with additional configuration steps.

                                                                      "},{"location":"data/raster/imagemosaic/configuration/#configuration-files","title":"Configuration files","text":"

                                                                      Within each store there are multiple configuration files that determine how the mosaic is rendered.

                                                                      Note

                                                                      The property file syntax uses a few reserved chars that need escaping in order to be used for keys or values. For example, the # character is used to comment out lines, in order to use it in values it needs to be escaped, like this: \\#. The same applies to the = character, which is used to separate the property name from its value: it should be specified as \\=. Finally, if there is a need to use the ` itself, it will have to be escaped as well:`.

                                                                      "},{"location":"data/raster/imagemosaic/configuration/#primary-configuration-file","title":"Primary configuration file","text":"

                                                                      The mosaic configuration file is the primary file used to store the configuration parameters that control the ImageMosaic plugin. When created by GeoServer it is by default called <directory>.properties, where <directory> is the name of the root directory of the store. (It is not related to the store name in GeoServer.) It can have other names, as long as it does not conflict with other files such as datastore.properties or indexer.properties. This file usually does not require manual editing.

                                                                      The table below describes the various elements in this configuration file.

                                                                      Parameter Mandatory? Description Levels Y Represents the resolutions for the various levels of the granules of this mosaic. Heterogeneous N Sets whether the image files are heterogeneous. Default is false. AbsolutePath N Controls whether or not the path stored inside the location attribute represents an absolute path or a path relative to the location of the shapefile index. Notice that a relative index ensures much more portability of the mosaic itself. Default value for this parameter is false, which means relative paths. Name N The name to be assigned to the index. If unspecified, the index name will usually match the name of the folder containing the mosaic. TypeName Y Featuretype name for this mosaic. Usually the name as Name. Caching N Boolean value to enable caching. When set to true, the ImageMosaic will try to save in memory the entire contents of the index to reduce loading/query time. Set to false for a large granule index and/or if new granules are to be ingested (for example, when the index is on a database and we interact directly with it). Default is false. ExpandToRGB N Boolean flag to force color expansion from index color model (paletted datasets) to component color model (RGB). Default is false. LocationAttribute Y The name of the attribute path in the shapefile index. Default is location. SuggestedSPI Y Suggested plugin for reading the image files. SuggestedFormat N Suggested GridFormat for reading the image files. Envelope2D N Envelope for the mosaic formatted as LLX,LLY URX,URY (notice the space between the lower left and upper right coordinate pairs). CheckAuxiliaryMetadata N This parameter allows to specify whether the ImageMosaic plugin should check for the presence of a GDAL aux.xml file beside each granule file. For most common use cases, you don't need to set or specify this parameter. Being disabled by Default, ImageMosaic won't look for an ancillary file for each granule being initialized in the GranuleCatalog. This avoid useless checks, especially when dealing with thousand of granules. You should set that parameter to true when you want to instruct the ImageMosaic to look for a GDAL generated aux.xml file containing PAM (Persistent Auxiliary Metadata) for each granule, to be attached to the Granule info (GranuleDescriptor). This is specially useful when you have setup a Dynamic ColorMap rendering transformation which dynamically set a color map based on the statistics collected into the granule's GDAL PAM being previously generated with a gdalinfo -stats parameter. LevelsNum Y Represents the number of reduced resolution layers that we currently have for the granules of this mosaic.

                                                                      A sample configuration file follows:

                                                                      Levels=0.4,0.4\nHeterogeneous=false\nAbsolutePath=false\nName=osm\nTypeName=osm\nCaching=false\nExpandToRGB=false\nLocationAttribute=location\nSuggestedSPI=it.geosolutions.imageioimpl.plugins.tiff.TIFFImageReaderSpi\nSuggestedFormat=org.geotools.gce.geotiff.GeoTiffFormat\nCheckAuxiliaryMetadata=false\nLevelsNum=1\n
                                                                      "},{"location":"data/raster/imagemosaic/configuration/#mosaic_datastore_properties","title":"datastore.properties","text":"

                                                                      By default the ImageMosaic index is specified by a shapefile, which is located at the root of the ImageMosaic directory, just like the primary configuration file.

                                                                      If needed, different storage can be used for the index --- like a spatial DBMS, which is the preferred solution when you wish to share the ImageMosaic itself in a cluster of GeoServer instances. In this case the user must supply GeoServer with the proper connection parameters, which can be specified by using a datastore.properties file placed at the root of the ImageMosaic directory.

                                                                      Note

                                                                      A shapefile is created automagically if it does not exist or if there is no datastore.properties file.

                                                                      Warning

                                                                      At the time of writing the following spatial DBMS have been tested successfully: Oracle, PostgreSQL, H2, SQLServer.

                                                                      +-----------------------+------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Parameter | Mandatory? | Description | +=======================+============+==================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================+ | StoreName | N | Can be used to refer to a GeoServer registered store, using a \"workspace:storeName\" syntax. When this is used, the no other connection parameters need to be provided. The SPI can still be provided to inform the mosaic of the resulting type of store (e.g., Oracle) in case specific behavior need to be enacted for it (e.g., in the case of Oracle the attributes are all uppercase and cannot be longer than 30 chars, the mosaic will respect the limits but the SPI parameter needs to be explicitly set to org.geotools.data.oracle.OracleNGDataStoreFactory as the actual store type is hidden when it reaches the mosaic code). Also, as a reminder, the code is picking up a Store reference, not a layer one, meaning that security restrictions that might have been applied to a layer exposing the feature type do not apply to the mosaic code (e.g., if a user has restrictions such as a spatial filter on said layer, it won't transfer to the mosaic, which needs to be secured separately) | +-----------------------+------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | SPI | Y | The DataStoreFactory used to connect to the index store: | | | | | | | | - PostGIS: org.geotools.data.postgis.PostgisNGDataStoreFactory | | | | - Oracle: org.geotools.data.oracle.OracleNGDataStoreFactory | | | | - H2: org.geotools.data.h2.H2DataStoreFactory | | | | - SQLServer: org.geotools.data.sqlserver.SQLServerDataStoreFactory | | | | | | | | JNDI can also be used with any of these stores. If JNDI is used, the DataStoreFactory name will differ from the above. | +-----------------------+------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Connection parameters | Y | The connection parameters used by the specified SPI. The list of these connection parameters can be found in the GeoTools documentation on the relevant store: | | | | | | | | - PostGIS | | | | - Oracle | | | | - H2 | | | | - SQLServer | | | | | | | | If JNDI is used, the connection parameters will include jndiReferenceName instead of host, port, etc. Note that for any connection parameters that include a space (such as loose bbox), the space must be escaped by preceding it with a backslash (loose\\ bbox). | +-----------------------+------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+

                                                                      Here is a sample datastore.properties file for a PostGIS index:

                                                                      SPI=org.geotools.data.postgis.PostgisNGDataStoreFactory\nhost=localhost\nport=5432\ndatabase=osm\nschema=public\nuser=user\npasswd=password\nLoose\\ bbox=true\nEstimated\\ extends=false\nvalidate\\ connections=true\nConnection\\ timeout=10\npreparedStatements=true\n

                                                                      Here is a sample datastore.properties file for a PostGIS index via JNDI:

                                                                      SPI=org.geotools.data.postgis.PostgisNGJNDIDataStoreFactory\n#String\n# JNDI data source\n# Default \"java:comp/env/\"+\"jdbc/mydatabase\"\njndiReferenceName=\n\n#Boolean\n# perform only primary filter on bbox\n# Default Boolean.TRUE\nLoose\\ bbox=true\n\n#Boolean\n# use prepared statements\n#Default Boolean.FALSE\npreparedStatements=false\n
                                                                      "},{"location":"data/raster/imagemosaic/configuration/#indexerproperties","title":"indexer.properties","text":"

                                                                      In addition to the required envelope and location attributes, the schema for the index store may expose other custom attributes which can be used later for filtering the ImageMosaic granules on the fly during a WMS or WCS request or to diver WMS and WCS dimensions like TIME, ELEVATION and so on. This is configured by the indexer.properties file:

                                                                      Parameter Mandatory? Description Schema Y A comma-separated sequence describing the mapping between attribute and data type. PropertyCollectors Y A comma-separated list of PropertyCollectors. Each entry in the list includes the extractor class, the file name (within square brackets [ ] and not including the .properties suffix) containing the regular expression needed to extract the attribute value from the granule file name, and the attribute name (within parentheses ( )). The instance of the extractor class also indicates the type of object computed by the specific collector, so a TimestampFileNameExtractorSPI will return Timestamps while a DoubleFileNameExtractorSPI will return Double numbers. TimeAttribute N Specifies the name of the time-variant attribute. ElevationAttribute N Specifies the name of the elevation attribute. AuxiliaryFile N Path to an auxiliary file to be used for internal purposes (For example: when dealing with NetCDF granules, it refers to the NetCDF XML ancillary file.) AbsolutePath N Controls whether or not the path stored inside the location attribute represents an absolute path or a path relative to the location of the shapefile index. Notice that a relative index ensures better portability of the mosaic itself. Default value for this parameter is false, which means relative paths. Caching N Boolean value to enable caching. When set to true, the ImageMosaic will try to save in memory the entire contents of the index to reduce loading/query time. Set to false for a large granule index and/or if new granules are to be ingested (for example, when the index is on a database and we interact directly with it). Default is false. CanBeEmpty N Boolean flag used for configuring empty mosaics. When enabled the ImageMosaic will not throw an exception caused by the absence of any coverage. By default it is set to false. Envelope2D N Envelope for the mosaic formatted as LLX,LLY URX,URY (notice the space between the lower left and upper right coordinate pairs). ExpandToRGB N Boolean flag to force color expansion from index color model (paletted datasets) to component color model (RGB). Default is false. IndexingDirectories N Comma separated values list of paths referring to directories containing granules to be indexed. If unspecified, the IndexingDirectory will be the mosaic configuration directory. This parameter allows configuration of a mosaic in a folder which contains only configuration files, while the granules to be indexed are stored somewhere else. Name N The name to be assigned to the index. If unspecified, the index name will usually match the name of the folder containing the mosaic. NoData N Specifies the NoData for the mosaic. (This might be useful, as an instance, when imposing the Envelope2D. At time of ImageMosaic's initialization, a small 5x5 pixels sample read is performed by ImageMosaic on the Envelope's corner in order to retrieve granule's metadata and properties, as nodata. If Envelope2D is forced in configuration, there might be the case that this sample read will not involve any actual granule so a default noData will be set which may be different with respect to what is actually stored on granules. Specifying the desired NoData property in indexer will solve this type of issue). CoverageNameCollectorSPI N As described in the previous row, the Name parameter allows specification of the coverage name to be exposed by the ImageMosaic. An ImageMosaic of NetCDFs instead exposes a coverage for each supported variable found in the NetCDF, using the variable's name as the coverage name (for instance, air_temperature, wind_speed, etc.) The optional CoverageNameCollectorSPI property allows specification of a CoverageNameCollector plugin to be used to instruct the ImageMosaic on how to setup different coverageNames for granules. It should contains the full name of the implementing class plus an optional set of semicolon-separated keyValue pairs prefixed by \":\". See below for an example. Recursive N Boolean flag used at indexing time. When set to true, the indexer will look for granules by scanning any subdirectory contained in the indexing directory. If false, only the main folder will be analyzed. Default is true. UseExistingSchema N Boolean flag used for enabling/disabling the use of existing schemas. When enabled, the ImageMosaic will start indexing granules using the existing database schema (from datastore.properties) instead of populating it. This is useful when you already have a database with a valid mosaic schema (the_geom, location and other attributes, take a look at gdalindex) or when you do not want to rename the images to add times and dimensions (you should simply add them to the table, to AdditionalDomainAttributes and to PropertyCollectors). Default is false. Wildcard N Wildcard used to specify which files should be scanned by the indexer. (For instance: \"*.tif\"). Currently, logic operators and lists aren't supported, so this field is limited to a single wildcard element with no support for AND/OR operators combinations. WrapStore N By default, Postgresql identifiers can't be longer than 63 chars. Longer names will be truncated to that fixed length. When dealing with multidimensional datasets (for instance: NetCDFs, GRIBs) each variable (NetCDF) or parameter (GRIB) is indexed into a table with the same name. Therefore an atmosphere-absorption-optical-thickness-due-to-particulate-organic-matter-ambient-aerosol-particles NetCDF CF variable will be associated to a table with the same name. Postgresql will truncate that to atmosphere-absorption-optical-thickness-due-to-particulate-orga breaking the one-to-one mapping and therefore breaking the proper functioning. Setting the WrapStore flag to true will establish a hidden mapping between full long names and truncated table names to support proper working. MosaicCRS N The \"native\" CRS of the mosaic, that is, the one in which footprints are collected. Useful when dealing with granules in multiple CRSs (see tutorial) AdditionalDomainAttributes N Comma separate list of custom dimensions to be exposed. Each custom dimension declaration can be a simple attribute name from the schema, e.g., runtime, a mapping from dimension name to attribute name, e.g. time2(runtime), or a mapping from a range dimension name to two attributes, e.g., timerange(timeStart,timeEnd) PropertySelection N Boolean value to enable/disable selection of properties from the mosaic index. Default is false. When enabled, the ImageMosaic will try to load in memory only the properties needed to perform mosaicking. A typical use case is using a STAC API as a mosaic index, a STAC item typically contains many complex properties, and the API might be remote, reducing the payload improves both query time and memory usage.

                                                                      Here is a sample indexer.properties file:

                                                                      Schema=*the_geom:Polygon,location:String,ingestion:java.util.Date,elevation:Double\nPropertyCollectors=TimestampFileNameExtractorSPI[timeregex](ingestion),DoubleFileNameExtractorSPI[elevationregex](elevation)\nTimeAttribute=ingestion\nElevationAttribute=elevation\nCaching=false\nAbsolutePath=false\n

                                                                      An example of optional CoverageNameCollectorSPI could be:

                                                                      CoverageNameCollectorSPI=org.geotools.gce.imagemosaic.namecollector.FileNameRegexNameCollectorSPI:regex=^([a-zA-Z0-9]+)\n

                                                                      This defines a regex-based name collector which extracts the coverage name from the prefix of the file name, so that an ImageMosaic with temperature_2015.tif, temperature_2016.tif, pressure_2015.tif, pressure_2016.tif will put temperature granules on a temperature coverage and pressure granules on a pressure coverage.

                                                                      Note

                                                                      The extraction works from the match of the full regular expression, if there are no capturing groups. If there are capturing groups instead, the match will be the concatenation of the text matched by all the capturing groups. This can be used to simplify the regular expression, for example, in order to match a string surrounded by underscores, regex=.*_(\\\\w+)_.* can be used instead of the more complex regex=(?<\\=_)\\\\w+(?\\=_) (using non capturing groups instead).

                                                                      "},{"location":"data/raster/imagemosaic/configuration/#property-collectors","title":"Property collectors","text":"

                                                                      The following table enumerates the available property collectors

                                                                      Collector SPI name Description ByteFileNameExtractorSPI DoubleFileNameExtractorSPI FloatFileNameExtractorSPI IntegerFileNameExtractorSPI LongFileNameExtractorSPI ShortFileNameExtractorSPI Extracts an number from the file name using a regular expression specified in a sidecar file, casting it to the desired type based on the SPI name (e..g, DoubleFileNameExtractorSPI extracts double precision floating points, IntegerFileNameExtractorSPI extracts 32 bit integers) TimestampFileNameExtractorSPI Extracts a timestamp from the filename using a regular expression specified in a sidecar file StringFileNameExtractorSPI Extracts a string from the filename using a regular expression specified in a sidecar file CurrentDateExtractorSPI Returns the current date and time (useful to track ingestion times in a mosaic) FSDateExtractorSPI Returns the creation date of the file being harvested DateExtractorSPI Returns the date found in tiff file header \"DateTime\" (code 306) ResolutionExtractorSPI ResolutionXExtractorSPI ResolutionYExtractorSPI Returns the native resolution of the raster being harvested. ResolutionExtractorSPI and ResolutionXExtractorSPI return the x resolution of the raster, ResolutionYExtractorSPI returns the resolution on the Y axis instead CRSExtractorSPI Returns the code of the raster coordinate reference system, as a string, e.g. \"EPSG:4326\"

                                                                      The PropertyCollectors parameter in the example above indicates two additional .properties files used to populate the ingestion and elevation attributes:

                                                                      timeregex.properties:

                                                                      regex=[0-9]{8}T[0-9]{9}Z(\\?!.*[0-9]{8}T[0-9]{9}Z.*)\n

                                                                      The above is a property file containing a regex used to extract Date and Time represented in ISO-8601 as part of the filename. (Note the T char between digits for date and digits for time, as per ISO-8601)

                                                                      In case of custom format datetimes in filename, an additional format element should be added after the regex, preceded by a comma, defining the custom representation.

                                                                      | Example: | Temperature_2017111319.tif | an hourly Temperature file with datetime = November, 13 2017 at 7:00 PM (the last 2 digits = 19) | | In that case, the timeregex.properties file should be like this:

                                                                      regex=.([0-9]{10}).,format=yyyyMMddHH

                                                                      In case of reduced precision of temporal information, where there is the need to get the higher time included in that reduced value, an additional ,useHighTime=true element should be added.

                                                                      | Example: | Temperature_2017111319.tif | an hourly Temperature file with datetime = November, 13 2017 at 19h 00m 00s 000ms | You want to get the max time included in that reduced precision, which is November, 13 2017 at 19h 59m 59s 999ms | | In that case, the timeregex.properties file should be like this:

                                                                      regex=.([0-9]{10}).,format=yyyyMMddHH,useHighTime=true

                                                                      In case the temporal information is spread along the whole file path, an additional ,fullPath=true element should be added.

                                                                      | Example: | /data/20120202/Temperature.T1800.tif | an hourly Temperature tif file with Year,Month and Day specified in the parent folder (20120202) and time value embedded in the name (Temperature.T1800.tif) | | In that case, the timeregex.properties file should be like this:

                                                                      regex=(?:/)(\\d{8})(?:/)(?:Temperature.)(T\\d{4})(?:.tif),fullPath=true

                                                                      elevationregex.properties:

                                                                      regex=(?<=_)(\\\\d{4}\\\\.\\\\d{3})(?=_)\n
                                                                      "},{"location":"data/raster/imagemosaic/configuration/#store-parameters","title":"Store parameters","text":"

                                                                      By default, ImageMosaic will be an option in the Raster Data Sources list when creating a new data store.

                                                                      ImageMosaic in the list of raster data stores

                                                                      Configuring an ImageMosaic data store

                                                                      Option Description Workspace Workspace for the store Data Source Name Name of the store Description Description of the store Enabled Determines whether the store is enabled. If unchecked, all layers in the store will be disabled. URL The location of the store. Can be a local directory."},{"location":"data/raster/imagemosaic/configuration/#coverage-parameters","title":"Coverage parameters","text":"

                                                                      Creation of the store is the first step to getting an ImageMosaic published in GeoServer. Most of the configuration is done when publishing the resulting coverage (layer).

                                                                      The Coverage Editor gives users the possibility to set a few control parameters to further control the mosaic creation process.

                                                                      Coverage parameters

                                                                      The parameters are as follows:

                                                                      +---------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Parameter | Description | +=================================+===================================================================================================================================================================================================================================================================================================================================================================================================================+ | Accurate resolution computation | Boolean value. If true, computes the resolution of the granules in 9 points: the corners of the requested area and the middle points, taking the better one. This will provide better results for cases where there is a lot more deformation on a subregion (top/bottom/sides) of the requested bounding box with respect to others. If false, computes the resolution using a basic affine scale transform. | +---------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | AllowMultithreading | If true, enables multithreaded tile loading. This allows performing parallelized loading of the granules that compose the mosaic. Setting this to true makes sense only if you set USE_JAI_IMAGEREAD to false at the same time to force immediate loading of data into memory. | +---------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | BackgroundValues | Sets the value of the mosaic background. Depending on the nature of the mosaic it is wise to set a value for the \"nodata\" area (usually -9999). This value is repeated on all the mosaic bands. | +---------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Filter | Sets the default mosaic filter. It should be a valid ECQL query to be used by default if no cql_filter is specified (instead of Filter.INCLUDE). This filter will be applied against the mosaic index, and may include any attributes exposed by the index store. If the cql_filter is specified in the request it will be overridden. | | | | | | ::: note | | | ::: title | | | Note | | | ::: | | | | | | Do not use this filter to change time or elevation dimensions defaults. It will be added as AND condition with CURRENT for \"time\" and LOWER for \"elevation\". | | | ::: | +---------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | FootprintBehavior | Sets the behavior of the regions of a granule that are outside of the granule footprint. Can be None (ignore the footprint), Cut (remove regions outside the footprint from the image and don't add an alpha channel), or Transparent (make regions outside the footprint completely transparent, and add an alpha channel if one is not already present). Defaults to None. | +---------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | InputTransparentColor | Sets the transparent color of the granules prior to processing by the ImageMosaic plugin, in order to control how they are superimposed. When GeoServer composes the granules to satisfy a user request, some can overlap others; setting this parameter with an appropriate color avoids the overlap of \"nodata\" areas between granules. See below for an example: | | | | | | | | | InputTransparentColor parameter not configured | | | | | | | | | InputTransparentColor parameter configured | +---------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | MaxAllowedTiles | Sets the maximum number of tiles that can be loaded simultaneously for a request. For large mosaics, this parameter should be set to avoid saturating the server by loading too many granules simultaneously. | +---------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | MergeBehavior | The method used to handle overlapping granules during the mosaic operation. Can be FLAT (only the topmost granule is visible in the case of an overlap) or STACK (a band-stacking merge is applied to the overlapping granules). Default is FLAT. | +---------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | OutputTransparentColor | Set the transparent color for the mosaic. This parameter make sense for RGB or paletted mosaics, but not for a DEM or MetOc data. See below for an example: | | | | | | | | | OutputTransparentColor parameter configured with \"no color\" | | | | | | | | | OutputTransparentColor parameter configured with \"nodata\" color | +---------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | SORTING | Controls the order in which the granules are passed to the mosaic operation. Only useful if MergeBehavior is set to FLAT. Should be the name of an attribute in the index file, followed by a space, followed by A for ascending, or D for descending. For example: sortattr D. | +---------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | SUGGESTED_TILE_SIZE | Controls the tile size of the input granules as well as the tile size of the output mosaic. It consists of two positive integers separated by a comma. Default is 512,512. If your data is properly tiled, you might want to set this parameter to blank to avoid unnecessarily reformatting when reading. | +---------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | USE_JAI_IMAGEREAD | Controls the low-level mechanism used to read the granules. If set to true, GeoServer will use the JAI ImageRead operation and its deferred loading mechanism. If set to false, GeoServer will perform direct ImageIO read calls, which will result in immediate loading. | | | | | | ::: note | | | ::: title | | | Note | | | ::: | | | | | | Deferred loading consumes less memory since it uses a streaming approach to only load into memory the data immediately needed for processing, but may cause problems under heavy load since it keeps the granule files open for a long time. | | | | | | Immediate loading consumes more memory since it loads the requested mosaic into memory all at once, but usually performs faster and prevents the \"too many files open\" error conditions that can occur with deferred loading. | | | ::: | +---------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+

                                                                      Continue on with the ImageMosaic tutorial to learn more and see examples.

                                                                      "},{"location":"data/raster/imagemosaic/tutorial/","title":"Using the ImageMosaic extension","text":"

                                                                      This tutorial will show you how to configure and publish an ImageMosaic store and coverage, followed by some configuration examples.

                                                                      "},{"location":"data/raster/imagemosaic/tutorial/#configuring-a-coverage-in-geoserver","title":"Configuring a coverage in GeoServer","text":"

                                                                      This is a process very similar to creating a featuretype. More specifically, one has to perform the steps highlighted in the sections below:

                                                                      "},{"location":"data/raster/imagemosaic/tutorial/#create-a-new-store","title":"Create a new store","text":"
                                                                      1. Go to Data Panel \u2192 Stores and click Add new Store.

                                                                      2. Select ImageMosaic under Raster Data Source:

                                                                        ImageMosaic in the list of raster data stores

                                                                      3. In order to create a new mosaic it is necessary to choose a workspace and store name in the Basic Store Info section, as well as a URL in the Connection Parameters section. Valid URLs include:

                                                                        • The absolute path to the shapefile index, or a directory containing the shapefile index.
                                                                        • The absolute path to the configuration file (\\*.properties````) or a directory containing the configuration file. If ````datastore.properties```` and ````indexer.properties` exist, they should be in the same directory as this configuration file.
                                                                        • The absolute path of a directory where the files you want to mosaic reside. In this case GeoServer automatically creates the needed mosaic files (.dbf, .prj, .properties, .shp and .shx) by inspecting the data present in the given directory and any subdirectories.
                                                                      4. Click Save:

                                                                        ![](images/imagemosaicconfigure.png)\n*Configuring an ImageMosaic data store*\n
                                                                      "},{"location":"data/raster/imagemosaic/tutorial/#create-a-new-coverage","title":"Create a new coverage","text":"
                                                                      1. Navigate to Data Panel --> Layers and click Add a new resource.

                                                                      2. Choose the name of the store you just created:

                                                                        ![](images/vito_newlayerchoser.png)\n*Layer Chooser*\n
                                                                      3. Click the layer you wish to configure and you will be presented with the Coverage Editor:

                                                                        ![](images/vito_coverageeditor.png)\n*Coverage Editor*\n
                                                                      4. Make sure there is a value for Native SRS, then click the Submit button. If the Native CRS is UNKNOWN, you must declare the SRS in the Declared SRS field.

                                                                      5. Click Save.

                                                                      6. Use the Layer Preview to view the mosaic.

                                                                      Warning

                                                                      If the created layer appears to be all black, it may be that GeoServer has not found any acceptable granules in the provided index. It is also possible that the shapefile index is empty (no granules were found in the provided directory) or it might be that the granules\\' paths in the shapefile index are not correct, which could happen if an existing index (using absolute paths) is moved to another place. If the shapefile index paths are not correct, then the DBF file can be opened and fixed with an editor. Alternately, you can delete the index and let GeoServer recreate it from the root directory.

                                                                      "},{"location":"data/raster/imagemosaic/tutorial/#configuration-examples","title":"Configuration examples","text":"

                                                                      Below are a few examples of mosaic configurations to demonstrate how we can make use of the ImageMosaic parameters.

                                                                      "},{"location":"data/raster/imagemosaic/tutorial/#dembathymetry","title":"DEM/Bathymetry","text":"

                                                                      Such a mosaic can be used to serve large amounts of data representing altitude or depth and therefore does not specify colors directly (it needs an SLD to generate pictures). In our case, we have a DEM dataset which consists of a set of raw GeoTIFF files.

                                                                      The first operation is to create the CoverageStore specifying, for example, the path of the shapefile in the URL field.

                                                                      Inside the Coverage Editor Publishing tab, you can specify the dem default style in order to represent the visualization style of the mosaic. The following is an example style:

                                                                      <?xml version=\"1.0\" encoding=\"ISO-8859-1\"?>\n<StyledLayerDescriptor version=\"1.0.0\"\n  xmlns=\"http://www.opengis.net/sld\" xmlns:ogc=\"http://www.opengis.net/ogc\"\n  xmlns:xlink=\"http://www.w3.org/1999/xlink\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\"\n  xsi:schemaLocation=\"http://www.opengis.net/sld  http://schemas.opengis.net/sld/1.0.0/StyledLayerDescriptor.xsd\">\n  <NamedLayer>\n    <Name>gtopo</Name>\n    <UserStyle>\n      <Name>dem</Name>\n      <Title>Simple DEM style</Title>\n      <Abstract>Classic elevation color progression</Abstract>\n      <FeatureTypeStyle>\n        <Rule>\n          <RasterSymbolizer>\n            <Opacity>1.0</Opacity>\n            <ColorMap>\n              <ColorMapEntry color=\"#000000\" quantity=\"-9999\" label=\"nodata\" opacity=\"1.0\" />\n              <ColorMapEntry color=\"#AAFFAA\" quantity=\"0\" label=\"values\" />\n              <ColorMapEntry color=\"#00FF00\" quantity=\"1000\" label=\"values\" />\n              <ColorMapEntry color=\"#FFFF00\" quantity=\"1200\" label=\"values\" />\n              <ColorMapEntry color=\"#FF7F00\" quantity=\"1400\" label=\"values\" />\n              <ColorMapEntry color=\"#BF7F3F\" quantity=\"1600\" label=\"values\" />\n              <ColorMapEntry color=\"#000000\" quantity=\"2000\" label=\"values\" />\n            </ColorMap>\n          </RasterSymbolizer>\n        </Rule>\n      </FeatureTypeStyle>\n    </UserStyle>\n  </NamedLayer>\n</StyledLayerDescriptor>\n

                                                                      In this way you have a clear distinction between the different intervals of the dataset that compose the mosaic, like the background and the \\\"nodata\\\" area.

                                                                      ![](images/vito_config_1.png)\n

                                                                      Note

                                                                      The \\\"nodata\\\" on the sample mosaic is -9999. The default background value is for mosaics is 0.0.

                                                                      The result is the following:

                                                                      ![](images/vito_1.png)\n*Basic configuration*\n

                                                                      By setting the other configuration parameters appropriately, it is possible to improve both the appearance of the mosaic as well as its performance. For instance, we could:

                                                                      • Make the \\\"nodata\\\" areas transparent and coherent with the real data. To achieve this we need to change the opacity of the \\\"nodata\\\" ColorMapEntry in the dem style to 0.0 and set the BackgroundValues parameter to -9999 so that empty areas will be filled with this value. The result is as follows:

                                                                        ![](images/vito_2.png)\n*Advanced configuration*\n
                                                                      • Allow multithreaded granules loading. By setting the AllowMultiThreading parameter to true, GeoServer will load the granules in parallel using multiple threads with a increase in performance on some architectures.

                                                                      The configuration parameters are as follows:

                                                                      Parameter Value MaxAllowedTiles 2147483647 BackgroundValues -9999 OutputTransparentColor \\\"no color\\\" InputTransparentColor \\\"no color\\\" AllowMultiThreading True USE_JAI_IMAGEREAD True SUGGESTED_TILE_SIZE 512,512"},{"location":"data/raster/imagemosaic/tutorial/#aerial-imagery","title":"Aerial imagery","text":"

                                                                      In this example we are going to create a mosaic that will serve aerial imagery, specifically RGB GeoTIFFs. Because this is visual data, in the Coverage Editor you can use the basic raster style, which is just a stub SLD to instruct the GeoServer raster renderer to not do anything particular in terms of color management:

                                                                      <?xml version=\"1.0\" encoding=\"ISO-8859-1\"?>\n<StyledLayerDescriptor version=\"1.0.0\"\n  xmlns=\"http://www.opengis.net/sld\" xmlns:ogc=\"http://www.opengis.net/ogc\"\n  xmlns:xlink=\"http://www.w3.org/1999/xlink\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\"\n  xsi:schemaLocation=\"http://www.opengis.net/sld  http://schemas.opengis.net/sld/1.0.0/StyledLayerDescriptor.xsd\">\n  <NamedLayer>\n    <Name>raster</Name>\n    <UserStyle>\n      <Name>raster</Name>\n      <Title>Raster</Title>\n      <Abstract>A sample style for rasters, good for displaying imagery   </Abstract>\n      <FeatureTypeStyle>\n        <FeatureTypeName>Feature</FeatureTypeName>\n        <Rule>\n          <RasterSymbolizer>\n            <Opacity>1.0</Opacity>\n          </RasterSymbolizer>\n        </Rule>\n      </FeatureTypeStyle>\n    </UserStyle>\n  </NamedLayer>\n</StyledLayerDescriptor>\n

                                                                      The result is the following:

                                                                      ![](images/prato_1.png)\n*Basic configuration*\n

                                                                      Note

                                                                      Those ugly black areas are the result of applying the default mosaic parameters to a mosaic that does not entirely cover its bounding box. The areas within the BBOX that are not covered with data will default to a value of 0 on each band. Since this mosaic is RGB we can simply set the OutputTransparentColor to 0,0,0 in order to get transparent fills for the BBOX.

                                                                      The various parameters can be set as follows:

                                                                      Parameter Value MaxAllowedTiles 2147483647 BackgroundValues (default) OutputTransparentColor #000000 InputTransparentColor \\\"no color\\\" AllowMultiThreading True USE_JAI_IMAGEREAD True SUGGESTED_TILE_SIZE 512,512

                                                                      The result is the following:

                                                                      ![](images/prato_2.png)\n*Advanced configuration*\n
                                                                      "},{"location":"data/raster/imagemosaic/tutorial/#scanned-maps","title":"Scanned maps","text":"

                                                                      In this case we want to show how to serve scanned maps (mostly B&W images) via a GeoServer mosaic.

                                                                      In the Coverage Editor you can use the basic raster since there is no need to use any of the advanced RasterSymbolizer capabilities.

                                                                      The result is the following.

                                                                      ![](images/iacovella_1.png)\n*Basic configuration*\n

                                                                      This mosaic, formed by two single granules, shows a typical case where the \\\"nodata\\\" collar areas of the granules overlap, as shown in the picture above. In this case we can use the InputTransparentColor parameter to make the collar areas disappear during the superimposition process --- in this case, by using an InputTransparentColor of #FFFFFF.

                                                                      The final configuration parameters are the following:

                                                                      Parameter Value MaxAllowedTiles 2147483647 BackgroundValues (default) OutputTransparentColor \\\"no color\\\" InputTransparentColor #FFFFFF AllowMultiThreading True USE_JAI_IMAGEREAD True SUGGESTED_TILE_SIZE 512,512

                                                                      This is the result:

                                                                      ![](images/iacovella_2.png)\n*Advanced configuration*\n
                                                                      "},{"location":"data/raster/imagemosaic/tutorial/#dynamic-imagery","title":"Dynamic imagery","text":"

                                                                      A mosaic need not be static. It can contain granules which change, are added or deleted. In this example, we will create a mosaic that changes over time.

                                                                      1. Create a mosaic in the standard way. (The specific configuration isn\\'t important.)
                                                                      ![](images/tutorial_dynamic1.png)\n*This mosaic contains 5 granules. Note that ``InputTransparentColor`` is set to ``#FFFFFF`` here.*\n

                                                                      To add new granules, the index that was created when the mosaic was originally created needs to be regenerated. There are two ways to do this:

                                                                      • Manually through the file system
                                                                      • Through the REST interface

                                                                      To update an ImageMosaic through the file system:

                                                                      1. Update the contents of the mosaic by copying the new files into place. (Subdirectories are acceptable.)
                                                                      2. Delete the index files. These files are contained in the top level directory containing the mosaic files and include (but are not limited to) the following:
                                                                        • `\\<mosaic_name>.dbf`
                                                                        • `\\<mosaic_name>.fix`
                                                                        • `\\<mosaic_name>.prj`
                                                                        • `\\<mosaic_name>.properties`
                                                                        • `\\<mosaic_name>.shp`
                                                                        • `\\<mosaic_name>.shx`
                                                                      3. (Optional but recommended) Edit the layer definition in GeoServer, making to sure to update the bounding box information (if changed).
                                                                      4. Save the layer. The index will be recreated.
                                                                      ![](images/tutorial_dynamic2.png)\n*This mosaic contains 9 granules*\n

                                                                      Note

                                                                      Please see the REST section for information on Uploading a new image mosaic.

                                                                      "},{"location":"data/raster/imagemosaic/tutorial/#multi-crs-mosaic","title":"Multi-resolution imagery with reprojection","text":"

                                                                      As a general rule, we want to have the highest resolution granules shown \\\"on top\\\", with the lower-resolution granules filling in the gaps as necessary.

                                                                      In this example, we will serve up overlapping granules that have varying resolutions. In addition, we will mix resolutions, such that the higher resolution granule is reprojected to match the resolution of the lower resolution granules.

                                                                      1. In the Coverage Editor, use the basic raster style.

                                                                      2. Create the mosaic in GeoServer.

                                                                      3. One important configuration setting is the SORTING parameter of the layer. In order to see the highest resolution imagery on top (the typical case), it must be set to resolution A. (For the case of lowest resolution on top, use resolution D .)

                                                                      4. Make any other configuration changes.

                                                                      5. Also, in order to allow for multiple CRSs in a single mosaic, an `indexer.properties` file will need to be created. Use the following :

                                                                        GranuleAcceptors=org.geotools.gce.imagemosaic.acceptors.HeterogeneousCRSAcceptorFactory\nGranuleHandler=org.geotools.gce.imagemosaic.granulehandler.ReprojectingGranuleHandlerFactory\nHeterogeneousCRS=true\nMosaicCRS=EPSG\\:4326\nPropertyCollectors=CRSExtractorSPI(crs),ResolutionExtractorSPI(resolution)\nSchema=*the_geom:Polygon,location:String,crs:String,resolution:String\n

                                                                        The MosaicCRS property is not mandatory, but it\\'s a good idea to set a predictable target CRS that all granule footprints can be reprojected into, otherwise the mosaic machinery will use the CRS of the first indexed granule.

                                                                      6. Save this file in the root of the mosaic directory (along with the index files). The result is the following:

                                                                        ![](images/tutorial_reproj_artifact.png)\n*Closeup of granule overlap (high resolution granule on right)*\n
                                                                      7. To remove the reprojection artifact (shown in the above as a black area) edit the layer configuration to set InputTransparentColor to #000000.

                                                                        ![](images/tutorial_reproj_noartifact.png)\n*Closeup of granule overlap (high resolution granule on right)*\n
                                                                      "},{"location":"data/raster/imagemosaic/tutorial/#referring-to-a-datastore-configured-in-geoserver","title":"Referring to a datastore configured in GeoServer","text":"

                                                                      It is possible to make the mosaic refer to an existing data store. The ``datastore.properties`` file in this case will contain only one or two properties, referring to the store to be used via the StoreName property. For simple cases, e.g., a PostGIS store, the following will be sufficient:

                                                                      StoreName=workspace:storename\n

                                                                      For Oracle or H2, it\\'s best to also specify the SPI in order to inform the mosaic that it needs to work around specific limitations of the storage (e.g., forced uppercase attribute usage, limitation in attribute name length and the like):

                                                                      StoreName=workspace:storename\nSPI=org.geotools.data.oracle.OracleNGDataStoreFactory\n

                                                                      The above will be sufficient in case the image mosaic can create the index table and perform normal indexing, using the directory name as the table name. In case a specific table name needs to be used, add an ``indexer.properties`` specifying the TypeName property, e.g.:

                                                                      TypeName=myMosaicTypeName

                                                                      In case the index \\\"table\\\" already exists instead, then a ``indexer.properties`` file will be required, with the following contents:

                                                                      UseExistingSchema=true\nTypeName=nameOfTheFeatureTypeContainingTheIndex\nAbsolutePath=true\n

                                                                      The above assumes location attribute provides absolute paths to the mosaic granules, instead of paths relative to the mosaic configuration files directory.

                                                                      "},{"location":"data/vector/","title":"Vector data","text":"

                                                                      This section discusses the vector data sources that GeoServer can access.

                                                                      The standard GeoServer installation supports the loading and serving of the following data formats:

                                                                      • Shapefile
                                                                      • Directory of spatial files
                                                                      • Java Properties
                                                                      • GeoPackage

                                                                      Other data sources are supplied as GeoServer extensions. Extensions are downloadable modules that add functionality to GeoServer. Extensions are available at the GeoServer download page.

                                                                      Warning

                                                                      The extension version must match the version of the GeoServer instance.

                                                                      • Pregeneralized Features
                                                                      "},{"location":"data/vector/directory/","title":"Directory of spatial files","text":"

                                                                      The directory store automates the process of loading multiple shapefiles into GeoServer. Loading a directory that contains multiple shapefiles will automatically add each shapefile to GeoServer.

                                                                      Note

                                                                      While GeoServer has robust support for the shapefile format, it is not the recommended format of choice in a production environment. Databases such as PostGIS are more suitable in production and offer better performance and scalability. See the section on Running in a production environment for more information.

                                                                      "},{"location":"data/vector/directory/#adding-a-directory","title":"Adding a directory","text":"

                                                                      To begin, navigate to Stores \u2192 Add a new store \u2192 Directory of spatial files.

                                                                      Adding a directory of spatial files as a store

                                                                      Option Description Workspace Name of the workspace to contain the store. This will also be the prefix of all of the layer names created from shapefiles in the store. Data Source Name Name of the store as known to GeoServer. Description Description of the directory store. Enabled Enables the store. If disabled, no data in any of the shapefiles will be served. URL Location of the directory. Can be an absolute path (such as file:C:\\Data\\shapefile_directory) or a path relative to the data directory (such as file:data/shapefile_directory. namespace Namespace to be associated with the store. This field is altered by changing the workspace name. skip scan Skip scan of alternative shapefile extensions (i.e. .SHP, .shp.XML, .CPG, ...) on Not-Windows systems. This can be useful when you have a directory containing several thousands of shapefiles. By Default, the shapefile plugin will look for all the shapefile extensions (.shp, .dbf, .shx, .prj, .qix, .fix, .shp.xml, .cpg). As soon as one of these is missing, it will do a search on the directory for the missing file, ignoring the case. This might be time consuming on directories with a huge number of files.

                                                                      When finished, click Save.

                                                                      "},{"location":"data/vector/directory/#configuring-shapefiles","title":"Configuring shapefiles","text":"

                                                                      All of the shapefiles contained in the directory store will be loaded as part of the directory store, but they will need to be individually configured as new layers they can be served by GeoServer. See the section on Layers for how to add and edit new layers.

                                                                      "},{"location":"data/vector/featurepregen/","title":"Pregeneralized Features","text":"

                                                                      Note

                                                                      GeoServer does not come built-in with support for Pregeneralized Features; it must be installed through an extension.

                                                                      "},{"location":"data/vector/featurepregen/#installing-the-pregeneralized-features-extension","title":"Installing the Pregeneralized Features extension","text":"
                                                                      1. Visit the website download page, locate your release, and download: feature-pregeneralized

                                                                        Warning

                                                                        Ensure to match plugin (example 2.24.2 above) version to the version of the GeoServer instance.

                                                                      2. Extract the contents of the archive into the WEB-INF/lib directory of the GeoServer installation.

                                                                      "},{"location":"data/vector/featurepregen/#adding-a-pregeneralized-features-data-store","title":"Adding a Pregeneralized Features data store","text":"

                                                                      If the extension is properly installed, Generalized Data Store will be listed as an option when creating a new data store.

                                                                      Generalized Data Store in the list of vector data stores

                                                                      "},{"location":"data/vector/featurepregen/#configuring-a-pregeneralized-features-data-store","title":"Configuring a Pregeneralized Features data store","text":"

                                                                      Configuring a Pregeneralized Features data store

                                                                      For a detailed description, look at the Tutorial</tutorials/feature-pregeneralized/feature-pregeneralized_tutorial>

                                                                      "},{"location":"data/vector/geopkg/","title":"GeoPackage","text":"

                                                                      GeoPackage is an SQLite based standard format that is able to hold multiple vector and raster data layers in a single file.

                                                                      GeoPackage files can be used both as Raster Data Stores as well as Vector Data Stores (so that both kinds of layers can published).

                                                                      "},{"location":"data/vector/geopkg/#adding-a-geopackage-vector-data-store","title":"Adding a GeoPackage Vector Data Store","text":"

                                                                      When the extension has been installed, GeoPackage will be an option in the Vector Data Sources list when creating a new data store.

                                                                      GeoPackage in the list of vector data stores

                                                                      Configuring a GeoPackage Vector data store

                                                                      Option Description database URI specifying geopackage file. user User to access database. passwd Password to access database. namespace Namespace to be associated with the database. This field is altered by changing the workspace name. max connections Maximum amount of open connections to the database. min connections Minimum number of pooled connections. fetch size Number of records read with each interaction with the database. Connection timeout Time (in seconds) the connection pool will wait before timing out. validate connections Checks the connection is alive before using it.

                                                                      When finished, click Save.

                                                                      "},{"location":"data/vector/properties/","title":"Java Properties","text":"

                                                                      The Properties data store provides access to one or more feature types (layers) stored in Java property files; these are plain text files stored on the local filesystem. The Properties data store was never intended to be shipped with GeoServer. It originated in a GeoTools tutorial, and later found widespread use by developers in automated tests that required a convenient store for small snippets of data. It slipped into GeoServer through the completeness of the packaging process, and was automatically detected and offered to users via the web interface. The Property data store has proved useful in tutorials and examples.

                                                                      • We do not recommend the use the Properties data store for large amounts of data, with either many features or large geometries. Its performance will be terrible.
                                                                      • For small data sets, such as collections of a few dozen points, you may find it to be satisfactory. For example, if you have a few points you wish to add as an extra layer, and no convenient database in which store them, the Properties data store provides a straightforward means of delivering them.
                                                                      • Changes to a property file are immediately reflected in GeoServer responses. There is no need to recreate the data store unless the first line of a property file is changed, or property files are added or removed.
                                                                      "},{"location":"data/vector/properties/#adding-a-properties-data-store","title":"Adding a Properties data store","text":"

                                                                      By default, Properties will be an option in the Vector Data Sources list when creating a new data store.

                                                                      Properties in the list of vector data stores

                                                                      "},{"location":"data/vector/properties/#configuring-a-properties-data-store","title":"Configuring a Properties data store","text":"

                                                                      Configuring a Properties data store

                                                                      Option Description Workspace Sets the namespace prefix of the feature types (layers) and their properties Data Source Name Unique identifier to distinguish this data store Description Optional text giving a verbose description of the data store Enabled Features will be delivered only if this option is checked directory Filesystem path to a directory containing one or more property files, for example /usr/local/geoserver/data/ex

                                                                      Every property file TYPENAME.properties in the designated directory is served as a feature type TYPENAME (the name of the file without the .properties), in the namespace of the data store.

                                                                      Before a feature type (layer) can be used, you must edit it to ensure that its bounding box and other metadata is configured.

                                                                      "},{"location":"data/vector/properties/#property-file-format","title":"Property file format","text":"

                                                                      The property file format is a subset of the Java properties format: a list of lines of the form KEY=VALUE.

                                                                      This example stations.properties defines four features of the feature type (layer) stations:

                                                                      _=id:Integer,code:String,name:String,location:Geometry:srid=4326\nstations.27=27|ALIC|Alice Springs|POINT(133.8855 -23.6701)\nstations.4=4|NORF|Norfolk Island|POINT(167.9388 -29.0434)\nstations.12=12|COCO|Cocos|POINT(96.8339 -12.1883)\nstations.31=31|ALBY|Albany|POINT(117.8102 -34.9502)\n
                                                                      • Blank lines are not permitted anywhere in the file.
                                                                      • The first line of the property file begins with _= and defines the type information required to interpret the following lines.
                                                                        • Comma separated values are of the form NAME:TYPE
                                                                        • Names are the property name that are used to encode the property in WFS responses.
                                                                        • Types include Integer, String, Float, and Geometry
                                                                        • Geometry can have an extra suffix :srid=XXXX that defines the Spatial Reference System by its numeric EPSG code. Note that geometries defined in this way are in longitude/latitude order.
                                                                      • Subsequent lines define features, one per line.
                                                                        • The key before the = is the feature ID (fid or gml:id in WFS responses). Each must be an NCName.
                                                                        • Feature data follows the = separated by vertical bars (|). The types of the data must match the declaration on the first line.
                                                                        • Leave a field empty if you want it to be null; in this case the property will be ignored.

                                                                      Note that in this example srid=4326 sets the spatial reference system (SRS) to EPSG:4326, which is by convention in longitude/latitude order when referred to in the short form. If you request these features in GML 3 you will see that GeoServer correctly translates the geometry to the URN form SRS urn:x-ogc:def:crs:EPSG:4326 in latitude/longitude form. See the WFS settings page for more on SRS axis order options.

                                                                      "},{"location":"data/vector/shapefile/","title":"Shapefile","text":"

                                                                      A shapefile is a popular geospatial vector data format.

                                                                      Note

                                                                      While GeoServer has robust support for the shapefile format, it is not the recommended format of choice in a production environment. Databases such as PostGIS are more suitable in production and offer better performance and scalability. See the section on Running in a production environment for more information.

                                                                      "},{"location":"data/vector/shapefile/#adding-a-shapefile","title":"Adding a shapefile","text":"

                                                                      A shapefile is actually a collection of files (with the extensions: .shp, .dbf, .shx, .prj, and sometimes others). All of these files need to be present in the same directory in order for GeoServer to accurately read them. As with all formats, adding a shapefile to GeoServer involves adding a new store to the existing Stores through the Web administration interface.

                                                                      Warning

                                                                      The .prj file, while not mandatory, is strongly recommended when working with GeoServer as it contains valuable projection info. GeoServer may not be able to load your shapefile without it!

                                                                      To begin, navigate to Stores \u2192 Add a new store \u2192 Shapefile.

                                                                      Adding a shapefile as a store

                                                                      Option Description Workspace Name of the workspace to contain the store. This will also be the prefix of the layer created from the store. Data Source Name Name of the shapefile as known to GeoServer. Can be different from the filename. The combination of the workspace name and this name will be the full layer name (ex: topp:states). Description Description of the shapefile/store. Enabled Enables the store. If unchecked, no data in the shapefile will be served. URL Location of the shapefile. Can be an absolute path (such as file:C:\\Data\\shapefile.shp) or a path relative to the data directory (such as file:data/shapefile.shp. namespace Namespace to be associated with the shapefile. This field is altered by changing the workspace name. create spatial index Enables the automatic creation of a spatial index. charset Character set used to decode strings from the .dbf file. memory mapped buffer Cache and reuse memory maps Enables the use of memory mapped I/O, improving caching of the file in memory. Turn off on Windows servers.

                                                                      When finished, click Save.

                                                                      "},{"location":"data/vector/shapefile/#configuring-a-shapefile-layer","title":"Configuring a shapefile layer","text":"

                                                                      Shapefiles contain exactly one layer, which needs to be added as a new layer before it will be able to be served by GeoServer. See the section on Layers for how to add and edit a new layer.

                                                                      "},{"location":"data/webadmin/","title":"Data settings","text":"

                                                                      This section describes how to manage load, manage, and publish data in the GeoServer web interface.

                                                                      It describes the core configuration data types that GeoServer uses to access and publish geospatial information. Each subsection describes the data type pages which provide add, view, edit, and delete capabilities.

                                                                      • Layer Preview
                                                                      • Workspaces
                                                                      • Stores
                                                                      • Layers
                                                                      • Layer Groups

                                                                      Note

                                                                      Information on the Styles pages can be found on the Styles page.

                                                                      "},{"location":"data/webadmin/layergroups/","title":"Layer Groups","text":"

                                                                      A layer group is a container in which layers and other layer groups can be organized in a hierarchical structure. A layer group can be referred to by a single name in WMS requests. This allows simpler requests, as one layer can be specified instead of multiple individual layers. A layer group also provides a consistent, fixed ordering of the layers it contains, and can specify alternate (non-default) styles for layers.

                                                                      Layer Groups page

                                                                      "},{"location":"data/webadmin/layergroups/#layer-group-modes","title":"Layer Group modes","text":"

                                                                      Layer group behaviour can be configured by setting its mode. There are 5 available values:

                                                                      • single: the layer group is exposed as a single layer with a name, acting as an alias for a list of layers. The layers are still showing up as top level entries in the WMS capabilities document (unless explicitly referred by a tree group).
                                                                      • opaque container: the layer group is exposed as a single layer with a name, acting as an alias for a list of layers. However, the layers and sub-groups contained in it won't show up in the capabilities document (unless explicitly referred by a tree group) and won't be available by themselves in WMS calls and in the WMS capabilities document, but only as part of the group.
                                                                      • named tree: the layer group can be referred to by one name, but also exposes its nested layers and groups in the capabilities document.
                                                                      • container tree: the layer group is exposed in the capabilities document, but does not have a name, making it impossible to render it on its own. This is called \"containing category\" in the WMS specification.
                                                                      • Earth Observation tree: a special type of group created to manage the WMS Earth Observation requirements. This group does not render its nested layers and groups, but only a \"preview layer\" called Root Layer. When this mode is chosen, a new field \"Root Layer\" will be exposed in the configuration UI.

                                                                      If a layer is included in any non single mode group, it will no longer be listed in the flat layer list. It will still be possible to include the layer in other layer groups.

                                                                      Layer Group Mode Named Contains Children Lists Children Details

                                                                      Single named no

                                                                      Opaque Container named yes no hides children

                                                                      Named Tree named yes lists children

                                                                      Container Tree yes lists children

                                                                      Earth Observation Tree named yes lists children has root layer

                                                                      "},{"location":"data/webadmin/layergroups/#edit-a-layer-group","title":"Edit a Layer Group","text":"

                                                                      To view or edit a layer group, click the layer group name. A layer group configuration page will be displayed. The initial fields allow you to configure the name, title, abstract, workspace, bounds, projection and mode of the layer group. To automatically set the bounding box, select the Generate Bounds button or the Generate Bounds From CRS button to use the bounds defined in the CRS (if available). You may also provide your own custom bounding box extents. To select an appropriate projection click the Find button.

                                                                      Note

                                                                      A layer group can contain layers with dissimilar bounds and projections. GeoServer automatically reprojects all layers to the projection of the layer group.

                                                                      The new Enabled checkbox, if disabled, will cause the layer group to just show up at configuration time (and in REST config), while the new Advertised checkbox, if unchecked, will make it to not be available in GetCapabilities request and in the layer preview. The behaviour of layer group regarding both checkboxes will not affect the behaviour of any of the layers being grouped, which will follow respectively that specified in the corresponding edit page.

                                                                      Layer Groups Edit page

                                                                      The table at the bottom of the page lists layers and groups contained within the current layer group. We refer to layers and layer groups as publishable elements. When a layer group is processed, the layers are rendered in the order provided, so the publishable elements at the bottom of list will be rendered last and will show on top of the other publishable elements.

                                                                      A publishable element can be positioned higher or lower on this list by clicking the green up or down arrows, respectively, or can be simply dragged in the target position. The layer at the top of the list is the first one to be painted, the layer below it will be painted second, and so on, the last layer will be painted on top of all others (this is the so called \"painter's model\").

                                                                      The Style column shows the style associated with each layer. To change the style associated with a layer, click the appropriate style link. A list of enabled styles will be displayed. Clicking on a style name reassigns the layer's style.

                                                                      Style editing for a layer within a layer group

                                                                      To remove a publishable element from the layer group, select its button in the Remove column. You will now be prompted to confirm or cancel this deletion.

                                                                      A layer can be added to the list by clicking the Add Layer... button at the top of the table. From the list of layers, select the layer to be added by clicking the layer name. The selected layer will be appended to the bottom of the publishable list.

                                                                      Dialog for adding a layer to a layer group

                                                                      A layer group can be added by clicking the Add Layer Group... button at the top of the table. From the list of layer groups, select the layer group to be added by clicking its name. The selected group will be appended to the bottom of the publishable list.

                                                                      Dialog for adding a layer group to a layer group

                                                                      A style group can be added by clicking the Add Style Group... button at the top of the table. From the list of styles, select the style group to be added by clicking its name. The selected style will be appended to the bottom of the publishable list.

                                                                      Dialog for adding a style group to a layer group

                                                                      You can view layer groups in the Layer Preview section of the web admin.

                                                                      Openlayers preview of the layer group \"tasmania\"

                                                                      Note

                                                                      By default, a layer group is queryable when at least a child layer is queryable. Uncheck \"Queryable\" box if you want to explicitly indicate that it is not queryable independently of how the child layers are configured.

                                                                      Security tab allows to set data access rules at layer group level.

                                                                      Note

                                                                      For more information on data access rules, please see the section on Data.

                                                                      To create/edit layergroup's data access rules simply check/uncheck checkboxes according to desired access mode and role. The Grant access to any role checkbox grant each role for each access mode.

                                                                      "},{"location":"data/webadmin/layergroups/#layer-group-styles","title":"Layer Group Styles","text":"

                                                                      The user can also define styles for a Layer Group. By style in this context we mean a different group definition that, while carrying the same meaning, uses a different set of styles, or even a different set of layers (e.g., night versus day style, or full versus simplified). The styles are named and can be thus be referenced through the styles parameter in the various WMS operations (GetMap, GetLegendGraphic, GetFeatureInfo), while the usual Layer Group configuration is kept as the default style.

                                                                      To add a new style on the Data tab scroll down until reaching the Layer Group Styles section and click on Add new.

                                                                      A form will pop up. Once defined a name (mandatory), it is possible to select the a list of layers and corresponding styles for the group style definition.

                                                                      In the above example the style uses the same list of layers, but different styles have been defined for the tiger:giant_polygon and tiger:poly_landmarks layers, respectively giant-polygon-2 and poly_landmarks-2. However the Layer Group Style might also contain a different list of layers comparing to the default one.

                                                                      Once a style has been defined it will appear in the GetCapabilities document and clients will be able to reference it in the styles parameter of GetMap, GetLegendGraphic and GetFeatureInfo operations, using the name defined at configuration time.

                                                                      The base configuration will be treated as the default Style of the Layer Group and used when either no style name is provided or the style name matches the default Layer Group Style name.

                                                                      Note

                                                                      The overall functionality is available only for Layer Group with mode SINGLE or OPAQUE. If a Layer Group is defined with another mode, the style name eventually present in a WMS operation will be ignored if not matching the default style name. Moreover the Layer Group Style section will not be available and the Style will not be advertised in the GetCapabilities response. This is due to the group internal structure appearing in the capabilities layer tree: only one list of sub-layers and sub-groups can be advertised.

                                                                      "},{"location":"data/webadmin/layergroups/#add-a-layer-group","title":"Add a Layer Group","text":"

                                                                      The buttons for adding and removing a layer group can be found at the top of the Layer Groups page.

                                                                      Buttons to add or remove a layer group

                                                                      To add a new layer group, select the \"Add a new layer group\" button. You will be prompted to name the layer group.

                                                                      New layer group dialog

                                                                      When finished, click Submit. You will be redirected to an empty layer group configuration page. Begin by adding layers by clicking the Add layer... button (described in the previous section). Once the layers are positioned accordingly, press Generate Bounds to automatically generate the bounding box and projection. You may also press the Generate Bounds From CRS button to use the CRS bounds (if available). Press Save to save the new layer group.

                                                                      New layer group configuration page

                                                                      "},{"location":"data/webadmin/layergroups/#remove-a-layer-group","title":"Remove a Layer Group","text":"

                                                                      To remove a layer group, select it by clicking the checkbox next to the layer group. Multiple layer groups can be selected, or all can be selected by clicking the checkbox in the header. Click the Remove selected layer group(s) link. You will be asked to confirm or cancel the deletion. Selecting OK removes the selected layer group(s).

                                                                      Removing a layer group

                                                                      "},{"location":"data/webadmin/layergroups/#layer-group-keywords","title":"Layer Group Keywords","text":"

                                                                      Is possible to associate a layer group with some keywords that will be used to assist catalog searching.

                                                                      Layer groups keywords editor

                                                                      Layer groups keywords will no be merged with contained layers keywords but keywords of a layer group should be logically inherited by contained layers.

                                                                      "},{"location":"data/webadmin/layergroups/#root-layer-in-capabilities","title":"Root Layer in Capabilities","text":"

                                                                      Capabilities documents in GeoServer always have a top level (root) Layer element that works as a container of all the available layers and groups.

                                                                      When a layer group is the only top level element in the Capabilities document, it is possible to remove this root Layer and return a hierarchy where the layer group is the root instead.

                                                                      To enable this functionality, choose the No option from the Root Layer in Capabilities section.

                                                                      By default this behaviour is inherited from the global WMS service settings (WMS Global Settings option). Finally, it is possible to override the service settings and force a Yes to always include the GeoServer root element.

                                                                      Layer groups root layer in capabilities options

                                                                      "},{"location":"data/webadmin/layergroups/#http-settings","title":"HTTP Settings","text":"

                                                                      Cache parameters that apply to the HTTP response from client requests.

                                                                      • Response Cache Headers--- If selected, conforming HTTP clients will not request the same tile twice within the time specified in Cache Time. One hour measured in seconds (3600), is the default value for Cache Time. Layer group Response Cache Headers configuration replace Response Cache Headers configured in layers defined in layer group.

                                                                      "},{"location":"data/webadmin/layerpreview/","title":"Layer Preview","text":"

                                                                      This page provides layer views in various output formats. A layer must be enabled to be previewed.

                                                                      Layer Preview Page

                                                                      Each layer row consists of a type, name, title, and available formats for viewing.

                                                                      Icon Description Raster (grid) Polygon Line Point Other Geometry Layer Group Cascading WMS Unknown/Other

                                                                      Name refers to the Workspace and Layer Name of a layer, while Title refers to the brief description configured in the Edit Layer: Data panel. In the following example, nurc refers to the Workspace, Arc_Sample refers to the Layer Name and \"A sample ArcGrid field\" is specified on the Edit Later Data panel.

                                                                      Single Layer preview row

                                                                      "},{"location":"data/webadmin/layerpreview/#output-formats","title":"Output Formats","text":"

                                                                      The Layer Preview page supports a variety of output formats for further use or data sharing. You can preview all three layer types in the common OpenLayers and KML formats. Similarly, using the \"All formats\" menu you can preview all layer types in seven additional output formats---AtomPub, GIF, GeoRss, JPEG, KML (compressed), PDF, PNG, SVG, and TIFF. Only Vector layers provide the WFS output previews, including the common GML as well as the CSV, GML3, GeoJSON and shapefile formats. The table below provides a brief description of all supported output formats, organized by output type (image, text, or data).

                                                                      "},{"location":"data/webadmin/layerpreview/#image-outputs","title":"Image Outputs","text":"

                                                                      All image outputs can be initiated from a WMS getMap request on either a raster, vector or coverage data. WMS are methods that allows visual display of spatial data without necessarily providing access to the features that comprise those data.

                                                                      Format Description KML KML (Keyhole Markup Language) is an XML-based language schema for expressing geographic data in an Earth browser, such as Google Earth or Google Maps. KML uses a tag-based structure with nested elements and attributes. For GeoServer, KML files are distributed as a KMZ, which is a zipped KML file. JPEG WMS output in raster format. The JPEG is a compressed graphic file format, with some loss of quality due to compression. It is best used for photos and not recommended for exact reproduction of data. GIF WMS output in raster format. The GIF (Graphics Interchange Format) is a bitmap image format best suited for sharp-edged line art with a limited number of colors. This takes advantage of the format's lossless compression, which favors flat areas of uniform color with well defined edges (in contrast to JPEG, which favors smooth gradients and softer images). GIF is limited to an 8-bit palette, or 256 colors. SVG WMS output in vector format. SVG (Scalable Vector Graphics) is a language for modeling two-dimensional graphics in XML. It differs from the GIF and JPEG in that it uses graphic objects rather than individual points. TIFF WMS output in raster format. TIFF (Tagged Image File Format) is a flexible, adaptable format for handling multiple data in a single file. GeoTIFF contains geographic data embedded as tags within the TIFF file. PNG WMS output in raster format. The PNG (Portable Network Graphics) file format was created as the free, open-source successor to the GIF. The PNG file format supports truecolor (16 million colors) while the GIF supports only 256 colors. The PNG file excels when the image has large, uniformly coloured areas. OpenLayers WMS GetMap request outputs a simple OpenLayers preview window. OpenLayers is an open source JavaScript library for displaying map data in web browsers. The OpenLayers output has some advanced filters that are not available when using a standalone version of OpenLayers. Further, the generated preview contains a header with easy configuration options for display. Version 3 of the OpenLayers library is used by default. Version 3 can be disabled with the ENABLE_OL3 (true/false) format option or system property. For older browsers not supported by OpenLayers 3, version 2 is used regardless of the setting. PDF A PDF (Portable Document Format) encapsulates a complete description of a fixed-layout 2D document,including any text, fonts, raster images, and 2D vector graphics.

                                                                      Sample Image Output-an OpenLayers preview of nurc:Pk50095

                                                                      "},{"location":"data/webadmin/layerpreview/#text-outputs","title":"Text Outputs","text":"Format Description AtomPub WMS output of spatial data in XML format. The AtomPub (Atom Publishing Protocol) is an application-level protocol for publishing and editing Web Resources using HTTP and XML. Developed as a replacement for the RSS family of standards for content syndication, Atom allows subscription of geo data. GeoRss WMS GetMap request output of vector data in XML format. RSS (Rich Site Summary) is an XML format for delivering regularly changing web content. GeoRss is a standard for encoding location as part of a RSS feed.supports Layers Preview produces a RSS 2.0 documents, with GeoRSS Simple geometries using Atom. GeoJSON JavaScript Object Notation (JSON) is a lightweight data-interchange format based on the JavaScript programming language. This makes it an ideal interchange format for browser based applications since it can be parsed directly and easily in to javascript. GeoJSON is a plain text output format that add geographic types to JSON (and is now a w3c standard). CSV WFS GetFeature output in comma-delimited text. CSV (Comma Separated Values) files are text files containing rows of data. Data values in each row are separated by commas. CSV files also contain a comma-separated header row explaining each row's value ordering. GeoServer's CSVs are fully streaming, with no limitation on the amount of data that can be outputted.

                                                                      A fragment of a simple GeoRSS for nurc:Pk50095 using Atom:

                                                                      <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n <rss xmlns:atom=\"http://www.w3.org/2005/Atom\"\n      xmlns:georss=\"http://www.georss.org/georss\" version=\"2.0\">\n    <channel>\n      <title>Pk50095</title>\n      <description>Feed auto-generated by GeoServer</description>\n      <link>></link>     \n      <item>\n        <title>fid--f04ca6b_1226f8d829e_-7ff4</title>\n        <georss:polygon>46.722110379286 13.00635746384126 \n         46.72697223230676 13.308182612644663 46.91359611878293\n         13.302316867622581 46.90870264238999 12.999446822650462 \n         46.722110379286 13.00635746384126\n        </georss:polygon>\n        </item>\n    </channel>\n</rss>\n
                                                                      "},{"location":"data/webadmin/layerpreview/#data-outputs","title":"Data Outputs","text":"

                                                                      All data outputs are initiated from a WFS GetFeature request on vector data.

                                                                      Format Description GML2 GML3 GML (Geography Markup Language) is the XML grammar defined by the Open Geospatial Consortium (OGC) to express geographical features. GML serves as a modeling language for geographic systems as well as an open interchange format for geographic data sharing. GML2 is the default (Common) output format, while GML3 is available from the \"All Formats\" menu. Shapefile The ESRI Shapefile, or simply a shapefile, is the most commonly used format for exchanging GIS data. GeoServer outputs shapefiles in zip format, with a directory of .cst, .dbf, .prg, .shp, and .shx files."},{"location":"data/webadmin/layers/","title":"Layers","text":"

                                                                      In GeoServer, the term \"layer\" refers to a raster or vector dataset that represents a collection of geographic features. Vector layers are analogous to \"featureTypes\" and raster layers are analogous to \"coverages\". All layers have a source of data, known as a Store. The layer is associated with the Workspace in which the Store is defined.

                                                                      In the Layers section of the web interface, you can view and edit existing layers, add (register) a new layer, or remove (unregister) a layer. The Layers View page displays the list of layers, and the Store and Workspace in which each layer is contained. The View page also displays the layer's status and native SRS.

                                                                      Layers View

                                                                      "},{"location":"data/webadmin/layers/#layer-types","title":"Layer types","text":"

                                                                      Layers can be divided into two types of data: raster and vector. These two formats differ in how they store spatial information. Vector types store information about feature types as mathematical paths---a point as a single x,y coordinate, lines as a series of x,y coordinates, and polygons as a series of x,y coordinates that start and end on the same place. Raster format data is a cell-based representation of features on the earth surface. Each cell has a distinct value, and all cells with the same value represent a specific feature.

                                                                      Field Description Raster (grid) Polygon Line Point"},{"location":"data/webadmin/layers/#data_webadmin_layers_add_a_layer","title":"Add a Layer","text":"

                                                                      At the upper left-hand corner of the layers view page there are two buttons for the adding and removal of layers. The green plus button allows you to add a new layer. The red minus button allows you to remove selected layers.

                                                                      Buttons to Add and Remove a Layer

                                                                      Clicking the Add a new layer button brings up a New Layer Chooser panel. The menu displays all currently enabled stores. From this menu, select the Store where the layer should be added.

                                                                      List of all currently enabled stores

                                                                      Upon selection of a Store, a list is displayed of resources within the store. Resources which have already been published as layers are listed first, followed by other resources which are available to be published. In this example, giant_polygon, poi, poly_landmarks and tiger_roads are all existing layers within the NYC store.

                                                                      List of published and available resources in a store

                                                                      To add a layer for an available resource click Publish. To add a new layer for a published resource click Publish Again. (Note that when re-publishing the name of the new layer may have to be modified to avoid conflict with an existing layer.) The actions display an Edit Layer page to enter the definition of the new layer.

                                                                      "},{"location":"data/webadmin/layers/#remove-a-layer","title":"Remove a Layer","text":"

                                                                      To remove a layer, select it by clicking the checkbox next to the layer. As shown below, multiple layers can be selected for batch removal. Note that selections for removal will not persist from one results pages to the next.

                                                                      Some layers selected for removal

                                                                      All layers can be selected for removal by clicking the checkbox in the header.

                                                                      All layers selected for removal

                                                                      Once layer(s) are selected, the Remove selected resources link is activated. Once you've clicked the link, you will be asked to confirm or cancel the removal. Selecting OK removes the selected layer(s).

                                                                      "},{"location":"data/webadmin/layers/#data_webadmin_layers_edit_data","title":"Edit Layer: Data","text":"

                                                                      To view or edit a layer, click the layer name. A layer configuration page will be displayed. The Data tab, activated by default, allows you to define and change data parameters for a layer.

                                                                      Edit Layer: Data tab

                                                                      "},{"location":"data/webadmin/layers/#basic-info","title":"Basic Info","text":"

                                                                      The beginning sections---Basic Resource Info, Keywords and Metadata link---are analogous to the Service Metadata section for WCS, WFS, and WMS. These sections provide \"data about the data,\" specifically textual information that make the layer data easier to understand and work with. The metadata information will appear in the capabilities documents which refer to the layer.

                                                                      • Name---Identifier used to reference the layer in WMS requests. (Note that for a new layer for an already-published resource, the name must be changed to avoid conflict.)

                                                                      • Enabled---A layer that is not enabled won't be available to any kind of request, it will just show up in the configuration (and in REST config)

                                                                      • Advertised---A layer is advertised by default. A non-advertised layer will be available in all data access requests (for example, WMS GetMap, WMS GetFeature) but won't appear in any capabilities document or in the layer preview.

                                                                      • Title---Human-readable description to briefly identify the layer to clients (required)

                                                                      • Abstract---Describes the layer in detail

                                                                      • Keywords---List of short words associated with the layer to assist catalog searching

                                                                      • Metadata Links---Allows linking to external documents that describe the data layer. The \"type\" input provides a few example types, like FGDC or ISO19115:2003, but allows any other type to be declared. The optional \"About\" entry can be used to point to the definition of the metadata standard, or any other side information about it. Finally, \"URL\" points to the actual metadata, while \"Format\" provides its mime type.

                                                                        Adding a metadata link in FGDC format

                                                                      "},{"location":"data/webadmin/layers/#coordinate-reference-systems","title":"Coordinate Reference Systems","text":"

                                                                      A coordinate reference system (CRS) defines how georeferenced spatial data relates to real locations on the Earth's surface. CRSes are part of a more general model called Spatial Reference Systems (SRS), which includes referencing by coordinates and geographic identifiers. GeoServer needs to know the Coordinate Reference System of your data. This information is used for computing the latitude/longitude bounding box and reprojecting the data during both WMS and WFS requests.

                                                                      Coordinate reference system of a layer

                                                                      • Native SRS---Specifies the coordinate system the layer is stored in. Clicking the projection link displays a description of the SRS.
                                                                      • Declared SRS---Specifies the coordinate system GeoServer publishes to clients
                                                                      • SRS Handling---Determines how GeoServer should handle projection when the two SRSes differ. Possible values are:
                                                                        • Force declared (default): the declared SRS is forced upon the data, overwriting the native one. This is the default option and normally the best course of action, the declared code comes from the EPSG database and has a wealth of extra information in it, starting from a valid EPSG code, an area of validity, a link back in the database to find the best transformation steps to other coordinate reference systems should reprojection be required. Use this option when the source has no native CRS, has a wrong one, or has one matching the EPSG code (in order to get full metadata in the CRS used by GeoServer).
                                                                        • Reproject from native: This setting should be used when the native data set has a CRS that is not matching any official EPSG. OGC protocols need to advertise a EPSG code for the layers, with this setting the declared one will be advertised, and reprojection from native will happen on the fly as needed (in case a third CRS is requested, the reprojection will go directly from native to declared)
                                                                        • Keep native: this is a setting that should be used in very rare cases. Keeping native means using the declared one in the capabilities documents, but then using the native CRS in all otherrequests (with no reprojection in between, unless explicitly requested from client). This is particularly problematic if the source is a shapefile, as the PRJ files lack all the extra information provided by the EPSG database (it will for example break WFS 1.1 and 2.0 SRS declarations in GML output). The setting meant to be used in cases where WMS is the primary target, and the native and declared CRSs have very small differences, avoiding on the fly reprojection and datum change.

                                                                      In summary, use Force Declared as your primary option, Reproject from native only if your source data does not match any EPSG code, and Keep Native only if you really know what you're doing.

                                                                      For WMS Server and WFS-NG layers with multiple supported CRS in capability document, the Native CRS can be selected from clicking Find button next to Native SRS field

                                                                      "},{"location":"data/webadmin/layers/#bounding-boxes","title":"Bounding Boxes","text":"

                                                                      The bounding box determines the extent of the data within a layer.

                                                                      • Native Bounding Box---The bounds of the data specified in the Native SRS. These bounds can be generated by clicking the Compute from data button or they can be generated from the SRS definition by clicking the Compute from SRS bounds button. The SRS used depends on the SRS Handling chosen: the declared SRS when Force declared or Reproject native to declared are chosen, otherwise the native SRS is used. If the SRS does not have a bounding defined then none is generated.
                                                                      • Lat/Lon Bounding Box---The bounds specified in geographic coordinates. These bounds can be calculated by clicking the Compute from native bounds button.

                                                                      Bounding Boxes of a layer

                                                                      "},{"location":"data/webadmin/layers/#coverage-parameters-raster","title":"Coverage Parameters (Raster)","text":"

                                                                      Optional coverage parameters are possible for certain types of raster data. For example, WorldImage formats request a valid range of grid coordinates in two dimensions known as a ReadGridGeometry2D. For ImageMosaic, you can use InputImageThresholdValue, InputTransparentColor, and OutputTransparentColor to control the rendering of the mosaic in terms of thresholding and transparency.

                                                                      "},{"location":"data/webadmin/layers/#curves-support-vector","title":"Curves support (Vector)","text":"

                                                                      GeoServer can handle geometries containing circular arcs (initially only from Oracle Spatial and the \"properties data store\", though more data sources are planned).

                                                                      These geometries are kept in memory in their circular representation for as long as possible, are properly visually depicted in WMS, and encoded in GML 3.x as curved.

                                                                      There are two options pertaining the circular arcs:

                                                                      • Linear geometries can contain circular arcs should be checked to inform the GML encoder that the layer can contain circular arcs among other linear segments in the geometries, and thus use \"gml:Curve\" in place of \"gml:LineString\" in GML 3.1 output format. This is required because there is no quick way to know from the data sources if the linear geometries do contain circular arcs, and the choice of top level GML elements influences whether it is possible, or not, to represent circular arcs in their natural form.
                                                                      • Linearization tolerance controls how accurately the linearized version of geometries matches the original circular version of them. The tolerance can be expressed as an absolute number in the native unit of measure of the data, or it can be expressed in meters or feet using the \"m\" and \"ft\" suffixes (such as \"10m\" or \"15ft\").

                                                                      Curved geometry control

                                                                      "},{"location":"data/webadmin/layers/#data_webadmin_layers_edit_publishing","title":"Feature Type Details (Vector)","text":"

                                                                      Vector layers have a list of the Feature Type Details. These include the Property and Type of a data source. For example, the sf:archsites layer shown below includes a geometry (the_geom) of type \"point\".

                                                                      Feature Type Details

                                                                      The Nillable option refers to whether the property requires a value or may be flagged as being null. Meanwhile Min/Max Occurrences refers to how many values a field is allowed to have. Currently both Nillable and Min/Max Occurrences are set to true and 0/1 but may be extended with future work on complex features.

                                                                      The Customize attributes checkbox opens an attribute editor allowing customization.

                                                                      Attribute customization

                                                                      It is possible to:

                                                                      • Change the order of attributes, using either the up/down arrows, or dragging the attribute row.
                                                                      • Remove an attribute using the \"remove\" icon at the end of the attribute row.
                                                                      • Add a new attribute, which will be computed based on the Source CQL expression.
                                                                      • Rename an attribute.
                                                                      • Add a description of the attribute, which will be visible wherever the feature type is described.
                                                                      • Change the nillability of the attribute, for example, making the attribute mandatory even if it's not in the data source, and vice-versa.
                                                                      • Change the type of the attribute using the Type column. The most common types are available in a drop-down on editing, but it's possible to indicate any valid Java class, as long as GeoServer has a converter that goes from the value produced by the Source expression to the target type (new converters can be plugged in with some Java programming).
                                                                      • Reset the table to the native settings, using the Reset customization link.

                                                                      Some of the feature type edits might result in the layer not being editable anymore, for example, by removing an attribute that is marked as mandatory in the data source.

                                                                      "},{"location":"data/webadmin/layers/#restricting-features-showing-up-in-the-layer","title":"Restricting features showing up in the layer","text":"

                                                                      By default GeoServer will publish all the features available in the layer. It is possible to restrict the features to a subset by specifying a CQL filter in the configuration:

                                                                      Restrict the features on layer by CQL filter

                                                                      Note

                                                                      It is recommended to use this setting for layers that are not meant to be edited. The filter is only applied to reads, if a WFS-T insert adds a feature not matching the filter, it will be added to the store anyways, but won't show up in any of the outputs.

                                                                      "},{"location":"data/webadmin/layers/#edit-layer-publishing","title":"Edit Layer: Publishing","text":"

                                                                      The Publishing tab configures HTTP and WMS/WFS/WCS settings.

                                                                      Edit Layer: Publishing tab

                                                                      "},{"location":"data/webadmin/layers/#http-settings","title":"HTTP Settings","text":"

                                                                      Cache parameters that apply to the HTTP response from client requests.

                                                                      • Response Cache Headers--- If selected, GeoServer will not request the same tile twice within the time specified in Cache Time. One hour measured in seconds (3600), is the default value for Cache Time.

                                                                      "},{"location":"data/webadmin/layers/#root-layer-in-capabilities","title":"Root Layer in Capabilities","text":"

                                                                      Capabilities documents in GeoServer always have a top level (root) Layer element that works as a container of all the available layers and groups.

                                                                      When a layer is the only top level element in the Capabilities document, it is possible to remove this root Layer and return a hierarchy where the layer is the root instead.

                                                                      To enable this functionality, choose the No option from the Root Layer in Capabilities section.

                                                                      By default this behaviour is inherited from the global WMS service settings (WMS Global Settings option). Finally, it is possible to override the service settings and force a Yes to always include the GeoServer root element.

                                                                      Layer root layer in capabilities options

                                                                      "},{"location":"data/webadmin/layers/#services-settings","title":"Services Settings","text":"

                                                                      Sets services configuration on layer level.

                                                                      Services Settings

                                                                      • Selectively enable services for layer---Activate/deactivate service enable/disable configuration for the layer.

                                                                      • Enabled Services---Selects enabled services list for this layer.

                                                                      • Disabled Services---Selects disabled services list for this layer.

                                                                        Note

                                                                        It is also possible to set by-default disabled services to all layers using the org.geoserver.service.disabled system/env/servlet context variable. This variable accepts a comma separated list of services that should be disabled by default, in case the resource in question has no explicit configuration.

                                                                      "},{"location":"data/webadmin/layers/#wms-settings","title":"WMS Settings","text":"

                                                                      Sets the WMS specific publishing parameters.

                                                                      WMS Settings

                                                                      • Queryable---Controls whether the layer is queryable via WMS GetFeatureInfo requests.
                                                                      • Default style---Style that will be used when the client does not specify a named style in GetMap requests.
                                                                      • Additional styles---Other styles that can be associated with this layer. Some clients (and the GeoServer Layer Preview) will present those as styling alternatives for that layer to the user.
                                                                      • Default rendering buffer---Default value of the buffer GetMap/GetFeatureInfo vendor parameter. See the WMS vendor parameters for more details.
                                                                      • Default WMS path---Location of the layer in the WMS capabilities layer tree. Useful for building non-opaque layer groups
                                                                      • Default Interpolation Method---Allows to specify a default resampling (interpolation) method for this layer. The available options are Nearest neighbor, Bilinear, Bicubic, or Use service default, which means that no layer specific configuration will be created (the default interpolation method selected in the WMS service configuration page will be used, see Raster Rendering Options for details). Can be overridden by the interpolations vendor parameter.
                                                                      "},{"location":"data/webadmin/layers/#wms-attribution","title":"WMS Attribution","text":"

                                                                      Sets publishing information about data providers.

                                                                      WMS Attribution

                                                                      • Attribution Text---Human-readable text describing the data provider. This might be used as the text for a hyperlink to the data provider's website.
                                                                      • Attribution Link---URL to the data provider's website.
                                                                      • Logo URL---URL to an image that serves as a logo for the data provider.
                                                                      • Logo Content Type, Width, and Height---These fields provide information about the logo image that clients may use to assist with layout. GeoServer will auto-detect these values if you click the Auto-detect image size and type link at the bottom of the section. The text, link, and URL are each advertised in the WMS Capabilities document if they are provided. Some WMS clients will display this information to advise users which providers provide a particular dataset. If you omit some of the fields, those that are provided will be published and those that are not will be omitted from the Capabilities document.
                                                                      "},{"location":"data/webadmin/layers/#wfs-settings","title":"WFS Settings","text":"

                                                                      Sets the WFS specific publishing parameters.

                                                                      WFS Settings

                                                                      • Per-Request Feature Limit---Sets the maximum number of features for a layer a WFS GetFeature operation should generate (regardless of the actual number of query hits)

                                                                      • Maximum number of decimals---Sets the maximum number of decimals in GML output.

                                                                      • Activate complex to simple features conversion - If the target output format does not handle complex features natively, this option enables the conversion of complex features to simple features, using only SF-0 (simple) attributes. This means that nested features and multiple-value attributes will be omitted from the final result, instead of throwing errors while generating the output. Output formats capable of handling complex features are not affected.

                                                                        Note

                                                                        It is also possible to override the OtherSRS/OtherCRS list configured in the WFS service, including overriding it with an empty list if need be. The input area will accept a comma separated list of EPSG codes:

                                                                        WFS otherSRS/otherCRS override

                                                                        The list will be used only for the capabilities document generation, but will not be used to limit the actual target SRS usage in GetFeature requests.

                                                                      • Encode coordinates measures---Checking this setting will cause coordinates measures (\"M\") to be encoded in WFS output formats that support measures. The default (not checked) is to not encode coordinates measures.

                                                                      "},{"location":"data/webadmin/layers/#wcs-settings","title":"WCS Settings","text":"
                                                                      • Request SRS---Provides a list of SRSs the layer can be converted to. New Request SRS allows you to add an SRS to that list.
                                                                      • Interpolation Methods---Sets the raster rendering process, if applicable.
                                                                      • Formats---Lists which output formats a layers supports.
                                                                      • GeoSearch---When enabled, allows the Google Geosearch crawler to index from this particular layer. See What is a Geo Sitemap? for more information.
                                                                      "},{"location":"data/webadmin/layers/#kml-format-settings","title":"KML Format Settings","text":"

                                                                      Limits features based on certain criteria, otherwise known as regionation.

                                                                      • Default Regionating Attribute---Choose which feature should show up more prominently than others.
                                                                      • Regionating Methods---There are four types of regionating methods:
                                                                        • external-sorting---Creates a temporary auxiliary database within GeoServer. The first request to build an index takes longer than subsequent requests.
                                                                        • geometry---Externally sorts by length (if lines) or area (if polygons)
                                                                        • native-sorting---Uses the default sorting algorithm of the backend where the data is hosted. It is faster than external-sorting, but will only work with PostGIS datastores.
                                                                        • random---Uses the existing order of the data and does not sort
                                                                      "},{"location":"data/webadmin/layers/#data_webadmin_layers_edit_dimensions","title":"Edit Layer: Dimensions","text":"

                                                                      GeoServer supports adding specific dimensions to WMS layers, as specified in WMS 1.1.1 and WMS 1.3.0 standards. There are two pre-defined dimensions in the WMS standards mentioned above, TIME and ELEVATION. Enabling dimensions for a layer allows users to specify those as extra parameters in GetMap requests, filtering the dataset to that particular set of times or elevations.

                                                                      These dimensions can be enabled and configured on the Dimensions tab.

                                                                      TIME dimension enabled for a WMS layer

                                                                      For each enabled dimension the following configuration options are available:

                                                                      • Attribute---Attribute name for picking the value for this dimension (vector only). This is treated at start of the range if End attribute is also given.
                                                                      • End attribute---Attribute name for picking the end of the value range for this dimension (optional, vector only).
                                                                      • Presentation---The presentation type for the available values in the capabilities document. Either each value separately (list), interval and resolution, or continuous interval.
                                                                      • Default value---Default value to use for this dimension if none is provided with the request. Select one of from four strategies:
                                                                        • smallest domain value---Uses the smallest available value from the data
                                                                        • biggest domain value---Uses the biggest available value from the data
                                                                        • nearest to the reference value---Selects the data value closest to the given reference value
                                                                        • reference value---Tries to use the given reference value as-is, regardless of whether its actually available in the data or not.
                                                                      • Reference value---The default value specifier. Only shown for the default value strategies where its used.
                                                                      • Nearest match---Whether to enable, or not, WMS nearest match support on this dimension. Currently supported only on the time dimension.
                                                                      • Nearest match on raw data---Whether to enable, or not, nearest match support on this dimension for raw data requests (WCS for coverage layers, WFS for feature layers). Currently supported only on the time dimension for WCS service.
                                                                      • Acceptable interval---A maximum search distance from the specified value (available only when nearest match is enabled). Can be empty (no limit), a single value (symmetric search) or using a before/after syntax to specify an asymmetric search range. Time distances should specified using the ISO period syntax. For example, PT1H/PT0H allows to search up to one hour before the user specified value, but not after.
                                                                      • On nearest match fail---What to do if the nearest match fails the acceptable interval. The default behavior is to use the original value and thus return an empty result, but can also be configured to throw an InvalidDimensionValue exception instead. In case the value is not set, it defaults to ignoring the nearest match and using the original value. To switch to the opposite default, set the following variable (system, environment, or web.xml, as usual): org.geoserver.wms.nearestFail=EXCEPTION.
                                                                      • Begin of data range---A manually declared start value for the data range. When specified, the End of data range has to be specified also. Has to be either numeric, an ISO 8601 DateTime format or the string PRESENT. If left blank GeoServer will determine the value automatically based on the data. When using 'PRESENT' the current DateTime of the server will be used when the capabilities document is generated. Setting this value manually may be desired when working with layers consisting of huge amounts of data where the automatic determination can get slow. This parameter is only handled for WMS Layers in their capabilities document.
                                                                      • End of data range---A manually declared end value for the data range. When specified, the Begin of data range has to be specified also. Has to be either numeric, an ISO 8601 DateTime format or the string PRESENT. If left blank GeoServer will determine the value automatically based on the data. When using 'PRESENT' the current DateTime of the server will be used when the capabilities document is generated. Setting this value manually may be desired when working with layers consisting of huge amounts of data where the automatic determination can get slow. This parameter is only handled for WMS Layers in their capabilities document.

                                                                      For time dimension the value must be in ISO 8601 DateTime format yyyy-MM-ddThh:mm:ss.SSSZ For elevation dimension, the value must be and integer of floating point number.

                                                                      Only for the \"Reference value\" strategy, it is also possible to use ranges or times and ranges of elevation, in the form fromValue/toValue. Only for the \"Reference value\" strategy, and limited to times, it's also possible to use relative times like P1M/PRESENT, but caution is given that the reference value is copied verbatim into the capabilities document, and as a result, not all client might be recognizing that syntax.

                                                                      Note

                                                                      For more information on specifying times, please see the section on Time Support in GeoServer WMS.

                                                                      "},{"location":"data/webadmin/layers/#vector-custom-dimensions","title":"Vector Custom Dimensions","text":"

                                                                      GeoServer also supports adding custom dimensions to vector layers, defining their names and configurations.

                                                                      Custom dimension enabled for a vector layer

                                                                      For each enabled dimension the following configuration options are available:

                                                                      • Name---Custom dimension name.
                                                                      • Attribute---Attribute name for picking the value for this dimension (vector only). This is treated at start of the range if End attribute is also given.
                                                                      • End attribute---Attribute name for picking the end of the value range for this dimension (optional, vector only).
                                                                      • Presentation---The presentation type for the available values in the capabilities document. Either each value separately (list), interval and resolution, or continuous interval.
                                                                      • Default value---Default value to use for this dimension if none is provided with the request. Select one of from four strategies:
                                                                        • smallest domain value---Uses the smallest available value from the data
                                                                        • biggest domain value---Uses the biggest available value from the data
                                                                        • nearest to the reference value---Selects the data value closest to the given reference value
                                                                        • reference value---Tries to use the given reference value as-is, regardless of whether its actually available in the data or not.
                                                                      • Reference value---The default value specifier. Only shown for the default value strategies where its used.
                                                                      • Nearest match---Whether to enable, or not, WMS nearest match support on this dimension.
                                                                      • Acceptable interval---A maximum search distance from the specified value (available only when nearest match is enabled). Can be empty (no limit), a single value (symmetric search) or using a before/after syntax to specify an asymmetric search range.
                                                                      • Begin of data range---A manually declared start value for the data range. When specified, the End of data range has to be specified also. Has to be either numeric, an ISO 8601 DateTime format or the string PRESENT. If left blank GeoServer will determine the value automatically based on the data. When using 'PRESENT' the current DateTime of the server will be used when the capabilities document is generated. Setting this value manually may be desired when working with layers consisting of huge amounts of data where the automatic determination can get slow. This parameter is only handled for WMS Layers in their capabilities document.
                                                                      • End of data range---A manually declared end value for the data range. When specified, the Begin of data range has to be specified also. Has to be either numeric, an ISO 8601 DateTime format or the string PRESENT. If left blank GeoServer will determine the value automatically based on the data. When using 'PRESENT' the current DateTime of the server will be used when the capabilities document is generated. Setting this value manually may be desired when working with layers consisting of huge amounts of data where the automatic determination can get slow. This parameter is only handled for WMS Layers in their capabilities document.
                                                                      "},{"location":"data/webadmin/layers/#edit-layer-security","title":"Edit Layer: Security","text":"

                                                                      Note

                                                                      For more information on data access rules, please see the section on Data.

                                                                      Sets data access rules at layer level.

                                                                      To create/edit layer's data access rules simply check/uncheck checkboxes according to desired access mode and role. The Grant access to any role checkbox grant each role for each access mode.

                                                                      "},{"location":"data/webadmin/stores/","title":"Stores","text":"

                                                                      A store connects to a data source that contains raster or vector data. A data source can be a file or group of files, a table in a database, a single raster file, or a directory (for example, a Vector Product Format library). The store construct allows connection parameters to be defined once, rather than for each dataset in a source. As such, it is necessary to register a store before configuring datasets within it.

                                                                      Stores View

                                                                      "},{"location":"data/webadmin/stores/#store-types","title":"Store types","text":"

                                                                      While there are many potential formats for data sources, there are only four kinds of stores. For raster data, a store can be a file. For vector data, a store can be a file, database, or server.

                                                                      Type Icon Description raster data in a file vector data in a file vector data in a database vector server (web feature server)"},{"location":"data/webadmin/stores/#edit-a-store","title":"Edit a Store","text":"

                                                                      To view or edit a store, click the store name. A store configuration page will be displayed. The exact contents of this page depend on the specific format of the store. See the sections Vector data, Raster data, and Databases for information about specific data formats. The example shows the configuration for the nurc:ArcGridSample store.

                                                                      Editing a raster data store

                                                                      "},{"location":"data/webadmin/stores/#basic-store-info","title":"Basic Store Info","text":"

                                                                      The basic information is common for all formats.

                                                                      • Workspace - the store is assigned to the selected workspace
                                                                      • Data Source Name - the store name as listed on the view page
                                                                      • Description - (optional) a description that displays in the administration interface
                                                                      • Enabled - enables or disables access to the store, along with all datasets defined for it
                                                                      • Auto disable on connection failure - auto disables access to the store if any issue happens when geoserver tries to acquire access to the store
                                                                      "},{"location":"data/webadmin/stores/#connection-parameters","title":"Connection Parameters","text":"

                                                                      The connection parameters vary depending on data format.

                                                                      "},{"location":"data/webadmin/stores/#data_webadmin_stores_add_a_store","title":"Add a Store","text":"

                                                                      The buttons for adding and removing a store can be found at the top of the Stores page.

                                                                      Buttons to add and remove a Store

                                                                      To add a store, select the Add new Store button. You will be prompted to choose a data source. GeoServer natively supports many formats (with more available via extensions). Click the appropriate data source to continue.

                                                                      Choosing the data source for a new store

                                                                      The next page configures the store. Since connection parameters differ across data sources, the exact contents of this page depend on the store's specific format. See the sections Vector data, Raster data, and Databases for information on specific data formats. The example below shows the ArcGrid raster configuration page.

                                                                      Configuration page for an ArcGrid raster data source

                                                                      "},{"location":"data/webadmin/stores/#remove-a-store","title":"Remove a Store","text":"

                                                                      To remove a store, click the checkbox next to the store. Multiple stores can be selected, or all can be selected by clicking the checkbox in the header.

                                                                      Stores selected for removal

                                                                      Click the Remove selected Stores button. You will be asked to confirm the removal of the configuration for the store(s) and all resources defined under them. Clicking OK removes the selected store(s), and returns to the Stores page.

                                                                      Confirm removal of stores

                                                                      "},{"location":"data/webadmin/workspaces/","title":"Workspaces","text":"

                                                                      This section describes how to view and configure workspaces. Analogous to a namespace, a workspace is a container which organizes other items. In GeoServer, a workspace is often used to group similar layers together. Layers may be referred to by their workspace name, colon, layer name (for example topp:states). Two different layers can have the same name as long as they belong to different workspaces (for example sf:states and topp:states).

                                                                      Workspaces page

                                                                      "},{"location":"data/webadmin/workspaces/#data_webadmin_workspaces_add_workspace","title":"Add a Workspace","text":"

                                                                      The buttons for adding and removing a workspace can be found at the top of the Workspaces view page.

                                                                      Buttons to add and remove

                                                                      To add a workspace, select the Add new workspace button. You will be prompted to enter the workspace name and URI (as described in Edit a Workspace below).

                                                                      New Workspace page with example

                                                                      "},{"location":"data/webadmin/workspaces/#remove-a-workspace","title":"Remove a Workspace","text":"

                                                                      To remove a workspace, select it by clicking the checkbox next to the workspace. Multiple workspaces can be selected, or all can be selected by clicking the checkbox in the header. Click the Remove selected workspaces(s) button. You will be asked to confirm or cancel the removal. Clicking OK removes the selected workspace(s).

                                                                      Workspace removal confirmation

                                                                      "},{"location":"data/webadmin/workspaces/#data_webadmin_workspaces_edit","title":"Edit a Workspace","text":"

                                                                      To view or edit a workspace, click the workspace name. A workspace configuration page will be displayed.

                                                                      Workspace named \"topp\"

                                                                      A workspace is defined by a name and a Namespace URI (Uniform Resource Identifier).

                                                                      • Name: The workspace name, may not contain whitespace.

                                                                        The workspace name is used as an XML prefix for the Namespace URI when generating xml documents.

                                                                        The workspace name is used as a prefix when naming individual layers (unless Default workspace is used as described below).

                                                                      • Namespace URI: A URI is similar to a URL, except URIs do not need to point to an actual location on the web, and only need to be a unique identifier.

                                                                        For a Workspace URI, we recommend using a URL associated with your project, with perhaps a different trailing identifier. For example, http://www.openplans.org/topp is the URI for the \"topp\" workspace.

                                                                      • Default Workspace: One workspace can be nominated as the default.

                                                                        Layers belonging to the default workspace can be accessed directly, and do not require the workspace name as a prefix.

                                                                        A GeoServer configured with one workspace can use this setting to avoid using the workspace name when referencing layers. Keep in mind the workspace name will still be used in the generation of xml documents (where the name is used as an XML prefix to reference the workspace Namespace URI).

                                                                      • Isolated workspace: Isolated workspaces content so they are not included as part of global web services.

                                                                        The workspace contents will only be visible and queryable in the context of a Virtual Services as described below Isolated Workspaces.

                                                                      "},{"location":"data/webadmin/workspaces/#workspace_services","title":"Workspace Services","text":"

                                                                      Use the checkbox located next to each service to override the global service definition for the associated service.

                                                                      Enable workspace services to provide default service description

                                                                      Once enabled clicking on the service link will open the settings page for the service, allowing default values for service title, abstract and other details to be supplied.

                                                                      Workspace WMS Settings

                                                                      Clients accessing this workspace as a Virtual Services will use the service metadata and settings provided here.

                                                                      "},{"location":"data/webadmin/workspaces/#workspace_settings","title":"Workspace Settings","text":"

                                                                      Use Enabled checkbox to override the global configuration and contact information for this workspace.

                                                                      Enable workspace settings to provide default contact information

                                                                      "},{"location":"data/webadmin/workspaces/#contact-information","title":"Contact Information","text":"

                                                                      Clients accessing this workspace as a Virtual Services will use the contact information provided here.

                                                                      Organization contact information:

                                                                      • The Welcome message is used as an introduction in the welcome page header for this workspace.
                                                                      • The Organization name and Online Resource are combined to form an organization link in the welcome page header for this workspace.

                                                                      Workspace Organization

                                                                      Primary contact information:

                                                                      • The email address if provided, will be used as the administrator contact in the welcome page footer for this workspace.

                                                                      Workspace Primary Contact

                                                                      Address contact information:

                                                                      Workspace address

                                                                      If this information is not provided the contact information from the global Contact Information page is used.

                                                                      "},{"location":"data/webadmin/workspaces/#service-settings","title":"Service Settings","text":"

                                                                      Other settings provide additional Global Settings can be overridden on a workspace-by-workspace basis.

                                                                      • Include Layer Prefix in Local Workspace Capabilities: Enable this setting to force the inclusion of the workspace name as a prefix when accessing workspace contents as a virtual web service. The layer ne:countries is always referenced as ne:countries with this setting enabled.

                                                                        With this setting disabled layers may be referenced directly (with no prefix) when accessed by a virtual web service. The layer ne:countries can be referenced as countries when this setting is disabled (and the layer is being accessed via a ne virtual web service).

                                                                      • Root Directory for REST PathMapper: setting used by the RESTful API as the Root Directory for uploaded files, following the structure:

                                                                        ${rootDirectory}/workspace/store[/<file>]\n

                                                                        Note

                                                                        This parameter is only used when the Enabled parameter of the Settings section is checked.

                                                                      Other Settings

                                                                      If this information is not provided the global settings will be used. For details on other settings see Global Settings.

                                                                      "},{"location":"data/webadmin/workspaces/#workspace_security","title":"Security","text":"

                                                                      The Security tab allows to set data access rules at workspace level.

                                                                      Note

                                                                      For more information on data access rules, please see the section on Data.

                                                                      To create/edit the workspace's data access rules, check/uncheck checkboxes according to the desired role. The Grant access to any role checkbox grant each role for any access mode.

                                                                      "},{"location":"datadirectory/","title":"GeoServer data directory","text":"

                                                                      The GeoServer data directory is the location in the file system where GeoServer stores its configuration information.

                                                                      The configuration defines what data is served by GeoServer, where it is stored, and how services interact with and serve the data. The data directory also contains a number of support files used by GeoServer for various purposes.

                                                                      For production use, it is recommended to define an external data directory (outside the application) to make it easier to upgrade. The Setting the data directory location section describes how to configure GeoServer to use an existing data directory.

                                                                      Note

                                                                      Since GeoServer provides both an interactive interface (via the web admin interface) and programmatic interface (through the REST API) to manage configuration, most users do not need to know about the internal structure of the data directory, but an overview is provided below.

                                                                      • Data directory default location
                                                                      • Setting the data directory location
                                                                      • Structure of the data directory
                                                                      • Migrating a data directory between versions
                                                                      • Parameterize catalog settings
                                                                      "},{"location":"datadirectory/configtemplate/","title":"Parameterize catalog settings","text":"

                                                                      Environment parametrization allows to parameterize some of the settings in GeoServer's catalog by means of a templating mechanism to tailor GeoServer's settings to the environment in which is run.

                                                                      For example, there might be the need to move the latest changes made from a GeoServer instance running on machine A to another instance running on machine B, but there are some differences in the way the two environments are set up (e.g. the password used to connect to the database is different). In such scenario if a simple backup of the catalog from instance A is created and restored on instance B, the stores configured on the database will not be accessible and the corresponding layers will not work properly.

                                                                      Another example can be the need to have different connection pool configuration for two different GeoServer instances, with respect to the max number of connections available in the pool.

                                                                      To enable env parametrization the following flag needs to be set via system variable to GeoServer's environment:

                                                                      -DALLOW_ENV_PARAMETRIZATION=true\n

                                                                      A properties file holding the parametrized settings needs to be created. It can be provided by naming it geoserver-environment.properties and by placing it in the root directory of the GeoServer's DATA_DIR.

                                                                      GeoServer is also able to use a properties file outside the GeoServer's DATA_DIR. In this case the path to the properties file must be defined in one of the following ways:

                                                                      • By providing a system variable -DENV_PROPERTIES={properties filepath}.
                                                                      • By providing an environment variable named ENV_PROPERTIES and the path to the properties file as the value.
                                                                      • By providing a context parameter in the WEB-INF/web.xml file for the GeoServer application:
                                                                      <web-app>\n  ...\n  <context-param>\n    <param-name>ENV_PROPERTIES</param-name>\n    <param-value>/var/lib/geoserver_data</param-value>\n  </context-param>\n  ...\n</web-app>\n

                                                                      Once a strategy to load the ENV_PROPERTIES has been defined and set, it is possible to edit GeoServer's configuration files of the source machine that needs to be parametrized. For example, let's parameterize the URL of a store (this can also be done via GeoServer admin UI):

                                                                      vim coveragestore.xml :

                                                                      ...\n <enabled>true</enabled>\n  <workspace>\n    <id>WorkspaceInfoImpl--134aa31e:1564c12ef68:-7ffe</id>\n  </workspace>\n  <__default>false<!--__default-->\n  <url>${store_url}</url>\n</coverageStore>\n

                                                                      A definition for the variable store_url needs to be added in

                                                                      geoserver-environment.properties :

                                                                      store_url = file:///var/geoserver/store/teststore\n

                                                                      Once GeoServer has been restarted, it is possible to see that the URL in \"Connection Parameters\" settings now refers the variable store_url whose value is defined in the geoserver-environment.properties file.

                                                                      Another common use case is parameterizing connection details for a vector datastore. Hostname, credentials and connection pool parameters for the databases tend to change between environments. Once the variables are set in the geoserver-environment.properties file, the Datastore can be configured as follows:

                                                                      "},{"location":"datadirectory/location/","title":"Data directory default location","text":"

                                                                      If GeoServer is running in standalone mode (via an installer or a binary) the data directory is located at <installation root>/data_dir.

                                                                      Standalone platform Default/typical location Windows (except XP) C:\\Program Files\\GeoServer 2.24.2\\data_dir Windows XP C:\\Program Files\\GeoServer 2.24.2\\data_dir Mac OS X /Applications/GeoServer.app/Contents/Resources/Java/data_dir Linux (Tomcat) /var/lib/tomcat9/webapps/geoserver/data

                                                                      If GeoServer is running as a web archive inside of a custom-deployed application server, the data directory is by default located at <web application root>/data.

                                                                      "},{"location":"datadirectory/location/#creating-a-new-data-directory","title":"Creating a new data directory","text":"

                                                                      The easiest way to create a new data directory is to copy an existing one.

                                                                      Once the data directory has been located, copy it to a new location. To point a GeoServer instance at the new data directory proceed to the next section Setting the data directory location.

                                                                      "},{"location":"datadirectory/migrating/","title":"Migrating a data directory between versions","text":"

                                                                      It is possible to keep the same data directory while migrating to different versions of GeoServer, such as during an update.

                                                                      There should generally be no problems or issues migrating data directories between patch versions of GeoServer (for example, from 2.9.0 to 2.9.1 or vice versa).

                                                                      Similarly, there should rarely be any issues involved with migrating between minor versions (for example, from 2.8.x to 2.9.x). Care should be taken to back up the data directory prior to migration.

                                                                      Note

                                                                      Some minor version migrations may not be reversible, since newer versions of GeoServer may make backwards-incompatible changes to the data directory.

                                                                      "},{"location":"datadirectory/setting/","title":"Setting the data directory location","text":"

                                                                      The procedure for setting the location of the GeoServer data directory is dependent on the type of GeoServer installation. Follow the instructions below specific to the target platform.

                                                                      Note

                                                                      If the location of the GeoServer data directory is not set explicitly, the directory data_dir under the root of the GeoServer installation will be chosen by default.

                                                                      "},{"location":"datadirectory/setting/#windows","title":"Windows","text":"

                                                                      On Windows platforms the location of the GeoServer data directory is controlled by the GEOSERVER_DATA_DIR environment variable.

                                                                      To set the environment variable:

                                                                      1. Open the System Control Panel.

                                                                      2. Click Advanced System Properties.

                                                                      3. Click Environment Variables.

                                                                      4. Click the New button and create a environment variable called GEOSERVER_DATA_DIR and set it to the desired location.

                                                                        Setting an environment variable on Windows

                                                                      "},{"location":"datadirectory/setting/#linux","title":"Linux","text":"

                                                                      On Linux platforms the location of the GeoServer data directory is controlled by the GEOSERVER_DATA_DIR environment variable. Setting the variable can be achieved with the following command (in the terminal):

                                                                      export GEOSERVER_DATA_DIR=/var/lib/geoserver_data\n

                                                                      To make the variable persist, place the command in the .bash_profile or .bashrc file. Ensure that this done for the user running GeoServer.

                                                                      "},{"location":"datadirectory/setting/#mac-os-x","title":"Mac OS X","text":"

                                                                      For the binary install of GeoServer on Mac OS X, the data directory is set in the same way as for Linux.

                                                                      For the Mac OS X install, set the GEOSERVER_DATA_DIR environment variable to the desired directory location. See this page for details on how to set an environment variable in Mac OS X.

                                                                      "},{"location":"datadirectory/setting/#web-archive","title":"Web archive","text":"

                                                                      When running a GeoServer WAR inside a servlet container, the data directory can be specified in a number of ways. The recommended method is to set a servlet context parameter. An alternative is to set a Java system property.

                                                                      "},{"location":"datadirectory/setting/#context-parameter","title":"Context parameter","text":"

                                                                      To specify the data directory using a servlet context parameter, create the following <context-param> element in the WEB-INF/web.xml file for the GeoServer application:

                                                                      <web-app>\n  ...\n  <context-param>\n    <param-name>GEOSERVER_DATA_DIR</param-name>\n    <param-value>/var/lib/geoserver_data</param-value>\n  </context-param>\n  ...\n</web-app>\n
                                                                      "},{"location":"datadirectory/setting/#java-system-property","title":"Java system property","text":"

                                                                      It is also possible to specify the data directory location with a Java system property. This method can be useful during upgrades, as it avoids the need to set the data directory after every upgrade.

                                                                      Warning

                                                                      Using a Java system property will typically set the property for all applications running in the servlet container, not just GeoServer.

                                                                      The method of setting the Java system property is dependent on the servlet container:

                                                                      • For Tomcat, edit the file bin/setclasspath.sh under the root of the Tomcat installation. Specify the GEOSERVER_DATA_DIR system property by setting the CATALINA_OPTS variable:

                                                                        CATALINA_OPTS=\"-DGEOSERVER_DATA_DIR=/var/lib/geoserver_data\"\n
                                                                      • For Glassfish, edit the file domains/<<domain>>/config/domain.xml under the root of the Glassfish installation, where <<domain>> refers to the domain that the GeoServer web application is deployed under. Add a <jvm-options> element inside the <java-config> element:

                                                                        ...\n<java-config>\n   ...\n  <jvm-options>-DGEOSERVER_DATA_DIR=/var/lib/geoserver_data</jvm-options>  \n</java-config>\n...\n
                                                                      "},{"location":"datadirectory/setting/#require-files-to-exist","title":"Require files to exist","text":"

                                                                      If the data directory is on a network filesystem, it can be desirable for security reasons to require one or more files or directories to exist before GeoServer will start, to prevent GeoServer from falling back into a default insecure configuration if the data directory appears to be empty because of the loss of this network resource.

                                                                      To require files or directories to exist, use any of the methods above to set GEOSERVER_REQUIRE_FILE. Do not specify a mount point as this will still exist if a network filesystem is unavailable; instead specify a file or directory inside a network mount. For example:

                                                                      Environment variable:

                                                                      export GEOSERVER_REQUIRE_FILE=/mnt/server/geoserver_data/global.xml\n

                                                                      Servlet context parameter:

                                                                      <web-app>\n  ...\n  <context-param>\n    <param-name>GEOSERVER_REQUIRE_FILE</param-name>\n    <param-value>/mnt/server/geoserver_data/global.xml</param-value>\n  </context-param>\n  ...\n</web-app>\n

                                                                      Java system property:

                                                                      CATALINA_OPTS=\"-DGEOSERVER_REQUIRE_FILE=/mnt/server/geoserver_data/global.xml\"\n
                                                                      "},{"location":"datadirectory/setting/#multiple-files","title":"Multiple files","text":"

                                                                      To specify multiple files or directories that must exist, separate them with the path separator (: on Linux, ; on Windows):

                                                                      Environment variable:

                                                                      export GEOSERVER_REQUIRE_FILE=/mnt/server/geoserver_data/global.xml:/mnt/server/data\n

                                                                      Servlet context parameter:

                                                                      <web-app>\n  ...\n  <context-param>\n    <param-name>GEOSERVER_REQUIRE_FILE</param-name>\n    <param-value>/mnt/server/geoserver_data/global.xml:/mnt/server/data</param-value>\n  </context-param>\n  ...\n</web-app>\n

                                                                      Java system property:

                                                                      CATALINA_OPTS=\"-DGEOSERVER_REQUIRE_FILE=/mnt/server/geoserver_data/global.xml:/mnt/server/data\"\n
                                                                      "},{"location":"datadirectory/structure/","title":"Structure of the data directory","text":"

                                                                      This section gives an overview of the structure and contents of the GeoServer data directory.

                                                                      This is not intended to be a complete reference to the GeoServer configuration information, since generally the data directory configuration files should not be accessed directly.

                                                                      Instead, the web_admin can be used to view and modify the configuration, and for programmatic access and manipulation the REST API <../rest/index.rst>_ should be used.

                                                                      The directories that do contain user-modifiable content are:

                                                                      • logs
                                                                      • palettes
                                                                      • templates
                                                                      • user_projections
                                                                      • www
                                                                      "},{"location":"datadirectory/structure/#top-level-xml-files","title":"Top-level XML files","text":"

                                                                      The top-level XML files contain information about the services and various global options for the server instance.

                                                                      File Description global.xml Contains settings common to all services, such as contact information, JAI settings, character sets and verbosity. logging.xml Specifies logging parameters, such as logging level, logfile location, and whether to log to stdout. wcs.xml Contains the service metadata and various settings for the WCS service. wfs.xml Contains the service metadata and various settings for the WFS service. wms.xml Contains the service metadata and various settings for the WMS service."},{"location":"datadirectory/structure/#workspaces","title":"workspaces","text":"

                                                                      The workspaces directory contain metadata about the layers published by GeoServer. It contains a directory for each defined workspace.

                                                                      Each workspace directory contains directories for the datastores defined in it. Each datastore directory contains directories for the layers defined for the datastore.

                                                                      Each layer directory contains a layer.xml file, and either a coverage.xml or a featuretype.xml file depending on whether the layer represents a raster or vector dataset.

                                                                      "},{"location":"datadirectory/structure/#data","title":"data","text":"

                                                                      The data directory can be used to store file-based geospatial datasets being served as layers.

                                                                      Note

                                                                      This should not be confused with the main GeoServer data directory, which is the parent to this directory.

                                                                      This directory is commonly used to store shapefiles and raster files, but can be used for any data that is file-based.

                                                                      The main benefit of storing data files under the data directory is portability.

                                                                      Consider a shapefile stored external to the data directory at a location C:\\gis_data\\foo.shp. The datastore entry in catalog.xml for this shapefile would look like the following:

                                                                      <datastore id=\"foo_shapefile\">\n   <connectionParams>\n     <parameter name=\"url\" value=\"file://C:/gis_data/foo.shp\" />\n   </connectionParams>\n </datastore>\n

                                                                      Now consider trying to port this data directory to another host running GeoServer. The location C:\\gis_data\\foo.shp probably does not exist on the second host. So either the file must be copied to this location on the new host, or catalog.xml must be changed to reflect a new location.

                                                                      This problem can be avoided by storing foo.shp in the data directory. In this case the datastore entry in catalog.xml becomes:

                                                                      <datastore id=\"foo_shapefile\">\n  <connectionParams>\n    <parameter name=\"url\" value=\"file:data/foo.shp\"/>\n  </connectionParams>\n</datastore>\n

                                                                      The value attribute is rewritten to be relative to the data directory. This location independence allows the entire data directory to be copied to a new host and used directly with no additional changes.

                                                                      "},{"location":"datadirectory/structure/#demo","title":"demo","text":"

                                                                      The demo directory contains files which define the sample requests available in the Demo Request page.

                                                                      "},{"location":"datadirectory/structure/#gwc","title":"gwc","text":"

                                                                      The gwc directory holds the tile cache created by the embedded GeoWebCache service.

                                                                      "},{"location":"datadirectory/structure/#layergroups","title":"layergroups","text":"

                                                                      The layergroups directory contains configuration information for the defined layergroups.

                                                                      "},{"location":"datadirectory/structure/#logs","title":"logs","text":"

                                                                      The logs directory contains configuration information for the various defined logging profiles, and the default geoserver.log log file.

                                                                      Note

                                                                      See also the Logging section for more details.

                                                                      "},{"location":"datadirectory/structure/#palettes","title":"palettes","text":"

                                                                      The palettes directory is used to store pre-computed Image Palettes. Image palettes are used by the GeoServer WMS as way to reduce the size of produced images while maintaining image quality.

                                                                      Note

                                                                      See also the Paletted Images tutorial for more information.

                                                                      "},{"location":"datadirectory/structure/#security","title":"security","text":"

                                                                      The security directory contains the files used to configure the GeoServer security subsystem. This includes a set of property files which define access roles, along with the services and data each role is authorized to access.

                                                                      Note

                                                                      See also the Security section for more information.

                                                                      "},{"location":"datadirectory/structure/#styles","title":"styles","text":"

                                                                      The styles directory contains files which contain styling information used by the GeoServer WMS.

                                                                      Note

                                                                      See also the Styling section for more information.

                                                                      For each SLD file in this directory there is a corresponding XML file:

                                                                      <style>\n  <id>StyleInfoImpl--570ae188:124761b8d78:-7fe1</id>\n  <name>grass</name>\n  <sldVersion>\n    <version>1.0.0</version>\n  </sldVersion>\n  <filename>grass_poly.sld</filename>\n  <legend>\n    <width>32</width>\n    <height>32</height>\n    <format>image/png</format>\n    <onlineResource>grass_fill.png</onlineResource>\n  </legend>\n</style>\n

                                                                      The styles directory can also be used to host support files referenced during style configuration:

                                                                      • Support files: SLD files can reference external graphics. This is useful when supplying your own icons in the form of image files or TrueType font files. Without any path information supplied, the default will be this directory.
                                                                      • A style external graphic is dynamically created for use as a legend. The contents of the directory is published allowing clients to access the legends used. When running GeoServer on localhost, an image file image.png stored in this directory can be referenced in a browser using http:/<host:port>/geoserver/styles/image.png.
                                                                      "},{"location":"datadirectory/structure/#templates","title":"templates","text":"

                                                                      The templates directory contains files used by the GeoServer templating subsystem. Templates are used to customize the output of various GeoServer operations.

                                                                      Note

                                                                      See also Freemarker Templates for more information..

                                                                      "},{"location":"datadirectory/structure/#user_projections","title":"user_projections","text":"

                                                                      The user_projections directory contains a file called epsg.properties which is used to define custom spatial reference systems that are not part of the official EPSG database.

                                                                      Note

                                                                      See also Custom CRS Definitions for more information.

                                                                      "},{"location":"datadirectory/structure/#www","title":"www","text":"

                                                                      The www directory is used to allow GeoServer to serve files like a regular web server. While not a replacement for a full web server, this can be useful for serving client-side mapping applications. The contents of this directory are served at http:/<host:port>/geoserver/www.

                                                                      Note

                                                                      See also Serving Static Files for more information.

                                                                      "},{"location":"extensions/","title":"Extensions","text":"

                                                                      Extensions are modules that add functionality to GeoServer. They are installed as add-ons to the base GeoServer installation.

                                                                      This section describes most of the extensions available for GeoServer. Other data formats can be found in the Vector data, Raster data, Databases, and Styling sections.

                                                                      • Key authentication module
                                                                      • Control flow module
                                                                      • DXF OutputFormat for WFS and WPS PPIO
                                                                      • Excel WFS Output Format
                                                                      • GeoPackage Output
                                                                      • GRIB
                                                                      • Importer
                                                                      • INSPIRE
                                                                      • JP2K Plugin
                                                                      • libjpeg-turbo Map Encoder Extension
                                                                      • Monitoring
                                                                      • NetCDF
                                                                      • NetCDF Output Format
                                                                      • OGR based WFS Output Format
                                                                      • GeoServer Printing Module
                                                                      • Cross-layer filtering
                                                                      • Vector Tiles
                                                                      • Web Coverage Service 2.0 Earth Observation extensions
                                                                      • MongoDB Data Store
                                                                      • SLD REST Service
                                                                      • Geofence Plugin
                                                                      • Geofence Internal Server
                                                                      • Geofence WPS Integration
                                                                      • CAS integration
                                                                      • Parameters Extractor
                                                                      • GWC S3 BlobStore plugin
                                                                      • WMTS Multidimensional
                                                                      • WPS Download plugin
                                                                      • WPS JDBC
                                                                      • MapML
                                                                      • Catalog Services for the Web (CSW) - ISO Metadata Profile
                                                                      • Metadata
                                                                      • IAU planetary CRSs
                                                                      "},{"location":"extensions/excel/","title":"Excel WFS Output Format","text":"

                                                                      The GeoServer Excel plugin adds the ability to output WFS responses in either Excel 97-2003 (.xls) or Excel 2007 (.xlsx) formats.

                                                                      "},{"location":"extensions/excel/#installation","title":"Installation","text":"
                                                                      1. From the website download page, locate your release, and download: excel
                                                                      2. Unzip the archive into the WEB-INF/lib directory of the GeoServer installation.
                                                                      3. Restart GeoServer.
                                                                      "},{"location":"extensions/excel/#usage","title":"Usage","text":"

                                                                      When making a WFS request, set the outputFormat to excel (for Excel 97-2003) or excel2007 (for Excel 2007).

                                                                      "},{"location":"extensions/excel/#examples","title":"Examples","text":"Excel 97-2003 GET:

                                                                      http://localhost:8080/geoserver/wfs?request=GetFeature&version=1.1.0&typeName=topp:states&outputFormat=excel

                                                                      Excel 2007 GET:

                                                                      http://localhost:8080/geoserver/wfs?request=GetFeature&version=1.1.0&typeName=topp:states&outputFormat=excel2007

                                                                      Excel 97-2003 POST:

                                                                      <wfs:GetFeature service=\"WFS\" version=\"1.1.0\"\n  outputFormat=\"excel\"\n  xmlns:topp=\"http://www.openplans.org/topp\"\n  xmlns:wfs=\"http://www.opengis.net/wfs\"\n  xmlns:ogc=\"http://www.opengis.net/ogc\"\n  xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\"\n  xsi:schemaLocation=\"http://www.opengis.net/wfs\n                      http://schemas.opengis.net/wfs/1.1.0/wfs.xsd\">\n  <wfs:Query typeName=\"topp:states\" />\n</wfs:GetFeature>\n
                                                                      "},{"location":"extensions/excel/#limitations","title":"Limitations","text":"

                                                                      Excel 97-2003 files are stored in a binary format and are thus space-efficient, but have inherent size limitations (65,526 rows per sheet; 256 columns per sheet).

                                                                      Excel 2007 files are XML-based, and have much higher limits (1,048,576 rows per sheet; 16,384 columns per sheet). However, because they are text files Excel 2007 files are usually larger than Excel 97-2003 files.

                                                                      If the number of rows in a sheet or characters in a cell exceeds the limits of the chosen Excel file format, warning text is inserted to indicate the truncation.

                                                                      "},{"location":"extensions/ogr/","title":"OGR based WFS Output Format","text":"

                                                                      The ogr2ogr based output format leverages the availability of the ogr2ogr command to allow the generation of more output formats than GeoServer can natively produce. The basics idea is to dump to the file system a file that ogr2ogr can translate, invoke it, zip and return the output of the translation.

                                                                      "},{"location":"extensions/ogr/#out-of-the-box-behaviour","title":"Out of the box behaviour","text":"

                                                                      Out of the box the plugin assumes the following:

                                                                      • ogr2ogr is available in the path
                                                                      • the GDAL_DATA variable is pointing to the GDAL data directory (which stores the spatial reference information for GDAL)

                                                                      In the default configuration the following formats are supported:

                                                                      • MapInfo in TAB format
                                                                      • MapInfo in MIF format
                                                                      • Un-styled KML
                                                                      • CSV (without geometry data dumps)

                                                                      The list might be shorter if ogr2ogr has not been built with support for the above formats.

                                                                      Once installed in GeoServer four new GetFeature output formats will be available, in particular, OGR-TAB, OGR-MIF, OGR-KML, OGR-CSV.

                                                                      "},{"location":"extensions/ogr/#ogr2ogr-conversion-abilities","title":"ogr2ogr conversion abilities","text":"

                                                                      The ogr2ogr utility is usually able to convert more formats than the default setup of this output format allows for, but the exact list depends on how the utility was built from sources. To get a full list of the formats available by your ogr2ogr build just run:

                                                                      ogr2ogr --help\n

                                                                      and you'll get the full set of options usable by the program, along with the supported formats. For example, the above produces the following output using the FWTools 2.2.8 distribution (which includes ogr2ogr among other useful information and conversion tools):

                                                                      Usage: ogr2ogr [--help-general] [-skipfailures] [-append] [-update] [-gt n]\n            [-select field_list] [-where restricted_where] \n            [-sql <sql statement>] \n            [-spat xmin ymin xmax ymax] [-preserve_fid] [-fid FID]\n            [-a_srs srs_def] [-t_srs srs_def] [-s_srs srs_def]\n            [-f format_name] [-overwrite] [[-dsco NAME=VALUE] ...]\n            [-segmentize max_dist]\n            dst_datasource_name src_datasource_name\n            [-lco NAME=VALUE] [-nln name] [-nlt type] [layer [layer ...]]\n\n-f format_name: output file format name, possible values are:\n  -f \"ESRI Shapefile\"\n  -f \"MapInfo File\"\n  -f \"TIGER\"\n  -f \"S57\"\n  -f \"DGN\"\n  -f \"Memory\"\n  -f \"BNA\"\n  -f \"CSV\"\n  -f \"GML\"\n  -f \"GPX\"\n  -f \"KML\"\n  -f \"GeoJSON\"\n  -f \"Interlis 1\"\n  -f \"Interlis 2\"\n  -f \"GMT\"\n  -f \"SQLite\"\n  -f \"ODBC\"\n  -f \"PostgreSQL\"\n  -f \"MySQL\"\n  -f \"Geoconcept\"\n-append: Append to existing layer instead of creating new if it exists\n-overwrite: delete the output layer and recreate it empty\n-update: Open existing output datasource in update mode\n-select field_list: Comma-delimited list of fields from input layer to\n                    copy to the new layer (defaults to all)\n-where restricted_where: Attribute query (like SQL WHERE)\n-sql statement: Execute given SQL statement and save result.\n-skipfailures: skip features or layers that fail to convert\n-gt n: group n features per transaction (default 200)\n-spat xmin ymin xmax ymax: spatial query extents\n-segmentize max_dist: maximum distance between 2 nodes.\n                      Used to create intermediate points\n-dsco NAME=VALUE: Dataset creation option (format specific)\n-lco  NAME=VALUE: Layer creation option (format specific)\n-nln name: Assign an alternate name to the new layer\n-nlt type: Force a geometry type for new layer.  One of NONE, GEOMETRY,\n     POINT, LINESTRING, POLYGON, GEOMETRYCOLLECTION, MULTIPOINT,\n     MULTIPOLYGON, or MULTILINESTRING.  Add \"25D\" for 3D layers.\n     Default is type of source layer.\n-a_srs srs_def: Assign an output SRS\n-t_srs srs_def: Reproject/transform to this SRS on output\n-s_srs srs_def: Override source SRS\n\nSrs_def can be a full WKT definition (hard to escape properly),\nor a well known definition (ie. EPSG:4326) or a file with a WKT\ndefinition.\n

                                                                      The full list of formats that ogr2ogr is able to support is available on the OGR site. Mind that this output format can handle only outputs that are file based and that do support creation. So, for example, you won't be able to use the Postgres output (since it's database based) or the ArcInfo binary coverage (creation not supported).

                                                                      "},{"location":"extensions/ogr/#customisation","title":"Customisation","text":"

                                                                      If ogr2ogr is not available in the default path, the GDAL_DATA is not set, or if the output formats needs tweaking, a ogr2ogr.xml file can be put in the root of the GeoServer data directory to customize the output format.

                                                                      The default GeoServer configuration is equivalent to the following xml file:

                                                                      <OgrConfiguration>\n  <ogr2ogrLocation>ogr2ogr</ogr2ogrLocation>\n  <!-- <gdalData>...</gdalData> -->\n  <formats>\n    <Format>\n      <ogrFormat>MapInfo File</ogrFormat>\n      <formatName>OGR-TAB</formatName>\n      <fileExtension>.tab</fileExtension>\n    </Format>\n    <Format>\n      <ogrFormat>MapInfo File</ogrFormat>\n      <formatName>OGR-MIF</formatName>\n      <fileExtension>.mif</fileExtension>\n      <option>-dsco</option>\n      <option>FORMAT=MIF</option>\n    </Format>\n    <Format>\n      <ogrFormat>CSV</ogrFormat>\n      <formatName>OGR-CSV</formatName>\n      <fileExtension>.csv</fileExtension>\n      <singleFile>true</singleFile>\n      <mimeType>text/csv</mimeType>\n    </Format>\n    <Format>\n      <ogrFormat>KML</ogrFormat>\n      <formatName>OGR-KML</formatName>\n      <fileExtension>.kml</fileExtension>\n      <singleFile>true</singleFile>\n      <mimeType>application/vnd.google-earth.kml</mimeType>\n    </Format>\n  </formats>\n</OgrConfiguration>\n

                                                                      The file showcases all possible usage of the configuration elements:

                                                                      • ogr2ogrLocation can be just ogr2ogr if the command is in the path, otherwise it should be the full path to the executable. For example, on a Windows box with FWTools installed it might be:

                                                                        <ogr2ogrLocation>c:\\Programmi\\FWTools2.2.8\\bin\\ogr2ogr.exe</ogr2ogrLocation>\n
                                                                      • gdalData must point to the GDAL data directory. For example, on a Windows box with FWTools installed it might be:

                                                                        <gdalData>c:\\Programmi\\FWTools2.2.8\\data</gdalData>\n
                                                                      • Format defines a single format, which is defined by the following tags:

                                                                        • ogrFormat: the name of the format to be passed to ogr2ogr with the -f option (it's case sensitive).
                                                                        • formatName: is the name of the output format as advertised by GeoServer
                                                                        • fileExtension: is the extension of the file generated after the translation, if any (can be omitted)
                                                                        • option: can be used to add one or more options to the ogr2ogr command line. As you can see by the MIF example, each item must be contained in its own tag. You can get a full list of options by running ogr2ogr --help or by visiting the ogr2ogr web page. Also consider that each format supports specific creation options, listed in the description page for each format (for example, here is the MapInfo one).
                                                                        • singleFile (since 2.0.3): if true the output of the conversion is supposed to be a single file that can be streamed directly back without the need to wrap it into a zip file
                                                                        • mimeType (since 2.0.3): the mime type of the file returned when using singleFile. If not specified application/octet-stream will be used as a default.
                                                                      "},{"location":"extensions/ogr/#ogr-based-wps-output-format","title":"OGR based WPS Output Format","text":"

                                                                      The OGR based WPS output format provides the ability to turn feature collection (vector layer) output types into formats supported by OGR, using the same configuration and same machinery provided by the OGR WFS output format (which should also be installed for the WPS portion to work).

                                                                      Unlike the WFS case the WPS output formats are receiving different treatment in WPS responses depending on whether they are binary, text, or xml, when the Execute response style chosen by the client is \"document\":

                                                                      • Binary types need to be base64 encoded for XML embedding
                                                                      • Text types need to be included inside a CDATA section
                                                                      • XML types can be integrated in the response as-is

                                                                      In order to understand the nature of the output format a new optional configuration element, <type>, can be added to the ogr2ogr.xml configuration file in order to specify the output nature. The possible values are binary, text, xml, in case the value is missing, binary is assumed. Here is an example showing all possible combinations:

                                                                      <OgrConfiguration>\n    <ogr2ogrLocation>ogr2ogr</ogr2ogrLocation>\n    <!-- <gdalData>...</gdalData> -->\n    <formats>\n        <Format>\n            <ogrFormat>MapInfo File</ogrFormat>\n            <formatName>OGR-TAB</formatName>\n            <fileExtension>.tab</fileExtension>\n            <type>binary</type> <!-- not really required, it\u2019s the default -->\n        </Format>\n        <Format>\n            <ogrFormat>MapInfo File</ogrFormat>\n            <formatName>OGR-MIF</formatName>\n            <fileExtension>.mif</fileExtension>\n            <option>-dsco</option>\n            <option>FORMAT=MIF</option>\n        </Format>\n        <Format>\n            <ogrFormat>CSV</ogrFormat>\n            <formatName>OGR-CSV</formatName>\n            <fileExtension>.csv</fileExtension>\n            <singleFile>true</singleFile>\n            <mimeType>text/csv</mimeType>\n            <option>-lco</option>\n            <option>GEOMETRY=AS_WKT</option>\n            <type>text</type>\n        </Format>\n        <Format>\n            <ogrFormat>KML</ogrFormat>\n            <formatName>OGR-KML</formatName>\n            <fileExtension>.kml</fileExtension>\n            <singleFile>true</singleFile>\n            <mimeType>application/vnd.google-earth.kml</mimeType>\n            <type>xml</type>\n        </Format>\n    </formats>\n</OgrConfiguration>\n
                                                                      "},{"location":"extensions/authkey/","title":"Key authentication module","text":"

                                                                      The authkey module for GeoServer allows for a very simple authentication protocol designed for OGC clients that cannot handle any kind of security protocol, not even the HTTP basic authentication.

                                                                      For these clients the module allows a minimal form of authentication by appending a unique key in the URL that is used as the sole authentication token. Obviously this approach is open to security token sniffing and must always be associated with the use of HTTPS connections.

                                                                      A sample authenticated request looks like:

                                                                      http://localhost:8080/geoserver/topp/wms?service=WMS&version=1.3.0&request=GetCapabilities&authkey=ef18d7e7-963b-470f-9230-c7f9de166888\n

                                                                      Where authkey=ef18d7e7-963b-470f-9230-c7f9de166888 is associated to a specific user (more on this later). The capabilities document contains backlinks to the server itself, linking to the URLs that can be used to perform GetMap, GetFeatureInfo and so on. When the authkey parameter is provided the backlinks will contain the authentication key as well, allowing any compliant WMS client to access secured resources.

                                                                      "},{"location":"extensions/authkey/#limitations","title":"Limitations","text":"

                                                                      The authkey module is meant to be used with OGC services. It won't work properly against the administration GUI, nor RESTConfig.

                                                                      The authkey module replaces the default basic authentication provider, therefore when editing a user the Enabled checkbox does not affect the authkey provider and you cannot disable users this way.

                                                                      "},{"location":"extensions/authkey/#key-providers","title":"Key providers","text":"

                                                                      Key providers are responsible for mapping the authentication keys to a user. The authentication key itself is a UUID (Universally Unique IDentifier (UUID)). A key provider needs a user/group service and it is responsible for synchronizing the authentication keys with the users contained in this service.

                                                                      "},{"location":"extensions/authkey/#key-provider-using-user-properties","title":"Key provider using user properties","text":"

                                                                      This key provider uses a user property UUID to map the authentication key to the user. User properties are stored in the user/group service. Synchronizing is simple since the logic has to search for users not having the property UUID and add it. The property value is a generated UUID.

                                                                      UUID=b52d2068-0a9b-45d7-aacc-144d16322018

                                                                      If the user/group service is read only, the property has to be added from outside, no synchronizing is possible.

                                                                      "},{"location":"extensions/authkey/#key-provider-using-a-property-file","title":"Key provider using a property file","text":"

                                                                      This key provider uses a property file named authkeys.properties. The default user/group service is named default. The authkeys.properties for this service would be located at

                                                                      $GEOSERVER_DATA_DIR/security/usergroup/default/authkeys.propeties

                                                                      A sample file looks as follows:

                                                                      # Format is authkey=username\nb52d2068-0a9b-45d7-aacc-144d16322018=admin\n1825efd3-20e1-4c18-9648-62c97d3ee5cb=sf\nef18d7e7-963b-470f-9230-c7f9de166888=topp\n

                                                                      This key provider also works for read only user/group services. Synchronizing adds new users not having an entry in this file and removes entries for users deleted in the user/group service.

                                                                      "},{"location":"extensions/authkey/#key-provider-using-an-external-web-service","title":"Key provider using an external web service","text":"

                                                                      This key provider calls an external URL to map the authentication key to the user. This allows GeoServer to integrate into an existing security infrastructure, where a session token is shared among applications and managed through dedicated web services.

                                                                      The web service URL and some other parameters can be specified to configure the mapper in detail:

                                                                      Option Description Web Service URL, with key placeholder the complete URL of the key mapping webservice, with a special placeholder ({key}) that will be replaced by the current authentication key Web Service Response User Search Regular Expression a regular expression used to extract the username from the webservice response; the first matched group (the part included in parentheses) in the regular expression will be used as the username; the default (\\^\\s(.)\\s*\\$) takes all the response text, trimming spaces at both ends Connection Timeout timeout to connect to the webservice Read Timeout timeout to read data from the webservice

                                                                      The mapper will call the webservice using an HTTP GET request (webservice requiring POST are not supported yet), replacing the {key} placeholder in the configured URL with the actual authentication key.

                                                                      If a response is received, it is parsed using the configured regular expression to extract the username from it. New lines are automatically stripped from the response. Some examples of regular expression that can be used are:

                                                                      Regular Expression Usage ^\\s*(.*)\\s*$ all text trimming spaces at both ends ^.*?\"user\"\\s*:\\s*\"([^\"]+)\".*$ json response where the username is contained in a property named user ^.*?<username>(.*?)</username>.*$ xml response where the username is contained in a tag named username

                                                                      Synchronizing users with the user/group service means clearing the current Security context cache. The keys cached in memory will be removed and re-created at the next call.

                                                                      "},{"location":"extensions/authkey/#authkey-webservice-body-response-usergroup-service","title":"AuthKEY WebService Body Response UserGroup Service","text":"

                                                                      When using an external web service to get Auth details, it is possible to define a custom GeoServer UserGroup Service being able to fetch Authorities - aka user's Roles - from the HTTP Body Response.

                                                                      The rationale is mostly the same; that kind of GeoServer UserGroup Service will apply a rolesRegex - Roles Regular Expression - to the body response - which can be either XML, JSON or Plain Text/HTML - in order to fetch the list of available Authorities.

                                                                      In order to do this, it is possible to configure instances of AuthKEY WebService Body Response User Group Service.

                                                                      First thing to do is to:

                                                                      1. Login as an Administrator

                                                                      2. Move to Security > Users, Groups, Roles and select Add new from User Group Services

                                                                      3. Click on AuthKEY WebService Body Response

                                                                      4. Provide a Name and select anything you want from Passwords - those won't be used by this service, but they are still mandatory for GeoServer -

                                                                      5. Provide a suitable Roles Regex to apply to your Web Service Response

                                                                      ::: note ::: title Note :::

                                                                      This is the only real mandatory value to provide. The others are optional and will allow you to customize the User Group Service behavior (see below) :::

                                                                      Once the new GeoServer UserGroup Service has been configured, it can be easily linked to the Key Provider Web Service Mapper.

                                                                      1. From Authentication > Authentication Filters, select - or add new - AuthKEY using Web Service as key mapper

                                                                      2. Select the newly defined UserGroup Service and save

                                                                      Additional Options

                                                                      1. Optional static comma-separated list of available Groups from the Web Service response

                                                                        It is worth notice that this UserGroup Service will always translate fetched Roles in the form ROLE_<ROLENAME>

                                                                        As an instance, if the Roles Regular Expression will match something like:

                                                                        my_user_role1, another_custom_user_role, role_External_Role_X\n

                                                                        this will be converted into 3 different GeoServer User Roles named as:

                                                                        ROLE_MY_USER_ROLE1\nROLE_ANOTHER_CUSTOM_USER_ROLE\nROLE_EXTERNAL_ROLE_X\n

                                                                        Of course the role names are known only at runtime; nevertheless it is possible to statically specify associated GeoServer User Groups to be mapped later to other internal GeoServer User Roles.

                                                                        What does this mean? A GeoServer User Group can be defined on the GeoServer Catalog and can be mapped by the active Role Services to one or more specific GeoServer User Roles.

                                                                        This mainly depends on the GeoServer Role Service you use. By default, the internal GeoServer Role Service can map Roles and Groups through static configuration stored on the GeoServer Data Dir. This is possible by editing GeoServer User Group details from the Users, Groups, and Roles panel

                                                                        Now, this custom UserGroup Service maps dynamically GeoServer User Role to GeoServer User Group as follows:

                                                                        ROLE_MY_USER_ROLE1              <> GROUP_MY_USER_ROLE1\nROLE_ANOTHER_CUSTOM_USER_ROLE   <> GROUP_ANOTHER_CUSTOM_USER_ROLE\nROLE_EXTERNAL_ROLE_X            <> GROUP_EXTERNAL_ROLE_X\n

                                                                        In order to be able to assign any GeoServer User Group to other internal GeoServer User Roles, since those are known only at runtime, the UserGroup Service allows us to statically specify the GeoServer User Groups the Web Service can use; this possible by setting the Optional static comma-separated list of available Groups from the Web Service response option:

                                                                        Once this is correctly configured, it will be possible to edit and assign GeoServer User Roles to the Groups by using the standard way

                                                                      2. Role Service to use

                                                                      By default, if no Role Service specified, the UserGroup Service will use the GeoServer Active Role Service to resolve GeoServer User Roles from GeoServer User Groups - as specified above -

                                                                      It is possible to define a Custom Role Service to use instead, to resole GeoServer User Roles; this is possible simply by selecting the Role Service to use from the Role Service to use option

                                                                      "},{"location":"extensions/authkey/#configuration","title":"Configuration","text":"

                                                                      Configuration can be done using the administrator GUI. There is a new type of authentication filter named authkey offering the following options.

                                                                      1. URL parameter name. This the name of URL parameter used in client HTTP requests. Default is authkey.
                                                                      2. Key Provider. GeoServer offers the providers described above.
                                                                      3. User/group service to be used.

                                                                      Some of the key providers can require additional configuration parameter. These will appear under the Key Provider combo-box when one of those is selected.

                                                                      After configuring the filter it is necessary to put this filter on the authentication filter chain(s).

                                                                      Note

                                                                      The administrator GUI for this filter has button Synchronize. Clicking on this button saves the current configuration and triggers a synchronize. If users are added/removed from the backing user/group service, the synchronize logic should be triggered.

                                                                      "},{"location":"extensions/authkey/#enabling-mappers-auto-synchronization","title":"Enabling Mappers' Auto-Synchronization","text":"

                                                                      The following check is available for all provides.

                                                                      If enabled, the service will automatically invoke the corresponding mapper synchronize method; the one associated to the current AuthKey provider.

                                                                      By default the synchronization happens every 60 seconds. In the case an administrator needs to change the auto-sync frequency, he will need to:

                                                                      1. Edit the file applicationContext.xml within the gs-authkey jar file
                                                                      2. Edit the property autoSyncDelaySeconds of the authenticationKeyProvider bean
                                                                      3. Restart GeoServer
                                                                      "},{"location":"extensions/authkey/#provider-pluggability","title":"Provider pluggability","text":"

                                                                      With some Java programming it is possible to programmatically create and register a new key to user name mapper that works under a different logic. For example, you could have daily tokens, token generators and the like.

                                                                      In order to provide your custom mapper you have to implement the org.geoserver.security.AuthenticationKeyMapper interface and then register said bean in the Spring application context. Alternatively it is possible to subclass from org.geoserver.security.AbstractAuthenticationKeyMapper. A mapper (key provider) has to implement

                                                                      /**\n * \n * Maps a unique authentication key to a username. Since usernames are\n * unique within a {@link GeoServerUserGroupService} an individual mapper\n * is needed for each service offering this feature.\n * \n * @author Andrea Aime - GeoSolution\n */\npublic interface AuthenticationKeyMapper extends BeanNameAware {\n\n    /**\n     * Maps the key provided in the request to the {@link GeoServerUser} object\n     * of the corresponding user, or returns null\n     * if no corresponding user is found\n     * \n     * Returns <code>null</code> if the user is disabled\n     * \n     * @param key\n     * @return\n     */\n    GeoServerUser getUser(String key) throws IOException;\n\n    /**\n     * Assures that each user in the corresponding {@link GeoServerUserGroupService} has\n     * an authentication key.\n     * \n     * returns the number of added authentication keys\n     * \n     * @throws IOException\n     */\n    int synchronize() throws IOException;\n\n    /**\n     * Returns <code>true</code> it the mapper can deal with read only u \n     * user/group services\n     * \n     * @return \n     */\n    boolean supportsReadOnlyUserGroupService();\n\n    String getBeanName();\n\n    void setUserGroupServiceName(String serviceName);\n    String getUserGroupServiceName();\n\n    public GeoServerSecurityManager getSecurityManager();\n    public void setSecurityManager(GeoServerSecurityManager securityManager);\n\n }\n

                                                                      The mapper would have to be registered in the Spring application context in a applicationContext.xml file in the root of your jar. Example for an implementation named com.mycompany.security.SuperpowersMapper:

                                                                      <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<!DOCTYPE beans PUBLIC \"-//SPRING//DTD BEAN//EN\" \"http://www.springframework.org/dtd/spring-beans.dtd\">\n<beans>\n  <bean id=\"superpowersMapper\" class=\"com.mycompany.security.SuperpowersMapper\"/>\n</beans>\n

                                                                      At this point you can drop the authkey jar along with your custom mapper jar and use it in the administrator GUI of the authentication key filter.

                                                                      "},{"location":"extensions/cas/","title":"CAS integration","text":"

                                                                      The CAS module allows to integrate GeoServer with the Central Authentication Service (CAS) Single Sign On (SSO), in particular, using standard tickets and proxy tickets.

                                                                      "},{"location":"extensions/cas/#installation","title":"Installation","text":"

                                                                      To install the CAS module:

                                                                      1. Visit the website download page, locate your release, and download: cas

                                                                        The download link will be in the Extensions section under Security.

                                                                        Warning

                                                                        Ensure to match plugin (example 2.24.2 above) version to the version of the GeoServer instance.

                                                                      1. Extract the files in this archive to the WEB-INF/lib directory of your GeoServer installation.
                                                                      2. Restart GeoServer
                                                                      "},{"location":"extensions/cas/#configuration","title":"Configuration","text":"

                                                                      The CAS integration is a authentication filter module, hence in order to use it one has to:

                                                                      • Go to the authentication page, add the CAS filter and configure it
                                                                      • Add it to the authentication chains, taking care of removing the other authentication methods (or the CAS authentication won't trigger and redirect users to the CAS login page)

                                                                      This page serves as a reference for configuration options, but a step by step tutorial is also available, see Authentication with CAS.

                                                                      Key Description Name Name of the filter CAS server URL including context root The CAS server location (GeoServer will redirect to it, for example, in order to login, adding the necessary extra path elements) No single sign on If checkecd, will send the \"renew=true\" options to the CAS server, forcing the user to login on the server at each request (unless session creation is allowed) Participate in single sign out Whether GeoServer should receive and handle callbacks for Single Sign Out. URL in CAS loutput page CAS logout page location Proxy callback URL The URL CAS will call back to after proxy ticket authentication Role source A choice of role sources for the user authenticated via CAS

                                                                      Specifically for the role source, the following options are available:

                                                                      Source Description User group service Locate the user in a the specified user group service, extract the roles from it. Role service Locate user roles from the specified role service Header attribute Look up the roles in the specified HTTP header of the CAS response Custom CAS attribute Extract the roles from a CAS custom attribute in the <cas:serviceResponse> received from the server. The attributes must be configured, on the CAS side, via an attribute repository, and then released for publication in service configuration."},{"location":"extensions/cas/#example-cas-configuration","title":"Example CAS configuration","text":"

                                                                      In order to use the CAS custom attributes the server must be configured to extract the attributes from a given attribute repository, and then allow their release in the GeoServer service configuration.

                                                                      For example, the following cas.properties file sets up a JDBC user source, as well as JDBC attribute repository (this configuration file might useful for testing purposes, but not setup for production):

                                                                      cas.server.name=https://localhost:8443\ncas.server.prefix=${cas.server.name}/cas\nserver.ssl.key-store=file:/etc/cas/config/thekeystore\nserver.ssl.key-store-password=changeit\nlogging.config=file:/etc/cas/config/log4j2.xml\n# cas.authn.accept.users=\n\ncas.authn.jdbc.query[0].driver-class=org.postgresql.Driver\ncas.authn.jdbc.query[0].url=jdbc:postgresql://localhost:5432/cas_users\ncas.authn.jdbc.query[0].dialect=org.hibernate.dialect.PostgreSQL95Dialect\ncas.authn.jdbc.query[0].driver-class=org.postgresql.Driver\ncas.authn.jdbc.query[0].user=theDbUser\ncas.authn.jdbc.query[0].password=theDbPassword\ncas.authn.jdbc.query[0].sql=SELECT * FROM users WHERE email = ?\ncas.authn.jdbc.query[0].password-encoder.type=BCRYPT\ncas.authn.jdbc.query[0].field-password=password\ncas.authn.jdbc.query[0].field-expired=expired\ncas.authn.jdbc.query[0].field-disabled=disabled\n\n\ncas.authn.attributeRepository.jdbc[0].driver-class=org.postgresql.Driver\ncas.authn.attributeRepository.jdbc[0].url=jdbc:postgresql://localhost:5432/cas_users\ncas.authn.attributeRepository.jdbc[0].dialect=org.hibernate.dialect.PostgreSQL95Dialect\ncas.authn.attributeRepository.jdbc[0].driver-class=org.postgresql.Driver\ncas.authn.attributeRepository.jdbc[0].user=theDbUser\ncas.authn.attributeRepository.jdbc[0].password=theDbPassword\ncas.authn.attributeRepository.jdbc[0].attributes.role=role\ncas.authn.attributeRepository.jdbc[0].singleRow=false\ncas.authn.attributeRepository.jdbc[0].columnMappings.attribute=value\ncas.authn.attributeRepository.jdbc[0].sql=SELECT * FROM roles WHERE {0}\ncas.authn.attributeRepository.jdbc[0].username=email\n\ncas.service-registry.json.location=classpath:/services\n

                                                                      The database has the following two tables for users and roles:

                                                                      CREATE TABLE public.users (\n    id bigint NOT NULL,\n    disabled boolean,\n    email character varying(40),\n    first_name character varying(40),\n    last_name character varying(40),\n    expired boolean,\n    password character varying(100)\n);\n\nCREATE TABLE public.roles (\n    email character varying,\n    attribute character varying,\n    value character varying\n);\n

                                                                      A sample service configuration for GeoServer might look as follows (again, setup for testing and development only):

                                                                      {\n  \"@class\" : \"org.apereo.cas.services.RegexRegisteredService\",\n  \"serviceId\" : \"^http(s)?://localhost:[\\\\d]+/geoserver/.*\",\n  \"name\" : \"GeoServer\",\n  \"id\" : 1002,\n  \"logoutType\" : \"BACK_CHANNEL\",\n  \"logoutUrl\" : \"https://localhost:8442/geoserver\",\n  \"redirectUrl\" : \"https://localhost:8442/geoserver\",\n  \"proxyPolicy\" : {\n    \"@class\" : \"org.apereo.cas.services.RegexMatchingRegisteredServiceProxyPolicy\",\n    \"pattern\" : \"^http(s)?://localhost:[\\\\d]+/geoserver/.*\"\n  },\n  \"attributeReleasePolicy\" : {\n    \"@class\" : \"org.apereo.cas.services.ReturnAllAttributeReleasePolicy\"\n  }\n}\n
                                                                      "},{"location":"extensions/cas/#configuring-the-web-chain","title":"Configuring the web chain","text":"

                                                                      The CAS authentication can be included in the web filter chain, with different behavior depending on which filters are included. The following discusses three possible examples.

                                                                      As first case, let's consider having only the CAS authentication in the \"web\" filter chain:

                                                                      Since anonymous access is not allowed, any attempt to access the GeoServer web console will cause a redirect to the CAS server, for login. Once logged in, the user interface shows a button to initiate a CAS logout (the logout is shared among all examples, won't be repeated in the following text).

                                                                      A second option is to allow anonymous access in the web chain, allowing users to access the layer preview and other demo functionality without logging in:

                                                                      In this case the web console does not immediately redirect to the CAS server, but provides a CAS login button instead:

                                                                      As a final example, let's consider having both CAS and form login in the web chain:

                                                                      This allows both a CAS login, and a form based login using GeoServer local username/password. It could be useful to allow GeoServer administration while the CAS server is offline for any reason. In this case both the form login and the CAS login button appear at the same time:

                                                                      "},{"location":"extensions/controlflow/","title":"Control flow module","text":"

                                                                      The control-flow module for GeoServer allows the administrator to control the amount of concurrent requests actually executing inside the server, as well as giving an opportunity to slow down users making too many requests. This kind of control is useful for a number of reasons:

                                                                      • Performance: tests show that, with local data sources, the maximum throughput in GetMap requests is achieved when allowing at most 2 times the number of CPU cores requests to run in parallel.
                                                                      • Resource control: requests such as GetMap can use a significant amount of memory. The WMS request limits<wms_configuration_limits> allow to control the amount of memory used per request, but an OutOfMemoryError is still possible if too many requests run in parallel. By controlling also the amount of requests executing it's possible to limit the total amount of memory used below the memory that was actually given to the Java Virtual Machine.
                                                                      • Fairness: a single user should not be able to overwhelm the server with a lot of requests, leaving other users with tiny slices of the overall processing power.

                                                                      The control flow method does not normally reject requests, it just queues up those in excess and executes them late. However, it's possible to configure the module to reject requests that have been waited in queue for too long.

                                                                      "},{"location":"extensions/controlflow/#installation","title":"Installation","text":"
                                                                      1. Visit the website download page, locate your release, and download: control-flow

                                                                        Warning

                                                                        Ensure to match plugin (example 2.24.2 above) version to the version of the GeoServer instance.

                                                                      1. Extract the files in this archive to the WEB-INF/lib directory of your GeoServer installation.
                                                                      2. Restart GeoServer
                                                                      "},{"location":"extensions/controlflow/#rule-syntax-reference","title":"Rule syntax reference","text":"

                                                                      The current implementation of the control flow module reads its rules from a controlflow.properties property file located in the GeoServer data directory.

                                                                      "},{"location":"extensions/controlflow/#total-ows-request-count","title":"Total OWS request count","text":"

                                                                      The global number of OWS requests executing in parallel can be specified with:

                                                                      ows.global=<count>\n

                                                                      Every request in excess will be queued and executed when other requests complete leaving some free execution slot.

                                                                      "},{"location":"extensions/controlflow/#per-request-control","title":"Per request control","text":"

                                                                      A per request type control can be demanded using the following syntax:

                                                                      ows.<service>[.<request>[.<outputFormat>]]=<count>\n

                                                                      Where:

                                                                      • <service> is the OWS service in question (at the time of writing can be wms, wfs, wcs)
                                                                      • <request>, optional, is the request type. For example, for the wms service it can be GetMap, GetFeatureInfo, DescribeLayer, GetLegendGraphics, GetCapabilities
                                                                      • <outputFormat>, optional, is the output format of the request. For example, for the wms GetMap request it could be image/png, image/gif and so on

                                                                      A few examples:

                                                                      # don't allow more than 16 WCS requests in parallel\nows.wcs=16\n# don't allow more than 8 GetMap requests in parallel\nows.wms.getmap=8\n# don't allow more than 2 WFS GetFeature requests with Excel output format\nows.wfs.getfeature.application/msexcel=2\n
                                                                      "},{"location":"extensions/controlflow/#request-priority-support","title":"Request priority support","text":"

                                                                      Requests controlled by \"ows.*\" controllers above can be also executed in priority order, in case there are too many the request will block and wait, and will we awoken in priority order (highest to lowest).

                                                                      Currently the only way to specific a priority for a request is to add it to a request HTTP header:

                                                                      ows.priority.http=<headerName>,<defaultPriority>\n

                                                                      The header \"headerName\" will contain a number defining the priority for the request, the default priority is used as a fallback if/when the header is not found.

                                                                      Using a header implies some other system is involved in the priority management. This is particularly good when using a load balancer, as the requests priorities need to be evenly split across cluster elements, control-flow only has visibility of a single instance. As an example, the priority will be de facto ignored at the cluster level if there are two nodes, and for whatever chance or design, the high priority requests end up converging on the same cluster node.

                                                                      "},{"location":"extensions/controlflow/#per-user-concurrency-control","title":"Per user concurrency control","text":"

                                                                      There are two mechanisms to identify user requests. The first one is cookie based, so it will work fine for browsers but not as much for other kinds of clients. The second one is ip based, which works for any type of client but that can limit all the users sitting behind the same router

                                                                      This avoids a single user (as identified by a cookie) to make too many requests in parallel:

                                                                      user=<count>\n

                                                                      Where <count> is the maximum number of requests a single user can execute in parallel.

                                                                      The following avoids a single ip address from making too many requests in parallel:

                                                                      ip=<count>\n

                                                                      Where <count> is the maximum number of requests a single ip address can execute in parallel.

                                                                      It is also possible to make this a bit more specific and throttle a single ip address instead by using the following:

                                                                      ip.<ip_addr>=<count>\n

                                                                      Where <count> is the maximum number of requests the ip specified in <ip_addr> will execute in parallel.

                                                                      To reject requests from a list of ip addresses:

                                                                      ip.blacklist=<ip_addr1>,<ip_addr2>,...\n
                                                                      "},{"location":"extensions/controlflow/#per-user-rate-control","title":"Per user rate control","text":"

                                                                      The rate control rules allow to setup the maximum number of requests per unit of time, based either on a cookie or IP address. These rules look as follows (see \"Per user concurrency control\" for the meaning of \"user\" and \"ip\"):

                                                                      user.ows[.<service>[.<request>[.<outputFormat>]]]=<requests>/<unit>[;<delay>s]\nip.ows[.<service>[.<request>[.<outputFormat>]]]=<requests>/<unit>[;<delay>s]\n

                                                                      Where:

                                                                      • <service> is the OWS service in question (at the time of writing can be wms, wfs, wcs)
                                                                      • <request>, optional, is the request type. For example, for the wms service it can be GetMap, GetFeatureInfo, DescribeLayer, GetLegendGraphics, GetCapabilities
                                                                      • <outputFormat>, optional, is the output format of the request. For example, for the wms GetMap request it could be image/png, image/gif and so on
                                                                      • <requests> is the number of requests in the unit of time
                                                                      • <unit> is the unit of time, can be \"s\", \"m\", \"h\", \"d\" (second, minute, hour and day respectively).
                                                                      • <delay> is an optional the delay applied to the requests that exceed the maximum number of requests in the current time slot. If not specified, once the limit is exceeded a immediate failure response with HTTP code 429 (\"Too many requests\") will be sent back to the caller.

                                                                      The following rule will allow 1000 WPS Execute requests a day, and delay each one in excess by 30 seconds:

                                                                      user.ows.wps.execute=1000/d;30s\n

                                                                      The following rule will instead allow up to 30 GetMap requests a second, but will immediately fail any request exceeding the cap:

                                                                      user.ows.wms.getmap=30/s\n

                                                                      In both cases headers informing the user of the request rate control will be added to the HTTP response. For example:

                                                                      X-Rate-Limit-Context: Any OGC request\nX-Rate-Limit-Limit: 10\nX-Rate-Limit-Remaining: 9\nX-Rate-Limit-Reset: 1103919616\nX-Rate-Limit-Action: Delay excess requests 1000ms\n

                                                                      In case several rate control rules apply to a single request, a batch of headers will be added to the response for each of them, it is thus advised to avoid adding too many of these rules in parallel

                                                                      Where:

                                                                      • X-Rate-Limit-Context is the type of request being subject to control
                                                                      • X-Rate-Limit-Limit is the total amount of requests allowed in the control interval
                                                                      • X-Rate-Limit-Remaining is the number of remaining requests allowed before the rate control kicks in
                                                                      • X-Rate-Limit-Reset is the Unix epoch at which the new control interval will begin
                                                                      • X-Rate-Limit-Action specifies what action is taken on requests exceeding the rate control
                                                                      "},{"location":"extensions/controlflow/#timeout","title":"Timeout","text":"

                                                                      A request timeout is specified with the following syntax:

                                                                      timeout=<seconds>\n

                                                                      where <seconds> is the number of seconds a request can stay queued waiting for execution. If the request does not enter execution before the timeout expires it will be rejected.

                                                                      "},{"location":"extensions/controlflow/#throttling-tile-requests-wms-c-tms-wmts","title":"Throttling tile requests (WMS-C, TMS, WMTS)","text":"

                                                                      GeoWebCache contributes three cached tiles services to GeoServer: WMS-C, TMS, and WMTS. It is also possible to use the Control flow module to throttle them, by adding the following rule to the configuration file:

                                                                      ows.gwc=<count>\n

                                                                      Where <count> is the maximum number of concurrent tile requests that will be delivered by GeoWebCache at any given time.

                                                                      Note also that tile request are sensitive to the other rules (user based, ip based, timeout, etc).

                                                                      "},{"location":"extensions/controlflow/#a-complete-example","title":"A complete example","text":"

                                                                      Assuming the server we want to protect has 4 cores a sample configuration could be:

                                                                      # if a request waits in queue for more than 60 seconds it's not worth\n# executing, the client will  likely have given up by then\ntimeout=60\n\n# don't allow the execution of more than 100 requests total in parallel\nows.global=100\n\n# don't allow more than 10 GetMap in parallel\nows.wms.getmap=10\n\n# don't allow more than 4 outputs with Excel output as it's memory bound\nows.wfs.getfeature.application/msexcel=4\n\n# don't allow a single user to perform more than 6 requests in parallel\n# (6 being the Firefox default concurrency level at the time of writing)\nuser=6\n\n# don't allow the execution of more than 16 tile requests in parallel\n# (assuming a server with 4 cores, GWC empirical tests show that throughput\n# peaks up at 4 x number of cores. Adjust as appropriate to your system)\nows.gwc=16\n
                                                                      "},{"location":"extensions/csw-iso/","title":"Catalog Services for the Web (CSW) - ISO Metadata Profile","text":"

                                                                      This section discusses the Catalog Services for Web (CSW) ISO Metadata Profile extension. With this community module on top of the general Catalog Services for the Web (CSW) extension, GeoServer supports the ISO Metadata Profile as an additional scheme for the CSW service.

                                                                      • Installing Catalog Services for Web (CSW) - ISO Metadata Profile
                                                                      • CSW ISO Metadata Profile Mapping File
                                                                      • Catalog Services for the Web (CSW) ISO Metadata tutorial
                                                                      "},{"location":"extensions/csw-iso/installing/","title":"Installing Catalog Services for Web (CSW) - ISO Metadata Profile","text":"

                                                                      To install the CSW ISO extension:

                                                                      1. Visit the GeoServer download page and navigate to the download page for the version of GeoServer your are using. If you do not have the CSW extension yet, get it first. Both the csw and csw-iso downloads are listed under extensions. The file needed are geoserver-*-csw-plugin.zip (if necessary) and geoserver-*-SNAPSHOT-csw-iso-plugin.zip, where * matches the version number of GeoServer you are using.
                                                                      2. Extract these zip files and place all the JARs in WEB-INF/lib.
                                                                      3. Perform any configuration required by your servlet container, and then restart.
                                                                      4. Verify that the CSW module was installed correctly by going to the Welcome page of the Web administration interface and seeing that CSW is listed in the Service Capabilities list. Open the CSW capabilities and search for the text gmd:MD_Metadata to verify that the ISO metadata profile was installed correctly.
                                                                      "},{"location":"extensions/csw-iso/mapping/","title":"CSW ISO Metadata Profile Mapping File","text":""},{"location":"extensions/csw-iso/mapping/#general","title":"General","text":"

                                                                      See Mapping Files for basic information on the CSW mapping file. The ISO Metadata mapping can be found in the file csw/MD_Metadata.properties inside the data directory.

                                                                      Below is an example of an ISO Metadata Profile Mapping File:

                                                                      @fileIdentifier.CharacterString=id\nidentificationInfo.MD_DataIdentification.citation.CI_Citation.title.CharacterString=title\nidentificationInfo.MD_DataIdentification.citation.CI_Citation.alternateTitle.CharacterString=list(description,alias,strConcat('##',title)) \nidentificationInfo.MD_DataIdentification.descriptiveKeywords.MD_Keywords.keyword.CharacterString=keywords \nidentificationInfo.MD_DataIdentification.abstract.CharacterString=abstract\n$dateStamp.Date= if_then_else ( isNull(\"metadata.date\") , 'Unknown', \"metadata.date\")\nhierarchyLevel.MD_ScopeCode.@codeListValue='http://purl.org/dc/dcmitype/Dataset'\n$contact.CI_ResponsibleParty.individualName.CharacterString=\nidentificationInfo.MD_DataIdentification.resourceConstraints[0].MD_LegalConstraints.accessConstraints.MD_RestrictionCode=\nidentificationInfo.MD_DataIdentification.resourceConstraints[1].MD_SecurityConstraints.classification.MD_ClassificationCode=\nidentificationInfo.MD_DataIdentification.citation.CI_Citation.date%.CI_Date.date.Date=lapply(\"metadata.citation-date\", if_then_else(isNull(\".\"), \"Expression/NIL\", dateFormat('YYYY-MM-dd', \".\")))\nidentificationInfo.MD_DataIdentification.descriptiveKeywords.MD_Keywords.keyword.CharacterString=list(keywords, if_then_else(equalTo(typeOf(\".\"), 'FeatureTypeInfo'), 'vector', 'raster'))\n

                                                                      The full path of each field must be specified (separated with dots). XML attributes are specified with the @ symbol, similar to the usual XML X-path notation. To avoid confusion with the identifier-symbol at the beginning of a mapping line, use @ (for an attribute that is not an identifier) or @@ (for an attribute that is also the identifier) - see the feature catatalog mapping file for an example.

                                                                      The % symbol denotes where a multi-valued mapping should be split in to multiple tags. Multiple % symbols may be used for multi-dimensional mappings - see the feature catatalog mapping file below for an example.

                                                                      Indexes with square brackets can be used to avoid merging tags that shouldn't be merged, as demonstrated above for resourceConstraints.

                                                                      To keep the result XSD compliant, the parameters dateStamp.Date and contact.CI_ResponsibleParty.individualName.CharacterString must be preceded by a $ sign to make sure that they are always included even when using property selection.

                                                                      The lapply function can be used to apply expressions to items of lists, which can be handy with multidimensional fields.

                                                                      The typeOf function (exclusive to CSW-ISO module) returns the type of the catalog item that is being processed (LayerGroupInfo, FeatureTypeInfo, CoverageInfo,...), which can be handy if you for example need to handle vector layers differently to raster layers.

                                                                      For more information on the ISO Metadata standard, please see the OGC Implementation Specification 07-045.

                                                                      "},{"location":"extensions/csw-iso/mapping/#feature-catalogs","title":"Feature Catalogs","text":"Within the ISO Metadata Profile, there is also support for Feature Catalogues that contain information about vector layer type metadata. As specified by the ISO Metadata standard these are exposed in separate records. For this purpose we have a separate mapping file::

                                                                      @@uuid=\"metadata.custom.feature-catalog/feature-catalog-uidentifier\" @id=\"metadata.custom.feature-catalog/feature-catalog-identifier\" \\$featureType.FC_FeatureType.typeName.LocalName=concatenate(\"name\", 'Type') \\$featureType.FC_FeatureType.isAbstract.Boolean='false' \\$featureType.FC_FeatureType.featureCatalogue.@uuidref=\"metadata.custom.feature-catalog/feature-catalog-identifier\" featureType.FC_FeatureType.definition.CharacterString=\"metadata.custom.feature-catalog/feature-type/feature-type-definition\" featureType.FC_FeatureType.carrierOfCharacteristics%.FC_FeatureAttribute.memberName.LocalName=\"metadata.custom.feature-catalog/feature-type/feature-attribute/name\" featureType.FC_FeatureType.carrierOfCharacteristics%.FC_FeatureAttribute.valueType.TypeName.aName.CharacterString=\"metadata.custom.feature-catalog/feature-type/feature-attribute/type\" featureType.FC_FeatureType.carrierOfCharacteristics%.FC_FeatureAttribute.length.CharacterString=\"metadata.custom.feature-catalog/feature-type/feature-attribute/length\" featureType.FC_FeatureType.carrierOfCharacteristics%.FC_FeatureAttribute.definition.CharacterString=\"metadata.custom.feature-catalog/feature-type/feature-attribute/definition\" featureType.FC_FeatureType.carrierOfCharacteristics%.FC_FeatureAttribute.cardinality.Multiplicity.range.MultiplicityRange.lower.Integer=\"metadata.custom.feature-catalog/feature-type/feature-attribute/min-occurrence\" featureType.FC_FeatureType.carrierOfCharacteristics%.FC_FeatureAttribute.cardinality.Multiplicity.range.MultiplicityRange.upper.UnlimitedInteger=\"metadata.custom.feature-catalog/feature-type/feature-attribute/max-occurrence\" featureType.FC_FeatureType.carrierOfCharacteristics%.FC_FeatureAttribute.cardinality.Multiplicity.range.MultiplicityRange.upper.UnlimitedInteger.@isInfinite=false featureType.FC_FeatureType.carrierOfCharacteristics%.FC_FeatureAttribute.listedValue%.FC_ListedValue.label.CharacterString=\"metadata.custom.feature-catalog/feature-type/feature-attribute/domain/value\" featureType.FC_FeatureType.carrierOfCharacteristics%.FC_FeatureAttribute.listedValue%.FC_ListedValue.definition.CharacterString=\"metadata.custom.feature-catalog/feature-type/feature-attribute/domain/definition\" featureType.FC_FeatureType.carrierOfCharacteristics%.FC_FeatureAttribute.listedValue%.FC_ListedValue.code.CharacterString=\"metadata.custom.feature-catalog/feature-type/feature-attribute/domain/code\"

                                                                      Only records that have a non-null identifier in the catalog mapping file will have a feature catalogue record. There is no support in the standard Geoserver GUI for user configuration of this information. The upcoming metadata community module makes this possible.

                                                                      "},{"location":"extensions/csw-iso/tutorial/","title":"Catalog Services for the Web (CSW) ISO Metadata tutorial","text":"

                                                                      This tutorial will show how to use the CSW module with the ISO Metadata Profile scheme. It assumes a fresh installation of GeoServer with the CSW ISO Metadata Profile module installed.

                                                                      "},{"location":"extensions/csw-iso/tutorial/#configuration","title":"Configuration","text":"

                                                                      In the <data_dir>/csw directory, create a new file named MD_Metadata.properties (ISO Metadata Profile mapping file) with the following contents:

                                                                      @fileIdentifier.CharacterString=prefixedName\nidentificationInfo.AbstractMD_Identification.citation.CI_Citation.title.CharacterString=title\nidentificationInfo.AbstractMD_Identification.descriptiveKeywords.MD_Keywords.keyword.CharacterString=keywords \nidentificationInfo.AbstractMD_Identification.abstract.CharacterString=abstract\n$dateStamp.Date= if_then_else ( isNull(\"metadata.date\") , 'Unknown', \"metadata.date\")\nhierarchyLevel.MD_ScopeCode.@codeListValue='http://purl.org/dc/dcmitype/Dataset'\n$contact.CI_ResponsibleParty.individualName.CharacterString='John Smith'\n
                                                                      "},{"location":"extensions/csw-iso/tutorial/#services","title":"Services","text":"

                                                                      With GeoServer running (and responding on http://localhost:8080), test GeoServer CSW in a web browser by querying the CSW capabilities as follows:

                                                                      http://localhost:8080/geoserver/csw?service=csw&version=2.0.2&request=GetCapabilities\n

                                                                      We can request a description of our Metadata record:

                                                                      http://localhost:8080/geoserver/csw?service=CSW&version=2.0.2&request=DescribeRecord&typeName=gmd:MD_Metadata\n

                                                                      This yields the following result:

                                                                      <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<csw:DescribeRecordResponse xmlns:csw=\"http://www.opengis.net/cat/csw/2.0.2\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xsi:schemaLocation=\"http://www.opengis.net/cat/csw/2.0.2 http://localhost:8080/geoserver/schemas/csw/2.0.2CSW-discovery.xsd\">\n<csw:SchemaComponent targetNamespace=\"http://www.opengis.net/cat/csw/2.0.2\" schemaLanguage=\"http://www.w3.org/XML/Schema\">\n<xs:schema xmlns:xs=\"http://www.w3.org/2001/XMLSchema\" xmlns:xlink=\"http://www.w3.org/1999/xlink\" xmlns:gco=\"http://www.isotc211.org/2005/gco\" xmlns:gmd=\"http://www.isotc211.org/2005/gmd\" targetNamespace=\"http://www.isotc211.org/2005/gmd\" elementFormDefault=\"qualified\" version=\"2012-07-13\">\n  <!-- ================================= Annotation ================================ -->\n  <xs:annotation>\n      <xs:documentation>Geographic MetaData (GMD) extensible markup language is a component of the XML Schema Implementation of Geographic Information Metadata documented in ISO/TS 19139:2007. GMD includes all the definitions of http://www.isotc211.org/2005/gmd namespace. The root document of this namespace is the file gmd.xsd. This identification.xsd schema implements the UML conceptual schema defined in A.2.2 of ISO 19115:2003. It contains the implementation of the following classes: MD_Identification, MD_BrowseGraphic, MD_DataIdentification, MD_ServiceIdentification, MD_RepresentativeFraction, MD_Usage, MD_Keywords, DS_Association, MD_AggregateInformation, MD_CharacterSetCode, MD_SpatialRepresentationTypeCode, MD_TopicCategoryCode, MD_ProgressCode, MD_KeywordTypeCode, DS_AssociationTypeCode, DS_InitiativeTypeCode, MD_ResolutionType.</xs:documentation>\n  </xs:annotation>\n  ...\n

                                                                      Query all layers as follows:

                                                                      http://localhost:8080/geoserver/csw?service=CSW&version=2.0.2&request=GetRecords&typeNames=gmd:MD_Metadata&resultType=results&elementSetName=full&outputSchema=http://www.isotc211.org/2005/gmd\n

                                                                      Request a particular layer by ID...:

                                                                      http://localhost:8080/geoserver/csw?service=CSW&version=2.0.2&request=GetRecordById&elementsetname=summary&id=CoverageInfoImpl--4a9eec43:132d48aac79:-8000&typeNames=gmd:MD_Metadata&resultType=results&elementSetName=full&outputSchema=http://www.isotc211.org/2005/gmd\n

                                                                      ...or use a filter to retrieve it by Title:

                                                                      http://localhost:8080/geoserver/csw?service=CSW&version=2.0.2&request=GetRecords&typeNames=gmd:MD_Metadata&resultType=results&elementSetName=full&outputSchema=http://www.isotc211.org/2005/gmd&constraint=Title=%27mosaic%27\n

                                                                      Either case should return:

                                                                      <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<csw:GetRecordsResponse xmlns:xml=\"http://www.w3.org/XML/1998/namespace\" xmlns=\"http://www.opengis.net/cat/csw/apiso/1.0\" xmlns:csw=\"http://www.opengis.net/cat/csw/2.0.2\" xmlns:gco=\"http://www.isotc211.org/2005/gco\" xmlns:gmd=\"http://www.isotc211.org/2005/gmd\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" version=\"2.0.2\" xsi:schemaLocation=\"http://www.opengis.net/cat/csw/2.0.2 http://localhost:8080/geoserver/schemas/csw/2.0.2/record.xsd\">\n  <csw:SearchStatus timestamp=\"2013-06-28T13:41:43.090Z\"/>\n  <csw:SearchResults numberOfRecordsMatched=\"1\" numberOfRecordsReturned=\"1\" nextRecord=\"0\" recordSchema=\"http://www.isotc211.org/2005/gmd\" elementSet=\"full\">\n<gmd:MD_Metadata>\n  <gmd:fileIdentifier>\n    <gco:CharacterString>CoverageInfoImpl--4a9eec43:132d48aac79:-8000</gco:CharacterString>\n  </gmd:fileIdentifier>\n  <gmd:dateStamp>\n    <gco:Date>Unknown</gco:Date>\n  </gmd:dateStamp>\n  <gmd:identificationInfo>\n    <gmd:MD_DataIdentification>\n      <gmd:extent>\n    <gmd:EX_Extent>\n      <gmd:geographicElement>\n        <gmd:EX_GeographicBoundingBox crs=\"urn:x-ogc:def:crs:EPSG:6.11:4326\">\n          <gmd:westBoundLongitude>36.492</gmd:westBoundLongitude>\n          <gmd:southBoundLatitude>6.346</gmd:southBoundLatitude>\n          <gmd:eastBoundLongitude>46.591</gmd:eastBoundLongitude>\n          <gmd:northBoundLatitude>20.83</gmd:northBoundLatitude>\n        </gmd:EX_GeographicBoundingBox>\n      </gmd:geographicElement>\n    </gmd:EX_Extent>\n      </gmd:extent>\n    </gmd:MD_DataIdentification>\n    <gmd:AbstractMD_Identification>\n      <gmd:citation>\n    <gmd:CI_Citation>\n      <gmd:title>\n        <gco:CharacterString>mosaic</gco:CharacterString>\n      </gmd:title>\n    </gmd:CI_Citation>\n      </gmd:citation>\n      <gmd:descriptiveKeywords>\n    <gmd:MD_Keywords>\n      <gmd:keyword>\n        <gco:CharacterString>WCS</gco:CharacterString>\n      </gmd:keyword>\n      <gmd:keyword>\n        <gco:CharacterString>ImageMosaic</gco:CharacterString>\n      </gmd:keyword>\n      <gmd:keyword>\n        <gco:CharacterString>mosaic</gco:CharacterString>\n      </gmd:keyword>\n    </gmd:MD_Keywords>\n      </gmd:descriptiveKeywords>\n    </gmd:AbstractMD_Identification>\n  </gmd:identificationInfo>\n  <gmd:contact>\n    <gmd:CI_ResponsibleParty>\n      <gmd:individualName>\n    <gco:CharacterString>John Smith</gco:CharacterString>\n      </gmd:individualName>\n    </gmd:CI_ResponsibleParty>\n  </gmd:contact>\n  <gmd:hierarchyLevel>\n    <gmd:MD_ScopeCode codeListValue=\"http://purl.org/dc/dcmitype/Dataset\"/>\n  </gmd:hierarchyLevel>\n</gmd:MD_Metadata>\n  </csw:SearchResults>\n</csw:GetRecordsResponse>\n

                                                                      We can request the domain of a property. For example, all values of \"Title\":

                                                                      http://localhost:8080/geoserver/csw?service=csw&version=2.0.2&request=GetDomain&propertyName=Title\n

                                                                      This should yield the following result:

                                                                      <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<csw:GetDomainResponse xmlns:csw=\"http://www.opengis.net/cat/csw/2.0.2\" xmlns:dc=\"http://purl.org/dc/elements/1.1/\" xmlns:dct=\"http://purl.org/dc/terms/\" xmlns:ows=\"http://www.opengis.net/ows/1.1\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xsi:schemaLocation=\"http://www.opengis.net/cat/csw/2.0.2 http://localhost:8080/geoserver/schemas/csw/2.0.2/CSW-discovery.xsd\">\n  <csw:DomainValues type=\"csw:Record\">\n  <csw:PropertyName>Title</csw:PropertyName>\n  <csw:ListOfValues>\n    <csw:Value>A sample ArcGrid file</csw:Value>\n    <csw:Value>Manhattan (NY) landmarks</csw:Value>\n    <csw:Value>Manhattan (NY) points of interest</csw:Value>\n    <csw:Value>Manhattan (NY) roads</csw:Value>\n    <csw:Value>North America sample imagery</csw:Value>\n    <csw:Value>Pk50095 is a A raster file accompanied by a spatial data file</csw:Value>\n    <csw:Value>Spearfish archeological sites</csw:Value>\n    <csw:Value>Spearfish bug locations</csw:Value>\n    <csw:Value>Spearfish restricted areas</csw:Value>\n    <csw:Value>Spearfish roads</csw:Value>\n    <csw:Value>Spearfish streams</csw:Value>\n    <csw:Value>Tasmania cities</csw:Value>\n    <csw:Value>Tasmania roads</csw:Value>\n    <csw:Value>Tasmania state boundaries</csw:Value>\n    <csw:Value>Tasmania water bodies</csw:Value>\n    <csw:Value>USA Population</csw:Value>\n    <csw:Value>World rectangle</csw:Value>\n    <csw:Value>mosaic</csw:Value>\n    <csw:Value>sfdem is a Tagged Image File Format with Geographic information</csw:Value>\n  </csw:ListOfValues>\n  </csw:DomainValues>\n</csw:GetDomainResponse>\n

                                                                      To request more than the first 10 records or for more complex queries you can use a HTTP POST request with an XML query as the request body. For example, using the maxRecords option in the following request it is possible to return the first 50 layers with \"ImageMosaic\" in a keyword:

                                                                      http://localhost:8080/geoserver/csw\n

                                                                      Postbody:

                                                                      <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<GetRecords service=\"CSW\" version=\"2.0.2\" maxRecords=\"50\" startPosition=\"1\" resultType=\"results\" outputFormat=\"application/xml\" outputSchema=\"http://www.opengis.net/cat/csw/2.0.2\" xmlns=\"http://www.opengis.net/cat/csw/2.0.2\" xmlns:csw=\"http://www.opengis.net/cat/csw/2.0.2\" xmlns:ogc=\"http://www.opengis.net/ogc\" xmlns:ows=\"http://www.opengis.net/ows\" xmlns:dc=\"http://purl.org/dc/elements/1.1/\" xmlns:dct=\"http://purl.org/dc/terms/\" xmlns:gml=\"http://www.opengis.net/gml\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xsi:schemaLocation=\"http://www.opengis.net/cat/csw/2.0.2 ../../../csw/2.0.2/CSW-discovery.xsd\">\n  <Query typeNames=\"csw:Record\">\n    <ElementSetName typeNames=\"csw:Record\">full</ElementSetName>\n    <Constraint version=\"1.1.0\">\n      <ogc:Filter>\n        <ogc:PropertyIsLike wildCard=\"%\" singleChar=\"_\" escapeChar=\"\">\n          <ogc:PropertyName>dc:subject</ogc:PropertyName>\n          <ogc:Literal>%ImageMosaic%</ogc:Literal>\n        </ogc:PropertyIsLike>\n      </ogc:Filter>\n    </Constraint>\n  </Query>\n</GetRecords>\n
                                                                      "},{"location":"extensions/dxf/","title":"DXF OutputFormat for WFS and WPS PPIO","text":"

                                                                      This extension adds two distinct functionalities to GeoServer, both related to DXF format support as an output.

                                                                      DXF is a CAD interchange format, useful to import data in several CAD systems. Being a textual format it can be easily compressed to a much smaller version, so the need for a DXF-ZIP format, for low bandwidth usage.

                                                                      There have been multiple revisions of the format, so we need to choose a \"version\" of DXF to write. The extension implements version 14, but can be easily extended (through SPI providers) to write other versions too.

                                                                      The DXF OutputFormat for WFS adds the support for two additional output formats for WFS GetFeature requests. The new formats, DXF and DXF-ZIP are associated to the \"application/dxf\" and \"application/zip\" mime type, respectively. They produce a standard DXF file or a DXF file compressed in zip format.

                                                                      The WPS PPIO adds dxf as an on output format option for WPS processes. The WPS PPIO requires the WPS extension to be installed on GeoServer.

                                                                      "},{"location":"extensions/dxf/#wfs-output-format-usage","title":"WFS Output Format usage","text":"

                                                                      Request Example:

                                                                      http://localhost:8080/geoserver/wfs?request=GetFeature&typeName=Polygons&\noutputFormat=dxf\n

                                                                      Output Example (portion):

                                                                      0\nSECTION\n2\nHEADER\n9\n$ACADVER\n1\nAC1014\n...\n0\nENDSEC\n...\n0\nSECTION\n2\nTABLES\n...  \n0\nTABLE\n2\nLAYER\n...\n0\nLAYER\n5\n2E\n330\n2\n100\nAcDbSymbolTableRecord\n100\nAcDbLayerTableRecord\n2\nPOLYGONS\n70\n   0\n62\n   7\n6\nCONTINUOUS\n0\nENDTAB\n...\n0\nENDSEC\n0\nSECTION\n2\nBLOCKS\n...\n0\nENDSEC\n0\nSECTION\n2\nENTITIES\n0\nLWPOLYLINE\n5\n927C0\n330\n1F\n100\nAcDbEntity\n8\nPOLYGONS\n100\nAcDbPolyline\n90\n   5\n70\n   1\n43\n0.0\n10\n500225.0\n20\n500025.0\n10\n500225.0\n20\n500075.0\n10\n500275.0\n20\n500050.0\n10\n500275.0\n20\n500025.0\n10\n500225.0\n20\n500025.0\n0\nENDSEC\n0\nSECTION\n2\nOBJECTS\n...\n0\nENDSEC\n0\nEOF\n

                                                                      Each single query is rendered as a layer. Geometries are encoded as entities (if simple enough to be expressed by a single DXF geometry type) or blocks (if complex, such as polygons with holes or collections).

                                                                      Some options are available to control the output generated. They are described in the following paragraphs.

                                                                      "},{"location":"extensions/dxf/#get-requests-format_options","title":"GET requests format_options","text":"The following format_options are supported:
                                                                      1. version: (number) creates a DXF in the specified version format (only 14 is currently supported)
                                                                      2. asblock: (true/false) if true, all geometries are written as blocks and then inserted as entities. If false, simple geometries are directly written as entities.
                                                                      3. colors: (comma delimited list of numbers): colors to be used for the DXF layers, in sequence. If layers are more than the specified colors, they will be reused many times. A set of default colors is used if the option is not used. Colors are AutoCad color numbers (7=white, etc.).
                                                                      4. ltypes: (comma delimited list of line type descriptors): line types to be used for the DXF layers, in sequence. If layers are more than the specified line types, they will be reused many times. If not specified, all layers will be given a solid, continuous line type. A descriptor has the following format: ![!], where is the name assigned to the line type, (optional) is a real number that tells how long is each part of the line pattern (defaults to 0.125), and is a visual description of the repeatable part of the line pattern, as a sequence of - (solid line), (dot) and _ (empty space). For example a dash-dot pattern would be expressed as --__.
                                                                      5. layers: (comma delimited list of strings) names to be assigned to the DXF layers. If specified, must contain a name for each requested query. By default a standard name will be assigned to layers.
                                                                      6. withattributes: (true/false) enables writing an extra layer with attributes from each feature, the layer has a punctual geometry, with a point in the centroid of the original feature
                                                                      7. "},{"location":"extensions/dxf/#post-options","title":"POST options","text":"

                                                                        Unfortunately, it's not currently possible to use format_options in POST requests. The only thing we chose to implement is the layers options, via the handle attribute of Query attributes. So, if specified, the layer of a Query will be named as its handle attribute. The handle attribute of the GetFeature tag can also be used to override the name of the file produced.

                                                                        "},{"location":"extensions/dxf/#wps-ppio","title":"WPS PPIO","text":"

                                                                        When the WPS PPIO module is installed, together with the WPS extension, WPS processes returning a FeatureCollection can use application/dxf or application/zip as output mime type to get a DXF (or zipped DXF) in output.

                                                                        "},{"location":"extensions/geofence/","title":"Geofence Plugin","text":"

                                                                        GeoFence offers an alternative to the GeoServer Security subsystem of GeoServer, allowing far more advanced security configurations, such as rules that combine data and service restrictions. It uses a client-server model, and this plugin only provides the client component. It must connect either to an external Geofence server, or be used in combination with the GeoServer integrated Geofence server Geofence Internal Server.

                                                                        • Installing the GeoServer GeoFence extension
                                                                        • GeoFence Admin GUI
                                                                        • GeoFence Cache REST
                                                                        "},{"location":"extensions/geofence/cache/","title":"GeoFence Cache REST","text":"

                                                                        The Geofence client cache status can be queried, and the cache cleared (invalidated) through a REST service.

                                                                        "},{"location":"extensions/geofence/cache/#requests","title":"Requests","text":""},{"location":"extensions/geofence/cache/#geofencerulecacheinfo","title":"/geofence/ruleCache/info","text":"

                                                                        Retrieve information about the geofence cache status.

                                                                        Method Action Parameters Response GET Retrieve information about the geofence cache status. Per cache (rules, admin rules and users) we retrieve the cache size, hits, misses, load successes, load failures, load times and evictions. --- 200 OK. Text Format."},{"location":"extensions/geofence/cache/#geofencerulecacheinvalidate","title":"/geofence/ruleCache/invalidate","text":"

                                                                        Invalidate the geofence cache.

                                                                        Method Action Parameters Response PUT Invalidate (clear) the geofence cache --- 200 OK."},{"location":"extensions/geofence/configuration/","title":"GeoFence Admin GUI","text":"

                                                                        The GeoFence Admin Page is a component of the GeoServer web interface. You can access it from the GeoServer web interface by clicking the GeoFence link, found on the left side of the screen after logging in.

                                                                        "},{"location":"extensions/geofence/configuration/#general-settings","title":"General Settings","text":"

                                                                        Configure the following settings here:

                                                                        • Geoserver instance name: the name under which this geoserver is known by the geofence server. This useful for when you use an external geofence server with multiple geoserver servers.
                                                                        • GeoServer services URL: this is how geoserver knows how to connect to the external geofence server. When using an internal geofence server, this is not configurable. For example \"http://localhost:9191/geofence/remoting/RuleReader\" for an external geofence server on localhost.
                                                                        "},{"location":"extensions/geofence/configuration/#options","title":"Options","text":"

                                                                        Configure the following settings here:

                                                                        • Allow remote and inline layers in SLD

                                                                        • Authenticated users can write

                                                                        • Use GeoServer roles to get authorizations

                                                                          • Disabled: For each authorization request, GeoServer sends only the user info to GeoFence.

                                                                            GeoFence will retrieve all the roles associated to the user, and will merge the permissions granted for each role.

                                                                          • Enabled: For each authorization request, GeoServer sends to GeoFence the user info AND the roles assigned in the current request session.

                                                                            GeoFence will retrieve all the roles associated to the user, and will only consider the requested roles that are really associated to the user.

                                                                        • Comma delimited list of mutually exclusive roles for authorization

                                                                          • This field is mandatory when the previous option is enabled.

                                                                            GeoServer will send to GeoFence the roles in the current request session which match the entries in this list. You can use the '' symbol to match any session role. When using \"\", you can use the format \"-ROLENAME\" to exclude one or more roles from the the session roles list.

                                                                        "},{"location":"extensions/geofence/configuration/#cache","title":"Cache","text":"

                                                                        Configure the following settings here:

                                                                        • Size of the rule cache (amount of entries)
                                                                        • Cache refresh interval (ms)
                                                                        • Cache expire interval (ms)

                                                                        Collected data about the cache can be retrieved here. Per cache (rules, admin rules and users) we retrieve the cache size, hits, misses, load successes, load failures, load times and evictions. The cache can be manually invalidated (cleared).

                                                                        "},{"location":"extensions/geofence/configuration/#basic-geoserver-configuration","title":"Basic GeoServer configuration","text":"
                                                                        • Login with the default administrative credentials admin / geoserver (or whatever you have configured before).
                                                                        • In the security panel you'll find the GeoFence link to the GeoFence security admin page
                                                                        • Open the GeoFence admin page; you'll get to this page:

                                                                          You can notice here the information that allow the GeoFence probe inside GeoServer to communicate with the GeoFence engine:

                                                                          • the URL that the probe shall use to communicate with GeoFence;
                                                                          • the name (default is default-gs) this instance will use to identify itself to GeoFence. This instance name should be equal to the one we set into GeoFence.
                                                                        • Testing connection to GeoFence.

                                                                          We already performed a connection test from GeoFence to GeoServer. Using the button Test connection we can also test that GeoServer can communicate to GeoFence. If everything is ok, you'll get this message:

                                                                        • Open the Authentication page under the Security settings:

                                                                        • Add the GeoFence authenticator and put it as the first in the list otherwise you will not be able to login as admin/admin:

                                                                        • Now that we added GeoFence as authentication provider, we'll be able to log into GeoServer using the credentials we added in GeoFence (user admin and user tiger). Try and log in using user tiger.
                                                                        "},{"location":"extensions/geofence/configuration/#testing-authorization","title":"Testing authorization","text":"
                                                                        • Logging into GeoServer as admin you will be able to see all the defined layers:
                                                                        • Logging into GeoServer as a non-admin user, the defined rules will be examined; since we defined no rules yet, the default behaviour is to deny access to all resources:
                                                                        • Get back to GeoFence, and add a rule which allows all layers in workspace tiger for user tiger; create a rule defining:

                                                                          • user tiger
                                                                          • instance default-gs
                                                                          • workspace tiger (you will get a dropdown menu containing all the workspaces available in the selected instance)
                                                                          • grant type: allow You'll get a line like this one:

                                                                        • Verify the new authorizations.

                                                                          Since the probe caches the GeoFence responses, you may need to login again as administrator (or you may keep an admin session open in another browser) and clear the probe cache. You can do it by pressing the \"Invalidate\" button in the bottom of the GeoFence admin page:

                                                                        • Login again in GeoServer as user tiger and you will see in layer preview all the layers in the tiger workspace:

                                                                        "},{"location":"extensions/geofence/installing/","title":"Installing the GeoServer GeoFence extension","text":"

                                                                        For version 2.15 and later, use the standard procedure to install an extension.

                                                                        1. Visit the website download page, locate your release, and download: geofence

                                                                          The download link will be in the Extensions section under Other.

                                                                          Warning

                                                                          Ensure to match plugin (example 2.24.2 above) version to the version of the GeoServer instance.

                                                                        2. Extract the files in this archive to the WEB-INF/lib directory of your GeoServer installation.

                                                                        3. Restart GeoServer

                                                                        "},{"location":"extensions/geofence-server/","title":"Geofence Internal Server","text":"

                                                                        This plugin runs a GeoFence server integrated internally in GeoServer. Geofence allows far more advanced security configurations than the default GeoServer Security subsystem, such as rules that combine data and service restrictions.

                                                                        In the integrated version, the users and roles service configured in geoserver are associated with the geofence rule database. The integrated geofence server can be configured using its WebGUI page or REST configuration.

                                                                        • Installing the GeoServer GeoFence Server extension
                                                                        • GeoFence Server GUI
                                                                        • GeoFence Rest API
                                                                        • AdminRules Rest API
                                                                        • Batch Rest API
                                                                        • Using the Internal GeoFence server (Tutorial)
                                                                        • Migrating old GeoFence configuration to GeoServer 2.12 and following
                                                                        "},{"location":"extensions/geofence-server/gui/","title":"GeoFence Server GUI","text":"

                                                                        The GeoFence user interface is a component of the GeoServer web interface. You can access it from the GeoServer web interface by clicking the GeoFence Data Rules link, found on the left side of the screen after logging in.

                                                                        "},{"location":"extensions/geofence-server/gui/#rules-page","title":"Rules page","text":"

                                                                        An overview of all rules is provided with priority, the rule's scope specifications (role, user, service, request, workspace and layer) and its access behaviour. The '*' symbol means that the rule applies to all possible values of that specification. Rules are always ordered by priority, but the order can be reversed by pressing the 'P' priority column header.

                                                                        A new rule can be added with the \"Add new rule\" link. Any number of rules can be deleted by selecting them and then clicking on the \"Remove selected rules\" link.

                                                                        Rule priority order can be easily on this page through the up and down arrows on the right side. Rules can be modified using the pencil symbol, which opens the rule page.

                                                                        "},{"location":"extensions/geofence-server/gui/#rule-page","title":"Rule page","text":"

                                                                        This page is displayed both when creating a new rule and modifying an existing rule.

                                                                        Priority can be changed manually by specifying a priority number. If this priority number is already occupied by another rule, this will cause that rule and all rules after it to shift one place to a lower priority.

                                                                        If using the IP Address range to limit access then on Linux (and other systems with IPv6 enabled) add the -Djava.net.preferIPv4Stack=true flag to the GeoServer startup options to make sure that the IP range matching works with IPv4 style addresses. Currently, IPv6 style address ranges are not supported by GeoFence.

                                                                        When Access type LIMIT is selected, additional options are displayed that allows the user to select the Catalog Mode and the Allowed Area (WKT) associated with this rule. The Spatial Filter Type parameter allows to define whether apply the Allowed Area filter to vector data as an Intersects or a Clip filter.

                                                                        When Access type ACCESS is selected as well as a specific layer, it becomes possible to specify the \"layer details\" in a separate tab. These make it possible to add additional filters to the layer for the rule in question. For example, the rule can alter the default style of the layer, specify which styles are available at all, which attributes are accessible for reading and/or writing, specify CQL filters for both reading and writing, specify a catalog mode, and an allowed area (WKT) filter.

                                                                        A CQL Read Filter can be setup to allow users to only access a subset of the available data.

                                                                        For example, having a daily time series layer (a Layer with time attribute/dimension), it's possible to restrict access to a given time range.

                                                                        A CQL filter to limit access to the whole 2020 year (static time range) would look as follows:

                                                                        time between 2020-01-01 and 2020-12-31\n

                                                                        A CQL filter limiting access to data older than a week (dynamic time range) would look like this instead:

                                                                        dateDifference(now(), time, 'd') > 7\n

                                                                        (see temporal-functions for more details on the date difference function)

                                                                        Allowed area can be defined in whatever SRID. Geoserver will automatically reproject it to the resource CRS when needed.

                                                                        "},{"location":"extensions/geofence-server/gui/#layer-groups","title":"Layer groups","text":"

                                                                        Layer groups are also supported. If no workspace has been specified, the layer dropdown will show global layer groups, while if a workspace is selected the workspace's layergroup will be showed together with the layers.

                                                                        The read and write filters text areas as well as the style palette in the layer details tab are disabled when the layer group is being configured.

                                                                        When a LayerGroup is request the contained resource will be handled in the following way:

                                                                        • a limit applied to the layer groups (allowed area or grant type) will be applied to all the contained layers.
                                                                        • if the access rule a contained layer is denying the access to the layer for the user requesting group, the layer will not be present in the output.
                                                                        • if the access rule of the layer has limits on its own, they will be merged in a restrictive way (intersection) with the one of the layer group if both the limits have been defined for the same role.
                                                                        • if the access rule of the layer has limits on its own, they will be merged in a permissive way (union) with the one of the layer group if both the limits have been defined for the different roles.

                                                                        When a layer contained in one or more layer group is directly accessed in the context of a WMS request, the following rules apply:

                                                                        • If any of the layer groups containing the requested resource has mode SINGLE no limits eventually defined for any of the layer groups will be applied.
                                                                        • If all the layer groups containing the requested resource have mode OPAQUE, the layer will not be visible.
                                                                        • If all the layer groups containing the resource has mode different from SINGLE and OPAQUE, the layer groups limits will be applied and merged with the one defined for the resource if present. For each layer group, the limits will be merged in a restrictive way with the ones defined for the resource if the rule was defined for the same role. On the contrary the limits will be merged with an enlargement logic, if coming from rules defined for different roles.
                                                                        "},{"location":"extensions/geofence-server/installing/","title":"Installing the GeoServer GeoFence Server extension","text":"
                                                                        1. Visit the website download page, locate your release, and download: geofence-server

                                                                          The download link will be in the Extensions section under Other.

                                                                          Warning

                                                                          Ensure to match plugin (example 2.24.2 above) version to the version of the GeoServer instance.

                                                                        1. Extract the files in this archive to the WEB-INF/lib directory of your GeoServer installation.

                                                                          ::: note ::: title Note :::

                                                                          By default GeoFence will store this data in a H2 database and the database schema will be automatically managed by Hibernate.

                                                                          The GeoFence documentation explains how to configure a different backed database and configure Hibernate behavior. :::

                                                                        2. Add the following system variable among the JVM startup options (location varies depending on installation type): -Dgwc.context.suffix=gwc

                                                                        3. Restart GeoServer

                                                                        "},{"location":"extensions/geofence-server/migration/","title":"Migrating old GeoFence configuration to GeoServer 2.12 and following","text":"

                                                                        Starting from GeoServer 2.12, the allowDynamicStyles GeoFence configuration option has been moved to the core GeoServer WMS module.

                                                                        This means that if you had this option active in GeoFence, you have to manually enable the same option in the WMS service configuration page of the GeoServer Admin UI (either globally or on a virtual service by virtual service basis).

                                                                        See here: WMS settings

                                                                        "},{"location":"extensions/geofence-server/rest-adminrule/","title":"AdminRules Rest API","text":""},{"location":"extensions/geofence-server/rest-adminrule/#security","title":"Security","text":"

                                                                        The Geofence Rest API is only accessible to users with the role ROLE_ADMIN.

                                                                        "},{"location":"extensions/geofence-server/rest-adminrule/#inputoutput","title":"Input/Output","text":""},{"location":"extensions/geofence-server/rest-adminrule/#data-object-transfer","title":"Data Object Transfer","text":"

                                                                        Both XML and JSON are supported for transfer of data objects. The default is XML. Alternatively, JSON may be used by setting the 'content-type' (POST) and 'accept' (GET) http headers to 'application/json' in your requests.

                                                                        Encoding of an AdminRule in XML:

                                                                        <AdminRule>\n    <id>..</id>\n    <priority>..</priority>\n    <userName>..</userName>\n    <roleName>..</roleName>\n    <addressRange>..</addressRange>\n    <workspace>..</workspace>\n    <access>..</access>\n</AdminRule>\n

                                                                        Encoding of a rule in JSON:

                                                                        {\"id\":..,\"priority\":..,\"userName\":\"..\",\"roleName\":\"..\",\"addressRange\":\"..\",\"workspace\":\"..\",\"access\":\"..\"}\n

                                                                        In case a rule that has \"any\" (\"*\") for a particular field the field is either not included (default), left empty or specified with a single asterisk (the latter two may be used for updates to distinguish from \"do not change this field\").

                                                                        access should be either ADMIN or USER.

                                                                        addressRange is a string in CIDR notation (block/bits: e.g. 127.0.0.1/32).

                                                                        Encoding of a list of rules in XML:

                                                                        <AdminRules count=\"n\">\n    <AdminRule> ... </AdminRule>\n    <AdminRule> ... </AdminRule>\n    ...     \n</AdminRules>\n

                                                                        The result of a count would not include the actual tags.

                                                                        Encoding of a list of rules in JSON:

                                                                        {\"count\":n,\"adminrules\":[{..},{..},..]}\n
                                                                        "},{"location":"extensions/geofence-server/rest-adminrule/#filter-parameters","title":"Filter Parameters","text":"

                                                                        All filter parameters are optional.

                                                                        Name Type Description page number Used for paging a list of rules. Specifies the number of the page. Leave out for no paging. If specified, entries should also be specified. entries number Used for paging a list of rules. Specifies the number of entries per page. Leave out for no paging. If specified, page should also be specified. userName string Filter rules on username (excludes all other specified usernames). userAny 0 or 1. Specify whether rules matching any username should be included or not. roleName string Filter rules on rolename (excludes all other specified rolenames). roleAny 0 or 1. Specify whether rules matching any rolename should be included or not. workspace string Filter rules on workspace (excludes all other specified workspaces). workspaceAny 0 or 1. Specify whether rules matching any workspace should be included or not."},{"location":"extensions/geofence-server/rest-adminrule/#requests","title":"Requests","text":""},{"location":"extensions/geofence-server/rest-adminrule/#geofencerestadminrules","title":"/geofence/rest/adminrules/","text":"

                                                                        Query all adminrules or add a new adminrule.

                                                                        Method Action Supported parameters Response GET List all adminrules, with respect to any added filters page, entries, userName, userAny, roleName, roleAny, workspace, workspaceAny 200 OK. List of adminrules in XML. POST Add a new adminrule None 201 Inserted. Created ID header."},{"location":"extensions/geofence-server/rest-adminrule/#geofencerestadminrulescount","title":"/geofence/rest/adminrules/count","text":"

                                                                        Counts (filtered) adminrules.

                                                                        Method Action Supported parameters Response GET Count all adminrules, with respect to any added filters userName, userAny, roleName, roleAny, workspace, workspaceAny 200 OK. Rule list count in XML."},{"location":"extensions/geofence-server/rest-adminrule/#geofencerestadminrulesidid","title":"/geofence/rest/adminrules/id/<id>","text":"

                                                                        Query, modify or delete a specific adminrule.

                                                                        Method Action Supported parameters Response GET Read adminrule information None 200 OK. AdminRule in XML. POST Modify the adminrule, unspecified fields remain unchanged. None 200 OK. DELETE Delete the adminrule None 200 OK."},{"location":"extensions/geofence-server/rest-batch-op/","title":"Batch Rest API","text":"

                                                                        Batch operations allow to run multiple insert, update and delete at the same time over rules and admin rules. All the operations are executed in a single transaction: this means that either all of them are successful or all the operations are rolled back.

                                                                        "},{"location":"extensions/geofence-server/rest-batch-op/#security","title":"Security","text":"

                                                                        The Geofence REST API is only accessible to users with the role ROLE_ADMIN.

                                                                        "},{"location":"extensions/geofence-server/rest-batch-op/#inputoutput","title":"Input/Output","text":""},{"location":"extensions/geofence-server/rest-batch-op/#data-object-transfer","title":"Data Object Transfer","text":"

                                                                        Both XML and JSON are supported for transfer of data objects. The default is XML. Alternatively, JSON may be used by setting the Content-Type and Accept HTTP headers to application/json in your requests.

                                                                        A Batch data object transfer must declare a list of operations. Each operation needs to declare:

                                                                        • The service name (rules for a Rule operation or adminrules for an AdminRule operation).
                                                                        • The type of the operation (insert, update, delete).
                                                                        • The id of the entity over which the operation is being performed in case of an update or delete types.
                                                                        • The Rule or AdminRule data object transfer in case of insert or update operation.

                                                                        Encoding of a Batch in XML:

                                                                        <Batch>\n<operations service=\"rules\" id=\"2\" type=\"update\">\n  <Rule id=\"2\">\n     <access>ALLOW</access>\n     <layer>layer</layer>\n     <priority>5</priority>\n     <request>GETMAP</request>\n     <roleName>ROLE_AUTHENTICATED</roleName>\n     <service>WMS</service>\n     <workspace>ws</workspace>\n  </Rule>\n</operations>\n<operations service=\"rules\" id=\"5\" type=\"delete\" />\n<operations service=\"adminrules\" type=\"insert\">\n  <RuleAdmin>\n     <priority>2</priority>\n     <roleName>ROLE_USER</roleName>\n     <workspace>ws</workspace>\n     <access>ADMIN</access>\n  </RuleAdmin>\n</operations>\n</Batch>\n

                                                                        Encoding of a Batch in JSON:

                                                                        {\n\"Batch\":{\n  \"operations\":[\n     {\n        \"@service\":\"adminrules\",\n        \"@type\":\"update\",\n        \"@id\":\"3\",\n        \"Rule\":{\n           \"access\":\"ALLOW\",\n           \"layer\":\"layer\",\n           \"priority\":5,\n           \"request\":\"GETMAP\",\n           \"service\":\"WMS\",\n           \"roleName\":\"ROLE_AUTHENTICATED\",\n           \"workspace\":\"ws\"\n        }\n     },\n     {\n        \"@service\":\"rules\",\n        \"@type\":\"delete\",\n        \"@id\":5\n     },\n     {\n        \"@service\":\"adminrules\",\n        \"@type\":\"insert\",\n        \"AdminRule\":{\n           \"priority\":2,\n           \"roleName\":\"ROLE_USER\",\n           \"workspace\":\"ws\",\n           \"access\":\"ADMIN\"\n        }\n     }\n  ]\n}\n}\n
                                                                        "},{"location":"extensions/geofence-server/rest-batch-op/#requests","title":"Requests","text":""},{"location":"extensions/geofence-server/rest-batch-op/#restgeofencebatchexec","title":"/rest/geofence/batch/exec","text":"

                                                                        Issue a Batch operation executing all the declared operations.

                                                                        Method Action Response code Response

                                                                        POST Execute a batch 200 OK

                                                                                                 400             BadRequest: malformed request body, duplicate rule addition\n\n                         404             NotFound: rule not found\n\n                         500             InternalServerError: unexpected error\n
                                                                        "},{"location":"extensions/geofence-server/rest/","title":"GeoFence Rest API","text":""},{"location":"extensions/geofence-server/rest/#security","title":"Security","text":"

                                                                        The Geofence Rest API is only accessible to users with the role ROLE_ADMIN.

                                                                        "},{"location":"extensions/geofence-server/rest/#inputoutput","title":"Input/Output","text":""},{"location":"extensions/geofence-server/rest/#data-object-transfer","title":"Data Object Transfer","text":"

                                                                        Both XML and JSON are supported for transfer of data objects. The default is XML. Alternatively, JSON may be used by setting the 'content-type' (POST) and 'accept' (GET) http headers to 'application/json' in your requests.

                                                                        Encoding of a rule in XML:

                                                                        <Rule>\n    <id>..</id>\n    <priority>..</priority>\n    <userName>..</userName>\n    <roleName>..</roleName>\n    <workspace>..</workspace>\n    <layer>..</layer>\n    <service>..</service>\n    <request>..</request>\n    <subfield>..</subfield>\n    <access> ALLOW | DENY | LIMIT </access>\n\n    <!-- for LIMIT access rules-->\n    <limits> \n        <allowedArea>..</allowedArea>\n        <catalogMode> HIDE | CHALLENGE | MIXED </catalogMode>\n    </limits>\n\n    <!-- for ALLOW access rules with specified layer -->\n    <layerDetails>\n        <layerType> VECTOR | RASTER | LAYERGROUP </layerType>\n        <defaultStyle>..</defaultStyle>\n        <cqlFilterRead>..</cqlFilterRead>\n        <cqlFilterWrite>..</cqlFilterWrite>\n        <allowedArea>..</allowedArea>\n        <catalogMode> HIDE | CHALLENGE | MIXED </catalogMode>\n\n        <allowedStyle>..</allowedStyle>\n        ..\n\n        <attribute>\n            <name>..</name>\n            <datatype>..</datatype>\n            <accessType> NONE | READONLY | READWRITE </accessType>\n        </attribute>            \n                    ..\n\n    </layerDetails>\n</Rule>\n

                                                                        Encoding of a rule in JSON:

                                                                        {\"Rule\": {\"id\":..,\"priority\":..,\"userName\":\"..\",\"roleName\":\"..\",\"workspace\":\"..\",\"layer\":\"..\",\"service\":\"..\",\"request\":\"..\",\"subfield\":\"..\",\"access\":\"..\"}}\n

                                                                        In case a rule that has \"any\" (\"*\") for a particular field the field is either not included (default), left empty or specified with a single asterisk (the latter two may be used for updates to distinguish from \"do not change this field\").

                                                                        Encoding of a list of rules in XML:

                                                                        <Rules count=\"n\">\n    <Rule> ... </Rule>\n    <Rule> ... </Rule>\n    ...     \n</Rules>\n

                                                                        The result of a count would not include the actual tags.

                                                                        Encoding of a list of rules in JSON:

                                                                        {\"count\":n,\"rules\":[{..},{..},..]}\n
                                                                        "},{"location":"extensions/geofence-server/rest/#filter-parameters","title":"Filter Parameters","text":"

                                                                        All filter parameters are optional.

                                                                        Name Type Description page number Used for paging a list of rules. Specifies the number of the page. Leave out for no paging. If specified, entries should also be specified. entries number Used for paging a list of rules. Specifies the number of entries per page. Leave out for no paging. If specified, page should also be specified. userName string Filter rules on username (excludes all other specified usernames). userAny 0 or 1. Specify whether rules for 'any' username are included or not. roleName string Filter rules on rolename (excludes all other specified rolenames). roleAny 0 or 1. Specify whether rules for 'any' rolename are included or not. service string Filter rules on service (excludes all other specified services). serviceAny 0 or 1. Specify whether rules for 'any' service are included or not. request string Filter rules on request (excludes all other specified requests). requestAny 0 or 1. Specify whether rules for 'any' request are included or not. workspace string Filter rules on workspace (excludes all other specified workspaces). workspaceAny 0 or 1. Specify whether rules for 'any' workspace are included or not. layer string Filter rules on layer (excludes all other specified layers). layerAny 0 or 1. Specify whether rules for 'any' layer are included or not."},{"location":"extensions/geofence-server/rest/#requests","title":"Requests","text":""},{"location":"extensions/geofence-server/rest/#restgeofencerules","title":"/rest/geofence/rules/","text":"

                                                                        Query all rules or add a new rule.

                                                                        Method Action Supported parameters Response GET List all rules, with respect to any added filters page, entries, userName, userAny, roleName, roleAny, service, serviceAny, request, requestAny, workspace, workspaceAny, layer, layerAny 200 OK. List of rules in XML. POST Add a new rule None 201 Inserted. Created ID header."},{"location":"extensions/geofence-server/rest/#restgeofencerulescount","title":"/rest/geofence/rules/count","text":"

                                                                        Counts (filtered) rules.

                                                                        Method Action Supported parameters Response GET Count all rules, with respect to any added filters userName, userAny, roleName, roleAny, service, serviceAny, request, requestAny, workspace, workspaceAny, layer, layerAny 200 OK. Rule list count in XML."},{"location":"extensions/geofence-server/rest/#restgeofencerulesidid","title":"/rest/geofence/rules/id/<id>","text":"

                                                                        Query, modify or delete a specific rule.

                                                                        Method Action Supported parameters Response GET Read rule information None 200 OK. Rule in XML. POST Modify the rule, unspecified fields remain unchanged. None 200 OK. DELETE Delete the rule None 200 OK."},{"location":"extensions/geofence-server/tutorial/","title":"Using the Internal GeoFence server (Tutorial)","text":""},{"location":"extensions/geofence-server/tutorial/#introduction","title":"Introduction","text":"

                                                                        This tutorial shows how to install and configure the Geofence Internal Server plug-in. It shows how to create rules in two ways: using the GUI and REST methods.

                                                                        The tutorial assumes:

                                                                        • GeoServer is running on http://localhost:8080/geoserver

                                                                        • You have a user/group service called \"default\" that allows the creation of new users. If your primary user/group service is not called \"default\", you must start geoserver with the following java system property present:

                                                                          org.geoserver.rest.DefaultUserGroupServiceName=<name_of_usergroupservice>\n

                                                                        with a user/group service that allows the creation of new users."},{"location":"extensions/geofence-server/tutorial/#getting-started","title":"Getting Started","text":"

                                                                        Install the plugin-in, see Installing the GeoServer GeoFence Server extension. Configure the user/group service as described above if necessary.

                                                                        Restart GeoServer.

                                                                        ::: note ::: title Note :::

                                                                        Since we defined no rules yet, the default behavior of GeoFence is to deny access to all resources. :::

                                                                        There should now be a GeoFence Data Rules link on the left side of the screen after logging in. Click on it. This is the configuration page of your internal GeoFence.

                                                                        "},{"location":"extensions/geofence-server/tutorial/#creating-new-rules-with-the-gui","title":"Creating new Rules with the GUI","text":"
                                                                        1. Click on the \"Add new rule\" link. Change only \"Access\" to \"DENY\".

                                                                        Click on \"Save\".

                                                                        We have now expressed that the first rule (with lowest priority) disallows everyone from everything. The following more specific rules we make will provide the exceptions to that general rule. It is also possible to do it the other way (allow everyone to anything as most general rule and specify exceptions to that.)

                                                                        1. As a next step, we will grant the administrator access to everything. Click on \"Add new rule\" again. Change \"Role\" to \"ADMIN\" and click \"Save\".

                                                                        You now have a working, basic security configuration.

                                                                        "},{"location":"extensions/geofence-server/tutorial/#creating-rules-with-the-rest-api","title":"Creating rules with the REST API","text":"

                                                                        1. Open a new tab with your browser and go to the following URL: http://localhost:8080/geoserver/geofence/rest/rules. You should get an XML representation of your rules:

                                                                        <?xml version=\"1.0\" encoding=\"UTF-8\" standalone=\"yes\"?>\n<Rules count=\"2\">\n  <Rule id=\"2\">\n      <access>ALLOW</access>\n      <priority>0</priority>\n      <roleName>ADMIN</roleName>\n  </Rule>\n  <Rule id=\"1\">\n      <access>DENY</access>\n      <priority>1</priority>\n  </Rule>\n</Rules>\n

                                                                        2. Let us first create a new user. Do this by sending a POST request to the following URL http://localhost:8080/geoserver/rest/security/usergroup/users with the following content:

                                                                        <user>\n      <userName>michaeljfox</userName>\n      <password>back2$future</password>\n      <enabled>true</enabled>\n</user>\n

                                                                        You should receive a 201 Created HTTP Response.

                                                                        3. Now we will create an access rule for this user. Do this by sending a POST request to the following URL: http://localhost:8080/geoserver/geofence/rest/rules with the following content:

                                                                        <Rule>\n      <userName>michaeljfox</userName>\n      <workspace>topp</workspace>\n      <layer>states</layer>\n      <service>WMS</service>\n      <request>GetMap</request>\n      <access>ALLOW</access>\n</Rule>\n

                                                                        Again, you should receive a 201 Created HTTP Response. When browsing to the URL http://localhost:8080/geoserver/geofence/rest/rules we should now see the following information:

                                                                        <?xml version=\"1.0\" encoding=\"UTF-8\" standalone=\"yes\"?>\n<Rules count=\"2\">\n  <Rule id=\"3\">\n      <access>ALLOW</access>\n      <layer>states</layer\n      <priority>0</priority>\n      <request>GETMAP</request>\n      <service>WMS</service>\n      <userName>michaeljfox</userName>\n      <workspace>topp</workspace>\n  </Rule>\n  <Rule id=\"2\">\n      <access>ALLOW</access>\n      <priority>0</priority>\n      <roleName>ADMIN</roleName>\n  </Rule>\n  <Rule id=\"1\">\n      <access>DENY</access>\n      <priority>1</priority>\n  </Rule>\n</Rules>\n
                                                                        1. It should now be possible to log on with username michaeljfox and password back2$future and perform a GetMap on the layer topp:states, but nothing else.
                                                                        "},{"location":"extensions/geofence-wps/","title":"Geofence WPS Integration","text":"

                                                                        This plugin adds a fine-grained control over WPS processes.

                                                                        Without this plugin, you can only allow/deny a layer for the whole WPS service for given user/roles.

                                                                        Using this plugin, you can create authorization rules for the single WPS process.

                                                                        • Installing the GeoServer GeoFence WPS Integration
                                                                        • GeoFence WPS rules setup
                                                                        "},{"location":"extensions/geofence-wps/gui/","title":"GeoFence WPS rules setup","text":"

                                                                        This plugin will not change the GUI in any way. Anyway, you can now use the subfield field to select the processes you want to authorize.

                                                                        For instance, with the following rules:

                                                                        you will enable all WPS processes for the tasmania_cities layer, but you will prevent to download it via WPS.

                                                                        "},{"location":"extensions/geofence-wps/gui/#chained-processes","title":"Chained processes","text":"

                                                                        Please note that this plugin also considers chained WPS processes, when they are running in the same GeoServer instance. If a user is running an execute request containing more than one chained process, all processes will be needed to be allowed in order for the request to be run successfully.

                                                                        For instance, if the user sends a request of this kind:

                                                                        /--> Proc2 --> Layer A\nProc1 --|\n\\              /--> Layer B\n --> Proc3 --|\n               --> Proc4 --> Layer C\n

                                                                        the user will need at least these permissions:

                                                                        • Proc1: LayerA + LayerB + LayerC
                                                                        • Proc2: LayerA
                                                                        • Proc3: LayerB + LayerC
                                                                        • Proc4: LayerC
                                                                        "},{"location":"extensions/geofence-wps/installing/","title":"Installing the GeoServer GeoFence WPS Integration","text":"
                                                                        1. Visit the website download page, locate your release, and download: geofence-wps

                                                                          The download link will be in the Extensions section under Other.

                                                                          Warning

                                                                          Ensure to match plugin (example 2.24.2 above) version to the version of the GeoServer instance.

                                                                        1. Extract the files in this archive to the WEB-INF/lib directory of your GeoServer installation.
                                                                        2. Restart GeoServer
                                                                        "},{"location":"extensions/geopkg-output/","title":"GeoPackage Output","text":"

                                                                        This extension supports GeoPKG as an output format for both WFS (vectors) and WMS (tiles).

                                                                        • Installing the GeoPackage Output Extension
                                                                        • Using the GeoPackage Output Extension
                                                                        "},{"location":"extensions/geopkg-output/install/","title":"Installing the GeoPackage Output Extension","text":"

                                                                        The GeoPackage Output extension is an official extension. Download the extension here - geopkg-output

                                                                        1. Download the extension for your version of GeoServer.

                                                                          Warning

                                                                          Make sure to match the version of the extension to the version of GeoServer.

                                                                        2. Extract the archive and copy the contents into the GeoServer WEB-INF/lib directory.

                                                                        3. Restart GeoServer.

                                                                        "},{"location":"extensions/geopkg-output/install/#verify-installation","title":"Verify Installation","text":"

                                                                        To verify that the extension was installed successfully:

                                                                        1. Request the WFS 1.0.0 GetCapabilities document from your server.

                                                                        2. Inside the resulting WFS 1.0.0 XML GetCapabilities document, find the WFS_Capabilities/Capability/GetFeature/ResultFormat section

                                                                        3. Verify that geopkg, geopackage, and gpkg are listed as a supported format

                                                                          <GetFeature>\n    <ResultFormat>\n        <GML2/>\n        <GML3/>\n        <SHAPE-ZIP/>\n        <CSV/>\n        <JSON/>\n        <KML/>\n        <geopackage/>\n        <geopkg/>\n        <gpkg/>\n    </ResultFormat>\n</GetFeature>\n

                                                                        Note

                                                                        You can also verify installation by looking for GeoPKG Output Extension on the server's Module Status Page.

                                                                        "},{"location":"extensions/geopkg-output/usage/","title":"Using the GeoPackage Output Extension","text":"

                                                                        The GeoPackage Output Extension adds support to WFS and WMS to request GetFeature and GetMap results in GeoPackage Format.

                                                                        "},{"location":"extensions/geopkg-output/usage/#wfs","title":"WFS","text":"

                                                                        Add &outputFormat=geopkg to your request. The result will be a GeoPackage (MIME type application/geopackage+sqlite3) containing the requested features.

                                                                        curl \"http://localhost:8080/geoserver/wfs?service=wfs&version=2.0.0&request=GetFeature&typeNames=ws:layername&outputFormat=geopkg\" \\\n-o wfs.gpkg\n

                                                                        You can use geopkg, geopackage, or gpkg as the output format in the request. Use 1.0.0, 1.1.0, or 2.0.0 as version= to specify which WFS version to use.

                                                                        Note

                                                                        GeoPackages always have the ordinates in X,Y (EAST_NORTH) format.

                                                                        "},{"location":"extensions/geopkg-output/usage/#wfs-output-configuration","title":"WFS Output Configuration","text":"

                                                                        GeoPackage output format configuration properties are available. For information on use of configuration properties see running in a production environment instructions.

                                                                        "},{"location":"extensions/geopkg-output/usage/#geopackagewfsindexed","title":"geopackage.wfs.indexed","text":"

                                                                        By default a spatial index is generated when generating GeoPackage output.

                                                                        Use java system property -Dgeopackage.wfs.indexed=false to suppress the generation of a spatial index in generated geopackage output.

                                                                        "},{"location":"extensions/geopkg-output/usage/#geopackagewfstempdir","title":"geopackage.wfs.tempdir","text":"

                                                                        The GeoPackage file format is an SQLite database which can only be managed as a file locally. To produce a GeoPackage GeoServer makes use of a temporary file created in java.io.tmpdir location. This temporary file is removed once the response is completed.

                                                                        Some container environments recommend use of a network share for their java.io.tmpdir location. This approach is not compatible with SQLite database driver which requires a local disk location and file lock.

                                                                        To override the temporary file location used for GeoPackage output format file generation use property -Dgeopackage.wfs.tempdir=<path location> to provide an alternate path.

                                                                        "},{"location":"extensions/geopkg-output/usage/#wms","title":"WMS","text":"

                                                                        Add &format=geopkg to your request. The result will be a GeoPackage (MIME type application/geopackage+sqlite3) containing the requested tiles.

                                                                        Using WMS 1.1.0 to access tiled image geopkg:

                                                                        curl \"http://localhost:8080/geoserver/wms?service=WMS&version=1.1.0&request=GetMap&layers=ws:layername&bbox=-123.43670607166865%2C48.3956835%2C-123.2539813%2C48.5128362547052&width=1536&height=984&srs=EPSG%3A4326&styles=&format=geopkg\" \\\n-o wms.gpkg\n

                                                                        Using WMS 1.3.0 to access tiled image geopkg:

                                                                        curl \"http://localhost:8080/geoserver/wms?service=WMS&version=1.3.0&request=GetMap&layers=ws:layername&bbox=48.3956835,-123.43670607166865,48.5128362547052,-123.2539813&width=768&height=492&srs=EPSG%3A4326&styles=&format=geopkg\" \\\n-o wms.gpkg\n

                                                                        You can use format=geopkg, format=geopackage, or format=gpkg as the output format in the request. Use WMS version=1.1.0, or version=1.3.0 to specify which WMS version to use, keeping in mind axis order for bbox differences.

                                                                        Note

                                                                        Regardless of WMS axis order used for bbox the resulting GeoPackages always have the ordinates in X,Y (EAST_NORTH) order as required by the specification.

                                                                        "},{"location":"extensions/geopkg-output/usage/#wms-format-options","title":"WMS Format options","text":"

                                                                        You can also add format options (format_options=param1:value1;param2:value2;...) to the request. With all default values, you will get a GeoPackage with PNG tiles of multiple resolutions. There will be a little more than 255 total tiles - all occupying the area in the request's bbox.

                                                                        +--------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Parameter | Description | +==============+=============================================================================================================================================================+ | min_zoom | Grid Zoom level for tiles to start. | | | | | | default: zoom level based on a single tile covering the bbox area. | +--------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------+ | max_zoom | Grid Zoom level for tiles to end. | | | | | | default: zoom where there's >255 tiles in total in the geopkg (could be a bit more) | +--------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------+ | num_zooms | Number of zoom levels in the geopkg. | | | | | | If present then max_zoom = min_zoom + num_zooms | +--------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------+ | format | Format for the image tiles in the geopkg. | | | | | | default: PNG | +--------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------+ | tileset_name | Name of tile set (\"layer\") used in the geopkg. | | | | | | default: based on the layer names given in the request ('_' separated) | +--------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------+ | min_column | First column number (from the gridset) to use. | | | | | | default: use request bbox to determine which tiles to produce | +--------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------+ | max_column | Last column number (from the gridset) to use. | | | | | | default: use request bbox to determine which tiles to produce | +--------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------+ | min_row | First row number (from the gridset) to use. | | | | | | default: use request bbox to determine which tiles to produce | +--------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------+ | max_row | Last row number (from the gridset) to use. | | | | | | default: use request bbox to determine which tiles to produce | +--------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------+ | gridset | Name of the gridset (from GWC GridSetBroker) to uses. | | | | | | default: find based on request SRS | +--------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------+ | flipy | Do NOT set. | | | | | | default: TRUE (required for GeoPackage - The tile coordinate (0,0) always refers to the tile in the upper left corner of the tile matrix\\...) | +--------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------+

                                                                        "},{"location":"extensions/grib/grib/","title":"GRIB","text":""},{"location":"extensions/grib/grib/#adding-a-grib-data-store","title":"Adding a GRIB data store","text":"

                                                                        To add a GRIB data store the user must go to Stores \u2192 Add New Store \u2192 GRIB.

                                                                        GRIB in the list of raster data stores

                                                                        "},{"location":"extensions/grib/grib/#configuring-a-grib-data-store","title":"Configuring a GRIB data store","text":"

                                                                        Configuring a GRIB data store

                                                                        Option Description Workspace Data Source Name Description Enabled URL"},{"location":"extensions/grib/grib/#relationship-with-netcdf","title":"Relationship with NetCDF","text":"

                                                                        Note

                                                                        Note that internally the GRIB extension uses the NetCDF reader, which supports also GRIB data. See also the NetCDF documentation page for further information.

                                                                        "},{"location":"extensions/grib/grib/#current-limitations","title":"Current limitations","text":"
                                                                        • Input coverages/slices should share the same bounding box (lon/lat coordinates are the same for the whole ND cube)
                                                                        "},{"location":"extensions/gwc-s3/","title":"GWC S3 BlobStore plugin","text":"

                                                                        This plugin supports the use of the AWS Simple Storage Service (Amazon S3) as storage medium for GWC<gwc_webadmin>.

                                                                        • Installing the GWC S3 extension
                                                                        • Configuring the S3 BlobStore plugin
                                                                        "},{"location":"extensions/gwc-s3/configuration/","title":"Configuring the S3 BlobStore plugin","text":"

                                                                        Once the plugin has been installed, one or more S3 BlobStores may be configured through BlobStores. Afterwards, cached layers can be explicitly assigned to it or one blobstore could be marked as 'default' to use it for all unassigned layers.

                                                                        "},{"location":"extensions/gwc-s3/configuration/#bucket","title":"Bucket","text":"

                                                                        The name of the AWS S3 bucket where the tiles are stored.

                                                                        "},{"location":"extensions/gwc-s3/configuration/#aws-access-key","title":"AWS Access Key","text":"

                                                                        The AWS Access Key ID. If AWS Access Key and AWS Secret Access Key are left blank, AWS Default Credential Chain will be used.

                                                                        "},{"location":"extensions/gwc-s3/configuration/#aws-secret-key","title":"AWS Secret Key","text":"

                                                                        AWS Secret Access Key.

                                                                        "},{"location":"extensions/gwc-s3/configuration/#s3-object-key-prefix","title":"S3 Object Key Prefix","text":"

                                                                        A prefix path to use as the root to store tiles under the bucket (optional).

                                                                        "},{"location":"extensions/gwc-s3/configuration/#maximum-connections","title":"Maximum Connections","text":"

                                                                        The maximum number of allowed open HTTP connections.

                                                                        "},{"location":"extensions/gwc-s3/configuration/#use-https","title":"Use HTTPS","text":"

                                                                        When enabled, a HTTPS connection will be used. When disabled, a regular HTTP connection will be used.

                                                                        "},{"location":"extensions/gwc-s3/configuration/#proxy-domain","title":"Proxy Domain","text":"

                                                                        A Windows domain name for configuring NTLM proxy support (optional).

                                                                        "},{"location":"extensions/gwc-s3/configuration/#proxy-workstation","title":"Proxy Workstation","text":"

                                                                        A Windows workstation name for configuring NTLM proxy support (optional).

                                                                        "},{"location":"extensions/gwc-s3/configuration/#proxy-host","title":"Proxy Host","text":"

                                                                        Proxy host the client will connect through (optional).

                                                                        "},{"location":"extensions/gwc-s3/configuration/#proxy-port","title":"Proxy Port","text":"

                                                                        Proxy port the client will connect through (optional).

                                                                        "},{"location":"extensions/gwc-s3/configuration/#proxy-username","title":"Proxy Username","text":"

                                                                        User name the client will use if connecting through a proxy (optional).

                                                                        "},{"location":"extensions/gwc-s3/configuration/#proxy-password","title":"Proxy Password","text":"

                                                                        Password the client will use if connecting through a proxy (optional).

                                                                        "},{"location":"extensions/gwc-s3/configuration/#use-gzip","title":"Use Gzip","text":"

                                                                        When enabled, the stored tiles will be GZIP compressed.

                                                                        "},{"location":"extensions/gwc-s3/configuration/#access-type","title":"Access Type","text":"

                                                                        Stored tiles will be created either as Public (readable and writable by any user that can access the S3 bucket), or Private (readable and writable only by the user identified by the AWS credentials specified above). Important: if the bucket itself is setup to block all public access, then the blobstore needs to be setup to Private as well, or AWS will return a 403 when attempting to store tiles.

                                                                        "},{"location":"extensions/gwc-s3/install/","title":"Installing the GWC S3 extension","text":"

                                                                        The GWC S3 extension is listed among the other extension downloads on the GeoServer download page.

                                                                        The installation process is similar to other GeoServer extensions:

                                                                        1. Visit the website download page, locate your release, and download: gwc-s3

                                                                          Verify that the version number in the filename (for example 2.24.2 above) corresponds to the version of GeoServer you are running.

                                                                        2. Extract the contents of the archive into the WEB-INF/lib directory in GeoServer. Make sure you do not create any sub-directories during the extraction process.

                                                                        3. Restart GeoServer.

                                                                        To verify the installation was successful, to \"Tile Caching\", \"Blobstores\" and create a new blobstore, the S3 option show be available:

                                                                        The S3 option showing while creating a new blobstore

                                                                        "},{"location":"extensions/iau/","title":"IAU planetary CRSs","text":"

                                                                        This extension adds IAU planetary CRSs to the database recognized by GeoServer and helps configuring and generating data in such CRSs, without having to create a fake EPSG code.

                                                                        • Installing the IAU authority
                                                                        • Using IAU authority
                                                                        "},{"location":"extensions/iau/install/","title":"Installing the IAU authority","text":"

                                                                        The IAU authority is an official extension. Download the extension here - iau

                                                                        1. Download the extension for your version of GeoServer.

                                                                          Warning

                                                                          Make sure to match the version of the extension to the version of GeoServer.

                                                                        2. Extract the archive and copy the contents into the GeoServer WEB-INF/lib directory.

                                                                        3. Restart GeoServer.

                                                                        "},{"location":"extensions/iau/install/#verify-installation","title":"Verify Installation","text":"

                                                                        To verify that the extension was installed successfully:

                                                                        1. On the left menu, get into Demos and then SRS List
                                                                        2. Go into the table filter text field, and type IAU, then press enter
                                                                        3. A number of IAU codes should appear in the table

                                                                        "},{"location":"extensions/iau/usage/","title":"Using IAU authority","text":"

                                                                        Support for the IAU authority required deep changes to the GeoServer code base, as the assumption that the only possible authority is EPSG was widespread.

                                                                        At the time of writing, the following modules support IAU:

                                                                        • GeoTIFF reading and writing (e.g. WCS output)
                                                                        • Shapefile and GeoPackage reading and writing (e.g. WFS output)
                                                                        • PostGIS reading (the spatial_ref_sys table must contain the IAU codes and definitions)
                                                                        • Basic functionality of WMS, WFS, WCS, WPS, OGC API - Features and OGC API - Maps.
                                                                        • GML and GeoJSON outputs, in various versions
                                                                        • The importer module should be able to successfully handle input data in IAU CRSs

                                                                        Other functionality might not be ready, the code base will be improved and generalized as contributions and funding allow.

                                                                        "},{"location":"extensions/importer/","title":"Importer","text":"

                                                                        The Importer extension gives a GeoServer administrator an alternate, more-streamlined method for uploading and configuring new layers.

                                                                        There are two primary advantages to using the Importer over the standard GeoServer data-loading workflow:

                                                                        1. Supports batch operations (loading and publishing multiple spatial files or database tables in one operation)
                                                                        2. Creates unique styles for each layer, rather than linking to the same (existing) styles.

                                                                        This section will discuss the Importer extension.

                                                                        • Installing the Importer extension
                                                                        • Configuring the Importer extension
                                                                        • Using the Importer extension
                                                                        • Importer interface reference
                                                                        • Supported data formats
                                                                        • REST API
                                                                        • Importer REST API examples
                                                                        "},{"location":"extensions/importer/configuring/","title":"Configuring the Importer extension","text":"

                                                                        The importer extension can be used without any explicit configuration, and by default it will:

                                                                        • Stage the REST uploads in a dedicated sub-folder of the data directory (uploads).
                                                                        • Pose no limit to the amount of concurrent imports executed.

                                                                        It is however possible to configure the above using the \"Importer\" entry under the \"Settings\" menu:

                                                                        The importer configuration menu entry

                                                                        The configuration page looks as follows:

                                                                        The importer configuration page

                                                                        +----------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Entry | Description | +========================================+===============================================================================================================================================================================================================================================================================================================================================+ | Upload root | The folder that will hold REST call uploads | +----------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Maximum synchronous jobs | How many synchronous jobs can be run in parallel. Synchronous jobs can only be run via the REST API. | +----------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Maximum asynchronous jobs | How many asynchronous jobs can be run in parallel. Asynchronous jobs can run via the REST API, | | | | | | : and all jobs started from the GUI are asynchronous. | +----------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Maximum asynchronous jobs | How many asynchronous jobs can be run in parallel. Asynchronous jobs can run via the REST API, | | | | | | : and all jobs started from the GUI are asynchronous. | +----------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Completed and stale imports expiration | How many minutes to wait, before removing an import from the database. Imports that are still running are ignored, while completed, errored, or imports that were created, but never started, are going to be considered for cleanup. Value is in minutes, set to zero or negative to never remove values. Defaults to 1440 minutes, one day. | +----------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+

                                                                        "},{"location":"extensions/importer/configuring/#importer-logging","title":"Importer Logging","text":"

                                                                        The importer extension includes a new IMPORTER_LOGGING profile which may be selected in global settings.

                                                                        • This profile is quiet during normal operation (similar to PRODUCTION_LOOGGING)
                                                                        • Provides configuration and information logs on importer activity
                                                                        "},{"location":"extensions/importer/formats/","title":"Supported data formats","text":"

                                                                        The importer supports any format that GeoServer can use a data store or coverage store. These include the most commonly used formats:

                                                                        • Shapefile
                                                                        • GeoTIFF

                                                                        And a few additional formats:

                                                                        • CSV
                                                                        • KML

                                                                        The following databases are supported:

                                                                        • PostGIS
                                                                        • Oracle
                                                                        • Microsoft SQL Server

                                                                        Note

                                                                        Oracle and SQL Server require extra drivers to be installed.

                                                                        • Install instructions for Oracle
                                                                        • Install instructions for SQL Server
                                                                        "},{"location":"extensions/importer/guireference/","title":"Importer interface reference","text":"

                                                                        The Layer Importer user interface is a component of the GeoServer web interface. You can access it from the GeoServer web interface by clicking the Import Data link, found on the left side of the screen after logging in.

                                                                        "},{"location":"extensions/importer/guireference/#data-sources-page","title":"Data sources page","text":"

                                                                        The front page of the Layer Importer is where the data source and format are set. The following options are displayed:

                                                                        "},{"location":"extensions/importer/guireference/#choose-a-data-source-to-import-from","title":"Choose a data source to import from","text":"

                                                                        Select one of the following data sources to use for the import:

                                                                        • Spatial Files (see Supported data formats for more details)
                                                                        • PostGIS database
                                                                        • Oracle database
                                                                        • SQL Server database

                                                                        Choose a data source

                                                                        The contents of the next section is dependent on the data source chosen here.

                                                                        "},{"location":"extensions/importer/guireference/#configure-the-data-source-spatial-files","title":"Configure the data source: Spatial Files","text":"

                                                                        There is a single box for selecting a file or directory. Click the Browse link to bring up a file chooser. To select a file, click on it. To select a directory, click on a directory name to open it and then click OK.

                                                                        Spatial file data source

                                                                        File chooser for selecting spatial files

                                                                        "},{"location":"extensions/importer/guireference/#configure-the-data-source-postgis","title":"Configure the data source: PostGIS","text":"

                                                                        Fill out fields for Connection type (Default or JNDI) Host, Port, Database name, Schema, Username to connect with, and Password.

                                                                        There are also advanced connection options, which are common to the standard PostGIS store loading procedure. (See the PostGIS data store page in the GeoServer reference documentation.)

                                                                        PostGIS data source connection

                                                                        "},{"location":"extensions/importer/guireference/#configure-the-data-source-oracle","title":"Configure the data source: Oracle","text":"

                                                                        The parameter fields for the Oracle import are identical to that of PostGIS. The fields aren't populated with default credentials with the exception of the port, which is set to 1521 by default.

                                                                        Note

                                                                        This option is only enabled if the Oracle extension is installed.

                                                                        Oracle data source connection

                                                                        "},{"location":"extensions/importer/guireference/#configure-the-data-source-sql-server","title":"Configure the data source: SQL Server","text":"

                                                                        The parameter fields for the SQL Server import are identical to that of PostGIS. The fields aren't populated with default credentials with the exception of the port, which is set to 4866 by default.

                                                                        Note

                                                                        This option is only enabled if the SQL Server extension is installed.

                                                                        SQL Server data source connection

                                                                        "},{"location":"extensions/importer/guireference/#specify-the-target-for-the-import","title":"Specify the target for the import","text":"

                                                                        This area specifies where in the GeoServer catalog the new data source will be stored. This does not affect file placement.

                                                                        Select the name of an existing workspace and store.

                                                                        Target workspace and store in GeoServer

                                                                        Alternately, select Create New and type in a names for a new workspace or store. During the import process, these will be created.

                                                                        Creating a new workspace and store

                                                                        "},{"location":"extensions/importer/guireference/#recent-imports","title":"Recent imports","text":"

                                                                        This section will list previous imports, and whether they were successful or not. Items can be removed from this list with the Remove button, but otherwise cannot be edited.

                                                                        Recent imports

                                                                        When ready to continue to the next page, click Next.

                                                                        "},{"location":"extensions/importer/guireference/#layer-listing-page","title":"Layer listing page","text":"

                                                                        On the next page will be a list of layers found by the Layer Importer. The layers will be named according to the source content's name (file name of database table name). For each entry there will be a Status showing if the source is ready to be imported.

                                                                        All layers will be selected for import by default, but can be deselected here by unchecking the box next to each entry.

                                                                        List of layers to be imported

                                                                        A common issue during the import process is when a CRS cannot be determined for a given layer. In this case, a dialog box will display where the CRS can be declared explicitly. Enter the CRS and Click Apply.

                                                                        Declaring a CRS

                                                                        When ready to perform the import, click Import.

                                                                        Each selected layer will be added to the GeoServer catalog inside a new or existing store, and published as a layer.

                                                                        After the import is complete the status area will refresh showing if the import was successful for each layer. If successful, a dialog box for previewing the layer will be displayed, with options for Layer Preview (OpenLayers), Google Earth, and GeoExplorer.

                                                                        Layers successfully imported

                                                                        "},{"location":"extensions/importer/guireference/#advanced-import-settings-page","title":"Advanced import settings page","text":"

                                                                        The Advanced link next to each layer will lead to the Advanced import settings page.

                                                                        On this page, data can be set to be reprojected from one CRS to another during the import process. To enable reprojection, select the Reprojection box, and enter the source and target CRS.

                                                                        In addition, on this page attributes can be renamed and their type changed. Click on the Add link under Attribute Remapping to select the attribute to alter, its type, and its new name. Click Apply when done.

                                                                        Click Save when finished.

                                                                        Advanced layer list page

                                                                        "},{"location":"extensions/importer/installing/","title":"Installing the Importer extension","text":"
                                                                        1. Visit the website download page, locate your release, and download: importer

                                                                          Verify that the version number in the filename (for example 2.24.2 above) corresponds to the version of GeoServer you are running.

                                                                        2. Extract the archive and copy the contents into the GeoServer WEB-INF/lib directory.

                                                                        3. Restart GeoServer.

                                                                        4. To verify that the extension was installed successfully, open the Web administration interface and look for an Import Data option in the Data section on the left-side menu.

                                                                          Importer extension successfully installed.

                                                                        For additional information please see the section on Using the Importer extension.

                                                                        "},{"location":"extensions/importer/rest_examples/","title":"Importer REST API examples","text":""},{"location":"extensions/importer/rest_examples/#mass-configuring-a-directory-of-shapefiles","title":"Mass configuring a directory of shapefiles","text":"

                                                                        In order to initiate an import of the c:\\data\\tasmania directory into the existing tasmania workspace:

                                                                        1. The following JSON will be POSTed to GeoServer.

                                                                          {\n   \"import\": {\n      \"targetWorkspace\": {\n         \"workspace\": {\n            \"name\": \"tasmania\"\n         }\n      },\n      \"data\": {\n        \"type\": \"directory\",\n        \"location\": \"C:/data/tasmania\"\n      }\n   }\n}\n
                                                                        2. This curl command can be used for the purpose:

                                                                        curl -u admin:geoserver -XPOST -H \"Content-type: application/json\" \\\n  -d @import.json \\\n  \"http://localhost:8080/geoserver/rest/imports\"\n

                                                                        The importer will locate the files to be imported, and automatically prepare the tasks, returning the following response:

                                                                        {\n  \"import\": {\n    \"id\": 9,\n    \"href\": \"http://localhost:8080/geoserver/rest/imports/9\",\n    \"state\": \"PENDING\",\n    \"archive\": false,\n    \"targetWorkspace\": {\n      \"workspace\": {\n        \"name\": \"tasmania\"\n      }\n    },\n    \"data\": {\n      \"type\": \"directory\",\n      \"format\": \"Shapefile\",\n      \"location\": \"C:\\\\data\\\\tasmania\",\n      \"href\": \"http://localhost:8080/geoserver/rest/imports/9/data\"\n    },\n    \"tasks\": [\n      {\n        \"id\": 0,\n        \"href\": \"http://localhost:8080/geoserver/rest/imports/9/tasks/0\",\n        \"state\": \"READY\"\n      },\n      {\n        \"id\": 1,\n        \"href\": \"http://localhost:8080/geoserver/rest/imports/9/tasks/1\",\n        \"state\": \"READY\"\n      },\n      {\n        \"id\": 2,\n        \"href\": \"http://localhost:8080/geoserver/rest/imports/9/tasks/2\",\n        \"state\": \"READY\"\n      },\n      {\n        \"id\": 3,\n        \"href\": \"http://localhost:8080/geoserver/rest/imports/9/tasks/3\",\n        \"state\": \"READY\"\n      }\n    ]\n  }\n}\n
                                                                        1. After checking every task is ready, the import can be initiated by executing a POST on the import resource:

                                                                          curl -u admin:geoserver -XPOST \\\n   \"http://localhost:8080/geoserver/rest/imports/9\"\n
                                                                        2. The resource can then be monitored for progress, and eventually final results:

                                                                          curl -u admin:geoserver -XGET \\\n   \"http://localhost:8080/geoserver/rest/imports/9\"\n

                                                                          Which in case of successful import will look like:

                                                                          {\n  \"import\": {\n    \"id\": 9,\n    \"href\": \"http://localhost:8080/geoserver/rest/imports/9\",\n    \"state\": \"COMPLETE\",\n    \"archive\": false,\n    \"targetWorkspace\": {\n      \"workspace\": {\n        \"name\": \"tasmania\"\n      }\n    },\n    \"data\": {\n      \"type\": \"directory\",\n      \"format\": \"Shapefile\",\n      \"location\": \"C:\\\\data\\\\tasmania\",\n      \"href\": \"http://localhost:8080/geoserver/rest/imports/9/data\"\n    },\n    \"tasks\": [\n      {\n        \"id\": 0,\n        \"href\": \"http://localhost:8080/geoserver/rest/imports/9/tasks/0\",\n        \"state\": \"COMPLETE\"\n      },\n      {\n        \"id\": 1,\n        \"href\": \"http://localhost:8080/geoserver/rest/imports/9/tasks/1\",\n        \"state\": \"COMPLETE\"\n      },\n      {\n        \"id\": 2,\n        \"href\": \"http://localhost:8080/geoserver/rest/imports/9/tasks/2\",\n        \"state\": \"COMPLETE\"\n      },\n      {\n        \"id\": 3,\n        \"href\": \"http://localhost:8080/geoserver/rest/imports/9/tasks/3\",\n        \"state\": \"COMPLETE\"\n      }\n    ]\n  }\n} \n
                                                                        "},{"location":"extensions/importer/rest_examples/#configuring-a-shapefile-with-no-projection-information","title":"Configuring a shapefile with no projection information","text":"

                                                                        In this case, let's assume we have a single shapefile, tasmania_cities.shp, that does not have the **.prj** sidecar file (the example is equally good for any case where the **prj`** file contents cannot be matched to an official EPSG code).

                                                                        1. We are going to post the following import definition:

                                                                          {\n   \"import\": {\n      \"targetWorkspace\": {\n         \"workspace\": {\n            \"name\": \"tasmania\"\n         }\n      },\n      \"data\": {\n        \"type\": \"file\",\n        \"file\": \"C:/data/tasmania/tasmania_cities.shp\"\n      }\n   }\n}\n
                                                                        2. With the cURL POST command:

                                                                          curl -u admin:geoserver -XPOST -H \"Content-type: application/json\" \\\n   -d @import.json \\\n   \"http://localhost:8080/geoserver/rest/imports\"\n

                                                                          The response in case the CRS is missing will be:

                                                                          {\n  \"import\": {\n    \"id\": 13,\n    \"href\": \"http://localhost:8080/geoserver/rest/imports/13\",\n    \"state\": \"PENDING\",\n    \"archive\": false,\n    \"targetWorkspace\": {\n      \"workspace\": {\n        \"name\": \"tasmania\"\n      }\n    },\n    \"data\": {\n      \"type\": \"file\",\n      \"format\": \"Shapefile\",\n      \"file\": \"tasmania_cities.shp\"\n    },\n    \"tasks\": [\n      {\n        \"id\": 0,\n        \"href\": \"http://localhost:8080/geoserver/rest/imports/13/tasks/0\",\n        \"state\": \"NO_CRS\"\n      }\n    ]\n  }\n}\n
                                                                        3. Drilling into the task layer:

                                                                          curl -u admin:geoserver -XGET -H \"Content-type: application/json\" \\\n     http://localhost:8080/geoserver/rest/imports/13/tasks/0/layer\n

                                                                          We can see the srs information is missing:

                                                                          {\n  \"layer\": {\n    \"name\": \"tasmania_cities\",\n    \"href\": \"http://localhost:8080/geoserver/rest/imports/13/tasks/0/layer\",\n    \"title\": \"tasmania_cities\",\n    \"originalName\": \"tasmania_cities\",\n    \"nativeName\": \"tasmania_cities\",\n    \"bbox\": {\n      \"minx\": 146.2910004483,\n      \"miny\": -43.85100181689,\n      \"maxx\": 148.2910004483,\n      \"maxy\": -41.85100181689\n    },\n    \"attributes\": [\n      {\n        \"name\": \"the_geom\",\n        \"binding\": \"org.locationtech.jts.geom.MultiPoint\"\n      },\n      {\n        \"name\": \"CITY_NAME\",\n        \"binding\": \"java.lang.String\"\n      },\n      {\n        \"name\": \"ADMIN_NAME\",\n        \"binding\": \"java.lang.String\"\n      },\n      {\n        \"name\": \"CNTRY_NAME\",\n        \"binding\": \"java.lang.String\"\n      },\n      {\n        \"name\": \"STATUS\",\n        \"binding\": \"java.lang.String\"\n      },\n      {\n        \"name\": \"POP_CLASS\",\n        \"binding\": \"java.lang.String\"\n      }\n    ],\n    \"style\": {\n      \"name\": \"tasmania_tasmania_cities2\",\n      \"href\": \"http://localhost:8080/geoserver/rest/imports/13/tasks/0/layer/style\"\n    }\n  }\n}\n
                                                                        4. Use the following json snippet to update the SRS:

                                                                          {\n   layer : {\n      srs: \"EPSG:4326\"\n   }\n}  \n

                                                                          Using cURL PUT command:

                                                                          curl -u admin:geoserver -XPUT -H \"Content-type: application/json\" \\\n  -d @layerUpdate.json \\\n  \"http://localhost:8080/geoserver/rest/imports/13/tasks/0/layer/\"\n
                                                                        5. Getting the import definition again:

                                                                          curl -u admin:geoserver -XGET -H \"Content-type: application/json\" \\\n     http://localhost:8080/geoserver/rest/imports/13/tasks/0\n

                                                                          The import is now ready to execute:

                                                                          {\n  \"import\": {\n    \"id\": 13,\n    \"href\": \"http://localhost:8080/geoserver/rest/imports/13\",\n    \"state\": \"PENDING\",\n    \"archive\": false,\n    \"targetWorkspace\": {\n      \"workspace\": {\n        \"name\": \"tasmania\"\n      }\n    },\n    \"data\": {\n      \"type\": \"file\",\n      \"format\": \"Shapefile\",\n      \"file\": \"tasmania_cities.shp\"\n    },\n    \"tasks\": [\n      {\n        \"id\": 0,\n        \"href\": \"http://localhost:8080/geoserver/rest/imports/13/tasks/0\",\n        \"state\": \"READY\"\n      }\n    ]\n  }\n}\n
                                                                        6. A POST request will execute the import:

                                                                          curl -u admin:geoserver -XPOST \\\n  \"http://localhost:8080/geoserver/rest/imports/13\"\n

                                                                          With a successful import marking the task as COMPLETE:

                                                                          {\n  \"import\": {\n    \"id\": 13,\n    \"href\": \"http://localhost:8080/geoserver/rest/imports/13\",\n    \"state\": \"COMPLETE\",\n    \"archive\": false,\n    \"targetWorkspace\": {\n      \"workspace\": {\n        \"name\": \"tasmania\"\n      }\n    },\n    \"data\": {\n      \"type\": \"file\",\n      \"format\": \"Shapefile\",\n      \"file\": \"tasmania_cities.shp\"\n    },\n    \"tasks\": [\n      {\n        \"id\": 0,\n        \"href\": \"http://localhost:8080/geoserver/rest/imports/13/tasks/0\",\n        \"state\": \"COMPLETE\"\n      }\n    ]\n  }\n}\n
                                                                        "},{"location":"extensions/importer/rest_examples/#uploading-a-shapefile-to-postgis","title":"Uploading a Shapefile to PostGIS","text":"

                                                                        This example shows the process for uploading a Shapefile (in a zip file) to an existing PostGIS datastore (cite:postgis).

                                                                        1. Setup cite:postgis datastore:

                                                                          {\n  \"dataStore\": {\n    \"name\": \"postgis\",\n    \"type\": \"PostGIS\",\n    \"workspace\": {\n      \"name\": \"cite\"\n    },\n    \"connectionParameters\": {\n      \"entry\": [\n        {\"@key\": \"schema\",\"$\": \"public\"},\n        {\"@key\": \"database\",\"$\": \"postgres\"},\n        {\"@key\": \"host\",\"$\": \"localhost\"},\n        {\"@key\": \"port\",\"$\": \"5432\"},\n        {\"@key\": \"passwd\",\"$\": \"postgres\"},\n        {\"@key\": \"dbtype\",\"$\": \"postgis\"},\n        {\"@key\": \"user\",\"$\": \"postgres\"},\n        {\"@key\": \"Estimated extends\",\"$\": \"true\"},\n        {\"@key\": \"encode functions\",\"$\": \"true\"},\n        {\"@key\": \"Loose bbox\",\"$\": \"true\"},\n        {\"@key\": \"Method used to simplify geometries\",\"$\": \"PRESERVETOPOLOGY\"},\n        {\"@key\": \"Support on the fly geometry simplification\",\"$\": \"true\"},\n        {\"@key\": \"validate connections\",\"$\": \"true\"},\n        {\"@key\": \"Connection timeout\",\"$\": \"20\"},\n        {\"@key\": \"min connections\",\"$\": \"1\"},\n        {\"@key\": \"max connections\",\"$\": \"10\"},\n        {\"@key\": \"Evictor tests per run\",\"$\": \"3\"},\n        {\"@key\": \"Test while idle\",\"$\": \"true\"},\n        {\"@key\": \"Max connection idle time\",\"$\": \"300\"}\n      ]\n    },\n    \"_default\": true\n  }\n}\n

                                                                          Using curl POST:

                                                                          curl  -u admin:geoserver -XPOST -H \"Content-type: application/json\" \\\n  -d @postgis.json \\\n  \"http://localhost:8080/geoserver/rest/workspaces/cite/datastores.json\"\n
                                                                        2. Create the import definition:

                                                                          {\n   \"import\": {\n      \"targetWorkspace\": {\n         \"workspace\": {\n            \"name\": \"cite\"\n         }\n      },\n      \"targetStore\": {\n         \"dataStore\": {\n            \"name\": \"postgis\"\n         }\n      }\n   }\n}\n

                                                                          POST this definition to /geoserver/rest/imports:

                                                                          curl -u admin:geoserver -XPOST -H \"Content-type: application/json\" \\\n  -d @import.json \\\n  \"http://localhost:8080/geoserver/rest/imports\"\n

                                                                          The response will contain the import ID.

                                                                        3. We now have an empty import with no tasks. To add a task, POST the shapefile to the list of tasks:

                                                                          curl -u admin:geoserver \\\n  -F name=myshapefile.zip -F filedata=@myshapefile.zip \\\n  \"http://localhost:8080/geoserver/rest/imports/14/tasks\"\n
                                                                        4. Since we sent a shapefile, importer assumes the target will be a shapefile store. To import to PostGIS, we will need to reset it.

                                                                          Create the following JSON file:

                                                                          {\n  \"dataStore\": {\n    \"name\":\"postgis\"\n  }\n}\n

                                                                          PUT this file to /geoserver/rest/imports/14/tasks/0/target:

                                                                          curl -u admin:geoserver -XPUT -H \"Content-type: application/json\" \\\n  -d @target.json \\\n  \"http://localhost:8080/geoserver/rest/imports/14/tasks/0/target\"\n
                                                                        5. Finally, we execute the import by sending a POST to /geoserver/rest/imports/14:

                                                                          curl -u admin:geoserver -XPOST \\\n  \"http://localhost:8080/geoserver/rest/imports/14\"\n
                                                                        "},{"location":"extensions/importer/rest_examples/#uploading-a-csv-file-to-postgis-while-transforming-it","title":"Uploading a CSV file to PostGIS while transforming it","text":"

                                                                        A remote sensing tool is generating CSV files with some locations and measurements, that we want to upload into PostGIS as a new spatial table.

                                                                        1. First, we are going to create a empty import with an existing postgis store as the target:

                                                                          curl -u admin:geoserver -XPOST -H \"Content-type: application/json\" \\\n  -d @import.json \\\n  \"http://localhost:8080/geoserver/rest/imports\"\n

                                                                          Where import.json is:

                                                                          {\n   \"import\": {\n      \"targetWorkspace\": {\n         \"workspace\": {\n            \"name\": \"cite\"\n         }\n      },\n      \"targetStore\": {\n         \"dataStore\": {\n            \"name\": \"postgis\"\n         }\n      }\n   }\n}\n
                                                                        2. Then, we are going to POST the csv file to the tasks list.

                                                                          AssetID, SampleTime, Lat, Lon, Value\n1, 2015-01-01T10:00:00, 10.00, 62.00, 15.2\n1, 2015-01-01T11:00:00, 10.10, 62.11, 30.25\n1, 2015-01-01T12:00:00, 10.20, 62.22, 41.2\n1, 2015-01-01T13:00:00, 10.31, 62.33, 27.6\n1, 2015-01-01T14:00:00, 10.41, 62.45, 12\n

                                                                          In order to create an import task for it:

                                                                          curl -u admin:geoserver -F name=test -F filedata=@values.csv \\\n  \"http://localhost:8080/geoserver/rest/imports/0/tasks\"\n

                                                                          And we are going to get back a new task definition, with a notification that the CRS is missing:

                                                                          {\n  \"task\": {\n    \"id\": 0,\n    \"href\": \"http://localhost:8080/geoserver/rest/imports/0/tasks/0\",\n    \"state\": \"NO_CRS\",\n    \"updateMode\": \"CREATE\",\n    \"data\": {\n      \"type\": \"file\",\n      \"format\": \"CSV\",\n      \"file\": \"values.csv\"\n    },\n    \"target\": {\n      \"href\": \"http://localhost:8080/geoserver/rest/imports/0/tasks/0/target\",\n      \"dataStore\": {\n        \"name\": \"postgis\",\n        \"type\": \"PostGIS\"\n      }\n    },\n    \"progress\": \"http://localhost:8080/geoserver/rest/imports/0/tasks/0/progress\",\n    \"layer\": {\n      \"name\": \"values\",\n      \"href\": \"http://localhost:8080/geoserver/rest/imports/0/tasks/0/layer\"\n    },\n    \"transformChain\": {\n      \"type\": \"vector\",\n      \"transforms\": []\n    }\n  }\n}\n
                                                                        3. Force the CRS by updating the layer:

                                                                          {\n   \"layer\" : {\n      \"srs\": \"EPSG:4326\"\n   }\n}\n

                                                                          Using PUT to update task layer:

                                                                          curl -u admin:geoserver -XPUT -H \"Content-type: application/json\" \\\n  -d @layerUpdate.json \\\n  \"http://localhost:8080/geoserver/rest/imports/0/tasks/0/layer/\"\n

                                                                          Updating the srs:

                                                                          {\n  \"layer\": {\n    \"name\": \"values\",\n    \"href\": \"http://localhost:8080/geoserver/rest/imports/0/tasks/0/layer\",\n    \"title\": \"values\",\n    \"originalName\": \"values\",\n    \"nativeName\": \"values\",\n    \"srs\": \"EPSG:4326\",\n    \"bbox\": {\n      \"minx\": 0,\n      \"miny\": 0,\n      \"maxx\": -1,\n      \"maxy\": -1\n    },\n    \"attributes\": [\n      {\n        \"name\": \"AssetID\",\n        \"binding\": \"java.lang.Integer\"\n      },\n      {\n        \"name\": \"SampleTime\",\n        \"binding\": \"java.lang.String\"\n      },\n      {\n        \"name\": \"Lat\",\n        \"binding\": \"java.lang.Double\"\n      },\n      {\n        \"name\": \"Lon\",\n        \"binding\": \"java.lang.Double\"\n      },\n      {\n        \"name\": \"Value\",\n        \"binding\": \"java.lang.Double\"\n      }\n    ],\n    \"style\": {\n      \"name\": \"point\",\n      \"href\": \"http://localhost:8080/geoserver/rest/imports/0/tasks/0/layer/style\"\n    }\n  }\n}\n
                                                                        4. Then, we are going to create a transformation mapping the Lat/Lon columns to a point:

                                                                          {\n  \"type\": \"AttributesToPointGeometryTransform\",\n  \"latField\": \"Lat\",\n  \"lngField\": \"Lon\"\n}\n

                                                                          The above will be uploaded task transforms:

                                                                          curl -u admin:geoserver -XPOST -H \"Content-type: application/json\" \\\n  -d @toPoint.json \\\n  \"http://localhost:8080/geoserver/rest/imports/0/tasks/0/transforms\"\n
                                                                        5. Now the import is ready to run, and we'll execute it using:

                                                                          curl -u admin:geoserver -XPOST \\\n  \"http://localhost:8080/geoserver/rest/imports/0\"\n
                                                                        6. The new layer is created in PostGIS and registered in GeoServer as a new layer.

                                                                          In case the features in the CSV need to be appended to an existing layer a PUT request against the task might be performed, changing its updateMode from \"CREATE\" to \"APPEND\". Changing it to \"REPLACE\" instead will preserve the layer, but remove the old contents and replace them with the newly uploaded ones.

                                                                        "},{"location":"extensions/importer/rest_examples/#replacing-postgis-table-using-the-contents-of-a-csv-file","title":"Replacing PostGIS table using the contents of a CSV file","text":"

                                                                        To update the values layer with new content:

                                                                        1. Create a new import into cite:postgis:

                                                                          curl -u admin:geoserver -XPOST -H \"Content-type: application/json\" \\\n  -d @import.json \"http://localhost:8080/geoserver/rest/imports\"\n

                                                                          Using:

                                                                          {\n   \"import\": {\n      \"targetWorkspace\": {\n         \"workspace\": {\n            \"name\": \"cite\"\n         }\n      },\n      \"targetStore\": {\n         \"dataStore\": {\n            \"name\": \"postgis\"\n         }\n      }\n   }\n}\n
                                                                        2. Use replace.csv to create a new task:

                                                                          curl -u admin:geoserver -XPOST \\\n  -F filedata=@replace.csv \\\n  \"http://localhost:8080/geoserver/rest/imports/1/tasks\"\n

                                                                          The csv file has an additional column:

                                                                          AssetID, SampleTime, Lat, Lon, Value, Status\n1, 2015-01-01T10:00:00, 10.00, 62.00, 15.2, ready\n1, 2015-01-01T11:00:00, 10.10, 62.11, 30.25, recording\n1, 2015-01-01T12:00:00, 10.20, 62.22, 41.2, recording\n1, 2015-01-01T13:00:00, 10.31, 62.33, 27.6, recording\n1, 2015-01-01T14:00:00, 10.41, 62.45, 12, complete\n
                                                                        3. Update task with as a \"REPLACE\" and supply srs information:

                                                                          curl -u admin:geoserver -XPUT -H \"Content-type: application/json\" \\\n  -d @taskUpdate.json \\\n  \"http://localhost:8080/geoserver/rest/imports/1/tasks/0\"\n

                                                                          Using:

                                                                          {\n   \"task\": {\n       \"updateMode\": \"REPLACE\",\n       \"layer\" : {\n          \"name\": \"values\",\n          \"title\": \"values\",\n          \"nativeName\": \"values\",\n          \"srs\": \"EPSG:4326\"\n       }\n   }\n}\n
                                                                        4. Update transform to supply a geometry column:

                                                                          curl -u admin:geoserver -XPOST -H \"Content-type: application/json\" \\\n  -d @toPoint.json \\\n  \"http://localhost:8080/geoserver/rest/imports/1/tasks/0/transforms\"\n

                                                                          Using:

                                                                          {\n  \"type\": \"AttributesToPointGeometryTransform\",\n  \"latField\": \"Lat\",\n  \"lngField\": \"Lon\"\n}\n
                                                                        5. Double check import:

                                                                          curl -u admin:geoserver -XGET \\\n  http://localhost:8080/geoserver/rest/imports/1.json\n
                                                                          {\n  \"import\": {\n    \"id\": 2,\n    \"href\": \"http://localhost:8080/geoserver/rest/imports/1\",\n    \"state\": \"PENDING\",\n    \"archive\": false,\n    \"targetWorkspace\": {\n      \"workspace\": {\n        \"name\": \"cite\",\n        \"isolated\": false\n      }\n    },\n    \"targetStore\": {\n      \"dataStore\": {\n        \"name\": \"postgis\",\n        \"type\": \"PostGIS\"\n      }\n    },\n    \"tasks\": [\n      {\n        \"id\": 0,\n        \"href\": \"http://localhost:8080/geoserver/rest/imports/1/tasks/0\",\n        \"state\": \"READY\"\n      }\n    ]\n  }\n}\n

                                                                          Task:

                                                                          curl -u admin:geoserver -XGET \\\n  http://localhost:8080/geoserver/rest/imports/1/tasks/0.json\n
                                                                          {\n  \"task\": {\n    \"id\": 0,\n    \"href\": \"http://localhost:8080/geoserver/rest/imports/2/tasks/0\",\n    \"state\": \"READY\",\n    \"updateMode\": \"REPLACE\",\n    \"data\": {\n      \"type\": \"file\",\n      \"format\": \"CSV\",\n      \"file\": \"replace.csv\"\n    },\n    \"target\": {\n      \"href\": \"http://localhost:8080/geoserver/rest/imports/2/tasks/0/target\",\n      \"dataStore\": {\n        \"name\": \"postgis\",\n        \"type\": \"PostGIS\"\n      }\n    },\n    \"progress\": \"http://localhost:8080/geoserver/rest/imports/2/tasks/0/progress\",\n    \"layer\": {\n      \"name\": \"replace\",\n      \"href\": \"http://localhost:8080/geoserver/rest/imports/2/tasks/0/layer\"\n    },\n    \"transformChain\": {\n      \"type\": \"vector\",\n      \"transforms\": [\n        {\n          \"type\": \"AttributesToPointGeometryTransform\",\n          \"href\": \"http://localhost:8080/geoserver/rest/imports/2/tasks/0/transforms/0\"\n        }\n      ]\n    }\n  }\n}\n

                                                                          Check layer to ensure name indicates layer to replace, and nativeName indicates the table contents to replace:

                                                                          curl -u admin:geoserver -XGET \\\n  http://localhost:8080/geoserver/rest/imports/1/tasks/0/layer.json\n
                                                                          {\n  \"layer\": {\n    \"name\": \"values\",\n    \"href\": \"http://localhost:8080/geoserver/rest/imports/1/tasks/0/layer\",\n    \"title\": \"values\",\n    \"originalName\": \"replace\",\n    \"nativeName\": \"replace\",\n    \"srs\": \"EPSG:4326\",\n    \"bbox\": {\n      \"minx\": 0,\n      \"miny\": 0,\n      \"maxx\": -1,\n      \"maxy\": -1\n    },\n    \"attributes\": [\n      {\n        \"name\": \"AssetID\",\n        \"binding\": \"java.lang.Integer\"\n      },\n      {\n        \"name\": \"SampleTime\",\n        \"binding\": \"java.lang.String\"\n      },\n      {\n        \"name\": \"Lat\",\n        \"binding\": \"java.lang.Double\"\n      },\n      {\n        \"name\": \"Lon\",\n        \"binding\": \"java.lang.Double\"\n      },\n      {\n        \"name\": \"Value\",\n        \"binding\": \"java.lang.Integer\"\n      }\n    ],\n    \"style\": {\n      \"name\": \"point\",\n      \"href\": \"http://localhost:8080/geoserver/rest/imports/1/tasks/0/layer/style\"\n    }\n  }\n}\n

                                                                          Transform:

                                                                          curl -u admin:geoserver -XGET \\\n  http://localhost:8080/geoserver/rest/imports/1/tasks/0/transforms/0.json\n
                                                                        6. To run the import:

                                                                          curl -u admin:geoserver -XPOST \\\n  \"http://localhost:8080/geoserver/rest/imports/1\"\n
                                                                        "},{"location":"extensions/importer/rest_examples/#uploading-and-optimizing-a-geotiff-with-ground-control-points","title":"Uploading and optimizing a GeoTiff with ground control points","text":"

                                                                        A data supplier is periodically providing GeoTiffs that we need to configure in GeoServer. The GeoTIFF is referenced via Ground Control Points, is organized by stripes, and has no overviews. The objective is to rectify, optimize and publish it via the importer.

                                                                        First, we are going to create a empty import with no store as the target:

                                                                        curl -u admin:geoserver -XPOST -H \"Content-type: application/json\" -d @import.json \"http://localhost:8080/geoserver/rest/imports\"\n

                                                                        Where import.json is:

                                                                        {\n   \"import\": {\n      \"targetWorkspace\": {\n         \"workspace\": {\n            \"name\": \"sf\"\n         }\n      }\n   }\n}\n

                                                                        Then, we are going to POST the GeoTiff file to the tasks list, in order to create an import task for it:

                                                                        curl -u admin:geoserver -F name=test -F filedata=@box_gcp_fixed.tif \"http://localhost:8080/geoserver/rest/imports/0/tasks\"\n

                                                                        We are then going to append the transformations to rectify (gdalwarp), retile (gdal_translate) and add overviews (gdaladdo) to it:

                                                                        curl -u admin:geoserver -XPOST -H \"Content-type: application/json\" -d @warp.json \"http://localhost:8080/geoserver/rest/imports/0/tasks/0/transforms\"\ncurl -u admin:geoserver -XPOST -H \"Content-type: application/json\" -d @gtx.json \"http://localhost:8080/geoserver/rest/imports/0/tasks/0/transforms\"\ncurl -u admin:geoserver -XPOST -H \"Content-type: application/json\" -d @gad.json \"http://localhost:8080/geoserver/rest/imports/0/tasks/0/transforms\"\n

                                                                        warp.json is:

                                                                        {\n  \"type\": \"GdalWarpTransform\",\n  \"options\": [ \"-t_srs\", \"EPSG:4326\"]\n}\n

                                                                        gtx.json is:

                                                                        {\n  \"type\": \"GdalTranslateTransform\",\n  \"options\": [ \"-co\", \"TILED=YES\", \"-co\", \"BLOCKXSIZE=512\", \"-co\", \"BLOCKYSIZE=512\"]\n}\n

                                                                        gad.json is:

                                                                        {\n  \"type\": \"GdalAddoTransform\",\n  \"options\": [ \"-r\", \"average\"],\n  \"levels\" : [2, 4, 8, 16]\n}\n

                                                                        Now the import is ready to run, and we'll execute it using:

                                                                        curl -u admin:geoserver -XPOST \"http://localhost:8080/geoserver/rest/imports/0\"\n

                                                                        A new layer box_gcp_fixed layer will appear in GeoServer, with an underlying GeoTiff file ready for web serving.

                                                                        "},{"location":"extensions/importer/rest_examples/#adding-a-new-granule-into-an-existing-mosaic","title":"Adding a new granule into an existing mosaic","text":"

                                                                        A data supplier is periodically providing new time based imagery that we need to add into an existing mosaic in GeoServer. The imagery is in GeoTiff format, and lacks a good internal structure, which needs to be aligned with the one into the other images.

                                                                        First, we are going to create a import with an indication of where the granule is located, and the target store:

                                                                        curl -u admin:geoserver -XPOST -H \"Content-type: application/json\" -d @import.json \"http://localhost:8080/geoserver/rest/imports\"

                                                                        Where import.json is:

                                                                        {\n   \"import\": {\n      \"targetWorkspace\": {\n         \"workspace\": {\n            \"name\": \"topp\"\n         }\n      },\n      \"data\": {\n        \"type\": \"file\",\n        \"file\": \"/home/aaime/devel/gisData/ndimensional/data/world/world.200407.3x5400x2700.tiff\"\n      },\n      \"targetStore\": {\n         \"dataStore\": {\n            \"name\": \"bluemarble\"\n         }\n      }\n   }\n}\n

                                                                        We are then going to append the transformations to harmonize the file with the rest of the mosaic:

                                                                        curl -u admin:geoserver -XPOST -H \"Content-type: application/json\" -d @gtx.json \"http://localhost:8080/geoserver/rest/imports/0/tasks/0/transforms\"\ncurl -u admin:geoserver -XPOST -H \"Content-type: application/json\" -d @gad.json \"http://localhost:8080/geoserver/rest/imports/0/tasks/0/transforms\"\n

                                                                        gtx.json is:

                                                                        {\n  \"type\": \"GdalTranslateTransform\",\n  \"options\": [ \"-co\", \"TILED=YES\"]\n}\n

                                                                        gad.json is:

                                                                        {\n  \"type\": \"GdalAddoTransform\",\n  \"options\": [ \"-r\", \"average\"],\n  \"levels\" : [2, 4, 8, 16, 32, 64, 128]\n}\n

                                                                        Now the import is ready to run, and we'll execute it using:

                                                                        curl -u admin:geoserver -XPOST \"http://localhost:8080/geoserver/rest/imports/0\"\n

                                                                        The new granule will be ingested into the mosaic, and will thus be available for time based requests.

                                                                        "},{"location":"extensions/importer/rest_examples/#asynchronously-fetching-and-importing-data-from-a-remote-server","title":"Asynchronously fetching and importing data from a remote server","text":"

                                                                        We assume a remote FTP server contains multiple shapefiles that we need to import in GeoServer as new layers. The files are large, and the server has much better bandwidth than the client, so it's best if GeoServer performs the data fetching on its own.

                                                                        In this case a asynchronous request using remote data will be the best fit:

                                                                        curl -u admin:geoserver -XPOST -H \"Content-type: application/json\" -d @import.json \"http://localhost:8080/geoserver/rest/imports?async=true\"\n

                                                                        Where import.json is:

                                                                        {\n   \"import\": {\n      \"targetWorkspace\": {\n         \"workspace\": {\n            \"name\": \"topp\"\n         }\n      },\n      \"data\": {\n        \"type\": \"remote\",\n        \"location\": \"ftp://myserver/data/bc_shapefiles\",\n        \"username\": \"dan\",\n        \"password\": \"secret\"\n      }\n   }\n}\n

                                                                        The request will return immediately with an import context in \"INIT\" state, and it will remain in such state until the data is fetched and the tasks created. Once the state switches to \"PENDING\" the import will be ready for execution. Since there is a lot of shapefiles to process, also the import run will be done in asynchronous mode:

                                                                        curl -u admin:geoserver -XPOST \"http://localhost:8080/geoserver/rest/imports/0?async=true\"\n

                                                                        The response will return immediately in this case as well, and the progress can be followed as the tasks in the import switch state.

                                                                        "},{"location":"extensions/importer/rest_examples/#importing-and-optimizing-a-large-image-with-a-single-request","title":"Importing and optimizing a large image with a single request","text":"

                                                                        A large image appears every now and then on a mounted disk share, the image needs to be optimized and imported into GeoServer as a new layer. Since the source is large and we need to copy it on the local disk where the data dir resides, a \"remote\" data is the right tool for the job, an asynchronous execution is also recommended to avoid waiting on a possibly large command. In this case the request will also contains the \"exec=true\" parameter to force the importer an immediate execution of the command.

                                                                        The request will then look as follows:

                                                                        curl -u admin:geoserver -XPOST -H \"Content-type: application/json\" -d @import.json \"http://localhost:8080/geoserver/rest/imports?async=true&exec=true\"\n

                                                                        Where import.json is:

                                                                        {\n  \"import\": {\n    \"targetWorkspace\": {\n      \"workspace\": {\n        \"name\": \"topp\"\n      }\n    },\n    \"data\": {\n      \"type\": \"remote\",\n      \"location\": \"\\/mnt\\/remoteDisk\\/bluemarble.tiff\"\n    },\n    \"transforms\": [\n      {\n        \"type\": \"GdalTranslateTransform\",\n        \"options\": [\n          \"-co\", \"TILED=YES\",\n          \"-co\", \"COMPRESS=JPEG\",\n          \"-co\", \"JPEG_QUALITY=85\",\n          \"-co\", \"PHOTOMETRIC=YCBCR\"\n        ]\n      },\n      {\n        \"type\": \"GdalAddoTransform\",\n        \"options\": [\n          \"-r\",\n          \"average\",\n          \"--config\", \"COMPRESS_OVERVIEW\", \"JPEG\",\n          \"--config\", \"PHOTOMETRIC_OVERVIEW\", \"YCBCR\"\n        ],\n        \"levels\": [ 2, 4, 8, 16, 32, 64 ]\n      }\n    ]\n  }\n}\n

                                                                        Given the request is asynchronous, the client will have to poll the server in order to check if the initialization and execution have succeeded.

                                                                        "},{"location":"extensions/importer/rest_reference/","title":"REST API","text":""},{"location":"extensions/importer/rest_reference/#importer-concepts","title":"Importer concepts","text":"

                                                                        The importer REST api is built around a tree of objects representing a single import, structured as follows:

                                                                        • import
                                                                          • target workspace
                                                                          -   data\n\n-\n\n    task (one or more)\n\n    :   -   data\n        -   layer\n        -   transformation (one or more)\n

                                                                        An import refers to the top level object and is a \"session\" like entity the state of the entire import. It maintains information relevant to the import as a whole such as user information, timestamps along with optional information that is uniform along all tasks, such as a target workspace, the shared input data (e.g., a directory, a database). An import is made of any number of task objects.

                                                                        A data is the description of the source data of a import (overall) or a task. In case the import has a global data definition, this normally refers to an aggregate store such as a directory or a database, and the data associated to the tasks refers to a single element inside such aggregation, such as a single file or table.

                                                                        A task represents a unit of work to the importer needed to register one new layer, or alter an existing one, and contains the following information:

                                                                        • The data being imported
                                                                        • The target store that is the destination of the import
                                                                        • The target layer
                                                                        • The data of a task, referred to as its source, is the data to be processed as part of the task.
                                                                        • The transformations that we need to apply to the data before it gets imported

                                                                        This data comes in a variety of forms including:

                                                                        • A spatial file (Shapefile, GeoTiff, KML, etc...)
                                                                        • A directory of spatial files
                                                                        • A table in a spatial database
                                                                        • A remote location that the server will download data from

                                                                        A task is classified as either \"direct\" or \"indirect\". A direct task is one in which the data being imported requires no transformation to be imported. It is imported directly. An example of such a task is one that involves simply importing an existing Shapefile as is. An indirect task is one that does require a transformation to the original import data. An example of an indirect task is one that involves importing a Shapefile into an existing PostGIS database. Another example of indirect task might involve taking a CSV file as an input, turning a x and y column into a Point, remapping a string column into a timestamp, and finally import the result into a PostGIS.

                                                                        "},{"location":"extensions/importer/rest_reference/#rest-api-reference","title":"REST API Reference","text":""},{"location":"extensions/importer/rest_reference/#all-the-imports","title":"All the imports","text":""},{"location":"extensions/importer/rest_reference/#imports","title":"/imports","text":"Method Action Status Code/Headers Input Output Parameters GET Retrieve all imports 200 n/a Import Collection n/a POST Create a new import 201 with Location header n/a Imports async=false/true,execute=false/true"},{"location":"extensions/importer/rest_reference/#retrieving-the-list-of-all-imports","title":"Retrieving the list of all imports","text":"
                                                                        GET /imports     \n

                                                                        results in:

                                                                        Status: 200 OK\nContent-Type: application/json\n\n    {\n       \"imports\": [{\n         \"id\": 0,\n         \"state\": \"COMPLETE\",\n         \"href\": \"http://localhost:8080/geoserver/rest/imports/0\"\n\n       }, {\n         \"id\": 1,\n         \"state\": \"PENDING\",\n         \"href\": \"http://localhost:8080/geoserver/rest/imports/1\"          \n       }]\n    }\n
                                                                        "},{"location":"extensions/importer/rest_reference/#creating-a-new-import","title":"Creating a new import","text":"

                                                                        Posting to the /imports path a import json object creates a new import session:

                                                                        Content-Type: application/json\n\n{\n   \"import\": {\n      \"targetWorkspace\": {\n         \"workspace\": {\n            \"name\": \"scratch\"\n         }\n      },\n      \"targetStore\": {\n         \"dataStore\": {\n            \"name\": \"shapes\"\n         }\n      },\n      \"data\": {\n        \"type\": \"file\",\n        \"file\": \"/data/spearfish/archsites.shp\"\n      }\n   }\n}\n

                                                                        The parameters are:

                                                                        Name Optional Description targetWorkspace Y The target workspace to import to targetStore Y The target store to import to data Y The data to be imported

                                                                        The mere creation does not start the import, but it may automatically populate its tasks depending on the target. For example, by referring a directory of shapefiles to be importer, the creation will automatically fill in a task to import each of the shapefiles as a new layer.

                                                                        The response to the above POST request will be:

                                                                        Status: 201 Created\nLocation: http://localhost:8080/geoserver/rest/imports/2\nContent-Type: application/json\n\n{  \n  \"import\": {\n    \"id\": 2, \n    \"href\": \"http://localhost:8080/geoserver/rest/imports/2\", \n    \"state\": \"READY\", \n    \"targetWorkspace\": {\n      \"workspace\": {\n        \"name\": \"scratch\"\n      }\n    }, \n    \"targetStore\": {\n      \"dataStore\": {\n        \"name\": \"shapes\", \n        \"type\": \"PostGIS\"\n      }\n    }, \n    \"data\": {\n      \"type\": \"file\", \n      \"format\": \"Shapefile\", \n      \"href\": \"http://localhost:8080/geoserver/rest/imports/2/data\", \n      \"file\": \"archsites.shp\"\n    }, \n    \"tasks\": [\n      {\n        \"id\": 0, \n        \"href\": \"http://localhost:8080/geoserver/rest/imports/2/tasks/0\", \n        \"state\": \"READY\"\n      }\n    ]\n  }\n}\n

                                                                        The operation of populating the tasks can require time, especially if done against a large set of files, or against a \"remote\" data (more on this later), in this case the POST request can include ?async=true at the end of the URL to make the importer run it asynchronously. In this case the import will be created in INIT state and will remain in such state until all the data transfer and task creation operations are completed. In case of failure to fetch data the import will immediately stop, the state will switch to the INIT_ERROR state, and a error message will appear in the import context \"message\" field.

                                                                        Adding the \"execute=true\" parameter to the context creation will also make the import start immediately, assuming tasks can be created during the init phase. Combining both execute and async, \"?async=true&execute=true\" will make the importer start an asynchronous initialization and execution.

                                                                        The import can also have a list of default transformations, that will be applied to tasks as they get created, either out of the initial data, or by upload. Here is an example of a import context creation with a default transformation:

                                                                        {\n  \"import\": {\n    \"targetWorkspace\": {\n      \"workspace\": {\n        \"name\": \"topp\"\n      }\n    },\n    \"data\": {\n      \"type\": \"file\",\n      \"file\": \"/tmp/locations.csv\"\n    },\n    \"targetStore\": {\n      \"dataStore\": {\n        \"name\": \"h2\"\n      }\n    },\n    \"transforms\": [\n      {\n        \"type\": \"AttributesToPointGeometryTransform\",\n        \"latField\": \"LAT\",\n        \"lngField\": \"LON\"\n      }\n    ]\n  }\n}\n

                                                                        To get more information about transformations see the Transformation reference.

                                                                        "},{"location":"extensions/importer/rest_reference/#import-object","title":"Import object","text":""},{"location":"extensions/importer/rest_reference/#imports_1","title":"/imports/ Method Action Status Code/Headers Input Output Parameters GET Retrieve import with id 200 n/a Imports n/a POST Execute import with id 204 n/a n/a async=true/false PUT Create import with proposed id . If the proposed id is ahead of the current (next) id, the current id will be advanced. If the proposed id is less than or equal to the current id, the current will be used. This allows an external system to dictate the id management. 201 with Location header n/a Imports n/a DELETE Remove import with id 200 n/a n/a n/a

                                                                        The representation of a import is the same as the one contained in the import creation response. The execution of a import can be a long task, as such, it's possible to add async=true to the request to make it run in an asynchronous fashion, the client will have to poll the import representation and check when it reaches either the \"COMPLETE\" or \"COMPLETE_ERROR\" state.

                                                                        ","text":""},{"location":"extensions/importer/rest_reference/#data","title":"Data","text":"

                                                                        A import can have a \"data\" representing the source of the data to be imported. The data can be of different types, in particular, \"file\", \"directory\", \"mosaic\", \"database\" and \"remote\". During the import initialization the importer will scan the contents of said resource, and generate import tasks for each data found in it.

                                                                        Most data types are discussed in the task section, the only type that's specific to the whole import context is the \"remote\" one, that is used to ask the importer to fetch the data from a remote location autonomusly, without asking the client to perform an upload.

                                                                        The representation of a remote resource looks as follows:

                                                                        \"data\": {\n  \"type\": \"remote\",\n  \"location\": \"ftp://fthost/path/to/importFile.zip\",\n  \"username\": \"user\",\n  \"password\": \"secret\",\n  \"domain\" : \"mydomain\"\n}\n

                                                                        The location can be any URI supported by Commons VFS, including HTTP and FTP servers. The username, password and domain elements are all optional, and required only if the remote server demands an authentication of sorts. In case the referred file is compressed, it will be unpacked as the download completes, and the tasks will be created over the result of unpacking.

                                                                        "},{"location":"extensions/importer/rest_reference/#tasks","title":"Tasks","text":""},{"location":"extensions/importer/rest_reference/#importstasks","title":"/imports//tasks Method Action Status Code/Headers Input Output GET Retrieve all tasks for import with id 200 n/a Task Collection POST Create a new task 201 with Location header Multipart form data Tasks","text":""},{"location":"extensions/importer/rest_reference/#file_upload","title":"Getting the list of tasks
                                                                        GET /imports/0/tasks\n

                                                                        Results in:

                                                                        Status: 200 OK\nContent-Type: application/json\n\n{\n  \"tasks\": [\n    {\n      \"id\": 0, \n      \"href\": \"http://localhost:8080/geoserver/rest/imports/2/tasks/0\", \n      \"state\": \"READY\"\n    }\n  ]\n}\n
                                                                        ","text":""},{"location":"extensions/importer/rest_reference/#creating-a-new-task-as-a-file-upload","title":"Creating a new task as a file upload

                                                                        A new task can be created by issuing a POST to imports/<importId>/tasks as a \"Content-type: multipart/form-data\" multipart encoded data as defined by RFC 2388. One or more file can be uploaded this way, and a task will be created for importing them. In case the file being uploaded is a zip file, it will be unzipped on the server side and treated as a directory of files.

                                                                        The response to the upload will be the creation of a new task, for example:

                                                                        Status: 201 Created\nLocation: http://localhost:8080/geoserver/rest/imports/1/tasks/1\nContent-type: application/json\n\n{\n  \"task\": {\n    \"id\": 1, \n    \"href\": \"http://localhost:8080/geoserver/rest/imports/2/tasks/1\", \n    \"state\": \"READY\",\n    \"updateMode\": \"CREATE\", \n    \"data\": {\n      \"type\": \"file\", \n      \"format\": \"Shapefile\", \n      \"href\": \"http://localhost:8080/geoserver/rest/imports/2/tasks/1/data\", \n      \"file\": \"bugsites.shp\"\n    }, \n    \"target\": {\n      \"href\": \"http://localhost:8080/geoserver/rest/imports/2/tasks/1/target\", \n      \"dataStore\": {\n        \"name\": \"shapes\", \n        \"type\": \"PostGIS\"\n      }\n    },\n    \"progress\": \"http://localhost:8080/geoserver/rest/imports/2/tasks/1/progress\", \n    \"layer\": {\n      \"name\": \"bugsites\", \n      \"href\": \"http://localhost:8080/geoserver/rest/imports/2/tasks/1/layer\"\n    }, \n    \"transformChain\": {\n      \"type\": \"vector\", \n      \"transforms\": []\n    }\n  }\n}\n
                                                                        ","text":""},{"location":"extensions/importer/rest_reference/#creating-a-new-task-from-form-upload","title":"Creating a new task from form upload

                                                                        This creation mode assumes the POST to imports/<importId>/tasks of form url encoded data containing a url parameter:

                                                                        Content-type: application/x-www-form-urlencoded\n\nurl=file:///data/spearfish/\n

                                                                        The creation response will be the same as the multipart upload.

                                                                        ","text":""},{"location":"extensions/importer/rest_reference/#single-task-resource","title":"Single task resource","text":""},{"location":"extensions/importer/rest_reference/#importstasks_1","title":"/imports//tasks/ Method Action Status Code/Headers Input Output GET Retrieve task with id within import with id 200 n/a Task PUT Modify task with id within import with id 200 Task Task DELETE Remove task with id within import with id 200 n/a n/a

                                                                        The representation of a task resource is the same one reported in the task creation response.

                                                                        ","text":""},{"location":"extensions/importer/rest_reference/#updating-a-task","title":"Updating a task

                                                                        A PUT request over an existing task can be used to update its representation. The representation can be partial, and just contains the elements that need to be updated.

                                                                        The updateMode of a task may have different values.

                                                                        UpdateMode Description CREATE This is the default starting updateMode of a task, that is: create the target resource if missing. REPLACE For vector stores: delete the existing features in the target layer and replace them with those from the task source. For raster stores: replace the underlying data. When dealing with StructuredGridCoverage reader (e.g. ImageMosaic) the new file will be harvested (replacing the old one). For single raster coverages (e.g. GeoTIFF) the name of the file should be the same so that the coverageStore layer will preserve the original name (the old file will be deleted). APPEND Add the features from the task source into an existing layer.

                                                                        The following PUT request updates a task from \"CREATE\" to \"APPEND\" mode:

                                                                        Content-Type: application/json\n\n{\n  \"task\": {\n     \"updateMode\": \"APPEND\"\n  }\n}\n
                                                                        ","text":""},{"location":"extensions/importer/rest_reference/#directory-files-representation","title":"Directory files representation","text":"

                                                                        The following operations are specific to data objects of type directory.

                                                                        "},{"location":"extensions/importer/rest_reference/#importstasksdatafiles","title":"/imports//tasks//data/files Method Action Status Code/Headers Input Output GET Retrieve the list of files for a task with id within import with id 200 n/a Task

                                                                        The response to a GET request will be:

                                                                        Status: 200 OK\nContent-Type: application/json\n\n{\n    files: [\n        {\n        file: \"tasmania_cities.shp\",\n        href: \"http://localhost:8080/geoserver/rest/imports/0/tasks/0/data/files/tasmania_cities.shp\"\n        },\n        {\n        file: \"tasmania_roads.shp\",\n        href: \"http://localhost:8080/geoserver/rest/imports/0/tasks/0/data/files/tasmania_roads.shp\"\n        },\n        {\n        file: \"tasmania_state_boundaries.shp\",\n        href: \"http://localhost:8080/geoserver/rest/imports/0/tasks/0/data/files/tasmania_state_boundaries.shp\"\n        },\n        {\n        file: \"tasmania_water_bodies.shp\",\n        href: \"http://localhost:8080/geoserver/rest/imports/0/tasks/0/data/files/tasmania_water_bodies.shp\"\n        }\n    ]\n}\n
                                                                        ","text":""},{"location":"extensions/importer/rest_reference/#importstasksdatafiles_1","title":"/imports//tasks//data/files/ Method Action Status Code/Headers Input Output GET Retrieve the file with id from the data of a task with id within import with id 200 n/a Task DELETE Remove a specific file from the task with id within import with id 200 n/a n/a

                                                                        Following the links we'll get to the representation of a single file, notice how in this case a main file can be associate to sidecar files:

                                                                        Status: 200 OK\nContent-Type: application/json\n\n{\n    type: \"file\",\n    format: \"Shapefile\",\n    location: \"C:\\devel\\gs_data\\release\\data\\taz_shapes\",\n    file: \"tasmania_cities.shp\",\n    href: \"http://localhost:8080/geoserver/rest/imports/0/tasks/0/data/files/tasmania_cities.shp\",\n    prj: \"tasmania_cities.prj\",\n    other: [\n        \"tasmania_cities.dbf\",\n        \"tasmania_cities.shx\"\n    ]\n}\n
                                                                        ","text":""},{"location":"extensions/importer/rest_reference/#mosaic-extensions","title":"Mosaic extensions

                                                                        In case the input data is of mosaic type, we have all the attributes typical of a directory, plus support for directly specifying the timestamp of a particular granule.

                                                                        In order to specify the timestamp a PUT request can be issued against the granule:

                                                                        Content-Type: application/json\n\n{\n   \"timestamp\": \"2004-01-01T00:00:00.000+0000\"\n}\n

                                                                        and the response will be:

                                                                        Status: 200 OK\nContent-Type: application/json\n\n{\n  \"type\": \"file\", \n  \"format\": \"GeoTIFF\", \n  \"href\": \"http://localhost:8080/geoserver/rest/imports/0/tasks/0/data/files/bm_200401.tif\", \n  \"location\": \"/data/bluemarble/mosaic\", \n  \"file\": \"bm_200401.tiff\", \n  \"prj\": null, \n  \"other\": [], \n  \"timestamp\": \"2004-01-01T00:00:00.000+0000\"\n}\n
                                                                        ","text":""},{"location":"extensions/importer/rest_reference/#database-data","title":"Database data","text":"

                                                                        The following operations are specific to data objects of type database. At the time or writing, the REST API does not allow the creation of a database data source, but it can provide a read only description of one that has been created using the GUI.

                                                                        "},{"location":"extensions/importer/rest_reference/#importstasksdata","title":"/imports//tasks//data Method Action Status Code/Headers Input Output GET Retrieve the database connection parameters for a task with id within import with id 200 n/a List of database connection parameters and available tables

                                                                        Performing a GET on a database type data will result in the following response:

                                                                        {\n    type: \"database\",\n    format: \"PostGIS\",\n    href: \"http://localhost:8080/geoserver/rest/imports/0/data\",\n    parameters: {\n        schema: \"public\",\n        fetch size: 1000,\n        validate connections: true,\n        Connection timeout: 20,\n        Primary key metadata table: null,\n        preparedStatements: true,\n        database: \"gttest\",\n        port: 5432,\n        passwd: \"cite\",\n        min connections: 1,\n        dbtype: \"postgis\",\n        host: \"localhost\",\n        Loose bbox: true,\n        max connections: 10,\n        user: \"cite\"\n    },\n    tables: [\n        \"geoline\",\n        \"geopoint\",\n        \"lakes\",\n        \"line3d\",\n    ]\n}\n
                                                                        ","text":""},{"location":"extensions/importer/rest_reference/#database-table","title":"Database table","text":"

                                                                        The following operations are specific to data objects of type table. At the time or writing, the REST API does not allow the creation of a database data source, but it can provide a read only description of one that has been created using the GUI. A table description is normally linked to task, and refers to a database data linked to the overall import.

                                                                        "},{"location":"extensions/importer/rest_reference/#importstasksdata_1","title":"/imports//tasks//data Method Action Status Code/Headers Input Output GET Retrieve the table description for a task with id within import with id 200 n/a A table representation

                                                                        Performing a GET on a database type data will result in the following response:

                                                                        {\n    type: \"table\",\n    name: \"abc\",\n    format: \"PostGIS\",\n    href: \"http://localhost:8080/geoserver/rest/imports/0/tasks/0/data\"\n}\n
                                                                        ","text":""},{"location":"extensions/importer/rest_reference/#task-target-layer","title":"Task target layer","text":""},{"location":"extensions/importer/rest_reference/#importstaskslayer","title":"/imports//tasks//layer

                                                                        The layer defines how the target layer will be created

                                                                        Method Action Status Code/Headers Input Output GET Retrieve the layer of a task with id within import with id 200 n/a A layer JSON representation PUT Modify the target layer for a task with id within import with id 200 Task Task

                                                                        Requesting the task layer will result in the following:

                                                                        Status: 200 OK\nContent-Type: application/json\n\n{\n    layer: {\n    name: \"tasmania_cities\",\n    href: \"http://localhost:8080/geoserver/rest/imports/0/tasks/0/layer\",\n    title: \"tasmania_cities\",\n    originalName: \"tasmania_cities\",\n    nativeName: \"tasmania_cities\",\n    srs: \"EPSG:4326\",\n    bbox: {\n        minx: 147.2909004483,\n        miny: -42.85110181689001,\n        maxx: 147.2911004483,\n        maxy: -42.85090181689,\n        crs: \"GEOGCS[\"WGS 84\", DATUM[\"World Geodetic System 1984\", SPHEROID[\"WGS 84\", 6378137.0, 298.257223563, AUTHORITY[\"EPSG\",\"7030\"]], AUTHORITY[\"EPSG\",\"6326\"]], PRIMEM[\"Greenwich\", 0.0, AUTHORITY[\"EPSG\",\"8901\"]], UNIT[\"degree\", 0.017453292519943295], AXIS[\"Geodetic longitude\", EAST], AXIS[\"Geodetic latitude\", NORTH], AUTHORITY[\"EPSG\",\"4326\"]]\"\n    },\n    attributes: [\n        {\n            name: \"the_geom\",\n            binding: \"org.locationtech.jts.geom.MultiPoint\"\n        },\n        {\n            name: \"CITY_NAME\",\n            binding: \"java.lang.String\"\n        },\n        {\n            name: \"ADMIN_NAME\",\n            binding: \"java.lang.String\"\n        },\n        {\n            name: \"CNTRY_NAME\",\n            binding: \"java.lang.String\"\n        },\n        {\n            name: \"STATUS\",\n            binding: \"java.lang.String\"\n        },\n        {\n            name: \"POP_CLASS\",\n            binding: \"java.lang.String\"\n        }\n        ],\n        style: {\n            name: \"cite_tasmania_cities\",\n            href: \"http://localhost:8080/geoserver/rest/imports/0/tasks/0/layer/style\"\n        }\n    }\n}\n

                                                                        All the above attributes can be updated using a PUT request. Even if the above representation is similar to the REST config API, it should not be confused with it, as it does not support all the same properties, in particular the supported properties are all the ones listed above.

                                                                        ","text":""},{"location":"extensions/importer/rest_reference/#task-transformations","title":"Task transformations","text":""},{"location":"extensions/importer/rest_reference/#importstaskstransforms","title":"/imports//tasks//transforms Method Action Status Code/Headers Input Output GET Retrieve the list of transformations of a task with id within import with id 200 n/a A list of transfromations in JSON format POST Create a new transformation and append it inside a task with id within import with id 201 A JSON transformation representation The transform location","text":""},{"location":"extensions/importer/rest_reference/#retrieving-the-transformation-list","title":"Retrieving the transformation list

                                                                        A GET request for the list of transformations will result in the following response:

                                                                        Status: 200 OK\nContent-Type: application/json\n\n{\n  \"transforms\": [\n    {\n      \"type\": \"ReprojectTransform\", \n      \"href\": \"http://localhost:8080/geoserver/rest/imports/0/tasks/1/transforms/0\", \n      \"source\": null, \n      \"target\": \"EPSG:4326\"\n    }, \n    {\n      \"type\": \"DateFormatTransform\", \n      \"href\": \"http://localhost:8080/geoserver/rest/imports/0/tasks/1/transforms/1\", \n      \"field\": \"date\", \n      \"format\": \"yyyyMMdd\"\n    }\n  ]\n}\n
                                                                        ","text":""},{"location":"extensions/importer/rest_reference/#appending-a-new-transformation","title":"Appending a new transformation

                                                                        Creating a new transformation requires posting a JSON document with a type property identifying the class of the transformation, plus any extra attribute required by the transformation itself (this is transformation specific, each one will use a different set of attributes).

                                                                        The following POST request creates an attribute type remapping:

                                                                        Content-Type: application/json\n\n{\n   \"type\": \"AttributeRemapTransform\",\n   \"field\": \"cat\",\n   \"target\": \"java.lang.Integer\"\n}\n

                                                                        The response will be:

                                                                        Status: 201 OK\nLocation: http://localhost:8080/geoserver/rest/imports/0/tasks/1/transform/2\n
                                                                        ","text":""},{"location":"extensions/importer/rest_reference/#importstaskstransforms_1","title":"/imports//tasks//transforms/ Method Action Status Code/Headers Input Output GET Retrieve a transformation identified by inside a task with id within import with id 200 n/a A single transformation in JSON format PUT Modifies the definition of a transformation identified by inside a task with id within import with id 200 A JSON transformation representation (eventually just the portion of it that needs to be modified) The full transformation representation DELETE Removes the transformation identified by inside a task with id within import with id 200 A JSON transformation representation (eventually just the portion of it that needs to be modified) The full transformation representation","text":""},{"location":"extensions/importer/rest_reference/#retrieve-a-single-transformation","title":"Retrieve a single transformation

                                                                        Requesting a single transformation by identifier will result in the following response:

                                                                        Status: 200 OK\nContent-Type: application/json\n\n{\n  \"type\": \"ReprojectTransform\", \n  \"href\": \"http://localhost:8080/geoserver/rest/imports/0/tasks/1/transforms/0\", \n  \"source\": null, \n  \"target\": \"EPSG:4326\"\n}\n
                                                                        ","text":""},{"location":"extensions/importer/rest_reference/#modify-an-existing-transformation","title":"Modify an existing transformation

                                                                        Assuming we have a reprojection transformation, and that we need to change the target SRS type, the following PUT request will do the job:

                                                                        Content-Type: application/json\n{\n   \"type\": \"ReprojectTransform\",\n   \"target\": \"EPSG:3005\"\n}\n

                                                                        The response will be:

                                                                        Status: 200 OK\nContent-Type: application/json\n\n{\n  \"type\": \"ReprojectTransform\", \n  \"href\": \"http://localhost:8080/geoserver/rest/imports/0/tasks/1/transform/0\", \n  \"source\": null, \n  \"target\": \"EPSG:3005\"\n}\n
                                                                        ","text":""},{"location":"extensions/importer/rest_reference/#transformations","title":"Transformation reference","text":""},{"location":"extensions/importer/rest_reference/#attributeremaptransform","title":"AttributeRemapTransform

                                                                        Remaps a certain field to a given target data type

                                                                        Parameter Optional Description field N The name of the field to be remapped target N The \"target\" field type, as a fully qualified Java class name","text":""},{"location":"extensions/importer/rest_reference/#attributecomputetransform","title":"AttributeComputeTransform

                                                                        Computes a new field based on an expression that can use the other field values

                                                                        Parameter Optional Description field N The name of the field to be computed fieldType N The field type, as a fully qualified Java class name (e.g., java.lang.String, java.lang.Integer, java.util.Date and so on) cql N The (E)CQL expression used to compute the new field (can be a constant value, e.g. 'My String')","text":""},{"location":"extensions/importer/rest_reference/#attributestopointgeometrytransform","title":"AttributesToPointGeometryTransform

                                                                        Transforms two numeric fields latField and lngField into a point geometry representation with pointFieldName setting name of the point POINT(lngField,latField), the source fields will be removed if preserveGeometry is false.

                                                                        Parameter Optional Description latField N The \"latitude\" field lngField N The \"longitude\" field pointFieldName Y The name of the point preserveGeometry Y Setting this flag will prevent source fields from removal (false by default)","text":""},{"location":"extensions/importer/rest_reference/#createindextransform","title":"CreateIndexTransform

                                                                        For database targets only, creates an index on a given column after importing the data into the database

                                                                        Parameter Optional Description field N The field to be indexed","text":""},{"location":"extensions/importer/rest_reference/#dateformattransform","title":"DateFormatTransform

                                                                        Parses a string representation of a date into a Date/Timestamp object

                                                                        Parameter Optional Description field N The field to be parsed format Y A date parsing pattern, setup using the Java SimpleDateFormat syntax. In case it's missing, a number of built-in formats will be tried instead (short and full ISO date formats, dates without any separators). enddate Y The field used as end date for the time dimension. presentation Y The time dimension presentation type; one of","text":""},{"location":"extensions/importer/rest_reference/#integerfieldtodatetransform","title":"IntegerFieldToDateTransform

                                                                        Takes a integer field and transforms it to a date, interpreting the intereger field as a date

                                                                        Parameter Optional Description field N The field containing the year information","text":""},{"location":"extensions/importer/rest_reference/#reprojecttransform","title":"ReprojectTransform

                                                                        Reprojects a vector layer from a source CRS to a target CRS

                                                                        Parameter Optional Description source Y Identifier of the source coordinate reference system (the native one will be used if missing) target N Identifier of the target coordinate reference system","text":""},{"location":"extensions/importer/rest_reference/#gdaltranslatetransform","title":"GdalTranslateTransform

                                                                        Applies gdal_translate to a single file raster input. Requires gdal_translate to be inside the PATH used by the web container running GeoServer.

                                                                        Parameter Optional Description options N Array of options that will be passed to gdal_translate (beside the input and output names, which are internally managed)","text":""},{"location":"extensions/importer/rest_reference/#gdalwarptransform","title":"GdalWarpTransform

                                                                        Applies gdalwarp to a single file raster input. Requires gdalwarp to be inside the PATH used by the web container running GeoServer.

                                                                        Parameter Optional Description options N Array of options that will be passed to gdalwarp (beside the input and output names, which are internally managed)","text":""},{"location":"extensions/importer/rest_reference/#gdaladdotransform","title":"GdalAddoTransform

                                                                        Applies gdaladdo to a single file raster input. Requires gdaladdo to be inside the PATH used by the web container running GeoServer.

                                                                        Parameter Optional Description options N Array of options that will be passed to gdaladdo (beside the input file name, which is internally managed) levels N Array of integers with the overview levels that will be passed to gdaladdo","text":""},{"location":"extensions/importer/rest_reference/#postscripttransform","title":"PostScriptTransform

                                                                        Runs the specified script after the data is imported. The script must be located in $GEOSERVER_DATA_DIR/importer/scripts. The script can be any executable file. At the time of writing, there is no way to pass information about the data just imported to the script (TBD).

                                                                        Parameter Optional Description name N Name of the script to be invoked options Y Array of options that will be passed to the script","text":""},{"location":"extensions/importer/using/","title":"Using the Importer extension","text":"

                                                                        Here are step-by-step instructions to import multiple shapefiles in one operation. For more details on different types of operations, please see Importer interface reference.

                                                                        1. Find a directory of shapefiles and copy into your GeoServer data directory.

                                                                          Note

                                                                          You can always use the Natural Earth Quickstart data for this task.

                                                                        2. Log in as an administrator and navigate to the Data \u2192 Import Data page.

                                                                        3. For select Spatial Files as the data source.

                                                                          Data source

                                                                        4. Click Browse to navigate to the directory of shapefiles to be imported.

                                                                        5. The web-based file browser will show as options your home directory, data directory, and the root of your file system (or drive). In this case, select Data directory

                                                                          Directory

                                                                        6. Back on the main form, select Create new next to Workspace, and enter ne to denote the workspace.

                                                                          Note

                                                                          Make sure the Store field reads Create new as well.

                                                                          Import target workspace

                                                                        7. Click Next to start the import process.

                                                                        8. On the next screen, any layers available for import will be shown.

                                                                          Note

                                                                          Non-spatial files will be ignored.

                                                                          Import layer list

                                                                        9. In most cases, all files will be ready for import, but if the spatial reference system (SRS) is not recognized, you will need to manually input this but clicking Advanced

                                                                          Note

                                                                          You will need to manually input the SRS if you used the Natural Earth data above. For each layer click on Advanced and set reprojection to EPSG:4326.

                                                                          Advanced import settings

                                                                        10. Check the box next to each layer you wish to import.

                                                                          Setting the layers to import

                                                                        11. When ready, click Import.

                                                                          Warning

                                                                          Don't click Done at this point, otherwise the import will be canceled.

                                                                        12. The results of the import process will be shown next to each layer.

                                                                        13. When finished, click Done.

                                                                          Note

                                                                          Recent import processes are listed at the bottom of the page. You may wish to visit these pages to check if any difficulties were encountered during the import process or import additional layers.

                                                                          Recent imports

                                                                        "},{"location":"extensions/inspire/","title":"INSPIRE","text":"

                                                                        The INSPIRE extension allows GeoServer to be compliant with the View Service and Download Service specifications put forth by the Infrastructure for Spatial Information in the European Community (INSPIRE) directive.

                                                                        In practice this means adding some extra elements into an extended capabilities section of the WMS, WFS and WCS capabilities documents. For WMS, WFS and WCS this includes a Metadata URL element with a link to the metadata associated with the service, and SupportedLanguages and ResponseLanguage elements which report the response language (GeoServer can only support one response language). For WFS and WCS there are also one or more SpatialDataSetIdentifier elements for each spatial data resource served by the service.

                                                                        Note

                                                                        The current INSPIRE extension fulfills \"Scenario 1\" of the View Service extended metadata requirements. \"Scenario 2\" is not currently supported in GeoServer, but is certainly possible to implement. If you are interested in implementing or funding this, please raise the issue on the GeoServer mailing list.

                                                                        For more information on the INSPIRE directive, please see the European Commission's INSPIRE website.

                                                                        • Installing the INSPIRE extension
                                                                        • Using the INSPIRE extension
                                                                        "},{"location":"extensions/inspire/installing/","title":"Installing the INSPIRE extension","text":"
                                                                        1. Visit the website download page, locate your release, and download: inspire

                                                                          Verify that the version number in the filename (for example 2.24.2 above) corresponds to the version of GeoServer you are running.

                                                                        2. Extract the archive and copy the contents into the GeoSever WEB-INF/lib directory.

                                                                        3. Restart GeoServer.

                                                                        To verify that the extension was installed successfully, please see the next section on Using the INSPIRE extension.

                                                                        "},{"location":"extensions/inspire/using/","title":"Using the INSPIRE extension","text":"

                                                                        When the INSPIRE extension has been properly installed, the WMS settings, WFS settings and WCS settings sections of the Web administration interface will show an extra INSPIRE configuration section. If the data directory has not been configured with INSPIRE parameters before, this section will just contain a check box to enable the creation of an INSPIRE ExtendedCapabilities element.

                                                                        Note

                                                                        If you do not see this content in the service configuration pages, the INSPIRE extension may not be installed properly. Reread the section on Installing the INSPIRE extension and verify that the correct file was saved to the correct directory.

                                                                        "},{"location":"extensions/inspire/using/#extended-wms-and-wmts-configuration","title":"Extended WMS and WMTS configuration","text":"

                                                                        INSPIRE-specific configuration is accessed on the main WMS settings or WMTS settings page in the Web administration interface. This is accessed by clicking on the WMS or WMTS link on the sidebar.

                                                                        Note

                                                                        You must be logged in as an administrator to edit WMS or WMTS configuration.

                                                                        Once on the service configuration page, there will be a block titled INSPIRE. If you enable the checkbox shown above this section will have three additional settings:

                                                                        • Default Language combo box, for setting the Default
                                                                        • Other Supported Languages area for setting Supported Languages
                                                                        • Service Metadata URL field, a URL containing the location of the metadata associated with the service
                                                                        • Service Metadata Type combo box, for detailing whether the metadata came from a CSW (Catalog Service) or a standalone metadata file

                                                                        INSPIRE-related options

                                                                        After clicking Submit on this page, any changes will be immediately reflected in the services (WMS 1.3.0 or WMTS 1.0.0) capabilities document.

                                                                        Note

                                                                        The Service Metadata URL field is mandatory so you will not be allowed to submit a blank value.

                                                                        Note

                                                                        The Service Metadata Type combo box only allows to select the appropriate MIME type for a CSW response or standalone metadata file or to omit a value altogether. If you think other values would be useful you could raise the issue on the GeoServer mailing list. In the meantime it is possible to manually edit the created configuration files as a workaround.

                                                                        "},{"location":"extensions/inspire/using/#extended-wms-and-wmts-capabilities","title":"Extended WMS and WMTS Capabilities","text":"

                                                                        Note

                                                                        The INSPIRE extension only modifies the WMS 1.3.0 response, so please make sure that you are viewing the correct capabilities document.

                                                                        The WMS 1.3.0 and WMTS 1.0.0 capabilities document will contain two additional entries in the xsi:schemaLocation of the root <WMS_Capabilities> tag once the INSPIRE extension is installed:

                                                                        • http://inspire.ec.europa.eu/schemas/inspire_vs/1.0
                                                                        • https://inspire.ec.europa.eu/schemas/inspire_vs/1.0/inspire_vs.xsd

                                                                        If you have enabled the check box to create the INSPIRE ExtendedCapabilities element and entered the values described in the previous section then there will also be an additional ExtendedCapabilities block. This tag block shows up in between the tags for <Exception> and <Layer>. It contains the following information:

                                                                        • Metadata URL and MIME type
                                                                        • Supported Language(s)
                                                                        • Response Language

                                                                        With the example values shown in the above configuration panel, this block would contain the following content:

                                                                        <inspire_vs:ExtendedCapabilities>\n <inspire_common:MetadataUrl>\n  <inspire_common:URL>\n   http://mysite.org/metadata.xml\n  </inspire_common:URL>\n  <inspire_common:MediaType>\n   application/vnd.iso.19139+xml\n  </inspire_common:MediaType>\n </inspire_common:MetadataUrl>\n <inspire_common:SupportedLanguages>\n  <inspire_common:DefaultLanguage>\n   <inspire_common:Language>eng</inspire_common:Language>\n  </inspire_common:DefaultLanguage>\n  <inspire_common:SupportedLanguage>fre</inspire_common:SupportedLanguage>\n </inspire_common:SupportedLanguages>\n <inspire_common:ResponseLanguage>\n  <inspire_common:Language>eng</inspire_common:Language>\n </inspire_common:ResponseLanguage>\n</inspire_vs:ExtendedCapabilities>\n

                                                                        ISNPIRE recommends that every layer offered by a INSPIRE WMTS should use the InspireCRS84Quad grid set which is already configured in GeoServer, but is up to the user to select it when publishing a INSPIRE WMTS layer.

                                                                        "},{"location":"extensions/inspire/using/#extended-wfs-and-wcs-configuration","title":"Extended WFS and WCS configuration","text":"

                                                                        INSPIRE-specific configuration is accessed on the main WFS settings and WCS settings pages in the Web administration interface. These are accessed by clicking on the WFS and WCS links on the sidebar respectively.

                                                                        Note

                                                                        You must be logged in as an administrator to edit WFS configuration.

                                                                        Once on the WFS or WCS configuration page, there will be a block titled INSPIRE. If you enable the checkbox shown above this section will have the following additional settings:

                                                                        • Language combo box, for setting the Supported, Default, and Response languages
                                                                        • Other Supported Languages area for setting Supported Languages
                                                                        • Service Metadata URL field, a URL containing the location of the metadata associated with the WFS or WCS
                                                                        • Service Metadata Type combo box, for detailing whether the metadata came from a CSW (Catalog Service) or a standalone metadata file
                                                                        • Spatial dataset identifiers table, where you can specify a code (mandatory), a namespace (optional) and a metadata URL (optional) for each spatial data set the WFS or WCS is offering

                                                                        INSPIRE-related options

                                                                        After clicking Submit on this page, any changes will be immediately reflected in the WFS 1.1 and WFS 2.0 or WCS 2.0 capabilities documents as appropriate.

                                                                        Note

                                                                        The Service Metadata URL field and at least one Spatial dataset identifiers entry are mandatory so you will not be allowed to submit the page without these.

                                                                        Note

                                                                        The Service Metadata Type combo box only allows to select the appropriate MIME type for a CSW response or standalone metadata file or to omit a value altogether. If you think other values would be useful you could raise the issue on the GeoServer mailing list. In the meantime it is possible to manually edit the created configuration files as a workaround.

                                                                        "},{"location":"extensions/inspire/using/#extended-wfs-and-wcs-capabilities","title":"Extended WFS and WCS Capabilities","text":"

                                                                        Note

                                                                        The INSPIRE directive is relevant to WFS 1.1 and 2.0 and WCS 2.0 only, so please make sure that you are viewing the correct capabilities document.

                                                                        The WFS and WCS capabilities documents will contain two additional entries in the xsi:schemaLocation of the root element tag once the INSPIRE extension is installed:

                                                                        • https://inspire.ec.europa.eu/schemas/common/1.0/common.xsd
                                                                        • https://inspire.ec.europa.eu/schemas/inspire_dls/1.0/inspire_dls.xsd

                                                                        If you have enabled the check box to create the INSPIRE ExtendedCapabilities element and entered the values described in the previous section then there will also be an additional ExtendedCapabilities block with the following information:

                                                                        • Metadata URL and MIME type
                                                                        • Supported Language(s)
                                                                        • Response Language
                                                                        • Spatial data identifier(s)

                                                                        With the example values shown in the above configuration panel, this block would contain the following content:

                                                                        <inspire_dls:ExtendedCapabilities>\n  <inspire_common:MetadataUrl>\n    <inspire_common:URL>\n      http://mysite.org/csw?SERVICE=CSW&REQUEST=GetRecord\n    </inspire_common:URL>\n    <inspire_common:MediaType>\n      application/vnd.iso.19139+xml\n    </inspire_common:MediaType>\n  </inspire_common:MetadataUrl>\n  <inspire_common:SupportedLanguages>\n    <inspire_common:DefaultLanguage>\n     <inspire_common:Language>eng</inspire_common:Language>\n    </inspire_common:DefaultLanguage>\n    <inspire_common:SupportedLanguage>fre</inspire_common:SupportedLanguage>\n  </inspire_common:SupportedLanguages>\n  <inspire_common:ResponseLanguage>\n    <inspire_common:Language>eng</inspire_common:Language>\n  </inspire_common:ResponseLanguage>\n  <inspire_dls:SpatialDataSetIdentifier metadataURL=\"http://mysite.org/ds/md/ds1.xml\">\n    <inspire_common:Code>\n     fc929094-8a30-2617-e044-002128a47908\n    </inspire_common:Code>\n  <inspire_common:Namespace>\n     http://metadata.mysite.org/ds\n  </inspire_common:Namespace>\n </inspire_dls:SpatialDataSetIdentifier>\n</inspire_dls:ExtendedCapabilities>\n

                                                                        The spatial data identifiers section is mandatory, but cannot be filled by default, it is your duty to provide at least one spatial dataset identifier (see the INSPIRE download service technical guidelines for more information).

                                                                        "},{"location":"extensions/inspire/using/#internationalization-support","title":"Internationalization support","text":"

                                                                        GeoServer offers the ability to configure GetCapabilities response in multiple languages. Content in different languages can be requested by using the request parameter Language, e.g. Language=eng. At the time of writing, the following services support the parameter: WFS 2.0, WMS 1.1 and 1.3, WCS 2.0.

                                                                        At the time of writing the INSPIRE Schemas only allow 23 choices for DefaultLanguage. The GeoServer INSPIRE extension allows some other languages to be chosen. If you choose one of these your capabilities document won't be Schema valid but, as discussed in issue 7388, the INSPIRE Schemas seem to be at fault.

                                                                        The language list available from the UI is define in a classpath file named available_languages.properties with the following content:

                                                                        bul=bg\ncze=cs\ndan=da\ndut=nl\neng=en\nest=et\nfin=fi\nfre=fr\nhrv=hr\nice=is\nger=de\ngle=ga\ngre=el\ngsw=de-CH\nhun=hu\nita=it\nlav=lv\nlit=lt\nmlt=mt\nnor=nb\npol=pl\npor=pt\nrum=ro\nslo=sk\nslv=sl\nspa=es\nswe=sv\n

                                                                        The entries of the above list represent the available INSPIRE language code matched with the corresponding ISO 639-1 code. The GeoServer internationalization support is based on OWS 2.0, and thus using ISO codes internally. The INSPIRE module maps on the fly the INSPIRE names to ISO codes based on the above property file. The property file can be overridden by placing a properties file named available_languages.properties in the inspire directory inside the GeoServer data directory.

                                                                        "},{"location":"extensions/jp2k/","title":"JP2K Plugin","text":"

                                                                        GeoServer can leverage the JP2K Geotools plugin to read JP2K coverage formats. In case you have a Kakadu license and you have built your set of native libraries, you will be able to access the JP2K data with higher performances leveraging on it. Otherwise you will use the standard SUN's JP2K. See GeoTools JP2K Plugin for further information.

                                                                        "},{"location":"extensions/jp2k/#installing-kakadu","title":"Installing Kakadu","text":"

                                                                        In order for GeoServer to leverage on the Kakadu libraries, the Kakadu binaries must be installed through your host system's OS.

                                                                        If you are on Windows, make sure that the Kakadu DLL files are on your PATH. If you are on Linux, be sure to set the LD_LIBRARY_PATH environment variable to be the folder where the SOs are extracted.

                                                                        Once these steps have been completed, restart GeoServer. If done correctly, new data formats will be in the Raster Data Sources list when creating a new data store:

                                                                        Raster Data Source

                                                                        Configuring a JP2K data store

                                                                        "},{"location":"extensions/libjpeg-turbo/","title":"libjpeg-turbo Map Encoder Extension","text":"

                                                                        This plugin brings in the ability to encode JPEG images as WMS output using the libjpeg-turbo library. Citing its website the libjpeg-turbo library is a derivative of libjpeg that uses SIMD instructions (MMX, SSE2, NEON) to accelerate baseline JPEG compression and decompression on x86, x86-64, and ARM systems. On such systems, libjpeg-turbo is generally 2-4x as fast as the unmodified version of libjpeg, all else being equal. I guess it is pretty clear why we wrote this plugin! Note that the underlying imageio-ext-turbojpeg uses TurboJpeg which is a higher level set of API (providing more user-friendly methods like \"Compress\") built on top of libjpeg-turbo.

                                                                        Warning

                                                                        The speedup may vary depending on the target infrastructure.

                                                                        The module, once installed, simply replace the standard JPEG encoder for GeoServer and allows us to use the libjpeg-turbo library to encode JPEG response for GetMap requests.

                                                                        Note

                                                                        It is worth to point out that the module depends on a successful installation of the libjpeg-turbo native libraries (more on this later).

                                                                        "},{"location":"extensions/libjpeg-turbo/#installing-the-libjpeg-turbo-native-library","title":"Installing the libjpeg-turbo native library","text":"

                                                                        Installing the libjpeg-turbo native library is a precondition to have the relative GeoServer Map Encoder properly installed; once the GeoServer extension has been installed as we explain in the following section, the needed JARs with the Java bridge to the library are in the classpath, therefore all we need to do is to install the native library itself to start encoding JPEG at turbo speed.

                                                                        To perform the installation of the libjpeg-turbo binaries (or native library) you have to perform the following steps:

                                                                        1. Go to the download site here and download the latest available stable release (1.2.90 at the time of writing)
                                                                        2. Select the package that matches the target platform in terms of Operating System (e.g. Linux rather than Windows) and Architecture (32 vs 64 bits)
                                                                        3. Perform the installation using the target platform conventions. As an instance for Windows you should be using an installer that installs all the needed libs in a location at user's choice. On Ubuntu Linux systems you can use the deb files instead.
                                                                        4. Once the native libraries are installed, you have to make sure the GeoServer can load them. This should happen automatically after Step 2 on Linux, while on Windows you should make sure that the location where you placed the DLLs is part of the PATH environment variable for the Java Process for the GeoServer.

                                                                        Warning

                                                                        When installing on Windows, always make sure that the location where you placed the DLLs is part of the PATH environment variable for the Java Process for the GeoServer. This usually means that you have to add such location to the PATH environmental variable for the user that is used to run GeoServer or the system wide variables.

                                                                        Warning

                                                                        When installing on Linux, make sure that the location where you placed the DLLs is part of the LD_LIBRARY_PATH environment variable for the Java Process for the GeoServer. This usually happens automatically for the various Linux packages, but in some cases you might be forced to do that manually

                                                                        Note

                                                                        It does not hurt to add also the location where the native libraries where installed to the Java startup options -Djava.library.path="},{"location":"extensions/libjpeg-turbo/#installing-the-geoserver-libjpeg-turbo-extension","title":"Installing the GeoServer libjpeg-turbo extension","text":"

                                                                        ::: warning ::: title Warning :::

                                                                        Before moving on make sure you installed the libjpeg-turbo binaries as per the section above. :::

                                                                        1. Visit the website download page, locate your release, and download: libjpeg-turbo

                                                                          Warning

                                                                          Make sure to match the version of the extension (for example 2.24.2 above) to the version of the GeoServer instance!

                                                                        1. Extract the contents of the archive into the WEB-INF/lib directory of the GeoServer installation.
                                                                        "},{"location":"extensions/libjpeg-turbo/#checking-if-the-extension-is-enabled","title":"Checking if the extension is enabled","text":"

                                                                        Once the extension is installed, the following lines should appear in the GeoServer log:

                                                                        10-mar-2013 19.16.28 it.geosolutions.imageio.plugins.turbojpeg.TurboJpegUtilities load\nINFO: TurboJPEG library loaded (turbojpeg)\n

                                                                        or:

                                                                        10 mar 19:17:12 WARN [turbojpeg.TurboJPEGMapResponse] - The turbo jpeg encoder is available for usage\n

                                                                        You can also check in the Server Status page. From the Modules tab:

                                                                        • Locate the GeoServer libjpeg-turbo Module module. The enabled status indicates if the extension is available
                                                                        • Click on the GeoServer libjpeg-turbo Module link to check module status. The Module Info dialog indicates the JNI LibJPEGTurbo Wrapper Version used.
                                                                        "},{"location":"extensions/libjpeg-turbo/#disabling-the-extension","title":"Disabling the extension","text":"

                                                                        When running GeoServer the turb encoder can be disabled by using the Java switch for the JVM process:

                                                                        -Ddisable.turbojpeg=true\n

                                                                        In this case a message like the following should be found in the log:

                                                                        WARN [map.turbojpeg] - The turbo jpeg encoder has been explicitly disabled\n

                                                                        Note

                                                                        We will soon add a section in the GUI to check the status of the extension and to allow users to enable/disable it at runtime.

                                                                        "},{"location":"extensions/mapml/","title":"MapML","text":"

                                                                        Map Markup Language (MapML) is a text-based format which allows map authors to encode map information as hypertext documents exchanged over the Uniform Interface of the Web. The format definition is a work-in-progress by the Maps for HTML W3C Community Group. Various tools to work with the format exist, including a Leaflet-based map viewer included in the GeoServer MapML extension. For more information on MapML refer to the Maps for HTML Community Group <https://maps4html.org/>.

                                                                        The MapML module for GeoServer adds new MapML resources to access WMS, WMTS and WFS services configured in Geoserver. The MapML modules includes support for styles, tiling, querying, and dimensions options for WMS layers, and also provides a MapML outputFormat for WMS GetFeatureInfo and WFS GetFeatures requests. See below for information on installing and configuring the MapML module.

                                                                        ::: note ::: title Note :::

                                                                        The Maps for HTML community kindly requests that if you use MapML and the software provided here or elsewhere, that you give us feedback about your experience: open an issue or start a discussion on GitHub. :::

                                                                        ::: warning ::: title Warning :::

                                                                        MapML is an experimental proposed extension of HTML for the Web. The objective of the project is to standardize map, layer and feature semantics in HTML. As the format progresses towards a Web standard, it may change slightly. Always use the latest version of this extension, and follow or join in the project's progress at https://maps4html.org. :::

                                                                        "},{"location":"extensions/mapml/#installation","title":"Installation","text":"
                                                                        1. Visit the website download page, locate your release, and download: mapml

                                                                          Warning

                                                                          Make sure to match the version of the extension (for example 2.24.2 above) to the version of the GeoServer instance!

                                                                        2. Extract the contents of the archive into the WEB-INF/lib directory of the GeoServer installation.

                                                                        3. Restart GeoServer.

                                                                        "},{"location":"extensions/mapml/#configuration","title":"Configuration","text":"

                                                                        Configuration can be done using the Geoserver administrator GUI. The MapML configuration is accessible in the MapML Settings section under the Publishing tab of the Layer or Layer Group Configuration page for the layer or layer group being configured. Here is the MapML Settings section, with some example values filled in:

                                                                        There is also a MapML-specific global WMS setting in the MapML Extension section of the WMS Services Settings Page. This setting is used to control the handling of multi-layer requests.

                                                                        If the Represent multi-layer requests as multiple elements is checked (and the configuration is saved), an individually accessible element will be generated for each requested layer. The default is to represent the layers as a single (hidden) .

                                                                        "},{"location":"extensions/mapml/#styles","title":"Styles","text":"

                                                                        Like any WMS layer or layer group available from GeoServer, a comma-separated list of styles may be supplied in the WMS GetMap styles parameter. If no style name is requested, the default style will be used for that layer. For single-layer (or layer group) requests, the set of alternate styles is presented as an option list in the layer preview map's layer control, with the currently requested style indicated.

                                                                        Note that in order to ensure that the default layer style is properly available to the preview map's option list, make sure that the style is moved to the Available Styles list in the Publishing tab of the Layer Configuration page. If the style is set to Default but not explicitly made Available, the style will not be available to MapML. Similarly but a with a slight variation in requirement, for Layer Groups, the 'default' layer group style must be copied and given a name matching default-style- plus the layer group name.

                                                                        "},{"location":"extensions/mapml/#license-info","title":"License Info","text":"

                                                                        Together these two attributes allow the administrator to define the contents of the <link rel=license> element in the MapML header. Here is an example of the resulting XML:

                                                                        https://creativecommons.org/licenses/by/4.0/\" rel=\"license\" title=\"Attribution 4.0 International (CC BY 4.0)\"/>

                                                                        License Title

                                                                        The License Title will be included as the value of title attribute of the <link rel=license> element in the MapML header.

                                                                        License Link

                                                                        The License Link will be included as the value of href attribute of the <link rel=license> element in the MapML header, and should be a valid URL referencing the license document.

                                                                        "},{"location":"extensions/mapml/#tile-settings","title":"Tile Settings","text":"

                                                                        Using tiles to access the layer can increase the performance of your web map. This is especially true if there is a tile cache mechanism in use between GeoServer and the browser client.

                                                                        Use Tiles

                                                                        If the \"Use Tiles\" checkbox is checked, by default the output MapML will define a tile-based reference to the WMS server. Otherwise, an image-based reference will be used. If one or more of the MapML-defined GridSets is referenced by the layer or layer group in its \"Tile Caching\" profile, GeoServer will generate tile references instead of generating WMS GetMap URLs in the MapML document body.

                                                                        "},{"location":"extensions/mapml/#tile-caching","title":"Tile Caching","text":"

                                                                        In the Tile Caching tab panel of the Edit Layer or Edit Layer Group page, at the bottom of the page you will see the table of GridSets that are assigned to the layer or layer group. The values \"WGS84\" and \"OSMTILE\" are equivalent to the EPSG:4326 and EPSG:900913 built in GeoWebCache GridSets. However, for the MapML module to recognize these GridSets, you must select and use the MapML names. For new layers or layer groups, or newly created grid subsets for a layer or layer group, the MapML values are selected by default. For existing layers that you wish to enable the use of cached tile references by the MapML service, you will have to select and add those values you wish to support from the dropdown of available GridSets. The set of recognized values for MapML is \"WGS84\" (equivalent to EPSG:4326), \"OSMTILE\" (equivalent to EPSG:900913), \"CBMTILE\" (Canada Base Map) and \"APSTILE\" (Alaska Polar Stereographic).

                                                                        "},{"location":"extensions/mapml/#sharding-config","title":"Sharding Config","text":"

                                                                        The Sharding Config options are intended to allow for parallel access to tiles via different server names. The actual server names must be configured in the DNS to refer to either the same server or different servers with the same GeSserver layer configuration. In the example above, the mapML client would alternate between the servers a.geoserver.org, b.geoserver.org, and c.geoserver.org to access the map images. The values in the example above would result in the following MapML:

                                                                        <input name=\"s\" type=\"hidden\" shard=\"true\" list=\"servers\" min=\"0.0\" max=\"0.0\"/>\n<datalist id=\"servers\">\n    <option value=\"a\"/>\n    <option value=\"b\"/>\n    <option value=\"c\"/>\n</datalist>\n<link tref=\"http://{s}.geoserver.org:8080/geoserver/test/wms?version=1.3.0&amp;service=WMS&amp;request=GetMap&amp;crs=EPSG:3857&amp;layers=cntry00&amp;styles=&amp;bbox={xmin},{ymin},{xmax},{ymax}&amp;format=image/png&amp;transparent=false&amp;width={w}&amp;height={h}\" rel=\"image\"/>\n
                                                                        Enable Sharding

                                                                        If Enable Sharding is checked, and values are provided for the Shard List and Shard Server Pattern fields, then a hidden shard list input will be included in the MapML.

                                                                        Shard List

                                                                        If Enable Sharding is checked, the Shard List should be populated with a comma-separated list of shard names which will be used to populate the shard data list element.

                                                                        Shard Server Pattern

                                                                        The Shard Server Pattern should be a valid DNS name including the special placeholder string {s} which will be replace with the Shard Names from the Shard List in requests to the server. This pattern should not include any slashes, the protocol string (http://) or the port number (:80), as these are all determined automatically from the URL used to access the MapML resource.

                                                                        "},{"location":"extensions/mapml/#dimension-config","title":"Dimension Config","text":"Dimension

                                                                        The selected dimension (if any) is advertised in the mapml as an input with the appropriate value options or ranges, as configured in the Dimension tab of the Layer Configuration page. Only dimensions enabled in the Dimension tab are available as options.

                                                                        "},{"location":"extensions/mapml/#attribute-to-mapping","title":"Attribute to mapping

                                                                        List of attributes The list allows you to read the names of the layer attributes, it doesn't really do more than that.

                                                                        Feature Caption Template String

                                                                        To cause an attribute to be serialized in MapML vector content as the element value, you must enter its name as a \\${placeholder} in the text box immediately below the attributes list. You can also add (a small amount of) plain text that will be copied verbatim into the content. is used as the accessible name of features by screen reader software, which will often read out this value without the user having to expand a popup; in other words, it will be used as a visual and audible tooltip when the feature is focused.","text":""},{"location":"extensions/mapml/#mapml-resources","title":"MapML Resources","text":"

                                                                        MapML resources will be available for any published WMS layers by making a GetMap request with the WMS output format to format=text/mapml. See Web Map Service (WMS) for further WMS details, GetMap for GetMap details, and WMS output formats for output format reference information.

                                                                        SRS/CRS

                                                                        Note that the WMS SRS or CRS must be one of the projections supported by MapML:

                                                                        • MapML:WGS84 (or EPSG:4326)
                                                                        • MapML:OSMTILE (or EPSG:3857)
                                                                        • MapML:CBMTILE (or EPSG:3978)
                                                                        • MapML:APSTILE (or EPSG:5936)

                                                                        The equivalent EPSG codes are provided for reference, but the MapML names are recommended, as they imply not only a coordinate refefence system, but also a tile grid and a set of zoom levels (Tiled CRS), that the MapML client will use when operating in tiled mode. When using tiles, it's also recommended to set up tile caching for the same-named gridsets.

                                                                        If the native SRS of a layer is not a match for the MapML ones, remember to configure the projection policy to \"reproject native to declare\". You might have to save and reload the layer configuration in order to re-compute the native bounds correctly.

                                                                        If the SRS or CRS is not one of the above, the GetMap request will fail with an InvalidParameterValue exception. The main \"MapML\" link in the preview page generates a HTML client able to consume MapML resources. The link is generated so that it always work, if the CRS configured for the layer is not supported, it will automatically fall back on MapML:WGS84.

                                                                        MapML Output Format

                                                                        The output image format for the MapML resource should be specified using the format_options parameter with a key called mapml-wms-format. If provided, the provided mime type must be a valid WMS format specifier. If not provided, it defaults to image/png.

                                                                        Example:

                                                                        http://localhost:8080/geoserver/tiger/wms?service=WMS&version=1.1.0&request=GetMap&layers=tiger:giant_polygon&bbox=-180.0,-90.0,180.0,90.0&width=768&height=384&srs=EPSG:4326&styles=&format=text/mapml&format_options=mapml-wms-format:image/jpeg\n
                                                                        "},{"location":"extensions/mapml/#mapml-visualization","title":"MapML Visualization","text":"

                                                                        With the MapML Extension module installed, the GeoServer Layer Preview page is modified to add a WMS GetMap link to the MapML resources for each layer or layer group. The MapML link in the Layer Preview table is generated by the MapML extension to an HTML Web map page that is created on the fly which refers to the GeoServer resource:

                                                                        You can add layers to the map as you like, by dragging the URL bar value generated by the the Layer Preview WMS formats dropdown menu selection of \"MapML\" as shown below, and dropping it onto another layer's MapML preview:

                                                                        If all goes well, you should see the layers stacked on the map and in the layer control.

                                                                        MapML visualization is supported by the Web-Map-Custom-Element project. The MapML viewer is built into the GeoServer layer and layer group preview facility. You can find out more about the Web-Map-Custom-Element at the project website <https://maps4html.org/web-map-doc/>. Here is a simple, self-contained example of an HTML page that uses the and elements:

                                                                        <!DOCTYPE html>\n<html lang=\"en\">\n  <head>\n    <meta charset=\"utf-8\" >\n    <title>MapML Test Map</title>\n    <meta name=\"viewport\" content=\"width=device-width, initial-scale=1\">\n    <script type=\"module\" src=\"http://localhost:8080/geoserver/mapml/viewer/widget/mapml-viewer.js\"></script>\n    <style>\n      html, body { height: 100%; }\n      * { margin: 0; padding: 0; }\n      mapml-viewer:defined { max-width: 100%; width: 100%; height: 100%; }\n      mapml-viewer:not(:defined) > * { display: none; } layer- { display: none; }\n    </style>\n  </head>\n  <body>\n    <mapml-viewer projection=\"osmtile\" zoom=\"2\" lat=\"61.209125\" lon=\"-90.850837\" controls>\n      <layer- label=\"US States\" src=\"http://localhost:8080/geoserver/mapml/topp:states/osmtile?style=population\" checked></layer->\n    </mapml-viewer>\n  </body>\n</html>\n

                                                                        In the above example, the place-holders topp:states, localhost:8080, osmtile, and population would need to be replaced with the appropriate values, and/or the style parameter could be removed entirely from the URL if not needed. You may also like to \"View Source\" on the preview page to see what the markup looks like for any layer. This code can be copied and pasted without harm, and you should try it and see what works and what the limitations are. For further information about MapML, and the Maps for HTML Community Group, please visit http://maps4html.org.

                                                                        "},{"location":"extensions/metadata/","title":"Metadata","text":"

                                                                        The Metadata module adds a fully customizable metadata tab to the layer configuration, allowing the user to have the layer configuration and layer metadata in one central place.

                                                                        • Getting Started
                                                                        • Fields configuration
                                                                        • Advanced Configuration
                                                                        • User Guide

                                                                        Bulk Operations can be done via the Metadata Rest Service.

                                                                        The layer metadata can be exposed by the Catalog Services for the Web (CSW) service, from there periodically harvested by GeoNetwork . Have a look at the INSPIRE metadata configuration using metadata and CSW tutorial for an example of matching metadata and CSW configurations that can be harvested by GeoNetwork.

                                                                        "},{"location":"extensions/metadata/advanced/","title":"Advanced Configuration","text":""},{"location":"extensions/metadata/advanced/#import-from-geonetwork","title":"Import from Geonetwork","text":"

                                                                        The Import from Geonetwork option allows the user to import existing metadata from GeoNetwork. Two confurations are needed for the import to work:

                                                                        • geonetworks: configure a list geonetwork endpoints
                                                                        • geonetworkmapping: define the mapping between the geonetwork fields and the fields configured in the metadata module.

                                                                        The configuration can be added to the same yaml file as the UI configuration or it can be put in a separate file.

                                                                        "},{"location":"extensions/metadata/advanced/#geonetwork-endpoint-configuration","title":"Geonetwork endpoint configuration","text":"

                                                                        The example will configure 2 endpoints.

                                                                        geonetworks:\n    - name: Geonetwork DOV production\n      url: https://www.dov.vlaanderen.be/geonetwork/srv/api/records/${UUID}/formatters/xml?attachment=true\n    - name: Geonetwork test\n      url: https://geonetwork-opensource.org/test/srv/api/records/${UUID}/formatters/xml?attachment=true\n

                                                                        +----------+----------+--------------------------------------------------------------------------------------------------------------------------+ | Key | Required | Description | +==========+==========+==========================================================================================================================+ | name | > yes | > The name of the Geonetwork endpoint that will be shown in the dropdown. | +----------+----------+--------------------------------------------------------------------------------------------------------------------------+ | url | > yes | > The url of the XML export of the metadata in the Geonetwork, where ${UUID} will be replaced by the metadata's UUID. | +----------+----------+--------------------------------------------------------------------------------------------------------------------------+

                                                                        "},{"location":"extensions/metadata/advanced/#geonetwork-mapping-configuration","title":"Geonetwork mapping configuration","text":"

                                                                        Each field from Geonetwork can be mapped to a native field from GeoServer or a field from the metadata module. The configuration for simple components are added under the yaml attribute geonetworkmapping. The fields of the type COMPLEX are mapped under the attribute objectmapping.

                                                                        The example will map one field (UUID) from the geonetwork xml to UI.

                                                                        geonetworkmapping:\n    -  geoserver: metadata-identifier\n       geonetwork: //gmd:fileIdentifier/gco:CharacterString/text()\n

                                                                        A complex object is mapped in the following example:

                                                                        objectmapping:\n    - typename: responsible-party\n      mapping:\n        - geoserver: organisation\n          geonetwork: .//gmd:CI_ResponsibleParty/gmd:organisationName/gco:CharacterString/text()\n        - geoserver: contactinfo\n          geonetwork: .//gmd:CI_ResponsibleParty/gmd:contactInfo\n        - geoserver: role\n          geonetwork: .//gmd:CI_ResponsibleParty/gmd:role/gmd:CI_RoleCode/@codeListValue\n

                                                                        Metadata from geonetwork can also be mapped to native fields. Do this by setting the mappingType to NATIVE

                                                                        -  geoserver: title\n   geonetwork: //gmd:identificationInfo/gmd:MD_DataIdentification/gmd:citation/gmd:CI_Citation/gmd:title/gco:CharacterString/text()\n   mappingType: NATIVE\n-  geoserver: alias\n   geonetwork: //gmd:identificationInfo/gmd:MD_DataIdentification/gmd:citation/gmd:CI_Citation/gmd:alternateTitle/gco:CharacterString/text()\n   mappingType: NATIVE\n

                                                                        +------------------+----------+-------------------------------------------------------------------------------------------------------------------------------------------+ | Key | Required | Description | +==================+==========+===========================================================================================================================================+ | geoserver | > yes | the key for the attributes in geoserver | +------------------+----------+-------------------------------------------------------------------------------------------------------------------------------------------+ | geonetwork | > yes | The xpath expression pointing to the content from the geonetwork metadata xml file. | +------------------+----------+-------------------------------------------------------------------------------------------------------------------------------------------+ | mappingType: | > no | > | CUSTOM (default; map to fields from the metadata module configuration) | | | | > | NATIVE (map to geoserver native fields) | +------------------+----------+-------------------------------------------------------------------------------------------------------------------------------------------+

                                                                        "},{"location":"extensions/metadata/advanced/#community_metadata_advanced_configuration_custom_native","title":"Custom to Native Mapping","text":"

                                                                        Sometimes your custom metadata configuration may contain a more complex version of fields already present in geoserver native metadata, or you may want to derive geoserver native fields (such as URL's, keywords, etcetera) from information in your custom metadata. Native fields are used by GetCapabilities requests, and you want to avoid filling in the same information twice. We can automatise deriving these native fields from custom fields using a custom-to-native mapping configuration. For example in the following configuration:

                                                                        customNativeMappings:\n  - type: KEYWORDS\n    mapping:\n      value: KEY_${keywords/name}\n      vocabulary: ${keywords/vocabulary}\n  - type: IDENTIFIERS\n    mapping:\n      value: ${identifiers/id}\n      authority: ${identifiers/authority}\n  - type: METADATALINKS\n    mapping:\n      value: https://my-host/geonetwork/?uuid=${uuid}\n      type: text/html\n      metadataType: ISO191156:2003\n  - type: METADATALINKS\n    mapping:\n      value: https://my-host/geonetwork/srv/nl/csw?Service=CSW&Request=GetRecordById&Version=2.0.2&outputSchema=http://www.isotc211.org/2005/gmd&elementSetName=full&id=${uuid}\n      type: text/xml\n      metadataType: ISO191156:2003\n

                                                                        +-------------+----------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Key | Required | Description | +=============+==========+===================================================================================================================================================================================+ | type | > yes | currently supported: KEYWORDS, IDENTIFIERS, METADATALINKS | +-------------+----------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | mapping | > yes | | List of key to value pairs. Value contains a literal with or without placeholder that contains custom attribute path (the / symbol denoting subfields inside complex fields). | | | | | Possible keys for KEYWORDS: value, vocabulary | | | | | Possible keys for METADATALINKS: value, type, metadataType, about | | | | | Possible keys for IDENTIFIERS: value, authority | +-------------+----------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+

                                                                        The synchronisation of the metadata takes place each time a layer is saved. Any information that has been entered by the user in mapped native fields via the GUI will be lost.

                                                                        "},{"location":"extensions/metadata/configuration/","title":"Getting Started","text":""},{"location":"extensions/metadata/configuration/#installation","title":"Installation","text":"

                                                                        To install the GeoServer Metadata extension:

                                                                        • Visit the GeoServer download page and navigate to the download page for the version of GeoServer your are using. The metadata download is listed under extensions. The file name is called geoserver-*-metadata-plugin.zip, where * matches the version number of GeoServer you are using.
                                                                        • Extract this file and place the JARs in WEB-INF/lib.
                                                                        • Perform any configuration required by your servlet container, and then restart. On startup, Metadata module will create a configuration directory metadata in the GeoServer Data Directory. The module will scan all yaml files in the metadata directory.
                                                                        "},{"location":"extensions/metadata/configuration/#basic-configuration","title":"Basic configuration","text":"

                                                                        By default the metadata module will add an extra tab to the edit layer page. Open the layer: navigate to Layers \u2192 Choose the layer \u2192 Metadata tab.

                                                                        The initial UI. Note the Metadata fields panel is still empty

                                                                        The content of the Metadata fields is configured by placing one or multiple yaml files describing the UI components in the metadata configuration folder, see INSPIRE metadata configuration using metadata and CSW for a real life example.

                                                                        Example UI configuration:

                                                                        attributes:\n  - key: metadata-identifier\n    fieldType: UUID\n  - key: metadata-datestamp\n    label: Date\n    fieldType: DATETIME\n  - key: data-language\n    fieldType: DROPDOWN\n    values:\n          - dut\n          - eng\n          - fre\n          - ger\n  - key: topic-category\n    fieldType: SUGGESTBOX\n    occurrence: REPEAT\n    values:\n          - farming\n          - biota\n          - boundaries\n          - climatologyMeteorologyAtmosphere\n          - economy\n          - elevation \n  - key: data-date\n    fieldType: COMPLEX\n    typename: data-identification-date\n    occurrence: REPEAT   \ntypes:    \n   - typename: data-identification-date\n     attributes:\n      - key: date\n        fieldType: DATE\n      - key: date-type\n        fieldType: DROPDOWN\n        values:\n          - creation\n          - publication\n          - revision  \n

                                                                        This configuration results in the following GUI:

                                                                        There are 3 main parts in the yaml:

                                                                        • attributes: a list of GUI components that will be rendered in the tab. They can be a basic type or a complex type, a complex type is a collection of basic types.
                                                                        • types: a list that defines the fields in each complex type.
                                                                        • tabs optionally, attributes may be displayed on separate tabs.

                                                                        Fields configuration gives an overview of all supported types and advanced features.

                                                                        "},{"location":"extensions/metadata/uiconfiguration/","title":"Fields configuration","text":"

                                                                        The ui for the metadata tab is made from a list of field components. The type of the field component and how they behave can be configured in the yaml file. All fields should be configured as a list which has the parent key attributes.

                                                                        "},{"location":"extensions/metadata/uiconfiguration/#field-options","title":"Field options","text":"

                                                                        A field is defined in the yaml following key-value pairs:

                                                                        • key
                                                                        • fieldType
                                                                        • label
                                                                        • occurrence
                                                                        • condition
                                                                        • tab
                                                                        • values (specific field types)
                                                                        • derivedFrom (specific field types)
                                                                        • typename (specific field types)
                                                                        "},{"location":"extensions/metadata/uiconfiguration/#key","title":"key","text":"

                                                                        The key is the identifier for the field and should therefore be unique. Other configurations can refer the field by using this identifier. E.g the geonetwork mapping, internationalization.

                                                                        +-------+----------+-------------------+ | Key | Required | Value | +=======+==========+===================+ | > key | > yes | > a unique string | +-------+----------+-------------------+

                                                                        "},{"location":"extensions/metadata/uiconfiguration/#fieldtype","title":"fieldType","text":"

                                                                        Chooses the type of input widget for the field. A detailed description for each type can be found in the Field Types section.

                                                                        +-------------+----------+------------------+ | Key | Required | Value | +=============+==========+==================+ | > fieldType | > yes | > - COMPLEX | | | | > - TEXT | | | | > - NUMBER | | | | > - TEXT_AREA | | | | > - DATE | | | | > - DATETIME | | | | > - BOOLEAN | | | | > - UUID | | | | > - DROPDOWN | | | | > - SUGGESTBOX | | | | > - REQUIREBOX | | | | > - DERIVED | +-------------+----------+------------------+

                                                                        "},{"location":"extensions/metadata/uiconfiguration/#label","title":"label","text":"

                                                                        If present this value will be used as the label for the field. When the label is not present in the yaml configuration the key will be used as label. Note: when the key is present in the internationalization (i18n) file see Internationalization support than the value from that file will be used as the label.

                                                                        +---------+----------+--------------+ | Key | Required | Value | +=========+==========+==============+ | > label | > no | > any string | +---------+----------+--------------+

                                                                        "},{"location":"extensions/metadata/uiconfiguration/#occurrence","title":"occurrence","text":"

                                                                        The value for occurrence determines whether or not the field should displayed as a table or as a single input field. SINGLE will result in one input field.

                                                                        e.g. single value input field of fieldType TEXT.

                                                                        Choosing REPEAT will render the field in a table allowing the user to input multiple values.

                                                                        e.g. field of fieldType TEXT rendered as a table.

                                                                        The data in table can be sorted using the green arrow buttons.

                                                                        +--------------+----------+------------------------+ | Key | Required | Value | +==============+==========+========================+ | > occurrence | > no | > - SINGLE (Default) | | | | > - REPEAT | +--------------+----------+------------------------+

                                                                        "},{"location":"extensions/metadata/uiconfiguration/#condition","title":"condition","text":"

                                                                        Conditional attributes are attributes that are only visible for some layers. A typical example are attributes only present for raster or vector layers. The condition is specified in CQL which is evaluated against the layer's ResourceInfo object.

                                                                        For example:

                                                                        condition: equalTo(typeOf(\".\"), 'FeatureTypeInfo')\n
                                                                        "},{"location":"extensions/metadata/uiconfiguration/#tab","title":"tab","text":"

                                                                        Optionally, attributes may be displayed on separate tabs. All tabs must be listed under tabs in the main configuration. Then this property is used to assign each attribute to one or more tab (separated by comma), so that the custom metadata panel is divided in tabs:

                                                                        "},{"location":"extensions/metadata/uiconfiguration/#values","title":"values","text":"

                                                                        The choices in a DROPDOWN, SUGGESTBOX or REQUIREBOX can be set using the values attribute in the yaml. This is useful for small list, for larger list it can be better to list the choices in a separate .csv file.

                                                                        "},{"location":"extensions/metadata/uiconfiguration/#derivedfrom","title":"derivedFrom","text":"

                                                                        Only used in the DERIVED field. The attribute derivedFrom contains the key for the parent on which the DERIVED field depends. Follow the link for more information on the DERIVED field.

                                                                        "},{"location":"extensions/metadata/uiconfiguration/#typename","title":"typename","text":"

                                                                        The typename is a required attribute for COMPLEX fields. It contains the key pointing to the definition of the COMPLEX field. A special typename featureAttribute is reserved for the Feature Catalog Generation and should not be used.

                                                                        "},{"location":"extensions/metadata/uiconfiguration/#field-types","title":"Field Types","text":"
                                                                        • TEXT
                                                                        • TEXT_AREA
                                                                        • UUID
                                                                        • NUMBER
                                                                        • BOOLEAN
                                                                        • DATE
                                                                        • DATETIME
                                                                        • DROPDOWN
                                                                        • SUGGESTBOX
                                                                        • REQUIREBOX
                                                                        • DERIVED
                                                                        • COMPLEX
                                                                        "},{"location":"extensions/metadata/uiconfiguration/#text","title":"TEXT","text":"

                                                                        Input field that allows any text.

                                                                        attributes:\n  - key: text-field\n    fieldType: TEXT\n
                                                                        "},{"location":"extensions/metadata/uiconfiguration/#text_area","title":"TEXT_AREA","text":"

                                                                        A multiline input.

                                                                        attributes:\n  - key: text-area-field\n      fieldType: TEXT_AREA\n
                                                                        "},{"location":"extensions/metadata/uiconfiguration/#uuid","title":"UUID","text":"

                                                                        Input field for a UUID, it allows any text input or the user can generate a UUID.

                                                                        attributes:\n  - key: uuid-field\n    fieldType: UUID\n
                                                                        "},{"location":"extensions/metadata/uiconfiguration/#number","title":"NUMBER","text":"

                                                                        Only numbers are accepted as valid input.

                                                                        attributes:\n  - key: number-field\n    fieldType: NUMBER\n
                                                                        "},{"location":"extensions/metadata/uiconfiguration/#boolean","title":"BOOLEAN","text":"

                                                                        Input field with checkbox.

                                                                        attributes:\n  - key: boolean-field\n    fieldType: BOOLEAN\n
                                                                        "},{"location":"extensions/metadata/uiconfiguration/#date","title":"DATE","text":"

                                                                        Date selection without time information.

                                                                        attributes:\n  - key: date-field\n    fieldType: DATE\n
                                                                        "},{"location":"extensions/metadata/uiconfiguration/#datetime","title":"DATETIME","text":"

                                                                        Selection date with time information.

                                                                        attributes:\n  - key: datetime-field\n    fieldType: DATETIME\n
                                                                        "},{"location":"extensions/metadata/uiconfiguration/#dropdown","title":"DROPDOWN","text":"

                                                                        A field for selecting a value from a dropdown. The values can be configured with the values attribute in the yaml or they can be configured in an other .csv file which is used for dropdowns with a lot of choices.

                                                                        Configuration in the yaml file.

                                                                        attributes:\n  - key: dropdown-field\n    fieldType: DROPDOWN\n    values:\n          - first\n          - second\n          - third\n

                                                                        To configure the values in a separate file add a yaml key csvImports on the same level as attributes and add the list of CSV files under this key. The first line in each CSV file should contain the key of the dropdown field for which you want to add the choices.

                                                                        metadata-ui.yaml

                                                                        attributes:\n  - key: dropdown-field\n    fieldType: DROPDOWN\n csvImports:\n  - dropdowncontent.csv   \n

                                                                        dropdowncontent.csv

                                                                        dropdown-field\nfirst\nsecond\nthird\n
                                                                        "},{"location":"extensions/metadata/uiconfiguration/#suggestbox","title":"SUGGESTBOX","text":"

                                                                        A field for selecting a value from a suggestbox. Suggestions will be given for the values where the input matches the beginning of the possible values. The values can be put in a separate CSV file in the same way as for the DROPDOWN field.

                                                                        attributes:\n  - key: suggestbox-field\n    fieldType: SUGGESTBOX\n    values:\n          - first\n          - second\n          - third\n
                                                                        "},{"location":"extensions/metadata/uiconfiguration/#requirebox","title":"REQUIREBOX","text":"

                                                                        This type is identical to suggestbox, except that the user is not allowed to fill in a custom value but enforced to choose a suggested value. This can be handy when an field value must be an element from a list, but this list is too long for a dropdown to be practical.

                                                                        "},{"location":"extensions/metadata/uiconfiguration/#derived","title":"DERIVED","text":"

                                                                        A derived field is a hidden field whose value depends on an other field. The yaml key derivedFrom should contain the key of the field it depends on. When a value is selected in the parent field a matching value for the derived field is searched in csv file or the value with the same index is picked from the values list.

                                                                        The CSV file should have at least two columns and start with the key of the parent field in the first column followed by the values for the parent field, the other columns should contain the key(s) of the derived field(s) in the first row followed by the matching values.

                                                                        Example derived field with config in a CSV file:

                                                                        metadata-ui.yaml

                                                                        attributes:\n  - key: derived-parent-field\n    fieldType: DROPDOWN\n  - key: hidden-field\n    fieldType: DERIVED\n    derivedFrom: derived-parent-field\ncsvImports:\n  - derived-mapping.csv\n

                                                                        derivedmapping.csv

                                                                        derived-parent-field;hidden-field\nparent-value01;hidden-value01\nparent-value02;hidden-value02\nparent-value03;hidden-value03\n

                                                                        Example derived field with values lists:

                                                                        metadata-ui.yaml

                                                                        attributes:\n  - key: derived-parent-field\n    fieldType: DROPDOWN\n    values:\n        - parent-value01\n        - parent-value02\n        - parent-value03\n  - key: hidden-field\n    fieldType: DERIVED\n    derivedFrom: derived-parent-field\n    values:\n        - hidden-value01\n        - hidden-value02\n        - hidden-value03\n
                                                                        "},{"location":"extensions/metadata/uiconfiguration/#complex","title":"COMPLEX","text":"

                                                                        A complex field is composed of multiple other fields. The yaml key typename is added to the field configuration. On the root level the yaml key types indicates the beginning of all complex type definition. A type definition should contain the typename followed by the key attributes which contains the configuration for the subfields.

                                                                        attributes:\n  - key: complex-type\n    fieldType: COMPLEX\n    typename: complex-field\n\ntypes:\n   - typename: complex-field\n     attributes:\n          - key: object-text\n            fieldType: TEXT\n          - key: object-numer\n            fieldType: NUMBER\n
                                                                        "},{"location":"extensions/metadata/uiconfiguration/#feature-catalog-generation","title":"Feature Catalog Generation","text":"

                                                                        To create a feature catalog for a vector layer, a complex structure is needed to describe all the attributes. A lot of this information is already present in the GeoServer feature type or the database. Metadata supports automatically generating a new structure in the metadata from the information at hands that can be customised afterwards. To create support for this feature in your configuration, define a repeatable COMPLEX field with built-in fieldType featureAttribute .

                                                                        In the example the featureCatalog object has two attributes. A unique identifier of the type UUID and the feature attribute field.

                                                                        e.g. Empty Feature attribute field

                                                                        - typename: featureCatalog\n  attributes:\n      - label: Unique identifier\n        key: feature-catalog-identifier\n        fieldType: UUID\n      - label: Feature attribute\n        key: feature-attribute\n        fieldType: COMPLEX\n        typename: featureAttribute\n        occurrence: REPEAT\n

                                                                        The Generate action will check the database metadata for that layer and generate a feature attribute for each column in the table.

                                                                        e.g. Feature attribute with generate feature types

                                                                        Whitin each feature attribute there is another Generate action that will generate the domain.

                                                                        e.g. Generate domain dialog

                                                                        There are two options to do this:
                                                                        • Using the existing data in the database for this attribute.
                                                                        • Using data from a look-up table in the same database. In this case you must specify the table, an attribute from which to take values and an attribute from which to take definitions.

                                                                        e.g. Feature attribute with generate domain

                                                                        "},{"location":"extensions/metadata/uiconfiguration/#internationalization-support","title":"Internationalization support","text":"

                                                                        All metadata field labels that appear in the Metadata fields can be internationalized. This is performed by creating an internationalization (i18n) file named metadata.properties. Create an entry for each key in the gui configuration following this pattern: PREFIX.attribute-key

                                                                        e.g.

                                                                        metadata.properties

                                                                        metadata.generated.form.metadata-identifier=Unique identifier for the metadata\n

                                                                        metadata_nl.properties

                                                                        metadata.generated.form.metadata-identifier=Metadata identificator\n

                                                                        Drop-down labels can be translated too, in the same properties file, using the key metadata.generated.form.[attributeKey].[value]=[label]. The value that will be internally stored for this field stays the same.

                                                                        "},{"location":"extensions/metadata/uiconfiguration/#community_metadata_uiconfiguration_hidden_fields","title":"Hidden Fields","text":"

                                                                        Hidden fields are not visible in the GUI and do not need to be configured. They are updated automatically.

                                                                        • _timestamp: date and time of the last metadata update.
                                                                        "},{"location":"extensions/metadata/user/","title":"User Guide","text":"

                                                                        To add metadata to a layer follow the steps in Adding metadata to Layer . When the metadata is repeated in multiple layers it is easier to create a template and reuse the data in the template for all the layers. See Templates .

                                                                        "},{"location":"extensions/metadata/user/#adding-metadata-to-layer","title":"Adding metadata to Layer","text":""},{"location":"extensions/metadata/user/#manually-adding-metadata","title":"Manually adding metadata","text":"

                                                                        Open the layer: navigate to Layers \u2192 Choose the layer \u2192 Metadata tab.

                                                                        The metadata fields are available in the panel Metadata fields.

                                                                        "},{"location":"extensions/metadata/user/#import-from-geonetwork","title":"Import from geonetwork","text":"

                                                                        See Advanced Configuration. Choose a geonetwork from the drop downbox, add the UUID from the metadata record and click Import. All the content of the fields that are mapped in the geonetwork mapping configuration will be deleted. All templates will be unlinked. The content will be replaced with the content from geonetwork.

                                                                        "},{"location":"extensions/metadata/user/#link-with-metadata-template","title":"Link with metadata template","text":"

                                                                        A metadata template can contain the content for metadata fields used in multiple layers. By defining these fields in a template you create one source for the content making it easier to maintain.

                                                                        To link a layer with template navigate to Layers \u2192 Choose the layer \u2192 Metadata tab in the Link with Template panel choose a template from the dropdown and click Link with template

                                                                        The values from the template will added to the metadata of the layer. How this is done depents on the type of the field.

                                                                        The field is not a list

                                                                        When the field is not a list the value will be replaced with the value from the template and the field will be read only. This will only happen for fields that are not empty in the template.

                                                                        The Field is a list

                                                                        For Fields that are a list the values from the template will be added as read only fields. The duplicate values in list will be removed if there are any.

                                                                        When multiple templates are linked with a layer the priority of the template will determine which values are added. If a field is present in both templates the value of the template with the highest priority will be picked. The priority is determined by the template order

                                                                        "},{"location":"extensions/metadata/user/#copy-from-other-layer","title":"Copy from other Layer","text":"

                                                                        Choose another layer from the drop downbox click Copy. Content will be replaced with any metadata content from the other layer, except for UUID's, which will be ignored.

                                                                        "},{"location":"extensions/metadata/user/#templates","title":"Templates","text":"

                                                                        Templates can be created, edited, deleted and ordered in Metadata \u2192 Templates . All changes to the templates will also update the linked layers when the templates are saved by clicking the Save button in the overview page. Templates that are linked to a layer cannot be removed and a warning message will appear.

                                                                        "},{"location":"extensions/metadata/user/#create-template","title":"Create template","text":"

                                                                        Use the Add new action to create a new template and choose a name for the template. The name is required and must be unique.

                                                                        "},{"location":"extensions/metadata/user/#edit-template","title":"Edit template","text":"

                                                                        Click on a template name to open the template and edit the values. Click Save to go back to the overview page, this will also recalculate the values in all linked layers.

                                                                        "},{"location":"extensions/metadata/user/#delete-template","title":"Delete template","text":"

                                                                        Select the templates that needs to be removed and click delete, the selected rows will be removed from the table. Save the changes by clicking the Save button.

                                                                        "},{"location":"extensions/metadata/user/#template-order","title":"Template order","text":"

                                                                        The templates have an order. The templates at the top of the list have a higher priority than the templates at the bottom. When a field has a value in multiple templates and the layer is linked with those templates the priority will determine which value is displayed in the metadata UI. The value defined in the template with the highest priority will be displayed.

                                                                        Change the order of the templates with the arrow keys in the priority column and save the changes by clicking Save button, this will also recalculate the values in all linked layers that may be affected.

                                                                        "},{"location":"extensions/metadata/user/#bulk-operations","title":"Bulk Operations","text":"

                                                                        This page provides a number of bulk operations mostly used for maintenance and migrations.

                                                                        "},{"location":"extensions/metadata/user/#clean-fix-all","title":"Clean / fix all","text":"

                                                                        This operation will go through all layers and perform a series of different actions on each of them to clean and repair any obsolete, corrupt or inconsistent data. This operation is useful after changing the metadata attribute configuration, bug fixes or other software updates, or exceptionally, unexpected failures.

                                                                        The actions performed are:
                                                                        • remove any existing metadata that is not according to the configuration
                                                                        • check the internal data structure and fix it if necessary
                                                                        • recalculate derived metadata fields
                                                                        • recalculate Custom to Native Mapping
                                                                        • Timestamp
                                                                        "},{"location":"extensions/metadata/user/#import-metadata","title":"Import metadata","text":"

                                                                        This option allows bulk import of metadata from GeoNetwork (see Advanced Configuration) and/or linking layers to templates. The layers that should be imported or linked are specified in a CSV file. You may specify a GeoNetwork to import from.

                                                                        The CSV file should use semicolumn as separator. The first column of your CSV files should be the layer name, the second column should be the geonetwork UUID (or left empty if you do not want to import from geonetwork), and any number of templates may be specified afterwards in the following columns.

                                                                        "},{"location":"extensions/metadata/user/#transfer-native-to-custom","title":"Transfer Native To Custom","text":"

                                                                        This operation will attempt to do the exact reverse of the Custom to Native Mapping that happens usually each time you save a layer. This will work in so far as the native attributes follow the patterns configured in your custom-to-native mapping configuration, or your configuration is basic enough. This operation is useful when you are migrating layers that were previously configured without the metadata module.

                                                                        You may optionally specify a selected list of rules if you do not wish to apply all them (by number, in the order of which they appear in the configuration), and a text file with layer names if you do not wish to go through all of them.

                                                                        "},{"location":"extensions/metadata/user/#clear-metadata","title":"Clear metadata","text":"

                                                                        Removes all existing metadata from all layers. Optionally, remove all existing templates as well. This cannot be undone.

                                                                        "},{"location":"extensions/mongodb/","title":"MongoDB Data Store","text":"

                                                                        This module provides support for MongoDB data store. This extension is build on top of GeoTools MongoDB plugin.

                                                                        "},{"location":"extensions/mongodb/#installation","title":"Installation","text":"
                                                                        1. Visit the website download page, locate your release, and download: mongodb

                                                                          The download link will be in the Extensions section under Vector Formats.

                                                                          Warning

                                                                          Make sure to match the version of the extension (for example 2.24.2 above) to the version of the GeoServer instance!

                                                                        2. Extract the files in this archive to the WEB-INF/lib directory of your GeoServer installation.

                                                                        3. Restart GeoServer

                                                                        "},{"location":"extensions/mongodb/#usage","title":"Usage","text":"

                                                                        If the extension was successfully installed a new type of data store named MongoDB should be available:

                                                                        MongoDB data store.

                                                                        Configuring a new MongoDB data store requires providing:

                                                                        1. The URL of a MongoDB database.
                                                                        2. The absolute path to a data directory where GeoServer will store the schema produced for the published collections.

                                                                        Configuring a MongoDB data store.

                                                                        For more details about the usage of this data store please check the GeoTools MongoDB plugin documentation.

                                                                        "},{"location":"extensions/monitoring/","title":"Monitoring","text":"

                                                                        The monitor extension tracks requests made against a GeoServer instance. With the extension request data can be persisted to a database, used to generate simple reports , and routed to a customized request audit log.

                                                                        To get the extension proceed to Installing the Monitor Extension. To learn more about how it works jump to the Monitoring Overview section.

                                                                        • Installing the Monitor Extension
                                                                        • Monitoring Overview
                                                                        • Data Reference
                                                                        • Monitor Configuration
                                                                        • Audit Logging
                                                                        • Monitor Query API
                                                                        • GeoIP
                                                                        "},{"location":"extensions/monitoring/audit/","title":"Audit Logging","text":"

                                                                        The history mode logs all requests into a database. This can put a very significant strain on the database and can lead to insertion issues as the request table begins to host millions of records.

                                                                        As an alternative to the history mode it's possible to enable the auditing logger, which will log the details of each request in a file, which is periodically rolled. Secondary applications can then process these log files and built ad-hoc summaries off line.

                                                                        "},{"location":"extensions/monitoring/audit/#configuration","title":"Configuration","text":"

                                                                        The monitor.properties file can contain the following items to enable and configure file auditing:

                                                                        audit.enabled=true\naudit.path=/path/to/the/logs/directory\naudit.roll_limit=20\n

                                                                        The audit.enable is used to turn on the logger (it is off by default). The audit.path is the directory where the log files will be created. The audit.roll_limit is the number of requests logged into a file before rolling happens. The files are also automatically rolled at the beginning of each day.

                                                                        In clustered installations with a shared data directory the audit path will need to be different for each node. In this case it's possible to specify the audit path by using a JVM system variable, add the following to the JVM startup options and it will override whatever is specified in monitor.properties:

                                                                        -DGEOSERVER_AUDIT_PATH=/path/to/the/logs/directory

                                                                        "},{"location":"extensions/monitoring/audit/#log-files","title":"Log Files","text":"

                                                                        The log directory will contain a number of log files following the geoserver_audit_yyyymmdd_nn.log pattern. The nn is increased at each roll of the file. The contents of the log directory will look like:

                                                                        geoserver_audit_20110811_2.log\ngeoserver_audit_20110811_3.log\ngeoserver_audit_20110811_4.log\ngeoserver_audit_20110811_5.log\ngeoserver_audit_20110811_6.log\ngeoserver_audit_20110811_7.log\ngeoserver_audit_20110811_8.log\n

                                                                        By default each log file contents will be a xml document looking like the following:

                                                                        <?xml version=\"1.0\" encoding=\"UTF-8\" ?>\n<Requests>\n    <Request id=\"168\">\n       <Service>WMS</Service> \n       <Version>1.1.1</Version>\n       <Operation>GetMap</Operation> \n       <SubOperation></SubOperation>\n       <Resources>GeoSolutions:elba-deparea</Resources>\n       <ResourcesProcessingTime>4</ResourcesProcessingTime>\n       <LabelsProcessingTime>0</LabelsProcessingTime>\n       <Path>/GeoSolutions/wms</Path>\n       <QueryString>LAYERS=GeoSolutions:elba-deparea&amp;STYLES=&amp;FORMAT=image/png&amp;TILED=true&amp;TILESORIGIN=9.916,42.312&amp;SERVICE=WMS&amp;VERSION=1.1.1&amp;REQUEST=GetMap&amp;EXCEPTIONS=application/vnd.ogc.se_inimage&amp;SRS=EPSG:4326&amp;BBOX=9.58375,42.64425,9.916,42.9765&amp;WIDTH=256&amp;HEIGHT=256</QueryString>\n       <HttpMethod>GET</HttpMethod>\n       <StartTime>2011-08-11T20:19:28.277Z</StartTime> \n       <EndTime>2011-08-11T20:19:28.29Z</EndTime>\n       <TotalTime>13</TotalTime> \n       <RemoteAddr>192.168.1.5</RemoteAddr>\n       <RemoteHost>192.168.1.5</RemoteHost>\n       <Host>demo1.geo-solutions.it</Host> \n       <RemoteUser>admin</RemoteUser>\n       <ResponseStatus>200</ResponseStatus>\n       <ResponseLength>1670</ResponseLength>\n       <ResponseContentType>image/png</ResponseContentType>\n       <Failed>false</Failed>\n    </Request>\n    ...\n</Requests>\n
                                                                        "},{"location":"extensions/monitoring/audit/#customizing-log-contents","title":"Customizing Log Contents","text":"

                                                                        The log contents are driven by three FreeMarker templates.

                                                                        header.ftl is used once when a new log file is created to form the first few lines of the file. The default header template is:

                                                                        <?xml version=\"1.0\" encoding=\"UTF-8\" ?>\n<Requests>\n

                                                                        content.ftl is used to write out the request details. The default template dumps all the known fields about the request:

                                                                        <#escape x as x?xml>\n<Request id=\"${id!\"\"}\">\n   <Service>${service!\"\"}</Service> \n   <Version>${owsVersion!\"\"}</Version>\n   <Operation>${operation!\"\"}</Operation> \n   <SubOperation>${subOperation!\"\"}</SubOperation>\n   <Resources>${resourcesList!\"\"}</Resources>\n   <ResourcesProcessingTime>${resourcesProcessingTimeList!\"\"}</ResourcesProcessingTime>\n   <LabelsProcessingTime>${labellingProcessingTime!\"\"}</LabelsProcessingTime>\n   <Path>${path!\"\"}</Path>\n   <QueryString>${queryString!\"\"}</QueryString>\n   <#if bodyAsString??>\n   <Body>\n   ${bodyAsString}\n   </Body>\n   <!--#if-->\n   <HttpMethod>${httpMethod!\"\"}</HttpMethod>\n   <StartTime>${startTime?datetime?iso_utc_ms}</StartTime> \n   <EndTime>${endTime?datetime?iso_utc_ms}</EndTime>\n   <TotalTime>${totalTime}</TotalTime> \n   <RemoteAddr>${remoteAddr!\"\"}</RemoteAddr>\n   <RemoteHost>${remoteHost!\"\"}</RemoteHost>\n   <Host>${host}</Host> \n   <RemoteUser>${remoteUser!\"\"}</RemoteUser>\n   <ResponseStatus>${responseStatus!\"\"}</ResponseStatus>\n   <ResponseLength>${responseLength?c}</ResponseLength>\n   <ResponseContentType>${responseContentType!\"\"}</ResponseContentType>\n   <CacheResult>${cacheResult!\"\"}</CacheResult>\n   <MissReason>${missReason!\"\"}</MissReason>\n   <#if error??>\n   <Failed>true</Failed>\n   <ErrorMessage>${errorMessage!\"\"}</ErrorMessage>\n   <#else>\n   <Failed>false</Failed>\n   <!--#if-->\n</Request>\n<!--#escape-->\n

                                                                        footer.ftl is executed just once when the log file is closed to build the last few lines of the file. The default footer template is:

                                                                        </Requests>\n

                                                                        The administrator is free to provide alternate templates, they can be placed in the same directory as monitor.properties, with the same names as above. GeoServer will pick them up automatically.

                                                                        "},{"location":"extensions/monitoring/configuration/","title":"Monitor Configuration","text":"

                                                                        Many aspects of the monitor extension are configurable. All configuration files are stored in the data directory under the monitoring directory:

                                                                        <data_directory>\n    monitoring/\n        filter.properties\n        monitor.properties\n

                                                                        The monitor.properties file is the main configuration file whose contents are described in the following sections. The filter.properties allows for filtering out those requests from being monitored.

                                                                        Database persistence with hibernate is described in more detail in the Database Persistence section.

                                                                        "},{"location":"extensions/monitoring/configuration/#monitor_storage","title":"Monitor Storage","text":"

                                                                        How request data is persisted is configurable via the storage property defined in the monitor.properties file. The following values are supported for the storage property:

                                                                        • memory - Request data is to be persisted in memory alone.

                                                                        The default value is memory.

                                                                        The \"monitor hibernate\" community module allows to also store the requests in a relational database.

                                                                        "},{"location":"extensions/monitoring/configuration/#memory-storage","title":"Memory Storage","text":"

                                                                        With memory storage only the most recent 100 requests are stored. And by definition this storage is volatile in that if the GeoServer instance is restarted, shutdown, or crashes this data is lost.

                                                                        "},{"location":"extensions/monitoring/configuration/#monitor_mode","title":"Monitor Mode","text":"

                                                                        The monitor extension supports different \"monitoring modes\" that control how request data is captured. Currently two modes are supported:

                                                                        • history (Default) - Request information updated post request only. No live information made available.
                                                                        • live - Information about a request is captured and updated in real time.

                                                                        The monitor mode is set with the mode property in the monitor.properties file. The default value is history.

                                                                        "},{"location":"extensions/monitoring/configuration/#history-mode","title":"History Mode","text":"

                                                                        History mode persists information (sending it to storage) about a request after a request has completed. This mode is appropriate in cases where a user is most interested in analyzing request data after the fact and doesn't require real time updates.

                                                                        "},{"location":"extensions/monitoring/configuration/#live-mode","title":"Live Mode","text":"

                                                                        Live mode updates request data (sending it to storage) in real time as it changes. This mode is suitable for users who care about what a service is doing now.

                                                                        "},{"location":"extensions/monitoring/configuration/#bounding-box","title":"Bounding Box","text":"

                                                                        When applicable one of the attributes the monitor extension can capture is the request bounding box. In some cases, such as WMS and WCS requests, capturing the bounding box is easy. However in other cases such as WFS it is not always possible to 100% reliably capture the bounding box. An example being a WFS request with a complex filter element.

                                                                        How the bounding box is captured is controlled by the bboxMode property in the monitor.properties file. It can have one of the following values.

                                                                        • none - No bounding box information is captured.
                                                                        • full - Bounding box information is captured and heuristics are applied for WFS requests.
                                                                        • no_wfs - Bounding box information is captured except for WFS requests.

                                                                        Part of a bounding box is a coordinate reference system (crs).Similar to the WFS case it is not always straight forward to determine what the crs is. For this reason the bboxCrs property is used to configure a default crs to be used. The default value for the property is \"EPSG:4326\" and will be used in cases where all lookup heuristics fail to determine a crs for the bounding box.

                                                                        "},{"location":"extensions/monitoring/configuration/#request-body-size","title":"Request Body Size","text":"

                                                                        The monitor extension will capture the contents of the request body when a body is specified as is common with a PUT or POST request. However since a request body can be large the extension limits the amount captured to the first 1024 bytes by default.

                                                                        A value of 0 indicates that no data from the request body should be captured. A value of -1 indicates that no limit should be placed on the capture and the entire body content should be stored.

                                                                        This limit is configurable with the maxBodySize property of the monitor.properties file.

                                                                        Note

                                                                        When using database persistence it is important to ensure that the size of the body field in the database can accommodate the maxBodySize property.

                                                                        "},{"location":"extensions/monitoring/configuration/#ignore-post-processors","title":"Ignore Post Processors","text":"

                                                                        The monitor passes request information through post processors which enrich the request information with DNS lookup, Location using IP database etc. It is possible to disable these post processors if some enrichments are not required with ignorePostProcessors property of the monitor.properties file.

                                                                        This parameter takes comma separated names of known post processors. The valid values are reverseDNS,geoIp,layerNameNormalizer

                                                                        "},{"location":"extensions/monitoring/configuration/#request_filters","title":"Request Filters","text":"

                                                                        By default not all requests are monitored. Those requests excluded include any web admin requests or any Monitor Query API requests. These exclusions are configured in the filter.properties file:

                                                                        /rest/monitor/**\n/web/**\n

                                                                        These default filters can be changed or extended to filter more types of requests. For example to filter out all WFS requests the following entry is added:

                                                                        /wfs\n
                                                                        "},{"location":"extensions/monitoring/configuration/#monitoring-threads","title":"Monitoring threads","text":"

                                                                        You can choose the number of post processor threads by configuring the postProcessorThreads property in the monitor.properties file. The default is 2.

                                                                        "},{"location":"extensions/monitoring/configuration/#dns-cache-configuration","title":"DNS cache configuration","text":"

                                                                        The reverseDNS post processor caches its result. You can modify the cache configuration by configuring the dnsCacheConfiguration property in the monitor.properties file. The default policy is expireAfterWrite=15m,maximumSize=1000 . Consult the guava cache builder documentation for all possibilities.

                                                                        "},{"location":"extensions/monitoring/configuration/#how-to-determine-the-filter-path","title":"How to determine the filter path","text":"

                                                                        The contents of filter.properties are a series of ant-style patterns that are applied to the path of the request. Consider the following request:

                                                                        http://localhost:8080/geoserver/wms?request=getcapabilities\n

                                                                        The path of the above request is /wms. In the following request:

                                                                        http://localhost:8080/geoserver/rest/workspaces/topp/datastores.xml\n

                                                                        The path is /rest/workspaces/topp/datastores.xml.

                                                                        In general, the path used in filters is comprised of the portion of the URL after /geoserver (including the preceding /) and before the query string ?:

                                                                        http://<host>:<port>/geoserver/<path>?<queryString>\n

                                                                        Note

                                                                        For more information about ant-style pattern matching, see the Apache Ant manual.

                                                                        "},{"location":"extensions/monitoring/configuration/#samples","title":"Samples","text":""},{"location":"extensions/monitoring/configuration/#monitorproperties","title":"monitor.properties","text":"
                                                                        # storage and mode\nstorage=memory\nmode=history\n\n# request body capture\nmaxBodySize=1024\n\n# bounding box capture\nbboxMode=no_wfs\nbboxCrs=EPSG:4326\n
                                                                        "},{"location":"extensions/monitoring/configuration/#filterproperties","title":"filter.properties","text":"
                                                                        # filter out monitor query api requests\n/rest/monitor/**\n\n# filter out all web requests\n/web\n/web/**\n\n# filter out requests for WCS service\n/wcs\n
                                                                        "},{"location":"extensions/monitoring/geoip/","title":"GeoIP","text":"

                                                                        The monitor extension has the capability to integrate with the MaxMind GeoIP database in order to provide geolocation information about the origin of a request. This functionality is not enabled by default.

                                                                        Note

                                                                        At this time only the freely available GeoLite City database is supported.

                                                                        "},{"location":"extensions/monitoring/geoip/#enabling-geoip-lookup","title":"Enabling GeoIP Lookup","text":"

                                                                        In order to enable the GeoIP lookup capabilities

                                                                        1. Download the GeoLite City database.
                                                                        2. Uncompress the file and copy GeoLiteCity.dat to the monitoring directory.
                                                                        3. Restart GeoServer.
                                                                        "},{"location":"extensions/monitoring/installation/","title":"Installing the Monitor Extension","text":"

                                                                        Note

                                                                        If performing an upgrade of the monitor extension please see Upgrading.

                                                                        The monitor extension is not part of the GeoServer core and must be installed as a plug-in. To install:

                                                                        1. Visit the website download page, locate your release, and download: monitor

                                                                          The download link will be in the Extensions section under Other.

                                                                          Warning

                                                                          Make sure to match the version of the extension (for example 2.24.2 above) to the version of the GeoServer instance!

                                                                        2. Extract the files in this archive to the WEB-INF/lib directory of your GeoServer installation.

                                                                        3. Restart GeoServer

                                                                        "},{"location":"extensions/monitoring/installation/#verifying-the-installation","title":"Verifying the Installation","text":"

                                                                        There are two ways to verify that the monitoring extension has been properly installed.

                                                                        1. Start GeoServer and open the Web administration interface. Log in using the administration account. If successfully installed, there will be a Monitor section on the left column of the home page.

                                                                        Monitoring section in the web admin interface

                                                                        1. Start GeoServer and navigate to the current GeoServer data directory. If successfully installed, a new directory named monitoring will be created in the data directory.
                                                                        "},{"location":"extensions/monitoring/overview/","title":"Monitoring Overview","text":"

                                                                        The following diagram outlines the architecture of the monitor extension:

                                                                        Monitor extension architecture

                                                                        As a request is processed the monitor inserts itself at particular points in the request life cycle to capture various information about the request. Such information includes:

                                                                        • Timestamp of the origin of the request
                                                                        • Total time it took for the request to complete
                                                                        • Origin of the request
                                                                        • HTTP information such as the body content type, header information, etc...

                                                                        And more. See the Data Reference section for a complete list.

                                                                        In addition to capturing request data the monitor extension is also capable of persisting it. Two options are provided out of the box:

                                                                        • Persisting to a relational database, see Database Persistence for more details
                                                                        • Piping to a log file, see Audit Logging for more details

                                                                        By default the extension will do neither and simply maintain data for only the most recent requests. The data is stored in memory meaning that if the server is restarted or shutdown this information is lost.The Monitor Configuration section provides a comprehensive guide to configuring the monitor extension.

                                                                        Stored request information is made available through a simple query api that allows clients to access request data through a HTTP interface.

                                                                        "},{"location":"extensions/monitoring/query/","title":"Monitor Query API","text":"

                                                                        The monitor extension provides a simple HTTP-based API for querying request information. It allows retrieving individual request records or sets of request records, in either HTML or CSV format. Records can be filtered by time range and the result set sorted by any field. Large result sets can be paged over multiple queries.

                                                                        "},{"location":"extensions/monitoring/query/#examples","title":"Examples","text":"

                                                                        The following examples show the syntax for common Monitoring queries.

                                                                        "},{"location":"extensions/monitoring/query/#all-requests-as-html","title":"All requests as HTML","text":"

                                                                        The simplest query is to retrieve an HTML document containing information about all requests:

                                                                        GET http://localhost:8080/geoserver/rest/monitor/requests.html\n
                                                                        "},{"location":"extensions/monitoring/query/#all-requests-as-csv","title":"All requests as CSV","text":"

                                                                        Request information can be returned in CSV format, for easier post-processing:

                                                                        GET http://localhost:8080/geoserver/rest/monitor/requests.csv\n

                                                                        Request bodies containing newlines are handled with quoted text. If your CSV reader doesn't handle quoted newlines, it will not work correctly.

                                                                        "},{"location":"extensions/monitoring/query/#all-requests-as-pkzip","title":"All requests as PKZip","text":"

                                                                        A PKZip archive containing the CSV file above, with all the request bodies and errors as separate files:

                                                                        GET http://localhost:8080/geoserver/rest/monitor/requests.zip\n
                                                                        "},{"location":"extensions/monitoring/query/#all-requests-as-ms-excel","title":"All requests as MS Excel","text":"

                                                                        A Microsoft Excel spreadsheet containing the same information as the CSV file:

                                                                        GET http://localhost:8080/geoserver/rest/monitor/requests.xls\n
                                                                        "},{"location":"extensions/monitoring/query/#requests-during-a-time-period","title":"Requests during a time period","text":"

                                                                        Requests can be filtered by date and time range:

                                                                        GET http://localhost:8080/geoserver/rest/monitor/requests.html?from=2010-06-20&to=2010-07-20\nGET http://localhost:8080/geoserver/rest/monitor/requests.html?from=2010-06-20T2:00:00&to=2010-06-20T16:00:00\n
                                                                        "},{"location":"extensions/monitoring/query/#request-set-paging","title":"Request set paging","text":"

                                                                        Large result sets can be paged over multiple queries:

                                                                        GET http://localhost:8080/geoserver/rest/monitor/requests.html?count=100\nGET http://localhost:8080/geoserver/rest/monitor/requests.html?count=100&offset=100\nGET http://localhost:8080/geoserver/rest/monitor/requests.html?count=100&offset=200\nGET http://localhost:8080/geoserver/rest/monitor/requests.html?count=100&offset=300\n
                                                                        "},{"location":"extensions/monitoring/query/#single-request","title":"Single request","text":"

                                                                        An individual request can be retrieved by specifying its ID:

                                                                        GET http://localhost:8080/geoserver/rest/monitor/requests/12345.html\n
                                                                        "},{"location":"extensions/monitoring/query/#api-reference","title":"API Reference","text":"

                                                                        There are two kinds of query: one for single requests, and one for sets of requests.

                                                                        "},{"location":"extensions/monitoring/query/#single-request-query","title":"Single Request Query","text":"

                                                                        A query for a single request record has the structure:

                                                                        GET http://<host>:<port>/geoserver/rest/monitor/requests/<id>.<format>\n

                                                                        where id is the numeric identifier of a single request, and format specifies the representation of the returned result as one of:

                                                                        • html - an HTML table.
                                                                        • csv - a Comma Separated Values table.
                                                                        • zip - PKZip archive containing CSV as above, plus plain text of errors and request body.
                                                                        • xls - Microsoft Excel spreadsheet.

                                                                        Note

                                                                        An alternative to specifying the returned representation with the format extension is to use the http Accept header and specify the MIME type as one of:

                                                                        • text/html
                                                                        • application/csv
                                                                        • application/zip
                                                                        • application/vnd.ms-excel

                                                                        See the HTTP specification for more information about the Accept header.

                                                                        "},{"location":"extensions/monitoring/query/#request-set-query","title":"Request Set Query","text":"

                                                                        The structure of a query for a set of requests is:

                                                                        GET http://<host>:<port>/geoserver/rest/monitor/requests.<format>[?parameter{&parameter}]\n

                                                                        where format is as described above, and parameter is one or more of the parameters listed below.

                                                                        The request set query accepts various parameters that control what requests are returned and how they are sorted. The available parameters are:

                                                                        "},{"location":"extensions/monitoring/query/#count-parameter","title":"count Parameter","text":"

                                                                        Specifies how many records should be returned.

                                                                        Syntax Example count=<integer> requests.html?count=100"},{"location":"extensions/monitoring/query/#offset-parameter","title":"offset Parameter","text":"

                                                                        Specifies where in the result set records should be returned from.

                                                                        Syntax Example offset=<integer> requests.html?count=100&offset=500"},{"location":"extensions/monitoring/query/#live-parameter","title":"live Parameter","text":"

                                                                        Specifies that only live (currently executing) requests be returned.

                                                                        Syntax Example live=<yes|no|true|false> requests.html?live=yes

                                                                        This parameter relies on a Monitor Mode being used that maintains real time request information (either live or mixed).

                                                                        "},{"location":"extensions/monitoring/query/#from-parameter","title":"from Parameter","text":"

                                                                        Specifies an inclusive lower bound on the timestamp for the start of a request. The timestamp can be specified to any desired precision.

                                                                        Syntax Example from=<timestamp> requests.html?from=2010-07-23T16:16:44 requests.html?from=2010-07-23"},{"location":"extensions/monitoring/query/#to-parameter","title":"to Parameter","text":"

                                                                        Specifies an inclusive upper bound on the timestamp for the start of a request. The timestamp can be specified to any desired precision.

                                                                        Syntax Example to=<timestamp> requests.html?to=2010-07-24T00:00:00 requests.html?to=2010-07-24"},{"location":"extensions/monitoring/query/#order-parameter","title":"order Parameter","text":"

                                                                        Specifies which request attribute to sort by, and optionally specifies the sort direction.

                                                                        Syntax Example order=<attribute>[;<ASC|DESC>] requests.html?order=path requests.html?order=startTime;DESC requests.html?order=totalTime;ASC"},{"location":"extensions/monitoring/reference/","title":"Data Reference","text":"

                                                                        The following is a list of all the attributes of a request that are captured by the monitor extension.

                                                                        "},{"location":"extensions/monitoring/reference/#general","title":"General","text":"Attribute Description Type ID Numeric identifier of the request. Every request is assigned an identifier upon its creation. Numeric Status Status of the request. See notes below. String Category The type of request being made, for example an OGC service request, a REST call, etc... See notes below. String Start time The time of the start of the request. Timestamp End time The time of the completion of the request. Timestamp Total time The total time spent handling the request, measured in milliseconds, equal to the end time - start time. Numeric Error message The exception message if the request failed or resulted in an error. String Error The raw exception if the message failed or resulted in an error. Text blob"},{"location":"extensions/monitoring/reference/#status","title":"Status","text":"

                                                                        The status of a request changes over it's life cycle and may have one of the following values:

                                                                        • WAITING - The request has been received by the server, but is queued and not yet being actively handled.
                                                                        • RUNNING - The request is in the process of being handled by the server.
                                                                        • FINISHED - The request has been completed and finished normally.
                                                                        • FAILED - The request has been completed but resulted in an error.
                                                                        • CANCELLED - The request was cancelled before it could complete.
                                                                        • INTERRUPTED - The request was interrupted before it could complete.
                                                                        "},{"location":"extensions/monitoring/reference/#category","title":"Category","text":"

                                                                        Requests are grouped into categories that describe the nature or type of the request. The following are the list of all categories:

                                                                        • OWS - The request is an OGC service request.
                                                                        • REST - The request is a REST service request.
                                                                        • OTHER - All other requests.
                                                                        "},{"location":"extensions/monitoring/reference/#http","title":"HTTP","text":"

                                                                        The following attributes are all HTTP related.

                                                                        Attribute Description Type HTTP method The HTTP method, one of GET, POST, PUT, or DELETE String Remote address The IP address of the client from which the request originated. String Remote host The hostname corresponding to the remote address, obtained via reverse DNS lookup. String Host The hostname of the server handling the request, from the point of view of the client. String Internal host The hostname of the server handling request, from the point of view of the local network. Availability depends on host and network configuration. String Path The path component of the request URL, for example: \"/wms\", \"/rest/workspaces.xml\", etc... String Query string The query string component of the request URL. Typically only present when the HTTP method is GET. String Body The body content of the request. Typically only present when the HTTP method is PUT or POST. Binary blob Body content length The total number of bytes comprising the body of the request. Typically only present when the HTTP method is PUT or POST. Numeric Body content type The mime type of the body content of the request, for example: \"application/json\", \"text/xml; subtype=gml/3.2\", etc... Typically only present when the HTTP method is PUT or POST. String Response status The HTTP response code, for example: 200, 401, etc... Numeric Response length The total number of bytes comprising the response to the request. Numeric Response content type The mime type of the response to the request. String Remote user The username specified parsed of the request. Only available when request included credentials for authentication. String Remote user agent The value of the User-Agent HTTP header. String Http referrer The value of the Referer HTTP header. String"},{"location":"extensions/monitoring/reference/#owsogc","title":"OWS/OGC","text":"

                                                                        The following attributes are OGC service specific.

                                                                        Attribute Description Type Service The OGC service identifier, for example: \"WMS\", \"WFS\", etc... String Operation The OGC operation name, for example: \"GetMap\", \"GetFeature\", etc... String Sub operation The ogc sub operation (if it applies). For instance when the operation is a WFS Transaction the sub operation may be one of \"Insert\", \"Update\", etc... String OWS/OGC Version The OGC service version, for example with WFS the version may be \"1.0.0\", \"1.1.0\", etc... String Resources Names of resources (layers, processes, etc...) specified as part of the request. List of String Resources processing times in milliseconds. Rendering times for resources. Rendering is performed by two concurrent threads, one reading and preprocessing data and styles towards a Java2D compatible format, the other painting the results of the first on the canvas. When the first thread starts reading the next layer, the second thread is likely still painting features from the layer before it, thus, times in this list are overlapping with each other, and the sum will be greater than the actual wall rendering time. List of Numeric Labels Processing Time Processing time in milliseconds for the labels of all resources listed. Numeric Bounding box The bounding box specified as part of the request. In some cases this is not possible to obtain this reliable, an example being a complex WFS query with a nested \"BBOX\" filter. List of Numeric"},{"location":"extensions/monitoring/reference/#geoip","title":"GeoIP","text":"

                                                                        The following attributes are specific to GeoIP look ups and are not captured out of the box. See GeoIP for more details.

                                                                        Attribute Description Type Remote country Name of the country of the client from which the request originated. String Remote city Name of the city from which the request originated. String Remote lat The latitude from which the request originated. Numeric Remote lon The longitude from which the request originated. Numeric"},{"location":"extensions/monitoring/reference/#gwc","title":"GWC","text":"

                                                                        The following attributes are specific to tile cached requests.

                                                                        Attribute Description Type CacheResult \"HIT\" or \"MISS\" (can be empty if GWC was not involved) String MissReason A description of why the cache was not used. Available only on requests hitting a cached layer on direct WMS integration, applies to cases where the request was not forwarded to GWC, for example \"no parameter filter exists for FEATUREID\", \"request does not align to grid(s) \"EPSG:4326\" or \"not a tile layer\". Will be missing for any request not hitting the direct integration (e.g., direct WMTS requests, for example) String"},{"location":"extensions/netcdf/netcdf/","title":"NetCDF","text":""},{"location":"extensions/netcdf/netcdf/#adding-a-netcdf-data-store","title":"Adding a NetCDF data store","text":"

                                                                        To add a NetCDF data store the user must go to Stores \u2192 Add New Store \u2192 NetCDF.

                                                                        NetCDF in the list of raster data stores

                                                                        "},{"location":"extensions/netcdf/netcdf/#configuring-a-netcdf-data-store","title":"Configuring a NetCDF data store","text":"

                                                                        Configuring a NetCDF data store

                                                                        Option Description Workspace Data Source Name Description Enabled URL"},{"location":"extensions/netcdf/netcdf/#notes-on-supported-netcdfs","title":"Notes on supported NetCDFs","text":"

                                                                        The NetCDF plugin for GeoServer supports gridded NetCDF files having dimensions following the COARDS convention (custom, Time, Elevation, Lat, Lon). The NetCDF plugin supports plain NetCDF datasets (.nc files) as well .ncml files (which aggregate and/or modify one or more datasets) and Feature Collections. It supports Forecast Model Run Collection Aggregations (FMRC) either through the NCML or Feature Collection syntax. It supports an unlimited amount of custom dimensions, including runtime.

                                                                        ToolsUI is an useful java tool developed by UCAR which can be useful for a preliminary check on your dataset. Opening a sample NetCDF using that tool will show an output like this in the Viewer tab:

                                                                        NetCDF viewer in ToolsUI

                                                                        • This dataset has 4 dimensions (time, z, lat, lon, marked by the D icon in the left side of the GUI. They have been marked by a blue rectangle in the screenshot).
                                                                        • Each dimension has an associated independent coordinate variable (marked by the green rectangle).
                                                                        • Finally, the dataset has 3 geophysical variables, marked by a red rectangle, each having 4 dimensions.

                                                                        The NetCDF plugin fully supports datasets where each variable's axis is identified by an independent coordinate variable, as shown in the previous example. There is limited support for coordinate variables with two dimensions (see Two-Dimensional Coordinate Variables), as part of the result of an aggregation (such as time,runtime - in the case of a runtime aggregation). Two dimensional non-independent latitude-longitude coordinate variables aren't currently supported. A similar dataset will look like this in ToolsUI. Look at the red marked latitude and longitude coordinate variables, each one identified by a y,x 2D matrix.

                                                                        NetCDF viewer in ToolsUI for 2D coordinate variables

                                                                        "},{"location":"extensions/netcdf/netcdf/#netcdf_multidim","title":"Two-Dimensional Coordinate Variables","text":"

                                                                        Two-dimension coordinate variables are exposed in GeoServer as single dimensions. Their domain is exposed in GetCapabilities as a flat list of possible values. However, they imply an interdependence between the different dimensions, where some combinations of values exist (have data) and other combinations do not. For example:

                                                                        +-----------+----------+----------+----------+----------+ | > Runtime | | > Time | | | +===========+==========+==========+==========+==========+ | | | > 0 | > 1 | > 2 | +-----------+----------+----------+----------+----------+ | 0 | 1/1/2017 | 1/1/2017 | \u00bd/2017 | \u00bc/2017 | +-----------+----------+----------+----------+----------+ | 1 | \u00bd/2017 | \u00bd/2017 | \u2153/2017 | > XXXX | +-----------+----------+----------+----------+----------+ | 2 | \u2153/2017 | \u2153/2017 | > XXXX | > XXXX | +-----------+----------+----------+----------+----------+

                                                                        The time dimension would thus be exposed in GeoServer as {1/1/2017, \u00bd/2017, \u2153/2017, \u00bc/2017}. However, the combinations (runtime=1/1/2017, time=\u2153/2017), (runtime=\u00bd/2017, time=1/1/2017), (runtime=\u00bd/2017, time=\u00bc/2017) , (runtime=\u2153/2017, time=1/1/2017), (runtime=\u2153/2017, time=\u00bd/2017) and (runtime=\u2153/2017, time=\u00bc/2017) do not exist.

                                                                        Some additional functionality was introduced to maximally exploit two-dimensional coordinate variables:

                                                                        • With requests that do not specify certain dimension values, we want to select default values that makes sense with regards to the dimensions values that were specified in the request. More specifically we want the maximum or minimum of the domain that matches the specified request's other dimension values; rather than the maximum or minimum of the entire domain.
                                                                        • The user may want to query which combination of dimension values do exist and which don't. This can be done through an Auxiliary Vector Store that publishes the entire index.

                                                                        A number of system properties allow us to configure this behavior:

                                                                        • org.geotools.coverage.io.netcdf.param.max

                                                                          A comma separated list of dimensions that must be maximised when their value is absent in the request. In the layer configuration, the default value of these dimensions must be set to 'Built-in'.

                                                                        • org.geotools.coverage.io.netcdf.param.min

                                                                          A comma separated list of dimensions that must be minimised when their value is absent in the request. In the layer configuration, the default value of these dimensions must be set to 'Built-in'.

                                                                        • org.geotools.coverage.io.netcdf.auxiliary.store

                                                                          Set to TRUE to display the 'NetCDF Auxiliary Store' option in Geoserver. A NetCDF Auxiliary Store must be published after publishing the actual NetCDF store.

                                                                        The NetCDF Auxiliary Store returns a WFS record like this for each possible combination of dimension values that do not include the two prime spatial dimensions:

                                                                        <topp:my-aux-store gml:id=\"1\">\n <topp:the_geom>\n  <gml:Polygon srsName=\"http://www.opengis.net/gml/srs/epsg.xml#4326\" srsDimension=\"2\">\n   <gml:exterior><gml:LinearRing>\n   <gml:posList>259.96003054 -0.04 259.96003054 70.04 310.03999998 70.04 310.03999998 -0.04 259.96003054   -0.04</gml:posList>\n   </gml:LinearRing></gml:exterior>\n  </gml:Polygon>\n </topp:the_geom>\n <topp:imageindex>160</topp:imageindex>\n <topp:depth>0.0</topp:depth>\n <topp:time>2017-01-01T00:00:00Z</topp:time>\n <topp:runtime>2017-01-02T00:00:00Z</topp:runtime>\n</topp:my-aux-store>\n
                                                                        "},{"location":"extensions/netcdf/netcdf/#supporting-custom-netcdf-coordinate-reference-systems","title":"Supporting Custom NetCDF Coordinate Reference Systems","text":""},{"location":"extensions/netcdf/netcdf/#grid-mapping-attributes","title":"Grid Mapping attributes","text":"

                                                                        Starting with GeoServer 2.8.x, NetCDF related modules (both NetCDF/GRIB store, imageMosaic store based on NetCDF/GRIB dataset and NetCDF output format) allow to support custom Coordinate Reference Systems and Projections. As reported in the NetCDF CF documentation, Grid mappings section a NetCDF CF file may expose gridmapping attributes to describe the underlying projection. A grid_mapping attribute in the variable refers to the name of a variable containing the grid mapping definition.

                                                                        The GeoTools NetCDF machinery will parse the attributes (if any) contained in the underlying NetCDF dataset to setup an OGC CoordinateReferenceSystem object. Once created, a CRS lookup will be made to identify a custom EPSG (if any) defined by the user to match that Projection. In case the NetCDF gridMapping is basically the same of the one exposed as EPSG entry but the matching doesn't happen, you may consider tuning the comparison tolerance: See Coordinate Reference System Configuration, Increase Comparison Tolerance section.

                                                                        Grid Mapping and related custom EPSG definition

                                                                        User defined NetCDF Coordinate Reference Systems with their custom EPSG need to be provided in user_projections\\netcdf.projections.properties file inside your data directory (you have to create that file if missing).

                                                                        A sample entry in that property file could look like this:

                                                                        971835=PROJCS[\"albers_conical_equal_area\", GEOGCS[\"unknown\", DATUM[\"unknown\", SPHEROID[\"unknown\", 6378137.0, 298.2572221010042]], PRIMEM[\"Greenwich\", 0.0], UNIT[\"degree\", 0.017453292519943295], AXIS[\"Geodetic longitude\", EAST], AXIS[\"Geodetic latitude\", NORTH]], PROJECTION[\"Albers_Conic_Equal_Area\"], PARAMETER[\"central_meridian\", -126.0], PARAMETER[\"latitude_of_origin\", 45.0], PARAMETER[\"standard_parallel_1\", 50.0], PARAMETER[\"false_easting\", 1000000.0], PARAMETER[\"false_northing\", 0.0], PARAMETER[\"standard_parallel_2\", 58.5], UNIT[\"m\", 1.0], AXIS[\"Easting\", EAST], AXIS[\"Northing\", NORTH], AUTHORITY[\"EPSG\",\"971835\"]]

                                                                        Note

                                                                        Note the \"unknown\" names for GEOGCS, DATUM and SPHEROID elements. This is how the underlying NetCDF machinery will name custom elements.

                                                                        Note

                                                                        Note the number that precedes the WKT. This will determine the EPSG code. So in this example, the EPSG code is 971835.

                                                                        Note

                                                                        When dealing with records indexing based on PostGIS, make sure the custom code isn't greater than 998999. (It took us a while to understand why we had some issues with custom codes using PostGIS as granules index. Some more details, here)

                                                                        Note

                                                                        If a parameter like \"central_meridian\" or \"longitude_of_origin\" or other longitude related value is outside the range [-180,180], make sure you adjust this value to belong to the standard range. As an instance a Central Meridian of 265 should be set as -95.

                                                                        You may specify further custom NetCDF EPSG references by adding more lines to that file.

                                                                        1. Insert the code WKT for the projection at the end of the file (on a single line or with backslash characters):

                                                                          971835=PROJCS[\"albers_conical_equal_area\", \\\n  GEOGCS[\"unknown\", \\\n    DATUM[\"unknown\", \\\n      SPHEROID[\"unknown\", 6378137.0, 298.2572221010042]],  \\\n    PRIMEM[\"Greenwich\", 0.0], \\\n    UNIT[\"degree\", 0.017453292519943295], \\\n    AXIS[\"Geodetic longitude\", EAST], \\\n    AXIS[\"Geodetic latitude\", NORTH]], \\\n  PROJECTION[\"Albers_Conic_Equal_Area\"], \\\n  PARAMETER[\"central_meridian\", -126.0], \\\n  PARAMETER[\"latitude_of_origin\", 45.0], \\\n  PARAMETER[\"standard_parallel_1\", 50.0], \\\n  PARAMETER[\"false_easting\", 1000000.0], \\\n  PARAMETER[\"false_northing\", 0.0], \\\n  PARAMETER[\"standard_parallel_2\", 58.5], \\\n  UNIT[\"m\", 1.0], \\\n  AXIS[\"Easting\", EAST], \\\n  AXIS[\"Northing\", NORTH], \\\n  AUTHORITY[\"EPSG\",\"971835\"]]\n
                                                                        2. Save the file.

                                                                        3. Restart GeoServer.

                                                                        4. Verify that the CRS has been properly parsed by navigating to the SRS List page in the Web administration interface.

                                                                        5. If the projection wasn't listed, examine the logs for any errors.

                                                                        "},{"location":"extensions/netcdf/netcdf/#projected-coordinates-with-axis-in-km","title":"Projected Coordinates with axis in km","text":"

                                                                        For GeoServer < 2.16.x, Projected Coordinates with axis units in km are automatically converted to meters and associated ProjectedCRS has Unit in meters too. Therefore, polygons stored in the geometry table have coordinates in meters.

                                                                        Starting with GeoServer 2.16.x, automatic conversion km-to-m is disabled by default in order to support km coordinates, directly. Therefore, make sure to define a proper custom CRS with km unit if you want to support it. (That is also needed if you want to publish the index as a vector layer).

                                                                        For example:

                                                                        971815=PROJCS[\"albers_conical_equal_area\", \\\n  GEOGCS[\"unknown\", \\\n    DATUM[\"unknown\", \\\n      SPHEROID[\"unknown\", 6378137.0, 298.2572221010042]],  \\\n    PRIMEM[\"Greenwich\", 0.0], \\\n    UNIT[\"degree\", 0.017453292519943295], \\\n    AXIS[\"Geodetic longitude\", EAST], \\\n    AXIS[\"Geodetic latitude\", NORTH]], \\\n  PROJECTION[\"Albers_Conic_Equal_Area\"], \\\n  PARAMETER[\"central_meridian\", -126.0], \\\n  PARAMETER[\"latitude_of_origin\", 45.0], \\\n  PARAMETER[\"standard_parallel_1\", 50.0], \\\n  PARAMETER[\"false_easting\", 1000000.0], \\\n  PARAMETER[\"false_northing\", 0.0], \\\n  PARAMETER[\"standard_parallel_2\", 58.5], \\\n  UNIT[\"km\", 1000.0], \\\n  AXIS[\"Easting\", EAST], \\\n  AXIS[\"Northing\", NORTH], \\\n  AUTHORITY[\"EPSG\",\"971815\"]]\n

                                                                        Note:

                                                                        UNIT[\"km\", 1000.0], \\\n

                                                                        Set -Dorg.geotools.coverage.io.netcdf.convertAxis.km to true to activate the automatic conversion or false to deactivate it.

                                                                        Note

                                                                        that is a global JVM setting: Any dataset with coordinates in km being configured before swapping the conversion behavior will need to be reconfigured to set the new Geometries and CRS.

                                                                        "},{"location":"extensions/netcdf/netcdf/#specify-an-external-file-through-system-properties","title":"Specify an external file through system properties","text":"

                                                                        You may also specify the NetCDF projections definition file by setting a Java system property which links to the specified file. As an instance: -Dnetcdf.projections.file=/full/path/of/the/customfile.properties

                                                                        "},{"location":"extensions/netcdf/netcdf/#wkt-attributes","title":"WKT Attributes","text":"

                                                                        Some NetCDFs may include a text attribute containing the WKT definition of a Coordinate Reference System. When present, it will be parsed by GeoServer to setup a CRS and a lookup will be performed to see if any EPSG is matching it.

                                                                        • spatial_ref

                                                                          GDAL spatial_ref attribute

                                                                        • esri_pe_string

                                                                          An attribute being defined by NetCDF CERP Metadata Convention

                                                                        "},{"location":"extensions/netcdf/netcdf/#netcdf-files-in-read-only-directories","title":"NetCDF files in read-only directories","text":"

                                                                        GeoServer creates hidden index files when accessing NetCDF files. Because these index files are created in the same directory as each NetCDF file, GeoServer will fail to publish NetCDF files if it lacks write access the containing directory.

                                                                        To permit access to NetCDF files in read-only directories, specify an alternate writeable directory for NetCDF index files by setting the NETCDF_DATA_DIR Java system property:

                                                                        -DNETCDF_DATA_DIR=/path/to/writeable/index/file/directory\n
                                                                        "},{"location":"extensions/netcdf/netcdf/#supporting-custom-netcdf-units","title":"Supporting Custom NetCDF Units","text":"

                                                                        The NetCDF format expresses units using a syntax that is not always understood by our unit parser, and often, uses unit names using unrecognized symbols or that simply unknown to it. The system already comes with some smarts, but in case a unit is not recognized, it's possible to act on the configuration and extend it.

                                                                        There are two property files that can be setup in order to modify unit magement, one is an alias file, the other is a replacement file:

                                                                        • An \"alias\" is a different symbol/name for a base unit (e.g., instead of using \"g\" the NetCDF files might be using \"grammes\")
                                                                        • A (text) \"replacement\" is used when the unit is a derived one, needing a full expression, or the syntax of the unit is simply unrecognized

                                                                        The alias file is called netcdf-unit-aliases.properties, if not provided these contents are assumed:

                                                                        # Aliases for unit names that can in turn be used to build more complex units\nMeter=m\nmeter=m\nMetre=m\nmicrogram=\u00b5g\nmicrogrammes=\u00b5g\nnanograms=ng\ndegree=deg\npercentage=%\ncelsius=\u00b0C\n````\n

                                                                        The replacement file is called netcdf-unit-replacements.properties, if not provided the following contents are assumed:

                                                                        microgrammes\\ per\\ cubic\\ meter=\u00b5g*m^-3\nDU=\u00b5mol*m^-2*446.2\nm2=m^2\nm3=m^3\ns2=s^2\n

                                                                        Both files express the NetCDF unit as the key, and the standard symbol or replacement text as the value.

                                                                        It is possible to place the files in three different locations:

                                                                        • If the NETCDF_UNIT_ALIASES and/or NETCDF_UNIT_REPLACEMENTS system variables are defined, the respective files will be looked up at the specified location (must be full paths, including the file name)
                                                                        • If the above are missing and external NetCDF data dir is defined via NETCDF_DATA_DIR then the files will be looked up in there
                                                                        • If the above are missing the root of the GeoServer data directory will be searched
                                                                        • If none of the above provide a file, then the built-in configuration will be used
                                                                        "},{"location":"extensions/netcdf/netcdf/#caching","title":"Caching","text":"

                                                                        When opening a NetCDF file, metadata and structures need to be setup, such as the Coordinate Reference System and related Coordinate Systems, the optional datastore configuration, the coverages structure (schemas and dimensions). Depending on the complexity of the file itself, those can be time consuming tasks. Operations that are continuously and repeatedly accessing the same files will be impacted by that. Therefore, starting with GeoServer 2.20.x, a caching mechanism has been setup.

                                                                        Some entities that can be considered static are internally cached once parsed: they include the NetCDF datastore configuration setup on top of the datastore properties file, the indexer built on top of the auxiliary xml file, as well as the unit of measure of the variables.

                                                                        Note

                                                                        Make sure to do a GeoServer reload if one of these config files get modified or updated, to clean the cache and allow the new settings to be used.

                                                                        "},{"location":"extensions/netcdf/netcdf/#file-caching","title":"File Caching","text":"

                                                                        An additional level of caching can be manually enabled, so that NetCDF Files can be cached and re-used. The object being cached is not the whole file, but a NetcdfDataset object, which is built on top of parsed metadata, including coordinate system info. Whenever a NetCDF dataset is being accessed, a cached instance is provided and released back to the cache-pool once done. So if there are 10 concurrent requests accessing the same NetCDF file, up to 10 different NetCDF dataset cached instances will be used.

                                                                        These Java system variables can be set to enable and configure the file caching:

                                                                        • org.geotools.coverage.io.netcdf.cachefile : boolean. set it to true to enable the dataset caching. (default: false, no files caching)
                                                                        • org.geotools.coverage.io.netcdf.cache.min : integer value representing the minimum number of datasets to be kept in cache (default: 200).
                                                                        • org.geotools.coverage.io.netcdf.cache.max : integer value representing the maximum number of datasets to be kept in cache before a cleanup get triggered (default: 300).
                                                                        • org.geotools.coverage.io.netcdf.cache.cleanup.period : integer value representing the time period (in seconds) before the next cache cleanup occurs (0 for no periodic cleanup, default is 12 minutes)

                                                                        Note

                                                                        When enabling the file caching and setting up an ImageMosaic of NetCDFs, consider disabling the Deferred Loading from the coverage configuration so that the underlying readers get access to the NetCDF dataset and release them as soon as the read is done.

                                                                        "},{"location":"extensions/netcdf/netcdf/#mosaic-of-netcdf-files","title":"Mosaic of NetCDF files","text":""},{"location":"extensions/netcdf/netcdf/#setting-up-a-basic-mosaic","title":"Setting up a basic mosaic","text":"

                                                                        A mosaic of NetCDF files is a bit different than usual, because each NetCDF file can contain multiple coverages. As a result, the mosaic setup requires extra configuration files, an indexer.xml acting as the mosaic index, and a _auxiliary.xml, describing the NetCDF file contents.

                                                                        Setting up these files can be a cumbersome process, so a utility has been written, which automatically fills their contents based on a sample NetCDF file (under the assumeption that all NetCDF files in the mosaic share the same variables and dimensions).

                                                                        Given a sample NetCDF file, you can get into the mosaic directory and run the CreateIndexer tool (for the NetCDF projection files, see above). On Windows:

                                                                        java -cp <path-to-geoserver>\\WEB-INF\\lib\\*.jar org.geotools.coverage.io.netcdf.tools.CreateIndexer <path-to-sample-nc-file> [-p <path-to-netcdf-projections>] [<path-to-output-directory>]\n

                                                                        On Linux:

                                                                        java -cp '<path-to-geoserver>/WEB-INF/lib/*' org.geotools.coverage.io.netcdf.tools.CreateIndexer <path-to-sample-nc-file> [-p <path-to-netcdf-projections>] [<path-to-output-directory>]\n

                                                                        Warning

                                                                        On older GeoServer version the command might fail complaining it cannot find org.jaxen.NamespaceContext. If that\\'s the case, download Jaxen 1.1.6, add it into the GeoServer WEB-INF/lib directory, and try again.

                                                                        This will generate the files and it\\'s going to be good enough if each NetCDF contains the same coverages. The indexer.xml file might look as follows:

                                                                        <?xml version=\"1.0\" encoding=\"UTF-8\"?><Indexer>\n  <domains>\n    <domain name=\"time\">\n      <attributes><attribute>time</attribute></attributes>\n    </domain>\n  </domains>\n  <coverages>\n    <coverage>\n      <name>dbz</name>\n      <schema name=\"dbz\">\n        <attributes>\n           the_geom:Polygon,imageindex:Integer,location:String,time:java.util.Date\n        </attributes>\n      </schema>\n      <domains>\n        <domain ref=\"time\" />\n      </domains>\n    </coverage>\n  </coverages>\n  <parameters>\n    <parameter name=\"AuxiliaryFile\" value=\"/path/to/the/mosaic/_auxiliary.xml\" />\n    <parameter name=\"AbsolutePath\" value=\"true\" />\n  </parameters>\n</Indexer>\n

                                                                        While the _auxiliary.xml file might look like:

                                                                        <?xml version=\"1.0\" encoding=\"UTF-8\"?><Indexer>\n    <coverages>\n        <coverage>\n            <schema name=\"dbz\">\n                <attributes>\n                   the_geom:Polygon,imageindex:Integer,time:java.util.Date\n                </attributes>\n            </schema>\n            <origName>dbz</origName>\n            <name>dbz</name>\n        </coverage>\n    </coverages>\n</Indexer>\n

                                                                        If instead there are different NetCDF files containing different coverages in the same mosaic, you\\'ll have to:

                                                                        • Run the above command using a different sample NetCDF file for each coverage, generating the output in different folders.
                                                                        • Manually merge them into a unified indexer.xml and _auxiliary.xml that will be placed in the mosaic directory.

                                                                        NetCDF files contain usually time dimensions, as a result, it\\'s not possible to rely on Shapefile based indexes, but use a relational database instead. So, add a datastore.properties file into the mosaic directory, pointing to a database of choice. Here is an example file, suitable to connect to a PostGIS enabled database, with a schema dedicated to contain the mosaic indexes (make sure it already exists in the database, GeoServer won\\'t create it):

                                                                        SPI=org.geotools.data.postgis.PostgisNGDataStoreFactory\nhost=localhost\nport=5432\ndatabase=netcdf\nschema=mosaic_indexes\nuser=user\npasswd=pwd\nLoose\\ bbox=true\nEstimated\\ extends=false\nvalidate\\ connections=true\nConnection\\ timeout=10\npreparedStatements=true\nmax\\ connections=20\n

                                                                        With this in place, it\\'s possible to create stores and layers in GeoServer:

                                                                        • Create a new Image Mosaic store, pointing to the mosaic directory.
                                                                        • After a bit of processing, the list of available coverages should appear, ready for layer creation.
                                                                        • Create each layer, and remember to configure time, elevation and custom dimensions in the \\\"dimensions\\\" tab.

                                                                        In case of error during the set up, the following suggestions apply:

                                                                        • Remove all extra files the mosaic might have created in the mosaic directory.
                                                                        • Remove the eventual new tables created in the database.
                                                                        • Enable the GeoTools developer logging profile in the global settings.
                                                                        • Run the mosaic creation again, inspect the logs to find out the reason (often it\\'s due to database permissions, or to NetCDF files that are not conforming to the CF conventions).
                                                                        • Repeat from the top until the mosaic creation succeeds.
                                                                        "},{"location":"extensions/netcdf/netcdf/#storing-netcdf-internal-indexes-in-a-centralized-index","title":"Storing NetCDF internal indexes in a centralized index","text":"

                                                                        By default the NetCDF reader creates a hidden directory, either as a sidecar or in the NetCDF data dir, containing a low level index file to speed up slices lookups, as well as a H2 database containing information about slice indexes and dimensions associated to them. This H2 store is opened and closed every time the associated NetCDF is read, causing less than optimal performance in map rendering.

                                                                        As an alternative, it\\'s possible to store all slice metadata from H2 to a centralized database, and have GeoServer manage the store connecting to it, thus keeping it always open. Some work is needed in order to make that happen thought.

                                                                        As a first step, create a store connection property file named netcdf_datastore.properties. Here is an example file, suitable to connect to a PostGIS enabled database, which makes the pair with the previously introduced datastore.properties :

                                                                        SPI=org.geotools.data.postgis.PostgisNGDataStoreFactory\nhost=localhost\nport=5432\ndatabase=netcdf\nschema=netcdf_indexes\nuser=user\npasswd=pwd\nLoose\\ bbox=true\nEstimated\\ extends=false\nvalidate\\ connections=true\nConnection\\ timeout=10\npreparedStatements=true\nmax\\ connections=20\n

                                                                        Notice how the NetCDF indexes are going to be stored in a different database schema, to prevent eventual table name conflicts (again, make sure the schema already exists in the database).

                                                                        GeoServer needs to be informed of this new configuration file, by editing the indexer.xml file and adding this new line in the parameters section:

                                                                        <parameter name=\"AuxiliaryDatastoreFile\" value=\"netcdf_datastore.properties\" /> \n

                                                                        The _auxiliary.xml file also needs to be modified, open it and change the attributes element(s), adding a location:String attribute right after the imageIndex:Integer attribute (position is important, mosaic construction will fail if the attribute is misplaced):

                                                                        <attributes>the_geom:Polygon,imageindex:Integer,location:String,time:java.util.Date</attributes>\n

                                                                        At this point the mosaic construction can be repeated from the GUI, just like a normal NetCDF image mosaic.

                                                                        "},{"location":"extensions/netcdf/netcdf/#migrating-mosaics-with-h2-netcdf-index-files-to-a-centralized-index","title":"Migrating mosaics with H2 NetCDF index files to a centralized index","text":"

                                                                        While the above setup allows to centralized index for NetCDF file contents. In case one already has a (very) large image mosaic of NetCDF files, having to re-harvest the NetCDF files can be time consuming and, in general, not practical.

                                                                        A utility has been created to perform the migration of existing mosaics to a centralized database index, the H2Migrate tool.

                                                                        On Windows:

                                                                        java -cp <path-to-geoserver>/WEB-INF/lib/*.jar org.geotools.coverage.io.netcdf.tools.H2Migrate -m <path-to-mosaic-directory> -is <indexPropertyFile> -v\n

                                                                        On Linux:

                                                                        java -cp '<path-to-geoserver>/WEB-INF/lib/*' org.geotools.coverage.io.netcdf.tools.H2Migrate -m <path-to-mosaic-directory> -is <indexPropertyFile> -v\n

                                                                        The tool supports other options as well, they can be discovered by running the tool without any parameter.

                                                                        Warning

                                                                        On older GeoServer version the command might fail complaining it cannot find org.apache.commons.cli.ParseException. If that\\'s the case, download commons-cli 1.1.4, add it into the GeoServer WEB-INF/lib directory, and try again.

                                                                        H2Migrate will connect to the target store using the information in indexPropertyFile, locate the granules to be migrated inspecting the mosaic contents, create a netcdf_index.properties file with StoreName=storeNameForIndex and update the mosaic to use it (basically, update the indexer.xml and all coverage property files to have a AuxiliaryDatastoreFile property pointing to netcdf_indexer.properties).

                                                                        It will also generate two files, migrated.txt and h2.txt:

                                                                        • migrated.txt contains the list of files successfully migrated, for audit purposes
                                                                        • h2.txt the list of H2 database files that can now be removed. The tool won\\'t do it automatically to ensure that the migration, but with this one one could automate removal, e.g., on Linux a simple cat h2.txt | xargs rm would do the trick (the <name>.log.db files change name often, it\\'s likely that they will have to be hunted down and removed with other means, e.g. if on Linux, using the \\\"find\\\").

                                                                        If the mosaic to be migrated is backed by a OpenSearch index, then the tool won\\'t be able to open the mosaic (it would require running inside GeoServer), so the connection parameters will have to be provided in a second property file, along with the list of tables containing the granules paths in the \\\"location\\\" attribute, e.g.:

                                                                        java -cp \\<path-to-geoserver>/WEB-INF/lib/*.jar org.geotools.coverage.io.netcdf.tools.H2Migrate -m \\<path-to-mosaic-directory> -ms \\<mosaicStorePropertyFile> -mit granule -is \\<indexPropertyFile> -isn \\<storeNameForIndex> -v

                                                                        After a successful migration, one final manual step is required. As before, the _auxiliary.xml file also needs to be modified. Open it and change the attributes element(s), adding a location:String attribute right after the imageIndex:Integer attribute (position is important, mosaic construction will fail if the attribute is mispaced):

                                                                        <attributes>the_geom:Polygon,imageindex:Integer,location:String,time:java.util.Date</attributes>\n

                                                                        Also, find every XML file holding a indexer like configuration, and add the parameter AuxiliaryDatastoreFile parameter:

                                                                        <parameter name=\"AuxiliaryDatastoreFile\" value=\"<path/to/mosaic/directory/>netcdf_datastore.properties\" /> \n

                                                                        Finally, do the same with the property files for each coverage, adding:

                                                                        AuxiliaryDatastoreFile=<path/to/mosaic/directory/>netcdf_datastore.properties\n

                                                                        The path to netcdf_datastore.properties can also be relative, but only if the image mosaic is configured to use relative paths.

                                                                        If GeoServer was running during the migration, the mosaic store just migrated needs to be reset so that it reads again its configuration: go to the mosaic store, open its configuration, and without changing any parameter, save it again: the layers backed by the mosaic are now ready to use.

                                                                        "},{"location":"extensions/netcdf-out/","title":"NetCDF Output Format","text":"

                                                                        This plugin adds the ability to encode WCS 2.0.1 multidimensional output as a NetCDF file using the Unidata NetCDF Java library.

                                                                        "},{"location":"extensions/netcdf-out/#getting-a-netcdf-output-file","title":"Getting a NetCDF output file","text":"

                                                                        Request NetCDF output by specifying format=application/x-netcdf in a GetCoverage request:

                                                                        http://localhost:8080/geoserver/wcs?service=WCS&version=2.0.1&request=GetCoverage&coverageid=it.geosolutions__V&format=application/x-netcdf...\n
                                                                        "},{"location":"extensions/netcdf-out/#current-limitations","title":"Current limitations","text":"
                                                                        • Input coverages/slices should share the same bounding box (lon/lat coordinates are the same for the whole ND cube).
                                                                        • NetCDF output will be produced only when input coverages come from a StructuredGridCoverage2D reader (this allows to query the GranuleSource to get the list of granules in order to setup dimensions slices for each sub-coverage).
                                                                        "},{"location":"extensions/netcdf-out/#netcdf-4","title":"NetCDF-4","text":"

                                                                        NetCDF-4 output is supported but requires native libraries (see Installing required NetCDF-4 Native libraries). NetCDF-4 adds support for compression. Use format=application/x-netcdf4 to request NetCDF-4 output.

                                                                        "},{"location":"extensions/netcdf-out/#settings","title":"Settings","text":"

                                                                        NetCDF output settings can be configured for each raster layer. The similar section in the Global Settings page configures the default settings used for newly created raster layers.

                                                                        • Variable Name (optional)
                                                                          • Sets the NetCDF variable name.
                                                                          • Does not change the layer name, which can be configured in the Data tab.
                                                                        • Variable Unit of Measure (optional)
                                                                          • Sets the NetCDF uom attribute.
                                                                        • Data Packing
                                                                          • Lossy compression by storing data in reduced precision.
                                                                          • One of NONE, BYTE, SHORT, or INT.
                                                                        • NetCDF-4 Compression Level
                                                                          • Lossless compression.
                                                                          • Level is an integer from 0 (no compression, fastest) to 9 (most compression, slowest).
                                                                        • NetCDF-4 Chunk Shuffling
                                                                          • Lossless byte reordering to improve compression.
                                                                        • Copy Variable Attributes from NetCDF/GRIB Source
                                                                          • Most attributes are copied from the source NetCDF/GRIB variable.
                                                                          • Some attributes such as coordinates and missing_value are skipped as these may no longer be valid.
                                                                          • For an ImageMosaic, one granule is chosen as the source.
                                                                        • Copy Global Attributes from NetCDF/GRIB Source
                                                                          • Attributes are copied from the source NetCDF/GRIB global attributes.
                                                                          • For an ImageMosaic, one granule is chosen as the source.
                                                                        • Variable Attributes
                                                                          • Values are encoded as integers or doubles if possible, otherwise strings.
                                                                          • Values set here overwrite attributes set elsewhere, such as those copied from a source NetCDF/GRIB variable.
                                                                        • Global Attributes
                                                                          • Values are encoded as integers or doubles if possible, otherwise strings.
                                                                        • Scalar Variables Copied from NetCDF/GRIB Source
                                                                          • Source specifies the name of the source variable in a NetCDF file or the toolsUI view of a GRIB file; only scalar source variables are supported.
                                                                          • Output specifies the name of the variable in the output NetCDF file.
                                                                          • If only one of Source or Output is given, the other is taken as the same.
                                                                          • Dimension is either blank to simply copy the source scalar from one granule, or the name of one output NetCDF dimension to cause values to be copied from multiple granules (such as those from an ImageMosaic over a non-spatial dimension) into a one-dimensional variable. The example above copies a single value from multiple reftime scalars into forecast_reference_time dimensioned by time in an ImageMosaic over time.
                                                                          • For an ImageMosaic, one granule is chosen as the source for variable attributes.
                                                                        "},{"location":"extensions/netcdf-out/#cf-standard-names-support","title":"CF Standard names support","text":"

                                                                        Note that the output name can also be chosen from the list of CF Standard names. Check CF standard names page for more info on it.

                                                                        Once you click on the dropdown, you may choose from the set of available standard names.

                                                                        NetCDF CF Standard names list

                                                                        Note that once you specify the standard name, the unit will be automatically configured, using the canonical unit associated with that standard name.

                                                                        NetCDF CF Standard names and canonical unit

                                                                        The list of standard names is populated by taking the entries from a standard name table xml. At time of writing, a valid example is available Here

                                                                        You have three ways to provide it to GeoServer.

                                                                        1. Add a -DNETCDF_STANDARD_TABLE=/path/to/the/table/tablename.xml property to the startup script.
                                                                        2. Put that xml file within the NETCDF_DATA_DIR which is the folder where all NetCDF auxiliary files are located. (More info)
                                                                        3. Put that xml file within the GEOSERVER_DATA_DIR.

                                                                        Note

                                                                        Note that for the 2nd and 3rd case, file name must be cf-standard-name-table.xml.

                                                                        "},{"location":"extensions/netcdf-out/nc4/","title":"Nc4","text":"orphan"},{"location":"extensions/netcdf-out/nc4/#nc4","title":"Installing required NetCDF-4 Native libraries","text":"

                                                                        In order to write NetCDF-4 files, you must have the NetCDF-4 C library (version 4.3.1 or above) available on your system, along with all supporting libraries (HDF5, zlib, etc). The following sections provide quick reference installation instructions. For more detailed info, please take a look at the NetCDF-4 C Library Loading page.

                                                                        "},{"location":"extensions/netcdf-out/nc4/#windows-install","title":"Windows install","text":"
                                                                        1. Download the latest NetCDF4 installer from the NetCDF-C Windows Libraries page.
                                                                        2. Install the executable
                                                                        3. Make sure to add the bin folder of the package you have extracted, to the PATH environment variable.
                                                                        "},{"location":"extensions/netcdf-out/nc4/#linux-install","title":"Linux install","text":"
                                                                        1. Download the latest required dependencies (SZIP, ZLIB, HDF5) from the NetCDF-4 libraries section.

                                                                          As an instance:

                                                                          bash wget ftp://ftp.unidata.ucar.edu/pub/netcdf/netcdf-4/hdf5-1.8.13.tar.gz wget ftp://ftp.unidata.ucar.edu/pub/netcdf/netcdf-4/zlib-1.2.8.tar.gz

                                                                        2. Download the latest NetCDF-C source code from here.

                                                                          As an instance:

                                                                          bash wget https://github.com/Unidata/netcdf-c/archive/v4.3.3.1.tar.gz

                                                                        3. Build and install the required dependencies (The following instructions assume that you will install all NetCDF4 C libs on /work/libs/nc4libs, as an instance).

                                                                          1. ZLIB

                                                                            ``` bash ./configure --prefix=/work/libs/nc4libs

                                                                            make check install\n```\n
                                                                          2. HDF5

                                                                            ``` bash ./configure --with-zlib=/work/libs/nc4libs --prefix=/work/libs/nc4libs --enable-threadsafe --with-pthread=/DIR/TO/PTHREAD

                                                                            make check install\n```\n
                                                                        4. Build the NetCDF C Library.

                                                                          CPPFLAGS=-I/work/libs/nc4libs/include LDFLAGS=-L/work/libs/nc4libs/lib ./configure --prefix=/work/libs/nc4libs\n\nmake check install\n
                                                                        5. Make sure to add the lib folder of the package you have extracted, to the PATH environment variable.

                                                                        "},{"location":"extensions/netcdf-out/nc4/#geoserver-startup-checks","title":"GeoServer startup checks","text":"

                                                                        If everything has been properly configured, you may notice a similar log message during GeoServer startup:

                                                                        | NetCDF-4 C library loaded (jna_path='null', libname='netcdf'). | Netcdf nc_inq_libvers='4.3.1 of Jan 16 2014 15:04:00 $' isProtected=true |

                                                                        In case the native libraries haven't been properly configured you will see a message like this, instead:

                                                                        NetCDF-4 C library not present (jna_path='null', libname='netcdf').

                                                                        "},{"location":"extensions/netcdf-out/nc4/#requesting-a-netcdf4-classic-output-file-as-wcs20-output","title":"Requesting a NetCDF4-Classic output file as WCS2.0 output","text":"

                                                                        Specifying application/x-netcdf4 as Format, will return a NetCDF4-Classic output files, provided that the underlying libraries are available.

                                                                        "},{"location":"extensions/params-extractor/","title":"Parameters Extractor","text":"

                                                                        This module allow us to entering specific request parameters as URL path fragments instead of using the query string.

                                                                        • Installing the Parameter Extractor extension
                                                                        • Using the Parameters Extractor module
                                                                        "},{"location":"extensions/params-extractor/install/","title":"Installing the Parameter Extractor extension","text":"

                                                                        The Parameter Extractor extension is listed among the other extension downloads on the GeoServer download page.

                                                                        The installation process is similar to other GeoServer extensions:

                                                                        1. Visit the website download page, locate your release, and download: params-extractor

                                                                          Verify that the version number in the filename (for example 2.24.2 above) corresponds to the version of GeoServer you are running.

                                                                        2. Extract the contents of the archive into the WEB-INF/lib directory in GeoServer. Make sure you do not create any sub-directories during the extraction process.

                                                                        3. Restart GeoServer.

                                                                        If installation was successful, you will see a new Params-Extractor entry in the left menu, under \"Settings\".

                                                                        The Parameter Extractor menu entry

                                                                        "},{"location":"extensions/params-extractor/usage/","title":"Using the Parameters Extractor module","text":"

                                                                        This module allow us to entering specific request parameters as URL path fragments instead of using the query string. For example, we want to be able to apply a cql_filter using a URL in the following form:

                                                                        /geoserver/<workspace>/<layer>/<filter>/ows?service=WMS&version=1.3.0&request=GetMap\n

                                                                        As a simple example of usage, if the is something like:

                                                                        K_140M\n

                                                                        the URL would become:

                                                                        /geoserver/<workspace>/<layer>/K_140M/ows?service=WMS&version=1.3.0&request=GetMap\n

                                                                        and this module will translate the URL to this new one:

                                                                        /geoserver/<workspace>/<layer>/ows?service=WMS&version=1.3.0&request=GetMap&cql_filter=seq='K140M'\n

                                                                        This module is configured by a set of rules that will be applied to the incoming URLs. Note that a get capabilities result will include the original URL maintaining the extra filter.

                                                                        This module also gives the possibility to echo existing URL parameters to the result of a get capabilities result. As an example, by default the following get capabilities request (note the existing cql_filter parameter):

                                                                        /geoserver/ows?service=wms&version=1.3.0&request=GetCapabilities&cql_filter=CFCC=%27D68%27\n

                                                                        will return a get capabilities document were the URLs will be of the type:

                                                                        /geoserver/ows?SERVICE=WMS&\n

                                                                        if this module is configured to echo an existing cql_filter parameter the result would be:

                                                                        /geoserver/ows?SERVICE=WMS&CQL_FILTER=CFCC%3D%27D68%27&\n

                                                                        This module is configured using three types of rules: echo parameter rules, basic rules and advanced rules. All of them can be managed in this module UI which is integrated in GeoServer UI.

                                                                        "},{"location":"extensions/params-extractor/usage/#echo-parameter-rules","title":"Echo Parameter Rules","text":"

                                                                        Echo parameter rules are very simple, they allow us to define that a certain existing URL parameter should be echoed to a get capabilities result. This type of rules only required one mandatory parameter which is the name of the existing URL parameter that should be echoed to a get capabilities result.

                                                                        Example of an echo parameter rule:

                                                                        Example of a echo parameter rule defined in the UI

                                                                        This rule will echo the cql_filter of this URL:

                                                                        /geoserver/ows?service=wms&version=1.3.0&request=GetCapabilities&cql_filter=CFCC=%27D68%27\n

                                                                        to the get capabilities result:

                                                                        /geoserver/ows?SERVICE=WMS&CQL_FILTER=CFCC%3D%27D68%27&\n
                                                                        "},{"location":"extensions/params-extractor/usage/#basic-rules","title":"Basic Rules","text":"

                                                                        Basic rules allow us to handle simple uses cases where we only want to extract a parameter from the URL.

                                                                        A basic rule is defined by three mandatory attributes:

                                                                        Attribute Description Position The position of the URL base path element to be selected Parameter The name of the parameter produced by this rule Transform Expression that defines the value of the parameter, use {PARAMETER} as a placeholder for the selected path element

                                                                        For commodity is also possible when defining this type of rules to configure that an existing parameter in the URL should be echoed to a get capabilities result.

                                                                        Example of a basic rule:

                                                                        Example of a basic rule defined in the UI

                                                                        This rule will transform the URL:

                                                                        /geoserver/tiger/wms/H11?SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap\n

                                                                        in:

                                                                        /geoserver/tiger/wms?SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&CQL_FILTER=CFCC%3D%27H11%27\n
                                                                        "},{"location":"extensions/params-extractor/usage/#advanced-rules","title":"Advanced Rules","text":"

                                                                        Advanced rules allow us to handle more complex uses cases where more flexibility is required.

                                                                        An advanced rule is defined by three mandatory attributes and four optional ones:

                                                                        Attribute Description Mandatory Match Regex match expression with groups, for example \\^(?:/[\\^/]){3}(/([\\^/]+)).\\$ selects the URL base path third element Yes Activation If defined this rule will only be applied to URLs that match this regex expression No Parameter The name of the parameter produced by this rule Yes Transform Expression that defines the value of the parameter, use \\$1 ... \\$n as placeholders for groups defined in the match expression Yes Remove The match expression group to be removed from URL, by default 1 No Combine Defines how to combine parameter existing value (\\$1 existing value, \\$2 new value), by default the value is overridden No Repeat If defined, Combine is applied not only once, but for every layer included in the LAYERS parameter, this allows filling parameters that require a value for each layer (e.g. STYLES or CQL_FILTER) No

                                                                        For commodity is also possible when defining this type of rules to configure that an existing parameter in the URL should be echoed to a get capabilities result.

                                                                        Example of an advanced rule:

                                                                        Example of an advanced rule defined in the UI

                                                                        This rule will transform the URL:

                                                                        /geoserver/tiger/wms/H11?SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&CQL_FILTER=CFCC%3D%27D68%27\n

                                                                        in:

                                                                        /geoserver/tiger/wms?SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&CQL_FILTER=CFCC%3D%27D68%27+or+CFCC%3D%27H11%27\n

                                                                        No that this rule will also echo an existing cql_filter parameter to the get capabilities result.

                                                                        Example of an advanced rule with repeat:

                                                                        Example of an advanced rule with repeat defined in the UI

                                                                        This rule will transform the URL:

                                                                        /geoserver/wms/H11?SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&LAYERS=tiger,other\n

                                                                        in:

                                                                        /geoserver/wms?SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&LAYERS=tiger,otherCQL_FILTER=CFCC%3D%27D68%27%3BCFCC%3D%27H11%27\n
                                                                        "},{"location":"extensions/params-extractor/usage/#rules-management","title":"Rules Management","text":"

                                                                        Rules can be managed and tested in the rules management UI. Besides the basic operations like add, remove and update is also possible to activate or deactivate rules. A deactivated rule will be ignored by this module.

                                                                        Follow a print screen of the rules management UI with all the rules previously defined:

                                                                        Rules management UI

                                                                        Note that the first rule (the advanced one) is not active.

                                                                        "},{"location":"extensions/params-extractor/usage/#rest-api","title":"REST API","text":"

                                                                        The rules and echo parameters can also be managed by means of a REST API found at geoserver/rest/params-extractor. Documentation for it is available in Swagger format

                                                                        "},{"location":"extensions/params-extractor/usage/#intercepting-the-security-filters-chain","title":"Intercepting the security filters chain","text":"

                                                                        By default, the params-extractor module does not interact with the security authentication filters. This is because the params-extractor filter is called later in the GeoServer filters chain.

                                                                        If you want params-extractor to work before the security filter chain, you have to configure it as a standard servlet filter in the GeoServer WEB-INF/web.xml file.

                                                                        This can be done adding the following to your current web.xml (immediately after the Set Character Encoding filter) and restarting GeoServer:

                                                                        <!DOCTYPE beans PUBLIC \"-//SPRING//DTD BEAN//EN\" \"http://www.springframework.org/dtd/spring-beans.dtd\">\n<web-app>\n    ...\n    <filter>\n     <filter-name>ExtractParams</filter-name>\n     <filter-class>org.geoserver.params.extractor.Filter</filter-class>\n    </filter>\n    ...\n    <filter-mapping>\n      <filter-name>ExtractParams</filter-name>\n      <url-pattern>/*</url-pattern>\n    </filter-mapping>\n    ...\n</web-app>\n
                                                                        "},{"location":"extensions/printing/","title":"GeoServer Printing Module","text":"

                                                                        The printing module for GeoServer allows easy hosting of the Mapfish printing service within a GeoServer instance. The Mapfish printing module provides an HTTP API for printing that is useful within JavaScript mapping applications. User interface components for interacting with the print service are available from the Mapfish and GeoExt projects.

                                                                        Reference:

                                                                        • https://mapfish.github.io/mapfish-print-v2/ (mapfish-print-lib documentation)
                                                                        "},{"location":"extensions/printing/#installation","title":"Installation","text":"
                                                                        • Visit the website download page, locate your release, and download: printing
                                                                        • Extract the contents of the ZIP archive into the /WEB-INF/lib/ in the GeoServer webapp. For example, if you have installed the GeoServer binary to /opt/geoserver/, the printing extension JAR files should be placed in /opt/geoserver/webapps/geoserver/WEB-INF/lib/.
                                                                        • After extracting the extension, restart GeoServer in order for the changes to take effect. All further configuration can be done with GeoServer running.
                                                                        "},{"location":"extensions/printing/#verifying-installation","title":"Verifying Installation","text":"

                                                                        On the first startup after installation, GeoServer should create a print module configuration file in {GEOSERVER_DATA_DIR}/printing/config.yaml. Checking for this file's existence is a quick way to verify the module is installed properly. It is safe to edit this file; in fact there is currently no way to modify the print module settings other than by opening this configuration file in a text editor.

                                                                        If the module is installed and configured properly, then you will also be able to retrieve a list of configured printing parameters from http://localhost:8080/geoserver/pdf/info.json . This service must be working properly for JavaScript clients to use the printing service.

                                                                        Finally, you can test printing in this sample page <files/print-example.html>. You can load it directly to attempt to produce a map from a GeoServer running at http://localhost:8080/geoserver/. If you are running at a different host and port, you can download the file and modify it with your HTML editor of choice to use the proper URL.

                                                                        Warning

                                                                        This sample script points at the development version of GeoExt. You can modify it for production use, but if you are going to do so you should also host your own, minified build of GeoExt and OpenLayers. The libraries used in the sample are subject to change without notice, so pages using them may change behavior without warning.

                                                                        "},{"location":"extensions/printing/#mapfish-documentation","title":"MapFish documentation","text":"
                                                                        • Configuration
                                                                        • Protocol
                                                                        • FAQ
                                                                        "},{"location":"extensions/printing/configuration/","title":"Configuration","text":"

                                                                        The server side uses a YAML configuration file that defines the page layouts and allowed values. This file is usually called config.yaml.

                                                                        Note

                                                                        Warranty disclaimer and license

                                                                        The authors provide these documents \"AS-IS\", without warranty of any kind either expressed or implied.

                                                                        Document under Creative Common License Attribution-Share Alike 2.5 Generic.

                                                                        Authors: MapFish developers.

                                                                        "},{"location":"extensions/printing/configuration/#general-structure","title":"General structure","text":"

                                                                        Here is the general structure:

                                                                        dpis:\n  - 254\n  - 190\n  {...}\n\n?maxSvgWidth: 2048 # set the maximum dimensions to 2048 points, this is useful when using MapServer and a maximum dimension is there\n?maxSvgHeight: 2048\n?integerSvg: false # the library in MapServer <= 5.6 does not support floating point values in the SVG coordinate space, set this to true if using a WMS that does not support floating point values in SVG coordinates\n\n?ignoreCapabilities: false # assume client is correct and do not load capabilities.  This is not recommended to be used unless you it fails when false (false is default)\n?disableLayersMerging: false # WMS layers with mergable parameters will be merged by default. Set this to true to disable attempts to merge.\n?maxPrintTimeBeforeWarningInSeconds: 30 # if print jobs take longer than this then a warning in the logs will be written along with the spec.\n?printTimeoutMinutes: 5 # The maximum time to allow a print job to take before cancelling the print job.  The default is 5 (minutes)\n?formats:\n  - pdf\n  - png\n  {...}\n\nscales:\n  - 25000\n  - 50000\n  {...}\n\nhosts:\n  - {HOST_WHITELIST_DEFINITION}\n  {...}\n\n?localHostForward: # For request on map.example.com we build an http request on localhost with the header Host=map.example.com, this is to don't pass throw the proxy.\n?  from:\n?    - map.example.com\n?  https2http: True # For above hosts on request on https we build a request on http\n\n?headers: ['Cookie', 'Referer'] # The header that will be copyed to the tiles http requests\n\n?keys:\n?  - !key\n?    host: !dnsMatch\n?      host: maps.google.com\n?      port: 80\n?    domain: !dnsMatch\n?      host: localhost\n?    key: 1234456\n?    id: gmd-xyz\n\n\n?fonts:\n? - {PATH}\n\n?globalParallelFetches: 5\n?perHostParallelFetches: 5\n?tilecacheMerging: false\n?connectionTimeout: 30000           MF_V1.2\n?socketTimeout: 180000              MF_V1.2\n?outputFilename: Mapfish-print      MF_V1.2\n?disableScaleLocking: false\n?brokenUrlPlaceholder: default      MF_V2.0\n?proxyBaseUrl: http://mapfishprint.org  MF_V2.0\n?tmsDefaultOriginX: 0.0f   MF_V2.0\n?tmsDefaultOriginY: 0.0f   MF_V2.0\n\n?security:\n?  - !basicAuth\n?      matcher: !dnsMatch\n?        host: www.camptocamp.com\n?        post: 443\n?      username: xyz\n?      password: zyx\n?      preemptive: true\n?  - !basicAuth\n?    username: abc\n?    password: bca\n\nlayouts:\n   {LAYOUT_NAME}:\n?   : Mapfish-print.pdf  MF_V1.2\n?   metaData:\n?     {METADATA_DEFINITION}\n?   titlePage:\n?     {PAGE_DEFINITION}\n    mainPage:\n?     rotation: false\n      {PAGE_DEFINITION}\n?   lastPage:\n?     {PAGE_DEFINITION}\n  {...}\n

                                                                        Optional parts are shown with a question mark in the left margin. The question marks must not be put in the configuration file. Their default values is shown.

                                                                        Note: Sets of values like DPI can be entered in one of two forms:

                                                                        dpi: [1,2,3,...]\n

                                                                        or

                                                                        dpis:\n  - 254\n  - 190\n
                                                                        "},{"location":"extensions/printing/configuration/#dpi-and-pdf-dimensions","title":"DPI and PDF Dimensions","text":"

                                                                        A chosen DPI value from the above configuration is used in WMS GetMap requests as an added format_options (GeoServer) or map_resolution (MapServer) parameter. This is used for symbol/label-rescaling suitable for high resolution printouts, see Geoserver format_options specification (Geoserver 2.1) and MapServer defresolution keyword (MapServer 5.6) for more information.

                                                                        In general, PDF dimensions and positions are specified in points. 72 points == 1 inch == 25.4 mm.

                                                                        "},{"location":"extensions/printing/configuration/#getting-maps","title":"Getting Maps","text":"

                                                                        The list of {HOST_WHITELIST_DEFINITION} defines the allowed URLs for getting maps. Its format will be defined in the next sub-section.

                                                                        The formats element lists the values formats that the server permits.

                                                                        • If omitted only 'pdf' is permitted.
                                                                        • If the single element '*' (quotes are required) is present then all formats that the server can produce can be requested.

                                                                        The formats the server can produce depends to a large degree on how the Java is configured.

                                                                        PDF is supported on all systems but for image output formats JAI and ImageIO is used which means both must be on the server for them to be available. You can get the list of supported formats by running the standalone client with the --clientConfig flag enabled (you will need to supply a yaml config file as well). If you are using the servlet then do a get info request to see the list of formats (with the '*' as the outputFormats parameter in the config file).

                                                                        \"globalParallelFetches\" and \"perHostParallelFetches\" are used to tune the parallel loading of the map tiles/images. If you want to disable the parallel loading, set \"globalParallelFetches\" to 1.

                                                                        New versions of tilecache added the support for merging multiple layers in a single WMS request. If you want to use this functionality, set the \"tilecacheMerging\" attribute to true.

                                                                        \"connectionTimeout\" and \"socketTimeout\" can be used to tune the timeouts for reading tiles from map servers.

                                                                        \"proxyBaseUrl\" the optional url of the proxy between mapfish-print and the internet. This is the url base that will be in the info.json response. On occasion the url or port of the web server containing mapfish-print is not the server that is public to the internet and the requests are proxied to the mapfish-print webserver. In this case it is important for the info.json request to return the public URL instead of the url of the webserver.

                                                                        \"tmsDefaultOriginX\" By default this is null. If non-null then TmsMapReader will use this as the origin x value if null then the origin will be derived from the maxExtent parameter.

                                                                        \"tmsDefaultOriginY\" By default this is null. If non-null then TmsMapReader will use this as the origin y value if null then the origin will be derived from the maxExtent parameter.

                                                                        "},{"location":"extensions/printing/configuration/#layouts","title":"Layouts","text":"

                                                                        You can have as many layouts as you want. Their name must be unique and will be used on the client side.

                                                                        A layout can have a \"titlePage\" that will be added at the beginning of the generated document. It cannot contain any map.

                                                                        The \"mainPage\" section is mandatory and will be used once for each page requested. The details of a {PAGE_DEFINITION} section can be found in another sub-section of this document.

                                                                        A layout \"lastPage\", will be added for the end of the document, and cannot contain any map.

                                                                        If you want to let the user rotate the map (for a given layout), you have to set the \"rotate\" field to \"true\" in the corresponding \"mainPage\" section.

                                                                        "},{"location":"extensions/printing/configuration/#output-filename","title":"Output filename","text":"

                                                                        If the 'outputFilename' parameter is defined in the main body then that name will be used by the MapPrintServlet when sending the pdf to the client. It will be the name of the file that the client downloads. If the 'outputFilename' parameter is defined in a layout then that value will override the default name. In both cases the .pdf suffic is optional; if not present the server will append .pdf to the name.

                                                                        In all cases the json request can override the filename defined in the configuration file by posting a 'outputFilename' attribute in the posted JSON. If the outputFilename has \\${date}, \\${time} or \\${dateTime} in it, it will be replaced with the current date using the related DateFormat.get*Instance().format() method. If a pattern is provided it will be passed to SimpleDataFormat for processing. A few examples follow:

                                                                        • outputFilename: \"host-\\${yyyyMMdd}.pdf\" # results in host-20111213.pdf
                                                                        • outputFilename: \"host-\\${date}\" # results in host-Dec_13_2011.pdf (actual output depends on local of server)
                                                                        • outputFilename: \"host-\\${dateTime}\" # results in host-Dec_13_2011_1:10:50_PM.pdf (actual output depends on local of server)
                                                                        • outputFilename: \"host-\\${time}.pdf\" # results in host-1:11:14_PM.pdf (actual output depends on local of server)
                                                                        • outputFilename: \"host-\\${yyMMdd-hhmmss}\"# results in host-111213-011154.pdf (actual output depends on local of server)

                                                                        \"disableScaleLocking\" allows you to bypass the choosing of scale from the available factors, and simply use the suggested value produced inside MapBlock.java.

                                                                        "},{"location":"extensions/printing/configuration/#broken-images","title":"Broken images","text":"

                                                                        \"brokenUrlPlaceholder\" the placeholder image to use in the case of a broken url. By default, when a url request fails, an error is thrown and the pdf process terminates. However if this parameter is set then instead a placeholder image is returned.

                                                                        Non-null values are:

                                                                        • \"default\" - use the system default image.
                                                                        • \"throw\" - throw an exception.
                                                                        • - obtain the image from the supplied url. If this url is broken then an exception will be thrown. This can be anytype of valid url from a file url to https url."},{"location":"extensions/printing/configuration/#security","title":"Security","text":"

                                                                          Both Keys and Security are options for accessing protected services. Keys are currently for Google maps premium accounts and Security is for other types and is more general Currently only BasicAuth is supported but other strategies can easily be added

                                                                          security:\n    - !basicAuth\n        matcher: !dnsMatch\n          host: www.camptocamp.com\n          post: 443\n        username: xyz\n        password: zyx\n        preemptive: true\n    - !basicAuth\n      username: abc\n      password: cba\n

                                                                          The above example has 2 security configuration. Each option is tested (in order) to see if it can be used for the given URI and if it applies it is used to configure requests for the URI. In the above example the first configuration will be used if the URI matches the hostmatcher provided if not then the second configuration will be applied. The last configuration has no host matcher so it is applied to all URIs.

                                                                          A basicAuth security configuration consists of 4 options

                                                                          • matcher - a host matcher for determining which requests need the security to be applied
                                                                          • username - username for basicauth
                                                                          • password - password for basicauth
                                                                          • preemptive - optional, but for cases where the credentials need to be sent without the challenge
                                                                          "},{"location":"extensions/printing/configuration/#x-forwarded-for","title":"X Forwarded For","text":"

                                                                          Added addForwardedFor optional flag (true / false) to enable by IP security.

                                                                          When the option is true, every request to WMS services have an X-Forwarded-For header with the client IP / name, so that IP based security rules are correctly applied by the underlying service.

                                                                          "},{"location":"extensions/printing/configuration/#keys","title":"Keys","text":"

                                                                          Google maps currently requires a private key to be used (we only support users Google maps premium accounts).

                                                                          The keys section allows a key to be mapped to hosts. The hosts are identified with host matchers that are described in the sub-section.

                                                                          In addition a domain hostmatcher can be used to select a key based on the domain of the local server. This can be useful if the same configuration is used in a test environment and a production environment with differing domains. For example mapfish.org and mapfish.net.

                                                                          Finally google maps (for example) requires a client id as well that is associated with the private key. There for in the case of google premium services a legal key would be:

                                                                          keys:\n  - !key\n    key: yxcvyxvcyxvyx\n    id: gme-xxxcs\n

                                                                          Thanks to the hosts and domain matcher it is possible to have a key for google maps and (for future proofing) a different key for a different service.

                                                                          "},{"location":"extensions/printing/configuration/#fonts-definition","title":"Fonts definition","text":"

                                                                          The \"fonts\" section is optional. It contains the path of the fonts you want to use. The entries can point to files (TTF, OTF, TTC, AFM, PFM) or directories. Don't point to directories containing too many files since it will slow down the start time. By default, PDF gives you access to the following fonts (Cp1252 encoding only):

                                                                          • Courrier (-Bold, -Oblique, -BoldOblique)
                                                                          • Helvetica (-Bold, -Oblique, -BoldOblique)
                                                                          • Times (-Roman, -Bold, -Oblique, -BoldOblique)
                                                                          • Symbol
                                                                          • ZapfDingbats
                                                                          "},{"location":"extensions/printing/configuration/#host-whitelist-definition","title":"Host whitelist definition","text":"

                                                                          In this section, you can put as many entries as you want, even for the same type of filter. If at least one matches, the Map server can be used.

                                                                          This section is not for defining which client can request maps. It is just here to avoid having the print module used as a proxy to access documents from computers behind firewalls.

                                                                          There are 3 ways to whitelist a host.

                                                                          "},{"location":"extensions/printing/configuration/#allowing-every-local-services","title":"Allowing every local services:","text":"
                                                                          - !localMatch\n  dummy: true\n

                                                                          The \"dummy\" parameter is ignored, but mandatory to avoid a limitation in the YAML format.

                                                                          "},{"location":"extensions/printing/configuration/#allowing-by-dns-name","title":"Allowing by DNS name:","text":"
                                                                          - !dnsMatch\n  host: labs.metacarta.com\n
                                                                          "},{"location":"extensions/printing/configuration/#allowing-by-ip-address","title":"Allowing by IP address:","text":"
                                                                          - !ipMatch\n  ip: www.camptocamp.org\n?   mask: 255.255.255.255\n

                                                                          The \"ip\" parameter can be a DNS name that will be resolved or directly an IP address.

                                                                          All the methods accept the following optional parameters:

                                                                          • port: to limit to a certain TCP port
                                                                          • pathRegexp: a regexp that must match the path part of the URL (before the '?').
                                                                          "},{"location":"extensions/printing/configuration/#metadata-definition","title":"Metadata definition","text":"

                                                                          Allow to add some metadata to the generated PDF. They are visible in acroread in the File->Properties menu.

                                                                          The structure is like that:

                                                                          metaData:\n?     title: ''\n?     author: ''\n?     subject: ''\n?     keywords: ''\n?     creator: ''\n?     supportLegacyReader: false\n

                                                                          All fields are optional and can use global variables, as defined in the Block definition chapter. Page specific variables are not accessible.

                                                                          "},{"location":"extensions/printing/configuration/#page-definition","title":"Page definition","text":"

                                                                          The structure is like that:

                                                                          pageSize: A4\n?     landscape: false\n?     marginLeft: 40\n?     marginRight: 40\n?     marginTop: 20\n?     marginBottom: 20\n?     backgroundPdf: template.pdf\n?     condition: null\n?     header:\n  height: 50\n  items:\n    - {BLOCK_DEFINITION}\n    {...}\nitems:\n  - {BLOCK_DEFINITION}\n  {...}\n?     footer:\n  height: 50\n  items:\n    - {BLOCK_DEFINITION}\n    {...}\n?     includeTitlePage: true\n?     includeLastPage: true\n?     includeExtraPage: true\n

                                                                          With the \"condition\" we can completely hide a page, same behavior than in block.

                                                                          If \"backgroundPdf\" is specified, the first page of the given PDF file will be added as background of every page.

                                                                          The \"header\" and \"footer\" sections are optional. If the \"items\" that are in the main section are too big, more pages are generated. The header and footer will be drawn on those pages as well.

                                                                          Here is a short list of supported pageSizes:

                                                                          name width height

                                                                          LETTER 612 792

                                                                          LEGAL 612 1008

                                                                          A4 595 842

                                                                          A3 842 1191

                                                                          The complete list can be found in http://api.itextpdf.com/itext/com/itextpdf/text/PageSize.html. If you want to use a custom page size, you can set pageSize to the width and the height separated by a space.

                                                                          "},{"location":"extensions/printing/configuration/#skip-rendering-of-pages","title":"Skip Rendering Of Pages","text":"

                                                                          New flag params to skip rendering of particular pages have been implemented:

                                                                          • includeTitlePage
                                                                          • includeLastPage
                                                                          • includeExtraPage

                                                                          They are all defaulted to true.

                                                                          "},{"location":"extensions/printing/configuration/#extra-pages","title":"Extra Pages","text":"

                                                                          Additional Pages are supported in many different places. They can be rendered due to legends overflowing on multiple pages, or by the dynamic images functionality.

                                                                          Where additional pages can be generated, the generating block will be spread among all the created pages (for example, the legend block will put legends on different pages, if configured to do so). If you want to put additional blocks on additional page, you can specify the renderOnExtraPage flag on the desired blocks. Only first level blocks are considered.

                                                                          In addition to that, an explicit extraPage block can be used in config.yaml to add a custom page between other pages. The renderOn property specify the exact position for rendering (beforeMainPage, beforeLastPage or afterLastPage).

                                                                          "},{"location":"extensions/printing/configuration/#block-definition","title":"Block definition","text":"

                                                                          The next sub-sections document the possible types of blocks.

                                                                          In general, text values or URLs can contain values taken from the spec structure coming with the client's request. A syntax similar to shell is used: \\${variableName}. If the current page is a titlePage, only the root values are taken. If it's a mainPage, the service will first look in the current page section then in the root values. Here is how to use this functionality:

                                                                          text: 'The value of mapTitle is: ${mapTitle}'\n

                                                                          Some virtual variables can be used:

                                                                          • \\${pageNum}: The current page number.
                                                                          • \\${pageTot}: The total number of pages. Can be used only in text blocks.
                                                                          • \\${now}: The current date and time as defined by the machine's locale.
                                                                          • \\${now FORMAT}: The current date and time as defined by the FORMAT string. The syntax is here: http://java.sun.com/j2se/1.5.0/docs/api/java/text/SimpleDateFormat.html.
                                                                          • \\${configDir}: The absolute path to the directory of the configuration file.
                                                                          • \\${format PRINTF VAR}: Format the value of VAR using the provided PRINTF format (for example: %,d).

                                                                          All the blocks can have a condition attribute that takes a spec attribute name. If the attribute name exists and is not equal to \"false\" or \"0\", the block is drawn. Otherwise, it is ignored. An exclamation mark may precede the condition to invert it, exclamation mark is part of yaml syntax, than the expression should be in quotes.

                                                                          Example: show text block only if in the spec the attribute name \"showText\" is given, is not equal to \"false\" and not equal to \"0\":

                                                                          - !text\n  text: 'mytext'\n  condition: showText\n
                                                                          "},{"location":"extensions/printing/configuration/#text-block","title":"Text block","text":"
                                                                          - !text\n?         font: Helvetica\n?         fontSize: 12\n?         fontEncoding: Cp1252\n?         fontColor: black\n?         spacingAfter: 0\n?         align: left\n?         vertAlign: middle\n?         backgroundColor: #FFFFFF\n  text: 'Blahblah'\n?         asHTML: false\n

                                                                          Typical \"fontEncoding\" values are:

                                                                          • Cp1250
                                                                          • Cp1252
                                                                          • Cp1257
                                                                          • Identity-H (horizontal UTF-8)
                                                                          • Identity-V (vertical UTF-8)
                                                                          • MacRoman

                                                                          The \"font\" must refer to a standard PDF font or a declared font.

                                                                          "},{"location":"extensions/printing/configuration/#html-in-text-blocks","title":"HTML In Text Blocks","text":"

                                                                          The new configuration property asHTML (to be used in config.yaml text blocks) allows to automatically render the included text as HTML (when true), instead of simple text. HTML tags are interpreted and styled.

                                                                          "},{"location":"extensions/printing/configuration/#image-block","title":"Image block","text":"
                                                                          - !image\n  maxWidth: 200\n  maxHeight: 100\n?         spacingAfter: 0\n?         align: left\n?         vertAlign: middle\n  url: http://trac.mapfish.org/trac/mapfish/chrome/site/img/mapfish.png\n

                                                                          Supported formats are PNG, GIF, Jpeg, Jpeg2000, BMP, WMF (vector), SVG and TIFF.

                                                                          The original aspect ratio will be respected. The url can contain \"\\${}\" variables.

                                                                          "},{"location":"extensions/printing/configuration/#simple-colored-box-icons","title":"Simple colored box icons","text":"

                                                                          This enhancement adds the feature of drawing a simple colored box, instead of an icon into a legend item.

                                                                          To draw a colored box, include a color: #hexvalue property in the printing spec, instead of an icon: url property.

                                                                          "},{"location":"extensions/printing/configuration/#base64","title":"Base64","text":"

                                                                          We added support for Base64 encoded images uris to PDFUtils so that embedded images can be included for styling vector points (for example).

                                                                          Example url:

                                                                          url: data:image/png;base64,<encoded image>\n
                                                                          "},{"location":"extensions/printing/configuration/#images-content","title":"Images content","text":"

                                                                          This enhancement allow you add SVG content inside the specification of the print. You need to add a name into the image to manage:

                                                                          - !columns\n    width: 580\n    height: 271\n    absoluteX:70\n    absoluteY:400\n    items:\n      - !image\n        name: chart1\n        maxWidth: 580\n        maxHeight: 271\n        rotation: '${rotation}'\n

                                                                          Spec:

                                                                          {\n...\nchart1:{\n  content: '<svg>SVG content</svg>' \n},\n...\n}\n

                                                                          then, the content its rendered inside the print page with the layout configuration.

                                                                          "},{"location":"extensions/printing/configuration/#columns-block","title":"Columns block","text":"
                                                                          - !columns\n?         config: {TABLE_CONFIG}\n?         widths: [25,25,25,25]\n?         backgroundColor: #FFFFFF\n?         absoluteX: null\n?         absoluteY: null\n?         width: {PAGE_WIDTH}\n?         spacingAfter: 0\n?         nbColumns: -1\n  items:\n    - {BLOCK_DEFINITION}\n    {...}\n

                                                                          Can be called !table as well.

                                                                          By default, the width of the columns will be equal.

                                                                          Each item will be in its own column.

                                                                          If the absoluteX, absoluteY and width are given, the columns block will be floating on top of the page at the specified position.

                                                                          The widths attribute can be used to change the width of the columns (by default, they have the same width). It must contain one integer for each column. The width of a given column is tableWidth*columnWeight/sum(columnWeight).

                                                                          Every block type is allowed except for map if the column has an absolute position.

                                                                          Look at <http://trac.mapfish.org/trac/mapfish/wiki/PrintModuleServer#Tableconfiguration to know how to specify the config field.

                                                                          "},{"location":"extensions/printing/configuration/#map-block","title":"Map block","text":"

                                                                          Allowed only within a mainPage.

                                                                          - !map\n  width: 0\n  height: 0\n?         name: map\n?         spacingAfter: 0\n?         align: left\n?         vertAlign: middle\n?         absoluteX: null\n?         absoluteY: null\n?         overviewMap: null\n?         backgroundColor: #FFFFFF\n

                                                                          width and height are mandatory. You can use variable substitution in this part, but if you do so, the browser won't receive the map size when it calls info.json. You'll have to override mapfish.widgets.print.Base.configReceived and set the map width and height of your layouts.

                                                                          If the absoluteX and absoluteY are given, the map block will be floating on top of the page at the specified position.

                                                                          The name is what will be displayed in the Acrobat's reader layer panel. The map layers will be displayed bellow it.

                                                                          If overviewMap is specified, the map will be an overview of the extent augmented by the given factor. There are few cases to consider with map overviews:

                                                                          1. If there is no overview overrides and no OL.Control.MapOverview, then all the layers will figure in the PDF map overview.
                                                                          2. If there are overview overrides, the OL map overview control is ignored.
                                                                          3. If there are no overview overrides and there is an OL.Control.MapOverview (takes the first one), then the layers defined in the control are taken into account. By default it is the current base layer.
                                                                          "},{"location":"extensions/printing/configuration/#scalebar-block","title":"Scalebar block","text":"

                                                                          Display a scalebar.

                                                                          Allowed only within a mainPage.

                                                                          - !scalebar\n  maxSize: 150\n?         type: line\n?         intervals: 3\n?         subIntervals: false\n?         units: m\n?         barSize: 5\n?         lineWidth: 1\n?         barDirection: up\n?         textDirection: up\n?         labelDistance: 3\n?         font: Helvetica\n?         fontSize: 12\n?         fontColor: black\n?         color: #000000\n?         barBgColor: null\n?         spacingAfter: 0\n?         align: left\n?         vertAlign: middle\n?         backgroundColor: #FFFFFF\n?         lockUnits: true\n?         preferredIntervals: [1,2,5,10]\n?         preferredIntervalFractions: 0.0\n

                                                                          The scalebar, will adapt its width up to maxSize (includes the labels) in order to have a multiple of 1, 2 or 5 values at each graduation. For example:

                                                                          • 0, 1, 2, ...
                                                                          • 0, 2, 4, ...
                                                                          • 0, 5, 10, ...
                                                                          • 0, 10, 20, ...

                                                                          The barSize is the thickness of the bar or the height of the tick marks on the line. The lineWith is for the thickness of the lines (or bar border).

                                                                          Units can be any of:

                                                                          • m (mm, cm, m or km)
                                                                          • ft (in, ft, yd, mi)
                                                                          • degrees (min, sec, \u00b0)

                                                                          If the value is too big or too small, the module will switch to one of the unit in parenthesis (the same unit is used for every intervals). If this behaviour is not desired, the lockUnits parameter will force the declared unit (or map unit if no unit is declared) to be used for the scalebar.

                                                                          The number of intervals can be set to anything >=2. Labels are drawn only at main intervals. If there is no space to display a label at a certain interval, this label won't be displayed. If subIntervals are enabled, their number will depend on the length of an interval.

                                                                          The type can be:

                                                                          • line: A simple line with graduations
                                                                          • bar: A thick bar with a suite of color and barBgColor blocks.
                                                                          • bar_sub: Like bar, but with little lines for labels.

                                                                          The bar and/or text orientation can be set to \"up\", \"down\", \"left\" or \"right\".

                                                                          The align attribute is for placing the whole scalebar withing the surrounding column or page. The vertAlign attribute is used only when placed in a column.

                                                                          Labels are always centered on the graduation, at a distance specified by labelDistance.

                                                                          "},{"location":"extensions/printing/configuration/#custom-intervals-in-scalebarblock","title":"Custom intervals in ScalebarBlock","text":"

                                                                          With this improvement we added two new configuration parameters to !scalebar blocks that allow to customize the scalebar preferred bar lengths.

                                                                          Now this set can be customized using the preferredIntervals property. This property is an array with the new (integer) allowed lengths. By default these were chosen in the 1,2,5,10 set.

                                                                          Another property, preferredIntervalFractions, can be specified to also use fractional intervals. By default only 0.0 is used, and thus only integer lengths are allowed.

                                                                          Example:

                                                                          .. code-block:: yaml\n

                                                                          preferredIntervals: [1,3,5,10] preferredIntervalFractions: [0.2,0.5]

                                                                          "},{"location":"extensions/printing/configuration/#attributes-block","title":"Attributes block","text":"

                                                                          Allows to display a table of the displayed feature's attributes.

                                                                          Allowed only within a mainPage.

                                                                          - !attributes\n  source: results\n?         tableConfig: {TABLE_CONFIG}\n  columnDefs:\n    {COLUMN_NAME}:\n?             columnWeight: 0        MF_V1.2\n      header: {BLOCK_DEFINITION}\n      cell: {BLOCK_DEFINITION}\n    {...}\n

                                                                          Look here for how to specify the tableConfig field.

                                                                          The columnWeigth (MF_V1.2 only) allows to define a weight for the column width. If you specify it for one column, you have to specify it for all of them. The width of a given column is tableWidth*columnWeight/sum(columnWeight).

                                                                          The source value defines the name of the entry in the root of the client's spec. For example, it would look like that:

                                                                          {\n  ...\n  pages: [\n    {\n      ...\n      results: {\n        data: [\n          {id:1, name: 'blah', icon: 'icon_pan'},\n          ...\n        ],\n        columns: ['id', 'name', 'icon']\n      }\n    }\n  ]\n  ...\n}\n

                                                                          With this spec you would have to define 3 columnDefs with the names id, name and icon. Each cell definition blocks have access to all the values of the current row.

                                                                          The spec part is filled automatically by the 2 MapFish widgets when their grids parameter is set.

                                                                          Here is a crazy example of columnDef that will show the name of the icon and it's bitmap side-by-side inside a single column:

                                                                          columnDefs:\n  icon:\n    header: !text\n      text: Symbol\n      backgroundColor: #A0A0A0\n    cell: !columns\n      items:\n        - !text\n          text: '${icon}'\n        - !image\n          align: center\n          maxWidth: 15\n          maxHeight: 15\n          url: 'http://www.mapfish.org/svn/mapfish/trunk/MapFish/client/mfbase/mapfish/img/${icon}.png'\n

                                                                          A more complex example can be found in SVN: config.yaml spec.json

                                                                          The print widgets are able to fill the spec for you based on a dictionary of Ext.grid.GridPanel. Just pass them through the grids parameter.

                                                                          "},{"location":"extensions/printing/configuration/#group-rendering-in-attribute-blocks","title":"Group Rendering In Attribute Blocks","text":"

                                                                          Attribute blocks now support grouping, by a specific attribute. Rows should be sorted by that attribute for grouping to work (no automatic sort is accomplished by the printing library).

                                                                          To identify the grouping attribute, use the groupBy property.

                                                                          Each group can be prefixed by a title, using the groupTitle property. You can specify any block in the groupTitle property, to render any kind of content as a title.

                                                                          You can also skip table header using the includeHeader flag (true by default).

                                                                          Finally you can force a page break before any new group, using the groupOnNewPage flag.

                                                                          "},{"location":"extensions/printing/configuration/#legends-block","title":"Legends block","text":"

                                                                          Display each layers along with its classes (icons and labels).

                                                                          - !legends\n?         backgroundColor: #FFFFFF\n?         borders: false\n?         horizontalAlignment: center\n?         maxWidth: 0\n?         maxHeight: 0\n?         iconMaxWidth: 0\n?         iconMaxHeight: 8\n?         iconPadding: 8 7 6 5\n?         textMaxWidth: 8\n?         textMaxHeight: 8\n?         textPadding: 8 7 6 5\n?         defaultScale: 1.0\n?         inline: true\n?         classIndentation: 20\n?         layerSpaceBefore: 5\n?         layerSpace: 5\n?         classSpace: 2\n?         layerFont: Helvetica\n?         layerFontSize: 10\n?         classFont: Helvetica\n?         classFontSize: 8\n?         fontEncoding: Cp1252\n?         columnMargin: 3\n?         overflow: false\n?         maxColumns: 1\n?         reorderColumns: false\n?         dontBreakItems: false\n?         fitWidth: 0\n?         fitHeight: 0\n

                                                                          borders is mainly for debugging purpouses and shows all borders in the legend tables. This can be either 'true' or 'false'.

                                                                          horizontalAlignment can be left, right or center (default) and aligns all items left, right or in the center.

                                                                          iconMaxWidth, iconMaxHeight, defaultScale with value of 0 indicate that the value will be ignored, i.e. the values are automatically set to the equivalent of Infinity, Infinity and 1 respectively. If the legends URL passed to MapFish (see http://mapfish.org/doc/print/protocol.html#print-pdf) are obtained from a WMS GetLegendGraphic request, the width/height are only indicative (even more when a label text is included with LEGEND_OPTIONS/forceLabels parameter) and it would be safer, in order to preserve scale coherence between legends and map, to set iconMaxWidth and iconMaxHeight to zero.

                                                                          textMaxWidth/Height and iconMaxWidth/Height define how wide/high the text/icon cells of a legend item can be. At this point textMaxHeight is ignored.

                                                                          textPadding and iconPadding can be used like standard CSS padding. In the above example 8 is the padding top, 7 padding right, 6 padding bottom and 5 padding left.

                                                                          if inline is true icons and text are rendered on the same line, BUT multicolumn is still enabled.

                                                                          if maxWidth is set the whole legend gets a maximum width, just like other blocks. Note that maxWidth does not have any impact on icons size, thus icons may overflow outside the legends block.

                                                                          if maxHeight is set the whole legend gets a maximum height. This forces more than one column to appear if the legend is higher than the specified value. This can be used to enable the multi-column layout. 0 makes the maxHeight= max value, i.e. the equivalent of infinity.

                                                                          if defaultScale is non null it means that the legend image will be scaled so it doesn't take the full space. This can be overriden for individual classes in the spec JSON sent to the print module by adding an attribute called 'scale' and giving it a number. In conjunction with iconMaxWidth/Height this can be used to control average and also maximum width/height. If defaultScale equals 1, one pixel is scaled to one point (1/72 inch) in generated PDF. By default, as GeoServer legends are generated with \\~90 dpi resolution (exactly 25.4/0.28), setting defaultScale value to 0.7937 (72*0.28/25.4) produces legend icons of same size as corresponding map icons. As the LEGEND_OPTIONS/dpi GeoServer parameter is not handled by MapFish, the resolution will necessary be \\~91 dpi, which may cause visual quality difference with the map.

                                                                          For this to work, you need to set the layerTree config option on MF print widgets, more precisely the legends should be present in the print.pdf JSON request.

                                                                          layerSpaceBefore is to specify the space before the second and consecutive layers.

                                                                          layerSpace and classSpace is to specify the line space to add after layers and classes.

                                                                          columnMaxWidth maximum width of a column in multi-column layout.

                                                                          maxColumns allows to specify a maximum number of columns to be used. After this number is reached, a new row is created.

                                                                          classIndentation amount of points to indent classes by.

                                                                          layerSpaceBefore if a layer is after another one, this defines the amount of space to have before it. This will not be applied if the layer is the first item in its column in multi-column layout.

                                                                          layerFont font of layer name legend items.

                                                                          layerFontSize font size of layer name.

                                                                          classFont font of class legend items.

                                                                          classFontSize font size of class.

                                                                          fontEncoding (see below)

                                                                          "},{"location":"extensions/printing/configuration/#legend-fitting","title":"Legend fitting","text":"

                                                                          Support for legend fitting (legend resized to fit a given rectangle) has been added, through 2 new config.yaml configuration properties (to be used in legend blocks).

                                                                          The properties are:

                                                                          • fitWidth: width of the rectangle for fitting (defaults to 0, meaning no fit)
                                                                          • fitHeight: height of the rectangle for fitting (defaults to 0, meaning no fit)

                                                                          Both properties or only one of them can be specified. When only one property is set, the other dimension is calculated to mantain the original aspect ratio for the legend.

                                                                          "},{"location":"extensions/printing/configuration/#multipage-legends","title":"Multipage legends","text":"

                                                                          By default a LegendsBlock must be contained in a single page. To allow it to span on several pages the overflow option can be used, setting it to true.

                                                                          When this option is used you also need to define maxColumns, to fix the max number of columns on each page and maxHeight, to fix the maximum height of each column.

                                                                          The LegendsBlock will be rendered on as many pages as needed to get all the items rendered with the given constraints.

                                                                          Please note that if more than one page is needed, the second and following pages will only contain legend columns, without any of the other element of the page where the legends block is defined.

                                                                          "},{"location":"extensions/printing/configuration/#creating-an-horizontal-layout-for-legends","title":"Creating an horizontal layout for legends","text":"

                                                                          Using some config.yaml configuration options in an unusual way it is possible to have a layout for legends that is horizontal, instead of vertical.

                                                                          To get this behaviour is necessary to:

                                                                          • use the legend block maxHeight property with a very low value (e.g. 1) to force a new column for each legend item
                                                                          • use the legend block maxColumns value to choose the number of columns for the legend (a new row will be forced after maxColumns is reached)
                                                                          "},{"location":"extensions/printing/configuration/#reorder-legends-block-in-columns","title":"Reorder legends block in columns","text":"

                                                                          When the option reorderColumns inside legends block it set to true and more than one column is necessary for the legends block, a new algorithm computes the best distribution of the legend items inside the columns. Currently a first fit with items sorted in height descending order is used. This is not sub-optimal, but it's fast.

                                                                          When a legend item is rendered to another column, by default name and legend icon could finish on different columns. To fix it, please enable the dontBreakItems option.

                                                                          "},{"location":"extensions/printing/configuration/#dont-break-legend-items","title":"Don't break legend items","text":"

                                                                          Set the flag dontBreakItems to true on legends block if you want to render legend and names as one table to forbid the break between different columns

                                                                          "},{"location":"extensions/printing/configuration/#table-configuration","title":"Table configuration","text":"

                                                                          The columns block and the attributes block can take a table configuration object like that:

                                                                          config:\n?     borderWidth: 0\n?     borderWidthLeft: 0\n?     borderWidthRight: 0\n?     borderWidthTop: 0\n?     borderWidthBottom: 0\n?     borderColor: black\n?     borderColorLeft: black\n?     borderColorRight: black\n?     borderColorTop: black\n?     borderColorBottom: black\n?     cells:\n?       - {CELL_CONFIGURATION}\n

                                                                          A cell configuration looks like that:

                                                                          ?     row: {...}\n?     col: {...}\n?     borderWidth: 0\n?     borderWidthLeft: 0\n?     borderWidthRight: 0\n?     borderWidthTop: 0\n?     borderWidthBottom: 0\n?     borderColor: black\n?     borderColorLeft: black\n?     borderColorRight: black\n?     borderColorTop: black\n?     borderColorBottom: black\n?     padding: 0\n?     paddingLeft: 0\n?     paddingRight: 0\n?     paddingTop: 0\n?     paddingBottom: 0\n?     backgroundColor: white\n?     align: LEFT\n?     vertAlign: TOP\n

                                                                          The stuff configured at table level is for the table border, not every cell.

                                                                          The cells list defines overrides for some cells. The cells an override is applied to is defined by the row and col attribute. Those attributes can have several formats:

                                                                          • 0: apply only to row or column 0 (the first)
                                                                          • 0-10: applies only the row or columns from 0 to 10
                                                                          • or you can use any regular expression

                                                                          Every matching overrides is applied in order and will override the values defined in the previous ones.

                                                                          For example, if you want to draw an attribute block like that:

                                                                          You define that:

                                                                          - !attributes\n  tableConfig:\n    borderWidth: 1\n    cells:\n      # match every cell (default cell formatting)\n      - borderWidthBottom: 0.5\n        borderWidthLeft: 0.5\n        padding: 4\n        paddingTop: 0\n      # match every even cell (yellowish background)\n      - row: '\\d*[02468]'\n        backgroundColor: #FFFFCC\n      # for the header\n      - row: 0\n        borderWidthBottom: 1\n        backgroundColor: #FA0002\n        align: center\n  {...}\n
                                                                          "},{"location":"extensions/printing/configuration/#dynamic-images-page","title":"Dynamic images page","text":"

                                                                          New layout to let you print a different number of pages dinamically.

                                                                          You need to put it in config.yaml:

                                                                          dynamicImagesPage:\n      rotation: true\n      pageSize: 595 842\n      landscape: false\n      items:[...]\n

                                                                          and when you called to the print servlet, you'll need to add this property to the spec:

                                                                          imagesPages:[\n     {firstPageConfiguration},\n     {secondPageConfiguration}\n]\n

                                                                          then it's render one page for each item found in the imagesPages property.

                                                                          Also, you cant select the pages placement inside the document with the property renderOn:

                                                                          • afterLastPage: It's rendered after the last page. It's the default option active.
                                                                          • beforeLastPage: It's rendered just before last page (between main page and last page layouts)
                                                                          • beforeMainPage: It's rendered before main page (between first page and main page)

                                                                          The first use of this layout it's add a dynamic number of pages with differents images with svg content generated dynamicaly (using also the images content enhancement). This is an example of use with two dynammic images by page:

                                                                          Example config.yaml:

                                                                          ...\n dynamicImagesPage:\n   rotation: true\n   pageSize: 595 842\n   landscape: false\n   items:\n     - !columns\n       absoluteX: 30\n       absoluteY: 812\n       width: 535\n       height: 100\n       items:\n         - !image\n           maxWidth: 535\n           url: '${configDir}/print_header.png'\n     - !columns\n       absoluteX: 0\n       absoluteY: 750\n       width: 595\n       widths: [595]\n       items:\n         - !text\n           align: center\n           vertAlign: middle\n           fontSize: 14\n           text: '${meteorologicalPagesTitle}'\n     - !columns\n       width: 580\n       height: 271\n       absoluteX:70\n       absoluteY:697\n       items:\n         - !image\n           name: chart1\n           maxWidth: 580\n           maxHeight: 271\n           rotation: '${rotation}'\n     - !columns\n       width: 580\n       height: 271\n       absoluteX:70\n       absoluteY:400\n       items:\n         - !image\n           name: chart2\n           maxWidth: 580\n           maxHeight: 271\n           rotation: '${rotation}'\n

                                                                          spec:

                                                                          {\n...\nimagePages:[\n    images:{\n        chart1:{\n             content: '<svg>SVG content</svg>'\n        },\n        chart2:{\n             content: '<svg>SVG content</svg>'\n        }\n    }\n],\n...\n}\n
                                                                          "},{"location":"extensions/printing/faq/","title":"FAQ","text":"

                                                                          Note

                                                                          Warranty disclaimer and license

                                                                          The authors provide these documents \"AS-IS\", without warranty of any kind either expressed or implied.

                                                                          Document under Creative Common License Attribution-Share Alike 2.5 Generic.

                                                                          Authors: MapFish developers.

                                                                          All I get in my PDF is: \"ERROR: infinite table loop\". What's wrong?

                                                                          Something in your page is too big. For example, the width or the height of your !map block.

                                                                          I tried to print (pylons mode) and I get a \"Java error\". What's next?

                                                                          Look in the apache error log, you'll find more information.

                                                                          What are the limitations of the type 2 layers?

                                                                          It depends mostly on the map server you use. For the moment, GeoServer has not been extensively tested. With MapServer:

                                                                          • The PDF output must be enabled when you compile and doesn't work in WMS mode, only in native MapServer mode. There are some limitations. on the styling. And you must use truetype fonts.
                                                                          • The SVG output is limited regarding the stylings you can use. For example only plain polygon fillings are supported by MapServer. If a complex styling is used, your features may appear plain black.
                                                                          I tried to change the layout and half the Map is printed off the page on the right. Or I have an empty page added. Is it a bug?

                                                                          It's mostly a feature ;-) . This kind of behavior can be seen in iText, when adding a block that is too big for the page size. Try to reduce the size of your map block.

                                                                          When I look at my generated PDF in Acrobat Reader, it looks good. But, when I print it, it misses some tiles/layers, some bitmaps are just weird or there are no page printed. What's wrong?

                                                                          There are three possible explanations:

                                                                          • Your printer has not enough memory: in Acrobat's print dialog, select \"Save printer memory\"
                                                                          • Your printer firmware is buggy: upgrade it
                                                                          • Your printer driver is buggy: upgrade it
                                                                          The module needs to go through a proxy to access the map services.

                                                                          It's so 90s... you should hire some fresh guys for your IT team. ;-)

                                                                          You need to set some system properties (http.proxy*) when you start your java programs.

                                                                          On the browser, the scale is displayed with spaces to separate thousands and it's against my religion. How do I put my sacred separator?

                                                                          By default, the browser's configured locale is used. You can force another locale in the print widget configuration:

                                                                          {\n  ...\n  configUrl: 'print/info.json',\n  serviceParams: { locale: 'fr_CH' },\n  ...\n}\n
                                                                          I copied the examples and the print widgets are not working.

                                                                          First edit the client/examples/examples.js file and make sure the URLs are correct.

                                                                          1. If you don't want to install the server side, make sure you installed a proxy (see Configure Proxy). For example, test (must return a JSON content, not the proxy.cgi script's content) it with an URL like that (adapt the hostname, port and path): http://localhost/cgi-bin/proxy.cgi?url=http://demo.mapfish.org/mapfishsample/trunk/print/info.json
                                                                          2. If you installed the server side, make sure it works by calling the URL specified in the mapfish.SERVER_BASE_URL variable (must be the hostname/port your page is accessed through) added with /print/info.json. For example, if you have mapfish.SERVER_BASE_URL=\"http://localhost/mapfish\": http://localhost/mapfish/print/info.json

                                                                          If it still doesn't work, use firefox, install firebug and check in the console panel that the AJAX request made by the print widget works fine.

                                                                          "},{"location":"extensions/printing/protocol/","title":"Protocol","text":"

                                                                          Four commands are available and are documented in the next sections.

                                                                          Every command uses the HTTP status code to notify errors.

                                                                          Note

                                                                          Warranty disclaimer and license

                                                                          The authors provide these documents \"AS-IS\", without warranty of any kind either expressed or implied.

                                                                          Document under Creative Common License Attribution-Share Alike 2.5 Generic.

                                                                          Authors: MapFish developers.

                                                                          "},{"location":"extensions/printing/protocol/#infojson","title":"info.json","text":"

                                                                          HTTP command:

                                                                          GET {PRINT_URL}/info.json?url={PRINT_URL}%2Finfo.json&var=printConfig\n

                                                                          Returns a JSON structure as such:

                                                                          var printConfig = {\n    \"scales\":[\n        {\"name\":\"25000\"},\n        {\"name\":\"50000\"},\n        {\"name\":\"100000\"}\n    ],\n    \"dpis\":[\n        {\"name\":\"190\"},\n        {\"name\":\"254\"}\n    ],\n    \"outputFormats\":[\n        {\"name\":\"pdf\"},\n        {\"name\":\"png\"}\n    ],\n    \"layouts\":[\n        {\n            \"name\":\"A4 portrait\",\n            \"map\":{\n                \"width\":440,\n                \"height\":483\n            }\n        }\n    ],\n    \"printURL\":\"http:\\/\\/localhost:5000\\/print\\/print.pdf\",\n    \"createURL\":\"http:\\/\\/localhost:5000\\/print\\/create.json\"\n}\n

                                                                          This can be loaded through an HTML script tag like that:

                                                                          <script type=\"text/javascript\"\n      src=\"http://localhost:5000/print/info.json?var=printConfig\"></script>\n

                                                                          or through an AJAX request, in this case the var query parameter will be omitted.

                                                                          The \"url\" query parameter is here to help the print servlet to know what URL is used by the browser to access the servlet. This parameter is here because the servlet can be behind a proxy, hiding the real URL.

                                                                          "},{"location":"extensions/printing/protocol/#printpdf","title":"print.pdf","text":"

                                                                          HTTP command:

                                                                          GET {PRINT_URL}/print.pdf?spec={SPEC}\n   or\nPOST {PRINT_URL}/print.pdf    with {SPEC} in the request body\n

                                                                          The \"SPEC\" parameter is a JSON structure like that:

                                                                          {\n    layout: 'A4 portrait',\n    ...CUSTOM_PARAMS...\n    srs: 'EPSG:4326',\n    units: 'degrees',\n    geodetic: false,\n    outputFilename: 'political-boundaries',\n    outputFormat: 'pdf',\n    mergeableParams: {\n        cql_filter: {\n            defaultValue: 'INCLUDE',\n            separator: ';',\n            context: 'http://labs.metacarta.com/wms/vmap0'\n        }\n    },\n    layers: [\n        {\n            type: 'WMS',\n            layers: ['basic'],\n            baseURL: 'http://labs.metacarta.com/wms/vmap0',\n            format: 'image/jpeg'\n        }\n    ],\n    pages: [\n        {\n            center: [6, 45.5],\n            scale: 4000000,\n            dpi: 190,\n            geodetic: false,\n            strictEpsg4326: false,\n            ...CUSTOM_PARAMS...\n        }\n    ],\n    legends: [\n        {\n            classes: [\n                {\n                    icons: [\n                        'full url to the image'\n                    ],\n                    name: 'an icon name',\n                    iconBeforeName: true\n                }\n            ],\n            name: 'a class name'\n        }\n    ]\n}\n

                                                                          The location to show on the map can be specified with a center and a scale as show or with a bbox like that:

                                                                          bbox: [5, 45, 6, 46]\n

                                                                          The print module will use the nearest scale and will make sure the aspect ratio stays correct.

                                                                          The geodetic parameter can be set to true so the scale of geodetic layers can correctly be calculated. Certain projections (Google and Latlong for example) are based on a spheroid and therefore require geodetic: true in order to correctly calculate the scale. If the geodetic parameter is not present it will be assumed to be false.

                                                                          The optional strictEpsg4326 parameter can be set to true to control how EPSG:4326 is interpreted. This needs to be true for WMS version 1.3.0 GetMap requests. See https://www.google.ch/search?q=epsg+4326+latitude+longitude+order&oq=epsg+4326+&aqs=chrome.3.69i57j0l5.5996j0j4&sourceid=chrome&espv=210&es_sm=93&ie=UTF-8 for some links to the history and mess that is EPSG:4326.

                                                                          The outputFilename parameter is optional and if omitted the values used in the server's configuration will be used instead. If it is present it will be the name of the downloaded file. The suffix will be added if not left off in the parameter. The date can be substituted into the filename as well if desired. See configuration's outputFilename for more information and examples

                                                                          The outputFormat parameter is optional and if omitted the value 'pdf' will be used. Only the formats returned in the info are permitted.

                                                                          There are two locations where custom parameters can be added. Those will be ignored by the web service but, will be accessible from the layout templates.

                                                                          Some layer types support merging more layers request into one, when the server is the same (for example WMS). For those, a mergeableParams section can be used to define merging strategies for some custom parameters. The default rule is to merge layers with identical custom parameters. Using mergeableParams, defined parameters values can be joined using a given separator and a default value if some of the layers miss the parameter. Mergeable parameters can have a context, that is the baseURL they can be used for (if not defined they will be used for every layer).

                                                                          For the format of the layers section, please look at the implementations pointed by mapfish.PrintProtocol.SUPPORTED_TYPES.

                                                                          This command returns the PDF file directly.

                                                                          "},{"location":"extensions/printing/protocol/#createjson","title":"create.json","text":"

                                                                          HTTP command:

                                                                          POST {PRINT_URL}/create.json?url={PRINT_URL}%2Fcreate.json\n

                                                                          The spec defined in the \"print.pdf\" command must be included in the POST body.

                                                                          Returns a JSON structure like that:

                                                                          {\n    getURL: 'http:\\/\\/localhost:5000\\/print\\/56723.pdf'\n}\n

                                                                          The URL returned can be used to retrieve the PDF file. See the next section.

                                                                          "},{"location":"extensions/printing/protocol/#idpdf","title":"{ID}.pdf","text":"

                                                                          This command's URL is returned by the \"create.json\" command.

                                                                          HTTP command:

                                                                          GET {PRINT_URL}/{ID}.pdf\n

                                                                          Returns the PDF. Can be called only during a limited time since the server side temporary file is deleted afterwards.

                                                                          "},{"location":"extensions/printing/protocol/#multiple-maps-on-a-single-page","title":"Multiple maps on a single page","text":"To print more than one map on a single page you need to:
                                                                          • specify several map blocks in a page of the yaml file, each with a distinct name property value
                                                                          • use a particular syntax in the spec to bind different rendering properties to each map block

                                                                          This is possible specifying a maps object in spec root object with a distinct key - object pair for each map. The key will refer the map block name as defined in yaml file. The object will contain layers and srs for the named map. Another maps object has to be specified inside the page object to describe positioning, scale and so on.

                                                                          {\n    ...\n    maps: {\n        \"main\": {\n            layers: [\n                ...\n            ],\n            srs: 'EPSG:4326'\n        },\n        \"other\": {\n            layers: [\n                ...\n            ],\n            srs: 'EPSG:4326'\n        }\n    },\n    ...\n    pages: [\n        {\n            maps: {\n                \"main\": {\n                    center: [6, 45.5],\n                    scale: 4000000,\n                    dpi: 190,\n                    geodetic: false,\n                    strictEpsg4326: false,\n                    ...CUSTOM_PARAMS...\n                },\n                \"other\": {\n                    center: [7.2, 38.6],\n                    scale: 1000000,\n                    dpi: 300,\n                    geodetic: false,\n                    strictEpsg4326: false,\n                    ...CUSTOM_PARAMS...\n                }\n            }\n\n        }\n    ],\n    ...\n}\n

                                                                          Other config blocks have been enabled to multiple maps usage. The scalebar block can be bound to a specific map, specifying a name property that matches the map name. Also, in text blocks you can use the \\${scale.} placeholder to print the scale of the map whose name is ."},{"location":"extensions/printing/protocol/#layers-params","title":"Layers Params","text":""},{"location":"extensions/printing/protocol/#vector","title":"Vector","text":"

                                                                          Type: vector

                                                                          Render vector layers. The geometries and the styling comes directly from the spec JSON.

                                                                          • opacity (Defaults to 1.0)
                                                                          • geoJson (Required) the geoJson to render
                                                                          • styleProperty (Defaults to '_style') Name of the property within the features to use as style name. The given property may contain a style object directly.
                                                                          • styles (Optional) dictionary of styles. One style is defined as in OpenLayers.Feature.Vector.style.
                                                                          • name (Defaults to vector) the layer name.
                                                                          "},{"location":"extensions/printing/protocol/#wms","title":"WMS","text":"

                                                                          Type: wms

                                                                          Support for the WMS protocol with possibilities to go through a WMS-C service (TileCache).

                                                                          • opacity (Defaults to 1.0)
                                                                          • baseURL (Required) Service URL
                                                                          • customParams (Optional) Map, additional URL arguments
                                                                          • layers (Required)
                                                                          • styles (Optional)
                                                                          • format (Required)
                                                                          • version (Defaults to 1.1.1)
                                                                          • useNativeAngle (Defaults to false) it true transform the map angle to customParams.angle for GeoServer, and customParams.map_angle for MapServer.
                                                                          "},{"location":"extensions/printing/protocol/#wmts","title":"WMTS","text":"

                                                                          Type: wmts

                                                                          Support for the protocol using directly the content of a WMTS tiled layer, support REST or KVP.

                                                                          Two possible mode, standard or simple, the simple mode imply that all the topLeftCorner are identical.

                                                                          Standard mode:

                                                                          • opacity (Defaults to 1.0)
                                                                          • baseURL the 'ResourceURL' available in the WMTS capabilities.
                                                                          • customParams (Optional) Map, additional URL arguments
                                                                          • layer (Required) the layer name
                                                                          • version (Defaults to 1.0.0) WMTS protocol version
                                                                          • requestEncoding (Defaults to REST) REST or KVP
                                                                          • style (Optional) the style name
                                                                          • dimensions (Optional) list of dimensions names
                                                                          • params (Optional) dictionary of dimensions name (capital) => value
                                                                          • matrixSet (Required) the name of the matrix set
                                                                          • matrixIds (Required) array of matrix ids e.g.:
                                                                          [{\n    \"identifier\": \"0\",\n    \"matrixSize\": [1, 1],\n    \"resolution\": 4000,\n    \"tileSize\": [256, 256],\n    \"topLeftCorner\": [420000, 350000]\n}, ...]\n
                                                                          • format (Optional, Required id requestEncoding is KVP)

                                                                          Simple mode:

                                                                          • baseURL base URL without the version.
                                                                          • layer (Required)
                                                                          • version (Required)
                                                                          • requestEncoding (Required) REST
                                                                          • tileOrigin (Required)
                                                                          • tileSize (Required)
                                                                          • extension (Required)
                                                                          • resolutions (Required)
                                                                          • style (Required)
                                                                          • tileFullExtent (Required)
                                                                          • zoomOffset (Required)
                                                                          • dimensions (Optional)
                                                                          • params (Optional)
                                                                          • formatSuffix (Required)
                                                                          "},{"location":"extensions/printing/protocol/#tms","title":"Tms","text":"

                                                                          Type: tms

                                                                          Support the TMS tile layout.

                                                                          • opacity (Defaults to 1.0)
                                                                          • baseURL (Required) Service URL
                                                                          • customParams (Optional) Map, additional URL arguments
                                                                          • maxExtent (Required) Array, extent coordinates [420000, 30000, 900000, 350000]
                                                                          • tileSize (Required) Array, tile size e.g. [256, 256]
                                                                          • format (Required)
                                                                          • layer (Required)
                                                                          • resolutions (Required) Array of resolutions
                                                                          • tileOrigin (Optional) Object, tile origin. Defaults to 0,0

                                                                          Resources:

                                                                          • Quick intro to TMS requests: http://geowebcache.org/docs/current/services/tms.html
                                                                          • TMS Spec (Not an Official Standard): http://wiki.osgeo.org/wiki/Tile_Map_Service_Specification
                                                                          "},{"location":"extensions/printing/protocol/#xyz","title":"Xyz","text":"

                                                                          Type: xyz

                                                                          Support the tile layout z/x/y..

                                                                          • opacity (Defaults to 1.0)
                                                                          • baseURL (Required) Service URL
                                                                          • customParams (Optional) Map, additional URL arguments
                                                                          • maxExtent (Required) Array, extent coordinates [420000, 30000, 900000, 350000]
                                                                          • tileSize (Required) Array, tile size e.g. [256, 256]
                                                                          • resolutions (Required) Array of resolutions (Required) Array of resolutions
                                                                          • extension (Required) file extension (Required) file extension
                                                                          • tileOrigin (Optional) Array, tile origin e.g. [420000, 350000]
                                                                          • tileOriginCorner tl or bl (Defaults to bl)
                                                                          • path_format (Optional) url fragment used to construct the tile location. Can support variable replacement of ${x}, ${y}, ${z} and ${extension}. Defaults to zz/x/y.extension format. You can use multiple \"letters\" to indicate a replaceable pattern (aka, ${zzzz} will ensure the z variable is 0 padded to have a length of AT LEAST 4 characters).
                                                                          "},{"location":"extensions/printing/protocol/#osm","title":"Osm","text":"

                                                                          Type: osm

                                                                          Support the OSM tile layout.

                                                                          • opacity (Defaults to 1.0)
                                                                          • baseURL (Required) Service URL
                                                                          • customParams (Optional) Map, additional URL arguments
                                                                          • maxExtent (Required) Array, extent coordinates [420000, 30000, 900000, 350000]
                                                                          • tileSize (Required) Array, tile size e.g. [256, 256]
                                                                          • resolutions (Required) Array of resolutions
                                                                          • extension (Required) file extension
                                                                          "},{"location":"extensions/printing/protocol/#tilecache","title":"TileCache","text":"

                                                                          Type: tileCache

                                                                          Support for the protocol using directly the content of a TileCache directory.

                                                                          • opacity (Defaults to 1.0)
                                                                          • baseURL (Required) Service URL
                                                                          • customParams (Optional) Map, additional URL arguments
                                                                          • layer (Required)
                                                                          • maxExtent (Required) Array, extent coordinates [420000, 30000, 900000, 350000]
                                                                          • tileSize (Required) Array, tile size e.g. [256, 256]
                                                                          • resolutions (Required) Array of resolutions
                                                                          • extension (Required) file extension
                                                                          "},{"location":"extensions/printing/protocol/#image","title":"Image","text":"

                                                                          Type: image

                                                                          • opacity (Defaults to 1.0)
                                                                          • name (Required)
                                                                          • baseURL (Required) Service URL
                                                                          • extent (Required)
                                                                          "},{"location":"extensions/printing/protocol/#mapserver","title":"MapServer","text":"

                                                                          Type: mapServer

                                                                          Support mapserver WMS server.

                                                                          • opacity (Defaults to 1.0)
                                                                          • baseURL (Required) Service URL
                                                                          • customParams (Optional) Map, additional URL arguments
                                                                          • layers (Required)
                                                                          • format (Required)
                                                                          "},{"location":"extensions/printing/protocol/#kamap","title":"KaMap","text":"

                                                                          Type: kaMap

                                                                          Support for the protocol using the KaMap tiling method

                                                                          • opacity (Defaults to 1.0)
                                                                          • baseURL (Required) Service URL
                                                                          • customParams (Optional) Map, additional URL arguments
                                                                          • map
                                                                          • group
                                                                          • maxExtent (Required) Array, extent coordinates [420000, 30000, 900000, 350000]
                                                                          • tileSize (Required) Array, tile size e.g. [256, 256]
                                                                          • resolutions (Required) Array of resolutions
                                                                          • extension (Required) file extension
                                                                          "},{"location":"extensions/printing/protocol/#kamapcache","title":"KaMapCache","text":"

                                                                          Type: kaMapCache

                                                                          Support for the protocol talking directly to a web-accessible ka-Map cache generated by the precache2.php script.

                                                                          • opacity (Defaults to 1.0)
                                                                          • baseURL (Required) Service URL
                                                                          • customParams (Optional) Map, additional URL arguments
                                                                          • map (Required)
                                                                          • group (Required)
                                                                          • metaTileWidth (Required)
                                                                          • metaTileHeight (Required)
                                                                          • units (Required)
                                                                          • maxExtent (Required) Array, extent coordinates [420000, 30000, 900000, 350000]
                                                                          • tileSize (Required) Array, tile size e.g. [256, 256]
                                                                          • resolutions (Required) Array of resolutions
                                                                          • extension (Required) file extension
                                                                          "},{"location":"extensions/printing/protocol/#google","title":"Google","text":"

                                                                          Type: google or tiledGoogle

                                                                          They used the Google Map Static API, tiledGoogle will create tiles and google only one image.

                                                                          The google map reader has several custom parameters that can be added to the request they are:

                                                                          • opacity (Optional, Defaults to 1.0)
                                                                          • baseURL (Required, should be 'http://maps.google.com/maps/api/staticmap')
                                                                          • customParams (Optional) Map, additional URL arguments
                                                                          • maxExtent (Required, should be [-20037508.34, -20037508.34, 20037508.34, 20037508.34])
                                                                          • resolutions (Required, should be [156543.03390625, 78271.516953125, 39135.7584765625, 19567.87923828125, 9783.939619140625, 4891.9698095703125, 2445.9849047851562, 1222.9924523925781, 611.4962261962891, 305.74811309814453, 152.87405654907226, 76.43702827453613, 38.218514137268066, 19.109257068634033, 9.554628534317017, 4.777314267158508, 2.388657133579254, 1.194328566789627, 0.5971642833948135, 0.29858214169740677, 0.14929107084870338, 0.07464553542435169])
                                                                          • extension (Required, should be png)
                                                                          • client (Optional)
                                                                          • format (Optional)
                                                                          • maptype (Required) - type of map to display: http://code.google.com/apis/maps/documentation/staticmaps/#MapTypes
                                                                          • sensor (Optional) - specifies whether the application requesting the static map is using a sensor to determine the user's location
                                                                          • language (Optional) - language of labels.
                                                                          • markers (Optional) - add markers to the map: http://code.google.com/apis/maps/documentation/staticmaps/#Markers
                                                                          markers: ['color:blue|label:S|46.5195933305192,6.566684726913701']\n
                                                                          • path (Optional) - add a path to the map: http://code.google.com/apis/maps/documentation/staticmaps/#Paths
                                                                          path: 'color:0x0000ff|weight:5|46.5095933305192,6.506684726913701|46.5195933305192,6.526684726913701|46.5395933305192,6.536684726913701|46.5695933305192,6.576684726913701',\n
                                                                          "},{"location":"extensions/printing/protocol/#warranty-disclaimer-and-license","title":"Warranty disclaimer and license","text":"

                                                                          The authors provide these documents \"AS-IS\", without warranty of any kind either expressed or implied.

                                                                          Document under Creative Common License Attribution-Share Alike 2.5 Generic.

                                                                          Authors: MapFish developers.

                                                                          "},{"location":"extensions/querylayer/","title":"Cross-layer filtering","text":"

                                                                          Cross-layer filtering provides the ability to find features from layer A that have a certain relationship to features in layer B. This can be used, for example, to find all bus stops within a given distance from a specified shop, or to find all coffee shops contained in a specified city district.

                                                                          The querylayer module adds filter functions that implement cross-layer filtering. The functions work by querying a secondary layer within a filter being applied to a primary layer. The name of the secondary layer and an attribute to extract from it are provided as arguments, along with an ECQL filter expression to determine which features are of interest. A common use case is to extract a geometry-valued attribute, and then use the value(s) in a spatial predicate against a geometry attribute in the primary layer.

                                                                          Filter functions are widely supported in GeoServer, so cross-layer filtering can be used in SLD rules and WMS and WFS requests, in either XML or CQL filters.

                                                                          "},{"location":"extensions/querylayer/#installing-the-querylayer-module","title":"Installing the querylayer module","text":"
                                                                          • Visit the website download page, locate your release, and download: querylayer

                                                                            ::: warning ::: title Warning :::

                                                                            The version of the extension must match the version of the GeoServer instance :::

                                                                          • Extract the contents of the extension archive into the WEB-INF/lib directory of the GeoServer installation.

                                                                          • To check the module is properly installed request the WFS 1.1 capabilities from the GeoServer home page. The Filter_Capabilities section should contain a reference to a function named queryCollection.
                                                                          ...\n<ogc:Filter_Capabilities>\n    ...\n    <ogc:ArithmeticOperators>\n      ...\n      <ogc:Functions>\n        <ogc:FunctionNames>\n          ...\n          <ogc:FunctionName nArgs=\"-1\">queryCollection</ogc:FunctionName>\n          <ogc:FunctionName nArgs=\"-1\">querySingle</ogc:FunctionName>\n          ...\n        </ogc:FunctionNames>\n      </ogc:Functions>\n    </ogc:ArithmeticOperators>\n  </ogc:Scalar_Capabilities>\n  ...\n</ogc:Filter_Capabilities>\n...\n
                                                                          "},{"location":"extensions/querylayer/#function-reference","title":"Function reference","text":"

                                                                          The extension provides the following filter functions to support cross-layer filtering.

                                                                          Name Arguments Description querySingle layer : String, attribute : String, filter : String Queries the specified layer applying the specified ECQL filter and returns the value of attribute from the first feature in the result set. The layer name must be qualified (e.g. topp:states). If no filtering is desired use the filter INCLUDE. queryCollection layer : String, attribute : String, filter : String Queries the specified layer applying the specified ECQL filter and returns a list containing the value of attribute for every feature in the result set. The layer name must be qualified (e.g. topp:states). If no filtering is desired use the filter INCLUDE. An exception is thrown if too many results are collected (see Memory Limits). collectGeometries geometries: a list of Geometry objects Converts a list of geometries into a single Geometry object. The output of queryCollection must be converted by this function in order to use it in spatial filter expressions (since geometry lists cannot be used directly). An exception is thrown if too many coordinates are collected (see Memory Limits)."},{"location":"extensions/querylayer/#optimizing-performance","title":"Optimizing performance","text":"

                                                                          In the GeoServer 2.1.x series, in order to have cross-layer filters execute with optimal performance it is necessary to specify the following system variable when starting the JVM:

                                                                          -Dorg.geotools.filter.function.simplify=true\n

                                                                          This ensures the functions are evaluated once per query, instead of once per result feature. This flag is not necessary for the GeoServer 2.2.x series. (Hopefully this behavior will become the default in 2.1.x as well.)

                                                                          "},{"location":"extensions/querylayer/#memory-limits","title":"Memory limits","text":"

                                                                          The queryCollection and collectGeometries functions do not perform a true database-style join. Instead they execute a query against the secondary layer every time they are executed, and load the entire result into memory. The functions thus risk using excessive server memory if the query result set is very large, or if the collected geometries are very large. To prevent impacting server stability there are built-in limits to how much data can be processed:

                                                                          • at most 1000 features are collected by queryCollection
                                                                          • at most 37000 coordinates (1MB worth of Coordinate objects) are collected by collectGeometries

                                                                          These limits can be overridden by setting alternate values for the following parameters (this can be done using JVM system variables, servlet context variables, or environment variables):

                                                                          • QUERY_LAYER_MAX_FEATURES controls the maximum number of features collected by queryCollection
                                                                          • GEOMETRY_COLLECT_MAX_COORDINATES controls the maximum number of coordinates collected by collectGeometries
                                                                          "},{"location":"extensions/querylayer/#wms-examples","title":"WMS Examples","text":"

                                                                          The following examples use the sf:bugsites, sf:roads and sf:restricted demo layers available in the standard GeoServer download.

                                                                          • Display only the bug sites overlapping the restricted area whose category is 3:

                                                                          The CQL cross-layer filter on the bugsites layer is

                                                                          INTERSECTS(the_geom, querySingle('restricted', 'the_geom','cat = 3')).

                                                                          The WMS request is:

                                                                          http://localhost:8080/geoserver/wms?LAYERS=sf%3Aroads%2Csf%3Arestricted%2Csf%3Abugsites&STYLES=&FORMAT=image%2Fpng&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&EXCEPTIONS=application%2Fvnd.ogc.se_inimage&SRS=EPSG%3A26713&CQL_FILTER=INCLUDE%3BINCLUDE%3BINTERSECTS(the_geom%2C%20querySingle(%27restricted%27%2C%20%27the_geom%27%2C%27cat%20%3D%203%27))&BBOX=589081.6705629,4914128.1213261,609174.02430924,4928177.0717971&WIDTH=512&HEIGHT=358\n

                                                                          The result is:

                                                                          • Display all bug sites within 200 meters of any road:

                                                                          The CQL cross-layer filter on the bugsites layer is

                                                                          DWITHIN(the_geom, collectGeometries(queryCollection('sf:roads','the_geom','INCLUDE')), 200, meters).

                                                                          The WMS request is:

                                                                          http://localhost:8080/geoserver/wms?LAYERS=sf%3Aroads%2Csf%3Arestricted%2Csf%3Abugsites&STYLES=&FORMAT=image%2Fpng&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&EXCEPTIONS=application%2Fvnd.ogc.se_inimage&SRS=EPSG%3A26713&CQL_FILTER=INCLUDE%3BINCLUDE%3BDWITHIN(the_geom%2C%20collectGeometries(queryCollection(%27sf%3Aroads%27%2C%27the_geom%27%2C%27INCLUDE%27))%2C%20200%2C%20meters)&BBOX=589042.42768447,4914010.3926913,609134.78143081,4928059.3431623&WIDTH=512&HEIGHT=358\n

                                                                          The result is:

                                                                          "},{"location":"extensions/querylayer/#wfs-examples","title":"WFS Examples","text":"

                                                                          The following examples use the sf:bugsites, sf:roads and sf:restricted demo layers available in the standard GeoServer download.

                                                                          • Retrieve only the bug sites overlapping the restricted area whose category is 3:
                                                                          <wfs:GetFeature xmlns:wfs=\"http://www.opengis.net/wfs\"\n                xmlns:sf=\"http://www.openplans.org/spearfish\"\n                xmlns:ogc=\"http://www.opengis.net/ogc\"\n                service=\"WFS\" version=\"1.0.0\">\n  <wfs:Query typeName=\"sf:bugsites\">\n    <ogc:Filter>\n      <ogc:Intersects>\n        <ogc:PropertyName>the_geom</ogc:PropertyName>\n        <ogc:Function name=\"querySingle\">\n           <ogc:Literal>sf:restricted</ogc:Literal>\n           <ogc:Literal>the_geom</ogc:Literal>\n           <ogc:Literal>cat = 3</ogc:Literal>\n        </ogc:Function>\n      </ogc:Intersects>\n    </ogc:Filter>\n  </wfs:Query>\n</wfs:GetFeature>\n
                                                                          • Retrieve all bugsites within 200 meters of any road:
                                                                          <wfs:GetFeature xmlns:wfs=\"http://www.opengis.net/wfs\"\n  xmlns:sf=\"http://www.openplans.org/spearfish\"\n  xmlns:ogc=\"http://www.opengis.net/ogc\"\n  service=\"WFS\" version=\"1.0.0\">\n  <wfs:Query typeName=\"sf:bugsites\">\n    <ogc:Filter>\n      <ogc:DWithin>\n        <ogc:PropertyName>the_geom</ogc:PropertyName>\n        <ogc:Function name=\"collectGeometries\">\n          <ogc:Function name=\"queryCollection\">\n            <ogc:Literal>sf:roads</ogc:Literal>\n            <ogc:Literal>the_geom</ogc:Literal>\n            <ogc:Literal>INCLUDE</ogc:Literal>\n          </ogc:Function>\n        </ogc:Function>\n        <ogc:Distance units=\"meter\">100</ogc:Distance>\n      </ogc:DWithin>\n    </ogc:Filter>\n  </wfs:Query>\n</wfs:GetFeature>\n
                                                                          "},{"location":"extensions/sldservice/","title":"SLD REST Service","text":"

                                                                          The SLD Service is a GeoServer REST service that can be used to create SLD styles on published GeoServer layers doing a classification on the layer data, following user provided directives.

                                                                          The purpose of the service is to allow clients to dynamically publish data and create simple styles on it.

                                                                          All the services are published under the common prefix /rest/sldservice/{layer}, where layer is the layer to classify/query.

                                                                          "},{"location":"extensions/sldservice/#query-vector-data-attributes","title":"Query Vector Data Attributes","text":"

                                                                          /attributes[.<format>]

                                                                          Method Action Status code Formats Default Format GET Gets the list of attributes for the given layer (of vector type) 200 HTML, XML, JSON HTML

                                                                          The service can be used to get the attributes list for the given vector layer. This can be used by a client as a prerequisite for the classify service, to get all the attributes usable for classification and let the user choose one.

                                                                          "},{"location":"extensions/sldservice/#examples","title":"Examples","text":"

                                                                          Get attributes for the states layer, in XML format

                                                                          curl -v -u admin:geoserver -XGET \n  http://localhost:8080/geoserver/rest/sldservice/states/attributes.xml\n
                                                                          <Attributes layer=\"states\">\n  <Attribute>\n    <name>P_FEMALE</name>\n    <type>Double</type>\n  </Attribute>\n  <Attribute>\n    <name>HOUSHOLD</name>\n    <type>Double</type>\n  </Attribute>\n  <Attribute>\n    <name>SERVICE</name>\n    <type>Double</type>\n  </Attribute>\n  ...\n</Attributes>\n

                                                                          Get attributes for the states layer, in JSON format

                                                                          curl -v -u admin:geoserver -XGET \n  http://localhost:8080/geoserver/rest/sldservice/states/attributes.json\n
                                                                          {  \n   \"Attributes\":{  \n      \"@layer\":\"states\",\n      \"Attribute\":[  \n         {  \n            \"name\":\"P_FEMALE\",\n            \"type\":\"Double\"\n         },\n         {  \n            \"name\":\"HOUSHOLD\",\n            \"type\":\"Double\"\n         },\n         {  \n            \"name\":\"SERVICE\",\n            \"type\":\"Double\"\n         },\n         ...\n      ]\n   }\n}\n
                                                                          "},{"location":"extensions/sldservice/#classify-raster-and-vector-data","title":"Classify Raster and Vector Data","text":"

                                                                          /classify[.<format>]

                                                                          Method Action Status code Formats Default Format GET Create a set of SLD Rules for the given layer 200 HTML, XML, JSON HTML

                                                                          The service can be used to create a set of SLD rules for the given vector layer, specifying the attribute used for classification, the classification type (equalInterval, uniqueInterval, quantile, jenks, equalArea, standardDeviation) and one of the predefined color ranges (red, blue, gray, jet, random, custom), together with some other optional parameters.

                                                                          The same can be applied on a raster layer too, in order to classify its contents. Data from the first band is used by default, but a different one can be selected.

                                                                          Using the CUSTOM ColorMap, startColor and endColor (and optionally midColor) have to be specified.

                                                                          The parameters usable to customize the SLD are:

                                                                          Parameter Description Values Default Value intervals Number of intervals (rules) for the SLD integer numeric value 2 attribute (mandatory) Classification attribute For vector layers, one of the layer attribute names, for raster layers, a band number (starting from one, like in the raster symbolizer) No default for vectors, \"1\" for rasters method Classification method equalInterval, uniqueInterval, quantile, jenks, equalArea, standardDeviation (intervals above and below the mean of one standard deviation, available for vectors only) equalInterval open open or closed ranges true, false false reverse normal or inverted ranges true, false false normalize normalize (cast) attribute to double type (needed by some stores to handle integer types correctly) true, false false ramp color ranges to use red, blue, gray, jet, random, custom red startColor starting color for the custom ramp endColor ending color for the custom ramp midColor central color for the custom ramp colors list of comma delimited colors for the custom ramp (use this instead of startColor, endColor and midColor to specify colors in more detail) strokeColor color of the stroke, for points and polygons BLACK strokeWeight weight of the stroke, for points and polygons (use a negative value to not include stroke in style) 1 pointSize size of points 15 fullSLD create a full valid SLD document, instead of the Rules fragment only true or false false cache append caching headers to the responses expire time in seconds, use 0 to disable cache 600 (10 minutes) viewparams allows use of parametric views view parameters in the usual format (:;...;:) customClasses allows specifying a set of custom classes (client driven style); no classes calculation will happen (method, intervals, etc. are ignored) classes in the following format: ,,;...;,,) bbox allows to run the classification on a specific bounding box. Recommended when the overall dataset is too big, and the classification can be performed on a smaller dataset, or to enhance the visualization of a particular subset of data same syntax as WMS/WFS, expected axis order is east/north unless the spatial reference system is explicitly provided, minx,miny,max,maxy[,srsName] stddevs limits the data the classifier is working on to a range of \"stddevs\" standard deviations around the mean value. a positive floating-point number (e.g., '1', '2.5', '3'). env a list of environment variables that the underlying layer may be using to select features/rasters to be classified (e.g., by using the filter in vector and mosaic layer definitions) a semicolon separate list of name to value assignments, e.g. name1:value1;name2:value2;name3:value3;... continuous used only for raster layers, if set to true will generate a raster palette that interpolates linearly between classified values true false percentages allows to obtain percentages of values in each class. For raster layers they will be included in the label of the ColorMapEntry, while for vector layer they will be placed in the rule title; in both cases they will be placed at the end of the text between parentheses. true false percentagesScale number of digits of percentages integer numeric value 1 intervalsForUnique Max number of intervals (rules or ColorMapEntry) that a uniqueIntervalClassification can produce. If the number of classes produced by the classification is greater than the number specified by this parameter, the service will return an error message. integer numeric value -1"},{"location":"extensions/sldservice/#more-on-unique-intervals-classification","title":"More on unique intervals classification","text":"

                                                                          The intervalsForUnique parameter allows the user to control the number of classes generated by the classification, that is important when dealing with large dataset. In this case the check on the classes' number will be made once the unique interval classification has been performed. Additionally it is possible to define a system variable named org.geoserver.sldService.maxUniqueRange to define the maximum number of values that can be collected by the classification (default value is 1024). This control is performed before the unique interval classification is performed on the data. If the number of values is found to be greater than the system variable value, the service will return an error message.

                                                                          "},{"location":"extensions/sldservice/#examples_1","title":"Examples","text":"

                                                                          A default (equalInterval) classification on the states layer LAND_KM attribute using a red based color range.

                                                                          curl -v -u admin:geoserver -XGET \n  http://localhost:8080/geoserver/rest/sldservice/states/classify.xml?attribute=LAND_KM&ramp=red\n
                                                                          <Rules>\n  <Rule>\n    <Title> &gt; 159.1 AND &lt;= 344189.1</Title>\n    <Filter>\n      <And>\n        <PropertyIsGreaterThanOrEqualTo>\n          <PropertyName>LAND_KM</PropertyName>\n          <Literal>159.1</Literal>\n        </PropertyIsGreaterThanOrEqualTo>\n        <PropertyIsLessThanOrEqualTo>\n          <PropertyName>LAND_KM</PropertyName>\n          <Literal>344189.1</Literal>\n        </PropertyIsLessThanOrEqualTo>\n      </And>\n    </Filter>\n    <PolygonSymbolizer>\n      <Fill>\n        <CssParameter name=\"fill\">#680000</CssParameter>\n      </Fill>\n      <Stroke/>\n    </PolygonSymbolizer>\n  </Rule>\n  <Rule>\n    <Title> &gt; 344189.1 AND &lt;= 688219.2</Title>\n    <Filter>\n      <And>\n        <PropertyIsGreaterThan>\n          <PropertyName>LAND_KM</PropertyName>\n          <Literal>344189.1</Literal>\n        </PropertyIsGreaterThan>\n        <PropertyIsLessThanOrEqualTo>\n          <PropertyName>LAND_KM</PropertyName>\n          <Literal>688219.2</Literal>\n        </PropertyIsLessThanOrEqualTo>\n      </And>\n    </Filter>\n    <PolygonSymbolizer>\n      <Fill>\n        <CssParameter name=\"fill\">#B20000</CssParameter>\n      </Fill>\n      <Stroke/>\n    </PolygonSymbolizer>\n  </Rule>\n</Rules>\n

                                                                          A uniqueInterval classification on the states layer SUB_REGION attribute using a red based color range.

                                                                          curl -v -u admin:geoserver -XGET \n  http://localhost:8080/geoserver/rest/sldservice/states/classify.xml?attribute=SUB_REGION&ramp=red&method=uniqueInterval\n
                                                                          <Rules>\n  <Rule>\n    <Title>E N Cen</Title>\n    <Filter>\n      <PropertyIsEqualTo>\n        <PropertyName>SUB_REGION</PropertyName>\n        <Literal>E N Cen</Literal>\n      </PropertyIsEqualTo>\n    </Filter>\n    <PolygonSymbolizer>\n      <Fill>\n        <CssParameter name=\"fill\">#330000</CssParameter>\n      </Fill>\n      <Stroke/>\n    </PolygonSymbolizer>\n  </Rule>\n  <Rule>\n    <Title>E S Cen</Title>\n    <Filter>\n      <PropertyIsEqualTo>\n        <PropertyName>SUB_REGION</PropertyName>\n        <Literal>E S Cen</Literal>\n      </PropertyIsEqualTo>\n    </Filter>\n    <PolygonSymbolizer>\n      <Fill>\n        <CssParameter name=\"fill\">#490000</CssParameter>\n      </Fill>\n      <Stroke/>\n    </PolygonSymbolizer>\n  </Rule>\n  ...\n</Rules>\n

                                                                          A uniqueInterval classification on the states layer SUB_REGION attribute using a red based color range and 3 intervals.

                                                                          curl -v -u admin:geoserver -XGET \n  http://localhost:8080/geoserver/rest/sldservice/states/classify.xml?attribute=SUB_REGION&ramp=red&method=uniqueInterval&intervals=3\n
                                                                          <string>Intervals: 9</string>\n

                                                                          A quantile classification on the states layer PERSONS attribute with a custom color ramp and 3 closed intervals.

                                                                          curl -v -u admin:geoserver -XGET \n  http://localhost:8080/geoserver/rest/sldservice/states/classify.xml?attribute=PERSONS&ramp=CUSTOM&method=quantile&intervals=3&startColor=0xFF0000&endColor=0x0000FF\n
                                                                          <Rules>\n  <Rule>\n    <Title> &gt; 453588.0 AND &lt;= 2477574.0</Title>\n    <Filter>\n      <And>\n        <PropertyIsGreaterThanOrEqualTo>\n          <PropertyName>PERSONS</PropertyName>\n          <Literal>453588.0</Literal>\n        </PropertyIsGreaterThanOrEqualTo>\n        <PropertyIsLessThanOrEqualTo>\n          <PropertyName>PERSONS</PropertyName>\n          <Literal>2477574.0</Literal>\n        </PropertyIsLessThanOrEqualTo>\n      </And>\n    </Filter>\n    <PolygonSymbolizer>\n      <Fill>\n        <CssParameter name=\"fill\">#FF0000</CssParameter>\n      </Fill>\n      <Stroke/>\n    </PolygonSymbolizer>\n  </Rule>\n  <Rule>\n    <Title> &gt; 2477574.0 AND &lt;= 4866692.0</Title>\n    <Filter>\n      <And>\n        <PropertyIsGreaterThan>\n          <PropertyName>PERSONS</PropertyName>\n          <Literal>2477574.0</Literal>\n        </PropertyIsGreaterThan>\n        <PropertyIsLessThanOrEqualTo>\n          <PropertyName>PERSONS</PropertyName>\n          <Literal>4866692.0</Literal>\n        </PropertyIsLessThanOrEqualTo>\n      </And>\n    </Filter>\n    <PolygonSymbolizer>\n      <Fill>\n        <CssParameter name=\"fill\">#AA0055</CssParameter>\n      </Fill>\n      <Stroke/>\n    </PolygonSymbolizer>\n  </Rule>\n  <Rule>\n    <Title> &gt; 4866692.0 AND &lt;= 2.9760021E7</Title>\n    <Filter>\n      <And>\n        <PropertyIsGreaterThan>\n          <PropertyName>PERSONS</PropertyName>\n          <Literal>4866692.0</Literal>\n        </PropertyIsGreaterThan>\n        <PropertyIsLessThanOrEqualTo>\n          <PropertyName>PERSONS</PropertyName>\n          <Literal>2.9760021E7</Literal>\n        </PropertyIsLessThanOrEqualTo>\n      </And>\n    </Filter>\n    <PolygonSymbolizer>\n      <Fill>\n        <CssParameter name=\"fill\">#5500AA</CssParameter>\n      </Fill>\n      <Stroke/>\n    </PolygonSymbolizer>\n  </Rule>\n</Rules>\n

                                                                          A quantile classification on the states layer PERSONS attribute with a custom color ramp and 3 open intervals.

                                                                          curl -v -u admin:geoserver -XGET \n  http://localhost:8080/geoserver/rest/sldservice/states/classify.xml?attribute=PERSONS&ramp=CUSTOM&method=quantile&intervals=3&startColor=0xFF0000&endColor=0x0000FF&open=true\n
                                                                          <Rules>\n  <Rule>\n    <Title> &lt;= 2477574.0</Title>\n    <Filter>\n      <PropertyIsLessThanOrEqualTo>\n        <PropertyName>PERSONS</PropertyName>\n        <Literal>2477574.0</Literal>\n      </PropertyIsLessThanOrEqualTo>\n    </Filter>\n    <PolygonSymbolizer>\n      <Fill>\n        <CssParameter name=\"fill\">#FF0000</CssParameter>\n      </Fill>\n      <Stroke/>\n    </PolygonSymbolizer>\n  </Rule>\n  <Rule>\n    <Title> &gt; 2477574.0 AND &lt;= 4866692.0</Title>\n    <Filter>\n      <And>\n        <PropertyIsGreaterThan>\n          <PropertyName>PERSONS</PropertyName>\n          <Literal>2477574.0</Literal>\n        </PropertyIsGreaterThan>\n        <PropertyIsLessThanOrEqualTo>\n          <PropertyName>PERSONS</PropertyName>\n          <Literal>4866692.0</Literal>\n        </PropertyIsLessThanOrEqualTo>\n      </And>\n    </Filter>\n    <PolygonSymbolizer>\n      <Fill>\n        <CssParameter name=\"fill\">#AA0055</CssParameter>\n      </Fill>\n      <Stroke/>\n    </PolygonSymbolizer>\n  </Rule>\n  <Rule>\n    <Title> &gt; 4866692.0</Title>\n    <Filter>\n      <PropertyIsGreaterThan>\n        <PropertyName>PERSONS</PropertyName>\n        <Literal>4866692.0</Literal>\n      </PropertyIsGreaterThan>\n    </Filter>\n    <PolygonSymbolizer>\n      <Fill>\n        <CssParameter name=\"fill\">#5500AA</CssParameter>\n      </Fill>\n      <Stroke/>\n    </PolygonSymbolizer>\n  </Rule>\n</Rules>\n
                                                                          "},{"location":"extensions/sldservice/#classify-raster-data","title":"Classify Raster Data","text":"

                                                                          This resource is deprecated, as the classify endpoint can now also handle raster data

                                                                          /rasterize[.<format>]

                                                                          Method Action Status code Formats Default Format GET Create a ColorMap SLD for the given layer (of coverage type) 200 HTML, XML, JSON, SLD HTML

                                                                          The service can be used to create a ColorMap SLD for the given coverage, specifying the type of ColorMap (VALUES, INTERVALS, RAMP) and one of the predefined color ranges (RED, BLUE, GRAY, JET, RANDOM, CUSTOM).

                                                                          Using the CUSTOM ColorMap, startColor and endColor (and optionally midColor) have to be specified.

                                                                          The parameters usable to customize the ColorMap are:

                                                                          Parameter Description Values Default Value min Minimum value for classification double numeric value 0.0 max Maximum value for classification double numeric value 100.0 classes Number of classes for the created map integer numeric value 100 digits Number of fractional digits for class limits (in labels) integer numeric value 5 type ColorMap type INTERVALS, VALUES, RAMP RAMP ramp ColorMap color ranges RED, BLUE, GRAY, JET, RANDOM, CUSTOM RED startColor starting color for the CUSTOM ramp endColor ending color for the CUSTOM ramp midColor central color for the CUSTOM ramp cache append caching headers to the responses expire time in seconds, use 0 to disable cache 600 (10 minutes)"},{"location":"extensions/sldservice/#examples_2","title":"Examples","text":"

                                                                          A RED color ramp with 5 classes

                                                                          curl -v -u admin:geoserver -XGET \n  http://localhost:8080/geoserver/rest/sldservice/sfdem/rasterize.sld?min=0&max=100&classes=5&type=RAMP&ramp=RED&digits=1\n
                                                                          <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<sld:StyledLayerDescriptor xmlns=\"http://www.opengis.net/sld\" xmlns:sld=\"http://www.opengis.net/sld\" xmlns:ogc=\"http://www.opengis.net/ogc\" xmlns:gml=\"http://www.opengis.net/gml\" version=\"1.0.0\">\n    <sld:NamedLayer>\n        <sld:Name>Default Styler</sld:Name>\n        <sld:UserStyle>\n            <sld:Name>Default Styler</sld:Name>\n            <sld:FeatureTypeStyle>\n                <sld:Name>name</sld:Name>\n                <sld:FeatureTypeName>gray</sld:FeatureTypeName>\n                <sld:Rule>\n                    <sld:RasterSymbolizer>\n                        <sld:ColorMap>\n                            <sld:ColorMapEntry color=\"#000000\" opacity=\"0\" quantity=\"-1.0E-9\" label=\"transparent\"/>\n                            <sld:ColorMapEntry color=\"#420000\" opacity=\"1.0\" quantity=\"0.0\" label=\"0.0\"/>\n                            <sld:ColorMapEntry color=\"#670000\" opacity=\"1.0\" quantity=\"25.0\" label=\"25.0\"/>\n                            <sld:ColorMapEntry color=\"#8B0000\" opacity=\"1.0\" quantity=\"50.0\" label=\"50.0\"/>\n                            <sld:ColorMapEntry color=\"#B00000\" opacity=\"1.0\" quantity=\"75.0\" label=\"75.0\"/>\n                            <sld:ColorMapEntry color=\"#D40000\" opacity=\"1.0\" quantity=\"100.0\" label=\"100.0\"/>\n                        </sld:ColorMap>\n                    </sld:RasterSymbolizer>\n                </sld:Rule>\n            </sld:FeatureTypeStyle>\n        </sld:UserStyle>\n    </sld:NamedLayer>\n</sld:StyledLayerDescriptor>\n

                                                                          A CUSTOM color ramp with 5 classes, with colors ranging from RED (0xFF0000) to BLUE (0x0000FF).

                                                                          curl -v -u admin:geoserver -XGET \n  http://localhost:8080/geoserver/rest/sldservice/sfdem/rasterize.sld?min=0&max=100&classes=5&type=RAMP&ramp=CUSTOM&digits=1&startColor=0xFF0000&endColor=0x0000FF\n
                                                                          <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<sld:StyledLayerDescriptor xmlns=\"http://www.opengis.net/sld\" xmlns:sld=\"http://www.opengis.net/sld\" xmlns:ogc=\"http://www.opengis.net/ogc\" xmlns:gml=\"http://www.opengis.net/gml\" version=\"1.0.0\">\n    <sld:NamedLayer>\n        <sld:Name>Default Styler</sld:Name>\n        <sld:UserStyle>\n            <sld:Name>Default Styler</sld:Name>\n            <sld:FeatureTypeStyle>\n                <sld:Name>name</sld:Name>\n                <sld:FeatureTypeName>gray</sld:FeatureTypeName>\n                <sld:Rule>\n                    <sld:RasterSymbolizer>\n                        <sld:ColorMap>\n                            <sld:ColorMapEntry color=\"#000000\" opacity=\"0\" quantity=\"-1.0E-9\" label=\"transparent\"/>\n                            <sld:ColorMapEntry color=\"#FF0000\" opacity=\"1.0\" quantity=\"0.0\" label=\"0.0\"/>\n                            <sld:ColorMapEntry color=\"#CC0033\" opacity=\"1.0\" quantity=\"25.0\" label=\"25.0\"/>\n                            <sld:ColorMapEntry color=\"#990066\" opacity=\"1.0\" quantity=\"50.0\" label=\"50.0\"/>\n                            <sld:ColorMapEntry color=\"#660099\" opacity=\"1.0\" quantity=\"75.0\" label=\"75.0\"/>\n                            <sld:ColorMapEntry color=\"#3300CC\" opacity=\"1.0\" quantity=\"100.0\" label=\"100.0\"/>\n                        </sld:ColorMap>\n                    </sld:RasterSymbolizer>\n                </sld:Rule>\n            </sld:FeatureTypeStyle>\n        </sld:UserStyle>\n    </sld:NamedLayer>\n</sld:StyledLayerDescriptor>\n
                                                                          "},{"location":"extensions/sldservice/#capabilities","title":"Capabilities","text":"

                                                                          /capabilities[.<format>]

                                                                          Method Action Status code Formats Default Format GET Returns the supported classification's methods for rasters and vectors 200 JSON, XML JSON

                                                                          The service can be used to retrieve the capabilities of the SldService plugin. At the time of writing the endpoint will simply return a list of supported classification's methods for both raster and vector data. It can be useful i.e. for clients who might be dealing with different GeoServer versions to know which classification methods is available to be used. Follow the service's outputs in json and xml format:

                                                                          {\n\"capabilities\": {\n    \"vector\": {\n        \"classifications\": [\n            \"quantile\",\n            \"jenks\",\n            \"equalArea\",\n            \"equalInterval\",\n            \"uniqueInterval\",\n            \"standardDeviation\"\n        ]\n    },\n    \"raster\": {\n        \"classifications\": [\n            \"quantile\",\n            \"jenks\",\n            \"equalArea\",\n            \"equalInterval\",\n            \"uniqueInterval\"\n        ]\n    }\n}\n}\n
                                                                          <capabilities>\n  <vector>\n      <classifications>quantile</classifications>\n      <classifications>jenks</classifications>\n      <classifications>equalArea</classifications>\n      <classifications>equalInterval</classifications>\n      <classifications>uniqueInterval</classifications>\n      <classifications>standardDeviation</classifications>\n  </vector>\n  <raster>\n      <classifications>quantile</classifications>\n      <classifications>jenks</classifications>\n      <classifications>equalArea</classifications>\n      <classifications>equalInterval</classifications>\n      <classifications>uniqueInterval</classifications>\n  </raster>\n</capabilities>\n
                                                                          "},{"location":"extensions/vectortiles/","title":"Vector Tiles","text":"

                                                                          GeoServer supports \"vector tile\" output in addition to the more standard image tile output. While the standard WMS output will generate a georeferenced map image, a vector tile contains georeferenced vector data, clipped into tiles for easy retrieval.

                                                                          Note

                                                                          This is an output format, not a data source.

                                                                          Note

                                                                          Here are two background video talks about \"Vector Tiles with GeoServer and OpenLayers\":

                                                                          • FOSS4G.NA 2016
                                                                          • FOSS4G 2016
                                                                          • Installing the Vector Tiles Extension
                                                                          • Vector tiles tutorial
                                                                          "},{"location":"extensions/vectortiles/install/","title":"Installing the Vector Tiles Extension","text":"
                                                                          1. From the website download page, locate your release, and download: vectortiles

                                                                            Warning

                                                                            Make sure to match the version of the extension to the version of GeoServer.

                                                                          2. Extract the archive and copy the contents into the GeoServer WEB-INF/lib directory.

                                                                          3. Restart GeoServer.

                                                                          To verify that the extension was installed successfully

                                                                          1. Open the Web administration interface

                                                                          2. Click Layers and select a vector layer

                                                                          3. Click the Tile Caching tab

                                                                          4. Scroll down to the section on Tile Formats. In addition to the standard GIF/PNG/JPEG formats, you should see the following:

                                                                            • application/json;type=geojson
                                                                            • application/json;type=topojson
                                                                            • application/vnd.mapbox-vector-tile

                                                                            Vector tiles tile formats

                                                                            If you don't see these options, the extension did not install correctly.

                                                                          "},{"location":"extensions/vectortiles/tutorial/","title":"Vector tiles tutorial","text":"

                                                                          This tutorial will show how to use the GeoServer vector tiles output.

                                                                          "},{"location":"extensions/vectortiles/tutorial/#why-use-vector-tiles","title":"Why use vector tiles?","text":"

                                                                          The advantages of vector tiles are:

                                                                          • Rendering is done by the client (for example, OpenLayers), not by the server. This allows different maps/applications to style a map differently without having to reconfigure GeoServer.
                                                                          • The size of a vector tile is usually smaller than an image tile, resulting in faster data transfer and lower bandwidth usage.
                                                                          • GeoWebCache, embedded with GeoServer efficiently stores the vector tile data. Since styling is done by the client, not the server, GeoWebCache only needs to store one tile for all different styles.
                                                                          • Because the vector data is available on the client, very high-resolution maps can be drawn without corresponding increases in bandwidth.
                                                                          • The client has native access to the actual feature information (attributes and geometry), allowing for very sophisticated rendering.

                                                                          On the other hand, the main disadvantage of vector tiles is that the geographic data may need to be pre-processed to allow the client to do the drawings it requires (similar to preprocessing data for image maps). With this in mind, vector tiles should only be used for rendering.

                                                                          "},{"location":"extensions/vectortiles/tutorial/#vector-tile-formats","title":"Vector tile formats","text":"

                                                                          GeoServer can also produce vector tiles in three formats: GeoJSON, TopoJSON, and MapBox Vector (MVT). These are also supported by OpenLayers and other clients.

                                                                          • MVT is the preferred format for production.
                                                                          Format MIME Description MapBox Vector (MVT) application/vnd.mapbox-vector-tile Recommended Format This is an efficient binary format that is widely supported by almost all Vector Tile applications. GeoJSON application/json;type=geojson This is a human readable JSON format. Although many geo-spatial applications support GeoJSON datasets, few Vector Tile applications support tiles in this format. Supported by Open Layers 3. TopoJSON application/json;type=topojson This is a very complex, but somewhat human readable JSON format that is good for polygon coverages. It is not a widely supported and very few Vector Tile applications support it. Supported by Open Layers 3."},{"location":"extensions/vectortiles/tutorial/#publish-vector-tiles-in-geowebcache","title":"Publish vector tiles in GeoWebCache","text":"

                                                                          We'll be publishing our vector tiles through GeoWebCache and publishing the layer in a custom OpenLayers application.

                                                                          For this tutorial, we'll be using the layer opengeo:countries to show off the capabilities, though with slight modifications, any layer will do.

                                                                          Note

                                                                          Download the Admin 0 - Countries shapefile and publish the layer as opengeo:countries.

                                                                          1. In the GeoServer admin interface, click Tile Layers under Tile Caching.

                                                                            Tile Layers

                                                                          2. Click opengeo:countries in the list of layers.

                                                                          3. By default the tile formats are image/jpeg and image/png. Check the boxes for the following vector tile formats:

                                                                            • application/json;type=geojson
                                                                            • application/json;type=topojson
                                                                            • application/vnd.mapbox-vector-tile

                                                                            Vector tiles tile formats

                                                                          4. Click Save.

                                                                          Our layer is now ready to be served.

                                                                          "},{"location":"extensions/vectortiles/tutorial/#create-openlayers-application-tms-vector-tiles","title":"Create OpenLayers application - TMS Vector Tiles","text":"
                                                                          1. Create a www/tms-vectortiles directory inside your GeoServer Data Directory.

                                                                          2. Download the latest version of OpenLayers. Download the v-package.zip file`_.

                                                                          3. Extract the following files from the downloaded archive to the directory created in step 1:

                                                                            • v<ol-version>-package/dist/ol.js
                                                                            • v<ol-version>-package/ol.css
                                                                          4. In a text editor, create a new file with the following content:

                                                                            <!DOCTYPE html -->\n<html>\n<head>\n  <title>Vector tiles</title>\n  <script src=\"ol.js\"></script>\n  <link rel=\"stylesheet\" href=\"ol.css\">\n  <style>\n    html, body {\n      font-family: sans-serif;\n      width: 100%;\n    }\n    .map {\n      height: 500px;\n      width: 100%;\n    }\n  </style>\n</head>\n<body>\n  <h3>Mapbox Protobuf - vector tiles TMS</h3>\n  <div id=\"map\" class=\"map\"></div>\n  <script>\n\n  var style_simple = new ol.style.Style({\n    fill: new ol.style.Fill({\n      color: '#ADD8E6'\n    }),\n    stroke: new ol.style.Stroke({\n      color: '#880000',\n      width: 1\n    })\n  });\n\n  function simpleStyle(feature) { \n    return style_simple;\n  }\n\n  var layer = 'opengeo:countries';\n  var projection_epsg_no = '900913';\n  var map = new ol.Map({\n    target: 'map',\n    view: new ol.View({\n      center: [0, 0],\n      zoom: 2\n    }),\n    layers: [new ol.layer.VectorTile({\n      style:simpleStyle,\n      source: new ol.source.VectorTile({\n        tilePixelRatio: 1, // oversampling when > 1\n        tileGrid: ol.tilegrid.createXYZ({maxZoom: 19}),\n        format: new ol.format.MVT(),\n        url: '/geoserver/gwc/service/tms/1.0.0/' + layer +\n            '@EPSG%3A'+projection_epsg_no+'@pbf/{z}/{x}/{-y}.pbf'\n      })\n    })]\n  });\n  </script>\n</body>\n</html>\n
                                                                          5. Save this file in the directory created above as index.html.

                                                                          6. Navigate to http://localhost:8080/geoserver/www/tms-vectortiles/index.html and verify that the output shows without any errors.

                                                                            Note

                                                                            If your GeoServer is deployed at a server other than http://localhost:8080/geoserver/, then please adjust the above URL.

                                                                            Vector tile output

                                                                          7. These tiles are being rendered by the OpenLayers client.

                                                                            "},{"location":"extensions/vectortiles/tutorial/#create-openlayers-application-wms-vector-tiles","title":"Create OpenLayers application - WMS Vector Tiles","text":"

                                                                            Note

                                                                            Vector tiles requested with WMS allows retrieving non-cached vector tiles (server side) by setting the tiled=false parameter on the getMap request. This setting could be particularly useful when serving fast changing source data that should constantly be kept up-to-date for display. However, in terms of rendering performances, vector tiles can be faster than a PNG provided there are few features per tile and a limited amount of attributes in the source vector data. Vice versa, for tiles containing a large number of features with a long list of attributes the PNG may still be the preferred option since it is orders of magnitude smaller in size.

                                                                            1. Create a www/wms-vectortiles directory inside your GeoServer Data Directory.

                                                                            2. Download the latest version of OpenLayers. Download the v-package.zip file.

                                                                            3. Extract the following files from the downloaded archive to the directory created in step 1:

                                                                              • v<ol-version>-package/dist/ol.js
                                                                              • v<ol-version>-package/ol.css
                                                                            4. In a text editor, create a new file with the following content:

                                                                              <!doctype html>\n<html>\n<head>\n  <title>Vector tiles</title>\n  <script src=\"ol.js\"></script>\n  <link rel=\"stylesheet\" href=\"ol.css\">\n  <style>\n    html, body {\n      font-family: sans-serif;\n      width: 100%;\n    }\n    .map {\n      height: 500px;\n      width: 100%;\n    }\n  </style>\n</head>\n<body>\n  <h3>Mapbox Protobuf - vector tiles WMS</h3>\n  <div class=\"refresh-container\">\n  <button id=\"refresh-button\" type=\"button\" onclick=\"updateFunc();\">Refresh/reload cache</button>\n  </div>\n  <div id=\"map\" class=\"map\"></div>\n  <script>\n\n    var layerParams = {'LAYERS': 'opengeo:countries', 'TILED': false, 'FORMAT': 'application/vnd.mapbox-vector-tile'};\n\n  var sourceOptions = {\n      url: '/geoserver/wms?',\n      params: layerParams,\n      serverType: 'geoserver',\n      transition: 0,\n      hidpi: false\n    };\n\n  var WMSTileSource = new ol.source.TileWMS(sourceOptions);\n\n  var mvtVectorSource = new ol.source.VectorTile(\n    Object.assign(\n      sourceOptions,\n      {\n        url: undefined,\n        format: new ol.format.MVT({layerName: '_layer_'}),\n        tileUrlFunction: function(tileCoord, pixelRatio, projection) {\n          return WMSTileSource.tileUrlFunction(tileCoord, pixelRatio, projection);\n        }\n      }\n    )\n  );\n\n\n    var updateFunc = function () {\n    WMSTileSource.updateParams(\n      Object.assign(\n        layerParams,\n        {\n          '_v_' : Date.now()\n        }\n      )\n    );\n    WMSTileSource.tileCache.pruneExceptNewestZ();\n    mvtVectorSource.clear();\n    mvtVectorSource.refresh();\n  };\n\n\n  var layer = new ol.layer.VectorTile({\n    source: mvtVectorSource\n  });\n\n  var map = new ol.Map({\n    target: 'map',\n    view: new ol.View({\n      center: [0,0],\n      zoom: 2\n    }),\n    layers: [layer]\n  });\n\n  </script>\n</body>\n</html>\n
                                                                            5. Save this file in the directory created above as index.html.

                                                                            6. Navigate to http://localhost:8080/geoserver/www/wms-vectortiles/index.html and verify that the output shows without any errors.

                                                                              Note

                                                                              If your GeoServer is deployed at a server other than http://localhost:8080/geoserver/, then please adjust the above URL.

                                                                            7. "},{"location":"extensions/vectortiles/tutorial/#styling-vector-tiles","title":"Styling vector tiles","text":"

                                                                              Since these tiles are rendered in the client, we need only change the styling instructions inside the client application. No changes to GeoServer are required, and tiles will not have to be regenerated.

                                                                              1. Change the fill color to light green:

                                                                                var style_simple = new ol.style.Style({\n  fill: new ol.style.Fill({\n    color: 'lightgreen'\n  }),\n   stroke: new ol.style.Stroke({\n      color: '#880000',\n      width: 1\n    })\n}) ;\n
                                                                              2. Save the file and reload the application.

                                                                                Vector tile output with alternate color

                                                                              3. We can also do attributed-based styling. This dataset contains has a property (region_un) which contains the region the country is in. Let's highlight countries in Africa by adding another style definition below the existing style:

                                                                                var style_highlighted = new ol.style.Style({\n  fill: new ol.style.Fill({\n    color: 'yellow'\n  }),\n  stroke: new ol.style.Stroke({\n    color: '#880000',\n    width: 1\n  })\n});\n
                                                                              4. Replace the existing style function:

                                                                                function simpleStyle(feature) { \n  return style_simple;\n}\n

                                                                                with the following:

                                                                                function simpleStyle(feature) { \n  if (feature.get(\"region_un\") == \"Africa\") {\n    return style_highlighted;\n  }\n  return style_simple;\n}\n
                                                                              5. Save the file and reload the application.

                                                                                Vector tile output with Africa highlighted

                                                                              "},{"location":"extensions/wcs20eo/","title":"Web Coverage Service 2.0 Earth Observation extensions","text":"

                                                                              The WCS 2.0 Earth Observation application profile (EO-WCS, OGC 10-140r1) extends the base WCS 2.0 protocol by adding temporal support and complex coverage structural description to the base WCS 2.0 protocol, in addition to requiring that a number of other extensions are supported - the base GeoServer WCS 2.0 module already supports all of those, such as subsetting and reprojection for example). The full specification can be downloaded from the OGC website.

                                                                              In the WCS 2.0 EO data model we not only have coverages, but also stitched mosaics (sets of coverages making up a mosaic of images, all granules having the same time and elevation) and dataset series, groups of coverages having different times and/or other attributes (elevation, custom dimensions). A dataset series is exposed in the capabilities document (inside the extension section) and its internal structure can be retrieved calling the new DescribeEOCoverageSet call. At the time of writing the EO extension adds support for dataset series, but does not provide direct support for stitched mosaic description.

                                                                              Each grid layer exposing its inner structure will then expose a flag to enable its exposure as a dataset series. At the time of writing, the only grid readers capable of exposing their internal structure are image mosaic and netCDF.

                                                                              "},{"location":"extensions/wcs20eo/#installing-the-wcs-20-eo-extension","title":"Installing the WCS 2.0 EO extension","text":"

                                                                              The steps to install the EO extension as the same as most other extensions:

                                                                              • Go to the website download page, locate the release used
                                                                              • Look among the extensions for WCS 2.0 EO extension package to download: wcs2_0-eo
                                                                              • Stop GeoServer (or the web container hosting it)
                                                                              • Unpack the contents of the zip file in the geoserver WEB-INF/lib folder
                                                                              • Restart GeoServer
                                                                              "},{"location":"extensions/wcs20eo/#exposing-dataset-series","title":"Exposing dataset series","text":"

                                                                              The first step to work with EO is to go into the WCS service panel and enable the EO extensions:

                                                                              Enabling the WCS 2.0 EO extensions

                                                                              The second step is finding and activating the EO extensions for a suitable grid layer, which needs to be one with time dimension support and ability to describe its inner structure. At the time of writing, this means a image mosaic with time support or a netCDF data layer with time dimension. Once the layer is located, the EO extensions for it can be enabled by ticking a checkbox in the publishing tab:

                                                                              Exposing a layer as a dataset

                                                                              Once that is done the capabilities document (e.g. http://localhost:8080/geoserver/ows?service=WCS&version=2.0.1&request=GetCapabilities for WCS 2.0 will contain an indication that a coverage set is present:

                                                                              <wcs:Extension>\n  <wcseo:DatasetSeriesSummary>\n    <ows:WGS84BoundingBox>\n      <ows:LowerCorner>0.2372206885127698 40.562080748421806</ows:LowerCorner>\n      <ows:UpperCorner>14.592757149389236 44.55808294568743</ows:UpperCorner>\n    </ows:WGS84BoundingBox>\n    <wcseo:DatasetSeriesId>nurc__watertemp_dss</wcseo:DatasetSeriesId>\n    <gml:TimePeriod gml:id=\"nurc__watertemp_dss__timeperiod\">\n      <gml:beginPosition>2008-10-31T00:00:00.000Z</gml:beginPosition>\n      <gml:endPosition>2008-11-01T00:00:00.000Z</gml:endPosition>\n   </gml:TimePeriod>\n  </wcseo:DatasetSeriesSummary>\n</wcs:Extension>\n

                                                                              And issuing a DescribeEOCoverageSet (e.g. http://localhost:8080/geoserver/ows?service=WCS&version=2.0.1&request=DescribeEOCoverageSet&eoId=nurc__watertemp_dss) on it will return the following:

                                                                              <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<wcseo:EOCoverageSetDescription xmlns:eop=\"http://www.opengis.net/eop/2.0\" xmlns:gml=\"http://www.opengis.net/gml/3.2\" xmlns:wcsgs=\"http://www.geoserver.org/wcsgs/2.0\" xmlns:gmlcov=\"http://www.opengis.net/gmlcov/1.0\" xmlns:om=\"http://www.opengis.net/om/2.0\" xmlns:swe=\"http://www.opengis.net/swe/2.0\" xmlns:wcs=\"http://www.opengis.net/wcs/2.0\" xmlns:wcseo=\"http://www.opengis.net/wcseo/1.0\" xmlns:xlink=\"http://www.w3.org/1999/xlink\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" numberMatched=\"4\" numberReturned=\"4\" xsi:schemaLocation=\"http://www.opengis.net/wcseo/1.0 http://localhost:8080/geoserver/schemas/wcseo/1.0/wcsEOAll.xsd\">\n  <wcs:CoverageDescriptions>\n    <wcs:CoverageDescription gml:id=\"nurc__watertemp_granule_watertemp.1\">\n      <gml:boundedBy>\n        <gml:EnvelopeWithTimePeriod srsName=\"http://www.opengis.net/def/crs/EPSG/0/4326\" axisLabels=\"Lat Long time\" uomLabels=\"Deg Deg s\" srsDimension=\"2\">\n          <gml:lowerCorner>40.562080748421806 0.23722068851276978</gml:lowerCorner>\n          <gml:upperCorner>44.55808294568743 14.592757149389236</gml:upperCorner>\n          <gml:beginPosition>2008-11-01T00:00:00.000Z</gml:beginPosition>\n          <gml:endPosition>2008-11-01T00:00:00.000Z</gml:endPosition>\n        </gml:EnvelopeWithTimePeriod>\n      </gml:boundedBy>\n      <wcs:CoverageId>nurc__watertemp_granule_watertemp.1</wcs:CoverageId>\n      <gml:coverageFunction>\n        <gml:GridFunction>\n          <gml:sequenceRule axisOrder=\"+2 +1\">Linear</gml:sequenceRule>\n          <gml:startPoint>0 0</gml:startPoint>\n        </gml:GridFunction>\n      </gml:coverageFunction>\n      <gmlcov:metadata>\n        <gmlcov:Extension>\n          <wcsgs:TimeDomain default=\"2008-11-01T00:00:00.000Z\">\n            <gml:TimeInstant gml:id=\"nurc__watertemp_granule_watertemp.1_td_0\">\n              <gml:timePosition>2008-11-01T00:00:00.000Z</gml:timePosition>\n            </gml:TimeInstant>\n          </wcsgs:TimeDomain>\n          <wcseo:EOMetadata>\n            <eop:EarthObservation gml:id=\"nurc__watertemp_metadata\">\n              <om:phenomenonTime>\n                <gml:TimePeriod gml:id=\"nurc__watertemp_tp\">\n                  <gml:beginPosition>2008-11-01T00:00:00.000Z</gml:beginPosition>\n                  <gml:endPosition>2008-11-01T00:00:00.000Z</gml:endPosition>\n                </gml:TimePeriod>\n              </om:phenomenonTime>\n              <om:resultTime>\n                <gml:TimeInstant gml:id=\"nurc__watertemp_rt\">\n                  <gml:timePosition>2008-11-01T00:00:00.000Z</gml:timePosition>\n                </gml:TimeInstant>\n              </om:resultTime>\n              <om:procedure/>\n              <om:observedProperty/>\n              <om:FeatureOfInterest>\n                <eop:Footprint gml:id=\"nurc__watertemp_fp\">\n                  <eop:multiExtentOf>\n                    <gml:MultiSurface gml:id=\"nurc__watertemp_ms\" srsName=\"http://www.opengis.net/def/crs/EPSG/0/4326\">\n                      <gml:surfaceMembers>\n                        <gml:Polygon gml:id=\"nurc__watertemp_msp\">\n                          <gml:exterior>\n                            <gml:LinearRing>\n                              <gml:posList>40.562080748421806 0.23722068851276978 40.562080748421806 14.592757149389236 44.55808294568743 14.592757149389236 44.55808294568743 0.23722068851276978 40.562080748421806 0.23722068851276978</gml:posList>\n                            </gml:LinearRing>\n                          </gml:exterior>\n                        </gml:Polygon>\n                      </gml:surfaceMembers>\n                    </gml:MultiSurface>\n                  </eop:multiExtentOf>\n                  <eop:centerOf>\n                    <gml:Point gml:id=\"nurc__watertemp_co\" srsName=\"http://www.opengis.net/def/crs/EPSG/0/4326\">\n                      <gml:pos>42.56008184705462 7.4149889189510025</gml:pos>\n                    </gml:Point>\n                  </eop:centerOf>\n                </eop:Footprint>\n              </om:FeatureOfInterest>\n              <eop:metaDataProperty>\n                <eop:EarthObservationMetaData>\n                  <eop:identifier>nurc__watertemp</eop:identifier>\n                  <eop:acquisitionType>NOMINAL</eop:acquisitionType>\n                  <eop:status>ARCHIVED</eop:status>\n                </eop:EarthObservationMetaData>\n              </eop:metaDataProperty>\n            </eop:EarthObservation>\n          </wcseo:EOMetadata>\n        </gmlcov:Extension>\n      </gmlcov:metadata>\n      <gml:domainSet>\n        <gml:RectifiedGrid gml:id=\"grid00__nurc__watertemp_granule_watertemp.1\" dimension=\"2\">\n          <gml:limits>\n            <gml:GridEnvelope>\n              <gml:low>0 0</gml:low>\n              <gml:high>24 24</gml:high>\n            </gml:GridEnvelope>\n          </gml:limits>\n          <gml:axisLabels>i j</gml:axisLabels>\n          <gml:origin>\n            <gml:Point gml:id=\"p00_nurc__watertemp_granule_watertemp.1\" srsName=\"http://www.opengis.net/def/crs/EPSG/0/4326\">\n              <gml:pos>44.47816290174212 0.5243314177302991</gml:pos>\n            </gml:Point>\n          </gml:origin>\n          <gml:offsetVector srsName=\"http://www.opengis.net/def/crs/EPSG/0/4326\">0.0 0.5742214584350587</gml:offsetVector>\n          <gml:offsetVector srsName=\"http://www.opengis.net/def/crs/EPSG/0/4326\">-0.159840087890625 0.0</gml:offsetVector>\n        </gml:RectifiedGrid>\n      </gml:domainSet>\n      <gmlcov:rangeType>\n        <swe:DataRecord>\n          <swe:field name=\"GRAY_INDEX\">\n            <swe:Quantity>\n              <swe:description>GRAY_INDEX</swe:description>\n              <swe:uom code=\"W.m-2.Sr-1\"/>\n              <swe:constraint>\n                <swe:AllowedValues>\n                  <swe:interval>-1.7976931348623157E308 1.7976931348623157E308</swe:interval>\n                </swe:AllowedValues>\n              </swe:constraint>\n            </swe:Quantity>\n          </swe:field>\n        </swe:DataRecord>\n      </gmlcov:rangeType>\n      <wcs:ServiceParameters>\n        <wcs:CoverageSubtype>RectifiedGridCoverage</wcs:CoverageSubtype>\n        <wcs:nativeFormat>image/tiff</wcs:nativeFormat>\n      </wcs:ServiceParameters>\n    </wcs:CoverageDescription>\n    <wcs:CoverageDescription gml:id=\"nurc__watertemp_granule_watertemp.2\">\n      <gml:boundedBy>\n        <gml:EnvelopeWithTimePeriod srsName=\"http://www.opengis.net/def/crs/EPSG/0/4326\" axisLabels=\"Lat Long time\" uomLabels=\"Deg Deg s\" srsDimension=\"2\">\n          <gml:lowerCorner>40.562080748421806 0.23722068851276978</gml:lowerCorner>\n          <gml:upperCorner>44.55808294568743 14.592757149389236</gml:upperCorner>\n          <gml:beginPosition>2008-11-01T00:00:00.000Z</gml:beginPosition>\n          <gml:endPosition>2008-11-01T00:00:00.000Z</gml:endPosition>\n        </gml:EnvelopeWithTimePeriod>\n      </gml:boundedBy>\n      <wcs:CoverageId>nurc__watertemp_granule_watertemp.2</wcs:CoverageId>\n      <gml:coverageFunction>\n        <gml:GridFunction>\n          <gml:sequenceRule axisOrder=\"+2 +1\">Linear</gml:sequenceRule>\n          <gml:startPoint>0 0</gml:startPoint>\n        </gml:GridFunction>\n      </gml:coverageFunction>\n      <gmlcov:metadata>\n        <gmlcov:Extension>\n          <wcsgs:TimeDomain default=\"2008-11-01T00:00:00.000Z\">\n            <gml:TimeInstant gml:id=\"nurc__watertemp_granule_watertemp.2_td_0\">\n              <gml:timePosition>2008-11-01T00:00:00.000Z</gml:timePosition>\n            </gml:TimeInstant>\n          </wcsgs:TimeDomain>\n          <wcseo:EOMetadata>\n            <eop:EarthObservation gml:id=\"nurc__watertemp_metadata\">\n              <om:phenomenonTime>\n                <gml:TimePeriod gml:id=\"nurc__watertemp_tp\">\n                  <gml:beginPosition>2008-11-01T00:00:00.000Z</gml:beginPosition>\n                  <gml:endPosition>2008-11-01T00:00:00.000Z</gml:endPosition>\n                </gml:TimePeriod>\n              </om:phenomenonTime>\n              <om:resultTime>\n                <gml:TimeInstant gml:id=\"nurc__watertemp_rt\">\n                  <gml:timePosition>2008-11-01T00:00:00.000Z</gml:timePosition>\n                </gml:TimeInstant>\n              </om:resultTime>\n              <om:procedure/>\n              <om:observedProperty/>\n              <om:FeatureOfInterest>\n                <eop:Footprint gml:id=\"nurc__watertemp_fp\">\n                  <eop:multiExtentOf>\n                    <gml:MultiSurface gml:id=\"nurc__watertemp_ms\" srsName=\"http://www.opengis.net/def/crs/EPSG/0/4326\">\n                      <gml:surfaceMembers>\n                        <gml:Polygon gml:id=\"nurc__watertemp_msp\">\n                          <gml:exterior>\n                            <gml:LinearRing>\n                              <gml:posList>40.562080748421806 0.23722068851276978 40.562080748421806 14.592757149389236 44.55808294568743 14.592757149389236 44.55808294568743 0.23722068851276978 40.562080748421806 0.23722068851276978</gml:posList>\n                            </gml:LinearRing>\n                          </gml:exterior>\n                        </gml:Polygon>\n                      </gml:surfaceMembers>\n                    </gml:MultiSurface>\n                  </eop:multiExtentOf>\n                  <eop:centerOf>\n                    <gml:Point gml:id=\"nurc__watertemp_co\" srsName=\"http://www.opengis.net/def/crs/EPSG/0/4326\">\n                      <gml:pos>42.56008184705462 7.4149889189510025</gml:pos>\n                    </gml:Point>\n                  </eop:centerOf>\n                </eop:Footprint>\n              </om:FeatureOfInterest>\n              <eop:metaDataProperty>\n                <eop:EarthObservationMetaData>\n                  <eop:identifier>nurc__watertemp</eop:identifier>\n                  <eop:acquisitionType>NOMINAL</eop:acquisitionType>\n                  <eop:status>ARCHIVED</eop:status>\n                </eop:EarthObservationMetaData>\n              </eop:metaDataProperty>\n            </eop:EarthObservation>\n          </wcseo:EOMetadata>\n        </gmlcov:Extension>\n      </gmlcov:metadata>\n      <gml:domainSet>\n        <gml:RectifiedGrid gml:id=\"grid00__nurc__watertemp_granule_watertemp.2\" dimension=\"2\">\n          <gml:limits>\n            <gml:GridEnvelope>\n              <gml:low>0 0</gml:low>\n              <gml:high>24 24</gml:high>\n            </gml:GridEnvelope>\n          </gml:limits>\n          <gml:axisLabels>i j</gml:axisLabels>\n          <gml:origin>\n            <gml:Point gml:id=\"p00_nurc__watertemp_granule_watertemp.2\" srsName=\"http://www.opengis.net/def/crs/EPSG/0/4326\">\n              <gml:pos>44.47816290174212 0.5243314177302991</gml:pos>\n            </gml:Point>\n          </gml:origin>\n          <gml:offsetVector srsName=\"http://www.opengis.net/def/crs/EPSG/0/4326\">0.0 0.5742214584350587</gml:offsetVector>\n          <gml:offsetVector srsName=\"http://www.opengis.net/def/crs/EPSG/0/4326\">-0.159840087890625 0.0</gml:offsetVector>\n        </gml:RectifiedGrid>\n      </gml:domainSet>\n      <gmlcov:rangeType>\n        <swe:DataRecord>\n          <swe:field name=\"GRAY_INDEX\">\n            <swe:Quantity>\n              <swe:description>GRAY_INDEX</swe:description>\n              <swe:uom code=\"W.m-2.Sr-1\"/>\n              <swe:constraint>\n                <swe:AllowedValues>\n                  <swe:interval>-1.7976931348623157E308 1.7976931348623157E308</swe:interval>\n                </swe:AllowedValues>\n              </swe:constraint>\n            </swe:Quantity>\n          </swe:field>\n        </swe:DataRecord>\n      </gmlcov:rangeType>\n      <wcs:ServiceParameters>\n        <wcs:CoverageSubtype>RectifiedGridCoverage</wcs:CoverageSubtype>\n        <wcs:nativeFormat>image/tiff</wcs:nativeFormat>\n      </wcs:ServiceParameters>\n    </wcs:CoverageDescription>\n    <wcs:CoverageDescription gml:id=\"nurc__watertemp_granule_watertemp.3\">\n      <gml:boundedBy>\n        <gml:EnvelopeWithTimePeriod srsName=\"http://www.opengis.net/def/crs/EPSG/0/4326\" axisLabels=\"Lat Long time\" uomLabels=\"Deg Deg s\" srsDimension=\"2\">\n          <gml:lowerCorner>40.562080748421806 0.23722068851276978</gml:lowerCorner>\n          <gml:upperCorner>44.55808294568743 14.592757149389236</gml:upperCorner>\n          <gml:beginPosition>2008-10-31T00:00:00.000Z</gml:beginPosition>\n          <gml:endPosition>2008-10-31T00:00:00.000Z</gml:endPosition>\n        </gml:EnvelopeWithTimePeriod>\n      </gml:boundedBy>\n      <wcs:CoverageId>nurc__watertemp_granule_watertemp.3</wcs:CoverageId>\n      <gml:coverageFunction>\n        <gml:GridFunction>\n          <gml:sequenceRule axisOrder=\"+2 +1\">Linear</gml:sequenceRule>\n          <gml:startPoint>0 0</gml:startPoint>\n        </gml:GridFunction>\n      </gml:coverageFunction>\n      <gmlcov:metadata>\n        <gmlcov:Extension>\n          <wcsgs:TimeDomain default=\"2008-10-31T00:00:00.000Z\">\n            <gml:TimeInstant gml:id=\"nurc__watertemp_granule_watertemp.3_td_0\">\n              <gml:timePosition>2008-10-31T00:00:00.000Z</gml:timePosition>\n            </gml:TimeInstant>\n          </wcsgs:TimeDomain>\n          <wcseo:EOMetadata>\n            <eop:EarthObservation gml:id=\"nurc__watertemp_metadata\">\n              <om:phenomenonTime>\n                <gml:TimePeriod gml:id=\"nurc__watertemp_tp\">\n                  <gml:beginPosition>2008-10-31T00:00:00.000Z</gml:beginPosition>\n                  <gml:endPosition>2008-10-31T00:00:00.000Z</gml:endPosition>\n                </gml:TimePeriod>\n              </om:phenomenonTime>\n              <om:resultTime>\n                <gml:TimeInstant gml:id=\"nurc__watertemp_rt\">\n                  <gml:timePosition>2008-10-31T00:00:00.000Z</gml:timePosition>\n                </gml:TimeInstant>\n              </om:resultTime>\n              <om:procedure/>\n              <om:observedProperty/>\n              <om:FeatureOfInterest>\n                <eop:Footprint gml:id=\"nurc__watertemp_fp\">\n                  <eop:multiExtentOf>\n                    <gml:MultiSurface gml:id=\"nurc__watertemp_ms\" srsName=\"http://www.opengis.net/def/crs/EPSG/0/4326\">\n                      <gml:surfaceMembers>\n                        <gml:Polygon gml:id=\"nurc__watertemp_msp\">\n                          <gml:exterior>\n                            <gml:LinearRing>\n                              <gml:posList>40.562080748421806 0.23722068851276978 40.562080748421806 14.592757149389236 44.55808294568743 14.592757149389236 44.55808294568743 0.23722068851276978 40.562080748421806 0.23722068851276978</gml:posList>\n                            </gml:LinearRing>\n                          </gml:exterior>\n                        </gml:Polygon>\n                      </gml:surfaceMembers>\n                    </gml:MultiSurface>\n                  </eop:multiExtentOf>\n                  <eop:centerOf>\n                    <gml:Point gml:id=\"nurc__watertemp_co\" srsName=\"http://www.opengis.net/def/crs/EPSG/0/4326\">\n                      <gml:pos>42.56008184705462 7.4149889189510025</gml:pos>\n                    </gml:Point>\n                  </eop:centerOf>\n                </eop:Footprint>\n              </om:FeatureOfInterest>\n              <eop:metaDataProperty>\n                <eop:EarthObservationMetaData>\n                  <eop:identifier>nurc__watertemp</eop:identifier>\n                  <eop:acquisitionType>NOMINAL</eop:acquisitionType>\n                  <eop:status>ARCHIVED</eop:status>\n                </eop:EarthObservationMetaData>\n              </eop:metaDataProperty>\n            </eop:EarthObservation>\n          </wcseo:EOMetadata>\n        </gmlcov:Extension>\n      </gmlcov:metadata>\n      <gml:domainSet>\n        <gml:RectifiedGrid gml:id=\"grid00__nurc__watertemp_granule_watertemp.3\" dimension=\"2\">\n          <gml:limits>\n            <gml:GridEnvelope>\n              <gml:low>0 0</gml:low>\n              <gml:high>24 24</gml:high>\n            </gml:GridEnvelope>\n          </gml:limits>\n          <gml:axisLabels>i j</gml:axisLabels>\n          <gml:origin>\n            <gml:Point gml:id=\"p00_nurc__watertemp_granule_watertemp.3\" srsName=\"http://www.opengis.net/def/crs/EPSG/0/4326\">\n              <gml:pos>44.47816290174212 0.5243314177302991</gml:pos>\n            </gml:Point>\n          </gml:origin>\n          <gml:offsetVector srsName=\"http://www.opengis.net/def/crs/EPSG/0/4326\">0.0 0.5742214584350587</gml:offsetVector>\n          <gml:offsetVector srsName=\"http://www.opengis.net/def/crs/EPSG/0/4326\">-0.159840087890625 0.0</gml:offsetVector>\n        </gml:RectifiedGrid>\n      </gml:domainSet>\n      <gmlcov:rangeType>\n        <swe:DataRecord>\n          <swe:field name=\"GRAY_INDEX\">\n            <swe:Quantity>\n              <swe:description>GRAY_INDEX</swe:description>\n              <swe:uom code=\"W.m-2.Sr-1\"/>\n              <swe:constraint>\n                <swe:AllowedValues>\n                  <swe:interval>-1.7976931348623157E308 1.7976931348623157E308</swe:interval>\n                </swe:AllowedValues>\n              </swe:constraint>\n            </swe:Quantity>\n          </swe:field>\n        </swe:DataRecord>\n      </gmlcov:rangeType>\n      <wcs:ServiceParameters>\n        <wcs:CoverageSubtype>RectifiedGridCoverage</wcs:CoverageSubtype>\n        <wcs:nativeFormat>image/tiff</wcs:nativeFormat>\n      </wcs:ServiceParameters>\n    </wcs:CoverageDescription>\n    <wcs:CoverageDescription gml:id=\"nurc__watertemp_granule_watertemp.4\">\n      <gml:boundedBy>\n        <gml:EnvelopeWithTimePeriod srsName=\"http://www.opengis.net/def/crs/EPSG/0/4326\" axisLabels=\"Lat Long time\" uomLabels=\"Deg Deg s\" srsDimension=\"2\">\n          <gml:lowerCorner>40.562080748421806 0.23722068851276978</gml:lowerCorner>\n          <gml:upperCorner>44.55808294568743 14.592757149389236</gml:upperCorner>\n          <gml:beginPosition>2008-10-31T00:00:00.000Z</gml:beginPosition>\n          <gml:endPosition>2008-10-31T00:00:00.000Z</gml:endPosition>\n        </gml:EnvelopeWithTimePeriod>\n      </gml:boundedBy>\n      <wcs:CoverageId>nurc__watertemp_granule_watertemp.4</wcs:CoverageId>\n      <gml:coverageFunction>\n        <gml:GridFunction>\n          <gml:sequenceRule axisOrder=\"+2 +1\">Linear</gml:sequenceRule>\n          <gml:startPoint>0 0</gml:startPoint>\n        </gml:GridFunction>\n      </gml:coverageFunction>\n      <gmlcov:metadata>\n        <gmlcov:Extension>\n          <wcsgs:TimeDomain default=\"2008-10-31T00:00:00.000Z\">\n            <gml:TimeInstant gml:id=\"nurc__watertemp_granule_watertemp.4_td_0\">\n              <gml:timePosition>2008-10-31T00:00:00.000Z</gml:timePosition>\n            </gml:TimeInstant>\n          </wcsgs:TimeDomain>\n          <wcseo:EOMetadata>\n            <eop:EarthObservation gml:id=\"nurc__watertemp_metadata\">\n              <om:phenomenonTime>\n                <gml:TimePeriod gml:id=\"nurc__watertemp_tp\">\n                  <gml:beginPosition>2008-10-31T00:00:00.000Z</gml:beginPosition>\n                  <gml:endPosition>2008-10-31T00:00:00.000Z</gml:endPosition>\n                </gml:TimePeriod>\n              </om:phenomenonTime>\n              <om:resultTime>\n                <gml:TimeInstant gml:id=\"nurc__watertemp_rt\">\n                  <gml:timePosition>2008-10-31T00:00:00.000Z</gml:timePosition>\n                </gml:TimeInstant>\n              </om:resultTime>\n              <om:procedure/>\n              <om:observedProperty/>\n              <om:FeatureOfInterest>\n                <eop:Footprint gml:id=\"nurc__watertemp_fp\">\n                  <eop:multiExtentOf>\n                    <gml:MultiSurface gml:id=\"nurc__watertemp_ms\" srsName=\"http://www.opengis.net/def/crs/EPSG/0/4326\">\n                      <gml:surfaceMembers>\n                        <gml:Polygon gml:id=\"nurc__watertemp_msp\">\n                          <gml:exterior>\n                            <gml:LinearRing>\n                              <gml:posList>40.562080748421806 0.23722068851276978 40.562080748421806 14.592757149389236 44.55808294568743 14.592757149389236 44.55808294568743 0.23722068851276978 40.562080748421806 0.23722068851276978</gml:posList>\n                            </gml:LinearRing>\n                          </gml:exterior>\n                        </gml:Polygon>\n                      </gml:surfaceMembers>\n                    </gml:MultiSurface>\n                  </eop:multiExtentOf>\n                  <eop:centerOf>\n                    <gml:Point gml:id=\"nurc__watertemp_co\" srsName=\"http://www.opengis.net/def/crs/EPSG/0/4326\">\n                      <gml:pos>42.56008184705462 7.4149889189510025</gml:pos>\n                    </gml:Point>\n                  </eop:centerOf>\n                </eop:Footprint>\n              </om:FeatureOfInterest>\n              <eop:metaDataProperty>\n                <eop:EarthObservationMetaData>\n                  <eop:identifier>nurc__watertemp</eop:identifier>\n                  <eop:acquisitionType>NOMINAL</eop:acquisitionType>\n                  <eop:status>ARCHIVED</eop:status>\n                </eop:EarthObservationMetaData>\n              </eop:metaDataProperty>\n            </eop:EarthObservation>\n          </wcseo:EOMetadata>\n        </gmlcov:Extension>\n      </gmlcov:metadata>\n      <gml:domainSet>\n        <gml:RectifiedGrid gml:id=\"grid00__nurc__watertemp_granule_watertemp.4\" dimension=\"2\">\n          <gml:limits>\n            <gml:GridEnvelope>\n              <gml:low>0 0</gml:low>\n              <gml:high>24 24</gml:high>\n            </gml:GridEnvelope>\n          </gml:limits>\n          <gml:axisLabels>i j</gml:axisLabels>\n          <gml:origin>\n            <gml:Point gml:id=\"p00_nurc__watertemp_granule_watertemp.4\" srsName=\"http://www.opengis.net/def/crs/EPSG/0/4326\">\n              <gml:pos>44.47816290174212 0.5243314177302991</gml:pos>\n            </gml:Point>\n          </gml:origin>\n          <gml:offsetVector srsName=\"http://www.opengis.net/def/crs/EPSG/0/4326\">0.0 0.5742214584350587</gml:offsetVector>\n          <gml:offsetVector srsName=\"http://www.opengis.net/def/crs/EPSG/0/4326\">-0.159840087890625 0.0</gml:offsetVector>\n        </gml:RectifiedGrid>\n      </gml:domainSet>\n      <gmlcov:rangeType>\n        <swe:DataRecord>\n          <swe:field name=\"GRAY_INDEX\">\n            <swe:Quantity>\n              <swe:description>GRAY_INDEX</swe:description>\n              <swe:uom code=\"W.m-2.Sr-1\"/>\n              <swe:constraint>\n                <swe:AllowedValues>\n                  <swe:interval>-1.7976931348623157E308 1.7976931348623157E308</swe:interval>\n                </swe:AllowedValues>\n              </swe:constraint>\n            </swe:Quantity>\n          </swe:field>\n        </swe:DataRecord>\n      </gmlcov:rangeType>\n      <wcs:ServiceParameters>\n        <wcs:CoverageSubtype>RectifiedGridCoverage</wcs:CoverageSubtype>\n        <wcs:nativeFormat>image/tiff</wcs:nativeFormat>\n      </wcs:ServiceParameters>\n    </wcs:CoverageDescription>\n  </wcs:CoverageDescriptions>\n  <wcseo:DatasetSeriesDescriptions>\n    <wcseo:DatasetSeriesDescription gml:id=\"nurc__watertemp_dss\">\n      <gml:boundedBy>\n        <gml:Envelope srsName=\"http://www.opengis.net/def/crs/EPSG/0/4326\" axisLabels=\"Lat Long\" uomLabels=\"Deg Deg\" srsDimension=\"2\">\n          <gml:lowerCorner>40.562080748421806 0.23722068851276978</gml:lowerCorner>\n          <gml:upperCorner>44.55808294568743 14.592757149389236</gml:upperCorner>\n        </gml:Envelope>\n      </gml:boundedBy>\n      <wcseo:DatasetSeriesId>nurc__watertemp_dss</wcseo:DatasetSeriesId>\n      <gml:TimePeriod gml:id=\"nurc__watertemp_dss_timeperiod\">\n        <gml:beginPosition>2008-10-31T00:00:00.000Z</gml:beginPosition>\n        <gml:endPosition>2008-11-01T00:00:00.000Z</gml:endPosition>\n      </gml:TimePeriod>\n    </wcseo:DatasetSeriesDescription>\n  </wcseo:DatasetSeriesDescriptions>\n</wcseo:EOCoverageSetDescription>\n

                                                                              Any of the inner coverages can be then retrieved via a standard GetCoverage, even if it's not directly part of the capabilities document, for example, to retrieve the first granule in the watertemp layer the request would be:

                                                                              http://localhost:8080/geoserver/ows?service=WCS&version=2.0.1&request=GetCoverage&coverageId=nurc__watertemp_granule_watertemp.1\n
                                                                              "},{"location":"extensions/wmts-multidimensional/","title":"WMTS Multidimensional","text":"

                                                                              This module implements the WMTS multidimensional domain discovery extensions as proposed in this document. It is highly recommended to read the document linked above for a better understanding of the implemented multidimensional domain discovery extensions.

                                                                              • Installing the WMTS multidimensional extension
                                                                              • WMTS Multidimensional usage
                                                                              • WMTS Multidimensional performance
                                                                              "},{"location":"extensions/wmts-multidimensional/install/","title":"Installing the WMTS multidimensional extension","text":"

                                                                              The WMS multidimensional extension is listed among the other extension downloads on the GeoServer download page.

                                                                              The installation process is similar to other GeoServer extensions:

                                                                              1. Download the wmts-multi-dimensional

                                                                                Verify that the version number in the filename corresponds to the version of GeoServer you are running (for example 2.24.2 above).

                                                                              2. Extract the contents of the archive into the WEB-INF/lib directory in GeoServer. Make sure you do not create any sub-directories during the extraction process.

                                                                              3. Restart GeoServer.

                                                                              If installation was successful, the WTMS capabilities document will contain the extra requests provided by the module, e.g.:

                                                                              <ows:Operation name=\"DescribeDomains\">\n  <ows:DCP>\n    <ows:HTTP>\n      <ows:Get xlink:href=\"http://localhost:8080/geoserver/gwc/service/wmts?\">\n        <ows:Constraint name=\"GetEncoding\">\n          <ows:AllowedValues>\n            <ows:Value>KVP</ows:Value>\n          </ows:AllowedValues>\n        </ows:Constraint>\n      </ows:Get>\n    </ows:HTTP>\n  </ows:DCP>\n</ows:Operation>\n<ows:Operation name=\"GetDomainValues\">\n  <ows:DCP>\n    <ows:HTTP>\n      <ows:Get xlink:href=\"http://localhost:8080/geoserver/gwc/service/wmts?\">\n        <ows:Constraint name=\"GetEncoding\">\n          <ows:AllowedValues>\n            <ows:Value>KVP</ows:Value>\n          </ows:AllowedValues>\n        </ows:Constraint>\n      </ows:Get>\n    </ows:HTTP>\n  </ows:DCP>\n</ows:Operation>\n

                                                                              A simple DescribeDomains request can be used to test if the module was correctly installed, the request can be made against any layer known by the WMTS service. For example, using the demo layer tiger:poly_landmarks shipped with GeoServer:

                                                                              http://localhost:8080/geoserver/gwc/service/wmts?REQUEST=DescribeDomains&Version=1.0.0&Layer=tiger:poly_landmarks&TileMatrixSet=EPSG:4326\n

                                                                              The result should be similar to the following, this layer doesn't have any domains:

                                                                              <?xml version=\"1.0\" encoding=\"UTF-8\"?><Domains xmlns=\"http://demo.geo-solutions.it/share/wmts-multidim/wmts_multi_dimensional.xsd\" xmlns:ows=\"http://www.opengis.net/ows/1.1\">\n  <SpaceDomain>\n    <BoundingBox CRS=\"EPSG:4326\" minx=\"0.0\" miny=\"0.0\" maxx=\"-1.0\" maxy=\"-1.0\"/>\n  </SpaceDomain>\n</Domains>\n

                                                                              If the module is not correctly installed the result will be an exception saying that this operation is not available:

                                                                              <ExceptionReport version=\"1.1.0\" xmlns=\"http://www.opengis.net/ows/1.1\"\n  xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\"\n  xsi:schemaLocation=\"http://www.opengis.net/ows/1.1 http://geowebcache.org/schema/ows/1.1.0/owsExceptionReport.xsd\">\n  <Exception exceptionCode=\"OperationNotSupported\" locator=\"request\">\n    <ExceptionText>describedomains is not implemented</ExceptionText>\n  </Exception>\n</ExceptionReport>\n
                                                                              "},{"location":"extensions/wmts-multidimensional/performance/","title":"WMTS Multidimensional performance","text":"

                                                                              The multi-dimensional extension is designed to get quick summary responses, either when providing the full dimensions descriptions, or drilling into a particular sub-context, e.g., finding the times available in a particular bounding box.

                                                                              The extension is often used to drive time sliders and visual tools to quickly drill down into a large multi-dimensional data set: as such, it's important that response times keep up with the user interactive usage.

                                                                              For it to perform well, the typical configurations for relational databases are, in order of increasing complexity:

                                                                              • Indexing all dimensions involved (geometry, time, elevation, and so on).
                                                                              • Clustering the table on the dimensions which are the typical main UI driving factor (e.g. PostgreSQL one-off clustering, Oracle index organized tables).
                                                                              • Partition the table based on the same dimension (e.g., PostgreSQL table partitioning).
                                                                              • Create a summary table and use it for queries instead of the original one. The next section describes this approach.
                                                                              "},{"location":"extensions/wmts-multidimensional/performance/#sidecar-summary-tables-for-vector-data","title":"Sidecar summary tables for vector data","text":"

                                                                              The multidimensional module can be configured to use a sidecar summary table, that will be queried in place of the original table, for any domain extraction purpose:

                                                                              Setting up a sidecar table.

                                                                              Conditions for the sidecar table to work:

                                                                              • Must contain all the same dimension columns as in the primary table, with same name and type.
                                                                              • Must have a significantly smaller number of records (meaning, the primary table has lots of duplicate dimension values).
                                                                              • May have reduced resolution in some dimension, if it's possible to accept reduced accuracy in the domain reports.

                                                                              Querying the sidecar table will bypass all of the main table configurations and security, including:

                                                                              • Property mapping (renaming, type modification, synthetic properties based on expression).
                                                                              • CQL filtering defined in the layer configuration.
                                                                              • Any security restriction (the layer must be public).

                                                                              In summary, the sidecar table is useful for vector layers that are:

                                                                              • Public.
                                                                              • Very large, with significant repetition of dimension values.
                                                                              • Read from the original table without any filtering or mapping.

                                                                              While the documentation above refers to relational databases, it's also possible to use sidecar layers that come from the same data store. For example, given a directory of shapefiles, it would be possible to create a summary shapefile with a summary of a larger shapefile, and use it as the query target in its place.

                                                                              "},{"location":"extensions/wmts-multidimensional/usage/","title":"WMTS Multidimensional usage","text":"

                                                                              All described operations including is optional parameters and other extensions were implemented, only the REST interfaces for the domain discovery operations were not implemented.

                                                                              The GetFeature operation only supports the profile GML 3.1 as feature info format (\"application/gml+xml; version=3.1\") and the GetHistogram operation only supports text/xml as output format.

                                                                              This module support well defined dimensions like elevation and time, but also custom dimensions.

                                                                              "},{"location":"extensions/wmts-multidimensional/usage/#getcapabilities","title":"GetCapabilities","text":"

                                                                              The default behavior of WMTS is to list in the capabilities document all the values available in a certain dimension, something like this:

                                                                              <Dimension>\n  <ows:Identifier>elevation</ows:Identifier>\n  <Default>0.0</Default>\n  <Value>0.0</Value>\n  <Value>200.0</Value>\n  <Value>400.0</Value>\n  <Value>600.0</Value>\n  <Value>800.0</Value>\n  <Value>1000.0</Value>\n  <Value>1200.0</Value>\n  <Value>1400.0</Value>\n  <Value>1600.0</Value>\n  <Value>1800.0</Value>\n  <Value>2000.0</Value>\n  <Value>3000.0</Value>\n  <Value>4000.0</Value>\n  <Value>5000.0</Value>\n  <Value>6000.0</Value>\n  <Value>7000.0</Value>\n  <Value>8000.0</Value>\n  <Value>9000.0</Value>\n</Dimension>\n

                                                                              This module will instead take into account the presentation mode selected by the user:

                                                                              Configuration of a layer dimensions.

                                                                              With the presentation mode select to Continuous interval or Resolution and interval we will instead see something like this:

                                                                              <Dimension>\n  <ows:Identifier>elevation</ows:Identifier>\n  <Default>0.0</Default>\n  <Value>0.0--9000.0</Value>\n</Dimension>\n

                                                                              Descriptions for the new introduced operations and associated formats will also be added to the capabilities document.

                                                                              "},{"location":"extensions/wmts-multidimensional/usage/#operations","title":"Operations","text":"

                                                                              This module adds three new operations to the WMTS service that are described in detail in this document:

                                                                              Operation Description DescribeDomains Describes all the dimension domains in a compact document, along with the restricted bounding box of the two dimensional space intercepted by the request. GetDomainValues Allows to page through domain values (supplements DescribeDomains in case the domain has too many values, and the client still wants to get all of them, one page at a time) GetHistogram Given a scattered domain description and an interval, this operation divides the interval in regular buckets, and provides an item count for each bucket. GetFeature Enumerate the actual dimension possible values combinations, returns a list of features along with dimension values using the same formats as the feature info operation (\"application/gml+xml; version=3.1\").

                                                                              Note that currently there is no restful implementations of this operations.

                                                                              "},{"location":"extensions/wmts-multidimensional/usage/#describedomains","title":"DescribeDomains","text":"

                                                                              This operation is useful to understand which domains are available in our layer dimensions and how they relate to each other. The parameters available for this operation are:

                                                                              Name Mandatory Description Service=WMTS Yes Service type identifier Request=DescribeDomains Yes Operation name Version=1.0.0 Yes Standard and schema version for this operation Layer Yes Layer identifier TileMatrixSet Yes Tile matrix set identifier bbox=minx,miny,maxx,maxy No Bounding box corners (lower left, upper right) in CRS units DimensionIdentifier No At most one per dimension, a range described as min/max, restricting the domain of this dimension Domains No A comma separated list of domain names to be returned, in case only a subset is required. The space domain is identified by \"bbox\". ExpandLimit No A numerical value, greater or equal to zero. If the number of unique domain values is below ExpandLimit then the domain with be represented in full, as a comma separated list of values, otherwise in compact form, as start--end. The server assumes a built-in limit of 200 in case not specified, and allows client to specify a value up to 10000, values can be tuned via the user interface, in the WMTS panel (server defaults) and on a layer by layer basis.

                                                                              Configuration domain expansion limits.

                                                                              The bbox parameter allows the client to restrict the DescribeDomains operation to a certain spatial area, by default the layer extent will be used.

                                                                              The DimensionIdentifier parameter can be used to restrict the domain values of a certain dimension, this is useful to answer questions like which elevations values are available in a specific day.

                                                                              A simple DescribeDomains request will look like this:

                                                                              http://localhost:8080/geoserver/gwc/service/wmts?REQUEST=DescribeDomains&Version=1.0.0&Layer=some_layer&TileMatrixSet=EPSG:4326\n

                                                                              and the result will be similar to this:

                                                                              <Domains xmlns=\"http://demo.geo-solutions.it/share/wmts-multidim/wmts_multi_dimensional.xsd\" xmlns:ows=\"http://www.opengis.net/ows/1.1\">\n  <SpaceDomain>\n    <BoundingBox CRS=\"EPSG:4326\" \n     maxx=\"179.875\" maxy=\"89.9375\" minx=\"-180.125\" miny=\"-90.125\"/>\n  </SpaceDomain>\n  <DimensionDomain>\n    <ows:Identifier>elevation</ows:Identifier>\n    <Domain>0.0,200.0,400.0,600.0,800.0,1000.0</Domain>\n    <Size>6</Size>\n  </DimensionDomain>\n  <DimensionDomain>\n    <ows:Identifier>REFERENCE_TIME</ows:Identifier>\n    <Domain>2016-02-23T00:00:00.000Z,2016-02-24T00:00:00.000Z</Domain>\n    <Size>2</Size>\n  </DimensionDomain>\n  <DimensionDomain>\n    <ows:Identifier>time</ows:Identifier>\n    <Domain>2016-02-23T03:00:00.000Z,2016-02-23T06:00:00.000Z</Domain>\n    <Size>2</Size>\n  </DimensionDomain>\n</Domains>\n

                                                                              Note that if an end attribute has been defined in the layer dimension configuration page, the result will show ranges in place of single values. The result in this case will look like the following:

                                                                              <Domains xmlns=\"http://demo.geo-solutions.it/share/wmts-multidim/wmts_multi_dimensional.xsd\" xmlns:ows=\"http://www.opengis.net/ows/1.1\">\n  <SpaceDomain>\n    <BoundingBox CRS=\"EPSG:4326\" \n     maxx=\"179.875\" maxy=\"89.9375\" minx=\"-180.125\" miny=\"-90.125\"/>\n  </SpaceDomain>\n  <DimensionDomain>\n    <ows:Identifier>elevation</ows:Identifier>\n    <Domain>0.0/50.0,200.0/300.0,400.0/500.0</Domain>\n    <Size>6</Size>\n  </DimensionDomain>\n  <DimensionDomain>\n    <ows:Identifier>REFERENCE_TIME</ows:Identifier>\n    <Domain>2016-02-23T00:00:00.000Z/2016-02-23T23:00:00.000Z,2016-02-24T00:00:00.000Z/2016-02-24T12:00:00.000Z</Domain>\n    <Size>2</Size>\n  </DimensionDomain>\n  <DimensionDomain>\n    <ows:Identifier>time</ows:Identifier>\n    <Domain>2016-02-23T03:00:00.000Z/2016-02-23T06:00:00.000Z,2016-02-23T06:00:00.000Z/2016-02-23T12:00:00.000Z</Domain>\n    <Size>2</Size>\n  </DimensionDomain>\n</Domains>\n

                                                                              From the information above we can see that we have three dimensions time, elevation and REFERENCE_TIME and the respective domains values.

                                                                              Now let's see how elevations relate to time dimension by asking which elevations under 500.0 meters are available at time 2016-02-23T03:00:00.000Z:

                                                                              http://localhost:8080/geoserver/gwc/service/wmts?REQUEST=DescribeDomains&Version=1.0.0&Layer=some_layer&TileMatrixSet=EPSG:4326&elevation=0/500&time=2016-02-23T03:00:00.000Z\n

                                                                              the result will be similar to this:

                                                                              <Domains xmlns=\"http://demo.geo-solutions.it/share/wmts-multidim/wmts_multi_dimensional.xsd\" xmlns:ows=\"http://www.opengis.net/ows/1.1\">\n  <SpaceDomain>\n    <BoundingBox CRS=\"EPSG:4326\" \n     maxx=\"179.875\" maxy=\"89.9375\" minx=\"-180.125\" miny=\"-90.125\"/>\n  </SpaceDomain>\n  <DimensionDomain>\n    <ows:Identifier>elevation</ows:Identifier>\n    <Domain>200.0</Domain>\n    <Size>1</Size>\n  </DimensionDomain>\n  <DimensionDomain>\n    <ows:Identifier>REFERENCE_TIME</ows:Identifier>\n    <Domain>2016-02-23T00:00:00.000Z</Domain>\n    <Size>1</Size>\n  </DimensionDomain>\n  <DimensionDomain>\n    <ows:Identifier>time</ows:Identifier>\n    <Domain>2016-02-23T03:00:00.000Z</Domain>\n    <Size>1</Size>\n  </DimensionDomain>\n</Domains>\n

                                                                              So for time 2016-02-23T03:00:00.000Z there is only values measured at 200.0 meters.

                                                                              In case only the space domain is of interest, the following request will do:

                                                                              http://localhost:8080/geoserver/gwc/service/wmts?REQUEST=DescribeDomains&Version=1.0.0&Layer=some_layer&TileMatrixSet=EPSG:4326&elevation=0/500&time=2016-02-23T03:00:00.000Z&domains=bbox\n

                                                                              and the result will be similar to this:

                                                                              <Domains xmlns=\"http://demo.geo-solutions.it/share/wmts-multidim/wmts_multi_dimensional.xsd\" xmlns:ows=\"http://www.opengis.net/ows/1.1\">\n  <SpaceDomain>\n    <BoundingBox CRS=\"EPSG:4326\" \n     maxx=\"179.875\" maxy=\"89.9375\" minx=\"-180.125\" miny=\"-90.125\"/>\n  </SpaceDomain>\n</Domains>\n
                                                                              "},{"location":"extensions/wmts-multidimensional/usage/#getdomainvalues","title":"GetDomainValues","text":"

                                                                              This operation is useful to page through the values of a given domain, in case the \"multidimensional\" area of interest is too large for DescribeDomain to return them in a single shot.

                                                                              Name Mandatory Description Service=WMTS Yes Service type identifier Request=GetDomainValues Yes Operation name Version=1.0.0 Yes Standard and schema version for this operation Layer Yes Layer identifier bbox=minx,miny,maxx,maxy No Bounding box corners (lower left, upper right) in CRS units DimensionIdentifier No At most one per dimension, a range described as min/max, restricting the domain of this dimension Domain Yes Name of the domain whose values will be returned (one cannot use \"bbox\", only single value dimensions can be enumerated by GetDomainValues, e.g., time, elevation). FromValue No Sets the beginning of domain enumeration, for paging purposes. It's not included in the result FromEnd No If equals to true specifies that the beginning of domain enumeration, set by the FromValue, should be applied to the end attribute. When set to true results will be sorted by end attribute. Sort No Can be \"asc\" or \"desc\", determines if the enumeration is from low to high, or from high to low Limit No Maximum number of values returned by this call. The server assumes a built-in limit of 1000 in case not specified, and allows client to specify a value up to 10000.

                                                                              For example, let's say a \"elevation\" domain has values 1,2,3 and 5, and that we are paging through it by pages of 2 elements. The client will start without providing a \"fromValue\", and will then continue using the last value of the previous page as a reference:

                                                                              http://localhost:8080/geoserver/gwc/service/wmts?request=GetDomainValues&Version=1.0.0&Layer=sampleLayer&domain=elevation&limit=2\n
                                                                              <DomainValues xmlns=\"http://demo.geo-solutions.it/share/wmts-multidim/wmts_multi_dimensional.xsd\" xmlns:ows=\"http://www.opengis.net/ows/1.1\">\n  <ows:Identifier>elevation</ows:Identifier>\n  <Limit>2</Limit>\n  <Sort>asc</Sort>\n  <Domain>1.0,2.0</Domain>\n  <Size>2</Size>\n</DomainValues>\n
                                                                              http://localhost:8080/geoserver/gwc/service/wmts?request=GetDomainValues&Version=1.0.0&Layer=sampleLayer&domain=elevation&limit=2&fromValue=2\n
                                                                              <DomainValues xmlns=\"http://demo.geo-solutions.it/share/wmts-multidim/wmts_multi_dimensional.xsd\" xmlns:ows=\"http://www.opengis.net/ows/1.1\">\n  <ows:Identifier>elevation</ows:Identifier>\n  <Limit>2</Limit>\n  <Sort>asc</Sort>\n  <FromValue>2.0</FromValue>\n  <Domain>3.0,5.0</Domain>\n  <Size>2</Size>\n</DomainValues>\n
                                                                              http://localhost:8080/geoserver/gwc/service/wmts?request=GetDomainValues&Version=1.0.0&Layer=sampleLayer&domain=elevation&limit=2&fromValue=5\n
                                                                              <DomainValues xmlns=\"http://demo.geo-solutions.it/share/wmts-multidim/wmts_multi_dimensional.xsd\" xmlns:ows=\"http://www.opengis.net/ows/1.1\">\n  <ows:Identifier>elevation</ows:Identifier>\n  <Limit>2</Limit>\n  <Sort>asc</Sort>\n  <FromValue>5.0</FromValue>\n  <Domain></Domain>\n  <Size>0</Size>\n</DomainValues>\n

                                                                              For elevations it might not be uncommon to iterate backwards, from the top-most elevation down to the lowest value. The interaction between client and server might then look as follows:

                                                                              http://localhost:8080/geoserver/gwc/service/wmts?request=GetDomainValues&Version=1.0.0&Layer=sampleLayer&domain=elevation&limit=2&sort=desc\n
                                                                              <DomainValues xmlns=\"http://demo.geo-solutions.it/share/wmts-multidim/wmts_multi_dimensional.xsd\" xmlns:ows=\"http://www.opengis.net/ows/1.1\">\n  <ows:Identifier>elevation</ows:Identifier>\n  <Limit>2</Limit>\n  <Sort>asc</Sort>\n  <Domain>5.0,3.0</Domain>\n  <Size>2</Size>\n</DomainValues>\n
                                                                              http://localhost:8080/geoserver/gwc/service/wmts?request=GetDomainValues&Version=1.0.0&Layer=sampleLayer&domain=elevation&limit=2&fromValue=3&sort=desc\n
                                                                              <DomainValues xmlns=\"http://demo.geo-solutions.it/share/wmts-multidim/wmts_multi_dimensional.xsd\" xmlns:ows=\"http://www.opengis.net/ows/1.1\">\n  <ows:Identifier>elevation</ows:Identifier>\n  <Limit>2</Limit>\n  <Sort>asc</Sort>\n  <FromValue>3.0</FromValue>\n  <Domain>2.0,1.0</Domain>\n  <Size>2</Size>\n</DomainValues>\n
                                                                              http://localhost:8080/geoserver/gwc/service/wmts?request=GetDomainValues&Version=1.0.0&Layer=sampleLayer&domain=elevation&limit=2&fromValue=1&sort=desc\n
                                                                              <DomainValues xmlns=\"http://demo.geo-solutions.it/share/wmts-multidim/wmts_multi_dimensional.xsd\" xmlns:ows=\"http://www.opengis.net/ows/1.1\">\n  <ows:Identifier>elevation</ows:Identifier>\n  <Limit>2</Limit>\n  <Sort>asc</Sort>\n  <FromValue>1.0</FromValue>\n  <Domain></Domain>\n  <Size>0</Size>\n</DomainValues>\n

                                                                              Assume now that along with the values 1,2,3,5 we have end attribute values respectively equal to 5,3,4,6.

                                                                              The following request:

                                                                              http://localhost:8080/geoserver/gwc/service/wmts?request=GetDomainValues&Version=1.0.0&Layer=sampleLayer&domain=elevation&limit=2&fromValue=3.5&fromEnd=true\n

                                                                              will return

                                                                              <DomainValues xmlns=\"http://demo.geo-solutions.it/share/wmts-multidim/wmts_multi_dimensional.xsd\" xmlns:ows=\"http://www.opengis.net/ows/1.1\">\n  <ows:Identifier>elevation</ows:Identifier>\n  <Limit>2</Limit>\n  <Sort>asc</Sort>\n  <Domain>3.0/4.0,1.0/5.0,5.0/6.0</Domain>\n  <Size>2</Size>\n</DomainValues>\n

                                                                              The paging approach might seem odd for those used to using \"limit\" and \"offset\". The main reason it's done this way it's performance, paging through unique values via limit and offset means that the data source has to compute and collect the unique values that are not needed (the ones in previous pages) in order to find the ones in the current page. With large domains (typical of time series) this quickly becomes too slow for interactive usage, as one moves forward in the domain.

                                                                              By giving a starting point, the unneeded data points can be skipped via index and the distinct value computation can be performed only on the current page data, stopping it as soon as the desired number of results has been computed. With an index on the dimension being queries, this results in nearly constant response times, regardless of the page being requested.

                                                                              "},{"location":"extensions/wmts-multidimensional/usage/#gethistogram","title":"GetHistogram","text":"

                                                                              This operation can be used to provide information about the data distribution between the minimum and maximum values of a certain dimension.

                                                                              The parameters available for this operation are:

                                                                              Name Mandatory Description Service=WMTS Yes Service type identifier Request=GetHistogram Yes Operation name Version=1.0.0 Yes Standard and schema version for this operation Layer Yes Layer identifier TileMatrixSet Yes Tile matrix set identifier BBOX=minx,miny,maxx,maxy No Bounding box corners (lower left, upper right) in CRS units DimensionIdentifier No At most one per dimension, a range described as min/max, restricting the domain of this dimension Histogram Yes Name of the dimension for which the histogram will be computed Resolution No Suggested size of the histogram bucket. Cannot be provided for enumerated dimensions, will use the period syntax for time (e.g. PT1H), a number for numeric dimensions, or auto to leave the decision to the server Format No The desired output format, default is text/html.

                                                                              The parameters common to the DescribeDomains operation work as already described above. Currently only the text/xml output format is supported.

                                                                              The following example request the histogram for time dimension with a resolution of 8 hours restricting elevations between 500.0 and 1000.0 meters:

                                                                              http://localhost:8080/geoserver/gwc/service/wmts?REQUEST=GetHistogram&Version=1.0.0&Layer=some_layer&TileMatrixSet=EPSG:4326&histogram=time&resolution=PT8H&elevation=500.0/1000.0\n

                                                                              and the result will be similar to this:

                                                                              <Histogram xmlns=\"http://demo.geo-solutions.it/share/wmts-multidim/wmts_multi_dimensional.xsd\" xmlns:ows=\"http://www.opengis.net/ows/1.1\">\n  <ows:Identifier>time</ows:Identifier>\n  <Domain>2016-02-23T00:00:00.000Z/2016-02-25T00:00:00.000Z/PT8H</Domain>\n  <Values>240,0,240,0,0,240</Values>\n</Histogram>\n

                                                                              Looking at the result we can conclude that measurements between 500.0 and 1000.0 meters are typically done during the night.

                                                                              The bucket matching is setup so that each one contains its first value, but not its last value (which is contained in the next bucket instead). This is important to understand the results. Say we have a dataset with regular elevations, from 0 to 100 with a step of 10, and the request calls for elevations between 0 and 20. Then the results will look something like follows:

                                                                              <Histogram xmlns=\"http://demo.geo-solutions.it/share/wmts-multidim/wmts_multi_dimensional.xsd\" xmlns:ows=\"http://www.opengis.net/ows/1.1\">\n  <ows:Identifier>elevation</ows:Identifier>\n  <Domain>0/30/10</Domain>\n  <Values>5,3,8</Values>\n</Histogram>\n

                                                                              That is, there values catch the intervals [0,10[, [10, 20[, and [20, 30[ (to have a bucket for the images/features having elevation exactly matching 20). This will happen only if an extreme value if found, the same request filtering on elevations between 0 and 15 will return this instead:

                                                                              <Histogram xmlns=\"http://demo.geo-solutions.it/share/wmts-multidim/wmts_multi_dimensional.xsd\" xmlns:ows=\"http://www.opengis.net/ows/1.1\">\n  <ows:Identifier>elevation</ows:Identifier>\n  <Domain>0/20/10</Domain>\n  <Values>5,3</Values>\n</Histogram>\n

                                                                              Note that if an end attribute is specified the bucket matching will be applied on ranges rather than on single values. In this case, buckets are filled by the intersection of ranges' values with bucket limits and not by containment. This is done in order to avoid some range values falling outside every bucket, but as a side effect, the same range can match more than one bucket.

                                                                              "},{"location":"extensions/wmts-multidimensional/usage/#getfeature","title":"GetFeature","text":"

                                                                              This operation is capable to enumerate the actual possible values combinations. The output of this operation is similar to the output of the WFS 2.0 GetFeature operation which is a list of features along with dimension values using the same formats as the feature info operation. This output can be used to draw the features on a map for example.

                                                                              The parameters available for this operation are:

                                                                              Name Mandatory Description Service=WMTS Yes Service type identifier Request=GetFeature Yes Operation name Version=1.0.0 Yes Standard and schema version for this operation Layer Yes Layer identifier TileMatrixSet Yes Tile matrix set identifier BBOX=minx,miny,maxx,maxy No Bounding box corners (lower left, upper right) in CRS units DimensionIdentifier No At most one per dimension, a range described as min/max, restricting the domain of this dimension Format Yes The desired output format

                                                                              The parameters common to the DescribeDomains operation work as already described above. Currently only the application/gml+xml; version=3.1 output format is supported.

                                                                              Using the same restrictions parameters we used for the second request used as an example for the DescribeDomains operation a GetFeature request will look like this:

                                                                              http://localhost:8080/geoserver/gwc/service/wmts?REQUEST=GetFeature&Version=1.0.0&Layer=some_layer&TileMatrixSet=EPSG:4326&elevation=0/500&time=2016-02-23T03:00:00.000Z\n

                                                                              and the result will be similar to this:

                                                                              <?xml version=\"1.0\" encoding=\"UTF-8\"?><wmts:FeatureCollection xmlns:xs=\"http://www.w3.org/2001/XMLSchema\" xmlns:gml=\"http://www.opengis.net/gml\" xmlns:wmts=\"http://www.opengis.net/wmts/1.0\">\n  <wmts:feature gml:id=\"FID.1681\">\n    <wmts:footprint>\n      <gml:Polygon xmlns:xs=\"http://www.w3.org/2001/XMLSchema\" xmlns:gml=\"http://www.opengis.net/gml\" xmlns:sch=\"http://www.ascc.net/xml/schematron\" xmlns:xlink=\"http://www.w3.org/1999/xlink\" srsDimension=\"2\" srsName=\"http://www.opengis.net/gml/srs/epsg.xml#4326\">\n        <gml:exterior>\n          <gml:LinearRing srsDimension=\"2\">\n            <gml:posList>-180.125 -90.125 -180.125 89.875 179.875 89.875 179.875 -90.125 -180.125 -90.125</gml:posList>\n          </gml:LinearRing>\n        </gml:exterior>\n      </gml:Polygon>\n    </wmts:footprint>\n    <wmts:dimension name=\"elevation\">200.0</wmts:dimension>\n    <wmts:dimension name=\"time\">2016-02-23T03:00:00.000Z</wmts:dimension>\n    <wmts:dimension name=\"REFERENCE_TIME\">2016-02-23T00:00:00.000Z</wmts:dimension>\n  </wmts:feature>\n</wmts:FeatureCollection>\n

                                                                              Note how this result correlate with the correspondent DescribeDomains operation result.

                                                                              "},{"location":"extensions/wps-download/","title":"WPS Download plugin","text":"

                                                                              WPS Download plugin provides some useful features for easily downloading: * Raster or Vector layer as zip files * Large maps as images * Time based animation The module also provides facilities to control the output file size.

                                                                              "},{"location":"extensions/wps-download/#installing-the-wps-download-extension","title":"Installing the WPS Download extension","text":"

                                                                              The WPS Download extension is listed among the other extension downloads on the GeoServer download page.

                                                                              The installation process is similar to other GeoServer extensions:

                                                                              1. From the website download page, locate your release, and download: wps-download

                                                                                Verify that the version number in the filename corresponds to the version of GeoServer you are running (for example 2.24.2 above).

                                                                              2. Extract the contents of the archive into the WEB-INF/lib directory in GeoServer. Make sure you do not create any sub-directories during the extraction process.

                                                                              3. Restart GeoServer.

                                                                              "},{"location":"extensions/wps-download/#module-description","title":"Module description","text":"

                                                                              This module provides the following WPS process:

                                                                              • gs:Download : can be used for downloading Raster and Vector Layers
                                                                              • gs:DownloadEstimator : can be used for checking if the downloaded file does not exceeds the configured limits.
                                                                              • gs:DownloadMap: allows to download a large map with the same composition found on the client side (eventually along with an asynchronous call)
                                                                              • gs:DownloadAnimation: allows to download a map with the same composition found on the client side, with animation over a give set of times
                                                                              "},{"location":"extensions/wps-download/#configuring-the-limits","title":"Configuring the limits","text":"

                                                                              The user interface provides a way to configure the WPS download in the WPS administration page:

                                                                              Where the available limits are:

                                                                              • Maximum features : maximum number of features to download
                                                                              • Raster size limits : maximum pixel size of the Raster to read (in square pixels, width by height)
                                                                              • Write limits : maximum raw raster size in bytes (a limit of how much space can a raster take in memory). For a given raster, its raw size in bytes is calculated by multiplying pixel number (raster_width x raster_height) with the accumulated sum of each band's pixel sample_type size in bytes, for all bands
                                                                              • Hard output limit : maximum file size to download (will be checked while writing the output, post compression)
                                                                              • ZIP compresion level : compression level for the output zip file
                                                                              • Maximum frames in animation : maximum number of frames allowed (if no limit, the maximum execution time limits will still apply and stop the process in case there are too many)

                                                                              The configuration is stored in a download.properties file found in the root of the GeoServer data directory.

                                                                              # Max #of features\nmaxFeatures=100000\n#8000 px X 8000 px\nrasterSizeLimits=64000000\n#8000 px X 8000 px X 3 bands X 1 byte per band = 192MB\nwriteLimits=192000000\n# 50 MB\nhardOutputLimit=52428800\n# STORE =0, BEST =8\ncompressionLevel=4\n# When set to 0 or below, no limit\nmaxAnimationFrames=1000\n

                                                                              The file can also be manually modified while GeoServer is running, the file is under watch and gets reloaded on modification.

                                                                              The configuration can also be edited via the REST API.

                                                                              "},{"location":"extensions/wps-download/#the-processes-and-their-usage","title":"The processes and their usage","text":"

                                                                              The following describes the various processes, separating raw downloads from rendered downloads:

                                                                              • Raw data download processes
                                                                              • Rendered map/animation download processes
                                                                              "},{"location":"extensions/wps-download/mapAnimationDownload/","title":"Rendered map/animation download processes","text":"

                                                                              These processes allow download large maps and animations.

                                                                              "},{"location":"extensions/wps-download/mapAnimationDownload/#the-rendered-download-processes","title":"The rendered download processes","text":"

                                                                              The map and animation downloads work off a set of common parameters:

                                                                              • bbox : a geo-referenced bounding box, controlling both output area and desired projection
                                                                              • decoration : the name of a decoration layout to be added on top of the map
                                                                              • decorationEnvironment : a valid value for the env parameter used when painting the decoration. Used for dynamic decoration layouts<wms_dynamic_decorations>.
                                                                              • time : a WMS time specification used to drive the selection of times across the layers in the map, and to control the frame generation in the animation
                                                                              • width and height : size of the output map/animation (and in combination with bounding box, also controls the output map scale)
                                                                              • layer: a list of layer specifications, from a client side point of view (thus, a layer can be composed of multiple server side layers). When dwn:DecorationName layer option is used, it allows to define a specific layout that will be used when decorations are applied to the layer. It allows to render more than one Legend on the resulting image, when having more than one Layer declared.
                                                                              • headerheight : height size of a header space allocated at top of rendered map. It's an optional parameter, that forces to shrink the maps view height in order to avoid overlapping header over the maps. In combination with the use of layer specification options allows to group decorators at the top of resulting image.
                                                                              "},{"location":"extensions/wps-download/mapAnimationDownload/#the-layer-specification","title":"The layer specification","text":"

                                                                              A layer specification is a XML structure made of three parts:

                                                                              • Name: a comma separated list of layer names (eventually just one)
                                                                              • Capabilities: link to a capabilities document (optional, used when targetting remote WMS layers)
                                                                              • Parameter (key, value): an extra parameter to be added in the WMS request represented by this layer (e.g., elevation, CQL_FILTER, env)
                                                                              • Opacity: an optional parameter, ranging from 0 to 100, that controls the layer image level of translucency during the merge process. When not set the layer image is fully opaque. Note that this is seperate from the overall map transparent boolean parameter.

                                                                              For example:

                                                                              <wps:ComplexData xmlns:dwn=\"http://geoserver.org/wps/download\">\n  <dwn:Layer>\n    <dwn:Capabilities>http://demo.geo-solutions.it/geoserver/ows?service=wms&amp;version=1.1.1&amp;request=GetCapabilities</dwn:Name>\n    <dwn:Name>topp:states</dwn:Name>\n    <dwn:Parameter key=\"CQL_FILTER\"><![CDATA[PERSONS > 1000000]]></dwn:Parameter>\n    <dwn:Opacity>37</dwn:Opacity>\n  </dwn:Layer>\n</wps:ComplexData>\n
                                                                              "},{"location":"extensions/wps-download/mapAnimationDownload/#decoration-layout","title":"Decoration Layout","text":"

                                                                              The decoration parameter specifies the file name (without extension) of the layout to be used to decorate the map. The layout is a list of decorators that should draw on top of the requested image. The decorators draw on the image one after the other, so the order of the decorators in the layout file is important: the first decorator output will appear under the others.

                                                                              Decorators are described in detail in the WMS Decorations section. It is also possible to use dynamic decoration layouts<wms_dynamic_decorations>, in this case the environment parameters for the decoration will be provided using dwn:Parameter, e.g.:

                                                                              <dwn:Layer>\n  <dwn:Name>theLayer</dwn:Name>\n  <dwn:DecorationName>theDynamicDecoration</dwn:DecorationName>\n  <dwn:Parameter key=\"env\">sla:top,right;bg:#FF0000</dwn:Parameter>\n</dwn:Layer>\n
                                                                              "},{"location":"extensions/wps-download/mapAnimationDownload/#map-download-process","title":"Map Download Process","text":"

                                                                              In addition to the common parameters, the MapDownloadProcess sports an extra boolean parameter, transparent, which can be either true or false, determining if the output map has a transparent or a solid background (animation lacks this parameter, as videos need solid background). The transparent parameter defaults to false[^1].

                                                                              Also, unlike animation, in the map download process the time parameter is optional.

                                                                              The map download process uses the WMS machinery to produce the output, but it's not subject to the WMS service limits (width and height in this process can be limited using the WPS process security).

                                                                              "},{"location":"extensions/wps-download/mapAnimationDownload/#sample-downloadmap-requests","title":"Sample DownloadMap requests","text":"

                                                                              A download map issued against a set of local layers can look as follows:

                                                                              <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<wps:Execute version=\"1.0.0\" service=\"WPS\"\n             xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xmlns=\"http://www.opengis.net/wps/1.0.0\"\n             xmlns:wfs=\"http://www.opengis.net/wfs\" xmlns:wps=\"http://www.opengis.net/wps/1.0.0\"\n             xmlns:ows=\"http://www.opengis.net/ows/1.1\" xmlns:gml=\"http://www.opengis.net/gml\"\n             xmlns:ogc=\"http://www.opengis.net/ogc\" xmlns:wcs=\"http://www.opengis.net/wcs/1.1.1\"\n             xmlns:xlink=\"http://www.w3.org/1999/xlink\"\n             xsi:schemaLocation=\"http://www.opengis.net/wps/1.0.0 http://schemas.opengis.net/wps/1.0.0/wpsAll.xsd\">\n  <ows:Identifier>gs:DownloadMap</ows:Identifier>\n  <wps:DataInputs>\n    <wps:Input>\n      <ows:Identifier>bbox</ows:Identifier>\n      <wps:Data>\n        <wps:BoundingBoxData crs=\"EPSG:4326\">\n          <ows:LowerCorner>0.237 40.562</ows:LowerCorner>\n          <ows:UpperCorner>14.593 44.55</ows:UpperCorner>\n        </wps:BoundingBoxData>\n      </wps:Data>\n    </wps:Input>\n    <wps:Input>\n      <ows:Identifier>time</ows:Identifier>\n      <wps:Data>\n        <wps:LiteralData>2008-10-31T00:00:00.000Z</wps:LiteralData>\n      </wps:Data>\n    </wps:Input>\n    <wps:Input>\n      <ows:Identifier>width</ows:Identifier>\n      <wps:Data>\n        <wps:LiteralData>200</wps:LiteralData>\n      </wps:Data>\n    </wps:Input>\n    <wps:Input>\n      <ows:Identifier>height</ows:Identifier>\n      <wps:Data>\n        <wps:LiteralData>80</wps:LiteralData>\n      </wps:Data>\n    </wps:Input>\n    <wps:Input>\n      <ows:Identifier>layer</ows:Identifier>\n      <wps:Data>\n        <wps:ComplexData xmlns:dwn=\"http://geoserver.org/wps/download\">\n          <dwn:Layer>\n            <dwn:Name>giantPolygon</dwn:Name>\n            <dwn:Parameter key=\"featureId\">giantPolygon.0</dwn:Parameter>\n          </dwn:Layer>\n        </wps:ComplexData>\n      </wps:Data>\n    </wps:Input>\n    <wps:Input>\n      <ows:Identifier>layer</ows:Identifier>\n      <wps:Data>\n        <wps:ComplexData xmlns:dwn=\"http://geoserver.org/wps/download\">\n          <dwn:Layer>\n            <dwn:Name>watertemp</dwn:Name>\n          </dwn:Layer>\n        </wps:ComplexData>\n      </wps:Data>\n    </wps:Input>\n  </wps:DataInputs>\n  <wps:ResponseForm>\n    <wps:RawDataOutput mimeType=\"image/png\">\n      <ows:Identifier>result</ows:Identifier>\n    </wps:RawDataOutput>\n  </wps:ResponseForm>\n</wps:Execute>\n

                                                                              For this example the layers could have been a single one, with a \"Name\" equal to \"giantPolygon,watertermp\".

                                                                              "},{"location":"extensions/wps-download/mapAnimationDownload/#secondary-output-map-metadata","title":"Secondary output: map metadata","text":"

                                                                              The process offers also a secondary output, called metadata, which can be used to determine if there were any issue related to the requested times. The warnings are issued when the layer has a \"nearest match\" behavior activated, with an eventual search range.

                                                                              In case the requested time could not be matched exactly, a warning will be issued that might contain:

                                                                              • An indication that a nearby time has been used, and which time that is.
                                                                              • An indication that no time was found, that was sufficiently close to the requested one, according to the search range specification in the layer \"nearest match\" configuration.

                                                                              In order to get both outputs, the following response form is recommended, which requires a reference (a link) for the map, while the warnings are included inline:

                                                                              <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<wps:Execute version=\"1.0.0\" service=\"WPS\"\n             xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xmlns=\"http://www.opengis.net/wps/1.0.0\"\n             xmlns:wfs=\"http://www.opengis.net/wfs\" xmlns:wps=\"http://www.opengis.net/wps/1.0.0\"\n             xmlns:ows=\"http://www.opengis.net/ows/1.1\" xmlns:gml=\"http://www.opengis.net/gml\"\n             xmlns:ogc=\"http://www.opengis.net/ogc\" xmlns:wcs=\"http://www.opengis.net/wcs/1.1.1\"\n             xmlns:xlink=\"http://www.w3.org/1999/xlink\"\n             xsi:schemaLocation=\"http://www.opengis.net/wps/1.0.0 http://schemas.opengis.net/wps/1.0.0/wpsAll.xsd\">\n  <ows:Identifier>gs:DownloadMap</ows:Identifier>\n  <!-- Inputs section removed for brevity -->\n  <wps:ResponseForm>\n    <wps:ResponseDocument>\n      <wps:Output asReference=\"true\">\n        <ows:Identifier>result</ows:Identifier>\n      </wps:Output>\n      <wps:Output>\n        <ows:Identifier>metadata</ows:Identifier>\n      </wps:Output>\n    </wps:ResponseDocument>\n  </wps:ResponseForm>\n</wps:Execute>\n

                                                                              A sample response, reporting warnings, follows:

                                                                              <?xml version=\"1.0\" encoding=\"UTF-8\"?><wps:ExecuteResponse xmlns:wps=\"http://www.opengis.net/wps/1.0.0\" xmlns:ows=\"http://www.opengis.net/ows/1.1\" xmlns:xlink=\"http://www.w3.org/1999/xlink\" xmlns:xs=\"http://www.w3.org/2001/XMLSchema\" service=\"WPS\" serviceInstance=\"http://localhost:8080/geoserver/ows?\" version=\"1.0.0\" xml:lang=\"en\">\n  <wps:Process wps:processVersion=\"1.0.0\">\n    <ows:Identifier>gs:DownloadMap</ows:Identifier>\n    <ows:Title>Map Download Process</ows:Title>\n    <ows:Abstract>Builds a large map given a set of layer definitions, area of interest, size and eventual target time.</ows:Abstract>\n  </wps:Process>\n  <wps:Status creationTime=\"2021-06-07T16:50:47.391Z\">\n    <wps:ProcessSucceeded>Process succeeded.</wps:ProcessSucceeded>\n  </wps:Status>\n  <wps:ProcessOutputs>\n    <wps:Output>\n      <ows:Identifier>result</ows:Identifier>\n      <ows:Title>The output map</ows:Title>\n      <wps:Reference href=\"http://localhost:8080/geoserver/ows?service=WPS&amp;version=1.0.0&amp;request=GetExecutionResult&amp;executionId=5db686ed-8591-4756-8651-4bd26281bf37&amp;outputId=result.png&amp;mimetype=image%2Fpng\" mimeType=\"image/png\"/>\n    </wps:Output>\n    <wps:Output>\n      <ows:Identifier>metadata</ows:Identifier>\n      <ows:Title>map metadata, including dimension match warnings</ows:Title>\n      <wps:Data>\n        <wps:ComplexData mimeType=\"text/xml\">\n          <DownloadMetadata>\n            <Warnings>\n              <DimensionWarning>\n                <LayerName>sf:bmtime</LayerName>\n                <DimensionName>time</DimensionName>\n                <Value class=\"Date\">2004-02-01T00:00:00.000Z</Value>\n                <WarningType>Nearest</WarningType>\n              </DimensionWarning>\n            </Warnings>\n            <WarningsFound>true</WarningsFound>\n          </DownloadMetadata>\n        </wps:ComplexData>\n      </wps:Data>\n    </wps:Output>\n  </wps:ProcessOutputs>\n</wps:ExecuteResponse>\n
                                                                              "},{"location":"extensions/wps-download/mapAnimationDownload/#animation-download-process","title":"Animation Download Process","text":"

                                                                              The download animation has all the basic parameters with the following variants/additions:

                                                                              • time: The time parameter is required and can be provided either as range with periodicity, start/stop/period, or as a comma separated list of times,t1,t2,...,tn
                                                                              • fps: Frame per seconds (defaults to one)
                                                                              "},{"location":"extensions/wps-download/mapAnimationDownload/#sample-downloadanimation-request","title":"Sample DownloadAnimation request","text":"

                                                                              A sample animation request can look as follows:

                                                                              <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<wps:Execute version=\"1.0.0\" service=\"WPS\"\n             xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xmlns=\"http://www.opengis.net/wps/1.0.0\"\n             xmlns:wfs=\"http://www.opengis.net/wfs\" xmlns:wps=\"http://www.opengis.net/wps/1.0.0\"\n             xmlns:ows=\"http://www.opengis.net/ows/1.1\" xmlns:gml=\"http://www.opengis.net/gml\"\n             xmlns:ogc=\"http://www.opengis.net/ogc\" xmlns:wcs=\"http://www.opengis.net/wcs/1.1.1\"\n             xmlns:xlink=\"http://www.w3.org/1999/xlink\"\n             xsi:schemaLocation=\"http://www.opengis.net/wps/1.0.0 http://schemas.opengis.net/wps/1.0.0/wpsAll.xsd\">\n  <ows:Identifier>gs:DownloadAnimation</ows:Identifier>\n  <wps:DataInputs>\n    <wps:Input>\n      <ows:Identifier>bbox</ows:Identifier>\n      <wps:Data>\n        <wps:BoundingBoxData crs=\"EPSG:4326\">\n          <ows:LowerCorner>-180 -90</ows:LowerCorner>\n          <ows:UpperCorner>180 90</ows:UpperCorner>\n        </wps:BoundingBoxData>\n      </wps:Data>\n    </wps:Input>\n    <wps:Input>\n      <ows:Identifier>decoration</ows:Identifier>\n      <wps:Data>\n        <wps:LiteralData>formattedTimestamper</wps:LiteralData>\n      </wps:Data>\n    </wps:Input>\n    <wps:Input>\n      <ows:Identifier>time</ows:Identifier>\n      <wps:Data>\n        <wps:LiteralData>2004-02-01,2004-03-01,2004-04-01,2004-05-01</wps:LiteralData>\n      </wps:Data>\n    </wps:Input>\n    <wps:Input>\n      <ows:Identifier>width</ows:Identifier>\n      <wps:Data>\n        <wps:LiteralData>271</wps:LiteralData>\n      </wps:Data>\n    </wps:Input>\n    <wps:Input>\n      <ows:Identifier>height</ows:Identifier>\n      <wps:Data>\n        <wps:LiteralData>136</wps:LiteralData>\n      </wps:Data>\n    </wps:Input>\n    <wps:Input>\n      <ows:Identifier>fps</ows:Identifier>\n      <wps:Data>\n        <wps:LiteralData>0.5</wps:LiteralData>\n      </wps:Data>\n    </wps:Input>\n    <wps:Input>\n      <ows:Identifier>layer</ows:Identifier>\n      <wps:Data>\n        <wps:ComplexData xmlns:dwn=\"http://geoserver.org/wps/download\">\n          <dwn:Layer>\n            <dwn:Name>sf:bmtime</dwn:Name>\n          </dwn:Layer>\n        </wps:ComplexData>\n      </wps:Data>\n    </wps:Input>\n  </wps:DataInputs>\n  <wps:ResponseForm>\n    <wps:RawDataOutput mimeType=\"video/mp4\">\n      <ows:Identifier>result</ows:Identifier>\n    </wps:RawDataOutput>\n  </wps:ResponseForm>\n</wps:Execute>\n

                                                                              The formattedTimestamper decoration ensures the frame time is included in the output animation, and looks as follows:

                                                                              <layout>\n  <decoration type=\"text\" affinity=\"bottom,right\" offset=\"6,6\" size=\"auto\">\n    <option name=\"message\"><![CDATA[\n<#setting datetime_format=\"yyyy-MM-dd'T'HH:mm:ss.SSSX\">\n<#setting locale=\"en_US\">\n<#if time??>\n${time?datetime?string[\"dd-MM-yyyy\"]}\n</#if>]]></option>\n    <option name=\"font-family\" value=\"Bitstream Vera Sans\"/>\n    <option name=\"font-size\" value=\"12\"/>\n    <option name=\"halo-radius\" value=\"2\"/>\n  </decoration>\n</layout>\n
                                                                              "},{"location":"extensions/wps-download/mapAnimationDownload/#secondary-output-animation-metadata","title":"Secondary output: animation metadata","text":"

                                                                              The process offers also a secondary output, called metadata, which can be used to determine if there were any issue related to the requested times. The warnings are issued when the layer has a \"nearest match\" behavior activated, with an eventual search range.

                                                                              In case the requested time could not be matched exactly, a warning will be issued that might contain:

                                                                              • An indication that a nearby time has been used, and which time that is.
                                                                              • An indication that no time was found, that was sufficiently close to the requested one, according to the search range specification in the layer \"nearest match\" configuration.

                                                                              In order to get both outputs, the following response form is recommended, which requires a reference (a link) for the animation, while the warnings are included inline:

                                                                              <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<wps:Execute version=\"1.0.0\" service=\"WPS\"\n             xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xmlns=\"http://www.opengis.net/wps/1.0.0\"\n             xmlns:wfs=\"http://www.opengis.net/wfs\" xmlns:wps=\"http://www.opengis.net/wps/1.0.0\"\n             xmlns:ows=\"http://www.opengis.net/ows/1.1\" xmlns:gml=\"http://www.opengis.net/gml\"\n             xmlns:ogc=\"http://www.opengis.net/ogc\" xmlns:wcs=\"http://www.opengis.net/wcs/1.1.1\"\n             xmlns:xlink=\"http://www.w3.org/1999/xlink\"\n             xsi:schemaLocation=\"http://www.opengis.net/wps/1.0.0 http://schemas.opengis.net/wps/1.0.0/wpsAll.xsd\">\n  <ows:Identifier>gs:DownloadAnimation</ows:Identifier>\n  <!-- Inputs section removed for brevity -->\n  <wps:ResponseForm>\n    <wps:ResponseDocument>\n      <wps:Output asReference=\"true\">\n        <ows:Identifier>result</ows:Identifier>\n      </wps:Output>\n      <wps:Output>\n        <ows:Identifier>metadata</ows:Identifier>\n      </wps:Output>\n    </wps:ResponseDocument>\n  </wps:ResponseForm>\n</wps:Execute>\n

                                                                              A sample response, reporting warnings and the frame count where they happened, follows:

                                                                              <?xml version=\"1.0\" encoding=\"UTF-8\"?><wps:ExecuteResponse xmlns:wps=\"http://www.opengis.net/wps/1.0.0\" xmlns:ows=\"http://www.opengis.net/ows/1.1\" xmlns:xlink=\"http://www.w3.org/1999/xlink\" xmlns:xs=\"http://www.w3.org/2001/XMLSchema\" service=\"WPS\" serviceInstance=\"http://localhost:8080/geoserver/ows?\" version=\"1.0.0\" xml:lang=\"en\">\n  <wps:Process wps:processVersion=\"1.0.0\">\n    <ows:Identifier>gs:DownloadAnimation</ows:Identifier>\n    <ows:Title>Animation Download Process</ows:Title>\n    <ows:Abstract>Builds an animation given a set of layer definitions, area of interest, size and a series of times for animation frames.</ows:Abstract>\n  </wps:Process>\n  <wps:Status creationTime=\"2021-06-07T16:50:47.391Z\">\n    <wps:ProcessSucceeded>Process succeeded.</wps:ProcessSucceeded>\n  </wps:Status>\n  <wps:ProcessOutputs>\n    <wps:Output>\n      <ows:Identifier>result</ows:Identifier>\n      <ows:Title>The animation</ows:Title>\n      <wps:Reference href=\"http://localhost:8080/geoserver/ows?service=WPS&amp;version=1.0.0&amp;request=GetExecutionResult&amp;executionId=b98eded5-8122-442b-a6c7-87a872779153&amp;outputId=result.mp4&amp;mimetype=video%2Fmp4\" mimeType=\"video/mp4\"/>\n    </wps:Output>\n    <wps:Output>\n      <ows:Identifier>metadata</ows:Identifier>\n      <ows:Title>Animation metadata, including dimension match warnings</ows:Title>\n      <wps:Data>\n        <wps:ComplexData mimeType=\"text/xml\">\n          <AnimationMetadata>\n            <Warnings>\n              <FrameWarning>\n                <LayerName>sf:bmtime</LayerName>\n                <DimensionName>time</DimensionName>\n                <Value class=\"Date\">2004-02-01T00:00:00.000Z</Value>\n                <WarningType>Nearest</WarningType>\n                <Frame>0</Frame>\n              </FrameWarning>\n              <FrameWarning>\n                <LayerName>sf:bmtime</LayerName>\n                <DimensionName>time</DimensionName>\n                <WarningType>FailedNearest</WarningType>\n                <Frame>1</Frame>\n              </FrameWarning>\n              <FrameWarning>\n                <LayerName>sf:bmtime</LayerName>\n                <DimensionName>time</DimensionName>\n                <Value class=\"Date\">2004-04-01T00:00:00.000Z</Value>\n                <WarningType>Nearest</WarningType>\n                <Frame>2</Frame>\n              </FrameWarning>\n              <FrameWarning>\n                <LayerName>sf:bmtime</LayerName>\n                <DimensionName>time</DimensionName>\n                <Value class=\"Date\">2004-05-01T00:00:00.000Z</Value>\n                <WarningType>Nearest</WarningType>\n                <Frame>3</Frame>\n              </FrameWarning>\n            </Warnings>\n            <WarningsFound>true</WarningsFound>\n          </AnimationMetadata>\n        </wps:ComplexData>\n      </wps:Data>\n    </wps:Output>\n  </wps:ProcessOutputs>\n</wps:ExecuteResponse>\n

                                                                              In the above output, frames 0, 2 and 3 were nearest matched to an available time, being specified in the Value field, while the time requested for frame number 1 was too far away from any available time, resulting in a NearestFail. The frame is still present in the animation, but will likely be blank. In case multiple time based layers are requested in the animation, there might be multiple warnings for each frame.

                                                                              Footnotes

                                                                              [^1]: The default value of transparent can be flipped using a system variable, e.g. -DDOWNLOAD_MAP_TRANSPARENT=true

                                                                              "},{"location":"extensions/wps-download/rawDownload/","title":"Raw data download processes","text":"

                                                                              These processes allow download of vector and raster data in raw form, without rendering.

                                                                              "},{"location":"extensions/wps-download/rawDownload/#download-estimator-process","title":"Download Estimator Process","text":"

                                                                              The Download Estimator Process checks the size of the file to download. This process takes in input the following parameters:

                                                                              • layername : name of the layer to check
                                                                              • ROI : ROI object to use for cropping data
                                                                              • filter : filter for filtering input data
                                                                              • targetCRS : CRS of the final layer if reprojection is needed

                                                                              This process will return a boolean which will be true if the downloaded file will not exceed the configured limits.

                                                                              "},{"location":"extensions/wps-download/rawDownload/#download-process","title":"Download Process","text":"

                                                                              The Download Process calls the Download Estimator Process, checks the file size, and, if the file does not exceed the limits, download the file as a zip. The parameters to set are

                                                                              • layerName : the name of the layer to process/download
                                                                              • filter : a vector filter for filtering input data(optional)
                                                                              • outputFormat : the MIME type of the format of the final file
                                                                              • targetCRS : the CRS of the output file (optional)
                                                                              • RoiCRS : Region Of Interest CRS (optional)
                                                                              • ROI : Region Of Interest object to use for cropping data (optional)
                                                                              • cropToROI : boolean parameter to allow cropping to actual ROI, or its envelope (optional)
                                                                              • interpolation : interpolation function to use when reprojecting / scaling raster data. Values are NEAREST (default), BILINEAR, BICUBIC2, BICUBIC (optional)
                                                                              • targetSizeX : size X in pixels of the output (optional, applies for raster input only)
                                                                              • targetSizeY : size Y in pixels of the output (optional, applies for raster input only)
                                                                              • selectedBands : a set of the band indices of the original raster that will be used for producing the final result (optional, applies for raster input only)
                                                                              • writeParameters : a set of writing parameters (optional, applies for raster input only). See Writing parameters below section for more details on writing parameters defintion.
                                                                              • minimizeReprojections : since 2.17, parameter to control CRS management when dealing with heterogeneous CRS's coverages, in order to minimize reprojections when granules in ROI match the TargetCRS. See RasterDownload of Heterogeneous CRS ImageMosaic below section for more details on this param.
                                                                              • bestResolutionOnMatchingCRS : since 2.17, parameter to control CRS and resolution management when dealing with heterogeneous CRS's coverages. See RasterDownload of Heterogeneous CRS ImageMosaic below section for more details on this param.
                                                                              • targetVerticalCRS : optional TargetVerticalCRS, to be used to transform elevation data from a VerticalCRS to another one. See Vertical data resampling on download below section for more details on this param
                                                                              • resolutionsDifferenceTolerance : the parameter allows to specify a tolerance value to control the use of native resolution of the data, when no target size has been specified and granules are reprojected. If
                                                                                • the percentage difference between original and reprojected coverages resolutions is below the specified tolerance value,
                                                                                • native resolution is the same for all the requested granules,
                                                                                • the unit of measure is the same for native and target CRS,

                                                                              the reprojected coverage will be forced to use native resolutions. For example by specifying a value of 5.0, if the percentage difference between native and reprojected data is below 5%, assuming that also the other two conditions are respected, the native resolutions will be preserved. Default values is 0.

                                                                              The targetCRS and RoiCRS parameters are using EPSG code terminology, so, valid parameters are literals like EPSG:4326 (if we are referring to a the Geogaphic WGS84 CRS), EPSG:3857 (for WGS84 Web Mercator CRS), etc.

                                                                              "},{"location":"extensions/wps-download/rawDownload/#roi-definition","title":"ROI Definition","text":"

                                                                              A ROI parameter is a geometry object which can also be defined if three different forms:

                                                                              • as TEXT, in various geometry textual formats/representations
                                                                              • as REFERENCE, which is the textual result of an HTTP GET/POST request to a specific url
                                                                              • as a SUPPROCESS result: the format produced as result of the process execution must be a compatible geometry textual format.

                                                                              As noted above, in all above forms/cases ROI geometry is defined as text, in specific formats. These can be:

                                                                              • text/xml; subtype=gml/3.1.1: conforming to gml specs 3.1.1
                                                                              • text/xml; subtype=gml/2.1.2: conforming to gml specs 2.1.2
                                                                              • application/wkt: the WKT geometry representation
                                                                              • application/json: the JSON geometry representation
                                                                              • application/gml-3.1.1: conforming to gml specs 3.1.1
                                                                              • application/gml-2.1.2: conforming to gml specs 2.1.2

                                                                              For example, a polygon used as ROI with the following WKT representation:

                                                                              POLYGON (( 500116.08576537756 499994.25579707103, 500116.08576537756 500110.1012210889, 500286.2657688021 500110.1012210889, 500286.2657688021 499994.25579707103, 500116.08576537756 499994.25579707103 ))

                                                                              would be represented in the following forms:

                                                                              • in application/wkt: POLYGON (( 500116.08576537756 499994.25579707103, 500116.08576537756 500110.1012210889, 500286.2657688021 500110.1012210889, 500286.2657688021 499994.25579707103, 500116.08576537756 499994.25579707103 ))
                                                                              • in application/json: {\"type\":\"Polygon\",\"coordinates\":[[[500116.0858,499994.2558],[500116.0858,500110.1012],[500286.2658,500110.1012],[500286.2658,499994.2558],[500116.0858,499994.2558]]]}
                                                                              • in text/xml:500116.08576537756,499994.25579707103 500116.08576537756,500110.1012210889 500286.2657688021,500110.1012210889 500286.2657688021,499994.25579707103 500116.08576537756,499994.25579707103
                                                                              • in application/xml: the following xml
                                                                              <?xml version=\"1.0\" encoding=\"UTF-8\"?><gml:Polygon xmlns:gml=\"http://www.opengis.net/gml\" xmlns:xs=\"http://www.w3.org/2001/XMLSchema\" xmlns:xlink=\"http://www.w3.org/1999/xlink\">\n  <gml:outerBoundaryIs>\n    <gml:LinearRing>\n      <gml:coordinates>500116.08576537756,499994.25579707103 500116.08576537756,500110.1012210889 500286.2657688021,500110.1012210889 500286.2657688021,499994.25579707103 500116.08576537756,499994.25579707103</gml:coordinates>\n    </gml:LinearRing>\n  </gml:outerBoundaryIs>\n</gml:Polygon>\n

                                                                              The general structure of a WPS Download request POST payload consists of two parts: the first (<wps:DataInputs>) contains the input parameters for the process, and the second (<wps:ResponseForm>) contains details about delivering the output. A typical pseudo payload is the following:

                                                                              <?xml version=\"1.0\" encoding=\"UTF-8\"?><wps:Execute version=\"1.0.0\" service=\"WPS\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xmlns=\"http://www.opengis.net/wps/1.0.0\" xmlns:wfs=\"http://www.opengis.net/wfs\" xmlns:wps=\"http://www.opengis.net/wps/1.0.0\" xmlns:ows=\"http://www.opengis.net/ows/1.1\" xmlns:gml=\"http://www.opengis.net/gml\" xmlns:ogc=\"http://www.opengis.net/ogc\" xmlns:wcs=\"http://www.opengis.net/wcs/1.1.1\" xmlns:xlink=\"http://www.w3.org/1999/xlink\" xsi:schemaLocation=\"http://www.opengis.net/wps/1.0.0 http://schemas.opengis.net/wps/1.0.0/wpsAll.xsd\">\n <ows:Identifier>gs:WPS_Process_Name_Here</ows:Identifier>\n <wps:DataInputs>\n  <wps:Input>\n   <ows:Identifier>First_Param_Name</ows:Identifier>\n   <wps:Data>\n     (First_Param_Data)\n   </wps:Data>\n  </wps:Input>\n  ...\n  ...\n </wps:DataInputs>\n <wps:ResponseForm>\n  <wps:RawDataOutput mimeType=\"application/zip\">\n   <ows:Identifier>result</ows:Identifier>\n  </wps:RawDataOutput>\n </wps:ResponseForm>\n</wps:Execute>\n

                                                                              Each parameter for the process is defined in its own <wps:Input> xml block. In case of simple type data, such as layerName, outputFormat, targetCRS, etc, input params xml blocks have the following form:

                                                                              <wps:Input>\n <ows:Identifier>layerName</ows:Identifier>\n <wps:Data>\n  <wps:LiteralData>nurc:Img_Sample</wps:LiteralData>\n </wps:Data>\n</wps:Input>\n

                                                                              Note the <wps:LiteralData> tags wrapping the parameter value. In case of geometry parameters, such as filter, ROI, the parameter's <wps:Input> block is different:

                                                                              <wps:Input>\n  <ows:Identifier>ROI</ows:Identifier>\n  <wps:Data>\n    <wps:ComplexData mimeType=\"application/wkt\"><![CDATA[POLYGON (( 500116.08576537756 499994.25579707103, 500116.08576537756 500110.1012210889, 500286.2657688021 500110.1012210889, 500286.2657688021 499994.25579707103, 500116.08576537756 499994.25579707103 ))]]></wps:ComplexData>\n  </wps:Data>\n</wps:Input>\n

                                                                              Note the <wps:ComplexData> tag, the mimeType=\"application/wkt\" parameter, and the ![CDATA[] wrapping of the actual geometry data (in textual representation), according to the selected MIME type.

                                                                              Note that if the ROI parameter is defined as WKT, you will need to specify a RoiCRS input parameter as well.

                                                                              In case the ROI is defined using a REFERENCE source, the input block is slightly different:

                                                                              <wps:Input>\n  <ows:Identifier>ROI</ows:Identifier>\n  <wps:Reference mimeType=\"application/wkt\" xlink:href=\"url_to_fetch_data\" method=\"GET\"/>\n</wps:Input>\n

                                                                              Note the <wps:Reference> tag replacing <wps:ComplexData> tag, and the extra xlink:href=\"url_to_fetch_data\" parameter, which defines the url to perform the HTTP GET request. For POST request cases, tech method is switched to POST, and a <wps:Body> tag is used to wrap POST data:

                                                                              <wps:Reference mimeType=\"application/wkt\" xlink:href=\"url_to_fetch_data\" method=\"POST\">\n  <wps:Body><![CDATA[request_body_data]]></wps:Body>\n</wps:Reference>\n
                                                                              "},{"location":"extensions/wps-download/rawDownload/#filter-parameter-definition","title":"Filter parameter definition","text":"

                                                                              A filter parameter is a definition of a vector filter operation:

                                                                              • as TEXT, in various textual formats/representations
                                                                              • as REFERENCE, which is the textual result of an HTTP GET/POST request to a specific url
                                                                              • as a SUBPROCESS result: the format produced as result of the process execution must be a compatible geometry textual format.

                                                                              Compatible text formats for filter definitions are:

                                                                              • text/xml; filter/1.0
                                                                              • text/xml; filter/1.1
                                                                              • text/xml; cql

                                                                              For more details on filter formats/languages, one can see ../../filter/syntax and ../../filter/function. Filter parameter applies to vector data. If this is the case with input data, a sample <wps:Input> block of a filter intersecting the polygon we used earlier as an example for ROI definition would be:

                                                                              <wps:Input>\n  <ows:Identifier>filter</ows:Identifier>\n  <wps:Data>\n    <wps:ComplexData mimeType=\"text/plain; subtype=cql\"><![CDATA[<Intersects>\n       <PropertyName>GEOMETRY</PropertyName>\n         <gml:Polygon>\n           <gml:outerBoundaryIs>\n             <gml:LinearRing>\n                <gml:coordinates>500116.08576537756,499994.25579707103 500116.08576537756,500110.1012210889 500286.2657688021,500110.1012210889 500286.2657688021,499994.25579707103 500116.08576537756,499994.25579707103</gml:coordinates>\n              </gml:LinearRing>\n           </gml:outerBoundaryIs>\n         </gml:Polygon>\n     </Intersects>]]></wps:ComplexData>\n  </wps:Data>\n</wps:Input>\n
                                                                              "},{"location":"extensions/wps-download/rawDownload/#sample-request","title":"Sample request","text":""},{"location":"extensions/wps-download/rawDownload/#synchronous-execution","title":"Synchronous execution","text":"

                                                                              The following is a sample WPS request for processing a raster dataset. Suppose we want to use the North America sample imagery (nurc:Img_Sample) layer, to produce an 80x80 pixels downloadable tiff in EPSG:4326

                                                                              Assuming that a local geoserver instance (setup for wps/wps-download support) is running, we issue a POST request to the url:

                                                                              http://127.0.0.1:8080/geoserver/ows?service=wps

                                                                              using the following payload:

                                                                              <?xml version=\"1.0\" encoding=\"UTF-8\"?><wps:Execute version=\"1.0.0\" service=\"WPS\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xmlns=\"http://www.opengis.net/wps/1.0.0\" xmlns:wfs=\"http://www.opengis.net/wfs\" xmlns:wps=\"http://www.opengis.net/wps/1.0.0\" xmlns:ows=\"http://www.opengis.net/ows/1.1\" xmlns:gml=\"http://www.opengis.net/gml\" xmlns:ogc=\"http://www.opengis.net/ogc\" xmlns:wcs=\"http://www.opengis.net/wcs/1.1.1\" xmlns:xlink=\"http://www.w3.org/1999/xlink\" xsi:schemaLocation=\"http://www.opengis.net/wps/1.0.0 http://schemas.opengis.net/wps/1.0.0/wpsAll.xsd\">\n <ows:Identifier>gs:Download</ows:Identifier>\n <wps:DataInputs>\n  <wps:Input>\n   <ows:Identifier>layerName</ows:Identifier>\n   <wps:Data>\n    <wps:LiteralData>nurc:Img_Sample</wps:LiteralData>\n   </wps:Data>\n  </wps:Input>\n  <wps:Input>\n   <ows:Identifier>outputFormat</ows:Identifier>\n   <wps:Data>\n    <wps:LiteralData>image/tiff</wps:LiteralData>\n   </wps:Data>\n  </wps:Input>\n  <wps:Input>\n   <ows:Identifier>targetCRS</ows:Identifier>\n   <wps:Data>\n    <wps:LiteralData>EPSG:4326</wps:LiteralData>\n   </wps:Data>\n  </wps:Input>\n  <wps:Input>\n   <ows:Identifier>targetSizeX</ows:Identifier>\n   <wps:Data>\n    <wps:LiteralData>80</wps:LiteralData>\n   </wps:Data>\n  </wps:Input>\n  <wps:Input>\n   <ows:Identifier>targetSizeY</ows:Identifier>\n   <wps:Data>\n    <wps:LiteralData>80</wps:LiteralData>\n   </wps:Data>\n  </wps:Input>\n </wps:DataInputs>\n <wps:ResponseForm>\n  <wps:RawDataOutput mimeType=\"application/zip\">\n   <ows:Identifier>result</ows:Identifier>\n  </wps:RawDataOutput>\n </wps:ResponseForm>\n</wps:Execute>\n

                                                                              More parameters (from the parameter list above) can be used, for example, we can only select bands 0 and 2 from the original raster:

                                                                              <wps:Input>\n <ows:Identifier>bandIndices</ows:Identifier>\n <wps:Data>\n  <wps:LiteralData>0</wps:LiteralData>\n </wps:Data>\n</wps:Input>\n<wps:Input>\n <ows:Identifier>bandIndices</ows:Identifier>\n <wps:Data>\n  <wps:LiteralData>2</wps:LiteralData>\n </wps:Data>\n</wps:Input>\n

                                                                              Or, use a Region Of Interest to crop the dataset:

                                                                              <wps:Input>\n  <ows:Identifier>ROI</ows:Identifier>\n  <wps:Data>\n    <wps:ComplexData mimeType=\"application/wkt\"><![CDATA[\"POLYGON (( 500116.08576537756 499994.25579707103, 500116.08576537756 500110.1012210889, 500286.2657688021 500110.1012210889, 500286.2657688021 499994.25579707103, 500116.08576537756 499994.25579707103 ))]]></wps:ComplexData>\n  </wps:Data>\n</wps:Input>\n<wps:Input>\n  <ows:Identifier>RoiCRS</ows:Identifier>\n  <wps:Data>\n    <wps:LiteralData>EPSG:32615</wps:LiteralData>\n  </wps:Data>\n</wps:Input>\n

                                                                              The result produced is a zipped file to download.

                                                                              "},{"location":"extensions/wps-download/rawDownload/#asynchronous-execution","title":"Asynchronous execution","text":"

                                                                              The process can also be performed asynchronously. In this case, the second part (wps:ResponseForm) of the wps download payload slightly changes, by using the storeExecuteResponse and status parameters, set to true for the <wps:ResponseDocument>:

                                                                              <wps:ResponseForm>\n  <wps:ResponseDocument storeExecuteResponse=\"true\" status=\"true\">\n    <wps:RawDataOutput mimeType=\"application/zip\">\n      <ows:Identifier>result</ows:Identifier>\n    </wps:RawDataOutput>\n  </wps:ResponseDocument>>\n</wps:ResponseForm>\n

                                                                              In case of asynchronous execution, the initial request to download data returns an xml indication that the process has successfully started:

                                                                              <?xml version=\"1.0\" encoding=\"UTF-8\"?><wps:ExecuteResponse xmlns:xs=\"http://www.w3.org/2001/XMLSchema\" xmlns:ows=\"http://www.opengis.net/ows/1.1\" xmlns:wps=\"http://www.opengis.net/wps/1.0.0\" xmlns:xlink=\"http://www.w3.org/1999/xlink\" xml:lang=\"en\" service=\"WPS\" serviceInstance=\"http://127.0.0.1:8080/geoserver/ows?\" statusLocation=\"http://127.0.0.1:8080/geoserver/ows?service=WPS&amp;version=1.0.0&amp;request=GetExecutionStatus&amp;executionId=dd0d61f5-7da3-41ed-bd3f-15311fa660ba\" version=\"1.0.0\">\n  <wps:Process wps:processVersion=\"1.0.0\">\n      <ows:Identifier>gs:Download</ows:Identifier>\n      <ows:Title>Enterprise Download Process</ows:Title>\n      <ows:Abstract>Downloads Layer Stream and provides a ZIP.</ows:Abstract>\n  </wps:Process>\n  <wps:Status creationTime=\"2016-08-08T11:03:18.167Z\">\n      <wps:ProcessAccepted>Process accepted.</wps:ProcessAccepted>\n  </wps:Status>\n</wps:ExecuteResponse>\n

                                                                              The response contains a <wps:Status> block indicating successful process creation and process start time. However, the important part in this response is the executionId=dd0d61f5-7da3-41ed-bd3f-15311fa660ba attribute in the <wps:ExecuteResponse> tag. The dd0d61f5-7da3-41ed-bd3f-15311fa660ba ID can be used as a reference for this process, in order to issue new GET requests and to check process status. These requests have the form:

                                                                              http://127.0.0.1:8080/geoserver/ows?service=WPS&request=GetExecutionStatus&executionId=277e24eb-365d-42e1-8329-44b8076d4fc0

                                                                              When issued (and process has finished on the server), this GET request returns the result to download/process as a base64 encoded zip:

                                                                              <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<wps:ExecuteResponse xmlns:xs=\"http://www.w3.org/2001/XMLSchema\" xmlns:ows=\"http://www.opengis.net/ows/1.1\" xmlns:wps=\"http://www.opengis.net/wps/1.0.0\" xmlns:xlink=\"http://www.w3.org/1999/xlink\" xml:lang=\"en\" service=\"WPS\" serviceInstance=\"http://127.0.0.1:8080/geoserver/ows?\" statusLocation=\"http://127.0.0.1:8080/geoserver/ows?service=WPS&amp;version=1.0.0&amp;request=GetExecutionStatus&amp;executionId=0c596a4d-7ddb-4a4e-bf35-4a64b47ee0d3\" version=\"1.0.0\">\n  <wps:Process wps:processVersion=\"1.0.0\">\n      <ows:Identifier>gs:Download</ows:Identifier>\n      <ows:Title>Enterprise Download Process</ows:Title>\n      <ows:Abstract>Downloads Layer Stream and provides a ZIP.</ows:Abstract>\n  </wps:Process>\n  <wps:Status creationTime=\"2016-08-08T11:18:46.015Z\">\n      <wps:ProcessSucceeded>Process succeeded.</wps:ProcessSucceeded>\n  </wps:Status>\n  <wps:ProcessOutputs>\n      <wps:Output>\n          <ows:Identifier>result</ows:Identifier>\n          <ows:Title>Zipped output files to download</ows:Title>\n          <wps:Data>\n              <wps:ComplexData encoding=\"base64\" mimeType=\"application/zip\">UEsDBBQACAgIAFdyCEkAAAAAAAAAAAAAAAApAAAAMGEwYmJkYmQtMjdkNi00...(more zipped raster data following, ommited for space saving)...</wps:ComplexData>\n          </wps:Data>\n      </wps:Output>\n  </wps:ProcessOutputs>\n</wps:ExecuteResponse>\n
                                                                              "},{"location":"extensions/wps-download/rawDownload/#asynchronous-execution-output-as-a-reference","title":"Asynchronous execution (output as a reference)","text":"

                                                                              The <wps:ResponseForm> of the previous asynchronous request payload example can be modified to get back a link to the file to be downloaded instead of the base64 encoded data.

                                                                              ...\n<wps:ResponseForm>\n  <wps:ResponseDocument storeExecuteResponse=\"true\" status=\"true\">\n    <wps:Output asReference=\"true\" mimeType=\"application/zip\">\n      <ows:Identifier>result</ows:Identifier>\n    </wps:Output>\n  </wps:ResponseDocument>\n</wps:ResponseForm>\n

                                                                              Note <wps:ResponseDocument> contains a <wps:Output> instead of a <wps:RawDataOutput> being used by previous example. Moreover the attribute asReference set to true has been added to the <wps:Output>.

                                                                              This time, when issued (and process has finished on the server), the GET request returns the result to download as a link as part of <wps:Output><wps:Reference> .

                                                                              <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n  <wps:ExecuteResponse xmlns:xs=\"http://www.w3.org/2001/XMLSchema\" xmlns:ows=\"http://www.opengis.net/ows/1.1\" xmlns:wps=\"http://www.opengis.net/wps/1.0.0\" xmlns:xlink=\"http://www.w3.org/1999/xlink\" xml:lang=\"en\" service=\"WPS\" serviceInstance=\"http://127.0.0.1:8080/geoserver/ows?\" statusLocation=\"http://127.0.0.1:8080/geoserver/ows?service=WPS&amp;version=1.0.0&amp;request=GetExecutionStatus&amp;executionId=c1074100-446a-4963-94ad-cbbf8b8a7fd1\" version=\"1.0.0\">\n  <wps:Process wps:processVersion=\"1.0.0\">\n    <ows:Identifier>gs:Download</ows:Identifier>\n    <ows:Title>Enterprise Download Process</ows:Title>\n    <ows:Abstract>Downloads Layer Stream and provides a ZIP.</ows:Abstract>\n  </wps:Process>\n  <wps:Status creationTime=\"2016-08-08T11:38:34.024Z\">\n    <wps:ProcessSucceeded>Process succeeded.</wps:ProcessSucceeded>\n  </wps:Status>\n  <wps:ProcessOutputs>\n    <wps:Output>\n      <ows:Identifier>result</ows:Identifier>\n      <ows:Title>Zipped output files to download</ows:Title>\n      <wps:Reference href=\"http://127.0.0.1:8080/geoserver/ows?service=WPS&amp;version=1.0.0&amp;request=GetExecutionResult&amp;executionId=c1074100-446a-4963-94ad-cbbf8b8a7fd1&amp;outputId=result.zip&amp;mimetype=application%2Fzip\" mimeType=\"application/zip\" />\n    </wps:Output>\n  </wps:ProcessOutputs>\n</wps:ExecuteResponse>\n
                                                                              "},{"location":"extensions/wps-download/rawDownload/#output-format-and-response-mime-types","title":"Output Format and Response mime-types","text":"

                                                                              By default, downloading vector data results in a Shapefile, compressed in a zip file along with its SLD file. It's also possible to download a GeoPackage file using application/geopackage+sqlite3 as the value for the mimeType parameter.

                                                                              Similarly, for raster data, by default the downloaded raster gets zipped, along with the SLD style associated to the layer. In some cases, this can be unnecessary, especially if the output TIFF already has some type of internal compression or if we simply want to get back the TIFF output file without the ancillary SLD. Let's consider downloading a RGB TIFF: the default raster.sld style won't add anything useful to the output. In that case it's possible to specify image/tiff in the Response's output mimeType: the output TIFF will be provided as is, without extra steps of compression and file management.

                                                                              ...\n<wps:ResponseForm>\n  <wps:ResponseDocument storeExecuteResponse=\"true\" status=\"true\">\n    <wps:Output asReference=\"true\" mimeType=\"image/tiff\">\n      <ows:Identifier>result</ows:Identifier>\n    </wps:Output>\n  </wps:ResponseDocument>\n</wps:ResponseForm>\n

                                                                              It is also possible to download the raster data as a GeoPackage, using application/geopackage+sqlite3 as the value for the mimeType parameter.

                                                                              "},{"location":"extensions/wps-download/rawDownload/#writing-buffering-options","title":"Writing buffering options","text":"

                                                                              By default raster pixels are encoded using a file stream writing through a default 16KB data buffer. Depending on the network and disk setup, you might want to change the size of the buffer to improve performance. This can be done by adding this property to the JAVA_OPTS: -Dorg.geoserver.wps.download.raster.buffer.size=sizeinbytes where sizeinbytes is the actual value to be set, i.e. 1048576 to set a 1MB buffer.

                                                                              Moreover, when copying back data resources from within the WPS machinery to the final file output location, a default 16KB data buffer is being used. It's also possible to change the size of such buffer by adding this property to the JAVA_OPTS: -Dorg.geoserver.wps.copy.buffer.size=sizeinbytes where sizeinbytes is the actual value to be set, i.e. 1048576 to set a 1MB buffer.

                                                                              "},{"location":"extensions/wps-download/rawDownload/#writing_params","title":"Writing parameters","text":"

                                                                              The writeParameters input element of a process execution allows to specify parameters to be applied by the outputFormat encoder when producing the output file. Writing parameters are listed as multiple <dwn:Parameter key=\"writingParameterName\">value</dwn:Parameter> within a <dwn:Parameters> parent element. See the below xml containing full syntax of a valid example for TIFF output format:

                                                                              <wps:Input>\n  <ows:Identifier>writeParameters</ows:Identifier>\n    <wps:Data>\n       <wps:ComplexData xmlns:dwn=\"http://geoserver.org/wps/download\">\n         <dwn:Parameters>\n            <dwn:Parameter key=\"tilewidth\">128</dwn:Parameter>\n            <dwn:Parameter key=\"tileheight\">128</dwn:Parameter>\n            <dwn:Parameter key=\"compression\">JPEG</dwn:Parameter>\n            <dwn:Parameter key=\"quality\">0.75</dwn:Parameter>\n         </dwn:Parameters>\n       </wps:ComplexData>\n    </wps:Data>\n</wps:Input>\n
                                                                              "},{"location":"extensions/wps-download/rawDownload/#geotifftiff-supported-writing-parameters","title":"GeoTIFF/TIFF supported writing parameters","text":"

                                                                              The supported writing parameters are:

                                                                              • tilewidth : Width of internal tiles, in pixels
                                                                              • tileheight : Height of internal tiles, in pixels
                                                                              • compression : Compression type used to store internal tiles. Supported values are:
                                                                                • CCITT RLE (Lossless) (Huffman)
                                                                                • LZW (Lossless)
                                                                                • JPEG (Lossy)
                                                                                • ZLib (Lossless)
                                                                                • PackBits (Lossless)
                                                                                • Deflate (Lossless)
                                                                              • quality : Compression quality. Value is in the range [0 : 1]
                                                                                • for JPEG lossy compression, 0 is for worst quality/higher compression and 1 is for best quality/lower compression. (default is 1).
                                                                                • for Deflate lossless compression, input value in the range [0 : 1] is linearly mapped to output deflate level in the range [1 : 9]: (deflate level = 1 + 8 * (quality)), where level 1 is for best speed and level 9 is for best compression. (default level is 9)
                                                                              • writenodata : Supported value is one of true/false. Note that, by default, a nodata TAG is produced as part of the output GeoTIFF file as soon as a nodata is found in the GridCoverage2D to be written. Therefore, not specifying this parameter will result into writing nodata to preserve default behavior. Setting it to false will avoid writing that TAG.
                                                                              "},{"location":"extensions/wps-download/rawDownload/#direct-download","title":"Direct download","text":"

                                                                              The raster process does its best to identify downloads that are in fact selecting a single, complete source file, and will perform a straight copy of it in such case.

                                                                              Conditions:

                                                                              • A single, complete source file is selected by the request (e.g. full input GeoTIFF, or single full granule out of an image mosaic).
                                                                              • The output format matches the input (e.g. both GeoTIFF)
                                                                              • The write parameters, if present, match the structure of the input file (same compression, same tiling structure)

                                                                              In order to better support opportunities for direct download, it's possible to specify the write parameter compression as auto: it won't interfere with selection of a direct download, if possible, and will fall back to deflate in case the direct download is not possible.

                                                                              "},{"location":"extensions/wps-download/rawDownload/#heterogeneous_imagemosaic","title":"RasterDownload of Heterogeneous CRS ImageMosaic","text":"

                                                                              An ImageMosaic made of granules in different coordinate reference systems (i.e. several DEM files in different UTM zones) is defined as ImageMosaic with Heterogeneous CRS. The ImageMosaic layer will expose a common CRS as the native one (i.e. 4326).

                                                                              By default, mosaicking granules with different CRSs will result into a reprojection from the original CRS of the granules to that common CRS.

                                                                              Since 2.17, a new parameter has been defined: minimizeReprojections

                                                                              It will be used on Raster Download with a defined ROI and a TargetCRS being specified. When set to true, any Granule in the ROI having a nativeCRS matching the TargetCRS will not be affected by reprojection.

                                                                              Since 2.17, a new parameter has been defined: bestResolutionOnMatchingCRS

                                                                              It will be used when minimizeReprojections is enabled too, on Raster Download with a defined ROI and a TargetCRS, without target size being specified. When set to true, the download will aim to preserve the native properties of the underlying granules matching the targetCRS, as much as possible.

                                                                              Back to the example, a RasterDownload specifying UTM32N as TargetCRS and a ROI covering an area containing UTM32N granules will result into getting those UTM32N granules without applying any intermediate reprojection, also providing back best raw resolution available for that CRS. So, if the ImageMosaic is a mix of UTM32N DEMs at 10 km resolution and UTM33N at 100 m resolution, the underlying reading request will use 10 km resolution, being the best resolution available in the targetCRS. When no granules are matching the targetCRS, the best resolution is taken from all the granules.

                                                                              Make sure to configure the ImageMosaic's index to contain both crs and resolution attributes, in order to preserve as much as possible the native properties of the granules.

                                                                              A typical indexer.properties of such ImageMosaic will look like this:

                                                                              GranuleAcceptors=org.geotools.gce.imagemosaic.acceptors.HeterogeneousCRSAcceptorFactory\nGranuleHandler=org.geotools.gce.imagemosaic.granulehandler.ReprojectingGranuleHandlerFactory\nHeterogeneousCRS=true\nMosaicCRS=EPSG\\:XXXX\nSchema=*the_geom:Polygon,location:String,crs:String,resX:double,resY:double\nResolutionXAttribute=resX\nResolutionYAttribute=resY\nCrsAttribute=crs\nPropertyCollectors=CRSExtractorSPI(crs),ResolutionXExtractorSPI(resX),ResolutionYExtractorSPI(resY)\n
                                                                              "},{"location":"extensions/wps-download/rawDownload/#vertical_resampling","title":"Vertical data resampling on download","text":"

                                                                              Coverages containing elevations data (i.e. DTM/DEM/DSM) have pixel values representing elevations/heights referred to a specific VerticalCRS.

                                                                              The associated VerticalCRS can be specified in the layer configuration, at the very bottom of the page, where a new optional Vertical Coordinate Reference System section shows up.

                                                                              The following example shows a DSM layer being configured to specify EPSG:5778 as adopted VerticalCRS.

                                                                              This section will only show up if:

                                                                              • The wps-download module has been deployed in GeoServer
                                                                              • The underlying data is single-band and datatype is at least 16 bit. (i.e.: no Byte datatype, no RGB images, ...)
                                                                              "},{"location":"extensions/wps-download/rawDownload/#wps-download-vertical-resampling","title":"WPS Download - Vertical resampling","text":"

                                                                              Resampling the data to a different VerticalCRS as part of the Raster Download Process is possible by specifying the targetVerticalCRS parameter in the WPS Download request. For example:

                                                                              <wps:Input>\n  <ows:Identifier>targetVerticalCRS</ows:Identifier>\n  <wps:Data>\n    <wps:LiteralData>EPSG:9274</wps:LiteralData>\n  </wps:Data>\n</wps:Input>\n

                                                                              Note

                                                                              An exception will be thrown when specifying a targetVerticalCRS but no source VerticalCRS has been assigned to the requested layer through the above setting.

                                                                              "},{"location":"extensions/wps-download/rawDownload/#custom-verticalcrs-definitions-and-grid-transformations","title":"Custom VerticalCRS definitions and grid transformations","text":"

                                                                              Custom verticalCRS definitions can be specified in GeoServer via properties file as any other Coordinate Reference System, as explained in Custom CRS Definitions page.

                                                                              This is an example of the above VerticalCRS being added as a WKT in the user_projections/epsg.properties file:

                                                                              9274=VERT_CS[\"EVRF2000 Austria height\", \\\n   VERT_DATUM[\"European Vertical Reference Frame 2000 Austria\", \\\n     2000, AUTHORITY[\"EPSG\",\"1261\"]], \\\n   AXIS[\"gravity-related height (H)\",up], \\\n   UNIT[\"m\",1.0], \\\nAUTHORITY[\"EPSG\",\"9274\"]]\n

                                                                              Transformations between VerticalCRSs can be supported through Vertical Grid Offset files (similarly to how NTV2 Grid Shift can be used in support of 2D grid transformation).

                                                                              Custom Coordinate Operations are defined in user_projections/epsg_operations.properties file within the data directory (create it if it doesn't exist).

                                                                              Each line in epsg_operations.properties will describe a coordinate operation consisting of a source CRS, a target CRS, and a math transform with its parameter values. Use the following syntax:

                                                                              <source crs code>,<target crs code>=<WKT math transform>\n

                                                                              The Math Transform is a Vertical Offset by Grid Interpolation requiring 2 parameters:

                                                                              1. A Vertical offset file referring an offset file containing a vertical offset for each pixel of the grid. The referred file need to be available in the user_projections directory,
                                                                              2. An Interpolation CRS code containing the EPSG code of the 2D CoordinateReferenceSystem of the grid file.
                                                                              "},{"location":"extensions/wps-download/rawDownload/#example","title":"Example","text":"

                                                                              Custom Vertical Grid Shift file for the transformation between the above Vertical CRSs :

                                                                              5778,9274=PARAM_MT[\"Vertical Offset by Grid Interpolation\", \\\nPARAMETER[\"Vertical offset file\", \"GV_Hoehengrid_V1.tif\"], \\\nPARAMETER[\"Interpolation CRS code\", 4312]]\n

                                                                              Note

                                                                              Only GeoTIFF vertical offset files are supported at the moment. Vertical resampling will access pixels from that GeoTIFF using tiled loading. Therefore, make sure that the grid file is not striped (a gdalinfo call reporting Band 1 Block = NNN x 1 means a striped file. In that case, consider retiling it for better access before using it as a Vertical Offset File)

                                                                              "},{"location":"extensions/wps-jdbc/","title":"WPS JDBC","text":"

                                                                              The WPS JDBC extension is a WPS status storage for asynchronous requests. Main advantages are:

                                                                              • Asynchronous request status sharing among multiple GeoServer nodes
                                                                              • Ability to retain the status of completed requests even after the GeoServer(s) have been restarted.
                                                                              "},{"location":"extensions/wps-jdbc/#wpsjdbc_install","title":"Installing the WPS JDBC extension","text":"
                                                                              1. From the website download page, locate your release, and download: wps-jdbc

                                                                                Verify that the version number in the filename corresponds to the version of GeoServer you are running (for example 2.24.2 above).

                                                                              2. Extract the contents of the archive into the WEB-INF/lib directory in GeoServer. Make sure you do not create any sub-directories during the extraction process.

                                                                              3. Restart GeoServer.

                                                                              "},{"location":"extensions/wps-jdbc/#configuring-the-wps-jdbc-properties","title":"Configuring the WPS JDBC properties","text":"
                                                                              1. Create a file named jdbcstatusstore.props into the GEOSERVER_DATA_DIR root

                                                                              2. Update the sample content below accordingly to your connection parameters

                                                                                user=postgres\nport=5432\npassword=******\npasswd=******\nhost=localhost\ndatabase=gsstore\ndriver=org.postgresql.Driver\ndbtype=postgis\n
                                                                              3. Restart GeoServer

                                                                              "},{"location":"extensions/wps-jdbc/#share-the-wps-execution-directory-among-the-cluster-nodes","title":"Share the WPS Execution Directory among the cluster nodes","text":"

                                                                              Typically the WPS JDBC plugin is useful when setting up a GeoServer cluster.

                                                                              The plugin allows sharing of the execution status among the nodes of the cluster.

                                                                              Nevertheless, this won't be sufficient. You will need to share the Execution folder too, in order to allow the different instances to correctly retrieve the executions results.

                                                                              1. Create a shared folder that all the nodes can reach somehow, e.g. by using nfs
                                                                              2. From the GeoServer Admin dashboard, go to the WPS menu and edit the Resource Storage Directory accordingly

                                                                              WPS JDBC shared Resource Storage Directory

                                                                              "},{"location":"filter/","title":"Filtering","text":"

                                                                              Filtering allows selecting features that satisfy a specific set of conditions. Filters can be used in several contexts in GeoServer:

                                                                              • in WMS requests, to select which features should be displayed on a map
                                                                              • in WFS requests, to specify the features to be returned
                                                                              • in SLD documents, to apply different symbolization to features on a thematic map.
                                                                              • Supported filter languages
                                                                              • Filter Encoding Reference
                                                                              • ECQL Reference
                                                                              • Filter functions
                                                                              • Filter Function Reference
                                                                              "},{"location":"filter/ecql_reference/","title":"ECQL Reference","text":"

                                                                              This section provides a reference for the syntax of the ECQL language. The full language grammar is documented in the GeoTools ECQL BNF definition

                                                                              "},{"location":"filter/ecql_reference/#syntax-notes","title":"Syntax Notes","text":"

                                                                              The sections below describe the major language constructs. Each construct lists all syntax options for it. Each option is defined as a sequence of other constructs, or recursively in terms of itself.

                                                                              • Symbols which are part of the ECQL language are shown in code font. All other symbols are part of the grammar description.
                                                                              • ECQL keywords are not case-sensitive.
                                                                              • A vertical bar symbol '|' indicates that a choice of keyword can be made.
                                                                              • Brackets '[ ... ]' delimit syntax that is optional.
                                                                              • Braces '{ ... }' delimit syntax that may be present zero or more times.
                                                                              "},{"location":"filter/ecql_reference/#ecql_cond","title":"Condition","text":"

                                                                              A filter condition is a single predicate, or a logical combination of other conditions.

                                                                              Syntax Description Predicate Single predicate expression Condition AND OR Condition NOT Condition Negation of a condition ( [ Condition ]"},{"location":"filter/ecql_reference/#ecql_pred","title":"Predicate","text":"

                                                                              Predicates are boolean-valued expressions which specify relationships between values.

                                                                              Syntax Description Expression = <> Expression [ NOT ] BETWEEN Expression AND Expression Tests whether a value lies in or outside a range (inclusive) Expression [ NOT ] LIKE ILIKE like-pattern Attribute [ NOT ] IN ( Expression { ,Expression } ) Tests whether an attribute value is (not) in a set of values. [ NOT ] IN ( Literal { ,Literal } ) Tests whether a feature ID value is (not) in a given set. ID values are integers or string literals Expression IS [ NOT ] NULL Tests whether a value is (non-)null Attribute EXISTS ** ** DOES-NOT-EXIST INCLUDE EXCLUDE"},{"location":"filter/ecql_reference/#ecql_temp","title":"Temporal Predicate","text":"

                                                                              Temporal predicates specify the relationship of a time-valued expression to a time or time period.

                                                                              Syntax Description ecql_expr BEFORE Time <ecql_reference.rst#ecql_literal>_ Tests whether a time value is before a point in time Expression BEFORE OR DURING Time Period Tests whether a time value is before or during a time period Expression DURING Time Period Tests whether a time value is during a time period Expression DURING OR AFTER Time Period Tests whether a time value is during or after a time period ecql_expr AFTER Time <ecql_reference.rst#ecql_literal>_ Tests whether a time value is after a point in time"},{"location":"filter/ecql_reference/#ecql_spat","title":"Spatial Predicate","text":"

                                                                              Spatial predicates specify the relationship between geometric values. Topological spatial predicates (INTERSECTS, DISJOINT, CONTAINS, WITHIN, TOUCHES CROSSES, OVERLAPS and RELATE) are defined in terms of the DE-9IM model described in the OGC Simple Features for SQL specification.

                                                                              Syntax Description INTERSECTS(Expression , Expression ) Tests whether two geometries intersect. The converse of DISJOINT DISJOINT(Expression , Expression ) Tests whether two geometries are disjoint. The converse of INTERSECTS CONTAINS(Expression , Expression ) Tests whether the first geometry topologically contains the second. The converse of WITHIN WITHIN(Expression , Expression ) Tests whether the first geometry is topologically within the second. The converse of CONTAINS TOUCHES(Expression , Expression ) Tests whether two geometries touch. Geometries touch if they have at least one point in common, but their interiors do not intersect. CROSSES(Expression , Expression ) Tests whether two geometries cross. Geometries cross if they have some but not all interior points in common OVERLAPS(Expression , Expression ) Tests whether two geometries overlap. Geometries overlap if they have the same dimension, have at least one point each not shared by the other, and the intersection of the interiors of the two geometries has the same dimension as the geometries themselves EQUALS(Expression , Expression ) Tests whether two geometries are topologically equal RELATE( Expression , Expression , pattern ) Tests whether geometries have the spatial relationship specified by a DE-9IM matrix pattern. A DE-9IM pattern is a string of length 9 specified using the characters *TF012. Example: '1*T***T**' DWITHIN( Expression , Expression , distance , units ) Tests whether the distance between two geometries is no more than the specified distance. distance is an unsigned numeric value for the distance tolerance. units is one of feet, meters, statute miles, nautical miles, kilometers BEYOND( Expression , Expression , distance , units ) Similar to DWITHIN, but tests whether the distance between two geometries is greater than the given distance. BBOX ( Expression , Number , Number , Number , Number [ , CRS ] ) Tests whether a geometry intersects a bounding box specified by its minimum and maximum X and Y values. The optional CRS is a string containing an SRS code (For example, 'EPSG:1234'. The default is to use the CRS of the queried layer)"},{"location":"filter/ecql_reference/#ecql_expr","title":"Expression","text":"

                                                                              An expression specifies a attribute, literal, or computed value. The type of the value is determined by the nature of the expression. The standard PEMDAS order of evaluation is used.

                                                                              Syntax Description Attribute Name of a feature attribute Literal Literal value Expression + - function ( [ Expression { , Expression } ] ) Value computed by evaluation of a filter function with zero or more arguments. ( | [ Expression ] | ) Bracketing with ( or ```` controls evaluation order"},{"location":"filter/ecql_reference/#ecql_attr","title":"Attribute","text":"

                                                                              An attribute name denotes the value of a feature attribute.

                                                                              • Simple attribute names are sequences of letters and numbers, e.g. [States123``
                                                                              • Attribute names quoted with double-quotes may be any sequence of characters, e.g. \\\"States!@#\\\"
                                                                              • Note: id is one of a few reserved keywords in ECQL and thus an attribute (or database column) named id must be quoted, e.g. \\\"id\\\"
                                                                              "},{"location":"filter/ecql_reference/#ecql_literal","title":"Literal","text":"

                                                                              Literals specify constant values of various types.

                                                                              Type Description Number Integer or floating-point number. Scientific notation is supported. Boolean TRUE or FALSE String String literal delimited by single quotes. To include a single quote in the string use two single-quotes: '' Geometry Geometry in WKT or EWKT format. WKT is defined in the OGC Simple Features for SQL specification. All standard geometry types are supported: POINT, LINESTRING, POLYGON, MULTIPOINT, MULTILINESTRING, MULTIPOLYGON, GEOMETRYCOLLECTION. EWKT allows specifying a geometry spatial reference system by prefixing it with a numerical code, in the form SRID=number;WKT, for example, SRID=4326;POINT (1 2). A custom type of Envelope is also supported with syntax ENVELOPE ( x1 x2 y1 y2 ). Time A UTC date/time value in the format yyyy-mm-hhThh:mm:ss. The seconds value may have a decimal fraction. The time zone may be specified as Z or +/-hh:mm. Example: 2006-11-30T00:30:00Z Duration A time duration specified as P [ y Y m M d D ] T [ h H m M s S ]. The duration can be specified to any desired precision by including only the required year, month, day, hour, minute and second components. Examples: P1Y2M, P4Y2M20D, P4Y2M1DT20H3M36S"},{"location":"filter/ecql_reference/#ecql_period","title":"Time Period","text":"

                                                                              Specifies a period of time, in several different formats.

                                                                              Syntax Description Time / Time Period specified by a start and end time Duration / Time Period specified by a duration before a given time Time / Duration Period specified by a duration after a given time"},{"location":"filter/filter_reference/","title":"Filter Encoding Reference","text":"

                                                                              This is a reference for the Filter Encoding language implemented in GeoServer. The Filter Encoding language uses an XML-based syntax. It is defined by the OGC Filter Encoding standard.

                                                                              Filters are used to select features or other objects from the context in which they are evaluated. They are similar in functionality to the SQL \"WHERE\" clause. A filter is specified using a condition.

                                                                              "},{"location":"filter/filter_reference/#filter_condition","title":"Condition","text":"

                                                                              A condition is a single Predicate element, or a combination of conditions by Logical operators.

                                                                              "},{"location":"filter/filter_reference/#filter_predicate","title":"Predicate","text":"

                                                                              Predicates are boolean-valued expressions which compute relationships between values. A predicate is specified by using a comparison operator or a spatial operator. The operators are used to compare properties of the features being filtered to other feature properties or to literal data.

                                                                              "},{"location":"filter/filter_reference/#comparison-operators","title":"Comparison operators","text":"

                                                                              Comparison operators are used to specify conditions on non-spatial attributes.

                                                                              "},{"location":"filter/filter_reference/#binary-comparison-operators","title":"Binary Comparison operators","text":"

                                                                              The binary comparison operators are:

                                                                              • <PropertyIsEqualTo>
                                                                              • <PropertyIsNotEqualTo>
                                                                              • <PropertyIsLessThan>
                                                                              • <PropertyIsLessThanOrEqualTo>
                                                                              • <PropertyIsGreaterThan>
                                                                              • <PropertyIsGreaterThanOrEqualTo>

                                                                              They contain the elements:

                                                                              Element Required? Description Expression Yes The first value to compare. Often a <PropertyName>. Expression Yes The second value to compare

                                                                              Binary comparison operator elements may include an optional matchCase attribute, with the value true or false. If this attribute is true (the default), string comparisons are case-sensitive. If the attribute is false strings comparisons do not check case.

                                                                              "},{"location":"filter/filter_reference/#propertyislike-operator","title":"PropertyIsLike operator","text":"

                                                                              The <PropertyIsLike> operator matches a string property value against a text pattern. It contains the elements:

                                                                              Element Required? Description <PropertyName> Yes Contains a string specifying the name of the property to test <Literal> Yes Contains a pattern string to be matched

                                                                              The pattern is specified by a sequence of regular characters and three special pattern characters. The pattern characters are defined by the following required attributes of the <PropertyIsLike> element:

                                                                              • wildCard specifies the pattern character which matches any sequence of zero or more string characters
                                                                              • singleChar specifies the pattern character which matches any single string character
                                                                              • escapeChar specifies the escape character which can be used to escape the pattern characters
                                                                              "},{"location":"filter/filter_reference/#propertyisnull-operator","title":"PropertyIsNull operator","text":"

                                                                              The <PropertyIsNull> operator tests whether a property value is null. It contains the element:

                                                                              Element Required? Description <PropertyName> Yes contains a string specifying the name of the property to be tested"},{"location":"filter/filter_reference/#propertyisbetweeen-operator","title":"PropertyIsBetweeen operator","text":"

                                                                              The <PropertyIsBetween> operator tests whether an expression value lies within a range given by a lower and upper bound (inclusive). It contains the elements:

                                                                              Element Required? Description Expression Yes The value to test <LowerBoundary> Yes Contains an Expression giving the lower bound of the range <UpperBoundary> Yes Contains an Expression giving the upper bound of the range"},{"location":"filter/filter_reference/#spatial-operators","title":"Spatial operators","text":"

                                                                              Spatial operators are used to specify conditions on the geometric attributes of a feature. The following spatial operators are available:

                                                                              "},{"location":"filter/filter_reference/#topological-operators","title":"Topological operators","text":"

                                                                              These operators test topological spatial relationships using the standard OGC Simple Features predicates:

                                                                              • <Intersects> - Tests whether two geometries intersect
                                                                              • <Disjoint> - Tests whether two geometries are disjoint (do not interact)
                                                                              • <Contains> - Tests whether a geometry contains another one
                                                                              • <Within> - Tests whether a geometry is within another one
                                                                              • <Touches> - Tests whether two geometries touch
                                                                              • <Crosses> - Tests whether two geometries cross
                                                                              • <Overlaps> - Tests whether two geometries overlap
                                                                              • <Equals> - Tests whether two geometries are topologically equal

                                                                              These contains the elements:

                                                                              Element Required? Description <PropertyName> Yes Contains a string specifying the name of the geometry-valued property to be tested. GML Geometry Yes A GML literal value specifying the geometry to test against"},{"location":"filter/filter_reference/#distance-operators","title":"Distance operators","text":"

                                                                              These operators test distance relationships between a geometry property and a geometry literal:

                                                                              • <DWithin>
                                                                              • <Beyond>

                                                                              They contain the elements:

                                                                              Element Required? Description <PropertyName> Yes Contains a string specifying the name of the property to be tested. If omitted, the default geometry attribute is assumed. GML Geometry Yes A literal value specifying a geometry to compute the distance to. This may be either a geometry or an envelope in GML 3 format <Distance> Yes Contains the numeric value for the distance tolerance. The element may include an optional units attribute."},{"location":"filter/filter_reference/#bounding-box-operator","title":"Bounding Box operator","text":"

                                                                              The <BBOX> operator tests whether a geometry-valued property intersects a fixed bounding box. It contains the elements:

                                                                              Element Required? Description <PropertyName> No Contains a string specifying the name of the property to be tested. If omitted, the default geometry attribute is assumed. <gml:Box> Yes A GML Box literal value specifying the bounding box to test against"},{"location":"filter/filter_reference/#examples","title":"Examples","text":"
                                                                              • This filter selects features with a geometry that intersects the point (1,1).
                                                                              <Intersects>\n  <PropertyName>GEOMETRY</PropertyName>\n  <gml:Point>\n    <gml:coordinates>1 1</gml:coordinates>\n  </gml:Point>\n</Intersects>\n
                                                                              • This filter selects features with a geometry that overlaps a polygon.
                                                                              <Overlaps>\n  <PropertyName>Geometry</PropertyName>\n  <gml:Polygon srsName=\"http://www.opengis.net/gml/srs/epsg.xml#63266405\">\n    <gml:outerBoundaryIs>\n      <gml:LinearRing>\n         <gml:posList> ... </gml:posList>\n      </gml:LinearRing>\n    </gml:outerBoundaryIs>\n  </gml:Polygon>\n </Overlaps>\n
                                                                              • This filter selects features with a geometry that intersects the geographic extent [-10,0 : 10,10].
                                                                              <BBOX>\n  <PropertyName>GEOMETRY</PropertyName>\n  <gml:Box srsName=\"urn:x-ogc:def:crs:EPSG:4326\">\n    <gml:coord>\n      <gml:X>-10</gml:X> <gml:Y>0</gml:Y>\n    </gml:coord>\n    <gml:coord>\n      <gml:X>10</gml:X> <gml:Y>10</gml:Y>\n    </gml:coord>\n  </gml:Box>\n</BBOX>\n
                                                                              "},{"location":"filter/filter_reference/#filter_logical","title":"Logical operators","text":"

                                                                              Logical operators are used to specify logical combinations of Condition elements (which may be either Predicate elements or other logical operators). They may be nested to any depth.

                                                                              The following logical operators are available:

                                                                              • <And> - computes the logical conjunction of the operands
                                                                              • <Or> - computes the logical disjunction of the operands

                                                                              The content for <And> and <Or> is two operands given by Condition elements.

                                                                              • <Not> - computes the logical negation of the operand

                                                                              The content for <Not> is a single operand given by a Condition element.

                                                                              "},{"location":"filter/filter_reference/#examples_1","title":"Examples","text":"
                                                                              • This filter uses <And> to combine a comparison predicate and a spatial predicate:
                                                                              <And>\n   <PropertyIsEqualTo>\n      <PropertyName>NAME</PropertyName>\n      <Literal>New York</Literal>\n   </PropertyIsEqualTo>\n   <Intersects>\n      <PropertyName>GEOMETRY</PropertyName>\n      <Literal>\n         <gml:Point>\n             <gml:coordinates>1 1</gml:coordinates>\n         </gml:Point>\n      </Literal>\n   </Intersects>\n</And>\n
                                                                              "},{"location":"filter/filter_reference/#filter_expression","title":"Expression","text":"

                                                                              Filter expressions specify constant, variable or computed data values. An expression is formed from one of the following elements (some of which contain sub-expressions, meaning that expressions may be of arbitrary depth):

                                                                              "},{"location":"filter/filter_reference/#arithmetic-operators","title":"Arithmetic operators","text":"

                                                                              The arithmetic operator elements compute arithmetic operations on numeric values.

                                                                              • <Add> - adds the two operands
                                                                              • <Sub> - subtracts the second operand from the first
                                                                              • <Mul> - multiplies the two operands
                                                                              • <Div> - divides the first operand by the second

                                                                              Each arithmetic operator element contains two Expression elements providing the operands.

                                                                              "},{"location":"filter/filter_reference/#function","title":"Function","text":"

                                                                              The <Function> element specifies a filter function to be evaluated. The required name attribute gives the function name. The element contains a sequence of zero or more Expression elements providing the values of the function arguments.

                                                                              See the Filter Function Reference for details of the functions provided by GeoServer.

                                                                              "},{"location":"filter/filter_reference/#property-value","title":"Property Value","text":"

                                                                              The <PropertyName> element refers to the value of a feature attribute. It contains a string or an XPath expression specifying the attribute name.

                                                                              "},{"location":"filter/filter_reference/#literal","title":"Literal","text":"

                                                                              The <Literal> element specifies a constant value. It contains data of one of the following types:

                                                                              Type Description Numeric A string representing a numeric value (integer or decimal). Boolean A boolean value of true or false. String A string value. XML-incompatible text may be included by using character entities or <![CDATA[ ]]> delimiters. Date A string representing a date. Geometry An element specifying a geometry in GML3 format."},{"location":"filter/filter_reference/#wfs-20-namespaces","title":"WFS 2.0 namespaces","text":"

                                                                              WFS 2.0 does not depend on any one GML version and thus requires an explicit namespace and schemaLocation for GML. In a GET request, namespaces can be placed on a Filter element (that is, filter= the block below, URL-encoded):

                                                                              <fes:Filter\n        xmlns:fes=\"http://www.opengis.net/fes/2.0\"\n        xmlns:gml=\"http://www.opengis.net/gml/3.2\">\n    <fes:Not>\n        <fes:Disjoint>\n            <fes:ValueReference>sf:the_geom</fes:ValueReference>\n            <gml:Polygon\n                    gml:id=\"polygon.1\"\n                    srsName='http://www.opengis.net/def/crs/EPSG/0/26713'>\n                <gml:exterior>\n                    <gml:LinearRing>\n                        <gml:posList>590431 4915204 590430\n                            4915205 590429 4915204 590430\n                            4915203 590431 4915204</gml:posList>\n                    </gml:LinearRing>\n                </gml:exterior>\n            </gml:Polygon>\n        </fes:Disjoint>\n    </fes:Not>\n</fes:Filter>\n
                                                                              "},{"location":"filter/function/","title":"Filter functions","text":"

                                                                              The OGC Filter Encoding specification provides a generic concept of a filter function. A filter function is a named function with any number of arguments, which can be used in a filter expression to perform specific calculations. This provides much richer expressiveness for defining filters. Filter functions can be used in both the XML Filter Encoding language and the textual ECQL language, using the syntax appropriate to the language.

                                                                              GeoServer provides many different kinds of filter functions, covering a wide range of functionality including mathematics, string formatting, and geometric operations. A complete list is provided in the Filter Function Reference.

                                                                              Note

                                                                              The Filter Encoding specification provides a standard syntax for filter functions, but does not mandate a specific set of functions. Servers are free to provide whatever functions they want, so some function expressions may work only in specific software.

                                                                              "},{"location":"filter/function/#examples","title":"Examples","text":"

                                                                              The following examples show how filter functions are used. The first shows enhanced WFS filtering using the geometryType function. The second shows how to use functions in SLD to get improved label rendering.

                                                                              "},{"location":"filter/function/#wfs-filtering","title":"WFS filtering","text":"

                                                                              Let's assume we have a feature type whose geometry field, geom, can contain any kind of geometry. For a certain application we need to extract only the features whose geometry is a simple point or a multipoint. This can be done using a GeoServer-specific filter function named geometryType. Here is the WFS request including the filter function:

                                                                              <wfs:GetFeature service=\"WFS\" version=\"1.0.0\"\n  outputFormat=\"GML2\"\n  xmlns:wfs=\"http://www.opengis.net/wfs\"\n  xmlns:ogc=\"http://www.opengis.net/ogc\"\n  xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\"\n  xsi:schemaLocation=\"http://www.opengis.net/wfs\n                      http://schemas.opengis.net/wfs/1.0.0/WFS-basic.xsd\">\n  <wfs:Query typeName=\"sf:archsites\">\n    <ogc:Filter>\n       <ogc:PropertyIsEqualTo>\n          <ogc:Function name=\"geometryType\">\n             <ogc:PropertyName>geom</ogc:PropertyName>\n          </ogc:Function>\n          <ogc:Literal>Point</ogc:Literal>\n       </ogc:PropertyIsEqualTo>\n    </ogc:Filter>\n    </wfs:Query>\n</wfs:GetFeature>\n
                                                                              "},{"location":"filter/function/#wfs-20-namespaces","title":"WFS 2.0 namespaces","text":"

                                                                              WFS 2.0 does not depend on any one GML version and thus requires an explicit namespace and schemaLocation for GML. This POST example selects features using a spatial query. Note the complete declaration of namespace prefixes. In a GET request, namespaces can be placed on a Filter element.

                                                                              <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<wfs:GetFeature service=\"WFS\" version=\"2.0.0\"\n    xmlns:wfs=\"http://www.opengis.net/wfs/2.0\"\n    xmlns:fes=\"http://www.opengis.net/fes/2.0\"\n    xmlns:gml=\"http://www.opengis.net/gml/3.2\"\n    xmlns:sf=\"http://www.openplans.org/spearfish\"\n    xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\"\n    xsi:schemaLocation=\"http://www.opengis.net/wfs/2.0\n                        http://schemas.opengis.net/wfs/2.0/wfs.xsd\n                        http://www.opengis.net/gml/3.2\n                        http://schemas.opengis.net/gml/3.2.1/gml.xsd\">\n    <wfs:Query typeNames=\"sf:bugsites\">\n        <fes:Filter>\n            <fes:Not>\n                <fes:Disjoint>\n                    <fes:ValueReference>sf:the_geom</fes:ValueReference>\n                    <!-- gml:id is mandatory on GML 3.2 geometry elements -->\n                    <gml:Polygon\n                            gml:id=\"polygon.1\"\n                            srsName='http://www.opengis.net/def/crs/EPSG/0/26713'>\n                        <gml:exterior>\n                            <gml:LinearRing>\n                                <!-- pairs must form a closed ring -->\n                                <gml:posList>590431 4915204 590430\n                                    4915205 590429 4915204 590430\n                                    4915203 590431 4915204</gml:posList>\n                            </gml:LinearRing>\n                        </gml:exterior>\n                    </gml:Polygon>\n                </fes:Disjoint>\n            </fes:Not>\n        </fes:Filter>\n    </wfs:Query>\n</wfs:GetFeature>\n
                                                                              "},{"location":"filter/function/#sld-formatting","title":"SLD formatting","text":"

                                                                              We want to display elevation labels in a contour map. The elevations are stored as floating point values, so the raw numeric values may display with unwanted decimal places (such as \"150.0\" or \"149.999999\"). We want to ensure the numbers are rounded appropriately (i.e. to display \"150\"). To achieve this the numberFormat filter function can be used in the SLD label content expression:

                                                                              ...\n<TextSymbolizer>\n  <Label>\n    <ogc:Function name=\"numberFormat\">\n      <ogc:Literal>##</ogc:Literal>\n      <ogc:PropertyName>ELEVATION</ogc:PropertyName>\n    </ogc:Function>\n  </Label>\n  ...\n</TextSymbolizer>\n...\n
                                                                              "},{"location":"filter/function/#performance-implications","title":"Performance implications","text":"

                                                                              Using filter functions in SLD symbolizer expressions does not have significant overhead, unless the function is performing very heavy computation.

                                                                              However, using functions in WFS filtering or SLD rule expressions may cause performance issues in certain cases. This is usually because specific filter functions are not recognized by a native data store filter encoder, and thus GeoServer must execute the functions in memory instead.

                                                                              For example, given a filter like BBOX(geom,-10,30,20,45) and geometryType(geom) = 'Point' most data stores will split the filter into two separate parts. The bounding box filter will be encoded as a primary filter and executed in SQL, while the geometryType function will be executed in memory on the results coming from the primary filter.

                                                                              "},{"location":"filter/function_reference/","title":"Filter Function Reference","text":"

                                                                              This reference describes all filter functions that can be used in WFS/WMS filtering or in SLD expressions.

                                                                              The list of functions available on a GeoServer instance can be determined by browsing to http://localhost:8080/geoserver/wfs?request=GetCapabilities and searching for ogc:Function_Names (WFS 1.0.0), ogc:FunctionNames (WFS 1.1.0), or fes:Functions (WFS 2.0.0) in the returned XML. If a function is described in the Capabilities document but is not in this reference, then it might mean that the function cannot be used for filtering, or that it is new and has not been documented. Ask for details on the user mailing list.

                                                                              Unless otherwise specified, none of the filter functions in this reference are understood natively by the data stores, and thus expressions using them will be evaluated in-memory.

                                                                              "},{"location":"filter/function_reference/#function-argument-type-reference","title":"Function argument type reference","text":"Type Description Double Floating point number, 8 bytes, IEEE 754. Ranges from 4.94065645841246544e-324d to 1.79769313486231570e+308d Float Floating point number, 4 bytes, IEEE 754. Ranges from 1.40129846432481707e-45 to 3.40282346638528860e+38. Smaller range and less accurate than Double. Integer Integer number, ranging from -2,147,483,648 to 2,147,483,647 Long Integer number, ranging from -9,223,372,036,854,775,808 to +9,223,372,036,854,775,807 Number A numeric value of any type Object A value of any type String A sequence of characters Timestamp Date and time information"},{"location":"filter/function_reference/#comparison-functions","title":"Comparison functions","text":"Name Arguments Description between num:Number, low:Number, high:Number returns true if low <= num <= high equalTo a:Object, b:Object Can be used to compare for equality two numbers, two strings, two dates, and so on greaterEqualThan x:Object, y:Object Returns true if x >= y. Parameters can be either numbers or strings (in the second case lexicographic ordering is used) greaterThan x:Object, y:Object Returns true if x > y. Parameters can be either numbers or strings (in the second case lexicographic ordering is used) in2, in3, in4, in5, in6, in7, in8, in9, in10 candidate:Object, v1:Object, ..., v9:Object Returns true if candidate is equal to one of the v1, ..., v9 values. Use the function name matching the number of arguments specified. in candidate:Object, v1:Object, v2:Object, ... Works exactly the same as the in2, ..., in10 functions described above, but takes any number of values as input. isLike string:String, pattern:String Returns true if the string matches the specified pattern. For the full syntax of the pattern specification see the Java Pattern class javadocs isNull obj:Object Returns true the passed parameter is null, false otherwise lessThan x:Object, y:Object Returns true if x < y. Parameters can be either numbers or strings (in the second case lexicographic ordering is used lessEqualThan x:Object, y:Object Returns true if x <= y. Parameters can be either numbers or strings (in the second case lexicographic ordering is used not bool:Boolean Returns the negation of bool notEqualTo x:Object, y:Object Returns true if x and y are equal, false otherwise"},{"location":"filter/function_reference/#control-functions","title":"Control functions","text":"Name Arguments Description if_then_else condition:Boolean, x:Object, y: Object Returns x if the condition is true, y otherwise"},{"location":"filter/function_reference/#environment-function","title":"Environment function","text":"

                                                                              This function returns the value of environment variables defined in various contexts. WMS GetMap automatically defines some variables SLD rendering, while others can be provided using the env request parameter. Example usage in e.g. a dynamic symbolizer:

                                                                              ${env('size', 20)}

                                                                              Example usage in a default Symbolizer:

                                                                              <PointSymbolizer uom=\"http://www.opengeospatial.org/se/units/metre\">\n  <Graphic>\n  ...\n    <Size>\n      <ogc:Function name=\"env\">\n        <ogc:Literal>size</ogc:Literal>\n        <ogc:Literal>20</ogc:Literal>\n      </ogc:Function>\n    </Size>\n  </Graphic>\n</PointSymbolizer>\n
                                                                              Name Arguments Description env variable:String Returns the value of the environment variable variable."},{"location":"filter/function_reference/#feature-functions","title":"Feature functions","text":"Name Arguments Description id feature:Feature returns the identifier of the feature PropertyExists f:Feature, propertyName:String Returns true if f has a property named propertyName property f:Feature, propertyName:String Returns the value of the property propertyName. Allows property names to be computed or specified by Variable substitution in SLD. mapGet f:Feature, map:Map, key:String Get the value of the map map related to the specified key."},{"location":"filter/function_reference/#spatial-relationship-functions","title":"Spatial Relationship functions","text":"

                                                                              For more information about the precise meaning of the spatial relationships consult the OGC Simple Feature Specification for SQL

                                                                              Name Arguments Description contains a:Geometry, b:Geometry Returns true if the geometry a contains b crosses a:Geometry, b:Geometry Returns true if a crosses b disjoint a:Geometry, b:Geometry Returns true if the two geometries are disjoint, false otherwise equalsExact a:Geometry, b:Geometry Returns true if the two geometries are exactly equal, same coordinates in the same order equalsExactTolerance a:Geometry, b:Geometry, tol:Double Returns true if the two geometries are exactly equal, same coordinates in the same order, allowing for a tol distance in the corresponding points intersects a:Geometry, b:Geometry Returns true if a intersects b isWithinDistance a: Geometry, b:Geometry, distance: Double Returns true if the distance between a and b is less than distance (measured as an euclidean distance) overlaps a: Geometry, b:Geometry Returns true a overlaps with b relate a: Geometry, b:Geometry Returns the DE-9IM intersection matrix for a and b relatePattern a: Geometry, b:Geometry, pattern:String Returns true if the DE-9IM intersection matrix for a and b matches the specified pattern touches a: Geometry, b: Geometry Returns true if a touches b according to the SQL simple feature specification rules within a: Geometry, b:Geometry Returns true is fully contained inside b"},{"location":"filter/function_reference/#geometric-functions","title":"Geometric functions","text":"Name Arguments Description area geometry:Geometry The area of the specified geometry. Works in a Cartesian plane, the result will be in the same unit of measure as the geometry coordinates (which also means the results won't make any sense for geographic data) boundary geometry:Geometry Returns the boundary of a geometry boundaryDimension geometry:Geometry Returns the number of dimensions of the geometry boundary buffer geometry:Geometry, distance:Double Returns the buffered area around the geometry using the specified distance bufferWithSegments geometry:Geometry, distance:Double, segments:Integer Returns the buffered area around the geometry using the specified distance and using the specified number of segments to represent a quadrant of a circle. centroid geometry:Geometry Returns the centroid of the geometry. Can be often used as a label point for polygons, though there is no guarantee it will actually lie inside the geometry convexHull geometry:Geometry Returns the convex hull of the specified geometry difference a:Geometry, b:Geometry Returns all the points that sit in a but not in b dimension a:Geometry Returns the dimension of the specified geometry distance a:Geometry, b:Geometry Returns the euclidean distance between the two geometries endAngle line:LineString Returns the angle of the end segment of the linestring endPoint line:LineString Returns the end point of the linestring envelope geometry:geometry Returns the polygon representing the envelope of the geometry, that is, the minimum rectangle with sides parallels to the axis containing it exteriorRing poly:Polygon Returns the exterior ring of the specified polygon geometryType geometry:Geometry Returns the type of the geometry as a string. May be Point, MultiPoint, LineString, LinearRing, MultiLineString, Polygon, MultiPolygon, GeometryCollection geomFromWKT wkt:String Returns the Geometry represented in the Well Known Text format contained in the wkt parameter geomLength geometry:Geometry Returns the length/perimeter of this geometry (computed in Cartesian space) getGeometryN collection:GeometryCollection, n:Integer Returns the n-th geometry inside the collection getX p:Point Returns the x ordinate of p getY p:Point Returns the y ordinate of p getZ p:Point Returns the z ordinate of p interiorPoint geometry:Geometry Returns a point that is either interior to the geometry, when possible, or sitting on its boundary, otherwise interiorRingN polyg:Polygon, n:Integer Returns the n-th interior ring of the polygon intersection a:Geometry, b:Geometry Returns the intersection between a and b. The intersection result can be anything including a geometry collection of heterogeneous, if the result is empty, it will be represented by an empty collection. isClosed line: LineString Returns true if line forms a closed ring, that is, if the first and last coordinates are equal isEmpty geometry:Geometry Returns true if the geometry does not contain any point (typical case, an empty geometry collection) isometric geometry:Geometry, extrusion:Double Returns a MultiPolygon containing the isometric extrusions of all components of the input geometry. The extrusion distance is extrusion, expressed in the same unit as the geometry coordinates. Can be used to get a pseudo-3d effect in a map isRing line:LineString Returns true if the line is actually a closed ring (equivalent to isRing(line) and isSimple(line)) isSimple line:LineString Returns true if the geometry self intersects only at boundary points isValid geometry: Geometry Returns true if the geometry is topologically valid (rings are closed, holes are inside the hull, and so on) numGeometries collection: GeometryCollection Returns the number of geometries contained in the geometry collection numInteriorRing poly: Polygon Returns the number of interior rings (holes) inside the specified polygon numPoint geometry: Geometry Returns the number of points (vertexes) contained in geometry offset geometry: Geometry, offsetX:Double, offsetY:Double Offsets all points in a geometry by the specified X and Y offsets. Offsets are working in the same coordinate system as the geometry own coordinates. pointN geometry: Geometry, n:Integer Returns the n-th point inside the specified geometry startAngle line: LineString Returns the angle of the starting segment of the input linestring startPoint line: LineString Returns the starting point of the input linestring symDifference a: Geometry, b:Geometry Returns the symmetrical difference between a and b (all points that are inside a or b, but not both) toWKT geometry: Geometry Returns the WKT representation of geometry union a: Geometry, b:Geometry Returns the union of a and b (the result may be a geometry collection) vertices geom: Geometry Returns a multi-point made with all the vertices of geom"},{"location":"filter/function_reference/#math-functions","title":"Math functions","text":"Name Arguments Description abs value:Integer The absolute value of the specified Integer value abs_2 value:Long The absolute value of the specified Long value abs_3 value:Float The absolute value of the specified Float value abs_4 value:Double The absolute value of the specified Double value acos angle:Double Returns the arc cosine of an angle in radians, in the range of 0.0 through PI asin angle:Double Returns the arc sine of an angle in radians, in the range of -PI / 2 through PI / 2 atan angle:Double Returns the arc tangent of an angle in radians, in the range of -PI/2 through PI/2 atan2 x:Double, y:Double Converts a rectangular coordinate (x, y) to polar (r, theta) and returns theta. ceil x: Double Returns the smallest (closest to negative infinity) double value that is greater than or equal to x and is equal to a mathematical integer. cos angle: Double Returns the cosine of an angle expressed in radians double2bool x: Double Returns true if x is zero, false otherwise exp x: Double Returns Euler's number e raised to the power of x floor x: Double Returns the largest (closest to positive infinity) value that is less than or equal to x and is equal to a mathematical integer IEEERemainder x: Double, y:Double Computes the remainder of x divided by y as prescribed by the IEEE 754 standard int2bbool x: Integer Returns true if x is zero, false otherwise int2ddouble x: Integer Converts x to a Double log x: Integer Returns the natural logarithm (base e) of x max, max_3, max_4 x1: Double, x2:Double, x3:Double, x4:Double Returns the maximum between x1, ..., x4 min, min_3, min_4 x1: Double, x2:Double, x3:Double, x4:Double Returns the minimum between x1, ..., x4 pi None Returns an approximation of pi, the ratio of the circumference of a circle to its diameter pow base:Double, exponent:Double Returns the value of base raised to the power of exponent random None Returns a Double value with a positive sign, greater than or equal to 0.0 and less than 1.0. Returned values are chosen pseudo-randomly with (approximately) uniform distribution from that range. rint x:Double Returns the Double value that is closest in value to the argument and is equal to a mathematical integer. If two double values that are mathematical integers are equally close, the result is the integer value that is even. round_2 x:Double Same as round, but returns a Long round x:Double Returns the closest Integer to x. The result is rounded to an integer by adding \u00bd, taking the floor of the result, and casting the result to type Integer. In other words, the result is equal to the value of the expression (int)floor(a + 0.5) roundDouble x:Double Returns the closest Long to x sin angle: Double Returns the sine of an angle expressed in radians tan angle:Double Returns the trigonometric tangent of angle expressed in radians toDegrees angle:Double Converts an angle expressed in radians into degrees toRadians angle:Double Converts an angle expressed in radians into degrees"},{"location":"filter/function_reference/#string-functions","title":"String functions","text":"

                                                                              String functions generally will accept any type of value for String arguments. Non-string values will be converted into a string representation automatically.

                                                                              Name Arguments Description Concatenate s1:String, s2:String, ... Concatenates any number of strings. Non-string arguments are allowed. strAbbreviate sentence:String, lower:Integer, upper:Integer, append:String Abbreviates the sentence at first space beyond lower (or at upper if no space). Appends append if string is abbreviated. strCapitalize sentence:String Fully capitalizes the sentence. For example, \"HoW aRe YOU?\" will be turned into \"How Are You?\" strConcat a:String, b:String Concatenates the two strings into one strDefaultIfBlank str:String, default:String returns default if str is empty, blank or null strEndsWith string:String, suffix:String Returns true if string ends with suffix strEqualsIgnoreCase a:String, b:String Returns true if the two strings are equal ignoring case considerations strIndexOf string:String, substring:String Returns the index within this string of the first occurrence of the specified substring, or -1 if not found strLastIndexOf string:String, substring:String Returns the index within this string of the last occurrence of the specified substring, or -1 if not found strLength string:String Returns the string length strMatches string:String, pattern:String Returns true if the string matches the specified regular expression. For the full syntax of the pattern specification see the Java Pattern class javadocs strReplace string:String, pattern:String, replacement:String, global: boolean Returns the string with the pattern replaced with the given replacement text. If the global argument is true then all occurrences of the pattern will be replaced, otherwise only the first. For the full syntax of the pattern specification see the Java Pattern class javadocs strStartsWith string:String, prefix:String Returns true if string starts with prefix strStripAccents string:String Removes diacritics (\\~= accents) from a string. The case will not be altered. strSubstring string:String, begin:Integer, end:Integer Returns a new string that is a substring of this string. The substring begins at the specified begin and extends to the character at index endIndex - 1 (indexes are zero-based). strSubstringStart string:String, begin:Integer Returns a new string that is a substring of this string. The substring begins at the specified begin and extends to the last character of the string strToLowerCase string:String Returns the lower case version of the string strToUpperCase string:String Returns the upper case version of the string strTrim string:String Returns a copy of the string, with leading and trailing blank-space omitted"},{"location":"filter/function_reference/#parsing-and-formatting-functions","title":"Parsing and formatting functions","text":"Name Arguments Description dateFormat format:String, date:Timestamp Formats the specified date according to the provided format. The format syntax can be found in the Java SimpleDateFormat javadocs dateParse format:String, dateString:String Parses a date from a dateString formatted according to the format specification. The format syntax can be found in the Java SimpleDateFormat javadocs numberFormat format:String, number:Double, locale:String Formats the number according to the specified format using the default locale or the one provided as an optional argument. The format syntax can be found in the Java DecimalFormat javadocs parseBoolean boolean:String Parses a string into a boolean. The empty string, f, 0.0 and 0 are considered false, everything else is considered true. parseDouble number:String Parses a string into a double. The number can be expressed in normal or scientific form. parseInt number:String Parses a string into an integer. parseLong number:String Parses a string into a long integer"},{"location":"filter/function_reference/#temporal-functions","title":"Temporal functions","text":"Name Arguments Description dateDifference a:Date, b:Date, timeUnits:String Computes the difference between two date (as a-b) and return a result in a specific time units. timeUnits is optional, representing the desired time units result. Default as milliseconds. Possible values are s (seconds), m (minutes), h (hours), d (days). now None Returns the current time as a Date"},{"location":"filter/function_reference/#transformation-functions","title":"Transformation functions","text":"

                                                                              Transformation functions transform values from one data space into another. These functions provide a concise way to compute styling parameters from feature attribute values. See also Styling using Transformation Functions.

                                                                              +-------------+----------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Name | Arguments | Description | +-------------+----------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Recode | lookupValue:Object, | Transforms a lookupValue from a set of discrete data values into another set of values. Any number of data/value pairs may be specified. | | | | | | | data:Object, value:Object, ... | | +-------------+----------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Categorize | lookupValue:Object, value:Object, | Transforms a continuous-valued attribute value into a set of discrete values. lookupValue and value must be an orderable type (typically numeric). The initial value is required. Any number of additional threshold/value pairs may be specified. belongsTo is optional, with the value succeeding or preceding. It defines which interval to use when the lookup value equals a threshold value. | | | | | | | threshold:Object, ... value:Object, | | | | | | | | belongsTo : String | | +-------------+----------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Interpolate | lookupValue:Numeric, | Transforms a continuous-valued attribute value into another continuous range of values. Any number of data/value pairs may be specified. mode is optional, with the value linear, cosine or cubic. It defines the interpolation algorithm to use. method is optional, with the value numeric or color. It defines whether the target values are numeric or RGB color specifications. | | | | | | | data:Numeric, value:Numeric or #RRGGBB, ... | | | | | | | | mode:String, method:String | | +-------------+----------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+

                                                                              "},{"location":"filter/syntax/","title":"Supported filter languages","text":"

                                                                              Data filtering in GeoServer is based on the concepts found in the OGC Filter Encoding Specification.

                                                                              GeoServer accepts filters encoded in two different languages: Filter Encoding and Common Query Language.

                                                                              "},{"location":"filter/syntax/#filter-encoding","title":"Filter Encoding","text":"

                                                                              The Filter Encoding language is an XML-based method for defining filters. XML Filters can be used in the following places in GeoServer:

                                                                              • in WMS GetMap requests, using the filter parameter
                                                                              • in WFS GetFeature requests, using the filter parameter
                                                                              • in SLD Rules, in the Filter element

                                                                              The Filter Encoding language is defined by OGC Filter Encoding Standards:

                                                                              • Filter Encoding 1.0 is used in WFS 1.0 and SLD 1.0
                                                                              • Filter Encoding 1.1 is used in WFS 1.1
                                                                              • Filter Encoding 2.0 is used in WFS 2.0
                                                                              "},{"location":"filter/syntax/#cqlecql","title":"CQL/ECQL","text":"

                                                                              CQL (Common Query Language) is a plain-text language created for the OGC Catalog specification. GeoServer has adapted it to be an easy-to-use filtering mechanism. GeoServer actually implements a more powerful extension called ECQL (Extended CQL), which allows expressing the full range of filters that OGC Filter 1.1 can encode. ECQL is accepted in many places in GeoServer:

                                                                              • in WMS GetMap requests, using the cql_filter parameter
                                                                              • in WFS GetFeature requests, using the cql_filter parameter
                                                                              • in SLD dynamic symbolizers

                                                                              The ECQL Reference describes the features of the ECQL language. The CQL and ECQL tutorial shows examples of defining filters.

                                                                              The CQL and ECQL languages are defined in:

                                                                              • OpenGIS Catalog Services Specification contains the standard definition of CQL
                                                                              • ECQL Grammar is the grammar defining the GeoTools ECQL implementation
                                                                              "},{"location":"geowebcache/","title":"GeoWebCache","text":"

                                                                              GeoWebCache is a tiling server. It runs as a proxy between a map client and map server, caching (storing) tiles as they are requested, eliminating redundant request processing and thus saving large amounts of processing time. GeoWebCache is integrated with GeoServer, though it is also available as a standalone product for use with other map servers.

                                                                              This section will discuss the version of GeoWebCache integrated with GeoServer. The first part will be show how GeoWebCache can be configured through the web admin interface, followed by a detailed discussion of the concepts of the.

                                                                              For information about the standalone product, please see the GeoWebCache homepage.

                                                                              • GeoWebCache settings
                                                                              • Using GeoWebCache
                                                                              • Configuration
                                                                              • Seeding and refreshing
                                                                              • HTTP Response Headers
                                                                              • GeoWebCache REST API
                                                                              • Troubleshooting
                                                                              "},{"location":"geowebcache/config/","title":"Configuration","text":"

                                                                              GeoWebCache is automatically configured for use with GeoServer using the most common options, with no setup required. All communication between GeoServer and GeoWebCache happens by passing messages inside the JVM.

                                                                              By default, all layers served by GeoServer will be known to GeoWebCache. See the Tile Layers page to test the configuration.

                                                                              Note

                                                                              Version 2.2.0 of GeoServer introduced changes to the configuration of the integrated GeoWebCache.

                                                                              "},{"location":"geowebcache/config/#integrated-user-interface","title":"Integrated user interface","text":"

                                                                              GeoWebCache has a full integrated web-based configuration. See the GeoWebCache settings section in the Web administration interface.

                                                                              "},{"location":"geowebcache/config/#determining-tiled-layers","title":"Determining tiled layers","text":"

                                                                              In versions of GeoServer prior to 2.2.0, the GeoWebCache integration was done in a such way that every GeoServer layer and layer group was forced to have an associated GeoWebCache tile layer. In addition, every such tile layer was forcedly published in the EPSG:900913 and EPSG:4326 gridsets with PNG and JPEG output formats.

                                                                              It is possible to selectively turn caching on or off for any layer served through GeoServer. This setting can be configured in the Tile Layers section of the Web administration interface.

                                                                              "},{"location":"geowebcache/config/#configuration-files","title":"Configuration files","text":"

                                                                              It is possible to configure most aspects of cached layers through the GeoWebCache settings section in the Web administration interface or the GeoWebCache REST API.

                                                                              GeoWebCache keeps the configuration for each GeoServer tiled layer separately, inside the <data_dir>/gwc-layers/ directory. There is one XML file for each tile layer. These files contain a different syntax from the <wmsLayer> syntax in the standalone version and are not meant to be edited by hand. Instead you can configure tile layers on the Tile Layers page or through the GeoWebCache REST API.

                                                                              Configuration for the defined gridsets is saved in <data_dir>/gwc/geowebcache.xml` so that the integrated GeoWebCache can continue to serve externally-defined tile layers from WMS services outside GeoServer.

                                                                              If upgrading from a version prior to 2.2.0, a migration process is run which creates a tile layer configuration for all the available layers and layer groups in GeoServer with the old defaults. From that point on, you should configure the tile layers on the Tile Layers page.

                                                                              "},{"location":"geowebcache/config/#changing-the-cache-directory","title":"Changing the cache directory","text":"

                                                                              GeoWebCache will automatically store cached tiles in a gwc directory inside your GeoServer data directory. To set a different directory, stop GeoServer (if it is running) and add the following code to your GeoServer web.xml file (located in the WEB-INF directory):

                                                                              <context-param>\n   <param-name>GEOWEBCACHE_CACHE_DIR</param-name>\n   <param-value>C:\\temp</param-value>\n</context-param>\n

                                                                              Change the path inside <param-value> to the desired cache path (such as C:\\temp or /tmp). Restart GeoServer when done.

                                                                              Note

                                                                              Make sure GeoServer has write access in this directory.

                                                                              "},{"location":"geowebcache/config/#geowebcache-with-multiple-geoserver-instances","title":"GeoWebCache with multiple GeoServer instances","text":"

                                                                              For stability reasons, it is not recommended to use the embedded GeoWebCache with multiple GeoServer instances. If you want to configure GeoWebCache as a front-end for multiple instances of GeoServer, we recommend using the standalone GeoWebCache.

                                                                              "},{"location":"geowebcache/config/#gwc_data_security","title":"GeoServer Data Security","text":"

                                                                              GWC Data Security is an option that can be turned on and turned off through the Caching defaults page. By default it is turned off.

                                                                              When turned on, the embedded GWC will do a data security check before calling GeoWebCache, i.e. verify whether the user actually has access to the layer, and reject the request if this is not the case. In the case of WMS-C requests, there is also limited support for data access limit filters, only with respect to geographic boundaries (all other types of data access limits will be ignored). The embedded GWC will reject requests for which the requested bounding box is (partly) inaccessible. It is only possible to request a tile within a bounding box that is fully accessible. This behaviour is different from the regular WMS, which will filter the data before serving it. However, if the integrated WMS/WMS-C is used, the request will be forwarded back to WMS and give the desired result.

                                                                              When using the default GeoServer security system, rules cannot combine data security with service security. However, when using a security subsystem it may be possible to make such particular combinations. In this case the WMS-C service inherits all security rules from the regular WMS service; while all other GWC services will get their security from rules associated with the 'GWC' service itself.

                                                                              "},{"location":"geowebcache/config/#configuring-in-memory-caching","title":"Configuring In Memory Caching","text":"

                                                                              GWC In Memory Caching is a new feature which allows to cache GWC tiles in memory reducing their access time. User can also choose to avoid to store the files on the disk if needed. For enabling/disabling these features the user may see the related section on the TileCaching Caching defaults page.

                                                                              Actually there are only two Caching methods:

                                                                              • Guava Caching
                                                                              • Hazelcast Caching
                                                                              "},{"location":"geowebcache/config/#guava-cache","title":"Guava Cache","text":"

                                                                              Guava Cache provides a local in-memory cache to use for a single GeoServer instance. For configuring Guava Caching the user must only edit the configuration parameters in the Caching Defaults page.

                                                                              "},{"location":"geowebcache/config/#hazelcast-cache","title":"Hazelcast Cache","text":"

                                                                              Hazelcast is an open-source API for distributed structures like clusters. GWC supports this API for creating a distributed in memory cache. At the time of writing, Hazelcast requires the installation of the gs-gwc-distributed plugin in the WEB_INF/lib directory of your geoserver application. This plugin can be found at the following link.

                                                                              There are 2 ways for configuring distributed caching in GWC:

                                                                              • Using an XML file called hazelcast.xml. This file must be located in a directory indicated by the JVM parameter hazelcast.config.dir
                                                                              • Directly, by configuring a bean inside the GeoServer application context

                                                                              Both the 2 configurations should define the following parameters:

                                                                              1. The Hazelcast configuration requires a Map object with name CacheProviderMap
                                                                              2. Map eviction policy must be LRU or LFU
                                                                              3. Map configuration must have a fixed size defined in Mb
                                                                              4. Map configuration must have USED_HEAP_SIZE as MaxSizePolicy

                                                                              Warning

                                                                              Be careful that all the cluster instances have the same configuration, because different configurations may result in incorrect Hazelcast behaviour.

                                                                              Warning

                                                                              In order to avoid missing tiles, the cluster instances should access the same data.

                                                                              "},{"location":"geowebcache/config/#configuration-with-hazelcastxml","title":"Configuration with hazelcast.xml","text":"

                                                                              Here can be found an example file:

                                                                              <hazelcast xmlns=\"http://www.hazelcast.com/schema/config\"\n           xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\"\n           xsi:schemaLocation=\"http://www.hazelcast.com/schema/config\n                               https://hazelcast.com/schema/config/hazelcast-config-5.3.xsd\">\n  <cluster-name>gsCacheCluster</cluster-name>\n\n  <network>\n    <!--\n        Typical usage: multicast enabled with port auto-increment enabled\n        or tcp-ip enabled with port auto-increment disabled. Note that you \n        must choose between multicast and tcp-ip. Another option could be\n        aws, but will not be described here.\n\n    -->\n    <port auto-increment=\"false\">5701</port>\n        <join>\n             <multicast enabled=\"false\">\n                <multicast-group>224.2.2.3</multicast-group>\n                <multicast-port>54327</multicast-port>\n            </multicast>\n            <tcp-ip enabled=\"true\">\n                <interface>192.168.1.32</interface>     \n                <interface>192.168.1.110</interface> \n            </tcp-ip>\n        </join>\n  </network>\n\n  <map name=\"CacheProviderMap\">\n        <eviction eviction-policy=\"LRU\" max-size-policy=\"USED_HEAP_SIZE\" size=\"16\" />\n  </map>\n\n</hazelcast>\n
                                                                              "},{"location":"geowebcache/config/#configuration-with-applicationcontext","title":"Configuration with ApplicationContext","text":"

                                                                              For configuring caching directly from the GeoServer application context, the user must edit the file geowebcache-distributed.xml inside the gs-gwc jar file. More informations about using Spring with Hazelcast can be found in the Hazelcast related documentation. The modified application context is presented below:

                                                                              <hz:hazelcast id=\"instance1\">\n    <hz:config>\n        <hz:group name=\"dev\" password=\"password\" />\n        <hz:network port=\"5701\" port-auto-increment=\"true\">\n            <hz:join>\n                <hz:multicast enabled=\"true\" multicast-group=\"224.2.2.3\"\n                    multicast-port=\"54327\" />\n            <hz:tcp-ip enabled=\"false\">\n              <hz:members>10.10.1.2, 10.10.1.3</hz:members>\n            </hz:tcp-ip>\n            </hz:join>\n        </hz:network>\n        <hz:map name=\"CacheProviderMap\" max-size=\"16\" eviction-policy=\"LRU\"\n            max-size-policy=\"USED_HEAP_SIZE\" />\n    </hz:config>\n</hz:hazelcast>\n\n<bean id=\"HazelCastLoader1\"\n    class=\"org.geowebcache.storage.blobstore.memory.distributed.HazelcastLoader\">\n    <property name=\"instance\" ref=\"instance1\" />\n</bean>\n\n<bean id=\"HazelCastCacheProvider1\"\n    class=\"org.geowebcache.storage.blobstore.memory.distributed.HazelcastCacheProvider\">\n    <constructor-arg ref=\"HazelCastLoader1\" />\n</bean>\n
                                                                              "},{"location":"geowebcache/config/#optional-configuration-parameters","title":"Optional configuration parameters","text":"

                                                                              In this section are described other available configuration parameters to configure:

                                                                              • Cache expiration time:

                                                                                <map name=\"CacheProviderMap\">\n...\n\n    <time-to-live-seconds>0</time-to-live-seconds>\n    <max-idle-seconds>0</max-idle-seconds>\n\n</map>\n

                                                                                Where time-to-live-seconds indicates how many seconds an entry can stay in cache and max-idle-seconds indicates how many seconds an entry may be not accessed before being evicted.

                                                                              • Near Cache.

                                                                                <map name=\"CacheProviderMap\">\n...\n<near-cache>\n  <!--\n    Same configuration parameters of the Hazelcast Map. Note that size indicates the maximum number of \n    entries in the near cache. A value of Integer.MAX_VALUE indicates no limit on the maximum \n    size.\n  -->\n  <time-to-live-seconds>0</time-to-live-seconds>\n  <max-idle-seconds>60</max-idle-seconds>\n  <eviction eviction-policy=\"LRU\" size=\"5000\" />\n\n  <!--\n    Indicates if a cached entry can be evicted if the same value is modified in the Hazelcast Map. Default is true.\n  -->\n  <invalidate-on-change>true</invalidate-on-change>\n\n  <!--\n    Indicates if local entries must be cached. Default is false.\n  -->\n  <cache-local-entries>false</cache-local-entries>\n</near-cache>\n\n</map>  \n

                                                                                Near Cache is a local cache for each cluster instance which is used for caching entries in the other cluster instances. This behaviour avoids requesting those entries each time by executing a remote call. This feature could be helpful in order to improve Hazelcast Cache performance.

                                                                                ::: note ::: title Note :::

                                                                                A value of max-size bigger or equal to Integer.MAX_VALUE cannot be used in order to avoid an uncontrollable growth of the cache size. :::

                                                                              "},{"location":"geowebcache/responseheaders/","title":"HTTP Response Headers","text":"

                                                                              The GeoWebCache integrated with GeoServer employs special information stored in the header of responses. These headers are available either with direct calls to the GeoWebCache endpoint or with direct WMS integration.

                                                                              "},{"location":"geowebcache/responseheaders/#custom-response-headers","title":"Custom response headers","text":"

                                                                              GeoWebCache returns both standard and custom HTTP response headers when serving a tile request. This aids in the debugging process, as well as adhering to an HTTP 1.1 transfer control mechanism.

                                                                              The response headers can be determined via a utility such as cURL.

                                                                              "},{"location":"geowebcache/responseheaders/#example","title":"Example","text":"

                                                                              Note

                                                                              For all cURL commands below, make sure to replace >/dev/null with >nul if you are running on Windows.

                                                                              This is a sample request and response using cURL:

                                                                              curl -v \"http://localhost:8080/geoserver/gwc/service/wms?LAYERS=sde%3Abmworld&FORMAT=image%2Fpng&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&STYLES=&SRS=EPSG%3A4326&BBOX=-180,-38,-52,90&WIDTH=256&HEIGHT=256&tiled=true\" > /dev/null \n
                                                                              < HTTP/1.1 200 OK\n< geowebcache-tile-index: [0, 1, 2]\n< geowebcache-cache-result: HIT\n< geowebcache-tile-index: [0, 1, 2]\n< geowebcache-tile-bounds: -180.0,-38.0,-52.0,90.0\n< geowebcache-gridset: GlobalCRS84Pixel\n< geowebcache-crs: EPSG:4326\n< Content-Type: image/png\n< Content-Length: 102860\n< Server: Jetty(6.1.8)\n

                                                                              From this, one can learn that the tile was found in the cache (HIT), the requested tile was from the gridset called GlobalCRS84Pixel and had a CRS of EPSG:4326.

                                                                              "},{"location":"geowebcache/responseheaders/#list-of-custom-response-headers","title":"List of custom response headers","text":"

                                                                              The following is the full list of custom response headers. Whenever GeoWebCache serves a tile request, it will write some or all of the following custom headers on the HTTP response.

                                                                              +----------------------------+----------------------------------------------------------------------------------------------------------------------------------------+ | Response Header | Description | +============================+========================================================================================================================================+ | geowebcache-cache-result | Shows whether the GeoWebCache WMS was used. Options are: | | | | | | - HIT: Tile requested was found on the cache | | | - MISS: Tile was not found on the cache but was acquired from the layer's data source | | | - WMS: Request was proxied directly to the origin WMS (for example, for GetFeatureInfo requests) | | | - OTHER: Response was the default white/transparent tile or an error occurred | +----------------------------+----------------------------------------------------------------------------------------------------------------------------------------+ | geowebcache-tile-index | Contains the three-dimensional tile index in x,y,z order of the returned tile image in the corresponding grid space (e.g. [1, 0, 0]) | +----------------------------+----------------------------------------------------------------------------------------------------------------------------------------+ | geowebcache-tile-bounds | Bounds of the returned tile in the corresponding coordinate reference system (e.g. -180,-90,0,90) | +----------------------------+----------------------------------------------------------------------------------------------------------------------------------------+ | geowebcache-gridset | Name of the gridset the tile belongs to (see Gridsets for more information) | +----------------------------+----------------------------------------------------------------------------------------------------------------------------------------+ | geowebcache-crs | Coordinate reference system code of the matching gridset (e.g. EPSG:900913, EPSG:4326, etc). | +----------------------------+----------------------------------------------------------------------------------------------------------------------------------------+

                                                                              "},{"location":"geowebcache/responseheaders/#gwc_lastmodifiedheaders","title":"Last-Modified and If-Modified-Since","text":"

                                                                              Well behaved HTTP 1.1 clients and server applications can make use of Last-Modified and If-Modified-Since HTTP control mechanisms to know when locally cached content is up to date, eliminating the need to download the same content again. This can result in considerable bandwidth savings. (See HTTP 1.1 RFC 2616, sections 14.29 and 14.25, for more information on these mechanisms.)

                                                                              GeoWebCache will write a Last-Modified HTTP response header when serving a tile image. The date is written as an RFC-1123 HTTP-Date:

                                                                              Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT\n

                                                                              Clients connecting to GeoWebCache can create a \"conditional GET\" request with the If-Modified-Since request header. If the tile wasn't modified after the date specified in the Last-Modified response header, GeoWebCache will return a 304 status code indicating that the resource was available and not modified.

                                                                              "},{"location":"geowebcache/responseheaders/#example_1","title":"Example","text":"

                                                                              A query for a specific tile returns the Last-Modified response header:

                                                                              curl -v \"http://localhost:8080/geoserver/gwc/service/wms?LAYERS=img%20states&FORMAT=image%2Fpng&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&STYLES=&EXCEPTIONS=application%2Fvnd.ogc.se_inimage&SRS=EPSG%3A4326&BBOX=-135,45,-90,90&WIDTH=256&HEIGHT=256\" >/dev/null\n
                                                                              > Host: localhost:8080\n> Accept: */*\n>\n< HTTP/1.1 200 OK\n...\n< Last-Modified: Wed, 25 Jul 2012 00:42:00 GMT\n< Content-Type: image/png\n< Content-Length: 31192\n

                                                                              This request has the If-Modified-Since header set to one second after what was returned by Last-Modified:

                                                                              curl --header \"If-Modified-Since: Wed, 25 Jul 2012 00:42:01 GMT\" -v \"http://localhost:8080/geoserver/gwc/service/wms?LAYERS=img%20states&FORMAT=image%2Fpng&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&STYLES=&EXCEPTIONS=application%2Fvnd.ogc.se_inimage&SRS=EPSG%3A4326&BBOX=-135,45,-90,90&WIDTH=256&HEIGHT=256\" >/dev/null\n
                                                                              > Host: localhost:8080\n> Accept: */*\n> If-Modified-Since: Wed, 25 Jul 2012 00:42:01 GMT\n> \n< HTTP/1.1 304 Not Modified\n< Last-Modified: Wed, 25 Jul 2012 00:42:00 GMT\n< Content-Type: image/png\n< Content-Length: 31192\n

                                                                              The response code is 304. As the file hasn't been modified since the time specified in the request, no content is actually transferred. The client is informed that its copy of the tile is up to date.

                                                                              However, if you were to set the If-Modified-Since header to before the time stored in Last-Modified, you will instead receive a 200 status code and the tile will be downloaded.

                                                                              This example sets the If-Modified-Since header to one second before what was returned by Last-Modified:

                                                                              curl --header \"If-Modified-Since: Wed, 25 Jul 2012 00:41:59 GMT\" -v \"http://localhost:8080/geoserver/gwc/service/wms?LAYERS=img%20states&FORMAT=image%2Fpng&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&STYLES=&EXCEPTIONS=application%2Fvnd.ogc.se_inimage&SRS=EPSG%3A4326&BBOX=-135,45,-90,90&WIDTH=256&HEIGHT=256\" >/dev/null\n
                                                                              > Host: localhost:8080\n> Accept: */*\n> If-Modified-Since: Wed, 25 Jul 2012 00:41:59 GMT\n> \n< HTTP/1.1 200 OK\n...\n< Last-Modified: Wed, 25 Jul 2012 00:42:00 GMT\n< Content-Type: image/png\n< Content-Length: 31192\n
                                                                              "},{"location":"geowebcache/seeding/","title":"Seeding and refreshing","text":"

                                                                              The primary benefit to GeoWebCache is that it allows for the acceleration of normal WMS tile request processing by eliminating the need for the tiles to be regenerated for every request. This page discusses tile generation.

                                                                              You can configure seeding processes via the Web administration interface. See the Tile Layers page for more information.

                                                                              "},{"location":"geowebcache/seeding/#generating-tiles","title":"Generating tiles","text":"

                                                                              There are two ways for tiles to be generated by GeoWebCache. The first way for tiles to be generated is during normal map viewing. In this case, tiles are cached only when they are requested from a client, either through map browsing (such as in OpenLayers) or through manual WMS tile requests. The first time a map view is requested it will be roughly at the same speed as a standard GeoServer WMS request. The second and subsequent map viewings will be greatly accelerated as those tiles will have already been generated. The main advantage to this method is that it requires no preprocessing, and that only the data that has been requested will be cached, thus potentially saving disk space as well. The disadvantage to this method is that map viewing will be only intermittently accelerated, reducing the quality of user experience.

                                                                              The other way for tiles to be generated is by seeding. Seeding is the process where map tiles are generated and cached internally from GeoWebCache. When processed in advance, the user experience is greatly enhanced, as the user never has to wait for tiles to be generated. The disadvantage to this process is that seeding can be a very time- and disk-consuming process.

                                                                              In practice, a combination of both methods are usually used, with certain zoom levels (or certain areas of zoom levels) seeded, and the less-likely-viewed tiles are left uncached.

                                                                              "},{"location":"geowebcache/troubleshooting/","title":"Troubleshooting","text":"

                                                                              This section will discuss some common issues with the integrated GeoWebCache and their solutions.

                                                                              "},{"location":"geowebcache/troubleshooting/#grid-misalignment","title":"Grid misalignment","text":"

                                                                              Sometimes errors will occur when requesting data from GeoWebCache endpoints. The error displayed might say that the \"resolution is not supported\" or the \"bounds do not align.\" This is due to the client making WMS requests that do not align with the grid of tiles that GeoWebCache has created, such as differing map bounds or layer bounds, or an unsupported resolution. If you are using OpenLayers as a client, looking at the source code of the included demos may provide more clues to matching up the grid.

                                                                              An alternative workaround is to enable direct WMS integration with the GeoServer WMS. You can set this on the Caching defaults page.

                                                                              "},{"location":"geowebcache/troubleshooting/#direct-wms-integration","title":"Direct WMS integration","text":"

                                                                              Direct integration allows WMS requests served through GeoServer to be cached as if they were received and processed by GeoWebCache. With Direct WMS Integration, a request may either be handled by the GeoServer WMS or GeoWebCache WMS.

                                                                              Sometimes requests that should go to GeoWebCache will instead be passed through to GeoServer, resulting in no tiles saved. That said, it is possible to determine why a request was not handled by GeoWebCache when intended. This is done by using the command-line utility cURL and inspecting the response headers.

                                                                              First, obtain a sample request. This can easily be done by going to the Layer Preview for a given layer, setting the Tiled parameter to Tiled, then right-clicking on an area of the map and copy the full path to the image location. If done correctly, the result will be a GET request that looks something like this:

                                                                              http://localhost:8090/geoserver/nurc/wms?LAYERS=nurc%3AArc_Sample&STYLES=&FORMAT=image%2Fjpeg&TILED=true&TILESORIGIN=-180%2C-90&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&SRS=EPSG%3A4326&BBOX=-45,-45,0,0&WIDTH=256&HEIGHT=256\n

                                                                              You can then paste this URL into a curl request:

                                                                              curl -v \"URL\"\n

                                                                              For example:

                                                                              curl -v \"http://localhost:8090/geoserver/nurc/wms?LAYERS=nurc%3AArc_Sample&STYLES=&FORMAT=image%2Fjpeg&TILED=true&TILESORIGIN=-180%2C-90&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&SRS=EPSG%3A4326&BBOX=-45,-45,0,0&WIDTH=256&HEIGHT=256\"\n

                                                                              Note

                                                                              To omit the raw image output to the terminal, pipe the output to your system's null. On Linux / OS X, append > /dev/null to these requests, and on Windows, append > nul.

                                                                              If the request doesn't go through GeoWebCache's WMS, a reason will be given in a custom response header. Look for the following response headers:

                                                                              • geowebcache-cache-result: Will say HIT if the GeoWebCache WMS processed the request, and MISS otherwise.
                                                                              • geowebcache-miss-reason: If the above shows as MISS, this will generated a short description of why the request wasn't handled by the GeoWebCache WMS.

                                                                              The following are some example requests made along with the responses. These responses have been truncated to show only the information relevant for troubleshooting.

                                                                              "},{"location":"geowebcache/troubleshooting/#successful-request","title":"Successful request","text":"

                                                                              This request was successfully handled by the GeoWebCache WMS.

                                                                              Request:

                                                                              curl -v \"http://localhost:8080/geoserver/topp/wms?TILED=true&LAYERS=states&FORMAT=image/png&REQUEST=GetMap&STYLES=&SRS=EPSG:4326&BBOX=-135,45,-112.5,67.5&WIDTH=256&HEIGHT=256\"\n

                                                                              Response:

                                                                              < HTTP/1.1 200 OK\n< Content-Type: image/png\n< geowebcache-crs: EPSG:4326\n...\n< geowebcache-layer: topp:states\n< geowebcache-gridset: EPSG:4326\n< geowebcache-tile-index: [2, 6, 3]\n...\n< geowebcache-cache-result: HIT\n< geowebcache-tile-bounds: -135.0,45.0,-112.5,67.5\n...\n
                                                                              "},{"location":"geowebcache/troubleshooting/#wrong-height-parameter","title":"Wrong height parameter","text":"

                                                                              The following request is not handled by the GeoWebCache WMS because the image requested (256x257) does not conform to the expected 256x256 tile size.

                                                                              Request:

                                                                              curl -v \"http://localhost:8080/geoserver/topp/wms?TILED=true&LAYERS=states&FORMAT=image/png&REQUEST=GetMap&STYLES=&SRS=EPSG:4326&BBOX=-135,45,-112.5,67.5&WIDTH=256&HEIGHT=257\"\n

                                                                              Response:

                                                                              < HTTP/1.1 200 OK\n< Content-Type: image/png\n< geowebcache-miss-reason: request does not align to grid(s) 'EPSG:4326' \n...\n
                                                                              "},{"location":"geowebcache/troubleshooting/#no-tile-layer-associated","title":"No tile layer associated","text":"

                                                                              The following request is not handled by the GeoWebCache WMS because the layer requested has no tile layer configured.

                                                                              Request:

                                                                              curl -v \"http://localhost:8080/geoserver/topp/wms?TILED=true&LAYERS=tasmania_roads&FORMAT=image/png&REQUEST=GetMap&STYLES=&SRS=EPSG:4326&BBOX=-135,45,-112.5,67.5&WIDTH=256&HEIGHT=256\"\n

                                                                              Response:

                                                                              < HTTP/1.1 200 OK\n< Content-Type: image/png\n< geowebcache-miss-reason: not a tile layer\n...\n
                                                                              "},{"location":"geowebcache/troubleshooting/#missing-parameter-filter","title":"Missing parameter filter","text":"

                                                                              The following request is not handled by the GeoWebCache WMS because the request contains a parameter filter (BGCOLOR) that is not configured for this layer.

                                                                              Request:

                                                                              curl -v \"http://localhost:8080/geoserver/topp/wms?BGCOLOR=0xAAAAAA&TILED=true&LAYERS=states&FORMAT=image/png&REQUEST=GetMap&STYLES=&SRS=EPSG:4326&BBOX=-135,45,-112.5,67.5&WIDTH=256&HEIGHT=256\"\n

                                                                              Response:

                                                                              < HTTP/1.1 200 OK\n< Content-Type: image/png\n< geowebcache-miss-reason: no parameter filter exists for BGCOLOR\n...\n
                                                                              "},{"location":"geowebcache/troubleshooting/#crs-not-defined","title":"CRS not defined","text":"

                                                                              The following request is not handled by the GeoWebCache WMS because the request references a CRS (EPSG:26986) that does not match any of the tile layer gridsets:

                                                                              Request:

                                                                              curl -v \"http://localhost:8080/geoserver/topp/wms?TILED=true&LAYERS=states&FORMAT=image/png&REQUEST=GetMap&STYLES=&SRS=EPSG:26986&BBOX=-135,45,-112.5,67.5&WIDTH=256&HEIGHT=256\"\n

                                                                              Response:

                                                                              < HTTP/1.1 200 OK\n< Content-Type: image/png\n< geowebcache-miss-reason: no cache exists for requested CRS\n...\n
                                                                              "},{"location":"geowebcache/troubleshooting/#workspace-styles","title":"Workspace Styles","text":"

                                                                              If a cached layer uses a style which is tied to a workspace, the layer needs to be viewed in the context of that workspace in order for the style to be visible. Trying to cache such a layer will result in an error.

                                                                              By default, the embeded GeoWebCache uses the global workspace. This can be overridden using a WORKSPACE parameter. To enable this, create a List of Strings Parameter filter for the layer named WORKSPACE. Set the default to the name of the workspace containing the style. Setting the other values will not be useful in most cases.

                                                                              Moving the style to a new workspace will require updating the filter.

                                                                              This parameter only applies to integrated tile layers. If you are adding a GeoServer layer on a remote GeoServer directly to GWC, then specify the workspace as part of the path as you would normally.

                                                                              "},{"location":"geowebcache/using/","title":"Using GeoWebCache","text":"

                                                                              Note

                                                                              For an more in-depth discussion of using GeoWebCache, please see the GeoWebCache documentation.

                                                                              "},{"location":"geowebcache/using/#gwc_directwms","title":"Direct integration with GeoServer WMS","text":"

                                                                              GeoWebCache can be transparently integrated with the GeoServer WMS, and so requires no special endpoint or custom URL. In this way one can have the simplicity of a standard WMS endpoint with the performance of a tiled client.

                                                                              Although this direct integration is disabled by default, it can be enabled by going to the Caching defaults page in the Web administration interface.

                                                                              When this feature is enabled, GeoServer WMS will cache and retrieve tiles from GeoWebCache (via a GetMap request) only if all of the following criteria are followed:

                                                                              • WMS Direct integration is enabled (you can set this on the Caching defaults page)
                                                                              • tiled=true is included in the request (unless the Explicitly require TILED Parameter is unchecked. you can set this on the Caching defaults page)
                                                                              • The request only references a single layer
                                                                              • Caching is enabled for that layer
                                                                              • The image requested is of the same height and width as the size saved in the layer configuration
                                                                              • The requested CRS matches one of the available tile layer gridsets
                                                                              • The image requested lines up with the existing grid bounds
                                                                              • A parameter is included for which there is a corresponding Parameter Filter

                                                                              In addition, when direct integration is enabled, the WMS capabilities document (via a GetCapabilities request) will only return the WMS-C vendor-specific capabilities elements (such as a <TileSet> element for each cached layer/CRS/format combination) if tiled=true is appended to the GetCapabilities request.

                                                                              Note

                                                                              For more information on WMS-C, please see the WMS Tiling Client Recommendation from OSGeo.

                                                                              Note

                                                                              GeoWebCache integration is not compatible with the OpenLayers-based Layer Preview, as the preview does not usually align with the GeoWebCache layer gridset. This is because the OpenLayers application calculates the tileorigin based on the layer's bounding box, which is different from the gridset. It is, possible to create an OpenLayers application that caches tiles; just make sure that the tileorigin aligns with the gridset.

                                                                              "},{"location":"geowebcache/using/#virtual-services","title":"Virtual services","text":"

                                                                              When direct WMS integration is enabled, GeoWebCache will properly handle requests to Virtual Services (/geoserver/<workspace>/wms?tiled=true&...).

                                                                              Virtual services capabilities documents will contain <TileSet> entries only for the layers that belong to that workspace (and global layer groups), and will be referenced by unqualified layer names (no namespace). For example, the layer topp:states will be referred to as <Layers>states</Layers> instead of <Layers>topp:states</Layers>, and GetMap requests to the virtual services endpoint using LAYERS=states will properly be handled.

                                                                              "},{"location":"geowebcache/using/#supported-parameter-filters","title":"Supported parameter filters","text":"

                                                                              With direct WMS integration, the following parameter filters are supported for GetMap requests:

                                                                              • ANGLE
                                                                              • BGCOLOR
                                                                              • BUFFER
                                                                              • CQL_FILTER
                                                                              • ELEVATION
                                                                              • ENV
                                                                              • FEATUREID
                                                                              • FEATUREVERSION
                                                                              • FILTER
                                                                              • FORMAT_OPTIONS
                                                                              • MAXFEATURES
                                                                              • PALETTE
                                                                              • STARTINDEX
                                                                              • TIME
                                                                              • VIEWPARAMS

                                                                              If a request is made using any of the above parameters, the request will be passed to GeoServer, unless a parameter filter has been set up, in which case GeoWebCache will process the request.

                                                                              "},{"location":"geowebcache/using/#gwc_endpoint","title":"GeoWebCache endpoint URL","text":"

                                                                              When not using direct integration, you can point your client directly to GeoWebCache.

                                                                              Warning

                                                                              GeoWebCache is not a true WMS, and so the following is an oversimplification. If you encounter errors, see the Troubleshooting page for help.

                                                                              To direct your client to GeoWebCache (and thus receive cached tiles) you need to change the WMS URL.

                                                                              If your application requests WMS tiles from GeoServer at this URL:

                                                                              http://example.com/geoserver/wms\n

                                                                              You can invoke the GeoWebCache WMS instead at this URL:

                                                                              http://example.com/geoserver/gwc/service/wms\n

                                                                              In other words, add /gwc/service/wms in between the path to your GeoServer instance and the WMS call.

                                                                              This end-point works using either:

                                                                              • WMS-C: A tileset description is included in the WMS GetCapabilities document instructing clients how to retrieve content as a series of tiles (each retrieved by a GetMap request). This technique supports HTTP caching taking advantage of the browser cache and any caching proxies deployed. This technique requires a client to be created with tile server support.

                                                                              • full-wms mode: GeoWebCache behaves as normal WMS supported ad-hoc WMS GetMapRequests. Each WMS Request is handled by obtaining the tiles required and stitching the result into a single image. This technique relies only on internal tile cache, but supports ad-hoc GetMap requests and does not require a client be constructed with tile server support.

                                                                                To enable this mode add the following in geowebcache.xml configuration file:

                                                                                <fullWMS>true</fullWMS>\n

                                                                                The fullWMS setting only effects the /gwc/service/wms endpoint and is not used by direct WMS integration.

                                                                              As soon as tiles are requested through the gwc/service/wms endpoint GeoWebCache automatically starts saving them. The initial requests for each tile will not be accelerated since GeoServer will need to generate the tile and store it from subsequent use. To automate this process of requesting tiles, you can seed the cache. See the section on Seeding and refreshing for more details.

                                                                              "},{"location":"geowebcache/using/#gwc_diskquota","title":"Disk quota","text":"

                                                                              GeoWebCache has a built-in disk quota feature to prevent disk space from growing unbounded. You can set the maximum size of the cache directory, poll interval, and what policy of tile removal to use when the quota is exceeded. Tiles can be removed based on usage (\"Least Frequently Used\" or LFU) or timestamp (\"Least Recently Used\" or LRU).

                                                                              Disk quotas are turned off by default, but can be configured on the Disk Quotas page in the Web administration interface.

                                                                              "},{"location":"geowebcache/using/#integration-with-external-mapping-sites","title":"Integration with external mapping sites","text":"

                                                                              The documentation on the GeoWebCache homepage contains examples for creating applications that integrate with Google Maps, Google Earth, Bing Maps, and more.

                                                                              "},{"location":"geowebcache/using/#support-for-custom-projections","title":"Support for custom projections","text":"

                                                                              The version of GeoWebCache that comes embedded in GeoServer automatically configures every layer served in GeoServer with the two most common projections:

                                                                              • EPSG:4326 (latitude/longitude)
                                                                              • EPSG:900913 (Spherical Mercator, the projection used in Google Maps)

                                                                              You can also set a custom CRS from any that GeoServer recognizes. See the Gridsets page for details.

                                                                              "},{"location":"geowebcache/rest/","title":"GeoWebCache REST API","text":"

                                                                              This section discusses the GeoWebCache REST API, an interface for working programmatically with the integrated GeoWebCache without the need for a GUI.

                                                                              The GeoWebCache REST endpoint when integrated with GeoServer is available at:

                                                                              <GEOSERVER_HOME>/gwc/rest/\n

                                                                              For example:

                                                                              http://example.com:8080/geoserver/gwc/rest/\n
                                                                              • Managing Layers
                                                                              • Seeding and Truncating
                                                                              • Disk Quota
                                                                              "},{"location":"geowebcache/rest/diskquota/","title":"Disk Quota","text":"

                                                                              The GeoWebCache REST API provides a RESTful interface through which users can configure the disk usage limits and expiration policies for a GeoWebCache instance.

                                                                              "},{"location":"geowebcache/rest/diskquota/#operations","title":"Operations","text":"

                                                                              URL: /gwc/rest/diskquota.<format>

                                                                              Method Action Return Code Formats GET Return the global disk quota configuration 200 XML, JSON POST 405 PUT Modify the global disk quota configuration 200 XML, JSON DELETE 405

                                                                              Representations:

                                                                              • XML
                                                                              • JSON

                                                                              The examples below use the cURL tool, though the examples apply to any HTTP-capable tool or library.

                                                                              "},{"location":"geowebcache/rest/diskquota/#retrieving-the-current-configuration","title":"Retrieving the current configuration","text":"

                                                                              The following returns the current disk quota configuration in XML format:

                                                                              curl -u admin:geoserver -v -XGET http://localhost:8080/geoserver/gwc/rest/diskquota.xml\n
                                                                              < HTTP/1.1 200 OK\n< Date: Mon, 21 Mar 2011 13:50:49 GMT\n< Server: Noelios-Restlet-Engine/1.0..8\n< Content-Type: text/xml; charset=ISO-8859-1\n< Content-Length: 422\n< \n<gwcQuotaConfiguration>\n  <enabled>true</enabled>\n  <diskBlockSize>2048</diskBlockSize>\n  <cacheCleanUpFrequency>5</cacheCleanUpFrequency>\n  <cacheCleanUpUnits>SECONDS</cacheCleanUpUnits>\n  <maxConcurrentCleanUps>5</maxConcurrentCleanUps>\n  <globalExpirationPolicyName>LRU</globalExpirationPolicyName>\n  <globalQuota>\n    <value>100</value>\n    <units>MiB</units>\n  </globalQuota>\n  <layerQuotas/>\n</gwcQuotaConfiguration>\n

                                                                              The following returns the current disk quota configuration in JSON format:

                                                                              curl -u admin:geoserver -v -XGET http://localhost:8080/geoserver/gwc/rest/diskquota.json\n
                                                                              < HTTP/1.1 200 OK\n< Date: Mon, 21 Mar 2011 13:53:42 GMT\n< Server: Noelios-Restlet-Engine/1.0..8\n< Content-Type: application/json; charset=ISO-8859-1\n< Content-Length: 241\n< \n* Connection #0 to host localhost left intact\n* Closing connection #0\n{\"gwcQuotaConfiguration\":{\"diskBlockSize\":2048,\"enabled\":true,\"maxConcurrentCleanUps\":5,\"cacheCleanUpFrequency\":5,\"globalExpirationPolicyName\":\"LRU\",\"globalQuota\":{\"value\":\"100\",\"units\":\"MiB\"},\"cacheCleanUpUnits\":\"SECONDS\"}}\n
                                                                              "},{"location":"geowebcache/rest/diskquota/#changing-configuration","title":"Changing configuration","text":"

                                                                              Note

                                                                              The request body for PUT should contain only the desired properties to be modified. For example, the following will only change the maxConcurrentCleanups property in XML format:

                                                                              <gwcQuotaConfiguration><maxConcurrentCleanUps>2</maxConcurrentCleanUps></gwcQuotaConfiguration>\n

                                                                              The following will only change the diskBlockSize, enabled, and globalQuota properties in JSON format:

                                                                              {\"gwcQuotaConfiguration\":{\"diskBlockSize\":2048,\"enabled\":true,\"globalQuota\":{\"value\":\"100\",\"units\":\"MiB\"}}\n

                                                                              The following XML example successfully enables the quota and sets the globalQuota size:

                                                                              curl -v -u admin:geoserver \"http://localhost:8090/geoserver/gwc/rest/diskquota.xml\" -X PUT -d \"<gwcQuotaConfiguration><enabled>true</enabled><globalQuota><value>100</value><units>GiB</units></globalQuota></gwcQuotaConfiguration>\"\n
                                                                              < HTTP/1.1 200 OK\n< Date: Fri, 18 Mar 2011 20:59:31 GMT\n< Server: Noelios-Restlet-Engine/1.0..8\n< Content-Type: text/xml; charset=ISO-8859-1\n< Content-Length: 422\n< \n<gwcQuotaConfiguration>\n  <enabled>true</enabled>\n  <diskBlockSize>2048</diskBlockSize>\n  <cacheCleanUpFrequency>5</cacheCleanUpFrequency>\n  <cacheCleanUpUnits>SECONDS</cacheCleanUpUnits>\n  <maxConcurrentCleanUps>5</maxConcurrentCleanUps>\n  <globalExpirationPolicyName>LFU</globalExpirationPolicyName>\n  <globalQuota>\n    <value>100</value>\n    <units>GiB</units>\n  </globalQuota>\n  <layerQuotas/>\n</gwcQuotaConfiguration>\n

                                                                              The following JSON example changes the globalQuote and expirationPolicyName parameters:

                                                                              curl -v -u admin:geoserver \"http://localhost:8090/geoserver/gwc/rest/diskquota.json\" -X PUT -d \"{\"gwcQuotaConfiguration\":{\"globalQuota\":{\"value\":\"100\",\"units\":\"MiB\"},\"globalExpirationPolicyName\":\"LRU\"}}\"\n
                                                                              < HTTP/1.1 200 OK\n< Date: Fri, 18 Mar 2011 21:02:20 GMT\n< Server: Noelios-Restlet-Engine/1.0..8\n< Content-Type: application/json; charset=ISO-8859-1\n< Content-Length: 241\n< \n* Connection #0 to host localhost left intact\n* Closing connection #0\n{\"gwcQuotaConfiguration\":{\"diskBlockSize\":2048,\"enabled\":true,\"maxConcurrentCleanUps\":5,\"cacheCleanUpFrequency\":5,\"globalExpirationPolicyName\":\"LRU\",\"globalQuota\":{\"value\":\"100\",\"units\":\"MiB\"},\"cacheCleanUpUnits\":\"SECONDS\",\"layerQuotas\":[]}}\n

                                                                              The following invalid XML example has an invalid parameter (maxConcurrentCleanUps must be > 0). It returns a 400 response code and contains an error message as plain text:

                                                                              curl -v -u admin:geoserver \"http://localhost:8090/geoserver/gwc/rest/diskquota.xml\" -X PUT -d \"<gwcQuotaConfiguration><maxConcurrentCleanUps>-1</maxConcurrentCleanUps></gwcQuotaConfiguration>\"\n
                                                                              < HTTP/1.1 400 Bad Request\n< Date: Fri, 18 Mar 2011 20:53:26 GMT\n< Server: Noelios-Restlet-Engine/1.0..8\n< Content-Type: text/plain; charset=ISO-8859-1\n< Content-Length: 53\n< \n* Connection #0 to host localhost left intact\n* Closing connection #0\nmaxConcurrentCleanUps shall be a positive integer: -1\n

                                                                              The following invalid JSON example uses an unknown unit of measure (ZZiB). It returns a 400 response code and contains an error message as plain text:

                                                                              curl -v -u admin:geoserver \"http://localhost:8090/geoserver/gwc/rest/diskquota.json\" -X PUT -d \"{\"gwcQuotaConfiguration\":{\"globalQuota\":{\"value\":\"100\",\"units\":\"ZZiB\"}}}\"\n
                                                                              < HTTP/1.1 400 Bad Request\n< Date: Fri, 18 Mar 2011 20:56:23 GMT\n< Server: Noelios-Restlet-Engine/1.0..8\n< Content-Type: text/plain; charset=ISO-8859-1\n< Content-Length: 601\n< \nNo enum const class org.geowebcache.diskquota.storage.StorageUnit.ZZiB : No enum const class org.geowebcache.diskquota.storage.StorageUnit.ZZiB\n---- Debugging information ----\nmessage             : No enum const class org.geowebcache.diskquota.storage.StorageUnit.ZZiB\ncause-exception     : java.lang.IllegalArgumentException\ncause-message       : No enum const class org.geowebcache.diskquota.storage.StorageUnit.ZZiB\nclass               : org.geowebcache.diskquota.DiskQuotaConfig\nrequired-type       : org.geowebcache.diskquota.storage.Quota\nline number         : -1\n* Connection #0 to host localhost left intact\n* Closing connection #0\n
                                                                              "},{"location":"geowebcache/rest/layers/","title":"Managing Layers","text":"

                                                                              The GeoWebCache REST API provides a RESTful interface through which users can add, modify, or remove cached layers.

                                                                              Note

                                                                              JSON is not recommended for managing layers as the JSON library has a number of issues with multi-valued properties such as \"parameterFilters\".

                                                                              "},{"location":"geowebcache/rest/layers/#layer-list","title":"Layer list","text":"

                                                                              URL: /gwc/rest/layers.xml

                                                                              Method Action Return Code Formats GET Return the list of available layers 200 XML POST 400 PUT 400 DELETE 400

                                                                              The following example will request a full list of layers:

                                                                              curl -u admin:geoserver \"http://localhost:8080/geoserver/gwc/rest/layers\"\n
                                                                              <layers>\n  <layer>\n    <name>img states</name>\n    <atom:link xmlns:atom=\"http://www.w3.org/2005/Atom\" rel=\"alternate\" href=\"http://localhost:8080/geoserver/gwc/rest/layers/img+states.xml\" type=\"text/xml\"/>\n  </layer>\n  <layer>\n    <name>raster test layer</name>\n    <atom:link xmlns:atom=\"http://www.w3.org/2005/Atom\" rel=\"alternate\" href=\"http://localhost:8080/geoserver/gwc/rest/layers/raster+test+layer.xml\" type=\"text/xml\"/>\n  </layer>\n  <layer>\n    <name>topp:states</name>\n    <atom:link xmlns:atom=\"http://www.w3.org/2005/Atom\" rel=\"alternate\" href=\"http://localhost:8080/geoserver/gwc/rest/layers/topp%3Astates.xml\" type=\"text/xml\"/>\n  </layer>\n </layers>\n
                                                                              "},{"location":"geowebcache/rest/layers/#layer-operations","title":"Layer Operations","text":"

                                                                              URL: /gwc/rest/layers/<layer>.xml

                                                                              Note

                                                                              JSON is not recommended for managing layers as the JSON library has a number of issues with multi-valued properties such as \"parameterFilters\".

                                                                              Method Action Return Code Formats GET Return the XML representation of the layer 200 XML POST Modify the definition/configuration of the layer 200 XML PUT Add a new layer 200 XML DELETE Delete the layer 200

                                                                              Note

                                                                              There are two different representations for cached layers, depending on whether the tile layer is created from the GeoServer WMS layer or layer group (GeoServerLayer), or is configured in geowebcache.xml as a regular GWC layer (wmsLayer). A GeoServer layer is referred to as a GeoServerLayer and contains no image data source information such as origin WMS URL.

                                                                              Representations:

                                                                              • GeoWebCache (wmsLayer) XML minimal
                                                                              • GeoWebCache (wmsLayer) XML
                                                                              • GeoServer (GeoServerLayer) XML minimal
                                                                              • GeoServer (GeoServerLayer) XML

                                                                              The examples below use the cURL tool, though the examples apply to any HTTP-capable tool or library.

                                                                              "},{"location":"geowebcache/rest/layers/#adding-a-geowebcache-layer","title":"Adding a GeoWebCache layer","text":"

                                                                              The following example will add a new layer to GeoWebCache:

                                                                              curl -v -u admin:geoserver -XPUT -H \"Content-type: text/xml\" -d @layer.xml  \"http://localhost:8080/geoserver/gwc/rest/layers/newlayer.xml\"\n

                                                                              The layer.xml file is defined as the following:

                                                                              <wmsLayer>\n  <name>newlayer</name>\n  <mimeFormats>\n    <string>image/png</string>\n  </mimeFormats>\n  <gridSubsets>\n    <gridSubset>\n      <gridSetName>EPSG:900913</gridSetName>\n    </gridSubset>\n  </gridSubsets>\n  <wmsUrl>\n    <string>http://localhost:8080/geoserver/wms</string>\n  </wmsUrl>\n  <wmsLayers>topp:states</wmsLayers>\n</wmsLayer>\n

                                                                              Note

                                                                              The addressed resource (newlayer in this example) must match the name of the layer in the XML representation.

                                                                              "},{"location":"geowebcache/rest/layers/#adding-a-geoserver-layer","title":"Adding a GeoServer layer","text":"

                                                                              The following example will add a new layer to both GeoServer and GeoWebCache:

                                                                              curl -v -u admin:geoserver -XPUT -H \"Content-type: text/xml\" -d @poi.xml  \"http://localhost:8080/geoserver/gwc/rest/layers/tiger:poi.xml\"\n

                                                                              The poi.xml file is defined as the following:

                                                                              <GeoServerLayer>\n  <id>LayerInfoImpl--570ae188:124761b8d78:-7fd0</id>\n  <enabled>true</enabled>\n  <name>tiger:poi</name>\n  <mimeFormats>\n    <string>image/png8</string>\n  </mimeFormats>\n  <gridSubsets>\n    <gridSubset>\n      <gridSetName>GoogleCRS84Quad</gridSetName>\n      <zoomStart>0</zoomStart>\n      <zoomStop>14</zoomStop>\n      <minCachedLevel>1</minCachedLevel>\n      <maxCachedLevel>9</maxCachedLevel>\n    </gridSubset>\n  </gridSubsets>\n  <metaWidthHeight>\n    <int>4</int>\n    <int>4</int>\n  </metaWidthHeight>\n  <gutter>50</gutter>\n  <autoCacheStyles>true</autoCacheStyles>\n</GeoServerLayer>\n

                                                                              Note

                                                                              The addressed resource ( tiger:poi in this example) must match the name of the layer in the XML representation, as well as the name of an existing GeoServer layer or layer group.

                                                                              "},{"location":"geowebcache/rest/layers/#modifying-a-layer","title":"Modifying a layer","text":"

                                                                              This example modifies the layer definition via the layer.xml file. The request adds a parameter filter and a grid subset to the existing tiger:poi tile layer:

                                                                              <GeoServerLayer>\n <enabled>true</enabled>\n <name>tiger:poi</name>\n <mimeFormats>\n   <string>image/png8</string>\n </mimeFormats>\n <gridSubsets>\n   <gridSubset>\n     <gridSetName>GoogleCRS84Quad</gridSetName>\n     <zoomStart>0</zoomStart>\n     <zoomStop>14</zoomStop>\n     <minCachedLevel>1</minCachedLevel>\n     <maxCachedLevel>9</maxCachedLevel>\n   </gridSubset>\n   <gridSubset>\n     <gridSetName>EPSG:900913</gridSetName>\n     <extent>\n       <coords>\n         <double>-8238959.403861314</double>\n         <double>4969300.121476209</double>\n         <double>-8237812.689219721</double>\n         <double>4971112.167757057</double>\n       </coords>\n     </extent>\n   </gridSubset>\n </gridSubsets>\n <metaWidthHeight>\n   <int>4</int>\n   <int>4</int>\n </metaWidthHeight>\n <parameterFilters>\n   <floatParameterFilter>\n     <key>ELEVATION</key>\n     <defaultValue>0.0</defaultValue>\n     <values>\n       <float>0.0</float>\n       <float>1.0</float>\n       <float>2.0</float>\n       <float>3.0</float>\n       <float>4.0</float>\n     </values>\n     <threshold>1.0E-3</threshold>\n   </floatParameterFilter>\n </parameterFilters>\n <gutter>50</gutter>\n <autoCacheStyles>true</autoCacheStyles>\n</GeoServerLayer>\n

                                                                              Instead of PUT, use the HTTP POST method instead:

                                                                              curl -v -u admin:geoserver -XPOST -H \"Content-type: text/xml\" -d @poi.xml  \"http://localhost:8080/geoserver/gwc/rest/layers/tiger:poi.xml\"\n
                                                                              "},{"location":"geowebcache/rest/layers/#deleting-a-layer","title":"Deleting a layer","text":"

                                                                              Deleting a GeoWebCache tile layer deletes the layer configuration as well as the layer's disk cache. No tile images will remain in the cache directory after deleting a tile layer.

                                                                              To delete a layer, use the HTTP DELETE method against the layer resource:

                                                                              curl -v -u admin:geoserver -XDELETE \"http://localhost:8080/geoserver/gwc/rest/layers/newlayer.xml\"\n

                                                                              Note

                                                                              If trying to delete a tile layer that is an integrated GeoServerLayer, only the GeoWebCache layer definition will be deleted; the GeoServer definition is left untouched. To delete a layer in GeoServer, use the GeoServer REST to manipulate GeoServer resources.

                                                                              On the other hand, deleting a GeoServer layer via the GeoServer REST API will automatically delete the associated tile layer.

                                                                              "},{"location":"geowebcache/rest/seed/","title":"Seeding and Truncating","text":"

                                                                              The GeoWebCache REST API provides a RESTful interface through which users can add or remove tiles from the cache on a per-layer basis.

                                                                              "},{"location":"geowebcache/rest/seed/#operations","title":"Operations","text":"

                                                                              URL: /gwc/rest/seed/<layer>.<format>

                                                                              Method Action Return Code Formats GET Return the status of the seeding threads 200 JSON POST Issue a seed or truncate task request 200 XML, JSON PUT 405 DELETE 405

                                                                              Representations:

                                                                              • XML
                                                                              • JSON

                                                                              The examples below use the cURL tool, though the examples apply to any HTTP-capable tool or library.

                                                                              "},{"location":"geowebcache/rest/seed/#seeding","title":"Seeding","text":"

                                                                              The following XML request initiates a seeding task:

                                                                              curl -v -u admin:geoserver -XPOST -H \"Content-type: text/xml\" -d '<seedRequest><name>nurc:Arc_Sample</name><srs><number>4326</number></srs><zoomStart>1</zoomStart><zoomStop>12</zoomStop><format>image/png</format><type>truncate</type><threadCount>2</threadCount></seedRequest>'  \"http://localhost:8080/geoserver/gwc/rest/seed/nurc:Arc_Sample.xml\"\n
                                                                              * About to connect() to localhost port 8080 (#0)\n*   Trying 127.0.0.1... connected\n* Connected to localhost (127.0.0.1) port 8080 (#0)\n* Server auth using Basic with user 'admin'\n> POST /geoserver/gwc/rest/seed/nurc:Arc_Sample.xml HTTP/1.1\n> Authorization: Basic YWRtaW46Z2Vvc2VydmVy\n> User-Agent: curl/7.21.3 (x86_64-pc-linux-gnu) libcurl/7.21.3 OpenSSL/0.9.8o zlib/1.2.3.4 libidn/1.18\n> Host: localhost:8080\n> Accept: */*\n> Content-type: text/xml\n> Content-Length: 209\n> \n< HTTP/1.1 200 OK\n

                                                                              The following is a more complete XML fragment for a seed request, including parameter filters:

                                                                              <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<seedRequest>\n  <name>topp:states</name>\n  <bounds>\n    <coords>\n      <double>-2495667.977678598</double>\n      <double>-2223677.196231552</double>\n      <double>3291070.6104286816</double>\n      <double>959189.3312465074</double>\n    </coords>\n  </bounds>\n\n  <!-- These are listed on http://localhost:8080/geoserver/gwc/demo -->\n  <gridSetId>EPSG:2163</gridSetId>\n  <zoomStart>0</zoomStart>\n  <zoomStop>2</zoomStop>\n  <format>image/png</format>\n\n  <!-- type can be seed, reseed, or truncate -->\n  <type>truncate</type> \n\n  <!-- Number of seeding threads to run in parallel. \n       If type == truncate only one thread will be used\n       regardless of this parameter -->\n  <threadCount>1</threadCount>\n  <!-- Parameter filters -->\n  <parameters>\n    <entry>\n      <string>STYLES</string>\n      <string>pophatch</string>\n    </entry>\n    <entry>\n      <string>CQL_FILTER</string>\n      <string>TOTPOP > 10000</string>\n    </entry>\n  </parameters>\n</seedRequest>\n
                                                                              "},{"location":"geowebcache/rest/seed/#truncating","title":"Truncating","text":"

                                                                              The following XML request initiates a truncating task:

                                                                              curl -v -u admin:geoserver -XPOST -H \"Content-type: application/json\" -d \"{'seedRequest':{'name':'topp:states','bounds':{'coords':{ 'double':['-124.0','22.0','66.0','72.0']}},'srs':{'number':4326},'zoomStart':1,'zoomStop':12,'format':'image\\/png','type':'truncate','threadCount':4}}}\"  \"http://localhost:8080/geoserver/gwc/rest/seed/nurc:Arc_Sample.json\"\n
                                                                              * About to connect() to localhost port 8080 (#0)\n*   Trying 127.0.0.1... connected\n* Connected to localhost (127.0.0.1) port 8080 (#0)\n* Server auth using Basic with user 'admin'\n> POST /geoserver/gwc/rest/seed/nurc:Arc_Sample.json HTTP/1.1\n> Authorization: Basic YWRtaW46Z2Vvc2VydmVy\n> User-Agent: curl/7.21.3 (x86_64-pc-linux-gnu) libcurl/7.21.3 OpenSSL/0.9.8o zlib/1.2.3.4 libidn/1.18\n> Host: localhost:8080\n> Accept: */*\n> Content-type: application/json\n> Content-Length: 205\n> \n< HTTP/1.1 200 OK\n< Date: Fri, 14 Oct 2011 22:09:21 GMT\n< Server: Noelios-Restlet-Engine/1.0..8\n< Transfer-Encoding: chunked\n< \n* Connection #0 to host localhost left intact\n* Closing connection #0\n
                                                                              "},{"location":"geowebcache/rest/seed/#querying-running-tasks","title":"Querying running tasks","text":"

                                                                              URL: /gwc/rest/seed[/<layer>].json

                                                                              Method Action Return Code Formats GET Get the global or per layer state of running and pending tasks 200 JSON POST 405 PUT 405 DELETE 405"},{"location":"geowebcache/rest/seed/#getting-current-state-of-the-seeding-threads","title":"Getting current state of the seeding threads","text":"

                                                                              Sending a GET request to the /gwc/rest/seed.json resource returns a list of pending (scheduled) and running tasks for all the layers.

                                                                              Sending a GET request to the /gwc/rest/seed/<layer name>.json resource returns a list of pending (scheduled) and running tasks for that specific layer.

                                                                              The returned content is a JSON array of the form:

                                                                              {\"long-array-array\":[[<long>,<long>,<long>,<long>,<long>],...]}\n

                                                                              If there are no pending or running tasks, the returned array is empty:

                                                                              {\"long-array-array\":[]}\n

                                                                              The returned array of arrays contains one array per seeding/truncating task. The meaning of each long value in each thread array is:

                                                                              [tiles processed, total number of tiles to process, estimated remaining time (in seconds), Task ID, Task status]\n

                                                                              The returned Task Status value will be one of the following:

                                                                              -1 = ABORTED \n 0 = PENDING\n 1 = RUNNING\n 2 = DONE\n

                                                                              The example below returns the current state of tasks for the topp:states layer:

                                                                              curl -u <user>:<password> -v -XGET http://localhost:8080/geoserver/gwc/rest/seed/topp:states.json\n
                                                                              {\"long-array-array\":[[17888,44739250,18319,1,1],[17744,44739250,18468,2,1],[16608,44739250,19733,3,0],[0,1000,1000,4,0]]}\n

                                                                              In the above response, tasks 1 and 2 for the topp:states layer are running, and tasks 3 and 4 are in a pending state waiting for an available thread.

                                                                              The example below returns a list of tasks for all the layers.

                                                                              curl -u <user>:<password> -XGET http://localhost:8080/geoserver/gwc/rest/seed.json\n
                                                                              {\"long-array-array\":[[2240,327426,1564,2,1],[2368,327426,1477,3,1],[2272,327426,1541,4,1],[2176,327426,1611,5,1],[1056,15954794690,79320691,6,1],[1088,15954794690,76987729,7,1],[1040,15954794690,80541010,8,1],[1104,15954794690,75871965,9,1]]}\n
                                                                              "},{"location":"geowebcache/rest/seed/#terminating-running-tasks","title":"Terminating running tasks","text":"

                                                                              URL: /gwc/rest/seed[/<layer>]

                                                                              Method Action Return Code Formats GET 405 POST Issue a kill running and/or pending tasks request 200 PUT 405 DELETE 405

                                                                              A POST request to the /gwc/rest/seed resource terminates pending and/or running tasks for all layers. A POST request to the /gwc/rest/seed/<layername> resource terminates pending and/or running tasks for a specific layer.

                                                                              It is possible to terminate individual or all pending and/or running tasks. Use the parameter kill_all with one of the following values: running, pending, or all.

                                                                              Note

                                                                              For backward compatibility, the kill_all parameter value 1 is also accepted and is equivalent to running.

                                                                              The following request terminates all running seed and truncate tasks.

                                                                              curl -v -u admin:geoserver -d \"kill_all=all\"  \"http://localhost:8080/geoserver/gwc/rest/seed\"\n
                                                                              * About to connect() to localhost port 8080 (#0)\n*   Trying 127.0.0.1... connected\n< HTTP/1.1 200 OK\n< Date: Fri, 14 Oct 2011 22:23:04 GMT\n< Server: Noelios-Restlet-Engine/1.0..8\n< Content-Type: text/html; charset=ISO-8859-1\n< Content-Length: 426\n< \n<html>\n...\n* Connection #0 to host localhost left intact\n* Closing connection #0\n
                                                                              "},{"location":"geowebcache/webadmin/","title":"GeoWebCache settings","text":"

                                                                              This section of the Web administration interface describes how to configure the tile caching options for GeoServer. GeoServer uses GeoWebCache to provide direct and integrated tile caching, and can dramatically increase your server's responsiveness and reliability.

                                                                              The pages in this menu can be accessed on the left side of the screen under the heading Tile Caching.

                                                                              Tile Caching menu

                                                                              • Tile Layers
                                                                              • Demo page
                                                                              • Caching defaults
                                                                              • Gridsets
                                                                              • Disk Quotas
                                                                              • BlobStores
                                                                              "},{"location":"geowebcache/webadmin/blobstores/","title":"BlobStores","text":"

                                                                              BlobStores allow us to configure how and where GeoWebCache will store its cached data on a per-layer basis. This page allows us to define the different BlobStores present in the system. BlobStores can be created, modified and removed from here.

                                                                              "},{"location":"geowebcache/webadmin/blobstores/#general","title":"General","text":""},{"location":"geowebcache/webadmin/blobstores/#identifier","title":"Identifier","text":"

                                                                              Each BlobStore has a unique identifier.

                                                                              "},{"location":"geowebcache/webadmin/blobstores/#blobstore-type","title":"BlobStore Type","text":"

                                                                              There can be different BlobStore types to use different ways of storage. There is only standard support for File BlobStores. Plugins may add additional types.

                                                                              "},{"location":"geowebcache/webadmin/blobstores/#enabled","title":"Enabled","text":"

                                                                              Disabled BlobStores will not be loaded. Disabling a BlobStore will disable caching for all layers and layergroups assigned to that BlobStore.

                                                                              "},{"location":"geowebcache/webadmin/blobstores/#default","title":"Default","text":"

                                                                              There should always be one default BlobStore, which cannot be removed. The default BlobStore will be used by all layers not assigned to a specific BlobStore. Removing a BlobStore will cause all layers assigned to this BlobStore to use the default BlobStore until specified otherwise.

                                                                              "},{"location":"geowebcache/webadmin/blobstores/#file-blobstore","title":"File BlobStore","text":"

                                                                              These store data on a disk in a specified directory.

                                                                              It is also possible to choose the tile file layout:

                                                                              • GeoWebCache default uses a path structure reducing the number of items in each directory, by splitting long lists in groups. In particular, the layout is z/xc_yc/x_y.ext where xc=x/(2^(z/2)), yc=y/(2^(z/2)). In other words, the tiles are split into square areas, the number of square areas growing with the zoom level, and each square being assigned to a intermediate directory. The Y coordinates are numbered from the south northwards.
                                                                              • TMS uses a TMS layout, that is, z/y/x.ext where the Y coordinates are numbered from the south northwards.
                                                                              • XYZ uses a \"slippy map\", or \"Google Maps like\" layout, that is, z/y/x.ext where the Y coordinates originate top left and grow southwards (opposite of TMS and GWC default order).

                                                                              Note

                                                                              When switching file layout type, the tile directories won't be deleted, it's up to the admin to clean up the tiles on the file system, GeoServer/GWC won't do it automatically.

                                                                              "},{"location":"geowebcache/webadmin/blobstores/#base-directory","title":"Base Directory","text":"

                                                                              The directory where the cached data is stored.

                                                                              "},{"location":"geowebcache/webadmin/blobstores/#disk-block-size","title":"Disk block size","text":"

                                                                              This setting determines how the tile cache calculates disk usage. The value for this setting should be equivalent to the disk block size of the storage medium where the cache is located. The default block size is 4096 bytes.

                                                                              "},{"location":"geowebcache/webadmin/defaults/","title":"Caching defaults","text":"

                                                                              The Caching Defaults page shows the global configuration options for the tile caching functionality in GeoServer, an embedded GeoWebCache.

                                                                              "},{"location":"geowebcache/webadmin/defaults/#gwc-provided-services","title":"GWC Provided Services","text":"

                                                                              In addition to the GeoServer endpoints, GeoWebCache provides other endpoints for OGC services. For example, the GeoServer WMS endpoint is available at:

                                                                              http://GEOSERVER_URL/wms?...\n

                                                                              The GeoWebCache WMS endpoint is:

                                                                              http://GEOSERVER_URL/gwc/service/wms?...\n

                                                                              Provided services

                                                                              The following settings describe the different services that can be enabled with GeoWebCache.

                                                                              "},{"location":"geowebcache/webadmin/defaults/#enable-direct-integration-with-geoserver-wms","title":"Enable direct integration with GeoServer WMS","text":"

                                                                              Direct integration allows WMS requests served through GeoServer to be cached as if they were received and processed by GeoWebCache. This provides all the advantages of using a tile server while still employing the more-flexible GeoServer WMS as a fallback. See the section on Using GeoWebCache for more details about this feature.

                                                                              With direct integration, tile caching is enabled for all standard WMS requests that contain the tiled=true parameter and conform to all required parameters.

                                                                              This setting is disabled by default. When enabling this option, it is a good idea to also turn on Disk Quotas as well, to prevent unbounded growth of the stored tiles.

                                                                              "},{"location":"geowebcache/webadmin/defaults/#explicitly-require-tiled-parameter","title":"Explicitly require TILED Parameter","text":"

                                                                              When this parameter is checked direct WMS integration requires that the tiled=true parameter be set in all requests that will be cached. If this parameter is unchecked all incoming requests will be considered for caching, the request must still conform to all required parameters.

                                                                              "},{"location":"geowebcache/webadmin/defaults/#enable-wms-c-service","title":"Enable WMS-C Service","text":"

                                                                              Enables the Cached Web Map Service (WMS-C) service. When this setting is enabled, GeoWebCache will respond to its own WMS-C endpoint:

                                                                              http://GEOSERVER_URL/gwc/service/wms?SERVICE=WMS&VERSION=1.1.1&TILED=true&...\n

                                                                              When the service is disabled, calls to the capabilities document will return a Service is disabled message.

                                                                              "},{"location":"geowebcache/webadmin/defaults/#enable-tms-service","title":"Enable TMS Service","text":"

                                                                              Enables the Tiled Map Service (TMS) endpoint in GeoWebCache. With the TMS service, GeoWebCache will respond to its own TMS endpoint:

                                                                              http://GEOSERVER/URL/gwc/service/tms/1.0.0\n

                                                                              When the service is disabled, calls to the capabilities document will return a Service is disabled message.

                                                                              "},{"location":"geowebcache/webadmin/defaults/#enable-wmts-service","title":"Enable WMTS Service","text":"

                                                                              Enables the Web Map Tiled Service (WMTS) endpoint in GeoWebCache. When this setting is enabled, GeoWebCache will respond to its own WMTS endpoint:

                                                                              http://GEOSERVER/URL/gwc/service/wmts?...\n

                                                                              When the service is disabled, calls to the capabilities document will return a Service is disabled message.

                                                                              HTTP RESTful API is available through the existing GWC integration allowing clients to retrieve the following resources:

                                                                              • capabilities document
                                                                              • tile
                                                                              • feature info

                                                                              For more information read GWC WMTS documentation.

                                                                              "},{"location":"geowebcache/webadmin/defaults/#enable-data-security","title":"Enable Data Security","text":"

                                                                              Enables the GeoServer Data Security in the embedded GeoWebCache.

                                                                              "},{"location":"geowebcache/webadmin/defaults/#default-caching-options-for-geoserver-layers","title":"Default Caching Options for GeoServer Layers","text":"

                                                                              This section describes the configuration of the various defaults and other global options for the tile cache in GeoServer.

                                                                              Default caching options

                                                                              "},{"location":"geowebcache/webadmin/defaults/#automatically-configure-a-geowebcache-layer-for-each-new-layer-or-layer-group","title":"Automatically configure a GeoWebCache layer for each new layer or layer group","text":"

                                                                              This setting, enabled by default, determines how layers in GeoServer are handled via the embedded GeoWebCache. When this setting is enabled, an entry in the GeoWebCache layer listing will be created whenever a new layer or layer group is published in GeoServer. Use this setting to keep the GeoWebCache catalog in sync. (This is enabled by default.)

                                                                              "},{"location":"geowebcache/webadmin/defaults/#automatically-cache-non-default-styles","title":"Automatically cache non-default styles","text":"

                                                                              By default, only requests using the default style for a given layer will be cached. When this setting is enabled, all requests for a given layer, even those that use a non-standard style will be cached. Disabling this may be useful in situations where disk space is an issue, or when only one default style is important.

                                                                              "},{"location":"geowebcache/webadmin/defaults/#default-metatile-size","title":"Default metatile size","text":"

                                                                              A metatile is several tiles combined into a larger one. This larger metatile is generated and then subdivided before being served back (and cached) as standard tiles. The advantage of using metatiling is in situations where a label or geometry lies on a boundary of a tile, which may be truncated or altered. With metatiling, these tile edge issues are greatly reduced.

                                                                              Moreover, with metatiling, the overall time it takes to seed the cache is reduced in most cases, when compared with rendering a full map with single tiles. In fact, using larger metatiling factors is a good way to reduce the time spent in seeding the cache.

                                                                              The disadvantage of metatiling is that at large sizes, memory consumption can be an issue.

                                                                              The size of the default metatile can be adjusted here. By default, GeoServer sets a metatile size of 4x4, which strikes a balance between performance, memory usage, and rendering accuracy.

                                                                              "},{"location":"geowebcache/webadmin/defaults/#default-gutter-size","title":"Default gutter size","text":"

                                                                              The gutter size sets the amount of extra space (in pixels) used when generating a tile. Use this in conjunction with metatiles to reduce problems with labels and features not being rendered incorrectly due to being on a tile boundary.

                                                                              "},{"location":"geowebcache/webadmin/defaults/#default-cache-formats","title":"Default Cache Formats","text":"

                                                                              This setting determines the default image formats that can be cached when tiled requests are made. There are four image formats that can be used when saving tiles:

                                                                              • PNG (24-bit PNG)
                                                                              • PNG8 (8-bit PNG)
                                                                              • JPEG
                                                                              • GIF

                                                                              The default settings are subdivided into vector layers, raster layers, and layer groups. You may select any of the above four formats for each of the three types of layers. Any requests that fall outside of these layer/format combinations will not be cached if sent through GeoServer, and will return an error if sent to the GeoWebCache endpoints.

                                                                              These defaults can be overwritten on a per-layer basis when editing the layer properties.

                                                                              Default image formats

                                                                              "},{"location":"geowebcache/webadmin/defaults/#in-memory-blobstore-options","title":"In Memory BlobStore Options","text":"

                                                                              These options are used for enabling/disabling In Memory Caching for GeoWebCache. This feature can be used for saving GWC tiles directly in memory, for a fast data retrieval.

                                                                              "},{"location":"geowebcache/webadmin/defaults/#enable","title":"Enable","text":"

                                                                              This parameter allows to enable or disable in memory caching. By default it is disabled.

                                                                              "},{"location":"geowebcache/webadmin/defaults/#avoid-persistence","title":"Avoid Persistence","text":"

                                                                              This parameter can be used to prevent the saving of any file in the file system, keeping all the GWC tiles only in memory. By default it is disabled.

                                                                              "},{"location":"geowebcache/webadmin/defaults/#available-caches","title":"Available Caches","text":"

                                                                              This parameter defines which Cache method can be used for In Memory Caching. By default the Guava Caching is used. Note that if a caching method requires an immutable configuration at GeoServer startup like HazelCast, the Hard Memory limit, Eviction Policy, Eviction Time and Concurrency Level parameters are disabled.

                                                                              More information on how to configure a new Cache object can be found in the GeoWebCache Configuration page.

                                                                              "},{"location":"geowebcache/webadmin/defaults/#cache-hard-memory-limit-mb","title":"Cache Hard Memory limit (Mb)","text":"

                                                                              Parameter for configuring in memory cache size in MB.

                                                                              "},{"location":"geowebcache/webadmin/defaults/#cache-eviction-policy","title":"Cache Eviction Policy","text":"

                                                                              Parameter for configuring in memory cache eviction policy, it may be: LRU, LFU, EXPIRE_AFTER_WRITE, EXPIRE_AFTER_ACCESS, NULL

                                                                              This eviction policies may not be supported by all caches implementations. For example, Guava Caching only supports the eviction policies: EXPIRE_AFTER_WRITE, EXPIRE_AFTER_ACCESS and NULL.

                                                                              Note, only the eviction policies accepted by the selected cache will be shown on the UI.

                                                                              "},{"location":"geowebcache/webadmin/defaults/#cache-eviction-time-in-seconds","title":"Cache Eviction Time (in Seconds)","text":"

                                                                              Parameter for configuring in memory cache eviction time. It is in seconds.

                                                                              Note

                                                                              Note that this parameter is also used for configuring an internal thread which performs a periodical cache cleanup.

                                                                              "},{"location":"geowebcache/webadmin/defaults/#cache-concurrency-level","title":"Cache Concurrency Level","text":"

                                                                              Parameter for configuring in memory cache concurrency.

                                                                              "},{"location":"geowebcache/webadmin/defaults/#clear-in-memory-cache","title":"Clear In Memory Cache","text":"

                                                                              Button for clearing all the tiles in the in memory cache.

                                                                              "},{"location":"geowebcache/webadmin/defaults/#cache-statistics","title":"Cache Statistics","text":"

                                                                              Various statistics parameters associated with the in memory cache.

                                                                              "},{"location":"geowebcache/webadmin/defaults/#update-cache-statistics","title":"Update Cache Statistics","text":"

                                                                              Button for updating cache statistics seen above. The statistics are always related to the local cached entries, even in case of distributed in memory caching

                                                                              Note

                                                                              Note that some Caches do not provide all the statistics parameters, in that case the user will only see \"Unavailable\" for those parameters.

                                                                              In Memory BlobStore Options

                                                                              Note

                                                                              Note that in the TileCaching tab for each Layer, you may decide to disable in memory caching for the selected Layer by clicking on the Enable In Memory Caching for this Layer checkbox. This option is disabled for those caches which don't support this feature.

                                                                              "},{"location":"geowebcache/webadmin/defaults/#skip-caching-on-dimension-warnings","title":"Skip caching on dimension warnings","text":"

                                                                              WMS dimension handling can be complex, with ability to return tiles where the specified time was not a match, or when the request contained no time at all. This may not be a good match for tile caching, as it breaks the unique link between URL and tile content.

                                                                              The following settings allow to disable caching when a WMS dimension warning is issued:

                                                                              Skip caching on cache warnings

                                                                              The best settings depend on the type of dataset and disk-quota configurations:

                                                                              • For static datasets with dimensions, the default value skip could be removed, as it's going to generate at most one copy of the tiles. The nearest match and failed nearest could be cached if there is a disk quota (to speed up clients that repeatedly fail to perform an exact time match), but it's best not to cache it if there is no disk quota, as the mismatches can be potentially infinite, leading to an uncontrolled growth of the cache.
                                                                              • For a datasets growing over time, it's better to disable caching on the default value, as it's often the \"latest\", that is, the most recently added to the dataset. This means the tiles contents change based on when they are asked for. The considerations for nearest and failed matches are the same as for the static datasets.

                                                                              Caution is advised if the data ingestion might happen to skip some time/elevation values, to fill them only at a later time. In this case, nearest matches could cause the system to cache a tile for a nearby time value, which would hide the actual values if they get ingested at a later time.

                                                                              "},{"location":"geowebcache/webadmin/defaults/#default-cached-gridsets","title":"Default Cached Gridsets","text":"

                                                                              This section shows the gridsets that will be automatically configured for cached layers. While there are some pre-configured gridsets available, only two are enabled by default. These correspond to the most common and universal cases:

                                                                              • EPSG:4326 (geographic) with 22 maximum zoom levels and 256x256 pixel tiles
                                                                              • EPSG:900913 (spherical Mercator) with 31 maximum zoom levels and 256x256 pixel tiles

                                                                              Default gridsets

                                                                              To add a pre-existing grid set, select it from the Add default grid set menu, and click the Add icon (green circle with plus sign).

                                                                              Adding an existing gridset to the list of defaults

                                                                              These definitions are described in more detail on the Gridsets page.

                                                                              "},{"location":"geowebcache/webadmin/demopage/","title":"Demo page","text":"

                                                                              In addition to the Tile Layers page, there is also a demo page where you can view configured layers, reload the configuration (when changing settings or adding new layers), and seed or refresh the existing cache on a per-layer basis.

                                                                              As this interface is part of the standalone GeoWebCache, some of the functionality here is duplicated from the Tile Layers page.

                                                                              Built-in demo page

                                                                              "},{"location":"geowebcache/webadmin/demopage/#viewing","title":"Viewing","text":"

                                                                              To view the demo page, append /gwc/demo to the address of your GeoServer instance. For example, if your GeoServer is at the following address:

                                                                              http://localhost:8080/geoserver\n

                                                                              The GeoWebCache demo page is accessible here:

                                                                              http://localhost:8080/geoserver/gwc/demo\n

                                                                              If there is a problem loading this page, verify the steps on the Using GeoWebCache page have been carried out successfully.

                                                                              "},{"location":"geowebcache/webadmin/demopage/#reload-configuration","title":"Reload configuration","text":"

                                                                              The demo page contains a list of every layer that GeoWebCache is aware of. This is typically (though not necessarily) identical to the list of layers as published in the GeoServer WMS capabilities document. If configuration changes are made to GeoServer, GeoWebCache will not automatically become aware of them. To ensure that GeoWebCache is using the latest configuration information, click the Reload Configuration button. Reloading the configuration will trigger authentication to GeoServer, and will require an administration username and password. Use the same username and password that you would use to log on to the Web administration interface. After a successful logon, the number of layers found and loaded will be displayed.

                                                                              Reloading the configuration

                                                                              "},{"location":"geowebcache/webadmin/demopage/#layers-and-output-formats","title":"Layers and output formats","text":"

                                                                              For each layer that GeoWebCache serves, links are typically available for a number of different projections and output formats. By default, OpenLayers applications are available using image formats of PNG, PNG8, GIF, and JPEG in both EPSG:4326 (standard lat/lon) and EPSG:900913 (used in Google Maps) projections. In addition, KML output is available (EPSG:4326 only) using the same image formats, plus vector data (\"kml\").

                                                                              Also on the list is an option to seed the layers (Seed this layer). More on this option below.

                                                                              "},{"location":"geowebcache/webadmin/demopage/#seeding","title":"Seeding","text":"

                                                                              You can configure seeding processes via the Web administration interface. See the Tile Layers page for more information.

                                                                              It is also possible to configure seeding process via the Demo page. The page contains a link next to each layer entitled Seed this layer. This link will trigger authentication with the GeoServer configuration. Use the same username and password that you would use to log on to the Web administration interface. After a successful logon, a new page shows up with seeding options.

                                                                              The seeding options page contains various parameters for configuring the way that the layer is seeded.

                                                                              Option Description Number of threads to use Possible values are between 1 and 16. Type of operation Sets the operation. There are three possible values: Seed (creates tiles, but does not overwrite existing ones), Reseed (like Seed, but overwrites existing tiles) and Truncate (deletes all tiles within the given parameters) SRS Specifies the projection to use when creating tiles (default values are EPSG:4326 and EPSG:900913) Format Sets the image format of the tiles. Can be application/vnd.google-earth.kml+xml (Google Earth KML), image/gif (GIF), image/jpeg (JPEG), image/png (24 bit PNG), and image/png8 (8 bit PNG) Zoom start Sets the minimum zoom level. Lower values indicate map views that are more zoomed out. When seeding, GeoWebCache will only create tiles for those zoom levels inclusive of this value and Zoom stop. Zoom stop Sets the maximum zoom level. Higher values indicate map views that are more zoomed in. When seeding, GeoWebCache will only create tiles for those zoom levels inclusive of this value and Zoom start. Bounding box (optional) Allows seeding to occur over a specified extent, instead of the full extent of the layer. This is useful if your layer contains data over a large area, but the application will only request tiles from a subset of that area. The four boxes correspond to Xmin, Ymin, Xmax, and Ymax.

                                                                              Warning

                                                                              Currently there is no progress bar to inform you of the time required to perform the operation, nor is there any intelligent handling of disk space. In short, the process may take a very long time, and the cache may fill up your disk. You may wish to set a Disk quota before running a seed job.

                                                                              "},{"location":"geowebcache/webadmin/diskquotas/","title":"Disk Quotas","text":"

                                                                              The Disk Quotas page manages the disk usage for cached tiles and allows you to set the global disk quota. Individual layer quotas can be set in the layer's properties page.

                                                                              By default, disk usage for cached tiles is unbounded. However, this can cause disk capacity issues, especially when using Direct WMS integration (see Disk Quotas for more on this). Setting a disk quota establishes disk usage limits.

                                                                              When finished making any changes, remember to click Submit.

                                                                              Disk quota

                                                                              "},{"location":"geowebcache/webadmin/diskquotas/#enable-disk-quota","title":"Enable disk quota","text":"

                                                                              When enabled, the disk quota will be set according to the options listed below. The setting is disabled by default.

                                                                              "},{"location":"geowebcache/webadmin/diskquotas/#disk-quota-check-frequency","title":"Disk quota check frequency","text":"

                                                                              This setting determines how often the cache is polled for any overage. Smaller values (more frequent polling) will slightly increase disk activity, but larger values (less frequent polling) may cause the disk quota to be temporarily exceeded. The default is 10 seconds.

                                                                              "},{"location":"geowebcache/webadmin/diskquotas/#maximum-tile-cache-size","title":"Maximum tile cache size","text":"

                                                                              The maximum size for the cache. When this value is exceeded and the cache is polled, tiles will be removed according to the policy. Note that the unit options are mebibytes (MiB) (approx. 1.05MB), gibibytes (GiB) (approx. 1.07GB), and tebibytes (TiB) (approx. 1.10TB). Default is 500 MiB.

                                                                              The graphic below this setting illustrates the size of the cache relative to the disk quota.

                                                                              "},{"location":"geowebcache/webadmin/diskquotas/#tile-removal-policy","title":"Tile removal policy","text":"

                                                                              When the disk quota is exceeded, this policy determines how the tiles to be deleted are identified. Options are Least Frequently Used (removes tiles based on how often the tile was accessed) or Least Recently Used (removes tiles based on date of last access). The optimum configuration is dependent on your data and server usage.

                                                                              "},{"location":"geowebcache/webadmin/gridsets/","title":"Gridsets","text":"

                                                                              A gridset defines a spatial reference system, bounding box (extent), a list of zoom levels (resolutions or scale denominators), and tile dimensions. Tile requests must conform to the gridset matrix, otherwise caching will not occur.

                                                                              This page allows you to edit existing saved gridsets or create new ones. There is a set of pre-configured gridsets, a few legacy ones based on \"EPSG:4326\" and \"EPSG:900913\", and a larger set coming from the OGC Tile Matrix Set specification <http://docs.opengeospatial.org/is/17-083r2/17-083r2.html>. For additional CRS support, new gridsets can be created. Another reason to create a new gridset would be to set a different tile size or different number of zoom levels.

                                                                              Gridsets menu

                                                                              "},{"location":"geowebcache/webadmin/gridsets/#creating-a-new-gridset","title":"Creating a new gridset","text":"

                                                                              To create a new gridset, click Create new gridset. You will then be asked to enter a range of parameters.

                                                                              Creating a new gridset

                                                                              "},{"location":"geowebcache/webadmin/gridsets/#name","title":"Name","text":"

                                                                              The short name of the new gridset.

                                                                              "},{"location":"geowebcache/webadmin/gridsets/#description","title":"Description","text":"

                                                                              Metadata on the gridset.

                                                                              "},{"location":"geowebcache/webadmin/gridsets/#coordinate-reference-system","title":"Coordinate Reference System","text":"

                                                                              The Coordinate Reference System (CRS) to use in the gridset. You can select from any CRS that GeoServer recognizes. After selection, both the units (meters, feet, degrees, etc.) and the number of meters per unit will be displayed.

                                                                              "},{"location":"geowebcache/webadmin/gridsets/#gridset-bounds","title":"Gridset bounds","text":"

                                                                              Sets the maximum extent for the gridset. Typically this is set to be the maximum extent of the CRS used, but a smaller value can be substituted if desired. To populate the max extent in the fields, click Compute from maximum extent of CRS.

                                                                              "},{"location":"geowebcache/webadmin/gridsets/#tile-width-and-height","title":"Tile width and height","text":"

                                                                              Sets the tile dimensions. Default is 256x256 pixels. The tile dimensions can be anything from 16 to 2048 pixels. In addition, the tiles need not be square.

                                                                              "},{"location":"geowebcache/webadmin/gridsets/#tile-matrix-set","title":"Tile matrix set","text":"

                                                                              The tile matrix set (or tile pyramid) is a list of zoom levels containing ever increasing amounts of tiles. This three dimensional collection of tile \"slots\" creates the framework where actual image tiles will be saved. You can define the tile matrix based on resolutions or scale denominators.

                                                                              Click Add zoom level to generate the first zoom level. The parameters will be automatically configured such that the full extent of will be contained by a single pixel's height. The number of pixels in a given zoom level will be displayed, along with the Pixel Size, Scale, and an optional Name, where you can give a name to each zoom level if desired.

                                                                              Typically each additional zoom level is twice as large in each dimension, and so contains four times as many tiles as the previous zoom level. The actual values will be populated automatically during subsequent clicking of the Add zoom level link. These defaults are usually sufficient, and you need only determine the maximum number of zoom levels desired for this gridset.

                                                                              When finished, click Save. Before you will be able to use this new gridset with a layer, you will need to add this gridset to the layer's list of available gridsets. This is done on an individual layer's properties page. You can also add this gridset to the default list on the Caching defaults page.

                                                                              Tile matrix set

                                                                              "},{"location":"geowebcache/webadmin/gridsets/#editing-a-gridset","title":"Editing a gridset","text":"

                                                                              Click an existing gridset to open it for editing. Please note that the built-in gridsets cannot be edited. They can, however, be copied.

                                                                              Editing a gridset

                                                                              This gridset is read-only

                                                                              "},{"location":"geowebcache/webadmin/gridsets/#copying-a-gridset","title":"Copying a gridset","text":"

                                                                              As there are many configuration options for a gridset, it is often more convenient to copy an existing gridset. For any of the existing gridsets, click the Create a copy link to copy the gridset information to a new gridset.

                                                                              "},{"location":"geowebcache/webadmin/gridsets/#removing-a-gridset","title":"Removing a gridset","text":"

                                                                              To remove a gridset, select the check box next to the gridset or gridsets, and click Remove selected gridsets.

                                                                              Warning

                                                                              Removing a gridset definition will remove not only the gridset definition, but also any tiles on any layers generated with this gridset.

                                                                              Removing a gridset

                                                                              "},{"location":"geowebcache/webadmin/layers/","title":"Tile Layers","text":"

                                                                              This page shows a listing of all of the layers known to the integrated GeoWebCache. It is similar to the Layer Preview for GeoWebCache, with many of the same options.

                                                                              Note

                                                                              There is also a link to the GeoWebCache standalone demo page.

                                                                              "},{"location":"geowebcache/webadmin/layers/#layer-information","title":"Layer information","text":"

                                                                              For each layer cached by GeoWebCache, the following information is available.

                                                                              "},{"location":"geowebcache/webadmin/layers/#disk-quota","title":"Disk Quota","text":"

                                                                              The maximum amount of disk space that can be used for this layer. By default, this will be set to N/A (unbounded) unless Disk Quotas are enabled.

                                                                              "},{"location":"geowebcache/webadmin/layers/#disk-used","title":"Disk Used","text":"

                                                                              The current disk space being used by tiles for this particular layer.

                                                                              Note

                                                                              This counter will only be updated if disk quotas are enabled. If disk quotas are not enabled, tiles will still be saved to disk, but the counter will remain as 0.0 B.

                                                                              "},{"location":"geowebcache/webadmin/layers/#enabled","title":"Enabled","text":"

                                                                              Indicates whether tile caching is enabled for this layer. It is possible to have a layer definition here but to not have tile caching enabled (set in the layer properties).

                                                                              "},{"location":"geowebcache/webadmin/layers/#preview","title":"Preview","text":"

                                                                              Similar to Layer Preview, this will generate a simple OpenLayers application populated with tiles from one of the available gridset/image format combinations. Select the desired option from the menu to view in OpenLayers.

                                                                              "},{"location":"geowebcache/webadmin/layers/#seedtruncate","title":"Seed/Truncate","text":"

                                                                              Opens the GeoWebCache page for automatically seeding and truncating the tile cache. Use this if you want to pre-populate some of your cache.

                                                                              "},{"location":"geowebcache/webadmin/layers/#empty","title":"Empty","text":"

                                                                              Will remove all saved tiles from the cache. This is identical to a full truncate operation for the layer.

                                                                              "},{"location":"geowebcache/webadmin/layers/#add-or-remove-cached-layers","title":"Add or remove cached layers","text":"

                                                                              The list of layers displayed on this page is typically the same as, or similar to, the full list of layers known to GeoServer. However, it may not be desirable to have every layer published in GeoServer have a cached layer component. In this case, simply select the box next to the layer to remove, and click Remove selected cached layers. The layer will be removed from GeoWebCache, and the disk cache for this layer will be entirely removed.

                                                                              Warning

                                                                              Deleting the tile cache cannot be undone.

                                                                              Removing a cached layer

                                                                              To add in a layer from GeoServer (if it wasn't set up to be added automatically), click the Add a new cached layer link.

                                                                              Adding a new cached layer

                                                                              "},{"location":"geowebcache/webadmin/layers/#clearing-geowebcache","title":"Clearing GeoWebCache","text":"

                                                                              The Empty all link allows to clear the entire cache, for all layers, grid sets and filter parameters combination.

                                                                              Warning

                                                                              This will truncate all layers in GeoWebCache

                                                                              Confirmation to GeoWebCache

                                                                              A confirmation will appear on the page as message with names of cleared Tile layers.

                                                                              "},{"location":"geowebcache/webadmin/layers/#configuring-a-cached-layer","title":"Configuring a cached layer","text":"

                                                                              You have two options for layer configuration. The first option is to load the layer using the default (global) settings. To do this, select the layer you wish to start caching, and click the Configure selected layers with caching defaults link. The second option is to configure the caching parameters manually, via the layer configuration pages. To do this, just click the layer name itself.

                                                                              "},{"location":"geowebcache/webadmin/layers/#parameter-filters","title":"Parameter Filters","text":"

                                                                              Parameter filters allow GeoWebCache to cache a layer with varying parameters such as STYLES, TIME. One is needed for each parameter to be cached and it needs to know how to recognize valid values to be cached and which values are the same as other values so they only get cached once. There are several different kinds of filter as a result.

                                                                              "},{"location":"geowebcache/webadmin/layers/#adding-a-filter","title":"Adding a Filter","text":"

                                                                              At the bottom of the filter list in the text box beside Add filter specify the name of the parameter. In the drop down box select the kind of filter you want then click the button. For a filter that automatically tracks the layers styles in a parameter named STYLES click the Add Style Filter button.

                                                                              "},{"location":"geowebcache/webadmin/layers/#removing-a-filter","title":"Removing a Filter","text":"

                                                                              To remove a filter, click the button to the right of the filter's entry in the filter list.

                                                                              "},{"location":"geowebcache/webadmin/layers/#types-of-filter","title":"Types of filter","text":"

                                                                              All parameter filters take a default parameter that will be used if the parameter was not specified. Specific types of parameter filter provide different ways of specifying which parameter values are allowed, and which are equivalent to one another and should be cached together.

                                                                              "},{"location":"geowebcache/webadmin/layers/#list-of-strings","title":"List of Strings","text":"

                                                                              The stringParameterFilter takes a collection of plain text strings. If the value matches one of the strings, it is valid, otherwise it is not. Matching can be done in a case sensitive way, or the strings can all be converted to upper or lower case before matching. As case rules vary between languages, the locale to use for case changes can be specified.

                                                                              "},{"location":"geowebcache/webadmin/layers/#regular-expression","title":"Regular Expression","text":"

                                                                              The regexParameterFilter takes a regular expression to match strings. This should be used with caution as it potentially allows an arbitrarily large number of caches to be created. Like the string filter, it can be normalized for case.

                                                                              "},{"location":"geowebcache/webadmin/layers/#list-of-numbers","title":"List of Numbers","text":"

                                                                              The floatParameterFilter is like the string filter in taking a list of values, but it uses floating point numbers rather than arbitrary text strings. A threshold can be given to pull close numbers to a standard value.

                                                                              "},{"location":"geowebcache/webadmin/layers/#list-of-whole-numbers","title":"List of Whole Numbers","text":"

                                                                              The integerParameterFilter is like the float filter but works with integer/whole number values.

                                                                              "},{"location":"geowebcache/webadmin/layers/#styles","title":"Styles","text":"

                                                                              The styleParameterFilter is connected to the GeoServer catalog and knows what styles are available for the layer and when they change. You can specify a default distinct from the normal layer default if you wish, and restrict the range of additional styles available if you do not wish to cache all of them.

                                                                              "},{"location":"gettingstarted/","title":"Getting started","text":"

                                                                              This section contains short tutorials for common tasks in GeoServer to get new users using the system quickly.

                                                                              • Using the web administration interface
                                                                              • Publishing a GeoPackage
                                                                              • Publishing a Image
                                                                              • Publishing a Layer Group
                                                                              • Publishing a style
                                                                              • Publishing a shapefile
                                                                              • Publishing a PostGIS table
                                                                              "},{"location":"gettingstarted/geopkg-quickstart/","title":"Publishing a GeoPackage","text":"

                                                                              This tutorial walks through the steps of publishing a GeoPackage with GeoServer.

                                                                              Note

                                                                              This tutorial assumes that GeoServer is running at http://localhost:8080/geoserver.

                                                                              "},{"location":"gettingstarted/geopkg-quickstart/#data-preparation","title":"Data preparation","text":"

                                                                              First let's gather that the data that we'll be publishing.

                                                                              1. The sample data folder includes data/ne/natural_earth.gpkg
                                                                              2. This file contains small scale 1:110m data:
                                                                                • coastlines
                                                                                • countries
                                                                                • boundary lines
                                                                                • populated places

                                                                              Note

                                                                              This data/ne/natural_earth.gpkg file has been processed from https://www.naturalearthdata.com/downloads/ page, to download the original (much larger) file visit the above page and download GeoPackage link.

                                                                              "},{"location":"gettingstarted/geopkg-quickstart/#creating-a-new-workspace","title":"Creating a new workspace","text":"

                                                                              The next step is to create a workspace for the geopackage. A workspace is a folder used to group similar layers together.

                                                                              Note

                                                                              This step is optional if you'd like to use an existing workspace. Usually, a workspace is created for each project, which can include stores and layers that are related to each other.

                                                                              1. In a web browser, navigate to http://localhost:8080/geoserver.

                                                                              2. Log into GeoServer as described in the Logging In section.

                                                                              3. Navigate to Data \u2192 Workspaces.

                                                                                Workspaces page

                                                                              4. Click the Add new workspace button to display the New Workspace page.

                                                                              5. You will be prompted to enter a workspace Name and Namespace URI.

                                                                                  • Field
                                                                                  • Value
                                                                                  • Name:
                                                                                  • tutorial
                                                                                  • Namespace URI
                                                                                  • http://localhost:8080/geoserver/tutorial

                                                                                Note

                                                                                A workspace name is an identifier describing your project. It must not exceed ten characters or contain spaces.

                                                                                Note

                                                                                A Namespace URI (Uniform Resource Identifier) can usually be a URL associated with your project with an added trailing identifier indicating the workspace. The Namespace URI filed does not need to resolve to an actual valid web address.

                                                                              6. Press the Submit button.

                                                                                New workspace

                                                                              7. The tutorial workspace will be added to the Workspaces list.

                                                                              "},{"location":"gettingstarted/geopkg-quickstart/#create-a-store","title":"Create a store","text":"

                                                                              Once the workspace is created, we are ready to add a new store. The store tells GeoServer how to connect to the geopackage.

                                                                              1. Navigate to Data\u2192Stores.

                                                                                Stores page

                                                                              2. This page displays a list of stores, including the type of store and the workspace that the store belongs to.

                                                                              3. In order to add the geopackage, you need to create a new store. Click the Add new Store button. You will be redirected to a list of the data sources supported by GeoServer. Note that the data sources are extensible, so your list may look slightly different.

                                                                                New data source

                                                                              4. From the list of Vector Data Sources locate and click the GeoPackage link.

                                                                                The New Vector Data Source page will display.

                                                                              5. Begin by configuring the Basic Store Info.

                                                                                  • Field
                                                                                  • Value
                                                                                  • workspace
                                                                                  • tutorial
                                                                                  • Data Source Name
                                                                                  • NaturalEarth
                                                                                  • Description
                                                                                  • GeoPackage of NaturalEarth data

                                                                                This information is internal to GeoServer and is not used as part of the web service protocols. We recommend keeping the Data Source Name simple as they will be used to form folders in the data directory (so keep any operating system restrictions on character use in mind).

                                                                                Basic Store info

                                                                              6. Connection parameters are used to establish the connection with your database. As GeoPackage is a file based database this will primarily consist of the geopackage location.

                                                                              7. Under Connection Parameters, browse to the location URL of the geopackage, in our example data/ne.shp.

                                                                                Browse database location

                                                                              8. The Connection Parameters for our geopackage are:

                                                                                  • Field
                                                                                  • Value
                                                                                  • Database
                                                                                  • file:data/ne/natural_earth.gpkg
                                                                                  • Read only
                                                                                  • checked

                                                                                The use of read_only above indicates that we will not be writing to this GeoPackage, allowing GeoServer to avoid managing write locks when accessing this content for greater performance.

                                                                                Connection Parameters

                                                                              9. Press Save.

                                                                              10. You will be redirected to the New Layer page (as this is the most common next step when adding a new data store).

                                                                              "},{"location":"gettingstarted/geopkg-quickstart/#creating-a-layer","title":"Creating a layer","text":"

                                                                              Now that we have connected to the GeoPackage, we can publish the layer.

                                                                              1. On the New Layer page, click Publish beside the countries layer name.

                                                                                New Layer

                                                                              2. The Edit Layer page defines the data and publishing parameters for a layer.

                                                                                Edit Layer Data tab

                                                                              3. There are three critical pieces of information required on the Data tab before we can even save.

                                                                                • Basic Resource Info - describes how the layer is presented to others
                                                                                • Coordinate Reference System - establishes how the spatial data is to be interpreted or drawn on the world
                                                                                • Bounding Boxes - establishes where the dataset is located in the world
                                                                              4. Locate Basic Resource Info and define the layer:

                                                                                  • Field
                                                                                  • Value
                                                                                  • Name
                                                                                  • countries
                                                                                  • Title
                                                                                  • Countries
                                                                                  • Abstract
                                                                                  • Sovereign states

                                                                                The naming of a layer is important, and while GeoServer does not offer restrictions many of the individual protocols will only work with very simple names.

                                                                                Basic Resource Info

                                                                              5. Double check the Coordiante Reference Systems information is correct.

                                                                                  • Field
                                                                                  • Value
                                                                                  • Native SRS
                                                                                  • EPSG:4326
                                                                                  • Declaired SRS
                                                                                  • EPSG:4326
                                                                                  • SRS Handling
                                                                                  • Force declared

                                                                                Coordinate Reference Systems

                                                                              6. Locate Bounding Boxes and generate the layer's bounding boxes by clicking the Compute from data and then Compute from native bounds links.

                                                                                Generating bounding boxes

                                                                              7. Press Apply to save your work thus far without closing the page.

                                                                                This is a good way to check that your information has been entered correctly, GeoServer will provide a warning if any required information is incomplete.

                                                                              8. Scroll to the top of the page and navigate to the Publishing tab.

                                                                              9. Locate the WMS Settings heading, where we can set the style.Ensure that the Default Style is set to `polygon``.

                                                                                WMS Settings

                                                                              10. Press Save to complete your layer edits.

                                                                              "},{"location":"gettingstarted/geopkg-quickstart/#previewing-the-layer","title":"Previewing the layer","text":"

                                                                              In order to verify that the tutorial:countries layer is published correctly, we can preview the layer.

                                                                              1. Navigate to the Data > Layer Preview page and find the tutorial:countries layer.

                                                                                Note

                                                                                Use the Search field with tutorial as shown to limit the number of layers to page through.

                                                                                Layer Preview

                                                                              2. Click the OpenLayers link in the Common Formats column.

                                                                              3. An OpenLayers map will load in a new tab and display the shapefile data with the default line style.

                                                                                You can use this preview map to zoom and pan around the dataset, as well as display the attributes of features.

                                                                                Preview map of countries

                                                                              "},{"location":"gettingstarted/group-quickstart/","title":"Publishing a Layer Group","text":"

                                                                              This tutorial walks through the steps of publishing a layer group combing several layers into a basemap.

                                                                              Note

                                                                              This tutorial assumes that GeoServer is running at http://localhost:8080/geoserver.

                                                                              "},{"location":"gettingstarted/group-quickstart/#data-preparation","title":"Data preparation","text":"

                                                                              First let's gather that the data that we'll be publishing.

                                                                              1. Complete the previous tutorials:
                                                                                • Publishing a GeoPackage defining the tutorial:countries layer
                                                                                • Publishing a Image defining the tutorial:shaded layer
                                                                              "},{"location":"gettingstarted/group-quickstart/#create-a-layer-group","title":"Create a layer group","text":"
                                                                              1. Navigate to Data > Layer Group page.

                                                                                Layer Groups

                                                                              2. This page displays a list of layer groups, workspace that the group belongs to.

                                                                                Note

                                                                                Layer groups are allowed to be \"global\" allowing a map to be created combing layers from several workspaces into a single visual.

                                                                              3. At the top of the list Layer Groups locate and click the Add new layer group link.

                                                                              4. The Layer group editor defines

                                                                                • Basic Resource Info - describes how the layer is presented to others
                                                                                • Coordinate Reference System - establishes how the spatial data is to be interpreted or drawn on the world
                                                                                • Bounding Boxes - establishes where the dataset is located in the world
                                                                                • Layers - the layers to be drawn (listed in draw order)
                                                                              5. Locate Basic Resource Info and define the layer:

                                                                                  • Name
                                                                                  • basemap
                                                                                  • Title
                                                                                  • Basemap
                                                                                  • Abstract
                                                                                  • Plain basemap suitable as a backdrop for geospatial data.
                                                                                  • Workspace
                                                                                  • tutorial

                                                                                Basic resource information

                                                                              6. Scroll down to the Layers list which is presently empty.

                                                                              7. Click Add Layer link, select the tutorial:shaded layer first.

                                                                                The raster should be drawn first, as other content will be shown over top of it.

                                                                              8. Click Add Layer link, select the tutorial:countries layer second.

                                                                                This polygon layer will be drawn second.

                                                                              9. Locate the tutorial:countries layer in the list and click the Style entry to change polygon to line.

                                                                                By drawing only the outline of the countries the shaded relief can show through.

                                                                                Layer group layers in drawing order

                                                                              10. Locate the Coordiante Reference Systems and press Generate Bounds.

                                                                                Now that layers are listed we they can be used to determine the corodinate reference system and bounds of the layer group.

                                                                                Coordinate Reference Systems

                                                                              11. Press Save complete your layer group.

                                                                              "},{"location":"gettingstarted/group-quickstart/#previewing-the-layer","title":"Previewing the layer","text":"

                                                                              In order to verify that the tutorial:basemap layer is published correctly, we can preview the layer.

                                                                              1. Navigate to the Data > Layer Preview page and find the tutorial:basemap layer.

                                                                                Note

                                                                                Use the Search field with tutorial as shown to limit the number of layers to page through.

                                                                              2. Click the OpenLayers link in the Common Formats column.

                                                                              3. An OpenLayers map will load in a new tab. This preview is used to zoom and pan around the dataset, as well as display the attributes of features.

                                                                                Preview basemap

                                                                              "},{"location":"gettingstarted/image-quickstart/","title":"Publishing a Image","text":"

                                                                              This tutorial walks through the steps of publishing a World + Image with GeoServer.

                                                                              Note

                                                                              This tutorial assumes that GeoServer is running at http://localhost:8080/geoserver.

                                                                              "},{"location":"gettingstarted/image-quickstart/#data-preparation","title":"Data preparation","text":"

                                                                              First let's gather that the data that we'll be publishing.

                                                                              1. Download the Natural Earth 1:50m Shaded Relief raster:

                                                                                • https://www.naturalearthdata.com/downloads/50m-raster-data/50m-shaded-relief/
                                                                              2. This file contains small scale 1:50m data:

                                                                                • SR_50M.prj
                                                                                • SR_50M.README.html
                                                                                • SR_50M.tfw
                                                                                • SR_50M.tif
                                                                                • SR_50M.VERSION.txt

                                                                                This forms a world (the tfw file) plus image (the tif file).

                                                                              3. Move these files into your GeoServer Data Directory data/ne folder.

                                                                              "},{"location":"gettingstarted/image-quickstart/#creating-a-new-workspace","title":"Creating a new workspace","text":"

                                                                              The next step is to create a workspace for the geopackage. A workspace is a folder used to group similar layers together.

                                                                              Note

                                                                              This step is optional if you'd like to use an existing workspace. Usually, a workspace is created for each project, which can include stores and layers that are related to each other.

                                                                              1. In a web browser, navigate to http://localhost:8080/geoserver.

                                                                              2. Log into GeoServer as described in the Logging In section.

                                                                              3. Navigate to Data \u2192 Workspaces.

                                                                              4. Click the Add new workspace button to display the New Workspace page.

                                                                              5. You will be prompted to enter a workspace Name and Namespace URI.

                                                                                  • Name:
                                                                                  • tutorial
                                                                                  • Namespace URI
                                                                                  • http://localhost:8080/geoserver/tutorial

                                                                                Note

                                                                                A workspace name is an identifier describing your project. It must not exceed ten characters or contain spaces.

                                                                                Note

                                                                                A Namespace URI (Uniform Resource Identifier) can usually be a URL associated with your project with an added trailing identifier indicating the workspace. The Namespace URI filed does not need to resolve to an actual valid web address.

                                                                              6. Press the Submit button.

                                                                              7. The tutorial workspace will be added to the Workspaces list.

                                                                              "},{"location":"gettingstarted/image-quickstart/#create-a-store","title":"Create a store","text":"

                                                                              Once the workspace is created, we are ready to add a new store. The store tells GeoServer how to connect to the geopackage.

                                                                              1. Navigate to Data\u2192Stores.

                                                                              2. This page displays a list of stores, including the type of store and the workspace that the store belongs to.

                                                                              3. In order to add the geopackage, you need to create a new store. Click the Add new Store button. You will be redirected to a list of the data sources supported by GeoServer. Note that the data sources are extensible, so your list may look slightly different.

                                                                              4. From the list of Raster Data Sources locate and click the WorldImage link.

                                                                                Raster Data Sources

                                                                              5. The New Vector Data Source page will display.

                                                                              6. Begin by configuring the Basic Store Info.

                                                                                  • workspace
                                                                                  • tutorial
                                                                                  • Data Source Name
                                                                                  • ShadedRelief
                                                                                  • Description
                                                                                  • Grayscale shaded relief of land areas.

                                                                                This information is internal to GeoServer and is not used as part of the web service protocols. We recommend keeping the Data Source Name simple as they will be used to form folders in the data directory (so keep any operating system restrictions on character use in mind).

                                                                                Basic Store info

                                                                              7. Connection parameters are used to establish the location of your data.

                                                                              8. Under Connection Parameters, browse to the location URL of the image, in our example file:data/ne/SR_50M.tif.

                                                                              9. The Connection Parameters for our geopackage are:

                                                                                  • database
                                                                                  • file:data/ne/SR_50M.tif

                                                                                The use of read_only above indicates that we will not be writing to this GeoPackage, allowing GeoServer to avoid managing write locks when accessing this content for greater performance.

                                                                                Connection Parameters

                                                                              10. Press Save.

                                                                              11. You will be redirected to the New Layer page (as this is the most common next step when adding a new data store).

                                                                              "},{"location":"gettingstarted/image-quickstart/#creating-a-layer","title":"Creating a layer","text":"

                                                                              Now that we have located the image, we can publish this information as a layer.

                                                                              1. On the New Layer page, click Publish beside the SR_50M layer name.

                                                                              2. The Edit Layer page defines the data and publishing parameters for a layer.

                                                                              3. There are three critical pieces of information required on the Data tab before we can even save.

                                                                                • Basic Resource Info - describes how the layer is presented to others
                                                                                • Coordinate Reference System - establishes how the spatial data is to be interpreted or drawn on the world
                                                                                • Bounding Boxes - establishes where the dataset is located in the world
                                                                              4. Locate Basic Resource Info and define the layer:

                                                                                  • Name
                                                                                  • shaded
                                                                                  • Title
                                                                                  • Shaded Relief
                                                                                  • Abstract
                                                                                  • Grayscale shaded relief of land areas.

                                                                                The naming of a layer is important, and while GeoServer does not offer restrictions many of the individual protocols will only work with very simple names.

                                                                                Basic Resource Info

                                                                              5. Check the Coordiante Reference Systems information is as listed below.

                                                                                Note

                                                                                In this case select Force declared to prefer the GeoServer internal EPSG database definition of WGS84 over the prj file provided alongside the same image.

                                                                                  • Native SRS
                                                                                  • EPSG:4326
                                                                                  • Declaired SRS
                                                                                  • EPSG:4326
                                                                                  • SRS Handling
                                                                                  • Force declared

                                                                                Coordinate Reference Systems

                                                                              6. Locate Bounding Boces and generate the layer's bounding boxes by clicking the Compute from SRS bounds and then Compute from native bounds links.

                                                                                Note

                                                                                In this case we are choosing a slightly larger bounding box that fully contains the image.

                                                                                Generating bounding boxes

                                                                              7. Press Apply to save your work thus far without closing the page.

                                                                                This is a good way to check that your information has been entered correctly, GeoServer will provide a warning if any required information is incomplete.

                                                                              8. Scroll to the top of the page and navigate to the Publishing tab.

                                                                              9. Locate the WMS Settings heading, where we can set the style.Ensure that the Default Style is set to raster.

                                                                                WMS Settings

                                                                              10. Press Save to complete your layer edits.

                                                                              "},{"location":"gettingstarted/image-quickstart/#previewing-the-layer","title":"Previewing the layer","text":"

                                                                              In order to verify that the tutorial:shaded layer is published correctly, we can preview the layer.

                                                                              1. Navigate to the Data > Layer Preview page and find the tutorial:shaded layer.

                                                                                Note

                                                                                Use the Search field with tutorial as shown to limit the number of layers to page through.

                                                                              2. Click the OpenLayers link in the Common Formats column.

                                                                              3. An OpenLayers map will load in a new tab and display the imagery with the default raster style.

                                                                                You can use this preview map to zoom and pan around the dataset, as well as display the attributes of features.

                                                                                Preview map of shaded relief

                                                                              "},{"location":"gettingstarted/postgis-quickstart/","title":"Publishing a PostGIS table","text":"

                                                                              This tutorial walks through the steps of publishing a PostGIS table with GeoServer.

                                                                              Note

                                                                              This tutorial assumes that PostgreSQL/PostGIS has been previously installed on the system and responding on localhost on port 5432, and also that GeoServer is running at http://localhost:8080/geoserver.

                                                                              "},{"location":"gettingstarted/postgis-quickstart/#data-preparation","title":"Data preparation","text":"

                                                                              First let's gather that the data that we'll be publishing.

                                                                              1. Download the file nyc_buildings.zip. It contains a PostGIS dump of a dataset of buildings from New York City.

                                                                              2. Create a PostGIS database called nyc. This can be done with the following commands:

                                                                                createdb nyc\npsql -d nyc -c 'CREATE EXTENSION postgis'\n

                                                                                Note

                                                                                You may need to supply a username and password with these commands.

                                                                              3. Extract nyc_buildings.sql from nyc_buildings.zip.

                                                                              4. Import nyc_buildings.sql into the nyc database:

                                                                                psql -f nyc_buildings.sql nyc\n
                                                                              "},{"location":"gettingstarted/postgis-quickstart/#creating-a-new-workspace","title":"Creating a new workspace","text":"

                                                                              The next step is to create a workspace for the data. A workspace is a container used to group similar layers together.

                                                                              Note

                                                                              This step is optional if you'd like to use an existing workspace. Usually, a workspace is created for each project, which can include stores and layers that are related to each other.

                                                                              1. In a web browser, navigate to http://localhost:8080/geoserver.

                                                                              2. Log into GeoServer as described in the Logging In section.

                                                                              3. Navigate to Data \u2192 Workspaces.

                                                                                Workspaces page

                                                                              4. Click the Add new workspace button.

                                                                              5. You will be prompted to enter a workspace Name and Namespace URI.

                                                                                Configure a new workspace

                                                                              6. Enter the Name as nyc and the Namespace URI as http://geoserver.org/nyc.

                                                                                Note

                                                                                A workspace name is an identifier describing your project. It must not exceed ten characters or contain spaces. A Namespace URI (Uniform Resource Identifier) can usually be a URL associated with your project with an added trailing identifier indicating the workspace. The Namespace URI filed does not need to resolve to an actual valid web address.

                                                                              7. Click the Submit button. The nyc workspace will be added to the Workspaces list.

                                                                              "},{"location":"gettingstarted/postgis-quickstart/#creating-a-store","title":"Creating a store","text":"

                                                                              Once the workspace is created, we are ready to add a new store. The store tells GeoServer how to connect to the database.

                                                                              1. Navigate to Data\u2192Stores.

                                                                              2. You should see a list of stores, including the type of store and the workspace that the store belongs to.

                                                                                Adding a new data source

                                                                              3. Create a new store by clicking the PostGIS link.

                                                                              4. Enter the Basic Store Info:

                                                                                • Select the nyc Workspace
                                                                                • Enter the Data Source Name as nyc_buildings
                                                                                • Add a brief Description

                                                                                Basic Store Info

                                                                              5. Specify the PostGIS database Connection Parameters:

                                                                                  • Option
                                                                                  • Value
                                                                                  • dbtype
                                                                                  • postgis
                                                                                  • host
                                                                                  • localhost
                                                                                  • port
                                                                                  • 5432
                                                                                  • database
                                                                                  • nyc
                                                                                  • schema
                                                                                  • public
                                                                                  • user
                                                                                  • postgres
                                                                                  • passwd
                                                                                  • (Password for the postgres user)
                                                                                  • validate connections
                                                                                  • (Checked)

                                                                                Note

                                                                                Leave all other fields at their default values.

                                                                                Connection Parameters

                                                                              6. Click Save.

                                                                              "},{"location":"gettingstarted/postgis-quickstart/#creating-a-layer","title":"Creating a layer","text":"

                                                                              Now that the store is loaded, we can publish the layer.

                                                                              1. Navigate to Data \u2192 Layers.

                                                                              2. Click Add a new resource.

                                                                              3. From the New Layer chooser menu, select nyc:nyc_buidings.

                                                                                Store selection

                                                                              4. On the resulting layer row, select the layer name nyc_buildings.

                                                                                New layer selection

                                                                              5. The Edit Layer page defines the data and publishing parameters for a layer. Enter a short Title and an Abstract for the nyc_buildings layer.

                                                                                Basic Resource Info

                                                                              6. Generate the layer's bounding boxes by clicking the Compute from data and then Compute from native bounds links.

                                                                                Generating bounding boxes

                                                                              7. Click the Publishing tab at the top of the page.

                                                                              8. We can set the layer's style here. Under WMS Settings, ensure that the Default Style is set to polygon.

                                                                                Select Default Style

                                                                              9. Finalize the layer configuration by scrolling to the bottom of the page and clicking Save.

                                                                              "},{"location":"gettingstarted/postgis-quickstart/#previewing-the-layer","title":"Previewing the layer","text":"

                                                                              In order to verify that the nyc_buildings layer is published correctly, we can preview the layer.

                                                                              1. Navigate to the Layer Preview screen and find the nyc:nyc_buildings layer.

                                                                              2. Click the OpenLayers link in the Common Formats column.

                                                                              3. An OpenLayers map will load in a new tab and display the shapefile data with the default line style. You can use this preview map to zoom and pan around the dataset, as well as display the attributes of features.

                                                                                Preview map of nyc_buildings

                                                                              "},{"location":"gettingstarted/shapefile-quickstart/","title":"Publishing a shapefile","text":"

                                                                              This tutorial walks through the steps of publishing a Shapefile with GeoServer.

                                                                              Note

                                                                              This tutorial assumes that GeoServer is running at http://localhost:8080/geoserver.

                                                                              "},{"location":"gettingstarted/shapefile-quickstart/#data-preparation","title":"Data preparation","text":"

                                                                              First let's gather that the data that we'll be publishing.

                                                                              1. Download the file nyc_roads.zip. This archive contains a shapefile of roads from New York City that will be used during in this tutorial.

                                                                              2. Unzip the nyc_roads.zip into a new directory named nyc_roads. The archive contains the following four files:

                                                                                nyc_roads.shp\nnyc_roads.shx\nnyc_roads.dbf\nnyc_roads.prj\n
                                                                              3. Move the nyc_roads directory into <GEOSERVER_DATA_DIR>/data, where <GEOSERVER_DATA_DIR> is the root of the GeoServer data directory. If no changes have been made to the GeoServer file structure, the path is geoserver/data_dir/data/nyc_roads.

                                                                              "},{"location":"gettingstarted/shapefile-quickstart/#creating-a-new-workspace","title":"Creating a new workspace","text":"

                                                                              The next step is to create a workspace for the shapefile. A workspace is a container used to group similar layers together.

                                                                              Note

                                                                              This step is optional if you'd like to use an existing workspace. Usually, a workspace is created for each project, which can include stores and layers that are related to each other.

                                                                              1. In a web browser, navigate to http://localhost:8080/geoserver.

                                                                              2. Log into GeoServer as described in the Logging In section.

                                                                              3. Navigate to Data \u2192 Workspaces.

                                                                                Workspaces page

                                                                              4. Click the Add new workspace button.

                                                                              5. You will be prompted to enter a workspace Name and Namespace URI.

                                                                                Configure a new workspace

                                                                              6. Enter the Name as nyc and the Namespace URI as http://geoserver.org/nyc.

                                                                                Note

                                                                                A workspace name is an identifier describing your project. It must not exceed ten characters or contain spaces. A Namespace URI (Uniform Resource Identifier) can usually be a URL associated with your project with an added trailing identifier indicating the workspace. The Namespace URI filed does not need to resolve to an actual valid web address.

                                                                                nyc workspace

                                                                              7. Click the Submit button. The nyc workspace will be added to the Workspaces list.

                                                                              "},{"location":"gettingstarted/shapefile-quickstart/#create-a-store","title":"Create a store","text":"

                                                                              Once the workspace is created, we are ready to add a new store. The store tells GeoServer how to connect to the shapefile.

                                                                              1. Navigate to Data\u2192Stores.

                                                                              2. You should see a list of stores, including the type of store and the workspace that the store belongs to.

                                                                              3. In order to add the shapefile, you need to create a new store. Click the Add new Store button. You will be redirected to a list of the data sources supported by GeoServer. Note that the data sources are extensible, so your list may look slightly different.

                                                                                Stores

                                                                              4. Click Shapefile. The New Vector Data Source page will display.

                                                                              5. Begin by configuring the Basic Store Info.

                                                                                • Select the workspace nyc from the drop down menu.
                                                                                • Enter the Data Source Name as NYC Roads
                                                                                • Enter a brief Description (such as \"Roads in New York City\").
                                                                              6. Under Connection Parameters, browse to the location URL of the shapefile, typically nyc_roads/nyc_roads.shp.

                                                                                Basic Store Info and Connection Parameters

                                                                              7. Click Save. You will be redirected to the New Layer page in order to configure the nyc_roads layer.

                                                                              "},{"location":"gettingstarted/shapefile-quickstart/#creating-a-layer","title":"Creating a layer","text":"

                                                                              Now that the store is loaded, we can publish the layer.

                                                                              1. On the New Layer page, click Publish beside the nyc_roads layer name.

                                                                                New layer

                                                                              2. The Edit Layer page defines the data and publishing parameters for a layer. Enter a short Title and an Abstract for the nyc_roads layer.

                                                                                Basic Resource Information

                                                                              3. Generate the layer's bounding boxes by clicking the Compute from data and then Compute from native bounds links.

                                                                                Generating bounding boxes

                                                                              4. Click the Publishing tab at the top of the page.

                                                                              5. We can set the layer's style here. Under WMS Settings, ensure that the Default Style is set to line.

                                                                                Select Default Style

                                                                              6. Finalize the layer configuration by scrolling to the bottom of the page and clicking Save.

                                                                              "},{"location":"gettingstarted/shapefile-quickstart/#previewing-the-layer","title":"Previewing the layer","text":"

                                                                              In order to verify that the nyc_roads layer is published correctly, we can preview the layer.

                                                                              1. Navigate to the Layer Preview screen and find the nyc:nyc_roads layer.

                                                                                Layer Preview

                                                                              2. Click the OpenLayers link in the Common Formats column.

                                                                              3. An OpenLayers map will load in a new tab and display the shapefile data with the default line style. You can use this preview map to zoom and pan around the dataset, as well as display the attributes of features.

                                                                                Preview map of nyc_roads

                                                                              "},{"location":"gettingstarted/style-quickstart/","title":"Publishing a style","text":"

                                                                              This tutorial walks through the steps of defining a style and associating it with a layer for use.

                                                                              Note

                                                                              This tutorial assumes that GeoServer is running at http://localhost:8080/geoserver.

                                                                              "},{"location":"gettingstarted/style-quickstart/#data-preparation","title":"Data preparation","text":"

                                                                              First let's gather that the data that we'll be publishing.

                                                                              1. Complete the previous tutorials:
                                                                                • Publishing a GeoPackage defining the tutorial:countries layer
                                                                                • Publishing a Image defining the tutorial:shaded layer
                                                                                • Publishing a Layer Group defining the tutorial:basemap layer
                                                                              "},{"location":"gettingstarted/style-quickstart/#create-a-style","title":"Create a style","text":"
                                                                              1. Navigate to Data > Style page.

                                                                                Styles

                                                                              2. This page displays a list of styles, including the workspace the style belongs to.

                                                                                Note

                                                                                Styles groups are allowed to be \"global\" allowing a style to be defined that can be used by any layer.

                                                                              3. At the top of the list Styles list, locate and click the Add a new style link.

                                                                              4. Locate Style Data and define the style:

                                                                                  • Name
                                                                                  • background
                                                                                  • Workspace
                                                                                  • tutorial
                                                                                  • Format
                                                                                  • SLD

                                                                                Style data

                                                                              5. Locate Style Content and carefully:

                                                                                • Under Generate a default style select Polygon

                                                                                Style Content configured to generate a polygon default style.

                                                                              6. Under Generate a default style locate and click the Generate link to populate the style editor with a generated outline of a polygion style.

                                                                              7. Press the Apply button to define this style.

                                                                                Now that the style is defined there are more options for interactively working with the style.

                                                                              8. Change to Publishing tab.

                                                                                • Use the search to filter with tutorial to locate tutorial:countries.
                                                                                • Select the Default checkbox for tutorial:countries to use the tutorial:background style the default for this layer.

                                                                                Style publish

                                                                              9. Next to Publishing navigate to the Layer Preview tab.

                                                                                • Locate the Preview on layer and click on the link to select tutorial:countries as a dataset to use when editing the style.

                                                                                Styled editor Layer Preview tab

                                                                              10. Edit your style by inserting fill-opacity value of 0.25.

                                                                                <?xml version=\"1.0\" encoding=\"ISO-8859-1\"?>\n<StyledLayerDescriptor version=\"1.0.0\"\n  xsi:schemaLocation=\"http://www.opengis.net/sld http://schemas.opengis.net/sld/1.0.0/StyledLayerDescriptor.xsd\"\n  xmlns=\"http://www.opengis.net/sld\" xmlns:ogc=\"http://www.opengis.net/ogc\"\n  xmlns:xlink=\"http://www.w3.org/1999/xlink\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\">\n\n  <NamedLayer>\n    <Name>background</Name>\n    <UserStyle>\n      <Title>Background</Title>\n      <FeatureTypeStyle>\n        <Rule>\n          <Title>Background</Title>\n          <PolygonSymbolizer>\n            <Fill>\n              <CssParameter name=\"fill\">#444433</CssParameter>\n              <CssParameter name=\"fill-opacity\">0.25</CssParameter>\n            </Fill>\n            <Stroke>\n              <CssParameter name=\"stroke\">#000000</CssParameter>\n              <CssParameter name=\"stroke-width\">0.25</CssParameter>\n            </Stroke>\n          </PolygonSymbolizer>\n        </Rule>\n      </FeatureTypeStyle>\n    </UserStyle>\n  </NamedLayer>\n</StyledLayerDescriptor>\n
                                                                              11. Press Apply to edit your style and check the resulting visual change in the layer preview.

                                                                              12. Experiment with:

                                                                                • Updating the title information, watching the displayed legend change
                                                                                • Full screen mode for side-by-side editing

                                                                                Full screen mode

                                                                              13. When this style is used as part of the tutorial::basemap the fill-opacity allows the shaded relief detail to be shown.

                                                                                Basemap with background style applied to countries

                                                                              "},{"location":"gettingstarted/web-admin-quickstart/","title":"Using the web administration interface","text":"

                                                                              GeoServer has a browser-based web administration interface application used to configure all aspects of GeoServer, from adding and publishing data to changing service settings.

                                                                              1. The web admin interface is accessed via a web browser at:

                                                                                http://<host>:<port>/geoserver\n
                                                                              2. For a default installation on a server the link is:

                                                                                http://localhost:8080/geoserver\n
                                                                              3. When the application starts, it displays the Welcome page.

                                                                                Welcome Page

                                                                              4. The welcome page provides links describing the web services used to access information.

                                                                                To use copy and paste these links into a Desktop GIS, mobile or web mapping application.

                                                                              Note

                                                                              For more information, please see the Welcome section.

                                                                              "},{"location":"gettingstarted/web-admin-quickstart/#logging_in","title":"Logging In","text":"

                                                                              In order to change any server settings or configure data, a user must first be authenticated.

                                                                              1. Navigate to the upper right of the web interface to log into GeoServer. The default administration credentials are:

                                                                                • User name: admin
                                                                                • Password: geoserver

                                                                                Note

                                                                                These can be changed in the Security section.

                                                                                Login

                                                                              2. Once logged in, the Welcome screen changes to show the available admin functions. These are primarily shown in the menus on the left side of the page.

                                                                                Additional options when logged in

                                                                              "},{"location":"gettingstarted/web-admin-quickstart/#layer-preview","title":"Layer Preview","text":"

                                                                              The Layer Preview page allows you to quickly view the output of published layers.

                                                                              1. Click the Layer Preview link on the menu to go to this page.

                                                                              2. From here, you can find the layer you'd like to preview and click a link for an output format. Click the OpenLayers link for a given layer and the view will display.

                                                                              3. To sort a column alphabetically, click the column header.

                                                                                Unsorted (left) and sorted (right) columns

                                                                              4. Searching can be used to filter the number of items displayed. This is useful for working with data types that contain a large number of items. To search data type items, enter the search string in the search box and click Enter. GeoServer will search the data type for items that match your query, and display a list view showing the search results.

                                                                                Search results for the query \"top\" on the Workspace page

                                                                                Note

                                                                                Sorting and searching apply to all data configuration pages.

                                                                              Note

                                                                              For more information, please see the Layer Preview section.

                                                                              "},{"location":"installation/","title":"Installation","text":"

                                                                              There are many ways to install GeoServer on your system. This section will discuss the various installation paths available.

                                                                              Note

                                                                              To run GeoServer as part of an existing servlet container such as Tomcat, please see the Web archive section.

                                                                              Warning

                                                                              GeoServer requires a Java 11 or Java 17 environment (JRE) to be installed on your system, available from OpenJDK, Adoptium for Windows and macOS installers, or provided by your OS distribution.

                                                                              This must be done prior to installation.

                                                                              • Linux binary
                                                                              • Windows binary
                                                                              • Windows installer
                                                                              • Web archive
                                                                              • Docker Container
                                                                              • Upgrading existing versions
                                                                              "},{"location":"installation/docker/","title":"Docker Container","text":"

                                                                              Geoserver is also packaged as a Docker Container. For more details, see the Geoserver Docker Container Project.

                                                                              See the README.md file for more technical information.

                                                                              "},{"location":"installation/docker/#quick-start","title":"Quick Start","text":"

                                                                              This will run the container, with the data directory included with the container:

                                                                              1. Make sure you have Docker installed.

                                                                              2. Download the container:

                                                                                Nightly Build

                                                                                These instructions are for GeoServer 2.24-SNAPSHOT which is provided as a Nightly release. Testing a Nightly release is a great way to try out new features, and test community modules. Nightly releases change on an ongoing basis and are not suitable for a production environment.

                                                                                docker pull docker.osgeo.org/geoserver: 2.24.x\n

                                                                                Release

                                                                                These instructions are for GeoServer 2.24.2.

                                                                                docker pull docker.osgeo.org/geoserver: 2.24.2\n
                                                                              3. Run the container

                                                                                Release

                                                                                docker run -it -p8080:8080 docker.osgeo.org/geoserver: 2.24.2\n

                                                                                Nightly Build

                                                                                docker run -it -p8080:8080 docker.osgeo.org/geoserver: 2.24.x\n
                                                                              4. In a web browser, navigate to http://localhost:8080/geoserver.

                                                                                If you see the GeoServer Welcome page, then GeoServer is successfully installed.

                                                                                GeoServer Welcome Page

                                                                              5. This setup is a quick test to ensure the software is working, but is difficult to use as file data can only be transferred to the data directory included with the container via the REST API.

                                                                              "},{"location":"installation/docker/#using-your-own-data-directory","title":"Using your own Data Directory","text":"

                                                                              This will run the container with a local data directory. The data directory will be mounted into the docker container.

                                                                              Note

                                                                              Change /MY/DATADIRECTORY to your data directory. If this directory is empty it will be populated with the standard Geoserver Sample Data Directory.

                                                                              1. Make sure you have Docker installed.

                                                                              2. Download the container

                                                                                Release

                                                                                docker pull docker.osgeo.org/geoserver: 2.24.2\n

                                                                                Nightly Build

                                                                                docker pull docker.osgeo.org/geoserver: 2.24.x\n
                                                                              3. Run the container

                                                                                Release

                                                                                docker run \\-\\-mount type=bind,src=/MY/DATADIRECTORY,target=/opt/geoserver_data -it -p8080:8080 docker.osgeo.org/geoserver: 2.24.2\n

                                                                                Nightly Build

                                                                                docker run \\-\\-mount type=bind,src=/MY/DATADIRECTORY,target=/opt/geoserver_data -it -p8080:8080 docker.osgeo.org/geoserver: 2.24.x\n
                                                                              4. In a web browser, navigate to http://localhost:8080/geoserver.

                                                                                If you see the GeoServer Welcome page, then GeoServer is successfully installed.

                                                                                GeoServer Welcome Page

                                                                              5. This setup allows direct management of the file data shared with the container. This setup is also easy to update to use the latest container.

                                                                              "},{"location":"installation/docker/#adding-geoserver-extensions","title":"Adding GeoServer Extensions","text":"

                                                                              You can add GeoServer Extensions - the container will download them during startup.

                                                                              Release

                                                                              docker run -it -p8080:8080 \\\\\n  \\-\\-env INSTALL_EXTENSIONS=true \\\\\n  \\-\\-env STABLE_EXTENSIONS=\"ysld,h2\" \\\\\n  docker.osgeo.org/geoserver: 2.24.2\n

                                                                              Nightly Build

                                                                              docker run -it -p8080:8080 \\\\\n  \\-\\-env INSTALL_EXTENSIONS=true \\\\\n  \\-\\-env STABLE_EXTENSIONS=\"ysld,h2\" \\\\\n  docker.osgeo.org/geoserver: 2.24.x\n

                                                                              This will download and install the YSLD and H2 extension.

                                                                              Here is a list of available extensions (taken from the build server):

                                                                              app-schema   gdal            jp2k          ogr-wps          web-resource\nauthkey      geofence        libjpeg-turbo oracle           wmts-multi-dimensional\ncas          geofence-server mapml         params-extractor wps-cluster-hazelcast\ncharts       geopkg-output   mbstyle       printing         wps-download\ncontrol-flow grib            mongodb       pyramid          wps-jdbc\ncss          gwc-s3          monitor       querylayer       wps\ncsw          h2              mysql         sldservice       xslt\ndb2          imagemap        netcdf-out    sqlserver        ysld\ndxf          importer        netcdf        vectortiles      \nexcel        inspire         ogr-wfs       wcs2_0-eo\n
                                                                              "},{"location":"installation/docker/#testing-geoserver-community-modules","title":"Testing Geoserver Community modules","text":"

                                                                              Working with a Nightly build is a good way to test community modules and provide feedback to developers working on new functionality.

                                                                              To work with community modules you must be using the GeoServer 2.24.x nightly build that matches the community module build:

                                                                              docker run -it -p8080:8080 \\\\\n  \\-\\-env INSTALL_EXTENSIONS=true \\\\\n  \\-\\-env STABLE_EXTENSIONS=\"ysld,h2\" \\\\\n  \\-\\-env COMMUNITY_EXTENSIONS=\"ogcapi-features,ogcapi-images,ogcapi-maps,ogcapi-styles,ogcapi-tiles\" \\\\\n  docker.osgeo.org/geoserver: 2.24.x\n

                                                                              For the current list see GeoServer build server.

                                                                              activeMQ-broker            jdbcconfig                 pgraster                    \nbackup-restore             jdbcstore                  proxy-base-ext              \ncog                        jms-cluster                s3-geotiff                  \ncolormap                   libdeflate                 sec-keycloak             \ncov-json                   mbtiles                    sec-oauth2-geonode          \ndds                        mbtiles-store              sec-oauth2-github           \ndyndimension               mongodb-schemaless         sec-oauth2-google           \nelasticsearch              ncwms                      sec-oauth2-openid-connect   \nfeatures-templating        netcdf-ghrsst              smart-data-loader           \nflatgeobuf                 notification               solr                        \ngdal-wcs                   ogcapi-coverages           spatialjson                 \ngdal-wps                   ogcapi-dggs                stac-datastore              \ngeopkg                     ogcapi-features            taskmanager-core            \ngpx                        ogcapi-images              taskmanager-s3              \ngsr                        ogcapi-maps                vector-mosaic\ngwc-azure-blobstore        ogcapi-styles              vsi                         \ngwc-distributed            ogcapi-tiled-features      webp                        \ngwc-mbtiles                ogcapi-tiles               wps-remote\ngwc-sqlite                 ogr-datastore              rat\nhz-cluster                 opensearch-eo                          \nimporter-jdbc              \njdbc-metrics\n
                                                                              "},{"location":"installation/linux/","title":"Linux binary","text":"

                                                                              Note

                                                                              For installing on Linux with an existing application server such as Tomcat, please see the Web archive section.

                                                                              The platform-independent binary is a GeoServer web application bundled inside Jetty, a lightweight and portable application server. It has the advantages of working very similarly across all operating systems and is very simple to set up.

                                                                              "},{"location":"installation/linux/#installation","title":"Installation","text":"
                                                                              1. Make sure you have a Java Runtime Environment (JRE) installed on your system. GeoServer requires a Java 11 or Java 17 environment, available from OpenJDK, Adoptium, or provided by your OS distribution.

                                                                                Note

                                                                                For more information about Java and GeoServer compatibility, please see the section on Java Considerations.

                                                                              2. Navigate to the GeoServer Download page.

                                                                              3. Select the version of GeoServer that you wish to download. If you're not sure, select Stable release.

                                                                                Nightly Build

                                                                                These instructions are for GeoServer 2.24-SNAPSHOT which is provided as a Nightly release. Testing a Nightly release is a great way to try out new features, and test community modules. Nightly releases change on an ongoing basis and are not suitable for a production environment.

                                                                                Release

                                                                                These instructions are for GeoServer 2.24.2.

                                                                              4. Select Platform Independent Binary on the download page: geoserver-2.24.2-bin.zip

                                                                              5. Download the zip archive and unpack to the directory where you would like the program to be located.

                                                                                Note

                                                                                A suggested location would be /usr/share/geoserver.

                                                                              6. Add an environment variable to save the location of GeoServer by typing the following command:

                                                                                echo \"export GEOSERVER_HOME=/usr/share/geoserver\" >> ~/.profile\n. ~/.profile\n
                                                                              7. Make yourself the owner of the geoserver folder. Type the following command in the terminal window, replacing USER_NAME with your own username :

                                                                                sudo chown -R USER_NAME /usr/share/geoserver/\n
                                                                              8. Start GeoServer by changing into the directory geoserver/bin and executing the startup.sh script:

                                                                                cd geoserver/bin\nsh startup.sh\n
                                                                              9. In a web browser, navigate to http://localhost:8080/geoserver.

                                                                                If you see the GeoServer Welcome page, then GeoServer is successfully installed.

                                                                                GeoServer Welcome Page

                                                                              10. To shut down GeoServer, either close the persistent command-line window, or run the shutdown.sh file inside the bin directory.

                                                                              "},{"location":"installation/linux/#uninstallation","title":"Uninstallation","text":"
                                                                              1. Stop GeoServer (if it is running).
                                                                              2. Delete the directory where GeoServer is installed.
                                                                              "},{"location":"installation/upgrade/","title":"Upgrading existing versions","text":"

                                                                              Warning

                                                                              Be aware that some upgrades are not reversible, meaning that the data directory may be changed so that it is no longer compatible with older versions of GeoServer. See Migrating a data directory between versions for more details.

                                                                              The general GeoServer upgrade process is as follows:

                                                                              1. Back up the current data directory. This can involve simply copying the directory to an additional place.

                                                                              2. Make sure that the current data directory is external to the application (not located inside the application file structure).

                                                                                Check the GeoServer Server status page to double check the data directory location.

                                                                              3. Make a note of any extensions you have installed.

                                                                                • The GeoServer About \u2192 Server Status page provides a Modules tab listing the modules installed.
                                                                                • Some extensions include more than one module, as an example the WPS extension is listed as gs-wps-core and gs-web-wps.
                                                                              4. Uninstall the old version and install the new version.

                                                                                • Download maintenance release to update existing installation
                                                                                • Download stable release when ready to upgrade
                                                                              5. Be sure to download and install each extension used by your prior installation.

                                                                              6. Make sure that the new installation continues to point to the same data directory used by the previous version.

                                                                              "},{"location":"installation/upgrade/#notes-on-upgrading-specific-versions","title":"Notes on upgrading specific versions","text":""},{"location":"installation/upgrade/#freemarker-template-html-auto-escaping-geoserver-225-and-newer","title":"FreeMarker Template HTML Auto-escaping (GeoServer 2.25 and newer)","text":"

                                                                              As of GeoServer 2.25, the FreeMarker library's HTML auto-escaping feature will be enabled by default to prevent cross-site scripting (XSS) vulnerabilities in WMS GetFeatureInfo HTML output when using the default FreeMarker templates and WMS service settings. Some users may experience incorrectly escaped HTML output when using custom templates or if HTML tags are stored in vector data stores.

                                                                              See the FreeMarker Template Auto-escaping page for information about the limitations of this feature and for instructions to disable this feature and delegate to the WMS service setting which defaults to disabling HTML auto-escaping.

                                                                              "},{"location":"installation/upgrade/#spring-security-strict-http-firewall-geoserver-225-and-newer","title":"Spring Security Strict HTTP Firewall (GeoServer 2.25 and newer)","text":"

                                                                              As of GeoServer 2.25, Spring Security's StrictHttpFirewall will be enabled by default which will provide stronger default protection, particularly against potential path traversal vulnerabilities.

                                                                              In some cases valid requests may be blocked if the names of GeoServer resources (e.g., workspaces) contain certain special characters and are included in URL paths. See the Spring Security Firewall page for instructions to disable the strict firewall and revert to the DefaultHttpFirewall used by earlier versions.

                                                                              "},{"location":"installation/upgrade/#wcs-arcgrid-output-format-removal-geoserver-224-and-newer","title":"WCS ArcGRID output format removal (GeoServer 2.24 and newer)","text":"

                                                                              The ArcGRID output format for WCS has been removed in GeoServer 2.24.0. If you have been using this format, you will need to switch to another text based format, such as GML coverage, or can get back the ArcGRID format by installing the WCS GDAL community module and use a configuration like the following (please adapt to your system):

                                                                              <ToolConfiguration>\n  <executable>gdal_translate</executable>\n  <environment>\n    <variable name=\"GDAL_DATA\" value=\"/usr/local/share/gdal\" />\n  </environment>\n  <formats>\n    <Format>\n      <toolFormat>AAIGrid</toolFormat>\n      <geoserverFormat>ArcGrid</geoserverFormat>\n      <fileExtension>.asc</fileExtension>\n      <singleFile>true</singleFile>\n      <mimeType>application/arcgrid</mimeType>\n    </Format>\n  </formats>\n</ToolConfiguration>\n
                                                                              "},{"location":"installation/upgrade/#disk-quota-hsql-db-usage-geoserver-224-and-newer","title":"Disk Quota HSQL DB usage (GeoServer 2.24 and newer)","text":"

                                                                              As of GeoServer 2.24, H2 DB support will be replaced with HSQL DB for Tile Caching / Disk Quota store.

                                                                              • H2 option under \"Disk quota store type\" and \"Target database type\" is replaced with HSQL.
                                                                              • The default store type will be in-process HSQL.
                                                                              • Existing installations with in-process H2 selection will automatically be migrated to in-process HSQL. Old H2 database files will remain in gwc/diskquota_page_store_h2/ under the data directory. You may delete those or leave them for a possible downgrade.
                                                                              • Important: Existing installations with external H2 database selection will not be migrated automatically. You will get an error message at startup and disk quota will be disabled, unless you use a plugin/extension with H2 dependency. But other features of GeoServer will keep working. You can go to Disk Quota page and configure an external HSQL database or switch to in-process HSQL. In case you want to keep using H2 as an in-process/external database, you can add H2 store plugin or any other extension or plugin that has H2 dependency.
                                                                              • GeoServer installations with extensions/plugins having H2 dependency will still have H2 option under \"Disk quota store type\" and \"Target database type\".
                                                                              "},{"location":"installation/upgrade/#remote-requests-control-geoserver-224-and-newer","title":"Remote requests control (GeoServer 2.24 and newer)","text":"

                                                                              As of GeoServer 2.24, remote requests control has been added, and enabled by default, in GeoServer. This feature allows administrators to control which remote requests are allowed to be made to GeoServer. By default, no authorizations are included, thus GeoServer will deny remote requests originating from user interaction. In particular, the following use cases are affected:

                                                                              • WMS operations with remotely fetch styles (sld parameter) and style referencing remote icons (in general, icons outside of the data directory). As a reminder, when a remote icon is not found, GeoServer will fall back to a default icon, a gray square with a black border.
                                                                              • WMS \"feature portrayal\" with dynamic remote WFS references provided in the request (REMOTE_OWS_TYPE and REMOTE_OWS_URL parameters).
                                                                              • WPS remote inputs via either GET or POST request (e.g., remote GeoJSON file source).

                                                                              The list of locations that are safe to contact can be configured using the URL Checks page.

                                                                              "},{"location":"installation/upgrade/#log4j-upgrade-geoserver-221-and-newer","title":"Log4J Upgrade (GeoServer 2.21 and newer)","text":"

                                                                              As of GeoServer 2.21, the logging system used by GeoServer has been upgraded from Log4J 1.2 to Log4J 2.

                                                                              • GeoServer now uses xml files for the built-in logging profiles (previously properties files were used).

                                                                              • The built-in logging profiles are upgraded with xml files:

                                                                                DEFAULT_LOGGING.xml\nDEFAULT_LOGGING.properties.bak\n
                                                                              • A backup of the prior properties files are created during the upgrade process. If you had previously made any customizations to a built-in profiles these backup files may be used as a reference when customizing the xml file.

                                                                              • Log4J 2 does have the ability to read Log4j 1.2 properties files although not all features are supported.

                                                                                Any custom properties files you created will continue to be available for use.

                                                                              • If necessary you can recover a customization you performed to a built-in logging profile by restoring to a different filename. To recover a customization from PRODUCTION_LOGGING.properties.bak rename the file to PRODUCTION_LOGGING.properties.bak to CUSTOM_LOGGING.properties.

                                                                              • If you never plan to customize the built-in logging profiles the UPDATE_BUILT_IN_LOGGING_PROFILES=true system property will always ensure you have our latest recommendation.

                                                                              "},{"location":"installation/upgrade/#jts-type-bindings-geoserver-214-and-newer","title":"JTS Type Bindings (GeoServer 2.14 and newer)","text":"

                                                                              As of GeoServer 2.14, the output produced by REST featuretype and structured coverage requests using a different package name (org.locationtech instead of com.vividsolutions) for geometry type bindings, due to the upgrade to JTS (Java Topology Suite) 1.16.0. For example:

                                                                              Before:

                                                                              ...\n<attribute>\n  <name>geom</name>\n  <minOccurs>0</minOccurs>\n  <maxOccurs>1</maxOccurs>\n  <nillable>true</nillable>\n  <binding>com.vividsolutions.jts.geom.Point</binding>\n</attribute>\n...\n

                                                                              After:

                                                                              ...\n<attribute>\n  <name>geom</name>\n  <minOccurs>0</minOccurs>\n  <maxOccurs>1</maxOccurs>\n  <nillable>true</nillable>\n  <binding>org.locationtech.jts.geom.Point</binding>\n</attribute>\n...\n

                                                                              Any REST clients which rely on this binding information should be updated to support the new names.

                                                                              "},{"location":"installation/upgrade/#geojson-encoding-geoserver-26-and-newer","title":"GeoJSON encoding (GeoServer 2.6 and newer)","text":"

                                                                              As of GeoServer 2.6, the GeoJSON produced by the WFS service no longer uses a non-standard encoding for the CRS. To re-enable this behavior for compatibility purposes, set GEOSERVER_GEOJSON_LEGACY_CRS=true as a system property, context parameter, or environment variable.

                                                                              "},{"location":"installation/war/","title":"Web archive","text":"

                                                                              GeoServer is packaged as a standalone servlet for use with existing application servers such as Apache Tomcat and Jetty.

                                                                              Note

                                                                              GeoServer has been mostly tested using Tomcat, and so is the recommended application server. GeoServer requires a newer version of Tomcat (7.0.65 or later) that implements Servlet 3 and annotation processing. Other application servers have been known to work, but are not guaranteed.

                                                                              "},{"location":"installation/war/#installation","title":"Installation","text":"
                                                                              1. Make sure you have a Java Runtime Environment (JRE) installed on your system. GeoServer requires a Java 11 or Java 17 environment,available from OpenJDK, Adoptium, or provided by your OS distribution.

                                                                                Note

                                                                                For more information about Java and GeoServer compatibility, please see the section on Java Considerations.

                                                                              2. Navigate to the GeoServer Download page.

                                                                              3. Select the version of GeoServer that you wish to download. If you're not sure, select Stable release.

                                                                                Nightly Build

                                                                                These instructions are for GeoServer 2.24-SNAPSHOT which is provided as a Nightly release. Testing a Nightly release is a great way to try out new features, and test community modules. Nightly releases change on an ongoing basis and are not suitable for a production environment.

                                                                                Release

                                                                                These instructions are for GeoServer 2.24.2.

                                                                              4. Select Web Archive on the download page: geoserver-2.24.2-war.zip

                                                                              5. Download and unpack the archive.

                                                                              6. Deploy the web archive as you would normally. Often, all that is necessary is to copy the geoserver.war file to the application server's webapps directory, and the application will be deployed.

                                                                                Note

                                                                                A restart of your application server may be necessary.

                                                                              "},{"location":"installation/war/#tomcat-hardening","title":"Tomcat Hardening","text":"

                                                                              Hide the Tomcat version in error responses and its error details.

                                                                              To remove the Tomcat version, create following file with empty parameters :

                                                                              cd $CATALINA_HOME (where Tomcat binaries are installed)\nmkdir -p ./lib/org/apache/catalina/util/\ncat > ./lib/org/apache/catalina/util/ServerInfo.properties <<EOF\nserver.info=\nserver.number=\nserver.built=\nEOF\n

                                                                              Additionally add to server.xml the ErrorReportValve to disable showReport and showServerInfo. This is used to hide errors handled globally by tomcat in host section.

                                                                              vi ./conf/server.xml

                                                                              Add to <Host name=... section this new ErrorReportValve entry: :

                                                                              ...\n     <Host name=\"localhost\"  appBase=\"webapps\"\n           unpackWARs=\"true\" autoDeploy=\"true\">\n\n       ...\n\n       <Valve className=\"org.apache.catalina.valves.ErrorReportValve\" showReport=\"false\" showServerInfo=\"false\" />\n\n     </Host>\n   </Engine>\n </Service>\n</Server>\n

                                                                              Why, if security by obscurity does not work?

                                                                              Even though this is not the final solution, it at least mitigates the visible eye-catcher of outdated software packages.

                                                                              Let's take the attackers point of view.

                                                                              Response with just HTTP status: :

                                                                              HTTP Status 400 \u2013 Bad Request\n

                                                                              Ok, it looks like a Tomcat is installed.

                                                                              Default full response: :

                                                                              HTTP Status 400 \u2013 Bad Request\nType Status Report\nMessage Invalid URI\nDescription The server cannot or will not process the request due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request message framing, or deceptive request routing).\nApache Tomcat/7.0.67\n

                                                                              Ahh, great, the software is not really maintained. Tomcat is far outdated from Dec. 2015 (6 years old as of today Jan. 2022) with a lot of unfixed vulnerabilities.

                                                                              Notice: For support reason, the local output of version.sh still outputs the current version :

                                                                              $CATALINA_HOME/bin/version.sh\n ...\n Server number:  7.0.67\n ...\n
                                                                              "},{"location":"installation/war/#running","title":"Running","text":"

                                                                              Use your container application's method of starting and stopping webapps to run GeoServer.

                                                                              To access the Web administration interface, open a browser and navigate to http://SERVER/geoserver . For example, with Tomcat running on port 8080 on localhost, the URL would be http://localhost:8080/geoserver.

                                                                              If you see the GeoServer Welcome page, then GeoServer is successfully installed.

                                                                              GeoServer Welcome Page

                                                                              "},{"location":"installation/war/#update","title":"Update","text":"

                                                                              Update regularly at least the container application! And repeat the hardening process.

                                                                              There are a lot of geoserver installations visible with outdated Tomcat versions.

                                                                              "},{"location":"installation/war/#uninstallation","title":"Uninstallation","text":"
                                                                              1. Stop the container application.
                                                                              2. Remove the GeoServer webapp from the container application's webapps directory. This will usually include the geoserver.war file as well as a geoserver directory.
                                                                              "},{"location":"installation/win_binary/","title":"Windows binary","text":"

                                                                              Note

                                                                              For installing on Windows with an existing application server such as Tomcat, please see the Web archive section.

                                                                              The other way of installing GeoServer on Windows is to use the platform-independent binary. This version is a GeoServer web application bundled inside Jetty, a lightweight and portable application server. It has the advantages of working very similarly across all operating systems and is very simple to set up.

                                                                              "},{"location":"installation/win_binary/#installation","title":"Installation","text":"
                                                                              1. Make sure you have a Java Runtime Environment (JRE) installed on your system. GeoServer requires a Java 11 or Java 17 environment, as provided by Adoptium Windows installers.

                                                                                Note

                                                                                For more information about Java and GeoServer, please see the section on Java Considerations.

                                                                              2. Navigate to the GeoServer Download page.

                                                                              3. Select the version of GeoServer that you wish to download. If you're not sure, select Stable release.

                                                                                Nightly Build

                                                                                These instructions are for GeoServer 2.24-SNAPSHOT which is provided as a Nightly release. Testing a Nightly release is a great way to try out new features, and test community modules. Nightly releases change on an ongoing basis and are not suitable for a production environment.

                                                                                Release

                                                                                These instructions are for GeoServer 2.24.2.

                                                                              4. Select Platform Independent Binary on the download page: geoserver-2.24.2-bin.zip

                                                                              5. Download the archive and unpack to the directory where you would like the program to be located.

                                                                                Note

                                                                                A suggested location would be C:\\\\Program Files\\GeoServer.

                                                                              "},{"location":"installation/win_binary/#setting-environment-variables","title":"Setting environment variables","text":"

                                                                              You will need to set the JAVA_HOME environment variable if it is not already set. This is the path to your JRE such that %JAVA_HOME%\\bin\\java.exe exists.

                                                                              1. Navigate to Control Panel \u2192 System \u2192 Advanced \u2192 Environment Variables.
                                                                              2. Under System variables click New.
                                                                              3. For Variable name enter JAVA_HOME. For Variable value enter the path to your JDK/JRE.
                                                                              4. Click OK three times.

                                                                              Note

                                                                              You may also want to set the GEOSERVER_HOME variable, which is the directory where GeoServer is installed, and the GEOSERVER_DATA_DIR variable, which is the location of the GeoServer data directory (which by default is %GEOSERVER_HOME\\data_dir). The latter is mandatory if you wish to use a data directory other than the default location. The procedure for setting these variables is identical to setting the JAVA_HOME variable.

                                                                              "},{"location":"installation/win_binary/#running","title":"Running","text":"

                                                                              Note

                                                                              This can be done either via Windows Explorer or the command line.

                                                                              1. Navigate to the bin directory inside the location where GeoServer is installed.

                                                                              2. Run startup.bat. A command-line window will appear and persist. This window contains diagnostic and troubleshooting information. This window must be left open, otherwise GeoServer will shut down.

                                                                              3. Navigate to http://localhost:8080/geoserver (or wherever you installed GeoServer) to access the GeoServer Web administration interface.

                                                                                If you see the GeoServer Welcome page, then GeoServer is successfully installed.

                                                                                GeoServer Welcome Page

                                                                              "},{"location":"installation/win_binary/#stopping","title":"Stopping","text":"

                                                                              To shut down GeoServer, either close the persistent command-line window, or run the shutdown.bat file inside the bin directory.

                                                                              "},{"location":"installation/win_binary/#uninstallation","title":"Uninstallation","text":"
                                                                              1. Stop GeoServer (if it is running).
                                                                              2. Delete the directory where GeoServer is installed.
                                                                              "},{"location":"installation/win_installer/","title":"Windows installer","text":"

                                                                              The Windows installer provides an easy way to set up GeoServer on your system, as it requires no configuration files to be edited or command line settings.

                                                                              1. Make sure you have a Java Runtime Environment (JRE) installed on your system. GeoServer requires a Java 11 or Java 17 environment, as provided by Adoptium Windows installers.

                                                                                Note

                                                                                For more information about Java and GeoServer, please see the section on Java Considerations.

                                                                              2. Navigate to the GeoServer Download page.

                                                                              3. Select the version of GeoServer that you wish to download. If you're not sure, select Stable release.

                                                                                Nightly Build

                                                                                This documentation covers GeoServer 2.24-SNAPSHOT which is under development and is available as a Nightly release.

                                                                                Nightly releases are used to test out try out new features and test community modules and do not provide a windows installer. When GeoServer 2.24.0 is released a windows installer will be provided.

                                                                                Release

                                                                                These instructions are for GeoServer 2.24.2.

                                                                              4. Click the link for the Windows Installer.

                                                                                Downloading the Windows installer

                                                                              5. After downloading, double-click the file to launch.

                                                                              6. At the Welcome screen, click Next.

                                                                                Welcome screen

                                                                              7. Read the License and click I Agree.

                                                                                GeoServer license

                                                                              8. Select the directory of the installation, then click Next.

                                                                                GeoServer install directory

                                                                              9. Select the Start Menu directory name and location, then click Next.

                                                                                Start menu location

                                                                              10. Enter the path to a valid Java Runtime Environment (JRE). GeoServer requires a valid JRE in order to run, so this step is required. The installer will inspect your system and attempt to automatically populate this box with a JRE if it is found, but otherwise you will have to enter this path manually. When finished, click Next.

                                                                                Note

                                                                                A typical path on Windows would be C:\\Program Files\\Java\\jre8.

                                                                                Note

                                                                                Don't include the \\bin in the JRE path. So if java.exe is located at C:\\Program Files (x86)\\Java\\jre8\\bin\\java.exe, set the path to be C:\\Program Files (x86)\\Java\\jre8.

                                                                                Note

                                                                                For more information about Java and GeoServer, please see the section on Java Considerations.

                                                                                Selecting a valid JRE

                                                                              11. Enter the path to your GeoServer data directory or select the default. If this is your first time using GeoServer, select the Default data directory. When finished, click Next.

                                                                                Setting a GeoServer data directory

                                                                              12. Enter the username and password for administration of GeoServer. GeoServer's Web administration interface requires authentication for management, and what is entered here will become those administrator credentials. The defaults are admin / geoserver. It is recommended to change these from the defaults. When finished, click Next.

                                                                                Setting the username and password for GeoServer administration

                                                                              13. Enter the port that GeoServer will respond on. This affects the location of the GeoServer Web administration interface, as well as the endpoints of the GeoServer services such as Web Map Service (WMS) and Web Feature Service (WFS). The default port is 8080, though any valid and unused port will work. When finished, click Next.

                                                                                Setting the GeoServer port

                                                                              14. Select whether GeoServer should be run manually or installed as a service. When run manually, GeoServer is run like a standard application under the current user. When installed as a service, GeoServer is integrated into Windows Services, and thus is easier to administer. If running on a server, or to manage GeoServer as a service, select Install as a service. Otherwise, select Run manually. When finished, click Next.

                                                                                Installing GeoServer as a service

                                                                              15. Review your selections and click the Back button if any changes need to be made. Otherwise, click Install.

                                                                                Verifying settings

                                                                              16. GeoServer will install on your system.

                                                                                Install progress

                                                                              17. When finished, click Finish to close the installer.

                                                                                Completing

                                                                              18. If you installed GeoServer as a service, it is already running. Otherwise, you can start GeoServer by going to the Start Menu, and clicking Start GeoServer in the GeoServer folder.

                                                                              19. Navigate to http://localhost:8080/geoserver (or wherever you installed GeoServer) to access the GeoServer Web administration interface.

                                                                                If you see the GeoServer Welcome page, then GeoServer is successfully installed.

                                                                                GeoServer Welcome Page

                                                                              "},{"location":"installation/win_installer/#uninstallation","title":"Uninstallation","text":"

                                                                              GeoServer can be uninstalled in two ways: by running the uninstall.exe file in the directory where GeoServer was installed, or by standard Windows program removal.

                                                                              "},{"location":"introduction/","title":"Introduction","text":"

                                                                              This section gives an overview of GeoServer the project, its background, and what it can do for you.

                                                                              For those who wish to get started with GeoServer right away, feel free to skip to the Installation section.

                                                                              • Overview
                                                                              • History
                                                                              • Getting involved
                                                                              • License
                                                                              "},{"location":"introduction/gettinginvolved/","title":"Getting involved","text":"

                                                                              GeoServer exists because of the efforts of people like you.

                                                                              There are many ways that you can help out with the GeoServer project. GeoServer fully embraces an open source development model that does not see a split between user and developer, producer and consumer, but instead sees everyone as a valuable contributor.

                                                                              "},{"location":"introduction/gettinginvolved/#development","title":"Development","text":"

                                                                              Helping to develop GeoServer is the obvious way to help out. Developers usually start with bug fixes and other small patches, and then move into larger contributions as they learn the system. Our developers are more than happy to help out as you learn and get acquainted. We try our hardest to keep our code clean and well documented.

                                                                              You can find the project on GitHub. As part of the GitHub model, anyone can submit patches as pull requests, which will be evaluated by the team. To learn more about contributing to the GeoServer codebase, we highly recommend joining the GeoServer developers mailing list. See details below.

                                                                              "},{"location":"introduction/gettinginvolved/#documentation","title":"Documentation","text":"

                                                                              Another crucial way to help out is with documentation. Whether it's adding tutorials or just correcting mistakes, every contribution serves to make the project more healthy. And the best part is that you do not need to be a developer in order to contribute.

                                                                              Our official documentation is contained as part of our official code repository. As part of the GitHub model, anyone can submit patches as pull requests, which will be evaluated by the team.

                                                                              To learn more about contributing to the GeoServer codebase, we highly recommend joining the GeoServer developers mailing list (see details below). For typos and other small changes, please see our Documentation Guide for how to make quick fixes.

                                                                              "},{"location":"introduction/gettinginvolved/#mailing-lists","title":"Mailing lists","text":"

                                                                              GeoServer maintains two email lists:

                                                                              • GeoServer Users
                                                                              • GeoServer Developers

                                                                              The Users list is mainly for those who have questions relating to the use of GeoServer, and the Developers list is for more code-specific and roadmap-based discussions. If you see a question asked on these lists that you know the answer to, please respond!

                                                                              These lists are publicly available and are a great resource for those who are new to GeoServer, who need a question answered, or who are interested in contributing code.

                                                                              "},{"location":"introduction/gettinginvolved/#irc","title":"IRC","text":"

                                                                              Users can join the IRC channel, #geoserver, on the Freenode network, in order to collaborate in real time. GeoServer developers occasionally will be in this channel as well.

                                                                              "},{"location":"introduction/gettinginvolved/#bug-tracking","title":"Bug tracking","text":"

                                                                              If you have a problem when working with GeoServer, then please let us know through the mailing lists. GeoServer uses JIRA , a bug tracking website, to manage issue reports. In order to submit an issue, you'll need to create an account first.

                                                                              Everyone is encouraged to submit patches and, if possible, fix issues as well. We welcome patches through JIRA, or pull requests to GitHub.

                                                                              Responsible Disclosure

                                                                              Warning

                                                                              If you encounter a security vulnerability in GeoServer please take care to report the issue in a responsible fashion:

                                                                              • Keep exploit details out of issue report (send to developer/PSC privately -- just like you would do for sensitive sample data)
                                                                              • Mark the issue as a vulnerability.
                                                                              • Be prepared to work with Project Steering Committee (PSC) members on a solution

                                                                              Keep in mind PSC members are volunteers and an extensive fix may require fundraising / resources

                                                                              If you are not in position to communicate in public please consider commercial support, contacting a PSC member, or reaching us via the Open Source Geospatial Foundation at info@osgeo.org.

                                                                              "},{"location":"introduction/gettinginvolved/#translation","title":"Translation","text":"

                                                                              We would like GeoServer available in as many languages as possible. The two areas of GeoServer to translate are the text that appears in the Web administration interface and this documentation. If you are interested in helping with this task, please let us know via the mailing lists.

                                                                              "},{"location":"introduction/gettinginvolved/#suggest-improvements","title":"Suggest improvements","text":"

                                                                              If you have suggestions as to how we can make GeoServer better, we would love to hear them. You can contact us through the mailing lists or submit a feature request through JIRA.

                                                                              "},{"location":"introduction/gettinginvolved/#spread-the-word","title":"Spread the word","text":"

                                                                              A further way to help out the GeoServer project is to spread the word. Word-of-mouth information sharing is more powerful than any marketing, and the more people who use our software, the better it will become.

                                                                              "},{"location":"introduction/gettinginvolved/#fund-improvements","title":"Fund improvements","text":"

                                                                              A final way to help out is to push for GeoServer to be used in your own organization. A number of commercial organizations offer support for GeoServer, and any improvements made due to that funding will benefit the entire GeoServer community.

                                                                              "},{"location":"introduction/history/","title":"History","text":"

                                                                              GeoServer was started in 2001 by The Open Planning Project (TOPP), a non-profit technology incubator based in New York. TOPP was creating a suite of tools to enable open democracy and to help make government more transparent. The first of these was GeoServer, which came out of a recognition that a suite of tools to enable citizen involvement in government and urban planning would be greatly enhanced by the ability to share spatial data.

                                                                              The GeoServer founders envisioned a Geospatial Web, analogous to the World Wide Web. With the World Wide Web, one can search for and download text. With the Geospatial Web, one can search for and download spatial data. Data providers would be able to publish their data straight to this web, and users could directly access it, as opposed to the now indirect and cumbersome methods of sharing data that exist today.

                                                                              Those involved with GeoServer founded the GeoTools project, an open source GIS Java toolkit. Through GeoTools, support for shapefiles, Oracle databases, and much more was added.

                                                                              Around the same time as GeoServer was founded, The OpenGIS Consortium (now the Open Geospatial Consortium) was working on the Web Feature Service standard. It specifies a protocol to make spatial data directly available on the web, using GML (Geographic Markup Language), an interoperable data format. A Web Map Service was also created, a protocol for creating and displaying map images created from spatial data.

                                                                              Other projects became interrelated. Refractions Research created PostGIS, a free and open spatial database, which enabled GeoServer to connect to a free database. Also, MetaCarta originally created OpenLayers, an open source browser-based map viewing utility. Together, these tools have all enhanced the functionality of GeoServer.

                                                                              GeoServer can now read data from over a dozen spatial data sources and output to many different formats. Now in its second decade, GeoServer is continuing on its mission to make spatial data more accessible to all.

                                                                              "},{"location":"introduction/license/","title":"License","text":"

                                                                              For complete license information NOTICE.txt.

                                                                              GeoServer is free software and is licensed under the GNU General Public License:

                                                                              GeoServer, open geospatial information server Copyright (C) 2014-2020 Open Source Geospatial Foundation. Copyright (C) 2001-2014 OpenPlans

                                                                              This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version (collectively, \"GPL\").

                                                                              As an exception to the terms of the GPL, you may copy, modify, propagate, and distribute a work formed by combining GeoServer with the EMF, XSD and OSHI Libraries, or a work derivative of such a combination, even if such copying, modification, propagation, or distribution would otherwise violate the terms of the GPL. Nothing in this exception exempts you from complying with the GPL in all respects for all of the code used other than the EMF, XSD and OSHI Libraries. You may include this exception and its grant of permissions when you distribute GeoServer. Inclusion of this notice with such a distribution constitutes a grant of such permissions. If you do not wish to grant these permissions, remove this paragraph from your distribution. \"GeoServer\" means the GeoServer software licensed under version 2 or any later version of the GPL, or a work based on such software and licensed under the GPL. \"EMF, XSD and OSHI Libraries\" means Eclipse Modeling Framework Project and XML Schema Definition software distributed by the Eclipse Foundation and the OSHI library, all licensed under the Eclipse Public License Version 1.0 (\"EPL\"), or a work based on such software and licensed under the EPL.

                                                                              This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

                                                                              You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Suite 500, Boston, MA 02110-1335 USA

                                                                              This product includes software developed by the Apache Software Foundation (http://www.apache.org/) licensed under the Apache License Version 2.0 and Apache License Version 1.1.

                                                                              This product includes software developed by the Eclipse Software Foundation under the Eclipse Public License.

                                                                              "},{"location":"introduction/overview/","title":"Overview","text":"

                                                                              GeoServer is an open source software server written in Java that allows users to share and edit geospatial data. Designed for interoperability, it publishes data from any major spatial data source using open standards.

                                                                              Being a community-driven project, GeoServer is developed, tested, and supported by a diverse group of individuals and organizations from around the world.

                                                                              GeoServer is the reference implementation of the Open Geospatial Consortium (OGC) Web Feature Service (WFS) and Web Coverage Service (WCS) standards, as well as a high performance certified compliant Web Map Service (WMS). GeoServer forms a core component of the Geospatial Web.

                                                                              "},{"location":"introduction/download/GPL/","title":"GPL","text":""},{"location":"introduction/download/GPL/#gnu-general-public-license","title":"GNU GENERAL PUBLIC LICENSE","text":"

                                                                              Version 2, June 1991

                                                                              Copyright (C) 1989, 1991 Free Software Foundation, Inc.  \n51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA\n\nEveryone is permitted to copy and distribute verbatim copies\nof this license document, but changing it is not allowed.\n
                                                                              "},{"location":"introduction/download/GPL/#preamble","title":"Preamble","text":"

                                                                              The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users. This General Public License applies to most of the Free Software Foundation's software and to any other program whose authors commit to using it. (Some other Free Software Foundation software is covered by the GNU Lesser General Public License instead.) You can apply it to your programs, too.

                                                                              When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs; and that you know you can do these things.

                                                                              To protect your rights, we need to make restrictions that forbid anyone to deny you these rights or to ask you to surrender the rights. These restrictions translate to certain responsibilities for you if you distribute copies of the software, or if you modify it.

                                                                              For example, if you distribute copies of such a program, whether gratis or for a fee, you must give the recipients all the rights that you have. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights.

                                                                              We protect your rights with two steps: (1) copyright the software, and (2) offer you this license which gives you legal permission to copy, distribute and/or modify the software.

                                                                              Also, for each author's protection and ours, we want to make certain that everyone understands that there is no warranty for this free software. If the software is modified by someone else and passed on, we want its recipients to know that what they have is not the original, so that any problems introduced by others will not reflect on the original authors' reputations.

                                                                              Finally, any free program is threatened constantly by software patents. We wish to avoid the danger that redistributors of a free program will individually obtain patent licenses, in effect making the program proprietary. To prevent this, we have made it clear that any patent must be licensed for everyone's free use or not licensed at all.

                                                                              The precise terms and conditions for copying, distribution and modification follow.

                                                                              "},{"location":"introduction/download/GPL/#terms-and-conditions-for-copying-distribution-and-modification","title":"TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION","text":"

                                                                              0. This License applies to any program or other work which contains a notice placed by the copyright holder saying it may be distributed under the terms of this General Public License. The \"Program\", below, refers to any such program or work, and a \"work based on the Program\" means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language. (Hereinafter, translation is included without limitation in the term \"modification\".) Each licensee is addressed as \"you\".

                                                                              Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program). Whether that is true depends on what the Program does.

                                                                              1. You may copy and distribute verbatim copies of the Program's source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and give any other recipients of the Program a copy of this License along with the Program.

                                                                              You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee.

                                                                              2. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions:

                                                                              a) You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change.

                                                                              b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.

                                                                              c) If the modified program normally reads commands interactively when run, you must cause it, when started running for such interactive use in the most ordinary way, to print or display an announcement including an appropriate copyright notice and a notice that there is no warranty (or else, saying that you provide a warranty) and that users may redistribute the program under these conditions, and telling the user how to view a copy of this License. (Exception: if the Program itself is interactive but does not normally print such an announcement, your work based on the Program is not required to print an announcement.)

                                                                              These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.

                                                                              Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program.

                                                                              In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License.

                                                                              3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following:

                                                                              a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,

                                                                              b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,

                                                                              c) Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.)

                                                                              The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.

                                                                              If distribution of executable or object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place counts as distribution of the source code, even though third parties are not compelled to copy the source along with the object code.

                                                                              4. You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.

                                                                              5. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Program (or any work based on the Program), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Program or works based on it.

                                                                              6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License.

                                                                              7. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all. For example, if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program.

                                                                              If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply and the section as a whole is intended to apply in other circumstances.

                                                                              It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system, which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice.

                                                                              This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License.

                                                                              8. If the distribution and/or use of the Program is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Program under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License.

                                                                              9. The Free Software Foundation may publish revised and/or new versions of the General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns.

                                                                              Each version is given a distinguishing version number. If the Program specifies a version number of this License which applies to it and \"any later version\", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation.

                                                                              10. If you wish to incorporate parts of the Program into other free programs whose distribution conditions are different, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally.

                                                                              NO WARRANTY

                                                                              11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM \"AS IS\" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.

                                                                              12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

                                                                              "},{"location":"introduction/download/GPL/#end-of-terms-and-conditions","title":"END OF TERMS AND CONDITIONS","text":""},{"location":"introduction/download/GPL/#how-to-apply-these-terms-to-your-new-programs","title":"How to Apply These Terms to Your New Programs","text":"

                                                                              If you develop a new program, and you want it to be of the greatest possible use to the public, the best way to achieve this is to make it free software which everyone can redistribute and change under these terms.

                                                                              To do so, attach the following notices to the program. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the \"copyright\" line and a pointer to where the full notice is found.

                                                                              one line to give the program's name and an idea of what it does.\nCopyright (C) yyyy  name of author\n\nThis program is free software; you can redistribute it and/or\nmodify it under the terms of the GNU General Public License\nas published by the Free Software Foundation; either version 2\nof the License, or (at your option) any later version.\n\nThis program is distributed in the hope that it will be useful,\nbut WITHOUT ANY WARRANTY; without even the implied warranty of\nMERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the\nGNU General Public License for more details.\n\nYou should have received a copy of the GNU General Public License\nalong with this program; if not, write to the Free Software\nFoundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.\n

                                                                              Also add information on how to contact you by electronic and paper mail.

                                                                              If the program is interactive, make it output a short notice like this when it starts in an interactive mode:

                                                                              Gnomovision version 69, Copyright (C) year name of author\nGnomovision comes with ABSOLUTELY NO WARRANTY; for details\ntype `show w'.  This is free software, and you are welcome\nto redistribute it under certain conditions; type `show c' \nfor details.\n

                                                                              The hypothetical commands `show w' and `show c' should show the appropriate parts of the General Public License. Of course, the commands you use may be called something other than `show w' and `show c'; they could even be mouse-clicks or menu items--whatever suits your program.

                                                                              You should also get your employer (if you work as a programmer) or your school, if any, to sign a \"copyright disclaimer\" for the program, if necessary. Here is a sample; alter the names:

                                                                              Yoyodyne, Inc., hereby disclaims all copyright\ninterest in the program `Gnomovision'\n(which makes passes at compilers) written \nby James Hacker.\n\nsignature of Ty Coon, 1 April 1989\nTy Coon, President of Vice\n

                                                                              This General Public License does not permit incorporating your program into proprietary programs. If your program is a subroutine library, you may consider it more useful to permit linking proprietary applications with the library. If this is what you want to do, use the GNU Lesser General Public License instead of this License.

                                                                              "},{"location":"introduction/download/NOTICE/","title":"GeoServer License Notice","text":"

                                                                              GeoServer is distributed under the GNU General Public License Version 2.0 license:

                                                                              GeoServer, open geospatial information server\nCopyright (C) 2014-2020 Open Source Geospatial Foundation.\nCopyright (C) 2001-2014 OpenPlans\n\nThis program is free software; you can redistribute it and/or modify\nit under the terms of the GNU General Public License as published by\nthe Free Software Foundation; either version 2 of the License, or\n(at your option) any later version (collectively, \"GPL\").\n\nAs an exception to the terms of the GPL, you may copy, modify,\npropagate, and distribute a work formed by combining GeoServer with the\nEMF, XSD and OSHI Libraries, or a work derivative of such a combination, even if\nsuch copying, modification, propagation, or distribution would otherwise\nviolate the terms of the GPL. Nothing in this exception exempts you from\ncomplying with the GPL in all respects for all of the code used other\nthan the EMF, XSD and OSHI Libraries. You may include this exception and its grant\nof permissions when you distribute GeoServer.  Inclusion of this notice\nwith such a distribution constitutes a grant of such permissions.  If\nyou do not wish to grant these permissions, remove this paragraph from\nyour distribution. \"GeoServer\" means the GeoServer software licensed\nunder version 2 or any later version of the GPL, or a work based on such\nsoftware and licensed under the GPL. \"EMF, XSD and OSHI Libraries\" means \nEclipse Modeling Framework Project and XML Schema Definition software\ndistributed by the Eclipse Foundation and the OSHI library, all licensed \nunder the Eclipse Public License Version 1.0 (\"EPL\"), or a work based on \nsuch software and licensed under the EPL.\n\nThis program is distributed in the hope that it will be useful,\nbut WITHOUT ANY WARRANTY; without even the implied warranty of\nMERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the\nGNU General Public License for more details.\n\nYou should have received a copy of the GNU General Public License\nalong with this program; if not, write to the Free Software\nFoundation, Inc., 51 Franklin Street, Suite 500, Boston, MA 02110-1335  USA\n

                                                                              For latest contact information of Open Source Geospatial Foundation see the website at https://www.osgeo.org. Current email is info@osgeo.org and address is OSGeo, 14525 SW Millikan #42523, Beaverton, Oregon, United States, 97005-2343.

                                                                              The full GPL license is available in this directory in the file GPL.md

                                                                              "},{"location":"introduction/download/NOTICE/#additional-libraries-and-code-used","title":"Additional Libraries and Code used","text":"

                                                                              GeoServer uses several additional libraries and pieces of code. We are including the appropriate notices in this file. We'd like to thank all the creators of the libraries we rely on, GeoServer would certainly not be possible without them. There are also several LGPL libraries that do not require us to cite them, but we'd like to thank GeoTools - https://geotools.org, JTS - https://locationtech.github.io/jts/ WKB4J https://wkb4j.sourceforge.net, OpenPDF - https://github.com/LibrePDF/OpenPDF, and J. David Eisenberg's PNG encoder https://www.catcode.com/pngencoder/

                                                                              "},{"location":"introduction/download/NOTICE/#neuquant-neural-net-quantization-algorithm","title":"NeuQuant Neural-Net Quantization Algorithm","text":"

                                                                              GeoServer also thanks Anthony Dekker for the NeuQuant Neural-Net Quantization Algorithm. The copyright notice is intact in the source code and also here:

                                                                              /* NeuQuant Neural-Net Quantization Algorithm\n * ------------------------------------------\n *\n * Copyright (c) 1994 Anthony Dekker\n *\n * NEUQUANT Neural-Net quantization algorithm by Anthony Dekker, 1994.\n * See \"Kohonen neural networks for optimal colour quantization\"\n * in \"Network: Computation in Neural Systems\" Vol. 5 (1994) pp 351-367.\n * for a discussion of the algorithm.\n *\n * Any party obtaining a copy of these files from the author, directly or\n * indirectly, is granted, free of charge, a full and unrestricted irrevocable,\n * world-wide, paid up, royalty-free, nonexclusive right and license to deal\n * in this software and documentation files (the \"Software\"), including without\n * limitation the rights to use, copy, modify, merge, publish, distribute, sublicense,\n * and/or sell copies of the Software, and to permit persons who receive\n * copies from any such party to do so, with the only requirement being\n * that this copyright notice remain intact.\n */\n
                                                                              "},{"location":"introduction/download/NOTICE/#gifencoder","title":"GifEncoder","text":"

                                                                              The GeoServer Project also thanks J. M. G. Elliot for his improvements on Jef Poskanzer's GifEncoder. Notice is included below on his Elliot's release to public domain and Poskanzer's original notice (which is new BSD). Source code is included in GeoServer source, with modifications done by David Blasby for The Open Planning Project (now OpenPlans).

                                                                              Since Gif89Encoder includes significant sections of code from Jef Poskanzer's GifEncoder.java, I'm including its notice in this distribution as requested (appended below).

                                                                              As for my part of the code, I hereby release it, on a strictly \"as is\" basis, to the public domain.

                                                                              J. M. G. Elliott 15-Jul-2000

                                                                              ---- from Jef Poskanzer's GifEncoder.java ----

                                                                              // GifEncoder - write out an image as a GIF\n//\n// Transparency handling and variable bit size courtesy of Jack Palevich.\n//\n// Copyright (C) 1996 by Jef Poskanzer <jef@acme.com>.  All rights reserved.\n//\n// Redistribution and use in source and binary forms, with or without\n// modification, are permitted provided that the following conditions\n// are met:\n// 1. Redistributions of source code must retain the above copyright\n//    notice, this list of conditions and the following disclaimer.\n// 2. Redistributions in binary form must reproduce the above copyright\n//    notice, this list of conditions and the following disclaimer in the\n//    documentation and/or other materials provided with the distribution.\n//\n// THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND\n// ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE\n// IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE\n// ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE\n// FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL\n// DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS\n// OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)\n// HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT\n// LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY\n// OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF\n// SUCH DAMAGE.\n//\n// Visit the ACME Labs Java page for up-to-date versions of this and other\n// fine Java utilities: https://www.acme.com/java/\n
                                                                              "},{"location":"introduction/download/NOTICE/#jai-imageio","title":"JAI ImageIO","text":"

                                                                              JAI ImageIO jars from Sun are also included. These are released under a BSD license (new). Notice is below:

                                                                              Initial sources\n\nCopyright (c) 2005 Sun Microsystems, Inc. All  Rights Reserved.\n\nRedistribution and use in source and binary forms, with or without\nmodification, are permitted provided that the following conditions\nare met:\n\n- Redistribution of source code must retain the above copyright \n  notice, this  list of conditions and the following disclaimer.\n\n- Redistribution in binary form must reproduce the above copyright\n  notice, this list of conditions and the following disclaimer in \n  the documentation and/or other materials provided with the\n  distribution.\n\nNeither the name of Sun Microsystems, Inc. or the names of \ncontributors may be used to endorse or promote products derived \nfrom this software without specific prior written permission.\n\nThis software is provided \"AS IS,\" without a warranty of any \nkind. ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND \nWARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, \nFITNESS FOR A PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE HEREBY\nEXCLUDED. SUN MIDROSYSTEMS, INC. (\"SUN\") AND ITS LICENSORS SHALL \nNOT BE LIABLE FOR ANY DAMAGES SUFFERED BY LICENSEE AS A RESULT OF \nUSING, MODIFYING OR DISTRIBUTING THIS SOFTWARE OR ITS\nDERIVATIVES. IN NO EVENT WILL SUN OR ITS LICENSORS BE LIABLE FOR \nANY LOST REVENUE, PROFIT OR DATA, OR FOR DIRECT, INDIRECT, SPECIAL,\nCONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, HOWEVER CAUSED AND\nREGARDLESS OF THE THEORY OF LIABILITY, ARISING OUT OF THE USE OF OR\nINABILITY TO USE THIS SOFTWARE, EVEN IF SUN HAS BEEN ADVISED OF THE\nPOSSIBILITY OF SUCH DAMAGES.\n\nYou acknowledge that this software is not designed or intended for \nuse in the design, construction, operation or maintenance of any \nnuclear facility.\n
                                                                              "},{"location":"introduction/download/NOTICE/#jetty","title":"Jetty","text":"

                                                                              GeoServer also includes binaries and from Jetty, the standard version can be found at https://www.eclipse.org/jetty/, released under an OSI-approved artistic license. We include the license completely, as some versions will be distributed without full source.

                                                                              Jetty License $Revision: 3.7 $ Preamble:

                                                                              The intent of this document is to state the conditions under which the Jetty Package may be copied, such that the Copyright Holder maintains some semblance of control over the development of the package, while giving the users of the package the right to use, distribute and make reasonable modifications to the Package in accordance with the goals and ideals of the Open Source concept as described at https://www.opensource.org.

                                                                              It is the intent of this license to allow commercial usage of the Jetty package, so long as the source code is distributed or suitable visible credit given or other arrangements made with the copyright holders.

                                                                              Definitions:

                                                                              • \"Jetty\" refers to the collection of Java classes that are distributed as a HTTP server with servlet capabilities and associated utilities.

                                                                              • \"Package\" refers to the collection of files distributed by the Copyright Holder, and derivatives of that collection of files created through textual modification.

                                                                              • \"Standard Version\" refers to such a Package if it has not been modified, or has been modified in accordance with the wishes of the Copyright Holder.

                                                                              • \"Copyright Holder\" is whoever is named in the copyright or copyrights for the package. Mort Bay Consulting Pty. Ltd. (Australia) is the \"Copyright Holder\" for the Jetty package.

                                                                              • \"You\" is you, if you're thinking about copying or distributing this Package.

                                                                              • \"Reasonable copying fee\" is whatever you can justify on the basis of media cost, duplication charges, time of people involved, and so on. (You will not be required to justify it to the Copyright Holder, but only to the computing community at large as a market that must bear the fee.)

                                                                              • \"Freely Available\" means that no fee is charged for the item itself, though there may be fees involved in handling the item. It also means that recipients of the item may redistribute it under the same conditions they received it.

                                                                              • The Jetty Package is Copyright \u00a9 Mort Bay Consulting Pty. Ltd. (Australia) and others. Individual files in this package may contain additional copyright notices. The javax.servlet packages are copyright Sun Microsystems Inc.

                                                                              • The Standard Version of the Jetty package is available from https://jetty.mortbay.org.

                                                                              • You may make and distribute verbatim copies of the source form of the Standard Version of this Package without restriction, provided that you include this license and all of the original copyright notices and associated disclaimers.

                                                                              • You may make and distribute verbatim copies of the compiled form of the Standard Version of this Package without restriction, provided that you include this license.

                                                                              • You may apply bug fixes, portability fixes and other modifications derived from the Public Domain or from the Copyright Holder. A Package modified in such a way shall still be considered the Standard Version.

                                                                              • You may otherwise modify your copy of this Package in any way, provided that you insert a prominent notice in each changed file stating how and when you changed that file, and provided that you do at least ONE of the following:

                                                                                a) Place your modifications in the Public Domain or otherwise make them Freely Available, such as by posting said modifications to Usenet or an equivalent medium, or placing the modifications on a major archive site such as ftp.uu.net, or by allowing the Copyright Holder to include your modifications in the Standard Version of the Package.

                                                                                b) Use the modified Package only within your corporation or organization.

                                                                                c) Rename any non-standard classes so the names do not conflict with standard classes, which must also be provided, and provide a separate manual page for each non-standard class that clearly documents how it differs from the Standard Version.

                                                                                d) Make other arrangements with the Copyright Holder.

                                                                              • You may distribute modifications or subsets of this Package in source code or compiled form, provided that you do at least ONE of the following:

                                                                                a) Distribute this license and all original copyright messages, together with instructions (in the about dialog, manual page or equivalent) on where to get the complete Standard Version.

                                                                                b) Accompany the distribution with the machine-readable source of the Package with your modifications. The modified package must include this license and all of the original copyright notices and associated disclaimers, together with instructions on where to get the complete Standard Version.

                                                                                c) Make other arrangements with the Copyright Holder.

                                                                              • You may charge a reasonable copying fee for any distribution of this Package. You may charge any fee you choose for support of this Package. You may not charge a fee for this Package itself. However, you may distribute this Package in aggregate with other (possibly commercial) programs as part of a larger (possibly commercial) software distribution provided that you meet the other distribution requirements of this license.

                                                                              • Input to or the output produced from the programs of this Package do not automatically fall under the copyright of this Package, but belong to whomever generated them, and may be sold commercially, and may be aggregated with this Package.

                                                                              • Any program subroutines supplied by you and linked into this Package shall not be considered part of this Package.

                                                                              • The name of the Copyright Holder may not be used to endorse or promote products derived from this software without specific prior written permission.

                                                                              • This license may change with each release of a Standard Version of the Package. You may choose to use the license associated with version you are using or the license of the latest Standard Version.

                                                                              • THIS PACKAGE IS PROVIDED \"AS IS\" AND WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.

                                                                              • If any superior law implies a warranty, the sole remedy under such shall be , at the Copyright Holders option either a) return of any price paid or b) use or reasonable endeavours to repair or replace the software.

                                                                              • This license shall be read under the laws of Australia.

                                                                              "},{"location":"introduction/download/NOTICE/#prototype-library-mit-license","title":"Prototype library (MIT License)","text":"

                                                                              GeoServer includes a few snippets from the Prototype library (www.prototypejs.org), under a MIT license:

                                                                              Copyright (c) 2005-2007 Sam Stephenson\n\nPermission is hereby granted, free of charge, to any person obtaining a copy\nof this software and associated documentation files (the \"Software\"), to deal\nin the Software without restriction, including without limitation the rights\nto use, copy, modify, merge, publish, distribute, sublicense, and/or sell\ncopies of the Software, and to permit persons to whom the Software is\nfurnished to do so, subject to the following conditions:\n\nTHE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\nIMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\nFITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE\nAUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\nLIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,\nOUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE\nSOFTWARE.\n
                                                                              "},{"location":"introduction/download/NOTICE/#apache-license","title":"Apache License","text":"

                                                                              GeoServer uses a number of libraries licensed under the Apache License, Version 2.0. These include Spring - https://www.springsource.org/, a number of Apache commons libraries - https://jakarta.apache.org/commons/ whose jars we distribute and include in our source tree under lib/. Also included as libraries are log4 https://logging.apache.org/log4j/docs/index.htmlj, batik https://xmlgraphics.apache.org/batik/, and xerces https://xerces.apache.org/xerces-j/.

                                                                              Note there is some disagreement as to whether GPL and Apache 2.0 are compatible see https://www.apache.org/licenses/GPL-compatibility.html for more information. We hope that something will work out, as GeoServer would not be possible without apache libraries.

                                                                              Notice for apache license is included below:

                                                                              Apache License Version 2.0, January 2004 https://www.apache.org/licenses/

                                                                              TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION

                                                                              1. Definitions.

                                                                              \"License\" shall mean the terms and conditions for use, reproduction, and distribution as defined by Sections 1 through 9 of this document.

                                                                              \"Licensor\" shall mean the copyright owner or entity authorized by the copyright owner that is granting the License.

                                                                              \"Legal Entity\" shall mean the union of the acting entity and all other entities that control, are controlled by, or are under common control with that entity. For the purposes of this definition, \"control\" means (i) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (ii) ownership of fifty percent (50%) or more of the outstanding shares, or (iii) beneficial ownership of such entity.

                                                                              \"You\" (or \"Your\") shall mean an individual or Legal Entity exercising permissions granted by this License.

                                                                              \"Source\" form shall mean the preferred form for making modifications, including but not limited to software source code, documentation source, and configuration files.

                                                                              \"Object\" form shall mean any form resulting from mechanical transformation or translation of a Source form, including but not limited to compiled object code, generated documentation, and conversions to other media types.

                                                                              \"Work\" shall mean the work of authorship, whether in Source or Object form, made available under the License, as indicated by a copyright notice that is included in or attached to the work (an example is provided in the Appendix below).

                                                                              \"Derivative Works\" shall mean any work, whether in Source or Object form, that is based on (or derived from) the Work and for which the editorial revisions, annotations, elaborations, or other modifications represent, as a whole, an original work of authorship. For the purposes of this License, Derivative Works shall not include works that remain separable from, or merely link (or bind by name) to the interfaces of, the Work and Derivative Works thereof.

                                                                              \"Contribution\" shall mean any work of authorship, including the original version of the Work and any modifications or additions to that Work or Derivative Works thereof, that is intentionally submitted to Licensor for inclusion in the Work by the copyright owner or by an individual or Legal Entity authorized to submit on behalf of the copyright owner. For the purposes of this definition, \"submitted\" means any form of electronic, verbal, or written communication sent to the Licensor or its representatives, including but not limited to communication on electronic mailing lists, source code control systems, and issue tracking systems that are managed by, or on behalf of, the Licensor for the purpose of discussing and improving the Work, but excluding communication that is conspicuously marked or otherwise designated in writing by the copyright owner as \"Not a Contribution.\"

                                                                              \"Contributor\" shall mean Licensor and any individual or Legal Entity on behalf of whom a Contribution has been received by Licensor and subsequently incorporated within the Work.

                                                                              1. Grant of Copyright License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare Derivative Works of, publicly display, publicly perform, sublicense, and distribute the Work and such Derivative Works in Source or Object form.

                                                                              2. Grant of Patent License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work to which such Contribution(s) was submitted. If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed.

                                                                              3. Redistribution. You may reproduce and distribute copies of the Work or Derivative Works thereof in any medium, with or without modifications, and in Source or Object form, provided that You meet the following conditions:

                                                                                1. You must give any other recipients of the Work or Derivative Works a copy of this License; and

                                                                                2. You must cause any modified files to carry prominent notices stating that You changed the files; and

                                                                                3. You must retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Works; and

                                                                                4. If the Work includes a \"NOTICE\" text file as part of its distribution, then any Derivative Works that You distribute must include a readable copy of the attribution notices contained within such NOTICE file, excluding those notices that do not pertain to any part of the Derivative Works, in at least one of the following places: within a NOTICE text file distributed as part of the Derivative Works; within the Source form or documentation, if provided along with the Derivative Works; or, within a display generated by the Derivative Works, if and wherever such third-party notices normally appear. The contents of the NOTICE file are for informational purposes only and do not modify the License. You may add Your own attribution notices within Derivative Works that You distribute, alongside or as an addendum to the NOTICE text from the Work, provided that such additional attribution notices cannot be construed as modifying the License.

                                                                              You may add Your own copyright statement to Your modifications and may provide additional or different license terms and conditions for use, reproduction, or distribution of Your modifications, or for any such Derivative Works as a whole, provided Your use, reproduction, and distribution of the Work otherwise complies with the conditions stated in this License.

                                                                              1. Submission of Contributions. Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions. Notwithstanding the above, nothing herein shall supersede or modify the terms of any separate license agreement you may have executed with Licensor regarding such Contributions.

                                                                              2. Trademarks. This License does not grant permission to use the trade names, trademarks, service marks, or product names of the Licensor, except as required for reasonable and customary use in describing the origin of the Work and reproducing the content of the NOTICE file.

                                                                              3. Disclaimer of Warranty. Unless required by applicable law or agreed to in writing, Licensor provides the Work (and each Contributor provides its Contributions) on an \"AS IS\" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are solely responsible for determining the appropriateness of using or redistributing the Work and assume any risks associated with Your exercise of permissions under this License.

                                                                              4. Limitation of Liability. In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall any Contributor be liable to You for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising as a result of this License or out of the use or inability to use the Work (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if such Contributor has been advised of the possibility of such damages.

                                                                              5. Accepting Warranty or Additional Liability. While redistributing the Work or Derivative Works thereof, You may choose to offer, and charge a fee for, acceptance of support, warranty, indemnity, or other liability obligations and/or rights consistent with this License. However, in accepting such obligations, You may act only on Your own behalf and on Your sole responsibility, not on behalf of any other Contributor, and only if You agree to indemnify, defend, and hold each Contributor harmless for any liability incurred by, or claims asserted against, such Contributor by reason of your accepting any such warranty or additional liability.

                                                                              END OF TERMS AND CONDITIONS

                                                                              "},{"location":"introduction/download/NOTICE/#eclipse-public-license","title":"Eclipse Public License","text":"

                                                                              GeoServer is build using a number of eclipse libraries including emf and xsd made available under the Eclipse Public License.

                                                                              The notice for EPL license is included below:

                                                                              Copyright (c) 2002-2006 IBM Corporation and others.\nAll rights reserved.   This program and the accompanying materials\nare made available under the terms of the Eclipse Public License v1.0\nwhich accompanies this distribution, and is available at\nhttps://www.eclipse.org/legal/epl-v10.html\n
                                                                              "},{"location":"introduction/download/NOTICE/#java-service-launcher-jsl","title":"Java Service Launcher (JSL)","text":"

                                                                              GeoServer uses the Java Service Launcher (JSL) by Michael Roeschter as a wrapper to install GeoServer as a Windows service. The following license applies to this software (taken from https://roeschter.de/#license):

                                                                              JAVA SERVICE LAUNCHER (JSL) is PUBLIC DOMAIN.\n\nThis means the software is FREE. Free means you may use or reuse \nany part of the software. You may package it with commercial software \nand use it in commercial and business environments. \nYou may NOT claim copyright for the JSL software and it's source code \nor any parts of the software and source. \nAny derived work may retain a copyright or be commercialized as long \nas the JSL parts of it are not covered by this copyright.\n\nYou may distribute derived work in executable form and not include \nthe JSL source code if JSL constitues only a minor part of the \nintellectual work (in other words, you can take the executable and \nembed it in a Java application you distribute commercially), but you \nmay not charge in particular for or discriminate against the use of \nthe parts derived from JSL.\n\nDisclaimer: \nThis software is supplied AS IS with no claim of fitness for purpose.\n
                                                                              "},{"location":"introduction/download/apache-1.1/","title":"Apache 1.1","text":""},{"location":"introduction/download/apache-1.1/#the-apache-software-license-version-11","title":"The Apache Software License, Version 1.1","text":"

                                                                              Copyright \u00a9 2000-2002 The Apache Software Foundation. All rights reserved.

                                                                              Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

                                                                              1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.

                                                                              2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

                                                                              3. The end-user documentation included with the redistribution, if any, must include the following acknowledgment:

                                                                                \"This product includes software developed by the Apache Software Foundation (http://www.apache.org/).\"

                                                                              Alternately, this acknowledgment may appear in the software itself, if and wherever such third-party acknowledgments normally appear.

                                                                              1. The names \"Xerces\" and \"Apache Software Foundation\" must not be used to endorse or promote products derived from this software without prior written permission. For written permission, please contact apache@apache.org.
                                                                              2. Products derived from this software may not be called \"Apache\", nor may \"Apache\" appear in their name, without prior written permission of the Apache Software Foundation.

                                                                              THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

                                                                              "},{"location":"introduction/download/apache-2.0/","title":"Apache License","text":"

                                                                              Version 2.0, January 2004 <http://www.apache.org/licenses/>

                                                                              "},{"location":"introduction/download/apache-2.0/#terms-and-conditions-for-use-reproduction-and-distribution","title":"Terms and Conditions for use, reproduction, and distribution","text":""},{"location":"introduction/download/apache-2.0/#1-definitions","title":"1. Definitions","text":"

                                                                              \u201cLicense\u201d shall mean the terms and conditions for use, reproduction, and distribution as defined by Sections 1 through 9 of this document.

                                                                              \u201cLicensor\u201d shall mean the copyright owner or entity authorized by the copyright owner that is granting the License.

                                                                              \u201cLegal Entity\u201d shall mean the union of the acting entity and all other entities that control, are controlled by, or are under common control with that entity. For the purposes of this definition, \u201ccontrol\u201d means (i) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (ii) ownership of fifty percent (50%) or more of the outstanding shares, or (iii) beneficial ownership of such entity.

                                                                              \u201cYou\u201d (or \u201cYour\u201d) shall mean an individual or Legal Entity exercising permissions granted by this License.

                                                                              \u201cSource\u201d form shall mean the preferred form for making modifications, including but not limited to software source code, documentation source, and configuration files.

                                                                              \u201cObject\u201d form shall mean any form resulting from mechanical transformation or translation of a Source form, including but not limited to compiled object code, generated documentation, and conversions to other media types.

                                                                              \u201cWork\u201d shall mean the work of authorship, whether in Source or Object form, made available under the License, as indicated by a copyright notice that is included in or attached to the work (an example is provided in the Appendix below).

                                                                              \u201cDerivative Works\u201d shall mean any work, whether in Source or Object form, that is based on (or derived from) the Work and for which the editorial revisions, annotations, elaborations, or other modifications represent, as a whole, an original work of authorship. For the purposes of this License, Derivative Works shall not include works that remain separable from, or merely link (or bind by name) to the interfaces of, the Work and Derivative Works thereof.

                                                                              \u201cContribution\u201d shall mean any work of authorship, including the original version of the Work and any modifications or additions to that Work or Derivative Works thereof, that is intentionally submitted to Licensor for inclusion in the Work by the copyright owner or by an individual or Legal Entity authorized to submit on behalf of the copyright owner. For the purposes of this definition, \u201csubmitted\u201d means any form of electronic, verbal, or written communication sent to the Licensor or its representatives, including but not limited to communication on electronic mailing lists, source code control systems, and issue tracking systems that are managed by, or on behalf of, the Licensor for the purpose of discussing and improving the Work, but excluding communication that is conspicuously marked or otherwise designated in writing by the copyright owner as \u201cNot a Contribution.\u201d

                                                                              \u201cContributor\u201d shall mean Licensor and any individual or Legal Entity on behalf of whom a Contribution has been received by Licensor and subsequently incorporated within the Work.

                                                                              "},{"location":"introduction/download/apache-2.0/#2-grant-of-copyright-license","title":"2. Grant of Copyright License","text":"

                                                                              Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare Derivative Works of, publicly display, publicly perform, sublicense, and distribute the Work and such Derivative Works in Source or Object form.

                                                                              "},{"location":"introduction/download/apache-2.0/#3-grant-of-patent-license","title":"3. Grant of Patent License","text":"

                                                                              Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work to which such Contribution(s) was submitted. If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed.

                                                                              "},{"location":"introduction/download/apache-2.0/#4-redistribution","title":"4. Redistribution","text":"

                                                                              You may reproduce and distribute copies of the Work or Derivative Works thereof in any medium, with or without modifications, and in Source or Object form, provided that You meet the following conditions:

                                                                              • (a) You must give any other recipients of the Work or Derivative Works a copy of this License; and
                                                                              • (b) You must cause any modified files to carry prominent notices stating that You changed the files; and
                                                                              • \u00a9 You must retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Works; and
                                                                              • (d) If the Work includes a \u201cNOTICE\u201d text file as part of its distribution, then any Derivative Works that You distribute must include a readable copy of the attribution notices contained within such NOTICE file, excluding those notices that do not pertain to any part of the Derivative Works, in at least one of the following places: within a NOTICE text file distributed as part of the Derivative Works; within the Source form or documentation, if provided along with the Derivative Works; or, within a display generated by the Derivative Works, if and wherever such third-party notices normally appear. The contents of the NOTICE file are for informational purposes only and do not modify the License. You may add Your own attribution notices within Derivative Works that You distribute, alongside or as an addendum to the NOTICE text from the Work, provided that such additional attribution notices cannot be construed as modifying the License.

                                                                              You may add Your own copyright statement to Your modifications and may provide additional or different license terms and conditions for use, reproduction, or distribution of Your modifications, or for any such Derivative Works as a whole, provided Your use, reproduction, and distribution of the Work otherwise complies with the conditions stated in this License.

                                                                              "},{"location":"introduction/download/apache-2.0/#5-submission-of-contributions","title":"5. Submission of Contributions","text":"

                                                                              Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions. Notwithstanding the above, nothing herein shall supersede or modify the terms of any separate license agreement you may have executed with Licensor regarding such Contributions.

                                                                              "},{"location":"introduction/download/apache-2.0/#6-trademarks","title":"6. Trademarks","text":"

                                                                              This License does not grant permission to use the trade names, trademarks, service marks, or product names of the Licensor, except as required for reasonable and customary use in describing the origin of the Work and reproducing the content of the NOTICE file.

                                                                              "},{"location":"introduction/download/apache-2.0/#7-disclaimer-of-warranty","title":"7. Disclaimer of Warranty","text":"

                                                                              Unless required by applicable law or agreed to in writing, Licensor provides the Work (and each Contributor provides its Contributions) on an \u201cAS IS\u201d BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are solely responsible for determining the appropriateness of using or redistributing the Work and assume any risks associated with Your exercise of permissions under this License.

                                                                              "},{"location":"introduction/download/apache-2.0/#8-limitation-of-liability","title":"8. Limitation of Liability","text":"

                                                                              In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall any Contributor be liable to You for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising as a result of this License or out of the use or inability to use the Work (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if such Contributor has been advised of the possibility of such damages.

                                                                              "},{"location":"introduction/download/apache-2.0/#9-accepting-warranty-or-additional-liability","title":"9. Accepting Warranty or Additional Liability","text":"

                                                                              While redistributing the Work or Derivative Works thereof, You may choose to offer, and charge a fee for, acceptance of support, warranty, indemnity, or other liability obligations and/or rights consistent with this License. However, in accepting such obligations, You may act only on Your own behalf and on Your sole responsibility, not on behalf of any other Contributor, and only if You agree to indemnify, defend, and hold each Contributor harmless for any liability incurred by, or claims asserted against, such Contributor by reason of your accepting any such warranty or additional liability.

                                                                              END OF TERMS AND CONDITIONS

                                                                              "},{"location":"introduction/download/apache-2.0/#appendix-how-to-apply-the-apache-license-to-your-work","title":"APPENDIX: How to apply the Apache License to your work","text":"

                                                                              To apply the Apache License to your work, attach the following boilerplate notice, with the fields enclosed by brackets [] replaced with your own identifying information. (Don't include the brackets!) The text should be enclosed in the appropriate comment syntax for the file format. We also recommend that a file or class name and description of purpose be included on the same \u201cprinted page\u201d as the copyright notice for easier identification within third-party archives.

                                                                              Copyright [yyyy] [name of copyright owner]\n\nLicensed under the Apache License, Version 2.0 (the \"License\");\nyou may not use this file except in compliance with the License.\nYou may obtain a copy of the License at\n\n  http://www.apache.org/licenses/LICENSE-2.0\n\nUnless required by applicable law or agreed to in writing, software\ndistributed under the License is distributed on an \"AS IS\" BASIS,\nWITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.\nSee the License for the specific language governing permissions and\nlimitations under the License.\n
                                                                              "},{"location":"introduction/download/epl-1.0/","title":"Epl 1.0","text":""},{"location":"introduction/download/epl-1.0/#eclipse-public-license-v-10","title":"Eclipse Public License -v 1.0","text":"

                                                                              THE ACCOMPANYING PROGRAM IS PROVIDED UNDER THE TERMS OF THIS ECLIPSE PUBLIC LICENSE (\"AGREEMENT\"). ANY USE, REPRODUCTION OR DISTRIBUTION OF THE PROGRAM CONSTITUTES RECIPIENT'S ACCEPTANCE OF THIS AGREEMENT.

                                                                              "},{"location":"introduction/download/epl-1.0/#1-definitions","title":"1. DEFINITIONS","text":"

                                                                              \"Contribution\" means:

                                                                              a) in the case of the initial Contributor, the initial code and documentation distributed under this Agreement, and

                                                                              b) in the case of each subsequent Contributor:

                                                                              i) changes to the Program, and

                                                                              ii) additions to the Program;

                                                                              where such changes and/or additions to the Program originate from and are distributed by that particular Contributor. A Contribution 'originates' from a Contributor if it was added to the Program by such Contributor itself or anyone acting on such Contributor's behalf. Contributions do not include additions to the Program which: (i) are separate modules of software distributed in conjunction with the Program under their own license agreement, and (ii) are not derivative works of the Program.

                                                                              \"Contributor\" means any person or entity that distributes the Program.

                                                                              \"Licensed Patents \" mean patent claims licensable by a Contributor which are necessarily infringed by the use or sale of its Contribution alone or when combined with the Program.

                                                                              \"Program\" means the Contributions distributed in accordance with this Agreement.

                                                                              \"Recipient\" means anyone who receives the Program under this Agreement, including all Contributors.

                                                                              "},{"location":"introduction/download/epl-1.0/#2-grant-of-rights","title":"2. GRANT OF RIGHTS","text":"

                                                                              a) Subject to the terms of this Agreement, each Contributor hereby grants Recipient a non-exclusive, worldwide, royalty-free copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, distribute and sublicense the Contribution of such Contributor, if any, and such derivative works, in source code and object code form.

                                                                              b) Subject to the terms of this Agreement, each Contributor hereby grants Recipient a non-exclusive, worldwide, royalty-free patent license under Licensed Patents to make, use, sell, offer to sell, import and otherwise transfer the Contribution of such Contributor, if any, in source code and object code form. This patent license shall apply to the combination of the Contribution and the Program if, at the time the Contribution is added by the Contributor, such addition of the Contribution causes such combination to be covered by the Licensed Patents. The patent license shall not apply to any other combinations which include the Contribution. No hardware per se is licensed hereunder.

                                                                              c) Recipient understands that although each Contributor grants the licenses to its Contributions set forth herein, no assurances are provided by any Contributor that the Program does not infringe the patent or other intellectual property rights of any other entity. Each Contributor disclaims any liability to Recipient for claims brought by any other entity based on infringement of intellectual property rights or otherwise. As a condition to exercising the rights and licenses granted hereunder, each Recipient hereby assumes sole responsibility to secure any other intellectual property rights needed, if any. For example, if a third party patent license is required to allow Recipient to distribute the Program, it is Recipient's responsibility to acquire that license before distributing the Program.

                                                                              d) Each Contributor represents that to its knowledge it has sufficient copyright rights in its Contribution, if any, to grant the copyright license set forth in this Agreement.

                                                                              "},{"location":"introduction/download/epl-1.0/#3-requirements","title":"3. REQUIREMENTS","text":"

                                                                              A Contributor may choose to distribute the Program in object code form under its own license agreement, provided that:

                                                                              a) it complies with the terms and conditions of this Agreement; and

                                                                              b) its license agreement:

                                                                              i) effectively disclaims on behalf of all Contributors all warranties and conditions, express and implied, including warranties or conditions of title and non-infringement, and implied warranties or conditions of merchantability and fitness for a particular purpose;

                                                                              ii) effectively excludes on behalf of all Contributors all liability for damages, including direct, indirect, special, incidental and consequential damages, such as lost profits;

                                                                              iii) states that any provisions which differ from this Agreement are offered by that Contributor alone and not by any other party; and

                                                                              iv) states that source code for the Program is available from such Contributor, and informs licensees how to obtain it in a reasonable manner on or through a medium customarily used for software exchange.

                                                                              When the Program is made available in source code form:

                                                                              a) it must be made available under this Agreement; and

                                                                              b) a copy of this Agreement must be included with each copy of the Program.

                                                                              Contributors may not remove or alter any copyright notices contained within the Program.

                                                                              Each Contributor must identify itself as the originator of its Contribution, if any, in a manner that reasonably allows subsequent Recipients to identify the originator of the Contribution.

                                                                              "},{"location":"introduction/download/epl-1.0/#4-commercial-distribution","title":"4. COMMERCIAL DISTRIBUTION","text":"

                                                                              Commercial distributors of software may accept certain responsibilities with respect to end users, business partners and the like. While this license is intended to facilitate the commercial use of the Program, the Contributor who includes the Program in a commercial product offering should do so in a manner which does not create potential liability for other Contributors. Therefore, if a Contributor includes the Program in a commercial product offering, such Contributor (\"Commercial Contributor\") hereby agrees to defend and indemnify every other Contributor (\"Indemnified Contributor\") against any losses, damages and costs (collectively \"Losses\") arising from claims, lawsuits and other legal actions brought by a third party against the Indemnified Contributor to the extent caused by the acts or omissions of such Commercial Contributor in connection with its distribution of the Program in a commercial product offering. The obligations in this section do not apply to any claims or Losses relating to any actual or alleged intellectual property infringement. In order to qualify, an Indemnified Contributor must: a) promptly notify the Commercial Contributor in writing of such claim, and b) allow the Commercial Contributor to control, and cooperate with the Commercial Contributor in, the defense and any related settlement negotiations. The Indemnified Contributor may participate in any such claim at its own expense.

                                                                              For example, a Contributor might include the Program in a commercial product offering, Product X. That Contributor is then a Commercial Contributor. If that Commercial Contributor then makes performance claims, or offers warranties related to Product X, those performance claims and warranties are such Commercial Contributor's responsibility alone. Under this section, the Commercial Contributor would have to defend claims against the other Contributors related to those performance claims and warranties, and if a court requires any other Contributor to pay any damages as a result, the Commercial Contributor must pay those damages.

                                                                              "},{"location":"introduction/download/epl-1.0/#5-no-warranty","title":"5. NO WARRANTY","text":"

                                                                              EXCEPT AS EXPRESSLY SET FORTH IN THIS AGREEMENT, THE PROGRAM IS PROVIDED ON AN \"AS IS\" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED INCLUDING, WITHOUT LIMITATION, ANY WARRANTIES OR CONDITIONS OF TITLE, NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Each Recipient is solely responsible for determining the appropriateness of using and distributing the Program and assumes all risks associated with its exercise of rights under this Agreement , including but not limited to the risks and costs of program errors, compliance with applicable laws, damage to or loss of data, programs or equipment, and unavailability or interruption of operations.

                                                                              "},{"location":"introduction/download/epl-1.0/#6-disclaimer-of-liability","title":"6. DISCLAIMER OF LIABILITY","text":"

                                                                              EXCEPT AS EXPRESSLY SET FORTH IN THIS AGREEMENT, NEITHER RECIPIENT NOR ANY CONTRIBUTORS SHALL HAVE ANY LIABILITY FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING WITHOUT LIMITATION LOST PROFITS), HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OR DISTRIBUTION OF THE PROGRAM OR THE EXERCISE OF ANY RIGHTS GRANTED HEREUNDER, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

                                                                              "},{"location":"introduction/download/epl-1.0/#7-general","title":"7. GENERAL","text":"

                                                                              If any provision of this Agreement is invalid or unenforceable under applicable law, it shall not affect the validity or enforceability of the remainder of the terms of this Agreement, and without further action by the parties hereto, such provision shall be reformed to the minimum extent necessary to make such provision valid and enforceable.

                                                                              If Recipient institutes patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Program itself (excluding combinations of the Program with other software or hardware) infringes such Recipient's patent(s), then such Recipient's rights granted under Section 2(b) shall terminate as of the date such litigation is filed.

                                                                              All Recipient's rights under this Agreement shall terminate if it fails to comply with any of the material terms or conditions of this Agreement and does not cure such failure in a reasonable period of time after becoming aware of such noncompliance. If all Recipient's rights under this Agreement terminate, Recipient agrees to cease use and distribution of the Program as soon as reasonably practicable. However, Recipient's obligations under this Agreement and any licenses granted by Recipient relating to the Program shall continue and survive.

                                                                              Everyone is permitted to copy and distribute copies of this Agreement, but in order to avoid inconsistency the Agreement is copyrighted and may only be modified in the following manner. The Agreement Steward reserves the right to publish new versions (including revisions) of this Agreement from time to time. No one other than the Agreement Steward has the right to modify this Agreement. The Eclipse Foundation is the initial Agreement Steward. The Eclipse Foundation may assign the responsibility to serve as the Agreement Steward to a suitable separate entity. Each new version of the Agreement will be given a distinguishing version number. The Program (including Contributions) may always be distributed subject to the version of the Agreement under which it was received. In addition, after a new version of the Agreement is published, Contributor may elect to distribute the Program (including its Contributions) under the new version. Except as expressly stated in Sections 2(a) and 2(b) above, Recipient receives no rights or licenses to the intellectual property of any Contributor under this Agreement, whether expressly, by implication, estoppel or otherwise. All rights in the Program not expressly granted under this Agreement are reserved.

                                                                              This Agreement is governed by the laws of the State of New York and the intellectual property laws of the United States of America. No party to this Agreement will bring a legal action under this Agreement more than one year after the cause of action arose. Each party waives its rights to a jury trial in any resulting litigation.

                                                                              "},{"location":"production/","title":"Running in a production environment","text":"

                                                                              GeoServer is geared towards many different uses, from a simple test server to the enterprise-level data server. While many optimizations for GeoServer are set by default, here are some extra considerations to keep in mind when running GeoServer in a production environment.

                                                                              • Java Considerations
                                                                              • Container Considerations
                                                                              • Configuration Considerations
                                                                              • Data Considerations
                                                                              • Linux init scripts
                                                                              • Other Considerations
                                                                              • Troubleshooting
                                                                              • Make cluster nodes identifiable from the GUI
                                                                              "},{"location":"production/config/","title":"Configuration Considerations","text":""},{"location":"production/config/#use-production-logging","title":"Use production logging","text":"

                                                                              Logging may visibly affect the performance of your server. High logging levels are often necessary to track down issues, but by default you should run with low levels. (You can switch the logging levels while GeoServer is running.)

                                                                              You can change the logging level in the Logging Profile. You will want to choose the PRODUCTION logging configuration, where only problems are written to the log files.

                                                                              "},{"location":"production/config/#logging-configuration-hardening","title":"Logging configuration hardening","text":"

                                                                              For production systems, it is advised to set GEOSERVER_LOG_LOCATION parameter during startup. The value may be defined as either an environment variable, java system property, or servlet context parameter.

                                                                              The location set for GEOSERVER_LOG_LOCATION has priority, causing the value provided using the Admin Console GUI or REST API to be ignored. This approach establishes a separation of responsibility between those setting up and controlling the actual machine, and those configuring the GeoServer application.

                                                                              See Advanced log configuration for more information.

                                                                              "},{"location":"production/config/#set-a-service-strategy","title":"Set a service strategy","text":"

                                                                              A service strategy is the method in which output is served to the client. This is a balance between proper form (being absolutely sure of reporting errors with the proper OGC codes, etc.) and speed (serving output as quickly as possible). This is a decision to be made based on the function that GeoServer is providing. You can configure the service strategy by modifying the web.xml file of your GeoServer instance.

                                                                              The possible strategies are:

                                                                              Strategy Description SPEED Serves output right away. This is the fastest strategy, but proper OGC errors are usually omitted. BUFFER Stores the whole result in memory, and then serves it after the output is complete. This ensures proper OGC error reporting, but delays the response quite a bit and can exhaust memory if the response is large. FILE Similar to BUFFER, but stores the whole result in a file instead of in memory. Slower than BUFFER, but ensures there won't be memory issues. PARTIAL-BUFFER A balance between BUFFER and SPEED, this strategy tries to buffer in memory a few KB of response, then serves the full output."},{"location":"production/config/#personalize-your-server","title":"Personalize your server","text":"

                                                                              This isn't a performance consideration, but it is just as important. In order to make GeoServer as useful as possible, you should customize the server's metadata to your organization. It may be tempting to skip some of the configuration steps, and leave in the same keywords and abstract as the sample, but this will only confuse potential users.

                                                                              Suggestions:

                                                                              • Fill out the WFS, WMS, and WCS Service Metadata sections (this info will be broadcast as part of the capabilities documents)
                                                                              • Serve your data with your own namespace (and provide a correct URI)
                                                                              • Remove default layers (such as topp:states)
                                                                              "},{"location":"production/config/#configure-service-limits","title":"Configure service limits","text":"

                                                                              Make sure clients cannot request an inordinate amount of resources from your server.

                                                                              In particular:

                                                                              • Set the maximum amount of features returned by each WFS GetFeature request (this can also be set on a per featuretype basis by modifying the layer publishing wfs settings).
                                                                              • Set the WMS request limits so that no request will consume too much memory or too much time
                                                                              • Set WPS limits, so no process will consume too much memory or too much time. You may also limit the size input parameters for further control.
                                                                              "},{"location":"production/config/#set-security-for-data-modification","title":"Set security for data modification","text":"

                                                                              GeoServer includes support for WFS-T (transactions) by default, which lets users modify your data.

                                                                              If you don't want your database modified, you can turn off transactions in the WFS settings. Set the Service Level to Basic. For extra security, we recommend any database access use datastore credentials providing read-only permissions. This will eliminate the possibility of a SQL injection (though GeoServer is generally not vulnerable to that sort of attack).

                                                                              If you would like some users to be able to modify data, set the service level Service Level to Transactional (or Complete) and use Service Security to limit access to the WFS.Transaction operation.

                                                                              If you would like some users to be able to modify some but not all of your data, set the Service Level to Transactional (or Complete), and use Layer security to limit write access to specific layers. Data security can be used to allow write access based on workspace, datastore, or layer security.

                                                                              "},{"location":"production/config/#cache-your-data","title":"Cache your data","text":"

                                                                              Server-side caching of WMS tiles is the best way to increase performance. In caching, pre-rendered tiles will be saved, eliminating the need for redundant WMS calls. There are several ways to set up WMS caching for GeoServer. GeoWebCache is the simplest method, as it comes bundled with GeoServer. (See the section on GeoWebCache for more details.) Another option is TileCache.

                                                                              You can also use a more generic non-spatial caching system, such as OSCache (an embedded cache service) or Squid (a web cache proxy).

                                                                              Caching is also possible for WFS layers, in a very limited fashion. For DataStores that don't have a quick way to determine feature counts (e.g. shapefiles), enabling caching can prevent querying a store twice during a single request. To enable caching, set the Java system property org.geoserver.wfs.getfeature.cachelimit to a positive integer. Any data sets that are smaller than the cache limit will be cached for the duration of a request, which will prevent the dataset from being queried a second time for the feature count. Note that this may adversely affect some types of DataStores, as it bypasses any feature count optimizations that may exist.

                                                                              "},{"location":"production/config/#welcome-page-selectors","title":"Welcome page selectors","text":"

                                                                              The workspace and layer selectors might take a lot of time to fill up against large catalogs. Because of this, GeoServer tries to limit the time taken to fill them (by default, 5 seconds), and the number of items in them (by default, 1000), and will fall back on simple text fields if the time limit is reached.

                                                                              In some situations, that won't be enough and the page might get stuck anyways. The following properties can be used to tweak the behavior:

                                                                              • GeoServerHomePage.selectionMode : can be set to text to always use simple text fields, dropdown to always use dropdowns, or auto to use the default automatic behavior.
                                                                              • GeoServerHomePage.selectionTimeout : the time limit in milliseconds, defaults to 5000.
                                                                              • GeoServerHomePage.selectionMaxItems : the maximum number of items to show in the dropdowns, defaults to 1000.

                                                                              When using text selection mode the page description is static, no longer offering of available workspace and layers.

                                                                              Welcome page text selection mode

                                                                              "},{"location":"production/config/#disable-the-geoserver-web-administration-interface","title":"Disable the GeoServer web administration interface","text":"

                                                                              In some circumstances, you might want to completely disable the web administration interface. There are two ways of doing this:

                                                                              • Set the Java system property GEOSERVER_CONSOLE_DISABLED to true by adding -DGEOSERVER_CONSOLE_DISABLED=true to your container's JVM options
                                                                              • Remove all of the gs-web*-.jar files from WEB-INF/lib
                                                                              "},{"location":"production/config/#disable-the-auto-complete-on-web-administration-interface-login","title":"Disable the Auto-complete on web administration interface login","text":"

                                                                              To disable the Auto Complete on Web Admin login form:

                                                                              • Set the Java system property geoserver.login.autocomplete to off by adding -Dgeoserver.login.autocomplete=off to your container's JVM options
                                                                              • If the browser has already cached the credentials, please consider clearing the cache or form data after setting the JVM option.
                                                                              "},{"location":"production/config/#disable-anonymous-access-to-the-layer-preview-page","title":"Disable anonymous access to the layer preview page","text":"

                                                                              In some circumstances, you might want to provide access to the layer preview page to authenticated users only. The solution is based on adding a new filter chain with a rule matching the path of the layer preview page to GeoServer's Authentication chain. Here are the steps to reproduce:

                                                                              • Under Security -> Authentication -> Filter Chains, add a new HTML chain
                                                                              • Set the new chain's name to webLayerPreview (or likewise)
                                                                              • As Ant pattern, enter the path of the layer preview page, which is /web/wicket/bookmarkable/org.geoserver.web.demo.MapPreviewPage (since it's an Ant pattern, the path could as well be written shorter with wildcards: /web/**/org.geoserver.web.demo.MapPreviewPage)
                                                                              • Check option Allow creation of an HTTP session for storing the authentication token
                                                                              • Under Chain filters, add filters rememberme and form (in that order) to the Selected list on the right side
                                                                              • Close the dialog by clicking the Close button; the new HTML chain has been added to the list of chains as the last entry
                                                                              • Since all chains are processed in turn from top to bottom, in order to have any effect, the new webLayerPreview chain must be positioned before the web chain (which matches paths /web/**,/gwc/rest/web/**,/)
                                                                              • Use the Position arrows on the left side of the list to move the newly added chain upwards accordingly
                                                                              • Save the changes you've made by clicking the Save button at the bottom of the page

                                                                              With that in place, unauthenticated users now just get forwarded to the login page when they click the layer preview menu item link.

                                                                              The above procedure could as well be applied to other pages of the web administration interface that one needs to remove anonymous access for. For example:

                                                                              • Demos -> Demo requests (path: /web/wicket/bookmarkable/org.geoserver.web.demo.DemoRequestsPage)
                                                                              • Demos -> WCS request builder (path: /web/wicket/bookmarkable/org.geoserver.wcs.web.demo.WCSRequestBuilder)

                                                                              Warning

                                                                              Although disabling anonymous access to the layer preview page MAY prevent some unauthenticated users from accessing data with some simple clicks, this is NOT a security feature. In particular, since other more sophisticated users, having the ability to build OGC requests, MAY still access critical data through GeoServer's services, this is NOT a replacement for a well-designed security concept based on data-level or service-level security.

                                                                              "},{"location":"production/config/#x-frame-options-policy","title":"X-Frame-Options Policy","text":"

                                                                              In order to prevent clickjacking attacks GeoServer defaults to setting the X-Frame-Options HTTP header to SAMEORIGIN. This prevents GeoServer from being embedded into an iFrame, which prevents certain kinds of security vulnerabilities. See the OWASP Clickjacking entry for details.

                                                                              If you wish to change this behavior you can do so through the following properties:

                                                                              • geoserver.xframe.shouldSetPolicy: controls whether the X-Frame-Options filter should be set at all. Default is true.
                                                                              • geoserver.xframe.policy: controls what the set the X-Frame-Options header to. Default is SAMEORIGIN valid options are DENY, SAMEORIGIN and ALLOW-FROM [uri]

                                                                              These properties can be set either via Java system property, command line argument (-D), environment variable or web.xml init parameter.

                                                                              "},{"location":"production/config/#x-content-type-options-policy","title":"X-Content-Type-Options Policy","text":"

                                                                              In order to mitigate MIME confusion attacks (which often results in Cross-Site Scripting), GeoServer defaults to setting the X-Content-Type-Options: nosniff HTTP header. See the OWASP X-Content-Type-Options entry for details.

                                                                              If you wish to change this behavior you can do so through the following property:

                                                                              • geoserver.xContentType.shouldSetPolicy: controls whether the X-Content-Type-Options header should be set. Default is true.

                                                                              This property can be set either via Java system property, command line argument (-D), environment variable or web.xml init parameter.

                                                                              "},{"location":"production/config/#ows-serviceexception-xml-mimetype","title":"OWS ServiceException XML mimeType","text":"

                                                                              By default, OWS Service Exception XML responses have content-type set to application/xml.

                                                                              In case you want it set to text/xml instead, you need to setup the Java System properties:

                                                                              • -Dows10.exception.xml.responsetype=text/xml for OWS 1.0.0 version
                                                                              • -Dows11.exception.xml.responsetype=text/xml for OWS 1.1.0 version
                                                                              "},{"location":"production/config/#production_config_freemarker_escaping","title":"FreeMarker Template Auto-escaping","text":"

                                                                              By default, FreeMarker's built-in automatic escaping functionality will be enabled to mitigate potential cross-site scripting (XSS) vulnerabilities in cases where GeoServer uses FreeMarker templates to generate HTML output and administrators are able to modify the templates and/or users have significant control over the output through service requests. When the GEOSERVER_FORCE_FREEMARKER_ESCAPING property is set to false, auto-escaping will delegate either to the feature's default behavior or other settings which allow administrators to enable/disable auto-escaping on a global or per virtual service basis. This property can be set to false either via Java system property, command line argument (-D), environment variable or web.xml init parameter.

                                                                              This setting currently applies to the WMS GetFeatureInfo HTML output format and may be applied to other applicable GeoServer functionality in the future.

                                                                              Warning

                                                                              While enabling auto-escaping will prevent XSS using the default templates and mitigate many cases where template authors are not considering XSS in their template design, it does NOT completely prevent template authors from creating templates that allow XSS (whether this is intentional or not). Additional functionality may be added in the future to mitigate those potential XSS vulnerabilities.

                                                                              "},{"location":"production/config/#production_config_external_entities","title":"External Entities Resolution","text":"

                                                                              When processing XML documents from service requests (POST requests, and GET requests with FILTER and SLD_BODY parameters) XML entity resolution is used to obtain any referenced documents. This is most commonly seen when the XML request provides the location of an XSD schema location for validation).

                                                                              GeoServer provides a number of facilities to control external entity resolution:

                                                                              • By default http and https entity resolution is unrestricted, with access to local file references prevented.

                                                                              • To restrict http and https entity resolution:

                                                                                -DENTITY_RESOLUTION_ALLOWLIST\n

                                                                                The built-in allow list includes w3c, ogc, and inspire schema locations:

                                                                                www.w3.org|schemas.opengis.net|www.opengis.net|inspire.ec.europa.eu/schemas\n

                                                                                In addition the proxy base url is included, if available from global settings.

                                                                                Access to local file references remains restricted.

                                                                              • To allow additional external entity http and https locations use a comma or bar separated list:

                                                                                -DENTITY_RESOLUTION_ALLOWLIST=server1|server2|server3/schemas\n
                                                                              • To turn off all restrictions (allowing http, https, and file references) use the global setting Unrestricted XML External Entity Resolution.

                                                                                This setting prevents ENTITY_RESOLUTION_ALLOWLIST from being used.

                                                                              "},{"location":"production/config/#production_config_spring_firewall","title":"Spring Security Firewall","text":"

                                                                              GeoServer defaults to using Spring Security's StrictHttpFirewall to help improve protection against potentially malicious requests. However, some users will need to disable the StrictHttpFirewall if the names of GeoServer resources (workspaces, layers, styles, etc.) in URL paths need to contain encoded percent, encoded period or decoded or encoded semicolon characters. The GEOSERVER_USE_STRICT_FIREWALL property can be set to false either via Java system property, command line argument (-D), environment variable or web.xml init parameter to use the more lenient DefaultHttpFirewall.

                                                                              "},{"location":"production/config/#static-web-files","title":"Static Web Files","text":"

                                                                              GeoServer by default allows administrators to serve static files by simply placing them in the www``` subdirectory of the GeoServer data directory. If this feature is not being used to serve HTML/JavaScript files or is not being used at all, the ````GEOSERVER_DISABLE_STATIC_WEB_FILES```` property can be set to true to mitigate potential stored XSS issues with that directory. See the \\Serving Static Files \\<../tutorials/staticfiles.rst>``_ page for more details.

                                                                              "},{"location":"production/config/#session-management","title":"Session Management","text":"

                                                                              GeoServer defaults to managing user sessions using cookies with the HttpOnly flag set to prevent attackers from using cross-site scripting (XSS) attacks to steal a user\\'s session token. You can configure the session behavior by modifying the `web.xml` file of your GeoServer instance.

                                                                              It is strongly recommended that production environments also set the Secure flag on session cookies. This can be enabled by uncommenting the following in the `web.xml` file if the web interface is only being accessed through HTTPS but the flag may need to be set by a proxy server if the web interface needs to support both HTTP and HTTPS.

                                                                              <secure>true</secure>\n
                                                                              "},{"location":"production/container/","title":"Container Considerations","text":"

                                                                              Java web containers such as Tomcat or Jetty ship with configurations that allow for fast startup, but don't always deliver the best performance.

                                                                              "},{"location":"production/container/#optimize-your-jvm","title":"Optimize your JVM","text":"

                                                                              Set the following performance settings in the Java virtual machine (JVM) for your container. These settings are not specific to any container.

                                                                              Option Description -Xms128m By starting with a larger heap GeoServer will not need to pause and ask the operating system for more memory during heavy load. The setting -Xms128m will tell the virtual machine to acquire grab a 128m heap memory on initial startup. -Xmx756M Defines an upper limit on how much heap memory Java will request from the operating system (use more if you have excess memory). By default, the JVM will use \u00bc of available system memory. The setting -Xms756m allocates 756MB of memory to GeoServer. -XX:SoftRefLRUPolicyMSPerMB=36000 Increases the lifetime of \"soft references\" in GeoServer. GeoServer uses soft references to cache datastore, spatial reference systems, and other data structures. By increasing this value to 36000 (which is 36 seconds) these values will stay in memory longer increasing the effectiveness of the cache. -XX:+UseParallelGC This garbage collector pauses the application while using several threads to recover memory. Recommended if your GeoServer will be under light load and can tolerate pauses to clean up memory. -XX:+UseParNewGC Enables use of the concurrent mark sweep (CMS) garbage collector uses multiple threads to recover memory while the application is running. Recommended for GeoServer under continuous use, with heap sizes of less than 6GB. \u2013XX:+UseG1GC The default garbage collector since Java 9. Enables use of the Garbage First Garbage Collector (G1) using background threads to scan memory while the application is running prior to cleanup. Recommended for GeoServer under continuous load and heap sizes of 6GB or more. Additionally you may experiment with -XX:+UseStringDeduplicationJVM to ask G1 to better manage common text strings in memory.

                                                                              For more information about JVM configuration, see the article Performance tuning garbage collection in Java and The 4 Java Garbage Collectors.

                                                                              Note

                                                                              You can only use one garbage collector at a time. Please refrain from combining garbage collectors at runtime.

                                                                              Note

                                                                              If you're serving just vector data, you'll be streaming, so having more memory won't increase performance. If you're serving coverages, however, image processing will use a tile cache and benefit from more memory. As an administrator you can configure the portion of memory available as a tile cache (see the Server Config page in the Web administration interface section) - for example to use 0.75 to allocate 75% of the heap as a tile cache.

                                                                              Note

                                                                              You can try out memory settings on the command line to check settings/defaults prior to use.

                                                                              To check settings use java -Xms128m -Xmx756m -XX:+PrintFlagsFinal -version | grep HeapSize:

                                                                              uintx InitialHeapSize   := 134217728     {product}\nuintx MaxHeapSize       := 792723456     {product}\n

                                                                              Which when converted from bytes matches 128 MB initial heap size, and 756 MB max heap size.

                                                                              Check defaults for your hardware using java -XX:+PrintFlagsFinal -version | grep HeapSize:

                                                                              uintx InitialHeapSize   := 268435456     {product}\nuintx MaxHeapSize       := 4294967296    {product}\n

                                                                              The above results (from a 16 GB laptop) amount to initial heap size of 256m, and a max heap size of around 4 GB (or around \u00bc of system memory).

                                                                              "},{"location":"production/container/#production_container.marlin","title":"Use newer Marlin rasterizer","text":"

                                                                              To use a newer version of Marlin than that provided by your JVM, add the following to the JVM startup options:

                                                                              -Xbootclasspath/a:$MARLIN_JAR\n-Dsun.java2d.renderer=org.marlin.pisces.MarlinRenderingEngine\n

                                                                              where $MARLIN_JAR is the location of the marlin*.jar file located in the geoserver/WEB-INF/lib directory or downloaded from the Marlin project.

                                                                              The server status page shows which renderer is being used.

                                                                              "},{"location":"production/container/#production_container.enable_cors","title":"Enable CORS","text":"

                                                                              Enable Cross-Origin Resource Sharing (CORS) to allow JavaScript applications outside of your own domain, or web browsers, to use GeoServer.

                                                                              "},{"location":"production/container/#enable-cors-for-tomcat","title":"Enable CORS for Tomcat","text":"

                                                                              The web archive distribution of GeoServer is tested with Tomcat. Use the following steps to enable CORS for Tomcat, more information on what this does and other options see the Tomcat CORS Filter documentation.

                                                                              1. Uncomment the following <filter> in webapps/geoserver/WEB-INF/web.xml:

                                                                                <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<web-app \n        xmlns=\"http://xmlns.jcp.org/xml/ns/javaee\" \n        xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\"\n        xsi:schemaLocation=\"http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd\"\n        metadata-complete=\"false\"\n        version=\"3.1\">\n    <display-name>GeoServer</display-name>\n\n      <context-param>\n    <param-name>serviceStrategy</param-name>\n    <!-- Meaning of the different values :\n\n         PARTIAL-BUFFER2\n         - Partially buffers the first xKb to disk. Once that has buffered, the the \n           result is streamed to the user. This will allow for most errors to be caught\n           early. \n\n         BUFFER\n         - stores the entire response in memory first, before sending it off to\n           the user (may run out of memory)\n\n         SPEED\n         - outputs directly to the response (and cannot recover in the case of an\n           error)\n\n         FILE\n         - outputs to the local filesystem first, before sending it off to the user\n      -->\n    <param-value>PARTIAL-BUFFER2</param-value>\n  </context-param>\n\n  <context-param>\n    <!-- see comments on the PARTIAL-BUFFER strategy -->\n    <!-- this sets the size of the buffer.  default is \"50\" = 50kb -->\n\n    <param-name>PARTIAL_BUFFER_STRATEGY_SIZE</param-name>\n    <param-value>50</param-value>\n  </context-param>\n\n  <!--Can be true or false (defaults to: false). -->\n  <!--When true the JSONP (text/javascript) output format is enabled -->\n  <!--\n  <context-param>\n    <param-name>ENABLE_JSONP</param-name>\n    <param-value>true</param-value>\n  </context-param>\n  -->\n    <!-- \n    <context-param>\n      <param-name>PROXY_BASE_URL</param-name>\n      <param-value>http://82.58.146.45/geoserver</param-value>\n    </context-param>\n     -->\n\n     <!--\n    <context-param>\n       <param-name>GEOSERVER_DATA_DIR</param-name>\n        <param-value>C:\\eclipse\\workspace\\geoserver_trunk\\cite\\confCiteWFSPostGIS</param-value>\n    </context-param> \n   -->\n\n    <!-- pick up all spring application contexts -->\n    <context-param>\n        <param-name>contextConfigLocation</param-name>\n        <param-value>classpath*:/applicationContext.xml classpath*:/applicationSecurityContext.xml</param-value>\n    </context-param>\n\n    <filter>\n     <filter-name>FlushSafeFilter</filter-name>\n     <filter-class>org.geoserver.filters.FlushSafeFilter</filter-class>\n    </filter>\n\n    <filter>\n      <filter-name>Set Character Encoding</filter-name>\n      <filter-class>org.springframework.web.filter.CharacterEncodingFilter</filter-class>\n      <init-param>\n        <param-name>encoding</param-name>\n        <param-value>UTF-8</param-value>\n      </init-param>\n    </filter>\n\n    <filter>\n     <filter-name>SessionDebugger</filter-name>\n     <filter-class>org.geoserver.filters.SessionDebugFilter</filter-class>\n    </filter>\n\n    <filter>\n    <filter-name>filterChainProxy</filter-name>     \n     <filter-class> org.springframework.web.filter.DelegatingFilterProxy</filter-class>\n    </filter>\n\n    <filter>\n      <filter-name>xFrameOptionsFilter</filter-name>\n      <filter-class>org.geoserver.filters.XFrameOptionsFilter</filter-class>\n    </filter>\n\n   <filter>\n     <filter-name>GZIP Compression Filter</filter-name>\n     <filter-class>org.geoserver.filters.GZIPFilter</filter-class>\n     <init-param>\n         <!-- The compressed-types parameter is a comma-separated list of regular expressions.\n              If a mime type matches any of the regular expressions then it will be compressed.\n              -->\n         <param-name>compressed-types</param-name>\n         <param-value>text/.*,.*xml.*,application/json,application/x-javascript</param-value>\n     </init-param>\n   </filter>\n\n   <filter>\n     <filter-name>Advanced Dispatch Filter</filter-name>\n     <filter-class>org.geoserver.platform.AdvancedDispatchFilter</filter-class>\n     <!-- \n     This filter allows for a single mapping to the spring dispatcher. However using /* as a mapping\n     in a servlet mapping causes the servlet path to be \"/\" of the request. This causes problems with\n     library like wicket and restlet. So this filter fakes the servlet path by assuming the first \n     component of the path is the mapped path. \n     -->\n   </filter>\n\n   <filter>\n    <filter-name>Spring Delegating Filter</filter-name>\n    <filter-class>org.geoserver.filters.SpringDelegatingFilter</filter-class>\n    <!--\n    This filter allows for filters to be loaded via spring rather than \n    registered here in web.xml.  One thing to note is that for such filters \n    init() is not called. INstead any initialization is performed via spring \n    ioc.\n    -->\n   </filter>\n\n   <filter>\n     <filter-name>Thread locals cleanup filter</filter-name>\n     <filter-class>org.geoserver.filters.ThreadLocalsCleanupFilter</filter-class>\n     <!-- \n     This filter cleans up thread locals Geotools is setting up for concurrency and performance\n     reasons \n     -->\n   </filter>\n\n   <!-- Uncomment following filter to enable CORS in Jetty. Do not forget the second config block further down.\n    <filter>\n      <filter-name>cross-origin</filter-name>\n      <filter-class>org.eclipse.jetty.servlets.CrossOriginFilter</filter-class>\n      <init-param>\n        <param-name>chainPreflight</param-name>\n        <param-value>false</param-value>\n      </init-param>\n      <init-param>\n        <param-name>allowedOrigins</param-name>\n        <param-value>*</param-value>\n      </init-param>\n      <init-param>\n        <param-name>allowedMethods</param-name>\n        <param-value>GET,POST,PUT,DELETE,HEAD,OPTIONS</param-value>\n      </init-param>\n      <init-param>\n        <param-name>allowedHeaders</param-name>\n        <param-value>*</param-value>\n      </init-param>\n    </filter>\n    -->\n\n   <!-- Uncomment following filter to enable CORS in Tomcat. Do not forget the second config block further down.\n    <filter>\n      <filter-name>cross-origin</filter-name>\n      <filter-class>org.apache.catalina.filters.CorsFilter</filter-class>\n      <init-param>\n        <param-name>cors.allowed.origins</param-name>\n        <param-value>*</param-value>\n      </init-param>\n      <init-param>\n        <param-name>cors.allowed.methods</param-name>\n        <param-value>GET,POST,PUT,DELETE,HEAD,OPTIONS</param-value>\n      </init-param>\n      <init-param>\n        <param-name>cors.allowed.headers</param-name>\n        <param-value>*</param-value>\n      </init-param>\n    </filter>\n    -->\n\n    <!-- \n      THIS FILTER MAPPING MUST BE THE FIRST ONE, otherwise we end up with ruined chars in the input from the GUI\n      See the \"Note\" in the Tomcat character encoding guide:\n      http://wiki.apache.org/tomcat/FAQ/CharacterEncoding\n    -->\n    <filter-mapping>\n      <filter-name>Set Character Encoding</filter-name>\n      <url-pattern>/*</url-pattern>\n    </filter-mapping>\n\n    <!-- Uncomment following filter-mapping to enable CORS\n    <filter-mapping>\n        <filter-name>cross-origin</filter-name>\n        <url-pattern>/*</url-pattern>\n    </filter-mapping>\n    -->\n\n    <filter-mapping>\n      <filter-name>FlushSafeFilter</filter-name>\n      <url-pattern>/*</url-pattern>\n    </filter-mapping>\n\n    <filter-mapping>\n      <filter-name>SessionDebugger</filter-name>\n      <url-pattern>/*</url-pattern>\n    </filter-mapping>\n\n    <filter-mapping>\n      <filter-name>GZIP Compression Filter</filter-name>\n      <url-pattern>/*</url-pattern>\n    </filter-mapping>\n\n    <filter-mapping>\n      <filter-name>xFrameOptionsFilter</filter-name>\n      <url-pattern>/*</url-pattern>\n    </filter-mapping>\n\n    <!-- \n      If you want to use your security system comment out this one too\n    -->\n    <filter-mapping>\n      <filter-name>filterChainProxy</filter-name>\n      <url-pattern>/*</url-pattern>\n    </filter-mapping>\n\n    <filter-mapping>\n      <filter-name>Advanced Dispatch Filter</filter-name>\n      <url-pattern>/*</url-pattern>\n    </filter-mapping>\n\n    <filter-mapping>\n      <filter-name>Spring Delegating Filter</filter-name>\n      <url-pattern>/*</url-pattern>\n    </filter-mapping>\n\n    <filter-mapping>\n      <filter-name>Thread locals cleanup filter</filter-name>\n      <url-pattern>/*</url-pattern>\n    </filter-mapping>\n\n    <!-- general initializer, should be first thing to execute -->\n    <listener>\n      <listener-class>org.geoserver.GeoserverInitStartupListener</listener-class>\n    </listener>\n\n    <!-- logging initializer, should execute before spring context startup -->\n    <listener>\n      <listener-class>org.geoserver.logging.LoggingStartupContextListener</listener-class>\n    </listener>\n\n    <!--  spring context loader -->\n    <listener>\n      <listener-class>org.geoserver.platform.GeoServerContextLoaderListener</listener-class>\n    </listener>\n\n    <!--  http session listener proxy -->\n    <listener>\n      <listener-class>org.geoserver.platform.GeoServerHttpSessionListenerProxy</listener-class>\n    </listener>\n\n    <!-- request context listener for session-scoped beans -->\n    <listener>\n        <listener-class>org.springframework.web.context.request.RequestContextListener</listener-class>\n    </listener>\n\n    <!-- spring dispatcher servlet, dispatches all incoming requests -->\n    <servlet>\n      <servlet-name>dispatcher</servlet-name>\n      <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>\n    </servlet>\n\n    <!-- single mapping to spring, this only works properly if the advanced dispatch filter is \n         active -->\n    <servlet-mapping>\n        <servlet-name>dispatcher</servlet-name>\n        <url-pattern>/*</url-pattern>\n    </servlet-mapping>\n\n    <session-config>\n        <cookie-config>\n            <http-only>true</http-only>\n            <!-- The Secure flag should be set on session cookies but is commented out by default since it -->\n            <!-- will break non-HTTPS web UI access and may cause problems with some proxy configurations. -->\n            <!-- Uncomment the following line to add the Secure flag to session cookies. -->\n            <!-- <secure>true</secure> -->\n        </cookie-config>\n        <tracking-mode>COOKIE</tracking-mode>\n    </session-config>\n\n    <mime-mapping>\n      <extension>xsl</extension>\n      <mime-type>text/xml</mime-type>\n    </mime-mapping>\n    <mime-mapping>\n      <extension>sld</extension>\n      <mime-type>text/xml</mime-type>\n    </mime-mapping>\n    <mime-mapping>\n      <extension>json</extension>\n      <mime-type>application/json</mime-type>\n    </mime-mapping>\n    <mime-mapping>\n      <extension>yaml</extension>\n      <mime-type>text/plain</mime-type>\n    </mime-mapping>\n\n    <welcome-file-list>\n        <welcome-file>index.html</welcome-file>\n    </welcome-file-list>\n\n</web-app>\n
                                                                              2. Uncomment the following <filter-mapping>:

                                                                                    <filter-mapping>\n        <filter-name>cross-origin</filter-name>\n        <url-pattern>/*</url-pattern>\n    </filter-mapping>\n\n    <filter-mapping>\n      <filter-name>filterChainProxy</filter-name>\n      <url-pattern>/*</url-pattern>\n    </filter-mapping>\n\n    <filter-mapping>\n      <filter-name>Advanced Dispatch Filter</filter-name>\n      <url-pattern>/*</url-pattern>\n    </filter-mapping>\n\n    <filter-mapping>\n      <filter-name>Spring Delegating Filter</filter-name>\n      <url-pattern>/*</url-pattern>\n    </filter-mapping>\n\n    <filter-mapping>\n      <filter-name>Thread locals cleanup filter</filter-name>\n      <url-pattern>/*</url-pattern>\n    </filter-mapping>\n\n    <!-- general initializer, should be first thing to execute \n    <listener>\n      <listener-class>org.geoserver.logging.LoggingStartupContextListener</listener-class>\n    </listener>\n\n    <!--  spring context loader \n    <listener>\n      <listener-class>org.geoserver.platform.GeoServerHttpSessionListenerProxy</listener-class>\n    </listener>\n\n    <!-- request context listener for session-scoped beans \n    <servlet>\n      <servlet-name>dispatcher</servlet-name>\n      <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>\n    </servlet>\n\n    <!-- single mapping to spring, this only works properly if the advanced dispatch filter is \n         active \n            <!-- will break non-HTTPS web UI access and may cause problems with some proxy configurations. \n            <!-- <secure>true</secure> \n
                                                                              3. Restart

                                                                              "},{"location":"production/container/#enable-cors-for-jetty-binary-installer","title":"Enable CORS for Jetty / binary installer","text":"

                                                                              The standalone distributions of GeoServer include the Jetty application server. Use the following steps to enable CORS for Jetty, for more information on what this does and other options see the Jetty Cross Origin Filter documentation

                                                                              1. Uncomment the following <filter> in webapps/geoserver/WEB-INF/web.xml:

                                                                                <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<web-app \n        xmlns=\"http://xmlns.jcp.org/xml/ns/javaee\" \n        xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\"\n        xsi:schemaLocation=\"http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd\"\n        metadata-complete=\"false\"\n        version=\"3.1\">\n    <display-name>GeoServer</display-name>\n\n      <context-param>\n    <param-name>serviceStrategy</param-name>\n    <!-- Meaning of the different values :\n\n         PARTIAL-BUFFER2\n         - Partially buffers the first xKb to disk. Once that has buffered, the the \n           result is streamed to the user. This will allow for most errors to be caught\n           early. \n\n         BUFFER\n         - stores the entire response in memory first, before sending it off to\n           the user (may run out of memory)\n\n         SPEED\n         - outputs directly to the response (and cannot recover in the case of an\n           error)\n\n         FILE\n         - outputs to the local filesystem first, before sending it off to the user\n      -->\n    <param-value>PARTIAL-BUFFER2</param-value>\n  </context-param>\n\n  <context-param>\n    <!-- see comments on the PARTIAL-BUFFER strategy -->\n    <!-- this sets the size of the buffer.  default is \"50\" = 50kb -->\n\n    <param-name>PARTIAL_BUFFER_STRATEGY_SIZE</param-name>\n    <param-value>50</param-value>\n  </context-param>\n\n  <!--Can be true or false (defaults to: false). -->\n  <!--When true the JSONP (text/javascript) output format is enabled -->\n  <!--\n  <context-param>\n    <param-name>ENABLE_JSONP</param-name>\n    <param-value>true</param-value>\n  </context-param>\n  -->\n    <!-- \n    <context-param>\n      <param-name>PROXY_BASE_URL</param-name>\n      <param-value>http://82.58.146.45/geoserver</param-value>\n    </context-param>\n     -->\n\n     <!--\n    <context-param>\n       <param-name>GEOSERVER_DATA_DIR</param-name>\n        <param-value>C:\\eclipse\\workspace\\geoserver_trunk\\cite\\confCiteWFSPostGIS</param-value>\n    </context-param> \n   -->\n\n    <!-- pick up all spring application contexts -->\n    <context-param>\n        <param-name>contextConfigLocation</param-name>\n        <param-value>classpath*:/applicationContext.xml classpath*:/applicationSecurityContext.xml</param-value>\n    </context-param>\n\n    <filter>\n     <filter-name>FlushSafeFilter</filter-name>\n     <filter-class>org.geoserver.filters.FlushSafeFilter</filter-class>\n    </filter>\n\n    <filter>\n      <filter-name>Set Character Encoding</filter-name>\n      <filter-class>org.springframework.web.filter.CharacterEncodingFilter</filter-class>\n      <init-param>\n        <param-name>encoding</param-name>\n        <param-value>UTF-8</param-value>\n      </init-param>\n    </filter>\n\n    <filter>\n     <filter-name>SessionDebugger</filter-name>\n     <filter-class>org.geoserver.filters.SessionDebugFilter</filter-class>\n    </filter>\n\n    <filter>\n    <filter-name>filterChainProxy</filter-name>     \n     <filter-class> org.springframework.web.filter.DelegatingFilterProxy</filter-class>\n    </filter>\n\n    <filter>\n      <filter-name>xFrameOptionsFilter</filter-name>\n      <filter-class>org.geoserver.filters.XFrameOptionsFilter</filter-class>\n    </filter>\n\n   <filter>\n     <filter-name>GZIP Compression Filter</filter-name>\n     <filter-class>org.geoserver.filters.GZIPFilter</filter-class>\n     <init-param>\n         <!-- The compressed-types parameter is a comma-separated list of regular expressions.\n              If a mime type matches any of the regular expressions then it will be compressed.\n              -->\n         <param-name>compressed-types</param-name>\n         <param-value>text/.*,.*xml.*,application/json,application/x-javascript</param-value>\n     </init-param>\n   </filter>\n\n   <filter>\n     <filter-name>Advanced Dispatch Filter</filter-name>\n     <filter-class>org.geoserver.platform.AdvancedDispatchFilter</filter-class>\n     <!-- \n     This filter allows for a single mapping to the spring dispatcher. However using /* as a mapping\n     in a servlet mapping causes the servlet path to be \"/\" of the request. This causes problems with\n     library like wicket and restlet. So this filter fakes the servlet path by assuming the first \n     component of the path is the mapped path. \n     -->\n   </filter>\n\n   <filter>\n    <filter-name>Spring Delegating Filter</filter-name>\n    <filter-class>org.geoserver.filters.SpringDelegatingFilter</filter-class>\n    <!--\n    This filter allows for filters to be loaded via spring rather than \n    registered here in web.xml.  One thing to note is that for such filters \n    init() is not called. INstead any initialization is performed via spring \n    ioc.\n    -->\n   </filter>\n\n   <filter>\n     <filter-name>Thread locals cleanup filter</filter-name>\n     <filter-class>org.geoserver.filters.ThreadLocalsCleanupFilter</filter-class>\n     <!-- \n     This filter cleans up thread locals Geotools is setting up for concurrency and performance\n     reasons \n     -->\n   </filter>\n\n   <!-- Uncomment following filter to enable CORS in Jetty. Do not forget the second config block further down.\n    <filter>\n      <filter-name>cross-origin</filter-name>\n      <filter-class>org.eclipse.jetty.servlets.CrossOriginFilter</filter-class>\n      <init-param>\n        <param-name>chainPreflight</param-name>\n        <param-value>false</param-value>\n      </init-param>\n      <init-param>\n        <param-name>allowedOrigins</param-name>\n        <param-value>*</param-value>\n      </init-param>\n      <init-param>\n        <param-name>allowedMethods</param-name>\n        <param-value>GET,POST,PUT,DELETE,HEAD,OPTIONS</param-value>\n      </init-param>\n      <init-param>\n        <param-name>allowedHeaders</param-name>\n        <param-value>*</param-value>\n      </init-param>\n    </filter>\n    -->\n\n   <!-- Uncomment following filter to enable CORS in Tomcat. Do not forget the second config block further down.\n    <filter>\n      <filter-name>cross-origin</filter-name>\n      <filter-class>org.apache.catalina.filters.CorsFilter</filter-class>\n      <init-param>\n        <param-name>cors.allowed.origins</param-name>\n        <param-value>*</param-value>\n      </init-param>\n      <init-param>\n        <param-name>cors.allowed.methods</param-name>\n        <param-value>GET,POST,PUT,DELETE,HEAD,OPTIONS</param-value>\n      </init-param>\n      <init-param>\n        <param-name>cors.allowed.headers</param-name>\n        <param-value>*</param-value>\n      </init-param>\n    </filter>\n    -->\n\n    <!-- \n      THIS FILTER MAPPING MUST BE THE FIRST ONE, otherwise we end up with ruined chars in the input from the GUI\n      See the \"Note\" in the Tomcat character encoding guide:\n      http://wiki.apache.org/tomcat/FAQ/CharacterEncoding\n    -->\n    <filter-mapping>\n      <filter-name>Set Character Encoding</filter-name>\n      <url-pattern>/*</url-pattern>\n    </filter-mapping>\n\n    <!-- Uncomment following filter-mapping to enable CORS\n    <filter-mapping>\n        <filter-name>cross-origin</filter-name>\n        <url-pattern>/*</url-pattern>\n    </filter-mapping>\n    -->\n\n    <filter-mapping>\n      <filter-name>FlushSafeFilter</filter-name>\n      <url-pattern>/*</url-pattern>\n    </filter-mapping>\n\n    <filter-mapping>\n      <filter-name>SessionDebugger</filter-name>\n      <url-pattern>/*</url-pattern>\n    </filter-mapping>\n\n    <filter-mapping>\n      <filter-name>GZIP Compression Filter</filter-name>\n      <url-pattern>/*</url-pattern>\n    </filter-mapping>\n\n    <filter-mapping>\n      <filter-name>xFrameOptionsFilter</filter-name>\n      <url-pattern>/*</url-pattern>\n    </filter-mapping>\n\n    <!-- \n      If you want to use your security system comment out this one too\n    -->\n    <filter-mapping>\n      <filter-name>filterChainProxy</filter-name>\n      <url-pattern>/*</url-pattern>\n    </filter-mapping>\n\n    <filter-mapping>\n      <filter-name>Advanced Dispatch Filter</filter-name>\n      <url-pattern>/*</url-pattern>\n    </filter-mapping>\n\n    <filter-mapping>\n      <filter-name>Spring Delegating Filter</filter-name>\n      <url-pattern>/*</url-pattern>\n    </filter-mapping>\n\n    <filter-mapping>\n      <filter-name>Thread locals cleanup filter</filter-name>\n      <url-pattern>/*</url-pattern>\n    </filter-mapping>\n\n    <!-- general initializer, should be first thing to execute -->\n    <listener>\n      <listener-class>org.geoserver.GeoserverInitStartupListener</listener-class>\n    </listener>\n\n    <!-- logging initializer, should execute before spring context startup -->\n    <listener>\n      <listener-class>org.geoserver.logging.LoggingStartupContextListener</listener-class>\n    </listener>\n\n    <!--  spring context loader -->\n    <listener>\n      <listener-class>org.geoserver.platform.GeoServerContextLoaderListener</listener-class>\n    </listener>\n\n    <!--  http session listener proxy -->\n    <listener>\n      <listener-class>org.geoserver.platform.GeoServerHttpSessionListenerProxy</listener-class>\n    </listener>\n\n    <!-- request context listener for session-scoped beans -->\n    <listener>\n        <listener-class>org.springframework.web.context.request.RequestContextListener</listener-class>\n    </listener>\n\n    <!-- spring dispatcher servlet, dispatches all incoming requests -->\n    <servlet>\n      <servlet-name>dispatcher</servlet-name>\n      <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>\n    </servlet>\n\n    <!-- single mapping to spring, this only works properly if the advanced dispatch filter is \n         active -->\n    <servlet-mapping>\n        <servlet-name>dispatcher</servlet-name>\n        <url-pattern>/*</url-pattern>\n    </servlet-mapping>\n\n    <session-config>\n        <cookie-config>\n            <http-only>true</http-only>\n            <!-- The Secure flag should be set on session cookies but is commented out by default since it -->\n            <!-- will break non-HTTPS web UI access and may cause problems with some proxy configurations. -->\n            <!-- Uncomment the following line to add the Secure flag to session cookies. -->\n            <!-- <secure>true</secure> -->\n        </cookie-config>\n        <tracking-mode>COOKIE</tracking-mode>\n    </session-config>\n\n    <mime-mapping>\n      <extension>xsl</extension>\n      <mime-type>text/xml</mime-type>\n    </mime-mapping>\n    <mime-mapping>\n      <extension>sld</extension>\n      <mime-type>text/xml</mime-type>\n    </mime-mapping>\n    <mime-mapping>\n      <extension>json</extension>\n      <mime-type>application/json</mime-type>\n    </mime-mapping>\n    <mime-mapping>\n      <extension>yaml</extension>\n      <mime-type>text/plain</mime-type>\n    </mime-mapping>\n\n    <welcome-file-list>\n        <welcome-file>index.html</welcome-file>\n    </welcome-file-list>\n\n</web-app>\n
                                                                              2. Uncomment the following <filter-mapping>:

                                                                                <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<web-app \n        xmlns=\"http://xmlns.jcp.org/xml/ns/javaee\" \n        xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\"\n        xsi:schemaLocation=\"http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd\"\n        metadata-complete=\"false\"\n        version=\"3.1\">\n    <display-name>GeoServer</display-name>\n\n      <context-param>\n    <param-name>serviceStrategy</param-name>\n    <!-- Meaning of the different values :\n\n         PARTIAL-BUFFER2\n         - Partially buffers the first xKb to disk. Once that has buffered, the the \n           result is streamed to the user. This will allow for most errors to be caught\n           early. \n\n         BUFFER\n         - stores the entire response in memory first, before sending it off to\n           the user (may run out of memory)\n\n         SPEED\n         - outputs directly to the response (and cannot recover in the case of an\n           error)\n\n         FILE\n         - outputs to the local filesystem first, before sending it off to the user\n      -->\n    <param-value>PARTIAL-BUFFER2</param-value>\n  </context-param>\n\n  <context-param>\n    <!-- see comments on the PARTIAL-BUFFER strategy -->\n    <!-- this sets the size of the buffer.  default is \"50\" = 50kb -->\n\n    <param-name>PARTIAL_BUFFER_STRATEGY_SIZE</param-name>\n    <param-value>50</param-value>\n  </context-param>\n\n  <!--Can be true or false (defaults to: false). -->\n  <!--When true the JSONP (text/javascript) output format is enabled -->\n  <!--\n  <context-param>\n    <param-name>ENABLE_JSONP</param-name>\n    <param-value>true</param-value>\n  </context-param>\n  -->\n    <!-- \n    <context-param>\n      <param-name>PROXY_BASE_URL</param-name>\n      <param-value>http://82.58.146.45/geoserver</param-value>\n    </context-param>\n     -->\n\n     <!--\n    <context-param>\n       <param-name>GEOSERVER_DATA_DIR</param-name>\n        <param-value>C:\\eclipse\\workspace\\geoserver_trunk\\cite\\confCiteWFSPostGIS</param-value>\n    </context-param> \n   -->\n\n    <!-- pick up all spring application contexts -->\n    <context-param>\n        <param-name>contextConfigLocation</param-name>\n        <param-value>classpath*:/applicationContext.xml classpath*:/applicationSecurityContext.xml</param-value>\n    </context-param>\n\n    <filter>\n     <filter-name>FlushSafeFilter</filter-name>\n     <filter-class>org.geoserver.filters.FlushSafeFilter</filter-class>\n    </filter>\n\n    <filter>\n      <filter-name>Set Character Encoding</filter-name>\n      <filter-class>org.springframework.web.filter.CharacterEncodingFilter</filter-class>\n      <init-param>\n        <param-name>encoding</param-name>\n        <param-value>UTF-8</param-value>\n      </init-param>\n    </filter>\n\n    <filter>\n     <filter-name>SessionDebugger</filter-name>\n     <filter-class>org.geoserver.filters.SessionDebugFilter</filter-class>\n    </filter>\n\n    <filter>\n    <filter-name>filterChainProxy</filter-name>     \n     <filter-class> org.springframework.web.filter.DelegatingFilterProxy</filter-class>\n    </filter>\n\n    <filter>\n      <filter-name>xFrameOptionsFilter</filter-name>\n      <filter-class>org.geoserver.filters.XFrameOptionsFilter</filter-class>\n    </filter>\n\n   <filter>\n     <filter-name>GZIP Compression Filter</filter-name>\n     <filter-class>org.geoserver.filters.GZIPFilter</filter-class>\n     <init-param>\n         <!-- The compressed-types parameter is a comma-separated list of regular expressions.\n              If a mime type matches any of the regular expressions then it will be compressed.\n              -->\n         <param-name>compressed-types</param-name>\n         <param-value>text/.*,.*xml.*,application/json,application/x-javascript</param-value>\n     </init-param>\n   </filter>\n\n   <filter>\n     <filter-name>Advanced Dispatch Filter</filter-name>\n     <filter-class>org.geoserver.platform.AdvancedDispatchFilter</filter-class>\n     <!-- \n     This filter allows for a single mapping to the spring dispatcher. However using /* as a mapping\n     in a servlet mapping causes the servlet path to be \"/\" of the request. This causes problems with\n     library like wicket and restlet. So this filter fakes the servlet path by assuming the first \n     component of the path is the mapped path. \n     -->\n   </filter>\n\n   <filter>\n    <filter-name>Spring Delegating Filter</filter-name>\n    <filter-class>org.geoserver.filters.SpringDelegatingFilter</filter-class>\n    <!--\n    This filter allows for filters to be loaded via spring rather than \n    registered here in web.xml.  One thing to note is that for such filters \n    init() is not called. INstead any initialization is performed via spring \n    ioc.\n    -->\n   </filter>\n\n   <filter>\n     <filter-name>Thread locals cleanup filter</filter-name>\n     <filter-class>org.geoserver.filters.ThreadLocalsCleanupFilter</filter-class>\n     <!-- \n     This filter cleans up thread locals Geotools is setting up for concurrency and performance\n     reasons \n     -->\n   </filter>\n\n   <!-- Uncomment following filter to enable CORS in Jetty. Do not forget the second config block further down.\n    <filter>\n      <filter-name>cross-origin</filter-name>\n      <filter-class>org.eclipse.jetty.servlets.CrossOriginFilter</filter-class>\n      <init-param>\n        <param-name>chainPreflight</param-name>\n        <param-value>false</param-value>\n      </init-param>\n      <init-param>\n        <param-name>allowedOrigins</param-name>\n        <param-value>*</param-value>\n      </init-param>\n      <init-param>\n        <param-name>allowedMethods</param-name>\n        <param-value>GET,POST,PUT,DELETE,HEAD,OPTIONS</param-value>\n      </init-param>\n      <init-param>\n        <param-name>allowedHeaders</param-name>\n        <param-value>*</param-value>\n      </init-param>\n    </filter>\n    -->\n\n   <!-- Uncomment following filter to enable CORS in Tomcat. Do not forget the second config block further down.\n    <filter>\n      <filter-name>cross-origin</filter-name>\n      <filter-class>org.apache.catalina.filters.CorsFilter</filter-class>\n      <init-param>\n        <param-name>cors.allowed.origins</param-name>\n        <param-value>*</param-value>\n      </init-param>\n      <init-param>\n        <param-name>cors.allowed.methods</param-name>\n        <param-value>GET,POST,PUT,DELETE,HEAD,OPTIONS</param-value>\n      </init-param>\n      <init-param>\n        <param-name>cors.allowed.headers</param-name>\n        <param-value>*</param-value>\n      </init-param>\n    </filter>\n    -->\n\n    <!-- \n      THIS FILTER MAPPING MUST BE THE FIRST ONE, otherwise we end up with ruined chars in the input from the GUI\n      See the \"Note\" in the Tomcat character encoding guide:\n      http://wiki.apache.org/tomcat/FAQ/CharacterEncoding\n    -->\n    <filter-mapping>\n      <filter-name>Set Character Encoding</filter-name>\n      <url-pattern>/*</url-pattern>\n    </filter-mapping>\n\n    <!-- Uncomment following filter-mapping to enable CORS\n    <filter-mapping>\n        <filter-name>cross-origin</filter-name>\n        <url-pattern>/*</url-pattern>\n    </filter-mapping>\n    -->\n\n    <filter-mapping>\n      <filter-name>FlushSafeFilter</filter-name>\n      <url-pattern>/*</url-pattern>\n    </filter-mapping>\n\n    <filter-mapping>\n      <filter-name>SessionDebugger</filter-name>\n      <url-pattern>/*</url-pattern>\n    </filter-mapping>\n\n    <filter-mapping>\n      <filter-name>GZIP Compression Filter</filter-name>\n      <url-pattern>/*</url-pattern>\n    </filter-mapping>\n\n    <filter-mapping>\n      <filter-name>xFrameOptionsFilter</filter-name>\n      <url-pattern>/*</url-pattern>\n    </filter-mapping>\n\n    <!-- \n      If you want to use your security system comment out this one too\n    -->\n    <filter-mapping>\n      <filter-name>filterChainProxy</filter-name>\n      <url-pattern>/*</url-pattern>\n    </filter-mapping>\n\n    <filter-mapping>\n      <filter-name>Advanced Dispatch Filter</filter-name>\n      <url-pattern>/*</url-pattern>\n    </filter-mapping>\n\n    <filter-mapping>\n      <filter-name>Spring Delegating Filter</filter-name>\n      <url-pattern>/*</url-pattern>\n    </filter-mapping>\n\n    <filter-mapping>\n      <filter-name>Thread locals cleanup filter</filter-name>\n      <url-pattern>/*</url-pattern>\n    </filter-mapping>\n\n    <!-- general initializer, should be first thing to execute -->\n    <listener>\n      <listener-class>org.geoserver.GeoserverInitStartupListener</listener-class>\n    </listener>\n\n    <!-- logging initializer, should execute before spring context startup -->\n    <listener>\n      <listener-class>org.geoserver.logging.LoggingStartupContextListener</listener-class>\n    </listener>\n\n    <!--  spring context loader -->\n    <listener>\n      <listener-class>org.geoserver.platform.GeoServerContextLoaderListener</listener-class>\n    </listener>\n\n    <!--  http session listener proxy -->\n    <listener>\n      <listener-class>org.geoserver.platform.GeoServerHttpSessionListenerProxy</listener-class>\n    </listener>\n\n    <!-- request context listener for session-scoped beans -->\n    <listener>\n        <listener-class>org.springframework.web.context.request.RequestContextListener</listener-class>\n    </listener>\n\n    <!-- spring dispatcher servlet, dispatches all incoming requests -->\n    <servlet>\n      <servlet-name>dispatcher</servlet-name>\n      <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>\n    </servlet>\n\n    <!-- single mapping to spring, this only works properly if the advanced dispatch filter is \n         active -->\n    <servlet-mapping>\n        <servlet-name>dispatcher</servlet-name>\n        <url-pattern>/*</url-pattern>\n    </servlet-mapping>\n\n    <session-config>\n        <cookie-config>\n            <http-only>true</http-only>\n            <!-- The Secure flag should be set on session cookies but is commented out by default since it -->\n            <!-- will break non-HTTPS web UI access and may cause problems with some proxy configurations. -->\n            <!-- Uncomment the following line to add the Secure flag to session cookies. -->\n            <!-- <secure>true</secure> -->\n        </cookie-config>\n        <tracking-mode>COOKIE</tracking-mode>\n    </session-config>\n\n    <mime-mapping>\n      <extension>xsl</extension>\n      <mime-type>text/xml</mime-type>\n    </mime-mapping>\n    <mime-mapping>\n      <extension>sld</extension>\n      <mime-type>text/xml</mime-type>\n    </mime-mapping>\n    <mime-mapping>\n      <extension>json</extension>\n      <mime-type>application/json</mime-type>\n    </mime-mapping>\n    <mime-mapping>\n      <extension>yaml</extension>\n      <mime-type>text/plain</mime-type>\n    </mime-mapping>\n\n    <welcome-file-list>\n        <welcome-file>index.html</welcome-file>\n    </welcome-file-list>\n\n</web-app>\n
                                                                              3. Restart

                                                                              "},{"location":"production/data/","title":"Data Considerations","text":""},{"location":"production/data/#use-an-external-data-directory","title":"Use an external data directory","text":"

                                                                              GeoServer comes with a built-in data directory. However, it is a good idea to separate the data from the application. Using an external data directory allows for much easier upgrades, since there is no risk of configuration information being overwritten. An external data directory also makes it easy to transfer your configuration elsewhere if desired. To point to an external data directory, you only need to edit the web.xml file. If you are new to GeoServer, you can copy (or just move) the data directory that comes with GeoServer to another location.

                                                                              "},{"location":"production/data/#use-a-spatial-database","title":"Use a spatial database","text":"

                                                                              Shapefiles are a very common format for geospatial data. But if you are running GeoServer in a production environment, it is better to use a spatial database such as PostGIS. This is essential if doing transactions (WFS-T). Most spatial databases provide shapefile conversion tools. Although there are many options for spatial databases (see the section on Databases), PostGIS is recommended. Oracle, and DB2 are also supported.

                                                                              "},{"location":"production/data/#pick-the-best-performing-coverage-formats","title":"Pick the best performing coverage formats","text":"

                                                                              There are very significant differences between performance of the various coverage formats.

                                                                              Serving big coverage data sets with good performance requires some knowledge and tuning, since usually data is set up for distribution and archival. The following tips try to provide you with a base knowledge of how data restructuring affects performance, and how to use the available tools to get optimal data serving performance.

                                                                              "},{"location":"production/data/#choose-the-right-format","title":"Choose the right format","text":"

                                                                              The first key element is choosing the right format. Some formats are designed for data exchange, others for data rendering and serving. A good data serving format is binary, allows for multi-resolution extraction, and provides support for quick subset extraction at native resolutions.

                                                                              Examples of such formats are GeoTiff, ECW, JPEG 2000 and MrSid. ArcGrid on the other hand is an example of format that's particularly ill-suited for large dataset serving (it's text based, no multi-resolution, and we have to read it fully even to extract a data subset in the general case).

                                                                              GeoServer supports MrSID, ECW and JPEG 2000 through the GDAL Image Format plugin. MrSID is the easiest to work with, as their reader is now available under a GeoServer compatible open source format. If you have ECW files you have several non-ideal options. If you are only using GeoServer for educational or non-profit purposes you can use the plugin for free. If not you need to buy a license, since it's server software. You could also use GDAL to convert it to MrSID or tiled GeoTiffs. If your files are JPEG 2000 you can use the utilities of ECW and MrSID software. But the fastest is Kakadu, which requires a license.

                                                                              "},{"location":"production/data/#setup-geotiff-data-for-fast-rendering","title":"Setup Geotiff data for fast rendering","text":"

                                                                              As soon as your Geotiffs gets beyond some tens of megabytes you'll want to add the following capabilities:

                                                                              • inner tiling
                                                                              • overviews

                                                                              Inner tiling sets up the image layout so that it's organized in tiles instead of simple stripes (rows). This allows much quicker access to a certain area of the geotiff, and the GeoServer readers will leverage this by accessing only the tiles needed to render the current display area. The following sample command instructs gdal_translate to create a tiled geotiff.

                                                                              gdal_translate -of GTiff -projwin -180 90 -50 -10 -co \"TILED=YES\" bigDataSet.ecw myTiff.tiff\n

                                                                              An overview is a downsampled version of the same image, that is, a zoomed out version, which is usually much smaller. When GeoServer needs to render the Geotiff, it'll look for the most appropriate overview as a starting point, thus reading and converting way less data. Overviews can be added using gdaladdo, or the OverviewsEmbedded command included in Geotools. Here is a sample of using gdaladdo to add overviews that are downsampled 2, 4, 8 and 16 times compared to the original:

                                                                              gdaladdo -r average mytiff.tif 2 4 8 16\n

                                                                              As a final note, Geotiff supports various kinds of compression both lossles as well as lossy. JPEG compression can produce artifacts but it usually produce very good results on RGB or RGBA images if coupled with inner masks. Deflate compression is to be preferred with elevation or similar data when a lossless compressions is needed. Generally speaking, if I/O is the bottleneck, compression can help a lot as it reduces the cost of I/O although at the expenses of some CPU cycles.

                                                                              "},{"location":"production/data/#handling-huge-data-sets","title":"Handling huge data sets","text":"

                                                                              If you have really huge data sets (several gigabytes), odds are that simply adding overviews and tiles does not cut it, making intermediate resolution serving slow. This is because tiling occurs only on the native resolution levels, and intermediate overviews are too big for quick extraction.

                                                                              So, what you need is a way to have tiling on intermediate levels as well. This is supported by the ImagePyramid plugin.

                                                                              This plugin assumes you have create various seamless image mosaics, each for a different resolution level of the original image. In the mosaic, tiles are actual files (for more info about mosaics, see the ImageMosaic). The whole pyramid structures looks like the following:

                                                                              rootDirectory\n    +- pyramid.properties\n    +- 0\n       +- mosaic metadata files\n       +- mosaic_file_0.tiff\n       +- ...\n       +- mosiac_file_n.tiff\n    +- ...\n    +- 32\n       +- mosaic metadata files\n       +- mosaic_file_0.tiff\n       +- ...\n       +- mosiac_file_n.tiff\n

                                                                              Creating a pyramid by hand can theoretically be done with gdal, but in practice it's a daunting task that would require some scripting, since gdal provides no \"tiler\" command to extract regular tiles out of an image, nor one to create a downsampled set of tiles. As an alternative, you can use the geotools PyramidBuilder tool (documentation on how to use this is pending, contact the developers if you need to use it).

                                                                              "},{"location":"production/identify/","title":"Make cluster nodes identifiable from the GUI","text":"

                                                                              When running one or more clusters of GeoServer installations it is useful to identify which cluster (and eventually which node of the cluster) one is working against by just glancing the web administration UI.

                                                                              This is possible by setting one variable, GEOSERVER_NODE_OPTS, with one of the supported mechanisms:

                                                                              • as a system variable
                                                                              • as an environment variable
                                                                              • as a servlet context parameter

                                                                              GEOSERVER_NODE_OPTS is a semicolon separated list of key/value pairs and it can contain the following keys:

                                                                              • id: the string identifying the node, which in turn can be a static string, or include the following substitution tokens
                                                                                • $host_ip The IP address of the node
                                                                                • $host_name The hostname of the node
                                                                                • $host_short_name The hostname truncated to not include the domain (foo.local becomes foo)
                                                                                • $host_compact_name The hostname with all domain parts shortened to their first character (foo.local becomes foo.l)
                                                                              • color: the label color, as a CSS color
                                                                              • background: the background color, as a CSS color

                                                                              Here are some examples:

                                                                              GEOSERVER_NODE_OPTS=\"id:test1;background:black;color:white\"

                                                                              GEOSERVER_NODE_OPTS=\"id:$host_ip\"

                                                                              GEOSERVER_NODE_OPTS=\"id:$host_name\"

                                                                              "},{"location":"production/java/","title":"Java Considerations","text":""},{"location":"production/java/#use-supported-jre","title":"Use supported JRE","text":"

                                                                              GeoServer's speed depends a lot on the chosen Java Runtime Environment (JRE). The latest versions of GeoServer are tested with both Oracle JRE and OpenJDK. Implementations other than those tested may work correctly, but are generally not recommended.

                                                                              Tested:

                                                                              • Java 17 - GeoServer 2.22.x and above (OpenJDK tested, experimental only)
                                                                              • Java 11 - GeoServer 2.15.x and above (OpenJDK tested)
                                                                              • Java 8 - GeoServer 2.9.x to GeoServer 2.22.x (OpenJDK and Oracle JRE tested)
                                                                              • Java 7 - GeoServer 2.6.x to GeoServer 2.8.x (OpenJDK and Oracle JRE tested)
                                                                              • Java 6 - GeoServer 2.3.x to GeoServer 2.5.x (Oracle JRE tested)
                                                                              • Java 5 - GeoServer 2.2.x and earlier (Sun JRE tested)

                                                                              As of GeoServer 2.0, a Java Runtime Environment (JRE) is sufficient to run GeoServer. GeoServer no longer requires a Java Development Kit (JDK).

                                                                              "},{"location":"production/java/#running-on-java-17","title":"Running on Java 17","text":"

                                                                              GeoServer is compatible with Java 17, but requires extra care for running in some environments.

                                                                              Deployment on Tomcat 9.0.55 has been tested with success.

                                                                              The \"bin\" packaging can work too, but requires turning off the Marlin rasterizer integration. This can be done by modifying the scripts, or by simply removing the Marlin jars:

                                                                              rm webapps/geoserver/WEB-INF/lib/marlin-0.9.3.jar\n

                                                                              GeoServer code depends on a variety of libraries trying to access the JDK internals. As reported above, it does not seem to matter when running as a web application. However, in case of need, here is the full list of opens used by the build process:

                                                                              --add-opens=java.base/java.lang=ALL-UNNAMED --add-opens=java.base/java.util=ALL-UNNAMED --add-opens=java.base/java.lang.reflect=ALL-UNNAMED --add-opens=java.base/java.text=ALL-UNNAMED --add-opens=java.desktop/java.awt.font=ALL-UNNAMED  --add-opens=java.desktop/sun.awt.image=ALL-UNNAMED --add-opens=java.naming/com.sun.jndi.ldap=ALL-UNNAMED\n
                                                                              "},{"location":"production/java/#running-on-java-11","title":"Running on Java 11","text":"

                                                                              GeoServer 2.15 will run under Java 11 with no additional configuration on Tomcat 9 or newer and Jetty 9.4.12 or newer.

                                                                              Running GeoServer under Java 11 on other Application Servers may require some additional configuration. Some Application Servers do not support Java 11 yet.

                                                                              • Wildfly 14 supports Java 11, with some additional configuration - in the run configuration, under VM arguments add:

                                                                                --add-modules=java.se

                                                                                Future WildFly releases should support Java 11 with no additional configuration.

                                                                              • GlassFish does not currently Java 11, although the upcoming 5.0.1 release is expected to include support for it.

                                                                              • WebLogic do not yet support Java 11.

                                                                              "},{"location":"production/linuxscript/","title":"Linux init scripts","text":"

                                                                              You will have to adjust the scripts to your environment. Download a script, rename it to geoserver and move it to /etc/init.d. Use chmod to make the script executable and test with /etc/init.d/geoserver.

                                                                              To set different values for environment variables, create a file /etc/default/geoserver and specify your environment.

                                                                              Example settings in /etc/default/geoserver for your environment:

                                                                              USER=geoserver\nGEOSERVER_DATA_DIR=/home/$USER/data_dir\nGEOSERVER_HOME=/home/$USER/geoserver\nJAVA_HOME=/usr/lib/jvm/java-6-sun\nJAVA_OPTS=\"-Xms128m -Xmx512m\"\n
                                                                              "},{"location":"production/linuxscript/#debianubuntu","title":"Debian/Ubuntu","text":"

                                                                              Download the init script

                                                                              "},{"location":"production/linuxscript/#suse","title":"Suse","text":"

                                                                              Download the init script

                                                                              "},{"location":"production/linuxscript/#starting-geoserver-in-tomcat","title":"Starting GeoServer in Tomcat","text":"

                                                                              Download the init script

                                                                              "},{"location":"production/misc/","title":"Other Considerations","text":""},{"location":"production/misc/#host-your-application-separately","title":"Host your application separately","text":"

                                                                              GeoServer includes a few sample applications in the demo section of the Web administration interface. For production instances, we recommend against this bundling of your application. To make upgrades and troubleshooting easier, please use a separate container for your application. It is perfectly fine, though, to use one container manager (such as Tomcat or Jetty) to host both GeoServer and your application.

                                                                              "},{"location":"production/misc/#proxy-your-server","title":"Proxy your server","text":"

                                                                              GeoServer can have the capabilities documents properly report a proxy. You can configure this in the Server configuration section of the Web administration interface and entering the URL of the external proxy in the field labeled Proxy base URL.

                                                                              "},{"location":"production/misc/#publish-your-servers-capabilities-documents","title":"Publish your server's capabilities documents","text":"

                                                                              In order to make it easier to find your data, put a link to your capabilities document somewhere on the web. This will ensure that a search engine will crawl and index it.

                                                                              "},{"location":"production/misc/#set-up-clustering","title":"Set up clustering","text":"

                                                                              Setting up a Cluster is one of the best ways to improve the reliability and performance of your GeoServer installation. All the most stable and high performance GeoServer instances are configured in some sort of cluster. There are a huge variety of techniques to configure a cluster, including at the container level, the virtual machine level, and the physical server level.

                                                                              Andrea Aime is currently working on an overview of what some of the biggest GeoServer users have done, for his 'GeoServer in Production' talk at FOSS4G 2009. In time that information will be migrated to tutorials and white papers.

                                                                              "},{"location":"production/troubleshooting/","title":"Troubleshooting","text":""},{"location":"production/troubleshooting/#checking-wfs-requests","title":"Checking WFS requests","text":"

                                                                              It often happens that users report issues with hand-crafted WFS requests not working as expected. In the majority of the cases the request is malformed, but GeoServer does not complain and just ignores the malformed part (this behaviour is the default to make older WFS clients work fine with GeoServer).

                                                                              If you want GeoServer to validate most WFS XML request you can post it to the following URL:

                                                                              http://host:port/geoserver/ows?strict=true\n

                                                                              Any deviation from the required structure will be noted in an error message. The only request type that is not validated in any case is the INSERT one (this is a GeoServer own limitation).

                                                                              "},{"location":"production/troubleshooting/#leveraging-geoserver-own-log","title":"Leveraging GeoServer own log","text":"

                                                                              GeoServer can generate a quite extensive log of its operations in the $GEOSERVER_DATA_DIR/logs/geoserver.log file. Looking into such file is one of the first things to do when troubleshooting a problem, in particular it's interesting to see the log contents in correspondence of a misbehaving request. The amount of information logged can vary based on the logging profile chosen in the Server Settings configuration page.

                                                                              "},{"location":"production/troubleshooting/#troubleshooting_requests","title":"Logging service requests","text":"

                                                                              GeoServer provides a request logging capability that is inactive by default. When enabled in the global settings GeoServer can log both the requested URL and POST requests contents.

                                                                              Global Settings

                                                                              To track a history of the incoming requests:

                                                                              1. Enable request logging by navigating to Settings > Global page, scroll down to Logging Settings, and Enable Request Logging.

                                                                              2. Enable this feature using Enable Request Logging.

                                                                              3. Optionally select Log Request Bodies to troubleshoot POST or PUT requests (for example WFS Transaction). The Number of characters to log setting will put an upper limit on the amount of data that is logged in order to avoid logging related performance issues.

                                                                              4. Optionally select Log Request Headers to troubleshoot Request Headers (for example when checking security credentials).

                                                                              5. Click Apply to apply these settings.

                                                                              6. This will log request information, resulting in something like the following:

                                                                                08 gen 11:30:13 INFO [geoserver.filters] - 127.0.0.1 \"GET /geoserver/wms?HEIGHT=330&WIDTH=660&LAYERS=nurc%3AArc_Sample&STYLES=&SRS=EPSG%3A4326&FORMAT=image%2Fjpeg&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&EXCEPTIONS=application%2Fvnd.ogc.se_inimage&BBOX=-93.515625,-40.078125,138.515625,75.9375\" \"Mozilla/5.0 (X11; U; Linux i686; it; rv:1.9.0.15) Gecko/2009102815 Ubuntu/9.04 (jaunty) Firefox/3.0.15\" \"http://localhost:8080/geoserver/wms?service=WMS&version=1.1.0&request=GetMap&layers=nurc:Arc_Sample&styles=&bbox=-180.0,-90.0,180.0,90.0&width=660&height=330&srs=EPSG:4326&format=application/openlayers\" \n08 gen 11:30:13 INFO [geoserver.filters] - 127.0.0.1 \"GET /geoserver/wms?HEIGHT=330&WIDTH=660&LAYERS=nurc%3AArc_Sample&STYLES=&SRS=EPSG%3A4326&FORMAT=image%2Fjpeg&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&EXCEPTIONS=application%2Fvnd.ogc.se_inimage&BBOX=-93.515625,-40.078125,138.515625,75.9375\" took 467ms\n08 gen 11:30:14 INFO [geoserver.filters] - 127.0.0.1 \"GET /geoserver/wms?REQUEST=GetFeatureInfo&EXCEPTIONS=application%2Fvnd.ogc.se_xml&BBOX=-93.515625%2C-40.078125%2C138.515625%2C75.9375&X=481&Y=222&INFO_FORMAT=text%2Fhtml&QUERY_LAYERS=nurc%3AArc_Sample&FEATURE_COUNT=50&Layers=nurc%3AArc_Sample&Styles=&Srs=EPSG%3A4326&WIDTH=660&HEIGHT=330&format=image%2Fjpeg\" \"Mozilla/5.0 (X11; U; Linux i686; it; rv:1.9.0.15) Gecko/2009102815 Ubuntu/9.04 (jaunty) Firefox/3.0.15\" \"http://localhost:8080/geoserver/wms?service=WMS&version=1.1.0&request=GetMap&layers=nurc:Arc_Sample&styles=&bbox=-180.0,-90.0,180.0,90.0&width=660&height=330&srs=EPSG:4326&format=application/openlayers\" \n08 gen 11:30:14 INFO [geoserver.filters] - 127.0.0.1 \"GET /geoserver/wms?REQUEST=GetFeatureInfo&EXCEPTIONS=application%2Fvnd.ogc.se_xml&BBOX=-93.515625%2C-40.078125%2C138.515625%2C75.9375&X=481&Y=222&INFO_FORMAT=text%2Fhtml&QUERY_LAYERS=nurc%3AArc_Sample&FEATURE_COUNT=50&Layers=nurc%3AArc_Sample&Styles=&Srs=EPSG%3A4326&WIDTH=660&HEIGHT=330&format=image%2Fjpeg\" took 314ms\n
                                                                              "},{"location":"production/troubleshooting/#server-status-jvm-console","title":"Server Status JVM Console","text":"

                                                                              GeoServer provides a built-in JVM Console used to obtain:

                                                                              • Thread Dump information
                                                                              • Heap Dump information

                                                                              This page can be used to check current status and download the results for careful review.

                                                                              JVM Console

                                                                              "},{"location":"production/troubleshooting/#using-jdk-tools-to-get-stack-and-memory-dumps","title":"Using JDK tools to get stack and memory dumps","text":"

                                                                              The JDK contains three useful command line tools that can be used to gather information about GeoServer instances that are leaking memory or not performing as requested: jps, jstack and jmap.

                                                                              All tools work against a live Java Virtual Machine, the one running GeoServer in particular. In order for them to work properly you'll have to run them with a user that has enough privileges to connect to the JVM process, in particular super user or the same user that's running the JVM usually have the required right.

                                                                              "},{"location":"production/troubleshooting/#jps","title":"jps","text":"

                                                                              jps is a tool listing all the Java processing running. It can be used to retrieve the pid (process id) of the virtual machine that is running GeoServer. For example:

                                                                              > jps -mlv\n\n16235 org.apache.catalina.startup.Bootstrap start -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.util.logging.config.file=/home/aaime/devel/webcontainers/apache-tomcat-6.0.18/conf/logging.properties -Djava.endorsed.dirs=/home/aaime/devel/webcontainers/apache-tomcat-6.0.18/endorsed -Dcatalina.base=/home/aaime/devel/webcontainers/apache-tomcat-6.0.18 -Dcatalina.home=/home/aaime/devel/webcontainers/apache-tomcat-6.0.18 -Djava.io.tmpdir=/home/aaime/devel/webcontainers/apache-tomcat-6.0.18/temp\n11521  -XX:MinHeapFreeRatio=10 -XX:MaxHeapFreeRatio=20 -Djava.library.path=/usr/lib/jni -Dosgi.requiredJavaVersion=1.5 -XX:MaxPermSize=256m -Xms64m -Xmx1024m -XX:CMSClassUnloadingEnabled -XX:CMSPermGenSweepingEnabled -XX:+UseParNewGC\n16287 sun.tools.jps.Jps -mlv -Dapplication.home=/usr/lib/jvm/java-6-sun-1.6.0.16 -Xms8m\n

                                                                              The output shows the pid, the main class name if available, and the parameters passed to the JVM at startup. In this example 16235 is Tomcat hosting GeoServer, 11521 is an Eclipse instance, and 16287 is jps itself. In the common case you'll have only few JVM and the one running GeoServer can be identified by the parameters passed to it.

                                                                              "},{"location":"production/troubleshooting/#jstack","title":"jstack","text":"

                                                                              jstack is a tool for extracting the current stack trace for each thread running in the virtual machine. It can be used to identify scalability issues and to gather what the program is actually doing.

                                                                              It usually requires detailed understanding of the inner workings of GeoServer to properly interpret the jstack output.

                                                                              An example of usage:

                                                                              > jstack -F -l 16235 > /tmp/tomcat-stack.txt\nAttaching to process ID 16235, please wait...\nDebugger attached successfully.\nServer compiler detected.\nJVM version is 14.2-b01\n

                                                                              And the file contents might look like:

                                                                              Deadlock Detection:\n\nNo deadlocks found.\n\nThread 16269: (state = BLOCKED)\n - java.lang.Object.wait(long) @bci=0 (Interpreted frame)\n - org.apache.tomcat.util.threads.ThreadPool$MonitorRunnable.run() @bci=10, line=565 (Interpreted frame)\n - java.lang.Thread.run() @bci=11, line=619 (Interpreted frame)\n\nLocked ownable synchronizers:\n    - None\n\nThread 16268: (state = IN_NATIVE)\n - java.net.PlainSocketImpl.socketAccept(java.net.SocketImpl) @bci=0 (Interpreted frame)\n - java.net.PlainSocketImpl.accept(java.net.SocketImpl) @bci=7, line=390 (Interpreted frame)\n - java.net.ServerSocket.implAccept(java.net.Socket) @bci=60, line=453 (Interpreted frame)\n - java.net.ServerSocket.accept() @bci=48, line=421 (Interpreted frame)\n - org.apache.jk.common.ChannelSocket.accept(org.apache.jk.core.MsgContext) @bci=46, line=306 (Interpreted frame)\n - org.apache.jk.common.ChannelSocket.acceptConnections() @bci=72, line=660 (Interpreted frame)\n - org.apache.jk.common.ChannelSocket$SocketAcceptor.runIt(java.lang.Object[]) @bci=4, line=870 (Interpreted frame)\n - org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run() @bci=167, line=690 (Interpreted frame)\n - java.lang.Thread.run() @bci=11, line=619 (Interpreted frame)\n\nLocked ownable synchronizers:\n    - None\n\nThread 16267: (state = BLOCKED)\n - java.lang.Object.wait(long) @bci=0 (Interpreted frame)\n - java.lang.Object.wait() @bci=2, line=485 (Interpreted frame)\n - org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run() @bci=26, line=662 (Interpreted frame)\n - java.lang.Thread.run() @bci=11, line=619 (Interpreted frame)\n\nLocked ownable synchronizers:\n    - None\n\n...\n
                                                                              "},{"location":"production/troubleshooting/#jmap","title":"jmap","text":"

                                                                              jmap is a tool to gather information about the Java virtual machine. It can be used in a few interesting ways.

                                                                              By running it without arguments (other than the process id of the JVM) it will print out a dump of the native libraries used by the JVM. This can come in handy when one wants to double check GeoServer is actually using a certain version of a native library (e.g., GDAL):

                                                                              > jmap 17251\n\nAttaching to process ID 17251, please wait...\nDebugger attached successfully.\nServer compiler detected.\nJVM version is 14.2-b01\n0x08048000  46K   /usr/lib/jvm/java-6-sun-1.6.0.16/jre/bin/java\n0x7f87f000  6406K /usr/lib/jvm/java-6-sun-1.6.0.16/jre/lib/i386/libNCSEcw.so.0\n0x7f9b2000  928K  /usr/lib/libstdc++.so.6.0.10\n0x7faa1000  7275K /usr/lib/jvm/java-6-sun-1.6.0.16/jre/lib/i386/libgdal.so.1\n0x800e9000  1208K /usr/lib/jvm/java-6-sun-1.6.0.16/jre/lib/i386/libclib_jiio.so\n0x80320000  712K  /usr/lib/jvm/java-6-sun-1.6.0.16/jre/lib/i386/libNCSUtil.so.0\n0x80343000  500K  /usr/lib/jvm/java-6-sun-1.6.0.16/jre/lib/i386/libNCSCnet.so.0\n0x8035a000  53K   /lib/libgcc_s.so.1\n0x8036c000  36K   /usr/lib/jvm/java-6-sun-1.6.0.16/jre/lib/i386/libnio.so\n0x803e2000  608K  /usr/lib/jvm/java-6-sun-1.6.0.16/jre/lib/i386/libawt.so\n0x80801000  101K  /usr/lib/jvm/java-6-sun-1.6.0.16/jre/lib/i386/libgdaljni.so\n0x80830000  26K   /usr/lib/jvm/java-6-sun-1.6.0.16/jre/lib/i386/headless/libmawt.so\n0x81229000  93K   /usr/lib/jvm/java-6-sun-1.6.0.16/jre/lib/i386/libnet.so\n0xb7179000  74K   /usr/lib/jvm/java-6-sun-1.6.0.16/jre/lib/i386/libzip.so\n0xb718a000  41K   /lib/tls/i686/cmov/libnss_files-2.9.so\n0xb7196000  37K   /lib/tls/i686/cmov/libnss_nis-2.9.so\n0xb71b3000  85K   /lib/tls/i686/cmov/libnsl-2.9.so\n0xb71ce000  29K   /lib/tls/i686/cmov/libnss_compat-2.9.so\n0xb71d7000  37K   /usr/lib/jvm/java-6-sun-1.6.0.16/jre/lib/i386/native_threads/libhpi.so\n0xb71de000  184K  /usr/lib/jvm/java-6-sun-1.6.0.16/jre/lib/i386/libjava.so\n0xb7203000  29K   /lib/tls/i686/cmov/librt-2.9.so\n0xb725d000  145K  /lib/tls/i686/cmov/libm-2.9.so\n0xb7283000  8965K /usr/lib/jvm/java-6-sun-1.6.0.16/jre/lib/i386/server/libjvm.so\n0xb7dc1000  1408K /lib/tls/i686/cmov/libc-2.9.so\n0xb7f24000  9K    /lib/tls/i686/cmov/libdl-2.9.so\n0xb7f28000  37K   /usr/lib/jvm/java-6-sun-1.6.0.16/jre/lib/i386/jli/libjli.so\n0xb7f32000  113K  /lib/tls/i686/cmov/libpthread-2.9.so\n0xb7f51000  55K   /usr/lib/jvm/java-6-sun-1.6.0.16/jre/lib/i386/libverify.so\n0xb7f60000  114K  /lib/ld-2.9.so\n

                                                                              It's also possible to get a quick summary of the JVM heap status:

                                                                              > jmap -heap 17251\n\nAttaching to process ID 17251, please wait...\nDebugger attached successfully.\nServer compiler detected.\nJVM version is 14.2-b01\n\nusing thread-local object allocation.\nParallel GC with 2 thread(s)\n\nHeap Configuration:\n   MinHeapFreeRatio = 40\n   MaxHeapFreeRatio = 70\n   MaxHeapSize      = 778043392 (742.0MB)\n   NewSize          = 1048576 (1.0MB)\n   MaxNewSize       = 4294901760 (4095.9375MB)\n   OldSize          = 4194304 (4.0MB)\n   NewRatio         = 8\n   SurvivorRatio    = 8\n   PermSize         = 16777216 (16.0MB)\n   MaxPermSize      = 67108864 (64.0MB)\n\nHeap Usage:\nPS Young Generation\nEden Space:\n   capacity = 42401792 (40.4375MB)\n   used     = 14401328 (13.734176635742188MB)\n   free     = 28000464 (26.703323364257812MB)\n   33.96396076845054% used\nFrom Space:\n   capacity = 4718592 (4.5MB)\n   used     = 2340640 (2.232208251953125MB)\n   free     = 2377952 (2.267791748046875MB)\n   49.60462782118056% used\nTo Space:\n   capacity = 4587520 (4.375MB)\n   used     = 0 (0.0MB)\n   free     = 4587520 (4.375MB)\n   0.0% used\nPS Old Generation\n   capacity = 43188224 (41.1875MB)\n   used     = 27294848 (26.0303955078125MB)\n   free     = 15893376 (15.1571044921875MB)\n   63.19974630121396% used\nPS Perm Generation\n   capacity = 38404096 (36.625MB)\n   used     = 38378640 (36.60072326660156MB)\n   free     = 25456 (0.0242767333984375MB)\n   99.93371540369027% used\n

                                                                              In the result it can be seen that the JVM is allowed to use up to 742MB of memory, and that at the moment the JVM is using 130MB (rough sum of the capacities of each heap section). In case of a persistent memory leak the JVM will end up using whatever is allowed to and each section of the heap will be almost 100% used.

                                                                              To see how the memory is actually being used in a succinct way the following command can be used (on Windows, replace head -25 with more):

                                                                              > jmap -histo:live 17251 | head -25\n\n num     #instances         #bytes  class name\n----------------------------------------------\n   1:         81668       10083280  <constMethodKlass>\n   2:         81668        6539632  <methodKlass>\n   3:         79795        5904728  [C\n   4:        123511        5272448  <symbolKlass>\n   5:          7974        4538688  <constantPoolKlass>\n   6:         98726        3949040  org.hsqldb.DiskNode\n   7:          7974        3612808  <instanceKlassKlass>\n   8:          9676        2517160  [B\n   9:          6235        2465488  <constantPoolCacheKlass>\n  10:         10054        2303368  [I\n  11:         83121        1994904  java.lang.String\n  12:         27794        1754360  [Ljava.lang.Object;\n  13:          9227         868000  [Ljava.util.HashMap$Entry;\n  14:          8492         815232  java.lang.Class\n  15:         10645         710208  [S\n  16:         14420         576800  org.hsqldb.CachedRow\n  17:          1927         574480  <methodDataKlass>\n  18:          8937         571968  org.apache.xerces.dom.ElementNSImpl\n  19:         12898         561776  [[I\n  20:         23122         554928  java.util.HashMap$Entry\n  21:         16910         541120  org.apache.xerces.dom.TextImpl\n  22:          9898         395920  org.apache.xerces.dom.AttrNSImpl\n

                                                                              By the dump we can see most of the memory is used by the GeoServer code itself (first 5 items) followed by the HSQL cache holding a few rows of the EPSG database. In case of a memory leak a few object types will hold the vast majority of the live heap. Mind, to look for a leak the dump should be gathered with the server almost idle. If, for example, the server is under a load of GetMap requests the main memory usage will be the byte[] holding the images while they are rendered, but that is not a leak, it's legitimate and temporary usage.

                                                                              In case of memory leaks a developer will probably ask for a full heap dump to analyze with a high end profiling tool. Such dump can be generated with the following command:

                                                                              > jmap -dump:live,file=/tmp/dump.hprof 17251\nDumping heap to /tmp/dump.hprof ...\nHeap dump file created\n

                                                                              The dump files are generally as big as the memory used so it's advisable to compress the resulting file before sending it to a developer.

                                                                              "},{"location":"production/troubleshooting/#xstream","title":"XStream","text":"

                                                                              GeoServer and GeoWebCache use XStream to read and write XML for configuration and for their REST APIs. In order to do this securely, it needs a list of Java classes that are safe to convert between objects and XML. If a class not on that list is given to XStream, it will generate the error com.thoughtworks.xstream.security.ForbiddenClassException. The specific class that was a problem should also be included. This may be a result of the lists of allowed classes missing a class, which should be reported as a bug, or it may be caused by an extension/plugin not adding its classes to the list (finally, it could be someone trying to perform a \"Remote Execution\" attack, which is what the allow-list is designed to prevent).

                                                                              This can be worked around by setting the system properties GEOSERVER_XSTREAM_WHITELIST for GeoServer or GEOWEBCACHE_XSTREAM_WHITELIST for GeoWebCache to a semicolon separated list of qualified class names. The class names may include wildcards ? for a single character, * for any number of characters not including the separator ., and ** for any number of characters including separators. For instance, org.example.blah.SomeClass; com.demonstration.*; ca.test.** will allow, the specific class org.example.blah.SomeClass, any class immediately within the package com.demonstration, and any class within the package ca.test or any of its descendant packages.

                                                                              GEOSERVER_XSTREAM_WHITELIST and GEOWEBCACHE_XSTREAM_WHITELIST should only be used as a workaround until GeoServer, GWC, or the extension causing the problem has been updated, so please report to the users list the missing classes as soon as possible.

                                                                              "},{"location":"rest/","title":"REST","text":"

                                                                              GeoServer provides a RESTful interface through which clients can retrieve information about an instance and make configuration changes. Using the REST interface's simple HTTP calls, clients can configure GeoServer without needing to use the Web administration interface.

                                                                              REST is an acronym for \"REpresentational State Transfer\". REST adopts a fixed set of operations on named resources, where the representation of each resource is the same for retrieving and setting information. In other words, you can retrieve (read) data in an XML format and also send data back to the server in similar XML format in order to set (write) changes to the system.

                                                                              Operations on resources are implemented with the standard primitives of HTTP: GET to read; and PUT, POST, and DELETE to write changes. Each resource is represented as a URL, such as http://GEOSERVER_HOME/rest/workspaces/topp.

                                                                              "},{"location":"rest/#api","title":"API","text":"

                                                                              Warning

                                                                              The API is documented as Swagger 2.0 files. However, these files have been written by hand back in 2017, and have not always been kept up to date with the evolution of the GeoServer configuration object structure. Also, they have not been tested for proper client generation, and will likely not work for that purpose. Take them only as a form of documentation.

                                                                              The following links provide direct access to the GeoServer REST API documentation, including definitions and examples of each endpoint:

                                                                              • /about/manifests
                                                                              • /about/system-status
                                                                              • /datastores
                                                                              • /coverages
                                                                              • /coveragestores
                                                                              • /featuretypes
                                                                              • /fonts
                                                                              • /layergroups
                                                                              • /layers
                                                                              • /logging
                                                                              • /monitoring
                                                                              • /namespaces
                                                                              • /services/wms|wfs|wcs|wmts/settings
                                                                              • /reload
                                                                              • /resource
                                                                              • /security
                                                                              • /settings
                                                                              • /structuredcoverages
                                                                              • /styles
                                                                              • /templates
                                                                              • /transforms
                                                                              • /wmslayers
                                                                              • /wmsstores
                                                                              • /wmtslayers
                                                                              • /wmtsstores
                                                                              • /workspaces
                                                                              • /usergroup
                                                                              • /roles
                                                                              • GeoWebCache:
                                                                                • /blobstores
                                                                                • /bounds
                                                                                • /diskquota
                                                                                • /filterupdate
                                                                                • /global
                                                                                • /gridsets
                                                                                • /index
                                                                                • /layers
                                                                                • /masstruncate
                                                                                • /statistics
                                                                                • /reload
                                                                                • /seed
                                                                              • Importer extension:
                                                                                • /imports
                                                                                • /imports (tasks)
                                                                                • /imports (transforms)
                                                                                • /imports (data)
                                                                              • Monitor extension:
                                                                                • /monitor
                                                                              • XSLT extension:
                                                                                • /services/wfs/transforms

                                                                              Note

                                                                              You can also view the original REST configuration API reference section.

                                                                              "},{"location":"rest/#examples","title":"Examples","text":"

                                                                              This section contains a number of examples which illustrate some of the most common uses of the REST API. They are grouped by endpoint.

                                                                              "},{"location":"rest/about/","title":"About","text":"

                                                                              The REST API allows you to set and retrieve information about the server itself.

                                                                              Note

                                                                              Read the API reference for /about/manifests <manifests.yaml>__.

                                                                              "},{"location":"rest/about/#retrieving-component-versions","title":"Retrieving component versions","text":"

                                                                              Retrieve the versions of the main components: GeoServer, GeoTools, and GeoWebCache

                                                                              Request

                                                                              curl

                                                                              curl -v -u admin:geoserver -XGET -H \"Accept: text/xml\" http://localhost:8080/geoserver/rest/about/version.xml

                                                                              Response

                                                                              <about>\n <resource name=\"GeoServer\">\n  <Build-Timestamp>11-Dec-2012 17:55</Build-Timestamp>\n  <Git-Revision>e66f8da85521f73d0fd00b71331069a5f49f7865</Git-Revision>\n  <Version>2.3-SNAPSHOT</Version>\n </resource>\n <resource name=\"GeoTools\">\n  <Build-Timestamp>04-Dec-2012 02:31</Build-Timestamp>\n  <Git-Revision>380a2b8545ee9221f1f2d38a4f10ef77a23bccae</Git-Revision>\n  <Version>9-SNAPSHOT</Version>\n </resource>\n <resource name=\"GeoWebCache\">\n  <Git-Revision>2a534f91f6b99e5120a9eaa5db62df771dd01688</Git-Revision>\n  <Version>1.3-SNAPSHOT</Version>\n </resource>\n</about>\n
                                                                              "},{"location":"rest/about/#retrieving-manifests","title":"Retrieving manifests","text":"

                                                                              Retrieve the full manifest and subsets of the manifest as known to the ClassLoader

                                                                              Request

                                                                              curl

                                                                              curl -v -u admin:geoserver -XGET -H \"Accept: text/xml\" http://localhost:8080/geoserver/rest/about/manifest.xml

                                                                              Note

                                                                              The result will be a very long list of manifest information. While this can be useful, it is often desirable to filter this list.

                                                                              Retrieve manifests, filtered by resource name

                                                                              Note

                                                                              This example will retrieve only resources where the name attribute matches gwc-.*.

                                                                              Request

                                                                              curl

                                                                              curl -v -u admin:geoserver -XGET -H \"Accept: text/xml\" http://localhost:8080/geoserver/rest/about/manifest.xml?manifest=gwc-.*

                                                                              Response

                                                                              <about>\n  <resource name=\"gwc-2.3.0\">\n    ...\n  </resource>\n  <resource name=\"gwc-core-1.4.0\">\n    ...\n  </resource>\n  <resource name=\"gwc-diskquota-core-1.4.0\">\n    ...\n  </resource>\n  <resource name=\"gwc-diskquota-jdbc-1.4.0\">\n    ...\n  </resource>\n  <resource name=\"gwc-georss-1.4.0\">\n    ...\n  </resource>\n  <resource name=\"gwc-gmaps-1.4.0\">\n    ...\n  </resource>\n  <resource name=\"gwc-kml-1.4.0\">\n    ...\n  </resource>\n  <resource name=\"gwc-rest-1.4.0\">\n    ...\n  </resource>\n  <resource name=\"gwc-tms-1.4.0\">\n    ...\n  </resource>\n  <resource name=\"gwc-ve-1.4.0\">\n    ...\n  </resource>\n  <resource name=\"gwc-wms-1.4.0\">\n    ...\n  </resource>\n  <resource name=\"gwc-wmts-1.4.0\">\n    ...\n  </resource>\n</about>\n

                                                                              Retrieve manifests, filtered by resource property

                                                                              Note

                                                                              This example will retrieve only resources with a property equal to GeoServerModule.

                                                                              Request

                                                                              curl

                                                                              curl -u admin:geoserver -XGET -H \"Accept: text/xml\" http://localhost:8080/geoserver/rest/about/manifest.xml?key=GeoServerModule

                                                                              Response

                                                                              <about>\n <resource name=\"control-flow-2.3.0\">\n  <GeoServerModule>extension</GeoServerModule>\n  ...\n </resource>\n ...\n <resource name=\"wms-2.3.0\">\n  <GeoServerModule>core</GeoServerModule>\n  ...\n </resource>\n</about>\n

                                                                              Retrieve manifests, filtered by both resource name and property

                                                                              Note

                                                                              This example will retrieve only resources where a property with named GeoServerModule has a value equal to extension.

                                                                              Request

                                                                              curl

                                                                              curl -u admin:geoserver -XGET -H \"Accept: text/xml\" http://localhost:8080/geoserver/rest/about/manifest.xml?key=GeoServerModule&value=extension

                                                                              "},{"location":"rest/about/#system-status","title":"System Status","text":"

                                                                              It is possible to request the available system information (monitoring data) through the GeoServer REST API. The supported formats are XML, JSON and HTML.

                                                                              The available REST endpoints are: :

                                                                              /geoserver/rest/about/system-status\n\n/geoserver/rest/about/system-status.json\n\n/geoserver/rest/about/system-status.xml\n\n/geoserver/rest/about/system-status.html\n

                                                                              The HTML representation of the system data is equal to the System status tab representation:

                                                                              System status

                                                                              The XML and JSON representations are quite similar. For each system information metric, the following attributes will be available:

                                                                              Name Description name name of the metric available TRUE if the system information value is available description description of this system information unit unit of the system information, can be empty category category of this system information priority this value can be used to render the metrics in a predefined order identifier identifies the resource associated with the metric, e.g. file partition name

                                                                              Example of XML representation:

                                                                              <metrics>\n  <metric>\n   <value>99614720</value>\n   <available>true</available>\n   <description>Partition [/dev/nvme0n1p2] total space</description>\n   <name>PARTITION_TOTAL</name>\n   <unit>bytes</unit>\n   <category>FILE_SYSTEM</category>\n   <identifier>/dev/nvme0n1p2</identifier>\n   <priority>507</priority>\n </metric>\n (...)\n

                                                                              Example of JSON representation:

                                                                              {\n    \"metrics\": {\n        \"metric\": [\n            {\n              \"available\": true,\n              \"category\": \"FILE_SYSTEM\",\n              \"description\": \"Partition [/dev/nvme0n1p2] total space\",\n              \"identifier\": \"/dev/nvme0n1p2\",\n              \"name\": \"PARTITION_TOTAL\",\n              \"priority\": 507,\n              \"unit\": \"bytes\",\n              \"value\": 99614720\n            },\n
                                                                              "},{"location":"rest/appschema/","title":"App Schema","text":""},{"location":"rest/appschema/#appschema_upload_create","title":"Uploading an app-schema mapping file","text":"

                                                                              Create a new app-schema store and update the feature type mappings of an existing app-schema store by uploading a mapping configuration file

                                                                              The following request uploads an app-schema mapping file called LandCoverVector.xml to a data store called LandCoverVector. If no LandCoverVector data store existed in workspace lcv prior to the request, it would be created.

                                                                              Request

                                                                              curl

                                                                              curl -v -X PUT -d @LandCoverVector.xml -H \"Content-Type: text/xml\" -u admin:geoserver http://localhost:8080/geoserver/rest/workspaces/lcv/datastores/LandCoverVector/file.appschema?configure=all

                                                                              Response

                                                                              201 Created\n
                                                                              "},{"location":"rest/appschema/#listing-app-schema-store-details","title":"Listing app-schema store details","text":"

                                                                              Request

                                                                              curl

                                                                              curl -v -u admin:geoserver -X GET http://localhost:8080/geoserver/rest/workspaces/lcv/datastores/LandCoverVector.xml

                                                                              Response

                                                                              <dataStore>\n  <name>LandCoverVector</name>\n  <type>Application Schema DataAccess</type>\n  <enabled>true</enabled>\n  <workspace>\n    <name>lcv</name>\n    <atom:link xmlns:atom=\"http://www.w3.org/2005/Atom\" rel=\"alternate\" href=\"http://localhost:8080/geoserver/rest/workspaces/lcv.xml\" type=\"application/xml\"/>\n  </workspace>\n  <connectionParameters>\n    <entry key=\"dbtype\">app-schema</entry>\n    <entry key=\"namespace\">http://inspire.ec.europa.eu/schemas/lcv/3.0</entry>\n    <entry key=\"url\">file:/path/to/data_dir/data/lcv/LandCoverVector/LandCoverVector.appschema</entry>\n  </connectionParameters>\n  <__default>false</__default>\n  <featureTypes>\n    <atom:link xmlns:atom=\"http://www.w3.org/2005/Atom\" rel=\"alternate\" href=\"http://localhost:8080/geoserver/rest/workspaces/lcv/datastores/LandCoverVector/featuretypes.xml\" type=\"application/xml\"/>\n  </featureTypes>\n</dataStore>\n
                                                                              "},{"location":"rest/appschema/#uploading-a-new-app-schema-mapping-configuration-file","title":"Uploading a new app-schema mapping configuration file","text":"

                                                                              Upload a new mapping configuration, stored in the mapping file \"`LandCoverVector_alternative.xml\", to the \"LandCoverVector\" data store

                                                                              Request

                                                                              curl

                                                                              curl -v -X PUT -d @LandCoverVector_alternative.xml -H \"Content-Type: text/xml\" -u admin:geoserver http://localhost:8080/geoserver/rest/workspaces/lcv/datastores/LandCoverVector/file.appschema?configure=none

                                                                              Response

                                                                              200 OK\n

                                                                              Note

                                                                              This time the configure parameter is set to none, because we don't want to configure again the feature types, just replace their mapping configuration.

                                                                              Note

                                                                              If the set of feature types mapped in the new configuration file differs from the set of feature types mapped in the old one (either some are missing, or some are new, or both), the best way to proceed is to delete the data store and create it anew issuing another PUT request, as shown above.

                                                                              "},{"location":"rest/appschema/#uploading-multiple-app-schema-mapping-files","title":"Uploading multiple app-schema mapping files","text":"

                                                                              Create a new app-schema data store based on a complex mapping configuration split into multiple files, and show how to upload application schemas (i.e. XSD files) along with the mapping configuration.

                                                                              Note

                                                                              In the previous example, we have seen how to create a new app-schema data store by uploading a mapping configuration stored in a single file; this time, things are more complicated, since the mappings have been spread over two configuration files: the main configuration file is called geosciml.appschema and contains the mappings for three feature types: GeologicUnit, MappedFeature and GeologicEvent; the second file is called cgi_termvalue.xml and contains the mappings for a single non-feature type, CGI_TermValue.

                                                                              Note

                                                                              As explained in the REST API reference documentation for data stores, when the mapping configuration is spread over multiple files, the extension of the main configuration file must be .appschema.

                                                                              The main configuration file includes the second file:

                                                                              ...\n<includedTypes>\n  <Include>cgi_termvalue.xml</Include>\n</includedTypes>\n...\n

                                                                              We also want to upload to GeoServer the schemas required to define the mapping, instead of having GeoServer retrieve them from the internet (which is especially useful in case our server doesn't have access to the web). The main schema is called geosciml.xsd and is referred to in geosciml.appschema as such:

                                                                              ...\n<targetTypes>\n  <FeatureType>\n    <schemaUri>geosciml.xsd</schemaUri>\n  </FeatureType>\n</targetTypes>\n...\n

                                                                              In this case, the main schema depends on several other schemas:

                                                                              <include schemaLocation=\"geologicUnit.xsd\"/>\n<include schemaLocation=\"borehole.xsd\"/>\n<include schemaLocation=\"vocabulary.xsd\"/>\n<include schemaLocation=\"geologicRelation.xsd\"/>\n<include schemaLocation=\"fossil.xsd\"/>\n<include schemaLocation=\"value.xsd\"/>\n<include schemaLocation=\"geologicFeature.xsd\"/>\n<include schemaLocation=\"geologicAge.xsd\"/>\n<include schemaLocation=\"earthMaterial.xsd\"/>\n<include schemaLocation=\"collection.xsd\"/>\n<include schemaLocation=\"geologicStructure.xsd\"/>\n

                                                                              They don't need to be listed in the targetTypes section of the mapping configuration, but they must be included in the ZIP archive that will be uploaded.

                                                                              Note

                                                                              The GeoSciML schemas listed above, as pretty much any application schema out there, reference the base GML schemas (notably, http://schemas.opengis.net/gml/3.1.1/base/gml.xsd) and a few other remotely hosted schemas (e.g. http://www.geosciml.org/cgiutilities/1.0/xsd/cgiUtilities.xsd). For the example to work in a completely offline environment, one would have to either replace all remote references with local ones, or pre-populate the app-schema cache with a copy of the remote schemas. GeoServer's user manual contains more information on the app-schema cache.

                                                                              To summarize, we'll upload to GeoServer a ZIP archive with the following contents:

                                                                              geosciml.appschema      # main mapping file\ncgi_termvalue.xml       # secondary mapping file\ngeosciml.xsd            # main schema\nborehole.xsd\ncollection.xsd\nearthMaterial.xsd\nfossil.xsd\ngeologicAge.xsd\ngeologicFeature.xsd\ngeologicRelation.xsd\ngeologicStructure.xsd\ngeologicUnit.xsd\nvalue.xsd\nvocabulary.xsd\n

                                                                              Request

                                                                              curl

                                                                              curl -X PUT --data-binary @geosciml.zip -H \"Content-Type: application/zip\" -u admin:geoserver http://localhost:8080/geoserver/rest/workspaces/gsml/datastores/geosciml/file.appschema?configure=all

                                                                              Response

                                                                              200 OK\n

                                                                              A new geosciml data store will be created with three feature types in it:

                                                                              <featureTypes>\n  <featureType>\n    <name>MappedFeature</name>\n    <atom:link xmlns:atom=\"http://www.w3.org/2005/Atom\" rel=\"alternate\" href=\"http://localhost:8080/geoserver/rest/workspaces/gsml/datastores/geosciml/featuretypes/MappedFeature.xml\" type=\"application/xml\"/>\n  </featureType>\n  <featureType>\n    <name>GeologicEvent</name>\n    <atom:link xmlns:atom=\"http://www.w3.org/2005/Atom\" rel=\"alternate\" href=\"http://localhost:8080/geoserver/rest/workspaces/gsml/datastores/geosciml/featuretypes/GeologicEvent.xml\" type=\"application/xml\"/>\n  </featureType>\n  <featureType>\n    <name>GeologicUnit</name>\n    <atom:link xmlns:atom=\"http://www.w3.org/2005/Atom\" rel=\"alternate\" href=\"http://localhost:8080/geoserver/rest/workspaces/gsml/datastores/geosciml/featuretypes/GeologicUnit.xml\" type=\"application/xml\"/>\n  </featureType>\n</featureTypes>\n
                                                                              "},{"location":"rest/appschema/#cleaning-schemas-on-internal-mongodb-stores","title":"Cleaning schemas on internal MongoDB stores","text":"

                                                                              Clean persisted schema on an internal MongoDB Store, allowing it to generate a new one from data.

                                                                              Request template

                                                                              curl

                                                                              curl -v -X POST -u admin:geoserver http://localhost:8080/geoserver/rest/workspaces/{WORKSPACE}/appschemastores/{APP_SCHEMA_STORE_NAME}/datastores/{INTERNAL_STORE_ID}/cleanSchemas

                                                                              Request

                                                                              curl

                                                                              curl -v -X POST -u admin:geoserver http://localhost:8080/geoserver/rest/workspaces/st/appschemastores/AppSchemaStoreName/datastores/store_id/cleanSchemas

                                                                              Response

                                                                              200 OK\n

                                                                              Clean persisted schema on all internal MongoDB Stores, allowing it to generate them from data.

                                                                              Request template

                                                                              curl

                                                                              curl -v -X POST -u admin:geoserver http://localhost:8080/geoserver/rest/workspaces/{WORKSPACE}/appschemastores/{APP_SCHEMA_STORE_NAME}/cleanSchemas

                                                                              Request

                                                                              curl

                                                                              curl -v -X POST -u admin:geoserver http://localhost:8080/geoserver/rest/workspaces/st/appschemastores/AppSchemaStoreName/cleanSchemas

                                                                              Response

                                                                              200 OK\n

                                                                              Rebuild persisted schema on internal MongoDB Store, allowing it to generate them from data and query parameters.

                                                                              Request template

                                                                              curl

                                                                              curl -v -X POST -u admin:geoserver http://localhost:8080/geoserver/rest/workspaces/{WORKSPACE}/appschemastores/{APP_SCHEMA_STORE_NAME}/datastores/{INTERNAL_STORE_ID}/rebuildMongoSchemas?ids={ID_1},{ID_2}&max={MAX_OBJECTS}

                                                                              • ids: Comma separated MongoDB JSON objects ids to query for generating schemas. Not required if the 'max' is setted.
                                                                              • max: Max number of MongoDB JSON objects to get for generating schemas. Not required if the 'ids' is setted.

                                                                              Request

                                                                              curl

                                                                              curl -v -X POST -u admin:geoserver http://localhost:8080/geoserver/rest/workspaces/st/appschemastores/AppSchemaStoreName/datastores/store_id/rebuildMongoSchemas?ids=58e5889ce4b02461ad5af081,58e5889ce4b02461ad5af080&max=5

                                                                              Response

                                                                              200 OK\n

                                                                              Rebuild persisted schema on all internal MongoDB Stores, allowing it to generate them from data and query parameters.

                                                                              Request template

                                                                              curl

                                                                              curl -v -X POST -u admin:geoserver http://localhost:8080/geoserver/rest/workspaces/{WORKSPACE}/appschemastores/{APP_SCHEMA_STORE_NAME}/rebuildMongoSchemas?ids={ID_1},{ID_2}&max={MAX_OBJECTS}

                                                                              • ids: Comma separated MongoDB JSON objects ids to query for generating schemas. Not required if the 'max' is setted.
                                                                              • max: Max number of MongoDB JSON objects to get for generating schemas. Not required if the 'ids' is setted.

                                                                              Request

                                                                              curl

                                                                              curl -v -X POST -u admin:geoserver http://localhost:8080/geoserver/rest/workspaces/st/appschemastores/AppSchemaStoreName/rebuildMongoSchemas?ids=58e5889ce4b02461ad5af081,58e5889ce4b02461ad5af080&max=5

                                                                              Response

                                                                              200 OK\n

                                                                              Note

                                                                              This endpoins are only available when App-Schema and MongoDB modules are installed on Geoserver, and involved app-schema store have internal MongoDB stores in mappings definition.

                                                                              "},{"location":"rest/fonts/","title":"Fonts","text":"

                                                                              The REST API allows you to list---but not modify---fonts available in GeoServer. It can be useful to use this operation to verify if a font used in a style file is available before uploading it.

                                                                              Note

                                                                              Read the API reference for /fonts.

                                                                              "},{"location":"rest/fonts/#getting-a-list-of-all-fonts","title":"Getting a list of all fonts","text":"

                                                                              List all fonts on the server, in JSON format:

                                                                              Request

                                                                              curl

                                                                              curl -u admin:geoserver -XGET http://localhost:8080/geoserver/rest/fonts.json

                                                                              Response

                                                                              {\"fonts\":[\"Calibri Light Italic\",\"Microsoft PhagsPa Bold\",\"Lucida Sans Typewriter Oblique\",\"ChaparralPro-Regular\",\"Californian FB Italic\"]}\n

                                                                              List all fonts on the server, in XML format:

                                                                              Request

                                                                              curl

                                                                              curl -u admin:geoserver -XGET http://localhost:8080/geoserver/rest/fonts.xml

                                                                              Response

                                                                              <root>\n  <fonts>\n    <entry>Calibri Light Italic</entry>\n    <entry>Microsoft PhagsPa Bold</entry>\n    <entry>Lucida Sans Typewriter Oblique</entry>\n    <entry>ChaparralPro-Regular</entry>\n    <entry>Californian FB Italic</entry>\n  </fonts>\n</root>\n
                                                                              "},{"location":"rest/imagemosaic/","title":"Uploading a new image mosaic","text":"

                                                                              Upload a ZIP file containing a mosaic definition and granule(s)

                                                                              Request

                                                                              curl

                                                                              curl -u admin:geoserver -XPUT -H \"Content-type:application/zip\" --data-binary @polyphemus.zip http://localhost:8080/geoserver/rest/workspaces/topp/coveragestores/polyphemus/file.imagemosaic

                                                                              Response

                                                                              200 OK\n
                                                                              "},{"location":"rest/imagemosaic/#updating-an-image-mosaic-contents","title":"Updating an image mosaic contents","text":"

                                                                              Harvest (or reharvest) a single file into the mosaic and update the mosaic index

                                                                              Request

                                                                              curl

                                                                              curl -v -u admin:geoserver -XPOST -H \"Content-type: text/plain\" -d \"file:///path/to/the/file/polyphemus_20130302.nc\" \"http://localhost:8080/geoserver/rest/workspaces/topp/coveragestores/poly-incremental/external.imagemosaic\"

                                                                              Response

                                                                              201 Created\n

                                                                              Harvest (or reharvest) a whole directory into the mosaic and update the mosaic index

                                                                              Request

                                                                              curl

                                                                              curl -v -u admin:geoserver -XPOST -H \"Content-type: text/plain\" -d \"file:///path/to/the/mosaic/folder\" \"http://localhost:8080/geoserver/rest/workspaces/topp/coveragestores/poly-incremental/external.imagemosaic\"

                                                                              Response

                                                                              201 Created\n
                                                                              "},{"location":"rest/imagemosaic/#listing-image-mosaic-details","title":"Listing image mosaic details","text":"

                                                                              Retrieve the image mosaic index structure

                                                                              Request

                                                                              curl

                                                                              curl -v -u admin:geoserver -XGET \"http://localhost:8080/geoserver/rest/workspaces/topp/coveragestores/polyphemus-v1/coverages/NO2/index.xml\"

                                                                              Response

                                                                              <Schema>\n<attributes>\n <Attribute>\n   <name>the_geom</name>\n   <minOccurs>0</minOccurs>\n   <maxOccurs>1</maxOccurs>\n   <nillable>true</nillable>\n   <binding>org.locationtech.jts.geom.Polygon</binding>\n </Attribute>\n <Attribute>\n   <name>location</name>\n   <minOccurs>0</minOccurs>\n   <maxOccurs>1</maxOccurs>\n   <nillable>true</nillable>\n   <binding>java.lang.String</binding>\n </Attribute>\n <Attribute>\n   <name>imageindex</name>\n   <minOccurs>0</minOccurs>\n   <maxOccurs>1</maxOccurs>\n   <nillable>true</nillable>\n   <binding>java.lang.Integer</binding>\n </Attribute>\n <Attribute>\n   <name>time</name>\n   <minOccurs>0</minOccurs>\n   <maxOccurs>1</maxOccurs>\n   <nillable>true</nillable>\n   <binding>java.sql.Timestamp</binding>\n </Attribute>\n <Attribute>\n   <name>elevation</name>\n   <minOccurs>0</minOccurs>\n   <maxOccurs>1</maxOccurs>\n   <nillable>true</nillable>\n   <binding>java.lang.Double</binding>\n </Attribute>\n <Attribute>\n   <name>fileDate</name>\n   <minOccurs>0</minOccurs>\n   <maxOccurs>1</maxOccurs>\n   <nillable>true</nillable>\n   <binding>java.sql.Timestamp</binding>\n </Attribute>\n <Attribute>\n   <name>updated</name>\n   <minOccurs>0</minOccurs>\n   <maxOccurs>1</maxOccurs>\n   <nillable>true</nillable>\n   <binding>java.sql.Timestamp</binding>\n </Attribute>\n</attributes>\n<atom:link xmlns:atom=\"http://www.w3.org/2005/Atom\" rel=\"alternate\" href=\"http://localhost:8080/geoserver/rest/workspaces/topp/coveragestores/polyphemus-v1/coverages/NO2/index/granules.xml\" type=\"application/xml\"/>\n</Schema>\n

                                                                              Retrieve the existing granule information

                                                                              Request

                                                                              curl

                                                                              curl -v -u admin:geoserver -XGET \"http://localhost:8080/geoserver/rest/workspaces/topp/coveragestores/polyphemus-v1/coverages/NO2/index/granules.xml?limit=2\"

                                                                              Response

                                                                              <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<wfs:FeatureCollection xmlns:gf=\"http://www.geoserver.org/rest/granules\" xmlns:ogc=\"http://www.opengis.net/ogc\" xmlns:wfs=\"http://www.opengis.net/wfs\" xmlns:gml=\"http://www.opengis.net/gml\">\n  <gml:boundedBy>\n    <gml:Box srsName=\"http://www.opengis.net/gml/srs/epsg.xml#4326\">\n      <gml:coord>\n        <gml:X>5.0</gml:X>\n        <gml:Y>45.0</gml:Y>\n      </gml:coord>\n      <gml:coord>\n        <gml:X>14.875</gml:X>\n        <gml:Y>50.9375</gml:Y>\n      </gml:coord>\n    </gml:Box>\n  </gml:boundedBy>\n  <gml:featureMember>\n    <gf:NO2 fid=\"NO2.1\">\n      <gf:the_geom>\n        <gml:Polygon>\n          <gml:outerBoundaryIs>\n            <gml:LinearRing>\n              <gml:coordinates>5.0,45.0 5.0,50.9375 14.875,50.9375 14.875,45.0 5.0,45.0</gml:coordinates>\n            </gml:LinearRing>\n          </gml:outerBoundaryIs>\n        </gml:Polygon>\n      </gf:the_geom>\n      <gf:location>polyphemus_20130301.nc</gf:location>\n      <gf:imageindex>336</gf:imageindex>\n      <gf:time>2013-03-01T00:00:00Z</gf:time>\n      <gf:elevation>10.0</gf:elevation>\n      <gf:fileDate>2013-03-01T00:00:00Z</gf:fileDate>\n      <gf:updated>2013-04-11T10:54:31Z</gf:updated>\n    </gf:NO2>\n  </gml:featureMember>\n  <gml:featureMember>\n    <gf:NO2 fid=\"NO2.2\">\n      <gf:the_geom>\n        <gml:Polygon>\n          <gml:outerBoundaryIs>\n            <gml:LinearRing>\n              <gml:coordinates>5.0,45.0 5.0,50.9375 14.875,50.9375 14.875,45.0 5.0,45.0</gml:coordinates>\n            </gml:LinearRing>\n          </gml:outerBoundaryIs>\n        </gml:Polygon>\n      </gf:the_geom>\n      <gf:location>polyphemus_20130301.nc</gf:location>\n      <gf:imageindex>337</gf:imageindex>\n      <gf:time>2013-03-01T00:00:00Z</gf:time>\n      <gf:elevation>35.0</gf:elevation>\n      <gf:fileDate>2013-03-01T00:00:00Z</gf:fileDate>\n      <gf:updated>2013-04-11T10:54:31Z</gf:updated>\n    </gf:NO2>\n  </gml:featureMember>\n</wfs:FeatureCollection>\n
                                                                              "},{"location":"rest/imagemosaic/#removing-image-mosaic-granules","title":"Removing image mosaic granules","text":"

                                                                              Remove all the granules originating from a particular file

                                                                              Request

                                                                              curl

                                                                              curl -v -u admin:geoserver -XDELETE \"http://localhost:8080/geoserver/rest/workspaces/topp/coveragestores/polyphemus-v1/coverages/NO2/index/granules.xml?filter=location='polyphemus_20130301.nc'\"

                                                                              Response

                                                                              200 OK\n
                                                                              "},{"location":"rest/imagemosaic/#uploading-an-empty-mosaic","title":"Uploading an empty mosaic","text":"

                                                                              Upload an archive with the definition of an mosaic, but with no granules

                                                                              Given a empty.zip file containing:

                                                                              • datastore.properties (PostGIS connection parameters)
                                                                              • indexer.xml (Mosaic indexer; note the CanBeEmpty=true parameter)
                                                                              • polyphemus-test.xml (Auxiliary file used by the NetCDF reader to parse schemas and tables)

                                                                              Warning

                                                                              Make sure to update the datastore.properties file with your connection parameters and refresh the ZIP before uploading it.

                                                                              Request

                                                                              curl

                                                                              curl -u admin:geoserver -XPUT -H \"Content-type:application/zip\" --data-binary @empty.zip http://localhost:8080/geoserver/rest/workspaces/topp/coveragestores/empty/file.imagemosaic?configure=none

                                                                              Note

                                                                              The configure=none parameter allows for future configuration after harvesting.

                                                                              Response

                                                                              200 OK\n

                                                                              Configure a coverage on the mosaic

                                                                              Given a coverageconfig.xml:

                                                                              <coverage>\n  <nativeCoverageName>NO2</nativeCoverageName>\n  <name>NO2</name>\n</coverage>\n

                                                                              Request

                                                                              curl

                                                                              curl -v -u admin:geoserver -XPOST -H \"Content-type: text/xml\" -d @\"/path/to/coverageconfig.xml\" \"http://localhost:8080/geoserver/rest/workspaces/topp/coveragestores/empty/coverages\"

                                                                              Note

                                                                              When specifying only the coverage name, the coverage will be automatically configured.

                                                                              Response

                                                                              201 Created\n
                                                                              "},{"location":"rest/layergroups/","title":"Layer groups","text":"

                                                                              The REST API allows you to create and modify layer groups in GeoServer.

                                                                              Note

                                                                              The examples below specify global layer groups, but the examples will work in a workspace-specific construction as well.

                                                                              Note

                                                                              Read the API reference for /layergroups.

                                                                              "},{"location":"rest/layergroups/#creating-a-layer-group","title":"Creating a layer group","text":"

                                                                              Create a new layer group based on already-published layers

                                                                              Given the following content saved as nycLayerGroup.xml:

                                                                              <layerGroup>\n  <name>nyc</name>\n  <layers>\n    <layer>roads</layer>\n    <layer>parks</layer>\n    <layer>buildings</layer>\n  </layers>\n  <styles>\n    <style>roads_style</style>\n    <style>polygon</style>\n    <style>polygon</style>\n  </styles>\n</layerGroup>\n

                                                                              Request

                                                                              curl

                                                                              curl -v -u admin:geoserver -XPOST -d @nycLayerGroup.xml -H \"Content-type: text/xml\" http://localhost:8080/geoserver/rest/layergroups

                                                                              Response

                                                                              201 Created\n

                                                                              Note

                                                                              This layer group can be viewed with a WMS GetMap request:

                                                                              http://localhost:8080/geoserver/wms/reflect?layers=nyc\n
                                                                              "},{"location":"rest/layers/","title":"Layers","text":"

                                                                              The REST API allows you to list, create, upload, update, and delete layers in GeoServer.

                                                                              Note

                                                                              Read the API reference for /layers.

                                                                              "},{"location":"rest/layers/#listing-all-layers","title":"Listing all layers","text":"

                                                                              List all layers on the server, in JSON format:

                                                                              Request

                                                                              curl

                                                                              curl -u admin:geoserver -XGET http://localhost:8080/geoserver/rest/layers.json

                                                                              Response

                                                                              {\n  \"layers\": {\n     \"layer\": [\n         {\n             \"name\": \"giant_polygon\",\n             \"href\": \"http://localhost:8080/geoserver/rest/layers/giant_polygon.json\"\n         },\n         {\n             \"name\": \"poi\",\n             \"href\": \"http://localhost:8080/geoserver/rest/layers/poi.json\"\n         },\n         ...\n      ]\n   }\n}\n

                                                                              List all layers on the server, in XML format:

                                                                              Request

                                                                              curl

                                                                              curl -u admin:geoserver -XGET http://localhost:8080/geoserver/rest/layers.xml

                                                                              Response

                                                                              <layers>\n  <layer>\n    <name>giant_polygon</name>\n    <atom:link xmlns:atom=\"http://www.w3.org/2005/Atom\" rel=\"alternate\" href=\"http://localhost:8080/geoserver/rest/layers/giant_polygon.xml\" type=\"application/xml\"/>\n  </layer>\n  <layer>\n    <name>poi</name>\n    <atom:link xmlns:atom=\"http://www.w3.org/2005/Atom\" rel=\"alternate\" href=\"http://localhost:8080/geoserver/rest/layers/poi.xml\" type=\"application/xml\"/>\n  </layer>\n  ...\n</layers>\n
                                                                              "},{"location":"rest/security/","title":"Security","text":"

                                                                              The REST API allows you to adjust GeoServer security settings.

                                                                              Note

                                                                              Read the API reference for /security.

                                                                              "},{"location":"rest/security/#listing-the-keystore-password","title":"Listing the keystore password","text":"

                                                                              Retrieve the keystore password for the \"root\" account

                                                                              Request

                                                                              curl

                                                                              curl -v -u admin:geoserver -XGET http://localhost:8080/geoserver/rest/security/masterpw.xml

                                                                              "},{"location":"rest/security/#changing-the-keystore-password","title":"Changing the keystore password","text":"

                                                                              Change to a new keystore password

                                                                              Note

                                                                              Requires knowledge of the current keystore password.

                                                                              Given a changes.xml file:

                                                                              <masterPassword>\n   <oldMasterPassword>-\"}3a^Kh</oldMasterPassword>\n   <newMasterPassword>geoserver1</newMasterPassword>\n</masterPassword>\n

                                                                              Request

                                                                              curl

                                                                              curl -v -u admin:geoserver -XPUT -H \"Content-type: text/xml\" -d @change.xml http://localhost:8080/geoserver/rest/security/masterpw.xml

                                                                              Response

                                                                              200 OK\n
                                                                              "},{"location":"rest/security/#listing-the-catalog-mode","title":"Listing the catalog mode","text":"

                                                                              Fetch the current catalog mode

                                                                              Request

                                                                              curl

                                                                              curl -v -u admin:geoserver -XGET http://localhost:8080/geoserver/rest/security/acl/catalog.xml

                                                                              Response

                                                                              <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<catalog>\n    <mode>HIDE</mode>\n</catalog>\n
                                                                              "},{"location":"rest/security/#changing-the-catalog-mode","title":"Changing the catalog mode","text":"

                                                                              Set a new catalog mode

                                                                              Given a newMode.xml file:

                                                                              <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<catalog>\n    <mode>MIXED</mode>\n</catalog>\n

                                                                              Request

                                                                              curl

                                                                              curl -v -u admin:geoserver -XPUT -H \"Content-type: text/xml\" -d @newMode.xml http://localhost:8080/geoserver/rest/security/acl/catalog.xml

                                                                              "},{"location":"rest/security/#listing-access-control-rules","title":"Listing access control rules","text":"

                                                                              Retrieve current list of access control rules

                                                                              Request

                                                                              curl

                                                                              curl -v -u admin:geoserver -XGET http://localhost:8080/geoserver/rest/security/acl/layers.xml

                                                                              Response

                                                                              <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<rules />\n

                                                                              Note

                                                                              The above response shows no rules specified.

                                                                              "},{"location":"rest/security/#changing-access-control-rules","title":"Changing access control rules","text":"

                                                                              Set a new list of access control rules

                                                                              Given a rules.xml file:

                                                                              <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<rules>\n   <rule resource=\"topp.*.r\">ROLE_AUTHORIZED</rule>\n   <rule resource=\"topp.mylayer.w\">ROLE_1,ROLE_2</rule>      \n</rules>\n

                                                                              Request

                                                                              curl

                                                                              curl -v -u admin:geoserver -XPOST -H \"Content-type: text/xml\" -d @rules.xml http://localhost:8080/geoserver/rest/security/acl/layers.xml

                                                                              Response

                                                                              201 Created\n
                                                                              "},{"location":"rest/security/#deleting-access-control-rules","title":"Deleting access control rules","text":"

                                                                              Delete individual access control rule

                                                                              Request

                                                                              curl

                                                                              curl -v -u admin:geoserver -XDELETE http://localhost:8080/geoserver/rest/security/acl/layers/topp.*.r

                                                                              Response

                                                                              200 OK\n
                                                                              "},{"location":"rest/stores/","title":"Stores","text":""},{"location":"rest/stores/#uploading-a-shapefile","title":"Uploading a shapefile","text":"

                                                                              Create a new store \"roads\" by uploading a shapefile \"roads.zip\"

                                                                              Request

                                                                              curl

                                                                              curl -v -u admin:geoserver -XPUT -H \"Content-type: application/zip\" --data-binary @roads.zip http://localhost:8080/geoserver/rest/workspaces/acme/datastores/roads/file.shp

                                                                              Response

                                                                              201 Created\n
                                                                              "},{"location":"rest/stores/#listing-store-details","title":"Listing store details","text":"

                                                                              Retrieve information about a specific store*

                                                                              Request

                                                                              curl

                                                                              curl -v -u admin:geoserver -XGET http://localhost:8080/geoserver/rest/workspaces/acme/datastores/roads.xml

                                                                              python

                                                                              TBD

                                                                              java

                                                                              TBD

                                                                              Response

                                                                              <dataStore>\n  <name>roads</name>\n  <type>Shapefile</type>\n  <enabled>true</enabled>\n  <workspace>\n    <name>acme</name>\n    <atom:link xmlns:atom=\"http://www.w3.org/2005/Atom\" rel=\"alternate\" \n     href=\"http://localhost:8080/geoserver/rest/workspaces/acme.xml\" type=\"application/xml\"/>\n  </workspace>\n  <connectionParameters>\n    <entry key=\"url\">file:/C:/path/to/data_dir/data/acme/roads/</entry>\n    <entry key=\"namespace\">http://acme</entry>\n  </connectionParameters>\n  <__default>false</__default>\n  <featureTypes>\n    <atom:link xmlns:atom=\"http://www.w3.org/2005/Atom\" rel=\"alternate\" \n     href=\"http://localhost:8080/geoserver/rest/workspaces/acme/datastores/roads/featuretypes.xml\" \n     type=\"application/xml\"/>\n  </featureTypes>\n</dataStore>\n

                                                                              Request

                                                                              Note

                                                                              The XML response only provides details about the store itself, so you can use HTML to see the contents of the store.

                                                                              curl -v -u admin:geoserver -XGET \n  http://localhost:8080/geoserver/rest/workspaces/acme/datastores/roads.html\n
                                                                              "},{"location":"rest/stores/#listing-featuretype-details","title":"Listing featuretype details","text":"

                                                                              Note

                                                                              By default when a shapefile is uploaded, a featuretype is automatically created.

                                                                              Request

                                                                              curl

                                                                              curl -v -u admin:geoserver -XGET http://localhost:8080/geoserver/rest/workspaces/acme/datastores/roads/featuretypes/roads.xml

                                                                              python

                                                                              TBD

                                                                              java

                                                                              TBD

                                                                              Response

                                                                              <featureType>\n  <name>roads</name>\n  <nativeName>roads</nativeName>\n  <namespace>\n    <name>acme</name>\n    <atom:link xmlns:atom=\"http://www.w3.org/2005/Atom\" rel=\"alternate\" \n     href=\"http://localhost:8080/geoserver/rest/namespaces/acme.xml\" type=\"application/xml\"/>\n  </namespace>\n  ...\n</featureType>\n
                                                                              "},{"location":"rest/stores/#adding-an-existing-shapefile","title":"Adding an existing shapefile","text":"

                                                                              Publish a shapefile \"rivers.shp\" that already exists on the server without needing to be uploaded

                                                                              Request

                                                                              curl

                                                                              curl -v -u admin:geoserver -XPUT -H \"Content-type: text/plain\" -d \"file:///data/shapefiles/rivers/rivers.shp\" http://localhost:8080/geoserver/rest/workspaces/acme/datastores/rivers/external.shp

                                                                              Note

                                                                              The external.shp part of the request URI indicates that the file is coming from outside the catalog.

                                                                              Response

                                                                              201 Created\n
                                                                              "},{"location":"rest/stores/#adding-a-directory-of-existing-shapefiles","title":"Adding a directory of existing shapefiles","text":"

                                                                              Create a store containing a directory of shapefiles that already exists on the server without needing to be uploaded

                                                                              Request

                                                                              curl

                                                                              curl -v -u admin:geoserver -XPUT -H \"Content-type: text/plain\" -d \"file:///data/shapefiles/\" \"http://localhost:8080/geoserver/rest/workspaces/acme/datastores/shapefiles/external.shp?configure=all\"

                                                                              Note

                                                                              The configure=all query string parameter sets each shapefile in the directory to be loaded and published.

                                                                              Response

                                                                              201 Created\n
                                                                              "},{"location":"rest/stores/#adding-a-postgis-database-store","title":"Adding a PostGIS database store","text":"

                                                                              Add an existing PostGIS database named \"nyc\" as a new store

                                                                              Note

                                                                              This example assumes that a PostGIS database named nyc is present on the local system and is accessible by the user bob.

                                                                              Given the following content saved as nycDataStore.xml:

                                                                              <dataStore> \n  <name>nyc</name>\n  <connectionParameters>\n    <host>localhost</host>\n    <port>5432</port>\n    <database>nyc</database> \n    <user>bob</user>\n    <passwd>postgres</passwd>\n    <dbtype>postgis</dbtype>\n  </connectionParameters>\n</dataStore> \n

                                                                              Request

                                                                              curl

                                                                              curl -v -u admin:geoserver -XPOST -T nycDataStore.xml -H \"Content-type: text/xml\" http://localhost:8080/geoserver/rest/workspaces/acme/datastores

                                                                              Response

                                                                              201 Created\n
                                                                              "},{"location":"rest/stores/#listing-a-postgis-database-store-details","title":"Listing a PostGIS database store details","text":"

                                                                              Retrieve information about a PostGIS store

                                                                              Request

                                                                              curl

                                                                              curl -v -u admin:geoserver -XGET http://localhost:8080/geoserver/rest/workspaces/acme/datastores/nyc.xml

                                                                              Response

                                                                              <dataStore>\n  <name>nyc</name>\n  <type>PostGIS</type>\n  <enabled>true</enabled>\n  <workspace>\n    <name>acme</name>\n    <atom:link xmlns:atom=\"http://www.w3.org/2005/Atom\" rel=\"alternate\" \n     href=\"http://localhost:8080/geoserver/rest/workspaces/acme.xml\" type=\"application/xml\"/>\n  </workspace>\n  <connectionParameters>\n    <entry key=\"port\">5432</entry>\n    <entry key=\"dbtype\">postgis</entry>\n    <entry key=\"host\">localhost</entry>\n    <entry key=\"user\">bob</entry>\n    <entry key=\"database\">nyc</entry>\n    <entry key=\"namespace\">http://acme</entry>\n  </connectionParameters>\n  <__default>false</__default>\n  <featureTypes>\n    <atom:link xmlns:atom=\"http://www.w3.org/2005/Atom\" rel=\"alternate\" \n     href=\"http://localhost:8080/geoserver/rest/workspaces/acme/datastores/nyc/featuretypes.xml\" \n     type=\"application/xml\"/>\n  </featureTypes>\n</dataStore>\n
                                                                              "},{"location":"rest/stores/#publishing-a-table-from-an-existing-postgis-store","title":"Publishing a table from an existing PostGIS store","text":"

                                                                              Publish a new featuretype from a PostGIS store table \"buildings\"

                                                                              Note

                                                                              This example assumes the table has already been created.

                                                                              Request

                                                                              curl

                                                                              curl -v -u admin:geoserver -XPOST -H \"Content-type: text/xml\" -d \"buildings\" http://localhost:8080/geoserver/rest/workspaces/acme/datastores/nyc/featuretypes

                                                                              Note

                                                                              This layer can viewed with a WMS GetMap request:

                                                                              http://localhost:8080/geoserver/wms/reflect?layers=acme:buildings\n
                                                                              "},{"location":"rest/stores/#creating-a-postgis-table","title":"Creating a PostGIS table","text":"

                                                                              Create a new featuretype in GeoServer and simultaneously create a table in PostGIS

                                                                              Given the following content saved as annotations.xml:

                                                                              <featureType>\n  <name>annotations</name>\n  <nativeName>annotations</nativeName>\n  <title>Annotations</title>\n  <srs>EPSG:4326</srs>\n  <attributes>\n    <attribute>\n      <name>the_geom</name>\n      <binding>org.locationtech.jts.geom.Point</binding>\n    </attribute>\n    <attribute>\n      <name>description</name>\n      <binding>java.lang.String</binding>\n    </attribute>\n    <attribute>\n      <name>timestamp</name>\n      <binding>java.util.Date</binding>\n    </attribute>\n  </attributes>\n</featureType>\n

                                                                              Request

                                                                              curl

                                                                              curl -v -u admin:geoserver -XPOST -T annotations.xml -H \"Content-type: text/xml\" http://localhost:8080/geoserver/rest/workspaces/acme/datastores/nyc/featuretypes

                                                                              Note

                                                                              The NYC store must be a PostGIS store for this to succeed.

                                                                              Response

                                                                              201 Created\n

                                                                              A new and empty table named \"annotations\" in the \"nyc\" database will be created as well.

                                                                              "},{"location":"rest/stores/#adding-an-external-wmts-store","title":"Adding an external WMTS Store","text":"

                                                                              Create a new WMTS store \"Basemap-Nat-Geo-Datastore\"

                                                                              Request

                                                                              curl

                                                                              curl -v -u admin:geoserver -XPOST -H \"Content-type: text/xml\" -d \"basemap-nat-geo-datastoreesri-street-maphttps://services.arcgisonline.com/arcgis/rest/services/NatGeo_World_Map/MapServer/WMTS/1.0.0/WMTSCapabilities.xmlWMTS\" http://localhost:8080/geoserver/rest/workspaces/acme/wmtsstores

                                                                              Response

                                                                              201 Created\n
                                                                              "},{"location":"rest/stores/#adding-an-external-wmts-layer","title":"Adding an external WMTS Layer","text":"

                                                                              Publish a new WMTS Layer \"NatGeo_World_Map\" from the WMTS store \"Basemap-Nat-Geo-Datastore\"

                                                                              Request

                                                                              curl

                                                                              curl -v -u admin:geoserver -XPOST -H \"Content-type: text/xml\" -d \"NatGeo_World_Map\" http://localhost:8080/geoserver/rest/workspaces/acme/wmtsstores/Basemap-Nat-Geo-Datastore/layers

                                                                              Response

                                                                              201 Created\n
                                                                              "},{"location":"rest/styles/","title":"Styles","text":"

                                                                              The REST API allows you to list, create, upload, update, and delete styles in GeoServer.

                                                                              Note

                                                                              Read the API reference for /styles.

                                                                              "},{"location":"rest/styles/#listing-all-styles","title":"Listing all styles","text":"

                                                                              List all styles on the server, in JSON format:

                                                                              Request

                                                                              curl

                                                                              curl -u admin:geoserver -XGET http://localhost:8080/geoserver/rest/styles.json

                                                                              Response

                                                                              {\"styles\":{\"style\":[{\"name\":\"burg\",\"href\":\"http:\\/\\/localhost:8080\\/geoserver\\/rest\\/styles\\/burg.json\"},{\"name\":\"capitals\",\"href\":\"http:\\/\\/localhost:8080\\/geoserver\\/rest\\/styles\\/capitals.json\"},{\"name\":\"dem\",\"href\":\"http:\\/\\/localhost:8080\\/geoserver\\/rest\\/styles\\/dem.json\"},{\"name\":\"generic\",\"href\":\"http:\\/\\/localhost:8080\\/geoserver\\/rest\\/styles\\/generic.json\"},{\"name\":\"giant_polygon\",\"href\":\"http:\\/\\/localhost:8080\\/geoserver\\/rest\\/styles\\/giant_polygon.json\"},{\"name\":\"grass\",\"href\":\"http:\\/\\/localhost:8080\\/geoserver\\/rest\\/styles\\/grass.json\"},{\"name\":\"green\",\"href\":\"http:\\/\\/localhost:8080\\/geoserver\\/rest\\/styles\\/green.json\"},{\"name\":\"line\",\"href\":\"http:\\/\\/localhost:8080\\/geoserver\\/rest\\/styles\\/line.json\"},{\"name\":\"poi\",\"href\":\"http:\\/\\/localhost:8080\\/geoserver\\/rest\\/styles\\/poi.json\"},{\"name\":\"point\",\"href\":\"http:\\/\\/localhost:8080\\/geoserver\\/rest\\/styles\\/point.json\"},{\"name\":\"polygon\",\"href\":\"http:\\/\\/localhost:8080\\/geoserver\\/rest\\/styles\\/polygon.json\"},{\"name\":\"poly_landmarks\",\"href\":\"http:\\/\\/localhost:8080\\/geoserver\\/rest\\/styles\\/poly_landmarks.json\"},{\"name\":\"pophatch\",\"href\":\"http:\\/\\/localhost:8080\\/geoserver\\/rest\\/styles\\/pophatch.json\"},{\"name\":\"population\",\"href\":\"http:\\/\\/localhost:8080\\/geoserver\\/rest\\/styles\\/population.json\"},{\"name\":\"rain\",\"href\":\"http:\\/\\/localhost:8080\\/geoserver\\/rest\\/styles\\/rain.json\"},{\"name\":\"raster\",\"href\":\"http:\\/\\/localhost:8080\\/geoserver\\/rest\\/styles\\/raster.json\"},{\"name\":\"restricted\",\"href\":\"http:\\/\\/localhost:8080\\/geoserver\\/rest\\/styles\\/restricted.json\"},{\"name\":\"simple_roads\",\"href\":\"http:\\/\\/localhost:8080\\/geoserver\\/rest\\/styles\\/simple_roads.json\"},{\"name\":\"simple_streams\",\"href\":\"http:\\/\\/localhost:8080\\/geoserver\\/rest\\/styles\\/simple_streams.json\"},{\"name\":\"tiger_roads\",\"href\":\"http:\\/\\/localhost:8080\\/geoserver\\/rest\\/styles\\/tiger_roads.json\"}]}}\n

                                                                              List all styles in a workspace, in XML format:

                                                                              Request

                                                                              curl

                                                                              curl -u admin:geoserver -XGET http://localhost:8080/geoserver/rest/cite/styles.xml

                                                                              Response

                                                                              <styles>\n  <style>\n    <name>citerain</name>\n    <atom:link xmlns:atom=\"http://www.w3.org/2005/Atom\" rel=\"alternate\" href=\"http://localhost:8080/geoserver/rest/workspaces/cite/styles/citerain.xml\" type=\"application/xml\"/>\n  </style>\n</styles>\n
                                                                              "},{"location":"rest/styles/#retrieve-a-style","title":"Retrieve a style","text":"

                                                                              Download the actual style code for a style:

                                                                              Request

                                                                              curl

                                                                              curl -u admin:geoserver -XGET http://localhost:8080/geoserver/rest/styles/rain.sld

                                                                              Response

                                                                              <StyledLayerDescriptor version=\"1.0.0\" xmlns=\"http://www.opengis.net/sld\" xmlns:ogc=\"http://www.opengis.net/ogc\"\n  xmlns:xlink=\"http://www.w3.org/1999/xlink\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\"\n  xsi:schemaLocation=\"http://www.opengis.net/sld http://schemas.opengis.net/sld/1.0.0/StyledLayerDescriptor.xsd\">\n  <NamedLayer>\n    <Name>rain</Name>\n    <UserStyle>\n      <Name>rain</Name>\n      <Title>Rain distribution</Title>\n      <FeatureTypeStyle>\n        <Rule>\n          <RasterSymbolizer>\n            <Opacity>1.0</Opacity>\n            <ColorMap>\n              <ColorMapEntry color=\"#FF0000\" quantity=\"0\" />\n              <ColorMapEntry color=\"#FFFFFF\" quantity=\"100\"/>\n              <ColorMapEntry color=\"#00FF00\" quantity=\"2000\"/>\n              <ColorMapEntry color=\"#0000FF\" quantity=\"5000\"/>\n            </ColorMap>\n          </RasterSymbolizer>\n        </Rule>\n      </FeatureTypeStyle>\n    </UserStyle>\n  </NamedLayer>\n</StyledLayerDescriptor>\n
                                                                              "},{"location":"rest/styles/#creating-a-style","title":"Creating a style","text":"

                                                                              You can create a new style on the server in two ways. In the first way, the creation is done in two steps: the style entry is created in the catalog, and then the style content is uploaded. The second way can add the style to the server in a single step by uploading a ZIP containing the style content:

                                                                              Create a new style in two steps:

                                                                              Request

                                                                              curl

                                                                              curl -v -u admin:geoserver -XPOST -H \"Content-type: text/xml\" -d \"\" http://localhost:8080/geoserver/rest/styles

                                                                              Response

                                                                              201 Created\n

                                                                              Request

                                                                              curl

                                                                              curl -v -u admin:geoserver -XPUT -H \"Content-type: application/vnd.ogc.sld+xml\" -d @roads.sld http://localhost:8080/geoserver/rest/styles/roads_style

                                                                              Response

                                                                              200 OK\n

                                                                              Create a new style in a single step:

                                                                              Request

                                                                              curl

                                                                              curl -u admin:geoserver -XPOST -H \"Content-type: application/zip\" --data-binary @roads_style.zip http://localhost:8080/geoserver/rest/styles

                                                                              Response

                                                                              201 Created\n

                                                                              Create a new style in a single step using CSS:

                                                                              Request

                                                                              curl

                                                                              curl -u admin:geoserver -XPOST -H \"Content-type: application/vnd.geoserver.geocss+css\" -d '* { stroke: red; }' http://localhost:8080/geoserver/rest/styles

                                                                              Response

                                                                              201 Created\n

                                                                              This example will create a new style on the server and populate it the contents of a local SLD file and related images provided in a SLD package. A SLD package is a zip file containing the SLD style and related image files used in the SLD.

                                                                              The following creates a new style named roads_style.

                                                                              Each code block below contains a single command that may be extended over multiple lines.

                                                                              Request

                                                                              curl

                                                                              curl -u admin:geoserver -XPOST -H \"Content-type: application/zip\" --data-binary @roads_style.zip http://localhost:8080/geoserver/rest/styles

                                                                              Response

                                                                              201 OK\n

                                                                              The SLD itself can be downloaded through a a GET request:

                                                                              curl

                                                                              curl -v -u admin:geoserver -XGET http://localhost:8080/geoserver/rest/styles/roads_style.sld

                                                                              "},{"location":"rest/styles/#changing-an-existing-style","title":"Changing an existing style","text":"

                                                                              Edit/reupload the content of an existing style on the server:

                                                                              Request

                                                                              curl

                                                                              curl -u admin:geoserver -XPUT -H \"Content-type: application/vnd.ogc.sld+xml\" -d @roads.sld http://localhost:8080/geoserver/rest/styles/roads_style

                                                                              Response

                                                                              200 OK\n

                                                                              Edit/reupload the content of an existing style on the server when the style is in a workspace:

                                                                              Request

                                                                              curl

                                                                              curl -u admin:geoserver -XPUT -H \"Content-type: application/vnd.ogc.sld+xml\" -d @roads.sld http://localhost:8080/geoserver/rest/workspaces/cite/styles/roads_style

                                                                              Response

                                                                              200 OK\n

                                                                              Edit/reupload the content of an existing style on the server using a ZIP file containing a shapefile:

                                                                              Request

                                                                              curl

                                                                              curl -u admin:geoserver -XPUT -H \"Content-type: application/zip\" --data-binary @roads_style.zip http://localhost:8080/geoserver/rest/styles/roads_style.zip

                                                                              Response

                                                                              200 OK\n
                                                                              "},{"location":"rest/styles/#deleting-a-style","title":"Deleting a style","text":"

                                                                              Remove a style entry from the server, retaining the orphaned style content:

                                                                              Request

                                                                              curl

                                                                              curl -u admin:geoserver -XDELETE http://localhost:8080/geoserver/rest/styles/zoning

                                                                              Response

                                                                              200 OK\n

                                                                              Remove a style entry from the server, deleting the orphaned style content:

                                                                              Request

                                                                              curl

                                                                              curl -u admin:geoserver -XDELETE http://localhost:8080/geoserver/rest/styles/zoning?purge=true

                                                                              Response

                                                                              200 OK\n
                                                                              "},{"location":"rest/workspaces/","title":"Workspaces","text":"

                                                                              The REST API allows you to create and manage workspaces in GeoServer.

                                                                              Note

                                                                              Read the API reference for /workspaces.

                                                                              "},{"location":"rest/workspaces/#adding-a-new-workspace","title":"Adding a new workspace","text":"

                                                                              Creates a new workspace named \"acme\" with a POST request

                                                                              Request

                                                                              curl

                                                                              curl -v -u admin:geoserver -XPOST -H \"Content-type: text/xml\" -d \"acme\" http://localhost:8080/geoserver/rest/workspaces

                                                                              python

                                                                              TBD

                                                                              java

                                                                              TBD

                                                                              Response

                                                                              201 Created\n

                                                                              Note

                                                                              The Location response header specifies the location (URI) of the newly created workspace.

                                                                              "},{"location":"rest/workspaces/#listing-workspace-details","title":"Listing workspace details","text":"

                                                                              Retrieve information about a specific workspace

                                                                              Request

                                                                              curl

                                                                              curl -v -u admin:geoserver -XGET -H \"Accept: text/xml\" http://localhost:8080/geoserver/rest/workspaces/acme

                                                                              Note

                                                                              The Accept header is optional.

                                                                              python

                                                                              TBD

                                                                              java

                                                                              TBD

                                                                              Response

                                                                              <workspace>\n  <name>acme</name>\n  <dataStores>\n    <atom:link xmlns:atom=\"http://www.w3.org/2005/Atom\" rel=\"alternate\" \n     href=\"http://localhost:8080/geoserver/rest/workspaces/acme/datastores.xml\" \n     type=\"application/xml\"/>\n  </dataStores>\n  <coverageStores>\n    <atom:link xmlns:atom=\"http://www.w3.org/2005/Atom\" rel=\"alternate\" \n     href=\"http://localhost:8080/geoserver/rest/workspaces/acme/coveragestores.xml\" \n     type=\"application/xml\"/>\n  </coverageStores>\n  <wmsStores>\n    <atom:link xmlns:atom=\"http://www.w3.org/2005/Atom\" rel=\"alternate\" \n     href=\"http://localhost:8080/geoserver/rest/workspaces/acme/wmsstores.xml\" \n     type=\"application/xml\"/>\n  </wmsStores>\n</workspace>\n

                                                                              This shows that the workspace can contain \"dataStores\" (for vector data), \"coverageStores\" (for raster data), and \"wmsStores\" (for cascaded WMS servers).

                                                                              "},{"location":"rest/api/","title":"REST configuration API reference","text":"

                                                                              This section describes the GeoServer REST configuration API.

                                                                              Note

                                                                              You may also wish to review the hand-written Open API REST documentation. This documentation is not auto-generated and may not exactly match the latest GeoServer. Please treat this resource as documentation only as this is not suitable for client generation.

                                                                              • API details
                                                                              • Global settings
                                                                              • Workspaces
                                                                              • Namespaces
                                                                              • Data stores
                                                                              • Feature types
                                                                              • Coverage stores
                                                                              • Coverages
                                                                              • Styles
                                                                              • Layers
                                                                              • Logging settings
                                                                              • Layer groups
                                                                              • Fonts
                                                                              • Freemarker templates
                                                                              • OWS Services
                                                                              • Reloading configuration
                                                                              • Resource reset
                                                                              • Manifests
                                                                              • Keystore Password
                                                                              • Self admin
                                                                              • Access Control
                                                                              • Users/Groups and Roles
                                                                              • Resources
                                                                              "},{"location":"rest/api/accesscontrol/","title":"Access Control","text":""},{"location":"rest/api/accesscontrol/#securityaclcatalogformat","title":"/security/acl/catalog.<format>","text":"

                                                                              Fetches the catalog mode and allows to change the catalog mode. The mode must be one of

                                                                              • HIDE
                                                                              • MIXED
                                                                              • CHALLENGE
                                                                              Method Action Status code Formats Default Format GET Fetch the catalog mode 200,403 XML, JSON PUT Set the catalog mode 200,403,404,422 XML, JSON

                                                                              Formats:

                                                                              XML

                                                                              <catalog>\n  <mode>HIDE</mode>\n</catalog>\n

                                                                              JSON

                                                                              {\"mode\":\"HIDE\" }\n
                                                                              "},{"location":"rest/api/accesscontrol/#exceptions","title":"Exceptions","text":"Exception Status code No administrative privileges 403 Malformed request 404 Invalid catalog mode 422"},{"location":"rest/api/accesscontrol/#securityacllayersformat","title":"/security/acl/layers.<format>","text":""},{"location":"rest/api/accesscontrol/#securityaclservicesformat","title":"/security/acl/services.<format>","text":""},{"location":"rest/api/accesscontrol/#securityaclrestformat","title":"/security/acl/rest.<format>","text":"

                                                                              API for administering access control for

                                                                              • Layers
                                                                              • Services
                                                                              • The REST API
                                                                              Method Action Status code Formats Default Format GET Fetch all rules 200,403 XML, JSON POST Add a set of rules 200,403,409 XML, JSON PUT Modify a set of rules 200,403,409 XML, JSON DELETE Delete a specific rule 200,404,409 XML, JSON

                                                                              Format for DELETE:

                                                                              The specified rule has to be the last part in the URI:

                                                                              /security/acl/layers/*.*.r\n

                                                                              Note

                                                                              Slashes (\"/\") in a rule name must be encoded with %2F. The REST rule /;GET must be encoded to /security/acl/rest/%2F;GET

                                                                              Formats for GET,POST and PUT:

                                                                              XML

                                                                              <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<rules>\n   <rule resource=\"*.*.r\">*</rule>\n   <rule resource=\"myworkspace.*.w\">ROLE_1,ROLE_2</rule>\n</rules> \n

                                                                              JSON :

                                                                              {\n\"*.*.r\": \"*\",\n\"myworkspace\".*.w\": \"ROLE_1,ROLE_2\"\n}\n

                                                                              The resource attribute specifies a rule. There are three different formats.

                                                                              • For layers: ... The asterisk is a wild card for and . is one of r (read), w (write) or a (administer).
                                                                              • For services: .. The asterisk is a wild card wild card for and . Examples:
                                                                                • wfs.GetFeature
                                                                                • wfs.GetTransaction
                                                                                • wfs.*
                                                                              • For REST: ;. Examples:
                                                                                • /**;GET
                                                                                • /**;POST,DELETE,PUT

                                                                                The content of a rule element is a comma separated list of roles or the asterisk.

                                                                                "},{"location":"rest/api/accesscontrol/#exceptions_1","title":"Exceptions","text":"Exception Status code No administrative privileges 403 POST, adding an already existing rule 409 PUT, modifying a non existing rule 409 DELETE, Deleting a non existing rule 409 Invalid rule specification 422

                                                                                Note

                                                                                When adding a set of rules and only one role does already exist, the whole request is aborted. When modifying a set of rules and only one role does not exist, the whole request is aborted too.

                                                                                "},{"location":"rest/api/coverages/","title":"Coverages","text":"

                                                                                A coverage is a raster data set which originates from a coverage store.

                                                                                Todo

                                                                                JC: \"The second level headings [don't] work so well for the longer paths - maybe another heading format?\"

                                                                                "},{"location":"rest/api/coverages/#workspaceswscoveragestorescscoveragesformat","title":"/workspaces/<ws>/coveragestores/<cs>/coverages[.<format>]","text":"

                                                                                Controls all coverages in a given coverage store and workspace.

                                                                                Method Action Status code Formats Default Format GET List all coverages in coverage store cs 200 HTML, XML, JSON HTML POST Create a new coverage 201 with Location header XML, JSON PUT 405 DELETE 405"},{"location":"rest/api/coverages/#workspaceswscoveragestorescscoveragescformat","title":"/workspaces/<ws>/coveragestores/<cs>/coverages/<c>[.<format>]","text":"

                                                                                Controls a particular coverage in a given coverage store and workspace.

                                                                                Method Action Status code Formats Default Format Parameters GET Return coverage c 200 HTML, XML, JSON HTML quietOnNotFound POST 405 PUT Modify coverage c 200 XML,JSON DELETE Delete coverage c 200 recurse"},{"location":"rest/api/coverages/#exceptions","title":"Exceptions","text":"Exception Status code GET for a coverage that does not exist 404 PUT that changes name of coverage 403 PUT that changes coverage store of coverage 403"},{"location":"rest/api/coverages/#parameters","title":"Parameters","text":""},{"location":"rest/api/coverages/#rest_api_coverages_recurse","title":"recurse","text":"

                                                                                The recurse parameter recursively deletes all layers referenced by the specified coverage. Permitted values for this parameter are \"true\" or \"false\". The default value is \"false\".

                                                                                "},{"location":"rest/api/coverages/#rest_api_coverages_quietOnNotFound","title":"quietOnNotFound","text":"

                                                                                The quietOnNotFound parameter avoids to log an Exception when the coverage is not present. Note that 404 status code will be returned anyway.

                                                                                "},{"location":"rest/api/coverages/#structured-coverages","title":"Structured coverages","text":"

                                                                                Structured coverages are the ones whose content is made of granules, normally associated to attributes, often used to represent time, elevation and other custom dimensions attached to the granules themselves. Image mosaic is an example of a writable structured coverage reader, in which each of the mosaic granules is associated with attributes. NetCDF is an example of a read only one, in which the multidimensional grid contained in the file is exposed as a set of 2D slices, each associated with a different set of variable values.

                                                                                The following API applies exclusively to structured coverage readers.

                                                                                "},{"location":"rest/api/coverages/#workspaceswscoveragestorescscoveragescoverageindexformat","title":"/workspaces/<ws>/coveragestores/<cs>/coverages/<coverage>/index[.<format>]","text":"

                                                                                Declares the set of attributes associated to the specified coverage, their name, type and min/max occurrences.

                                                                                Method Action Status code Formats Default Format Parameters GET Returns the attributes, their names and their types 200 XML, JSON XML POST 405 PUT 405 DELETE 405"},{"location":"rest/api/coverages/#workspaceswscoveragestorescscoveragescoverageindexgranulesformat","title":"/workspaces/<ws>/coveragestores/<cs>/coverages/<coverage>/index/granules.<format>","text":"

                                                                                Returns the full list of granules, each with its attributes vales and geometry, and allows to selectively remove them

                                                                                Method Action Status code Formats Default Format Parameters GET Returns the list of granules and their attributes, either in GML (when XML is used) or GeoJSON (when JSON is used) 200 XML, JSON XML offset, limit, filter POST 405 PUT 405 DELETE Deletes the granules (all, or just the ones selected via the filter parameter) 200 filter"},{"location":"rest/api/coverages/#parameters_1","title":"Parameters","text":""},{"location":"rest/api/coverages/#rest_api_coverages_offset","title":"offset","text":"

                                                                                The offset parameter instructs GeoServer to skip the specified number of first granules when returning the data.

                                                                                "},{"location":"rest/api/coverages/#rest_api_coverages_limit","title":"limit","text":"

                                                                                The limit parameter instructs GeoServer to return at most the specified number of granules when returning the data.

                                                                                "},{"location":"rest/api/coverages/#rest_api_coverages_filter","title":"filter","text":"

                                                                                The filter parameter is a CQL filter that allows to select which granules will be returned based on their attribute values.

                                                                                "},{"location":"rest/api/coverages/#workspaceswscoveragestorescscoveragesmosaicindexgranulesgranuleidformat","title":"/workspaces/<ws>/coveragestores/<cs>/coverages/<mosaic>/index/granules/<granuleId>.<format>","text":"

                                                                                Returns a single granule and allows for its removal.

                                                                                Method Action Status code Formats Default Format Parameters GET Returns the specified of granules and its attributes, either in GML (when XML is used) or GeoJSON (when JSON is used) 200 XML, JSON XML quietOnNotFound POST 405 PUT 405 DELETE Deletes the granule 200"},{"location":"rest/api/coverages/#exceptions_1","title":"Exceptions","text":"Exception Status code GET for a granule that does not exist 404"},{"location":"rest/api/coverages/#parameters_2","title":"Parameters","text":""},{"location":"rest/api/coverages/#rest_api_structuredcoverages_quietOnNotFound","title":"quietOnNotFound","text":"

                                                                                The quietOnNotFound parameter avoids to log an Exception when the granule is not present. Note that 404 status code will be returned anyway.

                                                                                "},{"location":"rest/api/coveragestores/","title":"Coverage stores","text":"

                                                                                A coverage store contains raster format spatial data.

                                                                                "},{"location":"rest/api/coveragestores/#workspaceswscoveragestoresformat","title":"/workspaces/<ws>/coveragestores[.<format>]","text":"

                                                                                Controls all coverage stores in a given workspace.

                                                                                Method Action Status code Formats Default Format GET List all coverage stores in workspace ws 200 HTML, XML, JSON HTML POST Create a new coverage store 201 with Location header XML, JSON PUT 405 DELETE 405"},{"location":"rest/api/coveragestores/#workspaceswscoveragestorescsformat","title":"/workspaces/<ws>/coveragestores/<cs>[.<format>]","text":"

                                                                                Controls a particular coverage store in a given workspace.

                                                                                Method Action Status code Formats Default Format Parameters GET Return coverage store cs 200 HTML, XML, JSON HTML quietOnNotFound POST 405 PUT Modify coverage store cs DELETE Delete coverage store cs recurse, purge"},{"location":"rest/api/coveragestores/#exceptions","title":"Exceptions","text":"Exception Status code GET for a coverage store that does not exist 404 PUT that changes name of coverage store 403 PUT that changes workspace of coverage store 403 DELETE against a coverage store that contains configured coverage 403"},{"location":"rest/api/coveragestores/#parameters","title":"Parameters","text":""},{"location":"rest/api/coveragestores/#rest_api_coveragestores_recurse","title":"recurse","text":"

                                                                                The recurse parameter recursively deletes all layers referenced by the coverage store. Allowed values for this parameter are \"true\" or \"false\". The default value is \"false\".

                                                                                "},{"location":"rest/api/coveragestores/#rest_api_coveragestores_purge","title":"purge","text":"

                                                                                The purge parameter is used to customize the delete of files on disk (in case the underlying reader implements a delete method). It can take one of the three values:

                                                                                • none-(Default) Do not delete any store's file from disk.
                                                                                • metadata-Delete only auxiliary files and metadata. It's recommended when data files (such as granules) should not be deleted from disk.
                                                                                • all-Purge everything related to that store (metadata and granules).
                                                                                "},{"location":"rest/api/coveragestores/#rest_api_coveragestores_quietOnNotFound","title":"quietOnNotFound","text":"

                                                                                The quietOnNotFound parameter avoids to log an Exception when the coverage store is not present. Note that 404 status code will be returned anyway.

                                                                                "},{"location":"rest/api/coveragestores/#workspaceswscoveragestorescsfileextension","title":"/workspaces/<ws>/coveragestores/<cs>/file[.<extension>]","text":"

                                                                                This end point allows a file containing spatial data to be added (via a POST or PUT) into an existing coverage store, or will create a new coverage store if it doesn't already exist. In case of coverage stores containing multiple coverages (e.g., mosaic of NetCDF files) all the coverages will be configured unless configure=false is specified as a parameter.

                                                                                Method Action Status code Formats Default Format Parameters GET Deprecated. Get the underlying files for the coverage store as a zip file with MIME type application/zip. 200 POST If the coverage store is a simple one (e.g. GeoTiff) it will return a 405, if the coverage store is a structured one (e.g., mosaic) it will harvest the specified files into it, which in turn will integrate the files into the store. Harvest meaning is store dependent, for mosaic the new files will be added as new granules of the mosaic, and existing files will get their attribute updated, other stores might have a different behavior. 405 if the coverage store is a simple one, 200 if structured and the harvest operation succeeded recalculate, filename PUT Creates or overwrites the files for coverage store cs 200 See note below configure, coverageName DELETE 405"},{"location":"rest/api/coveragestores/#rest_api_coveragestores_file_put","title":"coveragestores file PUT","text":"

                                                                                A file can be PUT to a coverage store as a standalone or zipped archive file. Standalone files are only suitable for coverage stores that work with a single file such as GeoTIFF store. Coverage stores that work with multiple files, such as the ImageMosaic store, must be sent as a zip archive.

                                                                                When uploading a standalone file, set the Content-type appropriately based on the file type. If you are loading a zip archive, set the Content-type to application/zip.

                                                                                "},{"location":"rest/api/coveragestores/#exceptions_1","title":"Exceptions","text":"Exception Status code GET for a data store that does not exist 404 GET for a data store that is not file based 404"},{"location":"rest/api/coveragestores/#parameters_1","title":"Parameters","text":""},{"location":"rest/api/coveragestores/#extension","title":"extension","text":"

                                                                                The extension parameter specifies the type of coverage store. The following extensions are supported:

                                                                                Extension Coverage store geotiff GeoTIFF worldimage Georeferenced image (JPEG, PNG, TIFF) imagemosaic Image mosaic"},{"location":"rest/api/coveragestores/#rest_api_coveragestores_configure","title":"configure","text":"

                                                                                The configure parameter controls how the coverage store is configured upon file upload. It can take one of the three values:

                                                                                • first---(Default) Only setup the first feature type available in the coverage store.
                                                                                • none---Do not configure any feature types.
                                                                                • all---Configure all feature types.
                                                                                "},{"location":"rest/api/coveragestores/#rest_api_coveragestores_coveragename","title":"coverageName","text":"

                                                                                The coverageName parameter specifies the name of the coverage within the coverage store. This parameter is only relevant if the configure parameter is not equal to \"none\". If not specified the resulting coverage will receive the same name as its containing coverage store.

                                                                                Note

                                                                                At present a one-to-one relationship exists between a coverage store and a coverage. However, there are plans to support multidimensional coverages, so this parameter may change.

                                                                                "},{"location":"rest/api/coveragestores/#rest_api_coveragestores_recalculate","title":"recalculate","text":"

                                                                                The recalculate parameter specifies whether to recalculate any bounding boxes for a coverage. Some properties of coverages are automatically recalculated when necessary. In particular, the native bounding box is recalculated when the projection or projection policy is changed. The lat/long bounding box is recalculated when the native bounding box is recalculated or when a new native bounding box is explicitly provided in the request. (The native and lat/long bounding boxes are not automatically recalculated when they are explicitly included in the request.) In addition, the client may explicitly request a fixed set of fields to calculate by including a comma-separated list of their names in the recalculate parameter. For example:

                                                                                • recalculate= (empty parameter)---Do not calculate any fields, regardless of the projection, projection policy, etc. This might be useful to avoid slow recalculation when operating against large datasets.
                                                                                • recalculate=nativebbox---Recalculate the native bounding box, but do not recalculate the lat/long bounding box.
                                                                                • recalculate=nativebbox,latlonbbox---Recalculate both the native bounding box and the lat/long bounding box.
                                                                                "},{"location":"rest/api/coveragestores/#rest_api_coveragestores_filename","title":"filename","text":"

                                                                                The filename parameter specifies the target file name for a file that needs to harvested as part of a mosaic. This is important to avoid clashes and to make sure the right dimension values are available in the name for multidimensional mosaics to work.

                                                                                • filename=`NCOM_wattemp_000_20081102T0000000_12.tiff` Set the uploaded file name toNCOM_wattemp_000_20081102T0000000_12.tiff``
                                                                                "},{"location":"rest/api/datastores/","title":"Data stores","text":"

                                                                                A data store contains vector format spatial data. It can be a file (such as a shapefile), a database (such as PostGIS), or a server (such as a remote Web Feature Service).

                                                                                "},{"location":"rest/api/datastores/#workspaceswsdatastoresformat","title":"/workspaces/<ws>/datastores[.<format>]","text":"

                                                                                Controls all data stores in a given workspace.

                                                                                Method Action Status code Formats Default Format GET List all data stores in workspace ws 200 HTML, XML, JSON HTML POST Create a new data store 201 with Location header XML, JSON PUT 405 DELETE 405"},{"location":"rest/api/datastores/#workspaceswsdatastoresdsformat","title":"/workspaces/<ws>/datastores/<ds>[.<format>]","text":"

                                                                                Controls a particular data store in a given workspace.

                                                                                Method Action Status code Formats Default Format Parameters GET Return data store ds 200 HTML, XML, JSON HTML quietOnNotFound POST 405 PUT Modify data store ds DELETE Delete data store ds recurse"},{"location":"rest/api/datastores/#exceptions","title":"Exceptions","text":"Exception Status code GET for a data store that does not exist 404 PUT that changes name of data store 403 PUT that changes workspace of data store 403 DELETE against a data store that contains configured feature types 403"},{"location":"rest/api/datastores/#parameters","title":"Parameters","text":""},{"location":"rest/api/datastores/#rest_api_datastores_recurse","title":"recurse","text":"

                                                                                The recurse parameter recursively deletes all layers referenced by the specified data store. Allowed values for this parameter are \"true\" or \"false\". The default value is \"false\".

                                                                                "},{"location":"rest/api/datastores/#rest_api_datastores_quietOnNotFound","title":"quietOnNotFound","text":"

                                                                                The quietOnNotFound parameter avoids to log an Exception when the data store is not present. Note that 404 status code will be returned anyway.

                                                                                "},{"location":"rest/api/datastores/#workspaceswsdatastoresdsfileurlexternalextension","title":"/workspaces/<ws>/datastores/<ds>/[file|url|external][.<extension>]","text":"

                                                                                These endpoints (file, url, and external) allow a file containing either spatial data or a mapping configuration (in case an app-schema data store is targeted), to be added (via a PUT request) into an existing data store, or will create a new data store if it doesn't already exist. The three endpoints are used to specify the method that is used to upload the file:

                                                                                • file---Uploads a file from a local source. The body of the request is the file itself.
                                                                                • url---Uploads a file from an remote source. The body of the request is a URL pointing to the file to upload. This URL must be visible from the server.
                                                                                • external---Uses an existing file on the server. The body of the request is the absolute path to the existing file.
                                                                                Method Action Status code Formats Default Format Parameters GET Deprecated. Retrieve the underlying files for the data store as a zip file with MIME type application/zip 200 POST 405 PUT Uploads files to the data store ds, creating it if necessary 200 See note below configure, target, update, charset DELETE 405"},{"location":"rest/api/datastores/#exceptions_1","title":"Exceptions","text":"Exception Status code GET for a data store that does not exist 404 GET for a data store that is not file based 404"},{"location":"rest/api/datastores/#parameters_1","title":"Parameters","text":""},{"location":"rest/api/datastores/#rest_api_datastores_extension","title":"extension","text":"

                                                                                The extension parameter specifies the type of data being uploaded. The following extensions are supported:

                                                                                Extension Datastore shp Shapefile properties Property file h2 H2 Database appschema App-schema mapping configuration"},{"location":"rest/api/datastores/#rest_api_datastores_file_put","title":"File PUT","text":"

                                                                                A file can be PUT to a data store as a standalone or zipped archive file. Standalone files are only suitable for data stores that work with a single file such as a GML store. Data stores that work with multiple files, such as the shapefile store, must be sent as a zip archive.

                                                                                When uploading a standalone file, set the Content-type appropriately based on the file type. If you are loading a zip archive, set the Content-type to application/zip.

                                                                                "},{"location":"rest/api/datastores/#rest_api_datastores_file_put_appschema","title":"file PUT Application Schema","text":"

                                                                                The app-schema mapping configuration can either be uploaded as a single file, or split in multiple files for reusability and/or mapping constraints (e.g. multiple mappings of the same feature type are needed). If multiple mapping files are uploaded as a zip archive, the extension of the main mapping file (the one including the others via the <includedTypes> tag) must be .appschema, otherwise it will not be recognized as the data store's primary file and publishing will fail.

                                                                                The application schemas (XSD files) required to define the mapping can be added to the zip archive and uploaded along with the mapping configuration. All files contained in the archive are uploaded to the same folder, so the path to the secondary mapping files and the application schemas, as specified in the main mapping file, is simply the file name of the included resource.

                                                                                "},{"location":"rest/api/datastores/#rest_api_datastores_configure","title":"configure","text":"

                                                                                The configure parameter controls how the data store is configured upon file upload. It can take one of the three values:

                                                                                • first---(Default) Only setup the first feature type available in the data store.
                                                                                • none---Do not configure any feature types.
                                                                                • all---Configure all feature types.

                                                                                Note

                                                                                When uploading an app-schema mapping configuration, only the feature types mapped in the main mapping file are considered to be top level features and will be automatically configured when configure=all or configure=first is specified.

                                                                                "},{"location":"rest/api/datastores/#rest_api_datastores_target","title":"target","text":"

                                                                                The target parameter determines what format or storage engine will be used when a new data store is created on the server for uploaded data. When importing data into an existing data store, it is ignored. The allowed values for this parameter are the same as for the extension parameter, except for appschema, which doesn't make sense in this context.

                                                                                "},{"location":"rest/api/datastores/#rest_api_datastores_update","title":"update","text":"

                                                                                The update parameter controls how existing data is handled when the file is PUT into a data store that already exists and already contains a schema that matches the content of the file. The parameter accepts one of the following values:

                                                                                • append---Data being uploaded is appended to the existing data. This is the default.
                                                                                • overwrite---Data being uploaded replaces any existing data.

                                                                                The parameter is ignored for app-schema data stores, which are read-only.

                                                                                "},{"location":"rest/api/datastores/#rest_api_datastores_charset","title":"charset","text":"

                                                                                The charset parameter specifies the character encoding of the file being uploaded (such as \"ISO-8559-1\").

                                                                                "},{"location":"rest/api/details/","title":"API details","text":"

                                                                                This page contains information on the REST API architecture.

                                                                                "},{"location":"rest/api/details/#authentication","title":"Authentication","text":"

                                                                                REST requires that the client be authenticated. By default, the method of authentication used is Basic authentication. See the Security section for how to change the authentication method.

                                                                                "},{"location":"rest/api/details/#status-codes","title":"Status codes","text":"

                                                                                An HTTP request uses a status code to relay the outcome of the request to the client. Different status codes are used for various purposes throughout this document. These codes are described in detail by the HTTP specification.

                                                                                The most common status codes are listed below, along with their descriptions:

                                                                                Status code Description Notes 200 OK The request was successful 201 Created A new resource was successfully created, such as a new feature type or data store 403 Forbidden Often denotes a permissions mismatch 404 Not Found Endpoint or resource was not at the indicated location 405 Method Not Allowed Often denotes an endpoint accessed with an incorrect operation (for example, a GET request where a PUT/POST is indicated) 500 Internal Server Error Often denotes a syntax error in the request"},{"location":"rest/api/details/#formats-and-representations","title":"Formats and representations","text":"

                                                                                A format specifies how a particular resource should be represented. A format is used:

                                                                                • In an operation to specify what representation should be returned to the client
                                                                                • In a POST or PUT operation to specify the representation being sent to the server

                                                                                In a GET operation the format can be specified in two ways.

                                                                                There are two ways to specify the format for a GET operation. The first option uses the Accept header. For example, with the header set to \"Accept: text/xml\" the resource would be returned as XML. The second option of setting the format is via a file extension. For example, given a resource foo, to request a representation of foo as XML, the request URI would end with /foo.xml. To request a representation as JSON, the request URI would end with /foo.json. When no format is specified the server will use its own internal format, usually HTML. When the response format is specified both by the header and by the extension, the format specified by the extension takes precedence.

                                                                                In a POST or PUT operation, the format of content being sent to the server is specified with the Content-type header. For example, to send a representation in XML, use \"Content-type: text/xml\" or \"Content-type: application/xml\". As with GET requests, the representation of the content returned from the server is specified by the Accept header or by the format.

                                                                                The following table defines the Content-type values for each format:

                                                                                Format Content-type XML application/xml JSON application/json HTML application/html SLD application/vnd.ogc.sld+xml ZIP application/zip"},{"location":"rest/api/featuretypes/","title":"Feature types","text":"

                                                                                A feature type is a vector based spatial resource or data set that originates from a data store. In some cases, such as with a shapefile, a feature type has a one-to-one relationship with its data store. In other cases, such as PostGIS, the relationship of feature type to data store is many-to-one, feature types corresponding to a table in the database.

                                                                                "},{"location":"rest/api/featuretypes/#workspaceswsdatastoresdsfeaturetypesformat","title":"/workspaces/<ws>/datastores/<ds>/featuretypes[.<format>]","text":"

                                                                                Controls all feature types in a given data store / workspace.

                                                                                Method Action Status code Formats Default Format Parameters GET List all feature types in data store ds 200 HTML, XML, JSON HTML list POST Create a new feature type, see note below 201 with Location header XML, JSON PUT 405 DELETE 405"},{"location":"rest/api/featuretypes/#rest_api_featuretypes_post","title":"featuretypes POST","text":"

                                                                                When creating a new feature type via POST, if no underlying dataset with the specified name exists an attempt will be made to create it. This will work only in cases where the underlying data format supports the creation of new types (such as a database). When creating a feature type in this manner the client should include all attribute information in the feature type representation.

                                                                                "},{"location":"rest/api/featuretypes/#exceptions","title":"Exceptions","text":"Exception Status code GET for a feature type that does not exist 404 PUT that changes name of feature type 403 PUT that changes data store of feature type 403"},{"location":"rest/api/featuretypes/#parameters","title":"Parameters","text":""},{"location":"rest/api/featuretypes/#rest_api_featuretypes_list","title":"list","text":"

                                                                                The list parameter is used to control the category of feature types that are returned. It can take one of the following values:

                                                                                • configured---Only configured feature types are returned. This is the default value.
                                                                                • available---Only feature types that haven't been configured but are available from the specified data store will be returned.
                                                                                • available_with_geom---Same as available but only includes feature types that have a geometry attribute.
                                                                                • all---The union of configured and available.
                                                                                "},{"location":"rest/api/featuretypes/#workspaceswsdatastoresdsfeaturetypesftformat","title":"/workspaces/<ws>/datastores/<ds>/featuretypes/<ft>[.<format>]","text":"

                                                                                Controls a particular feature type in a given data store and workspace.

                                                                                Method Action Status code Formats Default Format Parameters GET Return feature type ft 200 HTML, XML, JSON HTML quietOnNotFound POST 405 PUT Modify feature type ft 200 XML,JSON recalculate DELETE Delete feature type ft 200 recurse"},{"location":"rest/api/featuretypes/#exceptions_1","title":"Exceptions","text":"Exception Status code GET for a feature type that does not exist 404 PUT that changes name of feature type 403 PUT that changes data store of feature type 403"},{"location":"rest/api/featuretypes/#parameters_1","title":"Parameters","text":""},{"location":"rest/api/featuretypes/#rest_api_featuretypes_recurse","title":"recurse","text":"

                                                                                The recurse parameter recursively deletes all layers referenced by the specified featuretype. Allowed values for this parameter are \"true\" or \"false\". The default value is \"false\". A DELETE request with recurse=false will fail if any layers reference the featuretype.

                                                                                "},{"location":"rest/api/featuretypes/#rest_api_featuretypes_recalculate","title":"recalculate","text":"

                                                                                The recalculate parameter specifies whether to recalculate any bounding boxes for a feature type. Some properties of feature types are automatically recalculated when necessary. In particular, the native bounding box is recalculated when the projection or projection policy are changed, and the lat/long bounding box is recalculated when the native bounding box is recalculated, or when a new native bounding box is explicitly provided in the request. (The native and lat/long bounding boxes are not automatically recalculated when they are explicitly included in the request.) In addition, the client may explicitly request a fixed set of fields to calculate, by including a comma-separated list of their names in the recalculate parameter. For example:

                                                                                • recalculate= (empty parameter): Do not calculate any fields, regardless of the projection, projection policy, etc. This might be useful to avoid slow recalculation when operating against large datasets.
                                                                                • recalculate=nativebbox: Recalculate the native bounding box, but do not recalculate the lat/long bounding box.
                                                                                • recalculate=nativebbox,latlonbbox: Recalculate both the native bounding box and the lat/long bounding box.
                                                                                "},{"location":"rest/api/featuretypes/#projection-policy","title":"Projection Policy","text":"

                                                                                When specifying the Projection Policy in a FeatureType defined in the request body, the internal name should be used instead of the one available on the UI. The following table shows the correspondence between display and internal names:

                                                                                Display Name Internal Name Force declared FORCE_DECLARED Keep native NONE Reproject native to declared REPROJECT_TO_DECLARED"},{"location":"rest/api/featuretypes/#rest_api_featuretypes_quietOnNotFound","title":"quietOnNotFound","text":"

                                                                                The quietOnNotFound parameter avoids to log an Exception when the feature type is not present. Note that 404 status code will be returned anyway.

                                                                                "},{"location":"rest/api/fonts/","title":"Fonts","text":"

                                                                                This operation provides the list of fonts available in GeoServer. It can be useful to use this operation to verify if a font used in a SLD file is available before uploading the SLD.

                                                                                "},{"location":"rest/api/fonts/#fontsformat","title":"/fonts[.<format>]","text":"Method Action Status code Formats Default Format GET Return the fonts available in GeoServer 200 XML, JSON XML POST 405 PUT 405 DELETE 405"},{"location":"rest/api/global/","title":"Global settings","text":"

                                                                                Allows access to GeoServer's global settings.

                                                                                "},{"location":"rest/api/global/#settingsformat","title":"/settings[.<format>]","text":"

                                                                                Controls all global settings.

                                                                                Method Action Status code Formats Default Format GET List all global settings 200 HTML, XML, JSON HTML POST 405 PUT Update global settings 200 XML, JSON DELETE 405"},{"location":"rest/api/global/#settingscontactformat","title":"/settings/contact[.<format>]","text":"

                                                                                Controls global contact information only.

                                                                                Method Action Status code Formats Default Format GET List global contact information 200 HTML, XML, JSON HTML POST 405 PUT Update global contact 200 XML, JSON DELETE 405"},{"location":"rest/api/layergroups/","title":"Layer groups","text":"

                                                                                A layer group is a grouping of layers and styles that can be accessed as a single layer in a WMS GetMap request. A layer group is sometimes referred to as a \"base map\".

                                                                                "},{"location":"rest/api/layergroups/#layergroupsformat","title":"/layergroups[.<format>]","text":"

                                                                                Controls all layer groups.

                                                                                Method Action Status code Formats Default Format GET Return all layer groups 200 HTML, XML, JSON HTML POST Add a new layer group 201, with Location header XML,JSON PUT 405 DELETE 405"},{"location":"rest/api/layergroups/#layergroupslgformat","title":"/layergroups/<lg>[.<format>]","text":"

                                                                                Controls a particular layer group.

                                                                                Method Action Status code Formats Default Format Parameters GET Return layer group lg 200 HTML, XML, JSON HTML quietOnNotFound POST 405 PUT Modify layer group lg 200 XML,JSON DELETE Delete layer group lg 200"},{"location":"rest/api/layergroups/#exceptions","title":"Exceptions","text":"Exception Status code GET for a layer group that does not exist 404 POST that specifies layer group with no layers 400 PUT that changes name of layer group 403"},{"location":"rest/api/layergroups/#parameters","title":"Parameters","text":""},{"location":"rest/api/layergroups/#rest_api_layergroups_quietOnNotFound","title":"quietOnNotFound","text":"

                                                                                The quietOnNotFound parameter avoids to log an Exception when the layergroup is not present. Note that 404 status code will be returned anyway.

                                                                                "},{"location":"rest/api/layergroups/#workspaceswslayergroupsformat","title":"/workspaces/<ws>/layergroups[.<format>]","text":"

                                                                                Controls all layer groups in a given workspace.

                                                                                Method Action Status code Formats Default Format GET Return all layer groups within workspace ws 200 HTML, XML, JSON HTML POST Add a new layer group within workspace ws 201, with Location header XML,JSON PUT 405 DELETE 405"},{"location":"rest/api/layergroups/#workspaceswslayergroupslgformat","title":"/workspaces/<ws>/layergroups/<lg>[.<format>]","text":"

                                                                                Controls a particular layer group in a given workspace.

                                                                                Method Action Status code Formats Default Format GET Return layer group lg within workspace ws 200 HTML, XML, JSON HTML quietOnNotFound POST 405 PUT Modify layer group lg within workspace ws 200 XML,JSON DELETE Delete layer group lg within workspace ws 200"},{"location":"rest/api/layergroups/#exceptions_1","title":"Exceptions","text":"Exception Status code GET for a layer group that does not exist for that workspace 404"},{"location":"rest/api/layers/","title":"Layers","text":"

                                                                                A layer is a published resource (feature type or coverage).

                                                                                "},{"location":"rest/api/layers/#layersformat","title":"/layers[.<format>]","text":"

                                                                                Controls all layers.

                                                                                Method Action Status code Formats Default Format GET Return all layers 200 HTML, XML, JSON HTML POST 405 PUT 405 DELETE 405"},{"location":"rest/api/layers/#layerslformat","title":"/layers/<l>[.<format>]","text":"

                                                                                Controls a particular layer.

                                                                                Method Action Status code Formats Default Format Parameters GET Return layer l 200 HTML, XML, JSON HTML quietOnNotFound POST 405 PUT Modify layer l 200 XML,JSON DELETE Delete layer l 200 recurse"},{"location":"rest/api/layers/#exceptions","title":"Exceptions","text":"Exception Status code GET for a layer that does not exist 404 PUT that changes name of layer 403 PUT that changes resource of layer 403"},{"location":"rest/api/layers/#parameters","title":"Parameters","text":""},{"location":"rest/api/layers/#rest_api_layers_recurse","title":"recurse","text":"

                                                                                The recurse parameter recursively deletes all styles referenced by the specified layer. Allowed values for this parameter are \"true\" or \"false\". The default value is \"false\".

                                                                                "},{"location":"rest/api/layers/#rest_api_layers_quietOnNotFound","title":"quietOnNotFound","text":"

                                                                                The quietOnNotFound parameter avoids to log an Exception when the layer is not present. Note that 404 status code will be returned anyway.

                                                                                "},{"location":"rest/api/layers/#layerslstylesformat","title":"/layers/<l>/styles[.<format>]","text":"

                                                                                Controls all styles in a given layer.

                                                                                Method Action Status code Formats Default Format GET Return all styles for layer l 200 SLD, HTML, XML, JSON HTML POST Add a new style to layer l 201, with Location header XML, JSON PUT 405 DELETE 405"},{"location":"rest/api/logging/","title":"Logging settings","text":"

                                                                                Allows access to GeoServer's logging settings.

                                                                                "},{"location":"rest/api/logging/#loggingformat","title":"/logging[.<format>]","text":"

                                                                                Controls logging settings.

                                                                                Method Action Status code Formats Default Format GET List logging settings 200 HTML, XML, JSON HTML POST 405 PUT Update logging settings 200 XML, JSON DELETE 405"},{"location":"rest/api/manifests/","title":"Manifests","text":"

                                                                                GeoServer provides a REST service to expose a listing of all loaded JARs and resources on the running instance. This is useful for bug reports and to keep track of extensions deployed into the application. There are two endpoints for accessing this information:

                                                                                • about/manifest---Retrieves details on all loaded JARs
                                                                                • about/version---Retrieves details for the high-level components: GeoSever, GeoTools, and GeoWebCache
                                                                                • about/status-Retrieves details for the status of all loaded and configured modules
                                                                                "},{"location":"rest/api/manifests/#aboutmanifestformat","title":"/about/manifest[.<format>]","text":"

                                                                                This endpoint retrieves details on all loaded JARs.

                                                                                All the GeoServer manifest JARs are marked with the property GeoServerModule and classified by type, so you can use filtering capabilities to search for a set of manifests using regular expressions (see the manifest parameter) or a type category (see the key and value parameter).

                                                                                The available types are core, extension, or community. To filter modules by a particular type, append a request with key=GeoServerModule&value=<type>

                                                                                Method Action Status Code Formats Default Format Parameters GET List all manifests into the classpath 200 HTML, XML, JSON HTML manifest, key, value POST 405 PUT 405 DELETE 405"},{"location":"rest/api/manifests/#usage","title":"Usage","text":"

                                                                                The model is very simple and is shared between the version and the resource requests to parse both requests.:

                                                                                <about>\n  <resource name=\"{NAME}\">\n    <{KEY}>{VALUE}<!--{KEY}-->\n    ...\n  </resource>\n  ...\n</about>\n

                                                                                You can customize the results adding a properties file called manifest.properties into the root of the data directory. Below is the default implementation that is used when no custom properties file is present:

                                                                                resourceNameRegex=.+/(.*).(jar|war)\nresourceAttributeExclusions=Import-Package,Export-Package,Class-Path,Require-Bundle\nversionAttributeInclusions=Project-Version:Version,Build-Timestamp,Git-Revision,\n  Specification-Version:Version,Implementation-Version:Git-Revision\n

                                                                                where:

                                                                                • resourceNameRegex---Group(1) will be used to match the attribute name of the resource.
                                                                                • resourceAttributeExclusions---Comma-separated list of properties to exclude (deny-list), used to exclude parameters that are too verbose such that the resource properties list is left open. Users can add their JARs (with custom properties) having the complete list of properties.
                                                                                • versionAttributeInclusions---Comma-separated list of properties to include (allow-list). Also supports renaming properties (using key:replace) which is used to align the output of the versions request to the output of the web page. The model uses a map to store attributes, so the last attribute found in the manifest file will be used.
                                                                                "},{"location":"rest/api/manifests/#rest_api_manifests_manifest","title":"manifest","text":"

                                                                                The manifest parameter is used to filter over resulting resource (manifest) names attribute using Java regular expressions.

                                                                                "},{"location":"rest/api/manifests/#rest_api_manifests_key","title":"key","text":"

                                                                                The key parameter is used to filter over resulting resource (manifest) properties name. It can be combined with the value parameter.

                                                                                "},{"location":"rest/api/manifests/#rest_api_manifests_value","title":"value","text":"

                                                                                The value parameter is used to filter over resulting resource (manifest) properties value. It can be combined with the key parameter.

                                                                                "},{"location":"rest/api/manifests/#aboutversionformat","title":"/about/version[.<format>]","text":"

                                                                                This endpoint shows only the details for the high-level components: GeoServer, GeoTools, and GeoWebCache.

                                                                                Method Action Status Code Formats Default Format Parameters GET List GeoServer, GeoWebCache and GeoTools manifests 200 HTML, XML, JSON HTML manifest, key, value POST 405 PUT 405 DELETE 405"},{"location":"rest/api/manifests/#aboutstatusformat","title":"/about/status[.<format>]","text":"

                                                                                This endpoint shows the status details of all installed and configured modules.Status details always include human readable name, and module name. Optional details include version, availability, status message, and links to documentation.

                                                                                Method Action Status Code Formats Default Format Parameters GET List module statuses 200 HTML, XML, JSON HTML POST 405 PUT 405 DELETE 405"},{"location":"rest/api/masterpassword/","title":"Keystore Password","text":"

                                                                                The keystore password is used to encrypt the GeoServer key store and for an emergency login using the user root.

                                                                                Warning

                                                                                The use of HTTPS is recommended, otherwise all password are sent in plain text.

                                                                                "},{"location":"rest/api/masterpassword/#securitymasterpwformat","title":"/security/masterpw[.<format>]","text":"

                                                                                Fetches the keystore password and allows to change the keystore password

                                                                                Method Action Status code Formats Default Format GET Fetch the keystore password 200,403 XML, JSON PUT Changes the keystore password 200,405,422 XML, JSON

                                                                                Formats for PUT (keystore password change).

                                                                                XML

                                                                                <masterPassword>\n   <oldMasterPassword>oldPassword</oldMasterPassword>\n   <newMasterPassword>newPassword</newMasterPassword>\n</masterPassword>\n

                                                                                JSON

                                                                                { \"oldMasterPassword\":\"oldPassword\",\n  \"newMasterPassword\":\"newPassword\" }\n
                                                                                "},{"location":"rest/api/masterpassword/#exceptions","title":"Exceptions","text":"Exception Status code GET without administrative privileges 403 PUT without administrative privileges 405 PUT with the wrong current keystore password 422 PUT with a new keystore password rejected by the password policy 422"},{"location":"rest/api/namespaces/","title":"Namespaces","text":"

                                                                                A namespace is a uniquely identifiable grouping of feature types. It is identified by a prefix and a URI.

                                                                                "},{"location":"rest/api/namespaces/#namespacesformat","title":"/namespaces[.<format>]","text":"

                                                                                Controls all namespaces.

                                                                                Method Action Status code Formats Default Format GET List all namespaces 200 HTML, XML, JSON HTML POST Create a new namespace 201 with Location header XML, JSON PUT 405 DELETE 405"},{"location":"rest/api/namespaces/#namespacesnsformat","title":"/namespaces/<ns>[.<format>]","text":"

                                                                                Controls a particular namespace.

                                                                                Method Action Status code Formats Default Format Parameters GET Return namespace ns 200 HTML, XML, JSON HTML quietOnNotFound POST 405 PUT 200 Modify namespace ns XML, JSON DELETE 200 Delete namespace ns XML, JSON"},{"location":"rest/api/namespaces/#exceptions","title":"Exceptions","text":"Exception Status code GET for a namespace that does not exist 404 PUT that changes prefix of namespace 403 DELETE against a namespace whose corresponding workspace is non-empty 403"},{"location":"rest/api/namespaces/#parameters","title":"Parameters","text":""},{"location":"rest/api/namespaces/#rest_api_namespaces_quietOnNotFound","title":"quietOnNotFound","text":"

                                                                                The quietOnNotFound parameter avoids to log an Exception when the Namespace is not present. Note that 404 status code will be returned anyway.

                                                                                "},{"location":"rest/api/namespaces/#namespacesdefaultformat","title":"/namespaces/default[.<format>]","text":"

                                                                                Controls the default namespace.

                                                                                Method Action Status code Formats Default Format GET Return default namespace 200 HTML, XML, JSON HTML POST 405 PUT 200 Set default namespace XML, JSON DELETE 405"},{"location":"rest/api/reload/","title":"Reloading configuration","text":"

                                                                                Reloads the GeoServer catalog and configuration from disk. This operation is used in cases where an external tool has modified the on-disk configuration. This operation will also force GeoServer to drop any internal caches and reconnect to all data stores.

                                                                                "},{"location":"rest/api/reload/#reload","title":"/reload","text":"Method Action Status code Formats Default Format GET 405 POST Reload the configuration from disk 200 PUT Reload the configuration from disk 200 DELETE 405"},{"location":"rest/api/reset/","title":"Resource reset","text":"

                                                                                Resets all store, raster, and schema caches. This operation is used to force GeoServer to drop all caches and store connections and reconnect to each of them the next time they are needed by a request. This is useful in case the stores themselves cache some information about the data structures they manage that may have changed in the meantime.

                                                                                "},{"location":"rest/api/reset/#reset","title":"/reset","text":"Method Action Status code Formats Default Format GET 405 POST Reset all store, raster, and schema caches 200 PUT Reset all store, raster, and schema caches 200 DELETE 405"},{"location":"rest/api/resources/","title":"Resources","text":""},{"location":"rest/api/resources/#resourcepathtoresource","title":"/resource</path/to/resource>","text":"Method Action Status code Parameters GET Download a resource, list contents of directory, or show formatted resource metadata. 200 operation (default HEAD Show resource metadata in HTTP headers. 200 PUT Upload/move/copy a resource, create directories on the fly (overwrite if exists). For move/copy operations, place source path in body. Copying is not supported for directories. 200 (exists) 201 (new) operation (default DELETE Delete a resource (recursively if directory) 200"},{"location":"rest/api/resources/#exceptions","title":"Exceptions","text":"Exception Status code GET or DELETE for a resource that does not exist 404 PUT to directory 405 PUT method=copy with source directory 405 PUT with source path that doesn't exist 404 POST 405"},{"location":"rest/api/resources/#headers","title":"Headers","text":"Header Description Last-Modified When resource was last modified. Content-Type Will guess mime-type from extension or content. Resource-Type (custom) directory Resource-Parent (custom) Path to parent"},{"location":"rest/api/resources/#format","title":"Format","text":"

                                                                                Examples are given in XML. The JSON and HTML formats are analogue.

                                                                                "},{"location":"rest/api/resources/#metadata","title":"Metadata","text":"
                                                                                <ResourceMetaData>\n   <name> nameOfFile </name>\n   <parent> <path> path/to/parent </path>\n        <atom:link xmlns:atom=\"http://www.w3.org/2005/Atom\" rel=\"alternate\"\n   href=\"http://localhost:8080/geoserver/rest/resource/path/to/parent?operation=metadata&format=xml\" \n         type=\"application/xml\"/>\n   </parent>\n   <lastModified> date </lastModified>\n   <type> undefined | resource | directory </type>\n</ResourceMetaData>\n
                                                                                "},{"location":"rest/api/resources/#directories","title":"Directories","text":"
                                                                                <ResourceDirectory>`\n   <name> nameOfDirectory </name>\n   <parent> <path> path/to/parent </path>\n        <atom:link xmlns:atom=\"http://www.w3.org/2005/Atom\" rel=\"alternate\"\n   href=\"http://localhost:8080/geoserver/rest/resource/path/to/parent?operation=metadata&format=xml\" \n         type=\"application/xml\"/>\n   </parent>\n   <lastModified> date </lastModified>\n   <children>\n       <child>\n               <name> ... </name>\n               <atom:link xmlns:atom=\"http://www.w3.org/2005/Atom\" rel=\"alternate\"\n                href=\"http://localhost:8080/geoserver/rest/resource/path/to/child\"/>\n       </child>\n       <child>\n               ...\n       </child>\n       ...\n   </children>` \n</ResourceDirectory>\n
                                                                                "},{"location":"rest/api/selfadmin/","title":"Self admin","text":"

                                                                                Self admin operations allow a user to perform actions on the user's own info.

                                                                                Calls to the self admin operations are disabled by default. You'll have to edit the rest.properties file (more info at the REST services page) and add the line:

                                                                                /rest/security/self/**;GET,POST,PUT,DELETE=ROLE_AUTHENTICATED\n
                                                                                "},{"location":"rest/api/selfadmin/#securityselfpassword","title":"/security/self/password","text":"

                                                                                Allows a user to change own password

                                                                                Warning

                                                                                The use of HTTPS is recommended, otherwise all password are sent in plain text.

                                                                                Method Action Status code Formats Default Format PUT Changes the user password 200,400,424 XML, JSON

                                                                                Formats for PUT (password change).

                                                                                XML

                                                                                <userPassword>\n   <newPassword>newPassword</newPassword>\n</userPassword>\n

                                                                                JSON

                                                                                { \"newPassword\":\"newPassword\" }\n
                                                                                "},{"location":"rest/api/selfadmin/#exceptions","title":"Exceptions","text":"Exception Status code Error string (payload) PUT with an invalid newPassword or bad params 400 Missing 'newPassword' PUT for user not updatable 424 User service does not support changing pw"},{"location":"rest/api/services/","title":"OWS Services","text":"

                                                                                GeoServer includes several types of OGC services like WCS, WFS and WMS, commonly referred to as \"OWS\" services. These services can be global for the whole GeoServer instance or local to a particular workspace. In this last case, they are called virtual services.

                                                                                "},{"location":"rest/api/services/#serviceswcssettingsformat","title":"/services/wcs/settings[.<format>]","text":"

                                                                                Controls Web Coverage Service settings.

                                                                                Method Action Status code Formats Default Format GET Return global WCS settings 200 XML, JSON HTML POST 405 PUT Modify global WCS settings 200 DELETE 405"},{"location":"rest/api/services/#serviceswcsworkspaceswssettingsformat","title":"/services/wcs/workspaces/<ws>/settings[.<format>]","text":"

                                                                                Controls Web Coverage Service settings for a given workspace.

                                                                                Method Action Status code Formats Default Format GET Return WCS settings for workspace ws 200 HTML, XML, JSON HTML POST 405 PUT Create or modify WCS settings for workspace ws 200 XML,JSON DELETE Delete WCS settings for workspace ws 200"},{"location":"rest/api/services/#serviceswfssettingsformat","title":"/services/wfs/settings[.<format>]","text":"

                                                                                Controls Web Feature Service settings.

                                                                                Method Action Status code Formats Default Format GET Return global WFS settings 200 HTML, XML, JSON HTML POST 405 PUT Modify global WFS settings 200 XML,JSON DELETE 405"},{"location":"rest/api/services/#serviceswfsworkspaceswssettingsformat","title":"/services/wfs/workspaces/<ws>/settings[.<format>]","text":"

                                                                                Controls Web Feature Service settings for a given workspace.

                                                                                Method Action Status code Formats Default Format GET Return WFS settings for workspace ws 200 HTML, XML, JSON HTML POST 405 PUT Modify WFS settings for workspace ws 200 XML,JSON DELETE Delete WFS settings for workspace ws 200"},{"location":"rest/api/services/#serviceswmssettingsformat","title":"/services/wms/settings[.<format>]","text":"

                                                                                Controls Web Map Service settings.

                                                                                Method Action Status code Formats Default Format GET Return global WMS settings 200 HTML, XML, JSON HTML POST 405 PUT Modify global WMS settings 200 XML,JSON DELETE 405"},{"location":"rest/api/services/#serviceswmsworkspaceswssettingsformat","title":"/services/wms/workspaces/<ws>/settings[.<format>]","text":"

                                                                                Controls Web Map Service settings for a given workspace.

                                                                                Method Action Status code Formats Default Format GET Return WMS settings for workspace ws 200 HTML, XML, JSON HTML POST 405 PUT Modify WMS settings for workspace ws 200 XML,JSON DELETE Delete WMS settings for workspace ws 200"},{"location":"rest/api/services/#serviceswmtssettingsformat","title":"/services/wmts/settings[.<format>]","text":"

                                                                                Controls Web Map Tile Service settings.

                                                                                Method Action Status code Formats Default Format GET Return global WMTS settings 200 HTML, XML, JSON HTML POST 405 PUT Modify global WMTS settings 200 XML,JSON DELETE 405"},{"location":"rest/api/services/#serviceswmtsworkspaceswssettingsformat","title":"/services/wmts/workspaces/<ws>/settings[.<format>]","text":"

                                                                                Controls Web Map Tile Service settings for a given workspace.

                                                                                Method Action Status code Formats Default Format GET Return WMTS settings for workspace ws 200 HTML, XML, JSON HTML POST 405 PUT Modify WMTS settings for workspace ws 200 XML,JSON DELETE Delete WMTS settings for workspace ws 200

                                                                                Todo

                                                                                WPS?

                                                                                "},{"location":"rest/api/styles/","title":"Styles","text":"

                                                                                A style describes how a resource (feature type or coverage) should be symbolized or rendered by the Web Map Service. In GeoServer styles are specified with SLD.

                                                                                "},{"location":"rest/api/styles/#stylesformat","title":"/styles[.<format>]","text":"

                                                                                Controls all styles.

                                                                                Method Action Status code Formats Default Format Parameters GET Return all styles 200 HTML, XML, JSON HTML POST Create a new style 201 with Location header SLD, XML, JSON, ZIP See note below name raw PUT 405 DELETE 405"},{"location":"rest/api/styles/#rest_api_styles_post_put","title":"Styles POST and PUT","text":"

                                                                                When executing a POST or PUT request with an SLD style, the Content-type header should be set to the mime type identifying the style format. Style formats supported out of the box include:

                                                                                • SLD 1.0 with a mime type of application/vnd.ogc.sld+xml
                                                                                • SLD 1.1 / SE 1.1 with a mime type of application/vnd.ogc.se+xml
                                                                                • SLD package (zip file containing sld and image files used in the style) with a mime type of application/zip

                                                                                Other extensions (such as css) add support for additional formats.

                                                                                "},{"location":"rest/api/styles/#parameters","title":"Parameters","text":""},{"location":"rest/api/styles/#rest_api_styles_name","title":"name","text":"

                                                                                The name parameter specifies the name to be given to the style. This option is most useful when executing a POST request with a style in SLD format, and an appropriate name can be not be inferred from the SLD itself.

                                                                                "},{"location":"rest/api/styles/#rest_api_styles_raw","title":"raw","text":"

                                                                                The raw parameter specifies whether to forgo parsing and encoding of the uploaded style content. When set to \"true\" the style payload will be streamed directly to GeoServer configuration. Use this setting if the content and formatting of the style is to be preserved exactly. Use this setting with care as it may result in an invalid and unusable style. The default is \"false\".

                                                                                "},{"location":"rest/api/styles/#stylessformat","title":"/styles/<s>[.<format>]","text":"

                                                                                Controls a given style.

                                                                                Method Action Status code Formats Default Format Parameters GET Return style s 200 SLD, HTML, XML, JSON HTML quietOnNotFound pretty POST 405 PUT Modify style s 200 SLD, XML, JSON, ZIP See note above raw DELETE Delete style s 200 purge recurse"},{"location":"rest/api/styles/#exceptions","title":"Exceptions","text":"Exception Status code GET for a style that does not exist 404 PUT that changes name of style 403 DELETE against style which is referenced by existing layers 403"},{"location":"rest/api/styles/#parameters_1","title":"Parameters","text":""},{"location":"rest/api/styles/#rest_api_styles_purge","title":"purge","text":"

                                                                                The purge parameter specifies whether the underlying SLD file for the style should be deleted on disk. Allowable values for this parameter are \"true\" or \"false\". When set to \"true\" the underlying file will be deleted.

                                                                                "},{"location":"rest/api/styles/#rest_api_styles_recurse","title":"recurse","text":"

                                                                                The recurse parameter removes references to the specified style in existing layers. Allowed values for this parameter are \"true\" or \"false\". The default value is \"false\".

                                                                                "},{"location":"rest/api/styles/#rest_api_styles_quietOnNotFound","title":"quietOnNotFound","text":"

                                                                                The quietOnNotFound parameter avoids to log an Exception when the style is not present. Note that 404 status code will be returned anyway.

                                                                                "},{"location":"rest/api/styles/#rest_api_styles_pretty","title":"pretty","text":"

                                                                                The pretty parameter returns the style in a human-readable format, with proper blank-space and indentation. This parameter has no effect if you request a style in its native format - in this case the API returns the exact content of the underlying file. The HTML, XML, and JSON formats do not support this parameter.

                                                                                "},{"location":"rest/api/styles/#workspaceswsstylesformat","title":"/workspaces/<ws>/styles[.<format>]","text":"

                                                                                Controls all styles in a given workspace.

                                                                                Method Action Status code Formats Default Format Parameters GET Return all styles within workspace ws 200 HTML, XML, JSON HTML POST Create a new style within workspace ws 201 with Location header SLD, XML, JSON, ZIP See note above name raw PUT 405 DELETE 405 purge"},{"location":"rest/api/styles/#workspaceswsstylessformat","title":"/workspaces/<ws>/styles/<s>[.<format>]","text":"

                                                                                Controls a particular style in a given workspace.

                                                                                Method Action Status code Formats Default Format Parameters GET Return style s within workspace ws 200 SLD, HTML, XML, JSON HTML quietOnNotFound POST 405 PUT Modify style s within workspace ws 200 SLD, XML, JSON, ZIP See note above raw DELETE Delete style s within workspace ws 200"},{"location":"rest/api/styles/#exceptions_1","title":"Exceptions","text":"Exception Status code GET for a style that does not exist for that workspace 404"},{"location":"rest/api/templates/","title":"Freemarker templates","text":"

                                                                                Freemarker is a simple yet powerful template engine that GeoServer uses for user customization of outputs.

                                                                                It is possible to use the GeoServer REST API to manage Freemarker templates for catalog resources.

                                                                                "},{"location":"rest/api/templates/#templatestemplateftl","title":"/templates/<template>.ftl","text":"

                                                                                This endpoint manages a template that is global to the entire catalog.

                                                                                Method Action Status Code Formats Default Format GET Return a template 200 PUT Insert or update a template 405 DELETE Delete a template 405

                                                                                Identical operations apply to the following endpoints:

                                                                                • Workspace templates---/workspaces/<ws>/templates/<template>.ftl
                                                                                • Vector store templates---/workspaces/<ws>/datastores/<ds>/templates/<template>.ftl
                                                                                • Feature type templates---/workspaces/<ws>/datastores/<ds>/featuretypes/<f>/templates/<template>.ftl
                                                                                • Raster store templates---/workspaces/<ws>/coveragestores/<cs>/templates/<template>.ftl
                                                                                • Coverage templates---/workspaces/<ws>/coveragestores/<cs>/coverages/<c>/templates/<template>.ftl
                                                                                "},{"location":"rest/api/templates/#templatesformat","title":"/templates[.<format>]","text":"

                                                                                This endpoint manages all global templates.

                                                                                Method Action Status Code Formats Default Format GET Return templates 200 HTML, XML, JSON HTML

                                                                                Identical operations apply to the following endpoints:

                                                                                • Workspace templates---/workspaces/<ws>/templates[.<format>]
                                                                                • Vector store templates---/workspaces/<ws>/datastores/<ds>/templates[.<format>]
                                                                                • Feature type templates---/workspaces/<ws>/datastores/<ds>/featuretypes/<f>/templates[.<format>]
                                                                                • Raster store templates---/workspaces/<ws>/coveragestores/<cs>/templates[.<format>]
                                                                                • Coverage templates---/workspaces/<ws>/coveragestores/<cs>/coverages/<c>/templates[.<format>]
                                                                                "},{"location":"rest/api/userrole/","title":"Users/Groups and Roles","text":""},{"location":"rest/api/userrole/#security","title":"Security","text":"

                                                                                The Users/Groups and Roles Rest API is only accessible to users with the role ROLE_ADMIN.

                                                                                "},{"location":"rest/api/userrole/#inputoutput","title":"Input/Output","text":""},{"location":"rest/api/userrole/#data-object-transfer","title":"Data Object Transfer","text":"

                                                                                Both XML and JSON are supported for transfer of data objects. The default is XML. Alternatively, JSON may be used by setting the 'content-type' (POST) and 'accept' (GET) http headers to 'application/json' in your requests.

                                                                                Encoding of a user in XML:

                                                                                <user>\n    <userName>..</userName>\n    <password>..</password>\n    <enabled>true/false</enabled>\n</user>\n

                                                                                Encoding of a user in JSON:

                                                                                {\"userName\": \"..\", \"password\": \"..\", enabled: true/false}\n

                                                                                Passwords are left out in results of reading requests.

                                                                                Encoding of a list of users in XML:

                                                                                <users>\n    <user> ... </user>\n    <user> ... </user>\n    ...     \n</users>\n

                                                                                Encoding of a list of users in JSON:

                                                                                {\"users\":[ {..}, {..}, .. ]}\n

                                                                                Encoding of a list of groups in XML:

                                                                                <groups>\n    <group> agroupname </group>\n    <group> bgroupname </group>\n    ...     \n</groups>\n

                                                                                Encoding of a list of groups in JSON:

                                                                                {\"groups\":[ {..}, {..}, .. ]}\n

                                                                                Encoding of a list of roles:

                                                                                <roles>\n    <role> arolename </role>\n    <role> brolename </role>\n    ...     \n</roles>\n

                                                                                Encoding of a list of roles in JSON:

                                                                                {\"roles\":[ {..}, {..}, .. ]}\n
                                                                                "},{"location":"rest/api/userrole/#configuration","title":"Configuration","text":"

                                                                                The default user/group service is by default the service named \"default\". This can be altered in the following manner:

                                                                                1. Start geoserver with the following java system property present:
                                                                                  org.geoserver.rest.DefaultUserGroupServiceName=<name_of_usergroupservice>\n
                                                                                "},{"location":"rest/api/userrole/#requests","title":"Requests","text":""},{"location":"rest/api/userrole/#restusergroupserviceservicenameusers","title":"/rest/usergroup/[service/<serviceName>/]users/","text":"

                                                                                Query all users or add a new user in a particular or the default user/group service.

                                                                                Method Action Response GET List all users in service. 200 OK. List of users in XML. POST Add a new user 201 Inserted. Created ID header."},{"location":"rest/api/userrole/#restusergroupserviceservicenameuseruser","title":"/rest/usergroup/[service/<serviceName>/]user/<user>","text":"

                                                                                Query, modify or delete a specific user in a particular or the default user/group service.

                                                                                Method Action Response GET Read user information 200 OK. User in XML. POST Modify the user, unspecified fields remain unchanged. 200 OK. DELETE Delete the user 200 OK."},{"location":"rest/api/userrole/#restusergroupserviceservicenamegroups","title":"/rest/usergroup/[service/<serviceName>/]groups/","text":"

                                                                                Query all groups in a particular user/group or the default service.

                                                                                Method Action Response GET List all groups in service. 200 OK. List of groups in XML."},{"location":"rest/api/userrole/#restusergroupserviceservicenamegroupgroup","title":"/rest/usergroup/[service/<serviceName>/]group/<group>","text":"

                                                                                Add or delete a specific group in a particular or the default user/group service.

                                                                                Method Action Response POST Add the group. 200 OK. DELETE Delete the group. 200 OK."},{"location":"rest/api/userrole/#restusergroupserviceservicenameuserusergroups","title":"/rest/usergroup/[service/<serviceName>/]user/<user>/groups","text":"

                                                                                Query all groups associated with a user in a particular or the default user/group service.

                                                                                Method Action Response GET List all groups associated with user. 200 OK. List of groups in XML."},{"location":"rest/api/userrole/#restusergroupserviceservicenamegroupgroupusers","title":"/rest/usergroup/[service/<serviceName>/]group/<group>/users","text":"

                                                                                Query all users associated with a group in a particular or the default user/group service.

                                                                                Method Action Response GET List all users associated with group. 200 OK. List of groups in XML."},{"location":"rest/api/userrole/#restusergroupserviceservicenameusergroupgroup","title":"/rest/usergroup/[service/<serviceName>/]<user>/group/<group>","text":"

                                                                                Associate or disassociate a specific user with a specific group in a particular or the default user/group service.

                                                                                Method Action Response POST Associate the user with the group. 200 OK. DELETE Disassociate the user from the group. 200 OK."},{"location":"rest/api/userrole/#restrolesserviceservicename","title":"rest/roles/[service/{serviceName}/]","text":"

                                                                                Query all roles in a particular role service or the active role service.

                                                                                Method Action Response GET List all roles in service. 200 OK. List of roles in XML."},{"location":"rest/api/userrole/#restrolesserviceservicenamerolerole","title":"/rest/roles/[service/<serviceName>/]role/<role>","text":"

                                                                                Add or delete a specific role in a particular role service or the active role service.

                                                                                Method Action Response POST Add the role. 200 OK. DELETE Delete the role. 200 OK."},{"location":"rest/api/userrole/#restrolesserviceservicenameservicenameuseruserroles","title":"/rest/roles/[service/<serviceName>/]<serviceName>/user/<user>/roles","text":"

                                                                                Query all roles associated with a user in a particular role service or the active role service.

                                                                                Method Action Response GET List all roles associated with user. 200 OK. List of roles in XML."},{"location":"rest/api/userrole/#restrolesserviceservicenameroleroleuseruser","title":"/rest/roles/[service/<serviceName>/]role/<role>/user/<user>/","text":"

                                                                                Associate or disassociate a specific user with a specific role in a particular role service or the active role service.

                                                                                Method Action Response POST Associate the user with the role. 200 OK. DELETE Disassociate the user from the role. 200 OK."},{"location":"rest/api/workspaces/","title":"Workspaces","text":"

                                                                                A workspace is a grouping of data stores. Similar to a namespace, it is used to group data that is related in some way.

                                                                                "},{"location":"rest/api/workspaces/#workspacesformat","title":"/workspaces[.<format>]","text":"

                                                                                Controls all workspaces.

                                                                                Method Action Status code Formats Default Format GET List all workspaces 200 HTML, XML, JSON HTML POST Create a new workspace 201 with Location header XML, JSON PUT 405 DELETE 405"},{"location":"rest/api/workspaces/#workspaceswsformat","title":"/workspaces/<ws>[.<format>]","text":"

                                                                                Controls a specific workspace.

                                                                                Method Action Status code Formats Default Format Parameters GET Return workspace ws 200 HTML, XML, JSON HTML quietOnNotFound POST 405 PUT 200 Modify workspace ws XML, JSON DELETE 200 Delete workspace ws XML, JSON recurse"},{"location":"rest/api/workspaces/#exceptions","title":"Exceptions","text":"Exception Status code GET for a workspace that does not exist 404 PUT that changes name of workspace 403 DELETE against a workspace that is non-empty 403"},{"location":"rest/api/workspaces/#parameters","title":"Parameters","text":""},{"location":"rest/api/workspaces/#rest_api_workspaces_recurse","title":"recurse","text":"

                                                                                The recurse parameter recursively deletes all layers referenced by the specified workspace, including data stores, coverage stores, feature types, and so on. Allowed values for this parameter are \"true\" or \"false\". The default value is \"false\".

                                                                                "},{"location":"rest/api/workspaces/#rest_api_workspaces_quietOnNotFound","title":"quietOnNotFound","text":"

                                                                                The quietOnNotFound parameter avoids to log an Exception when the Workspace is not present. Note that 404 status code will be returned anyway.

                                                                                "},{"location":"rest/api/workspaces/#workspacesdefaultformat","title":"/workspaces/default[.<format>]","text":"

                                                                                Controls the default workspace.

                                                                                Method Action Status code Formats Default Format GET Returns default workspace 200 HTML, XML, JSON HTML POST 405 PUT 200 Set default workspace XML, JSON DELETE 405"},{"location":"rest/api/workspaces/#workspaceswssettingsformat","title":"/workspaces/<ws>/settings[.<format>]","text":"

                                                                                Controls settings on a specific workspace.

                                                                                Method Action Status code Formats Default Format GET Returns workspace settings 200 HTML, XML, JSON HTML POST 405 PUT Creates or updates workspace settings 200 XML, JSON DELETE Deletes workspace settings 200 XML, JSON"},{"location":"security/","title":"Security","text":"

                                                                                This section details the security subsystem in GeoServer, which is based on Spring Security.

                                                                                The first page discusses configuration options in the web administration interface. This is followed with a detailed discussion of the underlying processes.

                                                                                • Security settings
                                                                                • Role system
                                                                                • Authentication
                                                                                • Passwords
                                                                                • Root account
                                                                                • Service Security
                                                                                • Layer security
                                                                                • REST Security
                                                                                • URL Checks
                                                                                • Disabling security
                                                                                • Tutorials
                                                                                "},{"location":"security/disable/","title":"Disabling security","text":"

                                                                                If you are using an external security subsystem, you may want to disable the built-in security to prevent conflicts. Disabling security is possible for each security filter chain individually. The security filter chains are listed on the GeoServer authentication page.

                                                                                Warning

                                                                                Disabling security for a filter chain results in administrator privileges for each HTTP request matching this chain. As an example, disabling security on the web chain gives administrative access to each user accessing the Web administration interface interface.

                                                                                "},{"location":"security/layer/","title":"Layer security","text":"

                                                                                GeoServer allows access to be determined on a per-layer basis.

                                                                                Note

                                                                                Layer security and Service Security cannot be combined. For example, it is not possible to specify access to a specific OWS service, only for one specific layer.

                                                                                Providing access to layers is linked to roles. Layers and roles are linked in a file called layers.properties, which is located in the security directory in your GeoServer data directory. The file contains the rules that control access to workspaces and layers.

                                                                                Note

                                                                                The default layers security configuration in GeoServer allows any anonymous user to read data from any layer but only allows admin users to edit data.

                                                                                "},{"location":"security/layer/#rules","title":"Rules","text":"

                                                                                The syntax for a layer security rule can follow three different patterns ([] denotes optional parameters):

                                                                                globalLayerGroup.permission=role[,role2,...]\nworkspace.layer.permission=role[,role2,...]\nworkspace.workspaceLayerGroup.permission=role[,role2,...]\n

                                                                                The parameters include:

                                                                                • globalLayerGroup--- Name of a global layer group (one without workspace associated to it).

                                                                                • workspace--- Name of the workspace. The wildcard * is used to indicate all workspaces.

                                                                                • layer--- Name of a resource (featuretype/coverage/etc...). The wildcard * is used to indicate all layers.

                                                                                • workspaceLayerGroup--- Name of a workspace specific layer group.

                                                                                • permission--- Type of access permission/mode.

                                                                                  • r---Read access
                                                                                  • w---Write access
                                                                                  • a---Admin access

                                                                                  See Access modes for more details.

                                                                                • role[,role2,...] is the name(s) of predefined roles. The wildcard * is used to indicate the permission is applied to all users, including anonymous users.

                                                                                Note

                                                                                If a workspace or layer name is supposed to contain dots, they can be escaped using double backslashes (\\). For example, if a layer is named layer.with.dots the following syntax for a rule may be used:

                                                                                topp.layer\\\\.with\\\\.dots.r=role[,role2,...]\n

                                                                                General rules for layer security:

                                                                                • Each entry must have a unique combination of workspace, layer, and permission values.
                                                                                • If a permission at the global level is not specified, global permissions are assumed to allow read/write access.
                                                                                • If a permission for a workspace is not specified, it inherits permissions from the global specification.
                                                                                • If a permission for a layer is not specified, it inherits permissions from its workspace specification in all protocols except WMS (where layer groups rules play a role, see below).
                                                                                • If a user belongs to multiple roles, the least restrictive permission they inherit will apply.

                                                                                For WMS, layers will be also secured by considering their containing layer groups. In particular:

                                                                                • Rules with Single layer groups only affect the group itself, but not its contents. Single mode is considered just an alias for a list of layers, with no containment.
                                                                                • Rules with other types of groups (Named tree, Container tree, Earth Observation tree) also affect contained layers and nested layer groups. If the group is not accessible, the layers and groups contained in that group will not be accessible either.. The only exception is when another layer group which is accessible contains the same layer or nested group, in that case the layers they will show up under the allowed groups.
                                                                                • Workspace rules gets precedence over global layer group ones when it comes to allow access to layers.
                                                                                • Layer rules get precedence over all layer group rules when it comes to allow access to layers.

                                                                                The following tables summarizes the layer group behavior depending on whether they are used in a public or secured environment:

                                                                                Mode Public behavior Restricted behavior

                                                                                Single Looks like a stand-alone layer, can be requested directly and acts as an alias for a layer list. Layers are also visible at root level Does not control layer access at all

                                                                                Opaque container Looks like a stand-alone layer, can be requested directly and acts as an alias for a layer list. Layers in it are not available for WMS requests Same as public behavior

                                                                                Named tree Contained layers are visible as children in the capabilities document, the name can be used as a shortcut to request all layers. Restricting access to the group restricts also the contained layers, unless another \"tree\" group allows access to the same layer

                                                                                Container tree Same as \"named tree\", but does not have a name published in the capabilities document and thus cannot be requested directly Same as \"named tree\"

                                                                                "},{"location":"security/layer/#catalog-mode","title":"Catalog Mode","text":"

                                                                                The layers.properties file may contain a further directive that specifies how GeoServer will advertise secured layers and behave when a secured layer is accessed without the necessary privileges. The parameter is mode and is commonly referred to as the \"catalog mode\".

                                                                                The syntax is:

                                                                                mode=option\n

                                                                                option may be one of three values:

                                                                                Option Description hide (Default) Hides layers that the user does not have read access to, and behaves as if a layer is read only if the user does not have write permissions. The capabilities documents will not contain the layers the current user cannot access. This is the highest security mode. As a result, it may not work very well with clients such as uDig or Google Earth. challenge Allows free access to metadata, but any attempt at accessing actual data is met by a HTTP 401 code (which forces most clients to show an authentication dialog). The capabilities documents contain the full list of layers. DescribeFeatureType and DescribeCoverage operations work successfully. This mode works fine with clients such as uDig or Google Earth. mixed Hides the layers the user cannot read from the capabilities documents, but triggers authentication for any other attempt to access the data or the metadata. This option is useful if you don't want the world to see the existence of some of your data, but you still want selected people to who have data access links to get the data after authentication."},{"location":"security/layer/#access_mode","title":"Access modes","text":"

                                                                                The access mode defines what level of access should be granted on a specific workspace/layer to a particular role. There are three types of access mode:

                                                                                • r---Read mode (read data from a workspace/layer)
                                                                                • w---Write mode (write data to a workspace/layer)
                                                                                • a---Admin mode (access and modify the configuration of a workspace/layer)

                                                                                Some notes on the above access modes:

                                                                                • Write does not imply Read, but Admin implies both Write and Read.
                                                                                • Read and Write apply to the data of a layer, while Admin applies to the configuration of a layer.
                                                                                • As Admin mode only refers to the configuration of the layer, it is not required for any OGC service request.

                                                                                Note

                                                                                Currently, it is possible to assign Admin permission only to an entire workspace, and not to specific layers.

                                                                                "},{"location":"security/layer/#examples","title":"Examples","text":"

                                                                                The following examples illustrate some possible layer restrictions and the corresponding rules.

                                                                                "},{"location":"security/layer/#protecting-a-single-workspace-and-a-single-layer","title":"Protecting a single workspace and a single layer","text":"

                                                                                The following example demonstrates how to configure GeoServer as a primarily a read-only server:

                                                                                *.*.r=*\n*.*.w=NO_ONE\nprivate.*.r=TRUSTED_ROLE\nprivate.*.w=TRUSTED_ROLE\ntopp.congress_district.w=STATE_LEGISLATORS\n

                                                                                The mapping of roles to permissions is as follows:

                                                                                Role private.* topp.* topp.congress_district (all other workspaces) NO_ONE (none) w (none) w TRUSTED_ROLE r/w r r r STATE_LEGISLATORS (none) r r/w r (All other users) (none) r r r

                                                                                Note

                                                                                Specific workspace rule private.*.r=TRUSTED_ROLE will take precedence over the more generic rule *.*.r=*. When a request is made to read a layer private:vulnerable_infrastructure the most specific rule available is used to control access. In this case the workspace rule private.*.r=TRUSTED_ROLE is the most specific and only users that have TRUSTED_ROLE will be granted r access and be able to read the private:vulnerable_infrastructure layer. Other users that do not have the TRUSTED_ROLE will not be granted r access and will be unable to access the private:vulnerable_infrastructure layer.

                                                                                "},{"location":"security/layer/#locking-down-geoserver","title":"Locking down GeoServer","text":"

                                                                                The following example demonstrates how to lock down GeoServer:

                                                                                *.*.r=TRUSTED_ROLE\n*.*.w=TRUSTED_ROLE\ntopp.*.r=*\narmy.*.r=MILITARY_ROLE,TRUSTED_ROLE\narmy.*.w=MILITARY_ROLE,TRUSTED_ROLE\n

                                                                                The mapping of roles to permissions is as follows:

                                                                                Role topp.* army.* (All other workspaces) TRUSTED_ROLE r/w r/w r/w MILITARY_ROLE r r/w (none) (All other users) r (none) (none)"},{"location":"security/layer/#providing-restricted-administrative-access","title":"Providing restricted administrative access","text":"

                                                                                The following provides administrative access on a single workspace to a specific role, in additional to the full administrator role:

                                                                                *.*.a=ROLE_ADMINISTRATOR\ntopp.*.a=ROLE_TOPP_ADMIN,ROLE_ADMINISTRATOR\n
                                                                                "},{"location":"security/layer/#managing-multi-level-permissions","title":"Managing multi-level permissions","text":"

                                                                                The following example demonstrates how to configure GeoServer with global-, workspace--, and layer-level permissions:

                                                                                *.*.r=TRUSTED_ROLE\n*.*.w=NO_ONE\ntopp.*.r=*\ntopp.states.r=USA_CITIZEN_ROLE,LAND_MANAGER_ROLE,TRUSTED_ROLE\ntopp.states.w=NO_ONE\ntopp.poly_landmarks.w=LAND_MANAGER_ROLE\ntopp.military_bases.r=MILITARY_ROLE\ntopp.military_bases.w=MILITARY_ROLE\n

                                                                                The mapping of roles to permissions is as follows:

                                                                                Role topp.states topp.poly_landmarks topp.military_bases topp.(all other layers) (All other workspaces) NO_ONE w r (none) w w TRUSTED_ROLE r r (none) r r MILITARY_ROLE (none) r r/w r (none) USA_CITIZEN_ROLE r r (none) r (none) LAND_MANAGER_ROLE r r/w (none) r (none) (All other users) (none) r (none) r (none)

                                                                                Note

                                                                                The entry topp.states.w=NO_ONE is not required because this permission would be inherited from the global level (the entry *.*.w=NO_ONE).

                                                                                "},{"location":"security/layer/#invalid-configuration","title":"Invalid configuration","text":"

                                                                                The following examples are invalid because the workspace, layer, and permission combinations are not unique:

                                                                                topp.state.rw=ROLE1\ntopp.state.rw=ROLE2,ROLE3\n
                                                                                "},{"location":"security/layer/#security-by-layer-group-in-wms","title":"Security by layer group in WMS","text":"

                                                                                To clarify, lets assume the following starting situation, in which all layers and groups are visible:

                                                                                root\n+- namedTreeGroupA\n|   |   ws1:layerA\n|   \u2514   ws2:layerB\n+- namedTreeGroupB\n|   |   ws2:layerB\n|   \u2514   ws1:layerC\n+- layerD\n+- singleGroupC (contains ws1:layerA and layerD when requested)\n

                                                                                Here are a few examples of how the structure changes based on different security rules.

                                                                                • Denying access to namedTreeGroupA by:

                                                                                  namedTreeGroupA.r=ROLE_PRIVATE\n

                                                                                  Will give the following capabilities tree to anonymous users:

                                                                                  root\n+- namedTreeGroupB\n|   |   ws2:layerB\n|   \u2514   ws1:layerC\n+- layerD\n+- singleGroupC (contains only layerD when requested)\n
                                                                                • Denying access to namedTreeGroupB by :

                                                                                  namedTreeGroupB.r=ROLE_PRIVATE\n

                                                                                  Will give the following capabilities tree to anonymous users:

                                                                                  root\n+- namedTreeGroupA\n|   |   ws1:layerA\n|   \u2514   ws2:layerB\n+- layerD\n+- singleGroupC (contains ws1:layerA and layerD when requested)\n
                                                                                • Denying access to singleGroupC by:

                                                                                  singleGroupC.r=ROLE_PRIVATE\n

                                                                                  Will give the following capabilities tree to anonymous users:

                                                                                  root\n+- namedTreeGroupA\n|   |   ws1:layerA\n|   \u2514   ws2:layerB\n+- namedTreeGroupB\n|   |   ws2:layerB\n|   \u2514   ws1:layerC\n+- layerD\n
                                                                                • Denying access to everything, but allowing explicit access to namedTreeGroupA by:

                                                                                  nameTreeGroupA.r=*\n*.*.r=PRIVATE\n*.*.w=PRIVATE\n

                                                                                  Will give the following capabilities tree to anonymous users:

                                                                                  root\n+- namedTreeGroupA\n    |   ws1:layerA\n    \u2514   ws2:layerB\n
                                                                                • Denying access to nameTreeGroupA and namedTreeGroupB but explicitly allowing access to ws1:layerA:

                                                                                  namedTreeGroupA.r=ROLE_PRIVATE\nnamedTreeGroupB.r=ROLE_PRIVATE\nws1.layerA.r=*\n

                                                                                  Will give the following capabilities tree to anonymous users (notice how ws1:layerA popped up to the root):

                                                                                  root\n+- ws1:layerA\n+- layerD\n
                                                                                • Denying access to nameTreeGroupA and namedTreeGroupB but explicitly allowing all layers in ws2 (a workspace rule overrides global groups ones):

                                                                                  namedTreeGroupA.r=ROLE_PRIVATE\nnamedTreeGroupB.r=ROLE_PRIVATE\nws2.*.r=*\n

                                                                                  Will give the following capabilities tree to anonymous users (notice how ws1:layerB popped up to the root):

                                                                                  root\n+- ws2:layerB\n+- layerD\n+- singleGroupC\n
                                                                                "},{"location":"security/passwd/","title":"Passwords","text":"

                                                                                Passwords are a central aspect of any security system. This section describes how GeoServer handles passwords.

                                                                                "},{"location":"security/passwd/#security_passwd_encryption","title":"Password encryption","text":"

                                                                                A GeoServer configuration stores two types of passwords:

                                                                                • Passwords for user accounts to access GeoServer resources
                                                                                • Passwords used internally for accessing external services such as databases and cascading OGC services

                                                                                As these passwords are typically stored on disk it is strongly recommended that they be encrypted and not stored as human-readable text. GeoServer security provides four schemes for encrypting passwords: empty, plain text, Digest, and Password-based encryption (PBE).

                                                                                The password encryption scheme is specified as a global setting that affects the encryption of passwords used for external resources, and as an encryption scheme for each user/group service. The encryption scheme for external resources has to be reversible, while the user/group services can use any scheme.

                                                                                "},{"location":"security/passwd/#empty","title":"Empty","text":"

                                                                                The scheme is not reversible. Any password is encoded as an empty string, and as a consequence it is not possible to recalculate the plain text password. This scheme is used for user/group services in combination with an authentication mechanism using a back end system. Examples are user name/password authentication against a LDAP server or a JDBC database. In these scenarios, storing passwords locally to GeoServer does not make sense.

                                                                                "},{"location":"security/passwd/#plain-text","title":"Plain text","text":"

                                                                                Plain text passwords provide no encryption at all. In this case, passwords are human-readable by anyone who has access to the file system. For obvious reasons, this is not recommended for any but the most basic test server. A password mypassword is encoded as plain:mypassword, the prefix uniquely describing the algorithm used for encoding/decoding.

                                                                                "},{"location":"security/passwd/#digest","title":"Digest","text":"

                                                                                Digest encryption is not reversible. It applies, 100,000 times through an iterative process, a SHA-256 cryptographic hash function to passwords. This scheme is \"one-way\" in that it is virtually impossible to reverse and obtain the original password from its hashed representation. Please see the section on Reversible encryption for more information on reversibility.

                                                                                To protect from well known attacks, a random value called a salt is added to the password when generating the key. For each digesting, a separate random salt is used. Digesting the same password twice results in different hashed representations.

                                                                                As an example, the password geoserver is digested to digest1:YgaweuS60t+mJNobGlf9hzUC6g7gGTtPEu0TlnUxFlv0fYtBuTsQDzZcBM4AfZHd. digest1 indicates the usage of digesting. The hashed representation and the salt are base 64 encoded.

                                                                                "},{"location":"security/passwd/#password-based-encryption","title":"Password-based encryption","text":"

                                                                                Password-based encryption (PBE) normally employs a user-supplied password to generate an encryption key. This scheme is reversible. A random salt described in the previous section is used.

                                                                                Note

                                                                                The system never uses passwords specified by users because these passwords tend to be weak. Passwords used for encryption are generated using a secure random generator and stored in the GeoServer key store. The number of possible passwords is 2\\^260 .

                                                                                GeoServer supports two forms of PBE. Weak PBE (the GeoServer default) uses a basic encryption method that is relatively easy to crack. The encryption key is derived from the password using MD5 1000 times iteratively. The encryption algorithm itself is DES (Data Encryption Standard). DES has an effective key length of 56 bits, which is not really a challenge for computer systems in these days.

                                                                                Strong PBE uses a much stronger encryption method based on an AES 256-bit algorithm with CBC. The key length is 256 bit and is derived using SHA-256 instead of MD5. Using Strong PBE is highly recommended.

                                                                                As an example, the password geoserver is encrypted to crypt1:KWhO7jrTz/Gi0oTQRKsVeCmWIZY5VZaD. crypt1 indicates the usage of Weak PBE. The prefix for Strong PBE is crypt2. The ciphertext and the salt are base 64 encoded.

                                                                                "},{"location":"security/passwd/#security_passwd_reversible","title":"Reversible encryption","text":"

                                                                                Password encryption methods can be reversible, meaning that it is possible (and desirable) to obtain the plain-text password from its encrypted version. Reversible passwords are necessary for database connections or external OGC services such as cascading WMS and cascading WFS, since GeoServer must be able to decode the encrypted password and pass it to the external service. Plain text and PBE passwords are reversible.

                                                                                Non-reversible passwords provide the highest level of security, and therefore should be used for user accounts and wherever else possible. Using password digesting is highly recommended, the installation of the unrestricted policy files is not required.

                                                                                "},{"location":"security/passwd/#security_passwd_keystore","title":"Secret keys and the keystore","text":"

                                                                                For a reversible password to provide a meaningful level of security, access to the password must be restricted in some way. In GeoServer, encrypting and decrypting passwords involves the generation of secret shared keys, stored in a typical Java keystore. GeoServer uses its own keystore for this purpose named geoserver.jceks which is located in the security directory in the GeoServer data directory. This file is stored in the JCEKS format rather than the default JKS. JKS does not support storing shared keys.

                                                                                The GeoServer keystore is password protected with a Keystore password. It is possible to access the contents of the keystore with external tools such as keytool. For example, this following command would prompt for the keystore password and list the contents of the keystore:

                                                                                $ keytool -list -keystore geoserver.jceks -storetype \"JCEKS\"\n
                                                                                "},{"location":"security/passwd/#security_master_passwd","title":"Keystore password","text":"

                                                                                It is also possible to set a keystore password for GeoServer. This password serves two purposes:

                                                                                • Protect access to the keystore
                                                                                • Protect access to the GeoServer Root account

                                                                                By default, the keystore password is generated and stored in a file named security/masterpw.info using plain text. When upgrading from an existing GeoServer data directory (versions 2.1.x and lower), the algorithm attempts to figure out the password of a user with the role ROLE_ADMINISTRATOR. If such a password is found and the password length is 8 characters at minimum, GeoServer uses this password as keystore password. Again, the name of the chosen user is found in security/masterpw.info.

                                                                                Warning

                                                                                The file security/masterpw.info is a security risk. The administrator should read this file and verify the keystore password by logging on GeoServer as the root user. On success, this file should be removed.

                                                                                Warning

                                                                                The first thing an Administrator of the System should do is dump the keystore Password generated by GeoServer, store it somewhere not accessible by anyone, and delete security/masterpw.info or whatever file you dumped the password to.

                                                                                Refer to Active keystore password provider for information on how to change the keystore password.

                                                                                Note

                                                                                By default login to the Admin GUI and REST APIs using the Keystore Password is disabled. In order to enable it you will need to manually change the Keystore Password Provider config.xml, usually located in security/masterpw/default/config.xml, by adding the following statement:

                                                                                ``<loginEnabled>true</loginEnabled>``\n
                                                                                "},{"location":"security/passwd/#security_passwd_policy","title":"Password policies","text":"

                                                                                A password policy defines constraints on passwords such as password length, case, and required mix of character classes. Password policies are specified when adding User/group services and are used to constrain passwords when creating new users and when changing passwords of existing users.

                                                                                Each user/group service uses a password policy to enforce these rules. The default GeoServer password policy implementation supports the following optional constraints:

                                                                                • Passwords must contain at least one number
                                                                                • Passwords must contain at least one upper case letter
                                                                                • Passwords must contain at least one lower case letter
                                                                                • Password minimum length
                                                                                • Password maximum length
                                                                                "},{"location":"security/passwd/#parametrized-passwords","title":"Parametrized Passwords","text":"

                                                                                It is possible to parametrize users' passwords in a similar way to the catalog settings (see Parameterize catalog settings). Parametrization is supported when the encryption method used to store the place holder in the password field is plain text or is reversible (pbe, strong pbe). Non reversible encoding for the placeholder (e.g. digest) is not supported. On the contrary the actual value can be defined in the geoserver-environment.properties with any password encoding method supported by GeoServer. Examples are provided below:

                                                                                pwd.one=plain:clear_text_password\npwd.two=digest1:D9miJH/hVgfxZJscMafEtbtliG0ROxhLfsznyWfG38X2pda2JOSV4POi55PQI4tw\npwd.three=crypt1:xZJscMafEtbtliG0ROxhLfsznyWfG38X2pda2JOSV4POi55PQI4tw\n
                                                                                "},{"location":"security/rest/","title":"REST Security","text":"

                                                                                In addition to providing the ability to secure OWS style services, GeoServer also supports securing RESTful services.

                                                                                As with layer and service security, RESTful security configuration is based on security_roles. The mapping of request URI to role is defined in a file named rest.properties, located in the security directory of the GeoServer data directory.

                                                                                "},{"location":"security/rest/#syntax","title":"Syntax","text":"

                                                                                The following syntax defines access control rules for RESTful services (parameters in brackets [] are optional):

                                                                                uriPattern;method[,method,...]=role[,role,...]\n

                                                                                The parameters are:

                                                                                • uriPattern---ant pattern that matches a set of request URIs
                                                                                • method---HTTP request method, one of GET, POST, PUT, POST, DELETE, or HEAD
                                                                                • role---Name of a predefined role. The wildcard '* is used to indicate the permission is applied to all users, including anonymous users.

                                                                                Note

                                                                                • URI patterns should account for the first component of the rest path, usually rest or api
                                                                                • Method and role lists should not contain any spaces
                                                                                "},{"location":"security/rest/#security_rest_ant_patterns","title":"Ant patterns","text":"

                                                                                Ant patterns are commonly used for pattern matching directory and file paths. The examples section contains some basic instructions. The Apache ant user manual contains more sophisticated use cases.

                                                                                "},{"location":"security/rest/#security_rest_examples","title":"Examples","text":"

                                                                                Most of the examples in this section are specific to the GeoServer REST but any RESTful GeoServer service may be configured in the same manner.

                                                                                "},{"location":"security/rest/#allowing-only-authenticated-access","title":"Allowing only authenticated access","text":"

                                                                                The most secure configuration is one that forces any request to be authenticated. The following example locks down access to all requests:

                                                                                /**;GET,POST,PUT,DELETE=ROLE_ADMINISTRATOR\n

                                                                                A less restricting configuration locks down access to operations under the path /rest, but will allow anonymous access to requests that fall under other paths (for example /api):

                                                                                /rest/**;GET,POST,PUT,DELETE=ROLE_ADMINISTRATOR\n

                                                                                The following configuration is similar to the previous one except it grants access to a specific role rather than the administrator:

                                                                                /**;GET,POST,PUT,DELETE=ROLE_TRUSTED\n

                                                                                ROLE_TRUSTED is a role defined in users.properties.

                                                                                "},{"location":"security/rest/#providing-anonymous-read-only-access","title":"Providing anonymous read-only access","text":"

                                                                                The following configuration allows anonymous access when the GET (read) method is used but forces authentication for a POST, PUT, or DELETE (write):

                                                                                /**;GET=IS_AUTHENTICATED_ANONYMOUSLY\n/**;POST,PUT,DELETE=TRUSTED_ROLE\n
                                                                                "},{"location":"security/rest/#securing-a-specific-resource","title":"Securing a specific resource","text":"

                                                                                The following configuration forces authentication for access to a particular resource (in this case a feature type):

                                                                                /rest/**/states*;GET=TRUSTED_ROLE\n/rest/**;POST,PUT,DELETE=TRUSTED_ROLE\n

                                                                                The following secures access to a set of resources (in this case all data stores):

                                                                                /rest/**/datastores/*;GET=TRUSTED_ROLE\n/rest/**/datastores/*.*;GET=TRUSTED_ROLE\n/rest/**;POST,PUT,DELETE=TRUSTED_ROLE\n
                                                                                "},{"location":"security/root/","title":"Root account","text":"

                                                                                The highly configurable nature of GeoServer security may result in an administrator inadvertently disrupting normal authentication, essentially disabling all users including administrative accounts. For this reason, the GeoServer security subsystem contains a root account that is always active, regardless of the state of the security configuration. Much like its UNIX-style counterpart, this account provides \"super user\" status, and is meant to provide an alternative access method for fixing configuration issues.

                                                                                The username for the root account is root. Its name cannot be changed and the password for the root account is the Keystore password.

                                                                                "},{"location":"security/service/","title":"Service Security","text":"

                                                                                GeoServer supports access control at the service level, allowing for the locking down of service operations to only authenticated users who have been granted a particular role. There are two main categories of services in GeoServer. The first is OWS services such as WMS and WFS. The second are RESTful services, such as the GeoServer REST.

                                                                                Note

                                                                                Service-level security and Layer security cannot be combined. For example, it is not possible to specify access to a specific OWS service only for one specific layer.

                                                                                "},{"location":"security/service/#ows-services","title":"OWS services","text":"

                                                                                OWS services support setting security access constraints globally for a particular service, or to a specific operation within that service. A few examples include:

                                                                                • Securing the entire WFS service so only authenticated users have access to all WFS operations.
                                                                                • Allowing anonymous access to read-only WFS operations such as GetCapabilities, but securing write operations such as Transaction.
                                                                                • Disabling the WFS service in effect by securing all operations and not applying the appropriate roles to any users.

                                                                                OWS service security access rules are specified in a file named services.properties, located in the security directory in the GeoServer data directory. The file contains a list of rules that map service operations to defined roles. The syntax for specifying rules is as follows:

                                                                                <service>.<operation|*>=<role>[,<role2>,...]\n

                                                                                The parameters include:

                                                                                • []---Denotes optional parameters
                                                                                • |---Denotes \"or\"
                                                                                • service---Identifier of an OGC service, such as wfs, wms, or wcs
                                                                                • operation---Any operation supported by the service, examples include GetFeature for WFS, GetMap for WMS, * for all operations
                                                                                • role[,role2,...]---List of predefined role names

                                                                                Note

                                                                                It is important that roles specified are actually linked to a user, otherwise the whole service/operation will be accessible to no one except for the Root account. However in some cases this may be the desired effect.

                                                                                The default service security configuration in GeoServer contains no rules and allows any anonymous user to access any operation of any service. The following are some examples of desired security restrictions and the corresponding rules.

                                                                                "},{"location":"security/service/#securing-the-entire-wfs-service","title":"Securing the entire WFS service","text":"

                                                                                This rule grants access to any WFS operation only to authenticated users that have been granted the ROLE_WFS role:

                                                                                wfs.*=ROLE_WFS\n
                                                                                "},{"location":"security/service/#anonymous-wfs-access-only-for-read-only-operations","title":"Anonymous WFS access only for read-only operations","text":"

                                                                                This rule grants anonymous access to all WFS operations (such as GetCapabilities and GetFeature) but restricts Transaction requests to authenticated users that have been granted the ROLE_WFS_WRITE role:

                                                                                wfs.Transaction=ROLE_WFS_WRITE\n
                                                                                "},{"location":"security/service/#securing-data-accessing-wfs-operations-and-write-operations","title":"Securing data-accessing WFS operations and write operations","text":"

                                                                                Used in conjunction, these two rules grant anonymous access to GetCapabilities and DescribeFeatureType, forcing the user to authenticate for the GetFeature operation (must be granted the ROLE_WFS_READ role), and to authenticate to perform transactions (must be granted the ROLE_WFS_WRITE role:

                                                                                wfs.GetFeature=ROLE_WFS_READ\nwfs.Transaction=ROLE_WFS_WRITE\n

                                                                                Note this example does not specify whether a user accessing Transactions would also have access to GetFeature.

                                                                                "},{"location":"security/service/#security_service_rest","title":"REST services","text":"

                                                                                In addition to providing the ability to secure OWS services, GeoServer also allows for the securing of RESTful services.

                                                                                REST service security access rules are specified in a file named rest.properties, located in the security directory of the GeoServer data directory. This file contains a list of rules mapping request URIs to defined roles. The rule syntax is as follows:

                                                                                <uriPattern>;<method>[,<method>,...]=<role>[,<role>,...]\n

                                                                                The parameters include:

                                                                                • []---Denote optional parameters
                                                                                • uriPattern---The ant pattern that matches a set of request URIs
                                                                                • method---HTTP request method, one of GET, POST, PUT, POST, DELETE, or HEAD
                                                                                • role---Name of a predefined role. The wildcard * is used to indicate all users, including anonymous users.

                                                                                Note

                                                                                • URI patterns should account for the first component of the rest path, usually rest or api
                                                                                • method and role lists should not contain any spaces
                                                                                "},{"location":"security/service/#security_service_ant_patterns","title":"Ant patterns","text":"

                                                                                Ant patterns are commonly used for pattern matching directory and file paths. The following examples provide some basic instructions. The Apache ant user manual contains more sophisticated use cases.

                                                                                These examples are specific to GeoServer REST, but any RESTful GeoServer service could be configured in the same manner.

                                                                                "},{"location":"security/service/#disabling-anonymous-access-to-services","title":"Disabling anonymous access to services","text":"

                                                                                The most secure of configurations is one that forces any request, REST or otherwise, to be authenticated. The following will lock down access to all requests to users that are granted the ROLE_ADMINISTRATOR role:

                                                                                /**;GET,POST,PUT,DELETE=ROLE_ADMINISTRATOR\n

                                                                                A less restricting configuration locks down access to operations under the path /rest to users granted the ROLE_ADMINISTRATOR role, but will allow anonymous access to requests that fall under other paths (for example /api):

                                                                                /rest/**;GET,POST,PUT,DELETE=ROLE_ADMINISTRATOR\n
                                                                                "},{"location":"security/service/#allowing-anonymous-read-only-access","title":"Allowing anonymous read-only access","text":"

                                                                                The following configuration grants anonymous access when the GET method is used, but forces authentication for a POST, PUT, or DELETE method:

                                                                                /**;GET=IS_AUTHENTICATED_ANONYMOUSLY\n/**;POST,PUT,DELETE=TRUSTED_ROLE\n
                                                                                "},{"location":"security/service/#securing-a-specific-resource","title":"Securing a specific resource","text":"

                                                                                The following configuration forces authentication for access to a particular resource (in this case the states feature type):

                                                                                /rest/**/states*;GET=TRUSTED_ROLE\n/rest/**;POST,PUT,DELETE=TRUSTED_ROLE\n

                                                                                The following secures access to a set of resources (in this case all data stores).:

                                                                                /rest/**/datastores/*;GET=TRUSTED_ROLE\n/rest/**/datastores/*.*;GET=TRUSTED_ROLE\n/rest/**;POST,PUT,DELETE=TRUSTED_ROLE\n

                                                                                Note the trailing wildcards /* and /*.*.

                                                                                "},{"location":"security/urlchecks/","title":"URL Checks","text":"

                                                                                The URL External Access Checks page controls the checks that are performed on user provided URLs that GeoServer will use to access remote resources.

                                                                                Currently, the checks are performed on the following functionality:

                                                                                • WMS GetMap, GetFeatureInfo and GetLegendGraphic requests with remote SLD stylesheets (sld parameter)
                                                                                • Remote icons referenced by styles (access to icons in the data directory is always allowed)
                                                                                • WMS GetMap and GetFeatureInfo requests in feature portrayal mode (REMOTE_OWS and REMOTE_OWS_TYPE parameters)
                                                                                • WPS remote inputs, either as GET or POST requests

                                                                                External URLs configured by admins in the GUI (e.g. WFS, cascaded WMS & WMTS data stores) are not subject to this check.

                                                                                Please refer back to this page for any additional remote service access checks added in the future.

                                                                                "},{"location":"security/urlchecks/#configuration-of-url-checks","title":"Configuration of URL checks","text":"

                                                                                Navigate to Data > URL Checks page to manage and configure URL Checks.

                                                                                URL Checks table

                                                                                Use the Enable/Disable URL Checks enable this safety feature:

                                                                                • When the URL checks are enabled checkbox is enabled, URL checks are performed to limit GeoServer access to remote resources as outlined above.

                                                                                  Enabling URL checks is recommended to limit normal Open Web Service protocols interaction being used for Cross Site Scripting attacks.

                                                                                • When checkbox disabled, URL checks are NOT enabled, GeoServer is provided unrestricted access to remote resources.

                                                                                  Disabling URL Checks is not a secure or recommended setting.

                                                                                "},{"location":"security/urlchecks/#adding-a-regular-expression-based-check","title":"Adding a regular expression based check","text":"

                                                                                The buttons for adding and removing URL checks can be found at the top of the URL Check list table.

                                                                                To add a URL Check, press the Add new URL check button. You will be prompted to enter URL check details (as described in Editing a URL Check below).

                                                                                "},{"location":"security/urlchecks/#removing-a-regular-expression-based-check","title":"Removing a regular expression based check","text":"

                                                                                To remove a URL Check, select the checkbox next to one or more rows in the URL Check list table. Press the Remove selected URL checks button to remove. You will be asked to confirm or cancel the removal. Pressing OK removes the selected URL Checks.

                                                                                "},{"location":"security/urlchecks/#security_urlchecks_edit","title":"Editing a URL Check","text":"

                                                                                Regular Expression URL checks can be configured, with the following parameters for each check:

                                                                                Field Description Name Name for the check, used to identify it in the list. Description Description of the check, for later reference. Regular Expression A regular expression used to match allowed URLs Enabled Check box to enable or disable the check

                                                                                Configure Regular Expression URL check

                                                                                "},{"location":"security/urlchecks/#testing-url-checks","title":"Testing URL checks","text":"

                                                                                The Test URL Checks with external URL form allows a URL to be checked, reporting if access is allowed or disallowed.

                                                                                Test URL Checks form:

                                                                                Field Description URL to check Supply URL of external resource to check if access is allowed

                                                                                Press the Test URL button to perform the checks. If at least one URL Check matches the URL, it will be allowed and the test will indicate the URL Check permitting access. Otherwise it will be rejected and the test will indicate that no URL Check matched.

                                                                                Test URL Checks with external URL

                                                                                "},{"location":"security/urlchecks/#example-regex-patterns","title":"Example RegEx Patterns","text":"

                                                                                The most common pattern allows matching a given host name to allow external graphics from a remote server. This pattern uses ^ to mark the start, the host URL, .* to match anything, and $ to end - as shown in the in following pattern:

                                                                                ^https://styles\\.server\\.net/.*$

                                                                                https://styles.server.net/logo.png\n

                                                                                To allow external graphics from a specific directory on a remote server:

                                                                                ^https://styles\\.server\\.net/icons/.*$

                                                                                https://styles.server.net/icons/forest.png\n

                                                                                When working with external graphics making use of SVG parameters use (\\?.*)?$ to optionally allow any query parameters after ?:

                                                                                ^https://styles\\.server\\.net/icons/.*(\\?.*)?$

                                                                                https://styles.server.net/icons/forest.png\nhttps://styles.server.net/icons/forest.svg?color=darkgreen\n

                                                                                When obtaining content from an API \\?.* is used (as there is no need to support relative paths). As an example /geoserver/ows\\? is used below to access the GeoServer Open Web Service API:

                                                                                ^https?://localhost:8080/geoserver/ows\\?.*$

                                                                                http://localhost:8080/geoserver/ows?service=WMS&version=1.3.0&request=GetCapabilities\n

                                                                                To allow for GeoServer virtual web services (\\w+/)? is used for optional workspace name:

                                                                                ^https?://localhost:8080/geoserver/(\\w+/)?ows\\?.*$

                                                                                http://localhost:8080/geoserver/ows?service=WMS&version=1.3.0&request=GetCapabilities\nhttp://localhost:8080/geoserver/ne/ows?service=WMS&version=1.3.0&request=GetCapabilities\n

                                                                                To limit to Web Feature Service ?.*SERVICE=WFS.* is used to restrict query parameter:

                                                                                ^https?://localhost:8080/geoserver/(\\w+/)?ows\\?.*SERVICE=WFS.*?$

                                                                                http://localhost:8080/geoserver/tiger/ows?SERVICE=WFS&VERSION=1.0.0&REQUEST=GetFeature&TYPENAME=giant_polygon\n

                                                                                To allowing WMS REMOTE_OWS data access to an external GeoServer WFS service:

                                                                                ^https://mapping\\.server\\.net/geoserver/(\\w+/)?ows\\?.*SERVICE=WFS.*$

                                                                                https://mapping.server.net/geoserver/ows?SERVICE=WFS&VERSION=1.0.0&REQUEST=GetFeature&TYPENAME=roads\n

                                                                                To allow external graphic access to a remote GeoServer icons:

                                                                                ^https://mapping\\.server\\.net/geoserver/styles/.*(\\?.*)?$

                                                                                https://mapping.server.net/geoserver/styles/grass_fill.png\nhttps://mapping.server.net/geoserver/styles/ne/airport.svg?fill=gray\n

                                                                                File paths can also be checked:

                                                                                ^/var/opt/geoserver/data/.*$

                                                                                /var/opt/geoserver/data/example.tiff\n

                                                                                ^D:\\\\\\\\data\\\\.*$

                                                                                D:\\\\data\\example.tiff\n

                                                                                Note

                                                                                The locations being checked are normalized making it easier to write RegEx patterns:

                                                                                • URLs paths have been normalized to remove any redundant \\. or \\.. paths have been removed
                                                                                • File URLs have been normalized so that file:/ is represented as file:///
                                                                                • File paths have been normalized using / on Linux and \\ on Windows

                                                                                Note

                                                                                Web sites are available to help define a valid Java regular expression pattern. These tools can be used to interpret, explain and test regular expressions. For example:

                                                                                • https://regex101.com/ (enable the Java 8 flavor)
                                                                                • https://www.freeformatter.com/java-regex-tester.html
                                                                                "},{"location":"security/auth/","title":"Authentication","text":"

                                                                                There are three sets of GeoServer resources involved in authentication:

                                                                                • The Web administration interface (also known as web admin)
                                                                                • OWS services (such as WFS and WMS)
                                                                                • REST services

                                                                                The following sections describe how each set of GeoServer resources administers authentication. To configure the authentication settings and providers, please see the section on Authentication in the Web administration interface.

                                                                                • Authentication chain
                                                                                • Authenticating to the Web Admin Interface
                                                                                • Authentication to OWS and REST services
                                                                                • Authentication providers
                                                                                "},{"location":"security/auth/chain/","title":"Authentication chain","text":"

                                                                                Understanding the authentication chain helps explain how GeoServer authentication works. The authentication chain processes requests and applies certain authentication mechanisms. Examples of authentication mechanisms include:

                                                                                • Username/password---Performs authentication by looking up user information in an external user database
                                                                                • Browser cookie---Performs authentication by recognizing previously sent browser cookies (also known as \"Remember Me\")
                                                                                • LDAP---Performs authentication against an LDAP database
                                                                                • Anonymous---Essentially performs no authentication and allows a request to proceed without any credentials

                                                                                Multiple authentication mechanisms may be active within GeoServer at a given time. The following figure illustrates the flow of a generic request.

                                                                                Flow of a request through the authentication system

                                                                                Before dispatching a request to the appropriate service or handler, GeoServer first filters the request through the authentication chain. The request is passed to each mechanism in the chain in order, and each is given the chance to authenticate the request. If one of the mechanisms in the chain is able to successfully authenticate, the request moves to normal processing. Otherwise the request is not routed any further and an authorization error (usually a HTTP 401) is returned to the user.

                                                                                "},{"location":"security/auth/chain/#filter-chain-and-provider-chain","title":"Filter chain and provider chain","text":"

                                                                                In the case of GeoServer, the authentication chain is actually made up of two chains: a filter chain, which determine if further authentication of a request is required, and a provider chain, which performs the actual authentication.

                                                                                Detail of authentication chain, showing filter chain and provider chain

                                                                                The filter chain performs a variety of tasks, including:

                                                                                • Gathering user credentials from a request, for example from Basic and Digest Authentication headers
                                                                                • Handling events such as ending the session (logging out), or setting the \"Remember Me\" browser cookie
                                                                                • Performing session integration, detecting existing sessions and creating new sessions if necessary
                                                                                • Invoking the authentication provider chain to perform actual authentication

                                                                                The filter chain is actually processed twice, before and after the request is handled.

                                                                                The provider chain is concerned solely with performing the underlying authentication of a request. It is invoked by the filter chain when a filter determines that authentication is required.

                                                                                "},{"location":"security/auth/chain/#filter-chain-by-request-type","title":"Filter chain by request type","text":"

                                                                                A different filter chain can be applied to each different type of request in GeoServer. This happens because the administrator can configure a list of different filter chains and a matching rule for each of them. Only the first matching chain of the configured ordered list will be applied to any given request.

                                                                                Matching rules can be applied to:
                                                                                • HTTP Method (GET, POST, etc.)
                                                                                • one or more ANT patterns for the path section of the request (e.g /wms/**); if more than one pattern (comma delimited) is specified, any of them will match
                                                                                • an optional regular expression to match parameters on the query string, for one or more of the specified ANT pattern; if the path matches, also the query string is checked for matching; the regular expression can be specified after the ANT pattern, with a pipe (|) separator
                                                                                ANT Patterns support the following wildcards:
                                                                                • ? matches one character
                                                                                  • matches zero or more characters
                                                                                • ** matches zero or more 'directories' in a path

                                                                                Query String regular expressions will match the full query string (\\^ and \\$ terminators are automatically appended), so to match only part of it, remember to prefix and postfix the expression with . (e.g. .request=getcapabilities.*)

                                                                                "},{"location":"security/auth/chain/#examples-of-rules-ant-patterns-and-query-string-regular-expressions","title":"Examples of rules (ANT patterns and query string regular expressions)","text":"Pattern Description /wms, /wms/** simple ANT pattern /wms .request=GetMap. /wms (?=.request=getmap)(?=.format=image/png).* /wms (?=.request=getmap)(?!.format=image/png).*"},{"location":"security/auth/owsrest/","title":"Authentication to OWS and REST services","text":"

                                                                                OWS and REST services are stateless and have no inherent awareness of \"session\", so the authentication scheme for these services requires the client to supply credentials on every request. That said, \"session integration\" is supported, meaning that if a session already exists on the server (from a concurrent authenticated web admin session) it will be used for authentication. This scheme allows GeoServer to avoid the overhead of session creation for OWS and REST services.

                                                                                The default GeoServer configuration ships with support for HTTP Basic authentication for services.

                                                                                The typical process of authentication is as follows:

                                                                                1. User makes a service request without supplying any credentials
                                                                                2. If the user is accessing an unsecured resource, the request is handled normally
                                                                                3. If the user is accessing a secured resource:
                                                                                • An HTTP 401 status code is sent back to the client, typically forcing the client to prompt for credentials.
                                                                                • The service request is then repeated with the appropriate credentials included, usually in the HTTP header as with Basic Authentication.
                                                                                • If the user has sufficient privileges to access the resource the request is handled normally, otherwise, a HTTP 404 status code is returned to the client.
                                                                                1. Subsequent requests should include the original user credentials
                                                                                "},{"location":"security/auth/owsrest/#examples","title":"Examples","text":"

                                                                                The following describes the authentication chain for an OWS service:

                                                                                The OWS service authentication chain

                                                                                In this example the filter chain consists of three filters:

                                                                                • Session---Handles \"session integration\", recognizing existing sessions (but not creating new sessions)
                                                                                • Basic Auth---Extracts Basic Authentication credentials from request HTTP header
                                                                                • Anonymous---Handles anonymous access

                                                                                The provider chain is made up of two providers:

                                                                                • Root---Root account has a special \"super user\" provider. As this account is rarely used, this provider is rarely invoked.
                                                                                • Username/password---Performs username/password authentication against a user database

                                                                                To illustrate how the elements of the various chains work, here are some example OWS requests.

                                                                                "},{"location":"security/auth/owsrest/#anonymous-wms-getcapabilities-request","title":"Anonymous WMS GetCapabilities request","text":"

                                                                                This example shows the process for when a WMS client makes an anonymous GetCapabilities request.

                                                                                Authentication chain for a WMS client making an anonymous GetCapabilities request

                                                                                The Session filter looks for an existing session, but finds none, so processing continues. The Basic Auth filter looks for the Basic Authorization header in the request, but as the request is anonymous, the filter finds none. Finally, the Anonymous filter executes and authenticates the request anonymously. Since GetCapabilities is a \"discovery\" operation it is typically not locked down, even on a secure server. Assuming this is the case here, the anonymous request succeeds, returning the capabilities response to the client. The provider chain is not invoked.

                                                                                "},{"location":"security/auth/owsrest/#anonymous-wms-getmap-request-for-a-secured-layer","title":"Anonymous WMS GetMap request for a secured layer","text":"

                                                                                This example shows the process invoked when a WMS client makes an anonymous GetMap request for a secured layer

                                                                                The chain executes exactly as described above. The Session filter looks for an existing session, but finds none, so processing continues. The Basic Auth filter looks for the Basic Authorization header in the request, but as the request is anonymous, the filter finds none. Finally, the Anonymous filter executes and authenticates the request anonymously. However, in this case the layer being accessed is a secured resource, so the handling of the GetMap request fails. The server returns an exception accompanied with a HTTP 401 status code, which usually triggers the client presenting the user with a login dialog.

                                                                                "},{"location":"security/auth/owsrest/#wms-getmap-request-with-user-supplied-credentials","title":"WMS GetMap request with user-supplied credentials","text":"

                                                                                This example shows the process invoked when a WMS client gathers credentials from the user and reissues the previous request for a secured layer.

                                                                                Authentication chain for a WMS client making a GetMap request with user-supplied credentials

                                                                                The Session filter executes as described above, and does nothing. The Basic Auth filter finds the authorization header in the request, extracts the credentials for it, and invokes the provider chain. Processing moves to the Username/password provider that does the actual authentication. If the credentials have the necessary privileges to access the layer, the processing of the request continues normally and the GetMap request succeeds, returning the map response. If the credentials are not sufficient, the HTTP 401 status code will be supplied instead, which may again trigger the login dialog on the client side.

                                                                                "},{"location":"security/auth/providers/","title":"Authentication providers","text":"

                                                                                The following authentication providers are available in GeoServer:

                                                                                • Authentication of a username/password against a user/group service
                                                                                • Authentication against an LDAP server
                                                                                • Authentication by connecting to a database through JDBC
                                                                                "},{"location":"security/auth/providers/#security_auth_provider_userpasswd","title":"Username/password authentication","text":"

                                                                                Username and password authentication is the default authentication provider. It uses a user/group service to authenticate.

                                                                                The provider simply takes the username/password from an incoming request (such as a Basic Authentication request), then loads the user information from the user/group service and verifies the credentials.

                                                                                "},{"location":"security/auth/providers/#security_auth_provider_ldap","title":"LDAP authentication","text":"

                                                                                The LDAP authentication provider allows for authentication against a Lightweight Directory Access Protocol (LDAP) server. The provider takes the username/password from the incoming request and attempts to connect to the LDAP server with those credentials.

                                                                                Note

                                                                                Currently only LDAP Bind authentication is supported.

                                                                                "},{"location":"security/auth/providers/#role-assignment","title":"Role assignment","text":"

                                                                                The LDAP provider offers two options for role assignment for authenticated users:

                                                                                • Convert the user's LDAP groups into roles
                                                                                • Employ a user/group service

                                                                                The following LDAP database will illustrate the first option:

                                                                                dn: ou=people,dc=acme,dc=com\nobjectclass: organizationalUnit\nou: people\n\ndn: uid=bob,ou=people,dc=acme,dc=com\nobjectclass: person\nuid: bob\n\ndn: ou=groups,dc=acme,dc=com\nobjectclass: organizationalUnit\nou: groups\n\ndn: cn=workers,ou=groups,dc=acme,dc=com\nobjectclass: groupOfNames\ncn: users\nmember: uid=bob,ou=people,dc=acme,dc=com\n

                                                                                The above scenario defines a user with the uid of bob, and a group named workers of which bob is a member. After authentication, bob will be assigned the role ROLE_WORKERS. The role name is generated by concatenating ROLE_ with the name of the group in upper case.

                                                                                Note

                                                                                When the LDAP server doesn't allow searching in an anonymous context, the bindBeforeGroupSearch option should be enabled to avoid errors.

                                                                                In the case of using a user/group service, the user/group service is queried for the user following authentication, and the role assignment is performed by both the user/group service and the active role service. When using this option, any password defined for the user in the user/group service database is ignored.

                                                                                "},{"location":"security/auth/providers/#security_auth_provider_ldap_secure","title":"Secure LDAP connections","text":"

                                                                                There are two ways to create a secure LDAP connection with the server. The first is to directly specify a secure connection by using the ldaps protocol as part of the Server URL. This typically requires changing the connection port to port 636 rather than 389.

                                                                                The second method involves using STARTTLS (Transport Layer Security) to negotiate a secure connection over a non-secure one. The negotiation takes place over the non-secure URL using the \"ldap\" protocol on port 389. To use this option, the Use TLS flag must be set.

                                                                                Warning

                                                                                Using TLS for connections will prevent GeoServer from being able to pool LDAP connections. This means a new LDAP connection will be created and destroyed for each authentication, resulting in loss of performance.

                                                                                "},{"location":"security/auth/providers/#security_auth_provider_jdbc","title":"JDBC authentication","text":"

                                                                                The JDBC authentication provider authenticates by connecting to a database over JDBC.

                                                                                The provider takes the username/password from the incoming request and attempts to create a database connection using those credentials. Optionally the provider may use a user/group service to load user information after a successful authentication. In this context the user/group service will not be used for password verification, only for role assignment.

                                                                                Note

                                                                                To use the user/group service for password verification, please see the section on Username/password authentication.

                                                                                "},{"location":"security/auth/web/","title":"Authenticating to the Web Admin Interface","text":"

                                                                                The method of authenticating to the Web administration interface application is typical of most web applications that provide login capabilities. The application is based primarily on form-based authentication, in which a user authenticates through a form in a web browser. Upon successful authentication a session is created on the server, eliminating the need for a user to repeat the login process for each page they wish to access. An optional \"Remember Me\" setting is also supported which will store authentication information in a client-side cookie to allow the user to bypass the form-based authentication after the initial session has timed out.

                                                                                The typical process of authentication is as follows:

                                                                                1. User visits the home page of the web admin for the very first time, so neither a session or \"Remember Me\" cookie is present. In this case, the user is anonymously authenticated.
                                                                                2. User accesses a secured page and is presented with a login form.
                                                                                3. Upon successful login a session is created. Depending on the privileges of the account used to log in, the user will either be directed to the requested page or be redirected back to the home page.
                                                                                4. Upon subsequent requests to secured pages, the user is authenticated via browser session until the session expires or the user logs out.
                                                                                "},{"location":"security/auth/web/#examples","title":"Examples","text":"

                                                                                The following shows the default configuration of the authentication chain for the web admin.

                                                                                GeoServer authentication chain, with filter and provider chains

                                                                                In this example the filter chain is made up of the following filters:

                                                                                • Session---Handles session integration, recognizing existing sessions and creating new sessions on demand
                                                                                • Logout---Handles ending sessions (user logout)
                                                                                • Form login---Handles form logins
                                                                                • Remember Me---Handles \"Remember Me\" authentication, reading when the flag is set on a form login, creating the appropriate cookie, and recognizing the cookie on future requests
                                                                                • Anonymous---Handles anonymous access

                                                                                The provider chain is made up of two providers:

                                                                                • Root---The Root account has a special \"super user\" provider. As this account is rarely used, this provider is rarely invoked.
                                                                                • Username/password---Performs username/password authentication against a user database.

                                                                                To following example requests illustrate how the elements of the various chains work.

                                                                                "},{"location":"security/auth/web/#first-time-visit","title":"First time visit","text":"

                                                                                This example describes the process when a user visits the home page of the web admin for the first time.

                                                                                Authentication chain for a first time visit from a user

                                                                                The first filter to execute is the Session filter. It checks for an existing session, but finds none, so processing continues to the next filter in the chain. The Logout filter checks for the case of a user logging out, which also is not the case, so processing continues. The Form login filter checks for a form login, and also finds none. The Remember Me filter determines if this request can be authenticated from a previous session cookie, but in this case it cannot. The final filter to execute is the Anonymous filter which checks if the user specified any credentials. In this case the user has not provided any credentials, so the request is authenticated anonymously. Since no authentication is required to view the home page, the provider chain is not invoked.

                                                                                The last response to the request directs the user to the home page.

                                                                                "},{"location":"security/auth/web/#user-logs-on","title":"User logs on","text":"

                                                                                This examples describes the process invoked when a user logs on to the web admin via the login form.

                                                                                Authentication chain for a user logging in

                                                                                The Session filter finds no existing session, and processing continues. The Logout filter checks for a logout request, finds none, and continues. The Form login filter recognizes the request as a form login and begins the authentication process. It extracts the username and password from the request and invokes the provider chain.

                                                                                In the provider chain, the Root provider checks for the root account login, but doesn't find it so processing continues to the next provider. The Username/password provider checks if the supplied credentials are valid. If they are valid the authentication succeeds, user is redirected to the home page and is considered to be logged on. During the post-processing step the Session filter recognizes that a successful authentication has taken place and creates a new session.

                                                                                If the credentials are invalid, the user will be returned to the login form page and asked to try again.

                                                                                "},{"location":"security/auth/web/#user-visits-another-page","title":"User visits another page","text":"

                                                                                This example describes the process invoked when a user who is already logged on visits another page in the web admin.

                                                                                Authentication chain for a user visiting another page after logging in

                                                                                The Session filter executes and finds an existing session that is still valid. The session contains the authentication details and no further chain processing is required. The response is the page requested by the user.

                                                                                "},{"location":"security/auth/web/#user-returns-after-session-time-out","title":"User returns after session time out","text":"

                                                                                This example describes the process invoked when a user returns to the web admin after the previously created session has timed out.

                                                                                A session will time out after a certain period of time. When the user returns to the web admin, this becomes essentially the same chain of events as the user visiting the web app for the first time (as described previously). The chain proceeds to the Anonymous filter that authenticates anonymously. Since the page requested is likely to be a page that requires authentication, the user is redirected to the home page and is not logged on.

                                                                                "},{"location":"security/auth/web/#user-logs-on-with-remember-me-flag-set","title":"User logs on with \"Remember Me\" flag set","text":"

                                                                                This example describes the process for logging on with the \"Remember Me\" flag set.

                                                                                The chain of events for logging on with \"Remember Me\" set is identical to the process for when the flag is not set, except that after the successful authentication the Form login filter recognizes the \"Remember Me\" flag and triggers the creation of the browser cookie used to persist the authentication information. The user is now logged on and is directed to the home page.

                                                                                "},{"location":"security/auth/web/#user-returns-after-session-time-out-with-remember-me","title":"User returns after session time out (with \"Remember Me\")","text":"

                                                                                This example describes the process invoked when the user returns to the web admin after a period of inactivity, while the \"Remember Me\" flag is set.

                                                                                Authentication chain for a user returning after session time out with the \"Remember Me\" flag

                                                                                Even though the \"Remember Me\" flag is set, the user's session on the server will still time out as normal. As such, the chain proceeds accordingly through the filters, starting with the Session filter, which finds no valid session. The Logout and Form login filters do not apply here. The Remember Me filter recognizes the browser cookie and is able to authenticate the request. The user is directed to whatever page was accessed and remains logged on.

                                                                                "},{"location":"security/tutorials/","title":"Tutorials","text":"
                                                                                • Authentication with LDAP
                                                                                • Authentication with LDAP against ActiveDirectory
                                                                                • Configuring Digest Authentication
                                                                                • Configuring X.509 Certificate Authentication
                                                                                • Configuring J2EE Authentication
                                                                                • Configuring HTTP Header Proxy Authentication
                                                                                • Configuring Apache HTTPD Session Integration
                                                                                • Authentication with CAS
                                                                                "},{"location":"security/tutorials/activedirectory/","title":"Authentication with LDAP against ActiveDirectory","text":"

                                                                                This tutorial explains how to use GeoServer LDAP support to connect to a Windows Domain using ActiveDirectory as an LDAP server. It is recommended that the LDAP authentication section be read before proceeding.

                                                                                "},{"location":"security/tutorials/activedirectory/#windows-server-and-activedirectory","title":"Windows Server and ActiveDirectory","text":"

                                                                                Active Directory is just another LDAP server implementation, but has some features that we must know to successfully use it with GeoServer LDAP authentication. In this tutorial we will assume to have a Windows Server Domain Controller with ActiveDirectory named domain-controller for a domain named ad.local. If your environment uses different names (and it surely will) use your real names where needed.

                                                                                We will also assume that:

                                                                                • a group named GISADMINGROUP exists.
                                                                                • a user named GISADMIN exists, has password secret, and belongs to the GISADMINGROUP group.
                                                                                • a user named GISUSER exists, has password secret, and does NOT belong to the GISADMINGROUP group.

                                                                                Note

                                                                                ADMINISTRATOR cannot be generally used as the admin group name with ActiveDirectory, because Administrator is the root user name in Windows environment.

                                                                                "},{"location":"security/tutorials/activedirectory/#configure-the-ldap-authentication-provider","title":"Configure the LDAP authentication provider","text":"
                                                                                1. Start GeoServer and login to the web admin interface as the admin user.

                                                                                2. Click the Authentication link located under the Security section of the navigation sidebar.

                                                                                3. Scroll down to the Authentication Providers panel and click the Add new link.

                                                                                4. Click the LDAP link.

                                                                                5. Fill in the fields of the settings form as follows:

                                                                                  • Set Name to \"ad-ldap\"
                                                                                  • Set Server URL to \"
                                                                                  • Set Filter used to lookup user to (|(userPrincipalName={0})(sAMAccountName={1}))
                                                                                  • Set Format used for user login name to \"{0%7D@ad.local\"
                                                                                  • Check Use LDAP groups for authorization
                                                                                  • Check Bind user before searching for groups
                                                                                  • Set Group to use as ADMIN to \"GISADMINGROUP\"
                                                                                  • Set Group search base to \"cn=Users\"
                                                                                  • Set Group search filter to \"member={0}\"
                                                                                  • Test the LDAP connection by entering the username \"GISADMIN\" and password \"secret\" in the connection test form located on the right and click the Test Connection button.

                                                                                    A successful connection should be reported at the top of the page.

                                                                                  • Save.

                                                                                  • Back on the authentication page scroll down to the Provider Chain panel and move the ad-ldap provider from Available to Selected.

                                                                                  • Save.

                                                                                  • "},{"location":"security/tutorials/activedirectory/#test-a-ldap-login","title":"Test a LDAP login","text":"
                                                                                    1. Navigate to the GeoServer home page and log out of the admin account.
                                                                                    "},{"location":"security/tutorials/activedirectory/#login-as-the-user-gisuser-with-the-password-secret","title":". Login as the user \"GISUSER\" with the password \"secret\".","text":"

                                                                                    Logging in as GISUSER doesn't yield any administrative functionality because the GISUSER account has not been mapped to the administrator role. In the next section GeoServer will be configured to map groups from the LDAP database to roles.

                                                                                    Now we will login with a user having administrative rights.

                                                                                    1. Navigate to the GeoServer home page and log out of the account.
                                                                                    2. Login as the user \"GISADMIN\" with the password \"secret\".

                                                                                    Once logged in full administrative functionality should be available.

                                                                                    "},{"location":"security/tutorials/activedirectory/#configure-the-ldap-role-service","title":"Configure the LDAP role service","text":"

                                                                                    An additional step permits to configure a role service to get GeoServer roles from the LDAP repository and allow access rights to be assigned to those roles.

                                                                                    1. Click the Users,Group,Roles link located under the Security section of the navigation sidebar.

                                                                                    2. Click the Add new link under the Role Services section.

                                                                                    3. Click the LDAP option under the New Role Service section.

                                                                                    4. Enter ldapadrs in the Name text field.

                                                                                    5. Enter ldap://domain-controller/dc=ad,dc=local in the Server URL text field.

                                                                                    6. Enter CN=Users in the Group search base text field.

                                                                                    7. Enter member={1},dc=ad,dc=local in the Group user membership search filter text field.

                                                                                    8. Enter objectClass=group in the All groups search filter text field.

                                                                                    9. Enter sAMAccountName={0} in the Filter used to lookup user text field.

                                                                                    Then we need to a choose a user to authenticate on the server (many LDAP server don't allow anonymous data lookup).

                                                                                    1. Check the Authenticate to extract roles checkbox.
                                                                                    2. Enter GISADMIN@ad.local in the Username text field.
                                                                                    3. Enter secret in the Password text field.
                                                                                    4. Save.
                                                                                    5. Click the ldapadrs role service item under the Role Services section.
                                                                                    6. Select ROLE_DOMAIN ADMINS from the Administrator role combo-box.
                                                                                    7. Select ROLE_DOMAIN ADMINS from the Group administrator role combo-box.
                                                                                    8. Save again.

                                                                                    You should now be able to see and assign the new ActiveDirectory roles wherever an Available Roles list is shown (for example in the Data and Services rules sections.

                                                                                    "},{"location":"security/tutorials/cas/","title":"Authentication with CAS","text":"

                                                                                    This tutorial introduces GeoServer CAS support and walks through the process of setting up authentication against a CAS server. It is recommended that the Authentication chain section be read before proceeding. Reference information on cas setup is also available CAS integration.

                                                                                    "},{"location":"security/tutorials/cas/#cas-server-certificates","title":"CAS server certificates","text":"

                                                                                    A running CAS server is needed.

                                                                                    The first step is to import the server certificates into the GeoServer JVM.

                                                                                    If you need to export the CRT from the CAS server, you must execute the following command on the server JVM:

                                                                                    keytool -export -alias <server_name> -keystore <cas_jvm_keystore_path> -file server.crt\n

                                                                                    Once you have the server.crt file, the procedure to import the certificate into the JVM is the following one:

                                                                                    keytool -import -trustcacerts -alias <server_name> -file server.crt -keystore <path_to_JRE_cacerts>\n

                                                                                    Enter the keystore password and confirm the certificate to be trustable.

                                                                                    "},{"location":"security/tutorials/cas/#configure-the-cas-authentication-provider","title":"Configure the CAS authentication provider","text":"
                                                                                    1. Start GeoServer and login to the web admin interface as the admin user.

                                                                                    2. Click the Authentication link located under the Security section of the navigation sidebar.

                                                                                    3. Scroll down to the Authentication Filters panel and click the Add new link.

                                                                                    4. Click the CAS link.

                                                                                    5. Fill in the fields of the settings form as follows:

                                                                                    6. Update the filter chains by adding the new CAS filter.

                                                                                    7. Select the CAS Filter for each filter chain you want to protect with CAS.

                                                                                      Be sure to select and order correctly the CAS Filter.

                                                                                    8. Save.

                                                                                    "},{"location":"security/tutorials/cas/#test-a-cas-login","title":"Test a CAS login","text":"
                                                                                    1. Navigate to the GeoServer home page and log out of the admin account.

                                                                                    2. Try to login again, you should be able now to see the external CAS login form.

                                                                                    "},{"location":"security/tutorials/cert/","title":"Configuring X.509 Certificate Authentication","text":"

                                                                                    Certificate authentication involves the usage of public/private keys to identify oneself. This represents a much more secure alternative to basic username and password schemes.

                                                                                    X.509 is a well defined standard for the format of public key certificates. This tutorial walks through the process of setting up X.509 certificate authentication.

                                                                                    "},{"location":"security/tutorials/cert/#prerequisites","title":"Prerequisites","text":"

                                                                                    This tutorial assumes the following:

                                                                                    • A web browser that supports the usage of client certificates for authentication, also referred to as \"two-way SSL\". This tutorial uses Firefox.
                                                                                    • An SSL-capable servlet container. This tutorial uses Tomcat.
                                                                                    • GeoServer is deployed in Tomcat.
                                                                                    "},{"location":"security/tutorials/cert/#configure-the-usergroup-service","title":"Configure the user/group service","text":"

                                                                                    Users authenticated via a X.509 certificate must be configured in GeoServer. For this a new user/group service will be added.

                                                                                    1. Login to the web admin interface as the admin user.

                                                                                    2. Click the Users, Groups, and Roles link located under the Security section of the navigation sidebar.

                                                                                    3. Scroll down to the User Group Services panel and click the Add new link.

                                                                                    4. Create a new user/group service named cert-ugs and fill out the settings form as follows:

                                                                                      • Set Password encryption to Empty since users will not authenticate via password.
                                                                                      • Set Password policy to default.

                                                                                    5. Click Save.

                                                                                    6. Back on the Users, Groups, and Roles page, click the cert-ugs link.

                                                                                    7. Select the Users tab and click the Add new user link.

                                                                                    8. Add a new user named rod the and assign the ADMIN role.

                                                                                    9. Click Save.

                                                                                    10. Click the Authentication link located under the Security section of the navigation sidebar.

                                                                                    11. Scroll down to the Authentication Filters panel and click the Add new link.

                                                                                    12. Click the X.509 link and fill out form as follows:

                                                                                      • Set Name to \"cert\"
                                                                                      • Set Role source to User group service and set the associated drop-down to cert-ugs

                                                                                    13. Click Save.

                                                                                    14. Back on the authentication page, scroll down to the Filter Chains panel.

                                                                                    15. Click web in the Name column.

                                                                                    16. Select the cert filter and position it after the rememberme filter.

                                                                                    17. Click Close.

                                                                                    18. You will be returned to the previous page. Click Save.

                                                                                      Warning

                                                                                      This last change requires both Close and then Save to be clicked. You may wish to return to the web dialog to verify that the change was made.

                                                                                    "},{"location":"security/tutorials/cert/#download-sample-certificate-files","title":"Download sample certificate files","text":"

                                                                                    Rather than demonstrate how to create or obtain valid certificates, which is beyond the scope of this tutorial, sample files available as part of the spring security sample applications will be used.

                                                                                    Download and unpack the sample certificate files. This archive contains the following files:

                                                                                    • ca.pem is the certificate authority (CA) certificate issued by the \"Spring Security Test CA\" certificate authority. This file is used to sign the server and client certificates.
                                                                                    • server.jks is the Java keystore containing the server certificate and private key used by Tomcat and presented to the user during the setup of the SSL connection.
                                                                                    • rod.p12 contains the client certificate / key combination used to perform client authentication via the web browser.
                                                                                    "},{"location":"security/tutorials/cert/#configure-tomcat-for-ssl","title":"Configure Tomcat for SSL","text":"
                                                                                    1. Copy the server.jks file into the conf directory under the root of the Tomcat installation.

                                                                                    2. Edit the Tomcat conf/server.xml and add an SSL connector:

                                                                                      <Connector port=\"8443\" protocol=\"HTTP/1.1\" SSLEnabled=\"true\" scheme=\"https\" secure=\"true\"\n     clientAuth=\"true\" sslProtocol=\"TLS\" \n     keystoreFile=\"${catalina.home}/conf/server.jks\"\n     keystoreType=\"JKS\" keystorePass=\"password\"\n     truststoreFile=\"${catalina.home}/conf/server.jks\"\n     truststoreType=\"JKS\" truststorePass=\"password\" />\n

                                                                                      This enables SSL on port 8443.

                                                                                    3. By default, Tomcat has APR enabled. To disable it so the above configuration can work, remove or comment out the following line in the server.xml configuration file

                                                                                      <Listener className=\"org.apache.catalina.core.AprLifecycleListener\" SSLEngine=\"on\" />   \n
                                                                                    4. Restart Tomcat.

                                                                                    "},{"location":"security/tutorials/cert/#install-the-client-certificate","title":"Install the client certificate","text":"
                                                                                    1. In Firefox, select Preferences (or Tools \u2192 Options) and navigate to the Advanced panel.

                                                                                    2. Select the Encryption tab (or the Certificates tab, depending on your version) and click the View Certificates button.

                                                                                    3. On the Your Certificates panel click the Import button and select the rod.p12 file.

                                                                                    4. When prompted enter in the password password.

                                                                                    5. Click OK and close the Firefox Preferences.

                                                                                    "},{"location":"security/tutorials/cert/#test-certificate-login","title":"Test certificate login","text":"
                                                                                    1. Navigate to the GeoServer admin on port \"8443\" using HTTPS: https://localhost:8443/geoserver/web

                                                                                    2. You will be prompted for a certificate. Select the rod certificate for identification.

                                                                                    "},{"location":"security/tutorials/cert/#when-warned-about-the-self-signed-server-certificate-click-add-exception-to-add-a-security-exception","title":". When warned about the self-signed server certificate, click Add Exception to add a security exception.","text":"

                                                                                    The result is that the user rod is now logged into the GeoServer admin interface.

                                                                                    Note

                                                                                    Starting with version 31, Firefox implements a new mechanism for using certificates, which will cause a Issuer certificate is invalid error (sec_error_ca_cert_invalid) error when trying to use a self-signed repository such as the one proposed. To avoid that, you can disable this mechanism by browsing to about:config and setting the security.use_mozillapkix_verification parameter to false.

                                                                                    "},{"location":"security/tutorials/credentialsfromheaders/","title":"Configuring Apache HTTPD Session Integration","text":""},{"location":"security/tutorials/credentialsfromheaders/#introduction","title":"Introduction","text":"

                                                                                    When using Apache HTTPD as a proxy frontend for GeoServer, it is possible to share authentication with a proper configuration of both.

                                                                                    This requires enabling Session for the GeoServer location in Apache HTTPD and adding a custom Request Header with the session content, so that the GeoServer security system can receive user credentials and use them to authenticate the user with its internal filters.

                                                                                    To properly parse the received credentials we need to use the Credentials From Request Headers Authentication Filter.

                                                                                    Please note that the header containing the password is not sent back and forth to the user browser, but only from Apache HTTPD to GeoServer, so the password is not sent in clear through the public network.

                                                                                    This tutorial shows how to configure GeoServer to read user credentials from the Apache HTTPD Session and use them for authentication purposes.

                                                                                    "},{"location":"security/tutorials/credentialsfromheaders/#prerequisites","title":"Prerequisites","text":"

                                                                                    This tutorial uses the curl utility to issue HTTP request that test authentication. Install curl before proceeding.

                                                                                    "},{"location":"security/tutorials/credentialsfromheaders/#configure-the-credentials-from-request-headers-filter","title":"Configure the Credentials From Request Headers filter","text":"
                                                                                    1. Start GeoServer and login to the web admin interface as the admin user.

                                                                                    2. Click the Authentication link located under the Security section of the navigation sidebar.

                                                                                    3. Scroll down to the Authentication Filters panel and click the Add new link.

                                                                                    4. Click the Credentials From Headers link.

                                                                                    5. Fill in the fields of the settings form as follows:

                                                                                      • Set Name to \"apachessesion\"
                                                                                      • Set Username Header to \"X-Credentials\"
                                                                                      • Set Regular Expression for Username to \"private-user=([\\^&]*)\"
                                                                                      • Set Password Header to \"X-Credentials\"
                                                                                      • Set Regular Expression for Password to \"private-pw=([\\^&]*)\"

                                                                                    6. Save.

                                                                                    7. Back on the authentication page scroll down to the Filter Chains panel.

                                                                                    8. Click on \"default\" in the chain grid.

                                                                                    9. Scroll down and remove all filters from the Selected list and add the apachessesion filter.

                                                                                    10. Close.

                                                                                    11. Save.

                                                                                    "},{"location":"security/tutorials/credentialsfromheaders/#test-a-login","title":"Test a login","text":"
                                                                                    1. Execute the following curl command (with a wrong password):

                                                                                      curl -v -H \"X-Credentials: private-user=admin&private-pw=wrong\" \"http://localhost:8080/geoserver/wms?service=WMS&version=1.1.1&request=GetCapabilities\"\n

                                                                                      The result should be a 403 response signaling that access is denied. The output should look something like the following:

                                                                                      * About to connect() to localhost port 8080 (#0)\n*   Trying ::1... connected\n> GET /geoserver/wfs?request=getcapabilities HTTP/1.1\n> User-Agent: curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n> Host: localhost:8080\n> Accept: */*\n> \n< HTTP/1.1 403 Access Denied\n< Content-Type: text/html; charset=iso-8859-1\n< Content-Length: 1407\n< Server: Jetty(6.1.8)\n< \n<html>\n<head>\n<meta http-equiv=\"Content-Type\" content=\"text/html; charset=ISO-8859-1\"/>\n<title>Error 403 Access Denied</title>\n</head>\n    ...\n
                                                                                    2. Execute the same command but specify the right password.:

                                                                                      curl -v -H \"X-Credentials: private-user=admin&private-pw=geoserver\" \"http://localhost:8080/geoserver/wms?service=WMS&version=1.1.1&request=GetCapabilities\"\n

                                                                                      The result should be a successful authentication and contain the normal WMS capabilities response.

                                                                                    "},{"location":"security/tutorials/credentialsfromheaders/#configure-apache-httpd-to-forward-an-header-with-authentication-credentials","title":"Configure Apache HTTPD to forward an Header with authentication credentials","text":"

                                                                                    This can be done with an HTTPD configuration that looks like the following:

                                                                                    <Location  /geoserver>\n    Session On\n    SessionEnv On\n    SessionHeader X-Replace-Session\n    SessionCookieName session path=/\n    SessionCryptoPassphrase secret\n    RequestHeader set X-Credentials \"%{HTTP_SESSION}e\"\n</Location>\n

                                                                                    This configuration adds a new X-Credentials Request Header to each GeoServer request. The request header will contain the HTTPD Session information in a special format.

                                                                                    An example of the Session content is the following:

                                                                                    X-Credentials: private-user=admin&private-pw=geoserver

                                                                                    As you can see it contains both the username and password of the user, so the data can be used to authenticate the user in GeoServer.

                                                                                    "},{"location":"security/tutorials/digest/","title":"Configuring Digest Authentication","text":""},{"location":"security/tutorials/digest/#introduction","title":"Introduction","text":"

                                                                                    Out of the box GeoServer REST and OGC services support authentication via HTTP Basic authentication. One of the major downsides of basic auth is that it sends user passwords in plain text. HTTP Digest authentication offers a more secure alternative that applies a cryptographic hash function to passwords before sending them over the network.

                                                                                    This tutorial walks through the process of setting up digest authentication.

                                                                                    "},{"location":"security/tutorials/digest/#prerequisites","title":"Prerequisites","text":"

                                                                                    This tutorial uses the curl utility to issue HTTP request that test authentication. Install curl before proceeding.

                                                                                    Note

                                                                                    Any utility that supports both basic and digest authentication can be used in place of curl. Most modern web browsers support both types of authentication.

                                                                                    "},{"location":"security/tutorials/digest/#configure-the-digest-authentication-filter","title":"Configure the Digest authentication filter","text":"
                                                                                    1. Start GeoServer and login to the web admin interface as the admin user.

                                                                                    2. Click the Authentication link located under the Security section of the navigation sidebar.

                                                                                    3. Scroll down to the Authentication Filters panel and click the Add new link.

                                                                                    4. Click the Digest link.

                                                                                    5. Fill in the fields of the settings form as follows:

                                                                                      • Set Name to \"digest\"
                                                                                      • Set User group service to \"default\"

                                                                                    6. Save.

                                                                                    7. Back on the authentication page scroll down to the Filter Chains panel.

                                                                                    8. Select \"Default\" from the Request type drop down.

                                                                                    9. Unselect the basic filter and select the digest filter. Position the the digest filter before the anonymous filter.

                                                                                    10. Save.

                                                                                    "},{"location":"security/tutorials/digest/#secure-ogc-service-requests","title":"Secure OGC service requests","text":"

                                                                                    In order to test the authentication settings configured in the previous section a service or resource must be first secured. The Default filter chain is the chain applied to all OGC service requests so a service security rule must be configured.

                                                                                    1. From the GeoServer home page and click the Services link located under the Security section of the navigation sidebar.

                                                                                    2. On the Service security page click the Add new rule link and add a catch all rule that secures all OGC service requests requiring the ROLE_ADMINISTRATOR role.

                                                                                    3. Save.

                                                                                    "},{"location":"security/tutorials/digest/#test-a-digest-authentication-login","title":"Test a digest authentication login","text":"
                                                                                    1. Ensure that basic authentication is disabled execute the following curl command:

                                                                                      curl -v -u admin:geoserver -G \"http://localhost:8080/geoserve/wfs?request=getcapabilities\"\n

                                                                                      The result should be a 401 response signaling that authentication is required. The output should look something like the following:

                                                                                      * About to connect() to localhost port 8080 (#0)\n*   Trying 127.0.0.1... connected\n* Connected to localhost (127.0.0.1) port 8080 (#0)\n* Server auth using Basic with user 'admin'\n> GET /geoserver/wfs?request=getcapabilities HTTP/1.1\n> Authorization: Basic YWRtaW46Z2Vvc2VydmVy\n> User-Agent: curl/7.19.7 (universal-apple-darwin10.0) libcurl/7.19.7 OpenSSL/0.9.8r zlib/1.2.3\n> Host: localhost:8080\n> Accept: */*\n> \n< HTTP/1.1 401 Full authentication is required to access this resource\n< Set-Cookie: JSESSIONID=1dn2bi8qqu5qc;Path=/geoserver\n< WWW-Authenticate: Digest realm=\"GeoServer Realm\", qop=\"auth\", nonce=\"MTMzMzQzMDkxMTU3MjphZGIwMWE4MTc1NmRiMzI3YmFiODhmY2NmZGQ2MzEwZg==\"\n< Content-Type: text/html; charset=iso-8859-1\n< Content-Length: 1491\n< Server: Jetty(6.1.8)\n< \n<html>\n<head>\n<meta http-equiv=\"Content-Type\" content=\"text/html; charset=ISO-8859-1\"/>\n<title>Error 401 Full authentication is required to access this resource</title>\n</head>\n...\n
                                                                                    2. Execute the same command but specify the --digest option to tell curl to use digest authentication rather than basic authentication:

                                                                                      curl --digest -v -u admin:geoserver -G \"http://localhost:8080/geoserver/wfs?request=getcapabilities\"\n

                                                                                      The result should be a successful authentication and contain the normal WFS capabilities response.

                                                                                    "},{"location":"security/tutorials/httpheaderproxy/","title":"Configuring HTTP Header Proxy Authentication","text":""},{"location":"security/tutorials/httpheaderproxy/#introduction","title":"Introduction","text":"

                                                                                    Proxy authentication is used in multi-tier system. The user/principal authenticates at the proxy and the proxy provides the authentication information to other services.

                                                                                    This tutorial shows how to configure GeoServer to accept authentication information passed by HTTP header attribute(s). In this scenario GeoServer will do no actual authentication itself.

                                                                                    "},{"location":"security/tutorials/httpheaderproxy/#prerequisites","title":"Prerequisites","text":"

                                                                                    This tutorial uses the curl utility to issue HTTP request that test authentication. Install curl before proceeding.

                                                                                    Note

                                                                                    Any utility that supports setting HTTP header attributes can be used in place of curl.

                                                                                    "},{"location":"security/tutorials/httpheaderproxy/#configure-the-http-header-filter","title":"Configure the HTTP header filter","text":"
                                                                                    1. Start GeoServer and login to the web admin interface as the admin user.

                                                                                    2. Click the Authentication link located under the Security section of the navigation sidebar.

                                                                                    3. Scroll down to the Authentication Filters panel and click the Add new link.

                                                                                    4. Click the HTTP Header link.

                                                                                    5. Fill in the fields of the settings form as follows:

                                                                                      • Set Name to \"proxy\"
                                                                                      • Set Request header attribute to to \"sdf09rt2s\"
                                                                                      • Set Role source to \"User group service\"
                                                                                      • Set the name of the user group service to \"default\"

                                                                                    Additional information about role services is here Role source and role calculation

                                                                                    ::: warning ::: title Warning :::

                                                                                    The tutorial uses the obscure \"sdf09rt2s\" name for the header attribute. Why not use \"user\" or \"username\" ?. In a proxy scenario a relationship of trust is needed between the proxy and GeoServer. An attacker could easily send an HTTP request with an HTTP header attribute \"user\" and value \"admin\" and operate as an administrator.

                                                                                    One possibility is to configure the network infrastructure preventing such requests from all IP addresses except the IP of the proxy.

                                                                                    This tutorial uses a obscure header attribute name which should be a shared secret between the proxy and GeoServer. Additionally, the use of SSL is recommended, otherwise the shared secret is transported in plain text. :::

                                                                                    1. Save.

                                                                                    2. Back on the authentication page scroll down to the Filter Chains panel.

                                                                                    3. Select \"Default\" from the Request type drop down.

                                                                                    4. Unselect the basic filter and select the proxy filter. Position the the proxy filter before the anonymous filter.

                                                                                    5. Save.

                                                                                    "},{"location":"security/tutorials/httpheaderproxy/#secure-ogc-service-requests","title":"Secure OGC service requests","text":"

                                                                                    In order to test the authentication settings configured in the previous section a service or resource must be first secured. The Default filter chain is the chain applied to all OGC service requests so a service security rule must be configured.

                                                                                    1. From the GeoServer home page and click the Services link located under the Security section of the navigation sidebar.

                                                                                    2. On the Service security page click the Add new rule link and add a catch all rule that secures all OGC service requests requiring the ADMIN role.

                                                                                    3. Save.

                                                                                    "},{"location":"security/tutorials/httpheaderproxy/#test-a-proxy-login","title":"Test a proxy login","text":"
                                                                                    1. Execute the following curl command:

                                                                                      curl -v  -G \"http://localhost:8080/geoserver/wfs?request=getcapabilities\"\n

                                                                                      The result should be a 403 response signaling that access is denied. The output should look something like the following:

                                                                                      * About to connect() to localhost port 8080 (#0)\n*   Trying ::1... connected\n> GET /geoserver/wfs?request=getcapabilities HTTP/1.1\n> User-Agent: curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n> Host: localhost:8080\n> Accept: */*\n> \n< HTTP/1.1 403 Access Denied\n< Content-Type: text/html; charset=iso-8859-1\n< Content-Length: 1407\n< Server: Jetty(6.1.8)\n< \n<html>\n<head>\n<meta http-equiv=\"Content-Type\" content=\"text/html; charset=ISO-8859-1\"/>\n<title>Error 403 Access Denied</title>\n</head>\n    ...\n
                                                                                    2. Execute the same command but specify the --header option.:

                                                                                      curl -v --header \"sdf09rt2s: admin\" -G \"http://localhost:8080/geoserver/wfs?request=getcapabilities\"\n

                                                                                      The result should be a successful authentication and contain the normal WFS capabilities response.

                                                                                    "},{"location":"security/tutorials/j2ee/","title":"Configuring J2EE Authentication","text":"

                                                                                    Servlet containers such as Tomcat and Jetty offer their own options for authentication. Often it is desirable for an application such as GeoServer to use that existing authentication mechanisms rather than require its own authentication configuration.

                                                                                    J2EE authentication allows GeoServer to delegate to the servlet container for authentication. This tutorial walks through the process of setting up J2EE authentication.

                                                                                    "},{"location":"security/tutorials/j2ee/#prerequisites","title":"Prerequisites","text":"

                                                                                    This tutorial requires a servlet container capable of doing its own authentication. This tutorial uses Tomcat.

                                                                                    Deploy GeoServer in tomcat before proceeding.

                                                                                    "},{"location":"security/tutorials/j2ee/#configure-the-j2ee-authentication-filter","title":"Configure the J2EE authentication filter","text":"

                                                                                    In order to delegate to the container for authentication a filter must first be configured to recognize the container authentication.

                                                                                    1. Login to the GeoServer web admin interface as the admin user.

                                                                                    2. Click the Authentication link located under the Security section of the navigation sidebar.

                                                                                    3. Scroll down to the Authentication Filter panel and click the Add new link.

                                                                                    4. Create a new filter named \"j2ee\" and fill out the settings form as follows:

                                                                                      • Set the Role service to \"default\"

                                                                                    5. Save

                                                                                    6. Back on the authentication page scroll down to the Filter Chains panel.

                                                                                    7. Select \"Web UI\" from the Request type drop down.

                                                                                    8. Select the j2ee filter and position it after the anonymous filter.

                                                                                    9. Save.

                                                                                    "},{"location":"security/tutorials/j2ee/#configure-the-role-service","title":"Configure the role service","text":"

                                                                                    Since it is not possible to ask a J2EE container for the roles of a principal it is necessary to have all J2EE roles enlisted in a role service. The only J2EE API GeoServer can use is:

                                                                                    class: javax.servlet.http.HttpServletRequest\nmethod: boolean isUserInRole(String role)\n

                                                                                    The idea is to query all roles from the role service and test each role with the \"isUserInRole\" method.

                                                                                    This tutorial assumes a user named \"admin\" with password \"password\" and a J2EE role named \"tomcat\".

                                                                                    1. Click the Users, Groups, and Roles link located under the Security section of the navigation sidebar.

                                                                                    2. Click on default to work with the role service named \"default\".

                                                                                    3. Click on the Roles tab.

                                                                                    4. Click on the Add new role link.

                                                                                      • Set the Name to \"tomcat\"

                                                                                    5. Save

                                                                                    "},{"location":"security/tutorials/j2ee/#configure-tomcat-for-authentication","title":"Configure Tomcat for authentication","text":"

                                                                                    By default Tomcat does not require authentication for web applications. In this section Tomcat will be configured to secure GeoServer requiring a basic authentication login.

                                                                                    1. Shut down Tomcat.

                                                                                    2. Edit the conf/tomcat-users.xml under the Tomcat root directory and add a user named \"admin\":

                                                                                      <user username=\"admin\" password=\"password\" roles=\"tomcat\"/>\n
                                                                                    3. Edit the GeoServer web.xml file located at webapps/geoserver/WEB-INF/web.xml under the Tomcat root directory and add the following at the end of the file directly before the closing </web-app> element:

                                                                                      <security-constraint>\n  <web-resource-collection>\n    <url-pattern>/*</url-pattern>\n     <http-method>GET</http-method>\n     <http-method>POST</http-method>\n  </web-resource-collection>\n  <auth-constraint>\n    <role-name>tomcat</role-name>\n  </auth-constraint>\n</security-constraint>\n\n<login-config>\n  <auth-method>BASIC</auth-method>\n</login-config>\n
                                                                                    4. Save web.xml and restart Tomcat.

                                                                                    Note

                                                                                    It is necessary to add all the role names specified in the web.xml to the configured role service. This is duplicate work but there is currently no other solution.

                                                                                    "},{"location":"security/tutorials/j2ee/#test-j2ee-login","title":"Test J2EE login","text":"
                                                                                    1. Navigate to the GeoServer web admin interface. The result should be a prompt to authenticate.
                                                                                    "},{"location":"security/tutorials/j2ee/#enter-in-the-username-admin-and-password-password","title":". Enter in the username \"admin\" and password \"password\"","text":"

                                                                                    The result should be the admin user logged into the GeoServer web admin.

                                                                                    "},{"location":"security/tutorials/ldap/","title":"Authentication with LDAP","text":"

                                                                                    This tutorial introduces GeoServer LDAP support and walks through the process of setting up authentication against an LDAP server. It is recommended that the LDAP authentication section be read before proceeding.

                                                                                    "},{"location":"security/tutorials/ldap/#ldap-server-setup","title":"LDAP server setup","text":"

                                                                                    A mock LDAP server will be used for this tutorial. Download and run the acme-ldap jar:

                                                                                    java -jar acme-ldap.jar\n

                                                                                    The output of which should look like the following:

                                                                                    Directory contents:\n  ou=people,dc=acme,dc=org\n    uid=bob,ou=people,dc=acme,dc=org\n    uid=alice,ou=people,dc=acme,dc=org\n    uid=bill,ou=people,dc=acme,dc=org\n  ou=groups,dc=acme,dc=org\n  cn=users,ou=groups,dc=acme,dc=org\n    member: uid=bob,ou=people,dc=acme,dc=org\n    member: uid=alice,ou=people,dc=acme,dc=org\n  cn=admins,ou=groups,dc=acme,dc=org\n    member: uid=bill,ou=people,dc=acme,dc=org\n\n  Server running on port 10389\n

                                                                                    The following diagram illustrates the hierarchy of the LDAP datatabse:

                                                                                    The LDAP tree consists of:

                                                                                    • The root domain component, dc=acme,dc=org
                                                                                    • Two organizational units (groups) named user and admin
                                                                                    • Two users named bob and alice who are members of the user group
                                                                                    • One user named bill who is a member of the admin group
                                                                                    "},{"location":"security/tutorials/ldap/#configure-the-ldap-authentication-provider","title":"Configure the LDAP authentication provider","text":"
                                                                                    1. Start GeoServer and login to the web admin interface as the admin user.

                                                                                    2. Click the Authentication link located under the Security section of the navigation sidebar.

                                                                                    3. Scroll down to the Authentication Providers panel and click the Add new link.

                                                                                    4. Click the LDAP link.

                                                                                    5. Fill in the fields of the settings form as follows:

                                                                                      • Set Name to \"acme-ldap\"
                                                                                      • Set Server URL to \"\"
                                                                                      • Set User lookup pattern to \"uid={0},ou=people\"
                                                                                      • Test the LDAP connection by entering the username \"bob\" and password \"secret\" in the connection test form located on the right and click the Test Connection button.

                                                                                        A successful connection should be reported at the top of the page.

                                                                                      • Save.

                                                                                      • Back on the authentication page scroll down to the Provider Chain panel and move the acme-ldap provider from Available to Selected.

                                                                                      • Save.

                                                                                      • "},{"location":"security/tutorials/ldap/#test-a-ldap-login","title":"Test a LDAP login","text":"
                                                                                        1. Navigate to the GeoServer home page and log out of the admin account.
                                                                                        "},{"location":"security/tutorials/ldap/#login-as-the-user-bob-with-the-password-secret","title":". Login as the user \"bob\" with the password \"secret\".","text":"

                                                                                        Logging in as bob doesn't yield any administrative functionality because the bobaccount has not been mapped to the administrator role. In the next section GeoServer will be configured to map groups from the LDAP database to roles.

                                                                                        "},{"location":"security/tutorials/ldap/#map-ldap-groups-to-geoserver-roles","title":"Map LDAP groups to GeoServer roles","text":"

                                                                                        When using LDAP for authentication GeoServer maps LDAP groups to GeoServer roles by prefixing the group name with ROLE_ and converting the result to uppercase. For example bob and alice are members of the user group so after authentication they would be assigned a role named ROLE_USER. Similarly bill is a member of the admin group so he would be assigned a role named ROLE_ADMIN.

                                                                                        1. Log out of the web admin and log back in as the admin user.

                                                                                        2. Navigate to the Authentication page.

                                                                                        3. Scroll to the Authentication Providers panel and click the acme-ldap link.

                                                                                        4. On the settings page fill in the following form fields:

                                                                                          • Set Group search base to \"ou=groups\"
                                                                                          • Set Group search filter to \"member={0}\"

                                                                                          The first field specifies the node of the LDAP directory tree at which groups are located. In this case the organizational unit named groups. The second field specifies the LDAP query filter to use in order to locate those groups that a specific user is a member of. The {0} is a placeholder which is replaced with the uid of the user.

                                                                                          • Set Group to use as ADMIN to \"ADMIN\"
                                                                                          • Set Group to use as GROUP_ADMIN to \"ADMIN\"

                                                                                          If you want support for hierarchical LDAP groups:

                                                                                          • Check Enable Hierarchical groups search box.
                                                                                          • Set Max depth for hierarchical groups search to 10 (-1 for infinite depth, or the depth number you want to support).
                                                                                          • Set Nested group search filter to \"member={0}\"

                                                                                          These settings let users in the LDAP admin group to be recognized as GeoServer administrators.

                                                                                        5. Save.

                                                                                        At this point the LDAP provider will populate an authenticated user with roles based on the groups the user is a member of.

                                                                                        At this point members of the admin LDAP group should be given full administrative privileges once authenticated. Log out of the admin account and log in as \"bill\" with the password \"hello\". Once logged in full administrative functionality should be available.

                                                                                        "},{"location":"security/tutorials/ldap/#configure-the-ldap-role-service","title":"Configure the LDAP role service","text":"

                                                                                        An additional step permits to configure a role service to get GeoServer roles from the LDAP repository and allow access rights to be assigned to those roles.

                                                                                        1. Click the Users,Group,Roles link located under the Security section of the navigation sidebar.

                                                                                        2. Click the Add new link under the Role Services section.

                                                                                        3. Click the LDAP option under the New Role Service section.

                                                                                        4. Enter ldaprs in the Name text field.

                                                                                        5. Enter ldap://localhost:10389/dc=acme,dc=org in the Server URL text field.

                                                                                        6. Enter ou=groups in the Group search base text field.

                                                                                        7. Enter member=uid={0},ou=people,dc=acme,dc=org in the Group user membership search filter text field.

                                                                                        8. Enter cn=* in the All groups search filter text field.

                                                                                        Then we need to a choose a user to authenticate on the server (many LDAP server don't allow anonymous data lookup).

                                                                                        1. Check the Authenticate to extract roles checkbox.
                                                                                        2. Enter uid=bill,ou=people,dc=acme,dc=org in the Username text field.
                                                                                        3. Enter hello in the Password text field.

                                                                                        If we want Hierarchical groups working we need:

                                                                                        1. Check the Enable Hierarchical groups search checkbox.
                                                                                        2. Enter 10 in the Max depth for hierarchical groups search text field.
                                                                                        3. Enter member={1} in the Nested group search filter text field.
                                                                                        4. Save.
                                                                                        5. Click the ldaprs role service item under the Role Services section.
                                                                                        6. Select ROLE_ADMIN from the Administrator role combo-box.
                                                                                        7. Select ROLE_ADMIN from the Group administrator role combo-box.
                                                                                        8. Save again.

                                                                                        You should now be able to see and assign the new ROLE_ADMIN and ROLE_USER roles wherever an Available Roles list is shown (for example in the Data and Services rules sections.

                                                                                        "},{"location":"security/usergrouprole/","title":"Role system","text":"

                                                                                        Security in GeoServer is based on a role-based system, with roles created to serve particular functions. Examples of roles sporting a particular function are those accessing the Web Feature Service (WFS), administering the Web administration interface, and reading a specific layer. Roles are assigned to users and groups of users, and determine what actions those users or groups are permitted to do. A user is authorized through Authentication.

                                                                                        • Users and Groups
                                                                                        • User/group services
                                                                                        • Roles
                                                                                        • Role services
                                                                                        • Role source and role calculation
                                                                                        • Interaction between user/group and role services
                                                                                        "},{"location":"security/usergrouprole/interaction/","title":"Interaction between user/group and role services","text":"

                                                                                        The following section describes the interaction between the User/group services and the Role services.

                                                                                        "},{"location":"security/usergrouprole/interaction/#calculating-the-roles-of-a-user","title":"Calculating the roles of a user","text":"

                                                                                        The diagram below illustrates how a user/group service and a role service interact to calculate user roles.

                                                                                        User/group and role service interacting for role calculation

                                                                                        On fetching an enabled user from a user/group service, the roles(s) assigned to that user must be identified. The identification procedure is:

                                                                                        1. Fetch all enabled groups for the user. If a group is disabled, it is discarded.
                                                                                        2. Fetch all roles associated with the user and add the roles to the result set.
                                                                                        3. For each enabled group the user is a member of, fetch all roles associated with the group and add the roles to the result set.
                                                                                        4. For each role in the result set, fetch all ancestor roles and add those roles to the result set.
                                                                                        5. Personalize each role in the result set as required.
                                                                                        6. If the result set contains the local admin role, add the role ROLE_ADMINISTRATOR.
                                                                                        7. If the result set contains the local group admin role, add the role ROLE_GROUP_ADMIN.

                                                                                        Note

                                                                                        Role personalization looks for role parameters (key/value pairs) for each role and checks if the user properties (key/value pairs) contain an identical key. If any matches are found, the value of the role parameter is replaced by the value of the user property.

                                                                                        "},{"location":"security/usergrouprole/interaction/#authentication-of-user-credentials","title":"Authentication of user credentials","text":"

                                                                                        A user/group service is primarily used during authentication. An authentication provider in the Authentication chain may use a user/group service to authenticate user credentials.

                                                                                        Using a a user/group service for authentication

                                                                                        "},{"location":"security/usergrouprole/interaction/#geoserver-defaults","title":"GeoServer defaults","text":"

                                                                                        The following diagram illustrates the default user/group service, role service, and authentication provider in GeoServer:

                                                                                        Default GeoServer security configuration

                                                                                        Two authentication providers are configured---the Root provider and the Username/password provider. The Root provider authenticates for the GeoServer Root account and does not use a user/group service. The Username/password provider is the default provider and relays username and password credentials to a user/group service.

                                                                                        A single user/group service, which persist the user database as XML, is present. The database contains a single user named admin and no groups. Similarly, the role service persists the role database as XML. By default, this contains a single role named ADMIN, which is associated with the admin user. The ADMIN role is mapped to the ROLE_ADMINISTRATOR role and as a result, the admin user is associated with system administrator role during role calculation.

                                                                                        "},{"location":"security/usergrouprole/roles/","title":"Roles","text":"

                                                                                        GeoServer roles are keys associated with performing certain tasks or accessing particular resources. Roles are assigned to users and groups, authorizing them to perform the actions associated with the role. A GeoServer role includes the following:

                                                                                        • Role name
                                                                                        • Parent role
                                                                                        • Set of key/value pairs

                                                                                        GeoServer roles support inheritance---a child role inherits all the access granted to the parent role. For example, suppose you have one role named ROLE_SECRET and another role, ROLE_VERY_SECRET, that extends ROLE_SECRET. ROLE_VERY_SECRET can access everything ROLE_SECRET can access, but not vice versa.

                                                                                        Key/value pairs are implementation-specific and may be configured by the role service the user or group belongs to. For example, a role service that assigns roles based on employee organization may wish to associate additional information with the role such as Department Name.

                                                                                        GeoServer has a number of system roles, the names of which are reserved. Adding a new GeoServer role with reserved name is not permitted.

                                                                                        • ROLE_ADMINISTRATOR---Provides access to all operations and resources
                                                                                        • ROLE_GROUP_ADMIN---Special role for administrating user groups
                                                                                        • ROLE_AUTHENTICATED---Assigned to every user authenticating successfully
                                                                                        • ROLE_ANONYMOUS---Assigned if anonymous authentication is enabled and user does not log on
                                                                                        "},{"location":"security/usergrouprole/roleservices/","title":"Role services","text":"

                                                                                        A role service provides the following information for roles:

                                                                                        • List of roles
                                                                                        • Calculation of role assignments for a given user
                                                                                        • Mapping of a role to the system role ROLE_ADMINISTRATOR
                                                                                        • Mapping of a role to the system role ROLE_GROUP_ADMIN

                                                                                        When a user/group service loads information about a user or a group, it delegates to the role service to determine which roles should be assigned to the user or group. Unlike User/group services, only one role service is active at any given time. The default role service is set on the Settings page.

                                                                                        By default, GeoServer supports two types of role services:

                                                                                        • XML---(Default) role service persisted as XML
                                                                                        • JDBC---Role service persisted in a database via JDBC
                                                                                        "},{"location":"security/usergrouprole/roleservices/#security_rolesystem_mapping","title":"Mapping roles to system roles","text":"

                                                                                        To assign the system role ROLE_ADMINISTRATOR to a user or to a group, a new role with a different name must be created and mapped to the ROLE_ADMINISTRATOR role. The same holds true for the system role ROLE_GROUP_ADMIN. The mapping is stored in the service's config.xml file.

                                                                                        <roleService>\n  <id>471ed59f:13915c479bc:-7ffc</id>\n  <name>default</name>\n  <className>org.geoserver.security.xml.XMLRoleService</className>\n  <fileName>roles.xml</fileName>\n  <checkInterval>10000</checkInterval>\n  <validating>true</validating>\n  <adminRoleName>ADMIN</adminRoleName>\n  <groupAdminRoleName>GROUP_ADMIN</groupAdminRoleName>\n</roleService>\n

                                                                                        In this example, a user or a group assigned to the role ADMIN is also assigned to the system role ROLE_ADMINISTRATOR. The same holds true for GROUP_ADMIN and ROLE_GROUP_ADMIN.

                                                                                        "},{"location":"security/usergrouprole/roleservices/#security_rolesystem_rolexml","title":"XML role service","text":"

                                                                                        The XML role service persists the role database in an XML file. This is the default role service for GeoServer. This service represents the user database as XML, and corresponds to this XML schema.

                                                                                        Note

                                                                                        The XML role file, roles.xml, is located in the GeoServer data directory, security/role/<name>/roles.xml, where <name> is the name of the role service.

                                                                                        The service is configured to map the local role ADMIN to the system role ROLE_ADMINISTRATOR. Additionally, GROUP_ADMIN is mapped to ROLE_GROUP_ADMIN. The mapping is stored the config.xml file of each role service.

                                                                                        The following provides an illustration of the roles.xml that ships with the default GeoServer configuration:

                                                                                        <roleRegistry version=\"1.0\" xmlns=\"http://www.geoserver.org/security/roles\">\n  <roleList>\n    <role id=\"ADMIN\"/>\n    <role id=\"GROUP_ADMIN\"/>\n  </roleList>\n  <userList>\n    <userRoles username=\"admin\">\n      <roleRef roleID=\"ADMIN\"/>\n    </userRoles>\n  </userList>\n  <groupList/>\n</roleRegistry>\n

                                                                                        This configuration contains two roles named ADMIN and GROUP_ADMIN. The role ADMIN is assigned to the admin user. Since the ADMIN role is mapped to the system role ROLE_ADMINISTRATOR, the role calculation assigns both roles to the admin user.

                                                                                        For further information, please refer to configuring a role service in the Web administration interface.

                                                                                        "},{"location":"security/usergrouprole/roleservices/#security_rolesystem_rolej2ee","title":"J2EE role service","text":"

                                                                                        The J2EE role service parses roles from the WEB-INF/web.xml file. As a consequence, this service is a read only role service. Roles are extracted from the following XML elements:

                                                                                        "},{"location":"security/usergrouprole/roleservices/#security-role","title":"<security-role>","text":"
                                                                                        <security-role>\n   <role-name>role1</role-name>\n</security-role>\n<security-role>\n   <role-name>role2</role-name>\n</security-role>  \n<security-role>\n   <role-name>employee</role-name>\n</security-role>\n

                                                                                        Roles retrieved:

                                                                                        • role1
                                                                                        • role2
                                                                                        • employee
                                                                                        "},{"location":"security/usergrouprole/roleservices/#security-constraint","title":"<security-constraint>","text":"
                                                                                        <security-constraint>\n   <web-resource-collection>\n       <web-resource-name>Protected Area</web-resource-name>\n       <url-pattern>/jsp/security/protected/*</url-pattern>\n       <http-method>PUT</http-method>\n       <http-method>DELETE</http-method>\n       <http-method>GET</http-method>\n       <http-method>POST</http-method>\n   </web-resource-collection>\n   <auth-constraint>\n       <role-name>role1</role-name>\n       <role-name>employee</role-name>\n   </auth-constraint>\n</security-constraint>\n

                                                                                        Roles retrieved:

                                                                                        • role1
                                                                                        • employee
                                                                                        "},{"location":"security/usergrouprole/roleservices/#security-role-ref","title":"<security-role-ref>","text":"
                                                                                        <security-role-ref>\n    <role-name>MGR</role-name>\n    <!-- role name used in code -->\n    <role-link>employee</role-link>\n  </security-role-ref>      \n

                                                                                        Roles retrieved:

                                                                                        • MGR
                                                                                        "},{"location":"security/usergrouprole/roleservices/#security_rolesystem_rolejdbc","title":"JDBC role service","text":"

                                                                                        The JDBC role service persists the role database via JDBC, managing the role information in multiple tables. The role database schema is as follows:

                                                                                        Field Type Null Key name varchar(64) NO PRI parent varchar(64) YES Field Type Null Key rolename varchar(64) NO PRI propname varchar(64) NO PRI propvalue varchar(2048) YES Field Type Null Key username varchar(128) NO PRI rolename varchar(64) NO PRI Field Type Null Key groupname varchar(128) NO PRI rolename varchar(64) NO PRI

                                                                                        The roles table is the primary table and contains the list of roles. Roles in GeoServer support inheritance, so a role may optionally have a link to a parent role. The role_props table maps additional properties to a role. (See the section on Roles for more details.) The user_roles table maps users to the roles they are assigned. Similarly, the group_roles table maps which groups have been assigned to which roles.

                                                                                        The default GeoServer security configuration is:

                                                                                        name parent Empty Empty rolename propname propvalue Empty Empty Empty username rolename Empty Empty groupname rolename Empty Empty

                                                                                        For further information, please refer to configuring a role service in the Web administration interface.

                                                                                        "},{"location":"security/usergrouprole/roleservices/#ldap-role-service","title":"LDAP role service","text":"

                                                                                        The LDAP role service is a read only role service that maps groups from an LDAP repository to GeoServer roles.

                                                                                        Groups are extracted from a specific LDAP node, configured as the Groups search base. A role is mapped for every matching group. The role will have a name that is built taking the Group common name (cn attribute), transformed to upper case and with a ROLE_ prefix applied.

                                                                                        It is possible to filter extracted groups using an All groups filter (defaults to cn=* that basically extracts all nodes from the configured base). It is also possible to configure the filter for users to roles membership (defaults to member={0}).

                                                                                        A specific group can be assigned to the ROLE_ADMINISTRATOR and/or the ROLE_GROUP_ADMIN administrative roles.

                                                                                        Groups extraction can be done anonymously or using a given username/password if the LDAP repository requires it.

                                                                                        An example of configuration file (config.xml) for this type of role service is the following:

                                                                                        <org.geoserver.security.ldap.LDAPRoleServiceConfig>\n  <id>-36dfbd50:1424687f3e0:-8000</id>\n  <name>ldapacme</name>\n  <className>org.geoserver.security.ldap.LDAPRoleService</className>\n  <serverURL>ldap://127.0.0.1:10389/dc=acme,dc=org</serverURL>\n  <groupSearchBase>ou=groups</groupSearchBase>\n  <groupSearchFilter>member=uid={0},ou=people,dc=acme,dc=org</groupSearchFilter>\n  <useTLS>false</useTLS>\n  <bindBeforeGroupSearch>true</bindBeforeGroupSearch>\n  <adminGroup>ROLE_ADMIN</adminGroup>\n  <groupAdminGroup>ROLE_ADMIN</groupAdminGroup>\n  <user>uid=bill,ou=people,dc=acme,dc=org</user>\n  <password>hello</password>\n  <allGroupsSearchFilter>cn=*</allGroupsSearchFilter>\n</org.geoserver.security.ldap.LDAPRoleServiceConfig>\n

                                                                                        For further information, please refer to configuring a role service in the Web administration interface.

                                                                                        "},{"location":"security/usergrouprole/roleservices/#rest-role-service","title":"REST role service","text":"

                                                                                        The REST role service is a read only role service that maps groups and associated users to roles from a remote REST web service.

                                                                                        The REST service must support JSON encoding.

                                                                                        Here is a listing of significant methods provided by the REST Role Service (based on the LDAP role service, which similarly has to make network calls to work):

                                                                                        Method Mandatory getUserNamesForRole(roleName) N (implemented in LDAP, but I don't see actual users of this method besides a utility method that nobody uses) getRolesForUser(user) Y getRolesForGroup(group) N getRoles() Y (used by the UI) getParentRole(role) N getAdminRole() Y getGroupAdminRole() Y getRoleCount() Y (does not seem to be used much, we can trivially implement it from getRoles()"},{"location":"security/usergrouprole/roleservices/#rest-apis","title":"REST APIs","text":"

                                                                                        The following is an example of the REST API the role service may handle. The JSON and remote endpoints may differ; this is configurable via UI, allowing the REST role service to connect to a generic REST Service

                                                                                        From the above we could have the following REST API to talk to

                                                                                        ../api/roles

                                                                                        Returns the full list of roles (no paging required, we assume it's small). Example response:

                                                                                        {\"groups\":[\"r1\",\"r2\",\"r3\"]}\n

                                                                                        ../api/adminrole

                                                                                        Returns the role of the administrator (yes, just one, it's strange...):

                                                                                        {\"adminRole\":[\"root\"]}\n

                                                                                        ../api/users/<user>

                                                                                        Returns the list of roles for a particular user. Example response:

                                                                                        {\"users\": [{\"user\":\"u1\", \"groups\":[\"r1\",\"r2\"]}]}\n
                                                                                        "},{"location":"security/usergrouprole/roleservices/#configurable-api","title":"Configurable API","text":"

                                                                                        The GeoServerRoleService talking to a remote service provides the following config parameters:

                                                                                        • Base URL for the remote service
                                                                                        • Configurable URLs for the various calls
                                                                                        • JSON paths to the properties that contain the list of roles, and the one admin role

                                                                                        The above can be configured via the Web administration interface. The figure below shows the REST role service options configured to be compatible with the sample APIs above:

                                                                                        REST based role service configuration panel

                                                                                        "},{"location":"security/usergrouprole/rolesource/","title":"Role source and role calculation","text":"

                                                                                        Different authentication mechanisms provide different possibilities where to look for the roles of a principal/user. The role source is the base for the calculation of the roles assigned to the authenticated principal.

                                                                                        "},{"location":"security/usergrouprole/rolesource/#using-a-usergroup-service","title":"Using a user/group Service","text":"

                                                                                        During configuration of an authentication mechanism, the name of a user group service has to be specified. The used role service is always the role service configured as active role service. The role calculation itself is described here Interaction between user/group and role services

                                                                                        "},{"location":"security/usergrouprole/rolesource/#using-a-role-service-directly","title":"Using a role service directly","text":"

                                                                                        During configuration of an authentication mechanism, the name of a role service has to be specified. The calculation of the roles works as follows:

                                                                                        1. Fetch all roles for the user.
                                                                                        2. For each role in the result set, fetch all ancestor roles and add those roles to the result set.
                                                                                        3. If the result set contains the local admin role, add the role ROLE_ADMINISTRATOR.
                                                                                        4. If the result set contains the local group admin role, add the role ROLE_GROUP_ADMIN.

                                                                                        This algorithm does not offer the possibility to have personalized roles and it does not consider group memberships.

                                                                                        "},{"location":"security/usergrouprole/rolesource/#using-an-http-header-attribute","title":"Using an HTTP header attribute","text":"

                                                                                        The roles for a principal are sent by the client in an HTTP header attribute (Proxy authentication). GeoServer itself does no role calculation and extracts the roles from the header attribute. During configuration, the name of the header attribute must be specified. An example with a header attribute named \"roles\":

                                                                                        roles: role_a;role_b;role_c\n

                                                                                        An example for roles with role parameters:

                                                                                        roles: role_a;role_b(pnr=123,nick=max);role_c\n

                                                                                        The default syntax is

                                                                                        • roles are delimited by ;
                                                                                        • a role parameter list starts with ( and ends with )
                                                                                        • a role parameter is a key value pair delimited by =
                                                                                        • role parameters are delimited by ,
                                                                                        "},{"location":"security/usergrouprole/usergroups/","title":"Users and Groups","text":"

                                                                                        The definition of a GeoServer user is similar to most security systems. Although the correct Java term is principal---a principal being a human being, computer, software system, and so on---the term user is adopted throughout the GeoServer documentation. For each user the following information is maintained:

                                                                                        • User name
                                                                                        • Password (optionally stored encrypted)
                                                                                        • A flag indicating if the user is enabled (this is the default). A disabled user is prevented from logging on. Existing user sessions are not affected.
                                                                                        • Set of key/value pairs

                                                                                        Key/value pairs are implementation-specific and may be configured by the user/group service the user or group belongs to. For example, a user/group service that maintains information about a user such as Name, Email address, and so on, may wish to associate those attributes with the user object.

                                                                                        A GeoServer group is simply a set of users. For each group the following information is maintained:

                                                                                        • Group name
                                                                                        • A flag indicating if the group is enabled (this is the default). A disabled group does not contribute to the role calculation for all users contained in this group.
                                                                                        • List of users who belong to the group
                                                                                        "},{"location":"security/usergrouprole/usergroupservices/","title":"User/group services","text":"

                                                                                        A user/group service provides the following information for users and groups:

                                                                                        • Listing of users
                                                                                        • Listing of groups, including users affiliated with each group
                                                                                        • User passwords

                                                                                        Many authentication providers will make use of a user/group service to perform authentication. In this case, the user/group service would be the database against which users and passwords are authenticated. Depending on how the Authentication chain is configured, there may be zero, one, or multiple user/group services active at any given time.

                                                                                        A user/group service may be read-only, providing access to user information but not allowing new users and groups to be added or altered. This may occur if a user/group service was configured to delegate to an external service for the users and groups database. An example of this would be an external LDAP server.

                                                                                        By default, GeoServer support three types of user/group services:

                                                                                        • XML<security_rolesystem_usergroupxml>---(Default) User/group service persisted as XML
                                                                                        • JDBC<security_rolesystem_usergroupjdbc>---User/group service persisted in database via JDBC
                                                                                        • LDAP<security_rolesystem_usergroupldap>---User/group service obtained from an LDAP repository

                                                                                        Other services can be added to GeoServer, such as that provided by the AuthKey<authkey> extension.

                                                                                        "},{"location":"security/usergrouprole/usergroupservices/#security_rolesystem_usergroupxml","title":"XML user/group service","text":"

                                                                                        The XML user/group service persists the user/group database in an XML file. This is the default behavior in GeoServer. This service represents the user database as XML, and corresponds to this XML schema.

                                                                                        Note

                                                                                        The XML user/group file, users.xml, is located in the GeoServer data directory, security/usergroup/<name>/users.xml, where <name> is the name of the user/group service.

                                                                                        The following is the contents of users.xml that ships with the default GeoServer configuration:

                                                                                        <userRegistry version=\"1.0\" xmlns=\"http://www.geoserver.org/security/users\">\n  <users>\n    <user enabled=\"true\" name=\"admin\" password=\"crypt1:5WK8hBrtrte9wtImg5i5fjnd8VeqCjDB\"/>\n  </users>\n  <groups/>\n</userRegistry>\n

                                                                                        This particular configuration defines a single user, admin, and no groups. By default, stored user passwords are encrypted using the weak PBE method.

                                                                                        For further information, please refer to configuring a user/group service in the Web administration interface.

                                                                                        "},{"location":"security/usergrouprole/usergroupservices/#security_rolesystem_usergroupjdbc","title":"JDBC user/group service","text":"

                                                                                        The JDBC user/group service persists the user/group database via JDBC, managing the user information in multiple tables. The user/group database schema is as follows:

                                                                                        Field Type Null Key name varchar(128) NO PRI password varchar(254) YES enabled char(1) NO Field Type Null Key username varchar(128) NO PRI propname varchar(64) NO PRI propvalue varchar(2048) YES Field Type Null Key name varchar(128) NO PRI enabled char(1) NO Field Type Null Key groupname varchar(128) NO PRI username varchar(128) NO PRI

                                                                                        The users table is the primary table and contains the list of users with associated passwords. The user_props table maps additional properties to a user. (See Users and Groups for more details.) The groups table lists all available groups, and the group_members table maps which users belong to which groups.

                                                                                        The default GeoServer security configuration is:

                                                                                        name password enabled Empty Empty Empty username propname propvalue Empty Empty Empty name enabled Empty Empty groupname username Empty Empty

                                                                                        For further information, please refer to configuring a user/group service in the Web administration interface.

                                                                                        "},{"location":"security/usergrouprole/usergroupservices/#security_rolesystem_usergroupldap","title":"LDAP user/group service","text":"

                                                                                        The LDAP user/group service is a read only user/group service that maps users and groups from an LDAP repository to GeoServer users and groups.

                                                                                        Users are extracted from a specific LDAP node, configured as the Users search base. Groups are extracted from a specific LDAP node, configured as the Groups search base. A user is mapped for every matching user and a group is mapped for every matching group.

                                                                                        It is possible to specify the attributes which contain the name of the group (such as cn), the user (such as uid) as well as the membership relationship between the two (such as member). However, it is also possible to specify specific filters to search for all users/groups (for example cn=*), find a user/group by name (for example cn={0}) and map users to groups (such as member={0}). These filters can also be automatically derived from the attribute names. Alternatively, the attribute names may be left empty if the filters are provided.

                                                                                        For users, additional properties (key/value pairs, see Users and Groups) may be populated from the LDAP Server by providing a comma separated list of property names.

                                                                                        Retrieving the user/group information can be done anonymously or using a given username/password if the LDAP repository requires it.

                                                                                        An example of configuration file (config.xml) for this type of role service is the following:

                                                                                        <org.geoserver.security.ldap.LDAPUserGroupServiceConfig>\n  <id>2c3e0e8d:154853796a3:-8000</id>\n  <name>myldapservice</name>\n  <className>org.geoserver.security.ldap.LDAPUserGroupService</className>\n  <serverURL>ldap://127.0.0.1:10389/dc=acme,dc=org</serverURL>\n  <groupSearchBase>ou=groups</groupSearchBase>\n  <groupFilter>cn={0}</groupFilter>\n  <groupNameAttribute>cn</groupNameAttribute>\n  <allGroupsSearchFilter>cn=*</allGroupsSearchFilter>\n  <groupSearchFilter>member={0}</groupSearchFilter>\n  <groupMembershipAttribute>member</groupMembershipAttribute>\n  <userSearchBase>ou=people</userSearchBase>\n  <userFilter>uid</userFilter>\n  <userNameAttribute>uid={0}</userNameAttribute>\n  <allUsersSearchFilter>uid=*</allUsersSearchFilter>\n  <useTLS>false</useTLS>\n  <bindBeforeGroupSearch>true</bindBeforeGroupSearch>\n  <user>admin</user>\n  <password>admin</password>\n  <passwordEncoderName>emptyPasswordEncoder</passwordEncoderName>\n  <passwordPolicyName>default</passwordPolicyName>\n  <populatedAttributes>email, telephone</populatedAttributes>\n</org.geoserver.security.ldap.LDAPUserGroupServiceConfig>\n

                                                                                        For further information, please refer to configuring a user/group service in the Web administration interface.

                                                                                        "},{"location":"security/webadmin/","title":"Security settings","text":"

                                                                                        GeoServer has a robust security subsystem, modeled on Spring Security. Most of the security features are available through the Web administration interface. This section describes how to configure GeoServer security through the web administration interface.

                                                                                        • Settings
                                                                                        • Authentication
                                                                                        • Passwords
                                                                                        • Users, Groups, Roles
                                                                                        • Data
                                                                                        • Services
                                                                                        • File Browsing
                                                                                        • CSRF Protection
                                                                                        "},{"location":"security/webadmin/auth/","title":"Authentication","text":"

                                                                                        This page manages the authentication options, including authentication providers and the authentication chain.

                                                                                        "},{"location":"security/webadmin/auth/#brute-force-attack-prevention","title":"Brute force attack prevention","text":"

                                                                                        GeoServer ships with a delay based brute force attack prevention system.

                                                                                        Brute force attack prevention settings

                                                                                        Option Description Enabled Whether the brute force attack prevention is enabled. Defaults to true. Minimum delay on failed authentication (seconds) Minimum number of seconds a failed login request will be made to wait before getting a response Maximum delay on failed authentication (seconds) Maximum number of seconds a failed login request will be made to wait before getting a response Excluded network masks Network masks identifying hosts that are excluded from brute force attack prevention. Can be empty, include specific IPs, or a list of network masks. Defaults to 127.0.0.1, the localhost. Maximum number of threads blocked on failed login delay Limits the number of threads that get delayed on failed login, should be set to a value less than the container's available response threads.

                                                                                        The mechanism works as follows:

                                                                                        • Each failed authentication request is made to wait between min and max seconds before getting an actual response back.
                                                                                        • Each attempt to authenticate the same username in parallel fails immediately, regardless of whether the credentials were valid or not, with a message stating concurrent login attempts are not allowed.

                                                                                        The first item slows down a single threaded attack to the point of making it ineffective (each failed attempt is logged along with the IP attempting access), the second item breaks multi-threaded attacks ability to scale. Login attempts are slowed down/blocked on all protocols, be either a OGC request, a REST call, or the UI.

                                                                                        A user trying to login from the user interface while another request is blocked waiting for the cool-down period to expire will see a message like the following:

                                                                                        Error message for parallel user interface login

                                                                                        A HTTP request (REST or OGC) will instead get an immediate 401 with a message like:

                                                                                        HTTP/1.1 401 User foo, 5896 concurrent login attempt(s) denied during the quiet period

                                                                                        A blessed set of IPs that can dodge the mechanism allows legit administrators to take control of the server even during an attack. The system only trusts the actual requestor IP, ignoring \"X-Forwarded-For\" headers, as they can be easily spoofed (this in turn requires the admin to access the system from a local network, without proxies in the middle, for the blessed IP to be recognized).

                                                                                        The maximum number of threads blocked configuration allows to setup the system so that an attacker can misuse the system to simply block all service threads, by issuing requests with random usernames (the system cannot determine if a username is valid or not, none of the authentication mechanisms provides this information for security reasons).

                                                                                        Considerations on how to setup the system:

                                                                                        • A small delay is normally more than enough to stop a brute force attack, resist the temptation of setting high delay values as they might end up blocking too many legitimate accounts and trigger the max blocked threads mechanism.
                                                                                        • Ensure that the excluded networks are well protected by other means.
                                                                                        • Set the maximum number of blocked threads to a value large allow peak hour legit logins (e.g., early morning when all the users start working) while still leaving room for successful authentication requests.
                                                                                        • A clustered/load balanced setup will not share the state of blocked logins, each host tracks its local login failures.
                                                                                        "},{"location":"security/webadmin/auth/#authentication-filters","title":"Authentication filters","text":"

                                                                                        This section manages the Authentication Filters (adding, removing, and editing). Several authentication filters are configured by default (anonymous, basic, form, rememberme), but others can be added to the list.

                                                                                        List of authentication filters

                                                                                        "},{"location":"security/webadmin/auth/#anonymous-access","title":"Anonymous access","text":"

                                                                                        By default, GeoServer will allow anonymous access to the Web administration interface. Without authentication, users will still be able to view the Layer Preview, capabilities documents, and basic GeoServer details. Anonymous access can by removing the anonymous authentication filter. If removed, anonymous users navigating to the GeoServer page will get an HTTP 401 status code, which typically results in a browser-based request for credentials.

                                                                                        "},{"location":"security/webadmin/auth/#credentials-from-headers-filter","title":"Credentials from Headers filter","text":"

                                                                                        This filter allows gathering user credentials (username and password) from request headers in a flexible and configurable way.

                                                                                        Creating a new authentication filter fetching credentials from request headers

                                                                                        Option Description Name Name of the filter Username Header Name of the Request Header containing the username Regular Expression for Username Regular Expression used to extract the username from the related Header. Must define a group that will match the username. Password Header Name of the Request Header containing the password Regular Expression for Password Regular Expression used to extract the password from the related Header. Must define a group that will match the password. Parse Arguments as Uri Components If checked username and password are URI decoded before being used as credentials"},{"location":"security/webadmin/auth/#authentication-providers","title":"Authentication providers","text":"

                                                                                        This section manages the security_auth_providers (adding, removing, and editing). The default authentication provider uses basic username/password authentication <../auth/providers.rst#security_auth_provider_userpasswd>_. JDBC and LDAP authentication can also be used.

                                                                                        Click Add new to create a new provider. Click an existing provider to edit its parameters.

                                                                                        List of authentication providers

                                                                                        "},{"location":"security/webadmin/auth/#usernamepassword-provider","title":"Username/password provider","text":"

                                                                                        The default new authentication provider uses a user/group service for authentication.

                                                                                        Creating a new authentication provider with a username and password

                                                                                        Option Description Name Name of the provider User Group Service Name of the user/group service associated with this provider. Can be any one of the active user/group services."},{"location":"security/webadmin/auth/#jdbc-provider","title":"JDBC provider","text":"

                                                                                        The configuration options for the JDBC authentication provider are illustrated below.

                                                                                        Configuring the JDBC authentication provider

                                                                                        Option Description Name Name of the JDBC connection in GeoServer User Group Service Name of the user/group service to use to load user information after the user is authenticated Driver class name JDBC driver to use for the database connection Connection URL JDBC URL to use when creating the database connection"},{"location":"security/webadmin/auth/#ldap-provider","title":"LDAP provider","text":"

                                                                                        The following illustration shows the configuration options for the LDAP authentication provider. The default option is to use LDAP groups for role assignment, but there is also an option to use a user/group service for role assignment. Depending on whether this option is selected, the page itself will have different options.

                                                                                        Configuring the LDAP authentication provider using LDAP groups for role assignment

                                                                                        Configuring the LDAP authentication provider using user/group service for authentication

                                                                                        +------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Option | Description | +==========================================+=============================================================================================================================================================================================================================================================================================================================================================================================================================================================================+ | Name | Name of the LDAP connection in GeoServer | +------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Server URL | URL for the LDAP server connection. It must include the protocol, host, and port, as well as the \"distinguished name\" (DN) for the root of the LDAP tree. | +------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | TLS | Enables a STARTTLS connection. (See the section on Secure LDAP connections.) | +------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | User DN pattern | Search pattern to use to match the DN of the user in the LDAP database. The pattern should contain the placeholder {0} which is injected with the uid of the user. Example: uid={0},ou=people. The root DN specified as port of the Server URL is automatically appended. | +------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | User Filter | LDAP Filter used to extract User data from LDAP database. Used alternatively to User DN pattern and combined with User Format to separate bind and user data extraction handling. Example: (userPrincipalName={0}). Gets user data searching for a single record matching the filter. This may contain two placeholder values: {0}, the full DN of the user, for example uid=bob,ou=people,dc=acme,dc=com {1}, the uid portion of the full DN, for example bob. | +------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | User Format | String formatter used to build username used for binding. Used alternatively to User DN pattern and combined with User Filter to separate bind and user data extraction handling. Example: {0}@domain. Binds user with the username built applying the format. This may contain one placeholder: {0}, the username, for example bob | +------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Use LDAP groups for authorization | Specifies whether to use LDAP groups for role assignment | +------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Bind before group search | Specifies whether to bind to LDAP server with the user credentials before doing group search | +------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Group search base | Relative name of the node in the tree to use as the base for LDAP groups. Example: ou=groups. The root DN specified as port of the Server URL is automatically appended. Only applicable when the Use LDAP groups for authorization( parameter ischecked. | +------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Group search filter | Search pattern for locating the LDAP groups a user belongs to. This may contain two placeholder values: {0}, the full DN of the user, for example uid=bob,ou=people,dc=acme,dc=com {1}, the uid portion of the full DN, for example bob. Only applicable when the Use LDAP groups for authorization( parameter ischecked. | +------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Admin Group | Name of the group to be mapped to Administrator role (defaults to ADMINISTRATOR). Example: ADMIN. Adds the role ROLE_ADMINISTRATOR if the user belongs to a group named ADMIN (case insensitive) | +------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Group Admin Group | Name of the group to be mapped to Group Administrator role (defaults to GROUP_ADMIN). Example: GROUPADMIN. Adds the role ROLE_GROUP_ADMIN if the user belongs to a group named GROUPADMIN (case insensitive) | +------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | User Group Service | The user/group service to use for role assignment. Only applicable when the Use LDAP groups for authorization parameter is cleared. | +------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Enable Hierarchical groups search | Specifies whether to use Hierarchical LDAP groups search for role assignment | +------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Max depth for hierarchical groups search | Specifies the max group search depth level to use with Hierarchical LDAP groups search. Use -1 for no limit. Only applicable when the *Enable Hierarchical groups search( parameter ischecked. | +------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Nested group search filter | Search pattern for locating parent LDAP groups a group belongs to. This may contain two placeholder values: | | | | | | {0}, the full DN of the user, for example cn=it,ou=groups,dc=acme,dc=com | | | | | | {1}, the cn portion of the full DN, for example it. Only applicable when the Enable Hierarchical groups search( parameter ischecked*. | +------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+

                                                                                        "},{"location":"security/webadmin/auth/#authentication-chain","title":"Authentication chain","text":"

                                                                                        This section selects the authentication chain. Currently, only one default authentication chain is available. For further information about the default chain, please refer to Authentication chain.

                                                                                        Selecting the authentication chain

                                                                                        "},{"location":"security/webadmin/csrf/","title":"CSRF Protection","text":"

                                                                                        The GeoServer web admin employs a CSRF (Cross-Site Request Forgery) protection filter that will block any form submissions that didn't appear to originate from GeoServer. This can sometimes cause problems for certain proxy configurations.

                                                                                        Note

                                                                                        Symptoms of this problem may include the WPS request builder (and other wicket pages) failing with an HTTP status of 403 and the message \"Origin does not correspond to request\". However, you may need to view the page response in a debugger to see this, to the end user it will appear as if the form section of the page is just missing.

                                                                                        To allow-list your proxy with the CSRF filter, you can use the GEOSERVER_CSRF_WHITELIST property. This property is a comma-separated list of domains, of the form <domainname>.<TLD>, and can contain a subdomains. Alternatively, you can disable the CSRF filter by setting the GEOSERVER_CSRF_DISABLED property to true.

                                                                                        Each of these properties is set through one of the standard means:

                                                                                        • web.xml :

                                                                                          <context-param>\n  <param-name>GEOSERVER_CSRF_WHITELIST</param-name>\n  <param-value>example.org</param-value>\n</context-param>\n
                                                                                        • System property :

                                                                                          -DGEOSERVER_CSRF_WHITELIST=example.org\n
                                                                                        • Environment variable :

                                                                                          export GEOSERVER_CSRF_WHITELIST=example.org\n
                                                                                        "},{"location":"security/webadmin/data/","title":"Data","text":"

                                                                                        This section provides access to security settings related to data management and Layer security. Data access is granted to roles, and roles are granted to users and groups.

                                                                                        "},{"location":"security/webadmin/data/#rules","title":"Rules","text":"

                                                                                        There are two rules available by default, but they don't provide any restrictions on access by default. The first rule *.*.r, applied to all roles, states that any operation in any resource in any workspace can be read. The second rule, *.*.w, also applied to all roles, says the same for write access.

                                                                                        Rules for data access

                                                                                        Clicking an existing rule will open it for editing, while clicking the Add a new rule link will create a new rule.

                                                                                        Creating a new rule

                                                                                        Editing a layer group rule

                                                                                        Option Description Global layer group rule If checked, switches the editor to create/edit a rule about a global layer group (and will remove the layer configuration as a result) Workspace Sets the allowed workspace for this rule. Options are * (all workspaces), or the name of each workspace. Layer and groups Sets the allowed layer/groups for this rule. Options are * (all layers/groups in the chosen workspace), or the name of each layer in the above workspace. Will be disabled until the workspace is set. Access mode Specifies whether the rule refers to either Read or Write mode Grant access to any role If selected, the rule will apply to all roles, with no need to specify Role list Full list of roles, including a list of roles to which the rule is associated. Association can be toggled here via the arrow buttons. This option is not applied if Grant access to any role is checked. Add a new role Shortcut to adding a new role"},{"location":"security/webadmin/data/#catalog-mode","title":"Catalog Mode","text":"

                                                                                        This mode configures how GeoServer will advertise secured layers and behave when a secured layer is accessed without the necessary privileges. There are three options: HIDE, MIXED, and CHALLENGE. For further information on these options, please see the section on Layer security.

                                                                                        Catalog mode

                                                                                        "},{"location":"security/webadmin/filebrowse/","title":"File Browsing","text":"

                                                                                        The GeoServer web admin employs a file browser dialog that will expose locations of the file system other than the GeoServer directory. These locations include the root of the file system and the users home directory. In highly secure and multi-tenant environments disabling this feature may be desired.

                                                                                        The property GEOSERVER_FILEBROWSER_HIDEFS can be used to disable this functionality. When set to true only the GeoServer data directory will be exposed through the file browser.

                                                                                        The property is set through one of the standard means:

                                                                                        • web.xml :

                                                                                          <context-param>\n  <param-name>GEOSERVER_FILEBROWSER_HIDEFS</param-name>\n  <param-value>true</param-value>\n</context-param>\n
                                                                                        • System property :

                                                                                          -DGEOSERVER_FILEBROWSER_HIDEFS=true\n
                                                                                        • Environment variable :

                                                                                          export GEOSERVER_FILEBROWSER_HIDEFS=true\n
                                                                                        "},{"location":"security/webadmin/passwords/","title":"Passwords","text":"

                                                                                        This page configures the various options related to Passwords, the Keystore password, and Password policies.

                                                                                        Note

                                                                                        User passwords may be changed in the Users dialog box accessed from the Users, Groups, Roles page.

                                                                                        "},{"location":"security/webadmin/passwords/#security_webadmin_masterpasswordprovider","title":"Active keystore password provider","text":"

                                                                                        This option sets the active keystore password provider, via a list of all available keystore password providers.

                                                                                        Active keystore password provider

                                                                                        To change the keystore password click the Change password link.

                                                                                        Changing the keystore password

                                                                                        Warning

                                                                                        First thing to do as an Administrator of the System, would be to dump the Keystore Password generated by GeoServer, store it somewhere not accessible by anyone, and delete any security/masterpw.info or whatever file you used to dump the password in clear.

                                                                                        "},{"location":"security/webadmin/passwords/#keystore-password-providers","title":"Keystore Password Providers","text":"

                                                                                        This section provides the options for adding, removing, and editing keystore password providers.

                                                                                        Keystore password provider list

                                                                                        Note

                                                                                        By default the login to Admin GUI and REST APIs with Keystore Password is disabled. In order to enable it you will need to manually change the Keystore Password Provider config.xml, usually located into security/masterpw/default/config.xml, by adding the following statement:

                                                                                        ``<loginEnabled>true</loginEnabled>``\n
                                                                                        "},{"location":"security/webadmin/passwords/#password-policies","title":"Password policies","text":"

                                                                                        This section configures the various Password policies available to users in GeoServer. New password policies can be added or renamed, and existing policies edited or removed.

                                                                                        By default there are two password policies in effect, default and root. The default password policy, intended for most GeoServer users, does not have any active password constraints. The keystore password policy, intended for the Root account, specifies a minimum password length of eight characters. Password policies are applied to users via the user/group service.

                                                                                        List of password policies

                                                                                        Clicking an existing policy enables editing, while clicking the Add new button will create a new password policy.

                                                                                        Creating a new password policy

                                                                                        "},{"location":"security/webadmin/services/","title":"Services","text":"

                                                                                        This section provides access to the settings for Service Security. GeoServer can limit access based on OWS services (WFS, WMS, etc.) and their specific operations (GetCapabilities, GetMap, and so on).

                                                                                        By default, no service-based security is in effect in GeoServer. However rules can be added, removed, or edited here.

                                                                                        Service access rules list

                                                                                        Clicking the Add a new rule link will create a new rule.

                                                                                        New service rule

                                                                                        Option Description Service Sets the OWS service for this rule. Options are *, meaning all services, wcs, wfs, or wms. Method Sets the specific operation for this rule. Options depend on the Service, but include *, meaning all operations, as well as every service operation known to GeoServer, such as Capabilities, Transaction, GetMap, and more. Grant access to any role If selected, the rule will apply to all roles (no need to specify which ones) Role list Full list of roles, including a list of roles to which the rule is associated. Association can be switched here via the arrow buttons. This option is not applied if Grant access to any role is checked. Add a new role Shortcut to adding a new role"},{"location":"security/webadmin/settings/","title":"Settings","text":"

                                                                                        The Settings page controls the global GeoServer security settings.

                                                                                        Security Settings page

                                                                                        "},{"location":"security/webadmin/settings/#active-role-service","title":"Active role service","text":"

                                                                                        This option sets the active role service (provides information about roles). Role services are managed on the Users, Groups, Roles page. There can be only one active role service at one time.

                                                                                        "},{"location":"security/webadmin/settings/#encryption","title":"Encryption","text":"

                                                                                        The GeoServer user interface (UI) can sometimes expose parameters in plain text inside the URLs. As a result, it may be desirable to encrypt the URL parameters. To enable encryption, select Encrypt web admin URL parameters. This will configure GeoServer to uses a PBE-based Password encryption.

                                                                                        For example, with this feature enabled, the page:

                                                                                        http://GEOSERVER/web/?wicket:bookmarkablePage=:org.geoserver.security.web.SecuritySettingsPage\n

                                                                                        would now be found at the following URL:

                                                                                        http://GEOSERVER/web/?x=hrTNYMcF3OY7u4NdyYnRanL6a1PxMdLxTZcY5xK5ZXyi617EFEFCagMwHBWhrlg*ujTOyd17DLSn0NO2JKO1Dw\n
                                                                                        "},{"location":"security/webadmin/settings/#password-encryption","title":"Password encryption","text":"

                                                                                        This setting allows you to select the type of Password encryption used for passwords. The options are Plain text, Weak PBE, or Strong PBE.

                                                                                        If Strong PBE is not available as part of the JVM, a warning will display and the option will be disabled. To enable Strong PBE, you must install external policy JARs that support this form of encryption. See the section on Password encryption for more details about these settings.

                                                                                        Warning if Strong PBE is not available

                                                                                        "},{"location":"security/webadmin/ugr/","title":"Users, Groups, Roles","text":"

                                                                                        This section provides the configuration options for User/group services and Role services. In addition, users, groups, and roles themselves and can be added, edited, or removed. A great deal of configuration can be accomplished in this section and related pages.

                                                                                        "},{"location":"security/webadmin/ugr/#security_webadmin_usergroupservices","title":"User Group Services","text":"

                                                                                        In this menu, user/group services can be added, removed, or edited. By default, there is one user/group service in GeoServer, which is XML-based. It is encrypted with Weak PBE and uses the default password policy. It is also possible to have a user/group service based on JDBC, with or without JNDI.

                                                                                        User/group services

                                                                                        Clicking an existing user/group service will enable editing, while clicking the Add new link will configure a new user/group service.

                                                                                        There are three tabs for configuration: Settings, Users, and Groups.

                                                                                        Note

                                                                                        When creating a new user/group service, the form filled out initially can be found under the Settings tab.

                                                                                        "},{"location":"security/webadmin/ugr/#add-new-xml-usergroup-service","title":"Add new XML user/group service","text":"

                                                                                        To add a new XML user/group service, click the Add new link. XML is the default option. The following figure shows the configuration options for an XML user/group service.

                                                                                        Adding an XML user/group service

                                                                                        Option Description Name The name of the user/group service Password encryption Sets the type of Password encryption. Options are Plain text, Weak PBE, Strong PBE, and Digest. Password policy Sets the password policy. Options are any active password policies as set in the Passwords section. XML filename Name of the file that will contain the user and group information. Default is users.xml in the security/usergroup/<name_of_usergroupservice> directory. Enable schema validation If selected, forces schema validation to occur every time the XML file is read. This option is useful when editing the XML file by hand. File reload interval Defines the frequency (in milliseconds) in which GeoServer will check for changes to the XML file. If the file is found to have been modified, GeoServer will recreate the user/group database based on the current state of the file. This value is meant to be set in cases where the XML file contents might change \"out of process\" and not directly through the web admin interface. The value is specified in milliseconds. A value of 0 disables any checking of the file."},{"location":"security/webadmin/ugr/#add-new-jdbc-usergroup-service","title":"Add new JDBC user/group service","text":"

                                                                                        To add a new JDBC user/group service, click the Add new link, and then the JDBC option at the top of the following form. The following figure shows the configuration options for a JDBC user/group service.

                                                                                        Adding a user/group service via JDBC

                                                                                        Option Description Name Name of the JDBC user/group service in GeoServer Password encryption The method to used to encrypt user passwords Password policy The policy to use to enforce constraints on user passwords JNDI When unchecked, specifies a direct connection to the database. When checked, specifies an existing connection located through JNDI. Driver class name JDBC driver to use for the database connection Connection URL Specifies the JDBC URL to use when creating the database connection Username Username to use when connecting to the database Password Password to use when connecting to the database Create database tables Specifies whether to create all the necessary tables in the underlying database Data Definition Language (DDL) file Specifies a custom DDL file to use for creating tables in the underlying database, for cases where the default DDL statements fail on the given database. If left blank, internal defaults are used. Data Manipulation Language (DML) file Specifies a custom DML file to use for accessing tables in the underlying database, for cases where the default DML statements fail on the given database. If left blank, internal defaults are used.

                                                                                        In addition to the parameters listed above, the following additional parameter will apply when the JNDI flag is set.

                                                                                        Adding a user/group service via JDBC with JNDI

                                                                                        Option Description JNDI resource name JNDI name used to locate the database connection."},{"location":"security/webadmin/ugr/#add-new-ldap-usergroup-service","title":"Add new LDAP user/group service","text":"

                                                                                        To add a new LDAP user/group service, click the Add new link, and then the LDAP option at the top of the following form. The following figure shows the configuration options for a LDAP user/group service.

                                                                                        Adding a user/group service via LDAP

                                                                                        +---------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Option | Description | +===================================================+==============================================================================================================================================================================+ | Name | Name of the LDAP role service in GeoServer | +---------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Password encryption | The method to used to encrypt user passwords | +---------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Password policy | The policy to use to enforce constraints on user passwords | +---------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Server URL | URL for the LDAP server connection. It must include the protocol, host, and port, as well as the \"distinguished name\" (DN) for the root of the LDAP tree. | +---------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | TLS | Enables a STARTTLS connection. (See the section on Secure LDAP connections.) | +---------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Group search base | Relative name of the node in the tree to use as the base for LDAP groups. Example: ou=groups. The root DN specified as port of the Server URL is automatically appended. | +---------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Filter to search all groups | Sets the LDAP filter for search all groups available. Leave blank to derive from attribute. | +---------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Filter to search group by name | Sets the LDAP filter for search a group by its name. Leave blank to derive from attribute. | +---------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Attribute which contains the name of the group | Sets attribute containing the group name. Leave blank to derive from name filter. | +---------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Query format to retrieve the user/group mapping | Query format used for mapping user/group memberships. Leave blank to derive from attribute. This may contain some placeholder values: | | | | | | {0}, the username of the user, for example bob. | | | | | | {1}, the full DN of the user, for example uid=bob,ou=users. | +---------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Attribute name to retrieve the user/group mapping | Attribute name used for mapping user/group memberships. Leave blank to derive from filter. | +---------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | User search base | LDAP search base for users. | +---------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Filter to search all users | Sets the filter for search all available users. Leave blank to derive from attribute. | +---------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Filter to search user by name | Sets the filter format for search a user by its name. Leave blank to derive from attribute. | +---------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Attribute which contains the name of the user | Sets the attribute containing the name for users. Leave blank to derive from name filter. | +---------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | List of attributes to populate | Sets a comma separated list of attributes to populate on users. | +---------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Authenticated onto the LDAP before querying | When checked all LDAP searches will be done in authenticated mode, using the credentials given with the Username and Password options | +---------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Username | Username to use when connecting to the LDAP server. Only applicable when the Authenticated onto the LDAP before querying parameter is checked. | +---------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Password | Password to use when connecting to the LDAP server. Only applicable when the Authenticated onto the LDAP before querying parameter is checked. | +---------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Enable Hierarchical groups search | When checked all LDAP group searches will use hierarchical mode, retrieving LDAP parent groups too. | +---------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Max depth for hierarchical groups search | Max depth number for hierarchical LDAP groups search, use -1 for infinite depth. Only applicable when the Enable Hierarchical groups search parameter is checked. | +---------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Nested group search filter | LDAP search pattern for searching parent groups. Only applicable when the Enable Hierarchical groups search parameter is checked. | +---------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+

                                                                                        "},{"location":"security/webadmin/ugr/#edit-usergroup-service","title":"Edit user/group service","text":"

                                                                                        Once the new user/group service is added (either XML or JDBC), clicking on it in the list of user/group services will allow additional options to be specified, such as the users and groups associated with the service.

                                                                                        There are three tabs in the resulting menu: Settings, Users, and Groups. The Settings tab is identical to that found when creating the user/group service, while the others are described below.

                                                                                        The Users tab provides options to configure users in the user/group service.

                                                                                        Users tab

                                                                                        Clicking a username will allow its parameters to be changed, while clicking the Add new link will create a new user.

                                                                                        "},{"location":"security/webadmin/ugr/#security_webadmin_users","title":"Add user","text":"

                                                                                        Creating or editing a user

                                                                                        Option Description User name The name of the user Enabled When selected, will enable the user to authenticate Password The password for this user. Existing passwords will be obscured when viewed. Confirm password To set or change the password enter the password twice. User properties Key/value pairs associated with the user. Used for associating additional information with the user. Group list Full list of groups, including list of groups to which the user is a member. Membership can be toggled here via the arrow buttons. Add a new group Shortcut to adding a new group. Also available in the Groups tab. Role list Full list of roles, including a list of roles to which the user is associated. Association can be toggled here via the arrow buttons. Add a new role Shortcut to adding a new role List of current roles for the user List of current roles associated with the user. Click a role to enable editing.

                                                                                        The Groups tab provides configuration options for groups in this user/group service. There are options to add and remove a group, with an additional option to remove a group and the roles associated with that group.

                                                                                        Groups tab

                                                                                        "},{"location":"security/webadmin/ugr/#security_webadmin_groups","title":"Remove User","text":"

                                                                                        There are two related buttons that are responsible for removing users: Remove Selected, and Remove Selected and remove role associations.

                                                                                        • Remove Selected removes user from users.xml and leave untouched roles.xml.
                                                                                        • Remove Selected and remove role associations removes user from users.xml and also removes user and associated role to user from roles.xml.

                                                                                        Users tab

                                                                                        "},{"location":"security/webadmin/ugr/#add-group","title":"Add group","text":"

                                                                                        Creating or editing a group

                                                                                        Option Description Group name The name of the group Enabled When selected the group will be active Role list Full list of roles, including a list of roles to which the group is associated. Association can be toggled here via the arrow buttons. Add a new role Shortcut to adding a new role

                                                                                        In this menu, user/group services can be added, removed, or edited. By default, there is one user/group service in GeoServer, which is XML-based. It is encrypted with Weak PBE and uses the default password policy. It is also possible to have a user/group service based on JDBC with or without JNDI.

                                                                                        "},{"location":"security/webadmin/ugr/#security_webadmin_roleservices","title":"Role services","text":"

                                                                                        In this menu, role services can be added, removed, or edited. By default, the active role service in GeoServer is XML-based, but it is also possible to have a role service based on JDBC, with or without JNDI.

                                                                                        The Administrator role is called ROLE_ADMINISTRATOR.

                                                                                        Role services

                                                                                        Clicking an existing role service will open it for editing, while clicking the Add new link will configure a new role service.

                                                                                        There are two pages for configuration: Settings and Roles.

                                                                                        Note

                                                                                        When creating a new role service, the form filled out initially can be found under the Settings tab.

                                                                                        "},{"location":"security/webadmin/ugr/#add-new-xml-role-service","title":"Add new XML role service","text":"

                                                                                        To add a new XML role service, click the Add new link. XML is the default option. The following figure shows the configuration options for an XML role service.

                                                                                        Adding an XML role service

                                                                                        Option Description Name The name of the role service Administrator role The name of the role that performs the administrator functions XML filename Name of the file that will contain the role information. Default is roles.xml in the security/role/<name_of_roleservice> directory. File reload interval Defines the frequency (in milliseconds) in which GeoServer will check for changes to the XML file. If the file is found to have been modified, GeoServer will recreate the user/group database based on the current state of the file. This value is meant to be set in cases where the XML file contents might change \"out of process\" and not directly through the web admin interface. The value is specified in milliseconds. A value of 0 disables any checking of the file."},{"location":"security/webadmin/ugr/#add-new-jdbc-role-service","title":"Add new JDBC role service","text":"

                                                                                        To add a new XML role service, click the Add new link, and then the JDBC option at the top of the following form. The following figure shows the configuration options for a JDBC role service.

                                                                                        Adding a role service via JDBC

                                                                                        Option Description Name Name of the JDBC role service in GeoServer Administrator role The name of the role that performs the administrator function JNDI When unchecked, specifies a direct connection to the database. When checked, specifies an existing connection located through JNDI. Driver class name JDBC driver to use for the database connection Connection URL Specifies the JDBC URL to use when creating the database connection Username Username to use when connecting to the database Password Password to use when connecting to the database Create database tables Specifies whether to create all the necessary tables in the underlying database Data Definition Language (DDL) file Specifies a custom DDL file to use for creating tables in the underlying database, for cases where the default DDL statements fail on the given database. If left blank, internal defaults are used. Data Manipulation Language (DML) file Specifies a custom DML file to use for accessing tables in the underlying database, for cases where the default DML statements fail on the given database. If left blank, internal defaults are used.

                                                                                        In addition to the parameters listed above, the following additional parameter will apply when the JNDI flag is set.

                                                                                        Adding a role service via JDBC with JNDI

                                                                                        Option Description JNDI resource name JNDI name used to locate the database connection."},{"location":"security/webadmin/ugr/#add-new-ldap-role-service","title":"Add new LDAP role service","text":"

                                                                                        To add a new LDAP role service, click the Add new link, and then the LDAP option at the top of the following form. The following figure shows the configuration options for a LDAP role service.

                                                                                        Adding a role service via LDAP

                                                                                        Option Description Name Name of the LDAP role service in GeoServer Administrator role The name of the role that performs the administrator function Group administrator role The name of the role that performs the group administrator function Server URL URL for the LDAP server connection. It must include the protocol, host, and port, as well as the \"distinguished name\" (DN) for the root of the LDAP tree. TLS Enables a STARTTLS connection. (See the section on Secure LDAP connections.) Group search base Relative name of the node in the tree to use as the base for LDAP groups. Example: ou=groups. The root DN specified as port of the Server URL is automatically appended. Group user membership search filter Search pattern for extracting users of a LDAP group a user belongs to. This may contain some placeholder values: {0}, the username of the user, for example bob. {1}, the full DN of the user, for example uid=bob,ou=users. To use this placeholder, the Filter used to lookup user needs to be defined, so that the dn of a user can be extracted from its username. All groups search filter Search pattern for locating the LDAP groups to be mapped to GeoServer roles inside the Group search base root node Filter used to lookup user. optional filter used to extract a user dn, to be used together with Group user membership search filter when the {1} placeholder is specified. This may contain a placeholder value: {0}, the username of the user, for example bob. Role prefix Prefix appended in front of role names extracted from the LDAP. If left blank, no prefix will be inserted. Convert Role To Upper Case If selected all role names extracted from the LDAP will be converted to upper case. Authenticate to extract roles When checked all LDAP searches will be done in authenticated mode, using the credentials given with the Username and Password options Username Username to use when connecting to the LDAP server. Only applicable when the Authenticate to extract roles parameter is checked. Password Password to use when connecting to the LDAP server. Only applicable when the Authenticate to extract roles parameter is checked. Enable Hierarchical groups search When checked all LDAP group searches will use hierarchical mode, retrieving LDAP parent groups too. Max depth for hierarchical groups search Max depth number for hierarchical LDAP groups search, use -1 for infinite depth. Only applicable when the Enable Hierarchical groups search parameter is checked. Nested group search filter LDAP search pattern for searching parent groups. Only applicable when the Enable Hierarchical groups search parameter is checked."},{"location":"security/webadmin/ugr/#edit-role-service","title":"Edit role service","text":"

                                                                                        Once the new role service is added (either XML or JDBC), clicking it in the list of role services will allow the additional options to be specified, such as the roles associated with the service.

                                                                                        There are two tabs in the resulting menu: Settings and Roles. The Settings tab is identical to that found when creating the role service, while the Roles tab is described below.

                                                                                        Roles tab

                                                                                        Clicking a role will allow its parameters to be changed, while clicking the Add new link will create a new role.

                                                                                        "},{"location":"security/webadmin/ugr/#security_webadmin_roles","title":"Add role","text":"

                                                                                        Creating or editing a role

                                                                                        Option Description Role name The name of role. Convention is uppercase, but is not required. Parent roles The role that this role inherits. See the section on Roles for more information on inheritance. Role parameters Key/value pairs associated with the role. Used for associating additional information with the role."},{"location":"services/","title":"Services","text":"

                                                                                        GeoServer serves data using standard protocols established by the Open Geospatial Consortium:

                                                                                        • The Web Map Service (WMS) supports requests for map images (and other formats) generated from geographical data.
                                                                                        • The Web Feature Service (WFS) supports requests for geographical feature data (with vector geometry and attributes).
                                                                                        • The Web Coverage Service (WCS) supports requests for coverage data (rasters).

                                                                                        These services are the primary way that GeoServer supplies geospatial information.

                                                                                        • Web Map Service (WMS)
                                                                                        • Web Feature Service (WFS)
                                                                                        • Web Coverage Service (WCS)
                                                                                        • Web Processing Service (WPS)
                                                                                        • Catalog Services for the Web (CSW)
                                                                                        • Web Map Tile Service (WMTS)
                                                                                        "},{"location":"services/csw/","title":"Catalog Services for the Web (CSW)","text":"

                                                                                        This section discusses the Catalog Services for Web (CSW) optional extension. With this extension, GeoServer supports retrieving and displaying items from the GeoServer catalog using the CSW service.

                                                                                        For more information on CSW, please refer to OGC OpenGIS Implementation Specification 07-006r1 and the OGC tutorial on CSW.

                                                                                        • Installing Catalog Services for Web (CSW)
                                                                                        • Catalog Services for the Web (CSW) features
                                                                                        • DirectDownload

                                                                                        See the Catalog Services for the Web (CSW) ISO Metadata tutorial for a tutorial on how to use the CSW Metadata Module.

                                                                                        "},{"location":"services/csw/directdownload/","title":"DirectDownload","text":"

                                                                                        DirectDownload is a new operation (since GeoServer 2.9.x) supported by the CSW service.

                                                                                        In the Meteorology, Oceanography and Earth Observation domains, layers are usually based on complex NetCDF/GRIB files. Protocols such as WCS are set up to allow slice, rescale and reprojection of data, but not to preserve the original data as is.

                                                                                        This new operation allows direct download of the raw data for that layer. If the DirectDownload capability is enabled for a Coverage layer, the CSW record will be updated to contain links pointing back to the CSW service, using the DirectDownload vendor operation that will assemble the files for the requested resource, zip them, and send the result back to the requester.

                                                                                        The download links (one for each data file composing the layer plus a link to get all the files composing the layer) are added as new entries in CSW records:

                                                                                        • as additional term-references element for a Dublin Core schema
                                                                                        • as additional OnlineResource for ISO Metadata

                                                                                        Those links also contain the validity domain for the file such as envelope/time/elevation/custom dimensions (when present) for multidimensional layers.

                                                                                        "},{"location":"services/csw/directdownload/#configuration","title":"Configuration","text":"

                                                                                        DirectDownload capability can be activated as default for all layers, as global CSW configuration. Go into the CSW service panel and click on the enable DirectDownload checkbox if you want it enabled for all layers:

                                                                                        DirectDownload configuration (Service level)

                                                                                        From this section you can also set a download size limit value (0 means no limit). The specified value represents the maximum size (in kilobytes) of the sum of the sizes of the raw data referred to by a single download link. (You can think about the case of a download link referring to the whole layer data which may contain a wide set of files).

                                                                                        Note that the size check is performed on the raw data files prior to any compression.

                                                                                        "},{"location":"services/csw/directdownload/#per-layer-configuration","title":"Per Layer configuration","text":"

                                                                                        DirectDownload capability can also be enabled/disabled for a specific layer, which will override the global CSW configuration.

                                                                                        Go to the publishing tab of the layer.

                                                                                        Layer publishing section

                                                                                        Look for the DirectDownload settings section.

                                                                                        DirectDownload configuration (Layer level)

                                                                                        The configuration of this parameter follows the same rules as shown for the CSW configuration panel.

                                                                                        "},{"location":"services/csw/directdownload/#getrecords-example","title":"GetRecords example","text":"

                                                                                        A GetRecords response containing a layer with DirectDownload enabled, may result having a piece like this (using ISO Metadata output schema<csw_iso>):

                                                                                        ...\n<gmd:CI_OnlineResource>\n  <gmd:linkage>\n    <gmd:URL>\n    http://localhost:8080/geoserver/ows?service=CSW&version=2.0.2&request=DirectDownload&resourceId=geosolutions:Reflectivity_height_above_ground&file=82643c5bf682f67ef8b7de737b90ada759965cd8-samplefile.grib2&ENVELOPE=-2699073.2421875,-1588806.0302734375,2697926.7578125,1588193.9697265625&TIME=2015-06-23T00:00:00.000Z/2015-06-23T00:00:00.000Z&HEIGHT_ABOVE_GROUND=1000.0/4000.0\n    </gmd:URL>\n  </gmd:linkage>\n</gmd:CI_OnlineResource>\n...\n

                                                                                        That URL allows the direct download of the indicated file. Note that the filename has a SHA-1 header to avoid publishing the underlying file system structure paths.

                                                                                        "},{"location":"services/csw/features/","title":"Catalog Services for the Web (CSW) features","text":""},{"location":"services/csw/features/#supported-operations","title":"Supported operations","text":"

                                                                                        The following standard CSW operations are currently supported:

                                                                                        • GetCapabilities
                                                                                        • GetRecords
                                                                                        • GetRecordById
                                                                                        • GetDomain
                                                                                        • DescribeRecord

                                                                                        (Starting with GeoServer 2.9.x, a new vendor operation has been added: DirectDownload)

                                                                                        The Internal Catalog Store supports filtering on both full x-paths as well as the \"Queryables\" specified in GetCapabilities.

                                                                                        "},{"location":"services/csw/features/#catalog-stores","title":"Catalog stores","text":"

                                                                                        The default catalog store is the Internal Catalog Store, which retrieves information from the GeoServer's internal catalog. The Simple Catalog Store (simple-store module) adds an alternative simple store which reads the catalog data directly from files (mainly used for testing).

                                                                                        If there are multiple catalog stores present (for example, when the Simple Catalog Store module is loaded), set the Java system property DefaultCatalogStore to make sure that the correct catalog store will be used. To use the Internal Catalog Store, this property must be set to:

                                                                                        DefaultCatalogStore=org.geoserver.csw.store.internal.InternalCatalogStore\n

                                                                                        To use the Simple Catalog Store:

                                                                                        DefaultCatalogStore=org.geoserver.csw.store.simple.GeoServerSimpleCatalogStore\n
                                                                                        "},{"location":"services/csw/features/#supported-schemes","title":"Supported schemes","text":"

                                                                                        The Internal Catalog Store currently supports two metadata schemes:

                                                                                        • Dublin Core, by default.
                                                                                        • ISO Metadata Profile, if you install the Catalog Services for the Web (CSW) - ISO Metadata Profile Community Module.
                                                                                        "},{"location":"services/csw/features/#csw_mapping_file","title":"Mapping Files","text":"

                                                                                        Mapping files are located in the csw directory inside the GeoServer data directory. Assuming that each layer is mapped to a single record, each mapping file has the exact name of the record type name, combined with the .properties extension. For example:

                                                                                        • Dublin Core mapping can be found in the file csw/Record.properties inside the data directory.
                                                                                        • ISO Metadata mapping can be found in the file csw/MD_Metadata.properties inside the data directory (see Catalog Services for the Web (CSW) - ISO Metadata Profile Community Module).

                                                                                        There is also the possibility of having mapping each layer to multiple records. In this case, one would have multiple mapping files per type. Each mapping file will be applied to each layer. For instance, if there are three ISO Metadata mapping files, each layer will generate three ISO Metadata records, one for each mapping file. Practically, the different mapping files must be given unique names, encoded in the file name after the type name, followed by a dash, and before the extension. At most one mapping file per type can be nameless (as in the above example). For instance, one could have the following files in the csw directory:

                                                                                        • csw/Record.properties
                                                                                        • csw/Record-otherRecord.properties
                                                                                        • csw/Record-thirdRecord.properties
                                                                                        • csw/MD_Metadata.properties
                                                                                        • csw/MD_Metadata-otherRecord.properties
                                                                                        • csw/MD_Metadata-thirdRecord.properties

                                                                                        In this example, each of the two types have three mapping files: one nameless, one called otherRecord and one called thirdRecord. Each layer will thus generate three records for each type. Geoserver will assume that mappings of different type but with the same name refer to the same record (in another format). (This is only relevant for GetRecords requests where outputSchema and typeNames do not match\u00b8 which is unusual). The user is responsible for ensuring that identifiers are unique accross all mappings of the same record type.

                                                                                        The mapping files take the syntax from Java properties files. The left side of the equals sign specifies the target field name or path in the metadata record, paths being separated with dots. The right side of the equals sign specifies any CQL expression that denotes the value of the target property. The CQL expression is applied to each ResourceInfo object in the catalog and can retrieve all properties from this object. These expressions can make use of literals, properties present in the ResourceInfo object, and all normal CQL operators and functions. There is also support for complex data structures such as Maps using the dot notation and Lists using the bracket notation (Example mapping files are given below).

                                                                                        The properties in the ResourceInfo object that can be used are:

                                                                                        name\nqualifiedName\nnativeName\nqualifiedNativeName\nalias\ntitle\nabstract\ndescription\nmetadata.?\nnamespace\nnamespace.prefix\nnamespace.name\nnamespace.uri\nnamespace.metadata.?\nkeywords\nkeywords[?]\nkeywords[?].value\nkeywords[?].language\nkeywords[?].vocabulary\nkeywordValues\nkeywordValues[?]\nmetadataLinks\nmetadataLinks[?]\nmetadataLinks[?].id\nmetadataLinks[?].about\nmetadataLinks[?].metadataType\nmetadataLinks[?].type\nmetadataLinks[?].content\nlatLonBoundingBox\nlatLonBoundingBox.dimension\nlatLonBoundingBox.lowerCorner\nlatLonBoundingBox.upperCorner\nnativeBoundingBox\nnativeBoundingBox.dimension\nnativeBoundingBox.lowerCorner\nnativeBoundingBox.upperCorner\nsrs\nnativeCrs\nprojectionPolicy\nenabled\nadvertised\ncatalog.defaultNamespace\ncatalog.defaultWorkspace\nstore.name\nstore.description\nstore.type\nstore.metadata.?\nstore.enabled\nstore.workspace\nstore.workspace.name\nstore.metadata.?\nstore.connectionParameters.?\nstore.error\n

                                                                                        Depending on whether the resource is a FeatureTypeInfo or a CoverageInfo, additional properties may be taken from their respective object structure. You may use REST to view an xml model of feature types and datastores in which the xml tags represent the available properties in the objects.

                                                                                        Some fields in the metadata schemes can have multiple occurrences. They may be mapped to properties in the Catalog model that are also multi-valued, such as for example keywords. It is also possible to use a filter function called list to map multiple single-valued or multi-valued catalog properties to a MetaData field with multiple occurrences (see in ISO MetaData Profile example, mapping for the identificationInfo.AbstractMD_Identification.citation.CI_Citation.alternateTitle field).

                                                                                        Placing the @ symbol in front of the field will set that to use as identifier for each metadata record. This may be useful for ID filters. Use a $ sign in front of fields that are required to make sure the mapping is aware of the requirement (specifically for the purpose of property selection).

                                                                                        Below is an example of a Dublin Core mapping file:

                                                                                        @identifier.value=id\ntitle.value=title\ncreator.value='GeoServer Catalog'\nsubject.value=keywords\nsubject.scheme='http://www.digest.org/2.1'\nabstract.value=abstract\ndescription.value=strConcat('description about ' , title)\ndate.value=\"metadata.date\"\ntype.value='http://purl.org/dc/dcmitype/Dataset'\npublisher.value='Niels Charlier'\n#format.value=\n#language.value=\n#coverage.value=\n#source.value=\n#relation.value=\n#rights.value=\n#contributor.value=\n

                                                                                        All fields have the form of <fieldname>.value for the actual value in the field. Additionally <fieldname>.scheme can be specified for the @scheme attribute of this field.

                                                                                        Examples of attributes extracted from the ResourceInfo are id, title, and keywords, etc. The attribute metadata.date uses the metadata (java.util.)Map from the Resource object. In this map, it searches for the keyword \"date\".

                                                                                        Note that double quotes are necessary in order to preserve this meaning of the dots.

                                                                                        "},{"location":"services/csw/installing/","title":"Installing Catalog Services for Web (CSW)","text":"

                                                                                        The CSW extension is listed among the other extension downloads on the GeoServer download page.

                                                                                        The installation process is similar to other GeoServer extensions:

                                                                                        1. Download the csw

                                                                                          Verify that the version number in the filename corresponds to the version of GeoServer you are running (for example 2.24.2 above).

                                                                                        2. Extract the contents of the archive into the WEB-INF/lib directory in GeoServer. Make sure you do not create any sub-directories during the extraction process.

                                                                                        3. Restart GeoServer or the servlet container, as appropriate to your configuration.

                                                                                        4. Verify that the module was installed correctly by navigating to the Welcome page of the Web administration interface and seeing the CSW entry is listed in the Service Capabilities list, and the CSW modules are listed in the Web administration interface Module list.

                                                                                        CSW Installation Verification

                                                                                        "},{"location":"services/wcs/","title":"Web Coverage Service (WCS)","text":"

                                                                                        This section describes the Web Coverage Service (WCS).

                                                                                        • WCS settings
                                                                                        • WCS basics
                                                                                        • GetCapabilities
                                                                                        • WCS output formats
                                                                                        • WCS Vendor Parameters
                                                                                        • WCS configuration
                                                                                        • WCS Request Builder
                                                                                        "},{"location":"services/wcs/basics/","title":"WCS basics","text":"

                                                                                        GeoServer provides support for Open Geospatial Consortium (OGC) Web Coverage Service (WCS) versions 1.0, 1.1 and 2.0. One can think of WCS as the equivalent of Web Feature Service (WFS), but for raster data instead of vector data. It lets you get at the raw coverage information, not just the image. GeoServer is the reference implementation for WCS 1.1.

                                                                                        "},{"location":"services/wcs/configuration/","title":"WCS configuration","text":""},{"location":"services/wcs/configuration/#coverage-processing","title":"Coverage processing","text":"

                                                                                        The WCS processing chain can be tuned in respect of how raster overviews and read subsampling are used.

                                                                                        The overview policy has four possible values:

                                                                                        Option Description Version Lower resolution overview Looks up the two overviews with a resolution closest to the one requested and chooses the one at the lower resolution. 2.0.3 Don't use overviews Overviews will be ignored, the data at its native resolution will be used instead. This is the default value. 2.0.3 Higher resolution overview Looks up the two overviews with a resolution closest to the one requested and chooses the one at the higher resolution. 2.0.3 Closest overview Looks up the overview closest to the one requested 2.0.3

                                                                                        While reading coverage data at a resolution lower than the one available on persistent storage its common to use subsampling, that is, read one every N pixels as a way to reduce the resolution of the data read in memory. Use subsampling controls whether subsampling is enabled or not.

                                                                                        "},{"location":"services/wcs/configuration/#resource-consumption-limits","title":"Resource consumption limits","text":"

                                                                                        The request limit options allow the administrator to limit the resources consumed by each WCS GetCoverage request.

                                                                                        The request limits limit the size of the image read from the source and the size of the image returned to the client. Both of these limits are to be considered a worst case scenario and are setup to make sure the server never gets asked to deal with too much data.

                                                                                        Option Description Version Maximum input memory Sets the maximum amount of memory, in kilobytes, a GetCovearge request might use, at most, to read a coverage from the data source. The memory is computed as rw * rh * pixelsize, where rw and rh are the size of the raster to be read and pixelsize is the dimension or a pixel (e.g., a RGBA image will have 32bit pixels, a batimetry might have 16bit signed int ones) 2.0.3 Maximum output memory Sets the maximum amount of memory, in kilobytes, a GetCoverage request might use, at most, to host the resulting raster. The memory is computed as ow * oh * pixelsize, where ow and oh are the size of the raster to be generated in output. 2.0.3 Max number of dimension values Sets the maximum number of dimension (time, at least for now) values that a client can request in a GetCoverage request (the work to be done is usually proportional to said number of times, and the list of values is kept in memory during the processing) 2.14.0

                                                                                        To understand the limits let's consider a very simplified example in which no tiles and overviews enter the game:

                                                                                        • The request hits a certain area of the original raster. Reading it at full resolution requires grabbing a raster of size rw * rh, which has a certain number of bands, each with a certain size. The amount of memory used for the read will be rw * rh * pixelsize. This is the value measured by the input memory limit
                                                                                        • The WCS performs the necessary processing: band selection, resolution change (downsampling or upsampling), reprojection
                                                                                        • The resulting raster will have size ow * oh and will have a certain number of bands, possibly less than the input data, each with a certain size. The amount of memory used for the final raster will be ow * oh * pixelsize. This is the value measured by the output memory limit.
                                                                                        • Finally the resulting raster will be encoded in the output format. Depending on the output format structure the size of the result might be higher than the in memory size (ArcGrid case) or smaller (for example in the case of GeoTIFF output, which is normally LZW compressed)

                                                                                        In fact reality is a bit more complicated:

                                                                                        • The input source might be tiled, which means there is no need to fully read in memory the region, but it is sufficient to do so one tile at a time. The input limits won't consider inner tiling when computing the limits, but if all the input coverages are tiled the input limits should be designed considering the amount of data to be read from the persistent storage as opposed to the amount of data to be stored in memory
                                                                                        • The reader might be using overviews or performing subsampling during the read to avoid actually reading all the data at the native resolution should the output be subsampled
                                                                                        • The output format might be tile aware as well (GeoTIFF is), meaning it might be able to write out one tile at a time. In this case not even the output raster will be stored in memory fully at any given time.

                                                                                        Only a few input formats are so badly structure that they force the reader to read the whole input data in one shot, and should be avoided. Examples are: * JPEG or PNG images with world file * Single tiled and JPEG compressed GeoTIFF files

                                                                                        "},{"location":"services/wcs/configuration/#limited-srs-list","title":"Limited SRS list","text":"

                                                                                        Some clients may have problems processing a GetCapabilities document listing the complete list of SRS (projections) that GeoServer supports by default. You may also find some projections are not appropriate for your data products.

                                                                                        Use this setting to limit the default list of supported SRS (projections) for the service. This list will be used by default, individual coverages define their own list of SRS (projections).

                                                                                        Limited SRS list

                                                                                        To limit the service to only the required projections use the Limited SRS List text box to list the desired EPSG codes separated by commas, e.g. 4326,27700 .

                                                                                        "},{"location":"services/wcs/outputformats/","title":"WCS output formats","text":"

                                                                                        WCS output formats are configured coverage by coverage. The current list of output formats follows:

                                                                                        Images:

                                                                                        • JPEG - (format=jpeg)
                                                                                        • GIF - (format=gif)
                                                                                        • PNG - (format=png)
                                                                                        • Tiff - (format=tif)
                                                                                        • BMP - (format=bmp)

                                                                                        Georeferenced formats:

                                                                                        • GeoTiff - (format=geotiff)
                                                                                        • GML Coverage - (format=application/gml+xml)

                                                                                        The GML Coverage format is described by the OGC Coverage Implementation Schema, its components are also used to describe coverage metadata in WCS 2.0 DescribeCoverage responses.

                                                                                        "},{"location":"services/wcs/reference/","title":"WCS reference","text":""},{"location":"services/wcs/reference/#introduction","title":"Introduction","text":"

                                                                                        The Web Coverage Service (WCS) is a standard created by the OGC that refers to the receiving of geospatial information as 'coverages': digital geospatial information representing space-varying phenomena. One can think of it as Web Feature Service (WFS) for raster data. It gets the 'source code' of the map, but in this case it is not raw vectors but raw imagery.

                                                                                        An important distinction must be made between WCS and Web Map Service (WMS). They are similar, and can return similar formats, but a WCS is able to return more information, including valuable metadata and more formats. It additionally allows more precise queries, potentially against multi-dimensional backend formats.

                                                                                        "},{"location":"services/wcs/reference/#benefits-of-wcs","title":"Benefits of WCS","text":"

                                                                                        WCS provides a standard interface for how to request the raster source of a geospatial image. While a WMS can return an image it is generally only useful as an image. The results of a WCS can be used for complex modeling and analysis, as it often contains more information. It also allows more complex querying - clients can extract just the portion of the coverage that they need.

                                                                                        "},{"location":"services/wcs/reference/#operations","title":"Operations","text":"

                                                                                        WCS can perform the following operations:

                                                                                        Operation Description GetCapabilities Retrieves a list of the server's data, as well as valid WCS operations and parameters DescribeCoverage Retrieves an XML document that fully describes the request coverages. GetCoverage Returns a coverage in a well-known format. Like a WMS GetMap request, but with several extensions to support the retrieval of coverages.

                                                                                        Note

                                                                                        The following examples show the 1.1 protocol, the full specification for versions 1.0, 1.1 and 2.0 are available on the OGC website

                                                                                        "},{"location":"services/wcs/reference/#wCs_getcap","title":"GetCapabilities","text":"

                                                                                        The GetCapabilities operation is a request to a WCS server for a list of what operations and services (\"capabilities\") are being offered by that server.

                                                                                        A typical GetCapabilities request would look like this (at URL http://www.example.com/wcs):

                                                                                        Using a GET request (standard HTTP):

                                                                                        http://www.example.com/wcs?\nservice=wcs&\nAcceptVersions=1.1.0&\nrequest=GetCapabilities\n

                                                                                        Here there are three parameters being passed to our WCS server, service=wcs, AcceptVersions=1.1.0, and request=GetCapabilities. At a bare minimum, it is required that a WCS request have the service and request parameters. GeoServer relaxes these requirements (setting the default version if omitted), but \"officially\" they are mandatory, so they should always be included. The service key tells the WCS server that a WCS request is forthcoming. The AcceptVersions key refers to which version of WCS is being requested. The request key is where the actual GetCapabilities operation is specified.

                                                                                        WCS additionally supports the Sections parameter that lets a client only request a specific section of the Capabilities Document.

                                                                                        "},{"location":"services/wcs/reference/#wcs_describecoverage","title":"DescribeCoverage","text":"

                                                                                        The purpose of the DescribeCoverage request is to additional information about a Coverage a client wants to query. It returns information about the crs, the metadata, the domain, the range and the formats it is available in. A client generally will need to issue a DescribeCoverage request before being sure it can make the proper GetCoverage request.

                                                                                        "},{"location":"services/wcs/reference/#wcs_getcoverage","title":"GetCoverage","text":"

                                                                                        The GetCoverage operation requests the actual spatial data. It can retrieve subsets of coverages, and the result can be either the coverage itself or a reference to it. The most powerful thing about a GetCoverage request is its ability to subset domains (height and time) and ranges. It can also do resampling, encode in different data formats, and return the resulting file in different ways.

                                                                                        "},{"location":"services/wcs/requestbuilder/","title":"WCS Request Builder","text":"

                                                                                        GeoServer includes a request builder for building and testing out WCS requests. Since WCS requests can be cumbersome to author, this tool can make working with WCS much easier.

                                                                                        "},{"location":"services/wcs/requestbuilder/#accessing-the-wcs-request-builder","title":"Accessing the WCS Request Builder","text":"

                                                                                        To access the WCS Request Builder:

                                                                                        1. Navigate to the Web administration interface.
                                                                                        2. Click the Demos link on the left side.
                                                                                        3. Select WCS Request Builder from the list of demos.

                                                                                        WCS request builder in the list of demos

                                                                                        "},{"location":"services/wcs/requestbuilder/#using-the-wcs-request-builder","title":"Using the WCS Request Builder","text":"

                                                                                        The WCS Request Builder consists of a form which can be used to generate a number of different types of requests.

                                                                                        When first opened, the form is short, only including the following options:

                                                                                        • WCS Version---Version of WCS to use when crafting the request. Options are 1.0.0 and 1.1.1.

                                                                                        • Coverage name---Coverage to use in the request. Any published (raster) layer in GeoServer can be selected.

                                                                                          Note

                                                                                          All other options displayed will be non-functional until Coverage name is selected.

                                                                                        WCS request builder in its initial form

                                                                                        Once selected, the remainder of the form will be displayed. The following options are available:

                                                                                        • Spatial subset---Sets the extent of the GetCoverage request in units of the layer CRS. Defaults to the full extent of the layer.
                                                                                        • Coordinate reference system---Source CRS of the layer. Default is the CRS of the layer in GeoServer.
                                                                                        • Specify source grid manually (1.0.0 only)---If checked, allows for determining the grid of pixels for the output.
                                                                                        • Target coverage layout (1.1.1 only)---Specifies how the dimensions of the output grid will be determined:
                                                                                          • Automatic target layout---Sets that the output grid will be determined automatically.
                                                                                          • Specify grid resolutions---Sets the resolution of the output grid. X and Y resolutions can be set differently.
                                                                                          • Specify \"grid to world\" transformation---Sets the output using latitude/longitude, as well as X and Y scale and shear values.
                                                                                        • Target CRS---CRS of the result (output) of the GetCoverage request. If different from the Coordinate reference system, the result will be a reprojection into the target CRS.
                                                                                        • Output format---Format of the result (output) of the GetCoverage request. Any valid WCS output format is allowed. Default is GeoTIFF.

                                                                                        WCS request builder form (WCS version 1.0.0)

                                                                                        WCS request builder form (WCS version 1.1.1)

                                                                                        There is also a link for Describe coverage next to the Coverage name which will execute a WCS DescribeCoverage request for the particular layer.

                                                                                        At the bottom of the form are two buttons for form submission:

                                                                                        • Get Coverage---Executes a GetCoverage request using the parameters in the form. This will usually result in a file which can be downloaded.
                                                                                        • Generate GetCoverage XML---Generates the GetCoverage request using the parameters in the form and then, instead of executing it, outputs the request itself to the screen.

                                                                                        WCS request builder showing GetCoverage XML

                                                                                        "},{"location":"services/wcs/vendor/","title":"WCS Vendor Parameters","text":"

                                                                                        WCS vendor parameters are non-standard request parameters that are defined by an implementation to provide enhanced capabilities.

                                                                                        "},{"location":"services/wcs/vendor/#general-vendor-options","title":"General Vendor Options","text":"

                                                                                        These vendor options are available for all operations.

                                                                                        content-disposition ^^^^^^^^^^^^^^^^^^^

                                                                                        The content-disposition parameter directs how a web browser directed to handle returned content. The syntax is::

                                                                                        content-disposition=

                                                                                        Where content-disposition =attachment to direct the browser to save the content to disk.

                                                                                        Where content-disposition=inline asks the browser to display the content. Note this may present performance issues when asked to display very large content.

                                                                                        filename ^^^^^^^^

                                                                                        The filename parameter provides a suggested filename when a browser saves a file (e.g. to Downloads folder). The syntax is::

                                                                                        filename=

                                                                                        An example of filename use is::

                                                                                        filename=features.json

                                                                                        When service output is saved as a file, the vendor-option filename is used to provide the file name used.

                                                                                        "},{"location":"services/wcs/vendor/#getcoverage-request","title":"GetCoverage Request","text":""},{"location":"services/wcs/vendor/#namespace","title":"namespace","text":"

                                                                                        Requests to the WCS GetCapabilities operation can be filtered to only return layers corresponding to a particular namespace.

                                                                                        Sample code: :

                                                                                        http://example.com/geoserver/wcs?\n   service=wcs&\n   version=1.0.0&\n   request=GetCapabilities&\n   namespace=topp\n

                                                                                        Using an invalid namespace prefix will not cause any errors, but the document returned will not contain information on any layers.

                                                                                        "},{"location":"services/wcs/vendor/#cql_filter","title":"cql_filter","text":"

                                                                                        The cql_filter parameter is similar to same named WMS parameter, and allows expressing a filter using ECQL (Extended Common Query Language). The filter is sent down into readers exposing a Filter read parameter.

                                                                                        For example, assume a image mosaic has a tile index with a cloudCover percentage attribute, then it's possible to mosaic only granules with a cloud cover less than 10% using:

                                                                                        cql_filter=cloudCover < 10

                                                                                        For full details see the ECQL Reference and CQL and ECQL tutorial.

                                                                                        "},{"location":"services/wcs/vendor/#sortby","title":"sortBy","text":"

                                                                                        The sortBy parameter allows to control the order of granules being mosaicked, using the same syntax as WFS 1.0, that is:

                                                                                        • &sortBy=att1 A|D,att2 A|D, ...

                                                                                        This maps to a \"SORTING\" read parameter that the coverage reader might expose (image mosaic exposes such parameter).

                                                                                        In image mosaic, this causes the first granule found in the sorting will display on top, and then the others will follow.

                                                                                        Thus, to sort a scattered mosaic of satellite images so that the most recent image shows on top, and assuming the time attribute is called ingestion in the mosaic index, the specification will be &sortBy=ingestion D.

                                                                                        "},{"location":"services/wcs/webadmin/","title":"WCS settings","text":"

                                                                                        This page details the configuration options for WCS in the web administration interface.

                                                                                        The Web Coverage Service (WCS) provides few options for changing coverage functionality. While various elements can be configured for WFS and WMS requests, WCS allows only metadata information to be edited. This metadata information, entitled Service Metadata, is common to WCS, WFS and WMS requests.

                                                                                        WCS Configuration page

                                                                                        "},{"location":"services/wcs/webadmin/#workspace","title":"Workspace","text":"

                                                                                        Select workspace empty to configure global WCS settings.

                                                                                        See section on Workspace Services to override settings used by WCS Virtual Services.

                                                                                        "},{"location":"services/wcs/webadmin/#wcs-service-metadata","title":"WCS Service Metadata","text":"

                                                                                        For a description of WCS settings, see the section on Service Metadata.

                                                                                        "},{"location":"services/wcs/webadmin/#i18n-settings","title":"i18n Settings","text":"

                                                                                        Select the default language for the WCS Service.

                                                                                        Default language

                                                                                        See the Internationalization (i18n) section for a description of how this setting is used.

                                                                                        "},{"location":"services/wcs/webadmin/#compression-settings","title":"Compression Settings","text":"

                                                                                        Specify the default level for Deflate compression when requesting a coverage in TIFF format with Deflate compression.

                                                                                        Default Deflate compression level

                                                                                        "},{"location":"services/wfs/","title":"Web Feature Service (WFS)","text":"

                                                                                        This section describes the Web Feature Service (WFS).

                                                                                        • WFS settings
                                                                                        • WFS basics
                                                                                        • WFS reference
                                                                                        • WFS output formats
                                                                                        • WFS vendor parameters
                                                                                        • WFS schema mapping
                                                                                        • Axis ordering
                                                                                        "},{"location":"services/wfs/axis_order/","title":"Axis ordering","text":"

                                                                                        The definition of a spatial reference system includes an indication of the axis order used to interpret the coordinates. There are a number of projected spatial reference systems defined in north/east order in the formal EPSG definition, but are interpreted as being in east/north order by earlier versions of the WFS protocol.

                                                                                        • WFS 1.0.0: Provides geographic coordinates in east/north and may not be trusted to respect the EPSG definition axis order.
                                                                                        • WFS 1.1.0: Respects the axis order defined by the EPSG definition.
                                                                                        • WFS 2.0.0: Respects the axis order defined by the EPSG definition.

                                                                                        Forcing content into east/north order was intended to be easier for developers where computer displays are defined with an x/y order. However this decision has introduced no end of confusion, and was corrected in later versions of WFS.

                                                                                        Note

                                                                                        Some spatial reference systems, for example polar stereographic, do not have an east or west as they have a pole in the middle of the axis.

                                                                                        These differences may cause difficulties when clients switch between different WFS versions. To minimize confusion and increase interoperability, GeoServer has adopted the following guidelines when specifying spatial reference systems to avoid ambiguity.

                                                                                        Representation Axis order Interpretation EPSG:4326 longitude/latitude assumption http://www.opengis.net/gml/srs/epsg.xml#xxxx longitude/latitude strict urn:x-ogc:def:crs:EPSG:xxxx latitude/longitude strict urn:ogc:def:crs:EPSG::4326 latitude/longitude strict"},{"location":"services/wfs/axis_order/#srslist-axis-order","title":"SRSList Axis Order","text":"

                                                                                        To compare the spatial reference system definition for EPSG:4326:

                                                                                        1. Navigate Demos \u2192 SRS List page and search for 4326.

                                                                                        2. Compare the formal EPSG definition of WGS84:

                                                                                          WGS84 EPSG definition

                                                                                        3. With the internal definition of WGS84:

                                                                                          WGS84 Internal definition

                                                                                        The same approach can be used to check the definition of any spatial reference system supported by GeoServer.

                                                                                        Note

                                                                                        The formal EPSG definition provides the axis-order used to interpret coordinate values. GeoServer uses an internal representation that does not always respect the EPSG provided axis order.

                                                                                        In the example above EPSG:4326 is defined with a north/east axis order, while the internal representation has east/north order.

                                                                                        The startup option -Dorg.geotools.referencing.forceXY=true is used to configure GeoServer to prefer an internal representation in east/north axis order. We recommend the default value of true to match a wide range of clients that make this assumption.

                                                                                        "},{"location":"services/wfs/axis_order/#layer-axis-order","title":"Layer Axis Order","text":"

                                                                                        The default data directory includes the following dataset illustrating this challenge:

                                                                                        • shapefile/states.shp`: Data stored in x/y order:

                                                                                          MULTIPOLYGON (((-121.664154 38.169369,-121.781296 38.066856, ...\n
                                                                                        • shapefiles/states.prj :

                                                                                          GEOGCS[\"GCS_WGS_1984\",DATUM[\"WGS_1984\",SPHEROID[\"WGS_1984\",6378137,298.257223563]],PRIMEM[\"Greenwich\",0],UNIT[\"Degree\",0.017453292519943295]]\n

                                                                                          Published as topp:states with Spatial Reference System EPSG:4326.

                                                                                        To review how this layer has been published:

                                                                                        1. Navigate to the Edit Layer page for topp:states.

                                                                                        2. Locate Native SRS and click on the GCS_WGS_1984 link to show how GeoServer interpreted the PRJ file above.

                                                                                          The PRJ did not provide an axis-order and GeoSever has filled in an assumption. This describing the data in x/y order which matches our data and we could use it unmodified.

                                                                                          Native SRS for topp:states

                                                                                        3. Locate Declared SRS and click on EPSG:WGS 84... link to see the definition used to publish this content.

                                                                                          This is the internal definition of EPSG:4326 as shown in the SRSList above, which also describes the data in x/y order matching our data. This definition provides slightly more readable names along with additional AUTHORITY information that may be helpful to client applications.

                                                                                          Declared SRS for topp:states

                                                                                        4. The SRS Handling is set to Force declared to completely ignore the provided Native SRS definition and use the Declared SRS.

                                                                                          Force declared SRS handling for topp:states

                                                                                        "},{"location":"services/wfs/axis_order/#wfs-10-axis-order","title":"WFS 1.0 Axis Order","text":"

                                                                                        GetCapabilities describes topp:states using:

                                                                                        http://localhost:8080/geoserver/ows?service=wfs&version=1.0.0&request=GetCapabilities

                                                                                        <FeatureType><Name>topp:states</Name>\n  <Title>USA Population</Title>\n  <Abstract>This is some census data on the states.</Abstract>\n  <Keywords>census, united, boundaries, state, states</Keywords>\n  <SRS>EPSG:4326</SRS>\n  <LatLongBoundingBox minx=\"-124.731422\" miny=\"24.955967\" maxx=\"-66.969849\" maxy=\"49.371735\" />\n</FeatureType> \n

                                                                                        WFS 1.0 describes the latitude / longitude bounds with the understanding that you will associate minx and maxx with longitude, and also miny and maxy with latitude.

                                                                                        WFS 1.0 GetFeature request defaults to GML2 output, and the default EPSG:4326 spatial reference system used to publish the layer:

                                                                                        • WFS 1.0 Default: http://localhost:8080/geoserver/ows?service=WFS&version=1.0.0&request=GetFeature&typeName=topp%3Astates&featureId=states.1

                                                                                          The GML2 output uses http://www.opengis.net/gml/srs/epsg.xml#4326 reference, with data in x/y order:

                                                                                          <gml:MultiPolygon srsName=\"http://www.opengis.net/gml/srs/epsg.xml#4326\">\n  <gml:polygonMember>\n    <gml:Polygon>\n      <gml:outerBoundaryIs><gml:LinearRing>\n        <gml:coordinates decimal=\".\" cs=\",\" ts=\" \">\n          -88.071564,37.51099 -88.087883,37.476273\n
                                                                                        "},{"location":"services/wfs/axis_order/#wfs-10-output-format-gml3","title":"WFS 1.0 output format GML3","text":"
                                                                                        • GML3.1 (default EPSG:4326):

                                                                                          http://localhost:8080/geoserver/topp/ows?service=WFS&version=1.0.0&request=GetFeature&typeName=topp%3Astates&featureId=states.1&outputFormat=gml3

                                                                                          GML3 output uses http://www.opengis.net/gml/srs/epsg.xml#4326 reference, with data in x/y order:

                                                                                          <gml:MultiSurface srsName=\"http://www.opengis.net/gml/srs/epsg.xml#4326\">\n  <gml:surfaceMember>\n    <gml:Polygon>\n      <gml:exterior>\n        <gml:LinearRing>\n          <gml:posList>\n            -88.071564 37.51099 -88.087883 37.476273\n
                                                                                        • GML3.1 reproject to EPSG:4326

                                                                                          http://localhost:8080/geoserver/topp/ows?service=WFS&version=1.0.0&request=GetFeature&typeName=topp%3Astates&featureId=states.1&outputFormat=gml3&srsName=urn:x-ogc:def:crs:EPSG:4326

                                                                                          GML3 output uses http://www.opengis.net/gml/srs/epsg.xml#4326 reference, with data in x/y order:

                                                                                          <gml:MultiSurface srsName=\"http://www.opengis.net/gml/srs/epsg.xml#4326\">\n  <gml:surfaceMember>\n    <gml:Polygon>\n      <gml:exterior>\n        <gml:LinearRing>\n          <gml:posList>\n            -88.071564 37.51099 -88.087883\n
                                                                                        • GML 3.1 reproject to urn:x-ogc:def:crs:EPSG:4326

                                                                                          http://localhost:8080/geoserver/topp/ows?service=WFS&version=1.0.0&request=GetFeature&typeName=topp%3Astates&featureId=states.1&outputFormat=gml3&srsName=urn:x-ogc:def:crs:EPSG:4326

                                                                                          GML3.1 output using urn:x-ogc:def:crs:EPSG:4326 reference and data in y/x order:

                                                                                          <gml:MultiSurface srsName=\"urn:x-ogc:def:crs:EPSG:4326\">\n  <gml:surfaceMember>\n    <gml:Polygon>\n      <gml:exterior>\n        <gml:LinearRing>\n          <gml:posList>\n            37.51099 -88.071564 37.476273 -88.087883 \n
                                                                                        "},{"location":"services/wfs/axis_order/#wfs-10-output-format-gml32","title":"WFS 1.0 output format GML32","text":"
                                                                                        • GML3.2:

                                                                                          http://localhost:8080/geoserver/topp/ows?service=WFS&version=1.0.0&request=GetFeature&typeName=topp%3Astates&featureId=states.1&outputFormat=gml32

                                                                                          The GML32 output uses http://www.opengis.net/gml/srs/epsg.xml#4326 reference, with data in x/y order:

                                                                                          <gml:MultiSurface srsName=\"http://www.opengis.net/gml/srs/epsg.xml#4326\" gml:id=\"states.1.the_geom\">\n  <gml:surfaceMember>\n    <gml:Polygon gml:id=\"states.1.the_geom.1\">\n      <gml:exterior>\n        <gml:LinearRing>\n          <gml:posList>-88.071564 37.51099 -88.087883 37.476273 \n
                                                                                        • GML3.2 reproject to EPSG:4326:

                                                                                          http://localhost:8080/geoserver/topp/ows?service=WFS&version=1.0.0&request=GetFeature&typeName=topp%3Astates&featureId=states.1&outputFormat=gml32&srsName=EPSG:4326

                                                                                          The GML32 output uses http://www.opengis.net/gml/srs/epsg.xml#4326 reference, with data in x/y order:

                                                                                          <gml:MultiSurface srsName=\"http://www.opengis.net/gml/srs/epsg.xml#4326\" gml:id=\"states.1.the_geom\">\n  <gml:surfaceMember>\n    <gml:Polygon gml:id=\"states.1.the_geom.1\">\n      <gml:exterior>\n        <gml:LinearRing>\n          <gml:posList>\n            -88.071564 37.51099 -88.087883 37.476273\n
                                                                                        • GML3.2 reproject to urn:x-ogc:def:crs:EPSG:4326:

                                                                                          http://localhost:8080/geoserver/topp/ows?service=WFS&version=1.0.0&request=GetFeature&typeName=topp%3Astates&featureId=states.1&outputFormat=gml32&srsName=urn:x-ogc:def:crs:EPSG:4326

                                                                                          GML3.2 output using urn:x-ogc:def:crs:EPSG:4326 reference and data in y/x order:

                                                                                          <gml:MultiSurface srsName=\"urn:ogc:def:crs:EPSG::4326\" gml:id=\"states.1.the_geom\">\n  <gml:surfaceMember>\n    <gml:Polygon gml:id=\"states.1.the_geom.1\">\n      <gml:exterior>\n        <gml:LinearRing><gml:posList>\n          37.51099 -88.071564 37.476273 -88.087883 \n
                                                                                        "},{"location":"services/wfs/axis_order/#wfs-11-axis-order","title":"WFS 1.1 Axis Order","text":"

                                                                                        GetCapabilities describes topp:states using:

                                                                                        http://localhost:8080/geoserver/ows?service=wfs&version=1.1.0&request=GetCapabilities

                                                                                        <FeatureType>\n  <Name>topp:states</Name>\n  <Title>USA Population</Title>\n  <Abstract>This is some census data on the states.</Abstract>\n  <ows:Keywords>\n    <ows:Keyword>census</ows:Keyword><ows:Keyword>united</ows:Keyword><ows:Keyword>boundaries</ows:Keyword><ows:Keyword>state</ows:Keyword><ows:Keyword>states</ows:Keyword>\n  </ows:Keywords>\n  <DefaultSRS>urn:x-ogc:def:crs:EPSG:4326</DefaultSRS>\n  <ows:WGS84BoundingBox>\n    <ows:LowerCorner>-124.731422 24.955967</ows:LowerCorner>\n    <ows:UpperCorner>-66.969849 49.371735</ows:UpperCorner>\n  </ows:WGS84BoundingBox></FeatureType>    \n

                                                                                        WFS 1.1 describes the WGS84BoundingBox as a lower and upper corner in x/y order.

                                                                                        Warning

                                                                                        This combination is inconsistent with DefaultSRS definition and the LowerCorner and UpperCorner coordinate order and may confuse client applications.

                                                                                        The result matches the WFS 1.1.0 Implementation Specification GetCapabilities examples.

                                                                                        WFS 1.1 GetFeature request defaults to GML3 output, and the default urn:x-ogc:def:crs:EPSG:4326 spatial reference system used to publish the layer:

                                                                                        • WFS 1.1 Default:

                                                                                          http://localhost:8080/geoserver/ows?service=WFS&version=1.1.0&request=GetFeature&typeName=topp%3Astates&featureId=states.1

                                                                                          The GML3.1 output uses urn:x-ogc:def:crs:EPSG:4326 reference, with data in y/x order:

                                                                                          <gml:MultiSurface srsName=\"urn:x-ogc:def:crs:EPSG:4326\">\n  <gml:surfaceMember>\n    <gml:Polygon>\n      <gml:exterior>\n        <gml:LinearRing>\n          <gml:posList>\n             37.51099 -88.071564 37.476273 -88.087883  \n
                                                                                        • WFS 1.1 reproject to EPSG:4326:

                                                                                          http://localhost:8080/geoserver/ows?service=WFS&version=1.1.0&request=GetFeature&typeName=topp%3Astates&featureId=states.1&srsName=EPSG:4326

                                                                                          The GML3.1 output uses http://www.opengis.net/gml/srs/epsg.xml#4326 reference, with data in x/y order:

                                                                                          <gml:MultiSurface srsName=\"http://www.opengis.net/gml/srs/epsg.xml#4326\">\n  <gml:surfaceMember>\n    <gml:Polygon>\n      <gml:exterior>\n        <gml:LinearRing>\n          <gml:posList>\n            -88.071564 37.51099 -88.087883 37.476273\n

                                                                                          Note

                                                                                          The srsName and posList coordinate order are consistent.

                                                                                          This approach can be used to force x/y order.

                                                                                        • WFS 1.1 reproject to urn:x-ogc:def:crs:EPSG:4326:

                                                                                          http://localhost:8080/geoserver/ows?service=WFS&version=1.1.0&request=GetFeature&typeName=topp%3Astates&featureId=states.1&srsName=urn:x-ogc:def:crs:EPSG:4326

                                                                                          The GML3.1 output uses http://www.opengis.net/gml/srs/epsg.xml#4326 reference, with data in y/x order:

                                                                                          <gml:MultiSurface srsName=\"http://www.opengis.net/gml/srs/epsg.xml#4326\">\n  <gml:surfaceMember>\n    <gml:Polygon>\n      <gml:exterior>\n        <gml:LinearRing>\n          <gml:posList>\n            37.51099 -88.071564 37.476273 -88.087883\n
                                                                                        "},{"location":"services/wfs/axis_order/#wfs-11-output-format-gml2","title":"WFS 1.1 output format GML2","text":"
                                                                                        • GML2:

                                                                                          http://localhost:8080/geoserver/topp/ows?service=WFS&version=1.1.0&request=GetFeature&typeName=topp%3Astates&featureId=states.1&outputFormat=gml2

                                                                                          GML2 output uses http://www.opengis.net/gml/srs/epsg.xml#4326 reference, with data in y/x order:

                                                                                          <gml:MultiPolygon srsName=\"http://www.opengis.net/gml/srs/epsg.xml#4326\">\n  <gml:polygonMember>\n    <gml:Polygon><gml:outerBoundaryIs>\n      <gml:LinearRing>\n        <gml:coordinates decimal=\".\" cs=\",\" ts=\" \">\n          37.51099,-88.071564 37.476273,-88.087883\n
                                                                                        • GML2 reproject to EPSG:4326:

                                                                                          http://localhost:8080/geoserver/topp/ows?service=WFS&version=1.1.0&request=GetFeature&typeName=topp%3Astates&featureId=states.1&outputFormat=gml2&srsName=EPSG:4326

                                                                                          GML2 output uses http://www.opengis.net/gml/srs/epsg.xml#4326 reference, with data in x/y order:

                                                                                          <gml:MultiPolygon srsName=\"http://www.opengis.net/gml/srs/epsg.xml#4326\">\n  <gml:polygonMember>\n    <gml:Polygon>\n      <gml:outerBoundaryIs>\n        <gml:LinearRing>\n          <gml:coordinates decimal=\".\" cs=\",\" ts=\" \">\n            -88.071564,37.51099 -88.087883,37.476273\n

                                                                                          Note

                                                                                          The srsName and posList coordinate order are consistent.

                                                                                          This approach can be used to force x/y order.

                                                                                        "},{"location":"services/wfs/axis_order/#wfs-11-output-format-gml3","title":"WFS 1.1 output format GML3","text":"
                                                                                        • GML3:

                                                                                          http://localhost:8080/geoserver/topp/ows?service=WFS&version=1.1.0&request=GetFeature&typeName=topp%3Astates&featureId=states.1&outputFormat=gml3

                                                                                          GML3.1 output uses http://www.opengis.net/gml/srs/epsg.xml#4326 reference, with data in y/x order:

                                                                                          <gml:MultiSurface srsName=\"http://www.opengis.net/gml/srs/epsg.xml#4326\">\n  <gml:surfaceMember>\n    <gml:Polygon>\n      <gml:exterior>\n        <gml:LinearRing>\n          <gml:posList>\n            37.51099 -88.071564 37.476273 -88.087883\n
                                                                                        • GML3 reproject to EPSG:4326:

                                                                                          http://localhost:8080/geoserver/topp/ows?service=WFS&version=1.1.0&request=GetFeature&typeName=topp%3Astates&featureId=states.1&outputFormat=gml3&srsName=EPSG:4326

                                                                                          GML3.1 output uses http://www.opengis.net/gml/srs/epsg.xml#4326 reference, but has changed the data to x/y order:

                                                                                          <gml:MultiSurface srsName=\"http://www.opengis.net/gml/srs/epsg.xml#4326\">\n  <gml:surfaceMember>\n    <gml:Polygon>\n      <gml:exterior>\n        <gml:LinearRing>\n          <gml:posList>\n            -88.071564 37.51099 -88.087883 37.476273\n

                                                                                          Note

                                                                                          The srsName and posList coordinate order are consistent.

                                                                                          This approach can be used to force x/y order.

                                                                                        • GML3 reproject to urn:x-ogc:def:crs:EPSG:4326

                                                                                          http://localhost:8080/geoserver/topp/ows?service=WFS&version=1.1.0&request=GetFeature&typeName=topp%3Astates&featureId=states.1&outputFormat=gml3&srsName=urn:x-ogc:def:crs:EPSG:4326

                                                                                          GML3.1 output using urn:x-ogc:def:crs:EPSG:4326 reference and data in y/x order:

                                                                                          <gml:MultiSurface srsName=\"http://www.opengis.net/gml/srs/epsg.xml#4326\">\n  <gml:surfaceMember>\n    <gml:Polygon>\n      <gml:exterior>\n        <gml:LinearRing>\n          <gml:posList>\n            -88.071564 37.51099 -88.087883 37.476273\n

                                                                                          Note

                                                                                          The srsName and posList coordinate order are consistent.

                                                                                          This approach can be used to force x/y order.

                                                                                        "},{"location":"services/wfs/axis_order/#wfs-11-output-format-gml32","title":"WFS 1.1 output format GML32","text":"
                                                                                        • GML3.2:

                                                                                          http://localhost:8080/geoserver/topp/ows?service=WFS&version=1.1.0&request=GetFeature&typeName=topp%3Astates&featureId=states.1&outputFormat=gml32

                                                                                          The GML32 output uses http://www.opengis.net/gml/srs/epsg.xml#4326 reference, with data in y/x order:

                                                                                          <gml:MultiSurface srsName=\"urn:ogc:def:crs:EPSG::4326\" gml:id=\"states.1.the_geom\">\n  <gml:surfaceMember><gml:Polygon gml:id=\"states.1.the_geom.1\">\n    <gml:exterior>\n      <gml:LinearRing>\n        <gml:posList>37.51099 -88.071564 37.476273 -88.087883\n
                                                                                        • GML3.2 reproject to EPSG:4326:

                                                                                          http://localhost:8080/geoserver/topp/ows?service=WFS&version=1.0.0&request=GetFeature&typeName=topp%3Astates&featureId=states.1&outputFormat=gml32&srsName=EPSG:4326

                                                                                          The GML32 output uses http://www.opengis.net/gml/srs/epsg.xml#4326 reference, with data in x/y order:

                                                                                          <gml:MultiSurface srsName=\"http://www.opengis.net/gml/srs/epsg.xml#4326\" gml:id=\"states.1.the_geom\">\n  <gml:surfaceMember>\n    <gml:Polygon gml:id=\"states.1.the_geom.1\">\n      <gml:exterior>\n        <gml:LinearRing>\n          <gml:posList>-88.071564 37.51099 -88.087883 37.476273\n
                                                                                        • GML3.2 reproject to urn:x-ogc:def:crs:EPSG:4326:

                                                                                          http://localhost:8080/geoserver/topp/ows?service=WFS&version=1.0.0&request=GetFeature&typeName=topp%3Astates&featureId=states.1&outputFormat=gml32&srsName=urn:x-ogc:def:crs:EPSG:4326

                                                                                          GML3.2 output using urn:x-ogc:def:crs:EPSG:4326 reference and data in y/x order:

                                                                                          <gml:MultiSurface srsName=\"urn:ogc:def:crs:EPSG::4326\" gml:id=\"states.1.the_geom\">\n  <gml:surfaceMember>\n    <gml:Polygon gml:id=\"states.1.the_geom.1\">\n      <gml:exterior>\n        <gml:LinearRing><gml:posList>37.51099 -88.071564 37.476273 -88.087883 \n
                                                                                        "},{"location":"services/wfs/axis_order/#wfs-20-axis-order","title":"WFS 2.0 Axis Order","text":"

                                                                                        GetCapabilities describes topp:states using:

                                                                                        http://localhost:8080/geoserver/ows?service=wfs&version=2.0.0&request=GetCapabilities

                                                                                        <FeatureType>\n  <Name>topp:states</Name>\n  <Title>USA Population</Title>\n  <Abstract>This is some census data on the states.</Abstract>\n  <ows:Keywords>\n    <ows:Keyword>census</ows:Keyword><ows:Keyword>united</ows:Keyword><ows:Keyword>boundaries</ows:Keyword><ows:Keyword>state</ows:Keyword><ows:Keyword>states</ows:Keyword>\n  </ows:Keywords>\n  <DefaultCRS>urn:ogc:def:crs:EPSG::4326</DefaultCRS>\n  <ows:WGS84BoundingBox>\n    <ows:LowerCorner>-124.731422 24.955967</ows:LowerCorner>\n    <ows:UpperCorner>-66.969849 49.371735</ows:UpperCorner>\n  </ows:WGS84BoundingBox>\n</FeatureType>\n

                                                                                        WFS 2.0 describes the WGS84BoundingBox as a lower and upper corner in x/y order.

                                                                                        Warning

                                                                                        This combination is inconsistent with DefaultSRS definition and the LowerCorner and UpperCorner coordinate order and may confuse client applications.

                                                                                        The result matches the WFS 2.0 GetCapabilities examples.

                                                                                        WFS 2.0 GetFeature request defaults to GML3.2 output, and the default urn:ogc:def:crs:EPSG::4326 spatial reference system used to publish the layer:

                                                                                        • WFS 2.0 Default:

                                                                                          http://localhost:8080/geoserver/ows?service=WFS&version=2.0.0&request=GetFeature&typeNames=topp%3Astates&featureId=states.1

                                                                                          The GML3.2 output uses urn:ogc:def:crs:EPSG::4326 reference, with data in y/x order:

                                                                                          <gml:MultiSurface srsName=\"urn:ogc:def:crs:EPSG::4326\" gml:id=\"states.1.the_geom\">\n  <gml:surfaceMember>\n    <gml:Polygon gml:id=\"states.1.the_geom.1\">\n      <gml:exterior><gml:LinearRing>\n        <gml:posList>\n          37.51099 -88.071564 37.476273 -88.087883  \n
                                                                                        • WFS 2.0 reproject to EPSG:4326:

                                                                                          http://localhost:8080/geoserver/ows?service=WFS&version=2.0.0&request=GetFeature&typeNames=topp%3Astates&featureId=states.1&srsName=EPSG:4326

                                                                                          The GML3.2 output uses http://www.opengis.net/gml/srs/epsg.xml#4326 reference, with data in x/y order:

                                                                                          <gml:MultiSurface srsName=\"http://www.opengis.net/gml/srs/epsg.xml#4326\" gml:id=\"states.1.the_geom\">\n  <gml:surfaceMember>\n    <gml:Polygon gml:id=\"states.1.the_geom.1\">\n      <gml:exterior><gml:LinearRing>\n        <gml:posList>\n          -88.071564 37.51099 -88.087883 37.476273 \n
                                                                                        • WFS 2.0 reproject to urn:ogc:def:crs:EPSG::4326 http://localhost:8080/geoserver/ows?service=WFS&version=2.0.0&request=GetFeature&typeNames=topp%3Astates&featureId=states.1&srsName=urn:ogc:def:crs:EPSG::4326

                                                                                          The GML3.2 output uses urn:ogc:def:crs:EPSG::4326 reference, with data in y/x order:

                                                                                          <gml:MultiSurface srsName=\"urn:ogc:def:crs:EPSG::4326\" gml:id=\"states.1.the_geom\">\n  <gml:surfaceMember>\n    <gml:Polygon gml:id=\"states.1.the_geom.1\">\n      <gml:exterior><gml:LinearRing>\n        <gml:posList>\n          37.51099 -88.071564 37.476273 -88.087883 37.442852\n
                                                                                        "},{"location":"services/wfs/axis_order/#wfs-20-output-format-gml2","title":"WFS 2.0 output format GML2","text":"
                                                                                        • GML2:

                                                                                          http://localhost:8080/geoserver/ows?service=WFS&version=2.0.0&request=GetFeature&typeNames=topp%3Astates&featureId=states.1&outputFormat=gml2

                                                                                          <gml:MultiPolygon srsName=\"http://www.opengis.net/gml/srs/epsg.xml#4326\">\n  <gml:polygonMember>\n    <gml:Polygon>\n      <gml:outerBoundaryIs>\n        <gml:LinearRing>\n          <gml:coordinates decimal=\".\" cs=\",\" ts=\" \">\n            37.51099,-88.071564 37.476273,-88.087883 \n
                                                                                        • GML2 reproject to EPSG:4326:

                                                                                          http://localhost:8080/geoserver/ows?service=WFS&version=2.0.0&request=GetFeature&typeNames=topp%3Astates&featureId=states.1&outputFormat=gml2&srsName=EPSG:4326

                                                                                          <gml:MultiPolygon srsName=\"http://www.opengis.net/gml/srs/epsg.xml#4326\">\n  <gml:polygonMember>\n    <gml:Polygon>\n      <gml:outerBoundaryIs>\n        <gml:LinearRing>\n          <gml:coordinates decimal=\".\" cs=\",\" ts=\" \">\n            -88.071564,37.51099 -88.087883,37.476273\n

                                                                                          Note

                                                                                          The srsName and posList coordinate order are consistent.

                                                                                          This approach can be used to force x/y order.

                                                                                        • GML2 reproject to urn:x-ogc:def:crs:EPSG:4326:

                                                                                          http://localhost:8080/geoserver/ows?service=WFS&version=2.0.0&request=GetFeature&typeNames=topp%3Astates&featureId=states.1&outputFormat=gml2&srsName=urn:x-ogc:def:crs:EPSG:4326

                                                                                          <gml:MultiPolygon srsName=\"http://www.opengis.net/gml/srs/epsg.xml#4326\">\n  <gml:polygonMember>\n    <gml:Polygon>\n      <gml:outerBoundaryIs>\n        <gml:LinearRing>\n          <gml:coordinates decimal=\".\" cs=\",\" ts=\" \">\n            37.51099,-88.071564 37.476273,-88.087883\n
                                                                                        "},{"location":"services/wfs/axis_order/#wfs-20-output-format-gml3","title":"WFS 2.0 output format GML3","text":"
                                                                                        • GML3:

                                                                                          http://localhost:8080/geoserver/ows?service=WFS&version=2.0.0&request=GetFeature&typeNames=topp%3Astates&featureId=states.1&outputFormat=gml3

                                                                                          <gml:MultiSurface srsName=\"urn:x-ogc:def:crs:EPSG:4326\">\n  <gml:surfaceMember>\n    <gml:Polygon>\n      <gml:exterior>\n        <gml:LinearRing>\n          <gml:posList>\n            37.51099 -88.071564 37.476273 -88.087883 \n
                                                                                        • GML3 reproject to EPSG:4326:

                                                                                          http://localhost:8080/geoserver/ows?service=WFS&version=2.0.0&request=GetFeature&typeNames=topp%3Astates&featureId=states.1&outputFormat=gml3&srsName=EPSG:4326

                                                                                          <gml:MultiSurface srsName=\"urn:x-ogc:def:crs:EPSG:4326\">\n  <gml:surfaceMember>\n    <gml:Polygon>\n      <gml:exterior>\n        <gml:LinearRing>\n          <gml:posList>\n            -88.071564 37.51099 -88.087883 37.476273\n

                                                                                          Warning

                                                                                          This combination is inconsistent between srsName and posList coordinate order and may confuse applications expecting a valid GML3 document.

                                                                                          This approach can be used to force x/y order.

                                                                                        • GML3 reproject to urn:x-ogc:def:crs:EPSG:4326:

                                                                                          http://localhost:8080/geoserver/ows?service=WFS&version=2.0.0&request=GetFeature&typeNames=topp%3Astates&featureId=states.1&outputFormat=gml3&srsName=urn:x-ogc:def:crs:EPSG:4326

                                                                                          <gml:MultiSurface srsName=\"urn:x-ogc:def:crs:EPSG:4326\">\n  <gml:surfaceMember>\n    <gml:Polygon>\n      <gml:exterior>\n        <gml:LinearRing>\n          <gml:posList>\n            37.51099 -88.071564 37.476273 -88.087883\n
                                                                                        "},{"location":"services/wfs/axis_order/#wfs-20-output-format-gml32","title":"WFS 2.0 output format GML32","text":"
                                                                                        • GML32:

                                                                                          http://localhost:8080/geoserver/ows?service=WFS&version=2.0.0&request=GetFeature&typeNames=topp%3Astates&featureId=states.1&outputFormat=gml32

                                                                                          <gml:MultiSurface srsName=\"urn:ogc:def:crs:EPSG::4326\" gml:id=\"states.1.the_geom\">\n  <gml:surfaceMember>\n    <gml:Polygon gml:id=\"states.1.the_geom.1\"><gml:exterior>\n      <gml:LinearRing>\n        <gml:posList>\n          37.51099 -88.071564 37.476273 -88.087883 \n
                                                                                        • GML32 reproject to EPSG:4326:

                                                                                          http://localhost:8080/geoserver/ows?service=WFS&version=2.0.0&request=GetFeature&typeNames=topp%3Astates&featureId=states.1&outputFormat=gml32&srsName=EPSG:4326

                                                                                          <gml:MultiSurface srsName=\"urn:ogc:def:crs:EPSG::4326\" gml:id=\"states.1.the_geom\">\n  <gml:surfaceMember>\n    <gml:Polygon gml:id=\"states.1.the_geom.1\"><gml:exterior>\n      <gml:LinearRing>\n        <gml:posList>\n          -88.071564 37.51099 -88.087883 37.476273\n

                                                                                          Warning

                                                                                          This combination is inconsistent between srsName and posList coordinate order and may confuse applications expecting a valid GML3 document.

                                                                                          This approach can be used to force x/y order.

                                                                                        • GML32 reproject to urn:x-ogc:def:crs:EPSG:4326:

                                                                                          http://localhost:8080/geoserver/ows?service=WFS&version=2.0.0&request=GetFeature&typeNames=topp%3Astates&featureId=states.1&outputFormat=gml32&srsName=urn:x-ogc:def:crs:EPSG:4326

                                                                                          <gml:MultiSurface srsName=\"urn:ogc:def:crs:EPSG::4326\" gml:id=\"states.1.the_geom\">\n  <gml:surfaceMember>\n    <gml:Polygon gml:id=\"states.1.the_geom.1\"><gml:exterior>\n      <gml:LinearRing>\n        <gml:posList>\n          37.51099 -88.071564 37.476273 -88.087883\n
                                                                                        "},{"location":"services/wfs/basics/","title":"WFS basics","text":"

                                                                                        GeoServer provides support for the Open Geospatial Consortium (OGC) Web Feature Service (WFS) specification, versions 1.0.0, 1.1.0, and 2.0.0. WFS defines a standard for exchanging vector data over the Internet. With a compliant WFS, clients can query both the data structure and the source data. Advanced WFS operations also support feature locking and edit operations.

                                                                                        GeoServer is the reference implementation of all three versions of the standard, completely implementing every part of the protocol. This includes the basic operations of GetCapabilities, DescribeFeatureType, and GetFeature, as well as more advanced options such as Transaction. GeoServer WFS is also integrated with its Security system to limit access to data and transactions, and supports a variety of WFS output formats, making the raw data more widely available.

                                                                                        "},{"location":"services/wfs/basics/#differences-between-wfs-versions","title":"Differences between WFS versions","text":"

                                                                                        The major differences between the WFS versions are:

                                                                                        • WFS 1.1.0 and 2.0.0 return GML3 as the default GML, whereas in WFS 1.0.0, the default is GML2. GML3 adopts marginally different ways of specifying a geometry. GeoServer supports requests in both GML3 and GML2 formats.
                                                                                        • In WFS 1.1.0 and 2.0.0, the SRS (Spatial Reference System, or projection) is specified with urn:x-ogc:def:crs:EPSG:XXXX, whereas in WFS 1.0.0 the specification was http://www.opengis.net/gml/srs/epsg.xml#XXXX. This change has implications for the axis order of the returned data.
                                                                                        • WFS 1.1.0 and 2.0.0 support on-the-fly reprojection of data, which supports returning the data in a SRS other than the native SRS.
                                                                                        • WFS 2.0.0 introduces a new version of the filter encoding specification, adding support for temporal filters.
                                                                                        • WFS 2.0.0 supports joins via a GetFeature request.
                                                                                        • WFS 2.0.0 adds the ability to page results of a GetFeature request via the startIndex and count parameters. GeoServer now supports this functionality in WFS 1.0.0 and 1.1.0.
                                                                                        • WFS 2.0.0 supports stored queries, which are regular WFS queries stored on the server such that they may be invoked by passing the appropriate identifier with a WFS request.
                                                                                        • WFS 2.0.0 supports SOAP (Simple Object Access Protocol) as an alternative to the OGC interface.

                                                                                        Note

                                                                                        There are also two changes to parameter names which can cause confusion. WFS 2.0.0 uses the count parameter to limit the number of features returned rather than the maxFeatures parameter used in previous versions. It also changed typeName to typeNames although GeoServer will accept either.

                                                                                        "},{"location":"services/wfs/outputformats/","title":"WFS output formats","text":"

                                                                                        WFS returns features and feature information in a number of formats. The syntax for specifying an output format is:

                                                                                        outputFormat=<format>\n

                                                                                        where <format> is one of the following options:

                                                                                        Format Syntax Notes GML2 outputFormat=GML2 Default option for WFS 1.0.0 GML3 outputFormat=GML3 Default option for WFS 1.1.0 and 2.0.0 Shapefile outputFormat=shape-zip ZIP archive will be generated containing the shapefile (see Shapefile output below). JSON outputFormat=application/json Returns a GeoJSON or a JSON output. Note outputFormat=json is only supported for getFeature (for backward compatibility). JSONP outputFormat=text/javascript Returns a JSONP in the form: parseResponse(...json...). See WMS vendor parameters to change the callback name. Note that this format is disabled by default (See Global variables affecting WMS). CSV outputFormat=csv Returns a CSV (comma-separated values) file

                                                                                        Note

                                                                                        Some additional output formats (such as Excel) are available with the use of an extension. The full list of output formats supported by a particular GeoServer instance can be found by performing a WFS GetCapabilities request.

                                                                                        GeoServer provides the format_options vendor-specific parameter to specify parameters that are specific to each format. The syntax is:

                                                                                        format_options=param1:value1;param2:value2;...\n
                                                                                        "},{"location":"services/wfs/outputformats/#wfs_outputformat_shapezip","title":"Shapefile output","text":"

                                                                                        The shapefile format has a number of limitations that would prevent turning data sources into an equivalent shapefile. In order to abide with such limitations the shape-zip output format will automatically apply some transformations on the source data, and eventually split the single collection into multiple shapefiles. In particular, the shape-zip format will:

                                                                                        • Reduce attribute names to the DBF accepted length, making sure there are not conflicts (counters being added at the end of the attribute name to handle this).
                                                                                        • Fan out multiple geometry type into parallel shapefiles, named after the original feature type, plus the geometry type as a suffix.
                                                                                        • Fan out multiple shapefiles in case the maximum size is reached

                                                                                        The default max size for both .shp and .dbf file is 2GB, it's possible to modify those limits by setting the GS_SHP_MAX_SIZE and GS_DBF_MAX_SIZE system variables to a different value (as a byte count, the default value being 2147483647).

                                                                                        Shapefile output format_options:

                                                                                        • format_option=filename:<zipfile>: if a file name is provided, the name is used as the output file name. For example, format_options=filename:roads.zip.
                                                                                        "},{"location":"services/wfs/outputformats/#shapefile-filename-customization","title":"Shapefile filename customization","text":"

                                                                                        If a file name is not specified, the output file name is inferred from the requested feature type name. The shapefile output format output can be customized by preparing a Freemarker template which will configure the file name of the archive (ZIP file) and the files it contains. The default template is:

                                                                                        zip=${typename}\nshp=${typename}${geometryName}${geometryType}\ntxt=wfsrequest\n

                                                                                        The zip property is the name of the archive, the shp property is the name of the shapefile for a given feature type, and txt is the dump of the actual WFS request.

                                                                                        The properties available in the template are:

                                                                                        • typename---Feature type name (for the zip property this will be the first feature type if the request contains many feature types)
                                                                                        • geometryName---Name of the geometry attribute. Used only if the original feature type has more than one geometry attribute.
                                                                                        • geometryType---Type of geometry contained in the shapefile. This is only used if the output geometry type is generic and the various geometries are stored in one shapefile per type.
                                                                                        • workspace---Workspace of the feature type
                                                                                        • timestamp---Date object with the request timestamp
                                                                                        • iso_timestamp---String (ISO timestamp of the request at GMT) in yyyyMMdd_HHmmss format
                                                                                        "},{"location":"services/wfs/outputformats/#json-and-jsonp-output","title":"JSON and JSONP output","text":"

                                                                                        The JSON output format (and JSONP if enabled) return feature content as a GeoJSON document. Here is an example of a simple GeoJSON file;

                                                                                        {  \"type\": \"Feature\",\n   \"geometry\": {\n      \"type\": \"Point\",\n      \"coordinates\": [125.6, 10.1]\n   },\n   \"properties\": {\n      \"name\": \"Dinagat Islands\"\n   }\n}\n

                                                                                        The output properties can include the use of lists and maps:

                                                                                        {\n  \"type\": \"Feature\",\n  \"id\": \"example.3\",\n  \"geometry\": {\n    \"type\": \"POINT\",\n    \"coordinates\": [ -75.70742, 38.557476 ],\n  },\n  \"geometry_name\": \"geom\",\n  \"properties\": {\n    \"CONDITION\": \"Orange\",\n    \"RANGE\": {\"min\":\"37\",\"max\":\"93\"}\n  }\n}\n

                                                                                        JSON output format_options:

                                                                                        • format_options=id_policy:<attribute name>=<attribute|true|false> is used to determine if the id values are included in the output.

                                                                                          Use format_options=id_policy:reference_no for feature id generation using the reference_no attribute, or format_options=id_policy:reference_no=true for default feature id generation, or format_options=id_policy:reference_no=false to suppress feature id output.

                                                                                          If id_policy is not specified the geotools default feature id generation is used.

                                                                                        • format_options=callback:<parseResponse> applies only to the JSONP output format. See WMS vendor parameters to change the callback name. Note that this format is disabled by default (See Global variables affecting WMS).

                                                                                        • format_option=filename:<file>: if a file name is provided, the name is used as the output file name. The extension json is optional, for example format_options=filename:export or format_options=features.json

                                                                                        JSON output system properties:

                                                                                        • json.maxDepth=<max_value> is used to determine the max number of allowed JSON nested objects on encoding phase. By default the value is 100.

                                                                                        Note

                                                                                        Coordinates with a value equal to $\\pm \\infty$ will be encoded with their string representation \"Infinity\" or \"-Infinity\"

                                                                                        "},{"location":"services/wfs/outputformats/#csv-output","title":"CSV output","text":"

                                                                                        A Default CSV file uses a comma to separate values. Each line of the file is a data record. Each record consists of one or more fields, separated by commas. The separator can be changed using format_options as specified below.

                                                                                        csv file output format_options:

                                                                                        • format_option=filename:<file>: if a file name is provided, the name is used as the output file name. For example, format_options=filename:roads.csv.
                                                                                        • format_option=csvseparator:<csvseparator> (default is `, ```` ): if a separator is provided, it is used to separate values in output csv file. For example, ````format_options=csvseparator:-` is used to get dash separated file.

                                                                                        Some special characters need to be handled using keywords as below:

                                                                                        • space separated: format_options=csvseparator:space
                                                                                        • tab separated: format_options=csvseparator:tab
                                                                                        • semicolon separated: format_options=csvseparator:semicolon
                                                                                        "},{"location":"services/wfs/reference/","title":"WFS reference","text":"

                                                                                        The Web Feature Service (WFS) is a standard created by the Open Geospatial Consortium (OGC) for creating, modifying and exchanging vector format geographic information on the Internet using HTTP. A WFS encodes and transfers information in Geography Markup Language (GML), a subset of XML.

                                                                                        The current version of WFS is 2.0.0. GeoServer supports versions 2.0.0, 1.1.0, and 1.0.0. Although there are some important differences between the versions, the request syntax often remains the same.

                                                                                        A related OGC specification, the Web Map Service (WMS), defines the standard for exchanging geographic information in digital image format.

                                                                                        "},{"location":"services/wfs/reference/#benefits-of-wfs","title":"Benefits of WFS","text":"

                                                                                        The WFS standard defines the framework for providing access to, and supporting transactions on, discrete geographic features in a manner that is independent of the underlying data source. Through a combination of discovery, query, locking, and transaction operations, users have access to the source spatial and attribute data in a manner that allows them to interrogate, style, edit (create, update, and delete), and download individual features. The transactional capabilities of WFS also support the development and deployment of collaborative mapping applications.

                                                                                        "},{"location":"services/wfs/reference/#operations","title":"Operations","text":"

                                                                                        All versions of WFS support these operations:

                                                                                        Operation Description GetCapabilities Generates a metadata document describing a WFS service provided by server as well as valid WFS operations and parameters DescribeFeatureType Returns a description of feature types supported by a WFS service GetFeature Returns a selection of features from a data source including geometry and attribute values LockFeature Prevents a feature from being edited through a persistent feature lock Transaction Edits existing feature types by creating, updating, and deleting

                                                                                        The following operations are available in version 2.0.0 only:

                                                                                        Operation Description GetPropertyValue Retrieves the value of a feature property or part of the value of a complex feature property from the data store for a set of features identified using a query expression GetFeatureWithLock Returns a selection of features and also applies a lock on those features CreateStoredQuery Create a stored query on the WFS server DropStoredQuery Deletes a stored query from the WFS server ListStoredQueries Returns a list of the stored queries on a WFS server DescribeStoredQueries Returns a metadata document describing the stored queries on a WFS server

                                                                                        The following operations are available in version 1.1.0 only:

                                                                                        Operation Description GetGMLObject Retrieves features and elements by ID from a WFS

                                                                                        Note

                                                                                        In the examples that follow, the fictional URL http://example.com/geoserver/wfs is used for illustration. To test the examples, substitute the address of a valid WFS. Also, although the request would normally be defined on one line with no breaks, breaks are added for clarity in the examples provided.

                                                                                        "},{"location":"services/wfs/reference/#wfs_getcap","title":"GetCapabilities","text":"

                                                                                        The GetCapabilities operation is a request to a WFS server for a list of the operations and services, or capabilities, supported by that server.

                                                                                        To issue a GET request using HTTP:

                                                                                        http://example.com/geoserver/wfs?\n  service=wfs&\n  version=1.1.0&\n  request=GetCapabilities\n

                                                                                        The equivalent request using POST:

                                                                                        <GetCapabilities\n service=\"WFS\"\n xmlns=\"http://www.opengis.net/wfs\"\n xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\"\n xsi:schemaLocation=\"http://www.opengis.net/wfs          \n http://schemas.opengis.net/wfs/1.1.0/wfs.xsd\"/>\n

                                                                                        GET requests are simplest to decode, but the POST requests are equivalent.

                                                                                        The parameters for GetCapabilities are:

                                                                                        Parameter Required? Description service Yes Service name---Value is WFS version Yes Service version---Value is the current version number. The full version number must be supplied (\"1.1.0\", \"1.0.0\"), not the abbreviated form (\"1\" or \"1.1\"). request Yes Operation name---Value is GetCapabilities

                                                                                        Although all of the above parameters are technically required as per the specification, GeoServer will provide default values if any parameters are omitted from a request.

                                                                                        The GetCapabilities response is a lengthy XML document, the format of which is different for each of the supported versions. There are five main components in a GetCapabilities document:

                                                                                        Component Description ServiceIdentification Contains basic header information for the request such as the Title and ServiceType. The ServiceType indicates which version(s) of WFS are supported. ServiceProvider Provides contact information about the company publishing the WFS service, including telephone, website, and email. OperationsMetadata Describes the operations that the WFS server supports and the parameters for each operation. A WFS server may be configured not to respond to the operations listed above. FeatureTypeList Lists the feature types published by a WFS server. Feature types are listed in the form namespace:featuretype. The default projection of the feature type is also listed, along with the bounding box for the data in the stated projection. Filter_Capabilities Lists the filters, or expressions, that are available to form query predicates, for example, SpatialOperators (such as Equals, Touches) and ComparisonOperators (such as LessThan, GreaterThan). The filters themselves are not included in the GetCapabilities document."},{"location":"services/wfs/reference/#wfs_dft","title":"DescribeFeatureType","text":"

                                                                                        DescribeFeatureType requests information about an individual feature type before requesting the actual data. Specifically, the operation will request a list of features and attributes for the given feature type, or list the feature types available.

                                                                                        The parameters for DescribeFeatureType are:

                                                                                        Parameter Required? Description service Yes Service name---Value is WFS version Yes Service version---Value is the current version number request Yes Operation name---Value is DescribeFeatureType typeNames Yes Name of the feature type to describe (typeName for WFS 1.1.0 and earlier) exceptions No Format for reporting exceptions---default value is application/vnd.ogc.se_xml outputFormat No Defines the scheme description language used to describe feature types

                                                                                        To return a list of feature types, the GET request would be as follows. This request will return the list of feature types, sorted by namespace:

                                                                                        http://example.com/geoserver/wfs?\n  service=wfs&\n  version=2.0.0&\n  request=DescribeFeatureType\n

                                                                                        To list information about a specific feature type called namespace:featuretype, the GET request would be:

                                                                                        http://example.com/geoserver/wfs?\n  service=wfs&\n  version=2.0.0&\n  request=DescribeFeatureType&\n  typeNames=namespace:featuretype\n
                                                                                        "},{"location":"services/wfs/reference/#wfs_getfeature","title":"GetFeature","text":"

                                                                                        The GetFeature operation returns a selection of features from the data source.

                                                                                        This request will execute a GetFeature request for a given layer namespace:featuretype:

                                                                                        http://example.com/geoserver/wfs?\n  service=wfs&\n  version=2.0.0&\n  request=GetFeature&\n  typeNames=namespace:featuretype\n

                                                                                        Executing this command will return the geometries for all features in given a feature type, potentially a large amount of data. To limit the output, you can restrict the GetFeature request to a single feature by including an additional parameter, featureID and providing the ID of a specific feature. In this case, the GET request would be:

                                                                                        http://example.com/geoserver/wfs?\n  service=wfs&\n  version=2.0.0&\n  request=GetFeature&\n  typeNames=namespace:featuretype&\n  featureID=feature\n

                                                                                        If the ID of the feature is unknown but you still want to limit the number of features returned, use the count parameter for WFS 2.0.0 or the maxFeatures parameter for earlier WFS versions. In the examples below, N represents the number of features to return:

                                                                                        http://example.com/geoserver/wfs?\n  service=wfs&\n  version=2.0.0&\n  request=GetFeature&\n  typeNames=namespace:featuretype&\n  count=N\n\nhttp://example.com/geoserver/wfs?\n  service=wfs&\n  version=1.1.0&\n  request=GetFeature&\n  typeName=namespace:featuretype&\n  maxFeatures=N\n

                                                                                        Exactly which N features will be returned depends in the internal structure of the data. However, you can sort the returned selection based on an attribute value. In the following example, an attribute is included in the request using the sortBy=attribute parameter (replace attribute with the attribute you wish to sort by):

                                                                                        http://example.com/geoserver/wfs?\n   service=wfs&\n   version=2.0.0&\n   request=GetFeature&\n   typeNames=namespace:featuretype&\n   count=N&\n   sortBy=attribute\n

                                                                                        The default sort operation is to sort in ascending order. Some WFS servers require the sort order to be specified, even if an ascending order sort if required. In this case, append a +A to the request. Conversely, add a +D to the request to sort in descending order as follows:

                                                                                        http://example.com/geoserver/wfs?\n  service=wfs&\n  version=2.0.0&\n  request=GetFeature&\n  typeNames=namespace:featuretype&\n  count=N&\n  sortBy=attribute+D\n

                                                                                        There is no obligation to use sortBy with count in a GetFeature request, but they can be used together to manage the returned selection of features more effectively.

                                                                                        To restrict a GetFeature request by attribute rather than feature, use the propertyName key in the form propertyName=attribute. You can specify a single attribute, or multiple attributes separated by commas. To search for a single attribute in all features, the following request would be required:

                                                                                        http://example.com/geoserver/wfs?\n  service=wfs&\n  version=2.0.0&\n  request=GetFeature&\n  typeNames=namespace:featuretype&\n  propertyName=attribute\n

                                                                                        For a single property from just one feature, use both featureID and propertyName:

                                                                                        http://example.com/geoserver/wfs?\n  service=wfs&\n  version=2.0.0&\n  request=GetFeature&\n  typeNames=namespace:featuretype&\n  featureID=feature&\n  propertyName=attribute\n

                                                                                        For more than one property from a single feature, use a comma-separated list of values for propertyName:

                                                                                        http://example.com/geoserver/wfs?\n  service=wfs&\n  version=2.0.0&\n  request=GetFeature&\n  typeNames=namespace:featuretype&\n  featureID=feature&\n  propertyName=attribute1,attribute2\n

                                                                                        While the above permutations for a GetFeature request focused on non-spatial parameters, it is also possible to query for features based on geometry. While there are limited options available in a GET request for spatial queries (more are available in POST requests using filters), filtering by bounding box (BBOX) is supported.

                                                                                        The BBOX parameter allows you to search for features that are contained (or partially contained) inside a box of user-defined coordinates. The format of the BBOX parameter is bbox=a1,b1,a2,b2,[crs] where a1, b1, a2, and b2 represent the coordinate values. The optional crs parameter is used to name the CRS for the bbox coordinates (if they are different to the featureTypes native CRS.) The order of coordinates passed to the BBOX parameter depends on the coordinate system used (this is why the coordinate syntax isn't represented with x or y.)

                                                                                        To specify the coordinate system for the returned features, append srsName=CRS to the WFS request, where CRS is the Coordinate Reference System you wish to use.

                                                                                        As for which corners of the bounding box to specify, the only requirement is for a bottom corner (left or right) to be provided first. For example, bottom left and top right, or bottom right and top left.

                                                                                        An example request returning features based on a bounding box (using the featureTypes native CRS):

                                                                                        http://example.com/geoserver/wfs?\n  service=wfs&\n  version=2.0.0&\n  request=GetFeature&\n  typeNames=namespace:featuretype&\n  srsName=CRS&\n  bbox=a1,b1,a2,b2\n

                                                                                        To request features using a bounding box with CRS different from featureTypes native CRS:

                                                                                        http://example.com/geoserver/wfs?\n  service=wfs&\n  version=2.0.0&\n  request=GetFeature&\n  typeNames=namespace:featuretype&\n  srsName=CRS&\n  bbox=a1,b1,a2,b2,CRS\n
                                                                                        "},{"location":"services/wfs/reference/#lockfeature","title":"LockFeature","text":"

                                                                                        A LockFeature operation provides a long-term feature locking mechanism to ensure consistency in edit transactions. If one client fetches a feature and makes some changes before submitting it back to the WFS, locks prevent other clients from making any changes to the same feature, ensuring a transaction that can be serialized. If a WFS server supports this operation, it will be reported in the server's GetCapabilities response.

                                                                                        In practice, few clients support this operation.

                                                                                        "},{"location":"services/wfs/reference/#wfs_wfst","title":"Transaction","text":"

                                                                                        The Transaction operation can create, modify, and delete features published by a WFS. Each transaction will consist of zero or more Insert, Update, and Delete elements, with each transaction element performed in order. Every GeoServer transaction is atomic, meaning that if any of the elements fail, the transaction is abandoned, and the data is unaltered. A WFS server that supports transactions is sometimes known as a WFS-T server. GeoServer fully supports transactions.

                                                                                        More information on the syntax of transactions can be found in the WFS specification and in the GeoServer sample requests.

                                                                                        "},{"location":"services/wfs/reference/#getgmlobject","title":"GetGMLObject","text":"

                                                                                        Note

                                                                                        This operation is valid for WFS version 1.1.0 only.

                                                                                        A GetGMLObject operation accepts the identifier of a GML object (feature or geometry) and returns that object. This operation is relevant only in situations that require app-schema.complex-features by allowing clients to extract just a portion of the nested properties of a complex feature. As a result, this operation is not widely used by client applications.

                                                                                        "},{"location":"services/wfs/reference/#getpropertyvalue","title":"GetPropertyValue","text":"

                                                                                        Note

                                                                                        This operation is valid for WFS version 2.0.0 only.

                                                                                        A GetPropertyValue operation retrieves the value of a feature property, or part of the value of a complex feature property, from a data source for a given set of features identified by a query.

                                                                                        This example retrieves the geographic content only of the features in the topp:states layer:

                                                                                        http://example.com/geoserver/wfs?\n  service=wfs&\n  version=2.0.0&\n  request=GetPropertyValue&\n  typeNames=topp:states&\n  valueReference=the_geom\n

                                                                                        The same example in a POST request:

                                                                                        <wfs:GetPropertyValue service='WFS' version='2.0.0'\n xmlns:topp='http://www.openplans.org/topp'\n xmlns:fes='http://www.opengis.net/fes/2.0'\n xmlns:wfs='http://www.opengis.net/wfs/2.0'\n valueReference='the_geom'>\n  <wfs:Query typeNames='topp:states'/>\n</wfs:GetPropertyValue>\n

                                                                                        To retrieve value for a different attribute, alter the valueReference parameter.

                                                                                        "},{"location":"services/wfs/reference/#getfeaturewithlock","title":"GetFeatureWithLock","text":"

                                                                                        Note

                                                                                        This operation is valid for WFS version 2.0.0 only.

                                                                                        A GetFeatureWithLock operation is similar to a GetFeature operation, except that when the set of features are returned from the WFS server, the features are also locked in anticipation of a subsequent transaction operation.

                                                                                        This POST example retrieves the features of the topp:states layer, but in addition locks those features for five minutes.

                                                                                        <wfs:GetFeatureWithLock service='WFS' version='2.0.0'\n handle='GetFeatureWithLock-tc1' expiry='5' resultType='results'\n xmlns:topp='http://www.openplans.org/topp'\n xmlns:fes='http://www.opengis.net/fes/2.0'\n xmlns:wfs='http://www.opengis.net/wfs/2.0'\n valueReference='the_geom'>\n  <wfs:Query typeNames='topp:states'/>\n</wfs:GetFeatureWithLock>\n

                                                                                        To adjust the lock time, alter the expiry parameter.

                                                                                        "},{"location":"services/wfs/reference/#createstoredquery","title":"CreateStoredQuery","text":"

                                                                                        Note

                                                                                        This operation is valid for WFS version 2.0.0 only.

                                                                                        A CreateStoredQuery operation creates a stored query on the WFS server. The definition of the stored query is encoded in the StoredQueryDefinition parameter and is given an ID for a reference.

                                                                                        This POST example creates a new stored query (called \"myStoredQuery\") that filters the topp:states layer to those features that are within a given area of interest (${AreaOfInterest}):

                                                                                        <wfs:CreateStoredQuery service='WFS' version='2.0.0'\n xmlns:wfs='http://www.opengis.net/wfs/2.0'\n xmlns:fes='http://www.opengis.org/fes/2.0'\n xmlns:gml='http://www.opengis.net/gml/3.2'\n xmlns:myns='http://www.someserver.com/myns'\n xmlns:topp='http://www.openplans.org/topp'>\n  <wfs:StoredQueryDefinition id='myStoredQuery'>\n    <wfs:Parameter name='AreaOfInterest' type='gml:Polygon'/>\n    <wfs:QueryExpressionText\n     returnFeatureTypes='topp:states'\n     language='urn:ogc:def:queryLanguage:OGC-WFS::WFS_QueryExpression'\n     isPrivate='false'>\n      <wfs:Query typeNames='topp:states'>\n        <fes:Filter>\n          <fes:Within>\n            <fes:ValueReference>the_geom</fes:ValueReference>\n             ${AreaOfInterest}\n          </fes:Within>\n        </fes:Filter>\n      </wfs:Query>\n    </wfs:QueryExpressionText>\n  </wfs:StoredQueryDefinition>\n</wfs:CreateStoredQuery>\n
                                                                                        "},{"location":"services/wfs/reference/#dropstoredquery","title":"DropStoredQuery","text":"

                                                                                        Note

                                                                                        This operation is valid for WFS version 2.0.0 only.

                                                                                        A DropStoredQuery operation drops a stored query previous created by a CreateStoredQuery operation. The request accepts the ID of the query to drop.

                                                                                        This example will drop a stored query with an ID of myStoredQuery:

                                                                                        http://example.com/geoserver/wfs?\n  request=DropStoredQuery&\n  storedQuery_Id=myStoredQuery\n

                                                                                        The same example in a POST request:

                                                                                        <wfs:DropStoredQuery\n xmlns:wfs='http://www.opengis.net/wfs/2.0'\n service='WFS' id='myStoredQuery'/>\n
                                                                                        "},{"location":"services/wfs/reference/#liststoredqueries","title":"ListStoredQueries","text":"

                                                                                        Note

                                                                                        This operation is valid for WFS version 2.0.0 only.

                                                                                        A ListStoredQueries operation returns a list of the stored queries currently maintained by the WFS server.

                                                                                        This example lists all stored queries on the server:

                                                                                        http://example.com/geoserver/wfs?\n  request=ListStoredQueries&\n  service=wfs&\n  version=2.0.0\n

                                                                                        The same example in a POST request:

                                                                                        <wfs:ListStoredQueries service='WFS'\n version='2.0.0'\n xmlns:wfs='http://www.opengis.net/wfs/2.0'/>\n
                                                                                        "},{"location":"services/wfs/reference/#describestoredqueries","title":"DescribeStoredQueries","text":"

                                                                                        Note

                                                                                        This operation is valid for WFS version 2.0.0 only.

                                                                                        A DescribeStoredQuery operation returns detailed metadata about each stored query maintained by the WFS server. A description of an individual query may be requested by providing the ID of the specific query. If no ID is provided, all queries are described.

                                                                                        This example describes the existing stored query with an ID of urn:ogc:def:query:OGC-WFS::GetFeatureById:

                                                                                        http://example.com/geoserver/wfs?\n  request=DescribeStoredQueries&\n  storedQuery_Id=urn:ogc:def:query:OGC-WFS::GetFeatureById\n

                                                                                        The same example in a POST request:

                                                                                        <wfs:DescribeStoredQueries\n xmlns:wfs='http://www.opengis.net/wfs/2.0'\n service='WFS'>\n  <wfs:StoredQueryId>urn:ogc:def:query:OGC-WFS::GetFeatureById</wfs:StoredQueryId>\n</wfs:DescribeStoredQueries>\n
                                                                                        "},{"location":"services/wfs/reference/#exceptions","title":"Exceptions","text":"

                                                                                        WFS also supports a number of formats for reporting exceptions. The supported values for exception reporting are:

                                                                                        Format Syntax Description XML exceptions=text/xml (default) XML output JSON exceptions=application/json Simple JSON JSONP exceptions=text/javascript Return a JSONP in the form: parseResponse(...jsonp...). See WMS vendor parameters to change the callback name. Note that this format is disabled by default (See Global variables affecting WMS)."},{"location":"services/wfs/schemamapping/","title":"WFS schema mapping","text":"

                                                                                        One of the functions of the GeoServer WFS is to automatically map the internal schema of a dataset to a feature type schema. This mapping is performed according to the following rules:

                                                                                        • The name of the feature element maps to the name of the dataset.
                                                                                        • The name of the feature type maps to the name of the dataset with the string \"Type\" appended to it.
                                                                                        • The name of each attribute of the dataset maps to the name of an element particle contained in the feature type.
                                                                                        • The type of each attribute of the dataset maps to the appropriate XML schema type (xsd:int, xsd:double, and so on).

                                                                                        For example, a dataset has the following schema:

                                                                                        myDataset(intProperty:Integer, stringProperty:String, floatProperty:Float, geometry:Point)\n

                                                                                        This schema would be mapped to the following XML schema, available via a DescribeFeatureType request for the topp:myDataset type:

                                                                                        <xsd:schema xmlns:xsd=\"http://www.w3.org/2001/XMLSchema\"\n xmlns:gml=\"http://www.opengis.net/gml\"\n xmlns:topp=\"http://www.openplans.org/topp\" \n targetNamespace=\"http://www.openplans.org/topp\"\n elementFormDefault=\"qualified\">\n\n  <xsd:import namespace=\"http://www.opengis.net/gml\"\n   schemaLocation=\"http://localhost:8080/geoserver/schemas/gml/3.1.1/base/gml.xsd\"/>\n\n  <xsd:complexType name=\"myDatasetType\">\n    <xsd:complexContent>\n      <xsd:extension base=\"gml:AbstractFeatureType\">\n        <xsd:sequence>\n          <xsd:element maxOccurs=\"1\" minOccurs=\"0\" name=\"intProperty\" nillable=\"true\" type=\"xsd:int\"/>\n          <xsd:element maxOccurs=\"1\" minOccurs=\"0\" name=\"stringProperty\" nillable=\"true\" type=\"xsd:string\"/>\n          <xsd:element maxOccurs=\"1\" minOccurs=\"0\" name=\"floatProperty\" nillable=\"true\" type=\"xsd:double\"/>\n          <xsd:element maxOccurs=\"1\" minOccurs=\"0\" name=\"geometry\" nillable=\"true\" type=\"gml:PointPropertyType\"/>\n        </xsd:sequence>\n      </xsd:extension>\n    </xsd:complexContent>\n  </xsd:complexType>\n\n  <xsd:element name=\"myDataset\" substitutionGroup=\"gml:_Feature\" type=\"topp:myDatasetType\"/>\n\n</xsd:schema>\n
                                                                                        "},{"location":"services/wfs/schemamapping/#schema-customization","title":"Schema customization","text":"

                                                                                        The GeoServer WFS supports a limited amount of schema output customization. A custom schema may be useful for the following:

                                                                                        • Limiting the attributes which are exposed in the feature type schema
                                                                                        • Changing the types of attributes in the schema
                                                                                        • Changing the structure of the schema (for example, changing the base feature type)

                                                                                        For example, it may be useful to limit the exposed attributes in the example dataset described above. Start by retrieving the default output as a benchmark of the complete schema. With the feature type schema listed above, the GetFeature request would be as follows:

                                                                                        <topp:myDataset gml:id=\"myDataset.1\">\n <topp:intProperty>1</topp:intProperty>\n  <topp:stringProperty>one</topp:stringProperty>\n  <topp:floatProperty>1.1</topp:floatProperty>\n  <topp:geometry>\n    <gml:Point srsName=\"urn:x-ogc:def:crs:EPSG:4326\">\n      <gml:pos>1.0 1.0</gml:pos>\n    </gml:Point>\n  </topp:geometry>\n</topp:myDataset>\n

                                                                                        To remove floatProperty from the list of attributes, the following steps would be required:

                                                                                        1. The original schema is modified to remove the floatProperty, resulting in the following type definition:

                                                                                          <xsd:complexType name=\"myDatasetType\">\n  <xsd:complexContent>\n    <xsd:extension base=\"gml:AbstractFeatureType\">\n      <xsd:sequence>\n        <xsd:element maxOccurs=\"1\" minOccurs=\"0\" name=\"intProperty\" nillable=\"true\" type=\"xsd:int\"/>\n        <xsd:element maxOccurs=\"1\" minOccurs=\"0\" name=\"stringProperty\" nillable=\"true\" type=\"xsd:string\"/>\n        <!-- remove the floatProperty element\n        <xsd:element maxOccurs=\"1\" minOccurs=\"0\" name=\"floatProperty\" nillable=\"true\" type=\"xsd:double\"/>\n        -->\n        <xsd:element maxOccurs=\"1\" minOccurs=\"0\" name=\"geometry\" nillable=\"true\" type=\"gml:PointPropertyType\"/>\n      </xsd:sequence>\n    </xsd:extension>\n    </xsd:complexContent>\n</xsd:complexType>\n
                                                                                        2. The modification is saved in a file named schema.xsd.

                                                                                        3. The schema.xsd file is copied into the feature type directory for the topp:myDataset which is:

                                                                                          $GEOSERVER_DATA_DIR/workspaces/<workspace>/<datastore>/myDataset/\n

                                                                                          where <workspace> is the name of the workspace containing your data store and <datastore> is the name of the data store which contains myDataset

                                                                                        The modified schema will only be available to GeoServer when the configuration is reloaded or GeoServer is restarted.

                                                                                        A subsequent DescribeFeatureType request for topp:myDataset confirms the floatProperty element is absent:

                                                                                        <xsd:schema xmlns:xsd=\"http://www.w3.org/2001/XMLSchema\"\n xmlns:gml=\"http://www.opengis.net/gml\"\n xmlns:topp=\"http://www.openplans.org/topp\" \n targetNamespace=\"http://www.openplans.org/topp\"\n elementFormDefault=\"qualified\">\n\n  <xsd:import namespace=\"http://www.opengis.net/gml\"\n   schemaLocation=\"http://localhost:8080/geoserver/schemas/gml/3.1.1/base/gml.xsd\"/>\n\n  <xsd:complexType name=\"myDatasetType\">\n    <xsd:complexContent>\n      <xsd:extension base=\"gml:AbstractFeatureType\">\n        <xsd:sequence>\n          <xsd:element maxOccurs=\"1\" minOccurs=\"0\" name=\"intProperty\" nillable=\"true\" type=\"xsd:int\"/>\n          <xsd:element maxOccurs=\"1\" minOccurs=\"0\" name=\"stringProperty\" nillable=\"true\" type=\"xsd:string\"/>\n          <xsd:element maxOccurs=\"1\" minOccurs=\"0\" name=\"geometry\" nillable=\"true\" type=\"gml:PointPropertyType\"/>\n        </xsd:sequence>\n      </xsd:extension>\n    </xsd:complexContent>\n  </xsd:complexType>\n\n  <xsd:element name=\"myDataset\" substitutionGroup=\"gml:_Feature\" type=\"topp:myDatasetType\"/>\n\n</xsd:schema>\n

                                                                                        A GetFeature request will now return features that don't include the floatProperty attribute:

                                                                                        <topp:myDataset gml:id=\"myDataset.1\">\n  <topp:intProperty>1</topp:intProperty>\n  <topp:stringProperty>one</topp:stringProperty>\n  <topp:geometry>\n    <gml:Point srsName=\"urn:x-ogc:def:crs:EPSG:4326\">\n      <gml:pos>1.0 1.0</gml:pos>\n    </gml:Point>\n  </topp:geometry>\n</topp:myDataset>\n
                                                                                        "},{"location":"services/wfs/schemamapping/#wfs_schema_type_changing","title":"Type changing","text":"

                                                                                        Schema customization may be used to perform some type changing, although this is limited by the fact that a changed type must be in the same domain as the original type. For example, integer types must be changed to integer types, temporal types to temporal types, and so on.

                                                                                        The most common change type requirement is for geometry attributes. In many cases the underlying data set does not have the necessary metadata to report the specific geometry type of a geometry attribute. The automatic schema mapping would result in an element definition similar to the following:

                                                                                        <xsd:element maxOccurs=\"1\" minOccurs=\"0\" name=\"geometry\" nillable=\"true\" type=\"gml:GeometryPropertyType\"/>\n

                                                                                        However if the specific type of the geometry is known, the element definition above could be altered. For point geometry, the element definition could be altered to :

                                                                                        <xsd:element maxOccurs=\"1\" minOccurs=\"0\" name=\"geometry\" nillable=\"true\" type=\"gml:PointPropertyType\"/>\n
                                                                                        "},{"location":"services/wfs/vendor/","title":"WFS vendor parameters","text":"

                                                                                        WFS vendor parameters are non-standard request parameters defined by an implementation to provide enhanced capabilities. GeoServer supports a variety of vendor-specific WFS parameters.

                                                                                        "},{"location":"services/wfs/vendor/#general-vendor-options","title":"General Vendor Options","text":"

                                                                                        These vendor options are available for all operations.

                                                                                        content-disposition ^^^^^^^^^^^^^^^^^^^

                                                                                        The content-disposition parameter directs how a web browser directed to handle returned content. The syntax is::

                                                                                        content-disposition=

                                                                                        Where content-disposition =attachment to direct the browser to save the content to disk.

                                                                                        Where content-disposition=inline asks the browser to display the content. Note this may present performance issues when asked to display very large content.

                                                                                        filename ^^^^^^^^

                                                                                        The filename parameter provides a suggested filename when a browser saves a file (e.g. to Downloads folder). The syntax is::

                                                                                        filename=

                                                                                        An example of filename use is::

                                                                                        filename=features.json

                                                                                        When service output is saved as a file, the vendor-option filename is used to provide the file name used.

                                                                                        "},{"location":"services/wfs/vendor/#xml-request-validation","title":"XML request validation","text":"

                                                                                        GeoServer is less strict than the WFS specification when it comes to the validity of an XML request. To force incoming XML requests to be valid, use the following parameter:

                                                                                        strict=[true|false]\n

                                                                                        The default option for this parameter is false.

                                                                                        For example, the following request is invalid:

                                                                                        <wfs:GetFeature service=\"WFS\" version=\"1.0.0\"\n xmlns:wfs=\"http://www.opengis.net/wfs\">\n  <Query typeName=\"topp:states\"/>\n</wfs:GetFeature>\n

                                                                                        The request is invalid for two reasons:

                                                                                        • The Query element should be prefixed with wfs:.
                                                                                        • The namespace prefix has not been mapped to a namespace URI.

                                                                                        That said, the request would still be processed by default. Executing the above command with the strict=true parameter, however, would result in an error. The correct syntax should be:

                                                                                        <wfs:GetFeature service=\"WFS\" version=\"1.0.0\"\n xmlns:wfs=\"http://www.opengis.net/wfs\" \n xmlns:topp=\"http://www.openplans.org/topp\">\n  <wfs:Query typeName=\"topp:states\"/>\n</wfs:GetFeature>\n
                                                                                        "},{"location":"services/wfs/vendor/#getcapabilities-request","title":"GetCapabilities Request","text":""},{"location":"services/wfs/vendor/#namespace-filter","title":"Namespace filter","text":"

                                                                                        WFS GetCapabilities requests may be filtered to return only those layers that correspond to a particular namespace by adding the <namespace> parameter to the request.

                                                                                        Note

                                                                                        This parameter only affects GetCapabilities requests.

                                                                                        To apply this filter, add the following code to your request:

                                                                                        namespace=<namespace>\n

                                                                                        Although providing an invalid namespace will not result in any errors, the GetCapabilities document returned will not contain any layer information.

                                                                                        Warning

                                                                                        Using this parameter may result your GetCapabilities document becoming invalid, as the WFS specification requires the document to return at least one layer.

                                                                                        Note

                                                                                        This filter is related to Virtual Services.

                                                                                        "},{"location":"services/wfs/vendor/#getfeature-request","title":"GetFeature Request","text":""},{"location":"services/wfs/vendor/#cql-filters","title":"CQL filters","text":"

                                                                                        In WFS GetFeature GET requests, the cql_filter parameter can be used to specify a filter in ECQL (Extended Common Query Language) format. ECQL provides a more compact and readable syntax compared to OGC XML filters.

                                                                                        For full details see the ECQL Reference and CQL and ECQL tutorial.

                                                                                        The following example illustrates a GET request OGC filter:

                                                                                        filter=%3CFilter%20xmlns:gml=%22http://www.opengis.net/gml%22%3E%3CIntersects%3E%3CPropertyName%3Ethe_geom%3C/PropertyName%3E%3Cgml:Point%20srsName=%224326%22%3E%3Cgml:coordinates%3E-74.817265,40.5296504%3C/gml:coordinates%3E%3C/gml:Point%3E%3C/Intersects%3E%3C/Filter%3E\n

                                                                                        Using ECQL, the identical filter would be defined as follows:

                                                                                        cql_filter=INTERSECTS(the_geom,%20POINT%20(-74.817265%2040.5296504))\n
                                                                                        "},{"location":"services/wfs/vendor/#format-options","title":"Format options","text":"

                                                                                        The format_options parameter is a container for other parameters that are format-specific. The syntax is:

                                                                                        format_options=param1:value1;param2:value2;...\n

                                                                                        The supported format option is:

                                                                                        • callback (default is parseResponse) - specifies the callback function name for the JSONP response format
                                                                                        • id_policy (default is true) - Specifies id generation for the JSON output format. To include feature id in the output, use an attribute name, or use format_options=id_policy:true for feature id generation. To avoid the use of feature id completely use format_options=id_policy:false.
                                                                                        • filename (default is features or generated from feature type name)- provide a Content-Disposition header indicating the attachment filename (used as a suggestion by browsers saving content to disk using Save-As). For example format_options=filename:content.txt.
                                                                                        • csvseparator (default is `, ``` )- Specifies a separator that can be used in output csv file
                                                                                        "},{"location":"services/wfs/vendor/#reprojection","title":"Reprojection","text":"

                                                                                        As WFS 1.1.0 and 2.0.0 both support data reprojection, GeoServer can store the data in one projection and return GML in another projection. While not part of the specification, GeoServer supports this using WFS 1.0.0 as well. When submitting a WFS GetFeature GET request, you can add this parameter to specify the reprojection SRS as follows:

                                                                                        srsName=<srsName>\n

                                                                                        The code for the projection is represented by <srsName>, for example EPSG:4326. For POST requests, you can add the same code to the Query element.

                                                                                        "},{"location":"services/wfs/webadmin/","title":"WFS settings","text":"

                                                                                        This page details the configuration options for WFS in the web administration interface.

                                                                                        "},{"location":"services/wfs/webadmin/#workspace","title":"Workspace","text":"

                                                                                        Select workspace empty to configure global WFS settings.

                                                                                        See the section on Workspace Services to override settings used by WFS Virtual Services.

                                                                                        "},{"location":"services/wfs/webadmin/#service-metadata","title":"Service Metadata","text":"

                                                                                        For a description of WFS service options, see the section on Service Metadata.

                                                                                        "},{"location":"services/wfs/webadmin/#features","title":"Features","text":"

                                                                                        WFS configuration options - Features section

                                                                                        The Open Geospatial Consortium (OGC) Web Feature Service (WFS) is a protocol for serving geographic features across the Web. Feature information that is encoded and transported using WFS includes both feature geometry and feature attribute values. Basic Web Feature Service (WFS) supports feature query and retrieval. Feature limits and bounding can be configured on the WFS page.

                                                                                        Maximum number of features --- Maximum number of features that a WFS GetFeature operation should generate, regardless of the actual number of query hits. A WFS request can potentially contain a large dataset that is impractical to download to a client, and/or too large for a client's renderer. Maximum feature limits are also available for feature types. The default number is 1000000.

                                                                                        Maximum number of features for preview (Values <= 0 use the maximum number of features) - Maximum number of features to use for layer previews. The default is 50 features.

                                                                                        Return bounding box with every feature --- When creating the GetFeature GML output, adds an auto-calculated bounds element on each feature type. Not typically enabled, as including bounding box takes up extra bandwidth.

                                                                                        Ignore maximum number of features when calculating hits - When calculating the total number of hits, ignore the Maximum number of features setting. This can be used to get the count of matching features, even if they would not be made available for download because they exceed the maximum count specified. On very large data sets, this can slow down the response.

                                                                                        Activate complex to simple features conversion - Enables the conversion of complex features to simple features, using only SF-0 (simple) attributes for compatible output formats like CSV, KML, SHAPE-ZIP.

                                                                                        "},{"location":"services/wfs/webadmin/#service-levels","title":"Service Levels","text":"

                                                                                        WFS configuration options - Service Level section

                                                                                        GeoServer is compliant with the full \"Transactional Web Feature Server\" (WFS-T) level of service as defined by the OGC. Specifying the WFS service level limits the capabilities of GeoServer while still remaining compliant. The WFS Service Level setting defines what WFS operations are \"turned on\".

                                                                                        Basic --- Basic service levels provides facilities for searching and retrieving feature data with the GetCapabilities, DescribeFeatureType and GetFeature operations. It is compliant with the OGC basic Web Feature Service. This is considered a READ-ONLY web feature service.

                                                                                        Transactional --- In addition to all basic WFS operations, transactional service level supports transaction requests. A transaction request facilitates the creation, deletion, and updating of geographic features in conformance with the OGC Transactional Web Feature Service (WFS-T).

                                                                                        Complete --- Includes LockFeature support to the suite of transactional level operations. LockFeature operations help resolve links between related resources by processing lock requests on one or more instances of a feature type.

                                                                                        "},{"location":"services/wfs/webadmin/#extra-srs-codes-for-wfs-capabilities-generation","title":"Extra SRS codes for WFS capabilities generation","text":"

                                                                                        WFS 1.1.0 onwards adds the ability to reproject GetFeature output to a user specified target SRS. The list of applicable target SRS is defined on a feature type basis in the capabilities documents, and GeoServer allows reprojection to any supported SRS in its internal database. To declare that GeoServer would have to add 5000+ otherSRS/otherCRS elements per feature type, which is clearly impractical. As a result, no declaration is made by default.

                                                                                        A list of values to be declared in all feature types can be provided in the WFS administration panel, as a comma separated list of EPSG codes:

                                                                                        WFS otherSRS/otherCRS configuration

                                                                                        The list will be used only for the capabilities document generation. It does not limit the actual target SRS usage in GetFeature requests.

                                                                                        "},{"location":"services/wfs/webadmin/#csv","title":"CSV","text":"

                                                                                        WFS configuration options - CSV section

                                                                                        CSV is still widely used as a format to exchange tabular data. For GeoServer CSV output format, the date field format can specified using the Date Format text box as shown above. Here are some common formatting patterns supported

                                                                                        Date and Time Pattern Result yyyy.MM.dd G 'at' HH:mm:ss z 2001.07.04 AD at 12:08:56 PDT EEE, MMM d, ''yy Wed, Jul 4, '01 yyyy-MM-dd'T'HH:mm:ss.SSSZ 2001-07-04T12:08:56.235-0700 yyyy-MM-dd'T'HH:mm:ss.SSSXXX 2001-07-04T12:08:56.235-07:00

                                                                                        Here, yyyy-MM-dd'T'HHss.SSS'Z' pattern represents the year, month, day, hour, minute, second and milliseconds. The components are separated by a hyphen character. A literal 'T' character is used to separate the date and time parts. A literal 'Z' character represents the UTC time zone. For instance, yyyy represents the year with four digits, MM represents the month with leading zeros, dd represents the day with leading zeros, and so on.

                                                                                        Similarly, patterns can be formed by using the characters provided below

                                                                                        y- Year (four digits) \nyy- Year (two digits) \nyyyy- Year (four digits) \nM- Month (1 or 2 digits) \nMM- Month (2 digits, with leading zero) \nMMM- Month abbreviation (e.g., 'Jan', 'Feb') \nMMMM- Full month name (e.g., 'January', 'February') \nd- Day of the month (1 or 2 digits) \ndd- Day of the month (2 digits, with leading zero) \nE- Day of the week abbreviation (e.g., 'Mon', 'Tue') \nEEEE- Full day of the week (e.g., 'Monday', 'Tuesday') \nH- Hour in 24-hour format (0 to 23) \nHH- Hour in 24-hour format (2 digits, with leading zero) \nh- Hour in 12-hour format (1 to 12) \nhh- Hour in 12-hour format (2 digits, with leading zero) \nm- Minute (1 or 2 digits) \nmm- Minute (2 digits, with leading zero) \ns- Second (1 or 2 digits) \nss- Second (2 digits, with leading zero) \nSSS- Represents the milliseconds in a three-digit format (e.g., 750)\na- AM/PM marker \nn- Nanosecond \nZ- Time zone offset (e.g., '+0800') \nzzzz- Time zone full name (e.g., 'Pacific Standard Time')\n

                                                                                        Reference SimpleDateFormat Link : https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/text/SimpleDateFormat.html

                                                                                        "},{"location":"services/wfs/webadmin/#configuration-of-output-format-types-allowed-in-getfeature","title":"Configuration of Output Format types allowed in GetFeature","text":"

                                                                                        Checking the Enable Output Format type checking checkbox will enable restrictions on the available output formats for GetFeature requests. It will also limit what Output Format types will be displayed as available in GetCapabilities responses. GetFeature requests with Output types not included in the Allowed Output types panel will result in an Invalid Parameter ServiceException response.

                                                                                        Note that if the Allowed Output Types panel is left as empty and the Enable Output Format Type checking is checked, all Output types will be restricted.

                                                                                        Output Format types configuration

                                                                                        "},{"location":"services/wfs/webadmin/#gml","title":"GML","text":"

                                                                                        WFS configuration options - GML sections

                                                                                        Geography Markup Language (GML) is the XML-based specification defined by the Open Geospatial Consortium (OGC) to express geographical features. GML serves as a modeling language for geographic systems as well as an open interchange format for geographic transactions on the Internet.

                                                                                        The older GML standard, GML 2 encodes geographic information, including both spatial and non-spatial properties. GML3 extends GML2 support to 3D shapes (surfaces and solids) as well as other advanced facilities. GML 3 is a modular superset of GML 2 that simplifies and minimizes the implementation size by allowing users to select out necessary parts. Additions in GML 3 include support for complex geometries, spatial and temporal reference systems, topology, units of measure, metadata, gridded data, and default styles for feature and coverage visualization. GML 3 is almost entirely backwards compatible with GML 2.

                                                                                        WFS 2.0.0 request return GML 3.2 as the default format, WFS 1.1.0 requests return GML 3 as the default format, and WFS 1.0.0 requests return GML 2 as the default format. For each of the GML formats supported by GeoServer, a different SRS format can be selected.

                                                                                        EPSG Code --- Returns the typical EPSG number in the form EPSG:XXXX (e.g. EPSG:4326). This formats the geographic coordinates in longitude/latitude (x/y) order.

                                                                                        OGC HTTP URL --- Returns a URL that identifies each EPSG code: http://www.opengis.net/gml/srs/epsg.xml#XXXX (e.g. http://www.opengis.net/gml/srs/epsg.xml#4326). This formats the geographic coordinates in longitude/latitude (x/y) order. This format is the default GML 2 SRS convention.

                                                                                        OGC Experimental URN - Returns a URN that identifies each EPSG code: urn:x-ogc:def:crs:EPSG:XXXX (e.g. urn:x-ogc:def:crs:EPSG:4326). This format was the original GML 3 SRS convention.

                                                                                        OGC URN --- (WFS 1.1.1 only) Returns the colon delimited SRS formatting: urn:ogc:def:crs:EPSG::XXXX (e.g urn:ogc:def:crs:EPSG::4326). This is the revised GML 3 SRS convention, and is the default for GML 3.2. This formats data in the traditional axis order for geographic and cartographic systems---latitude/longitude (y/x).

                                                                                        OGC HTTP URI - Returns a URI that identifies each EPSG code: http://www.opengis.net/def/crs/EPSG/0/XXXX (e.g. http://www.opengis.net/def/crs/EPSG/0/4326).

                                                                                        For each GML type, there is also an \"Override GML Attributes\" checkbox. Selecting this (checking the checkbox) will cause attributes to be redefined in the application schema.

                                                                                        "},{"location":"services/wfs/webadmin/#override-gml-32-mime-type","title":"Override GML 3.2 MIME type","text":"

                                                                                        The default MIME used for GML 3.2 encoded responses is application/gml+xml; version=3.2 which is the MIME type mandated by OGC WFS 2.0 specification. This MIME type is not identified as XML by most common clients such as browsers.

                                                                                        Option Override MIME Type allows the selection of the MIME type that should be used for the responses encoded in GML 3.2.

                                                                                        The available MIME types are: application/gml+xml; version=3.2, text/xml; subtype=gml/3.2 and text/xml.

                                                                                        "},{"location":"services/wfs/webadmin/#configure-xml-entity-expansion-limit-on-wfs-xml-readers","title":"Configure XML Entity Expansion limit on WFS XML readers","text":"

                                                                                        By default, the WFS XML reader sets Entity Expansion limit to 100, but it can be configured via the org.geoserver.wfs.xml.entityExpansionLimit system property, or using the web.xml init parameter, or by Environment variable.

                                                                                        For example, using the command line the limit can be adjusted using a parameter:

                                                                                        -Dorg.geoserver.wfs.xml.entityExpansionLimit=50

                                                                                        Or in Tomcat properties file ({TOMCAT_HOME}/conf/catalina.properties) adding the line:

                                                                                        org.geoserver.wfs.xml.entityExpansionLimit=50

                                                                                        "},{"location":"services/wfs/webadmin/#conformance","title":"Conformance","text":"

                                                                                        WFS configuration options - Conformance section

                                                                                        Selecting the Encode canonical WFS schema location checkbox modifies the WFS responses to include the canonical schema locations in the xsi:schemaLocation attribute, instead of using the default schema locations on the local GeoServer. Note that turning this option on may result in the client not being able to validate the WFS response, depending on network configuration.

                                                                                        "},{"location":"services/wfs/webadmin/#encode-response-with","title":"Encode response with","text":"

                                                                                        WFS configuration options - Encode response with

                                                                                        The Encode response with radio button group has two selection - One \"featureMembers\" element (the default) or Multiple \"featureMember\" elements. This switches the WFS 1.1.0 encoding accordingly. Use of multiple featureMember elements may be required for Application Schema referencing.

                                                                                        "},{"location":"services/wfs/webadmin/#shape-zip-output-format","title":"SHAPE-ZIP output format","text":"

                                                                                        WFS configuration options - Encode response with

                                                                                        Selecting the Use ESRI WKT format for SHAPE-ZIP generated .prj files checkbox modifies how projections are encoded in the Shapefile zip output format. If this checkbox is not selected, OGC WKT format will be used. If this checkbox is selected, ESRI WKT format will be used.

                                                                                        Note: this requires an esri.properties file to be provided in the user_projections subdirectory of the GeoServer data directory. This may be obtained from the GeoTools EPSG extension.

                                                                                        Selecting the Include WFS request dump file checkbox specifies if the file 'wfsrequest.txt' will be included in the Shapefile zip output. 'wfsrequest.txt' contains a dump of the full request URL used to get the Shapefile zip output. If this checkbox is not selected, 'wfsrequest.txt' will not be included in the output. If this checkbox is selected, 'wfsrequest.txt' will be included in the output.

                                                                                        "},{"location":"services/wfs/webadmin/#stored-queries","title":"Stored Queries","text":"

                                                                                        Selecting the Allow Global Stored Queries checkbox determines if global stored queries will included for usage in workspace virtual services, or not. When disabled, only stored queries created inside the workspace will be visible.

                                                                                        "},{"location":"services/wfs/webadmin/#i18n-settings","title":"i18n Settings","text":"

                                                                                        Select default language for WFS Service.

                                                                                        Default language

                                                                                        See Internationalization (i18n) section for a how this setting is used.

                                                                                        "},{"location":"services/wms/","title":"Web Map Service (WMS)","text":"

                                                                                        This section describes the Web Map Service (WMS).

                                                                                        • WMS settings
                                                                                        • WMS basics
                                                                                        • GetCapabilities
                                                                                        • Time Support in GeoServer WMS
                                                                                        • WMS output formats
                                                                                        • WMS vendor parameters
                                                                                        • Non Standard AUTO Namespace
                                                                                        • WMS configuration
                                                                                        • Global variables affecting WMS
                                                                                        • GetLegendGraphic
                                                                                        • WMS Decorations
                                                                                        • Google Earth
                                                                                        "},{"location":"services/wms/basics/","title":"WMS basics","text":"

                                                                                        GeoServer provides support for Open Geospatial Consortium (OGC) Web Map Service (WMS) versions 1.1.1 and 1.3.0. This is the most widely used standard for generating maps on the web, and it is the primary interface to request map products from GeoServer. Using WMS makes it possible for clients to overlay maps from several different sources in a seamless way.

                                                                                        GeoServer's WMS implementation fully supports the standard, and is certified compliant against the OGC's test suite. It includes a wide variety of rendering and labeling options, and is one of the fastest WMS Servers for both raster and vector data.

                                                                                        GeoServer WMS supports reprojection to any coordinate reference system in the EPSG database. It is possible to add additional coordinate systems if the Well Known Text definition is known. See Coordinate Reference System Handling for details.

                                                                                        GeoServer fully supports the Styled Layer Descriptor (SLD) standard, and uses SLD files as its native styling language. For more information on how to style data in GeoServer see the section Styling

                                                                                        "},{"location":"services/wms/basics/#differences-between-wms-versions","title":"Differences between WMS versions","text":"

                                                                                        The major differences between versions 1.1.1 and 1.3.0 are:

                                                                                        • In 1.1.1 geographic coordinate systems specified with the EPSG namespace are defined to have an axis ordering of longitude/latitude. In 1.3.0 the ordering is latitude/longitude. See Axis Ordering below for more details.
                                                                                        • In the GetMap operation the srs parameter is called crs in 1.3.0. GeoServer supports both keys regardless of version.
                                                                                        • In the GetFeatureInfo operation the x and y parameters are called i and j in 1.3.0. GeoServer supports both keys regardless of version, except when in CITE-compliance mode.
                                                                                        "},{"location":"services/wms/basics/#axis_ordering","title":"Axis Ordering","text":"

                                                                                        The WMS 1.3.0 specification mandates using the axis ordering as defined in the EPSG database. For instance, for EPSG:4326 the axis ordering is latitude/longitude, or north/east. This is contrary to the fact that most spatial data is usually in longitude/latitude, or east/north.

                                                                                        The WMS 1.1 always uses east/north axis ordering. So when upgrading from WMS 1.1, if the CRS defines north/east axis ordering (e.g. EPSG:4326), the coordinate order in the BBOX parameter must be reversed.

                                                                                        For example, consider the WMS 1.1 request using the WGS84 SRS (EPSG:4326):

                                                                                        geoserver/wms?VERSION=1.1.1&REQUEST=GetMap&SRS=epsg:4326&BBOX=-180,-90,180,90&...

                                                                                        The equivalent WMS 1.3.0 request is:

                                                                                        geoserver/wms?VERSION=1.3.0&REQUEST=GetMap&CRS=epsg:4326&BBOX=-90,-180,90,180&...

                                                                                        Note that the coordinates specified in the BBOX parameter are reversed.

                                                                                        "},{"location":"services/wms/configuration/","title":"WMS configuration","text":""},{"location":"services/wms/configuration/#layer-groups","title":"Layer Groups","text":"

                                                                                        A Layer Group is a group of layers that can be referred to by one layer name. For example, if you put three layers (call them layer_A, layer_B, and layer_C) under the one \"Layer Group\" layer, then when a user makes a WMS getMap request for that group name, they will get a map of those three layers.

                                                                                        For information on configuring Layer Groups in the Web Administration Interface see Layer Groups

                                                                                        "},{"location":"services/wms/configuration/#wms_configuration_limits","title":"Request limits","text":"

                                                                                        The request limit options allow the administrator to limit the resources consumed by each WMS GetMap request.

                                                                                        The following table shows the option names, a description, and the minimum GeoServer version at which the option is available (older versions will ignore it if set).

                                                                                        Option Description Version Max rendering memory (KB) Sets the maximum amount of memory a single GetMap request is allowed to use (in kilobytes). The limit is checked before request execution by estimating how much memory would be required to produce the output in the format requested. For example, for an image format the estimate is based on the size of the required rendering memory (which is determined by the image size, the pixel bit depth, and the number of active FeatureTypeStyles at the requested scale). If the estimated memory size is below the limit, the request is executed; otherwise it is cancelled. 1.7.5 Max rendering time (s) Sets the maximum amount of time GeoServer will spend processing a request (in seconds). This time limits the \"blind processing\" portion of the request, that is, the time taken to read data and compute the output result (which may occur concurrently). If the execution time reaches the limit, the request is cancelled. The time required to write results back to the client is not limited by this parameter, since this is determined by the (unknown) network latency between the server and the client. For example, in the case of PNG/JPEG image generation, this option limits the data reading and rendering time, but not the time taken to write the image out. 1.7.5 Max rendering errors (count) Sets the maximum amount of rendering errors tolerated by a GetMap request. By default GetMap makes a best-effort attempt to serve the result, ignoring invalid features, reprojection errors and the like. Setting a limit on the number of errors ignored can make it easier to notice issues, and conserves CPU cycles by reducing the errors which must be handled and logged 1.7.5 Max number of dimension values Sets the maximum number of dimension (time, elevation, custom) values that a client can request in a GetMap/GetFeatureInfo request (the work to be done is usually proportional to said number of times, and the list of values is kept in memory during the processing) 2.14.0

                                                                                        The default value of each limit is 0, which specifies that the limit is not applied.

                                                                                        If any of the request limits is exceeded, the GetMap operation is cancelled and a ServiceException is returned to the client.

                                                                                        When setting the above limits it is suggested that peak conditions be taken into consideration. For example, under normal circumstances a GetMap request may take less than a second. Under high load it is acceptable for it to take longer, but it's usually not desirable to allow a request to go on for 30 minutes.

                                                                                        The following table shows examples of reasonable values for the request limits:

                                                                                        Option Value Rationale maxRequestMemory 16384 16MB are sufficient to render a 2048x2048 image at 4 bytes per pixel (full color and transparency), or a 8x8 meta-tile when using GeoWebCache or TileCache. Note that the rendering process uses a separate memory buffer for each FeatureTypeStyle in an SLD, so this also affects the maximum image size. For example, if an SLD contains two FeatureTypeStyle elements in order to draw cased lines for a highway, the maximum image size will be limited to 1448x1448 (the memory requirement increases with the product of the image dimensions, so halving the memory decreases image dimensions by only about 30%) maxRenderingTime 120 A request that processes for a full two minutes is probably rendering too many features, regardless of the current server load. This may be caused by a request against a big layer using a style that does not have suitable scale dependencies maxRenderingErrors 100 Encountering 100 errors is probably the result of a request trying to reproject a big data set into a projection that is not appropriate for the output extent, resulting in many reprojection failures."},{"location":"services/wms/configuration/#layergroup-capabilities-settings","title":"LayerGroup Capabilities Settings","text":"Option Description Default LayerGroup Style In GetCapabilities Enable/disable the encoding of the default LayerGroup style in GetCapabilties responses for LayerGroup with mode Named Tree, Container Tree, Earth Observation Tree. Single and Opaque groups are not affected by the option and will always show the default style. By default the option is set to enabled."},{"location":"services/wms/decoration/","title":"WMS Decorations","text":"

                                                                                        WMS Decorations provide a framework for visually annotating images from WMS with absolute, rather than spatial, positioning. Examples of decorations include compasses, legends, and watermarks.

                                                                                        "},{"location":"services/wms/decoration/#configuration","title":"Configuration","text":"

                                                                                        To use decorations in a GetMap request, the administrator must first configure a decoration layout. These layouts are stored in a subdirectory called layouts in the GeoServer data directory as XML files, one file per layout. Each layout file must have the extension .xml. Once a layout foo.xml is defined, users can request it by adding &format_options=layout:foo to the request parameters.

                                                                                        Layout files follow a very simple XML structure; a root node named layout containing any number of decoration elements. The order of the decoration elements is the order they are drawn so, in case they are overlapping, the first one will appear under the others.

                                                                                        Each decoration element has several attributes:

                                                                                        Attribute Meaning type the type of decoration to use (see Decoration Types) affinity the region of the map image to which the decoration is anchored offset how far from the anchor point the decoration is drawn size the maximum size to render the decoration. Note that some decorations may dynamically resize themselves.

                                                                                        Each decoration element may also contain an arbitrary number of option elements providing a parameter name and value:

                                                                                        <option name=\"foo\" value=\"bar\"/>\n

                                                                                        Option interpretation depends on the type of decoration in use.

                                                                                        "},{"location":"services/wms/decoration/#wms_decoration_types","title":"Decoration Types","text":"

                                                                                        While GeoServer allows for decorations to be added via extension, there is a core set of decorations included in the default installation. These decorations include:

                                                                                        The image decoration (type=\"image\") overlays a static image file onto the document. If height and width are specified, the image will be scaled to fit, otherwise the image is displayed at full size.

                                                                                        Option Name Meaning url provides the URL or file path to the image to draw (relative to the GeoServer data directory) opacity a number from 0 to 100 indicating how opaque the image should be.

                                                                                        The scaleratio decoration (type=\"scaleratio\") overlays a text description of the map's scale ratio onto the document.

                                                                                        Option Name Meaning bgcolor the background color for the text. supports RGB or RGBA colors specified as hex values. fgcolor the color for the text and border. follows the color specification from bgcolor. format the number format pattern, specified using Java own DecimalFormat syntax formatLanguage the language used to drive number formatting (applies only if also format is used), using a valid Java Locale

                                                                                        The scaleline decoration (type=\"scaleline\") overlays a graphic showing the scale of the map in world units.

                                                                                        Option Name Meaning bgcolor the background color, as used in scaleratio fgcolor the foreground color, as used in scaleratio fontsize the size of the font to use transparent if set to true, the background and border won't be painted (false by default) measurement-system can be set to \"metric\" to only show metric units, \"imperial\" to only show imperial units, or \"both\" to show both of them (default)

                                                                                        The legend decoration (type=\"legend\") overlays a graphic containing legends for the layers in the map.

                                                                                        Option Name Meaning legend_options the list of legend_options used as in GetLegendGraphic opacity the legend opacity with a value between 0 and 1

                                                                                        The text decoration (type=\"text\") overlays a parametric, single line text message on top of the map. The parameter values can be fed via the env request parameter, just like SLD environment parameters.

                                                                                        Option Name Meaning message the message to be displayed, as plain text or Freemarker template that can use the env map contents to expand variables font-family the name of the font used to display the message, e.g., Arial, defaults to Serif font-size the size of the font to use (can have decimals), defaults to 12 font-italic it true the font will be italic, defaults to false font-bold if true the font will be bold, defaults to false font-color the color of the message, in #RRGGBB or #RRGGBBAA format, defaults to black halo-radius the radius of a halo around the message, can have decimals, defaults to 0 halo-color the halo fill color, in #RRGGBB or #RRGGBBAA format, defaults to white"},{"location":"services/wms/decoration/#example","title":"Example","text":"

                                                                                        A layout configuration file might look like this:

                                                                                        <layout>\n    <decoration type=\"image\" affinity=\"bottom,right\" offset=\"6,6\" size=\"80,31\">\n        <option name=\"url\" value=\"pbGS_80x31glow.png\"/>\n    </decoration>\n\n    <decoration type=\"scaleline\" affinity=\"bottom,left\" offset=\"36,6\"/>\n\n    <decoration type=\"legend\" affinity=\"top,left\" offset=\"6,6\" size=\"auto\"/>\n</layout>\n

                                                                                        Used against the states layer from the default GeoServer data, this layout produces an image like the following.

                                                                                        The default states layer, drawn with the decoration layout above.

                                                                                        "},{"location":"services/wms/decoration/#wms_dynamic_decorations","title":"Expressions in decoration attributes and options","text":"

                                                                                        Each decoration can have options to control its appearance, as well as attributes controlling its positioning. Option and attribute values are normally static strings specified in the decoration layout.

                                                                                        However, it's also possible to make them dynamic using (E)CQL expressions, using the ${cql expression} syntax. The expression can use functions, and in particular it can access env variables provided though the request.

                                                                                        For example, this decoration layout:

                                                                                        <layout>\n    <decoration type=\"scaleline\" affinity=\"${env('sla', 'bottom,left')}\">\n       <option name=\"bgcolor\" value=\"${env('bg', '#AAAAAA')}\"/>\n    </decoration>\n</layout>\n

                                                                                        Would generate a scale line with:

                                                                                        • A light gray background, with a GetMap request that does not contain the bg env variable.
                                                                                        • A red background, if the request includes a env section like &env=bg:FF0000.
                                                                                        • A scaleline positioned on the top right, if the request includes a env section like &env=sla:top,right.

                                                                                        All options allow usage of expressions, with one notable exception: the message option in the text decoration. This one option cannot use expressions, as it would allow expansion, and evaluation, of user provided FreeMarker templates. The template can contain control structures, loops and other active elements, as such, allowing its value to be provided via WMS requests is deemed too risky.

                                                                                        "},{"location":"services/wms/global/","title":"Global variables affecting WMS","text":"

                                                                                        This document details the set of global variables that can affect WMS behaviour. Each global variable can be set as an environment variable, as a servlet context variable, or as a Java system property, just like the well known GEOSERVER_DATA_DIR setting. Refer to Setting the data directory location for details on how a global variable can be specified.

                                                                                        "},{"location":"services/wms/global/#max_filter_rules","title":"MAX_FILTER_RULES","text":"

                                                                                        A integer number (defaults to 20) When drawing a style containing multiple active rules the renderer combines the filters of the rules in OR and adds them to the standard bounding box filter. This behaviour is active up until the maximum number of filter rules is reached, past that the rule filters are no more added to avoid huge queries. By default up to 20 rules are combined, past 20 rules only the bounding box filter is used. Turning it off (setting it to 0) can be useful if the styles are mostly classifications, detrimental if the rule filters are actually filtering a good amount of data out.

                                                                                        "},{"location":"services/wms/global/#optimize_line_width","title":"OPTIMIZE_LINE_WIDTH","text":"

                                                                                        Can be true or false (defaults to: false). When true any stroke whose width is less than 1.5 pixels gets slimmed down to \"zero\", which is actually not zero, but a very thin line. That was the behaviour GeoServer used to default to before the 2.0 series. When false the stroke width is not modified and it's possible to specify widths less than one pixel. This is the default behaviour starting from the 2.0.0 release

                                                                                        "},{"location":"services/wms/global/#enable_jsonp","title":"ENABLE_JSONP","text":"

                                                                                        Can be true or false (defaults to: false). When true the JSONP (text/javascript) output format is enabled.

                                                                                        "},{"location":"services/wms/nonstandardautonamespace/","title":"Non Standard AUTO Namespace","text":"

                                                                                        The WMS standard supports a small number of \"automatic\" coordinate reference systems that include a user-selected centre of projection. These are specified using:

                                                                                        AUTO:auto_crs_id,factor,lon0,lat0\n

                                                                                        for example:

                                                                                        CRS=AUTO:42003,1,-100,45\n

                                                                                        Note

                                                                                        in GeoServer 2.8.x AUTO and AUTO2 namespaces are treated identically.

                                                                                        Note

                                                                                        in GeoServer 2.8.x the factor parameter in the AUTO namespace is ignored. The BBOX parameter to GetMap must therefore be specified in metres.

                                                                                        The WMS standard provide projections with IDs in the range 42001 to 42005.

                                                                                        ID Projection 42001 Universal Transverse Mercator 42002 Transverse Mercator 42003 Orthographic 42004 Equirectangular 42005 Mollweide (not supported in GeoServer 2.8.x)

                                                                                        GeoServer also supports some non-standard coordinate reference systems. These are

                                                                                        ID Projection 97001 Gnomonic 97002 Stereographic

                                                                                        Note

                                                                                        the auto stereographic projection uses a sphere. It does this by setting the semi minor axis to the same value as the semi major axis.

                                                                                        "},{"location":"services/wms/outputformats/","title":"WMS output formats","text":"

                                                                                        WMS returns images in a number of possible formats. This page shows a list of the output formats. The syntax for setting an output format is:

                                                                                        format=<format>\n

                                                                                        where <format> is any of the options below.

                                                                                        Note

                                                                                        The list of output formats supported by a GeoServer instance can be found by a WMS GetCapabilities request.

                                                                                        Format Syntax Notes PNG format=image/png Default PNG8 format=image/png8 Same as PNG, but computes an optimal 256 color (8 bit) palette, so the image size is usually smaller JPEG format=image/jpeg JPEG-PNG format=image/vnd.jpeg-png A custom format that will decide dynamically, based on the image contents, if it's best to use a JPEG or PNG compression. The images are returned in JPEG format if fully opaque and not paletted. In order to use this format in a meaningful way the GetMap must include a \"&transparent=TRUE\" parameter, as without it GeoServer generates opaque images with the default/requested background color, making this format always return JPEG images (or always PNG, if they are paletted). When using the layer preview to test this format, remember to add \"&transparent=TRUE\" to the preview URL, as normally the preview generates non transparent images. JPEG-PNG8 format=image/vnd.jpeg-png8 Same as JPEG-PNG, but generating a paletted output if the PNG format is chosen GIF format=image/gif TIFF format=image/tiff TIFF8 format=image/tiff8 Same as TIFF, but computes an optimal 256 color (8 bit) palette, so the image size is usually smaller GeoTIFF format=image/geotiff Same as TIFF, but includes extra GeoTIFF metadata GeoTIFF8 format=image/geotiff8 Same as TIFF, but includes extra GeoTIFF metadata and computes an optimal 256 color (8 bit) palette, so the image size is usually smaller SVG format=image/svg PDF format=application/pdf GeoRSS format=rss KML format=kml KMZ format=kmz MapML format=text/mapml MapML HTML Viewer text/html; subtype=mapml OpenLayers format=application/openlayers Generates an OpenLayers HTML application. UTFGrid format=application/json;type=utfgrid Generates an UTFGrid 1.3 JSON response. Requires vector output, either from a vector layer, or from a raster layer turned into vectors by a rendering transformation."},{"location":"services/wms/reference/","title":"WMS reference","text":""},{"location":"services/wms/reference/#introduction","title":"Introduction","text":"

                                                                                        The OGC Web Map Service (WMS) specification defines an HTTP interface for requesting georeferenced map images from a server. GeoServer supports WMS 1.1.1, the most widely used version of WMS, as well as WMS 1.3.0.

                                                                                        The relevant OGC WMS specifications are:

                                                                                        • OGC Web Map Service Implementation Specification, Version 1.1.1
                                                                                        • OGC Web Map Service Implementation Specification, Version 1.3.0

                                                                                        GeoServer also supports some extensions to the WMS specification made by the Styled Layer Descriptor (SLD) standard to control the styling of the map output. These are defined in:

                                                                                        • OpenGIS Styled Layer Descriptor Profile of the Web Map Service Implementation Specification, Version 1.1.0
                                                                                        "},{"location":"services/wms/reference/#benefits-of-wms","title":"Benefits of WMS","text":"

                                                                                        WMS provides a standard interface for requesting a geospatial map image. The benefit of this is that WMS clients can request images from multiple WMS servers, and then combine them into a single view for the user. The standard guarantees that these images can all be overlaid on one another as they actually would be in reality. Numerous servers and clients support WMS.

                                                                                        "},{"location":"services/wms/reference/#operations","title":"Operations","text":"

                                                                                        WMS requests can perform the following operations:

                                                                                        Operation Description GetCapabilities Retrieves metadata about the service, including supported operations and parameters, and a list of the available layers GetMap Retrieves a map image for a specified area and content GetFeatureInfo Retrieves the underlying data, including geometry and attribute values, for a pixel location on a map DescribeLayer Indicates the WFS or WCS to retrieve additional information about the layer. GetLegendGraphic Retrieves a generated legend for a map"},{"location":"services/wms/reference/#wms_getcap","title":"GetCapabilities","text":"

                                                                                        The GetCapabilities operation requests metadata about the operations, services, and data (\"capabilities\") that are offered by a WMS server.

                                                                                        The parameters for the GetCapabilities operation are:

                                                                                        Parameter Required? Description service Yes Service name. Value is WMS. version Yes Service version. Value is one of 1.0.0, 1.1.0, 1.1.1, 1.3.0. request Yes Operation name. Value is GetCapabilities.

                                                                                        GeoServer provides the following vendor-specific parameters for the GetCapabilities operation. They are fully documented in the WMS vendor parameters section.

                                                                                        Parameter Required? Description namespace No limits response to layers in a given namespace format No request the capabilities document in a certain format rootLayer No Flag to enable/disable the standard Root top level Layer element. Values are true or false. When false, the Root element will be included only if there are multiple top level layers, if there is only one, it will be the root layer itself. When specified, will override the global WMS setting or layer / group setting for the same behaviour.

                                                                                        A example GetCapabilities request is: :

                                                                                        http://localhost:8080/geoserver/wms?\nservice=wms&\nversion=1.1.1&\nrequest=GetCapabilities\n

                                                                                        There are three parameters being passed to the WMS server, service=wms, version=1.1.1, and request=GetCapabilities. The service parameter tells the WMS server that a WMS request is forthcoming. The version parameter refers to which version of WMS is being requested. The request parameter specifies the GetCapabilities operation. The WMS standard requires that requests always includes these three parameters. GeoServer relaxes these requirements (by setting the default version if omitted), but for standard-compliance they should always be specified.

                                                                                        The response is a Capabilities XML document that is a detailed description of the WMS service. It contains three main sections:

                                                                                        Service Contains service metadata such as the service name, keywords, and contact information for the organization operating the server. Request Describes the operations the WMS service provides and the parameters and output formats for each operation. If desired GeoServer can be configured to disable support for certain WMS operations. Layer Lists the available coordinate systems and layers. In GeoServer layers are named in the form \"namespace:layer\". Each layer provides service metadata such as title, abstract and keywords."},{"location":"services/wms/reference/#wms_getmap","title":"GetMap","text":"

                                                                                        The GetMap operation requests that the server generate a map. The core parameters specify one or more layers and styles to appear on the map, a bounding box for the map extent, a target spatial reference system, and a width, height, and format for the output. The information needed to specify values for parameters such as layers, styles and srs can be obtained from the Capabilities document.

                                                                                        The response is a map image, or other map output artifact, depending on the format requested. GeoServer provides a wide variety of output formats, described in WMS output formats.

                                                                                        The standard parameters for the GetMap operation are:

                                                                                        Parameter Required? Description service Yes Service name. Value is WMS. version Yes Service version. Value is one of 1.0.0, 1.1.0, 1.1.1, 1.3.0. request Yes Operation name. Value is GetMap. layers Yes Layers to display on map. Value is a comma-separated list of layer names. styles Yes Styles in which layers are to be rendered. Value is a comma-separated list of style names, or empty if default styling is required. Style names may be empty in the list, to use default layer styling. srs or crs Yes Spatial Reference System for map output. Value is in form EPSG:nnn. crs is the parameter key used in WMS 1.3.0. bbox Yes Bounding box for map extent. Value is minx,miny,maxx,maxy in units of the SRS. width Yes Width of map output, in pixels. height Yes Height of map output, in pixels. format Yes Format for the map output. See WMS output formats for supported values. transparent No Whether the map background should be transparent. Values are true or false. Default is false bgcolor No Background color for the map image. Value is in the form RRGGBB. Default is FFFFFF (white). exceptions No Format in which to report exceptions. Default value is application/vnd.ogc.se_xml. time No Time value or range for map data. See Time Support in GeoServer WMS for more information. sld No A URL referencing a StyledLayerDescriptor XML file which controls or enhances map layers and styling sld_body No A URL-encoded StyledLayerDescriptor XML document which controls or enhances map layers and styling

                                                                                        GeoServer provides a number of useful vendor-specific parameters for the GetMap operation. These are documented in the WMS vendor parameters section.

                                                                                        Example WMS request for topp:states layer to be output as a PNG map image in SRS EPGS:4326 and using default styling is: :

                                                                                        http://localhost:8080/geoserver/wms?\nrequest=GetMap\n&service=WMS\n&version=1.1.1\n&layers=topp%3Astates\n&styles=population\n&srs=EPSG%3A4326\n&bbox=-145.15104058007,21.731919794922,-57.154894212888,58.961058642578&\n&width=780\n&height=330\n&format=image%2Fpng\n

                                                                                        The standard specifies many of the parameters as being mandatory, GeoServer provides the WMS Reflector to allow many of them to be optionally specified.

                                                                                        Experimenting with this feature is a good way to get to know the GetMap parameters.

                                                                                        Example WMS request using a GetMap XML document is:

                                                                                        <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<ogc:GetMap xmlns:ogc=\"http://www.opengis.net/ows\"\n            xmlns:gml=\"http://www.opengis.net/gml\"\n   version=\"1.1.1\" service=\"WMS\">\n   <StyledLayerDescriptor version=\"1.0.0\">\n      <NamedLayer>\n        <Name>topp:states</Name>\n        <NamedStyle><Name>population</Name></NamedStyle> \n      </NamedLayer> \n   </StyledLayerDescriptor>\n   <BoundingBox srsName=\"http://www.opengis.net/gml/srs/epsg.xml#4326\">\n      <gml:coord><gml:X>-130</gml:X><gml:Y>24</gml:Y></gml:coord>\n      <gml:coord><gml:X>-55</gml:X><gml:Y>50</gml:Y></gml:coord>\n   </BoundingBox>\n   <Output>\n      <Format>image/png</Format>\n      <Size><Width>550</Width><Height>250</Height></Size>\n   </Output>\n</ogc:GetMap>\n
                                                                                        "},{"location":"services/wms/reference/#time","title":"Time","text":"

                                                                                        As of GeoServer 2.2.0, GeoServer supports a TIME attribute for WMS GetMap requests as described in version 1.3.0 of the WMS specification. This parameter allows filtering a dataset by temporal slices as well as spatial tiles for rendering. See /services/wms/time for information on its use.

                                                                                        "},{"location":"services/wms/reference/#wms_getfeatureinfo","title":"GetFeatureInfo","text":"

                                                                                        The GetFeatureInfo operation requests the spatial and attribute data for the features at a given location on a map. It is similar to the WFS GetFeature operation, but less flexible in both input and output. Since GeoServer provides a WFS service we recommend using it instead of GetFeatureInfo whenever possible.

                                                                                        The one advantage of GetFeatureInfo is that the request uses an (x,y) pixel value from a returned WMS image. This is easier to use for a naive client that is not able to perform true geographic referencing.

                                                                                        The standard parameters for the GetFeatureInfo operation are:

                                                                                        Parameter Required? Description service Yes Service name. Value is WMS. version Yes Service version. Value is one of 1.0.0, 1.1.0, 1.1.1, 1.3.0. request Yes Operation name. Value is GetFeatureInfo. layers Yes See GetMap styles Yes See GetMap srs or crs Yes See GetMap bbox Yes See GetMap width Yes See GetMap height Yes See GetMap query_layers Yes Comma-separated list of one or more layers to query. info_format No Format for the feature information response. See below for values. feature_count No Maximum number of features to return. Default is 1. x or i Yes X ordinate of query point on map, in pixels. 0 is left side. i is the parameter key used in WMS 1.3.0. y or j Yes Y ordinate of query point on map, in pixels. 0 is the top. j is the parameter key used in WMS 1.3.0. exceptions No Format in which to report exceptions. The default value is application/vnd.ogc.se_xml.

                                                                                        Note: If you are sending a GetFeatureInfo request against a layergroup, all the layers in that layergroup must be set as \"Queryable\" to get a result (See WMS Settings on Layers page<data_webadmin_layers>)

                                                                                        GeoServer supports a number of output formats for the GetFeatureInfo response. Server-styled HTML is the most commonly-used format. For maximum control and customisation the client should use GML3 and style the raw data itself. The supported formats are:

                                                                                        Format Syntax Notes TEXT info_format=text/plain Simple text output. (The default format) GML 2 info_format=application/vnd.ogc.gml Works only for Simple Features (see app-schema.complex-features) GML 3 info_format=application/vnd.ogc.gml/3.1.1 Works for both Simple and Complex Features (see app-schema.complex-features) HTML info_format=text/html Uses HTML templates that are defined on the server. See HTML output format for information on how to template HTML output. JSON info_format=application/json Simple JSON representation. See GeoJSON output format for information on how to template JSON output. JSONP info_format=text/javascript Returns JSONP in the form: parseResponse(...json...). See WMS vendor parameters to change the callback name. Note that this format is disabled by default (See Global variables affecting WMS).

                                                                                        GeoServer provides the following vendor-specific parameters for the GetFeatureInfo operation. They are fully documented in the WMS vendor parameters section.

                                                                                        Parameter Required? Description buffer No width of search radius around query point (in pixels). cql_filter No Filter for returned data, in ECQL format filter No Filter for returned data, in OGC Filter format propertyName No Feature properties to be returned exclude_nodata_result No When set to true, a NaN will be returned when the feature's queried pixel value is nodata.

                                                                                        An example request for feature information from the topp:states layer in HTML format is: :

                                                                                        http://localhost:8080/geoserver/wms?\nrequest=GetFeatureInfo\n&service=WMS\n&version=1.1.1\n&layers=topp%3Astates\n&styles=\n&srs=EPSG%3A4326\n&format=image%2Fpng\n&bbox=-145.151041%2C21.73192%2C-57.154894%2C58.961059\n&width=780\n&height=330\n&query_layers=topp%3Astates\n&info_format=text%2Fhtml\n&feature_count=50\n&x=353\n&y=145\n&exceptions=application%2Fvnd.ogc.se_xml\n

                                                                                        An example request for feature information in GeoJSON format is: :

                                                                                        http://localhost:8080/geoserver/wms?\n&INFO_FORMAT=application/json\n&REQUEST=GetFeatureInfo\n&EXCEPTIONS=application/vnd.ogc.se_xml\n&SERVICE=WMS\n&VERSION=1.1.1\n&WIDTH=970&HEIGHT=485&X=486&Y=165&BBOX=-180,-90,180,90\n&LAYERS=COUNTRYPROFILES:grp_administrative_map\n&QUERY_LAYERS=COUNTRYPROFILES:grp_administrative_map\n&TYPENAME=COUNTRYPROFILES:grp_administrative_map\n

                                                                                        The result will be:

                                                                                        {\n\"type\":\"FeatureCollection\",\n\"features\":[\n   {\n      \"type\":\"Feature\",\n      \"id\":\"dt_gaul_geom.fid-138e3070879\",\n      \"geometry\":{\n         \"type\":\"MultiPolygon\",\n         \"coordinates\":[\n            [\n               [\n                  [\n                     XXXXXXXXXX,\n                     XXXXXXXXXX\n                  ],\n                  ...\n                  [\n                     XXXXXXXXXX,\n                     XXXXXXXXXX\n                  ]\n               ]\n            ]\n         ]\n      },\n      \"geometry_name\":\"at_geom\",\n      \"properties\":{\n         \"bk_gaul\":X,\n         \"at_admlevel\":0,\n         \"at_iso3\":\"XXX\",\n         \"ia_name\":\"XXXX\",\n         \"at_gaul_l0\":X,\n         \"bbox\":[\n            XXXX,\n            XXXX,\n            XXXX,\n            XXXX\n         ]\n      }\n   }\n],\n\"crs\":{\n   \"type\":\"EPSG\",\n   \"properties\":{\n      \"code\":\"4326\"\n   }\n},\n\"bbox\":[\n   XXXX,\n   XXXX,\n   XXXX,\n   XXXX\n]\n}\n
                                                                                        "},{"location":"services/wms/reference/#wms_describelayer","title":"DescribeLayer","text":"

                                                                                        The DescribeLayer operation is used primarily by clients that understand SLD-based WMS. In order to make an SLD one needs to know the structure of the data. WMS and WFS both have operations to do this, so the DescribeLayer operation just routes the client to the appropriate service.

                                                                                        The standard parameters for the DescribeLayer operation are:

                                                                                        Parameter Required? Description service Yes Service name. Value is WMS. version Yes Service version. Value is 1.1.1. request Yes Operation name. Value is DescribeLayer. layers Yes See GetMap exceptions No Format in which to report exceptions. The default value is application/vnd.ogc.se_xml.

                                                                                        GeoServer supports a number of output formats for the DescribeLayer response. Server-styled HTML is the most commonly-used format. The supported formats are:

                                                                                        Format Syntax Notes TEXT output_format=text/xml Same as default. GML 2 output_format=application/vnd.ogc.wms_xml The default format. JSON output_format=application/json Simple JSON representation. JSONP output_format=text/javascript Return JSONP in the form: paddingOutput(...jsonp...). See WMS vendor parameters to change the callback name. Note that this format is disabled by default (See Global variables affecting WMS).

                                                                                        An example request in XML (default) format on a layer is: :

                                                                                        http://localhost:8080/geoserver/topp/wms?service=WMS &version=1.1.1 &request=DescribeLayer &layers=topp:coverage

                                                                                        <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<!DOCTYPE WMS_DescribeLayerResponse SYSTEM \"http://localhost:8080/geoserver/schemas/wms/1.1.1/WMS_DescribeLayerResponse.dtd\">\n<WMS_DescribeLayerResponse version=\"1.1.1\">\n   <LayerDescription name=\"topp:coverage\" owsURL=\"http://localhost:8080/geoserver/topp/wcs?\" owsType=\"WCS\">\n      <Query typeName=\"topp:coverage\"/>\n   </LayerDescription>\n</WMS_DescribeLayerResponse>\n

                                                                                        An example request for feature description in JSON format on a layer group is: :

                                                                                        http://localhost:8080/geoserver/wms?service=WMS\n&version=1.1.1\n&request=DescribeLayer\n&layers=sf:roads,topp:tasmania_roads,nurc:mosaic\n&outputFormat=application/json\n

                                                                                        The result will be: :

                                                                                        {\n  version: \"1.1.1\",\n  layerDescriptions: [\n    {\n        layerName: \"sf:roads\",\n        owsURL: \"http://localhost:8080/geoserver/wfs/WfsDispatcher?\",\n        owsType: \"WFS\",\n        typeName: \"sf:roads\"\n    },\n    {\n        layerName: \"topp:tasmania_roads\",\n        owsURL: \"http://localhost:8080/geoserver/wfs/WfsDispatcher?\",\n        owsType: \"WFS\",\n        typeName: \"topp:tasmania_roads\"\n    },\n    {\n        layerName: \"nurc:mosaic\",\n        owsURL: \"http://localhost:8080/geoserver/wcs?\",\n        owsType: \"WCS\",\n        typeName: \"nurc:mosaic\"\n    }\n  ]\n
                                                                                        "},{"location":"services/wms/reference/#wms_getlegendgraphic","title":"GetLegendGraphic","text":"

                                                                                        The GetLegendGraphic operation provides a mechanism for generating legend graphics as images, beyond the LegendURL reference of WMS Capabilities. It generates a legend based on the style defined on the server, or alternatively based on a user-supplied SLD. For more information on this operation and the various options that GeoServer supports see GetLegendGraphic.

                                                                                        "},{"location":"services/wms/reference/#exceptions","title":"Exceptions","text":"

                                                                                        Formats in which WMS can report exceptions. The supported values for exceptions are:

                                                                                        Format Syntax Notes XML EXCEPTIONS=application/vnd.ogc.se_xml XML output. (The default format) INIMAGE EXCEPTIONS=application/vnd.ogc.se_inimage Generates an image BLANK EXCEPTIONS=application/vnd.ogc.se_blank Generates a blank image PARTIALMAP EXCEPTIONS=application/vnd.gs.wms_partial This is a GeoServer vendor parameter and only applicable for GetMap requests. Returns everything that was rendered at the time the rendering process threw an exception. Can be used with the WMS Configuration Limits to return a partial image even if the request is terminated for exceeding one of these limits. It also works with the timeout vendor parameter. JSON EXCEPTIONS=application/json Simple JSON representation. JSONP EXCEPTIONS=text/javascript Return JSONP in the form: paddingOutput(...jsonp...). See WMS vendor parameters to change the callback name. Note that this format is disabled by default (See Global variables affecting WMS)."},{"location":"services/wms/time/","title":"Time Support in GeoServer WMS","text":"

                                                                                        GeoServer supports a TIME attribute in GetMap requests for layers that are properly configured with a time dimension. This is used to specify a temporal subset for rendering.

                                                                                        For example, you might have a single dataset with weather observations collected over time and choose to plot a single day's worth of observations.

                                                                                        The attribute to be used in TIME requests can be set up through the GeoServer web interface by navigating to Layers -> [specific layer] -> Dimensions tab.

                                                                                        Note

                                                                                        Read more about how to use the web interface to configure an attribute for TIME requests.

                                                                                        "},{"location":"services/wms/time/#specifying-a-time","title":"Specifying a time","text":"

                                                                                        The format used for specifying a time in the WMS TIME parameter is based on ISO-8601. Times may be specified up to a precision of 1 millisecond; GeoServer does not represent time queries with more precision than this.

                                                                                        The parameter is:

                                                                                        TIME=<timestring>\n

                                                                                        Times follow the general format:

                                                                                        yyyy-MM-ddThh:mm:ss.SSSZ\n

                                                                                        where:

                                                                                        • yyyy: 4-digit year
                                                                                        • MM: 2-digit month
                                                                                        • dd: 2-digit day
                                                                                        • hh: 2-digit hour
                                                                                        • mm: 2-digit minute
                                                                                        • ss: 2-digit second
                                                                                        • SSS: 3-digit millisecond

                                                                                        The day and intraday values are separated with a capital T, and the entire thing is suffixed with a Z, indicating UTC for the time zone. (The WMS specification does not provide for other time zones.)

                                                                                        GeoServer will apply the TIME value to all temporally enabled layers in the LAYERS parameter of the GetMap request. Layers without a temporal component will be served normally, allowing clients to include reference information like political boundaries along with temporal data.

                                                                                        Description Time specification December 12, 2001 at 6:00 PM 2001-12-12T18:00:00.0Z May 5, 1993 at 11:34 PM 1993-05-05T11:34:00.0Z"},{"location":"services/wms/time/#specifying-an-absolute-interval","title":"Specifying an absolute interval","text":"

                                                                                        A client may request information over a continuous interval instead of a single instant by specifying a start and end time, separated by a / character.

                                                                                        In this scenario the start and end are inclusive; that is, samples from exactly the endpoints of the specified range will be included in the rendered tile.

                                                                                        Description Time specification The month of September 2002 2002-09-01T00:00:00.0Z/2002-09-30T23:59:59.999Z The entire day of December 25, 2010 2010-12-25T00:00:00.0Z/2010-12-25T23:59:59.999Z"},{"location":"services/wms/time/#specifying-a-relative-interval","title":"Specifying a relative interval","text":"

                                                                                        A client may request information over a relative time interval instead of a set time range by specifying a start or end time with an associated duration, separated by a / character.

                                                                                        One end of the interval must be a time value, but the other may be a duration value as defined by the ISO 8601 standard. The special keyword PRESENT may be used to specify a time relative to the present server time.

                                                                                        Description Time specification The month of September 2002 2002-09-01T00:00:00.0Z/P1M The entire day of December 25, 2010 2010-12-25T00:00:00.0Z/P1D The entire day preceding December 25, 2010 P1D/2010-12-25T00:00:00.0Z 36 hours preceding the current time PT36H/PRESENT

                                                                                        Note

                                                                                        The final example could be paired with the KML service to provide a Google Earth network link which is always updated with the last 36 hours of data.

                                                                                        "},{"location":"services/wms/time/#reduced-accuracy-times","title":"Reduced accuracy times","text":"

                                                                                        The WMS specification also allows time specifications to be truncated by omitting some of the time string. In this case, GeoServer treats the time as a range whose length is equal to the most precise unit specified in the time string.

                                                                                        For example, if the time specification omits all fields except year, it identifies a range one year long starting at the beginning of that year.

                                                                                        Note

                                                                                        GeoServer implements this by adding the appropriate unit, then subtracting 1 millisecond. This avoids surprising results when using an interval that aligns with the actual sampling frequency of the data - for example, if yearly data is natively stored with dates like 2001-01-01T00:00:00.0Z, 2002-01-01T00:00:00Z, etc. then a request for 2001 would include the samples for both 2001 and 2002, which wouldn't be desired.

                                                                                        Description Reduced Accuracy Time Equivalent Range The month of September 2002 2002-09 2002-09-01T00:00:00.0Z/2002-09-30T23:59:59.999Z The day of December 25, 2010 2010-12-25 2010-12-25T00:00:00.0Z/2010-12-25T23:59:59.999Z"},{"location":"services/wms/time/#reduced-accuracy-times-with-ranges","title":"Reduced accuracy times with ranges","text":"

                                                                                        Reduced accuracy times are also allowed when specifying ranges. In this case, GeoServer effectively expands the start and end times as described above, and then includes any samples from after the beginning of the start interval and before the end of the end interval.

                                                                                        Note

                                                                                        Again, the ranges are inclusive.

                                                                                        Description Reduced Accuracy Time Equivalent Range The months of September through December 2002 2002-09/2002-12 2002-09-01T00:00:00.0Z/2002-12-31T23:59:59.999Z 12PM through 6PM, December 25, 2010 2010-12-25T12/2010-12-25T18 2010-12-25T12:00:00.0Z/2010-12-25T18:59:59.999Z

                                                                                        Note

                                                                                        In the last example, note that the result may not be intuitive, as it includes all times from 6PM to 6:59PM.

                                                                                        "},{"location":"services/wms/time/#specifying-a-list-of-times","title":"Specifying a list of times","text":"

                                                                                        GeoServer can also accept a list of discrete time values. This is useful for some applications such as animations, where one time is equal to one frame.

                                                                                        The elements of a list are separated by commas.

                                                                                        Note

                                                                                        GeoServer currently does not support lists of ranges, so all list queries effectively have a resolution of 1 millisecond. If you use reduced accuracy notation when specifying a range, each range will be automatically converted to the instant at the beginning of the range.

                                                                                        If the list is evenly spaced (for example, daily or hourly samples) then the list may be specified as a range, using a start time, end time, and period separated by slashes.

                                                                                        Description List notation Equivalent range notation Noon every day for August 12-14, 2012 TIME=2012-08-12T12:00:00.0Z,2012-08-13T12:00:00.0Z,2012-08-14T12:00:00.0Z TIME=2012-08-12T12:00:00.0Z/2012-08-18:T12:00:00.0Z/P1D Midnight on the first of September, October, and November 1999 TIME=1999-09-01T00:00:00.0Z,1999-10-01T00:00:00.0Z,1999-11-01T00:00:00.0Z TIME=1999-09-01T00:00:00.0Z/1999-11-01T00:00:00.0Z/P1M"},{"location":"services/wms/time/#specifying-a-periodicity","title":"Specifying a periodicity","text":"

                                                                                        The periodicity is also specified in ISO-8601 format: a capital P followed by one or more interval lengths, each consisting of a number and a letter identifying a time unit:

                                                                                        Unit Abbreviation Years Y Months M Days D Hours H Minutes M Seconds S

                                                                                        The Year/Month/Day group of values must be separated from the Hours/Minutes/Seconds group by a T character. The T itself may be omitted if hours, minutes, and seconds are all omitted. Additionally, fields which contain a 0 may be omitted entirely.

                                                                                        Fractional values are permitted, but only for the most specific value that is included.

                                                                                        Note

                                                                                        The period must divide evenly into the interval defined by the start/end times. So if the start/end times denote 12 hours, a period of 1 hour would be allowed, but a period of 5 hours would not.

                                                                                        For example, the multiple representations listed below are all equivalent.

                                                                                        • One hour:

                                                                                          P0Y0M0DT1H0M0S\n\nPT1H0M0S\n\nPT1H\n
                                                                                        • 90 minutes:

                                                                                          P0Y0M0DT1H30M0S\n\nPT1H30M\n\nP90M\n
                                                                                        • 18 months:

                                                                                          P1Y6M0DT0H0M0S\n\nP1Y6M0D\n\nP0Y18M0DT0H0M0S\n\nP18M\n

                                                                                          Note

                                                                                          P1.25Y3M would not be acceptable, because fractional values are only permitted in the most specific value given, which in this case would be months.

                                                                                        "},{"location":"services/wms/vendor/","title":"WMS vendor parameters","text":"

                                                                                        WMS vendor parameters are non-standard request parameters that are defined by an implementation to provide enhanced capabilities. GeoServer supports a variety of vendor-specific parameters.

                                                                                        "},{"location":"services/wms/vendor/#general-vendor-options","title":"General Vendor Options","text":"

                                                                                        These vendor options are available for all operations.

                                                                                        content-disposition ^^^^^^^^^^^^^^^^^^^

                                                                                        The content-disposition parameter directs how a web browser directed to handle returned content. The syntax is::

                                                                                        content-disposition=

                                                                                        Where content-disposition =attachment to direct the browser to save the content to disk.

                                                                                        Where content-disposition=inline asks the browser to display the content. Note this may present performance issues when asked to display very large content.

                                                                                        filename ^^^^^^^^

                                                                                        The filename parameter provides a suggested filename when a browser saves a file (e.g. to Downloads folder). The syntax is::

                                                                                        filename=

                                                                                        An example of filename use is::

                                                                                        filename=features.json

                                                                                        When service output is saved as a file, the vendor-option filename is used to provide the file name used.

                                                                                        "},{"location":"services/wms/vendor/#getcapabilities-request","title":"GetCapabilities Request","text":""},{"location":"services/wms/vendor/#format","title":"format","text":"

                                                                                        The format parameter can be used to request capabilities documents in a certain format. If the requested format is not supported the default format will be used. Refer to the GetCapabilities response for the list of supported formats, which differs according to the WMS version.

                                                                                        An example request:

                                                                                        http://localhost:8080/geoserver/ows?service=wms&version=1.1.1&request=GetCapabilities&format=text/xml

                                                                                        <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<WMT_MS_Capabilities version=\"1.1.1\" updateSequence=\"247\">\n <Capability>\n     <Request>\n         <GetCapabilities>\n             <Format>application/vnd.ogc.wms_xml</Format>\n             <Format>text/xml</Format>\n...\n

                                                                                        Note

                                                                                        Currently this parameter can only be used to request WMS 1.1.1 capabilities documents encoded in text/xml, if used with other WMS versions or other formats it will have no effect. application/json is not supported.

                                                                                        "},{"location":"services/wms/vendor/#namespace","title":"namespace","text":"

                                                                                        The namespace parameter causes WMS GetCapabilities responses to be filtered to only contain layers in a particular namespace. The syntax is:

                                                                                        namespace=<namespace>\n

                                                                                        where <namespace> is the namespace prefix.

                                                                                        Warning

                                                                                        Using an invalid namespace prefix will not cause an error, but the capabilities document returned will contain no layers, only layer groups.

                                                                                        Note

                                                                                        This affects the capabilities document only, not other requests. Other WMS operations will still process all layers, even when a namespace is specified.

                                                                                        "},{"location":"services/wms/vendor/#rootlayer","title":"rootLayer","text":"

                                                                                        The rootLayer parameter can be used to request capabilities documents to include or not a top level root Layer container. By default this top level root is always included as a parent of the configured layers and groups. The default can be changed at the service (WMS) level, or at the layer / group level.

                                                                                        Using this parameter it is possible to exclude the default root when the resulting document has a single top element (e.g. a single group with nested children). To do that, use the false value.

                                                                                        The parameter can also be used to override what is defined at the WMS or layer / group level. For example if the service is configure to exclude the Root element, we can force it with rootLayer=true.

                                                                                        An example request:

                                                                                        http://localhost:8080/geoserver/ows?service=wms&version=1.1.1&request=GetCapabilities&rootLayer=false

                                                                                        An example with XML POST:

                                                                                        <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<ogc:GetCapabilities xmlns:ogc=\"http://www.opengis.net/ows\"\n            xmlns:gml=\"http://www.opengis.net/gml\"\n   version=\"1.1.1\" service=\"WMS\" rootLayer=\"false\">\n</ogc:GetCapabilities>\n
                                                                                        "},{"location":"services/wms/vendor/#getmap-request","title":"GetMap Request","text":""},{"location":"services/wms/vendor/#angle","title":"angle","text":"

                                                                                        The angle parameter rotates the output map clockwise around its center. The syntax is:

                                                                                        angle=<x>\n

                                                                                        where <x> is the number of degrees to rotate by.

                                                                                        Map rotation is supported in all raster formats, PDF, and SVG when using the Batik producer (which is the default).

                                                                                        "},{"location":"services/wms/vendor/#buffer","title":"buffer","text":"

                                                                                        The buffer parameter specifies the number of additional border pixels that are used in the GetMap and GetFeatureInfo operations. The syntax is:

                                                                                        buffer=<bufferwidth>\n

                                                                                        where <bufferwidth> is the width of the buffer in pixels.

                                                                                        In the GetMap operation, buffering includes features that lie outside the request bounding box, but whose styling is thick enough to be visible inside the map area.

                                                                                        In the GetFeatureInfo operation, buffering creates a \"search radius\" around the location of the request. Feature info is returned for features intersecting the search area. This is useful when working with an OpenLayers map (such as those generated by the Layer Preview page) since it relaxes the need to click precisely on a point for the appropriate feature info to be returned.

                                                                                        In both operations GeoServer attempts to compute the buffer value automatically by inspecting the styles for each layer. All active symbolizers are evaluated, and the size of the largest is used (i.e. largest point symbolizer, thickest line symbolizer). Automatic buffer sizing cannot be computed if:

                                                                                        • the SLD contains sizes that are specified as feature attribute values
                                                                                        • the SLD contains external graphics and does not specify their size explicitly

                                                                                        In this event, the following defaults are used:

                                                                                        • 0 pixels for GetMap requests
                                                                                        • 5 pixels for GetFeatureInfo requests (a different min value can be set via the org.geoserver.wms.featureinfo.minBuffer system variable, e.g., add -Dorg.geoserver.wms.featureinfo.minBuffer=10 to make the min buffer be 10 pixels)

                                                                                        If these are not sufficiently large, the explicit parameter can be used.

                                                                                        "},{"location":"services/wms/vendor/#cql_filter","title":"cql_filter","text":"

                                                                                        The cql_filter parameter is similar to the standard filter parameter, but the filter is expressed using ECQL (Extended Common Query Language). ECQL provides a more compact and readable syntax compared to OGC XML filters. For full details see the ECQL Reference and CQL and ECQL tutorial.

                                                                                        If more than one layer is specified in the layers parameter, then a separate filter can be specified for each layer, separated by semicolons. The syntax is:

                                                                                        cql_filter=filter1;filter2...\n

                                                                                        An example of a simple CQL filter is:

                                                                                        cql_filter=INTERSECTS(the_geom,%20POINT%20(-74.817265%2040.5296504))\n
                                                                                        "},{"location":"services/wms/vendor/#sortby","title":"sortBy","text":"

                                                                                        The sortBy parameter allows to control the order of features/rasters displayed in the map, using the same syntax as WFS 1.0, that is:

                                                                                        • &sortBy=att1 A|D,att2 A|D, ... for a single layer request
                                                                                        • &sortBy=(att1Layer1 A|D,att2Layer1 A|D, ...)(att1Layer2 A|D,att2Layer2 A|D, ...)... when requesting multiple layers

                                                                                        Care should be taken when using it as it has different behavior for raster layers, vector layers, and layer groups. In particular:

                                                                                        • | For raster layers, sortBy maps to a \"SORTING\" read parameter that the reader might expose (image mosaic exposes such parameter). | In image mosaic, this causes the first granule found in the sorting will display on top, and then the others will follow. | Thus, to sort a scattered mosaic of satellite images so that the most recent image shows on top, and assuming the time attribute is called ingestion in the mosaic index, the specification will be &sortBy=ingestion D.

                                                                                        • | For vector layers, sortBy maps to a sort by clause in the vector data source, and then painting happens using the normal \"painter model\" rules, so the first item returned is painted first, and then all others on top of it. | Thus, to sort a set of event points so that the most recent event is painted on top, and assuming the attribute is called \"date\" in the vector layer, the specification will be &sortBy=date or &sortBy=date A (ascending direction being the default one).

                                                                                        • | For layer groups, the sort specification is going to be copied over all internal layers, so the spec has to be valid for all of them, or an error will be reported. | An empty spec can be used for layer groups in this case, for example, layers=theGroup,theLayer&sortBy=(),(date A)

                                                                                        "},{"location":"services/wms/vendor/#env","title":"env","text":"

                                                                                        The env parameter defines the set of substitution values that can be used in SLD variable substitution. The syntax is:

                                                                                        env=param1:value1;param2:value2;...\n

                                                                                        See Variable substitution in SLD for more information.

                                                                                        "},{"location":"services/wms/vendor/#featureid","title":"featureid","text":"

                                                                                        The featureid parameter filters by feature ID, a unique value given to all features. Multiple features can be selected by separating the featureids by comma, as in this example:

                                                                                        featureid=states.1,states.45\n
                                                                                        "},{"location":"services/wms/vendor/#filter","title":"filter","text":"

                                                                                        The WMS specification allows only limited filtering of data. GeoServer enhances the WMS filter capability to match that provided by WFS. The filter parameter can specify a list of OGC XML filters. The list is enclosed in parentheses: ( ). When used in a GET request, the XML tag brackets must be URL-encoded.

                                                                                        If more than one layer is specified in the layers parameter then a separate filter can be specified for each layer.

                                                                                        An example of an OGC filter encoded in a GET request is:

                                                                                        filter=%3CFilter%20xmlns:gml=%22http://www.opengis.net/gml%22%3E%3CIntersects%3E%3CPropertyName%3Ethe_geom%3C/PropertyName%3E%3Cgml:Point%20srsName=%224326%22%3E%3Cgml:coordinates%3E-74.817265,40.5296504%3C/gml:coordinates%3E%3C/gml:Point%3E%3C/Intersects%3E%3C/Filter%3E\n

                                                                                        An example of an OGC filter encoding standard 2.0 in a GET request is:

                                                                                        filter=%3Cfes%3AFilter%20xmlns%3Axsi%3D%22http%3A%2F%2Fwww.w3.org%2F2001%2FXMLSchema-instance%22%20xmlns%3Agml%3D%22http%3A%2F%2Fwww.opengis.net%2Fgml%2F3.2%22%20xmlns%3Awfs%3D%22http%3A%2F%2Fwww.opengis.net%2Fwfs%22%20xmlns%3D%22http%3A%2F%2Fwww.opengis.net%2Ffes%2F2.0%22%20xmlns%3Afes%3D%22http%3A%2F%2Fwww.opengis.net%2Ffes%2F2.0%22%3E%3Cfes%3APropertyIsLike%20wildCard%3D%22*%22%20singleChar%3D%22.%22%20escapeChar%3D%22!%22%3E%3Cfes%3AValueReference%3ENAME%3C%2Ffes%3AValueReference%3E%3Cfes%3ALiteral%3E*United*%3C%2Ffes%3ALiteral%3E%3C%2Ffes%3APropertyIsLike%3E%3C%2Ffes%3AFilter%3E\n

                                                                                        An example of an OGC filter encoding standard 2.0 :

                                                                                        <fes:Filter xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xmlns:gml=\"http://www.opengis.net/gml/3.2\" xmlns:wfs=\"http://www.opengis.net/wfs\" xmlns=\"http://www.opengis.net/fes/2.0\" xmlns:fes=\"http://www.opengis.net/fes/2.0\"><fes:PropertyIsLike wildCard=\"*\" singleChar=\".\" escapeChar=\"!\"><fes:ValueReference>NAME</fes:ValueReference><fes:Literal>*United*</fes:Literal></fes:PropertyIsLike></fes:Filter>\n
                                                                                        "},{"location":"services/wms/vendor/#format_options","title":"format_options","text":"

                                                                                        The format_options is a container for parameters that are format-specific. The syntax is:

                                                                                        format_options=param1:value1;param2:value2;...\n

                                                                                        The supported format options are:

                                                                                        • antialias (values = on, off, text): controls the use of antialiased rendering in raster output.
                                                                                        • callback: specifies the callback function name for the jsonp response format (default is parseResponse).
                                                                                        • dpi: sets the rendering DPI (dots-per-inch) for raster outputs. The OGC standard output resolution is 90 DPI. If you need to create high resolution images (e.g for printing) it is advisable to request a larger image size and specify a higher DPI. In general, the image size should be increased by a factor equal to targetDPI/90, with the target dpi set in the format options. For example, to print a 100x100 image at 300 DPI request a 333x333 image with the DPI value set to 300: &width=333&height=333&format_options=dpi:300
                                                                                        • layout: specifies a layout name to use. Layouts are used to add decorators such as compasses and legends. This capability is discussed further in the WMS Decorations section.
                                                                                        • quantizer (values = octree, mediancut): controls the color quantizer used to produce PNG8 images. GeoServer 2.2.0 provides two quantizers, a fast RGB quantizer called octree that does not handle translucency and a slower but more accurate RGBA quantizer called mediancut. By default the first is used on opaque images, whilst the second is enabled if the client asks for a transparent image (transparent=true). This vendor parameter can be used to manually force the usage of a particular quantizer.
                                                                                        • timeout: Apply a timeout value for a getMap request. If the timeout is reached, the getMap request is cancelled and an error is returned. The value used for the timeout will be the minimum of this format option and the global WMS timeout defined in the WMS configuration. A value of zero means no timeout.
                                                                                        • kmattr (values = true, false): determines whether the KML returned by GeoServer should include clickable attributes or not. This parameter primarily affects Google Earth rendering.
                                                                                        • legend (values = true, false): KML may add the legend.
                                                                                        • kmscore (values = between 0 to force raster output and 100 to force vector output): parameter sets whether GeoServer should render KML data as vector or raster. This parameter primarily affects Google Earth rendering.
                                                                                        • kmltitle: parameter sets the KML title.
                                                                                        • kmlrefresh (values = greater than 0 or expires): Force Network Link reload in refresh mode on interval of seconds. When expires is specified client will refresh whenever the time has elapsed specified in cache expiration headers. The caching time may be set in the Layer configuration under Publishing tab setting HTTP Cache Time. This parameter primarily affects Google Earth rendering and is dependent on being respected by the client. Using a second interval is a more reliable choice.
                                                                                        • kmlvisible (values = true, false): Indicates whether layers selected will default to enabled or not. Default behavior is enabled. This parameter primarily affects Google Earth rendering.
                                                                                        • advancedProjectionHandling (values = true, false): Enable Disable advanced projection handling, if it is enabled in the GUI. If it is disabled in the GUI, this option has no effect.
                                                                                        • mapWrapping (values = true, false): Enable Disable continuous map wrapping, if it is enabled in the GUI. If it is disabled in the GUI, this option has no effect. Continuous map wrapping will also be disabled if advancedProjectionHandling is disabled.
                                                                                        • decorationsOnly (values = true, false): Disabled by default. When value is true, it allows to get a transparent sized image for the request on which maps are not rendered, but it keeps the decorations applied (if present).
                                                                                        "},{"location":"services/wms/vendor/#maxfeatures-and-startindex","title":"maxFeatures and startIndex","text":"

                                                                                        The parameters maxFeatures and startIndex can be used together to provide \"paging\" support. Paging is helpful in situations such as KML crawling, where it is desirable to be able to retrieve the map in sections when there are a large number of features.

                                                                                        The startindex=n parameter specifies the index from which to start rendering in an ordered list of features. n must be a positive integer.

                                                                                        The maxfeatures=n parameter sets a limit on the amount of features rendered. n must be a positive integer. When used with startindex, the features rendered will be the ones starting at the startindex value.

                                                                                        Note that not all layers support paging. For a layer to be queried in this way, the underlying feature source must support paging. This is usually the case for databases (such as PostGIS).

                                                                                        "},{"location":"services/wms/vendor/#palette","title":"palette","text":"

                                                                                        It is sometimes advisable (for speed and bandwidth reasons) to downsample the bit depth of returned maps. The way to do this is to create an image with a limited color palette, and save it in the palettes directory inside your GeoServer Data Directory. It is then possible to specify the palette parameter of the form:

                                                                                        palette=<image>\n

                                                                                        where <image> is the filename of the palette image (without the extension). To force a web-safe palette, use the syntax palette=safe. For more information see the tutorial on Paletted Images

                                                                                        "},{"location":"services/wms/vendor/#propertyname","title":"propertyName","text":"

                                                                                        The propertyName parameter specifies which properties are included in the response of the GetFeatureInfo operation. The syntax is the same as in the WFS GetFeature operation. For a request for a single layer the syntax is:

                                                                                        propertyName=name1,...,nameN\n

                                                                                        For multiple layers the syntax is:

                                                                                        propertyName=(nameLayer11,...,nameLayer1N)...(name1LayerN,...,nameNLayerN)\n

                                                                                        The nature of the properties depends on the layer type:

                                                                                        • For vector layers the names specify the feature attributes.
                                                                                        • For raster layers the names specify the bands.
                                                                                        • For cascaded WMS layers the names specify the GML properties to be returned by the remote server.
                                                                                        "},{"location":"services/wms/vendor/#tiled","title":"tiled","text":"

                                                                                        Meta-tiling prevents issues with duplicated labels when using a tiled client such as OpenLayers. When meta-tiling is used, images are rendered and then split into smaller tiles (by default in a 3x3 pattern) before being served. In order for meta-tiling to work, the tile size must be set to 256x256 pixels, and the tiled and tilesorigin parameters must be specified.

                                                                                        The tiled parameter controls whether meta-tiling is used. The syntax is:

                                                                                        tiled=[true|false]\n

                                                                                        To invoke meta-tiling use tiled=true.

                                                                                        "},{"location":"services/wms/vendor/#tilesorigin","title":"tilesorigin","text":"

                                                                                        The tilesorigin parameter is also required for meta-tiling. The syntax is:

                                                                                        tilesorigin=x,y\n

                                                                                        where x and y are the coordinates of the lower left corner (the \"origin\") of the tile grid system.

                                                                                        "},{"location":"services/wms/vendor/#openlayers-example","title":"OpenLayers example","text":"

                                                                                        In OpenLayers, a good way to specify the tilesorigin is to reference the map extents directly.

                                                                                        Warning

                                                                                        If the map extents are modified dynamically, the tilesorigin of each meta-tiled layer must be updated accordingly.

                                                                                        The following code shows how to specify the meta-tiling parameters:

                                                                                        var options = {\n    ...\n    maxExtent: new OpenLayers.Bounds(-180, -90, 180, 90),\n    ...\n};\nmap = new OpenLayers.Map('map', options);\n\ntiled = new OpenLayers.Layer.WMS(\n    \"Layer name\", \"http://localhost:8080/geoserver/wms\",\n    {\n        srs: 'EPSG:4326',\n        width: 391,\n        styles: '',\n        height: 550,\n        layers: 'layerName',\n        format: 'image/png',\n        tiled: true,\n        tilesorigin: map.maxExtent.left + ',' + map.maxExtent.bottom\n    },\n    {buffer: 0} \n);\n
                                                                                        "},{"location":"services/wms/vendor/#scalemethod","title":"scaleMethod","text":"

                                                                                        The scaleMethod parameter controls how the scale denominator is computed by GeoServer The two possible values are:

                                                                                        • OGC (default): the scale denominator is computed according to the OGC SLD specification, which

                                                                                          imposes simplified formulas for the sake of interoperability

                                                                                        • Accurate: use the full expressions for computing the scale denominator against geographic

                                                                                          data, taking into account the ellipsoidal shape of Earth

                                                                                        The two methods tend to return values rather close to each other near the equator, but they do diverge to larger differences as the latitude approaches the poles.

                                                                                        "},{"location":"services/wms/vendor/#wms_vendor_parameter_interpolations","title":"interpolations","text":"

                                                                                        The interpolations parameter allows choosing a specific resampling (interpolation) method. It can be used in the GetMap operation.

                                                                                        If more than one layer is specified in the layers parameter, then a separate interpolation method can be specified for each layer, separated by commas. The syntax is:

                                                                                        interpolations=method1,method2,...\n

                                                                                        method values can be one of the following:

                                                                                        • nearest neighbor
                                                                                        • bilinear
                                                                                        • bicubic

                                                                                        or empty if the default method has to be used for the related layer.

                                                                                        The parameter allows to override the global WMS Raster Rendering Options setting (see WMS Settings for more info), as well as the layer specific Default Interpolation Method publishing parameter (see Layers for more info), on a layer by layer basis.

                                                                                        "},{"location":"services/wms/vendor/#clip","title":"clip","text":"

                                                                                        The clip parameter can be used to clip WMS response using a Polygon mask represented by a valid WKT String.

                                                                                        Here are two examples, the first one using WKT, the second using EWKT:

                                                                                        clip=POLYGON((-14.50804652396198 55.579454354599356,34.53492222603802 55.579454354599356,34.53492222603802 32.400173313532584,-14.50804652396198 32.400173313532584,-14.50804652396198 55.579454354599356))\nclip=srid=900913;POLYGON ((-1615028.3514525702 7475148.401208023, 3844409.956787858 7475148.401208023, 3844409.956787858 3815954.983140064, -1615028.3514525702 3815954.983140064, -1615028.3514525702 7475148.401208023))\n

                                                                                        Note

                                                                                        The Axis order of WKT must be East/North regardless of WMS version. Currently this parameter is ignored for layers with Complex features.

                                                                                        "},{"location":"services/wms/webadmin/","title":"WMS settings","text":"

                                                                                        This page details the configuration options for WMS in the web administration interface.

                                                                                        WMS configuration options

                                                                                        "},{"location":"services/wms/webadmin/#workspace","title":"Workspace","text":"

                                                                                        Select workspace empty to configure global WMS settings.

                                                                                        See section on Workspace Services to override settings used by WMS Virtual Services.

                                                                                        "},{"location":"services/wms/webadmin/#service-metadata","title":"Service Metadata","text":"

                                                                                        For a description of WMS services, see the section on Service Metadata.

                                                                                        "},{"location":"services/wms/webadmin/#services_webadmin_wms_raster_options","title":"Root Layer Information","text":"

                                                                                        In this section is possible to define a title and an abstract for the root layer in the WMS capabilities. When these are left empty the WMS service title and abstract are used.

                                                                                        It is also possible to set the flag Always include Root Layer in capabilities. This is checked by default, but can be unset so that the root layer is included in capabilities only when there is NOT already a single top level Layer element. This can be useful to allow compatibility with some WMS clients that are not happy with the two or more layer tree levels. This default setting can be overridden at the layer or request level.

                                                                                        "},{"location":"services/wms/webadmin/#raster-rendering-options","title":"Raster Rendering Options","text":"

                                                                                        The Web Map Service Interface Standard (WMS) provides a simple way to request and serve geo-registered map images. During pan and zoom operations, WMS requests generate map images through a variety of raster rendering processes. Such image manipulation is generally called resampling, interpolation, or down-sampling. GeoServer supports three resampling methods that determine how cell values of a raster are outputted. These sampling methods-Nearest Neighbor, Bilinear Interpolation and Bicubic-are available on the Default Interpolation menu.

                                                                                        Nearest Neighbor -Uses the center of nearest input cell to determine the value of the output cell. Original values are retained and no new averages are created. Because image values stay exactly the same, rendering is fast but possibly pixelated from sharp edge detail. Nearest neighbor interpolation is recommended for categorical data such as land use classification.

                                                                                        Bilinear -Determines the value of the output cell based by sampling the value of the four nearest cells by linear weighting. The closer an input cell, the higher its influence of on the output cell value. Since output values may differ from nearest input, bilinear interpolation is recommended for continuous data like elevation and raw slope values. Bilinear interpolation takes about five times as long as nearest neighbor interpolation.

                                                                                        Bicubic -Looks at the sixteen nearest cells and fits a smooth curve through the points to find the output value. Bicubic interpolation may both change the input value as well as place the output value outside of the range of input values. Bicubic interpolation is recommended for smoothing continuous data, but this incurs a processing performance overhead.

                                                                                        "},{"location":"services/wms/webadmin/#dimensions-settings","title":"Dimensions settings","text":"

                                                                                        The WMS specification mandates the throwing of an InvalidDimensionValue exception when a dimension value is not valid, and the nearest match is not enabled. This is the default behavior of GeoServer starting with version 2.25, while older versions simply ignored the invalid value and returned empty responses.

                                                                                        The behavior can be controlled in the Dimension Settings section, with a choice of three possible values:

                                                                                        • Use GS version default. Will return an exception if version is greater or equal than 2.25, otherwise will ignore the invalid value.
                                                                                        • Return InvalidDimensionValue. Will return an exception on invalid value, unless nearest neighbor match has been enabled for the layer (standard compliant behavior).
                                                                                        • Ignore invalid value. Will ignore invalid values and return an empty map/info (legacy behavior).
                                                                                        "},{"location":"services/wms/webadmin/#watermark-settings","title":"Watermark Settings","text":"

                                                                                        Watermarking is the process of embedding an image into a map. Watermarks are usually used for branding, copyright, and security measures. Watermarks are configured in the WMS watermarks setting section.

                                                                                        Enable Watermark -Turns on watermarking. When selected, all maps will render with the same watermark. It is not currently possible to specify watermarking on a per-layer or per-feature basis.

                                                                                        Watermark URL -Location of the graphic for the watermark. The graphic can be referenced as an absolute path (e.g., C:\\GeoServer\\watermark.png), a relative one inside GeoServer's data directory (e.g., watermark.png), or a URL (e.g., http://www.example.com/images/watermark.png).

                                                                                        Each of these methods have their own advantages and disadvantages. When using an absolute or relative link, GeoServer keeps a cached copy of the graphic in memory, and won't continually link to the original file. This means that if the original file is subsequently deleted, GeoServer won't register it missing until the watermark settings are edited. Using a URL might seem more convenient, but it is more I/O intensive. GeoServer will load the watermark image for every WMS request. Also, should the URL cease to be valid, the layer will not properly display.

                                                                                        Watermark Transparency--Determines the opacity level of the watermark. Numbers range between 0 (opaque) and 100 (fully invisible).

                                                                                        Watermark Position -Specifies the position of the watermark relative to the WMS request. The nine options indicate which side and corner to place the graphic (top-left, top-center, top-right, etc). The default watermark position is bottom-right. Note that the watermark will always be displayed flush with the boundary. If extra space is required, the graphic itself needs to change.

                                                                                        Because each WMS request renders the watermark, a single tiled map positions one watermark relative to the view window while a tiled map positions the watermark for each tile. The only layer specific aspect of watermarking occurs because a single tile map is one WMS request, whereas a tiled map contains many WMS requests. (The latter watermark display resembles Google Maps faint copyright notice in their Satellite imagery.) The following three examples demonstrate watermark position, transparency and tiling display, respectively.

                                                                                        Single tile watermark (aligned top-right, transparency=0)

                                                                                        Single tile watermark (aligned top-right, transparency=90)

                                                                                        Tiled watermark (aligned top-right, transparency=90)

                                                                                        "},{"location":"services/wms/webadmin/#svg-options","title":"SVG Options","text":"

                                                                                        The GeoServer WMS supports SVG (Scalable Vector Graphics) as an output format. GeoServer currently supports two SVG renderers, available from the SVG producer menu.

                                                                                        1. Simple -Simple SVG renderer. It has limited support for SLD styling, but is very fast.
                                                                                        2. Batik -Batik renderer (as it uses the Batik SVG Framework). It has full support for SLD styling, but is slower.

                                                                                        Enable Anti-aliasing Anti-aliasing is a technique for making edges appear smoother by filling in the edges of an object with pixels that are between the object's color and the background color. Anti-aliasing creates the illusion of smoother lines and smoother selections. Turning on anti-aliasing will generally make maps look nicer, but will increase the size of the images, and will take longer to return. If you are overlaying the anti-aliased map on top of others, beware of using transparencies as the anti-aliasing process mixes with the colors behind and can create a \"halo\" effect.

                                                                                        "},{"location":"services/wms/webadmin/#limited-srs-list","title":"Limited SRS list","text":"

                                                                                        Some clients can have problems processing the large list of SRS (projections) that GeoServer can support when they are all listed in the capabilities document. It is possible to add a list of needed projections in the Limited SRS List box. This takes the form of a list of EPSG codes separated by commas, e.g. 4326,27700.

                                                                                        A limited SRS list

                                                                                        The Output bounding box for every supported CRS flag is only respected if a Limited SRS list has been specified.Setting this flag causes the WMS capabilities document to contain a Bounding Box for each supported CRS, for each Layer. Doing this for every CRS in the EPSG database, for each Layer in the catalog, would result in a impractically huge capabilities document.

                                                                                        "},{"location":"services/wms/webadmin/#authorization-headers-forwarding-for-remote-slds","title":"Authorization headers forwarding for remote SLDs","text":"

                                                                                        A GetMap request may specify the style by referring a remote URL in the SLD parameter. There might be the case that the remote URL require same authorization headers as the current GetMap request. If that's the case a list of allowed style URLs can be specified using newline as separators (URLs might be long). Authorization headers will be only forwarded to a remote URL when it starts with one of the specified URLs.

                                                                                        The list of remote URLs being allowed for authorization headers forwarding.

                                                                                        "},{"location":"services/wms/webadmin/#advanced-projection-handling-and-map-wrapping","title":"Advanced projection handling and map wrapping","text":"

                                                                                        Advanced projection handling is a set of extra \"smarts\" applied while rendering that help getting a good looking map despite the data touching or crossing \"difficult areas\" in selected map projection. This includes, among others:

                                                                                        • Cutting the geometries so that they fit within the area of mathematical stability of the projection math, e.g., it will cut any bit at more than 45 degrees west and east from the central meridian of a transverse Mercator projection, or beyond 85 degrees north or south in a Mercator projection
                                                                                        • Make sure both \"ends\" of the world get queried for data when a map in polar stereographic is hitting an area that includes the dateline
                                                                                        • Ability to optionally preprocess geometries with a densify operation that allows better results when a reprojection operation causes a lot of deformation in the original geometry. Adding more points to the original geometry produces a more precise reprojected one (e.g. straight lines that become curves when reprojected).

                                                                                        Along with advanced projection handling there is the possibility of creating a continuous map across the dateline, wrapping the data on the other side of the longitude range, to get a continuous map. This is called continuous map wrapping, and it's enabled in Mercator and Equirectangular (plate carr\u00e9e) projections. This also uses an heuristic to guess direction of lines that cross the dateline (west to east or east to west). The heuristic can be disabled using the Disable dateline wrapping heuristic option.

                                                                                        Advanced projection handling and continuous map wrapping functionalities are rather useful, and enabled by default, but the tendency to generate multiple or-ed bounding boxes (to query both sides of the dateline) can cause extreme slowness in certain databases (e.g. Oracle), and some users might simply not like the wrapping output, thus, it's possible to disable both functions in the WMS UI:

                                                                                        Continuous map wrapping is disabled if advanced projection handling is disabled.

                                                                                        Automatic densification can slow down rendering, so it's disabled by default, but can be enabled using the Enable automatic densification of geometries option.

                                                                                        Advanced projection handling can also be disabled using the advancedProjectionHandling Format Option. Similarly, continuous map wrapping can also be disabled using the mapWrapping Format Option, automatic densification can be enabled using the advancedProjectionHandlingDensification Format Option, and the dateline heuristic can be disabled using the disableDatelineWrappingHeuristic Format Option.

                                                                                        "},{"location":"services/wms/webadmin/#restricting-mime-types-for-getmap-and-getfeatureinfo-requests","title":"Restricting MIME types for GetMap and GetFeatureInfo requests","text":"

                                                                                        GeoServer supports restricting formats for WMS GetMap and WMS GetFeatureInfo requests. The default is to allow all MIME types for both kinds of request.

                                                                                        The following figure shows an example for MIME type restriction. The MIME types image/png and text/html;subtype=openlayers are allowed for GetMap requests, the MIME types text/html and text/plain are allowed for GetFeatureInfo requests. A GetMap/GetFeatureInfo request with a MIME type not allowed will result in a service exception reporting the error.

                                                                                        Note

                                                                                        Activating MIME type restriction and not allowing at least one MIME type disables the particular request.

                                                                                        "},{"location":"services/wms/webadmin/#disabling-usage-of-dynamic-styling-in-getmap-getfeatureinfo-and-getlegendgraphic-requests","title":"Disabling usage of dynamic styling in GetMap, GetFeatureInfo and GetLegendGraphic requests","text":"

                                                                                        Dynamic styles can be applied to layers in GetMap, GetFeatureInfo and GetLegendGraphic requests using the SLD or SLD_BODY parameters for GET requests.

                                                                                        In addition, GetMap POST requests can contain inline style definition for layers.

                                                                                        The usage of dynamic styling can be restricted on a global or per virtual service basis using the Dynamic styling section.

                                                                                        When the flag is checked, a GetMap/GetFeatureInfo/GetLegendGraphic request with a dynamic style will result in a service exception reporting the error.

                                                                                        "},{"location":"services/wms/webadmin/#disabling-getfeatureinfo-requests-results-reprojection","title":"Disabling GetFeatureInfo requests results reprojection","text":"

                                                                                        By default GetFeatureInfo results are reproject to the map coordinate reference system. This behavior can be deactivated on a global or per virtual service basis in the GetFeatureInfo results reprojection section.

                                                                                        When the flag is checked, GetFeatureInfo requests results will not be reprojected and will instead used the layer coordinate reference system.

                                                                                        "},{"location":"services/wms/webadmin/#services_webadmin_wms_featureinfo_transformation","title":"Disabling GetFeatureInfo requests results transformation","text":"

                                                                                        By default GetFeatureInfo results are determined from the output after evaluating rendering transformation on the layer data. This behavior can be changed only for raster sources (i.e., raster-to-raster and raster-to-vector transformations). This behavior can be deactivated on a global or per virtual service basis in the GetFeatureInfo results transformation section. This setting can be overridden for individual FeatureTypeStyle elements using the transformFeatureInfo SLD vendor option (See section Rendering Transformations).

                                                                                        When the flag is checked, GetFeatureInfo requests results will not be transformed and will instead use the raw, underlying raster data.

                                                                                        Note

                                                                                        WMS Specification

                                                                                        While this option provides a way to revert to the behavior that was used in older GeoServer versions (<2.21.0), the WMS specification states that \"The GetFeatureInfo operation is designed to provide clients of a WMS with more information about features in the pictures of maps that were returned by previous Map requests\" so using this option might not be the behavior as the specification intended it.

                                                                                        "},{"location":"services/wms/webadmin/#enabling-getfeatureinfo-requests-results-html-auto-escaping","title":"Enabling GetFeatureInfo requests results HTML auto-escaping","text":"

                                                                                        By default GetFeatureInfo results are printed in the HTML templates without any automatic escaping, which could result in incorrect and potentially malicious results. This behavior can be activated on a global or per virtual service basis in the GetFeatureInfo results auto-escaping section.

                                                                                        When the flag is checked, values that are printed in the HTML templates for GetFeatureInfo requests results will be automatically escaped. The default FreeMarker templates can be overridden to enable or disable auto-escaping on a per template, per block or per value basis.

                                                                                        Note

                                                                                        Auto-escaping is forced to be enabled by default and that property must be disabled for this setting to have any effect. See the FreeMarker Template Auto-escaping page for instructions.

                                                                                        "},{"location":"services/wms/webadmin/#setting-remote-style-max-connection-and-request-time","title":"Setting Remote Style max connection and request time","text":"

                                                                                        Remote styles max request time and connection timeout can be configured in milliseconds.

                                                                                        Timeout in milliseconds -The max connection timeout in milliseconds for remote style requests.

                                                                                        Max request time in milliseconds -The max request time limit in milliseconds for remote style requests.

                                                                                        "},{"location":"services/wms/webadmin/#mark-factory-precedence","title":"Mark Factory Precedence","text":"

                                                                                        Mark factories can be filtered and ordered during the rendering execution. This makes room to optimize the rendering phase by omitting unused mark factories and prioritizing the fastest ones.

                                                                                        Enable Mark Factory Precedence -Enables the mark factory precedence setup.

                                                                                        Mark Factory Precedence setup -The allowed mark factories to use and its execution order.

                                                                                        "},{"location":"services/wms/webadmin/#i18n-settings","title":"i18n Settings","text":"

                                                                                        Select default language for WMS Service.

                                                                                        Default language

                                                                                        See Internationalization (i18n) section for a how this setting is used.

                                                                                        "},{"location":"services/wms/get_legend_graphic/","title":"GetLegendGraphic","text":"

                                                                                        This chapter describes whether to use the GetLegendGraphics request. The SLD Specifications 1.0.0 gives a good description about GetLegendGraphic requests:

                                                                                        The GetLegendGraphic operation itself is optional for an SLD-enabled WMS. It provides a general mechanism for acquiring legend symbols, beyond the LegendURL reference of WMS Capabilities. Servers supporting the GetLegendGraphic call might code LegendURL references as GetLegendGraphic for interface consistency. Vendor-specific parameters may be added to GetLegendGraphic requests and all of the usual OGC-interface options and rules apply. No XML-POST method for GetLegendGraphic is presently defined.

                                                                                        Here is an example invocation:

                                                                                        http://localhost:8080/geoserver/wms?REQUEST=GetLegendGraphic&VERSION=1.0.0&FORMAT=image/png&WIDTH=20&HEIGHT=20&LAYER=topp:states\n

                                                                                        which would produce four 20x20 icons that graphically represent the rules of the default style of the topp:states layer.

                                                                                        Sample legend

                                                                                        The following table lists the whole set of GetLegendGraphic parameters that can be used.

                                                                                        Parameter Required Description REQUEST Required Value must be \"GetLegendGraphic\". LAYER Required Layer for which to produce legend graphic. STYLE Optional Style of layer for which to produce legend graphic. If not present, the default style is selected. The style may be any valid style available for a layer, including non-SLD internally-defined styles. FEATURETYPE Optional Feature type for which to produce the legend graphic. This is not needed if the layer has only a single feature type. RULE Optional Rule of style to produce legend graphic for, if applicable. In the case that a style has multiple rules but no specific rule is selected, then the map server is obligated to produce a graphic that is representative of all of the rules of the style. SCALE Optional In the case that a RULE is not specified for a style, this parameter may assist the server in selecting a more appropriate representative graphic by eliminating internal rules that are out-of-scope. This value is a standardized scale denominator, defined in Section 10.2. Specifying the scale will also make the symbolizers using Unit Of Measure resize according to the specified scale. SLD Optional This parameter specifies a reference to an external SLD document. It works in the same way as the SLD= parameter of the WMS GetMap operation. SLD_BODY Optional This parameter allows an SLD document to be included directly in an HTTP-GET request. It works in the same way as the SLD_BODY= parameter of the WMS GetMap operation. FORMAT Required This gives the MIME type of the file format in which to return the legend graphic. Allowed values are the same as for the FORMAT= parameter of the WMS GetMap request. WIDTH Optional This gives a hint for the width of the returned graphic in pixels. Vector-graphics can use this value as a hint for the level of detail to include. HEIGHT Optional This gives a hint for the height of the returned graphic in pixels. EXCEPTIONS Optional This gives the MIME type of the format in which to return exceptions. Allowed values are the same as for the EXCEPTIONS= parameter of the WMS GetMap request. LANGUAGE Optional Allows setting labels language for style titles and rules titles; needs a correctly localized SLD to work properly; if labels are not available in the requested language, the default text will be used; look at i18N in SLD for further details."},{"location":"services/wms/get_legend_graphic/#get_legend_graphic_options","title":"Controlling legend appearance with LEGEND_OPTIONS","text":"

                                                                                        GeoServer allows finer control over the legend appearance via the vendor parameter LEGEND_OPTIONS. The general format of LEGEND_OPTIONS is the same as FORMAT_OPTIONS, that is:

                                                                                        ...&LEGEND_OPTIONS=key1:v1;key2:v2;...;keyn:vn\n

                                                                                        Here is a description of the various parameters that can be used in LEGEND_OPTIONS:

                                                                                        • fontName (string) the name of the font to be used when generating rule titles. The font must be available on the server
                                                                                        • fontStyle (string) can be set to italic or bold to control the text style. Other combinations are not allowed right now but we could implement that as well.
                                                                                        • fontSize (integer) allows us to set the Font size for the various text elements. Notice that default size is 12.
                                                                                        • fontColor (hex) allows us to set the color for the text of rules and labels (see above for recommendation on how to create values). Values are expressed in 0xRRGGBB format
                                                                                        • fontAntiAliasing (true/false) when true enables antialiasing for rule titles
                                                                                        • bgColor (hex) background color for the generated legend, values are expressed in 0xRRGGBB format
                                                                                        • dpi (integer) sets the DPI for the current request, in the same way as it is supported by GetMap. Setting a DPI larger than 91 (the default) makes all fonts, symbols and line widths grow without changing the current scale, making it possible to get a high resolution version of the legend suitable for inclusion in printouts
                                                                                        • forceLabels \"on\" means labels will always be drawn, even if only one rule is available. \"off\" means labels will never be drawn, even if multiple rules are available. Off by default.
                                                                                        • forceTitles \"off\" means layer titles will not be drawn for layer groups. On by default.
                                                                                        • labelMargin margin (in pixels) to use between icons and labels.
                                                                                        • layout sets icons layout to be vertical (default) or horizontal.
                                                                                        • columnheight enables multicolumn layout when layout is vertical. Each column height is limited by the columnheight value (in pixels).
                                                                                        • rowwidth enables multirow layout when layout is horizontal. Each row width is limited by the rowwidth value (in pixels).
                                                                                        • columns enables multicolumn layout when layout is vertical. The value is the maximum columns number of legend. The rows used are equal to the next greater integer of /.
                                                                                        • rows enables multirow layout when layout is horizontal. The value is the maximum rows number of legend. The columns used are equal to the next greater integer of /.
                                                                                        • grouplayout Orientation of groups of layer, possible values are horizontal and vertical (default if not specified).
                                                                                        • countMatched When set to true, adds at the end of each label the number of features matching that rule in the current map. Requires extra parameters, see details in the dedicated section.
                                                                                        • hideEmptyRules When set to true hides rules that are not matching any feature.
                                                                                        • wrap When set to true word wraps long legend labels, leading to taller legends but less wide ones.
                                                                                        • wrap_limit when set, it wraps the legend label with the specified number of pixels.
                                                                                        • Here is a sample request sporting most the options:

                                                                                          http://localhost:8080/geoserver/wms?REQUEST=GetLegendGraphic&VERSION=1.0.0&FORMAT=image/png&WIDTH=20&HEIGHT=20&LAYER=topp:states&legend_options=fontName:Times%20New%20Roman;fontAntiAliasing:true;fontColor:0x000033;fontSize:14;bgColor:0xFFFFEE;dpi:180\n

                                                                                          Using LEGEND_OPTIONS to control the output

                                                                                          "},{"location":"services/wms/get_legend_graphic/#controlling-legend-layout","title":"Controlling legend layout","text":"

                                                                                          A set of LEGEND_OPTIONS keys are used to control icons layout in the produced legend images. In particular, a vertical or horizontal layout can be chosen.

                                                                                          Multi column or multi row layouts are possible, and are controlled by the columnheight / rowwidth options (to limit each column / row size) or by the columns / rows options (to fix the # of columns / rows to be used).

                                                                                          Both columnheight / columns and rowwidth / rows can be used to limit the whole size of the produced image (some icons are skipped if they do not fit into the given limits).

                                                                                          In addition, orientation of legends in a layergroup can be configured using the grouplayout option.

                                                                                          "},{"location":"services/wms/get_legend_graphic/#raster-legends-explained","title":"Raster Legends Explained","text":"

                                                                                          This chapter aims to briefly describe the work that I have performed in order to support legends for raster data that draw information taken from the various bits of the SLD 1.0 RasterSymbolizer element. Recall, that up to now there was no way to create legends for raster data, therefore we have tried to fill the gap by providing an implementation of the getLegendGraphic request that would work with the ColorMap element of the SLD 1.0 RasterSymbolizer. Notice that some \"debug\" info about the style, like colormap type and band used are printed out as well.

                                                                                          "},{"location":"services/wms/get_legend_graphic/#whats-a-raster-legend","title":"What's a raster legend","text":"

                                                                                          Here below I have drawn the structure of a typical legend, where some elements of interests are parameterized.

                                                                                          The structure of a typical legend

                                                                                          Take as an instance one of the SLD files attached to this page, each row in the above table draws its essence from the ColorMapEntry element as shown here below:

                                                                                          <ColorMapEntry color=\"#732600\" quantity=\"9888\" opacity=\"1.0\" label=\"<-70 mm\"/>\n

                                                                                          The producer for the raster legend will make use of this elements in order to build the legend, with this in mind, notice that:

                                                                                          • the width of the Color element is driven by the requested width for the GetLegendGraphic request
                                                                                          • the width and height of label and rules is computed accordingly to the used Font and Font size for the prepared text (no new line management for the moment)
                                                                                          • the height of the Color element is driven by the requested width for the GetLegendGraphic request, but notice that for ramps we expand this a little since the goal is to turn the various Color elements into a single long strip
                                                                                          • the height of each row is set to the maximum height of the single elements
                                                                                          • the width of each row is set to the sum of the width of the various elements plus the various paddings
                                                                                          • dx,dy the spaces between elements and rows are set to the 15% of the requested width and height. Notice that dy is ignored for the colormaps of type ramp since they must create a continuous color strip.
                                                                                          • absoluteMargins true/false, used to change the Unit of Measure of dx from percentage (when false) to a fixed number of pixels (when true).
                                                                                          • mx,my the margins from the border of the legends are set to the 1.5% of the total size of the legend

                                                                                          In conclusion, here below I am adding an image of a sample legend with all the various options at work. The request that generated it is the following:

                                                                                          http://localhost:8081/geoserver/wms?REQUEST=GetLegendGraphic&VERSION=1.0.0&FORMAT=image/png&WIDTH=100&HEIGHT=20&LAYER=it.geosolutions:di08031_da&LEGEND_OPTIONS=forceRule:True;dx:0.2;dy:0.2;mx:0.2;my:0.2;fontStyle:bold;borderColor:0000ff;border:true;fontColor:ff0000;fontSize:18\n

                                                                                          Do not worry if it seems like something written in ancient dead language, I am going to explain the various params here below.

                                                                                          Example of a raster legend

                                                                                          "},{"location":"services/wms/get_legend_graphic/#raster-legends-types","title":"Raster legends' types","text":"

                                                                                          As you may know (well, actually you might not since I never wrote any real docs about the RasterSymbolizer work I did) GeoServer supports three types of ColorMaps:

                                                                                          • ramp this is what SLD 1.0 dictates, which means a linear interpolation weighted on values between the colors of the various ColorMapEntries.
                                                                                          • values this is an extension that allows link quantities to colors as specified by the ColorMapEntries quantities. Values not specified are translated into transparent pixels.
                                                                                          • classes this is an extension that allows pure classifications based on intervals created from the ColorMapEntries quantities. Values not specified are translated into transparent pixels.

                                                                                          Here below I am going to list various examples that use the attached styles on a rainfall floating point geotiff.

                                                                                          "},{"location":"services/wms/get_legend_graphic/#colormap-type-is-values","title":"ColorMap type is VALUES","text":"

                                                                                          Refer to the SLD rainfall.sld in attachment.

                                                                                          Raster legend - VALUES type

                                                                                          "},{"location":"services/wms/get_legend_graphic/#colormap-type-is-classes","title":"ColorMap type is CLASSES","text":"

                                                                                          Refer to the SLD rainfall_classes.sld in attachment.

                                                                                          Raster legend - CLASSES type

                                                                                          "},{"location":"services/wms/get_legend_graphic/#colormap-type-is-ramp","title":"ColorMap type is RAMP","text":"

                                                                                          Refer to the SLD rainfall_classes.sld in attachment. Notice that the first legend shows the default border behavior while the second has been forced to draw a border for the breakpoint color of the colormap entry quantity described by the rendered text. Notice that each color element has a part that show the fixed color from the colormap entry it depicts (the lowest part of it, the one that has been outlined by the border in the second legend below) while the upper part of the element has a gradient that connects each element to the previous one to point out the fact that we are using linear interpolation.

                                                                                          Raster legend - RAMP type

                                                                                          "},{"location":"services/wms/get_legend_graphic/#the-various-control-parameters-and-how-to-set-them","title":"The various control parameters and how to set them","text":"

                                                                                          I am now going to briefly explain the various parameters that we can use to control the layout and content of the legend. A request that puts all the various options is shown here:

                                                                                          http://localhost:8081/geoserver/wms?REQUEST=GetLegendGraphic&VERSION=1.0.0&FORMAT=image/png&WIDTH=100&HEIGHT=20&LAYER=it.geosolutions:di08031_da&LEGEND_OPTIONS=forceRule:True;dx:0.2;dy:0.2;mx:0.2;my:0.2;fontStyle:bold;borderColor:0000ff;border:true;fontColor:ff0000;fontSize:18\n

                                                                                          Let's now examine all the interesting elements, one by one. Notice that I am not going to discuss the mechanics of the GetLegendGraphic operation, for that you may want to refer to the SLD 1.0 spec, my goal is to briefly discuss the LEGEND_OPTIONS parameter.

                                                                                          • forceRule (boolean) by default rules for a ColorMapEntry are not drawn to keep the legend small and compact, unless there are no labels at all. You can change this behaviour by setting this parameter to true.
                                                                                          • dx,dy,mx,my (double) can be used to set the margin and the buffers between elements
                                                                                          • border (boolean) activates or deactivates the border on the color elements in order to make the separations clearer. Notice that I decided to always have a line that would split the various color elements for the ramp type of colormap.
                                                                                          • borderColor (hex) allows us to set the color for the border in 0xRRGGBB format
                                                                                          "},{"location":"services/wms/get_legend_graphic/#cql-expressions-and-env","title":"CQL Expressions and ENV","text":"

                                                                                          If CQL expressions are used in ColorMapEntry attributes (see here) to create a dynamic color map taking values from ENV, the same ENV parameters used for GetMap can be given to GetLegendGraphic to get the desired legend entries.

                                                                                          "},{"location":"services/wms/get_legend_graphic/#content-dependent","title":"Content dependent legends","text":"

                                                                                          GeoServer allows building content dependent legend, that is, legends whose contents depend on the currently displayed map. In order to support it the GetLegendGraphic call needs the following extra parameters:

                                                                                          • BBOX
                                                                                          • SRS or CRS (depending on the WMS version, SRS for 1.1.1 and CRS for 1.3.0)
                                                                                          • SRCWIDTH and SRCHEIGHT, the size of the reference map (width and height already have a different meaning in GetLegendGraphic)

                                                                                          Other parameters can also be added to better match the GetMap request, for example, it is recommended to mirror filtering vendor parameters such as, for example, CQL_FILTER,FILTER,FEATUREID,TIME,ELEVATION.

                                                                                          Content dependent evaluation is enabled via the following LEGEND_OPTIONS parameters:

                                                                                          • countMatched: adds the number of features matching the particular rule at the end of the rule label (requires visible labels to work). Applicable only to vector layers.
                                                                                          • hideEmptyRules: hides rules that are not matching any feature. Applicable only if countMatched is true.

                                                                                          For example, let's assume the following layout is added to GeoServer (legend.xml to be placed in GEOSERVER_DATA_DIR/layouts):

                                                                                          <layout>\n    <decoration type=\"legend\" affinity=\"top,right\" offset=\"0,0\" size=\"auto\"/>\n</layout>\n

                                                                                          This will make a legend appear in the GetMap response. The following preview request uses the layout to embed a legend and activates feature counting in it:

                                                                                          http://localhost:8080/geoserver/topp/wms?service=WMS&version=1.1.0&request=GetMap&layers=topp:states&styles=&bbox=-124.73142200000001,24.955967,-66.969849,49.371735&width=768&height=330&srs=EPSG:4326&format=application/openlayers&format_options=layout:legend&legend_options=countMatched:true;fontAntiAliasing:true\n

                                                                                          The result will look as follows:

                                                                                          Embedded legend, full map

                                                                                          Embedded legend, four states

                                                                                          Embedded legend, single state

                                                                                          Embedded legend, single state, hide empty rules

                                                                                          The same can be achieved using a stand-alone GetLegendGraphic request:

                                                                                          http://localhost:8080/geoserver/topp/wms?service=WMS&version=1.1.0&request=GetLegendGraphic&width=20&height=20&layer=topp:states&bbox=-124.73142200000001,24.955967,-66.969849,49.371735&srcwidth=768&srcheight=330&srs=EPSG:4326&format=image/png&legend_options=countMatched:true;fontAntiAliasing:true\n

                                                                                          Direct legend request

                                                                                          Or hide the empty rules using a stand-alone GetLegendGraphic request:

                                                                                          http://localhost:8080/geoserver/topp/wms?service=WMS&version=1.1.0&request=GetLegendGraphic&width=20&height=20&layer=topp:states&bbox=-101.0028076171875,31.025390625,-96.7840576171875,32.838134765625&srcwidth=768&srcheight=330&srs=EPSG:4326&format=image/png&legend_options=countMatched:true;fontAntiAliasing:true;hideEmptyRules:true\n

                                                                                          Direct legend request

                                                                                          "},{"location":"services/wms/get_legend_graphic/#json-output-format","title":"JSON Output Format","text":"

                                                                                          Since version 2.15.0 it has been possible to use application/json as an output format in GetLegendGraphic requests. This allows a JSON aware client to receive a JSON representation of the legend graphic to use for its own rendering requirements.

                                                                                          A simple http request can be used:

                                                                                          http://localhost:9000/geoserver/wms?service=WMS&version=1.1.0&request=GetLegendGraphic&layer=topp:states&format=application/json\n

                                                                                          Which returns a JSON response:

                                                                                          {\"Legend\": [{\n  \"layerName\": \"states\",\n  \"title\": \"USA Population\",\n  \"rules\":   [\n        {\n      \"title\": \"< 2M\",\n      \"filter\": \"[PERSONS < '2000000']\",\n      \"symbolizers\": [{\"Polygon\":       {\n        \"fill\": \"#4DFF4D\",\n        \"fill-opacity\": \"0.7\"\n      }}]\n    },\n        {\n      \"title\": \"2M - 4M\",\n      \"filter\": \"[PERSONS BETWEEN '2000000' AND '4000000']\",\n      \"symbolizers\": [{\"Polygon\":       {\n        \"fill\": \"#FF4D4D\",\n        \"fill-opacity\": \"0.7\"\n      }}]\n    },\n        {\n      \"title\": \"> 4M\",\n      \"filter\": \"[PERSONS > '4000000']\",\n      \"symbolizers\": [{\"Polygon\":       {\n        \"fill\": \"#4D4DFF\",\n        \"fill-opacity\": \"0.7\"\n      }}]\n    },\n        {\n      \"title\": \"Boundary\",\n      \"symbolizers\":       [\n        {\"Line\":         {\n          \"stroke\": \"#000000\",\n          \"stroke-width\": \"0.2\",\n          \"stroke-opacity\": \"1\",\n          \"stroke-linecap\": \"butt\",\n          \"stroke-linejoin\": \"miter\"\n        }},\n        {\"Text\":         {\n          \"label\": \"[STATE_ABBR]\",\n          \"fonts\": [          {\n            \"font-family\": [\"Times New Roman\"],\n            \"font-style\": \"Normal\",\n            \"font-weight\": \"normal\",\n            \"font-size\": \"14\"\n          }],\n          \"label-placement\":           {\n            \"x-anchor\": \"0.5\",\n            \"y-anchor\": \"0.5\",\n            \"rotation\": \"0.0\"\n          }\n        }}\n      ]\n    }\n  ]\n}]}\n

                                                                                          This JSON contains an array of Legends (one for each layer requested) and each legend contains some metadata about the legend and an array of rule objects for each rule within the feature type of the style. Each rule contains the metadata associated with the rule, any filter element and an array of symbolizer objects.

                                                                                          "},{"location":"services/wms/get_legend_graphic/#filters-and-expressions","title":"Filters and Expressions","text":"

                                                                                          Filters are encoded using ECQL, a rule with an ElseFilter has an element \"ElseFilter\" set to the value \"true\". Expressions are also encoded in ECQL (wrapped in []) when encountered in the style.

                                                                                          "},{"location":"services/wms/get_legend_graphic/#symbolizers","title":"Symbolizers","text":"
                                                                                          • PointSymbolizer

                                                                                            A point symbolizer will be represented as a series of elements containing metadata and an array of graphics symbols (see here) , these can be well known marks or external graphics. The point symbolizer also provides an \"URL\" element which allows a client to make a request back to GeoServer to fetch a PNG image of the point symbol.

                                                                                            {\"Point\":     {\n    \"title\": \"title\",\n    \"abstract\": \"abstract\",\n    \"url\": \"http://localhost:9000/geoserver/kml/icon/capitals?0.0.0=\",\n    \"size\": \"6\",\n    \"opacity\": \"1.0\",\n    \"rotation\": \"0.0\",\n    \"graphics\": [      {\n      \"mark\": \"circle\",\n      \"fill\": \"#FFFFFF\",\n      \"fill-opacity\": \"1.0\",\n      \"stroke\": \"#000000\",\n      \"stroke-width\": \"2\",\n      \"stroke-opacity\": \"1\",\n      \"stroke-linecap\": \"butt\",\n      \"stroke-linejoin\": \"miter\"\n    }]}}\n
                                                                                          • LineSymbolizer

                                                                                            A line symbolizer is represented as a list of metadata elements and the stroke parameters <sld_reference_linesymbolizer_css>, it is possible for there to be a graphic-stroke element too.

                                                                                            {\"Line\":     {\n  \"stroke\": \"#AA3333\",\n  \"stroke-width\": \"2\",\n  \"stroke-opacity\": \"1\",\n  \"stroke-linecap\": \"butt\",\n  \"stroke-linejoin\": \"miter\"\n}}\n\n\n{\"Line\":       {\n    \"graphic-stroke\":         {\n      \"url\": \"http://local-test:8080/geoserver/kml/icon/Default Styler\",\n      \"size\": \"6\",\n      \"opacity\": \"0.4\",\n      \"rotation\": \"[(rotation*-1)]\",\n      \"graphics\": [          {\n        \"mark\": \"square\",\n        \"fill\": \"#FFFF00\",\n        \"fill-opacity\": \"1.0\"\n      }]\n    },\n    \"stroke-opacity\": \"1\",\n    \"stroke-linecap\": \"butt\",\n    \"stroke-linejoin\": \"miter\",\n    \"perpendicular-offset\": \"10\"\n  }}  \n
                                                                                          • PolygonSymbolizer

                                                                                            A polygon symbolizer contains stroke parameters <sld_reference_linesymbolizer_css> and fill parameters <sld_reference_fill>.

                                                                                            {\"Polygon\":       {\n  \"stroke\": \"#000000\",\n  \"stroke-width\": \"0.5\",\n  \"stroke-opacity\": \"1\",\n  \"stroke-linecap\": \"butt\",\n  \"stroke-linejoin\": \"miter\",\n  \"fill\": \"#0099CC\",\n  \"fill-opacity\": \"1.0\"\n}}\n

                                                                                            Or a graphic stroke and/or a graphic fill (as described above).

                                                                                            {\"Polygon\":       {\n  \"graphic-stroke\":         {\n    \"url\": \"http://local-test:8080/geoserver/kml/icon/Default Styler\",\n    \"size\": \"6\",\n    \"opacity\": \"0.4\",\n    \"rotation\": \"[(rotation*-1)]\",\n    \"graphics\": [          {\n      \"mark\": \"square\",\n      \"fill\": \"#FFFF00\",\n      \"fill-opacity\": \"1.0\"\n    }]\n  },\n  \"stroke-opacity\": \"1\",\n  \"stroke-linecap\": \"butt\",\n  \"stroke-linejoin\": \"miter\",\n  \"graphic-fill\":         {\n    \"url\": \"http://local-test:8080/geoserver/kml/icon/Default Styler\",\n    \"size\": \"4\",\n    \"opacity\": \"0.4\",\n    \"rotation\": \"[(rotation*-1)]\",\n    \"graphics\": [          {\n      \"mark\": \"circle\",\n      \"fill\": \"#FFFFFF\",\n      \"fill-opacity\": \"1.0\"\n    }]\n  }}}\n
                                                                                          • RasterSymbolizer

                                                                                            Raster symbolizers contain a colormap with an array of entries, each entry contains a label, quantity and color element.

                                                                                            {\"Raster\":   {\n  \"colormap\":     {\n    \"entries\":       [\n              {\n        \"label\": \"values\",\n        \"quantity\": \"0\",\n        \"color\": \"#AAFFAA\"\n      },\n              {\n        \"quantity\": \"1000\",\n        \"color\": \"#00FF00\"\n      },\n              {\n        \"label\": \"values\",\n        \"quantity\": \"1200\",\n        \"color\": \"#FFFF00\"\n      },\n              {\n        \"label\": \"values\",\n        \"quantity\": \"1400\",\n        \"color\": \"#FF7F00\"\n      },\n              {\n        \"label\": \"values\",\n        \"quantity\": \"1600\",\n        \"color\": \"#BF7F3F\"\n      },\n              {\n        \"label\": \"values\",\n        \"quantity\": \"2000\",\n        \"color\": \"#000000\"\n      }\n    ],\n    \"type\": \"ramp\"\n  },\n  \"opacity\": \"1.0\"\n}}\n
                                                                                          • TextSymbolizer

                                                                                            A text symbolizer contains a label expression, followed by an array of fonts and a label-placement object containing details of how the label is placed.

                                                                                            {\"Text\":         {\n    \"label\": \"[STATE_ABBR]\",\n    \"fonts\": [          {\n        \"font-family\": [\"Times New Roman\"],\n        \"font-style\": \"Normal\",\n        \"font-weight\": \"normal\",\n        \"font-size\": \"14\"\n    }],\n    \"label-placement\":           {\n        \"x-anchor\": \"0.5\",\n        \"y-anchor\": \"0.5\",\n        \"rotation\": \"0.0\"\n    }\n}}\n
                                                                                          "},{"location":"services/wms/get_legend_graphic/#vendor-options","title":"Vendor Options","text":"

                                                                                          In any case where one or more vendor options is included in the symbolizer there will be a vendor-options element included in the output. This object will include one line for each vendor option.

                                                                                          \"vendor-options\": {\n  \"labelAllGroup\": \"true\",\n  \"spaceAround\": \"10\",\n  \"followLine\": \"true\",\n  \"autoWrap\": \"50\"\n}\n
                                                                                          "},{"location":"services/wms/googleearth/","title":"Google Earth","text":"

                                                                                          This section contains information on Google Earth support in GeoServer.

                                                                                          Google Earth is a 3-D virtual globe program. A free download from Google, it allows the user to virtually view, pan, and fly around Earth imagery. The imagery on Google Earth is obtained from a variety of sources, mainly from commercial satellite and aerial photography providers.

                                                                                          Google Earth recognizes a markup language called KML (Keyhole Markup Language) for data exchange. GeoServer integrates with Google Earth by supporting KML as a native output format. Any data configured to be served by GeoServer is thus able to take advantage of the full visualization capabilities of Google Earth.

                                                                                          • Overview
                                                                                          • Quickstart
                                                                                          • KML Styling
                                                                                          • Tutorials
                                                                                          • Features
                                                                                          "},{"location":"services/wms/googleearth/kmlstyling/","title":"KML Styling","text":""},{"location":"services/wms/googleearth/kmlstyling/#introduction","title":"Introduction","text":"

                                                                                          Keyhole Markup Langauge (KML), when created and output by GeoServer, is styled using Styled Layer Descriptors (SLD). This is the same approach used to style standard WMS output formats, but is a bit different from how Google Earth is normally styled, behaving more like Cascading Style Sheets (CSS). The style of the map is specified in the SLD file as a series of rules, and then the data matching those rules is styled appropriately in the KML output. For those unfamiliar with SLD, a good place to start is the Introduction to SLD. The remainder of this guide contains information about how to construct SLD documents in order to impact the look of KML produced by GeoServer.

                                                                                          "},{"location":"services/wms/googleearth/kmlstyling/#contents","title":"Contents","text":"

                                                                                          SLD Generation from CSS

                                                                                          Creating SLD by hand

                                                                                          SLD Structure

                                                                                          Points

                                                                                          Lines

                                                                                          Polygons

                                                                                          Text Labels

                                                                                          Descriptions

                                                                                          "},{"location":"services/wms/googleearth/kmlstyling/#kml-styling-basic","title":"SLD Generation from CSS","text":"

                                                                                          The CSS extension provides the facility to generate SLD files using a lightweight \"Cascading Style Sheet\" syntax. The CSS GUI provides a live map preview as you are editing your style in addition to an attribute reference for the current layer.

                                                                                          The generated styles will work seamlessly with KML output from GeoServer.

                                                                                          "},{"location":"services/wms/googleearth/kmlstyling/#kml-styling-sld-hand","title":"Creating SLD by hand","text":"

                                                                                          One can edit the SLD files directly instead of using the CSS extension. For the most complete exploration of editing SLDs see the Styling section. The examples below show how some of the basic styles show up in Google Earth.

                                                                                          "},{"location":"services/wms/googleearth/kmlstyling/#kml-styling-sld-structure","title":"SLD Structure","text":"

                                                                                          The following is a skeleton of a SLD document. It can be used as a base on which to expand upon to create more interesting and complicated styles.

                                                                                          <StyledLayerDescriptor version=\"1.0.0\"\n   xsi:schemaLocation=\"http://www.opengis.net/sld StyledLayerDescriptor.xsd\"\n   xmlns=\"http://www.opengis.net/sld\"\n   xmlns:ogc=\"http://www.opengis.net/ogc\"\n   xmlns:xlink=\"http://www.w3.org/1999/xlink\"\n   xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\">\n   <NamedLayer>\n      <Name>Default Line</Name>\n      <UserStyle>\n         <Title>My Style</Title>\n         <Abstract>A style</Abstract>\n         <FeatureTypeStyle>\n            <Rule>\n\n                  <!-- symbolizers go here -->\n\n            </Rule>\n         </FeatureTypeStyle>\n      </UserStyle>\n   </NamedLayer>\n</StyledLayerDescriptor>\n

                                                                                          Figure 3: Basic SLD structure

                                                                                          In order to test the code snippets in this document, create an SLD with the content as shown in Figure 3, and then add the specific code you wish to test in the space that says <!-- symbolizers go here -->. To view, edit, or add SLD files to GeoServer, navigate to Config -> Data -> Styles.

                                                                                          "},{"location":"services/wms/googleearth/kmlstyling/#kml-styling-points","title":"Points","text":"

                                                                                          In SLD, styles for points are specified via a PointSymbolizer. An empty PointSymbolizer element will result in a default KML style:

                                                                                          <PointSymbolizer>\n</PointSymbolizer>\n

                                                                                          Figure 4: Default point

                                                                                          Three aspects of points that can be specified are color, opacity, and the icon.

                                                                                          "},{"location":"services/wms/googleearth/kmlstyling/#point-color","title":"Point Color","text":"

                                                                                          The color of a point is specified with a CssParameter element and a fill attribute. The color is specified as a six digit hexadecimal code.

                                                                                          <PointSymbolizer>\n   <Graphic>\n      <Mark>\n         <Fill>\n            <CssParameter name=\"fill\">#ff0000</CssParameter>\n         </Fill>\n      </Mark>\n   </Graphic>\n</PointSymbolizer>\n

                                                                                          Figure 5: Setting the point color (#ff0000 = 100% red)

                                                                                          "},{"location":"services/wms/googleearth/kmlstyling/#point-opacity","title":"Point Opacity","text":"

                                                                                          The opacity of a point is specified with a CssParameter element and a fill-opacity attribute. The opacity is specified as a floating point number between 0 and 1, with 0 being completely transparent, and 1 being completely opaque.

                                                                                          <PointSymbolizer>\n   <Graphic>\n      <Mark>\n         <Fill>\n            <CssParameter name=\"fill-opacity\">0.5</CssParameter>\n         </Fill>\n      </Mark>\n   </Graphic>\n</PointSymbolizer>\n

                                                                                          Figure 6: Setting the point opacity (0.5 = 50% opaque)

                                                                                          "},{"location":"services/wms/googleearth/kmlstyling/#point-icon","title":"Point Icon","text":"

                                                                                          An icon different from the default can be specified with the ExternalGraphic element:

                                                                                          <PointSymbolizer>\n   <Graphic>\n      <ExternalGraphic>\n         <OnlineResource xlink:type=\"simple\"\n            xlink:href=\"http://maps.google.com/mapfiles/kml/pal3/icon55.png\"/>\n         <Format>image/png</Format>\n      </ExternalGraphic>\n   </Graphic>\n</PointSymbolizer>\n

                                                                                          Figure 7: A custom icon for points

                                                                                          In Figure 7, the custom icon is specified as a remote URL. It is also possible to place the graphic in the GeoServer styles directory, and then specify the filename only:

                                                                                          <PointSymbolizer>\n   <Graphic>\n      <ExternalGraphic>\n         <OnlineResource xlink:type=\"simple\" xlink:href=\"icon55.png\"/>\n         <Format>image/png</Format>\n      </ExternalGraphic>\n   </Graphic>\n</PointSymbolizer>\n

                                                                                          Figure 8: Specifying a local file for a graphic point

                                                                                          "},{"location":"services/wms/googleearth/kmlstyling/#kml-styling-lines","title":"Lines","text":"

                                                                                          Styles for lines are specified via a LineSymbolizer. An empty LineSymbolizer element will result in a default KML style:

                                                                                          <LineSymbolizer>\n</LineSymbolizer>\n

                                                                                          Figure 9: Default line

                                                                                          The aspects of the resulting line which can be specified via a LineSymbolizer are color, width, and opacity.

                                                                                          "},{"location":"services/wms/googleearth/kmlstyling/#line-color","title":"Line Color","text":"

                                                                                          The color of a line is specified with a CssParameter element and a stroke attribute. The color is specified as a six digit hexadecimal code.

                                                                                          <LineSymbolizer>\n   <Stroke>\n      <CssParameter name=\"stroke\">#ff0000</CssParameter>\n   </Stroke>\n</LineSymbolizer>\n

                                                                                          Figure 10: Line rendered with color #ff0000 (100% red)

                                                                                          "},{"location":"services/wms/googleearth/kmlstyling/#line-width","title":"Line Width","text":"

                                                                                          The width of a line is specified with a CssParameter element and a stroke-width attribute. The width is specified as an integer (in pixels):

                                                                                          <LineSymbolizer>\n   <Stroke>\n      <CssParameter name=\"stroke-width\">5</CssParameter>\n   </Stroke>\n</LineSymbolizer>\n

                                                                                          Figure 11: Line rendered with a width of five (5) pixels

                                                                                          "},{"location":"services/wms/googleearth/kmlstyling/#line-opacity","title":"Line Opacity","text":"

                                                                                          The opacity of a line is specified with a CssParameter element and a fill-opacity attribute. The opacity is specified as a floating point number between 0 and 1, with 0 being completely transparent, and 1 being completely opaque.

                                                                                          <LineSymbolizer>\n   <Stroke>\n      <CssParameter name=\"stroke-opacity\">0.5</CssParameter>\n   </Stroke>\n</LineSymbolizer>\n

                                                                                          Figure 12: A line rendered with 50% opacity

                                                                                          "},{"location":"services/wms/googleearth/kmlstyling/#kml-styling-polygons","title":"Polygons","text":"

                                                                                          Styles for polygons are specified via a PolygonSymbolizer. An empty PolygonSymbolizer element will result in a default KML style:

                                                                                          <PolygonSymbolizer>\n</PolygonSymbolizer>\n

                                                                                          Polygons have more options for styling than points and lines, as polygons have both an inside (\"fill\") and an outline (\"stroke\"). The aspects of polygons that can be specified via a PolygonSymbolizer are stroke color, stroke width, stroke opacity, fill color, and fill opacity.

                                                                                          "},{"location":"services/wms/googleearth/kmlstyling/#polygon-stroke-color","title":"Polygon Stroke Color","text":"

                                                                                          The outline color of a polygon is specified with a CssParameter element and stroke attribute inside of a Stroke element. The color is specified as a 6 digit hexadecimal code:

                                                                                          <PolygonSymbolizer>\n   <Stroke>\n      <CssParameter name=\"stroke\">#0000FF</CssParameter>\n   </Stroke>\n</PolygonSymbolizer>\n

                                                                                          Figure 13: Outline of a polygon (#0000FF or 100% blue)

                                                                                          "},{"location":"services/wms/googleearth/kmlstyling/#polygon-stroke-width","title":"Polygon Stroke Width","text":"

                                                                                          The outline width of a polygon is specified with a CssParameter element and stroke-width attribute inside of a Stroke element. The width is specified as an integer.

                                                                                          <PolygonSymbolizer>\n   <Stroke>\n      <CssParameter name=\"stroke-width\">5</CssParameter>\n   </Stroke>\n</PolygonSymbolizer>\n

                                                                                          Figure 14: Polygon with stroke width of five (5) pixels

                                                                                          "},{"location":"services/wms/googleearth/kmlstyling/#polygon-stroke-opacity","title":"Polygon Stroke Opacity","text":"

                                                                                          The stroke opacity of a polygon is specified with a CssParameter element and stroke attribute inside of a Stroke element. The opacity is specified as a floating point number between 0 and 1, with 0 being completely transparent, and 1 being completely opaque.

                                                                                          <PolygonSymbolizer>\n   <Stroke>\n      <CssParameter name=\"stroke-opacity\">0.5</CssParameter>\n   </Stroke>\n</PolygonSymbolizer>\n

                                                                                          Figure 15: Polygon stroke opacity of 0.5 (50% opaque)

                                                                                          "},{"location":"services/wms/googleearth/kmlstyling/#polygon-fill-color","title":"Polygon Fill Color","text":"

                                                                                          The fill color of a polygon is specified with a CssParameter element and fill attribute inside of a Fill element. The color is specified as a six digit hexadecimal code:

                                                                                          <PolygonSymbolizer>\n   <Fill>\n      <CssParameter name=\"fill\">#0000FF</CssParameter>\n   </Fill>\n</PolygonSymbolizer>\n

                                                                                          Figure 16: Polygon fill color of #0000FF (100% blue)

                                                                                          "},{"location":"services/wms/googleearth/kmlstyling/#polygon-fill-opacity","title":"Polygon Fill Opacity","text":"

                                                                                          The fill opacity of a polygon is specified with a CssParameter element and fill-opacity attribute inside of a Fill element. The opacity is specified as a floating point number between 0 and 1, with 0 being completely transparent, and 1 being completely opaque.

                                                                                          <PolygonSymbolizer>\n   <Fill>\n      <CssParameter name=\"fill-opacity\">0.5</CssParameter>\n   </Fill>\n</PolygonSymbolizer>\n

                                                                                          Figure 17: Polygon fill opacity of 0.5 (50% opaque)

                                                                                          "},{"location":"services/wms/googleearth/kmlstyling/#kml-styling-text-labels","title":"Text Labels","text":"

                                                                                          There are two ways to specify a label for a feature in Google Earth. The first is with Freemarker templates (LINK?), and the second is with a TextSymbolizer. Templates take precedence over symbolizers.

                                                                                          "},{"location":"services/wms/googleearth/kmlstyling/#freemarker-templates","title":"Freemarker Templates","text":"

                                                                                          Specifying labels via a Freemarker template involves creating a special text file called title.ftl and placing it into the workspaces/<ws name>/<datastore name>/<feature type name> directory (inside the GeoServer data directory) for the dataset to be labeled. For example, to create a template to label the states dataset by state name one would create the file here: <data_dir>/workspaces/topp/states_shapefile/states/title.ftl. The content of the file would be:

                                                                                          ${STATE_NAME.value}\n

                                                                                          Figure 18: Using a Freemarker template to display the value of STATE_NAME

                                                                                          For more information on Placemark Templates, please see our full tutorial (LINK FORTHCOMING).

                                                                                          "},{"location":"services/wms/googleearth/kmlstyling/#textsymbolizer","title":"TextSymbolizer","text":"

                                                                                          In SLD labels are specified with the Label element of a TextSymbolizer. (Note the ogc: prefix on the PropertyName element.)

                                                                                          <TextSymbolizer>\n   <Label>\n      <ogc:PropertyName>STATE_NAME</ogc:PropertyName>\n   </Label>\n</TextSymbolizer>\n

                                                                                          Figure 19: Using a TextSymbolizer to display the value of STATE_NAME

                                                                                          The aspects of the resulting label which can be specified via a TextSymbolizer are color and opacity.

                                                                                          "},{"location":"services/wms/googleearth/kmlstyling/#textsymbolizer-color","title":"TextSymbolizer Color","text":"

                                                                                          The color of a label is specified with a CssParameter element and fill attribute inside of a Fill element. The color is specified as a six digit hexadecimal code:

                                                                                          <TextSymbolizer>\n   <Label>\n      <ogc:PropertyName>STATE_NAME</ogc:PropertyName>\n   </Label>\n   <Fill>\n      <CssParameter name=\"fill\">#000000</CssParameter>\n   </Fill>\n</TextSymbolizer>\n

                                                                                          Figure 20: TextSymbolizer with black text color (#000000)

                                                                                          "},{"location":"services/wms/googleearth/kmlstyling/#textsymbolizer-opacity","title":"TextSymbolizer Opacity","text":"

                                                                                          The opacity of a label is specified with a CssParameter element and fill-opacity attribute inside of a Fill element. The opacity is specified as a floating point number between 0 and 1, with 0 being completely transparent, and 1 being completely opaque.

                                                                                          <TextSymbolizer>\n   <Label>\n      <ogc:PropertyName>STATE_NAME</ogc:PropertyName>\n   </Label>\n   <Fill>\n      <CssParameter name=\"fill-opacity\">0.5</CssParameter>\n   </Fill>\n</TextSymbolizer>\n

                                                                                          Figure 21: TextSymbolizer with opacity 0.5 (50% opaque)

                                                                                          "},{"location":"services/wms/googleearth/kmlstyling/#kml-styling-descriptions","title":"Descriptions","text":"

                                                                                          When working with KML, each feature is linked to a description, accessible when the feature is clicked on. By default, GeoServer creates a list of all the attributes and values for the particular feature.

                                                                                          Figure 22: Default description for a feature

                                                                                          It is possible to modify this default behavior. Much like with featureType titles, which are edited by creating a title.ftl template, a custom description can be used by creating template called description.ftl and placing it into the feature type directory (inside the GeoServer data directory) for the dataset. For instance, to create a template to provide a description for the states dataset, one would create the file: <data_dir>/workspaces/topp/states_shapefile/states/description.ftl. As an example, if the content of the description template is:

                                                                                          This is the state of ${STATE_NAME.value}.\n

                                                                                          The resultant description will look like this:

                                                                                          Figure 23: A custom description

                                                                                          It is also possible to create one description template for all featureTypes in a given namespace. To do this, create a description.ftl file as above, and save it as <data_dir>/templates/<workspace>/description.ftl. Please note that if a description template is created for a specific featureType that also has an associated namespace description template, the featureType template (i.e. the most specific template) will take priority.

                                                                                          One can also create more complex descriptions using a combination of HTML and the attributes of the data. A full tutorial on how to use templates to create descriptions is available in our page on KML Placemark Templates. (LINK?)

                                                                                          SLD Generation from CSS SLD Structure Points Lines Polygons Text Labels Descriptions

                                                                                          "},{"location":"services/wms/googleearth/overview/","title":"Overview","text":""},{"location":"services/wms/googleearth/overview/#why-use-geoserver-with-google-earth","title":"Why use GeoServer with Google Earth?","text":"

                                                                                          GeoServer is useful when one wants to put a lot of data on to Google Earth. GeoServer automatically generates KML that can be easily and quickly served and visualized in Google Earth. GeoServer operates entirely through a Network Link, which allows it to selectively return information for the area being viewed. With GeoServer as a robust and powerful server and Google Earth providing rich visualizations, they are a perfect match for sharing your data.

                                                                                          "},{"location":"services/wms/googleearth/overview/#standards-based-implementation","title":"Standards-based implementation","text":"

                                                                                          GeoServer supports Google Earth by providing KML as a Web Map Service (WMS) output format. This means that adding data published by GeoServer is as simple as constructing a standard WMS request and specifying \"application/vnd.google-earth.kml+xml\" as the outputFormat. Since generating KML is just a WMS request, it fully supports Styling via SLD.

                                                                                          See the next section (Quickstart) to view GeoServer and Google Earth in action.

                                                                                          "},{"location":"services/wms/googleearth/quickstart/","title":"Quickstart","text":"

                                                                                          Note

                                                                                          If you are using GeoServer locally, the GEOSERVER_URL is usually http://localhost:8080/geoserver

                                                                                          "},{"location":"services/wms/googleearth/quickstart/#viewing-a-layer","title":"Viewing a layer","text":"

                                                                                          Once GeoServer is installed and running, open up a web browser and go to the web admin console (Web administration interface). Navigate to the Layer Preview by clicking on the Layer Preview link at the bottom of the left sidebar. You will be presented with a list of the currently configured layers in your GeoServer instance. Find the row that says topp:states. To the right of the layer click on the link that says KML.

                                                                                          The Map Preview page

                                                                                          If Google Earth is correctly installed on your computer, you will see a dialog asking how to open the file. Select Open with Google Earth.

                                                                                          Open with Google Earth

                                                                                          When Google Earth is finished loading the result will be similar to below.

                                                                                          The topp:states layer rendered in Google Earth

                                                                                          "},{"location":"services/wms/googleearth/quickstart/#direct-access-to-kml","title":"Direct access to KML","text":"

                                                                                          All of the configured FeatureTypes are available to be output as KML (and thus loaded into Google Earth). The URL structure for KMLs is:

                                                                                          http://GEOSERVER_URL/wms/kml?layers=<layername>\n

                                                                                          For example, the topp:states layer URL is:

                                                                                          http://GEOSERVER_URL/wms/kml?layers=topp:states\n
                                                                                          "},{"location":"services/wms/googleearth/quickstart/#adding-a-network-link","title":"Adding a Network Link","text":"

                                                                                          An alternative to serving KML directly into Google Earth is to use a Network Link. A Network Link allows for better integration into Google Earth. For example, using a Network Link enables the user to refresh the data within Google Earth, without having to retype a URL, or click on links in the GeoServer Map Preview again.

                                                                                          To add a Network Link, pull down the Add menu, and go to Network Link. The New Network Link dialog box will appear. Name your layer in the Name field. (This will show up in My Places on the main Google Earth screen.) Set Link to:

                                                                                          http://GEOSERVER_URL/wms/kml?layers=topp:states\n

                                                                                          (Don't forget to replace the GEOSERVER_URL.) Click OK. You can now save this layer in your My Places.

                                                                                          Adding a network link

                                                                                          Check out the sections on Tutorials and the KML Styling for more information.

                                                                                          "},{"location":"services/wms/googleearth/features/","title":"Features","text":"

                                                                                          This section delves into greater detail about the various functionality and options possible with KML output and Google Earth.

                                                                                          • KML Reflector
                                                                                          • Toggling Placemarks
                                                                                          • Customizing Placemarks
                                                                                          • KML Placemark Placement
                                                                                          • KML Height and Time
                                                                                          • KML Legends
                                                                                          • Filters
                                                                                          • KML Super-Overlays
                                                                                          • KML Regionation
                                                                                          • KML Scoring
                                                                                          "},{"location":"services/wms/googleearth/features/customizingplacemarks/","title":"Customizing Placemarks","text":"

                                                                                          KML output can leverage some powerful visualization abilities in Google Earth. Titles can be displayed on top of the features. Descriptions (custom HTML shown when clicking on a feature) can be added to customize the views of the attribute data. In addition, using Google Earth's time slider, time-based animations can be created. Finally, height of features can be set, as opposed to the default ground overlay. All of these can be accomplished by creating Freemarker templates. Freemarker templates are text files (with limited HTML code), saved in the GeoServer data directory, that utilize variables that link to specific attributes in the data.

                                                                                          "},{"location":"services/wms/googleearth/features/customizingplacemarks/#titles","title":"Titles","text":"

                                                                                          Specifying labels via a template involves creating a special text file called title.ftl and placing it into the featuretypes directory inside the GeoServer data directory for the dataset to be labeled. For instance, to create a template to label the states layer by state name, one would create the file: <data_dir>/workspaces/topp/states_shapefile/states/title.ftl. The content of the file would be:

                                                                                          ${STATE_NAME.value}\n
                                                                                          "},{"location":"services/wms/googleearth/features/customizingplacemarks/#descriptions","title":"Descriptions","text":"

                                                                                          When working with KML, each feature is linked to a description, accessible when the feature is clicked on. By default, GeoServer creates a list of all the attributes and values for the particular feature.

                                                                                          It is possible to modify this default behavior. Much like with featuretype titles, which are edited by creating a title.ftl template, specifying descriptions via a template involves creating a special text file called description.ftl and placing it into the featuretypes directory inside the GeoServer data directory for the dataset to be labeled. For instance, a sample description template would be saved here: <data_dir>/workspaces/topp/states_shapefile/states/description.ftl. The content of the file could be:

                                                                                          This is the state of ${STATE_NAME.value}.\n

                                                                                          The resulting description will look like this:

                                                                                          Warning

                                                                                          Add SS: A custom description

                                                                                          It is also possible to create one description template for all layers in a given namespace. To do this, create a description.ftl file as above, and save it here:

                                                                                          <data_dir>/workspaces/<namespace>/description.ftl.\n

                                                                                          Please note that if a description template is created for a specific layer that also has an associated namespace description template, the layer template (i.e. the most specific template) will take priority.

                                                                                          "},{"location":"services/wms/googleearth/features/filters/","title":"Filters","text":"

                                                                                          Though not specific to Google Earth, GeoServer has the ability to filter data returned from the Web Map Service (WMS). The KML Reflector will pass through any WMS filter or cql_filter parameter to GeoServer to constrain the response.

                                                                                          Note

                                                                                          Filters are basically a translation of a SQL \"WHERE\" statement into web form. Though limited to a single table, this allows users to do logical filters like \"AND\" and \"OR\" to make very complex queries, leveraging numerical and string comparisons, geometric operations (\"bbox\", \"touches\", \"intersects\", \"disjoint\"), \"LIKE\" statements, nulls, and more.

                                                                                          "},{"location":"services/wms/googleearth/features/filters/#filter","title":"Filter","text":"

                                                                                          There simplest filter is very easy to include. It is called the featureid filter, and it lets you filter to a single feature by its ID. The syntax is:

                                                                                          featureid=<feature>\n

                                                                                          where is the feature and its ID. An example would be:

                                                                                          http://localhost:8080/geoserver/wms/kml?layers=topp:states&featureid=states.5\n

                                                                                          This request will output only the state of Maryland. The feature IDs of your data are most easily found by doing WFS or KML requests and examining the resulting output.

                                                                                          "},{"location":"services/wms/googleearth/features/filters/#cql-filter","title":"CQL Filter","text":"

                                                                                          Using filters in a URL can be very unwieldy, as one needs to include URL-encoded XML:

                                                                                          http:/localhost:8080/geoserver/wms/kml?layers=topp:states&FILTER=%3CFilter%3E%3CPropertyIsBetween%3E%3CPropertyName%3Etopp:LAND_KM%3C/PropertyName%3E%3CLowerBoundary%3E%3CLiteral%3E100000%3C/Literal%3E%3C/LowerBoundary%3E%3CUpperBoundary%3E%3CLiteral%3E150000%3C/Literal%3E%3C/UpperBoundary%3E%3C/PropertyIsBetween%3E%3C/Filter%3E\n

                                                                                          Instead, one can use Common Query Language (CQL), which allows one to specify the same statement more succinctly:

                                                                                          http://localhost:8080/geoserver/wms/kml?layers=topp:states&CQL_FILTER=LAND_KM+BETWEEN+100000+AND+150000\n

                                                                                          This query will return all the states in the US with areas between 100,000 and 150,000 km\\^2.

                                                                                          "},{"location":"services/wms/googleearth/features/kmlcentroids/","title":"KML Placemark Placement","text":"

                                                                                          The placemark \"placement\" (also referred to as the \"centroid\") refers to the location of the placemark icon with respect to the feature geometry itself. Historically this placement has been chosen to be simply the centroid of the feature geometry. This section describes options for controlling placement were introduced.

                                                                                          "},{"location":"services/wms/googleearth/features/kmlcentroids/#clipping","title":"Clipping","text":"

                                                                                          The KMCENTROID_CLIP option determines whether the feature geometry should be clipped to the viewport before the centroid is calculated. This will ensure that the placemark icon always falls within the viewport, even in cases part of a geometry falls outside of it.

                                                                                          The option is set to either true or false. The default value isfalse.

                                                                                          As an example consider the following square polygon with its placemark icon. When the polygon is entirely in the viewport the placement is good.

                                                                                          When the polygon moves out of the viewport the icon is lost as in the following figure:

                                                                                          When KMCENTROID_CLIP set to true only the part of the geometry intersecting the viewport is considered.

                                                                                          "},{"location":"services/wms/googleearth/features/kmlcentroids/#sampling-for-internal-point","title":"Sampling for internal point","text":"

                                                                                          The KMCENTROID_CONTAIN option determines whether point chosen for the centroid must fall within the feature geometry. For irregularly shaped geometries (like a \"C\" shaped polygon) the default centroid calculation will fall outside of the geometry. The option is set to either true or false. The default value is false.

                                                                                          In order to find a contained point of a polygon a sampling tequnique is used where a number of points are chosen until one is found that falls within the polygon. The KMCENTROID_SAMPLE option determines how many samples to attempt. The value is an integer with a default value is 5. Note that this option only applies when KMCENTROID_CONTAIN is set to true.

                                                                                          As an example consider the following \"c\" shaped polygon with its placemark icon. By default the icon falls outside of the polygon.

                                                                                          When KMCENTROID_CONTAIN set to true a point within the polygon is chosen.

                                                                                          Note

                                                                                          The sampling tequnique may not always be able to find a suitable point. You can try to increase the number of samples but it is still not a guarantee. Care also must be taken when increasing the sample count since it adds overhead to the overall KML rendering process.

                                                                                          "},{"location":"services/wms/googleearth/features/kmlheighttime/","title":"KML Height and Time","text":""},{"location":"services/wms/googleearth/features/kmlheighttime/#height","title":"Height","text":"

                                                                                          GeoServer by default creates two dimensional overlays in Google Earth. However, GeoServer can output features with height information (also called \"KML extrudes\") if desired. This can have the effect of having features \"float\" above the ground, or create bar graph style structures in the shape of the features. The height of features can be linked to an attribute of the data.

                                                                                          Setting the height of features is determined by using a KML Freemarker template. Create a file called height.ftl, and save it in the same directory as the featuretype in your GeoServer data directory. For example, to create a height template for the states layer, the file should be saved in <data_dir>/workspaces/topp/states_shapefile/states/height.ftl.

                                                                                          To set the height based on an attribute, the syntax is:

                                                                                          ${ATTRIBUTE.value}\n

                                                                                          Replace the word ATTRIBUTE with the name of the height attribute in your data set. For a complete tutorial on working with the height templates see Heights Templates.

                                                                                          "},{"location":"services/wms/googleearth/features/kmlheighttime/#time","title":"Time","text":"

                                                                                          Google Earth also contains a \"time slider\", which can allow animations of data, and show changes over time. As with height, time can be linked to an attribute of the data, as long as the data set has a date/time attribute. Linking this date/time attribute to the time slider in Google Earth is accomplished by creating a Freemarker template. Create a file called time.ftl, and save it in the same directory that contains your data's info.xml.

                                                                                          To set the time based on an attribute the syntax is:

                                                                                          ${DATETIME_ATTRIBUTE.value}\n

                                                                                          Replace the word DATETIME_ATTRIBUTE with the name of the date/time attribute. When creating KML, GeoServer will automatically link the data to the time element in Google Earth. If set successfully, the time slider will automatically appear.

                                                                                          For a full tutorial on using GeoServer with Google Earth's time slider see Time

                                                                                          "},{"location":"services/wms/googleearth/features/kmllegends/","title":"KML Legends","text":"

                                                                                          WMS includes a GetLegendGraphic operation which allows a WMS client to obtain a legend graphic from the server for a particular layer. Combining the legend with KML overlays allows the legend to be viewed inside Google Earth.

                                                                                          To get GeoServer to include a legend with the KML output, append legend=true to the KML reflector request. For example:

                                                                                          http://localhost:8080/geoserver/wms/kml?layers=topp:states&legend=true\n

                                                                                          The resulting Google Earth output looks like this:

                                                                                          "},{"location":"services/wms/googleearth/features/kmlreflector/","title":"KML Reflector","text":"

                                                                                          Standard WMS requests can be quite long and cumbersome. The following is an example of a request for KML output from GeoServer:

                                                                                          http://localhost:8080/geoserver/ows?service=WMS&request=GetMap&version=1.1.1&format=application/vnd.google-earth.kml+XML&width=1024&height=1024&srs=EPSG:4326&layers=topp:states&styles=population&bbox=-180,-90,180,90\n

                                                                                          GeoServer includes an alternate way of requesting KML, and that is to use the KML reflector. The KML reflector is a simpler URL-encoded request that uses sensible defaults for many of the parameters in a standard WMS request. Using the KML reflector one can shorten the above request to:

                                                                                          http://localhost:8080/geoserver/wms/kml?layers=topp:states\n
                                                                                          "},{"location":"services/wms/googleearth/features/kmlreflector/#using-the-kml-reflector","title":"Using the KML reflector","text":"

                                                                                          The only mandatory parameter is the layers parameter. The syntax is as follows:

                                                                                          http://GEOSERVER_URL/wms/kml?layers=<layer>\n

                                                                                          where GEOSERVER_URL is the URL of your GeoServer instance, and <layer> is the name of the featuretype to be served.

                                                                                          The following table lists the default assumptions:

                                                                                          Key Value request GetMap service wms version 1.1.1 srs EPSG:4326 format application/vnd.google-earth.kml+xml width 2048 height 2048 bbox <layer bounds> kmattr true kmplacemark false kmscore 40 styles [default style for the featuretype]

                                                                                          Any of these defaults can be changed when specifying the request. For instance, to specify a particular style, one can append styles=population to the request:

                                                                                          http://localhost:8080/geoserver/wms/kml?layers=topp:states&styles=population\n

                                                                                          To specify a different bounding box, append the parameter to the request:

                                                                                          http://localhost:8080/geoserver/wms/kml?layers=topp:states&bbox=-124.73,24.96,-66.97,49.37\n
                                                                                          "},{"location":"services/wms/googleearth/features/kmlreflector/#reflector-modes","title":"Reflector modes","text":"

                                                                                          The KML reflector can operate in one of three modes: refresh, superoverlay, and download.

                                                                                          The mode is set by appending the following parameter to the URL:

                                                                                          mode=<mode>\n

                                                                                          where <mode> is one of the three reflector modes. The details for each mode are as follows:

                                                                                          Mode Description refresh (default for all versions except 1.7.1 through 1.7.5) Returns dynamic KML that can be refreshed/updated by the Google Earth client. Data is refreshed and new data/imagery is downloaded when zooming/panning stops. This mode can return either vector or raster (placemark or overlay) The decision to return either vector or raster data is determined by the value of kmscore. Please see the section on KML Scoring for more information. superoverlay (default for versions 1.7.1 through 1.7.5) Returns KML as a super-overlay. A super-overlay is a form of KML in which data is broken up into regions. Please see the section on KML Super-Overlays for more information. download Returns KML which contains the entire data set. In the case of a vector layer, this will include a series of KML placemarks. With raster layers, this will include a single KML ground overlay. This is the only mode that doesn't dynamically request new data from the server, and thus is self-contained KML."},{"location":"services/wms/googleearth/features/kmlreflector/#more-about-the-superoverlay-mode","title":"More about the \"superoverlay\" mode","text":"

                                                                                          When requesting KML using the superoverlay mode, there are four additional submodes available regarding how and when data is requested. These options are set by appending the following parameter to the KML reflector request:

                                                                                          superoverlay_mode=<submode>\n

                                                                                          where <submode> is one of the following options:

                                                                                          Submode Description auto (default) Always returns vector features if the original data is in vector form, and returns raster imagery if the original data is in raster form. This can sometimes be less than optimal if the geometry of the features are very complicated, which can slow down Google Earth. raster Always returns raster imagery, regardless of the original data. This is almost always faster, but all vector information is lost in this view. overview Displays either vector or raster data depending on the view. At higher zoom levels, raster imagery will be displayed, and at lower zoom levels, vector features will be displayed. The determination for when to switch between vector and raster is made by the regionation parameters set on the server. See the section on KML Regionation for more information. hybrid Displays both raster and vector data at all times."},{"location":"services/wms/googleearth/features/kmlregionation/","title":"KML Regionation","text":"

                                                                                          Displaying vector features on Google Earth is a very powerful way of creating nicely-styled maps. However, it is not always optimal to display all features at all times. Displaying too many features can create an unsightly map, and can adversely affect Google Earth's performance. To combat this, GeoServer's KML output includes the ability to limit features based on certain criteria. This process is known as regionation. Regionation is active by default when using the superoverlay KML reflector mode.

                                                                                          "},{"location":"services/wms/googleearth/features/kmlregionation/#regionation-attributes","title":"Regionation Attributes","text":"

                                                                                          The most important aspect of regionation is to decide how to determine which features show up more prominently than others. This can be done either by geometry, or by attribute. One should choose the option that best exemplifies the relative \"importance\" of the feature. When choosing to regionate by geometry, only the larger lines and polygons will be displayed at higher zoom levels, with smaller ones being displayed when zooming in. When regionating by an attribute, the higher value of this attribute will make those features show up at higher zoom levels. (Choosing an attribute with a non-numeric value will be ignored, and will instead default to regionation by geometry.)

                                                                                          "},{"location":"services/wms/googleearth/features/kmlregionation/#regionation-strategies","title":"Regionation Strategies","text":"

                                                                                          Regionation strategies sets how to determine which features should be shown at any given time or zoom level. There are five types of regionation strategies:

                                                                                          Strategy Description best_guess (default) The actual strategy is determined by the type of data being operated on. If the data consists of points, the random strategy is used. If the data consists of lines or polygons, the geometry strategy is used. external-sorting Creates a temporary auxiliary database within GeoServer. It takes slightly extra time to build the index upon first request. native-sorting Uses the default sorting algorithm of the backend where the data is hosted. It is faster than external-sorting, but will only work with PostGIS datastores. geometry Externally sorts by length (if lines) or area (if polygons). random Uses the existing order of the data and does not sort.

                                                                                          In most cases, the best_guess strategy is sufficient.

                                                                                          "},{"location":"services/wms/googleearth/features/kmlregionation/#setting-regionation-parameters","title":"Setting Regionation Parameters","text":"

                                                                                          Regionation strategies and attributes are featuretype-specific, and therefore are set in the Layers editing page of the Web administration interface. This can be navigated to by selecting 'Layers' on the left sidebar.

                                                                                          "},{"location":"services/wms/googleearth/features/kmlscoring/","title":"KML Scoring","text":"

                                                                                          Note

                                                                                          KML scoring only applies when using the super-overlay mode refresh. See KML Super-Overlays for more information.

                                                                                          GeoServer can return KML in one of two forms. The first is as a number of placemark elements (vectors). Each placemark corresponds to a feature in the underlying dataset. This form only applies to vector datasets.

                                                                                          The second form is as an overlay (image). In this form the rendering is done by the GeoServer WMS and only the resulting graphic is sent to Google Earth. This is the only form available for raster datasets, but can be applied to vector datasets as well.

                                                                                          There are advantages to and disadvantages to each output mode when rendering vector data. Placemarks look nicer, but there can be performance problems with Google Earth if the data set is large. Overlays put less of a strain on Google Earth, but aren't as nice looking.

                                                                                          The following shows the same dataset rendered in Placemark form on the top and Overlay form on the bottom.

                                                                                          KML scoring is the process of determining whether to render features as rasters or as vectors.

                                                                                          "},{"location":"services/wms/googleearth/features/kmlscoring/#the-kmscore-attribute","title":"The kmscore attribute","text":"

                                                                                          GeoServer makes the determination on whether to render a layer as raster or vector based on how many features are in the data set and an attribute called kmscore. The kmscore attribute determines the maximum amount of vector features rendered. It is calculated by this formula:

                                                                                          maximum number of features = 10^(kmscore/15)\n

                                                                                          The following table shows the values of this threshold for various values of the kmscore parameter:

                                                                                          kmscore Maximum # of features 0 Force overlay/raster output 10 4 20 21 30 100 40 Approx. 450 50 (default) Approx. 2150 60 Approx. 10,000 70 Approx. 45,000 80 Approx. 200,000 90 Approx. 1,000,000 100 Force placemark/vector output

                                                                                          The syntax for specifying kmscore is:

                                                                                          kmscore=<value>\n

                                                                                          where <value> is an integer between 0 and 100. For example:

                                                                                          http://localhost:8080/geoserver/wms/kml?layers=topp:states&mode=refresh&kmscore=20\n

                                                                                          The kmscore attribute will be ignored if using a reflector mode other than refresh.

                                                                                          "},{"location":"services/wms/googleearth/features/kmlsuperoverlays/","title":"KML Super-Overlays","text":"

                                                                                          Super-overlays are a form of KML in which data is broken up into regions. This allows Google Earth to refresh/request only particular regions of the map when the view area changes. Super-overlays are used to efficiently publish large sets of data. (Please see Google's page on super-overlays for more information.)

                                                                                          GeoServer supports two types of super-overlays: raster and vector. With raster super-overlays, GeoServer intelligently produces imagery appropriate to the current zoom level and dynamically outputs new imagery when the zoom level changes. With vector super-overlays, feature data is requested for only the visible features and new features are dynamically loaded as necessary. Raster super-overlays require less resources on the client, but vector super-overlays have a higher output quality.

                                                                                          When using the KML Reflector, super-overlays are enabled by default, whether the data in question is raster or vector. For more information on the various options for KML super-overlay output, please see the page on the KML Reflector.

                                                                                          "},{"location":"services/wms/googleearth/features/kmlsuperoverlays/#raster-super-overlays","title":"Raster Super-Overlays","text":"

                                                                                          Consider this image, which is generated from GeoServer. When zoomed out, the data is at a small size.

                                                                                          When zooming in, the image grows larger, but since the image is at low resolution (originally designed to be viewed small), the quality degrades.

                                                                                          However, in a super-overlay, the KML document requests a new image from GeoServer of a higher resolution for that zoom level. As the new image is downloaded, the old image is replaced by the new image.

                                                                                          "},{"location":"services/wms/googleearth/features/kmlsuperoverlays/#raster-super-overlays-and-geowebcache","title":"Raster Super-Overlays and GeoWebCache","text":"

                                                                                          GeoServer implements super-overlays in a way that is compatible with the WMS Tiling Client Recommendation. Super-overlays are generated such that the tiles of the super-overlay are the same tiles that a WMS tiling client would request. One can therefore use existing tile caching mechanisms and reap a potentially large performance benefit.

                                                                                          The easiest way to tile cache a raster super overlay is to use GeoWebCache which is built into GeoServer:

                                                                                          http://GEOSERVER_URL/gwc/service/kml/<layername>.<imageformat>.kmz\n

                                                                                          where GEOSERVER_URL is the URL of your GeoServer instance.

                                                                                          "},{"location":"services/wms/googleearth/features/kmlsuperoverlays/#vector-super-overlays","title":"Vector Super-Overlays","text":"

                                                                                          GeoServer can include the feature information directly in the KML document. This has lots of benefits. It allows the user to select (click on) features to see descriptions, toggle the display of individual features, as well as have better rendering, regardless of zoom level. For large datasets, however, the feature information can take a long time to download and use a lot of client-side resources. Vector super-overlays allow the client to only download part of a dataset, and request more features as necessary.

                                                                                          Vector super-overlays can use the process of KML Regionation to organize features into a hierarchy. The regionation process can operate in a variety of modes. Most of the modes require a \"regionation attribute\" which is used to determine which features should be visible at a particular zoom level. Please see the KML Regionation page for more details.

                                                                                          "},{"location":"services/wms/googleearth/features/kmlsuperoverlays/#vector-super-overlays-and-geowebcache","title":"Vector Super-Overlays and GeoWebCache","text":"

                                                                                          As with raster super-overlays, it is possible to cache vector super-overlays using GeoWebCache. Below is the syntax for generating a vector super-overlay KML document via GeoWebCache:

                                                                                          http://GEOSERVER_URL/gwc/service/kml/<layername>.kml.kmz\n

                                                                                          where GEOSERVER_URL is the URL of your GeoServer instance.

                                                                                          Unlike generating a super-overlay with the standard KML Reflector, it is not possible to specify the regionation properties as part of the URL. These parameters must be set in the Layers configuration which can be navigated to by clicking on 'Layers' in the left hand sidebar and then selecting your vector layer.

                                                                                          "},{"location":"services/wms/googleearth/features/togglingplacemarks/","title":"Toggling Placemarks","text":""},{"location":"services/wms/googleearth/features/togglingplacemarks/#vector-placemarks","title":"Vector Placemarks","text":"

                                                                                          When GeoServer generates KML for a vector dataset, it attaches information from the data to each feature that is created. When clicking on a vector feature, a pop-up window is displayed. This is called a placemark. By default this is a simple list which displays attribute data, although this information can be customized using Freemarker templates.

                                                                                          If you would like this information not to be shown when a feature is clicked (either for security reasons, or simply to have a cleaner user interface), it is possible to disable this functionality. To do so, use the kmattr parameter in a KML request to turn off attribution.

                                                                                          The syntax for kmattr is as follows:

                                                                                          format_options=kmattr:[true|false]\n

                                                                                          Note that kmattr is a \"format option\", so the syntax is slightly different from the usual key-value pair. For example:

                                                                                          http://localhost:8080/geoserver/wms/kml?layers=topp:states&format_options=kmattr:false\n
                                                                                          "},{"location":"services/wms/googleearth/features/togglingplacemarks/#raster-placemarks","title":"Raster Placemarks","text":"

                                                                                          Unlike vector features, where the placemark is enabled by default, placemarks are disabled by default with raster images of features. To enable this feature, you can use the kmplacemark format option in your KML request. The syntax is similar to the kmattr format option specified above:

                                                                                          format_options=kmplacemark:[true|false]\n

                                                                                          For example, using the KML reflector, the syntax would be:

                                                                                          http://localhost:8080/geoserver/wms/kml?layers=topp:states&format_options=kmplacemark:true\n
                                                                                          "},{"location":"services/wms/googleearth/tutorials/","title":"Tutorials","text":"
                                                                                          • KML Placemark Templates
                                                                                          • Heights Templates
                                                                                          • Time
                                                                                          • Super-Overlays and GeoWebCache
                                                                                          "},{"location":"services/wms/googleearth/tutorials/superoverlaysgwc/","title":"Super-Overlays and GeoWebCache","text":""},{"location":"services/wms/googleearth/tutorials/superoverlaysgwc/#overview","title":"Overview","text":"

                                                                                          This tutorial explains how to use GeoWebCache (GWC) to enhance the performance of super-overlays in Google Earth. For more information please see the page on KML Super-Overlays

                                                                                          Conveniently GeoWebCache can generate super-overlays automatically. With the standalone GeoWebCache it takes minimal amount of configuration. Please see the GeoWebCache documentation for more information on the standalone version of GeoWebCache.

                                                                                          We are going to use the plug in version of GeoWebCache where there is no configuration need. For this tutorial we are also using the topp:states layer. Using the GeoWebCache plug in with super-overlays

                                                                                          To access GWC from GeoServer go to http://localhost:8080/geoserver/gwc/demo/. This should return a layer list of similar to below.

                                                                                          To use a super-overlay in GeoWebCache select the KML (vector) option display for each layer. Lets select topp:states.The url would be http://localhost:8080/geoserver/gwc/service/kml/topp:states.kml.kmz After doing so you will be presented with a open option dialog, choose Google Earth.

                                                                                          When Google Earth finishes loading you should be viewing a the topp:states layers.

                                                                                          "},{"location":"services/wms/googleearth/tutorials/heights/heights/","title":"Heights Templates","text":""},{"location":"services/wms/googleearth/tutorials/heights/heights/#introduction","title":"Introduction","text":"

                                                                                          Height Templates in KML allow you to use an attribute of your data as the 'height' of features in Google Earth.

                                                                                          Note

                                                                                          This tutorial assumes that GeoServer is running on http://localhost:8080.

                                                                                          "},{"location":"services/wms/googleearth/tutorials/heights/heights/#getting-started","title":"Getting Started","text":"

                                                                                          For the purposes of this tutorial, you just need to have GeoServer with the release configuration, and Google Earth installed. Google Earth is available for free from <http://earth.google.com/ <http://earth.google.com/>`_.

                                                                                          "},{"location":"services/wms/googleearth/tutorials/heights/heights/#step-one","title":"Step One","text":"

                                                                                          By default GeoServer renders all features with 0 height, so they appear to lay flat on the world's surface in Google Earth.

                                                                                          To view the topp:states layer (packaged with all releases of GeoServer) in Google Earth, the easiest way is to use a network link. In Google Earth, under Places, right-click on Temporary Places, and go to Add \u2192 Network Link. In the dialog box, fill in topp:states as the Name, and the following URL as the Link:

                                                                                          http://localhost:8080/geoserver/wms/reflect?layers=topp:states&format=application/vnd.google-earth.kml+xml\n

                                                                                          topp:states in Google Earth

                                                                                          "},{"location":"services/wms/googleearth/tutorials/heights/heights/#step-two","title":"Step Two","text":"

                                                                                          An interesting value to use for the height would be the population of each state (so that more populated states appear taller on the map). We can do this by creating a file called height.ftl in the GeoServer data directory under workspaces/topp/states_shapefile/states. To set the population value, we enter the following text inside this new file:

                                                                                          ${PERSONS.value}\n

                                                                                          This uses the value of the PERSONS attribute as the height for each feature. To admire our handiwork, we can refresh our view by right-clicking on our temporary place (called topp:states) and selecting Refresh:

                                                                                          Height by Population

                                                                                          "},{"location":"services/wms/googleearth/tutorials/heights/heights/#step-three","title":"Step Three","text":"

                                                                                          Looking at our population map, we see that California dwarfs the rest of the nation, and in general all of the states are too tall for us to see the heights from a convenient angle. In order to scale things down to a more manageable size, we can divide all height values by 100. Just change the template we wrote earlier to read:

                                                                                          ${PERSONS.value / 100}\n

                                                                                          Refreshing our view once again, we see that our height field has disappeared. Looking at the GeoServer log (in the data directory under logs/geoserver.log) we see something like:

                                                                                          Caused by: freemarker.core.NonNumericalException: Error on line 1, column 3 in height.ftl\nExpression PERSONS.value is not numerical\n

                                                                                          However, we know that the PERSONS field is numeric, even if it is declared in the shapefile as a string value. To force a conversion, we can append ?number, like so:

                                                                                          ${PERSONS.value?number / 100}\n

                                                                                          One final Refresh brings us to a nicely sized map of the US:

                                                                                          Scaled Height

                                                                                          "},{"location":"services/wms/googleearth/tutorials/heights/heights/#step-four","title":"Step Four","text":"

                                                                                          There are still a couple of tweaks we can make. The default is to create a 'solid' look for features with height, but Google Earth can also create floating polygons that are disconnected from the ground. To turn off the 'connect to ground' functionality, add a format option called 'extrude' whose value is 'false'. That is, change the Link in the Network Link to be:

                                                                                          http://localhost:8080/geoserver/wms/reflect?layers=topp:states&format=application/vnd.google-earth.kml%2Bxml&format_options=extrude:false\n

                                                                                          We also have a few options for how Google Earth interprets the height field. By default, the height is interpreted as relative to the ground, but we can also set the heights relative to sea level, or to be ignored (useful for reverting to the 'flat' look without erasing your template). This is controlled with a format option named altitudeMode, whose values are summarized below.

                                                                                          altitudeMode Purpose altitudeMode Interpret height as relative to ground level absolute Interpret height as relative to sea level clampToGround Ignore height entirely"},{"location":"services/wms/googleearth/tutorials/kmlplacemark/","title":"KML Placemark Templates","text":""},{"location":"services/wms/googleearth/tutorials/kmlplacemark/#introduction","title":"Introduction","text":"

                                                                                          In KML a \"Placemark\" is used to mark a position on a map, often visualized with a yellow push pin. A placemark can have a \"description\" which allows one to attach information to it. Placemark descriptions are nothing more than an HTML snippet and can contain anything we want it to.

                                                                                          By default GeoServer produces placemark descriptions which are HTML tables describing all the attributes available for a particular feature in a dataset. In the following image we see the placemark description for the feature representing Idaho state:

                                                                                          The default placemark

                                                                                          This is great, but what about if one wanted some other sort of information to be conveyed in the description. Or perhaps one does not want to show all the attributes of the dataset. The answer is Templates!!

                                                                                          A template is more or less a way to create some output.

                                                                                          "},{"location":"services/wms/googleearth/tutorials/kmlplacemark/#getting-started","title":"Getting Started","text":"

                                                                                          First let us get set up. To complete the tutorial you will need the following:

                                                                                          • A GeoServer install
                                                                                          • A text editor

                                                                                          And thats it. For this tutorial we will assume that GeoServer is running the same configuration ( data directory ) that it does out of the box.

                                                                                          "},{"location":"services/wms/googleearth/tutorials/kmlplacemark/#hello-world","title":"Hello World","text":"

                                                                                          Ok, time to get to creating our first template. We will start off an extremely simple template which, you guessed it, creates the placemark description \"Hello World!\". So lets go.

                                                                                          1. Using the text editor of your choice start a new file called description.ftl

                                                                                          2. Add the following content to the file:

                                                                                            Hello World!\n
                                                                                          3. Save the file in the workspaces/topp/states_shapefile/states directory of your \"data directory\". The data directory is the location of all the GeoServer configuration files. It is normally pointed to by the environment variable GEOSERVER_DATA_DIR.

                                                                                          4. Start GeoServer is it is not already running.

                                                                                          And thats it. We can now test out our template by adding the following network link in google earth:

                                                                                          http://localhost:8080/geoserver/wms/kml?layers=states\n

                                                                                          And voila. Your first template

                                                                                          Hello World template.

                                                                                          Refreshing Templates: One nice aspect of templates is that they are read upon every request. So one can simply edit the template in place and have it picked up by GeoServer as soon as the file is saved. So when after editing and saving a template simply \"Refresh\" the network link in Google Earth to have the new content picked up.

                                                                                          Refresh Template

                                                                                          As stated before template descriptions are nothing more than html. Play around with description.ftl and add some of your own html. Some examples you may want to try:

                                                                                          1. A simple link to the homepage of your organization:
                                                                                            Provided by the <a href=\"http://topp.openplans.org\">The Open Planning Project</a>.\n

                                                                                          Homepage of Topp

                                                                                          Homepage of Topp

                                                                                          1. The logo of your organization:
                                                                                            <img src=\"http://topp.openplans.org/images/logo.jpg\"/>\n

                                                                                          Logo of Topp

                                                                                          Logo of Topp

                                                                                          The possibilities are endless. Now this is all great and everything but these examples are some what lacking in that the content is static. In the next section we will create more realistic template which actually access some the attributes of our data set.

                                                                                          "},{"location":"services/wms/googleearth/tutorials/kmlplacemark/#data-content","title":"Data Content","text":"

                                                                                          The real power of templates is the ability to easily access content, in the case of features this content is the attributes of features.In a KML placemark description template, there are a number of \"template variables\" available.

                                                                                          • The variable \"fid\", which corresponds to the id of the feature
                                                                                          • The variable \"typeName\", which corresponds to the name of the type of the feature
                                                                                          • A sequence of variables corresponding to feature attributes, each named the same name as the attribute

                                                                                          So with this knowledge in hand let us come up with some more examples:

                                                                                          Simple fid/typename access:

                                                                                          This is feature ${fid} of type ${typeName}.\n

                                                                                          This is a feature of 3.1 of type states.

                                                                                          FID

                                                                                          Access to the values of two attributes named STATE_NAME, and PERSONS:

                                                                                          This is ${STATE_NAME.value} state which has a population of ${PERSONS.value}.\n

                                                                                          ID This is Idaho state which has a population of 1.006.749.

                                                                                          Attributes

                                                                                          "},{"location":"services/wms/googleearth/tutorials/kmlplacemark/#attribute-variables","title":"Attribute Variables","text":"

                                                                                          A feature attribute a \"complex object\" which is made up of three parts:

                                                                                          1. A value, given as a default string representation of the actual attribute value feasible to be used directly
                                                                                          2. A rawValue, being the actual value of the attribute, to allow for more specialized customization (for example, ${attribute.value?string(\"Enabled\", \"Disabled\")} for custom representations of boolean attributes, etc).
                                                                                          3. A type, each of which is accessible via ${<attribute_name>.name}, ${<attribute_name>.value}, ${<attribute_name>.rawValue}, ${<attribute_name>.type} respectively. The other variables: fid, and typeName and are \"simple objects\" which are available directly.
                                                                                          "},{"location":"services/wms/googleearth/tutorials/kmlplacemark/#wms-demo-example","title":"WMS Demo Example","text":"

                                                                                          We will base our final example off the \"WMS Example\" demo which ships with GeoServer. To check out the demo visit http://localhost:8080/geoserver/popup_map/index.html in your web browser.

                                                                                          You will notice that hovering the mouse over one of the points on the map displays an image specific to that point. Let us replicate this with a KML placemark description.

                                                                                          1. In the featureTypes/DS_poi_poi directory of the geoserver data directory create the following template:

                                                                                            <img src=\"http://localhost:8080/geoserver/popup_map/${THUMBNAIL.value}\"/>\n
                                                                                          2. Add the following network link in Google Earth:

                                                                                            http://localhost:8080/geoserver/wms/kml?layers=tiger:poi\n

                                                                                          Poi.4

                                                                                          WMS Example

                                                                                          "},{"location":"services/wms/googleearth/tutorials/time/time/","title":"Time","text":"

                                                                                          Warning

                                                                                          The screenshots on this tutorial have not yet been updated for the 2.0.x user interface. But most all the rest of the information should be valid, and the user interface is roughly the same, but a bit more easy to use.

                                                                                          "},{"location":"services/wms/googleearth/tutorials/time/time/#getting-started","title":"Getting Started","text":"

                                                                                          For this tutorial we will using a Shapefile which contains information about the number of Internet users in the countries of Western Europe for a rang of years.

                                                                                          1. Download and unzip inet_weu.zip
                                                                                          2. Configure GeoServer to serve the Shapefile inet_weu.zip. (A tutorial is available Publishing a shapefile.)
                                                                                          3. Add the SLD \"inet_weu.sld to GeoServer. ( A tutorial is available for Styling_)
                                                                                          4. Set the style of the feature type added in step 2 to the style added in step 3

                                                                                          Style

                                                                                          "},{"location":"services/wms/googleearth/tutorials/time/time/#checking-the-setup","title":"Checking the Setup","text":"

                                                                                          If all is configured properly you should be able to navigate to http://localhost:8080/geoserver/wms/kml?layers=topp:inet_weu&format=openlayers&bbox=-33.780,26.266,21.005,56.427 and see the following map:

                                                                                          Setup

                                                                                          "},{"location":"services/wms/googleearth/tutorials/time/time/#creating-the-template","title":"Creating the Template","text":"

                                                                                          Next we will create a template which allows us to specify the temporal aspects of the dataset. The schema of our dataset looks like:

                                                                                          INET_P100n Number of internet users per 100 people NAME Name of country RPT_YEAR Year Geometry Polygon representing the country

                                                                                          The temporal attribute is RPT_YEAR and is the one that matters to us. Ok, time to create the template.

                                                                                          1. In your text editor of choice, create a new text file called time.ftl.
                                                                                          2. Add the following text:
                                                                                          ${RPT_YEAR.value?date('yyyy')}\n
                                                                                          1. Save the file to the <GEOSERVER_DATA_DIR>/workspaces/topp/inet_weu_shapefile/inet_weu directory. Where <GEOSERVER_DATA_DIR> is the location of the \"data directory\" of your GeoServer installation. Usually pointed to via the GEOSERVER_DATA_DIR environment variable.

                                                                                          See the ref:references section for more information about specifying a date format.

                                                                                          "},{"location":"services/wms/googleearth/tutorials/time/time/#trying-it-out","title":"Trying it Out","text":"

                                                                                          Ok time to try it out.

                                                                                          1. Navigate to http://localhost:8080/geoserver/wms/kml?layers=inet_weu&legend=true. This should cause Google Earth to open.

                                                                                          Google Earth

                                                                                          1. In Google Earth, adjust the time bar so that it captures a time interval that is approximately 1 year wide

                                                                                          Google Earth Time Bar

                                                                                          1. Slide the time bar forward in time and notice how the polygon colors change

                                                                                          Sliding the Time Bar

                                                                                          "},{"location":"services/wms/googleearth/tutorials/time/time/#references","title":"References","text":""},{"location":"services/wms/googleearth/tutorials/time/time/#specifying-a-date-format","title":"Specifying a Date Format","text":"

                                                                                          When setting up a time template for your own dataset the most important issue is the format of your temporal data. It may or may not be in a format in which GeoServer can read directly. You can check if the date/time format can be used directly by GeoServer by using the following time template. This is an example time template file (time.ftl) file without explicit formatting.

                                                                                          ${DATETIME_ATTRIBUTE_NAME.value}\n

                                                                                          While GeoServer will try its best to parse the data there are cases in which your data is in a format which it cannot parse. When this occurs it is necessary to explicitly specify the format. Luckily Freemarker provides us with functionality to do just this.

                                                                                          Consider the date time 12:30 on January 01, 2007 specified in the following format: 01?01%2007&12$30!00. When creating the template we need to explicitly tell Freemarker the format the date time is in with the datetime function. This is an example time template file (time.ftl) file with explicit formatting: :

                                                                                          ${DATETIME_ATTRIBUTE_NAME.value?datetime(\"M?d%y&H:m:s\")}\n

                                                                                          The process is similar for dates (no time). The date 01?01%2007 would be specified in a template with explicit formatting:

                                                                                          ${DATETIME_ATTRIBUTE_NAME.value?date(\"M?d%y\")}\n

                                                                                          So when must you specify the date format in this manner? The following table illustrates the date formats that GeoServer can understand. Note that the '-' character can be one of any of the following characters: '/' (forward slash), ' ' (space), '.' (period), ',' (comma)

                                                                                          Date Format Example yyyy-MM-dd 2007-06-20 yyyy-MMM-dd 2007-Jun-20 MM-dd-yyyy 06-20-2007 MMM-dd-yyyy Jun-20-2007 dd-MM-yyyy 20-06-2007 dd-MMM-yyyy 20-Jun-2007

                                                                                          The set of date time formats which GeoServer can be understand is formed by appending the timestamp formats hh:mm and hh:mm:ss to the entries in the above table:

                                                                                          DateTime Format Example yyyy-MM-dd hh:mm 2007-06-20 12:30 yyyy-MMM-dd hh:mm 2007-Jun-20 12:30 yyyy-MM-dd hhss 2007-06-20 12:30:00 yyyy-MMM-dd hhss 2007-Jun-20 12:30:00

                                                                                          Warning

                                                                                          Setting the Timezone

                                                                                          Be aware that the KML output for date time formats will reflect the timezone of the java virtual machine, which can be set using the user.timezone parameter in the startup script. For example, the following command starts GeoServer using the Coordinated Universal Time (UTC) timezone.

                                                                                          exec \"$_RUNJAVA\" -DGEOSERVER_DATA_DIR=\"$GEOSERVER_DATA_DIR\"

                                                                                          -Djava.awt.headless=true -DSTOP.PORT=8079 -Duser.timezone=UTC -DSTOP.KEY=geoserver -jar start.jar

                                                                                          If the timezone is not set, it will default to the timezone of the operating system.

                                                                                          "},{"location":"services/wms/googleearth/tutorials/time/time/#specifying-a-date-range","title":"Specifying a Date Range","text":"

                                                                                          In the above example a single time stamp is output for the dataset. GeoServer also supports specifying date ranges via a template. The syntax for ranges is:

                                                                                          <begin>||<end>\n

                                                                                          Where begin is the first date in the range, end is the last date in the range, and || is the delimiter between the two. As an example:

                                                                                          01/01/2007||06/01/2007\n

                                                                                          Would the date range starting at January 1, 2007 and ending June 1, 2007. Date ranges can also be open ended:

                                                                                          ||06/01/2007\n06/01/2007||\n

                                                                                          The first date specifies a date range where the beginning is open-ended. The second specifies a date range where the end is open-ended.

                                                                                          "},{"location":"services/wmts/","title":"Web Map Tile Service (WMTS)","text":"

                                                                                          This section describes the Web Map Tile Service (WMTS).

                                                                                          • WMTS settings
                                                                                          "},{"location":"services/wmts/webadmin/","title":"WMTS settings","text":"

                                                                                          This page details the configuration options for WMTS in the web administration interface.

                                                                                          WMTS configuration options

                                                                                          "},{"location":"services/wmts/webadmin/#workspace","title":"Workspace","text":"

                                                                                          Select workspace empty to configure global WMTS settings.

                                                                                          See the section on Workspace Services to override settings used by WMTS Virtual Services.

                                                                                          "},{"location":"services/wmts/webadmin/#service-metadata","title":"Service Metadata","text":"

                                                                                          For a description of the WMTS service, see the section on Service Metadata.

                                                                                          "},{"location":"services/wps/","title":"Web Processing Service (WPS)","text":"

                                                                                          Web Processing Service (WPS) is an OGC service for the publishing of geospatial processes, algorithms, and calculations. The WPS service is available as an extension for GeoServer providing an execute operation for data processing and geospatial analysis.

                                                                                          WPS is not a part of GeoServer by default but is available as an extension.

                                                                                          The main advantage of GeoServer WPS over a standalone WPS is direct integration with other GeoServer services and the data catalog. This means that it is possible to create processes based on data served in GeoServer, as opposed to sending the entire data source in the request. It is also possible for the results of a process to be stored as a new layer in the GeoServer catalog. In this way, WPS acts as a full remote geospatial analysis tool, capable of reading and writing data from and to GeoServer.

                                                                                          For the official WPS 1.0.0 specification, see OGC Web Processing Service 05-007r7.

                                                                                          • Installing the WPS extension
                                                                                          • WPS Operations
                                                                                          • WPS Service page
                                                                                          • WPS Security and input limits
                                                                                          • WPS Request Builder
                                                                                          • Process Cookbook
                                                                                          • Hazelcast based process status clustering
                                                                                          "},{"location":"services/wps/administration/","title":"WPS Service page","text":"

                                                                                          The Web Processing Service (WPS) page supports the basic metadata for the service, as well as service specific settings

                                                                                          "},{"location":"services/wps/administration/#service-metadata","title":"Service Metadata","text":"

                                                                                          The service metadata section is common among all services. See the section on Service Metadata.

                                                                                          "},{"location":"services/wps/administration/#execution-and-resource-management-options","title":"Execution and resource management options","text":"

                                                                                          Execution settings:

                                                                                          • Connection timeout: the number of seconds the WPS will wait before giving up on a remote HTTP connection used to retrieve complex inputs
                                                                                          • Maximum synchronous executions run parallel: the maximum number of synchronous processes that will run in parallel at a given time. The others will be queued.
                                                                                          • Maximum execution time for synchronous requests: the maximum time a synchronous process is allowed executing. Processes running in synchronous mode will have to complete execution within the set time limit, or they will be dismissed automatically. These requests have the client waiting for a response on a HTTP connection, so choose a relatively short time (e.g., 60 seconds)
                                                                                          • Maximum queue and execution time for synchronous requests: the maximum time a process is allowed in the queue and executing. Processes running in synchronous mode will have to complete within the set time limit, or they will be dismissed automatically. These requests have the client waiting for a response on a HTTP connection, so choose a relatively short time (e.g., 60 seconds)
                                                                                          • Maximum asynchronous executions run parallel: the maximum number of asynchronous processes that will run in parallel at a given time. The others will be queued
                                                                                          • Maximum execution time for asynchronous requests: the maximum time an asysynchronous process is allowed executing. Processes running in asynchronous mode will have to complete within the set time limit, or they will be dismissed automatically
                                                                                          • Maximum queue and execution time for asynchronous requests: the maximum time an asysynchronous process is allowed in the queue and executing. Processes running in asynchronous mode will have to complete within the set time limit, or they will be dismissed automatically

                                                                                          Resource settings:

                                                                                          • Resource expiration timeout: number of seconds the result of a asynchronous execution will be kept available on disk for user to retrieve. Once this time is expired these resources will be eligible for clearing (which happens at regular intervals).
                                                                                          • Resource storage directory: where on disk the input, temporary and output resources associated to a certain process will be kept. By default it will be the temp/wps directory inside the GeoServer data directory
                                                                                          • External output directory: Some processes allow execution outputs to be stored in an external output directory (not subject to Resource expiration timeout). To enable this functionality provide a path to external storage with the understanding that you are responsible for managing the contents of this folder. Leave empty to disable writing outside of the resource storage.
                                                                                          "},{"location":"services/wps/administration/#process-status-page","title":"Process status page","text":"

                                                                                          The process status page, available in the \"About & Status\" section, reports about running, and recently completed, processes:

                                                                                          The table contains several information bits:

                                                                                          • S/A: synchronous or asynchronous execution
                                                                                          • Node: the name of the machine running the process (important in a clustered environment)
                                                                                          • User: user that started the execution
                                                                                          • Process name: the main process being run (chained processes will not appear in this table)
                                                                                          • Created: when the process got created
                                                                                          • Phase: the current phase in the process lifecycle
                                                                                          • Progress: current progress
                                                                                          • Task: what the process is actually doing at the moment

                                                                                          In GeoServer there are the following execution phases:

                                                                                          • QUEUED: the process is waiting to be executed
                                                                                          • RUNNING: the process is either retrieving and parsing the inputs, computing the results, or writing them out
                                                                                          • FAILED: the process execution terminated with a failure
                                                                                          • SUCCESS: the process execution terminated with a success
                                                                                          • DISMISSING: the process execution is being dismissed, depending on the process nature this might take some time, or be instantaneous

                                                                                          All executions listed in the table can be selected, and then dismissed using the \"Dismiss selected processes\" link at the top of the table. Unlike the \"Dismiss\" vendor operation this UI allows to also dismiss synchronous processes. Once the process dismissal is complete, the process execution will disappear from the table (in accordance with the WPS specification).

                                                                                          Completed processes can also be dismissed, this will cause all on disk resources associated to the process to be removed immediately, instead of waiting for the regular time based expiration.

                                                                                          "},{"location":"services/wps/hazelcast-clustering/","title":"Hazelcast based process status clustering","text":"

                                                                                          Starting with version 2.7.0 GeoServer has a new WPS extension point allowing GeoServer nodes in the same cluster to share the status of current WPS requests. This is particularly important for asynchronous ones, as the client polling for the progress/results might not be hitting the same node that's currently running the requests.

                                                                                          The Hazelcast based status sharing module leverages the Hazelcast library to share the information about the current process status using a replicated map.

                                                                                          "},{"location":"services/wps/hazelcast-clustering/#installation","title":"Installation","text":"

                                                                                          The installation of the module follows the usual process for most extensions:

                                                                                          • Stop GeoServer
                                                                                          • Unpack the contents of gs-wps-hazelcast-status.zip into the geoserver/WEB-INF/lib folder
                                                                                          • Restart GeoServer
                                                                                          "},{"location":"services/wps/hazelcast-clustering/#configuration","title":"Configuration","text":"

                                                                                          The module does not require any configuration in case the default behavior is suitable for the deploy environment.

                                                                                          By default, the module will use multicast messages to locate other nodes in the same cluster and will automatically start sharing information about the process status with them.

                                                                                          In case this is not satisfactory, a hazelcast.xml file can be created/edited in the root of the GeoServer data directory to modify the network connection methods.

                                                                                          The file is not using a GeoServer specific syntax, it's instead a regular Hazelcast configuration file with a simple distributed map declaration:

                                                                                          <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<!--\nConfigure Hazelcast for clustering GeoServer's WPS process status.\nFor more information, see:\nhttps://docs.hazelcast.com/hazelcast/5.3/configuration/configuring-declaratively\n-->\n<hazelcast xmlns=\"http://www.hazelcast.com/schema/config\"\n           xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\"\n           xsi:schemaLocation=\"http://www.hazelcast.com/schema/config\n                               https://hazelcast.com/schema/config/hazelcast-config-5.3.xsd\">\n  <cluster-name>gsWpsCluster</cluster-name>\n\n  <!-- \n     Make Hazelcast use log4j2 just like GeoServer. Remember to add\n     a Logger for com.hazelcast with the appropriate logging level\n     in the geoserver logging configuration to see Hazelcast log messages\n  -->\n  <properties>\n    <property name=\"hazelcast.logging.type\">log4j2</property>\n  </properties>\n\n  <!-- Network section, by default it enables multicast, tune it to use tcp in case \n    multicast is not allowed, and list the nodes that make up a reasonable core of the \n    cluster (e.g., machines that will never be all down at the same time) -->\n  <network>\n    <port auto-increment=\"true\">5701</port>\n    <join>\n      <multicast enabled=\"true\">\n        <multicast-group>224.2.2.3</multicast-group>\n        <multicast-port>54327</multicast-port>\n      </multicast>\n      <tcp-ip enabled=\"false\">\n        <interface>127.0.0.1</interface>\n      </tcp-ip>\n      <aws enabled=\"false\">\n        <access-key>my-access-key</access-key>\n        <secret-key>my-secret-key</secret-key>\n        <region>us-east-1</region>\n      </aws>\n    </join>\n  </network>\n\n\n\n  <!-- The WPS status map -->\n  <map name=\"wpsExecutionStatusMap\">\n    <indexes>\n      <!-- Add indexes to support the two most common queries -->\n      <index type=\"HASH\">\n        <attributes>\n          <attribute>executionId</attribute>\n        </attributes>\n      </index>\n      <index type=\"SORTED\">\n        <attributes>\n          <attribute>completionTime</attribute>\n        </attributes>\n      </index>\n    </indexes>\n  </map>\n</hazelcast>\n

                                                                                          In case a TCP based configuration is desired, one just needs to disable the multicast one, enable the tcp-ip one, and add a list of interface addresses in it that will form the core of the cluster. Not all nodes in the cluster need to be listed in said section, but a list long enough to ensure that not all the nodes in the list might go down at the same time: as long as at least one of said nodes lives, the cluster will maintain its integrity.

                                                                                          "},{"location":"services/wps/install/","title":"Installing the WPS extension","text":"

                                                                                          The WPS module is not a part of GeoServer core, but instead must be installed as an extension. To install WPS:

                                                                                          1. Navigate to the GeoServer download page.

                                                                                          2. Find the page that matches the exact version of GeoServer you are running.

                                                                                            Warning

                                                                                            Be sure to match the version of the extension with that of GeoServer, otherwise errors will occur.

                                                                                          3. Download the WPS extension: wps

                                                                                            The download link for WPS will be in the Extensions section under Other.

                                                                                          4. Extract the files in this archive to the WEB-INF/lib directory of your GeoServer installation.

                                                                                          5. Restart GeoServer.

                                                                                          After restarting, load the Web administration interface. If the extension loaded properly, you should see an extra entry for WPS in the Service Capabilities column. If you don't see this entry, check the logs for errors.

                                                                                          A link for the WPS capabilities document will display if installed properly

                                                                                          "},{"location":"services/wps/install/#configuring-wps","title":"Configuring WPS","text":"

                                                                                          WPS processes are subject to the same feature limit as the WFS service. The limit applies to process input, so even processes which summarize data and return few results will be affected if applied to very large datasets. The limit is set on the WFS settings Admin page.

                                                                                          Warning

                                                                                          If the limit is encountered during process execution, no error is given. Any results computed by the process may be incomplete

                                                                                          "},{"location":"services/wps/operations/","title":"WPS Operations","text":"

                                                                                          The WPS 1.0.0 standard defines three operations for the discovery and execution of geospatial processes, and GeoServer extends these with two further vendor or pseudo-operations. The operations are:

                                                                                          Operation Description GetCapabilities Retrieves details of the service offering, including service metadata and metadata describing the available processes DescribeProcess Retrieves a description of a WPS process available through the service Execute A request to perform the process with specified input values and required output data items Dismiss (vendor extension) Used to cancel the execution of a process GetExecutions (vendor extension) Retrieves a list of the current Execution Statuses"},{"location":"services/wps/operations/#wps_getcaps","title":"GetCapabilities","text":"

                                                                                          The GetCapabilities operation requests details of the service offering, including service metadata and metadata describing the available processes. The response is an XML document called the capabilities document.

                                                                                          The required parameters, as in all OGC GetCapabilities requests, are service=WPS, version=1.0.0 and request=GetCapabilities.

                                                                                          An example of a GetCapabilities request is:

                                                                                          http://localhost:8080/geoserver/ows?\n  service=WPS&\n  version=1.0.0&\n  request=GetCapabilities\n
                                                                                          "},{"location":"services/wps/operations/#describeprocess","title":"DescribeProcess","text":"

                                                                                          The DescribeProcess operation requests a description of a WPS process available through the service.

                                                                                          The parameter identifier specifies the process to describe. Multiple processes can be requested, separated by commas (for example, identifier=JTS:buffer,gs:Clip). At least one process must be specified.

                                                                                          Note

                                                                                          As with all OGC parameters, the keys (request, version, etc) are case-insensitive, and the values (GetCapabilities, JTS:buffer, etc.) are case-sensitive. GeoServer is generally more relaxed about case, but it is best to follow the specification.

                                                                                          The response is an XML document containing metadata about each requested process, including the following:

                                                                                          • Process name, title and abstract
                                                                                          • For each input and output parameter: identifier, title, abstract, multiplicity, and supported datatype and format

                                                                                          An example request for the process JTS:buffer is:

                                                                                          http://localhost:8080/geoserver/ows?\n  service=WPS&\n  version=1.0.0&\n  request=DescribeProcess&\n  identifier=JTS:buffer\n

                                                                                          The response XML document contains the following information:

                                                                                          +--------------------+-------------------------------------------------------------------------------------------------------------------------------------------------+ | Title | \"Buffers a geometry using a certain distance\" | +--------------------+-------------------------------------------------------------------------------------------------------------------------------------------------+ | Inputs | geom: \"The geometry to be buffered\" (geometry, mandatory) | | | | | | distance: \"The distance (same unit of measure as the geometry)\" (double, mandatory) | | | | | | quadrant segments: \"Number of quadrant segments. Use > 0 for round joins, 0 for flat joins, < 0 for mitred joins\" (integer, optional) | | | | | | capstyle: \"The buffer cap style, round, flat, square\" (literal value, optional) | +--------------------+-------------------------------------------------------------------------------------------------------------------------------------------------+ | Output formats | One of the GeoServer supported formats for Geometry encoding | +--------------------+-------------------------------------------------------------------------------------------------------------------------------------------------+

                                                                                          In general, GeoServer processes use complex objects as inputs and objects, like geometries, feature collections and raster data.

                                                                                          The formats available for input and output of each of those complex processes are commonly managed by Process Parameter IO classes, generic encoders/decoders that are attached to each process by the WPS machinery.

                                                                                          In the core of GeoServer WPS, the following PPIOs are available:

                                                                                          • For geometries, GML 2 and 3, GeoJSON, Well Known Text.
                                                                                          • For feature collections, GML2 and 3, GeoJSON, Zipped shapefile, and KML.
                                                                                          • For rasters, GeoTIFF, PNG, JPEG.

                                                                                          The set of PPIOs can be extended by installing plugins. For example, the DXF extension<dxf> comes with a PPIO that can encode feature collections in DXF: when plugged in, most processes generating feature collections in output will offer to encode them also in DXF.

                                                                                          "},{"location":"services/wps/operations/#execute","title":"Execute","text":"

                                                                                          The Execute operation is a request to perform the process with specified input values and required output data items. The request may be made as either a GET URL, or a POST with an XML request document. Because the request has a complex structure, the POST form is more typically used.

                                                                                          The inputs and outputs required for the request depend on the process being executed. GeoServer provides a wide variety of processes to process geometry, features, and coverage data. For more information see the section Process Cookbook.

                                                                                          Below is an example of a Execute POST request. The example process (JTS:buffer) takes as input a geometry geom (in this case the point POINT(0 0)), a distance (with the value 10), a quantization factor quadrantSegments (here set to be 1), and a capStyle (specified as flat). The <ResponseForm> element specifies the format for the single output result to be GML 3.1.1.

                                                                                          <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<wps:Execute version=\"1.0.0\" service=\"WPS\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xmlns=\"http://www.opengis.net/wps/1.0.0\" xmlns:wfs=\"http://www.opengis.net/wfs\" xmlns:wps=\"http://www.opengis.net/wps/1.0.0\" xmlns:ows=\"http://www.opengis.net/ows/1.1\" xmlns:gml=\"http://www.opengis.net/gml\" xmlns:ogc=\"http://www.opengis.net/ogc\" xmlns:wcs=\"http://www.opengis.net/wcs/1.1.1\" xmlns:xlink=\"http://www.w3.org/1999/xlink\" xsi:schemaLocation=\"http://www.opengis.net/wps/1.0.0 http://schemas.opengis.net/wps/1.0.0/wpsAll.xsd\">\n  <ows:Identifier>JTS:buffer</ows:Identifier>\n  <wps:DataInputs>\n    <wps:Input>\n      <ows:Identifier>geom</ows:Identifier>\n      <wps:Data>\n        <wps:ComplexData mimeType=\"application/wkt\"><![CDATA[POINT(0 0)]]></wps:ComplexData>\n      </wps:Data>\n    </wps:Input>\n    <wps:Input>\n      <ows:Identifier>distance</ows:Identifier>\n      <wps:Data>\n        <wps:LiteralData>10</wps:LiteralData>\n      </wps:Data>\n    </wps:Input>\n    <wps:Input>\n      <ows:Identifier>quadrantSegments</ows:Identifier>\n      <wps:Data>\n        <wps:LiteralData>1</wps:LiteralData>\n      </wps:Data>\n    </wps:Input>\n    <wps:Input>\n      <ows:Identifier>capStyle</ows:Identifier>\n      <wps:Data>\n        <wps:LiteralData>flat</wps:LiteralData>\n      </wps:Data>\n    </wps:Input>\n  </wps:DataInputs>\n  <wps:ResponseForm>\n    <wps:RawDataOutput mimeType=\"application/gml-3.1.1\">\n      <ows:Identifier>result</ows:Identifier>\n    </wps:RawDataOutput>\n  </wps:ResponseForm>\n</wps:Execute>\n

                                                                                          The process performs a buffer operation using the supplied inputs, and returns the outputs as specified. The response from the request is (with numbers rounded for clarity):

                                                                                          <?xml version=\"1.0\" encoding=\"utf-8\"?>\n<gml:Polygon xmlns:sch=\"http://www.ascc.net/xml/schematron\"\n xmlns:gml=\"http://www.opengis.net/gml\"\n xmlns:xlink=\"http://www.w3.org/1999/xlink\">\n  <gml:exterior>\n    <gml:LinearRing>\n      <gml:posList>\n        10.0 0.0\n        0.0 -10.0\n        -10.0 0.0 \n        0.0 10.0\n        10.0 0.0\n      </gml:posList>\n    </gml:LinearRing>\n  </gml:exterior>\n</gml:Polygon>\n

                                                                                          For help in generating WPS requests you can use the built-in interactive WPS Request Builder.

                                                                                          "},{"location":"services/wps/operations/#dismiss","title":"Dismiss","text":"

                                                                                          Note

                                                                                          This is a vendor extension of the GeoServer WPS Service. This operation is specific to GeoServer.

                                                                                          According to the WPS specification, an asynchronous process execution returns a back link to a status location that the client can ping to get progress report about the process, and eventually retrieve its final results.

                                                                                          In GeoServer this link is implemented as a pseudo-operation called GetExecutionStatus, and the link has the following structure:

                                                                                          http://host:port/geoserver/ows?service=WPS&version=1.0.0&request=GetExecutionStatus&executionId=397e8cbd-7d51-48c5-ad72-b0fcbe7cfbdb\n

                                                                                          The executionId identifies the running request, and can be used in the Dismiss vendor operation in order to cancel the execution of the process:

                                                                                          http://host:port/geoserver/ows?service=WPS&version=1.0.0&request=Dismiss&executionId=397e8cbd-7d51-48c5-ad72-b0fcbe7cfbdb

                                                                                          Upon receipt GeoServer will do its best to stop the running process, and subsequent calls to Dismiss or GetExecutionStatus will report that the executionId is not known anymore. Internally, GeoServer will stop any process that attempts to report progress, and poison input and outputs to break the execution of the process, but the execution of processes that already got their inputs, and are not reporting their progress back, will continue until their natural end.

                                                                                          For example, let's consider the \"\" process, possibly working against a very large input GML geometry, to be fetched from another host. The process itself does a single call to a JTS function, which cannot report progress. Here are three possible scenarios, depending on when the Dismiss operation is invoked:

                                                                                          • Dismiss is invoked while the GML is being retrieved, in this case the execution will stop immediately
                                                                                          • Dismiss is invoked while the process is doing the buffering, in this case, the execution will stop as soon as the buffering is completed
                                                                                          • Dismiss is invoked while the output GML is being encoded, also in this case the execution will stop immediately
                                                                                          "},{"location":"services/wps/operations/#getexecutions","title":"GetExecutions","text":"

                                                                                          Note

                                                                                          This is a vendor extension of the GeoServer WPS Service. This operation is specific to GeoServer.

                                                                                          This operation allows a client to recognize the list of WPS Executions.

                                                                                          The client makes a simple \"GetExecutions\" request to the WPS Server, in order to get back an XML document containing the list of current Execution Statuses.

                                                                                          It is also possible to filter the \"GetExecutions\" request along with simple parameters, in order to refine the output and get back only the executions status we are looking for.

                                                                                          Adding a bit more to this, AUTHORIZATION headers must be sent along with the \"GetExecutions\" request; the WPS Server will be able, if the security subsystem is available and enable on the latter, to prove the list resources to the client itself.

                                                                                          The operation will return only the list of available Executions the logged in user has started, except in the case it is an Administrator. In that case he will be able to get the whole list.

                                                                                          If the \"lineage\" option of the WPS Execute Request has been specified, the client will be able to retrieve the Execute Inputs values provided to the process Identifier.

                                                                                          "},{"location":"services/wps/operations/#statusinfo-document","title":"StatusInfo Document","text":"

                                                                                          Refers to http://docs.opengeospatial.org/is/14-065/14-065.html section 9.5 and extends it.

                                                                                          The StatusInfo document is used to provide identification and status information about jobs on a WPS server. The operation adds additional fields to the StatusInfo Document reporting also the WPS Process Identifier and other information on estimated execution and expiration time.

                                                                                          "},{"location":"services/wps/operations/#getexecutionsoperation","title":"GetExecutionsOperation","text":"

                                                                                          The GetExecutions Operation allows WPS clients to retrieve the list of available process jobs running on a WPS instance. The output is returned in the form of an XML document.

                                                                                          The GetExecutions Operation returns only the list of available Executions the logged in user has started, except in the case it is an Administrator. In that case he will be able to get the whole list.

                                                                                          "},{"location":"services/wps/operations/#getexecutionsrequest","title":"GetExecutionsRequest","text":"

                                                                                          The GetExecutions Request is a common structure for synchronous execution. It inherits basic properties from the RequestBaseType and contains additional elements that allow to filter out, refine and order the list of available Process Jobs.

                                                                                          "},{"location":"services/wps/operations/#getexecutionsresponse","title":"GetExecutionsResponse","text":"

                                                                                          The GetExecutionsResponse it is always in the form of an XML document. Except in case of Exception, the response document will contain a list of StatusInfo elements filtered, refined or ordered accordingly to the specified parameters.

                                                                                          "},{"location":"services/wps/operations/#response-paging","title":"Response paging","text":"

                                                                                          Response paging is the ability of a client to scroll through a set of response values, N values at-a-time much like one scrolls through the response from a search engine one page at a time.

                                                                                          Similar to the WFS 2.0.0 response paging mechanism (see section \"7.7.4.4 Response paging\" of the specification), the output will show to the client the following attributes as part of the response document.

                                                                                          "},{"location":"services/wps/operations/#getexecutionsexceptions","title":"GetExecutionsExceptions","text":"

                                                                                          When a WPS server encounters an error while performing an GetExecutionsResponse, it shall return an exception report as specified in clause 8 of [OGC 06-121r9]. If appropriate, the server shall use additional exception codes as defined in this section.

                                                                                          "},{"location":"services/wps/operations/#retrieve-the-wps-execute-input-values","title":"Retrieve the WPS Execute Input values","text":"

                                                                                          The GetExecutions Operations tries (best-effort) to retrieve the Input values specified from the Execute Request iff the lineage option has been provided to the Execute Request.

                                                                                          Example requests with the lineage option active

                                                                                          <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<wps:Execute version=\"1.0.0\" service=\"WPS\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xmlns=\"http://www.opengis.net/wps/1.0.0\" xmlns:wfs=\"http://www.opengis.net/wfs\" xmlns:wps=\"http://www.opengis.net/wps/1.0.0\" xmlns:ows=\"http://www.opengis.net/ows/1.1\" xmlns:gml=\"http://www.opengis.net/gml\" xmlns:ogc=\"http://www.opengis.net/ogc\" xmlns:wcs=\"http://www.opengis.net/wcs/1.1.1\" xmlns:xlink=\"http://www.w3.org/1999/xlink\" xsi:schemaLocation=\"http://www.opengis.net/wps/1.0.0 http://schemas.opengis.net/wps/1.0.0/wpsAll.xsd\">\n  <ows:Identifier>JTS:convexHull</ows:Identifier>\n  <wps:DataInputs>\n    <wps:Input>\n      <ows:Identifier>geom</ows:Identifier>\n      <wps:Reference mimeType=\"application/wkt\" xlink:href=\"http://www.geo-solutions.it/geoserver/wfs?\" method=\"GET\"/>\n    </wps:Input>\n  </wps:DataInputs>\n  <wps:ResponseForm>\n    <wps:ResponseDocument lineage=\"true\" storeExecuteResponse=\"true\" status=\"true\">\n      <wps:Output asReference=\"false\">\n        <ows:Identifier>result</ows:Identifier>\n      </wps:Output>\n    </wps:ResponseDocument>\n  </wps:ResponseForm>\n</wps:Execute>\n
                                                                                          <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<wps:Execute version=\"1.0.0\" service=\"WPS\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xmlns=\"http://www.opengis.net/wps/1.0.0\" xmlns:wfs=\"http://www.opengis.net/wfs\" xmlns:wps=\"http://www.opengis.net/wps/1.0.0\" xmlns:ows=\"http://www.opengis.net/ows/1.1\" xmlns:gml=\"http://www.opengis.net/gml\" xmlns:ogc=\"http://www.opengis.net/ogc\" xmlns:wcs=\"http://www.opengis.net/wcs/1.1.1\" xmlns:xlink=\"http://www.w3.org/1999/xlink\" xsi:schemaLocation=\"http://www.opengis.net/wps/1.0.0 http://schemas.opengis.net/wps/1.0.0/wpsAll.xsd\">\n  <ows:Identifier>gs:BufferFeatureCollection</ows:Identifier>\n  <wps:DataInputs>\n    <wps:Input>\n      <ows:Identifier>features</ows:Identifier>\n      <wps:Reference mimeType=\"text/xml\" xlink:href=\"http://geoserver/wps\" method=\"POST\">\n        <wps:Body>\n            <wps:Execute version=\"1.0.0\" service=\"WPS\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xmlns=\"http://www.opengis.net/wps/1.0.0\" xmlns:wfs=\"http://www.opengis.net/wfs\" xmlns:wps=\"http://www.opengis.net/wps/1.0.0\" xmlns:ows=\"http://www.opengis.net/ows/1.1\" xmlns:gml=\"http://www.opengis.net/gml\" xmlns:ogc=\"http://www.opengis.net/ogc\" xmlns:wcs=\"http://www.opengis.net/wcs/1.1.1\" xmlns:xlink=\"http://www.w3.org/1999/xlink\" xsi:schemaLocation=\"http://www.opengis.net/wps/1.0.0 http://schemas.opengis.net/wps/1.0.0/wpsAll.xsd\">\n              <ows:Identifier>gs:CollectGeometries</ows:Identifier>\n              <wps:DataInputs>\n                <wps:Input>\n                  <ows:Identifier>features</ows:Identifier>\n                  <wps:Reference mimeType=\"text/xml\" xlink:href=\"http://geoserver/wfs\" method=\"POST\">\n                    <wps:Body>\n                      <wfs:GetFeature service=\"WFS\" version=\"1.0.0\" outputFormat=\"GML2\" xmlns:geonode=\"http://www.geonode.org/\">\n                        <wfs:Query typeName=\"geonode:san_andres_y_providencia_administrative\"/>\n                      </wfs:GetFeature>\n                    </wps:Body>\n                  </wps:Reference>\n                </wps:Input>\n              </wps:DataInputs>\n              <wps:ResponseForm>\n                <wps:RawDataOutput lineage=\"true\" mimeType=\"text/xml; subtype=gml/3.1.1\">\n                  <ows:Identifier>result</ows:Identifier>\n                </wps:RawDataOutput>\n              </wps:ResponseForm>\n            </wps:Execute>\n        </wps:Body>\n      </wps:Reference>\n    </wps:Input>\n    <wps:Input>\n      <ows:Identifier>distance</ows:Identifier>\n      <wps:Data>\n        <wps:LiteralData>0.005</wps:LiteralData>\n      </wps:Data>\n    </wps:Input>\n  </wps:DataInputs>\n  <wps:ResponseForm>\n    <wps:ResponseDocument lineage=\"true\" storeExecuteResponse=\"true\" status=\"true\">\n      <wps:Output asReference=\"false\">\n        <ows:Identifier>result</ows:Identifier>\n      </wps:Output>\n    </wps:ResponseDocument>\n  </wps:ResponseForm>\n</wps:Execute>\n
                                                                                          <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<wps:Execute version=\"1.0.0\" service=\"WPS\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xmlns=\"http://www.opengis.net/wps/1.0.0\" xmlns:wfs=\"http://www.opengis.net/wfs\" xmlns:wps=\"http://www.opengis.net/wps/1.0.0\" xmlns:ows=\"http://www.opengis.net/ows/1.1\" xmlns:gml=\"http://www.opengis.net/gml\" xmlns:ogc=\"http://www.opengis.net/ogc\" xmlns:wcs=\"http://www.opengis.net/wcs/1.1.1\" xmlns:xlink=\"http://www.w3.org/1999/xlink\" xsi:schemaLocation=\"http://www.opengis.net/wps/1.0.0 http://schemas.opengis.net/wps/1.0.0/wpsAll.xsd\">\n  <ows:Identifier>gs:Clip</ows:Identifier>\n  <wps:DataInputs>\n    <wps:Input>\n      <ows:Identifier>features</ows:Identifier>\n      <wps:Reference mimeType=\"text/xml\" xlink:href=\"http://geoserver/wfs\" method=\"POST\">\n        <wps:Body>\n          <wfs:GetFeature service=\"WFS\" version=\"1.0.0\" outputFormat=\"GML2\" xmlns:geonode=\"http://www.geonode.org/\">\n            <wfs:Query typeName=\"geonode:san_andres_y_providencia_administrative\"/>\n          </wfs:GetFeature>\n        </wps:Body>\n      </wps:Reference>\n    </wps:Input>\n    <wps:Input>\n      <ows:Identifier>clip</ows:Identifier>\n      <wps:Data>\n        <wps:ComplexData mimeType=\"application/json\"><![CDATA[{\"type\":\"MultiLineString\",\"coordinates\":[[[-81.8254,12.199],[-81.8162,12.1827],[-81.812,12.1653],[-81.8156,12.1465],[-81.8269,12.1321],[-81.8433,12.123],[-81.8614,12.119],[-81.8795,12.1232],[-81.8953,12.1336],[-81.9049,12.1494],[-81.9087,12.1673],[-81.9054,12.1864],[-81.8938,12.2004],[-81.8795,12.2089],[-81.8593,12.2136],[-81.8399,12.2096],[-81.8254,12.199]],[[-81.6565,12.635],[-81.6808,12.6391],[-81.7085,12.6262],[-81.739,12.6046],[-81.7611,12.5775],[-81.775,12.5397],[-81.7708,12.5207],[-81.7667,12.4971],[-81.7701,12.4748],[-81.7646,12.4504],[-81.739,12.4369],[-81.7022,12.4389],[-81.6835,12.4578],[-81.6794,12.4883],[-81.6676,12.5153],[-81.651,12.541],[-81.66,12.5552],[-81.6489,12.5762],[-81.6274,12.5931],[-81.6309,12.6181],[-81.6565,12.635]],[[-81.2954,13.3496],[-81.3004,13.3132],[-81.3143,13.29],[-81.3413,13.2755],[-81.3731,13.2674],[-81.4058,13.2657],[-81.4335,13.2633],[-81.4531,13.2771],[-81.4574,13.3079],[-81.4663,13.3257],[-81.463,13.3476],[-81.447,13.3674],[-81.4228,13.3879],[-81.412,13.4126],[-81.403,13.4375],[-81.391,13.4582],[-81.3674,13.4687],[-81.3503,13.4574],[-81.3205,13.448],[-81.2941,13.4177],[-81.2846,13.3878],[-81.2954,13.3496]],[[-79.9333,14.9856],[-79.9333,15.5028]]]}]]></wps:ComplexData>\n      </wps:Data>\n    </wps:Input>\n  </wps:DataInputs>\n  <wps:ResponseForm>\n    <wps:ResponseDocument lineage=\"true\" storeExecuteResponse=\"true\" status=\"true\">\n      <wps:Output asReference=\"false\">\n        <ows:Identifier>result</ows:Identifier>\n      </wps:Output>\n    </wps:ResponseDocument>\n  </wps:ResponseForm>\n</wps:Execute>\n
                                                                                          "},{"location":"services/wps/requestbuilder/","title":"WPS Request Builder","text":"

                                                                                          The GeoServer WPS extension includes a request builder for testing out WPS processes through the Web administration interface. This tool can also be used to demonstrate processes, and construct your own examples.

                                                                                          "},{"location":"services/wps/requestbuilder/#accessing-the-request-builder","title":"Accessing the request builder","text":"

                                                                                          To access the WPS Request Builder:

                                                                                          1. Navigate to the main Web administration interface.
                                                                                          2. Click on the Demos link on the left side.
                                                                                          3. Select WPS Request Builder from the list of demos.

                                                                                          WPS request builder in the list of demos

                                                                                          "},{"location":"services/wps/requestbuilder/#using-the-request-builder","title":"Using the request builder","text":"

                                                                                          The WPS Request Builder primarily consists of a selection box listing all of the available processes, and two buttons, one to submit the WPS request, and another to display what the POST request looks like.

                                                                                          Blank WPS request builder form

                                                                                          The display changes depending on the process and input selected. JTS processes have available as inputs any of a GML/WKT-based feature collection, URL reference, or subprocess. GeoServer-specific processes have all these as options and also includes the ability to choose a GeoServer layer as input.

                                                                                          For each process, a form will display based on the required and optional parameters associated with that process, if any.

                                                                                          WPS request builder form to determine the bounds of topp:states

                                                                                          To see the process as a POST request, click the Generate XML from process inputs/outputs button.

                                                                                          Raw WPS POST request for the above process

                                                                                          To execute the process, click the Execute Process button. The response will be displayed in a window or

                                                                                          WPS server response

                                                                                          "},{"location":"services/wps/security/","title":"WPS Security and input limits","text":"

                                                                                          GeoServer service security is normally based on the generic OGC security configuration, however, when it comes to WPS there is also a need to restrict access to individual processes, in the same way that data security restricts access to layers.

                                                                                          WPS security allows access to be determined by process group or by single process. Each process and process group can be enabled/disabled, or subject to access control based on the user roles.

                                                                                          The WPS security page

                                                                                          The WPS security configurations can be changed using the Web administration interface on the WPS security page under Security.

                                                                                          Click to access the WPS security settings

                                                                                          "},{"location":"services/wps/security/#setting-access-roles","title":"Setting access roles","text":"

                                                                                          The list of roles attached to each group or process will determine which users can access which processes. If the list is empty the group/process will be available to all users, unless it has been disabled, in which case it won't be available to anyone.

                                                                                          The roles string must be a list of roles separated by semicolons. The role editor provides auto-completion and also allows quick copy and paste of role lists from one process definition to the other:

                                                                                          Role selector field with auto-complete

                                                                                          "},{"location":"services/wps/security/#access-modes","title":"Access modes","text":"

                                                                                          The process access mode configuration specifies how GeoServer will advertise secured processes and behave when a secured process is accessed without the necessary privileges. The parameter can be one of three values:

                                                                                          • HIDE (default): The processes not available to the current user will be hidden from the user (not listed in the capabilities documents). Direct access will result in GeoServer claiming the process does not exist.
                                                                                          • CHALLENGE: All processes will be shown in the capabilities documents, but an authentication request will be raised if a secured process is specifically requested by a user that does not have sufficient access rights
                                                                                          • MIXED: The secured processes will not be shown in the capabilities documents for users not having sufficient access rights, but an authentication request will still be raised if a secured process is requested.
                                                                                          "},{"location":"services/wps/security/#complex-inputs","title":"Complex Inputs","text":"

                                                                                          By default, Execute requests support loading complex inputs from references to local files and external servers. This behavior can be restricted in the Complex Inputs section. When the flag is checked, an Execute request with an input reference that is not an internal WCS/WFS/WPS request will result in a service exception reporting the error.

                                                                                          "},{"location":"services/wps/security/#input-limits","title":"Input limits","text":"

                                                                                          The amount of resources used by a process is usually related directly to the inputs of the process itself. With this in mind, administrators can set three different type of limits on each process inputs:

                                                                                          • The maximum size of complex inputs

                                                                                          • The range of acceptable values for numeric values

                                                                                          • The maximum multiplicity of repeatable inputs

                                                                                            Note

                                                                                            As an example of the last point, think of contour extraction, where the number of levels for the contours can drastically affect the execution time

                                                                                          GeoServer allows the administrator to configure these limits, and fail requests that don't respect them.

                                                                                          The maximum size can be given a global default on the WPS security page. It is also possible to define limits on a per-process basis by navigating to the process limits editor in the process list.

                                                                                          Note

                                                                                          Processes having a * beside the link have a defined set of limits

                                                                                          The process selector, with access constraints and links to the limits configuration

                                                                                          The process limits editor shows all inputs for which a limit can be provided. An empty field means that limits are disabled for that input.

                                                                                          The process limit page, with input limits configured

                                                                                          Warning

                                                                                          In order for the limits to be saved: click on OK on this Process limits page; and then click OK on the Process selection page; and finally Save on the WPS security page.

                                                                                          "},{"location":"services/wps/processes/","title":"Process Cookbook","text":"

                                                                                          The Web Processing Service describes a method for publishing geospatial processes, but does not specify what those processes should be. Servers that implement WPS therefore have complete leeway in what types of processes to implement, as well as how those processes are implemented. This means that a process request designed for one type of WPS is not expected to work on a different type of WPS.

                                                                                          GeoServer gathers processes into several different categories based on subject. These categories are grouped by prefix:

                                                                                          • geo: geometry processes
                                                                                          • ras: raster processes
                                                                                          • vec: Vector processes
                                                                                          • gs: GeoServer-specific processes

                                                                                          This cookbook provides examples of some of the available process. Unless otherwise stated examples were generated with the WPS Request Builder using the sample data included with each GeoServer release.

                                                                                          • Geometry Processes
                                                                                          • GeoServer processes
                                                                                          • Process chaining

                                                                                          Note

                                                                                          Previous releases of GeoServer grouped processes not by subject, but by the internal library responsible for implementation. The \"JTS\" and \"gt\" prefixes can be enabled to preserve backwards compatibility, or you may safely disable them off - their functionality is correctly sorted into the \"vec\" and \"geo\" categories.

                                                                                          "},{"location":"services/wps/processes/chaining/","title":"Process chaining","text":"

                                                                                          One of the benefits of WPS is its native ability to chain processes. Much like how functions can call other functions, a WPS process can use as its input the output of another process. Many complex functions can thus be combined in to a single powerful request.

                                                                                          For example, let's take some of the sample data that is shipped with GeoServer and use the WPS engine to chain a few of the built in processes, which will allow users to perform geospatial analysis on the fly.

                                                                                          The question we want to answer in this example is the following: How many miles of roads are crossing a protected area?

                                                                                          The data that will be used for this example is included with a standard installation of GeoServer:

                                                                                          • sf:roads: the layer that contains road information
                                                                                          • sf:restricted: the layer representing restricted areas

                                                                                          The restricted areas partially overlap the roads. We would like to know the total length of roads inside the restricted areas, as shown in the next screenshot. The road network is represented in white against a false color DEM (Digital Elevation Model). The restricted areas are represented with a dashed line in dark brown. The portion of the road network that is inside the restricted areas is drawn in red.

                                                                                          Length of total roads inside restricted area

                                                                                          In order to calculate the total length, we will need the following built in WPS processes:

                                                                                          • gs:IntersectionFeatureCollection: returns the intersection between two feature collections adding the attributes from both of them
                                                                                          • gs:CollectGeometries: collects all the default geometries in a feature collection and returns them as a single geometry collection
                                                                                          • JTS:length: calculates the length of a geometry in the same unit of measure as the geometry

                                                                                          The sequence in which these processes are executed is important. The first thing we want to do is intersect the road network with the restricted areas. This gives us the feature collection with all the roads that we are interested in. Then we collect those geometries into a single GeometryCollection so that the length can be calculated with the built in JTS algorithm.

                                                                                          gs:IntersectionFeatureCollection \u2192 gs:CollectGeometries \u2192 JTS:length

                                                                                          The sequence of processes determines how the WPS request is built, by embedding the first process into the second, the second into the third, etc. A process produces some output which will become the input of the next process, resulting in a processing pipeline that can solve complex spatial analysis with a single HTTP request. The advantage of using GeoServer's layers is that data is not being shipped back and forth between processes, resulting in very good performance.

                                                                                          Here is the complete WPS request in XML format:

                                                                                          <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<wps:Execute version=\"1.0.0\" service=\"WPS\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xmlns=\"http://www.opengis.net/wps/1.0.0\" xmlns:wfs=\"http://www.opengis.net/wfs\" xmlns:wps=\"http://www.opengis.net/wps/1.0.0\" xmlns:ows=\"http://www.opengis.net/ows/1.1\" xmlns:gml=\"http://www.opengis.net/gml\" xmlns:ogc=\"http://www.opengis.net/ogc\" xmlns:wcs=\"http://www.opengis.net/wcs/1.1.1\" xmlns:xlink=\"http://www.w3.org/1999/xlink\" xsi:schemaLocation=\"http://www.opengis.net/wps/1.0.0 http://schemas.opengis.net/wps/1.0.0/wpsAll.xsd\">\n\n  <ows:Identifier>JTS:length</ows:Identifier>\n  <wps:DataInputs>\n    <wps:Input>\n      <ows:Identifier>geom</ows:Identifier>\n  <wps:Reference mimeType=\"text/xml; subtype=gml/3.1.1\"\n              xlink:href=\"http://geoserver/wps\" method=\"POST\">\n      <wps:Body>\n        <wps:Execute version=\"1.0.0\" service=\"WPS\">\n          <ows:Identifier>gs:CollectGeometries</ows:Identifier>\n          <wps:DataInputs>\n            <wps:Input>\n              <ows:Identifier>features</ows:Identifier>\n              <wps:Reference mimeType=\"text/xml; subtype=wfs-collection/1.0\" xlink:href=\"http://geoserver/wps\" method=\"POST\">\n                <wps:Body>\n                  <wps:Execute version=\"1.0.0\" service=\"WPS\">\n                    <ows:Identifier>gs:IntersectionFeatureCollection</ows:Identifier>\n                    <wps:DataInputs>\n                      <wps:Input>\n                        <ows:Identifier>first feature collection</ows:Identifier>\n                        <wps:Reference mimeType=\"text/xml; subtype=wfs-collection/1.0\" xlink:href=\"http://geoserver/wfs\" method=\"POST\">\n                          <wps:Body>\n                            <wfs:GetFeature service=\"WFS\" version=\"1.0.0\" outputFormat=\"GML2\">\n                              <wfs:Query typeName=\"sf:roads\"/>\n                            </wfs:GetFeature>\n                          </wps:Body>\n                        </wps:Reference>\n                      </wps:Input>\n                      <wps:Input>\n                        <ows:Identifier>second feature collection</ows:Identifier>\n                        <wps:Reference mimeType=\"text/xml; subtype=wfs-collection/1.0\" xlink:href=\"http://geoserver/wfs\" method=\"POST\">\n                          <wps:Body>\n                            <wfs:GetFeature service=\"WFS\" version=\"1.0.0\" outputFormat=\"GML2\">\n                              <wfs:Query typeName=\"sf:restricted\"/>\n                            </wfs:GetFeature>\n                          </wps:Body>\n                        </wps:Reference>\n                      </wps:Input>\n                      <wps:Input>\n                        <ows:Identifier>first attributes to retain</ows:Identifier>\n                        <wps:Data>\n                          <wps:LiteralData>the_geom cat</wps:LiteralData>\n                        </wps:Data>\n                      </wps:Input>\n                      <wps:Input>\n                        <ows:Identifier>second attributes to retain</ows:Identifier>\n                        <wps:Data>\n                          <wps:LiteralData>cat</wps:LiteralData>\n                        </wps:Data>\n                      </wps:Input>\n                    </wps:DataInputs>\n                    <wps:ResponseForm>\n                      <wps:RawDataOutput mimeType=\"text/xml;\n                     subtype=wfs-collection/1.0\">\n                        <ows:Identifier>result</ows:Identifier>\n                      </wps:RawDataOutput>\n                    </wps:ResponseForm>\n                  </wps:Execute>\n                </wps:Body>\n              </wps:Reference>\n            </wps:Input>\n          </wps:DataInputs>\n          <wps:ResponseForm>\n            <wps:RawDataOutput mimeType=\"text/xml; subtype=gml/3.1.1\">\n              <ows:Identifier>result</ows:Identifier>\n            </wps:RawDataOutput>\n          </wps:ResponseForm>\n        </wps:Execute>\n      </wps:Body>\n    </wps:Reference>\n    </wps:Input>\n  </wps:DataInputs>\n  <wps:ResponseForm>\n    <wps:RawDataOutput>\n      <ows:Identifier>result</ows:Identifier>\n    </wps:RawDataOutput>\n  </wps:ResponseForm>\n</wps:Execute>\n

                                                                                          You can save this XML request in a file called wps-chaining.xml and execute the request using cURL like this:

                                                                                          curl -u admin:geoserver -H 'Content-type: xml' -XPOST -d@'wps-chaining.xml' http://localhost:8080/geoserver/wps

                                                                                          The response is just a number, the total length of the roads that intersect the restricted areas, and should be around 25076.285 meters (the length process returns map units)

                                                                                          To see WPS requests in action, you can use the built-in WPS Request Builder.

                                                                                          "},{"location":"services/wps/processes/geo/","title":"Geometry Processes","text":"

                                                                                          The geometry processes are built using the JTS Topology Suite (JTS). JTS is a Java library of functions for processing geometries in two dimensions. JTS conforms to the Simple Features Specification for SQL published by the Open Geospatial Consortium (OGC), similar to PostGIS. JTS includes common spatial functions such as area, buffer, intersection, and simplify.

                                                                                          GeoServer WPS implements some of these functions as \"geo\" processes. The names and definitions of these processes are subject to change, so they have not been included here. For a full list of JTS processes, please see the GeoServer WPS capabilities document or browse with the WPS Request Builder.

                                                                                          "},{"location":"services/wps/processes/gs/","title":"GeoServer processes","text":"

                                                                                          GeoServer WPS includes a few processes created especially for use with GeoServer. These are usually GeoServer-specific functions, such as bounds and reprojection. They use an internal connection to the GeoServer WFS/WCS, not part of the WPS specification, for reading and writing data.

                                                                                          As with the \"geo\" processes, the names and definitions of these processes are subject to change, so they have not been included here. For a full list of GeoServer-specific processes, please see the GeoServer WPS capabilities document (or browse with the WPS Request Builder.)

                                                                                          "},{"location":"services/wps/processes/gs/#aggregation-process","title":"Aggregation process","text":"

                                                                                          The aggregation process is used to perform common aggregation functions (sum, average, count) on vector data. The available outputs formats for this process are text/xml and application/json.

                                                                                          The process parameters are described in the table bellow:

                                                                                          Parameter Description Mandatory Multiple features Input feature collection. yes no aggregationAttribute Attribute on which to perform aggregation. yes no function An aggregate function to compute. Functions include Count, Average, Max, Median, Min, StdDev, and Sum. yes yes singlePass If TRUE computes all aggregation values in a single pass. This will defeat DBMS-specific optimizations. If a group by attribute is provided this parameter will be ignored. yes no groupByAttributes Group by attribute. no yes

                                                                                          Follow some examples of the invocation of this process using GeoServer shipped topp:states layer.

                                                                                          The examples can be tested with CURL:

                                                                                          curl -u admin:geoserver -H 'Content-type: xml' -XPOST -d@'wps-request.xml' http://localhost:8080/geoserver/wps\n

                                                                                          where wps-request.xml is the file that contains the request.

                                                                                          "},{"location":"services/wps/processes/gs/#aggregate-example","title":"Aggregate Example","text":"

                                                                                          Counts the total number of states, sum all the number of persons, computes the average number of persons per state and give the maximum and minimum number of persons in a state.

                                                                                          Request:

                                                                                          <?xml version=\"1.0\" encoding=\"UTF-8\"?><wps:Execute version=\"1.0.0\" service=\"WPS\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xmlns=\"http://www.opengis.net/wps/1.0.0\" xmlns:wfs=\"http://www.opengis.net/wfs\" xmlns:wps=\"http://www.opengis.net/wps/1.0.0\" xmlns:ows=\"http://www.opengis.net/ows/1.1\" xmlns:gml=\"http://www.opengis.net/gml\" xmlns:ogc=\"http://www.opengis.net/ogc\" xmlns:wcs=\"http://www.opengis.net/wcs/1.1.1\" xmlns:xlink=\"http://www.w3.org/1999/xlink\" xsi:schemaLocation=\"http://www.opengis.net/wps/1.0.0 http://schemas.opengis.net/wps/1.0.0/wpsAll.xsd\">\n  <ows:Identifier>gs:Aggregate</ows:Identifier>\n  <wps:DataInputs>\n    <wps:Input>\n      <ows:Identifier>features</ows:Identifier>\n      <wps:Reference mimeType=\"text/xml\" xlink:href=\"http://geoserver/wfs\" method=\"POST\">\n        <wps:Body>\n          <wfs:GetFeature service=\"WFS\" version=\"1.0.0\" outputFormat=\"GML2\" xmlns:sf=\"http://www.openplans.org/spearfish\">\n            <wfs:Query typeName=\"topp:states\"/>\n          </wfs:GetFeature>\n        </wps:Body>\n      </wps:Reference>\n    </wps:Input>\n    <wps:Input>\n      <ows:Identifier>aggregationAttribute</ows:Identifier>\n      <wps:Data>\n        <wps:LiteralData>PERSONS</wps:LiteralData>\n      </wps:Data>\n    </wps:Input>\n    <wps:Input>\n      <ows:Identifier>function</ows:Identifier>\n      <wps:Data>\n        <wps:LiteralData>Count</wps:LiteralData>\n      </wps:Data>\n    </wps:Input>\n    <wps:Input>\n      <ows:Identifier>function</ows:Identifier>\n      <wps:Data>\n        <wps:LiteralData>Average</wps:LiteralData>\n      </wps:Data>\n    </wps:Input>\n    <wps:Input>\n      <ows:Identifier>function</ows:Identifier>\n      <wps:Data>\n        <wps:LiteralData>Sum</wps:LiteralData>\n      </wps:Data>\n    </wps:Input>\n    <wps:Input>\n      <ows:Identifier>function</ows:Identifier>\n      <wps:Data>\n        <wps:LiteralData>Min</wps:LiteralData>\n      </wps:Data>\n    </wps:Input>\n    <wps:Input>\n      <ows:Identifier>function</ows:Identifier>\n      <wps:Data>\n        <wps:LiteralData>Max</wps:LiteralData>\n      </wps:Data>\n    </wps:Input>\n    <wps:Input>\n      <ows:Identifier>singlePass</ows:Identifier>\n      <wps:Data>\n        <wps:LiteralData>false</wps:LiteralData>\n      </wps:Data>\n    </wps:Input>\n  </wps:DataInputs>\n  <wps:ResponseForm>\n    <wps:RawDataOutput mimeType=\"application/json\">\n      <ows:Identifier>result</ows:Identifier>\n    </wps:RawDataOutput>\n  </wps:ResponseForm>\n</wps:Execute>\n

                                                                                          The result:

                                                                                          {\n  \"AggregationAttribute\": \"PERSONS\",\n  \"AggregationFunctions\": [\"Max\", \"Min\", \"Average\", \"Sum\", \"Count\"],\n  \"GroupByAttributes\": [],\n  \"AggregationResults\": [\n    [29760021, 453588, 5038397.020408163, 246881454, 49]\n  ]\n}\n

                                                                                          The value of AggregationResults attribute should be read in a tabular way. The group by attributes come first in the order they appear in GroupByAttributes attribute. After comes the result of the aggregation functions in the order they appear in the AggregationFunctions attribute. In this case there is no group by attributes so the result only contains a row with the aggregation functions results. This is very similar to the result of an SQL query.

                                                                                          This result should be interpreted like this:

                                                                                          Max Min Average Sum Count 29760021 453588 5038397.020408163 246881454 49

                                                                                          To obtain the result in the XML format the request wps:ResponseForm element needs to be changed to:

                                                                                          <wps:ResponseForm>\n  <wps:RawDataOutput mimeType=\"text/xml\">\n    <ows:Identifier>result</ows:Identifier>\n  </wps:RawDataOutput>\n</wps:ResponseForm>\n

                                                                                          The result in XML format:

                                                                                          <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<AggregationResults>\n  <Min>453588.0</Min>\n  <Max>2.9760021E7</Max>\n  <Average>5038397.020408163</Average>\n  <Sum>2.46881454E8</Sum>\n  <Count>49</Count>\n</AggregationResults>\n
                                                                                          "},{"location":"services/wps/processes/gs/#aggregate-groupby-example","title":"Aggregate GroupBy Example","text":"

                                                                                          This example count the number of states and the population average grouped by region.

                                                                                          Request:

                                                                                          <?xml version=\"1.0\" encoding=\"UTF-8\"?><wps:Execute version=\"1.0.0\" service=\"WPS\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xmlns=\"http://www.opengis.net/wps/1.0.0\" xmlns:wfs=\"http://www.opengis.net/wfs\" xmlns:wps=\"http://www.opengis.net/wps/1.0.0\" xmlns:ows=\"http://www.opengis.net/ows/1.1\" xmlns:gml=\"http://www.opengis.net/gml\" xmlns:ogc=\"http://www.opengis.net/ogc\" xmlns:wcs=\"http://www.opengis.net/wcs/1.1.1\" xmlns:xlink=\"http://www.w3.org/1999/xlink\" xsi:schemaLocation=\"http://www.opengis.net/wps/1.0.0 http://schemas.opengis.net/wps/1.0.0/wpsAll.xsd\">\n  <ows:Identifier>gs:Aggregate</ows:Identifier>\n  <wps:DataInputs>\n    <wps:Input>\n      <ows:Identifier>features</ows:Identifier>\n      <wps:Reference mimeType=\"text/xml\" xlink:href=\"http://geoserver/wfs\" method=\"POST\">\n        <wps:Body>\n          <wfs:GetFeature service=\"WFS\" version=\"1.0.0\" outputFormat=\"GML2\" xmlns:sf=\"http://www.openplans.org/spearfish\">\n            <wfs:Query typeName=\"topp:states\"/>\n          </wfs:GetFeature>\n        </wps:Body>\n      </wps:Reference>\n    </wps:Input>\n    <wps:Input>\n      <ows:Identifier>aggregationAttribute</ows:Identifier>\n      <wps:Data>\n        <wps:LiteralData>PERSONS</wps:LiteralData>\n      </wps:Data>\n    </wps:Input>\n    <wps:Input>\n      <ows:Identifier>function</ows:Identifier>\n      <wps:Data>\n        <wps:LiteralData>Count</wps:LiteralData>\n      </wps:Data>\n    </wps:Input>\n    <wps:Input>\n      <ows:Identifier>function</ows:Identifier>\n      <wps:Data>\n        <wps:LiteralData>Average</wps:LiteralData>\n      </wps:Data>\n    </wps:Input>\n    <wps:Input>\n      <ows:Identifier>singlePass</ows:Identifier>\n      <wps:Data>\n        <wps:LiteralData>false</wps:LiteralData>\n      </wps:Data>\n    </wps:Input>\n    <wps:Input>\n      <ows:Identifier>groupByAttributes</ows:Identifier>\n      <wps:Data>\n        <wps:LiteralData>SUB_REGION</wps:LiteralData>\n      </wps:Data>\n    </wps:Input>\n  </wps:DataInputs>\n  <wps:ResponseForm>\n    <wps:RawDataOutput mimeType=\"application/json\">\n      <ows:Identifier>result</ows:Identifier>\n    </wps:RawDataOutput>\n  </wps:ResponseForm>\n</wps:Execute>\n

                                                                                          The result:

                                                                                          { \n  \"AggregationAttribute\": \"PERSONS\",\n  \"AggregationFunctions\": [\"Average\", \"Count\"],\n  \"GroupByAttributes\": [\"SUB_REGION\"], \n  \"AggregationResults\": [ \n    [ \"N Eng\", 2201157.1666666665, 6 ], \n    [ \"W N Cen\", 2522812.8571428573, 7 ], \n    [ \"Pacific\", 12489678, 3 ], \n    [ \"Mtn\", 1690408.25, 8 ], \n    [ \"E S Cen\", 3998821.25, 4 ], \n    [ \"S Atl\", 4837695.666666667, 9 ], \n    [ \"Mid Atl\", 12534095.333333334, 3 ], \n    [ \"E N Cen\", 8209477.2, 5 ], \n    [ \"W S Cen\", 6709575.75, 4 ]\n  ]\n}\n

                                                                                          Since there is a group by attribute the result contains a row for each different value of the group by attribute. Very similar to the result of an SQL query. If there is more that one group by attribute (which is not the case) their values will be in the order they appear in the GroupByAttributes attribute.

                                                                                          This result should be interpreted like this:

                                                                                          Sub Region Average count N Eng 2201157.1666666665 6 W N Cen 2522812.8571428573 7 Pacific 12489678 3 Mtn 1690408.25 8 E S Cen 3998821.25 4 S Atl 4837695.666666667 9 Mid Atl 12534095.333333334 3 E N Cen 8209477.2 5 W S Cen 6709575.75 4

                                                                                          The result in XML format:

                                                                                          <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<AggregationResults>\n  <GroupByResult>\n    <object-array>\n      <string>N Eng</string>\n      <double>2201157.1666666665</double>\n      <int>6</int>\n    </object-array>\n    <object-array>\n      <string>W N Cen</string>\n      <double>2522812.8571428573</double>\n      <int>7</int>\n    </object-array>\n    <object-array>\n      <string>Pacific</string>\n      <double>1.2489678E7</double>\n      <int>3</int>\n    </object-array>\n    <object-array>\n      <string>Mtn</string>\n      <double>1690408.25</double>\n      <int>8</int>\n    </object-array>\n    <object-array>\n      <string>E S Cen</string>\n      <double>3998821.25</double>\n      <int>4</int>\n    </object-array>\n    <object-array>\n      <string>S Atl</string>\n      <double>4837695.666666667</double>\n      <int>9</int>\n    </object-array>\n    <object-array>\n      <string>Mid Atl</string>\n      <double>1.2534095333333334E7</double>\n      <int>3</int>\n    </object-array>\n    <object-array>\n      <string>E N Cen</string>\n      <double>8209477.2</double>\n      <int>5</int>\n    </object-array>\n    <object-array>\n      <string>W S Cen</string>\n      <double>6709575.75</double>\n      <int>4</int>\n    </object-array>\n  </GroupByResult>\n</AggregationResults>\n
                                                                                          "},{"location":"styling/","title":"Styling","text":"

                                                                                          This section discusses the styling of geospatial data served through GeoServer.

                                                                                          • Styles
                                                                                          • SLD Styling
                                                                                          • Generating SLD styles with QGIS
                                                                                          • CSS Styling
                                                                                          • YSLD Styling
                                                                                          • MBStyle Styling
                                                                                          • Styling Workshop
                                                                                          "},{"location":"styling/css/","title":"CSS Styling","text":"

                                                                                          The CSS extension uses a CSS-derived language instead of SLD. These CSS styles are internally converted to SLD, which is then used as normal by GeoServer. The CSS syntax is duplicated from SVG styling where appropriate, but extended to avoid losing facilities provided by SLD when possible.

                                                                                          CSS is not a part of GeoServer by default, but is available as an extension.

                                                                                          • Installing the GeoServer CSS extension
                                                                                          • Tutorial: Styling data with CSS
                                                                                          • Filter syntax
                                                                                          • Metadata
                                                                                          • Multi-valued properties
                                                                                          • Property listing
                                                                                          • CSS value types
                                                                                          • Directives
                                                                                          • Understanding Cascading in CSS
                                                                                          • Nested rules
                                                                                          • Rendering transformations in CSS
                                                                                          • Styled marks
                                                                                          • CSS Cookbook
                                                                                          • Styling examples
                                                                                          "},{"location":"styling/css/cascading/","title":"Understanding Cascading in CSS","text":"

                                                                                          Cascading Style Sheets are the styling language of the web, use a simple syntax, but sometimes their simplicity can be deceitful if the writer is not aware of how the \"Cascading\" part of it works. The confusion might become greater by looking at the translated SLD, and wondering how all the SLD rules came to be from a much smaller set of CSS rules.

                                                                                          This document tries to clarify how cascading works, how it can be controlled in SLD translation, and for those that would prefer simpler, if more verbose, styles, shows how to turn cascading off for good.

                                                                                          "},{"location":"styling/css/cascading/#css-rules-application","title":"CSS rules application","text":"

                                                                                          Given a certain feature, how are CSS rules applied to it? This is roughly the algorithm:

                                                                                          • Locate all rules whose selector matches the current feature
                                                                                          • Sort them by specificity, less specific to more specific
                                                                                          • Have more specific rules add to and override properties set in less specific rules

                                                                                          As you can see, depending on the feature attributes a new rule is built by the above algorithm, mixing all the applicable rules for that feature.

                                                                                          The core of the algorithm allows to prepare rather succinct style sheets for otherwise very complex rule sets, by setting the common bits in less specific rules, and override them specifying the exceptions to the norm in more specific rules.

                                                                                          "},{"location":"styling/css/cascading/#understanding-specificity","title":"Understanding specificity","text":"

                                                                                          In web pages CSS specificity is setup as a tuple of four numbers called a,b,c,d:

                                                                                          • a: set to 1 if the style is local to an element, that is, defined in the element style attribute
                                                                                          • b: counts the number of ID attributes in the selector
                                                                                          • c: count the number of other attributes and pseudo classes in the selector
                                                                                          • d: count the number of element names or pseudo elements in the selector

                                                                                          a is more important than b, which is more important than c, and so on, so for example, if one rule has a=1 and then second has a=0, the first is more specific, regardless of what values have b, c and d.

                                                                                          Here are some examples from the CSS specification, from less specific to more specific:

                                                                                          *             {}  /* a=0 b=0 c=0 d=0 -> specificity = 0,0,0,0 */\nli            {}  /* a=0 b=0 c=0 d=1 -> specificity = 0,0,0,1 */\nli:first-line {}  /* a=0 b=0 c=0 d=2 -> specificity = 0,0,0,2 */\nul li         {}  /* a=0 b=0 c=0 d=2 -> specificity = 0,0,0,2 */\nul ol+li      {}  /* a=0 b=0 c=0 d=3 -> specificity = 0,0,0,3 */\nh1 + *[rel=up]{}  /* a=0 b=0 c=1 d=1 -> specificity = 0,0,1,1 */\nul ol li.red  {}  /* a=0 b=0 c=1 d=3 -> specificity = 0,0,1,3 */\nli.red.level  {}  /* a=0 b=0 c=2 d=1 -> specificity = 0,0,2,1 */\n#x34y         {}  /* a=0 b=1 c=0 d=0 -> specificity = 0,1,0,0 */\nstyle=\"...\"       /* a=1 b=0 c=0 d=0 -> specificity = 1,0,0,0 */\n

                                                                                          In cartographic CSS there are no HTML elements that could have a local style, so a is always zero. The others are calculated as follows:

                                                                                          • b: number of feature ids in the rule
                                                                                          • c: number of attributes in CQL filters and pseudo-classes (e.g., :mark) used in the selector
                                                                                          • d: 1 if a typename is specified, 0 otherwise

                                                                                          Here are some examples, from less to more specific:

                                                                                          *                  {}  /* a=0 b=0 c=0 d=0 -> specificity = 0,0,0,0 */\ntopp:states        {}  /* a=0 b=0 c=0 d=1 -> specificity = 0,0,0,1 */\n:mark              {}  /* a=0 b=0 c=1 d=0 -> specificity = 0,0,1,0 */\n[a = 1 and b > 10] {}  /* a=0 b=0 c=1 d=0 -> specificity = 0,0,2,0 */\n#states.1          {}  /* a=0 b=1 c=0 d=0 -> specificity = 0,1,0,0 */\n

                                                                                          In case two rules have the same specificity, the last one in the document wins.

                                                                                          "},{"location":"styling/css/cascading/#understanding-css-to-sld-translation-in-cascading-mode","title":"Understanding CSS to SLD translation in cascading mode","text":"

                                                                                          As discussed above, CSS rule application can potentially generate a different rule for each feature, depending on its attributes and how they get matched by the various CSS selectors.

                                                                                          SLD on the other hand starts from the rules, and applies all of them, in turn, to each feature, painting each matching rule. The two evaluation modes are quite different, in order to turn CSS into SLD the translator has to generate every possible CSS rule combination, while making sure the generated SLD rules are mutually exclusive (CSS generated a single rule for a given feature in the end).

                                                                                          The combination of all rules is called a power set, and the exclusivity is guaranteed by negating the filters of all previously generated SLD rules and adding to the current one. As one might imagine, this would result in a lot of rules, with very complex filters.

                                                                                          The translator addresses the above concerns by applying a few basic strategies:

                                                                                          • The generated filters are evaluated in memory, if the filter is found to be \"impossible\", that is, something that could never match an exiting feature, the associated rule is not emitted (e.g., a = 1 and a = 2 or a = 1 and not(a = 1))
                                                                                          • The generated SLD has a vendor option <sld:VendorOption name=\"ruleEvaluation\">first</sld:VendorOption> which forces the renderer to give up evaluating further rules once one of them actually matched a feature

                                                                                          The above is nice and sufficient in theory, while in practice it can break down with very complex CSS styles having a number of orthogonal selectors (e.g., 10 rules controlling the fill on the values of attribute a and 10 rules controlling the stroke on values of attribute b, and another 10 rules controlling the opacity of fill and stroke based on attribute c, resulting in 1000 possible combinations).

                                                                                          For this reason by default the translator will try to generated simplified and fully exclusive rules only if the set of rules is \"small\", and will instead generate the full power set otherwise, to avoid incurring in a CSS to SLD translation time of minutes if not hours.

                                                                                          The translation modes are controlled by the @mode directive, with the following values:

                                                                                          • 'Exclusive': translate the style sheet in a minimum set of SLD rules with simplified selectors, taking whatever time and memory required
                                                                                          • 'Simple': just generated the power set without trying to build a minimum style sheet, ensuring the translation is fast, even if the resulting SLD might look very complex
                                                                                          • 'Auto': this is the default value, it will perform the power set expansion, and then will proceed in Exclusive mode if the power set contains less than 100 derived rules, or in Simple mode otherwise. The rule count threshold can be manually controlled by using the @autoThreshold directive.
                                                                                          "},{"location":"styling/css/cascading/#the-flat-translation-mode","title":"The Flat translation mode","text":"

                                                                                          The @mode directive has one last possible value, Flat, which enables a flat translation mode in which specificity and cascading are not applied.

                                                                                          In this mode the CSS will be translated almost 1:1 into a corresponding SLD, each CSS rule producing and equivalent SLD rule, with the exception of the rules with pseudo-classes specifying how to stroke/fill marks and symbols in general.

                                                                                          Care should be taken when writing rules with pseudo classes, they will be taken into consideration only if their selector matches the one of the preceding rule. Consider this example:

                                                                                          @mode \"Flat\";\n\n[type = 'Capital'] { \n  mark: symbol(circle);\n}\n\n[type = 'Capital'] :mark {\n  fill: white;\n  size: 6px;\n}\n\n:mark {\n  stroke: black;\n  stroke-width: 2px;\n}\n

                                                                                          In the above example, the first rule with the :mark pseudo class will be taken into consideration and merged with the capital one, the second one instead will be ignored. The resulting SLD will thus not contain any stroke specification for the 'circle' mark:

                                                                                          <?xml version=\"1.0\" encoding=\"UTF-8\"?><sld:StyledLayerDescriptor xmlns=\"http://www.opengis.net/sld\" \n      xmlns:sld=\"http://www.opengis.net/sld\" xmlns:ogc=\"http://www.opengis.net/ogc\" \n      xmlns:gml=\"http://www.opengis.net/gml\" version=\"1.0.0\">\n  <sld:NamedLayer>\n    <sld:Name/>\n    <sld:UserStyle>\n      <sld:Name>Default Styler</sld:Name>\n      <sld:FeatureTypeStyle>\n        <sld:Rule>\n          <ogc:Filter>\n            <ogc:PropertyIsEqualTo>\n              <ogc:PropertyName>type</ogc:PropertyName>\n              <ogc:Literal>Capital</ogc:Literal>\n            </ogc:PropertyIsEqualTo>\n          </ogc:Filter>\n          <sld:PointSymbolizer>\n            <sld:Graphic>\n              <sld:Mark>\n                <sld:WellKnownName>circle</sld:WellKnownName>\n                <sld:Fill>\n                  <sld:CssParameter name=\"fill\">#ffffff</sld:CssParameter>\n                </sld:Fill>\n              </sld:Mark>\n              <sld:Size>6</sld:Size>\n            </sld:Graphic>\n          </sld:PointSymbolizer>\n        </sld:Rule>\n      </sld:FeatureTypeStyle>\n    </sld:UserStyle>\n  </sld:NamedLayer>\n</sld:StyledLayerDescriptor>\n

                                                                                          The advantages of flat mode are:

                                                                                          • Easy to understand, the rules are applied in the order they are written
                                                                                          • Legend control, the generated legend contains no surprises as rules are not mixed together and are not reordered

                                                                                          The main disadvantage is that there is no more a way to share common styling bits in general rules, all common bits have to be repeated in all rules.

                                                                                          Note

                                                                                          In the future we hope to add the ability to nest rules, which is going to address some of the limitations of flat mode without introducing the most complex bits of the standard cascading mode

                                                                                          "},{"location":"styling/css/cascading/#comparing-cascading-vs-flat-modes-an-example","title":"Comparing cascading vs flat modes, an example","text":"

                                                                                          Consider the following CSS:

                                                                                          * { stroke: black; stroke-width: 10 }\n\n[cat = 'important'] { stroke: yellow; }\n

                                                                                          If the above style is translated in cascading mode, it will generate two mutually exclusive SLD rules:

                                                                                          • One applying a 10px wide yellow stroke on all features whose cat attribute is 'important'
                                                                                          • One applying a 10px wide black stroke on all feature whose cat attribute is not 'important'

                                                                                          Thus, each feature will be painted by a single line, either yellow or black.

                                                                                          If instead the style contains a @mode 'Flat' directive at the top, it will generated two non mutually exclusive SLD rules:

                                                                                          • One applying a 10px wide black stroke on all features
                                                                                          • One applying a 1px wide yewllow stroke on all feature whose cat attribute is 'important'

                                                                                          Thus, all features will at least be painted 10px black, but the 'important' ones will also have a second 1px yellow line on top of the first one

                                                                                          "},{"location":"styling/css/directives/","title":"Directives","text":"

                                                                                          A directive is a CSS top level declaration that allows control of some aspects of the stylesheet application or translation to SLD. All directives are declared at the beginning of the CSS sheet and follow the same syntax:

                                                                                          @name value;\n

                                                                                          For example:

                                                                                          @mode 'Flat';\n@styleName 'The name';\n@styleTitle 'The title;\n@styleAbstract 'This is a longer description'\n\n* { \n  stroke: black \n}\n\n[cat = 10] { \n  stroke: yellow; stroke-width: 10 \n}\n
                                                                                          "},{"location":"styling/css/directives/#supported-directives","title":"Supported directives","text":"Directive Type Meaning Accepts Expression? mode String, Exclusive, Simple, Auto, Flat Controls how the CSS is translated to SLD. Exclusive, Simple and Auto are cascaded modes, Flat turns off cascading and has the CSS behave like a simplified syntax SLD sheet. See Understanding Cascading in CSS for an explanation of how the various modes work false styleName String The generated SLD style name No styleTitle String The generated SLD style title No styleAbstract String The generated SLD style abstract/description No"},{"location":"styling/css/filters/","title":"Filter syntax","text":"

                                                                                          Filters limit the set of features affected by a rule's properties. There are several types of simple filters, which can be combined to provide more complex filters for rules.

                                                                                          "},{"location":"styling/css/filters/#combining-filters","title":"Combining filters","text":"

                                                                                          Combination is done in the usual CSS way. A rule with two filters separated by a comma affects any features that match either filter, while a rule with two filters separated by only whitespace affects only features that match both filters. Here's an example using a basic attribute filter (described below):

                                                                                          /* Matches places where the lake is flooding */\n[rainfall>12] [lakes>1] {\n    fill: black;\n}\n\n/* Matches wet places */\n[rainfall>12], [lakes>1] {\n    fill: blue;\n}\n

                                                                                          When writing a selector that uses both and and or combinators, remember that the and combinator has higher precedence. For example:

                                                                                          restricted [cat='2'], [cat='3'], [cat='4'] [@sd <= 200k] [@sd > 100k] {\n  fill: #EE0000;\n}\n

                                                                                          The above selector should be read as:

                                                                                          • typename is 'restricted' and cat='2' or
                                                                                          • cat='3' or
                                                                                          • cat='4' and scale is between 100000 and 200000

                                                                                          If instead the intention was to combine in or just the three cat filters, the right syntax would have been:

                                                                                          restricted [cat='2' or cat='3' or cat='4'] [@sd <= 200k] [@sd > 100k] {\n  fill: #EE0000;\n}\n

                                                                                          Which should be read as:

                                                                                          • typename is 'restricted' and
                                                                                          • (cat='2' or cat='3' or cat='4') and
                                                                                          • scale is between 100000 and 200000
                                                                                          "},{"location":"styling/css/filters/#filtering-on-data-attributes","title":"Filtering on data attributes","text":"

                                                                                          An attribute filter matches some attribute of the data (for example, a column in a database table). This is probably the most common type of filter. An attribute filter takes the form of an attribute name and a data value separated by some predicate operator (such as the less-than operator <).

                                                                                          Supported predicate operators include the following:

                                                                                          Operator Meaning = The property must be exactly equal to the specified value. <> The property must not be exactly equal to the specified value. > The property must be greater than (or alphabetically later than) the specified value. >= The property must be greater than or equal to the specified value. < The property must be less than (or alphabetically earlier than) the specified value. <= The property must be less than or equal to the specified value. LIKE The property must match the pattern described by the specified value. Patterns use _ to indicate a single unspecified character and % to indicate an unknown number of unspecified characters.

                                                                                          For example, to only render outlines for the states whose names start with letters in the first half of the alphabet, the rule would look like:

                                                                                          [STATE_NAME<='M'] {\n    stroke: black;\n}\n

                                                                                          Note

                                                                                          The current implementation of property filters uses ECQL syntax, described on the GeoTools documentation.

                                                                                          "},{"location":"styling/css/filters/#filtering-on-type","title":"Filtering on type","text":"

                                                                                          When dealing with data from multiple sources, it may be useful to provide rules that only affect one of those sources. This is done very simply; just specify the name of the layer as a filter:

                                                                                          states {\n    stroke: black;\n}\n
                                                                                          "},{"location":"styling/css/filters/#filtering-by-id","title":"Filtering by ID","text":"

                                                                                          For layers that provide feature-level identifiers, you can style specific features simply by specifying the ID. This is done by prefixing the ID with a hash sign (#):

                                                                                          #states.2 {\n    stroke: black;\n}\n

                                                                                          Note

                                                                                          In CSS, the . character is not allowed in element ids; and the #states.foo selector matches the element with id states only if it also has the class foo. Since this form of identifier comes up so frequently in GeoServer layers, the CSS module deviates from standard CSS slightly in this regard. Future revisions may use some form of munging to avoid this deviation.

                                                                                          "},{"location":"styling/css/filters/#filtering-by-rendering-context-scale","title":"Filtering by rendering context (scale)","text":"

                                                                                          Often, there are aspects of a map that should change based on the context in which it is being viewed. For example, a road map might omit residential roads when being viewed at the state level, but feature them prominently at the neighborhood level. Details such as scale level are presented as pseudo-attributes; they look like property filters, but the property names start with an @ symbol:

                                                                                          [roadtype = 'Residential'][@sd > 100k] {\n    stroke: black;\n}\n

                                                                                          The context details that are provided are as follows:

                                                                                          Pseudo-Attribute Meaning @sd The scale denominator for the current rendering. More explicitly, this is the ratio of real-world distance to screen/rendered distance. @scale Same as above, the scale denominator (not scale) for the current rendering. Supported for backwards compatibility

                                                                                          The scale value can be expressed as a plain number, for for brevity and readability the suffixes k (kilo), M (mega), G (giga) can be used, for example:

                                                                                          [@sd > 100k]\n[@sd < 12M]\n[@sd < 1G]\n

                                                                                          Note

                                                                                          While property filters (currently) use the more complex ECQL syntax, pseudo-attributes cannot use complex expressions and MUST take the form of ."},{"location":"styling/css/filters/#filtering-symbols","title":"Filtering symbols","text":"

                                                                                          When using symbols to create graphics inline, you may want to apply some styling options to them. You can specify style attributes for built-in symbols by using a few special selectors:

                                                                                          PseudoSelector Meaning :mark specifies that a rule applies to symbols used as point markers :stroke specifies that a rule applies to symbols used as stroke patterns :fill specifies that a rule applies to symbols used as fill patterns :symbol specifies that a rule applies to any symbol, regardless of which context it is used in :nth-mark(n) specifies that a rule applies to the symbol used for the nth stacked point marker on a feature. :nth-stroke(n) specifies that a rule applies to the symbol used for the nth stacked stroke pattern on a feature. :nth-fill(n) specifies that a rule applies to the symbol used for the nth stacked fill pattern on a feature. :nth-symbol(n) specifies that a rule applies to the symbol used for the nth stacked symbol on a feature, regardless of which context it is used in.

                                                                                          For more discussion on using these selectors, see Styled marks.

                                                                                          "},{"location":"styling/css/filters/#global-rules","title":"Global rules","text":"

                                                                                          Sometimes it is useful to have a rule that matches all features, for example, to provide some default styling for your map (remember, by default nothing is rendered). This is accomplished using a single asterisk * in place of the usual filter. This catch-all rule can be used in complex expressions, which may be useful if you want a rule to provide defaults as well as overriding values for some features:

                                                                                          * {\n    stroke: black;\n}\n
                                                                                          "},{"location":"styling/css/install/","title":"Installing the GeoServer CSS extension","text":"

                                                                                          The CSS extension is listed among the other extension downloads on the GeoServer download page.

                                                                                          The installation process is similar to other GeoServer extensions:

                                                                                          1. Download the css

                                                                                            Verify that the version number in the filename corresponds to the version of GeoServer you are running (for example 2.24.2 above).

                                                                                          2. Extract the contents of the archive into the WEB-INF/lib directory in GeoServer. Make sure you do not create any sub-directories during the extraction process.

                                                                                          3. Restart GeoServer.

                                                                                          If installation was successful, you will see a new CSS entry in the Styles editor.

                                                                                          CSS format in the new style page

                                                                                          After installation, you may wish to read the tutorial: Styling data with CSS.

                                                                                          "},{"location":"styling/css/metadata/","title":"Metadata","text":"

                                                                                          One feature that appears in SLD that has no analog in CSS is the ability to provide metadata for styles and style rules. For example, this SLD embeds a title for its single rule:

                                                                                          <?xml version=\"1.0\" encoding=\"ISO-8859-1\"?>\n<StyledLayerDescriptor version=\"1.0.0\" \n    xmlns=\"http://www.opengis.net/sld\" \n    xmlns:ogc=\"http://www.opengis.net/ogc\"\n    xmlns:xlink=\"http://www.w3.org/1999/xlink\" \n    xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" \n    xmlns:gml=\"http://www.opengis.net/gml\"\n    xsi:schemaLocation=\"http://www.opengis.net/sld \n        http://schemas.opengis.net/sld/1.0.0/StyledLayerDescriptor.xsd\"\n>\n  <NamedLayer>\n    <Name>Country Borders</Name>\n    <UserStyle>\n      <Name>borders</Name>\n      <Title>Country Borders</Title>\n      <Abstract>\n          Borders of countries, in an appropriately sovereign aesthetic.\n      </Abstract>\n      <FeatureTypeStyle>\n        <Rule>\n          <Title>Borders</Title>\n          <LineSymbolizer>\n            <Stroke>\n              <CssParameter name=\"stroke-width\">0.2</CssParameter>\n            </Stroke>\n          </LineSymbolizer>\n        </Rule>\n     </FeatureTypeStyle>\n    </UserStyle>\n  </NamedLayer>\n</StyledLayerDescriptor>\n

                                                                                          Software such as GeoServer can use this metadata to automatically generate nice legend images directly from the style. You don't have to give up this ability when styling maps in CSS; just add comment before your rules including lines that start with @title and @abstract. Here is the analogous style in CSS:

                                                                                          /*\n * @title This is a point layer.\n * @abstract This is an abstract point layer.\n */\n* {\n    mark: mark(circle);\n}\n

                                                                                          Rules can provide either a title, an abstract, both, or neither. The SLD Name for a rule is autogenerated based on the filters from the CSS rules that combined to form it, for aid in troubleshooting.

                                                                                          "},{"location":"styling/css/metadata/#combined-rules","title":"Combined rules","text":"

                                                                                          One thing to keep in mind when dealing with CSS styles is that multiple rules may apply to the same subset of map features, especially as styles get more complicated. Metadata is inherited similarly to CSS properties, but metadata fields are combined instead of overriding less specific rules. That means that when you have a style like this:

                                                                                          /* @title Borders */\n* {\n    stroke: black;\n}\n\n/* @title Parcels */\n[category='parcel'] {\n    fill: blue;\n}\n

                                                                                          The legend entry for parcels will have the title 'Parcels with Borders'. If you don't like this behavior, then only provide titles for the most specific rules in your style. (Or, suggest something better in an issue report!) Rules that don't provide titles are simply omitted from title aggregation.

                                                                                          "},{"location":"styling/css/multivalueprops/","title":"Multi-valued properties","text":"

                                                                                          When rendering maps, it is sometimes useful to draw the same feature multiple times. For example, you might want to stroke a roads layer with a thick line and then a slimmer line of a different color to create a halo effect.

                                                                                          In GeoServer's css module, all properties may have multiple values. There is a distinction between complex properties, and multi-valued properties. Complex properties are separated by spaces, while multi-valued properties are separated by commas. So, this style fills a polygon once:

                                                                                          * {\n    fill: url(\"path/to/img.png\") red;\n}\n

                                                                                          Using red as a fallback color if the image cannot be loaded. If you wanted to draw red on top of the image, you would have to style like so:

                                                                                          * {\n    fill: url(\"path/to/img.png\"), red;\n    /* set a transparency for the second fill,\n       leave the first fully opaque. */\n    fill-opacity: 100%, 20%;\n}\n

                                                                                          For each type of symbolizer (fill, mark, stroke, and label) the number of values determines the number of times the feature will be drawn. For example, you could create a bulls-eye effect by drawing multiple circles on top of each other with decreasing sizes:

                                                                                          * {\n    mark: symbol(circle), symbol(circle), symbol(circle), symbol(circle);\n    mark-size: 40px, 30px, 20px, 10px;\n}\n

                                                                                          If you do not provide the same number of values for an auxiliary property, the list will be repeated as many times as needed to finish. So:

                                                                                          * {\n    mark: symbol(circle), symbol(circle), symbol(circle), symbol(circle);\n    mark-size: 40px, 30px, 20px, 10px;\n    mark-opacity: 12%;\n}\n

                                                                                          makes all those circles 12% opaque. (Note that they are all drawn on top of each other, so the center one will appear 4 times as solid as the outermost one.)

                                                                                          "},{"location":"styling/css/multivalueprops/#inheritance","title":"Inheritance","text":"

                                                                                          For purposes of inheritance/cascading, property lists are treated as indivisible units. For example:

                                                                                          * {\n    stroke: red, green, blue;\n    stroke-width: 10px, 6px, 2px;\n}\n\n[type='special'] {\n    stroke: pink;\n}\n

                                                                                          This style will draw the 'special' features with only one outline. It has stroke-width: 10px, 6px, 2px; so that outline will be 10px wide.

                                                                                          "},{"location":"styling/css/nested/","title":"Nested rules","text":"

                                                                                          Starting with GeoServer 2.10 the CSS modules supports rule nesting, that is, a child rule can be written among properties of a parent rule. The nested rules inherits the parent rule selector and properties, adding its own extra selectors and property overrides.

                                                                                          Each nested rule can be written as normal, however, if other rules or properties follow, it must be terminated with a semicolon (this char being the separator in the CSS language).

                                                                                          Nesting is a pure syntax improvement, as such it does not actually provide extra functionality, besides more compact and hopefully readable styles.

                                                                                          This is an example of a CSS style using only cascading to get a different shape, fill and stroke color for a point symbol in case the type attribute equals to important:

                                                                                          [@sd < 3000] {\n  mark: symbol(circle)\n}\n\n[@sd < 3000] :mark {\n  fill: gray;\n  size: 5\n}\n\n[@sd < 3000] [type = 'important'] {\n  mark: symbol('triangle')\n}\n\n[@sd < 3000] [type = 'important'] :mark {\n  fill: red;\n  stroke: yellow\n}\n

                                                                                          This second version uses rule nesting getting a more compact expression, putting related symbology element close by:

                                                                                          [@sd < 3000] {\n   mark: symbol(circle);\n   :mark {\n      fill: gray;\n      size: 5\n   };\n   [type = 'important'] {\n      mark: symbol(triangle);\n      :mark {\n        fill: red;\n        stroke: yellow\n      }\n   }\n}\n
                                                                                          "},{"location":"styling/css/properties/","title":"Property listing","text":"

                                                                                          This page lists the supported rendering properties. See CSS value types for more information about the value types for each.

                                                                                          "},{"location":"styling/css/properties/#css_properties_point","title":"Point symbology","text":"Property Type Meaning Accepts Expression? mark url, symbol The image or well-known shape to render for points yes mark-composite string The composite mode to be used and the optional opacity separated with a comma. See the full list of available modes. no mark-mime string (MIME Type) The type of the image referenced by a url() No, defaults to 'image/jpeg' mark-geometry expression An expression to use for the geometry when rendering features yes mark-size length The width to assume for the provided image. The height will be adjusted to preserve the source aspect ratio. yes mark-rotation angle A rotation to be applied (clockwise) to the mark image. yes z-index integer Controls the z ordering of output no mark-label-obstacle boolean If true the point symbol will be considered an obstacle for labels, no label will overlap it no mark-anchor expression The part of the mark to place over the point or middle of the polygon. This takes 2 values - x y where x=0 is the left edge of the label, x=1 is the right edge. y=0 is the bottom edge of the label, y=1 is the top edge. Specify 0.5 0.5 to centre a label. yes mark-offset expression This is for fine-tuning mark-anchor. x and y values specify pixel offsets to adjust the mark position. yes"},{"location":"styling/css/properties/#css_properties_line","title":"Line symbology","text":"Property Type Meaning Accepts Expression? stroke color, url, symbol The color, graphic, or well-known shape to use to stroke lines or outlines yes stroke-composite string The composite mode to be used and the optional opacity separated with a comma. See the full list of available modes. no stroke-geometry expression An expression to use for the geometry when rendering features. yes stroke-offset expression Draws a parallel line using the specified distance, positive values offset left, negative right. yes stroke-mime string (MIME Type) The type of the image referenced by a url() No, defaults to 'image/jpeg' stroke-opacity percentage A value in the range of 0 (fully transparent) to 1.0 (fully opaque) yes stroke-width length The width to use for stroking the line. yes stroke-size length An image or symbol used for the stroke pattern will be stretched or squashed to this size before rendering. If this value differs from the stroke-width, the graphic will be repeated or clipped as needed. yes stroke-rotation angle A rotation to be applied (clockwise) to the stroke image. See also the stroke- repeat property. yes stroke-linecap keyword: butt, square, round The style to apply to the ends of lines drawn yes stroke-linejoin keyword: miter, round, bevel The style to apply to the \"elbows\" where segments of multi-line features meet. yes stroke-dasharray list of lengths The lengths of segments to use in a dashed line. no stroke-dashoffset length How far to offset the dash pattern from the ends of the lines. yes stroke-repeat keyword: repeat, stipple How to use the provided graphic to paint the line. If repeat, then the graphic is repeatedly painted along the length of the line (rotated appropriately to match the line's direction). If stipple, then the line is treated as a polygon to be filled. yes z-index integer Controls the z ordering of output no stroke-label-obstacle boolean If true the line will be considered an obstacle for labels, no label will overlap it no"},{"location":"styling/css/properties/#css_properties_polygon","title":"Polygon symbology","text":"Property Type Meaning Accepts Expression? fill color, url, symbol The color, graphic, or well-known shape to use to stroke lines or outlines yes fill-composite string The composite mode to be used and the optional opacity separated with a comma. See the full list of available modes. no fill-geometry expression An expression to use for the geometry when rendering features. yes fill-mime string (MIME Type) The type of the image referenced by a url() No, defaults to 'image/jpeg' fill-opacity percentage A value in the range of 0 (fully transparent) to 1.0 (fully opaque) yes fill-size length The width to assume for the image or graphic provided. yes fill-rotation angle A rotation to be applied (clockwise) to the fill image. yes z-index integer Controls the z ordering of output no fill-label-obstacle boolean If true the polygon will be considered an obstacle for labels, no label will overlap it no graphic-margin List of lengths A list of 1 to 4 values, specifying the space between repeated graphics in a texture paint. One value is uniform spacing in all directions, two values are considered top/bottom and right/left, three values are considered top, right/left, bottom, four values are read as top,right,bottom,left. no random none,grid,free Activates random distribution of symbols in a texture fill tile. See Fills with randomized symbols for details. Defaults to \"none\" no random-seed integer number The seed for the random generator. Defaults to 0 no random-rotation none/free When set to \"free\" activates random rotation of the symbol in addition to random distribution. Defaults to \"none\" no random-symbol-count positive integer number Number of symbols to be placed in the texture fill tile. May not be respected due to location conflicts (no two symbols are allowed to overlap). Defaults to 16. no random-tile-size positive integer number Size of the texture paint tile that will be filled with the random symbols. Defaults to 256. no"},{"location":"styling/css/properties/#css_properties_text1","title":"Text symbology (labelling) - part 1","text":"Property Type Meaning Accepts Expression? label string The text to display as labels for features yes label-geometry expression An expression to use for the geometry when rendering features. yes label-anchor expression The part of the label to place over the point or middle of the polygon. This takes 2 values - x y where x=0 is the left edge of the label, x=1 is the right edge. y=0 is the bottom edge of the label, y=1 is the top edge. Specify 0.5 0.5 to centre a label. yes label-offset expression This is for fine-tuning label-anchor. x and y values specify pixels to adjust the label position. For lines, a single value will make the label be parallel to the line, at the given distance, while two values will force a point style placement, with the label painted horizontally at the center of the line (plus the given offsets) yes label-rotation expression Clockwise rotation of label in degrees. yes label-z-index expression Used to determine which labels are drawn on top of other labels. Lower z-indexes are drawn on top. yes shield mark, symbol A graphic to display behind the label, such as a highway shield. yes shield-mime string (MIME Type) The type of the image referenced by a url() No, defaults to 'image/jpeg' shield-placement one of label, independent, defaults to label Placement of the shield relative to the label. The default is label, meaning the shield will move along with the label and be centered with it (classic road shield). independent places the shield independently instead, using its own anchor and offset properties. The latter is useful to build \"point and label\" compositions (e.g., city labels) so that the point won't show up if the label does not (as an alternative to a mark and label setup, where the mark will always show up). no shield-anchor expression The part of the shield to place over the point or middle of the polygon. This takes 2 values - x y where x=0 is the left edge of the label, x=1 is the right edge. y=0 is the bottom edge of the label, y=1 is the top edge. Specify 0.5 0.5 to centre a label. This property activates only if the shield-placement one is set to independent, otherwise the shield will be centered with the label. yes shield-offset expression This is for fine-tuning shield-anchor. x and y values specify pixels to adjust the shield position. This property activates only if the shield-placement one is set to independent, otherwise the shield will be centered with the label. yes font-family string The name of the font or font family to use for labels yes font-fill fill The fill to use when rendering fonts yes font-style keyword: normal, italic, oblique The style for the lettering yes font-weight keyword: normal, bold The weight for the lettering yes font-size length The size for the font to display. yes font-opacity percentage The opacity of the text, from 0 (fully transparent) to 1.0 (fully opaque). yes halo-radius length The size of a halo to display around the lettering (to enhance readability). This is required to activate the halo feature. yes halo-color color The color for the halo yes halo-opacity percentage The opacity of the halo, from 0 (fully transparent) to 1.0 (fully opaque). yes label-padding length The amount of 'padding' space to provide around labels. Labels will not be rendered closer together than this threshold. This is equivalent to the spaceAround<labeling_space_around> vendor parameter. no label-group one of: true or false If true, the render will treat features with the same label text as a single feature for the purpose of labelling. This is equivalent to the group<labeling_group> vendor parameter. no label-max-displacement length If set, this is the maximum displacement that the renderer will apply to a label. Labels that need larger displacements to avoid collisions will simply be omitted. This is equivalent to the maxDisplacement<labeling_max_displacement> vendor parameter. no"},{"location":"styling/css/properties/#css_properties_text2","title":"Text symbology (labelling) - part 2","text":"Property Type Meaning Accepts Expression? label-min-group-distance length This is equivalent to the minGroupDistance vendor parameter in SLD. no label-repeat length If set, the renderer will repeat labels at this interval along a line. This is equivalent to the repeat<labeling_repeat> vendor parameter. no label-all-group one of true or false when using grouping, whether to label only the longest line that could be built by merging the lines forming the group, or also the other ones. This is equivalent to the allGroup<labeling_all_group> vendor parameter. no label-remove-overlaps one of true or false If enabled, the renderer will remove overlapping lines within a group to avoid duplicate labels. This is equivalent to the removeOverlaps vendor parameter. no label-allow-overruns one of true or false Determines whether the renderer will show labels that are longer than the lines being labelled. This is equivalent to the allowOverrun vendor parameter. no label-follow-line one of true or false If enabled, the render will curve labels to follow the lines being labelled. This is equivalent to the followLine<labeling_follow_line> vendor parameter. no label-max-angle-delta one of true or false The maximum amount of curve allowed between two characters of a label; only applies when 'follow-line: true' is set. This is equivalent to the maxAngleDelta<labeling_max_angle_delta> vendor parameter. no label-auto-wrap length Labels will be wrapped to multiple lines if they exceed this length in pixels. This is equivalent to the autoWrap<labeling_autowrap> vendor parameter. no label-force-ltr one of true or false By default, the renderer will flip labels whose normal orientation would cause them to be upside-down. Set this parameter to false if you are using some icon character label like an arrow to show a line's direction. This is equivalent to the forceLeftToRight<labeling_force_left_to_right> vendor parameter. no label-conflict-resolution one of true or false Set this to false to disable label conflict resolution, allowing overlapping labels to be rendered. This is equivalent to the conflictResolution<labeling_conflict_resolution> vendor parameter. no label-fit-goodness scale The renderer will omit labels that fall below this \"match quality\" score. The scoring rules differ for each geometry type. This is equivalent to the goodnessOfFit<labeling_goodness_of_fit> vendor parameter. no label-priority expression Specifies an expression to use in determining which features to prefer if there are labelling conflicts. This is equivalent to the Priority<labeling_priority> SLD extension. yes"},{"location":"styling/css/properties/#css_properties_text3","title":"Text symbology (labelling) - part 3","text":"Property Type Meaning Accepts Expression? shield-resize string, one of none, stretch, or proportional Specifies a mode for resizing label graphics (such as highway shields) to fit the text of the label. The default mode, 'none', never modifies the label graphic. In stretch mode, GeoServer will resize the graphic to exactly surround the label text, possibly modifying the image's aspect ratio. In proportional mode, GeoServer will expand the image to be large enough to surround the text while preserving its original aspect ratio. none shield-margin list of lengths, one to four elements long. Specifies an extra margin (in pixels) to be applied to the label text when calculating label dimensions for use with the shield-resize option. Similar to the margin shorthand property in CSS for HTML, its interpretation varies depending on how many margin values are provided: 1 = use that margin length on all sides of the label 2 = use the first for top & bottom margins and the second for left & right margins. 3 = use the first for the top margin, second for left & right margins, third for the bottom margin. 4 = use the first for the top margin, second for the right margin, third for the bottom margin, and fourth for the left margin. none label-underline-text one of true or false If enabled, the renderer will underline labels. This is equivalent to the underlineText vendor parameter. no label-strikethrough-text one of true or false If enabled, the renderer will strikethrough labels. This is equivalent to the strikethroughText vendor parameter. no label-char-spacing an amount of pixels, can be negative If present, expands or shrinks the space between subsequent characters in a label according to the value specified no label-word-spacing an amount of pixels, must be zero or positive If present, expands the space between subsequent words in a label according to the value specified no"},{"location":"styling/css/properties/#css_properties_raster","title":"Raster symbology","text":"Property Type Meaning Accepts Expression? raster-channels string The list of raster channels to be used in the output. It can be \"auto\" to make the renderer choose the best course of action, or a list of band numbers, a single one will generate a gray image, three will generate an RGB one, four will generate a RGBA one. E.g., \"1 3 7\" to choose the first, third and seventh band of the input raster to make an RGB image no raster-composite string The composite mode to be used and the optional opacity separated with a comma. See the full list of available modes. no raster-geometry expression The attribute containing the raster to be painted. Normally not needed, but it would work if you had a custom vector data source that contains a GridCoverage attribute, in order to select it yes raster-opacity floating point A value comprised between 0 and 1, 0 meaning completely transparent, 1 meaning completely opaque. This controls the whole raster transparency. no raster-contrast-enhancement string Allows to stretch the range of data/colors in order to enhance tiny differences. Possible values are 'normalize', 'histogram' and 'none' no raster-gamma floating point Gamma adjustment for the output raster no raster-z-index integer Controls the z ordering of the raster output no raster-color-map string Applies a color map to single banded input. The contents are a space separate list of color-map-entry(color, value) (opacity assumed to be 1 and label will have a null value), or color-map-entry(color, value, opacity, label). The values must be provided in increasing order. no raster-color-map-type string Controls how the color map entries are interpreted, the possible values are \"ramp\", \"intervals\" and \"values\", with ramp being the default if no \"raster-color-map-type\" is provided. The default \"ramp\" behavior is to linearly interpolate color between the provided values, and assign the lowest color to all values below the lowest value, and the highest color to all values above the highest value. The \"intervals\" behavior instead assigns solid colors between values, whilst \"values\" only assigns colors to the specified values, every other value in the raster is not painted at all no raster-color-map-extended string Enables \"extended color map\" mode, which makes the color map use 65536 entries instead of 256, and thus allows for a more precise color mapping. The default is \"false\", which means the color map is limited to 256 entries (if more than 256 colors are used, the extended color map mode is enabled automatically). This property is ignored if the \"raster-color-map\" property is not provided. no raster-label-fi string Controls if and how color map entry labels are included, as attributes, in the GetFeatureInfo output. Valid values are add, adding the labels as extra attributes, replace, using the labels in place of the actual value, or none (the default) which does not include the labels in the output. no raster-label-name string If color map entry labels are included in the GetFeatureInfo output, this property controls then name of the attribute that will contain them. no"},{"location":"styling/css/properties/#css_properties_shared","title":"Shared","text":"Property Type Meaning Accepts Expression? composite string The composite mode to be used and the optional opacity separated with a comma. See the full list of available modes. no composite-base one of true or false This will tell the rendering engine to use that FeatureTypeStyle as the destination, and will compose all subsequent FeatureTypeStyle/Layers on top of it, until another base is found. no geometry expression An expression to use for the geometry when rendering features. This provides a geometry for all types of symbology, but can be overridden by the symbol-specific geometry properties. yes sort-by string A comma separated list of sorting directives, att1 A|D, att2 A|D, ... where att? are attribute names, and A or D are an optional direction specification, A is ascending, D is descending. Determines the loading, and thus painting, order of the features no sort-by-group string Rules with the different z-index but same sort-by-group id have their features sorted as a single group. Useful to z-order across layers or across different feature groups, like roads and rails, especially when using z-index to support casing no transform function Applies a rendering transformation on the current level. The function syntax is txName(key1:value1,key1:value2). Values can be single ones, or space separated lists. no"},{"location":"styling/css/properties/#css_properties_symbol","title":"Symbol properties","text":"

                                                                                          These properties are applied only when styling built-in symbols. See Styled marks for details.

                                                                                          Property Type Meaning Accepts Expression? size length The size at which to render the symbol. yes rotation angle An angle through which to rotate the symbol. yes"},{"location":"styling/css/styledmarks/","title":"Styled marks","text":"

                                                                                          GeoServer's CSS module provides a collection of predefined symbols that you can use and combine to create simple marks, strokes, and fill patterns without needing an image editing program. You can access these symbols via the symbol() CSS function. For example, the built-in circle symbol makes it easy to create a simple 'dot' marker for a point layer:

                                                                                          * {\n  mark: symbol(circle);\n}\n

                                                                                          Symbols work anywhere you can use a url() to reference an image (as in, you can use symbols for stroke and fill patterns as well as markers.)

                                                                                          "},{"location":"styling/css/styledmarks/#symbol-names","title":"Symbol names","text":"

                                                                                          GeoServer extensions can add extra symbols (such as the chart:// symbol family which allows the use of charts as symbols via a naming scheme similar to the Google Charts API). However, there are a few symbols that are always available:

                                                                                          • circle
                                                                                          • square
                                                                                          • triangle
                                                                                          • arrow
                                                                                          • cross
                                                                                          • star
                                                                                          • x
                                                                                          • shape://horizline
                                                                                          • shape://vertline
                                                                                          • shape://backslash
                                                                                          • shape://slash
                                                                                          • shape://plus
                                                                                          • shape://times
                                                                                          • windbarbs://default(size)[unit]
                                                                                          "},{"location":"styling/css/styledmarks/#symbol-selectors","title":"Symbol selectors","text":"

                                                                                          Symbols offer some additional styling options beyond those offered for image references. To specify these style properties, just add another rule with a special selector. There are 8 \"pseudoclass\" selectors that are used to style selectors:

                                                                                          • :mark specifies that a rule applies to symbols used as point markers
                                                                                          • :shield specifies that a rule applies to symbols used as label shields (icons displayed behind label text)
                                                                                          • :stroke specifies that a rule applies to symbols used as stroke patterns
                                                                                          • :fill specifies that a rule applies to symbols used as fill patterns
                                                                                          • :symbol specifies that a rule applies to any symbol, regardless of which context it is used in
                                                                                          • :nth-mark(n) specifies that a rule applies to the symbol used for the nth stacked point marker on a feature.
                                                                                          • :nth-shield(n) specifies that a rule applies to the symbol used for the background of the nth stacked label on a feature
                                                                                          • :nth-stroke(n) specifies that a rule applies to the symbol used for the nth stacked stroke pattern on a feature.
                                                                                          • :nth-fill(n) specifies that a rule applies to the symbol used for the nth stacked fill pattern on a feature.
                                                                                          • :nth-symbol(n) specifies that a rule applies to the symbol used for the nth stacked symbol on a feature, regardless of which context it is used in.

                                                                                          These pseudoclass selectors can be used in a top level rule, but starting with GeoServer 2.10, they are more commonly used in sub-rules close to the mark property, to get better readability (see example below).

                                                                                          "},{"location":"styling/css/styledmarks/#symbol-styling-properties","title":"Symbol styling properties","text":"

                                                                                          Styling a built-in symbol is similar to styling a polygon feature. However, the styling options are slightly different from those available to a true polygon feature:

                                                                                          • The mark and label families of properties are unavailable for symbols.
                                                                                          • Nested symbol styling is not currently supported.
                                                                                          • Only the first stroke and fill will be used.
                                                                                          • Additional size (as a length) and rotation (as an angle) properties are available. These are analogous to the (mark|stroke|fill)-size and (mark|stroke|fill)-rotation properties available for true geometry styling.

                                                                                          Note

                                                                                          The various prefixed '-size' and '-rotation' properties on the containing style override those for the symbol if they are present.

                                                                                          "},{"location":"styling/css/styledmarks/#example-styled-symbol","title":"Example styled symbol","text":"

                                                                                          As an example, consider a situation where you are styling a layer that includes data about hospitals in your town. You can create a simple hospital logo by placing a red cross symbol on top of a white circle background:

                                                                                          [usage='hospital'] {\n  mark: symbol('circle'), symbol('cross');\n  :nth-mark(1) {\n    size: 16px;\n    fill: white;\n    stroke: red;\n  };\n  :nth-mark(2) {\n    size: 12px;\n    fill: red;\n  }\n}\n

                                                                                          Also an windbarb example where you get wind speed and direction from your data fields horSpeed and horDir (direction):

                                                                                          * {\n  /* select windbard based on speed( here in meters per second, and south hemisphere) */\n  mark: symbol('windbarbs://default(${horSpeed})[m/s]?hemisphere=s');\n\n  /* rotate windbarb based on horDir property (in degrees) */\n  mark-rotation: [horDir];\n\n  mark-size: 20;\n}\n
                                                                                          "},{"location":"styling/css/transformation/","title":"Rendering transformations in CSS","text":"

                                                                                          Starting with GeoServer 2.10 the CSS modules supports rendering transformations via the transform property.

                                                                                          The property is a function call with a special key/value pair syntax, using the following template:

                                                                                          transformationName(key1:value1,key2:v21 v22 ... v2M,...,keyN:vN)\n

                                                                                          The values can be simple ones, or can be a space separated list. The parameter representing the input layer can be omitted, the engine will automatically recognize input parameters of type feature collection or grid coverage.

                                                                                          The transformation function is subject to cascading like all other properties, but cascading acts at the whole z-level, so if multiple transformations are needed, they need to be associated with two different z-levels.

                                                                                          This is an example of a CSS style extracting contour lines from a DEM, and also showing the single values when a suitable zoom level is reached:

                                                                                          /* @title Levels */\n* {\n  transform: ras:Contour(levels: 1100 1200 1300 1400 1500 1600 1700);\n  z-index: 0;\n  stroke: gray;\n  label: [numberFormat('#', value)];\n  font-size: 12;\n  font-fill: black;\n  font-weight: bold;\n  halo-color: white;\n  halo-radius: 2;\n  label-follow-line: true;\n  label-repeat: 200;\n  label-max-angle-delta: 45;\n  label-priority: 2000;\n}\n\n/* @title Values */\n[@sd < 12000] {\n  transform: ras:RasterAsPointCollection(scale: 0.5);\n  z-index: 1;\n  label: [GRAY_INDEX];\n  label-anchor: 0.5 0.5;\n  font-family: Arial;\n  font-fill: black;\n  font-size: 6;\n  label-priority: 1000;\n}\n

                                                                                          The two transformations in action against a DEM layer

                                                                                          "},{"location":"styling/css/tutorial/","title":"Tutorial: Styling data with CSS","text":"

                                                                                          This tutorial will show using CSS to style a layer, along with the equivalent SLD code.

                                                                                          To use this tutorial, you will need the CSS extension as well as the states layer from the default GeoServer configuration.

                                                                                          "},{"location":"styling/css/tutorial/#creating-a-style-for-the-states-layer","title":"Creating a style for the states layer","text":"

                                                                                          The SLD file for the default states layer looks like this:

                                                                                          <?xml version=\"1.0\" encoding=\"ISO-8859-1\"?>\n<StyledLayerDescriptor\n  version=\"1.0.0\"\n  xmlns=\"http://www.opengis.net/sld\" \n  xmlns:ogc=\"http://www.opengis.net/ogc\"\n  xmlns:xlink=\"http://www.w3.org/1999/xlink\"\n  xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\"\n  xmlns:gml=\"http://www.opengis.net/gml\"\n  xsi:schemaLocation=\"http://www.opengis.net/sld\n    http://schemas.opengis.net/sld/1.0.0/StyledLayerDescriptor.xsd\n\">\n  <NamedLayer>\n    <Name>USA states population</Name>\n    <UserStyle>\n      <Name>population</Name>\n      <Title>Population in the United States</Title>\n      <Abstract>A sample filter that filters the United States into three\n        categories of population, drawn in different colors</Abstract>\n      <FeatureTypeStyle>\n        <Rule>\n          <Title>&lt; 2M</Title>\n          <ogc:Filter>\n            <ogc:PropertyIsLessThan>\n             <ogc:PropertyName>PERSONS</ogc:PropertyName>\n             <ogc:Literal>2000000</ogc:Literal>\n            </ogc:PropertyIsLessThan>\n          </ogc:Filter>\n          <PolygonSymbolizer>\n             <Fill>\n                <!-- CssParameters allowed are fill (the color) and fill-opacity -->\n                <CssParameter name=\"fill\">#4DFF4D</CssParameter>\n                <CssParameter name=\"fill-opacity\">0.7</CssParameter>\n             </Fill>     \n          </PolygonSymbolizer>\n        </Rule>\n        <Rule>\n          <Title>2M - 4M</Title>\n          <ogc:Filter>\n            <ogc:PropertyIsBetween>\n              <ogc:PropertyName>PERSONS</ogc:PropertyName>\n              <ogc:LowerBoundary>\n                <ogc:Literal>2000000</ogc:Literal>\n              </ogc:LowerBoundary>\n              <ogc:UpperBoundary>\n                <ogc:Literal>4000000</ogc:Literal>\n              </ogc:UpperBoundary>\n            </ogc:PropertyIsBetween>\n          </ogc:Filter>\n          <PolygonSymbolizer>\n             <Fill>\n                <!-- CssParameters allowed are fill (the color) and fill-opacity -->\n                <CssParameter name=\"fill\">#FF4D4D</CssParameter>\n                <CssParameter name=\"fill-opacity\">0.7</CssParameter>\n             </Fill>     \n          </PolygonSymbolizer>\n        </Rule>\n        <Rule>\n          <Title>&gt; 4M</Title>\n          <!-- like a linesymbolizer but with a fill too -->\n          <ogc:Filter>\n            <ogc:PropertyIsGreaterThan>\n             <ogc:PropertyName>PERSONS</ogc:PropertyName>\n             <ogc:Literal>4000000</ogc:Literal>\n            </ogc:PropertyIsGreaterThan>\n          </ogc:Filter>\n          <PolygonSymbolizer>\n             <Fill>\n                <!-- CssParameters allowed are fill (the color) and fill-opacity -->\n                <CssParameter name=\"fill\">#4D4DFF</CssParameter>\n                <CssParameter name=\"fill-opacity\">0.7</CssParameter>\n             </Fill>     \n          </PolygonSymbolizer>\n        </Rule>\n        <Rule>\n          <Title>Boundary</Title>\n          <LineSymbolizer>\n            <Stroke>\n              <CssParameter name=\"stroke-width\">0.2</CssParameter>\n            </Stroke>\n          </LineSymbolizer>\n          <TextSymbolizer>\n            <Label>\n              <ogc:PropertyName>STATE_ABBR</ogc:PropertyName>\n            </Label>\n            <Font>\n              <CssParameter name=\"font-family\">Times New Roman</CssParameter>\n              <CssParameter name=\"font-style\">Normal</CssParameter>\n              <CssParameter name=\"font-size\">14</CssParameter>\n            </Font>\n            <LabelPlacement>\n              <PointPlacement>\n                <AnchorPoint>\n                  <AnchorPointX>0.5</AnchorPointX>\n                  <AnchorPointY>0.5</AnchorPointY>\n                </AnchorPoint>\n              </PointPlacement>\n            </LabelPlacement>\n          </TextSymbolizer>\n        </Rule>\n     </FeatureTypeStyle>\n    </UserStyle>\n    </NamedLayer>\n</StyledLayerDescriptor>\n

                                                                                          Now, let's start on a CSS file that accomplishes the same thing.

                                                                                          First, got to the styles page and click on Add a new style link to start a new style. In the \"New style\" page, do the following:

                                                                                          • Name the new style anything you'd like, such as csstutorial
                                                                                          • Choose CSS as the format
                                                                                          • In the Generate a default style dropdown choose Polygon and click on Generate...

                                                                                          Creating a new CSS style

                                                                                          This creates an example style with a source similar to this one (the colors may differ):

                                                                                          /* @title cyan polygon */\n* {\n    stroke: #000000;\n    stroke-width: 0.5;\n    fill: #0099cc;\n}\n

                                                                                          This demonstrates the basic elements of a CSS style:

                                                                                          A selector that identifies some part of the data to style. Here, the selector is *, indicating that all data should use the style properties.

                                                                                          Properties inside curly braces ({}) which specify how the affected features should be styled. Properties consist of name/value pairs separated by colons (:).

                                                                                          We can also see the basics for styling a polygon (fill), and its outline (stroke).

                                                                                          See Also

                                                                                          The Filter syntax and Property listing pages provide more information about the options available in CSS styles.

                                                                                          Before moving on, let's save the style and preview it with the states layer:

                                                                                          • Click on \"Apply\" to save the layer and enable the style preview
                                                                                          • Now on the \"Style Editor page\", switch to the \"layer preview\" tab and click on the \"previewing on layer\" link, then choose the \"states\" layer in the dialog
                                                                                          • The style editor should now show the states layer filled and stroked

                                                                                          Previewing the CSS style with the state layer

                                                                                          Let's use these basics to start translating the states style. The first rule in the SLD applies to states where the PERSONS field is less than two million:

                                                                                          <Rule>\n  <Title>&lt; 2M</Title>\n  <ogc:Filter>\n    <ogc:PropertyIsLessThan>\n     <ogc:PropertyName>PERSONS</ogc:PropertyName>\n     <ogc:Literal>2000000</ogc:Literal>\n    </ogc:PropertyIsLessThan>\n  </ogc:Filter>\n  <PolygonSymbolizer>\n     <Fill>\n        <!-- CssParameters allowed are fill (the color) and fill-opacity -->\n        <CssParameter name=\"fill\">#4DFF4D</CssParameter>\n        <CssParameter name=\"fill-opacity\">0.7</CssParameter>\n     </Fill>     \n  </PolygonSymbolizer>\n</Rule>\n

                                                                                          Using a CQL</tutorials/cql/cql_tutorial>-based selector, and copying the names and values of the CssParameters over, we get:

                                                                                          [PERSONS < 2000000] {\n  fill: #4DFF4D;\n  fill-opacity: 0.7;\n}\n

                                                                                          For the second style, we have a PropertyIsBetween filter, which doesn't directly translate to CSS:

                                                                                          <Rule>\n  <Title>2M - 4M</Title>\n  <ogc:Filter>\n    <ogc:PropertyIsBetween>\n      <ogc:PropertyName>PERSONS</ogc:PropertyName>\n      <ogc:LowerBoundary>\n        <ogc:Literal>2000000</ogc:Literal>\n      </ogc:LowerBoundary>\n      <ogc:UpperBoundary>\n        <ogc:Literal>4000000</ogc:Literal>\n      </ogc:UpperBoundary>\n    </ogc:PropertyIsBetween>\n  </ogc:Filter>\n  <PolygonSymbolizer>\n     <Fill>\n        <!-- CssParameters allowed are fill (the color) and fill-opacity -->\n        <CssParameter name=\"fill\">#FF4D4D</CssParameter>\n        <CssParameter name=\"fill-opacity\">0.7</CssParameter>\n     </Fill>     \n  </PolygonSymbolizer>\n</Rule>\n

                                                                                          However, PropertyIsBetween can easily be replaced by a combination of two comparison selectors. In CSS, you can apply multiple selectors to a rule by simply placing them one after the other. Selectors separated by only blank-space must all be satisfied for a style to apply. Multiple such groups can be attached to a rule by separating them with commas (,). If a feature matches any of the comma-separated groups for a rule then that style is applied. Thus, the CSS equivalent of the second rule is:

                                                                                          [PERSONS >= 2000000] [PERSONS < 4000000] {\n  fill: #FF4D4D;\n  fill-opacity: 0.7;\n}\n

                                                                                          The third rule can be handled in much the same manner as the first:

                                                                                          [PERSONS >= 4000000] {\n  fill: #4D4DFF;\n  fill-opacity: 0.7;\n}\n

                                                                                          The fourth and final rule is a bit different. It applies a label and outline to all the states:

                                                                                          <Rule>\n  <Title>Boundary</Title>\n  <LineSymbolizer>\n    <Stroke>\n      <CssParameter name=\"stroke-width\">0.2</CssParameter>\n    </Stroke>\n  </LineSymbolizer>\n  <TextSymbolizer>\n    <Label>\n      <ogc:PropertyName>STATE_ABBR</ogc:PropertyName>\n    </Label>\n    <Font>\n      <CssParameter name=\"font-family\">Times New Roman</CssParameter>\n      <CssParameter name=\"font-style\">Normal</CssParameter>\n      <CssParameter name=\"font-size\">14</CssParameter>\n    </Font>\n    <LabelPlacement>\n      <PointPlacement>\n        <AnchorPoint>\n          <AnchorPointX>0.5</AnchorPointX>\n          <AnchorPointY>0.5</AnchorPointY>\n        </AnchorPoint>\n      </PointPlacement>\n    </LabelPlacement>\n  </TextSymbolizer>\n</Rule>\n

                                                                                          This introduces the idea of rendering an extracted value (STATE_ABBR) directly into the map, unlike all of the rules thus far. For this, you can use a CQL expression wrapped in square braces ([]) as the value of a CSS property. It is also necessary to surround values containing blank-space, such as Times New Roman, with single- or double-quotes (\", '). With these details in mind, let's write the rule:

                                                                                          * {\n  stroke-width: 0.2;\n  label: [STATE_ABBR];\n  label-anchor: 0.5 0.5;\n  font-family: \"Times New Roman\";\n  font-fill: black;\n  font-style: normal;\n  font-size: 14;\n}\n

                                                                                          Putting it all together, you should now have a style that looks like:

                                                                                          [PERSONS < 2000000] {\n  fill: #4DFF4D;\n  fill-opacity: 0.7;\n}\n\n[PERSONS >= 2000000] [PERSONS < 4000000] {\n  fill: #FF4D4D;\n  fill-opacity: 0.7;\n}\n\n[PERSONS >= 4000000] {\n  fill: #4D4DFF;\n  fill-opacity: 0.7;\n}\n\n* {\n  stroke-width: 0.2;\n  label: [STATE_ABBR];\n  label-anchor: 0.5 0.5;\n  font-family: \"Times New Roman\";\n  font-fill: black;\n  font-style: normal;\n  font-size: 14;\n}\n

                                                                                          Click the Apply button at the bottom of the form to save your changes.

                                                                                          CSS style applied to the states layer

                                                                                          You will see that the borders are missing! In the GeoServer CSS module, each type of symbolizer has a \"key\" property which controls whether it is applied. Without these \"key\" properties, subordinate properties are ignored. These \"key\" properties are:

                                                                                          • fill, which controls whether or not Polygon fills are applied. This specified the color or graphic to use for the fill.
                                                                                          • stroke, which controls whether or not Line and Polygon outline strokes are applied. This specifies the color (or graphic fill) of the stroke.
                                                                                          • mark, which controls whether or not point markers are drawn. This identifies a Well-Known Mark or image URL to use.
                                                                                          • label, which controls whether or not to draw labels on the map. This identifies the text to use for labelling the map, usually as a CQL expression.
                                                                                          • halo-radius, which controls whether or not to draw a halo around labels. This specifies how large such halos should be.

                                                                                          See Also

                                                                                          The Property listing page for information about the other properties.

                                                                                          Since we don't specify a stroke color, no stroke is applied. Let's add it, replacing the final rule so that it will now look like this:

                                                                                          * {\n  stroke: black;\n  stroke-width: 0.2;\n  label: [STATE_ABBR];\n  label-anchor: 0.5 0.5;\n  font-family: \"Times New Roman\";\n  font-fill: black;\n  font-style: normal;\n  font-size: 14;\n}\n

                                                                                          Border added to style

                                                                                          "},{"location":"styling/css/tutorial/#refining-the-style","title":"Refining the style","text":""},{"location":"styling/css/tutorial/#removing-duplicated-properties","title":"Removing duplicated properties","text":"

                                                                                          The style that we have right now is only 23 lines, a nice improvement over the 103 lines of XML that we started with. However, we are still repeating the fill-opacity attribute everywhere.

                                                                                          We can move it into the * rule and have it applied everywhere. This works because the GeoServer CSS module emulates cascading: While SLD uses a \"painter's model\" where each rule is processed independently, a cascading style allows you to provide general style properties and override only specific properties for particular features.

                                                                                          This brings the style down to only 21 lines:

                                                                                          [PERSONS < 2000000] {\n  fill: #4DFF4D;\n}\n\n[PERSONS > 2000000] [PERSONS < 4000000] {\n  fill: #FF4D4D;\n}\n\n[PERSONS > 4000000] {\n  fill: #4D4DFF;\n}\n\n* {\n  fill-opacity: 0.7;\n  stroke-width: 0.2;\n  label: [STATE_ABBR];\n  label-anchor: 0.5 0.5;\n  font-family: \"Times New Roman\";\n  font-fill: black;\n  font-style: normal;\n  font-size: 14;\n}\n
                                                                                          "},{"location":"styling/css/tutorial/#scale-dependent-styles","title":"Scale-dependent styles","text":"

                                                                                          The labels for this style are nice, but at lower zoom levels they seem a little crowded. We can easily move the labels to a rule that doesn't activate until the scale denominator is below 2000000. We do want to keep the stroke and fill-opacity at all zoom levels, so we can separate them from the label properties.

                                                                                          Keep the following properties in the main (*) rule:

                                                                                          * {\n  fill-opacity: 0.7;\n  stroke-width: 0.2;\n}\n

                                                                                          Remove all the rest, moving them into a new rule:

                                                                                          [@sd < 20M] {\n  label: [STATE_ABBR];\n  label-anchor: 0.5 0.5;\n  font-family: \"Times New Roman\";\n  font-fill: black;\n  font-style: normal;\n  font-size: 14;\n}\n
                                                                                          "},{"location":"styling/css/tutorial/#setting-titles-for-the-legend","title":"Setting titles for the legend","text":"

                                                                                          So far, we haven't set titles for any of the style rules. This doesn't really cause any problems while viewing maps, but GeoServer uses the title in auto-generating legend graphics. Without the titles, GeoServer falls back on the names, which in the CSS module are generated from the filters for each rule. Titles are not normally a part of CSS, so GeoServer looks for them in specially formatted comments before each rule. We can add titles like this:

                                                                                          /* @title Population < 2M */\n[PERSONS < 2000000] {\n\n  ...\n\n/* @title 2M < Population < 4M */\n[PERSONS > 2000000] [PERSONS < 4000000] {\n\n  ...\n\n/* @title Population > 4M */\n[PERSONS > 4000000] {\n\n  ...\n\n\n/* @title Boundaries */\n* {\n\n  ...\n

                                                                                          Because of the way that CSS is translated to SLD, each SLD rule is a combination of several CSS rules. This is handled by combining the titles with the word \"with\". If the title is omitted for a rule, then it is simply not included in the SLD output.

                                                                                          The final CSS should look like this:

                                                                                          /* @title Population < 2M */\n[PERSONS < 2000000] {\n  fill: #4DFF4D;\n  fill-opacity: 0.7;\n}\n\n/* @title 2M < Population < 4M */\n[PERSONS >= 2000000] [PERSONS < 4000000] {\n  fill: #FF4D4D;\n  fill-opacity: 0.7;\n}\n\n/* @title Population > 4M */\n[PERSONS >= 4000000] {\n  fill: #4D4DFF;\n  fill-opacity: 0.7;\n}\n\n\n/* @title Boundaries */\n* {\n  stroke: black;\n  stroke-width: 0.2;\n  fill-opacity: 0.7;\n}\n\n[@sd < 20M] {\n  label: [STATE_ABBR];\n  label-anchor: 0.5 0.5;\n  font-family: \"Times New Roman\";\n  font-fill: black;\n  font-style: normal;\n  font-size: 14;\n}\n

                                                                                          Final style with rule names

                                                                                          "},{"location":"styling/css/tutorial/#applying-rule-nesting","title":"Applying rule nesting","text":"

                                                                                          As a final variation, the style can be made more compact by leveraging rule nesting:

                                                                                          * {\n  stroke: black;\n  stroke-width: 0.2;\n  fill-opacity: 0.7;\n\n  /* @title Population < 2M */\n  [PERSONS < 2000000] {\n    fill: #4DFF4D;\n  };\n  /* @title 2M < Population < 4M */\n  [PERSONS >= 2000000] [PERSONS < 4000000] {\n    fill: #FF4D4D;\n  };\n  /* @title Population > 4M */\n  [PERSONS >= 4000000] {\n    fill: #4D4DFF;\n  };\n\n  /* Labelling */\n  [@sd < 20M] {\n    label: [STATE_ABBR];\n    label-anchor: 0.5 0.5;\n    font-family: \"Times New Roman\";\n    font-fill: black;\n    font-style: normal;\n    font-size: 14;\n  }   \n}\n
                                                                                          "},{"location":"styling/css/tutorial/#css-workshop","title":"CSS Workshop","text":"

                                                                                          For more details, visit the next section, the CSS workshop. This workshop has been used in the past for classroom settings to teach the CSS extension and has been ported to the user documentation.

                                                                                          "},{"location":"styling/css/valuetypes/","title":"CSS value types","text":"

                                                                                          This page presents a brief overview of CSS types as used by this project. Note that these can be repeated as described in Multi-valued properties.

                                                                                          "},{"location":"styling/css/valuetypes/#numbers","title":"Numbers","text":"

                                                                                          Numeric values consist of a number, or a number annotated with a measurement value. In general, it is wise to use measurement annotations most of the time, to avoid ambiguity and protect against potential future changes to the default units.

                                                                                          Currently, the supported units include:

                                                                                          • Length
                                                                                            • px pixels
                                                                                            • m meters
                                                                                            • ft feet
                                                                                          • Angle
                                                                                            • deg degrees
                                                                                          • Ratio
                                                                                            • % percentage

                                                                                          When using expressions in place of numeric values, the first unit listed for the type of measure is assumed.

                                                                                          Since the CSS module translates styles to SLD before any rendering occurs, its model of unit-of-measure is tied to that of SLD. In practice, this means that for any particular symbolizer, there only one unit-of-measure applied for the style. Therefore, the CSS module extracts that unit-of-measure from one special property for each symbolizer type. Those types are listed below for reference:

                                                                                          • fill-size determines the unit-of-measure for polygon symbolizers (but that doesn't matter so much since it is the only measure associated with fills)
                                                                                          • stroke-width determines the unit-of-measure for line symbolizers
                                                                                          • mark-size determines the unit-of-measure for point symbolizers
                                                                                          • font-size determines the unit-of-measure for text symbolizers and the associated halos
                                                                                          "},{"location":"styling/css/valuetypes/#strings","title":"Strings","text":"

                                                                                          String values consist of a small snippet of text. For example, a string could be a literal label to use for a subset of roads:

                                                                                          [lanes>20] {\n    label: \"Serious Freaking Highway\";\n}\n

                                                                                          Strings can be enclosed in either single or double quotes. It's easiest to simply use whichever type of quotes are not in your string value, but you can escape quote characters by prefixing them with a backslash `. Backslash characters themselves must also be prefixed. For example,'\\''` is a string value consisting of a single backslash followed by a single quote character.

                                                                                          "},{"location":"styling/css/valuetypes/#labels","title":"Labels","text":"

                                                                                          While labels aren't really a special type of value, they deserve a special mention since labels are more likely to require special string manipulation than other CSS values.

                                                                                          If a label is a simple string value, then it works like any other string would:

                                                                                          [lanes > 20] {\n    label: \"Serious Freaking Highway\";\n}\n

                                                                                          However, if a label has multiple values, all of those values will be concatenated to form a single label:

                                                                                          [lanes > 20] {\n   label: \"Serious \" \"Freaking \" \"Highway\";\n}\n

                                                                                          Note the blank-space within the label strings here; no blank-space is added when concatenating strings, so you must be explicit about where you want it included. You can also mix CQL expressions in with literal string values here:

                                                                                          states {\n   label: [STATE_NAME] \" (\" [STATE_ABBR] \")\";\n}\n

                                                                                          Note

                                                                                          This automatic concatenation is currently a special feature only provided for labels. However, string concatenation is also supported directly in CQL expressions by using the strConcat filter function:

                                                                                          * { fill: [strConcat('#', color_hex)]; }\n

                                                                                          This form of concatenation works with any property that supports expressions.

                                                                                          "},{"location":"styling/css/valuetypes/#colors","title":"Colors","text":"

                                                                                          Color values are relatively important to styling, so there are multiple ways to specify them.

                                                                                          Format Interpretation #RRGGBB A hexadecimal-encoded color value, with two digits each for red, green, and blue. #RGB A hexadecimal-encoded color value, with one digits each for red, green, and blue. This is equivalent to the two-digit-per-channel encoding with each digit duplicated. rgb(r, g, b) A three-part color value with each channel represented by a value in the range 0 to 1, or in the range 0 to 255. 0 to 1 is used if any of the values include a decimal point, otherwise it is 0 to 255. Simple name The simple English name of the color. A full list of the supported colors is available at http://www.w3.org/TR/SVG/types.html#ColorKeywords"},{"location":"styling/css/valuetypes/#external-references","title":"External references","text":"

                                                                                          When using external images to decorate map features, it is necessary to reference them by URL. This is done by a call to the url function. The URL value may be wrapped in single or double-quotes, or not at all. The same escaping rules as for string values. The url function is also a special case where the surrounding quote marks can usually be omitted. Some examples:

                                                                                          /* These properties are all equivalent. */\n\n* {\n    stroke: url(\"http://example.com/\");\n    stroke: url('http://example.com/');\n    stroke: url(http://example.com/);\n}\n

                                                                                          Note

                                                                                          While relative URLs are supported, they will be fully resolved during the conversion process to SLD and written out as absolute URLs. This may be cause problems when relocating data directories, etc. The style can be regenerated with the current correct URL by opening it in the demo editor and using the Submit button there.

                                                                                          "},{"location":"styling/css/valuetypes/#well-known-marks","title":"Well-known marks","text":"

                                                                                          As defined in the SLD standard, GeoServer's css module also allows using a certain set of well-known mark types without having to provide graphic resources explicitly. These include:

                                                                                          • circle
                                                                                          • square
                                                                                          • cross
                                                                                          • star
                                                                                          • arrow

                                                                                          And others. Additionally, vendors can provide an extended set of well-known marks, a facet of the standard that is exploited by some GeoTools plugins to provide dynamic map features such as using characters from TrueType fonts as map symbols, or dynamic charting. In support of these extended mark names, the css module provides a symbol function similar to url. The syntax is the same, aside from the function name:

                                                                                          * {\n    mark: symbol(circle);\n    mark: symbol('ttf://Times+New+Roman&char=0x19b2');\n    mark: symbol(\"chart://type=pie&x&y&z\");\n}\n
                                                                                          "},{"location":"styling/css/cookbook/","title":"CSS Cookbook","text":"

                                                                                          The CSS Cookbook is a collection of CSS \"recipes\" for creating various types of map styles. Wherever possible, each example is designed to show off a single CSS feature so that code can be copied from the examples and adapted when creating CSS styles of your own. Most examples are shared with the SLD Cookbook, to make a comparison between the two syntaxes immediate.

                                                                                          The CSS Cookbook is divided into four sections: the first three for each of the vector types (points, lines, and polygons) and the fourth section for rasters. Each example in every section contains a screen-shot showing actual GeoServer WMS output and the full CSS code for reference.

                                                                                          Each section uses data created especially for the Cookbooks (both CSS and SLD), with shapefiles for vector data and GeoTIFFs for raster data. The projection for data is EPSG:4326. All files can be easily loaded into GeoServer in order to recreate the examples.

                                                                                          Data type Shapefile Point sld_cookbook_point.zip Line sld_cookbook_line.zip Polygon sld_cookbook_polygon.zip Raster sld_cookbook_raster.zip
                                                                                          • Points
                                                                                          • Lines
                                                                                          • Polygons
                                                                                          • Rasters
                                                                                          "},{"location":"styling/css/cookbook/line/","title":"Lines","text":"

                                                                                          While lines can also seem to be simple shapes, having length but no width, there are many options and tricks for making lines display nicely.

                                                                                          "},{"location":"styling/css/cookbook/line/#css_cookbook_lines_attributes","title":"Example lines layer","text":"

                                                                                          The lines layer used in the examples below contains road information for a fictional country. For reference, the attribute table for the points in this layer is included below.

                                                                                          fid (Feature ID) name (Road name) type (Road class) line.1 Latway highway line.2 Crescent Avenue secondary line.3 Forest Avenue secondary line.4 Longway highway line.5 Saxer Avenue secondary line.6 Ridge Avenue secondary line.7 Holly Lane local-road line.8 Mulberry Street local-road line.9 Nathan Lane local-road line.10 Central Street local-road line.11 Lois Lane local-road line.12 Rocky Road local-road line.13 Fleet Street local-road line.14 Diane Court local-road line.15 Cedar Trail local-road line.16 Victory Road local-road line.17 Highland Road local-road line.18 Easy Street local-road line.19 Hill Street local-road line.20 Country Road local-road line.21 Main Street local-road line.22 Jani Lane local-road line.23 Shinbone Alley local-road line.24 State Street local-road line.25 River Road local-road

                                                                                          Download the lines shapefile

                                                                                          "},{"location":"styling/css/cookbook/line/#css_cookbook_lines_simpleline","title":"Simple line","text":"

                                                                                          This example specifies lines be colored black with a thickness of 3 pixels.

                                                                                          Simple line

                                                                                          "},{"location":"styling/css/cookbook/line/#code","title":"Code","text":"
                                                                                          * { \n  stroke: black;\n  stroke-width: 3px;\n}\n
                                                                                          "},{"location":"styling/css/cookbook/line/#details","title":"Details","text":"

                                                                                          The only rule asks for a black stroke (this attribute is mandatory to get strokes to actually show up), 3 pixels wide.

                                                                                          "},{"location":"styling/css/cookbook/line/#line-with-border","title":"Line with border","text":"

                                                                                          This example shows how to draw lines with borders (sometimes called \"cased lines\"). In this case the lines are drawn with a 3 pixel blue center and a 1 pixel wide gray border.

                                                                                          Line with border

                                                                                          "},{"location":"styling/css/cookbook/line/#code_1","title":"Code","text":"
                                                                                          * { \n  stroke: #333333, #6699FF;\n  stroke-width: 5px, 3px;\n  stroke-linecap: round;\n  z-index: 0, 1;\n}\n
                                                                                          "},{"location":"styling/css/cookbook/line/#details_1","title":"Details","text":"

                                                                                          Lines in CSS have no notion of a \"fill\", only \"stroke\". Thus, unlike points or polygons, it is not possible to style the \"edge\" of the line geometry. It is, however, possible to achieve this effect by drawing each line twice: once with a certain width and again with a slightly smaller width. This gives the illusion of fill and stroke by obscuring the larger lines everywhere except along the edges of the smaller lines.

                                                                                          The style uses the \"multi-valued properties\" CSS support by specifying two strokes and two stroke-widths. This causes each feature to be painted twice, first with a dark gray (#333333) line 5 pixels wide, and then a thinner blue (#6699FF) line 3 pixels wide.

                                                                                          Since every line is drawn twice, the order of the rendering is very important. Without the z-index indication, each feature would first draw the gray stroke and then the blue one, and then the rendering engine would move to the next feature, and so on. This would result in ugly overlaps when lines do cross. By using the z-index property (Line 3) instead, all gray lines will be painted first, and then all blue lines will painted on top, thus making sure the blue lines visually connect.

                                                                                          The \"stroke-linecap\" property is the only one having a single value, this is because the value is the same for both the gray and blue line.

                                                                                          The result is a 3 pixel blue line with a 1 pixel gray border, since the 5 pixel gray line will display 1 pixel on each side of the 3 pixel blue line.

                                                                                          "},{"location":"styling/css/cookbook/line/#dashed-line","title":"Dashed line","text":"

                                                                                          This example alters the Simple line to create a dashed line consisting of 5 pixels of drawn line alternating with 2 pixels of blank space.

                                                                                          Dashed line

                                                                                          "},{"location":"styling/css/cookbook/line/#code_2","title":"Code","text":"
                                                                                          * { \n  stroke: blue;\n  stroke-width: 3px;\n  stroke-dasharray: 5 2;\n}\n
                                                                                          "},{"location":"styling/css/cookbook/line/#details_2","title":"Details","text":"

                                                                                          In this example the we create a blue line, 3 pixels wide, and specify a dash array with value \"5 2\", which creates a repeating pattern of 5 pixels of drawn line, followed by 2 pixels of omitted line.

                                                                                          "},{"location":"styling/css/cookbook/line/#railroad-hatching","title":"Railroad (hatching)","text":"

                                                                                          This example uses hatching to create a railroad style. Both the line and the hatches are black, with a 2 pixel thickness for the main line and a 1 pixel width for the perpendicular hatches.

                                                                                          Railroad (hatching)

                                                                                          "},{"location":"styling/css/cookbook/line/#code_3","title":"Code","text":"
                                                                                          * { \n  stroke: #333333, symbol(\"shape://vertline\");\n  stroke-width: 3px;\n  :nth-stroke(2) {\n    size: 12;\n    stroke: #333333;\n    stroke-width: 1px;\n  }\n}\n
                                                                                          "},{"location":"styling/css/cookbook/line/#details_3","title":"Details","text":"

                                                                                          In this example a multi-valued stroke is used: the fist value makes the renderer paint a dark gray line (3 pixels wide, according to the \"stroke-width\" attribute), whilst the second value makes the line be painted by repeating the \"shape://vertline\" symbol over and over, creating the hatching effect.

                                                                                          In order to specify how the symbol itself should be painted, the \":nth-stroke(2)\" pseudo-selector is used at Line 4 to specify the options for the repeated symbol: in particular with are instructing the renderer to create a 12px wide symbol, with a dark gray stroke 1 pixel wide.

                                                                                          "},{"location":"styling/css/cookbook/line/#spaced-graphic-symbols","title":"Spaced graphic symbols","text":"

                                                                                          This example uses a graphic stroke along with dash arrays to create a \"dot and space\" line type. Adding the dash array specification allows to control the amount of space between one symbol and the next one. Without using the dash array the lines would be densely populated with dots, each one touching the previous one.

                                                                                          Spaced symbols along a line

                                                                                          "},{"location":"styling/css/cookbook/line/#code_4","title":"Code","text":"
                                                                                          * { \n  stroke: symbol(circle);\n  stroke-dasharray: 4 6;\n  :stroke {\n    size: 4;\n    fill: #666666;\n    stroke: #333333;\n    stroke-width: 1px;\n  }\n}\n
                                                                                          "},{"location":"styling/css/cookbook/line/#details_4","title":"Details","text":"

                                                                                          This example, like others before, uses symbol(circle) to place a graphic symbol along a line.

                                                                                          The symbol details are specified in the nested rule at Line 4 using the \":stroke\" pseudo-selector, creating a gray fill circle, 4 pixels wide, with a dark gray outline.

                                                                                          The spacing between symbols is controlled with the stroke-dasharray at line 3, which specifies 4 pixels of pen-down (just enough to draw the circle) and 6 pixels of pen-up, to provide the spacing.

                                                                                          "},{"location":"styling/css/cookbook/line/#css_cookbook_lines_dashoffset","title":"Alternating symbols with dash offsets","text":"

                                                                                          This example shows how to create a complex line style which alternates a dashed line and a graphic symbol. The code builds on features shown in the previous examples:

                                                                                          • stroke-dasharray controls pen-down/pen-up behavior to generate dashed lines
                                                                                          • symbol(...) places symbols along a line combining the two allows control of symbol spacing

                                                                                          This also shows the usage of a dash offset, which controls where rendering starts in the dash array. For example, with a dash array of 5 10 and a dash offset of 7 the renderer starts drawing the pattern 7 pixels from the beginning. It skips the 5 pixels pen-down section and 2 pixels of the pen-up section, then draws the remaining 8 pixels of pen-up, then 5 down, 10 up, and so on.

                                                                                          The example shows how to use these features to create two synchronized sequences of dash arrays, one drawing line segments and the other symbols.

                                                                                          Alternating dash and symbol

                                                                                          "},{"location":"styling/css/cookbook/line/#code_5","title":"Code","text":"
                                                                                          * { \n  stroke: blue, symbol(circle);\n  stroke-width: 1px;\n  stroke-dasharray: 10 10, 5 15;\n  stroke-dashoffset: 0, 7.5;\n  :nth-stroke(2) {\n    stroke: #000033;\n    stroke-width: 1px;\n    size: 5px;\n  }\n}\n
                                                                                          "},{"location":"styling/css/cookbook/line/#details_5","title":"Details","text":"

                                                                                          | This example uses again multi-valued properties to create two subsequent strokes applied to the same lines. | The first stroke is a solid blue line, 1 pixel wide, with a dash array of \"10 10\". | The second one instead is a repeated circle, using a dash array of \"5 15\" and with a dash offset of 7.5. This makes the sequence start with 12.5 pixels of white space, then a circle (which is then centered between the two line segments of the other pattern), then 15 pixels of white space, and so on.

                                                                                          The circle portrayal details are specified using the pseudo selector \"nth-stroke(2)\" at line 6, asking for circles that are 5 pixels wide, not filled, and with a dark blue outline.

                                                                                          "},{"location":"styling/css/cookbook/line/#css_cookbook_lines_defaultlabel","title":"Line with default label","text":"

                                                                                          This example shows a text label on the simple line. This is how a label will be displayed in the absence of any other customization.

                                                                                          Line with default label

                                                                                          "},{"location":"styling/css/cookbook/line/#code_6","title":"Code","text":"
                                                                                          * { \n  stroke: red;\n  label: [name];\n  font-fill: black;\n}\n
                                                                                          "},{"location":"styling/css/cookbook/line/#details_6","title":"Details","text":"

                                                                                          This example paints lines with a red stroke, and then adds horizontal black labels at the center of the line, using the \"name\" attribute to fill the label.

                                                                                          "},{"location":"styling/css/cookbook/line/#css_cookbook_lines_perpendicularlabel","title":"Labels along line with perpendicular offset","text":"

                                                                                          This example shows a text label on the simple line, just like the previous example, but will force the label to be parallel to the lines, and will offset them a few pixels away.

                                                                                          Line with default label

                                                                                          "},{"location":"styling/css/cookbook/line/#code_7","title":"Code","text":"
                                                                                          * { \n  stroke: red;\n  label: [name];\n  label-offset: 7px;\n  font-fill: black;\n}\n
                                                                                          "},{"location":"styling/css/cookbook/line/#details_7","title":"Details","text":"

                                                                                          This example is line by line identical to the previous one, but it add a new attribute \"label-offset\", which in the case of lines, when having a single value, is interpreted as a perpendicular offset from the line. The label is painted along a straight line, parallel to the line orientation in the center point of the label.

                                                                                          "},{"location":"styling/css/cookbook/line/#css_cookbook_lines_labelfollowingline","title":"Label following line","text":"

                                                                                          This example renders the text label to follow the contour of the lines.

                                                                                          Label following line

                                                                                          "},{"location":"styling/css/cookbook/line/#code_8","title":"Code","text":"
                                                                                          * { \n  stroke: red;\n  label: [name];\n  font-fill: black;\n  label-follow-line: true;\n}\n
                                                                                          "},{"location":"styling/css/cookbook/line/#details_8","title":"Details","text":"

                                                                                          As the Line with default label example showed, the default label behavior isn't optimal.

                                                                                          This example is similar to the Line with default label example with the exception of line 5 where the \"label-follow-line\" option is specified, which forces the labels to strickly follow the line.

                                                                                          Not all labels are visible partly because of conflict resolution, and partly because the renderer cannot find a line segment long and \"straight\" enough to paint the label (labels are not painted over sharp turns by default).

                                                                                          "},{"location":"styling/css/cookbook/line/#css_cookbook_lines_optimizedlabel","title":"Optimized label placement","text":"

                                                                                          This example optimizes label placement for lines such that the maximum number of labels are displayed.

                                                                                          Optimized label

                                                                                          "},{"location":"styling/css/cookbook/line/#code_9","title":"Code","text":"
                                                                                          * { \n  stroke: red;\n  label: [name];\n  font-fill: black;\n  label-follow-line: true;\n  label-max-angle-delta: 90;\n  label-max-displacement: 400;\n  label-repeat: 150;\n}\n
                                                                                          "},{"location":"styling/css/cookbook/line/#details_9","title":"Details","text":"

                                                                                          This example is similar to the previous example, Label following line. The only differences are contained in lines 6-8. Line 6 sets the maximum angle that the label will follow. This sets the label to never bend more than 90 degrees to prevent the label from becoming illegible due to a pronounced curve or angle. Line 7 sets the maximum displacement of the label to be 400 pixels. In order to resolve conflicts with overlapping labels, GeoServer will attempt to move the labels such that they are no longer overlapping. This value sets how far the label can be moved relative to its original placement. Finally, line 8 sets the labels to be repeated every 150 pixels. A feature will typically receive only one label, but this can cause confusion for long lines. Setting the label to repeat ensures that the line is always labeled locally.

                                                                                          "},{"location":"styling/css/cookbook/line/#css_cookbook_lines_optimizedstyledlabel","title":"Optimized and styled label","text":"

                                                                                          This example improves the style of the labels from the Optimized label placement example.

                                                                                          Optimized and styled label

                                                                                          "},{"location":"styling/css/cookbook/line/#code_10","title":"Code","text":"
                                                                                          * { \n  stroke: red;\n  label: [name];\n  font-family: Arial;\n  font-weight: bold;\n  font-fill: black;\n  font-size: 10;\n  halo-color: white;\n  halo-radius: 1;\n  label-follow-line: true;\n  label-max-angle-delta: 90;\n  label-max-displacement: 400;\n  label-repeat: 150;\n}\n
                                                                                          "},{"location":"styling/css/cookbook/line/#details_10","title":"Details","text":"

                                                                                          This example is similar to the Optimized label placement. The only differences are:

                                                                                          • The font family and weight have been specified
                                                                                          • In order to make the labels easier to read, a white \"halo\" has been added. The halo draws a thin 1 pixel white border around the text, making it stand out from the background.
                                                                                          "},{"location":"styling/css/cookbook/line/#attribute-based-line","title":"Attribute-based line","text":"

                                                                                          This example styles the lines differently based on the \"type\" (Road class) attribute.

                                                                                          Attribute-based line

                                                                                          "},{"location":"styling/css/cookbook/line/#code_11","title":"Code","text":"
                                                                                          [type = 'local-road'] {\n  stroke: #009933;\n  stroke-width: 2;\n  z-index: 0;\n}\n\n[type = 'secondary'] {\n  stroke: #0055CC;\n  stroke-width: 3;\n  z-index: 1;\n}\n\n[type = 'highway'] {\n  stroke: #FF0000;\n  stroke-width: 6;\n  z-index: 2;\n}\n
                                                                                          "},{"location":"styling/css/cookbook/line/#details_11","title":"Details","text":"

                                                                                          Note

                                                                                          Refer to the Example lines layer to see the attributes for the layer. This example has eschewed labels in order to simplify the style, but you can refer to the example Optimized and styled label to see which attributes correspond to which points.

                                                                                          There are three types of road classes in our fictional country, ranging from back roads to high-speed freeways: \"highway\", \"secondary\", and \"local-road\". In order to make sure the roads are rendered in the proper order of importance, a \"z-index\" attribute has been placed in each rule.

                                                                                          The three rules are designed as follows:

                                                                                          Rule order Rule name / type Color Size 1 local-road #009933 (green) 2 2 secondary #0055CC (blue) 3 3 highway #FF0000 (red) 6

                                                                                          Lines 1-5 comprise the first rule, the filter matches all roads that the \"type\" attribute has a value of \"local-road\". If this condition is true for a particular line, the rule renders it dark green, 2 pixels wide. All these lines are rendered first, and thus sit at the bottom of the final map.

                                                                                          Lines 7-11 match the \"secondary\" roads, painting them dark blue, 3 pixels wide. Given the \"z-index\" is 1, they are rendered after the local roads, but below the highways.

                                                                                          Lines 13-17 match the \"highway\" roads, painting them red 6 pixels wide. These roads are pained last, thus, on top of all others.

                                                                                          "},{"location":"styling/css/cookbook/line/#zoom-based-line","title":"Zoom-based line","text":"

                                                                                          This example alters the Simple line style at different zoom levels.

                                                                                          Zoom-based line: Zoomed in

                                                                                          Zoom-based line: Partially zoomed

                                                                                          Zoom-based line: Zoomed out

                                                                                          "},{"location":"styling/css/cookbook/line/#code_12","title":"Code","text":"
                                                                                          * {\n  stroke: #009933;\n}\n\n[@sd < 180M] {\n  stroke-width: 6;\n}\n\n[@sd > 180M] [@sd < 360M] {\n  stroke-width: 4;\n}\n\n[@sd > 360M] {\n  stroke-width: 2;\n}\n
                                                                                          "},{"location":"styling/css/cookbook/line/#details_12","title":"Details","text":"

                                                                                          It is often desirable to make shapes larger at higher zoom levels when creating a natural-looking map. This example varies the thickness of the lines according to the zoom level (or more accurately, scale denominator). Scale denominators refer to the scale of the map. A scale denominator of 10,000 means the map has a scale of 1:10,000 in the units of the map projection.

                                                                                          Note

                                                                                          Determining the appropriate scale denominators (zoom levels) to use is beyond the scope of this example.

                                                                                          This style contains three rules. The three rules are designed as follows:

                                                                                          Rule order Rule name Scale denominator Line width 1 Large 1:180,000,000 or less 6 2 Medium 1:180,000,000 to 1:360,000,000 4 3 Small Greater than 1:360,000,000 2

                                                                                          The order of these rules does not matter since the scales denominated in each rule do not overlap.

                                                                                          The first rule provides the stroke color used at all zoom levels, dark gray, while the other three rules cascade over it applying the different stroke widths based on the current zoom level leveraging the \"@sd\" pseudo attribute. The \"@sd\" pseudo attribute can only be compared using the \"<\" and \">\" operators, using any other operator will result in errors.

                                                                                          The result of this style is that lines are drawn with larger widths as one zooms in and smaller widths as one zooms out.

                                                                                          "},{"location":"styling/css/cookbook/point/","title":"Points","text":"

                                                                                          While points are seemingly the simplest type of shape, possessing only position and no other dimensions, there are many different ways that a point can be styled in CSS.

                                                                                          "},{"location":"styling/css/cookbook/point/#css_cookbook_points_attributes","title":"Example points layer","text":"

                                                                                          The points layer used for the examples below contains name and population information for the major cities of a fictional country. For reference, the attribute table for the points in this layer is included below.

                                                                                          fid (Feature ID) name (City name) pop (Population) point.1 Borfin 157860 point.2 Supox City 578231 point.3 Ruckis 98159 point.4 Thisland 34879 point.5 Synopolis 24567 point.6 San Glissando 76024 point.7 Detrania 205609

                                                                                          Download the points shapefile

                                                                                          "},{"location":"styling/css/cookbook/point/#css_cookbook_points_simplepoint","title":"Simple point","text":"

                                                                                          This example specifies points be styled as red circles with a diameter of 6 pixels.

                                                                                          Simple point

                                                                                          "},{"location":"styling/css/cookbook/point/#code","title":"Code","text":"
                                                                                          * { \n  mark: symbol(circle); \n  mark-size: 6px;\n  :mark {\n    fill: red;\n  }\n}\n
                                                                                          "},{"location":"styling/css/cookbook/point/#details","title":"Details","text":"

                                                                                          There are two rules in this CSS, the outer one matches all features, and asks them to be depicted with a circular mark, 6 pixels wide. The nested rule uses a symbol selector, :mark, which selects all marks, and allows to specify how to fill the contents of the circle, in this case, with a solid red fill (a stand alone fill property would have been interpreted as the request to fill all polygons in the input with solid red instead).

                                                                                          "},{"location":"styling/css/cookbook/point/#css_cookbook_points_simplepointwithstroke","title":"Simple point with stroke","text":"

                                                                                          This example adds a stroke (or border) around the Simple point, with the stroke colored black and given a thickness of 2 pixels.

                                                                                          Simple point with stroke

                                                                                          "},{"location":"styling/css/cookbook/point/#code_1","title":"Code","text":"
                                                                                          * { \n  mark: symbol(circle); \n  mark-size: 6px;\n  :mark {\n    fill: red;\n    stroke: black;\n    stroke-width: 2px;\n  }\n}\n
                                                                                          "},{"location":"styling/css/cookbook/point/#details_1","title":"Details","text":"

                                                                                          This example is similar to the Simple point example, in this case a stroke and a stroke width have been specified in the mark selector in order to apply them to the circle symbols.

                                                                                          "},{"location":"styling/css/cookbook/point/#rotated-square","title":"Rotated square","text":"

                                                                                          This example creates a square instead of a circle, colors it green, sizes it to 12 pixels, and rotates it by 45 degrees.

                                                                                          Rotated square

                                                                                          "},{"location":"styling/css/cookbook/point/#code_2","title":"Code","text":"
                                                                                          * { \n  mark: symbol(square); \n  mark-size: 12px;\n  mark-rotation: 45;\n  :mark {\n    fill: #009900;\n  }\n}\n
                                                                                          "},{"location":"styling/css/cookbook/point/#details_2","title":"Details","text":"

                                                                                          In this example, line 2 sets the shape to be a square, with line 6 setting the color to a dark green (#009900). Line 3 sets the size of the square to be 12 pixels, and line 4 set the rotation is to 45 degrees.

                                                                                          "},{"location":"styling/css/cookbook/point/#transparent-triangle","title":"Transparent triangle","text":"

                                                                                          This example draws a triangle, creates a black stroke identical to the Simple point with stroke example, and sets the fill of the triangle to 20% opacity (mostly transparent).

                                                                                          Transparent triangle

                                                                                          "},{"location":"styling/css/cookbook/point/#code_3","title":"Code","text":"
                                                                                          * { \n  mark: symbol(triangle); \n  mark-size: 12;\n  :mark {\n    fill: #009900;\n    fill-opacity: 0.2;\n    stroke: black;\n    stroke-width : 2px;\n  }\n}\n
                                                                                          "},{"location":"styling/css/cookbook/point/#details_3","title":"Details","text":"

                                                                                          In this example, line 2 once again sets the shape, in this case to a triangle, where line 3 sets the mark size to 12 pixels. Line 5 sets the fill color to a dark green (#009900) and line 6 sets the opacity to 0.2 (20% opaque). An opacity value of 1 means that the shape is drawn 100% opaque, while an opacity value of 0 means that the shape is drawn 0% opaque, or completely transparent. The value of 0.2 (20% opaque) means that the fill of the points partially takes on the color and style of whatever is drawn beneath it. In this example, since the background is white, the dark green looks lighter. Were the points imposed on a dark background, the resulting color would be darker. Line 8 set the stroke color to black and width to 2 pixels.

                                                                                          "},{"location":"styling/css/cookbook/point/#point-as-graphic","title":"Point as graphic","text":"

                                                                                          This example styles each point as a graphic instead of as a simple shape.

                                                                                          Point as graphic

                                                                                          "},{"location":"styling/css/cookbook/point/#code_4","title":"Code","text":"
                                                                                          * { \n  mark: url(smileyface.png); \n  mark-mime: \"image/png\";\n}\n
                                                                                          "},{"location":"styling/css/cookbook/point/#details_4","title":"Details","text":"

                                                                                          This style uses a graphic instead of a simple shape to render the points. Line 2 sets the path and file name of the graphic, while line 3 indicates the format (MIME type) of the graphic (image/png). In this example, the graphic is contained in the same directory as the SLD, so no path information is necessary, although a full URL could be used if desired.

                                                                                          Graphic used for points

                                                                                          "},{"location":"styling/css/cookbook/point/#css_cookbook_points_pointwithdefaultlabel","title":"Point with default label","text":"

                                                                                          This example shows a text label on the Simple point that displays the \"name\" attribute of the point. This is how a label will be displayed in the absence of any other customization.

                                                                                          Point with default label

                                                                                          "},{"location":"styling/css/cookbook/point/#code_5","title":"Code","text":"
                                                                                          * { \n  mark: symbol(circle);\n  mark-size: 6px;\n  label: [name];\n  font-fill: black;\n  :mark {\n    fill: red;\n  }\n}\n
                                                                                          "},{"location":"styling/css/cookbook/point/#details_5","title":"Details","text":"

                                                                                          This style is quite similar to the Simple point, but two new properties have been added to specify the labelling options. Line 4 indicates that the label contents come from the \"name\" attribute (anything in square brackets is a CQL expression, the attribute name being the simplest case) while Line 5 sets the label color to black.

                                                                                          "},{"location":"styling/css/cookbook/point/#css_cookbook_points_pointwithstyledlabel","title":"Point with styled label","text":"

                                                                                          This example improves the label style from the Point with default label example by centering the label above the point and providing a different font name and size.

                                                                                          Point with styled label

                                                                                          "},{"location":"styling/css/cookbook/point/#code_6","title":"Code","text":"
                                                                                          * { \n  mark: symbol(circle);\n  mark-size: 6px;\n  label: [name];\n  font-fill: black;\n  font-family: Arial;\n  font-size: 12;\n  font-weight: bold;\n  label-anchor: 0.5 0;\n  label-offset: 0 5;\n  :mark {\n    fill: red;\n  }\n\n}\n
                                                                                          "},{"location":"styling/css/cookbook/point/#details_6","title":"Details","text":"

                                                                                          This example expands on Point with default label and specifies the font attributes, in particular, the text is Aria, bold, 12px wide. Moreover, the label is moved on top of the point, by specifying an anchor of 0.5 0, which sets the point to be centered (0.5) horizontally axis and bottom aligned (0.0) vertically with the label, and an offset which moves the label 5 pixels up vertically.

                                                                                          The result is a centered bold label placed slightly above each point.

                                                                                          "},{"location":"styling/css/cookbook/point/#point-with-rotated-label","title":"Point with rotated label","text":"

                                                                                          This example builds on the previous example, Point with styled label, by rotating the label by 45 degrees, positioning the labels farther away from the points, and changing the color of the label to purple.

                                                                                          Point with rotated label

                                                                                          "},{"location":"styling/css/cookbook/point/#code_7","title":"Code","text":"
                                                                                          * { \n  mark: symbol(circle);\n  mark-size: 6px;\n  label: [name];\n  font-fill: #990099;\n  font-family: Arial;\n  font-size: 12;\n  font-weight: bold;\n  label-anchor: 0.5 0;\n  label-offset: 0 25;\n  label-rotation: -45;\n  :mark {\n    fill: red;\n  }\n}\n
                                                                                          "},{"location":"styling/css/cookbook/point/#details_7","title":"Details","text":"

                                                                                          This example is similar to the Point with styled label, but there are three important differences. Line 10 specifies 25 pixels of vertical displacement. Line 11 specifies a rotation of \"-45\" or 45 degrees counter-clockwise. (Rotation values increase clockwise, which is why the value is negative.) Finally, line 5 sets the font color to be a shade of purple (#99099).

                                                                                          Note that the displacement takes effect before the rotation during rendering, so in this example, the 25 pixel vertical displacement is itself rotated 45 degrees.

                                                                                          "},{"location":"styling/css/cookbook/point/#attribute-based-point","title":"Attribute-based point","text":"

                                                                                          This example alters the size of the symbol based on the value of the population (\"pop\") attribute.

                                                                                          Attribute-based point

                                                                                          "},{"location":"styling/css/cookbook/point/#code_8","title":"Code","text":"
                                                                                          * {\n  mark: symbol(circle);\n  :mark {\n    fill: #0033CC;\n  };\n  [pop < 50000] {\n    mark-size: 8;\n  };\n  [pop >= 50000] [pop < 100000] {\n    mark-size: 12;\n  };\n  [pop >= 100000] {\n    mark-size: 16;\n  }\n}\n
                                                                                          "},{"location":"styling/css/cookbook/point/#details_8","title":"Details","text":"

                                                                                          Note

                                                                                          Refer to the Example points layer to see the attributes for this data. This example has eschewed labels in order to simplify the style, but you can refer to the example Point with styled label to see which attributes correspond to which points.

                                                                                          This style shows how the basic mark setup (red circle, default size) can be overridden via cascading/nesting, changing the size depending on the pop attribute value, with smaller values yielding a smaller circle, and larger values yielding a larger circle.

                                                                                          The three rules are designed as follows:

                                                                                          Rule order Rule name Population (\"pop\") Size 1 SmallPop Less than 50,000 8 2 MediumPop 50,000 to 100,000 12 3 LargePop Greater than 100,000 16

                                                                                          The result of this style is that cities with larger populations have larger points. In particular, the rule at Line 6 matches all features whose \"pop\" attribute is less than 50000, the rule at Line 9 matches all features whose \"pop\" attribute is between 50000 and 100000 (mind the space between the two predicates, it is equivalent to and AND, if we had used a comma it would have been an OR instead), while the rule at Line 12 matches all features with more than 100000 inhabitants.

                                                                                          "},{"location":"styling/css/cookbook/point/#zoom-based-point","title":"Zoom-based point","text":"

                                                                                          This example alters the style of the points at different zoom levels.

                                                                                          Zoom-based point: Zoomed in

                                                                                          Zoom-based point: Partially zoomed

                                                                                          Zoom-based point: Zoomed out

                                                                                          "},{"location":"styling/css/cookbook/point/#code_9","title":"Code","text":"
                                                                                          * {\n  mark: symbol(circle);\n}\n\n:mark {\n  fill: #CC3300;\n}\n\n[@sd < 16M] {\n  mark-size: 12;\n}\n\n[@sd > 16M] [@sd < 32M] {\n  mark-size: 8;\n}\n\n[@sd > 32M] {\n  mark-size: 4;\n}\n
                                                                                          "},{"location":"styling/css/cookbook/point/#details_9","title":"Details","text":"

                                                                                          It is often desirable to make shapes larger at higher zoom levels when creating a natural-looking map. This example styles the points to vary in size based on the zoom level (or more accurately, scale denominator). Scale denominators refer to the scale of the map. A scale denominator of 10,000 means the map has a scale of 1:10,000 in the units of the map projection.

                                                                                          Note

                                                                                          Determining the appropriate scale denominators (zoom levels) to use is beyond the scope of this example.

                                                                                          This style contains three rules matching the scale. The three rules are designed as follows:

                                                                                          Rule order Rule name Scale denominator Point size 1 Large 1:16,000,000 or less 12 2 Medium 1:16,000,000 to 1:32,000,000 8 3 Small Greater than 1:32,000,000 4

                                                                                          The order of these rules does not matter since the scales denominated in each rule do not overlap.

                                                                                          The rules use the \"@sd\" pseudo-attribute, which refers to the current scale denominator, and which can be compared using the '<' and '>' operators only (using any other operator or function will result in errors).

                                                                                          The result of this style is that points are drawn larger as one zooms in and smaller as one zooms out.

                                                                                          While this example uses on purpose cascading to show a different possible setup, the same style could be written as:

                                                                                          * {\n  mark: symbol(circle);\n  :mark {\n    fill: #CC3300;\n  };\n  [@sd < 16M] {\n    mark-size: 12;\n  };\n  [@sd > 16M] [@sd < 32M] {\n    mark-size: 8;\n  };\n  [@sd > 32M] {\n    mark-size: 4;\n  }\n}\n
                                                                                          "},{"location":"styling/css/cookbook/polygon/","title":"Polygons","text":"

                                                                                          Polygons are two dimensional shapes that contain both an outer edge (or \"stroke\") and an inside (or \"fill\"). A polygon can be thought of as an irregularly-shaped point and is styled in similar ways to points.

                                                                                          "},{"location":"styling/css/cookbook/polygon/#css_cookbook_polygons_attributes","title":"Example polygons layer","text":"

                                                                                          The polygons layer used below contains county information for a fictional country. For reference, the attribute table for the polygons is included below.

                                                                                          fid (Feature ID) name (County name) pop (Population) polygon.1 Irony County 412234 polygon.2 Tracker County 235421 polygon.3 Dracula County 135022 polygon.4 Poly County 1567879 polygon.5 Bearing County 201989 polygon.6 Monte Cristo County 152734 polygon.7 Massive County 67123 polygon.8 Rhombus County 198029

                                                                                          Download the polygons shapefile

                                                                                          "},{"location":"styling/css/cookbook/polygon/#css_cookbook_polygons_simplepolygon","title":"Simple polygon","text":"

                                                                                          This example shows a polygon filled in blue.

                                                                                          Simple polygon

                                                                                          "},{"location":"styling/css/cookbook/polygon/#code","title":"Code","text":"
                                                                                          * { \n  fill: #000080; \n}\n
                                                                                          "},{"location":"styling/css/cookbook/polygon/#details","title":"Details","text":"

                                                                                          This simple rule applies a dark blue (#000080) fill to all the polygons in the dataset.

                                                                                          Note

                                                                                          The light-colored borders around the polygons in the figure are artifacts of the renderer caused by the polygons being adjacent. There is no border in this style.

                                                                                          "},{"location":"styling/css/cookbook/polygon/#css_cookbook_polygons_simplepolygonwithstroke","title":"Simple polygon with stroke","text":"

                                                                                          This example adds a 2 pixel white stroke to the Simple polygon example.

                                                                                          Simple polygon with stroke

                                                                                          "},{"location":"styling/css/cookbook/polygon/#code_1","title":"Code","text":"
                                                                                          * { \n  fill: #000080; \n  stroke: #FFFFFF;\n  stroke-width: 2;\n}\n
                                                                                          "},{"location":"styling/css/cookbook/polygon/#details_1","title":"Details","text":"

                                                                                          This example is similar to the Simple polygon example above, with the addition of the \"stroke\" and \"stroke-width\" attributes, that add a white, 2 pixels wide border around each polygon.

                                                                                          "},{"location":"styling/css/cookbook/polygon/#transparent-polygon","title":"Transparent polygon","text":"

                                                                                          This example builds on the Simple polygon with stroke example and makes the fill partially transparent by setting the opacity to 50%.

                                                                                          Transparent polygon

                                                                                          "},{"location":"styling/css/cookbook/polygon/#code_2","title":"Code","text":"
                                                                                          * { \n  fill: #000080; \n  fill-opacity: 0.5;\n  stroke: #FFFFFF;\n  stroke-width: 2;\n}\n
                                                                                          "},{"location":"styling/css/cookbook/polygon/#details_2","title":"Details","text":"

                                                                                          This example is similar to the Simple polygon with stroke example, save for defining the fill's opacity in line 3. The value of 0.5 results in partially transparent fill that is 50% opaque. An opacity value of 1 would draw the fill as 100% opaque, while an opacity value of 0 would result in a completely transparent (0% opaque) fill. In this example, since the background is white, the dark blue looks lighter. Were the points imposed on a dark background, the resulting color would be darker.

                                                                                          "},{"location":"styling/css/cookbook/polygon/#css_cookbook_polygons_graphicfill","title":"Graphic fill","text":"

                                                                                          This example fills the polygons with a tiled graphic.

                                                                                          Graphic fill

                                                                                          "},{"location":"styling/css/cookbook/polygon/#code_3","title":"Code","text":"
                                                                                          * { \n  fill: url(\"colorblocks1.png\");\n  fill-mime: 'image/png';\n}\n
                                                                                          "},{"location":"styling/css/cookbook/polygon/#details_3","title":"Details","text":"

                                                                                          This style fills the polygon with a tiled graphic. The graphic is selected providing a url for the fill, which in this case is meant to the relative to the styles directory contained within the data directory (an absolute path could have been provided, as well as a internet reference). Line 3 specifies that the image itself is a png (by default the code assumes jpegs are used and will fail to parse the file unless we specify its mime type). The size of the image is not specified, meaning the native size is going to be used. In case a rescale is desired, the \"fill-size\" attribute can be used to force a different size.

                                                                                          Graphic used for fill

                                                                                          "},{"location":"styling/css/cookbook/polygon/#hatching-fill","title":"Hatching fill","text":"

                                                                                          This example fills the polygons with a hatching pattern.

                                                                                          Hatching fill

                                                                                          "},{"location":"styling/css/cookbook/polygon/#code_4","title":"Code","text":"
                                                                                          * { \n  fill: symbol(\"shape://times\");\n  :fill {\n    size: 16;\n    stroke: #990099;\n    stroke-width: 1px;\n  }\n}\n
                                                                                          "},{"location":"styling/css/cookbook/polygon/#details_4","title":"Details","text":"

                                                                                          In this example the fill is specified to be the \"shape://times\" symbol, which is going to be tiled creating a cross-hatch effect.

                                                                                          The details of the hatch are specified at line 3*, where the pseudo-selector \":fill\" is used to match the contents of the fill, and specify that we want a symbol large 16 pixels (the larger the symbol, the coarser the cross hatch will be), and painted with a 1 pixel wide purple stroke.

                                                                                          "},{"location":"styling/css/cookbook/polygon/#css_cookbook_polygons_polygonwithdefaultlabel","title":"Polygon with default label","text":"

                                                                                          This example shows a text label on the polygon. In the absence of any other customization, this is how a label will be displayed.

                                                                                          Polygon with default label

                                                                                          "},{"location":"styling/css/cookbook/polygon/#code_5","title":"Code","text":"
                                                                                          * { \n  fill: #40FF40;\n  stroke: white;\n  stroke-width: 2;\n  label: [name];\n  font-fill: black;\n}\n
                                                                                          "},{"location":"styling/css/cookbook/polygon/#details_5","title":"Details","text":"

                                                                                          The single rule in the CSS applies to all feature: first it fills all polygons a light green with white outline, and then applies the \"name\" attribute as the label, using the default font (Times), with black color and default font size (10 px).

                                                                                          "},{"location":"styling/css/cookbook/polygon/#label-halo","title":"Label halo","text":"

                                                                                          This example alters the look of the Polygon with default label by adding a white halo to the label.

                                                                                          Label halo

                                                                                          "},{"location":"styling/css/cookbook/polygon/#code_6","title":"Code","text":"
                                                                                          * { \n  fill: #40FF40;\n  stroke: white;\n  stroke-width: 2;\n  label: [name];\n  font-fill: black;\n  halo-color: white;\n  halo-radius: 3;\n}\n
                                                                                          "},{"location":"styling/css/cookbook/polygon/#details_6","title":"Details","text":"

                                                                                          This example builds on Polygon with default label, with the addition of a halo around the labels on lines 7-8. A halo creates a color buffer around the label to improve label legibility. Line 9 sets the radius of the halo, extending the halo 3 pixels around the edge of the label, and line 8 sets the color of the halo to white. Since halos are most useful when set to a sharp contrast relative to the text color, this example uses a white halo around black text to ensure optimum readability.

                                                                                          "},{"location":"styling/css/cookbook/polygon/#css_cookbook_polygons_polygonwithstyledlabel","title":"Polygon with styled label","text":"

                                                                                          This example improves the label style from the Polygon with default label example by centering the label on the polygon, specifying a different font name and size, and setting additional label placement optimizations.

                                                                                          Polygon with styled label

                                                                                          "},{"location":"styling/css/cookbook/polygon/#code_7","title":"Code","text":"
                                                                                          * { \n  fill: #40FF40;\n  stroke: white;\n  stroke-width: 2;\n  label: [name];\n  font-family: Arial;\n  font-size: 11px;\n  font-style: normal;\n  font-weight: bold;\n  font-fill: black;\n  label-anchor: 0.5 0.5;\n  label-auto-wrap: 60;\n  label-max-displacement: 150;\n}\n
                                                                                          "},{"location":"styling/css/cookbook/polygon/#details_7","title":"Details","text":"

                                                                                          This example is similar to the Polygon with default label example, with additional styling options for the labels.

                                                                                          The font is setup to be Arial, 11 pixels, \"normal\" (as opposed to \"italic\") and bold.

                                                                                          The \"label-anchor\" affects where the label is placed relative to the centroid of the polygon, centering the label by positioning it 50% (or 0.5) of the way horizontally along the centroid of the polygon, as well as vertically in exactly the same way.

                                                                                          Finally, there are two added touches for label placement optimization: The \"label-auto-wrap\" attribute ensures that long labels are split across multiple lines by setting line wrapping on the labels to 60 pixels, whilst the \"label-max-displacement\" allows the label to be displaced by up to 150 pixels. This ensures that labels are compacted and less likely to spill over polygon boundaries. Notice little Massive County in the corner, whose label is now displayed.

                                                                                          "},{"location":"styling/css/cookbook/polygon/#attribute-based-polygon","title":"Attribute-based polygon","text":"

                                                                                          This example styles the polygons differently based on the \"pop\" (Population) attribute.

                                                                                          Attribute-based polygon

                                                                                          "},{"location":"styling/css/cookbook/polygon/#code_8","title":"Code","text":"
                                                                                          [parseLong(pop) < 200000] {\n  fill: #66FF66;\n}\n\n[parseLong(pop) >= 200000] [parseLong(pop) < 500000] {\n  fill: #33CC33;\n}\n\n[parseLong(pop) >= 500000] {\n  fill: #009900;\n}\n
                                                                                          "},{"location":"styling/css/cookbook/polygon/#details_8","title":"Details","text":"

                                                                                          Note

                                                                                          Refer to the Example polygons layer to see the attributes for the layer. This example has eschewed labels in order to simplify the style, but you can refer to the example Polygon with styled label to see which attributes correspond to which polygons.

                                                                                          Each polygon in our fictional country has a population that is represented by the population (\"pop\") attribute. This style contains three rules that alter the fill based on the value of \"pop\" attribute, with smaller values yielding a lighter color and larger values yielding a darker color.

                                                                                          The three rules are designed as follows:

                                                                                          Rule order Rule name Population (\"pop\") Color 1 SmallPop Less than 200,000 #66FF66 2 MediumPop 200,000 to 500,000 #33CC33 3 LargePop Greater than 500,000 #009900

                                                                                          The order of the rules does not matter in this case, since each shape is only rendered by a single rule.

                                                                                          The first rule fills light green all polygons whose \"pop\" attribute is below 200,000, the second paints medium green all poygons whose \"pop\" attribute is between 200,000 and 500,000, while the third rule paints dark green the remaining polygons.

                                                                                          What's interesting in the filters is the use of the \"parseLong\" filter function: this function is necessary because the \"pop\" attribute is a string, leaving it as is we would have a string comparison, whilst the function turns it into a number, ensuring proper numeric comparisons instead.

                                                                                          "},{"location":"styling/css/cookbook/polygon/#zoom-based-polygon","title":"Zoom-based polygon","text":"

                                                                                          This example alters the style of the polygon at different zoom levels.

                                                                                          Zoom-based polygon: Zoomed in

                                                                                          Zoom-based polygon: Partially zoomed

                                                                                          Zoom-based polygon: Zoomed out

                                                                                          "},{"location":"styling/css/cookbook/polygon/#code_9","title":"Code","text":"
                                                                                          * {\n  fill: #0000CC;\n  stroke: black;\n}\n\n[@sd < 100M] {\n   stroke-width: 7;\n   label: [name];\n   label-anchor: 0.5 0.5;\n   font-fill: white;\n   font-family: Arial;\n   font-size: 14;\n   font-weight: bold;\n}\n\n[@sd > 100M] [@sd < 200M] {\n   stroke-width: 4;\n}\n\n[@sd > 200M] {\n   stroke-width: 1;\n}\n
                                                                                          "},{"location":"styling/css/cookbook/polygon/#details_9","title":"Details","text":"

                                                                                          It is often desirable to make shapes larger at higher zoom levels when creating a natural-looking map. This example varies the thickness of the lines according to the zoom level. Polygons already do this by nature of being two dimensional, but another way to adjust styling of polygons based on zoom level is to adjust the thickness of the stroke (to be larger as the map is zoomed in) or to limit labels to only certain zoom levels. This is ensures that the size and quantity of strokes and labels remains legible and doesn't overshadow the polygons themselves.

                                                                                          Zoom levels (or more accurately, scale denominators) refer to the scale of the map. A scale denominator of 10,000 means the map has a scale of 1:10,000 in the units of the map projection.

                                                                                          Note

                                                                                          Determining the appropriate scale denominators (zoom levels) to use is beyond the scope of this example.

                                                                                          This style contains three rules, defined as follows:

                                                                                          Rule order Rule name Scale denominator Stroke width Label display? 1 Large 1:100,000,000 or less 7 Yes 2 Medium 1:100,000,000 to 1:200,000,000 4 No 3 Small Greater than 1:200,000,000 2 No

                                                                                          The first rule (lines 1-4) defines the attributes that are not scale dependent: dark blue fill, black outline.

                                                                                          The second (lines 6-14) rule provides specific overrides for the higher zoom levels, asking for a large stroke (7 pixels) and a label, which is only visible at this zoom level. The label is white, bold, Arial 14 pixels, its contents are coming form the \"name\" attribute.

                                                                                          The third rule (lines 16-18) specifies a stroke width of 4 pixels for medium zoom levels, whilst for low zoom levels the stroke width is set to 1 pixel by the last rule (lines 20-22).

                                                                                          The resulting style produces a polygon stroke that gets larger as one zooms in and labels that only display when zoomed in to a sufficient level.

                                                                                          "},{"location":"styling/css/cookbook/raster/","title":"Rasters","text":"

                                                                                          Rasters are geographic data displayed in a grid. They are similar to image files such as PNG files, except that instead of each point containing visual information, each point contains geographic information in numerical form. Rasters can be thought of as a georeferenced table of numerical values.

                                                                                          One example of a raster is a Digital Elevation Model (DEM) layer, which has elevation data encoded numerically at each georeferenced data point.

                                                                                          "},{"location":"styling/css/cookbook/raster/#example-raster","title":"Example raster","text":"

                                                                                          The raster layer that is used in the examples below contains elevation data for a fictional world. The data is stored in EPSG:4326 (longitude/latitude) and has a data range from 70 to 256. If rendered in grayscale, where minimum values are colored black and maximum values are colored white, the raster would look like this:

                                                                                          Raster file as rendered in grayscale

                                                                                          Download the raster file

                                                                                          "},{"location":"styling/css/cookbook/raster/#css_cookbook_raster_twocolorgradient","title":"Two-color gradient","text":"

                                                                                          This example shows a two-color style with green at lower elevations and brown at higher elevations.

                                                                                          Two-color gradient

                                                                                          "},{"location":"styling/css/cookbook/raster/#code","title":"Code","text":"
                                                                                          * {\n  raster-channels: auto;\n  raster-color-map: \n                    color-map-entry(#008000, 70)\n                    color-map-entry(#663333, 256);\n}\n
                                                                                          "},{"location":"styling/css/cookbook/raster/#details","title":"Details","text":"

                                                                                          There is a single rule which applies a color map to the raster data.

                                                                                          The \"raster-channels\" attribute activates raster symbolization, the \"auto\" value is indicates that we are going to use the default choice of bands to symbolize the output (either gray or RBG/RGBA depending on the input data). There is also the possibility of providing a band name or a list of band names in case we want to choose specific bands out of a multiband input, e.g., \"1\" or \"1 3 7\".

                                                                                          The \"raster-color-map\" attribute builds a smooth gradient between two colors corresponding to two elevation values. Each \"color-map-entry\" represents one entry or anchor in the gradient:

                                                                                          • The first argument is the color
                                                                                          • The second argument is the value at which we anchor the color
                                                                                          • An optional third argument could specify the opacity of the pixels, as a value between 0 (fully transparent) and 1 (fully opaque). The default, when not specified, is 1, fully opaque.

                                                                                          Line 4 sets the lower value of 70, which is styled a opaque dark green (#008000), and line 5 sets the upper value of 256, which is styled a opaque dark brown (#663333). All data values in between these two quantities will be linearly interpolated: a value of 163 (the midpoint between 70 and 256) will be colored as the midpoint between the two colors (in this case approximately #335717, a muddy green).

                                                                                          "},{"location":"styling/css/cookbook/raster/#transparent-gradient","title":"Transparent gradient","text":"

                                                                                          This example creates the same two-color gradient as in the Two-color gradient as in the example above but makes the entire layer mostly transparent by setting a 30% opacity.

                                                                                          Transparent gradient

                                                                                          "},{"location":"styling/css/cookbook/raster/#code_1","title":"Code","text":"
                                                                                          * {\n  raster-channels: auto;\n  raster-opacity: 0.3;\n  raster-color-map: color-map-entry(#008000, 70)\n                    color-map-entry(#663333, 256);\n}\n
                                                                                          "},{"location":"styling/css/cookbook/raster/#details_1","title":"Details","text":"

                                                                                          This example is similar to the Two-color gradient example save for the addition of line 3, which sets the opacity of the layer to 0.3 (or 30% opaque). An opacity value of 1 means that the shape is drawn 100% opaque, while an opacity value of 0 means that the shape is rendered as completely transparent. The value of 0.3 means that the raster partially takes on the color and style of whatever is drawn beneath it. Since the background is white in this example, the colors generated from the \"raster-color-map\" look lighter, but were the raster imposed on a dark background the resulting colors would be darker.

                                                                                          "},{"location":"styling/css/cookbook/raster/#brightness-and-contrast","title":"Brightness and contrast","text":"

                                                                                          This example normalizes the color output and then increases the brightness by a factor of 2.

                                                                                          Brightness and contrast

                                                                                          "},{"location":"styling/css/cookbook/raster/#code_2","title":"Code","text":"
                                                                                          * {\n  raster-channels: auto;\n  raster-contrast-enhancement: normalize;\n  raster-gamma: 0.5;\n  raster-color-map: color-map-entry(#008000, 70)\n                    color-map-entry(#663333, 256);\n}\n
                                                                                          "},{"location":"styling/css/cookbook/raster/#details_2","title":"Details","text":"

                                                                                          This example is similar to the Two-color gradient, save for the addition of the contrast enhancement and gamma attributes on lines 3-4. Line 3 normalizes the output by increasing the contrast to its maximum extent. Line 4 then adjusts the brightness by a factor of 0.5. Since values less than 1 make the output brighter, a value of 0.5 makes the output twice as bright.

                                                                                          "},{"location":"styling/css/cookbook/raster/#three-color-gradient","title":"Three-color gradient","text":"

                                                                                          This example creates a three-color gradient in primary colors. In addition, we want to avoid displaying data outside of the chosen range, leading some data not to be rendered at all.

                                                                                          Three-color gradient

                                                                                          "},{"location":"styling/css/cookbook/raster/#code_3","title":"Code","text":"
                                                                                          * {\n  raster-channels: auto;\n  raster-color-map: \n                    color-map-entry(black, 150, 0)\n                    color-map-entry(blue, 150)\n                    color-map-entry(yellow, 200)\n                    color-map-entry(red, 250)\n                    color-map-entry(black, 250, 0)\n}\n
                                                                                          "},{"location":"styling/css/cookbook/raster/#details_3","title":"Details","text":"

                                                                                          This example creates a three-color gradient, with two extra rules to make ranges of color disappear. The color map behavior is such that any value below the lowest entry gets the same color as that entry, and any value above the last entry gets the same color as the last entry, while everything in between is linearly interpolated (all values must be provided from lower to higher). Line 4 associates value 150 and below with a transparent color (0 opacity, that is, fully transparent), and so does line 8, which makes transparent every value above 250. The lines in the middle create a gradient going from blue, to yellow, to red.

                                                                                          "},{"location":"styling/css/cookbook/raster/#alpha-channel","title":"Alpha channel","text":"

                                                                                          This example creates an \"alpha channel\" effect such that higher values are increasingly transparent.

                                                                                          Alpha channel

                                                                                          "},{"location":"styling/css/cookbook/raster/#code_4","title":"Code","text":"
                                                                                          * {\n  raster-channels: auto;\n  raster-color-map: color-map-entry(#008000, 70)\n                    color-map-entry(#663333, 256, 0);\n}\n
                                                                                          "},{"location":"styling/css/cookbook/raster/#details_4","title":"Details","text":"

                                                                                          An alpha channel is another way of referring to variable transparency. Much like how a gradient maps values to colors, each entry in a \"raster-color-map\" can have a value for opacity (with the default being 1.0 or completely opaque).

                                                                                          In this example, there is a \"raster-color-map\" with two entries: line 3 specifies the lower bound of 70 be colored dark green (#008000), while line 4 specifies the upper bound of 256 also be colored dark green but with an opacity value of 0. This means that values of 256 will be rendered at 0% opacity (entirely transparent). Just like the gradient color, the opacity is also linearly interpolated such that a value of 163 (the midpoint between 70 and 256) is rendered at 50% opacity.

                                                                                          "},{"location":"styling/css/cookbook/raster/#discrete-colors","title":"Discrete colors","text":"

                                                                                          This example shows a gradient that is not linearly interpolated but instead has values mapped precisely to one of three specific colors.

                                                                                          Discrete colors

                                                                                          "},{"location":"styling/css/cookbook/raster/#code_5","title":"Code","text":"
                                                                                          * {\n  raster-channels: auto;\n  raster-color-map-type: intervals;\n  raster-color-map: color-map-entry(#008000, 150)\n                    color-map-entry(#663333, 256);\n}\n
                                                                                          "},{"location":"styling/css/cookbook/raster/#details_5","title":"Details","text":"

                                                                                          Sometimes color bands in discrete steps are more appropriate than a color gradient. The \"raster-color-map-type: intervals\" attribute sets the display to output discrete colors instead of a gradient. The values in each entry correspond to the upper bound for the color band such that colors are mapped to values less than the value of one entry but greater than or equal to the next lower entry. For example, line 4 colors all values less than 150 to dark green (#008000) and line 5 colors all values less than 256 but greater than or equal to 150 to dark brown (#663333).

                                                                                          "},{"location":"styling/css/cookbook/raster/#many-color-gradient","title":"Many color gradient","text":"

                                                                                          This example shows a gradient interpolated across eight different colors.

                                                                                          Many color gradient

                                                                                          "},{"location":"styling/css/cookbook/raster/#code_6","title":"Code","text":"
                                                                                          * {\n  raster-channels: auto;\n  raster-color-map: \n          color-map-entry(black, 95)\n          color-map-entry(blue, 110)\n          color-map-entry(green, 135)\n          color-map-entry(red, 160)\n          color-map-entry(purple, 185)\n          color-map-entry(yellow, 210)\n          color-map-entry(cyan, 235)\n          color-map-entry(white, 256)\n}\n
                                                                                          "},{"location":"styling/css/cookbook/raster/#details_6","title":"Details","text":"

                                                                                          This example is similar to the previous ones, and creates a color gradient between 8 colors as reported in the following table

                                                                                          Entry number Value Color 1 95 Black 2 110 Blue 3 135 Green 4 160 Red 5 185 Purple 6 210 Yellow 7 235 Cyan 8 256 White"},{"location":"styling/css/examples/","title":"Styling examples","text":"

                                                                                          The following pages contain CSS styling examples grouped by specific topics.

                                                                                          • Fills with randomized symbols
                                                                                          • Using transformation functions
                                                                                          • Example of 2.5D extrusion
                                                                                          • KML
                                                                                          • Miscellaneous
                                                                                          "},{"location":"styling/css/examples/extrude/","title":"Example of 2.5D extrusion","text":""},{"location":"styling/css/examples/extrude/#extruding-a-geometry","title":"Extruding a geometry","text":"

                                                                                          In this example, a 2.5D style is applied to the US States Population default layer. To achieve the 2.5D look two styling components need to work together, named isometric for the extrusion effect, and offset to add a rooftop or top surface. In order to draw states with a larger population on top, a sort-by using the PERSONS field was added. Also note that the same z-order was given to maintain the draw order of each state.

                                                                                          The flat mode directive was used to ensure that cascading is not applied. This enables the style to treat each CSS rule the same as an SLD rule which means rules can overlay on-top of each other with later rules being drawn first.

                                                                                          The extrusion part of the CSS produces the darker grey areas. The isometric function (see /filter/function_reference) was used to give the extrusion effect based on the US state's population size.

                                                                                          The last step was to add an offset to the geometry producing the lighter grey areas as a top surface. The extrusion above works on each state from the ground up based on the population size. It is therefore necessary to offset the geometry in the Y axis with the same height used for the geometry extrusion. This adds the geometry at the top of the extrusion giving the effect of a top surface.

                                                                                          @mode \"Flat\";\n/* EXTRUDING THE POLYGON */\n* {\n  fill: #7B7B7B;\n  fill-geometry: [isometric(the_geom, PERSONS/8M)];\n  stroke: #636363;\n  stroke-geometry: [isometric(the_geom, PERSONS/8M)];\n  stroke-opacity:0.7;\n  sort-by: PERSONS;  \n  z-index:0;\n}\n/* ADDING TOP SURFACE */\n* {\n  fill-geometry: [offset(the_geom, 0, PERSONS/8M)];\n  stroke-geometry: [offset(the_geom, 0, PERSONS/8M)];\n  fill: #CACCCD;\n  stroke: #000000;\n  stroke-opacity: 0.7;\n  sort-by: PERSONS;\n  z-index:0;\n  label: [STATE_ABBR];\n  font-family: 'Dialog';\n  font-weight: 'Bold';\n  halo-color: white;\n  halo-radius: 1;\n}\n

                                                                                          "},{"location":"styling/css/examples/extrude/#footnote","title":"Footnote","text":"

                                                                                          Using the population size to sort the rendering order causes some states (e.g. New York) to almost entirely overlay another state (in this case, Pennsylvania.) A better implementation might be to add a field containing the x value of the centroid and use this field in the sort-by clause in descending order i.e. (sort-by: centroid_x D).

                                                                                          "},{"location":"styling/css/examples/kml/","title":"KML","text":""},{"location":"styling/css/examples/kml/#detecting-raster-to-vector-switch-in-kml","title":"Detecting raster to vector switch in KML","text":"

                                                                                          GeoServer 2.4 added a new icon server that KML output uses to make sure the point symbolisers look the same as in a normal WMS call no matter what scale they are looked at.

                                                                                          This may pose some issue when working in the default KML generation mode, where the map is a ground overlay up to a certain scale, and switches to a vector, clickable representation once the number of features in the visualization fall below a certain scale (as controlled by the KMSCORE parameter): the end user is not informed \"visually\" that the switch happened.

                                                                                          There is however a custom environment variable, set by the KML generator, that styles can leverage to know whether the KML generation is happening in ground overlay or vector mode.

                                                                                          The following example leverages this function to show a larger point symbol when points become clickable:

                                                                                          * { \n  mark: symbol(\"circle\");\n}\n\n:mark [env('kmlOutputMode') = 'vector'] {\n  size: 8;\n}\n\n:mark {\n  size: 4;\n  fill: yellow;\n  stroke: black;\n}\n

                                                                                          This will result in the following output:

                                                                                          Raster output, points are not yet clickable

                                                                                          Vector output, points are clickable and painted as larger icons

                                                                                          One important bit about the above CSS is that the order of the rules is important. The CSS to SLD translator uses specificity to decide which rule overrides which other one, and the specificity is driven, at the time of writing, only by scale rules and access to attributes. The filter using the kmlOutputMode filter is not actually using any feature attribute, so it has the same specificity as the catch all :mark rule. Putting it first ensures that it overrides the catch all rule anyways, while putting it second would result in the output size being always 4.

                                                                                          "},{"location":"styling/css/examples/kml/#getting-kml-marks-similar-to-the-old-kml-encoder","title":"Getting KML marks similar to the old KML encoder","text":"

                                                                                          The old KML generator (prior to GeoServer 2.4) was not able to truly respect the marks own shape, and as a result, was simply applying the mark color to a fixed bull's eye like icon, for example:

                                                                                          Starting with GeoServer 2.4 the KML engine has been rewritten, and among other things, it can produce an exact representation of the marks, respecting not only color, but also shape and stroking. However, what if one want to reproduce the old output look?

                                                                                          The solution is to leverage the ability to respect marks appearance to the letter, and combine two superimposed marks to generate the desired output:

                                                                                          * { \n  mark: symbol('circle'), symbol('circle');\n  mark-size: 12, 4;\n}\n\n:nth-mark(1) {\n  fill: red;\n  stroke: black; \n  stroke-width: 2;\n}\n\n:nth-mark(2) {\n  fill: black;\n}\n

                                                                                          Which results in the following Google Earth output:

                                                                                          "},{"location":"styling/css/examples/misc/","title":"Miscellaneous","text":""},{"location":"styling/css/examples/misc/#markers-sized-by-an-attribute-value","title":"Markers sized by an attribute value","text":"

                                                                                          The following produces square markers at each point, but these are sized such that the area of each marker is proportional to the REPORTS attribute. When zoomed in (when there are less points in view) the size of the markers is doubled to make the smaller points more noticeable.

                                                                                          * {\n  mark: symbol(square);\n}\n\n[@sd > 1M] :mark {\n  size: [sqrt(REPORTS)];\n}\n\n/* So that single-report points can be more easily seen */\n[@sd < 1M] :mark {\n  size: [sqrt(REPORTS)*2];\n}\n

                                                                                          This example uses the sqrt function. There are many functions available for use in CSS and SLD. For more details read - /filter/function_reference

                                                                                          "},{"location":"styling/css/examples/misc/#specifying-a-geometry-attribute","title":"Specifying a geometry attribute","text":"

                                                                                          In some cases, typically when using a database table with multiple geometry columns, it's necessary to specify which geometry to use. For example, let's suppose you have a table containing routes start and end both containing point geometries. The following CSS will style the start with a triangle mark, and the end with a square.

                                                                                          * {\n    geometry: [start],          [end];\n    mark:     symbol(triangle), symbol(square);\n}\n
                                                                                          "},{"location":"styling/css/examples/misc/#generating-a-geometry-geometry-transformations","title":"Generating a geometry (Geometry Transformations)","text":"

                                                                                          Taking the previous example a bit further, we can also perform computations on-the-fly to generate the geometries that will be drawn. Any operation that is available for GeoServer Geometry transformations in SLD is also available in CSS styles. To use them, we simply provide a more complex expression in the geometry property. For example, we could mark the start and end points of all the paths in a line layer (you can test this example out with any line layer, such as the sf:streams layer that is included in GeoServer's default data directory.)

                                                                                          * {\n    geometry: [startPoint(the_geom)], [endPoint(the_geom)];\n    mark:     symbol(triangle),       symbol(square);\n}\n
                                                                                          "},{"location":"styling/css/examples/misc/#rendering-different-geometry-types-linespoints-with-a-single-style","title":"Rendering different geometry types (lines/points) with a single style","text":"

                                                                                          As one more riff on the geometry examples, we'll show how to render both the original line and the start/endpoints in a single style. This is accomplished by using stroke-geometry and mark-geometry to specify that different geometry expressions should be used for symbols compared with strokes.

                                                                                          * {\n    stroke-geometry: [the_geom];\n    stroke:          blue;\n    mark-geometry: [startPoint(the_geom)], [endPoint(the_geom)];\n    mark:          symbol(triangle),       symbol(square);\n}\n
                                                                                          "},{"location":"styling/css/examples/randomfills/","title":"Fills with randomized symbols","text":"

                                                                                          It is possible to generate fills by randomly repeating a symbol in the polygons to be filled. Please refer to the equivalent SLD chapter for details on the meaning of the various options.

                                                                                          "},{"location":"styling/css/examples/randomfills/#simple-random-distribution","title":"Simple random distribution","text":"

                                                                                          Here is an example distributing up to 50 small \"slash\" symbols in a 100x100 pixel tile (in case of conflicts the symbol will be skipped), enabling random symbol rotation), and setting the seed to \"5\" to get a distribution different than the default one:

                                                                                          * {\n  fill: symbol(\"shape://slash\");\n  :fill {\n    size: 8;\n    stroke: blue;\n    stroke-width: 4;\n    stroke-linecap: round;\n  };\n  stroke: black;\n  fill-random: grid;\n  fill-random-seed: 5;\n  fill-random-rotation: free;\n  fill-random-symbol-count: 50;\n  fill-random-tile-size: 100;\n}\n

                                                                                          Random distribution of a diagonal line

                                                                                          "},{"location":"styling/css/examples/randomfills/#thematic-map-using-point-density","title":"Thematic map using point density","text":"

                                                                                          Randomized distributions can also be used for thematic mapping, for example, here is the SLD for a version of topp:states that displays the number of inhabitant\u00ecs varying the density of a random point distribution:

                                                                                          * { \n  fill: symbol(\"circle\");\n  stroke: black;\n  fill-random: grid; \n  fill-random-tile-size: 100;\n\n  :fill {\n    size: 2;\n    fill: darkgray;\n  };\n  /* @title low */\n  [PERSONS < 2000000] {\n    fill-random-symbol-count: 50;\n  };\n  /* @title mid */\n  [PERSONS >= 2000000] [PERSONS < 4000000] {\n    fill-random-symbol-count: 150;\n  };\n  /* @title high */\n  [PERSONS >= 4000000] {\n    fill-random-symbol-count: 500;\n  }\n}\n

                                                                                          Thematic map via point density approach

                                                                                          "},{"location":"styling/css/examples/transformation/","title":"Using transformation functions","text":"

                                                                                          The transformation functions supported described in SLD and described in the equivalent SLD chapter are also available in CSS, the following shows examples of how they can be used.

                                                                                          "},{"location":"styling/css/examples/transformation/#recode","title":"Recode","text":"

                                                                                          The Recode filter function transforms a set of discrete values for an attribute into another set of values, by applying a (input, output) mapping onto the values of the variable/expression that is provided as the first input of the function.

                                                                                          Consider a chloropleth map of the US states dataset using the fill color to indicate the topographic regions for the states. The dataset has an attribute SUB_REGION containing the region code for each state. The Recode function is used to map each region code into a different color.

                                                                                          Note

                                                                                          It is to be noted that the following example specifies colors as hex string as opposed to native CSS color names, this is because the function syntax is expressed in CQL, which does not have support for native CSS color names.

                                                                                          * { \n  fill: [recode(strTrim(SUB_REGION),\n         'N Eng', '#6495ED',\n         'Mid Atl', '#B0C4DE',\n         'S Atl', '#00FFFF',\n         'E N Cen', '#9ACD32',\n         'E S Cen', '#00FA9A',\n         'W N Cen', '#FFF8DC',\n         'W S Cen', '#F5DEB3',\n         'Mtn', '#F4A460',\n         'Pacific', '#87CEEB')];\n  stroke: lightgrey;\n  label: [STATE_ABBR];\n  font-family: 'Arial';\n  font-fill: black;\n  label-anchor: 0.5 0.5;\n}\n

                                                                                          "},{"location":"styling/css/examples/transformation/#categorize","title":"Categorize","text":"

                                                                                          The Categorize filter function transforms a continuous-valued attribute into a set of discrete values by assiging ranges of values and turning them into a color, size, width, opacity, etc.

                                                                                          In the following example a coropleth map is build associating a color to the state population density in the ranges [ <= 20], [20 - 100], and [ > 100].

                                                                                          * { \n  fill: [categorize(\n         PERSONS / LAND_KM,\n         '#87CEEB',\n         20,\n         '#FFFACD',\n         100,\n         '#F08080')];\n  stroke : lightgrey;\n  label: [STATE_ABBR];\n  font-family: 'Arial';\n  font-fill: black;\n  label-anchor: 0.5 0.5; \n}\n

                                                                                          "},{"location":"styling/css/examples/transformation/#interpolate","title":"Interpolate","text":"

                                                                                          The Interpolate filter function transforms a continuous-valued attribute into another continuous range of values by applying piecewise interpolation.

                                                                                          The result will work for numeric values such as size, width, opacity when operating in numeric interpolation method (the default), and for colors when working in color mode.

                                                                                          The type of curve fitting the specified points can be either linear (the default), cubic or cosine, these values are known as the interpolation mode.

                                                                                          Both the interpolation method and mode are optional, and if provided, they are added at the end of the input list.

                                                                                          In the following example the state population is mapped to a continuous color scale in a rather compact way using the interpolate function:

                                                                                          * { \n  fill: [Interpolate(\n         PERSONS,\n         0, '#FEFEEE',\n         9000000, '#00FF00',\n         23000000, '#FF0000',\n         'color',\n         'linear')];\n  stroke : lightgrey;\n  label: [STATE_ABBR];\n  font-family: 'Arial';\n  font-fill: black;\n  label-anchor: 0.5 0.5; \n}\n

                                                                                          "},{"location":"styling/mbstyle/","title":"MBStyle Styling","text":"

                                                                                          This module allows GeoServer to use Mapbox style documents directly.

                                                                                          A Mapbox style document is a JSON based language that defines the visual appearance of a map, what data is drawn, and the order data and styling to use when drawing.

                                                                                          A Mapbox style document is an alternative to SLD, with different strengths and weaknesses:

                                                                                          • Both Mapbox style and SLD documents can define an entire Map, selecting what data is drawn and in what order.

                                                                                            As both these documents define the order in which layers are drawn they can be used to define a Layer Group (using the Add Style Group link).

                                                                                          • Mapbox style documents provide less control then the GeoServer SLD vendor options or accomplish a result using a different approach.

                                                                                            A GeoServer SLD TextSymbolizers allows a label priority used when drawing labels. This priority can even be generated on the fly using an expression. A MapBox style document producing the same effect would use several symbol layers, each drawing labels of different importance, and rely on draw order to ensure that the most important labels are drawn first (and are thus shown).

                                                                                          • The key advantage of Mapbox style documents is their compatibility with Mapbox GL JS and OpenLayers.

                                                                                            GeoServer publishes the styles used for rendering, web mapping clients or mobile apps to make use of the same Mapbox style document used by GeoServer.

                                                                                          • Feel free to experiment with Mapbox style documents, use the GeoServer REST API to convert to SLD (complete with GeoServer vendor options).

                                                                                          Mapbox style document support is not a part of GeoServer by default, but is available as an optional extension to install.

                                                                                          • Installing the GeoServer MBStyle extension
                                                                                          • Publishing a GeoServer Layer for use with Mapbox Styles
                                                                                          • MBStyle references
                                                                                          • MBStyle Cookbook
                                                                                          "},{"location":"styling/mbstyle/installing/","title":"Installing the GeoServer MBStyle extension","text":"

                                                                                          The MBStyle extension is listed on the GeoServer download page.

                                                                                          To install MBStyle extension:

                                                                                          1. Download the mbstyle

                                                                                            Verify that the version number in the filename corresponds to the version of GeoServer you are running (for example 2.24.2 above).

                                                                                          2. Extract the contents of the archive into the WEB-INF/lib directory in GeoServer. This extension includes two jars.

                                                                                          3. Restart GeoServer.

                                                                                          4. To confirm successful installation, check for a new MBStyle format option in the Styles editor.

                                                                                          "},{"location":"styling/mbstyle/source/","title":"Publishing a GeoServer Layer for use with Mapbox Styles","text":"

                                                                                          GeoServer can be configured to serve layers as vector tiles to be used as sources for Mapbox styles rendered by client-side applications such as OpenLayers.

                                                                                          1. production_container.enable_cors in GeoServer.
                                                                                          2. Install the Vector Tiles <vectortiles.install> extension.
                                                                                          3. Follow the vectortiles.tutorial to publish your layers in application/vnd.mapbox-vector-tile format (You only need to do the \"Publish vector tiles in GeoWebCache\" step).

                                                                                          Once these steps are complete, you will be able to use your GeoServer layers in any Mapbox-compatible client application that can access your GeoServer.

                                                                                          "},{"location":"styling/mbstyle/source/#source","title":"Source","text":"

                                                                                          The source syntax to use these GeoServer layers in your MapBox Style is:

                                                                                          \"<source-name>\": {\n  \"type\": \"vector\",\n  \"tiles\": [\n    \"http://localhost:8080/geoserver/gwc/service/wmts?REQUEST=GetTile&SERVICE=WMTS\n        &VERSION=1.0.0&LAYER=<workspace>:<layer>&STYLE=&TILEMATRIX=EPSG:900913:{z}\n        &TILEMATRIXSET=EPSG:900913&FORMAT=application/vnd.mapbox-vector-tile\n        &TILECOL={x}&TILEROW={y}\"\n  ],\n  \"minZoom\": 0,\n  \"maxZoom\": 14\n}\n

                                                                                          Note

                                                                                          <workspace> and <layer> should be replaced by the workspace and name of the layer in question. {x}, {y}, and {z} are placeholder values for the tile indices and should be preserved as written.

                                                                                          Note

                                                                                          <source-name> should be replaced by a source name of your choice. It will be used to refer to the source when defining a layer in the Mapbox Style.

                                                                                          Note

                                                                                          If geoserver is not being served from localhost:8080, update the domain accordingly.

                                                                                          "},{"location":"styling/mbstyle/cookbook/","title":"MBStyle Cookbook","text":"

                                                                                          The MBStyle Cookbook is a collection of MBStyle \"recipes\" for creating various types of map styles. Wherever possible, each example is designed to show off a single MBStyle layer so that code can be copied from the examples and adapted when creating MBStyles of your own. While not an exhaustive reference like the MBStyle reference the MBStyle cookbook is designed to be a practical reference, showing common style templates that are easy to understand.

                                                                                          The MBStyle Cookbook is divided into four sections: the first three for each of the vector types (points, lines, and polygons) and the fourth section for rasters to come. Each example in every section contains a screenshot showing actual GeoServer WMS output, a snippet of the MBStyle code for reference, and a link to download the full MBStyle.

                                                                                          Each section uses data created especially for the MBStyle Cookbook, with shapefiles for vector data and GeoTIFFs for raster data.

                                                                                          Data Type Shapefile Point mbstyle_cookbook_point.zip Line mbstyle_cookbook_line.zip Polygon mbstyle_cookbook_polygon.zip
                                                                                          • Points
                                                                                          • Lines
                                                                                          • Polygons
                                                                                          "},{"location":"styling/mbstyle/cookbook/lines/","title":"Lines","text":"

                                                                                          While lines can also seem to be simple shapes, having length but no width, there are many options and tricks for making lines display nicely.

                                                                                          "},{"location":"styling/mbstyle/cookbook/lines/#mbstyle_cookbook_lines_attributes","title":"Example lines layer","text":"

                                                                                          The lines layer used in the examples below contains road information for a fictional country. For reference, the attribute table for the points in this layer is included below.

                                                                                          fid (Feature ID) name (Road name) type (Road class) line.1 Latway highway line.2 Crescent Avenue secondary line.3 Forest Avenue secondary line.4 Longway highway line.5 Saxer Avenue secondary line.6 Ridge Avenue secondary line.7 Holly Lane local-road line.8 Mulberry Street local-road line.9 Nathan Lane local-road line.10 Central Street local-road line.11 Lois Lane local-road line.12 Rocky Road local-road line.13 Fleet Street local-road line.14 Diane Court local-road line.15 Cedar Trail local-road line.16 Victory Road local-road line.17 Highland Road local-road line.18 Easy Street local-road line.19 Hill Street local-road line.20 Country Road local-road line.21 Main Street local-road line.22 Jani Lane local-road line.23 Shinbone Alley local-road line.24 State Street local-road line.25 River Road local-road

                                                                                          Download the lines shapefile

                                                                                          "},{"location":"styling/mbstyle/cookbook/lines/#mbstyle_cookbook_lines_simpleline","title":"Simple line","text":"

                                                                                          This example specifies lines be colored black with a thickness of 3 pixels.

                                                                                          Simple line

                                                                                          "},{"location":"styling/mbstyle/cookbook/lines/#code","title":"Code","text":"

                                                                                          Download the \"Simple line\" MBStyle

                                                                                          {\n  \"version\": 8,\n  \"name\": \"simple-line\",\n  \"layers\": [\n    {\n      \"id\": \"simple-line\",\n      \"type\": \"line\",\n      \"paint\": {\n        \"line-color\": \"#000000\",\n        \"line-width\": 3\n      }\n    }\n  ]\n}\n
                                                                                          "},{"location":"styling/mbstyle/cookbook/lines/#details","title":"Details","text":"

                                                                                          There is one layer style for this MBStyle, which is the simplest possible situation. Styling lines is accomplished using the line layer. Line 9 specifies the color of the line to be black (\"#000000\"), while line 10 specifies the width of the lines to be 3 pixels.

                                                                                          "},{"location":"styling/mbstyle/cookbook/lines/#line-with-border","title":"Line with border","text":"

                                                                                          This example shows how to draw lines with borders (sometimes called \"cased lines\"). In this case the lines are drawn with a 3 pixel blue center and a 1 pixel wide gray border.

                                                                                          Line with border

                                                                                          "},{"location":"styling/mbstyle/cookbook/lines/#code_1","title":"Code","text":"

                                                                                          Download the \"Line with border\" MBStyle

                                                                                          {\n  \"version\": 8,\n  \"name\": \"simple-borderedline\",\n  \"layers\": [\n    {\n      \"id\": \"simple-borderedline\",\n      \"type\": \"line\",\n      \"layout\": {\n        \"line-cap\": \"round\"\n      },\n      \"paint\": {\n        \"line-color\": \"#333333\",\n        \"line-width\": 5\n      }\n    },\n    {\n      \"id\": \"simple-line\",\n      \"type\": \"line\",\n      \"layout\": {\n        \"line-cap\": \"round\"\n      },\n      \"paint\": {\n        \"line-color\": \"#6699FF\",\n        \"line-width\": 3\n      }\n    }\n  ]\n}\n
                                                                                          "},{"location":"styling/mbstyle/cookbook/lines/#details_1","title":"Details","text":"

                                                                                          In this example we are drawing the lines twice to achieve the appearance of a line with a border. Since every line is drawn twice, the order of the rendering is very important. GeoServer renders layers in the order that they are presented in the MBStyle. In this style, the gray border lines are drawn first via the first layer style, followed by the blue center lines in a second layer style. This ensures that the blue lines are not obscured by the gray lines, and also ensures proper rendering at intersections, so that the blue lines \"connect\".

                                                                                          In this example, lines 5-15 comprise the first layer style, which is the outer line (or \"stroke\"). Line 12 specifies the color of the line to be dark gray (\"#333333\"), line 13 specifies the width of this line to be 5 pixels, and in the layout line 9 a line-cap parameter of round renders the ends of the line as rounded instead of flat. (When working with bordered lines using a round line cap ensures that the border connects properly at the ends of the lines.)

                                                                                          Lines 16-26 comprise the second layer, which is the inner line (or \"fill\"). Line 23 specifies the color of the line to be a medium blue (\"#6699FF\"), line 24 specifies the width of this line to be 3 pixels, and in the layout line 20 again renders the edges of the line to be rounded instead of flat.

                                                                                          The result is a 3 pixel blue line with a 1 pixel gray border, since the 5 pixel gray line will display 1 pixel on each side of the 3 pixel blue line.

                                                                                          "},{"location":"styling/mbstyle/cookbook/lines/#dashed-line","title":"Dashed line","text":"

                                                                                          This example alters the Simple line to create a dashed line consisting of 5 pixels of drawn line alternating with 2 pixels of blank space.

                                                                                          Dashed line

                                                                                          "},{"location":"styling/mbstyle/cookbook/lines/#code_2","title":"Code","text":"

                                                                                          Download the \"Dashed line\" MBStyle

                                                                                          {\n  \"version\": 8,\n  \"name\": \"simple-dashedline\",\n  \"layers\": [\n    {\n      \"id\": \"simple-dashedline\",\n      \"type\": \"line\",\n      \"paint\": {\n        \"line-color\": \"#0000FF\",\n        \"line-width\": 3,\n        \"line-dasharray\": [5, 2]\n      }\n    }\n  ]\n}\n
                                                                                          "},{"location":"styling/mbstyle/cookbook/lines/#details_2","title":"Details","text":"

                                                                                          In this example, line 9 sets the color of the lines to be blue (\"#0000FF\") and line 10 sets the width of the lines to be 3 pixels. Line 11 determines the composition of the line dashes. The value of [5, 2] creates a repeating pattern of 5 pixels of drawn line, followed by 2 pixels of omitted line.

                                                                                          "},{"location":"styling/mbstyle/cookbook/lines/#offset-line","title":"Offset line","text":"

                                                                                          This example alters the Simple line to add a perpendicular offset line on the left side of the line, at five pixels distance.

                                                                                          Dashed line

                                                                                          "},{"location":"styling/mbstyle/cookbook/lines/#code_3","title":"Code","text":"

                                                                                          Download the \"Offset line\" MBStlye

                                                                                          {\n  \"version\": 8,\n  \"name\": \"simple-offsetline\",\n  \"layers\": [\n    {\n      \"id\": \"simple-line\",\n      \"type\": \"line\",\n      \"paint\": {\n        \"line-color\": \"#000000\",\n        \"line-width\": 1\n      }\n    },\n    {\n      \"id\": \"simple-offsetline\",\n      \"type\": \"line\",\n      \"paint\": {\n        \"line-color\": \"#FF0000\",\n        \"line-width\": 1,\n        \"line-dasharray\": [5, 2],\n        \"line-offset\": 5\n      }\n    }\n  ]\n}\n
                                                                                          "},{"location":"styling/mbstyle/cookbook/lines/#details_3","title":"Details","text":"

                                                                                          In this example, lines 5-11 draw a simple black line like in the Simple line example. Lines 13-21 draw a red dashed line like in the above Dashed line example. Line 20 modifies the dashed line with a 5 pixel offset from the line geometry.

                                                                                          "},{"location":"styling/mbstyle/cookbook/points/","title":"Points","text":"

                                                                                          Points are seemingly the simplest type of shape, possessing only position and no other dimensions. MBStyle has a circle type that can be styled to represent a point.

                                                                                          "},{"location":"styling/mbstyle/cookbook/points/#mbstyle_cookbook_points_attributes","title":"Example points layer","text":"

                                                                                          The points layer used for the examples below contains name and population information for the major cities of a fictional country. For reference, the attribute table for the points in this layer is included below.

                                                                                          fid (Feature ID) name (City name) pop (Population) point.1 Borfin 157860 point.2 Supox City 578231 point.3 Ruckis 98159 point.4 Thisland 34879 point.5 Synopolis 24567 point.6 San Glissando 76024 point.7 Detrania 205609

                                                                                          Download the points shapefile

                                                                                          "},{"location":"styling/mbstyle/cookbook/points/#mbstyle_cookbook_points_simplepoint","title":"Simple point","text":"

                                                                                          This example specifies points be styled as red circles with a diameter of 6 pixels.

                                                                                          Simple point

                                                                                          "},{"location":"styling/mbstyle/cookbook/points/#code","title":"Code","text":"

                                                                                          Download the \"Simple point\" MBStyle JSON

                                                                                          {\n  \"version\": 8,\n  \"name\": \"point-circle-test\",\n  \"layers\": [\n    {\n      \"id\": \"point\",\n      \"type\": \"circle\",\n      \"paint\": {\n        \"circle-radius\": 3,\n        \"circle-color\": \"#FF0000\",\n        \"circle-pitch-scale\": \"map\"\n      }\n    }\n  ]\n}\n
                                                                                          "},{"location":"styling/mbstyle/cookbook/points/#details","title":"Details","text":"

                                                                                          There is one layer in this MBStyle, which is the simplest possible situation. The \"version\" must always be set to 8. Layers is required for any MBStyle as an array. \"id\" is required and is a unique name for that layer. For our examples we will be setting the \"type\" to \"circle\".

                                                                                          "},{"location":"styling/mbstyle/cookbook/points/#mbstyle_cookbook_points_simplepointwithstroke","title":"Simple point with stroke","text":"

                                                                                          This example adds a stroke (or border) around the Simple point, with the stroke colored black and given a thickness of 2 pixels.

                                                                                          Simple point with stroke

                                                                                          "},{"location":"styling/mbstyle/cookbook/points/#code_1","title":"Code","text":"

                                                                                          Download the \"Simple point with stroke\" MBStyle JSON

                                                                                          {\n  \"version\": 8,\n  \"name\": \"point-circle-test\",\n  \"layers\": [\n    {\n      \"id\": \"point\",\n      \"type\": \"circle\",\n      \"paint\": {\n        \"circle-radius\": 3,\n        \"circle-color\": \"#FF0000\",\n        \"circle-pitch-scale\": \"map\",\n        \"circle-stroke-color\": \"#000000\",\n        \"circle-stroke-width\": 2\n      }\n    }\n  ]\n}\n
                                                                                          "},{"location":"styling/mbstyle/cookbook/points/#details_1","title":"Details","text":"

                                                                                          This example is similar to the Simple point example. Lines 12-13 specify the stroke, with line 12 setting the color to black ('#000000') and line 13 setting the width to 2 pixels.

                                                                                          "},{"location":"styling/mbstyle/cookbook/polygons/","title":"Polygons","text":"

                                                                                          Polygons are two dimensional shapes that contain both an outer stroke (or \"outline\") and an inside (or \"fill\"). A polygon can be thought of as an irregularly-shaped point and is styled in similar ways to circles.

                                                                                          "},{"location":"styling/mbstyle/cookbook/polygons/#mbstyle_cookbook_polygons_attributes","title":"Example polygons layer","text":"

                                                                                          The polygons layer used below contains county information for a fictional country. For reference, the attribute table for the polygons is included below.

                                                                                          fid (Feature ID) name (County name) pop (Population) polygon.1 Irony County 412234 polygon.2 Tracker County 235421 polygon.3 Dracula County 135022 polygon.4 Poly County 1567879 polygon.5 Bearing County 201989 polygon.6 Monte Cristo County 152734 polygon.7 Massive County 67123 polygon.8 Rhombus County 198029

                                                                                          Download the polygons shapefile

                                                                                          "},{"location":"styling/mbstyle/cookbook/polygons/#mbstyle_cookbook_polygons_simplepolygon","title":"Simple polygon","text":"

                                                                                          This example shows a polygon filled in blue.

                                                                                          Simple polygon

                                                                                          "},{"location":"styling/mbstyle/cookbook/polygons/#code","title":"Code","text":"

                                                                                          Download the \"Simple polygon\" MBStyle

                                                                                          {\n  \"version\": 8,\n  \"name\": \"simple-polygon\",\n  \"layers\": [\n    {\n      \"id\": \"polygon\",\n      \"type\": \"fill\",\n      \"paint\": {\n        \"fill-color\": \"#000080\"\n      }\n    }\n  ]\n}\n
                                                                                          "},{"location":"styling/mbstyle/cookbook/polygons/#details","title":"Details","text":"

                                                                                          There is one layer for this style, which is the simplest possible situation. Styling polygons is accomplished via the fill type (line 7). Line 9 specifies dark blue ('#000080') as the polygon's fill color.

                                                                                          Note

                                                                                          The light-colored outlines around the polygons in the figure are artifacts of the renderer caused by the polygons being adjacent. There is no outline in this style.

                                                                                          "},{"location":"styling/mbstyle/cookbook/polygons/#mbstyle_cookbook_polygons_simplepolygonwithstroke","title":"Simple polygon with stroke","text":"

                                                                                          This example adds a 1 pixel white outline to the Simple polygon example.

                                                                                          Simple polygon with stroke

                                                                                          "},{"location":"styling/mbstyle/cookbook/polygons/#code_1","title":"Code","text":"

                                                                                          Download the \"Simple polygon with stroke\" MBStyle

                                                                                          {\n  \"version\": 8,\n  \"name\": \"simple-polygon-outline\",\n  \"layers\": [\n    {\n      \"id\": \"polygon-outline\",\n      \"type\": \"fill\",\n      \"paint\": {\n        \"fill-outline-color\": \"#FFFFFF\",\n        \"fill-color\": \"#000080\"\n      }\n    }\n  ]\n}\n
                                                                                          "},{"location":"styling/mbstyle/cookbook/polygons/#details_1","title":"Details","text":"

                                                                                          This example is similar to the Simple polygon example above, with the addition of fill-outline paint parameter (line 9). Line 9 also sets the color of stroke to white ('#FFFFFF'), the \"fill-outline-color\" can only be 1 pixel, a limitation of MBStyle.

                                                                                          "},{"location":"styling/mbstyle/cookbook/polygons/#transparent-polygon","title":"Transparent polygon","text":"

                                                                                          This example builds on the Simple polygon with stroke example and makes the fill partially transparent by setting the opacity to 50%.

                                                                                          Transparent polygon

                                                                                          "},{"location":"styling/mbstyle/cookbook/polygons/#code_2","title":"Code","text":"

                                                                                          Download the \"Transparent polygon\" MBStyle

                                                                                          {\n  \"version\": 8,\n  \"name\": \"simple-polygon-transparent\",\n  \"layers\": [\n    {\n      \"id\": \"polygon-transparent\",\n      \"type\": \"fill\",\n      \"paint\": {\n        \"fill-outline-color\": \"#FFFFFF\",\n        \"fill-color\": \"#000080\",\n        \"fill-opacity\": 0.5\n      }\n    }\n  ]\n}\n
                                                                                          "},{"location":"styling/mbstyle/cookbook/polygons/#details_2","title":"Details","text":"

                                                                                          This example is similar to the Simple polygon with stroke example, save for defining the fill's opacity in line 11. The value of 0.5 results in partially transparent fill that is 50% opaque. An opacity value of 1 would draw the fill as 100% opaque, while an opacity value of 0 would result in a completely transparent (0% opaque) fill. In this example, since the background is white, the dark blue looks lighter. Were the fill imposed on a dark background, the resulting color would be darker.

                                                                                          "},{"location":"styling/mbstyle/reference/","title":"MBStyle references","text":"

                                                                                          As MBstyle is heavily modeled on JSON, it may be useful to refer to the JSON-Schema documentation for basic syntax.

                                                                                          "},{"location":"styling/mbstyle/reference/#mapbox-style-specification","title":"Mapbox Style Specification","text":"

                                                                                          For an extended reference to these styles check out the Mapbox Style Specifications.

                                                                                          "},{"location":"styling/mbstyle/reference/#geotools-mbstyle-extension","title":"GeoTools MBStyle extension","text":"

                                                                                          The implementation used by GeoServer is documented here. The GeoTools project is responsible for the parser/encoder to convert between Mapbox Styles and GeoServer style objects.

                                                                                          This documentation is actively maintained and matches the capabilities in GeoServer:

                                                                                          • Specification

                                                                                          When reading the above reference keep in mind the specification is written in an additive fashion, where new features are documented along with the version number range for which they are supported.

                                                                                          As an example the basic functionality of background-color support is added in GeoTools 23.0, as shown in the following table:

                                                                                          Support Mapbox GeoTools OpenLayers basic functionality >= 0.10.0 Not yet supported >= 2.4.0"},{"location":"styling/qgis/","title":"Generating SLD styles with QGIS","text":"

                                                                                          QGIS includes a sophisticated style editor with many map rendering possibilities. Styles generated with QGIS can then be exported (with limitations) to SLD for usage with GeoServer.

                                                                                          QGIS style exporting abilities have been evolving over time, as a reference:

                                                                                          • For vector data QGIS exports SLD 1.1 styles that can be read by GeoServer. In order to get the suitable results it's important to use QGIS 3.0 or newer, and GeoServer 2.13.x or newer.
                                                                                          • Raster data styling export is new in QGIS 3.4.5 (yet to be released at the time of writing). This new version exports SLD 1.0 styles with vendor extensions to support contrast stretching that most recent GeoServer versions support properly. For older QGIS versions limited export functionality is available using the SLD4Raster plugin.

                                                                                          For the export it is advised to use the Save As functionality available in the style dialog, as indicated below in this guide. Other plugins exist that streamline the export process, but they may ruin the style trying to adapt it to older GeoServer versions (e.g., translating it down to SLD 1.0 by simple text processing means), or rewrite it entirely.

                                                                                          Warning

                                                                                          Despite the progress in the last years, it is known that not all QGIS rendering options are supported by SLD and/or by GeoServer (e.g. shapeburst symbology), and that support for exporting some parts is simply missing (e.g.. expression based symbology is supported in SLD, but QGIS won't export it). If you are interested, both projects would welcome sponsoring to improve the situation.

                                                                                          "},{"location":"styling/qgis/#exporting-vector-symbology","title":"Exporting vector symbology","text":"

                                                                                          This is a step by step guide to style a GeoServer demo layer, sfdem.

                                                                                          1. Open QGIS (minimum version 3.0)

                                                                                          2. Load the states.shp dataset from the GeoServer data directory, <GEOSERVER_DATA_DIR>/data/shapefiles/states.shp

                                                                                          3. Double click the layer to open the Properties dialog and switch to the Symbology page.

                                                                                          4. Choose a Graduated rendering, on the PERSONS column, and click on Classify button to generate 1.5 standard deviations, select the spectral color ramp, switch mode to Quantile and finally and click on the Classify button to generate a 5 classes map, as shown in figure.

                                                                                            QGIS vector styling

                                                                                          5. Switch to the Labels page, choose Single labels````, label with the ````STATE NAME` attribute and choose your preferred text rendering options, as shown in figure

                                                                                            ![](images/qgis-label-style.png)\n*QGIS labelling*\n
                                                                                          6. The layer renders as follows:

                                                                                            ![](images/qgis-vector-render.png)\n*QGIS raster styling*\n
                                                                                          7. Go back At the Properties dialog, from the bottom of the Styles page, choose Style --> Save Style.

                                                                                            ![](images/qgis-vector-saveas.png)\n*Export using Save As...*\n
                                                                                          8. Choose export in the SLD format, placing the file in the desired location.

                                                                                            ![](images/qgis-choose-format.png)\n*Choosing export format...*\n
                                                                                          9. Go in GeoServer, create a new style, use the Upload a new style dialog to choose the exported file, and click on upload link.

                                                                                            ![](images/gs-vector-upload.png)\n*Uploading style in GeoServer...*\n
                                                                                          10. Click on guilabel:Apply.

                                                                                          11. Change to the Layer preview tab, click on the Preview on Layer link to choose topp:states to verify proper rendering.

                                                                                            ![](images/gs-vector-preview.png)\n*Previewing style in GeoServer...*\n
                                                                                          12. Eventually switch to the Publishing tab, search for states, and select Default or Associated checkbox to publish the layer to use the new style permanently.

                                                                                            ![](images/gs-vector-associate.png)\n*Associating style in GeoServer...*\n
                                                                                          "},{"location":"styling/qgis/#exporting-raster-symbology","title":"Exporting raster symbology","text":"

                                                                                          The following are a couple of examples on how to export raster layers\\' symbology in QGIS and how to use the resulting SLD to style layers in GeoServer.

                                                                                          Warning

                                                                                          As mentioned above, this functionality has some limitations:

                                                                                          • Hillshading vendor options are not fully supported by GeoServer so you can\\'t choose the Band and the position of the sun (Altitude and Azimuth), the Multidirectional option is not supported too
                                                                                          • GeoServer is not able to interpret the Color Rendering options yet

                                                                                          This is a step by step guide to style a GeoServer demo layer, sfdem.

                                                                                          1. Open QGIS (minimum version 3.4.5)

                                                                                          2. Load the `sfdem.tif` raster from the GeoServer data directory, `\\<GEOSERVER_DATA_DIR>/data/sf/sfdem.tif`

                                                                                          3. Double click the layer to open the Properties dialog and switch to the Symbology page.

                                                                                          4. Choose a Singleband pseudocolor rendering, Generate Min / Max Value Settings using Mean \u00b1 standard deviation with using 1.5 standard deviations. Generate a 5 classes Linear interpolated map, as shown in figure.

                                                                                            ![](images/qgis-raster-style.png)\n*QGIS raster styling*\n
                                                                                          5. The layer renders as follows:

                                                                                            ![](images/qgis-raster-render.png)\n*QGIS raster styling*\n
                                                                                          6. Return to the layer\\'s Properties dialog Symbology page, at the bottom of the page choose Style --> Save Style.

                                                                                            ![](images/qgis-raster-saveas.png)\n*Export using Save As...*\n
                                                                                          7. Choose export in the SLD format, placing the file in the desired location

                                                                                            ![](images/qgis-choose-format.png)\n*Choosing export format...*\n
                                                                                          8. Go in GeoServer, create a new style, use the Upload a new style dialog to choose the exported file, and click on upload link.

                                                                                            ![](images/gs-raster-upload.png)\n*Uploading style in GeoServer...*\n
                                                                                          9. Click on guilabel:Apply then change to the Layer preview tab. Click on the Preview on Layer link to choose sfdem to verify proper rendering.

                                                                                            ![](images/gs-raster-preview.png)\n*Previewing style in GeoServer...*\n
                                                                                          10. Finally switch to the Publishing tab, search for sfdem layer, and select Default or Associated checkbox to publish sfdem with the new style.

                                                                                            ![](images/gs-raster-associate.png)\n*Associating style in GeoServer...*\n

                                                                                          The next example shows how to style an aerial image instead.

                                                                                          1. Download an aerial image (for example from USGS Landsat image archives) if you do not already have one. Give it a name (aerial in this example) and save it as GeoTIFF

                                                                                            ![](images/landsat_usgs_sentinel2.png)\n*aerial.tiff*\n
                                                                                          2. Open GeoServer, create a new Store (see Add a Store), add a GeoTIFF Raster Data Source to the Store and connect it to your aerial.tif file

                                                                                          3. In GeoServer, create a new Layer (see Add a Layer) choosing the Store you have created in the previous step

                                                                                          4. Open QGIS (minimum version 3.4.5)

                                                                                          5. Load the aerial.tif raster

                                                                                          6. Double click the layer to open the Properties dialog and switch to the Symbology page

                                                                                          7. Choose a Multiband color rendering, set the bands (Red band == Band 1 (red), Green band == Band 2 (Green), Blue band == Band 3 (Blue)), generate Min / Max Value Settings using 5,0 - 95,0 % range of Cumulative count cut and select Stretch to MinMax as Contrast enhancement option, as shown in the picture below

                                                                                            ![](images/qgis-sentinel2-raster-style.png)\n*QGIS layer properties - Symbology*\n
                                                                                          8. The layer renders as follows:

                                                                                            ![](images/qgis-sentinel2-raster-rendering.png)\n*QGIS layer rendering*\n
                                                                                          9. Save the Style as SLD

                                                                                          10. Go in GeoServer, use the generated SLD to create a new style, choose the aerial layer through the Preview on Layer link and verify if the layer is properly rendered (see the previous example for further details)

                                                                                            ![](images/gs-sentinel2-raster-rendering.png)\n*GeoServer layer rendering*\n
                                                                                          11. Finally Publish the aerial layer with the new style as described in the previous example.

                                                                                          "},{"location":"styling/sld/","title":"SLD Styling","text":"

                                                                                          This section discusses styling of geospatial data using \"Style Layer Descriptor\" XML files.

                                                                                          • Introduction to SLD
                                                                                          • Working with SLD
                                                                                          • SLD Cookbook
                                                                                          • SLD Reference
                                                                                          • SLD Extensions in GeoServer
                                                                                          • SLD Tips and Tricks
                                                                                          • i18N in SLD
                                                                                          "},{"location":"styling/sld/introduction/","title":"Introduction to SLD","text":"

                                                                                          Geospatial data has no intrinsic visual component. In order to see data, it must be styled. Styling specifies color, thickness, and other visible attributes used to render data on a map.

                                                                                          In GeoServer, styling is accomplished using a markup language called Styled Layer Descriptor, or SLD for short. SLD is an XML-based markup language and is very powerful, although somewhat complex. This page gives an introduction to the capabilities of SLD and how it works within GeoServer.

                                                                                          Note

                                                                                          Since GeoServer uses SLD exclusively for styling, the terms \"SLD\" and \"style\" will often be used interchangeably.

                                                                                          "},{"location":"styling/sld/introduction/#sld-concepts","title":"SLD Concepts","text":"

                                                                                          In GeoServer styling is most often specified using XML SLD style documents. Style documents are associated with GeoServer layers (featuretypes) to specify how they should be rendered. A style document specifies a single named layer and a user style for it. The layer and style can have metadata elements such as a name identifying them, a title for displaying them, and an abstract describing them in detail. Within the top-level style are one or more feature type styles, which act as \"virtual layers\" to provide control over rendering order (allowing styling effects such as cased lines for roads). Each feature type style contains one or more rules, which control how styling is applied based on feature attributes and zoom level. Rules select applicable features by using filters, which are logical conditions containing predicates, expressions and filter functions. To specify the details of styling for individual features, rules contain any number of symbolizers. Symbolizers specify styling for points, lines and polygons, as well as rasters and text labels.

                                                                                          For more information refer to the SLD Reference.

                                                                                          "},{"location":"styling/sld/introduction/#types-of-styling","title":"Types of styling","text":"

                                                                                          Vector data that GeoServer can serve consists of three classes of shapes: Points, lines, and polygons. Lines (one dimensional shapes) are the simplest, as they have only the edge to style (also known as \"stroke\"). Polygons, two dimensional shapes, have an edge and an inside (also known as a \"fill\"), both of which can be styled differently. Points, even though they lack dimension, have both an edge and a fill (not to mention a size) that can be styled. For fills, color can be specified; for strokes, color and thickness can be specified.

                                                                                          GeoServer also serves raster data. This can be styled with a wide variety of control over color palette, opacity, contrast and other parameters.

                                                                                          More advanced styling is possible as well. Points can be specified with well-known shapes like circles, squares, stars, and even custom graphics or text. Lines can be styled with a dash styles and hashes. Polygons can be filled with a custom tiled graphics. Styling can be based on attributes in the data, so that certain features are styled differently. Text labels on features are possible as well. Styling can also be determined by zoom level, so that features are displayed in a way appropriate to their apparent size. The possibilities are vast.

                                                                                          "},{"location":"styling/sld/introduction/#a-basic-style-example","title":"A basic style example","text":"

                                                                                          A good way to learn about SLD is to study styling examples. The following is a simple SLD that can be applied to a layer that contains points, to style them as red circles with a size of 6 pixels. (This is the first example in the Points section of the SLD Cookbook.)

                                                                                          <?xml version=\"1.0\" encoding=\"ISO-8859-1\"?>\n<StyledLayerDescriptor version=\"1.0.0\" \n    xsi:schemaLocation=\"http://www.opengis.net/sld StyledLayerDescriptor.xsd\" \n    xmlns=\"http://www.opengis.net/sld\" \n    xmlns:ogc=\"http://www.opengis.net/ogc\" \n    xmlns:xlink=\"http://www.w3.org/1999/xlink\" \n    xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\">\n  <NamedLayer>\n    <Name>Simple point</Name>\n    <UserStyle>\n      <Title>GeoServer SLD Cook Book: Simple point</Title>\n      <FeatureTypeStyle>\n        <Rule>\n          <PointSymbolizer>\n            <Graphic>\n              <Mark>\n                <WellKnownName>circle</WellKnownName>\n                <Fill>\n                  <CssParameter name=\"fill\">#FF0000</CssParameter>\n                </Fill>\n              </Mark>\n              <Size>6</Size>\n            </Graphic>\n          </PointSymbolizer>\n        </Rule>\n      </FeatureTypeStyle>\n    </UserStyle>\n  </NamedLayer>\n</StyledLayerDescriptor>\n

                                                                                          Although the example looks long, only a few lines are really important to understand. Line 14 states that a \"PointSymbolizer\" is to be used to style data as points. Lines 15-17 state that points are to be styled using a graphic shape specified by a \"well known name\", in this case a circle. SLD provides names for many shapes such as \"square\", \"star\", \"triangle\", etc. Lines 18-20 specify the shape should be filled with a color of #FF0000 (red). This is an RGB color code, written in hexadecimal, in the form of #RRGGBB. Finally, line 22 specifies that the size of the shape is 6 pixels in width. The rest of the structure contains metadata about the style, such as a name identifying the style and a title for use in legends.

                                                                                          Note

                                                                                          In SLD documents some tags have prefixes, such as ogc:. This is because they are defined in XML namespaces. The top-level StyledLayerDescriptor tag (lines 2-7) specifies two XML namespaces, one called xmlns, and one called xmlns:ogc. The first namespace is the default for the document, so tags belonging to it do not need a prefix. Tags belonging to the second require the prefix ogc:. In fact, the namespace prefixes can be any identifier. The first namespace could be called xmlns:sld (as it often is) and then all the tags in this example would require an sld: prefix. The key point is that tags need to have the prefix for the namespace they belong to.

                                                                                          See the SLD Cookbook for more examples of styling with SLD.

                                                                                          "},{"location":"styling/sld/language/","title":"i18N in SLD","text":"

                                                                                          This section describes how to specify metadata (titles and abstracts) in different languages in SLD documents.

                                                                                          "},{"location":"styling/sld/language/#metadata-in-different-languages","title":"Metadata in different languages","text":"

                                                                                          GeoServer extends Title and Abstract sections, so that text in different languages can be included.

                                                                                          This is an example of the syntax to use:

                                                                                          <Title>This is the default title\n  <Localized lang=\"en\">English title</Localized>\n  <Localized lang=\"it\">Titolo in italiano</Localized>\n</Title>\n

                                                                                          A default text (This is the default title in the example) and a set of Localized sections, one for each language that you want to support.

                                                                                          Each Localized section specifies the language (using a two letter abbreviation in the lang attribute) and the related text.

                                                                                          Currently, GeoServer supports localized text in SLD in WMS GetLegendGraphic requests (legends that contain labels are rendered using the requested language, if a LANGUAGE parameter is added to the request, e.g. LANGUAGE=it).

                                                                                          "},{"location":"styling/sld/language/#using-the-language-function","title":"Using the language function","text":"

                                                                                          GeoServer provides a language function that can be used to get the LANGUAGE requested in GetMap or GetFeatureInfo request. The function can be used to generate maps whose symbology is language dependent.

                                                                                          Here is an example providing labels in multiple languages, integrating the language function with Recode e.g:

                                                                                          <TextSymbolizer>\n       <Label>\n         <ogc:Function name=\"Recode\">\n           <ogc:Function name=\"language\"/>\n           <ogc:Literal/>\n           <ogc:PropertyName>name_default</ogc:PropertyName>\n           <ogc:Literal>en</ogc:Literal>\n           <ogc:PropertyName>name_en</ogc:PropertyName>\n           <ogc:Literal>it</ogc:Literal>\n           <ogc:PropertyName>name_it</ogc:PropertyName>\n           <ogc:Literal>fr</ogc:Literal>\n           <ogc:PropertyName>name_fr</ogc:PropertyName>\n         </ogc:Function>\n       </Label>\n       <Fill>\n         <CssParameter name=\"fill\">#000000</CssParameter>\n       </Fill>\n</TextSymbolizer>\n

                                                                                          The empty <ogc:Literal/> elements acts as the default language, matching a value with a missing language parameter. If there is no default value,the default language will be returned. See Internationalization (i18n) for details on Default Language.

                                                                                          It is also possible to use the language function in a rule filter, filtering rules for both rendering and legend production purposes. This one shows how to refer to different symbols based on the current language:

                                                                                          <Rule>\n  <ogc:Filter>\n    <ogc:PropertyIsEqualTo>\n      <ogc:Function name=\"language\"/>\n      <ogc:Literal>it</ogc:Literal>\n    </ogc:PropertyIsEqualTo>\n  </ogc:Filter>\n  <PointSymbolizer>\n    <Graphic>\n      <ExternalGraphic>\n        <OnlineResource xlink:type=\"simple\" xlink:href=\"it_symbol.png\"/>\n        <Format>image/png</Format>\n      </ExternalGraphic>\n      <Size>32</Size>\n    </Graphic>\n  </PointSymbolizer>\n</Rule>\n<Rule>\n  <ogc:Filter>\n    <ogc:PropertyIsEqualTo>\n      <ogc:Function name=\"language\"/>\n      <ogc:Literal>de</ogc:Literal>\n    </ogc:PropertyIsEqualTo>\n  </ogc:Filter>\n  <PointSymbolizer>\n    <Graphic>\n      <ExternalGraphic>\n        <OnlineResource xlink:type=\"simple\" xlink:href=\"de_symbol.png\"/>\n        <Format>image/png</Format>\n      </ExternalGraphic>\n      <Size>32</Size>\n    </Graphic>\n  </PointSymbolizer>\n</Rule>\n

                                                                                          Specifically for the external graphics, if the external symbols are all co-located, and follow a naming convention including the language identifier, then it's also possible to embed the language in the symbol URL:

                                                                                          <Rule>\n  <PointSymbolizer>\n    <Graphic>\n      <ExternalGraphic>\n        <OnlineResource xlink:type=\"simple\" xlink:href=\"${language()}_symbol.png\"/>\n        <Format>image/png</Format>\n      </ExternalGraphic>\n      <Size>32</Size>\n    </Graphic>\n  </PointSymbolizer>\n</Rule>\n
                                                                                          "},{"location":"styling/sld/working/","title":"Working with SLD","text":"

                                                                                          This section describes how to create, view and troubleshoot SLD styling in GeoServer.

                                                                                          "},{"location":"styling/sld/working/#creating","title":"Creating","text":"

                                                                                          GeoServer comes with some basic styles defined in its catalog. Any number of new styles can be added to the catalog. Styles can also be specified externally to the server, either to define a complete map, or to extend the server style catalog using library mode.

                                                                                          "},{"location":"styling/sld/working/#catalog-styles","title":"Catalog Styles","text":"

                                                                                          Styles in the catalog can be viewed, edited and validated via the Styles page menu of the Web administration interface. They may also be created and accessed via the REST Styles API.

                                                                                          There are two types of Catalog Styles: Symbology Encoding styles (the default) and Style Layer Descriptor styles.

                                                                                          "},{"location":"styling/sld/working/#symbology-encoding-styles","title":"Symbology Encoding Styles","text":"

                                                                                          A Symbology Encoding style consists of a Symbology Encoding document used to specify the styling of a single layer. In GeoServer, this is more commonly referred to as a style.

                                                                                          GeoServer supports the use of a StyledLayerDescriptor document containing a single <NamedLayer> element, which contains a single <UserStyle> element to specify the styling.

                                                                                          • When used in this fashion the layer name is ignored, since the style may be applied to many different layers.
                                                                                          • When using an StyledLayerDescriptor generated by another application keep in mind only the first <NamedLayer> is used, any subsequent content is ignored.

                                                                                          Every layer (featuretype) registered with GeoServer must have at least one symbology encoding style associated with it, which is the default style for rendering the layer. Any number of additional styles can be associated with a layer. This allows layers to have appropriate styles advertised in the WMS GetCapabilities document. A layer's styles can be changed using the Layers page of the Web administration interface.

                                                                                          Note

                                                                                          When adding a layer and a style for it to GeoServer at the same time, the style should be added first, so that the new layer can be associated with the style immediately.

                                                                                          "},{"location":"styling/sld/working/#style-layer-descriptor-styles","title":"Style Layer Descriptor Styles","text":"

                                                                                          A Style Layer Descriptor is a StyledLayerDescriptor document containing any number of <NamedLayer> and <UserLayer> elements, each of which may contain any number of <UserStyle> or <NamedStyle> elements.

                                                                                          Within a Style Layer Descriptor document, the name of any <NamedLayer> elements should match a layer (or layer group) in the catalog. Likewise, any <NamedStyle> elements should refer to a style in the catalog.

                                                                                          Style Layer Descriptor styles can define new layers of styled data, by using the InlineFeature element to provide feature data.

                                                                                          Within GeoServer, when Style Layer Descriptor styles are used they are typically in the form of style groups. Style groups can be added to layer groups as an alternative way of defining a collection of styled layers, using either the Web Administration interface or the REST API.

                                                                                          Style Layer Descriptor styles can still be assigned to layers and used like a layer style, in which case only the first <NamedLayer> will be used. Style Layer Descriptor styles can also be used as an External Style, via the geoserver styles endpoint (/geoserver/styles) or the geoserver REST api.

                                                                                          "},{"location":"styling/sld/working/#external-styles","title":"External Styles","text":"

                                                                                          Styling can be defined externally to the server in a number of ways:

                                                                                          • An internet-accessible SLD document can be provided via the SLD=url parameter in a WMS GetMap GET request
                                                                                          • An SLD document can be provided directly in a WMS GetMap GET request using the SLD_BODY=style parameter. The SLD XML must be URL-encoded.
                                                                                          • A StyledLayerDescriptor element can be included in a WMS GetMap POST request XML document.

                                                                                          In all of these cases, if the WMS layers parameter is not supplied then the map content is defined completely by the layers and styles present in the external SLD. If the layers parameter is present, then styling operates in Library Mode.

                                                                                          The structure of an external style is the same as a Style Layer Descriptor style, as described above.

                                                                                          External styles can define new layers of styled data, by using the SLD InlineFeature element to provide feature data. This can be used to implement dynamic feature highlighting, for example.

                                                                                          External styling may be generated dynamically by client applications, This provides a powerful way for clients to control styling effects.

                                                                                          "},{"location":"styling/sld/working/#sld_library_mode","title":"Library Mode","text":"

                                                                                          In library mode externally-defined styles are treated as a style library, which acts as an extension to the server style catalog. Library mode occurs when map layers and styles are specified using the layers and styles WMS parameters, and additional styling is supplied externally using one of the methods described in the previous section. The styles in the external style document take precedence over the catalog styles during rendering.

                                                                                          Style lookup in library mode operates as follows:

                                                                                          • For each layer in the layers list, the applied style is either a named style specified in the styles list (if present), or the layer default style
                                                                                          • For a named style, if the external style document has a <NamedLayer>...<UserStyle> with matching layer name and style name, then it is used. Otherwise, the style name is searched for in the catalog. If it is not found there, an error occurs.
                                                                                          • For a default style, the external style document is searched to find a <NamedLayer> element with the layer name. If it contains a <UserStyle> with the <IsDefault> element having the value 1 then that style is used. Otherwise, the default server style for the layer (which must exist) is used.

                                                                                          Generally it is simpler and more performant to use styles from the server catalog. However, library mode can be useful if it is required to style a map containing many layers and where only a few of them need to have their styling defined externally.

                                                                                          "},{"location":"styling/sld/working/#viewing","title":"Viewing","text":"

                                                                                          Once a style has been associated with a layer, the resulting rendering of the layer data can be viewed by using the Layer Preview. The most convenient output format to use is the built-in OpenLayers viewer. Styles can be modified while the view is open, and their effect is visible as soon as the map view is panned or zoomed. Alternate styles can be viewed by specifying them in the styles WMS request parameter.

                                                                                          To view the effect of compositing multiple styled layers, several approaches are available:

                                                                                          • Create a layer group for the desired layers using the Layer Groups page, and preview it. Non-default styles can be specified for layers if required.
                                                                                          • Submit a WMS GetMap GET request specifying multiple layers in the layers parameter, and the corresponding styles in the styles parameter (if non-default styles are required).
                                                                                          • Submit a WMS GetMap POST request containing a StyledLayerDescriptor element specifying server layers, optional layers of inline data, and either named catalog styles or user-defined styling for each layer.
                                                                                          "},{"location":"styling/sld/working/#troubleshooting","title":"Troubleshooting","text":"

                                                                                          SLD is a type of programming language, not unlike creating a web page or building a script. As such, problems may arise that may require troubleshooting.

                                                                                          "},{"location":"styling/sld/working/#syntax-errors","title":"Syntax Errors","text":"

                                                                                          To minimize syntax errors when creating the SLD, it is recommended to use a text editor that is designed to work with XML (such as the Style Editor provided in the GeoServer UI). XML editors can make finding syntax errors easier by providing syntax highlighting and (sometimes) built-in error checking.

                                                                                          The GeoServer Style Editor allows validating a document against the SLD XML schema. This is not mandatory, but is recommended to do before saving styles.

                                                                                          "},{"location":"styling/sld/working/#semantic-errors","title":"Semantic Errors","text":"

                                                                                          Semantic errors cannot be caught by SLD validation, but show up when a style is applied during map rendering. Most of the time this will result in a map displaying no features (a blank map), but some errors will prevent the map from rendering at all.

                                                                                          The easiest way to fix semantic errors in an SLD is to try to isolate the error. If the SLD is long with many rules and filters, try temporarily removing some of them to see if the errors go away.

                                                                                          In some cases the server will produce a WMS Exception document which may help to identify the error. It is also worth checking the server log to see if any error messages have been recorded.

                                                                                          "},{"location":"styling/sld/cookbook/","title":"SLD Cookbook","text":"

                                                                                          The SLD Cookbook is a collection of SLD \"recipes\" for creating various types of map styles. Wherever possible, each example is designed to show off a single SLD feature so that code can be copied from the examples and adapted when creating SLDs of your own. While not an exhaustive reference like the SLD Reference or the OGC SLD 1.0 specification the SLD Cookbook is designed to be a practical reference, showing common style templates that are easy to understand.

                                                                                          The SLD Cookbook is divided into four sections: the first three for each of the vector types (points, lines, and polygons) and the fourth section for rasters. Each example in every section contains a screenshot showing actual GeoServer WMS output, a snippet of the SLD code for reference, and a link to download the full SLD.

                                                                                          Each section uses data created especially for the SLD Cookbook, with shapefiles for vector data and GeoTIFFs for raster data. The projection for data is EPSG:4326. All files can be easily loaded into GeoServer in order to recreate the examples.

                                                                                          Data Type Shapefile Point sld_cookbook_point.zip Line sld_cookbook_line.zip Polygon sld_cookbook_polygon.zip Raster sld_cookbook_raster.zip
                                                                                          • Points
                                                                                          • Lines
                                                                                          • Polygons
                                                                                          • Rasters
                                                                                          "},{"location":"styling/sld/cookbook/lines/","title":"Lines","text":"

                                                                                          While lines can also seem to be simple shapes, having length but no width, there are many options and tricks for making lines display nicely.

                                                                                          Warning

                                                                                          The code examples shown on this page are not the full SLD code, as they omit the SLD header and footer information for the sake of brevity. Please use the links to download the full SLD for each example.

                                                                                          "},{"location":"styling/sld/cookbook/lines/#sld_cookbook_lines_attributes","title":"Example lines layer","text":"

                                                                                          The lines layer used in the examples below contains road information for a fictional country. For reference, the attribute table for the points in this layer is included below.

                                                                                          fid (Feature ID) name (Road name) type (Road class) line.1 Latway highway line.2 Crescent Avenue secondary line.3 Forest Avenue secondary line.4 Longway highway line.5 Saxer Avenue secondary line.6 Ridge Avenue secondary line.7 Holly Lane local-road line.8 Mulberry Street local-road line.9 Nathan Lane local-road line.10 Central Street local-road line.11 Lois Lane local-road line.12 Rocky Road local-road line.13 Fleet Street local-road line.14 Diane Court local-road line.15 Cedar Trail local-road line.16 Victory Road local-road line.17 Highland Road local-road line.18 Easy Street local-road line.19 Hill Street local-road line.20 Country Road local-road line.21 Main Street local-road line.22 Jani Lane local-road line.23 Shinbone Alley local-road line.24 State Street local-road line.25 River Road local-road

                                                                                          Download the lines shapefile

                                                                                          "},{"location":"styling/sld/cookbook/lines/#sld_cookbook_lines_simpleline","title":"Simple line","text":"

                                                                                          This example specifies lines be colored black with a thickness of 3 pixels.

                                                                                          Simple line

                                                                                          "},{"location":"styling/sld/cookbook/lines/#code","title":"Code","text":"

                                                                                          View and download the full \"Simple line\" SLD

                                                                                          <FeatureTypeStyle>\n  <Rule>\n    <LineSymbolizer>\n      <Stroke>\n        <CssParameter name=\"stroke\">#000000</CssParameter>\n        <CssParameter name=\"stroke-width\">3</CssParameter>    \n      </Stroke>\n    </LineSymbolizer>\n  </Rule>\n</FeatureTypeStyle>\n
                                                                                          "},{"location":"styling/sld/cookbook/lines/#details","title":"Details","text":"

                                                                                          There is one <Rule> in one <FeatureTypeStyle> for this SLD, which is the simplest possible situation. (All subsequent examples will contain one <Rule> and one <FeatureTypeStyle> unless otherwise specified.) Styling lines is accomplished via the <LineSymbolizer> (lines 3-8). Line 5 specifies the color of the line to be black (#000000), while line 6 specifies the width of the lines to be 3 pixels.

                                                                                          "},{"location":"styling/sld/cookbook/lines/#line-with-border","title":"Line with border","text":"

                                                                                          This example shows how to draw lines with borders (sometimes called \"cased lines\"). In this case the lines are drawn with a 3 pixel blue center and a 1 pixel wide gray border.

                                                                                          Line with border

                                                                                          "},{"location":"styling/sld/cookbook/lines/#code_1","title":"Code","text":"

                                                                                          View and download the full \"Line with border\" SLD

                                                                                          <FeatureTypeStyle>\n   <Rule>\n    <LineSymbolizer>\n      <Stroke>\n        <CssParameter name=\"stroke\">#333333</CssParameter>                           \n        <CssParameter name=\"stroke-width\">5</CssParameter>    \n        <CssParameter name=\"stroke-linecap\">round</CssParameter>    \n      </Stroke> \n    </LineSymbolizer>\n  </Rule>\n</FeatureTypeStyle>\n<FeatureTypeStyle>\n   <Rule>\n    <LineSymbolizer>\n    <Stroke>\n        <CssParameter name=\"stroke\">#6699FF</CssParameter>                           \n        <CssParameter name=\"stroke-width\">3</CssParameter> \n        <CssParameter name=\"stroke-linecap\">round</CssParameter>  \n      </Stroke>\n    </LineSymbolizer>                                          \n   </Rule>\n</FeatureTypeStyle>\n
                                                                                          "},{"location":"styling/sld/cookbook/lines/#details_1","title":"Details","text":"

                                                                                          Lines in SLD have no notion of a \"fill\", only \"stroke\". Thus, unlike points or polygons, it is not possible to style the \"edge\" of the line geometry. It is, however, possible to achieve this effect by drawing each line twice: once with a certain width and again with a slightly smaller width. This gives the illusion of fill and stroke by obscuring the larger lines everywhere except along the edges of the smaller lines.

                                                                                          Since every line is drawn twice, the order of the rendering is very important. GeoServer renders <FeatureTypeStyle>s in the order that they are presented in the SLD. In this style, the gray border lines are drawn first via the first <FeatureTypeStyle>, followed by the blue center lines in a second <FeatureTypeStyle>. This ensures that the blue lines are not obscured by the gray lines, and also ensures proper rendering at intersections, so that the blue lines \"connect\".

                                                                                          In this example, lines 1-11 comprise the first <FeatureTypeStyle>, which is the outer line (or \"stroke\"). Line 5 specifies the color of the line to be dark gray (#333333), line 6 specifies the width of this line to be 5 pixels, and in line 7 a stroke-linecap parameter of round renders the ends of the line as rounded instead of flat. (When working with bordered lines using a round line cap ensures that the border connects properly at the ends of the lines.)

                                                                                          Lines 12-22 comprise the second <FeatureTypeStyle>, which is the inner line (or \"fill\"). Line 16 specifies the color of the line to be a medium blue (#6699FF), line 17 specifies the width of this line to be 3 pixels, and line 18 again renders the edges of the line to be rounded instead of flat.

                                                                                          The result is a 3 pixel blue line with a 1 pixel gray border, since the 5 pixel gray line will display 1 pixel on each side of the 3 pixel blue line.

                                                                                          "},{"location":"styling/sld/cookbook/lines/#dashed-line","title":"Dashed line","text":"

                                                                                          This example alters the Simple line to create a dashed line consisting of 5 pixels of drawn line alternating with 2 pixels of blank space.

                                                                                          Dashed line

                                                                                          "},{"location":"styling/sld/cookbook/lines/#code_2","title":"Code","text":"

                                                                                          View and download the full \"Dashed line\" SLD

                                                                                          <FeatureTypeStyle>\n  <Rule>\n    <LineSymbolizer>\n      <Stroke>\n        <CssParameter name=\"stroke\">#0000FF</CssParameter>\n        <CssParameter name=\"stroke-width\">3</CssParameter>\n        <CssParameter name=\"stroke-dasharray\">5 2</CssParameter>\n      </Stroke>\n    </LineSymbolizer>\n  </Rule>\n</FeatureTypeStyle>\n
                                                                                          "},{"location":"styling/sld/cookbook/lines/#details_2","title":"Details","text":"

                                                                                          In this example, line 5 sets the color of the lines to be blue (#0000FF) and line 6 sets the width of the lines to be 3 pixels. Line 7 determines the composition of the line dashes. The value of 5 2 creates a repeating pattern of 5 pixels of drawn line, followed by 2 pixels of omitted line.

                                                                                          "},{"location":"styling/sld/cookbook/lines/#offset-line","title":"Offset line","text":"

                                                                                          This example alters the Simple line to add a perpendicular offset line on the left side of the line, at five pixels distance.

                                                                                          Offset line

                                                                                          "},{"location":"styling/sld/cookbook/lines/#code_3","title":"Code","text":"

                                                                                          View and download the full \"Dashed line\" SLD

                                                                                          <FeatureTypeStyle>\n  <Rule>\n    <LineSymbolizer>\n      <Stroke>\n        <CssParameter name=\"stroke\">#000000</CssParameter>\n      </Stroke>\n    </LineSymbolizer>\n    <LineSymbolizer>\n      <Stroke>\n        <CssParameter name=\"stroke\">#FF0000</CssParameter>\n        <CssParameter name=\"stroke-dasharray\">5 2</CssParameter>\n      </Stroke>\n      <PerpendicularOffset>5</PerpendicularOffset>\n    </LineSymbolizer>\n  </Rule>\n</FeatureTypeStyle>\n
                                                                                          "},{"location":"styling/sld/cookbook/lines/#details_3","title":"Details","text":"

                                                                                          In this example, the first line symbolizer just paints the lines black. line 8 begins a second lines symbolizer, sets the color of the lines to be red (#FF0000) at line 10 and determines the composition of the line dashes at Line 11. Line 13 finally specifies a perpendicular offset of 5 pixels (positive, thus on the left side).

                                                                                          "},{"location":"styling/sld/cookbook/lines/#railroad-hatching","title":"Railroad (hatching)","text":"

                                                                                          This example uses hatching to create a railroad style. Both the line and the hatches are black, with a 2 pixel thickness for the main line and a 1 pixel width for the perpendicular hatches.

                                                                                          Note

                                                                                          This example leverages an SLD extension in GeoServer. Hatching is not part of the standard SLD 1.0 specification.

                                                                                          Railroad (hatching)

                                                                                          "},{"location":"styling/sld/cookbook/lines/#code_4","title":"Code","text":"

                                                                                          View and download the full \"Railroad (hatching)\" SLD

                                                                                          <FeatureTypeStyle>\n  <Rule>\n    <LineSymbolizer>\n      <Stroke>\n        <CssParameter name=\"stroke\">#333333</CssParameter>\n        <CssParameter name=\"stroke-width\">3</CssParameter>\n      </Stroke>\n    </LineSymbolizer> \n    <LineSymbolizer>\n      <Stroke>\n        <GraphicStroke>\n          <Graphic>\n            <Mark>\n              <WellKnownName>shape://vertline</WellKnownName>\n              <Stroke>\n                <CssParameter name=\"stroke\">#333333</CssParameter>\n                <CssParameter name=\"stroke-width\">1</CssParameter>\n              </Stroke>\n            </Mark>\n            <Size>12</Size>\n          </Graphic>\n        </GraphicStroke>\n      </Stroke>\n    </LineSymbolizer>\n  </Rule>\n</FeatureTypeStyle>\n
                                                                                          "},{"location":"styling/sld/cookbook/lines/#details_4","title":"Details","text":"

                                                                                          In this example there are two <LineSymbolizer>s. The first symbolizer, on lines 3-8, draws a standard line, with line 5 drawing the lines as dark gray (#333333) and line 6 setting the width of the lines to be 2 pixels.

                                                                                          The hatching is invoked in the second symbolizer, on lines 9-24. Line 14 specifies that the symbolizer draw a vertical line hatch (shape://vertline) perpendicular to the line geometry. Lines 16-17 set the hatch color to dark gray (#333333) and width to 1 pixel. Finally, line 20 specifies both the length of the hatch and the distance between each hatch to both be 12 pixels.

                                                                                          "},{"location":"styling/sld/cookbook/lines/#spaced-graphic-symbols","title":"Spaced graphic symbols","text":"

                                                                                          This example uses a graphic stroke along with dash arrays to create a \"dot and space\" line type. Adding the dash array specification allows to control the amount of space between one symbol and the next one. Without using the dash array the lines would be densely populated with dots, each one touching the previous one.

                                                                                          Note

                                                                                          This example may not work in other systems using SLD, since they may not support combining the use of stroke-dasharray and GraphicStroke. While the SLD is spec-compliant, the SLD specification does not state what this combination is supposed to produce.

                                                                                          Spaced symbols along a line

                                                                                          "},{"location":"styling/sld/cookbook/lines/#code_5","title":"Code","text":"

                                                                                          View and download the full \"Spaced symbols\" SLD

                                                                                          <FeatureTypeStyle>\n  <Rule>\n    <LineSymbolizer>\n      <Stroke>\n        <GraphicStroke>\n          <Graphic>\n            <Mark>\n              <WellKnownName>circle</WellKnownName>\n              <Fill>\n                <CssParameter name=\"fill\">#666666</CssParameter>  \n              </Fill>\n              <Stroke>\n                <CssParameter name=\"stroke\">#333333</CssParameter>\n                <CssParameter name=\"stroke-width\">1</CssParameter>\n              </Stroke>\n            </Mark>\n            <Size>4</Size>\n          </Graphic>\n        </GraphicStroke>\n        <CssParameter name=\"stroke-dasharray\">4 6</CssParameter>\n      </Stroke>\n    </LineSymbolizer>\n  </Rule>\n</FeatureTypeStyle>\n
                                                                                          "},{"location":"styling/sld/cookbook/lines/#details_5","title":"Details","text":"

                                                                                          This example, like others before, uses a GraphicStroke to place a graphic symbol along a line. The symbol, defined at lines 7-16 is a 4 pixel gray circle with a dark gray outline. The spacing between symbols is controlled with the stroke-dasharray at line 20, which specifies 4 pixels of pen-down (just enough to draw the circle) and 6 pixels of pen-up, to provide the spacing.

                                                                                          "},{"location":"styling/sld/cookbook/lines/#sld_cookbook_lines_defaultlabel","title":"Alternating symbols with dash offsets","text":"

                                                                                          This example shows how to create a complex line style which alternates a dashed line and a graphic symbol. The code builds on features shown in the previous examples:

                                                                                          • stroke-dasharray controls pen-down/pen-up behavior to generate dashed lines
                                                                                          • GraphicStroke places symbols along a line
                                                                                          • combining the two allows control of symbol spacing

                                                                                          This also shows the usage of a dash offset, which controls where rendering starts in the dash array. For example, with a dash array of 5 10 and a dash offset of 7 the renderer starts drawing the pattern 7 pixels from the beginning. It skips the 5 pixels pen-down section and 2 pixels of the pen-up section, then draws the remaining 8 pixels of pen-up, then 5 down, 10 up, and so on.

                                                                                          The example shows how to use these features to create two synchronized sequences of dash arrays, one drawing line segments and the other symbols.

                                                                                          Note

                                                                                          This example may not work in other systems using SLD, since they may not support combining the use of stroke-dasharray and GraphicStroke. While the SLD is spec-compliant, the SLD specification does not state what this combination is supposed to produce.

                                                                                          Alternating dash and symbol

                                                                                          "},{"location":"styling/sld/cookbook/lines/#code_6","title":"Code","text":"

                                                                                          View and download the full \"Spaced symbols\" SLD

                                                                                          <FeatureTypeStyle>\n  <Rule>\n    <LineSymbolizer>\n      <Stroke>\n        <CssParameter name=\"stroke\">#0000FF</CssParameter>\n        <CssParameter name=\"stroke-width\">1</CssParameter>\n        <CssParameter name=\"stroke-dasharray\">10 10</CssParameter>\n      </Stroke>\n    </LineSymbolizer>\n    <LineSymbolizer>\n      <Stroke>\n        <GraphicStroke>\n          <Graphic>\n            <Mark>\n              <WellKnownName>circle</WellKnownName>\n              <Stroke>\n                <CssParameter name=\"stroke\">#000033</CssParameter>\n                <CssParameter name=\"stroke-width\">1</CssParameter>\n              </Stroke>\n            </Mark>\n            <Size>5</Size>\n          </Graphic>\n        </GraphicStroke>\n        <CssParameter name=\"stroke-dasharray\">5 15</CssParameter>\n        <CssParameter name=\"stroke-dashoffset\">7.5</CssParameter>\n      </Stroke>\n    </LineSymbolizer>\n  </Rule>\n</FeatureTypeStyle>\n
                                                                                          "},{"location":"styling/sld/cookbook/lines/#details_6","title":"Details","text":"

                                                                                          In this example two LineSymbolizers use stroke-dasharray and different symbology to produce a sequence of alternating dashes and symbols. The first symbolizer (lines 3-9) is a simple dashed line alternating 10 pixels of pen-down with 10 pixels of pen-up. The second symbolizer (lines 10-27) alternates a 5 pixel empty circle with 15 pixels of white space. The circle symbol is produced by a Mark element, with its symbology specified by stroke parameters (lines 17-18). The spacing between symbols is controlled with the stroke-dasharray (line 24), which specifies 5 pixels of pen-down (just enough to draw the circle) and 15 pixels of pen-up. In order to have the two sequences positioned correctly the second one uses a stroke-dashoffset of 7.5 (line 25). This makes the sequence start with 12.5 pixels of white space, then a circle (which is then centered between the two line segments of the other pattern), then 15 pixels of white space, and so on.

                                                                                          "},{"location":"styling/sld/cookbook/lines/#line-with-default-label","title":"Line with default label","text":"

                                                                                          This example shows a text label on the simple line. This is how a label will be displayed in the absence of any other customization.

                                                                                          Line with default label

                                                                                          "},{"location":"styling/sld/cookbook/lines/#code_7","title":"Code","text":"

                                                                                          View and download the full \"Line with default label\" SLD

                                                                                          <FeatureTypeStyle>\n  <Rule>\n    <LineSymbolizer>\n      <Stroke>\n        <CssParameter name=\"stroke\">#FF0000</CssParameter>\n      </Stroke>\n    </LineSymbolizer>\n    <TextSymbolizer>\n      <Label>\n        <ogc:PropertyName>name</ogc:PropertyName>\n      </Label>\n      <LabelPlacement>\n        <LinePlacement />\n      </LabelPlacement>\n      <Fill>\n        <CssParameter name=\"fill\">#000000</CssParameter>\n      </Fill>\n    </TextSymbolizer>\n  </Rule>\n</FeatureTypeStyle>\n
                                                                                          "},{"location":"styling/sld/cookbook/lines/#details_7","title":"Details","text":"

                                                                                          In this example, there is one rule with a <LineSymbolizer> and a <TextSymbolizer>. The <LineSymbolizer> (lines 3-7) draws red lines (#FF0000). Since no width is specified, the default is set to 1 pixel. The <TextSymbolizer> (lines 8-15) determines the labeling of the lines. Lines 9-11 specify that the text of the label will be determined by the value of the \"name\" attribute for each line. (Refer to the attribute table in the Example lines layer section if necessary.) Line 13 sets the text color to black. All other details about the label are set to the renderer default, which here is Times New Roman font, font color black, and font size of 10 pixels.

                                                                                          "},{"location":"styling/sld/cookbook/lines/#sld_cookbook_lines_labelfollowingline","title":"Label following line","text":"

                                                                                          This example renders the text label to follow the contour of the lines.

                                                                                          Note

                                                                                          Labels following lines is an SLD extension specific to GeoServer. It is not part of the SLD 1.0 specification.

                                                                                          Label following line

                                                                                          "},{"location":"styling/sld/cookbook/lines/#code_8","title":"Code","text":"

                                                                                          View and download the full \"Label following line\" SLD

                                                                                          <FeatureTypeStyle>\n  <Rule>\n    <LineSymbolizer>\n      <Stroke>\n        <CssParameter name=\"stroke\">#FF0000</CssParameter>\n      </Stroke>\n    </LineSymbolizer>\n    <TextSymbolizer>\n      <Label>\n        <ogc:PropertyName>name</ogc:PropertyName>\n      </Label>\n      <LabelPlacement>\n        <LinePlacement />\n      </LabelPlacement>\n      <Fill>\n        <CssParameter name=\"fill\">#000000</CssParameter>\n      </Fill>\n      <VendorOption name=\"followLine\">true</VendorOption>\n    </TextSymbolizer>\n  </Rule>\n</FeatureTypeStyle>\n
                                                                                          "},{"location":"styling/sld/cookbook/lines/#details_8","title":"Details","text":"

                                                                                          As the Alternating symbols with dash offsets example showed, the default label behavior isn't optimal. The label is displayed at a tangent to the line itself, leading to uncertainty as to which label corresponds to which line.

                                                                                          This example is similar to the Alternating symbols with dash offsets example with the exception of lines 12-18. Line 18 sets the option to have the label follow the line, while lines 12-14 specify that the label is placed along a line. If <LinePlacement /> is not specified in an SLD, then <PointPlacement /> is assumed, which isn't compatible with line-specific rendering options.

                                                                                          Note

                                                                                          Not all labels are shown due to label conflict resolution. See the next section on Optimized label placement for an example of how to maximize label display.

                                                                                          "},{"location":"styling/sld/cookbook/lines/#sld_cookbook_lines_optimizedlabel","title":"Optimized label placement","text":"

                                                                                          This example optimizes label placement for lines such that the maximum number of labels are displayed.

                                                                                          Note

                                                                                          This example uses options that are specific to GeoServer and are not part of the SLD 1.0 specification.

                                                                                          Optimized label

                                                                                          "},{"location":"styling/sld/cookbook/lines/#code_9","title":"Code","text":"

                                                                                          View and download the full \"Optimized label\" SLD

                                                                                          <FeatureTypeStyle>\n  <Rule>\n    <LineSymbolizer>\n      <Stroke>\n        <CssParameter name=\"stroke\">#FF0000</CssParameter>\n      </Stroke>\n    </LineSymbolizer>\n    <TextSymbolizer>\n      <Label>\n        <ogc:PropertyName>name</ogc:PropertyName>\n      </Label>\n      <LabelPlacement>\n         <LinePlacement />\n      </LabelPlacement>\n      <Fill>\n        <CssParameter name=\"fill\">#000000</CssParameter>\n      </Fill>\n      <VendorOption name=\"followLine\">true</VendorOption>\n      <VendorOption name=\"maxAngleDelta\">90</VendorOption>\n      <VendorOption name=\"maxDisplacement\">400</VendorOption>\n      <VendorOption name=\"repeat\">150</VendorOption>\n    </TextSymbolizer>\n  </Rule>\n</FeatureTypeStyle>\n
                                                                                          "},{"location":"styling/sld/cookbook/lines/#details_9","title":"Details","text":"

                                                                                          GeoServer uses \"conflict resolution\" to ensure that labels aren't drawn on top of other labels, obscuring them both. This accounts for the reason why many lines don't have labels in the previous example, Label following line. While this setting can be toggled, it is usually a good idea to leave it on and use other label placement options to ensure that labels are drawn as often as desired and in the correct places. This example does just that.

                                                                                          This example is similar to the previous example, Label following line. The only differences are contained in lines 18-21. Line 19 sets the maximum angle that the label will follow. This sets the label to never bend more than 90 degrees to prevent the label from becoming illegible due to a pronounced curve or angle. Line 20 sets the maximum displacement of the label to be 400 pixels. In order to resolve conflicts with overlapping labels, GeoServer will attempt to move the labels such that they are no longer overlapping. This value sets how far the label can be moved relative to its original placement. Finally, line 21 sets the labels to be repeated every 150 pixels. A feature will typically receive only one label, but this can cause confusion for long lines. Setting the label to repeat ensures that the line is always labeled locally.

                                                                                          "},{"location":"styling/sld/cookbook/lines/#sld_cookbook_lines_optimizedstyledlabel","title":"Optimized and styled label","text":"

                                                                                          This example improves the style of the labels from the Optimized label placement example.

                                                                                          Optimized and styled label

                                                                                          "},{"location":"styling/sld/cookbook/lines/#code_10","title":"Code","text":"

                                                                                          View and download the full \"Optimized and styled label\" SLD

                                                                                          <FeatureTypeStyle>\n  <Rule>\n    <LineSymbolizer>\n      <Stroke>\n        <CssParameter name=\"stroke\">#FF0000</CssParameter>\n      </Stroke>\n    </LineSymbolizer>\n    <TextSymbolizer>\n      <Label>\n        <ogc:PropertyName>name</ogc:PropertyName>\n      </Label>\n      <LabelPlacement>\n        <LinePlacement />\n      </LabelPlacement>\n      <Fill>\n        <CssParameter name=\"fill\">#000000</CssParameter>\n      </Fill>\n      <Font>\n        <CssParameter name=\"font-family\">Arial</CssParameter>\n        <CssParameter name=\"font-size\">10</CssParameter>\n        <CssParameter name=\"font-style\">normal</CssParameter>\n        <CssParameter name=\"font-weight\">bold</CssParameter>\n      </Font>\n      <VendorOption name=\"followLine\">true</VendorOption>\n      <VendorOption name=\"maxAngleDelta\">90</VendorOption>\n      <VendorOption name=\"maxDisplacement\">400</VendorOption>\n      <VendorOption name=\"repeat\">150</VendorOption>\n    </TextSymbolizer>\n  </Rule>\n</FeatureTypeStyle>\n
                                                                                          "},{"location":"styling/sld/cookbook/lines/#details_10","title":"Details","text":"

                                                                                          This example is similar to the Optimized label placement. The only difference is in the font information, which is contained in lines 18-23. Line 19 sets the font family to be \"Arial\", line 20 sets the font size to 10, line 21 sets the font style to \"normal\" (as opposed to \"italic\" or \"oblique\"), and line 22 sets the font weight to \"bold\" (as opposed to \"normal\").

                                                                                          "},{"location":"styling/sld/cookbook/lines/#attribute-based-line","title":"Attribute-based line","text":"

                                                                                          This example styles the lines differently based on the \"type\" (Road class) attribute.

                                                                                          Attribute-based line

                                                                                          "},{"location":"styling/sld/cookbook/lines/#code_11","title":"Code","text":"

                                                                                          View and download the full \"Attribute-based line\" SLD

                                                                                          <FeatureTypeStyle>\n  <Rule>\n    <Name>local-road</Name>\n    <ogc:Filter>\n      <ogc:PropertyIsEqualTo>\n        <ogc:PropertyName>type</ogc:PropertyName>\n        <ogc:Literal>local-road</ogc:Literal>\n      </ogc:PropertyIsEqualTo>\n    </ogc:Filter>\n    <LineSymbolizer>\n      <Stroke>\n        <CssParameter name=\"stroke\">#009933</CssParameter>\n        <CssParameter name=\"stroke-width\">2</CssParameter>\n      </Stroke>\n    </LineSymbolizer>\n  </Rule>\n</FeatureTypeStyle>\n<FeatureTypeStyle>\n  <Rule>\n    <Name>secondary</Name>\n    <ogc:Filter>\n      <ogc:PropertyIsEqualTo>\n        <ogc:PropertyName>type</ogc:PropertyName>\n        <ogc:Literal>secondary</ogc:Literal>\n      </ogc:PropertyIsEqualTo>\n    </ogc:Filter>\n    <LineSymbolizer>\n      <Stroke>\n        <CssParameter name=\"stroke\">#0055CC</CssParameter>\n        <CssParameter name=\"stroke-width\">3</CssParameter>\n      </Stroke>\n    </LineSymbolizer>\n  </Rule>\n</FeatureTypeStyle>\n<FeatureTypeStyle>\n  <Rule>\n  <Name>highway</Name>\n    <ogc:Filter>\n      <ogc:PropertyIsEqualTo>\n        <ogc:PropertyName>type</ogc:PropertyName>\n        <ogc:Literal>highway</ogc:Literal>\n      </ogc:PropertyIsEqualTo>\n    </ogc:Filter>\n    <LineSymbolizer>\n      <Stroke>\n        <CssParameter name=\"stroke\">#FF0000</CssParameter>\n        <CssParameter name=\"stroke-width\">6</CssParameter>\n      </Stroke>\n    </LineSymbolizer>\n  </Rule>\n</FeatureTypeStyle>\n
                                                                                          "},{"location":"styling/sld/cookbook/lines/#details_11","title":"Details","text":"

                                                                                          Note

                                                                                          Refer to the Example lines layer to see the attributes for the layer. This example has eschewed labels in order to simplify the style, but you can refer to the example Optimized and styled label to see which attributes correspond to which points.

                                                                                          There are three types of road classes in our fictional country, ranging from back roads to high-speed freeways: \"highway\", \"secondary\", and \"local-road\". In order to handle each case separately, there is more than one <FeatureTypeStyle>, each containing a single rule. This ensures that each road type is rendered in order, as each <FeatureTypeStyle> is drawn based on the order in which it appears in the SLD.

                                                                                          The three rules are designed as follows:

                                                                                          Rule order Rule name / type Color Size 1 local-road #009933 (green) 2 2 secondary #0055CC (blue) 3 3 highway #FF0000 (red) 6

                                                                                          Lines 2-16 comprise the first <Rule>. Lines 4-9 set the filter for this rule, such that the \"type\" attribute has a value of \"local-road\". If this condition is true for a particular line, the rule is rendered according to the <LineSymbolizer> which is on lines 10-15. Lines 12-13 set the color of the line to be a dark green (#009933) and the width to be 2 pixels.

                                                                                          Lines 19-33 comprise the second <Rule>. Lines 21-26 set the filter for this rule, such that the \"type\" attribute has a value of \"secondary\". If this condition is true for a particular line, the rule is rendered according to the <LineSymbolizer> which is on lines 27-32. Lines 29-30 set the color of the line to be a dark blue (#0055CC) and the width to be 3 pixels, making the lines slightly thicker than the \"local-road\" lines and also a different color.

                                                                                          Lines 36-50 comprise the third and final <Rule>. Lines 38-43 set the filter for this rule, such that the \"type\" attribute has a value of \"primary\". If this condition is true for a particular line, the rule is rendered according to the <LineSymbolizer> which is on lines 44-49. Lines 46-47 set the color of the line to be a bright red (#FF0000) and the width to be 6 pixels, so that these lines are rendered on top of and thicker than the other two road classes. In this way, the \"primary\" roads are given priority in the map rendering.

                                                                                          "},{"location":"styling/sld/cookbook/lines/#zoom-based-line","title":"Zoom-based line","text":"

                                                                                          This example alters the Simple line style at different zoom levels.

                                                                                          Zoom-based line: Zoomed in

                                                                                          Zoom-based line: Partially zoomed

                                                                                          Zoom-based line: Zoomed out

                                                                                          "},{"location":"styling/sld/cookbook/lines/#code_12","title":"Code","text":"

                                                                                          View and download the full \"Zoom-based line\" SLD

                                                                                          <FeatureTypeStyle>\n  <Rule>\n    <Name>Large</Name>\n    <MaxScaleDenominator>180000000</MaxScaleDenominator>\n    <LineSymbolizer>\n      <Stroke>\n        <CssParameter name=\"stroke\">#009933</CssParameter>\n        <CssParameter name=\"stroke-width\">6</CssParameter>\n      </Stroke>\n    </LineSymbolizer>\n  </Rule>\n  <Rule>\n    <Name>Medium</Name>\n    <MinScaleDenominator>180000000</MinScaleDenominator>\n    <MaxScaleDenominator>360000000</MaxScaleDenominator>\n    <LineSymbolizer>\n      <Stroke>\n        <CssParameter name=\"stroke\">#009933</CssParameter>\n        <CssParameter name=\"stroke-width\">4</CssParameter>\n      </Stroke>\n    </LineSymbolizer>\n  </Rule>\n  <Rule>\n    <Name>Small</Name>\n    <MinScaleDenominator>360000000</MinScaleDenominator>\n    <LineSymbolizer>\n      <Stroke>\n        <CssParameter name=\"stroke\">#009933</CssParameter>\n        <CssParameter name=\"stroke-width\">2</CssParameter>\n      </Stroke>\n    </LineSymbolizer>\n  </Rule>\n</FeatureTypeStyle>\n
                                                                                          "},{"location":"styling/sld/cookbook/lines/#details_12","title":"Details","text":"

                                                                                          It is often desirable to make shapes larger at higher zoom levels when creating a natural-looking map. This example varies the thickness of the lines according to the zoom level (or more accurately, scale denominator). Scale denominators refer to the scale of the map. A scale denominator of 10,000 means the map has a scale of 1:10,000 in the units of the map projection.

                                                                                          Note

                                                                                          Determining the appropriate scale denominators (zoom levels) to use is beyond the scope of this example.

                                                                                          This style contains three rules. The three rules are designed as follows:

                                                                                          Rule order Rule name Scale denominator Line width 1 Large 1:180,000,000 or less 6 2 Medium 1:180,000,000 to 1:360,000,000 4 3 Small Greater than 1:360,000,000 2

                                                                                          The order of these rules does not matter since the scales denominated in each rule do not overlap.

                                                                                          The first rule (lines 2-11) is the smallest scale denominator, corresponding to when the view is \"zoomed in\". The scale rule is set on line 4, so that the rule will apply to any map with a scale denominator of 180,000,000 or less. Line 7-8 draws the line to be dark green (#009933) with a width of 6 pixels.

                                                                                          The second rule (lines 12-22) is the intermediate scale denominator, corresponding to when the view is \"partially zoomed\". Lines 14-15 set the scale such that the rule will apply to any map with scale denominators between 180,000,000 and 360,000,000. (The <MinScaleDenominator> is inclusive and the <MaxScaleDenominator> is exclusive, so a zoom level of exactly 360,000,000 would not apply here.) Aside from the scale, the only difference between this rule and the previous is the width of the lines, which is set to 4 pixels on line 19.

                                                                                          The third rule (lines 23-32) is the largest scale denominator, corresponding to when the map is \"zoomed out\". The scale rule is set on line 25, so that the rule will apply to any map with a scale denominator of 360,000,000 or greater. Again, the only other difference between this rule and the others is the width of the lines, which is set to 2 pixels on line 29.

                                                                                          The result of this style is that lines are drawn with larger widths as one zooms in and smaller widths as one zooms out.

                                                                                          "},{"location":"styling/sld/cookbook/points/","title":"Points","text":"

                                                                                          While points are seemingly the simplest type of shape, possessing only position and no other dimensions, there are many different ways that a point can be styled in SLD.

                                                                                          Warning

                                                                                          The code examples shown on this page are not the full SLD code, as they omit the SLD header and footer information for the sake of brevity. Please use the links to download the full SLD for each example.

                                                                                          "},{"location":"styling/sld/cookbook/points/#sld_cookbook_points_attributes","title":"Example points layer","text":"

                                                                                          The points layer used for the examples below contains name and population information for the major cities of a fictional country. For reference, the attribute table for the points in this layer is included below.

                                                                                          fid (Feature ID) name (City name) pop (Population) point.1 Borfin 157860 point.2 Supox City 578231 point.3 Ruckis 98159 point.4 Thisland 34879 point.5 Synopolis 24567 point.6 San Glissando 76024 point.7 Detrania 205609

                                                                                          Download the points shapefile

                                                                                          "},{"location":"styling/sld/cookbook/points/#sld_cookbook_points_simplepoint","title":"Simple point","text":"

                                                                                          This example specifies points be styled as red circles with a diameter of 6 pixels.

                                                                                          Simple point

                                                                                          "},{"location":"styling/sld/cookbook/points/#code","title":"Code","text":"

                                                                                          View and download the full \"Simple point\" SLD

                                                                                          <FeatureTypeStyle>\n  <Rule>\n    <PointSymbolizer>\n      <Graphic>\n        <Mark>\n          <WellKnownName>circle</WellKnownName>\n          <Fill>\n            <CssParameter name=\"fill\">#FF0000</CssParameter>\n          </Fill>\n        </Mark>\n        <Size>6</Size>\n      </Graphic>\n    </PointSymbolizer>\n  </Rule>\n</FeatureTypeStyle>\n
                                                                                          "},{"location":"styling/sld/cookbook/points/#details","title":"Details","text":"

                                                                                          There is one <Rule> in one <FeatureTypeStyle> for this SLD, which is the simplest possible situation. (All subsequent examples will contain one <Rule> and one <FeatureTypeStyle> unless otherwise specified.) Styling points is accomplished via the <PointSymbolizer> (lines 3-13). Line 6 specifies the shape of the symbol to be a circle, with line 8 determining the fill color to be red (#FF0000). Line 11 sets the size (diameter) of the graphic to be 6 pixels.

                                                                                          "},{"location":"styling/sld/cookbook/points/#sld_cookbook_points_simplepointwithstroke","title":"Simple point with stroke","text":"

                                                                                          This example adds a stroke (or border) around the Simple point, with the stroke colored black and given a thickness of 2 pixels.

                                                                                          Simple point with stroke

                                                                                          "},{"location":"styling/sld/cookbook/points/#code_1","title":"Code","text":"

                                                                                          View and download the full \"Simple point with stroke\" SLD

                                                                                          <FeatureTypeStyle>\n  <Rule>\n    <PointSymbolizer>\n      <Graphic>\n        <Mark>\n          <WellKnownName>circle</WellKnownName>\n          <Fill>\n            <CssParameter name=\"fill\">#FF0000</CssParameter>\n          </Fill>\n          <Stroke>\n            <CssParameter name=\"stroke\">#000000</CssParameter>\n            <CssParameter name=\"stroke-width\">2</CssParameter>\n          </Stroke>\n        </Mark>\n        <Size>6</Size>\n      </Graphic>\n    </PointSymbolizer>\n  </Rule>\n</FeatureTypeStyle>\n
                                                                                          "},{"location":"styling/sld/cookbook/points/#details_1","title":"Details","text":"

                                                                                          This example is similar to the Simple point example. Lines 10-13 specify the stroke, with line 11 setting the color to black (#000000) and line 12 setting the width to 2 pixels.

                                                                                          "},{"location":"styling/sld/cookbook/points/#rotated-square","title":"Rotated square","text":"

                                                                                          This example creates a square instead of a circle, colors it green, sizes it to 12 pixels, and rotates it by 45 degrees.

                                                                                          Rotated square

                                                                                          "},{"location":"styling/sld/cookbook/points/#code_2","title":"Code","text":"

                                                                                          View and download the full \"Rotated square\" SLD

                                                                                          <FeatureTypeStyle>\n  <Rule>\n    <PointSymbolizer>\n      <Graphic>\n        <Mark>\n          <WellKnownName>square</WellKnownName>\n          <Fill>\n            <CssParameter name=\"fill\">#009900</CssParameter>\n          </Fill>\n        </Mark>\n        <Size>12</Size>\n        <Rotation>45</Rotation>\n      </Graphic>\n    </PointSymbolizer>\n  </Rule>\n</FeatureTypeStyle>\n
                                                                                          "},{"location":"styling/sld/cookbook/points/#details_2","title":"Details","text":"

                                                                                          In this example, line 6 sets the shape to be a square, with line 8 setting the color to a dark green (#009900). Line 11 sets the size of the square to be 12 pixels, and line 12 set the rotation is to 45 degrees.

                                                                                          "},{"location":"styling/sld/cookbook/points/#transparent-triangle","title":"Transparent triangle","text":"

                                                                                          This example draws a triangle, creates a black stroke identical to the Simple point with stroke example, and sets the fill of the triangle to 20% opacity (mostly transparent).

                                                                                          Transparent triangle

                                                                                          "},{"location":"styling/sld/cookbook/points/#code_3","title":"Code","text":"

                                                                                          View and download the full \"Transparent triangle\" SLD

                                                                                          <FeatureTypeStyle>\n  <Rule>\n    <PointSymbolizer>\n      <Graphic>\n        <Mark>\n          <WellKnownName>triangle</WellKnownName>\n          <Fill>\n            <CssParameter name=\"fill\">#009900</CssParameter>\n            <CssParameter name=\"fill-opacity\">0.2</CssParameter>\n          </Fill>\n          <Stroke>\n            <CssParameter name=\"stroke\">#000000</CssParameter>\n            <CssParameter name=\"stroke-width\">2</CssParameter>\n          </Stroke>\n        </Mark>\n        <Size>12</Size>\n      </Graphic>\n    </PointSymbolizer>\n  </Rule>\n</FeatureTypeStyle>\n
                                                                                          "},{"location":"styling/sld/cookbook/points/#details_3","title":"Details","text":"

                                                                                          In this example, line 6 once again sets the shape, in this case to a triangle. Line 8 sets the fill color to a dark green (#009900) and line 9 sets the opacity to 0.2 (20% opaque). An opacity value of 1 means that the shape is drawn 100% opaque, while an opacity value of 0 means that the shape is drawn 0% opaque, or completely transparent. The value of 0.2 (20% opaque) means that the fill of the points partially takes on the color and style of whatever is drawn beneath it. In this example, since the background is white, the dark green looks lighter. Were the points imposed on a dark background, the resulting color would be darker. Lines 12-13 set the stroke color to black (#000000) and width to 2 pixels. Finally, line 16 sets the size of the point to be 12 pixels in diameter.

                                                                                          "},{"location":"styling/sld/cookbook/points/#point-as-graphic","title":"Point as graphic","text":"

                                                                                          This example styles each point as a graphic instead of as a simple shape.

                                                                                          Point as graphic

                                                                                          "},{"location":"styling/sld/cookbook/points/#code_4","title":"Code","text":"

                                                                                          View and download the full \"Point as graphic\" SLD

                                                                                          <FeatureTypeStyle>\n  <Rule>\n    <PointSymbolizer>\n      <Graphic>\n        <ExternalGraphic>\n          <OnlineResource\n            xlink:type=\"simple\"\n            xlink:href=\"smileyface.png\" />\n          <Format>image/png</Format>\n        </ExternalGraphic>\n        <Size>32</Size>\n      </Graphic>\n    </PointSymbolizer>\n  </Rule>\n</FeatureTypeStyle>\n
                                                                                          "},{"location":"styling/sld/cookbook/points/#details_4","title":"Details","text":"

                                                                                          This style uses a graphic instead of a simple shape to render the points. In SLD, this is known as an <ExternalGraphic>, to distinguish it from the commonly-used shapes such as squares and circles that are \"internal\" to the renderer. Lines 5-10 specify the details of this graphic. Line 8 sets the path and file name of the graphic, while line 9 indicates the format (MIME type) of the graphic (image/png). In this example, the graphic is contained in the same directory as the SLD, so no path information is necessary in line 8, although a full URL could be used if desired. Line 11 determines the size of the displayed graphic; this can be set independently of the dimensions of the graphic itself, although in this case they are the same (32 pixels). Should a graphic be rectangular, the <Size> value will apply to the height of the graphic only, with the width scaled proportionally.

                                                                                          Graphic used for points

                                                                                          "},{"location":"styling/sld/cookbook/points/#sld_cookbook_points_pointwithdefaultlabel","title":"Point with default label","text":"

                                                                                          This example shows a text label on the Simple point that displays the \"name\" attribute of the point. This is how a label will be displayed in the absence of any other customization.

                                                                                          Point with default label

                                                                                          "},{"location":"styling/sld/cookbook/points/#code_5","title":"Code","text":"

                                                                                          View and download the full \"Point with default label\" SLD

                                                                                          <FeatureTypeStyle>\n  <Rule>\n    <PointSymbolizer>\n      <Graphic>\n        <Mark>\n          <WellKnownName>circle</WellKnownName>\n          <Fill>\n            <CssParameter name=\"fill\">#FF0000</CssParameter>\n          </Fill>\n        </Mark>\n        <Size>6</Size>\n      </Graphic>\n    </PointSymbolizer>\n    <TextSymbolizer>\n      <Label>\n        <ogc:PropertyName>name</ogc:PropertyName>\n      </Label>\n      <Fill>\n        <CssParameter name=\"fill\">#000000</CssParameter>\n      </Fill>\n    </TextSymbolizer>\n  </Rule>\n</FeatureTypeStyle>\n
                                                                                          "},{"location":"styling/sld/cookbook/points/#details_5","title":"Details","text":"

                                                                                          Lines 3-13, which contain the <PointSymbolizer>, are identical to the Simple point example above. The label is set in the <TextSymbolizer> on lines 14-27. Lines 15-17 determine what text to display in the label, which in this case is the value of the \"name\" attribute. (Refer to the attribute table in the Example points layer section if necessary.) Line 19 sets the text color. All other details about the label are set to the renderer default, which here is Times New Roman font, font color black, and font size of 10 pixels. The bottom left of the label is aligned with the center of the point.

                                                                                          "},{"location":"styling/sld/cookbook/points/#sld_cookbook_points_pointwithstyledlabel","title":"Point with styled label","text":"

                                                                                          This example improves the label style from the Point with default label example by centering the label above the point and providing a different font name and size.

                                                                                          Point with styled label

                                                                                          "},{"location":"styling/sld/cookbook/points/#code_6","title":"Code","text":"

                                                                                          View and download the full \"Point with styled label\" SLD

                                                                                          <FeatureTypeStyle>\n  <Rule>\n    <PointSymbolizer>\n      <Graphic>\n        <Mark>\n          <WellKnownName>circle</WellKnownName>\n          <Fill>\n            <CssParameter name=\"fill\">#FF0000</CssParameter>\n          </Fill>\n        </Mark>\n        <Size>6</Size>\n      </Graphic>\n    </PointSymbolizer>\n    <TextSymbolizer>\n      <Label>\n        <ogc:PropertyName>name</ogc:PropertyName>\n      </Label>\n      <Font>\n        <CssParameter name=\"font-family\">Arial</CssParameter>\n        <CssParameter name=\"font-size\">12</CssParameter>\n        <CssParameter name=\"font-style\">normal</CssParameter>\n        <CssParameter name=\"font-weight\">bold</CssParameter>\n      </Font>\n      <LabelPlacement>\n        <PointPlacement>\n          <AnchorPoint>\n            <AnchorPointX>0.5</AnchorPointX>\n            <AnchorPointY>0.0</AnchorPointY>\n          </AnchorPoint>\n          <Displacement>\n            <DisplacementX>0</DisplacementX>\n            <DisplacementY>5</DisplacementY>\n          </Displacement>\n        </PointPlacement>\n      </LabelPlacement>\n      <Fill>\n        <CssParameter name=\"fill\">#000000</CssParameter>\n      </Fill>\n    </TextSymbolizer>\n  </Rule>\n</FeatureTypeStyle>\n
                                                                                          "},{"location":"styling/sld/cookbook/points/#details_6","title":"Details","text":"

                                                                                          In this example, lines 3-13 are identical to the Simple point example above. The <TextSymbolizer> on lines 14-39 contains many more details about the label styling than the previous example, Point with default label. Lines 15-17 once again specify the \"name\" attribute as text to display. Lines 18-23 set the font information: line 19 sets the font family to be \"Arial\", line 20 sets the font size to 12, line 21 sets the font style to \"normal\" (as opposed to \"italic\" or \"oblique\"), and line 22 sets the font weight to \"bold\" (as opposed to \"normal\"). Lines 24-35 (<LabelPlacement>) determine the placement of the label relative to the point. The <AnchorPoint> (lines 26-29) sets the point of intersection between the label and point, which here (line 27-28) sets the point to be centered (0.5) horizontally axis and bottom aligned (0.0) vertically with the label. There is also <Displacement> (lines 30-33), which sets the offset of the label relative to the line, which in this case is 0 pixels horizontally (line 31) and 5 pixels vertically (line 32). Finally, line 37 sets the font color of the label to black (#000000).

                                                                                          The result is a centered bold label placed slightly above each point.

                                                                                          "},{"location":"styling/sld/cookbook/points/#point-with-rotated-label","title":"Point with rotated label","text":"

                                                                                          This example builds on the previous example, Point with styled label, by rotating the label by 45 degrees, positioning the labels farther away from the points, and changing the color of the label to purple.

                                                                                          Point with rotated label

                                                                                          "},{"location":"styling/sld/cookbook/points/#code_7","title":"Code","text":"

                                                                                          View and download the full \"Point with rotated label\" SLD

                                                                                          <FeatureTypeStyle>\n  <Rule>\n    <PointSymbolizer>\n      <Graphic>\n        <Mark>\n          <WellKnownName>circle</WellKnownName>\n          <Fill>\n            <CssParameter name=\"fill\">#FF0000</CssParameter>\n          </Fill>\n        </Mark>\n        <Size>6</Size>\n      </Graphic>\n    </PointSymbolizer>\n    <TextSymbolizer>\n      <Label>\n        <ogc:PropertyName>name</ogc:PropertyName>\n      </Label>\n      <Font>\n        <CssParameter name=\"font-family\">Arial</CssParameter>\n        <CssParameter name=\"font-size\">12</CssParameter>\n        <CssParameter name=\"font-style\">normal</CssParameter>\n        <CssParameter name=\"font-weight\">bold</CssParameter>\n      </Font>\n      <LabelPlacement>\n        <PointPlacement>\n          <AnchorPoint>\n            <AnchorPointX>0.5</AnchorPointX>\n            <AnchorPointY>0.0</AnchorPointY>\n          </AnchorPoint>\n          <Displacement>\n            <DisplacementX>0</DisplacementX>\n            <DisplacementY>25</DisplacementY>\n          </Displacement>\n          <Rotation>-45</Rotation>\n        </PointPlacement>\n      </LabelPlacement>\n      <Fill>\n        <CssParameter name=\"fill\">#990099</CssParameter>\n      </Fill>\n    </TextSymbolizer>\n  </Rule>\n</FeatureTypeStyle>\n
                                                                                          "},{"location":"styling/sld/cookbook/points/#details_7","title":"Details","text":"

                                                                                          This example is similar to the Point with styled label, but there are three important differences. Line 32 specifies 25 pixels of vertical displacement. Line 34 specifies a rotation of \"-45\" or 45 degrees counter-clockwise. (Rotation values increase clockwise, which is why the value is negative.) Finally, line 38 sets the font color to be a shade of purple (#99099).

                                                                                          Note that the displacement takes effect before the rotation during rendering, so in this example, the 25 pixel vertical displacement is itself rotated 45 degrees.

                                                                                          "},{"location":"styling/sld/cookbook/points/#attribute-based-point","title":"Attribute-based point","text":"

                                                                                          This example alters the size of the symbol based on the value of the population (\"pop\") attribute.

                                                                                          Attribute-based point

                                                                                          "},{"location":"styling/sld/cookbook/points/#code_8","title":"Code","text":"

                                                                                          View and download the full \"Attribute-based point\" SLD

                                                                                          <FeatureTypeStyle>\n  <Rule>\n    <Name>SmallPop</Name>\n    <Title>1 to 50000</Title>\n    <ogc:Filter>\n      <ogc:PropertyIsLessThan>\n        <ogc:PropertyName>pop</ogc:PropertyName>\n        <ogc:Literal>50000</ogc:Literal>\n      </ogc:PropertyIsLessThan>\n    </ogc:Filter>\n    <PointSymbolizer>\n      <Graphic>\n        <Mark>\n          <WellKnownName>circle</WellKnownName>\n          <Fill>\n            <CssParameter name=\"fill\">#0033CC</CssParameter>\n          </Fill>\n        </Mark>\n        <Size>8</Size>\n      </Graphic>\n    </PointSymbolizer>\n  </Rule>\n  <Rule>\n    <Name>MediumPop</Name>\n    <Title>50000 to 100000</Title>\n    <ogc:Filter>\n      <ogc:And>\n        <ogc:PropertyIsGreaterThanOrEqualTo>\n          <ogc:PropertyName>pop</ogc:PropertyName>\n          <ogc:Literal>50000</ogc:Literal>\n        </ogc:PropertyIsGreaterThanOrEqualTo>\n        <ogc:PropertyIsLessThan>\n          <ogc:PropertyName>pop</ogc:PropertyName>\n          <ogc:Literal>100000</ogc:Literal>\n        </ogc:PropertyIsLessThan>\n      </ogc:And>\n    </ogc:Filter>\n    <PointSymbolizer>\n      <Graphic>\n        <Mark>\n          <WellKnownName>circle</WellKnownName>\n          <Fill>\n            <CssParameter name=\"fill\">#0033CC</CssParameter>\n          </Fill>\n        </Mark>\n        <Size>12</Size>\n      </Graphic>\n    </PointSymbolizer>\n  </Rule>\n  <Rule>\n    <Name>LargePop</Name>\n    <Title>Greater than 100000</Title>\n    <ogc:Filter>\n      <ogc:PropertyIsGreaterThanOrEqualTo>\n        <ogc:PropertyName>pop</ogc:PropertyName>\n        <ogc:Literal>100000</ogc:Literal>\n      </ogc:PropertyIsGreaterThanOrEqualTo>\n    </ogc:Filter>\n    <PointSymbolizer>\n      <Graphic>\n        <Mark>\n          <WellKnownName>circle</WellKnownName>\n          <Fill>\n            <CssParameter name=\"fill\">#0033CC</CssParameter>\n          </Fill>\n        </Mark>\n        <Size>16</Size>\n      </Graphic>\n    </PointSymbolizer>\n  </Rule>\n</FeatureTypeStyle>\n
                                                                                          "},{"location":"styling/sld/cookbook/points/#details_8","title":"Details","text":"

                                                                                          Note

                                                                                          Refer to the Example points layer to see the attributes for this data. This example has eschewed labels in order to simplify the style, but you can refer to the example Point with styled label to see which attributes correspond to which points.

                                                                                          This style contains three rules. Each <Rule> varies the style based on the value of the population (\"pop\") attribute for each point, with smaller values yielding a smaller circle, and larger values yielding a larger circle.

                                                                                          The three rules are designed as follows:

                                                                                          Rule order Rule name Population (\"pop\") Size 1 SmallPop Less than 50,000 8 2 MediumPop 50,000 to 100,000 12 3 LargePop Greater than 100,000 16

                                                                                          The order of the rules does not matter in this case, since each shape is only rendered by a single rule.

                                                                                          The first rule, on lines 2-22, specifies the styling of those points whose population attribute is less than 50,000. Lines 5-10 set this filter, with lines 6-9 setting the \"less than\" filter, line 7 denoting the attribute (\"pop\"), and line 8 the value of 50,000. The symbol is a circle (line 14), the color is dark blue (#0033CC, on line 16), and the size is 8 pixels in diameter (line 19).

                                                                                          The second rule, on lines 23-49, specifies a style for points whose population attribute is greater than or equal to 50,000 and less than 100,000. The population filter is set on lines 26-37. This filter is longer than in the first rule because two criteria need to be specified instead of one: a \"greater than or equal to\" and a \"less than\" filter. Notice the And on line 27 and line 36. This mandates that both filters need to be true for the rule to be applicable. The size of the graphic is set to 12 pixels on line 46. All other styling directives are identical to the first rule.

                                                                                          The third rule, on lines 50-70, specifies a style for points whose population attribute is greater than or equal to 100,000. The population filter is set on lines 53-58, and the only other difference is the size of the circle, which in this rule (line 67) is 16 pixels.

                                                                                          The result of this style is that cities with larger populations have larger points.

                                                                                          "},{"location":"styling/sld/cookbook/points/#zoom-based-point","title":"Zoom-based point","text":"

                                                                                          This example alters the style of the points at different zoom levels.

                                                                                          Zoom-based point: Zoomed in

                                                                                          Zoom-based point: Partially zoomed

                                                                                          Zoom-based point: Zoomed out

                                                                                          "},{"location":"styling/sld/cookbook/points/#code_9","title":"Code","text":"

                                                                                          View and download the full \"Zoom-based point\" SLD

                                                                                          <FeatureTypeStyle>\n  <Rule>\n    <Name>Large</Name>\n    <MaxScaleDenominator>160000000</MaxScaleDenominator>\n    <PointSymbolizer>\n      <Graphic>\n        <Mark>\n          <WellKnownName>circle</WellKnownName>\n          <Fill>\n            <CssParameter name=\"fill\">#CC3300</CssParameter>\n          </Fill>\n        </Mark>\n        <Size>12</Size>\n      </Graphic>\n    </PointSymbolizer>\n  </Rule>\n  <Rule>\n    <Name>Medium</Name>\n    <MinScaleDenominator>160000000</MinScaleDenominator>\n    <MaxScaleDenominator>320000000</MaxScaleDenominator>\n    <PointSymbolizer>\n      <Graphic>\n        <Mark>\n          <WellKnownName>circle</WellKnownName>\n          <Fill>\n            <CssParameter name=\"fill\">#CC3300</CssParameter>\n          </Fill>\n        </Mark>\n        <Size>8</Size>\n      </Graphic>\n    </PointSymbolizer>\n  </Rule>\n  <Rule>\n    <Name>Small</Name>\n    <MinScaleDenominator>320000000</MinScaleDenominator>\n    <PointSymbolizer>\n      <Graphic>\n        <Mark>\n          <WellKnownName>circle</WellKnownName>\n          <Fill>\n            <CssParameter name=\"fill\">#CC3300</CssParameter>\n          </Fill>\n        </Mark>\n        <Size>4</Size>\n      </Graphic>\n    </PointSymbolizer>\n  </Rule>\n</FeatureTypeStyle>\n
                                                                                          "},{"location":"styling/sld/cookbook/points/#details_9","title":"Details","text":"

                                                                                          It is often desirable to make shapes larger at higher zoom levels when creating a natural-looking map. This example styles the points to vary in size based on the zoom level (or more accurately, scale denominator). Scale denominators refer to the scale of the map. A scale denominator of 10,000 means the map has a scale of 1:10,000 in the units of the map projection.

                                                                                          Note

                                                                                          Determining the appropriate scale denominators (zoom levels) to use is beyond the scope of this example.

                                                                                          This style contains three rules. The three rules are designed as follows:

                                                                                          Rule order Rule name Scale denominator Point size 1 Large 1:160,000,000 or less 12 2 Medium 1:160,000,000 to 1:320,000,000 8 3 Small Greater than 1:320,000,000 4

                                                                                          The order of these rules does not matter since the scales denominated in each rule do not overlap.

                                                                                          The first rule (lines 2-16) is for the smallest scale denominator, corresponding to when the view is \"zoomed in\". The scale rule is set on line 4, so that the rule will apply to any map with a scale denominator of 160,000,000 or less. The rule draws a circle (line 8), colored red (#CC3300 on line 10) with a size of 12 pixels (line 13).

                                                                                          The second rule (lines 17-32) is the intermediate scale denominator, corresponding to when the view is \"partially zoomed\". The scale rules are set on lines 19-20, so that the rule will apply to any map with a scale denominator between 160,000,000 and 320,000,000. (The <MinScaleDenominator> is inclusive and the <MaxScaleDenominator> is exclusive, so a zoom level of exactly 320,000,000 would not apply here.) Aside from the scale, the only difference between this rule and the first is the size of the symbol, which is set to 8 pixels on line 29.

                                                                                          The third rule (lines 33-47) is the largest scale denominator, corresponding to when the map is \"zoomed out\". The scale rule is set on line 35, so that the rule will apply to any map with a scale denominator of 320,000,000 or more. Again, the only other difference between this rule and the others is the size of the symbol, which is set to 4 pixels on line 44.

                                                                                          The result of this style is that points are drawn larger as one zooms in and smaller as one zooms out.

                                                                                          "},{"location":"styling/sld/cookbook/polygons/","title":"Polygons","text":"

                                                                                          Polygons are two dimensional shapes that contain both an outer edge (or \"stroke\") and an inside (or \"fill\"). A polygon can be thought of as an irregularly-shaped point and is styled in similar ways to points.

                                                                                          Warning

                                                                                          The code examples shown on this page are not the full SLD code, as they omit the SLD header and footer information for the sake of brevity. Please use the links to download the full SLD for each example.

                                                                                          "},{"location":"styling/sld/cookbook/polygons/#sld_cookbook_polygons_attributes","title":"Example polygons layer","text":"

                                                                                          The polygons layer used below contains county information for a fictional country. For reference, the attribute table for the polygons is included below.

                                                                                          fid (Feature ID) name (County name) pop (Population) polygon.1 Irony County 412234 polygon.2 Tracker County 235421 polygon.3 Dracula County 135022 polygon.4 Poly County 1567879 polygon.5 Bearing County 201989 polygon.6 Monte Cristo County 152734 polygon.7 Massive County 67123 polygon.8 Rhombus County 198029

                                                                                          Download the polygons shapefile

                                                                                          "},{"location":"styling/sld/cookbook/polygons/#sld_cookbook_polygons_simplepolygon","title":"Simple polygon","text":"

                                                                                          This example shows a polygon filled in blue.

                                                                                          Simple polygon

                                                                                          "},{"location":"styling/sld/cookbook/polygons/#code","title":"Code","text":"

                                                                                          View and download the full \"Simple polygon\" SLD

                                                                                          <FeatureTypeStyle>\n  <Rule>\n    <PolygonSymbolizer>\n      <Fill>\n        <CssParameter name=\"fill\">#000080</CssParameter>\n      </Fill>\n    </PolygonSymbolizer>\n  </Rule>\n</FeatureTypeStyle>\n
                                                                                          "},{"location":"styling/sld/cookbook/polygons/#details","title":"Details","text":"

                                                                                          There is one <Rule> in one <FeatureTypeStyle> for this style, which is the simplest possible situation. (All subsequent examples will share this characteristic unless otherwise specified.) Styling polygons is accomplished via the <PolygonSymbolizer> (lines 3-7). Line 5 specifies dark blue (#000080) as the polygon's fill color.

                                                                                          Note

                                                                                          The light-colored borders around the polygons in the figure are artifacts of the renderer caused by the polygons being adjacent. There is no border in this style.

                                                                                          "},{"location":"styling/sld/cookbook/polygons/#sld_cookbook_polygons_simplepolygonwithstroke","title":"Simple polygon with stroke","text":"

                                                                                          This example adds a 2 pixel white stroke to the Simple polygon example.

                                                                                          Simple polygon with stroke

                                                                                          "},{"location":"styling/sld/cookbook/polygons/#code_1","title":"Code","text":"

                                                                                          View and download the full \"Simple polygon with stroke\" SLD

                                                                                          <FeatureTypeStyle>\n  <Rule>\n    <PolygonSymbolizer>\n      <Fill>\n        <CssParameter name=\"fill\">#000080</CssParameter>\n      </Fill>\n      <Stroke>\n        <CssParameter name=\"stroke\">#FFFFFF</CssParameter>\n        <CssParameter name=\"stroke-width\">2</CssParameter>\n      </Stroke>\n    </PolygonSymbolizer>\n  </Rule>\n</FeatureTypeStyle>\n
                                                                                          "},{"location":"styling/sld/cookbook/polygons/#details_1","title":"Details","text":"

                                                                                          This example is similar to the Simple polygon example above, with the addition of the <Stroke> tag (lines 7-10). Line 8 sets the color of stroke to white (#FFFFFF) and line 9 sets the width of the stroke to 2 pixels.

                                                                                          "},{"location":"styling/sld/cookbook/polygons/#transparent-polygon","title":"Transparent polygon","text":"

                                                                                          This example builds on the Simple polygon with stroke example and makes the fill partially transparent by setting the opacity to 50%.

                                                                                          Transparent polygon

                                                                                          "},{"location":"styling/sld/cookbook/polygons/#code_2","title":"Code","text":"

                                                                                          View and download the full \"Transparent polygon\" SLD

                                                                                          <FeatureTypeStyle>\n  <Rule>\n    <PolygonSymbolizer>\n      <Fill>\n        <CssParameter name=\"fill\">#000080</CssParameter>\n        <CssParameter name=\"fill-opacity\">0.5</CssParameter>\n      </Fill>\n      <Stroke>\n        <CssParameter name=\"stroke\">#FFFFFF</CssParameter>\n        <CssParameter name=\"stroke-width\">2</CssParameter>\n      </Stroke>\n    </PolygonSymbolizer>\n  </Rule>\n</FeatureTypeStyle>\n
                                                                                          "},{"location":"styling/sld/cookbook/polygons/#details_2","title":"Details","text":"

                                                                                          This example is similar to the Simple polygon with stroke example, save for defining the fill's opacity in line 6. The value of 0.5 results in partially transparent fill that is 50% opaque. An opacity value of 1 would draw the fill as 100% opaque, while an opacity value of 0 would result in a completely transparent (0% opaque) fill. In this example, since the background is white, the dark blue looks lighter. Were the points imposed on a dark background, the resulting color would be darker.

                                                                                          "},{"location":"styling/sld/cookbook/polygons/#sld_cookbook_polygons_offset","title":"Offset inner lines","text":"

                                                                                          Shows how to draw inner buffer lines inside a polygon.

                                                                                          Offset buffer

                                                                                          "},{"location":"styling/sld/cookbook/polygons/#code_3","title":"Code","text":"

                                                                                          View and download the full \"Inner offset lines\" SLD

                                                                                          <FeatureTypeStyle>\n  <Rule>\n    <PolygonSymbolizer>\n      <Stroke>\n        <CssParameter name=\"stroke\">#000000</CssParameter>\n        <CssParameter name=\"stroke-width\">2</CssParameter> \n      </Stroke>\n    </PolygonSymbolizer>\n    <LineSymbolizer>\n      <Stroke>\n        <CssParameter name=\"stroke\">#AAAAAA</CssParameter>\n        <CssParameter name=\"stroke-width\">3</CssParameter>\n      </Stroke>\n      <PerpendicularOffset>-2</PerpendicularOffset>\n    </LineSymbolizer>\n  </Rule>\n</FeatureTypeStyle>\n
                                                                                          "},{"location":"styling/sld/cookbook/polygons/#details_3","title":"Details","text":"

                                                                                          This example is similar to the Simple polygon with stroke example, save for defining adding a <LineSymbolizer>> at line 9, where a light gray (line 11) 3 pixels wide (line 12) line is drawn as a inner buffer inside the polygon. Line 14 controls the buffering distance, setting a inner buffer of 2 pixels.

                                                                                          "},{"location":"styling/sld/cookbook/polygons/#sld_cookbook_polygons_graphicfill","title":"Graphic fill","text":"

                                                                                          This example fills the polygons with a tiled graphic.

                                                                                          Graphic fill

                                                                                          "},{"location":"styling/sld/cookbook/polygons/#code_4","title":"Code","text":"

                                                                                          View and download the full \"Graphic fill\" SLD

                                                                                          <FeatureTypeStyle>\n  <Rule>\n    <PolygonSymbolizer>\n      <Fill>\n        <GraphicFill>\n          <Graphic>\n            <ExternalGraphic>\n              <OnlineResource\n                xlink:type=\"simple\"\n                xlink:href=\"colorblocks.png\" />\n              <Format>image/png</Format>\n            </ExternalGraphic>\n          <Size>93</Size>\n          </Graphic>\n        </GraphicFill>\n      </Fill>\n    </PolygonSymbolizer>\n  </Rule>\n</FeatureTypeStyle>\n
                                                                                          "},{"location":"styling/sld/cookbook/polygons/#details_4","title":"Details","text":"

                                                                                          This style fills the polygon with a tiled graphic. This is known as an <ExternalGraphic> in SLD, to distinguish it from commonly-used shapes such as squares and circles that are \"internal\" to the renderer. Lines 7-12 specify details for the graphic, with line 10 setting the path and file name of the graphic and line 11 indicating the file format (MIME type) of the graphic (image/png). Although a full URL could be specified if desired, no path information is necessary in line 11 because this graphic is contained in the same directory as the SLD. Line 13 determines the height of the displayed graphic in pixels; if the value differs from the height of the graphic then it will be scaled accordingly while preserving the aspect ratio.

                                                                                          Graphic used for fill

                                                                                          "},{"location":"styling/sld/cookbook/polygons/#hatching-fill","title":"Hatching fill","text":"

                                                                                          This example fills the polygons with a hatching pattern.

                                                                                          Note

                                                                                          This example leverages an SLD extension in GeoServer. Hatching is not part of the standard SLD 1.0 specification.

                                                                                          Hatching fill

                                                                                          "},{"location":"styling/sld/cookbook/polygons/#code_5","title":"Code","text":"

                                                                                          View and download the full \"Hatching fill\" SLD

                                                                                          <FeatureTypeStyle>\n  <Rule>\n    <PolygonSymbolizer>\n      <Fill>\n        <GraphicFill>\n          <Graphic>\n            <Mark>\n              <WellKnownName>shape://times</WellKnownName>\n              <Stroke>\n                <CssParameter name=\"stroke\">#990099</CssParameter>\n                <CssParameter name=\"stroke-width\">1</CssParameter>\n              </Stroke>\n            </Mark>\n            <Size>16</Size>\n          </Graphic>\n        </GraphicFill>\n      </Fill>\n    </PolygonSymbolizer>\n  </Rule>\n</FeatureTypeStyle>\n
                                                                                          "},{"location":"styling/sld/cookbook/polygons/#details_5","title":"Details","text":"

                                                                                          In this example, there is a <GraphicFill> tag as in the Graphic fill example, but a <Mark> (lines 7-13) is used instead of an <ExternalGraphic>. Line 8 specifies a \"times\" symbol (an \"x\") be tiled throughout the polygon. Line 10 sets the color to purple (#990099), line 11 sets the width of the hatches to 1 pixel, and line 14 sets the size of the tile to 16 pixels. Because hatch tiles are always square, the <Size> sets both the width and the height.

                                                                                          "},{"location":"styling/sld/cookbook/polygons/#sld_cookbook_polygons_polygonwithdefaultlabel","title":"Polygon with default label","text":"

                                                                                          This example shows a text label on the polygon. In the absence of any other customization, this is how a label will be displayed.

                                                                                          Polygon with default label

                                                                                          "},{"location":"styling/sld/cookbook/polygons/#code_6","title":"Code","text":"

                                                                                          View and download the full \"Polygon with default label\" SLD

                                                                                          <FeatureTypeStyle>\n  <Rule>\n    <PolygonSymbolizer>\n      <Fill>\n        <CssParameter name=\"fill\">#40FF40</CssParameter>\n      </Fill>\n      <Stroke>\n        <CssParameter name=\"stroke\">#FFFFFF</CssParameter>\n        <CssParameter name=\"stroke-width\">2</CssParameter>\n      </Stroke>\n    </PolygonSymbolizer>        \n    <TextSymbolizer>\n      <Label>\n        <ogc:PropertyName>name</ogc:PropertyName>\n      </Label>            \n    </TextSymbolizer>\n  </Rule>\n</FeatureTypeStyle>\n
                                                                                          "},{"location":"styling/sld/cookbook/polygons/#details_6","title":"Details","text":"

                                                                                          In this example there is a <PolygonSymbolizer> and a <TextSymbolizer>. Lines 3-11 comprise the <PolygonSymbolizer>. The fill of the polygon is set on line 5 to a light green (#40FF40) while the stroke of the polygon is set on lines 8-9 to white (#FFFFFF) with a thickness of 2 pixels. The label is set in the <TextSymbolizer> on lines 12-16, with line 14 determining what text to display, in this case the value of the \"name\" attribute. (Refer to the attribute table in the Example polygons layer section if necessary.) All other details about the label are set to the renderer default, which here is Times New Roman font, font color black, and font size of 10 pixels.

                                                                                          "},{"location":"styling/sld/cookbook/polygons/#label-halo","title":"Label halo","text":"

                                                                                          This example alters the look of the Polygon with default label by adding a white halo to the label.

                                                                                          Label halo

                                                                                          "},{"location":"styling/sld/cookbook/polygons/#code_7","title":"Code","text":"

                                                                                          View and download the full \"Label halo\" SLD

                                                                                          <FeatureTypeStyle>\n  <Rule>\n    <PolygonSymbolizer>\n      <Fill>\n        <CssParameter name=\"fill\">#40FF40</CssParameter>\n      </Fill>\n      <Stroke>\n        <CssParameter name=\"stroke\">#FFFFFF</CssParameter>\n        <CssParameter name=\"stroke-width\">2</CssParameter>\n      </Stroke>\n    </PolygonSymbolizer>        \n    <TextSymbolizer>\n      <Label>\n        <ogc:PropertyName>name</ogc:PropertyName>\n      </Label>\n      <Halo>\n        <Radius>3</Radius>\n        <Fill>\n          <CssParameter name=\"fill\">#FFFFFF</CssParameter>\n        </Fill>\n      </Halo>\n    </TextSymbolizer>\n  </Rule>\n</FeatureTypeStyle>\n
                                                                                          "},{"location":"styling/sld/cookbook/polygons/#details_7","title":"Details","text":"

                                                                                          This example is similar to the Polygon with default label, with the addition of a halo around the labels on lines 16-21. A halo creates a color buffer around the label to improve label legibility. Line 17 sets the radius of the halo, extending the halo 3 pixels around the edge of the label, and line 19 sets the color of the halo to white (#FFFFFF). Since halos are most useful when set to a sharp contrast relative to the text color, this example uses a white halo around black text to ensure optimum readability.

                                                                                          "},{"location":"styling/sld/cookbook/polygons/#sld_cookbook_polygons_polygonwithstyledlabel","title":"Polygon with styled label","text":"

                                                                                          This example improves the label style from the Polygon with default label example by centering the label on the polygon, specifying a different font name and size, and setting additional label placement optimizations.

                                                                                          Note

                                                                                          The label placement optimizations discussed below (the <VendorOption> tags) are SLD extensions that are custom to GeoServer. They are not part of the SLD 1.0 specification.

                                                                                          Polygon with styled label

                                                                                          "},{"location":"styling/sld/cookbook/polygons/#code_8","title":"Code","text":"

                                                                                          View and download the full \"Polygon with styled label\" SLD

                                                                                          <FeatureTypeStyle>\n  <Rule>\n    <PolygonSymbolizer>\n      <Fill>\n        <CssParameter name=\"fill\">#40FF40</CssParameter>\n      </Fill>\n      <Stroke>\n        <CssParameter name=\"stroke\">#FFFFFF</CssParameter>\n        <CssParameter name=\"stroke-width\">2</CssParameter>\n      </Stroke>\n    </PolygonSymbolizer>        \n    <TextSymbolizer>\n      <Label>\n        <ogc:PropertyName>name</ogc:PropertyName>\n      </Label>\n      <Font>\n        <CssParameter name=\"font-family\">Arial</CssParameter>\n        <CssParameter name=\"font-size\">11</CssParameter>\n        <CssParameter name=\"font-style\">normal</CssParameter>\n        <CssParameter name=\"font-weight\">bold</CssParameter>\n      </Font>\n      <LabelPlacement>\n        <PointPlacement>\n          <AnchorPoint>\n            <AnchorPointX>0.5</AnchorPointX>\n            <AnchorPointY>0.5</AnchorPointY>\n          </AnchorPoint>\n        </PointPlacement>\n      </LabelPlacement>\n      <Fill>\n        <CssParameter name=\"fill\">#000000</CssParameter>\n      </Fill>\n      <VendorOption name=\"autoWrap\">60</VendorOption>\n      <VendorOption name=\"maxDisplacement\">150</VendorOption>\n    </TextSymbolizer>\n  </Rule>\n</FeatureTypeStyle>\n
                                                                                          "},{"location":"styling/sld/cookbook/polygons/#details_8","title":"Details","text":"

                                                                                          This example is similar to the Polygon with default label example, with additional styling options within the <TextSymbolizer> on lines 12-35. Lines 16-21 set the font styling. Line 17 sets the font family to be Arial, line 18 sets the font size to 11 pixels, line 19 sets the font style to \"normal\" (as opposed to \"italic\" or \"oblique\"), and line 20 sets the font weight to \"bold\" (as opposed to \"normal\").

                                                                                          The <LabelPlacement> tag on lines 22-29 affects where the label is placed relative to the centroid of the polygon. Line 21 centers the label by positioning it 50% (or 0.5) of the way horizontally along the centroid of the polygon. Line 22 centers the label vertically in exactly the same way.

                                                                                          Finally, there are two added touches for label placement optimization: line 33 ensures that long labels are split across multiple lines by setting line wrapping on the labels to 60 pixels, and line 34 allows the label to be displaced by up to 150 pixels. This ensures that labels are compacted and less likely to spill over polygon boundaries. Notice little Massive County in the corner, whose label is now displayed.\"

                                                                                          "},{"location":"styling/sld/cookbook/polygons/#attribute-based-polygon","title":"Attribute-based polygon","text":"

                                                                                          This example styles the polygons differently based on the \"pop\" (Population) attribute.

                                                                                          Attribute-based polygon

                                                                                          "},{"location":"styling/sld/cookbook/polygons/#code_9","title":"Code","text":"

                                                                                          View and download the full \"Attribute-based polygon\" SLD

                                                                                          <FeatureTypeStyle>\n  <Rule>\n    <Name>SmallPop</Name>\n    <Title>Less Than 200,000</Title>\n    <ogc:Filter>\n      <ogc:PropertyIsLessThan>\n        <ogc:PropertyName>pop</ogc:PropertyName>\n        <ogc:Literal>200000</ogc:Literal>\n      </ogc:PropertyIsLessThan>\n    </ogc:Filter>\n    <PolygonSymbolizer>\n      <Fill>\n        <CssParameter name=\"fill\">#66FF66</CssParameter>\n      </Fill>\n    </PolygonSymbolizer>\n  </Rule>\n  <Rule>\n    <Name>MediumPop</Name>\n    <Title>200,000 to 500,000</Title>\n    <ogc:Filter>\n      <ogc:And>\n        <ogc:PropertyIsGreaterThanOrEqualTo>\n          <ogc:PropertyName>pop</ogc:PropertyName>\n          <ogc:Literal>200000</ogc:Literal>\n        </ogc:PropertyIsGreaterThanOrEqualTo>\n        <ogc:PropertyIsLessThan>\n          <ogc:PropertyName>pop</ogc:PropertyName>\n          <ogc:Literal>500000</ogc:Literal>\n        </ogc:PropertyIsLessThan>\n      </ogc:And>\n    </ogc:Filter>\n    <PolygonSymbolizer>\n      <Fill>\n        <CssParameter name=\"fill\">#33CC33</CssParameter>\n      </Fill>\n    </PolygonSymbolizer>\n  </Rule>\n  <Rule>\n    <Name>LargePop</Name>\n    <Title>Greater Than 500,000</Title>\n    <ogc:Filter>\n      <ogc:PropertyIsGreaterThan>\n        <ogc:PropertyName>pop</ogc:PropertyName>\n        <ogc:Literal>500000</ogc:Literal>\n      </ogc:PropertyIsGreaterThan>\n    </ogc:Filter>\n    <PolygonSymbolizer>\n      <Fill>\n        <CssParameter name=\"fill\">#009900</CssParameter>\n      </Fill>\n    </PolygonSymbolizer>\n  </Rule>\n</FeatureTypeStyle>\n
                                                                                          "},{"location":"styling/sld/cookbook/polygons/#details_9","title":"Details","text":"

                                                                                          Note

                                                                                          Refer to the Example polygons layer to see the attributes for the layer. This example has eschewed labels in order to simplify the style, but you can refer to the example Polygon with styled label to see which attributes correspond to which polygons.

                                                                                          Each polygon in our fictional country has a population that is represented by the population (\"pop\") attribute. This style contains three rules that alter the fill based on the value of \"pop\" attribute, with smaller values yielding a lighter color and larger values yielding a darker color.

                                                                                          The three rules are designed as follows:

                                                                                          Rule order Rule name Population (\"pop\") Color 1 SmallPop Less than 200,000 #66FF66 2 MediumPop 200,000 to 500,000 #33CC33 3 LargePop Greater than 500,000 #009900

                                                                                          The order of the rules does not matter in this case, since each shape is only rendered by a single rule.

                                                                                          The first rule, on lines 2-16, specifies the styling of polygons whose population attribute is less than 200,000. Lines 5-10 set this filter, with lines 6-9 setting the \"less than\" filter, line 7 denoting the attribute (\"pop\"), and line 8 the value of 200,000. The color of the polygon fill is set to a light green (#66FF66) on line 13.

                                                                                          The second rule, on lines 17-37, is similar, specifying a style for polygons whose population attribute is greater than or equal to 200,000 but less than 500,000. The filter is set on lines 20-31. This filter is longer than in the first rule because two criteria need to be specified instead of one: a \"greater than or equal to\" and a \"less than\" filter. Notice the And on line 21 and line 30. This mandates that both filters need to be true for the rule to be applicable. The color of the polygon fill is set to a medium green on (#33CC33) on line 34.

                                                                                          The third rule, on lines 38-52, specifies a style for polygons whose population attribute is greater than or equal to 500,000. The filter is set on lines 41-46. The color of the polygon fill is the only other difference in this rule, which is set to a dark green (#009900) on line 49.

                                                                                          "},{"location":"styling/sld/cookbook/polygons/#zoom-based-polygon","title":"Zoom-based polygon","text":"

                                                                                          This example alters the style of the polygon at different zoom levels.

                                                                                          Zoom-based polygon: Zoomed in

                                                                                          Zoom-based polygon: Partially zoomed

                                                                                          Zoom-based polygon: Zoomed out

                                                                                          "},{"location":"styling/sld/cookbook/polygons/#code_10","title":"Code","text":"

                                                                                          View and download the full \"Zoom-based polygon\" SLD

                                                                                          <FeatureTypeStyle>\n  <Rule>\n    <Name>Large</Name>\n    <MaxScaleDenominator>100000000</MaxScaleDenominator>\n    <PolygonSymbolizer>\n      <Fill>\n        <CssParameter name=\"fill\">#0000CC</CssParameter>\n      </Fill>\n      <Stroke>\n        <CssParameter name=\"stroke\">#000000</CssParameter>\n        <CssParameter name=\"stroke-width\">7</CssParameter>\n      </Stroke>\n    </PolygonSymbolizer>\n    <TextSymbolizer>\n      <Label>\n        <ogc:PropertyName>name</ogc:PropertyName>\n      </Label>  \n      <Font>\n        <CssParameter name=\"font-family\">Arial</CssParameter>\n        <CssParameter name=\"font-size\">14</CssParameter>\n        <CssParameter name=\"font-style\">normal</CssParameter>\n        <CssParameter name=\"font-weight\">bold</CssParameter>\n      </Font>\n      <LabelPlacement>\n        <PointPlacement>\n          <AnchorPoint>\n            <AnchorPointX>0.5</AnchorPointX>\n            <AnchorPointY>0.5</AnchorPointY>\n          </AnchorPoint>\n        </PointPlacement>\n      </LabelPlacement>\n      <Fill>\n        <CssParameter name=\"fill\">#FFFFFF</CssParameter>\n      </Fill>\n    </TextSymbolizer>\n  </Rule>\n  <Rule>\n    <Name>Medium</Name>\n    <MinScaleDenominator>100000000</MinScaleDenominator>\n    <MaxScaleDenominator>200000000</MaxScaleDenominator>\n    <PolygonSymbolizer>\n      <Fill>\n        <CssParameter name=\"fill\">#0000CC</CssParameter>\n      </Fill>\n      <Stroke>\n        <CssParameter name=\"stroke\">#000000</CssParameter>\n        <CssParameter name=\"stroke-width\">4</CssParameter>\n      </Stroke>\n    </PolygonSymbolizer>\n  </Rule>\n  <Rule>\n    <Name>Small</Name>\n    <MinScaleDenominator>200000000</MinScaleDenominator>\n    <PolygonSymbolizer>\n      <Fill>\n        <CssParameter name=\"fill\">#0000CC</CssParameter>\n      </Fill>\n      <Stroke>\n        <CssParameter name=\"stroke\">#000000</CssParameter>\n        <CssParameter name=\"stroke-width\">1</CssParameter>\n      </Stroke>\n    </PolygonSymbolizer>\n  </Rule>\n</FeatureTypeStyle>\n
                                                                                          "},{"location":"styling/sld/cookbook/polygons/#details_10","title":"Details","text":"

                                                                                          It is often desirable to make shapes larger at higher zoom levels when creating a natural-looking map. This example varies the thickness of the lines according to the zoom level. Polygons already do this by nature of being two dimensional, but another way to adjust styling of polygons based on zoom level is to adjust the thickness of the stroke (to be larger as the map is zoomed in) or to limit labels to only certain zoom levels. This is ensures that the size and quantity of strokes and labels remains legible and doesn't overshadow the polygons themselves.

                                                                                          Zoom levels (or more accurately, scale denominators) refer to the scale of the map. A scale denominator of 10,000 means the map has a scale of 1:10,000 in the units of the map projection.

                                                                                          Note

                                                                                          Determining the appropriate scale denominators (zoom levels) to use is beyond the scope of this example.

                                                                                          This style contains three rules, defined as follows:

                                                                                          Rule order Rule name Scale denominator Stroke width Label display? 1 Large 1:100,000,000 or less 7 Yes 2 Medium 1:100,000,000 to 1:200,000,000 4 No 3 Small Greater than 1:200,000,000 2 No

                                                                                          The first rule, on lines 2-36, is for the smallest scale denominator, corresponding to when the view is \"zoomed in\". The scale rule is set on line 40 such that the rule will apply only where the scale denominator is 100,000,000 or less. Line 7 defines the fill as blue (#0000CC). Note that the fill is kept constant across all rules regardless of the scale denominator. As in the Polygon with default label or Polygon with styled label examples, the rule also contains a <TextSymbolizer> at lines 14-35 for drawing a text label on top of the polygon. Lines 19-22 set the font information to be Arial, 14 pixels, and bold with no italics. The label is centered both horizontally and vertically along the centroid of the polygon on by setting <AnchorPointX> and <AnchorPointY> to both be 0.5 (or 50%) on lines 27-28. Finally, the color of the font is set to white (#FFFFFF) in line 33.

                                                                                          The second rule, on lines 37-50, is for the intermediate scale denominators, corresponding to when the view is \"partially zoomed\". The scale rules on lines 39-40 set the rule such that it will apply to any map with a scale denominator between 100,000,000 and 200,000,000. (The <MinScaleDenominator> is inclusive and the <MaxScaleDenominator> is exclusive, so a zoom level of exactly 200,000,000 would not apply here.) Aside from the scale, there are two differences between this rule and the first: the width of the stroke is set to 4 pixels on line 47 and a <TextSymbolizer> is not present so that no labels will be displayed.

                                                                                          The third rule, on lines 51-63, is for the largest scale denominator, corresponding to when the map is \"zoomed out\". The scale rule is set on line 53 such that the rule will apply to any map with a scale denominator of 200,000,000 or greater. Again, the only differences between this rule and the others are the width of the lines, which is set to 1 pixel on line 60, and the absence of a <TextSymbolizer> so that no labels will be displayed.

                                                                                          The resulting style produces a polygon stroke that gets larger as one zooms in and labels that only display when zoomed in to a sufficient level.

                                                                                          "},{"location":"styling/sld/cookbook/rasters/","title":"Rasters","text":"

                                                                                          Rasters are geographic data displayed in a grid. They are similar to image files such as PNG files, except that instead of each point containing visual information, each point contains geographic information in numerical form. Rasters can be thought of as a georeferenced table of numerical values.

                                                                                          One example of a raster is a Digital Elevation Model (DEM) layer, which has elevation data encoded numerically at each georeferenced data point.

                                                                                          Warning

                                                                                          The code examples shown on this page are not the full SLD code, as they omit the SLD header and footer information for the sake of brevity. Please use the links to download the full SLD for each example.

                                                                                          "},{"location":"styling/sld/cookbook/rasters/#example-raster","title":"Example raster","text":"

                                                                                          The raster layer that is used in the examples below contains elevation data for a fictional world. The data is stored in EPSG:4326 (longitude/latitude) and has a data range from 70 to 256. If rendered in grayscale, where minimum values are colored black and maximum values are colored white, the raster would look like this:

                                                                                          Raster file as rendered in grayscale

                                                                                          Download the raster shapefile

                                                                                          "},{"location":"styling/sld/cookbook/rasters/#sld_cookbook_raster_twocolorgradient","title":"Two-color gradient","text":"

                                                                                          This example shows a two-color style with green at lower elevations and brown at higher elevations.

                                                                                          Two-color gradient

                                                                                          "},{"location":"styling/sld/cookbook/rasters/#code","title":"Code","text":"

                                                                                          View and download the full \"Two-color gradient\" SLD

                                                                                          <FeatureTypeStyle>\n  <Rule>\n    <RasterSymbolizer>\n      <ColorMap>\n        <ColorMapEntry color=\"#008000\" quantity=\"70\" />\n        <ColorMapEntry color=\"#663333\" quantity=\"256\" />\n      </ColorMap>\n    </RasterSymbolizer>\n  </Rule>\n</FeatureTypeStyle>\n
                                                                                          "},{"location":"styling/sld/cookbook/rasters/#details","title":"Details","text":"

                                                                                          There is one <Rule> in one <FeatureTypeStyle> for this example, which is the simplest possible situation. All subsequent examples will share this characteristic. Styling of rasters is done via the <RasterSymbolizer> tag (lines 3-8).

                                                                                          This example creates a smooth gradient between two colors corresponding to two elevation values. The gradient is created via the <ColorMap> on lines 4-7. Each entry in the <ColorMap> represents one entry or anchor in the gradient. Line 5 sets the lower value of 70 via the quantity parameter, which is styled a dark green (#008000). Line 6 sets the upper value of 256 via the quantity parameter again, which is styled a dark brown (#663333). All data values in between these two quantities will be linearly interpolated: a value of 163 (the midpoint between 70 and 256) will be colored as the midpoint between the two colors (in this case approximately #335717, a muddy green).

                                                                                          "},{"location":"styling/sld/cookbook/rasters/#transparent-gradient","title":"Transparent gradient","text":"

                                                                                          This example creates the same two-color gradient as in the Two-color gradient as in the example above but makes the entire layer mostly transparent by setting a 30% opacity.

                                                                                          Transparent gradient

                                                                                          "},{"location":"styling/sld/cookbook/rasters/#code_1","title":"Code","text":"

                                                                                          View and download the full \"Transparent gradient\" SLD

                                                                                          <FeatureTypeStyle>\n  <Rule>\n    <RasterSymbolizer>\n      <Opacity>0.3</Opacity>\n      <ColorMap>\n        <ColorMapEntry color=\"#008000\" quantity=\"70\" />\n        <ColorMapEntry color=\"#663333\" quantity=\"256\" />\n      </ColorMap>\n    </RasterSymbolizer>\n  </Rule>\n</FeatureTypeStyle>\n
                                                                                          "},{"location":"styling/sld/cookbook/rasters/#details_1","title":"Details","text":"

                                                                                          This example is similar to the Two-color gradient example save for the addition of line 4, which sets the opacity of the layer to 0.3 (or 30% opaque). An opacity value of 1 means that the shape is drawn 100% opaque, while an opacity value of 0 means that the shape is rendered as completely transparent. The value of 0.3 means that the raster partially takes on the color and style of whatever is drawn beneath it. Since the background is white in this example, the colors generated from the <ColorMap> look lighter, but were the raster imposed on a dark background the resulting colors would be darker.

                                                                                          "},{"location":"styling/sld/cookbook/rasters/#brightness-and-contrast","title":"Brightness and contrast","text":"

                                                                                          This example normalizes the color output and then increases the brightness by a factor of 2.

                                                                                          Brightness and contrast

                                                                                          "},{"location":"styling/sld/cookbook/rasters/#code_2","title":"Code","text":"

                                                                                          View and download the full \"Brightness and contrast\" SLD

                                                                                          <FeatureTypeStyle>\n  <Rule>\n    <RasterSymbolizer>\n      <ContrastEnhancement>\n        <Normalize />\n        <GammaValue>0.5</GammaValue>\n      </ContrastEnhancement>\n      <ColorMap>\n        <ColorMapEntry color=\"#008000\" quantity=\"70\" />\n        <ColorMapEntry color=\"#663333\" quantity=\"256\" />\n      </ColorMap>\n    </RasterSymbolizer>\n  </Rule>\n</FeatureTypeStyle>\n
                                                                                          "},{"location":"styling/sld/cookbook/rasters/#details_2","title":"Details","text":"

                                                                                          This example is similar to the Two-color gradient, save for the addition of the <ContrastEnhancement> tag on lines 4-7. Line 5 normalizes the output by increasing the contrast to its maximum extent. Line 6 then adjusts the brightness by a factor of 0.5. Since values less than 1 make the output brighter, a value of 0.5 makes the output twice as bright.

                                                                                          As with previous examples, lines 8-11 determine the <ColorMap>, with line 9 setting the lower bound (70) to be colored dark green (#008000) and line 10 setting the upper bound (256) to be colored dark brown (#663333).

                                                                                          "},{"location":"styling/sld/cookbook/rasters/#three-color-gradient","title":"Three-color gradient","text":"

                                                                                          This example creates a three-color gradient in primary colors.

                                                                                          Three-color gradient

                                                                                          "},{"location":"styling/sld/cookbook/rasters/#code_3","title":"Code","text":"

                                                                                          View and download the full \"Three-color gradient\" SLD

                                                                                          <FeatureTypeStyle>\n  <Rule>\n    <RasterSymbolizer>\n      <ColorMap>\n        <ColorMapEntry color=\"#0000FF\" quantity=\"150\" />\n        <ColorMapEntry color=\"#FFFF00\" quantity=\"200\" />\n        <ColorMapEntry color=\"#FF0000\" quantity=\"250\" />\n      </ColorMap>\n    </RasterSymbolizer>\n  </Rule>\n</FeatureTypeStyle>\n
                                                                                          "},{"location":"styling/sld/cookbook/rasters/#details_3","title":"Details","text":"

                                                                                          This example creates a three-color gradient based on a <ColorMap> with three entries on lines 4-8: line 5 specifies the lower bound (150) be styled in blue (#0000FF), line 6 specifies an intermediate point (200) be styled in yellow (#FFFF00), and line 7 specifies the upper bound (250) be styled in red (#FF0000).

                                                                                          Since our data values run between 70 and 256, some data points are not accounted for in this style. Those values below the lowest entry in the color map (the range from 70 to 149) are styled the same color as the lower bound, in this case blue. Values above the upper bound in the color map (the range from 251 to 256) are styled the same color as the upper bound, in this case red.

                                                                                          "},{"location":"styling/sld/cookbook/rasters/#alpha-channel","title":"Alpha channel","text":"

                                                                                          This example creates an \"alpha channel\" effect such that higher values are increasingly transparent.

                                                                                          Alpha channel

                                                                                          "},{"location":"styling/sld/cookbook/rasters/#code_4","title":"Code","text":"

                                                                                          View and download the full \"Alpha channel\" SLD

                                                                                          <FeatureTypeStyle>\n  <Rule>\n    <RasterSymbolizer>\n      <ColorMap>\n        <ColorMapEntry color=\"#008000\" quantity=\"70\" />\n        <ColorMapEntry color=\"#008000\" quantity=\"256\" opacity=\"0\"/>\n      </ColorMap>\n    </RasterSymbolizer>\n  </Rule>\n</FeatureTypeStyle>\n
                                                                                          "},{"location":"styling/sld/cookbook/rasters/#details_4","title":"Details","text":"

                                                                                          An alpha channel is another way of referring to variable transparency. Much like how a gradient maps values to colors, each entry in a <ColorMap> can have a value for opacity (with the default being 1.0 or completely opaque).

                                                                                          In this example, there is a <ColorMap> with two entries: line 5 specifies the lower bound of 70 be colored dark green (#008000), while line 6 specifies the upper bound of 256 also be colored dark green but with an opacity value of 0. This means that values of 256 will be rendered at 0% opacity (entirely transparent). Just like the gradient color, the opacity is also linearly interpolated such that a value of 163 (the midpoint between 70 and 256) is rendered at 50% opacity.

                                                                                          "},{"location":"styling/sld/cookbook/rasters/#discrete-colors","title":"Discrete colors","text":"

                                                                                          This example shows a gradient that is not linearly interpolated but instead has values mapped precisely to one of three specific colors.

                                                                                          Note

                                                                                          This example leverages an SLD extension in GeoServer. Discrete colors are not part of the standard SLD 1.0 specification.

                                                                                          Discrete colors

                                                                                          "},{"location":"styling/sld/cookbook/rasters/#code_5","title":"Code","text":"

                                                                                          View and download the full \"Discrete colors\" SLD

                                                                                          <FeatureTypeStyle>\n  <Rule>\n    <RasterSymbolizer>\n      <ColorMap type=\"intervals\">\n        <ColorMapEntry color=\"#008000\" quantity=\"150\" />\n        <ColorMapEntry color=\"#663333\" quantity=\"256\" />\n      </ColorMap>\n    </RasterSymbolizer>\n  </Rule>\n</FeatureTypeStyle>\n
                                                                                          "},{"location":"styling/sld/cookbook/rasters/#details_5","title":"Details","text":"

                                                                                          Sometimes color bands in discrete steps are more appropriate than a color gradient. The type=\"intervals\" parameter added to the <ColorMap> on line 4 sets the display to output discrete colors instead of a gradient. The values in each entry correspond to the upper bound for the color band such that colors are mapped to values less than the value of one entry but greater than or equal to the next lower entry. For example, line 5 colors all values less than 150 to dark green (#008000) and line 6 colors all values less than 256 but greater than or equal to 150 to dark brown (#663333).

                                                                                          "},{"location":"styling/sld/cookbook/rasters/#many-color-gradient","title":"Many color gradient","text":"

                                                                                          This example shows a gradient interpolated across eight different colors.

                                                                                          Many color gradient

                                                                                          "},{"location":"styling/sld/cookbook/rasters/#code_6","title":"Code","text":"

                                                                                          View and download the full \"Many color gradient\" SLD

                                                                                          <FeatureTypeStyle>\n  <Rule>\n    <RasterSymbolizer>\n      <ColorMap>\n        <ColorMapEntry color=\"#000000\" quantity=\"95\" />\n        <ColorMapEntry color=\"#0000FF\" quantity=\"110\" />\n        <ColorMapEntry color=\"#00FF00\" quantity=\"135\" />\n        <ColorMapEntry color=\"#FF0000\" quantity=\"160\" />\n        <ColorMapEntry color=\"#FF00FF\" quantity=\"185\" />\n        <ColorMapEntry color=\"#FFFF00\" quantity=\"210\" />\n        <ColorMapEntry color=\"#00FFFF\" quantity=\"235\" />\n        <ColorMapEntry color=\"#FFFFFF\" quantity=\"256\" />\n      </ColorMap>\n    </RasterSymbolizer>\n  </Rule>\n</FeatureTypeStyle>\n
                                                                                          "},{"location":"styling/sld/cookbook/rasters/#details_6","title":"Details","text":"

                                                                                          A <ColorMap> can include up to 255 <ColorMapEntry> elements. This example has eight entries (lines 4-13):

                                                                                          Entry number Value Color RGB code 1 95 Black #000000 2 110 Blue #0000FF 3 135 Green #00FF00 4 160 Red #FF0000 5 185 Purple #FF00FF 6 210 Yellow #FFFF00 7 235 Cyan #00FFFF 8 256 White #FFFFFF"},{"location":"styling/sld/extensions/","title":"SLD Extensions in GeoServer","text":"

                                                                                          GeoServer provides a number of vendor-specific extensions to SLD 1.0. Although not portable to other applications, these extensions make styling more powerful and concise and allow for the generation of better-looking maps.

                                                                                          • Geometry transformations in SLD
                                                                                          • Rendering Transformations
                                                                                          • Graphic symbology in GeoServer
                                                                                          • Variable substitution in SLD
                                                                                          • Specifying symbolizer sizes in ground units
                                                                                          • Label Obstacles
                                                                                          • Adding space around graphic fills
                                                                                          • Fills with randomized symbols
                                                                                          • Color compositing and color blending
                                                                                          • Z ordering features within and across feature types and layers
                                                                                          • Rendering Selection
                                                                                          "},{"location":"styling/sld/extensions/geometry-transformations/","title":"Geometry transformations in SLD","text":"

                                                                                          SLD symbolizers may contain an optional <Geometry> element, which allows specifying which geometry attribute is to be rendered. In the common case of a featuretype with a single geometry attribute this element is usually omitted, but it is useful when a featuretype has multiple geometry-valued attributes.

                                                                                          SLD 1.0 requires the <Geometry> content to be a <ogc:PropertyName>. GeoServer extends this to allow a general SLD expression to be used. The expression can contain filter functions that manipulate geometries by transforming them into something different. This facility is called SLD geometry transformations.

                                                                                          GeoServer provides a number of filter functions that can transform geometry. A full list is available in the Filter Function Reference. They can be used to do things such as extracting line vertices or endpoints, offsetting polygons, or buffering geometries.

                                                                                          Geometry transformations are computed in the geometry's original coordinate reference system, before any reprojection and rescaling to the output map is performed. For this reason, transformation parameters must be expressed in the units of the geometry CRS. This must be taken into account when using geometry transformations at different screen scales, since the parameters will not change with scale.

                                                                                          "},{"location":"styling/sld/extensions/geometry-transformations/#examples","title":"Examples","text":"

                                                                                          Let's look at some examples.

                                                                                          "},{"location":"styling/sld/extensions/geometry-transformations/#extracting-vertices","title":"Extracting vertices","text":"

                                                                                          Here is an example that allows one to extract all the vertices of a geometry, and make them visible in a map, using the vertices function:

                                                                                          <PointSymbolizer>\n  <Geometry>\n    <ogc:Function name=\"vertices\">\n       <ogc:PropertyName>the_geom</ogc:PropertyName>\n    </ogc:Function>\n  </Geometry>\n  <Graphic>\n    <Mark>\n      <WellKnownName>square</WellKnownName>\n      <Fill>\n        <CssParameter name=\"fill\">#FF0000</CssParameter>\n      </Fill>\n    </Mark>\n    <Size>6</Size>\n  </Graphic>\n</PointSymbolizer>\n

                                                                                          View the full \"Vertices\" SLD

                                                                                          Applied to the sample tasmania_roads layer this will result in:

                                                                                          Extracting and showing the vertices out of a geometry

                                                                                          "},{"location":"styling/sld/extensions/geometry-transformations/#start-and-end-point","title":"Start and end point","text":"

                                                                                          The startPoint and endPoint functions can be used to extract the start and end point of a line.

                                                                                          ``` {.xml linenos=\" the_geom square 0x00FF00 1.5 8 the_geom circle 0xFF0000 4 \"}

                                                                                          [View the full \"StartEnd\" SLD](artifacts/startend.sld)\n\nApplied to the sample ``tasmania_roads`` layer this will result in:\n\n![](images/startend.png)\n*Extracting start and end point of a line*\n\n### Drop shadow\n\nThe ``offset`` function can be used to create drop shadow effects below polygons. Notice that the offset values reflect the fact that the data used in the example is in a geographic coordinate system.\n\n``` {.xml linenos=\"\"}\n<PolygonSymbolizer>\n  <Geometry>\n     <ogc:Function name=\"offset\">\n        <ogc:PropertyName>the_geom</ogc:PropertyName>\n        <ogc:Literal>0.00004</ogc:Literal>\n        <ogc:Literal>-0.00004</ogc:Literal>\n     </ogc:Function>\n  </Geometry>\n  <Fill>\n    <CssParameter name=\"fill\">#555555</CssParameter>\n  </Fill>\n</PolygonSymbolizer>\n

                                                                                          View the full \"Shadow\" SLD

                                                                                          Applied to the sample tasmania_roads layer this will result in:

                                                                                          Dropping building shadows

                                                                                          "},{"location":"styling/sld/extensions/geometry-transformations/#performance-tips","title":"Performance tips","text":"

                                                                                          GeoServer's filter functions contain a number of set-related or constructive geometric functions, such as buffer, intersection, difference and others. These can be used as geometry transformations, but they be can quite heavy in terms of CPU consumption so it is advisable to use them with care. One strategy is to activate them only at higher zoom levels, so that fewer features are processed.

                                                                                          Buffering can often be visually approximated by using very large strokes together with round line joins and line caps. This avoids incurring the performance cost of a true geometric buffer transformation.

                                                                                          "},{"location":"styling/sld/extensions/geometry-transformations/#adding-new-transformations","title":"Adding new transformations","text":"

                                                                                          Additional filter functions can be developed in Java and then deployed in a JAR file as a GeoServer plugin. A guide is not available at this time, but see the GeoTools main module for examples.

                                                                                          "},{"location":"styling/sld/extensions/label-obstacles/","title":"Label Obstacles","text":"

                                                                                          GeoServer implements an algorithm for label conflict resolution, to prevent labels from overlapping one another. By default this algorithm only considers conflicts with other labels. This can result in labels overlapping other symbolizers, which may produce an undesirable effect.

                                                                                          no-border

                                                                                          GeoServer supports a vendor option called labelObstacle that allows marking a symbolizer as an obstacle. This tells the labeller to avoid rendering labels that overlap it.

                                                                                          Warning

                                                                                          Beware of marking a line or poly symbolizer as a label obstacle. The label conflict resolving routine is based on the bounding box so marking as a label obstacle will result in no label overlapping not only the geometry itself, but its bounding box as well.

                                                                                          <?xml version=\"1.0\" encoding=\"ISO-8859-1\"?>\n<StyledLayerDescriptor version=\"1.0.0\" xmlns=\"http://www.opengis.net/sld\" xmlns:ogc=\"http://www.opengis.net/ogc\"\n  xmlns:xlink=\"http://www.w3.org/1999/xlink\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\">\n  <NamedLayer>\n    <UserStyle>\n\n      <FeatureTypeStyle>\n        <Rule>\n          <PointSymbolizer>\n            <Graphic>\n              <ExternalGraphic>\n                <OnlineResource\n                  xlink:type=\"simple\"\n                  xlink:href=\"smileyface.png\" />\n                <Format>image/png</Format>\n              </ExternalGraphic>\n              <Size>32</Size>\n            </Graphic>\n            <VendorOption name=\"labelObstacle\">true</VendorOption>\n          </PointSymbolizer>\n        </Rule>\n      </FeatureTypeStyle>\n\n    </UserStyle>\n  </NamedLayer>\n</StyledLayerDescriptor>\n

                                                                                          no-border

                                                                                          Applying the obstacle to a regular point style:

                                                                                          <PointSymbolizer>\n  <Graphic>\n    <ExternalGraphic>\n      <OnlineResource\n        xlink:type=\"simple\"\n        xlink:href=\"smileyface.png\" />\n      <Format>image/png</Format>\n    </ExternalGraphic>\n    <Size>32</Size>\n  </Graphic>\n  <VendorOption name=\"labelObstacle\">true</VendorOption>\n</PointSymbolizer>\n

                                                                                          no-border

                                                                                          Applying the obstacle to line/polygon style:

                                                                                          no-border

                                                                                          "},{"location":"styling/sld/extensions/margins/","title":"Adding space around graphic fills","text":"

                                                                                          Starting with GeoServer 2.3.4 it is possible to add white space around symbols used inside graphic fills, effectively allowing to control the density of the symbols in the map.

                                                                                          <PolygonSymbolizer>\n  <Fill>\n    <GraphicFill>\n      <Graphic>\n        <ExternalGraphic>\n          <OnlineResource xlink:type=\"simple\" xlink:href=\"./rockFillSymbol.png\"/>\n          <Format>image/png</Format>\n        </ExternalGraphic>\n      </Graphic>\n    </GraphicFill>\n  </Fill>\n  <VendorOption name=\"graphic-margin\">10</VendorOption>\n</PolygonSymbolizer>\n

                                                                                          The above forces 10 pixels of white space above, below and on either side of the symbol, effectively adding 20 pixels of white space between the symbols in the fill. The graphic-margin can be expressed, just like the CSS margin, in four different ways:

                                                                                          • top,right,bottom,left (one explicit value per margin)
                                                                                          • top,right-left,bottom (three values, with right and left sharing the same value)
                                                                                          • top-bottom,right-left (two values, top and bottom sharing the same value)
                                                                                          • top-right-bottom-left (single value for all four margins)

                                                                                          The ability to specify different margins allows to use more than one symbol in a fill, and synchronize the relative positions of the various symbols to generate a composite fill:

                                                                                          <PolygonSymbolizer>\n  <Fill>\n    <GraphicFill>\n      <Graphic>\n        <ExternalGraphic>\n          <OnlineResource xlink:type=\"simple\" xlink:href=\"./boulderGeometry.png\"/>\n          <Format>image/png</Format>\n        </ExternalGraphic>\n      </Graphic>\n    </GraphicFill>\n  </Fill>\n  <VendorOption name=\"graphic-margin\">35 17 17 35</VendorOption>\n</PolygonSymbolizer>\n<PolygonSymbolizer>\n  <Fill>\n    <GraphicFill>\n      <Graphic>\n        <ExternalGraphic>\n          <OnlineResource xlink:type=\"simple\" xlink:href=\"./roughGrassFillSymbol.png\"/>\n          <Format>image/png</Format>\n        </ExternalGraphic>\n      </Graphic>\n    </GraphicFill>\n  </Fill>\n  <VendorOption name=\"graphic-margin\">16 16 32 32</VendorOption>\n</PolygonSymbolizer>\n

                                                                                          no-border

                                                                                          "},{"location":"styling/sld/extensions/pointsymbols/","title":"Graphic symbology in GeoServer","text":"

                                                                                          Graphic symbology is supported via the SLD <Graphic> element. This element can appear in several contexts in SLD:

                                                                                          • in a PointSymbolizer, to display symbols at points
                                                                                          • in the <Stroke>/<GraphicStroke> element of a LineSymbolizer and PolygonSymbolizer, to display repeated symbols along lines and polygon boundaries.
                                                                                          • in the <Stroke>/<GraphicFill> element of a LineSymbolizer and PolygonSymbolizer, to fill lines and polygon boundaries with tiled symbols.
                                                                                          • in the <Fill>/<GraphicFill> element of a PolygonSymbolizer, to fill polygons with tiled symbols (stippling).
                                                                                          • in a TextSymbolizer to display a graphic behind or instead of text labels (this is a GeoServer extension).

                                                                                          <Graphic> contains either a <Mark> or an <ExternalGraphic> element. Marks are pure vector symbols whose geometry is predefined but with stroke and fill defined in the SLD itself. External Graphics are external files (such as PNG images or SVG graphics) that contain the shape and color information defining how to render a symbol.

                                                                                          In standard SLD the <Mark> and <ExternalGraphic> names are fixed strings. GeoServer extends this by providing dynamic symbolizers, which allow computing symbol names on a per-feature basis by embedding CQL expressions in them.

                                                                                          "},{"location":"styling/sld/extensions/pointsymbols/#marks","title":"Marks","text":"

                                                                                          GeoServer supports the standard SLD <Mark> symbols, a user-expandable set of extended symbols, and also TrueType Font glyphs. The symbol names are specified in the <WellKnownName> element.

                                                                                          See also the PointSymbolizer reference for further details, as well as the examples in the Points Cookbook section.

                                                                                          "},{"location":"styling/sld/extensions/pointsymbols/#standard-symbols","title":"Standard symbols","text":"

                                                                                          The SLD specification mandates the support of the following symbols:

                                                                                          Name Description square A square circle A circle triangle A triangle pointing up star five-pointed star cross A square cross with space around (not suitable for hatch fills) x A square X with space around (not suitable for hatch fills)"},{"location":"styling/sld/extensions/pointsymbols/#shape-symbols","title":"Shape symbols","text":"

                                                                                          The shape symbols set adds extra symbols that are not part of the basic set.

                                                                                          1. To enable ensure that the WMS Settings ****Mark Factory PrecedencehasShapeMarkFactory`` selected.

                                                                                          2. The shape symbols are prefixed by shape://

                                                                                              • Name
                                                                                              • Description
                                                                                              • shape://vertline
                                                                                              • A vertical line (suitable for hatch fills or to make railroad symbols)
                                                                                              • shape://horline
                                                                                              • A horizontal line (suitable for hatch fills)
                                                                                              • shape://slash
                                                                                              • A diagonal line leaning forwards like the \"slash\" keyboard symbol (suitable for diagonal hatches)
                                                                                              • shape://backslash
                                                                                              • Same as shape://slash, but oriented in the opposite direction
                                                                                              • shape://dot
                                                                                              • A very small circle with space around
                                                                                              • shape://plus
                                                                                              • A + symbol, without space around (suitable for cross-hatch fills)
                                                                                              • shape://times
                                                                                              • A \"X\" symbol, without space around (suitable for cross-hatch fills)
                                                                                              • shape://oarrow
                                                                                              • An open arrow symbol (triangle without one side, suitable for placing arrows at the end of lines)
                                                                                              • shape://carrow
                                                                                              • A closed arrow symbol (closed triangle, suitable for placing arrows at the end of lines)
                                                                                          "},{"location":"styling/sld/extensions/pointsymbols/#weather-symbols","title":"Weather Symbols","text":"

                                                                                          The weather symbols are prefixed by the extshape:// protocol in the SLD:

                                                                                          1. To enable ensure that the WMS Settings ****Mark Factory PrecedencehasMeteoMarkFactory`` selected.

                                                                                          2. These symbols are:

                                                                                              • Name
                                                                                              • Description
                                                                                              • Produces
                                                                                              • extshape://triangle
                                                                                              • cold front
                                                                                              • extshape://emicircle
                                                                                              • warm front
                                                                                              • extshape://triangleemicircle
                                                                                              • stationary front
                                                                                          3. You can use extshape:// for a few additional built-in shapes:

                                                                                              • extshape://narrow
                                                                                              • North Arrow
                                                                                              • extshape://sarrow
                                                                                              • South Arrow

                                                                                          More complex symbols like Wind Barbs can be created with the windbarbs:// prefix.

                                                                                          1. To enable ensure that the WMS Settings ****Mark Factory PrecedencehasWindBarbsmFactory`` selected.

                                                                                          2. There are some examples:

                                                                                              • Name
                                                                                              • Description
                                                                                              • windbarbs://default(15)[kts]
                                                                                              • 15 wind intensity with [kts] unit of measure
                                                                                              • windbarbs://default(9)[m/s]?hemisphere=s
                                                                                              • 9 wind intensity with [m/s] unit of measure, in the south hemisphere
                                                                                          "},{"location":"styling/sld/extensions/pointsymbols/#custom-wkt-shapes","title":"Custom WKT Shapes","text":"

                                                                                          Custom shapes can be defined using your own Geometry, to enable use WMS Settings ****Mark Factory Precedenceto selectWKTMarkFactory. Geometry is defined using the same well-known-text format used for CQL_FILTER. .. code-block:: xml <LineSymbolizer> <Stroke> <GraphicStroke> <Graphic> <Mark> <WellKnownName>wkt://MULTILINESTRING((-0.25 -0.25, -0.125 -0.25), (0.125 -0.25, 0.25 -0.25), (-0.25 0.25, -0.125 0.25), (0.125 0.25, 0.25 0.25))</WellKnownName> <Fill> <CssParameter name=\"fill\">#0000ff</CssParameter> </Fill> <Stroke> <CssParameter name=\"stroke\">#0000ff</CssParameter> <CssParameter name=\"stroke-width\">1</CssParameter> </Stroke> </Mark> <Size>6</Size> </Graphic> </GraphicStroke> </Stroke> </LineSymbolizer> Which produces double dashed line: .. image:: images/double-dashed-line.png You can also make use of curves when defining WKT: .. code-block:: xml <LineSymbolizer> <Stroke> <GraphicStroke> <Graphic> <Mark> <WellKnownName>wkt://COMPOUNDCURVE((0 0, 0.25 0), CIRCULARSTRING(0.25 0, 0.5 0.5, 0.75 0), (0.75 0, 1 0))</WellKnownName> <Fill> <CssParameter name=\"fill\">#0000ff</CssParameter> </Fill> <Stroke> <CssParameter name=\"stroke\">#0000ff</CssParameter> <CssParameter name=\"stroke-width\">1</CssParameter> </Stroke> </Mark> <Size>10</Size> </Graphic> </GraphicStroke> </Stroke> </LineSymbolizer> Producing an \"emi circle\" line: .. image:: images/emicircle-line.png Bulk TTF marks ~~~~~~~~~~~~~~ It is possible to create a mark using glyphs from any decorative or symbolic True Type Font, such as Wingdings, WebDings, or the many symbol fonts available on the internet. To enable use WMS Settings ****Mark Factory Precedence to select TTFMarkFactory.

                                                                                          The syntax for specifying this is:

                                                                                          ttf://<fontname>#<hexcode>\n

                                                                                          where fontname is the full name of a TTF font available to GeoServer, and hexcode is the hexadecimal code of the symbol. To get the hex code of a symbol, use the \"Char Map\" utility available in most operating systems (Windows and Linux Gnome both have one).

                                                                                          For example, to use the \"shield\" symbol contained in the WebDings font, the Gnome charmap reports the symbol hex code as shown:

                                                                                          Selecting a symbol hex code in the Gnome char map

                                                                                          The SLD to use the shield glyph as a symbol is:

                                                                                          <PointSymbolizer>\n    <Graphic>\n      <Mark>\n        <WellKnownName>ttf://Webdings#0x0064</WellKnownName>\n        <Fill>\n          <CssParameter name=\"fill\">#AAAAAA</CssParameter>\n        </Fill>\n        <Stroke/>\n      </Mark>\n    <Size>16</Size>\n  </Graphic>\n</PointSymbolizer>\n

                                                                                          This results in the following map display:

                                                                                          Shield symbols rendered on the map

                                                                                          "},{"location":"styling/sld/extensions/pointsymbols/#extending-the-mark-subsystem-using-java","title":"Extending the Mark subsystem using Java","text":"

                                                                                          The Mark subsystem is user-extensible. To do this using Java code, implement the MarkFactory interface and declare the implementation in the META-INF/services/org.geotools.renderer.style.MarkFactory file.

                                                                                          For further information see the Javadoc of the GeoTools MarkFactory, along with the following example code:

                                                                                          • The factory SPI registration file
                                                                                          • The TTFMarkFactory implementation
                                                                                          • The ShapeMarkFactory implementation
                                                                                          "},{"location":"styling/sld/extensions/pointsymbols/#external-graphics","title":"External Graphics","text":"

                                                                                          <ExternalGraphic> is the other way to define point symbology. Unlike marks, external graphics are used as-is, so the specification is somewhat simpler. The element content specifies a graphic <OnlineResource> using a URL or file path, and the graphic <Format> using a MIME type:

                                                                                          <PointSymbolizer>\n    <Graphic>\n       <ExternalGraphic>\n          <OnlineResource xlink:type=\"simple\" xlink:href=\"http://mywebsite.com/pointsymbol.png\" />\n          <Format>image/png</Format>\n       </ExternalGraphic>\n    </Graphic>\n</PointSymbolizer>\n

                                                                                          As with <Mark>, a <Size> element can be optionally specified. When using images as graphic symbols it is better to avoid resizing, as that may blur their appearance. Use images at their native resolution by omitting the <Size> element. In contrast, for SVG graphics specifying a <Size> is recommended. SVG files are a vector-based format describing both shape and color, so they scale cleanly to any size.

                                                                                          If the path of the symbol file is relative, the file is looked for under $GEOSERVER_DATA_DIR/styles. For example:

                                                                                          <PointSymbolizer>\n  <Graphic>\n    <ExternalGraphic>\n      <OnlineResource xlink:type=\"simple\" xlink:href=\"burg02.svg\" />\n      <Format>image/svg+xml</Format>\n    </ExternalGraphic>\n    <Size>20</Size>\n  </Graphic>\n</PointSymbolizer>\n

                                                                                          In this example an SVG graphic is being used, so the size is specified explicitly.

                                                                                          "},{"location":"styling/sld/extensions/pointsymbols/#svg-parameters","title":"SVG Parameters","text":"

                                                                                          GeoServer can handle SVG images in which parts of the SVG-attributes are named parameters, as outlined the SVG Parameters 1.0 specification. This capability is also supported by QGIS.

                                                                                          SVG Parameters are represented in a file like: poi_peak.svg as:

                                                                                          <svg enable-background=\"new 0 0 580 580\" height=\"580\" viewBox=\"0 0 580 580\" width=\"580\" xmlns=\"http://www.w3.org/2000/svg\">\n<path d=\"m290.565 67.281l-255.498 442.534-1.087 1.885 511.229.393 2.18.002z\" fill=\"param(fill)\" \n fill-opacity=\"param(fill-opacity)\" stroke=\"param(outline)\" stroke-opacity=\"param(outline-opacity)\" stroke-width=\"param(outline-width)\"/>\n</svg>\n

                                                                                          The 'param'-constructs mean that you can define the parameters: fill, fill-opacity, outline, outline-opacity and outline-width as part of an SVG URL reference, where a reference to this image with red fill would be: poi_peak.svg?fill=#FF0000.

                                                                                          Note: When editng SVG files (e.g. in Inkscape) save using 'simple svg' format.

                                                                                          Default behaviour:

                                                                                          • OnlineResource href URI without any parameters.

                                                                                            <se:OnlineResource xlink:href=\"poi_peak.svg\" xlink:type=\"simple\"/>\n
                                                                                          • Displays poi_peak.svg with the default black fill.

                                                                                            SVG image with default black fill

                                                                                          Using #ff000 red parameter:

                                                                                          • OnlineResource href URI with parameter:

                                                                                            <se:OnlineResource xlink:href=\"poi_peak.svg?fill=#ff0000\" xlink:type=\"simple\"/>\n
                                                                                          • Displays poi_peak.svg with supplied red fill.

                                                                                            SVG image with fill provided by parameter

                                                                                          To define several parameters, the query-parameters should be url-encoded.

                                                                                          • A green peak with 25% opacity: ?fill=#00ff00&opacity=0.25, requires encoding both the '#' ( %23 ) and the '&' ( &amp; ) signs:

                                                                                            <se:OnlineResource xlink:href=\"poi_peak.svg?fill=%2300ff00&amp;opacity=0.25\" xlink:type=\"simple\"/>\n
                                                                                          • Displayed with white fill, red outlined peaks:

                                                                                            SVG image with fill and outline provided by parameters

                                                                                          Parameters names are defined by the SVG file:

                                                                                          • The parameter 'stroke' above is called 'outline' in the original svg file:

                                                                                            stroke=\"param(outline)\"\n
                                                                                          • OnlineResource href URI referencing parameters fill, outline and outline-width:

                                                                                            <se:OnlineResource xlink:href=\"poi_peak.svg?fill=%23ffffff&amp;outline=%23ff0000&amp;outline-width=5\" xlink:type=\"simple\"/>\n
                                                                                          • Displayed as:

                                                                                            SVG image with fill

                                                                                          The use of SVG parameters can be combinded with dynamic symbolizers (covered below) to supply SVG parameter values based on feature attribute data and expressions.

                                                                                          • OnlineResource href URI referencing SVG Parameter with dynamic CQL expression:

                                                                                            <se:OnlineResource xlink:href=\"poi_peak.svg?fill=${COLOR}\" xlink:type=\"simple\"/>\n
                                                                                          • Display depends on the feature attribute COLOR.

                                                                                          "},{"location":"styling/sld/extensions/pointsymbols/#bulk-wkt-shapes","title":"Bulk WKT Shapes","text":"

                                                                                          It is possible to create a symbol set of your own custom marks using a property file.

                                                                                          Here is an example.properties:

                                                                                          zig=LINESTRING(0.0 0.25, 0.25 0.25, 0.5 0.75, 0.75 0.25, 1.00 0.25)\nblock=POLYGON((0 0, 1 0, 1 1, 0 1, 0 0))\n

                                                                                          The SLD to use the symbols defined in example.properties is:

                                                                                          <PointSymbolizer>\n  <Graphic>\n    <ExternalGraphic>\n      <OnlineResource \n        xlink:type=\"simple\"\n        xlink:href=\"example.properties#zig\" />\n      <Format>wkt</Format>\n    </ExternalGraphic>\n    <Size>20</Size>\n  </Graphic>\n</PointSymbolizer>\n
                                                                                          "},{"location":"styling/sld/extensions/pointsymbols/#symbol-positioning","title":"Symbol Positioning","text":"

                                                                                          Graphic symbols are rendered so that the center of the graphic extent lies on the placement point (or points, in the case of repeated or tiled graphics). If it is desired to have a graphic offset from a point (such as a symbol which acts as a pointer) it is necessary to offset the visible portion of the graphic within the overall extent. For images this can be accomplished by extending the image with transparent pixels. For SVG graphics this can be done by surrounding the shape with an invisible rectangle with the desired relative position.

                                                                                          "},{"location":"styling/sld/extensions/pointsymbols/#dynamic-symbolizers","title":"Dynamic symbolizers","text":"

                                                                                          In standard SLD, the Mark/WellKnowName element and the ExternalGraphic/OnlineResource/@xlink:href attribute are fixed strings. This means they have the same value for all rendered features. When the symbols to be displayed vary depending on feature attributes this restriction leads to very verbose styling, as a separate Rule and Symbolizer must be used for each different symbol.

                                                                                          GeoServer improves this by allowing CQL expressions<filter_ecql_reference> to be embedded inside the content of both WellKnownName and OnlineResource/@xlink:href. When the names of the symbols can be derived from the feature attribute values, this provides much more compact styling. CQL expressions can be embedded in a <WellKnownName> content string or an <OnlineResource> xlink:href attribute by using the syntax:

                                                                                          ${<cql expression>}\n

                                                                                          Note

                                                                                          Currently xlink:href strings must be valid URLs before expression expansion is performed. This means that the URL cannot be completely provided by an expression. The xlink:href string must explicitly include at least the prefix http://

                                                                                          The simplest form of expression is a single attribute name, such as ${STATE_ABBR}. For example, suppose we want to display the flags of the US states using symbols whose file names match the state name. The following style specifies the flag symbols using a single rule:

                                                                                          <ExternalGraphic>\n   <OnlineResource xlink:type=\"simple\" \n                   xlink:href=\"http://mysite.com/tn_${STATE_ABBR}.jpg\"/>\n   <Format>image/jpeg</Format>\n</ExternalGraphic>\n

                                                                                          If manipulation of the attribute values is required a full CQL expression can be specified. For example, if the values in the STATE_ABBR attribute are uppercase but the URL requires a lowercase name, the CQL strToLowerCase function can be used:

                                                                                          <ExternalGraphic>\n   <OnlineResource xlink:type=\"simple\"\n            xlink:href=\"http://mysite.com/tn_${strToLowerCase(STATE_ABBR)}.jpg\" />\n   <Format>image/jpeg</Format>\n</ExternalGraphic>\n
                                                                                          "},{"location":"styling/sld/extensions/randomized/","title":"Fills with randomized symbols","text":"

                                                                                          Starting with GeoServer 2.4.2 it is possible to generate fills by randomly repeating a symbol in the polygons to be filled. Or, to be more precise, generate the usual texture fill by repeating over and over a tile, whose contents is the random repetition of a fill. The random distribution is stable, so it will be the same across calls and tiles, and it's controlled by the seed used to generate the distribution.

                                                                                          The random fill is generated by specifying a GraphicFill with a Mark or ExternalGraphic, and then adding vendor options to control how the symbol is randomly repeated. Here is a table with options, default values, and possible values:

                                                                                          Option Default value Description random none Activates random distribution of symbol. Possible values are none, free, grid. none disables random distribution, free generates a completely random distribution, grid will generate a regular grid of positions, and only randomizes the position of the symbol around the cell centers, providing a more even distribution in space random-tile-size 256 Size the texture fill tile that will contain the randomly distributed symbols random-rotation none Activates random symbol rotation. Possible values are none (no rotation) or free random-symbol-count 16 The number of symbols in the tile. The number of symbols actually painted can be lower, as the distribution will ensure no two symbols overlap with each other. random-seed 0 The \"seed\" used to generate the random distribution. Changing this value will result in a different symbol distribution

                                                                                          Here is an example:

                                                                                          <sld:PolygonSymbolizer>\n <sld:Fill>\n   <sld:GraphicFill>\n     <sld:Graphic>\n       <sld:Mark>\n         <sld:WellKnownName>shape://slash</sld:WellKnownName>\n         <sld:Stroke>\n           <sld:CssParameter name=\"stroke\">#0000ff</sld:CssParameter>\n           <sld:CssParameter name=\"stroke-linecap\">round</sld:CssParameter>\n           <sld:CssParameter name=\"stroke-width\">4</sld:CssParameter>\n         </sld:Stroke>\n       </sld:Mark>\n       <sld:Size>8</sld:Size>\n     </sld:Graphic>\n   </sld:GraphicFill>\n </sld:Fill>\n <sld:VendorOption name=\"random-seed\">5</sld:VendorOption>\n <sld:VendorOption name=\"random\">grid</sld:VendorOption>\n <sld:VendorOption name=\"random-tile-size\">100</sld:VendorOption>\n <sld:VendorOption name=\"random-rotation\">free</sld:VendorOption>\n <sld:VendorOption name=\"random-symbol-count\">50</sld:VendorOption>\n</sld:PolygonSymbolizer>\n

                                                                                          Random distribution of a diagonal line

                                                                                          Randomized distributions can also be used for thematic mapping, for example, here is the SLD for a version of topp:states that displays the number of inhabitant\u00ecs varying the density of a random point distribution:

                                                                                          <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<sld:UserStyle xmlns=\"http://www.opengis.net/sld\" xmlns:sld=\"http://www.opengis.net/sld\" xmlns:ogc=\"http://www.opengis.net/ogc\" xmlns:gml=\"http://www.opengis.net/gml\">\n  <sld:Name>Default Styler</sld:Name>\n  <sld:FeatureTypeStyle>\n    <sld:Name>name</sld:Name>\n    <sld:Rule>\n      <ogc:Filter>\n        <ogc:And>\n          <ogc:Not>\n            <ogc:PropertyIsLessThan>\n              <ogc:PropertyName>PERSONS</ogc:PropertyName>\n              <ogc:Literal>2000000</ogc:Literal>\n            </ogc:PropertyIsLessThan>\n          </ogc:Not>\n          <ogc:Not>\n            <ogc:PropertyIsGreaterThanOrEqualTo>\n              <ogc:PropertyName>PERSONS</ogc:PropertyName>\n              <ogc:Literal>4000000</ogc:Literal>\n            </ogc:PropertyIsGreaterThanOrEqualTo>\n          </ogc:Not>\n        </ogc:And>\n      </ogc:Filter>\n      <sld:PolygonSymbolizer>\n        <sld:Fill>\n          <sld:GraphicFill>\n            <sld:Graphic>\n              <sld:Mark>\n                <sld:WellKnownName>circle</sld:WellKnownName>\n                <sld:Fill>\n                  <sld:CssParameter name=\"fill\">#a9a9a9</sld:CssParameter>\n                </sld:Fill>\n              </sld:Mark>\n              <sld:Size>2</sld:Size>\n            </sld:Graphic>\n          </sld:GraphicFill>\n        </sld:Fill>\n        <sld:VendorOption name=\"random\">grid</sld:VendorOption>\n        <sld:VendorOption name=\"random-tile-size\">100</sld:VendorOption>\n        <sld:VendorOption name=\"random-symbol-count\">150</sld:VendorOption>\n      </sld:PolygonSymbolizer>\n      <sld:LineSymbolizer>\n        <sld:Stroke/>\n      </sld:LineSymbolizer>\n    </sld:Rule>\n    <sld:Rule>\n      <ogc:Filter>\n        <ogc:PropertyIsLessThan>\n          <ogc:PropertyName>PERSONS</ogc:PropertyName>\n          <ogc:Literal>2000000</ogc:Literal>\n        </ogc:PropertyIsLessThan>\n      </ogc:Filter>\n      <sld:PolygonSymbolizer>\n        <sld:Fill>\n          <sld:GraphicFill>\n            <sld:Graphic>\n              <sld:Mark>\n                <sld:WellKnownName>circle</sld:WellKnownName>\n                <sld:Fill>\n                  <sld:CssParameter name=\"fill\">#a9a9a9</sld:CssParameter>\n                </sld:Fill>\n              </sld:Mark>\n              <sld:Size>2</sld:Size>\n            </sld:Graphic>\n          </sld:GraphicFill>\n        </sld:Fill>\n        <sld:VendorOption name=\"random\">grid</sld:VendorOption>\n        <sld:VendorOption name=\"random-tile-size\">100</sld:VendorOption>\n        <sld:VendorOption name=\"random-symbol-count\">50</sld:VendorOption>\n      </sld:PolygonSymbolizer>\n      <sld:LineSymbolizer>\n        <sld:Stroke/>\n      </sld:LineSymbolizer>\n    </sld:Rule>\n    <sld:Rule>\n      <ogc:Filter>\n        <ogc:PropertyIsGreaterThanOrEqualTo>\n          <ogc:PropertyName>PERSONS</ogc:PropertyName>\n          <ogc:Literal>4000000</ogc:Literal>\n        </ogc:PropertyIsGreaterThanOrEqualTo>\n      </ogc:Filter>\n      <sld:PolygonSymbolizer>\n        <sld:Fill>\n          <sld:GraphicFill>\n            <sld:Graphic>\n              <sld:Mark>\n                <sld:WellKnownName>circle</sld:WellKnownName>\n                <sld:Fill>\n                  <sld:CssParameter name=\"fill\">#a9a9a9</sld:CssParameter>\n                </sld:Fill>\n              </sld:Mark>\n              <sld:Size>2</sld:Size>\n            </sld:Graphic>\n          </sld:GraphicFill>\n        </sld:Fill>\n        <sld:VendorOption name=\"random\">grid</sld:VendorOption>\n        <sld:VendorOption name=\"random-tile-size\">100</sld:VendorOption>\n        <sld:VendorOption name=\"random-symbol-count\">500</sld:VendorOption>\n      </sld:PolygonSymbolizer>\n      <sld:LineSymbolizer>\n        <sld:Stroke/>\n      </sld:LineSymbolizer>\n    </sld:Rule>\n  </sld:FeatureTypeStyle>\n</sld:UserStyle>\n

                                                                                          Thematic map via point density approach

                                                                                          "},{"location":"styling/sld/extensions/rendering-selection/","title":"Rendering Selection","text":"

                                                                                          GeoServer provides a VendorOption to define whether a particular element Rule, FeatureTypeStyle or Symbolizer should be applied to a getLegendGraphic output or to a getMap output.

                                                                                          This allows to generate legends from the SLD that can be better looking and more expressive, without the underlying complexity of the actual rendered style. Other systems have a dedicated language to build legends instead. The advantage of using the same language is that dynamic behaviors, like rule removal based on the area being rendered, can be easily retained.

                                                                                          The vendor option is named inclusion, e.g.:

                                                                                          • legendOnly
                                                                                          • mapOnly

                                                                                          Valid values are:

                                                                                          • legendOnly the element will be skipped when applying the style to the data to render map.
                                                                                          • mapOnly the element will be skipped when applying the style to the data to render legend.
                                                                                          • normal will have the same effect then omitting the VendorOption: the SLD element will be used for both map and legend (same effect as not specifying the vendor option).

                                                                                          Take as an example the following style: for each Rule two symbolizers are defined one that will be skipped when rendering the legend and one that will be skipped when rendering the map and loads the legend icon from an external svg file.

                                                                                          <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<StyledLayerDescriptor xmlns=\"http://www.opengis.net/sld\" xmlns:ogc=\"http://www.opengis.net/ogc\" xmlns:xlink=\"http://www.w3.org/1999/xlink\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" version=\"1.0.0\" xsi:schemaLocation=\"http://www.opengis.net/sld http://schemas.opengis.net/sld/1.0.0/StyledLayerDescriptor.xsd\">\n  <NamedLayer>\n     <Name>Style example</Name>\n     <UserStyle>\n        <FeatureTypeStyle>\n           <Rule>\n              <ogc:Filter>\n                 <ogc:PropertyIsLessThan>\n                    <ogc:PropertyName>numericValue</ogc:PropertyName>\n                    <ogc:Literal>90</ogc:Literal>\n                 </ogc:PropertyIsLessThan>\n              </ogc:Filter>\n              <PointSymbolizer>\n                 <Graphic>\n                    <Mark>\n                       <WellKnownName>circle</WellKnownName>\n                       <Fill>\n                          <CssParameter name=\"fill\">0xFF0000</CssParameter>\n                       </Fill>\n                    </Mark>\n                    <Size>32</Size>\n                 </Graphic>\n                 <VendorOption name=\"inclusion\">mapOnly</VendorOption>\n              </PointSymbolizer>\n              <PointSymbolizer>\n                 <Graphic>\n                    <ExternalGraphic>\n                       <OnlineResource xlink:type=\"simple\" xlink:href=\"my-custom-legend-icon1.svg\" />\n                       <Format>image/svg+xml</Format>\n                    </ExternalGraphic>\n                    <Size>20</Size>\n                 </Graphic>\n                 <VendorOption name=\"inclusion\">legendOnly</VendorOption>\n              </PointSymbolizer>\n           </Rule>\n           <Rule>\n              <ogc:Filter>\n                 <ogc:And>\n                    <ogc:PropertyIsGreaterThanOrEqualTo>\n                       <ogc:PropertyName>numericValue</ogc:PropertyName>\n                       <ogc:Literal>90</ogc:Literal>\n                    </ogc:PropertyIsGreaterThanOrEqualTo>\n                    <ogc:PropertyIsLessThan>\n                       <ogc:PropertyName>numericValue</ogc:PropertyName>\n                       <ogc:Literal>180</ogc:Literal>\n                    </ogc:PropertyIsLessThan>\n                 </ogc:And>\n              </ogc:Filter>\n              <PointSymbolizer>\n                 <Graphic>\n                    <Mark>\n                       <WellKnownName>circle</WellKnownName>\n                       <Fill>\n                          <CssParameter name=\"fill\">#6495ED</CssParameter>\n                       </Fill>\n                    </Mark>\n                    <Size>32</Size>\n                 </Graphic>\n                 <VendorOption name=\"inclusion\">mapOnly</VendorOption>\n              </PointSymbolizer>\n              <PointSymbolizer>\n                 <Graphic>\n                    <ExternalGraphic>\n                       <OnlineResource xlink:type=\"simple\" xlink:href=\"my-custom-legend-icon2.svg\" />\n                       <Format>image/svg+xml</Format>\n                    </ExternalGraphic>\n                    <Size>20</Size>\n                 </Graphic>\n                 <VendorOption name=\"inclusion\">legendOnly</VendorOption>\n              </PointSymbolizer>\n           </Rule>\n        </FeatureTypeStyle>\n     </UserStyle>\n  </NamedLayer>\n</StyledLayerDescriptor>\n

                                                                                          The same result could have been obtained by defining each rule two time each one with a single symbolizer, and defining the vendor options at the rule level.

                                                                                          <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<StyledLayerDescriptor xmlns=\"http://www.opengis.net/sld\" xmlns:ogc=\"http://www.opengis.net/ogc\" xmlns:xlink=\"http://www.w3.org/1999/xlink\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" version=\"1.0.0\" xsi:schemaLocation=\"http://www.opengis.net/sld http://schemas.opengis.net/sld/1.0.0/StyledLayerDescriptor.xsd\">\n <NamedLayer>\n    <Name>Style example</Name>\n    <UserStyle>\n       <FeatureTypeStyle>\n          <Rule>\n             <ogc:Filter>\n                <ogc:PropertyIsLessThan>\n                   <ogc:PropertyName>numericValue</ogc:PropertyName>\n                   <ogc:Literal>90</ogc:Literal>\n                </ogc:PropertyIsLessThan>\n             </ogc:Filter>\n             <PointSymbolizer>\n                <Graphic>\n                   <Mark>\n                      <WellKnownName>circle</WellKnownName>\n                      <Fill>\n                         <CssParameter name=\"fill\">0xFF0000</CssParameter>\n                      </Fill>\n                   </Mark>\n                   <Size>32</Size>\n                </Graphic>\n             </PointSymbolizer>\n             <VendorOption name=\"inclusion\">mapOnly</VendorOption>\n          </Rule>\n          <Rule>\n             <ogc:Filter>\n                <ogc:And>\n                   <ogc:PropertyIsGreaterThanOrEqualTo>\n                      <ogc:PropertyName>numericValue</ogc:PropertyName>\n                      <ogc:Literal>90</ogc:Literal>\n                   </ogc:PropertyIsGreaterThanOrEqualTo>\n                   <ogc:PropertyIsLessThan>\n                      <ogc:PropertyName>numericValue</ogc:PropertyName>\n                      <ogc:Literal>180</ogc:Literal>\n                   </ogc:PropertyIsLessThan>\n                </ogc:And>\n             </ogc:Filter>\n             <PointSymbolizer>\n                <Graphic>\n                   <Mark>\n                      <WellKnownName>circle</WellKnownName>\n                      <Fill>\n                         <CssParameter name=\"fill\">#6495ED</CssParameter>\n                      </Fill>\n                   </Mark>\n                   <Size>32</Size>\n                </Graphic>\n                <VendorOption name=\"inclusion\">mapOnly</VendorOption>\n             </PointSymbolizer>\n          </Rule>\n          <Rule>\n             <ogc:Filter>\n                <ogc:PropertyIsLessThan>\n                   <ogc:PropertyName>numericValue</ogc:PropertyName>\n                   <ogc:Literal>90</ogc:Literal>\n                </ogc:PropertyIsLessThan>\n             </ogc:Filter>\n             <PointSymbolizer>\n                <Graphic>\n                   <ExternalGraphic>\n                      <OnlineResource xlink:type=\"simple\" xlink:href=\"my-custom-legend-icon1.svg\" />\n                      <Format>image/svg+xml</Format>\n                   </ExternalGraphic>\n                   <Size>20</Size>\n                </Graphic>\n                <VendorOption name=\"inclusion\">legendOnly</VendorOption>\n             </PointSymbolizer>\n          </Rule>\n          <Rule>\n             <ogc:Filter>\n                <ogc:And>\n                   <ogc:PropertyIsGreaterThanOrEqualTo>\n                      <ogc:PropertyName>numericValue</ogc:PropertyName>\n                      <ogc:Literal>90</ogc:Literal>\n                   </ogc:PropertyIsGreaterThanOrEqualTo>\n                   <ogc:PropertyIsLessThan>\n                      <ogc:PropertyName>numericValue</ogc:PropertyName>\n                      <ogc:Literal>180</ogc:Literal>\n                   </ogc:PropertyIsLessThan>\n                </ogc:And>\n             </ogc:Filter>\n             <PointSymbolizer>\n                <Graphic>\n                   <ExternalGraphic>\n                      <OnlineResource xlink:type=\"simple\" xlink:href=\"my-custom-legend-icon2.svg\" />\n                      <Format>image/svg+xml</Format>\n                   </ExternalGraphic>\n                   <Size>20</Size>\n                </Graphic>\n                <VendorOption name=\"inclusion\">legendOnly</VendorOption>\n             </PointSymbolizer>\n          </Rule>\n       </FeatureTypeStyle>\n    </UserStyle>\n </NamedLayer>\n</StyledLayerDescriptor>\n

                                                                                          A third way to obtain the same result could be to define vendor options at the FeatureTypeStyle level.

                                                                                          <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<StyledLayerDescriptor xmlns=\"http://www.opengis.net/sld\" xmlns:ogc=\"http://www.opengis.net/ogc\" xmlns:xlink=\"http://www.w3.org/1999/xlink\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" version=\"1.0.0\" xsi:schemaLocation=\"http://www.opengis.net/sld http://schemas.opengis.net/sld/1.0.0/StyledLayerDescriptor.xsd\">\n<NamedLayer>\n   <Name>Style example</Name>\n   <UserStyle>\n   <FeatureTypeStyle>\n         <Rule>\n            <ogc:Filter>\n               <ogc:PropertyIsLessThan>\n                  <ogc:PropertyName>numericValue</ogc:PropertyName>\n                  <ogc:Literal>90</ogc:Literal>\n               </ogc:PropertyIsLessThan>\n            </ogc:Filter>\n            <PointSymbolizer>\n               <Graphic>\n                  <Mark>\n                     <WellKnownName>circle</WellKnownName>\n                     <Fill>\n                        <CssParameter name=\"fill\">0xFF0000</CssParameter>\n                     </Fill>\n                  </Mark>\n                  <Size>32</Size>\n               </Graphic>\n            </PointSymbolizer>\n         </Rule>\n         <Rule>\n            <ogc:Filter>\n               <ogc:And>\n                  <ogc:PropertyIsGreaterThanOrEqualTo>\n                     <ogc:PropertyName>numericValue</ogc:PropertyName>\n                     <ogc:Literal>90</ogc:Literal>\n                  </ogc:PropertyIsGreaterThanOrEqualTo>\n                  <ogc:PropertyIsLessThan>\n                     <ogc:PropertyName>numericValue</ogc:PropertyName>\n                     <ogc:Literal>180</ogc:Literal>\n                  </ogc:PropertyIsLessThan>\n               </ogc:And>\n            </ogc:Filter>\n            <PointSymbolizer>\n               <Graphic>\n                  <Mark>\n                     <WellKnownName>circle</WellKnownName>\n                     <Fill>\n                        <CssParameter name=\"fill\">#6495ED</CssParameter>\n                     </Fill>\n                  </Mark>\n                  <Size>32</Size>\n               </Graphic>\n            </PointSymbolizer>\n         </Rule>\n         <VendorOption name=\"inclusion\">mapOnly</VendorOption>\n      </FeatureTypeStyle>\n      <FeatureTypeStyle>\n         <Rule>\n            <ogc:Filter>\n               <ogc:PropertyIsLessThan>\n                  <ogc:PropertyName>numericValue</ogc:PropertyName>\n                  <ogc:Literal>90</ogc:Literal>\n               </ogc:PropertyIsLessThan>\n            </ogc:Filter>\n            <PointSymbolizer>\n               <Graphic>\n                  <ExternalGraphic>\n                     <OnlineResource xlink:type=\"simple\" xlink:href=\"my-custom-legend-icon1.svg\" />\n                     <Format>image/svg+xml</Format>\n                  </ExternalGraphic>\n                  <Size>20</Size>\n               </Graphic>\n            </PointSymbolizer>\n         </Rule>\n         <Rule>\n            <ogc:Filter>\n               <ogc:And>\n                  <ogc:PropertyIsGreaterThanOrEqualTo>\n                     <ogc:PropertyName>numericValue</ogc:PropertyName>\n                     <ogc:Literal>90</ogc:Literal>\n                  </ogc:PropertyIsGreaterThanOrEqualTo>\n                  <ogc:PropertyIsLessThan>\n                     <ogc:PropertyName>numericValue</ogc:PropertyName>\n                     <ogc:Literal>180</ogc:Literal>\n                  </ogc:PropertyIsLessThan>\n               </ogc:And>\n            </ogc:Filter>\n            <PointSymbolizer>\n               <Graphic>\n                  <ExternalGraphic>\n                     <OnlineResource xlink:type=\"simple\" xlink:href=\"my-custom-legend-icon2.svg\" />\n                     <Format>image/svg+xml</Format>\n                  </ExternalGraphic>\n                  <Size>20</Size>\n               </Graphic>\n            </PointSymbolizer>\n         </Rule>\n         <VendorOption name=\"inclusion\">legendOnly</VendorOption>\n      </FeatureTypeStyle>\n   </UserStyle>\n</NamedLayer>\n</StyledLayerDescriptor>\n
                                                                                          "},{"location":"styling/sld/extensions/rendering-transform/","title":"Rendering Transformations","text":"

                                                                                          Rendering Transformations allow processing to be carried out on datasets within the GeoServer rendering pipeline. A typical transformation computes a derived or aggregated result from the input data, allowing various useful visualization effects to be obtained. Transformations may transform data from one format into another (i.e vector to raster or vice-versa), to provide an appropriate format for display.

                                                                                          The following table lists examples of various kinds of rendering transformations available in GeoServer:

                                                                                          Type Examples Raster-to-Vector Contour extracts contours from a DEM raster. RasterAsPointCollections extracts a vector field from a multi-band raster Vector-to-Raster BarnesSurfaceInterpolation computes a surface from scattered data points. Heatmap computes a heatmap surface from weighted data points. Vector-to-Vector PointStacker aggregates dense point data into clusters.

                                                                                          Rendering transformations are invoked within SLD styles. Parameters may be supplied to control the appearance of the output. The rendered output for the layer is produced by applying the styling rules and symbolizers in the SLD to the result of transformation.

                                                                                          Rendering transformations are implemented using the same mechanism as Process Cookbook. They can thus also be executed via the WPS protocol, if required. Conversely, any WPS process can be executed as a transformation, as long as the input and output are appropriate for use within an SLD.

                                                                                          This section is a general guide to rendering transformation usage in GeoServer. For details of input, parameters, and output for any particular rendering transformation, refer to its own documentation.

                                                                                          "},{"location":"styling/sld/extensions/rendering-transform/#installation","title":"Installation","text":"

                                                                                          Using Rendering Transformations requires the WPS extension to be installed. See Installing the WPS extension.

                                                                                          Note

                                                                                          The WPS service does not need to be enabled to use Rendering Transformations. To avoid unwanted consumption of server resources it may be desirable to disable the WPS service if it is not being used directly.

                                                                                          "},{"location":"styling/sld/extensions/rendering-transform/#usage","title":"Usage","text":"

                                                                                          Rendering Transformations are invoked by adding the <Transformation> element to a <FeatureTypeStyle> element in an SLD document. This element specifies the name of the transformation process, and usually includes parameter values controlling the operation of the transformation.

                                                                                          The <Transformation> element syntax leverages the OGC Filter function syntax. The content of the element is a <ogc:Function> with the name of the rendering transformation process. Transformation processes may accept some number of parameters, which may be either required (in which case they must be specified), or optional (in which case they may be omitted if the default value is acceptable). Parameters are supplied as name/value pairs. Each parameter's name and value are supplied via another function <ogc:Function name=\"parameter\">. The first argument to this function is an <ogc:Literal> containing the name of the parameter. The optional following arguments provide the value for the parameter (if any). Some parameters accept only a single value, while others may accept a list of values. As with any filter function argument, values may be supplied in several ways:

                                                                                          • As a literal value
                                                                                          • As a computed expression
                                                                                          • As an SLD environment variable, whose actual value is supplied in the WMS request (see Variable substitution in SLD).
                                                                                          • As a predefined SLD environment variable (which allows obtaining values for the current request such as output image width and height).

                                                                                          The order of the supplied parameters is not significant.

                                                                                          Most rendering transformations take as input a dataset to be transformed. This is supplied via a special named parameter which does not have a value specified. The name of the parameter is determined by the particular transformation being used. When the transformation is executed, the input dataset is passed to it via this parameter.

                                                                                          The input dataset is determined by the same query mechanism as used for all WMS requests, and can thus be filtered in the request if required.

                                                                                          In rendering transformations which take as input a featuretype (vector dataset) and convert it to a raster dataset, in order to pass validation the SLD needs to mention the geometry attribute of the input dataset (even though it is not used). This is done by specifying the attribute name in the symbolizer <Geometry> element.

                                                                                          The output of the rendering transformation is styled using symbolizers appropriate to its format: PointSymbolizer, LineSymbolizer, PolygonSymbolizer, and TextSymbolizer for vector data, and RasterSymbolizer for raster coverage data.

                                                                                          If it is desired to display the input dataset in its original form, or transformed in another way, there are two options:

                                                                                          • Another <FeatureTypeStyle> can be used in the same SLD
                                                                                          • Another SLD can be created, and the layer displayed twice using the different SLDs
                                                                                          "},{"location":"styling/sld/extensions/rendering-transform/#notes","title":"Notes","text":"
                                                                                          • Rendering transformations may not work correctly in tiled mode, unless they have been specifically written to accommodate it.
                                                                                          "},{"location":"styling/sld/extensions/rendering-transform/#examples","title":"Examples","text":""},{"location":"styling/sld/extensions/rendering-transform/#contour-extraction","title":"Contour extraction","text":"

                                                                                          ras:Contour is a Raster-to-Vector rendering transformation which extracts contour lines at specified levels from a raster DEM. The following SLD invokes the transformation and styles the contours as black lines.

                                                                                          <?xml version=\"1.0\" encoding=\"ISO-8859-1\"?>\n<StyledLayerDescriptor version=\"1.0.0\" \n  xsi:schemaLocation=\"http://www.opengis.net/sld StyledLayerDescriptor.xsd\" \n  xmlns=\"http://www.opengis.net/sld\" \n  xmlns:ogc=\"http://www.opengis.net/ogc\" \n  xmlns:xlink=\"http://www.w3.org/1999/xlink\" \n  xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\">\n  <NamedLayer>\n    <Name>contour_dem</Name>\n    <UserStyle>\n      <Title>Contour DEM</Title>\n      <Abstract>Extracts contours from DEM</Abstract>\n      <FeatureTypeStyle>\n        <Transformation>\n          <ogc:Function name=\"ras:Contour\">\n            <ogc:Function name=\"parameter\">\n              <ogc:Literal>data</ogc:Literal>\n            </ogc:Function>\n            <ogc:Function name=\"parameter\">\n              <ogc:Literal>levels</ogc:Literal>\n              <ogc:Literal>1100</ogc:Literal>\n              <ogc:Literal>1200</ogc:Literal>\n              <ogc:Literal>1300</ogc:Literal>\n              <ogc:Literal>1400</ogc:Literal>\n              <ogc:Literal>1500</ogc:Literal>\n              <ogc:Literal>1600</ogc:Literal>\n              <ogc:Literal>1700</ogc:Literal>\n              <ogc:Literal>1800</ogc:Literal>\n            </ogc:Function>\n          </ogc:Function>\n        </Transformation>\n        <Rule>\n          <Name>rule1</Name>\n          <Title>Contour Line</Title>\n          <LineSymbolizer>\n            <Stroke>\n              <CssParameter name=\"stroke\">#000000</CssParameter>\n              <CssParameter name=\"stroke-width\">1</CssParameter>\n            </Stroke>\n          </LineSymbolizer>\n          <TextSymbolizer>\n            <Label>\n              <ogc:PropertyName>value</ogc:PropertyName>\n            </Label>\n            <Font>\n              <CssParameter name=\"font-family\">Arial</CssParameter>\n              <CssParameter name=\"font-style\">Normal</CssParameter>\n              <CssParameter name=\"font-size\">10</CssParameter>\n            </Font>\n            <LabelPlacement>\n              <LinePlacement/>\n            </LabelPlacement>\n            <Halo>\n              <Radius>\n                <ogc:Literal>2</ogc:Literal>\n              </Radius>\n              <Fill>\n                <CssParameter name=\"fill\">#FFFFFF</CssParameter>\n                <CssParameter name=\"fill-opacity\">0.6</CssParameter>        \n              </Fill>\n            </Halo>\n            <Fill>\n              <CssParameter name=\"fill\">#000000</CssParameter>\n            </Fill>\n            <Priority>2000</Priority>\n            <VendorOption name=\"followLine\">true</VendorOption>\n            <VendorOption name=\"repeat\">100</VendorOption>\n            <VendorOption name=\"maxDisplacement\">50</VendorOption>\n            <VendorOption name=\"maxAngleDelta\">30</VendorOption>\n          </TextSymbolizer>\n        </Rule>\n      </FeatureTypeStyle>\n    </UserStyle>\n  </NamedLayer>\n </StyledLayerDescriptor>\n

                                                                                          Key aspects of the SLD are:

                                                                                          • Lines 14-15 define the rendering transformation, using the process ras:Contour.
                                                                                          • Lines 16-18 supply the input data parameter, named data in this process.
                                                                                          • Lines 19-29 supply values for the process's levels parameter, which specifies the elevation levels for the contours to extract.
                                                                                          • Lines 35-40 specify a LineSymbolizer to style the contour lines.
                                                                                          • Lines 41-70 specify a TextSymbolizer to show the contour levels along the lines.

                                                                                          The result of using this transformation is shown in the following map image (which also shows the underlying DEM raster):

                                                                                          "},{"location":"styling/sld/extensions/rendering-transform/#heatmap-generation","title":"Heatmap generation","text":"

                                                                                          vec:Heatmap is a Vector-to-Raster rendering transformation which generates a heatmap surface from weighted point data. The following SLD invokes a Heatmap rendering transformation on a featuretype with point geometries and an attribute pop2000 supplying the weight for the points (in this example, a dataset of world urban areas is used). The output is styled using a color ramp across the output data value range [0 .. 1].

                                                                                          <?xml version=\"1.0\" encoding=\"ISO-8859-1\"?>\n<StyledLayerDescriptor version=\"1.0.0\" \n    xsi:schemaLocation=\"http://www.opengis.net/sld StyledLayerDescriptor.xsd\" \n    xmlns=\"http://www.opengis.net/sld\" \n    xmlns:ogc=\"http://www.opengis.net/ogc\" \n    xmlns:xlink=\"http://www.w3.org/1999/xlink\" \n    xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\">\n  <NamedLayer>\n    <Name>Heatmap</Name>\n    <UserStyle>\n      <Title>Heatmap</Title>\n      <Abstract>A heatmap surface showing population density</Abstract>\n      <FeatureTypeStyle>\n        <Transformation>\n          <ogc:Function name=\"vec:Heatmap\">\n            <ogc:Function name=\"parameter\">\n              <ogc:Literal>data</ogc:Literal>\n            </ogc:Function>\n            <ogc:Function name=\"parameter\">\n              <ogc:Literal>weightAttr</ogc:Literal>\n              <ogc:Literal>pop2000</ogc:Literal>\n            </ogc:Function>\n            <ogc:Function name=\"parameter\">\n              <ogc:Literal>radiusPixels</ogc:Literal>\n              <ogc:Function name=\"env\">\n                <ogc:Literal>radius</ogc:Literal>\n                <ogc:Literal>100</ogc:Literal>\n              </ogc:Function>\n            </ogc:Function>\n            <ogc:Function name=\"parameter\">\n              <ogc:Literal>pixelsPerCell</ogc:Literal>\n              <ogc:Literal>10</ogc:Literal>\n            </ogc:Function>\n            <ogc:Function name=\"parameter\">\n              <ogc:Literal>outputBBOX</ogc:Literal>\n              <ogc:Function name=\"env\">\n                <ogc:Literal>wms_bbox</ogc:Literal>\n              </ogc:Function>\n            </ogc:Function>\n            <ogc:Function name=\"parameter\">\n              <ogc:Literal>outputWidth</ogc:Literal>\n              <ogc:Function name=\"env\">\n                <ogc:Literal>wms_width</ogc:Literal>\n              </ogc:Function>\n            </ogc:Function>\n            <ogc:Function name=\"parameter\">\n              <ogc:Literal>outputHeight</ogc:Literal>\n              <ogc:Function name=\"env\">\n                <ogc:Literal>wms_height</ogc:Literal>\n              </ogc:Function>\n            </ogc:Function>\n          </ogc:Function>\n        </Transformation>\n       <Rule>\n         <RasterSymbolizer>\n         <!-- specify geometry attribute to pass validation -->\n           <Geometry>\n             <ogc:PropertyName>the_geom</ogc:PropertyName></Geometry>\n           <Opacity>0.6</Opacity>\n           <ColorMap type=\"ramp\" >\n             <ColorMapEntry color=\"#FFFFFF\" quantity=\"0\" label=\"nodata\" \n               opacity=\"0\"/>\n             <ColorMapEntry color=\"#FFFFFF\" quantity=\"0.02\" label=\"nodata\" \n               opacity=\"0\"/>\n             <ColorMapEntry color=\"#4444FF\" quantity=\".1\" label=\"nodata\"/>\n             <ColorMapEntry color=\"#FF0000\" quantity=\".5\" label=\"values\" />\n             <ColorMapEntry color=\"#FFFF00\" quantity=\"1.0\" label=\"values\" />\n           </ColorMap>\n         </RasterSymbolizer>\n        </Rule>\n      </FeatureTypeStyle>\n    </UserStyle>\n  </NamedLayer>\n </StyledLayerDescriptor>\n

                                                                                          Key aspects of the SLD are:

                                                                                          • Lines 14-15 define the rendering transformation, using the process vec:Heatmap.
                                                                                          • Lines 16-18 supply the input data parameter, named data in this process.
                                                                                          • Lines 19-22 supply a value for the process's weightAttr parameter, which specifies the input attribute providing a weight for each data point.
                                                                                          • Lines 23-29 supply the value for the radiusPixels parameter, which controls the \"spread\" of the heatmap around each point. In this SLD the value of this parameter may be supplied by a SLD substitution variable called radius, with a default value of 100 pixels.
                                                                                          • Lines 30-33 supply the pixelsPerCell parameter, which controls the resolution at which the heatmap raster is computed.
                                                                                          • Lines 34-38 supply the outputBBOX parameter, which is given the value of the standard SLD environment variable wms_bbox.
                                                                                          • Lines 40-45 supply the outputWidth parameter, which is given the value of the standard SLD environment variable wms_width.
                                                                                          • Lines 46-52 supply the outputHeight parameter, which is given the value of the standard SLD environment variable wms_height.
                                                                                          • Lines 55-70 specify a RasterSymbolizer to style the computed raster surface. The symbolizer contains a ramped color map for the data range [0..1].
                                                                                          • Line 58 specifies the geometry attribute of the input featuretype, which is necessary to pass SLD validation.

                                                                                          This transformation styles a layer to produce a heatmap surface for the data in the requested map extent, as shown in the image below. (The map image also shows the original input data points styled by another SLD, as well as a base map layer.)

                                                                                          "},{"location":"styling/sld/extensions/rendering-transform/#running-map-algebra-on-the-fly-using-jiffle","title":"Running map algebra on the fly using Jiffle","text":"

                                                                                          The Jiffle rendering transformation allows to run map algebra on the bands of an input raster layer using the Jiffle language. For example, the following style computes the NDVI index from a 13 bands Sentinel 2 image, in which the red and NIR bands are the forth and eight bands (Jiffle band indexes are zero based), and then displays the resulting index with a color map:

                                                                                          <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<StyledLayerDescriptor xmlns=\"http://www.opengis.net/sld\" xmlns:ogc=\"http://www.opengis.net/ogc\" xmlns:xlink=\"http://www.w3.org/1999/xlink\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xsi:schemaLocation=\"http://www.opengis.net/sld\nhttp://schemas.opengis.net/sld/1.0.0/StyledLayerDescriptor.xsd\" version=\"1.0.0\">\n  <NamedLayer>\n    <Name>Sentinel2 NDVI</Name>\n    <UserStyle>\n      <Title>NDVI</Title>\n      <FeatureTypeStyle>\n        <Transformation>\n          <ogc:Function name=\"ras:Jiffle\">\n            <ogc:Function name=\"parameter\">\n              <ogc:Literal>coverage</ogc:Literal>\n            </ogc:Function>\n            <ogc:Function name=\"parameter\">\n              <ogc:Literal>script</ogc:Literal>\n              <ogc:Literal>\n                nir = src[7];\n                vir = src[3];\n                dest = (nir - vir) / (nir + vir);\n              </ogc:Literal>\n            </ogc:Function>\n          </ogc:Function>\n        </Transformation>\n        <Rule>\n          <RasterSymbolizer>\n            <Opacity>1.0</Opacity>\n            <ColorMap>\n              <ColorMapEntry color=\"#000000\" quantity=\"-1\"/>\n              <ColorMapEntry color=\"#0000ff\" quantity=\"-0.75\"/>\n              <ColorMapEntry color=\"#ff00ff\" quantity=\"-0.25\"/>\n              <ColorMapEntry color=\"#ff0000\" quantity=\"0\"/>\n              <ColorMapEntry color=\"#ffff00\" quantity=\"0.5\"/>\n              <ColorMapEntry color=\"#00ff00\" quantity=\"1\"/>\n            </ColorMap>\n          </RasterSymbolizer>\n        </Rule>\n      </FeatureTypeStyle>\n    </UserStyle>\n  </NamedLayer>\n</StyledLayerDescriptor>\n

                                                                                          Here are a view of the area, using the visible color bands:

                                                                                          and then the display of the NDVI index computed with the above style:

                                                                                          "},{"location":"styling/sld/extensions/rendering-transform/#group-candidate-selection","title":"Group candidate selection","text":"

                                                                                          vec:GroupCandidateSelection is a Vector-to-Vector rendering transformation which filters a FeatureCollection according to the aggregate operation chosen (MIN or MAX) and the groups defined through attribute names. Given a feature collection, groups according to the defined grouping attributes, and returns the feature having the MIN or MAX value for the chosen attribute. One feature will be chosen for each group. The following SLD invokes the transformation:

                                                                                          <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n    <sld:StyledLayerDescriptor xmlns:sld=\"http://www.opengis.net/sld\" xmlns=\"http://www.opengis.net/sld\" xmlns:st=\"http://www.stations.org/1.0\" xmlns:gml=\"http://www.opengis.net/gml\" xmlns:ogc=\"http://www.opengis.net/ogc\" xmlns:xlink=\"http://www.w3.org/1999/xlink\" version=\"1.0.0\">\n     <sld:UserLayer>\n     <sld:UserStyle>\n         <sld:Name>Default Styler</sld:Name>\n         <sld:Title>Default Styler</sld:Title>\n         <sld:FeatureTypeStyle>\n             <Transformation>\n                 <ogc:Function name=\"vec:GroupCandidateSelection\">\n                     <ogc:Function name=\"parameter\">\n                         <ogc:Literal>data</ogc:Literal>\n                     </ogc:Function>\n                     <ogc:Function name=\"parameter\">\n                         <ogc:Literal>operationAttribute</ogc:Literal>\n                         <ogc:Literal>st:numericAttribute</ogc:Literal>\n                     </ogc:Function>\n                     <ogc:Function name=\"parameter\">\n                         <ogc:Literal>aggregation</ogc:Literal>\n                         <ogc:Literal>MIN</ogc:Literal>\n                     </ogc:Function>\n                     <ogc:Function name=\"parameter\">\n                         <ogc:Literal>groupingAttributes</ogc:Literal>\n                         <ogc:Literal>st:inferredAttribute</ogc:Literal>\n                         <ogc:Literal>st:inferredAttribute2</ogc:Literal>\n                     </ogc:Function>\n                 </ogc:Function>\n             </Transformation>\n             <sld:rule>\n                 <sld:Title>Stations Selected Candidate</sld:Title>\n                 <sld:PointSymbolizer>\n                     <Stroke>\n                         <CssParameter name=\"stroke\">#000000</CssParameter>\n                     </Stroke>\n                 </sld:PointSymbolizer>\n             </sld:rule>\n         </sld:FeatureTypeStyle>\n     </sld:UserStyle>\n  </sld:UserLayer>\n</sld:StyledLayerDescriptor>\n

                                                                                          Where st:numericAttribute, st:inferredAttribute and st:inferredAttribute2 are attributes of the current layer being rendered, in this case, a layer based complex features, having the attributes used for rendering in the http://www.stations.org/1.0 namespace.

                                                                                          This vector process accepts four parameters:

                                                                                          • data: the data on which perform the computation.
                                                                                          • aggregation: the type of operation required to filter data (MIN or MAX).
                                                                                          • operationAttribute: the xpath to the attribute whose value will be used to perform the MIN or MAX operation.
                                                                                          • groupingAttributes: a lists of xpath pointing to the attributes defining the features' groups for which perform the filtering process.
                                                                                          "},{"location":"styling/sld/extensions/rendering-transform/#disabling-getfeatureinfo-requests-results-transformation","title":"Disabling GetFeatureInfo requests results transformation","text":"

                                                                                          By default GetFeatureInfo results are determined from the output after evaluating rendering transformation on the layer data. This behavior can be changed only for raster sources (i.e., raster-to-raster and raster-to-vector transformations). See section Disabling GetFeatureInfo requests results transformation to disable this behavior on a global or per virtual service basis. The WMS setting can be overridden for individual FeatureTypeStyle elements using the transformFeatureInfo SLD vendor option (either true or false).

                                                                                          <VendorOption name=\"transformFeatureInfo\">true</VendorOption>\n
                                                                                          "},{"location":"styling/sld/extensions/substitution/","title":"Variable substitution in SLD","text":"

                                                                                          Variable substitution in SLD is a GeoServer extension (starting in version 2.0.2) that allows passing values from WMS requests into SLD styles. This allows dynamically setting values such as colors, fonts, sizes and filter thresholds.

                                                                                          Variables are specified in WMS GetMap requests by using the env request parameter followed by a list of name:value pairs separated by semicolons:

                                                                                          ...&env=name1:value1;name2=value2&...\n

                                                                                          In an SLD the variable values are accessed using the env function. The function retrieves a substitution variable value specified in the current request:

                                                                                          <ogc:Function name=\"env\">\n   <ogc:Literal>size</ogc:Literal>\n</ogc:Function>       \n

                                                                                          A default value can be provided. It will be used if the variable was not specified in the request:

                                                                                          <ogc:Function name=\"env\">\n   <ogc:Literal>size</ogc:Literal>\n   <ogc:Literal>6</ogc:Literal>\n</ogc:Function>  \n

                                                                                          The env function can be used in an SLD anywhere an OGC expression is allowed. For example, it can be used in CSSParameter elements, in size and offset elements, and in rule filter expressions. It is also accepted in some places where full expressions are not allowed, such as in the Mark/WellKnownName element.

                                                                                          "},{"location":"styling/sld/extensions/substitution/#predefined-variables","title":"Predefined Variables","text":"

                                                                                          GeoServer has predefined variables which provide information about specific properties of the request output. These are useful when SLD parameters need to depend on output dimensions. The predefined variables are:

                                                                                          Name Type Description wms_bbox ReferencedEnvelope the georeferenced extent of the request output wms_crs CoordinateReferenceSystem the definition of the output coordinate reference system wms_srs String the code for the output coordinate reference system wms_width Integer the width (in pixels) of the output image wms_height Integer the height (in pixels) of the output image wms_scale_denominator Integer the denominator of the output map scale kmlOutputMode Either vector or empty this variable gets set to vector when the kml generator is writing out vector features as placemarks, as opposed to ground overlays"},{"location":"styling/sld/extensions/substitution/#example","title":"Example","text":"

                                                                                          The following SLD symbolizer has been parameterized in three places, with default values provided in each case:

                                                                                          <PointSymbolizer>\n  <Graphic>\n    <Mark>\n      <WellKnownName><ogc:Function name=\"env\">\n            <ogc:Literal>name</ogc:Literal>\n            <ogc:Literal>square</ogc:Literal>\n         </ogc:Function>\n      </WellKnownName>\n      <Fill>\n        <CssParameter name=\"fill\">\n          #<ogc:Function name=\"env\">\n            <ogc:Literal>color</ogc:Literal>\n            <ogc:Literal>FF0000</ogc:Literal>\n         </ogc:Function>\n        </CssParameter>\n      </Fill>\n    </Mark>\n    <Size>\n       <ogc:Function name=\"env\">\n          <ogc:Literal>size</ogc:Literal>\n          <ogc:Literal>6</ogc:Literal>\n       </ogc:Function>\n    </Size>\n  </Graphic>\n</PointSymbolizer>\n

                                                                                          Download the full SLD style

                                                                                          When no variables are provided in the WMS request, the SLD uses the default values and renders the sample sf:bugsites dataset as shown:

                                                                                          Default rendering

                                                                                          If the request is changed to specify the following variable values:

                                                                                          &env=color:00FF00;name:triangle;size:12\n

                                                                                          the result is instead:

                                                                                          Rendering with variables supplied

                                                                                          "},{"location":"styling/sld/extensions/uom/","title":"Specifying symbolizer sizes in ground units","text":"

                                                                                          The SLD 1.0 specification allows giving symbolizer sizes in a single unit of measure: pixels. This means that the size of symbolizers is the same at all zoom levels (which is usually the desired behaviour).

                                                                                          The Symbology Encoding 1.1 specification provides a uom attribute on Symbolizer elements. This allows specifying styling parameter sizes in ground units of metres or feet, as well as the default which is screen pixels. When ground units are used, the screen size of styled elements increases as the map is zoomed in to larger scales. GeoServer supports the SE 1.1 uom attribute in its extended SLD 1.0 support.

                                                                                          Note

                                                                                          This extended feature is officially supported in GeoServer 2.1.0. It is available in GeoServer 2.0.3 if the -DenableDpiUomRescaling=true system variable is specified for the JVM.

                                                                                          The value of the uom attribute is a URI indicating the desired unit. The units of measure supported are those given in the SE 1.1 specification:

                                                                                          http://www.opengeospatial.org/se/units/metre\nhttp://www.opengeospatial.org/se/units/foot\nhttp://www.opengeospatial.org/se/units/pixel\n

                                                                                          Note

                                                                                          The px override modifier for parameters values is not currently supported.

                                                                                          "},{"location":"styling/sld/extensions/uom/#example","title":"Example","text":"

                                                                                          The following SLD shows the uom attribute used to specify the width of a LineSymbolizer in metres:

                                                                                          <?xml version=\"1.0\" encoding=\"ISO-8859-1\"?>\n<StyledLayerDescriptor version=\"1.0.0\" xmlns=\"http://www.opengis.net/sld\" xmlns:ogc=\"http://www.opengis.net/ogc\"\n  xmlns:xlink=\"http://www.w3.org/1999/xlink\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\">\n  <NamedLayer>\n    <Name>5m blue line</Name>\n    <UserStyle>\n      <Title>tm blue line</Title>\n      <Abstract>Default line style, 5m wide blue</Abstract>\n\n      <FeatureTypeStyle>\n        <Rule>\n          <Title>Blue Line, 5m large</Title>\n          <LineSymbolizer uom=\"http://www.opengeospatial.org/se/units/metre\">\n            <Stroke>\n              <CssParameter name=\"stroke\">#0000FF</CssParameter>\n              <CssParameter name=\"stroke-width\">5</CssParameter>\n            </Stroke>\n          </LineSymbolizer>\n        </Rule>\n\n      </FeatureTypeStyle>\n    </UserStyle>\n  </NamedLayer>\n</StyledLayerDescriptor>\n

                                                                                          Applying the style to the tiger:tiger_roads dataset shows how the line widths increase as the map is zoomed in:

                                                                                          "},{"location":"styling/sld/extensions/composite-blend/","title":"Color compositing and color blending","text":"

                                                                                          It is possible to perform color blending and compositing, either between feature type styles or by associating blending operations with each symbolizer.

                                                                                          GeoServer implements most of the color compositing and blending modes suggested by the SVG compositing and blending level 1 specification. Either set of operations allows one to control how two overlapping layers/symbols are merged together to form a final map (as opposed to the normal behavior of just stacking images on top of each other).

                                                                                          This section will use the following definitions for the common terms \"source\" and \"destination\":

                                                                                          • Source : Image currently being painted on top of the map
                                                                                          • Destination: Background image that the source image is being drawn on
                                                                                          • Specifying compositing and blending in SLD
                                                                                          • Composite and blending modes
                                                                                          • Compositing and blending example
                                                                                          "},{"location":"styling/sld/extensions/composite-blend/example/","title":"Compositing and blending example","text":"

                                                                                          Let's say we want to draw the topp:states layer so that the polygons are not filled with the population keyed colors, but only an inner border inside the polygon should appear, leaving the internal fully transparent.

                                                                                          This is the destination:

                                                                                          topp:states layer

                                                                                          Using alpha blending, this can be achieved by creating a mask around the state borders with a thick stroke, and then using a \"destination-in\" alpha compositing.

                                                                                          This is the source (mask):

                                                                                          Layer mask

                                                                                          The SLD will contain three FeatureTypeStyles. The first one would be the standard rules (states colored by population) and the last one will contain the label rules. The second (middle) one is where the blending will occur:

                                                                                          ...\n<FeatureTypeStyle>\n  <!-- Usual states rules, skipped for brevity -->\n</FeatureTypeStyle>\n<FeatureTypeStyle>\n  <Rule>\n    <LineSymbolizer>\n      <Stroke>\n        <CssParameter name=\"stroke-width\">10</CssParameter>\n        <CssParameter name=\"stroke\">#000000</CssParameter>\n      </Stroke>\n    </LineSymbolizer>\n  </Rule>\n  <VendorOption name=\"composite\">destination-in</VendorOption>\n</FeatureTypeStyle>\n<FeatureTypeStyle>\n  <!-- The label rules, skipped for brevity -->\n</FeatureTypeStyle>\n...\n

                                                                                          This is the result of the composition:

                                                                                          Now, if for example someone makes a WMS call in which the another layer is drawn below this one, the result will look like this:

                                                                                          This other background layer is hardly visible, because it has been cut by the mask. This shows the risks of using alpha compositing without care in a WMS setting.

                                                                                          In order to achieve the desired result no matter how the client composes the request, the first FeatureTypeStyle that draws the polygons (the states themselves) needs to be set as a compositing base, ensuring the mask will only be applied to it.

                                                                                          <VendorOption name=\"composite-base\">true</VendorOption>\n

                                                                                          The result will look like the following (though a multiply blend was added to the base to ensure a nice visual transparency effect on the border lines):

                                                                                          Download the final style

                                                                                          Note

                                                                                          See the full list of available modes.

                                                                                          "},{"location":"styling/sld/extensions/composite-blend/modes/","title":"Composite and blending modes","text":"

                                                                                          There are two types of modes: alpha composite and color blending.

                                                                                          Alpha compositing controls how two images are merged together by using the alpha levels of the two. No color mixing is being performed, only pure binary selection (either one or the other).

                                                                                          Color blending modes mix the colors of source and destination in various ways. Each pixel in the result will be some sort of combination between the source and destination pixels.

                                                                                          The following page shows the full list of available modes. (See the syntax page for more details.) To aid in comprehension, two source and two destination images will be used to show visually how each mode works:

                                                                                          +---------------------+----------------------+ | Source 1 | Source 2 | +=====================+======================+ | | | +---------------------+----------------------+

                                                                                          +---------------------+----------------------+ | Destination 1 | Destination 2 | +=====================+======================+ | | | +---------------------+----------------------+

                                                                                          "},{"location":"styling/sld/extensions/composite-blend/modes/#alpha-compositing-modes","title":"Alpha compositing modes","text":""},{"location":"styling/sld/extensions/composite-blend/modes/#copy","title":"copy","text":"

                                                                                          Only the source will be present in the output.

                                                                                          +-----------------------------+-----------------------------+ | Example 1 | Example 2 | +=============================+=============================+ | | | +-----------------------------+-----------------------------+

                                                                                          "},{"location":"styling/sld/extensions/composite-blend/modes/#destination","title":"destination","text":"

                                                                                          Only the destination will be present in the output

                                                                                          +------------------------------------+------------------------------------+ | Example 1 | Example 2 | +====================================+====================================+ | | | +------------------------------------+------------------------------------+

                                                                                          "},{"location":"styling/sld/extensions/composite-blend/modes/#source-over","title":"source-over","text":"

                                                                                          The source is drawn over the destination, and the destination is visible where the source is transparent. Opposite of destination-over.

                                                                                          +------------------------------------+------------------------------------+ | Example 1 | Example 2 | +====================================+====================================+ | | | +------------------------------------+------------------------------------+

                                                                                          "},{"location":"styling/sld/extensions/composite-blend/modes/#destination-over","title":"destination-over","text":"

                                                                                          The source is drawn below the destination, and is visible only when the destination is transparent. Opposite of source-over.

                                                                                          +-----------------------------------------+-----------------------------------------+ | Example 1 | Example 2 | +=========================================+=========================================+ | | | +-----------------------------------------+-----------------------------------------+

                                                                                          "},{"location":"styling/sld/extensions/composite-blend/modes/#source-in","title":"source-in","text":"

                                                                                          The source is visible only when overlapping some non-transparent pixel of the destination. This allows the background map to act as a mask for the layer/feature being drawn. Opposite of destination-in.

                                                                                          +----------------------------------+----------------------------------+ | Example 1 | Example 2 | +==================================+==================================+ | | | +----------------------------------+----------------------------------+

                                                                                          "},{"location":"styling/sld/extensions/composite-blend/modes/#destination-in","title":"destination-in","text":"

                                                                                          The destination is retained only when overlapping some non transparent pixel in the source. This allows the layer/feature to be drawn to act as a mask for the background map. Opposite of source-in.

                                                                                          +---------------------------------------+---------------------------------------+ | Example 1 | Example 2 | +=======================================+=======================================+ | | | +---------------------------------------+---------------------------------------+

                                                                                          "},{"location":"styling/sld/extensions/composite-blend/modes/#source-out","title":"source-out","text":"

                                                                                          The source is retained only in areas where the destination is transparent. This acts as a reverse mask when compared to source-in.

                                                                                          +-----------------------------------+-----------------------------------+ | Example 1 | Example 2 | +===================================+===================================+ | | | +-----------------------------------+-----------------------------------+

                                                                                          "},{"location":"styling/sld/extensions/composite-blend/modes/#destination-out","title":"destination-out","text":"

                                                                                          The destination is retained only in areas where the source is transparent. This acts as a reverse mask when compared to destination-in.

                                                                                          +----------------------------------------+----------------------------------------+ | Example 1 | Example 2 | +========================================+========================================+ | | | +----------------------------------------+----------------------------------------+

                                                                                          "},{"location":"styling/sld/extensions/composite-blend/modes/#source-atop","title":"source-atop","text":"

                                                                                          The destination is drawn fully, while the source is drawn only where it intersects the destination.

                                                                                          +------------------------------------+------------------------------------+ | Example 1 | Example 2 | +====================================+====================================+ | | | +------------------------------------+------------------------------------+

                                                                                          "},{"location":"styling/sld/extensions/composite-blend/modes/#destination-atop","title":"destination-atop","text":"

                                                                                          The source is drawn fully, and the destination is drawn over the source and only where it intersects it.

                                                                                          +-----------------------------------------+-----------------------------------------+ | Example 1 | Example 2 | +=========================================+=========================================+ | | | +-----------------------------------------+-----------------------------------------+

                                                                                          "},{"location":"styling/sld/extensions/composite-blend/modes/#xor","title":"xor","text":"

                                                                                          \"Exclusive Or\" mode. Each pixel is rendered only if either the source or the destination is not blank, but not both.

                                                                                          +----------------------------+----------------------------+ | Example 1 | Example 2 | +============================+============================+ | | | +----------------------------+----------------------------+

                                                                                          "},{"location":"styling/sld/extensions/composite-blend/modes/#color-blending-modes","title":"Color blending modes","text":""},{"location":"styling/sld/extensions/composite-blend/modes/#multiply","title":"multiply","text":"

                                                                                          The source color is multiplied by the destination color and replaces the destination. The resulting color is always at least as dark as either the source or destination color. Multiplying any color with black results in black. Multiplying any color with white preserves the original color.

                                                                                          +---------------------------------+---------------------------------+ | Example 1 | Example 2 | +=================================+=================================+ | | | +---------------------------------+---------------------------------+

                                                                                          "},{"location":"styling/sld/extensions/composite-blend/modes/#screen","title":"screen","text":"

                                                                                          Multiplies the complements of the source and destination color values, then complements the result. The end result color is always at least as light as either of the two constituent colors. Screening any color with white produces white; screening with black leaves the original color unchanged.

                                                                                          The effect is similar to projecting multiple photographic slides simultaneously onto a single screen.

                                                                                          +-------------------------------+-------------------------------+ | Example 1 | Example 2 | +===============================+===============================+ | | | +-------------------------------+-------------------------------+

                                                                                          "},{"location":"styling/sld/extensions/composite-blend/modes/#overlay","title":"overlay","text":"

                                                                                          Multiplies (screens) the colors depending on the destination color value. Source colors overlay the destination while preserving its highlights and shadows. The backdrop color is not replaced but is mixed with the source color to reflect the lightness or darkness of the backdrop.

                                                                                          +--------------------------------+--------------------------------+ | Example 1 | Example 2 | +================================+================================+ | | | +--------------------------------+--------------------------------+

                                                                                          "},{"location":"styling/sld/extensions/composite-blend/modes/#darken","title":"darken","text":"

                                                                                          Selects the darker of the destination and source colors. The destination is replaced with the source only where the source is darker.

                                                                                          +-------------------------------+-------------------------------+ | Example 1 | Example 2 | +===============================+===============================+ | | | +-------------------------------+-------------------------------+

                                                                                          "},{"location":"styling/sld/extensions/composite-blend/modes/#lighten","title":"lighten","text":"

                                                                                          Selects the lighter of the destination and source colors. The destination is replaced with the source only where the source is lighter.

                                                                                          +--------------------------------+--------------------------------+ | Example 1 | Example 2 | +================================+================================+ | | | +--------------------------------+--------------------------------+

                                                                                          "},{"location":"styling/sld/extensions/composite-blend/modes/#color-dodge","title":"color-dodge","text":"

                                                                                          Brightens the destination color to reflect the source color. Drawing with black produces no changes.

                                                                                          +------------------------------------+------------------------------------+ | Example 1 | Example 2 | +====================================+====================================+ | | | +------------------------------------+------------------------------------+

                                                                                          "},{"location":"styling/sld/extensions/composite-blend/modes/#color-burn","title":"color-burn","text":"

                                                                                          Darkens the destination color to reflect the source color. Drawing with white produces no change.

                                                                                          +-----------------------------------+-----------------------------------+ | Example 1 | Example 2 | +===================================+===================================+ | | | +-----------------------------------+-----------------------------------+

                                                                                          "},{"location":"styling/sld/extensions/composite-blend/modes/#hard-light","title":"hard-light","text":"

                                                                                          Multiplies or screens the colors, depending on the source color value. The effect is similar to shining a harsh spotlight on the destination.

                                                                                          +-----------------------------------+-----------------------------------+ | Example 1 | Example 2 | +===================================+===================================+ | | | +-----------------------------------+-----------------------------------+

                                                                                          "},{"location":"styling/sld/extensions/composite-blend/modes/#soft-light","title":"soft-light","text":"

                                                                                          Darkens or lightens the colors, depending on the source color value. The effect is similar to shining a diffused spotlight on the destination.

                                                                                          +-----------------------------------+-----------------------------------+ | Example 1 | Example 2 | +===================================+===================================+ | | | +-----------------------------------+-----------------------------------+

                                                                                          "},{"location":"styling/sld/extensions/composite-blend/modes/#difference","title":"difference","text":"

                                                                                          Subtracts the darker of the two constituent colors from the lighter color. White inverts the destination color; black produces no change.

                                                                                          +-----------------------------------+-----------------------------------+ | Example 1 | Example 2 | +===================================+===================================+ | | | +-----------------------------------+-----------------------------------+

                                                                                          "},{"location":"styling/sld/extensions/composite-blend/modes/#exclusion","title":"exclusion","text":"

                                                                                          Produces an effect similar to that of difference but lower in contrast. White inverts the destination color; black produces no change.

                                                                                          +----------------------------------+----------------------------------+ | Example 1 | Example 2 | +==================================+==================================+ | | | +----------------------------------+----------------------------------+

                                                                                          "},{"location":"styling/sld/extensions/composite-blend/syntax/","title":"Specifying compositing and blending in SLD","text":""},{"location":"styling/sld/extensions/composite-blend/syntax/#composites","title":"Composites","text":"

                                                                                          Both compositing and blending can be specified in SLD by adding the following VendorOption to either the end of a Symbolizer or FeatureTypeStyle:

                                                                                          <VendorOption name=\"composite\">multiply</VendorOption>        \n

                                                                                          In case a custom opacity is desired, it can be added after the operation name separated with a comma:

                                                                                          <VendorOption name=\"composite\">multiply, 0.5</VendorOption>\n

                                                                                          Note

                                                                                          See the full list of available modes.

                                                                                          Warning

                                                                                          Blending against symbolizers causes exceptions inside the JDK when using OpenJDK. The issue is known and has been reportedly fixed, but only in OpenJDK 9.

                                                                                          One way to get around this issue with OpenJDK \u215e is to install the Marlin renderer. This replaces the OpenJDK core renderer and does not suffer from the same issue.

                                                                                          Oracle JDK 7 or 8 does not show this issue.

                                                                                          "},{"location":"styling/sld/extensions/composite-blend/syntax/#composite-bases","title":"Composite bases","text":"

                                                                                          For FeatureTypeStyles an additional vendor option can be added to control compositing groups:

                                                                                          <VendorOption name=\"composite-base\">true</VendorOption>\n

                                                                                          This will tell the rendering engine to use that FeatureTypeStyle as the destination, and will compose all subsequent FeatureTypeStyle/Layers on top of it, until another base is found. Once the full set of layers against a base is composed, then the base itself will be composed against the next set of composed layers, using its own compositing operator, if present.

                                                                                          Without this setting, the destination will be the full stack of all previous FeatureTypeStyles and layers drawn before the current one. This can be limiting for two reasons:

                                                                                          • It limits the usefulness of alpha-composite masking operations
                                                                                          • It breaks the WMS model, where the client can decide freely how to stack layers (the desired compositing effects will be achieved only when a certain stack of layers is used)

                                                                                          Consider the following example:

                                                                                          In this example, the first two layers are drawn on top of each other, forming \"Merge1\".

                                                                                          The third layer is a composite base, as such it won't be merged on top of the already drawn map immediately, but it will be drawn to an off-screen buffer, and layer 4 and 5 will be drawn/composited on top of it. Once that happens, \"Merge2\" is ready, and gets drawn on top of \"Merge1\",

                                                                                          The next layer is another base, so \"Base2\" will be again drawn to an off-screen buffer, and layer 7 and 8 will be drawn/composited on top of it, forming Merge3. Once Merge3 is ready, it will be drawn/composited on top of the already fused Merge1/Merge2, generating the final map.

                                                                                          "},{"location":"styling/sld/extensions/z-order/","title":"Z ordering features within and across feature types and layers","text":"

                                                                                          Starting with GeoServer 2.8.0 it is possible to control the order in which the features are being loaded and painted on the map, thus replicating the same above/below relationships found in the reality.

                                                                                          • Enabling z-ordering in a single FeatureTypeStyle
                                                                                          • Z ordering single layer example
                                                                                          "},{"location":"styling/sld/extensions/z-order/example/","title":"Z ordering single layer example","text":"

                                                                                          The OpenStreetMap dataset uses extensively a z_order attribute to model the above/below relationships between elements in the real world.

                                                                                          A small downloadable shapefile is provided that shows a small area with a rich set of different z-orders, where roads and rails go above and below each other. For reference, this is the dataset schema:

                                                                                          Name Type Notes osm_id numeric type string The type of the segment, can be \"mainroads\", \"minorroads\", \"railways\", ... bridge numeric 0 or 1 ref numeric 0 or 1 tunnel numeric oneway numeric 0 or 1 z_order numeric class string

                                                                                          The dataset contains several different values for z_order, in particular: -10, -7, -5, -3, -1, 0, 3, 4, 5, 7, 9, 10, 13, 14, 15, 17, 19.

                                                                                          Here is a sample CSS style using z-ordering, but not groups, to perform the display. Road casing is achieved by multiple FeatureTypeStyle, or z-index values in CSS:

                                                                                          [class = 'railways' and bridge = 1] {\n  stroke: #333333;\n  stroke-width: 8;\n  z-index: 0;\n}\n\n[class = 'minorroads'] {\n  stroke: #a69269;\n  stroke-width: 3;\n  z-index: 0;\n}\n\n[class = 'mainroads'] {\n  stroke: #ff0000;\n  stroke-width: 5;\n  z-index: 0;\n}\n\n[class = 'motorways'] {\n  stroke: #990000;\n  stroke-width: 8;\n  z-index: 0;\n}\n\n[class = 'railways' and bridge = 1] {\n  stroke: #ffffff;\n  stroke-width: 6;\n  z-index: 1;\n}\n\n[class = 'railways'] {\n  stroke: #333333;\n  stroke-width: 3;\n  z-index: 2;\n}\n\n[class = 'railways'] {\n  stroke: #ffffff;\n  stroke-width: 1.5;\n  stroke-dasharray: 5, 5;\n  z-index: 3;\n}\n\n[class = 'motorways'] {\n  stroke: #ff6666;\n  stroke-width: 6;\n  stroke-linecap: round;\n  z-index: 3;\n}\n\n[class = 'minorroads'] {\n  stroke: #ffffff;\n  stroke-width: 2,5;\n  stroke-linecap: round;\n  z-index: 3;\n}\n\n[class = 'mainroads'] {\n  stroke: #ff9999;\n  stroke-width: 4;\n  stroke-linecap: round;\n  z-index: 3;\n}\n\n* {\n sort-by: \"z_order\";\n}\n

                                                                                          The sorting is achieved by using the sort-by property, which translates into a sortBy VendorOption in SLD. A full equivalent SLD is available for download.

                                                                                          This is the resulting map:

                                                                                          As one can see, there are evident issues:

                                                                                          • Roads and rails are not showing any evident z-ordering, in fact, all rails are below roads, but their dashed white center shows a mix of below and above roads
                                                                                          • The rails bridges (depicted with a third thicker line around the rail symbol) are consistently below some other road or rail, while they should be above.

                                                                                          This is mostly happening because the various FeatureTypeStyle elements are not put doctor in a single group.

                                                                                          A slight change in the CSS, grouping all levels in the same sortByGroup, solves the issues above:

                                                                                          [class = 'railways' and bridge = 1] {\n  stroke: #333333;\n  stroke-width: 8;\n  z-index: 0;\n}\n\n[class = 'minorroads'] {\n  stroke: #a69269;\n  stroke-width: 3;\n  z-index: 0;\n}\n\n[class = 'mainroads'] {\n  stroke: #ff0000;\n  stroke-width: 5;\n  z-index: 0;\n}\n\n[class = 'motorways'] {\n  stroke: #990000;\n  stroke-width: 8;\n  z-index: 0;\n}\n\n[class = 'railways' and bridge = 1] {\n  stroke: #ffffff;\n  stroke-width: 6;\n  z-index: 1;\n}\n\n[class = 'railways'] {\n  stroke: #333333;\n  stroke-width: 3;\n  z-index: 2;\n}\n\n[class = 'railways'] {\n  stroke: #ffffff;\n  stroke-width: 1.5;\n  stroke-dasharray: 5, 5;\n  z-index: 3;\n}\n\n[class = 'motorways'] {\n  stroke: #ff6666;\n  stroke-width: 6;\n  stroke-linecap: round;\n  z-index: 3;\n}\n\n[class = 'minorroads'] {\n  stroke: #ffffff;\n  stroke-width: 2,5;\n  stroke-linecap: round;\n  z-index: 3;\n}\n\n[class = 'mainroads'] {\n  stroke: #ff9999;\n  stroke-width: 4;\n  stroke-linecap: round;\n  z-index: 3;\n}\n\n* {\n sort-by: \"z_order\";\n sort-by-group: \"roadsGroup\";\n}\n

                                                                                          A full equivalent SLD is also available for download.

                                                                                          The result now shows proper z-ordering:

                                                                                          "},{"location":"styling/sld/extensions/z-order/syntax/","title":"Enabling z-ordering in a single FeatureTypeStyle","text":"

                                                                                          The z-ordering is implemented as a new FeatureTypeStyle vendor option, sortBy, which controls in which order the features are extracted from the data source, and thus painted. The sortBy syntax is the same as the WFS one, that is, a list of comma separated field names, with an optional direction modifier (ascending being the default):

                                                                                          field1 [A|D], field2 [A|D], ... , fieldN [A|D]\n

                                                                                          Some examples:

                                                                                          • \"z\": sorts the features based on the z field, ascending (lower z values are painted first, higher later)
                                                                                          • \"cat,z D\": sorts the features on the cat attribute, with ascending order, and for those that have the same cat value, the sorting is on descending z
                                                                                          • \"cat D,z D\": sorts the features on the cat attribute, with descending order, and for those that have the same cat value, the sorting is on descending z

                                                                                          So, if we wanted to order features based on a single \"elevation\" attribute we'd be using the following SLD snippet:

                                                                                          ...\n<sld:FeatureTypeStyle>\n  <sld:Rule>\n    ...\n    <!-- filters and symbolizers here -->\n    ...\n  </sld:Rule>\n  <sld:VendorOption name=\"sortBy\">elevation</sld:VendorOption>\n</sld:FeatureTypeStyle>\n...\n
                                                                                          "},{"location":"styling/sld/extensions/z-order/syntax/#z-ordering-across-featuretypestyle","title":"z-ordering across FeatureTypeStyle","text":"

                                                                                          It is a common need to perform road casing against a complex road network, which can have its own z-ordering needs (e.g., over and under passes). Casing is normally achieved by using two separate two FeatureTypeStyle, one drawing a thick line, one drawing a thin one.

                                                                                          Let's consider a simple data set, made of just three roads:

                                                                                          _=geom:LineString:404000,z:int\nLine.1=LINESTRING(0 4, 10 4)|1\nLine.2=LINESTRING(0 6, 10 6)|3\nLine.3=LINESTRING(7 0, 7 10)|1\n

                                                                                          Adding a \"sortBy\" rule to both FeatureTypeStyle objects will achieve no visible result:

                                                                                          <?xml version=\"1.0\" encoding=\"ISO-8859-1\"?>\n<StyledLayerDescriptor version=\"1.0.0\"\n  xsi:schemaLocation=\"http://www.opengis.net/sld StyledLayerDescriptor.xsd\"\n  xmlns=\"http://www.opengis.net/sld\" xmlns:ogc=\"http://www.opengis.net/ogc\"\n  xmlns:xlink=\"http://www.w3.org/1999/xlink\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\">\n  <!-- a named layer is the basic building block of an sld document -->\n\n  <NamedLayer>\n    <UserStyle>\n      <FeatureTypeStyle>\n        <Rule>\n          <LineSymbolizer>\n            <Stroke>\n              <CssParameter name=\"stroke\">#FF0000</CssParameter>\n              <CssParameter name=\"stroke-width\">8</CssParameter>\n            </Stroke>\n          </LineSymbolizer>\n        </Rule>\n        <sld:VendorOption name=\"sortBy\">z</sld:VendorOption>\n      </FeatureTypeStyle>\n      <FeatureTypeStyle>\n        <Rule>\n          <LineSymbolizer>\n            <Stroke>\n              <CssParameter name=\"stroke\">#FFFFFF</CssParameter>\n              <CssParameter name=\"stroke-width\">6</CssParameter>\n            </Stroke>\n          </LineSymbolizer>\n        </Rule>\n        <sld:VendorOption name=\"sortBy\">z</sld:VendorOption>\n      </FeatureTypeStyle>\n    </UserStyle>\n  </NamedLayer>\n</StyledLayerDescriptor>\n

                                                                                          The result will be the following:

                                                                                          This is happening because while the roads are loaded in the right order, Line.1,Line.3,Line.2, they are all painted with the tick link first, and then the code will start over, and paint them all with the thin line.

                                                                                          In order to get both casing and z-ordering to work a new vendor option, sortByGroup, needs to be added to both FeatureTypeStyle, grouping them in a single z-ordering paint.

                                                                                          <?xml version=\"1.0\" encoding=\"ISO-8859-1\"?>\n<StyledLayerDescriptor version=\"1.0.0\"\n  xsi:schemaLocation=\"http://www.opengis.net/sld StyledLayerDescriptor.xsd\"\n  xmlns=\"http://www.opengis.net/sld\" xmlns:ogc=\"http://www.opengis.net/ogc\"\n  xmlns:xlink=\"http://www.w3.org/1999/xlink\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\">\n  <!-- a named layer is the basic building block of an sld document -->\n\n  <NamedLayer>\n    <UserStyle>\n      <FeatureTypeStyle>\n        <Rule>\n          <LineSymbolizer>\n            <Stroke>\n              <CssParameter name=\"stroke\">#FF0000</CssParameter>\n              <CssParameter name=\"stroke-width\">8</CssParameter>\n            </Stroke>\n          </LineSymbolizer>\n        </Rule>\n        <sld:VendorOption name=\"sortBy\">z</sld:VendorOption>\n        <sld:VendorOption name=\"sortByGroup\">roads</sld:VendorOption>\n      </FeatureTypeStyle>\n      <FeatureTypeStyle>\n        <Rule>\n          <LineSymbolizer>\n            <Stroke>\n              <CssParameter name=\"stroke\">#FFFFFF</CssParameter>\n              <CssParameter name=\"stroke-width\">6</CssParameter>\n            </Stroke>\n          </LineSymbolizer>\n        </Rule>\n        <sld:VendorOption name=\"sortBy\">z</sld:VendorOption>\n        <sld:VendorOption name=\"sortByGroup\">roads</sld:VendorOption>\n      </FeatureTypeStyle>\n    </UserStyle>\n  </NamedLayer>\n</StyledLayerDescriptor>\n

                                                                                          The result will be the following:

                                                                                          When grouping is used, the code will first paint Line.1,Line3 with the thick line, then track back and paint them with the thin line, then move to paint Line.2 with the thick line, and finally Line.2 with the thin line, achieving the desired result.

                                                                                          "},{"location":"styling/sld/extensions/z-order/syntax/#z-ordering-across-layers","title":"z-ordering across layers","text":"

                                                                                          Different layers, such for example roads and rails, can have their features z-ordered together by putting all the FeatureTypeStyle in their styles in the same sortByGroup, provided the following conditions are met:

                                                                                          • The layers are side by side in the WMS request/layer group. In other words, the z-ordering allows to break the WMS specified order only if the layers are directly subsequent in the request. This can be extended to any number of layers, provided the progression of FeatureTypeStyle in the same group is not broken
                                                                                          • There is no FeatureTypeStyle in the layer style that's breaking the sequence

                                                                                          Let's consider an example, with a rails layer having two FeatureTypeStyle, one with a group, the other not:

                                                                                          FeatureTypeStyle id SortByGroup id rails1 linework rails2 none

                                                                                          We then have a roads layer with two FeatureTypeStyle, both in the same group:

                                                                                          FeatureTypeStyle id SortByGroup id road1 linework road2 linework

                                                                                          If the WMS request asks for &layers=roads,rails, then the expanded FeatureTypeStyle list will be:

                                                                                          FeatureTypeStyle id SortByGroup id road1 linework road2 linework rails1 linework rails2 none

                                                                                          As a result, the road1,road2,rails1 will form a single group, and this will result in the rails be merged with the roads when z-ordering.

                                                                                          If instead the WMS request asks for &layers=rails,roads````, then the expanded ````FeatureTypeStyle` list will be:

                                                                                          FeatureTypeStyle id SortByGroup id rails1 linework rails2 none road1 linework road2 linework

                                                                                          The rails2 feature type style breaks the sequence, as a result, the rails will not be z-ordered in the same group as the roads.

                                                                                          "},{"location":"styling/sld/reference/","title":"SLD Reference","text":"

                                                                                          The OGC Styled Layer Descriptor (SLD) standard defines a language for expressing styling of geospatial data. GeoServer uses SLD as its primary styling language.

                                                                                          SLD 1.0.0 is defined in the following specification:

                                                                                          • OGC Styled Layer Descriptor Implementation Specification, Version 1.0.0

                                                                                          Subsequently the functionality of SLD has been split into two specifications:

                                                                                          • OGC Symbology Encoding Implementation Specification, Version 1.1.0
                                                                                          • OGC Styled Layer Descriptor profile of the Web Map Service Implementation Specification, Version 1.1.0

                                                                                          GeoServer implements the SLD 1.0.0 standard, as well as some parts of the SE 1.1.0 and WMS-SLD 1.1.0 standards.

                                                                                          Elements of SLD

                                                                                          The following sections describe the SLD elements implemented in GeoServer.

                                                                                          The root element for an SLD is <StyledLayerDescriptor>. It contains a Layers and Styles elements which describe how a map is to be composed and styled.

                                                                                          • StyledLayerDescriptor
                                                                                          • Layers
                                                                                          • Styles

                                                                                          Styles contain Rules and Filters to determine sets of features to be styled with specific symbology. Rules may also specify the scale range in which the feature styling is visible.

                                                                                          • Rules
                                                                                          • Filters

                                                                                          Rules contain Symbolizers to specify how features are styled. There are 5 types of symbolizers:

                                                                                          • PointSymbolizer, which styles features as points
                                                                                          • LineSymbolizer, which styles features as lines
                                                                                          • PolygonSymbolizer, which styles features as polygons
                                                                                          • TextSymbolizer, which styles text labels for features
                                                                                          • RasterSymbolizer, which styles raster coverages

                                                                                          Each symbolizer type has its own parameters to control styling.

                                                                                          • PointSymbolizer
                                                                                          • LineSymbolizer
                                                                                          • PolygonSymbolizer
                                                                                          • TextSymbolizer
                                                                                          • Labeling
                                                                                          • RasterSymbolizer
                                                                                          "},{"location":"styling/sld/reference/filters/","title":"Filters","text":"

                                                                                          A filter is the mechanism in SLD for specifying conditions. They are similar in functionality to the SQL \"WHERE\" clause. Filters are used within Rules to determine which styles should be applied to which features in a data set. The filter language used by SLD follows the OGC Filter Encoding standard. It is described in detail in the Filter Encoding Reference.

                                                                                          A filter condition is specified by using a comparison operator or a spatial operator, or two or more of these combined by logical operators. The operators are usually used to compare properties of the features being filtered to other properties or to literal data.

                                                                                          "},{"location":"styling/sld/reference/filters/#comparison-operators","title":"Comparison operators","text":"

                                                                                          Comparison operators are used to specify conditions on the non-spatial attributes of a feature. The following binary comparison operators are available:

                                                                                          • <PropertyIsEqualTo>
                                                                                          • <PropertyIsNotEqualTo>
                                                                                          • <PropertyIsLessThan>
                                                                                          • <PropertyIsLessThanOrEqualTo>
                                                                                          • <PropertyIsGreaterThan>
                                                                                          • <PropertyIsGreaterThanOrEqualTo>

                                                                                          These operators contain two filter expressions to be compared. The first operand is often a <PropertyName>, but both operands may be any expression, function or literal value.

                                                                                          Binary comparison operators may include a matchCase attribute with the value true or false. If this attribute is true (which is the default), string comparisons are case-sensitive. If the attribute is specified and has the value false strings comparisons do not check case.

                                                                                          Other available value comparison operators are:

                                                                                          • <PropertyIsLike>
                                                                                          • <PropertyIsNull>
                                                                                          • <PropertyIsBetween>

                                                                                          <PropertyIsLike> matches a string property value against a text pattern. It contains a <PropertyName> element containing the name of the property containing the string to be matched and a <Literal> element containing the pattern. The pattern is specified by a sequence of regular characters and three special pattern characters. The pattern characters are defined by the following required attributes of the <PropertyIsLike> element:

                                                                                          • wildCard specifies a pattern character which matches any sequence of zero or more characters
                                                                                          • singleChar specifies a pattern character which matches any single character
                                                                                          • escapeChar specifies an escape character which can be used to escape these pattern characters

                                                                                          <PropertyIsNull> tests whether a property value is null. It contains a single <PropertyName> element containing the name of the property containing the value to be tested.

                                                                                          <PropertyIsBetween> tests whether an expression value lies within a range. It contains a filter expression providing the value to test, followed by the elements <LowerBoundary> and <UpperBoundary>, each containing a filter expression.

                                                                                          "},{"location":"styling/sld/reference/filters/#examples","title":"Examples","text":"
                                                                                          • The following filter selects features whose NAME attribute has the value of \"New York\":
                                                                                          <PropertyIsEqualTo>\n   <PropertyName>NAME</PropertyName>\n   <Literal>New York</Literal>\n</PropertyIsEqualTo>\n
                                                                                          • The following filter selects features whose geometry area is greater than 1,000,000:
                                                                                          <PropertyIsGreaterThan>\n   <ogc:Function name=\"area\"> \n     <PropertyName>GEOMETRY</PropertyName>\n   </ogc:Function>\n   <Literal>1000000</Literal>\n</PropertyIsGreaterThan>\n
                                                                                          "},{"location":"styling/sld/reference/filters/#spatial-operators","title":"Spatial operators","text":"

                                                                                          Spatial operators are used to specify conditions on the geometric attributes of a feature. The following spatial operators are available:

                                                                                          Topological Operators

                                                                                          These operators test topological spatial relationships using the standard OGC Simple Features predicates:

                                                                                          • <Intersects>
                                                                                          • <Equals>
                                                                                          • <Disjoint>
                                                                                          • <Touches>
                                                                                          • <Within>
                                                                                          • <Overlaps>
                                                                                          • <Crosses>
                                                                                          • <Contains>

                                                                                          The content for these operators is a <PropertyName> element for a geometry-valued property and a GML geometry literal.

                                                                                          Distance Operators

                                                                                          These operators compute distance relationships between geometries:

                                                                                          • <DWithin>
                                                                                          • <Beyond>

                                                                                          The content for these elements is a <PropertyName> element for a geometry-valued property, a GML geometry literal, and a <Distance> element containing the value for the distance tolerance. The <Distance> element may include an optional units attribute.

                                                                                          Bounding Box Operator

                                                                                          This operator tests whether a feature geometry attribute intersects a given bounding box:

                                                                                          • <BBOX>

                                                                                          The content is an optional <PropertyName> element, and a GML envelope literal. If the PropertyName is omitted the default geometry attribute is assumed.

                                                                                          "},{"location":"styling/sld/reference/filters/#examples_1","title":"Examples","text":"
                                                                                          • The following filter selects features with a geometry that intersects the point (1,1):
                                                                                          <Intersects>\n   <PropertyName>GEOMETRY</PropertyName>\n   <Literal>\n      <gml:Point>\n         <gml:coordinates>1 1</gml:coordinates>\n      </gml:Point>\n   </Literal>\n</Intersects>\n
                                                                                          • The following filter selects features with a geometry that intersects the box [-10,0 : 10,10]:
                                                                                          <ogc:BBOX>\n  <ogc:PropertyName>GEOMETRY</ogc:PropertyName>\n  <gml:Box srsName=\"urn:x-ogc:def:crs:EPSG:4326\">\n    <gml:coord>\n      <gml:X>-10</gml:X> <gml:Y>0</gml:Y>\n    </gml:coord>\n    <gml:coord>\n      <gml:X>10</gml:X> <gml:Y>10</gml:Y>\n    </gml:coord>\n  </gml:Box>\n</ogc:BBOX>\n
                                                                                          "},{"location":"styling/sld/reference/filters/#logical-operators","title":"Logical operators","text":"

                                                                                          Logical operators are used to create logical combinations of other filter operators. They may be nested to any depth. The following logical operators are available:

                                                                                          • <And>
                                                                                          • <Or>
                                                                                          • <Not>

                                                                                          The content for <And> and <Or> is two filter operator elements. The content for <Not> is a single filter operator element.

                                                                                          "},{"location":"styling/sld/reference/filters/#examples_2","title":"Examples","text":"
                                                                                          • The following filter uses <And> to combine a comparison operator and a spatial operator:
                                                                                          <And>\n   <PropertyIsEqualTo>\n      <PropertyName>NAME</PropertyName>\n      <Literal>New York</Literal>\n   </PropertyIsEqualTo>\n   <Intersects>\n      <PropertyName>GEOMETRY</PropertyName>\n      <Literal>\n         <gml:Point>\n             <gml:coordinates>1 1</gml:coordinates>\n         </gml:Point>\n      </Literal>\n   </Intersects>\n</And>\n
                                                                                          "},{"location":"styling/sld/reference/filters/#sld_filter_expression","title":"Filter Expressions","text":"

                                                                                          Filter expressions allow performing computation on data values. The following elements can be used to form expressions.

                                                                                          Arithmetic Operators

                                                                                          These operators perform arithmetic on numeric values. Each contains two expressions as sub-elements.

                                                                                          • <Add>
                                                                                          • <Sub>
                                                                                          • <Mul>
                                                                                          • <Div>

                                                                                          Functions

                                                                                          The <Function> element specifies a filter function to be evaluated. The name attribute gives the function name. The element contains a sequence of zero or more filter expressions providing the function arguments. See the Filter Function Reference for details of the functions provided by GeoServer.

                                                                                          Feature Property Values

                                                                                          The <PropertyName> element allows referring to the value of a given feature attribute. It contains a string specifying the attribute name.

                                                                                          Literals

                                                                                          The <Literal> element allows specifying constant values of numeric, boolean, string, date or geometry type.

                                                                                          "},{"location":"styling/sld/reference/labeling/","title":"Labeling","text":"

                                                                                          This section discusses the details of controlling label placement via the standard SLD options. It also describes a number of GeoServer enhanced options for label placement that provide better cartographic output.

                                                                                          "},{"location":"styling/sld/reference/labeling/#labelplacement","title":"LabelPlacement","text":"

                                                                                          The SLD specification defines two alternative label placement strategies which can be used in the <LabelPlacement> element:

                                                                                          • <PointPlacement> places labels at a single point
                                                                                          • <LinePlacement> places labels along a line
                                                                                          "},{"location":"styling/sld/reference/labeling/#pointplacement","title":"PointPlacement","text":"

                                                                                          When <PointPlacement> is used the geometry is labelled at a single label point. For lines, this point lies at the middle of the visible portion of the line. For polygons, the point is the centroid of the visible portion of the polygon. The position of the label relative to the label point can be controlled by the following sub-elements:

                                                                                          Element Description <AnchorPoint> Determines the placement of the label relative to the label point. Values given as decimals between 0-1. <Displacement> Offsets the label from the anchor point. Values given in pixels. <Rotation> Rotates the label clockwise by a given number of degrees.

                                                                                          The best way to explain these options is with examples.

                                                                                          "},{"location":"styling/sld/reference/labeling/#anchorpoint","title":"AnchorPoint","text":"

                                                                                          The anchor point determines where the label is placed relative to the label point.

                                                                                          <AnchorPoint>\n  <AnchorPointX>\n    0.5\n  </AnchorPointX>\n  <AnchorPointY>\n    0.5\n  </AnchorPointY>\n</AnchorPoint>\n

                                                                                          The anchor point values---listed here as (X, Y) ordered pairs---are specified relative to the bounding box of the label, with values from 0 to 1 inclusive. For example:

                                                                                          • (Default) Bottom left of the box is (0, 0)
                                                                                          • Top right is (1, 1)
                                                                                          • Center is (0.5, 0.5)

                                                                                          So to have the anchor location centered just below the label (label top-centered), use (0.5, 0):

                                                                                          <AnchorPoint>\n  <AnchorPointX>\n    0.5\n  </AnchorPointX>\n  <AnchorPointY>\n    0\n  </AnchorPointY>\n</AnchorPoint>\n

                                                                                          The following examples show how changing the anchor point affects the position of labels:

                                                                                          (0, 0.5) places the label to the right of the label point

                                                                                          (0.5, 0.5) places the center of the label at the label point

                                                                                          (1, 0.5) places the label to the left of the label point

                                                                                          (0.5, 0) places the label horizontally centered above the label point

                                                                                          "},{"location":"styling/sld/reference/labeling/#displacement","title":"Displacement","text":"

                                                                                          Displacement allows fine control of the placement of the label. The displacement values offset the location of the label from the anchor point by a specified number of pixels. The element syntax is:

                                                                                          <Displacement>\n  <DisplacementX>\n     10\n  </DisplacementX>\n  <DisplacementY>\n      0\n  </DisplacementY>\n</Displacement>\n

                                                                                          Examples:

                                                                                          Displacement of X=10 pixels (compare with default anchor point of (X=0, Y=0.5) shown above)

                                                                                          Displacement of Y=-10 pixels (compare with anchor point (X= 0.5, Y=1.0) - not shown)

                                                                                          "},{"location":"styling/sld/reference/labeling/#rotation","title":"Rotation","text":"

                                                                                          The optional <Rotation> element specifies that labels should be rotated clockwise by a given number of degrees

                                                                                          <Rotation>\n  45\n</Rotation>\n

                                                                                          The examples below show how the rotation interacts with anchor points and displacements.

                                                                                          45 degree rotation

                                                                                          45 degree rotation with anchor point (X=0.5, Y=0.5)

                                                                                          45 degree rotation with 40-pixel X displacement

                                                                                          45 degree rotation with 40-pixel Y displacement with anchor point (X=0.5, Y=0.5)

                                                                                          "},{"location":"styling/sld/reference/labeling/#lineplacement","title":"LinePlacement","text":"

                                                                                          To label linear features (such as a road or river), the <LinePlacement> element can be specified. This indicates that the styler should determine the best placement and rotation for the labels along the lines.

                                                                                          The standard SLD LinePlacement element provides one optional sub-element, <PerpendicularOffset>. GeoServer provides much more control over line label placement via vendor-specific options; see below for details.

                                                                                          "},{"location":"styling/sld/reference/labeling/#perpendicularoffset","title":"PerpendicularOffset","text":"

                                                                                          The optional <PerpendicularOffset> element allows you to position a label above or below a line. (This is similar to the <DisplacementY> for label points described above.) The displacement value is specified in pixels. A positive value displaces upwards, a negative value downwards.

                                                                                          <LabelPlacement>\n  <LinePlacement>\n    <PerpendicularOffset>\n       10\n    </PerpendicularOffset>           \n  </LinePlacement>\n</LabelPlacement>\n

                                                                                          Examples:

                                                                                          PerpendicularOffset = 0 (default)

                                                                                          PerpendicularOffset = 10

                                                                                          "},{"location":"styling/sld/reference/labeling/#composing-labels-from-multiple-attributes","title":"Composing labels from multiple attributes","text":"

                                                                                          The <Label> element in <TextSymbolizer> allows mixed content. This means its content can be a mixture of plain text and Filter Expressions. The mix gets interepreted as a concatenation. You can leverage this to create complex labels out of multiple attributes.

                                                                                          For example, if you want both a state name and its abbreviation to appear in a label, you can do the following:

                                                                                          <Label>\n  <ogc:PropertyName>STATE_NAME</ogc:PropertyName> (<ogc:PropertyName>STATE_ABBR</ogc:PropertyName>)\n</Label>\n

                                                                                          and you'll get a label looking like Texas (TX).

                                                                                          If you need to add extra white space or newline, you'll stumble into an XML oddity. The whitespace handling in the Label element is following a XML rule called \"collapse\", in which all leading and trailing whitespaces have to be removed, whilst all whitespaces (and newlines) in the middle of the xml element are collapsed into a single whitespace.

                                                                                          So, what if you need to insert a newline or a sequence of two or more spaces between your property names? Enter CDATA. CDATA is a special XML section that has to be returned to the interpreter as-is, without following any whitespace handling rule. So, for example, if you wanted to have the state abbreviation sitting on the next line you'd use the following:

                                                                                          <Label>\n  <ogc:PropertyName>STATE_NAME</ogc:PropertyName><![CDATA[\n]]>(<ogc:PropertyName>STATE_ABBR</ogc:PropertyName>)\n</Label>\n
                                                                                          "},{"location":"styling/sld/reference/labeling/#geoserver-enhanced-options","title":"GeoServer Enhanced Options","text":"

                                                                                          GeoServer provides a number of label styling options as extensions to the SLD specification. Using these options gives more control over how the map looks, since the SLD standard isn't expressive enough to provide all the options one might want.

                                                                                          These options are specified as subelements of <TextSymbolizer>.

                                                                                          "},{"location":"styling/sld/reference/labeling/#labeling_priority","title":"Priority Labeling","text":"

                                                                                          The optional <Priority> element allows specifying label priority. This controls how conflicts (overlaps) between labels are resolved during rendering. The element content may be an expression to retrieve or calculate a relative priority value for each feature in a layer. Alternatively, the content may be a constant value, to set the priority of a layer's labels relative to other layers on a rendered map.

                                                                                          The default priority for labels is 1000.

                                                                                          Note

                                                                                          Standard SLD Conflict Resolution

                                                                                          If the <Priority> element is not present, or if a group of labels all have the same priority, then standard SLD label conflict resolution is used. Under this strategy, the label to display out of a group of conflicting labels is chosen essentially at random.

                                                                                          For example, take the following dataset of cities:

                                                                                          City Name   | population\n------------+------------\nYonkers     |     197,818\nJersey City |     237,681\nNewark      |     280,123\nNew York    |   8,107,916\n

                                                                                          City locations (large scale map)

                                                                                          More people know where New York City is than where Jersey City is. Thus we want to give the label \"New York\" priority so it will be visible when in conflict with (overlapping) \"Jersey City\". To do this we include the following code in the <TextSymbolizer>:

                                                                                          <Priority>\n    <ogc:PropertyName>population</ogc:PropertyName>\n</Priority>\n

                                                                                          This ensures that at small scales New York is labeled in preference to the less populous cities nearby:

                                                                                          City locations (small scale map)

                                                                                          Without priority labeling, Jersey City could be labeled in preference to New York, making it difficult to interpret the map. At scales showing many features, priority labeling is essential to ensure that larger cities are more visible than smaller cities.

                                                                                          "},{"location":"styling/sld/reference/labeling/#labeling_group","title":"Grouping Features (group)","text":"

                                                                                          The group option allows displaying a single label for multiple features in a logical group.

                                                                                          <VendorOption name=\"group\">yes</VendorOption>\n

                                                                                          Grouping works by collecting all features with the same label text, then choosing a representative geometry for the group, according to the following rules:

                                                                                          Geometry Label Point Point Set The first point inside the view rectangle is used. Line Set Lines are joined together, clipped to the view rectangle, and the longest path is used. Polygon Set Polygons are clipped to the view rectangle, and the largest polygon is used.

                                                                                          If desired the labeller can be forced to label every element in a group by specifying the labelAllGroup option.

                                                                                          Warning

                                                                                          Be careful that the labels truly indicate features that should be grouped together. For example, grouping on city name alone might end up creating a group containing both Paris (France) and Paris (Texas).

                                                                                          Road data is a classic example to show why grouping is useful. It is usually desirable to display only a single label for all of \"Main Street\", not a label for every block of \"Main Street.\"

                                                                                          When the group option is off (the default), grouping is not performed and every block feature is labeled (subject to label deconfliction):

                                                                                          When the group option is used, geometries with the same label are grouped together and the label position is determined from the entire group. This produces a much less cluttered map:

                                                                                          "},{"location":"styling/sld/reference/labeling/#labeling_all_group","title":"labelAllGroup","text":"

                                                                                          The labelAllGroup option can be used in conjunction with the group option (see Grouping Features (group)). It causes all of the disjoint paths in a line group to be labeled, not just the longest one.

                                                                                          <VendorOption name=\"labelAllGroup\">true</VendorOption>\n
                                                                                          "},{"location":"styling/sld/reference/labeling/#labeling_space_around","title":"Overlapping and Separating Labels (spaceAround)","text":"

                                                                                          By default GeoServer will not render labels \"on top of each other\". By using the spaceAround option you can either allow labels to overlap, or add extra space around labels. The value supplied for the option is a positive or negative size, in pixels.

                                                                                          <VendorOption name=\"spaceAround\">10</VendorOption>\n

                                                                                          Using the default value of 0, the bounding box of a label cannot overlap the bounding box of another label:

                                                                                          With a negative spaceAround value, overlapping is allowed:

                                                                                          With a positive spaceAround value of 10, each label is at least 20 pixels apart from others:

                                                                                          Positive spaceAround values actually provide twice the space that you might expect. This is because you can specify a spaceAround for one label as 5, and for another label (in another TextSymbolizer) as 3. The total distance between them is 8. Two labels in the first symbolizer (\"5\") will each be 5 pixels apart from each other, for a total of 10 pixels.

                                                                                          Note

                                                                                          Interaction between values in different TextSymbolizers

                                                                                          You can have multiple TextSymbolizers in your SLD file, each with a different spaceAround option. If all the spaceAround options are >=0, this will do what you would normally expect. If you have negative values ('allow overlap') then these labels can overlap labels that you've said should not be overlapping. If you don't like this behavior, it's not difficult to change - feel free to submit a patch!

                                                                                          "},{"location":"styling/sld/reference/labeling/#labeling_follow_line","title":"followLine","text":"

                                                                                          The followLine option forces a label to follow the curve of the line. To use this option add the following to the <TextSymbolizer>.

                                                                                          Note

                                                                                          Straight Lines

                                                                                          You don't need to use followLine for straight lines. GeoServer will automatically follow the orientation of the line. However in this case followLine can be used to ensure the text isn't rendered if longer than the line.

                                                                                          <VendorOption name=\"followLine\">true</VendorOption>  \n

                                                                                          It is required to use <LinePlacement> along with this option to ensure that labels are placed along lines:

                                                                                          <LabelPlacement>\n  <LinePlacement/>\n</LabelPlacement>\n
                                                                                          "},{"location":"styling/sld/reference/labeling/#labeling_max_displacement","title":"maxDisplacement","text":"

                                                                                          The maxDisplacement option controls the displacement of the label along a line, around a point and inside a polygon.

                                                                                          For lines, normally GeoServer labels a line at its center point only. If this label conflicts with another one it may not be displayed at all. When this option is enabled the labeller will attempt to avoid conflic by using an alternate location within maxDisplacement pixels along the line from the pre-computed label point.

                                                                                          If used in conjunction with repeat, the value for maxDisplacement should always be lower than the value for repeat.

                                                                                          For points this causes the renderer to start circling around the point in search of a empty stop to place the label, step by step increasing the size of the circle until the max displacement is reached. The same happens for polygons, around the polygon labelling point (normally the centroid).

                                                                                          <VendorOption name=\"maxDisplacement\">10</VendorOption> \n
                                                                                          "},{"location":"styling/sld/reference/labeling/#labeling_repeat","title":"repeat","text":"

                                                                                          The repeat option determines how often GeoServer displays labels along a line. Normally GeoServer labels each line only once, regardless of length. Specifying a positive value for this option makes the labeller attempt to draw the label every repeat pixels. For long or complex lines (such as contour lines) this makes labeling more informative.

                                                                                          <VendorOption name=\"repeat\">100</VendorOption>\n
                                                                                          "},{"location":"styling/sld/reference/labeling/#labeling_max_angle_delta","title":"maxAngleDelta","text":"

                                                                                          When used in conjunction with followLine, the maxAngleDelta option sets the maximum angle, in degrees, between two subsequent characters in a curved label. Large angles create either visually disconnected words or overlapping characters. It is advised not to use angles larger than 30.

                                                                                          <VendorOption name=\"maxAngleDelta\">15</VendorOption>\n
                                                                                          "},{"location":"styling/sld/reference/labeling/#labeling_autowrap","title":"autoWrap","text":"

                                                                                          The autoWrap option wraps labels when they exceed the given width (in pixels). The size should be wide enough to accommodate the longest word, otherwise single words will be split over multiple lines.

                                                                                          <VendorOption name=\"autoWrap\">50</VendorOption>\n

                                                                                          Labeling with autoWrap enabled

                                                                                          "},{"location":"styling/sld/reference/labeling/#labeling_force_left_to_right","title":"forceLeftToRight","text":"

                                                                                          The renderer tries to draw labels along lines so that the text is upright, for maximum legibility. This means a label may not follow the line orientation, but instead may be rotated 180\u00b0 to display the text the right way up. In some cases altering the orientation of the label is not desired; for example, if the label is a directional arrow showing the orientation of the line.

                                                                                          The forceLeftToRight option can be set to false to disable label flipping, making the label always follow the inherent orientation of the line being labelled:

                                                                                          <VendorOption name=\"forceLeftToRight\">false</VendorOption>\n
                                                                                          "},{"location":"styling/sld/reference/labeling/#labeling_conflict_resolution","title":"conflictResolution","text":"

                                                                                          By default labels are subject to conflict resolution, meaning the renderer will not allow any label to overlap with a label that has been already drawn. Setting the conflictResolution option to false causes this label to bypass conflict resolution. This means the label will be drawn even if it overlaps with other labels, and other labels drawn after it may overlap it.

                                                                                          <VendorOption name=\"conflictResolution\">false</VendorOption>\n
                                                                                          "},{"location":"styling/sld/reference/labeling/#labeling_goodness_of_fit","title":"goodnessOfFit","text":"

                                                                                          GeoServer will remove labels if they are a particularly bad fit for the geometry they are labeling.

                                                                                          Geometry Goodness of Fit Algorithm Point Always returns 1.0 since the label is at the point Line Always returns 1.0 since the label is always placed on the line. Polygon The label is sampled approximately at every letter. The distance from these points to the polygon is determined and each sample votes based on how close it is to the polygon. (see LabelCacheDefault#goodnessOfFit())

                                                                                          The default value is 0.5, but it can be modified using:

                                                                                          <VendorOption name=\"goodnessOfFit\">0.3</VendorOption>\n
                                                                                          "},{"location":"styling/sld/reference/labeling/#polygonalign","title":"polygonAlign","text":"

                                                                                          GeoServer normally tries to place labels horizontally within a polygon, and gives up if the label position is busy or if the label does not fit enough in the polygon. This option allows GeoServer to try alternate rotations for the labels.

                                                                                          <VendorOption name=\"polygonAlign\">mbr</VendorOption>\n
                                                                                          Option Description manual The default value. Only a rotation manually specified in the <Rotation> tag will be used ortho If the label does not fit horizontally and the polygon is taller than wider then vertical alignment will also be tried mbr If the label does not fit horizontally the minimum bounding rectangle will be computed and a label aligned to it will be tried out as well"},{"location":"styling/sld/reference/labeling/#labeling_graphic_resize","title":"graphic-resize","text":"

                                                                                          When a <Graphic> is specified for a label by default it is displayed at its native size and aspect ratio. The graphic-resize option instructs the renderer to magnify or stretch the graphic to fully contain the text of the label. If this option is used the graphic-margin option may also be specified.

                                                                                          <VendorOption name=\"graphic-resize\">stretch</VendorOption>\n
                                                                                          Option Description none Graphic is displayed at its native size (default) proportional Graphic size is increased uniformly to contain the label text stretch Graphic size is increased anisotropically to contain the label text

                                                                                          no-border

                                                                                          Labeling with a Graphic Mark \"square\" - L) at native size; R) with \"graphic-resize\"=stretch and \"graphic-margin\"=3

                                                                                          "},{"location":"styling/sld/reference/labeling/#labeling_graphic_margin","title":"graphic-margin","text":"

                                                                                          The graphic-margin options specifies a margin (in pixels) to use around the label text when the graphic-resize option is specified.

                                                                                          <VendorOption name=\"graphic-margin\">margin</VendorOption>\n
                                                                                          "},{"location":"styling/sld/reference/labeling/#partials","title":"partials","text":"

                                                                                          The partials options instructs the renderer to render labels that cross the map extent, which are normally not painted since there is no guarantee that a map put on the side of the current one (tiled rendering) will contain the other half of the label. By enabling \"partials\" the style editor takes responsibility for the other half being there (maybe because the label points have been placed by hand and are assured not to conflict with each other, at all zoom levels).

                                                                                          <VendorOption name=\"partials\">true</VendorOption>\n
                                                                                          "},{"location":"styling/sld/reference/labeling/#labeling_underline_text","title":"underlineText","text":"

                                                                                          The underlineText option instruct the renderer to underline labels. The underline will work like a typical word processor text underline. The thickness and position of the underline will be defined by the font and color will be the same as the text. Spaces will also be underlined.

                                                                                          <VendorOption name=\"underlineText\">true</VendorOption>\n

                                                                                          Some underlines examples:

                                                                                          "},{"location":"styling/sld/reference/labeling/#labeling_strikethrough_text","title":"strikethroughText","text":"

                                                                                          The strikethroughText option instruct the renderer to strikethrough labels. The strikethrough will work like a typical word processor text strikethrough. The thickness and position of the line will be defined by the font and color will be the same as the text. Spaces will also be stroken.

                                                                                          <VendorOption name=\"strikethroughText\">true</VendorOption>\n

                                                                                          Some strikethrough examples:

                                                                                          "},{"location":"styling/sld/reference/labeling/#charspacing","title":"charSpacing","text":"

                                                                                          The charSpacing option controls the amount of space between characters, a positive value increases it, a negative value shrinks it (and will eventually make characters overlap). The value is specified in pixels.

                                                                                          <VendorOption name=\"charSpacing\">3</VendorOption>\n

                                                                                          Example of adding 3 extra pixels of space between chars on road names:

                                                                                          "},{"location":"styling/sld/reference/labeling/#wordspacing","title":"wordSpacing","text":"

                                                                                          The wordSpacing option controls the amount of space between words, for this option only positive values (or zero) are accepted. The value is specified in pixels.

                                                                                          <VendorOption name=\"wordSpacing\">5</VendorOption>\n

                                                                                          Example of adding 5 extra pixels of space between words on road names:

                                                                                          "},{"location":"styling/sld/reference/labeling/#displacementmode","title":"displacementMode","text":"

                                                                                          Comma separated list of label displacement directions for point/polygon labels (used along with maxDisplacement). The indicated directions will be tried in turn. Valid values are cardinal directions abbreviations, in particular, N, W, E, S, NW, NE, SW, SE.

                                                                                          The following example sets the typical \"diagonal displacement\" typically used for points:

                                                                                          <VendorOption name=\"displacementMode\">NE, NW, SW, SE</VendorOption>\n

                                                                                          While this one allows displacement only in the vertical direction:

                                                                                          <VendorOption name=\"displacementMode\">N, S</VendorOption>\n
                                                                                          "},{"location":"styling/sld/reference/layers/","title":"Layers","text":"

                                                                                          An SLD document contains a sequence of layer definitions indicating the layers to be styled. Each layer definition is either a NamedLayer reference or a supplied UserLayer.

                                                                                          "},{"location":"styling/sld/reference/layers/#namedlayer","title":"NamedLayer","text":"

                                                                                          A NamedLayer specifies an existing layer to be styled, and the styling to apply to it. The styling may be any combination of catalog styles and explicitly-defined styles. If no style is specified, the default style for the layer is used.

                                                                                          The <NamedLayer> element contains the following elements:

                                                                                          Tag Required? Description <Name> Yes The name of the layer to be styled. (Ignored in catalog styles.) <Description> No The description for the layer. <NamedStyle> 0..N The name of a catalog style to apply to the layer. <UserStyle> 0..N The definition of a style to apply to the layer. See Styles"},{"location":"styling/sld/reference/layers/#userlayer","title":"UserLayer","text":"

                                                                                          A UserLayer defines a new layer to be styled, and the styling to apply to it. The data for the layer is provided directly in the layer definition using the <InlineFeature> element. Since the layer is not known to the server, the styling must be explicitly specified as well.

                                                                                          The <UserLayer> element contains the following elements:

                                                                                          Tag Required? Description <Name> No The name for the layer being defined <Description> No The description for the layer <InlineFeature> No One or more feature collections providing the layer data, specified using GML. <UserStyle> 1..N The definition of the style(s) to use for the layer. See Styles

                                                                                          A common use is to define a geometry to be rendered to indicate an Area Of Interest.

                                                                                          "},{"location":"styling/sld/reference/layers/#sld_reference_inlinefeature","title":"InlineFeature","text":"

                                                                                          An InlineFeature element contains data defining a layer to be styled. The element contains one or more <FeatureCollection> elements defining the data. Each Feature Collection can contain any number of <featureMember> elements, each containing a feature specified using GML markup. The features can contain any type of geometry (point, line or polygon, and collections of these). They may also contain scalar-valued attributes, which can be useful for labelling.

                                                                                          "},{"location":"styling/sld/reference/layers/#example","title":"Example","text":"

                                                                                          The following style specifies a named layer using the default style, and a user-defined layer with inline data and styling. It displays the US States layer, with a labelled red box surrounding the Pacific NW.

                                                                                          <sld:StyledLayerDescriptor xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\"\n   xsi:schemaLocation=\"http://www.opengis.net/sld StyledLayerDescriptor.xsd\"\n   xmlns:gml=\"http://www.opengis.net/gml/3.2\" xmlns:ogc=\"http://www.opengis.net/ogc\"\n   xmlns:sld=\"http://www.opengis.net/sld\" version=\"1.0.0\">\n   <sld:NamedLayer>\n      <sld:Name>usa:states</sld:Name>\n   </sld:NamedLayer>\n   <sld:UserLayer>\n      <sld:Name>Inline</sld:Name>\n      <sld:InlineFeature>\n         <sld:FeatureCollection>\n            <sld:featureMember>\n              <feature>\n                <geometryProperty>\n                  <gml:Polygon>\n                     <gml:outerBoundaryIs>\n                        <gml:LinearRing>\n                           <gml:coordinates>\n           -127.0,51.0 -110.0,51.0 -110.0,41.0 -127.0,41.0 -127.0,51.0   \n                           </gml:coordinates>\n                        </gml:LinearRing>\n                     </gml:outerBoundaryIs>\n                  </gml:Polygon>\n                </geometryProperty>\n                <title>Pacific NW </title>\n              </feature>\n            </sld:featureMember>\n         </sld:FeatureCollection>\n      </sld:InlineFeature>\n      <sld:UserStyle>\n         <sld:FeatureTypeStyle>\n            <sld:Rule>\n              <sld:PolygonSymbolizer>\n                <Stroke>\n                  <CssParameter name=\"stroke\">#FF0000</CssParameter>\n                  <CssParameter name=\"stroke-width\">2</CssParameter>\n                </Stroke>\n              </sld:PolygonSymbolizer>\n              <sld:TextSymbolizer>\n                <sld:Label>\n                  <ogc:PropertyName>title</ogc:PropertyName>\n                </sld:Label>\n                <sld:Fill>\n                  <sld:CssParameter name=\"fill\">#FF0000</sld:CssParameter>\n                </sld:Fill>\n              </sld:TextSymbolizer>\n            </sld:Rule>\n         </sld:FeatureTypeStyle>\n      </sld:UserStyle>\n   </sld:UserLayer>\n</sld:StyledLayerDescriptor>\n
                                                                                          "},{"location":"styling/sld/reference/linesymbolizer/","title":"LineSymbolizer","text":"

                                                                                          A LineSymbolizer styles features as lines. Lines are one-dimensional geometries that have both position and length. Each line is comprised of one or more line segments, and has either two ends or none (if it is closed).

                                                                                          "},{"location":"styling/sld/reference/linesymbolizer/#syntax","title":"Syntax","text":"

                                                                                          A <LineSymbolizer> contains an optional <Geometry> element, and a required <Stroke> element specifying the line symbology.

                                                                                          Tag Required? Description <Geometry> No Specifies the geometry to be rendered. <Stroke> Yes Specifies the styling for the line. <PerpendicularOffset> No Specifies the perpendicular offset for the current line"},{"location":"styling/sld/reference/linesymbolizer/#geometry","title":"Geometry","text":"

                                                                                          The <Geometry> element is optional. If present, it specifies the featuretype property from which to obtain the geometry to style using the PropertyName element. See also Geometry transformations in SLD for GeoServer extensions for specifying geometry.

                                                                                          Any kind of geometry may be styled with a <LineSymbolizer>. Point geometries are treated as lines of zero length, with a horizontal orientation. For polygonal geometries the boundary (or boundaries) are used as the lines, each line being a closed ring with no ends.

                                                                                          "},{"location":"styling/sld/reference/linesymbolizer/#sld_reference_stroke","title":"Stroke","text":"

                                                                                          The <Stroke> element specifies the styling of a line. There are three elements that can be included inside the <Stroke> element.

                                                                                          Tag Required? Description <GraphicFill> No Renders the pixels of the line with a repeated pattern. <GraphicStroke> No Renders the line with a repeated linear graphic. <CssParameter> 0..N Determines the stroke styling parameters."},{"location":"styling/sld/reference/linesymbolizer/#graphicfill","title":"GraphicFill","text":"

                                                                                          The <GraphicFill> element specifies that the pixels of the line are to be filled with a repeating graphic image or symbol. The graphic is specified by a <Graphic> sub-element, which is described in the PointSymbolizer Graphic section.

                                                                                          "},{"location":"styling/sld/reference/linesymbolizer/#sld_reference_linesymbolizer_graphicstroke","title":"GraphicStroke","text":"

                                                                                          The <GraphicStroke> element specifies the line is to be drawn using a repeated graphic image or symbol following the line. The graphic is specified by a <Graphic> sub-element, which is described in the PointSymbolizer Graphic section.

                                                                                          The spacing of the graphic symbol can be specified using the <Size> element in the <Graphic> element, or the <CSSParameter name=\"stroke-dasharray\"> in the Stroke element.

                                                                                          "},{"location":"styling/sld/reference/linesymbolizer/#sld_reference_linesymbolizer_css","title":"CssParameter","text":"

                                                                                          The <CssParameter> elements describe the basic styling of the line. Any number of <CssParameter> elements can be specified.

                                                                                          The name attribute indicates what aspect of styling an element specifies, using the standard CSS/SVG styling model. The content of the element supplies the value of the styling parameter. The value may contain expressions.

                                                                                          The following parameters are supported:

                                                                                          Parameter Required? Description name=\"stroke\" No Specifies the solid color given to the line, in the form #RRGGBB. Default is black (#000000). name=\"stroke-width\" No Specifies the width of the line in pixels. Default is 1. name=\"stroke-opacity\" No Specifies the opacity (transparency) of the line. The value is a number are between 0 (completely transparent) and 1 (completely opaque). Default is 1. name=\"stroke-linejoin\" No Determines how lines are rendered at intersections of line segments. Possible values are mitre (sharp corner), round (rounded corner), and bevel (diagonal corner). Default is mitre. name=\"stroke-linecap\" No Determines how lines are rendered at their ends. Possible values are butt (sharp square edge), round (rounded edge), and square (slightly elongated square edge). Default is butt. name=\"stroke-dasharray\" No Encodes a dash pattern as a series of numbers separated by spaces. Odd-indexed numbers (first, third, etc) determine the length in pxiels to draw the line, and even-indexed numbers (second, fourth, etc) determine the length in pixels to blank out the line. Default is an unbroken line. Starting from version 2.1 dash arrays can be combined with graphic strokes to generate complex line styles with alternating symbols or a mix of lines and symbols. name=\"stroke-dashoffset\" No Specifies the distance in pixels into the dasharray pattern at which to start drawing. Default is 0."},{"location":"styling/sld/reference/linesymbolizer/#perpendicularoffset","title":"PerpendicularOffset","text":"

                                                                                          The <PerpendicularOffset> element is optional. It is native to the SE 1.1 specification, but supported also in SLD 1.0 as a vendor extension.

                                                                                          If present, it makes the renderer draw a line parallel to the original one, at the given distance. When applied on lines, positive values generate a parallel line on the left hand side, negative values on the right hand side. When applied on polygons instead, positive is interpreted as outwards, negative as inwards.

                                                                                          As most properties, <PerpendicularOffset> accepts expressions.

                                                                                          Care should be taken when using it, as it might become a performance bottleneck. When offsetting lines a fast offset algorithm is used, which works well at small distances, but can generate visible artifacts at higher values. When working against polygons the fast offset line algorithm is used up to 3 pixels away from the original geometry, after that a full buffer algorithm is used instead, which always provides correct results, but is significantly more expensive.

                                                                                          "},{"location":"styling/sld/reference/linesymbolizer/#basic-example","title":"Basic Example","text":"

                                                                                          The following symbolizer is taken from the Lines section in the SLD Cookbook.

                                                                                          <LineSymbolizer>\n  <Stroke>\n    <CssParameter name=\"stroke\">#0000FF</CssParameter>\n    <CssParameter name=\"stroke-width\">3</CssParameter>\n    <CssParameter name=\"stroke-dasharray\">5 2</CssParameter>\n  </Stroke>\n</LineSymbolizer>\n

                                                                                          The symbolizer styles a feature as a dashed blue line of width 3 pixels.

                                                                                          Dashed blue line

                                                                                          "},{"location":"styling/sld/reference/linesymbolizer/#offsetting-lines","title":"Offsetting lines","text":"

                                                                                          The following style excerpt generates a solid line, and then a dashed blue line 3 pixels on the left of it.

                                                                                          <LineSymbolizer>\n  <Stroke>\n    <CssParameter name=\"stroke\">#000000</CssParameter>\n    <CssParameter name=\"stroke-width\">2</CssParameter>\n  </Stroke>\n</LineSymbolizer>\n<LineSymbolizer>\n  <Stroke>\n    <CssParameter name=\"stroke\">#0000FF</CssParameter>\n    <CssParameter name=\"stroke-width\">3</CssParameter>\n    <CssParameter name=\"stroke-dasharray\">5 2</CssParameter>\n  </Stroke>\n  <PerpendicularOffset>3</PerpendicularOffset>\n</LineSymbolizer>\n

                                                                                          Left offset dashed line

                                                                                          "},{"location":"styling/sld/reference/linesymbolizer/#offsetting-polygons","title":"Offsetting polygons","text":"

                                                                                          The following style excerpt builds a inward offset line for polygons.

                                                                                          <PolygonSymbolizer>\n  <Stroke>\n    <CssParameter name=\"stroke\">#000000</CssParameter>\n    <CssParameter name=\"stroke-width\">2</CssParameter> \n  </Stroke>\n</PolygonSymbolizer>\n<LineSymbolizer>\n  <Stroke>\n    <CssParameter name=\"stroke\">#AAAAAA</CssParameter>\n    <CssParameter name=\"stroke-width\">3</CssParameter>\n  </Stroke>\n  <PerpendicularOffset>-2</PerpendicularOffset>\n</LineSymbolizer>\n

                                                                                          Inwards offset line

                                                                                          "},{"location":"styling/sld/reference/pointsymbolizer/","title":"PointSymbolizer","text":"

                                                                                          A PointSymbolizer styles features as points. Points are depicted as graphic symbols at a single location on the map.

                                                                                          "},{"location":"styling/sld/reference/pointsymbolizer/#syntax","title":"Syntax","text":"

                                                                                          A <PointSymbolizer> contains an optional <Geometry> element, and a required <Graphic> element specifying the point symbology.

                                                                                          Tag Required? Description <Geometry> No Specifies the geometry to be rendered. <Graphic> Yes Specifies the styling for the point symbol."},{"location":"styling/sld/reference/pointsymbolizer/#geometry","title":"Geometry","text":"

                                                                                          The <Geometry> element is optional. If present, it specifies the featuretype property from which to obtain the geometry to style using a <PropertyName> element. See also Geometry transformations in SLD for GeoServer extensions for specifying geometry.

                                                                                          Any kind of geometry may be styled with a <PointSymbolizer>. For non-point geometries, a representative point is used (such as the centroid of a line or polygon).

                                                                                          "},{"location":"styling/sld/reference/pointsymbolizer/#sld_reference_graphic","title":"Graphic","text":"

                                                                                          Symbology is specified using a <Graphic> element. The symbol is specified by either an <ExternalGraphic> or a <Mark> element. External Graphics are image files (in a format such as PNG or SVG) that contain the shape and color information defining how to render a symbol. Marks are vector shapes whose stroke and fill are defined explicitly in the symbolizer.

                                                                                          There are five possible sub-elements of the <Graphic> element. One of <ExternalGraphic> or <Mark> must be specified; the others are optional.

                                                                                          Tag Required? Description <ExternalGraphic> No (when using <Mark>) Specifies an external image file to use as the symbol. <Mark> No (when using <ExternalGraphic>) Specifies a named shape to use as the symbol. <Opacity> No Specifies the opacity (transparency) of the symbol. Values range from 0 (completely transparent) to 1 (completely opaque). Value may contain expressions. Default is 1 (opaque). <Size> No Specifies the size of the symbol, in pixels. When used with an image file, this specifies the height of the image, with the width being scaled accordingly. if omitted the native symbol size is used. Value may contain expressions. <Rotation> No Specifies the rotation of the symbol about its center point, in decimal degrees. Positive values indicate rotation in the clockwise direction, negative values indicate counter-clockwise rotation. Value may contain expressions. Default is 0."},{"location":"styling/sld/reference/pointsymbolizer/#externalgraphic","title":"ExternalGraphic","text":"

                                                                                          External Graphics are image files (in formats such as PNG or SVG) that contain the shape and color information defining how to render a symbol. For GeoServer extensions for specifying external graphics, see Graphic symbology in GeoServer.

                                                                                          The <ExternalGraphic> element has the sub-elements:

                                                                                          Tag Required? Description <OnlineResource> Yes The xlink:href attribute specifies the location of the image file. The value can be either a URL or a local pathname relative to the SLD directory. The value can contain CQL expressions delimited by ${ }. The attribute xlink:type=\"simple\" is also required. The element does not contain any content. <Format> Yes The MIME type of the image format. Most standard web image formats are supported. Common MIME types are image/png, image/jpeg, image/gif, and image/svg+xml"},{"location":"styling/sld/reference/pointsymbolizer/#mark","title":"Mark","text":"

                                                                                          Marks are predefined vector shapes identified by a well-known name. Their fill and stroke can be defined explicitly in the SLD. For GeoServer extensions for specifying mark symbols, see Graphic symbology in GeoServer.

                                                                                          The <Mark> element has the sub-elements:

                                                                                          Tag Required? Description <WellKnownName> No The name of the shape. Standard SLD shapes are circle, square, triangle, star, cross, or x. Default is square. <Fill> No Specifies how the symbol should be filled (for closed shapes). Options are to use <CssParameter name=\"fill\"> to specify a solid fill color, or using <GraphicFill> for a tiled graphic fill. See the PolygonSymbolizer Fill for the full syntax. <Stroke> No Specifies how the symbol linework should be drawn. Some options are using <CssParameter name=\"stroke\"> to specify a stroke color, or using <GraphicStroke> for a repeated graphic. See the LineSymbolizer Stroke for the full syntax."},{"location":"styling/sld/reference/pointsymbolizer/#example","title":"Example","text":"

                                                                                          The following symbolizer is taken from the Points section in the SLD Cookbook.

                                                                                          <PointSymbolizer>\n  <Graphic>\n    <Mark>\n  <WellKnownName>circle</WellKnownName>\n      <Fill>\n    <CssParameter name=\"fill\">#FF0000</CssParameter>\n  </Fill>\n    </Mark>\n    <Size>6</Size>\n  </Graphic>\n</PointSymbolizer>\n

                                                                                          The symbolizer contains the required <Graphic> element. Inside this element is the <Mark> element and <Size> element, which are the minimum required element inside <Graphic> (when not using the <ExternalGraphic> element). The <Mark> element contains the <WellKnownName> element and a <Fill> element. No other element are required. In summary, this example specifies the following:

                                                                                          1. Features will be rendered as points
                                                                                          2. Points will be rendered as circles
                                                                                          3. Circles will be rendered with a diameter of 6 pixels and filled with the color red

                                                                                          The next example uses an external graphic loaded from the file system:

                                                                                          <PointSymbolizer>\n  <Graphic>\n    <ExternalGraphic>\n      <OnlineResource xlink:type=\"simple\" \n                      xlink:href=\"file:///var/www/htdocs/sun.png\" />\n      <Format>image.png</Format>\n    </ExternalGraphic>\n  </Graphic>\n</PointSymbolizer>\n

                                                                                          For file:// URLs, the file must be readable by the user the GeoServer process is running as. You can also use href:// URLs to reference remote graphics.

                                                                                          Further examples can be found in the Points section of the SLD Cookbook.

                                                                                          "},{"location":"styling/sld/reference/pointsymbolizer/#sld_reference_parameter_expressions","title":"Using expressions in parameter values","text":"

                                                                                          Many SLD parameters allow their values to be of mixed type. This means that the element content can be:

                                                                                          • a constant value expressed as a string
                                                                                          • a filter expression
                                                                                          • any combination of strings and filter expressions.

                                                                                          Using expressions in parameter values provides the ability to determine styling dynamically on a per-feature basis, by computing parameter values from feature properties. Using computed parameters is an alternative to using rules in some situations, and may provide a more compact SLD document.

                                                                                          GeoServer also supports using substitution variables provided in WMS requests. This is described in Variable substitution in SLD.

                                                                                          "},{"location":"styling/sld/reference/polygonsymbolizer/","title":"PolygonSymbolizer","text":"

                                                                                          A PolygonSymbolizer styles features as polygons. Polygons are two-dimensional geometries. They can be depicted with styling for their interior (fill) and their border (stroke). Polygons may contain one or more holes, which are stroked but not filled. When rendering a polygon, the fill is rendered before the border is stroked.

                                                                                          "},{"location":"styling/sld/reference/polygonsymbolizer/#syntax","title":"Syntax","text":"

                                                                                          A <PolygonSymbolizer> contains an optional <Geometry> element, and two elements <Fill> and <Stroke> for specifying styling:

                                                                                          Tag Required? Description <Geometry> No Specifies the geometry to be rendered. <Fill> No Specifies the styling for the polygon interior. <Stroke> No Specifies the styling for the polygon border."},{"location":"styling/sld/reference/polygonsymbolizer/#geometry","title":"Geometry","text":"

                                                                                          The <Geometry> element is optional. If present, it specifies the featuretype property from which to obtain the geometry to style using the PropertyName element. See also Geometry transformations in SLD for GeoServer extensions for specifying geometry.

                                                                                          Any kind of geometry may be styled with a <PolygonSymbolizer>. Point geometries are treated as small orthonormal square polygons. Linear geometries are closed by joining their ends.

                                                                                          "},{"location":"styling/sld/reference/polygonsymbolizer/#stroke","title":"Stroke","text":"

                                                                                          The <Stroke> element specifies the styling for the border of a polygon. The syntax is described in the <LineSymbolizer> Stroke section.

                                                                                          "},{"location":"styling/sld/reference/polygonsymbolizer/#sld_reference_fill","title":"Fill","text":"

                                                                                          The <Fill> element specifies the styling for the interior of a polygon. It can contain the sub-elements:

                                                                                          Tag Required? Description <GraphicFill> No Renders the fill of the polygon with a repeated pattern. <CssParameter> 0..N Specifies parameters for filling with a solid color."},{"location":"styling/sld/reference/polygonsymbolizer/#graphicfill","title":"GraphicFill","text":"

                                                                                          The <GraphicFill> element contains a <Graphic> element, which specifies a graphic image or symbol to use for a repeated fill pattern. The syntax is described in the PointSymbolizer Graphic section.

                                                                                          "},{"location":"styling/sld/reference/polygonsymbolizer/#cssparameter","title":"CssParameter","text":"

                                                                                          The <CssParameter> elements describe the styling of a solid polygon fill. Any number of <CssParameter> elements can be specified.

                                                                                          The name attribute indicates what aspect of styling an element specifies, using the standard CSS/SVG styling model. The content of the element supplies the value of the styling parameter. The value may contain expressions.

                                                                                          The following parameters are supported:

                                                                                          Parameter Required? Description name=\"fill\" No Specifies the fill color, in the form #RRGGBB. Default is grey (#808080). name=\"fill-opacity\" No Specifies the opacity (transparency) of the fill. The value is a decimal number between 0 (completely transparent) and 1 (completely opaque). Default is 1."},{"location":"styling/sld/reference/polygonsymbolizer/#example","title":"Example","text":"

                                                                                          The following symbolizer is taken from the Polygons section in the SLD Cookbook.

                                                                                          <PolygonSymbolizer>\n  <Fill>\n    <CssParameter name=\"fill\">#000080</CssParameter>\n  </Fill>\n</PolygonSymbolizer>\n

                                                                                          This symbolizer contains only a <Fill> element. Inside this element is a <CssParameter> that specifies the fill color for the polygon to be #000080 (a muted blue).

                                                                                          Further examples can be found in the Polygons section of the SLD Cookbook.

                                                                                          "},{"location":"styling/sld/reference/rastersymbolizer/","title":"RasterSymbolizer","text":"

                                                                                          GeoServer supports the ability to display raster data in addition to vector data.

                                                                                          Raster data is not merely a picture, rather it can be thought of as a grid of georeferenced information, much like a graphic is a grid of visual information (with combination of reds, greens, and blues). Unlike graphics, which only contain visual data, each point/pixel in a raster grid can have many different attributes (bands), with possibly none of them having an inherently visual component.

                                                                                          With the above in mind, one needs to choose how to visualize the data, and this, like in all other cases, is done by using an SLD. The analogy to vector data is evident in the naming of the tags used. Vectors, consisting of points, line, and polygons, are styled by using the <PointSymbolizer>, <LineSymbolizer>, and <PolygonSymbolizer> tags. It is therefore not very surprising that raster data is styled with the tag ."},{"location":"styling/sld/reference/rastersymbolizer/#syntax","title":"Syntax","text":"

                                                                                          The following elements can be used inside the <RasterSymbolizer> element.

                                                                                          • <Opacity>
                                                                                          • <ColorMap>
                                                                                          • <ChannelSelection>
                                                                                          • <ContrastEnhancement>
                                                                                          • <ShadedRelief> *
                                                                                          • <OverlapBehavior> *
                                                                                          • <ImageOutline> *

                                                                                          Warning

                                                                                          The starred (*) elements are not yet implemented in GeoServer.

                                                                                          "},{"location":"styling/sld/reference/rastersymbolizer/#opacity","title":"Opacity","text":"

                                                                                          The <Opacity> element sets the transparency level for the entire rendered image. As is standard, the values range from zero (0) to one (1), with zero being transparent, and one being opaque. The syntax is:

                                                                                          <Opacity>0.5</Opacity>\n

                                                                                          where, in this case, the raster is rendered at 50% opacity.

                                                                                          "},{"location":"styling/sld/reference/rastersymbolizer/#colormap","title":"ColorMap","text":"

                                                                                          The <ColorMap> element defines the color values for the pixels of a raster image, as either color gradients, or a mapping of specific values to fixed colors.

                                                                                          A color map is defined by a sequence of <ColorMapEntry> elements. Each <ColorMapEntry> element specifies a color and a quantity attribute. The quantity refers to the value of a raster pixel. The color value is denoted in standard hexadecimal RGB format (#RRGGBB). <ColorMapEntry> elements can also have opacity and label attributes. The opacity attribute overrides the global <Opacity> value. The label attribute is used to provide text for legends. A color map can contain up to 255 <ColorMapEntry> elements.

                                                                                          The simplest <ColorMap> has two color map entries. One specifyies a color for the \"bottom\" of the dataset, and the other specifyies a color for the \"top\" of the dataset. Pixels with values equal to or less than the minimum value are rendered with the bottom color (and opacity). Pixels with values equal to or great than the maximum value are rendered with the top color and opacity. The colors for values in between are automatically interpolated, making creating color gradients easy.

                                                                                          A color map can be refined by adding additional intermediate entries. This is useful if the dataset has discrete values rather than a gradient, or if a multi-colored gradient is desired. One entry is added for each different color to be used, along with the corresponding quantity value.

                                                                                          For example, a simple ColorMap can define a color gradient from color #323232 to color #BBBBBB over quantity values from -300 to 200:

                                                                                          <ColorMap>\n    <ColorMapEntry color=\"#323232\" quantity=\"-300\" label=\"label1\" opacity=\"1\"/>\n    <ColorMapEntry color=\"#BBBBBB\" quantity=\"200\" label=\"label2\" opacity=\"1\"/>\n</ColorMap>\n

                                                                                          A more refined example defines a color gradient from color #FFCC32 through color #BBBBBB, running through color #3645CC and color #CC3636. The bottom color #FFCC32 is defined to be transparent This simulates an alpha channel, since pixels with values of -300 and below will not be rendered. Notice that the default opacity is 1 (opaque) when not specified.

                                                                                          <ColorMap>\n    <ColorMapEntry color=\"#FFCC32\" quantity=\"-300\" label=\"label1\" opacity=\"0\"/>\n    <ColorMapEntry color=\"#3645CC\" quantity=\"0\" label=\"label2\" opacity=\"1\"/>\n    <ColorMapEntry color=\"#CC3636\" quantity=\"100\" label=\"label3\" opacity=\"1\"/>\n    <ColorMapEntry color=\"#BBBBBB\" quantity=\"200\" label=\"label4\" opacity=\"1\"/>\n</ColorMap>\n

                                                                                          GeoServer extends the <ColorMap> element to allow two attributes: type and extended.

                                                                                          "},{"location":"styling/sld/reference/rastersymbolizer/#type","title":"type","text":"

                                                                                          The <ColorMap> type attribute specifies the kind of ColorMap to use. There are three different types of ColorMaps that can be specified: ramp, intervals and values.

                                                                                          type=\"ramp\" is the default ColorMap type. It specifies that colors should be interpolated for values between the color map entries. The result is shown in the following example.

                                                                                          <ColorMap type=\"ramp\">\n        <ColorMapEntry color=\"#EEBE2F\" quantity=\"-300\" label=\"label\" opacity=\"0\"/>\n        <ColorMapEntry color=\"#2851CC\" quantity=\"0\" label=\"values\" opacity=\"1\"/>\n        <ColorMapEntry color=\"#211F1F\" quantity=\"50\" label=\"label\" opacity=\"1\"/>\n        <ColorMapEntry color=\"#EE0F0F\" quantity=\"100\" label=\"label\" opacity=\"1\"/>\n        <ColorMapEntry color=\"#AAAAAA\" quantity=\"200\" label=\"label\" opacity=\"1\"/>\n        <ColorMapEntry color=\"#6FEE4F\" quantity=\"250\" label=\"label\" opacity=\"1\"/>\n        <ColorMapEntry color=\"#3ECC1B\" quantity=\"300\" label=\"label\" opacity=\"1\"/>\n        <ColorMapEntry color=\"#886363\" quantity=\"350\" label=\"label\" opacity=\"1\"/>\n        <ColorMapEntry color=\"#5194CC\" quantity=\"400\" label=\"label\" opacity=\"1\"/>\n        <ColorMapEntry color=\"#2C58DD\" quantity=\"450\" label=\"label\" opacity=\"1\"/>\n        <ColorMapEntry color=\"#DDB02C\" quantity=\"600\" label=\"label\" opacity=\"1\"/>\n</ColorMap>\n

                                                                                          type=\"values\" means that only pixels with the specified entry quantity values are rendered. Pixels with other values are not rendered. Using the example set of color map entries:

                                                                                          <ColorMap type=\"values\">\n        <ColorMapEntry color=\"#EEBE2F\" quantity=\"-300\" label=\"label\" opacity=\"0\"/>\n        ...\n        <ColorMapEntry color=\"#DDB02C\" quantity=\"600\" label=\"label\" opacity=\"1\"/>\n</ColorMap>\n

                                                                                          The result image is:

                                                                                          type=\"intervals\" value means that each interval defined by two entries is rendered using the color of the first (lowest-value) entry. No color interpolation is applied across the intervals. Using the example set of color map entries:

                                                                                          <ColorMap type=\"intervals\" extended=\"true\">\n        <ColorMapEntry color=\"#EEBE2F\" quantity=\"-300\" label=\"label\" opacity=\"0\"/>\n        ...\n        <ColorMapEntry color=\"#DDB02C\" quantity=\"600\" label=\"label\" opacity=\"1\"/>\n</ColorMap>   \n

                                                                                          The result image is:

                                                                                          The color map type is also reflected in the legend graphic. A typical request for a raster legend is (using the forceRule:true option to force output of the color map):

                                                                                          http://localhost:8080/geoserver/wms?REQUEST=GetLegendGraphic&VERSION=1.0.0&&STYLE=raster100&FORMAT=image/png&WIDTH=50&HEIGHT=20&LEGEND_OPTIONS=forceRule:true&LAYER=it.geosolutions:di08032_da\n

                                                                                          The legends returned for the different types are:

                                                                                          "},{"location":"styling/sld/reference/rastersymbolizer/#extended","title":"extended","text":"

                                                                                          The extended attribute specifies whether the color map gradient uses 256 (8-bit) or 65536 (16-bit) colors. The value false (the default) specifies that the color scale is calculated using 8-bit color, and true specifies using 16-bit color.

                                                                                          "},{"location":"styling/sld/reference/rastersymbolizer/#sld_reference_rastersymbolizer_colormap_cql","title":"CQL Expressions","text":"

                                                                                          All of the ColorMapEntry attributes (color, quantity, label and opacity) can be defined using cql expressions, with the \\${...expression...} syntax.

                                                                                          CQL expressions are useful to make the color map dynamic, using values taken from the client:

                                                                                          <ColorMapEntry color=\"#00FF00\" quantity=\"${env('low',3)}\" label=\"Low\" opacity=\"1\"/>\n<ColorMapEntry color=\"#FFFF00\" quantity=\"${env('medium',10)}\" label=\"Medium\" opacity=\"1\"/>\n<ColorMapEntry color=\"#FF0000\" quantity=\"${env('high',1000)}\" label=\"High\" opacity=\"1\"/>\n

                                                                                          In this example quantity values are not fixed, but can be specified by the client using the ENV request parameter:

                                                                                          http://localhost:8080/geoserver/wms?REQUEST=GetMap&VERSION=1.0.0&...&ENV=low:10;medium:100;high:500

                                                                                          For a complete reference of CQL capabilities, see here

                                                                                          "},{"location":"styling/sld/reference/rastersymbolizer/#channelselection","title":"ChannelSelection","text":"

                                                                                          The <ChannelSelection> element specifies how dataset bands are mapped to image color channels. Named dataset bands may be mapped to red, green and blue channels, or a single named band may be mapped to a grayscale channel.

                                                                                          The following example maps source channels 1, 2 and 3 to the red, green, and blue color channels.

                                                                                          <ChannelSelection>\n  <RedChannel>\n        <SourceChannelName>1</SourceChannelName>\n  </RedChannel>\n  <GreenChannel>\n        <SourceChannelName>2</SourceChannelName>\n  </GreenChannel>\n  <BlueChannel>\n        <SourceChannelName>3</SourceChannelName>\n  </BlueChannel>\n</ChannelSelection>\n

                                                                                          The next example shows selecting a single band of an RGB image as a grayscale channel, and re-colorizing it via a ColorMap:

                                                                                          <RasterSymbolizer>\n        <Opacity>1.0</Opacity>\n        <ChannelSelection>\n            <GrayChannel>\n                <SourceChannelName>1</SourceChannelName>\n            </GrayChannel>\n        </ChannelSelection>\n        <ColorMap extended=\"true\">\n            <ColorMapEntry color=\"#0000ff\" quantity=\"3189.0\"/>\n            <ColorMapEntry color=\"#009933\" quantity=\"6000.0\"/>\n            <ColorMapEntry color=\"#ff9900\" quantity=\"9000.0\" />\n            <ColorMapEntry color=\"#ff0000\" quantity=\"14265.0\"/>\n        </ColorMap>\n</RasterSymbolizer>\n

                                                                                          "},{"location":"styling/sld/reference/rastersymbolizer/#channelselection-expressions","title":"ChannelSelection Expressions","text":"

                                                                                          Since the previous approach supports Strings only and therefore is static and not suitable when dealing with multispectral imagery that has more than four bands and hyperspectral imagery (hyperspectral sensors have typically hundreds of bands), a dynamical approach is needed.

                                                                                          By replacing Strings with Expressions in <SourceChannelName>, context free functions like env can be used to indicate which bands are to be used in a particular rendering session.

                                                                                          The following example shows how to set the Red, Green and Blue channels and to map them into the desired bands. Here below, the env function will set, by default in the WMS request, the RedChannel on the second band, the GreenChannel on the fifth band and the BlueChannel on the seventh band.

                                                                                          <RasterSymbolizer>\n<ChannelSelection>\n    <RedChannel>\n    <SourceChannelName>\n        <ogc:Function name=\"env\">\n            <ogc:Literal>B1</ogc:Literal>\n            <ogc:Literal>1</ogc:Literal>\n        </ogc:Function>\n    </SourceChannelName>\n    </RedChannel>\n    <GreenChannel>\n    <SourceChannelName>\n        <ogc:Function name=\"env\">\n            <ogc:Literal>B2</ogc:Literal>\n            <ogc:Literal>2</ogc:Literal>\n        </ogc:Function>\n    </SourceChannelName>\n    </GreenChannel>\n    <BlueChannel>\n    <SourceChannelName>\n        <ogc:Function name=\"env\">\n            <ogc:Literal>B3</ogc:Literal>\n            <ogc:Literal>3</ogc:Literal>\n        </ogc:Function>\n    </SourceChannelName>\n    </BlueChannel>\n</ChannelSelection>\n<RasterSymbolizer>\n

                                                                                          The style Schema supports also the SLD 1.1 and CSS. As a CSS examples:

                                                                                          * { raster-channels: [env('B1','1')] '2' '3'; }\n\n* { raster-channels: @B1(1)  '2' '3';}\n

                                                                                          One can specify the env request parameters in the WMS request to switch the bands and render the raster layer using the desired bands, for example the 4, 2, 3 as the following:

                                                                                          http://localhost:8083/geosolutions/wms?service=WMS&version=1.1.0&request=GetMap&layers=geosolutions:raster_multichannel&styles=&bbox=-180.0,-90.5,180.0,90.5&width=768&height=386&srs=EPSG:4326&format=application/openlayers&env=B1:4;B2:2;B3:3\n

                                                                                          Now let us suppose that we want to work on a single band and to exclude all the remaining bands in order to render a monochromatic raster. As an SLD example:

                                                                                          <RasterSymbolizer>\n  <Opacity>1.0</se:Opacity>\n  <ChannelSelection>\n    <GrayChannel>\n      <SourceChannelName>\n            <Function name=\"env\">\n             <ogc:Literal>B1</ogc:Literal>\n             <ogc:Literal>7</ogc:Literal>\n          </ogc:Function>\n      </SourceChannelName>\n    </GrayChannel>\n  </ChannelSelection>\n</RasterSymbolizer>\n

                                                                                          The Schema above will render the channel \"7\" by default. As before, you can choose to render any channel of the raster by calling the env function in your WMS request and setting the desired band. By adding to the request &env=B1:3 for example:

                                                                                          http://localhost:8083/geoserver/wms?service=WMS&version=1.1.0&request=GetMap&layers=geosolutions:usa&styles=&bbox=-130.85168,20.7052,-62.0054,54.1141&width=768&height=372&srs=EPSG:4326&format=application/openlayers&env=B1:3\n

                                                                                          Finally, you can add a ColorMap on the selected channel as the following:

                                                                                          <RasterSymbolizer>\n <Opacity>1.0</Opacity>\n <ChannelSelection>\n   <GrayChannel>\n     <SourceChannelName>\n        <ogc:Function name=\"env\">\n            <ogc:Literal>B1</ogc:Literal>\n            <ogc:Literal>7</ogc:Literal>\n         </ogc:Function>\n     </SourceChannelName>\n   </GrayChannel>\n </ChannelSelection>\n <ColorMap>\n     <ColorMapEntry color=\"#0000ff\" quantity=\"50.0\"/>\n     <ColorMapEntry color=\"#009933\" quantity=\"100.0\"/>\n     <ColorMapEntry color=\"#ff9900\" quantity=\"150.0\" />\n     <ColorMapEntry color=\"#ff0000\" quantity=\"200.0\"/>\n </ColorMap>\n</RasterSymbolizer>     \n

                                                                                          "},{"location":"styling/sld/reference/rastersymbolizer/#contrastenhancement","title":"ContrastEnhancement","text":"

                                                                                          The <ContrastEnhancement> element is used to adjust the relative brightness of the image data. A <ContrastEnhancement> element can be specified for the entire image, or in individual Channel elements. In this way, different enhancements can be used on each channel.

                                                                                          There are three types of enhancements possible:

                                                                                          • Normalize
                                                                                          • Histogram
                                                                                          • GammaValue

                                                                                          <Normalize> means to expand the contrast so that the minimum quantity is mapped to minimum brightness, and the maximum quantity is mapped to maximum brightness.

                                                                                          <Histogram> is similar to Normalize, but the algorithm used attempts to produce an image with an equal number of pixels at all brightness levels.

                                                                                          <GammaValue> is a scaling factor that adjusts the brightness of the image. A value less than one (1) darkens the image, and a value greater than one (1) brightens it. The default is 1 (no change).

                                                                                          These examples turn on Normalize and Histogram, respectively:

                                                                                          <ContrastEnhancement>\n    <Normalize/>\n</ContrastEnhancement>\n
                                                                                          <ContrastEnhancement>\n    <Histogram/>\n</ContrastEnhancement>\n

                                                                                          This example increases the brightness of the image by a factor of two.

                                                                                          <ContrastEnhancement>\n    <GammaValue>2</GammaValue>\n</ContrastEnhancement>\n

                                                                                          It is also possible to customize Normalize Contrast Enhancement element for the RasterSymbolizer. 3 new VendorOptions are supported:

                                                                                          • ALGORITHM_NAME to control the algorithm to apply
                                                                                          • MIN_VALUE to control the min value for the algorithm
                                                                                          • MAX_VALUE to control the max value for the algorithm

                                                                                          Supported algorithms are:

                                                                                          • StretchToMinimumMaximum it will linearly stretch the source raster by linearly mapping values within the [MIN_VALUE, MAX_VALUE] range to [0,255]. This will also automatically result into a clip of the values outside the specified input range.
                                                                                          • ClipToMinimumMaximum it will result into a clamp operation. Values smaller than MIN_VALUE will be forced to MIN_VALUE. Values greater than MAX_VALUE will be forced to MAX_VALUE. Values in the [MIN_VALUE, MAX_VALUE] range will passthrough unchanged.
                                                                                          • ClipToZero is similar to ClipToMinimumMaximum. However, values outside the [MIN_VALUE, MAX_VALUE] range will be forced to be 0.

                                                                                          Note

                                                                                          The target data type for the stretch algorithm is always byte (this might change in the future). This means that if the MAX_VALUE for the Clip oriented algorithms is greater than 255 an implicit clamp will apply anyway to clamp to 255.

                                                                                          Here below some examples

                                                                                          <ContrastEnhancement>\n  <Normalize>\n   <VendorOption name=\"algorithm\">StretchToMinimumMaximum</VendorOption>\n   <VendorOption name=\"minValue\">50</VendorOption>\n   <VendorOption name=\"maxValue\">100</VendorOption>\n  </Normalize>\n</ContrastEnhancement>\n

                                                                                          This example will apply a Normalized ContrastEnhancement by linearly stretch from pixel values [50, 100] to [0, 255]

                                                                                          <ContrastEnhancement>\n  <Normalize>\n   <VendorOption name=\"algorithm\">ClipToMinimumMaximum</VendorOption>\n   <VendorOption name=\"minValue\">50</VendorOption>\n   <VendorOption name=\"maxValue\">100</VendorOption>\n  </Normalize>\n</ContrastEnhancement>\n
                                                                                          <ContrastEnhancement>\n  <Normalize>\n   <VendorOption name=\"algorithm\">ClipToMinimumMaximum</VendorOption>\n   <VendorOption name=\"minValue\">50</VendorOption>\n   <VendorOption name=\"maxValue\">100</VendorOption>\n  </Normalize>\n</ContrastEnhancement>  \n

                                                                                          Here below a more complex example that shows the possibility to control the values from a client using env functions. This is extremely interesting for interactive applications.

                                                                                          ...\n<ContrastEnhancement>\n    <Normalize>\n     <VendorOption name=\"algorithm\">\n       <ogc:Function name=\"env\">\n         <ogc:Literal>algorithm</ogc:Literal>\n         <ogc:Literal>StretchToMinimumMaximum</ogc:Literal>\n       </ogc:Function>                                       \n     </VendorOption>\n     <VendorOption name='minValue'>\n       <ogc:Function name=\"env\">\n         <ogc:Literal>minValue</ogc:Literal>\n         <ogc:Literal>10</ogc:Literal>\n       </ogc:Function>\n     </VendorOption>\n     <VendorOption name='maxValue'>\n       <ogc:Function name=\"env\">\n         <ogc:Literal>maxValue</ogc:Literal>\n         <ogc:Literal>1200</ogc:Literal>\n       </ogc:Function>                                       \n     </VendorOption>\n    </Normalize>\n</ContrastEnhancement>\n...\n
                                                                                          "},{"location":"styling/sld/reference/rastersymbolizer/#shadedrelief","title":"ShadedRelief","text":"

                                                                                          Warning

                                                                                          Support for this element has not been implemented yet.

                                                                                          The <ShadedRelief> element can be used to create a 3-D effect, by selectively adjusting brightness. This is a nice effect to use on an elevation dataset. There are two types of shaded relief possible.

                                                                                          • BrightnessOnly
                                                                                          • ReliefFactor

                                                                                          BrightnessOnly, which takes no parameters, applies shading in WHAT WAY? ReliefFactor sets the amount of exaggeration of the shading (for example, to make hills appear higher). According to the OGC SLD specification, a value of around 55 gives \"reasonable results\" for Earth-based datasets:

                                                                                          <ShadedRelief>\n    <BrightnessOnly />\n    <ReliefFactor>55</ReliefFactor>\n</ShadedRelief>\n

                                                                                          The above example turns on Relief shading in WHAT WAY?

                                                                                          "},{"location":"styling/sld/reference/rastersymbolizer/#overlapbehavior","title":"OverlapBehavior","text":"

                                                                                          Warning

                                                                                          Support for this element has not been implemented yet.

                                                                                          Sometimes raster data is comprised of multiple image sets. Take, for example, a satellite view of the Earth at night . As all of the Earth can't be in nighttime at once, a composite of multiple images are taken. These images are georeferenced, and pieced together to make the finished product. That said, it is possible that two images from the same dataset could overlap slightly, and the OverlapBehavior element is designed to determine how this is handled. There are four types of OverlapBehavior:

                                                                                          • AVERAGE
                                                                                          • RANDOM
                                                                                          • LATEST_ON_TOP
                                                                                          • EARLIEST_ON_TOP

                                                                                          AVERAGE takes each overlapping point and displays their average value. RANDOM determines which image gets displayed according to chance (which can sometimes result in a crisper image). LATEST_ON_TOP and EARLIEST_ON_TOP sets the determining factor to be the internal timestamp on each image in the dataset. None of these elements have any parameters, and are all called in the same way:

                                                                                          <OverlapBehavior>\n    <AVERAGE />\n</OverlapBehavior>\n

                                                                                          The above sets the OverlapBehavior to AVERAGE.

                                                                                          "},{"location":"styling/sld/reference/rastersymbolizer/#imageoutline","title":"ImageOutline","text":"

                                                                                          Warning

                                                                                          Support for this element has not been implemented yet.

                                                                                          Given the situation mentioned previously of the image composite, it is possible to style each image so as to have an outline. One can even set a fill color and opacity of each image; a reason to do this would be to \"gray-out\" an image. To use ImageOutline, you would define a or inside of the element:

                                                                                          <ImageOutline>\n    <LineSymbolizer>\n        <Stroke>\n                <CssParameter name=\"stroke\">#0000ff</CssParameter>\n        </Stroke>\n    </LineSymbolizer>\n</ImageOutline>\n

                                                                                          The above would create a border line (colored blue with a one pixel default thickness) around each image in the dataset.

                                                                                          "},{"location":"styling/sld/reference/rules/","title":"Rules","text":"

                                                                                          Styling rules define the portrayal of features. A rule combines a filter with any number of symbolizers. Features for which the filter condition evaluates as true are rendered using the symbolizers in the rule.

                                                                                          "},{"location":"styling/sld/reference/rules/#syntax","title":"Syntax","text":"

                                                                                          The <Rule> element contains the following elements:

                                                                                          Tag Required? Description <Name> No Specifies a name for the rule. <Title> No Specifies a title for the rule. The title is used in display lists and legends. <Abstract> No Specifies an abstract describing the rule. <Filter> No Specifies a filter controlling when the rule is applied. See Filters <MinScaleDenominator> No Specifies the minimum scale denominator (inclusive) for the scale range in which this rule applies. If present, the rule applies at the given scale and all smaller scales. <MaxScaleDenominator> No Specifies the maximum scale denominator (exclusive) for the scale range in which this rule applies. If present, the rule applies at scales larger than the given scale. <PointSymbolizer> 0..N Specifies styling as points. See PointSymbolizer <LineSymbolizer> 0..N Specifies styling as lines. See LineSymbolizer <PolygonSymbolizer> 0..N Specifies styling as polygons. See PolygonSymbolizer <TextSymbolizer> 0..N Specifies styling for text labels. See TextSymbolizer <RasterSymbolizer> 0..N Specifies styling for raster data. See RasterSymbolizer"},{"location":"styling/sld/reference/rules/#scale-selection","title":"Scale Selection","text":"

                                                                                          Rules support scale selection to allow specifying the scale range in which a rule may be applied (assuming the filter condition is satisfied as well, if present). Scale selection allows for varying portrayal of features at different map scales. In particular, at smaller scales it is common to use simpler styling for features, or even prevent the display of some features altogether.

                                                                                          Scale ranges are specified by using scale denominators. These values correspond directly to the ground distance covered by a map, but are inversely related to the common \"large\" and \"small\" terminology for map scale. In other words:

                                                                                          • large scale maps cover less area and have a smaller scale denominator
                                                                                          • small scale maps cover more area and have a larger scale denominator

                                                                                          Two optional elements specify the scale range for a rule:

                                                                                          Tag Required? Description <MinScaleDenominator> No Specifies the minimum scale denominator (inclusive) for the scale range in which this rule applies. If present, the rule applies at the given scale and all smaller scales. <MaxScaleDenominator> No Specifies the maximum scale denominator (exclusive) for the scale range in which this rule applies. If present, the rule applies at scales larger than the given scale.

                                                                                          Note

                                                                                          The current scale can also be obtained via the wms_scale_denominator SLD environment variable. This allows including scale dependency in Filter Expressions.

                                                                                          The following example shows the use of scale selection in a pair of rules. The rules specify that:

                                                                                          • at scales above 1:20,000 (larger scales, with scale denominators smaller than 20,000) features are symbolized with 10-pixel red squares,
                                                                                          • at scales at or below 1:20,000 (smaller scales, with scale denominators larger than 20,000) features are symbolized with 4-pixel blue triangles.
                                                                                          <Rule>\n   <MaxScaleDenominator>20000</MaxScaleDenominator>\n   <PointSymbolizer>\n     <Graphic>\n       <Mark>\n         <WellKnownName>square</WellKnownName>\n         <Fill><CssParameter name=\"fill\">#FF0000</CssParameter>\n       </Mark>\n       <Size>10</Size>\n     </Graphic>\n   </PointSymbolizer>\n</Rule>\n<Rule>\n   <MinScaleDenominator>20000</MinScaleDenominator>\n   <PointSymbolizer>\n     <Graphic>\n       <Mark>\n         <WellKnownName>triangle</WellKnownName>\n         <Fill><CssParameter name=\"fill\">#0000FF</CssParameter>\n       </Mark>\n       <Size>4</Size>\n     </Graphic>\n   </PointSymbolizer>\n</Rule>\n
                                                                                          "},{"location":"styling/sld/reference/rules/#evaluation-order","title":"Evaluation Order","text":"

                                                                                          Within an SLD document each <FeatureTypeStyle> can contain many rules. Multiple-rule SLDs are the basis for thematic styling. In GeoServer each <FeatureTypeStyle> is evaluated once for each feature processed. The rules within it are evaluated in the order they occur. A rule is applied when its filter condition (if any) is true for a feature and the rule is enabled at the current map scale. The rule is applied by rendering the feature using each symbolizer within the rule, in the order in which they occur. The rendering is performed into the image buffer for the parent <FeatureTypeStyle>. Thus symbolizers earlier in a FeatureTypeStyle and Rule are rendered before symbolizers occurring later in the document (this is the \"Painter's Model\" method of rendering).

                                                                                          "},{"location":"styling/sld/reference/rules/#examples","title":"Examples","text":"

                                                                                          The following rule applies only to features which have a POPULATION attribute greater than 100,000, and symbolizes the features as red points.

                                                                                          <Rule>\n   <ogc:Filter>\n     <ogc:PropertyIsGreaterThan>\n       <ogc:PropertyName>POPULATION</ogc:PropertyName>\n       <ogc:Literal>100000</ogc:Literal>\n     </ogc:PropertyIsGreaterThan>\n   </ogc:Filter>\n   <PointSymbolizer>\n     <Graphic>\n       <Mark>\n         <Fill><CssParameter name=\"fill\">#FF0000</CssParameter>\n       </Mark>\n     </Graphic>\n   </PointSymbolizer>\n</Rule>\n

                                                                                          An additional rule can be added which applies to features whose POPULATION attribute is less than 100,000, and symbolizes them as green points.

                                                                                          <Rule>\n  <ogc:Filter>\n    <ogc:PropertyIsLessThan>\n      <ogc:PropertyName>POPULATION</ogc:PropertyName>\n      <ogc:Literal>100000</ogc:Literal>\n    </ogc:PropertyIsLessThan>\n  </ogc:Filter>\n  <PointSymbolizer>\n    <Graphic>\n      <Mark>\n        <Fill><CssParameter name=\"fill\">#0000FF</CssParameter>\n      </Mark>\n    </Graphic>\n  </PointSymbolizer>\n</Rule>\n
                                                                                          "},{"location":"styling/sld/reference/sld/","title":"StyledLayerDescriptor","text":"

                                                                                          The root element for an SLD is <StyledLayerDescriptor>. It contains a sequence of Layers defining the styled map content.

                                                                                          The <StyledLayerDescriptor> element contains the following elements:

                                                                                          Tag Required? Description <NamedLayer> 0..N A reference to a named layer in the server catalog <UserLayer> 0..N A layer defined in the style itself"},{"location":"styling/sld/reference/styles/","title":"Styles","text":"

                                                                                          The style elements specify the styling to be applied to a layer.

                                                                                          "},{"location":"styling/sld/reference/styles/#userstyle","title":"UserStyle","text":"

                                                                                          The UserStyle element defines styling for a layer.

                                                                                          The <UserStyle> element contains the following elements:

                                                                                          Tag Required? Description <Name> No The name of the style, used to reference it externally. (Ignored for catalog styles.) <Title> No The title of the style. <Abstract> No The description for the style. <IsDefault> No Whether the style is the default one for a named layer. Used in SLD Library Mode. Values are 1 or 0 (default). <FeatureTypeStyle> 1..N Defines the symbology for rendering a single feature type."},{"location":"styling/sld/reference/styles/#featuretypestyle","title":"FeatureTypeStyle","text":"

                                                                                          The FeatureTypeStyle element specifies the styling that is applied to a single feature type of a layer. It contains a list of rules which determine the symbology to be applied to each feature of a layer.

                                                                                          The <FeatureTypeStyle> element contains the following elements:

                                                                                          Tag Required? Description <Name> No Not used at present <Title> No The title for the style. <Abstract> No The description for the style. <FeatureTypeName> No Identifies the feature type the style is to be applied to. Omitted if the style applies to all features in a layer. <Rule> 1..N A styling rule to be evaluated. See Rules

                                                                                          Usually a layer contains only a single feature type, so the <FeatureTypeName> is omitted.

                                                                                          Any number of <FeatureTypeStyle> elements can be specified in a style. In GeoServer each one is rendered into a separate image buffer. After all features are rendered the buffers are composited to form the final layer image. The compositing is done in the order the FeatureTypeStyles are given in the SLD, with the first one on the bottom (the \"Painter's Model\"). This effectively creates \"virtual layers\", which can be used to achieve styling effects such as cased lines.

                                                                                          "},{"location":"styling/sld/reference/textsymbolizer/","title":"TextSymbolizer","text":"

                                                                                          A TextSymbolizer styles features as text labels. Text labels are positioned either at points or along linear paths derived from the geometry being labelled.

                                                                                          Labelling is a complex operation, and effective labelling is crucial to obtaining legible and visually pleasing cartographic output. For this reason SLD provides many options to control label placement. To improve quality even more GeoServer provides additional options and parameters. The usage of the standard and extended options are described in greater detail in the following section on Labeling.

                                                                                          "},{"location":"styling/sld/reference/textsymbolizer/#syntax","title":"Syntax","text":"

                                                                                          A <TextSymbolizer> contains the following elements:

                                                                                          Tag Required? Description <Geometry> No The geometry to be labelled. <Label> No The text content for the label. <Font> No The font information for the label. <LabelPlacement> No Sets the position of the label relative to its associated geometry. <Halo> No Creates a colored background around the label text, for improved legibility. <Fill> No The fill style of the label text. <Graphic> No A graphic to be displayed behind the label text. See Graphic for content syntax. <Priority> No The priority of the label during conflict resolution. Content may contains expressions. See also Priority Labeling. <VendorOption> 0..N A GeoServer-specific option. See Labeling for descriptions of the available options. Any number of options may be specified."},{"location":"styling/sld/reference/textsymbolizer/#geometry","title":"Geometry","text":"

                                                                                          The <Geometry> element is optional. If present, it specifies the featuretype property from which to obtain the geometry to label, using a <PropertyName> element. See also Geometry transformations in SLD for GeoServer extensions for specifying geometry.

                                                                                          Any kind of geometry may be labelled with a <TextSymbolizer>. For non-point geometries, a representative point is used (such as the centroid of a line or polygon).

                                                                                          "},{"location":"styling/sld/reference/textsymbolizer/#label","title":"Label","text":"

                                                                                          The <Label> element specifies the text that will be rendered as the label. It allows content of mixed type, which means that the content can be a mixture of string data and Filter Expressions. These are concatenated to form the final label text. If a label is provided directly by a feature property, the content is a single <PropertyName>. Multiple properties can be included in the label, and property values can be manipulated by filter expressions and functions. Additional \"boilerplate\" text can be provided as well. Whitespace can be preserved by surrounding it with XML <![CDATA[ ]]> delimiters.

                                                                                          If this element is omitted, no label is rendered.

                                                                                          "},{"location":"styling/sld/reference/textsymbolizer/#font","title":"Font","text":"

                                                                                          The <Font> element specifies the font to be used for the label. A set of <CssParameter> elements specify the details of the font.

                                                                                          The name attribute indicates what aspect of the font is described, using the standard CSS/SVG font model. The content of the element supplies the value of the font parameter. The value may contain expressions.

                                                                                          Parameter Required? Description name=\"font-family\" No The family name of the font to use for the label. Default is Times. name=\"font-style\" No The style of the font. Options are normal, italic, and oblique. Default is normal. name=\"font-weight\" No The weight of the font. Options are normal and bold. Default is normal. name=\"font-size\" No The size of the font in pixels. Default is 10."},{"location":"styling/sld/reference/textsymbolizer/#labelplacement","title":"LabelPlacement","text":"

                                                                                          The <LabelPlacement> element specifies the placement of the label relative to the geometry being labelled. There are two possible sub-elements: <PointPlacement> or <LinePlacement>. Exactly one of these must be specified.

                                                                                          Tag Required? Description <PointPlacement> No Labels a geometry at a single point <LinePlacement> No Labels a geometry along a linear path"},{"location":"styling/sld/reference/textsymbolizer/#pointplacement","title":"PointPlacement","text":"

                                                                                          The <PointPlacement> element indicates the label is placed at a labelling point derived from the geometry being labelled. The position of the label relative to the labelling point may be controlled by the following sub-elements:

                                                                                          Tag Required? Description <AnchorPoint> No The location within the label bounding box that is aligned with the label point. The location is specified by <AnchorPointX> and <AnchorPointY> sub-elements, with values in the range [0..1]. Values may contain expressions. <Displacement> No Specifies that the label point should be offset from the original point. The offset is specified by <DisplacementX> and <DisplacementY> sub-elements, with values in pixels. Values may contain expressions. Default is (0, 0). <Rotation> No The rotation of the label in clockwise degrees (negative values are counterclockwise). Value may contain expressions. Default is 0.

                                                                                          The anchor point justification, displacement offsetting, and rotation are applied in that order.

                                                                                          "},{"location":"styling/sld/reference/textsymbolizer/#lineplacement","title":"LinePlacement","text":"

                                                                                          The <LinePlacement> element indicates the label is placed along a linear path derived from the geometry being labelled. The position of the label relative to the linear path may be controlled by the following sub-element:

                                                                                          Tag Required? Description <PerpendicularOffset> No The offset from the linear path, in pixels. Positive values offset to the left of the line, negative to the right. Value may contain expressions. Default is 0.

                                                                                          The appearance of text along linear paths can be further controlled by the vendor options followLine, maxDisplacement, repeat, labelAllGroup, and maxAngleDelta. These are described in Labeling.

                                                                                          "},{"location":"styling/sld/reference/textsymbolizer/#halo","title":"Halo","text":"

                                                                                          A halo creates a colored background around the label text, which improves readability in low contrast situations. Within the <Halo> element there are two sub-elements which control the appearance of the halo:

                                                                                          Tag Required? Description <Radius> No The halo radius, in pixels. Value may contain expressions. Default is 1. <Fill> No The color and opacity of the halo via CssParameter elements for fill and fill-opacity. See Fill for full syntax. The parameter values may contain expressions. Default is a white fill (#FFFFFF) at 100% opacity."},{"location":"styling/sld/reference/textsymbolizer/#fill","title":"Fill","text":"

                                                                                          The <Fill> element specifies the fill style for the label text. The syntax is the same as that of the PolygonSymbolizer Fill element. The default fill color is black (#FFFFFF) at 100% opacity..

                                                                                          "},{"location":"styling/sld/reference/textsymbolizer/#graphic","title":"Graphic","text":"

                                                                                          The <Graphic> element specifies a graphic symbol to be displayed behind the label text (if any). A classic use for this is to display \"highway shields\" behind road numbers provided by feature attributes. The element content has the same syntax as the <PointSymbolizer> Graphic element. Graphics can be provided by internal mark symbols, or by external images or SVG files. Their size and aspect ratio can be changed to match the text displayed with them by using the vendor options graphic-resize and graphic-margin.

                                                                                          "},{"location":"styling/sld/reference/textsymbolizer/#example","title":"Example","text":"

                                                                                          The following symbolizer is taken from the Points section in the SLD Cookbook.

                                                                                          <TextSymbolizer>\n  <Label>\n    <ogc:PropertyName>name</ogc:PropertyName>\n  </Label>\n  <Font>\n    <CssParameter name=\"font-family\">Arial</CssParameter>\n    <CssParameter name=\"font-size\">12</CssParameter>\n    <CssParameter name=\"font-style\">normal</CssParameter>\n    <CssParameter name=\"font-weight\">bold</CssParameter>\n  </Font>\n  <LabelPlacement>\n    <PointPlacement>\n      <AnchorPoint>\n        <AnchorPointX>0.5</AnchorPointX>\n        <AnchorPointY>0.0</AnchorPointY>\n      </AnchorPoint>\n      <Displacement>\n        <DisplacementX>0</DisplacementX>\n        <DisplacementY>25</DisplacementY>\n      </Displacement>\n      <Rotation>-45</Rotation>\n    </PointPlacement>\n  </LabelPlacement>\n  <Fill>\n    <CssParameter name=\"fill\">#990099</CssParameter>\n  </Fill>\n</TextSymbolizer>\n

                                                                                          The symbolizer labels features with the text from the name property. The font is Arial in bold at 12 pt size, filled in purple. The labels are centered on the point along their lower edge, then displaced 25 pixels upwards, and finally rotated 45 degrees counterclockwise.

                                                                                          The displacement takes effect before the rotation during rendering, so the 25 pixel vertical displacement is itself rotated 45 degrees.

                                                                                          Point with rotated label

                                                                                          "},{"location":"styling/sld/reference/textsymbolizer/#scalable-font-size","title":"Scalable Font Size","text":"

                                                                                          The font size can also be set depending on the scale denominator as follows:

                                                                                          <CssParameter name=\"font-size\">\n  <ogc:Function name=\"Categorize\">\n    <!-- Value to transform -->\n    <ogc:Function name=\"env\">\n      <ogc:Literal>wms_scale_denominator</ogc:Literal>\n    </ogc:Function>\n    <!-- Output values and thresholds -->\n    <!-- Ranges: -->\n    <!-- [scale <= 300, font 12] -->\n    <!-- [scale 300 - 2500, font 10] -->\n    <!-- [scale > 2500, font 8] -->\n    <ogc:Literal>12</ogc:Literal>\n    <ogc:Literal>300</ogc:Literal>\n    <ogc:Literal>10</ogc:Literal>\n    <ogc:Literal>2500</ogc:Literal>\n    <ogc:Literal>8</ogc:Literal>\n  </ogc:Function>\n</CssParameter>\n

                                                                                          The above example would display text at different sizes depending on the scale denominator setting. A font size of 12 for scale denominator of less than or equal to 300, a font size of 10 for scale denominator from 300-2500 and a font size of 8 for scale denominator greater than 2500.

                                                                                          "},{"location":"styling/sld/tipstricks/","title":"SLD Tips and Tricks","text":"

                                                                                          This section details various advanced strategies for working with SLD.

                                                                                          • Styling mixed geometry types
                                                                                          • Styling using Transformation Functions
                                                                                          "},{"location":"styling/sld/tipstricks/mixed-geometries/","title":"Styling mixed geometry types","text":"

                                                                                          On occasion one might need to style a geometry column whose geometry type can be different for each feature (some are polygons, some are points, etc), and use different styling for different geometry types.

                                                                                          SLD 1.0 does not provide a clean solution for dealing with this situation. Point, Line, and Polygon symbolizers do not select geometry by type, since each can apply to all geometry types:

                                                                                          • Point symbolizers apply to any kind of geometry. If the geometry is not a point, the centroid of the geometry is used.
                                                                                          • Line symbolizers apply to both lines and polygons. For polygons the boundary is styled.
                                                                                          • Polygon symbolizers apply to lines, by adding a closing segment connecting the first and last points of the line.

                                                                                          There is also no standard filter predicate to identify geometry type which could be used in rules.

                                                                                          This section suggests a number of ways to accomplish styling by geometry type. They require either data restructuring or the use of non-standard filter functions.

                                                                                          "},{"location":"styling/sld/tipstricks/mixed-geometries/#restructuring-the-data","title":"Restructuring the data","text":"

                                                                                          There are a few ways to restructure the data so that it can be styled by geometry type using only standard SLD constructs.

                                                                                          "},{"location":"styling/sld/tipstricks/mixed-geometries/#split-the-table","title":"Split the table","text":"

                                                                                          The first and obvious one is to split the original table into a set of separate tables, each one containing a single geometry type. For example, if table findings has a geometry column that can contain point, lines, and polygons, three tables can be created, each one containing a single geometry type.

                                                                                          "},{"location":"styling/sld/tipstricks/mixed-geometries/#separate-geometry-columns","title":"Separate geometry columns","text":"

                                                                                          A second way is to use one table and separate geometry columns. So, if the table findings has a geom column, the restructured table will have point, line and polygon columns, each of them containing just one geometry type. After the restructuring, the symbolizers will refer to a specific geometry, for example:

                                                                                          <PolygonSymbolizer>\n    <Geometry><ogc:PropertyName>polygon</ogc:PropertyName></Geometry>\n</PolygonSymbolizer>\n

                                                                                          This way each symbolizer will match only the geometry types it is supposed to render, and skip over the rows that contain a null value.

                                                                                          "},{"location":"styling/sld/tipstricks/mixed-geometries/#add-a-geometry-type-column","title":"Add a geometry type column","text":"

                                                                                          A third way is to add a geometry type column allowing standard filtering constructs to be used, and then build a separate rule per geometry type. In the example above a new attribute, gtype will be added containing the values Point, Line and Polygon. The following SLD template can be used after the change:

                                                                                          <Rule>\n   <ogc:Filter>\n      <ogc:PropertyIsEqualTo>\n         <ogc:PropertyName>gtype</ogc:PropertyName>\n         <ogc:Literal>Point</ogc:Literal>\n      </ogc:PropertyIsEqualTo>\n   </ogc:Filter>\n   <PointSymbolizer>\n      ...\n   </PointSymbolizer>\n</Rule>\n<Rule>\n   <ogc:Filter>\n      <ogc:PropertyIsEqualTo>\n         <ogc:PropertyName>gtype</ogc:PropertyName>\n         <ogc:Literal>Line</ogc:Literal>\n      </ogc:PropertyIsEqualTo>\n   </ogc:Filter>\n   <LineSymbolizer>\n      ...\n   </LineSymbolizer>\n</Rule>\n<Rule>\n   <ogc:Filter>\n      <ogc:PropertyIsEqualTo>\n         <ogc:PropertyName>gtype</ogc:PropertyName>\n         <ogc:Literal>Polygon</ogc:Literal>\n      </ogc:PropertyIsEqualTo>\n   </ogc:Filter>\n   <PolygonSymbolizer>\n      ...\n   </PolygonSymbolizer>\n</Rule>\n

                                                                                          The above suggestions assume that restructuring the data is technically possible. This is usually true in spatial databases that provide functions that allow determining the geometry type.

                                                                                          "},{"location":"styling/sld/tipstricks/mixed-geometries/#create-views","title":"Create views","text":"

                                                                                          A less invasive way to get the same results without changing the structure of the table is to create views that have the required structure. This allows the original data to be kept intact, and the views may be used for rendering.

                                                                                          "},{"location":"styling/sld/tipstricks/mixed-geometries/#using-sld-rules-and-filter-functions","title":"Using SLD rules and filter functions","text":"

                                                                                          SLD 1.0 uses the OGC Filter 1.0 specification for filtering out the data to be styled by each rule. Filters can contain Filter functions to compute properties of geometric values. In GeoServer, filtering by geometry type can be done using the geometryType or dimension filter functions.

                                                                                          Note

                                                                                          The Filter Encoding specification provides a standard syntax for filter functions, but does not mandate a specific set of functions. SLDs using these functions may not be portable to other styling software.

                                                                                          "},{"location":"styling/sld/tipstricks/mixed-geometries/#geometrytype-function","title":"geometryType function","text":"

                                                                                          The geometryType function takes a geometry property and returns a string, which (currently) is one of the values Point, LineString, LinearRing, Polygon, MultiPoint, MultiLineString, MultiPolygon and GeometryCollection.

                                                                                          Using this function, a Rule matching only single points can be written as:

                                                                                          <Rule>\n   <ogc:PropertyIsEqualTo>\n      <ogc:Function name=\"geometryType\">\n         <ogc:PropertyName>geom</ogc:PropertyName>\n      </ogc:Function>\n      <ogc:Literal>Point</ogc:Literal>\n   </ogc:PropertyIsEqualTo>\n   <PointSymbolizer>\n     ...\n   </PointSymbolizer>\n</Rule>\n

                                                                                          The filter is more complex if it has to match all linear geometry types. In this case, it looks like:

                                                                                          <Rule>\n   <ogc:Filter>\n     <ogc:PropertyIsEqualTo>\n       <ogc:Function name=\"in3\">\n          <ogc:Function name=\"geometryType\">\n              <ogc:PropertyName>geom</ogc:PropertyName>\n          </ogc:Function>\n          <ogc:Literal>LineString</ogc:Literal>\n          <ogc:Literal>LinearRing</ogc:Literal>\n          <ogc:Literal>MultiLineString</ogc:Literal>\n       </ogc:Function>\n       <ogc:Literal>true</ogc:Literal>\n     </ogc:PropertyIsEqualTo>\n   </ogc:Filter>\n   <LineSymbolizer>\n     ...\n   </LineSymbolizer>\n</Rule>\n

                                                                                          This filter is read as geometryType(geom) in (\"LineString\", \"LinearRing\", \"MultiLineString\"). Filter functions in Filter 1.0 have a fixed number of arguments, so there is a series of in functions whose names correspond to the number of arguments they accept: in2, in3, ..., in10.

                                                                                          "},{"location":"styling/sld/tipstricks/mixed-geometries/#dimension-function","title":"dimension function","text":"

                                                                                          A slightly simpler alternative is to use the geometry dimension function to select geometries of a desired dimension. Dimension 0 selects Points and MultiPoints, dimension 1 selects LineStrings, LinearRings and MultiLineStrings, and dimension 2 selects Polygons and MultiPolygons. The following example shows how to select linear geometries:

                                                                                          <Rule>\n   <ogc:PropertyIsEqualTo>\n      <ogc:Function name=\"dimension\">\n         <ogc:PropertyName>geom</ogc:PropertyName>\n      </ogc:Function>\n      <ogc:Literal>1</ogc:Literal>\n   </ogc:PropertyIsEqualTo>\n   <LineSymbolizer>\n     ...\n   </LineSymbolizer>\n</Rule>\n
                                                                                          "},{"location":"styling/sld/tipstricks/transformation-func/","title":"Styling using Transformation Functions","text":"

                                                                                          The Symbology Encoding 1.1 specification defines the following transformation functions:

                                                                                          • Recode transforms a set of discrete attribute values into another set of values
                                                                                          • Categorize transforms a continuous-valued attribute into a set of discrete values
                                                                                          • Interpolate transforms a continuous-valued attribute into another continuous range of values

                                                                                          These functions provide a concise way to compute styling parameters from feature attribute values. GeoServer implements them as Filter functions with the same names.

                                                                                          Note

                                                                                          The GeoServer function syntax is slightly different to the SE 1.1 definition, since the specification defines extra syntax elements which are not available in GeoServer functions.

                                                                                          These functions can make style documents more concise, since they express logic which would otherwise require many separate rules or complex Filter expressions, They even allow logic which is impossible to express any other way. A further advantage is that they often provide superior performance to explicit rules.

                                                                                          One disadvantage of using these functions for styling is that they are not displayed in WMS legend graphics.

                                                                                          "},{"location":"styling/sld/tipstricks/transformation-func/#recode","title":"Recode","text":"

                                                                                          The Recode filter function transforms a set of discrete values for an attribute into another set of values. The function can be used within SLD styling parameters to convert the value of a feature attribute into specific values for a parameter such as color, size, width, opacity, etc.

                                                                                          The recoding is defined by a set of (input, output) value pairs.

                                                                                          "},{"location":"styling/sld/tipstricks/transformation-func/#example","title":"Example","text":"

                                                                                          Consider a chloropleth map of the US states dataset using the fill color to indicate the topographic regions for the states. The dataset has an attribute SUB_REGION containing the region code for each state. The Recode function is used to map each region code into a different color.

                                                                                          The symbolizer for this style is:

                                                                                          <PolygonSymbolizer>\n   <Fill>\n     <CssParameter name=\"fill\">\n       <ogc:Function name=\"Recode\">\n         <!-- Value to transform -->\n         <ogc:Function name=\"strTrim\">\n           <ogc:PropertyName>SUB_REGION</ogc:PropertyName>\n         </ogc:Function>\n\n         <!-- Map of input to output values -->\n         <ogc:Literal>N Eng</ogc:Literal>\n         <ogc:Literal>#6495ED</ogc:Literal>\n\n         <ogc:Literal>Mid Atl</ogc:Literal>\n         <ogc:Literal>#B0C4DE</ogc:Literal>\n\n         <ogc:Literal>S Atl</ogc:Literal>\n         <ogc:Literal>#00FFFF</ogc:Literal>  \n\n         <ogc:Literal>E N Cen</ogc:Literal>\n         <ogc:Literal>#9ACD32</ogc:Literal>\n\n         <ogc:Literal>E S Cen</ogc:Literal>\n         <ogc:Literal>#00FA9A</ogc:Literal>\n\n         <ogc:Literal>W N Cen</ogc:Literal>\n         <ogc:Literal>#FFF8DC</ogc:Literal>\n\n         <ogc:Literal>W S Cen</ogc:Literal>\n         <ogc:Literal>#F5DEB3</ogc:Literal>\n\n         <ogc:Literal>Mtn</ogc:Literal>\n         <ogc:Literal>#F4A460</ogc:Literal>\n\n         <ogc:Literal>Pacific</ogc:Literal>\n         <ogc:Literal>#87CEEB</ogc:Literal>\n       </ogc:Function>  \n     </CssParameter>\n   </Fill>\n</PolygonSymbolizer>\n

                                                                                          This style produces the following output:

                                                                                          "},{"location":"styling/sld/tipstricks/transformation-func/#categorize","title":"Categorize","text":"

                                                                                          The Categorize filter function transforms a continuous-valued attribute into a set of discrete values. The function can be used within SLD styling parameters to convert the value of a feature attribute into specific values for a parameter such as color, size, width, opacity, etc.

                                                                                          The categorization is defined by a list of alternating output values and data thresholds. The threshold values define the breaks between the input ranges. Inputs are converted into output values depending on which range they fall in.

                                                                                          "},{"location":"styling/sld/tipstricks/transformation-func/#example_1","title":"Example","text":"

                                                                                          Consider a chloropleth map of the US states dataset using the fill color to indicate a categorization of the states by population. The dataset has attributes PERSONS and LAND_KM from which the population density is computed using the Div operator. This value is input to the Categorize function, which is used to assign different colors to the density ranges [ <= 20], [20 - 100], and [ > 100].

                                                                                          The symbolizer for this style is:

                                                                                          <PolygonSymbolizer>\n   <Fill>\n     <CssParameter name=\"fill\">\n       <ogc:Function name=\"Categorize\">\n         <!-- Value to transform -->\n         <ogc:Div>\n           <ogc:PropertyName>PERSONS</ogc:PropertyName>\n           <ogc:PropertyName>LAND_KM</ogc:PropertyName>\n         </ogc:Div>\n\n         <!-- Output values and thresholds -->\n         <ogc:Literal>#87CEEB</ogc:Literal>\n         <ogc:Literal>20</ogc:Literal>\n         <ogc:Literal>#FFFACD</ogc:Literal>\n         <ogc:Literal>100</ogc:Literal>\n         <ogc:Literal>#F08080</ogc:Literal>\n\n       </ogc:Function>  \n     </CssParameter>\n   </Fill>\n</PolygonSymbolizer>\n

                                                                                          This style produces the following output:

                                                                                          "},{"location":"styling/sld/tipstricks/transformation-func/#interpolate","title":"Interpolate","text":"

                                                                                          The Interpolate filter function transforms a continuous-valued attribute into another continuous range of values. The function can be used within SLD styling parameters to convert the value of a feature attribute into a continuous-valued parameter such as color, size, width, opacity, etc.

                                                                                          The transformation is defined by a set of (input, output) control points chosen along a desired mapping curve. Piecewise interpolation along the curve is used to compute an output value for any input value.

                                                                                          The function is able to compute either numeric or color values as output. This is known as the interpolation method, and is specified by an optional parameter with a value of numeric (the default) or color.

                                                                                          The shape of the mapping curve between control points is specified by the interpolation mode, which is an optional parameter with values of linear (the default), cubic, or cosine.

                                                                                          "},{"location":"styling/sld/tipstricks/transformation-func/#example_2","title":"Example","text":"

                                                                                          Interpolating over color ranges allows concise definition of continuously-varying colors for chloropleth (thematic) maps. As an example, consider a map of the US states dataset using the fill color to indicate the population of the states. The dataset has an attribute PERSONS containing the population of each state. The population values lie in the range 0 to around 30,000,000. The interpolation curve is defined by three control points which assign colors to the population levels 0, 9,000,000 and 23,000,000. The colors for population values are computed by piecewise linear interpolation along this curve. For example, a state with a population of 16,000,000 is displayed with a color midway between the ones for the middle and upper control points. States with populations greater than 23,000,000 are displayed with the last color.

                                                                                          Because the interpolation is being performed over color values, the method parameter is supplied, with a value of color. Since the default linear interpolation is used, no interpolation mode is supplied,

                                                                                          The symbolizer for this style is:

                                                                                          <PolygonSymbolizer>\n   <Fill>\n     <CssParameter name=\"fill\">\n       <ogc:Function name=\"Interpolate\">\n         <!-- Property to transform -->\n         <ogc:PropertyName>PERSONS</ogc:PropertyName>\n\n         <!-- Mapping curve definition pairs (input, output) -->\n         <ogc:Literal>0</ogc:Literal>\n         <ogc:Literal>#fefeee</ogc:Literal>\n\n         <ogc:Literal>9000000</ogc:Literal>\n         <ogc:Literal>#00ff00</ogc:Literal>\n\n         <ogc:Literal>23000000</ogc:Literal>\n         <ogc:Literal>#ff0000</ogc:Literal>\n\n         <!-- Interpolation method -->\n         <ogc:Literal>color</ogc:Literal>\n\n         <!-- Interpolation mode - defaults to linear -->\n       </ogc:Function>  \n     </CssParameter>\n   </Fill>\n</PolygonSymbolizer>\n

                                                                                          This symbolizer produces the following output:

                                                                                          "},{"location":"styling/webadmin/","title":"Styles","text":"

                                                                                          This section will detail how to work with the styles pages in the Web administration interface. For more information on styles and syntax, please see the main section on Styling.

                                                                                          Styles are used to control the appearance of geospatial data. Styles for GeoServer are written in a number of different formats:

                                                                                          • Styled Layer Descriptor (SLD): An OGC standard for geospatial styling. Available by default.
                                                                                          • Cascading Style Sheets (CSS): A CSS-like syntax. Available via an extension.
                                                                                          • YSLD: An SLD-equivalent based on YAML for improved authoring. Available via the ysld extension .
                                                                                          • MBStyle: A syntax based on JSON for improved interoperability. Available via the mbstyle extension .
                                                                                          "},{"location":"styling/webadmin/#styling_webadmin_styles","title":"Styles page","text":"

                                                                                          On the Styles page, you can add a new style, remove a style, or view or edit an existing style.

                                                                                          Styles page

                                                                                          "},{"location":"styling/webadmin/#styling_webadmin_add","title":"Add a Style","text":"

                                                                                          The buttons for adding and removing a style can be found at the top of the Styles page.

                                                                                          Adding or removing a style

                                                                                          To add a new style, click Add a new style button. You will be redirected to the new style page, which is the same as the Style Editor Data tab.

                                                                                          The editor page provides several options for submitting a new style:

                                                                                          • Type the style definition directly into the editor.

                                                                                          • Generate a new default style based on an internal template:

                                                                                            Generating a new default style.

                                                                                          • Copy the contents of an existing style into the editor:

                                                                                            Copying an existing Style from GeoServer

                                                                                          • Upload a local file that contains the style:

                                                                                            Uploading an file from the local system

                                                                                          When creating a style, only the Data tab will be available. Click Apply on the new style to stay on the Style Editor page and gain access to all tabs.

                                                                                          "},{"location":"styling/webadmin/#styling_webadmin_remove","title":"Remove a Style","text":"

                                                                                          To remove a style, click the check box next to the style. Multiple styles can be selected at the same time. Click the Remove selected style(s) link at the top of the page. You will be asked for confirmation:

                                                                                          Confirmation prompt for removing styles

                                                                                          Click OK to remove the selected style(s).

                                                                                          "},{"location":"styling/webadmin/#styling_webadmin_edit","title":"Style Editor","text":"

                                                                                          On the Styles page, click a style name to open the Style Editor.

                                                                                          The Style Editor page presents the style definition. The page contains four tabs with many configuration options:

                                                                                          • Data: Includes basic style information, the ability to generate a style, and legend details
                                                                                          • Publishing: Displays which layers are using this style
                                                                                          • Layer Preview: Previews the style with an associated layer while editing
                                                                                          • Layer Attributes: Displays a list of attributes for the associated layer

                                                                                          Style Editor tabs

                                                                                          At the bottom of the Style Editor page is a number of options:

                                                                                          Option Description Validate Will test the current style for correctness according to the Format option selected. For SLD styles, it will check compliance against the SLD schema. Mind, the parser might be able to read and work with a formally incorrect style. Save Makes the changes to the style and returns to the Styles page Apply Makes the changes to the style and remain on the Style Editor page. This is useful to update the Layer Preview tab. Cancel Cancels all changes to the style and returns to the Styles page

                                                                                          Style Editor options

                                                                                          "},{"location":"styling/webadmin/#styling_webadmin_edit_definition","title":"Style definition","text":"

                                                                                          On all tabs, the Style Editor will display the style definition at the bottom, allowing for direct editing of the style. Switch between the tabs in order to facilitate style creation and editing.

                                                                                          Style editor

                                                                                          The style editor supports line numbering, automatic indentation, and real-time syntax highlighting. You can also increase or decrease the font size of the editor.

                                                                                          Button Description Undo Redo Go to line Find in style text (CTRL-F) Find next occurrence in style text (CTRL-G/Cmd-G) Find and replace in style text (CTRL-SHIFT-F/Cmd-Option-F). First enter the search term, press ENTER, then type the replace term and press ENTER again. It is also possible to run \"replace all\" using CTRL-SHIFT-R/Cmd-Shift-Option-F. Auto-format the editor contents Change the font size in the editor Insert image into style (choose existing or upload) Change height of style editor (disabled in full screen mode)

                                                                                          During editing and especially after editing is complete, you will want to check validation of the syntax. This can be done by clicking the Validate button at the bottom.

                                                                                          If no errors are found, you will see this message:

                                                                                          No validation errors

                                                                                          If any validation errors are found, they will be displayed:

                                                                                          Validation error message

                                                                                          "},{"location":"styling/webadmin/#styling_webadmin_edit_data","title":"Style Editor: Data tab","text":"

                                                                                          The Data tab includes basic style information, the ability to generate a style, and legend details.

                                                                                          The Style Data area has mandatory basic style information:

                                                                                          Option Description Name Name of the style Workspace Workspace in which the style is contained. Styles can be inside workspaces, but can also be \"global\" (no workspace). Format Format of the style. Options are SLD, CSS, and YSLD, MBStyle depending on availability.

                                                                                          Style Data area

                                                                                          The Style Content area allows you to generate a style, copy an existing style, or upload an existing style:

                                                                                          Option Description Generate a default style Selects a generic style based on geometry. Options are Point, Line, Polygon, Raster, and Generic. Click Generate when selected. Copy from existing style Selects an existing style in GeoServer and copy its contents to this style. Any style in GeoServer is available as an option. Not all styles will work with all layers. Click Copy when selected. Upload a style file Selects a plain text file on your local system to add as the style. Click Upload when selected.

                                                                                          Style Content area

                                                                                          The Legend area allows you to add, modify, or delete a custom style, and preview the legend for the style. By default GeoServer will generate a legend based on your style file, but this can be customized here:

                                                                                          Option Description Add legend Allows you to use a custom legend Online Resource Path to the custom legend graphic to use. Can be a URL or a local path (relative to the style file path). See Structure of the data directory for a description of the styles directory. Auto-detect image size and type Populates the Width, Height, and Format options for the Online Resource Width Width of the custom legend graphic Height Height of the custom legend graphic Format Mime type of the custom legend graphic Discard legend Will remove the settings for the custom legend graphic and will instead use the default generated legend. Preview legend Previews the legend based on the current settings Choose Image Insert image into style (choose existing or upload)

                                                                                          Legend area

                                                                                          Choose Image Dialog

                                                                                          "},{"location":"styling/webadmin/#styling_webadmin_edit_publishing","title":"Style Editor: Publishing tab","text":"

                                                                                          The Publishing tab displays a list of all layers on the server, with the purpose of showing which layers are associated with the current style. Layers can set a single default style and have any number of additional styles. If this style is set to be either of these options for a layer, it will be shown with a check box in the table.

                                                                                          Option Description Workspace Workspace of the layer Layer Name of the layer Default Shows whether the style being edited is the default for a given layer Associated Shows whether the style being edited is an additional style for a given layer

                                                                                          Publishing tab

                                                                                          "},{"location":"styling/webadmin/#styling_webadmin_edit_preview","title":"Style Editor: Layer Preview tab","text":"

                                                                                          It is very common to have to iterate your styles and test how the visualization changes over time. The Layer Preview tab allows you to make changes to the style and see them without having to navigate away from the page.

                                                                                          The Layer Preview tab shows a single image. GeoServer tries to identify which layer should be shown (for example, a layer for which this style is the default), but if the layer being previewed is not the desired one, click the layer name above the preview box and select a layer.

                                                                                          Layer Preview tab

                                                                                          "},{"location":"styling/webadmin/#styling_webadmin_edit_attributes","title":"Style Editor: Layer Attributes tab","text":"

                                                                                          Most styles utilize the specific values of certain attributes of the associated layer in order to create more detailed and useful styles. (For example: styling all large cities different from small cities based on a particular attribute.)

                                                                                          The Layer Attributes tab will display a list of attributes for the given associated layer. GeoServer tries to identify which layer should be shown (for example, a layer for which this style is the default), but if the layer being previewed is not the desired one, click the layer name above the table and select a layer.

                                                                                          Option Description name Name of the attribute type Type of the attribute. Can be a numeric (such as \"Long\"), a string (\"String\"), or a geometry (such as \"Point\"). sample Sample value of the attribute taken from the data min Minimum value of the attribute in the data set, if applicable max Minimum value of the attribute in the data set, if applicable computeStats Click Compute to calculate the min and max values for that attribute, if applicable

                                                                                          Layer Attributes tab

                                                                                          "},{"location":"styling/webadmin/#style-editor-full-screen-side-by-side-mode","title":"Style Editor: full screen side by side mode","text":"

                                                                                          The style editor page has now a \"outwards arrows\" button on the top right side of the window:

                                                                                          The new fullscreen functionality

                                                                                          Pressing it will cause the editor and preview to go side by side and use the entire browser window space:

                                                                                          Side by side style editing

                                                                                          The button turns into a \"inwards arrows\" icon, pressing it resumes the original editing mode.

                                                                                          "},{"location":"styling/workshop/","title":"Styling Workshop","text":"

                                                                                          This workshop will explore how GeoServer styling can be used for a range of creative effects. This workshop also introduces both the CSS and YSLD extensions, which provide alternate styling languages to SLD.

                                                                                          The following material will be covered in this workshop:

                                                                                          setup/index

                                                                                          Workshop materials and setup

                                                                                          design/index

                                                                                          Overview of map design (i.e. cartography) considerations. Select color palette with colorbrewer.

                                                                                          css/index

                                                                                          Introduction to GeoServer styling followed by easy styling with the CSS module.

                                                                                          ysld/index

                                                                                          Introduction to GeoServer styling followed by easy styling with the YSLD module.

                                                                                          mbstyle/index

                                                                                          Introduction to GeoServer styling followed by easy styling with the MBStyle module.

                                                                                          "},{"location":"styling/workshop/css/","title":"CSS Styling Workbook","text":"

                                                                                          GeoServer styling can be used for a range of creative effects. This section introduces the CSS Extension which can be used to quickly generate SLD files.

                                                                                          • CSS Quickstart
                                                                                          • Lines
                                                                                          • Polygons
                                                                                          • Points
                                                                                          • Rasters
                                                                                          • CSS Workbook Conclusion
                                                                                          "},{"location":"styling/workshop/css/css/","title":"CSS Quickstart","text":"

                                                                                          In the last section, we saw how the OGC defines style using XML documents (called SLD files).

                                                                                          We will now explore GeoServer styling in greater detail using a tool to generate our SLD files. The Cascading Style Sheet (CSS) GeoServer extension is used to generate SLD files using a syntax more familiar to web developers.

                                                                                          Using the CSS extension to define styles results in shorter examples that are easier to understand. At any point we will be able to review the generated SLD file.

                                                                                          "},{"location":"styling/workshop/css/css/#syntax","title":"Syntax","text":"

                                                                                          This section provides a quick introduction to CSS syntax for mapping professionals who may not be familiar with web design.

                                                                                          "},{"location":"styling/workshop/css/css/#key-properties","title":"Key properties","text":"

                                                                                          As we work through CSS styling examples you will note the use of key properties. These properties are required to trigger the creation of an appropriate symbolizer in SLD.

                                                                                          stroke Color (or graphic) for LineString or Polygon border fill Color (or graphic) for Polygon Fill mark Well-known Mark or graphic used for Point label Text expression labeling halo-radius Size of halo used to outline label

                                                                                          Using just these key properties and the selector *, you will be able to visualize vector data.

                                                                                          For example, here is the key property stroke providing a gray representation for line or polygon data:

                                                                                          * {\n   stroke: gray;\n}\n

                                                                                          Here is the key property fill providing a blue fill for polygon data:

                                                                                          * {\n   fill: #2020ED;\n}\n

                                                                                          Here is the key property mark showing the use of the well-known symbol square:

                                                                                          * {\n   mark: symbol(square);\n}\n

                                                                                          Here is the key property label generating labels using the CITY_NAME feature attribute:

                                                                                          * {\n   label: [CITY_NAME];\n}\n

                                                                                          Here is the key property halo-radius providing an outline around generated label:

                                                                                          * {\n   label: [NAME];\n   halo-radius: 1;\n}\n

                                                                                          Reference:

                                                                                          • CSS Cookbook
                                                                                          • CSS Examples
                                                                                          "},{"location":"styling/workshop/css/css/#rules","title":"Rules","text":"

                                                                                          We have already seen a CSS style composed of a single rule:

                                                                                          * {\n  mark: symbol(circle);\n}\n

                                                                                          We can also make a rule that only applies to a specific FeatureType:

                                                                                          populated_places {\n  mark: symbol(triangle);\n}\n

                                                                                          We can make a style consisting of more than one rule, carefully choosing the selector for each rule. In this case we are using a selector to style capital cities with a star, and non-capital with a circle:

                                                                                          [ FEATURECLA = 'Admin-0 capital' ] {\n  mark: symbol(star);\n  mark-size: 6px;\n}\n\n[ FEATURECLA <> 'Admin-0 capital' ] {\n  mark: symbol(circle);\n  mark-size: 6px;\n}\n

                                                                                          The feature attribute test performed above uses Constraint Query Language (CQL). This syntax can be used to define filters to select content, similar to how the SQL WHERE statement is used. It can also be used to define expressions to access attribute values allowing their use when defining style properties.

                                                                                          Rule selectors can also be triggered based on the state of the rendering engine. In this example we are only applying labels when zoomed in:

                                                                                          [@scale < 20000000] {\n   label: [ NAME ];\n}\n

                                                                                          In the above example the label is defined using the CQL Expression NAME. This results in a dynamic style that generates each label on a case-by-case basis, filling in the label with the feature attribute NAME.

                                                                                          Reference:

                                                                                          • Filter Syntax
                                                                                          • ECQL Reference
                                                                                          "},{"location":"styling/workshop/css/css/#cascading","title":"Cascading","text":"

                                                                                          In the above example feature attribute selection we repeated information. An alternate approach is to make use of CSS Cascading and factor out common properties into a general rule:

                                                                                          [ FEATURECLA = 'Admin-0 capital' ] {\n  mark: symbol(star);\n}\n\n[ FEATURECLA <> 'Admin-0 capital' ] {\n  mark: symbol(circle);\n}\n\n* {\n  mark-size: 6px;\n}\n
                                                                                          "},{"location":"styling/workshop/css/css/#pseudo-selector","title":"Pseudo-selector","text":"

                                                                                          Up to this point we have been styling individual features, documenting how each shape is represented.

                                                                                          When a shape is represented using a symbol, we have a second challenge: documenting the colors and appearance of the symbol. The CSS extension provides a pseudo-selector allowing further properties to be applied to a symbol.

                                                                                          Example of using a pseudo-selector:

                                                                                          * {\n  mark: symbol(circle);\n}\n\n:mark {\n  fill: black;\n  stroke: white;\n}\n

                                                                                          In this example the :mark pseudo-selector is used select the circle mark, and provides a fill and stroke for use when rendering.

                                                                                          Pseudo-selector Use of symbol :mark point markers :stroke stroke patterns :fill fill patterns :shield label shield :symbol any use

                                                                                          The above pseudo-selectors apply to all symbols, but to be specific the syntax nth-symbol(1) can be used:

                                                                                          * {\n  mark: symbol(circle);\n}\n\n:nth-mark(1) {\n  fill: black;\n  stroke: white;\n}\n

                                                                                          Reference:

                                                                                          • Styled Marks (User Guide)
                                                                                          "},{"location":"styling/workshop/css/css/#compare-css-to-sld","title":"Compare CSS to SLD","text":"

                                                                                          The CSS extension is built with the same GeoServer rendering engine in mind, providing access to all the functionality of SLD (along with vendor options for fine control of labeling). The two approaches use slightly different terminology: SLD uses terms familiar to mapping professionals, CSS uses ideas familiar to web developers.

                                                                                          "},{"location":"styling/workshop/css/css/#sld-style","title":"SLD Style","text":"

                                                                                          SLD makes use of a series of Rules to select content for display. Content is selected using filters that support attribute, spatial and temporal queries.

                                                                                          Once selected, content is transformed into a shape and drawn using symbolizers. Symbolizers are configured using CSS Properties to document settings such as \"fill\" and \"opacity\".

                                                                                          Content can be drawn by more than one rule, allowing for a range of effects.

                                                                                          Here is an example SLD file for reference:

                                                                                          <?xml version=\"1.0\" encoding=\"ISO-8859-1\"?>\n<StyledLayerDescriptor version=\"1.0.0\"\n xsi:schemaLocation=\"http://www.opengis.net/sld StyledLayerDescriptor.xsd\"\n xmlns=\"http://www.opengis.net/sld\"\n xmlns:ogc=\"http://www.opengis.net/ogc\"\n xmlns:xlink=\"http://www.w3.org/1999/xlink\"\n xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\">\n  <NamedLayer>\n    <Name>airports</Name>\n    <UserStyle>\n      <Title>Airports</Title>\n      <FeatureTypeStyle>\n        <Rule>\n          <Name>airports</Name>\n          <Title>Airports</Title>\n            <PointSymbolizer>\n              <Graphic>\n                <ExternalGraphic>\n                  <OnlineResource xlink:type=\"simple\"\n                  xlink:href=\"airport.svg\" />\n                  <Format>image/svg</Format>\n                </ExternalGraphic>\n                <ExternalGraphic>\n                  <OnlineResource xlink:type=\"simple\"\n                  xlink:href=\"airport.png\" />\n                  <Format>image/png</Format>\n                </ExternalGraphic>\n                <Mark>\n                  <WellKnownName>triangle</WellKnownName>\n                  <Fill>\n                    <CssParameter name=\"fill\">#000000</CssParameter>\n                  </Fill>\n                  <Stroke>\n                    <CssParameter name=\"stroke\">#FFFFFF</CssParameter>\n                    <CssParameter name=\"stroke-opacity\">0.50</CssParameter>\n                  </Stroke>\n                </Mark>\n              <Size>16</Size>\n            </Graphic>\n          </PointSymbolizer>\n        </Rule>\n      </FeatureTypeStyle>\n    </UserStyle>\n  </NamedLayer>\n</StyledLayerDescriptor>\n
                                                                                          "},{"location":"styling/workshop/css/css/#css-style","title":"CSS Style","text":"

                                                                                          CSS also makes use of rules, each rule making use of selectors to shortlist content for display. Each selector uses a CQL filter that supports attribute, spatial and temporal queries. Once selected, CSS Properties are used to describe how content is rendered.

                                                                                          Content is not drawn by more than one rule. When content satisfies the conditions of more than one rule the resulting properties are combined using a process called inheritance. This technique of having a generic rule that is refined for specific cases is where the Cascading in Cascading Style Sheet comes from.

                                                                                          Here is an example using CSS:

                                                                                          * {\n  mark: url(airport.svg);\n  mark-mime: \"image/svg\";\n}\n

                                                                                          In this rule the selector * is used to match all content. The rule defines properties indicating how this content is to be styled. The property mark is used to indicate we want this content drawn as a Point. The value url(airport.svg) is a URL reference to the image file used to represent each point. The mark-mime property indicates the expected format of this image file.

                                                                                          "},{"location":"styling/workshop/css/css/#tour","title":"Tour","text":"

                                                                                          To confirm everything works, let's reproduce the airports style above.

                                                                                          1. Navigate to the Styles page.

                                                                                          2. Each time we edit a style, the contents of the associated SLD file are replaced. Rather than disrupt any of our existing styles we will create a new style. Click Add a new style and choose the following:

                                                                                              • Name:
                                                                                              • airport0
                                                                                              • Workspace:
                                                                                              • (none specified)
                                                                                              • Format:
                                                                                              • CSS
                                                                                          3. Replace the initial YSLD definition with our airport CSS example and click Apply:

                                                                                            * {\n  mark: url(airport.svg);\n  mark-mime: \"image/svg\";\n}\n
                                                                                          4. Click the Layer Preview tab to preview the style. We want to preview on the airports layer, so click the name of the current layer and select ne:airports from the list that appears. You can use the mouse buttons to pan and scroll wheel to change scale.

                                                                                            Choosing the airports layer

                                                                                            Layer preview

                                                                                          5. Click Layer Data for a summary of the selected data.

                                                                                            Layer attributes

                                                                                          "},{"location":"styling/workshop/css/css/#bonus","title":"Bonus","text":"

                                                                                          Finished early? For now please help your neighbour so we can proceed with the workshop.

                                                                                          If you are really stuck please consider the following challenge rather than skipping ahead.

                                                                                          "},{"location":"styling/workshop/css/css/#explore-data","title":"Explore Data","text":"
                                                                                          1. Return to the Data tab and use the Compute link to determine the minimum and maximum for the scalerank attribute.
                                                                                          "},{"location":"styling/workshop/css/css/#challenge-compare-sld-generation","title":"Challenge Compare SLD Generation","text":"

                                                                                          # The rest API can be used to review your CSS file directly.

                                                                                          Browser:

                                                                                          • Command line:

                                                                                            curl -v -u admin:geoserver -XGET http://localhost:8080/geoserver/rest/styles/airports0.css\n
                                                                                            1. The REST API can also be used generate an SLD file:

                                                                                              Browser:

                                                                                              • Command line:

                                                                                                curl -v -u admin:geoserver -XGET http://localhost:8080/geoserver/rest/styles/airports0.sld?pretty=true\n
                                                                                                1. Compare the generated SLD differ above with the handwritten SLD file used as an example?

                                                                                                  Challenge: What differences can you spot?

                                                                                                  Instructor Notes

                                                                                                  Generated SLD does not include name or title information; this can be added by students using an annotation. Encourage students to look this up in the reference material provided.

                                                                                                  The second difference is with the use of a fallback Mark when defining a PointSymbolizer. The CSS extension does not bother with a fallback as it knows the capabilities of the GeoServer rendering engine (and is not trying to create a reusable style).

                                                                                                "},{"location":"styling/workshop/css/done/","title":"CSS Workbook Conclusion","text":"

                                                                                                We hope you have enjoyed this styling workshop.

                                                                                                Additional resources:

                                                                                                • CSS Extension
                                                                                                • CSS Cookbook
                                                                                                "},{"location":"styling/workshop/css/done/#css-workbook-answer-key","title":"CSS Workbook Answer Key","text":"

                                                                                                The following questions were listed throughout the workshop as an opportunity to explore the material in greater depth. Please do your best to consider the questions in detail prior to checking here for the answer. Questions are provided to teach valuable skills, such as a chance to understand how feature type styles are used to control z-order, or where to locate information in the user manual.

                                                                                                "},{"location":"styling/workshop/css/done/#css.line.a0","title":"SLD Generation","text":"

                                                                                                Answer for Challenge SLD Generation <css.line.q0>:

                                                                                                1. Generate the SLD for the following CSS.

                                                                                                  * {\n  stroke: black;\n}\n
                                                                                                2. Challenge: What is unusual about the generated SLD? Can you explain why it still works as expected?

                                                                                                  The generated SLD does not contain any stroke properties, even though black was specified:

                                                                                                  <sld:LineSymbolizer>\n  <sld:Stroke/>\n</sld:LineSymbolizer>\n

                                                                                                  SLD considers black the default stroke color for a LineSymbolizer, so no further detail was required.

                                                                                                "},{"location":"styling/workshop/css/done/#css.line.a1","title":"Classification","text":"

                                                                                                Answer for Challenge Classification <css.line.q1>:

                                                                                                1. Challenge: Create a new style adjust road appearance based on type.

                                                                                                  Hint: The available values are 'Major Highway','Secondary Highway','Road' and 'Unknown'.

                                                                                                2. Here is an example:

                                                                                                  [type = 'Major Highway' ] {\n    stroke: #000088;\n    stroke-width: 1.25;\n}\n[type = 'Secondary Highway' ]{\n    stroke: #8888AA;\n    stroke-width: 0.75;\n}\n[type = 'Road']{\n    stroke: #888888;\n    stroke-width: .75;\n}\n[type = 'Unknown' ]{\n    stroke: #888888;\n    stroke-width: 0.5;\n}\n* {\n   stroke: #AAAAAA;\n   stroke-opacity: 0.25;\n   stroke-width: 0.5;\n}\n
                                                                                                "},{"location":"styling/workshop/css/done/#css.line.a2","title":"SLD Z-Index Generation","text":"

                                                                                                Answer for Challenge SLD Z-Index Generation <css.line.q2>:

                                                                                                1. Review the SLD generated by the z-index example.

                                                                                                  * {\n  stroke: black, #8080E6;\n  stroke-width: 5px, 3px;\n  z-index: 0, 1;\n}\n
                                                                                                2. Challenge: There is an interesting trick in the generated SLD, can you explain how it works?

                                                                                                3. The Z-Order example produces multiple FeatureTypeSytle definitions, each acting like an \"inner layer\".

                                                                                                  Each FeatureTypeStyle is rendered into its own raster, and the results merged in order. The legend shown in the map preview also provides a hint, as the rule from each FeatureType style is shown.

                                                                                                "},{"location":"styling/workshop/css/done/#css.line.a3","title":"Label Shields","text":"

                                                                                                Answer for Challenge Label Shields <css.line.q2>:

                                                                                                1. The traditional presentation of roads in the US is the use of a shield symbol, with the road number marked on top.

                                                                                                1. Challenge: Have a look at the documentation and reproduce this technique.

                                                                                                2. The use of a label shield is a vendor specific capability of the GeoServer rendering engine. The tricky part of this exercise is finding the documentation online ( i.e. Styled Marks in CSS).

                                                                                                  * {\n    stroke: black,lightgray;\n    stroke-width: 3,2;\n    label: [name];\n    font-family: 'Ariel';\n    font-size: 10;\n    font-fill: black;\n    shield: symbol(square);\n}\n:shield {\n    fill: white;\n    stroke: black;\n    size: 18;\n}\n
                                                                                                "},{"location":"styling/workshop/css/done/#css.polygon.a1","title":"Antialiasing","text":"

                                                                                                Answer for Explore Antialiasing <css.polygon.q1>:

                                                                                                1. When we rendered our initial preview, without a stroke, thin white gaps (or slivers) are visible between our polygons.

                                                                                                  This effect is made more pronounced by the rendering engine making use of the Java 2D sub-pixel accuracy. This technique is primarily used to prevent an aliased (stair-stepped) appearance on diagonal lines.

                                                                                                2. Explore: Experiment with fill and stroke settings to eliminate slivers between polygons.

                                                                                                  The obvious approach works - setting both values to the same color:

                                                                                                  symbolizers:\n- polygon:\n    stroke-color: 'lightgrey'\n    stroke-width: 1\n    fill-color: 'lightgrey'\n
                                                                                                "},{"location":"styling/workshop/css/done/#css.polygon.a2","title":"Categorize","text":"

                                                                                                Answer for Explore Categorize <css.polygon.q2>:

                                                                                                1. An exciting use of the GeoServer shape symbols is the theming by changing the size used for pattern density.

                                                                                                2. Explore: Use the Categorize function to theme by datarank.

                                                                                                  Example:

                                                                                                  .. code-block:: css\n\n   * {\n     fill: symbol('shape://slash');\n     fill-size: [\n        Categorize(datarank,\n         4, 4,\n         5, 6,\n         8, 10,\n        10)\n     ];\n     stroke: black;\n   }\n   :fill {\n     stroke: darkgray;\n   }\n
                                                                                                "},{"location":"styling/workshop/css/done/#css.polygon.a4","title":"Halo","text":"

                                                                                                Answer for Challenge Halo <css.polygon.q4>:

                                                                                                1. The halo example used the fill color and opacity for a muted halo, while this improved readability it did not bring attention to our labels.

                                                                                                  A common design choice for emphasis is to outline the text in a contrasting color.

                                                                                                2. Challenge: Produce a map that uses a white halo around black text.

                                                                                                  Here is an example:

                                                                                                  * {  stroke: gray;\n     fill: #7EB5D3;\n     label: [name];\n     label-anchor: 0.5 0.5;\n     font-fill: black;\n     font-family: \"Arial\";\n     font-size: 14;\n     halo-radius: 1;\n     halo-color: white;\n   }\n
                                                                                                "},{"location":"styling/workshop/css/done/#css.polygon.a5","title":"Theming using Multiple Attributes","text":"

                                                                                                Answer for Challenge Theming using Multiple Attributes <css.polygon.q5>:

                                                                                                1. A powerful tool is theming using multiple attributes. This is an important concept allowing map readers to perform \"integration by eyeball\" (detecting correlations between attribute values information).

                                                                                                2. Challenge: Combine the mapcolor9 and datarank examples to reproduce the following map.

                                                                                                  This should be a cut and paste using the recode example, and categorize examples already provided.

                                                                                                  * {\n   fill: [\n    recode(mapcolor9,\n      1,'#8dd3c7', 2,'#ffffb3', 3,'#bebada',\n      4,'#fb8072', 5,'#80b1d3', 6,'#fdb462',\n      7,'#b3de69', 8,'#fccde5', 9,'#d9d9d9')\n   ], symbol('shape://slash');\n\n   fill-size: '',[\n      Categorize(datarank,\n       6, 4,\n       8, 6,\n      10, 10,\n      12)\n   ];\n   stroke: black;\n}\n:fill {\n   stroke: black;\n}\n
                                                                                                "},{"location":"styling/workshop/css/done/#css.polygon.a6","title":"Use of Use of Z-Index","text":"

                                                                                                Answer for Challenge Use of Z-Index <css.polygon.q6>:

                                                                                                1. Earlier we looked at using z-index to simulate line string casing. The line work was drawn twice, once with thick line, and then a second time with a thinner line. The resulting effect is similar to text halos - providing breathing space around complex line work allowing it to stand out.

                                                                                                2. Challenge: Use what you know of LineString z-index to reproduce the following map:

                                                                                                  This is a tricky challenge. While it is easy enough to introduce z-index to control stroke what is not immediately obvious is that z-order also controls fill order. The previous examples illustrate how to introduce z-order, some thought is required to untangle fill and stroke z-order (dummy stroke definitions need to be introduced using empty commas).

                                                                                                  * {\n  fill: lightgray, symbol('shape://slash');\n  fill-size: 8px;\n  stroke: '','',lightgray, black;\n  stroke-width: '','',6,1.5;\n  z-index: 1,2,3,4;\n}\n:fill {\n  stroke: black;\n  stroke-width: 0.75;\n}\n

                                                                                                  The included legend should be a large clue about what is going on.

                                                                                                "},{"location":"styling/workshop/css/done/#css.point.a1","title":"Geometry Location","text":"

                                                                                                Answer for Challenge Geometry Location <css.point.q1>:

                                                                                                1. The mark property can be used to render any geometry content.

                                                                                                2. Challenge: Try this yourself by rendering a polygon layer using a mark property.

                                                                                                  This can be done one of two ways:

                                                                                                  • Changing the association of a polygon layer, such as ne:states_provinces_shp to point_example and using the layer preview page.
                                                                                                  • Changing the Layer Preview tab to a polygon layer, such as ne:states_provinces_shp.

                                                                                                  The important thing to notice is that the centroid of each polygon is used as a point location.

                                                                                                "},{"location":"styling/workshop/css/done/#css.point.a2","title":"Dynamic Symbolization","text":"

                                                                                                Answer for Explore Dynamic Symbolization <css.point.q2>:

                                                                                                1. SLD Mark and ExternalGraphic provide an opportunity for dynamic symbolization.

                                                                                                  This is accomplished by embedding a small CQL expression in the string passed to symbol or url. This sub-expression is isolated with \\${ } as shown:

                                                                                                  - point:\n    symbols:\n    - mark:\n        shape: ${if_then_else(equalTo(FEATURECLA,'Admin-0 capital'),'star','circle')}\n
                                                                                                2. Challenge: Use this approach to rewrite the Dynamic Styling example.

                                                                                                  Example available here point_example.css

                                                                                                  [@scale < 4000000]{ mark: symbol(

                                                                                                  \"\\${if_then_else(equalTo(FEATURECLA,'Admin-0 capital'),'star','circle')}\"

                                                                                                  ); mark-size: [13-SCALERANK]; label: [NAME]; label-offset: 0 [13-SCALERANK];

                                                                                                  }

                                                                                                "},{"location":"styling/workshop/css/done/#css.point.a3","title":"Layer Group","text":"

                                                                                                Answer for Challenge Layer Group <css.point.q3>:

                                                                                                1. Use a Layer Group to explore how symbology works together to form a map.

                                                                                                  • ne:NE1
                                                                                                  • ne:states_provincces_shp
                                                                                                  • ne:populated_places
                                                                                                2. This background is relatively busy and care must be taken to ensure both symbols and labels are clearly visible.

                                                                                                3. Challenge: Do your best to style populated_places over this busy background.

                                                                                                  Here is an example with labels for inspiration:

                                                                                                  This should be an opportunity to revisit label halo settings from Polygons.

                                                                                                  * {\n   mark-size: [5+((10-SCALERANK)/3)];\n\n   font-fill: black;\n   font-family: \"Arial\";\n   font-size: 10;\n\n   label-anchor: 0.5 1;\n   label-offset: 0 [-12+SCALERANK];\n\n   halo-radius: 2;\n   halo-color: lightgray;\n   halo-opacity:0.7;\n\n   mark-label-obstacle: true;\n   label-max-displacement: 90;\n   label-priority: [0 - LABELRANK];\n}\n:symbol {\n  fill: black;\n  stroke: white;\n  stroke-opacity:0.75;\n}\n

                                                                                                  Using a lightgray halo, 0.7 opacity and radius 2 fades out the complexity immediately surrounding the label text improving legibility.

                                                                                                "},{"location":"styling/workshop/css/done/#css.raster.a1","title":"Contrast Enhancement","text":"

                                                                                                Discussion for Explore Contrast Enhancement <css.raster.q1>:

                                                                                                1. A special effect that is effective with grayscale information is automatic contrast adjustment.

                                                                                                2. Make use of a simple contrast enhancement with usgs:dem:

                                                                                                  * {\n    raster-channels: auto;\n    raster-contrast-enhancement: normalize;\n}\n
                                                                                                3. Can you explain what happens when zoom in to only show a land area (as indicated with the bounding box below)?

                                                                                                  What happens is insanity, normalize stretches the palette of the output image to use the full dynamic range. As long as we have ocean on the screen (with value 0) the land area was shown with roughly the same presentation.

                                                                                                  Once we zoom in to show only a land area, the lowest point on the screen (say 100) becomes the new black, radically altering what is displayed on the screen.

                                                                                                "},{"location":"styling/workshop/css/done/#css.raster.a2","title":"Intervals","text":"

                                                                                                Answer for Challenge Intervals <css.raster.q2>:

                                                                                                1. The color-map type property dictates how the values are used to generate a resulting color.

                                                                                                  • ramp is used for quantitative data, providing a smooth interpolation between the provided color values.
                                                                                                  • intervals provides categorization for quantitative data, assigning each range of values a solid color.
                                                                                                  • values is used for qualitative data, each value is required to have a color-map entry or it will not be displayed.
                                                                                                2. Challenge: Update your DEM example to use intervals for presentation. What are the advantages of using this approach for elevation data?

                                                                                                  By using intervals it becomes very clear how relatively flat most of the continent is. The ramp presentation provided lots of fascinating detail which distracted from this fact.

                                                                                                  Here is style for you to cut and paste:

                                                                                                  * {\n  raster-channels: auto;\n  raster-color-map:\n     color-map-entry(#014636,   0,0)\n     color-map-entry(#014636,   1)\n     color-map-entry(#016c59, 500)\n     color-map-entry(#02818a,1000)\n     color-map-entry(#3690c0,1500)\n     color-map-entry(#67a9cf,2000)\n     color-map-entry(#a6bddb,2500)\n     color-map-entry(#d0d1e6,3000)\n     color-map-entry(#ece2f0,3500)\n     color-map-entry(#fff7fb,4000);\n  raster-color-map-type: intervals;\n}\n
                                                                                                "},{"location":"styling/workshop/css/done/#css.raster.a3","title":"Clear Digital Elevation Model Presentation","text":"

                                                                                                Answer for Challenge Clear Digital Elevation Model Presentation <css.raster.q3>:

                                                                                                1. Now that you have seen the data on screen and have a better understanding how would you modify our initial gray-scale example?

                                                                                                2. Challenge: Use what you have learned to present the usgs:dem clearly.

                                                                                                  The original was a dark mess. Consider making use of mid-tones (or adopting a sequential palette from color brewer) in order to fix this. In the following example the ocean has been left dark, allowing the mountains stand out more.

                                                                                                  * {\n  raster-channels: auto;\n  raster-color-map: color-map-entry(#000000, 0)\n                    color-map-entry(#444444, 1)\n                    color-map-entry(#FFFFFF, 3000);\n}\n
                                                                                                "},{"location":"styling/workshop/css/done/#css.raster.a4","title":"Raster Opacity","text":"

                                                                                                Discussion for Challenge Clear Digital Elevation Model Presentation <css.raster.q3>:

                                                                                                1. There is a quick way to make raster data transparent, raster opacity property works in the same fashion as with vector data. The raster as a whole will be drawn partially transparent allow content from other layers to provide context.

                                                                                                2. Challenge: Can you think of an example where this would be useful?

                                                                                                  This is difficult as raster data is usually provided for use as a basemap, with layers being drawn over top.

                                                                                                  The most obvious example here is the display of weather systems, or model output such as fire danger. By drawing the raster with some transparency, the landmass can be shown for context.

                                                                                                "},{"location":"styling/workshop/css/linestring/","title":"Lines","text":"

                                                                                                We will start our tour of CSS styling by looking at the representation of lines.

                                                                                                LineString Geometry

                                                                                                Review of line symbology:

                                                                                                • Lines are used to represent physical details that are too small to be represented at the current scale. Line work can also be used to model non-physical ideas such as network connectivity, or the boundary between land-use classifications. The visual width of lines do not change depending on scale.
                                                                                                • Lines are recording as LineStrings or Curves depending on the geometry model used.
                                                                                                • SLD uses a LineSymbolizer record how the shape of a line is drawn. The primary characteristic documented is the Stroke used to draw each segment between vertices.
                                                                                                • Labeling of line work is anchored to the midpoint of the line. GeoServer provides an option to allow label rotation aligned with line segments.

                                                                                                For our exercises we are going to be using simple CSS documents, often consisting of a single rule, in order to focus on the properties used for line symbology.

                                                                                                Each exercise makes use of the ne:roads layer.

                                                                                                Reference:

                                                                                                • Line Symbology (User Manual | CSS Property Listing)
                                                                                                • Lines (User Manual | CSS Cookbook)
                                                                                                • LineString (User Manual | SLD Reference )
                                                                                                "},{"location":"styling/workshop/css/linestring/#stroke","title":"Stroke","text":"

                                                                                                The only mandatory property for representation of linework is stroke. This is a key property; its presence triggers the generation of an appropriate LineSymbolizer.

                                                                                                Basic Stroke Properties

                                                                                                The use of stroke as a key property prevents CSS from having the idea of a default line color (as the stroke information must be supplied each time).

                                                                                                1. Navigate to the CSS Styles page.

                                                                                                2. Click Choose a different layer and select ne:roads from the list.

                                                                                                3. Click Create a new style and choose the following:

                                                                                                    • Workspace for new layer:
                                                                                                    • No workspace
                                                                                                    • New style name:
                                                                                                    • line_example
                                                                                                4. Replace the generated CSS definition with the following stroke example:

                                                                                                  /* @title Line\n * @abstract Example line symbolization\n */\n * {\n   stroke: blue;\n }\n
                                                                                                5. Click Submit and then the Map tab for an initial preview.

                                                                                                  You can use this tab to follow along as the style is edited, it will refresh each time Submit is pressed.

                                                                                                6. You can look at the SLD tab at any time to see the generated SLD. Currently it is showing a straight forward LineSymbolizer generated from the CSS stroke property:

                                                                                                  <sld:UserStyle>\n   <sld:Name>Default Styler</sld:Name>\n   <sld:FeatureTypeStyle>\n      <sld:Name>name</sld:Name>\n      <sld:Rule>\n         <sld:Title>Line</sld:Title>\n         <sld:Abstract>Example line symboloization</sld:Abstract>\n         <sld:LineSymbolizer>\n            <sld:Stroke>\n               <sld:CssParameter name=\"stroke\">#0000ff</sld:CssParameter>\n            </sld:Stroke> \n         </sld:LineSymbolizer>\n      </sld:Rule>\n   </sld:FeatureTypeStyle>\n</sld:UserStyle>\n
                                                                                                7. Additional properties cane be used fine-tune appearance. Use stroke-width to specify the width of the line.

                                                                                                  /* @title Line\n * @abstract Example line symbolization\n */\n * {\n   stroke: blue;\n   stroke-width: 2px;\n }\n
                                                                                                8. The stroke-dasharray is used to define breaks rendering the line as a dot dash pattern.

                                                                                                  /* @title Line\n * @abstract Example line symbolization\n */\n * {\n   stroke: blue;\n   stroke-width: 2px;\n   stroke-dasharray: 5 2;\n }\n
                                                                                                9. Check the Map tab to preview the result.

                                                                                                Note

                                                                                                The GeoServer rendering engine is quite sophisticated and allows the use of units of measure (such as m or ft). While we are using pixels in this example, real world units will be converted using the current scale.

                                                                                                "},{"location":"styling/workshop/css/linestring/#z-index","title":"Z-Index","text":"

                                                                                                The next exercise shows how to work around a limitation when using multiple strokes to render a line.

                                                                                                Use of Z-Index

                                                                                                1. Providing two strokes is often used to provide a contrasting edge (called casing) to thick line work.

                                                                                                  Update line_example with the following:

                                                                                                  * {\n  stroke: black, #8080E6;\n  stroke-width: 5px, 3px;\n}\n
                                                                                                2. If you look carefully you can see a problem with our initial attempt. The junctions of each line show that the casing outlines each line individually, making the lines appear randomly overlapped. Ideally we would like to control this process, only making use of this effect for overpasses.

                                                                                                3. The z-index parameter allows a draw order to be supplied. This time all the thick black lines are dawn first (at z-index 0) followed by the thinner blue lines (at z-index 1).

                                                                                                  * {\n  stroke: black, #8080E6;\n  stroke-width: 5px, 3px;\n  z-index: 0, 1;\n}\n
                                                                                                4. If you look carefully you can see the difference.

                                                                                                5. By using z-index we have been able to simulate line casing.

                                                                                                "},{"location":"styling/workshop/css/linestring/#label","title":"Label","text":"

                                                                                                Our next example is significant as it introduces the how text labels are generated.

                                                                                                Use of Label Property

                                                                                                This is also our first example making use of a dynamic style (where the value of a property is defined by an attribute from your data).

                                                                                                1. To enable LineString labeling we will need to use the key properties for both stroke and label.

                                                                                                  Update line_example with the following:

                                                                                                  * {\n  stroke: blue;\n  label: [name];\n}\n
                                                                                                2. The SLD standard documents the default label position for each kind of Geometry. For LineStrings the initial label is positioned on the midway point of the line.

                                                                                                3. We have used an expression to calculate a property value for label. The label property is generated dynamically from the name attribute. Expressions are supplied within square brackets, making use of Constraint Query Language (CQL) syntax.

                                                                                                  * {\n  stroke: blue;\n  label: [name];\n}\n
                                                                                                4. Additional properties can be supplied to fine-tune label presentation:

                                                                                                  * {\n  stroke: blue;\n  label: [name];\n  font-fill: black;\n  label-offset: 7px;\n}\n
                                                                                                5. The font-fill property is set to black provides the label color.

                                                                                                  * {\n  stroke: blue;\n  label: [name];\n  font-fill: black;\n  label-offset: 7px;\n}\n
                                                                                                6. The label-offset property is used to adjust the starting position used for labeling.

                                                                                                  Normally the displacement offset is supplied using two numbers (allowing an x and y offset from the midway point used for LineString labeling).

                                                                                                  When labeling a LineString there is a special twist: by specifying a single number for label-offset we can ask the rendering engine to position our label a set distance away from the LineString.

                                                                                                  * {\n  stroke: blue;\n  label: [name];\n  font-fill: black;\n  label-offset: 7px;\n}\n
                                                                                                7. When used in this manner the rotation of the label will be adjusted automatically to match the LineString.

                                                                                                "},{"location":"styling/workshop/css/linestring/#how-labeling-works","title":"How Labeling Works","text":"

                                                                                                The rendering engine collects all the generated labels during the rendering of each layer. Then, during labeling, the engine sorts through the labels performing collision avoidance (to prevent labels overlapping). Finally the rendering engine draws the labels on top of the map. Even with collision avoidance you can spot areas where labels are so closely spaced that the result is hard to read.

                                                                                                To take greater control over the GeoServer rendering engine we can use extra parameters.

                                                                                                1. The ability to take control of the labeling process is exactly the kind of hint a extra parameter is intended for.

                                                                                                  Update line_example with the following:

                                                                                                  * {\n  stroke: blue;\n  label: [name];\n  font-fill: black;\n  label-offset: 7px;\n  label-padding: 10;\n}\n
                                                                                                2. The parameter label-padding provides additional space around our label for use in collision avoidance.

                                                                                                  * {\n  stroke: blue;\n  label: [name];\n  font-fill: black;\n  label-offset: 7px;\n  label-padding: 10;\n}\n
                                                                                                3. Each label is now separated from its neighbor, improving legibility.

                                                                                                "},{"location":"styling/workshop/css/linestring/#scale","title":"Scale","text":"

                                                                                                This section explores the use of attribute selectors and the @scale selector together to simplify the road dataset for display.

                                                                                                1. Replace the line_example CSS definition with:

                                                                                                  [scalerank < 4] {\n  stroke: black;\n}\n
                                                                                                2. And use the Map tab to preview the result.

                                                                                                3. The scalerank attribute is provided by the Natural Earth dataset to allow control of the level of detail based on scale. Our selector short-listed all content with scalerank 4 or lower, providing a nice quick preview when we are zoomed out.

                                                                                                4. In addition to testing feature attributes, selectors can also be used to check the state of the rendering engine.

                                                                                                  Replace your CSS with the following:

                                                                                                  [@scale > 35000000] {\n   stroke: black;\n}\n[@scale < 35000000] {\n   stroke: blue;\n}\n
                                                                                                5. As you adjust the scale in the Map preview (using the mouse scroll wheel) the color will change between black and blue. You can read the current scale in the bottom right corner, and the legend will change to reflect the current style.

                                                                                                6. Putting these two ideas together allows control of level detail based on scale:

                                                                                                  [@scale < 9000000] [scalerank > 7] {\n  stroke: #888888;\n}\n\n[@scale < 17000000] [scalerank = 7] {\n  stroke: #777777;\n}\n\n[@scale < 35000000] [scalerank = 6] {\n  stroke: #444444;\n}\n\n[@scale > 9000000] [@scale < 70000000] [scalerank = 5] {\n  stroke: #000055;\n}\n[@scale < 9000000] [scalerank = 5] {\n  stroke: #000055;\n  stroke-width: 2\n}\n\n[@scale > 35000000] [scalerank < 4] {\n  stroke: black;\n}\n[@scale > 9000000] [@scale <= 35000000] [scalerank < 4] {\n  stroke: black;\n  stroke-width: 2\n}\n[@scale <= 9000000] [scalerank < 4] {\n  stroke: black;\n  stroke-width: 4\n}\n
                                                                                                7. As shown above selectors can be combined in the same rule:

                                                                                                  • Selectors separated by blank-space are combined CQL Filter AND
                                                                                                  • Selectors separated by a comma are combined using CQL Filter OR

                                                                                                  Our first rule [[@scale < 9000000] [scalerank > 7]]{.title-ref} checks that the scale is less than 9M AND scalerank is greater than 7.

                                                                                                "},{"location":"styling/workshop/css/linestring/#bonus","title":"Bonus","text":"

                                                                                                Finished early? Here are some opportunities to explore what we have learned, and extra challenges requiring creativity and research.

                                                                                                In a classroom setting please divide the challenges between teams (this allows us to work through all the material in the time available).

                                                                                                Instructor Notes

                                                                                                As usual the Explore section invites readers to reapply the material covered in a slightly different context or dataset.

                                                                                                The use of selectors using the roads type attribute provides this opportunity.

                                                                                                "},{"location":"styling/workshop/css/linestring/#explore-follow-line-option","title":"Explore Follow Line Option","text":"

                                                                                                Options can be used to enable some quite useful effects, while still providing a style that can be used by other applications.

                                                                                                1. Update line_example with the following:

                                                                                                  * {\n  stroke: #ededff;\n  stroke-width: 10;\n  label: [level] \" \" [name];\n  font-fill: black;\n  label-follow-line: true;\n}\n
                                                                                                2. The property stroke-width has been used to make our line thicker in order to provide a backdrop for our label.

                                                                                                  * {\n  stroke: #ededff;\n  stroke-width: 10;\n  label: [level] \" \" [name];\n  font-fill: black;\n  label-follow-line: true;\n}\n
                                                                                                3. The label property combines combine several CQL expressions together for a longer label.

                                                                                                  * {\n  stroke: #ededff;\n  stroke-width: 10;\n  label: [level] \" \" [name];\n  font-fill: black;\n  label-follow-line: true;\n}\n

                                                                                                  The combined label property:

                                                                                                  [level] \" \" [name]\n

                                                                                                  Is internally represented with the Concatenate function:

                                                                                                  [Concatenate(level,' #', name)]\n
                                                                                                4. The property label-follow-line provides the ability of have a label exactly follow a LineString character by character.

                                                                                                  * {\n  stroke: #ededff;\n  stroke-width: 10;\n  label: [level] \" \" [name];\n  font-fill: black;\n  label-follow-line: true;\n}\n
                                                                                                5. The result is a new appearance for our roads.

                                                                                                "},{"location":"styling/workshop/css/linestring/#css.line.q0","title":"Challenge SLD Generation","text":"
                                                                                                1. Generate the SLD for the following CSS.

                                                                                                  * {\n  stroke: black;\n}\n

                                                                                                  What is unusual about the SLD code for this example?

                                                                                                2. Challenge: What is unusual about the generated SLD? Can you explain why it still works as expected?

                                                                                                  Note

                                                                                                  Answer provided <css.line.a0> at the end of the workbook.

                                                                                                "},{"location":"styling/workshop/css/linestring/#css.line.q1","title":"Challenge Classification","text":"
                                                                                                1. The roads type attribute provides classification information.

                                                                                                  You can Layer Preview to inspect features to determine available values for type.

                                                                                                2. Challenge: Create a new style adjust road appearance based on type.

                                                                                                  Hint: The available values are 'Major Highway','Secondary Highway','Road' and 'Unknown'.

                                                                                                  Note

                                                                                                  Answer provided <css.line.a1> at the end of the workbook.

                                                                                                "},{"location":"styling/workshop/css/linestring/#css.line.q2","title":"Challenge SLD Z-Index Generation","text":"
                                                                                                1. Review the SLD generated by the z-index example.

                                                                                                  * {\n  stroke: black, #8080E6;\n  stroke-width: 5px, 3px;\n  z-index: 0, 1;\n}\n
                                                                                                2. Challenge: There is an interesting trick in the generated SLD, can you explain how it works?

                                                                                                  Note

                                                                                                  Answer provided <css.line.a2> at the end of the workbook.

                                                                                                "},{"location":"styling/workshop/css/linestring/#css.line.q3","title":"Challenge Label Shields","text":"
                                                                                                1. The traditional presentation of roads in the US is the use of a shield symbol, with the road number marked on top.

                                                                                                2. Challenge: Have a look at the documentation and reproduce this technique.

                                                                                                  Note

                                                                                                  Answer provided <css.line.a3> at the end of the workbook.

                                                                                                "},{"location":"styling/workshop/css/point/","title":"Points","text":"

                                                                                                The next stop of the CSS styling tour is the representation of points.

                                                                                                Review of point symbology:

                                                                                                • Points are used to represent a location only, and do not form a shape. The visual width of lines do not change depending on scale.
                                                                                                • SLD uses a PointSymbolizer record how the shape of a line is drawn.
                                                                                                • Labeling of points is anchored to the point location.

                                                                                                As points have no inherent shape of their own, emphasis is placed on marking locations with an appropriate symbol.

                                                                                                Reference:

                                                                                                • Point Symbology (User Manual | CSS Property Listing)
                                                                                                • Points (User Manual | CSS Cookbook)
                                                                                                • Styled Marks (User Manual | CSS Styling )
                                                                                                • Point (User Manual | SLD Reference )

                                                                                                This exercise makes use of the ne:populated_places layer.

                                                                                                1. Navigate to the Styles page.

                                                                                                2. Click Add a new style and choose the following:

                                                                                                    • Name:
                                                                                                    • point_example
                                                                                                    • Workspace:
                                                                                                    • No workspace
                                                                                                    • Format:
                                                                                                    • CSS
                                                                                                3. Replace the initial CSS definition with the following and click apply:

                                                                                                  * {\n  mark: symbol(circle);\n}\n
                                                                                                4. And use the Layer Preview tab to preview the result.

                                                                                                "},{"location":"styling/workshop/css/point/#mark","title":"Mark","text":"

                                                                                                Points are represented with the mandatory property mark.

                                                                                                The SLD standard provides \"well-known\" symbols for use with point symbology: circle, square, triangle, arrow, cross, star, and x.

                                                                                                1. As a key property the presence mark triggers the generation of an appropriate PointSymbolizer.

                                                                                                  * {\n mark: symbol(square);\n}\n
                                                                                                2. Map Preview:

                                                                                                3. Before we continue we will use a selector to cut down the amount of data shown to a reasonable level.

                                                                                                  [ SCALERANK < 1 ] {\n  mark: symbol(square);\n}\n
                                                                                                4. Resulting in a considerably cleaner image:

                                                                                                5. Additional properties are available to control a mark's presentation:

                                                                                                  The mark-size property is used to control symbol size.

                                                                                                  The mark-rotation property controls orientation, accepting input in degrees.

                                                                                                  Trying these two settings together:

                                                                                                  [ SCALERANK < 1 ] {\n  mark: symbol(square);\n  mark-size: 8;\n  mark-rotation: 45;\n}\n
                                                                                                6. Results in each location being marked with a diamond:

                                                                                                7. Now that we have assigned our point location a symbol we can make use of a pseudo-selector to style the resulting shape.

                                                                                                  :symbol - provides styling for all the symbols in the CSS document.

                                                                                                  :mark - provides styling for all the mark symbols in the CSS document.

                                                                                                  This form of pseudo-selector is used for all marks:

                                                                                                  [ SCALERANK < 1 ] {\n  mark: symbol(square);\n  mark-size: 8;\n  mark-rotation: 45;\n}\n:mark{\n   fill: white;\n   stroke: black;\n}\n
                                                                                                8. Updating the mark to a white square with a black outline.

                                                                                                9. The second approach is used to individual configure symbols in the same document.

                                                                                                  :nth-symbol(1) - if needed we could specify which symbol in the document we wish to modify.

                                                                                                  :nth-mark(1) - provides styling for the first mark symbol in the CSS document.

                                                                                                  Using this approach marks can be composed of multiple symbols, each with its own settings:

                                                                                                  [ SCALERANK < 1 ] {\n  mark: symbol(square),symbol(cross);\n  mark-size: 16,14;\n  mark-rotation: 0,45;\n}\n:nth-mark(1){\n   fill: red;\n   stroke: black;\n}\n:nth-mark(2){\n   fill: black;\n   stroke: white;\n}\n
                                                                                                10. Producing an interesting compound symbol effect:

                                                                                                "},{"location":"styling/workshop/css/point/#graphic","title":"Graphic","text":"

                                                                                                Symbols can also be supplied by an external graphic,

                                                                                                This technique was shown with the initial ` CSS example.

                                                                                                1. To use an external graphic two pieces of information are required.

                                                                                                  mark property is defined with a url reference to image.

                                                                                                  mark-mime property is used to tell the rendering engine what file format to expect

                                                                                                  This technique is used to reference files placed in the styles directory.

                                                                                                  [ SCALERANK < 1 ] {\n  mark: url(port.svg);\n  mark-mime: \"image/svg\";\n}\n
                                                                                                2. Drawing the provided shape in each location:

                                                                                                3. The mark property url reference can also be used to reference external images. We can make use of the GeoServer logo.

                                                                                                  [ SCALERANK < 1 ] {\n     mark: url(\"http://localhost:8080/geoserver/web/wicket/resource/org.geoserver.web.GeoServerBasePage/img/logo.png\");\n     mark-mime: \"image/png\";\n     mark-size: 16;\n}\n
                                                                                                4. As shown in the map preview.

                                                                                                "},{"location":"styling/workshop/css/point/#label","title":"Label","text":"

                                                                                                Labeling is now familiar from our experience with LineString and Polygons.

                                                                                                The key properties mark and label are required to label Point locations.

                                                                                                1. Replace point_example with the following:

                                                                                                  [ SCALERANK < 1 ] {\n  mark: symbol(circle);\n  label: [NAME];\n}\n
                                                                                                2. Confirm the result in Map preview.

                                                                                                3. Each label is drawn starting from the provided point - which is unfortunate as it assures each label will overlap with the symbol used. To fix this limitation we will make use of the SLD controls for label placement:

                                                                                                  label-anchor provides two values expressing how a label is aligned with respect to the starting label position.

                                                                                                  label-offset is be used to provide an initial displacement using and x and y offset. For points this offset is recommended to adjust the label position away for the area used by the symbol.

                                                                                                  Note

                                                                                                  The property label-anchor defines an anchor position relative to the bounding box formed by the resulting label. This anchor position is snapped to the label position generated by the point location and displacement offset.

                                                                                                4. Using these two facilities together we can center our labels below the symbol, taking care that the displacement used provides an offset just outside the area required for the symbol size.

                                                                                                  [ SCALERANK < 1 ] {\n  mark: symbol(circle);\n  mark-size: 10;\n\n  label: [NAME];\n  label-offset: 0 -12;\n  label-anchor: 0.5 1.0;\n\n  font-fill: black;\n}\n
                                                                                                5. Each label is now placed under the mark.

                                                                                                6. One remaining issue is the overlap between labels and symbols.

                                                                                                  GeoServer provides a vendor specific parameter to allow symbols to take part in label conflict resolution, preventing labels from overlapping any symbols. This severely limits the area available for labeling and is best used in conjunction with a large maximum displacement vendor option.

                                                                                                  mark-label-obstacle vendor parameter asks the rendering engine to avoid drawing labels over top of the indicated symbol.

                                                                                                  label-max-displacement vendor parameter provides the rendering engine a maximum distance it is allowed to move labels during conflict resolution.

                                                                                                  label-padding vendor parameter tells the rendering engine to provide a minimum distance between the labels on the map, ensuring they do not overlap.

                                                                                                  Update our example to use these settings:

                                                                                                  [ SCALERANK < 1 ] {\n  mark: symbol(circle);\n  mark-size: 10;\n\n  label: [NAME];\n  label-offset: 0 -12;\n  label-anchor: 0.5 1.0;\n\n  font-fill: black;\n\n  mark-label-obstacle: true;\n  label-max-displacement: 100;\n  label-padding: 2;\n}\n
                                                                                                7. Resulting in a considerably cleaner image:

                                                                                                "},{"location":"styling/workshop/css/point/#dynamic-styling","title":"Dynamic Styling","text":"
                                                                                                1. We will quickly use scalerank to select content based on @scale selectors.

                                                                                                  [@scale < 4000000] {\n   mark: symbol(circle);\n}\n[@scale > 4000000] [@scale < 8000000] [SCALERANK < 7] {\n   mark: symbol(circle);\n}\n\n[@scale > 8000000] [@scale < 17000000] [SCALERANK < 5] {\n   mark: symbol(circle);\n}\n\n[@scale > 17000000] [@scale < 35000000] [SCALERANK < 4] {\n   mark: symbol(circle);\n}\n\n[@scale > 35000000] [@scale < 70000000][SCALERANK < 3] {\n   mark: symbol(circle);\n}\n\n[@scale > 70000000] [@scale < 140000000][SCALERANK < 2] {\n   mark: symbol(circle);\n}\n\n[@scale > 140000000] [SCALERANK < 1] {\n  mark: symbol(circle);\n}\n\n* {\n  mark-size: 6;\n}\n
                                                                                                2. Click Submit to update the Map after each step.

                                                                                                3. To add labeling we must use both the key properties mark and label in each scale selector, using rule cascading to define the mark-size and font information once.

                                                                                                  [@scale < 4000000] {\n   mark: symbol(circle);\n   label: [NAME];\n}\n[@scale > 4000000] [@scale < 8000000] [SCALERANK < 7] {\n   mark: symbol(circle);\n   label: [NAME];\n}\n\n[@scale > 8000000] [@scale < 17000000] [SCALERANK < 5] {\n   mark: symbol(circle);\n   label: [NAME];\n}\n\n[@scale > 17000000] [@scale < 35000000] [SCALERANK < 4] {\n   mark: symbol(circle);\n   label: [NAME];\n}\n\n[@scale > 35000000] [@scale < 70000000][SCALERANK < 3] {\n   mark: symbol(circle);\n   label: [NAME];\n}\n\n[@scale > 70000000] [@scale < 140000000][SCALERANK < 2] {\n   mark: symbol(circle);\n   label: [NAME];\n}\n\n[@scale > 140000000] [SCALERANK < 1] {\n   mark: symbol(circle);\n   label: [NAME];\n}\n\n* {\n  mark-size: 6;\n\n  font-fill: black;\n  font-family: \"Arial\";\n  font-size: 10;\n}\n

                                                                                                4. We will use label-offset and label-anchor to position the label above each symbol.

                                                                                                  Add the following two lines to the * selector:

                                                                                                  * {\n  mark-size: 6;\n\n  font-fill: black;\n  font-family: \"Arial\";\n  font-size: 10;\n\n  label-anchor: 0.5 0;\n  label-offset: 0 6;\n}\n

                                                                                                5. A little bit of work with vendor specific parameters will prevent our labels from colliding with each symbol, while giving the rendering engine some flexibility in how far it is allowed to relocate a label.

                                                                                                  Add the following vendor options to the * selector:

                                                                                                  * {\n  mark-size: 6;\n\n  font-fill: black;\n  font-family: \"Arial\";\n  font-size: 10;\n\n  label-anchor: 0.5 0;\n  label-offset: 0 6;\n\n  mark-label-obstacle: true;\n  label-max-displacement: 90;\n  label-padding: 2;\n}\n

                                                                                                6. Now that we have clearly labeled our cities, zoom into an area you are familiar with and we can look at changing symbology on a case-by-case basis.

                                                                                                  We have used expressions previous to generate an appropriate label. Expressions can also be used for many other property settings.

                                                                                                  The ne:populated_places layer provides several attributes specifically to make styling easier:

                                                                                                  • SCALERANK: we have already used this attribute to control the level of detail displayed
                                                                                                  • LABELRANK: hint used for conflict resolution, allowing important cities such as capitals to be labeled even when they are close to a larger neighbor.
                                                                                                  • FEATURECLA: used to indicate different types of cities. We will check for Admin-0 capital cities.

                                                                                                  The first thing we will do is calculate the mark-size using a quick expression:

                                                                                                  [10-(SCALERANK/2)]\n

                                                                                                  This expression should result in sizes between 5 and 9 and will need to be applied to both mark-size and label-offset.

                                                                                                  Rather than the \"first come first served\" default to resolve labeling conflicts we can manually provide GeoServer with a label priority. The expression provided is calculated for each label, in the event of a conflict the label with the highest priority takes precedence.

                                                                                                  The LABELRANK attribute goes from 1 through 10 and needs to be flipped around before use as a GeoServer label priority:

                                                                                                  [10 - LABELRANK]\n

                                                                                                  This expression will result in values between 0 and 10 and will be used for the label-priority.

                                                                                                  * {\n  mark-size: [10-(SCALERANK/2)];\n\n  font-fill: black;\n  font-family: \"Arial\";\n  font-size: 10;\n\n  label-anchor: 0.5 0;\n  label-offset: 0 [10-(SCALERANK/2)];\n\n  mark-label-obstacle: true;\n  label-max-displacement: 90;\n  label-padding: 2;\n  label-priority: [10 - LABELRANK];\n}\n

                                                                                                7. Next we can use FEATURECLA to check for capital cities.

                                                                                                  Adding a selector for capital cities at the top of the file:

                                                                                                  /* capitals */\n[@scale < 70000000]\n[FEATURECLA = 'Admin-0 capital']  {\n   mark: symbol(star);\n   label: [NAME];\n}\n[@scale > 70000000] [SCALERANK < 2]\n[FEATURECLA = 'Admin-0 capital']  {\n   mark: symbol(star);\n   label: [NAME];\n}\n

                                                                                                  And updating the populated places selectors to ignore capital cities:

                                                                                                  /* populated places */\n[@scale < 4000000]\n[FEATURECLA <> 'Admin-0 capital'] {\n   mark: symbol(circle);\n   label: [NAME];\n}\n[@scale > 4000000] [@scale < 8000000] [SCALERANK < 7]\n[FEATURECLA <> 'Admin-0 capital'] {\n   mark: symbol(circle);\n   label: [NAME];\n}\n\n[@scale > 8000000] [@scale < 17000000] [SCALERANK < 5]\n[FEATURECLA <> 'Admin-0 capital'] {\n   mark: symbol(circle);\n   label: [NAME];\n}\n\n[@scale > 17000000] [@scale < 35000000] [SCALERANK < 4]\n[FEATURECLA <> 'Admin-0 capital'] {\n   mark: symbol(circle);\n   label: [NAME];\n}\n\n[@scale > 35000000] [@scale < 70000000][SCALERANK < 3]\n[FEATURECLA <> 'Admin-0 capital'] {\n   mark: symbol(circle);\n   label: [NAME];\n}\n\n[@scale > 70000000] [@scale < 140000000][SCALERANK < 2]\n[FEATURECLA <> 'Admin-0 capital'] {\n   mark: symbol(circle);\n   label: [NAME];\n}\n\n[@scale > 140000000] [SCALERANK < 1]\n[FEATURECLA <> 'Admin-0 capital'] {\n   mark: symbol(circle);\n   label: [NAME];\n}\n

                                                                                                8. Finally we can fill in the capital city symbols using a combination of a selector to detect capital cities, and pseudo selector to provide mark styling.

                                                                                                  [FEATURECLA = 'Admin-0 capital'] :mark {\n  fill: black;\n}\n\n:symbol {\n  fill: gray;\n  stroke: black;\n}\n

                                                                                                9. If you would like to check your work the final file is here: point_example.css

                                                                                                "},{"location":"styling/workshop/css/point/#bonus","title":"Bonus","text":"

                                                                                                Instructor Notes

                                                                                                The exercise section does not review the examples above, instead it explores the use of:

                                                                                                • scale and attribute selectors
                                                                                                • recode to map from attribute to symbol
                                                                                                • interpolate to change size by population
                                                                                                "},{"location":"styling/workshop/css/point/#css.point.q1","title":"Challenge Geometry Location","text":"

                                                                                                Instructor Notes

                                                                                                As usual Explore invites readers to reapply the material covered in a slightly different context or dataset.

                                                                                                The use of selectors using the roads type attribute provides this opportunity.

                                                                                                1. The mark property can be used to render any geometry content.

                                                                                                2. Challenge: Try this yourself by rendering a polygon layer using a mark property.

                                                                                                  Note

                                                                                                  Answer discussed <ysld.point.a1> at the end of the workbook.

                                                                                                "},{"location":"styling/workshop/css/point/#css.point.q2","title":"Explore Dynamic Symbolization","text":"
                                                                                                1. We went to a lot of work to set up selectors to choose between symbol(star) and symbol(circle) for capital cities.

                                                                                                  This approach is straightforward when applied in isolation:

                                                                                                  [FEATURECLA = 'Admin-0 capital'] {\n   mark: symbol(star);\n}\n[FEATURECLA <> 'Admin-0 capital'] {\n   mark: symbol(circle);\n}\n

                                                                                                  When combined with checking another attribute, or checking @scale as in our example, this approach can quickly lead to many rules which can be difficult to keep straight.

                                                                                                2. Taking a closer look both symbol() and url() can actually be expressed using a string:

                                                                                                  [FEATURECLA = 'Admin-0 capital'] {\n   mark: symbol(\"star\");\n}\n

                                                                                                  Which is represented in SLD as:

                                                                                                  <sld:PointSymbolizer>\n  <sld:Graphic>\n     <sld:Mark>\n        <sld:WellKnownName>star</sld:WellKnownName>\n        <sld:Fill/>\n        <sld:Stroke/>\n     </sld:Mark>\n  </sld:Graphic>\n</sld:PointSymbolizer>\n
                                                                                                3. GeoServer recognizes this limitation of SLD Mark and ExternalGraphic and provides an opportunity for dynamic symbolization.

                                                                                                  This is accomplished by embedding a small CQL expression in the string passed to symbol or url. This sub-expression is isolated with \\${ } as shown:

                                                                                                  * {\n   mark: symbol(\n     \"${if_then_else(equalTo(FEATURECLA,'Admin-0 capital'),'star','circle')}\"\n   );\n}\n

                                                                                                  Which is represented in SLD as:

                                                                                                  <sld:PointSymbolizer>\n  <sld:Graphic>\n     <sld:Mark>\n        <sld:WellKnownName>${if_then_else(equalTo(FEATURECLA,'Admin-0 capital'),'star','circle')}</sld:WellKnownName>\n        <sld:Fill/>\n        <sld:Stroke/>\n     </sld:Mark>\n  </sld:Graphic>\n</sld:PointSymbolizer>\n
                                                                                                4. Challenge: Use this approach to rewrite the Dynamic Styling example.

                                                                                                  Note

                                                                                                  Answer provided <ysld.point.a2> at the end of the workbook.

                                                                                                1. Challenge: Use the Interpolate function to smoothly change mark-size based on city population.
                                                                                                "},{"location":"styling/workshop/css/point/#css.point.q3","title":"Challenge Layer Group","text":"
                                                                                                1. Use a Layer Group to explore how symbology works together to form a map.

                                                                                                  • ne:NE1
                                                                                                  • ne:states_provincces_shp
                                                                                                  • ne: populated_places
                                                                                                2. To help start things out here is a style for ne:states_provinces_shp:

                                                                                                  * {     \n   fill: white,[\n    recode(mapcolor9,\n      1,'#8dd3c7', 2,'#ffffb3', 3,'#bebada',\n      4,'#fb8072', 5,'#80b1d3', 6,'#fdb462',\n      7,'#b3de69', 8,'#fccde5', 9,'#d9d9d9')\n   ];\n   fill-opacity: 05%,50%;\n\n   stroke: black;\n   stroke-width: 0.25;\n   stroke-opacity: 50%;\n}\n
                                                                                                3. This background is relatively busy and care must be taken to ensure both symbols and labels are clearly visible.

                                                                                                4. Challenge: Do your best to style populated_places over this busy background.

                                                                                                  Here is an example with labels for inspiration:

                                                                                                  Note

                                                                                                  Answer provided <ysld.point.a3> at the end of the workbook.

                                                                                                "},{"location":"styling/workshop/css/point/#explore-true-type-fonts","title":"Explore True Type Fonts","text":"
                                                                                                1. In addition to image formats GeoServer can make use other kinds of graphics, such as True Type fonts:

                                                                                                  * {\n   mark: symbol(\"ttf://Webdings#0x0064\");\n}\n:mark {\n   stroke: blue;\n}\n
                                                                                                2. Additional fonts dropped in the styles directory are available for use.

                                                                                                "},{"location":"styling/workshop/css/point/#explore-custom-graphics","title":"Explore Custom Graphics","text":"
                                                                                                1. The GeoServer rendering engine allows Java developers to hook in additional symbol support.

                                                                                                  This facility is used by GeoServer to offer the shapes used for pattern fills. Community extensions allow the use of simple custom shapes and even charts.

                                                                                                2. Support has been added for custom graphics using the WKT Geometry representation.

                                                                                                  * {\n   mark: symbol(\"wkt://MULTILINESTRING((-0.25 -0.25, -0.125 -0.25), (0.125 -0.25, 0.25 -0.25), (-0.25 0.25, -0.125 0.25), (0.125 0.25, 0.25 0.25))\");\n}\n:mark {\n   stroke: blue;\n} \n
                                                                                                "},{"location":"styling/workshop/css/polygon/","title":"Polygons","text":"

                                                                                                Next we look at how CSS styling can be used to represent polygons.

                                                                                                Polygon Geometry

                                                                                                Review of polygon symbology:

                                                                                                • Polygons offer a direct representation of physical extent or the output of analysis.

                                                                                                • The visual appearance of polygons reflects the current scale.

                                                                                                • Polygons are recorded as a LinearRing describing the polygon boundary. Further LinearRings can be used to describe any holes in the polygon if present.

                                                                                                  The Simple Feature for SQL Geometry model (used by GeoJSON) represents these areas as Polygons, the ISO 19107 geometry model (used by GML3) represents these areas as Surfaces.

                                                                                                • SLD uses a PolygonSymbolizer to describe how the shape of a polygon is drawn. The primary characteristic documented is the Fill used to shade the polygon interior. The use of a Stroke to describe the polygon boundary is optional.

                                                                                                • Labeling of a polygon is anchored to the centroid of the polygon. GeoServer provides a vendor option to allow labels to line wrap to remain within the polygon boundaries.

                                                                                                For our Polygon exercises we will try and limit our CSS documents to a single rule, in order to showcase the properties used for rendering.

                                                                                                Reference:

                                                                                                • Polygon Symbology (User Manual | CSS Property Listing)
                                                                                                • Polygons (User Manual | CSS Cookbook)
                                                                                                • Polygons (User Manual | SLD Reference )

                                                                                                This exercise makes use of the ne:states_provinces_shp layer.

                                                                                                1. Navigate to Styles.

                                                                                                2. Create a new style polygon_example.

                                                                                                    • Name:
                                                                                                    • polygon_example
                                                                                                    • Workspace:
                                                                                                    • No workspace
                                                                                                    • Format:
                                                                                                    • CSS

                                                                                                3. Enter the following style and click ****Apply`` to save:

                                                                                                  * { fill: lightgrey; }\n
                                                                                                4. Click on the tab Layer Preview to preview.

                                                                                                5. Set ne:states_provinces_shp as the preview layer.

                                                                                                "},{"location":"styling/workshop/css/polygon/#stroke-and-fill","title":"Stroke and Fill","text":"

                                                                                                The key property for polygon data is fill.

                                                                                                The fill property is used to provide the color, or pattern, used to draw the interior of a polygon.

                                                                                                1. Replace the contents of polygon_example with the following fill example:

                                                                                                  * {\n   fill: gray;\n}\n
                                                                                                2. The Map tab can be used preview the change:

                                                                                                3. To draw the boundary of the polygon the stroke property is used:

                                                                                                  The stroke property is used to provide the color, or pattern, for the polygon boundary. It is effected by the same parameters (and vendor specific parameters) as used for LineStrings.

                                                                                                  * {\n   fill: gray;\n   stroke: black;\n   stroke-width: 2;\n}\n

                                                                                                  Note

                                                                                                  Technically the boundary of a polygon is a specific case of a LineString where the first and last vertex are the same, forming a closed LinearRing.

                                                                                                4. The effect of adding stroke is shown in the map preview:

                                                                                                5. An interesting technique when styling polygons in conjunction with background information is to control the fill opacity.

                                                                                                  The fill-opacity property is used to adjust transparency (provided as range from 0.0 to 1.0). Use of fill-opacity to render polygons works well in conjunction with a raster base map. This approach allows details of the base map to shown through.

                                                                                                  The stroke-opacity property is used in a similar fashion, as a range from 0.0 to 1.0.

                                                                                                  * {\n   fill: white;\n   fill-opacity: 50%;\n   stroke: lightgrey;\n   stroke-width: 0.25;\n   stroke-opacity: 50%;\n}\n
                                                                                                6. As shown in the map preview:

                                                                                                7. This effect can be better appreciated using a layer group.

                                                                                                  Where the transparent polygons is used lighten the landscape provided by the base map.

                                                                                                Instructor Notes

                                                                                                In this example we want to ensure readers know the key property for polygon data.

                                                                                                It is also our first example of using opacity.

                                                                                                "},{"location":"styling/workshop/css/polygon/#pattern","title":"Pattern","text":"

                                                                                                In addition to color, the fill property can also be used to provide a pattern.

                                                                                                The fill pattern is defined by repeating one of the built-in symbols, or making use of an external image.

                                                                                                1. We have two options for configuring a fill with a repeating graphic:

                                                                                                  Using url to reference to an external graphic. Used in conjunction with fill-mime property.

                                                                                                  Use of symbol to access a predefined shape. SLD provides several well-known shapes (circle, square, triangle, arrow, cross, star, and x). GeoServer provides additional shapes specifically for use as fill patterns.

                                                                                                  Update polygon_example with the following built-in symbol as a repeating fill pattern:

                                                                                                  * {\n   fill: symbol(square);\n}\n
                                                                                                2. The map preview (and legend) will show the result:

                                                                                                3. Add a black stroke:

                                                                                                  * {\n   fill: symbol(square);\n   stroke: black;\n}\n
                                                                                                4. To outline the individual shapes:

                                                                                                5. Additional fill properties allow control over the orientation and size of the symbol.

                                                                                                  The fill-size property is used to adjust the size of the symbol prior to use.

                                                                                                  The fill-rotation property is used to adjust the orientation of the symbol.

                                                                                                  Adjust the size and rotation as shown:

                                                                                                  * {\n   fill: symbol(square);\n   fill-size: 22px;\n   fill-rotation: 45;\n   stroke: black;\n}\n
                                                                                                6. The size of each symbol is increased, and each symbol rotated by 45 degrees.

                                                                                                  Note

                                                                                                  Does the above look correct? There is an open request GEOT-4642 to rotate the entire pattern, rather than each individual symbol.

                                                                                                  Instructor Notes

                                                                                                  Prior to GeoServer 2.5 a toRadians call was required as described in GEOT-4641.

                                                                                                  * {\n   fill: symbol(square);\n   fill-size: 22px;\n   fill-rotation: [toRadians(45)];\n}\n
                                                                                                7. The size and rotation properties just affect the size and placement of the symbol, but do not alter the symbol's design. In order to control the color we need to make use of a pseudo-selector. We have two options for referencing to our symbol above:

                                                                                                  :symbol provides styling for all the symbols in the CSS document.

                                                                                                  :fill provides styling for all the fill symbols in the CSS document.

                                                                                                8. Replace the contents of polygon_example with the following:

                                                                                                  * {\n   fill: symbol(square);\n}\n:fill {\n   fill: green;\n   stroke: darkgreen;\n}\n
                                                                                                9. This change adjusts the appearance of our grid of squares.

                                                                                                10. If you have more than one symbol:

                                                                                                  :nth-symbol(1) is used to specify which symbol in the document we wish to modify.

                                                                                                  :nth-fill(1) provides styling for the indicated fill symbol

                                                                                                  To rewrite our example to use this approach:

                                                                                                  * {\n   fill: symbol(square);\n}\n:nth-fill(1) {\n   fill: green;\n   stroke: darkgreen;\n}\n
                                                                                                11. Since we only have one fill in our CSS document the map preview looks identical.

                                                                                                12. The well-known symbols are more suited for marking individual points. Now that we understand how a pattern can be controlled it is time to look at the patterns GeoServer provides.

                                                                                                  shape://horizline horizontal hatching shape://vertline vertical hatching shape://backslash right hatching pattern shape://slash left hatching pattern shape://plus vertical and horizontal hatching pattern shape://times cross hatch pattern

                                                                                                  Update the example to use shape://slash for a pattern of left hatching.

                                                                                                  * {\n   fill: symbol('shape://slash');\n   stroke: black;\n}\n:fill {\n  stroke: gray;\n}\n
                                                                                                13. This approach is well suited to printed output or low color devices.

                                                                                                14. To control the size of the symbol produced use the fill-size property.

                                                                                                  * {\n   fill: symbol('shape://slash');\n   fill-size: 8;\n   stroke: black;\n}\n:fill {\n   stroke: green;\n}\n
                                                                                                15. This results in a tighter pattern shown:

                                                                                                16. Another approach (producing the same result is to use the size property on the appropriate pseudo-selector.

                                                                                                  * {\n   fill: symbol('shape://slash');\n   stroke: black;\n}\n:fill {\n   stroke: green;\n   size: 8;\n}\n
                                                                                                17. This produces the same visual result:

                                                                                                18. Multiple fills can be combined by supplying more than one fill as part of the same rule.

                                                                                                  Note the use of a comma to separate fill-size values (including the first fill-size value which is empty). This was the same approach used when combining strokes.

                                                                                                  * {\n   fill: #DDDDFF, symbol('shape://slash');\n   fill-size: '','8';\n   stroke: black;\n}\n:fill {\n   stroke: black;\n   stroke-width: 0.5;\n}\n
                                                                                                19. The resulting image has a solid fill, with a pattern drawn overtop.

                                                                                                "},{"location":"styling/workshop/css/polygon/#label","title":"Label","text":"

                                                                                                Labeling polygons follows the same approach used for LineStrings.

                                                                                                The key properties fill and label are used to enable Polygon label generation.

                                                                                                1. By default labels are drawn starting at the centroid of each polygon.

                                                                                                2. Try out label and fill together by replacing our polygon_example with the following:

                                                                                                  * {\n  stroke: blue;\n  fill: #7EB5D3;\n  label: [name];\n  font-fill: black;\n}\n
                                                                                                3. Each label is drawn from the lower-left corner as shown in the Map preview.

                                                                                                4. We can adjust how the label is drawn at the polygon centroid.

                                                                                                  The property label-anchor provides two numbers expressing how a label is aligned with respect to the centroid. The first value controls the horizontal alignment, while the second value controls the vertical alignment. Alignment is expressed between 0.0 and 1.0 as shown in the following table.

                                                                                                           Left      Center    Right\n

                                                                                                  Top 0.0 1.0 0.5 1.0 1.0 1.0

                                                                                                  Middle 0.0 0.5 0.5 0.5 1.0 0.5

                                                                                                  Bottom 0.0 0.0 0.5 0.0 1.0 0.0

                                                                                                  Adjusting the label-anchor is the recommended approach to positioning your labels.

                                                                                                5. Using the label-anchor property we can center our labels with respect to geometry centroid.

                                                                                                  To align the center of our label we select 50% horizontally and 50% vertically, by filling in 0.5 and 0.5 below:

                                                                                                  * {  stroke: blue;\n     fill: #7EB5D3;\n     label: [name];\n     font-fill: black;\n     label-anchor: 0.5 0.5;\n}\n
                                                                                                6. The labeling position remains at the polygon centroid. We adjust alignment by controlling which part of the label we are \"snapping\" into position.

                                                                                                7. The property label-offset can be used to provide an initial displacement using and x and y offset.

                                                                                                8. This offset is used to adjust the label position relative to the geometry centroid resulting in the starting label position.

                                                                                                  * {  stroke: blue;\n     fill: #7EB5D3;\n     label: [name];\n     font-fill: black;\n     label-offset: 0 7;\n}\n
                                                                                                9. Confirm this result in the map preview.

                                                                                                10. These two settings can be used together.

                                                                                                  The rendering engine starts by determining the label position generated from the geometry centroid and the label-offset displacement. The bounding box of the label is used with the label-anchor setting align the label to this location.

                                                                                                  Step 1: starting label position = centroid + displacement

                                                                                                  Step 2: snap the label anchor to the starting label position

                                                                                                11. To move our labels down (allowing readers to focus on each shape) we can use displacement combined with followed by horizontal alignment.

                                                                                                  * {  stroke: blue;\n     fill: #7EB5D3;\n     label: [name];\n     font-fill: black;\n     label-anchor: 0.5 1;\n     label-offset: 0 -7;\n }\n
                                                                                                12. As shown in the map preview.

                                                                                                "},{"location":"styling/workshop/css/polygon/#legibility","title":"Legibility","text":"

                                                                                                When working with labels a map can become busy very quickly, and difficult to read.

                                                                                                1. GeoServer provides extensive vendor parameters directly controlling the labelling process.

                                                                                                  Many of these parameters focus on controlling conflict resolution (when labels would otherwise overlap).

                                                                                                2. Two common properties for controlling labeling are:

                                                                                                  label-max-displacement indicates the maximum distance GeoServer should displace a label during conflict resolution.

                                                                                                  label-auto-wrap allows any labels extending past the provided width will be wrapped into multiple lines.

                                                                                                3. Using these together we can make a small improvement in our example:

                                                                                                  * {  stroke: blue;\n     fill: #7EB5D3;\n     label: [name];\n     font-fill: black;\n     label-anchor: 0.5 0.5;\n\n     label-max-displacement: 40;\n     label-auto-wrap: 70;\n   }\n
                                                                                                4. As shown in the following preview.

                                                                                                5. Even with this improved spacing between labels, it is difficult to read the result against the complicated line work.

                                                                                                  Use of a halo to outline labels allows the text to stand out from an otherwise busy background. In this case we will make use of the fill color, to provide some space around our labels. We will also change the font to Arial.

                                                                                                  * {  stroke: blue;\n     fill: #7EB5D3;\n     label: [name];\n     label-anchor: 0.5 0.5;\n     font-fill: black;\n     font-family: \"Arial\";\n     font-size: 14;\n     halo-radius: 2;\n     halo-color: #7EB5D3;\n     halo-opacity:0.8;\n\n     label-max-displacement: 40;\n     label-auto-wrap: 70;\n   }\n
                                                                                                6. By making use of halo-opacity we still allow stroke information to show through, but prevent the stroke information from making the text hard to read.

                                                                                                7. And advanced technique for manually taking control of conflict resolution is the use of the label-priority.

                                                                                                  This property takes an expression which is used in the event of a conflict. The label with the highest priority \"wins.\"

                                                                                                8. The Natural Earth dataset we are using includes a labelrank intended to control what labels are displayed based on zoom level.

                                                                                                  The values for labelrank go from 0 (for zoomed out) to 20 (for zoomed in). To use this value for label-priority we need to swap the values around so a scalerank of 1 is given the highest priority.

                                                                                                  * {  stroke: blue;\n     fill: #7EB5D3;\n     label: [name];\n     label-anchor: 0.5 0.5;\n     font-fill: black;\n     font-family: \"Arial\";\n     font-size: 14;\n     halo-radius: 2;\n     halo-color: #7EB5D3;\n     halo-opacity:0.8;\n\n     label-max-displacement: 40;\n     label-auto-wrap: 70;\n     label-priority: [20-labelrank];\n   }\n
                                                                                                9. In the following map East Flanders will take priority over Zeeland when the two labels overlap.

                                                                                                "},{"location":"styling/workshop/css/polygon/#theme","title":"Theme","text":"

                                                                                                A thematic map (rather than focusing on representing the shape of the world) uses elements of style to illustrate differences in the data under study. This section is a little more advanced and we will take the time to look at the generated SLD file.

                                                                                                Instructor Notes

                                                                                                This instruction section follows our pattern with LineString. Building on the examples and exploring how selectors can be used.

                                                                                                • For LineString we explored the use of @scale, in this section we are going to look at theming by attribute.
                                                                                                • We also unpack how cascading occurs, and what the result looks like in the generated XML.
                                                                                                • care is being taken to introduce the symbology encoding functions as an option for theming ( placing equal importance on their use).

                                                                                                Checklist:

                                                                                                • filter vs function for theming
                                                                                                • Cascading
                                                                                                1. We can use a site like ColorBrewer to explore the use of color theming for polygon symbology. In this approach the fill color of the polygon is determined by the value of the attribute under study.

                                                                                                  This presentation of a dataset is known as \"theming\" by an attribute.

                                                                                                2. For our ne:states_provinces_shp dataset, a mapcolor9 attribute has been provided for this purpose. Theming by mapcolor9 results in a map where neighbouring countries are visually distinct.

                                                                                                  +----------------------------+---------+---------+ | > Qualitative 9-class Set3 | | | +----------------------------+---------+---------+ | #8dd3c7 | #fb8072 | #b3de69 | +----------------------------+---------+---------+ | #ffffb3 | #80b1d3 | #fccde5 | +----------------------------+---------+---------+ | #bebada | #fdb462 | #d9d9d9 | +----------------------------+---------+---------+

                                                                                                  If you are unfamiliar with theming you may wish to visit http://colorbrewer2.org to learn more. The i icons provide an adequate background on theming approaches for qualitative, sequential and diverging datasets.

                                                                                                3. The first approach we will take is to directly select content based on colormap, providing a color based on the 9-class Set3 palette above:

                                                                                                  [mapcolor9=1] {\n   fill: #8dd3c7;\n}\n[mapcolor9=2] {\n   fill: #ffffb3;\n}\n[mapcolor9=3] {\n   fill: #bebada;\n}\n[mapcolor9=4] {\n   fill: #fb8072;\n}\n[mapcolor9=5] {\n   fill: #80b1d3;\n}\n[mapcolor9=6] {\n   fill: #fdb462;\n}\n[mapcolor9=7] {\n   fill: #b3de69;\n}\n[mapcolor9=8] {\n   fill: #fccde5;\n}\n[mapcolor9=9] {\n   fill: #d9d9d9;\n}\n* {\n  stroke: gray;\n  stroke-width: 0.5;\n}\n
                                                                                                4. The Map tab can be used to preview this result.

                                                                                                5. This CSS makes use of cascading to avoid repeating the stroke and stroke-width information multiple times.

                                                                                                  As an example the mapcolor9=2 rule, combined with the * rule results in the following collection of properties:

                                                                                                  [mapcolor9=2] {\n  fill: #ffffb3;\n  stroke: gray;\n  stroke-width: 0.5;\n}\n
                                                                                                6. Reviewing the generated SLD shows us this representation:

                                                                                                  <sld:Rule>\n   <ogc:Filter>\n      <ogc:PropertyIsEqualTo>\n         <ogc:PropertyName>mapcolor9</ogc:PropertyName>\n         <ogc:Literal>2</ogc:Literal>\n      </ogc:PropertyIsEqualTo>\n   </ogc:Filter>\n   <sld:PolygonSymbolizer>\n      <sld:Fill>\n         <sld:CssParameter name=\"fill\">#ffffb3</sld:CssParameter>\n      </sld:Fill>\n   </sld:PolygonSymbolizer>\n   <sld:LineSymbolizer>\n      <sld:Stroke>\n         <sld:CssParameter name=\"stroke\">#808080</sld:CssParameter>\n         <sld:CssParameter name=\"stroke-width\">0.5</sld:CssParameter>\n      </sld:Stroke>\n   </sld:LineSymbolizer>\n</sld:Rule>\n
                                                                                                7. There are three important functions, defined by the Symbology Encoding specification, that are often easier to use for theming than using rules.

                                                                                                  • Recode: Used the theme qualitative data. Attribute values are directly mapped to styling property such as fill or stroke-width.
                                                                                                  • Categorize: Used the theme quantitative data. Categories are defined using min and max ranges, and values are sorted into the appropriate category.
                                                                                                  • Interpolate: Used to smoothly theme quantitative data by calculating a styling property based on an attribute value.

                                                                                                  Theming is an activity, producing a visual result allow map readers to learn more about how an attribute is distributed spatially. We are free to produce this visual in the most efficient way possible.

                                                                                                8. Swap out mapcolor9 theme to use the Recode function:

                                                                                                  * {\n  fill:[\n    recode(mapcolor9,\n      1,'#8dd3c7', 2,'#ffffb3', 3,'#bebada',\n      4,'#fb8072', 5,'#80b1d3', 6,'#fdb462',\n      7,'#b3de69', 8,'#fccde5', 9,'#d9d9d9')\n  ]; \n  stroke: gray;\n  stroke-width: 0.5;\n}\n
                                                                                                9. The Map tab provides the same preview.

                                                                                                10. The Generated SLD tab shows where things get interesting. Our generated style now consists of a single Rule:

                                                                                                  <sld:Rule>\n   <sld:PolygonSymbolizer>\n      <sld:Fill>\n         <sld:CssParameter name=\"fill\">\n            <ogc:Function name=\"Recode\">\n               <ogc:PropertyName>mapcolor9</ogc:PropertyName>\n               <ogc:Literal>1</ogc:Literal>\n                  <ogc:Literal>#8dd3c7</ogc:Literal>\n               <ogc:Literal>2</ogc:Literal>\n                  <ogc:Literal>#ffffb3</ogc:Literal>\n               <ogc:Literal>3</ogc:Literal>\n                  <ogc:Literal>#bebada</ogc:Literal>\n               <ogc:Literal>4</ogc:Literal>\n                  <ogc:Literal>#fb8072</ogc:Literal>\n               <ogc:Literal>5</ogc:Literal>\n                  <ogc:Literal>#80b1d3</ogc:Literal>\n               <ogc:Literal>6</ogc:Literal>\n                  <ogc:Literal>#fdb462</ogc:Literal>\n               <ogc:Literal>7</ogc:Literal>\n                  <ogc:Literal>#b3de69</ogc:Literal>\n               <ogc:Literal>8</ogc:Literal>\n                  <ogc:Literal>#fccde5</ogc:Literal>\n               <ogc:Literal>9</ogc:Literal>\n                  <ogc:Literal>#d9d9d9</ogc:Literal>\n         </ogc:Function>\n         </sld:CssParameter>\n      </sld:Fill>\n   </sld:PolygonSymbolizer>\n   <sld:LineSymbolizer>\n      <sld:Stroke>\n         <sld:CssParameter name=\"stroke\">#808080</sld:CssParameter>\n         <sld:CssParameter name=\"stroke-width\">0.5</sld:CssParameter>\n      </sld:Stroke>\n   </sld:LineSymbolizer>\n</sld:Rule>\n
                                                                                                "},{"location":"styling/workshop/css/polygon/#bonus","title":"Bonus","text":"

                                                                                                The following optional explore and challenge activities offer a chance to review and apply the ideas introduced here. The challenge activities require a bit of creativity and research to complete.

                                                                                                In a classroom setting you are encouraged to team up into groups, with each group taking on a different challenge.

                                                                                                "},{"location":"styling/workshop/css/polygon/#css.polygon.q1","title":"Explore Antialiasing","text":"
                                                                                                1. When we rendered our initial preview, without a stroke, thin white gaps (or slivers) are visible between our polygons.

                                                                                                  This effect is made more pronounced by the rendering engine making use of the Java 2D sub-pixel accuracy. This technique is primarily used to prevent an aliased (stair-stepped) appearance on diagonal lines.

                                                                                                2. Clients can turn this feature off using a GetMap format option:

                                                                                                  format_options=antialiasing=off;\n

                                                                                                  The LayerPreview provides access to this setting from the Open Layers Options Toolbar:

                                                                                                3. Explore: Experiment with fill and stroke settings to eliminate slivers between polygons.

                                                                                                  Note

                                                                                                  Answer provided <css.polygon.a1> at the end of the workbook.

                                                                                                "},{"location":"styling/workshop/css/polygon/#css.polygon.q2","title":"Explore Categorize","text":"

                                                                                                Instructor Notes

                                                                                                This section reviews use of the Symbology Encoding Categorize function for something else other than color. Goal is to have readers reach for SE Functions as often as selectors when styling.

                                                                                                Additional exercise ideas:

                                                                                                • Control size using Interpolate: While Recode offers an alternative for selectors (matching discrete values) Interpolate brings something new to the table - gradual color (or value) progression. The best of example of this is controlling width using the ne:rivers data layer (which is not yet available).
                                                                                                1. The Categorize function can be used to generate property values based on quantitative information. Here is an example using Categorize to color states according to size.

                                                                                                  * {\n   fill: [\n      Categorize(Shape_Area,\n         '#08519c', 0.5,\n         '#3182bd', 1,\n         '#6baed6', 5,\n         '#9ecae1', 60,\n         '#c6dbef', 80,\n         '#eff3ff')\n   ];\n}\n

                                                                                                2. An exciting use of the GeoServer shape symbols is the theming by changing the fill-size used for pattern density.

                                                                                                3. Explore: Use the Categorize function to theme by datarank.

                                                                                                  Note

                                                                                                  Answer provided <css.polygon.a2> at the end of the workbook.

                                                                                                "},{"location":"styling/workshop/css/polygon/#css.polygon.q3","title":"Challenge Goodness of Fit","text":"
                                                                                                1. A subject we touched on during labeling was the conflict resolution GeoServer performs to ensure labels do not overlap.

                                                                                                2. In addition to the vendor parameter for max displacement you can experiment with different values for \"goodness of fit\". These settings control how far GeoServer is willing to move a label to avoid conflict, and under what terms it simply gives up:

                                                                                                  label-fit-goodness: 0.3;\nlabel-max-displacement: 130;\n
                                                                                                3. You can also experiment with turning off this facility completely:

                                                                                                  label-conflict-resolution: false;\n
                                                                                                4. Challenge: Construct your own example using max displacement and fit-goodness.

                                                                                                "},{"location":"styling/workshop/css/polygon/#css.polygon.q4","title":"Challenge Halo","text":"
                                                                                                1. The halo example used the fill color and opacity for a muted halo, while this improved readability it did not bring attention to our labels.

                                                                                                  A common design choice for emphasis is to outline the text in a contrasting color.

                                                                                                2. Challenge: Produce a map that uses a white halo around black text.

                                                                                                  Note

                                                                                                  Answer provided <css.polygon.a4> at the end of the workbook.

                                                                                                "},{"location":"styling/workshop/css/polygon/#css.polygon.q5","title":"Challenge Theming using Multiple Attributes","text":"
                                                                                                1. A powerful tool is theming using multiple attributes. This is an important concept allowing map readers to perform \"integration by eyeball\" (detecting correlations between attribute values information).

                                                                                                2. Challenge: Combine the mapcolor9 and datarank examples to reproduce the following map.

                                                                                                  Note

                                                                                                  Answer provided <css.polygon.a5> at the end of the workbook.

                                                                                                "},{"location":"styling/workshop/css/polygon/#css.polygon.q6","title":"Challenge Use of Z-Index","text":"
                                                                                                1. Earlier we looked at using z-index to simulate line string casing. The line work was drawn twice, once with thick line, and then a second time with a thinner line. The resulting effect is similar to text halos - providing breathing space around complex line work allowing it to stand out.

                                                                                                2. Challenge: Use what you know of LineString z-index to reproduce the following map:

                                                                                                ::: note ::: title Note :::

                                                                                                Answer provided <css.polygon.a6> at the end of the workbook. :::

                                                                                                "},{"location":"styling/workshop/css/raster/","title":"Rasters","text":"

                                                                                                Finally we will look at using CSS styling for the portrayal of raster data.

                                                                                                Raster Symbology

                                                                                                Review of raster symbology:

                                                                                                • Raster data is Grid Coverage where values have been recorded in a regular array. In OGC terms a Coverage can be used to look up a value or measurement for each location.

                                                                                                • When queried with a \"sample\" location:

                                                                                                  • A grid coverage can determine the appropriate array location and retrieve a value. Different techniques may be used interpolate an appropriate value from several measurements (higher quality) or directly return the \"nearest neighbor\" (faster).
                                                                                                  • A vector coverages would use a point-in-polygon check and return an appropriate attribute value.
                                                                                                  • A scientific model can calculate a value for each sample location
                                                                                                • Many raster formats organize information into bands of content. Values recorded in these bands and may be mapped into colors for display (a process similar to theming an attribute for vector data).

                                                                                                  For imagery the raster data is already formed into red, green and blue bands for display.

                                                                                                • As raster data has no inherent shape, the format is responsible for describing the orientation and location of the grid used to record measurements.

                                                                                                These raster examples use a digital elevation model consisting of a single band of height measurements. The imagery examples use an RGB image that has been hand coloured for use as a base map.

                                                                                                Reference:

                                                                                                • Raster Symbology (User Manual | CSS Property Listing )
                                                                                                • Rasters (User Manual | CSS Cookbook );
                                                                                                • Point (User Manual | SLD Reference )

                                                                                                The exercise makes use of the usgs:dem and ne:ne1 layers.

                                                                                                "},{"location":"styling/workshop/css/raster/#image","title":"Image","text":"

                                                                                                The raster-channels is the key property for display of images and raster data. The value auto is recommended, allowing the image format to select the appropriate red, green and blue channels for display.

                                                                                                1. Navigate to the Styles page.

                                                                                                2. Click Add a new style and choose the following:

                                                                                                    • Name:
                                                                                                    • image_example
                                                                                                    • Workspace:
                                                                                                    • No workspace
                                                                                                    • Format:
                                                                                                    • CSS
                                                                                                3. Replace the initial CSS definition with:

                                                                                                  * {\n  raster-channels: auto;\n}\n
                                                                                                4. And use the Layer Preview tab to preview the result.

                                                                                                5. If required a list three band numbers can be supplied (for images recording in several wavelengths) or a single band number can be used to view a grayscale image.

                                                                                                  * {\n  raster-channels: 2;\n}\n
                                                                                                6. Isolating just the green band (it will be drawn as a grayscale image):

                                                                                                "},{"location":"styling/workshop/css/raster/#dem","title":"DEM","text":"

                                                                                                A digital elevation model is an example of raster data made up of measurements, rather than colors information.

                                                                                                The usgs:dem layer used for this exercise:

                                                                                                1. Return to the Styles page.

                                                                                                2. Click Add a new style and choose the following:

                                                                                                    • Name:
                                                                                                    • raster_example
                                                                                                    • Workspace:
                                                                                                    • No workspace
                                                                                                    • Format:
                                                                                                    • CSS
                                                                                                3. When we use the raster-channels property set to auto the rendering engine will select our single band of raster content, and do its best to map these values into a grayscale image. Replace the content of the style with:

                                                                                                  * {\n  raster-channels: auto;\n}\n
                                                                                                4. Use the Layer Preview tab to preview the result. The range produced in this case from the highest and lowest values.

                                                                                                5. We can use a bit of image processing to emphasis the generated color mapping by making use raster-contrast-enhancement.

                                                                                                  * {\n  raster-channels: 1;\n  raster-contrast-enhancement: histogram;\n}\n
                                                                                                6. Image processing of this sort should be used with caution as it does distort the presentation (in this case making the landscape look more varied then it is in reality.

                                                                                                "},{"location":"styling/workshop/css/raster/#color-map","title":"Color Map","text":"

                                                                                                The approach of mapping a data channel directly to a color channel is only suitable to quickly look at quantitative data.

                                                                                                For qualitative data (such as land use) or simply to use color, we need a different approach:

                                                                                                1. Apply the following CSS to our usgs:DEM layer:

                                                                                                  * {\n  raster-channels: auto;\n  raster-color-map: color-map-entry(#9080DB, 0)\n                    color-map-entry(#008000, 1)\n                    color-map-entry(#105020, 255)\n                    color-map-entry(#FFFFFF, 4000);\n}\n
                                                                                                2. Resulting in this artificial color image:

                                                                                                3. An opacity value can also be used with color-map-entry.

                                                                                                  * {\n  raster-channels: auto;\n  raster-color-map: color-map-entry(#9080DB, 0, 0.0)\n                    color-map-entry(#008000, 1, 1.0)\n                    color-map-entry(#105020, 200, 1.0)\n                    color-map-entry(#FFFFFF, 4000, 1.0);\n}\n
                                                                                                4. Allowing the areas of zero height to be transparent:

                                                                                                5. Raster format for GIS work often supply a \"no data\" value, or contain a mask, limiting the dataset to only the locations with valid information.

                                                                                                "},{"location":"styling/workshop/css/raster/#custom","title":"Custom","text":"

                                                                                                We can use what we have learned about color maps to apply a color brewer palette to our data.

                                                                                                This exploration focuses on accurately communicating differences in value, rather than strictly making a pretty picture. Care should be taken to consider the target audience and medium used during palette selection.

                                                                                                1. Restore the raster_example CSS style to the following:

                                                                                                  * {\n  raster-channels: auto;\n}\n
                                                                                                2. Producing the following map preview.

                                                                                                3. To start with we can provide our own grayscale using two color map entries.

                                                                                                  * {\n  raster-channels: auto;\n  raster-color-map: color-map-entry(#000000, 0)\n                    color-map-entry(#FFFFFF, 4000);\n}\n
                                                                                                4. Use the Map tab to zoom in and take a look.

                                                                                                  This is much more direct representation of the source data. We have used our knowledge of elevations to construct a more accurate style.

                                                                                                5. While our straightforward style is easy to understand, it does leave a bit to be desired with respect to clarity.

                                                                                                  The eye has a hard time telling apart dark shades of black (or bright shades of white) and will struggle to make sense of this image. To address this limitation we are going to switch to the ColorBrewer 9-class PuBuGn palette. This is a sequential palette that has been hand tuned to communicate a steady change of values.

                                                                                                6. Update your style with the following:

                                                                                                  * {\n  raster-channels: auto;\n  raster-color-map:\n     color-map-entry(#014636,   0)\n     color-map-entry(#016c59, 500)\n     color-map-entry(#02818a,1000)\n     color-map-entry(#3690c0,1500)\n     color-map-entry(#67a9cf,2000)\n     color-map-entry(#a6bddb,2500)\n     color-map-entry(#d0d1e6,3000)\n     color-map-entry(#ece2f0,3500)\n     color-map-entry(#fff7fb,4000);\n}\n

                                                                                                7. A little bit of work with alpha (to mark the ocean as a no-data section):

                                                                                                  * {\n  raster-channels: auto;\n  raster-color-map:\n     color-map-entry(#014636,   0,0)\n     color-map-entry(#014636,   1)\n     color-map-entry(#016c59, 500)\n     color-map-entry(#02818a,1000)\n     color-map-entry(#3690c0,1500)\n     color-map-entry(#67a9cf,2000)\n     color-map-entry(#a6bddb,2500)\n     color-map-entry(#d0d1e6,3000)\n     color-map-entry(#ece2f0,3500)\n     color-map-entry(#fff7fb,4000);\n}\n
                                                                                                8. And we are done:

                                                                                                "},{"location":"styling/workshop/css/raster/#bonus","title":"Bonus","text":""},{"location":"styling/workshop/css/raster/#css.raster.q1","title":"Explore Contrast Enhancement","text":"
                                                                                                1. A special effect that is effective with grayscale information is automatic contrast adjustment.

                                                                                                2. Make use of a simple contrast enhancement with usgs:dem:

                                                                                                  * {\n    raster-channels: auto;\n    raster-contrast-enhancement: normalize;\n}\n
                                                                                                3. Can you explain what happens when zoom in to only show a land area (as indicated with the bounding box below)?

                                                                                                  Note

                                                                                                  Discussion provided <ysld.raster.a1> at the end of the workbook.

                                                                                                "},{"location":"styling/workshop/css/raster/#css.raster.q2","title":"Challenge Intervals","text":"
                                                                                                1. The raster-color-map-type property dictates how the values are used to generate a resulting color.

                                                                                                  • ramp is used for quantitative data, providing a smooth interpolation between the provided color values.
                                                                                                  • intervals provides categorization for quantitative data, assigning each range of values a solid color.
                                                                                                  • values is used for qualitative data, each value is required to have a color-map-entry or it will not be displayed.
                                                                                                2. Challenge: Update your DEM example to use intervals for presentation. What are the advantages of using this approach for elevation data?

                                                                                                  Note

                                                                                                  Answer provided <ysld.raster.a2> at the end of the workbook.

                                                                                                  Instructor Notes

                                                                                                  By using intervals it becomes very clear how relatively flat most of the continent is. The ramp presentation provided lots of fascinating detail which distracted from this fact.

                                                                                                  Here is style for you to cut and paste:

                                                                                                  * {\n  raster-channels: auto;\n  raster-color-map:\n     color-map-entry(#014636,   0,0)\n     color-map-entry(#014636,   1)\n     color-map-entry(#016c59, 500)\n     color-map-entry(#02818a,1000)\n     color-map-entry(#3690c0,1500)\n     color-map-entry(#67a9cf,2000)\n     color-map-entry(#a6bddb,2500)\n     color-map-entry(#d0d1e6,3000)\n     color-map-entry(#ece2f0,3500)\n     color-map-entry(#fff7fb,4000);\n  raster-color-map-type: intervals;\n}\n

                                                                                                "},{"location":"styling/workshop/css/raster/#explore-image-processing","title":"Explore Image Processing","text":"

                                                                                                Additional properties are available to provide slight image processing during visualization.

                                                                                                Note

                                                                                                In this section are we going to be working around a preview issue where only the top left corner of the raster remains visible during image processing. This issue has been reported as GEOS-6213.

                                                                                                Image processing can be used to enhance the output to highlight small details or to balance images from different sensors allowing them to be compared.

                                                                                                1. The raster-contrast-enhancement property is used to turn on a range of post processing effects. Settings are provided for normalize or histogram or none;

                                                                                                  * {\n    raster-channels: auto;\n    raster-contrast-enhancement: normalize;\n}\n
                                                                                                2. Producing the following image:

                                                                                                3. The raster-gamma property is used adjust the brightness of raster-contrast-enhancement output. Values less than 1 are used to brighten the image while values greater than 1 darken the image.

                                                                                                  * {\n   raster-channels: auto;\n   raster-contrast-enhancement: none;\n   raster-gamma: 1.5;\n}\n
                                                                                                4. Providing the following effect:

                                                                                                "},{"location":"styling/workshop/css/raster/#css.raster.q3","title":"Challenge Clear Digital Elevation Model Presentation","text":"
                                                                                                1. Now that you have seen the data on screen and have a better understanding how would you modify our initial gray-scale example?

                                                                                                2. Challenge: Use what you have learned to present the usgs:dem clearly.

                                                                                                  Note

                                                                                                  Answer provided <ysld.raster.a3> at the end of the workbook.

                                                                                                  Instructor Notes

                                                                                                  The original was a dark mess, students will hopefully make use of the mid-tones (or even check color brewer) in order to fix this. I have left the ocean dark so the mountains can stand out more.

                                                                                                  * {\n  raster-channels: auto;\n  raster-color-map: color-map-entry(#000000, 0)\n                    color-map-entry(#444444, 1)\n                    color-map-entry(#FFFFFF, 3000);\n}\n

                                                                                                "},{"location":"styling/workshop/css/raster/#css.raster.q4","title":"Challenge Raster Opacity","text":"
                                                                                                1. There is a quick way to make raster data transparent, raster-opacity property works in the same fashion as with vector data. The raster as a whole will be drawn partially transparent allow content from other layers to provide context.

                                                                                                2. Challenge: Can you think of an example where this would be useful?

                                                                                                  Note

                                                                                                  Discussion provided <ysld.raster.a4> at the end of the workbook.

                                                                                                "},{"location":"styling/workshop/design/","title":"Design","text":"

                                                                                                This section introduces mapping as a tool for visual communication.

                                                                                                • Symbology
                                                                                                • Style

                                                                                                Note

                                                                                                This section uses Open Geospatial Consortium (OGC) terminology in our description of geometry and spatial data. While the terms we use here are general purpose, they may differ slightly from those you are familiar with.

                                                                                                References:

                                                                                                • Geographic Markup Language
                                                                                                • OGC Reference Model (OGC Portal)
                                                                                                • ISO 19107 Geographic information -- Spatial schema (ISO)
                                                                                                • How to Lie with Maps
                                                                                                • Cartography And Map Terminologies
                                                                                                "},{"location":"styling/workshop/design/style/","title":"Style","text":"

                                                                                                The design choices made to represent content is a key aspect of cartography. The style used when rendering data into a visualisation is the result of these choices.

                                                                                                The Open Geospatial Consortium standard for recording style is divided into two parts:

                                                                                                • Symbology Encoding (SE): Records a \"feature type style\" documenting how individual features are drawn using a series of rules.
                                                                                                • Style Layer Descriptor (SLD): Records which \"feature type styles\" may be used with a layer.

                                                                                                The Symbology Encoding standard provides the terms we will be using to describe style:

                                                                                                • Stroke: borders and outlines of shapes
                                                                                                • Fill: interior of shapes
                                                                                                "},{"location":"styling/workshop/design/style/#line-symbolizer","title":"Line symbolizer","text":"

                                                                                                A line symbolizer documents how individual strokes are used to draw a line string, including color and line width.

                                                                                                The SLD specification provides a default stroke used when drawing line strings. These values for color and width will be used if needed.

                                                                                                <LineSymbolizer>\n  <Stroke/>\n</LineSymbolizer>\n

                                                                                                GeoServer includes a default line.sld file providing a blue stroke. This file is used when you initially set up a linestring layer.

                                                                                                From GeoServer's line.sld style:

                                                                                                <LineSymbolizer>\n  <Stroke>\n    <CssParameter name=\"stroke\">#0000FF</CssParameter>\n  </Stroke>\n</LineSymbolizer>\n
                                                                                                "},{"location":"styling/workshop/design/style/#polygon-symbolizer","title":"Polygon symbolizer","text":"

                                                                                                A polygon symbolizer documents both the stroke in addition to the fill used to draw a polygon. A fill can consist of a color, pattern, or other texture:

                                                                                                The SLD specification provides a default gray fill, but does not supply a stroke. These values will be used if you do not provide an alternative.

                                                                                                GeoServer includes a default polygon.sld file providing a gray fill and a black outline. This file will be used when you initially create a polygon layer.

                                                                                                From GeoServer's polygon.sld style:

                                                                                                <PolygonSymbolizer>\n  <Fill>\n    <CssParameter name=\"fill\">#AAAAAA</CssParameter>\n  </Fill>\n  <Stroke>\n    <CssParameter name=\"stroke\">#000000</CssParameter>\n    <CssParameter name=\"stroke-width\">1</CssParameter>\n  </Stroke>\n</PolygonSymbolizer>\n
                                                                                                "},{"location":"styling/workshop/design/style/#point-symbolizer","title":"Point symbolizer","text":"

                                                                                                A point symbolizer documents the \"mark\" used to represent a point. A mark may be defined by a glyph (icon) or a common mark (circle, square, etc.). The point symbolizer records the stroke and fill used to draw the mark.

                                                                                                From GeoServer's default point.sld style:

                                                                                                <PointSymbolizer>\n  <Graphic>\n    <Mark>\n      <WellKnownName>square</WellKnownName>\n      <Fill>\n        <CssParameter name=\"fill\">#FF0000</CssParameter>\n      </Fill>\n    </Mark>\n    <Size>6</Size>\n  </Graphic>\n</PointSymbolizer>\n
                                                                                                "},{"location":"styling/workshop/design/style/#text-symbolizer","title":"Text symbolizer","text":"

                                                                                                A text symbolizer provides details on how labels are to be drawn, including font, size, and color information.

                                                                                                From the populated_places.sld style:

                                                                                                <sld:TextSymbolizer>\n    <sld:Label>\n        <ogc:PropertyName>NAME</ogc:PropertyName>\n    </sld:Label>\n    <sld:Font>\n        <sld:CssParameter name=\"font-family\">Arial</sld:CssParameter>\n        <sld:CssParameter name=\"font-size\">10.0</sld:CssParameter>\n        <sld:CssParameter name=\"font-style\">normal</sld:CssParameter>\n        <sld:CssParameter name=\"font-weight\">bold</sld:CssParameter>\n    </sld:Font>\n    <sld:Halo>\n        <sld:Radius>1</sld:Radius>\n        <sld:Fill>\n            <sld:CssParameter name=\"fill\">#FFFFFF</sld:CssParameter>\n        </sld:Fill>\n    </sld:Halo>\n    <sld:Fill>\n        <sld:CssParameter name=\"fill\">#000000</sld:CssParameter>\n    </sld:Fill>\n</sld:TextSymbolizer>\n

                                                                                                Note

                                                                                                The Style Layer Descriptor standard makes use of the Filter Encoding specification to create small expressions as shown above to access the NAME of each city:

                                                                                                <ogc:PropertyName>NAME</ogc:PropertyName>\n

                                                                                                This same approach can be used to dynamically generate any values needed for styling.

                                                                                                "},{"location":"styling/workshop/design/style/#raster-symbolizer","title":"Raster symbolizer","text":"

                                                                                                A raster symbolizer provides a mapping from raster values to colors displayed. This can be provided by a color table, function, or directly mapping bands of data to use for the display channels.

                                                                                                From GeoServer's dem.sld style:

                                                                                                <RasterSymbolizer>\n  <Opacity>1.0</Opacity>\n  <ColorMap>\n    <ColorMapEntry color=\"#000000\" quantity=\"-500\" label=\"nodata\" opacity=\"0.0\" />\n    <ColorMapEntry color=\"#AAFFAA\" quantity=\"0\" label=\"values\" />\n    <ColorMapEntry color=\"#00FF00\" quantity=\"1000\"/>\n    <ColorMapEntry color=\"#FFFF00\" quantity=\"1200\" label=\"values\" />\n    <ColorMapEntry color=\"#FF7F00\" quantity=\"1400\" label=\"values\" />\n    <ColorMapEntry color=\"#BF7F3F\" quantity=\"1600\" label=\"values\" />\n    <ColorMapEntry color=\"#000000\" quantity=\"2000\" label=\"values\" />\n  </ColorMap>\n</RasterSymbolizer>\n
                                                                                                "},{"location":"styling/workshop/design/symbology/","title":"Symbology","text":"

                                                                                                In cartography, symbology is the practice of representing information using shapes, colors and symbols on a map.

                                                                                                A map legend, offers a quick summary of the symbology used for a map.

                                                                                                The symbology for each layer should be distinct, allowing readers to clearly understand the information being presented. Care should be taken to consider the situation in which the map will be used, such as:

                                                                                                • Screen size of the output device
                                                                                                • Ability of target device to reproduce color
                                                                                                • Allowances for disabilities such as color blindness
                                                                                                "},{"location":"styling/workshop/design/symbology/#theme","title":"Theme","text":"

                                                                                                For thematic maps, the symbology is changed on a feature-by-feature basis in order to illustrate the attribute values being presented.

                                                                                                The same data set may be represented in different maps, themed by a different attribute each time.

                                                                                                "},{"location":"styling/workshop/design/symbology/#using-multiple-themes","title":"Using Multiple Themes","text":"

                                                                                                A single map can be produced showing two datasets (each themed by a different attribute) allowing readers to look for any interesting patterns.

                                                                                                As an example there may be a relationship between a country's growing region and annual rainfall.

                                                                                                "},{"location":"styling/workshop/design/symbology/#map-icons","title":"Map Icons","text":"

                                                                                                The use of map icons (pictograms, glyphs or symbology sets) is a special case where we have a gap in terminology between Cartography and GIS.

                                                                                                As an example we may wish to represent a point-of-interest data set with each location marked by a different symbol.

                                                                                                In cartography, each \"type\" is presented to the user as a clearly distinct data set with its own visual representation in the map legend.

                                                                                                This is contrasted with GIS, where the \"points of interest\" are managed as a single layer and complex styling is used to produce the desired cartographic output.

                                                                                                Technically the data set is themed by an attribute to produce this effect:

                                                                                                • Often an attribute named type is introduced, and styling rules are used to associated each value with a distinct graphic mark.
                                                                                                • Another common solution is to distribute the \"symbology set\" as TrueType font. A character attribute is introduced, the value of which is the appropriate letter to draw.
                                                                                                "},{"location":"styling/workshop/design/symbology/#map-design","title":"Map Design","text":"

                                                                                                The choice of how to present content is the subject of map design. Cartography, like any venue for design, is a human endeavor between art and science. In this exercise we are going to explore the trade offs in the use of color for effective communication.

                                                                                                It is a challenge to explore cartography without getting stuck in the details of configuring style (which we will cover next). In order to side-step these details, we will be using a web application for this section: Color Brewer by Cynthia Brewer of Pennsylvania State University.

                                                                                                Selection of an appropriate color palette is difficult, with a tension between what looks good and what can be understood. The research project that produced the color palettes used by Color Brewer was based on comprehension tests.

                                                                                                1. Navigate to: http://colorbrewer2.org/

                                                                                                  The website provides a generic data set which we can use to determine how effective each choice is in communicating attribute differences. We will be using this website to explore how to effectively theme an attribute.

                                                                                                  Color Brewer

                                                                                                2. The decisions we make when theming depend entirely on what point we are trying to communicate.

                                                                                                  In this scenario, we are going to communicate a vaccination schedule, county by county. Care should be taken to ensure each county appears equally important, and we should stay clear of red for anyone squeamish about needles. We need to ensure readers can quickly locate their county and look at the appropriate calendar entry.

                                                                                                3. The first step is determining how many attribute values you are looking to communicate. Set Number of data classes to 5.

                                                                                                  Number of data classes

                                                                                                4. Color brewer offers palettes using three different color schemes:

                                                                                                  Sequential

                                                                                                  Diverging

                                                                                                  Qualitative

                                                                                                  The nature of our data is qualitative (each attribute value is attached an equal importance, and there is no implied order that wish to communicate with color).

                                                                                                5. Set Nature of your data to Qualitative. This change drastically reduces the number of color schemes listed.

                                                                                                  Qualitative color scheme

                                                                                                6. The initial 5-class Accent color scheme does reasonably well.

                                                                                                  5-class accent

                                                                                                7. One of our requirements is to help readers locate their county. To assist with that let's turn on roads and cities.

                                                                                                  Adding context

                                                                                                8. The map is now starting to look a little busy:

                                                                                                  Lots of context

                                                                                                9. Now that we have seen what we are up against, we can try a strategy to help the text and roads stand out while still communicating our vaccination schedule. Change to one of the pastel color schemes.

                                                                                                  Pastel color scheme

                                                                                                10. Change the borders and roads to gray.

                                                                                                  Gray borders and roads

                                                                                                11. The result is fairly clear symbology and provides context.

                                                                                                  Finished with context

                                                                                                12. Using our current \"pastel\" design, set the Number of data classes to 9. At values larger than this, the distinctions between colors becomes so subtle that readers will have trouble clearly distinguishing the content.

                                                                                                13. Make a note of these colors (we will be using them in the exercise on styling next).

                                                                                                  Category Color 1 #fbb4ae 2 #b3cde3 3 #ccebc5 4 #decbe4 5 #fed9a6 6 #ffffcc 7 #e5d8bd 8 #fddaec 9 #f2f2f2

                                                                                                  Color palette

                                                                                                "},{"location":"styling/workshop/design/symbology/#bonus","title":"Bonus","text":"

                                                                                                Finished early? While waiting take a moment to explore this topic in more detail, and if you are feeling creative there is a challenge to try.

                                                                                                Note

                                                                                                In a classroom setting please divide the challenges between teams.

                                                                                                This allows us to work through all the material in the time available.

                                                                                                Explore Device Differences

                                                                                                1. Different output devices provide limitations in the amount of color information they can portray.

                                                                                                2. Explore: How does changing to a printed map affect the number of classes you can communicate using the current \"pastel\" approach?

                                                                                                  Instructor Notes

                                                                                                  The answer is five, but to be really sure four. Read the tool tips to determine fitness for purpose.

                                                                                                Explore Accessibility

                                                                                                1. Communication is a two way street, both in presenting information through design choices, and also perceiving information.

                                                                                                  Disabled readers will have a diminished ability to comprehend maps based on color.

                                                                                                2. Explore: What approach can be used to cater to color-blind map readers?

                                                                                                  Instructor Notes

                                                                                                  Select a color-blind-safe palette, or make use of texture or pattern to communicate attribute changes.

                                                                                                Explore Color Choice

                                                                                                1. The Color Brewer application provides a lot of helpful information using the small \"information\" icons in each section.

                                                                                                  Information icons

                                                                                                2. Explore: Using this information which color scheme would you choose for a digital elevation model?

                                                                                                  Instructor Notes

                                                                                                  Sequential scheme to communicate elevation differences with equal emphasis. If a reader wants to use diverging to emphasis the extremes, that is fine as long as they are doing it on purpose.

                                                                                                Challenge Adjusted Colour Scheme

                                                                                                1. Some datasets included a critical value or threshold that should be communicated clearly.

                                                                                                2. Challenge: How would you adjust a diverging color scheme to be suitable for a digital elevation model that includes bathymetry information (ocean depth)?

                                                                                                  Hint: For a target audience of humans sea-level would be considered a critical value.

                                                                                                  Instructor Notes

                                                                                                  The answer is provided by a Learn more link in the application:

                                                                                                  • http://colorbrewer2.org/js/learnmore/schemes_full.html#diverging

                                                                                                  Remove colors until the critical value is at sea-level.

                                                                                                "},{"location":"styling/workshop/mbstyle/","title":"MBStyle Styling Workbook","text":"

                                                                                                GeoServer styling can be used for a range of creative effects. This section introduces the MBStyle Extension which can be used as alternative to SLD files.

                                                                                                • MBStyle Quickstart
                                                                                                • Lines
                                                                                                • Polygons
                                                                                                • Points
                                                                                                • Rasters
                                                                                                • MBStyle Workbook Conclusion
                                                                                                "},{"location":"styling/workshop/mbstyle/done/","title":"MBStyle Workbook Conclusion","text":"

                                                                                                We hope you have enjoyed this styling workshop.

                                                                                                Additional resources:

                                                                                                • MBStyle Extension
                                                                                                • MBStyle Reference
                                                                                                "},{"location":"styling/workshop/mbstyle/done/#mbstyle-tips-and-tricks","title":"MBStyle Tips and Tricks","text":""},{"location":"styling/workshop/mbstyle/done/#mbstyle-workshop-answer-key","title":"MBStyle Workshop Answer Key","text":"

                                                                                                The following questions were listed throughout the workshop as an opportunity to explore the material in greater depth. Please do your best to consider the questions in detail prior to checking here for the answer. Questions are provided to teach valuable skills, such as a chance to understand how feature type styles are used to control z-order, or where to locate information in the user manual.

                                                                                                Note

                                                                                                Coming Soon

                                                                                                "},{"location":"styling/workshop/mbstyle/done/#mbstyle.line.a1","title":"Classification","text":"

                                                                                                Answer for Challenge Classification <mbstyle.line.q1>:

                                                                                                1. Challenge: Create a new style adjust road appearance based on type.

                                                                                                  Hint: The available values are 'Major Highway','Secondary Highway','Road' and 'Unknown'.

                                                                                                2. Here is an example:

                                                                                                  {\n \"version\": 8,\n \"name\": \"line_example\",\n \"layers\": [\n   {\n     \"id\": \"line_hwy1\",\n     \"source-layer\": \"ne:roads\",\n     \"type\": \"line\",\n     \"filter\": [\"==\", \"type\", \"Major Highway\"],\n     \"paint\": {\n       \"line-color\": \"#000088\",\n       \"line-width\": 1.25,\n       \"line-opacity\": 0.25 \n     }\n   },\n   {\n     \"id\": \"line_hwy2\",\n     \"source-layer\": \"ne:roads\",\n     \"type\": \"line\",\n     \"filter\": [\"==\", \"type\", \"Secondary Highway\"],\n     \"paint\": {\n       \"line-color\": \"#8888AA\",\n       \"line-width\": 0.75,\n       \"line-opacity\": 0.25\n     }\n   },\n   {\n     \"id\": \"line_road\",\n     \"source-layer\": \"ne:roads\",\n     \"type\": \"line\",\n     \"filter\": [\"==\", \"type\", \"Road\"],\n     \"paint\": {\n       \"line-color\": \"#888888\",\n       \"line-width\": 0.75,\n       \"line-opacity\": 0.25\n     }\n   },\n   {\n     \"id\": \"line_unk\",\n     \"source-layer\": \"ne:roads\",\n     \"type\": \"line\",\n     \"filter\": [\"==\", \"type\", \"Unknown\"],\n     \"paint\": {\n       \"line-color\": \"#888888\",\n       \"line-width\": 0.5,\n       \"line-opacity\": 0.25\n     }\n   }\n ]\n}\n
                                                                                                "},{"location":"styling/workshop/mbstyle/done/#mbstyle.line.a2","title":"One Rule Classification","text":"

                                                                                                Answer for Challenge One Rule Classification <mbstyle.line.q2>:

                                                                                                1. Challenge: Create a new style and classify the roads based on their scale rank using expressions in a single rule instead of multiple rules with filters.
                                                                                                2. This exercise requires looking up information in the MBstyle user guide.
                                                                                                  • The Mapbox Style specification functions provides details.
                                                                                                "},{"location":"styling/workshop/mbstyle/done/#mbstyle.line.a3","title":"Label Shields","text":"

                                                                                                Answer for Challenge Label Shields <mbstyle.line.q3>:

                                                                                                1. Challenge: Have a look at the documentation for putting a graphic on a text symbolizer in SLD and reproduce this technique in MBStyle.

                                                                                                2. The use of a label shield is a vendor specific capability of the GeoServer rendering engine. The tricky part of this exercise is finding which symbol layout parameters give the desired behavior, mainly icon-text-fit but also the various placement and overlap parameters to allow the text to be drawn atop the labels ( see symbol layer).

                                                                                                  {\n  \"version\": 8,\n  \"name\": \"line_example\",\n  \"sprite\": \"http://localhost:8080/geoserver/styles/sprites\",\n  \"layers\": [\n    {\n      \"id\": \"line_casing\",\n      \"source-layer\": \"ne:roads\",\n      \"type\": \"line\",\n      \"paint\": {\n        \"line-color\": \"#000000\",\n        \"line-width\": 3,\n      }\n    },\n    {\n      \"id\": \"line_inner\",\n      \"source-layer\": \"ne:roads\",\n      \"type\": \"line\",\n      \"paint\": {\n        \"line-color\": \"#D3D3D3\",\n        \"line-width\": 2,\n      }\n    },\n    {\n      \"id\": \"label\",\n      \"source-layer\": \"ne:roads\",\n      \"type\": \"symbol\",\n      \"layout\": {\n        \"icon-image\": \"white_square16\",\n        \"icon-text-fit\": \"width\",\n        \"icon-text-fit-padding\": [2, 2, 2, 2],\n        \"text-field\": \"{name}\",\n        \"text-font\": [\"Ariel\"],\n        \"text-font-size\": 10,\n        \"text-ignore-placement\": true,\n        \"text-allow-overlap\": true,\n        \"icon-ignore-placement\": true,\n        \"icon-allow-overlap\": true,\n        \"symbol-placement\": \"line\",\n        \"symbol-spacing\": 0\n\n      }\n      \"paint\": {\n        \"text-color\": \"black\"\n      }\n    }\n  ]\n}\n
                                                                                                "},{"location":"styling/workshop/mbstyle/done/#mbstyle.polygon.a2","title":"Interval","text":"

                                                                                                Answer for Explore Interval <mbstyle.polygon.q2>:

                                                                                                1. An exciting use of the GeoServer fill-pattern symbols is theming by changing the pattern used.

                                                                                                2. Explore: Use the interval function to theme by datarank.

                                                                                                  Example:

                                                                                                  {\n \"version\": 8,\n \"name\": \"polygon_example\",\n \"sprite\": \"http://localhost:8080/geoserver/styles/sprites\",\n \"layers\": [\n   {\n     \"id\": \"polygon\",\n     \"source-layer\": \"ne:states_provinces_shp\",\n     \"type\": \"fill\",\n     \"paint\": {\n       \"fill-pattern\": {\n         \"property\": \"datarank\",\n         \"type\": \"interval\",\n         \"stops\": [\n           [4, \"grey_diag8\"],\n           [6, \"grey_diag16\"]\n         ]\n       }\n     }\n   }\n ]\n}\n
                                                                                                "},{"location":"styling/workshop/mbstyle/done/#mbstyle.polygon.a4","title":"Halo","text":"

                                                                                                Answer for Challenge Halo <mbstyle.polygon.q4>:

                                                                                                1. The halo example used the fill color and opacity for a muted halo, while this improved readability it did not bring attention to our labels.

                                                                                                  A common design choice for emphasis is to outline the text in a contrasting color.

                                                                                                2. Challenge: Produce a map that uses a white halo around black text.

                                                                                                  Here is an example:

                                                                                                  {\n  \"version\": 8,\n  \"name\": \"polygon_example\",\n  \"layers\": [\n    {\n      \"id\": \"polygon_fill\",\n      \"source-layer\": \"ne:states_provinces_shp\",\n      \"type\": \"fill\",\n      \"paint\": {\n        \"fill-color\": \"#7EB5D3\",\n        \"fill-outline-color\": \"gray\"\n      }\n    },\n    {\n      \"id\": \"polygon_label\",\n      \"source-layer\": \"ne:states_provinces_shp\",\n      \"type\": \"symbol\",\n      \"layout\": {\n        \"text-field\": \"{name}\",\n        \"text-anchor\": \"center\"\n        \"text-max-width\": 14,\n        \"text-font\": [\"Arial\"]\n      },\n      \"paint\": {\n        \"text-color\": \"white\",\n        \"text-halo-color\": \"black\",\n        \"text-halo-width\": 1\n\n      }\n    }\n  ]\n}\n
                                                                                                "},{"location":"styling/workshop/mbstyle/done/#mbstyle.polygon.a5","title":"Theming using Multiple Attributes","text":"

                                                                                                Answer for Challenge Theming using Multiple Attributes <mbstyle.polygon.q5>:

                                                                                                1. A powerful tool is theming using multiple attributes. This is an important concept allowing map readers to perform \"integration by eyeball\" (detecting correlations between attribute values information).

                                                                                                2. Challenge: Combine the mapcolor9 and datarank examples to reproduce the following map.

                                                                                                  This should be a cut and paste using the categorical example, and interval examples already provided.

                                                                                                  {\n  \"version\": 8,\n  \"name\": \"polygon_example\",\n  \"sprite\": \"http://localhost:8080/geoserver/styles/sprites\",\n  \"layers\": [\n    {\n      \"id\": \"polygon\",\n      \"source-layer\": \"ne:states_provinces_shp\",\n      \"type\": \"fill\",\n      \"paint\": {\n        \"fill-color\": {\n          \"property\": \"mapcolor9\",\n          \"type\": \"categorical\",\n          \"stops\": [\n            [1, \"#8dd3c7\"],\n            [2, \"#ffffb3\"],\n            [3, \"#bebada\"],\n            [4, \"#fb8072\"],\n            [5, \"#80b1d3\"],\n            [6, \"#fdb462\"],\n            [7, \"#b3de69\"],\n            [8, \"#fccde5\"],\n            [9, \"#d9d9d9\"]\n          ]\n        },\n        \"fill-outline-color\": \"gray\"\n      }\n    },\n    {\n      \"id\": \"polygon\",\n      \"source-layer\": \"ne:states_provinces_shp\",\n      \"type\": \"fill\",\n      \"paint\": {\n        \"fill-pattern\": {\n          \"property\": \"datarank\",\n          \"type\": \"interval\",\n          \"stops\": [\n            [4, \"grey_diag8\"],\n            [6, \"grey_diag16\"]\n          ]\n        }\n      }\n    }\n  ]\n}\n
                                                                                                "},{"location":"styling/workshop/mbstyle/done/#mbstyle.polygon.a6","title":"Use of Z-Index","text":"

                                                                                                Answer for Challenge Use of Z-Index <mbstyle.polygon.q6>:

                                                                                                1. Using multiple layers to simulate line string casing. The resulting effect is similar to text halos - providing breathing space around complex line work allowing it to stand out.

                                                                                                2. Challenge: Use what you know of LineString rendering order to reproduce the following map:

                                                                                                  This is much easier when using MBStyle, where z-order is controlled by layer.

                                                                                                  {\n   \"version\": 8,\n   \"name\": \"polygon_example\",\n   \"sprite\": \"http://localhost:8080/geoserver/styles/sprites\",\n   \"layers\": [\n     {\n       \"id\": \"polygon_fill\",\n       \"source-layer\": \"ne:states_provinces_shp\",\n       \"type\": \"fill\",\n       \"paint\": {\n         \"fill-color\": \"lightgrey\",\n       }\n     },\n     {\n       \"id\": \"polygon_pattern\",\n       \"source-layer\": \"ne:states_provinces_shp\",\n       \"type\": \"fill\",\n       \"paint\": {\n         \"fill-pattern\": \"grey_diag16\"\n       }\n     }\n     {\n       \"id\": \"polygon_casing\",\n       \"source-layer\": \"ne:states_provinces_shp\",\n       \"type\": \"line\",\n       \"paint\": {\n         \"line-color\": \"lightgrey\",\n         \"line-width\": 6\n       }\n     },\n     {\n       \"id\": \"polygon_outline\",\n       \"source-layer\": \"ne:states_provinces_shp\",\n       \"type\": \"line\",\n       \"paint\": {\n         \"line-color\": \"black\",\n         \"line-width\": 1.5\n       }\n     }\n   ]\n }\n

                                                                                                  The structure of the legend graphic provides an indication on what is going on.

                                                                                                "},{"location":"styling/workshop/mbstyle/done/#mbstyle.point.a1","title":"Geometry Location","text":"

                                                                                                Answer for Challenge Geometry Location <mbstyle.point.q1>:

                                                                                                1. The symbol layer can be used to render any geometry content.

                                                                                                2. Challenge: Try this yourself by rendering polygon data using a symbol layer.

                                                                                                  This can be done one of two ways:

                                                                                                  • Changing the association of a polygon layer, such as ne:states_provinces_shp to point_example and using the layer preview page.
                                                                                                  • Changing the Layer Preview tab to a polygon layer, such as ne:states_provinces_shp.

                                                                                                  The important thing to notice is that the centroid of each polygon is used as a point location.

                                                                                                "},{"location":"styling/workshop/mbstyle/done/#mbstyle.point.a2","title":"Dynamic Symbolization","text":"

                                                                                                Answer for Explore Dynamic Symbolization <mbstyle.point.q2>:

                                                                                                1. icon-image provides an opportunity for dynamic symbolization.

                                                                                                  This is accomplished by using a function for the value of icon-image:

                                                                                                  {\n  \"version\": 8,\n  \"name\": \"point_example\",\n  \"sprite\": \"http://localhost:8080/geoserver/styles/sprites\",\n  \"layers\": [\n    {\n      \"id\": \"point_capital\",\n      \"type\": \"symbol\",\n      \"source-layer\": \"ne:populated_places\",\n      \"layout\": {\n        \"icon-image\": {\n          \"type\": \"categorical\",\n          \"property\": \"FEATURECLA\",\n          \"default\": \"grey_circle\",\n          \"stops\": [\n            [\"Admin-0 capital\", \"star\"]\n          ]\n        }\n      }\n    }\n  ]\n}\n
                                                                                                2. Challenge: Use this approach to rewrite the Dynamic Styling example.

                                                                                                  Example available here point_example.json :

                                                                                                  {

                                                                                                  \"id\": \"point_example\", \"type\": \"symbol\", \"source-layer\": \"ne:populated_places\", \"layout\": { \"icon-image\": { \"type\": \"categorical\", \"property\": \"FEATURECLA\", \"default\": \"grey_circle\", \"stops\": [ [\"Admin-0 capital\", \"star\"] ] }, \"icon-size\": { \"property\": \"SCALERANK\", \"type\": \"exponential\", \"stops\": [ [0, 2.5], [10, 1] ] }, }

                                                                                                  }

                                                                                                "},{"location":"styling/workshop/mbstyle/done/#mbstyle.raster.a4","title":"Raster Opacity","text":"

                                                                                                Discussion for Challenge Raster Opacity <mbstyle.raster.q4>:

                                                                                                1. There is a quick way to make raster data transparent, raster opacity property works in the same fashion as with vector data. The raster as a whole will be drawn partially transparent allow content from other layers to provide context.

                                                                                                2. Challenge: Can you think of an example where this would be useful?

                                                                                                  This is difficult as raster data is usually provided for use as a basemap, with layers being drawn over top.

                                                                                                  The most obvious example here is the display of weather systems, or model output such as fire danger. By drawing the raster with some transparency, the landmass can be shown for context.

                                                                                                "},{"location":"styling/workshop/mbstyle/linestring/","title":"Lines","text":"

                                                                                                We will start our tour of MBStyle styling by looking at the representation of lines.

                                                                                                LineString Geometry

                                                                                                Review of line symbology:

                                                                                                • Lines can be used to represent either abstract concepts with length but not width such as networks and boundaries, or long thin features with a didth that is too smallt o represent on the map. This means that the visual width of line symbols do not normally change depending on scale.
                                                                                                • Lines are recorded as LineStrings or Curves depending on the geometry model used.
                                                                                                • SLD uses a LineSymbolizer to record how the shape of a line is drawn. The primary characteristic documented is the Stroke used to draw each segment between vertices.
                                                                                                • Labeling of line work is anchored to the midpoint of the line. GeoServer provides a vendor option to allow label rotation aligned with line segments.

                                                                                                For our exercises we are going to be using simple MBStyle documents, often consisting of a single layer, in order to focus on the properties used for line symbology.

                                                                                                Each exercise makes use of the ne:roads layer.

                                                                                                Reference:

                                                                                                • MBStyle Reference
                                                                                                • MapBox Style Spec Line Layer
                                                                                                • LineString (User Manual | SLD Reference )
                                                                                                "},{"location":"styling/workshop/mbstyle/linestring/#line","title":"Line","text":"

                                                                                                A line layer is represented by the line type.

                                                                                                Basic Stroke Properties

                                                                                                1. Navigate to the Styles page.

                                                                                                2. Click Add a new style and choose the following:

                                                                                                    • New style name:
                                                                                                    • line_example
                                                                                                    • Workspace for new layer:
                                                                                                    • Leave blank
                                                                                                    • Format:
                                                                                                    • MBStyle
                                                                                                3. Fill in the style editor

                                                                                                  {\n  \"version\": 8,\n  \"name\": \"line_example\",\n  \"layers\": [\n      {\n          \"id\": \"line_example\",\n          \"source-layer\": \"ne:roads\",\n          \"type\": \"line\",\n      }\n  ]\n}\n
                                                                                                4. Click Apply

                                                                                                5. Click Layer Preview to see your new style applied to a layer.

                                                                                                  You can use this tab to follow along as the style is edited, it will refresh each time Apply is pressed.

                                                                                                6. You can see the equivalent SLD by requesting http://localhost:8080/geoserver/rest/styles/line_example.sld?pretty=true which will currently show the default line symbolizer we created.

                                                                                                  <?xml version=\"1.0\" encoding=\"UTF-8\"?><sld:StyledLayerDescriptor xmlns=\"http://www.opengis.net/sld\" xmlns:sld=\"http://www.opengis.net/sld\" xmlns:gml=\"http://www.opengis.net/gml\" xmlns:ogc=\"http://www.opengis.net/ogc\" version=\"1.0.0\">\n  <sld:NamedLayer>\n    <sld:Name>line_example</sld:Name>\n    <sld:UserStyle>\n      <sld:Name>line_example</sld:Name>\n      <sld:FeatureTypeStyle>\n        <sld:Name>name</sld:Name>\n        <sld:Rule>\n          <sld:LineSymbolizer/>\n        </sld:Rule>\n      </sld:FeatureTypeStyle>\n    </sld:UserStyle>\n  </sld:NamedLayer>\n</sld:StyledLayerDescriptor>\n

                                                                                                We only specified the line layer, so all of the boilerplate around was generated for us.

                                                                                                1. Additional properties cane be used fine-tune appearance. Use line-color to specify the colour and width of the line.

                                                                                                  {\n  \"paint\": {\n    \"line-color\": \"blue\"\n  }\n}\n
                                                                                                2. line-width lets us make the line wider

                                                                                                  {\n  \"paint\": {\n    \"line-color\": \"blue\",\n    \"line-width\": 2\n  }\n}\n
                                                                                                3. line-dasharray applies a dot dash pattern.

                                                                                                  {\n  \"paint\": {\n    \"line-color\": \"blue\",\n    \"line-width\": 2,\n    \"line-dasharray\": [5, 2]\n  }\n}\n
                                                                                                4. Check the Map tab to preview the result.

                                                                                                "},{"location":"styling/workshop/mbstyle/linestring/#multiple-layers","title":"Multiple Layers","text":"

                                                                                                Providing two strokes is often used to provide a contrasting edge (called casing) to thick lines. This can be created using two layers.

                                                                                                1. Start by filling in a bit of boilerplate that we'll be using

                                                                                                  {\n  \"version\": 8,\n  \"name\": \"line_example\",\n  \"layers\": [\n    {\n      \"id\": \"line_example\",\n      \"source-layer\": \"ne:roads\",\n      \"type\": \"line\",\n      \"paint\": {\n        \"line-color\": \"#8080E6\",\n        \"line-width\": 3,\n      }\n    }\n  ]\n}\n
                                                                                                2. Add a second layer to the rule

                                                                                                  {\n  \"version\": 8,\n  \"name\": \"line_example\",\n  \"layers\": [\n    {\n      \"id\": \"line_casing\",\n      \"source-layer\": \"ne:roads\",\n      \"type\": \"line\",\n      \"paint\": {\n        \"line-color\": \"black\",\n        \"line-width\": 5,\n      }\n    },\n    {\n      \"id\": \"line_center\",\n      \"source-layer\": \"ne:roads\",\n      \"type\": \"line\",\n      \"paint\": {\n        \"line-color\": \"#8080E6\",\n        \"line-width\": 3,\n      }\n    }\n  ]\n}\n

                                                                                                  The wider black line is first so it is drawn first, then the thinner blue line drawn second and so over top of the black line. This is called the painter's algorithm.

                                                                                                "},{"location":"styling/workshop/mbstyle/linestring/#label","title":"Label","text":"

                                                                                                Our next example is significant as it introduces how text labels are generated.

                                                                                                Use of Label Property

                                                                                                This is also our first example making use of a dynamic style (where a value comes from an attribute from your data).

                                                                                                1. To enable LineString labeling we add a symbol layer with a text-field.

                                                                                                  Update line_example with the following:

                                                                                                  {\n  \"version\": 8,\n  \"name\": \"line_example\",\n  \"layers\": [\n    {\n      \"id\": \"line\",\n      \"source-layer\": \"ne:roads\",\n      \"type\": \"line\",\n      \"paint\": {\n        \"line-color\": \"blue\",\n        \"line-width\": 1,\n      }\n    },\n    {\n      \"id\": \"label\",\n      \"source-layer\": \"ne:roads\",\n      \"type\": \"symbol\",\n      \"layout\": {\n        \"text-field\": \"{name}\"\n      }\n    }\n  ]\n}\n
                                                                                                2. The SLD standard documents the default label position for each kind of Geometry. For LineStrings the initial label is positioned on the midway point of the line.

                                                                                                3. We have used a feature property calculate a value for the label. The label is generated dynamically from the name attribute. Feature properties are supplied within curly braces, and must match the name of a property of the feature type.

                                                                                                  {\n \"version\": 8,\n \"name\": \"line_example\",\n \"layers\": [\n   {\n     \"id\": \"line\",\n     \"source-layer\": \"ne:roads\",\n     \"type\": \"line\",\n     \"paint\": {\n       \"line-color\": \"blue\",\n       \"line-width\": 1,\n     }\n   },\n   {\n     \"id\": \"label\",\n     \"source-layer\": \"ne:roads\",\n     \"type\": \"symbol\",\n     \"layout\": {\n       \"text-field\": \"{name}\"\n     }\n   }\n ]\n}\n
                                                                                                4. Additional keys can be supplied to fine-tune label presentation:

                                                                                                  {\n  \"version\": 8,\n  \"name\": \"line_example\",\n  \"layers\": [\n    {\n      \"id\": \"line\",\n      \"source-layer\": \"ne:roads\",\n      \"type\": \"line\",\n      \"paint\": {\n        \"line-color\": \"blue\",\n        \"line-width\": 1,\n      }\n    },\n    {\n      \"id\": \"label\",\n      \"source-layer\": \"ne:roads\",\n      \"type\": \"symbol\",\n      \"layout\": {\n        \"text-field\": \"{name}\",\n        \"symbol-placement\": \"line\",\n        \"text-offset\": [0, -8]\n      }\n      \"paint\": {\n        \"text-color\": \"black\"\n      }\n    }\n  ]\n}\n
                                                                                                5. The text-color property is set to black to provide the colour of the text. Notice how this is a paint property, unlike all the others which are layout properties.

                                                                                                  {\n  \"version\": 8,\n  \"name\": \"line_example\",\n  \"layers\": [\n    {\n      \"id\": \"line\",\n      \"source-layer\": \"ne:roads\",\n      \"type\": \"line\",\n      \"paint\": {\n        \"line-color\": \"blue\",\n        \"line-width\": 1,\n      }\n    },\n    {\n      \"id\": \"label\",\n      \"source-layer\": \"ne:roads\",\n      \"type\": \"symbol\",\n      \"layout\": {\n        \"text-field\": \"{name}\",\n        \"symbol-placement\": \"line\",\n        \"text-offset\": [0, -8]\n      }\n      \"paint\": {\n        \"text-color\": \"black\"\n      }\n    }\n  ]\n}\n
                                                                                                6. The symbol-placement property is used to set how the label is placed with respect to the line. By default it is point which causes the label to be placed next to the midpoint as it would be for a point feature. When set to line it is placed along the line instead. text-offset specifies how far from the anchor the label should be placed, in both the x and y directions.

                                                                                                  {\n  \"version\": 8,\n  \"name\": \"line_example\",\n  \"layers\": [\n    {\n      \"id\": \"line\",\n      \"source-layer\": \"ne:roads\",\n      \"type\": \"line\",\n      \"paint\": {\n        \"line-color\": \"blue\",\n        \"line-width\": 1,\n      }\n    },\n    {\n      \"id\": \"label\",\n      \"source-layer\": \"ne:roads\",\n      \"type\": \"symbol\",\n      \"layout\": {\n        \"text-field\": \"{name}\",\n        \"symbol-placement\": \"line\",\n        \"text-offset\": [0, -8]\n      }\n      \"paint\": {\n        \"text-color\": \"black\"\n      }\n    }\n  ]\n}\n

                                                                                                "},{"location":"styling/workshop/mbstyle/linestring/#how-labeling-works","title":"How Labeling Works","text":"

                                                                                                The rendering engine collects all the generated labels during the rendering of each layer. Then, during labeling, the engine sorts through the labels performing collision avoidance (to prevent labels overlapping). Finally the rendering engine draws the labels on top of the map. Even with collision avoidance you can spot areas where labels are so closely spaced that the result is hard to read.

                                                                                                1. The parameter text-padding provides additional space around our label for use in collision avoidance.

                                                                                                  {\n  \"version\": 8,\n  \"name\": \"line_example\",\n  \"layers\": [\n    {\n      \"id\": \"line\",\n      \"source-layer\": \"ne:roads\",\n      \"type\": \"line\",\n      \"paint\": {\n        \"line-color\": \"blue\",\n        \"line-width\": 1,\n      }\n    },\n    {\n      \"id\": \"label\",\n      \"source-layer\": \"ne:roads\",\n      \"type\": \"symbol\",\n      \"layout\": {\n        \"text-field\": \"{name}\",\n        \"symbol-placement\": \"line\",\n        \"text-offset\": [0, -8],\n        \"text-padding\": \"10\"\n      }\n      \"paint\": {\n        \"text-color\": \"black\"\n      }\n    }\n  ]\n}\n
                                                                                                2. Each label is now separated from its neighbor, improving legibility.

                                                                                                "},{"location":"styling/workshop/mbstyle/linestring/#zoom","title":"Zoom","text":"

                                                                                                This section explores the use of rules with filters and zoom restrictions.

                                                                                                1. Replace the line_example MBStyle definition with:

                                                                                                  {\n  \"version\": 8,\n  \"name\": \"line_example\",\n  \"layers\": [\n    {\n      \"id\": \"line_example\",\n      \"source-layer\": \"ne:roads\",\n      \"type\": \"line\",\n      \"filter\": [\"<\", \"scalerank\", 4],\n      \"paint\": {\n        \"line-color\": \"black\",\n        \"line-width\": 1\n      }\n    }\n  ]\n}\n
                                                                                                2. And use the Map tab to preview the result.

                                                                                                3. The scalerank attribute is provided by the Natural Earth dataset to allow control of the level of detail based on scale. Our filter short-listed all content with scalerank 4 or lower, providing a nice quick preview when we are zoomed out.

                                                                                                4. In addition to testing feature attributes, selectors can also be used to check the state of the rendering engine.

                                                                                                  Replace your MBStyle with the following:

                                                                                                  {\n  \"version\": 8,\n  \"name\": \"line_example\",\n  \"layers\": [\n    {\n      \"id\": \"line_black\",\n      \"source-layer\": \"ne:roads\",\n      \"type\": \"line\",\n      \"maxzoom\": 3,\n      \"paint\": {\n        \"line-color\": \"black\",\n        \"line-width\": 1\n      }\n    },\n    {\n      \"id\": \"line_blue\",\n      \"source-layer\": \"ne:roads\",\n      \"type\": \"line\",\n      \"minzoom\": 3,\n      \"paint\": {\n        \"line-color\": \"blue\",\n        \"line-width\": 1\n      }\n    }\n  ]\n}\n
                                                                                                5. As you adjust the scale in the Map preview (using the mouse scroll wheel) the color will change between black and blue. You can read the current scale in the bottom right corner, and the legend will change to reflect the current style.

                                                                                                6. Putting these two ideas together allows control of level detail based on scale:

                                                                                                  {\n  \"version\": 8,\n  \"name\": \"line_example\",\n  \"layers\": [\n    {\n      \"id\": \"line_else\",\n      \"source-layer\": \"ne:roads\",\n      \"type\": \"line\",\n      \"filter\": [\">\", \"scalerank\", 7],\n      \"minzoom\": 7,\n      \"paint\": {\n        \"line-color\": \"#888888\",\n        \"line-width\": 1\n      }\n    },\n    {\n      \"id\": \"line_7\",\n      \"source-layer\": \"ne:roads\",\n      \"type\": \"line\",\n      \"filter\": [\"==\", \"scalerank\", 7],\n      \"minzoom\": 6,\n      \"paint\": {\n        \"line-color\": \"#777777\",\n        \"line-width\": 1\n      }\n    },\n    {\n      \"id\": \"line_6\",\n      \"source-layer\": \"ne:roads\",\n      \"type\": \"line\",\n      \"filter\": [\"==\", \"scalerank\", 6],\n      \"minzoom\": 5,\n      \"paint\": {\n        \"line-color\": \"#444444\",\n        \"line-width\": 1\n      }\n    },\n    {\n      \"id\": \"line_5_1\",\n      \"source-layer\": \"ne:roads\",\n      \"type\": \"line\",\n      \"filter\": [\"==\", \"scalerank\", 5],\n      \"minzoom\": 4,\n      \"maxzoom\": 7\n      \"paint\": {\n        \"line-color\": \"#000055\",\n        \"line-width\": 1\n      }\n    },\n    {\n      \"id\": \"line_5_2\",\n      \"source-layer\": \"ne:roads\",\n      \"type\": \"line\",\n      \"filter\": [\"==\", \"scalerank\", 5],\n      \"minzoom\": 7,\n      \"paint\": {\n        \"line-color\": \"#000055\",\n        \"line-width\": 2\n      }\n    },\n    {\n      \"id\": \"line_5_1\",\n      \"source-layer\": \"ne:roads\",\n      \"type\": \"line\",\n      \"filter\": [\"<=\", \"scalerank\", 4],\n      \"maxzoom\": 5,\n      \"paint\": {\n        \"line-color\": \"black\",\n        \"line-width\": 1\n      }\n    },\n    {\n      \"id\": \"line_5_2\",\n      \"source-layer\": \"ne:roads\",\n      \"type\": \"line\",\n      \"filter\": [\"<=\", \"scalerank\", 4],\n      \"minzoom\": 5,\n      \"maxzoom\": 7\n      \"paint\": {\n        \"line-color\": \"black\",\n        \"line-width\": 2\n      }\n    },\n    {\n      \"id\": \"line_5_4\",\n      \"source-layer\": \"ne:roads\",\n      \"type\": \"line\",\n      \"filter\": [\"<=\", \"scalerank\", 4],\n      \"minzoom\": 7,\n      \"paint\": {\n        \"line-color\": \"black\",\n        \"line-width\": 4\n      }\n    }\n  ]\n}\n
                                                                                                7. When a rule has both a filter and a scale, it will trigger when both are true.

                                                                                                "},{"location":"styling/workshop/mbstyle/linestring/#bonus","title":"Bonus","text":"

                                                                                                Finished early? Here are some opportunities to explore what we have learned, and extra challenges requiring creativity and research.

                                                                                                In a classroom setting please divide the challenges between teams (this allows us to work through all the material in the time available).

                                                                                                Instructor Notes

                                                                                                As usual the Explore section invites readers to reapply the material covered in a slightly different context or dataset.

                                                                                                The use of selectors using the roads type attribute provides this opportunity.

                                                                                                "},{"location":"styling/workshop/mbstyle/linestring/#mbstyle.line.q1","title":"Challenge Classification","text":"
                                                                                                1. The roads type attribute provides classification information.

                                                                                                  You can Layer Preview to inspect features to determine available values for type.

                                                                                                2. Challenge: Create a new style adjust road appearance based on type.

                                                                                                  Note

                                                                                                  The available values are 'Major Highway','Secondary Highway','Road' and 'Unknown'.

                                                                                                  Note

                                                                                                  Answer provided <mbstyle.line.a1> at the end of the workbook.

                                                                                                "},{"location":"styling/workshop/mbstyle/linestring/#mbstyle.line.q2","title":"Challenge One Rule Classification","text":"
                                                                                                1. You can save a lot of typing by doing your classification in an expression using arithmetic or the Recode function

                                                                                                2. Challenge: Create a new style and classify the roads based on their scale rank using expressions in a single rule instead of multiple rules with filters.

                                                                                                  Note

                                                                                                  Answer provided <mbstyle.line.a2> at the end of the workbook.

                                                                                                "},{"location":"styling/workshop/mbstyle/linestring/#mbstyle.line.q3","title":"Challenge Label Shields","text":"
                                                                                                1. The traditional presentation of roads in the US is the use of a shield symbol, with the road number marked on top.

                                                                                                2. Challenge: Have a look at the documentation for putting a graphic on a text symbolizer in SLD and reproduce this technique in MBStyle.

                                                                                                  Note

                                                                                                  Answer provided <mbstyle.line.a3> at the end of the workbook.

                                                                                                "},{"location":"styling/workshop/mbstyle/mbstyle/","title":"MBStyle Quickstart","text":"

                                                                                                In the last section, we saw how the OGC defines style using XML documents (called SLD files).

                                                                                                We will now explore GeoServer styling in greater detail using a tool to generate our SLD files. The MBStyle GeoServer extension is used to generate SLD files using the MabBox Style styling language. Styles written in this language can also be used to style vector tiles in client-side applications.

                                                                                                Using the MBStyle extension to define styles results in shorter examples that are easier to understand. At any point we will be able to review the generated SLD file.

                                                                                                Reference:

                                                                                                • MBStyle Reference
                                                                                                "},{"location":"styling/workshop/mbstyle/mbstyle/#mbstyle-syntax","title":"MBStyle Syntax","text":"

                                                                                                This section provides a quick introduction to MBStyle syntax for mapping professionals who may not be familiar with JSON.

                                                                                                "},{"location":"styling/workshop/mbstyle/mbstyle/#json-syntax","title":"JSON Syntax","text":"

                                                                                                All MBStyles consist of a JSON document. There are three types of structures in a JSON document:

                                                                                                1. Object, a collection of key-value pairs. All JSON documents are JSON objects.
                                                                                                2. Array, a collection of values.
                                                                                                3. Value, the value in a key-value pair, or an entry in an array. Values can be objects, arrays, strings, numbers, true, false, or null.
                                                                                                Object A collection of key-value pairs, enclosed by curly braces and delimited by commas. Keys are surrounded by quotes and seperarted from values by a colon. Array A collection values, enclosed by square brackets and delimited by commas. String Text value. Must be surrounded by quotes. Number Numerical value. Must not be surrounded by quotes. Boolean true or false. Null null. Represents an undefined or unset value."},{"location":"styling/workshop/mbstyle/mbstyle/#mbstyle-specification","title":"MBStyle Specification","text":"

                                                                                                The Mapbox Style specification defines a number of additional rules that MBStyles must follow.

                                                                                                "},{"location":"styling/workshop/mbstyle/mbstyle/#root-level-properties","title":"Root-level Properties","text":"

                                                                                                Root level properties of a Mapbox style specify the map's layers, tile sources and other resources, and default values for the initial camera position when not specified elsewhere.

                                                                                                The following root-level properties are required for all MBStyles. Additional root-level properties which are supported but not required can be found in the spec.

                                                                                                version The version of the Mapbox Style specification to use. Must be set to 8. name The name of the style. sources An object defining the source data. Not used by GeoServer. layers An array of layer style objects

                                                                                                For example: :

                                                                                                {\n    \"version\": 8,\n    \"name\": \"Streets\",\n    \"sources\": {...},\n    \"layers\": [...]\n}\n
                                                                                                "},{"location":"styling/workshop/mbstyle/mbstyle/#sources","title":"Sources","text":"

                                                                                                The sources parameter consists of a collection of named sources which define vector tile data the style is to be applied to. This is only used for MBStyles used in client-side applications, and is ignored by GeoServer. If you are only using MBStyles to style your layers within GeoServer, you don't need a sources parameter. However, if you also want to use your MBStyles for client-side styling, you will need the sources parameter.

                                                                                                A GeoServer vector tile source would be defined like this:

                                                                                                {\n  \"cookbook\": {\n    \"type\": \"vector\",\n    \"tiles\": [\n      \"http://localhost:8080/geoserver/gwc/service/wmts?REQUEST=GetTile&SERVICE=WMTS&VERSION=1.0.0&LAYER=cookbook&STYLE=&TILEMATRIX=EPSG:900913:{z}&TILEMATRIXSET=EPSG:900913&FORMAT=application/vnd.mapbox-vector-tile&TILECOL={x}&TILEROW={y}\"\n    ],\n    \"minZoom\": 0,\n    \"maxZoom\": 14\n  }\n}\n
                                                                                                "},{"location":"styling/workshop/mbstyle/mbstyle/#layers","title":"Layers","text":"

                                                                                                The layers parameter contains the primary layout and styling information in the MBStyle. Each layer in the layers list is a self-contained block of styling information. Layers are applied in order, so the last layer in the layers list will be rendered at the top of the image.

                                                                                                Reference:

                                                                                                • MBStyle Styling (User Guide)
                                                                                                • Mapbox Style specification
                                                                                                "},{"location":"styling/workshop/mbstyle/mbstyle/#compare-mbstyle-to-sld","title":"Compare MBStyle to SLD","text":"

                                                                                                The MBStyle extension is built with the same GeoServer rendering engine in mind, providing access to most of the functionality of SLD. The two approaches use slightly different terminology: SLD uses terms familiar to mapping professionals, while MBStyle uses ideas more familiar to web developers.

                                                                                                "},{"location":"styling/workshop/mbstyle/mbstyle/#sld-style","title":"SLD Style","text":"

                                                                                                Here is an example SLD file for reference:

                                                                                                <?xml version=\"1.0\" encoding=\"ISO-8859-1\"?>\n<StyledLayerDescriptor version=\"1.0.0\"\n xsi:schemaLocation=\"http://www.opengis.net/sld StyledLayerDescriptor.xsd\"\n xmlns=\"http://www.opengis.net/sld\"\n xmlns:ogc=\"http://www.opengis.net/ogc\"\n xmlns:xlink=\"http://www.w3.org/1999/xlink\"\n xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\">\n  <NamedLayer>\n    <Name>airports</Name>\n    <UserStyle>\n      <Title>Airports</Title>\n      <FeatureTypeStyle>\n        <Rule>\n          <Name>airports</Name>\n          <Title>Airports</Title>\n          <PointSymbolizer>\n            <Graphic>\n              <ExternalGraphic>\n                <OnlineResource xlink:type=\"simple\"\n                xlink:href=\"airport.svg\" />\n                <Format>image/svg</Format>\n              </ExternalGraphic>\n              <Size>16</Size>\n            </Graphic>\n          </PointSymbolizer>\n        </Rule>\n      </FeatureTypeStyle>\n    </UserStyle>\n  </NamedLayer>\n</StyledLayerDescriptor>\n
                                                                                                "},{"location":"styling/workshop/mbstyle/mbstyle/#mbstyle-style","title":"MBStyle Style","text":"

                                                                                                Here is the same example as MBStyle:

                                                                                                {\n  \"version\": 8,\n  \"name\": \"airports\",\n  \"sprite\": \"http://localhost:8080/geoserver/styles/sprites\",\n  \"layers\": [\n      {\n          \"id\": \"airports\",\n          \"type\": \"symbol\",\n          \"layout\": {\n              \"icon-image\": \"airport\"\n          }\n      }\n  ]\n}\n

                                                                                                We use a point symbolizer to indicate we want this content drawn as a Point (line 16 in the SLD, line 8 in the MBStyle). The point symbolizer declares an external graphic, which contains the URL airports.svg indicating the image that should be drawn (line 20 in the SLD, line 10 in the MBStyle).

                                                                                                Note

                                                                                                Rather than refer to many diffferent icons separately, MBStyles use a single sprite-sheet containing all the necessary icons for the style. This is defined by the sprite property at the top-level of the style.

                                                                                                "},{"location":"styling/workshop/mbstyle/mbstyle/#tour","title":"Tour","text":"

                                                                                                To confirm everything works, let's reproduce the airports style above.

                                                                                                1. Navigate to the Styles page.

                                                                                                2. Each time we edit a style, the contents of the associated SLD file are replaced. Rather than disrupt any of our existing styles we will create a new style. Click Add a new style and choose the following:

                                                                                                    • Name:
                                                                                                    • airports0
                                                                                                    • Workspace:
                                                                                                    • (leave empty)
                                                                                                    • Format:
                                                                                                    • MBStyle
                                                                                                3. Replace the initial MBStyle definition with our airport MBStyle example and click Apply:

                                                                                                  {% \n  include \"../files/airports0.json\"\n%}\n
                                                                                                4. Click the Layer Preview tab to preview the style. We want to preview on the airports layer, so click the name of the current layer and select ne:airports from the list that appears. You can use the mouse buttons to pan and scroll wheel to change scale.

                                                                                                  Choosing the airports layer

                                                                                                  Layer preview

                                                                                                5. Click Layer Data for a summary of the selected data.

                                                                                                  Layer attributes

                                                                                                "},{"location":"styling/workshop/mbstyle/mbstyle/#bonus","title":"Bonus","text":"

                                                                                                Finished early? For now please help your neighbour so we can proceed with the workshop.

                                                                                                If you are really stuck please consider the following challenge rather than skipping ahead.

                                                                                                "},{"location":"styling/workshop/mbstyle/mbstyle/#explore-data","title":"Explore Data","text":"
                                                                                                1. Return to the Data tab and use the Compute link to determine the minimum and maximum for the scalerank attribute.

                                                                                                  Instructor Notes

                                                                                                  Should be 2 and 9 respectively.

                                                                                                "},{"location":"styling/workshop/mbstyle/mbstyle/#challenge-compare-sld-generation","title":"Challenge Compare SLD Generation","text":"
                                                                                                1. The rest API can be used to review your YAML file directly.

                                                                                                Browser:

                                                                                                • Command line:

                                                                                                  curl -v -u admin:geoserver -XGET http://localhost:8080/geoserver/rest/styles/airports0.json\n
                                                                                                  1. The REST API can also be used generate an SLD file:

                                                                                                    Browser:

                                                                                                    • Command line:

                                                                                                      curl -v -u admin:geoserver -XGET http://localhost:8080/geoserver/rest/styles/airports0.sld?pretty=true\n
                                                                                                      1. Compare the generated SLD differ above with the handwritten SLD file used as an example?

                                                                                                        Challenge: What differences can you spot?

                                                                                                        Instructor Notes

                                                                                                        Generated SLD does not include name or title information; this can of course be added. Please check the MBStyle reference for details.

                                                                                                        The second difference is with the use of a fallback Mark when defining a PointSymbolizer.

                                                                                                      "},{"location":"styling/workshop/mbstyle/point/","title":"Points","text":"

                                                                                                      The next stop of the mbstyle styling tour is the representation of points.

                                                                                                      Review of point symbology:

                                                                                                      • Points are used to represent a location only, and do not form a shape. The visual width of lines do not change depending on scale.
                                                                                                      • SLD uses a PointSymbolizer record how the shape of a line is drawn.
                                                                                                      • Labeling of points is anchored to the point location.

                                                                                                      As points have no inherent shape of their own, emphasis is placed on marking locations with an appropriate symbol.

                                                                                                      Reference:

                                                                                                      • MBStyle Reference
                                                                                                      • MapBox Style Spec Symbol Layer
                                                                                                      • MapBox Style Spec Circle Layer
                                                                                                      • Point (User Manual | SLD Reference )

                                                                                                      This exercise makes use of the ne:populated_places layer.

                                                                                                      1. Navigate to the Styles page.

                                                                                                      2. Click Add a new style and choose the following:

                                                                                                          • Name:
                                                                                                          • point_example
                                                                                                          • Workspace:
                                                                                                          • No workspace
                                                                                                          • Format:
                                                                                                          • MBStyle
                                                                                                      3. Replace the initial MBStyle definition with the following and click apply:

                                                                                                        {\n  \"version\": 8,\n  \"name\": \"point_example\",\n  \"sprite\": \"http://localhost:8080/geoserver/styles/sprites\"\n  \"layers\": [\n    {\n      \"id\": \"point_example\",\n      \"type\": \"symbol\",\n      \"source-layer\": \"ne:populated_places\",\n      \"layout\": {\n        \"icon-image\": \"grey_circle\",\n      }\n    }\n  ]\n}\n
                                                                                                      4. And use the Layer Preview tab to preview the result.

                                                                                                      "},{"location":"styling/workshop/mbstyle/point/#sprite","title":"Sprite","text":"

                                                                                                      The symbol layer controls the display of point data. Points are typically represented with an icon-image.

                                                                                                      MBStyle uses a sprite-sheet defined at the top-level of the style to define a set of icons. You can view the names of all the icons in the sprite-sheet by looking at its json definition, at http://localhost:8080/geoserver/styles/sprites.json.

                                                                                                      1. Change the symbol used by the style to a square:

                                                                                                        {\n  \"version\": 8,\n  \"name\": \"point_example\",\n  \"sprite\": \"http://localhost:8080/geoserver/styles/sprites\"\n  \"layers\": [\n    {\n      \"id\": \"point_example\",\n      \"type\": \"symbol\",\n      \"source-layer\": \"ne:populated_places\",\n      \"layout\": {\n        \"icon-image\": \"grey_square16\",\n      }\n    }\n  ]\n}\n
                                                                                                      2. Map Preview:

                                                                                                      3. Before we continue we will use a selector to cut down the amount of data shown to a reasonable level.

                                                                                                        {\n  \"version\": 8,\n  \"name\": \"point_example\",\n  \"sprite\": \"http://localhost:8080/geoserver/styles/sprites\"\n  \"layers\": [\n    {\n      \"id\": \"point_example\",\n      \"type\": \"symbol\",\n      \"source-layer\": \"ne:populated_places\",\n      \"filter\": [\"<\", \"SCALERANK\", 1],\n      \"layout\": {\n        \"icon-image\": \"grey_square16\",\n      }\n    }\n  ]\n}\n
                                                                                                      4. Resulting in a considerably cleaner image:

                                                                                                      5. Additional properties are available to control an icon's presentation:

                                                                                                        The icon-size property is used to control symbol size.

                                                                                                        The icon-rotate property controls orientation, accepting input in degrees.

                                                                                                        Trying these two settings together:

                                                                                                        {\n  \"version\": 8,\n  \"name\": \"point_example\",\n  \"sprite\": \"http://localhost:8080/geoserver/styles/sprites\"\n  \"layers\": [\n    {\n      \"id\": \"point_example\",\n      \"type\": \"symbol\",\n      \"source-layer\": \"ne:populated_places\",\n      \"filter\": [\"<\", \"SCALERANK\", 1],\n      \"layout\": {\n        \"icon-image\": \"grey_square16\",\n        \"icon-size\": 0.75,\n        \"icon-rotate\": 45\n      }\n    }\n  ]\n}\n
                                                                                                      6. Results in each location being marked with a diamond:

                                                                                                      "},{"location":"styling/workshop/mbstyle/point/#circle","title":"Circle","text":"

                                                                                                      Another way of displaying point data is using the circle layer. Rather than rendering an icon from a preset sprite sheet, the circle layer lets us chose size and color for a simple circle.

                                                                                                      1. Modify the style to render a grey circle using the circle layer:

                                                                                                        {\n  \"version\": 8,\n  \"name\": \"point_example\",\n  \"layers\": [\n    {\n      \"id\": \"point_example\",\n      \"type\": \"circle\",\n      \"source-layer\": \"ne:populated_places\",\n      \"paint\": {\n        \"circle-color\": \"gray\",\n        \"circle-radius\": 8\n        \"circle-stroke-color\": \"black\",\n        \"circle-stroke-width\": 1\n      }\n    }\n  ]\n}\n
                                                                                                      2. And use the Layer Preview tab to preview the result.

                                                                                                      "},{"location":"styling/workshop/mbstyle/point/#label","title":"Label","text":"

                                                                                                      Labeling is now familiar from our experience with LineString and Polygons.

                                                                                                      The symbol layer with the label property are used to label Point Locations.

                                                                                                      1. Replace point_example with the following:

                                                                                                        {\n  \"version\": 8,\n  \"name\": \"point_example\",\n  \"layers\": [\n     {\n      \"id\": \"point_circle\",\n      \"type\": \"circle\",\n      \"source-layer\": \"ne:populated_places\",\n      \"paint\": {\n        \"circle-color\": \"gray\",\n        \"circle-radius\": 8\n        \"circle-stroke-color\": \"black\",\n        \"circle-stroke-width\": 1\n      }\n    },\n    {\n      \"id\": \"point_label\",\n      \"source-layer\": \"ne:populated_places\",\n      \"filter\": [\"<\", \"SCALERANK\", 1],\n      \"type\": \"symbol\",\n      \"layout\": {\n        \"text-field\": \"{NAME}\" \n      },\n      \"paint\": {\n        \"text-color\": \"gray\" \n      }\n    }\n  ]\n}\n
                                                                                                      2. Confirm the result in Map preview.

                                                                                                      3. Each label is drawn starting from the provided point - which is unfortunate as it assures each label will overlap with the symbol used. To fix this limitation we will make use of the MBStyle controls for label placement:

                                                                                                        text-anchor provides a value expressing how a label is aligned with respect to the starting label position.

                                                                                                        text-translate is used to provide an initial displacement using and x and y offset. For points this offset is recommended to adjust the label position away for the area used by the symbol.

                                                                                                        Note

                                                                                                        The property text-anchor defines an anchor position relative to the bounding box formed by the resulting label. This anchor position is snapped to the label position generated by the point location and displacement offset.

                                                                                                      4. Using these two facilities together we can center our labels below the symbol, taking care that the displacement used provides an offset just outside the area required for the symbol size.

                                                                                                        {\n  \"version\": 8,\n  \"name\": \"point_example\",\n  \"layers\": [\n    {\n      \"id\": \"point_circle\",\n      \"type\": \"circle\",\n      \"source-layer\": \"ne:populated_places\",\n      \"paint\": {\n        \"circle-color\": \"gray\",\n        \"circle-radius\": 8\n        \"circle-stroke-color\": \"black\",\n        \"circle-stroke-width\": 1\n      }\n    },\n    {\n      \"id\": \"point_label\",\n      \"source-layer\": \"ne:populated_places\",\n      \"filter\": [\"<\", \"SCALERANK\", 1],\n      \"type\": \"symbol\",\n      \"layout\": {\n        \"text-field\": \"{NAME}\",\n        \"text-anchor\": \"top\"\n      },\n      \"paint\": {\n        \"text-color\": \"black\",\n        \"text-translate\": [0, 12]\n      }\n    }\n  ]\n}\n
                                                                                                      5. Each label is now placed under the mark.

                                                                                                      6. One remaining issue is the overlap between labels and symbols.

                                                                                                        MBStyle provides various parameters to control label rendering and conflict resolution, preventing labels from overlapping any symbols.

                                                                                                        icon-allow-overlap and text-allow-overlap allows the rendering engine to draw the indicated symbol atop previous labels and icons.

                                                                                                        icon-ignore-placement and text-ignore-placement allows the rendering engine to draw labels and icons over top of the indicated symbol.

                                                                                                        icon-padding and text-padding tells the rendering engine to provide a minimum distance between the icons and text on the map, ensuring they do not overlap with other labels or icons.

                                                                                                        The -allow-overlap and -ignore-placement parameters are false by default, which is the behavior we want. Update our example to use text-padding:

                                                                                                        {\n  \"version\": 8,\n  \"name\": \"point_example\",\n  \"layers\": [\n    {\n      \"id\": \"point_circle\",\n      \"type\": \"circle\",\n      \"source-layer\": \"ne:populated_places\",\n      \"paint\": {\n        \"circle-color\": \"gray\",\n        \"circle-radius\": 8\n        \"circle-stroke-color\": \"black\",\n        \"circle-stroke-width\": 1\n      }\n    },\n    {\n      \"id\": \"point_label\",\n      \"source-layer\": \"ne:populated_places\",\n      \"filter\": [\"<\", \"SCALERANK\", 1],\n      \"type\": \"symbol\",\n      \"layout\": {\n        \"text-field\": \"{NAME}\",\n        \"text-anchor\": \"top\",\n        \"text-padding\": 2\n      },\n      \"paint\": {\n        \"text-color\": \"black\",\n        \"text-translate\": [0, 12]\n      }\n    }\n  ]\n}\n
                                                                                                      7. Resulting in a considerably cleaner image:

                                                                                                      "},{"location":"styling/workshop/mbstyle/point/#dynamic-styling","title":"Dynamic Styling","text":"
                                                                                                      1. We will quickly use minzoom and maxzoom to select content based on SCALERANK selectors.

                                                                                                        {\n  \"version\": 8,\n  \"name\": \"point_example\",\n  \"layers\": [\n    {\n      \"id\": \"point_7\",\n      \"type\": \"circle\",\n      \"source-layer\": \"ne:populated_places\",\n      \"filter\": [\"<\", \"SCALERANK\", 7],\n      \"minzoom\": 6,\n      \"maxzoom\": 7,\n      \"paint\": {\n        \"circle-color\": \"gray\",\n        \"circle-radius\": 8\n        \"circle-stroke-color\": \"black\",\n        \"circle-stroke-width\": 1\n      }\n    },\n    {\n      \"id\": \"point_5\",\n      \"type\": \"circle\",\n      \"source-layer\": \"ne:populated_places\",\n      \"filter\": [\"<\", \"SCALERANK\", 5],\n      \"minzoom\": 5,\n      \"maxzoom\": 6,\n      \"paint\": {\n        \"circle-color\": \"gray\",\n        \"circle-radius\": 8\n        \"circle-stroke-color\": \"black\",\n        \"circle-stroke-width\": 1\n      }\n    },\n    {\n      \"id\": \"point_4\",\n      \"type\": \"circle\",\n      \"source-layer\": \"ne:populated_places\",\n      \"filter\": [\"<\", \"SCALERANK\", 4],\n      \"minzoom\": 4,\n      \"maxzoom\": 5,\n      \"paint\": {\n        \"circle-color\": \"gray\",\n        \"circle-radius\": 8\n        \"circle-stroke-color\": \"black\",\n        \"circle-stroke-width\": 1\n      }\n    },\n    {\n      \"id\": \"point_3\",\n      \"type\": \"circle\",\n      \"source-layer\": \"ne:populated_places\",\n      \"filter\": [\"<\", \"SCALERANK\", 3],\n      \"minzoom\": 3,\n      \"maxzoom\": 4,\n      \"paint\": {\n        \"circle-color\": \"gray\",\n        \"circle-radius\": 8\n        \"circle-stroke-color\": \"black\",\n        \"circle-stroke-width\": 1\n      }\n    },\n    {\n      \"id\": \"point_2\",\n      \"type\": \"circle\",\n      \"source-layer\": \"ne:populated_places\",\n      \"filter\": [\"<\", \"SCALERANK\", 2],\n      \"minzoom\": 2,\n      \"maxzoom\": 3,\n      \"paint\": {\n        \"circle-color\": \"gray\",\n        \"circle-radius\": 8\n        \"circle-stroke-color\": \"black\",\n        \"circle-stroke-width\": 1\n      }\n    },\n    {\n      \"id\": \"point_1\",\n      \"type\": \"circle\",\n      \"source-layer\": \"ne:populated_places\",\n      \"filter\": [\"<\", \"SCALERANK\", 1],\n      \"maxzoom\": 2,\n      \"paint\": {\n        \"circle-color\": \"gray\",\n        \"circle-radius\": 8\n        \"circle-stroke-color\": \"black\",\n        \"circle-stroke-width\": 1\n      }\n    },\n    {\n      \"id\": \"point_0\",\n      \"type\": \"circle\",\n      \"source-layer\": \"ne:populated_places\",\n      \"minzoom\": 7,\n      \"paint\": {\n        \"circle-color\": \"gray\",\n        \"circle-radius\": 8\n        \"circle-stroke-color\": \"black\",\n        \"circle-stroke-width\": 1\n      }\n    }\n  ]\n}\n
                                                                                                      2. Click Submit to update the Map after each step.

                                                                                                      3. To add labeling we can add a symbol layer for each of the existing circle layers.

                                                                                                        {\n   \"version\": 8,\n   \"name\": \"point_example\",\n   \"layers\": [\n     {\n       \"id\": \"point_7\",\n       \"type\": \"circle\",\n       \"source-layer\": \"ne:populated_places\",\n       \"filter\": [\"<\", \"SCALERANK\", 7],\n       \"minzoom\": 6,\n       \"maxzoom\": 7,\n       \"paint\": {\n         \"circle-color\": \"gray\",\n         \"circle-radius\": 8\n         \"circle-stroke-color\": \"black\",\n         \"circle-stroke-width\": 1\n       }\n     },\n     {\n       \"id\": \"point_7_text\",\n       \"type\": \"symbol\",\n       \"source-layer\": \"ne:populated_places\",\n       \"filter\": [\"<\", \"SCALERANK\", 7],\n       \"minzoom\": 6,\n       \"maxzoom\": 7,\n       \"layout\": {\n         \"text-field\": \"{NAME}\",\n         \"text-font\": [\"Arial\"],\n         \"text-size\": 10\n       },\n       \"paint\": {\n         \"text-color\": \"black\"\n       }\n     },\n     {\n       \"id\": \"point_5\",\n       \"type\": \"circle\",\n       \"source-layer\": \"ne:populated_places\",\n       \"filter\": [\"<\", \"SCALERANK\", 5],\n       \"minzoom\": 5,\n       \"maxzoom\": 6,\n       \"paint\": {\n         \"circle-color\": \"gray\",\n         \"circle-radius\": 8\n         \"circle-stroke-color\": \"black\",\n         \"circle-stroke-width\": 1\n       }\n     },\n     {\n       \"id\": \"point_5_text\",\n       \"type\": \"symbol\",\n       \"source-layer\": \"ne:populated_places\",\n       \"filter\": [\"<\", \"SCALERANK\", 5],\n       \"minzoom\": 5,\n       \"maxzoom\": 6,\n       \"layout\": {\n         \"text-field\": \"{NAME}\",\n         \"text-font\": [\"Arial\"],\n         \"text-size\": 10\n       },\n       \"paint\": {\n         \"text-color\": \"black\"\n       }\n     },\n     {\n       \"id\": \"point_4\",\n       \"type\": \"circle\",\n       \"source-layer\": \"ne:populated_places\",\n       \"filter\": [\"<\", \"SCALERANK\", 4],\n       \"minzoom\": 4,\n       \"maxzoom\": 5,\n       \"paint\": {\n         \"circle-color\": \"gray\",\n         \"circle-radius\": 8\n         \"circle-stroke-color\": \"black\",\n         \"circle-stroke-width\": 1\n       }\n     },\n     {\n       \"id\": \"point_4_text\",\n       \"type\": \"symbol\",\n       \"source-layer\": \"ne:populated_places\",\n       \"filter\": [\"<\", \"SCALERANK\", 4],\n       \"minzoom\": 4,\n       \"maxzoom\": 5,\n       \"layout\": {\n         \"text-field\": \"{NAME}\",\n         \"text-font\": [\"Arial\"],\n         \"text-size\": 10\n       },\n       \"paint\": {\n         \"text-color\": \"black\"\n       }\n     },\n     {\n       \"id\": \"point_3\",\n       \"type\": \"circle\",\n       \"source-layer\": \"ne:populated_places\",\n       \"filter\": [\"<\", \"SCALERANK\", 3],\n       \"minzoom\": 3,\n       \"maxzoom\": 4,\n       \"paint\": {\n         \"circle-color\": \"gray\",\n         \"circle-radius\": 8\n         \"circle-stroke-color\": \"black\",\n         \"circle-stroke-width\": 1\n       }\n     },\n     {\n       \"id\": \"point_3_text\",\n       \"type\": \"symbol\",\n       \"source-layer\": \"ne:populated_places\",\n       \"filter\": [\"<\", \"SCALERANK\", 3],\n       \"minzoom\": 3,\n       \"maxzoom\": 4,\n       \"layout\": {\n         \"text-field\": \"{NAME}\",\n         \"text-font\": [\"Arial\"],\n         \"text-size\": 10\n       },\n       \"paint\": {\n         \"text-color\": \"black\"\n       }\n     },\n     {\n       \"id\": \"point_2\",\n       \"type\": \"circle\",\n       \"source-layer\": \"ne:populated_places\",\n       \"filter\": [\"<\", \"SCALERANK\", 2],\n       \"minzoom\": 2,\n       \"maxzoom\": 3,\n       \"paint\": {\n         \"circle-color\": \"gray\",\n         \"circle-radius\": 8\n         \"circle-stroke-color\": \"black\",\n         \"circle-stroke-width\": 1\n       }\n     },\n     {\n       \"id\": \"point_2_text\",\n       \"type\": \"symbol\",\n       \"source-layer\": \"ne:populated_places\",\n       \"filter\": [\"<\", \"SCALERANK\", 2],\n       \"minzoom\": 2,\n       \"maxzoom\": 3,\n       \"layout\": {\n         \"text-field\": \"{NAME}\",\n         \"text-font\": [\"Arial\"],\n         \"text-size\": 10\n       },\n       \"paint\": {\n         \"text-color\": \"black\"\n       }\n     },\n     {\n       \"id\": \"point_1\",\n       \"type\": \"circle\",\n       \"source-layer\": \"ne:populated_places\",\n       \"filter\": [\"<\", \"SCALERANK\", 1],\n       \"maxzoom\": 2,\n       \"paint\": {\n         \"circle-color\": \"gray\",\n         \"circle-radius\": 8\n         \"circle-stroke-color\": \"black\",\n         \"circle-stroke-width\": 1\n       }\n     },\n     {\n       \"id\": \"point_1_text\",\n       \"type\": \"symbol\",\n       \"source-layer\": \"ne:populated_places\",\n       \"filter\": [\"<\", \"SCALERANK\", 1],\n       \"maxzoom\": 2,\n       \"layout\": {\n         \"text-field\": \"{NAME}\",\n         \"text-font\": [\"Arial\"],\n         \"text-size\": 10\n       },\n       \"paint\": {\n         \"text-color\": \"black\"\n       }\n     },\n     {\n       \"id\": \"point_0\",\n       \"type\": \"circle\",\n       \"source-layer\": \"ne:populated_places\",\n       \"minzoom\": 7,\n       \"paint\": {\n         \"circle-color\": \"gray\",\n         \"circle-radius\": 8\n         \"circle-stroke-color\": \"black\",\n         \"circle-stroke-width\": 1\n       }\n     },\n     {\n       \"id\": \"point_0_text\",\n       \"type\": \"symbol\",\n       \"source-layer\": \"ne:populated_places\",\n       \"minzoom\": 7,\n       \"layout\": {\n         \"text-field\": \"{NAME}\",\n         \"text-font\": [\"Arial\"],\n         \"text-size\": 10\n       },\n       \"paint\": {\n         \"text-color\": \"black\"\n       }\n     }\n   ]\n }\n

                                                                                                      4. We will use text-offset to position the label above each symbol, and text-padding to give some extra space around our labels.

                                                                                                        Add the following line to each layer:

                                                                                                        {\n  \"id\": \"point_example\",\n  \"type\": \"symbol\",\n  \"source-layer\": \"ne:populated_places\",\n  \"minzoom\": 7,\n  \"layout\": {\n    \"text-field\": \"{NAME}\",\n    \"text-font\": [\"Arial\"],\n    \"text-size\": 10,\n    \"text-padding\": 2\n  },\n  \"paint\": {\n    \"text-color\": \"black\",\n    \"text-translate\": [0, -12]\n  }\n}\n

                                                                                                      5. Now that we have clearly labeled our cities, zoom into an area you are familiar with and we can look at changing symbology on a case-by-case basis.

                                                                                                        We have used expressions previous to generate an appropriate label. Expressions can also be used for many other property settings.

                                                                                                        The ne:populated_places layer provides several attributes specifically to make styling easier:

                                                                                                        • SCALERANK: we have already used this attribute to control the level of detail displayed
                                                                                                        • FEATURECLA: used to indicate different types of cities. We will check for Admin-0 capital cities.

                                                                                                        The first thing we will do is calculate the point size using a quick expression:

                                                                                                        {\n  \"property\": \"SCALERANK\",\n  \"type\": \"exponential\",\n  \"stops\": [\n    [0, 4.5],\n    [10, 2.5]\n  ]\n},\n

                                                                                                        This expression should result in sizes between 5 and 9 and will need to be applied to both point size and label displacement.

                                                                                                        {\n  \"id\": \"point_0\",\n  \"type\": \"circle\",\n  \"source-layer\": \"ne:populated_places\",\n  \"minzoom\": 7,\n  \"paint\": {\n    \"circle-color\": \"gray\",\n    \"circle-radius\": {\n      \"property\": \"SCALERANK\",\n      \"type\": \"exponential\",\n      \"stops\": [\n        [0, 4.5],\n        [10, 2.5]\n      ]\n    },\n    \"circle-stroke-color\": \"black\",\n    \"circle-stroke-width\": 1\n  }\n}\n
                                                                                                        {\n  \"id\": \"point_0_text\",\n  \"type\": \"symbol\",\n  \"source-layer\": \"ne:populated_places\",\n  \"minzoom\": 7,\n  \"layout\": {\n    \"text-field\": \"{NAME}\",\n    \"text-font\": [\"Arial\"],\n    \"text-size\": 10,\n    \"text-padding\": 2\n  },\n  \"paint\": {\n    \"text-color\": \"black\",\n    \"text-translate\": {\n      \"property\": \"SCALERANK\",\n      \"type\": \"exponential\",\n      \"stops\": [\n        [0, [0, -8]],\n        [10, [0, -6]]\n      ]\n    },\n  }\n}\n

                                                                                                      6. Next we can use FEATURECLA to check for capital cities.

                                                                                                        Adding a selector for capital cities at the top of the rules list:

                                                                                                        {\n  \"id\": \"point_capital\",\n  \"type\": \"symbol\",\n  \"source-layer\": \"ne:populated_places\",\n  \"filter\": [\"all\",[\"<\", \"SCALERANK\", 2], [\"==\", \"FEATURECLA\", \"Admin-0 capital\"]]\n  \"minzoom\": 2,\n  \"layout\": {\n    \"icon-image\": \"star\",\n    \"text-field\": \"{NAME}\",\n    \"text-font\": [\"Arial\"],\n    \"text-size\": 10,\n    \"text-padding\": 2\n  },\n  \"paint\": {\n    \"text-color\": \"black\",\n    \"text-translate\": [0, -12]\n  }\n}\n

                                                                                                        Also add the sprite-sheet url to the top of the style if it is not present:

                                                                                                        {\n  \"version\": 8,\n  \"name\": \"point_example\",\n  \"sprite\": \"http://localhost:8080/geoserver/styles/sprites\",\n}\n

                                                                                                        And updating the populated places selectors to ignore capital cities:

                                                                                                        {\n  \"id\": \"point_7\",\n  \"type\": \"circle\",\n  \"source-layer\": \"ne:populated_places\",\n  \"filter\": [\"all\", [\"<\", \"SCALERANK\", 7], [\"!=\", \"FEATURECLA\", \"Admin-0 capital\"]],\n  \"minzoom\": 6,\n  \"maxzoom\": 7,\n  \"paint\": {\n    \"circle-color\": \"gray\",\n    \"circle-radius\": {\n      \"property\": \"SCALERANK\",\n      \"type\": \"exponential\",\n      \"stops\": [\n        [0, 4.5],\n        [10, 2.5]\n      ]\n    },\n    \"circle-stroke-color\": \"black\",\n    \"circle-stroke-width\": 1\n  }\n}\n
                                                                                                        {\n  \"id\": \"point_7_text\",\n  \"type\": \"symbol\",\n  \"source-layer\": \"ne:populated_places\",\n  \"filter\": [\"all\", [\"<\", \"SCALERANK\", 7], [\"!=\", \"FEATURECLA\", \"Admin-0 capital\"]],\n  \"minzoom\": 6,\n  \"maxzoom\": 7,\n  \"layout\": {\n    \"text-field\": \"{NAME}\",\n    \"text-font\": [\"Arial\"],\n    \"text-size\": 10,\n    \"text-padding\": 2\n  },\n  \"paint\": {\n    \"text-color\": \"black\",\n    \"text-translate\": {\n      \"property\": \"SCALERANK\",\n      \"type\": \"exponential\",\n      \"stops\": [\n        [0, [0, -8]],\n        [10, [0, -6]]\n      ]\n    }\n  }\n}\n
                                                                                                        {\n  \"id\": \"point_5\",\n  \"type\": \"circle\",\n  \"source-layer\": \"ne:populated_places\",\n  \"filter\": [\"all\", [\"<\", \"SCALERANK\", 5], [\"!=\", \"FEATURECLA\", \"Admin-0 capital\"]],\n  \"minzoom\": 5,\n  \"maxzoom\": 6,\n  \"paint\": {\n    \"circle-color\": \"gray\",\n    \"circle-radius\": {\n      \"property\": \"SCALERANK\",\n      \"type\": \"exponential\",\n      \"stops\": [\n        [0, 4.5],\n        [10, 2.5]\n      ]\n    },\n    \"circle-stroke-color\": \"black\",\n    \"circle-stroke-width\": 1\n  }\n}\n
                                                                                                        {\n  \"id\": \"point_5_text\",\n  \"type\": \"symbol\",\n  \"source-layer\": \"ne:populated_places\",\n  \"filter\": [\"all\", [\"<\", \"SCALERANK\", 5], [\"!=\", \"FEATURECLA\", \"Admin-0 capital\"]],\n  \"minzoom\": 5,\n  \"maxzoom\": 6,\n  \"layout\": {\n    \"text-field\": \"{NAME}\",\n    \"text-font\": [\"Arial\"],\n    \"text-size\": 10,\n    \"text-padding\": 2\n  },\n  \"paint\": {\n    \"text-color\": \"black\",\n    \"text-translate\": {\n      \"property\": \"SCALERANK\",\n      \"type\": \"exponential\",\n      \"stops\": [\n        [0, [0, -8]],\n        [10, [0, -6]]\n      ]\n    }\n  }\n}\n
                                                                                                        {\n  \"id\": \"point_4\",\n  \"type\": \"circle\",\n  \"source-layer\": \"ne:populated_places\",\n  \"filter\": [\"all\", [\"<\", \"SCALERANK\", 4], [\"!=\", \"FEATURECLA\", \"Admin-0 capital\"]],\n  \"minzoom\": 4,\n  \"maxzoom\": 5,\n  \"paint\": {\n    \"circle-color\": \"gray\",\n    \"circle-radius\": {\n      \"property\": \"SCALERANK\",\n      \"type\": \"exponential\",\n      \"stops\": [\n        [0, 4.5],\n        [10, 2.5]\n      ]\n    },\n    \"circle-stroke-color\": \"black\",\n    \"circle-stroke-width\": 1\n  }\n}\n
                                                                                                        {\n  \"id\": \"point_4_text\",\n  \"type\": \"symbol\",\n  \"source-layer\": \"ne:populated_places\",\n  \"filter\": [\"all\", [\"<\", \"SCALERANK\", 4], [\"!=\", \"FEATURECLA\", \"Admin-0 capital\"]],\n  \"minzoom\": 4,\n  \"maxzoom\": 5,\n  \"layout\": {\n    \"text-field\": \"{NAME}\",\n    \"text-font\": [\"Arial\"],\n    \"text-size\": 10,\n    \"text-padding\": 2\n  },\n  \"paint\": {\n    \"text-color\": \"black\",\n    \"text-translate\": {\n      \"property\": \"SCALERANK\",\n      \"type\": \"exponential\",\n      \"stops\": [\n        [0, [0, -8]],\n        [10, [0, -6]]\n      ]\n    }\n  }\n}\n
                                                                                                        {\n  \"id\": \"point_3\",\n  \"type\": \"circle\",\n  \"source-layer\": \"ne:populated_places\",\n  \"filter\": [\"all\", [\"<\", \"SCALERANK\", 3], [\"!=\", \"FEATURECLA\", \"Admin-0 capital\"]],\n  \"minzoom\": 3,\n  \"maxzoom\": 4,\n  \"paint\": {\n    \"circle-color\": \"gray\",\n    \"circle-radius\": 8\n    \"circle-stroke-color\": \"black\",\n    \"circle-stroke-width\": 1\n  }\n}\n
                                                                                                        {\n  \"id\": \"point_3_text\",\n  \"type\": \"symbol\",\n  \"source-layer\": \"ne:populated_places\",\n  \"filter\": [\"all\", [\"<\", \"SCALERANK\", 3], [\"!=\", \"FEATURECLA\", \"Admin-0 capital\"]],\n  \"minzoom\": 3,\n  \"maxzoom\": 4,\n  \"layout\": {\n    \"text-field\": \"{NAME}\",\n    \"text-font\": [\"Arial\"],\n    \"text-size\": 10,\n    \"text-padding\": 2\n  },\n  \"paint\": {\n    \"text-color\": \"black\",\n    \"text-translate\": {\n      \"property\": \"SCALERANK\",\n      \"type\": \"exponential\",\n      \"stops\": [\n        [0, [0, -8]],\n        [10, [0, -6]]\n      ]\n    }\n  }\n}\n
                                                                                                        {\n  \"id\": \"point_2\",\n  \"type\": \"circle\",\n  \"source-layer\": \"ne:populated_places\",\n  \"filter\": [\"all\", [\"<\", \"SCALERANK\", 2], [\"!=\", \"FEATURECLA\", \"Admin-0 capital\"]],\n  \"minzoom\": 2,\n  \"maxzoom\": 3,\n  \"paint\": {\n    \"circle-color\": \"gray\",\n    \"circle-radius\": {\n      \"property\": \"SCALERANK\",\n      \"type\": \"exponential\",\n      \"stops\": [\n        [0, 4.5],\n        [10, 2.5]\n      ]\n    },\n    \"circle-stroke-color\": \"black\",\n    \"circle-stroke-width\": 1\n  }\n}\n
                                                                                                        {\n  \"id\": \"point_2_text\",\n  \"type\": \"symbol\",\n  \"source-layer\": \"ne:populated_places\",\n  \"filter\": [\"all\", [\"<\", \"SCALERANK\", 2], [\"!=\", \"FEATURECLA\", \"Admin-0 capital\"]],\n  \"minzoom\": 2,\n  \"maxzoom\": 3,\n  \"layout\": {\n    \"text-field\": \"{NAME}\",\n    \"text-font\": [\"Arial\"],\n    \"text-size\": 10,\n    \"text-padding\": 2\n  },\n  \"paint\": {\n    \"text-color\": \"black\",\n    \"text-translate\": {\n      \"property\": \"SCALERANK\",\n      \"type\": \"exponential\",\n      \"stops\": [\n        [0, [0, -8]],\n        [10, [0, -6]]\n      ]\n    }\n  }\n}\n
                                                                                                        {\n  \"id\": \"point_1\",\n  \"type\": \"circle\",\n  \"source-layer\": \"ne:populated_places\",\n  \"filter\": [\"<\", \"SCALERANK\", 1],\n  \"maxzoom\": 2,\n  \"paint\": {\n    \"circle-color\": \"gray\",\n    \"circle-radius\": {\n      \"property\": \"SCALERANK\",\n      \"type\": \"exponential\",\n      \"stops\": [\n        [0, 4.5],\n        [10, 2.5]\n      ]\n    },\n    \"circle-stroke-color\": \"black\",\n    \"circle-stroke-width\": 1\n  }\n}\n
                                                                                                        {\n  \"id\": \"point_1_text\",\n  \"type\": \"symbol\",\n  \"source-layer\": \"ne:populated_places\",\n  \"filter\": [\"<\", \"SCALERANK\", 1],\n  \"maxzoom\": 2,\n  \"layout\": {\n    \"text-field\": \"{NAME}\",\n    \"text-font\": [\"Arial\"],\n    \"text-size\": 10,\n    \"text-padding\": 2\n  },\n  \"paint\": {\n    \"text-color\": \"black\",\n    \"text-translate\": {\n      \"property\": \"SCALERANK\",\n      \"type\": \"exponential\",\n      \"stops\": [\n        [0, [0, -8]],\n        [10, [0, -6]]\n      ]\n    }\n  }\n}\n
                                                                                                        {\n  \"id\": \"point_0\",\n  \"type\": \"circle\",\n  \"source-layer\": \"ne:populated_places\",\n  \"filter\": [\"!=\", \"FEATURECLA\", \"Admin-0 capital\"],\n  \"minzoom\": 7,\n  \"paint\": {\n    \"circle-color\": \"gray\",\n    \"circle-radius\": {\n      \"property\": \"SCALERANK\",\n      \"type\": \"exponential\",\n      \"stops\": [\n        [0, 4.5],\n        [10, 2.5]\n      ]\n    },\n    \"circle-stroke-color\": \"black\",\n    \"circle-stroke-width\": 1\n  }\n}\n
                                                                                                        {\n  \"id\": \"point_0_text\",\n  \"type\": \"symbol\",\n  \"source-layer\": \"ne:populated_places\",\n  \"filter\": [\"!=\", \"FEATURECLA\", \"Admin-0 capital\"],\n  \"minzoom\": 7,\n  \"layout\": {\n    \"text-field\": \"{NAME}\",\n    \"text-font\": [\"Arial\"],\n    \"text-size\": 10,\n    \"text-padding\": 2\n  },\n  \"paint\": {\n    \"text-color\": \"black\",\n    \"text-translate\": {\n      \"property\": \"SCALERANK\",\n      \"type\": \"exponential\",\n      \"stops\": [\n        [0, [0, -8]],\n        [10, [0, -6]]\n      ]\n    }\n  }\n}\n

                                                                                                      7. If you would like to check your work the final file is here: point_example.mbstyle

                                                                                                      "},{"location":"styling/workshop/mbstyle/point/#bonus","title":"Bonus","text":"

                                                                                                      Instructor Notes

                                                                                                      The exercise section does not review the examples above, instead it explores the use of:

                                                                                                      • rules using min/max scale and rules using attribute filters
                                                                                                      • recode to map from attribute to symbol
                                                                                                      • interpolate to change size by population
                                                                                                      "},{"location":"styling/workshop/mbstyle/point/#mbstyle.point.q1","title":"Challenge Geometry Location","text":"

                                                                                                      Instructor Notes

                                                                                                      As usual Explore invites readers to reapply the material covered in a slightly different context or dataset.

                                                                                                      The use of filters using the roads type attribute provides this opportunity.

                                                                                                      1. The mark property can be used to render any geometry content.

                                                                                                      2. Challenge: Try this yourself by rendering a polygon layer using a mark property.

                                                                                                        Note

                                                                                                        Answer discussed <mbstyle.point.a1> at the end of the workbook.

                                                                                                      "},{"location":"styling/workshop/mbstyle/point/#mbstyle.point.q2","title":"Explore Dynamic Symbolization","text":"
                                                                                                      1. We went to a lot of work to set up selectors to choose between star and circle for capital cities.

                                                                                                        This approach is straightforward when applied in isolation:

                                                                                                        {\n  \"version\": 8,\n  \"name\": \"point_example\",\n  \"sprite\": \"http://localhost:8080/geoserver/styles/sprites\",\n  \"layers\": [\n    {\n      \"id\": \"point_capital\",\n      \"type\": \"symbol\",\n      \"source-layer\": \"ne:populated_places\",\n      \"filter\": [\"==\", \"FEATURECLA\", \"Admin-0 capital\"]\n      \"minzoom\": 2,\n      \"layout\": {\n        \"icon-image\": \"star\",\n      }\n    },\n    {\n      \"id\": \"point_0\",\n      \"type\": \"circle\",\n      \"source-layer\": \"ne:populated_places\",\n      \"filter\": [\"!=\", \"FEATURECLA\", \"Admin-0 capital\"],\n      \"minzoom\": 7,\n      \"paint\": {\n        \"circle-color\": \"gray\",\n        \"circle-radius\": 4,\n        \"circle-stroke-color\": \"black\",\n        \"circle-stroke-width\": 1\n      }\n    }\n  ]\n}\n

                                                                                                        When combined with checking another attribute, or checking @scale as in our example, this approach can quickly lead to many rules which can be difficult to keep straight.

                                                                                                      2. Taking a closer look, icon-image is expressed using a string:

                                                                                                        {\n  \"id\": \"point_capital\",\n  \"type\": \"symbol\",\n  \"source-layer\": \"ne:populated_places\",\n  \"filter\": [\"==\", \"FEATURECLA\", \"Admin-0 capital\"]\n  \"minzoom\": 2,\n  \"layout\": {\n    \"icon-image\": \"star\",\n  }\n}\n

                                                                                                        Which is represented in SLD as:

                                                                                                        <sld:PointSymbolizer uom=\"http://www.opengeospatial.org/se/units/pixel\">\n  <sld:Graphic>\n    <sld:ExternalGraphic>\n      <sld:OnlineResource xmlns:xlink=\"http://www.w3.org/1999/xlink\" xlink:type=\"simple\" xlink:href=\"http://localhost:8080/geoserver/styles/sprites#icon=${strURLEncode('star')}&size=${strURLEncode(1.0)}\"/>\n      <sld:Format>mbsprite</sld:Format>\n    </sld:ExternalGraphic>\n  </sld:Graphic>\n</sld:PointSymbolizer>\n
                                                                                                      3. MBStyle provides an opportunity for dynamic symbolization.

                                                                                                        This is accomplished by using a function for the value of the icon-image:

                                                                                                        {\n  \"version\": 8,\n  \"name\": \"point_example\",\n  \"sprite\": \"http://localhost:8080/geoserver/styles/sprites\",\n  \"layers\": [\n    {\n      \"id\": \"point_capital\",\n      \"type\": \"symbol\",\n      \"source-layer\": \"ne:populated_places\",\n      \"layout\": {\n        \"icon-image\": {\n          \"type\": \"categorical\",\n          \"property\": \"FEATURECLA\",\n          \"default\": \"grey_circle\",\n          \"stops\": [\n            [\"Admin-0 capital\", \"star\"]\n          ]\n        }\n      }\n    }\n  ]\n}\n

                                                                                                        Which is represented in SLD as:

                                                                                                        <sld:PointSymbolizer uom=\"http://www.opengeospatial.org/se/units/pixel\">\n  <sld:Graphic>\n    <sld:ExternalGraphic>\n      <sld:OnlineResource xmlns:xlink=\"http://www.w3.org/1999/xlink\" xlink:type=\"simple\" xlink:href=\"http://localhost:8080/geoserver/styles/sprites#icon=${strURLEncode(DefaultIfNull(Recode(FEATURECLA,'Admin-0 capital','star'),'grey_circle'))}&size=${strURLEncode(1.0)}\"/>\n      <sld:Format>mbsprite</sld:Format>\n    </sld:ExternalGraphic>\n  </sld:Graphic>\n</sld:PointSymbolizer>\n
                                                                                                      4. Challenge: Use this approach to rewrite the Dynamic Styling example.

                                                                                                        Note

                                                                                                        Answer provided <mbstyle.point.a2> at the end of the workbook.

                                                                                                      1. Challenge: Use the Interpolate function to smoothly change the mark size based on city population.
                                                                                                      "},{"location":"styling/workshop/mbstyle/polygon/","title":"Polygons","text":"

                                                                                                      Next we look at how MBStyle styling can be used to represent polygons.

                                                                                                      Polygon Geometry

                                                                                                      Review of polygon symbology:

                                                                                                      • Polygons offer a direct representation of physical extent or the output of analysis.

                                                                                                      • The visual appearance of polygons reflects the current scale.

                                                                                                      • Polygons are recorded as a LinearRing describing the polygon boundary. Further LinearRings can be used to describe any holes in the polygon if present.

                                                                                                        The Simple Feature for SQL Geometry model (used by GeoJSON) represents these areas as Polygons, the ISO 19107 geometry model (used by GML3) represents these areas as Surfaces.

                                                                                                      • SLD uses a PolygonSymbolizer to describe how the shape of a polygon is drawn. The primary characteristic documented is the Fill used to shade the polygon interior. The use of a Stroke to describe the polygon boundary is optional.

                                                                                                      • Labeling of a polygon is anchored to the centroid of the polygon. GeoServer provides a vendor-option to allow labels to line wrap to remain within the polygon boundaries.

                                                                                                      For our Polygon exercises we will try and limit our MBStyle documents to a single rule, in order to showcase the properties used for rendering.

                                                                                                      Reference:

                                                                                                      • MBStyle Reference
                                                                                                      • MapBox Style Spec Fill Layer
                                                                                                      • Polygons (User Manual | SLD Reference )

                                                                                                      This exercise makes use of the ne:states_provinces_shp layer.

                                                                                                      1. Navigate to Styles.

                                                                                                      2. Create a new style polygon_example.

                                                                                                          • Name:
                                                                                                          • polygon_example
                                                                                                          • Workspace:
                                                                                                          • No workspace
                                                                                                          • Format:
                                                                                                          • MBStyle

                                                                                                      3. Enter the following style and click ****Apply`` to save:

                                                                                                        {\n  \"version\": 8,\n  \"name\": \"polygon_example\",\n  \"layers\": [\n    {\n      \"id\": \"polygon_example\",\n      \"source-layer\": \"ne:states_provinces_shp\",\n      \"type\": \"fill\",\n      \"paint\": {\n        \"fill-color\": \"lightgrey\"\n      }\n    }\n  ]\n}\n
                                                                                                      4. Click on the tab Layer Preview to preview.

                                                                                                      5. Set ne:states_provinces_shp as the preview layer.

                                                                                                      "},{"location":"styling/workshop/mbstyle/polygon/#fill-and-outline","title":"Fill and Outline","text":"

                                                                                                      The fill layer controls the display of polygon data.

                                                                                                      The fill-color property is used to provide the color used to draw the interior of a polygon.

                                                                                                      1. Replace the contents of polygon_example with the following fill example:

                                                                                                        {\n  \"version\": 8,\n  \"name\": \"polygon_example\",\n  \"layers\": [\n    {\n      \"id\": \"polygon_example\",\n      \"source-layer\": \"ne:states_provinces_shp\",\n      \"type\": \"fill\",\n      \"paint\": {\n        \"fill-color\": \"gray\"\n      }\n    }\n  ]\n}\n
                                                                                                      2. The Map tab can be used preview the change:

                                                                                                      3. To draw the boundary of the polygon the fill-outline property is used:

                                                                                                        The fill-outline property is used to provide the color of the polygon boundary. For more advanced boundary styling, use a separate line layer.

                                                                                                        {\n  \"version\": 8,\n  \"name\": \"polygon_example\",\n  \"layers\": [\n    {\n      \"id\": \"polygon_example\",\n      \"source-layer\": \"ne:states_provinces_shp\",\n      \"type\": \"fill\",\n      \"paint\": {\n        \"fill-color\": \"gray\",\n        \"fill-outline-color\": \"black\"\n      }\n    }\n  ]\n}\n

                                                                                                        Note

                                                                                                        Technically the boundary of a polygon is a specific case of a LineString where the first and last vertex are the same, forming a closed LinearRing.

                                                                                                      4. The effect of adding fill-outline is shown in the map preview:

                                                                                                      5. An interesting technique when styling polygons in conjunction with background information is to control the fill opacity.

                                                                                                        The fill-opacity property is used to adjust transparency (provided as range from 0.0 to 1.0). Use of fill-opacity to render polygons works well in conjunction with a raster base map. This approach allows details of the base map to shown through. fill-opacity affects both the fill and the fill outline.

                                                                                                        The stroke-opacity property is used in a similar fashion, as a range from 0.0 to 1.0.

                                                                                                        {\n  \"version\": 8,\n  \"name\": \"polygon_example\",\n  \"layers\": [\n    {\n      \"id\": \"polygon_example\",\n      \"source-layer\": \"ne:states_provinces_shp\",\n      \"type\": \"fill\",\n      \"paint\": {\n        \"fill-opacity\": 0.5,\n        \"fill-color\": \"white\",\n        \"fill-outline-color\": \"lightgrey\"\n      }\n    }\n  ]\n}\n
                                                                                                      6. As shown in the map preview:

                                                                                                      7. This effect can be better appreciated using a layer group.

                                                                                                        Where the transparent polygons is used lighten the landscape provided by the base map.

                                                                                                      Instructor Notes

                                                                                                      In this example we want to ensure readers know the key property for polygon data.

                                                                                                      It is also our first example of using opacity.

                                                                                                      "},{"location":"styling/workshop/mbstyle/polygon/#pattern","title":"Pattern","text":"

                                                                                                      The fill-pattern property can be used to provide a pattern.

                                                                                                      The fill pattern is defined by repeating an image defined in a sprite-sheet.

                                                                                                      1. Update polygon_example with the following sprite as a repeating fill pattern:

                                                                                                        {\n  \"version\": 8,\n  \"name\": \"polygon_example\",\n  \"sprite\": \"http://localhost:8080/geoserver/styles/sprites\"\n  \"layers\": [\n    {\n      \"id\": \"polygon_example\",\n      \"source-layer\": \"ne:states_provinces_shp\",\n      \"type\": \"fill\",\n      \"paint\": {\n        \"fill-pattern\": \"grey_square16\" \n      }\n    }\n  ]\n}\n
                                                                                                      2. The map preview (and legend) will show the result:

                                                                                                      3. You can view the names of all the icons in the sprite-sheet by looking at its json definition, at http://localhost:8080/geoserver/styles/sprites.json.

                                                                                                        {\n    \"white_square16\": {\n        \"height\": 16,\n        \"pixelRatio\": 1,\n        \"width\": 16,\n        \"x\": 1,\n        \"y\": 1\n    },\n    \"grey_square8\": {\n        \"height\": 8,\n        \"pixelRatio\": 1,\n        \"width\": 8,\n        \"x\": 24,\n        \"y\": 18\n    },\n    \"grey_square16\": {\n        \"height\": 16,\n        \"pixelRatio\": 1,\n        \"width\": 16,\n        \"x\": 18,\n        \"y\": 1\n    },\n    \"grey_square22\": {\n        \"height\": 22,\n        \"pixelRatio\": 1,\n        \"width\": 22,\n        \"x\": 1,\n        \"y\": 18\n    },\n    \"green_square16\": {\n        \"height\": 16,\n        \"pixelRatio\": 1,\n        \"width\": 16,\n        \"x\": 35,\n        \"y\": 1\n    },\n    \"grey_x\": {\n        \"height\": 30,\n        \"pixelRatio\": 1,\n        \"width\": 30,\n        \"x\": 1,\n        \"y\": 41\n    },\n    \"grey_diag8\": {\n        \"height\": 8,\n        \"pixelRatio\": 1,\n        \"width\": 8,\n        \"x\": 24,\n        \"y\": 27\n    },\n    \"grey_diag16\": {\n        \"height\": 16,\n        \"pixelRatio\": 1,\n        \"width\": 16,\n        \"x\": 35,\n        \"y\": 18\n    },\n    \"grey_circle\": {\n        \"height\": 17,\n        \"pixelRatio\": 1,\n        \"width\": 17,\n        \"x\": 36,\n        \"y\": 36\n    },\n    \"airport\": {\n        \"height\": 16,\n        \"pixelRatio\": 1,\n        \"width\": 16,\n        \"x\": 52,\n        \"y\": 18\n    },\n    \"port\": {\n        \"height\": 16,\n        \"pixelRatio\": 1,\n        \"width\": 16,\n        \"x\": 52,\n        \"y\": 1\n    },\n    \"star\": {\n        \"height\": 16,\n        \"pixelRatio\": 1,\n        \"width\": 16,\n        \"x\": 69,\n        \"y\": 1\n    }\n}\n

                                                                                                        Update the example to use grey_diag16 for a pattern of left hatching.

                                                                                                        {\n  \"version\": 8,\n  \"name\": \"polygon_example\",\n  \"sprite\": \"http://localhost:8080/geoserver/styles/sprites\"\n  \"layers\": [\n    {\n      \"id\": \"polygon_example\",\n      \"source-layer\": \"ne:states_provinces_shp\",\n      \"type\": \"fill\",\n      \"paint\": {\n        \"fill-pattern\": \"grey_diag16\" \n      }\n    }\n  ]\n}\n
                                                                                                      4. This approach is well suited to printed output or low color devices.

                                                                                                      5. Multiple fills can be applied by using a separate layer for each fill.

                                                                                                        {\n  \"version\": 8,\n  \"name\": \"polygon_example\",\n  \"sprite\": \"http://localhost:8080/geoserver/styles/sprites\"\n  \"layers\": [\n    {\n      \"id\": \"polygon_background\",\n      \"source-layer\": \"ne:states_provinces_shp\",\n      \"type\": \"fill\",\n      \"paint\": {\n        \"fill-color\": \"#DDDDFF\",\n        \"fill-outline-color\": \"black\"\n      }\n    },\n    {\n      \"id\": \"polygon_pattern\",\n      \"source-layer\": \"ne:states_provinces_shp\",\n      \"type\": \"fill\",\n      \"paint\": {\n        \"fill-pattern\": \"grey_diag8\" \n      }\n    }\n  ]\n}\n
                                                                                                      6. The resulting image has a solid fill, with a pattern drawn overtop.

                                                                                                      "},{"location":"styling/workshop/mbstyle/polygon/#label","title":"Label","text":"

                                                                                                      Labeling polygons follows the same approach used for LineStrings.

                                                                                                      1. By default labels are drawn starting at the centroid of each polygon.

                                                                                                      2. Try out text-field and text-color by replacing our polygon_example with the following:

                                                                                                        {\n  \"version\": 8,\n  \"name\": \"polygon_example\",\n  \"layers\": [\n    {\n      \"id\": \"polygon_fill\",\n      \"source-layer\": \"ne:states_provinces_shp\",\n      \"type\": \"fill\",\n      \"paint\": {\n        \"fill-color\": \"#7EB5D3\",\n        \"fill-outline-color\": \"blue\"\n      }\n    },\n    {\n      \"id\": \"polygon_label\",\n      \"source-layer\": \"ne:states_provinces_shp\",\n      \"type\": \"symbol\",\n      \"layout\": {\n        \"text-field\": \"{name}\" \n      },\n      \"paint\": {\n        \"text-color\": \"black\" \n      }\n    }\n  ]\n}\n
                                                                                                      3. Each label is drawn from the lower-left corner as shown in the Map preview.

                                                                                                      4. We can adjust how the label is drawn at the polygon centroid.

                                                                                                        The property text-anchor provides two numbers expressing how a label is aligned with respect to the centroid. Adjusting the text-anchor is the recommended approach to positioning your labels.

                                                                                                      5. Using the text-anchor property we can center our labels with respect to geometry centroid.

                                                                                                        To align the center of our label we select \"center\" below:

                                                                                                        {\n  \"version\": 8,\n  \"name\": \"polygon_example\",\n  \"layers\": [\n    {\n      \"id\": \"polygon_fill\",\n      \"source-layer\": \"ne:states_provinces_shp\",\n      \"type\": \"fill\",\n      \"paint\": {\n        \"fill-color\": \"#7EB5D3\",\n        \"fill-outline-color\": \"blue\"\n      }\n    },\n    {\n      \"id\": \"polygon_label\",\n      \"source-layer\": \"ne:states_provinces_shp\",\n      \"type\": \"symbol\",\n      \"layout\": {\n        \"text-field\": \"{name}\",\n        \"text-anchor\": \"center\"\n      },\n      \"paint\": {\n        \"text-color\": \"black\" \n      }\n    }\n  ]\n}\n
                                                                                                      6. The labeling position remains at the polygon centroid. We adjust alignment by controlling which part of the label we are \"snapping\" into position.

                                                                                                      7. The property text-translate can be used to provide an initial displacement using and x and y offset.

                                                                                                      8. This offset is used to adjust the label position relative to the geometry centroid resulting in the starting label position.

                                                                                                        {\n  \"version\": 8,\n  \"name\": \"polygon_example\",\n  \"layers\": [\n    {\n      \"id\": \"polygon_fill\",\n      \"source-layer\": \"ne:states_provinces_shp\",\n      \"type\": \"fill\",\n      \"paint\": {\n        \"fill-color\": \"#7EB5D3\",\n        \"fill-outline-color\": \"blue\"\n      }\n    },\n    {\n      \"id\": \"polygon_label\",\n      \"source-layer\": \"ne:states_provinces_shp\",\n      \"type\": \"symbol\",\n      \"layout\": {\n        \"text-field\": \"{name}\",\n      },\n      \"paint\": {\n        \"text-color\": \"black\",\n        \"text-translate\": [0, -7]\n      }\n    }\n  ]\n}\n
                                                                                                      9. Confirm this result in the map preview.

                                                                                                      10. These two settings can be used together.

                                                                                                        The rendering engine starts by determining the label position generated from the geometry centroid and the text-translate displacement. The bounding box of the label is used with the text-anchor setting align the label to this location.

                                                                                                        Step 1: starting label position = centroid + displacement

                                                                                                        Step 2: snap the label anchor to the starting label position

                                                                                                      11. To move our labels down (allowing readers to focus on each shape) we can use displacement combined with followed by horizontal alignment.

                                                                                                        {\n  \"version\": 8,\n  \"name\": \"polygon_example\",\n  \"layers\": [\n    {\n      \"id\": \"polygon_fill\",\n      \"source-layer\": \"ne:states_provinces_shp\",\n      \"type\": \"fill\",\n      \"paint\": {\n        \"fill-color\": \"#7EB5D3\",\n        \"fill-outline-color\": \"blue\"\n      }\n    },\n    {\n      \"id\": \"polygon_label\",\n      \"source-layer\": \"ne:states_provinces_shp\",\n      \"type\": \"symbol\",\n      \"layout\": {\n        \"text-field\": \"{name}\",\n        \"text-anchor\": \"left\"\n      },\n      \"paint\": {\n        \"text-color\": \"black\",\n        \"text-translate\": [0, -7]\n      }\n    }\n  ]\n}\n
                                                                                                      12. As shown in the map preview.

                                                                                                      "},{"location":"styling/workshop/mbstyle/polygon/#legibility","title":"Legibility","text":"

                                                                                                      When working with labels a map can become busy very quickly, and difficult to read.

                                                                                                      1. MBStyle extensive properties for controlling the labelling process.

                                                                                                        One common property for controlling labeling is text-max-width, which allows any labels extending past the provided width will be wrapped into multiple lines.

                                                                                                      2. Using this we can make a small improvement in our example:

                                                                                                        {\n  \"version\": 8,\n  \"name\": \"polygon_example\",\n  \"layers\": [\n    {\n      \"id\": \"polygon_fill\",\n      \"source-layer\": \"ne:states_provinces_shp\",\n      \"type\": \"fill\",\n      \"paint\": {\n        \"fill-color\": \"#7EB5D3\",\n        \"fill-outline-color\": \"blue\"\n      }\n    },\n    {\n      \"id\": \"polygon_label\",\n      \"source-layer\": \"ne:states_provinces_shp\",\n      \"type\": \"symbol\",\n      \"layout\": {\n        \"text-field\": \"{name}\",\n        \"text-anchor\": \"center\"\n        \"text-max-width\": 14\n      },\n      \"paint\": {\n        \"text-color\": \"black\",\n      }\n    }\n  ]\n}\n
                                                                                                      3. As shown in the following preview.

                                                                                                      4. Even with this improved spacing between labels, it is difficult to read the result against the complicated line work.

                                                                                                        Use of a halo to outline labels allows the text to stand out from an otherwise busy background. In this case we will make use of the fill color, to provide some space around our labels. We will also change the font to Arial.

                                                                                                        {\n  \"version\": 8,\n  \"name\": \"polygon_example\",\n  \"layers\": [\n    {\n      \"id\": \"polygon_fill\",\n      \"source-layer\": \"ne:states_provinces_shp\",\n      \"type\": \"fill\",\n      \"paint\": {\n        \"fill-color\": \"#7EB5D3\",\n        \"fill-outline-color\": \"blue\"\n      }\n    },\n    {\n      \"id\": \"polygon_label\",\n      \"source-layer\": \"ne:states_provinces_shp\",\n      \"type\": \"symbol\",\n      \"layout\": {\n        \"text-field\": \"{name}\",\n        \"text-anchor\": \"center\"\n        \"text-max-width\": 14,\n        \"text-font\": [\"Arial\"]\n      },\n      \"paint\": {\n        \"text-color\": \"black\",\n        \"text-halo-color\": \"#7EB5D3\",\n        \"text-halo-width\": 2\n\n      }\n    }\n  ]\n}\n

                                                                                                      "},{"location":"styling/workshop/mbstyle/polygon/#theme","title":"Theme","text":"

                                                                                                      A thematic map (rather than focusing on representing the shape of the world) uses elements of style to illustrate differences in the data under study. This section is a little more advanced and we will take the time to look at the generated SLD file.

                                                                                                      Instructor Notes

                                                                                                      This instruction section follows our pattern with LineString. Building on the examples and exploring how selectors can be used.

                                                                                                      • For LineString we explored the use of @scale, in this section we are going to look at theming by attribute.
                                                                                                      • We also unpack how cascading occurs, and what the result looks like in the generated XML.
                                                                                                      • care is being taken to introduce the symbology encoding functions as an option for theming (placing equal importance on their use).

                                                                                                      Checklist:

                                                                                                      • filter vs function for theming
                                                                                                      • Cascading
                                                                                                      1. We can use a site like ColorBrewer to explore the use of color theming for polygon symbology. In this approach the fill color of the polygon is determined by the value of the attribute under study.

                                                                                                        This presentation of a dataset is known as \"theming\" by an attribute.

                                                                                                      2. For our ne:states_provinces_shp dataset, a mapcolor9 attribute has been provided for this purpose. Theming by mapcolor9 results in a map where neighbouring countries are visually distinct.

                                                                                                        +----------------------------+---------+---------+ | > Qualitative 9-class Set3 | | | +----------------------------+---------+---------+ | #8dd3c7 | #fb8072 | #b3de69 | +----------------------------+---------+---------+ | #ffffb3 | #80b1d3 | #fccde5 | +----------------------------+---------+---------+ | #bebada | #fdb462 | #d9d9d9 | +----------------------------+---------+---------+

                                                                                                        If you are unfamiliar with theming you may wish to visit http://colorbrewer2.org to learn more. The i icons provide an adequate background on theming approaches for qualitative, sequential and diverging datasets.

                                                                                                      3. The first approach we will take is to directly select content based on colormap, providing a color based on the 9-class Set3 palette above:

                                                                                                        {\n  \"version\": 8,\n  \"name\": \"polygon_example\",\n  \"layers\": [\n    {\n      \"id\": \"polygon_1\",\n      \"filter\": [\"==\", \"mapcolor9\", 1],\n      \"source-layer\": \"ne:states_provinces_shp\",\n      \"type\": \"fill\",\n      \"paint\": {\n        \"fill-color\": \"#8DD3C7\",\n        \"fill-outline-color\": \"gray\"\n      }\n    },\n    {\n      \"id\": \"polygon_2\",\n      \"filter\": [\"==\", \"mapcolor9\", 2],\n      \"source-layer\": \"ne:states_provinces_shp\",\n      \"type\": \"fill\",\n      \"paint\": {\n        \"fill-color\": \"#FFFFB3\",\n        \"fill-outline-color\": \"gray\"\n      }\n    },\n    {\n      \"id\": \"polygon_3\",\n      \"filter\": [\"==\", \"mapcolor9\", 3],\n      \"source-layer\": \"ne:states_provinces_shp\",\n      \"type\": \"fill\",\n      \"paint\": {\n        \"fill-color\": \"#BEBADA\",\n        \"fill-outline-color\": \"gray\"\n      }\n    },\n    {\n      \"id\": \"polygon_4\",\n      \"filter\": [\"==\", \"mapcolor9\", 4],\n      \"source-layer\": \"ne:states_provinces_shp\",\n      \"type\": \"fill\",\n      \"paint\": {\n        \"fill-color\": \"#FB8072\",\n        \"fill-outline-color\": \"gray\"\n      }\n    },\n    {\n      \"id\": \"polygon_5\",\n      \"filter\": [\"==\", \"mapcolor9\", 5],\n      \"source-layer\": \"ne:states_provinces_shp\",\n      \"type\": \"fill\",\n      \"paint\": {\n        \"fill-color\": \"#80B1D3\",\n        \"fill-outline-color\": \"gray\"\n      }\n    },\n    {\n      \"id\": \"polygon_6\",\n      \"filter\": [\"==\", \"mapcolor9\", 6],\n      \"source-layer\": \"ne:states_provinces_shp\",\n      \"type\": \"fill\",\n      \"paint\": {\n        \"fill-color\": \"#FDB462\",\n        \"fill-outline-color\": \"gray\"\n      }\n    },\n    {\n      \"id\": \"polygon_7\",\n      \"filter\": [\"==\", \"mapcolor9\", 7],\n      \"source-layer\": \"ne:states_provinces_shp\",\n      \"type\": \"fill\",\n      \"paint\": {\n        \"fill-color\": \"#B3DE69\",\n        \"fill-outline-color\": \"gray\"\n      }\n    },\n    {\n      \"id\": \"polygon_8\",\n      \"filter\": [\"==\", \"mapcolor9\", 8],\n      \"source-layer\": \"ne:states_provinces_shp\",\n      \"type\": \"fill\",\n      \"paint\": {\n        \"fill-color\": \"#FCCDE5\",\n        \"fill-outline-color\": \"gray\"\n      }\n    },\n    {\n      \"id\": \"polygon_9\",\n      \"filter\": [\"==\", \"mapcolor9\", 9],\n      \"source-layer\": \"ne:states_provinces_shp\",\n      \"type\": \"fill\",\n      \"paint\": {\n        \"fill-color\": \"#D9D9D9\",\n        \"fill-outline-color\": \"gray\"\n      }\n    }\n  ]\n}\n
                                                                                                      4. The Map tab can be used to preview this result.

                                                                                                      5. Property functions can be used to make theming substantially easier, by directly mapping property values to style values using an array of stops. MBStyle supports three types of function interpolation, which is used to define the behavior between these stops:

                                                                                                        • categorical: Used the theme qualitative data. Attribute values are directly mapped to styling property such as fill or stroke-width. Equivalent to the SLD Recode function.
                                                                                                        • interval: Used the theme quantitative data. Categories are defined using min and max ranges, and values are sorted into the appropriate category. Equivalent to the SLD Categorize function.
                                                                                                        • exponential: Used to smoothly theme quantitative data by calculating a styling property based on an attribute value. Supports a base attribute for controlling the steepness of interpolation. When base is 1, this is equivalent to the SLD Interpolate function.

                                                                                                        Theming is an activity, producing a visual result allow map readers to learn more about how an attribute is distributed spatially. We are free to produce this visual in the most efficient way possible.

                                                                                                      6. Swap out mapcolor9 theme to use the categorical function:

                                                                                                        {\n  \"version\": 8,\n  \"name\": \"polygon_example\",\n  \"layers\": [\n    {\n      \"id\": \"polygon\",\n      \"source-layer\": \"ne:states_provinces_shp\",\n      \"type\": \"fill\",\n      \"paint\": {\n        \"fill-color\": {\n          \"property\": \"mapcolor9\",\n          \"type\": \"categorical\",\n          \"stops\": [\n            [1, \"#8dd3c7\"],\n            [2, \"#ffffb3\"],\n            [3, \"#bebada\"],\n            [4, \"#fb8072\"],\n            [5, \"#80b1d3\"],\n            [6, \"#fdb462\"],\n            [7, \"#b3de69\"],\n            [8, \"#fccde5\"],\n            [9, \"#d9d9d9\"]\n          ]\n        },\n        \"fill-outline-color\": \"gray\"\n      }\n    }\n  ]\n}\n
                                                                                                      7. The Map tab provides the same preview.

                                                                                                      8. The Generated SLD tab shows where things get interesting. Our generated style now consists of a single Rule:

                                                                                                        <sld:Rule>\n   <sld:PolygonSymbolizer>\n      <sld:Fill>\n         <sld:CssParameter name=\"fill\">\n            <ogc:Function name=\"Recode\">\n               <ogc:PropertyName>mapcolor9</ogc:PropertyName>\n               <ogc:Literal>1</ogc:Literal>\n                  <ogc:Literal>#8dd3c7</ogc:Literal>\n               <ogc:Literal>2</ogc:Literal>\n                  <ogc:Literal>#ffffb3</ogc:Literal>\n               <ogc:Literal>3</ogc:Literal>\n                  <ogc:Literal>#bebada</ogc:Literal>\n               <ogc:Literal>4</ogc:Literal>\n                  <ogc:Literal>#fb8072</ogc:Literal>\n               <ogc:Literal>5</ogc:Literal>\n                  <ogc:Literal>#80b1d3</ogc:Literal>\n               <ogc:Literal>6</ogc:Literal>\n                  <ogc:Literal>#fdb462</ogc:Literal>\n               <ogc:Literal>7</ogc:Literal>\n                  <ogc:Literal>#b3de69</ogc:Literal>\n               <ogc:Literal>8</ogc:Literal>\n                  <ogc:Literal>#fccde5</ogc:Literal>\n               <ogc:Literal>9</ogc:Literal>\n                  <ogc:Literal>#d9d9d9</ogc:Literal>\n         </ogc:Function>\n         </sld:CssParameter>\n      </sld:Fill>\n   </sld:PolygonSymbolizer>\n   <sld:LineSymbolizer>\n      <sld:Stroke>\n         <sld:CssParameter name=\"stroke\">#808080</sld:CssParameter>\n         <sld:CssParameter name=\"stroke-width\">0.5</sld:CssParameter>\n      </sld:Stroke>\n   </sld:LineSymbolizer>\n</sld:Rule>\n
                                                                                                      "},{"location":"styling/workshop/mbstyle/polygon/#bonus","title":"Bonus","text":"

                                                                                                      The following optional explore and challenge activities offer a chance to review and apply the ideas introduced here. The challenge activities enquire a bit of creativity and research to complete.

                                                                                                      In a classroom setting you are encouraged to team up into groups, with each group taking on a different challenge.

                                                                                                      "},{"location":"styling/workshop/mbstyle/polygon/#mbstyle.polygon.q2","title":"Explore Interval","text":"

                                                                                                      Instructor Notes

                                                                                                      This section reviews use of the Symbology Encoding Categorize function for something else other than color. Goal is to have readers reach for SE Functions as often as selectors when styling.

                                                                                                      Additional exercise ideas:

                                                                                                      • Control size using Interpolate: While Recode offers an alternative for selectors (matching discrete values) Interpolate brings something new to the table - gradual color (or value) progression. The best of example of this is controlling width using the ne:rivers data layer (which is not yet available).
                                                                                                      1. The interval function can be used to generate property values based on quantitative information. Here is an example using interval to color states according to size.

                                                                                                        {\n \"version\": 8,\n \"name\": \"polygon_example\",\n \"layers\": [\n   {\n     \"id\": \"polygon\",\n     \"source-layer\": \"ne:states_provinces_shp\",\n     \"type\": \"fill\",\n     \"paint\": {\n       \"fill-color\": {\n         \"property\": \"Shape_Area\",\n         \"type\": \"interval\",\n         \"stops\": [\n           [0, \"#08519c\"],\n           [0.5, \"#3182bd\"],\n           [1, \"#6baed6\"],\n           [5, \"#9ecae1\"],\n           [60, \"#c6dbef\"],\n           [80, \"#eff3ff\"]\n         ]\n       }\n     }\n   }\n ]\n}\n

                                                                                                      2. An exciting use of the GeoServer shape symbols is the theming by changing the size used for pattern density.

                                                                                                      3. Explore: Use the interval function to theme by datarank.

                                                                                                        Note

                                                                                                        Answer provided <mbstyle.polygon.a2> at the end of the workbook.

                                                                                                      "},{"location":"styling/workshop/mbstyle/polygon/#mbstyle.polygon.q4","title":"Challenge Halo","text":"
                                                                                                      1. The halo example used the fill color and opacity for a muted halo, while this improved readability it did not bring attention to our labels.

                                                                                                        A common design choice for emphasis is to outline the text in a contrasting color.

                                                                                                      2. Challenge: Produce a map that uses a white halo around black text.

                                                                                                        Note

                                                                                                        Answer provided <mbstyle.polygon.a4> at the end of the workbook.

                                                                                                      "},{"location":"styling/workshop/mbstyle/polygon/#mbstyle.polygon.q5","title":"Challenge Theming using Multiple Attributes","text":"
                                                                                                      1. A powerful tool is theming using multiple attributes. This is an important concept allowing map readers to perform \"integration by eyeball\" (detecting correlations between attribute values information).

                                                                                                      2. Challenge: Combine the mapcolor9 and datarank examples to reproduce the following map.

                                                                                                        Note

                                                                                                        Answer provided <mbstyle.polygon.a5> at the end of the workbook.

                                                                                                      "},{"location":"styling/workshop/mbstyle/polygon/#mbstyle.polygon.q6","title":"Challenge Use of Z-Index","text":"
                                                                                                      1. Earlier we looked at using multiple layers to simulate line string casing. The line work was drawn twice, once with thick line, and then a second time with a thinner line. The resulting effect is similar to text halos - providing breathing space around complex line work allowing it to stand out.

                                                                                                      2. Challenge: Use what you know of rendering order to reproduce the following map:

                                                                                                        Note

                                                                                                        Answer provided <mbstyle.polygon.a6> at the end of the workbook.

                                                                                                      "},{"location":"styling/workshop/mbstyle/raster/","title":"Rasters","text":"

                                                                                                      Finally we will look at using MBStyle styling for the portrayal of raster data.

                                                                                                      Raster Symbology

                                                                                                      Review of raster symbology:

                                                                                                      • Raster data is Grid Coverage where values have been recorded in a regular array. In OGC terms a Coverage can be used to look up a value or measurement for each location.

                                                                                                      • When queried with a \"sample\" location:

                                                                                                        • A grid coverage can determine the appropriate array location and retrieve a value. Different techniques may be used interpolate an appropriate value from several measurements (higher quality) or directly return the \"nearest neighbor\" (faster).
                                                                                                        • A vector coverages would use a point-in-polygon check and return an appropriate attribute value.
                                                                                                        • A scientific model can calculate a value for each sample location
                                                                                                      • Many raster formats organize information into bands of content. Values recorded in these bands and may be mapped into colors for display (a process similar to theming an attribute for vector data).

                                                                                                        For imagery the raster data is already formed into red, green and blue bands for display.

                                                                                                      • As raster data has no inherent shape, the format is responsible for describing the orientation and location of the grid used to record measurements.

                                                                                                      These raster examples use a digital elevation model consisting of a single band of height measurements. The imagery examples use an RGB image that has been hand coloured for use as a base map.

                                                                                                      Since MBStyle is primarily intended for client-side styling, it doesn't have much ability to style raster data when compared with SLD, so this section will be much shorter than the equivalent raster sections for CSS and YSLD.

                                                                                                      Reference:

                                                                                                      • MBStyle Reference
                                                                                                      • MapBox Style Spec Raster Layer
                                                                                                      • Point (User Manual | SLD Reference )

                                                                                                      The exercise makes use of the usgs:dem and ne:ne1 layers.

                                                                                                      "},{"location":"styling/workshop/mbstyle/raster/#image","title":"Image","text":"

                                                                                                      The raster layer controls the display of raster data.

                                                                                                      1. Navigate to the Styles page.

                                                                                                      2. Click Add a new style and choose the following:

                                                                                                          • Name:
                                                                                                          • image_example
                                                                                                          • Workspace:
                                                                                                          • No workspace
                                                                                                          • Format:
                                                                                                          • MBStyle
                                                                                                      3. Replace the initial MBStyle definition with:

                                                                                                        {\n  \"name\": \"image_example\",\n  \"version\": 8,\n  \"layers\": [\n    {\n      \"id\": \"image_example\",\n      \"type\": \"raster\",\n      \"source-layer\": \"ne:ne1\",\n      \"paint\": {\n        \"raster-opacity\": 1\n      }\n    }\n  ]\n}\n
                                                                                                      4. And use the Layer Preview tab to preview the result.

                                                                                                      "},{"location":"styling/workshop/mbstyle/raster/#dem","title":"DEM","text":"

                                                                                                      A digital elevation model is an example of raster data made up of measurements, rather than color information.

                                                                                                      The usgs:dem layer used for this exercise:

                                                                                                      1. Return to the Styles page.

                                                                                                      2. Click Add a new style and choose the following:

                                                                                                          • Name:
                                                                                                          • raster_example
                                                                                                          • Workspace:
                                                                                                          • No workspace
                                                                                                          • Format:
                                                                                                          • MBStyle
                                                                                                      3. The rendering engine will select our single band of raster content, and do its best to map these values into a grayscale image. Replace the content of the style with:

                                                                                                        {\n  \"name\": \"raster_example\",\n  \"version\": 8,\n  \"layers\": [\n    {\n      \"id\": \"raster_example\",\n      \"type\": \"raster\",\n      \"source-layer\": \"usgs:dem\",\n      \"paint\": {\n        \"raster-opacity\": 1\n      }\n    }\n  ]\n}\n
                                                                                                      4. Use the Layer Preview tab to preview the result. The range produced in this case from the highest and lowest values.

                                                                                                      "},{"location":"styling/workshop/mbstyle/raster/#bonus","title":"Bonus","text":""},{"location":"styling/workshop/mbstyle/raster/#mbstyle.raster.q4","title":"Challenge Raster Opacity","text":"
                                                                                                      1. There is a quick way to make raster data transparent, raster opacity property works in the same fashion as with vector data. The raster as a whole will be drawn partially transparent allow content from other layers to provide context.

                                                                                                      2. Challenge: Can you think of an example where this would be useful?

                                                                                                        Note

                                                                                                        Discussion provided <mbstyle.raster.a4> at the end of the workbook.

                                                                                                      "},{"location":"styling/workshop/setup/","title":"Workshop Setup","text":"

                                                                                                      Content:

                                                                                                      • Extension Install
                                                                                                      • Course Data
                                                                                                      "},{"location":"styling/workshop/setup/data/","title":"Course Data","text":""},{"location":"styling/workshop/setup/data/#natural-earth","title":"Natural Earth","text":"

                                                                                                      The Natural Earth dataset is a free collection of vector and raster data published by the North American Cartographic Information Society to encourage mapping.

                                                                                                      For this course we will be using the Natural Earth cultural and physical vector layers backed by a raster shaded relief dataset.

                                                                                                      Natural Earth

                                                                                                      The quickstart Natural Earth styling has been exported from QGIS and cleaned up in uDig for use in GeoServer.

                                                                                                      "},{"location":"styling/workshop/setup/data/#digital-elevation-model","title":"Digital Elevation Model","text":"

                                                                                                      A digital elevation model records height information for visualisation and analysis. We are using a dataset derived from the USGS GTOPO30 dataset.

                                                                                                      Digital Elevation Model

                                                                                                      The GeoServer \"dem\" styling has been used for this dataset.

                                                                                                      "},{"location":"styling/workshop/setup/data/#configuration","title":"Configuration","text":"

                                                                                                      Note

                                                                                                      In a classroom setting GeoServer has been preconfigured with the appropriate data directory.

                                                                                                      To set up GeoServer yourself:

                                                                                                      1. Download and unzip the following into your data directory:

                                                                                                        • styling-workshop-vector.zip
                                                                                                        • styling-workshop-raster.zip

                                                                                                        This will produce a raster and vector folder referenced in the following steps.

                                                                                                        Optional default SLD styles:

                                                                                                        • styling-workshop-sld.zip
                                                                                                      2. Use the Importer to add and publish -

                                                                                                        the following TIF Coverage Stores:

                                                                                                        • dem/W100N40.TIF
                                                                                                        • ne/ne1/NE1_HR_LC_SR.tif

                                                                                                        the following directories of shape files:

                                                                                                        • ne/ne1/physical
                                                                                                        • ne/ne1/cultural

                                                                                                      3. Cleaning up the published vector layers:

                                                                                                        • Layer names have been shortened for publication - the ne_10m_admin_1_states_provinces_lines_ship.shp is published named states_provinces_shp
                                                                                                        • Use EPSG:4326 as the spatial reference system
                                                                                                        • Optional: Appropriate SLD styles have been provided (from the uDig project)

                                                                                                      4. To clean up the published raster layers:

                                                                                                        • The NE1 GeoTiff is styled with the default raster style
                                                                                                        • The usgs:dem GeoTiff is styled with the default DEM style

                                                                                                      5. Optional: create a basemap group layer consisting of:

                                                                                                        This offers a combined layer, forming a cohesive base map.

                                                                                                      "},{"location":"styling/workshop/setup/install/","title":"Extension Install","text":"

                                                                                                      This workshop course requires GeoServer with a few additional extensions.

                                                                                                      • CSS Styling: Quickly and easily generate SLD files
                                                                                                      • YSLD Styling: An alternative styling language to SLD
                                                                                                      • Importer: Wizard for bulk import of data

                                                                                                      On Windows the following is recommended:

                                                                                                      • FireFox
                                                                                                      • Notepad++

                                                                                                      The CSS extension is distributed as a supported GeoServer extension. Extensions are unpacked into the libs folder of the GeoServer application. The YSLD extension is a new addition to geoserver and is distributed as an unsupported GeoServer extension.

                                                                                                      Note

                                                                                                      In a classroom setting these extensions have already been installed.

                                                                                                      "},{"location":"styling/workshop/setup/install/#manual-install","title":"Manual Install","text":"

                                                                                                      To download and install the required extensions by hand:

                                                                                                        • From the download page download:
                                                                                                        • css
                                                                                                        • ysld

                                                                                                        It is important to download the version that matches the GeoServer you are running.

                                                                                                      1. Stop the GeoServer application.

                                                                                                      2. Navigate into the webapps/geoserver/WEB-INF/lib folder.

                                                                                                        These files make up the running GeoServer application.

                                                                                                      3. Unzip the contents of the three zip files into the lib folder.

                                                                                                      4. Restart the Application Server.

                                                                                                      5. Login to the Web Administration application. Select Styles from the naviagion menu. Click Create a new style and ensure both CSS and YSLD are available in the formats dropdown. Click Cancel to return to the Styles page without saving.

                                                                                                      "},{"location":"styling/workshop/ysld/","title":"YSLD Styling Workbook","text":"

                                                                                                      GeoServer styling can be used for a range of creative effects. This section introduces the YSLD Extension which can be used as alternative to SLD files.

                                                                                                      • YSLD Quickstart
                                                                                                      • Lines
                                                                                                      • Polygons
                                                                                                      • Points
                                                                                                      • Rasters
                                                                                                      • YSLD Workbook Conclusion
                                                                                                      "},{"location":"styling/workshop/ysld/done/","title":"YSLD Workbook Conclusion","text":"

                                                                                                      We hope you have enjoyed this styling workshop.

                                                                                                      Additional resources:

                                                                                                      • YSLD Extension
                                                                                                      • YSLD Reference
                                                                                                      "},{"location":"styling/workshop/ysld/done/#ysld-tips-and-tricks","title":"YSLD Tips and Tricks","text":""},{"location":"styling/workshop/ysld/done/#converting-to-ysld","title":"Converting to YSLD","text":"

                                                                                                      The REST API can be used to convert any of your existing CSS or SLD styles to YSLD.

                                                                                                      1. Navigate to the rest api endpoint for styles:

                                                                                                        • Note

                                                                                                          Using view-source: in chrome or firefox allows us to focus on page content.

                                                                                                        • Click on one of the styles (for example states.html)

                                                                                                        • Click on the link to the style contents

                                                                                                          • Change the URL with ?pretty=true for human readable XML.

                                                                                                            • Change the URL with yaml to convert to YSLD.

                                                                                                              • The original SLD file is convert to YSLD:

                                                                                                                name: states\ntitle: Population in the United States\nabstract: |-\n  A sample filter that filters the United States into three\n          categories of population, drawn in different colors\nfeature-styles:\n- name: name\n  rules:\n  - name: Population < 2M\n    title: Population < 2M\n    filter: ${PERSONS < '2000000'}\n    scale: [min, max]\n    symbolizers:\n    - polygon:\n        fill-color: '#A6CEE3'\n        fill-opacity: 0.7\n  - name: Population 2M-4M\n    title: Population 2M-4M\n    filter: ${PERSONS BETWEEN '2000000' AND '4000000'}\n    scale: [min, max]\n    symbolizers:\n    - polygon:\n        fill-color: F78B4\n        fill-opacity: 0.7\n  - name: '> 4M'\n    title: Population > 4M\n    filter: ${PERSONS > '4000000'}\n    scale: [min, max]\n    symbolizers:\n    - polygon:\n        fill-color: '#B2DF8A'\n        fill-opacity: 0.7\n  - name: State Outlines\n    title: State Outlines\n    scale: [min, max]\n    symbolizers:\n    - line:\n        stroke-color: '#8CADBF'\n        stroke-width: 0.1\n  - name: State Abbreviations\n    title: State Abbreviations\n    scale: ['1.75E7', '3.5E7']\n    symbolizers:\n    - text:\n        label: ${STATE_ABBR}\n        font-family: SansSerif\n        font-size: 12\n        font-style: Normal\n        font-weight: normal\n        placement: point\n        anchor: [0.5, 0.5]\n  - name: State Names\n    title: State Names\n    scale: [min, '1.75E7']\n    symbolizers:\n    - text:\n        label: ${STATE_NAME}\n        font-family: SansSerif\n        font-size: 12\n        font-style: Normal\n        font-weight: normal\n        placement: point\n        anchor: [0.5, 0.5]\n        x-maxDisplacement: 100\n        x-goodnessOfFit: 0.9\n
                                                                                                                "},{"location":"styling/workshop/ysld/done/#ysld-workshop-answer-key","title":"YSLD Workshop Answer Key","text":"

                                                                                                                The following questions were listed throughout the workshop as an opportunity to explore the material in greater depth. Please do your best to consider the questions in detail prior to checking here for the answer. Questions are provided to teach valuable skills, such as a chance to understand how feature type styles are used to control z-order, or where to locate information in the user manual.

                                                                                                                "},{"location":"styling/workshop/ysld/done/#ysld.line.a1","title":"Classification","text":"

                                                                                                                Answer for Challenge Classification <ysld.line.q1>:

                                                                                                                1. Challenge: Create a new style adjust road appearance based on type.

                                                                                                                  Hint: The available values are 'Major Highway','Secondary Highway','Road' and 'Unknown'.

                                                                                                                2. Here is an example:

                                                                                                                  define: &common\n  stroke-opacity: 0.25\n\nrules:\n- filter: ${type = 'Major Highway'}\n  symbolizers:\n  - line:\n      stroke-color: '#000088'\n      stroke-width: 1.25\n      <<: *common\n- filter: ${type = 'Secondary Highway'}\n  symbolizers:\n  - line:\n      stroke-color: '#8888AA'\n      stroke-width: 0.75\n      <<: *common\n- filter: ${type = 'Road'}\n  symbolizers:\n  - line:\n      stroke-color: '#888888'\n      stroke-width: 0.75\n      <<: *common\n- filter: ${type = 'Unknown'}\n  symbolizers:\n  - line:\n      stroke-color: '#888888'\n      stroke-width: 0.5\n      <<: *common\n- else: true\n  symbolizers:\n  - line:\n      stroke-color: '#AAAAAA'\n      stroke-width: 0.5\n      <<: *common\n
                                                                                                                "},{"location":"styling/workshop/ysld/done/#ysld.line.a2","title":"One Rule Classification","text":"

                                                                                                                Answer for Challenge One Rule Classification <ysld.line.q2>:

                                                                                                                1. Challenge: Create a new style and classify the roads based on their scale rank using expressions in a single rule instead of multiple rules with filters.
                                                                                                                2. This exercise requires looking up information in the user guide, the search term recode provides several examples.
                                                                                                                  • The YSLD Reference theming functions provides a clear example.
                                                                                                                "},{"location":"styling/workshop/ysld/done/#ysld.line.a3","title":"Label Shields","text":"

                                                                                                                Answer for Challenge Label Shields <ysld.line.q3>:

                                                                                                                1. Challenge: Have a look at the documentation for putting a graphic on a text symbolizer in SLD and reproduce this technique in YSLD.

                                                                                                                2. The use of a label shield is a vendor specific capability of the GeoServer rendering engine. The tricky part of this exercise is finding the documentation online ( i.e. TextSymbolizer - Graphic).

                                                                                                                  symbolizers:\n- line:\n    stroke-color: '#000000'\n    stroke-width: 3\n- line:\n    stroke-color: '#D3D3D3'\n    stroke-width: 2\n- text:\n    label: ${name}\n    fill-color: '#000000'\n    font-family: Ariel\n    font-size: 10\n    font-style: normal\n    font-weight: normal\n    placement: point\n    graphic:\n      size: 18\n      symbols:\n      - mark:\n          shape: square\n          stroke-color: '#000000'\n          stroke-width: 1\n          fill-color: '#FFFFFF'\n
                                                                                                                "},{"location":"styling/workshop/ysld/done/#ysld.polygon.a1","title":"Antialiasing","text":"

                                                                                                                Answer for Explore Antialiasing <ysld.polygon.q1>:

                                                                                                                1. When we rendered our initial preview, without a stroke, thin white gaps (or slivers) are visible between our polygons.

                                                                                                                  This effect is made more pronounced by the rendering engine making use of the Java 2D sub-pixel accuracy. This technique is primarily used to prevent an aliased (stair-stepped) appearance on diagonal lines.

                                                                                                                2. Explore: Experiment with fill and stroke settings to eliminate slivers between polygons.

                                                                                                                  The obvious approach works - setting both values to the same color:

                                                                                                                  symbolizers:\n- polygon:\n    stroke-color: 'lightgrey'\n    stroke-width: 1\n    fill-color: 'lightgrey'\n
                                                                                                                "},{"location":"styling/workshop/ysld/done/#ysld.polygon.a2","title":"Categorize","text":"

                                                                                                                Answer for Explore Categorize <ysld.polygon.q2>:

                                                                                                                1. An exciting use of the GeoServer shape symbols is the theming by changing the size used for pattern density.

                                                                                                                2. Explore: Use the Categorize function to theme by datarank.

                                                                                                                  Example:

                                                                                                                  symbolizers:\n- polygon:\n    stroke-color: 'black'\n    stroke-width: 1\n    fill-color: 'gray'\n    fill-graphic:\n      size: ${Categorize(datarank,'4','4','5','6','8','10','10')}\n      symbols:\n      - mark:\n          shape: shape://slash\n          stroke-color: 'darkgray'\n          stroke-width: 1\n
                                                                                                                "},{"location":"styling/workshop/ysld/done/#ysld.polygon.a4","title":"Halo","text":"

                                                                                                                Answer for Challenge Halo <ysld.polygon.q4>:

                                                                                                                1. The halo example used the fill color and opacity for a muted halo, while this improved readability it did not bring attention to our labels.

                                                                                                                  A common design choice for emphasis is to outline the text in a contrasting color.

                                                                                                                2. Challenge: Produce a map that uses a white halo around black text.

                                                                                                                  Here is an example:

                                                                                                                  symbolizers:\n- polygon:\n    stroke-color: 'gray'\n    stroke-width: 1\n    fill-color: '#7EB5D3'\n- text:\n    label: ${name}\n    fill-color: 'black'\n    halo:\n      fill-color: 'white'\n      radius: 1\n    font-family: Arial\n    font-size: 14\n    font-style: normal\n    font-weight: normal\n    anchor: [0.5, 0.5]\n
                                                                                                                "},{"location":"styling/workshop/ysld/done/#ysld.polygon.a5","title":"Theming using Multiple Attributes","text":"

                                                                                                                Answer for Challenge Theming using Multiple Attributes <ysld.polygon.q5>:

                                                                                                                1. A powerful tool is theming using multiple attributes. This is an important concept allowing map readers to perform \"integration by eyeball\" (detecting correlations between attribute values information).

                                                                                                                2. Challenge: Combine the mapcolor9 and datarank examples to reproduce the following map.

                                                                                                                  This should be a cut and paste using the recode example, and categorize examples already provided.

                                                                                                                  symbolizers:\n- polygon:\n    stroke-color: 'black'\n    stroke-width: 1\n    fill-color: ${Recode(mapcolor9,\n      '1','#8dd3c7',\n      '2','#ffffb3',\n      '3','#bebada',\n      '4','#fb8072',\n      '5','#80b1d3',\n      '6','#fdb462',\n      '7','#b3de69',\n      '8','#fccde5',\n      '9','#d9d9d9')}\n- polygon:\n    stroke-color: 'black'\n    stroke-width: 1\n    fill-color: 'gray'\n    fill-graphic:\n      size: ${Categorize(datarank,'6','4','8','6','10','10','12')}\n      symbols:\n      - mark:\n          shape: shape://slash\n          stroke-color: 'black'\n          stroke-width: 1\n          fill-color: 'gray'\n
                                                                                                                "},{"location":"styling/workshop/ysld/done/#ysld.polygon.a6","title":"Use of Feature styles","text":"

                                                                                                                Answer for Challenge Use of Feature styles <ysld.polygon.q6>:

                                                                                                                1. Using multiple feature-styles to simulate line string casing. The resulting effect is similar to text halos - providing breathing space around complex line work allowing it to stand out.

                                                                                                                2. Challenge: Use what you know of LineString feature-styles to reproduce the following map:

                                                                                                                  This is much easier when using YSLD, where z-order is controlled by feature-style order. In this instance, multiple symbolizers within a feature-style will not work, as the order within a feature-style is only consistent per-feature (not per-layer).

                                                                                                                  feature-styles:\n- rules:\n  - symbolizers:\n    - polygon:\n        stroke-width: 1.0\n        fill-color: 'lightgrey'\n- rules:\n  - symbolizers:\n    - polygon:\n        stroke-width: 1.0\n        fill-color: 'gray'\n        fill-graphic:\n          size: 8\n          symbols:\n          - mark:\n              shape: shape://slash\n              stroke-color: 'black'\n              stroke-width: 0.75\n- rules:\n  - symbolizers:\n    - line:\n        stroke-color: 'lightgrey'\n        stroke-width: 6\n- rules:\n  - symbolizers:\n    - line:\n        stroke-color: 'black'\n        stroke-width: 1.5\n

                                                                                                                  The structure of the legend graphic provides an indication on what is going on.

                                                                                                                "},{"location":"styling/workshop/ysld/done/#ysld.point.a1","title":"Geometry Location","text":"

                                                                                                                Answer for Challenge Geometry Location <ysld.point.q1>:

                                                                                                                1. The mark property can be used to render any geometry content.

                                                                                                                2. Challenge: Try this yourself by rendering a polygon layer using a mark property.

                                                                                                                  This can be done one of two ways:

                                                                                                                  • Changing the association of a polygon layer, such as ne:states_provinces_shp to point_example and using the layer preview page.
                                                                                                                  • Changing the Layer Preview tab to a polygon layer, such as ne:states_provinces_shp.

                                                                                                                  The important thing to notice is that the centroid of each polygon is used as a point location.

                                                                                                                "},{"location":"styling/workshop/ysld/done/#ysld.point.a2","title":"Dynamic Symbolization","text":"

                                                                                                                Answer for Explore Dynamic Symbolization <ysld.point.q2>:

                                                                                                                1. SLD Mark and ExternalGraphic provide an opportunity for dynamic symbolization.

                                                                                                                  This is accomplished by embedding a small CQL expression in the string passed to symbol or url. This sub-expression is isolated with \\${ } as shown:

                                                                                                                  - point:\n    symbols:\n    - mark:\n        shape: ${if_then_else(equalTo(FEATURECLA,'Admin-0 capital'),'star','circle')}\n
                                                                                                                2. Challenge: Use this approach to rewrite the Dynamic Styling example.

                                                                                                                  Example available here point_example.css :

                                                                                                                  define: &point

                                                                                                                  size: \\${10-(SCALERANK/2)} symbols:

                                                                                                                  • mark:
                                                                                                                  shape: \\${if_then_else(equalTo(FEATURECLA,'Admin-0 capital'),'star','circle')} stroke-color: 'black' stroke-width: 1 fill-color: 'gray'

                                                                                                                  x-labelObstacle: true

                                                                                                                "},{"location":"styling/workshop/ysld/done/#ysld.point.a3","title":"Layer Group","text":"

                                                                                                                Answer for Challenge Layer Group <ysld.point.q3>:

                                                                                                                1. Use a Layer Group to explore how symbology works together to form a map.

                                                                                                                  • ne:NE1
                                                                                                                  • ne:states_provincces_shp
                                                                                                                  • ne:populated_places
                                                                                                                2. This background is relatively busy and care must be taken to ensure both symbols and labels are clearly visible.

                                                                                                                3. Challenge: Do your best to style populated_places over this busy background.

                                                                                                                  Here is an example with labels for inspiration:

                                                                                                                  This is opportunity to revisit label halo settings from Polygons: :

                                                                                                                  symbolizers:\n- point:\n    size: ${'5' + '10' - SCALERANK / '3'}\n    symbols:\n    - mark:\n        shape: circle\n        stroke-color: 'white'\n        stroke-width: 1\n        stroke-opacity: 0.75\n        fill-color: 'black'\n        x-labelObstacle: true\n    - text:\n        label: ${name}\n        fill-color: 'black'\n        font-family: Arial\n        font-size: 14\n        anchor: [0.5, 1]\n        offset: [0 ${'-12' + SCALERANK}]\n        halo:\n          fill-color: `lightgray`\n          radius: 2\n          opacity: 0.7\n        priority: ${`0` - LABELRANK}\n        x-maxDisplacement: 90\n

                                                                                                                  Using a lightgray halo, 0.7 opacity and radius 2 fades out the complexity immediately surrounding the label text improving legibility.

                                                                                                                "},{"location":"styling/workshop/ysld/done/#ysld.raster.a1","title":"Contrast Enhancement","text":"

                                                                                                                Discussion for Explore Contrast Enhancement <ysld.raster.q1>:

                                                                                                                1. A special effect that is effective with grayscale information is automatic contrast adjustment.

                                                                                                                2. Make use of a simple contrast enhancement with usgs:dem:

                                                                                                                  symbolizers:\n- raster:\n    opacity: 1.0\n    contrast-enhancement:\n      mode: normalize\n
                                                                                                                3. Can you explain what happens when zoom in to only show a land area (as indicated with the bounding box below)?

                                                                                                                  What happens is insanity, normalize stretches the palette of the output image to use the full dynamic range. As long as we have ocean on the screen (with value 0) the land area was shown with roughly the same presentation.

                                                                                                                  Once we zoom in to show only a land area, the lowest point on the screen (say 100) becomes the new black, radically altering what is displayed on the screen.

                                                                                                                "},{"location":"styling/workshop/ysld/done/#ysld.raster.a2","title":"Intervals","text":"

                                                                                                                Answer for Challenge Intervals <ysld.raster.q2>:

                                                                                                                1. The color-map type property dictates how the values are used to generate a resulting color.

                                                                                                                  • ramp is used for quantitative data, providing a smooth interpolation between the provided color values.
                                                                                                                  • intervals provides categorization for quantitative data, assigning each range of values a solid color.
                                                                                                                  • values is used for qualitative data, each value is required to have a color-map entry or it will not be displayed.
                                                                                                                2. Challenge: Update your DEM example to use intervals for presentation. What are the advantages of using this approach for elevation data?

                                                                                                                  By using intervals it becomes very clear how relatively flat most of the continent is. The ramp presentation provided lots of fascinating detail which distracted from this fact.

                                                                                                                  Here is style for you to cut and paste:

                                                                                                                  symbolizers:\n- raster:\n    opacity: 1.0\n    color-map:\n      type: intervals\n      entries:\n      - ['#014636', 0, 0, null]\n      - ['#014636', 1.0, 1, null]\n      - ['#016C59', 1.0, 500, null]\n      - ['#02818A', 1.0, 1000, null]\n      - ['#3690C0', 1.0, 1500, null]\n      - ['#67A9CF', 1.0, 2000, null]\n      - ['#A6BDDB', 1.0, 2500, null]\n      - ['#D0D1E6', 1.0, 3000, null]\n      - ['#ECE2F0', 1.0, 3500, null]\n      - ['#FFF7FB', 1.0, 4000, null]\n
                                                                                                                "},{"location":"styling/workshop/ysld/done/#ysld.raster.a3","title":"Clear Digital Elevation Model Presentation","text":"

                                                                                                                Answer for Challenge Clear Digital Elevation Model Presentation <ysld.raster.q3>:

                                                                                                                1. Now that you have seen the data on screen and have a better understanding how would you modify our initial gray-scale example?

                                                                                                                2. Challenge: Use what you have learned to present the usgs:dem clearly.

                                                                                                                  The original was a dark mess. Consider making use of mid-tones (or adopting a sequential palette from color brewer) in order to fix this. In the following example the ocean has been left dark, allowing the mountains stand out more.

                                                                                                                  symbolizers:\n- raster:\n    opacity: 1.0\n    color-map:\n      type: ramp\n      entries:\n      - ['#000000', 1.0, 0, null]\n      - ['#444444', 1.0, 1, null]\n      - ['#FFFFFF', 1.0, 3000, null]\n
                                                                                                                "},{"location":"styling/workshop/ysld/done/#ysld.raster.a4","title":"Raster Opacity","text":"

                                                                                                                Discussion for Challenge Clear Digital Elevation Model Presentation <ysld.raster.q3>:

                                                                                                                1. There is a quick way to make raster data transparent, raster opacity property works in the same fashion as with vector data. The raster as a whole will be drawn partially transparent allow content from other layers to provide context.

                                                                                                                2. Challenge: Can you think of an example where this would be useful?

                                                                                                                  This is difficult as raster data is usually provided for use as a basemap, with layers being drawn over top.

                                                                                                                  The most obvious example here is the display of weather systems, or model output such as fire danger. By drawing the raster with some transparency, the landmass can be shown for context.

                                                                                                                "},{"location":"styling/workshop/ysld/linestring/","title":"Lines","text":"

                                                                                                                We will start our tour of YSLD styling by looking at the representation of lines.

                                                                                                                LineString Geometry

                                                                                                                Review of line symbology:

                                                                                                                • Lines can be used to represent either abstract concepts with length but not width such as networks and boundaries, or long thin features with a width that is too small to represent on the map. This means that the visual width of line symbols do not normally change depending on scale.
                                                                                                                • Lines are recorded as LineStrings or Curves depending on the geometry model used.
                                                                                                                • SLD uses a LineSymbolizer to record how the shape of a line is drawn. The primary characteristic documented is the Stroke used to draw each segment between vertices.
                                                                                                                • Labeling of line work is anchored to the midpoint of the line. GeoServer provides a vendor option to allow label rotation aligned with line segments.

                                                                                                                For our exercises we are going to be using simple YSLD documents, often consisting of a single rule, in order to focus on the properties used for line symbology.

                                                                                                                Each exercise makes use of the ne:roads layer.

                                                                                                                Reference:

                                                                                                                • YSLD Reference
                                                                                                                • YSLD Reference Line symbolizer (User Manual | YSLD Reference)
                                                                                                                • LineString (User Manual | SLD Reference )
                                                                                                                "},{"location":"styling/workshop/ysld/linestring/#line","title":"Line","text":"

                                                                                                                A line symbolizer is represented by a line key. You can make a completely default symbolizer by giving it an empty map

                                                                                                                line:\n

                                                                                                                Basic Stroke Properties

                                                                                                                1. Navigate to the Styles page.

                                                                                                                2. Click Add a new style and choose the following:

                                                                                                                    • New style name:
                                                                                                                    • line_example
                                                                                                                    • Workspace for new layer:
                                                                                                                    • Leave blank
                                                                                                                    • Format:
                                                                                                                    • YSLD
                                                                                                                3. Choose line from the Generate a default style dropdown and click generate.

                                                                                                                4. The style editor should look like below:

                                                                                                                  title: dark yellow line\nsymbolizers:\n- line:\n    stroke-width: 1.0\n    stroke-color: '#99cc00'\n

                                                                                                                Note

                                                                                                                The title and value for stroke-color may be different.

                                                                                                                1. Click Apply

                                                                                                                2. Click Layer Preview to see your new style applied to a layer.

                                                                                                                  You can use this tab to follow along as the style is edited, it will refresh each time Apply is pressed.

                                                                                                                3. You can see the equivalent SLD by requesting http://localhost:8080/geoserver/rest/styles/line_example.sld?pretty=true which will currently show the default line symbolizer we created.

                                                                                                                  <?xml version=\"1.0\" encoding=\"UTF-8\"?><sld:StyledLayerDescriptor xmlns=\"http://www.opengis.net/sld\" xmlns:sld=\"http://www.opengis.net/sld\" xmlns:gml=\"http://www.opengis.net/gml\" xmlns:ogc=\"http://www.opengis.net/ogc\" version=\"1.0.0\">\n <sld:NamedLayer>\n  <sld:Name>line_example</sld:Name>\n  <sld:UserStyle>\n    <sld:Name>line_example</sld:Name>\n    <sld:Title>dark yellow line</sld:Title>\n    <sld:FeatureTypeStyle>\n      <sld:Name>name</sld:Name>\n      <sld:Rule>\n        <sld:LineSymbolizer>\n          <sld:Stroke>\n            <sld:CssParameter name=\"stroke\">#99CC00</sld:CssParameter>\n          </sld:Stroke>\n        </sld:LineSymbolizer>\n      </sld:Rule>\n    </sld:FeatureTypeStyle>\n  </sld:UserStyle>\n </sld:NamedLayer>\n</sld:StyledLayerDescriptor>\n

                                                                                                                We only specified the line symbolizer, so all of the boilerplate around was generated for us.

                                                                                                                1. Additional properties can be used fine-tune appearance. Use stroke-color to specify the colour of the line.

                                                                                                                  line:\n  stroke-color: blue\n
                                                                                                                2. stroke-width lets us make the line wider

                                                                                                                  line:\n  stroke-color: blue\nstroke-width: 2px\n
                                                                                                                3. stroke-dasharray applies a dot dash pattern.

                                                                                                                  line:\n  stroke-color: blue\nstroke-width: 2px\n  stroke-dasharray: 5 2\n
                                                                                                                4. Check the Layer Preview tab to preview the result.

                                                                                                                Note

                                                                                                                The GeoServer rendering engine is quite sophisticated and allows the use of units of measure (such as m or ft). While we are using pixels in this example, real world units will be converted using the current scale, allowing for lines that change width with the scale.

                                                                                                                "},{"location":"styling/workshop/ysld/linestring/#multiple-symbolizers","title":"Multiple Symbolizers","text":"

                                                                                                                Providing two strokes is often used to provide a contrasting edge (called casing) to thick lines. This can be created using two symbolizers.

                                                                                                                1. Start by filling in a bit of boilerplate that we'll be using

                                                                                                                  feature-styles:\n- rules:\n  - symbolizers:\n    - line:\n        stroke-color: '#8080E6'\n        stroke-width: 3px\n

                                                                                                                  The line symbolizer is inside a rule, which is inside a feature style.

                                                                                                                2. Add a second symbolizer to the rule

                                                                                                                  feature-styles:\n- rules:\n  - symbolizers:\n    - line:\n        stroke-color: black\n        stroke-width: 5px\n    - line:\n        stroke-color: '#8080E6'\n        stroke-width: 3px\n

                                                                                                                  The wider black line is first so it is drawn first, then the thinner blue line drawn second and so over top of the black line. This is called the painter's algorithm.

                                                                                                                3. If you look carefully you can see a problem with our initial attempt. The junctions of each line show that the casing outlines each line individually, making the lines appear randomly overlapped. Ideally we would like to control this process, only making use of this effect for overpasses.

                                                                                                                  This is because the black and blue symbolizers are being drawn on a feature by feature basis. For nice line casing, we want all of the black symbols, and then all of the blue symbols.

                                                                                                                4. Create a new feature style and move the second symbolizer there.

                                                                                                                  feature-styles:\n- rules:\n  - symbolizers:\n    - line:\n        stroke-color: black\n        stroke-width: 5px\n- rules:\n  - symbolizers:\n    - line:\n        stroke-color: '#8080E6'\n        stroke-width: 3px\n

                                                                                                                  Again we are using painter's algorithm order: the first feature style is drawn first then the second so the second is drawn on top of the first. The difference is that for each feature style, all of the features are drawn before the next feature style is drawn.

                                                                                                                5. If you look carefully you can see the difference.

                                                                                                                6. By using feature styles we have been able to simulate line casing.

                                                                                                                "},{"location":"styling/workshop/ysld/linestring/#label","title":"Label","text":"

                                                                                                                Our next example is significant as it introduces how text labels are generated.

                                                                                                                Use of Label Property

                                                                                                                This is also our first example making use of a dynamic style (where a value comes from an attribute from your data).

                                                                                                                1. To enable LineString labeling we add a text symbolizer witrh a label.

                                                                                                                  Update line_example with the following:

                                                                                                                  symbolizers:\n- line:\n    stroke-color: blue\n    stroke-width: 1px\n- text:\n    label: ${name}\n
                                                                                                                2. The SLD standard documents the default label position for each kind of Geometry. For LineStrings the initial label is positioned on the midway point of the line.

                                                                                                                3. We have used an expression to calculate a property value for label. The label is generated dynamically from the name attribute. Expressions are supplied within curly braces preceded with a dollar sign, and use Extended Constraint Query Language (ECQL) syntax.

                                                                                                                  symbolizers:\n- line:\n    stroke-color: blue\n    stroke-width: 1px\n- text:\n    label: ${name}\n
                                                                                                                4. Additional keys can be supplied to fine-tune label presentation:

                                                                                                                  symbolizers:\n- line:\n    stroke-color: blue\n    stroke-width: 1px\n- text:\n    label: ${name}\n    fill-color: black\nplacement: line\n    offset: 7px\n
                                                                                                                5. The fill-color property is set to black to provide the colour of the text.

                                                                                                                  symbolizers:\n- line:\n    stroke-color: blue\n    stroke-width: 1px\n- text:\n    label: ${name}\n    fill-color: black\n    placement: line\n    offset: 7px\n
                                                                                                                6. The placement property is used to set how the label is placed with respect to the line. By default it is point which causes the label to be placed next to the midpoint as it would be for a point feature. When set to line it is placed along the line instead. offset specifies how far from the line the label should be placed.

                                                                                                                  symbolizers:\n- line:\n    stroke-color: blue\n    stroke-width: 1px\n- text:\n    label: ${name}\n    fill-color: black\n    placement: line\n    offset: 7px\n

                                                                                                                7. When using point placement, you can shift the position of the label using displacement instead of offset. This takes an x value and a y value.

                                                                                                                  symbolizers:\n- line:\n    stroke-color: blue\n    stroke-width: 1px\n- text:\n    label: ${name}\n    fill-color: black\n    displacement: [5px, -10px]\n
                                                                                                                "},{"location":"styling/workshop/ysld/linestring/#how-labeling-works","title":"How Labeling Works","text":"

                                                                                                                The rendering engine collects all the generated labels during the rendering of each layer. Then, during labeling, the engine sorts through the labels performing collision avoidance (to prevent labels overlapping). Finally the rendering engine draws the labels on top of the map. Even with collision avoidance you can spot areas where labels are so closely spaced that the result is hard to read.

                                                                                                                The parameters provided by SLD are general purpose and should be compatible with any rendering engine.

                                                                                                                To take greater control over the GeoServer rendering engine we can use \"vendor specific\" parameters. These hints are used specifically for the GeoServer rendering engine and will be ignored by other systems. In YSLD vendor specific parameters start with the prefix x-.

                                                                                                                1. The ability to take control of the labeling process is exactly the kind of hint a vendor specific parameter is intended for.

                                                                                                                  Update line_example with the following:

                                                                                                                  symbolizers:\n- line:\n    stroke-color: blue\n    stroke-width: 1px\n- text:\n    label: ${name}\n    fill-color: black\n    placement: line\n    offset: 7px\nx-label-padding: 10\n
                                                                                                                2. The parameter x-label-padding provides additional space around our label for use in collision avoidance.

                                                                                                                  symbolizers:\n- line:\n    stroke-color: blue\n    stroke-width: 1px\n- text:\n    label: ${name}\n    fill-color: black\n    placement: line\n    offset: 7px\nx-label-padding: 10\n
                                                                                                                3. Each label is now separated from its neighbor, improving legibility.

                                                                                                                "},{"location":"styling/workshop/ysld/linestring/#scale","title":"Scale","text":"

                                                                                                                This section explores the use of rules with filters and scale restrictions.

                                                                                                                1. Replace the line_example YSLD definition with:

                                                                                                                  rules:\n- filter: ${scalerank < 4}\n  symbolizers:\n  - line:\n      stroke-color: black\n      stroke-width: 1\n
                                                                                                                2. And use the Layer Preview tab to preview the result.

                                                                                                                3. The scalerank attribute is provided by the Natural Earth dataset to allow control of the level of detail based on scale. Our filter short-listed all content with scalerank 4 or lower, providing a nice quick preview when we are zoomed out.

                                                                                                                4. In addition to testing feature attributes, selectors can also be used to check the state of the rendering engine.

                                                                                                                  Replace your YSLD with the following:

                                                                                                                  rules:\n- scale: [35000000, max]\n  symbolizers:\n  - line:\n      stroke-color: black\n      stroke-width: 1\n- scale: [min, 35000000]\n  symbolizers:\n  - line:\n      stroke-color: blue\n      stroke-width: 1\n
                                                                                                                5. As you adjust the scale in the Layer Preview (using the mouse scroll wheel) the color will change between black and blue. You can read the current scale in the bottom right corner, and the legend will change to reflect the current style.

                                                                                                                6. Putting these two ideas together allows control of level detail based on scale:

                                                                                                                  define: &primaryStyle\n  stroke-color: black\ndefine: &primaryFilter ${scalerank <= 4}\n\ndefine: &secondaryStyle\n  stroke-color: '#000055'\ndefine: &secondaryFilter ${scalerank = 5}\n\nrules:\n\n  - else: true\n    scale: [min, 9000000]\n    symbolizers:\n    - line:\n        stroke-color: '#888888'\n        stroke-width: 1\n\n  - filter: ${scalerank = 7}\n    scale: [min, 17000000]\n    symbolizers:\n    - line:\n        stroke-color: '#777777'\n        stroke-width: 1\n\n  - filter: ${scalerank = 6}\n    scale: [min, 35000000]\n    symbolizers:\n    - line:\n        stroke-color: '#444444'\n        stroke-width: 1\n\n  - filter: *secondaryFilter\n    scale: [9000000, 70000000]\n    symbolizers:\n    - line:\n        <<: *secondaryStyle\n        stroke-width: 1\n  - filter: *secondaryFilter\n    scale: [min, 9000000]\n    symbolizers:\n    - line:\n        <<: *secondaryStyle\n        stroke-width: 2\n\n  - filter: *primaryFilter\n    scale: [35000000, max]\n    symbolizers:\n    - line:\n        <<: *primaryStyle\n        stroke-width: 1\n  - filter: *primaryFilter\n    scale: [9000000, 35000000]\n    symbolizers:\n    - line:\n        <<: *primaryStyle\n        stroke-width: 2\n  - filter: *primaryFilter\n    scale: [min, 9000000]\n    symbolizers:\n    - line:\n        <<: *primaryStyle\n        stroke-width: 4\n
                                                                                                                7. When a rule has both a filter and a scale, it will trigger when both are true.

                                                                                                                  The first rule has else: true instead of a filter. This causes it to be applied after all other rules have been checked if none of them worked.

                                                                                                                  Since there are some things we need to specify more than once like the colour and filter for primary and secondary roads, even as they change size at different scales, they are given names with define so they can be reused. The filters are inserted inline using *name while the style is inserted as a block with <<: *name

                                                                                                                "},{"location":"styling/workshop/ysld/linestring/#bonus","title":"Bonus","text":"

                                                                                                                Finished early? Here are some opportunities to explore what we have learned, and extra challenges requiring creativity and research.

                                                                                                                In a classroom setting please divide the challenges between teams (this allows us to work through all the material in the time available).

                                                                                                                Instructor Notes

                                                                                                                As usual the Explore section invites readers to reapply the material covered in a slightly different context or dataset.

                                                                                                                The use of selectors using the roads type attribute provides this opportunity.

                                                                                                                "},{"location":"styling/workshop/ysld/linestring/#explore-vendor-option-follow-line","title":"Explore Vendor Option Follow Line","text":"

                                                                                                                Vendor options can be used to enable some quite spectacular effects, while still providing a style that can be used by other applications.

                                                                                                                1. Update line_example with the following:

                                                                                                                  symbolizers:\n- line:\n    stroke-color: '#EDEDFF'\n    stroke-width: 10\n- text:\n    label: '${level} #${name}'\n    fill-color: '#000000'\n    x-followLine: true\n

                                                                                                                  The \\# character is the comment character in YAML, so we have to quote strings that contain it like colours and in this expression.

                                                                                                                2. The property stroke-width has been used to make our line thicker in order to provide a backdrop for our label.

                                                                                                                  symbolizers:\n- line:\n    stroke-color: '#EDEDFF'\n    stroke-width: 10\n- text:\n    label: '${level} #${name}'\n    fill-color: '#000000'\n    placement: point\n    x-followLine: true\n
                                                                                                                3. The label property combine several CQL expressions together for a longer label.

                                                                                                                  symbolizers:\n- line:\n    stroke-color: '#EDEDFF'\n    stroke-width: 10\n- text:\n    label: '${level} #${name}'\n    fill-color: '#000000'\n    x-followLine: true\n

                                                                                                                  The expressions in the label property:

                                                                                                                  ${level} #${name}\n

                                                                                                                  are inserted into the text by combining them with the text between them using Concatenate function:

                                                                                                                  [Concatenate(level,' #', name)]\n

                                                                                                                  This happens silently in the background.

                                                                                                                4. The property x-followLine provides the ability of have a label exactly follow a LineString character by character.

                                                                                                                  symbolizers:\n- line:\n    stroke-color: '#EDEDFF'\n    stroke-width: 10\n- text:\n    label: ${level}  ${name}\n    fill-color: '#000000'\n    x-followLine: true\n
                                                                                                                5. The result is a new appearance for our roads.

                                                                                                                "},{"location":"styling/workshop/ysld/linestring/#ysld.line.q1","title":"Challenge Classification","text":"
                                                                                                                1. The roads type attribute provides classification information.

                                                                                                                  You can Layer Preview to inspect features to determine available values for type.

                                                                                                                2. Challenge: Create a new style adjust road appearance based on type.

                                                                                                                  note:: The available values are 'Major Highway','Secondary Highway','Road' and 'Unknown'.

                                                                                                                  note:: Answer provided <ysld.line.a1> at the end of the workbook.

                                                                                                                "},{"location":"styling/workshop/ysld/linestring/#ysld.line.q2","title":"Challenge One Rule Classification","text":"
                                                                                                                1. You can save a lot of typing by doing your classification in an expression using arithmetic or the Recode function

                                                                                                                2. Challenge: Create a new style and classify the roads based on their scale rank using expressions in a single rule instead of multiple rules with filters.

                                                                                                                  Note

                                                                                                                  Answer provided <ysld.line.a2> at the end of the workbook.

                                                                                                                "},{"location":"styling/workshop/ysld/linestring/#ysld.line.q3","title":"Challenge Label Shields","text":"
                                                                                                                1. The traditional presentation of roads in the US is the use of a shield symbol, with the road number marked on top.

                                                                                                                2. Challenge: Have a look at the documentation for putting a graphic on a text symbolizer in SLD and reproduce this technique in YSLD.

                                                                                                                  Note

                                                                                                                  Answer provided <ysld.line.a3> at the end of the workbook.

                                                                                                                "},{"location":"styling/workshop/ysld/point/","title":"Points","text":"

                                                                                                                The next stop of the ysld styling tour is the representation of points.

                                                                                                                Review of point symbology:

                                                                                                                • Points are used to represent a location only, and do not form a shape. The visual width of lines do not change depending on scale.
                                                                                                                • SLD uses a PointSymbolizer record how the shape of a line is drawn.
                                                                                                                • Labeling of points is anchored to the point location.

                                                                                                                As points have no inherent shape of their own, emphasis is placed on marking locations with an appropriate symbol.

                                                                                                                Reference:

                                                                                                                • YSLD Reference
                                                                                                                • YSLD Reference Point symbolizer (User Manual | YSLD Reference)
                                                                                                                • Point (User Manual | SLD Reference )

                                                                                                                This exercise makes use of the ne:populated_places layer.

                                                                                                                1. Navigate to the Styles page.

                                                                                                                2. Click Add a new style and choose the following:

                                                                                                                    • Name:
                                                                                                                    • point_example
                                                                                                                    • Workspace:
                                                                                                                    • No workspace
                                                                                                                    • Format:
                                                                                                                    • YSLD
                                                                                                                3. Choose point from the Generate a default style dropdown and click generate.

                                                                                                                4. Replace the initial YSLD definition with the following and click apply:

                                                                                                                  symbolizers:\n- point:\n    symbols:\n    - mark:\n        shape: circle\n        stroke-width: 1\n
                                                                                                                5. And use the Layer Preview tab to preview the result.

                                                                                                                "},{"location":"styling/workshop/ysld/point/#mark","title":"Mark","text":"

                                                                                                                The point symbolizer controls the display of point data. Points are represented with the mandatory property mark.

                                                                                                                The SLD standard provides \"well-known\" symbols for use with point symbology: circle, square, triangle, arrow, cross, star, and x.

                                                                                                                1. Change the symbol used by the style to a square:

                                                                                                                  symbolizers:\n- point:\n    symbols:\n    - mark:\n        shape: square\n        stroke-width: 1\n
                                                                                                                2. Map Preview:

                                                                                                                3. Before we continue we will use a filter to cut down the amount of data shown to a reasonable level.

                                                                                                                  rules:\n- filter: ${SCALERANK < '1'}\n  scale: [min, max]\n  symbolizers:\n  - point:\n      symbols:\n      - mark:\n          shape: square\n          stroke-width: 1\n

                                                                                                                Note

                                                                                                                symbolizers has been indented under rules

                                                                                                                1. Resulting in a considerably cleaner image:

                                                                                                                2. Additional properties are available to control a mark's presentation:

                                                                                                                  The size property is used to control symbol size.

                                                                                                                  The rotation property controls orientation, accepting input in degrees.

                                                                                                                  Trying these two settings together:

                                                                                                                  rules:\n- filter: ${SCALERANK < '1'}\n  scale: [min, max]\n  symbolizers:\n  - point:\n      size: 8\n      rotation: 45.0\n      symbols:\n      - mark:\n          shape: square\n          stroke-width: 1\n
                                                                                                                3. Results in each location being marked with a diamond:

                                                                                                                4. The mark property provides parameters to style the point symbol. Let's change the fill-color to gray.

                                                                                                                  rules:\n- filter: ${SCALERANK < '1'}\n  scale: [min, max]\n  symbolizers:\n  - point:\n      size: 8\n      rotation: 45.0\n      symbols:\n      - mark:\n          shape: square\n          stroke-color: 'black'\n          stroke-width: 1\n          fill-color: 'gray'\n
                                                                                                                5. Updating the mark to a gray square with a black outline.

                                                                                                                6. You can add more symbolizers to apply additional point styles.

                                                                                                                  Using this approach marks can be composed of multiple symbols, each with its own settings:

                                                                                                                  rules:\n- filter: ${SCALERANK < '1'}\n  scale: [min, max]\n  symbolizers:\n  - point:\n      size: 16\n      symbols:\n      - mark:\n          shape: square\n          stroke-color: 'black'\n          stroke-width: 1\n          fill-color: 'red'\n  - point:\n      size: 14\n      rotation: 45.0\n      symbols:\n      - mark:\n          shape: cross\n          stroke-color: 'white'\n          stroke-width: 1\n          fill-color: 'black'\n
                                                                                                                7. Producing an interesting compound symbol effect:

                                                                                                                "},{"location":"styling/workshop/ysld/point/#graphic","title":"Graphic","text":"

                                                                                                                Symbols can also be supplied by an external graphic,

                                                                                                                This technique was shown with the initial airport.svg YSLD example.

                                                                                                                1. To use an external graphic two pieces of information are required.

                                                                                                                  url property is defined with a url reference to image.

                                                                                                                  format property is used to tell the rendering engine what file format to expect

                                                                                                                  This technique is used to reference files placed in the styles directory.

                                                                                                                  rules:\n- filter: ${SCALERANK < '1'}\n  scale: [min, max]\n  symbolizers:\n  - point:\n      symbols:\n      - external:\n          url: file:/path/to/geoserver/data_dir/styles/port.svg\n          format: image/svg\n
                                                                                                                2. Drawing the provided shape in each location:

                                                                                                                3. The property url reference can also be used to reference external images. We can make use of the GeoServer logo.

                                                                                                                  rules:\n- filter: ${SCALERANK < '1'}\n  scale: [min, max]\n  symbolizers:\n  - point:\n      size: 16\n      symbols:\n      - external:\n          url: http://localhost:8080/geoserver/web/wicket/resource/org.geoserver.web.GeoServerBasePage/img/logo.png\n          format: image/png\n
                                                                                                                4. As shown in the map preview.

                                                                                                                "},{"location":"styling/workshop/ysld/point/#label","title":"Label","text":"

                                                                                                                Labeling is now familiar from our experience with LineString and Polygons.

                                                                                                                The text symbolizer with the label property are required to label Point Locations.

                                                                                                                1. Replace point_example with the following:

                                                                                                                  rules:\n- filter: ${SCALERANK < '1'}\n  scale: [min, max]\n  symbolizers:\n  - point:\n      symbols:\n      - mark:\n          shape: circle\n          stroke-color: 'black'\n          stroke-width: 1\n          fill-color: 'gray'\n  - text:\n      label: ${NAME}\n      fill-color: 'gray'\n      placement: point\n
                                                                                                                2. Confirm the result in Layer Preview preview.

                                                                                                                3. Each label is drawn starting from the provided point - which is unfortunate as it assures each label will overlap with the symbol used. To fix this limitation we will make use of the YSLD controls for label placement:

                                                                                                                  anchor provides two values expressing how a label is aligned with respect to the starting label position.

                                                                                                                  displacement is be used to provide an initial displacement using and x and y offset. For points this offset is recommended to adjust the label position away for the area used by the symbol.

                                                                                                                  Note

                                                                                                                  The property anchor defines an anchor position relative to the bounding box formed by the resulting label. This anchor position is snapped to the label position generated by the point location and displacement offset.

                                                                                                                  Using these two facilities together we can center our labels below the symbol, taking care that the displacement used provides an offset just outside the area required for the symbol size.

                                                                                                                  rules:\n- filter: ${SCALERANK < '1'}\n  scale: [min, max]\n  symbolizers:\n  - point:\n      size: 10\n      symbols:\n      - mark:\n          shape: circle\n          stroke-color: 'black'\n          stroke-width: 1\n          fill-color: 'gray'\n  - text:\n      label: ${NAME}\n      fill-color: 'black'\n      placement: point\n      anchor: [0.5, 1.0]\n      displacement: [0, -12]\n
                                                                                                                4. Each label is now placed under the mark.

                                                                                                                5. One remaining issue is the overlap between labels and symbols.

                                                                                                                  GeoServer provides a vendor specific parameter to allow symbols to take part in label conflict resolution, preventing labels from overlapping any symbols. This severely limits the area available for labeling and is best used in conjunction with a large maximum displacement vendor option.

                                                                                                                  x-labelObstacle vendor parameter asks the rendering engine to avoid drawing labels over top of the indicated symbol. This applies to the point symbolizer.

                                                                                                                  x-maxDisplacement vendor parameter provides the rendering engine a maximum distance it is allowed to move labels during conflict resolution. This applies to the text symbolizer.

                                                                                                                  x-spaceAround vendor parameter tells the rendering engine to provide a minimum distance between the labels on the map, ensuring they do not overlap. This applies to the text symbolizer.

                                                                                                                  Update our example to use these settings:

                                                                                                                  rules:\n- filter: ${SCALERANK < '1'}\n  scale: [min, max]\n  symbolizers:\n  - point:\n      size: 10\n      symbols:\n      - mark:\n          shape: circle\n          stroke-color: 'black'\n          stroke-width: 1\n          fill-color: 'gray'\n      x-labelObstacle: true\n  - text:\n      label: ${NAME}\n      fill-color: 'black'\n      placement: point\n      anchor: [0.5, 1.0]\n      displacement: [0, -12]\n      x-maxDisplacement: 100\n      x-spaceAround: 2\n
                                                                                                                6. Resulting in a considerably cleaner image:

                                                                                                                "},{"location":"styling/workshop/ysld/point/#dynamic-styling","title":"Dynamic Styling","text":"
                                                                                                                1. We will quickly use scalerank to select content based on @scale filters.

                                                                                                                  define: &point\n  size: 6\n  symbols:\n  - mark:\n      shape: circle\n      stroke-color: 'black'\n      stroke-width: 1\n      fill-color: 'gray'\nrules:\n- filter: ${SCALERANK < '7'}\n  scale: ['4000000.0', '8000000.0']\n  symbolizers:\n  - point:\n      <<: *point\n- filter: ${SCALERANK < '5'}\n  scale: ['8000000.0', '1.7E7']\n  symbolizers:\n  - point:\n      <<: *point\n- filter: ${SCALERANK < '4'}\n  scale: ['1.7E7', '3.5E7']\n  symbolizers:\n  - point:\n      <<: *point\n- filter: ${SCALERANK < '3'}\n  scale: ['3.5E7', '7.0E7']\n  symbolizers:\n  - point:\n      <<: *point\n- filter: ${SCALERANK < '2'}\n  scale: ['7.0E7', '1.4E8']\n  symbolizers:\n  - point:\n      <<: *point\n- filter: ${SCALERANK < '1'}\n  scale: ['1.4E8', max]\n  symbolizers:\n  - point:\n      <<: *point\n- scale: [min, '4000000.0']\n  symbolizers:\n  - point:\n      <<: *point\n
                                                                                                                2. Click Apply to update the Layer Preview after each step.

                                                                                                                  Note

                                                                                                                  This YSLD makes use of a define to avoid repeating the point symbolizer content multiple times. As an example the [scale: [min, '4000000.0']]{.title-ref} rule, combined with the define: results in the following collection of properties:

                                                                                                                  - scale: [min, '4000000.0']\n  symbolizers:\n  - point:\n      size: 6\n      symbols:\n      - mark:\n          shape: circle\n          stroke-color: 'black'\n          stroke-width: 1\n          fill-color: 'gray'\n
                                                                                                                3. To add labeling we must use both a point and text symbolizer in each scale filter.

                                                                                                                  define: &point\n  size: 6\n  symbols:\n  - mark:\n      shape: circle\n      stroke-color: 'black'\n      stroke-width: 1\n      fill-color: 'gray'\ndefine: &label\n  label: ${NAME}\n  fill-color: 'black'\n  font-family: Arial\n  font-size: 10\n  font-style: normal\n  font-weight: normal\n  placement: point\nrules:\n- filter: ${SCALERANK < '7'}\n  scale: ['4000000.0', '8000000.0']\n  symbolizers:\n  - point:\n      <<: *point\n  - text:\n      <<: *label\n- filter: ${SCALERANK < '5'}\n  scale: ['8000000.0', '1.7E7']\n  symbolizers:\n  - point:\n      <<: *point\n  - text:\n      <<: *label\n- filter: ${SCALERANK < '4'}\n  scale: ['1.7E7', '3.5E7']\n  symbolizers:\n  - point:\n      <<: *point\n  - text:\n      <<: *label\n- filter: ${SCALERANK < '3'}\n  scale: ['3.5E7', '7.0E7']\n  symbolizers:\n  - point:\n      <<: *point\n  - text:\n      <<: *label\n- filter: ${SCALERANK < '2'}\n  scale: ['7.0E7', '1.4E8']\n  symbolizers:\n  - point:\n      <<: *point\n  - text:\n      <<: *label\n- filter: ${SCALERANK < '1'}\n  scale: ['1.4E8', max]\n  symbolizers:\n  - point:\n      <<: *point\n  - text:\n      <<: *label\n- scale: [min, '4000000.0']\n  symbolizers:\n  - point:\n      <<: *point\n  - text:\n      <<: *label\n

                                                                                                                4. We will use displacement and anchor to position the label above each symbol.

                                                                                                                  Add the following two lines to the label define:

                                                                                                                  define: &label\n  label: ${NAME}\n  fill-color: 'black'\n  font-family: Arial\n  font-size: 10\n  font-style: normal\n  font-weight: normal\n  placement: point\n  anchor: [0.5, 0]\n  displacement: [0, 6]\n

                                                                                                                5. A little bit of work with vendor specific parameters will prevent our labels from colliding with each symbol, while giving the rendering engine some flexibility in how far it is allowed to relocate a label.

                                                                                                                  Add the following vendor options to the label define:

                                                                                                                  define: &label\n  label: ${NAME}\n  fill-color: 'black'\n  font-family: Arial\n  font-size: 10\n  font-style: normal\n  font-weight: normal\n  placement: point\n  anchor: [0.5, 0]\n  displacement: [0, 6]\n  x-maxDisplacement: 90\n  x-spaceAround: 2\n

                                                                                                                  Add the following vendor option to the point define:

                                                                                                                  define: &point\n  size: 6\n  symbols:\n  - mark:\n      shape: circle\n      stroke-color: 'black'\n      stroke-width: 1\n      fill-color: 'gray'\n  x-labelObstacle: true\n

                                                                                                                6. Now that we have clearly labeled our cities, zoom into an area you are familiar with and we can look at changing symbology on a case-by-case basis.

                                                                                                                  We have used expressions previous to generate an appropriate label. Expressions can also be used for many other property settings.

                                                                                                                  The ne:populated_places layer provides several attributes specifically to make styling easier:

                                                                                                                  • SCALERANK: we have already used this attribute to control the level of detail displayed
                                                                                                                  • LABELRANK: hint used for conflict resolution, allowing important cities such as capitals to be labeled even when they are close to a larger neighbor.
                                                                                                                  • FEATURECLA: used to indicate different types of cities. We will check for Admin-0 capital cities.

                                                                                                                  The first thing we will do is calculate the point size using a quick expression:

                                                                                                                  ${10-(SCALERANK/2)}\n

                                                                                                                  This expression should result in sizes between 5 and 9 and will need to be applied to both point size and label displacement.

                                                                                                                  Rather than the \"first come first served\" default to resolve labeling conflicts we can manually provide GeoServer with a label priority. The expression provided is calculated for each label, in the event of a conflict the label with the highest priority takes precedence.

                                                                                                                  The LABELRANK attribute goes from 1 through 10 and needs to be flipped around before use as a GeoServer label priority:

                                                                                                                  ${10 - LABELRANK}\n

                                                                                                                  This expression will result in values between 0 and 10 and will be used for the priority.

                                                                                                                  define: &point\n  size: ${10-(SCALERANK/2)}\n  symbols:\n  - mark:\n      shape: circle\n      stroke-color: 'black'\n      stroke-width: 1\n      fill-color: 'gray'\n  x-labelObstacle: true\ndefine: &label\n  label: ${NAME}\n  fill-color: 'black'\n  font-family: Arial\n  font-size: 10\n  font-style: normal\n  font-weight: normal\n  placement: point\n  anchor: [0.5, 0]\n  displacement: [0, '${''10'' - SCALERANK / ''2''}']\n  priority: ${'10' - LABELRANK}\n  x-maxDisplacement: 90\n  x-spaceAround: 2\n

                                                                                                                7. Next we can use FEATURECLA to check for capital cities.

                                                                                                                  Adding a filter for capital cities at the top of the rules list:

                                                                                                                  - filter: ${SCALERANK < '2' AND FEATURECLA = 'Admin-0 capital'}\n  scale: ['7.0E7', max]\n  name: capitals\n  symbolizers:\n  - point:\n      symbols:\n      - mark:\n          shape: star\n          stroke-color: 'black'\n          stroke-width: 1\n          fill-color: 'gray'\n  - text:\n      label: ${NAME}\n      fill-color: 'gray'\n      placement: point\n- filter: ${FEATURECLA = 'Admin-0 capital'}\n  scale: [min, '7.0E7']\n  name: capitals\n  symbolizers:\n  - point:\n      symbols:\n      - mark:\n          shape: star\n          stroke-color: 'black'\n          stroke-width: 1\n          fill-color: 'gray'\n  - text:\n      label: ${NAME}\n      fill-color: 'gray'\n      placement: point\n

                                                                                                                  And updating the populated places filters to ignore capital cities:

                                                                                                                  - filter: ${SCALERANK < '7' AND FEATURECLA <> 'Admin-0 capital'}\n  scale: ['4000000.0', '8000000.0']\n  symbolizers:\n  - point:\n      <<: *point\n  - text:\n      <<: *label\n- filter: ${SCALERANK < '5' AND FEATURECLA <> 'Admin-0 capital'}\n  scale: ['8000000.0', '1.7E7']\n  symbolizers:\n  - point:\n      <<: *point\n  - text:\n      <<: *label\n- filter: ${SCALERANK < '4' AND FEATURECLA <> 'Admin-0 capital'}\n  scale: ['1.7E7', '3.5E7']\n  symbolizers:\n  - point:\n      <<: *point\n  - text:\n      <<: *label\n- filter: ${SCALERANK < '3' AND FEATURECLA <> 'Admin-0 capital'}\n  scale: ['3.5E7', '7.0E7']\n  symbolizers:\n  - point:\n      <<: *point\n  - text:\n      <<: *label\n- filter: ${SCALERANK < '2' AND FEATURECLA <> 'Admin-0 capital'}\n  scale: ['7.0E7', '1.4E8']\n  symbolizers:\n  - point:\n      <<: *point\n  - text:\n      <<: *label\n- filter: ${SCALERANK < '1' AND FEATURECLA <> 'Admin-0 capital'}\n  scale: ['1.4E8', max]\n  symbolizers:\n  - point:\n      <<: *point\n  - text:\n      <<: *label\n- scale: [min, '4000000.0']\n  symbolizers:\n  - point:\n      <<: *point\n  - text:\n      <<: *label\n

                                                                                                                8. If you would like to check your work the final file is here: point_example.ysld

                                                                                                                "},{"location":"styling/workshop/ysld/point/#bonus","title":"Bonus","text":"

                                                                                                                Instructor Notes

                                                                                                                The exercise section does not review the examples above, instead it explores the use of:

                                                                                                                • rules using min/max scale and rules using attribute filters
                                                                                                                • recode to map from attribute to symbol
                                                                                                                • interpolate to change size by population
                                                                                                                "},{"location":"styling/workshop/ysld/point/#ysld.point.q1","title":"Challenge Geometry Location","text":"

                                                                                                                Instructor Notes

                                                                                                                As usual Explore invites readers to reapply the material covered in a slightly different context or dataset.

                                                                                                                The use of filters using the roads type attribute provides this opportunity.

                                                                                                                1. The mark property can be used to render any geometry content.

                                                                                                                2. Challenge: Try this yourself by rendering a polygon layer using a mark property.

                                                                                                                  Note

                                                                                                                  Answer discussed <ysld.point.a1> at the end of the workbook.

                                                                                                                "},{"location":"styling/workshop/ysld/point/#ysld.point.q2","title":"Explore Dynamic Symbolization","text":"
                                                                                                                1. We went to a lot of work to set up filters to choose between star and circle for capital cities.

                                                                                                                  This approach is straightforward when applied in isolation:

                                                                                                                  rules:\n- filter: ${FEATURECLA = 'Admin-0 capital'}\n  scale: [min, max]\n  symbolizers:\n  - point:\n      symbols:\n      - mark:\n          shape: star\n          stroke-color: 'black'\n          stroke-width: 1\n          fill-color: 'gray'\n- filter: ${FEATURECLA <> 'Admin-0 capital'}\n  scale: [min, max]\n  symbolizers:\n  - point:\n      symbols:\n      - mark:\n          shape: circle\n          stroke-color: 'black'\n          stroke-width: 1\n          fill-color: 'gray'\n

                                                                                                                  When combined with checking another attribute, or checking @scale as in our example, this approach can quickly lead to many rules which can be difficult to keep straight.

                                                                                                                2. Taking a closer look, shape can actually be expressed using a string:

                                                                                                                  rules:\n- filter: ${FEATURECLA = 'Admin-0 capital'}\n  scale: [min, max]\n  symbolizers:\n  - point:\n      symbols:\n      - mark:\n          shape: 'star'\n          stroke-color: 'black'\n          stroke-width: 1\n          fill-color: 'gray'\n

                                                                                                                  Which is represented in SLD as:

                                                                                                                  <sld:PointSymbolizer>\n  <sld:Graphic>\n     <sld:Mark>\n        <sld:WellKnownName>star</sld:WellKnownName>\n        <sld:Fill/>\n        <sld:Stroke/>\n     </sld:Mark>\n  </sld:Graphic>\n</sld:PointSymbolizer>\n
                                                                                                                3. GeoServer recognizes this limitation of SLD Mark and ExternalGraphic and provides an opportunity for dynamic symbolization.

                                                                                                                  This is accomplished by embedding a small CQL expression in the string passed to symbol or url. This sub-expression is isolated with \\${ } as shown:

                                                                                                                  - point:\n    symbols:\n    - mark:\n        shape: ${if_then_else(equalTo(FEATURECLA,'Admin-0 capital'),'star','circle')}\n

                                                                                                                  Which is represented in SLD as:

                                                                                                                  <sld:PointSymbolizer>\n  <sld:Graphic>\n     <sld:Mark>\n        <sld:WellKnownName>${if_then_else(equalTo(FEATURECLA,'Admin-0 capital'),'star','circle')}</sld:WellKnownName>\n        <sld:Fill/>\n        <sld:Stroke/>\n     </sld:Mark>\n  </sld:Graphic>\n</sld:PointSymbolizer>\n
                                                                                                                4. Challenge: Use this approach to rewrite the Dynamic Styling example.

                                                                                                                  Note

                                                                                                                  Answer provided <ysld.point.a2> at the end of the workbook.

                                                                                                                1. Challenge: Use the Interpolate function to smoothly change the mark size based on city population.
                                                                                                                "},{"location":"styling/workshop/ysld/point/#ysld.point.q3","title":"Challenge Layer Group","text":"
                                                                                                                1. Use a Layer Group to explore how symbology works together to form a map.

                                                                                                                  • ne:NE1
                                                                                                                  • ne:states_provincces_shp
                                                                                                                  • ne:populated_places
                                                                                                                2. To help start things out here is a style for ne:states_provinces_shp:

                                                                                                                  symbolizers:\n- polygon:\n    stroke-color: 'black'\n    stroke-width: 0.25\n    stroke-opacity: 0.5\n    fill-color: 'white'\n    fill-opacity: 0.05\n- polygon:\n    stroke-color: 'black'\n    stroke-width: 0.25\n    stroke-opacity: 0.5\n    fill-color: ${Recode(mapcolor9,'1','#8dd3c7','2','#ffffb3','3','#bebada','4','#fb8072','5','#80b1d3','6','#fdb462','7','#b3de69','8','#fccde5','9','#d9d9d9')}\n    fill-opacity: 0.5\n
                                                                                                                3. This background is relatively busy and care must be taken to ensure both symbols and labels are clearly visible.

                                                                                                                4. Challenge: Do your best to style populated_places over this busy background.

                                                                                                                  Here is an example with labels for inspiration:

                                                                                                                  Note

                                                                                                                  Answer provided <ysld.point.a3> at the end of the workbook.

                                                                                                                "},{"location":"styling/workshop/ysld/point/#explore-true-type-fonts","title":"Explore True Type Fonts","text":"
                                                                                                                1. In addition to image formats GeoServer can make use other kinds of graphics, such as True Type fonts:

                                                                                                                  symbolizers:\n- point:\n    symbols:\n    - mark:\n        shape: ttf://Webdings#0x0064\n        stroke-color: 'blue'\n        stroke-width: 1\n
                                                                                                                2. Additional fonts dropped in the styles directory are available for use.

                                                                                                                "},{"location":"styling/workshop/ysld/point/#explore-custom-graphics","title":"Explore Custom Graphics","text":"
                                                                                                                1. The GeoServer rendering engine allows Java developers to hook in additional symbol support.

                                                                                                                  This facility is used by GeoServer to offer the shapes used for pattern fills. Community extensions allow the use of simple custom shapes and even charts.

                                                                                                                2. Support has been added for custom graphics using the WKT Geometry representation.

                                                                                                                  symbolizers:\n- point:\n    symbols:\n    - mark:\n        shape: wkt://MULTILINESTRING((-0.25 -0.25, -0.125 -0.25), (0.125 -0.25, 0.25 -0.25), (-0.25 0.25, -0.125 0.25), (0.125 0.25, 0.25 0.25))\n        stroke-color: 'blue'\n        stroke-width: 1\n
                                                                                                                "},{"location":"styling/workshop/ysld/polygon/","title":"Polygons","text":"

                                                                                                                Next we look at how YSLD styling can be used to represent polygons.

                                                                                                                Polygon Geometry

                                                                                                                Review of polygon symbology:

                                                                                                                • Polygons offer a direct representation of physical extent or the output of analysis.

                                                                                                                • The visual appearance of polygons reflects the current scale.

                                                                                                                • Polygons are recorded as a LinearRing describing the polygon boundary. Further LinearRings can be used to describe any holes in the polygon if present.

                                                                                                                  The Simple Feature for SQL Geometry model (used by GeoJSON) represents these areas as Polygons, the ISO 19107 geometry model (used by GML3) represents these areas as Surfaces.

                                                                                                                • SLD uses a PolygonSymbolizer to describe how the shape of a polygon is drawn. The primary characteristic documented is the Fill used to shade the polygon interior. The use of a Stroke to describe the polygon boundary is optional.

                                                                                                                • Labeling of a polygon is anchored to the centroid of the polygon. GeoServer provides a vendor-option to allow labels to line wrap to remain within the polygon boundaries.

                                                                                                                For our Polygon exercises we will try and limit our YSLD documents to a single rule, in order to showcase the properties used for rendering.

                                                                                                                Reference:

                                                                                                                • YSLD Reference
                                                                                                                • YSLD Reference Polygon symbolizer (User Manual | YSLD Reference)
                                                                                                                • Polygons (User Manual | SLD Reference )

                                                                                                                This exercise makes use of the ne:states_provinces_shp layer.

                                                                                                                1. Navigate to Styles.

                                                                                                                2. Create a new style polygon_example.

                                                                                                                    • Name:
                                                                                                                    • polygon_example
                                                                                                                    • Workspace:
                                                                                                                    • No workspace
                                                                                                                    • Format:
                                                                                                                    • YSLD
                                                                                                                3. Choose polygon from the Generate a default style dropdown and click generate.

                                                                                                                4. Replace the generated style with the following style and click Apply to save:

                                                                                                                  symbolizers:\n- polygon:\n    fill-color: 'lightgrey'\n
                                                                                                                5. Click on the tab Layer Preview to preview.

                                                                                                                6. Set ne:states_provinces_shp as the preview layer.

                                                                                                                "},{"location":"styling/workshop/ysld/polygon/#stroke-and-fill","title":"Stroke and Fill","text":"

                                                                                                                The polygon symbolizer controls the display of polygon data.

                                                                                                                The fill-color property is used to provide the color used to draw the interior of a polygon.

                                                                                                                1. Replace the contents of polygon_example with the following fill example:

                                                                                                                  symbolizers:\n- polygon:\n    fill-color: 'gray'\n
                                                                                                                2. The Layer Preview tab can be used preview the change:

                                                                                                                3. To draw the boundary of the polygon the stroke property is used:

                                                                                                                  The stroke property is used to provide the color and size of the polygon boundary. It is effected by the same parameters (and vendor specific parameters) as used for LineStrings.

                                                                                                                  symbolizers:\n- polygon:\n    fill-color: 'gray'\n    stroke-color: 'black'\n    stroke-width: 2\n

                                                                                                                  Note

                                                                                                                  Technically the boundary of a polygon is a specific case of a LineString where the first and last vertex are the same, forming a closed LinearRing.

                                                                                                                4. The effect of adding stroke is shown in the map preview:

                                                                                                                5. An interesting technique when styling polygons in conjunction with background information is to control the fill opacity.

                                                                                                                  The fill-opacity property is used to adjust transparency (provided as range from 0.0 to 1.0). Use of fill-opacity to render polygons works well in conjunction with a raster base map. This approach allows details of the base map to shown through.

                                                                                                                  The stroke-opacity property is used in a similar fashion, as a range from 0.0 to 1.0.

                                                                                                                  symbolizers:\n- polygon:\n    fill-color: 'white'\n    fill-opacity: 0.5\n    stroke-color: 'lightgrey'\n    stroke-width: 0.25\n    stroke-opacity: 0.5\n
                                                                                                                6. As shown in the map preview:

                                                                                                                7. This effect can be better appreciated using a layer group.

                                                                                                                  Where the transparent polygons is used lighten the landscape provided by the base map.

                                                                                                                Instructor Notes

                                                                                                                In this example we want to ensure readers know the key property for polygon data.

                                                                                                                It is also our first example of using opacity.

                                                                                                                "},{"location":"styling/workshop/ysld/polygon/#pattern","title":"Pattern","text":"

                                                                                                                The fill-graphic property can be used to provide a pattern.

                                                                                                                The fill pattern is defined by repeating one of the built-in symbols, or making use of an external image.

                                                                                                                1. We have two options for configuring a fill-graphic with a repeating graphic:

                                                                                                                  Using external to reference to an external graphic.

                                                                                                                  Use of mark to access a predefined shape. SLD provides several well-known shapes (circle, square, triangle, arrow, cross, star, and x). GeoServer provides additional shapes specifically for use as fill patterns.

                                                                                                                  Update polygon_example with the following built-in symbol as a repeating fill pattern:

                                                                                                                  symbolizers:\n- polygon:\n    fill-graphic:\n      symbols:\n      - mark:\n          shape: square\n          fill-color: 'gray'\n          stroke-color: 'black'\n          stroke-width: 1\n
                                                                                                                2. The map preview (and legend) will show the result:

                                                                                                                3. Add a black stroke:

                                                                                                                  symbolizers:\n- polygon:\n    stroke-color: 'black'\n    stroke-width: 1\n    fill-graphic:\n      symbols:\n      - mark:\n          shape: square\n          fill-color: 'gray'\n          stroke-color: 'black'\n          stroke-width: 1\n
                                                                                                                4. To outline the individual shapes:

                                                                                                                5. Additional fill properties allow control over the orientation and size of the symbol.

                                                                                                                  The size property is used to adjust the size of the symbol prior to use.

                                                                                                                  The rotation property is used to adjust the orientation of the symbol.

                                                                                                                  Adjust the size and rotation as shown:

                                                                                                                  symbolizers:\n- polygon:\n    stroke-color: 'black'\n    stroke-width: 1\n    fill-graphic:\n      size: 22\n      rotation: 45.0\n      symbols:\n      - mark:\n          shape: square\n          fill-color: 'gray'\n          stroke-color: 'black'\n          stroke-width: 1\n
                                                                                                                6. The size of each symbol is increased, and each symbol rotated by 45 degrees.

                                                                                                                  Note

                                                                                                                  Does the above look correct? There is an open request GEOT-4642 to rotate the entire pattern, rather than each individual symbol.

                                                                                                                7. The size and rotation properties just affect the size and placement of the symbol, but do not alter the symbol's design. In order to control the color we set the fill-color and stroke-color properties of the mark.

                                                                                                                8. Replace the contents of polygon_example with the following:

                                                                                                                  symbolizers:\n- polygon:\n    fill-graphic:\n      symbols:\n      - mark:\n          shape: square\n          fill-color: '#008000'\n          stroke-color: '#006400'\n          stroke-width: 1\n
                                                                                                                9. This change adjusts the appearance of our grid of squares.

                                                                                                                10. The well-known symbols are more suited for marking individual points. Now that we understand how a pattern can be controlled it is time to look at the patterns GeoServer provides.

                                                                                                                  shape://horizline horizontal hatching shape://vertline vertical hatching shape://backslash right hatching pattern shape://slash left hatching pattern shape://plus vertical and horizontal hatching pattern shape://times cross hatch pattern

                                                                                                                  Update the example to use shape://slash for a pattern of left hatching.

                                                                                                                  symbolizers:\n- polygon:\n    stroke-color: 'black'\n    stroke-width: 1\n    fill-graphic:\n      symbols:\n      - mark:\n          shape: 'shape://slash'\n          stroke-color: 'gray'\n
                                                                                                                11. This approach is well suited to printed output or low color devices.

                                                                                                                12. To control the size of the symbol produced use the size property of the fill-graphic.

                                                                                                                  symbolizers:\n- polygon:\n    stroke-color: 'black'\n    stroke-width: 1\n    fill-graphic:\n      size: 8\n      symbols:\n      - mark:\n          shape: 'shape://slash'\n          stroke-color: 'gray'\n
                                                                                                                13. This results in a tighter pattern shown:

                                                                                                                14. Multiple fills can be applied by using a separate symbolizer for each fill as part of the same rule.

                                                                                                                  symbolizers:\n- polygon:\n    stroke-color: 'black'\n    stroke-width: 1\n    fill-color: '#DDDDFF'\n- polygon:\n    fill-graphic:\n      size: 8\n      symbols:\n      - mark:\n          shape: shape://slash\n          stroke-color: 'black'\n          stroke-width: 0.5\n
                                                                                                                15. The resulting image has a solid fill, with a pattern drawn overtop.

                                                                                                                "},{"location":"styling/workshop/ysld/polygon/#label","title":"Label","text":"

                                                                                                                Labeling polygons follows the same approach used for LineStrings.

                                                                                                                The key properties fill and label are used to enable Polygon label generation.

                                                                                                                1. By default labels are drawn starting at the centroid of each polygon.

                                                                                                                2. Try out label and fill together by replacing our polygon_example with the following:

                                                                                                                  symbolizers:\n- polygon:\n    stroke-color: 'blue'\n    stroke-width: 1\n    fill-color: '#7EB5D3'\n- text:\n    label: ${name}\n    fill-color: 'black'\n
                                                                                                                3. Each label is drawn from the lower-left corner as shown in the Layer Preview preview.

                                                                                                                4. We can adjust how the label is drawn at the polygon centroid.

                                                                                                                  The property anchor provides two numbers expressing how a label is aligned with respect to the centroid. The first value controls the horizontal alignment, while the second value controls the vertical alignment. Alignment is expressed between 0.0 and 1.0 as shown in the following table.

                                                                                                                           Left      Center    Right\n

                                                                                                                  Top 0.0 1.0 0.5 1.0 1.0 1.0

                                                                                                                  Middle 0.0 0.5 0.5 0.5 1.0 0.5

                                                                                                                  Bottom 0.0 0.0 0.5 0.0 1.0 0.0

                                                                                                                  Adjusting the anchor is the recommended approach to positioning your labels.

                                                                                                                5. Using the anchor property we can center our labels with respect to geometry centroid.

                                                                                                                  To align the center of our label we select 50% horizontally and 50% vertically, by filling in 0.5 and 0.5 below:

                                                                                                                  symbolizers:\n- polygon:\n    stroke-color: 'blue'\n    stroke-width: 1\n    fill-color: '#7EB5D3'\n- text:\n    label: ${name}\n    fill-color: 'black'\n    anchor: [0.5, 0.5]\n
                                                                                                                6. The labeling position remains at the polygon centroid. We adjust alignment by controlling which part of the label we are \"snapping\" into position.

                                                                                                                7. The property displacement can be used to provide an initial displacement using and x and y offset.

                                                                                                                8. This offset is used to adjust the label position relative to the geometry centroid resulting in the starting label position.

                                                                                                                  symbolizers:\n- polygon:\n    stroke-color: 'blue'\n    stroke-width: 1\n    fill-color: '#7EB5D3'\n- text:\n    label: ${name}\n    fill-color: 'black'\n    displacement: [0, 7]\n
                                                                                                                9. Confirm this result in the map preview.

                                                                                                                10. These two settings can be used together.

                                                                                                                  The rendering engine starts by determining the label position generated from the geometry centroid and the label-offset displacement. The bounding box of the label is used with the label-anchor setting align the label to this location.

                                                                                                                  Step 1: starting label position = centroid + displacement

                                                                                                                  Step 2: snap the label anchor to the starting label position

                                                                                                                11. To move our labels down (allowing readers to focus on each shape) we can use displacement combined with followed by horizontal alignment.

                                                                                                                  symbolizers:\n- polygon:\n    stroke-color: 'blue'\n    stroke-width: 1\n    fill-color: '#7EB5D3'\n- text:\n    label: ${name}\n    fill-color: 'black'\n    anchor: [0.5, 1]\n    displacement: [0, -7]\n
                                                                                                                12. As shown in the map preview.

                                                                                                                "},{"location":"styling/workshop/ysld/polygon/#legibility","title":"Legibility","text":"

                                                                                                                When working with labels a map can become busy very quickly, and difficult to read.

                                                                                                                1. GeoServer provides extensive vendor parameters directly controlling the labelling process.

                                                                                                                  Many of these parameters focus on controlling conflict resolution (when labels would otherwise overlap).

                                                                                                                2. Two common properties for controlling labeling are:

                                                                                                                  x-maxDisplacement indicates the maximum distance GeoServer should displace a label during conflict resolution.

                                                                                                                  x-autoWrap allows any labels extending past the provided width will be wrapped into multiple lines.

                                                                                                                3. Using these together we can make a small improvement in our example:

                                                                                                                  symbolizers:\n- polygon:\n    stroke-color: 'blue'\n    stroke-width: 1\n    fill-color: '#7EB5D3'\n- text:\n    label: ${name}\n    fill-color: 'black'\n    anchor: [0.5, 0.5]\n    x-maxDisplacement: 40\n    x-autoWrap: 70\n
                                                                                                                4. As shown in the following preview.

                                                                                                                5. Even with this improved spacing between labels, it is difficult to read the result against the complicated line work.

                                                                                                                  Use of a halo to outline labels allows the text to stand out from an otherwise busy background. In this case we will make use of the fill color, to provide some space around our labels. We will also change the font to Arial.

                                                                                                                  symbolizers:\n- polygon:\n    stroke-color: 'blue'\n    stroke-width: 1\n    fill-color: '#7EB5D3'\n- text:\n    label: ${name}\n    fill-color: 'black'\n    anchor: [0.5, 0.5]\n    font-family: Arial\n    font-size: 14\n    font-style: normal\n    font-weight: normal\n    halo:\n      fill-color: '#7EB5D3'\n      fill-opacity: 0.8\n      radius: 2\n    x-maxDisplacement: 40\n    x-autoWrap: 70\n
                                                                                                                6. By making use of fill-opacity on the halo we still allow stroke information to show through, but prevent the stroke information from making the text hard to read.

                                                                                                                7. And advanced technique for manually taking control of conflict resolution is the use of the priority.

                                                                                                                  This property takes an expression which is used in the event of a conflict. The label with the highest priority \"wins.\"

                                                                                                                8. The Natural Earth dataset we are using includes a labelrank intended to control what labels are displayed based on zoom level.

                                                                                                                  The values for labelrank go from 0 (for zoomed out) to 20 (for zoomed in). To use this value for priority we need to swap the values around so a scalerank of 1 is given the highest priority.

                                                                                                                  symbolizers:\n- polygon:\n    stroke-color: 'blue'\n    stroke-width: 1\n    fill-color: '#7EB5D3'\n- text:\n    label: ${name}\n    fill-color: 'black'\n    anchor: [0.5, 0.5]\n    font-family: Arial\n    font-size: 14\n    font-style: normal\n    font-weight: normal\n    halo:\n      fill-color: '#7EB5D3'\n      fill-opacity: 0.8\n      radius: 2\n    x-maxDisplacement: 40\n    x-autoWrap: 70\n    priority: ${'20' - labelrank}\n
                                                                                                                9. In the following map East Flanders will take priority over Zeeland when the two labels overlap.

                                                                                                                "},{"location":"styling/workshop/ysld/polygon/#theme","title":"Theme","text":"

                                                                                                                A thematic map (rather than focusing on representing the shape of the world) uses elements of style to illustrate differences in the data under study. This section is a little more advanced and we will take the time to look at the generated SLD file.

                                                                                                                Instructor Notes

                                                                                                                This instruction section follows our pattern with LineString. Building on the examples and exploring how selectors can be used.

                                                                                                                • For LineString we explored the use of @scale, in this section we are going to look at theming by attribute.
                                                                                                                • We also unpack how cascading occurs, and what the result looks like in the generated XML.
                                                                                                                • care is being taken to introduce the symbology encoding functions as an option for theming ( placing equal importance on their use).

                                                                                                                Checklist:

                                                                                                                • filter vs function for theming
                                                                                                                • Cascading
                                                                                                                1. We can use a site like ColorBrewer to explore the use of color theming for polygon symbology. In this approach the fill color of the polygon is determined by the value of the attribute under study.

                                                                                                                  This presentation of a dataset is known as \"theming\" by an attribute.

                                                                                                                2. For our ne:states_provinces_shp dataset, a mapcolor9 attribute has been provided for this purpose. Theming by mapcolor9 results in a map where neighbouring countries are visually distinct.

                                                                                                                  +----------------------------+---------+---------+ | > Qualitative 9-class Set3 | | | +----------------------------+---------+---------+ | #8dd3c7 | #fb8072 | #b3de69 | +----------------------------+---------+---------+ | #ffffb3 | #80b1d3 | #fccde5 | +----------------------------+---------+---------+ | #bebada | #fdb462 | #d9d9d9 | +----------------------------+---------+---------+

                                                                                                                  If you are unfamiliar with theming you may wish to visit http://colorbrewer2.org to learn more. The i icons provide an adequate background on theming approaches for qualitative, sequential and diverging datasets.

                                                                                                                3. The first approach we will take is to directly select content based on colormap, providing a color based on the 9-class Set3 palette above:

                                                                                                                  define: &stroke\n  stroke-color: 'gray'\n  stroke-width: 0.5\nrules:\n  - filter: ${mapcolor9 = '1'}\n    scale: [min, max]\n    symbolizers:\n    - polygon:\n        <<: *stroke\n        fill-color: '#8DD3C7'\n  - filter: ${mapcolor9 = '2'}\n    scale: [min, max]\n    symbolizers:\n    - polygon:\n        <<: *stroke\n        fill-color: '#FFFFB3'\n  - filter: ${mapcolor9 = '3'}\n    scale: [min, max]\n    symbolizers:\n    - polygon:\n        <<: *stroke\n        fill-color: '#BEBADA'\n  - filter: ${mapcolor9 = '4'}\n    scale: [min, max]\n    symbolizers:\n    - polygon:\n        <<: *stroke\n        fill-color: '#FB8072'\n  - filter: ${mapcolor9 = '5'}\n    scale: [min, max]\n    symbolizers:\n    - polygon:\n        <<: *stroke\n        fill-color: '#80B1D3'\n  - filter: ${mapcolor9 = '6'}\n    scale: [min, max]\n    symbolizers:\n    - polygon:\n        <<: *stroke\n        fill-color: '#FDB462'\n  - filter: ${mapcolor9 = '7'}\n    scale: [min, max]\n    symbolizers:\n    - polygon:\n        <<: *stroke\n        fill-color: '#B3DE69'\n  - filter: ${mapcolor9 = '8'}\n    scale: [min, max]\n    symbolizers:\n    - polygon:\n        <<: *stroke\n        fill-color: '#FCCDE5'\n  - filter: ${mapcolor9 = '9'}\n    scale: [min, max]\n    symbolizers:\n    - polygon:\n        <<: *stroke\n        fill-color: '#D9D9D9'\n  - filter: ${mapcolor9 <> '1' AND mapcolor9 <> '2' AND mapcolor9 <> '3' AND mapcolor9 <> '4' AND mapcolor9 <> '5' AND mapcolor9 <> '6' AND mapcolor9 <> '7' AND mapcolor9 <> '8' AND mapcolor9 <> '9'}\n    scale: [min, max]\n    symbolizers:\n    - line:\n        <<: *stroke\n
                                                                                                                4. The Layer Preview tab can be used to preview this result.

                                                                                                                5. This YSLD makes use of a define to avoid repeating the stroke-color and stroke-width information multiple times.

                                                                                                                  As an example the \\${mapcolor9 = '2'} rule, combined with the define: results in the following collection of properties:

                                                                                                                  - filter: ${mapcolor9 = '2'}\n    scale: [min, max]\n    symbolizers:\n    - polygon:\n        stroke-color: 'gray'\n        stroke-width: 0.5\n        fill-color: '#FFFFB3'\n
                                                                                                                6. Reviewing the generated SLD shows us this representation:

                                                                                                                  <sld:Rule>\n   <ogc:Filter>\n      <ogc:PropertyIsEqualTo>\n         <ogc:PropertyName>mapcolor9</ogc:PropertyName>\n         <ogc:Literal>2</ogc:Literal>\n      </ogc:PropertyIsEqualTo>\n   </ogc:Filter>\n   <sld:PolygonSymbolizer>\n      <sld:Fill>\n         <sld:CssParameter name=\"fill\">#ffffb3</sld:CssParameter>\n      </sld:Fill>\n   </sld:PolygonSymbolizer>\n   <sld:LineSymbolizer>\n      <sld:Stroke>\n         <sld:CssParameter name=\"stroke\">#808080</sld:CssParameter>\n         <sld:CssParameter name=\"stroke-width\">0.5</sld:CssParameter>\n      </sld:Stroke>\n   </sld:LineSymbolizer>\n</sld:Rule>\n
                                                                                                                7. There are three important functions, defined by the Symbology Encoding specification, that are often easier to use for theming than using rules.

                                                                                                                  • Recode: Used the theme qualitative data. Attribute values are directly mapped to styling property such as fill or stroke-width.
                                                                                                                  • Categorize: Used the theme quantitative data. Categories are defined using min and max ranges, and values are sorted into the appropriate category.
                                                                                                                  • Interpolate: Used to smoothly theme quantitative data by calculating a styling property based on an attribute value.

                                                                                                                  Theming is an activity, producing a visual result allow map readers to learn more about how an attribute is distributed spatially. We are free to produce this visual in the most efficient way possible.

                                                                                                                8. Swap out mapcolor9 theme to use the Recode function:

                                                                                                                  symbolizers:\n- polygon:\n    stroke-color: 'gray'\n    stroke-width: 0.5\n    fill-color: ${Recode(mapcolor9,\n      '1','#8dd3c7',\n      '2','#ffffb3',\n      '3','#bebada',\n      '4','#fb8072',\n      '5','#80b1d3',\n      '6','#fdb462',\n      '7','#b3de69',\n      '8','#fccde5',\n      '9','#d9d9d9')}\n
                                                                                                                9. The Layer Preview tab provides the same preview.

                                                                                                                10. The Generated SLD tab shows where things get interesting. Our generated style now consists of a single Rule:

                                                                                                                  <sld:Rule>\n   <sld:PolygonSymbolizer>\n      <sld:Fill>\n         <sld:CssParameter name=\"fill\">\n            <ogc:Function name=\"Recode\">\n               <ogc:PropertyName>mapcolor9</ogc:PropertyName>\n               <ogc:Literal>1</ogc:Literal>\n                  <ogc:Literal>#8dd3c7</ogc:Literal>\n               <ogc:Literal>2</ogc:Literal>\n                  <ogc:Literal>#ffffb3</ogc:Literal>\n               <ogc:Literal>3</ogc:Literal>\n                  <ogc:Literal>#bebada</ogc:Literal>\n               <ogc:Literal>4</ogc:Literal>\n                  <ogc:Literal>#fb8072</ogc:Literal>\n               <ogc:Literal>5</ogc:Literal>\n                  <ogc:Literal>#80b1d3</ogc:Literal>\n               <ogc:Literal>6</ogc:Literal>\n                  <ogc:Literal>#fdb462</ogc:Literal>\n               <ogc:Literal>7</ogc:Literal>\n                  <ogc:Literal>#b3de69</ogc:Literal>\n               <ogc:Literal>8</ogc:Literal>\n                  <ogc:Literal>#fccde5</ogc:Literal>\n               <ogc:Literal>9</ogc:Literal>\n                  <ogc:Literal>#d9d9d9</ogc:Literal>\n         </ogc:Function>\n         </sld:CssParameter>\n      </sld:Fill>\n   </sld:PolygonSymbolizer>\n   <sld:LineSymbolizer>\n      <sld:Stroke>\n         <sld:CssParameter name=\"stroke\">#808080</sld:CssParameter>\n         <sld:CssParameter name=\"stroke-width\">0.5</sld:CssParameter>\n      </sld:Stroke>\n   </sld:LineSymbolizer>\n</sld:Rule>\n
                                                                                                                "},{"location":"styling/workshop/ysld/polygon/#bonus","title":"Bonus","text":"

                                                                                                                The following optional explore and challenge activities offer a chance to review and apply the ideas introduced here. The challenge activities require a bit of creativity and research to complete.

                                                                                                                In a classroom setting you are encouraged to team up into groups, with each group taking on a different challenge.

                                                                                                                "},{"location":"styling/workshop/ysld/polygon/#ysld.polygon.q1","title":"Explore Antialiasing","text":"
                                                                                                                1. When we rendered our initial preview, without a stroke, thin white gaps (or slivers) are visible between our polygons.

                                                                                                                  This effect is made more pronounced by the rendering engine making use of the Java 2D sub-pixel accuracy. This technique is primarily used to prevent an aliased (stair-stepped) appearance on diagonal lines.

                                                                                                                2. Clients can turn this feature off using a GetMap format option:

                                                                                                                  format_options=antialiasing=off;\n

                                                                                                                  The LayerPreview provides access to this setting from the Open Layers Options Toolbar:

                                                                                                                3. Explore: Experiment with fill and stroke settings to eliminate slivers between polygons.

                                                                                                                  Note

                                                                                                                  Answer provided <ysld.polygon.a1> at the end of the workbook.

                                                                                                                "},{"location":"styling/workshop/ysld/polygon/#ysld.polygon.q2","title":"Explore Categorize","text":"

                                                                                                                Instructor Notes

                                                                                                                This section reviews use of the Symbology Encoding Categorize function for something else other than color. Goal is to have readers reach for SE Functions as often as selectors when styling.

                                                                                                                Additional exercise ideas:

                                                                                                                • Control size using Interpolate: While Recode offers an alternative for selectors (matching discrete values) Interpolate brings something new to the table - gradual color (or value) progression. The best of example of this is controlling width using the ne:rivers data layer (which is not yet available).
                                                                                                                1. The Categorize function can be used to generate property values based on quantitative information. Here is an example using Categorize to color states according to size.

                                                                                                                  symbolizers:\n- polygon:\n    fill-color: ${Categorize(Shape_Area,\n      '#08519c','0.5',\n      '#3182bd','1',\n      '#6baed6','5',\n      '#9ecae1','60',\n      '#c6dbef','80',\n      '#eff3ff')}\n

                                                                                                                2. An exciting use of the GeoServer shape symbols is the theming by changing the size used for pattern density.

                                                                                                                3. Explore: Use the Categorize function to theme by datarank.

                                                                                                                  Note

                                                                                                                  Answer provided <ysld.polygon.a2> at the end of the workbook.

                                                                                                                "},{"location":"styling/workshop/ysld/polygon/#ysld.polygon.q3","title":"Challenge Goodness of Fit","text":"
                                                                                                                1. A subject we touched on during labeling was the conflict resolution GeoServer performs to ensure labels do not overlap.

                                                                                                                2. In addition to the vendor parameter for max displacement you can experiment with different values for \"goodness of fit\". These settings control how far GeoServer is willing to move a label to avoid conflict, and under what terms it simply gives up:

                                                                                                                  x-goodnessOfFit: 0.3\nx-maxDisplacement: 130\n
                                                                                                                3. You can also experiment with turning off this facility completely:

                                                                                                                  x-conflictResolution: false\n
                                                                                                                4. Challenge: Construct your own example using maxDisplacement and goodnessOfFit.

                                                                                                                "},{"location":"styling/workshop/ysld/polygon/#ysld.polygon.q4","title":"Challenge Halo","text":"
                                                                                                                1. The halo example used the fill color and opacity for a muted halo, while this improved readability it did not bring attention to our labels.

                                                                                                                  A common design choice for emphasis is to outline the text in a contrasting color.

                                                                                                                2. Challenge: Produce a map that uses a white halo around black text.

                                                                                                                  Note

                                                                                                                  Answer provided <ysld.polygon.a4> at the end of the workbook.

                                                                                                                "},{"location":"styling/workshop/ysld/polygon/#ysld.polygon.q5","title":"Challenge Theming using Multiple Attributes","text":"
                                                                                                                1. A powerful tool is theming using multiple attributes. This is an important concept allowing map readers to perform \"integration by eyeball\" (detecting correlations between attribute values information).

                                                                                                                2. Challenge: Combine the mapcolor9 and datarank examples to reproduce the following map.

                                                                                                                  Note

                                                                                                                  Answer provided <ysld.polygon.a5> at the end of the workbook.

                                                                                                                "},{"location":"styling/workshop/ysld/polygon/#ysld.polygon.q6","title":"Challenge Use of Z-Index","text":"
                                                                                                                1. Earlier we looked at using multiple feature-styles to simulate line string casing. The line work was drawn twice, once with thick line, and then a second time with a thinner line. The resulting effect is similar to text halos - providing breathing space around complex line work allowing it to stand out.

                                                                                                                2. Challenge: Use what you know of LineString feature-styles to reproduce the following map:

                                                                                                                  Note

                                                                                                                  Answer provided <ysld.polygon.a6> at the end of the workbook.

                                                                                                                "},{"location":"styling/workshop/ysld/raster/","title":"Rasters","text":"

                                                                                                                Finally we will look at using YSLD styling for the portrayal of raster data.

                                                                                                                Raster Symbology

                                                                                                                Review of raster symbology:

                                                                                                                • Raster data is Grid Coverage where values have been recorded in a regular array. In OGC terms a Coverage can be used to look up a value or measurement for each location.

                                                                                                                • When queried with a \"sample\" location:

                                                                                                                  • A grid coverage can determine the appropriate array location and retrieve a value. Different techniques may be used interpolate an appropriate value from several measurements (higher quality) or directly return the \"nearest neighbor\" (faster).
                                                                                                                  • A vector coverages would use a point-in-polygon check and return an appropriate attribute value.
                                                                                                                  • A scientific model can calculate a value for each sample location
                                                                                                                • Many raster formats organize information into bands of content. Values recorded in these bands and may be mapped into colors for display (a process similar to theming an attribute for vector data).

                                                                                                                  For imagery the raster data is already formed into red, green and blue bands for display.

                                                                                                                • As raster data has no inherent shape, the format is responsible for describing the orientation and location of the grid used to record measurements.

                                                                                                                These raster examples use a digital elevation model consisting of a single band of height measurements. The imagery examples use an RGB image that has been hand coloured for use as a base map.

                                                                                                                Reference:

                                                                                                                • YSLD Reference
                                                                                                                • Raster (YSLD Reference | Raster symbolizer)
                                                                                                                • Raster (User Manual | SLD Reference )

                                                                                                                The exercise makes use of the usgs:dem and ne:ne1 layers.

                                                                                                                "},{"location":"styling/workshop/ysld/raster/#image","title":"Image","text":"

                                                                                                                The raster symbolizer controls the display of raster data. By default, the raster symbolizer automatically selects the appropriate red, green and blue channels for display.

                                                                                                                1. Navigate to the Styles page.

                                                                                                                2. Click Add a new style and choose the following:

                                                                                                                    • Name:
                                                                                                                    • image_example
                                                                                                                    • Workspace:
                                                                                                                    • No workspace
                                                                                                                    • Format:
                                                                                                                    • YSLD
                                                                                                                3. Choose raster from the Generate a default style dropdown and click generate.

                                                                                                                4. Replace the initial YSLD definition with:

                                                                                                                  symbolizers:\n- raster:\n    opacity: 1.0\n
                                                                                                                5. And use the Layer Preview tab to preview the result.

                                                                                                                6. The channels property can be used to provide a list three band numbers (for images recording in several wavelengths) or a single band number can be used to view a grayscale image.

                                                                                                                  symbolizers:\n- raster:\n    opacity: 1.0\n    channels:\n      gray:\n        name: '2'\n
                                                                                                                7. Isolating just the green band (it will be drawn as a grayscale image):

                                                                                                                "},{"location":"styling/workshop/ysld/raster/#dem","title":"DEM","text":"

                                                                                                                A digital elevation model is an example of raster data made up of measurements, rather than color information.

                                                                                                                The usgs:dem layer used for this exercise:

                                                                                                                1. Return to the Styles page.

                                                                                                                2. Click Add a new style and choose the following:

                                                                                                                    • Name:
                                                                                                                    • raster_example
                                                                                                                    • Workspace:
                                                                                                                    • No workspace
                                                                                                                    • Format:
                                                                                                                    • YSLD
                                                                                                                3. Choose raster from the Generate a default style dropdown and click generate.

                                                                                                                4. The rendering engine will select our single band of raster content, and do its best to map these values into a grayscale image. Replace the content of the style with:

                                                                                                                  symbolizers:\n- raster:\n    opacity: 1.0\n
                                                                                                                5. Use the Layer Preview tab to preview the result. The range produced in this case from the highest and lowest values.

                                                                                                                6. We can use a bit of image processing to emphasis the generated color mapping by making use of contrast-enhancement.

                                                                                                                  symbolizers:\n- raster:\n    opacity: 1.0\n    channels:\n      gray:\n        name: '1'\n        contrast-enhancement:\n          mode: histogram\n
                                                                                                                7. Image processing of this sort should be used with caution as it does distort the presentation (in this case making the landscape look more varied then it is in reality.

                                                                                                                "},{"location":"styling/workshop/ysld/raster/#color-map","title":"Color Map","text":"

                                                                                                                The approach of mapping a data channel directly to a color channel is only suitable to quickly look at quantitative data.

                                                                                                                For qualitative data (such as land use) or simply to use color, we need a different approach:

                                                                                                                Note

                                                                                                                We can use a color map to artificially color a single band raster introducing smooth graduations for elevation or temperature models or clear differentiation for qualitative data.

                                                                                                                1. Apply the following YAML to our usgs:DEM layer:

                                                                                                                  symbolizers:\n- raster:\n    opacity: 1.0\n    color-map:\n      type: ramp\n      entries:\n      - ['#9080DB', 1.0, 0, null]\n      - ['#008000', 1.0, 1, null]\n      - ['#105020', 1.0, 255, null]\n      - ['#FFFFFF', 1.0, 4000, null]\n
                                                                                                                2. Resulting in this artificial color image:

                                                                                                                3. An opacity value can also be used with each color-map entry.

                                                                                                                  symbolizers:\n- raster:\n    opacity: 1.0\n    color-map:\n      type: ramp\n      entries:\n      - ['#9080DB', 0.0, 0, null]\n      - ['#008000', 1.0, 1, null]\n      - ['#105020', 1.0, 255, null]\n      - ['#FFFFFF', 1.0, 4000, null]\n
                                                                                                                4. Allowing the areas of zero height to be transparent:

                                                                                                                Note

                                                                                                                Raster format for GIS work often supply a \"no data\" value, or contain a mask, limiting the dataset to only the locations with valid information.

                                                                                                                "},{"location":"styling/workshop/ysld/raster/#custom","title":"Custom","text":"

                                                                                                                We can use what we have learned about color maps to apply a color brewer palette to our data.

                                                                                                                This exploration focuses on accurately communicating differences in value, rather than strictly making a pretty picture. Care should be taken to consider the target audience and medium used during palette selection.

                                                                                                                1. Restore the raster_example YSLD style to the following:

                                                                                                                  symbolizers:\n- raster:\n    opacity: 1.0\n
                                                                                                                2. Producing the following map preview.

                                                                                                                3. To start with we can provide our own grayscale using two color map entries.

                                                                                                                  symbolizers:\n- raster:\n    opacity: 1.0\n    color-map:\n      type: ramp\n      entries:\n      - ['#000000', 1.0, 0, null]\n      - ['#FFFFFF', 1.0, 4000, null]\n
                                                                                                                4. Use the Layer Preview tab to zoom in and take a look.

                                                                                                                  This is much more direct representation of the source data. We have used our knowledge of elevations to construct a more accurate style.

                                                                                                                5. While our straightforward style is easy to understand, it does leave a bit to be desired with respect to clarity.

                                                                                                                  The eye has a hard time telling apart dark shades of black (or bright shades of white) and will struggle to make sense of this image. To address this limitation we are going to switch to the ColorBrewer 9-class PuBuGn palette. This is a sequential palette that has been hand tuned to communicate a steady change of values.

                                                                                                                6. Update your style with the following:

                                                                                                                  symbolizers:\n- raster:\n    opacity: 1.0\n    color-map:\n      type: ramp\n      entries:\n      - ['#014636', 1.0, 0, null]\n      - ['#016C59', 1.0, 500, null]\n      - ['#02818A', 1.0, 1000, null]\n      - ['#3690C0', 1.0, 1500, null]\n      - ['#67A9CF', 1.0, 2000, null]\n      - ['#A6BDDB', 1.0, 2500, null]\n      - ['#D0D1E6', 1.0, 3000, null]\n      - ['#ECE2F0', 1.0, 3500, null]\n      - ['#FFF7FB', 1.0, 4000, null]\n

                                                                                                                7. A little bit of work with alpha (to mark the ocean as a no-data section):

                                                                                                                  symbolizers:\n- raster:\n    opacity: 1.0\n    color-map:\n      type: ramp\n      entries:\n      - ['#014636', 0, 0, null]\n      - ['#014636', 1.0, 1, null]\n      - ['#016C59', 1.0, 500, null]\n      - ['#02818A', 1.0, 1000, null]\n      - ['#3690C0', 1.0, 1500, null]\n      - ['#67A9CF', 1.0, 2000, null]\n      - ['#A6BDDB', 1.0, 2500, null]\n      - ['#D0D1E6', 1.0, 3000, null]\n      - ['#ECE2F0', 1.0, 3500, null]\n      - ['#FFF7FB', 1.0, 4000, null]\n
                                                                                                                8. And we are done:

                                                                                                                "},{"location":"styling/workshop/ysld/raster/#bonus","title":"Bonus","text":""},{"location":"styling/workshop/ysld/raster/#ysld.raster.q1","title":"Explore Contrast Enhancement","text":"
                                                                                                                1. A special effect that is effective with grayscale information is automatic contrast adjustment.
                                                                                                                2. Make use of a simple contrast enhancement with usgs:dem:
                                                                                                                symbolizers:\n- raster:\n    opacity: 1.0\n    contrast-enhancement:\n      mode: normalize\n
                                                                                                                1. Can you explain what happens when zoom in to only show a land area (as indicated with the bounding box below)?

                                                                                                                  Note

                                                                                                                  Discussion provided <ysld.raster.a1> at the end of the workbook.

                                                                                                                "},{"location":"styling/workshop/ysld/raster/#ysld.raster.q2","title":"Challenge Intervals","text":"
                                                                                                                1. The color-map type property dictates how the values are used to generate a resulting color.

                                                                                                                  • ramp is used for quantitative data, providing a smooth interpolation between the provided color values.
                                                                                                                  • intervals provides categorization for quantitative data, assigning each range of values a solid color.
                                                                                                                  • values is used for qualitative data, each value is required to have a color-map entry or it will not be displayed.
                                                                                                                2. Challenge: Update your DEM example to use intervals for presentation. What are the advantages of using this approach for elevation data?

                                                                                                                  Note

                                                                                                                  Answer provided <ysld.raster.a2> at the end of the workbook.

                                                                                                                "},{"location":"styling/workshop/ysld/raster/#explore-image-processing","title":"Explore Image Processing","text":"

                                                                                                                Additional properties are available to provide slight image processing during visualization.

                                                                                                                Note

                                                                                                                In this section are we going to be working around a preview issue where only the top left corner of the raster remains visible during image processing. This issue has been reported as GEOS-6213.

                                                                                                                Image processing can be used to enhance the output to highlight small details or to balance images from different sensors allowing them to be compared.

                                                                                                                1. The contrast-enhancement property is used to turn on a range of post processing effects. Settings are provided for normalize or histogram or none;
                                                                                                                symbolizers:\n- raster:\n    opacity: 1.0\n    contrast-enhancement:\n      mode: normalize\n
                                                                                                                1. Producing the following image:

                                                                                                                2. The raster-gamma property is used adjust the brightness of contrast-enhancement output. Values less than 1 are used to brighten the image while values greater than 1 darken the image.

                                                                                                                symbolizers:\n- raster:\n    opacity: 1.0\n    contrast-enhancement:\n      gamma: 1.5\n
                                                                                                                1. Providing the following effect:

                                                                                                                "},{"location":"styling/workshop/ysld/raster/#ysld.raster.q3","title":"Challenge Clear Digital Elevation Model Presentation","text":"
                                                                                                                1. Now that you have seen the data on screen and have a better understanding how would you modify our initial gray-scale example?

                                                                                                                2. Challenge: Use what you have learned to present the usgs:dem clearly.

                                                                                                                  Note

                                                                                                                  Answer provided <ysld.raster.a3> at the end of the workbook.

                                                                                                                "},{"location":"styling/workshop/ysld/raster/#ysld.raster.q4","title":"Challenge Raster Opacity","text":"
                                                                                                                1. There is a quick way to make raster data transparent, raster opacity property works in the same fashion as with vector data. The raster as a whole will be drawn partially transparent allow content from other layers to provide context.

                                                                                                                2. Challenge: Can you think of an example where this would be useful?

                                                                                                                  Note

                                                                                                                  Discussion provided <ysld.raster.a4> at the end of the workbook.

                                                                                                                "},{"location":"styling/workshop/ysld/ysld/","title":"YSLD Quickstart","text":"

                                                                                                                In the last section, we saw how the OGC defines style using XML documents (called SLD files).

                                                                                                                We will now explore GeoServer styling in greater detail using a tool to generate our SLD files. The YSLD GeoServer extension is used to generate SLD files using a clearer, more concise language based on YAML. Unlike CSS, the YSLD styling language has a one-to-one correspondence to SLD, meaning that each line of YSLD translates directly to one or more lines of SLD. Additionally, A YSLD style can be converted to SLD and back without loss of information.

                                                                                                                Using the YSLD extension to define styles results in shorter examples that are easier to understand. At any point we will be able to review the generated SLD file.

                                                                                                                Reference:

                                                                                                                • YSLD Reference
                                                                                                                "},{"location":"styling/workshop/ysld/ysld/#syntax","title":"Syntax","text":"

                                                                                                                This section provides a quick introduction to YSLD syntax for mapping professionals who may not be familiar with YAML.

                                                                                                                "},{"location":"styling/workshop/ysld/ysld/#property-syntax","title":"Property Syntax","text":"

                                                                                                                Individual statements (or directives) in a YSLD styling document are designed as key-value, or property-value pairs of the following form:

                                                                                                                <property>: <value>\n

                                                                                                                The <property> is a string denoting the property name, while the <value> can be one of a number of different types depending on context.

                                                                                                                Integer Numerical value. May be surrounded by quotes. Float Numerical value. May be surrounded by quotes. Text Text value. If value is ambiguous, use single quotes. Color Hexadecimal color of the form '#RRGGBB'. Tuple A list of values in brackets. e.g. [[0, 1]]{.title-ref} Expression CQL expression surrounded by \\${ }"},{"location":"styling/workshop/ysld/ysld/#mappings-and-lists","title":"Mappings and lists","text":"

                                                                                                                There are three types of objects in a YSLD document:

                                                                                                                1. Scalar, a simple value

                                                                                                                2. Mapping, a collection of key-value (property-value) pairs

                                                                                                                3. List, any collection of objects. A list can contain mappings, scalars, and even other lists.

                                                                                                                  Lists require dashes for every entry, while mappings do not.

                                                                                                                For example, a symbolizer block is a list, so every entry requires its own dash:

                                                                                                                • symbolizer:

                                                                                                                  • polygon:

                                                                                                                    ...

                                                                                                                  • text:

                                                                                                                    ...

                                                                                                                The polygon: and text: objects (the individual symbolizers themselves) are mappings, and as such, the contents do not require dashes, only indents:

                                                                                                                - polygon:\n    stroke-color: '#808080'\n    fill-color: '#FF0000'\n

                                                                                                                The dash next to polygon means that the item itself is contained in a list, not that it contains a list. And the placement of the dash is at the same level of indentation as the list title.

                                                                                                                If you have a list that contains only one item, and there is no other content at higher levels of the list, you may omit the enclosing elements. For example, the following are equivalent:

                                                                                                                feature-styles:\n- rules:\n  - symbolizers:\n    - point:\n        symbols:\n        - mark:\n            shape: circle\n            fill-color: 'gray'\n
                                                                                                                point:\n  symbols:\n  - mark:\n      shape: circle\n      fill-color: 'gray'\n

                                                                                                                This is useful for making your styles more concise.

                                                                                                                "},{"location":"styling/workshop/ysld/ysld/#indentation","title":"Indentation","text":"

                                                                                                                Indentation is very important in YSLD. All directives must be indented to its proper place to ensure proper hierarchy. Improper indentation will cause a style to be rendered incorrectly, or not at all.

                                                                                                                For example, the polygon symbolizer, since it is a mapping, contains certain parameters inside it, such as the color of the fill and stroke. These must be indented such that they are \"inside\" the polygon block.

                                                                                                                In this example, the following markup is correct:

                                                                                                                - polygon:\n    fill-color: '#808080'\n    fill-opacity: 0.5\n    stroke-color: black\n    stroke-opacity: 0.75\n

                                                                                                                The parameters inside the polygon (symbolizer) are indented, meaning that they are referencing the symbolizer and are not \"outside it.\"

                                                                                                                Compare to the following incorrect markup:

                                                                                                                - polygon:\n  fill-color: '#808080'\n  fill-opacity: 0.5\n  stroke-color: black\n  stroke-opacity: 0.75\n
                                                                                                                "},{"location":"styling/workshop/ysld/ysld/#rules","title":"Rules","text":"

                                                                                                                We have already seen a CSS style composed of a single rule:

                                                                                                                point:\n  symbols:\n  - mark:\n      shape: circle\n      fill-color: 'gray'\n

                                                                                                                We can make a style consisting of more than one rule, carefully choosing the selector for each rule. In this case we are using a selector to style capital cities with a star, and non-capital with a circle:

                                                                                                                rules:\n  - filter: ${FEATURECLA = 'Admin-0 capital'}\n    scale: [min, max]\n    symbolizers:\n    - point:\n        size: 6\n        symbols:\n        - mark:\n            shape: star\n            stroke-color: 'black'\n            stroke-width: 1\n            fill-color: 'gray'\n  - filter: ${FEATURECLA <> 'Admin-0 capital'}\n    scale: [min, max]\n    symbolizers:\n    - point:\n        size: 6\n        symbols:\n        - mark:\n            shape: circle\n            stroke-color: 'black'\n            stroke-width: 1\n            fill-color: 'gray'\n

                                                                                                                The feature attribute test performed above uses Constraint Query Language (CQL). This syntax can be used to define filters to select content, similar to how the SQL WHERE statement is used. It can also be used to define expressions to access attribute values allowing their use when defining style properties.

                                                                                                                Rule selectors can also be triggered based on the state of the rendering engine. In this example we are only applying labels when zoomed in:

                                                                                                                rules:\n  - scale: [min, '2.0E7']\n    symbolizers:\n    - text:\n        label: ${NAME}\n        fill-color: 'gray'\n

                                                                                                                In the above example the label is defined using the CQL Expression NAME. This results in a dynamic style that generates each label on a case-by-case basis, filling in the label with the feature attribute NAME.

                                                                                                                Reference:

                                                                                                                • Filter Syntax (YSLD Reference)
                                                                                                                • ECQL Reference (User Guide)
                                                                                                                "},{"location":"styling/workshop/ysld/ysld/#variables","title":"Variables","text":"

                                                                                                                Up to this point we have been styling individual features, documenting how each shape is represented.

                                                                                                                When styling multiple features, or using filters to style individual features in different years, you may need to repeat styling information.

                                                                                                                Variables in YSLD allow for a certain directive or block of directives to be defined by name and later reused. This can greatly simplify the styling document.

                                                                                                                The two most-common use cases for using variables are:

                                                                                                                • To create a more-friendly name for a value (such as using myorange instead of #EE8000)
                                                                                                                • To define a block of directives to remove redundant content and to decrease file length

                                                                                                                It is customary, but not required, to place all definitions at the very top of the YSLD file.

                                                                                                                The syntax for defining a variable as a single value is:

                                                                                                                define: &variable <value>\n

                                                                                                                The defined variable can then be used as a value by variable name with a *:

                                                                                                                <directive>: *variable\n

                                                                                                                The syntax for defining a variable as a content block is:

                                                                                                                define: &varblock\n  <directive>: <value>\n  <directive>: <value>\n  ...\n  <block>:\n  - <directive>: <value>\n    <directive>: <value>\n  ...\n

                                                                                                                The syntax for using a variable block is to prepend the variable name with <<: *. For example:

                                                                                                                <block>:\n- <directive>: <value>\n  <<: *varblock\n
                                                                                                                • Variables (YSLD Reference)
                                                                                                                "},{"location":"styling/workshop/ysld/ysld/#compare-ysld-to-sld","title":"Compare YSLD to SLD","text":"

                                                                                                                As noted above, YSLD has a one-to-one correspondence with SLD, it merely uses a different markup language to display the same content. We can compare a SLD style with a YSLD style to see this correspondence:

                                                                                                                "},{"location":"styling/workshop/ysld/ysld/#sld-style","title":"SLD Style","text":"

                                                                                                                Here is an example SLD file for reference:

                                                                                                                <?xml version=\"1.0\" encoding=\"ISO-8859-1\"?>\n<StyledLayerDescriptor version=\"1.0.0\"\n xsi:schemaLocation=\"http://www.opengis.net/sld StyledLayerDescriptor.xsd\"\n xmlns=\"http://www.opengis.net/sld\"\n xmlns:ogc=\"http://www.opengis.net/ogc\"\n xmlns:xlink=\"http://www.w3.org/1999/xlink\"\n xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\">\n  <NamedLayer>\n    <Name>airports</Name>\n    <UserStyle>\n      <Title>Airports</Title>\n      <FeatureTypeStyle>\n        <Rule>\n          <Name>airports</Name>\n          <Title>Airports</Title>\n          <PointSymbolizer>\n            <Graphic>\n              <ExternalGraphic>\n                <OnlineResource xlink:type=\"simple\"\n                xlink:href=\"airport.svg\" />\n                <Format>image/svg</Format>\n              </ExternalGraphic>\n              <Size>16</Size>\n            </Graphic>\n          </PointSymbolizer>\n        </Rule>\n      </FeatureTypeStyle>\n    </UserStyle>\n  </NamedLayer>\n</StyledLayerDescriptor>\n
                                                                                                                "},{"location":"styling/workshop/ysld/ysld/#ysld-style","title":"YSLD Style","text":"

                                                                                                                Here is the same example as YSLD:

                                                                                                                name: airports\ntitle: Airports\nscale: [min, max]\nsymbolizers:\n- point:\n    size: 16\n    symbols:\n    - external:\n        url: airport.svg\n        format: image/svg\n

                                                                                                                We use a point symbolizer to indicate we want this content drawn as a Point (line 16 in the SLD, line 5 in the YSLD). The point symbolizer declares an external graphic, which contains the URL airports.svg indicating the image that should be drawn (line 20 in the SLD, line 9 in the YSLD).

                                                                                                                "},{"location":"styling/workshop/ysld/ysld/#tour","title":"Tour","text":"

                                                                                                                To confirm everything works, let's reproduce the airports style above.

                                                                                                                1. Navigate to the Styles page.

                                                                                                                2. Each time we edit a style, the contents of the associated SLD file are replaced. Rather than disrupt any of our existing styles we will create a new style. Click Add a new style and choose the following:

                                                                                                                    • Name:
                                                                                                                    • airports0
                                                                                                                    • Workspace:
                                                                                                                    • (leave empty)
                                                                                                                    • Format:
                                                                                                                    • YSLD
                                                                                                                3. Replace the initial YSLD definition with our airport YSLD example and click Apply:

                                                                                                                  {% \n  include \"../files/airports0.ysld\"\n%}\n
                                                                                                                4. Click the Layer Preview tab to preview the style. We want to preview on the airports layer, so click the name of the current layer and select ne:airports from the list that appears. You can use the mouse buttons to pan and scroll wheel to change scale.

                                                                                                                  Choosing the airports layer

                                                                                                                  Layer preview

                                                                                                                5. Click Layer Data for a summary of the selected data.

                                                                                                                  Layer attributes

                                                                                                                "},{"location":"styling/workshop/ysld/ysld/#bonus","title":"Bonus","text":"

                                                                                                                Finished early? For now please help your neighbour so we can proceed with the workshop.

                                                                                                                If you are really stuck please consider the following challenge rather than skipping ahead.

                                                                                                                "},{"location":"styling/workshop/ysld/ysld/#explore-data","title":"Explore Data","text":"
                                                                                                                1. Return to the Data tab and use the Compute link to determine the minimum and maximum for the scalerank attribute.

                                                                                                                  Instructor Notes

                                                                                                                  Should be 2 and 9 respectively.

                                                                                                                "},{"location":"styling/workshop/ysld/ysld/#challenge-compare-sld-generation","title":"Challenge Compare SLD Generation","text":"

                                                                                                                # The rest API can be used to review your YAML file directly.

                                                                                                                Browser:

                                                                                                                • Command line:

                                                                                                                  curl -v -u admin:geoserver -XGET http://localhost:8080/geoserver/rest/styles/airports0.yaml\n
                                                                                                                  1. The REST API can also be used generate an SLD file:

                                                                                                                    Browser:

                                                                                                                    • Command line:

                                                                                                                      curl -v -u admin:geoserver -XGET http://localhost:8080/geoserver/rest/styles/airports0.sld?pretty=true\n
                                                                                                                      1. Compare the generated SLD differ above with the handwritten SLD file used as an example?

                                                                                                                        Challenge: What differences can you spot?

                                                                                                                        Instructor Notes

                                                                                                                        Generated SLD does not include name or title information; this can of course be added. Please check the YSLD reference for details.

                                                                                                                        The second difference is with the use of a fallback Mark when defining a PointSymbolizer.

                                                                                                                      "},{"location":"styling/ysld/","title":"YSLD Styling","text":"

                                                                                                                      This module adds support for the YSLD styling language.

                                                                                                                      YSLD is a YAML based language which closely matches the structure of SLD, and the internal data model that GeoServer's renderer uses. For details on YSLD syntax see the reference below or the GeoTools documentation.

                                                                                                                      YSLD is not a part of GeoServer by default, but is available as an optional install.

                                                                                                                      • Installing the GeoServer YSLD extension
                                                                                                                      • GeoServer Specific Extensions
                                                                                                                      • YSLD reference
                                                                                                                      • YSLD Cookbook
                                                                                                                      "},{"location":"styling/ysld/gs-extensions/","title":"GeoServer Specific Extensions","text":""},{"location":"styling/ysld/gs-extensions/#geowebcache-integration","title":"GeoWebCache Integration","text":"

                                                                                                                      When defining rules in terms of zoom levels, you can use the zoom level from a gridset defined in the integrated GeoWebCache instance.

                                                                                                                      For instance, if your GWC had a gridset named CanadaLCCQuad and you wanted a style rule to apply to levels 0-2 of that gridset you could use the following:

                                                                                                                      grid:\n  name: CanadaLCCQuad\nrules:\n- zoom: [0,2]\n  point:\n    ...\n
                                                                                                                      "},{"location":"styling/ysld/installing/","title":"Installing the GeoServer YSLD extension","text":"

                                                                                                                      The YSLD extension is listed on the GeoServer download page.

                                                                                                                      To install:

                                                                                                                      1. Download the ysld

                                                                                                                        Verify that the version number in the filename corresponds to the version of GeoServer you are running (for example 2.24.2 above).

                                                                                                                      2. Extract the contents of the archive into the WEB-INF/lib directory in GeoServer. Make sure you do not create any sub-directories during the extraction process.

                                                                                                                      3. Restart GeoServer.

                                                                                                                      4. To confirm successful installation, check for a new YSLD entry in the Styles editor.

                                                                                                                      "},{"location":"styling/ysld/cookbook/","title":"YSLD Cookbook","text":"

                                                                                                                      The YSLD Cookbook is a collection of YSLD \"recipes\" for creating various types of map styles. Wherever possible, each example is designed to show off a single YSLD feature so that code can be copied from the examples and adapted when creating YSLDs of your own. While not an exhaustive reference like the YSLD reference the YSLD cookbook is designed to be a practical reference, showing common style templates that are easy to understand.

                                                                                                                      The YSLD Cookbook is divided into four sections: the first three for each of the vector types (points, lines, and polygons) and the fourth section for rasters. Each example in every section contains a screenshot showing actual GeoServer WMS output, a snippet of the YSLD code for reference, and a link to download the full YSLD.

                                                                                                                      Each section uses data created especially for the YSLD Cookbook, with shapefiles for vector data and GeoTIFFs for raster data. The projection for data is EPSG:4326.

                                                                                                                      Data Type Shapefile Point ysld_cookbook_point.zip Line ysld_cookbook_line.zip Polygon ysld_cookbook_polygon.zip Raster ysld_cookbook_raster.zip
                                                                                                                      • Points
                                                                                                                      • Lines
                                                                                                                      • Polygons
                                                                                                                      • Rasters
                                                                                                                      "},{"location":"styling/ysld/cookbook/lines/","title":"Lines","text":"

                                                                                                                      While lines can also seem to be simple shapes, having length but no width, there are many options and tricks for making lines display nicely.

                                                                                                                      "},{"location":"styling/ysld/cookbook/lines/#ysld_cookbook_lines_attributes","title":"Example lines layer","text":"

                                                                                                                      The lines layer used in the examples below contains road information for a fictional country. For reference, the attribute table for the points in this layer is included below.

                                                                                                                      fid (Feature ID) name (Road name) type (Road class) line.1 Latway highway line.2 Crescent Avenue secondary line.3 Forest Avenue secondary line.4 Longway highway line.5 Saxer Avenue secondary line.6 Ridge Avenue secondary line.7 Holly Lane local-road line.8 Mulberry Street local-road line.9 Nathan Lane local-road line.10 Central Street local-road line.11 Lois Lane local-road line.12 Rocky Road local-road line.13 Fleet Street local-road line.14 Diane Court local-road line.15 Cedar Trail local-road line.16 Victory Road local-road line.17 Highland Road local-road line.18 Easy Street local-road line.19 Hill Street local-road line.20 Country Road local-road line.21 Main Street local-road line.22 Jani Lane local-road line.23 Shinbone Alley local-road line.24 State Street local-road line.25 River Road local-road

                                                                                                                      Download the lines shapefile

                                                                                                                      "},{"location":"styling/ysld/cookbook/lines/#ysld_cookbook_lines_simpleline","title":"Simple line","text":"

                                                                                                                      This example specifies lines be colored black with a thickness of 3 pixels.

                                                                                                                      Simple line

                                                                                                                      "},{"location":"styling/ysld/cookbook/lines/#code","title":"Code","text":"

                                                                                                                      Download the \"Simple line\" YSLD

                                                                                                                      title: 'YSLD Cook Book: Simple Line'\nfeature-styles:\n- name: name\n  rules:\n  - symbolizers:\n    - line:\n        stroke-color: '#000000'\n        stroke-width: 3\n
                                                                                                                      "},{"location":"styling/ysld/cookbook/lines/#details","title":"Details","text":"

                                                                                                                      There is one rule in one feature style for this YSLD, which is the simplest possible situation. (All subsequent examples will contain one rule and one feature style unless otherwise specified.) Styling lines is accomplished via the line symbolizer (lines 5-8). Line 7 specifies the color of the line to be black ('#000000'), while line 8 specifies the width of the lines to be 3 pixels.

                                                                                                                      "},{"location":"styling/ysld/cookbook/lines/#line-with-border","title":"Line with border","text":"

                                                                                                                      This example shows how to draw lines with borders (sometimes called \"cased lines\"). In this case the lines are drawn with a 3 pixel blue center and a 1 pixel wide gray border.

                                                                                                                      Line with border

                                                                                                                      "},{"location":"styling/ysld/cookbook/lines/#code_1","title":"Code","text":"

                                                                                                                      Download the \"Line with border\" YSLD

                                                                                                                      title: 'YSLD Cook Book: Line with border'\nfeature-styles:\n- name: name\n  rules:\n  - symbolizers:\n    - line:\n        stroke-color: '#333333'\n        stroke-width: 5\n        stroke-linecap: round\n- name: name\n  rules:\n  - symbolizers:\n    - line:\n        stroke-color: '#6699FF'\n        stroke-width: 3\n        stroke-linecap: round\n
                                                                                                                      "},{"location":"styling/ysld/cookbook/lines/#details_1","title":"Details","text":"

                                                                                                                      Lines in YSLD have no notion of a \"fill\", only \"stroke\". Thus, unlike points or polygons, it is not possible to style the \"edge\" of the line geometry. It is, however, possible to achieve this effect by drawing each line twice: once with a certain width and again with a slightly smaller width. This gives the illusion of fill and stroke by obscuring the larger lines everywhere except along the edges of the smaller lines.

                                                                                                                      Since every line is drawn twice, the order of the rendering is very important. GeoServer renders feature-styles in the order that they are presented in the YSLD. In this style, the gray border lines are drawn first via the first feature style, followed by the blue center lines in a second feature style. This ensures that the blue lines are not obscured by the gray lines, and also ensures proper rendering at intersections, so that the blue lines \"connect\".

                                                                                                                      In this example, lines 3-9 comprise the first feature style, which is the outer line (or \"stroke\"). Line 7 specifies the color of the line to be dark gray ('#333333'), line 8 specifies the width of this line to be 5 pixels, and in line 9 a stroke-linecap parameter of round renders the ends of the line as rounded instead of flat. (When working with bordered lines using a round line cap ensures that the border connects properly at the ends of the lines.)

                                                                                                                      Lines 10-16 comprise the second feature-style, which is the inner line (or \"fill\"). Line 14 specifies the color of the line to be a medium blue ('#6699FF'), line 15 specifies the width of this line to be 3 pixels, and line 16 again renders the edges of the line to be rounded instead of flat.

                                                                                                                      The result is a 3 pixel blue line with a 1 pixel gray border, since the 5 pixel gray line will display 1 pixel on each side of the 3 pixel blue line.

                                                                                                                      "},{"location":"styling/ysld/cookbook/lines/#dashed-line","title":"Dashed line","text":"

                                                                                                                      This example alters the Simple line to create a dashed line consisting of 5 pixels of drawn line alternating with 2 pixels of blank space.

                                                                                                                      Dashed line

                                                                                                                      "},{"location":"styling/ysld/cookbook/lines/#code_2","title":"Code","text":"

                                                                                                                      Download the \"Dashed line\" YSLD

                                                                                                                      title: 'YSLD Cook Book: Dashed line'\nfeature-styles:\n- name: name\n  rules:\n  - symbolizers:\n    - line:\n        stroke-color: '#0000FF'\n        stroke-width: 3\n        stroke-dasharray: 5 2\n
                                                                                                                      "},{"location":"styling/ysld/cookbook/lines/#details_2","title":"Details","text":"

                                                                                                                      In this example, line 8 sets the color of the lines to be blue ('#0000FF') and line 8 sets the width of the lines to be 3 pixels. Line 9 determines the composition of the line dashes. The value of 5 2 creates a repeating pattern of 5 pixels of drawn line, followed by 2 pixels of omitted line.

                                                                                                                      "},{"location":"styling/ysld/cookbook/lines/#offset-line","title":"Offset line","text":"

                                                                                                                      This example alters the Simple line to add a perpendicular offset line on the left side of the line, at five pixels distance.

                                                                                                                      Dashed line

                                                                                                                      "},{"location":"styling/ysld/cookbook/lines/#code_3","title":"Code","text":"

                                                                                                                      Download the \"Offset line\" YSLD

                                                                                                                      title: 'YSLD Cook Book: Dashed line'\nfeature-styles:\n- name: name\n  rules:\n  - symbolizers:\n    - line:\n        stroke-color: '#000000'\n        stroke-width: 2\n    - line:\n        stroke-color: '#0000FF'\n        stroke-width: 3\n        stroke-dasharray: 5 2\n        offset: 3\n
                                                                                                                      "},{"location":"styling/ysld/cookbook/lines/#details_3","title":"Details","text":"

                                                                                                                      In this example, lines 6-8 draw a simple black line like in the Simple line example. Lines 9-12 draw a blue dashed line like in the above Dashed line example. Line 13 modifies the dashed line with a 3 pixel offset from the line geometry.

                                                                                                                      "},{"location":"styling/ysld/cookbook/lines/#railroad-hatching","title":"Railroad (hatching)","text":"

                                                                                                                      This example uses hatching to create a railroad style. Both the line and the hatches are black, with a 2 pixel thickness for the main line and a 1 pixel width for the perpendicular hatches.

                                                                                                                      Railroad (hatching)

                                                                                                                      "},{"location":"styling/ysld/cookbook/lines/#code_4","title":"Code","text":"

                                                                                                                      Download the \"Railroad (hatching)\" YSLD

                                                                                                                      title: 'YSLD Cook Book: Railroad (hatching)'\nfeature-styles:\n- name: name\n  rules:\n  - symbolizers:\n    - line:\n        stroke-color: '#333333'\n        stroke-width: 3\n    - line:\n        stroke-color: '#333333'\n        stroke-width: 1\n        stroke-graphic:\n          size: 12\n          symbols:\n          - mark:\n              shape: shape://vertline\n              stroke-color: '#333333'\n              stroke-width: 1\n
                                                                                                                      "},{"location":"styling/ysld/cookbook/lines/#details_4","title":"Details","text":"

                                                                                                                      In this example there are two line symbolizers. The first symbolizer, on lines 6-8, draws a standard line, with line 7 drawing the lines as dark gray ('#333333') and line 8 setting the width of the lines to be 2 pixels.

                                                                                                                      The hatching is invoked in the second symbolizer, on lines 9-18. Line 16 specifies that the symbolizer draw a vertical line hatch (shape://vertline) perpendicular to the line geometry. Lines 17-18 set the hatch color to dark gray ('#333333') and width to 1 pixel. Finally, line 13 specifies both the length of the hatch and the distance between each hatch to both be 12 pixels.

                                                                                                                      "},{"location":"styling/ysld/cookbook/lines/#spaced-graphic-symbols","title":"Spaced graphic symbols","text":"

                                                                                                                      This example uses a graphic stroke along with dash arrays to create a \"dot and space\" line type. Adding the dash array specification allows to control the amount of space between one symbol and the next one. Without using the dash array the lines would be densely populated with dots, each one touching the previous one.

                                                                                                                      Spaced symbols along a line

                                                                                                                      "},{"location":"styling/ysld/cookbook/lines/#code_5","title":"Code","text":"

                                                                                                                      Download the \"Spaced symbols\" YSLD

                                                                                                                      name: Default Styler\ntitle: 'YSLD Cook Book: Dash/Space line'\nfeature-styles:\n- name: name\n  rules:\n  - symbolizers:\n    - line:\n        stroke-color: '#333333'\n        stroke-width: 1\n        stroke-dasharray: 4 6\n        stroke-graphic:\n          size: 4\n          symbols:\n          - mark:\n              shape: circle\n              stroke-color: '#333333'\n              stroke-width: 1\n              fill-color: '#666666'\n
                                                                                                                      "},{"location":"styling/ysld/cookbook/lines/#details_5","title":"Details","text":"

                                                                                                                      This example, like others before, uses a stroke-graphic to place a graphic symbol along a line. The symbol, defined on lines 14-18 is a 4 pixel gray circle with a dark gray outline. The spacing between symbols is controlled with the stroke-dasharray at line 9, which specifies 4 pixels of pen-down (just enough to draw the circle) and 6 pixels of pen-up, to provide the spacing.

                                                                                                                      "},{"location":"styling/ysld/cookbook/lines/#ysld_cookbook_lines_defaultlabel","title":"Alternating symbols with dash offsets","text":"

                                                                                                                      This example shows how to create a complex line style which alternates a dashed line and a graphic symbol. The code builds on features shown in the previous examples:

                                                                                                                      • stroke-dasharray controls pen-down/pen-up behavior to generate dashed lines
                                                                                                                      • stroke-graphic places symbols along a line
                                                                                                                      • combining the two allows control of symbol spacing

                                                                                                                      This also shows the usage of a dash offset, which controls where rendering starts in the dash array. For example, with a dash array of 5 10 and a dash offset of 7 the renderer starts drawing the pattern 7 pixels from the beginning. It skips the 5 pixels pen-down section and 2 pixels of the pen-up section, then draws the remaining 8 pixels of pen-up, then 5 down, 10 up, and so on.

                                                                                                                      The example shows how to use these features to create two synchronized sequences of dash arrays, one drawing line segments and the other symbols.

                                                                                                                      Alternating dash and symbol

                                                                                                                      "},{"location":"styling/ysld/cookbook/lines/#code_6","title":"Code","text":"

                                                                                                                      Download the \"Spaced symbols\" YSLD

                                                                                                                      title: 'YSLD Cook Book: Dash/Symbol line'\nfeature-styles:\n- name: name\n  rules:\n  - symbolizers:\n    - line:\n        stroke-color: '#0000FF'\n        stroke-width: 1\n        stroke-dasharray: 10 10\n    - line:\n        stroke-color: '#000033'\n        stroke-width: 1\n        stroke-dasharray: 5 15\n        stroke-dashoffset: 7.5\n        stroke-graphic:\n          size: 5\n          symbols:\n          - mark:\n              shape: circle\n              stroke-color: '#000033'\n              stroke-width: 1\n
                                                                                                                      "},{"location":"styling/ysld/cookbook/lines/#details_6","title":"Details","text":"

                                                                                                                      In this example two line symbolizers use stroke-dasharray and different symbology to produce a sequence of alternating dashes and symbols. The first symbolizer (lines 6-9) is a simple dashed line alternating 10 pixels of pen-down with 10 pixels of pen-up. The second symbolizer (lines 10-21) alternates a 5 pixel empty circle with 15 pixels of white space. The circle symbol is produced by a mark element, with its symbology specified by stroke parameters (lines 20-21). The spacing between symbols is controlled with the stroke-dasharray (line 13), which specifies 5 pixels of pen-down (just enough to draw the circle) and 15 pixels of pen-up. In order to have the two sequences positioned correctly the second one uses a stroke-dashoffset of 7.5 (line 14). This makes the sequence start with 12.5 pixels of white space, then a circle (which is then centered between the two line segments of the other pattern), then 15 pixels of white space, and so on.

                                                                                                                      "},{"location":"styling/ysld/cookbook/lines/#line-with-default-label","title":"Line with default label","text":"

                                                                                                                      This example shows a text label on the simple line. This is how a label will be displayed in the absence of any other customization.

                                                                                                                      Line with default label

                                                                                                                      "},{"location":"styling/ysld/cookbook/lines/#code_7","title":"Code","text":"

                                                                                                                      Download the \"Line with default label\" YSLD

                                                                                                                      name: Default Styler\ntitle: 'YSLD Cook Book: Line with default label'\nfeature-styles:\n- name: name\n  rules:\n  - symbolizers:\n    - line:\n        stroke-color: '#FF0000'\n        stroke-width: 1\n    - text:\n        label: ${name}\n        fill-color: '#000000'\n        font-family: Serif\n        font-size: 10\n        font-style: normal\n        font-weight: normal\n        placement: point\n
                                                                                                                      "},{"location":"styling/ysld/cookbook/lines/#details_7","title":"Details","text":"

                                                                                                                      In this example, there is one rule with a line symbolizer and a text symbolizer. The line symbolizer (lines 6-8) draws red lines ('#FF0000'). The text symbolizer (lines 10-17) determines the labeling of the lines. Line 10 specifies that the text of the label will be determined by the value of the \"name\" attribute for each line. (Refer to the attribute table in the Example lines layer section if necessary.) Line 11 sets the text color to black. All other details about the label are set to the renderer default, which here is Times New Roman font, font color black, and font size of 10 pixels.

                                                                                                                      "},{"location":"styling/ysld/cookbook/lines/#ysld_cookbook_lines_labelfollowingline","title":"Label following line","text":"

                                                                                                                      This example renders the text label to follow the contour of the lines.

                                                                                                                      Label following line

                                                                                                                      "},{"location":"styling/ysld/cookbook/lines/#code_8","title":"Code","text":"

                                                                                                                      Download the \"Label following line\" YSLD

                                                                                                                      title: 'YSLD Cook Book: Label following line'\nfeature-styles:\n- name: name\n  rules:\n  - symbolizers:\n    - line:\n        stroke-color: '#FF0000'\n        stroke-width: 1\n    - text:\n        label: ${name}\n        fill-color: '#000000'\n        placement: line\n        offset: 0\n        x-followLine: true\n
                                                                                                                      "},{"location":"styling/ysld/cookbook/lines/#details_8","title":"Details","text":"

                                                                                                                      As the Alternating symbols with dash offsets example showed, the default label behavior isn't optimal. The label is displayed at a tangent to the line itself, leading to uncertainty as to which label corresponds to which line.

                                                                                                                      This example is similar to the Alternating symbols with dash offsets example with the exception of lines 12-14. Line 14 sets the option to have the label follow the line, while lines 12-13 specify that the label is placed along a line. If placement: line is not specified in an YSLD, then placement: point is assumed, which isn't compatible with line-specific rendering options.

                                                                                                                      Note

                                                                                                                      Not all labels are shown due to label conflict resolution. See the next section on Optimized label placement for an example of how to maximize label display.

                                                                                                                      "},{"location":"styling/ysld/cookbook/lines/#ysld_cookbook_lines_optimizedlabel","title":"Optimized label placement","text":"

                                                                                                                      This example optimizes label placement for lines such that the maximum number of labels are displayed.

                                                                                                                      Optimized label

                                                                                                                      "},{"location":"styling/ysld/cookbook/lines/#code_9","title":"Code","text":"

                                                                                                                      Download the \"Optimized label\" YSLD

                                                                                                                      title: 'YSLD Cook Book: Optimized label placement'\nfeature-styles:\n- name: name\n  rules:\n  - symbolizers:\n    - line:\n        stroke-color: '#FF0000'\n        stroke-width: 1\n    - text:\n        label: ${name}\n        fill-color: '#000000'\n        placement: line\n        offset: 0\n        x-followLine: true\n        x-maxAngleDelta: 90\n        x-maxDisplacement: 400\n        x-repeat: 150\n
                                                                                                                      "},{"location":"styling/ysld/cookbook/lines/#details_9","title":"Details","text":"

                                                                                                                      GeoServer uses \"conflict resolution\" to ensure that labels aren't drawn on top of other labels, obscuring them both. This accounts for the reason why many lines don't have labels in the previous example, Label following line. While this setting can be toggled, it is usually a good idea to leave it on and use other label placement options to ensure that labels are drawn as often as desired and in the correct places. This example does just that.

                                                                                                                      This example is similar to the previous example, Label following line. The only differences are contained in lines 15-17. Line 15 sets the maximum angle that the label will follow. This sets the label to never bend more than 90 degrees to prevent the label from becoming illegible due to a pronounced curve or angle. Line 16 sets the maximum displacement of the label to be 400 pixels. In order to resolve conflicts with overlapping labels, GeoServer will attempt to move the labels such that they are no longer overlapping. This value sets how far the label can be moved relative to its original placement. Finally, line 17 sets the labels to be repeated every 150 pixels. A feature will typically receive only one label, but this can cause confusion for long lines. Setting the label to repeat ensures that the line is always labeled locally.

                                                                                                                      "},{"location":"styling/ysld/cookbook/lines/#ysld_cookbook_lines_optimizedstyledlabel","title":"Optimized and styled label","text":"

                                                                                                                      This example improves the style of the labels from the Optimized label placement example.

                                                                                                                      Optimized and styled label

                                                                                                                      "},{"location":"styling/ysld/cookbook/lines/#code_10","title":"Code","text":"

                                                                                                                      Download the \"Optimized and styled label\" YSLD

                                                                                                                      title: 'YSLD Cook Book: Optimized and styled label'\nfeature-styles:\n- name: name\n  rules:\n  - symbolizers:\n    - line:\n        stroke-color: '#FF0000'\n        stroke-width: 1\n    - text:\n        label: ${name}\n        fill-color: '#000000'\n        font-family: Arial\n        font-size: 10\n        font-style: normal\n        font-weight: bold\n        placement: line\n        offset: 0\n        x-followLine: true\n        x-maxAngleDelta: 90\n        x-maxDisplacement: 400\n        x-repeat: 150\n
                                                                                                                      "},{"location":"styling/ysld/cookbook/lines/#details_10","title":"Details","text":"

                                                                                                                      This example is similar to the Optimized label placement. The only difference is in the font information, which is contained in lines 12-15. Line 12 sets the font family to be \"Arial\", line 13 sets the font size to 10, line 14 sets the font style to \"normal\" (as opposed to \"italic\" or \"oblique\"), and line 15 sets the font weight to \"bold\" (as opposed to \"normal\").

                                                                                                                      "},{"location":"styling/ysld/cookbook/lines/#attribute-based-line","title":"Attribute-based line","text":"

                                                                                                                      This example styles the lines differently based on the \"type\" (Road class) attribute.

                                                                                                                      Attribute-based line

                                                                                                                      "},{"location":"styling/ysld/cookbook/lines/#code_11","title":"Code","text":"

                                                                                                                      Download the \"Attribute-based line\" YSLD

                                                                                                                      title: 'YSLD Cook Book: Attribute-based line'\nfeature-styles:\n- name: name\n  rules:\n  - name: local-road\n    filter: ${type = 'local-road'}\n    symbolizers:\n    - line:\n        stroke-color: '#009933'\n        stroke-width: 2\n- name: name\n  rules:\n  - name: secondary\n    filter: ${type = 'secondary'}\n    symbolizers:\n    - line:\n        stroke-color: '#0055CC'\n        stroke-width: 3\n- name: name\n  rules:\n  - name: highway\n    filter: ${type = 'highway'}\n    symbolizers:\n    - line:\n        stroke-color: '#FF0000'\n        stroke-width: 6\n
                                                                                                                      "},{"location":"styling/ysld/cookbook/lines/#details_11","title":"Details","text":"

                                                                                                                      Note

                                                                                                                      Refer to the Example lines layer to see the attributes for the layer. This example has eschewed labels in order to simplify the style, but you can refer to the example Optimized and styled label to see which attributes correspond to which points.

                                                                                                                      There are three types of road classes in our fictional country, ranging from back roads to high-speed freeways: \"highway\", \"secondary\", and \"local-road\". In order to handle each case separately, there is more than one feature style, each containing a single rule. This ensures that each road type is rendered in order, as each feature style is drawn based on the order in which it appears in the YSLD.

                                                                                                                      The three rules are designed as follows:

                                                                                                                      Rule order Rule name / type Color Size 1 local-road #009933 (green) 2 2 secondary #0055CC (blue) 3 3 highway #FF0000 (red) 6

                                                                                                                      Lines 3-10 comprise the first rule. Line 6 sets the filter for this rule, such that the \"type\" attribute has a value of \"local-road\". If this condition is true for a particular line, the rule is rendered according to the line symbolizer which is on lines 8-10. Lines 9-10 set the color of the line to be a dark green ('#009933') and the width to be 2 pixels.

                                                                                                                      Lines 11-18 comprise the second rule. Line 14 sets the filter for this rule, such that the \"type\" attribute has a value of \"secondary\". If this condition is true for a particular line, the rule is rendered according to the line symbolizer which is on lines 16-18. Lines 17-18 set the color of the line to be a dark blue ('#0055CC') and the width to be 3 pixels, making the lines slightly thicker than the \"local-road\" lines and also a different color.

                                                                                                                      Lines 19-26 comprise the third and final rule. Line 22 sets the filter for this rule, such that the \"type\" attribute has a value of \"primary\". If this condition is true for a particular line, the rule is rendered according to the line symbolizer which is on lines 24-26. Lines 25-26 set the color of the line to be a bright red ('#FF0000') and the width to be 6 pixels, so that these lines are rendered on top of and thicker than the other two road classes. In this way, the \"primary\" roads are given priority in the map rendering.

                                                                                                                      "},{"location":"styling/ysld/cookbook/lines/#zoom-based-line","title":"Zoom-based line","text":"

                                                                                                                      This example alters the Simple line style at different zoom levels.

                                                                                                                      Zoom-based line: Zoomed in

                                                                                                                      Zoom-based line: Partially zoomed

                                                                                                                      Zoom-based line: Zoomed out

                                                                                                                      "},{"location":"styling/ysld/cookbook/lines/#code_12","title":"Code","text":"

                                                                                                                      Download the \"Zoom-based line\" YSLD

                                                                                                                      title: 'YSLD Cook Book: Zoom-based line'\nfeature-styles:\n- name: name\n  rules:\n  - name: Large\n    scale: [min,1.8e8]\n    symbolizers:\n    - line:\n        stroke-color: '#009933'\n        stroke-width: 6\n  - name: Medium\n    scale: [1.8e8,3.6e8]\n    symbolizers:\n    - line:\n        stroke-color: '#009933'\n        stroke-width: 4\n  - name: Small\n    scale: [3.6e8,max]\n    symbolizers:\n    - line:\n        stroke-color: '#009933'\n        stroke-width: 2\n
                                                                                                                      "},{"location":"styling/ysld/cookbook/lines/#details_12","title":"Details","text":"

                                                                                                                      It is often desirable to make shapes larger at higher zoom levels when creating a natural-looking map. This example varies the thickness of the lines according to the zoom level (or more accurately, scale denominator). Scale denominators refer to the scale of the map. A scale denominator of 10,000 means the map has a scale of 1:10,000 in the units of the map projection.

                                                                                                                      Note

                                                                                                                      Determining the appropriate scale denominators (zoom levels) to use is beyond the scope of this example.

                                                                                                                      This style contains three rules. The three rules are designed as follows:

                                                                                                                      Rule order Rule name Scale denominator Line width 1 Large 1:180,000,000 or less 6 2 Medium 1:180,000,000 to 1:360,000,000 4 3 Small Greater than 1:360,000,000 2

                                                                                                                      The order of these rules does not matter since the scales denominated in each rule do not overlap.

                                                                                                                      The first rule (lines 5-10) is the smallest scale denominator, corresponding to when the view is \"zoomed in\". The scale rule is set on line 6, so that the rule will apply to any map with a scale denominator of 180,000,000 or less. Lines 9-10 draw the line to be dark green ('#009933') with a width of 6 pixels.

                                                                                                                      The second rule (lines 11-16) is the intermediate scale denominator, corresponding to when the view is \"partially zoomed\". Lines 12 set the scale such that the rule will apply to any map with scale denominators between 180,000,000 and 360,000,000. (The lower bound is inclusive and the upper bound is exclusive, so a zoom level of exactly 360,000,000 would not apply here.) Aside from the scale, the only difference between this rule and the previous is the width of the lines, which is set to 4 pixels on line 16.

                                                                                                                      The third rule (lines 17-22) is the largest scale denominator, corresponding to when the map is \"zoomed out\". The scale rule is set on line 18, so that the rule will apply to any map with a scale denominator of 360,000,000 or greater. Again, the only other difference between this rule and the others is the width of the lines, which is set to 2 pixels on line 22.

                                                                                                                      The result of this style is that lines are drawn with larger widths as one zooms in and smaller widths as one zooms out.

                                                                                                                      "},{"location":"styling/ysld/cookbook/points/","title":"Points","text":"

                                                                                                                      While points are seemingly the simplest type of shape, possessing only position and no other dimensions, there are many different ways that a point can be styled in YSLD.

                                                                                                                      "},{"location":"styling/ysld/cookbook/points/#ysld_cookbook_points_attributes","title":"Example points layer","text":"

                                                                                                                      The points layer used for the examples below contains name and population information for the major cities of a fictional country. For reference, the attribute table for the points in this layer is included below.

                                                                                                                      fid (Feature ID) name (City name) pop (Population) point.1 Borfin 157860 point.2 Supox City 578231 point.3 Ruckis 98159 point.4 Thisland 34879 point.5 Synopolis 24567 point.6 San Glissando 76024 point.7 Detrania 205609

                                                                                                                      Download the points shapefile

                                                                                                                      "},{"location":"styling/ysld/cookbook/points/#ysld_cookbook_points_simplepoint","title":"Simple point","text":"

                                                                                                                      This example specifies points be styled as red circles with a diameter of 6 pixels.

                                                                                                                      Simple point

                                                                                                                      "},{"location":"styling/ysld/cookbook/points/#code","title":"Code","text":"

                                                                                                                      Download the \"Simple point\" YSLD

                                                                                                                      title: 'YSLD Cook Book: Simple Point'\nfeature-styles:\n- name: name\n  rules:\n  - symbolizers:\n    - point:\n        size: 6\n        symbols:\n        - mark:\n            shape: circle\n            fill-color: '#FF0000'\n
                                                                                                                      "},{"location":"styling/ysld/cookbook/points/#details","title":"Details","text":"

                                                                                                                      There is one rule in one feature style for this YSLD, which is the simplest possible situation. (All subsequent examples will contain one rule and one feature style unless otherwise specified.) Styling points is accomplished via the point symbolizer (lines 6-11). Line 10 specifies the shape of the symbol to be a circle, with line 11 determining the fill color to be red ('#FF0000'). Line 7 sets the size (diameter) of the graphic to be 6 pixels.

                                                                                                                      "},{"location":"styling/ysld/cookbook/points/#ysld_cookbook_points_simplepointwithstroke","title":"Simple point with stroke","text":"

                                                                                                                      This example adds a stroke (or border) around the Simple point, with the stroke colored black and given a thickness of 2 pixels.

                                                                                                                      Simple point with stroke

                                                                                                                      "},{"location":"styling/ysld/cookbook/points/#code_1","title":"Code","text":"

                                                                                                                      Download the \"Simple point with stroke\" YSLD

                                                                                                                      title: 'YSLD Cook Book: Simple point with stroke'\nfeature-styles:\n- name: name\n  rules:\n  - symbolizers:\n    - point:\n        size: 6\n        symbols:\n        - mark:\n            shape: circle\n            stroke-color: '#000000'\n            stroke-width: 2\n            fill-color: '#FF0000'\n
                                                                                                                      "},{"location":"styling/ysld/cookbook/points/#details_1","title":"Details","text":"

                                                                                                                      This example is similar to the Simple point example. Lines 11-12 specify the stroke, with line 11 setting the color to black ('#000000') and line 12 setting the width to 2 pixels.

                                                                                                                      "},{"location":"styling/ysld/cookbook/points/#rotated-square","title":"Rotated square","text":"

                                                                                                                      This example creates a square instead of a circle, colors it green, sizes it to 12 pixels, and rotates it by 45 degrees.

                                                                                                                      Rotated square

                                                                                                                      "},{"location":"styling/ysld/cookbook/points/#code_2","title":"Code","text":"

                                                                                                                      Download the \"Rotated square\" YSLD

                                                                                                                      title: 'YSLD Cook Book: Rotated square'\nfeature-styles:\n- name: name\n  rules:\n  - symbolizers:\n    - point:\n        size: 12\n        rotation: 45\n        symbols:\n        - mark:\n            shape: square\n            fill-color: '#009900'\n
                                                                                                                      "},{"location":"styling/ysld/cookbook/points/#details_2","title":"Details","text":"

                                                                                                                      In this example, line 11 sets the shape to be a square, with line 12 setting the color to a dark green (009900). Line 7 sets the size of the square to be 12 pixels, and line 8 sets the rotation to 45 degrees.

                                                                                                                      "},{"location":"styling/ysld/cookbook/points/#transparent-triangle","title":"Transparent triangle","text":"

                                                                                                                      This example draws a triangle, creates a black stroke identical to the Simple point with stroke example, and sets the fill of the triangle to 20% opacity (mostly transparent).

                                                                                                                      Transparent triangle

                                                                                                                      "},{"location":"styling/ysld/cookbook/points/#code_3","title":"Code","text":"

                                                                                                                      Download the \"Transparent triangle\" YSLD

                                                                                                                      title: 'YSLD Cook Book: Transparent triangle'\nfeature-styles:\n- name: name\n  rules:\n  - symbolizers:\n    - point:\n        size: 12\n        symbols:\n        - mark:\n            shape: triangle\n            stroke-color: '#000000'\n            stroke-width: 2\n            fill-color: '#009900'\n            fill-opacity: 0.2\n
                                                                                                                      "},{"location":"styling/ysld/cookbook/points/#details_3","title":"Details","text":"

                                                                                                                      In this example, line 10 once again sets the shape, in this case to a triangle. Line 13 sets the fill color to a dark green ('#009900') and line 14 sets the opacity to 0.2 (20% opaque). An opacity value of 1 means that the shape is drawn 100% opaque, while an opacity value of 0 means that the shape is drawn 0% opaque, or completely transparent. The value of 0.2 (20% opaque) means that the fill of the points partially takes on the color and style of whatever is drawn beneath it. In this example, since the background is white, the dark green looks lighter. Were the points imposed on a dark background, the resulting color would be darker. Lines 11-12 set the stroke color to black ('#000000') and width to 2 pixels. Finally, line 7 sets the size of the point to be 12 pixels in diameter.

                                                                                                                      "},{"location":"styling/ysld/cookbook/points/#point-as-graphic","title":"Point as graphic","text":"

                                                                                                                      This example styles each point as a graphic instead of as a simple shape.

                                                                                                                      Point as graphic

                                                                                                                      "},{"location":"styling/ysld/cookbook/points/#code_4","title":"Code","text":"

                                                                                                                      Download the \"Point as graphic\" YSLD

                                                                                                                      title: 'YSLD Cook Book: Point as graphic'\nfeature-styles:\n- name: name\n  rules:\n  - symbolizers:\n    - point:\n        size: 32\n        symbols:\n        - external:\n            url: smileyface.png\n            format: image/png\n
                                                                                                                      "},{"location":"styling/ysld/cookbook/points/#details_4","title":"Details","text":"

                                                                                                                      This style uses a graphic instead of a simple shape to render the points. In YSLD, this is known as an external, to distinguish it from the commonly-used shapes such as squares and circles that are \"internal\" to the renderer. Lines 9-11 specify the details of this graphic. Line 10 sets the path and file name of the graphic, while line 11 indicates the format (MIME type) of the graphic (image/png). In this example, the graphic is contained in the same directory as the YSLD, so no path information is necessary in line 10, although a full URL could be used if desired. Line 7 determines the size of the displayed graphic; this can be set independently of the dimensions of the graphic itself, although in this case they are the same (32 pixels). Should a graphic be rectangular, the size value will apply to the height of the graphic only, with the width scaled proportionally.

                                                                                                                      Graphic used for points

                                                                                                                      "},{"location":"styling/ysld/cookbook/points/#ysld_cookbook_points_pointwithdefaultlabel","title":"Point with default label","text":"

                                                                                                                      This example shows a text label on the Simple point that displays the \"name\" attribute of the point. This is how a label will be displayed in the absence of any other customization.

                                                                                                                      Point with default label

                                                                                                                      "},{"location":"styling/ysld/cookbook/points/#code_5","title":"Code","text":"

                                                                                                                      Download the \"Point with default label\" YSLD

                                                                                                                      title: 'YSLD Cook Book: Point with default label'\nfeature-styles:\n- name: name\n  rules:\n  - symbolizers:\n    - point:\n        size: 6\n        symbols:\n        - mark:\n            shape: circle\n            fill-color: '#FF0000'\n    - text:\n        label: ${name}\n        fill-color: '#000000'\n        font-family: Serif\n        font-size: 10\n        font-style: normal\n        font-weight: normal\n        placement: point\n
                                                                                                                      "},{"location":"styling/ysld/cookbook/points/#details_5","title":"Details","text":"

                                                                                                                      Lines 2-11, which contain the point symbolizer, are identical to the Simple point example above. The label is set in the text symbolizer on lines 12-19. Line 13 determines what text to display in the label, which in this case is the value of the \"name\" attribute. (Refer to the attribute table in the Example points layer section if necessary.) Line 15 sets the text color. All other details about the label are set to the renderer default, which here is Times New Roman font, font color black, and font size of 10 pixels. The bottom left of the label is aligned with the center of the point.

                                                                                                                      "},{"location":"styling/ysld/cookbook/points/#ysld_cookbook_points_pointwithstyledlabel","title":"Point with styled label","text":"

                                                                                                                      This example improves the label style from the Point with default label example by centering the label above the point and providing a different font name and size.

                                                                                                                      Point with styled label

                                                                                                                      "},{"location":"styling/ysld/cookbook/points/#code_6","title":"Code","text":"

                                                                                                                      Download the \"Point with styled label\" YSLD

                                                                                                                      title: 'YSLD Cook Book: Point with styled label'\nfeature-styles:\n- name: name\n  rules:\n  - symbolizers:\n    - point:\n        size: 6\n        symbols:\n        - mark:\n            shape: circle\n            fill-color: '#FF0000'\n    - text:\n        label: ${name}\n        fill-color: '#000000'\n        font-family: Arial\n        font-size: 12\n        font-style: normal\n        font-weight: bold\n        placement: point\n        anchor: [0.5,0.0]\n        displacement: [0,5]\n
                                                                                                                      "},{"location":"styling/ysld/cookbook/points/#details_6","title":"Details","text":"

                                                                                                                      In this example, lines 2-11 are identical to the Simple point example above. The <TextSymbolizer> on lines 12-21 contains many more details about the label styling than the previous example, Point with default label. Line 13 once again specifies the \"name\" attribute as text to display. Lines 15-18 set the font information: line 15 sets the font family to be \"Arial\", line 16 sets the font size to 12, line 17 sets the font style to \"normal\" (as opposed to \"italic\" or \"oblique\"), and line 18 sets the font weight to \"bold\" (as opposed to \"normal\"). Lines 19-21 determine the placement of the label relative to the point. The anchor (line 20) sets the point of intersection between the label and point, which here sets the point to be centered (0.5) horizontally axis and bottom aligned (0.0) vertically with the label. There is also displacement (line 21), which sets the offset of the label relative to the line, which in this case is 0 pixels horizontally and 5 pixels vertically . Finally, line 14 sets the font color of the label to black ('#000000').

                                                                                                                      The result is a centered bold label placed slightly above each point.

                                                                                                                      "},{"location":"styling/ysld/cookbook/points/#point-with-rotated-label","title":"Point with rotated label","text":"

                                                                                                                      This example builds on the previous example, Point with styled label, by rotating the label by 45 degrees, positioning the labels farther away from the points, and changing the color of the label to purple.

                                                                                                                      Point with rotated label

                                                                                                                      "},{"location":"styling/ysld/cookbook/points/#code_7","title":"Code","text":"

                                                                                                                      Download the \"Point with rotated label\" YSLD

                                                                                                                      title: 'YSLD Cook Book: Point with rotated label'\nfeature-styles:\n- name: name\n  rules:\n  - symbolizers:\n    - point:\n        size: 6\n        symbols:\n        - mark:\n            shape: circle\n            fill-color: '#FF0000'\n    - text:\n        label: ${name}\n        fill-color: '#990099'\n        font-family: Arial\n        font-size: 12\n        font-style: normal\n        font-weight: bold\n        placement: point\n        anchor: [0.5,0.0]\n        displacement: [0,25]\n        rotation: -45\n
                                                                                                                      "},{"location":"styling/ysld/cookbook/points/#details_7","title":"Details","text":"

                                                                                                                      This example is similar to the Point with styled label, but there are three important differences. Line 21 specifies 25 pixels of vertical displacement. Line 22 specifies a rotation of \"-45\" or 45 degrees counter-clockwise. (Rotation values increase clockwise, which is why the value is negative.) Finally, line 14 sets the font color to be a shade of purple ('#99099').

                                                                                                                      Note that the displacement takes effect before the rotation during rendering, so in this example, the 25 pixel vertical displacement is itself rotated 45 degrees.

                                                                                                                      "},{"location":"styling/ysld/cookbook/points/#attribute-based-point","title":"Attribute-based point","text":"

                                                                                                                      This example alters the size of the symbol based on the value of the population (\"pop\") attribute.

                                                                                                                      Attribute-based point

                                                                                                                      "},{"location":"styling/ysld/cookbook/points/#code_8","title":"Code","text":"

                                                                                                                      Download the \"Attribute-based point\" YSLD

                                                                                                                      title: 'YSLD Cook Book: Attribute-based point'\nfeature-styles:\n- name: name\n  rules:\n  - name: SmallPop\n    title: 1 to 50000\n    filter: ${pop < '50000'}\n    symbolizers:\n    - point:\n        size: 8\n        symbols:\n        - mark:\n            shape: circle\n            fill-color: '#0033CC'\n  - name: MediumPop\n    title: 50000 to 100000\n    filter: ${pop >= '50000' AND pop < '100000'}\n    symbolizers:\n    - point:\n        size: 12\n        symbols:\n        - mark:\n            shape: circle\n            fill-color: '#0033CC'\n  - name: LargePop\n    title: Greater than 100000\n    filter: ${pop >= '100000'}\n    symbolizers:\n    - point:\n        size: 16\n        symbols:\n        - mark:\n            shape: circle\n            fill-color: '#0033CC'\n
                                                                                                                      "},{"location":"styling/ysld/cookbook/points/#details_8","title":"Details","text":"

                                                                                                                      Note

                                                                                                                      Refer to the Example points layer to see the attributes for this data. This example has eschewed labels in order to simplify the style, but you can refer to the example Point with styled label to see which attributes correspond to which points.

                                                                                                                      This style contains three rules. Each rule varies the style based on the value of the population (\"pop\") attribute for each point, with smaller values yielding a smaller circle, and larger values yielding a larger circle.

                                                                                                                      The three rules are designed as follows:

                                                                                                                      Rule order Rule name Population (pop) Size 1 SmallPop Less than 50,000 8 2 MediumPop 50,000 to 100,000 12 3 LargePop Greater than 100,000 16

                                                                                                                      The order of the rules does not matter in this case, since each shape is only rendered by a single rule.

                                                                                                                      The first rule, on lines 5-14, specifies the styling of those points whose population attribute is less than 50,000. Line 7 sets this filter, denoting the attribute (\"pop\") to be \"less than\" the value of 50,000. The symbol is a circle (line 13), the color is dark blue ('#0033CC', on line 15), and the size is 8 pixels in diameter (line 18).

                                                                                                                      The second rule, on lines 15-24, specifies a style for points whose population attribute is greater than or equal to 50,000 and less than 100,000. The population filter is set on line 17. This filter specifies two criteria instead of one: a \"greater than or equal to\" and a \"less than\" filter. These criteria are joined by AND, which mandates that both filters need to be true for the rule to be applicable. The size of the graphic is set to 12 pixels on line 20. All other styling directives are identical to the first rule.

                                                                                                                      The third rule, on lines 25-34, specifies a style for points whose population attribute is greater than or equal to 100,000. The population filter is set on line 27, and the only other difference is the size of the circle, which in this rule (line 30) is 16 pixels.

                                                                                                                      The result of this style is that cities with larger populations have larger points.

                                                                                                                      "},{"location":"styling/ysld/cookbook/points/#zoom-based-point","title":"Zoom-based point","text":"

                                                                                                                      This example alters the style of the points at different zoom levels.

                                                                                                                      Zoom-based point: Zoomed in

                                                                                                                      Zoom-based point: Partially zoomed

                                                                                                                      Zoom-based point: Zoomed out

                                                                                                                      "},{"location":"styling/ysld/cookbook/points/#code_9","title":"Code","text":"

                                                                                                                      Download the \"Zoom-based point\" YSLD

                                                                                                                      title: 'YSLD Cook Book: Zoom-based point'\nfeature-styles:\n- name: name\n  rules:\n  - name: Large\n    scale: [min,1.6e8]\n    symbolizers:\n    - point:\n        size: 12\n        symbols:\n        - mark:\n            shape: circle\n            fill-color: '#CC3300'\n  - name: Medium\n    scale: [1.6e8,3.2e8]\n    symbolizers:\n    - point:\n        size: 8\n        symbols:\n        - mark:\n            shape: circle\n            fill-color: '#CC3300'\n  - name: Small\n    scale: [3.2e8,max]\n    symbolizers:\n    - point:\n        size: 4\n        symbols:\n        - mark:\n            shape: circle\n            fill-color: '#CC3300'\n
                                                                                                                      "},{"location":"styling/ysld/cookbook/points/#details_9","title":"Details","text":"

                                                                                                                      It is often desirable to make shapes larger at higher zoom levels when creating a natural-looking map. This example styles the points to vary in size based on the zoom level (or more accurately, scale denominator). Scale denominators refer to the scale of the map. A scale denominator of 10,000 means the map has a scale of 1:10,000 in the units of the map projection.

                                                                                                                      Note

                                                                                                                      Determining the appropriate scale denominators (zoom levels) to use is beyond the scope of this example.

                                                                                                                      This style contains three rules. The three rules are designed as follows:

                                                                                                                      Rule order Rule name Scale denominator Point size 1 Large 1:160,000,000 or less 12 2 Medium 1:160,000,000 to 1:320,000,000 8 3 Small Greater than 1:320,000,000 4

                                                                                                                      The order of these rules does not matter since the scales denominated in each rule do not overlap.

                                                                                                                      The first rule (lines 5-13) is for the smallest scale denominator, corresponding to when the view is \"zoomed in\". The scale rule is set on line 6, so that the rule will apply to any map with a scale denominator of 160,000,000 or less. The rule draws a circle (line 12), colored red (#CC3300 on line 13) with a size of 12 pixels (line 9).

                                                                                                                      The second rule (lines 14-22) is the intermediate scale denominator, corresponding to when the view is \"partially zoomed\". The scale rules is set on line 15, so that the rule will apply to any map with a scale denominator between 160,000,000 and 320,000,000. (The lower bound is inclusive and the upper bound is exclusive, so a zoom level of exactly 320,000,000 would not apply here.) Aside from the scale, the only difference between this rule and the first is the size of the symbol, which is set to 8 pixels on line 18.

                                                                                                                      The third rule (lines 23-31) is the largest scale denominator, corresponding to when the map is \"zoomed out\". The scale rule is set on line 24, so that the rule will apply to any map with a scale denominator of 320,000,000 or more. Again, the only other difference between this rule and the others is the size of the symbol, which is set to 4 pixels on line 27.

                                                                                                                      The result of this style is that points are drawn larger as one zooms in and smaller as one zooms out.

                                                                                                                      "},{"location":"styling/ysld/cookbook/polygons/","title":"Polygons","text":"

                                                                                                                      Polygons are two dimensional shapes that contain both an outer edge (or \"stroke\") and an inside (or \"fill\"). A polygon can be thought of as an irregularly-shaped point and is styled in similar ways to points.

                                                                                                                      "},{"location":"styling/ysld/cookbook/polygons/#ysld_cookbook_polygons_attributes","title":"Example polygons layer","text":"

                                                                                                                      The polygons layer used below contains county information for a fictional country. For reference, the attribute table for the polygons is included below.

                                                                                                                      fid (Feature ID) name (County name) pop (Population) polygon.1 Irony County 412234 polygon.2 Tracker County 235421 polygon.3 Dracula County 135022 polygon.4 Poly County 1567879 polygon.5 Bearing County 201989 polygon.6 Monte Cristo County 152734 polygon.7 Massive County 67123 polygon.8 Rhombus County 198029

                                                                                                                      Download the polygons shapefile

                                                                                                                      "},{"location":"styling/ysld/cookbook/polygons/#ysld_cookbook_polygons_simplepolygon","title":"Simple polygon","text":"

                                                                                                                      This example shows a polygon filled in blue.

                                                                                                                      Simple polygon

                                                                                                                      "},{"location":"styling/ysld/cookbook/polygons/#code","title":"Code","text":"

                                                                                                                      Download the \"Simple polygon\" YSLD

                                                                                                                      title: 'YSLD Cook Book: Simple polygon'\nfeature-styles:\n- name: name\n  rules:\n  - symbolizers:\n    - polygon:\n        fill-color: '#000080'\n
                                                                                                                      "},{"location":"styling/ysld/cookbook/polygons/#details","title":"Details","text":"

                                                                                                                      There is one rule in one feature style for this style, which is the simplest possible situation. (All subsequent examples will share this characteristic unless otherwise specified.) Styling polygons is accomplished via the polygon symbolizer (lines 6-7). Line 7 specifies dark blue ('#000080') as the polygon's fill color.

                                                                                                                      Note

                                                                                                                      The light-colored borders around the polygons in the figure are artifacts of the renderer caused by the polygons being adjacent. There is no border in this style.

                                                                                                                      "},{"location":"styling/ysld/cookbook/polygons/#ysld_cookbook_polygons_simplepolygonwithstroke","title":"Simple polygon with stroke","text":"

                                                                                                                      This example adds a 2 pixel white stroke to the Simple polygon example.

                                                                                                                      Simple polygon with stroke

                                                                                                                      "},{"location":"styling/ysld/cookbook/polygons/#code_1","title":"Code","text":"

                                                                                                                      Download the \"Simple polygon with stroke\" YSLD

                                                                                                                      title: 'YSLD Cook Book: Simple polygon with stroke'\nfeature-styles:\n- name: name\n  rules:\n  - symbolizers:\n    - polygon:\n        stroke-color: '#FFFFFF'\n        stroke-width: 2\n        fill-color: '#000080'\n
                                                                                                                      "},{"location":"styling/ysld/cookbook/polygons/#details_1","title":"Details","text":"

                                                                                                                      This example is similar to the Simple polygon example above, with the addition of stroke parameters (lines 7-8). Line 7 sets the color of stroke to white ('#FFFFFF') and line 8 sets the width of the stroke to 2 pixels.

                                                                                                                      "},{"location":"styling/ysld/cookbook/polygons/#transparent-polygon","title":"Transparent polygon","text":"

                                                                                                                      This example builds on the Simple polygon with stroke example and makes the fill partially transparent by setting the opacity to 50%.

                                                                                                                      Transparent polygon

                                                                                                                      "},{"location":"styling/ysld/cookbook/polygons/#code_2","title":"Code","text":"

                                                                                                                      Download the \"Transparent polygon\" YSLD

                                                                                                                      title: 'YSLD Cook Book: Transparent polygon'\nfeature-styles:\n- name: name\n  rules:\n  - symbolizers:\n    - polygon:\n        stroke-color: '#FFFFFF'\n        stroke-width: 2\n        fill-color: '#000080'\n        fill-opacity: 0.5\n
                                                                                                                      "},{"location":"styling/ysld/cookbook/polygons/#details_2","title":"Details","text":"

                                                                                                                      This example is similar to the Simple polygon with stroke example, save for defining the fill's opacity in line 10. The value of 0.5 results in partially transparent fill that is 50% opaque. An opacity value of 1 would draw the fill as 100% opaque, while an opacity value of 0 would result in a completely transparent (0% opaque) fill. In this example, since the background is white, the dark blue looks lighter. Were the points imposed on a dark background, the resulting color would be darker.

                                                                                                                      "},{"location":"styling/ysld/cookbook/polygons/#ysld_cookbook_polygons_graphicfill","title":"Graphic fill","text":"

                                                                                                                      This example fills the polygons with a tiled graphic.

                                                                                                                      Graphic fill

                                                                                                                      "},{"location":"styling/ysld/cookbook/polygons/#code_3","title":"Code","text":"

                                                                                                                      Download the \"Graphic fill\" YSLD

                                                                                                                      title: 'YSLD Cook Book: Graphic fill'\nfeature-styles:\n- name: name\n  rules:\n  - symbolizers:\n    - polygon:\n        fill-color: '#808080'\n        fill-graphic:\n          size: 93\n          symbols:\n          - external:\n              url: colorblocks.png\n              format: image/png\n
                                                                                                                      "},{"location":"styling/ysld/cookbook/polygons/#details_3","title":"Details","text":"

                                                                                                                      This style fills the polygon with a tiled graphic. This is known as an external in YSLD, to distinguish it from commonly-used shapes such as squares and circles that are \"internal\" to the renderer. Lines 11-13 specify details for the graphic, with line 12 setting the path and file name of the graphic and line 13 indicating the file format (MIME type) of the graphic (image/png). Although a full URL could be specified if desired, no path information is necessary in line 12 because this graphic is contained in the same directory as the YSLD. Line 9 determines the height of the displayed graphic in pixels; if the value differs from the height of the graphic then it will be scaled accordingly while preserving the aspect ratio.

                                                                                                                      Graphic used for fill

                                                                                                                      "},{"location":"styling/ysld/cookbook/polygons/#hatching-fill","title":"Hatching fill","text":"

                                                                                                                      This example fills the polygons with a hatching pattern.

                                                                                                                      Hatching fill

                                                                                                                      "},{"location":"styling/ysld/cookbook/polygons/#code_4","title":"Code","text":"

                                                                                                                      Download the \"Hatching fill\" YSLD

                                                                                                                      title: 'YSLD Cook Book: Hatching fill'\nfeature-styles:\n- name: name\n  rules:\n  - symbolizers:\n    - polygon:\n        fill-color: '#808080'\n        fill-graphic:\n          size: 16\n          symbols:\n          - mark:\n              shape: shape://times\n              stroke-color: '#990099'\n              stroke-width: 1\n
                                                                                                                      "},{"location":"styling/ysld/cookbook/polygons/#details_4","title":"Details","text":"

                                                                                                                      In this example, there is a fill-graphic parameter as in the Graphic fill example, but a mark (lines 11-14) is used instead of an external. Line 12 specifies a \"times\" symbol (an \"x\") be tiled throughout the polygon. Line 13 sets the color to purple ('#990099'), line 14 sets the width of the hatches to 1 pixel, and line 9 sets the size of the tile to 16 pixels. Because hatch tiles are always square, the size sets both the width and the height.

                                                                                                                      "},{"location":"styling/ysld/cookbook/polygons/#ysld_cookbook_polygons_polygonwithdefaultlabel","title":"Polygon with default label","text":"

                                                                                                                      This example shows a text label on the polygon. In the absence of any other customization, this is how a label will be displayed.

                                                                                                                      Polygon with default label

                                                                                                                      "},{"location":"styling/ysld/cookbook/polygons/#code_5","title":"Code","text":"

                                                                                                                      Download the \"Polygon with default label\" YSLD

                                                                                                                      title: 'YSLD Cook Book: Polygon with default label'\nfeature-styles:\n- name: name\n  rules:\n  - symbolizers:\n    - polygon:\n        stroke-color: '#FFFFFF'\n        stroke-width: 2\n        fill-color: '#40FF40'\n    - text:\n        label: ${name}\n        placement: point\n
                                                                                                                      "},{"location":"styling/ysld/cookbook/polygons/#details_5","title":"Details","text":"

                                                                                                                      In this example there is a polygon symbolizer and a text symbolizer. Lines 6-9 comprise the polygon symbolizer. The fill of the polygon is set on line 7 to a light green ('#40FF40') while the stroke of the polygon is set on lines 8-9 to white ('#FFFFFF') with a thickness of 2 pixels. The label is set in the text symbolizer on lines 10-12, with line 11 determining what text to display, in this case the value of the \"name\" attribute. (Refer to the attribute table in the Example polygons layer section if necessary.) All other details about the label are set to the renderer default, which here is Times New Roman font, font color black, and font size of 10 pixels.

                                                                                                                      "},{"location":"styling/ysld/cookbook/polygons/#label-halo","title":"Label halo","text":"

                                                                                                                      This example alters the look of the Polygon with default label by adding a white halo to the label.

                                                                                                                      Label halo

                                                                                                                      "},{"location":"styling/ysld/cookbook/polygons/#code_6","title":"Code","text":"

                                                                                                                      Download the \"Label halo\" YSLD

                                                                                                                      title: 'YSLD Cook Book: Label halo'\nfeature-styles:\n- name: name\n  rules:\n  - symbolizers:\n    - polygon:\n        stroke-color: '#FFFFFF'\n        stroke-width: 2\n        fill-color: '#40FF40'\n    - text:\n        label: ${name}\n        halo:\n          fill-color: '#FFFFFF'\n          radius: 3\n        placement:\n          type: point\n
                                                                                                                      "},{"location":"styling/ysld/cookbook/polygons/#details_6","title":"Details","text":"

                                                                                                                      This example is similar to the Polygon with default label, with the addition of a halo around the labels on lines 12-14. A halo creates a color buffer around the label to improve label legibility. Line 14 sets the radius of the halo, extending the halo 3 pixels around the edge of the label, and line 13 sets the color of the halo to white ('#FFFFFF'). Since halos are most useful when set to a sharp contrast relative to the text color, this example uses a white halo around black text to ensure optimum readability.

                                                                                                                      "},{"location":"styling/ysld/cookbook/polygons/#ysld_cookbook_polygons_polygonwithstyledlabel","title":"Polygon with styled label","text":"

                                                                                                                      This example improves the label style from the Polygon with default label example by centering the label on the polygon, specifying a different font name and size, and setting additional label placement optimizations.

                                                                                                                      Polygon with styled label

                                                                                                                      "},{"location":"styling/ysld/cookbook/polygons/#code_7","title":"Code","text":"

                                                                                                                      Download the \"Polygon with styled label\" YSLD

                                                                                                                      title: 'YSLD Cook Book: Polygon with styled label'\nfeature-styles:\n- name: name\n  rules:\n  - symbolizers:\n    - polygon:\n        stroke-color: '#FFFFFF'\n        stroke-width: 2\n        fill-color: '#40FF40'\n    - text:\n        label: ${name}\n        fill-color: '#000000'\n        font-family: Arial\n        font-size: 11\n        font-style: normal\n        font-weight: bold\n        placement: point\n        anchor: [0.5,0.5]\n        x-autoWrap: 60\n        x-maxDisplacement: 150\n
                                                                                                                      "},{"location":"styling/ysld/cookbook/polygons/#details_7","title":"Details","text":"

                                                                                                                      This example is similar to the Polygon with default label example, with additional styling options within the text symbolizer on lines 13-21. Lines 13-16 set the font styling. Line 13 sets the font family to be Arial, line 14 sets the font size to 11 pixels, line 15 sets the font style to \"normal\" (as opposed to \"italic\" or \"oblique\"), and line 16 sets the font weight to \"bold\" (as opposed to \"normal\").

                                                                                                                      The anchor parameter on line 18 centers the label by positioning it 50% (or 0.5) of the way horizontally and vertically along the centroid of the polygon.

                                                                                                                      Finally, there are two added touches for label placement optimization: line 20 ensures that long labels are split across multiple lines by setting line wrapping on the labels to 60 pixels, and line 21 allows the label to be displaced by up to 150 pixels. This ensures that labels are compacted and less likely to spill over polygon boundaries. Notice little Massive County in the corner, whose label is now displayed.\"

                                                                                                                      "},{"location":"styling/ysld/cookbook/polygons/#attribute-based-polygon","title":"Attribute-based polygon","text":"

                                                                                                                      This example styles the polygons differently based on the \"pop\" (Population) attribute.

                                                                                                                      Attribute-based polygon

                                                                                                                      "},{"location":"styling/ysld/cookbook/polygons/#code_8","title":"Code","text":"

                                                                                                                      Download the \"Attribute-based polygon\" YSLD

                                                                                                                      title: 'YSLD Cook Book: Attribute-based polygon'\nfeature-styles:\n- name: name\n  rules:\n  - name: SmallPop\n    title: Less Than 200,000\n    filter: ${pop < '200000'}\n    symbolizers:\n    - polygon:\n        fill-color: '#66FF66'\n  - name: MediumPop\n    title: 200,000 to 500,000\n    filter: ${pop >= '200000' AND pop < '500000'}\n    symbolizers:\n    - polygon:\n        fill-color: '#33CC33'\n  - name: LargePop\n    title: ${Greater Than 500,000}\n    filter: pop > '500000'\n    symbolizers:\n    - polygon:\n        fill-color: '#009900'\n
                                                                                                                      "},{"location":"styling/ysld/cookbook/polygons/#details_8","title":"Details","text":"

                                                                                                                      Note

                                                                                                                      Refer to the Example polygons layer to see the attributes for the layer. This example has eschewed labels in order to simplify the style, but you can refer to the example Polygon with styled label to see which attributes correspond to which polygons.

                                                                                                                      Each polygon in our fictional country has a population that is represented by the population (\"pop\") attribute. This style contains three rules that alter the fill based on the value of \"pop\" attribute, with smaller values yielding a lighter color and larger values yielding a darker color.

                                                                                                                      The three rules are designed as follows:

                                                                                                                      Rule order Rule name Population (pop) Color 1 SmallPop Less than 200,000 #66FF66 2 MediumPop 200,000 to 500,000 #33CC33 3 LargePop Greater than 500,000 #009900

                                                                                                                      The order of the rules does not matter in this case, since each shape is only rendered by a single rule.

                                                                                                                      The first rule, on lines 5-10, specifies the styling of polygons whose population attribute is less than 200,000. Line 7 sets this filter, denoting the attribute (\"pop\"), to be \"less than\" the value of 200,000. The color of the polygon fill is set to a light green ('#66FF66') on line 10.

                                                                                                                      The second rule, on lines 11-16, is similar, specifying a style for polygons whose population attribute is greater than or equal to 200,000 but less than 500,000. The filter is set on line 13. This filter specifies two criteria instead of one: a \"greater than or equal to\" and a \"less than\" filter. These criteria are joined by AND, which mandates that both filters need to be true for the rule to be applicable. The color of the polygon fill is set to a medium green on ('#33CC33') on line 16.

                                                                                                                      The third rule, on lines 17-22, specifies a style for polygons whose population attribute is greater than or equal to 500,000. The filter is set on line 19. The color of the polygon fill is the only other difference in this rule, which is set to a dark green ('#009900') on line 22.

                                                                                                                      "},{"location":"styling/ysld/cookbook/polygons/#zoom-based-polygon","title":"Zoom-based polygon","text":"

                                                                                                                      This example alters the style of the polygon at different zoom levels.

                                                                                                                      Zoom-based polygon: Zoomed in

                                                                                                                      Zoom-based polygon: Partially zoomed

                                                                                                                      Zoom-based polygon: Zoomed out

                                                                                                                      "},{"location":"styling/ysld/cookbook/polygons/#code_9","title":"Code","text":"

                                                                                                                      Download the \"Zoom-based polygon\" YSLD

                                                                                                                      title: 'YSLD Cook Book: Zoom-based polygon'\nfeature-styles:\n- name: name\n  rules:\n  - name: Large\n    scale: [min,1.0e8]\n    symbolizers:\n    - polygon:\n        stroke-color: '#000000'\n        stroke-width: 7\n        fill-color: '#0000CC'\n    - text:\n        label: ${name}\n        fill-color: '#FFFFFF'\n        font-family: Arial\n        font-size: 14\n        font-style: normal\n        font-weight: bold\n        placement: point\n        anchor: [0.5,0.5]\n  - name: Medium\n    scale: [1.0e8,2.0e8]\n    symbolizers:\n    - polygon:\n        stroke-color: '#000000'\n        stroke-width: 4\n        fill-color: '#0000CC'\n  - name: Small\n    scale: [2.0e8,max]\n    symbolizers:\n    - polygon:\n        stroke-color: '#000000'\n        stroke-width: 1\n        fill-color: '#0000CC'\n
                                                                                                                      "},{"location":"styling/ysld/cookbook/polygons/#details_9","title":"Details","text":"

                                                                                                                      It is often desirable to make shapes larger at higher zoom levels when creating a natural-looking map. This example varies the thickness of the lines according to the zoom level. Polygons already do this by nature of being two dimensional, but another way to adjust styling of polygons based on zoom level is to adjust the thickness of the stroke (to be larger as the map is zoomed in) or to limit labels to only certain zoom levels. This is ensures that the size and quantity of strokes and labels remains legible and doesn't overshadow the polygons themselves.

                                                                                                                      Zoom levels (or more accurately, scale denominators) refer to the scale of the map. A scale denominator of 10,000 means the map has a scale of 1:10,000 in the units of the map projection.

                                                                                                                      Note

                                                                                                                      Determining the appropriate scale denominators (zoom levels) to use is beyond the scope of this example.

                                                                                                                      This style contains three rules, defined as follows:

                                                                                                                      Rule order Rule name Scale denominator Stroke width Label display? 1 Large 1:100,000,000 or less 7 Yes 2 Medium 1:100,000,000 to 1:200,000,000 4 No 3 Small Greater than 1:200,000,000 2 No

                                                                                                                      The first rule, on lines 5-20, is for the smallest scale denominator, corresponding to when the view is \"zoomed in\". The scale rule is set on line 6 such that the rule will apply only where the scale denominator is 100,000,000 or less. Line 11 defines the fill as blue ('#0000CC'). Note that the fill is kept constant across all rules regardless of the scale denominator. As in the Polygon with default label or Polygon with styled label examples, the rule also contains a text symbolizer at lines 12-20 for drawing a text label on top of the polygon. Lines 15-18 set the font information to be Arial, 14 pixels, and bold with no italics. The label is centered both horizontally and vertically along the centroid of the polygon on by setting anchor to be [0.5, 0.5] (or 50%) on line 20. Finally, the color of the font is set to white ('#FFFFFF') in line 14.

                                                                                                                      The second rule, on lines 21-27, is for the intermediate scale denominators, corresponding to when the view is \"partially zoomed\". The scale rules on lines 22 set the rule such that it will apply to any map with a scale denominator between 100,000,000 and 200,000,000. (The lower bound is inclusive and the upper bound is exclusive, so a zoom level of exactly 200,000,000 would not apply here.) Aside from the scale, there are two differences between this rule and the first: the width of the stroke is set to 4 pixels on line 26 and a text symbolizer is not present so that no labels will be displayed.

                                                                                                                      The third rule, on lines 28-34, is for the largest scale denominator, corresponding to when the map is \"zoomed out\". The scale rule is set on line 29 such that the rule will apply to any map with a scale denominator of 200,000,000 or greater. Again, the only differences between this rule and the others are the width of the lines, which is set to 1 pixel on line 33, and the absence of a text symbolizer so that no labels will be displayed.

                                                                                                                      The resulting style produces a polygon stroke that gets larger as one zooms in and labels that only display when zoomed in to a sufficient level.

                                                                                                                      "},{"location":"styling/ysld/cookbook/rasters/","title":"Rasters","text":"

                                                                                                                      Rasters are geographic data displayed in a grid. They are similar to image files such as PNG files, except that instead of each point containing visual information, each point contains geographic information in numerical form. Rasters can be thought of as a georeferenced table of numerical values.

                                                                                                                      One example of a raster is a Digital Elevation Model (DEM) layer, which has elevation data encoded numerically at each georeferenced data point.

                                                                                                                      "},{"location":"styling/ysld/cookbook/rasters/#example-raster","title":"Example raster","text":"

                                                                                                                      The raster layer that is used in the examples below contains elevation data for a fictional world. The data is stored in EPSG:4326 (longitude/latitude) and has a data range from 70 to 256. If rendered in grayscale, where minimum values are colored black and maximum values are colored white, the raster would look like this:

                                                                                                                      Raster file as rendered in grayscale

                                                                                                                      Download the raster shapefile

                                                                                                                      "},{"location":"styling/ysld/cookbook/rasters/#ysld_cookbook_raster_twocolorgradient","title":"Two-color gradient","text":"

                                                                                                                      This example shows a two-color style with green at lower elevations and brown at higher elevations.

                                                                                                                      Two-color gradient

                                                                                                                      "},{"location":"styling/ysld/cookbook/rasters/#code","title":"Code","text":"

                                                                                                                      Download the \"Two-color gradient\" YSLD

                                                                                                                      title: 'YSLD Cook Book: Two color gradient'\nfeature-styles:\n- name: name\n  rules:\n  - symbolizers:\n    - raster:\n        opacity: 1.0\n        color-map:\n          type: ramp\n          entries:\n          - ['#008000',1,70,'']\n          - ['#663333',1,256,'']\n
                                                                                                                      "},{"location":"styling/ysld/cookbook/rasters/#details","title":"Details","text":"

                                                                                                                      There is one rule in one feature style for this example, which is the simplest possible situation. All subsequent examples will share this characteristic. Styling of rasters is done via the raster symbolizer (lines 2-7).

                                                                                                                      This example creates a smooth gradient between two colors corresponding to two elevation values. The gradient is created via the color-map on lines 8-12. Each entry in the color-map represents one entry or anchor in the gradient. Line 11 sets the lower value of 70 and color to a dark green ('#008000'). Line 12 sets the upper value of 256 and color to a dark brown ('#663333'). Line 9 sets the type to ramp, which means that all data values in between these two quantities will be linearly interpolated: a value of 163 (the midpoint between 70 and 256) will be colored as the midpoint between the two colors (in this case approximately '#335717', a muddy green).

                                                                                                                      "},{"location":"styling/ysld/cookbook/rasters/#transparent-gradient","title":"Transparent gradient","text":"

                                                                                                                      This example creates the same two-color gradient as in the Two-color gradient as in the example above but makes the entire layer mostly transparent by setting a 30% opacity.

                                                                                                                      Transparent gradient

                                                                                                                      "},{"location":"styling/ysld/cookbook/rasters/#code_1","title":"Code","text":"

                                                                                                                      Download the \"Transparent gradient\" YSLD

                                                                                                                      title: 'YSLD Cook Book: Transparent gradient'\nfeature-styles:\n- name: name\n  rules:\n  - symbolizers:\n    - raster:\n        opacity: 0.3\n        color-map:\n          type: ramp\n          entries:\n          - ['#008000',1,70,'']\n          - ['#663333',1,256,'']\n
                                                                                                                      "},{"location":"styling/ysld/cookbook/rasters/#details_1","title":"Details","text":"

                                                                                                                      This example is similar to the Two-color gradient example save for the addition of line 7, which sets the opacity of the layer to 0.3 (or 30% opaque). An opacity value of 1 means that the shape is drawn 100% opaque, while an opacity value of 0 means that the shape is rendered as completely transparent. The value of 0.3 means that the raster partially takes on the color and style of whatever is drawn beneath it. Since the background is white in this example, the colors generated from the color-map look lighter, but were the raster imposed on a dark background the resulting colors would be darker.

                                                                                                                      "},{"location":"styling/ysld/cookbook/rasters/#brightness-and-contrast","title":"Brightness and contrast","text":"

                                                                                                                      This example normalizes the color output and then increases the brightness by a factor of 2.

                                                                                                                      Brightness and contrast

                                                                                                                      "},{"location":"styling/ysld/cookbook/rasters/#code_2","title":"Code","text":"

                                                                                                                      Download the \"Brightness and contrast\" YSLD

                                                                                                                      title: 'YSLD Cook Book: Brightness and contrast'\nfeature-styles:\n- name: name\n  rules:\n  - symbolizers:\n    - raster:\n        opacity: 1\n        color-map:\n          type: ramp\n          entries:\n          - ['#008000',1,70,'']\n          - ['#663333',1,256,'']\n        contrast-enhancement:\n          mode: normalize\n          gamma: 0.5\n
                                                                                                                      "},{"location":"styling/ysld/cookbook/rasters/#details_2","title":"Details","text":"

                                                                                                                      This example is similar to the Two-color gradient, save for the addition of the contrast-enhancement parameter on lines 13-15. Line 14 normalizes the output by increasing the contrast to its maximum extent. Line 15 then adjusts the brightness by a factor of 0.5. Since values less than 1 make the output brighter, a value of 0.5 makes the output twice as bright.

                                                                                                                      As with previous examples, lines 8-12 determine the color-map, with line 11 setting the lower bound (70) to be colored dark green ('#008000') and line 12 setting the upper bound (256) to be colored dark brown ('#663333').

                                                                                                                      "},{"location":"styling/ysld/cookbook/rasters/#three-color-gradient","title":"Three-color gradient","text":"

                                                                                                                      This example creates a three-color gradient in primary colors.

                                                                                                                      Three-color gradient

                                                                                                                      "},{"location":"styling/ysld/cookbook/rasters/#code_3","title":"Code","text":"

                                                                                                                      Download the \"Three-color gradient\" YSLD

                                                                                                                      title: 'YSLD Cook Book: Three color gradient'\nfeature-styles:\n- name: name\n  rules:\n  - symbolizers:\n    - raster:\n        opacity: 1\n        color-map:\n          type: ramp\n          entries:\n          - ['#0000FF',1,150,'']\n          - ['#FFFF00',1,200,'']\n          - ['#FF0000',1,250,'']\n
                                                                                                                      "},{"location":"styling/ysld/cookbook/rasters/#details_3","title":"Details","text":"

                                                                                                                      This example creates a three-color gradient based on a color-map with three entries on lines 8-13: line 11 specifies the lower bound (150) be styled in blue ('#0000FF'), line 12 specifies an intermediate point (200) be styled in yellow ('#FFFF00'), and line 13 specifies the upper bound (250) be styled in red ('#FF0000').

                                                                                                                      Since our data values run between 70 and 256, some data points are not accounted for in this style. Those values below the lowest entry in the color map (the range from 70 to 149) are styled the same color as the lower bound, in this case blue. Values above the upper bound in the color map (the range from 251 to 256) are styled the same color as the upper bound, in this case red.

                                                                                                                      "},{"location":"styling/ysld/cookbook/rasters/#alpha-channel","title":"Alpha channel","text":"

                                                                                                                      This example creates an \"alpha channel\" effect such that higher values are increasingly transparent.

                                                                                                                      Alpha channel

                                                                                                                      "},{"location":"styling/ysld/cookbook/rasters/#code_4","title":"Code","text":"

                                                                                                                      Download the \"Alpha channel\" YSLD

                                                                                                                      title: 'YSLD Cook Book: Alpha channel'\nfeature-styles:\n- name: name\n  rules:\n  - symbolizers:\n    - raster:\n        opacity: 1\n        color-map:\n          type: ramp\n          entries:\n          - ['#008000',1,70,'']\n          - ['#008000',0,256,'']\n
                                                                                                                      "},{"location":"styling/ysld/cookbook/rasters/#details_4","title":"Details","text":"

                                                                                                                      An alpha channel is another way of referring to variable transparency. Much like how a gradient maps values to colors, each entry in a color-map can have a value for opacity (with the default being 1.0 or completely opaque).

                                                                                                                      In this example, there is a color-map with two entries: line 11 specifies the lower bound of 70 be colored dark green ('#008000'), while line 13 specifies the upper bound of 256 also be colored dark green but with an opacity value of 0. This means that values of 256 will be rendered at 0% opacity (entirely transparent). Just like the gradient color, the opacity is also linearly interpolated such that a value of 163 (the midpoint between 70 and 256) is rendered at 50% opacity.

                                                                                                                      "},{"location":"styling/ysld/cookbook/rasters/#discrete-colors","title":"Discrete colors","text":"

                                                                                                                      This example shows a gradient that is not linearly interpolated but instead has values mapped precisely to one of three specific colors.

                                                                                                                      Discrete colors

                                                                                                                      "},{"location":"styling/ysld/cookbook/rasters/#code_5","title":"Code","text":"

                                                                                                                      Download the \"Discrete colors\" YSLD

                                                                                                                      title: 'YSLD Cook Book: Discrete colors'\nfeature-styles:\n- name: name\n  rules:\n  - symbolizers:\n    - raster:\n        opacity: 1\n        color-map:\n          type: intervals\n          entries:\n          - ['#008000',1,150,'']\n          - ['#663333',1,256,'']\n
                                                                                                                      "},{"location":"styling/ysld/cookbook/rasters/#details_5","title":"Details","text":"

                                                                                                                      Sometimes color bands in discrete steps are more appropriate than a color gradient. The type: intervals parameter added to the color-map on line 9 sets the display to output discrete colors instead of a gradient. The values in each entry correspond to the upper bound for the color band such that colors are mapped to values less than the value of one entry but greater than or equal to the next lower entry. For example, line 11 colors all values less than 150 to dark green ('#008000') and line 12 colors all values less than 256 but greater than or equal to 150 to dark brown ('#663333').

                                                                                                                      "},{"location":"styling/ysld/cookbook/rasters/#many-color-gradient","title":"Many color gradient","text":"

                                                                                                                      This example shows a gradient interpolated across eight different colors.

                                                                                                                      Many color gradient

                                                                                                                      "},{"location":"styling/ysld/cookbook/rasters/#code_6","title":"Code","text":"

                                                                                                                      Download the \"Many color gradient\" YSLD

                                                                                                                      title: 'YSLD Cook Book: Many color gradient'\nfeature-styles:\n- name: name\n  rules:\n  - symbolizers:\n    - raster:\n        opacity: 1\n        color-map:\n          type: ramp\n          entries:\n          - ['#000000',1,95,'']\n          - ['#0000FF',1,110,'']\n          - ['#00FF00',1,135,'']\n          - ['#FF0000',1,160,'']\n          - ['#FF00FF',1,185,'']\n          - ['#FFFF00',1,210,'']\n          - ['#00FFFF',1,235,'']\n          - ['#FFFFFF',1,256,'']\n
                                                                                                                      "},{"location":"styling/ysld/cookbook/rasters/#details_6","title":"Details","text":"

                                                                                                                      A color-map can include up to 255 entries. This example has eight entries (lines 11-18):

                                                                                                                      Entry number Value Color RGB code 1 95 Black '#000000' 2 110 Blue '#0000FF' 3 135 Green '#00FF00' 4 160 Red '#FF0000' 5 185 Purple '#FF00FF' 6 210 Yellow '#FFFF00' 7 235 Cyan '#00FFFF' 8 256 White '#FFFFFF'"},{"location":"styling/ysld/reference/","title":"YSLD reference","text":"

                                                                                                                      This section will detail the usage and syntax of the YSLD markup language.

                                                                                                                      As YSLD is heavily modeled on YAML, it may be useful to refer to the YAML specification for basic syntax.

                                                                                                                      • Structure
                                                                                                                      • Feature Styles
                                                                                                                      • Rules
                                                                                                                      • Symbolizers
                                                                                                                      • Line symbolizer
                                                                                                                      • Polygon symbolizer
                                                                                                                      • Point symbolizer
                                                                                                                      • Raster symbolizer
                                                                                                                      • Text symbolizer
                                                                                                                      • Scale and zoom
                                                                                                                      • Filters
                                                                                                                      • Functions
                                                                                                                      • Define and reuse YAML Variables
                                                                                                                      • Transforms
                                                                                                                      "},{"location":"styling/ysld/reference/featurestyles/","title":"Feature Styles","text":"

                                                                                                                      In YSLD, a Feature Style is a block of styling Rules. The Feature Style is applied to a single feature type and drawn in an off-screen buffer.

                                                                                                                      The feature style element

                                                                                                                      The purpose of a Feature Style is to specify drawing order. The buffer for the first Feature Style will be drawn first, while buffer for the second Feature Style will be processed after that, etc. When drawing is complete the buffers will composed into the final drawn map.

                                                                                                                      A Feature Style is a top-level element in a YSLD style.

                                                                                                                      Consider the following hierarchy:

                                                                                                                      • Feature Style 1
                                                                                                                        • Rule 1a
                                                                                                                        • Rule 1b
                                                                                                                      • Feature Style 2
                                                                                                                        • Rule 2a
                                                                                                                        • Rule 2b
                                                                                                                        • Rule 2c

                                                                                                                      In this case, the rules contained inside Feature Style 1 will be processed and their symbolizers drawn first. After Rule 1a and 1b are processed, the renderer will move on to Feature Style 2, where Rule 2a, 2b, and 2c will then be processed and their symbolizers drawn.

                                                                                                                      Feature style order

                                                                                                                      "},{"location":"styling/ysld/reference/featurestyles/#drawing-order","title":"Drawing order","text":"

                                                                                                                      The order of feature styles is significant, and also the order of rules inside feature styles is significant.

                                                                                                                      Rules inside a feature style are all applied to each feature at once. After all of the rules in a feature style have been applied to each feature, the next feature style will start again, applying rules to each feature.

                                                                                                                      The off-screen buffer for each feature style is merged together during composition. These buffers are merged in the order defined by the feature styles. In this way, using multiple feature styles is a way of specifying z-order.

                                                                                                                      Consider the same hierarchy as above. Given a layer that contains three features, the rules will be applied as follows:

                                                                                                                      Feature style 1 will draw an off-screen buffer:

                                                                                                                      1. Rule 1a is applied to the first feature, followed by rule 1b
                                                                                                                      2. Rule 1a is applied to the second feature, followed by rule 1b
                                                                                                                      3. Rule 1a is applied to the third feature, followed by rule 1b

                                                                                                                      Feature style 1 buffer

                                                                                                                      Feature style 2 will draw an off-screen buffer:

                                                                                                                      1. Rule 2a is applied to the first feature, followed by rule 2b and then rule 2c
                                                                                                                      2. Rule 2a is applied to the second feature, followed by rule 2b and then rule 2c
                                                                                                                      3. Rule 2a is applied to the third feature, followed by rule 2b and then rule 2c

                                                                                                                      Feature style 2 buffer

                                                                                                                      This final map is produced by composition:

                                                                                                                      1. The buffer for feature style 1 is drawn
                                                                                                                      2. The buffer for feature style 2 is drawn
                                                                                                                      3. Any labeling is drawn on top

                                                                                                                      Composition of both feature styles

                                                                                                                      If you need a rule to apply on top of other rules, use a second feature style. A useful case for this is for lines representing bridges or overpasses. In order to ensure that the bridge lines always display on \"top\" of other lines (which in a display that includes, they would need to be applied using a second feature style.)

                                                                                                                      "},{"location":"styling/ysld/reference/featurestyles/#syntax","title":"Syntax","text":"

                                                                                                                      The following is the basic syntax of a feature style. Note that the contents of the block are not all expanded here.

                                                                                                                      feature-styles:\n- name: <text>\n  title: <text>\n  abstract: <text>\n  transform:\n    ...\n  rules:\n  - ...\n  x-ruleEvaluation: <text>\n  x-composite: <text>\n  x-composite-base: <boolean>\n  x-inclusion: <text>\n

                                                                                                                      where:

                                                                                                                      Property Required? Description Default value name No Internal reference to the feature style. It is recommended that the value be lower case and contain no spaces. Blank title No Human-readable name of the feature style. Exposed as a name for the group of rules contained in the feature style. Blank abstract No Longer description of the feature style. Blank transform No Rendering transformation information. N/A rules Yes List of styling rules. N/A

                                                                                                                      The following properties are equivalent to SLD \"vendor options\".

                                                                                                                      Property Required? Description Default value x-ruleEvaluation No When equals to first - stops rule evaluation after the first match. Can make the rendering more efficient by reducing the number of rules that need to be traversed by features, as well as simplyfing the rule filters. all x-composite No Allows for both alpha compositing and color blending options between buffers. There are many options; see below. N/A x-composite-base No Allows the rendering engine to use that feature-style as a \"base\", and will compose all subsequent feature-styles and layers on top of it, until another base is found. Once the full set of layers against a base is composed, then the base itself will be composed against the next set of composed layers using its own compositing operator, if present. This is useful to fine-tune the use of x-composite, and to make sure that only the desired content is composited/blended and not all of the drawn content. false x-inclusion No Define if rule should be included in style for legendOnly or mapOnly (see Rendering Selection) normal"},{"location":"styling/ysld/reference/featurestyles/#ysld_reference_featurestyles_composite","title":"Compositing and blending","text":"

                                                                                                                      By default, multiple feature styles are drawn with one buffer on top of the other. However, using the x-composite and x-composite-base options, one can customize the way that buffers are displayed.

                                                                                                                      The following two tables show the possible alpha compositing and color blending values for the x-composite option. Note that in the tables below, source refers to the buffer that is drawn on top, while destination refers to the buffer that the source is drawn on top of.

                                                                                                                      Todo

                                                                                                                      Add image showing source and destination

                                                                                                                      Alpha compositing

                                                                                                                      Alpha compositing controls how buffers are merged using the transparent areas of each buffer.

                                                                                                                      +--------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Value | Description | +====================+=============================================================================================================================================================================================================+ | copy | Only the source will be present in the output. | | | | | | | +--------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | destination | Only the destination will be present in the output. | | | | | | | +--------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | source-over | The source is drawn over the destination, and the destination is visible where the source is transparent. Opposite of destination-over. This is the default value for x-composite. | | | | | | | +--------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | destination-over | The source is drawn below the destination, and is visible only when the destination is transparent. Opposite of source-over. | | | | | | | +--------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | source-in | The source is visible only when overlapping some non-transparent pixel of the destination. This allows the background map to act as a mask for the layer/feature being drawn. Opposite of destination-in. | | | | | | | +--------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | destination-in | The destination is retained only when overlapping some non transparent pixel in the source. This allows the layer/feature to be drawn to act as a mask for the background map. Opposite of source-in. | | | | | | | +--------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | source-out | The source is retained only in areas where the destination is transparent. This acts as a reverse mask when compared to source-in. | | | | | | | +--------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | destination-out | The destination is retained only in areas where the source is transparent. This acts as a reverse mask when compared to destination-in. | | | | | | | +--------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | source-atop | The destination is drawn fully, while the source is drawn only where it intersects the destination. | | | | | | | +--------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | destination-atop | The source is drawn fully, and the destination is drawn over the source only where it intersects it. | | | | | | | +--------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | xor | \"Exclusive Or\" mode. Each pixel is rendered only if either the source or the destination is not blank, but not both. | | | | | | | +--------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+

                                                                                                                      Color blending

                                                                                                                      Color blending allows buffers to be mixed during composition.

                                                                                                                      +---------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Value | Description | +===============+========================================================================================================================================================================================================================================================================================================+ | multiply | The source color is multiplied by the destination color and replaces the destination. The resulting color is always at least as dark as either the source or destination color. Multiplying any color with black results in black. Multiplying any color with white preserves the original color. | | | | | | | +---------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | screen | Multiplies the complements of the source and destination color values, then complements the result. The end result color is always at least as light as either of the two constituent colors. Screening any color with white produces white; screening with black leaves the original color unchanged. | | | | | | | +---------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | overlay | Multiplies the colors depending on the destination color value. Source colors overlay the destination while preserving highlights and shadows. The backdrop color is not replaced but is mixed with the source color to reflect the lightness or darkness of the backdrop. | | | | | | | +---------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | darken | Selects the darker of the destination and source colors. The destination is replaced with the source only where the source is darker. | | | | | | | +---------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | lighten | Selects the lighter of the destination and source colors. The destination is replaced with the source only where the source is lighter. | | | | | | | +---------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | color-dodge | Brightens the destination color to reflect the source color. Drawing with black produces no changes. | | | | | | | +---------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | color-burn | Darkens the destination color to reflect the source color. Drawing with white produces no change. | | | | | | | +---------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | hard-light | Multiplies the colors, depending on the source color value. The effect is similar to shining a harsh spotlight on the destination. | | | | | | | +---------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | soft-light | Darkens or lightens the colors, depending on the source color value. The effect is similar to a diffused spotlight on the destination. | | | | | | | +---------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | difference | Subtracts the darker of the two constituent colors from the lighter color. White inverts the destination color; black produces no change. | | | | | | | +---------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | exclusion | Produces an effect similar to that of difference but lower in contrast. White inverts the destination color; black produces no change. | | | | | | | +---------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+

                                                                                                                      Note

                                                                                                                      For more details about the compositing and blending options, please see Composite and blending modes.

                                                                                                                      "},{"location":"styling/ysld/reference/featurestyles/#short-syntax","title":"Short syntax","text":"

                                                                                                                      When a style has a single feature style, it is possible to omit the syntax for the feature style and start at the first parameter inside.

                                                                                                                      So the following complete styles are both equivalent:

                                                                                                                      feature-styles:\n- rules:\n  - name: rule1\n    scale: [min,50000]\n    symbolizers:\n    - line:\n        stroke-color: '#000000'\n        stroke-width: 2\n  - name: rule2\n    scale: [50000,max]\n    symbolizers:\n    - line:\n        stroke-color: '#000000'\n        stroke-width: 1\n
                                                                                                                      rules:\n- name: rule1\n  scale: [min,50000]\n  symbolizers:\n  - line:\n      stroke-color: '#000000'\n      stroke-width: 2\n- name: rule2\n  scale: [50000,max]\n  symbolizers:\n  - line:\n      stroke-color: '#000000'\n      stroke-width: 1\n
                                                                                                                      "},{"location":"styling/ysld/reference/featurestyles/#examples","title":"Examples","text":""},{"location":"styling/ysld/reference/featurestyles/#road-casing","title":"Road casing","text":"

                                                                                                                      This example shows how a smaller line can be drawn on top of a larger line, creating the effect of lines being drawn with a border or \"casing\":

                                                                                                                      feature-styles:\n- name: outer\n  title: Outer line\n  rules:\n  - name: outer_rule\n    symbolizers:\n    - line:\n        stroke-color: '#808080'\n        stroke-width: 8\n- name: inner\n  title: Inner line\n  rules:\n  - name: inner_rule\n    symbolizers:\n    - line:\n        stroke-color: '#44FF88'\n        stroke-width: 6\n

                                                                                                                      To draw the inner lines always on top of the outer lines we need to control the z-order. The outer_rule is encased in its own feature style and drawn into a distinct \"Outer line\" buffer. Next the inner_rule is encased in its own feature style and drawn into a distinct \"Inner line\" buffer.

                                                                                                                      Feature style buffers

                                                                                                                      During composition these two off-screen buffers are combined into the final map.

                                                                                                                      Final map composition

                                                                                                                      When drawn, the outer line has a width of 8 pixels and the inner line has a width of 6 pixels, so the line \"border\" is 1 pixel (on each side).

                                                                                                                      Example showing road casing

                                                                                                                      "},{"location":"styling/ysld/reference/featurestyles/#first-match","title":"First match","text":"

                                                                                                                      Given a style that has many rules with distinct outcomes, it may be advantageous to employ x-ruleEvaluation: first so as to improve rendering efficiency and simplify those rules.

                                                                                                                      This first example shows the standard way of creating rules for a dataset. There are villages, towns, and cities (type = 'village', type = 'town' or type = 'city') and they have an industry which could be either fishing or other values.

                                                                                                                      Note

                                                                                                                      In order to simplify this example, the specifics of the point symbolizers have been replaced by Define and reuse YAML Variables. In a real-world example, these would need to be defined in the YSLD as well.

                                                                                                                      feature-styles:\n- name: without_first_match\n  rules:\n  - name: fishing_town\n    filter: ${type = 'town' AND industry = 'fishing'}\n    symbolizers:\n    - point:\n        <<: *fishingtown\n  - name: fishing_city\n    filter: ${type = 'city' AND industry = 'fishing'}\n    symbolizers:\n    - point:\n        <<: *fishingcity\n  - name: other_towns_cities\n    filter: ${type IN ('town', 'city') AND industry <> 'fishing'}\n    symbolizers:\n    - point:\n        <<: *othertownscities\n  - name: other\n    else: true\n    symbolizers:\n    - point:\n        <<: *allotherplaces\n

                                                                                                                      Using the x-ruleEvaluation: first parameter, the style is simplified:

                                                                                                                      feature-styles:\n- name: with_first_match\n  x-ruleEvaluation: first\n  rules:\n  - name: fishing_town\n    filter: ${type = 'town' AND industry = 'fishing'}\n    symbolizers:\n    - point:\n        <<: *fishingtown\n  - name: fishing_city\n    filter: ${type = 'city' AND industry = 'fishing'}\n    symbolizers:\n    - point:\n        <<: *fishingcity\n  - name: other_towns_cities\n    filter: ${type IN ('town', 'city')}\n    symbolizers:\n    - point:\n        <<: *othertownscities\n  - name: other\n    else: true\n    symbolizers:\n    - point:\n        <<: *allotherplaces\n

                                                                                                                      Specifically, the third rule no longer needs the extra AND industry <> 'fishing', because the previous two rules imply that any features remaining by this rule have that condition.

                                                                                                                      "},{"location":"styling/ysld/reference/featurestyles/#layer-mask","title":"Layer mask","text":"

                                                                                                                      Given two layers (in this case, two three-band rasters), one can mask or \"knock out\" the other, making visible what's beneath.

                                                                                                                      Top/source layer

                                                                                                                      Bottom/destination layer

                                                                                                                      Note

                                                                                                                      Screenshots show data provided by Natural Earth.

                                                                                                                      Layer 1 (top/source):

                                                                                                                      feature-styles:\n- rules:\n  - title: Top/source\n    symbolizers:\n    - raster:\n        opacity: 1.0\n  x-composite: xor\n

                                                                                                                      Layer 2 (bottom/destination):

                                                                                                                      feature-styles:\n- rules:\n  - title: Bottom/destination\n    symbolizers:\n    - raster:\n        opacity: 1.0\n

                                                                                                                      Layer as mask

                                                                                                                      "},{"location":"styling/ysld/reference/featurestyles/#color-inversion","title":"Color inversion","text":"

                                                                                                                      Given the same two layers as the previous example, one can display the difference of the colors of layers, which can have the effect of a color \"inversion\".

                                                                                                                      Layer 1 (top/source):

                                                                                                                      feature-styles:\n- rules:\n  - title: Top/source\n    symbolizers:\n    - raster:\n        opacity: 1.0\n  x-composite: difference\n

                                                                                                                      Layer 2 (bottom/destination):

                                                                                                                      feature-styles:\n- rules:\n  - title: Bottom/destination\n    symbolizers:\n    - raster:\n        opacity: 1.0\n

                                                                                                                      Layer as color inversion

                                                                                                                      "},{"location":"styling/ysld/reference/filters/","title":"Filters","text":"

                                                                                                                      Filters are predicates that allow rules to be applied selectively.

                                                                                                                      A filter can take a great many different forms.

                                                                                                                      Note

                                                                                                                      A scale is a type of filter, but is discussed separately.

                                                                                                                      Note

                                                                                                                      For more information, please see the GeoTools CQL documentation and GeoServer CQL tutorial.

                                                                                                                      "},{"location":"styling/ysld/reference/filters/#syntax","title":"Syntax","text":"

                                                                                                                      The basic syntax of a filter is:

                                                                                                                      rules:\n  ...\n  filter: ${<expression>}\n  ...\n

                                                                                                                      where <expression> is any valid CQL/ECQL filter.

                                                                                                                      Note

                                                                                                                      Be aware that filters are applied to rules and so appear inside them, but outside of any symbolizers.

                                                                                                                      "},{"location":"styling/ysld/reference/filters/#types-of-filters","title":"Types of filters","text":"

                                                                                                                      As mentioned above, the filter can be any valid construction made with CQL/ECQL (Extended/Contextual Query Language).

                                                                                                                      CQL is written using a familiar text-based syntax with strong similarities to SQL statements. One can think of a CQL expression as the \"WHERE\" clause of a SQL statement.

                                                                                                                      The following are all standard filter constructions:

                                                                                                                      "},{"location":"styling/ysld/reference/filters/#object-comparison","title":"Object comparison","text":"

                                                                                                                      This filter will test to see if a comparison to an attribute is true. It has the following form:

                                                                                                                      ${<attribute> <operator> <value>}\n

                                                                                                                      where:

                                                                                                                      Attribute Required? Description Default value <attribute> Yes That to which something is going to be compared. Typically an attribute name. May be case sensitive. N/A <operator> Yes Method of comparison. Valid operators are =, <, >, <=, >=, <>, LIKE, ILIKE, BETWEEN, IS NULL, IN. NOT can be added to invert the comparison. N/A <value> Yes That which the <attribute> is being compared to. Typically a static value such as a string or scalar, though can be an expression that evaluates to a static value. Can include mathematical operators such as +, -, *, /. Use single quotes for strings, as double-quotes will be interpreted as an attribute name. Omit quotes for scalar values. N/A

                                                                                                                      The following is a description of all available operators:

                                                                                                                      Operator Description = Equals < Less than (non-inclusive) > Greater than (non-inclusive) <= Less than or equal to (inclusive) >= Greater than or equal to (inclusive) LIKE Fuzzy matching for strings and other non-numeric attributes. Add % for multi-character wildcards, and _ for single-character wildcards. ILIKE Case-insensitive version of LIKE BETWEEN Tests if a value that is between two given values IS NULL For testing against a NULL value IN Used when specifying a list. Must be contained in the list for the statement to be true. NOT Negates a boolean (true/false) condition. Can be used with an additional operator such as NOT LIKE or NOT BETWEEN. <> Not equal (used when comparing a string or numeric value only)

                                                                                                                      Note

                                                                                                                      These operators are not case sensitive, but are shown here in all caps for legibility and consistency.

                                                                                                                      "},{"location":"styling/ysld/reference/filters/#spatial-filters","title":"Spatial filters","text":"

                                                                                                                      Filters can be spatial in nature. Any valid spatial construction in WKT (Well Known Text) can be used. Spatial filters include INTERSECTS, DISJOINT, CONTAINS, WITHIN, TOUCHES, CROSSES, EQUALS, DWITHIN, and BBOX. NOT can be added to negate the condition.

                                                                                                                      For more details about these spatial filters and their syntax, please see the GeoServer ECQL reference or uDig CQL reference.

                                                                                                                      "},{"location":"styling/ysld/reference/filters/#compound-statements","title":"Compound statements","text":"

                                                                                                                      The filter can be a combination of statements. A common case is testing if the value of an attribute is greater than one value but less than another.

                                                                                                                      The syntax for creating compound statements is to use standard Boolean notation such as AND, OR, and NOT along with relevant parentheses.

                                                                                                                      For example, a filter where both statements need to be true would be:

                                                                                                                      filter: ${<statement1> AND <statement2>}\n

                                                                                                                      A filter where either statement would need to be true would be:

                                                                                                                      filter: ${<statement1> OR <statement2>}\n

                                                                                                                      Larger filters can be built up in this way:

                                                                                                                      filter: ${(<statement1> OR <statement2>) AND <statement3> OR NOT <statement4>}\n

                                                                                                                      In these examples, every <statement> is a valid filter.

                                                                                                                      In terms of precedence, AND is evaluated first, followed by OR, unless modified by parentheses. So, in the last example above, (<statement1> OR <statement2>) will be evaluated first, followed by the result of that AND <statement3>, and finally the result of that with OR NOT <statement4>.

                                                                                                                      "},{"location":"styling/ysld/reference/filters/#examples","title":"Examples","text":"

                                                                                                                      Filter size based on an attribute

                                                                                                                      Filters are used to style different features of a layer based on certain conditions. The ILIKE operator is used to compare two strings (ignoring case) to see if they are similar. When using LIKE or ILIKE, the % character matches any number of letters (So %hwy matches any streetname ending in hwy). This example uses filters to distinguish between Highways, Roads, and other streets, and draw them using different colors and sizes:

                                                                                                                      feature-styles:\n- rules:\n  - filter: ${streetname ILIKE '%hwy'}\n      symbolizers:\n      - line:\n          stroke-color: '#007799'\n          stroke-width: 8\n  - filter: ${streetname ILIKE '%rd'}\n      symbolizers:\n      - line:\n          stroke-color: '#00AA00'\n          stroke-width: 4\n  - else: true\n      symbolizers:\n      - line:\n          stroke-color: black\n          stroke-width: 2\n

                                                                                                                      Filter based on road types

                                                                                                                      Filter color based on attribute value

                                                                                                                      Filters can also be used to color a map based on attributes of the data. The following example uses the YEARBLT attribute to color different lots based on the year they were built. The else rule applies only if no other filter rule applies

                                                                                                                      Note

                                                                                                                      The Recode function can perform the same functionality in a more compact syntax.

                                                                                                                      name: Year Built Filter feature-styles: - rules: - filter: ${YEARBLT > 2000} symbolizers: - polygon: stroke-color: '#000000' stroke-width: 0.5 fill-color: '#00FF00' - filter: ${YEARBLT > 1990 AND YEARBLT < 2000} symbolizers: - polygon: stroke-color: '#000000' stroke-width: 0.5 fill-color: '#22DD00' - filter: ${YEARBLT > 1980 AND YEARBLT < 1990} symbolizers: - polygon: stroke-color: '#000000' stroke-width: 0.5 fill-color: '#44BB00' - filter: ${YEARBLT > 1970 AND YEARBLT < 1980} symbolizers: - polygon: stroke-color: '#000000' stroke-width: 0.5 fill-color: '#668800' - else: true symbolizers: - polygon: stroke-color: '#000000' stroke-width: 0.5 fill-color: '#DD4400'

                                                                                                                      Filter based on attribute value

                                                                                                                      Filter by bounding box

                                                                                                                      Spatial filters can be used to filter a layer based on its geometry. The bbox filter can be used to select features that are contained within a bounding box. This example colors polygons orange within the bounding box, and blue outside the bounding box:

                                                                                                                      name: Spatial Filter\nfeature-styles:\n- name: name\n  rules:\n  - filter: bbox(the_geom, -122.9, 42.36, -122.85, 42.28)\n    symbolizers:\n    - polygon:\n         fill-color: '#99CC00'\n  - else: true\n    symbolizers:\n    - polygon:\n         fill-color: '#0099CC'\n

                                                                                                                      Detail of bbox filter

                                                                                                                      Filter by arbitrary geometries

                                                                                                                      Spatial filters can also be used to compare layer geometries against arbitrary geometries, not just bounding boxes. In this example, the within filter is used to select all buildings inside a triangular region defined using Well-Known Text (WKT) and color them green. All other features are colored blue:

                                                                                                                      feature-styles:\n- name: name\n  rules:\n  - filter: within(the_geom, POLYGON ((-122.9075 42.3625, -122.8225 42.3625, -122.8268 42.2803, -122.9075 42.3625)))\n    symbolizers:\n    - polygon:\n        fill-color: '#00CC00'\n  - else: true\n    symbolizers:\n    - polygon:\n        fill-color: '#0099CC'\n

                                                                                                                      Filter using within

                                                                                                                      "},{"location":"styling/ysld/reference/functions/","title":"Functions","text":"

                                                                                                                      Functions are additional operations that can be employed when calculating values for YSLD parameters. In most cases, a value for a parameter can be the output (result) of a function.

                                                                                                                      Functions can be used in most places in a style document.

                                                                                                                      "},{"location":"styling/ysld/reference/functions/#syntax","title":"Syntax","text":"

                                                                                                                      Functions aren't a parameter to itself, but instead are used as a part of the values of a parameter, or indeed in any expression. So the syntax is very general, for example:

                                                                                                                      <parameter>: ${<function>}\n

                                                                                                                      Functions are evaluated at rendering time, so the output is passed as the parameter value and then rendered accordingly.

                                                                                                                      "},{"location":"styling/ysld/reference/functions/#list-of-functions","title":"List of functions","text":"

                                                                                                                      A reference list of functions can be found in the GeoServer User Manual and is also available in raw form in the GeoTools User Manual Function List.

                                                                                                                      The functions can be broken up loosely into categories such as geometric, math, and string functions.

                                                                                                                      "},{"location":"styling/ysld/reference/functions/#ysld_reference_functions_theming","title":"Theming functions","text":"

                                                                                                                      There are three important functions that are often easier to use for theming than using rules, and can vastly simplify your style documents: Recode, Categorize, and Interpolate.

                                                                                                                      Recode: Attribute values are directly mapped to styling properties:

                                                                                                                      recode(attribute,value1,result1,value2,result2,value3,result3,...)\n

                                                                                                                      This is equivalent to creating multiple rules with similar filters:

                                                                                                                      rules:\n- ...\n  filter: ${attribute = value1}\n  - ...\n    <property>: result1\n- ...\n  filter: ${attribute = value2}\n  - ...\n    <property>: result2\n- ...\n  filter: ${attribute = value3}\n  - ...\n    <property>: result3\n

                                                                                                                      Categorize: Categories are defined using minimum and maximum ranges, and attribute values are sorted into the appropriate category:

                                                                                                                      categorize(attribute,category0,value1,category1,value2,category2,...,belongsTo)\n

                                                                                                                      This would create a situation where the attribute value, if less than value1 will be given the result of category0; if between value1 and value2, will be given the result of category1; if between value2 and value3, will be given the result of category2, etc. Values must be in ascending order.

                                                                                                                      The belongsTo argument is optional, and can be either succeeding or preceding. It defines which interval to use when the lookup value equals the attribute value. If the attribute value is equal to value1 and suceeding is used, then the result will be category1. If preceding is used then the result will be category0. The default is succeeding.

                                                                                                                      This is equivalent to creating the following multiple rules:

                                                                                                                      rules:\n- ...\n  filter: ${attribute < value1}\n  - ...\n    <property>: category0\n- ...\n  filter: ${attribute >= value1 AND attribute < value2}\n  - ...\n    <property>: category1\n- ...\n  filter: ${attribute >= value2}\n  - ...\n    <property>: category2\n

                                                                                                                      Interpolate: Used to smoothly theme quantitative data by calculating a styling property based on an attribute value. This is similar to Categorize, except that the values are continuous and not discrete:

                                                                                                                      interpolate(attribute,value1,entry1,value2,entry2,...,mode,method)\n

                                                                                                                      This would create a situation where the attribute value, if equal to value1 will be given the result of entry1; if halfway between value1 and value2 will be given a result of halfway in between entry1 and entry2; if three-quarters between value1 and value2 will be given a result of three-quarters in between entry1 and entry2, etc.

                                                                                                                      The mode argument is optional, and can be either linear, cosine, or cubic. It defines the interpolation algorithm to use, and defaults to linear.

                                                                                                                      The method argument is optional, and can be either numeric or color. It determines whether entry1, entry2, ... are numbers or colors, and defaults to numeric.

                                                                                                                      There is no equivalent to this function in vector styling. The closest to this in raster styling is the color ramp.

                                                                                                                      The three theming functions can be neatly summarized by this table:

                                                                                                                      Function Type of input Type of output Recode Discrete Discrete Categorize Continuous Discrete Interpolate Continuous Continuous"},{"location":"styling/ysld/reference/functions/#examples","title":"Examples","text":""},{"location":"styling/ysld/reference/functions/#display-rotated-arrows-at-line-endpoints","title":"Display rotated arrows at line endpoints","text":"

                                                                                                                      The startPoint(geom) and endPoint(geom) functions take a geometry as an argument and returns the start and end points of the geometry respectively. The startAngle(geom) and endAngle(geom) functions take a geometry as an argument and return the angle of the line terminating at the start and end points of the geometry respectively. These functions can be used to display an arrow at the end of a line geometry, and rotate it to match the direction of the line:

                                                                                                                      feature-styles:\n- rules:\n  - symbolizers:\n      - line:\n          stroke-width: 1\n      - point:\n          geometry: ${endPoint(geom)}\n          rotation: ${endAngle(geom)}\n          size: 24\n          symbols:\n          - mark:\n              shape: 'shape://carrow'\n              fill-color: '#000000'\n

                                                                                                                      Endpoint arrows

                                                                                                                      "},{"location":"styling/ysld/reference/functions/#drop-shadow","title":"Drop shadow","text":"

                                                                                                                      The offset(geom, x, y) function takes a geometry and two values, and displaces the geometry by those values in the x and y directions. This can be used to create a drop-shadow effect:

                                                                                                                      feature-styles:\n- name: shadow\n  rules:\n  - symbolizers:\n    - polygon:\n        stroke-width: 0.0\n        fill-color: '#000000'\n        fill-opacity: 0.75\n        geometry: ${offset(geom, 0.0001, -0.0001)}\n- name: fill\n  rules:\n  - symbolizers:\n    - polygon:\n      stroke-width: 0.0\n      fill-color: '#00FFFF'\n

                                                                                                                      Drop shadow

                                                                                                                      "},{"location":"styling/ysld/reference/functions/#different-colored-outline","title":"Different-colored outline","text":"

                                                                                                                      The buffer(geom, buffer) function takes a geometry and a value as arguments, and returns a polygon geometry with a boundary equal to the original geometry plus the value. This can be used to generate an extended outline filled with a different color, for example to style a shoreline:

                                                                                                                      feature-styles:\n- name: shoreline\n  rules:\n  - polygon:\n      fill-color: '#00BBFF'\n      geometry: ${buffer(geom, 0.00025)}\n- name: land\n  rules:\n  - polygon:\n      fill-color: '#00DD00'\n

                                                                                                                      Buffered outline

                                                                                                                      See also:

                                                                                                                      • convexHull(geom)
                                                                                                                      • octagonalEnvelope(geom)
                                                                                                                      • mincircle(geom)
                                                                                                                      • minrectangle(geom)
                                                                                                                      • minimumdiameter(geom)
                                                                                                                      "},{"location":"styling/ysld/reference/functions/#display-vertices-of-a-line","title":"Display vertices of a line","text":"

                                                                                                                      The vertices(geom) function takes a geometry and returns a collection of points representing the vertices of the geometry. This can be used to convert a polygon or line geometry into a point geometry:

                                                                                                                      point:\n  geometry: vertices(geom)\n

                                                                                                                      Endpoint arrows

                                                                                                                      See also:

                                                                                                                      • boundary(geom)
                                                                                                                      • centroid(geom)
                                                                                                                      "},{"location":"styling/ysld/reference/functions/#angle-between-two-points","title":"Angle between two points","text":"

                                                                                                                      The atan2(x, y) function calculates the arctangent of (y/x) and so is able to determine the angle (in radians) between two points. This function uses the signs of the x and y values to determine the computed angle, so it is preferable over atan(). The getX(point_geom) and getY(point_geom) extracts the x and y ordinates from a geometry respectively, while toDegrees(value) converts from radians to degrees:

                                                                                                                      point:\n  symbols:\n  - mark:\n      shape: triangle\n  rotation: ${toDegrees(atan2(\n    getX(startPoint(the_geom))-getX(endPoint(the_geom)),\n    getY(startPoint(the_geom))-getY(endPoint(the_geom))))}\n

                                                                                                                      See also:

                                                                                                                      • sin(value)
                                                                                                                      • cos(value)
                                                                                                                      • tan(value)
                                                                                                                      • asin(value)
                                                                                                                      • acos(value)
                                                                                                                      • atan(value)
                                                                                                                      • toRadians(value)
                                                                                                                      • pi()
                                                                                                                      "},{"location":"styling/ysld/reference/functions/#scale-objects-based-on-a-large-range-of-values","title":"Scale objects based on a large range of values","text":"

                                                                                                                      The log(value) function returns the natural logarithm of the provided value. Use log(value)/log(base) to specify a different base.

                                                                                                                      For example, specifying log(population)/log(2) will make the output increase by 1 when the value of population doubles. This allows one to display relative sizes on a consistent scale while still being able to represent very small and very large populations:

                                                                                                                      point:\n  symbols:\n  - mark:\n      shape: circle\n  size: ${log(population)/log(2)}\n

                                                                                                                      See also:

                                                                                                                      • exp(val)
                                                                                                                      • pow(base,exponent)
                                                                                                                      • sqrt(val)
                                                                                                                      "},{"location":"styling/ysld/reference/functions/#combine-several-strings-into-one","title":"Combine several strings into one","text":"

                                                                                                                      The Concatenate(string1, string2, ...) function takes any number of strings and combines them to form a single string. This can be used to display more than one attribute within a single label:

                                                                                                                      text:\n  label: ${Concatenate(name, ', ', population)}\n
                                                                                                                      "},{"location":"styling/ysld/reference/functions/#capitalize-words","title":"Capitalize words","text":"

                                                                                                                      The strCapitalize(string) function takes a single string and capitalizes the first letter of each word in the string. This could be used to capitalize labels created from lower case text:

                                                                                                                      text:\n  label: ${strCapitalize(name)}\n

                                                                                                                      See also:

                                                                                                                      • strToLowerCase(string)
                                                                                                                      • strToUpperCase(string)
                                                                                                                      "},{"location":"styling/ysld/reference/functions/#color-based-on-discrete-values","title":"Color based on discrete values","text":"

                                                                                                                      In certain cases, theming functions can be used in place of filters to produce similar output much more simply. For example, the Recode function can take an attribute and output a different value based on an attribute value. So instead of various filters, the entire constructions can be done in a single line. For example, this could be used to color different types of buildings:

                                                                                                                      feature-styles:\n- name: name\n  rules:\n  - symbolizers:\n    - polygon:\n        fill-color: \n          ${recode(zone, \n          'I-L', '#FF7700', \n          'I-H', '#BB6600', \n          'C-H', '#0077BB', \n          'C-R', '#00BBDD', \n          'C-C', '#00DDFF', \n          '', '#777777')}\n

                                                                                                                      In the above example, the attribute is zone , and then each subsequent pair consists of an attribute value followed by a color.

                                                                                                                      Recode Function

                                                                                                                      "},{"location":"styling/ysld/reference/functions/#color-based-on-categories","title":"Color based on categories","text":"

                                                                                                                      The Categorize function returns a different value depending on which range (category) an attribute value matches. This can also make a style much more simple by reducing the number of filters. This example uses categorize to color based on certain values of the YEARBLT attribute:

                                                                                                                      feature-styles:\n- name: name\n  rules:\n  - symbolizers:\n     - polygon:\n        stroke-color: '#000000'\n        stroke-width: 0.5\n        fill-color:\n          ${categorize(YEARBLT, '#DD4400', \n          1950,'#AA4400',\n          1960,'#886600',\n          1970,'#668800',\n          1980,'#44BB00',\n          1990,'#22DD00',\n          2000,'#00FF00')}\n

                                                                                                                      Categorize Function

                                                                                                                      "},{"location":"styling/ysld/reference/functions/#choropleth-map","title":"Choropleth map","text":"

                                                                                                                      The interpolate function can be used to create a continuous set of values by interpolating between attribute values. This can be used to create a choropleth map which shows different colors for regions based on some continuous attribute such as area or population:

                                                                                                                      feature-styles:\n- name: name\n  rules:\n  - title: fill-graphic\n    symbolizers:  \n    - polygon:\n        stroke-width: 1\n        fill-color: ${interpolate(PERSONS, 0.0, '#00FF00', 1e7,'#FF0000', 'color')}\n

                                                                                                                      Choropleth Map

                                                                                                                      "},{"location":"styling/ysld/reference/rules/","title":"Rules","text":"

                                                                                                                      A rule is a collection of styling directives, primarily consisting of symbolizers combined with optional conditional statements.

                                                                                                                      • If a conditional statement exists in a rule, then the styling directives will only be carried out if the conditional returns true. Otherwise, the rule will be skipped.
                                                                                                                      • If no conditional statement exists in a rule, then the styling directive will always be carried out.

                                                                                                                      Todo

                                                                                                                      FIGURE NEEDED

                                                                                                                      The types of conditional statements available to rules are:

                                                                                                                      • Filters for attribute-based rendering
                                                                                                                      • Scale for scale-based rendering

                                                                                                                      Rules are contained within feature styles. There is no limit on the number of rules that can be created, and there is no restriction that all rules must be mutually exclusive (as in, some rules may apply to the same features).

                                                                                                                      "},{"location":"styling/ysld/reference/rules/#syntax","title":"Syntax","text":"

                                                                                                                      The following is the basic syntax of a rule. Note that the contents of the block are not all expanded; see the other sections for the relevant syntax.

                                                                                                                      rules:\n- name: <text>\n  title: <text>\n  filter: <filter>\n  else: <boolean>\n  scale: [<min>,<max>]\n  symbolizers:\n  - ...\n  x-inclusion: <text>\n

                                                                                                                      where:

                                                                                                                      Property Required? Description Default value name No Internal reference to the feature style. It is recommended that the value be lower case and contain no spaces. Blank title No Human-readable description of what the rule accomplishes. Blank filter No Filter expression which will need to evaluate to be true for the symbolizer(s) to be applied. Cannot be used with else. Blank (meaning that the rule will apply to all features) else No Specifies whether the rule will be an \"else\" rule. An else rule applies when, after scale and filters are applied, no other rule applies. To make an else rule, set this option to true. Cannot be used with filter. false scale No Scale boundaries showing at what scales (related to zoom levels) the rule will be applied. Visible at all scales symbolizers Yes Block containing one or more symbolizers. These contain the actual visualization directives. If the filter returns true and the view is within the scale boundaries, these symbolizers will be drawn. N/A x-inclusion No Define if rule should be included in style for legendOnly or mapOnly (see Rendering Selection) normal"},{"location":"styling/ysld/reference/rules/#short-syntax","title":"Short syntax","text":"

                                                                                                                      When a style has a single rule inside a single feature style, it is possible to omit the syntax for both and start at the first parameter inside.

                                                                                                                      So the following complete styles are equivalent:

                                                                                                                      feature-styles:\n- rules:\n  - symbolizers:\n    - line:\n        stroke-color: '#000000'\n        stroke-width: 2\n\nline:\n  stroke-color: '#000000'\n  stroke-width: 2\n
                                                                                                                      "},{"location":"styling/ysld/reference/rules/#examples","title":"Examples","text":""},{"location":"styling/ysld/reference/rules/#else-filter","title":"Else filter","text":"

                                                                                                                      Using filter and else together:

                                                                                                                      rules:\n- name: small\n  title: Small features\n  filter: ${type = 'small'}\n  symbolizers:\n  - ...\n- name: large\n  title: Large features\n  filter: ${type = 'large'}\n  symbolizers:\n  - ...\n- name: else\n  title: All other features\n  else: true\n  symbolizers:\n  - ...\n

                                                                                                                      In the above situation:

                                                                                                                      • If a feature has a value of \"small\" in its type attribute, it will be styled with the \"small\" rule.
                                                                                                                      • If a feature has a value of \"large\" in its type attribute, it will be styled with the \"large\" rule.
                                                                                                                      • If a feature has a value of \"medium\" (or anything else) in its type attribute, it will be styled with the \"else\" rule.
                                                                                                                      "},{"location":"styling/ysld/reference/rules/#else-with-scale","title":"Else with scale","text":"

                                                                                                                      Using filter, else, and scale together:

                                                                                                                      rules:\n- name: small_zoomin\n  scale: [min,10000]\n  title: Small features when zoomed in\n  filter: ${type = 'small'}\n  symbolizers:\n  - ...\n- name: small_zoomout\n  scale: [10000,max]\n  title: Small features when zoomed out\n  filter: ${type = 'small'}\n  symbolizers:\n  - ...\n- name: else_zoomin\n  scale: [min,10000]\n  title: All other features when zoomed in\n  else: true\n  symbolizers:\n  - ...\n- name: else_zoomout\n  scale: [10000,max]\n  title: All other features when zoomed out\n  else: true\n  symbolizers:\n  - ...\n

                                                                                                                      In the above situation:

                                                                                                                      • If a feature has a value of \"small\" in its type attribute, and the map is a scale level less than 10,000, it will be styled with the \"small_zoomin\" rule.
                                                                                                                      • If a feature has a value of anything else other than \"small\" in its type attribute, and the map is a scale level less than 10,000, it will be styled with the \"else_zoomin\" rule.
                                                                                                                      • If a feature has a value of \"small\" in its type attribute, and the map is a scale level greater than 10,000, it will be styled with the \"small_zoomout\" rule.
                                                                                                                      • If a feature has a value of anything else other than \"small\" in its type attribute, and the map is a scale level greater than 10,000, it will be styled with the \"else_zoomout\" rule.
                                                                                                                      "},{"location":"styling/ysld/reference/scalezoom/","title":"Scale and zoom","text":"

                                                                                                                      It is common for different rules to be applied at different zoom levels on a web map.

                                                                                                                      For example, on a roads layer, you would not want to display every single road when viewing the whole world. Or perhaps you may wish to styles the same features differently depending on the zoom level. For example: a cities layer styled using points at low zoom levels (when \"zoomed out\") and with polygon borders at higher zoom levels (\"zoomed in\").

                                                                                                                      Todo

                                                                                                                      ADD FIGURE

                                                                                                                      YSLD allows rules to be applied depending on the scale or zoom level. You can specify by scale, or you can define zoom levels in terms of scales and specify by zoom level.

                                                                                                                      Warning

                                                                                                                      Be aware that scales for a layer (where a style is applied) may interact differently when the layer is contained in a map, if the map has a different coordinate reference system from the layer.

                                                                                                                      "},{"location":"styling/ysld/reference/scalezoom/#scale-syntax","title":"Scale syntax","text":"

                                                                                                                      The syntax for using a scale conditional parameter in a rule is:

                                                                                                                      rules:\n- ...\n  scale: [<min>,<max>]\n  ...\n

                                                                                                                      where:

                                                                                                                      Attribute Required? Description Default value min Yes The minimum scale (inclusive) for which the rule will be applied. Value is a number, either decimal or integer. N/A max Yes The maximum scale (exclusive) for which the rule will be applied. Value is a number, either decimal or integer. N/A

                                                                                                                      Note

                                                                                                                      It is not possible to use an expression for any of these values.

                                                                                                                      Use the literal strings min and max to denote where there are no lower or upper scale boundaries. For example, to denote that the scale is anything less than some <max> value:

                                                                                                                      scale: [min,<max>]\n

                                                                                                                      To denote that the scale is anything greater than or equal to some <min> value:

                                                                                                                      scale: [<min>,max]\n

                                                                                                                      Note

                                                                                                                      In the above examples, min and max are always literals, entered exactly like that, while <min> and <max> would be replaced by actual scalar values.

                                                                                                                      If the scale parameter is omitted entirely, then the rule will apply at all scales.

                                                                                                                      "},{"location":"styling/ysld/reference/scalezoom/#scale-examples","title":"Scale examples","text":"

                                                                                                                      Three rules, all applicable at different scales:

                                                                                                                      rule:\n- name: large_scale\n  scale: [min,100000]\n  symbolizers:\n  - line:\n      stroke-width: 3\n      stroke-color: '#0165CD'\n- name: medium_scale\n  scale: [100000,200000]\n  symbolizers:\n  - line:\n      stroke-width: 2\n      stroke-color: '#0165CD'\n- name: small_scale\n  scale: [200000,max]\n  symbolizers:\n  - line:\n      stroke-width: 1\n      stroke-color: '#0165CD'\n

                                                                                                                      This example will display lines with:

                                                                                                                      • A stroke width of 3 at scales less than 100,000 (large_scale)
                                                                                                                      • A stroke width of 2 at scales between 100,000 and 200,000 (medium_scale)
                                                                                                                      • A stroke width of 1 at scales greater than 200,000 (small_scale)

                                                                                                                      Given the rules above, the following arbitrary sample scales would map to the rules as follows:

                                                                                                                      Scale Rule 50000 large_scale 100000 medium_scale 150000 medium_scale 200000 small_scale 300000 small_scale

                                                                                                                      Note the edge cases, since the min value is inclusive and the max value is exclusive.

                                                                                                                      "},{"location":"styling/ysld/reference/scalezoom/#scientific-notation-for-scales","title":"Scientific notation for scales","text":"

                                                                                                                      To make comprehension easier and to lessen the chance of errors, scale values can be expressed in scientific notation.

                                                                                                                      So a scale of 500000000, which is equal to 5 \u00d7 10\\^8 (a 5 with eight zeros), can be replaced by 5e8.

                                                                                                                      "},{"location":"styling/ysld/reference/scalezoom/#relationship-between-scale-and-zoom","title":"Relationship between scale and zoom","text":"

                                                                                                                      When working with web maps, often it is more convenient to talk about zoom levels instead of scales. The relationship between zoom and scale is context dependent.

                                                                                                                      For example, for EPSG:4326 with world boundaries, zoom level 0 (completely zoomed out) corresponds to a scale of approximately 279,541,000 with each subsequent zoom level having half the scale value. For EPSG:3857 (Web Mercator) with world boundaries, zoom level 0 corresponds to a scale of approximately 559,082,000, again with each subsequent zoom level having half the scale value.

                                                                                                                      But since zoom levels are discrete (0, 1, 2, etc.) and scale levels are continuous, it's actually a range of scale levels that corresponds to a given zoom level.

                                                                                                                      For example, if you have a situation where a zoom level 0 corresponds to a scale of 1,000,000 (and each subsequent zoom level is half that scale, as is common), you can set the scale values of your rules to be:

                                                                                                                      • scale: [750000,1500000] (includes 1,000,000)
                                                                                                                      • scale: [340000,750000] (includes 500,000)
                                                                                                                      • scale: [160000,340000] (includes 250,000)
                                                                                                                      • scale: [80000,160000] (includes 125,000)
                                                                                                                      • etc.

                                                                                                                      Also be aware of the inverse relationship between scale and zoom; as the zoom level increases, the scale decreases.

                                                                                                                      "},{"location":"styling/ysld/reference/scalezoom/#zoom-syntax","title":"Zoom syntax","text":"

                                                                                                                      In certain limited cases, it can be more useful to specify scales by way of zoom levels for predefined gridsets. These can be any predefined gridsets in GeoServer.

                                                                                                                      Inside a rule, the syntax for using zoom levels is:

                                                                                                                      rules:\n- ...\n  zoom: [<min>, <max>]\n  ...\n

                                                                                                                      where:

                                                                                                                      Attribute Required? Description Default value min Yes The minimum zoom level for which the rule will be applied. Value is an integer. N/A max Yes The maximum zoom level for which the rule will be applied. Value is an integer. N/A

                                                                                                                      Note

                                                                                                                      It is not possible to use an expression for any of these values.

                                                                                                                      As with scales, use the literal strings min and max to denote where there are no lower or upper scale boundaries. For example, to denote that the zoom level is anything less than some <max> value:

                                                                                                                      zoom: [min,<max>]\n

                                                                                                                      To denote that the zoom level is anything greater than or equal to some <min> value:

                                                                                                                      zoom: [<min>,max]\n

                                                                                                                      Note

                                                                                                                      In the above examples, min and max are always literals, entered exactly like that, while <min> and <max> would be replaced by actual scalar values.

                                                                                                                      The scale and zoom parameters should not be used together in a rule (but if used, scale takes priority over zoom).

                                                                                                                      "},{"location":"styling/ysld/reference/scalezoom/#specifying-a-grid","title":"Specifying a grid","text":"

                                                                                                                      While every web map can have zoom levels, the specific relationship between a zoom level and its scale is dependent on the gridset (spatial reference system, extent, etc.) used.

                                                                                                                      So when specifying zoom levels in YSLD, you should also specify the grid.

                                                                                                                      The grid parameter should remain at the top of the YSLD content, above any Feature Styles or Rules. The syntax is:

                                                                                                                      grid:\n  name: <string>\n

                                                                                                                      where:

                                                                                                                      Property Required? Description Default value name No WGS84, WebMercator, or a name of a predefined gridset in GeoServer. WebMercator

                                                                                                                      Note

                                                                                                                      As many web maps use \"web mercator\" (also known as EPSG:3857 or EPSG:900913), this is assumed to be the default if no grid is specified.

                                                                                                                      Warning

                                                                                                                      As multiple gridsets can contain the same SRS, we recommend naming custom gridsets by something other than the EPSG code.

                                                                                                                      "},{"location":"styling/ysld/reference/scalezoom/#zoom-examples","title":"Zoom examples","text":""},{"location":"styling/ysld/reference/scalezoom/#default-gridset","title":"Default gridset","text":"

                                                                                                                      Given the default of web mercator (also known as EPSG:3857 or EPSG:900913), which requires no grid designation, this defines zoom levels as the following scale levels (rounded to the nearest whole number below):

                                                                                                                      Scale Zoom level 559082264 0 279541132 1 139770566 2 69885283 3 34942641 4 17471321 5 8735660 6 4367830 7 2183915 8 <previous_scale> / 2 <previous_zoom> + 1"},{"location":"styling/ysld/reference/scalezoom/#named-gridsets","title":"Named gridsets","text":"

                                                                                                                      For the existing gridset of WGS84 (often known as EPSG:4326):

                                                                                                                      grid:\n  name: WGS84\n

                                                                                                                      This defines zoom levels as the following scale levels (rounded to the nearest whole number below):

                                                                                                                      Scale Zoom level 559082264 0 279541132 1 139770566 2 69885283 3 34942641 4 17471321 5 8735660 6 4367830 7 2183915 8 <previous_scale> / 2 <previous_zoom> + 1

                                                                                                                      Given a custom named gridset called NYLongIslandFtUS, defined by a CRS of EPSG:2263 and using its full extent:

                                                                                                                      grid:\n  name: NYLongIslandFtUS\n

                                                                                                                      This defines zoom levels as the following (rounded to the nearest whole number below):

                                                                                                                      Scale Zoom level 4381894 0 2190947 1 1095473 2 547736 3 273868 4 136934 5 68467 6 34234 7 17117 8 <previous_scale> / 2 <previous_zoom> + 1

                                                                                                                      Note

                                                                                                                      These scale values can be verified in GeoServer on the Gridsets page under the definition for the gridset:

                                                                                                                      Gridset defined in GeoServer

                                                                                                                      Specifically, note the Scale values under Tile Matrix Set.

                                                                                                                      "},{"location":"styling/ysld/reference/structure/","title":"Structure","text":"

                                                                                                                      Here is a simple example of a YSLD style containing a single rule inside a single feature style:

                                                                                                                      name: style_example\ntitle: An example of YSLD styling\nabstract: Used in the User Manual of GeoServer\nfeature-styles:\n- rules:\n  - name: all\n    title: Every feature will be styled this way\n    symbolizers:\n    - polygon:\n        fill-color: '#808080'\n        fill-opacity: 0.5\n        stroke-color: '#000000'\n        stroke-opacity: 0.75\n

                                                                                                                      This would style every polygon feature in a given layer with the given RGB color codes (a medium gray for a fill and black for the outline), with the given opacities for both fill and stroke being given in decimals indicating percentage (so 0.5 is 50% opaque).

                                                                                                                      Note

                                                                                                                      For more details on syntax, please see the section on symbolizers.

                                                                                                                      The structure of a typical YSLD file is as follows:

                                                                                                                      +--------------------------------------+-----------------------------------------------------------------------------------------------------+ | Structure | Description | +======================================+=====================================================================================================+ | Variable definitions | For common style settings | +--------------------------------------+-----------------------------------------------------------------------------------------------------+ | Scale grid / zoom levels | Used to define style based on tile set zoom level | +--------------------------------------+-----------------------------------------------------------------------------------------------------+ | style header | Document name, title, and abstract followed by feature-styles | | | | | | | +--------------------------------------+-----------------------------------------------------------------------------------------------------+ | feature style | Independent block that can contain one or many rules. | | | | | | | +--------------------------------------+-----------------------------------------------------------------------------------------------------+ | rule | Directive that can contain one or many symbolizers. | | | | | | | +--------------------------------------+-----------------------------------------------------------------------------------------------------+ | filter | A rule \"includes\" all features unless made to be selective by the use of a filter. | | | | | | | +--------------------------------------+-----------------------------------------------------------------------------------------------------+ | symbolizers | basic unit of a style containing the actual visualization instructions for individual features. | +--------------------------------------+-----------------------------------------------------------------------------------------------------+

                                                                                                                      The structure YSLD files is outlined using indentation.

                                                                                                                      Structure of YSLD style_example

                                                                                                                      "},{"location":"styling/ysld/reference/structure/#property-syntax","title":"Property syntax","text":"

                                                                                                                      Individual statements (or directives) in a YSLD styling document are designed as key-value, or property-value pairs of the following form:

                                                                                                                      <property>: <value>\n

                                                                                                                      The <property> is a string denoting the property name, while the <value> can be one of a number of different types depending on context. These different types require slightly different markup, as shown in the following table:

                                                                                                                      +-------------------------------------------+------------------------------+----------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Type | Syntax | Example | Notes | +===========================================+==============================+======================+=========================================================================================================================================================================================================================================================================================================================+ | Integer | Value only | 12 | Quotes allowed as well | +-------------------------------------------+------------------------------+----------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Float | Value only | 0.75 | Quotes allowed as well | +-------------------------------------------+------------------------------+----------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Text | Quotes | Title | Spaces, colons, and other special characters are allowed. If value is ambiguous, use single quotes. | +-------------------------------------------+------------------------------+----------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Color | - '# + six digits' (hex) | - '#FF00FF' | Used when specifying RGB colors. For hex, use '#RRGGBB' with each two character pair having a value from 00 to FF. For decimal, use rgb(rrr,ggg,bbb) with each ordinate having a value from 0 to 255. Quotes are not required when using named colors. | | | - rgb(r,g,b) (decimal) | - rgb(255,0,255) | | | | - Text (named colors) | - fuchsia | | +-------------------------------------------+------------------------------+----------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Tuple | Brackets | [0,15000] | Use two single quotes to denote blank entries in the tuple (for example: ['#FFFFFF',0,0,'']). | +-------------------------------------------+------------------------------+----------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Filter or other expression | \\${} | ${type = road} | If attribute name is ambiguous, encase in brackets (for example: ${[type] = road}). If value is ambiguous, use single quotes (${type = 'road'}). | +-------------------------------------------+------------------------------+----------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+"},{"location":"styling/ysld/reference/structure/#expressions","title":"Expressions","text":"

                                                                                                                      Throughout the reference guide, there are references to values that are denoted by <expression>. An expression is a flexible term meaning that the value can be one of the following kinds of objects:

                                                                                                                      • Literal (scalar or string)
                                                                                                                      • Attribute name
                                                                                                                      • Function

                                                                                                                      If using a function, it must evaluate to match the type expected by the property.

                                                                                                                      "},{"location":"styling/ysld/reference/structure/#mappings-and-lists","title":"Mappings and lists","text":"

                                                                                                                      Note

                                                                                                                      The following discussion is taken from basic YAML syntax. Please refer to the YAML specification if necessary.

                                                                                                                      There are three types of objects in a YSLD document:

                                                                                                                      1. Scalar, a simple value
                                                                                                                      2. Mapping, a collection of key-value (property-value) pairs
                                                                                                                      3. List, any collection of objects. A list can contain mappings, scalars, and even other lists.

                                                                                                                      Lists require dashes for every entry, while mappings do not.

                                                                                                                      For example, a symbolizer block is a list, so every entry requires its own dash:

                                                                                                                      - symbolizer:\n  - polygon:\n      ...\n  - text:\n      ...\n

                                                                                                                      The point: and text: objects (the individual symbolizers themselves) are mappings, and as such, the contents do not require dashes, only indents:

                                                                                                                      - polygon:\n    stroke-color: '#808080'\n    fill-color: '#FF0000'\n

                                                                                                                      The dash next to polygon means that the item itself is contained in a list, not that it contains a list. And the placement of the dash is at the same level of indentation as the list title.

                                                                                                                      It is sometimes not obvious whether an object should be a list (and use dashes) or a mapping (and not use dashes), so please refer to this table if unsure:

                                                                                                                      Object Type Feature style List Rule List Symbolizer List Individual symbolizers (contents) Mapping Transform Mapping Color table (for raster symbolizers) List"},{"location":"styling/ysld/reference/structure/#ysld_reference_structure_indentation","title":"Indentation","text":"

                                                                                                                      Indentation is very important in YSLD. All directives must be indented to its proper place to ensure proper hierarchy. Improper indentation will cause a style to be rendered incorrectly, or not at all.

                                                                                                                      For example, the polygon symbolizer, since it is a mapping, contains certain parameters inside it, such as the color of the fill and stroke. These must be indented such that they are \"inside\" the polygon block.

                                                                                                                      In this example, the following markup is correct:

                                                                                                                      - polygon:\n    fill-color: '#808080'\n    fill-opacity: 0.5\n    stroke-color: black\n    stroke-opacity: 0.75\n

                                                                                                                      The parameters inside the polygon (symbolizer) are indented, meaning that they are referencing the symbolizer and are not \"outside it.\"

                                                                                                                      Compare to the following incorrect markup:

                                                                                                                      - polygon:\n  fill-color: '#808080'\n  fill-opacity: 0.5\n  stroke-color: black\n  stroke-opacity: 0.75\n

                                                                                                                      The parameters that are relevant to the polygon block here need to be contained inside that block. Without the parameters being indented, they are at the same \"level\" as the polygon block, and so will not be interpreted correctly.

                                                                                                                      Note

                                                                                                                      For more details on symbolizer syntax, please see the section on symbolizers.

                                                                                                                      "},{"location":"styling/ysld/reference/structure/#wrapped-lines","title":"Wrapped lines","text":"

                                                                                                                      Long lines can be wrapped by indenting each subsequent line in the text block. New line characters will be converted to spaces, so each line should not end with a space.

                                                                                                                      So in a situation with a long value:

                                                                                                                      - name: shortname\n  title: Longer name\n  abstract: This is a really long abstract that in no way is ever likely to fit on a single line on most people's displays.\n

                                                                                                                      This can be altered to look like:

                                                                                                                      - name: shortname\n  title: Longer name\n  abstract: This is a really long abstract that in no way\n            is ever likely to fit on a single line on most\n            people's displays.\n

                                                                                                                      In both cases, the value for abstract is unchanged.

                                                                                                                      Wrapped lines can be done between properties and values as well. So this single line:

                                                                                                                      stroke-width: ${roadwidth / 500}\n

                                                                                                                      Can be altered to look like:

                                                                                                                      stroke-width:\n  ${roadwidth / 500}\n

                                                                                                                      The only constraint with using wrapped lines is that the subsequent lines need to be indented.

                                                                                                                      "},{"location":"styling/ysld/reference/structure/#comments","title":"Comments","text":"

                                                                                                                      Comments are allowed in YSLD, both for descriptive reasons and to remove certain styling directives without deleting them outright. Comments are indicated by a # as the first non-blank-space character in a line. For example:

                                                                                                                      # This is a line symbolizer\n- line:\n    stroke-color: '#000000'\n    stroke-width: 2\n#   stroke-width: 3\n

                                                                                                                      The above would display the lines with width of 2; the line showing a width of 3 is commented out.

                                                                                                                      Comment blocks do not exist, so each line of a comment will need to be indicated as such:

                                                                                                                      - line:\n    stroke-color: '#000000'\n    stroke-width: 2\n#- line:\n#    stroke-color: '#FF0000'\n#    stroke-width: 3\n

                                                                                                                      Note

                                                                                                                      Comments are not preserved when converting to SLD.

                                                                                                                      "},{"location":"styling/ysld/reference/transforms/","title":"Transforms","text":"

                                                                                                                      YSLD allows for the use of rendering transformations. Rendering transformations are processes on the server that are executed inside the rendering pipeline, to allow for dynamic data transformations. In GeoServer, rendering transformations are typically exposed as WPS processes.

                                                                                                                      For example, one could create a style that applies to a point layer, and applies a Heatmap process as a rendering transformation, making the output a (raster) heatmap.

                                                                                                                      Because rendering transformations can change the geometry type, it is important to make sure that the symbolizer used matches the output of the rendering transformation, not the input. In the above heatmap example, the appropriate symbolizer would be a raster symbolizer, as the output of a heatmap is a raster.

                                                                                                                      "},{"location":"styling/ysld/reference/transforms/#syntax","title":"Syntax","text":"

                                                                                                                      The full syntax for using a rendering transformation is:

                                                                                                                      feature-styles\n  ...\n  transform:\n    name: <text>\n    params: <options>\n  rules:\n    ...\n

                                                                                                                      where:

                                                                                                                      Property Required? Description Default value name Yes Full name of the rendering transform including any prefixes (such as vec:Heatmap) N/A params Yes All input parameters for the rendering transformation. Content will vary greatly based on the amount and type of parameters needed. N/A

                                                                                                                      The values in the params options typically include values, strings, or attributes. However, it can be useful with a transformation to include environment parameters that concern the position and size of the map when it is rendered. For example, the following are common reserved environment parameters:

                                                                                                                      Environment parameter Description env('wms_bbox') The bounding box of the request env('wms_width') The width of the request env('wms_height') The height of the request

                                                                                                                      With this in mind, the following params are assumed unless otherwise specified:

                                                                                                                      params:\n  ...\n  outputBBOX: ${env('wms_bbox')}\n  outputWidth: ${env('wms_width')}\n  outputHeight: ${env('wms_height')}\n  ...\n

                                                                                                                      Note

                                                                                                                      Be aware that the transform happens outside of the rules and symbolizers, but inside the feature styles.

                                                                                                                      "},{"location":"styling/ysld/reference/transforms/#examples","title":"Examples","text":""},{"location":"styling/ysld/reference/transforms/#heatmap","title":"Heatmap","text":"

                                                                                                                      The following uses the vec:Heatmap process to convert a point layer to a heatmap raster:

                                                                                                                      title: Heatmap\nfeature-styles:\n- transform:\n    name: vec:Heatmap\n    params:\n      weightAttr: pop2000\n      radiusPixels: 100\n      pixelsPerCell: 10\n  rules:\n  - symbolizers:\n    - raster:\n        opacity: 0.6\n        color-map:\n          type: ramp\n          entries:\n          - ['#FFFFFF',0,0.0,nodata]\n          - ['#4444FF',1,0.1,nodata]\n          - ['#FF0000',1,0.5,values]\n          - ['#FFFF00',1,1.0,values]\n
                                                                                                                      "},{"location":"styling/ysld/reference/transforms/#point-stacker","title":"Point Stacker","text":"

                                                                                                                      The point stacker transform can be used to combine points that are close together. This transform acts on a point geometry layer, and combines any points that are within a single cell as specified by the cellSize parameter. The resulting geometry has attributes geom (the geometry), count (the number of features represented by this point) and countUnique (the number of unique features represented by this point). These attributes can be used to size and label the points based on how many points are combined together:

                                                                                                                      title: pointstacker\nfeature-styles:\n- transform:\n    name: vec:PointStacker\n    params:\n    cellSize: 100\n  rules:\n  - symbolizers:\n    - point:\n        size: ${8*sqrt(count)}\n        symbols:\n        - mark:\n            shape: circle\n            fill-color: '#EE0000'\n  - filter: count > 1\n    symbolizers:\n    - text:\n          fill-color: '#FFFFFF'\n          font-family: Arial\n          font-size: 10\n          font-weight: bold\n          label: ${count}\n          placement:\n              anchor: [0.5,0.75]\n

                                                                                                                      Point stacker

                                                                                                                      "},{"location":"styling/ysld/reference/variables/","title":"Define and reuse YAML Variables","text":"

                                                                                                                      Variables in YSLD that allow for a certain directive or block of directives to be defined by name and later reused. This can greatly simplify the styling document.

                                                                                                                      The two most-common use cases for using variables are:

                                                                                                                      • To create a more-friendly name for a value (such as using myorange instead of #EE8000)
                                                                                                                      • To define a block of directives to remove redundant content and to decrease file length

                                                                                                                      It is customary, but not required, to place all definitions at the very top of the YSLD file, above all header information, feature styles, or rules.

                                                                                                                      "},{"location":"styling/ysld/reference/variables/#syntax","title":"Syntax","text":""},{"location":"styling/ysld/reference/variables/#define-a-single-value","title":"Define a single value","text":"

                                                                                                                      The syntax for defining a variable as a single value is:

                                                                                                                      define: &variable <value>\n

                                                                                                                      where:

                                                                                                                      Attribute Required? Description Default value define Yes Starts the definition block. N/A &variable Yes The name of the variable being defined. The & is not part of the variable name. N/A <value> Yes A single value, such as 512 or '#DD0000' N/A

                                                                                                                      The syntax for using this variable is to prepend the variable name with a *:

                                                                                                                      <directive>: *variable\n

                                                                                                                      This variable can be used in any place where its type is expected.

                                                                                                                      "},{"location":"styling/ysld/reference/variables/#define-a-directive-block","title":"Define a directive block","text":"

                                                                                                                      The syntax for defining a variable as a content block is:

                                                                                                                      define: &varblock\n  <directive>: <value>\n  <directive>: <value>\n  ...\n  <block>:\n  - <directive>: <value>\n    <directive>: <value>\n  ...\n

                                                                                                                      Any number of directives or blocks of directives can be inside the definition block. Moreover, any type of directive that is valid YSLD can be included in the definition, so long as the content block could be substituted for the variable without modification.

                                                                                                                      Note

                                                                                                                      It is also possible to have nested definitions.

                                                                                                                      The syntax for using this variable is to prepend the variable name with <<: *. For example:

                                                                                                                      <block>:\n- <directive>: <value>  \n  <<: *varblock\n

                                                                                                                      The line that contains the variable will be replaced with the contents of the definition.

                                                                                                                      "},{"location":"styling/ysld/reference/variables/#examples","title":"Examples","text":""},{"location":"styling/ysld/reference/variables/#define-variables-to-reuse-colors","title":"Define variables to reuse colors","text":"

                                                                                                                      Name background color for both polygon fill and halo outline:

                                                                                                                      define: &background_color '#998088'\ndefine: &text_color \"#111122\"\n\nfeature-styles:\n- rules:\n  - symbolizers:\n    - polygon:\n        stroke-width: 1\n        fill-color: *background_color\n    - text:\n        label: ${name}\n        fill-color: *text_color\n        halo:\n           radius: 2\n           fill-color: *background_color\n           fill-opacity: 0.8\n
                                                                                                                      "},{"location":"styling/ysld/reference/variables/#define-block-to-reuse-stroke","title":"Define block to reuse stroke","text":"

                                                                                                                      Define a block of stroke parameters for reuse in each rule:

                                                                                                                      define: &stroke_style\n  stroke: '#FF0000'\n  stroke-width: 2\n  stroke-opacity: 0.5\n\nfeature-styles:\n- rules:\n  - filter: ${pop < '200000'}\n    symbolizers:\n    - polygon:\n        <<: *stroke_style\n        fill-color: '#66FF66'\n  - filter: ${pop BETWEEN '200000' AND '500000'}\n    symbolizers:\n    - polygon:\n        <<: *stroke_style\n        fill-color: '#33CC33'\n  - filter: ${pop > '500000'}\n    symbolizers:\n    - polygon:\n        <<: *stroke_style\n        fill-color: '009900'\n
                                                                                                                      "},{"location":"styling/ysld/reference/symbolizers/","title":"Symbolizers","text":"

                                                                                                                      The basic unit of visualization is the symbolizer. There are five types of symbolizers: Point, Line, Polygon, Raster, and Text.

                                                                                                                      Symbolizers are contained inside rules. A rule can contain one or many symbolizers.

                                                                                                                      Note

                                                                                                                      The most common use case for multiple symbolizers is a geometry (point/line/polygon) symbolizer to draw the features plus a text symbolizer for labeling these features.

                                                                                                                      Use of multiple symbolizers

                                                                                                                      "},{"location":"styling/ysld/reference/symbolizers/#drawing-order","title":"Drawing order","text":"

                                                                                                                      The order of symbolizers significant, and also the order of your data.

                                                                                                                      For each feature the rules are evaluated resulting in a list of symbolizers that will be used to draw that feature. The symbolizers are drawn in the order provided.

                                                                                                                      Consider the following two symbolizers:

                                                                                                                      symbolizers:\n- point:\n    symbols:\n    - mark:\n        shape: square\n        fill-color: '#FFCC00'\n- point:\n    symbols:\n    - mark:\n        shape: triangle\n        fill-color: '#FF3300'\n

                                                                                                                      When drawing three points these symbolizers will be applied in order on each feature:

                                                                                                                      1. Feature 1 is drawn as a square, followed by a triangle:

                                                                                                                        Feature 1 buffer rendering

                                                                                                                      2. Feature 2 is drawn as a square, followed by a triangle. Notice the slight overlap with Feature 1:

                                                                                                                        Feature 2 buffer rendering

                                                                                                                      3. Feature 3 is drawn as a square, followed by a triangle:

                                                                                                                        Feature 3 buffer rendering

                                                                                                                      Note

                                                                                                                      In the final image, Feature 1 and Feature 2 have a slight overlap. This overlap is determined by data order which we have no control over. If you need to control the overlap review the Feature Styles section on managing \"z-order\".

                                                                                                                      Feature style controlling z-order

                                                                                                                      "},{"location":"styling/ysld/reference/symbolizers/#matching-symbolizers-and-geometries","title":"Matching symbolizers and geometries","text":"

                                                                                                                      It is common to match the symbolizer with the type of geometries contained in the layer, but this is not required. The following table illustrates what will happen when a geometry symbolizer is matched up with another type of geometry.

                                                                                                                      Points Lines Polygon Raster Point Symbolizer Points Midpoint of the lines Centroid of the polygons Centroid of the raster Line Symbolizer n/a Lines Outline (stroke) of the polygons Outline (stroke) of the raster Polygon Symbolizer n/a Will \"close\" the line and style as a polygon Polygons Will \"outline\" the raster and style as a polygon Raster Symbolizer n/a n/a n/a Transform raster values to color channels for display Text Symbolizer Label at point location Label at midpoint of lines Label at centroid of polygons Label at centroid of raster outline"},{"location":"styling/ysld/reference/symbolizers/#syntax","title":"Syntax","text":"

                                                                                                                      The following is the basic syntax common to all symbolizers. Note that the contents of the block are not all expanded here and that each kind of symbolizer provides additional syntax.

                                                                                                                      geometry: <cql>\nuom: <text>\n..\nx-composite: <text>\nx-composite-base: <boolean>\nx-inclusion: <text>\n

                                                                                                                      Where:

                                                                                                                      Property Required? Description Default value geometry No Specifies which attribute to use as the geometry (see Geometry transformations in SLD) First geometry attribute found (usually named geom or the_geom) uom No Unit of measure used for width calculations (see Specifying symbolizer sizes in ground units) pixel

                                                                                                                      Additional \"vendor options\" properties for Color compositing and color blending:

                                                                                                                      Property Required? Description Default value x-composite No Allows for both alpha compositing and color blending options between symbolizers. N/A x-composite-base No Allows the rendering engine to use the symbolizer mapping to define a \"base\" buffer for subsequent compositing and blending using x-composite. See the section on Feature Styles for more details. false

                                                                                                                      Additional \"vendor options\" properties for Rendering Selection:

                                                                                                                      Property Required? Description Default value x-inclusion No Define if rule should be included in style for legendOnly or mapOnly. normal"},{"location":"styling/ysld/reference/symbolizers/line/","title":"Line symbolizer","text":"

                                                                                                                      The line symbolizer is used to style linear (1-dimensional) features. It is in some ways the simplest of the symbolizers because it only contains facilities for the stroke (outline) of a feature.

                                                                                                                      "},{"location":"styling/ysld/reference/symbolizers/line/#syntax","title":"Syntax","text":"

                                                                                                                      The full syntax of a line symbolizer is:

                                                                                                                      symbolizers:\n- line:\n    stroke-color: <color>\n    stroke-width: <expression>\n    stroke-opacity: <expression>\n    stroke-linejoin: <expression>\n    stroke-linecap: <expression>\n    stroke-dasharray: <float list>\n    stroke-dashoffset: <expression>\n    stroke-graphic: \n      <graphic_options>\n    stroke-graphic-fill: \n      <graphic_options>\n    offset: <expression>\n    geometry: <expression>\n    uom: <text>\n    x-labelObstacle: <boolean>\n    x-composite-base: <boolean>\n    x-composite: <text>\n    x-inclusion: <text>\n

                                                                                                                      where:

                                                                                                                      Property Required? Description Default value stroke-color No Color of line features. '#000000' (black) stroke-width No Width of line features, measured in pixels. 1 stroke-opacity No Opacity of line features. Valid values are a decimal value between 0 (completely transparent) and 1 (completely opaque). 1 stroke-linejoin No How line segments are joined together. Options are mitre (sharp corner), round (round corner), and bevel (diagonal corner). mitre stroke-linecap No How line features are rendered at their ends. Options are butt (sharp square edge), round (rounded edge), and square (slightly elongated square edge). butt stroke-dasharray No A numeric list signifying length of lines and gaps, creating a dashed effect. Units are pixels, so \"2 3\" would be a repeating pattern of 2 pixels of drawn line followed by 3 pixels of blank space. If only one number is supplied, this will mean equal amounts of line and gap. No dash stroke-dashoffset No Number of pixels into the dasharray to offset the drawing of the dash, used to shift the location of the lines and gaps in a dash. 0 stroke-graphic No A design or pattern to be used along the stroke. Output will always be a linear repeating pattern, and as such is not tied to the value of stroke-width. Can either be a mark consisting of a common shape or a URL that points to a graphic. The <graphic_options> should consist of a mapping containing symbols: followed by an external: or mark:, with appropriate parameters as detailed in the Point symbolizer section. Cannot be used with stroke-graphic-fill. N/A stroke-graphic-fill No A design or pattern to be used for the fill of the stroke. The area that is to be filled is tied directly to the value of stroke-width. Can either be a mark consisting of a common shape or a URL that points to a graphic. The <graphic_options> should consist of a mapping containing symbols: followed by an external: or mark:, with appropriate parameters as detailed in the Point symbolizer section. Cannot be used with stroke-graphic. N/A Property Required? Description Default value offset No Value in pixels for moving the drawn line relative to the location of the feature. 0 Property Required? Description Default value geometry No Specifies which attribute to use as the geometry (see Geometry transformations in SLD) First geometry attribute found (usually named geom or the_geom) uom No Unit of measure used for width calculations (see Specifying symbolizer sizes in ground units) pixel

                                                                                                                      Additional \"vendor options\" property for Label Obstacles:

                                                                                                                      Property Required? Description Default value x-labelObstacle No Marks the symbolizer as an obstacle such that labels drawn via a text symbolizer will not be drawn over top of these features. Options are true or false. Note that the bounding boxes of features are used when calculating obstacles, so unintended effects may occur when marking a line or polygon symbolizer as an obstacle. false

                                                                                                                      Additional \"vendor options\" properties for Color compositing and color blending:

                                                                                                                      Property Required? Description Default value x-composite No Allows for both alpha compositing and color blending options between symbolizers. N/A x-composite-base No Allows the rendering engine to use the symbolizer mapping to define a \"base\" buffer for subsequent compositing and blending using x-composite. See the section on Feature Styles for more details. false

                                                                                                                      Additional \"vendor options\" properties for Rendering Selection:

                                                                                                                      Property Required? Description Default value x-inclusion No Define if rule should be included in style for legendOnly or mapOnly. normal"},{"location":"styling/ysld/reference/symbolizers/line/#examples","title":"Examples","text":""},{"location":"styling/ysld/reference/symbolizers/line/#basic-line-with-styled-ends","title":"Basic line with styled ends","text":"

                                                                                                                      The linejoin and linecap properties can be used to style the joins and ends of any stroke. This example draws lines with partially transparent black lines with rounded ends and sharp (mitred) corners:

                                                                                                                      feature-styles:\n- rules:\n  - symbolizers:\n    - line:\n        stroke-color: '#000000'\n        stroke-width: 8\n        stroke-opacity: 0.5\n        stroke-linejoin: mitre\n        stroke-linecap: round\n

                                                                                                                      Basic line with styled ends

                                                                                                                      "},{"location":"styling/ysld/reference/symbolizers/line/#railroad-pattern","title":"Railroad pattern","text":"

                                                                                                                      Todo

                                                                                                                      Fix this example

                                                                                                                      Many maps use a hatched pattern to represent railroads. This can be accomplished by using two line symbolizers, one solid and one dashed. Specifically, the stroke-dasharray property is used to create a dashed line of length 1 every 24 pixels:

                                                                                                                      name: railroad\nfeature-styles:\n- name: name\n  rules:\n  - symbolizers:\n    - line:\n        stroke-color: '#000000'\n        stroke-width: 1\n    - line:\n        stroke-color: '#000000'\n        stroke-width: 12\n        stroke-dasharray: '1 24'\n

                                                                                                                      Railroad pattern

                                                                                                                      "},{"location":"styling/ysld/reference/symbolizers/line/#specifying-sizes-in-units","title":"Specifying sizes in units","text":"

                                                                                                                      The units for stroke-width, size, and other similar attributes default to pixels, meaning that graphics remain a constant size at different zoom levels. Alternately, units (feet or meters) can be specified for values, so graphics will scale as you zoom in or out. This example draws roads with a fixed width of 8 meters:

                                                                                                                      feature-styles:\n- rules:\n  - symbolizers:\n    - line:\n        stroke-color: '#000000'\n        stroke-width: '8 m'\n

                                                                                                                      Line width measured in meters (zoomed out)

                                                                                                                      Line width measured in meters (zoomed in)

                                                                                                                      The default unit of measure for the symbolizer is defined using uom. This example uses a default of meters to supply distances for stroke-width and stroke-dasharray using meters.

                                                                                                                      line:\n  uom: metre\n  stroke-color: '#000000'\n  stroke-width: '8'\n  stroke-dasharray: '20 3'\n

                                                                                                                      Line width and spacing in meters

                                                                                                                      "},{"location":"styling/ysld/reference/symbolizers/point/","title":"Point symbolizer","text":"

                                                                                                                      The point symbolizer is used to style point features or centroids of non-point features.

                                                                                                                      "},{"location":"styling/ysld/reference/symbolizers/point/#syntax","title":"Syntax","text":"

                                                                                                                      The full syntax of a point symbolizer is:

                                                                                                                      symbolizers:\n- point:\n    symbols:\n    - external:\n        url: <text>\n        format: <text>\n    - mark:\n        shape: <shape>\n        fill-color: <color>\n        fill-opacity: <expression>\n        fill-graphic: \n          <graphic_options>\n        stroke-color: <color>\n        stroke-width: <expression>\n        stroke-opacity: <expression>\n        stroke-linejoin: <expression>\n        stroke-linecap: <expression>\n        stroke-dasharray: <float list>\n        stroke-dashoffset: <expression>\n        stroke-graphic: \n          <graphic_options>\n        stroke-graphic-fill: \n          <graphic_options>\n    size: <expression>\n    anchor: <tuple>\n    displacement: <tuple>\n    opacity: <expression>\n    rotation: <expression>\n    geometry: <expression>\n    uom: <text>\n    x-labelObstacle: <boolean>\n    x-composite-base: <boolean>\n    x-composite: <text>\n    x-inclusion: <text>\n

                                                                                                                      where:

                                                                                                                      Property Required? Description Default value stroke-color No Color of line features. '#000000' (black) stroke-width No Width of line features, measured in pixels. 1 stroke-opacity No Opacity of line features. Valid values are a decimal value between 0 (completely transparent) and 1 (completely opaque). 1 stroke-linejoin No How line segments are joined together. Options are mitre (sharp corner), round (round corner), and bevel (diagonal corner). mitre stroke-linecap No How line features are rendered at their ends. Options are butt (sharp square edge), round (rounded edge), and square (slightly elongated square edge). butt stroke-dasharray No A numeric list signifying length of lines and gaps, creating a dashed effect. Units are pixels, so \"2 3\" would be a repeating pattern of 2 pixels of drawn line followed by 3 pixels of blank space. If only one number is supplied, this will mean equal amounts of line and gap. No dash stroke-dashoffset No Number of pixels into the dasharray to offset the drawing of the dash, used to shift the location of the lines and gaps in a dash. 0 stroke-graphic No A design or pattern to be used along the stroke. Output will always be a linear repeating pattern, and as such is not tied to the value of stroke-width. Can either be a mark consisting of a common shape or a URL that points to a graphic. The <graphic_options> should consist of a mapping containing symbols: followed by an external: or mark:, with appropriate parameters as detailed in the Point symbolizer section. Cannot be used with stroke-graphic-fill. N/A stroke-graphic-fill No A design or pattern to be used for the fill of the stroke. The area that is to be filled is tied directly to the value of stroke-width. Can either be a mark consisting of a common shape or a URL that points to a graphic. The <graphic_options> should consist of a mapping containing symbols: followed by an external: or mark:, with appropriate parameters as detailed in the Point symbolizer section. Cannot be used with stroke-graphic. N/A Property Required? Description Default value fill-color No Color of inside of features. '#808080' (gray) fill-opacity No Opacity of the fill. Valid values are a decimal value between 0 (completely transparent) and 1 (completely opaque). 1 fill-graphic No A design or pattern to be used for the fill of the feature. Can either be a mark consisting of a common shape or a URL that points to a graphic. The <graphic_options> should consist of a mapping containing symbols: followed by an external: or mark:, with appropriate parameters as detailed in the Point symbolizer section. None

                                                                                                                      The use of fill-graphic allows for the following extra options:

                                                                                                                      Property Required? Description Default value x-graphic-margin No Used to specify margins (in pixels) around the graphic used in the fill. Possible values are a list of four (top, right, bottom, left), a list of three (top, right and left, bottom), a list of two (top and bottom, right and left), or a single value. N/A x-random No Activates random distribution of symbols. Possible values are free or grid. free generates a completely random distribution, and grid will generate a regular grid of positions, and only randomize the position of the symbol around the cell centers, providing a more even distribution. N/A x-random-tile-size No When used with x-random, determines the size of the grid (in pixels) that will contain the randomly distributed symbols. 256 x-random-rotation No When used with x-random, activates random symbol rotation. Possible values are none or free. none x-random-symbol-count No When used tih x-random, determines the number of symbols drawn. Increasing this number will generate a more dense distribution of symbols 16 x-random-seed No Determines the \"seed\" used to generate the random distribution. Changing this value will result in a different symbol distribution. 0

                                                                                                                      Todo

                                                                                                                      Add examples using random

                                                                                                                      Property Required? Description Default value external No Specifies an image to use to style the point. N/A url Yes Location of the image. Can either be an actual URL or a file path (relative to where the style file is saved in the GeoServer data directory). Should be enclosed in single quotes. N/A format Yes Format of the image. Must be a valid MIME type (such as image/png for PNG, image/jpeg for JPG, image/svg+xml for SVG) N/A mark No Specifies a regular shape to use to style the point. N/A shape No Shape of the mark. Options are square, circle, triangle, cross, x, and star. square size No Size of the mark in pixels. If the aspect ratio of the mark is not 1:1 (square), will apply to the height of the graphic only, with the width scaled proportionally. 16 anchor No Specify the center of the symbol relative to the feature location. Value is an [x,y] tuple with decimal values from 0-1, with [0,0] meaning that the symbol is anchored to the top left, and [1,1] meaning anchored to bottom right. [0.5,0.5] displacement No Specifies a distance to which to move the symbol relative to the feature. Value is an [x,y] tuple with values expressed in pixels, so [10,5] will displace the symbol 10 pixels to the right and 5 pixels down. [0,0] opacity No Specifies the level of transparency. Value of 0 means entirely transparent, while 1 means entirely opaque. Only affects graphics referenced by the external parameter; the opacity of mark symbols is controlled by the fill-opacity and stroke-opacity of the mark. 1 rotation No Value (in degrees) or rotation of the mark. Larger values increase counter-clockwise rotation. A value of 180 will make the mark upside-down. 0 Property Required? Description Default value geometry No Specifies which attribute to use as the geometry (see Geometry transformations in SLD) First geometry attribute found (usually named geom or the_geom) uom No Unit of measure used for width calculations (see Specifying symbolizer sizes in ground units) pixel

                                                                                                                      The following properties are equivalent to SLD \"vendor options\".

                                                                                                                      Additional \"vendor options\" property for Label Obstacles:

                                                                                                                      Property Required? Description Default value x-labelObstacle No Marks the symbolizer as an obstacle such that labels drawn via a text symbolizer will not be drawn over top of these features. Options are true or false. Note that the bounding boxes of features are used when calculating obstacles, so unintended effects may occur when marking a line or polygon symbolizer as an obstacle. false

                                                                                                                      Additional \"vendor options\" properties for Color compositing and color blending:

                                                                                                                      Additional \"vendor options\" properties for Color compositing and color blending:

                                                                                                                      Property Required? Description Default value x-composite No Allows for both alpha compositing and color blending options between symbolizers. N/A x-composite-base No Allows the rendering engine to use the symbolizer mapping to define a \"base\" buffer for subsequent compositing and blending using x-composite. See the section on Feature Styles for more details. false

                                                                                                                      Additional \"vendor options\" properties for Rendering Selection:

                                                                                                                      Additional \"vendor options\" properties for Rendering Selection:

                                                                                                                      Property Required? Description Default value x-inclusion No Define if rule should be included in style for legendOnly or mapOnly. normal"},{"location":"styling/ysld/reference/symbolizers/point/#examples","title":"Examples","text":""},{"location":"styling/ysld/reference/symbolizers/point/#basic-point","title":"Basic point","text":"

                                                                                                                      A point symbolizer draws a point at the center of any geometry. It is defined by an external image or a symbol, either of which can be sized and rotated. A mark is a pre-defined symbol that can be drawn at the location of a point. Similar to polygons, marks have both a fill and a stroke. This example shows a point symbolizer that draws semi-transparent red diamonds with black outlines:

                                                                                                                      feature-styles:\n- name: name\n  rules:\n  - title: red point\n    symbolizers:\n    - point:\n        symbols:\n        - mark:\n            shape: square\n            fill-color: '#FF0000'\n            fill-opacity: 0.75\n            stroke-color: '#000000'\n            stroke-width: 1.5\n            stroke-opacity: 1\n        size: 20\n        rotation: 45\n

                                                                                                                      Basic point

                                                                                                                      "},{"location":"styling/ysld/reference/symbolizers/point/#point-as-image","title":"Point as image","text":"

                                                                                                                      Sometimes it may be useful to use an image to represent certain points. This can be accomplished using the external symbol property, which requires a url and a format. The url should be enclosed in single quotes. The format property is a MIME type image. This example shows a point symbolizer that draws an image centered on each point:

                                                                                                                      name: point\nfeature-styles:\n- name: name\n  rules:\n  - symbolizers:\n    - point:\n        symbols:\n        - external:\n            url: 'geoserver.png'\n            format: image/png\n        size: 16\n

                                                                                                                      Point as image

                                                                                                                      "},{"location":"styling/ysld/reference/symbolizers/point/#point-composition","title":"Point composition","text":"

                                                                                                                      Using more than one point symbolizer allows the composition of more complex symbology. This example shows two symbolizers along with the x-composite parameter in order to subtract a shape from a square mark, allowing the background to show through.

                                                                                                                      symbolizers:\n- point:\n    symbols:\n    - mark:\n        shape: square\n        fill-color: '#222222'\n    size: 40\n- point:\n    symbols:\n    - external:\n        url: 'stamp.png'\n        format: image/png\n    x-composite: xor\n    size: 40\n

                                                                                                                      Point composition

                                                                                                                      "},{"location":"styling/ysld/reference/symbolizers/point/#points-as-arrow-heads","title":"Points as arrow heads","text":"

                                                                                                                      Sometimes it is useful to generate a point using a CQL expression. The following example generates a point at the end of each line in the shape of an arrow, rotated such that it matches the orientation of the line.

                                                                                                                      name: arrow\nsymbolizers:\n- line:\n   stroke-color: '#808080'\n   stroke-width: 3\n- point:\n    geometry: ${endPoint(the_geom)}\n    symbols:\n    - mark:\n        shape: shape://oarrow\n        fill-color: '#808080'\n    size: 30\n    rotation: ${endAngle(the_geom)}\n

                                                                                                                      Point as arrow head

                                                                                                                      "},{"location":"styling/ysld/reference/symbolizers/polygon/","title":"Polygon symbolizer","text":"

                                                                                                                      The polygon symbolizer styles polygon (2-dimensional) features. It contains facilities for the stroke (outline) of a feature as well as the fill (inside) of a feature.

                                                                                                                      "},{"location":"styling/ysld/reference/symbolizers/polygon/#syntax","title":"Syntax","text":"

                                                                                                                      The full syntax of a polygon symbolizer is:

                                                                                                                      symbolizers:\n- polygon:\n    fill-color: <color>\n    fill-opacity: <expression>\n    fill-graphic: \n      <graphic_options>\n    stroke-color: <color>\n    stroke-width: <expression>\n    stroke-opacity: <expression>\n    stroke-linejoin: <expression>\n    stroke-linecap: <expression>\n    stroke-dasharray: <float list>\n    stroke-dashoffset: <expression>\n    stroke-graphic:\n      <graphic_options>\n    stroke-graphic-fill: \n      <graphic_options>\n    offset: <expression>\n    displacement: <expression>\n    geometry: <expression>\n    uom: <text>\n    x-labelObstacle: <boolean>\n    x-composite-base: <boolean>\n    x-composite: <text>\n    x-inclusion: <text>\n

                                                                                                                      where:

                                                                                                                      Property Required? Description Default value stroke-color No Color of line features. '#000000' (black) stroke-width No Width of line features, measured in pixels. 1 stroke-opacity No Opacity of line features. Valid values are a decimal value between 0 (completely transparent) and 1 (completely opaque). 1 stroke-linejoin No How line segments are joined together. Options are mitre (sharp corner), round (round corner), and bevel (diagonal corner). mitre stroke-linecap No How line features are rendered at their ends. Options are butt (sharp square edge), round (rounded edge), and square (slightly elongated square edge). butt stroke-dasharray No A numeric list signifying length of lines and gaps, creating a dashed effect. Units are pixels, so \"2 3\" would be a repeating pattern of 2 pixels of drawn line followed by 3 pixels of blank space. If only one number is supplied, this will mean equal amounts of line and gap. No dash stroke-dashoffset No Number of pixels into the dasharray to offset the drawing of the dash, used to shift the location of the lines and gaps in a dash. 0 stroke-graphic No A design or pattern to be used along the stroke. Output will always be a linear repeating pattern, and as such is not tied to the value of stroke-width. Can either be a mark consisting of a common shape or a URL that points to a graphic. The <graphic_options> should consist of a mapping containing symbols: followed by an external: or mark:, with appropriate parameters as detailed in the Point symbolizer section. Cannot be used with stroke-graphic-fill. N/A stroke-graphic-fill No A design or pattern to be used for the fill of the stroke. The area that is to be filled is tied directly to the value of stroke-width. Can either be a mark consisting of a common shape or a URL that points to a graphic. The <graphic_options> should consist of a mapping containing symbols: followed by an external: or mark:, with appropriate parameters as detailed in the Point symbolizer section. Cannot be used with stroke-graphic. N/A Property Required? Description Default value fill-color No Color of inside of features. '#808080' (gray) fill-opacity No Opacity of the fill. Valid values are a decimal value between 0 (completely transparent) and 1 (completely opaque). 1 fill-graphic No A design or pattern to be used for the fill of the feature. Can either be a mark consisting of a common shape or a URL that points to a graphic. The <graphic_options> should consist of a mapping containing symbols: followed by an external: or mark:, with appropriate parameters as detailed in the Point symbolizer section. None

                                                                                                                      The use of fill-graphic allows for the following extra options:

                                                                                                                      Property Required? Description Default value x-graphic-margin No Used to specify margins (in pixels) around the graphic used in the fill. Possible values are a list of four (top, right, bottom, left), a list of three (top, right and left, bottom), a list of two (top and bottom, right and left), or a single value. N/A x-random No Activates random distribution of symbols. Possible values are free or grid. free generates a completely random distribution, and grid will generate a regular grid of positions, and only randomize the position of the symbol around the cell centers, providing a more even distribution. N/A x-random-tile-size No When used with x-random, determines the size of the grid (in pixels) that will contain the randomly distributed symbols. 256 x-random-rotation No When used with x-random, activates random symbol rotation. Possible values are none or free. none x-random-symbol-count No When used tih x-random, determines the number of symbols drawn. Increasing this number will generate a more dense distribution of symbols 16 x-random-seed No Determines the \"seed\" used to generate the random distribution. Changing this value will result in a different symbol distribution. 0

                                                                                                                      Todo

                                                                                                                      Add examples using random

                                                                                                                      Property Required? Description Default value offset No Value in pixels for moving the drawn line relative to the location of the feature. 0 displacement No Specifies a distance to which to move the symbol relative to the feature. Value is an [x,y] tuple with values expressed in pixels, so [10,5] will displace the symbol 10 pixels to the right, and 5 pixels down. [0,0] Property Required? Description Default value geometry No Specifies which attribute to use as the geometry (see Geometry transformations in SLD) First geometry attribute found (usually named geom or the_geom) uom No Unit of measure used for width calculations (see Specifying symbolizer sizes in ground units) pixel

                                                                                                                      The following properties are equivalent to SLD \"vendor options\".

                                                                                                                      Additional \"vendor options\" property for Label Obstacles:

                                                                                                                      Property Required? Description Default value x-labelObstacle No Marks the symbolizer as an obstacle such that labels drawn via a text symbolizer will not be drawn over top of these features. Options are true or false. Note that the bounding boxes of features are used when calculating obstacles, so unintended effects may occur when marking a line or polygon symbolizer as an obstacle. false

                                                                                                                      Additional \"vendor options\" properties for Color compositing and color blending:

                                                                                                                      Additional \"vendor options\" properties for Color compositing and color blending:

                                                                                                                      Property Required? Description Default value x-composite No Allows for both alpha compositing and color blending options between symbolizers. N/A x-composite-base No Allows the rendering engine to use the symbolizer mapping to define a \"base\" buffer for subsequent compositing and blending using x-composite. See the section on Feature Styles for more details. false

                                                                                                                      Additional \"vendor options\" properties for Rendering Selection:

                                                                                                                      Additional \"vendor options\" properties for Rendering Selection:

                                                                                                                      Property Required? Description Default value x-inclusion No Define if rule should be included in style for legendOnly or mapOnly. normal"},{"location":"styling/ysld/reference/symbolizers/polygon/#examples","title":"Examples","text":""},{"location":"styling/ysld/reference/symbolizers/polygon/#basic-polygon","title":"Basic polygon","text":"

                                                                                                                      Polygon symbolizers have both a stroke and a fill, similar to marks for point symbolizers. The following example draws a polygon symbolizer with a red fill and black stroke with beveled line joins for the stroke:

                                                                                                                      feature-styles:\n- name: name\n  rules:\n  - title: fill-graphic\n    symbolizers:  \n    - polygon:\n        fill-color: '#FF0000'\n        fill-opacity: 0.9\n        stroke-color: '#000000'\n        stroke-width: 8\n        stroke-opacity: 1\n        stroke-linejoin: bevel\n

                                                                                                                      "},{"location":"styling/ysld/reference/symbolizers/polygon/#fill-with-graphic","title":"Fill with graphic","text":"

                                                                                                                      The fill-graphic property is used to fill a geometry with a repeating graphic. This can be a mark or an external image. The x-graphic-margin option can be used to specify top, right, bottom, and left margins around the graphic used in the fill. This example uses two sets of repeating squares with different offset values to draw a checkerboard pattern:

                                                                                                                      name: checkers\nfeature-styles:\n- name: name\n  rules:\n  - title: fill-graphic\n    symbolizers:  \n    - polygon:\n        stroke-width: 1\n        fill-graphic:\n          symbols:\n          - mark:\n              shape: square\n              fill-color: '#000000'\n          size: 8\n        x-graphic-margin: 16 16 0 0\n    - polygon:\n        stroke-width: 1\n        fill-graphic:\n          symbols:\n          - mark:\n              shape: square\n              fill-color: '#000000'\n          size: 8\n        x-graphic-margin: 0 0 16 16\n

                                                                                                                      Checkered fill

                                                                                                                      "},{"location":"styling/ysld/reference/symbolizers/polygon/#randomized-graphic-fill","title":"Randomized graphic fill","text":"

                                                                                                                      Normally, the graphic used for the fill-graphic property is tiled. Alternatively, one can scatter this image randomly across the fill area using the x-random option and associated other options. This could be used to create a speckled pattern, as in the following example:

                                                                                                                      name: speckles\nfeature-styles:\n- name: name\n  rules:\n  - title: fill-graphic\n    symbolizers:  \n    - polygon:\n        stroke-width: 1\n        fill-graphic:\n          symbols:\n            - mark:\n                shape: circle\n                fill-color: '#000000'\n          size: 3\n          x-random: grid\n          x-random-seed: 2\n          x-random-tile-size: 1000\n          x-random-rotation: free\n          x-random-symbol-count: 1000\n

                                                                                                                      Randomized graphic fill

                                                                                                                      "},{"location":"styling/ysld/reference/symbolizers/raster/","title":"Raster symbolizer","text":"

                                                                                                                      The raster symbolizer styles raster (coverage) layers. A raster is an array of information with each cell in the array containing one or more values, stored as \"bands\".

                                                                                                                      The full syntax of a raster symbolizer is:

                                                                                                                      symbolizers:\n- raster:\n    opacity: <expression>\n    channels:\n      gray: \n        <channel_options>\n      red:\n        <channel_options>\n      green:\n        <channel_options>\n      blue:\n        <channel_options>\n    color-map:\n      type: <ramp|interval|values>\n      entries:\n      - [color, entry_opacity, band_value, text_label]\n    contrast-enhancement: \n      mode: <normalize|histogram>\n      gamma: <expression>\n    x-inclusion: <text>\n

                                                                                                                      where:

                                                                                                                      Property Required? Description Default value opacity No Opacity of the entire display. Valid values are a decimal between 0 (completely transparent) and 1 (completely opaque). 1 channels No Selects the band(s) to display and the display method. N/A gray No Display a single band as a grayscale image. Cannot be used with red, green, and blue. The <channel_options> can be the band name or a mapping containing name: and contrast-enhancement: (optional). 1 red No Display three bands as an RGB image. Must be used with green, and blue. Cannot be used with gray. The <channel_options> can be the band name or a mapping containing name: and contrast-enhancement: (optional). 1 green No Display three bands as an RGB image. Must be used with red, and blue. Cannot be used with gray. The <channel_options> can be the band name or a mapping containing name: and contrast-enhancement: (optional). 2 blue No Display three bands as an RGB image. Must be used with red, and green. Cannot be used with gray. The <channel_options> can be the band name or a mapping containing name: and contrast-enhancement: (optional). See examples below. 3 color-map No Creates a mapping of colors to grid values. Can only be used with a single band. N/A type No Type of color mapping. Options are ramp, an interpolated list of values; interval, a non-interpolated list of values; and values, where values need to match exactly to be drawn. ramp entries No Values for the color mapping. Syntax is a list of tuples. N/A color Yes Color for the particular color map entry. Value is a standard color value. N/A entry_opacity Yes Opacity of the particular color map entry. Valid values are a decimal between 0 (completely transparent) and 1 (completely opaque). N/A band_value Yes Grid value to use for the particular color map entry. Values are data-dependent. Behavior at or around this value is determined by the color ramp type. N/A text_label No Label for the particular color map entry Blank contrast-enhancement No Modifies the contrast of the display N/A mode No Type of contrast enhancement. Options are normalize (stretches contrast so that the smallest and largest values are set to black and white, respectively) or histogram (produces equal number of content in the image at each brightness level). normalize gamma No Multiplier value for contrast adjustment. A value greater than 1 will increase darkness, while a value less than 1 will decrease darkness. 1

                                                                                                                      Additional \"vendor options\" properties for Color compositing and color blending:

                                                                                                                      Additional \"vendor options\" properties for Color compositing and color blending:

                                                                                                                      Property Required? Description Default value x-composite No Allows for both alpha compositing and color blending options between symbolizers. N/A x-composite-base No Allows the rendering engine to use the symbolizer mapping to define a \"base\" buffer for subsequent compositing and blending using x-composite. See the section on Feature Styles for more details. false

                                                                                                                      Additional \"vendor options\" properties for Rendering Selection:

                                                                                                                      Additional \"vendor options\" properties for Rendering Selection:

                                                                                                                      Property Required? Description Default value x-inclusion No Define if rule should be included in style for legendOnly or mapOnly. normal"},{"location":"styling/ysld/reference/symbolizers/raster/#examples","title":"Examples","text":"

                                                                                                                      Todo

                                                                                                                      All examples need figures

                                                                                                                      "},{"location":"styling/ysld/reference/symbolizers/raster/#enhanced-contrast","title":"Enhanced contrast","text":"

                                                                                                                      This example takes a given raster and lightens the output by a factor of 2:

                                                                                                                      symbolizers:\n- raster:\n    contrast-enhancement: \n      gamma: 0.5\n

                                                                                                                      Lightened image

                                                                                                                      "},{"location":"styling/ysld/reference/symbolizers/raster/#normalized-output","title":"Normalized output","text":"

                                                                                                                      This example takes a given raster and adjusts the contrast so that the smallest values are darkest and the highest values are lightest:

                                                                                                                      symbolizers:\n- raster:\n    contrast-enhancement: \n      mode: normalize\n

                                                                                                                      Normalized image

                                                                                                                      "},{"location":"styling/ysld/reference/symbolizers/raster/#band-selection","title":"Band selection","text":"

                                                                                                                      This example takes a raster with multiple bands and outputs band 2 as a grayscale image (This could be used to select a single band in a multi-band image to use with color-map):

                                                                                                                      name: raster\nfeature-styles:\n- name: name\n  rules:\n  - symbolizers:\n    - raster:\n        opacity: 1.0\n        channels:\n          gray: 2\n

                                                                                                                      Grayscale band selection

                                                                                                                      "},{"location":"styling/ysld/reference/symbolizers/raster/#band-selection-with-contrast","title":"Band selection with contrast","text":"

                                                                                                                      This example takes an RGB raster, doubles the intensity of the red, and normalizes the green band:

                                                                                                                      name: raster\nfeature-styles:\n- name: name\n  rules:\n  - symbolizers:\n    - raster:\n        channels:\n          red:\n            name: 1\n            contrast-enhancement:\n              gamma: .5\n          green:\n            name: 2\n            contrast-enhancement:\n              mode: normalize\n          blue:\n            name: 3\n

                                                                                                                      Band selection with contrast enhancement

                                                                                                                      "},{"location":"styling/ysld/reference/symbolizers/raster/#color-ramp","title":"Color ramp","text":"

                                                                                                                      This example shows a color ramp from red to green to blue, with raster band values from 0-200:

                                                                                                                      symbolizers:\n- raster:\n    color-map:\n      type: ramp\n      entries:\n      - ['#FF0000', 1, 0, red]\n      - ['#00FF00', 1, 100, green]\n      - ['#0000FF', 1, 200, blue]\n

                                                                                                                      In this example, the grid values will have the following colors applied:

                                                                                                                      • Less than or equal to 0 will have an output color of solid red
                                                                                                                      • Between 0 and 100 will have an output color interpolated between red and green
                                                                                                                      • Between 100 and 200 will have an output color interpolated between green and blue
                                                                                                                      • Greater than 200 will have an output color of solid blue

                                                                                                                      Color map with ramp

                                                                                                                      "},{"location":"styling/ysld/reference/symbolizers/raster/#color-intervals","title":"Color intervals","text":"

                                                                                                                      The same example as above, but with the color-map type set to intervals:

                                                                                                                      symbolizers:\n- raster:\n    color-map:\n      type: intervals\n      entries:\n      - ['#FF0000', 1, 0, red]\n      - ['#00FF00', 1, 100, green]\n      - ['#0000FF', 1, 200, blue]\n

                                                                                                                      In this example, the grid values will have the following colors applied:

                                                                                                                      • Less than or equal to 0 will have an output color of solid red
                                                                                                                      • Between 0 and 100 will have an output color of solid green
                                                                                                                      • Between 100 and 200 will have an output color of solid blue
                                                                                                                      • Greater than 200 will not be colored at all (transparent)

                                                                                                                      Color map with intervals

                                                                                                                      "},{"location":"styling/ysld/reference/symbolizers/raster/#color-values","title":"Color values","text":"

                                                                                                                      The same example as above, but with the color-map type set to values:

                                                                                                                      symbolizers:\n- raster:\n    color-map:\n      type: values\n      entries:\n      - ['#FF0000', 1, 0, red]\n      - ['#00FF00', 1, 100, green]\n      - ['#0000FF', 1, 200, blue]\n

                                                                                                                      In this example, the grid values will have the following colors applied:

                                                                                                                      • Equal to 0 will have an output color of solid red
                                                                                                                      • Equal to 100 will have an output color of solid green
                                                                                                                      • Equal to 200 will have an output color of solid blue

                                                                                                                      Any other values (even those in between the above values) will not be colored at all.

                                                                                                                      Color map with values

                                                                                                                      "},{"location":"styling/ysld/reference/symbolizers/text/","title":"Text symbolizer","text":"

                                                                                                                      The text symbolizer styles labels of vector features. Labels can consist of text strings and/or graphics.

                                                                                                                      "},{"location":"styling/ysld/reference/symbolizers/text/#syntax","title":"Syntax","text":"

                                                                                                                      The full syntax of a text symbolizer is:

                                                                                                                      symbolizers:\n- text:\n    fill-color: <color>\n    fill-opacity: <expression>\n    fill-graphic: \n      <graphic_options>\n    stroke-graphic: \n      <graphic_options>\n    stroke-graphic-fill: \n      <graphic_options>\n    label: <expression>\n    font-family: <expression>\n    font-size: <expression>\n    font-style: <expression>\n    font-weight: <expression>\n    placement: <point|line>\n    offset: <expression>\n    anchor: <tuple>\n    displacement: <tuple>\n    rotation: <expression>\n    priority: <expression>\n    halo:\n      radius: <expression>\n      fill-color: <color>\n      fill-opacity: <expression>\n      fill-graphic:\n        <graphic_options>\n    graphic:\n      symbols:\n        <graphic_options>\n      size: <expression>\n      opacity: <expression>\n      rotation: <expression>\n    geometry: <expression>\n    uom: <text>\n    x-composite-base: <boolean>\n    x-composite: <text>\n    x-allowOverruns: <boolean>\n    x-autoWrap: <expression>\n    x-conflictResolution: <boolean>\n    x-followLine: <boolean>\n    x-forceLeftToRight: <boolean>\n    x-goodnessOfFit: <expression>\n    x-graphic-margin: <expression>\n    x-graphic-resize: <none|proportional|stretch>\n    x-group: <boolean>\n    x-labelAllGroup: <boolean>\n    x-repeat: <expression>\n    x-maxAngleDelta: <expression>\n    x-maxDisplacement: <expression>\n    x-minGroupDistance: <expression>\n    x-partials: <boolean>\n    x-polygonAlign: <boolean>\n    x-spaceAround: <expression>\n    x-underlineText: <boolean>\n    x-strikethroughText: <boolean>\n    x-charSpacing: <expression>\n    x-wordSpacing: <expression>\n    x-inclusion: <text>\n

                                                                                                                      where:

                                                                                                                      Property Required? Description Default value fill-color No Color of inside of the label. '#808080' (gray) fill-opacity No Opacity of fill of the label text. Valid values are a decimal value between 0 (completely transparent) and 1 (completely opaque). 1 fill-graphic No A design to be used for the fill of the text label. Can either be a mark consisting of a common shape or a URL that points to a graphic. The <graphic_options> should consist of a mapping containing symbols: followed by an external: or mark:, with appropriate parameters as detailed in the Point symbolizer section. None stroke-graphic No A design or pattern to be used along the stroke around the label text. the output will always be a linear repeating pattern, and as such is not tied to the value of stroke-width. Can either be a mark consisting of a common shape or a URL that points to a graphic. The <graphic_options> should consist of a mapping containing symbols: followed by an external: or mark:, with appropriate parameters. Cannot be used with stroke-graphic-fill. N/A stroke-graphic-fill No A design or pattern to be used for the fill of the stroke around the label text. This area that is to be filled is tied directly to the value of stroke-width. Can either be a mark consisting of a common shape or a URL that points to a graphic. The <graphic_options> should consist of a mapping containing symbols: followed by an external: or mark:, with appropriate parameters as detailed in the Point symbolizer section. Cannot be used with stroke-graphic. N/A Property Required? Description Default value label Yes Text to display. Often taken from an attribute but any valid expression that constructs a string will do. N/A font-family No Type of font to be used for the label. Options are system dependent; the full list of fonts available can be found via the GeoServer Server Status page. serif font-size No Size of the font. 10 font-style No Style of the font. Options are normal, italic, and oblique. normal font-weight No Weight of the font. Options are normal and bold. normal placement No Determines whether the label is to be drawn derived from a point or a line. point offset No Value (in pixels) for moving the drawn label relative to the location of the feature. A positive value will shift the label in the direction of its top, while a negative value will shift the label in the direction of its bottom. Only valid for when type is set to line. 0 anchor No Specify the center of the symbol relative to the feature location (centroid for lines and polygons). Value is an [x,y] tuple with decimal values from 0-1, with [0,0] meaning that the symbol is anchored to the bottom left of the label, and [1,1] meaning anchored to the top right of the label. [0,0] displacement No Specifies a distance (in pixels) to which to move the label relative to the feature. Value is an [x,y] tuple with values expressed in pixels, so [10,5] will displace the label 10 pixels to the right and 5 pixels up. Only valid for when type is set to point. [0,0] rotation No Value (in degrees) or rotation of the label. Larger values increase counter-clockwise rotation. A value of 180 will make the label upside-down. Only valid for when type is set to point. 0 priority No The priority used when choosing which labels to display during conflict resolution. Higher priority values take precedence over lower priority values. 1000 halo No Creates a shaded area around the label for easier legibility No halo radius No Size (in pixels) of the halo 1 fill-color No Color of the halo '#808080' fill-opacity No Specifies the level of transparency for the halo. Value of 0 means entirely transparent, while 1 means entirely opaque. 1

                                                                                                                      The following properties allow for a graphic to be displayed in addition to just a label. This is used when drawing \"shields\" (text over top of a graphic) such as in road signs.

                                                                                                                      Property Required? Description Default value graphic No Specifies whether a graphic is to be drawn for the label. N/A (no graphic) symbols No The details of the graphic. Consists of an external: or mark: section, with appropriate parameters as detailed in the Point symbolizer section. N/A size No Size of the graphic in pixels. If the aspect ratio is not 1:1 (square), will apply to the height of the graphic only, with the width scaled proportionally. 16 opacity No Specifies the level of transparency for the graphic. Value of 0 means entirely transparent, while 1 means entirely opaque. 1 rotation No Value (in degrees) or rotation of the graphic. Larger values increase counter-clockwise rotation. A value of 180 will make the graphic upside-down. 0 Property Required? Description Default value geometry No Specifies which attribute to use as the geometry (see Geometry transformations in SLD) First geometry attribute found (usually named geom or the_geom) uom No Unit of measure used for width calculations (see Specifying symbolizer sizes in ground units) pixel

                                                                                                                      The following properties are equivalent to SLD \"vendor options\".

                                                                                                                      Property Required? Description Default value x-allowOverruns No Allows labels on lines to move slightly beyond the beginning or end of the line. true x-autoWrap No The number of pixels beyond which a label will be wrapped over multiple lines. Cannot use with x-followLine. 0 x-conflictResolution No Enables conflict resolution, meaning no two labels will be allowed to overlap. Without conflict resolution, symbolizers can overlap with other labels. true x-followLine No On linear geometries, the label will follow the shape of the current line, as opposed to being drawn at a tangent. Will override false x-forceLeftToRight No Forces labels to a readable orientation, otherwise will follow the line orientation, possibly making the label look upside-down. This setting is useful when using symbol fonts to add direction markers along a line. false x-goodnessOfFit No Percentage (expressed as a decimal between 0-1) of the label that must fit inside the geometry to permit the label to be drawn. Works only on polygon features. 0.5 x-graphic-margin No Number of pixels between the stretched graphic and the text. Only applies when x-graphic-resize is set to stretch or proportional. 0 x-graphic-resize No Allows for stretching the graphic underneath a label to fit the label size. Options are none, stretch or proportional. Used in conjunction with x-graphic-margin.. none x-group No Geometries with identical labels will be considered a single entity to be labeled. Used to control repeated labels. false x-labelAllGroup No Used in conjunction with x-group. When true all items in a group are labeled. When false, only the largest geometry in the group is labeled. Valid for lines only. false x-repeat No Desired distance (in pixels) between labels drawn on a group. If zero, only one label will be drawn. Used in conjunction with x-group. Valid for lines only. 0 x-maxAngleDelta No Maximum allowed angle (in degrees) between two characters in a curved label. Used in conjunction with x-followLine. Values higher than 30 may cause loss of legibility of the label. 22.5 x-maxDisplacement No Distance (in pixels) a label can be displaced from its natural position in an attempt to eliminate conflict with other labels. 0 x-minGroupDistance No Minimum distance (in pixels) between two labels in the same label group. Used in conjunction with displacement or repeat to avoid having two labels too close to each other No minimum distance x-partials No Will display partial labels (truncated on the border of the display area). false x-polygonAlign No Overrides manual rotation to align label rotation automatically. Valid for polygons only. false x-spaceAround No Minimum distance (in pixels) between two labels. A negative value specifies the maximum overlap between two labels. 0 x-underlineText No Instruct the renderer to underline labels. false x-strikethroughText No Instruct the renderer to strikethrough labels. false x-charSpacing No The option controls the amount of space between characters, a positive value increases it, a negative value shrinks it (and will eventually make characters overlap). The value is specified in pixels. 0 x-wordSpacing No The option controls the amount of space between words, for this option only positive values (or zero) are accepted. The value is specified in pixels. 0

                                                                                                                      Additional \"vendor options\" properties for Color compositing and color blending:

                                                                                                                      Property Required? Description Default value x-composite No Allows for both alpha compositing and color blending options between symbolizers. N/A x-composite-base No Allows the rendering engine to use the symbolizer mapping to define a \"base\" buffer for subsequent compositing and blending using x-composite. See the section on Feature Styles for more details. false"},{"location":"styling/ysld/reference/symbolizers/text/#examples","title":"Examples","text":""},{"location":"styling/ysld/reference/symbolizers/text/#basic-label","title":"Basic label","text":"

                                                                                                                      Text symbolizers are used to draw labels on objects. The label text is usually linked to some attribute of the layer. Font options are available in the font-family, font-size, font-style, and font-weight properties. The following example draws a label using the name attribute of the layer, and with a SansSerif font of size 12, gray color, bold and italic:

                                                                                                                      feature-styles:\n- name: name\n  rules:\n  - title: fill-graphic\n    symbolizers:\n    - text:\n        label: ${name}\n        fill-color: '#555555'\n        font-family: SansSerif\n        font-size: 12\n        font-style: italic\n        font-weight: bold\n

                                                                                                                      Basic label

                                                                                                                      "},{"location":"styling/ysld/reference/symbolizers/text/#label-with-wrap","title":"Label with wrap","text":"

                                                                                                                      Wrapping long labels can improve how well they fit on maps. This can be accomplished using the x-autoWrap property. This example wraps lines longer than 70 pixels:

                                                                                                                      feature-styles:\n- name: name\n  rules:\n  - symbolizers:\n    - polygon:\n        stroke-width: 1\n        fill-color: '#00DD77'\n    - text:\n        label: ${name}\n        font-size: 12\n        x-autoWrap: 70\n        x-maxDisplacement: 100\n        anchor: [0.5,-1]\n

                                                                                                                      Label with wrap

                                                                                                                      "},{"location":"styling/ysld/reference/symbolizers/text/#label-with-halo","title":"Label with halo","text":"

                                                                                                                      Surrounding labels with a halo will allow them to be visible even on complex maps with various background features. This can be accomplished using the halo family of properties. This example surrounds the label in a partially transparent white halo of radius 2:

                                                                                                                      feature-styles:\n- name: name\n  rules:\n  - symbolizers:  \n    - polygon:\n        stroke-width: 1\n        fill-color: '#00DD77'\n    - text:\n        label: ${name}\n        font-size: 12\n        x-autoWrap: 70\n        x-maxDisplacement: 100\n        halo:\n           radius: 2\n           fill-color: '#FFFFFF'\n           fill-opacity: 0.8\n        anchor: [0.5,-1]\n

                                                                                                                      Label with halo

                                                                                                                      "},{"location":"styling/ysld/reference/symbolizers/text/#grouped-labels","title":"Grouped labels","text":"

                                                                                                                      Grouping and other properties can be used to better control where labels are placed. The x-group option combines all labels with identical text into a single label. This can be useful to show only a single label for a street rather than having a label on every block of the street. The x-goodnesOfFit option determines whether or not to draw labels based on how well they fit into the available space. The x-maxDisplacement option determines the maximum distance a label can be moved to avoid overlaps.

                                                                                                                      The following example uses x-group to ensure only one label is drawn for each feature, and sets x-goodnesOfFit to zero so that labels will be drawn even if they have a poor fit:

                                                                                                                      feature-styles:\n- name: name\n  rules:\n  - title: fill-graphic\n    symbolizers:\n    - text:\n        label: ${name}\n        fill-color: '#555555'\n        font-family: SansSerif\n        font-size: 12\n        font-style: italic\n        font-weight: bold\n        x-group: true\n        x-goodnessOfFit: 0.0\n        x-maxDisplacement: 400\n

                                                                                                                      Grouped labels

                                                                                                                      "},{"location":"styling/ysld/reference/symbolizers/text/#labels-following-lines","title":"Labels following lines","text":"

                                                                                                                      In order to have a label follow a line (and not be drawn tangent to a line), the x-followLine option can be set. Other properties can be used in conjunction with this to achieve the best visual result. The following example has street names following the line of the street, with a maximum angle of 90 degrees, repeating every 150 pixels:

                                                                                                                      feature-styles:\n- rules:\n  - symbolizers:\n    - line:\n        stroke-color: '#EDEDFF'\n        stroke-width: 10\n    - text:\n        label: name\n        x-followLine: true\n        x-maxAngleDelta: 90\n        x-maxDisplacement: 400\n        x-repeat: 150\n

                                                                                                                      Labels following lines

                                                                                                                      "},{"location":"styling/ysld/reference/symbolizers/text/#labels-avoiding-obstacles","title":"Labels avoiding obstacles","text":"

                                                                                                                      The x-labelObstacle option is used to mark a different symbolizer as an obstacle that labels should avoid. This example draws labels and points on a line geometry, and also uses a point symbolizer to draw the vertices of the lines as points. It is those points which are set to be treated as obstacles to be avoided:

                                                                                                                      feature-styles:\n- rules:\n  - symbolizers:\n      - line:\n          stroke-color: '#00BBDD'\n          stroke-width: 10\n- rules:\n  - symbolizers:\n      - point:\n          geometry: ${vertices(the_geom)}\n          x-labelObstacle: true\n          symbols:\n          - mark:\n              shape: circle\n              stroke-color: '#000000'\n              fill-color: '#007777'\n      - text:\n          label: ${streetname}\n          x-maxDisplacement: 400\n          x-followLine: true\n

                                                                                                                      Labels avoiding obstacles

                                                                                                                      "},{"location":"styling/ysld/reference/symbolizers/text/#road-shields","title":"Road Shields","text":"

                                                                                                                      The graphic option is used to display a symbol behind a label. A common use for this is to display \"highway shields\" behind road numbers. This example uses a circle shape to draw state shields, and an external image to draw interstate shields, then draws road names on top. The x-graphic-resize and x-graphic-margin options are used to resize the graphics to fit the label text:

                                                                                                                      feature-styles:\n- name: state\n  rules:\n  - filter: ${level ilike 'State'}\n    symbolizers:\n    - line:\n        stroke-color: '#AAEE00'\n        stroke-width: 4\n        stroke-linecap: round\n    - text:\n        label: ${name}\n        anchor: [0.5, 0.5]\n        fill-color: black\n        font-family: SansSerif\n        font-weight: bold\n        font-size: 8\n        x-graphic-resize: stretch\n        x-graphic-margin: 6\n        graphic:\n          symbols:\n          - mark: \n              shape: circle\n              fill-color: white\n              stroke-color: black \n- name: interstate\n  rules:\n  - filter: ${level ilike 'Interstate'}\n    symbolizers:\n    - line:\n        stroke-color: '#99CC00'\n        stroke-width: 6\n        stroke-linecap: round\n    - text:\n        label: ${name}\n        anchor: [0.5, 0.5]\n        fill-color: white\n        font-family: SansSerif\n        font-weight: bold\n        font-size: 8\n        x-graphic-resize: stretch\n        x-graphic-margin: 6\n        graphic:\n          symbols:\n          - external:\n              url: interstate.png\n              format: image/png\n

                                                                                                                      Road Shields

                                                                                                                      "},{"location":"tutorials/","title":"Tutorials","text":"

                                                                                                                      Quickstart:

                                                                                                                      • Using the web administration interface
                                                                                                                      • Publishing a shapefile
                                                                                                                      • Publishing a GeoPackage
                                                                                                                      • Publishing a PostGIS table

                                                                                                                      Template:

                                                                                                                      • Freemarker Templates
                                                                                                                      • GeoRSS
                                                                                                                      • GetFeatureInfo Templates

                                                                                                                      WMS Tutorials:

                                                                                                                      • Paletted Images
                                                                                                                      • Serving Static Files
                                                                                                                      • WMS Reflector
                                                                                                                      • CQL and ECQL

                                                                                                                      Styling:

                                                                                                                      • CSS Quickstart
                                                                                                                      • MBStyle Styling Workbook
                                                                                                                      • YSLD Styling Workbook

                                                                                                                      Imagery tutorials:

                                                                                                                      • Using the ImageMosaic plugin for raster time-series data
                                                                                                                      • Using the ImageMosaic plugin for raster with time and elevation data
                                                                                                                      • Using the ImageMosaic plugin with footprint management
                                                                                                                      • Building and using an image pyramid

                                                                                                                      Imagery tutorials:

                                                                                                                      • Using the GeoTools feature-pregeneralized module

                                                                                                                      Catalogue tutorials:

                                                                                                                      • INSPIRE metadata configuration using metadata and CSW

                                                                                                                      Application server tutorials:

                                                                                                                      • Setting up a JNDI connection pool with Tomcat
                                                                                                                      • geoserver on JBoss
                                                                                                                      • Running GeoServer in Cloud Foundry
                                                                                                                      "},{"location":"tutorials/freemarker/","title":"Freemarker Templates","text":""},{"location":"tutorials/freemarker/#introduction","title":"Introduction","text":"

                                                                                                                      This tutorial will introduce you to a more in depth view of what FreeMarker templates are and how you can use the data provided to templates by GeoServer.

                                                                                                                      Freemarker is a simple yet powerful template engine that GeoServer uses to allow user customization of outputs. In particular, at the time of writing it's used to allow customization of GetFeatureInfo, GeoRSS and KML outputs.

                                                                                                                      Freemarker allows for simple variable expansions, as in ${myVarName}, expansion of nested properties, such as in ${feature.myAtt.value}, up to little programs using loops, ifs and variables. Most of the relevant information about how to approach template writing is included in the Freemarker's Designer guide and won't be repeated here: the guide, along with the KML Placemark Templates and GetFeatureInfo Templates tutorials should be good enough to give you a good grip on how a template is built.

                                                                                                                      "},{"location":"tutorials/freemarker/#template-lookup","title":"Template Lookup","text":"

                                                                                                                      GeoServer looks up templates in three different places, allowing for various levels of customization. For example given the content.ftl template used to generate WMS GetFeatureInfo content:

                                                                                                                      • Look into GEOSERVER_DATA_DIR/workspaces/<workspace>/<datastore>/<featuretype>/content.ftl to see if there is a feature type specific template
                                                                                                                      • Look into GEOSERVER_DATA_DIR/workspaces/<workspace>/<datastore>/content.ftl to see if there is a store specific template
                                                                                                                      • Look into GEOSERVER_DATA_DIR/workspaces/<workspace>/content.ftl to see if there is a workspace specific template
                                                                                                                      • Look into GEOSERVER_DATA_DIR/workspaces/content.ftl looking for a global override
                                                                                                                      • Look into GEOSERVER_DATA_DIR/templates/content.ftl looking for a global override
                                                                                                                      • Look into the GeoServer classpath and load the default template

                                                                                                                      Each templated output format tutorial should provide you with the template names, and state whether the templates can be type specific, or not. If you can't find the source files for the default template, look in the service jar of the geoserver distribution (for example, wms-x.y.z.jar). You just have to unzip it, and you'll find the xxx.ftl files GeoServer is using as the default templates.

                                                                                                                      "},{"location":"tutorials/freemarker/#common-data-models","title":"Common Data Models","text":"

                                                                                                                      Freemarker calls \"data model\" the set of data provided to the template. Each output format used by GeoServer will inject a different data model according to the information it's managing. There are three very common elements that appear in almost every template: Feature, FeatureType and FeatureCollection. Here we provide a data model of each.

                                                                                                                      The data model is a sort of tree, where each element has a name and a type. Besides basic types, we'll use:

                                                                                                                      • list: a flat list of items that you can scan thru using the FreeMarker <#list> directive;
                                                                                                                      • map: a key/value map, that you usually access using the dot notation, as in ${myMap.myKey}, and can be nested;
                                                                                                                      • listMap: a special construct that is, at the same time, a Map, and a list of the values.

                                                                                                                      Here are the data models (as you can see there are redundancies, in particular in attributes, we chose this approach to make template building easier):

                                                                                                                      FeatureType (map)

                                                                                                                      • name (string): the type name
                                                                                                                      • attributes (listMap): the type attributes
                                                                                                                        • name (string): attribute name
                                                                                                                        • namespace (string): attribute namespace URI
                                                                                                                        • prefix (string): attribute namespace prefix
                                                                                                                        • type (string): attribute type, the fully qualified Java class name
                                                                                                                        • isGeometry (boolean): true if the attribute is geometric, false otherwise

                                                                                                                      Feature (map)

                                                                                                                      • fid (string): the feature ID (WFS feature id)
                                                                                                                      • typeName (string): the type name
                                                                                                                      • attributes (listMap): the list of attributes (both data and metadata)
                                                                                                                        • name (string): attribute name
                                                                                                                        • namespace (string): attribute namespace URI
                                                                                                                        • prefix (string): attribute namespace prefix
                                                                                                                        • isGeometry (boolean): true if the attribute is geometric, false otherwise
                                                                                                                        • value: a string representation of the attribute value
                                                                                                                        • isComplex (boolean): true if the attribute is a feature (see app-schema.complex-features), false otherwise
                                                                                                                        • type (string or FeatureType): attribute type: if isComplex is false, the fully qualified Java class name; if isComplex is true, a FeatureType
                                                                                                                        • rawValue: the actual attribute value (is isComplex is true rawValue is a Feature)
                                                                                                                      • type (map)
                                                                                                                        • name (string): the type name (same as typeName)
                                                                                                                        • namespace (string): attribute namespace URI
                                                                                                                        • prefix (string): attribute namespace prefix
                                                                                                                        • title (string): The title configured in the admin console
                                                                                                                        • abstract (string): The abstract for the type
                                                                                                                        • description (string): The description for the type
                                                                                                                        • keywords (list): The keywords for the type
                                                                                                                        • metadataLinks (list): The metadata URLs for the type
                                                                                                                        • SRS (string): The layer's SRS
                                                                                                                        • nativeCRS (string): The layer's coordinate reference system as WKT

                                                                                                                      FeatureCollection (map)

                                                                                                                      • features (list of Feature, see above)
                                                                                                                      • type (FeatureType, see above)

                                                                                                                      request (map)

                                                                                                                      Contains the GetFeatureInfo request parameters and related values.

                                                                                                                      environment (map)

                                                                                                                      Allows accessing several environment variables, in particular those defined in:

                                                                                                                      • JVM system properties
                                                                                                                      • OS environment variables
                                                                                                                      • web.xml context parameters

                                                                                                                      Math (map)

                                                                                                                      Allows accessing math functions.

                                                                                                                      "},{"location":"tutorials/freemarker/#examples","title":"Examples","text":"

                                                                                                                      request

                                                                                                                      • \\${request.LAYERS}
                                                                                                                      • \\${request.ENV.PROPERTY}

                                                                                                                      environment

                                                                                                                      • \\${environment.GEOSERVER_DATA_DIR}
                                                                                                                      • \\${environment.WEB_SITE_URL}

                                                                                                                      Math

                                                                                                                      • \\${Math.max(request.NUMBER1,request.NUMBER2)}
                                                                                                                      "},{"location":"tutorials/staticfiles/","title":"Serving Static Files","text":"

                                                                                                                      You can place static files in the www subdirectory of the GeoServer data directory, and they will be served at http:/myhost:8080/geoserver/www. This means you can deploy HTML, images, or JavaScript, and have GeoServer serve them directly on the web.

                                                                                                                      This approach has some limitations:

                                                                                                                      • This approach does not make use of accelerators such as the Tomcat APR library. If you have many static files to be served at high speed, you may wish to create your own web app to be deployed along with GeoServer or use a separate web server to serve the content.

                                                                                                                      The GEOSERVER_DISABLE_STATIC_WEB_FILES property can be set to true convert the text/html and application/javascript content types to text/plain in the Content-Type HTTP response header which will prevent web pages from being served through the www directory. This will help to prevent stored cross-site scripting vulnerabilities if the www directory is not being used at all or if it is only used to serve files other than web pages, such as PDF or Word documents. The default behavior is to NOT convert these content types. This property can be set either via Java system property, command line argument (-D), environment variable or web.xml init parameter.

                                                                                                                      "},{"location":"tutorials/wmsreflector/","title":"WMS Reflector","text":""},{"location":"tutorials/wmsreflector/#overview","title":"Overview","text":"

                                                                                                                      Standard WMS requests can be quite long and verbose. For instance the following, which returns an OpenLayers application with an 800x600 image set to display the feature topp:states, with bounds set to the northwestern hemisphere by providing the appropriate bounding box:

                                                                                                                      http://localhost:8080/geoserver/wms?service=WMS&request=GetMap&version=1.1.1&format=application/openlayers&width=800&height=600&srs=EPSG:4326&layers=topp:states&styles=population&bbox=-180,0,0,90\n

                                                                                                                      Typing into a browser, or HTML editor, can be quite cumbersome and error prone. The WMS Reflector solves this problem nicely by using good default values for the options that you do not specify. Using the reflector one can shorten the above request to:

                                                                                                                      http://localhost:8080/geoserver/wms/reflect?format=application/openlayers&layers=topp:states&width=800\n

                                                                                                                      This request only specifies that you want the reflector (wms/reflect) to return an OpenLayers application (format=application/openlayers), that you want it to display the feature \"topp:states\" (layers=topp:states) and that the width should be 800 pixels (width=800). However, this will not return the exact same value as above. Instead, the reflector will zoom to the bounds of the feature and return a map that is 800 pixels wide, but with the height adjusted to the aspect ratio of the feature.

                                                                                                                      "},{"location":"tutorials/wmsreflector/#using-the-wms-reflector","title":"Using the WMS Reflector","text":"

                                                                                                                      To use the WMS reflector all one must do is specify wms/reflect? as opposed to wms? in a request. The only mandatory parameter to a WMS reflector call is the layers parameter. As stated above the reflector fills in sensible defaults for the rest of the parameters. The following table lists all the defaults used:

                                                                                                                      request getmap service wms version 1.1.1 format image/png width 512 height 512 if width is not specified srs EPSG:4326 bbox bounds of layer(s)

                                                                                                                      Any of these defaults can be overridden when specifying the request. The styles parameter is derived by using the default style as configured by GeoServer for each layer specified in the layers parameter.

                                                                                                                      Any parameter you send with a WMS request is also legitimate when requesting data from the reflector. Its strength is what it does with the parameters you do not specify, which is explored in the next section.

                                                                                                                      layers: This is the only mandatory parameter. It is a comma separated list of the layers you wish to include in your image or OpenLayers application.

                                                                                                                      format: The default output format is image/png. Alternatives include image/jpeg (good for raster backgrounds), image/png8 (8 bit colors, smaller files) and image/gif

                                                                                                                      width: Describes the width of the image, alternatively the size of the map in an OpenLayers. It defaults to 512 pixels and can be calculated based on the height and the aspect ratio of the bounding box.

                                                                                                                      height: Describes the height of the image, alternatively the map in an OpenLayers. It can be calculated based on the width and the aspect ratio of the bounding box.

                                                                                                                      bbox: The bounding box is automatically determined by taking the union of the bounds of the specified layers. In essence, it determines the extent of the map. By default, if you do not specify bbox, it will show you everything. If you have one layer of Los Angeles, and another of New York, it show you most of the United States. The bounding box, automatically set or specified, also determines the aspect ratio of the map. If you only specify one of width or height, the other will be determined based on the aspect ratio of the bounding box.

                                                                                                                      Warning

                                                                                                                      If you specify height, width and bounding box there are zero degrees of freedom, and if the aspect ratios do not match your image will be warped.

                                                                                                                      styles: You can override the default styles by providing a comma separated list with the names of styles which must be known by the server.

                                                                                                                      srs: The spatial reference system (SRS) parameter is somewhat difficult. If not specified the WMS Reflector will use EPSG:4326 / WGS84. It will support the native SRS of the layers as well, provided all layers share the same one.

                                                                                                                      "},{"location":"tutorials/wmsreflector/#example-1","title":"Example 1","text":"

                                                                                                                      Request the layer topp:states , it will come back with the default style (demographic), width (512 pixels) and height (adjusted to aspect ratio):

                                                                                                                      http://localhost:8080/geoserver/wms/reflect?layers=topp:states\n
                                                                                                                      "},{"location":"tutorials/wmsreflector/#example-2","title":"Example 2","text":"

                                                                                                                      Request the layers topp:states and sf:restricted, it will come back with the default styles, and the specified width (640 pixels) and the height automatically adjusted to the aspect ratio:

                                                                                                                      http://localhost:8080/geoserver/wms/reflect?layers=topp:states,sf:restricted&width=640\n
                                                                                                                      "},{"location":"tutorials/wmsreflector/#example-3","title":"Example 3","text":"

                                                                                                                      In the example above the sf:restricted layer is very difficult to see, because it is so small compared to the United States. To give the user a chance to get a better view, if they choose, we can return an OpenLayers application instead. Zoom in on South Dakota (SD) to see the restricted areas:

                                                                                                                      http://localhost:8080/geoserver/wms/reflect?format=application/openlayers&layers=topp:states,sf:restricted&width=640\n
                                                                                                                      "},{"location":"tutorials/wmsreflector/#example-4","title":"Example 4","text":"

                                                                                                                      Now, if you mainly want to show the restricted layer, but also provide the context, you can set the bounding box for the request. The easiest way to obtain the coordinates is to use the application in example three and the coordinates at the bottom right of the map. The coordinates displayed in OpenLayers are x , y , the reflector service expects to be given bbox=minx,miny,maxx,maxy . Make sure it contains no whitespaces and users a period (\".\") as the decimal separator. In our case, it will be bbox=-103.929,44.375,-103.633,44.500 :

                                                                                                                      http://localhost:8080/geoserver/wms/reflect?format=application/openlayers&layers=topp:states,sf:restricted&width=640&bbox=-103.929,44.375,-103.633,44.500\n
                                                                                                                      "},{"location":"tutorials/wmsreflector/#outputting-to-a-webpage","title":"Outputting to a Webpage","text":"

                                                                                                                      Say you have a webpage and you wish to include a picture that is 400 pixels wide and that shows the layer topp:states, on this page.

                                                                                                                      <img src=\"http://localhost:8080/geoserver/wms/reflect?layers=topp:states&width=400\" />\n

                                                                                                                      If you want the page to render in the browser before GeoServer is done, you should specify the height and width of the picture. You could just pick any approximate value, but it may be a good idea to look at the generated image first and then use those values. In the case of the layer above, the height becomes 169 pixels, so we can specify that as an attribute in the tag:

                                                                                                                      <img src=\"http://localhost:8080/geoserver/wms/reflect?layers=topp:states&width=400\" height=\"169\" width=\"400\"/>\n

                                                                                                                      If you are worried that the bounds of the layer may change, so that the height changes relative to the width, you may also want to specify the height in the URL to the reflector. This ensures the layer will always be centered and fit on the 400x169 canvas.

                                                                                                                      The reflector can also create a simple instance of OpenLayers that shows the layers you specify in your request. One possible application is to turn the image above into a link that refers to the OpenLayers instance for the same feature, which is especially handy if you think a minority of your users will want to take closer look. To link to this JavaScript application, you need to specify the output format of the reflector: format=application/OpenLayers:

                                                                                                                      http://localhost:8080/geoserver/wms/reflect?format=application/openlayers&width=400\n

                                                                                                                      The image above then becomes

                                                                                                                      <a href=\"http://localhost:8080/geoserver/wms/reflect?format=application/openlayers&layers=topp:states\">\n<img src=\"http://localhost:8080/geoserver/wms/reflect?layers=topp:states&width=400\" height=\"169\" width=\"400\" />\n</a>\n

                                                                                                                      (The a-tags are on separate lines for clarity, they will in fact result in a space in front and after the image).

                                                                                                                      "},{"location":"tutorials/wmsreflector/#openlayers-in-an-iframe","title":"OpenLayers in an iframe","text":"

                                                                                                                      Many people do not like iframes, and for good reasons, but they may be appropriate in this case. The following example will run OpenLayers in an iframe.

                                                                                                                      <iframe src =\"http://localhost:8080/geoserver/wms/reflect?format=application/openlayers&layers=topp:states\" width=\"100%\">\n</iframe>\n

                                                                                                                      Alternatively, you can open OpenLayers in a separate webpage and choose \"View Source code\" in your browser. By copying the HTML you can insert the OpenLayers client in your own page without using an iframe.

                                                                                                                      "},{"location":"tutorials/GetFeatureInfo/","title":"GetFeatureInfo Templates","text":"

                                                                                                                      This tutorial describes how to use GeoServer to create custom GetFeatureInfo responses.

                                                                                                                      "},{"location":"tutorials/GetFeatureInfo/#introduction","title":"Introduction","text":"

                                                                                                                      GetFeatureInfo is a WMS standard call that allows you to retrieve information about features and coverages displayed in a map. The map can be composed of various layers, and GetFeatureInfo can be instructed to return multiple feature descriptions, which may be of different types. GetFeatureInfo can generate output in various formats: GML2, plain text, GeoJSON and HTML. Templating is concerned with the HTML and GeoJSON ones. While raster layers have a few more specific customization capabilities.

                                                                                                                      • HTML output format
                                                                                                                      • GeoJSON output format
                                                                                                                      • Raster GetFeatureInfo Response Customization
                                                                                                                      "},{"location":"tutorials/GetFeatureInfo/geojson/","title":"GeoJSON output format","text":"

                                                                                                                      The default GeoJSON output uses the WFS GeoJSON encoding mechanism, producing a fixed output, it is however possible to customize the output using FreeMarker templates. GeoServer will lookup for json templates following the same rules defined for the html output, but the template files have to be named appending _json to the usual name, as below:

                                                                                                                      • header_json.ftl
                                                                                                                      • content_json.ftl
                                                                                                                      • footer_json.ftl

                                                                                                                      Moreover, unlike the html case, all three template files must be provided. In case of a multi-layer request, GeoServer will act in the following way:

                                                                                                                      • content template will be searched following the usual rules;
                                                                                                                      • since there are no default templates for GeoJSON, header and footer will be looked up in the templates directory;
                                                                                                                      • features with no content template will be encoded with the normal GeoJSON encoding, along with the customized ones.

                                                                                                                      Follow examples of json template for each type.

                                                                                                                      The header json template:

                                                                                                                      {\n \"header\":\"this is the header\",\n \"type\":\"FeatureCollection\",\n \"features\":[\n

                                                                                                                      The footer json template:

                                                                                                                      ],\n\"footer\" : \"this is the footer\"\n}\n

                                                                                                                      The content json template:

                                                                                                                      <#list features as feature>\n{\n\"content\" : \"this is the content\",\n\"type\": \"Feature\",\n\"id\" : \"${feature.fid}\",\n<#list feature.attributes as attribute>\n<#if attribute.isGeometry>\n\"geometry\": ${geoJSON.geomToGeoJSON(attribute.rawValue)},\n<!--#if-->\n<!--#list-->\n\"properties\": {\n<#list feature.attributes?filter(a -> !a.isGeometry) as attribute>\n\"${attribute.name}\": \"${attribute.value}\"\n<#if attribute_has_next>\n,\n<!--#if-->\n<!--#list-->\n}\n}\n<#if feature_has_next>\n,\n<!--#if-->\n<!--#list-->\n

                                                                                                                      As it is possible to see from the content template, a new static model geoJSON, which has the geomToGeoJSON method has been provided. It can be used to encode a valid geoJSON geometry by passing to it the raw value of the geometry attribute in the following way: ${geoJSON.geomToGeoJSON(attribute.rawValue)}.

                                                                                                                      Placing the above templates in the directory of layer tiger_roads and issuing this request, :

                                                                                                                      http://localhost:8080/geoserver/tiger/wms?SERVICE=WMS&VERSION=1.1.1&REQUEST=GetFeatureInfo&FORMAT=application/json&TRANSPARENT=true&QUERY_LAYERS=tiger:tiger_roads&LAYERS=tiger:tiger_roads&exceptions=application/vnd.ogc.se_inimage&INFO_FORMAT=application/json&FEATURE_COUNT=50&X=50&Y=50&SRS=EPSG:4326&STYLES=&WIDTH=101&HEIGHT=101&BBOX=-73.96894311918004,40.78191518783569,-73.96460866941197,40.78624963760376\n

                                                                                                                      will produce the output:

                                                                                                                      {\n  \"header\":\"this is the header\",\n  \"type\":\"FeatureCollection\",\n  \"features\":[\n     {\n        \"content\":\"this is the content\",\n        \"type\":\"Feature\",\n        \"id\":\"tiger_roads.7752\",\n        \"geometry\":{\n           \"type\":\"MultiLineString\",\n           \"coordinates\":[\n              [\n                 [\n                    -73.9674,\n                    40.7844\n                 ],\n                 [\n                    -73.9642,\n                    40.7832\n                 ],\n                 [\n                    -73.9628,\n                    40.7813\n                 ]\n              ]\n           ]\n        },\n        \"properties\":{\n           \"CFCC\":\"A41\",\n           \"NAME\":\"85th St Transverse\"\n        }\n     }\n  ],\n  \"footer\":\"this is the footer\"\n}\n

                                                                                                                      While taking care of moving header_json.ftl and footer_json.ftl into the templates directory and performing the following request against the layer group tiger-ny :

                                                                                                                      http://localhost:8080/geoserver/wms?SERVICE=WMS&VERSION=1.1.1&REQUEST=GetFeatureInfo&FORMAT=application/json&TRANSPARENT=true&QUERY_LAYERS=tiger-ny&LAYERS=tiger-ny&exceptions=application/vnd.ogc.se_inimage&INFO_FORMAT=application/json&FEATURE_COUNT=50&X=50&Y=50&SRS=EPSG:4326&STYLES=&WIDTH=101&HEIGHT=101&BBOX=-74.01161170018896,40.70833468424098,-74.00944447530493,40.710501909125014\n

                                                                                                                      will return the following result:

                                                                                                                      {\n  \"header\":\"this is the header\",\n  \"type\":\"FeatureCollection\",\n  \"features\":[\n     {\n        \"type\":\"Feature\",\n        \"id\":\"giant_polygon.1\",\n        \"geometry\":{\n           \"type\":\"MultiPolygon\",\n           \"coordinates\":[\n              [\n                 [\n                    [\n                       -180,\n                       -90\n                    ],\n                    [\n                       -180,\n                       90\n                    ],\n                    [\n                       180,\n                       90\n                    ],\n                    [\n                       180,\n                       -90\n                    ],\n                    [\n                       -180,\n                       -90\n                    ]\n                 ]\n              ]\n           ]\n        },\n        \"properties\":{\n           \"@featureType\":\"giant_polygon\",\n           \"the_geom\":{\n              \"type\":\"MultiPolygon\",\n              \"coordinates\":[\n                 [\n                    [\n                       [\n                          -180,\n                          -90\n                       ],\n                       [\n                          -180,\n                          90\n                       ],\n                       [\n                          180,\n                          90\n                       ],\n                       [\n                          180,\n                          -90\n                       ],\n                       [\n                          -180,\n                          -90\n                       ]\n                    ]\n                 ]\n              ]\n           }\n        }\n     },\n     {\n        \"content\":\"this is the content\",\n        \"type\":\"Feature\",\n        \"id\":\"tiger_roads.7672\",\n        \"geometry\":{\n           \"type\":\"MultiLineString\",\n           \"coordinates\":[\n              [\n                 [\n                    -74.0108,\n                    40.7093\n                 ],\n                 [\n                    -74.0105,\n                    40.7096\n                 ]\n              ]\n           ]\n        },\n        \"properties\":{\n           \"CFCC\":\"A41\",\n           \"NAME\":\"Broadway\"\n        }\n     },\n     {\n        \"type\":\"Feature\",\n        \"id\":\"poi.3\",\n        \"geometry\":{\n           \"type\":\"Point\",\n           \"coordinates\":[\n              -74.01053,\n              40.709387\n           ]\n        },\n        \"properties\":{\n           \"@featureType\":\"poi\",\n           \"the_geom\":{\n              \"type\":\"Point\",\n              \"coordinates\":[\n                 -74.01053,\n                 40.709387\n              ]\n           },\n           \"NAME\":\"art\",\n           \"THUMBNAIL\":\"pics/22037856-Ti.jpg\",\n           \"MAINPAGE\":\"pics/22037856-L.jpg\"\n        }\n     }\n  ],\n  \"footer\":\"this is the footer\"\n}\n

                                                                                                                      As it is possible to see, the json output comprises a mix of the output mediated by a content_json.ftl for the tiger_roads feature, and the normal output for the other features, while header and footer have been kept respectively at the top and at the bottom.

                                                                                                                      "},{"location":"tutorials/GetFeatureInfo/html/","title":"HTML output format","text":"

                                                                                                                      The default HTML output is a sequence of titled tables, each one for a different layer. The following example shows the default output for the tiger-ny basemap (included in the above cited releases, and onwards).

                                                                                                                      Default Output

                                                                                                                      "},{"location":"tutorials/GetFeatureInfo/html/#standard-templates","title":"Standard Templates","text":"

                                                                                                                      The following assumes you're already up to speed with FreeMarker templates. If you're not, read the Freemarker Templates tutorial, and the KML Placemark Templates page, which has simple examples.

                                                                                                                      The default output is generated by the standard templates, which are three:

                                                                                                                      • header.ftl
                                                                                                                      • content.ftl
                                                                                                                      • footer.ftl

                                                                                                                      The header template is invoked just once, and usually contains the start of the HTML page, along with some CSS. The default header template looks like this (as you can see, it's completely static, and it's in fact not provided with any variable you could expand):

                                                                                                                      <#-- \nHeader section of the GetFeatureInfo HTML output. Should have the <head> section, and\na starter of the <body>. It is advised that eventual css uses a special class for featureInfo,\nsince the generated HTML may blend with another page changing its aspect when using generic classes\nlike td, tr, and so on. \n-->\n<html>\n  <head>\n    <title>GeoServer GetFeatureInfo output</title>\n  </head>\n  <style type=\"text/css\">\n    table.featureInfo, table.featureInfo td, table.featureInfo th {\n        border:1px solid #ddd;\n        border-collapse:collapse;\n        margin:0;\n        padding:0;\n        font-size: 90%;\n        padding:.2em .1em;\n    }\n    table.featureInfo th{\n        padding:.2em .2em;\n        text-transform:uppercase;\n        font-weight:bold;\n        background:#eee;\n    }\n    table.featureInfo td{\n        background:#fff;\n    }\n    table.featureInfo tr.odd td{\n        background:#eee;\n    }\n    table.featureInfo caption{\n        text-align:left;\n        font-size:100%;\n        font-weight:bold;\n        text-transform:uppercase;\n        padding:.2em .2em;\n    }\n  </style>\n  <body>\n

                                                                                                                      The footer template is similar, a static template used to close the HTML document properly:

                                                                                                                      <#-- \nFooter section of the GetFeatureInfo HTML output. Should close the body and the html tag.\n-->\n  </body>\n</html>\n

                                                                                                                      The content template is the one that turns feature objects into actual HTML tables. The template is called multiple times: each time it's fed with a different feature collection, whose features all have the same type. In the above example, the template has been called once for the roads, and once for the points of interest (POI). Here is the template source:

                                                                                                                      <#-- \nBody section of the GetFeatureInfo template, it's provided with one feature collection, and\nwill be called multiple times if there are various feature collections\n-->\n<table class=\"featureInfo\">\n  <caption class=\"featureInfo\">${type.name}</caption>\n  <tr>\n<#list type.attributes as attribute>\n  <#if !attribute.isGeometry>\n    <th >${attribute.name}</th>\n  <!--#if-->\n<!--#list-->\n  </tr>\n\n<#assign odd = false>\n<#list features as feature>\n  <#if odd>\n    <tr class=\"odd\">\n  <#else>\n    <tr>\n  <!--#if-->\n  <#assign odd = !odd>\n\n  <#list feature.attributes as attribute>\n    <#if !attribute.isGeometry>\n      <td>${attribute.value}</td>\n    <!--#if-->\n  <!--#list-->\n  </tr>\n<!--#list-->\n</table>\n<br/>\n

                                                                                                                      As you can see, there is a first loop scanning type and outputting its attributes into the table header, then a second loop going over each feature in the collection (features). From each feature, the attribute collections are accessed to dump the attribute value. In both cases, geometries are skipped, since there is not much point in including them in the tabular report. In the table building code you can also see how odd rows are given the \"odd\" class, so that their background colors improve readability.

                                                                                                                      "},{"location":"tutorials/GetFeatureInfo/html/#custom-templates","title":"Custom Templates","text":"

                                                                                                                      So, what do you have to do if you want to override the custom templates? Well, it depends on which template you want to override.

                                                                                                                      header.ftl and footer.ftl are type independent, so if you want to override them you have to place a file named header.ftl or footer.ftl in the templates directory, located in your GeoServer GeoServer data directory. On the contrary, content.ftl may be generic, or specific to a feature type.

                                                                                                                      For example, let's say you would prefer a bulleted list appearance for your feature info output, and you want this to be applied to all GetFeatureInfo HTML output. In that case you would drop the following content.ftl in the templates directory:

                                                                                                                      <ul>\n<#list features as feature>\n  <li><b>Type: ${type.name}</b> (id: <em>${feature.fid}</em>):\n  <ul>\n  <#list feature.attributes as attribute>\n    <#if !attribute.isGeometry>\n      <li>${attribute.name}: ${attribute.value}</li>\n    <!--#if-->\n  <!--#list-->\n  </ul>\n  </li>\n<!--#list-->\n</ul>\n

                                                                                                                      With this template in place, the output would be:

                                                                                                                      Bulleted List Output

                                                                                                                      Looking at the output we notice that point of interest features refer to image files, which we know are stored inside the default GeoServer distribution in the demo_app/pics path. So, we could provide a POI specific override that actually loads the images.

                                                                                                                      This is easy: just put the following template in the feature type folder, which in this case is workspaces/topp/DS_poi/poi (you should refer to your Internet visible server address instead of localhost, or its IP if you have fixed IPs):

                                                                                                                      <ul>\n<#list features as feature>\n  <li><b>Point of interest, \"${feature.NAME.value}\"</b>: <br/>\n  <img src=\"http://localhost:8080/geoserver/popup_map/${feature.THUMBNAIL.value}\"/>\n  </li>\n<!--#list-->\n</ul>\n

                                                                                                                      With this additional template, the output is:

                                                                                                                      Output with Thumbnail Image

                                                                                                                      As you can see, roads are still using the generic template, whilst POI is using its own custom template.

                                                                                                                      "},{"location":"tutorials/GetFeatureInfo/html/#advanced-formatting","title":"Advanced Formatting","text":"

                                                                                                                      The value property of Feature attribute values are given by geoserver in String form, using a sensible default depending on the actual type of the attribute value. If you need to access the raw attribute value in order to apply a custom format (for example, to output \"Enabled\" or \"Disabled\" for a given boolean property, instead of the default true/false, you can just use the rawValue property instead of value. For example: ${attribute.rawValue?string(\"Enabled\", \"Disabled\")} instead of just ${attribute.value}.

                                                                                                                      "},{"location":"tutorials/GetFeatureInfo/html/#auto-escaping","title":"Auto-Escaping","text":"

                                                                                                                      Auto-escaping can be used to escape special characters so that they are displayed correctly in clients and to prevent injection. GeoServer administrators can enable or disable auto-escaping for FreeMarker template values for the HTML output format on a global or per virtual service basis. Template authors are able to override the WMS service setting to enable or disable escaping on a per template, per block or per value basis. See Auto-escaping for more information.

                                                                                                                      "},{"location":"tutorials/GetFeatureInfo/html/#accessing-static-methods","title":"Accessing static methods","text":"

                                                                                                                      It is possible to call static methods and variables from within Freemarker templates to enable more sophisticated templates. But please be aware that generally static method calls are a security liability, which can be used to make harmful things, especially when template authors can not be fully trusted. So by default this feature is disabled. The configuration parameter org.geoserver.htmlTemplates.staticMemberAccess has to specified to enabled it, for example as system property. The parameter takes a comma separated list of fully qualified class names. GeoServer allows access to static member of these classes from within templates using their simple, unqualified class name as the example below demonstrates.

                                                                                                                      The following system property enables selective access:

                                                                                                                      -Dorg.geoserver.htmlTemplates.staticMemberAccess=java.lang.String\n

                                                                                                                      This exposes the static members of java.lang.String using the variable name String in the template, which can be used in templates as follows:

                                                                                                                      <ul>\n<#list features as feature>\n  <li>${feature.NAME.value}: ${String.format(\"%.2f \u20ac\", feature.AMOUNT.rawValue)}\n  </li>\n<!--#list-->\n</ul>\n

                                                                                                                      In case of granting access to multiple classes with the same simple name, the later specified classes will be exposed with a number suffix. For example when specifying -Dorg.geoserver.htmlTemplates.staticMemberAccess=java.lang.String,com.acme.String, the statics of java.lang.String will be exposed as String while the statics of com.acme.String will be exposed as String2 and so on.

                                                                                                                      You can also enable unrestricted access by specifying a * as the next example demonstrates.

                                                                                                                      The following system property enables unrestricted access:

                                                                                                                      -Dorg.geoserver.htmlTemplates.staticMemberAccess=*\n

                                                                                                                      In this case GeoServer exposes a statics variable you can use in templates to access static members as follows:

                                                                                                                      <#assign String=statics['java.lang.String']>\n<ul>\n<#list features as feature>\n  <li>${feature.NAME.value}: ${String.format(\"%.2f \u20ac\", feature.AMOUNT.rawValue)}\n  </li>\n<!--#list-->\n</ul>\n

                                                                                                                      Note

                                                                                                                      Unrestricted access as shown above is only recommended if you can fully trust your template authors.

                                                                                                                      "},{"location":"tutorials/GetFeatureInfo/raster/","title":"Raster GetFeatureInfo Response Customization","text":"

                                                                                                                      The default output for a GetFeatureInfo request on a raster layer contains just the value of the selected pixel, one for each band of the image. For instance, in case of an application/json output format:

                                                                                                                      {\n\"type\": \"FeatureCollection\",\n\"features\": [\n  {\n    \"type\": \"Feature\",\n    \"id\": \"\",\n    \"geometry\": null,\n    \"properties\": {\n      \"GRAY_INDEX\": 124,\n    }\n  }\n],\n\"totalFeatures\": \"unknown\",\n\"numberReturned\": 1,\n\"timeStamp\": \"2021-03-19T11:33:52.587Z\",\n\"crs\": null\n}\n

                                                                                                                      If the raster layer is associated with a Style based on a ColorMap, GeoServer allows to include in the output the labels of each ColorMapEntry matching the pixel. This is controlled by a VendorOption, that needs to be added inside the RasterSymbolizer holding the ColorMap.

                                                                                                                      <sld:RasterSymbolizer>\n   <sld:ColorMap>\n       <sld:ColorMapEntry color=\"#0000FF\" quantity=\"1.0\" label=\"low\"/>\n       <sld:ColorMapEntry color=\"#FFFF00\" quantity=\"124.81173566700335\" label=\"mid\"/>\n       <sld:ColorMapEntry color=\"#FF7F00\" quantity=\"559.2041949413946\" label=\"high\"/>\n       <sld:ColorMapEntry color=\"#FF0000\" quantity=\"55537.0\" label=\"veryhigh\"/>\n   </sld:ColorMap>\n   <sld:ContrastEnhancement/>\n   <VendorOption name=\"labelInFeatureInfo\">add</VendorOption>\n</sld:RasterSymbolizer>\n

                                                                                                                      The output produced by the above RasterSymbolizer looks as follows:

                                                                                                                      {\n\"type\": \"FeatureCollection\",\n\"features\": [ \n  { \n    \"type\": \"Feature\",\n    \"id\": \"\",\n    \"geometry\": null,\n    \"properties\": {\n      \"GRAY_INDEX\": 124,\n      \"Label_GRAY_INDEX\": \"mid\"\n    }\n  }\n],\n\"totalFeatures\": \"unknown\",\n\"numberReturned\": 1,\n\"timeStamp\": \"2021-03-19T11:33:52.587Z\",\n\"crs\": null\n}\n

                                                                                                                      As it's possible to see, the label's value has been added to the output with attribute name Label_GRAY_INDEX.

                                                                                                                      The VendorOption labelInFeatureInfo supports the following values:

                                                                                                                      • add the label value is added to the normal GetFeatureInfo output.
                                                                                                                      • replace the label value replaces the pixel value in the output.
                                                                                                                      • none no label is added to the output. We obtain a normal GetFeatureInfo response.

                                                                                                                      Additionally, it is possible to customize the attribute name of the label value, by means of a second VendorOption: <VendorOption name=\"labelAttributeName\">your custom name</VendorOption>.

                                                                                                                      Assuming to have a RasterSymbolizer like this

                                                                                                                      <sld:RasterSymbolizer>\n   <sld:ColorMap>\n       <sld:ColorMapEntry color=\"#0000FF\" quantity=\"1.0\" label=\"low\"/>\n       <sld:ColorMapEntry color=\"#FFFF00\" quantity=\"124.81173566700335\" label=\"mid\"/>\n       <sld:ColorMapEntry color=\"#FF7F00\" quantity=\"559.2041949413946\" label=\"high\"/>\n       <sld:ColorMapEntry color=\"#FF0000\" quantity=\"55537.0\" label=\"very high\"/>\n   </sld:ColorMap>\n   <sld:ContrastEnhancement/>\n   <VendorOption name=\"labelInFeatureInfo\">add</VendorOption>\n   <VendorOption name=\"labelAttributeName\">custom name</VendorOption>\n</sld:RasterSymbolizer>\n

                                                                                                                      we would obtain the following output, where the attribute name of the label value has been replaced by the one specified in the labelAttributeName VendorOption:

                                                                                                                      {\n \"type\": \"FeatureCollection\",\n \"features\": [\n   {\n     \"type\": \"Feature\",\n     \"id\": \"\",\n     \"geometry\": null,\n     \"properties\": {\n       \"GRAY_INDEX\": 159,\n       \"custom name\": \"mid\"\n     }\n   }\n ],\n \"totalFeatures\": \"unknown\",\n \"numberReturned\": 1,\n \"timeStamp\": \"2021-03-19T11:50:32.433Z\",\n \"crs\": null\n}\n

                                                                                                                      We have been using the JSON output format for the example above, but the two VendorOptions work for all other GetFeatureInfo output formats.

                                                                                                                      "},{"location":"tutorials/cloud-foundry/run_cf/","title":"Running GeoServer in Cloud Foundry","text":"

                                                                                                                      Many organizations are moving applications and databases workload to cloud providers. One target platform for apps is Cloud Foundry. While it is not the best environment for intense usage of GeoServer, it is sufficient for simple usage. This tutorial is a simple guide on a basic deployment.

                                                                                                                      For more advanced deployments, refer to section Advanced Topics

                                                                                                                      "},{"location":"tutorials/cloud-foundry/run_cf/#java-environment","title":"Java Environment","text":"

                                                                                                                      Cloud Foundry runs micro services written in multiple languages using the abstraction concept of language buildpacks. The java buildpack supports OpenJDK and proprietary JREs and tomcat from version 6.0.0 to 9.x.y

                                                                                                                      "},{"location":"tutorials/cloud-foundry/run_cf/#cloud-foundry-client","title":"Cloud Foundry client","text":"

                                                                                                                      To interact with Cloud Foundry, install the command line tool for your platform.

                                                                                                                      "},{"location":"tutorials/cloud-foundry/run_cf/#get-a-cloud-foundry-trial-account-or-use-your-organization-paid-plan","title":"Get a Cloud Foundry trial account (or use your organization paid plan)","text":"

                                                                                                                      Register for a free trial account with SAP or IBM.

                                                                                                                      Warning At this time, IBM doesn't allow more 64 MB of memory in free instances which prevents from starting the geoserver. The tutorial will be updated if this changes, however, the Cloud Foundry commands and manifest files are identical because Cloud Foundry truly is multi cloud!

                                                                                                                      "},{"location":"tutorials/cloud-foundry/run_cf/#cloud-foundry-on-sap-cloud-platform","title":"Cloud Foundry on SAP Cloud Platform","text":"

                                                                                                                      Logon to your cockpit and select your trial organization

                                                                                                                      Notice the field organization name and the Cloud Foundry API endpoint.

                                                                                                                      Use those 2 values to login with the command line:

                                                                                                                      $ cf login -a https://api.cf.eu10.hana.ondemand.com -o your_org_name_trial\nAPI endpoint: https://api.cf.eu10.hana.ondemand.com\n\nEmail: your.email@here.com\n\nPassword: \nAuthenticating...\nOK\n\nTargeted org your_org_name_trial\n\nTargeted space dev\n\n\n\nAPI endpoint:   https://api.cf.eu10.hana.ondemand.com (API version: 3.88.0)\nUser:           your.email@here.com\nOrg:            your_org_name_trial\nSpace:          dev\n

                                                                                                                      And now that you are logged in, you can list the apps:

                                                                                                                      cf apps\nGetting apps in org your_org_name_trial / space dev as your.email@here.com...\nOK\n\nNo apps found\n
                                                                                                                      "},{"location":"tutorials/cloud-foundry/run_cf/#publish-geoserver","title":"Publish GeoServer","text":"

                                                                                                                      Now that you are logged in to a Cloud Foundry space, you can publish GeoServer as a servlet. Download GeoServer as a war file. Create a deployment configuration file called manifest.yml:

                                                                                                                      ---\napplications:\n- name: geoserver\npath: ./geoserver.war\nhealth-check-type: process\nrandom-route: true\nbuildpacks:\n    - java_buildpack\n

                                                                                                                      The default behavior is to use the latest OpenJRE and tomcat versions. And voil\u00e0, you're ready to publish GeoServer!:

                                                                                                                      $ cf push -f manifest.yml\nPushing from manifest to org your.email@here.com / space dev as your.email@here.com...\nUsing manifest file manifest.yml\nGetting app info...\n[...]\nPackaging files to upload...\nUploading files...\n    45.38 MiB / 45.38 MiB [=================================================================] 100.00% 3m59s\n[...]\nWaiting for app to start...\n[...]\n

                                                                                                                      This should take two minutes the first time then you can check your application status by running:

                                                                                                                      $ cf apps\nGetting apps in org 2d2950f1trial / space dev as your.email@here.com...\nOK\n\nname        requested state   instances   memory   disk   urls\ngeoserver   started           1/1         1G       1G     geoserver-humble-puku-pi.cfapps.eu10.hana.ondemand.com\n

                                                                                                                      You can open the url in your browser. HTTP is automatically redirected to HTTPS and traffic is encrypted using the Cloud Foundry platform certificates which are trusted by most browsers.

                                                                                                                      "},{"location":"tutorials/cloud-foundry/run_cf/#advanced-topics","title":"Advanced Topics","text":""},{"location":"tutorials/cloud-foundry/run_cf/#changing-the-memory-limit","title":"Changing the memory limit","text":"

                                                                                                                      Use the command cf scale, for instance to set the limit at 2Gigabytes, execute:

                                                                                                                      $cf scale geoserver -m 2G -f\nScaling app geoserver in org 2d2950f1trial / space dev as your.email@here.com...\n

                                                                                                                      This restarts the application and displays the new limit:

                                                                                                                      state     since                    cpu    memory         disk           details\n#0   running   2020-11-13 01:54:56 PM   0.4%   470.8M of 2G   250.2M of 1G\n

                                                                                                                      As for most parameters, resource limits can also be set in the manifest file

                                                                                                                      "},{"location":"tutorials/cloud-foundry/run_cf/#changing-the-manifest-file","title":"Changing the manifest file","text":"The manifest file allows you to configure:
                                                                                                                      • Resource limits (memory and cpu)
                                                                                                                      • configure the route URL
                                                                                                                      • Set environment variables, for instance to set a specific tomcat version
                                                                                                                      ---\napplications:\n- name: geoserver\npath: ./geoserver.war\nhealth-check-type: process\nrandom-route: true\nbuildpacks:\n    - https://github.com/cloudfoundry/java-buildpack.git\nenv:\n    JBP_CONFIG_TOMCAT: '{ tomcat: { version: 8.0.+ } }'\n
                                                                                                                      "},{"location":"tutorials/cloud-foundry/run_cf/#scaling-challenges","title":"Scaling challenges","text":"

                                                                                                                      Total Memory limit of 8 GB. The goal of Cloud Foundry as a micro service platform is to break a monolithic application into smaller blocks. The containers are restricted to 8 GB in IBM and SAP platforms.

                                                                                                                      "},{"location":"tutorials/cql/cql_tutorial/","title":"CQL and ECQL","text":"

                                                                                                                      CQL (Common Query Language) is a query language created by the OGC for the Catalogue Web Services specification. Unlike the XML-based Filter Encoding language, CQL is written using a familiar text-based syntax. It is thus more readable and better-suited for manual authoring.

                                                                                                                      However, CQL has some limitations. For example it cannot encode id filters, and it requires an attribute to be on the left side of any comparison operator. For this reason, GeoServer provides an extended version of CQL called ECQL. ECQL removes the limitations of CQL, providing a more flexible language with stronger similarities with SQL.

                                                                                                                      GeoServer supports the use of both CQL and ECQL in WMS and WFS requests, as well as in GeoServer's SLD dynamic symbolizers. Whenever the documentation refers to CQL, ECQL syntax can be used as well (and if not, please report that as a bug!).

                                                                                                                      This tutorial introduces the CQL/ECQL language by example. For a full reference, refer to the ECQL Reference.

                                                                                                                      "},{"location":"tutorials/cql/cql_tutorial/#getting-started","title":"Getting started","text":"

                                                                                                                      The following examples use the topp:states sample layer shipped with GeoServer. They demonstrate how CQL filters work by using the WMS CQL_FILTER vendor parameter<wms_vendor_parameters> to alter the data displayed by WMS requests. The easiest way to follow the tutorial is to open the GeoServer Map Preview for the topp:states layer. Click on the Options button at the top of the map preview to open the advanced options toolbar. The example filters can be entered in the Filter: CQL box.

                                                                                                                      topp:states preview with advanced toolbar open.

                                                                                                                      The attributes used in the filter examples are those included in the layer. For example, the following are the attribute names and values for the Colorado feature:

                                                                                                                      Attribute states.6 STATE_NAME Colorado STATE_FIPS 08 SUB_REGION Mtn STATE_ABBR CO LAND_KM 268659.501 WATER_KM 960.364 PERSONS 3294394.0 FAMILIES 854214.0 HOUSHOLD 1282489.0 MALE 1631295.0 FEMALE 1663099.0 WORKERS 1233023.0 DRVALONE 1216639.0 CARPOOL 210274.0 PUBTRANS 46983.0 EMPLOYED 1633281.0 UNEMPLOY 99438.0 SERVICE 421079.0 MANUAL 181760.0 P_MALE 0.495 P_FEMALE 0.505 SAMP_POP 512677.0"},{"location":"tutorials/cql/cql_tutorial/#simple-comparisons","title":"Simple comparisons","text":"

                                                                                                                      Let's get started with a simple example. In CQL arithmetic and comparisons are expressed using plain text. The filter PERSONS > 15000000 will select states that have more than 15 million inhabitants:

                                                                                                                      PERSONS > 15000000

                                                                                                                      The full list of comparison operators is: =, <>, >, >=, <, <=.

                                                                                                                      To select a range of values the BETWEEN operator can be used: PERSONS BETWEEN 1000000 AND 3000000:

                                                                                                                      PERSONS BETWEEN 1000000 AND 3000000

                                                                                                                      Comparison operators also support text values. For instance, to select only the state of California, the filter is STATE_NAME = 'California'. More general text comparisons can be made using the LIKE operator. STATE_NAME LIKE 'N%' will extract all states starting with an \"N\":

                                                                                                                      STATE_NAME LIKE 'N%'

                                                                                                                      It is also possible to compare two attributes with each other. MALE > FEMALE selects the states in which the male population surpasses the female one (a rare occurrence):

                                                                                                                      MALE > FEMALE

                                                                                                                      Arithmetic expressions can be computed using the +, -, *, / operators. The filter UNEMPLOY / (EMPLOYED + UNEMPLOY) > 0.07 selects all states whose unemployment ratio is above 7% (remember the sample data is very old, so don't draw any conclusion from the results!)

                                                                                                                      UNEMPLOY / (EMPLOYED + UNEMPLOY) > 0.07

                                                                                                                      "},{"location":"tutorials/cql/cql_tutorial/#id-and-list-comparisons","title":"Id and list comparisons","text":"

                                                                                                                      If we want to extract only the states with specific feature ids we can use the IN operator without specifying any attribute, as in IN ('states.1', 'states.12'):

                                                                                                                      IN ('states.1', 'states.12')

                                                                                                                      If instead we want to extract the states whose name is in a given list we can use the IN operator specifying an attribute name, as in STATE_NAME IN ('New York', 'California', 'Montana', 'Texas'):

                                                                                                                      STATE_NAME IN ('New York', 'California', 'Montana', 'Texas')

                                                                                                                      Warning

                                                                                                                      Note: id is one of a few reserved keywords in ECQL and thus an attribute (or database column) named id must be quoted, e.g. \"id\"

                                                                                                                      "},{"location":"tutorials/cql/cql_tutorial/#filter-functions","title":"Filter functions","text":"

                                                                                                                      CQL/ECQL can use any of the filter functions available in GeoServer. This greatly increases the power of CQL expressions.

                                                                                                                      For example, suppose we want to find all states whose name contains an \"m\", regardless of letter case. We can use the strToLowerCase to turn all the state names to lowercase and then use a like comparison: strToLowerCase(STATE_NAME) like '%m%':

                                                                                                                      strToLowerCase(STATE_NAME) like '%m%'

                                                                                                                      "},{"location":"tutorials/cql/cql_tutorial/#geometric-filters","title":"Geometric filters","text":"

                                                                                                                      CQL provides a full set of geometric filter capabilities. Say, for example, you want to display only the states that intersect the (-90,40,-60,45) bounding box. The filter will be BBOX(the_geom, -90, 40, -60, 45)

                                                                                                                      BBOX(the_geom, -90, 40, -60, 45)

                                                                                                                      Conversely, you can select the states that do not intersect the bounding box with the filter: DISJOINT(the_geom, POLYGON((-90 40, -90 45, -60 45, -60 40, -90 40))):

                                                                                                                      DISJOINT(the_geom, POLYGON((-90 40, -90 45, -60 45, -60 40, -90 40)))

                                                                                                                      The full list of geometric predicates is: EQUALS, DISJOINT, INTERSECTS, TOUCHES, CROSSES, WITHIN, CONTAINS, OVERLAPS, RELATE, DWITHIN, BEYOND.

                                                                                                                      "},{"location":"tutorials/feature-pregeneralized/feature-pregeneralized_tutorial/","title":"Using the GeoTools feature-pregeneralized module","text":"

                                                                                                                      Warning

                                                                                                                      The screenshots on this tutorial have not yet been updated for the 2.0.x user interface. But most all the rest of the information should be valid, and the user interface is roughly the same, but a bit more easy to use.

                                                                                                                      "},{"location":"tutorials/feature-pregeneralized/feature-pregeneralized_tutorial/#introduction","title":"Introduction","text":"

                                                                                                                      This tutorial shows how to use the geotools feature-pregeneralized module in GeoServer. The feature-pregeneralized module is used to improve performance and lower memory usage and IO traffic.

                                                                                                                      Note

                                                                                                                      Vector generalization reduces the number of vertices of a geometry for a given purpose. It makes no sense drawing a polygon with 500000 vertices on a screen. A much smaller number of vertices is enough to draw a topological correct picture of the polygon.

                                                                                                                      This module needs features with already generalized geometries, selecting the best fit geometry on demand.

                                                                                                                      The full documentation is available in GeoTools Pregeneralized Plugin documentation.

                                                                                                                      This tutorial will show two possible scenarios, explaining step by step what to do for using this module in GeoServer.

                                                                                                                      "},{"location":"tutorials/feature-pregeneralized/feature-pregeneralized_tutorial/#getting-started","title":"Getting Started","text":"

                                                                                                                      First, find the location of the GEOSERVER_DATA_DIR. This info is contained in the log file when starting GeoServer.:

                                                                                                                      ----------------------------------\n- GEOSERVER_DATA_DIR: /home/mcr/geoserver-1.7.x/1.7.x/data/release\n----------------------------------\n

                                                                                                                      Within this directory, we have to place the shape files. There is already a sub directory data which will be used. Within this sub directory, create a directory streams.

                                                                                                                      Within {GEOSERVER_DATA_DIR}/data/streams create another sub directory called 0. ( 0 meaning \"no generalized geometries\").

                                                                                                                      This tutorial is based on a shape file, which you can download from here Streams. Unzip this file into {GEOSERVER_DATA_DIR}/data/streams/0.

                                                                                                                      Look for the WEB-INF/lib/ directory of your GeoServer installation. There must be a file called gt-feature-pregeneralized-{version}-jar. This jar file includes a tool for generalizing shape files. Open a cmd line and execute the following:

                                                                                                                      cd <GEOSERVER_DATA_DIR>/data/streams/0\njava -jar <GEOSERVER_INSTALLATION>/WEB-INF/lib/gt-feature-pregeneralized-{version}.jar generalize 0/streams.shp . 5,10,20,50\n

                                                                                                                      You should see the following output:

                                                                                                                      Shape file            0/streams.shp\nTarget directory      .\nDistances             5,10,20,50\n% |################################|\n

                                                                                                                      Now there are four additional directories 5.0 , 10.0 , 20.0 , 50.0 . Look at the size of files with the extension shp within these directories, increasing the generalization distance reduces the file size.

                                                                                                                      Note

                                                                                                                      The generalized geometries can be stored in additional properties of a feature or the features can be duplicated. Mixed variations are also possible. Since we are working with shape files we have to duplicate the features.

                                                                                                                      There are two possibilities how we can deploy our generalized shape files.

                                                                                                                      1. Deploy hidden (not visible to the user)
                                                                                                                      2. Deploy each generalized shape file as a separate GeoServer feature
                                                                                                                      "},{"location":"tutorials/feature-pregeneralized/feature-pregeneralized_tutorial/#hidden-deployment","title":"Hidden Deployment","text":"

                                                                                                                      First we need a XML config file

                                                                                                                      <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<GeneralizationInfos version=\"1.0\">\n  <GeneralizationInfo dataSourceName=\"file:data/streams/0/streams.shp\"  featureName=\"GenStreams\" baseFeatureName=\"streams\" geomPropertyName=\"the_geom\">\n      <Generalization dataSourceName=\"file:data/streams/5.0/streams.shp\"  distance=\"5\" featureName=\"streams\" geomPropertyName=\"the_geom\"/>\n      <Generalization dataSourceName=\"file:data/streams/10.0/streams.shp\"  distance=\"10\" featureName=\"streams\" geomPropertyName=\"the_geom\"/>\n      <Generalization dataSourceName=\"file:data/streams/20.0/streams.shp\"  distance=\"20\" featureName=\"streams\" geomPropertyName=\"the_geom\"/>\n      <Generalization dataSourceName=\"file:data/streams/50.0/streams.shp\"  distance=\"50\" featureName=\"streams\" geomPropertyName=\"the_geom\"/>      \n  </GeneralizationInfo>\n</GeneralizationInfos>\n

                                                                                                                      Save this file as geninfo_shapefile.xml into {GEOSERVER_DATA_DIR}/data/streams.

                                                                                                                      Note

                                                                                                                      The dataSourceName attribute in the XML config is not interpreted as a name, it could be the URL for a shape file or for a property file containing properties for data store creation (e. g. jdbc connect parameters). Remember, this is a hidden deployment and no names are needed. The only official name is the value of the attribute featureName in the GeneralizationInfo Element.

                                                                                                                      Start GeoServer and go to Config\u2192Data\u2192DataStores\u2192New and fill in the form

                                                                                                                      Press Submit.

                                                                                                                      The next form you see is

                                                                                                                      Note

                                                                                                                      RepositoryClassName and GeneralizationInfosProviderClassName have default values which suit for GeoTools, not for GeoServer. Change GeoTools to GeoServer in the package names to instantiate the correct objects for GeoServer. GeneralizationInfosProviderParam could be an URL or a datastore from the GeoServer catalog. A datastore is referenced by using workspacename:datastorename. This makes sense if you have your own implementation for the GeneralizationInfosProvider interface and this implementation reads the infos from a database.

                                                                                                                      The configuration should look like this

                                                                                                                      Press Submit, afterward a form for the feature type opens.

                                                                                                                      Alter the Style to line, SRS is 26713 and press the Generate button labeled by Bounding Box.

                                                                                                                      Afterward, press Submit, Apply and Save.

                                                                                                                      Examine the result by pressing \"My GeoServer, Demo and Map Preview. In this list there must be an entry topp:GenStreams. Press it and you will see

                                                                                                                      Now start zooming in and out and look at the log file of GeoServer. If the deployment is correct you should see something like this:

                                                                                                                      May 20, 2009 4:53:05 PM org.geotools.data.gen.PreGeneralizedFeatureSource logDistanceInfo\nINFO: Using generalizsation: file:data/streams/20.0/streams.shp streams the_geom 20.0\nMay 20, 2009 4:53:41 PM org.geotools.data.gen.PreGeneralizedFeatureSource logDistanceInfo\nINFO: Using generalizsation: file:data/streams/5.0/streams.shp streams the_geom 5.0\nMay 20, 2009 4:54:08 PM org.geotools.data.gen.PreGeneralizedFeatureSource logDistanceInfo\nINFO: Using generalizsation: file:data/streams/5.0/streams.shp streams the_geom 5.0\nMay 20, 2009 4:54:09 PM org.geotools.data.gen.PreGeneralizedFeatureSource logDistanceInfo\nINFO: Using generalizsation: file:data/streams/20.0/streams.shp streams the_geom 20.0\n
                                                                                                                      "},{"location":"tutorials/feature-pregeneralized/feature-pregeneralized_tutorial/#public-deployment","title":"Public Deployment","text":"

                                                                                                                      First we have to configure all our shape files

                                                                                                                      The Feature Data Set ID for the other shape files is

                                                                                                                      1. Streams_5
                                                                                                                      2. Streams_10
                                                                                                                      3. Streams_20
                                                                                                                      4. Streams_50

                                                                                                                      The URL needed for the other shape files

                                                                                                                      1. file:data/streams/5.0/streams.shp
                                                                                                                      2. file:data/streams/10.0/streams.shp
                                                                                                                      3. file:data/streams/20.0/streams.shp
                                                                                                                      4. file:data/streams/50.0/streams.shp

                                                                                                                      Each feature needs an Alias, here it is streams_0. For the other shape files use

                                                                                                                      1. streams_5
                                                                                                                      2. streams_10
                                                                                                                      3. streams_20
                                                                                                                      4. streams_50

                                                                                                                      Check the result by pressing My GeoServer, Demo and Map Preview. You should see your additional layers.

                                                                                                                      No we need another XML configuration file

                                                                                                                      <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<GeneralizationInfos version=\"1.0\">\n  <GeneralizationInfo dataSourceNameSpace=\"topp\" dataSourceName=\"Streams_0\"  featureName=\"GenStreams2\" baseFeatureName=\"streams\" geomPropertyName=\"the_geom\">\n      <Generalization dataSourceNameSpace=\"topp\" dataSourceName=\"Streams_5\"  distance=\"5\" featureName=\"streams\" geomPropertyName=\"the_geom\"/>\n      <Generalization dataSourceNameSpace=\"topp\" dataSourceName=\"Streams_10\"  distance=\"10\" featureName=\"streams\" geomPropertyName=\"the_geom\"/>\n      <Generalization dataSourceNameSpace=\"topp\" dataSourceName=\"Streams_20\"  distance=\"20\" featureName=\"streams\" geomPropertyName=\"the_geom\"/>\n      <Generalization dataSourceNameSpace=\"topp\" dataSourceName=\"Streams_50\"  distance=\"50\" featureName=\"streams\" geomPropertyName=\"the_geom\"/>       \n  </GeneralizationInfo>\n</GeneralizationInfos>\n

                                                                                                                      Save this file as geninfo_shapefile2.xml into {GEOSERVER_DATA_DIR}/data/streams.

                                                                                                                      Create the pregeneralized datastore

                                                                                                                      Now we use the CatalogRepository class to find our needed data stores

                                                                                                                      Last step

                                                                                                                      In the Map Preview you should find topp:GenStreams2 and all other generalizations. Test in the same manner we discussed in the hidden deployment and you should see something like this in the GeoServer log:

                                                                                                                      May 20, 2009 6:11:06 PM org.geotools.data.gen.PreGeneralizedFeatureSource logDistanceInfo\nINFO: Using generalizsation: Streams_20 streams the_geom 20.0\nMay 20, 2009 6:11:08 PM org.geotools.data.gen.PreGeneralizedFeatureSource logDistanceInfo\nINFO: Using generalizsation: Streams_10 streams the_geom 10.0\nMay 20, 2009 6:11:12 PM org.geotools.data.gen.PreGeneralizedFeatureSource logDistanceInfo\nINFO: Using generalizsation: Streams_10 streams the_geom 10.0\n
                                                                                                                      "},{"location":"tutorials/feature-pregeneralized/feature-pregeneralized_tutorial/#conclusion","title":"Conclusion","text":"

                                                                                                                      This is only a very simple example using shape files. The plugin architecture allows you to get your data and generalizations from anywhere. The used dataset is a very small one, so you will not feel a big difference in response time. Having big geometries (in the sense of many vertices) and creating maps with some different layers will show the difference.

                                                                                                                      "},{"location":"tutorials/georss/georss/","title":"GeoRSS","text":"

                                                                                                                      GeoServer supports GeoRSS as an output format allowing you to serve features as an RSS feed.

                                                                                                                      "},{"location":"tutorials/georss/georss/#quick-start","title":"Quick Start","text":"

                                                                                                                      If you are using a web browser which can render RSS feeds simply visit the URL http://localhost:8080/geoserver/wms/reflect?layers=states&format=rss in your browser. This is assuming a local GeoServer instance is running with an out of the box configuration. You should see a result that looks more or less like this:

                                                                                                                      topp:states rss feed

                                                                                                                      "},{"location":"tutorials/georss/georss/#templating","title":"Templating","text":"

                                                                                                                      GeoServer uses FreeMarker templates to customize the returned GeoRSS feed. If you are not familiar with FreeMarker templates you may wish to read the Freemarker Templates tutorial, and the KML Placemark Templates page, which has simple examples.

                                                                                                                      Three template files are currently supported:

                                                                                                                      • title.ftl
                                                                                                                      • description.ftl
                                                                                                                      • link.ftl

                                                                                                                      Each of these files may be used to customize the associated field in the GeoRSS feed.

                                                                                                                      "},{"location":"tutorials/georss/georss/#ajax-map-mashups","title":"Ajax Map Mashups","text":"

                                                                                                                      Note

                                                                                                                      For Ajax map mashups to work, the GeoServer instance must be visible to the Internet (i.e. using the address localhost will not work).

                                                                                                                      "},{"location":"tutorials/georss/georss/#google-maps","title":"Google Maps","text":"

                                                                                                                      How to create a Google Maps mashup with a GeoRSS overlay produced by GeoServer.

                                                                                                                      1. Obtain a Google Maps API Key from Google.

                                                                                                                      2. Create an html file called gmaps.html:

                                                                                                                        <!DOCTYPE html PUBLIC \"-//W3C//DTD XHTML 1.0 Strict//EN\" \"http://www.w3.org    R/xhtml1/DTD/xhtml1-strict.dtd\">\n<html xmlns=\"http://www.w3.org/1999/xhtml\">\n    <head>\n    <meta http-equiv=\"content-type\" content=\"text/html; charset=utf-8\"/>\n    <title>Google Maps JavaScript API Example<    itle>\n    <script src=\"http://maps.google.com/maps?file=api&amp;v=2.x&amp;key=<INSERT MAPS API KEY HERE>\" type=\"text/javascript\"></script>\n\n    <script type=\"text/javascript\">\n    //<![CDATA[\n        function load() {\n            if (GBrowserIsCompatible()) {\n                var map = new GMap2(document.getElementById(\"map\"));\n                map.addControl(new GLargeMapControl());\n                map.setCenter(new GLatLng(40,-98), 4);\n                var geoXml = new GGeoXml(\"<INSERT GEOSERVER URL HERE>/geoserver/wms/reflect?layers=states&format=rss\");\n                map.addOverlay(geoXml);\n            }\n        }\n    //]]>\n    </script>\n\n    </head>\n    <body onload=\"load()\" onunload=\"GUnload()\">\n        <div id=\"map\" style=\"width: 800px; height: 600px\"></div>\n    </body>\n</html>\n
                                                                                                                      3. Visit gmaps.html in your web browser.

                                                                                                                      Note

                                                                                                                      The version of the google maps api must be 2.x, and not just 2 You must insert your specific maps api key, and geoserver base url

                                                                                                                      "},{"location":"tutorials/georss/georss/#yahoo-maps","title":"Yahoo Maps","text":"

                                                                                                                      How to create a Yahoo! Maps mashup with a GeoRSS overlay produced by GeoServer.

                                                                                                                      1. Obtain a <Yahoo Maps Application ID <http://search.yahooapis.com/webservices/register_application>`_ from Yahoo.

                                                                                                                      2. Create an html file called ymaps.html:

                                                                                                                        <html>\n    <head>\n    <title>Yahoo! Maps GeoRSS Overlay Example<    itle>\n    <script src=\"http://api.maps.yahoo.com/ajaxymap?v=3.0&appid=<INSERT APPLICATION ID HERE>\" type=\"text/javascript\"></script>\n    <script type=\"text/javascript\" language=\"JavaScript\">\n\n        function StartYMap() {\n            var map = new YMap(document.getElementById('ymap')); \n            map.addPanControl();\n            map.addZoomShort();\n\n            function doStart(eventObj) {\n                var defaultEventObject = eventObj;\n                //eventObj.ThisMap [map object]\n                //eventObj.URL [argument]\n                //eventObj.Data [processed input]\n            }\n\n            function doEnd(eventObj) {\n                var defaultEventObject = eventObj;\n                //eventObj.ThisMap [map object]\n                //eventObj.URL [argument]\n                //eventObj.Data [processed input]\n                map.smoothMoveByXY(new YCoordPoint(10,50));\n            }\n\n            YEvent.Capture(map,EventsList.onStartGeoRSS, function(eventObj) { doStart(eventObj); });\n            YEvent.Capture(map,EventsList.onEndGeoRSS, function(eventObj) { doEnd(eventObj); });\n\n            map.addOverlay(new YGeoRSS('http://<INSERT GEOSERVER URL HERE>/geoserver/wms/reflect?layers=states&format=rss'));\n        }\n\n    window.onload = StartYMap;\n     </script>\n      </head>\n      <body>\n           <div id=\"ymap\" style=\"width: 800px; height: 600px; left:2px; top:2px\"></div>\n     </body>\n</html>\n
                                                                                                                      3. Visit ymaps.html in your web browser.

                                                                                                                      Note

                                                                                                                      The version of the yahoo maps api must be 3.0 You must insert your specific application id, and geoserver base url

                                                                                                                      "},{"location":"tutorials/georss/georss/#microsoft-virtual-earth","title":"Microsoft Virtual Earth","text":"

                                                                                                                      Note

                                                                                                                      Non Internet Explorer Users*: GeoRSS overlays are only supported in Internet Explorer, versions greater than 5.5.

                                                                                                                      How to create a Microsoft Virtual Earth mashup with a GeoRSS overlay produced by GeoServer.

                                                                                                                      Note

                                                                                                                      To access a GeoRSS feed from Microsoft Virtual Earth the file (ve.html) must be accessed from a Web Server, IE. It will not work if run from local disk.

                                                                                                                      1. Create an html file called ve.html. Note: You must insert your specific maps api key, and geoserver base url:

                                                                                                                        <html>\n  <head>\n    <script src=\"http://dev.virtualearth.net/mapcontrol/v4/mapcontrol.js\"></script>\n    <script>\n     var map;\n\n     function OnPageLoad()\n     {\n        map = new VEMap('map');\n        map.LoadMap();\n\n        var veLayerSpec = new VELayerSpecification();\n        veLayerSpec.Type = VELayerType.GeoRSS;\n        veLayerSpec.ID = 'Hazards';\n    veLayerSpec.LayerSource = 'http://<INSERT GEOSERVER URL HERE>/geoserver/wms/reflect?layers=states&format=rss';\n    veLayerSpec.Method = 'get';\n    map.AddLayer(veLayerSpec);\n    }\n   </script>\n </head>\n <body onload=\"OnPageLoad();\">\n    <div id=\"map\" style=\"position:relative;width:800px;height:600px;\"></div>\n  </body>\n\n</html>\n
                                                                                                                      2. Visit ve.html in your web browser. You should see the following:

                                                                                                                      Virtual Earth

                                                                                                                      "},{"location":"tutorials/imagemosaic_footprint/imagemosaic_footprint/","title":"Using the ImageMosaic plugin with footprint management","text":""},{"location":"tutorials/imagemosaic_footprint/imagemosaic_footprint/#introduction","title":"Introduction","text":"

                                                                                                                      This step-by-step tutorial describes how to associate Footprint to a raster data using the ImageMosaic plugin.

                                                                                                                      Footprint is a Shape used as a Mask for the mosaic. Masking can be useful for hiding pixels which are meaningless, or for enhancing only few regions of the image in respect to others.

                                                                                                                      This tutorial assumes knowledge of the concepts explained in ImageMosaic section.

                                                                                                                      This tutorial contains two sections:

                                                                                                                      • The first section, Configuration, describes the possible configurations needed to set up an ImageMosaic with footprint.
                                                                                                                      • The second section, Examples, provides examples of configuration of an ImageMosaic with footprint.
                                                                                                                      "},{"location":"tutorials/imagemosaic_footprint/imagemosaic_footprint/#configuration","title":"Configuration","text":"

                                                                                                                      Footprint can be configured in three different ways:

                                                                                                                      1. By using for each mosaic granule a Sidecar File, a Shapefile with the same name of the granule which contains the footprint for it;
                                                                                                                      2. By using a single Shapefile called footprints.shp which contains all the footprints for each granule; each footprint is associated to a granule with the location attribute;
                                                                                                                      3. By using a file called footprints.properties .

                                                                                                                      The last option should be used when the first two are not available and requires to write the following piece of code inside the footprints.properties file:

                                                                                                                      footprint_source=*location of the Shapefile*\nfootprint_filter=*filter on the Shapefile searching for the attribute associated to each granule*\n

                                                                                                                      For example if a Shapefile called fakeShapeFile stores the various footprints in a table like this, where each Name attribute is referred to a granule file:

                                                                                                                      And the associated granules are:

                                                                                                                      • ortho_1-1_1n_s_la087_2010_1.tif
                                                                                                                      • ortho_2-2_1n_s_la075_2010_1.tif
                                                                                                                      • ortho_1-1_1n_s_la103_2010_1.tif
                                                                                                                      • and so on ...

                                                                                                                      The associated footprints.properties file must be like this:

                                                                                                                      footprint_source=fakeShapeFile.shp\nfootprint_filter=Name=strSubstring(granule.location, 0, strLength(granule.location) - 4)\n

                                                                                                                      The substring operation is done for comparing the footprint attribute names and the granule names without the .tif extension.

                                                                                                                      There are three possible behaviours for Footprint:

                                                                                                                      • None: simply doesn't use the Footprint and behaves like a standard ImageMosaic layer;
                                                                                                                      • Transparent: adds an alpha band of 0s on the image portions outside of the Footprint making them transparent, typically used for RGB data;
                                                                                                                      • Cut: set the background value on the image portions outside of the Footprint, typically used for GrayScale data.

                                                                                                                      The behaviour must be set directly on the Layer configuration page.

                                                                                                                      Another feature of the Footprint is the possibility to calculate an Inset of the image. Inset is a reduction of the footprint border by a value defined by the user which is typically used for removing the compression artifacts. This feature can be achieved by adding the following code inside footprints.properties (in case of the first two configurations this file must be added):

                                                                                                                      footprint_inset=*value in the shapefile u.o.m.*\nfootprint_inset_type=*full/border*\n

                                                                                                                      Full inset type calculates the inset for each footprint side while Border does the same operation but those straight lines that overlap the image bounds are avoided; this last parameter is useful for images already cut in a regular grid.

                                                                                                                      Each modification of the footprints.properties file requires to Reload GeoServer. This operation can be achieved by going to Server Status and clicking on the Reload button on the bottom-right side of the page.

                                                                                                                      The two datasets used in the tutorial can be downloaded here: Mosaic with a single image which represents Boulder (Colorado), Mosaic with multiple images which represents Italy. The first can be used for testing footprint configuration with a Sidecar File and the second for the other two configurations.

                                                                                                                      "},{"location":"tutorials/imagemosaic_footprint/imagemosaic_footprint/#examples","title":"Examples","text":"

                                                                                                                      Here are presented a few steps for configuring a new ImageMosaic layer with footprint.

                                                                                                                      "},{"location":"tutorials/imagemosaic_footprint/imagemosaic_footprint/#step-1-create-a-new-imagemosaic-layer","title":"Step 1: Create a new ImageMosaic Layer","text":"

                                                                                                                      As seen before an ImageMosaic data store can be created by going to Stores \u2192 Add New Store \u2192 ImageMosaic.

                                                                                                                      An associated Layer can be created by going to Layers \u2192 Add New Resource, choosing the name of the data store created above and then clicking on the publish button.

                                                                                                                      "},{"location":"tutorials/imagemosaic_footprint/imagemosaic_footprint/#step-2-configuring-a-new-layer-for-the-mosaic","title":"Step 2: Configuring a new Layer for the Mosaic","text":"

                                                                                                                      Inside the new page the only field which is interesting for this tutorial is FootprintBehavior:

                                                                                                                      The user can set one of the three values for the Footprint behaviour as described above.

                                                                                                                      After that, the user must confirm the modification by clicking on the Save button on the bottom side of the page.

                                                                                                                      "},{"location":"tutorials/imagemosaic_footprint/imagemosaic_footprint/#step-3-example-results","title":"Step 3: Example Results","text":"

                                                                                                                      Here are presented the results for each dataset.

                                                                                                                      "},{"location":"tutorials/imagemosaic_footprint/imagemosaic_footprint/#footprint-configured-with-sidecar-file","title":"Footprint configured with Sidecar File","text":"

                                                                                                                      This is an example of mosaic without applying Footprint:

                                                                                                                      And this is the result of setting FootprintBehavior to Cut:

                                                                                                                      Background is gray because in this example the BackgroundValues field has been set to -20000.

                                                                                                                      If an Inset is added, the final mosaic is:

                                                                                                                      The footprints.properties file is:

                                                                                                                      footprint_inset=0.01\nfootprint_inset_type=full\n

                                                                                                                      Note

                                                                                                                      Remember that each modification on footprints.properties requires a Reload of GeoServer for seeing the results.

                                                                                                                      Note

                                                                                                                      When configuring this mosaic you must set the declared CRS field to \"EPSG:4326\".

                                                                                                                      "},{"location":"tutorials/imagemosaic_footprint/imagemosaic_footprint/#footprint-configured-with-footprintsshp","title":"Footprint configured with footprints.shp","text":"

                                                                                                                      This is another example of mosaic without Footprint:

                                                                                                                      And now after setting FootprintBehavior to Transparent (no Inset is used) on the Layer:

                                                                                                                      "},{"location":"tutorials/imagemosaic_footprint/imagemosaic_footprint/#footprint-configured-with-footprintsproperties","title":"Footprint configured with footprints.properties","text":"

                                                                                                                      Note

                                                                                                                      For testing this functionality the user must rename all the footprints.xxx files to mask.xxx.

                                                                                                                      The result of setting FootprintBehavior to Transparent, Inset type to border and Inset value to 0.00001 is:

                                                                                                                      The footprints.properties file is:

                                                                                                                      footprint_source=mask.shp\nfootprint_inset=0.00001\nfootprint_inset_type=border\n
                                                                                                                      "},{"location":"tutorials/imagemosaic_footprint/imagemosaic_footprint/#raster-masking","title":"Raster Masking","text":"

                                                                                                                      From 2.8.x version, GeoServer is able to support also Raster Masks. Those masks can be internal or external (in which case the mask files should use the .msk extension), for each file. It is crucial that mask files should have the same pixel size, georeferencing and CRS as the image they are masking.

                                                                                                                      It must be pointed out that external/internal masks may have overviews like the related original images.

                                                                                                                      More information about Mask bands may be found at the GDAL Mask Band Page

                                                                                                                      A footprints.properties file that would exploit raster masks would be as follows:

                                                                                                                      footprint_source=raster\n

                                                                                                                      Note

                                                                                                                      Raster masks do not support to control inset.

                                                                                                                      Below you may find an example of configuring a Mosaic with Raster masks:

                                                                                                                      "},{"location":"tutorials/imagemosaic_footprint/imagemosaic_footprint/#step-1-create-a-new-imagemosaic-layer_1","title":"Step 1: Create a new ImageMosaic Layer","text":"

                                                                                                                      Download data from the following link and configure an ImageMosaic layer called rastermask without changing default configuration parameters.

                                                                                                                      Zip file contains two images and their related .msk files. For this example the two masks are two simple squares.

                                                                                                                      "},{"location":"tutorials/imagemosaic_footprint/imagemosaic_footprint/#step-2-watch-the-layer-using-layerpreview","title":"Step 2: Watch the layer using LayerPreview","text":"

                                                                                                                      Go to LayerPreview \u2192 rastermask \u2192 OpenLayers. The result should be similar to the one below.

                                                                                                                      "},{"location":"tutorials/imagemosaic_footprint/imagemosaic_footprint/#step-3-change-the-footprint-behavior","title":"Step 3: Change the Footprint Behavior","text":"

                                                                                                                      Change the FootprintBehavior parameter to Transparent. Cut value should not be used since the files are RGB.

                                                                                                                      "},{"location":"tutorials/imagemosaic_footprint/imagemosaic_footprint/#step-4-check-the-result","title":"Step 4: Check the result","text":"

                                                                                                                      Go to LayerPreview \u2192 rastermask \u2192 OpenLayers. The result should be changed now.

                                                                                                                      "},{"location":"tutorials/imagemosaic_footprint/imagemosaic_footprint/#multilevel-geometry-masking","title":"Multilevel Geometry Masking","text":"

                                                                                                                      From 2.14.x version, GeoServer is able to support also multilevel overviews geometries (A geometry footprint for each overview, being stored on a separate sidecar file).

                                                                                                                      A footprints.properties file that would exploit multiple WKB sidecar files would be as follows:

                                                                                                                      footprint_source=multisidecar\nfootprintLoaderSPI=org.geotools.coverage.grid.io.footprint.WKBLoaderSPI\noverviewsFootprintLoaderSPI=org.geotools.coverage.grid.io.footprint.WKBLoaderSPI\noverviewsRoiInRasterSpace=True\noverviewsSuffixFormat=_%d\n

                                                                                                                      Notes:

                                                                                                                      • footprintLoaderSPI: Contains the fully qualified name of the SPI implementation for main footprint loading (Optional property. When not specified, the proper footprint loader will be automatically found by scanning the available SPIs). Currently supported values are:

                                                                                                                        • org.geotools.coverage.grid.io.footprint.WKBLoaderSPI for WKB overviews
                                                                                                                        • org.geotools.coverage.grid.io.footprint.WKTLoaderSPI for WKT overviews
                                                                                                                        • org.geotools.gce.imagemosaic.catalog.ShapeFileLoaderSPI for Shapefile overviews
                                                                                                                      • overviewsFootprintLoaderSPI: Contains the fully qualified name of the SPI implementation for overviews footprints loading (Optional property. When not specified, same loader as footprintLoaderSpi will be used if provided);

                                                                                                                      • overviewsRoiInRasterSpace: Specifies whether the overviews ROI footprint geometrys are in raster space or model space coordinates. (Optional property. Default is False, meaning that overviews footprints are in model space);

                                                                                                                      • overviewsSuffixFormat: Specifies the String format syntax used to define the suffix of the overviews footprints file name. (Optional property. Default is %d). To give an example, if granule file is R1C1.tif and related 1st overview footprint is stored into R1C1_1.wkt, overviewsSuffixFormat should be %d. In case 1st overview footprint is stored into R1C1-Ov1.wkt, overviewsSuffixFormat should be -Ov%d.

                                                                                                                      Same steps of previous section are required to configure an ImageMosaic layer with footprint management.

                                                                                                                      "},{"location":"tutorials/imagemosaic_timeseries/imagemosaic_time-elevationseries/","title":"Using the ImageMosaic plugin for raster with time and elevation data","text":""},{"location":"tutorials/imagemosaic_timeseries/imagemosaic_time-elevationseries/#introduction","title":"Introduction","text":"

                                                                                                                      This tutorial is the following of Using the ImageMosaic plugin for raster time-series data and explains how manage an ImageMosaic using both Time and Elevation attributes.

                                                                                                                      The dataset used is a set of raster images used in weather forecast, representing the temperature in a certain zone at different times and elevations.

                                                                                                                      All the steps explained in chapter Configurations of ImageMosaic section are still the same.

                                                                                                                      This tutorial explains just how to configure the elevationregex.properties that is an additional configuration file needed, and how to modify the indexer.properties.

                                                                                                                      The dataset used is different so also a fix to the timeregex.properties used in the previous tutorial is needed.

                                                                                                                      Will be shown also how query GeoServer asking for layers specifying both time and elevation dimensions.

                                                                                                                      The dataset used in the tutorial can be downloaded Here

                                                                                                                      "},{"location":"tutorials/imagemosaic_timeseries/imagemosaic_time-elevationseries/#configuration-examples","title":"Configuration examples","text":"

                                                                                                                      The additional configurations needed in order to handle also the elevation attributes are:

                                                                                                                      • Improve the previous version of the indexer.properties file
                                                                                                                      • Add the elevationregex.properties file in order to extract the elevation dimension from the filename
                                                                                                                      "},{"location":"tutorials/imagemosaic_timeseries/imagemosaic_time-elevationseries/#indexerproperties","title":"indexer.properties:","text":"

                                                                                                                      Here the user can specify the information that needs GeoServer for creating the table in the database.

                                                                                                                      In this case the time values are stored in the column ingestion as shown in the previous tutorial but now is mandatory specify the elevation column too.

                                                                                                                      Caching=false\nTimeAttribute=ingestion\nElevationAttribute=elevation\nSchema=*the_geom:Polygon,location:String,ingestion:java.util.Date,elevation:Double\nPropertyCollectors=TimestampFileNameExtractorSPI[timeregex](ingestion),DoubleFileNameExtractorSPI[elevationregex](elevation)\n
                                                                                                                      "},{"location":"tutorials/imagemosaic_timeseries/imagemosaic_time-elevationseries/#elevationregexproperties","title":"elevationregex.properties:","text":"

                                                                                                                      Remember that every tif file must follow this naming convention:

                                                                                                                      {coveragename}_{timestamp}_[{elevation}].tif\n

                                                                                                                      As in the timeregex property file the user must specify the pattern that the elevation in the file name looks like. In this example it consists of 4 digits, a dot '.' and other 3 digits.

                                                                                                                      an example of filename, that is used in this tutorial is:

                                                                                                                      gfs50kmTemperature20130310T180000000Z_0600.000_.tiff\n

                                                                                                                      The GeoServer ImageMosaic plugin scans the filename and search for the first occurrence that match with the pattern specified. Here the content of elevationregex.properties:

                                                                                                                      regex=(?<=_)(\\\\d{4}\\\\.\\\\d{3})(?=_)\n
                                                                                                                      "},{"location":"tutorials/imagemosaic_timeseries/imagemosaic_time-elevationseries/#timeregexproperties","title":"timeregex.properties:","text":"

                                                                                                                      As you can see the time in this dataset is specified as ISO8601 format:

                                                                                                                      20130310T180000000Z\n

                                                                                                                      Instead of the form yyyymmdd as in the previous tutorial. So the regex to specify in timeregex.properties is:

                                                                                                                      regex=[0-9]{8}T[0-9]{9}Z(\\?!.\\*[0-9]{8}T[0-9]{9}Z.\\*)\n
                                                                                                                      "},{"location":"tutorials/imagemosaic_timeseries/imagemosaic_time-elevationseries/#coverage-based-on-filestore","title":"Coverage based on filestore","text":"

                                                                                                                      Once the mosaic configuration is ready the store mosaic could be loaded on GeoServer.

                                                                                                                      The steps needed are the same shown the previous chapter. After the store is loaded and a layer published note the differences in WMS Capabilities document and in the table on postgres.

                                                                                                                      "},{"location":"tutorials/imagemosaic_timeseries/imagemosaic_time-elevationseries/#wms-capabilities-document","title":"WMS Capabilities document","text":"

                                                                                                                      The WMS Capabilities document is a bit different, now there is also the dimension elevation. In this example both time and elevation dimension are set to List .

                                                                                                                      <Dimension name=\"time\" default=\"current\" units=\"ISO8601\">\n    2013-03-10T00:00:00.000Z,2013-03-11T00:00:00.000Z,2013-03-12T00:00:00.000Z,2013-03-13T00:00:00.000Z,2013-03-14T00:00:00.000Z,2013-03-15T00:00:00.000Z,2013-03-16T00:00:00.000Z,2013-03-17T00:00:00.000Z,2013-03-18T00:00:00.000Z\n</Dimension>\n<Dimension name=\"elevation\" default=\"200.0\" units=\"EPSG:5030\" unitSymbol=\"m\">\n    200.0,300.0,500.0,600.0,700.0,850.0,925.0,1000.0\n</Dimension>\n
                                                                                                                      "},{"location":"tutorials/imagemosaic_timeseries/imagemosaic_time-elevationseries/#the-table-on-postgres","title":"The table on postgres","text":"

                                                                                                                      With the elevation support enabled the table on postgres has, for each image, the field elevation filled with the elevation value.

                                                                                                                      Note

                                                                                                                      The user must create manually the index on the table in order to speed up the search by attribute.

                                                                                                                      "},{"location":"tutorials/imagemosaic_timeseries/imagemosaic_time-elevationseries/#query-layer-on-timestamp","title":"Query layer on timestamp:","text":"

                                                                                                                      In order to display a snapshot of the map at a specific time instant and elevation you have to pass in the request those parameters.

                                                                                                                      • &time= < pattern > , as shown before,
                                                                                                                      • &elevation= < pattern > where you pass the value of the elevation.

                                                                                                                      For example if an user wants to obtain the temperature coverage images for the day 2013-03-10 at 6 PM at elevation 200 meters must append to the request:

                                                                                                                      &time=2013-03-10T00:00:00.000Z&elevation=200.0\n

                                                                                                                      Same day at elevation 300.0 meters:

                                                                                                                      &time=2013-03-10T00:00:00.000Z&elevation=300.0\n

                                                                                                                      Note that if just the time dimension is append to the request will be displayed the elevation 200 meters (if present) because of the default attribute of the tag <Dimension name=\"elevation\" ... in the WMS Capabilities document is set to 200

                                                                                                                      "},{"location":"tutorials/imagemosaic_timeseries/imagemosaic_timeseries/","title":"Using the ImageMosaic plugin for raster time-series data","text":""},{"location":"tutorials/imagemosaic_timeseries/imagemosaic_timeseries/#introduction","title":"Introduction","text":"

                                                                                                                      This step-by-step tutorial describes how to build a time-series coverage using the ImageMosaic plugin. The ImageMosaic plugin allows the creation of a time-series layer of a raster dataset. The single images are held in a queryable structure to allow access to a specific dataset with a temporal filter.

                                                                                                                      This tutorial assumes knowledge of the concepts explained in ImageMosaic section.

                                                                                                                      This tutorial contains four sections:

                                                                                                                      • The first section, Configuration, describes the configuration files needed to set up an ImageMosaic store from GeoServer.
                                                                                                                      • The second section, Configuration examples, providing examples of the configuration files needed.
                                                                                                                      • The last two sections, Coverage based on filestore and Coverage based on database describe, once the previous configurations steps are done, how to create and configure an ImageMosaic store using the GeoServer GUI.

                                                                                                                      The dataset used in the tutorial can be downloaded Here. It contains 3 image files and a .sld file representing a style needed for correctly render the images.

                                                                                                                      "},{"location":"tutorials/imagemosaic_timeseries/imagemosaic_timeseries/#configuration","title":"Configuration","text":"

                                                                                                                      To support time-series layers, GeoServer needs to be run in a web container that has the timezone properly configured. To set the time zone to be Coordinated Universal Time (UTC), add this switch when launching the java process:

                                                                                                                      -Duser.timezone=GMT\n

                                                                                                                      If using a shapefile as the mosaic index store (see next section), another java process option is needed to enable support for timestamps in shapefile stores:

                                                                                                                      -Dorg.geotools.shapefile.datetime=true\n

                                                                                                                      Note

                                                                                                                      Support for timestamp is not part of the DBF standard (used in shapefile for attributes). The DBF standard only supports Date, and only few applications understand it. As long as shapefiles are only used for GeoServer input that is not a problem, but the above setting will cause issues if you have WFS enabled and users also download shapefiles as GetFeature output: if the feature type extracted has timestamps, then the generated shapefile will have as well, making it difficult to use the generated shapefile in desktop applications. As a rule of thumb, if you also need WFS support it is advisable to use an external store (PostGIS, Oracle) instead of shapefile. Of course, if all that's needed is a date, using shapefile as an index without the above property is fine as well.

                                                                                                                      In order to load a new CoverageStore from the GeoServer GUI two steps are needed:

                                                                                                                      1. Create a new directory in which you store all the raster files (the mosaic granules) and three configuration files. This directory represents the MOSAIC_DIR.
                                                                                                                      2. Install and setup a DBMS instance, this DB is that one where the mosaic indexes will be stored.
                                                                                                                      "},{"location":"tutorials/imagemosaic_timeseries/imagemosaic_timeseries/#mosaic_dir-and-the-configuration-files","title":"MOSAIC_DIR and the Configuration Files","text":"

                                                                                                                      The user can name and place the MOSAIC_DIR as and where they want.

                                                                                                                      The MOSAIC_DIR contains all mosaic granules files and the 3 needed configuration files. The files are in .properties format.

                                                                                                                      Note

                                                                                                                      Every tif file must follow the same naming convention. In this tutorial will be used {coveragename}_{timestamp}.tif

                                                                                                                      In a properties file you specify your properties in a key-value manner: e.g. myproperty=myvalue

                                                                                                                      The configuration files needed are:

                                                                                                                      1. datastore.properties: contains all relevant information responsible for connecting to the database in which the spatial indexes of the mosaic will be stored
                                                                                                                      2. indexer.properties: specifies the name of the time-variant attribute, the elevation attribute and the type of the attributes
                                                                                                                      3. timeregex.properties: specifies the regular expression used to extract the time information from the filename.

                                                                                                                      All the configuration files must be placed in the root of the MOSAIC_DIR. The granule images could be placed also in MOSAIC_DIR subfolders.

                                                                                                                      Please note that datastore.properties isn't mandatory. The plugin provides two possibilities to access to time series data:

                                                                                                                      • Using a shapefile in order to store the granules indexes. That's the default behavior without providing the datastore.properties file.
                                                                                                                      • Using a DBMS, which maps the timestamp to the corresponding raster source. The former uses the time attribute for access to the granule from the mapping table.

                                                                                                                      For production installation is strong recommended the usage of a DBMS instead of shapefile in order to improve performances.

                                                                                                                      Otherwise the usage of a shapefile could be useful in development and test environments due to less configurations are needed.

                                                                                                                      "},{"location":"tutorials/imagemosaic_timeseries/imagemosaic_timeseries/#datastoreproperties","title":"datastore.properties","text":"

                                                                                                                      Here is shown an example of datastore.properties suitable for Postgis.

                                                                                                                      Parameter Mandatory Description SPI Y The factory class used for the datastore e.g. org.geotools.data.postgis.PostgisNGDataStoreFactory host Y The host name of the database. port Y The port of the database database Y The name/instance of the database. schema Y The name of the database schema. user Y The database user. passwd Y The database password. Loose bbox N default 'false' Boolean value to specify if loosing the bounding box. Estimated extend N default 'true' Boolean values to specify if the extent of the data should be estimated. validate connections N default 'true' Boolean value to specify if the connection should be validated. Connection timeout N default '20' Specifies the timeout in minutes. preparedStatements N default 'false' Boolean flag that specifies if for the database queries prepared statements should be used. This improves performance, because the database query parser has to parse the query only once

                                                                                                                      Note

                                                                                                                      The first 8 parameters are valid for each DBMS used, the last 4 may vary from different DBMS. for more information see :geotoolsGeoTools JDBC documentation <jdbc/index.html>.

                                                                                                                      "},{"location":"tutorials/imagemosaic_timeseries/imagemosaic_timeseries/#indexerproperties","title":"indexer.properties","text":"Parameter Mandatory Description TimeAttribute N Specifies the name of the time-variant attribute ElevationAttribute N Specifies the name of the elevation attribute. Schema Y A comma separated sequence that describes the mapping between attribute and the data type. PropertyCollectors Y Specifies the extractor classes.

                                                                                                                      Warning

                                                                                                                      TimeAttribute is not a mandatory param but for the purpose of this tutorial is needed.

                                                                                                                      "},{"location":"tutorials/imagemosaic_timeseries/imagemosaic_timeseries/#timeregexproperties","title":"timeregex.properties","text":"Parameter Mandatory Description regex Y Specifies the pattern used for extracting the information from the file

                                                                                                                      After this you can create a new ImageMosaic datastore.

                                                                                                                      "},{"location":"tutorials/imagemosaic_timeseries/imagemosaic_timeseries/#install-and-setup-a-dbms-instance","title":"Install and setup a DBMS instance","text":"

                                                                                                                      First of all, note that the usage of a DBMS to store the mosaic indexes is not mandatory. If the user does not create a datastore.properties file in the MOSAIC_DIR, then the plugin will use a shapefile. The shapefile will be created in the MOSAIC_DIR.

                                                                                                                      Anyway, especially for large dataset, the usage of a DBMS is strongly recommended. The ImageMosaic plugin supports all the most used DBMS.

                                                                                                                      The configuration needed are the basics: create a new empty DB with geospatial extensions, a new schema and configure the user with W/R grants.

                                                                                                                      If the user wants to avoid to manually create the DB, it will be automatically generated by the ImageMosaic plugin taking the information defined inside the datastore.properties file.

                                                                                                                      Note

                                                                                                                      In case of automatic DB creation with PostgreSQL the user must check the PostgreSQL and PostGIS versions: if the first is lower than 9.1 and the second is lower than 2.0, the user have to add the following string of code inside the datastore.properties file :

                                                                                                                      create\\ database\\ params=WITH\\ TEMPLATE\\=template_postgis\n

                                                                                                                      (Specifying the proper PostGIS template... in this example: template_postgis).

                                                                                                                      This tutorial shows use of PostgreSQL 9.1 together with PostGIS 2.0.

                                                                                                                      "},{"location":"tutorials/imagemosaic_timeseries/imagemosaic_timeseries/#configuration-examples","title":"Configuration examples","text":"

                                                                                                                      As example is used a set of data that represents hydrological data in a certain area in South Tyrol, a region in northern Italy. The origin data was converted from asc format to TIFF using the GDAL gdal translate utility.

                                                                                                                      For this running example we will create a layer named snow.

                                                                                                                      As mentioned before the files could located in any part of the file system.

                                                                                                                      In this tutorial the chosen MOSAIC_DIR directory is called hydroalp and is placed under the root of the GEOSERVER_DATA_DIR.

                                                                                                                      "},{"location":"tutorials/imagemosaic_timeseries/imagemosaic_timeseries/#configure-the-mosaic_dir","title":"Configure the MOSAIC_DIR:","text":"

                                                                                                                      This part showsn an entire MOSAIC_DIR configuration.

                                                                                                                      "},{"location":"tutorials/imagemosaic_timeseries/imagemosaic_timeseries/#datastoreproperties_1","title":"datastore.properties:","text":"
                                                                                                                      SPI=org.geotools.data.postgis.PostgisNGDataStoreFactory\nhost=localhost\nport=5432\ndatabase=db\nschema=public\nuser=dbuser\npasswd=dbpasswd\nLoose\\ bbox=true\nEstimated\\ extends=false\nvalidate\\ connections=true\nConnection\\ timeout=10\npreparedStatements=true\n

                                                                                                                      Note

                                                                                                                      In case of a missing datastore.properties file a shape file is created to hold the indexes.

                                                                                                                      "},{"location":"tutorials/imagemosaic_timeseries/imagemosaic_timeseries/#granules-naming-convention","title":"Granules Naming Convention","text":"

                                                                                                                      Here an example of the granules naming that satisfies the rule shown before:

                                                                                                                      $ls hydroalp/snow/*.tif\n\nsnow/snow_20091001.tif\nsnow/snow_20091101.tif\nsnow/snow_20091201.tif\nsnow/snow_20100101.tif\nsnow/snow_20100201.tif\nsnow/snow_20100301.tif\nsnow/snow_20100401.tif\nsnow/snow_20100501.tif\nsnow/snow_20100601.tif\nsnow/snow_20100701.tif\nsnow/snow_20100801.tif\nsnow/snow_20100901.tif\n
                                                                                                                      "},{"location":"tutorials/imagemosaic_timeseries/imagemosaic_timeseries/#timeregexproperties_1","title":"timeregex.properties:","text":"

                                                                                                                      In the timeregex property file you specify the pattern describing the date(time) part of the file names. In this example it consists simply of 8 digits as specified below.

                                                                                                                      regex=[0-9]{8}\n
                                                                                                                      "},{"location":"tutorials/imagemosaic_timeseries/imagemosaic_timeseries/#indexerproperties_1","title":"indexer.properties:","text":"

                                                                                                                      Here the user can specify the information that GeoServer uses to create the index table in the database. In this example, the time values are stored in the column ingestion.

                                                                                                                      TimeAttribute=ingestion\nElevationAttribute=elevation\nSchema=*the_geom:Polygon,location:String,ingestion:java.util.Date,elevation:Integer\nPropertyCollectors=TimestampFileNameExtractorSPI[timeregex](ingestion)\n
                                                                                                                      "},{"location":"tutorials/imagemosaic_timeseries/imagemosaic_timeseries/#create-and-publish-an-imagemosaic-store","title":"Create and Publish an ImageMosaic store:","text":""},{"location":"tutorials/imagemosaic_timeseries/imagemosaic_timeseries/#step-1-create-new-imagemosaic-data-store","title":"Step 1: Create new ImageMosaic data store","text":"

                                                                                                                      We create a new data store of type raster data and choose ImageMosaic.

                                                                                                                      Note

                                                                                                                      Be aware that GeoServer creates a table which is identical with the name of your layer. If the table already exists, it will not be dropped from the DB and the following error message will appear. The same message will appear if the generated property file already exists in the directory or there are incorrect connection parameters in datastore.properties file.

                                                                                                                      "},{"location":"tutorials/imagemosaic_timeseries/imagemosaic_timeseries/#step-2-specify-layer","title":"Step 2: Specify layer","text":"

                                                                                                                      We specify the directory that contains the property and TIFF files (path must end with a slash) and add the layer.

                                                                                                                      "},{"location":"tutorials/imagemosaic_timeseries/imagemosaic_timeseries/#step-3-set-coverage-parameters","title":"Step 3: Set coverage parameters","text":"

                                                                                                                      The relevant parameters are AllowMultithreading and USE_JAI_IMAGEREAD. Do not forget to specify the background value according to your the value in your tif file. If you want to control which granule is displayed when a number of images match the time period specified then set the SORTING parameter to the variable name you want to use for sorting followed by a space and either D or A for descending or ascending. Descending values will mean that the latest image in a series that occurs in the time period requested is shown.

                                                                                                                      Remember that for display correctly the images contained in the provided dataset a custom style is needed.

                                                                                                                      Set as default style the snow_style.sld contained in the dataset archive.

                                                                                                                      More information about raster styling can be found in chapter Rasters

                                                                                                                      "},{"location":"tutorials/imagemosaic_timeseries/imagemosaic_timeseries/#step-4-set-temporal-properties","title":"Step 4: Set temporal properties","text":"

                                                                                                                      In the Dimensions tab you can specify how the time attributes are represented.

                                                                                                                      By enabling the Time or Elevation checkbox you can specify the how these dimensions will be presented. In this example, queries are only over the time attribute.

                                                                                                                      Below is shown a snippet of the Capabilities document for each presentation case:

                                                                                                                      Setting the presentation to List, all mosaic times are listed:

                                                                                                                      <Dimension name=\"time\" default=\"current\" units=\"ISO8601\">\n    2009-10-01T00:00:00.000Z,2009-11-01T00:00:00.000Z,2009-12-01T00:00:00.000Z,2010-01-01T00:00:00.000Z,2010-02-01T00:00:00.000Z,2010-03-01T00:00:00.000Z,2010-04-01T00:00:00.000Z,2010-05-01T00:00:00.000Z,2010-06-01T00:00:00.000Z,2010-07-01T00:00:00.000Z,2010-08-01T00:00:00.000Z,2010-09-01T00:00:00.000Z,2010-10-01T00:00:00.000Z,2010-11-01T00:00:00.000Z,2010-12-01T00:00:00.000Z,2011-01-01T00:00:00.000Z,2011-02-01T00:00:00.000Z,2011-03-01T00:00:00.000Z,2011-04-01T00:00:00.000Z,2011-05-01T00:00:00.000Z,2011-06-01T00:00:00.000Z,2011-07-01T00:00:00.000Z,2011-08-01T00:00:00.000Z,2011-09-01T00:00:00.000Z\n</Dimension>\n

                                                                                                                      Setting the presentation to Continuous interval only the start, end and interval extent times are listed:

                                                                                                                      <Dimension name=\"time\" default=\"current\" units=\"ISO8601\">\n    2009-10-01T00:00:00.000Z/2011-09-01T00:00:00.000Z/P1Y11MT10H\n</Dimension>\n

                                                                                                                      Setting the presentation to Interval and resolutions gives to user the possibility to specify the resolutions of the interval:

                                                                                                                      <Dimension name=\"time\" default=\"current\" units=\"ISO8601\">\n    2009-10-01T00:00:00.000Z/2011-09-01T00:00:00.000Z/P1DT12H\n</Dimension>\n

                                                                                                                      In this case the resolution is set to 1.5 days.

                                                                                                                      Note

                                                                                                                      To visualize the GetCapabilities document, go to the GeoServer homepage, and click on the WMS 1.3.0 link under the tab labeled Service Capabilities.

                                                                                                                      For this tutorial the Presentation attribute is set to List

                                                                                                                      After this steps the new layer is available in GeoServer. GeoServer will create a property file in the source directory. GeoServer will either create a shapefile for the mosaic indexes, or will create a table on the database (named the same as the layer name) for the index.

                                                                                                                      "},{"location":"tutorials/imagemosaic_timeseries/imagemosaic_timeseries/#generated-property-file","title":"Generated property file:","text":"
                                                                                                                      #-Automagically created from GeoTools-\n#Sat Oct 13 10:47:08 CEST 2012\nLevels=100.0,100.0\nHeterogeneous=false\nElevationAttribute=elevation\nTimeAttribute=ingestion\nAbsolutePath=false\nName=snow\nCaching=false\nExpandToRGB=false\nLocationAttribute=location\nSuggestedSPI=it.geosolutions.imageioimpl.plugins.tiff.TIFFImageReaderSpi\nLevelsNum=1\n

                                                                                                                      Note

                                                                                                                      The parameter Caching=false is important to allow the user is to update manually the mosaic, by adding to and removing granules from MOSAIC_DIR and updating the appropriate database entry.

                                                                                                                      "},{"location":"tutorials/imagemosaic_timeseries/imagemosaic_timeseries/#generated-table","title":"Generated table:","text":"

                                                                                                                      Note

                                                                                                                      The user must create manually the index on the table in order to speed up the search by attribute.

                                                                                                                      "},{"location":"tutorials/imagemosaic_timeseries/imagemosaic_timeseries/#step-5-query-layer-on-timestamp","title":"Step 5: query layer on timestamp:","text":"

                                                                                                                      In order to display a snapshot of the map at a specific time instant you have to pass in the request an additional time parameter with a specific notation &time= < pattern > where you pass a value that corresponds to them in the filestore. The only thing is the pattern of the time value is slightly different.

                                                                                                                      For example if an user wants to obtain the snow coverage images from the months Oct,Nov,Dec 2009, pass in each request &time=2009-10-01, &time=2009-11-01 and &time=2009-12-01. You can recognize in the three images how the snow coverage changes. Here the color blue means a lot of snow.

                                                                                                                      "},{"location":"tutorials/imagemosaic_timeseries/imagemosaic_timeseries/#create-and-publish-a-layer-from-mosaic-indexes","title":"Create and publish a Layer from mosaic indexes:","text":"

                                                                                                                      After the previous steps it is also possible to create a layer that represents the spatial indexes of the mosaic. This is an useful feature when handling a large dataset of mosaics with high resolutions granules, since the user can easily get the footprints of the images. In this case will be rendered only the geometries stored on the indexes tables.

                                                                                                                      "},{"location":"tutorials/imagemosaic_timeseries/imagemosaic_timeseries/#step-1-add-a-postgis-datastore","title":"Step 1: add a postgis datastore:","text":"

                                                                                                                      and specify the connection parameters

                                                                                                                      "},{"location":"tutorials/imagemosaic_timeseries/imagemosaic_timeseries/#step-2-add-database-layer","title":"Step 2: add database layer:","text":"

                                                                                                                      Choose from the created datastore the table that you want to publish as a layer.

                                                                                                                      "},{"location":"tutorials/imagemosaic_timeseries/imagemosaic_timeseries/#step-3-specify-dimension","title":"Step 3: specify dimension:","text":"

                                                                                                                      In the tab Dimension specify the time-variant attribute and the form of presentation.

                                                                                                                      That's it. Now is possible query this layer too.

                                                                                                                      "},{"location":"tutorials/imagepyramid/imagepyramid/","title":"Building and using an image pyramid","text":"

                                                                                                                      GeoServer can efficiently deal with large TIFF with overviews, as long as the TIFF is below the 2GB size limit.

                                                                                                                      Once the image size goes beyond such limit it's time to start considering an image pyramid instead.

                                                                                                                      An image pyramid builds multiple mosaics of images, each one at a different zoom level, making it so that each tile is stored in a separate file. This comes with a composition overhead to bring back the tiles into a single image, but can speed up image handling as each overview is tiled, and thus a sub-set of it can be accessed efficiently (as opposed to a single GeoTIFF, where the base level can be tiled, but the overviews never are).

                                                                                                                      This tutorial shows how to build an image pyramid with open source utilities and how to load it into GeoServer. The tutorial assumes you're running at least GeoServer 2.0.2.

                                                                                                                      "},{"location":"tutorials/imagepyramid/imagepyramid/#building-a-pyramid","title":"Building a pyramid","text":"

                                                                                                                      For this tutorial we have prepared a sample BlueMarble TNG subset in GeoTIFF form. The image is tiled and JPEG compressed, without overviews. Not exactly what you'd want to use for high performance data serving, but good for redistribution and as a starting point to build a pyramid.

                                                                                                                      In order to build the pyramid we'll use the gdal_retile.py utility, part of the GDAL command line utilities and available for various operating systems (if you're using Microsoft Windows look for FWTools).

                                                                                                                      The following commands will build a pyramid on disk:

                                                                                                                      mkdir bmpyramid\ngdal_retile.py -v -r bilinear -levels 4 -ps 2048 2048 -co \"TILED=YES\" -co \"COMPRESS=JPEG\" -targetDir bmpyramid bmreduced.tiff\n

                                                                                                                      The gdal_retile.py user guide provides a detailed explanation for all the possible parameters, here is a description of the ones used in the command line above:

                                                                                                                      • -v: verbose output, allows the user to see each file creation scroll by, thus knowing progress is being made (a big pyramid construction can take hours)
                                                                                                                      • -r bilinear: use bilinear interpolation when building the lower resolution levels. This is key to get good image quality without asking GeoServer to perform expensive interpolations in memory
                                                                                                                      • -levels 4: the number of levels in the pyramid
                                                                                                                      • -ps 2048 2048: each tile in the pyramid will be a 2048x2048 GeoTIFF
                                                                                                                      • -co \"TILED=YES\": each GeoTIFF tile in the pyramid will be inner tiled
                                                                                                                      • -co \"COMPRESS=JPEG\": each GeoTIFF tile in the pyramid will be JPEG compressed (trades small size for higher performance, try out it without this parameter too)
                                                                                                                      • -targetDir bmpyramid: build the pyramid in the bmpyramid directory. The target directory must exist and be empty
                                                                                                                      • bmreduced.tiff: the source file

                                                                                                                      This will produce a number of TIFF files in bmpyramid along with the sub-directories 1, 2, 3, and 4.

                                                                                                                      Once that is done, and assuming the GeoServer image pyramid plug-in is already installed, it's possible to create the coverage store by pointing at the directory containing the pyramid and clicking save:

                                                                                                                      Configuring a image pyramid store

                                                                                                                      When clicking save the store will look into the directory, recognize a gdal_retile generated structure and perform some background operations:

                                                                                                                      • move all tiff files in the root to a newly create directory 0
                                                                                                                      • create an image mosaic in all sub-directories (shapefile index plus property file)
                                                                                                                      • create the root property file describing the whole pyramid structure

                                                                                                                      Once that is done the user will be asked to choose a coverage, which will be named after the pyramid root directory:

                                                                                                                      Choosing the coverage for publishing

                                                                                                                      Publish the layer, and then setup the layer parameter USE_JAI_IMAGEREAD to false to get better scalability:

                                                                                                                      Tuning the pyramid parameters

                                                                                                                      Submit and go to the preview, the pyramid should be ready to use:

                                                                                                                      Previewing the pyramid

                                                                                                                      "},{"location":"tutorials/imagepyramid/imagepyramid/#notes-on-big-pyramids","title":"Notes on big pyramids","text":"

                                                                                                                      The code that is auto-creating the pyramid indexes and metadata files might take time to run, especially if:

                                                                                                                      • the pyramid zero level is composed of many thousands of files
                                                                                                                      • the system is busy with the disk already and that results in higher times to move all the files to the 0 directory

                                                                                                                      If the delay is too high the request to create the store will time out and might break the pyramid creation. So, in case of very big pyramids consider loosing some of the comfort and creating the 0 directory and moving the files by hand:

                                                                                                                      cd bmpyramid\nmkdir 0\nmv *.tiff 0\n
                                                                                                                      "},{"location":"tutorials/jboss/jboss_tutorial/","title":"geoserver on JBoss","text":"

                                                                                                                      This tutorial documents how to install various versions of geoserver onto various versions of JBoss.

                                                                                                                      "},{"location":"tutorials/jboss/jboss_tutorial/#geoserver-270-on-jboss-as-51","title":"geoserver 2.7.0 on JBoss AS 5.1","text":"

                                                                                                                      To install geoserver onto JBoss AS 5.1, the following is required:

                                                                                                                      1. Create the file jboss-classloading.xml with the following content then copy it into the WEB-INF directory in the geoserver.war:
                                                                                                                      <classloading xmlns=\"urn:jboss:classloading:1.0\"\n    name=\"geoserver.war\"\n    domain=\"GeoServerDomain\">\n</classloading>\n
                                                                                                                      1. Extract the hsqldb-2.2.8.jar file from the WEB-INF/lib directory from the geoserver.war and copy it as hsqldb.jar to the common/lib directory in the JBoss deployment.
                                                                                                                      2. Add the following text to the WEB-INF/web.xml file in the geoserver.war so that JBoss logging does not end up in the geoserver.log:
                                                                                                                      <context-param>\n    <param-name>RELINQUISH_LOG4J_CONTROL</param-name>\n    <param-value>true</param-value>\n</context-param>    \n
                                                                                                                      "},{"location":"tutorials/metadata/","title":"INSPIRE metadata configuration using metadata and CSW","text":"

                                                                                                                      The INSPIRE directive requires exposure of fairly complex metadata schemes based on the ISO Metadata Profile. This exposure is supported by the built-in Catalog Services for the Web (CSW) service (can be harvested by GeoNetwork), while the Metadata community module allows adding any amount of customized metadata fields to layers that may be required for your particular case.

                                                                                                                      Creating all the needed configuration files in both modules can be a tedious task. Therefore we have added this example configuration.

                                                                                                                      "},{"location":"tutorials/metadata/#metadata-configuration","title":"Metadata configuration","text":"

                                                                                                                      Place the following files in the metadata folder:

                                                                                                                      UI configuration metadata-ui.yaml

                                                                                                                      Translate keys to labels metadata.properties

                                                                                                                      Translate keys to Dutch labels metadata_nl.properties

                                                                                                                      Content for gemet-concept dropdown keyword-gemet-concept.csv

                                                                                                                      Content for reference-system requirebox keyword-gemet-concept.csv

                                                                                                                      Content for inspire-theme-label & inspire-theme-ref keyword-inspire-theme.csv

                                                                                                                      Geonetwork mapping metadata-mapping.yaml

                                                                                                                      Namespaces for geonetwork mapping metadata-mapping.yaml

                                                                                                                      Geonetwork endpoints metadata-geonetwork.yaml

                                                                                                                      Synchronize native fields metadata-native-mapping.yaml

                                                                                                                      Open any layer: navigate to Layers \u2192 Choose the layer \u2192 Metadata tab.

                                                                                                                      The metadata fields are available in the panel Metadata fields.

                                                                                                                      You may now add custom metadata to your layers.

                                                                                                                      "},{"location":"tutorials/metadata/#csw-configuration","title":"CSW configuration","text":"

                                                                                                                      Map metadata attributes to xml MD_Metadata.properties

                                                                                                                      Map Feature Catalogue attributes to xml FC_FeatureCatalogue.properties

                                                                                                                      Map Record attributes to xml Record.properties

                                                                                                                      You may now see your custom metadata exposed by the built-in CSW service:

                                                                                                                      e.g. https://my.host/geoserver/csw?service=CSW&version=2.0.2&request=GetRecords&typeNames=gmd:MD_Metadata&resultType=results&elementSetName=full&outputSchema=http://www.isotc211.org/2005/gmd.

                                                                                                                      "},{"location":"tutorials/metadata/#geonetwork-configuration","title":"GeoNetwork configuration","text":"

                                                                                                                      Create a GeoNetwork CSW harvester that points to your to Geoserver's CSW endpoint:

                                                                                                                      e.g. https://my.host/geoserver/csw?Service=CSW&Request=Getcapabilities.

                                                                                                                      You may now start harvesting!

                                                                                                                      "},{"location":"tutorials/palettedimage/palettedimage/","title":"Paletted Images","text":"

                                                                                                                      GeoServer has the ability to output high quality 256 color images. This tutorial introduces you to the palette concepts, the various image generation options, and offers a quality/resource comparison of them in different situations.

                                                                                                                      "},{"location":"tutorials/palettedimage/palettedimage/#what-are-paletted-images","title":"What are Paletted Images?","text":"

                                                                                                                      Some image formats, such as GIF or PNG, can use a palette, which is a table of (usually) 256 colors to allow for better compression. Basically, instead of representing each pixel with its full color triplet, which takes 24bits (plus eventual 8 more for transparency), they use a 8 bit index that represent the position inside the palette, and thus the color.

                                                                                                                      This allows for images that are 3-4 times smaller than the standard images, with the limitation that only 256 different colors can appear on the image itself. Depending of the actual map, this may be a very stringent limitation, visibly degrading the image quality, or it may be that the output cannot be differentiated from a full color image. For many maps, one can easily find 256 representative colors.

                                                                                                                      In the latter case, the smaller footprint of paletted images is usually a big gain in both performance and costs, because more data can be served with the same internet connection, and the clients will obtain responses faster.

                                                                                                                      "},{"location":"tutorials/palettedimage/palettedimage/#formats-and-antialiasing","title":"Formats and Antialiasing","text":"

                                                                                                                      Internet standards offer a variety of image formats, all having different strong and weak points. The three most common formats are:

                                                                                                                      • JPEG: a lossy format with tunable compression. JPEG is best suited for imagery layers, where the pixel color varies continuously from one pixel to the next one, and allows for the best compressed outputs. On the contrary, it's not suited to most vector layers, because even slight compression generates visible artifacts on uniform color areas.
                                                                                                                      • PNG: a non lossy format allowing for both full color and paletted. In full color images each pixel is encoded as a 24bits integer with full transparency information (so PNG images can be translucent), in paletted mode each pixel is an 8 bit index into a 256 color table (the palette). This format is best suited to vector layers, especially in the paletted version. The full color version is sometimes referred as PNG24, the paletted version as PNG8.
                                                                                                                      • GIF: a non lossy format with a 256 color palette, best suited for vector layers. Does not support translucency, but allows for fully transparent pixels.

                                                                                                                      So, as it turns out, paletted images can be used with profit on vector data sets, either using the PNG8 or GIF formats.

                                                                                                                      Antialiasing plays a role too. Let's take a road layer, where each road is depicted by a solid gray line, 2 pixels thick. One may think this layer needs only 2 colors: the background one (eventually transparent) and gray. In fact, this is true only if no antialiasing is enabled. Antialiasing will smooth the borders of the line giving a softer, better looking shape, and it will do so by adding pixels with an intermediate color, thus increasing the number of colors that are needed to fully display the image.

                                                                                                                      The following zoom of an image shows antialiasing in action:

                                                                                                                      Antialiasing

                                                                                                                      These output formats, if no other parameters are provided, do compute the optimal palette on the fly. As you'll see, this is an expensive process (CPU bound), but as you'll see, depending on the speed of the network connecting the server and the client, the extra cost can be ignored (especially if the bottleneck can be found in the network instead of the server CPU).

                                                                                                                      Optimal palette computation is anyways a repetitive work that can be done up front: a user can compute the optimal palette once, and tell GeoServer to use it. There are three ways to do so:

                                                                                                                      1. Use the internet safe palette, a standard palette built in into GeoServer, by appending palette=safe to the GetMap request.

                                                                                                                      2. Provide a palette by example. In this case, the user will generate an 256 color images using an external program (such as Photoshop), and then will save it into the $GEOSERVER_DATA_DIR/palettes directory. The sample file can be either in GIF or PNG format. If the file is named mypalette.gif or mypalette.png, the user will be able to refer it appending palette=mypalette to the GetMap request. GeoServer will load the palette from the file and use it.

                                                                                                                      3. Provide a palette file. The palette file must be in JASC-PAL format, and have a .pal extension. This file type can be generated by applications such as Paint Shop Pro and IrfanView, but also can be generated manually in a text editor. The process is just as before, but this time only the palette file will be stored into $GEOSERVER_DATA_DIR/palettes.

                                                                                                                        Note

                                                                                                                        GeoServer does not support palette files in Microsoft Palette format, despite having the same .pal file extension.

                                                                                                                      "},{"location":"tutorials/palettedimage/palettedimage/#an-example-with-vector-data","title":"An Example with Vector Data","text":"

                                                                                                                      Enough theory, let's have a look at how to deal with paletted images in practice. We'll use the tiger-ny basemap to gather some numbers, and in particular the following map request:

                                                                                                                      http://localhost:8080/geoserver/wms?SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&LAYERS=tiger-ny&BBOX=-74.022019,40.701196,-73.992366,40.720964&HEIGHT=400&WIDTH=600&FORMAT=image/png

                                                                                                                      And we'll change various parameters in order to play with formats and palettes. Here goes the sampler:

                                                                                                                      Parameters:FORMAT=image/png | Size: 257 KB | Map generation time: 0.3s

                                                                                                                      The standard PNG full color output

                                                                                                                      Parameters:FORMAT=image/png8 | Size: 60 KB | Map generation time: 0.6s

                                                                                                                      The PNG8 output

                                                                                                                      Parameters:FORMAT=image/png | Size: 257 KB | Map generation time: 0.3s

                                                                                                                      PNG + internet safe palette

                                                                                                                      Parameters:FORMAT=image/png & palette=nyp | Size: 56KB | Map generation time: 0.3s

                                                                                                                      PNG + custom palette <http://geoserver.org/download/attachments/1278244/nyp.pal?version=1>_

                                                                                                                      The attachments include also the GIF outputs, whose size, appearance and generation time does not differ significantly from the PNG outputs.

                                                                                                                      As we can see, depending on the choice we have a variation on the image quality, size and generation time (which has been recorded using the FasterFox Firefox extension timer, with the browser sitting on the same box as the server). Using palette=xxx provides the best match in speed and size, though using the built-in internet safe palette altered the colors. Then again, the real gain can be seen only by assuming a certain connection speed between the server and the client, and adding the time required to move the image to the client. The following table provides some results:

                                                                                                                      Configuration GT(s) File size (kb) TT 256kbit/s TT 1MBit/s TT 4MBit/s TT 20MBit/s tiger-ny-png 0,36 257 8,39 2,42 0,87 0,46 tyger-ny-png8 0,6 60 2,48 1,08 0,72 0,62 tiger-ny-png + safe palette 0,3 56 22,05 0,75 0,41 0,32 tiger-ny-png + custom palette 0,3 59 2,14 0,77 0,42 0,32

                                                                                                                      Legend:

                                                                                                                      • GT: map generation time on the same box
                                                                                                                      • TT <speed>: total time needed for a client to show the image, assuming an internet connection of the given speed. This time is a sum of the image generation time and the transfer time, that is, GT + sizeInKbytes * 8/ speedInKbits.

                                                                                                                      As the table shows, the full color PNG image takes usually a lot more time than other formats, unless it's being served over a fast network (and even in this case, one should consider network congestion as well). The png8 output format proves to be a good choice if the connection is slow, whilst the extra work done in looking up an optimal palette always pays back in faster map delivery.

                                                                                                                      "},{"location":"tutorials/palettedimage/palettedimage/#generating-the-custom-palette","title":"Generating the custom palette","text":"

                                                                                                                      The nyp.pal file has been generated using IrfanView, on Windows:

                                                                                                                      • open the png 24 bit version of the image
                                                                                                                      • use Image/Decrease Color Depth and set 256 colors
                                                                                                                      • use Image/Palette/Export to save the palette
                                                                                                                      "},{"location":"tutorials/palettedimage/palettedimage/#an-example-with-raster-data","title":"An example with raster data","text":"

                                                                                                                      To give you an example when paletted images may not fit the bill, let's consider the sf:dem coverage from the sample data, and repeat the same operation as before.

                                                                                                                      Parameters:FORMAT=image/png Size: 117 KB | Map generation time: 0.2s

                                                                                                                      The standard PNG full color output.

                                                                                                                      Parameters:FORMAT=image/jpeg Size: 23KB | Map generation time: 0.12s

                                                                                                                      JPEG output

                                                                                                                      Parameters:FORMAT=image/png8 Size: 60 KB | Map generation time: 0.5s

                                                                                                                      The PNG8 output.

                                                                                                                      Parameters:FORMAT=image/png & palette=dem-png8 Size: 48KB | Map generation time: 0.15s

                                                                                                                      PNG + custom palette (using the png8 output as the palette).

                                                                                                                      Parameters:FORMAT=image/png & palette=safe Size: 17KB | Map generation time: 0.15s

                                                                                                                      PNG + internet safe palette.

                                                                                                                      As the sample shows, the JPEG output has the same quality as the full color image, is generated faster and uses only \u2155 of its size. On the other hand, the version using the internet safe palette is fast and small, but the output is totally ruined. Everything considered, JPEG is the clear winner, sporting good quality, fast image generation and a size that's half of the best png output we can get.

                                                                                                                      "},{"location":"tutorials/tomcat-jndi/tomcat-jndi/","title":"Setting up a JNDI connection pool with Tomcat","text":"

                                                                                                                      This tutorial walks the reader through the procedures necessary to setup a Oracle JNDI connection pool in Tomcat 6 and how to retrieve it from GeoServer. In the last section other two examples of configuration are described with PostGIS and SQLServer.

                                                                                                                      "},{"location":"tutorials/tomcat-jndi/tomcat-jndi/#tomcat-setup","title":"Tomcat setup","text":"

                                                                                                                      In order to setup a connection pool Tomcat needs a JDBC driver and the necessary pool configurations.

                                                                                                                      First off, you need to find the JDBC driver for your database. Most often it is distributed on the website of your DBMS provider, or available in the installed version of your database. For example, a Oracle XE install on a Linux system provides the driver at /usr/lib/oracle/xe/app/oracle/product/10.2.0/server/jdbc/lib/ojdbc14.jar, and that file needs to be moved into Tomcat shared libs directory, {TOMCAT_HOME}/lib

                                                                                                                      Note

                                                                                                                      be careful to remove the jdbc driver from the GeoServer WEB-INF/lib folder when copied to the Tomcat shared libs, to avoid issues in JNDI DataStores usage.

                                                                                                                      Once that is done, the Tomcat configuration file {TOMCAT_HOME}/conf/context.xml needs to be edited in order to setup the connection pool. In the case of a local Oracle XE the setup might look like:

                                                                                                                      <Context>\n   ...\n   <Resource name=\"jdbc/oralocal\"\n      auth=\"Container\"\n      type=\"javax.sql.DataSource\"\n      driverClassName=\"oracle.jdbc.driver.OracleDriver\"\n      url=\"jdbc:oracle:thin:@localhost:1521:xe\"\n      username=\"xxxxx\" password=\"xxxxxx\"\n      maxTotal=\"20\"\n      initialSize=\"0\"\n      minIdle=\"0\"\n      maxIdle=\"8\"\n      maxWait=\"10000\"\n      timeBetweenEvictionRunsMillis=\"30000\"\n      minEvictableIdleTimeMillis=\"60000\"\n      testWhileIdle=\"true\"\n      poolPreparedStatements=\"true\"\n      maxOpenPreparedStatements=\"100\"\n      validationQuery=\"SELECT SYSDATE FROM DUAL\"\n      maxAge=\"600000\"\n      rollbackOnReturn=\"true\"\n      />\n </Context>\n

                                                                                                                      Note

                                                                                                                      The above configuration is valid for Tomcat 8+, while Tomcat 7.x would use maxActive in place of maxTotal.

                                                                                                                      The example sets up a connection pool connecting to the local Oracle XE instance. The pool configuration shows is quite full-fledged:

                                                                                                                      • at most 20 active connections (max number of connection that will ever be used in parallel)
                                                                                                                      • at most 3 connections kept in the pool unused
                                                                                                                      • prepared statement pooling (very important for good performance)
                                                                                                                      • at most 100 prepared statements in the pool
                                                                                                                      • a validation query that double checks the connection is still alive before actually using it (this is not necessary if there is guarantee the connections will never drop, either due to the server forcefully closing them, or to network/maintenance issues).

                                                                                                                      Warning

                                                                                                                      Modify following settings only if you really know what you are doing. Using too low values for removedAbandonedTimeout and minEvictableIdleTimeMillis may result in connection failures, if so try to setup logAbandoned to true and check your catalina.out log file.

                                                                                                                      Other parameters to setup connection pool:

                                                                                                                      • timeBetweenEvictionRunsMillis (default -1) The number of milliseconds to sleep between runs of the idle object evictor thread. When non-positive, no idle object evictor thread will be run.
                                                                                                                      • numTestsPerEvictionRun (default 3) The number of objects to examine during each run of the idle object evictor thread (if any).
                                                                                                                      • minEvictableIdleTimeMillis (default 1000 * 60 * 30) The minimum amount of time an object may sit idle in the pool before it is eligible for eviction by the idle object evictor (if any).
                                                                                                                      • removeAbandoned (default false) Flag to remove abandoned connections if they exceed the removeAbandonedTimout. If set to true a connection is considered abandoned and eligible for removal if it has been idle longer than the removeAbandonedTimeout. Setting this to true can recover db connections from poorly written applications which fail to close a connection.
                                                                                                                      • removeAbandonedTimeout (default 300) Timeout in seconds before an abandoned connection can be removed.
                                                                                                                      • logAbandoned (default false) Flag to log stack traces for application code which abandoned a Statement or Connection.

                                                                                                                      For more information about the possible parameters and their values refer to the DBCP documentation.

                                                                                                                      "},{"location":"tutorials/tomcat-jndi/tomcat-jndi/#geoserver-setup","title":"GeoServer setup","text":"

                                                                                                                      Login into the GeoServer web administration interface and configure the datastore.

                                                                                                                      First, choose the Oracle (JNDI) datastore and give it a name:

                                                                                                                      Choosing a JNDI enabled datastore

                                                                                                                      Then, configure the connection parameters so that the JNDI path matches the one specified in the Tomcat configuration:

                                                                                                                      Configuring the JNDI connection

                                                                                                                      When you are doing this, make sure the schema is properly setup, or the datastore will list all the tables it can find in the schema it can access. In the case of Oracle the schema is usually the user name, upper cased.

                                                                                                                      Once the datastore is accepted the GeoServer usage proceeds as normal.

                                                                                                                      "},{"location":"tutorials/tomcat-jndi/tomcat-jndi/#other-examples","title":"Other examples","text":""},{"location":"tutorials/tomcat-jndi/tomcat-jndi/#configuring-a-postgresql-connection-pool","title":"Configuring a PostgreSQL connection pool","text":"

                                                                                                                      In this example a PostgreSQL connection pool will be configured.

                                                                                                                      For configuring the JNDI pool you need to move the Postgres JDBC driver (it should be named postgresql-XX.X.X.jar) from the GeoServer WEB-INF/lib folder and put it into the {TOMCAT_HOME}/lib folder.

                                                                                                                      Then the following code must be added to the Tomcat configuration file {TOMCAT_HOME}/conf/context.xml inside a Context tag.

                                                                                                                      <Context>\n    <Resource name=\"jdbc/postgres\"\n      auth=\"Container\"\n      type=\"javax.sql.DataSource\"\n      driverClassName=\"org.postgresql.Driver\"\n      url=\"jdbc:postgresql://localhost:5432/test\"\n      username=\"xxxxx\" password=\"xxxxxx\"\n      maxTotal=\"20\"\n      initialSize=\"0\"\n      minIdle=\"0\"\n      maxIdle=\"8\"\n      maxWait=\"10000\"\n      timeBetweenEvictionRunsMillis=\"30000\"\n      minEvictableIdleTimeMillis=\"60000\"\n      testWhileIdle=\"true\"\n      validationQuery=\"SELECT 1\"\n      maxAge=\"600000\"\n      rollbackOnReturn=\"true\"\n    />\n</Context>\n
                                                                                                                      "},{"location":"tutorials/tomcat-jndi/tomcat-jndi/#geoserver-setup_1","title":"GeoServer setup","text":"

                                                                                                                      Login into the GeoServer web administration interface.

                                                                                                                      First, choose the PostGIS (JNDI) datastore and give it a name:

                                                                                                                      Then configure the associated parameters. The value for jndiReferenceName corresponds to the Resource name given in {TOMCAT_HOME}/conf/context.xml.

                                                                                                                      "},{"location":"tutorials/tomcat-jndi/tomcat-jndi/#configuring-a-sqlserver-connection-pool","title":"Configuring a SQLServer connection pool","text":"

                                                                                                                      For configuring the connection pool for SQLServer you need to configure the SQLServer drivers as explained in the Microsoft SQL Server section and put the jar file into the {TOMCAT_HOME}/lib folder.

                                                                                                                      Then the following code must be written in the Tomcat configuration file {TOMCAT_HOME}/conf/context.xml

                                                                                                                      <Context>\n   ...\n      <Resource name=\"jdbc/sqlserver\"\n      auth=\"Container\"\n      type=\"javax.sql.DataSource\"\n      driverClassName=\"com.microsoft.sqlserver.jdbc.SQLServerDriver\"\n      url=\"jdbc:sqlserver://localhost:1433;databaseName=test;user=admin;password=admin;\"\n      username=\"admin\" password=\"admin\"\n      maxTotal=\"20\"\n      initialSize=\"0\"\n      minIdle=\"0\"\n      maxIdle=\"8\"\n      maxWait=\"10000\"\n      timeBetweenEvictionRunsMillis=\"30000\"\n      minEvictableIdleTimeMillis=\"60000\"\n      testWhileIdle=\"true\"\n      poolPreparedStatements=\"true\"\n      maxOpenPreparedStatements=\"100\"\n      validationQuery=\"SELECT 1\"\n      maxAge=\"600000\"\n      rollbackOnReturn=\"true\"\n      />\n</Context>\n

                                                                                                                      Note

                                                                                                                      Note that database name, username and password must be defined directly in the URL.

                                                                                                                      "},{"location":"tutorials/tomcat-jndi/tomcat-jndi/#geoserver-setup_2","title":"GeoServer setup","text":"

                                                                                                                      Login into the GeoServer web administration interface.

                                                                                                                      First, choose the Microsoft SQL Server (JNDI) datastore and give it a name:

                                                                                                                      Then configure the associated params:

                                                                                                                      "},{"location":"webadmin/","title":"Web administration interface","text":"

                                                                                                                      The Web administration interface is a web-based tool for configuring all aspects of GeoServer, from adding data to changing service settings. In a default GeoServer installation, this interface is accessed via a web browser at http://localhost:8080/geoserver/web. However, this URL may vary depending on your local installation.

                                                                                                                      Web admin interface

                                                                                                                      The following sections detail the menu options available in GeoServer. Unless otherwise specified, you will need to be logged in with administrative credentials to see the complete list of pages.

                                                                                                                      "},{"location":"webadmin/#welcome","title":"Welcome","text":"
                                                                                                                      • The Welcome page lists the web services published by GeoServer.

                                                                                                                        When logged in with administrative credentials a configuration overview is provided, along with any information or warning notifications.

                                                                                                                      "},{"location":"webadmin/#about-status","title":"About & Status","text":"

                                                                                                                      The About & Status section provides access to GeoServer diagnostic and configuration tools, and can be particularly useful for debugging.

                                                                                                                      • The Status page shows a summary of server configuration parameters and run-time status.

                                                                                                                      • The GeoServer Logs page shows the GeoServer log output. This is useful for determining errors without having to leave the browser.

                                                                                                                      • The Contact Information page sets the public contact information available in the Capabilities document of the WMS server.

                                                                                                                      • The About GeoServer Page section provides links to the GeoServer documentation, homepage and bug tracker.

                                                                                                                        You do not need to be logged into GeoServer to access this page.

                                                                                                                      "},{"location":"webadmin/#data","title":"Data","text":"

                                                                                                                      The Data management section contains configuration options for all the different data-related settings.

                                                                                                                      • The Layer Preview page provides links to layer previews in various output formats, including the common OpenLayers and KML formats. This page helps to visually verify and explore the configuration of a particular layer.

                                                                                                                        You do not need to be logged into GeoServer to access the Layer Preview.

                                                                                                                      • The Workspaces page displays a list of workspaces, with the ability to add, edit, and delete. Also shows which workspace is the default for the server.

                                                                                                                      • The Stores page displays a list of stores, with the ability to add, edit, and delete. Details include the workspace associated with the store, the type of store (data format), and whether the store is enabled.

                                                                                                                      • The Layers page displays a list of layers, with the ability to add, edit, and delete. Details include the workspace and store associated with the layer, whether the layer is enabled, and the spatial reference system (SRS) of the layer.

                                                                                                                      • The Layer Groups page displays a list of layer groups, with the ability to add, edit, and delete. Details include the associated workspace (if any).

                                                                                                                      • The Styles page displays a list of styles, with the ability to add, edit, and delete. Details include the associated workspace (if any).

                                                                                                                      In each of these pages that contain a table, there are three different ways to locate an object: sorting, searching, and paging. To alphabetically sort a data type, click on the column header. For simple searching, enter the search criteria in the search box and hit Enter. And to page through the entries (25 at a time), use the arrow buttons located on the bottom and top of the table.

                                                                                                                      These pages are shown to administrators, and users that have data admin permissions.

                                                                                                                      "},{"location":"webadmin/#services","title":"Services","text":"

                                                                                                                      The Services section is for configuring the services published by GeoServer.

                                                                                                                      • The Web Coverage Service (WCS) page manages metadata, resource limits, and SRS availability for WCS.
                                                                                                                      • The Web Feature Service (WFS) page manages metadata, feature publishing, service level options, and data-specific output for WFS.
                                                                                                                      • The Web Map Service (WMS) page manages metadata, resource limits, SRS availability, and other data-specific output for WMS.
                                                                                                                      • The Web Processing Service (WPS) page manages metadata and resource limits for WPS.
                                                                                                                      "},{"location":"webadmin/#settings","title":"Settings","text":"

                                                                                                                      The Settings section contains configuration settings that apply to the entire server.

                                                                                                                      • The Global Settings page configures messaging, logging, character and proxy settings for the entire server.
                                                                                                                      • The Image Processing page configures several JAI parameters, used by both WMS and WCS operations.
                                                                                                                      • The Coverage Access page configures settings related to loading and publishing coverages.
                                                                                                                      "},{"location":"webadmin/#tile-caching","title":"Tile Caching","text":"

                                                                                                                      The Tile Caching section configures the embedded GeoWebCache.

                                                                                                                      • The Tile Layers page shows which layers in GeoServer are also available as tiled (cached)layers, with the ability to add, edit, and delete.
                                                                                                                      • The Caching Defaults page sets the global options for the caching service.
                                                                                                                      • The Gridsets page shows all available gridsets for the tile caches, with the ability to add, edit, and delete.
                                                                                                                      • The Disk Quota page sets the options for tile cache management on disk, including strategies to reduce file size when necessary.
                                                                                                                      • The BlobStores pages manages the different blobstores (tile cache sources) known to the embedded GeoWebCache.
                                                                                                                      "},{"location":"webadmin/#security","title":"Security","text":"

                                                                                                                      The Security section configures the built-in security subsystem.

                                                                                                                      • The Settings page manages high-level options for the security subsystem.
                                                                                                                      • The Authentication page manages authentication filters, filter chains, and providers.
                                                                                                                      • The Passwords page manages the password policies for users and the root account.
                                                                                                                      • The Users, Groups, Roles page manages the users, groups, and roles, and how they are all associated with each other. Passwords for user accounts can be changed here.
                                                                                                                      • The Data page manages the data-level security options, allowing workspaces and layers to be restricted by role.
                                                                                                                      • The Services page manages the service-level security options, allowing services and operations to be restricted by role.
                                                                                                                      "},{"location":"webadmin/#demos","title":"Demos","text":"

                                                                                                                      The Demos section contains links to example WMS, WCS, and WFS requests for GeoServer as well as a listing all SRS info known to GeoServer. In addition, there is a reprojection console for converting coordinates between spatial reference systems, and a request builder for WCS requests.

                                                                                                                      You do not need to be logged into GeoServer to access these pages.

                                                                                                                      "},{"location":"webadmin/#tools","title":"Tools","text":"

                                                                                                                      The Tools section contains administrative tools.

                                                                                                                      • The Web Resource tool provides management of data directory icons, fonts, and configuration files.
                                                                                                                      • The Catalog Bulk Load Tool can bulk copy configuration for testing
                                                                                                                      "},{"location":"webadmin/#extensions","title":"Extensions","text":"

                                                                                                                      GeoServer extensions can add functionality and extra options to the web interface. Details can be found in the section for each extension.

                                                                                                                      "},{"location":"webadmin/#user-interface","title":"User interface","text":""},{"location":"webadmin/#navigation","title":"Navigation","text":"

                                                                                                                      A navigation menu is provided along the left-hand-side of the screen listing configuration pages.

                                                                                                                      To return to the main Welcome click on the GeoServer logo at the top of the navigation menu.

                                                                                                                      "},{"location":"webadmin/#user-login","title":"User login","text":"

                                                                                                                      The upper right of the web administration interface provides options to login.

                                                                                                                      GeoServer will share only the web services and layers available to the current user.

                                                                                                                      "},{"location":"webadmin/#choosing-the-ui-language","title":"Choosing the UI language","text":"

                                                                                                                      The administration interface is displayed using the browser's preferred language when available, otherwise it will fall back to English. The drop-down chooser on the side of the login/logout button allows selection of a different language.

                                                                                                                      The language choice is saved in the session, as well as in a cookie, to retain the language choice across user sessions.

                                                                                                                      "},{"location":"webadmin/about/","title":"About GeoServer Page","text":"

                                                                                                                      The About Page provides information about GeoServer along with useful documentation links.

                                                                                                                      About GeoServer Page

                                                                                                                      "},{"location":"webadmin/welcome/","title":"Welcome","text":"

                                                                                                                      The Welcome Page lists the web services published by GeoServer for mapping, data access and processing.

                                                                                                                      "},{"location":"webadmin/welcome/#welcome_webservices","title":"Web Services","text":"

                                                                                                                      The welcome page lists the global web services (accessing the complete list of layers).

                                                                                                                      Welcome Page Global Services

                                                                                                                      To use copy-and-paste the web services URLs into your Desktop GIS or web mapping application.

                                                                                                                      QGIS Desktop GIS WMS Connection

                                                                                                                      QGIS Desktop GIS Add WMS Layer

                                                                                                                      QGIS Desktop GIS Map

                                                                                                                      Opening these URLs in the browser download or display machine readable the service description.

                                                                                                                      WMS 1.3.0 GetCapabilities Document

                                                                                                                      If global web services are disabled the initial welcome page web services will not be available.

                                                                                                                      "},{"location":"webadmin/welcome/#workspace-web-services","title":"Workspace Web Services","text":"

                                                                                                                      Use workspace select at the top of the welcome page to choose a workspace. The welcome page contact information and web services are updated to match the workspace selected.

                                                                                                                      Welcome Workspace Web Services

                                                                                                                      The web service links provided may be used in your Desktop GIS or web mapping application to access the workspace layers.

                                                                                                                      "},{"location":"webadmin/welcome/#layer-web-services","title":"Layer Web Services","text":"

                                                                                                                      Use the layer select at the top of the welcome page to choose a layer or layer group.

                                                                                                                      Welcome Workspace Web Services

                                                                                                                      The workspace select, along with the page contact information and web services are updated to match the layer selected.

                                                                                                                      "},{"location":"webadmin/welcome/#server-overview-administrators","title":"Server Overview (Administrators)","text":"

                                                                                                                      When logged in with administrative credentials a configuration overview is provided, along with any information or warning notifications.

                                                                                                                      Welcome Administrator Feedback

                                                                                                                      Click Layers summary link to navigate to the Layers page, press Add layers to create a new layer.

                                                                                                                      Click Stores summary link to navigate to the Stores page, press Add stores to create a new store.

                                                                                                                      Click Workspaces summary link to navigate to the Workspaces page, press Add workspaces to create a new workspace.

                                                                                                                      "},{"location":"webadmin/welcome/#information-and-warnings","title":"Information and Warnings","text":"

                                                                                                                      GeoServer status information messages provide feedback on normal operation.

                                                                                                                      Warnings describe configuration issues to be addressed, often with a short-cut to the configuration page used to address the issue.

                                                                                                                      "}]} \ No newline at end of file diff --git a/security/auth/chain/index.html b/security/auth/chain/index.html index da529cd129a..b7611c1dff0 100644 --- a/security/auth/chain/index.html +++ b/security/auth/chain/index.html @@ -1976,14 +1976,32 @@

                                                                                                                      Filter chain by request type

                                                                                                                      Query String regular expressions will match the full query string (\^ and \$ terminators are automatically appended), so to match only part of it, remember to prefix and postfix the expression with . (e.g. .request=getcapabilities.*)

                                                                                                                      Examples of rules (ANT patterns and query string regular expressions)

                                                                                                                      -
                                                                                                                      -

                                                                                                                      Pattern Description

                                                                                                                      -
                                                                                                                      -

                                                                                                                      /wms, /wms/** simple ANT pattern

                                                                                                                      -

                                                                                                                      /wms|.request=GetMap. ANT pattern and querystring regex to match one parameter

                                                                                                                      -

                                                                                                                      /wms|(?=.request=getmap)(?=.format=image/png).* ANT pattern and querystring regex to match two parameters in any order

                                                                                                                      -

                                                                                                                      /wms|(?=.request=getmap)(?!.format=image/png).* ANT pattern and querystring regex to match one parameters and be sure another one is not matched

                                                                                                                      -
                                                                                                                      + + + + + + + + + + + + + + + + + + + + + + + + + +
                                                                                                                      PatternDescription
                                                                                                                      /wms, /wms/**simple ANT pattern
                                                                                                                      /wms.request=GetMap.
                                                                                                                      /wms(?=.request=getmap)(?=.format=image/png).*
                                                                                                                      /wms(?=.request=getmap)(?!.format=image/png).*
                                                                                                                      diff --git a/security/layer/index.html b/security/layer/index.html index 6907a3ffd82..2f72ef7caeb 100644 --- a/security/layer/index.html +++ b/security/layer/index.html @@ -2032,13 +2032,28 @@

                                                                                                                      Catalog Mode

                                                                                                                      mode=option
                                                                                                                       

                                                                                                                      option may be one of three values:

                                                                                                                      -
                                                                                                                      -

                                                                                                                      Option Description

                                                                                                                      -
                                                                                                                      -

                                                                                                                      hide (Default) Hides layers that the user does not have read access to, and behaves as if a layer is read only if the user does not have write permissions. The capabilities documents will not contain the layers the current user cannot access. This is the highest security mode. As a result, it may not work very well with clients such as uDig or Google Earth.

                                                                                                                      -

                                                                                                                      challenge Allows free access to metadata, but any attempt at accessing actual data is met by a HTTP 401 code (which forces most clients to show an authentication dialog). The capabilities documents contain the full list of layers. DescribeFeatureType and DescribeCoverage operations work successfully. This mode works fine with clients such as uDig or Google Earth.

                                                                                                                      -

                                                                                                                      mixed Hides the layers the user cannot read from the capabilities documents, but triggers authentication for any other attempt to access the data or the metadata. This option is useful if you don't want the world to see the existence of some of your data, but you still want selected people to who have data access links to get the data after authentication.

                                                                                                                      -
                                                                                                                      + + + + + + + + + + + + + + + + + + + + + +
                                                                                                                      OptionDescription
                                                                                                                      hide(Default) Hides layers that the user does not have read access to, and behaves as if a layer is read only if the user does not have write permissions. The capabilities documents will not contain the layers the current user cannot access. This is the highest security mode. As a result, it may not work very well with clients such as uDig or Google Earth.
                                                                                                                      challengeAllows free access to metadata, but any attempt at accessing actual data is met by a HTTP 401 code (which forces most clients to show an authentication dialog). The capabilities documents contain the full list of layers. DescribeFeatureType and DescribeCoverage operations work successfully. This mode works fine with clients such as uDig or Google Earth.
                                                                                                                      mixedHides the layers the user cannot read from the capabilities documents, but triggers authentication for any other attempt to access the data or the metadata. This option is useful if you don't want the world to see the existence of some of your data, but you still want selected people to who have data access links to get the data after authentication.

                                                                                                                      Access modes

                                                                                                                      The access mode defines what level of access should be granted on a specific workspace/layer to a particular role. There are three types of access mode:

                                                                                                                        @@ -2067,14 +2082,47 @@

                                                                                                                        Protecting a single wo topp.congress_district.w=STATE_LEGISLATORS

      The mapping of roles to permissions is as follows:

      -
      -

      Role private. topp. topp.congress_district (all other workspaces)

      -
      -

      NO_ONE (none) w (none) w

      -

      TRUSTED_ROLE r/w r r r

      -

      STATE_LEGISLATORS (none) r r/w r

      -

      (All other users) (none) r r r

      -
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      Roleprivate.*topp.*topp.congress_district(all other workspaces)
      NO_ONE(none)w(none)w
      TRUSTED_ROLEr/wrrr
      STATE_LEGISLATORS(none)rr/wr
      (All other users)(none)rrr

      Note

      Specific workspace rule private.*.r=TRUSTED_ROLE will take precedence over the more generic rule *.*.r=*. When a request is made to read a layer private:vulnerable_infrastructure the most specific rule available is used to control access. In this case the workspace rule private.*.r=TRUSTED_ROLE is the most specific and only users that have TRUSTED_ROLE will be granted r access and be able to read the private:vulnerable_infrastructure layer. Other users that do not have the TRUSTED_ROLE will not be granted r access and will be unable to access the private:vulnerable_infrastructure layer.

      @@ -2088,13 +2136,36 @@

      Locking down GeoServer

      army.*.w=MILITARY_ROLE,TRUSTED_ROLE

    The mapping of roles to permissions is as follows:

    -
    -

    Role topp. army. (All other workspaces)

    -
    -

    TRUSTED_ROLE r/w r/w r/w

    -

    MILITARY_ROLE r r/w (none)

    -

    (All other users) r (none) (none)

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Roletopp.*army.*(All other workspaces)
    TRUSTED_ROLEr/wr/wr/w
    MILITARY_ROLErr/w(none)
    (All other users)r(none)(none)

    Providing restricted administrative access

    The following provides administrative access on a single workspace to a specific role, in additional to the full administrator role:

    *.*.a=ROLE_ADMINISTRATOR
    @@ -2112,16 +2183,68 @@ 

    Managing multi-level permissions

    topp.military_bases.w=MILITARY_ROLE

    The mapping of roles to permissions is as follows:

    -
    -

    Role topp.states topp.poly_landmarks topp.military_bases topp.(all other layers) (All other workspaces)

    -
    -

    NO_ONE w r (none) w w

    -

    TRUSTED_ROLE r r (none) r r

    -

    MILITARY_ROLE (none) r r/w r (none)

    -

    USA_CITIZEN_ROLE r r (none) r (none)

    -

    LAND_MANAGER_ROLE r r/w (none) r (none)

    -

    (All other users) (none) r (none) r (none)

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Roletopp.statestopp.poly_landmarkstopp.military_basestopp.(all other layers)(All other workspaces)
    NO_ONEwr(none)ww
    TRUSTED_ROLErr(none)rr
    MILITARY_ROLE(none)rr/wr(none)
    USA_CITIZEN_ROLErr(none)r(none)
    LAND_MANAGER_ROLErr/w(none)r(none)
    (All other users)(none)r(none)r(none)

    Note

    The entry topp.states.w=NO_ONE is not required because this permission would be inherited from the global level (the entry *.*.w=NO_ONE).

    diff --git a/security/urlchecks/index.html b/security/urlchecks/index.html index 5f9b584be64..1d47f36aea1 100644 --- a/security/urlchecks/index.html +++ b/security/urlchecks/index.html @@ -1899,24 +1899,51 @@

    Removing a regular expression

    To remove a URL Check, select the checkbox next to one or more rows in the URL Check list table. Press the Remove selected URL checks button to remove. You will be asked to confirm or cancel the removal. Pressing OK removes the selected URL Checks.

    Editing a URL Check

    Regular Expression URL checks can be configured, with the following parameters for each check:

    -
    -

    Field Description

    -
    -

    Name Name for the check, used to identify it in the list.

    -

    Description Description of the check, for later reference.

    -

    Regular Expression A regular expression used to match allowed URLs

    -

    Enabled Check box to enable or disable the check

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + +
    FieldDescription
    NameName for the check, used to identify it in the list.
    DescriptionDescription of the check, for later reference.
    Regular ExpressionA regular expression used to match allowed URLs
    EnabledCheck box to enable or disable the check

    Configure Regular Expression URL check

    Testing URL checks

    The Test URL Checks with external URL form allows a URL to be checked, reporting if access is allowed or disallowed.

    Test URL Checks form:

    -
    -

    Field Description

    -
    -

    URL to check Supply URL of external resource to check if access is allowed

    -
    + + + + + + + + + + + + + +
    FieldDescription
    URL to checkSupply URL of external resource to check if access is allowed

    Press the Test URL button to perform the checks. If at least one URL Check matches the URL, it will be allowed and the test will indicate the URL Check permitting access. Otherwise it will be rejected and the test will indicate that no URL Check matched.

    Test URL Checks with external URL

    diff --git a/security/usergrouprole/roleservices/index.html b/security/usergrouprole/roleservices/index.html index 52ef2822fe6..741f9477fff 100644 --- a/security/usergrouprole/roleservices/index.html +++ b/security/usergrouprole/roleservices/index.html @@ -2233,77 +2233,168 @@

    <security-role-ref>

    JDBC role service

    The JDBC role service persists the role database via JDBC, managing the role information in multiple tables. The role database schema is as follows:

    -
    -

    Field Type Null Key

    -
    -

    name varchar(64) NO PRI

    -

    parent varchar(64) YES

    -
    -
    -
    Table: roles
    -
    -
    -

    Field Type Null Key

    -
    -

    rolename varchar(64) NO PRI

    -

    propname varchar(64) NO PRI

    -

    propvalue varchar(2048) YES

    -
    -
    -
    Table: role_props
    -
    -
    -

    Field Type Null Key

    -
    -

    username varchar(128) NO PRI

    -

    rolename varchar(64) NO PRI

    -
    -
    -
    Table: user_roles
    -
    -
    -

    Field Type Null Key

    -
    -

    groupname varchar(128) NO PRI

    -

    rolename varchar(64) NO PRI

    -
    -
    -
    Table: group_roles
    -
    + + + + + + + + + + + + + + + + + + + + + + + +
    FieldTypeNullKey
    namevarchar(64)NOPRI
    parentvarchar(64)YES
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    FieldTypeNullKey
    rolenamevarchar(64)NOPRI
    propnamevarchar(64)NOPRI
    propvaluevarchar(2048)YES
    + + + + + + + + + + + + + + + + + + + + + + + +
    FieldTypeNullKey
    usernamevarchar(128)NOPRI
    rolenamevarchar(64)NOPRI
    + + + + + + + + + + + + + + + + + + + + + + + +
    FieldTypeNullKey
    groupnamevarchar(128)NOPRI
    rolenamevarchar(64)NOPRI

    The roles table is the primary table and contains the list of roles. Roles in GeoServer support inheritance, so a role may optionally have a link to a parent role. The role_props table maps additional properties to a role. (See the section on Roles for more details.) The user_roles table maps users to the roles they are assigned. Similarly, the group_roles table maps which groups have been assigned to which roles.

    The default GeoServer security configuration is:

    -
    -

    name parent

    -
    -

    Empty Empty

    -
    -
    -
    Table: roles
    -
    -
    -

    rolename propname propvalue

    -
    -

    Empty Empty Empty

    -
    -
    -
    Table: role_props
    -
    -
    -

    username rolename

    -
    -

    Empty Empty

    -
    -
    -
    Table: user_roles
    -
    -
    -

    groupname rolename

    -
    -

    Empty Empty

    -
    -
    -
    Table: group_roles
    -
    + + + + + + + + + + + + + +
    nameparent
    EmptyEmpty
    + + + + + + + + + + + + + + + +
    rolenamepropnamepropvalue
    EmptyEmptyEmpty
    + + + + + + + + + + + + + +
    usernamerolename
    EmptyEmpty
    + + + + + + + + + + + + + +
    groupnamerolename
    EmptyEmpty

    For further information, please refer to configuring a role service in the Web administration interface.

    LDAP role service

    The LDAP role service is a read only role service that maps groups from an LDAP repository to GeoServer roles.

    @@ -2335,21 +2426,48 @@

    REST role service

    The REST role service is a read only role service that maps groups and associated users to roles from a remote REST web service.

    The REST service must support JSON encoding.

    Here is a listing of significant methods provided by the REST Role Service (based on the LDAP role service, which similarly has to make network calls to work):

    -
    -

    Method Mandatory

    -
    -

    getUserNamesForRole(roleName) N (implemented in LDAP, but I don't see actual users of this method besides a utility method that nobody uses)

    -

    getRolesForUser(user) Y

    -

    getRolesForGroup(group) N

    -

    getRoles() Y (used by the UI)

    -

    getParentRole(role) N

    -

    getAdminRole() Y

    -

    getGroupAdminRole() Y

    -

    getRoleCount() Y (does not seem to be used much, we can trivially implement it from getRoles()

    -
    -
    -
    Table: roles
    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    MethodMandatory
    getUserNamesForRole(roleName)N (implemented in LDAP, but I don't see actual users of this method besides a utility method that nobody uses)
    getRolesForUser(user)Y
    getRolesForGroup(group)N
    getRoles()Y (used by the UI)
    getParentRole(role)N
    getAdminRole()Y
    getGroupAdminRole()Y
    getRoleCount()Y (does not seem to be used much, we can trivially implement it from getRoles()

    REST APIs

    The following is an example of the REST API the role service may handle. The JSON and remote endpoints may differ; this is configurable via UI, allowing the REST role service to connect to a generic REST Service

    From the above we could have the following REST API to talk to

    diff --git a/security/usergrouprole/usergroupservices/index.html b/security/usergrouprole/usergroupservices/index.html index 39cfe0d0d2a..0f0ecaa9fce 100644 --- a/security/usergrouprole/usergroupservices/index.html +++ b/security/usergrouprole/usergroupservices/index.html @@ -1989,78 +1989,176 @@

    XML user/group service

    For further information, please refer to configuring a user/group service in the Web administration interface.

    JDBC user/group service

    The JDBC user/group service persists the user/group database via JDBC, managing the user information in multiple tables. The user/group database schema is as follows:

    -
    -

    Field Type Null Key

    -
    -

    name varchar(128) NO PRI

    -

    password varchar(254) YES

    -

    enabled char(1) NO

    -
    -
    -
    Table: users
    -
    -
    -

    Field Type Null Key

    -
    -

    username varchar(128) NO PRI

    -

    propname varchar(64) NO PRI

    -

    propvalue varchar(2048) YES

    -
    -
    -
    Table: user_props
    -
    -
    -

    Field Type Null Key

    -
    -

    name varchar(128) NO PRI

    -

    enabled char(1) NO

    -
    -
    -
    Table: groups
    -
    -
    -

    Field Type Null Key

    -
    -

    groupname varchar(128) NO PRI

    -

    username varchar(128) NO PRI

    -
    -
    -
    Table: group_members
    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    FieldTypeNullKey
    namevarchar(128)NOPRI
    passwordvarchar(254)YES
    enabledchar(1)NO
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    FieldTypeNullKey
    usernamevarchar(128)NOPRI
    propnamevarchar(64)NOPRI
    propvaluevarchar(2048)YES
    + + + + + + + + + + + + + + + + + + + + + + + +
    FieldTypeNullKey
    namevarchar(128)NOPRI
    enabledchar(1)NO
    + + + + + + + + + + + + + + + + + + + + + + + +
    FieldTypeNullKey
    groupnamevarchar(128)NOPRI
    usernamevarchar(128)NOPRI

    The users table is the primary table and contains the list of users with associated passwords. The user_props table maps additional properties to a user. (See Users and Groups for more details.) The groups table lists all available groups, and the group_members table maps which users belong to which groups.

    The default GeoServer security configuration is:

    -
    -

    name password enabled

    -
    -

    Empty Empty Empty

    -
    -
    -
    Table: users
    -
    -
    -

    username propname propvalue

    -
    -

    Empty Empty Empty

    -
    -
    -
    Table: user_props
    -
    -
    -

    name enabled

    -
    -

    Empty Empty

    -
    -
    -
    Table: groups
    -
    -
    -

    groupname username

    -
    -

    Empty Empty

    -
    -
    -
    Table: group_members
    -
    + + + + + + + + + + + + + + + +
    namepasswordenabled
    EmptyEmptyEmpty
    + + + + + + + + + + + + + + + +
    usernamepropnamepropvalue
    EmptyEmptyEmpty
    + + + + + + + + + + + + + +
    nameenabled
    EmptyEmpty
    + + + + + + + + + + + + + +
    groupnameusername
    EmptyEmpty

    For further information, please refer to configuring a user/group service in the Web administration interface.

    LDAP user/group service

    The LDAP user/group service is a read only user/group service that maps users and groups from an LDAP repository to GeoServer users and groups.

    diff --git a/security/webadmin/auth/index.html b/security/webadmin/auth/index.html index f9e9d03620c..cbbc5ee61bf 100644 --- a/security/webadmin/auth/index.html +++ b/security/webadmin/auth/index.html @@ -2135,15 +2135,36 @@

    Brute force attack prevention

    GeoServer ships with a delay based brute force attack prevention system.

    Brute force attack prevention settings

    -
    -

    Option Description

    -
    -

    Enabled Whether the brute force attack prevention is enabled. Defaults to true.

    -

    Minimum delay on failed authentication (seconds) Minimum number of seconds a failed login request will be made to wait before getting a response

    -

    Maximum delay on failed authentication (seconds) Maximum number of seconds a failed login request will be made to wait before getting a response

    -

    Excluded network masks Network masks identifying hosts that are excluded from brute force attack prevention. Can be empty, include specific IPs, or a list of network masks. Defaults to 127.0.0.1, the localhost.

    -

    Maximum number of threads blocked on failed login delay Limits the number of threads that get delayed on failed login, should be set to a value less than the container's available response threads.

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    OptionDescription
    EnabledWhether the brute force attack prevention is enabled. Defaults to true.
    Minimum delay on failed authentication (seconds)Minimum number of seconds a failed login request will be made to wait before getting a response
    Maximum delay on failed authentication (seconds)Maximum number of seconds a failed login request will be made to wait before getting a response
    Excluded network masksNetwork masks identifying hosts that are excluded from brute force attack prevention. Can be empty, include specific IPs, or a list of network masks. Defaults to 127.0.0.1, the localhost.
    Maximum number of threads blocked on failed login delayLimits the number of threads that get delayed on failed login, should be set to a value less than the container's available response threads.

    The mechanism works as follows:

    • Each failed authentication request is made to wait between min and max seconds before getting an actual response back.
    • @@ -2174,16 +2195,40 @@

      Credentials from Headers filter

      This filter allows gathering user credentials (username and password) from request headers in a flexible and configurable way.

      Creating a new authentication filter fetching credentials from request headers

      -
      -

      Option Description

      -
      -

      Name Name of the filter

      -

      Username Header Name of the Request Header containing the username

      -

      Regular Expression for Username Regular Expression used to extract the username from the related Header. Must define a group that will match the username.

      -

      Password Header Name of the Request Header containing the password

      -

      Regular Expression for Password Regular Expression used to extract the password from the related Header. Must define a group that will match the password.

      -

      Parse Arguments as Uri Components If checked username and password are URI decoded before being used as credentials

      -
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      OptionDescription
      NameName of the filter
      Username HeaderName of the Request Header containing the username
      Regular Expression for UsernameRegular Expression used to extract the username from the related Header. Must define a group that will match the username.
      Password HeaderName of the Request Header containing the password
      Regular Expression for PasswordRegular Expression used to extract the password from the related Header. Must define a group that will match the password.
      Parse Arguments as Uri ComponentsIf checked username and password are URI decoded before being used as credentials

      Authentication providers

      This section manages the security_auth_providers (adding, removing, and editing). The default authentication provider uses basic username/password authentication <../auth/providers.rst#security_auth_provider_userpasswd>_. JDBC and LDAP authentication can also be used.

      Click Add new to create a new provider. Click an existing provider to edit its parameters.

      @@ -2193,24 +2238,54 @@

      Username/password provider

      The default new authentication provider uses a user/group service for authentication.

      Creating a new authentication provider with a username and password

      -
      -

      Option Description

      -
      -

      Name Name of the provider

      -

      User Group Service Name of the user/group service associated with this provider. Can be any one of the active user/group services.

      -
      + + + + + + + + + + + + + + + + + +
      OptionDescription
      NameName of the provider
      User Group ServiceName of the user/group service associated with this provider. Can be any one of the active user/group services.

      JDBC provider

      The configuration options for the JDBC authentication provider are illustrated below.

      Configuring the JDBC authentication provider

      -
      -

      Option Description

      -
      -

      Name Name of the JDBC connection in GeoServer

      -

      User Group Service Name of the user/group service to use to load user information after the user is authenticated

      -

      Driver class name JDBC driver to use for the database connection

      -

      Connection URL JDBC URL to use when creating the database connection

      -
      + + + + + + + + + + + + + + + + + + + + + + + + + +
      OptionDescription
      NameName of the JDBC connection in GeoServer
      User Group ServiceName of the user/group service to use to load user information after the user is authenticated
      Driver class nameJDBC driver to use for the database connection
      Connection URLJDBC URL to use when creating the database connection

      LDAP provider

      The following illustration shows the configuration options for the LDAP authentication provider. The default option is to use LDAP groups for role assignment, but there is also an option to use a user/group service for role assignment. Depending on whether this option is selected, the page itself will have different options.

      diff --git a/security/webadmin/data/index.html b/security/webadmin/data/index.html index a0777e389fa..03f9b38cd4c 100644 --- a/security/webadmin/data/index.html +++ b/security/webadmin/data/index.html @@ -1990,17 +1990,44 @@

      Rules

      Creating a new rule

      Editing a layer group rule

      -
      -

      Option Description

      -
      -

      Global layer group rule If checked, switches the editor to create/edit a rule about a global layer group (and will remove the layer configuration as a result)

      -

      Workspace Sets the allowed workspace for this rule. Options are * (all workspaces), or the name of each workspace.

      -

      Layer and groups Sets the allowed layer/groups for this rule. Options are * (all layers/groups in the chosen workspace), or the name of each layer in the above workspace. Will be disabled until the workspace is set.

      -

      Access mode Specifies whether the rule refers to either Read or Write mode

      -

      Grant access to any role If selected, the rule will apply to all roles, with no need to specify

      -

      Role list Full list of roles, including a list of roles to which the rule is associated. Association can be toggled here via the arrow buttons. This option is not applied if Grant access to any role is checked.

      -

      Add a new role Shortcut to adding a new role

      -
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      OptionDescription
      Global layer group ruleIf checked, switches the editor to create/edit a rule about a global layer group (and will remove the layer configuration as a result)
      WorkspaceSets the allowed workspace for this rule. Options are * (all workspaces), or the name of each workspace.
      Layer and groupsSets the allowed layer/groups for this rule. Options are * (all layers/groups in the chosen workspace), or the name of each layer in the above workspace. Will be disabled until the workspace is set.
      Access modeSpecifies whether the rule refers to either Read or Write mode
      Grant access to any roleIf selected, the rule will apply to all roles, with no need to specify
      Role listFull list of roles, including a list of roles to which the rule is associated. Association can be toggled here via the arrow buttons. This option is not applied if Grant access to any role is checked.
      Add a new roleShortcut to adding a new role

      Catalog Mode

      This mode configures how GeoServer will advertise secured layers and behave when a secured layer is accessed without the necessary privileges. There are three options: HIDE, MIXED, and CHALLENGE. For further information on these options, please see the section on Layer security.

      diff --git a/security/webadmin/services/index.html b/security/webadmin/services/index.html index 1d22c5baf6a..346bee61a60 100644 --- a/security/webadmin/services/index.html +++ b/security/webadmin/services/index.html @@ -1913,15 +1913,36 @@

      Services

      Clicking the Add a new rule link will create a new rule.

      New service rule

      -
      -

      Option Description

      -
      -

      Service Sets the OWS service for this rule. Options are *, meaning all services, wcs, wfs, or wms.

      -

      Method Sets the specific operation for this rule. Options depend on the Service, but include *, meaning all operations, as well as every service operation known to GeoServer, such as Capabilities, Transaction, GetMap, and more.

      -

      Grant access to any role If selected, the rule will apply to all roles (no need to specify which ones)

      -

      Role list Full list of roles, including a list of roles to which the rule is associated. Association can be switched here via the arrow buttons. This option is not applied if Grant access to any role is checked.

      -

      Add a new role Shortcut to adding a new role

      -
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      OptionDescription
      ServiceSets the OWS service for this rule. Options are *, meaning all services, wcs, wfs, or wms.
      MethodSets the specific operation for this rule. Options depend on the Service, but include *, meaning all operations, as well as every service operation known to GeoServer, such as Capabilities, Transaction, GetMap, and more.
      Grant access to any roleIf selected, the rule will apply to all roles (no need to specify which ones)
      Role listFull list of roles, including a list of roles to which the rule is associated. Association can be switched here via the arrow buttons. This option is not applied if Grant access to any role is checked.
      Add a new roleShortcut to adding a new role
      diff --git a/security/webadmin/ugr/index.html b/security/webadmin/ugr/index.html index 7a219da316a..cc752fb9adc 100644 --- a/security/webadmin/ugr/index.html +++ b/security/webadmin/ugr/index.html @@ -2235,43 +2235,115 @@

      Add new XML user/group service

      To add a new XML user/group service, click the Add new link. XML is the default option. The following figure shows the configuration options for an XML user/group service.

      Adding an XML user/group service

      -
      -

      Option Description

      -
      -

      Name The name of the user/group service

      -

      Password encryption Sets the type of Password encryption. Options are Plain text, Weak PBE, Strong PBE, and Digest.

      -

      Password policy Sets the password policy. Options are any active password policies as set in the Passwords section.

      -

      XML filename Name of the file that will contain the user and group information. Default is users.xml in the security/usergroup/<name_of_usergroupservice> directory.

      -

      Enable schema validation If selected, forces schema validation to occur every time the XML file is read. This option is useful when editing the XML file by hand.

      -

      File reload interval Defines the frequency (in milliseconds) in which GeoServer will check for changes to the XML file. If the file is found to have been modified, GeoServer will recreate the user/group database based on the current state of the file. This value is meant to be set in cases where the XML file contents might change "out of process" and not directly through the web admin interface. The value is specified in milliseconds. A value of 0 disables any checking of the file.

      -
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      OptionDescription
      NameThe name of the user/group service
      Password encryptionSets the type of Password encryption. Options are Plain text, Weak PBE, Strong PBE, and Digest.
      Password policySets the password policy. Options are any active password policies as set in the Passwords section.
      XML filenameName of the file that will contain the user and group information. Default is users.xml in the security/usergroup/<name_of_usergroupservice> directory.
      Enable schema validationIf selected, forces schema validation to occur every time the XML file is read. This option is useful when editing the XML file by hand.
      File reload intervalDefines the frequency (in milliseconds) in which GeoServer will check for changes to the XML file. If the file is found to have been modified, GeoServer will recreate the user/group database based on the current state of the file. This value is meant to be set in cases where the XML file contents might change "out of process" and not directly through the web admin interface. The value is specified in milliseconds. A value of 0 disables any checking of the file.

      Add new JDBC user/group service

      To add a new JDBC user/group service, click the Add new link, and then the JDBC option at the top of the following form. The following figure shows the configuration options for a JDBC user/group service.

      Adding a user/group service via JDBC

      -
      -

      Option Description

      -
      -

      Name Name of the JDBC user/group service in GeoServer

      -

      Password encryption The method to used to encrypt user passwords

      -

      Password policy The policy to use to enforce constraints on user passwords

      -

      JNDI When unchecked, specifies a direct connection to the database. When checked, specifies an existing connection located through JNDI.

      -

      Driver class name JDBC driver to use for the database connection

      -

      Connection URL Specifies the JDBC URL to use when creating the database connection

      -

      Username Username to use when connecting to the database

      -

      Password Password to use when connecting to the database

      -

      Create database tables Specifies whether to create all the necessary tables in the underlying database

      -

      Data Definition Language (DDL) file Specifies a custom DDL file to use for creating tables in the underlying database, for cases where the default DDL statements fail on the given database. If left blank, internal defaults are used.

      -

      Data Manipulation Language (DML) file Specifies a custom DML file to use for accessing tables in the underlying database, for cases where the default DML statements fail on the given database. If left blank, internal defaults are used.

      -
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      OptionDescription
      NameName of the JDBC user/group service in GeoServer
      Password encryptionThe method to used to encrypt user passwords
      Password policyThe policy to use to enforce constraints on user passwords
      JNDIWhen unchecked, specifies a direct connection to the database. When checked, specifies an existing connection located through JNDI.
      Driver class nameJDBC driver to use for the database connection
      Connection URLSpecifies the JDBC URL to use when creating the database connection
      UsernameUsername to use when connecting to the database
      PasswordPassword to use when connecting to the database
      Create database tablesSpecifies whether to create all the necessary tables in the underlying database
      Data Definition Language (DDL) fileSpecifies a custom DDL file to use for creating tables in the underlying database, for cases where the default DDL statements fail on the given database. If left blank, internal defaults are used.
      Data Manipulation Language (DML) fileSpecifies a custom DML file to use for accessing tables in the underlying database, for cases where the default DML statements fail on the given database. If left blank, internal defaults are used.

      In addition to the parameters listed above, the following additional parameter will apply when the JNDI flag is set.

      Adding a user/group service via JDBC with JNDI

      -
      -

      Option Description

      -
      -

      JNDI resource name JNDI name used to locate the database connection.

      -
      + + + + + + + + + + + + + +
      OptionDescription
      JNDI resource nameJNDI name used to locate the database connection.

      Add new LDAP user/group service

      To add a new LDAP user/group service, click the Add new link, and then the LDAP option at the top of the following form. The following figure shows the configuration options for a LDAP user/group service.

      @@ -2337,20 +2409,56 @@

      Edit user/group service

      Add user

      Creating or editing a user

      -
      -

      Option Description

      -
      -

      User name The name of the user

      -

      Enabled When selected, will enable the user to authenticate

      -

      Password The password for this user. Existing passwords will be obscured when viewed.

      -

      Confirm password To set or change the password enter the password twice.

      -

      User properties Key/value pairs associated with the user. Used for associating additional information with the user.

      -

      Group list Full list of groups, including list of groups to which the user is a member. Membership can be toggled here via the arrow buttons.

      -

      Add a new group Shortcut to adding a new group. Also available in the Groups tab.

      -

      Role list Full list of roles, including a list of roles to which the user is associated. Association can be toggled here via the arrow buttons.

      -

      Add a new role Shortcut to adding a new role

      -

      List of current roles for the user List of current roles associated with the user. Click a role to enable editing.

      -
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      OptionDescription
      User nameThe name of the user
      EnabledWhen selected, will enable the user to authenticate
      PasswordThe password for this user. Existing passwords will be obscured when viewed.
      Confirm passwordTo set or change the password enter the password twice.
      User propertiesKey/value pairs associated with the user. Used for associating additional information with the user.
      Group listFull list of groups, including list of groups to which the user is a member. Membership can be toggled here via the arrow buttons.
      Add a new groupShortcut to adding a new group. Also available in the Groups tab.
      Role listFull list of roles, including a list of roles to which the user is associated. Association can be toggled here via the arrow buttons.
      Add a new roleShortcut to adding a new role
      List of current roles for the userList of current roles associated with the user. Click a role to enable editing.

      The Groups tab provides configuration options for groups in this user/group service. There are options to add and remove a group, with an additional option to remove a group and the roles associated with that group.

      Groups tab

      @@ -2365,14 +2473,32 @@

      Remove User

      Add group

      Creating or editing a group

      -
      -

      Option Description

      -
      -

      Group name The name of the group

      -

      Enabled When selected the group will be active

      -

      Role list Full list of roles, including a list of roles to which the group is associated. Association can be toggled here via the arrow buttons.

      -

      Add a new role Shortcut to adding a new role

      -
      + + + + + + + + + + + + + + + + + + + + + + + + + +
      OptionDescription
      Group nameThe name of the group
      EnabledWhen selected the group will be active
      Role listFull list of roles, including a list of roles to which the group is associated. Association can be toggled here via the arrow buttons.
      Add a new roleShortcut to adding a new role

      In this menu, user/group services can be added, removed, or edited. By default, there is one user/group service in GeoServer, which is XML-based. It is encrypted with Weak PBE and uses the default password policy. It is also possible to have a user/group service based on JDBC with or without JNDI.

      Role services

      In this menu, role services can be added, removed, or edited. By default, the active role service in GeoServer is XML-based, but it is also possible to have a role service based on JDBC, with or without JNDI.

      @@ -2389,65 +2515,185 @@

      Add new XML role service

      To add a new XML role service, click the Add new link. XML is the default option. The following figure shows the configuration options for an XML role service.

      Adding an XML role service

      -
      -

      Option Description

      -
      -

      Name The name of the role service

      -

      Administrator role The name of the role that performs the administrator functions

      -

      XML filename Name of the file that will contain the role information. Default is roles.xml in the security/role/<name_of_roleservice> directory.

      -

      File reload interval Defines the frequency (in milliseconds) in which GeoServer will check for changes to the XML file. If the file is found to have been modified, GeoServer will recreate the user/group database based on the current state of the file. This value is meant to be set in cases where the XML file contents might change "out of process" and not directly through the web admin interface. The value is specified in milliseconds. A value of 0 disables any checking of the file.

      -
      + + + + + + + + + + + + + + + + + + + + + + + + + +
      OptionDescription
      NameThe name of the role service
      Administrator roleThe name of the role that performs the administrator functions
      XML filenameName of the file that will contain the role information. Default is roles.xml in the security/role/<name_of_roleservice> directory.
      File reload intervalDefines the frequency (in milliseconds) in which GeoServer will check for changes to the XML file. If the file is found to have been modified, GeoServer will recreate the user/group database based on the current state of the file. This value is meant to be set in cases where the XML file contents might change "out of process" and not directly through the web admin interface. The value is specified in milliseconds. A value of 0 disables any checking of the file.

      Add new JDBC role service

      To add a new XML role service, click the Add new link, and then the JDBC option at the top of the following form. The following figure shows the configuration options for a JDBC role service.

      Adding a role service via JDBC

      -
      -

      Option Description

      -
      -

      Name Name of the JDBC role service in GeoServer

      -

      Administrator role The name of the role that performs the administrator function

      -

      JNDI When unchecked, specifies a direct connection to the database. When checked, specifies an existing connection located through JNDI.

      -

      Driver class name JDBC driver to use for the database connection

      -

      Connection URL Specifies the JDBC URL to use when creating the database connection

      -

      Username Username to use when connecting to the database

      -

      Password Password to use when connecting to the database

      -

      Create database tables Specifies whether to create all the necessary tables in the underlying database

      -

      Data Definition Language (DDL) file Specifies a custom DDL file to use for creating tables in the underlying database, for cases where the default DDL statements fail on the given database. If left blank, internal defaults are used.

      -

      Data Manipulation Language (DML) file Specifies a custom DML file to use for accessing tables in the underlying database, for cases where the default DML statements fail on the given database. If left blank, internal defaults are used.

      -
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      OptionDescription
      NameName of the JDBC role service in GeoServer
      Administrator roleThe name of the role that performs the administrator function
      JNDIWhen unchecked, specifies a direct connection to the database. When checked, specifies an existing connection located through JNDI.
      Driver class nameJDBC driver to use for the database connection
      Connection URLSpecifies the JDBC URL to use when creating the database connection
      UsernameUsername to use when connecting to the database
      PasswordPassword to use when connecting to the database
      Create database tablesSpecifies whether to create all the necessary tables in the underlying database
      Data Definition Language (DDL) fileSpecifies a custom DDL file to use for creating tables in the underlying database, for cases where the default DDL statements fail on the given database. If left blank, internal defaults are used.
      Data Manipulation Language (DML) fileSpecifies a custom DML file to use for accessing tables in the underlying database, for cases where the default DML statements fail on the given database. If left blank, internal defaults are used.

      In addition to the parameters listed above, the following additional parameter will apply when the JNDI flag is set.

      Adding a role service via JDBC with JNDI

      -
      -

      Option Description

      -
      -

      JNDI resource name JNDI name used to locate the database connection.

      -
      + + + + + + + + + + + + + +
      OptionDescription
      JNDI resource nameJNDI name used to locate the database connection.

      Add new LDAP role service

      To add a new LDAP role service, click the Add new link, and then the LDAP option at the top of the following form. The following figure shows the configuration options for a LDAP role service.

      Adding a role service via LDAP

      -
      -

      Option Description

      -
      -

      Name Name of the LDAP role service in GeoServer

      -

      Administrator role The name of the role that performs the administrator function

      -

      Group administrator role The name of the role that performs the group administrator function

      -

      Server URL URL for the LDAP server connection. It must include the protocol, host, and port, as well as the "distinguished name" (DN) for the root of the LDAP tree.

      -

      TLS Enables a STARTTLS connection. (See the section on Secure LDAP connections.)

      -

      Group search base Relative name of the node in the tree to use as the base for LDAP groups. Example: ou=groups. The root DN specified as port of the Server URL is automatically appended.

      -

      Group user membership search filter Search pattern for extracting users of a LDAP group a user belongs to. This may contain some placeholder values: {0}, the username of the user, for example bob. {1}, the full DN of the user, for example uid=bob,ou=users. To use this placeholder, the Filter used to lookup user needs to be defined, so that the dn of a user can be extracted from its username.

      -

      All groups search filter Search pattern for locating the LDAP groups to be mapped to GeoServer roles inside the Group search base root node

      -

      Filter used to lookup user. optional filter used to extract a user dn, to be used together with Group user membership search filter when the {1} placeholder is specified. This may contain a placeholder value: {0}, the username of the user, for example bob.

      -

      Role prefix Prefix appended in front of role names extracted from the LDAP. If left blank, no prefix will be inserted.

      -

      Convert Role To Upper Case If selected all role names extracted from the LDAP will be converted to upper case.

      -

      Authenticate to extract roles When checked all LDAP searches will be done in authenticated mode, using the credentials given with the Username and Password options

      -

      Username Username to use when connecting to the LDAP server. Only applicable when the Authenticate to extract roles parameter is checked.

      -

      Password Password to use when connecting to the LDAP server. Only applicable when the Authenticate to extract roles parameter is checked.

      -

      Enable Hierarchical groups search When checked all LDAP group searches will use hierarchical mode, retrieving LDAP parent groups too.

      -

      Max depth for hierarchical groups search Max depth number for hierarchical LDAP groups search, use -1 for infinite depth. Only applicable when the Enable Hierarchical groups search parameter is checked.

      -

      Nested group search filter LDAP search pattern for searching parent groups. Only applicable when the Enable Hierarchical groups search parameter is checked.

      -
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      OptionDescription
      NameName of the LDAP role service in GeoServer
      Administrator roleThe name of the role that performs the administrator function
      Group administrator roleThe name of the role that performs the group administrator function
      Server URLURL for the LDAP server connection. It must include the protocol, host, and port, as well as the "distinguished name" (DN) for the root of the LDAP tree.
      TLSEnables a STARTTLS connection. (See the section on Secure LDAP connections.)
      Group search baseRelative name of the node in the tree to use as the base for LDAP groups. Example: ou=groups. The root DN specified as port of the Server URL is automatically appended.
      Group user membership search filterSearch pattern for extracting users of a LDAP group a user belongs to. This may contain some placeholder values: {0}, the username of the user, for example bob. {1}, the full DN of the user, for example uid=bob,ou=users. To use this placeholder, the Filter used to lookup user needs to be defined, so that the dn of a user can be extracted from its username.
      All groups search filterSearch pattern for locating the LDAP groups to be mapped to GeoServer roles inside the Group search base root node
      Filter used to lookup user.optional filter used to extract a user dn, to be used together with Group user membership search filter when the {1} placeholder is specified. This may contain a placeholder value: {0}, the username of the user, for example bob.
      Role prefixPrefix appended in front of role names extracted from the LDAP. If left blank, no prefix will be inserted.
      Convert Role To Upper CaseIf selected all role names extracted from the LDAP will be converted to upper case.
      Authenticate to extract rolesWhen checked all LDAP searches will be done in authenticated mode, using the credentials given with the Username and Password options
      UsernameUsername to use when connecting to the LDAP server. Only applicable when the Authenticate to extract roles parameter is checked.
      PasswordPassword to use when connecting to the LDAP server. Only applicable when the Authenticate to extract roles parameter is checked.
      Enable Hierarchical groups searchWhen checked all LDAP group searches will use hierarchical mode, retrieving LDAP parent groups too.
      Max depth for hierarchical groups searchMax depth number for hierarchical LDAP groups search, use -1 for infinite depth. Only applicable when the Enable Hierarchical groups search parameter is checked.
      Nested group search filterLDAP search pattern for searching parent groups. Only applicable when the Enable Hierarchical groups search parameter is checked.

      Edit role service

      Once the new role service is added (either XML or JDBC), clicking it in the list of role services will allow the additional options to be specified, such as the roles associated with the service.

      There are two tabs in the resulting menu: Settings and Roles. The Settings tab is identical to that found when creating the role service, while the Roles tab is described below.

      @@ -2457,13 +2703,28 @@

      Edit role service

      Add role

      Creating or editing a role

      -
      -

      Option Description

      -
      -

      Role name The name of role. Convention is uppercase, but is not required.

      -

      Parent roles The role that this role inherits. See the section on Roles for more information on inheritance.

      -

      Role parameters Key/value pairs associated with the role. Used for associating additional information with the role.

      -
      + + + + + + + + + + + + + + + + + + + + + +
      OptionDescription
      Role nameThe name of role. Convention is uppercase, but is not required.
      Parent rolesThe role that this role inherits. See the section on Roles for more information on inheritance.
      Role parametersKey/value pairs associated with the role. Used for associating additional information with the role.
      diff --git a/services/wcs/configuration/index.html b/services/wcs/configuration/index.html index 25e317ba1a2..3aaf1401b5c 100644 --- a/services/wcs/configuration/index.html +++ b/services/wcs/configuration/index.html @@ -2002,23 +2002,77 @@

      WCS configuration

      Coverage processing

      The WCS processing chain can be tuned in respect of how raster overviews and read subsampling are used.

      The overview policy has four possible values:

      -
      -

      Option Description Version

      -

      Lower resolution overview Looks up the two overviews with a resolution closest to the one requested and chooses the one at the lower resolution. 2.0.3

      -

      Don't use overviews Overviews will be ignored, the data at its native resolution will be used instead. This is the default value. 2.0.3

      -

      Higher resolution overview Looks up the two overviews with a resolution closest to the one requested and chooses the one at the higher resolution. 2.0.3

      -

      Closest overview Looks up the overview closest to the one requested 2.0.3

      -
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      OptionDescriptionVersion
      Lower resolution overviewLooks up the two overviews with a resolution closest to the one requested and chooses the one at the lower resolution.2.0.3
      Don't use overviewsOverviews will be ignored, the data at its native resolution will be used instead. This is the default value.2.0.3
      Higher resolution overviewLooks up the two overviews with a resolution closest to the one requested and chooses the one at the higher resolution.2.0.3
      Closest overviewLooks up the overview closest to the one requested2.0.3

      While reading coverage data at a resolution lower than the one available on persistent storage its common to use subsampling, that is, read one every N pixels as a way to reduce the resolution of the data read in memory. Use subsampling controls whether subsampling is enabled or not.

      Resource consumption limits

      The request limit options allow the administrator to limit the resources consumed by each WCS GetCoverage request.

      The request limits limit the size of the image read from the source and the size of the image returned to the client. Both of these limits are to be considered a worst case scenario and are setup to make sure the server never gets asked to deal with too much data.

      -
      -

      Option Description Version

      -

      Maximum input memory Sets the maximum amount of memory, in kilobytes, a GetCovearge request might use, at most, to read a coverage from the data source. The memory is computed as rw * rh * pixelsize, where rw and rh are the size of the raster to be read and pixelsize is the dimension or a pixel (e.g., a RGBA image will have 32bit pixels, a batimetry might have 16bit signed int ones) 2.0.3

      -

      Maximum output memory Sets the maximum amount of memory, in kilobytes, a GetCoverage request might use, at most, to host the resulting raster. The memory is computed as ow * oh * pixelsize, where ow and oh are the size of the raster to be generated in output. 2.0.3

      -

      Max number of dimension values Sets the maximum number of dimension (time, at least for now) values that a client can request in a GetCoverage request (the work to be done is usually proportional to said number of times, and the list of values is kept in memory during the processing) 2.14.0

      -
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      OptionDescriptionVersion
      Maximum input memorySets the maximum amount of memory, in kilobytes, a GetCovearge request might use, at most, to read a coverage from the data source. The memory is computed as rw * rh * pixelsize, where rw and rh are the size of the raster to be read and pixelsize is the dimension or a pixel (e.g., a RGBA image will have 32bit pixels, a batimetry might have 16bit signed int ones)2.0.3
      Maximum output memorySets the maximum amount of memory, in kilobytes, a GetCoverage request might use, at most, to host the resulting raster. The memory is computed as ow * oh * pixelsize, where ow and oh are the size of the raster to be generated in output.2.0.3
      Max number of dimension valuesSets the maximum number of dimension (time, at least for now) values that a client can request in a GetCoverage request (the work to be done is usually proportional to said number of times, and the list of values is kept in memory during the processing)2.14.0

      To understand the limits let's consider a very simplified example in which no tiles and overviews enter the game:

      • The request hits a certain area of the original raster. Reading it at full resolution requires grabbing a raster of size rw * rh, which has a certain number of bands, each with a certain size. The amount of memory used for the read will be rw * rh * pixelsize. This is the value measured by the input memory limit
      • diff --git a/services/wcs/reference/index.html b/services/wcs/reference/index.html index 726bbe2dbec..5145098b771 100644 --- a/services/wcs/reference/index.html +++ b/services/wcs/reference/index.html @@ -2072,12 +2072,32 @@

        Benefits of WCS

        WCS provides a standard interface for how to request the raster source of a geospatial image. While a WMS can return an image it is generally only useful as an image. The results of a WCS can be used for complex modeling and analysis, as it often contains more information. It also allows more complex querying - clients can extract just the portion of the coverage that they need.

        Operations

        WCS can perform the following operations:

        -
        -

        Operation Description

        -

        GetCapabilities Retrieves a list of the server's data, as well as valid WCS operations and parameters

        -

        DescribeCoverage Retrieves an XML document that fully describes the request coverages.

        -

        GetCoverage Returns a coverage in a well-known format. Like a WMS GetMap request, but with several extensions to support the retrieval of coverages.

        -
        + + + + + + + + + + + + + + + + + + + + + + + + + +
        OperationDescription
        GetCapabilitiesRetrieves a list of the server's data, as well as valid WCS operations and parameters
        DescribeCoverageRetrieves an XML document that fully describes the request coverages.
        GetCoverageReturns a coverage in a well-known format. Like a WMS GetMap request, but with several extensions to support the retrieval of coverages.

        Note

        The following examples show the 1.1 protocol, the full specification for versions 1.0, 1.1 and 2.0 are available on the OGC website

        diff --git a/services/wfs/axis_order/index.html b/services/wfs/axis_order/index.html index 3a4315144e1..5652e8c37d8 100644 --- a/services/wfs/axis_order/index.html +++ b/services/wfs/axis_order/index.html @@ -2227,14 +2227,37 @@

        Axis ordering

        Some spatial reference systems, for example polar stereographic, do not have an east or west as they have a pole in the middle of the axis.

        These differences may cause difficulties when clients switch between different WFS versions. To minimize confusion and increase interoperability, GeoServer has adopted the following guidelines when specifying spatial reference systems to avoid ambiguity.

        -
        -

        Representation Axis order Interpretation

        -
        -

        EPSG:4326 longitude/latitude assumption

        -

        http://www.opengis.net/gml/srs/epsg.xml#xxxx longitude/latitude strict

        -

        urn:x-ogc:def:crs:EPSG:xxxx latitude/longitude strict

        -

        urn:ogc:def:crs:EPSG::4326 latitude/longitude strict

        -
        + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
        RepresentationAxis orderInterpretation
        EPSG:4326longitude/latitudeassumption
        http://www.opengis.net/gml/srs/epsg.xml#xxxxlongitude/latitudestrict
        urn:x-ogc:def:crs:EPSG:xxxxlatitude/longitudestrict
        urn:ogc:def:crs:EPSG::4326latitude/longitudestrict

        SRSList Axis Order

        To compare the spatial reference system definition for EPSG:4326:

          diff --git a/services/wfs/outputformats/index.html b/services/wfs/outputformats/index.html index ad52ab205f2..8c8a545e8ad 100644 --- a/services/wfs/outputformats/index.html +++ b/services/wfs/outputformats/index.html @@ -2033,16 +2033,47 @@

          WFS output formats

          outputFormat=<format>
           

          where <format> is one of the following options:

          -
          -

          Format Syntax Notes

          -
          -

          GML2 outputFormat=GML2 Default option for WFS 1.0.0

          -

          GML3 outputFormat=GML3 Default option for WFS 1.1.0 and 2.0.0

          -

          Shapefile outputFormat=shape-zip ZIP archive will be generated containing the shapefile (see Shapefile output below).

          -

          JSON outputFormat=application/json Returns a GeoJSON or a JSON output. Note outputFormat=json is only supported for getFeature (for backward compatibility).

          -

          JSONP outputFormat=text/javascript Returns a JSONP in the form: parseResponse(...json...). See WMS vendor parameters to change the callback name. Note that this format is disabled by default (See Global variables affecting WMS).

          -

          CSV outputFormat=csv Returns a CSV (comma-separated values) file

          -
          + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
          FormatSyntaxNotes
          GML2outputFormat=GML2Default option for WFS 1.0.0
          GML3outputFormat=GML3Default option for WFS 1.1.0 and 2.0.0
          ShapefileoutputFormat=shape-zipZIP archive will be generated containing the shapefile (see Shapefile output below).
          JSONoutputFormat=application/jsonReturns a GeoJSON or a JSON output. Note outputFormat=json is only supported for getFeature (for backward compatibility).
          JSONPoutputFormat=text/javascriptReturns a JSONP in the form: parseResponse(...json...). See WMS vendor parameters to change the callback name. Note that this format is disabled by default (See Global variables affecting WMS).
          CSVoutputFormat=csvReturns a CSV (comma-separated values) file

          Note

          Some additional output formats (such as Excel) are available with the use of an extension. The full list of output formats supported by a particular GeoServer instance can be found by performing a WFS GetCapabilities request.

          diff --git a/services/wfs/reference/index.html b/services/wfs/reference/index.html index 1547ab3d12a..b0b4b12f051 100644 --- a/services/wfs/reference/index.html +++ b/services/wfs/reference/index.html @@ -2234,32 +2234,86 @@

          Benefits of WFS

          The WFS standard defines the framework for providing access to, and supporting transactions on, discrete geographic features in a manner that is independent of the underlying data source. Through a combination of discovery, query, locking, and transaction operations, users have access to the source spatial and attribute data in a manner that allows them to interrogate, style, edit (create, update, and delete), and download individual features. The transactional capabilities of WFS also support the development and deployment of collaborative mapping applications.

          Operations

          All versions of WFS support these operations:

          -
          -

          Operation Description

          -
          -

          GetCapabilities Generates a metadata document describing a WFS service provided by server as well as valid WFS operations and parameters

          -

          DescribeFeatureType Returns a description of feature types supported by a WFS service

          -

          GetFeature Returns a selection of features from a data source including geometry and attribute values

          -

          LockFeature Prevents a feature from being edited through a persistent feature lock

          -

          Transaction Edits existing feature types by creating, updating, and deleting

          -
          + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
          OperationDescription
          GetCapabilitiesGenerates a metadata document describing a WFS service provided by server as well as valid WFS operations and parameters
          DescribeFeatureTypeReturns a description of feature types supported by a WFS service
          GetFeatureReturns a selection of features from a data source including geometry and attribute values
          LockFeaturePrevents a feature from being edited through a persistent feature lock
          TransactionEdits existing feature types by creating, updating, and deleting

          The following operations are available in version 2.0.0 only:

          -
          -

          Operation Description

          -
          -

          GetPropertyValue Retrieves the value of a feature property or part of the value of a complex feature property from the data store for a set of features identified using a query expression

          -

          GetFeatureWithLock Returns a selection of features and also applies a lock on those features

          -

          CreateStoredQuery Create a stored query on the WFS server

          -

          DropStoredQuery Deletes a stored query from the WFS server

          -

          ListStoredQueries Returns a list of the stored queries on a WFS server

          -

          DescribeStoredQueries Returns a metadata document describing the stored queries on a WFS server

          -
          + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
          OperationDescription
          GetPropertyValueRetrieves the value of a feature property or part of the value of a complex feature property from the data store for a set of features identified using a query expression
          GetFeatureWithLockReturns a selection of features and also applies a lock on those features
          CreateStoredQueryCreate a stored query on the WFS server
          DropStoredQueryDeletes a stored query from the WFS server
          ListStoredQueriesReturns a list of the stored queries on a WFS server
          DescribeStoredQueriesReturns a metadata document describing the stored queries on a WFS server

          The following operations are available in version 1.1.0 only:

          -
          -

          Operation Description

          -
          -

          GetGMLObject Retrieves features and elements by ID from a WFS

          -
          + + + + + + + + + + + + + +
          OperationDescription
          GetGMLObjectRetrieves features and elements by ID from a WFS

          Note

          In the examples that follow, the fictional URL http://example.com/geoserver/wfs is used for illustration. To test the examples, substitute the address of a valid WFS. Also, although the request would normally be defined on one line with no breaks, breaks are added for clarity in the examples provided.

          @@ -2282,37 +2336,108 @@

          GetCapabilities

    GET requests are simplest to decode, but the POST requests are equivalent.

    The parameters for GetCapabilities are:

    -
    -

    Parameter Required? Description

    -
    -

    service Yes Service name---Value is WFS

    -

    version Yes Service version---Value is the current version number. The full version number must be supplied ("1.1.0", "1.0.0"), not the abbreviated form ("1" or "1.1").

    -

    request Yes Operation name---Value is GetCapabilities

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + +
    ParameterRequired?Description
    serviceYesService name---Value is WFS
    versionYesService version---Value is the current version number. The full version number must be supplied ("1.1.0", "1.0.0"), not the abbreviated form ("1" or "1.1").
    requestYesOperation name---Value is GetCapabilities

    Although all of the above parameters are technically required as per the specification, GeoServer will provide default values if any parameters are omitted from a request.

    The GetCapabilities response is a lengthy XML document, the format of which is different for each of the supported versions. There are five main components in a GetCapabilities document:

    -
    -

    Component Description

    -
    -

    ServiceIdentification Contains basic header information for the request such as the Title and ServiceType. The ServiceType indicates which version(s) of WFS are supported.

    -

    ServiceProvider Provides contact information about the company publishing the WFS service, including telephone, website, and email.

    -

    OperationsMetadata Describes the operations that the WFS server supports and the parameters for each operation. A WFS server may be configured not to respond to the operations listed above.

    -

    FeatureTypeList Lists the feature types published by a WFS server. Feature types are listed in the form namespace:featuretype. The default projection of the feature type is also listed, along with the bounding box for the data in the stated projection.

    -

    Filter_Capabilities Lists the filters, or expressions, that are available to form query predicates, for example, SpatialOperators (such as Equals, Touches) and ComparisonOperators (such as LessThan, GreaterThan). The filters themselves are not included in the GetCapabilities document.

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ComponentDescription
    ServiceIdentificationContains basic header information for the request such as the Title and ServiceType. The ServiceType indicates which version(s) of WFS are supported.
    ServiceProviderProvides contact information about the company publishing the WFS service, including telephone, website, and email.
    OperationsMetadataDescribes the operations that the WFS server supports and the parameters for each operation. A WFS server may be configured not to respond to the operations listed above.
    FeatureTypeListLists the feature types published by a WFS server. Feature types are listed in the form namespace:featuretype. The default projection of the feature type is also listed, along with the bounding box for the data in the stated projection.
    Filter_CapabilitiesLists the filters, or expressions, that are available to form query predicates, for example, SpatialOperators (such as Equals, Touches) and ComparisonOperators (such as LessThan, GreaterThan). The filters themselves are not included in the GetCapabilities document.

    DescribeFeatureType

    DescribeFeatureType requests information about an individual feature type before requesting the actual data. Specifically, the operation will request a list of features and attributes for the given feature type, or list the feature types available.

    The parameters for DescribeFeatureType are:

    -
    -

    Parameter Required? Description

    -
    -

    service Yes Service name---Value is WFS

    -

    version Yes Service version---Value is the current version number

    -

    request Yes Operation name---Value is DescribeFeatureType

    -

    typeNames Yes Name of the feature type to describe (typeName for WFS 1.1.0 and earlier)

    -

    exceptions No Format for reporting exceptions---default value is application/vnd.ogc.se_xml

    -

    outputFormat No Defines the scheme description language used to describe feature types

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ParameterRequired?Description
    serviceYesService name---Value is WFS
    versionYesService version---Value is the current version number
    requestYesOperation name---Value is DescribeFeatureType
    typeNamesYesName of the feature type to describe (typeName for WFS 1.1.0 and earlier)
    exceptionsNoFormat for reporting exceptions---default value is application/vnd.ogc.se_xml
    outputFormatNoDefines the scheme description language used to describe feature types

    To return a list of feature types, the GET request would be as follows. This request will return the list of feature types, sorted by namespace:

    http://example.com/geoserver/wfs?
       service=wfs&
    @@ -2562,13 +2687,32 @@ 

    DescribeStoredQueries

    Exceptions

    WFS also supports a number of formats for reporting exceptions. The supported values for exception reporting are:

    -
    -

    Format Syntax Description

    -
    -

    XML exceptions=text/xml (default) XML output

    -

    JSON exceptions=application/json Simple JSON

    -

    JSONP exceptions=text/javascript Return a JSONP in the form: parseResponse(...jsonp...). See WMS vendor parameters to change the callback name. Note that this format is disabled by default (See Global variables affecting WMS).

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + +
    FormatSyntaxDescription
    XMLexceptions=text/xml(default) XML output
    JSONexceptions=application/jsonSimple JSON
    JSONPexceptions=text/javascriptReturn a JSONP in the form: parseResponse(...jsonp...). See WMS vendor parameters to change the callback name. Note that this format is disabled by default (See Global variables affecting WMS).
    diff --git a/services/wfs/webadmin/index.html b/services/wfs/webadmin/index.html index accb41e9b5c..5dbd90d4999 100644 --- a/services/wfs/webadmin/index.html +++ b/services/wfs/webadmin/index.html @@ -2259,14 +2259,32 @@

    CSV

    WFS configuration options - CSV section

    CSV is still widely used as a format to exchange tabular data. For GeoServer CSV output format, the date field format can specified using the Date Format text box as shown above. Here are some common formatting patterns supported

    -
    -

    Date and Time Pattern Result

    -
    -

    yyyy.MM.dd G 'at' HH:mm:ss z 2001.07.04 AD at 12:08:56 PDT

    -

    EEE, MMM d, ''yy Wed, Jul 4, '01

    -

    yyyy-MM-dd'T'HH:mm:ss.SSSZ 2001-07-04T12:08:56.235-0700

    -

    yyyy-MM-dd'T'HH:mm:ss.SSSXXX 2001-07-04T12:08:56.235-07:00

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + +
    Date and Time PatternResult
    yyyy.MM.dd G 'at' HH:mm:ss z2001.07.04 AD at 12:08:56 PDT
    EEE, MMM d, ''yyWed, Jul 4, '01
    yyyy-MM-dd'T'HH:mm:ss.SSSZ2001-07-04T12:08:56.235-0700
    yyyy-MM-dd'T'HH:mm:ss.SSSXXX2001-07-04T12:08:56.235-07:00

    Here, yyyy-MM-dd'T'HH🇲🇲ss.SSS'Z' pattern represents the year, month, day, hour, minute, second and milliseconds. The components are separated by a hyphen character. A literal 'T' character is used to separate the date and time parts. A literal 'Z' character represents the UTC time zone. For instance, yyyy represents the year with four digits, MM represents the month with leading zeros, dd represents the day with leading zeros, and so on.

    Similarly, patterns can be formed by using the characters provided below

    y- Year (four digits) 
    diff --git a/services/wms/configuration/index.html b/services/wms/configuration/index.html
    index 8365b1cc18f..f26f25fd3f8 100644
    --- a/services/wms/configuration/index.html
    +++ b/services/wms/configuration/index.html
    @@ -2148,28 +2148,96 @@ 

    Layer Groups

    Request limits

    The request limit options allow the administrator to limit the resources consumed by each WMS GetMap request.

    The following table shows the option names, a description, and the minimum GeoServer version at which the option is available (older versions will ignore it if set).

    -
    -

    Option Description Version

    -

    Max rendering memory (KB) Sets the maximum amount of memory a single GetMap request is allowed to use (in kilobytes). The limit is checked before request execution by estimating how much memory would be required to produce the output in the format requested. For example, for an image format the estimate is based on the size of the required rendering memory (which is determined by the image size, the pixel bit depth, and the number of active FeatureTypeStyles at the requested scale). If the estimated memory size is below the limit, the request is executed; otherwise it is cancelled. 1.7.5

    -

    Max rendering time (s) Sets the maximum amount of time GeoServer will spend processing a request (in seconds). This time limits the "blind processing" portion of the request, that is, the time taken to read data and compute the output result (which may occur concurrently). If the execution time reaches the limit, the request is cancelled. The time required to write results back to the client is not limited by this parameter, since this is determined by the (unknown) network latency between the server and the client. For example, in the case of PNG/JPEG image generation, this option limits the data reading and rendering time, but not the time taken to write the image out. 1.7.5

    -

    Max rendering errors (count) Sets the maximum amount of rendering errors tolerated by a GetMap request. By default GetMap makes a best-effort attempt to serve the result, ignoring invalid features, reprojection errors and the like. Setting a limit on the number of errors ignored can make it easier to notice issues, and conserves CPU cycles by reducing the errors which must be handled and logged 1.7.5

    -

    Max number of dimension values Sets the maximum number of dimension (time, elevation, custom) values that a client can request in a GetMap/GetFeatureInfo request (the work to be done is usually proportional to said number of times, and the list of values is kept in memory during the processing) 2.14.0

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    OptionDescriptionVersion
    Max rendering memory (KB)Sets the maximum amount of memory a single GetMap request is allowed to use (in kilobytes). The limit is checked before request execution by estimating how much memory would be required to produce the output in the format requested. For example, for an image format the estimate is based on the size of the required rendering memory (which is determined by the image size, the pixel bit depth, and the number of active FeatureTypeStyles at the requested scale). If the estimated memory size is below the limit, the request is executed; otherwise it is cancelled.1.7.5
    Max rendering time (s)Sets the maximum amount of time GeoServer will spend processing a request (in seconds). This time limits the "blind processing" portion of the request, that is, the time taken to read data and compute the output result (which may occur concurrently). If the execution time reaches the limit, the request is cancelled. The time required to write results back to the client is not limited by this parameter, since this is determined by the (unknown) network latency between the server and the client. For example, in the case of PNG/JPEG image generation, this option limits the data reading and rendering time, but not the time taken to write the image out.1.7.5
    Max rendering errors (count)Sets the maximum amount of rendering errors tolerated by a GetMap request. By default GetMap makes a best-effort attempt to serve the result, ignoring invalid features, reprojection errors and the like. Setting a limit on the number of errors ignored can make it easier to notice issues, and conserves CPU cycles by reducing the errors which must be handled and logged1.7.5
    Max number of dimension valuesSets the maximum number of dimension (time, elevation, custom) values that a client can request in a GetMap/GetFeatureInfo request (the work to be done is usually proportional to said number of times, and the list of values is kept in memory during the processing)2.14.0

    The default value of each limit is 0, which specifies that the limit is not applied.

    If any of the request limits is exceeded, the GetMap operation is cancelled and a ServiceException is returned to the client.

    When setting the above limits it is suggested that peak conditions be taken into consideration. For example, under normal circumstances a GetMap request may take less than a second. Under high load it is acceptable for it to take longer, but it's usually not desirable to allow a request to go on for 30 minutes.

    The following table shows examples of reasonable values for the request limits:

    -
    -

    Option Value Rationale

    -

    maxRequestMemory 16384 16MB are sufficient to render a 2048x2048 image at 4 bytes per pixel (full color and transparency), or a 8x8 meta-tile when using GeoWebCache or TileCache. Note that the rendering process uses a separate memory buffer for each FeatureTypeStyle in an SLD, so this also affects the maximum image size. For example, if an SLD contains two FeatureTypeStyle elements in order to draw cased lines for a highway, the maximum image size will be limited to 1448x1448 (the memory requirement increases with the product of the image dimensions, so halving the memory decreases image dimensions by only about 30%)

    -

    maxRenderingTime 120 A request that processes for a full two minutes is probably rendering too many features, regardless of the current server load. This may be caused by a request against a big layer using a style that does not have suitable scale dependencies

    -

    maxRenderingErrors 100 Encountering 100 errors is probably the result of a request trying to reproject a big data set into a projection that is not appropriate for the output extent, resulting in many reprojection failures.

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    OptionValueRationale
    maxRequestMemory1638416MB are sufficient to render a 2048x2048 image at 4 bytes per pixel (full color and transparency), or a 8x8 meta-tile when using GeoWebCache or TileCache. Note that the rendering process uses a separate memory buffer for each FeatureTypeStyle in an SLD, so this also affects the maximum image size. For example, if an SLD contains two FeatureTypeStyle elements in order to draw cased lines for a highway, the maximum image size will be limited to 1448x1448 (the memory requirement increases with the product of the image dimensions, so halving the memory decreases image dimensions by only about 30%)
    maxRenderingTime120A request that processes for a full two minutes is probably rendering too many features, regardless of the current server load. This may be caused by a request against a big layer using a style that does not have suitable scale dependencies
    maxRenderingErrors100Encountering 100 errors is probably the result of a request trying to reproject a big data set into a projection that is not appropriate for the output extent, resulting in many reprojection failures.

    LayerGroup Capabilities Settings

    -
    -

    Option Description

    -

    Default LayerGroup Style In GetCapabilities Enable/disable the encoding of the default LayerGroup style in GetCapabilties responses for LayerGroup with mode Named Tree, Container Tree, Earth Observation Tree. Single and Opaque groups are not affected by the option and will always show the default style. By default the option is set to enabled.

    -
    + + + + + + + + + + + + + + + + + +
    OptionDescription
    Default LayerGroup Style In GetCapabilitiesEnable/disable the encoding of the default LayerGroup style in GetCapabilties responses for LayerGroup with mode Named Tree, Container Tree, Earth Observation Tree. Single and Opaque groups are not affected by the option and will always show the default style. By default the option is set to enabled.
    diff --git a/services/wms/decoration/index.html b/services/wms/decoration/index.html index 0851ee36be7..2e2682644be 100644 --- a/services/wms/decoration/index.html +++ b/services/wms/decoration/index.html @@ -2165,14 +2165,32 @@

    Configuration

    To use decorations in a GetMap request, the administrator must first configure a decoration layout. These layouts are stored in a subdirectory called layouts in the GeoServer data directory as XML files, one file per layout. Each layout file must have the extension .xml. Once a layout foo.xml is defined, users can request it by adding &format_options=layout:foo to the request parameters.

    Layout files follow a very simple XML structure; a root node named layout containing any number of decoration elements. The order of the decoration elements is the order they are drawn so, in case they are overlapping, the first one will appear under the others.

    Each decoration element has several attributes:

    -
    -

    Attribute Meaning

    -
    -

    type the type of decoration to use (see Decoration Types)

    -

    affinity the region of the map image to which the decoration is anchored

    -

    offset how far from the anchor point the decoration is drawn

    -

    size the maximum size to render the decoration. Note that some decorations may dynamically resize themselves.

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + +
    AttributeMeaning
    typethe type of decoration to use (see Decoration Types)
    affinitythe region of the map image to which the decoration is anchored
    offsethow far from the anchor point the decoration is drawn
    sizethe maximum size to render the decoration. Note that some decorations may dynamically resize themselves.

    Each decoration element may also contain an arbitrary number of option elements providing a parameter name and value:

    <option name="foo" value="bar"/>
     
    @@ -2180,51 +2198,144 @@

    Configuration

    Decoration Types

    While GeoServer allows for decorations to be added via extension, there is a core set of decorations included in the default installation. These decorations include:

    The image decoration (type="image") overlays a static image file onto the document. If height and width are specified, the image will be scaled to fit, otherwise the image is displayed at full size.

    -
    -

    Option Name Meaning

    -
    -

    url provides the URL or file path to the image to draw (relative to the GeoServer data directory)

    -

    opacity a number from 0 to 100 indicating how opaque the image should be.

    -
    + + + + + + + + + + + + + + + + + +
    Option NameMeaning
    urlprovides the URL or file path to the image to draw (relative to the GeoServer data directory)
    opacitya number from 0 to 100 indicating how opaque the image should be.

    The scaleratio decoration (type="scaleratio") overlays a text description of the map's scale ratio onto the document.

    -
    -

    Option Name Meaning

    -
    -

    bgcolor the background color for the text. supports RGB or RGBA colors specified as hex values.

    -

    fgcolor the color for the text and border. follows the color specification from bgcolor.

    -

    format the number format pattern, specified using Java own DecimalFormat syntax

    -

    formatLanguage the language used to drive number formatting (applies only if also format is used), using a valid Java Locale

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + +
    Option NameMeaning
    bgcolorthe background color for the text. supports RGB or RGBA colors specified as hex values.
    fgcolorthe color for the text and border. follows the color specification from bgcolor.
    formatthe number format pattern, specified using Java own DecimalFormat syntax
    formatLanguagethe language used to drive number formatting (applies only if also format is used), using a valid Java Locale

    The scaleline decoration (type="scaleline") overlays a graphic showing the scale of the map in world units.

    -
    -

    Option Name Meaning

    -
    -

    bgcolor the background color, as used in scaleratio

    -

    fgcolor the foreground color, as used in scaleratio

    -

    fontsize the size of the font to use

    -

    transparent if set to true, the background and border won't be painted (false by default)

    -

    measurement-system can be set to "metric" to only show metric units, "imperial" to only show imperial units, or "both" to show both of them (default)

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Option NameMeaning
    bgcolorthe background color, as used in scaleratio
    fgcolorthe foreground color, as used in scaleratio
    fontsizethe size of the font to use
    transparentif set to true, the background and border won't be painted (false by default)
    measurement-systemcan be set to "metric" to only show metric units, "imperial" to only show imperial units, or "both" to show both of them (default)

    The legend decoration (type="legend") overlays a graphic containing legends for the layers in the map.

    -
    -

    Option Name Meaning

    -
    -

    legend_options the list of legend_options used as in GetLegendGraphic

    -

    opacity the legend opacity with a value between 0 and 1

    -
    + + + + + + + + + + + + + + + + + +
    Option NameMeaning
    legend_optionsthe list of legend_options used as in GetLegendGraphic
    opacitythe legend opacity with a value between 0 and 1

    The text decoration (type="text") overlays a parametric, single line text message on top of the map. The parameter values can be fed via the env request parameter, just like SLD environment parameters.

    -
    -

    Option Name Meaning

    -
    -

    message the message to be displayed, as plain text or Freemarker template that can use the env map contents to expand variables

    -

    font-family the name of the font used to display the message, e.g., Arial, defaults to Serif

    -

    font-size the size of the font to use (can have decimals), defaults to 12

    -

    font-italic it true the font will be italic, defaults to false

    -

    font-bold if true the font will be bold, defaults to false

    -

    font-color the color of the message, in #RRGGBB or #RRGGBBAA format, defaults to black

    -

    halo-radius the radius of a halo around the message, can have decimals, defaults to 0

    -

    halo-color the halo fill color, in #RRGGBB or #RRGGBBAA format, defaults to white

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Option NameMeaning
    messagethe message to be displayed, as plain text or Freemarker template that can use the env map contents to expand variables
    font-familythe name of the font used to display the message, e.g., Arial, defaults to Serif
    font-sizethe size of the font to use (can have decimals), defaults to 12
    font-italicit true the font will be italic, defaults to false
    font-boldif true the font will be bold, defaults to false
    font-colorthe color of the message, in #RRGGBB or #RRGGBBAA format, defaults to black
    halo-radiusthe radius of a halo around the message, can have decimals, defaults to 0
    halo-colorthe halo fill color, in #RRGGBB or #RRGGBBAA format, defaults to white

    Example

    A layout configuration file might look like this:

    <layout>
    diff --git a/services/wms/get_legend_graphic/index.html b/services/wms/get_legend_graphic/index.html
    index 29d21364f2b..7eb9563b801 100644
    --- a/services/wms/get_legend_graphic/index.html
    +++ b/services/wms/get_legend_graphic/index.html
    @@ -2391,22 +2391,87 @@ 

    GetLegendGraphic

    Sample legend

    The following table lists the whole set of GetLegendGraphic parameters that can be used.

    -
    -

    Parameter Required Description

    -

    REQUEST Required Value must be "GetLegendGraphic".

    -

    LAYER Required Layer for which to produce legend graphic.

    -

    STYLE Optional Style of layer for which to produce legend graphic. If not present, the default style is selected. The style may be any valid style available for a layer, including non-SLD internally-defined styles.

    -

    FEATURETYPE Optional Feature type for which to produce the legend graphic. This is not needed if the layer has only a single feature type.

    -

    RULE Optional Rule of style to produce legend graphic for, if applicable. In the case that a style has multiple rules but no specific rule is selected, then the map server is obligated to produce a graphic that is representative of all of the rules of the style.

    -

    SCALE Optional In the case that a RULE is not specified for a style, this parameter may assist the server in selecting a more appropriate representative graphic by eliminating internal rules that are out-of-scope. This value is a standardized scale denominator, defined in Section 10.2. Specifying the scale will also make the symbolizers using Unit Of Measure resize according to the specified scale.

    -

    SLD Optional This parameter specifies a reference to an external SLD document. It works in the same way as the SLD= parameter of the WMS GetMap operation.

    -

    SLD_BODY Optional This parameter allows an SLD document to be included directly in an HTTP-GET request. It works in the same way as the SLD_BODY= parameter of the WMS GetMap operation.

    -

    FORMAT Required This gives the MIME type of the file format in which to return the legend graphic. Allowed values are the same as for the FORMAT= parameter of the WMS GetMap request.

    -

    WIDTH Optional This gives a hint for the width of the returned graphic in pixels. Vector-graphics can use this value as a hint for the level of detail to include.

    -

    HEIGHT Optional This gives a hint for the height of the returned graphic in pixels.

    -

    EXCEPTIONS Optional This gives the MIME type of the format in which to return exceptions. Allowed values are the same as for the EXCEPTIONS= parameter of the WMS GetMap request.

    -

    LANGUAGE Optional Allows setting labels language for style titles and rules titles; needs a correctly localized SLD to work properly; if labels are not available in the requested language, the default text will be used; look at i18N in SLD for further details.

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ParameterRequiredDescription
    REQUESTRequiredValue must be "GetLegendGraphic".
    LAYERRequiredLayer for which to produce legend graphic.
    STYLEOptionalStyle of layer for which to produce legend graphic. If not present, the default style is selected. The style may be any valid style available for a layer, including non-SLD internally-defined styles.
    FEATURETYPEOptionalFeature type for which to produce the legend graphic. This is not needed if the layer has only a single feature type.
    RULEOptionalRule of style to produce legend graphic for, if applicable. In the case that a style has multiple rules but no specific rule is selected, then the map server is obligated to produce a graphic that is representative of all of the rules of the style.
    SCALEOptionalIn the case that a RULE is not specified for a style, this parameter may assist the server in selecting a more appropriate representative graphic by eliminating internal rules that are out-of-scope. This value is a standardized scale denominator, defined in Section 10.2. Specifying the scale will also make the symbolizers using Unit Of Measure resize according to the specified scale.
    SLDOptionalThis parameter specifies a reference to an external SLD document. It works in the same way as the SLD= parameter of the WMS GetMap operation.
    SLD_BODYOptionalThis parameter allows an SLD document to be included directly in an HTTP-GET request. It works in the same way as the SLD_BODY= parameter of the WMS GetMap operation.
    FORMATRequiredThis gives the MIME type of the file format in which to return the legend graphic. Allowed values are the same as for the FORMAT= parameter of the WMS GetMap request.
    WIDTHOptionalThis gives a hint for the width of the returned graphic in pixels. Vector-graphics can use this value as a hint for the level of detail to include.
    HEIGHTOptionalThis gives a hint for the height of the returned graphic in pixels.
    EXCEPTIONSOptionalThis gives the MIME type of the format in which to return exceptions. Allowed values are the same as for the EXCEPTIONS= parameter of the WMS GetMap request.
    LANGUAGEOptionalAllows setting labels language for style titles and rules titles; needs a correctly localized SLD to work properly; if labels are not available in the requested language, the default text will be used; look at i18N in SLD for further details.

    Controlling legend appearance with LEGEND_OPTIONS

    GeoServer allows finer control over the legend appearance via the vendor parameter LEGEND_OPTIONS. The general format of LEGEND_OPTIONS is the same as FORMAT_OPTIONS, that is:

    ...&LEGEND_OPTIONS=key1:v1;key2:v2;...;keyn:vn
    diff --git a/services/wms/googleearth/features/kmlreflector/index.html b/services/wms/googleearth/features/kmlreflector/index.html
    index 1490cf9239a..4259c4b300b 100644
    --- a/services/wms/googleearth/features/kmlreflector/index.html
    +++ b/services/wms/googleearth/features/kmlreflector/index.html
    @@ -2589,21 +2589,68 @@ 

    Using the KML reflector

    where GEOSERVER_URL is the URL of your GeoServer instance, and <layer> is the name of the featuretype to be served.

    The following table lists the default assumptions:

    -
    -

    Key Value

    -

    request GetMap

    -

    service wms

    -

    version 1.1.1

    -

    srs EPSG:4326

    -

    format application/vnd.google-earth.kml+xml

    -

    width 2048

    -

    height 2048

    -

    bbox <layer bounds>

    -

    kmattr true

    -

    kmplacemark false

    -

    kmscore 40

    -

    styles [default style for the featuretype]

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    KeyValue
    requestGetMap
    servicewms
    version1.1.1
    srsEPSG:4326
    formatapplication/vnd.google-earth.kml+xml
    width2048
    height2048
    bbox<layer bounds>
    kmattrtrue
    kmplacemarkfalse
    kmscore40
    styles[default style for the featuretype]

    Any of these defaults can be changed when specifying the request. For instance, to specify a particular style, one can append styles=population to the request:

    http://localhost:8080/geoserver/wms/kml?layers=topp:states&styles=population
     
    @@ -2616,24 +2663,67 @@

    Reflector modes

    mode=<mode>
     

    where <mode> is one of the three reflector modes. The details for each mode are as follows:

    -
    -

    Mode Description

    -

    refresh (default for all versions except 1.7.1 through 1.7.5) Returns dynamic KML that can be refreshed/updated by the Google Earth client. Data is refreshed and new data/imagery is downloaded when zooming/panning stops. This mode can return either vector or raster (placemark or overlay) The decision to return either vector or raster data is determined by the value of kmscore. Please see the section on KML Scoring for more information.

    -

    superoverlay (default for versions 1.7.1 through 1.7.5) Returns KML as a super-overlay. A super-overlay is a form of KML in which data is broken up into regions. Please see the section on KML Super-Overlays for more information.

    -

    download Returns KML which contains the entire data set. In the case of a vector layer, this will include a series of KML placemarks. With raster layers, this will include a single KML ground overlay. This is the only mode that doesn't dynamically request new data from the server, and thus is self-contained KML.

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + +
    ModeDescription
    refresh(default for all versions except 1.7.1 through 1.7.5) Returns dynamic KML that can be refreshed/updated by the Google Earth client. Data is refreshed and new data/imagery is downloaded when zooming/panning stops. This mode can return either vector or raster (placemark or overlay) The decision to return either vector or raster data is determined by the value of kmscore. Please see the section on KML Scoring for more information.
    superoverlay(default for versions 1.7.1 through 1.7.5) Returns KML as a super-overlay. A super-overlay is a form of KML in which data is broken up into regions. Please see the section on KML Super-Overlays for more information.
    downloadReturns KML which contains the entire data set. In the case of a vector layer, this will include a series of KML placemarks. With raster layers, this will include a single KML ground overlay. This is the only mode that doesn't dynamically request new data from the server, and thus is self-contained KML.

    More about the "superoverlay" mode

    When requesting KML using the superoverlay mode, there are four additional submodes available regarding how and when data is requested. These options are set by appending the following parameter to the KML reflector request:

    superoverlay_mode=<submode>
     

    where <submode> is one of the following options:

    -
    -

    Submode Description

    -

    auto (default) Always returns vector features if the original data is in vector form, and returns raster imagery if the original data is in raster form. This can sometimes be less than optimal if the geometry of the features are very complicated, which can slow down Google Earth.

    -

    raster Always returns raster imagery, regardless of the original data. This is almost always faster, but all vector information is lost in this view.

    -

    overview Displays either vector or raster data depending on the view. At higher zoom levels, raster imagery will be displayed, and at lower zoom levels, vector features will be displayed. The determination for when to switch between vector and raster is made by the regionation parameters set on the server. See the section on KML Regionation for more information.

    -

    hybrid Displays both raster and vector data at all times.

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    SubmodeDescription
    auto(default) Always returns vector features if the original data is in vector form, and returns raster imagery if the original data is in raster form. This can sometimes be less than optimal if the geometry of the features are very complicated, which can slow down Google Earth.
    rasterAlways returns raster imagery, regardless of the original data. This is almost always faster, but all vector information is lost in this view.
    overviewDisplays either vector or raster data depending on the view. At higher zoom levels, raster imagery will be displayed, and at lower zoom levels, vector features will be displayed. The determination for when to switch between vector and raster is made by the regionation parameters set on the server. See the section on KML Regionation for more information.
    hybridDisplays both raster and vector data at all times.
    diff --git a/services/wms/googleearth/features/kmlregionation/index.html b/services/wms/googleearth/features/kmlregionation/index.html index e83c35e1171..3f3e391f242 100644 --- a/services/wms/googleearth/features/kmlregionation/index.html +++ b/services/wms/googleearth/features/kmlregionation/index.html @@ -2582,14 +2582,40 @@

    Regionation Attributes

    The most important aspect of regionation is to decide how to determine which features show up more prominently than others. This can be done either by geometry, or by attribute. One should choose the option that best exemplifies the relative "importance" of the feature. When choosing to regionate by geometry, only the larger lines and polygons will be displayed at higher zoom levels, with smaller ones being displayed when zooming in. When regionating by an attribute, the higher value of this attribute will make those features show up at higher zoom levels. (Choosing an attribute with a non-numeric value will be ignored, and will instead default to regionation by geometry.)

    Regionation Strategies

    Regionation strategies sets how to determine which features should be shown at any given time or zoom level. There are five types of regionation strategies:

    -
    -

    Strategy Description

    -

    best_guess (default) The actual strategy is determined by the type of data being operated on. If the data consists of points, the random strategy is used. If the data consists of lines or polygons, the geometry strategy is used.

    -

    external-sorting Creates a temporary auxiliary database within GeoServer. It takes slightly extra time to build the index upon first request.

    -

    native-sorting Uses the default sorting algorithm of the backend where the data is hosted. It is faster than external-sorting, but will only work with PostGIS datastores.

    -

    geometry Externally sorts by length (if lines) or area (if polygons).

    -

    random Uses the existing order of the data and does not sort.

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    StrategyDescription
    best_guess(default) The actual strategy is determined by the type of data being operated on. If the data consists of points, the random strategy is used. If the data consists of lines or polygons, the geometry strategy is used.
    external-sortingCreates a temporary auxiliary database within GeoServer. It takes slightly extra time to build the index upon first request.
    native-sortingUses the default sorting algorithm of the backend where the data is hosted. It is faster than external-sorting, but will only work with PostGIS datastores.
    geometryExternally sorts by length (if lines) or area (if polygons).
    randomUses the existing order of the data and does not sort.

    In most cases, the best_guess strategy is sufficient.

    Setting Regionation Parameters

    Regionation strategies and attributes are featuretype-specific, and therefore are set in the Layers editing page of the Web administration interface. This can be navigated to by selecting 'Layers' on the left sidebar.

    diff --git a/services/wms/googleearth/features/kmlscoring/index.html b/services/wms/googleearth/features/kmlscoring/index.html index 8cd212ec10c..1a5347a4981 100644 --- a/services/wms/googleearth/features/kmlscoring/index.html +++ b/services/wms/googleearth/features/kmlscoring/index.html @@ -2557,20 +2557,64 @@

    The kmscore attribute

    maximum number of features = 10^(kmscore/15)
     

    The following table shows the values of this threshold for various values of the kmscore parameter:

    -
    -

    kmscore Maximum # of features

    -

    0 Force overlay/raster output

    -

    10 4

    -

    20 21

    -

    30 100

    -

    40 Approx. 450

    -

    50 (default) Approx. 2150

    -

    60 Approx. 10,000

    -

    70 Approx. 45,000

    -

    80 Approx. 200,000

    -

    90 Approx. 1,000,000

    -

    100 Force placemark/vector output

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    kmscoreMaximum # of features
    0Force overlay/raster output
    104
    2021
    30100
    40Approx. 450
    50(default) Approx. 2150
    60Approx. 10,000
    70Approx. 45,000
    80Approx. 200,000
    90Approx. 1,000,000
    100Force placemark/vector output

    The syntax for specifying kmscore is:

    kmscore=<value>
     
    diff --git a/services/wms/googleearth/tutorials/heights/heights/index.html b/services/wms/googleearth/tutorials/heights/heights/index.html index ae1d07a0aac..2ad5999d41b 100644 --- a/services/wms/googleearth/tutorials/heights/heights/index.html +++ b/services/wms/googleearth/tutorials/heights/heights/index.html @@ -2546,12 +2546,32 @@

    Step Four

    http://localhost:8080/geoserver/wms/reflect?layers=topp:states&format=application/vnd.google-earth.kml%2Bxml&format_options=extrude:false
     

    We also have a few options for how Google Earth interprets the height field. By default, the height is interpreted as relative to the ground, but we can also set the heights relative to sea level, or to be ignored (useful for reverting to the 'flat' look without erasing your template). This is controlled with a format option named altitudeMode, whose values are summarized below.

    -
    -

    altitudeMode Purpose

    -

    altitudeMode Interpret height as relative to ground level

    -

    absolute Interpret height as relative to sea level

    -

    clampToGround Ignore height entirely

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + +
    altitudeModePurpose
    altitudeModeInterpret height as relative to ground level
    absoluteInterpret height as relative to sea level
    clampToGroundIgnore height entirely
    diff --git a/services/wms/googleearth/tutorials/time/time/index.html b/services/wms/googleearth/tutorials/time/time/index.html index fe03ec1dbcb..de805660cb7 100644 --- a/services/wms/googleearth/tutorials/time/time/index.html +++ b/services/wms/googleearth/tutorials/time/time/index.html @@ -2555,12 +2555,32 @@

    Checking the Setup

    Setup

    Creating the Template

    Next we will create a template which allows us to specify the temporal aspects of the dataset. The schema of our dataset looks like:

    -
    -

    INET_P100n Number of internet users per 100 people

    -

    NAME Name of country

    -

    RPT_YEAR Year

    -

    Geometry Polygon representing the country

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + +
    INET_P100nNumber of internet users per 100 people
    NAMEName of country
    RPT_YEARYear
    GeometryPolygon representing the country

    The temporal attribute is RPT_YEAR and is the one that matters to us. Ok, time to create the template.

    1. In your text editor of choice, create a new text file called time.ftl.
    2. @@ -2602,23 +2622,75 @@

      Specifying a Date Format

      ${DATETIME_ATTRIBUTE_NAME.value?date("M?d%y")}
       

      So when must you specify the date format in this manner? The following table illustrates the date formats that GeoServer can understand. Note that the '-' character can be one of any of the following characters: '/' (forward slash), ' ' (space), '.' (period), ',' (comma)

      -
      -

      Date Format Example

      -

      yyyy-MM-dd 2007-06-20

      -

      yyyy-MMM-dd 2007-Jun-20

      -

      MM-dd-yyyy 06-20-2007

      -

      MMM-dd-yyyy Jun-20-2007

      -

      dd-MM-yyyy 20-06-2007

      -

      dd-MMM-yyyy 20-Jun-2007

      -
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      Date FormatExample
      yyyy-MM-dd2007-06-20
      yyyy-MMM-dd2007-Jun-20
      MM-dd-yyyy06-20-2007
      MMM-dd-yyyyJun-20-2007
      dd-MM-yyyy20-06-2007
      dd-MMM-yyyy20-Jun-2007

      The set of date time formats which GeoServer can be understand is formed by appending the timestamp formats hh:mm and hh:mm:ss to the entries in the above table:

      -
      -

      DateTime Format Example

      -

      yyyy-MM-dd hh:mm 2007-06-20 12:30

      -

      yyyy-MMM-dd hh:mm 2007-Jun-20 12:30

      -

      yyyy-MM-dd hh🇲🇲ss 2007-06-20 12:30:00

      -

      yyyy-MMM-dd hh🇲🇲ss 2007-Jun-20 12:30:00

      -
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      DateTime FormatExample
      yyyy-MM-dd hh:mm2007-06-20 12:30
      yyyy-MMM-dd hh:mm2007-Jun-20 12:30
      yyyy-MM-dd hh🇲🇲ss2007-06-20 12:30:00
      yyyy-MMM-dd hh🇲🇲ss2007-Jun-20 12:30:00

      Warning

      Setting the Timezone

      diff --git a/services/wms/nonstandardautonamespace/index.html b/services/wms/nonstandardautonamespace/index.html index 4d73a04e3d4..20d98df7dd1 100644 --- a/services/wms/nonstandardautonamespace/index.html +++ b/services/wms/nonstandardautonamespace/index.html @@ -2065,20 +2065,63 @@

      Non Standard AUTO Namespace

      in GeoServer 2.8.x the factor parameter in the AUTO namespace is ignored. The BBOX parameter to GetMap must therefore be specified in metres.

      The WMS standard provide projections with IDs in the range 42001 to 42005.

      -
      -

      ID Projection

      -

      42001 Universal Transverse Mercator

      -

      42002 Transverse Mercator

      -

      42003 Orthographic

      -

      42004 Equirectangular

      -

      42005 Mollweide (not supported in GeoServer 2.8.x)

      -
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      IDProjection
      42001Universal Transverse Mercator
      42002Transverse Mercator
      42003Orthographic
      42004Equirectangular
      42005Mollweide (not supported in GeoServer 2.8.x)

      GeoServer also supports some non-standard coordinate reference systems. These are

      -
      -

      ID Projection

      -

      97001 Gnomonic

      -

      97002 Stereographic

      -
      + + + + + + + + + + + + + + + + + + + + + +
      IDProjection
      97001Gnomonic
      97002Stereographic

      Note

      the auto stereographic projection uses a sphere. It does this by setting the semi minor axis to the same value as the semi major axis.

      diff --git a/services/wms/outputformats/index.html b/services/wms/outputformats/index.html index 1581e9aabcb..9123a87be8f 100644 --- a/services/wms/outputformats/index.html +++ b/services/wms/outputformats/index.html @@ -2058,28 +2058,117 @@

      WMS output formats

      Note

      The list of output formats supported by a GeoServer instance can be found by a WMS GetCapabilities request.

      -
      -

      Format Syntax Notes

      -

      PNG format=image/png Default

      -

      PNG8 format=image/png8 Same as PNG, but computes an optimal 256 color (8 bit) palette, so the image size is usually smaller

      -

      JPEG format=image/jpeg

      -

      JPEG-PNG format=image/vnd.jpeg-png A custom format that will decide dynamically, based on the image contents, if it's best to use a JPEG or PNG compression. The images are returned in JPEG format if fully opaque and not paletted. In order to use this format in a meaningful way the GetMap must include a "&transparent=TRUE" parameter, as without it GeoServer generates opaque images with the default/requested background color, making this format always return JPEG images (or always PNG, if they are paletted). When using the layer preview to test this format, remember to add "&transparent=TRUE" to the preview URL, as normally the preview generates non transparent images.

      -

      JPEG-PNG8 format=image/vnd.jpeg-png8 Same as JPEG-PNG, but generating a paletted output if the PNG format is chosen

      -

      GIF format=image/gif

      -

      TIFF format=image/tiff

      -

      TIFF8 format=image/tiff8 Same as TIFF, but computes an optimal 256 color (8 bit) palette, so the image size is usually smaller

      -

      GeoTIFF format=image/geotiff Same as TIFF, but includes extra GeoTIFF metadata

      -

      GeoTIFF8 format=image/geotiff8 Same as TIFF, but includes extra GeoTIFF metadata and computes an optimal 256 color (8 bit) palette, so the image size is usually smaller

      -

      SVG format=image/svg

      -

      PDF format=application/pdf

      -

      GeoRSS format=rss

      -

      KML format=kml

      -

      KMZ format=kmz

      -

      MapML format=text/mapml

      -

      MapML HTML Viewer text/html; subtype=mapml

      -

      OpenLayers format=application/openlayers Generates an OpenLayers HTML application.

      -

      UTFGrid format=application/json;type=utfgrid Generates an UTFGrid 1.3 JSON response. Requires vector output, either from a vector layer, or from a raster layer turned into vectors by a rendering transformation.

      -
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      FormatSyntaxNotes
      PNGformat=image/pngDefault
      PNG8format=image/png8Same as PNG, but computes an optimal 256 color (8 bit) palette, so the image size is usually smaller
      JPEGformat=image/jpeg
      JPEG-PNGformat=image/vnd.jpeg-pngA custom format that will decide dynamically, based on the image contents, if it's best to use a JPEG or PNG compression. The images are returned in JPEG format if fully opaque and not paletted. In order to use this format in a meaningful way the GetMap must include a "&transparent=TRUE" parameter, as without it GeoServer generates opaque images with the default/requested background color, making this format always return JPEG images (or always PNG, if they are paletted). When using the layer preview to test this format, remember to add "&transparent=TRUE" to the preview URL, as normally the preview generates non transparent images.
      JPEG-PNG8format=image/vnd.jpeg-png8Same as JPEG-PNG, but generating a paletted output if the PNG format is chosen
      GIFformat=image/gif
      TIFFformat=image/tiff
      TIFF8format=image/tiff8Same as TIFF, but computes an optimal 256 color (8 bit) palette, so the image size is usually smaller
      GeoTIFFformat=image/geotiffSame as TIFF, but includes extra GeoTIFF metadata
      GeoTIFF8format=image/geotiff8Same as TIFF, but includes extra GeoTIFF metadata and computes an optimal 256 color (8 bit) palette, so the image size is usually smaller
      SVGformat=image/svg
      PDFformat=application/pdf
      GeoRSSformat=rss
      KMLformat=kml
      KMZformat=kmz
      MapMLformat=text/mapml
      MapML HTML Viewertext/html; subtype=mapml
      OpenLayersformat=application/openlayersGenerates an OpenLayers HTML application.
      UTFGridformat=application/json;type=utfgridGenerates an UTFGrid 1.3 JSON response. Requires vector output, either from a vector layer, or from a raster layer turned into vectors by a rendering transformation.
      diff --git a/services/wms/reference/index.html b/services/wms/reference/index.html index db1e83e35ad..0f73a97e8b1 100644 --- a/services/wms/reference/index.html +++ b/services/wms/reference/index.html @@ -2307,30 +2307,106 @@

      Benefits of WMS

      WMS provides a standard interface for requesting a geospatial map image. The benefit of this is that WMS clients can request images from multiple WMS servers, and then combine them into a single view for the user. The standard guarantees that these images can all be overlaid on one another as they actually would be in reality. Numerous servers and clients support WMS.

      Operations

      WMS requests can perform the following operations:

      -
      -

      Operation Description

      -

      GetCapabilities Retrieves metadata about the service, including supported operations and parameters, and a list of the available layers

      -

      GetMap Retrieves a map image for a specified area and content

      -

      GetFeatureInfo Retrieves the underlying data, including geometry and attribute values, for a pixel location on a map

      -

      DescribeLayer Indicates the WFS or WCS to retrieve additional information about the layer.

      -

      GetLegendGraphic Retrieves a generated legend for a map

      -
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      OperationDescription
      GetCapabilitiesRetrieves metadata about the service, including supported operations and parameters, and a list of the available layers
      GetMapRetrieves a map image for a specified area and content
      GetFeatureInfoRetrieves the underlying data, including geometry and attribute values, for a pixel location on a map
      DescribeLayerIndicates the WFS or WCS to retrieve additional information about the layer.
      GetLegendGraphicRetrieves a generated legend for a map

      GetCapabilities

      The GetCapabilities operation requests metadata about the operations, services, and data ("capabilities") that are offered by a WMS server.

      The parameters for the GetCapabilities operation are:

      -
      -

      Parameter Required? Description

      -

      service Yes Service name. Value is WMS.

      -

      version Yes Service version. Value is one of 1.0.0, 1.1.0, 1.1.1, 1.3.0.

      -

      request Yes Operation name. Value is GetCapabilities.

      -
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      ParameterRequired?Description
      serviceYesService name. Value is WMS.
      versionYesService version. Value is one of 1.0.0, 1.1.0, 1.1.1, 1.3.0.
      requestYesOperation name. Value is GetCapabilities.

      GeoServer provides the following vendor-specific parameters for the GetCapabilities operation. They are fully documented in the WMS vendor parameters section.

      -
      -

      Parameter Required? Description

      -

      namespace No limits response to layers in a given namespace

      -

      format No request the capabilities document in a certain format

      -

      rootLayer No Flag to enable/disable the standard Root top level Layer element. Values are true or false. When false, the Root element will be included only if there are multiple top level layers, if there is only one, it will be the root layer itself. When specified, will override the global WMS setting or layer / group setting for the same behaviour.

      -
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      ParameterRequired?Description
      namespaceNolimits response to layers in a given namespace
      formatNorequest the capabilities document in a certain format
      rootLayerNoFlag to enable/disable the standard Root top level Layer element. Values are true or false. When false, the Root element will be included only if there are multiple top level layers, if there is only one, it will be the root layer itself. When specified, will override the global WMS setting or layer / group setting for the same behaviour.

      A example GetCapabilities request is: :

      http://localhost:8080/geoserver/wms?
       service=wms&
      @@ -2339,34 +2415,128 @@ 

      GetCapabilities

      There are three parameters being passed to the WMS server, service=wms, version=1.1.1, and request=GetCapabilities. The service parameter tells the WMS server that a WMS request is forthcoming. The version parameter refers to which version of WMS is being requested. The request parameter specifies the GetCapabilities operation. The WMS standard requires that requests always includes these three parameters. GeoServer relaxes these requirements (by setting the default version if omitted), but for standard-compliance they should always be specified.

      The response is a Capabilities XML document that is a detailed description of the WMS service. It contains three main sections:

      -
      -

      Service Contains service metadata such as the service name, keywords, and contact information for the organization operating the server.

      -

      Request Describes the operations the WMS service provides and the parameters and output formats for each operation. If desired GeoServer can be configured to disable support for certain WMS operations.

      -

      Layer Lists the available coordinate systems and layers. In GeoServer layers are named in the form "namespace:layer". Each layer provides service metadata such as title, abstract and keywords.

      -
      + + + + + + + + + + + + + + + + + + + + + +
      ServiceContains service metadata such as the service name, keywords, and contact information for the organization operating the server.
      RequestDescribes the operations the WMS service provides and the parameters and output formats for each operation. If desired GeoServer can be configured to disable support for certain WMS operations.
      LayerLists the available coordinate systems and layers. In GeoServer layers are named in the form "namespace:layer". Each layer provides service metadata such as title, abstract and keywords.

      GetMap

      The GetMap operation requests that the server generate a map. The core parameters specify one or more layers and styles to appear on the map, a bounding box for the map extent, a target spatial reference system, and a width, height, and format for the output. The information needed to specify values for parameters such as layers, styles and srs can be obtained from the Capabilities document.

      The response is a map image, or other map output artifact, depending on the format requested. GeoServer provides a wide variety of output formats, described in WMS output formats.

      The standard parameters for the GetMap operation are:

      -
      -

      Parameter Required? Description

      -

      service Yes Service name. Value is WMS.

      -

      version Yes Service version. Value is one of 1.0.0, 1.1.0, 1.1.1, 1.3.0.

      -

      request Yes Operation name. Value is GetMap.

      -

      layers Yes Layers to display on map. Value is a comma-separated list of layer names.

      -

      styles Yes Styles in which layers are to be rendered. Value is a comma-separated list of style names, or empty if default styling is required. Style names may be empty in the list, to use default layer styling.

      -

      srs or crs Yes Spatial Reference System for map output. Value is in form EPSG:nnn. crs is the parameter key used in WMS 1.3.0.

      -

      bbox Yes Bounding box for map extent. Value is minx,miny,maxx,maxy in units of the SRS.

      -

      width Yes Width of map output, in pixels.

      -

      height Yes Height of map output, in pixels.

      -

      format Yes Format for the map output. See WMS output formats for supported values.

      -

      transparent No Whether the map background should be transparent. Values are true or false. Default is false

      -

      bgcolor No Background color for the map image. Value is in the form RRGGBB. Default is FFFFFF (white).

      -

      exceptions No Format in which to report exceptions. Default value is application/vnd.ogc.se_xml.

      -

      time No Time value or range for map data. See Time Support in GeoServer WMS for more information.

      -

      sld No A URL referencing a StyledLayerDescriptor XML file which controls or enhances map layers and styling

      -

      sld_body No A URL-encoded StyledLayerDescriptor XML document which controls or enhances map layers and styling

      -
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      ParameterRequired?Description
      serviceYesService name. Value is WMS.
      versionYesService version. Value is one of 1.0.0, 1.1.0, 1.1.1, 1.3.0.
      requestYesOperation name. Value is GetMap.
      layersYesLayers to display on map. Value is a comma-separated list of layer names.
      stylesYesStyles in which layers are to be rendered. Value is a comma-separated list of style names, or empty if default styling is required. Style names may be empty in the list, to use default layer styling.
      srs or crsYesSpatial Reference System for map output. Value is in form EPSG:nnn. crs is the parameter key used in WMS 1.3.0.
      bboxYesBounding box for map extent. Value is minx,miny,maxx,maxy in units of the SRS.
      widthYesWidth of map output, in pixels.
      heightYesHeight of map output, in pixels.
      formatYesFormat for the map output. See WMS output formats for supported values.
      transparentNoWhether the map background should be transparent. Values are true or false. Default is false
      bgcolorNoBackground color for the map image. Value is in the form RRGGBB. Default is FFFFFF (white).
      exceptionsNoFormat in which to report exceptions. Default value is application/vnd.ogc.se_xml.
      timeNoTime value or range for map data. See Time Support in GeoServer WMS for more information.
      sldNoA URL referencing a StyledLayerDescriptor XML file which controls or enhances map layers and styling
      sld_bodyNoA URL-encoded StyledLayerDescriptor XML document which controls or enhances map layers and styling

      GeoServer provides a number of useful vendor-specific parameters for the GetMap operation. These are documented in the WMS vendor parameters section.

      Example WMS request for topp:states layer to be output as a PNG map image in SRS EPGS:4326 and using default styling is: :

      http://localhost:8080/geoserver/wms?
      @@ -2410,44 +2580,187 @@ 

      GetFeatureInfo

      The GetFeatureInfo operation requests the spatial and attribute data for the features at a given location on a map. It is similar to the WFS GetFeature operation, but less flexible in both input and output. Since GeoServer provides a WFS service we recommend using it instead of GetFeatureInfo whenever possible.

      The one advantage of GetFeatureInfo is that the request uses an (x,y) pixel value from a returned WMS image. This is easier to use for a naive client that is not able to perform true geographic referencing.

      The standard parameters for the GetFeatureInfo operation are:

      -
      -

      Parameter Required? Description

      -

      service Yes Service name. Value is WMS.

      -

      version Yes Service version. Value is one of 1.0.0, 1.1.0, 1.1.1, 1.3.0.

      -

      request Yes Operation name. Value is GetFeatureInfo.

      -

      layers Yes See GetMap

      -

      styles Yes See GetMap

      -

      srs or crs Yes See GetMap

      -

      bbox Yes See GetMap

      -

      width Yes See GetMap

      -

      height Yes See GetMap

      -

      query_layers Yes Comma-separated list of one or more layers to query.

      -

      info_format No Format for the feature information response. See below for values.

      -

      feature_count No Maximum number of features to return. Default is 1.

      -

      x or i Yes X ordinate of query point on map, in pixels. 0 is left side. i is the parameter key used in WMS 1.3.0.

      -

      y or j Yes Y ordinate of query point on map, in pixels. 0 is the top. j is the parameter key used in WMS 1.3.0.

      -

      exceptions No Format in which to report exceptions. The default value is application/vnd.ogc.se_xml.

      -
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      ParameterRequired?Description
      serviceYesService name. Value is WMS.
      versionYesService version. Value is one of 1.0.0, 1.1.0, 1.1.1, 1.3.0.
      requestYesOperation name. Value is GetFeatureInfo.
      layersYesSee GetMap
      stylesYesSee GetMap
      srs or crsYesSee GetMap
      bboxYesSee GetMap
      widthYesSee GetMap
      heightYesSee GetMap
      query_layersYesComma-separated list of one or more layers to query.
      info_formatNoFormat for the feature information response. See below for values.
      feature_countNoMaximum number of features to return. Default is 1.
      x or iYesX ordinate of query point on map, in pixels. 0 is left side. i is the parameter key used in WMS 1.3.0.
      y or jYesY ordinate of query point on map, in pixels. 0 is the top. j is the parameter key used in WMS 1.3.0.
      exceptionsNoFormat in which to report exceptions. The default value is application/vnd.ogc.se_xml.

      Note: If you are sending a GetFeatureInfo request against a layergroup, all the layers in that layergroup must be set as "Queryable" to get a result (See WMS Settings on Layers page<data_webadmin_layers>)

      GeoServer supports a number of output formats for the GetFeatureInfo response. Server-styled HTML is the most commonly-used format. For maximum control and customisation the client should use GML3 and style the raw data itself. The supported formats are:

      -
      -

      Format Syntax Notes

      -

      TEXT info_format=text/plain Simple text output. (The default format)

      -

      GML 2 info_format=application/vnd.ogc.gml Works only for Simple Features (see app-schema.complex-features)

      -

      GML 3 info_format=application/vnd.ogc.gml/3.1.1 Works for both Simple and Complex Features (see app-schema.complex-features)

      -

      HTML info_format=text/html Uses HTML templates that are defined on the server. See HTML output format for information on how to template HTML output.

      -

      JSON info_format=application/json Simple JSON representation. See GeoJSON output format for information on how to template JSON output.

      -

      JSONP info_format=text/javascript Returns JSONP in the form: parseResponse(...json...). See WMS vendor parameters to change the callback name. Note that this format is disabled by default (See Global variables affecting WMS).

      -
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      FormatSyntaxNotes
      TEXTinfo_format=text/plainSimple text output. (The default format)
      GML 2info_format=application/vnd.ogc.gmlWorks only for Simple Features (see app-schema.complex-features)
      GML 3info_format=application/vnd.ogc.gml/3.1.1Works for both Simple and Complex Features (see app-schema.complex-features)
      HTMLinfo_format=text/htmlUses HTML templates that are defined on the server. See HTML output format for information on how to template HTML output.
      JSONinfo_format=application/jsonSimple JSON representation. See GeoJSON output format for information on how to template JSON output.
      JSONPinfo_format=text/javascriptReturns JSONP in the form: parseResponse(...json...). See WMS vendor parameters to change the callback name. Note that this format is disabled by default (See Global variables affecting WMS).

      GeoServer provides the following vendor-specific parameters for the GetFeatureInfo operation. They are fully documented in the WMS vendor parameters section.

      -
      -

      Parameter Required? Description

      -

      buffer No width of search radius around query point (in pixels).

      -

      cql_filter No Filter for returned data, in ECQL format

      -

      filter No Filter for returned data, in OGC Filter format

      -

      propertyName No Feature properties to be returned

      -

      exclude_nodata_result No When set to true, a NaN will be returned when the feature's queried pixel value is nodata.

      -
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      ParameterRequired?Description
      bufferNowidth of search radius around query point (in pixels).
      cql_filterNoFilter for returned data, in ECQL format
      filterNoFilter for returned data, in OGC Filter format
      propertyNameNoFeature properties to be returned
      exclude_nodata_resultNoWhen set to true, a NaN will be returned when the feature's queried pixel value is nodata.

      An example request for feature information from the topp:states layer in HTML format is: :

      http://localhost:8080/geoserver/wms?
       request=GetFeatureInfo
      @@ -2537,22 +2850,84 @@ 

      GetFeatureInfo

      DescribeLayer

      The DescribeLayer operation is used primarily by clients that understand SLD-based WMS. In order to make an SLD one needs to know the structure of the data. WMS and WFS both have operations to do this, so the DescribeLayer operation just routes the client to the appropriate service.

      The standard parameters for the DescribeLayer operation are:

      -
      -

      Parameter Required? Description

      -

      service Yes Service name. Value is WMS.

      -

      version Yes Service version. Value is 1.1.1.

      -

      request Yes Operation name. Value is DescribeLayer.

      -

      layers Yes See GetMap

      -

      exceptions No Format in which to report exceptions. The default value is application/vnd.ogc.se_xml.

      -
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      ParameterRequired?Description
      serviceYesService name. Value is WMS.
      versionYesService version. Value is 1.1.1.
      requestYesOperation name. Value is DescribeLayer.
      layersYesSee GetMap
      exceptionsNoFormat in which to report exceptions. The default value is application/vnd.ogc.se_xml.

      GeoServer supports a number of output formats for the DescribeLayer response. Server-styled HTML is the most commonly-used format. The supported formats are:

      -
      -

      Format Syntax Notes

      -

      TEXT output_format=text/xml Same as default.

      -

      GML 2 output_format=application/vnd.ogc.wms_xml The default format.

      -

      JSON output_format=application/json Simple JSON representation.

      -

      JSONP output_format=text/javascript Return JSONP in the form: paddingOutput(...jsonp...). See WMS vendor parameters to change the callback name. Note that this format is disabled by default (See Global variables affecting WMS).

      -
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      FormatSyntaxNotes
      TEXToutput_format=text/xmlSame as default.
      GML 2output_format=application/vnd.ogc.wms_xmlThe default format.
      JSONoutput_format=application/jsonSimple JSON representation.
      JSONPoutput_format=text/javascriptReturn JSONP in the form: paddingOutput(...jsonp...). See WMS vendor parameters to change the callback name. Note that this format is disabled by default (See Global variables affecting WMS).

      An example request in XML (default) format on a layer is: :

      http://localhost:8080/geoserver/topp/wms?service=WMS &version=1.1.1 &request=DescribeLayer &layers=topp:coverage

      @@ -2600,15 +2975,52 @@

      GetLegendGraphic

      The GetLegendGraphic operation provides a mechanism for generating legend graphics as images, beyond the LegendURL reference of WMS Capabilities. It generates a legend based on the style defined on the server, or alternatively based on a user-supplied SLD. For more information on this operation and the various options that GeoServer supports see GetLegendGraphic.

      Exceptions

      Formats in which WMS can report exceptions. The supported values for exceptions are:

      -
      -

      Format Syntax Notes

      -

      XML EXCEPTIONS=application/vnd.ogc.se_xml XML output. (The default format)

      -

      INIMAGE EXCEPTIONS=application/vnd.ogc.se_inimage Generates an image

      -

      BLANK EXCEPTIONS=application/vnd.ogc.se_blank Generates a blank image

      -

      PARTIALMAP EXCEPTIONS=application/vnd.gs.wms_partial This is a GeoServer vendor parameter and only applicable for GetMap requests. Returns everything that was rendered at the time the rendering process threw an exception. Can be used with the WMS Configuration Limits to return a partial image even if the request is terminated for exceeding one of these limits. It also works with the timeout vendor parameter.

      -

      JSON EXCEPTIONS=application/json Simple JSON representation.

      -

      JSONP EXCEPTIONS=text/javascript Return JSONP in the form: paddingOutput(...jsonp...). See WMS vendor parameters to change the callback name. Note that this format is disabled by default (See Global variables affecting WMS).

      -
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      FormatSyntaxNotes
      XMLEXCEPTIONS=application/vnd.ogc.se_xmlXML output. (The default format)
      INIMAGEEXCEPTIONS=application/vnd.ogc.se_inimageGenerates an image
      BLANKEXCEPTIONS=application/vnd.ogc.se_blankGenerates a blank image
      PARTIALMAPEXCEPTIONS=application/vnd.gs.wms_partialThis is a GeoServer vendor parameter and only applicable for GetMap requests. Returns everything that was rendered at the time the rendering process threw an exception. Can be used with the WMS Configuration Limits to return a partial image even if the request is terminated for exceeding one of these limits. It also works with the timeout vendor parameter.
      JSONEXCEPTIONS=application/jsonSimple JSON representation.
      JSONPEXCEPTIONS=text/javascriptReturn JSONP in the form: paddingOutput(...jsonp...). See WMS vendor parameters to change the callback name. Note that this format is disabled by default (See Global variables affecting WMS).
      diff --git a/services/wps/operations/index.html b/services/wps/operations/index.html index 2b594362ad0..895adddf25f 100644 --- a/services/wps/operations/index.html +++ b/services/wps/operations/index.html @@ -2208,14 +2208,40 @@

      WPS Operations

      The WPS 1.0.0 standard defines three operations for the discovery and execution of geospatial processes, and GeoServer extends these with two further vendor or pseudo-operations. The operations are:

      -
      -

      Operation Description

      -

      GetCapabilities Retrieves details of the service offering, including service metadata and metadata describing the available processes

      -

      DescribeProcess Retrieves a description of a WPS process available through the service

      -

      Execute A request to perform the process with specified input values and required output data items

      -

      Dismiss (vendor extension) Used to cancel the execution of a process

      -

      GetExecutions (vendor extension) Retrieves a list of the current Execution Statuses

      -
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      OperationDescription
      GetCapabilitiesRetrieves details of the service offering, including service metadata and metadata describing the available processes
      DescribeProcessRetrieves a description of a WPS process available through the service
      ExecuteA request to perform the process with specified input values and required output data items
      Dismiss (vendor extension)Used to cancel the execution of a process
      GetExecutions (vendor extension)Retrieves a list of the current Execution Statuses

      GetCapabilities

      The GetCapabilities operation requests details of the service offering, including service metadata and metadata describing the available processes. The response is an XML document called the capabilities document.

      The required parameters, as in all OGC GetCapabilities requests, are service=WPS, version=1.0.0 and request=GetCapabilities.

      diff --git a/services/wps/processes/gs/index.html b/services/wps/processes/gs/index.html index b6a25e91160..7e34d9313ab 100644 --- a/services/wps/processes/gs/index.html +++ b/services/wps/processes/gs/index.html @@ -2130,14 +2130,54 @@

      GeoServer processes

      Aggregation process

      The aggregation process is used to perform common aggregation functions (sum, average, count) on vector data. The available outputs formats for this process are text/xml and application/json.

      The process parameters are described in the table bellow:

      -
      -

      Parameter Description Mandatory Multiple

      -

      features Input feature collection. yes no

      -

      aggregationAttribute Attribute on which to perform aggregation. yes no

      -

      function An aggregate function to compute. Functions include Count, Average, Max, Median, Min, StdDev, and Sum. yes yes

      -

      singlePass If TRUE computes all aggregation values in a single pass. This will defeat DBMS-specific optimizations. If a group by attribute is provided this parameter will be ignored. yes no

      -

      groupByAttributes Group by attribute. no yes

      -
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      ParameterDescriptionMandatoryMultiple
      featuresInput feature collection.yesno
      aggregationAttributeAttribute on which to perform aggregation.yesno
      functionAn aggregate function to compute. Functions include Count, Average, Max, Median, Min, StdDev, and Sum.yesyes
      singlePassIf TRUE computes all aggregation values in a single pass. This will defeat DBMS-specific optimizations. If a group by attribute is provided this parameter will be ignored.yesno
      groupByAttributesGroup by attribute.noyes

      Follow some examples of the invocation of this process using GeoServer shipped topp:states layer.

      The examples can be tested with CURL:

      curl -u admin:geoserver -H 'Content-type: xml' -XPOST -d@'wps-request.xml' http://localhost:8080/geoserver/wps
      @@ -2221,10 +2261,33 @@ 

      Aggregate Example

      The value of AggregationResults attribute should be read in a tabular way. The group by attributes come first in the order they appear in GroupByAttributes attribute. After comes the result of the aggregation functions in the order they appear in the AggregationFunctions attribute. In this case there is no group by attributes so the result only contains a row with the aggregation functions results. This is very similar to the result of an SQL query.

      This result should be interpreted like this:

      -
      -

      Max Min Average Sum Count

      -

      29760021 453588 5038397.020408163 246881454 49

      -
      + + + + + + + + + + + + + + + + + + + + + + + + + + +
      MaxMinAverageSumCount
      297600214535885038397.02040816324688145449

      To obtain the result in the XML format the request wps:ResponseForm element needs to be changed to:

      <wps:ResponseForm>
         <wps:RawDataOutput mimeType="text/xml">
      @@ -2316,18 +2379,67 @@ 

      Aggregate GroupBy Example

      Since there is a group by attribute the result contains a row for each different value of the group by attribute. Very similar to the result of an SQL query. If there is more that one group by attribute (which is not the case) their values will be in the order they appear in the GroupByAttributes attribute.

      This result should be interpreted like this:

      -
      -

      Sub Region Average count

      -

      N Eng 2201157.1666666665 6

      -

      W N Cen 2522812.8571428573 7

      -

      Pacific 12489678 3

      -

      Mtn 1690408.25 8

      -

      E S Cen 3998821.25 4

      -

      S Atl 4837695.666666667 9

      -

      Mid Atl 12534095.333333334 3

      -

      E N Cen 8209477.2 5

      -

      W S Cen 6709575.75 4

      -
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      Sub RegionAveragecount
      N Eng2201157.16666666656
      W N Cen2522812.85714285737
      Pacific124896783
      Mtn1690408.258
      E S Cen3998821.254
      S Atl4837695.6666666679
      Mid Atl12534095.3333333343
      E N Cen8209477.25
      W S Cen6709575.754

      The result in XML format:

      <?xml version="1.0" encoding="UTF-8"?>
       <AggregationResults>
      diff --git a/sitemap.xml.gz b/sitemap.xml.gz
      index c4cffe98f7cbd775b293bbafc31e0f4a5b1a1b98..70c0b434f016c05d6906a3da20f98b3ef358d7c0 100644
      GIT binary patch
      delta 15
      Wcmcbid_$Q{zMF$%YtBZtOM(C_^#yVO
      
      delta 15
      Wcmcbid_$Q{zMF&NVaP_dOM(C`g$0HH
      
      diff --git a/styling/css/cookbook/index.html b/styling/css/cookbook/index.html
      index 66a18764b07..2179993cfda 100644
      --- a/styling/css/cookbook/index.html
      +++ b/styling/css/cookbook/index.html
      @@ -2146,14 +2146,32 @@ 

      CSS Cookbook

      The CSS Cookbook is a collection of CSS "recipes" for creating various types of map styles. Wherever possible, each example is designed to show off a single CSS feature so that code can be copied from the examples and adapted when creating CSS styles of your own. Most examples are shared with the SLD Cookbook, to make a comparison between the two syntaxes immediate.

      The CSS Cookbook is divided into four sections: the first three for each of the vector types (points, lines, and polygons) and the fourth section for rasters. Each example in every section contains a screen-shot showing actual GeoServer WMS output and the full CSS code for reference.

      Each section uses data created especially for the Cookbooks (both CSS and SLD), with shapefiles for vector data and GeoTIFFs for raster data. The projection for data is EPSG:4326. All files can be easily loaded into GeoServer in order to recreate the examples.

      -
      -

      Data type Shapefile

      -
      -

      Point sld_cookbook_point.zip

      -

      Line sld_cookbook_line.zip

      -

      Polygon sld_cookbook_polygon.zip

      -

      Raster sld_cookbook_raster.zip

      -
      + + + + + + + + + + + + + + + + + + + + + + + + + +
      Data typeShapefile
      Pointsld_cookbook_point.zip
      Linesld_cookbook_line.zip
      Polygonsld_cookbook_polygon.zip
      Rastersld_cookbook_raster.zip
      • Points
      • diff --git a/styling/css/cookbook/line/index.html b/styling/css/cookbook/line/index.html index 4fb8014bd6a..86cb79c5533 100644 --- a/styling/css/cookbook/line/index.html +++ b/styling/css/cookbook/line/index.html @@ -3070,34 +3070,147 @@

        Lines

        While lines can also seem to be simple shapes, having length but no width, there are many options and tricks for making lines display nicely.

        Example lines layer

        The lines layer used in the examples below contains road information for a fictional country. For reference, the attribute table for the points in this layer is included below.

        -
        -

        fid (Feature ID) name (Road name) type (Road class)

        -

        line.1 Latway highway

        -

        line.2 Crescent Avenue secondary

        -

        line.3 Forest Avenue secondary

        -

        line.4 Longway highway

        -

        line.5 Saxer Avenue secondary

        -

        line.6 Ridge Avenue secondary

        -

        line.7 Holly Lane local-road

        -

        line.8 Mulberry Street local-road

        -

        line.9 Nathan Lane local-road

        -

        line.10 Central Street local-road

        -

        line.11 Lois Lane local-road

        -

        line.12 Rocky Road local-road

        -

        line.13 Fleet Street local-road

        -

        line.14 Diane Court local-road

        -

        line.15 Cedar Trail local-road

        -

        line.16 Victory Road local-road

        -

        line.17 Highland Road local-road

        -

        line.18 Easy Street local-road

        -

        line.19 Hill Street local-road

        -

        line.20 Country Road local-road

        -

        line.21 Main Street local-road

        -

        line.22 Jani Lane local-road

        -

        line.23 Shinbone Alley local-road

        -

        line.24 State Street local-road

        -

        line.25 River Road local-road

        -
        + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
        fid (Feature ID)name (Road name)type (Road class)
        line.1Latwayhighway
        line.2Crescent Avenuesecondary
        line.3Forest Avenuesecondary
        line.4Longwayhighway
        line.5Saxer Avenuesecondary
        line.6Ridge Avenuesecondary
        line.7Holly Lanelocal-road
        line.8Mulberry Streetlocal-road
        line.9Nathan Lanelocal-road
        line.10Central Streetlocal-road
        line.11Lois Lanelocal-road
        line.12Rocky Roadlocal-road
        line.13Fleet Streetlocal-road
        line.14Diane Courtlocal-road
        line.15Cedar Traillocal-road
        line.16Victory Roadlocal-road
        line.17Highland Roadlocal-road
        line.18Easy Streetlocal-road
        line.19Hill Streetlocal-road
        line.20Country Roadlocal-road
        line.21Main Streetlocal-road
        line.22Jani Lanelocal-road
        line.23Shinbone Alleylocal-road
        line.24State Streetlocal-road
        line.25River Roadlocal-road

        Download the lines shapefile

        Simple line

        This example specifies lines be colored black with a thickness of 3 pixels.

        @@ -3328,12 +3441,42 @@

        Details

      There are three types of road classes in our fictional country, ranging from back roads to high-speed freeways: "highway", "secondary", and "local-road". In order to make sure the roads are rendered in the proper order of importance, a "z-index" attribute has been placed in each rule.

      The three rules are designed as follows:

      -
      -

      Rule order Rule name / type Color Size

      -

      1 local-road #009933 (green) 2

      -

      2 secondary #0055CC (blue) 3

      -

      3 highway #FF0000 (red) 6

      -
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      Rule orderRule name / typeColorSize
      1local-road#009933 (green)2
      2secondary#0055CC (blue)3
      3highway#FF0000 (red)6

      Lines 1-5 comprise the first rule, the filter matches all roads that the "type" attribute has a value of "local-road". If this condition is true for a particular line, the rule renders it dark green, 2 pixels wide. All these lines are rendered first, and thus sit at the bottom of the final map.

      Lines 7-11 match the "secondary" roads, painting them dark blue, 3 pixels wide. Given the "z-index" is 1, they are rendered after the local roads, but below the highways.

      Lines 13-17 match the "highway" roads, painting them red 6 pixels wide. These roads are pained last, thus, on top of all others.

      @@ -3369,12 +3512,42 @@

      Details

      Determining the appropriate scale denominators (zoom levels) to use is beyond the scope of this example.

      This style contains three rules. The three rules are designed as follows:

      -
      -

      Rule order Rule name Scale denominator Line width

      -

      1 Large 1:180,000,000 or less 6

      -

      2 Medium 1:180,000,000 to 1:360,000,000 4

      -

      3 Small Greater than 1:360,000,000 2

      -
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      Rule orderRule nameScale denominatorLine width
      1Large1:180,000,000 or less6
      2Medium1:180,000,000 to 1:360,000,0004
      3SmallGreater than 1:360,000,0002

      The order of these rules does not matter since the scales denominated in each rule do not overlap.

      The first rule provides the stroke color used at all zoom levels, dark gray, while the other three rules cascade over it applying the different stroke widths based on the current zoom level leveraging the "@sd" pseudo attribute. The "@sd" pseudo attribute can only be compared using the "<" and ">" operators, using any other operator will result in errors.

      The result of this style is that lines are drawn with larger widths as one zooms in and smaller widths as one zooms out.

      diff --git a/styling/css/cookbook/point/index.html b/styling/css/cookbook/point/index.html index f053610acbc..5e6cae4b3e0 100644 --- a/styling/css/cookbook/point/index.html +++ b/styling/css/cookbook/point/index.html @@ -2872,16 +2872,57 @@

      Points

      While points are seemingly the simplest type of shape, possessing only position and no other dimensions, there are many different ways that a point can be styled in CSS.

      Example points layer

      The points layer used for the examples below contains name and population information for the major cities of a fictional country. For reference, the attribute table for the points in this layer is included below.

      -
      -

      fid (Feature ID) name (City name) pop (Population)

      -

      point.1 Borfin 157860

      -

      point.2 Supox City 578231

      -

      point.3 Ruckis 98159

      -

      point.4 Thisland 34879

      -

      point.5 Synopolis 24567

      -

      point.6 San Glissando 76024

      -

      point.7 Detrania 205609

      -
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      fid (Feature ID)name (City name)pop (Population)
      point.1Borfin157860
      point.2Supox City578231
      point.3Ruckis98159
      point.4Thisland34879
      point.5Synopolis24567
      point.6San Glissando76024
      point.7Detrania205609

      Download the points shapefile

      Simple point

      This example specifies points be styled as red circles with a diameter of 6 pixels.

      @@ -3056,12 +3097,42 @@

      Details

      This style shows how the basic mark setup (red circle, default size) can be overridden via cascading/nesting, changing the size depending on the pop attribute value, with smaller values yielding a smaller circle, and larger values yielding a larger circle.

      The three rules are designed as follows:

      -
      -

      Rule order Rule name Population ("pop") Size

      -

      1 SmallPop Less than 50,000 8

      -

      2 MediumPop 50,000 to 100,000 12

      -

      3 LargePop Greater than 100,000 16

      -
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      Rule orderRule namePopulation ("pop")Size
      1SmallPopLess than 50,0008
      2MediumPop50,000 to 100,00012
      3LargePopGreater than 100,00016

      The result of this style is that cities with larger populations have larger points. In particular, the rule at Line 6 matches all features whose "pop" attribute is less than 50000, the rule at Line 9 matches all features whose "pop" attribute is between 50000 and 100000 (mind the space between the two predicates, it is equivalent to and AND, if we had used a comma it would have been an OR instead), while the rule at Line 12 matches all features with more than 100000 inhabitants.

      Zoom-based point

      This example alters the style of the points at different zoom levels.

      @@ -3099,12 +3170,42 @@

      Details

      Determining the appropriate scale denominators (zoom levels) to use is beyond the scope of this example.

      This style contains three rules matching the scale. The three rules are designed as follows:

      -
      -

      Rule order Rule name Scale denominator Point size

      -

      1 Large 1:16,000,000 or less 12

      -

      2 Medium 1:16,000,000 to 1:32,000,000 8

      -

      3 Small Greater than 1:32,000,000 4

      -
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      Rule orderRule nameScale denominatorPoint size
      1Large1:16,000,000 or less12
      2Medium1:16,000,000 to 1:32,000,0008
      3SmallGreater than 1:32,000,0004

      The order of these rules does not matter since the scales denominated in each rule do not overlap.

      The rules use the "@sd" pseudo-attribute, which refers to the current scale denominator, and which can be compared using the '<' and '>' operators only (using any other operator or function will result in errors).

      The result of this style is that points are drawn larger as one zooms in and smaller as one zooms out.

      diff --git a/styling/css/cookbook/polygon/index.html b/styling/css/cookbook/polygon/index.html index 2ed37a81118..d1e637799cd 100644 --- a/styling/css/cookbook/polygon/index.html +++ b/styling/css/cookbook/polygon/index.html @@ -2872,17 +2872,62 @@

      Polygons

      Polygons are two dimensional shapes that contain both an outer edge (or "stroke") and an inside (or "fill"). A polygon can be thought of as an irregularly-shaped point and is styled in similar ways to points.

      Example polygons layer

      The polygons layer used below contains county information for a fictional country. For reference, the attribute table for the polygons is included below.

      -
      -

      fid (Feature ID) name (County name) pop (Population)

      -

      polygon.1 Irony County 412234

      -

      polygon.2 Tracker County 235421

      -

      polygon.3 Dracula County 135022

      -

      polygon.4 Poly County 1567879

      -

      polygon.5 Bearing County 201989

      -

      polygon.6 Monte Cristo County 152734

      -

      polygon.7 Massive County 67123

      -

      polygon.8 Rhombus County 198029

      -
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      fid (Feature ID)name (County name)pop (Population)
      polygon.1Irony County412234
      polygon.2Tracker County235421
      polygon.3Dracula County135022
      polygon.4Poly County1567879
      polygon.5Bearing County201989
      polygon.6Monte Cristo County152734
      polygon.7Massive County67123
      polygon.8Rhombus County198029

      Download the polygons shapefile

      Simple polygon

      This example shows a polygon filled in blue.

      @@ -3038,12 +3083,42 @@

      Details

    Each polygon in our fictional country has a population that is represented by the population ("pop") attribute. This style contains three rules that alter the fill based on the value of "pop" attribute, with smaller values yielding a lighter color and larger values yielding a darker color.

    The three rules are designed as follows:

    -
    -

    Rule order Rule name Population ("pop") Color

    -

    1 SmallPop Less than 200,000 #66FF66

    -

    2 MediumPop 200,000 to 500,000 #33CC33

    -

    3 LargePop Greater than 500,000 #009900

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Rule orderRule namePopulation ("pop")Color
    1SmallPopLess than 200,000#66FF66
    2MediumPop200,000 to 500,000#33CC33
    3LargePopGreater than 500,000#009900

    The order of the rules does not matter in this case, since each shape is only rendered by a single rule.

    The first rule fills light green all polygons whose "pop" attribute is below 200,000, the second paints medium green all poygons whose "pop" attribute is between 200,000 and 500,000, while the third rule paints dark green the remaining polygons.

    What's interesting in the filters is the use of the "parseLong" filter function: this function is necessary because the "pop" attribute is a string, leaving it as is we would have a string comparison, whilst the function turns it into a number, ensuring proper numeric comparisons instead.

    @@ -3087,12 +3162,47 @@

    Details

    Determining the appropriate scale denominators (zoom levels) to use is beyond the scope of this example.

    This style contains three rules, defined as follows:

    -
    -

    Rule order Rule name Scale denominator Stroke width Label display?

    -

    1 Large 1:100,000,000 or less 7 Yes

    -

    2 Medium 1:100,000,000 to 1:200,000,000 4 No

    -

    3 Small Greater than 1:200,000,000 2 No

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Rule orderRule nameScale denominatorStroke widthLabel display?
    1Large1:100,000,000 or less7Yes
    2Medium1:100,000,000 to 1:200,000,0004No
    3SmallGreater than 1:200,000,0002No

    The first rule (lines 1-4) defines the attributes that are not scale dependent: dark blue fill, black outline.

    The second (lines 6-14) rule provides specific overrides for the higher zoom levels, asking for a large stroke (7 pixels) and a label, which is only visible at this zoom level. The label is white, bold, Arial 14 pixels, its contents are coming form the "name" attribute.

    The third rule (lines 16-18) specifies a stroke width of 4 pixels for medium zoom levels, whilst for low zoom levels the stroke width is set to 1 pixel by the last rule (lines 20-22).

    diff --git a/styling/css/cookbook/raster/index.html b/styling/css/cookbook/raster/index.html index da9b3ce90bc..720af6998d7 100644 --- a/styling/css/cookbook/raster/index.html +++ b/styling/css/cookbook/raster/index.html @@ -2796,17 +2796,62 @@

    Code

    Details

    This example is similar to the previous ones, and creates a color gradient between 8 colors as reported in the following table

    -
    -

    Entry number Value Color

    -

    1 95 Black

    -

    2 110 Blue

    -

    3 135 Green

    -

    4 160 Red

    -

    5 185 Purple

    -

    6 210 Yellow

    -

    7 235 Cyan

    -

    8 256 White

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Entry numberValueColor
    195Black
    2110Blue
    3135Green
    4160Red
    5185Purple
    6210Yellow
    7235Cyan
    8256White
    diff --git a/styling/css/directives/index.html b/styling/css/directives/index.html index 722cd19071f..a00db10f3b9 100644 --- a/styling/css/directives/index.html +++ b/styling/css/directives/index.html @@ -2126,14 +2126,42 @@

    Directives

    }

    Supported directives

    -
    -

    Directive Type Meaning Accepts Expression?

    -
    -

    mode String, Exclusive, Simple, Auto, Flat Controls how the CSS is translated to SLD. Exclusive, Simple and Auto are cascaded modes, Flat turns off cascading and has the CSS behave like a simplified syntax SLD sheet. See Understanding Cascading in CSS for an explanation of how the various modes work false

    -

    styleName String The generated SLD style name No

    -

    styleTitle String The generated SLD style title No

    -

    styleAbstract String The generated SLD style abstract/description No

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    DirectiveTypeMeaningAccepts Expression?
    modeString, Exclusive, Simple, Auto, FlatControls how the CSS is translated to SLD. Exclusive, Simple and Auto are cascaded modes, Flat turns off cascading and has the CSS behave like a simplified syntax SLD sheet. See Understanding Cascading in CSS for an explanation of how the various modes workfalse
    styleNameStringThe generated SLD style nameNo
    styleTitleStringThe generated SLD style titleNo
    styleAbstractStringThe generated SLD style abstract/descriptionNo
    diff --git a/styling/css/filters/index.html b/styling/css/filters/index.html index 0cb7d4835bc..fcc9df37f39 100644 --- a/styling/css/filters/index.html +++ b/styling/css/filters/index.html @@ -2254,17 +2254,44 @@

    Combining filters

    Filtering on data attributes

    An attribute filter matches some attribute of the data (for example, a column in a database table). This is probably the most common type of filter. An attribute filter takes the form of an attribute name and a data value separated by some predicate operator (such as the less-than operator <).

    Supported predicate operators include the following:

    -
    -

    Operator Meaning

    -
    -

    = The property must be exactly equal to the specified value.

    -

    <> The property must not be exactly equal to the specified value.

    -

    > The property must be greater than (or alphabetically later than) the specified value.

    -

    >= The property must be greater than or equal to the specified value.

    -

    < The property must be less than (or alphabetically earlier than) the specified value.

    -

    <= The property must be less than or equal to the specified value.

    -

    LIKE The property must match the pattern described by the specified value. Patterns use _ to indicate a single unspecified character and % to indicate an unknown number of unspecified characters.

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    OperatorMeaning
    =The property must be exactly equal to the specified value.
    <>The property must not be exactly equal to the specified value.
    >The property must be greater than (or alphabetically later than) the specified value.
    >=The property must be greater than or equal to the specified value.
    <The property must be less than (or alphabetically earlier than) the specified value.
    <=The property must be less than or equal to the specified value.
    LIKEThe property must match the pattern described by the specified value. Patterns use _ to indicate a single unspecified character and % to indicate an unknown number of unspecified characters.

    For example, to only render outlines for the states whose names start with letters in the first half of the alphabet, the rule would look like:

    [STATE_NAME<='M'] {
         stroke: black;
    @@ -2297,12 +2324,24 @@ 

    Filtering by rendering context (sc }

    The context details that are provided are as follows:

    -
    -

    Pseudo-Attribute Meaning

    -
    -

    @sd The scale denominator for the current rendering. More explicitly, this is the ratio of real-world distance to screen/rendered distance.

    -

    @scale Same as above, the scale denominator (not scale) for the current rendering. Supported for backwards compatibility

    -
    + + + + + + + + + + + + + + + + + +
    Pseudo-AttributeMeaning
    @sdThe scale denominator for the current rendering. More explicitly, this is the ratio of real-world distance to screen/rendered distance.
    @scaleSame as above, the scale denominator (not scale) for the current rendering. Supported for backwards compatibility

    The scale value can be expressed as a plain number, for for brevity and readability the suffixes k (kilo), M (mega), G (giga) can be used, for example:

    [@sd > 100k]
     [@sd < 12M]
    @@ -2314,18 +2353,48 @@ 

    Filtering by rendering context (sc

    Filtering symbols

    When using symbols to create graphics inline, you may want to apply some styling options to them. You can specify style attributes for built-in symbols by using a few special selectors:

    -
    -

    PseudoSelector Meaning

    -
    -

    :mark specifies that a rule applies to symbols used as point markers

    -

    :stroke specifies that a rule applies to symbols used as stroke patterns

    -

    :fill specifies that a rule applies to symbols used as fill patterns

    -

    :symbol specifies that a rule applies to any symbol, regardless of which context it is used in

    -

    :nth-mark(n) specifies that a rule applies to the symbol used for the nth stacked point marker on a feature.

    -

    :nth-stroke(n) specifies that a rule applies to the symbol used for the nth stacked stroke pattern on a feature.

    -

    :nth-fill(n) specifies that a rule applies to the symbol used for the nth stacked fill pattern on a feature.

    -

    :nth-symbol(n) specifies that a rule applies to the symbol used for the nth stacked symbol on a feature, regardless of which context it is used in.

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    PseudoSelectorMeaning
    :markspecifies that a rule applies to symbols used as point markers
    :strokespecifies that a rule applies to symbols used as stroke patterns
    :fillspecifies that a rule applies to symbols used as fill patterns
    :symbolspecifies that a rule applies to any symbol, regardless of which context it is used in
    :nth-mark(n)specifies that a rule applies to the symbol used for the nth stacked point marker on a feature.
    :nth-stroke(n)specifies that a rule applies to the symbol used for the nth stacked stroke pattern on a feature.
    :nth-fill(n)specifies that a rule applies to the symbol used for the nth stacked fill pattern on a feature.
    :nth-symbol(n)specifies that a rule applies to the symbol used for the nth stacked symbol on a feature, regardless of which context it is used in.

    For more discussion on using these selectors, see Styled marks.

    Global rules

    Sometimes it is useful to have a rule that matches all features, for example, to provide some default styling for your map (remember, by default nothing is rendered). This is accomplished using a single asterisk * in place of the usual filter. This catch-all rule can be used in complex expressions, which may be useful if you want a rule to provide defaults as well as overriding values for some features:

    diff --git a/styling/css/properties/index.html b/styling/css/properties/index.html index cc73b22d4be..67c5af257e9 100644 --- a/styling/css/properties/index.html +++ b/styling/css/properties/index.html @@ -2254,153 +2254,735 @@

    Property listing

    This page lists the supported rendering properties. See CSS value types for more information about the value types for each.

    Point symbology

    -
    -

    Property Type Meaning Accepts Expression?

    -
    -

    mark url, symbol The image or well-known shape to render for points yes

    -

    mark-composite string The composite mode to be used and the optional opacity separated with a comma. See the full list of available modes. no

    -

    mark-mime string (MIME Type) The type of the image referenced by a url() No, defaults to 'image/jpeg'

    -

    mark-geometry expression An expression to use for the geometry when rendering features yes

    -

    mark-size length The width to assume for the provided image. The height will be adjusted to preserve the source aspect ratio. yes

    -

    mark-rotation angle A rotation to be applied (clockwise) to the mark image. yes

    -

    z-index integer Controls the z ordering of output no

    -

    mark-label-obstacle boolean If true the point symbol will be considered an obstacle for labels, no label will overlap it no

    -

    mark-anchor expression The part of the mark to place over the point or middle of the polygon. This takes 2 values - x y where x=0 is the left edge of the label, x=1 is the right edge. y=0 is the bottom edge of the label, y=1 is the top edge. Specify 0.5 0.5 to centre a label. yes

    -

    mark-offset expression This is for fine-tuning mark-anchor. x and y values specify pixel offsets to adjust the mark position. yes

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    PropertyTypeMeaningAccepts Expression?
    markurl, symbolThe image or well-known shape to render for pointsyes
    mark-compositestringThe composite mode to be used and the optional opacity separated with a comma. See the full list of available modes.no
    mark-mimestring (MIME Type)The type of the image referenced by a url()No, defaults to 'image/jpeg'
    mark-geometryexpressionAn expression to use for the geometry when rendering featuresyes
    mark-sizelengthThe width to assume for the provided image. The height will be adjusted to preserve the source aspect ratio.yes
    mark-rotationangleA rotation to be applied (clockwise) to the mark image.yes
    z-indexintegerControls the z ordering of outputno
    mark-label-obstaclebooleanIf true the point symbol will be considered an obstacle for labels, no label will overlap itno
    mark-anchorexpressionThe part of the mark to place over the point or middle of the polygon. This takes 2 values - x y where x=0 is the left edge of the label, x=1 is the right edge. y=0 is the bottom edge of the label, y=1 is the top edge. Specify 0.5 0.5 to centre a label.yes
    mark-offsetexpressionThis is for fine-tuning mark-anchor. x and y values specify pixel offsets to adjust the mark position.yes

    Line symbology

    -
    -

    Property Type Meaning Accepts Expression?

    -
    -

    stroke color, url, symbol The color, graphic, or well-known shape to use to stroke lines or outlines yes

    -

    stroke-composite string The composite mode to be used and the optional opacity separated with a comma. See the full list of available modes. no

    -

    stroke-geometry expression An expression to use for the geometry when rendering features. yes

    -

    stroke-offset expression Draws a parallel line using the specified distance, positive values offset left, negative right. yes

    -

    stroke-mime string (MIME Type) The type of the image referenced by a url() No, defaults to 'image/jpeg'

    -

    stroke-opacity percentage A value in the range of 0 (fully transparent) to 1.0 (fully opaque) yes

    -

    stroke-width length The width to use for stroking the line. yes

    -

    stroke-size length An image or symbol used for the stroke pattern will be stretched or squashed to this size before rendering. If this value differs from the stroke-width, the graphic will be repeated or clipped as needed. yes

    -

    stroke-rotation angle A rotation to be applied (clockwise) to the stroke image. See also the stroke- repeat property. yes

    -

    stroke-linecap keyword: butt, square, round The style to apply to the ends of lines drawn yes

    -

    stroke-linejoin keyword: miter, round, bevel The style to apply to the "elbows" where segments of multi-line features meet. yes

    -

    stroke-dasharray list of lengths The lengths of segments to use in a dashed line. no

    -

    stroke-dashoffset length How far to offset the dash pattern from the ends of the lines. yes|

    -

    stroke-repeat keyword: repeat, stipple How to use the provided graphic to paint the line. If repeat, then the graphic is repeatedly painted along the length of the line (rotated appropriately to match the line's direction). If stipple, then the line is treated as a polygon to be filled. yes

    -

    z-index integer Controls the z ordering of output no

    -

    stroke-label-obstacle boolean If true the line will be considered an obstacle for labels, no label will overlap it no

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    PropertyTypeMeaningAccepts Expression?
    strokecolor, url, symbolThe color, graphic, or well-known shape to use to stroke lines or outlinesyes
    stroke-compositestringThe composite mode to be used and the optional opacity separated with a comma. See the full list of available modes.no
    stroke-geometryexpressionAn expression to use for the geometry when rendering features.yes
    stroke-offsetexpressionDraws a parallel line using the specified distance, positive values offset left, negative right.yes
    stroke-mimestring (MIME Type)The type of the image referenced by a url()No, defaults to 'image/jpeg'
    stroke-opacitypercentageA value in the range of 0 (fully transparent) to 1.0 (fully opaque)yes
    stroke-widthlengthThe width to use for stroking the line.yes
    stroke-sizelengthAn image or symbol used for the stroke pattern will be stretched or squashed to this size before rendering. If this value differs from the stroke-width, the graphic will be repeated or clipped as needed.yes
    stroke-rotationangleA rotation to be applied (clockwise) to the stroke image. See also the stroke- repeat property.yes
    stroke-linecapkeyword: butt, square, roundThe style to apply to the ends of lines drawnyes
    stroke-linejoinkeyword: miter, round, bevelThe style to apply to the "elbows" where segments of multi-line features meet.yes
    stroke-dasharraylist of lengthsThe lengths of segments to use in a dashed line.no
    stroke-dashoffsetlengthHow far to offset the dash pattern from the ends of the lines.yes
    stroke-repeatkeyword: repeat, stippleHow to use the provided graphic to paint the line. If repeat, then the graphic is repeatedly painted along the length of the line (rotated appropriately to match the line's direction). If stipple, then the line is treated as a polygon to be filled.yes
    z-indexintegerControls the z ordering of outputno
    stroke-label-obstaclebooleanIf true the line will be considered an obstacle for labels, no label will overlap itno

    Polygon symbology

    -
    -

    Property Type Meaning Accepts Expression?

    -
    -

    fill color, url, symbol The color, graphic, or well-known shape to use to stroke lines or outlines yes

    -

    fill-composite string The composite mode to be used and the optional opacity separated with a comma. See the full list of available modes. no

    -

    fill-geometry expression An expression to use for the geometry when rendering features. yes

    -

    fill-mime string (MIME Type) The type of the image referenced by a url() No, defaults to 'image/jpeg'

    -

    fill-opacity percentage A value in the range of 0 (fully transparent) to 1.0 (fully opaque) yes

    -

    fill-size length The width to assume for the image or graphic provided. yes

    -

    fill-rotation angle A rotation to be applied (clockwise) to the fill image. yes

    -

    z-index integer Controls the z ordering of output no

    -

    fill-label-obstacle boolean If true the polygon will be considered an obstacle for labels, no label will overlap it no

    -

    graphic-margin List of lengths A list of 1 to 4 values, specifying the space between repeated graphics in a texture paint. One value is uniform spacing in all directions, two values are considered top/bottom and right/left, three values are considered top, right/left, bottom, four values are read as top,right,bottom,left. no

    -

    random none,grid,free Activates random distribution of symbols in a texture fill tile. See Fills with randomized symbols for details. Defaults to "none" no

    -

    random-seed integer number The seed for the random generator. Defaults to 0 no

    -

    random-rotation none/free When set to "free" activates random rotation of the symbol in addition to random distribution. Defaults to "none" no

    -

    random-symbol-count positive integer number Number of symbols to be placed in the texture fill tile. May not be respected due to location conflicts (no two symbols are allowed to overlap). Defaults to 16. no

    -

    random-tile-size positive integer number Size of the texture paint tile that will be filled with the random symbols. Defaults to 256. no

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    PropertyTypeMeaningAccepts Expression?
    fillcolor, url, symbolThe color, graphic, or well-known shape to use to stroke lines or outlinesyes
    fill-compositestringThe composite mode to be used and the optional opacity separated with a comma. See the full list of available modes.no
    fill-geometryexpressionAn expression to use for the geometry when rendering features.yes
    fill-mimestring (MIME Type)The type of the image referenced by a url()No, defaults to 'image/jpeg'
    fill-opacitypercentageA value in the range of 0 (fully transparent) to 1.0 (fully opaque)yes
    fill-sizelengthThe width to assume for the image or graphic provided.yes
    fill-rotationangleA rotation to be applied (clockwise) to the fill image.yes
    z-indexintegerControls the z ordering of outputno
    fill-label-obstaclebooleanIf true the polygon will be considered an obstacle for labels, no label will overlap itno
    graphic-marginList of lengthsA list of 1 to 4 values, specifying the space between repeated graphics in a texture paint. One value is uniform spacing in all directions, two values are considered top/bottom and right/left, three values are considered top, right/left, bottom, four values are read as top,right,bottom,left.no
    randomnone,grid,freeActivates random distribution of symbols in a texture fill tile. See Fills with randomized symbols for details. Defaults to "none"no
    random-seedinteger numberThe seed for the random generator. Defaults to 0no
    random-rotationnone/freeWhen set to "free" activates random rotation of the symbol in addition to random distribution. Defaults to "none"no
    random-symbol-countpositive integer numberNumber of symbols to be placed in the texture fill tile. May not be respected due to location conflicts (no two symbols are allowed to overlap). Defaults to 16.no
    random-tile-sizepositive integer numberSize of the texture paint tile that will be filled with the random symbols. Defaults to 256.no

    Text symbology (labelling) - part 1

    -
    -

    Property Type Meaning Accepts Expression?

    -
    -

    label string The text to display as labels for features yes

    -

    label-geometry expression An expression to use for the geometry when rendering features. yes

    -

    label-anchor expression The part of the label to place over the point or middle of the polygon. This takes 2 values - x y where x=0 is the left edge of the label, x=1 is the right edge. y=0 is the bottom edge of the label, y=1 is the top edge. Specify 0.5 0.5 to centre a label. yes

    -

    label-offset expression This is for fine-tuning label-anchor. x and y values specify pixels to adjust the label position. For lines, a single value will make the label be parallel to the line, at the given distance, while two values will force a point style placement, with the label painted horizontally at the center of the line (plus the given offsets) yes

    -

    label-rotation expression Clockwise rotation of label in degrees. yes

    -

    label-z-index expression Used to determine which labels are drawn on top of other labels. Lower z-indexes are drawn on top. yes

    -

    shield mark, symbol A graphic to display behind the label, such as a highway shield. yes

    -

    shield-mime string (MIME Type) The type of the image referenced by a url() No, defaults to 'image/jpeg'

    -

    shield-placement one of label, independent, defaults to label Placement of the shield relative to the label. The default is label, meaning the shield will move along with the label and be centered with it (classic road shield). independent places the shield independently instead, using its own anchor and offset properties. The latter is useful to build "point and label" compositions (e.g., city labels) so that the point won't show up if the label does not (as an alternative to a mark and label setup, where the mark will always show up). no

    -

    shield-anchor expression The part of the shield to place over the point or middle of the polygon. This takes 2 values - x y where x=0 is the left edge of the label, x=1 is the right edge. y=0 is the bottom edge of the label, y=1 is the top edge. Specify 0.5 0.5 to centre a label. This property activates only if the shield-placement one is set to independent, otherwise the shield will be centered with the label. yes

    -

    shield-offset expression This is for fine-tuning shield-anchor. x and y values specify pixels to adjust the shield position. This property activates only if the shield-placement one is set to independent, otherwise the shield will be centered with the label. yes

    -

    font-family string The name of the font or font family to use for labels yes

    -

    font-fill fill The fill to use when rendering fonts yes

    -

    font-style keyword: normal, italic, oblique The style for the lettering yes

    -

    font-weight keyword: normal, bold The weight for the lettering yes

    -

    font-size length The size for the font to display. yes

    -

    font-opacity percentage The opacity of the text, from 0 (fully transparent) to 1.0 (fully opaque). yes

    -

    halo-radius length The size of a halo to display around the lettering (to enhance readability). This is required to activate the halo feature. yes

    -

    halo-color color The color for the halo yes

    -

    halo-opacity percentage The opacity of the halo, from 0 (fully transparent) to 1.0 (fully opaque). yes

    -

    label-padding length The amount of 'padding' space to provide around labels. Labels will not be rendered closer together than this threshold. This is equivalent to the spaceAround<labeling_space_around> vendor parameter. no

    -

    label-group one of: true or false If true, the render will treat features with the same label text as a single feature for the purpose of labelling. This is equivalent to the group<labeling_group> vendor parameter. no

    -

    label-max-displacement length If set, this is the maximum displacement that the renderer will apply to a label. Labels that need larger displacements to avoid collisions will simply be omitted. This is equivalent to the maxDisplacement<labeling_max_displacement> vendor parameter. no

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    PropertyTypeMeaningAccepts Expression?
    labelstringThe text to display as labels for featuresyes
    label-geometryexpressionAn expression to use for the geometry when rendering features.yes
    label-anchorexpressionThe part of the label to place over the point or middle of the polygon. This takes 2 values - x y where x=0 is the left edge of the label, x=1 is the right edge. y=0 is the bottom edge of the label, y=1 is the top edge. Specify 0.5 0.5 to centre a label.yes
    label-offsetexpressionThis is for fine-tuning label-anchor. x and y values specify pixels to adjust the label position. For lines, a single value will make the label be parallel to the line, at the given distance, while two values will force a point style placement, with the label painted horizontally at the center of the line (plus the given offsets)yes
    label-rotationexpressionClockwise rotation of label in degrees.yes
    label-z-indexexpressionUsed to determine which labels are drawn on top of other labels. Lower z-indexes are drawn on top.yes
    shieldmark, symbolA graphic to display behind the label, such as a highway shield.yes
    shield-mimestring (MIME Type)The type of the image referenced by a url()No, defaults to 'image/jpeg'
    shield-placementone of label, independent, defaults to labelPlacement of the shield relative to the label. The default is label, meaning the shield will move along with the label and be centered with it (classic road shield). independent places the shield independently instead, using its own anchor and offset properties. The latter is useful to build "point and label" compositions (e.g., city labels) so that the point won't show up if the label does not (as an alternative to a mark and label setup, where the mark will always show up).no
    shield-anchorexpressionThe part of the shield to place over the point or middle of the polygon. This takes 2 values - x y where x=0 is the left edge of the label, x=1 is the right edge. y=0 is the bottom edge of the label, y=1 is the top edge. Specify 0.5 0.5 to centre a label. This property activates only if the shield-placement one is set to independent, otherwise the shield will be centered with the label.yes
    shield-offsetexpressionThis is for fine-tuning shield-anchor. x and y values specify pixels to adjust the shield position. This property activates only if the shield-placement one is set to independent, otherwise the shield will be centered with the label.yes
    font-familystringThe name of the font or font family to use for labelsyes
    font-fillfillThe fill to use when rendering fontsyes
    font-stylekeyword: normal, italic, obliqueThe style for the letteringyes
    font-weightkeyword: normal, boldThe weight for the letteringyes
    font-sizelengthThe size for the font to display.yes
    font-opacitypercentageThe opacity of the text, from 0 (fully transparent) to 1.0 (fully opaque).yes
    halo-radiuslengthThe size of a halo to display around the lettering (to enhance readability). This is required to activate the halo feature.yes
    halo-colorcolorThe color for the haloyes
    halo-opacitypercentageThe opacity of the halo, from 0 (fully transparent) to 1.0 (fully opaque).yes
    label-paddinglengthThe amount of 'padding' space to provide around labels. Labels will not be rendered closer together than this threshold. This is equivalent to the spaceAround<labeling_space_around> vendor parameter.no
    label-groupone of: true or falseIf true, the render will treat features with the same label text as a single feature for the purpose of labelling. This is equivalent to the group<labeling_group> vendor parameter.no
    label-max-displacementlengthIf set, this is the maximum displacement that the renderer will apply to a label. Labels that need larger displacements to avoid collisions will simply be omitted. This is equivalent to the maxDisplacement<labeling_max_displacement> vendor parameter.no

    Text symbology (labelling) - part 2

    -
    -

    Property Type Meaning Accepts Expression?

    -
    -

    label-min-group-distance length This is equivalent to the minGroupDistance vendor parameter in SLD. no

    -

    label-repeat length If set, the renderer will repeat labels at this interval along a line. This is equivalent to the repeat<labeling_repeat> vendor parameter. no

    -

    label-all-group one of true or false when using grouping, whether to label only the longest line that could be built by merging the lines forming the group, or also the other ones. This is equivalent to the allGroup<labeling_all_group> vendor parameter. no

    -

    label-remove-overlaps one of true or false If enabled, the renderer will remove overlapping lines within a group to avoid duplicate labels. This is equivalent to the removeOverlaps vendor parameter. no

    -

    label-allow-overruns one of true or false Determines whether the renderer will show labels that are longer than the lines being labelled. This is equivalent to the allowOverrun vendor parameter. no

    -

    label-follow-line one of true or false If enabled, the render will curve labels to follow the lines being labelled. This is equivalent to the followLine<labeling_follow_line> vendor parameter. no

    -

    label-max-angle-delta one of true or false The maximum amount of curve allowed between two characters of a label; only applies when 'follow-line: true' is set. This is equivalent to the maxAngleDelta<labeling_max_angle_delta> vendor parameter. no

    -

    label-auto-wrap length Labels will be wrapped to multiple lines if they exceed this length in pixels. This is equivalent to the autoWrap<labeling_autowrap> vendor parameter. no

    -

    label-force-ltr one of true or false By default, the renderer will flip labels whose normal orientation would cause them to be upside-down. Set this parameter to false if you are using some icon character label like an arrow to show a line's direction. This is equivalent to the forceLeftToRight<labeling_force_left_to_right> vendor parameter. no

    -

    label-conflict-resolution one of true or false Set this to false to disable label conflict resolution, allowing overlapping labels to be rendered. This is equivalent to the conflictResolution<labeling_conflict_resolution> vendor parameter. no

    -

    label-fit-goodness scale The renderer will omit labels that fall below this "match quality" score. The scoring rules differ for each geometry type. This is equivalent to the goodnessOfFit<labeling_goodness_of_fit> vendor parameter. no

    -

    label-priority expression Specifies an expression to use in determining which features to prefer if there are labelling conflicts. This is equivalent to the Priority<labeling_priority> SLD extension. yes

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    PropertyTypeMeaningAccepts Expression?
    label-min-group-distancelengthThis is equivalent to the minGroupDistance vendor parameter in SLD.no
    label-repeatlengthIf set, the renderer will repeat labels at this interval along a line. This is equivalent to the repeat<labeling_repeat> vendor parameter.no
    label-all-groupone of true or falsewhen using grouping, whether to label only the longest line that could be built by merging the lines forming the group, or also the other ones. This is equivalent to the allGroup<labeling_all_group> vendor parameter.no
    label-remove-overlapsone of true or falseIf enabled, the renderer will remove overlapping lines within a group to avoid duplicate labels. This is equivalent to the removeOverlaps vendor parameter.no
    label-allow-overrunsone of true or falseDetermines whether the renderer will show labels that are longer than the lines being labelled. This is equivalent to the allowOverrun vendor parameter.no
    label-follow-lineone of true or falseIf enabled, the render will curve labels to follow the lines being labelled. This is equivalent to the followLine<labeling_follow_line> vendor parameter.no
    label-max-angle-deltaone of true or falseThe maximum amount of curve allowed between two characters of a label; only applies when 'follow-line: true' is set. This is equivalent to the maxAngleDelta<labeling_max_angle_delta> vendor parameter.no
    label-auto-wraplengthLabels will be wrapped to multiple lines if they exceed this length in pixels. This is equivalent to the autoWrap<labeling_autowrap> vendor parameter.no
    label-force-ltrone of true or falseBy default, the renderer will flip labels whose normal orientation would cause them to be upside-down. Set this parameter to false if you are using some icon character label like an arrow to show a line's direction. This is equivalent to the forceLeftToRight<labeling_force_left_to_right> vendor parameter.no
    label-conflict-resolutionone of true or falseSet this to false to disable label conflict resolution, allowing overlapping labels to be rendered. This is equivalent to the conflictResolution<labeling_conflict_resolution> vendor parameter.no
    label-fit-goodnessscaleThe renderer will omit labels that fall below this "match quality" score. The scoring rules differ for each geometry type. This is equivalent to the goodnessOfFit<labeling_goodness_of_fit> vendor parameter.no
    label-priorityexpressionSpecifies an expression to use in determining which features to prefer if there are labelling conflicts. This is equivalent to the Priority<labeling_priority> SLD extension.yes

    Text symbology (labelling) - part 3

    -
    -

    Property Type Meaning Accepts Expression?

    -
    -

    shield-resize string, one of none, stretch, or proportional Specifies a mode for resizing label graphics (such as highway shields) to fit the text of the label. The default mode, 'none', never modifies the label graphic. In stretch mode, GeoServer will resize the graphic to exactly surround the label text, possibly modifying the image's aspect ratio. In proportional mode, GeoServer will expand the image to be large enough to surround the text while preserving its original aspect ratio. none

    -

    shield-margin list of lengths, one to four elements long. Specifies an extra margin (in pixels) to be applied to the label text when calculating label dimensions for use with the shield-resize option. Similar to the margin shorthand property in CSS for HTML, its interpretation varies depending on how many margin values are provided: 1 = use that margin length on all sides of the label 2 = use the first for top & bottom margins and the second for left & right margins. 3 = use the first for the top margin, second for left & right margins, third for the bottom margin. 4 = use the first for the top margin, second for the right margin, third for the bottom margin, and fourth for the left margin. none

    -

    label-underline-text one of true or false If enabled, the renderer will underline labels. This is equivalent to the underlineText vendor parameter. no

    -

    label-strikethrough-text one of true or false If enabled, the renderer will strikethrough labels. This is equivalent to the strikethroughText vendor parameter. no

    -

    label-char-spacing an amount of pixels, can be negative If present, expands or shrinks the space between subsequent characters in a label according to the value specified no

    -

    label-word-spacing an amount of pixels, must be zero or positive If present, expands the space between subsequent words in a label according to the value specified no

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    PropertyTypeMeaningAccepts Expression?
    shield-resizestring, one of none, stretch, or proportionalSpecifies a mode for resizing label graphics (such as highway shields) to fit the text of the label. The default mode, 'none', never modifies the label graphic. In stretch mode, GeoServer will resize the graphic to exactly surround the label text, possibly modifying the image's aspect ratio. In proportional mode, GeoServer will expand the image to be large enough to surround the text while preserving its original aspect ratio.none
    shield-marginlist of lengths, one to four elements long.Specifies an extra margin (in pixels) to be applied to the label text when calculating label dimensions for use with the shield-resize option. Similar to the margin shorthand property in CSS for HTML, its interpretation varies depending on how many margin values are provided: 1 = use that margin length on all sides of the label 2 = use the first for top & bottom margins and the second for left & right margins. 3 = use the first for the top margin, second for left & right margins, third for the bottom margin. 4 = use the first for the top margin, second for the right margin, third for the bottom margin, and fourth for the left margin.none
    label-underline-textone of true or falseIf enabled, the renderer will underline labels. This is equivalent to the underlineText vendor parameter.no
    label-strikethrough-textone of true or falseIf enabled, the renderer will strikethrough labels. This is equivalent to the strikethroughText vendor parameter.no
    label-char-spacingan amount of pixels, can be negativeIf present, expands or shrinks the space between subsequent characters in a label according to the value specifiedno
    label-word-spacingan amount of pixels, must be zero or positiveIf present, expands the space between subsequent words in a label according to the value specifiedno

    Raster symbology

    -
    -

    Property Type Meaning Accepts Expression?

    -
    -

    raster-channels string The list of raster channels to be used in the output. It can be "auto" to make the renderer choose the best course of action, or a list of band numbers, a single one will generate a gray image, three will generate an RGB one, four will generate a RGBA one. E.g., "1 3 7" to choose the first, third and seventh band of the input raster to make an RGB image no

    -

    raster-composite string The composite mode to be used and the optional opacity separated with a comma. See the full list of available modes. no

    -

    raster-geometry expression The attribute containing the raster to be painted. Normally not needed, but it would work if you had a custom vector data source that contains a GridCoverage attribute, in order to select it yes

    -

    raster-opacity floating point A value comprised between 0 and 1, 0 meaning completely transparent, 1 meaning completely opaque. This controls the whole raster transparency. no

    -

    raster-contrast-enhancement string Allows to stretch the range of data/colors in order to enhance tiny differences. Possible values are 'normalize', 'histogram' and 'none' no

    -

    raster-gamma floating point Gamma adjustment for the output raster no

    -

    raster-z-index integer Controls the z ordering of the raster output no

    -

    raster-color-map string Applies a color map to single banded input. The contents are a space separate list of color-map-entry(color, value) (opacity assumed to be 1 and label will have a null value), or color-map-entry(color, value, opacity, label). The values must be provided in increasing order. no

    -

    raster-color-map-type string Controls how the color map entries are interpreted, the possible values are "ramp", "intervals" and "values", with ramp being the default if no "raster-color-map-type" is provided. The default "ramp" behavior is to linearly interpolate color between the provided values, and assign the lowest color to all values below the lowest value, and the highest color to all values above the highest value. The "intervals" behavior instead assigns solid colors between values, whilst "values" only assigns colors to the specified values, every other value in the raster is not painted at all no

    -

    raster-color-map-extended string Enables "extended color map" mode, which makes the color map use 65536 entries instead of 256, and thus allows for a more precise color mapping. The default is "false", which means the color map is limited to 256 entries (if more than 256 colors are used, the extended color map mode is enabled automatically). This property is ignored if the "raster-color-map" property is not provided. no

    -

    raster-label-fi string Controls if and how color map entry labels are included, as attributes, in the GetFeatureInfo output. Valid values are add, adding the labels as extra attributes, replace, using the labels in place of the actual value, or none (the default) which does not include the labels in the output. no

    -

    raster-label-name string If color map entry labels are included in the GetFeatureInfo output, this property controls then name of the attribute that will contain them. no

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    PropertyTypeMeaningAccepts Expression?
    raster-channelsstringThe list of raster channels to be used in the output. It can be "auto" to make the renderer choose the best course of action, or a list of band numbers, a single one will generate a gray image, three will generate an RGB one, four will generate a RGBA one. E.g., "1 3 7" to choose the first, third and seventh band of the input raster to make an RGB imageno
    raster-compositestringThe composite mode to be used and the optional opacity separated with a comma. See the full list of available modes.no
    raster-geometryexpressionThe attribute containing the raster to be painted. Normally not needed, but it would work if you had a custom vector data source that contains a GridCoverage attribute, in order to select ityes
    raster-opacityfloating pointA value comprised between 0 and 1, 0 meaning completely transparent, 1 meaning completely opaque. This controls the whole raster transparency.no
    raster-contrast-enhancementstringAllows to stretch the range of data/colors in order to enhance tiny differences. Possible values are 'normalize', 'histogram' and 'none'no
    raster-gammafloating pointGamma adjustment for the output rasterno
    raster-z-indexintegerControls the z ordering of the raster outputno
    raster-color-mapstringApplies a color map to single banded input. The contents are a space separate list of color-map-entry(color, value) (opacity assumed to be 1 and label will have a null value), or color-map-entry(color, value, opacity, label). The values must be provided in increasing order.no
    raster-color-map-typestringControls how the color map entries are interpreted, the possible values are "ramp", "intervals" and "values", with ramp being the default if no "raster-color-map-type" is provided. The default "ramp" behavior is to linearly interpolate color between the provided values, and assign the lowest color to all values below the lowest value, and the highest color to all values above the highest value. The "intervals" behavior instead assigns solid colors between values, whilst "values" only assigns colors to the specified values, every other value in the raster is not painted at allno
    raster-color-map-extendedstringEnables "extended color map" mode, which makes the color map use 65536 entries instead of 256, and thus allows for a more precise color mapping. The default is "false", which means the color map is limited to 256 entries (if more than 256 colors are used, the extended color map mode is enabled automatically). This property is ignored if the "raster-color-map" property is not provided.no
    raster-label-fistringControls if and how color map entry labels are included, as attributes, in the GetFeatureInfo output. Valid values are add, adding the labels as extra attributes, replace, using the labels in place of the actual value, or none (the default) which does not include the labels in the output.no
    raster-label-namestringIf color map entry labels are included in the GetFeatureInfo output, this property controls then name of the attribute that will contain them.no

    Shared

    -
    -

    Property Type Meaning Accepts Expression?

    -
    -

    composite string The composite mode to be used and the optional opacity separated with a comma. See the full list of available modes. no

    -

    composite-base one of true or false This will tell the rendering engine to use that FeatureTypeStyle as the destination, and will compose all subsequent FeatureTypeStyle/Layers on top of it, until another base is found. no

    -

    geometry expression An expression to use for the geometry when rendering features. This provides a geometry for all types of symbology, but can be overridden by the symbol-specific geometry properties. yes

    -

    sort-by string A comma separated list of sorting directives, att1 A|D, att2 A|D, ... where att? are attribute names, and A or D are an optional direction specification, A is ascending, D is descending. Determines the loading, and thus painting, order of the features no

    -

    sort-by-group string Rules with the different z-index but same sort-by-group id have their features sorted as a single group. Useful to z-order across layers or across different feature groups, like roads and rails, especially when using z-index to support casing no

    -

    transform function Applies a rendering transformation on the current level. The function syntax is txName(key1:value1,key1:value2). Values can be single ones, or space separated lists. no

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    PropertyTypeMeaningAccepts Expression?
    compositestringThe composite mode to be used and the optional opacity separated with a comma. See the full list of available modes.no
    composite-baseone of true or falseThis will tell the rendering engine to use that FeatureTypeStyle as the destination, and will compose all subsequent FeatureTypeStyle/Layers on top of it, until another base is found.no
    geometryexpressionAn expression to use for the geometry when rendering features. This provides a geometry for all types of symbology, but can be overridden by the symbol-specific geometry properties.yes
    sort-bystringA comma separated list of sorting directives, att1 A|D, att2 A|D, ... where att? are attribute names, and A or D are an optional direction specification, A is ascending, D is descending. Determines the loading, and thus painting, order of the featuresno
    sort-by-groupstringRules with the different z-index but same sort-by-group id have their features sorted as a single group. Useful to z-order across layers or across different feature groups, like roads and rails, especially when using z-index to support casingno
    transformfunctionApplies a rendering transformation on the current level. The function syntax is txName(key1:value1,key1:value2). Values can be single ones, or space separated lists.no

    Symbol properties

    These properties are applied only when styling built-in symbols. See Styled marks for details.

    -
    -

    Property Type Meaning Accepts Expression?

    -
    -

    size length The size at which to render the symbol. yes

    -

    rotation angle An angle through which to rotate the symbol. yes

    -
    + + + + + + + + + + + + + + + + + + + + + + + +
    PropertyTypeMeaningAccepts Expression?
    sizelengthThe size at which to render the symbol.yes
    rotationangleAn angle through which to rotate the symbol.yes
    diff --git a/styling/css/valuetypes/index.html b/styling/css/valuetypes/index.html index f385fd2a8ca..ebb1e498a80 100644 --- a/styling/css/valuetypes/index.html +++ b/styling/css/valuetypes/index.html @@ -2259,14 +2259,32 @@

    Labels

    Colors

    Color values are relatively important to styling, so there are multiple ways to specify them.

    -
    -

    Format Interpretation

    -
    -

    #RRGGBB A hexadecimal-encoded color value, with two digits each for red, green, and blue.

    -

    #RGB A hexadecimal-encoded color value, with one digits each for red, green, and blue. This is equivalent to the two-digit-per-channel encoding with each digit duplicated.

    -

    rgb(r, g, b) A three-part color value with each channel represented by a value in the range 0 to 1, or in the range 0 to 255. 0 to 1 is used if any of the values include a decimal point, otherwise it is 0 to 255.

    -

    Simple name The simple English name of the color. A full list of the supported colors is available at http://www.w3.org/TR/SVG/types.html#ColorKeywords

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + +
    FormatInterpretation
    #RRGGBBA hexadecimal-encoded color value, with two digits each for red, green, and blue.
    #RGBA hexadecimal-encoded color value, with one digits each for red, green, and blue. This is equivalent to the two-digit-per-channel encoding with each digit duplicated.
    rgb(r, g, b)A three-part color value with each channel represented by a value in the range 0 to 1, or in the range 0 to 255. 0 to 1 is used if any of the values include a decimal point, otherwise it is 0 to 255.
    Simple nameThe simple English name of the color. A full list of the supported colors is available at http://www.w3.org/TR/SVG/types.html#ColorKeywords

    External references

    When using external images to decorate map features, it is necessary to reference them by URL. This is done by a call to the url function. The URL value may be wrapped in single or double-quotes, or not at all. The same escaping rules as for string values. The url function is also a special case where the surrounding quote marks can usually be omitted. Some examples:

    /* These properties are all equivalent. */
    diff --git a/styling/mbstyle/cookbook/index.html b/styling/mbstyle/cookbook/index.html
    index 51a387c6149..c973575ad7d 100644
    --- a/styling/mbstyle/cookbook/index.html
    +++ b/styling/mbstyle/cookbook/index.html
    @@ -1875,13 +1875,28 @@ 

    MBStyle Cookbook

    The MBStyle Cookbook is a collection of MBStyle "recipes" for creating various types of map styles. Wherever possible, each example is designed to show off a single MBStyle layer so that code can be copied from the examples and adapted when creating MBStyles of your own. While not an exhaustive reference like the MBStyle reference the MBStyle cookbook is designed to be a practical reference, showing common style templates that are easy to understand.

    The MBStyle Cookbook is divided into four sections: the first three for each of the vector types (points, lines, and polygons) and the fourth section for rasters to come. Each example in every section contains a screenshot showing actual GeoServer WMS output, a snippet of the MBStyle code for reference, and a link to download the full MBStyle.

    Each section uses data created especially for the MBStyle Cookbook, with shapefiles for vector data and GeoTIFFs for raster data.

    -
    -

    Data Type Shapefile

    -
    -

    Point mbstyle_cookbook_point.zip

    -

    Line mbstyle_cookbook_line.zip

    -

    Polygon mbstyle_cookbook_polygon.zip

    -
    + + + + + + + + + + + + + + + + + + + + + +
    Data TypeShapefile
    Pointmbstyle_cookbook_point.zip
    Linembstyle_cookbook_line.zip
    Polygonmbstyle_cookbook_polygon.zip
    • Points
    • diff --git a/styling/mbstyle/cookbook/lines/index.html b/styling/mbstyle/cookbook/lines/index.html index 6b2a33b5bec..9d7d9828c55 100644 --- a/styling/mbstyle/cookbook/lines/index.html +++ b/styling/mbstyle/cookbook/lines/index.html @@ -2205,35 +2205,142 @@

      Lines

      While lines can also seem to be simple shapes, having length but no width, there are many options and tricks for making lines display nicely.

      Example lines layer

      The lines layer used in the examples below contains road information for a fictional country. For reference, the attribute table for the points in this layer is included below.

      -
      -

      fid (Feature ID) name (Road name) type (Road class)

      -
      -

      line.1 Latway highway

      -

      line.2 Crescent Avenue secondary

      -

      line.3 Forest Avenue secondary

      -

      line.4 Longway highway

      -

      line.5 Saxer Avenue secondary

      -

      line.6 Ridge Avenue secondary

      -

      line.7 Holly Lane local-road

      -

      line.8 Mulberry Street local-road

      -

      line.9 Nathan Lane local-road

      -

      line.10 Central Street local-road

      -

      line.11 Lois Lane local-road

      -

      line.12 Rocky Road local-road

      -

      line.13 Fleet Street local-road

      -

      line.14 Diane Court local-road

      -

      line.15 Cedar Trail local-road

      -

      line.16 Victory Road local-road

      -

      line.17 Highland Road local-road

      -

      line.18 Easy Street local-road

      -

      line.19 Hill Street local-road

      -

      line.20 Country Road local-road

      -

      line.21 Main Street local-road

      -

      line.22 Jani Lane local-road

      -

      line.23 Shinbone Alley local-road

      -

      line.24 State Street local-road

      -

      line.25 River Road local-road

      -
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      fid (Feature ID)name (Road name)type (Road class)
      line.1Latwayhighway
      line.2Crescent Avenuesecondary
      line.3Forest Avenuesecondary
      line.4Longwayhighway
      line.5Saxer Avenuesecondary
      line.6Ridge Avenuesecondary
      line.7Holly Lanelocal-road
      line.8Mulberry Streetlocal-road
      line.9Nathan Lanelocal-road
      line.10Central Streetlocal-road
      line.11Lois Lanelocal-road
      line.12Rocky Roadlocal-road
      line.13Fleet Streetlocal-road
      line.14Diane Courtlocal-road
      line.15Cedar Traillocal-road
      line.16Victory Roadlocal-road
      line.17Highland Roadlocal-road
      line.18Easy Streetlocal-road
      line.19Hill Streetlocal-road
      line.20Country Roadlocal-road
      line.21Main Streetlocal-road
      line.22Jani Lanelocal-road
      line.23Shinbone Alleylocal-road
      line.24State Streetlocal-road
      line.25River Roadlocal-road

      Download the lines shapefile

      Simple line

      This example specifies lines be colored black with a thickness of 3 pixels.

      diff --git a/styling/mbstyle/cookbook/points/index.html b/styling/mbstyle/cookbook/points/index.html index 1e1401acf53..716a5d70a88 100644 --- a/styling/mbstyle/cookbook/points/index.html +++ b/styling/mbstyle/cookbook/points/index.html @@ -2073,17 +2073,52 @@

      Points

      Points are seemingly the simplest type of shape, possessing only position and no other dimensions. MBStyle has a circle type that can be styled to represent a point.

      Example points layer

      The points layer used for the examples below contains name and population information for the major cities of a fictional country. For reference, the attribute table for the points in this layer is included below.

      -
      -

      fid (Feature ID) name (City name) pop (Population)

      -
      -

      point.1 Borfin 157860

      -

      point.2 Supox City 578231

      -

      point.3 Ruckis 98159

      -

      point.4 Thisland 34879

      -

      point.5 Synopolis 24567

      -

      point.6 San Glissando 76024

      -

      point.7 Detrania 205609

      -
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      fid (Feature ID)name (City name)pop (Population)
      point.1Borfin157860
      point.2Supox City578231
      point.3Ruckis98159
      point.4Thisland34879
      point.5Synopolis24567
      point.6San Glissando76024
      point.7Detrania205609

      Download the points shapefile

      Simple point

      This example specifies points be styled as red circles with a diameter of 6 pixels.

      diff --git a/styling/mbstyle/cookbook/polygons/index.html b/styling/mbstyle/cookbook/polygons/index.html index e775169292e..ea141f28a2c 100644 --- a/styling/mbstyle/cookbook/polygons/index.html +++ b/styling/mbstyle/cookbook/polygons/index.html @@ -2139,18 +2139,57 @@

      Polygons

      Polygons are two dimensional shapes that contain both an outer stroke (or "outline") and an inside (or "fill"). A polygon can be thought of as an irregularly-shaped point and is styled in similar ways to circles.

      Example polygons layer

      The polygons layer used below contains county information for a fictional country. For reference, the attribute table for the polygons is included below.

      -
      -

      fid (Feature ID) name (County name) pop (Population)

      -
      -

      polygon.1 Irony County 412234

      -

      polygon.2 Tracker County 235421

      -

      polygon.3 Dracula County 135022

      -

      polygon.4 Poly County 1567879

      -

      polygon.5 Bearing County 201989

      -

      polygon.6 Monte Cristo County 152734

      -

      polygon.7 Massive County 67123

      -

      polygon.8 Rhombus County 198029

      -
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      fid (Feature ID)name (County name)pop (Population)
      polygon.1Irony County412234
      polygon.2Tracker County235421
      polygon.3Dracula County135022
      polygon.4Poly County1567879
      polygon.5Bearing County201989
      polygon.6Monte Cristo County152734
      polygon.7Massive County67123
      polygon.8Rhombus County198029

      Download the polygons shapefile

      Simple polygon

      This example shows a polygon filled in blue.

      diff --git a/styling/mbstyle/reference/index.html b/styling/mbstyle/reference/index.html index 431cca00059..4a1e8e1925a 100644 --- a/styling/mbstyle/reference/index.html +++ b/styling/mbstyle/reference/index.html @@ -1887,11 +1887,24 @@

      GeoTools MBStyle extension

    When reading the above reference keep in mind the specification is written in an additive fashion, where new features are documented along with the version number range for which they are supported.

    As an example the basic functionality of background-color support is added in GeoTools 23.0, as shown in the following table:

    -
    -

    Support Mapbox GeoTools OpenLayers

    -
    -

    basic functionality >= 0.10.0 Not yet supported >= 2.4.0

    -
    + + + + + + + + + + + + + + + + + +
    SupportMapboxGeoToolsOpenLayers
    basic functionality>= 0.10.0Not yet supported>= 2.4.0
    diff --git a/styling/sld/cookbook/index.html b/styling/sld/cookbook/index.html index c7bef9f0d91..8e581f9df0e 100644 --- a/styling/sld/cookbook/index.html +++ b/styling/sld/cookbook/index.html @@ -2093,13 +2093,36 @@

    SLD Cookbook

    The SLD Cookbook is a collection of SLD "recipes" for creating various types of map styles. Wherever possible, each example is designed to show off a single SLD feature so that code can be copied from the examples and adapted when creating SLDs of your own. While not an exhaustive reference like the SLD Reference or the OGC SLD 1.0 specification the SLD Cookbook is designed to be a practical reference, showing common style templates that are easy to understand.

    The SLD Cookbook is divided into four sections: the first three for each of the vector types (points, lines, and polygons) and the fourth section for rasters. Each example in every section contains a screenshot showing actual GeoServer WMS output, a snippet of the SLD code for reference, and a link to download the full SLD.

    Each section uses data created especially for the SLD Cookbook, with shapefiles for vector data and GeoTIFFs for raster data. The projection for data is EPSG:4326. All files can be easily loaded into GeoServer in order to recreate the examples.

    -
    -

    Data Type Shapefile

    -

    Point sld_cookbook_point.zip

    -

    Line sld_cookbook_line.zip

    -

    Polygon sld_cookbook_polygon.zip

    -

    Raster sld_cookbook_raster.zip

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Data TypeShapefile
    Pointsld_cookbook_point.zip
    Linesld_cookbook_line.zip
    Polygonsld_cookbook_polygon.zip
    Rastersld_cookbook_raster.zip
    • Points
    • diff --git a/styling/sld/cookbook/lines/index.html b/styling/sld/cookbook/lines/index.html index b4c579ddd6d..1a6c6cb1297 100644 --- a/styling/sld/cookbook/lines/index.html +++ b/styling/sld/cookbook/lines/index.html @@ -3021,34 +3021,147 @@

      Lines

    Example lines layer

    The lines layer used in the examples below contains road information for a fictional country. For reference, the attribute table for the points in this layer is included below.

    -
    -

    fid (Feature ID) name (Road name) type (Road class)

    -

    line.1 Latway highway

    -

    line.2 Crescent Avenue secondary

    -

    line.3 Forest Avenue secondary

    -

    line.4 Longway highway

    -

    line.5 Saxer Avenue secondary

    -

    line.6 Ridge Avenue secondary

    -

    line.7 Holly Lane local-road

    -

    line.8 Mulberry Street local-road

    -

    line.9 Nathan Lane local-road

    -

    line.10 Central Street local-road

    -

    line.11 Lois Lane local-road

    -

    line.12 Rocky Road local-road

    -

    line.13 Fleet Street local-road

    -

    line.14 Diane Court local-road

    -

    line.15 Cedar Trail local-road

    -

    line.16 Victory Road local-road

    -

    line.17 Highland Road local-road

    -

    line.18 Easy Street local-road

    -

    line.19 Hill Street local-road

    -

    line.20 Country Road local-road

    -

    line.21 Main Street local-road

    -

    line.22 Jani Lane local-road

    -

    line.23 Shinbone Alley local-road

    -

    line.24 State Street local-road

    -

    line.25 River Road local-road

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    fid (Feature ID)name (Road name)type (Road class)
    line.1Latwayhighway
    line.2Crescent Avenuesecondary
    line.3Forest Avenuesecondary
    line.4Longwayhighway
    line.5Saxer Avenuesecondary
    line.6Ridge Avenuesecondary
    line.7Holly Lanelocal-road
    line.8Mulberry Streetlocal-road
    line.9Nathan Lanelocal-road
    line.10Central Streetlocal-road
    line.11Lois Lanelocal-road
    line.12Rocky Roadlocal-road
    line.13Fleet Streetlocal-road
    line.14Diane Courtlocal-road
    line.15Cedar Traillocal-road
    line.16Victory Roadlocal-road
    line.17Highland Roadlocal-road
    line.18Easy Streetlocal-road
    line.19Hill Streetlocal-road
    line.20Country Roadlocal-road
    line.21Main Streetlocal-road
    line.22Jani Lanelocal-road
    line.23Shinbone Alleylocal-road
    line.24State Streetlocal-road
    line.25River Roadlocal-road

    Download the lines shapefile

    Simple line

    This example specifies lines be colored black with a thickness of 3 pixels.

    @@ -3487,12 +3600,42 @@

    Details

    There are three types of road classes in our fictional country, ranging from back roads to high-speed freeways: "highway", "secondary", and "local-road". In order to handle each case separately, there is more than one <FeatureTypeStyle>, each containing a single rule. This ensures that each road type is rendered in order, as each <FeatureTypeStyle> is drawn based on the order in which it appears in the SLD.

    The three rules are designed as follows:

    -
    -

    Rule order Rule name / type Color Size

    -

    1 local-road #009933 (green) 2

    -

    2 secondary #0055CC (blue) 3

    -

    3 highway #FF0000 (red) 6

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Rule orderRule name / typeColorSize
    1local-road#009933 (green)2
    2secondary#0055CC (blue)3
    3highway#FF0000 (red)6

    Lines 2-16 comprise the first <Rule>. Lines 4-9 set the filter for this rule, such that the "type" attribute has a value of "local-road". If this condition is true for a particular line, the rule is rendered according to the <LineSymbolizer> which is on lines 10-15. Lines 12-13 set the color of the line to be a dark green (#009933) and the width to be 2 pixels.

    Lines 19-33 comprise the second <Rule>. Lines 21-26 set the filter for this rule, such that the "type" attribute has a value of "secondary". If this condition is true for a particular line, the rule is rendered according to the <LineSymbolizer> which is on lines 27-32. Lines 29-30 set the color of the line to be a dark blue (#0055CC) and the width to be 3 pixels, making the lines slightly thicker than the "local-road" lines and also a different color.

    Lines 36-50 comprise the third and final <Rule>. Lines 38-43 set the filter for this rule, such that the "type" attribute has a value of "primary". If this condition is true for a particular line, the rule is rendered according to the <LineSymbolizer> which is on lines 44-49. Lines 46-47 set the color of the line to be a bright red (#FF0000) and the width to be 6 pixels, so that these lines are rendered on top of and thicker than the other two road classes. In this way, the "primary" roads are given priority in the map rendering.

    @@ -3547,12 +3690,42 @@

    Details

    Determining the appropriate scale denominators (zoom levels) to use is beyond the scope of this example.

    This style contains three rules. The three rules are designed as follows:

    -
    -

    Rule order Rule name Scale denominator Line width

    -

    1 Large 1:180,000,000 or less 6

    -

    2 Medium 1:180,000,000 to 1:360,000,000 4

    -

    3 Small Greater than 1:360,000,000 2

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Rule orderRule nameScale denominatorLine width
    1Large1:180,000,000 or less6
    2Medium1:180,000,000 to 1:360,000,0004
    3SmallGreater than 1:360,000,0002

    The order of these rules does not matter since the scales denominated in each rule do not overlap.

    The first rule (lines 2-11) is the smallest scale denominator, corresponding to when the view is "zoomed in". The scale rule is set on line 4, so that the rule will apply to any map with a scale denominator of 180,000,000 or less. Line 7-8 draws the line to be dark green (#009933) with a width of 6 pixels.

    The second rule (lines 12-22) is the intermediate scale denominator, corresponding to when the view is "partially zoomed". Lines 14-15 set the scale such that the rule will apply to any map with scale denominators between 180,000,000 and 360,000,000. (The <MinScaleDenominator> is inclusive and the <MaxScaleDenominator> is exclusive, so a zoom level of exactly 360,000,000 would not apply here.) Aside from the scale, the only difference between this rule and the previous is the width of the lines, which is set to 4 pixels on line 19.

    diff --git a/styling/sld/cookbook/points/index.html b/styling/sld/cookbook/points/index.html index 7135eedaa42..b8888937acf 100644 --- a/styling/sld/cookbook/points/index.html +++ b/styling/sld/cookbook/points/index.html @@ -2823,16 +2823,57 @@

    Points

    Example points layer

    The points layer used for the examples below contains name and population information for the major cities of a fictional country. For reference, the attribute table for the points in this layer is included below.

    -
    -

    fid (Feature ID) name (City name) pop (Population)

    -

    point.1 Borfin 157860

    -

    point.2 Supox City 578231

    -

    point.3 Ruckis 98159

    -

    point.4 Thisland 34879

    -

    point.5 Synopolis 24567

    -

    point.6 San Glissando 76024

    -

    point.7 Detrania 205609

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    fid (Feature ID)name (City name)pop (Population)
    point.1Borfin157860
    point.2Supox City578231
    point.3Ruckis98159
    point.4Thisland34879
    point.5Synopolis24567
    point.6San Glissando76024
    point.7Detrania205609

    Download the points shapefile

    Simple point

    This example specifies points be styled as red circles with a diameter of 6 pixels.

    @@ -3186,12 +3227,42 @@

    Details

    This style contains three rules. Each <Rule> varies the style based on the value of the population ("pop") attribute for each point, with smaller values yielding a smaller circle, and larger values yielding a larger circle.

    The three rules are designed as follows:

    -
    -

    Rule order Rule name Population ("pop") Size

    -

    1 SmallPop Less than 50,000 8

    -

    2 MediumPop 50,000 to 100,000 12

    -

    3 LargePop Greater than 100,000 16

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Rule orderRule namePopulation ("pop")Size
    1SmallPopLess than 50,0008
    2MediumPop50,000 to 100,00012
    3LargePopGreater than 100,00016

    The order of the rules does not matter in this case, since each shape is only rendered by a single rule.

    The first rule, on lines 2-22, specifies the styling of those points whose population attribute is less than 50,000. Lines 5-10 set this filter, with lines 6-9 setting the "less than" filter, line 7 denoting the attribute ("pop"), and line 8 the value of 50,000. The symbol is a circle (line 14), the color is dark blue (#0033CC, on line 16), and the size is 8 pixels in diameter (line 19).

    The second rule, on lines 23-49, specifies a style for points whose population attribute is greater than or equal to 50,000 and less than 100,000. The population filter is set on lines 26-37. This filter is longer than in the first rule because two criteria need to be specified instead of one: a "greater than or equal to" and a "less than" filter. Notice the And on line 27 and line 36. This mandates that both filters need to be true for the rule to be applicable. The size of the graphic is set to 12 pixels on line 46. All other styling directives are identical to the first rule.

    @@ -3263,12 +3334,42 @@

    Details

    Determining the appropriate scale denominators (zoom levels) to use is beyond the scope of this example.

    This style contains three rules. The three rules are designed as follows:

    -
    -

    Rule order Rule name Scale denominator Point size

    -

    1 Large 1:160,000,000 or less 12

    -

    2 Medium 1:160,000,000 to 1:320,000,000 8

    -

    3 Small Greater than 1:320,000,000 4

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Rule orderRule nameScale denominatorPoint size
    1Large1:160,000,000 or less12
    2Medium1:160,000,000 to 1:320,000,0008
    3SmallGreater than 1:320,000,0004

    The order of these rules does not matter since the scales denominated in each rule do not overlap.

    The first rule (lines 2-16) is for the smallest scale denominator, corresponding to when the view is "zoomed in". The scale rule is set on line 4, so that the rule will apply to any map with a scale denominator of 160,000,000 or less. The rule draws a circle (line 8), colored red (#CC3300 on line 10) with a size of 12 pixels (line 13).

    The second rule (lines 17-32) is the intermediate scale denominator, corresponding to when the view is "partially zoomed". The scale rules are set on lines 19-20, so that the rule will apply to any map with a scale denominator between 160,000,000 and 320,000,000. (The <MinScaleDenominator> is inclusive and the <MaxScaleDenominator> is exclusive, so a zoom level of exactly 320,000,000 would not apply here.) Aside from the scale, the only difference between this rule and the first is the size of the symbol, which is set to 8 pixels on line 29.

    diff --git a/styling/sld/cookbook/polygons/index.html b/styling/sld/cookbook/polygons/index.html index b02dda4b561..76e2942a28d 100644 --- a/styling/sld/cookbook/polygons/index.html +++ b/styling/sld/cookbook/polygons/index.html @@ -2889,17 +2889,62 @@

    Polygons

    Example polygons layer

    The polygons layer used below contains county information for a fictional country. For reference, the attribute table for the polygons is included below.

    -
    -

    fid (Feature ID) name (County name) pop (Population)

    -

    polygon.1 Irony County 412234

    -

    polygon.2 Tracker County 235421

    -

    polygon.3 Dracula County 135022

    -

    polygon.4 Poly County 1567879

    -

    polygon.5 Bearing County 201989

    -

    polygon.6 Monte Cristo County 152734

    -

    polygon.7 Massive County 67123

    -

    polygon.8 Rhombus County 198029

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    fid (Feature ID)name (County name)pop (Population)
    polygon.1Irony County412234
    polygon.2Tracker County235421
    polygon.3Dracula County135022
    polygon.4Poly County1567879
    polygon.5Bearing County201989
    polygon.6Monte Cristo County152734
    polygon.7Massive County67123
    polygon.8Rhombus County198029

    Download the polygons shapefile

    Simple polygon

    This example shows a polygon filled in blue.

    @@ -3236,12 +3281,42 @@

    Details

    Each polygon in our fictional country has a population that is represented by the population ("pop") attribute. This style contains three rules that alter the fill based on the value of "pop" attribute, with smaller values yielding a lighter color and larger values yielding a darker color.

    The three rules are designed as follows:

    -
    -

    Rule order Rule name Population ("pop") Color

    -

    1 SmallPop Less than 200,000 #66FF66

    -

    2 MediumPop 200,000 to 500,000 #33CC33

    -

    3 LargePop Greater than 500,000 #009900

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Rule orderRule namePopulation ("pop")Color
    1SmallPopLess than 200,000#66FF66
    2MediumPop200,000 to 500,000#33CC33
    3LargePopGreater than 500,000#009900

    The order of the rules does not matter in this case, since each shape is only rendered by a single rule.

    The first rule, on lines 2-16, specifies the styling of polygons whose population attribute is less than 200,000. Lines 5-10 set this filter, with lines 6-9 setting the "less than" filter, line 7 denoting the attribute ("pop"), and line 8 the value of 200,000. The color of the polygon fill is set to a light green (#66FF66) on line 13.

    The second rule, on lines 17-37, is similar, specifying a style for polygons whose population attribute is greater than or equal to 200,000 but less than 500,000. The filter is set on lines 20-31. This filter is longer than in the first rule because two criteria need to be specified instead of one: a "greater than or equal to" and a "less than" filter. Notice the And on line 21 and line 30. This mandates that both filters need to be true for the rule to be applicable. The color of the polygon fill is set to a medium green on (#33CC33) on line 34.

    @@ -3329,12 +3404,47 @@

    Details

    Determining the appropriate scale denominators (zoom levels) to use is beyond the scope of this example.

    This style contains three rules, defined as follows:

    -
    -

    Rule order Rule name Scale denominator Stroke width Label display?

    -

    1 Large 1:100,000,000 or less 7 Yes

    -

    2 Medium 1:100,000,000 to 1:200,000,000 4 No

    -

    3 Small Greater than 1:200,000,000 2 No

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Rule orderRule nameScale denominatorStroke widthLabel display?
    1Large1:100,000,000 or less7Yes
    2Medium1:100,000,000 to 1:200,000,0004No
    3SmallGreater than 1:200,000,0002No

    The first rule, on lines 2-36, is for the smallest scale denominator, corresponding to when the view is "zoomed in". The scale rule is set on line 40 such that the rule will apply only where the scale denominator is 100,000,000 or less. Line 7 defines the fill as blue (#0000CC). Note that the fill is kept constant across all rules regardless of the scale denominator. As in the Polygon with default label or Polygon with styled label examples, the rule also contains a <TextSymbolizer> at lines 14-35 for drawing a text label on top of the polygon. Lines 19-22 set the font information to be Arial, 14 pixels, and bold with no italics. The label is centered both horizontally and vertically along the centroid of the polygon on by setting <AnchorPointX> and <AnchorPointY> to both be 0.5 (or 50%) on lines 27-28. Finally, the color of the font is set to white (#FFFFFF) in line 33.

    The second rule, on lines 37-50, is for the intermediate scale denominators, corresponding to when the view is "partially zoomed". The scale rules on lines 39-40 set the rule such that it will apply to any map with a scale denominator between 100,000,000 and 200,000,000. (The <MinScaleDenominator> is inclusive and the <MaxScaleDenominator> is exclusive, so a zoom level of exactly 200,000,000 would not apply here.) Aside from the scale, there are two differences between this rule and the first: the width of the stroke is set to 4 pixels on line 47 and a <TextSymbolizer> is not present so that no labels will be displayed.

    The third rule, on lines 51-63, is for the largest scale denominator, corresponding to when the map is "zoomed out". The scale rule is set on line 53 such that the rule will apply to any map with a scale denominator of 200,000,000 or greater. Again, the only differences between this rule and the others are the width of the lines, which is set to 1 pixel on line 60, and the absence of a <TextSymbolizer> so that no labels will be displayed.

    diff --git a/styling/sld/cookbook/rasters/index.html b/styling/sld/cookbook/rasters/index.html index 72bde7dc46f..8eb73ad70bd 100644 --- a/styling/sld/cookbook/rasters/index.html +++ b/styling/sld/cookbook/rasters/index.html @@ -2782,17 +2782,72 @@

    Code

    Details

    A <ColorMap> can include up to 255 <ColorMapEntry> elements. This example has eight entries (lines 4-13):

    -
    -

    Entry number Value Color RGB code

    -

    1 95 Black #000000

    -

    2 110 Blue #0000FF

    -

    3 135 Green #00FF00

    -

    4 160 Red #FF0000

    -

    5 185 Purple #FF00FF

    -

    6 210 Yellow #FFFF00

    -

    7 235 Cyan #00FFFF

    -

    8 256 White #FFFFFF

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Entry numberValueColorRGB code
    195Black#000000
    2110Blue#0000FF
    3135Green#00FF00
    4160Red#FF0000
    5185Purple#FF00FF
    6210Yellow#FFFF00
    7235Cyan#00FFFF
    8256White#FFFFFF
    diff --git a/styling/sld/extensions/composite-blend/modes/index.html b/styling/sld/extensions/composite-blend/modes/index.html index 6aed2158151..55af8375df9 100644 --- a/styling/sld/extensions/composite-blend/modes/index.html +++ b/styling/sld/extensions/composite-blend/modes/index.html @@ -2891,24 +2891,24 @@

    Composite and blending modes

    Alpha compositing controls how two images are merged together by using the alpha levels of the two. No color mixing is being performed, only pure binary selection (either one or the other).

    Color blending modes mix the colors of source and destination in various ways. Each pixel in the result will be some sort of combination between the source and destination pixels.

    The following page shows the full list of available modes. (See the syntax page for more details.) To aid in comprehension, two source and two destination images will be used to show visually how each mode works:

    -

    +-----------------------------------+-----------------------------------+ -| Source 1 | Source 2 | -+===================================+===================================+ -| | | -+-----------------------------------+-----------------------------------+

    -

    +-----------------------------------+-----------------------------------+ -| Destination 1 | Destination 2 | -+===================================+===================================+ -| | | -+-----------------------------------+-----------------------------------+

    +

    +---------------------+----------------------+ +| Source 1 | Source 2 | ++=====================+======================+ +| | | ++---------------------+----------------------+

    +

    +---------------------+----------------------+ +| Destination 1 | Destination 2 | ++=====================+======================+ +| | | ++---------------------+----------------------+

    Alpha compositing modes

    copy

    Only the source will be present in the output.

    -

    +-----------------------------------+-----------------------------------+ -| Example 1 | Example 2 | -+===================================+===================================+ -| | | -+-----------------------------------+-----------------------------------+

    +

    +-----------------------------+-----------------------------+ +| Example 1 | Example 2 | ++=============================+=============================+ +| | | ++-----------------------------+-----------------------------+

    destination

    Only the destination will be present in the output

    +------------------------------------+------------------------------------+ @@ -2932,11 +2932,11 @@

    destination-over

    +-----------------------------------------+-----------------------------------------+

    source-in

    The source is visible only when overlapping some non-transparent pixel of the destination. This allows the background map to act as a mask for the layer/feature being drawn. Opposite of destination-in.

    -

    +-----------------------------------+-----------------------------------+ -| Example 1 | Example 2 | -+===================================+===================================+ -| | | -+-----------------------------------+-----------------------------------+

    +

    +----------------------------------+----------------------------------+ +| Example 1 | Example 2 | ++==================================+==================================+ +| | | ++----------------------------------+----------------------------------+

    destination-in

    The destination is retained only when overlapping some non transparent pixel in the source. This allows the layer/feature to be drawn to act as a mask for the background map. Opposite of source-in.

    +---------------------------------------+---------------------------------------+ @@ -2974,48 +2974,48 @@

    destination-atop

    +-----------------------------------------+-----------------------------------------+

    xor

    "Exclusive Or" mode. Each pixel is rendered only if either the source or the destination is not blank, but not both.

    -

    +-----------------------------------+-----------------------------------+ -| Example 1 | Example 2 | -+===================================+===================================+ -| | | -+-----------------------------------+-----------------------------------+

    +

    +----------------------------+----------------------------+ +| Example 1 | Example 2 | ++============================+============================+ +| | | ++----------------------------+----------------------------+

    Color blending modes

    multiply

    The source color is multiplied by the destination color and replaces the destination. The resulting color is always at least as dark as either the source or destination color. Multiplying any color with black results in black. Multiplying any color with white preserves the original color.

    -

    +-----------------------------------+-----------------------------------+ -| Example 1 | Example 2 | -+===================================+===================================+ -| | | -+-----------------------------------+-----------------------------------+

    +

    +---------------------------------+---------------------------------+ +| Example 1 | Example 2 | ++=================================+=================================+ +| | | ++---------------------------------+---------------------------------+

    screen

    Multiplies the complements of the source and destination color values, then complements the result. The end result color is always at least as light as either of the two constituent colors. Screening any color with white produces white; screening with black leaves the original color unchanged.

    The effect is similar to projecting multiple photographic slides simultaneously onto a single screen.

    -

    +-----------------------------------+-----------------------------------+ -| Example 1 | Example 2 | -+===================================+===================================+ -| | | -+-----------------------------------+-----------------------------------+

    +

    +-------------------------------+-------------------------------+ +| Example 1 | Example 2 | ++===============================+===============================+ +| | | ++-------------------------------+-------------------------------+

    overlay

    Multiplies (screens) the colors depending on the destination color value. Source colors overlay the destination while preserving its highlights and shadows. The backdrop color is not replaced but is mixed with the source color to reflect the lightness or darkness of the backdrop.

    -

    +-----------------------------------+-----------------------------------+ -| Example 1 | Example 2 | -+===================================+===================================+ -| | | -+-----------------------------------+-----------------------------------+

    +

    +--------------------------------+--------------------------------+ +| Example 1 | Example 2 | ++================================+================================+ +| | | ++--------------------------------+--------------------------------+

    darken

    Selects the darker of the destination and source colors. The destination is replaced with the source only where the source is darker.

    -

    +-----------------------------------+-----------------------------------+ -| Example 1 | Example 2 | -+===================================+===================================+ -| | | -+-----------------------------------+-----------------------------------+

    +

    +-------------------------------+-------------------------------+ +| Example 1 | Example 2 | ++===============================+===============================+ +| | | ++-------------------------------+-------------------------------+

    lighten

    Selects the lighter of the destination and source colors. The destination is replaced with the source only where the source is lighter.

    -

    +-----------------------------------+-----------------------------------+ -| Example 1 | Example 2 | -+===================================+===================================+ -| | | -+-----------------------------------+-----------------------------------+

    +

    +--------------------------------+--------------------------------+ +| Example 1 | Example 2 | ++================================+================================+ +| | | ++--------------------------------+--------------------------------+

    color-dodge

    Brightens the destination color to reflect the source color. Drawing with black produces no changes.

    +------------------------------------+------------------------------------+ @@ -3053,11 +3053,11 @@

    difference

    +-----------------------------------+-----------------------------------+

    exclusion

    Produces an effect similar to that of difference but lower in contrast. White inverts the destination color; black produces no change.

    -

    +-----------------------------------+-----------------------------------+ -| Example 1 | Example 2 | -+===================================+===================================+ -| | | -+-----------------------------------+-----------------------------------+

    +

    +----------------------------------+----------------------------------+ +| Example 1 | Example 2 | ++==================================+==================================+ +| | | ++----------------------------------+----------------------------------+

    diff --git a/styling/sld/extensions/pointsymbols/index.html b/styling/sld/extensions/pointsymbols/index.html index ffd501adc1a..f2b3773f27f 100644 --- a/styling/sld/extensions/pointsymbols/index.html +++ b/styling/sld/extensions/pointsymbols/index.html @@ -2588,15 +2588,44 @@

    Marks

    See also the PointSymbolizer reference for further details, as well as the examples in the Points Cookbook section.

    Standard symbols

    The SLD specification mandates the support of the following symbols:

    -
    -

    Name Description

    -

    square A square

    -

    circle A circle

    -

    triangle A triangle pointing up

    -

    star five-pointed star

    -

    cross A square cross with space around (not suitable for hatch fills)

    -

    x A square X with space around (not suitable for hatch fills)

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    NameDescription
    squareA square
    circleA circle
    triangleA triangle pointing up
    starfive-pointed star
    crossA square cross with space around (not suitable for hatch fills)
    xA square X with space around (not suitable for hatch fills)

    Shape symbols

    The shape symbols set adds extra symbols that are not part of the basic set.

      @@ -2605,18 +2634,80 @@

      Shape symbols

    1. The shape symbols are prefixed by shape://

      -
      -

      Name Description

      -

      shape://vertline A vertical line (suitable for hatch fills or to make railroad symbols)

      -

      shape://horline A horizontal line (suitable for hatch fills)

      -

      shape://slash A diagonal line leaning forwards like the "slash" keyboard symbol (suitable for diagonal hatches)

      -

      shape://backslash Same as shape://slash, but oriented in the opposite direction

      -

      shape://dot A very small circle with space around

      -

      shape://plus A + symbol, without space around (suitable for cross-hatch fills)

      -

      shape://times A "X" symbol, without space around (suitable for cross-hatch fills)

      -

      shape://oarrow An open arrow symbol (triangle without one side, suitable for placing arrows at the end of lines)

      -

      shape://carrow A closed arrow symbol (closed triangle, suitable for placing arrows at the end of lines)

      -
      + + + + + + + + + + + +
      +
        +
      • +
          +
        • Name
        • +
        • Description
        • +
        +
      • +
      • +
          +
        • shape://vertline
        • +
        • A vertical line (suitable for hatch fills or to make railroad symbols)
        • +
        +
      • +
      • +
          +
        • shape://horline
        • +
        • A horizontal line (suitable for hatch fills)
        • +
        +
      • +
      • +
          +
        • shape://slash
        • +
        • A diagonal line leaning forwards like the "slash" keyboard symbol (suitable for diagonal hatches)
        • +
        +
      • +
      • +
          +
        • shape://backslash
        • +
        • Same as shape://slash, but oriented in the opposite direction
        • +
        +
      • +
      • +
          +
        • shape://dot
        • +
        • A very small circle with space around
        • +
        +
      • +
      • +
          +
        • shape://plus
        • +
        • A + symbol, without space around (suitable for cross-hatch fills)
        • +
        +
      • +
      • +
          +
        • shape://times
        • +
        • A "X" symbol, without space around (suitable for cross-hatch fills)
        • +
        +
      • +
      • +
          +
        • shape://oarrow
        • +
        • An open arrow symbol (triangle without one side, suitable for placing arrows at the end of lines)
        • +
        +
      • +
      • +
          +
        • shape://carrow
        • +
        • A closed arrow symbol (closed triangle, suitable for placing arrows at the end of lines)
        • +
        +
      • +

    Weather Symbols

    @@ -2627,19 +2718,77 @@

    Weather Symbols

  • These symbols are:

    -
    -

    Name Description Produces

    -

    extshape://triangle cold front triangle

    -

    extshape://emicircle warm front emicircle

    -

    extshape://triangleemicircle stationary front triangleemicircle

    -
    + + + + + + + + + + + +
    +
      +
    • +
        +
      • Name
      • +
      • Description
      • +
      • Produces
      • +
      +
    • +
    • +
        +
      • extshape://triangle
      • +
      • cold front
      • +
      • triangle
      • +
      +
    • +
    • +
        +
      • extshape://emicircle
      • +
      • warm front
      • +
      • emicircle
      • +
      +
    • +
    • +
        +
      • extshape://triangleemicircle
      • +
      • stationary front
      • +
      • triangleemicircle
      • +
      +
    • +
  • You can use extshape:// for a few additional built-in shapes:

    -
    -

    extshape://narrow North Arrow

    -

    extshape://sarrow South Arrow

    -
    + + + + + + + + + + + +
    +
      +
    • +
        +
      • extshape://narrow
      • +
      • North Arrow
      • +
      +
    • +
    • +
        +
      • extshape://sarrow
      • +
      • South Arrow
      • +
      +
    • +
  • More complex symbols like Wind Barbs can be created with the windbarbs:// prefix.

    @@ -2649,11 +2798,38 @@

    Weather Symbols

  • There are some examples:

    -
    -

    Name Description

    -

    windbarbs://default(15)[kts] 15 wind intensity with [kts] unit of measure

    -

    windbarbs://default(9)[m/s]?hemisphere=s 9 wind intensity with [m/s] unit of measure, in the south hemisphere

    -
    + + + + + + + + + + + +
    +
      +
    • +
        +
      • Name
      • +
      • Description
      • +
      +
    • +
    • +
        +
      • windbarbs://default(15)[kts]
      • +
      • 15 wind intensity with [kts] unit of measure
      • +
      +
    • +
    • +
        +
      • windbarbs://default(9)[m/s]?hemisphere=s
      • +
      • 9 wind intensity with [m/s] unit of measure, in the south hemisphere
      • +
      +
    • +
  • Custom WKT Shapes

    diff --git a/styling/sld/extensions/randomized/index.html b/styling/sld/extensions/randomized/index.html index 340e12639df..89f13e2a98f 100644 --- a/styling/sld/extensions/randomized/index.html +++ b/styling/sld/extensions/randomized/index.html @@ -2315,15 +2315,42 @@

    Fills with randomized symbols

    Starting with GeoServer 2.4.2 it is possible to generate fills by randomly repeating a symbol in the polygons to be filled. Or, to be more precise, generate the usual texture fill by repeating over and over a tile, whose contents is the random repetition of a fill. The random distribution is stable, so it will be the same across calls and tiles, and it's controlled by the seed used to generate the distribution.

    The random fill is generated by specifying a GraphicFill with a Mark or ExternalGraphic, and then adding vendor options to control how the symbol is randomly repeated. Here is a table with options, default values, and possible values:

    -
    -

    Option Default value Description

    -
    -

    random none Activates random distribution of symbol. Possible values are none, free, grid. none disables random distribution, free generates a completely random distribution, grid will generate a regular grid of positions, and only randomizes the position of the symbol around the cell centers, providing a more even distribution in space

    -

    random-tile-size 256 Size the texture fill tile that will contain the randomly distributed symbols

    -

    random-rotation none Activates random symbol rotation. Possible values are none (no rotation) or free

    -

    random-symbol-count 16 The number of symbols in the tile. The number of symbols actually painted can be lower, as the distribution will ensure no two symbols overlap with each other.

    -

    random-seed 0 The "seed" used to generate the random distribution. Changing this value will result in a different symbol distribution

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    OptionDefault valueDescription
    randomnoneActivates random distribution of symbol. Possible values are none, free, grid. none disables random distribution, free generates a completely random distribution, grid will generate a regular grid of positions, and only randomizes the position of the symbol around the cell centers, providing a more even distribution in space
    random-tile-size256Size the texture fill tile that will contain the randomly distributed symbols
    random-rotationnoneActivates random symbol rotation. Possible values are none (no rotation) or free
    random-symbol-count16The number of symbols in the tile. The number of symbols actually painted can be lower, as the distribution will ensure no two symbols overlap with each other.
    random-seed0The "seed" used to generate the random distribution. Changing this value will result in a different symbol distribution

    Here is an example:

    <sld:PolygonSymbolizer>
      <sld:Fill>
    diff --git a/styling/sld/extensions/rendering-transform/index.html b/styling/sld/extensions/rendering-transform/index.html
    index f8b722b48cd..772fdbec97b 100644
    --- a/styling/sld/extensions/rendering-transform/index.html
    +++ b/styling/sld/extensions/rendering-transform/index.html
    @@ -2551,12 +2551,32 @@
     

    Rendering Transformations

    Rendering Transformations allow processing to be carried out on datasets within the GeoServer rendering pipeline. A typical transformation computes a derived or aggregated result from the input data, allowing various useful visualization effects to be obtained. Transformations may transform data from one format into another (i.e vector to raster or vice-versa), to provide an appropriate format for display.

    The following table lists examples of various kinds of rendering transformations available in GeoServer:

    -
    -

    Type Examples

    -

    Raster-to-Vector Contour extracts contours from a DEM raster. RasterAsPointCollections extracts a vector field from a multi-band raster

    -

    Vector-to-Raster BarnesSurfaceInterpolation computes a surface from scattered data points. Heatmap computes a heatmap surface from weighted data points.

    -

    Vector-to-Vector PointStacker aggregates dense point data into clusters.

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + +
    TypeExamples
    Raster-to-VectorContour extracts contours from a DEM raster. RasterAsPointCollections extracts a vector field from a multi-band raster
    Vector-to-RasterBarnesSurfaceInterpolation computes a surface from scattered data points. Heatmap computes a heatmap surface from weighted data points.
    Vector-to-VectorPointStacker aggregates dense point data into clusters.

    Rendering transformations are invoked within SLD styles. Parameters may be supplied to control the appearance of the output. The rendered output for the layer is produced by applying the styling rules and symbolizers in the SLD to the result of transformation.

    Rendering transformations are implemented using the same mechanism as Process Cookbook. They can thus also be executed via the WPS protocol, if required. Conversely, any WPS process can be executed as a transformation, as long as the input and output are appropriate for use within an SLD.

    This section is a general guide to rendering transformation usage in GeoServer. For details of input, parameters, and output for any particular rendering transformation, refer to its own documentation.

    diff --git a/styling/sld/extensions/substitution/index.html b/styling/sld/extensions/substitution/index.html index 7c37da6e9b9..498fa95a7cf 100644 --- a/styling/sld/extensions/substitution/index.html +++ b/styling/sld/extensions/substitution/index.html @@ -2405,16 +2405,57 @@

    Variable substitution in SLD

    The env function can be used in an SLD anywhere an OGC expression is allowed. For example, it can be used in CSSParameter elements, in size and offset elements, and in rule filter expressions. It is also accepted in some places where full expressions are not allowed, such as in the Mark/WellKnownName element.

    Predefined Variables

    GeoServer has predefined variables which provide information about specific properties of the request output. These are useful when SLD parameters need to depend on output dimensions. The predefined variables are:

    -
    -

    Name Type Description

    -

    wms_bbox ReferencedEnvelope the georeferenced extent of the request output

    -

    wms_crs CoordinateReferenceSystem the definition of the output coordinate reference system

    -

    wms_srs String the code for the output coordinate reference system

    -

    wms_width Integer the width (in pixels) of the output image

    -

    wms_height Integer the height (in pixels) of the output image

    -

    wms_scale_denominator Integer the denominator of the output map scale

    -

    kmlOutputMode Either vector or empty this variable gets set to vector when the kml generator is writing out vector features as placemarks, as opposed to ground overlays

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    NameTypeDescription
    wms_bboxReferencedEnvelopethe georeferenced extent of the request output
    wms_crsCoordinateReferenceSystemthe definition of the output coordinate reference system
    wms_srsStringthe code for the output coordinate reference system
    wms_widthIntegerthe width (in pixels) of the output image
    wms_heightIntegerthe height (in pixels) of the output image
    wms_scale_denominatorIntegerthe denominator of the output map scale
    kmlOutputModeEither vector or emptythis variable gets set to vector when the kml generator is writing out vector features as placemarks, as opposed to ground overlays

    Example

    The following SLD symbolizer has been parameterized in three places, with default values provided in each case:

    <PointSymbolizer>
    diff --git a/styling/sld/extensions/z-order/example/index.html b/styling/sld/extensions/z-order/example/index.html
    index c61d2546acb..382aba128f8 100644
    --- a/styling/sld/extensions/z-order/example/index.html
    +++ b/styling/sld/extensions/z-order/example/index.html
    @@ -2374,18 +2374,57 @@
     

    Z ordering single layer example

    The OpenStreetMap dataset uses extensively a z_order attribute to model the above/below relationships between elements in the real world.

    A small downloadable shapefile is provided that shows a small area with a rich set of different z-orders, where roads and rails go above and below each other. For reference, this is the dataset schema:

    -
    -

    Name Type Notes

    -
    -

    osm_id numeric

    -

    type string The type of the segment, can be "mainroads", "minorroads", "railways", ...

    -

    bridge numeric 0 or 1

    -

    ref numeric 0 or 1

    -

    tunnel numeric

    -

    oneway numeric 0 or 1

    -

    z_order numeric

    -

    class string

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    NameTypeNotes
    osm_idnumeric
    typestringThe type of the segment, can be "mainroads", "minorroads", "railways", ...
    bridgenumeric0 or 1
    refnumeric0 or 1
    tunnelnumeric
    onewaynumeric0 or 1
    z_ordernumeric
    classstring

    The dataset contains several different values for z_order, in particular: -10, -7, -5, -3, -1, 0, 3, 4, 5, 7, 9, 10, 13, 14, 15, 17, 19.

    Here is a sample CSS style using z-ordering, but not groups, to perform the display. Road casing is achieved by multiple FeatureTypeStyle, or z-index values in CSS:

    [class = 'railways' and bridge = 1] {
    diff --git a/styling/sld/extensions/z-order/syntax/index.html b/styling/sld/extensions/z-order/syntax/index.html
    index f859a96cbfc..9cd50c58e4c 100644
    --- a/styling/sld/extensions/z-order/syntax/index.html
    +++ b/styling/sld/extensions/z-order/syntax/index.html
    @@ -2566,38 +2566,98 @@ 

    z-ordering across layers

    Let's consider an example, with a rails layer having two FeatureTypeStyle, one with a group, the other not:

    -
    -

    FeatureTypeStyle id SortByGroup id

    -
    -

    rails1 linework

    -

    rails2 none

    -
    + + + + + + + + + + + + + + + + + +
    FeatureTypeStyle idSortByGroup id
    rails1linework
    rails2none

    We then have a roads layer with two FeatureTypeStyle, both in the same group:

    -
    -

    FeatureTypeStyle id SortByGroup id

    -
    -

    road1 linework

    -

    road2 linework

    -
    + + + + + + + + + + + + + + + + + +
    FeatureTypeStyle idSortByGroup id
    road1linework
    road2linework

    If the WMS request asks for &layers=roads,rails, then the expanded FeatureTypeStyle list will be:

    -
    -

    FeatureTypeStyle id SortByGroup id

    -
    -

    road1 linework

    -

    road2 linework

    -

    rails1 linework

    -

    rails2 none

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + +
    FeatureTypeStyle idSortByGroup id
    road1linework
    road2linework
    rails1linework
    rails2none

    As a result, the road1,road2,rails1 will form a single group, and this will result in the rails be merged with the roads when z-ordering.

    If instead the WMS request asks for &layers=rails,roads````, then the expanded ````FeatureTypeStyle` list will be:

    -
    -

    FeatureTypeStyle id SortByGroup id

    -
    -

    rails1 linework

    -

    rails2 none

    -

    road1 linework

    -

    road2 linework

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + +
    FeatureTypeStyle idSortByGroup id
    rails1linework
    rails2none
    road1linework
    road2linework

    The rails2 feature type style breaks the sequence, as a result, the rails will not be z-ordered in the same group as the roads.

    diff --git a/styling/sld/reference/labeling/index.html b/styling/sld/reference/labeling/index.html index d98a28cb172..c6fb55c8b46 100644 --- a/styling/sld/reference/labeling/index.html +++ b/styling/sld/reference/labeling/index.html @@ -2870,12 +2870,32 @@

    LabelPlacement

    PointPlacement

    When <PointPlacement> is used the geometry is labelled at a single label point. For lines, this point lies at the middle of the visible portion of the line. For polygons, the point is the centroid of the visible portion of the polygon. The position of the label relative to the label point can be controlled by the following sub-elements:

    -
    -

    Element Description

    -

    <AnchorPoint> Determines the placement of the label relative to the label point. Values given as decimals between 0-1.

    -

    <Displacement> Offsets the label from the anchor point. Values given in pixels.

    -

    <Rotation> Rotates the label clockwise by a given number of degrees.

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + +
    ElementDescription
    <AnchorPoint>Determines the placement of the label relative to the label point. Values given as decimals between 0-1.
    <Displacement>Offsets the label from the anchor point. Values given in pixels.
    <Rotation>Rotates the label clockwise by a given number of degrees.

    The best way to explain these options is with examples.

    AnchorPoint

    The anchor point determines where the label is placed relative to the label point.

    @@ -3014,12 +3034,32 @@

    Grouping Features (group)

    <VendorOption name="group">yes</VendorOption>
     

    Grouping works by collecting all features with the same label text, then choosing a representative geometry for the group, according to the following rules:

    -
    -

    Geometry Label Point

    -

    Point Set The first point inside the view rectangle is used.

    -

    Line Set Lines are joined together, clipped to the view rectangle, and the longest path is used.

    -

    Polygon Set Polygons are clipped to the view rectangle, and the largest polygon is used.

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + +
    GeometryLabel Point
    Point SetThe first point inside the view rectangle is used.
    Line SetLines are joined together, clipped to the view rectangle, and the longest path is used.
    Polygon SetPolygons are clipped to the view rectangle, and the largest polygon is used.

    If desired the labeller can be forced to label every element in a group by specifying the labelAllGroup option.

    Warning

    @@ -3096,12 +3136,32 @@

    conflictResolution

    goodnessOfFit

    GeoServer will remove labels if they are a particularly bad fit for the geometry they are labeling.

    -
    -

    Geometry Goodness of Fit Algorithm

    -

    Point Always returns 1.0 since the label is at the point

    -

    Line Always returns 1.0 since the label is always placed on the line.

    -

    Polygon The label is sampled approximately at every letter. The distance from these points to the polygon is determined and each sample votes based on how close it is to the polygon. (see LabelCacheDefault#goodnessOfFit())

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + +
    GeometryGoodness of Fit Algorithm
    PointAlways returns 1.0 since the label is at the point
    LineAlways returns 1.0 since the label is always placed on the line.
    PolygonThe label is sampled approximately at every letter. The distance from these points to the polygon is determined and each sample votes based on how close it is to the polygon. (see LabelCacheDefault#goodnessOfFit())

    The default value is 0.5, but it can be modified using:

    <VendorOption name="goodnessOfFit">0.3</VendorOption>
     
    @@ -3109,22 +3169,62 @@

    polygonAlign

    GeoServer normally tries to place labels horizontally within a polygon, and gives up if the label position is busy or if the label does not fit enough in the polygon. This option allows GeoServer to try alternate rotations for the labels.

    <VendorOption name="polygonAlign">mbr</VendorOption>
     
    -
    -

    Option Description

    -

    manual The default value. Only a rotation manually specified in the <Rotation> tag will be used

    -

    ortho If the label does not fit horizontally and the polygon is taller than wider then vertical alignment will also be tried

    -

    mbr If the label does not fit horizontally the minimum bounding rectangle will be computed and a label aligned to it will be tried out as well

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + +
    OptionDescription
    manualThe default value. Only a rotation manually specified in the <Rotation> tag will be used
    orthoIf the label does not fit horizontally and the polygon is taller than wider then vertical alignment will also be tried
    mbrIf the label does not fit horizontally the minimum bounding rectangle will be computed and a label aligned to it will be tried out as well

    graphic-resize

    When a <Graphic> is specified for a label by default it is displayed at its native size and aspect ratio. The graphic-resize option instructs the renderer to magnify or stretch the graphic to fully contain the text of the label. If this option is used the graphic-margin option may also be specified.

    <VendorOption name="graphic-resize">stretch</VendorOption>
     
    -
    -

    Option Description

    -

    none Graphic is displayed at its native size (default)

    -

    proportional Graphic size is increased uniformly to contain the label text

    -

    stretch Graphic size is increased anisotropically to contain the label text

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + +
    OptionDescription
    noneGraphic is displayed at its native size (default)
    proportionalGraphic size is increased uniformly to contain the label text
    stretchGraphic size is increased anisotropically to contain the label text

    no-border

    diff --git a/styling/sld/reference/layers/index.html b/styling/sld/reference/layers/index.html index f7456a90bb4..8d8fd8a2c14 100644 --- a/styling/sld/reference/layers/index.html +++ b/styling/sld/reference/layers/index.html @@ -2373,23 +2373,81 @@

    Layers

    NamedLayer

    A NamedLayer specifies an existing layer to be styled, and the styling to apply to it. The styling may be any combination of catalog styles and explicitly-defined styles. If no style is specified, the default style for the layer is used.

    The <NamedLayer> element contains the following elements:

    -
    -

    Tag Required? Description

    -

    <Name> Yes The name of the layer to be styled. (Ignored in catalog styles.)

    -

    <Description> No The description for the layer.

    -

    <NamedStyle> 0..N The name of a catalog style to apply to the layer.

    -

    <UserStyle> 0..N The definition of a style to apply to the layer. See Styles

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    TagRequired?Description
    <Name>YesThe name of the layer to be styled. (Ignored in catalog styles.)
    <Description>NoThe description for the layer.
    <NamedStyle>0..NThe name of a catalog style to apply to the layer.
    <UserStyle>0..NThe definition of a style to apply to the layer. See Styles

    UserLayer

    A UserLayer defines a new layer to be styled, and the styling to apply to it. The data for the layer is provided directly in the layer definition using the <InlineFeature> element. Since the layer is not known to the server, the styling must be explicitly specified as well.

    The <UserLayer> element contains the following elements:

    -
    -

    Tag Required? Description

    -

    <Name> No The name for the layer being defined

    -

    <Description> No The description for the layer

    -

    <InlineFeature> No One or more feature collections providing the layer data, specified using GML.

    -

    <UserStyle> 1..N The definition of the style(s) to use for the layer. See Styles

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    TagRequired?Description
    <Name>NoThe name for the layer being defined
    <Description>NoThe description for the layer
    <InlineFeature>NoOne or more feature collections providing the layer data, specified using GML.
    <UserStyle>1..NThe definition of the style(s) to use for the layer. See Styles

    A common use is to define a geometry to be rendered to indicate an Area Of Interest.

    InlineFeature

    An InlineFeature element contains data defining a layer to be styled. The element contains one or more <FeatureCollection> elements defining the data. Each Feature Collection can contain any number of <featureMember> elements, each containing a feature specified using GML markup. The features can contain any type of geometry (point, line or polygon, and collections of these). They may also contain scalar-valued attributes, which can be useful for labelling.

    diff --git a/styling/sld/reference/linesymbolizer/index.html b/styling/sld/reference/linesymbolizer/index.html index fbd491a6421..04a7e7c3196 100644 --- a/styling/sld/reference/linesymbolizer/index.html +++ b/styling/sld/reference/linesymbolizer/index.html @@ -2480,23 +2480,73 @@

    LineSymbolizer

    A LineSymbolizer styles features as lines. Lines are one-dimensional geometries that have both position and length. Each line is comprised of one or more line segments, and has either two ends or none (if it is closed).

    Syntax

    A <LineSymbolizer> contains an optional <Geometry> element, and a required <Stroke> element specifying the line symbology.

    -
    -

    Tag Required? Description

    -

    <Geometry> No Specifies the geometry to be rendered.

    -

    <Stroke> Yes Specifies the styling for the line.

    -

    <PerpendicularOffset> No Specifies the perpendicular offset for the current line

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    TagRequired?Description
    <Geometry>NoSpecifies the geometry to be rendered.
    <Stroke>YesSpecifies the styling for the line.
    <PerpendicularOffset>NoSpecifies the perpendicular offset for the current line

    Geometry

    The <Geometry> element is optional. If present, it specifies the featuretype property from which to obtain the geometry to style using the PropertyName element. See also Geometry transformations in SLD for GeoServer extensions for specifying geometry.

    Any kind of geometry may be styled with a <LineSymbolizer>. Point geometries are treated as lines of zero length, with a horizontal orientation. For polygonal geometries the boundary (or boundaries) are used as the lines, each line being a closed ring with no ends.

    Stroke

    The <Stroke> element specifies the styling of a line. There are three elements that can be included inside the <Stroke> element.

    -
    -

    Tag Required? Description

    -

    <GraphicFill> No Renders the pixels of the line with a repeated pattern.

    -

    <GraphicStroke> No Renders the line with a repeated linear graphic.

    -

    <CssParameter> 0..N Determines the stroke styling parameters.

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    TagRequired?Description
    <GraphicFill>NoRenders the pixels of the line with a repeated pattern.
    <GraphicStroke>NoRenders the line with a repeated linear graphic.
    <CssParameter>0..NDetermines the stroke styling parameters.

    GraphicFill

    The <GraphicFill> element specifies that the pixels of the line are to be filled with a repeating graphic image or symbol. The graphic is specified by a <Graphic> sub-element, which is described in the PointSymbolizer Graphic section.

    GraphicStroke

    @@ -2506,16 +2556,57 @@

    CssParameter

    The <CssParameter> elements describe the basic styling of the line. Any number of <CssParameter> elements can be specified.

    The name attribute indicates what aspect of styling an element specifies, using the standard CSS/SVG styling model. The content of the element supplies the value of the styling parameter. The value may contain expressions.

    The following parameters are supported:

    -
    -

    Parameter Required? Description

    -

    name="stroke" No Specifies the solid color given to the line, in the form #RRGGBB. Default is black (#000000).

    -

    name="stroke-width" No Specifies the width of the line in pixels. Default is 1.

    -

    name="stroke-opacity" No Specifies the opacity (transparency) of the line. The value is a number are between 0 (completely transparent) and 1 (completely opaque). Default is 1.

    -

    name="stroke-linejoin" No Determines how lines are rendered at intersections of line segments. Possible values are mitre (sharp corner), round (rounded corner), and bevel (diagonal corner). Default is mitre.

    -

    name="stroke-linecap" No Determines how lines are rendered at their ends. Possible values are butt (sharp square edge), round (rounded edge), and square (slightly elongated square edge). Default is butt.

    -

    name="stroke-dasharray" No Encodes a dash pattern as a series of numbers separated by spaces. Odd-indexed numbers (first, third, etc) determine the length in pxiels to draw the line, and even-indexed numbers (second, fourth, etc) determine the length in pixels to blank out the line. Default is an unbroken line. Starting from version 2.1 dash arrays can be combined with graphic strokes to generate complex line styles with alternating symbols or a mix of lines and symbols.

    -

    name="stroke-dashoffset" No Specifies the distance in pixels into the dasharray pattern at which to start drawing. Default is 0.

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ParameterRequired?Description
    name="stroke"NoSpecifies the solid color given to the line, in the form #RRGGBB. Default is black (#000000).
    name="stroke-width"NoSpecifies the width of the line in pixels. Default is 1.
    name="stroke-opacity"NoSpecifies the opacity (transparency) of the line. The value is a number are between 0 (completely transparent) and 1 (completely opaque). Default is 1.
    name="stroke-linejoin"NoDetermines how lines are rendered at intersections of line segments. Possible values are mitre (sharp corner), round (rounded corner), and bevel (diagonal corner). Default is mitre.
    name="stroke-linecap"NoDetermines how lines are rendered at their ends. Possible values are butt (sharp square edge), round (rounded edge), and square (slightly elongated square edge). Default is butt.
    name="stroke-dasharray"NoEncodes a dash pattern as a series of numbers separated by spaces. Odd-indexed numbers (first, third, etc) determine the length in pxiels to draw the line, and even-indexed numbers (second, fourth, etc) determine the length in pixels to blank out the line. Default is an unbroken line. Starting from version 2.1 dash arrays can be combined with graphic strokes to generate complex line styles with alternating symbols or a mix of lines and symbols.
    name="stroke-dashoffset"NoSpecifies the distance in pixels into the dasharray pattern at which to start drawing. Default is 0.

    PerpendicularOffset

    The <PerpendicularOffset> element is optional. It is native to the SE 1.1 specification, but supported also in SLD 1.0 as a vendor extension.

    If present, it makes the renderer draw a line parallel to the original one, at the given distance. When applied on lines, positive values generate a parallel line on the left hand side, negative values on the right hand side. When applied on polygons instead, positive is interpreted as outwards, negative as inwards.

    diff --git a/styling/sld/reference/pointsymbolizer/index.html b/styling/sld/reference/pointsymbolizer/index.html index 260987938e3..01ecfe8abba 100644 --- a/styling/sld/reference/pointsymbolizer/index.html +++ b/styling/sld/reference/pointsymbolizer/index.html @@ -2426,42 +2426,142 @@

    PointSymbolizer

    A PointSymbolizer styles features as points. Points are depicted as graphic symbols at a single location on the map.

    Syntax

    A <PointSymbolizer> contains an optional <Geometry> element, and a required <Graphic> element specifying the point symbology.

    -
    -

    Tag Required? Description

    -

    <Geometry> No Specifies the geometry to be rendered.

    -

    <Graphic> Yes Specifies the styling for the point symbol.

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + +
    TagRequired?Description
    <Geometry>NoSpecifies the geometry to be rendered.
    <Graphic>YesSpecifies the styling for the point symbol.

    Geometry

    The <Geometry> element is optional. If present, it specifies the featuretype property from which to obtain the geometry to style using a <PropertyName> element. See also Geometry transformations in SLD for GeoServer extensions for specifying geometry.

    Any kind of geometry may be styled with a <PointSymbolizer>. For non-point geometries, a representative point is used (such as the centroid of a line or polygon).

    Graphic

    Symbology is specified using a <Graphic> element. The symbol is specified by either an <ExternalGraphic> or a <Mark> element. External Graphics are image files (in a format such as PNG or SVG) that contain the shape and color information defining how to render a symbol. Marks are vector shapes whose stroke and fill are defined explicitly in the symbolizer.

    There are five possible sub-elements of the <Graphic> element. One of <ExternalGraphic> or <Mark> must be specified; the others are optional.

    -
    -

    Tag Required? Description

    -

    <ExternalGraphic> No (when using <Mark>) Specifies an external image file to use as the symbol.

    -

    <Mark> No (when using <ExternalGraphic>) Specifies a named shape to use as the symbol.

    -

    <Opacity> No Specifies the opacity (transparency) of the symbol. Values range from 0 (completely transparent) to 1 (completely opaque). Value may contain expressions. Default is 1 (opaque).

    -

    <Size> No Specifies the size of the symbol, in pixels. When used with an image file, this specifies the height of the image, with the width being scaled accordingly. if omitted the native symbol size is used. Value may contain expressions.

    -

    <Rotation> No Specifies the rotation of the symbol about its center point, in decimal degrees. Positive values indicate rotation in the clockwise direction, negative values indicate counter-clockwise rotation. Value may contain expressions. Default is 0.

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    TagRequired?Description
    <ExternalGraphic>No (when using <Mark>)Specifies an external image file to use as the symbol.
    <Mark>No (when using <ExternalGraphic>)Specifies a named shape to use as the symbol.
    <Opacity>NoSpecifies the opacity (transparency) of the symbol. Values range from 0 (completely transparent) to 1 (completely opaque). Value may contain expressions. Default is 1 (opaque).
    <Size>NoSpecifies the size of the symbol, in pixels. When used with an image file, this specifies the height of the image, with the width being scaled accordingly. if omitted the native symbol size is used. Value may contain expressions.
    <Rotation>NoSpecifies the rotation of the symbol about its center point, in decimal degrees. Positive values indicate rotation in the clockwise direction, negative values indicate counter-clockwise rotation. Value may contain expressions. Default is 0.

    ExternalGraphic

    External Graphics are image files (in formats such as PNG or SVG) that contain the shape and color information defining how to render a symbol. For GeoServer extensions for specifying external graphics, see Graphic symbology in GeoServer.

    The <ExternalGraphic> element has the sub-elements:

    -
    -

    Tag Required? Description

    -

    <OnlineResource> Yes The xlink:href attribute specifies the location of the image file. The value can be either a URL or a local pathname relative to the SLD directory. The value can contain CQL expressions delimited by ${ }. The attribute xlink:type="simple" is also required. The element does not contain any content.

    -

    <Format> Yes The MIME type of the image format. Most standard web image formats are supported. Common MIME types are image/png, image/jpeg, image/gif, and image/svg+xml

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + +
    TagRequired?Description
    <OnlineResource>YesThe xlink:href attribute specifies the location of the image file. The value can be either a URL or a local pathname relative to the SLD directory. The value can contain CQL expressions delimited by ${ }. The attribute xlink:type="simple" is also required. The element does not contain any content.
    <Format>YesThe MIME type of the image format. Most standard web image formats are supported. Common MIME types are image/png, image/jpeg, image/gif, and image/svg+xml

    Mark

    Marks are predefined vector shapes identified by a well-known name. Their fill and stroke can be defined explicitly in the SLD. For GeoServer extensions for specifying mark symbols, see Graphic symbology in GeoServer.

    The <Mark> element has the sub-elements:

    -
    -

    Tag Required? Description

    -

    <WellKnownName> No The name of the shape. Standard SLD shapes are circle, square, triangle, star, cross, or x. Default is square.

    -

    <Fill> No Specifies how the symbol should be filled (for closed shapes). Options are to use <CssParameter name="fill"> to specify a solid fill color, or using <GraphicFill> for a tiled graphic fill. See the PolygonSymbolizer Fill for the full syntax.

    -

    <Stroke> No Specifies how the symbol linework should be drawn. Some options are using <CssParameter name="stroke"> to specify a stroke color, or using <GraphicStroke> for a repeated graphic. See the LineSymbolizer Stroke for the full syntax.

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    TagRequired?Description
    <WellKnownName>NoThe name of the shape. Standard SLD shapes are circle, square, triangle, star, cross, or x. Default is square.
    <Fill>NoSpecifies how the symbol should be filled (for closed shapes). Options are to use <CssParameter name="fill"> to specify a solid fill color, or using <GraphicFill> for a tiled graphic fill. See the PolygonSymbolizer Fill for the full syntax.
    <Stroke>NoSpecifies how the symbol linework should be drawn. Some options are using <CssParameter name="stroke"> to specify a stroke color, or using <GraphicStroke> for a repeated graphic. See the LineSymbolizer Stroke for the full syntax.

    Example

    The following symbolizer is taken from the Points section in the SLD Cookbook.

    <PointSymbolizer>
    diff --git a/styling/sld/reference/polygonsymbolizer/index.html b/styling/sld/reference/polygonsymbolizer/index.html
    index 4002db32cc6..9540336ab3f 100644
    --- a/styling/sld/reference/polygonsymbolizer/index.html
    +++ b/styling/sld/reference/polygonsymbolizer/index.html
    @@ -2426,12 +2426,37 @@ 

    PolygonSymbolizer

    A PolygonSymbolizer styles features as polygons. Polygons are two-dimensional geometries. They can be depicted with styling for their interior (fill) and their border (stroke). Polygons may contain one or more holes, which are stroked but not filled. When rendering a polygon, the fill is rendered before the border is stroked.

    Syntax

    A <PolygonSymbolizer> contains an optional <Geometry> element, and two elements <Fill> and <Stroke> for specifying styling:

    -
    -

    Tag Required? Description

    -

    <Geometry> No Specifies the geometry to be rendered.

    -

    <Fill> No Specifies the styling for the polygon interior.

    -

    <Stroke> No Specifies the styling for the polygon border.

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    TagRequired?Description
    <Geometry>NoSpecifies the geometry to be rendered.
    <Fill>NoSpecifies the styling for the polygon interior.
    <Stroke>NoSpecifies the styling for the polygon border.

    Geometry

    The <Geometry> element is optional. If present, it specifies the featuretype property from which to obtain the geometry to style using the PropertyName element. See also Geometry transformations in SLD for GeoServer extensions for specifying geometry.

    Any kind of geometry may be styled with a <PolygonSymbolizer>. Point geometries are treated as small orthonormal square polygons. Linear geometries are closed by joining their ends.

    @@ -2439,22 +2464,64 @@

    Stroke

    The <Stroke> element specifies the styling for the border of a polygon. The syntax is described in the <LineSymbolizer> Stroke section.

    Fill

    The <Fill> element specifies the styling for the interior of a polygon. It can contain the sub-elements:

    -
    -

    Tag Required? Description

    -

    <GraphicFill> No Renders the fill of the polygon with a repeated pattern.

    -

    <CssParameter> 0..N Specifies parameters for filling with a solid color.

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + +
    TagRequired?Description
    <GraphicFill>NoRenders the fill of the polygon with a repeated pattern.
    <CssParameter>0..NSpecifies parameters for filling with a solid color.

    GraphicFill

    The <GraphicFill> element contains a <Graphic> element, which specifies a graphic image or symbol to use for a repeated fill pattern. The syntax is described in the PointSymbolizer Graphic section.

    CssParameter

    The <CssParameter> elements describe the styling of a solid polygon fill. Any number of <CssParameter> elements can be specified.

    The name attribute indicates what aspect of styling an element specifies, using the standard CSS/SVG styling model. The content of the element supplies the value of the styling parameter. The value may contain expressions.

    The following parameters are supported:

    -
    -

    Parameter Required? Description

    -

    name="fill" No Specifies the fill color, in the form #RRGGBB. Default is grey (#808080).

    -

    name="fill-opacity" No Specifies the opacity (transparency) of the fill. The value is a decimal number between 0 (completely transparent) and 1 (completely opaque). Default is 1.

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + +
    ParameterRequired?Description
    name="fill"NoSpecifies the fill color, in the form #RRGGBB. Default is grey (#808080).
    name="fill-opacity"NoSpecifies the opacity (transparency) of the fill. The value is a decimal number between 0 (completely transparent) and 1 (completely opaque). Default is 1.

    Example

    The following symbolizer is taken from the Polygons section in the SLD Cookbook.

    <PolygonSymbolizer>
    diff --git a/styling/sld/reference/rules/index.html b/styling/sld/reference/rules/index.html
    index f52167c4cf1..f19a4f082c8 100644
    --- a/styling/sld/reference/rules/index.html
    +++ b/styling/sld/reference/rules/index.html
    @@ -2360,20 +2360,77 @@ 

    Rules

    Styling rules define the portrayal of features. A rule combines a filter with any number of symbolizers. Features for which the filter condition evaluates as true are rendered using the symbolizers in the rule.

    Syntax

    The <Rule> element contains the following elements:

    -
    -

    Tag Required? Description

    -

    <Name> No Specifies a name for the rule.

    -

    <Title> No Specifies a title for the rule. The title is used in display lists and legends.

    -

    <Abstract> No Specifies an abstract describing the rule.

    -

    <Filter> No Specifies a filter controlling when the rule is applied. See Filters

    -

    <MinScaleDenominator> No Specifies the minimum scale denominator (inclusive) for the scale range in which this rule applies. If present, the rule applies at the given scale and all smaller scales.

    -

    <MaxScaleDenominator> No Specifies the maximum scale denominator (exclusive) for the scale range in which this rule applies. If present, the rule applies at scales larger than the given scale.

    -

    <PointSymbolizer> 0..N Specifies styling as points. See PointSymbolizer

    -

    <LineSymbolizer> 0..N Specifies styling as lines. See LineSymbolizer

    -

    <PolygonSymbolizer> 0..N Specifies styling as polygons. See PolygonSymbolizer

    -

    <TextSymbolizer> 0..N Specifies styling for text labels. See TextSymbolizer

    -

    <RasterSymbolizer> 0..N Specifies styling for raster data. See RasterSymbolizer

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    TagRequired?Description
    <Name>NoSpecifies a name for the rule.
    <Title>NoSpecifies a title for the rule. The title is used in display lists and legends.
    <Abstract>NoSpecifies an abstract describing the rule.
    <Filter>NoSpecifies a filter controlling when the rule is applied. See Filters
    <MinScaleDenominator>NoSpecifies the minimum scale denominator (inclusive) for the scale range in which this rule applies. If present, the rule applies at the given scale and all smaller scales.
    <MaxScaleDenominator>NoSpecifies the maximum scale denominator (exclusive) for the scale range in which this rule applies. If present, the rule applies at scales larger than the given scale.
    <PointSymbolizer>0..NSpecifies styling as points. See PointSymbolizer
    <LineSymbolizer>0..NSpecifies styling as lines. See LineSymbolizer
    <PolygonSymbolizer>0..NSpecifies styling as polygons. See PolygonSymbolizer
    <TextSymbolizer>0..NSpecifies styling for text labels. See TextSymbolizer
    <RasterSymbolizer>0..NSpecifies styling for raster data. See RasterSymbolizer

    Scale Selection

    Rules support scale selection to allow specifying the scale range in which a rule may be applied (assuming the filter condition is satisfied as well, if present). Scale selection allows for varying portrayal of features at different map scales. In particular, at smaller scales it is common to use simpler styling for features, or even prevent the display of some features altogether.

    Scale ranges are specified by using scale denominators. These values correspond directly to the ground distance covered by a map, but are inversely related to the common "large" and "small" terminology for map scale. In other words:

    @@ -2382,11 +2439,32 @@

    Scale Selection

  • small scale maps cover more area and have a larger scale denominator
  • Two optional elements specify the scale range for a rule:

    -
    -

    Tag Required? Description

    -

    <MinScaleDenominator> No Specifies the minimum scale denominator (inclusive) for the scale range in which this rule applies. If present, the rule applies at the given scale and all smaller scales.

    -

    <MaxScaleDenominator> No Specifies the maximum scale denominator (exclusive) for the scale range in which this rule applies. If present, the rule applies at scales larger than the given scale.

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + +
    TagRequired?Description
    <MinScaleDenominator>NoSpecifies the minimum scale denominator (inclusive) for the scale range in which this rule applies. If present, the rule applies at the given scale and all smaller scales.
    <MaxScaleDenominator>NoSpecifies the maximum scale denominator (exclusive) for the scale range in which this rule applies. If present, the rule applies at scales larger than the given scale.

    Note

    The current scale can also be obtained via the wms_scale_denominator SLD environment variable. This allows including scale dependency in Filter Expressions.

    diff --git a/styling/sld/reference/sld/index.html b/styling/sld/reference/sld/index.html index 15d059ad679..48c51c4abf7 100644 --- a/styling/sld/reference/sld/index.html +++ b/styling/sld/reference/sld/index.html @@ -2249,11 +2249,32 @@

    StyledLayerDescriptor

    The root element for an SLD is <StyledLayerDescriptor>. It contains a sequence of Layers defining the styled map content.

    The <StyledLayerDescriptor> element contains the following elements:

    -
    -

    Tag Required? Description

    -

    <NamedLayer> 0..N A reference to a named layer in the server catalog

    -

    <UserLayer> 0..N A layer defined in the style itself

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + +
    TagRequired?Description
    <NamedLayer>0..NA reference to a named layer in the server catalog
    <UserLayer>0..NA layer defined in the style itself
    diff --git a/styling/sld/reference/styles/index.html b/styling/sld/reference/styles/index.html index ac26861ed62..3250d32c145 100644 --- a/styling/sld/reference/styles/index.html +++ b/styling/sld/reference/styles/index.html @@ -2325,25 +2325,91 @@

    Styles

    UserStyle

    The UserStyle element defines styling for a layer.

    The <UserStyle> element contains the following elements:

    -
    -

    Tag Required? Description

    -

    <Name> No The name of the style, used to reference it externally. (Ignored for catalog styles.)

    -

    <Title> No The title of the style.

    -

    <Abstract> No The description for the style.

    -

    <IsDefault> No Whether the style is the default one for a named layer. Used in SLD Library Mode. Values are 1 or 0 (default).

    -

    <FeatureTypeStyle> 1..N Defines the symbology for rendering a single feature type.

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    TagRequired?Description
    <Name>NoThe name of the style, used to reference it externally. (Ignored for catalog styles.)
    <Title>NoThe title of the style.
    <Abstract>NoThe description for the style.
    <IsDefault>NoWhether the style is the default one for a named layer. Used in SLD Library Mode. Values are 1 or 0 (default).
    <FeatureTypeStyle>1..NDefines the symbology for rendering a single feature type.

    FeatureTypeStyle

    The FeatureTypeStyle element specifies the styling that is applied to a single feature type of a layer. It contains a list of rules which determine the symbology to be applied to each feature of a layer.

    The <FeatureTypeStyle> element contains the following elements:

    -
    -

    Tag Required? Description

    -

    <Name> No Not used at present

    -

    <Title> No The title for the style.

    -

    <Abstract> No The description for the style.

    -

    <FeatureTypeName> No Identifies the feature type the style is to be applied to. Omitted if the style applies to all features in a layer.

    -

    <Rule> 1..N A styling rule to be evaluated. See Rules

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    TagRequired?Description
    <Name>NoNot used at present
    <Title>NoThe title for the style.
    <Abstract>NoThe description for the style.
    <FeatureTypeName>NoIdentifies the feature type the style is to be applied to. Omitted if the style applies to all features in a layer.
    <Rule>1..NA styling rule to be evaluated. See Rules

    Usually a layer contains only a single feature type, so the <FeatureTypeName> is omitted.

    Any number of <FeatureTypeStyle> elements can be specified in a style. In GeoServer each one is rendered into a separate image buffer. After all features are rendered the buffers are composited to form the final layer image. The compositing is done in the order the FeatureTypeStyles are given in the SLD, with the first one on the bottom (the "Painter's Model"). This effectively creates "virtual layers", which can be used to achieve styling effects such as cased lines.

    diff --git a/styling/sld/reference/textsymbolizer/index.html b/styling/sld/reference/textsymbolizer/index.html index a7dc898d6dc..01f8279d194 100644 --- a/styling/sld/reference/textsymbolizer/index.html +++ b/styling/sld/reference/textsymbolizer/index.html @@ -2517,18 +2517,67 @@

    TextSymbolizer

    Labelling is a complex operation, and effective labelling is crucial to obtaining legible and visually pleasing cartographic output. For this reason SLD provides many options to control label placement. To improve quality even more GeoServer provides additional options and parameters. The usage of the standard and extended options are described in greater detail in the following section on Labeling.

    Syntax

    A <TextSymbolizer> contains the following elements:

    -
    -

    Tag Required? Description

    -

    <Geometry> No The geometry to be labelled.

    -

    <Label> No The text content for the label.

    -

    <Font> No The font information for the label.

    -

    <LabelPlacement> No Sets the position of the label relative to its associated geometry.

    -

    <Halo> No Creates a colored background around the label text, for improved legibility.

    -

    <Fill> No The fill style of the label text.

    -

    <Graphic> No A graphic to be displayed behind the label text. See Graphic for content syntax.

    -

    <Priority> No The priority of the label during conflict resolution. Content may contains expressions. See also Priority Labeling.

    -

    <VendorOption> 0..N A GeoServer-specific option. See Labeling for descriptions of the available options. Any number of options may be specified.

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    TagRequired?Description
    <Geometry>NoThe geometry to be labelled.
    <Label>NoThe text content for the label.
    <Font>NoThe font information for the label.
    <LabelPlacement>NoSets the position of the label relative to its associated geometry.
    <Halo>NoCreates a colored background around the label text, for improved legibility.
    <Fill>NoThe fill style of the label text.
    <Graphic>NoA graphic to be displayed behind the label text. See Graphic for content syntax.
    <Priority>NoThe priority of the label during conflict resolution. Content may contains expressions. See also Priority Labeling.
    <VendorOption>0..NA GeoServer-specific option. See Labeling for descriptions of the available options. Any number of options may be specified.

    Geometry

    The <Geometry> element is optional. If present, it specifies the featuretype property from which to obtain the geometry to label, using a <PropertyName> element. See also Geometry transformations in SLD for GeoServer extensions for specifying geometry.

    Any kind of geometry may be labelled with a <TextSymbolizer>. For non-point geometries, a representative point is used (such as the centroid of a line or polygon).

    @@ -2542,44 +2591,152 @@

    Font

    + + - +Parameter +Required? +Description + + +name="font-family" +No +The family name of the font to use for the label. Default is Times. + + +name="font-style" +No +The style of the font. Options are normal, italic, and oblique. Default is normal. + + +name="font-weight" +No +The weight of the font. Options are normal and bold. Default is normal. + + +name="font-size" +No +The size of the font in pixels. Default is 10.

    LabelPlacement

    The <LabelPlacement> element specifies the placement of the label relative to the geometry being labelled. There are two possible sub-elements: <PointPlacement> or <LinePlacement>. Exactly one of these must be specified.

    -
    -

    Tag Required? Description

    -

    <PointPlacement> No Labels a geometry at a single point

    -

    <LinePlacement> No Labels a geometry along a linear path

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + +
    TagRequired?Description
    <PointPlacement>NoLabels a geometry at a single point
    <LinePlacement>NoLabels a geometry along a linear path

    PointPlacement

    The <PointPlacement> element indicates the label is placed at a labelling point derived from the geometry being labelled. The position of the label relative to the labelling point may be controlled by the following sub-elements:

    -
    -

    Tag Required? Description

    -

    <AnchorPoint> No The location within the label bounding box that is aligned with the label point. The location is specified by <AnchorPointX> and <AnchorPointY> sub-elements, with values in the range [0..1]. Values may contain expressions.

    -

    <Displacement> No Specifies that the label point should be offset from the original point. The offset is specified by <DisplacementX> and <DisplacementY> sub-elements, with values in pixels. Values may contain expressions. Default is (0, 0).

    -

    <Rotation> No The rotation of the label in clockwise degrees (negative values are counterclockwise). Value may contain expressions. Default is 0.

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    TagRequired?Description
    <AnchorPoint>NoThe location within the label bounding box that is aligned with the label point. The location is specified by <AnchorPointX> and <AnchorPointY> sub-elements, with values in the range [0..1]. Values may contain expressions.
    <Displacement>NoSpecifies that the label point should be offset from the original point. The offset is specified by <DisplacementX> and <DisplacementY> sub-elements, with values in pixels. Values may contain expressions. Default is (0, 0).
    <Rotation>NoThe rotation of the label in clockwise degrees (negative values are counterclockwise). Value may contain expressions. Default is 0.

    The anchor point justification, displacement offsetting, and rotation are applied in that order.

    LinePlacement

    The <LinePlacement> element indicates the label is placed along a linear path derived from the geometry being labelled. The position of the label relative to the linear path may be controlled by the following sub-element:

    -
    -

    Tag Required? Description

    -

    <PerpendicularOffset> No The offset from the linear path, in pixels. Positive values offset to the left of the line, negative to the right. Value may contain expressions. Default is 0.

    -
    + + + + + + + + + + + + + + + + + + + + +
    TagRequired?Description
    <PerpendicularOffset>NoThe offset from the linear path, in pixels. Positive values offset to the left of the line, negative to the right. Value may contain expressions. Default is 0.

    The appearance of text along linear paths can be further controlled by the vendor options followLine, maxDisplacement, repeat, labelAllGroup, and maxAngleDelta. These are described in Labeling.

    Halo

    A halo creates a colored background around the label text, which improves readability in low contrast situations. Within the <Halo> element there are two sub-elements which control the appearance of the halo:

    -
    -

    Tag Required? Description

    -

    <Radius> No The halo radius, in pixels. Value may contain expressions. Default is 1.

    -

    <Fill> No The color and opacity of the halo via CssParameter elements for fill and fill-opacity. See Fill for full syntax. The parameter values may contain expressions. Default is a white fill (#FFFFFF) at 100% opacity.

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + +
    TagRequired?Description
    <Radius>NoThe halo radius, in pixels. Value may contain expressions. Default is 1.
    <Fill>NoThe color and opacity of the halo via CssParameter elements for fill and fill-opacity. See Fill for full syntax. The parameter values may contain expressions. Default is a white fill (#FFFFFF) at 100% opacity.

    Fill

    The <Fill> element specifies the fill style for the label text. The syntax is the same as that of the PolygonSymbolizer Fill element. The default fill color is black (#FFFFFF) at 100% opacity..

    Graphic

    diff --git a/styling/webadmin/index.html b/styling/webadmin/index.html index e3ec89ee259..f2c3641a7cb 100644 --- a/styling/webadmin/index.html +++ b/styling/webadmin/index.html @@ -1965,14 +1965,32 @@

    Style Editor

    Style Editor tabs

    At the bottom of the Style Editor page is a number of options:

    -
    -

    Option Description

    -
    -

    Validate Will test the current style for correctness according to the Format option selected. For SLD styles, it will check compliance against the SLD schema. Mind, the parser might be able to read and work with a formally incorrect style.

    -

    Save Makes the changes to the style and returns to the Styles page

    -

    Apply Makes the changes to the style and remain on the Style Editor page. This is useful to update the Layer Preview tab.

    -

    Cancel Cancels all changes to the style and returns to the Styles page

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + +
    OptionDescription
    ValidateWill test the current style for correctness according to the Format option selected. For SLD styles, it will check compliance against the SLD schema. Mind, the parser might be able to read and work with a formally incorrect style.
    SaveMakes the changes to the style and returns to the Styles page
    ApplyMakes the changes to the style and remain on the Style Editor page. This is useful to update the Layer Preview tab.
    CancelCancels all changes to the style and returns to the Styles page

    Style Editor options

    Style definition

    @@ -1980,20 +1998,56 @@

    Style definition

    Style editor

    The style editor supports line numbering, automatic indentation, and real-time syntax highlighting. You can also increase or decrease the font size of the editor.

    -
    -

    Button Description

    -
    -

    image Undo

    -

    image Redo

    -

    image Go to line

    -

    image Find in style text (CTRL-F)

    -

    image Find next occurrence in style text (CTRL-G/Cmd-G)

    -

    image Find and replace in style text (CTRL-SHIFT-F/Cmd-Option-F). First enter the search term, press ENTER, then type the replace term and press ENTER again. It is also possible to run "replace all" using CTRL-SHIFT-R/Cmd-Shift-Option-F.

    -

    image Auto-format the editor contents

    -

    image Change the font size in the editor

    -

    image Insert image into style (choose existing or upload)

    -

    image Change height of style editor (disabled in full screen mode)

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ButtonDescription
    imageUndo
    imageRedo
    imageGo to line
    imageFind in style text (CTRL-F)
    imageFind next occurrence in style text (CTRL-G/Cmd-G)
    imageFind and replace in style text (CTRL-SHIFT-F/Cmd-Option-F). First enter the search term, press ENTER, then type the replace term and press ENTER again. It is also possible to run "replace all" using CTRL-SHIFT-R/Cmd-Shift-Option-F.
    imageAuto-format the editor contents
    imageChange the font size in the editor
    imageInsert image into style (choose existing or upload)
    imageChange height of style editor (disabled in full screen mode)

    During editing and especially after editing is complete, you will want to check validation of the syntax. This can be done by clicking the Validate button at the bottom.

    If no errors are found, you will see this message:

    @@ -2004,53 +2058,134 @@

    Style definition

    Style Editor: Data tab

    The Data tab includes basic style information, the ability to generate a style, and legend details.

    The Style Data area has mandatory basic style information:

    -
    -

    Option Description

    -
    -

    Name Name of the style

    -

    Workspace Workspace in which the style is contained. Styles can be inside workspaces, but can also be "global" (no workspace).

    -

    Format Format of the style. Options are SLD, CSS, and YSLD, MBStyle depending on availability.

    -
    + + + + + + + + + + + + + + + + + + + + + +
    OptionDescription
    NameName of the style
    WorkspaceWorkspace in which the style is contained. Styles can be inside workspaces, but can also be "global" (no workspace).
    FormatFormat of the style. Options are SLD, CSS, and YSLD, MBStyle depending on availability.

    Style Data area

    The Style Content area allows you to generate a style, copy an existing style, or upload an existing style:

    -
    -

    Option Description

    -
    -

    Generate a default style Selects a generic style based on geometry. Options are Point, Line, Polygon, Raster, and Generic. Click Generate when selected.

    -

    Copy from existing style Selects an existing style in GeoServer and copy its contents to this style. Any style in GeoServer is available as an option. Not all styles will work with all layers. Click Copy when selected.

    -

    Upload a style file Selects a plain text file on your local system to add as the style. Click Upload when selected.

    -
    + + + + + + + + + + + + + + + + + + + + + +
    OptionDescription
    Generate a default styleSelects a generic style based on geometry. Options are Point, Line, Polygon, Raster, and Generic. Click Generate when selected.
    Copy from existing styleSelects an existing style in GeoServer and copy its contents to this style. Any style in GeoServer is available as an option. Not all styles will work with all layers. Click Copy when selected.
    Upload a style fileSelects a plain text file on your local system to add as the style. Click Upload when selected.

    Style Content area

    The Legend area allows you to add, modify, or delete a custom style, and preview the legend for the style. By default GeoServer will generate a legend based on your style file, but this can be customized here:

    -
    -

    Option Description

    -
    -

    Add legend Allows you to use a custom legend

    -

    Online Resource Path to the custom legend graphic to use. Can be a URL or a local path (relative to the style file path). See Structure of the data directory for a description of the styles directory.

    -

    Auto-detect image size and type Populates the Width, Height, and Format options for the Online Resource

    -

    Width Width of the custom legend graphic

    -

    Height Height of the custom legend graphic

    -

    Format Mime type of the custom legend graphic

    -

    Discard legend Will remove the settings for the custom legend graphic and will instead use the default generated legend.

    -

    Preview legend Previews the legend based on the current settings

    -

    Choose Image Insert image into style (choose existing or upload)

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    OptionDescription
    Add legendAllows you to use a custom legend
    Online ResourcePath to the custom legend graphic to use. Can be a URL or a local path (relative to the style file path). See Structure of the data directory for a description of the styles directory.
    Auto-detect image size and typePopulates the Width, Height, and Format options for the Online Resource
    WidthWidth of the custom legend graphic
    HeightHeight of the custom legend graphic
    FormatMime type of the custom legend graphic
    Discard legendWill remove the settings for the custom legend graphic and will instead use the default generated legend.
    Preview legendPreviews the legend based on the current settings
    Choose ImageInsert image into style (choose existing or upload)

    Legend area

    Choose Image Dialog

    Style Editor: Publishing tab

    The Publishing tab displays a list of all layers on the server, with the purpose of showing which layers are associated with the current style. Layers can set a single default style and have any number of additional styles. If this style is set to be either of these options for a layer, it will be shown with a check box in the table.

    -
    -

    Option Description

    -
    -

    Workspace Workspace of the layer

    -

    Layer Name of the layer

    -

    Default Shows whether the style being edited is the default for a given layer

    -

    Associated Shows whether the style being edited is an additional style for a given layer

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + +
    OptionDescription
    WorkspaceWorkspace of the layer
    LayerName of the layer
    DefaultShows whether the style being edited is the default for a given layer
    AssociatedShows whether the style being edited is an additional style for a given layer

    Publishing tab

    Style Editor: Layer Preview tab

    @@ -2061,16 +2196,40 @@

    Style Editor: Layer Preview tab

    Style Editor: Layer Attributes tab

    Most styles utilize the specific values of certain attributes of the associated layer in order to create more detailed and useful styles. (For example: styling all large cities different from small cities based on a particular attribute.)

    The Layer Attributes tab will display a list of attributes for the given associated layer. GeoServer tries to identify which layer should be shown (for example, a layer for which this style is the default), but if the layer being previewed is not the desired one, click the layer name above the table and select a layer.

    -
    -

    Option Description

    -
    -

    name Name of the attribute

    -

    type Type of the attribute. Can be a numeric (such as "Long"), a string ("String"), or a geometry (such as "Point").

    -

    sample Sample value of the attribute taken from the data

    -

    min Minimum value of the attribute in the data set, if applicable

    -

    max Minimum value of the attribute in the data set, if applicable

    -

    computeStats Click Compute to calculate the min and max values for that attribute, if applicable

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    OptionDescription
    nameName of the attribute
    typeType of the attribute. Can be a numeric (such as "Long"), a string ("String"), or a geometry (such as "Point").
    sampleSample value of the attribute taken from the data
    minMinimum value of the attribute in the data set, if applicable
    maxMinimum value of the attribute in the data set, if applicable
    computeStatsClick Compute to calculate the min and max values for that attribute, if applicable

    Layer Attributes tab

    Style Editor: full screen side by side mode

    diff --git a/styling/workshop/css/css/index.html b/styling/workshop/css/css/index.html index 986f7595cf8..5ff932a1605 100644 --- a/styling/workshop/css/css/index.html +++ b/styling/workshop/css/css/index.html @@ -2652,11 +2652,38 @@

    Tour

  • Each time we edit a style, the contents of the associated SLD file are replaced. Rather than disrupt any of our existing styles we will create a new style. Click Add a new style and choose the following:

    -
    -

    Name: airport0

    -

    Workspace: (none specified)

    -

    Format: CSS

    -
    + + + + + + + + + + + +
    +
      +
    • +
        +
      • Name:
      • +
      • airport0
      • +
      +
    • +
    • +
        +
      • Workspace:
      • +
      • (none specified)
      • +
      +
    • +
    • +
        +
      • Format:
      • +
      • CSS
      • +
      +
    • +
  • Replace the initial YSLD definition with our airport CSS example and click Apply:

    diff --git a/styling/workshop/css/linestring/index.html b/styling/workshop/css/linestring/index.html index 4c5ca76981d..6fef04f6182 100644 --- a/styling/workshop/css/linestring/index.html +++ b/styling/workshop/css/linestring/index.html @@ -2396,10 +2396,32 @@

    Stroke

  • Click Create a new style and choose the following:

    -
    -

    Workspace for new layer: No workspace

    -

    New style name: line_example

    -
    + + + + + + + + + + + +
    +
      +
    • +
        +
      • Workspace for new layer:
      • +
      • No workspace
      • +
      +
    • +
    • +
        +
      • New style name:
      • +
      • line_example
      • +
      +
    • +
  • Replace the generated CSS definition with the following stroke example:

    diff --git a/styling/workshop/css/point/index.html b/styling/workshop/css/point/index.html index 50f0a6c4d36..6ab08554b10 100644 --- a/styling/workshop/css/point/index.html +++ b/styling/workshop/css/point/index.html @@ -2369,11 +2369,38 @@

    Points

  • Click Add a new style and choose the following:

    -
    -

    Name: point_example

    -

    Workspace: No workspace

    -

    Format: CSS

    -
    + + + + + + + + + + + +
    +
      +
    • +
        +
      • Name:
      • +
      • point_example
      • +
      +
    • +
    • +
        +
      • Workspace:
      • +
      • No workspace
      • +
      +
    • +
    • +
        +
      • Format:
      • +
      • CSS
      • +
      +
    • +
  • Replace the initial CSS definition with the following and click apply:

    diff --git a/styling/workshop/css/polygon/index.html b/styling/workshop/css/polygon/index.html index 232a224640f..800b19057f4 100644 --- a/styling/workshop/css/polygon/index.html +++ b/styling/workshop/css/polygon/index.html @@ -2418,11 +2418,38 @@

    Polygons

  • Create a new style polygon_example.

    -
    -

    Name: polygon_example

    -

    Workspace: No workspace

    -

    Format: CSS

    -
    + + + + + + + + + + + +
    +
      +
    • +
        +
      • Name:
      • +
      • polygon_example
      • +
      +
    • +
    • +
        +
      • Workspace:
      • +
      • No workspace
      • +
      +
    • +
    • +
        +
      • Format:
      • +
      • CSS
      • +
      +
    • +

    image

  • diff --git a/styling/workshop/css/raster/index.html b/styling/workshop/css/raster/index.html index b8b935b8e29..a26c41dd2f9 100644 --- a/styling/workshop/css/raster/index.html +++ b/styling/workshop/css/raster/index.html @@ -2386,11 +2386,38 @@

    Image

  • Click Add a new style and choose the following:

    -
    -

    Name: image_example

    -

    Workspace: No workspace

    -

    Format: CSS

    -
    + + + + + + + + + + + +
    +
      +
    • +
        +
      • Name:
      • +
      • image_example
      • +
      +
    • +
    • +
        +
      • Workspace:
      • +
      • No workspace
      • +
      +
    • +
    • +
        +
      • Format:
      • +
      • CSS
      • +
      +
    • +
  • Replace the initial CSS definition with:

    @@ -2424,11 +2451,38 @@

    DEM

  • Click Add a new style and choose the following:

    -
    -

    Name: raster_example

    -

    Workspace: No workspace

    -

    Format: CSS

    -
    + + + + + + + + + + + +
    +
      +
    • +
        +
      • Name:
      • +
      • raster_example
      • +
      +
    • +
    • +
        +
      • Workspace:
      • +
      • No workspace
      • +
      +
    • +
    • +
        +
      • Format:
      • +
      • CSS
      • +
      +
    • +
  • When we use the raster-channels property set to auto the rendering engine will select our single band of raster content, and do its best to map these values into a grayscale image. Replace the content of the style with:

    diff --git a/styling/workshop/mbstyle/linestring/index.html b/styling/workshop/mbstyle/linestring/index.html index 2509b76424d..32800a2bdcc 100644 --- a/styling/workshop/mbstyle/linestring/index.html +++ b/styling/workshop/mbstyle/linestring/index.html @@ -2356,11 +2356,38 @@

    Line

  • Click Add a new style and choose the following:

    -
    -

    New style name: line_example

    -

    Workspace for new layer: Leave blank

    -

    Format: MBStyle

    -
    + + + + + + + + + + + +
    +
      +
    • +
        +
      • New style name:
      • +
      • line_example
      • +
      +
    • +
    • +
        +
      • Workspace for new layer:
      • +
      • Leave blank
      • +
      +
    • +
    • +
        +
      • Format:
      • +
      • MBStyle
      • +
      +
    • +
  • Fill in the style editor

    diff --git a/styling/workshop/mbstyle/mbstyle/index.html b/styling/workshop/mbstyle/mbstyle/index.html index 3e0f6b21a38..70d0e9799c3 100644 --- a/styling/workshop/mbstyle/mbstyle/index.html +++ b/styling/workshop/mbstyle/mbstyle/index.html @@ -2614,11 +2614,38 @@

    Tour

  • Each time we edit a style, the contents of the associated SLD file are replaced. Rather than disrupt any of our existing styles we will create a new style. Click Add a new style and choose the following:

    -
    -

    Name: airports0

    -

    Workspace: (leave empty)

    -

    Format: MBStyle

    -
    + + + + + + + + + + + +
    +
      +
    • +
        +
      • Name:
      • +
      • airports0
      • +
      +
    • +
    • +
        +
      • Workspace:
      • +
      • (leave empty)
      • +
      +
    • +
    • +
        +
      • Format:
      • +
      • MBStyle
      • +
      +
    • +
  • Replace the initial MBStyle definition with our airport MBStyle example and click Apply:

    diff --git a/styling/workshop/mbstyle/point/index.html b/styling/workshop/mbstyle/point/index.html index fd94dfb7e55..eaa96b8cd4a 100644 --- a/styling/workshop/mbstyle/point/index.html +++ b/styling/workshop/mbstyle/point/index.html @@ -2315,11 +2315,38 @@

    Points

  • Click Add a new style and choose the following:

    -
    -

    Name: point_example

    -

    Workspace: No workspace

    -

    Format: MBStyle

    -
    + + + + + + + + + + + +
    +
      +
    • +
        +
      • Name:
      • +
      • point_example
      • +
      +
    • +
    • +
        +
      • Workspace:
      • +
      • No workspace
      • +
      +
    • +
    • +
        +
      • Format:
      • +
      • MBStyle
      • +
      +
    • +
  • Replace the initial MBStyle definition with the following and click apply:

    diff --git a/styling/workshop/mbstyle/polygon/index.html b/styling/workshop/mbstyle/polygon/index.html index e894d16e281..1d9598f3e6d 100644 --- a/styling/workshop/mbstyle/polygon/index.html +++ b/styling/workshop/mbstyle/polygon/index.html @@ -2382,11 +2382,38 @@

    Polygons

  • Create a new style polygon_example.

    -
    -

    Name: polygon_example

    -

    Workspace: No workspace

    -

    Format: MBStyle

    -
    + + + + + + + + + + + +
    +
      +
    • +
        +
      • Name:
      • +
      • polygon_example
      • +
      +
    • +
    • +
        +
      • Workspace:
      • +
      • No workspace
      • +
      +
    • +
    • +
        +
      • Format:
      • +
      • MBStyle
      • +
      +
    • +

    image

  • diff --git a/styling/workshop/mbstyle/raster/index.html b/styling/workshop/mbstyle/raster/index.html index fa59dd81d84..dcf146c960c 100644 --- a/styling/workshop/mbstyle/raster/index.html +++ b/styling/workshop/mbstyle/raster/index.html @@ -2279,11 +2279,38 @@

    Image

  • Click Add a new style and choose the following:

    -
    -

    Name: image_example

    -

    Workspace: No workspace

    -

    Format: MBStyle

    -
    + + + + + + + + + + + +
    +
      +
    • +
        +
      • Name:
      • +
      • image_example
      • +
      +
    • +
    • +
        +
      • Workspace:
      • +
      • No workspace
      • +
      +
    • +
    • +
        +
      • Format:
      • +
      • MBStyle
      • +
      +
    • +
  • Replace the initial MBStyle definition with:

    @@ -2317,11 +2344,38 @@

    DEM

  • Click Add a new style and choose the following:

    -
    -

    Name: raster_example

    -

    Workspace: No workspace

    -

    Format: MBStyle

    -
    + + + + + + + + + + + +
    +
      +
    • +
        +
      • Name:
      • +
      • raster_example
      • +
      +
    • +
    • +
        +
      • Workspace:
      • +
      • No workspace
      • +
      +
    • +
    • +
        +
      • Format:
      • +
      • MBStyle
      • +
      +
    • +
  • The rendering engine will select our single band of raster content, and do its best to map these values into a grayscale image. Replace the content of the style with:

    diff --git a/styling/workshop/ysld/linestring/index.html b/styling/workshop/ysld/linestring/index.html index 5b681df33a3..61aa6a9ec90 100644 --- a/styling/workshop/ysld/linestring/index.html +++ b/styling/workshop/ysld/linestring/index.html @@ -2376,11 +2376,38 @@

    Line

  • Click Add a new style and choose the following:

    -
    -

    New style name: line_example

    -

    Workspace for new layer: Leave blank

    -

    Format: YSLD

    -
    + + + + + + + + + + + +
    +
      +
    • +
        +
      • New style name:
      • +
      • line_example
      • +
      +
    • +
    • +
        +
      • Workspace for new layer:
      • +
      • Leave blank
      • +
      +
    • +
    • +
        +
      • Format:
      • +
      • YSLD
      • +
      +
    • +
  • Choose line from the Generate a default style dropdown and click generate.

    diff --git a/styling/workshop/ysld/point/index.html b/styling/workshop/ysld/point/index.html index fd572203e30..7414dcf7fa5 100644 --- a/styling/workshop/ysld/point/index.html +++ b/styling/workshop/ysld/point/index.html @@ -2368,11 +2368,38 @@

    Points

  • Click Add a new style and choose the following:

    -
    -

    Name: point_example

    -

    Workspace: No workspace

    -

    Format: YSLD

    -
    + + + + + + + + + + + +
    +
      +
    • +
        +
      • Name:
      • +
      • point_example
      • +
      +
    • +
    • +
        +
      • Workspace:
      • +
      • No workspace
      • +
      +
    • +
    • +
        +
      • Format:
      • +
      • YSLD
      • +
      +
    • +
  • Choose point from the Generate a default style dropdown and click generate.

    diff --git a/styling/workshop/ysld/polygon/index.html b/styling/workshop/ysld/polygon/index.html index f493c1bed24..1ae0cd7a051 100644 --- a/styling/workshop/ysld/polygon/index.html +++ b/styling/workshop/ysld/polygon/index.html @@ -2418,11 +2418,38 @@

    Polygons

  • Create a new style polygon_example.

    -
    -

    Name: polygon_example

    -

    Workspace: No workspace

    -

    Format: YSLD

    -
    + + + + + + + + + + + +
    +
      +
    • +
        +
      • Name:
      • +
      • polygon_example
      • +
      +
    • +
    • +
        +
      • Workspace:
      • +
      • No workspace
      • +
      +
    • +
    • +
        +
      • Format:
      • +
      • YSLD
      • +
      +
    • +
  • Choose polygon from the Generate a default style dropdown and click generate.

    diff --git a/styling/workshop/ysld/raster/index.html b/styling/workshop/ysld/raster/index.html index ba0a4e92784..2e5dcd76f15 100644 --- a/styling/workshop/ysld/raster/index.html +++ b/styling/workshop/ysld/raster/index.html @@ -2386,11 +2386,38 @@

    Image

  • Click Add a new style and choose the following:

    -
    -

    Name: image_example

    -

    Workspace: No workspace

    -

    Format: YSLD

    -
    + + + + + + + + + + + +
    +
      +
    • +
        +
      • Name:
      • +
      • image_example
      • +
      +
    • +
    • +
        +
      • Workspace:
      • +
      • No workspace
      • +
      +
    • +
    • +
        +
      • Format:
      • +
      • YSLD
      • +
      +
    • +
  • Choose raster from the Generate a default style dropdown and click generate.

    @@ -2430,11 +2457,38 @@

    DEM

  • Click Add a new style and choose the following:

    -
    -

    Name: raster_example

    -

    Workspace: No workspace

    -

    Format: YSLD

    -
    + + + + + + + + + + + +
    +
      +
    • +
        +
      • Name:
      • +
      • raster_example
      • +
      +
    • +
    • +
        +
      • Workspace:
      • +
      • No workspace
      • +
      +
    • +
    • +
        +
      • Format:
      • +
      • YSLD
      • +
      +
    • +
  • Choose raster from the Generate a default style dropdown and click generate.

    diff --git a/styling/workshop/ysld/ysld/index.html b/styling/workshop/ysld/ysld/index.html index 5c8e0f7a6ad..580e628002f 100644 --- a/styling/workshop/ysld/ysld/index.html +++ b/styling/workshop/ysld/ysld/index.html @@ -2718,11 +2718,38 @@

    Tour

  • Each time we edit a style, the contents of the associated SLD file are replaced. Rather than disrupt any of our existing styles we will create a new style. Click Add a new style and choose the following:

    -
    -

    Name: airports0

    -

    Workspace: (leave empty)

    -

    Format: YSLD

    -
    + + + + + + + + + + + +
    +
      +
    • +
        +
      • Name:
      • +
      • airports0
      • +
      +
    • +
    • +
        +
      • Workspace:
      • +
      • (leave empty)
      • +
      +
    • +
    • +
        +
      • Format:
      • +
      • YSLD
      • +
      +
    • +
  • Replace the initial YSLD definition with our airport YSLD example and click Apply:

    diff --git a/styling/ysld/cookbook/index.html b/styling/ysld/cookbook/index.html index fa01a17f286..57d5c4997db 100644 --- a/styling/ysld/cookbook/index.html +++ b/styling/ysld/cookbook/index.html @@ -1956,14 +1956,32 @@

    YSLD Cookbook

    The YSLD Cookbook is a collection of YSLD "recipes" for creating various types of map styles. Wherever possible, each example is designed to show off a single YSLD feature so that code can be copied from the examples and adapted when creating YSLDs of your own. While not an exhaustive reference like the YSLD reference the YSLD cookbook is designed to be a practical reference, showing common style templates that are easy to understand.

    The YSLD Cookbook is divided into four sections: the first three for each of the vector types (points, lines, and polygons) and the fourth section for rasters. Each example in every section contains a screenshot showing actual GeoServer WMS output, a snippet of the YSLD code for reference, and a link to download the full YSLD.

    Each section uses data created especially for the YSLD Cookbook, with shapefiles for vector data and GeoTIFFs for raster data. The projection for data is EPSG:4326.

    -
    -

    Data Type Shapefile

    -
    -

    Point ysld_cookbook_point.zip

    -

    Line ysld_cookbook_line.zip

    -

    Polygon ysld_cookbook_polygon.zip

    -

    Raster ysld_cookbook_raster.zip

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + +
    Data TypeShapefile
    Pointysld_cookbook_point.zip
    Lineysld_cookbook_line.zip
    Polygonysld_cookbook_polygon.zip
    Rasterysld_cookbook_raster.zip
    • Points
    • diff --git a/styling/ysld/cookbook/lines/index.html b/styling/ysld/cookbook/lines/index.html index 7de6648cfa1..395e4379588 100644 --- a/styling/ysld/cookbook/lines/index.html +++ b/styling/ysld/cookbook/lines/index.html @@ -2880,35 +2880,142 @@

      Lines

      While lines can also seem to be simple shapes, having length but no width, there are many options and tricks for making lines display nicely.

      Example lines layer

      The lines layer used in the examples below contains road information for a fictional country. For reference, the attribute table for the points in this layer is included below.

      -
      -

      fid (Feature ID) name (Road name) type (Road class)

      -
      -

      line.1 Latway highway

      -

      line.2 Crescent Avenue secondary

      -

      line.3 Forest Avenue secondary

      -

      line.4 Longway highway

      -

      line.5 Saxer Avenue secondary

      -

      line.6 Ridge Avenue secondary

      -

      line.7 Holly Lane local-road

      -

      line.8 Mulberry Street local-road

      -

      line.9 Nathan Lane local-road

      -

      line.10 Central Street local-road

      -

      line.11 Lois Lane local-road

      -

      line.12 Rocky Road local-road

      -

      line.13 Fleet Street local-road

      -

      line.14 Diane Court local-road

      -

      line.15 Cedar Trail local-road

      -

      line.16 Victory Road local-road

      -

      line.17 Highland Road local-road

      -

      line.18 Easy Street local-road

      -

      line.19 Hill Street local-road

      -

      line.20 Country Road local-road

      -

      line.21 Main Street local-road

      -

      line.22 Jani Lane local-road

      -

      line.23 Shinbone Alley local-road

      -

      line.24 State Street local-road

      -

      line.25 River Road local-road

      -
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      fid (Feature ID)name (Road name)type (Road class)
      line.1Latwayhighway
      line.2Crescent Avenuesecondary
      line.3Forest Avenuesecondary
      line.4Longwayhighway
      line.5Saxer Avenuesecondary
      line.6Ridge Avenuesecondary
      line.7Holly Lanelocal-road
      line.8Mulberry Streetlocal-road
      line.9Nathan Lanelocal-road
      line.10Central Streetlocal-road
      line.11Lois Lanelocal-road
      line.12Rocky Roadlocal-road
      line.13Fleet Streetlocal-road
      line.14Diane Courtlocal-road
      line.15Cedar Traillocal-road
      line.16Victory Roadlocal-road
      line.17Highland Roadlocal-road
      line.18Easy Streetlocal-road
      line.19Hill Streetlocal-road
      line.20Country Roadlocal-road
      line.21Main Streetlocal-road
      line.22Jani Lanelocal-road
      line.23Shinbone Alleylocal-road
      line.24State Streetlocal-road
      line.25River Roadlocal-road

      Download the lines shapefile

      Simple line

      This example specifies lines be colored black with a thickness of 3 pixels.

      @@ -3241,13 +3348,36 @@

      Details

    There are three types of road classes in our fictional country, ranging from back roads to high-speed freeways: "highway", "secondary", and "local-road". In order to handle each case separately, there is more than one feature style, each containing a single rule. This ensures that each road type is rendered in order, as each feature style is drawn based on the order in which it appears in the YSLD.

    The three rules are designed as follows:

    -
    -

    Rule order Rule name / type Color Size

    -
    -

    1 local-road #009933 (green) 2

    -

    2 secondary #0055CC (blue) 3

    -

    3 highway #FF0000 (red) 6

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Rule orderRule name / typeColorSize
    1local-road#009933 (green)2
    2secondary#0055CC (blue)3
    3highway#FF0000 (red)6

    Lines 3-10 comprise the first rule. Line 6 sets the filter for this rule, such that the "type" attribute has a value of "local-road". If this condition is true for a particular line, the rule is rendered according to the line symbolizer which is on lines 8-10. Lines 9-10 set the color of the line to be a dark green ('#009933') and the width to be 2 pixels.

    Lines 11-18 comprise the second rule. Line 14 sets the filter for this rule, such that the "type" attribute has a value of "secondary". If this condition is true for a particular line, the rule is rendered according to the line symbolizer which is on lines 16-18. Lines 17-18 set the color of the line to be a dark blue ('#0055CC') and the width to be 3 pixels, making the lines slightly thicker than the "local-road" lines and also a different color.

    Lines 19-26 comprise the third and final rule. Line 22 sets the filter for this rule, such that the "type" attribute has a value of "primary". If this condition is true for a particular line, the rule is rendered according to the line symbolizer which is on lines 24-26. Lines 25-26 set the color of the line to be a bright red ('#FF0000') and the width to be 6 pixels, so that these lines are rendered on top of and thicker than the other two road classes. In this way, the "primary" roads are given priority in the map rendering.

    @@ -3291,13 +3421,36 @@

    Details

    Determining the appropriate scale denominators (zoom levels) to use is beyond the scope of this example.

  • This style contains three rules. The three rules are designed as follows:

    -
    -

    Rule order Rule name Scale denominator Line width

    -
    -

    1 Large 1:180,000,000 or less 6

    -

    2 Medium 1:180,000,000 to 1:360,000,000 4

    -

    3 Small Greater than 1:360,000,000 2

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Rule orderRule nameScale denominatorLine width
    1Large1:180,000,000 or less6
    2Medium1:180,000,000 to 1:360,000,0004
    3SmallGreater than 1:360,000,0002

    The order of these rules does not matter since the scales denominated in each rule do not overlap.

    The first rule (lines 5-10) is the smallest scale denominator, corresponding to when the view is "zoomed in". The scale rule is set on line 6, so that the rule will apply to any map with a scale denominator of 180,000,000 or less. Lines 9-10 draw the line to be dark green ('#009933') with a width of 6 pixels.

    The second rule (lines 11-16) is the intermediate scale denominator, corresponding to when the view is "partially zoomed". Lines 12 set the scale such that the rule will apply to any map with scale denominators between 180,000,000 and 360,000,000. (The lower bound is inclusive and the upper bound is exclusive, so a zoom level of exactly 360,000,000 would not apply here.) Aside from the scale, the only difference between this rule and the previous is the width of the lines, which is set to 4 pixels on line 16.

    diff --git a/styling/ysld/cookbook/points/index.html b/styling/ysld/cookbook/points/index.html index e110a3f7352..84fa691f56b 100644 --- a/styling/ysld/cookbook/points/index.html +++ b/styling/ysld/cookbook/points/index.html @@ -2682,17 +2682,52 @@

    Points

    While points are seemingly the simplest type of shape, possessing only position and no other dimensions, there are many different ways that a point can be styled in YSLD.

    Example points layer

    The points layer used for the examples below contains name and population information for the major cities of a fictional country. For reference, the attribute table for the points in this layer is included below.

    -
    -

    fid (Feature ID) name (City name) pop (Population)

    -
    -

    point.1 Borfin 157860

    -

    point.2 Supox City 578231

    -

    point.3 Ruckis 98159

    -

    point.4 Thisland 34879

    -

    point.5 Synopolis 24567

    -

    point.6 San Glissando 76024

    -

    point.7 Detrania 205609

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    fid (Feature ID)name (City name)pop (Population)
    point.1Borfin157860
    point.2Supox City578231
    point.3Ruckis98159
    point.4Thisland34879
    point.5Synopolis24567
    point.6San Glissando76024
    point.7Detrania205609

    Download the points shapefile

    Simple point

    This example specifies points be styled as red circles with a diameter of 6 pixels.

    @@ -2941,13 +2976,36 @@

    Details

    This style contains three rules. Each rule varies the style based on the value of the population ("pop") attribute for each point, with smaller values yielding a smaller circle, and larger values yielding a larger circle.

    The three rules are designed as follows:

    -
    -

    Rule order Rule name Population (pop) Size

    -
    -

    1 SmallPop Less than 50,000 8

    -

    2 MediumPop 50,000 to 100,000 12

    -

    3 LargePop Greater than 100,000 16

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Rule orderRule namePopulation (pop)Size
    1SmallPopLess than 50,0008
    2MediumPop50,000 to 100,00012
    3LargePopGreater than 100,00016

    The order of the rules does not matter in this case, since each shape is only rendered by a single rule.

    The first rule, on lines 5-14, specifies the styling of those points whose population attribute is less than 50,000. Line 7 sets this filter, denoting the attribute ("pop") to be "less than" the value of 50,000. The symbol is a circle (line 13), the color is dark blue ('#0033CC', on line 15), and the size is 8 pixels in diameter (line 18).

    The second rule, on lines 15-24, specifies a style for points whose population attribute is greater than or equal to 50,000 and less than 100,000. The population filter is set on line 17. This filter specifies two criteria instead of one: a "greater than or equal to" and a "less than" filter. These criteria are joined by AND, which mandates that both filters need to be true for the rule to be applicable. The size of the graphic is set to 12 pixels on line 20. All other styling directives are identical to the first rule.

    @@ -3002,13 +3060,36 @@

    Details

    Determining the appropriate scale denominators (zoom levels) to use is beyond the scope of this example.

    This style contains three rules. The three rules are designed as follows:

    -
    -

    Rule order Rule name Scale denominator Point size

    -
    -

    1 Large 1:160,000,000 or less 12

    -

    2 Medium 1:160,000,000 to 1:320,000,000 8

    -

    3 Small Greater than 1:320,000,000 4

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Rule orderRule nameScale denominatorPoint size
    1Large1:160,000,000 or less12
    2Medium1:160,000,000 to 1:320,000,0008
    3SmallGreater than 1:320,000,0004

    The order of these rules does not matter since the scales denominated in each rule do not overlap.

    The first rule (lines 5-13) is for the smallest scale denominator, corresponding to when the view is "zoomed in". The scale rule is set on line 6, so that the rule will apply to any map with a scale denominator of 160,000,000 or less. The rule draws a circle (line 12), colored red (#CC3300 on line 13) with a size of 12 pixels (line 9).

    The second rule (lines 14-22) is the intermediate scale denominator, corresponding to when the view is "partially zoomed". The scale rules is set on line 15, so that the rule will apply to any map with a scale denominator between 160,000,000 and 320,000,000. (The lower bound is inclusive and the upper bound is exclusive, so a zoom level of exactly 320,000,000 would not apply here.) Aside from the scale, the only difference between this rule and the first is the size of the symbol, which is set to 8 pixels on line 18.

    diff --git a/styling/ysld/cookbook/polygons/index.html b/styling/ysld/cookbook/polygons/index.html index 9f2ecf17b6c..70b658ce47e 100644 --- a/styling/ysld/cookbook/polygons/index.html +++ b/styling/ysld/cookbook/polygons/index.html @@ -2682,18 +2682,57 @@

    Polygons

    Polygons are two dimensional shapes that contain both an outer edge (or "stroke") and an inside (or "fill"). A polygon can be thought of as an irregularly-shaped point and is styled in similar ways to points.

    Example polygons layer

    The polygons layer used below contains county information for a fictional country. For reference, the attribute table for the polygons is included below.

    -
    -

    fid (Feature ID) name (County name) pop (Population)

    -
    -

    polygon.1 Irony County 412234

    -

    polygon.2 Tracker County 235421

    -

    polygon.3 Dracula County 135022

    -

    polygon.4 Poly County 1567879

    -

    polygon.5 Bearing County 201989

    -

    polygon.6 Monte Cristo County 152734

    -

    polygon.7 Massive County 67123

    -

    polygon.8 Rhombus County 198029

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    fid (Feature ID)name (County name)pop (Population)
    polygon.1Irony County412234
    polygon.2Tracker County235421
    polygon.3Dracula County135022
    polygon.4Poly County1567879
    polygon.5Bearing County201989
    polygon.6Monte Cristo County152734
    polygon.7Massive County67123
    polygon.8Rhombus County198029

    Download the polygons shapefile

    Simple polygon

    This example shows a polygon filled in blue.

    @@ -2912,13 +2951,36 @@

    Details

    Each polygon in our fictional country has a population that is represented by the population ("pop") attribute. This style contains three rules that alter the fill based on the value of "pop" attribute, with smaller values yielding a lighter color and larger values yielding a darker color.

    The three rules are designed as follows:

    -
    -

    Rule order Rule name Population (pop) Color

    -
    -

    1 SmallPop Less than 200,000 #66FF66

    -

    2 MediumPop 200,000 to 500,000 #33CC33

    -

    3 LargePop Greater than 500,000 #009900

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Rule orderRule namePopulation (pop)Color
    1SmallPopLess than 200,000#66FF66
    2MediumPop200,000 to 500,000#33CC33
    3LargePopGreater than 500,000#009900

    The order of the rules does not matter in this case, since each shape is only rendered by a single rule.

    The first rule, on lines 5-10, specifies the styling of polygons whose population attribute is less than 200,000. Line 7 sets this filter, denoting the attribute ("pop"), to be "less than" the value of 200,000. The color of the polygon fill is set to a light green ('#66FF66') on line 10.

    The second rule, on lines 11-16, is similar, specifying a style for polygons whose population attribute is greater than or equal to 200,000 but less than 500,000. The filter is set on line 13. This filter specifies two criteria instead of one: a "greater than or equal to" and a "less than" filter. These criteria are joined by AND, which mandates that both filters need to be true for the rule to be applicable. The color of the polygon fill is set to a medium green on ('#33CC33') on line 16.

    @@ -2976,13 +3038,40 @@

    Details

    Determining the appropriate scale denominators (zoom levels) to use is beyond the scope of this example.

    This style contains three rules, defined as follows:

    -
    -

    Rule order Rule name Scale denominator Stroke width Label display?

    -
    -

    1 Large 1:100,000,000 or less 7 Yes

    -

    2 Medium 1:100,000,000 to 1:200,000,000 4 No

    -

    3 Small Greater than 1:200,000,000 2 No

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Rule orderRule nameScale denominatorStroke widthLabel display?
    1Large1:100,000,000 or less7Yes
    2Medium1:100,000,000 to 1:200,000,0004No
    3SmallGreater than 1:200,000,0002No

    The first rule, on lines 5-20, is for the smallest scale denominator, corresponding to when the view is "zoomed in". The scale rule is set on line 6 such that the rule will apply only where the scale denominator is 100,000,000 or less. Line 11 defines the fill as blue ('#0000CC'). Note that the fill is kept constant across all rules regardless of the scale denominator. As in the Polygon with default label or Polygon with styled label examples, the rule also contains a text symbolizer at lines 12-20 for drawing a text label on top of the polygon. Lines 15-18 set the font information to be Arial, 14 pixels, and bold with no italics. The label is centered both horizontally and vertically along the centroid of the polygon on by setting anchor to be [0.5, 0.5] (or 50%) on line 20. Finally, the color of the font is set to white ('#FFFFFF') in line 14.

    The second rule, on lines 21-27, is for the intermediate scale denominators, corresponding to when the view is "partially zoomed". The scale rules on lines 22 set the rule such that it will apply to any map with a scale denominator between 100,000,000 and 200,000,000. (The lower bound is inclusive and the upper bound is exclusive, so a zoom level of exactly 200,000,000 would not apply here.) Aside from the scale, there are two differences between this rule and the first: the width of the stroke is set to 4 pixels on line 26 and a text symbolizer is not present so that no labels will be displayed.

    The third rule, on lines 28-34, is for the largest scale denominator, corresponding to when the map is "zoomed out". The scale rule is set on line 29 such that the rule will apply to any map with a scale denominator of 200,000,000 or greater. Again, the only differences between this rule and the others are the width of the lines, which is set to 1 pixel on line 33, and the absence of a text symbolizer so that no labels will be displayed.

    diff --git a/styling/ysld/cookbook/rasters/index.html b/styling/ysld/cookbook/rasters/index.html index a3224dc5e8b..dd3aac7a10b 100644 --- a/styling/ysld/cookbook/rasters/index.html +++ b/styling/ysld/cookbook/rasters/index.html @@ -2649,18 +2649,66 @@

    Code

    Details

    A color-map can include up to 255 entries. This example has eight entries (lines 11-18):

    -
    -

    Entry number Value Color RGB code

    -
    -

    1 95 Black '#000000'

    -

    2 110 Blue '#0000FF'

    -

    3 135 Green '#00FF00'

    -

    4 160 Red '#FF0000'

    -

    5 185 Purple '#FF00FF'

    -

    6 210 Yellow '#FFFF00'

    -

    7 235 Cyan '#00FFFF'

    -

    8 256 White '#FFFFFF'

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Entry numberValueColorRGB code
    195Black'#000000'
    2110Blue'#0000FF'
    3135Green'#00FF00'
    4160Red'#FF0000'
    5185Purple'#FF00FF'
    6210Yellow'#FFFF00'
    7235Cyan'#00FFFF'
    8256White'#FFFFFF'
    diff --git a/styling/ysld/reference/featurestyles/index.html b/styling/ysld/reference/featurestyles/index.html index 41c1bc55624..815d3f8c6d3 100644 --- a/styling/ysld/reference/featurestyles/index.html +++ b/styling/ysld/reference/featurestyles/index.html @@ -2453,24 +2453,85 @@

    Syntax

    x-inclusion: <text>

    where:

    -
    -

    Property Required? Description Default value

    -
    -

    name No Internal reference to the feature style. It is recommended that the value be lower case and contain no spaces. Blank

    -

    title No Human-readable name of the feature style. Exposed as a name for the group of rules contained in the feature style. Blank

    -

    abstract No Longer description of the feature style. Blank

    -

    transform No Rendering transformation information. N/A

    -

    rules Yes List of styling rules. N/A

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    PropertyRequired?DescriptionDefault value
    nameNoInternal reference to the feature style. It is recommended that the value be lower case and contain no spaces.Blank
    titleNoHuman-readable name of the feature style. Exposed as a name for the group of rules contained in the feature style.Blank
    abstractNoLonger description of the feature style.Blank
    transformNoRendering transformation information.N/A
    rulesYesList of styling rules.N/A

    The following properties are equivalent to SLD "vendor options".

    -
    -

    Property Required? Description Default value

    -
    -

    x-ruleEvaluation No When equals to first - stops rule evaluation after the first match. Can make the rendering more efficient by reducing the number of rules that need to be traversed by features, as well as simplyfing the rule filters. all

    -

    x-composite No Allows for both alpha compositing and color blending options between buffers. There are many options; see below. N/A

    -

    x-composite-base No Allows the rendering engine to use that feature-style as a "base", and will compose all subsequent feature-styles and layers on top of it, until another base is found. Once the full set of layers against a base is composed, then the base itself will be composed against the next set of composed layers using its own compositing operator, if present. This is useful to fine-tune the use of x-composite, and to make sure that only the desired content is composited/blended and not all of the drawn content. false

    -

    x-inclusion No Define if rule should be included in style for legendOnly or mapOnly (see Rendering Selection) normal

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    PropertyRequired?DescriptionDefault value
    x-ruleEvaluationNoWhen equals to first - stops rule evaluation after the first match. Can make the rendering more efficient by reducing the number of rules that need to be traversed by features, as well as simplyfing the rule filters.all
    x-compositeNoAllows for both alpha compositing and color blending options between buffers. There are many options; see below.N/A
    x-composite-baseNoAllows the rendering engine to use that feature-style as a "base", and will compose all subsequent feature-styles and layers on top of it, until another base is found. Once the full set of layers against a base is composed, then the base itself will be composed against the next set of composed layers using its own compositing operator, if present. This is useful to fine-tune the use of x-composite, and to make sure that only the desired content is composited/blended and not all of the drawn content.false
    x-inclusionNoDefine if rule should be included in style for legendOnly or mapOnly (see Rendering Selection)normal

    Compositing and blending

    By default, multiple feature styles are drawn with one buffer on top of the other. However, using the x-composite and x-composite-base options, one can customize the way that buffers are displayed.

    The following two tables show the possible alpha compositing and color blending values for the x-composite option. Note that in the tables below, source refers to the buffer that is drawn on top, while destination refers to the buffer that the source is drawn on top of.

    diff --git a/styling/ysld/reference/filters/index.html b/styling/ysld/reference/filters/index.html index 97b1027ab5f..0ff91a5c6e0 100644 --- a/styling/ysld/reference/filters/index.html +++ b/styling/ysld/reference/filters/index.html @@ -2362,30 +2362,95 @@

    Object comparison

    ${<attribute> <operator> <value>}
     

    where:

    -
    -

    Attribute Required? Description Default value

    -
    -

    <attribute> Yes That to which something is going to be compared. Typically an attribute name. May be case sensitive. N/A

    -

    <operator> Yes Method of comparison. Valid operators are =, <, >, <=, >=, <>, LIKE, ILIKE, BETWEEN, IS NULL, IN. NOT can be added to invert the comparison. N/A

    -

    <value> Yes That which the <attribute> is being compared to. Typically a static value such as a string or scalar, though can be an expression that evaluates to a static value. Can include mathematical operators such as +, -, *, /. Use single quotes for strings, as double-quotes will be interpreted as an attribute name. Omit quotes for scalar values. N/A

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    AttributeRequired?DescriptionDefault value
    <attribute>YesThat to which something is going to be compared. Typically an attribute name. May be case sensitive.N/A
    <operator>YesMethod of comparison. Valid operators are =, <, >, <=, >=, <>, LIKE, ILIKE, BETWEEN, IS NULL, IN. NOT can be added to invert the comparison.N/A
    <value>YesThat which the <attribute> is being compared to. Typically a static value such as a string or scalar, though can be an expression that evaluates to a static value. Can include mathematical operators such as +, -, *, /. Use single quotes for strings, as double-quotes will be interpreted as an attribute name. Omit quotes for scalar values.N/A

    The following is a description of all available operators:

    -
    -

    Operator Description

    -
    -

    = Equals

    -

    < Less than (non-inclusive)

    -

    > Greater than (non-inclusive)

    -

    <= Less than or equal to (inclusive)

    -

    >= Greater than or equal to (inclusive)

    -

    LIKE Fuzzy matching for strings and other non-numeric attributes. Add % for multi-character wildcards, and _ for single-character wildcards.

    -

    ILIKE Case-insensitive version of LIKE

    -

    BETWEEN Tests if a value that is between two given values

    -

    IS NULL For testing against a NULL value

    -

    IN Used when specifying a list. Must be contained in the list for the statement to be true.

    -

    NOT Negates a boolean (true/false) condition. Can be used with an additional operator such as NOT LIKE or NOT BETWEEN.

    -

    <> Not equal (used when comparing a string or numeric value only)

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    OperatorDescription
    =Equals
    <Less than (non-inclusive)
    >Greater than (non-inclusive)
    <=Less than or equal to (inclusive)
    >=Greater than or equal to (inclusive)
    LIKEFuzzy matching for strings and other non-numeric attributes. Add % for multi-character wildcards, and _ for single-character wildcards.
    ILIKECase-insensitive version of LIKE
    BETWEENTests if a value that is between two given values
    IS NULLFor testing against a NULL value
    INUsed when specifying a list. Must be contained in the list for the statement to be true.
    NOTNegates a boolean (true/false) condition. Can be used with an additional operator such as NOT LIKE or NOT BETWEEN.
    <>Not equal (used when comparing a string or numeric value only)

    Note

    These operators are not case sensitive, but are shown here in all caps for legibility and consistency.

    diff --git a/styling/ysld/reference/rules/index.html b/styling/ysld/reference/rules/index.html index 56e9f76e3c5..a43af82b866 100644 --- a/styling/ysld/reference/rules/index.html +++ b/styling/ysld/reference/rules/index.html @@ -2341,17 +2341,60 @@

    Syntax

    x-inclusion: <text>

    where:

    -
    -

    Property Required? Description Default value

    -
    -

    name No Internal reference to the feature style. It is recommended that the value be lower case and contain no spaces. Blank

    -

    title No Human-readable description of what the rule accomplishes. Blank

    -

    filter No Filter expression which will need to evaluate to be true for the symbolizer(s) to be applied. Cannot be used with else. Blank (meaning that the rule will apply to all features)

    -

    else No Specifies whether the rule will be an "else" rule. An else rule applies when, after scale and filters are applied, no other rule applies. To make an else rule, set this option to true. Cannot be used with filter. false

    -

    scale No Scale boundaries showing at what scales (related to zoom levels) the rule will be applied. Visible at all scales

    -

    symbolizers Yes Block containing one or more symbolizers. These contain the actual visualization directives. If the filter returns true and the view is within the scale boundaries, these symbolizers will be drawn. N/A

    -

    x-inclusion No Define if rule should be included in style for legendOnly or mapOnly (see Rendering Selection) normal

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    PropertyRequired?DescriptionDefault value
    nameNoInternal reference to the feature style. It is recommended that the value be lower case and contain no spaces.Blank
    titleNoHuman-readable description of what the rule accomplishes.Blank
    filterNoFilter expression which will need to evaluate to be true for the symbolizer(s) to be applied. Cannot be used with else.Blank (meaning that the rule will apply to all features)
    elseNoSpecifies whether the rule will be an "else" rule. An else rule applies when, after scale and filters are applied, no other rule applies. To make an else rule, set this option to true. Cannot be used with filter.false
    scaleNoScale boundaries showing at what scales (related to zoom levels) the rule will be applied.Visible at all scales
    symbolizersYesBlock containing one or more symbolizers. These contain the actual visualization directives. If the filter returns true and the view is within the scale boundaries, these symbolizers will be drawn.N/A
    x-inclusionNoDefine if rule should be included in style for legendOnly or mapOnly (see Rendering Selection)normal

    Short syntax

    When a style has a single rule inside a single feature style, it is possible to omit the syntax for both and start at the first parameter inside.

    So the following complete styles are equivalent:

    diff --git a/styling/ysld/reference/scalezoom/index.html b/styling/ysld/reference/scalezoom/index.html index 7b148d8506a..ad269730ea9 100644 --- a/styling/ysld/reference/scalezoom/index.html +++ b/styling/ysld/reference/scalezoom/index.html @@ -2404,12 +2404,30 @@

    Scale syntax

    ...

    where:

    -
    -

    Attribute Required? Description Default value

    -
    -

    min Yes The minimum scale (inclusive) for which the rule will be applied. Value is a number, either decimal or integer. N/A

    -

    max Yes The maximum scale (exclusive) for which the rule will be applied. Value is a number, either decimal or integer. N/A

    -
    + + + + + + + + + + + + + + + + + + + + + + + +
    AttributeRequired?DescriptionDefault value
    minYesThe minimum scale (inclusive) for which the rule will be applied. Value is a number, either decimal or integer.N/A
    maxYesThe maximum scale (exclusive) for which the rule will be applied. Value is a number, either decimal or integer.N/A

    Note

    It is not possible to use an expression for any of these values.

    @@ -2510,12 +2528,30 @@

    Zoom syntax

    ...

    where:

    -
    -

    Attribute Required? Description Default value

    -
    -

    min Yes The minimum zoom level for which the rule will be applied. Value is an integer. N/A

    -

    max Yes The maximum zoom level for which the rule will be applied. Value is an integer. N/A

    -
    + + + + + + + + + + + + + + + + + + + + + + + +
    AttributeRequired?DescriptionDefault value
    minYesThe minimum zoom level for which the rule will be applied. Value is an integer.N/A
    maxYesThe maximum zoom level for which the rule will be applied. Value is an integer.N/A

    Note

    It is not possible to use an expression for any of these values.

    @@ -2539,11 +2575,24 @@

    Specifying a grid

    name: <string>

    where:

    -
    -

    Property Required? Description Default value

    -
    -

    name No WGS84, WebMercator, or a name of a predefined gridset in GeoServer. WebMercator

    -
    + + + + + + + + + + + + + + + + + +
    PropertyRequired?DescriptionDefault value
    nameNoWGS84, WebMercator, or a name of a predefined gridset in GeoServer.WebMercator

    Note

    As many web maps use "web mercator" (also known as EPSG:3857 or EPSG:900913), this is assumed to be the default if no grid is specified.

    diff --git a/styling/ysld/reference/symbolizers/index.html b/styling/ysld/reference/symbolizers/index.html index b6d910693a2..ff563029972 100644 --- a/styling/ysld/reference/symbolizers/index.html +++ b/styling/ysld/reference/symbolizers/index.html @@ -2373,93 +2373,74 @@

    Syntax

    x-inclusion: <text>

    Where:

    -

    .. list-table:: - :class: non-responsive - :header-rows: 1 - :stub-columns: 1 - :widths: 20 10 50 20

    -
      -
    • -
        -
      • Property
      • -
      • Required?
      • -
      • Description
      • -
      • Default value
      • -
      -
    • -
    • -
        -
      • geometry
      • -
      • No
      • -
      • Specifies which attribute to use as the geometry (see :ref:geometry_transformations)
      • -
      • First geometry attribute found (usually named geom or the_geom)
      • -
      -
    • -
    • -
        -
      • uom
      • -
      • No
      • -
      • Unit of measure used for width calculations (see :ref:unit_of_measure)
      • -
      • pixel
      • -
      -
    • -
    -

    Additional "vendor options" properties for :ref:sld-extensions_composite-blend:

    -

    .. list-table:: - :class: non-responsive - :header-rows: 1 - :stub-columns: 1 - :widths: 20 10 50 20

    -
      -
    • -
        -
      • Property
      • -
      • Required?
      • -
      • Description
      • -
      • Default value
      • -
      -
    • -
    • -
        -
      • x-composite
      • -
      • No
      • -
      • Allows for both alpha compositing and color blending options between symbolizers.
      • -
      • N/A
      • -
      -
    • -
    • -
        -
      • x-composite-base
      • -
      • No
      • -
      • Allows the rendering engine to use the symbolizer mapping to define a "base" buffer for subsequent compositing and blending using x-composite. See the section on :ref:Feature Styles <ysld_reference_featurestyles_composite> for more details.
      • -
      • false
      • -
      -
    • -
    -

    Additional "vendor options" properties for :ref:rendering_selection:

    -

    .. list-table:: - :class: non-responsive - :header-rows: 1 - :stub-columns: 1 - :widths: 20 10 50 20

    -
      -
    • -
        -
      • Property
      • -
      • Required?
      • -
      • Description
      • -
      • Default value
      • -
      -
    • -
    • -
        -
      • x-inclusion
      • -
      • No
      • -
      • Define if rule should be included in style for legendOnly or mapOnly.
      • -
      • normal
      • -
      -
    • -
    + + + + + + + + + + + + + + + + + + + + + + + +
    PropertyRequired?DescriptionDefault value
    geometryNoSpecifies which attribute to use as the geometry (see Geometry transformations in SLD)First geometry attribute found (usually named geom or the_geom)
    uomNoUnit of measure used for width calculations (see Specifying symbolizer sizes in ground units)pixel
    +

    Additional "vendor options" properties for Color compositing and color blending:

    + + + + + + + + + + + + + + + + + + + + + + + +
    PropertyRequired?DescriptionDefault value
    x-compositeNoAllows for both alpha compositing and color blending options between symbolizers.N/A
    x-composite-baseNoAllows the rendering engine to use the symbolizer mapping to define a "base" buffer for subsequent compositing and blending using x-composite. See the section on Feature Styles for more details.false
    +

    Additional "vendor options" properties for Rendering Selection:

    + + + + + + + + + + + + + + + + + +
    PropertyRequired?DescriptionDefault value
    x-inclusionNoDefine if rule should be included in style for legendOnly or mapOnly.normal
    diff --git a/styling/ysld/reference/symbolizers/line/index.html b/styling/ysld/reference/symbolizers/line/index.html index d91ec39eb6a..5a36e1bc4e1 100644 --- a/styling/ysld/reference/symbolizers/line/index.html +++ b/styling/ysld/reference/symbolizers/line/index.html @@ -2338,209 +2338,177 @@

    Syntax

    x-inclusion: <text>

    where:

    -

    .. list-table:: - :class: non-responsive - :header-rows: 1 - :stub-columns: 1 - :widths: 20 10 50 20

    - -
    -

    Property Required? Description Default value

    -
    -

    offset No Value in pixels for moving the drawn line relative to the location of the feature. 0

    -
    -

    .. list-table:: - :class: non-responsive - :header-rows: 1 - :stub-columns: 1 - :widths: 20 10 50 20

    - -

    Additional "vendor options" property for :ref:label_obstacles:

    -

    .. list-table:: - :class: non-responsive - :header-rows: 1 - :stub-columns: 1 - :widths: 20 10 50 20

    - -

    Additional "vendor options" properties for :ref:sld-extensions_composite-blend:

    -

    .. list-table:: - :class: non-responsive - :header-rows: 1 - :stub-columns: 1 - :widths: 20 10 50 20

    - -

    Additional "vendor options" properties for :ref:rendering_selection:

    -

    .. list-table:: - :class: non-responsive - :header-rows: 1 - :stub-columns: 1 - :widths: 20 10 50 20

    - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    PropertyRequired?DescriptionDefault value
    stroke-colorNoColor of line features.'#000000' (black)
    stroke-widthNoWidth of line features, measured in pixels.1
    stroke-opacityNoOpacity of line features. Valid values are a decimal value between 0 (completely transparent) and 1 (completely opaque).1
    stroke-linejoinNoHow line segments are joined together. Options are mitre (sharp corner), round (round corner), and bevel (diagonal corner).mitre
    stroke-linecapNoHow line features are rendered at their ends. Options are butt (sharp square edge), round (rounded edge), and square (slightly elongated square edge).butt
    stroke-dasharrayNoA numeric list signifying length of lines and gaps, creating a dashed effect. Units are pixels, so "2 3" would be a repeating pattern of 2 pixels of drawn line followed by 3 pixels of blank space. If only one number is supplied, this will mean equal amounts of line and gap.No dash
    stroke-dashoffsetNoNumber of pixels into the dasharray to offset the drawing of the dash, used to shift the location of the lines and gaps in a dash.0
    stroke-graphicNoA design or pattern to be used along the stroke. Output will always be a linear repeating pattern, and as such is not tied to the value of stroke-width. Can either be a mark consisting of a common shape or a URL that points to a graphic. The <graphic_options> should consist of a mapping containing symbols: followed by an external: or mark:, with appropriate parameters as detailed in the Point symbolizer section. Cannot be used with stroke-graphic-fill.N/A
    stroke-graphic-fillNoA design or pattern to be used for the fill of the stroke. The area that is to be filled is tied directly to the value of stroke-width. Can either be a mark consisting of a common shape or a URL that points to a graphic. The <graphic_options> should consist of a mapping containing symbols: followed by an external: or mark:, with appropriate parameters as detailed in the Point symbolizer section. Cannot be used with stroke-graphic.N/A
    + + + + + + + + + + + + + + + + + +
    PropertyRequired?DescriptionDefault value
    offsetNoValue in pixels for moving the drawn line relative to the location of the feature.0
    + + + + + + + + + + + + + + + + + + + + + + + +
    PropertyRequired?DescriptionDefault value
    geometryNoSpecifies which attribute to use as the geometry (see Geometry transformations in SLD)First geometry attribute found (usually named geom or the_geom)
    uomNoUnit of measure used for width calculations (see Specifying symbolizer sizes in ground units)pixel
    +

    Additional "vendor options" property for Label Obstacles:

    + + + + + + + + + + + + + + + + + +
    PropertyRequired?DescriptionDefault value
    x-labelObstacleNoMarks the symbolizer as an obstacle such that labels drawn via a text symbolizer will not be drawn over top of these features. Options are true or false. Note that the bounding boxes of features are used when calculating obstacles, so unintended effects may occur when marking a line or polygon symbolizer as an obstacle.false
    +

    Additional "vendor options" properties for Color compositing and color blending:

    + + + + + + + + + + + + + + + + + + + + + + + +
    PropertyRequired?DescriptionDefault value
    x-compositeNoAllows for both alpha compositing and color blending options between symbolizers.N/A
    x-composite-baseNoAllows the rendering engine to use the symbolizer mapping to define a "base" buffer for subsequent compositing and blending using x-composite. See the section on Feature Styles for more details.false
    +

    Additional "vendor options" properties for Rendering Selection:

    + + + + + + + + + + + + + + + + + +
    PropertyRequired?DescriptionDefault value
    x-inclusionNoDefine if rule should be included in style for legendOnly or mapOnly.normal

    Examples

    Basic line with styled ends

    The linejoin and linecap properties can be used to style the joins and ends of any stroke. This example draws lines with partially transparent black lines with rounded ends and sharp (mitred) corners:

    diff --git a/styling/ysld/reference/symbolizers/point/index.html b/styling/ysld/reference/symbolizers/point/index.html index 4601e005842..60f009963d7 100644 --- a/styling/ysld/reference/symbolizers/point/index.html +++ b/styling/ysld/reference/symbolizers/point/index.html @@ -2370,325 +2370,317 @@

    Syntax

    x-inclusion: <text>

    where:

    -

    .. list-table:: - :class: non-responsive - :header-rows: 1 - :stub-columns: 1 - :widths: 20 10 50 20

    - -

    .. list-table:: - :class: non-responsive - :header-rows: 1 - :stub-columns: 1 - :widths: 20 10 50 20

    - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    PropertyRequired?DescriptionDefault value
    stroke-colorNoColor of line features.'#000000' (black)
    stroke-widthNoWidth of line features, measured in pixels.1
    stroke-opacityNoOpacity of line features. Valid values are a decimal value between 0 (completely transparent) and 1 (completely opaque).1
    stroke-linejoinNoHow line segments are joined together. Options are mitre (sharp corner), round (round corner), and bevel (diagonal corner).mitre
    stroke-linecapNoHow line features are rendered at their ends. Options are butt (sharp square edge), round (rounded edge), and square (slightly elongated square edge).butt
    stroke-dasharrayNoA numeric list signifying length of lines and gaps, creating a dashed effect. Units are pixels, so "2 3" would be a repeating pattern of 2 pixels of drawn line followed by 3 pixels of blank space. If only one number is supplied, this will mean equal amounts of line and gap.No dash
    stroke-dashoffsetNoNumber of pixels into the dasharray to offset the drawing of the dash, used to shift the location of the lines and gaps in a dash.0
    stroke-graphicNoA design or pattern to be used along the stroke. Output will always be a linear repeating pattern, and as such is not tied to the value of stroke-width. Can either be a mark consisting of a common shape or a URL that points to a graphic. The <graphic_options> should consist of a mapping containing symbols: followed by an external: or mark:, with appropriate parameters as detailed in the Point symbolizer section. Cannot be used with stroke-graphic-fill.N/A
    stroke-graphic-fillNoA design or pattern to be used for the fill of the stroke. The area that is to be filled is tied directly to the value of stroke-width. Can either be a mark consisting of a common shape or a URL that points to a graphic. The <graphic_options> should consist of a mapping containing symbols: followed by an external: or mark:, with appropriate parameters as detailed in the Point symbolizer section. Cannot be used with stroke-graphic.N/A
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    PropertyRequired?DescriptionDefault value
    fill-colorNoColor of inside of features.'#808080' (gray)
    fill-opacityNoOpacity of the fill. Valid values are a decimal value between 0 (completely transparent) and 1 (completely opaque).1
    fill-graphicNoA design or pattern to be used for the fill of the feature. Can either be a mark consisting of a common shape or a URL that points to a graphic. The <graphic_options> should consist of a mapping containing symbols: followed by an external: or mark:, with appropriate parameters as detailed in the Point symbolizer section.None

    The use of fill-graphic allows for the following extra options:

    -

    .. list-table:: - :class: non-responsive - :header-rows: 1 - :stub-columns: 1 - :widths: 20 10 50 20

    - -

    .. todo:: Add examples using random

    -
    -

    Property Required? Description Default value

    -
    -

    external No Specifies an image to use to style the point. N/A

    -

    url Yes Location of the image. Can either be an actual URL or a file path (relative to where the style file is saved in the GeoServer data directory). Should be enclosed in single quotes. N/A

    -

    format Yes Format of the image. Must be a valid MIME type (such as image/png for PNG, image/jpeg for JPG, image/svg+xml for SVG) N/A

    -

    mark No Specifies a regular shape to use to style the point. N/A

    -

    shape No Shape of the mark. Options are square, circle, triangle, cross, x, and star. square

    -

    size No Size of the mark in pixels. If the aspect ratio of the mark is not 1:1 (square), will apply to the height of the graphic only, with the width scaled proportionally. 16

    -

    anchor No Specify the center of the symbol relative to the feature location. Value is an [x,y] tuple with decimal values from 0-1, with [0,0] meaning that the symbol is anchored to the top left, and [1,1] meaning anchored to bottom right. [0.5,0.5]

    -

    displacement No Specifies a distance to which to move the symbol relative to the feature. Value is an [x,y] tuple with values expressed in pixels, so [10,5] will displace the symbol 10 pixels to the right and 5 pixels down. [0,0]

    -

    opacity No Specifies the level of transparency. Value of 0 means entirely transparent, while 1 means entirely opaque. Only affects graphics referenced by the external parameter; the opacity of mark symbols is controlled by the fill-opacity and stroke-opacity of the mark. 1

    -

    rotation No Value (in degrees) or rotation of the mark. Larger values increase counter-clockwise rotation. A value of 180 will make the mark upside-down. 0

    -
    -

    .. list-table:: - :class: non-responsive - :header-rows: 1 - :stub-columns: 1 - :widths: 20 10 50 20

    - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    PropertyRequired?DescriptionDefault value
    x-graphic-marginNoUsed to specify margins (in pixels) around the graphic used in the fill. Possible values are a list of four (top, right, bottom, left), a list of three (top, right and left, bottom), a list of two (top and bottom, right and left), or a single value.N/A
    x-randomNoActivates random distribution of symbols. Possible values are free or grid. free generates a completely random distribution, and grid will generate a regular grid of positions, and only randomize the position of the symbol around the cell centers, providing a more even distribution.N/A
    x-random-tile-sizeNoWhen used with x-random, determines the size of the grid (in pixels) that will contain the randomly distributed symbols.256
    x-random-rotationNoWhen used with x-random, activates random symbol rotation. Possible values are none or free.none
    x-random-symbol-countNoWhen used tih x-random, determines the number of symbols drawn. Increasing this number will generate a more dense distribution of symbols16
    x-random-seedNoDetermines the "seed" used to generate the random distribution. Changing this value will result in a different symbol distribution.0
    +
    +

    Todo

    +

    Add examples using random

    +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    PropertyRequired?DescriptionDefault value
    externalNoSpecifies an image to use to style the point.N/A
    urlYesLocation of the image. Can either be an actual URL or a file path (relative to where the style file is saved in the GeoServer data directory). Should be enclosed in single quotes.N/A
    formatYesFormat of the image. Must be a valid MIME type (such as image/png for PNG, image/jpeg for JPG, image/svg+xml for SVG)N/A
    markNoSpecifies a regular shape to use to style the point.N/A
    shapeNoShape of the mark. Options are square, circle, triangle, cross, x, and star.square
    sizeNoSize of the mark in pixels. If the aspect ratio of the mark is not 1:1 (square), will apply to the height of the graphic only, with the width scaled proportionally.16
    anchorNoSpecify the center of the symbol relative to the feature location. Value is an [x,y] tuple with decimal values from 0-1, with [0,0] meaning that the symbol is anchored to the top left, and [1,1] meaning anchored to bottom right.[0.5,0.5]
    displacementNoSpecifies a distance to which to move the symbol relative to the feature. Value is an [x,y] tuple with values expressed in pixels, so [10,5] will displace the symbol 10 pixels to the right and 5 pixels down.[0,0]
    opacityNoSpecifies the level of transparency. Value of 0 means entirely transparent, while 1 means entirely opaque. Only affects graphics referenced by the external parameter; the opacity of mark symbols is controlled by the fill-opacity and stroke-opacity of the mark.1
    rotationNoValue (in degrees) or rotation of the mark. Larger values increase counter-clockwise rotation. A value of 180 will make the mark upside-down.0
    + + + + + + + + + + + + + + + + + + + + + + + +
    PropertyRequired?DescriptionDefault value
    geometryNoSpecifies which attribute to use as the geometry (see Geometry transformations in SLD)First geometry attribute found (usually named geom or the_geom)
    uomNoUnit of measure used for width calculations (see Specifying symbolizer sizes in ground units)pixel

    The following properties are equivalent to SLD "vendor options".

    -

    Additional "vendor options" property for :ref:label_obstacles:

    -

    .. list-table:: - :class: non-responsive - :header-rows: 1 - :stub-columns: 1 - :widths: 20 10 50 20

    - +

    Additional "vendor options" property for Label Obstacles:

    + + + + + + + + + + + + + + + + + +
    PropertyRequired?DescriptionDefault value
    x-labelObstacleNoMarks the symbolizer as an obstacle such that labels drawn via a text symbolizer will not be drawn over top of these features. Options are true or false. Note that the bounding boxes of features are used when calculating obstacles, so unintended effects may occur when marking a line or polygon symbolizer as an obstacle.false

    Additional "vendor options" properties for Color compositing and color blending:

    -

    Additional "vendor options" properties for :ref:sld-extensions_composite-blend:

    -

    .. list-table:: - :class: non-responsive - :header-rows: 1 - :stub-columns: 1 - :widths: 20 10 50 20

    - +

    Additional "vendor options" properties for Color compositing and color blending:

    + + + + + + + + + + + + + + + + + + + + + + + +
    PropertyRequired?DescriptionDefault value
    x-compositeNoAllows for both alpha compositing and color blending options between symbolizers.N/A
    x-composite-baseNoAllows the rendering engine to use the symbolizer mapping to define a "base" buffer for subsequent compositing and blending using x-composite. See the section on Feature Styles for more details.false

    Additional "vendor options" properties for Rendering Selection:

    -

    Additional "vendor options" properties for :ref:rendering_selection:

    -

    .. list-table:: - :class: non-responsive - :header-rows: 1 - :stub-columns: 1 - :widths: 20 10 50 20

    - +

    Additional "vendor options" properties for Rendering Selection:

    + + + + + + + + + + + + + + + + + +
    PropertyRequired?DescriptionDefault value
    x-inclusionNoDefine if rule should be included in style for legendOnly or mapOnly.normal

    Examples

    Basic point

    A point symbolizer draws a point at the center of any geometry. It is defined by an external image or a symbol, either of which can be sized and rotated. A mark is a pre-defined symbol that can be drawn at the location of a point. Similar to polygons, marks have both a fill and a stroke. This example shows a point symbolizer that draws semi-transparent red diamonds with black outlines:

    diff --git a/styling/ysld/reference/symbolizers/polygon/index.html b/styling/ysld/reference/symbolizers/polygon/index.html index e9e08aa0b6a..0a33610250f 100644 --- a/styling/ysld/reference/symbolizers/polygon/index.html +++ b/styling/ysld/reference/symbolizers/polygon/index.html @@ -2343,317 +2343,269 @@

    Syntax

    x-inclusion: <text>

    where:

    -

    .. list-table:: - :class: non-responsive - :header-rows: 1 - :stub-columns: 1 - :widths: 20 10 50 20

    - -

    .. list-table:: - :class: non-responsive - :header-rows: 1 - :stub-columns: 1 - :widths: 20 10 50 20

    - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    PropertyRequired?DescriptionDefault value
    stroke-colorNoColor of line features.'#000000' (black)
    stroke-widthNoWidth of line features, measured in pixels.1
    stroke-opacityNoOpacity of line features. Valid values are a decimal value between 0 (completely transparent) and 1 (completely opaque).1
    stroke-linejoinNoHow line segments are joined together. Options are mitre (sharp corner), round (round corner), and bevel (diagonal corner).mitre
    stroke-linecapNoHow line features are rendered at their ends. Options are butt (sharp square edge), round (rounded edge), and square (slightly elongated square edge).butt
    stroke-dasharrayNoA numeric list signifying length of lines and gaps, creating a dashed effect. Units are pixels, so "2 3" would be a repeating pattern of 2 pixels of drawn line followed by 3 pixels of blank space. If only one number is supplied, this will mean equal amounts of line and gap.No dash
    stroke-dashoffsetNoNumber of pixels into the dasharray to offset the drawing of the dash, used to shift the location of the lines and gaps in a dash.0
    stroke-graphicNoA design or pattern to be used along the stroke. Output will always be a linear repeating pattern, and as such is not tied to the value of stroke-width. Can either be a mark consisting of a common shape or a URL that points to a graphic. The <graphic_options> should consist of a mapping containing symbols: followed by an external: or mark:, with appropriate parameters as detailed in the Point symbolizer section. Cannot be used with stroke-graphic-fill.N/A
    stroke-graphic-fillNoA design or pattern to be used for the fill of the stroke. The area that is to be filled is tied directly to the value of stroke-width. Can either be a mark consisting of a common shape or a URL that points to a graphic. The <graphic_options> should consist of a mapping containing symbols: followed by an external: or mark:, with appropriate parameters as detailed in the Point symbolizer section. Cannot be used with stroke-graphic.N/A
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    PropertyRequired?DescriptionDefault value
    fill-colorNoColor of inside of features.'#808080' (gray)
    fill-opacityNoOpacity of the fill. Valid values are a decimal value between 0 (completely transparent) and 1 (completely opaque).1
    fill-graphicNoA design or pattern to be used for the fill of the feature. Can either be a mark consisting of a common shape or a URL that points to a graphic. The <graphic_options> should consist of a mapping containing symbols: followed by an external: or mark:, with appropriate parameters as detailed in the Point symbolizer section.None

    The use of fill-graphic allows for the following extra options:

    -

    .. list-table:: - :class: non-responsive - :header-rows: 1 - :stub-columns: 1 - :widths: 20 10 50 20

    - -

    .. todo:: Add examples using random

    -
    -

    Property Required? Description Default value

    -
    -

    offset No Value in pixels for moving the drawn line relative to the location of the feature. 0

    -

    displacement No Specifies a distance to which to move the symbol relative to the feature. Value is an [x,y] tuple with values expressed in pixels, so [10,5] will displace the symbol 10 pixels to the right, and 5 pixels down. [0,0]

    -
    -

    .. list-table:: - :class: non-responsive - :header-rows: 1 - :stub-columns: 1 - :widths: 20 10 50 20

    - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    PropertyRequired?DescriptionDefault value
    x-graphic-marginNoUsed to specify margins (in pixels) around the graphic used in the fill. Possible values are a list of four (top, right, bottom, left), a list of three (top, right and left, bottom), a list of two (top and bottom, right and left), or a single value.N/A
    x-randomNoActivates random distribution of symbols. Possible values are free or grid. free generates a completely random distribution, and grid will generate a regular grid of positions, and only randomize the position of the symbol around the cell centers, providing a more even distribution.N/A
    x-random-tile-sizeNoWhen used with x-random, determines the size of the grid (in pixels) that will contain the randomly distributed symbols.256
    x-random-rotationNoWhen used with x-random, activates random symbol rotation. Possible values are none or free.none
    x-random-symbol-countNoWhen used tih x-random, determines the number of symbols drawn. Increasing this number will generate a more dense distribution of symbols16
    x-random-seedNoDetermines the "seed" used to generate the random distribution. Changing this value will result in a different symbol distribution.0
    +
    +

    Todo

    +

    Add examples using random

    +
    + + + + + + + + + + + + + + + + + + + + + + + +
    PropertyRequired?DescriptionDefault value
    offsetNoValue in pixels for moving the drawn line relative to the location of the feature.0
    displacementNoSpecifies a distance to which to move the symbol relative to the feature. Value is an [x,y] tuple with values expressed in pixels, so [10,5] will displace the symbol 10 pixels to the right, and 5 pixels down.[0,0]
    + + + + + + + + + + + + + + + + + + + + + + + +
    PropertyRequired?DescriptionDefault value
    geometryNoSpecifies which attribute to use as the geometry (see Geometry transformations in SLD)First geometry attribute found (usually named geom or the_geom)
    uomNoUnit of measure used for width calculations (see Specifying symbolizer sizes in ground units)pixel

    The following properties are equivalent to SLD "vendor options".

    -

    Additional "vendor options" property for :ref:label_obstacles:

    -

    .. list-table:: - :class: non-responsive - :header-rows: 1 - :stub-columns: 1 - :widths: 20 10 50 20

    - +

    Additional "vendor options" property for Label Obstacles:

    + + + + + + + + + + + + + + + + + +
    PropertyRequired?DescriptionDefault value
    x-labelObstacleNoMarks the symbolizer as an obstacle such that labels drawn via a text symbolizer will not be drawn over top of these features. Options are true or false. Note that the bounding boxes of features are used when calculating obstacles, so unintended effects may occur when marking a line or polygon symbolizer as an obstacle.false

    Additional "vendor options" properties for Color compositing and color blending:

    -

    Additional "vendor options" properties for :ref:sld-extensions_composite-blend:

    -

    .. list-table:: - :class: non-responsive - :header-rows: 1 - :stub-columns: 1 - :widths: 20 10 50 20

    - +

    Additional "vendor options" properties for Color compositing and color blending:

    + + + + + + + + + + + + + + + + + + + + + + + +
    PropertyRequired?DescriptionDefault value
    x-compositeNoAllows for both alpha compositing and color blending options between symbolizers.N/A
    x-composite-baseNoAllows the rendering engine to use the symbolizer mapping to define a "base" buffer for subsequent compositing and blending using x-composite. See the section on Feature Styles for more details.false

    Additional "vendor options" properties for Rendering Selection:

    -

    Additional "vendor options" properties for :ref:rendering_selection:

    -

    .. list-table:: - :class: non-responsive - :header-rows: 1 - :stub-columns: 1 - :widths: 20 10 50 20

    - +

    Additional "vendor options" properties for Rendering Selection:

    + + + + + + + + + + + + + + + + + +
    PropertyRequired?DescriptionDefault value
    x-inclusionNoDefine if rule should be included in style for legendOnly or mapOnly.normal

    Examples

    Basic polygon

    Polygon symbolizers have both a stroke and a fill, similar to marks for point symbolizers. The following example draws a polygon symbolizer with a red fill and black stroke with beveled line joins for the stroke:

    diff --git a/styling/ysld/reference/symbolizers/raster/index.html b/styling/ysld/reference/symbolizers/raster/index.html index 3ed7d62cf08..a2b3ae322ff 100644 --- a/styling/ysld/reference/symbolizers/raster/index.html +++ b/styling/ysld/reference/symbolizers/raster/index.html @@ -2391,84 +2391,160 @@

    Raster symbolizer

    x-inclusion: <text>

    where:

    -
    -

    Property Required? Description Default value

    -
    -

    opacity No Opacity of the entire display. Valid values are a decimal between 0 (completely transparent) and 1 (completely opaque). 1

    -

    channels No Selects the band(s) to display and the display method. N/A

    -

    gray No Display a single band as a grayscale image. Cannot be used with red, green, and blue. The <channel_options> can be the band name or a mapping containing name: and contrast-enhancement: (optional). 1

    -

    red No Display three bands as an RGB image. Must be used with green, and blue. Cannot be used with gray. The <channel_options> can be the band name or a mapping containing name: and contrast-enhancement: (optional). 1

    -

    green No Display three bands as an RGB image. Must be used with red, and blue. Cannot be used with gray. The <channel_options> can be the band name or a mapping containing name: and contrast-enhancement: (optional). 2

    -

    blue No Display three bands as an RGB image. Must be used with red, and green. Cannot be used with gray. The <channel_options> can be the band name or a mapping containing name: and contrast-enhancement: (optional). See examples below. 3

    -

    color-map No Creates a mapping of colors to grid values. Can only be used with a single band. N/A

    -

    type No Type of color mapping. Options are ramp, an interpolated list of values; interval, a non-interpolated list of values; and values, where values need to match exactly to be drawn. ramp

    -

    entries No Values for the color mapping. Syntax is a list of tuples. N/A

    -

    color Yes Color for the particular color map entry. Value is a standard color value. N/A

    -

    entry_opacity Yes Opacity of the particular color map entry. Valid values are a decimal between 0 (completely transparent) and 1 (completely opaque). N/A

    -

    band_value Yes Grid value to use for the particular color map entry. Values are data-dependent. Behavior at or around this value is determined by the color ramp type. N/A

    -

    text_label No Label for the particular color map entry Blank

    -

    contrast-enhancement No Modifies the contrast of the display N/A

    -

    mode No Type of contrast enhancement. Options are normalize (stretches contrast so that the smallest and largest values are set to black and white, respectively) or histogram (produces equal number of content in the image at each brightness level). normalize

    -

    gamma No Multiplier value for contrast adjustment. A value greater than 1 will increase darkness, while a value less than 1 will decrease darkness. 1

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    PropertyRequired?DescriptionDefault value
    opacityNoOpacity of the entire display. Valid values are a decimal between 0 (completely transparent) and 1 (completely opaque).1
    channelsNoSelects the band(s) to display and the display method.N/A
    grayNoDisplay a single band as a grayscale image. Cannot be used with red, green, and blue. The <channel_options> can be the band name or a mapping containing name: and contrast-enhancement: (optional).1
    redNoDisplay three bands as an RGB image. Must be used with green, and blue. Cannot be used with gray. The <channel_options> can be the band name or a mapping containing name: and contrast-enhancement: (optional).1
    greenNoDisplay three bands as an RGB image. Must be used with red, and blue. Cannot be used with gray. The <channel_options> can be the band name or a mapping containing name: and contrast-enhancement: (optional).2
    blueNoDisplay three bands as an RGB image. Must be used with red, and green. Cannot be used with gray. The <channel_options> can be the band name or a mapping containing name: and contrast-enhancement: (optional). See examples below.3
    color-mapNoCreates a mapping of colors to grid values. Can only be used with a single band.N/A
    typeNoType of color mapping. Options are ramp, an interpolated list of values; interval, a non-interpolated list of values; and values, where values need to match exactly to be drawn.ramp
    entriesNoValues for the color mapping. Syntax is a list of tuples.N/A
    colorYesColor for the particular color map entry. Value is a standard color value.N/A
    entry_opacityYesOpacity of the particular color map entry. Valid values are a decimal between 0 (completely transparent) and 1 (completely opaque).N/A
    band_valueYesGrid value to use for the particular color map entry. Values are data-dependent. Behavior at or around this value is determined by the color ramp type.N/A
    text_labelNoLabel for the particular color map entryBlank
    contrast-enhancementNoModifies the contrast of the displayN/A
    modeNoType of contrast enhancement. Options are normalize (stretches contrast so that the smallest and largest values are set to black and white, respectively) or histogram (produces equal number of content in the image at each brightness level).normalize
    gammaNoMultiplier value for contrast adjustment. A value greater than 1 will increase darkness, while a value less than 1 will decrease darkness.1

    Additional "vendor options" properties for Color compositing and color blending:

    -

    Additional "vendor options" properties for :ref:sld-extensions_composite-blend:

    -

    .. list-table:: - :class: non-responsive - :header-rows: 1 - :stub-columns: 1 - :widths: 20 10 50 20

    - +

    Additional "vendor options" properties for Color compositing and color blending:

    + + + + + + + + + + + + + + + + + + + + + + + +
    PropertyRequired?DescriptionDefault value
    x-compositeNoAllows for both alpha compositing and color blending options between symbolizers.N/A
    x-composite-baseNoAllows the rendering engine to use the symbolizer mapping to define a "base" buffer for subsequent compositing and blending using x-composite. See the section on Feature Styles for more details.false

    Additional "vendor options" properties for Rendering Selection:

    -

    Additional "vendor options" properties for :ref:rendering_selection:

    -

    .. list-table:: - :class: non-responsive - :header-rows: 1 - :stub-columns: 1 - :widths: 20 10 50 20

    - +

    Additional "vendor options" properties for Rendering Selection:

    + + + + + + + + + + + + + + + + + +
    PropertyRequired?DescriptionDefault value
    x-inclusionNoDefine if rule should be included in style for legendOnly or mapOnly.normal

    Examples

    Todo

    diff --git a/styling/ysld/reference/symbolizers/text/index.html b/styling/ysld/reference/symbolizers/text/index.html index 7a28007a2b7..40751978788 100644 --- a/styling/ysld/reference/symbolizers/text/index.html +++ b/styling/ysld/reference/symbolizers/text/index.html @@ -2449,133 +2449,381 @@

    Syntax

    x-inclusion: <text>

    where:

    -
    -

    Property Required? Description Default value

    -
    -

    fill-color No Color of inside of the label. '#808080' (gray)

    -

    fill-opacity No Opacity of fill of the label text. Valid values are a decimal value between 0 (completely transparent) and 1 (completely opaque). 1

    -

    fill-graphic No A design to be used for the fill of the text label. Can either be a mark consisting of a common shape or a URL that points to a graphic. The <graphic_options> should consist of a mapping containing symbols: followed by an external: or mark:, with appropriate parameters as detailed in the Point symbolizer section. None

    -

    stroke-graphic No A design or pattern to be used along the stroke around the label text. the output will always be a linear repeating pattern, and as such is not tied to the value of stroke-width. Can either be a mark consisting of a common shape or a URL that points to a graphic. The <graphic_options> should consist of a mapping containing symbols: followed by an external: or mark:, with appropriate parameters. Cannot be used with stroke-graphic-fill. N/A

    -

    stroke-graphic-fill No A design or pattern to be used for the fill of the stroke around the label text. This area that is to be filled is tied directly to the value of stroke-width. Can either be a mark consisting of a common shape or a URL that points to a graphic. The <graphic_options> should consist of a mapping containing symbols: followed by an external: or mark:, with appropriate parameters as detailed in the Point symbolizer section. Cannot be used with stroke-graphic. N/A

    -
    -
    -

    Property Required? Description Default value

    -
    -

    label Yes Text to display. Often taken from an attribute but any valid expression that constructs a string will do. N/A

    -

    font-family No Type of font to be used for the label. Options are system dependent; the full list of fonts available can be found via the GeoServer Server Status page. serif

    -

    font-size No Size of the font. 10

    -

    font-style No Style of the font. Options are normal, italic, and oblique. normal

    -

    font-weight No Weight of the font. Options are normal and bold. normal

    -

    placement No Determines whether the label is to be drawn derived from a point or a line. point

    -

    offset No Value (in pixels) for moving the drawn label relative to the location of the feature. A positive value will shift the label in the direction of its top, while a negative value will shift the label in the direction of its bottom. Only valid for when type is set to line. 0

    -

    anchor No Specify the center of the symbol relative to the feature location (centroid for lines and polygons). Value is an [x,y] tuple with decimal values from 0-1, with [0,0] meaning that the symbol is anchored to the bottom left of the label, and [1,1] meaning anchored to the top right of the label. [0,0]

    -

    displacement No Specifies a distance (in pixels) to which to move the label relative to the feature. Value is an [x,y] tuple with values expressed in pixels, so [10,5] will displace the label 10 pixels to the right and 5 pixels up. Only valid for when type is set to point. [0,0]

    -

    rotation No Value (in degrees) or rotation of the label. Larger values increase counter-clockwise rotation. A value of 180 will make the label upside-down. Only valid for when type is set to point. 0

    -

    priority No The priority used when choosing which labels to display during conflict resolution. Higher priority values take precedence over lower priority values. 1000

    -

    halo No Creates a shaded area around the label for easier legibility No halo

    -

    radius No Size (in pixels) of the halo 1

    -

    fill-color No Color of the halo '#808080'

    -

    fill-opacity No Specifies the level of transparency for the halo. Value of 0 means entirely transparent, while 1 means entirely opaque. 1

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    PropertyRequired?DescriptionDefault value
    fill-colorNoColor of inside of the label.'#808080' (gray)
    fill-opacityNoOpacity of fill of the label text. Valid values are a decimal value between 0 (completely transparent) and 1 (completely opaque).1
    fill-graphicNoA design to be used for the fill of the text label. Can either be a mark consisting of a common shape or a URL that points to a graphic. The <graphic_options> should consist of a mapping containing symbols: followed by an external: or mark:, with appropriate parameters as detailed in the Point symbolizer section.None
    stroke-graphicNoA design or pattern to be used along the stroke around the label text. the output will always be a linear repeating pattern, and as such is not tied to the value of stroke-width. Can either be a mark consisting of a common shape or a URL that points to a graphic. The <graphic_options> should consist of a mapping containing symbols: followed by an external: or mark:, with appropriate parameters. Cannot be used with stroke-graphic-fill.N/A
    stroke-graphic-fillNoA design or pattern to be used for the fill of the stroke around the label text. This area that is to be filled is tied directly to the value of stroke-width. Can either be a mark consisting of a common shape or a URL that points to a graphic. The <graphic_options> should consist of a mapping containing symbols: followed by an external: or mark:, with appropriate parameters as detailed in the Point symbolizer section. Cannot be used with stroke-graphic.N/A
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    PropertyRequired?DescriptionDefault value
    labelYesText to display. Often taken from an attribute but any valid expression that constructs a string will do.N/A
    font-familyNoType of font to be used for the label. Options are system dependent; the full list of fonts available can be found via the GeoServer Server Status page.serif
    font-sizeNoSize of the font.10
    font-styleNoStyle of the font. Options are normal, italic, and oblique.normal
    font-weightNoWeight of the font. Options are normal and bold.normal
    placementNoDetermines whether the label is to be drawn derived from a point or a line.point
    offsetNoValue (in pixels) for moving the drawn label relative to the location of the feature. A positive value will shift the label in the direction of its top, while a negative value will shift the label in the direction of its bottom. Only valid for when type is set to line.0
    anchorNoSpecify the center of the symbol relative to the feature location (centroid for lines and polygons). Value is an [x,y] tuple with decimal values from 0-1, with [0,0] meaning that the symbol is anchored to the bottom left of the label, and [1,1] meaning anchored to the top right of the label.[0,0]
    displacementNoSpecifies a distance (in pixels) to which to move the label relative to the feature. Value is an [x,y] tuple with values expressed in pixels, so [10,5] will displace the label 10 pixels to the right and 5 pixels up. Only valid for when type is set to point.[0,0]
    rotationNoValue (in degrees) or rotation of the label. Larger values increase counter-clockwise rotation. A value of 180 will make the label upside-down. Only valid for when type is set to point.0
    priorityNoThe priority used when choosing which labels to display during conflict resolution. Higher priority values take precedence over lower priority values.1000
    haloNoCreates a shaded area around the label for easier legibilityNo halo
    radiusNoSize (in pixels) of the halo1
    fill-colorNoColor of the halo'#808080'
    fill-opacityNoSpecifies the level of transparency for the halo. Value of 0 means entirely transparent, while 1 means entirely opaque.1

    The following properties allow for a graphic to be displayed in addition to just a label. This is used when drawing "shields" (text over top of a graphic) such as in road signs.

    -
    -

    Property Required? Description Default value

    -
    -

    graphic No Specifies whether a graphic is to be drawn for the label. N/A (no graphic)

    -

    symbols No The details of the graphic. Consists of an external: or mark: section, with appropriate parameters as detailed in the Point symbolizer section. N/A

    -

    size No Size of the graphic in pixels. If the aspect ratio is not 1:1 (square), will apply to the height of the graphic only, with the width scaled proportionally. 16

    -

    opacity No Specifies the level of transparency for the graphic. Value of 0 means entirely transparent, while 1 means entirely opaque. 1

    -

    rotation No Value (in degrees) or rotation of the graphic. Larger values increase counter-clockwise rotation. A value of 180 will make the graphic upside-down. 0

    -
    -

    .. list-table:: - :class: non-responsive - :header-rows: 1 - :stub-columns: 1 - :widths: 20 10 50 20

    - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    PropertyRequired?DescriptionDefault value
    graphicNoSpecifies whether a graphic is to be drawn for the label.N/A (no graphic)
    symbolsNoThe details of the graphic. Consists of an external: or mark: section, with appropriate parameters as detailed in the Point symbolizer section.N/A
    sizeNoSize of the graphic in pixels. If the aspect ratio is not 1:1 (square), will apply to the height of the graphic only, with the width scaled proportionally.16
    opacityNoSpecifies the level of transparency for the graphic. Value of 0 means entirely transparent, while 1 means entirely opaque.1
    rotationNoValue (in degrees) or rotation of the graphic. Larger values increase counter-clockwise rotation. A value of 180 will make the graphic upside-down.0
    + + + + + + + + + + + + + + + + + + + + + + + +
    PropertyRequired?DescriptionDefault value
    geometryNoSpecifies which attribute to use as the geometry (see Geometry transformations in SLD)First geometry attribute found (usually named geom or the_geom)
    uomNoUnit of measure used for width calculations (see Specifying symbolizer sizes in ground units)pixel

    The following properties are equivalent to SLD "vendor options".

    -
    -

    Property Required? Description Default value

    -
    -

    x-allowOverruns No Allows labels on lines to move slightly beyond the beginning or end of the line. true

    -

    x-autoWrap No The number of pixels beyond which a label will be wrapped over multiple lines. Cannot use with x-followLine. 0

    -

    x-conflictResolution No Enables conflict resolution, meaning no two labels will be allowed to overlap. Without conflict resolution, symbolizers can overlap with other labels. true

    -

    x-followLine No On linear geometries, the label will follow the shape of the current line, as opposed to being drawn at a tangent. Will override false

    -

    x-forceLeftToRight No Forces labels to a readable orientation, otherwise will follow the line orientation, possibly making the label look upside-down. This setting is useful when using symbol fonts to add direction markers along a line. false

    -

    x-goodnessOfFit No Percentage (expressed as a decimal between 0-1) of the label that must fit inside the geometry to permit the label to be drawn. Works only on polygon features. 0.5

    -

    x-graphic-margin No Number of pixels between the stretched graphic and the text. Only applies when x-graphic-resize is set to stretch or proportional. 0

    -

    x-graphic-resize No Allows for stretching the graphic underneath a label to fit the label size. Options are none, stretch or proportional. Used in conjunction with x-graphic-margin.. none

    -

    x-group No Geometries with identical labels will be considered a single entity to be labeled. Used to control repeated labels. false

    -

    x-labelAllGroup No Used in conjunction with x-group. When true all items in a group are labeled. When false, only the largest geometry in the group is labeled. Valid for lines only. false

    -

    x-repeat No Desired distance (in pixels) between labels drawn on a group. If zero, only one label will be drawn. Used in conjunction with x-group. Valid for lines only. 0

    -

    x-maxAngleDelta No Maximum allowed angle (in degrees) between two characters in a curved label. Used in conjunction with x-followLine. Values higher than 30 may cause loss of legibility of the label. 22.5

    -

    x-maxDisplacement No Distance (in pixels) a label can be displaced from its natural position in an attempt to eliminate conflict with other labels. 0

    -

    x-minGroupDistance No Minimum distance (in pixels) between two labels in the same label group. Used in conjunction with displacement or repeat to avoid having two labels too close to each other No minimum distance

    -

    x-partials No Will display partial labels (truncated on the border of the display area). false

    -

    x-polygonAlign No Overrides manual rotation to align label rotation automatically. Valid for polygons only. false

    -

    x-spaceAround No Minimum distance (in pixels) between two labels. A negative value specifies the maximum overlap between two labels. 0

    -

    x-underlineText No Instruct the renderer to underline labels. false

    -

    x-strikethroughText No Instruct the renderer to strikethrough labels. false

    -

    x-charSpacing No The option controls the amount of space between characters, a positive value increases it, a negative value shrinks it (and will eventually make characters overlap). The value is specified in pixels. 0

    -

    x-wordSpacing No The option controls the amount of space between words, for this option only positive values (or zero) are accepted. The value is specified in pixels. 0

    -
    -

    Additional "vendor options" properties for :ref:sld-extensions_composite-blend:

    -

    .. list-table:: - :class: non-responsive - :header-rows: 1 - :stub-columns: 1 - :widths: 20 10 50 20

    - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    PropertyRequired?DescriptionDefault value
    x-allowOverrunsNoAllows labels on lines to move slightly beyond the beginning or end of the line.true
    x-autoWrapNoThe number of pixels beyond which a label will be wrapped over multiple lines. Cannot use with x-followLine.0
    x-conflictResolutionNoEnables conflict resolution, meaning no two labels will be allowed to overlap. Without conflict resolution, symbolizers can overlap with other labels.true
    x-followLineNoOn linear geometries, the label will follow the shape of the current line, as opposed to being drawn at a tangent. Will overridefalse
    x-forceLeftToRightNoForces labels to a readable orientation, otherwise will follow the line orientation, possibly making the label look upside-down. This setting is useful when using symbol fonts to add direction markers along a line.false
    x-goodnessOfFitNoPercentage (expressed as a decimal between 0-1) of the label that must fit inside the geometry to permit the label to be drawn. Works only on polygon features.0.5
    x-graphic-marginNoNumber of pixels between the stretched graphic and the text. Only applies when x-graphic-resize is set to stretch or proportional.0
    x-graphic-resizeNoAllows for stretching the graphic underneath a label to fit the label size. Options are none, stretch or proportional. Used in conjunction with x-graphic-margin..none
    x-groupNoGeometries with identical labels will be considered a single entity to be labeled. Used to control repeated labels.false
    x-labelAllGroupNoUsed in conjunction with x-group. When true all items in a group are labeled. When false, only the largest geometry in the group is labeled. Valid for lines only.false
    x-repeatNoDesired distance (in pixels) between labels drawn on a group. If zero, only one label will be drawn. Used in conjunction with x-group. Valid for lines only.0
    x-maxAngleDeltaNoMaximum allowed angle (in degrees) between two characters in a curved label. Used in conjunction with x-followLine. Values higher than 30 may cause loss of legibility of the label.22.5
    x-maxDisplacementNoDistance (in pixels) a label can be displaced from its natural position in an attempt to eliminate conflict with other labels.0
    x-minGroupDistanceNoMinimum distance (in pixels) between two labels in the same label group. Used in conjunction with displacement or repeat to avoid having two labels too close to each otherNo minimum distance
    x-partialsNoWill display partial labels (truncated on the border of the display area).false
    x-polygonAlignNoOverrides manual rotation to align label rotation automatically. Valid for polygons only.false
    x-spaceAroundNoMinimum distance (in pixels) between two labels. A negative value specifies the maximum overlap between two labels.0
    x-underlineTextNoInstruct the renderer to underline labels.false
    x-strikethroughTextNoInstruct the renderer to strikethrough labels.false
    x-charSpacingNoThe option controls the amount of space between characters, a positive value increases it, a negative value shrinks it (and will eventually make characters overlap). The value is specified in pixels.0
    x-wordSpacingNoThe option controls the amount of space between words, for this option only positive values (or zero) are accepted. The value is specified in pixels.0
    +

    Additional "vendor options" properties for Color compositing and color blending:

    + + + + + + + + + + + + + + + + + + + + + + + +
    PropertyRequired?DescriptionDefault value
    x-compositeNoAllows for both alpha compositing and color blending options between symbolizers.N/A
    x-composite-baseNoAllows the rendering engine to use the symbolizer mapping to define a "base" buffer for subsequent compositing and blending using x-composite. See the section on Feature Styles for more details.false

    Examples

    Basic label

    Text symbolizers are used to draw labels on objects. The label text is usually linked to some attribute of the layer. Font options are available in the font-family, font-size, font-style, and font-weight properties. The following example draws a label using the name attribute of the layer, and with a SansSerif font of size 12, gray color, bold and italic:

    diff --git a/styling/ysld/reference/transforms/index.html b/styling/ysld/reference/transforms/index.html index 94053131a92..442d73d7e54 100644 --- a/styling/ysld/reference/transforms/index.html +++ b/styling/ysld/reference/transforms/index.html @@ -2309,20 +2309,53 @@

    Syntax

    ...

    where:

    -
    -

    Property Required? Description Default value

    -
    -

    name Yes Full name of the rendering transform including any prefixes (such as vec:Heatmap) N/A

    -

    params Yes All input parameters for the rendering transformation. Content will vary greatly based on the amount and type of parameters needed. N/A

    -
    + + + + + + + + + + + + + + + + + + + + + + + +
    PropertyRequired?DescriptionDefault value
    nameYesFull name of the rendering transform including any prefixes (such as vec:Heatmap)N/A
    paramsYesAll input parameters for the rendering transformation. Content will vary greatly based on the amount and type of parameters needed.N/A

    The values in the params options typically include values, strings, or attributes. However, it can be useful with a transformation to include environment parameters that concern the position and size of the map when it is rendered. For example, the following are common reserved environment parameters:

    -
    -

    Environment parameter Description

    -
    -

    env('wms_bbox') The bounding box of the request

    -

    env('wms_width') The width of the request

    -

    env('wms_height') The height of the request

    -
    + + + + + + + + + + + + + + + + + + + + + +
    Environment parameterDescription
    env('wms_bbox')The bounding box of the request
    env('wms_width')The width of the request
    env('wms_height')The height of the request

    With this in mind, the following params are assumed unless otherwise specified:

    params:
       ...
    diff --git a/styling/ysld/reference/variables/index.html b/styling/ysld/reference/variables/index.html
    index bd2b1815d7f..a8a90b6dd05 100644
    --- a/styling/ysld/reference/variables/index.html
    +++ b/styling/ysld/reference/variables/index.html
    @@ -2356,13 +2356,36 @@ 

    Define a single value

    define: &variable <value>
     

    where:

    -
    -

    Attribute Required? Description Default value

    -
    -

    define Yes Starts the definition block. N/A

    -

    &variable Yes The name of the variable being defined. The & is not part of the variable name. N/A

    -

    <value> Yes A single value, such as 512 or '#DD0000' N/A

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    AttributeRequired?DescriptionDefault value
    defineYesStarts the definition block.N/A
    &variableYesThe name of the variable being defined. The & is not part of the variable name.N/A
    <value>YesA single value, such as 512 or '#DD0000'N/A

    The syntax for using this variable is to prepend the variable name with a *:

    <directive>: *variable
     
    diff --git a/tutorials/imagemosaic_timeseries/imagemosaic_timeseries/index.html b/tutorials/imagemosaic_timeseries/imagemosaic_timeseries/index.html index 3484e40a8b0..6eceb12e144 100644 --- a/tutorials/imagemosaic_timeseries/imagemosaic_timeseries/index.html +++ b/tutorials/imagemosaic_timeseries/imagemosaic_timeseries/index.html @@ -2624,42 +2624,149 @@

    MOSAIC_DIR and the Configuration

    Otherwise the usage of a shapefile could be useful in development and test environments due to less configurations are needed.

    datastore.properties

    Here is shown an example of datastore.properties suitable for Postgis.

    -
    -

    Parameter Mandatory Description

    -

    SPI Y The factory class used for the datastore e.g. org.geotools.data.postgis.PostgisNGDataStoreFactory

    -

    host Y The host name of the database.

    -

    port Y The port of the database

    -

    database Y The name/instance of the database.

    -

    schema Y The name of the database schema.

    -

    user Y The database user.

    -

    passwd Y The database password.

    -

    Loose bbox N default 'false' Boolean value to specify if loosing the bounding box.

    -

    Estimated extend N default 'true' Boolean values to specify if the extent of the data should be estimated.

    -

    validate connections N default 'true' Boolean value to specify if the connection should be validated.

    -

    Connection timeout N default '20' Specifies the timeout in minutes.

    -

    preparedStatements N default 'false' Boolean flag that specifies if for the database queries prepared statements should be used. This improves performance, because the database query parser has to parse the query only once

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ParameterMandatoryDescription
    SPIYThe factory class used for the datastore e.g. org.geotools.data.postgis.PostgisNGDataStoreFactory
    hostYThe host name of the database.
    portYThe port of the database
    databaseYThe name/instance of the database.
    schemaYThe name of the database schema.
    userYThe database user.
    passwdYThe database password.
    Loose bboxN default 'false'Boolean value to specify if loosing the bounding box.
    Estimated extendN default 'true'Boolean values to specify if the extent of the data should be estimated.
    validate connectionsN default 'true'Boolean value to specify if the connection should be validated.
    Connection timeoutN default '20'Specifies the timeout in minutes.
    preparedStatementsN default 'false'Boolean flag that specifies if for the database queries prepared statements should be used. This improves performance, because the database query parser has to parse the query only once

    Note

    The first 8 parameters are valid for each DBMS used, the last 4 may vary from different DBMS. for more information see :geotoolsGeoTools JDBC documentation <jdbc/index.html>.

    indexer.properties

    -
    -

    Parameter Mandatory Description

    -

    TimeAttribute N Specifies the name of the time-variant attribute

    -

    ElevationAttribute N Specifies the name of the elevation attribute.

    -

    Schema Y A comma separated sequence that describes the mapping between attribute and the data type.

    -

    PropertyCollectors Y Specifies the extractor classes.

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ParameterMandatoryDescription
    TimeAttributeNSpecifies the name of the time-variant attribute
    ElevationAttributeNSpecifies the name of the elevation attribute.
    SchemaYA comma separated sequence that describes the mapping between attribute and the data type.
    PropertyCollectorsYSpecifies the extractor classes.

    Warning

    TimeAttribute is not a mandatory param but for the purpose of this tutorial is needed.

    timeregex.properties

    -
    -

    Parameter Mandatory Description

    -

    regex Y Specifies the pattern used for extracting the information from the file

    -
    + + + + + + + + + + + + + + + + + + + + +
    ParameterMandatoryDescription
    regexYSpecifies the pattern used for extracting the information from the file

    After this you can create a new ImageMosaic datastore.

    Install and setup a DBMS instance

    First of all, note that the usage of a DBMS to store the mosaic indexes is not mandatory. If the user does not create a datastore.properties file in the MOSAIC_DIR, then the plugin will use a shapefile. The shapefile will be created in the MOSAIC_DIR.

    diff --git a/tutorials/palettedimage/palettedimage/index.html b/tutorials/palettedimage/palettedimage/index.html index 98509b206b7..237693dff31 100644 --- a/tutorials/palettedimage/palettedimage/index.html +++ b/tutorials/palettedimage/palettedimage/index.html @@ -2184,13 +2184,66 @@

    An Example with Vector Data

    PNG + custom palette <http://geoserver.org/download/attachments/1278244/nyp.pal?version=1>_

    The attachments include also the GIF outputs, whose size, appearance and generation time does not differ significantly from the PNG outputs.

    As we can see, depending on the choice we have a variation on the image quality, size and generation time (which has been recorded using the FasterFox Firefox extension timer, with the browser sitting on the same box as the server). Using palette=xxx provides the best match in speed and size, though using the built-in internet safe palette altered the colors. Then again, the real gain can be seen only by assuming a certain connection speed between the server and the client, and adding the time required to move the image to the client. The following table provides some results:

    -
    -

    Configuration GT(s) File size (kb) TT 256kbit/s TT 1MBit/s TT 4MBit/s TT 20MBit/s

    -

    tiger-ny-png 0,36 257 8,39 2,42 0,87 0,46

    -

    tyger-ny-png8 0,6 60 2,48 1,08 0,72 0,62

    -

    tiger-ny-png + safe palette 0,3 56 22,05 0,75 0,41 0,32

    -

    tiger-ny-png + custom palette 0,3 59 2,14 0,77 0,42 0,32

    -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ConfigurationGT(s)File size (kb)TT 256kbit/sTT 1MBit/sTT 4MBit/sTT 20MBit/s
    tiger-ny-png0,362578,392,420,870,46
    tyger-ny-png80,6602,481,080,720,62
    tiger-ny-png + safe palette0,35622,050,750,410,32
    tiger-ny-png + custom palette0,3592,140,770,420,32

    Legend:

    • GT: map generation time on the same box
    • diff --git a/tutorials/wmsreflector/index.html b/tutorials/wmsreflector/index.html index aefac45af43..8376223ecd3 100644 --- a/tutorials/wmsreflector/index.html +++ b/tutorials/wmsreflector/index.html @@ -2206,16 +2206,48 @@

      Overview

      This request only specifies that you want the reflector (wms/reflect) to return an OpenLayers application (format=application/openlayers), that you want it to display the feature "topp:states" (layers=topp:states) and that the width should be 800 pixels (width=800). However, this will not return the exact same value as above. Instead, the reflector will zoom to the bounds of the feature and return a map that is 800 pixels wide, but with the height adjusted to the aspect ratio of the feature.

      Using the WMS Reflector

      To use the WMS reflector all one must do is specify wms/reflect? as opposed to wms? in a request. The only mandatory parameter to a WMS reflector call is the layers parameter. As stated above the reflector fills in sensible defaults for the rest of the parameters. The following table lists all the defaults used:

      -
      -

      request getmap

      -

      service wms

      -

      version 1.1.1

      -

      format image/png

      -

      width 512

      -

      height 512 if width is not specified

      -

      srs EPSG:4326

      -

      bbox bounds of layer(s)

      -
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      requestgetmap
      servicewms
      version1.1.1
      formatimage/png
      width512
      height512 if width is not specified
      srsEPSG:4326
      bboxbounds of layer(s)

      Any of these defaults can be overridden when specifying the request. The styles parameter is derived by using the default style as configured by GeoServer for each layer specified in the layers parameter.

      Any parameter you send with a WMS request is also legitimate when requesting data from the reflector. Its strength is what it does with the parameters you do not specify, which is explored in the next section.

      layers: This is the only mandatory parameter. It is a comma separated list of the layers you wish to include in your image or OpenLayers application.